1600 行 Python，吞吐超 vLLM？

「1600 行 Python，吞吐超 vLLM？」这个标题里的问号，就是本文要拆的东西。LiteMoE 是 11 月 1 日创建的新仓库，Apache-2.0 协议，目前 22 个星，README 的副标题是「A MoE inference engine you can read in an afternoon」：一个下午就能读完的 MoE 推理引擎。作者的定位原话很清醒：「Use vLLM for production. Use LiteMoE to learn how MoE inference works, or as a small base for experiments.」上线还是用 vLLM，LiteMoE 是教材和实验底座。配套还有一个交互演示，能逐步看一次真实推理的全程：token 进出、top-5 候选、KV Cache 增长、每层的专家路由；另有 11 节中文推理教程。

一、「吞吐超 vLLM」逐项拆开

这个说法成立的场景是：固定批次、贪心解码、单 GPU、只有 Granite 3.1 的两个尺寸（1B，3.5GB；3B，7.5GB）、上下文上限 4096。在这个受限场景里，LiteMoE 的吞吐是 vLLM 的 105% 到 109%。逐项列数字：A100 上 Granite 1B 是 110.6%、3B 是 107.1%，总体 108.8%；L4 上 1B 是 105.5%、3B 是 105.0%，总体 105.3%。方法论反而是全文的亮点：同一次分配里在一张卡上先后跑两个引擎；固定输入加预热，取 5 次的中位数；多个场景取几何平均。作者有句话值得所有跑分引用者抄下来：「只报最高值就是误导」。

二、质量验证：未检测到损失不等于没有损失

不只是跑速度。GSM8K 全部 1319 题（Granite 3B，A100）：LiteMoE 46.2%，vLLM 47.2%，差值 -0.9，95% 置信区间 -2.9 到 +1.1。作者的结论写法很克制：未检测到损失，而不是「没有损失」。这个口径区分在 AI 报告里太少见了。

三、速度从哪来：算子外的执行层

先说清关系：LiteMoE 直接调用 vLLM 的 expert、attention 和 router 算子，自己拥有的是 forward、KV Cache 和生成循环。所以提升不来自算子，来自「算子外的执行层」。最大的一项叫 Lean Decode：把 Decode 阶段里不影响活请求的工作全部删掉，每层的掩码、专家编号的索引查找、输出复制，核心思想是「已结束的请求，算错了也没关系，只要不影响别人」。整个 Decode 跑成一张 CUDA Graph，A100 上加 15% 到 19%，L4 上加 4% 到 6%。代价也要写明：快路径改变了 BF16 的舍入顺序，输出和参考实现不再逐位相同。

四、舍掉了什么

README 原话：「vLLM also runs a scheduler and a full serving stack, which LiteMoE doesn't have.」其他模型、多卡、采样、线上服务、动态批处理，全部不在范围内。这就是那 5% 到 9% 的真实含金量：在「同一张卡、固定批次、贪心解码、单一模型」的受限条件下，赢了一个背着调度器和全套服务栈的 vLLM。

五、冷水：四条都得泼

一，苹果比橙子：拿轻量固定批次引擎对比带调度器加服务栈的 vLLM，作者自己在 README 里写明了这个限定。二，场景极窄：混合长度场景只有 100% 左右，等于没赢；没有动态批处理就没有线上价值。三，项目才 3 天、22 星，长期维护是未知数。四，精度口径要记住：「未检测到损失」在统计上不等于「没有损失」。

六、判断

这不是一篇挑战 vLLM 的檄文，而是一份「执行层仍有油水可榨」的证明：vLLM 背着全套服务栈还能被一个 1600 行的玩具在受限场景里小胜，说明 Decode 阶段的浪费是真实存在的，Lean Decode 的思路（证明某项工作没必要，比微调算子更值钱）值得所有推理框架作者抄走。对读者来说，它的学习材料价值可能大于工程价值：一个下午读完的代码、逐步演示的 visualizer、11 节中文教程，第 9 节的测试方法论单拎出来都算一堂课。

来源：github.com/ZhuLinsen/LiteMoE（第一手，README 全文已读，2026-11-03 直读）；11 节中文推理教程（全文已读）；V2EX 原帖 v2ex.com/t/1253957。