https://cybersecurityerial.github.io/echo_blog/tags/sglang/Recent content in SGLang on Echo的技术博客Hugozh-cnTue, 28 Jul 2026 20:55:18 +0800https://cybersecurityerial.github.io/echo_blog/posts/llm-system-sglang-01-shared-expert-fusion/Tue, 28 Jul 2026 20:55:18 +0800https://cybersecurityerial.github.io/echo_blog/posts/llm-system-sglang-01-shared-expert-fusion/<blockquote> <p>这篇笔记把 SGLang 共享专家融合的计算语义、权重布局和执行路径压缩成六张结构图。图中的实现判断以 2026-07-29 的 SGLang <code>main</code> 分支为准；正文只补充图中容易误读的部分。</p> </blockquote> <h2 id="从双路径到一次-moe-gemm">从双路径到一次 MoE GEMM</h2> <p><img alt="SGLang 共享专家融合：从双路径到一次 MoE GEMM" loading="lazy" src="https://cybersecurityerial.github.io/echo_blog/images/llm-system-sglang-shared-expert-fusion/01-fusion-overview.png"></p> <p>融合不是让 Router 在 Shared Expert 与 Routed Expert 之间做选择。Shared Expert 仍然是必经计算，只是被追加为一个额外的 Expert Slot，并随路由结果一起交给 MoE Kernel。这样 Routed Expert 与 Shared Expert 可以在一次 MoE GEMM 中完成，省去独立的 Shared Expert GEMM 与 Kernel Launch。</p> <h2 id="layouttop-k-与权重重映射">Layout、Top-K 与权重重映射</h2> <p><img alt="SGLang 共享专家融合的 Layout、Top-K 与权重重映射" loading="lazy" src="https://cybersecurityerial.github.io/echo_blog/images/llm-system-sglang-shared-expert-fusion/02-layout-topk-weight-remap.png"></p> <p>普通布局是在 <code>N</code> 个 Routed Expert 后追加一个 Shared Expert，得到 <code>N + 1</code> 个 Slot，并把实际执行的 Expert 数增加一。当前 DeepEP / Mega 系列后端还需要为各个 EP Rank 保留本地 Shared Expert Slot，因此布局会扩展为 <code>N + EP_size</code>。Checkpoint Loader 随后把 <code>mlp.shared_experts</code> 的权重重映射到追加的 Slot；只改 Expert ID 而不改加载布局，并不能得到正确结果。</p>https://cybersecurityerial.github.io/echo_blog/posts/why-vllm-and-sglang-fail-in-generative-search-and-recommendation/Thu, 16 Jul 2026 00:00:00 +0800https://cybersecurityerial.github.io/echo_blog/posts/why-vllm-and-sglang-fail-in-generative-search-and-recommendation/<h2 id="workload的区别">workload的区别</h2> <p>推理的类型是非常多的，RL rollout，在线服务，推荐&hellip;&hellip;这些workload都不一样，虽然说推理框架这一层原则上是一个runtime的workload调度层，但是随着不断的发展，每个推理框架也并不能做到对任意的workload都有一套好的runtime策略，最终这几个框架的优化还是固化到了某几个场景，比如高贵的RL后训练，比如最主流的Serving，然后一些类似于广告推荐的边缘场景就被一脚踢死了（笑。</p> <p>这他吗就很尴尬呀，现状就是典型场景已经穷尽了可能性，没东西做了，非典型的场景又没好的实现，导致必须从头开始吃屎，不过这里不吐槽这种极度的不均衡，只谈谈为什么知名的v和s两家推理框架换个场景就不行了，本质上是在讨论workload。</p> <p>v和s两家框架面向的是在线序列的批处理，也就是一下QPS来了很多，然后以一个很高效的调度方式让这些任务都能被调度起来。框架层只是下发，实际的工作都在算子队列里面。而GR显然不一样，作为推荐输入的embedding是共享的，推理出来的东西是一个多级索引，这个多级索引被硬编码为token，输出token只能从这里挑选，一般叫Sematic ID（所以也得小小扩充一下词表）。然后一般的GR还会做beam search，类似于给非top的输出一次参与后续自回归生成机会，以增加结果的diversity。这个操作对于传统llm来说是很少见的。</p> <p>做beam的时候虽然kvcache解决了重计算的问题，prefix sharing或copyonwrite解决了重复存储的问题，但是beam阶段load同一kv的操作依然是问题。算子上这是很多次重复没必要的G2S。如果要改这个算子的话，会更麻烦。</p> <h2 id="beam导致的kv重排">beam导致的kv重排</h2> <p>beam因为在自回归这一层做了分叉，原先设计的那种纯顺序化的kvcache就很容易出问题了，beam会主动更新自己候选的beam，也就是说他的batch来自于beam主动的而不是外界来的很多共同前缀的请求。beam能主动产生batch也能修改他们的顺序关系（熵之源说是），一旦修改了，就和顺序化的自回归假设不一样了，就得重新换block/radix treenode顺序。beam的候选+淘汰对传统自回归的范式设计影响太大了，必须得侵入式修改算子+框架。</p> <h2 id="其他调度">其他调度</h2> <p>gr还会有很多奇奇怪怪的前处理后处理，这些都没被v和s优化过，所以自然性能也不行。</p>