SGLang

这篇笔记把 SGLang 共享专家融合的计算语义、权重布局和执行路径压缩成六张结构图。图中的实现判断以 2026-07-29 的 SGLang main 分支为准；正文只补充图中容易误读的部分。 从双路径到一次 MoE GEMM 融合不是让 Router 在 Shared Expert 与 Routed Expert 之间做选择。Shared Expert 仍然是必经计算，只是被追加为一个额外的 Expert Slot，并随路由结果一起交给 MoE Kernel。这样 Routed Expert 与 Shared Expert 可以在一次 MoE GEMM 中完成，省去独立的 Shared Expert GEMM 与 Kernel Launch。 Layout、Top-K 与权重重映射 普通布局是在 N 个 Routed Expert 后追加一个 Shared Expert，得到 N + 1 个 Slot，并把实际执行的 Expert 数增加一。当前 DeepEP / Mega 系列后端还需要为各个 EP Rank 保留本地 Shared Expert Slot，因此布局会扩展为 N + EP_size。Checkpoint Loader 随后把 mlp.shared_experts 的权重重映射到追加的 Slot；只改 Expert ID 而不改加载布局，并不能得到正确结果。 ...

workload的区别 推理的类型是非常多的，RL rollout，在线服务，推荐……这些workload都不一样，虽然说推理框架这一层原则上是一个runtime的workload调度层，但是随着不断的发展，每个推理框架也并不能做到对任意的workload都有一套好的runtime策略，最终这几个框架的优化还是固化到了某几个场景，比如高贵的RL后训练，比如最主流的Serving，然后一些类似于广告推荐的边缘场景就被一脚踢死了（笑。 这他吗就很尴尬呀，现状就是典型场景已经穷尽了可能性，没东西做了，非典型的场景又没好的实现，导致必须从头开始吃屎，不过这里不吐槽这种极度的不均衡，只谈谈为什么知名的v和s两家推理框架换个场景就不行了，本质上是在讨论workload。 v和s两家框架面向的是在线序列的批处理，也就是一下QPS来了很多，然后以一个很高效的调度方式让这些任务都能被调度起来。框架层只是下发，实际的工作都在算子队列里面。而GR显然不一样，作为推荐输入的embedding是共享的，推理出来的东西是一个多级索引，这个多级索引被硬编码为token，输出token只能从这里挑选，一般叫Sematic ID（所以也得小小扩充一下词表）。然后一般的GR还会做beam search，类似于给非top的输出一次参与后续自回归生成机会，以增加结果的diversity。这个操作对于传统llm来说是很少见的。 做beam的时候虽然kvcache解决了重计算的问题，prefix sharing或copyonwrite解决了重复存储的问题，但是beam阶段load同一kv的操作依然是问题。算子上这是很多次重复没必要的G2S。如果要改这个算子的话，会更麻烦。 beam导致的kv重排 beam因为在自回归这一层做了分叉，原先设计的那种纯顺序化的kvcache就很容易出问题了，beam会主动更新自己候选的beam，也就是说他的batch来自于beam主动的而不是外界来的很多共同前缀的请求。beam能主动产生batch也能修改他们的顺序关系（熵之源说是），一旦修改了，就和顺序化的自回归假设不一样了，就得重新换block/radix treenode顺序。beam的候选+淘汰对传统自回归的范式设计影响太大了，必须得侵入式修改算子+框架。 其他调度 gr还会有很多奇奇怪怪的前处理后处理，这些都没被v和s优化过，所以自然性能也不行。