系列:每日AI热点

每日AI热点 · 2026-08-21:共享专家融合同日在 NVIDIA 与 AMD 两侧兑现,BS=1 吞吐 +14.98%

今天有一条很少见的对称证据:同一个优化思路(MoE 共享专家融合)在 08-20 同一天,分别在 NVIDIA 侧(vLLM #53040)和 AMD 侧(SGLang #32340)拿到两位数收益。当两家厂商、两个框架、两条内核栈给出形状一致的收益曲线时,基本可以确认收益来自消除固定开销这个结构性原因,而不是某一家内核的独门魔法。第二条主线是可观测性:vLLM #48915 把逐请求投机解码接受率写进了 OpenAI 兼容响应体。

★ 今日最值得关注

共享专家融合:vLLM #53040(NVIDIA)与 SGLang #32340(AMD)同日兑现。

先看 vLLM #53040 做了什么。DeepSeek V4 类 MoE 模型每层有两路专家:routed 专家(FP4) 和 共享专家(FP8,每个 token 必过)。融合前的执行序列是四次内核 launch:

  1. routed FP4 MegaMoE
  2. shared FP8 gate/up
  3. shared down
  4. add(残差相加)

这四次 launch 之间还要多次把中间结果写回 HBM 再读出来。融合后,SM100 persistent MegaMoE 内核统一调度:shared 的 L1 段、routed 的 dispatch + MMA、shared 的 L2 段、FP32 累加,全部在一个 persistent 内核里完成,最终只写一次 BF16 输出。

实测数字(B200/GB200,DSv4,128/256 输出):

指标融合前融合后变化
BS=1 输出吞吐130.02 tok/s149.50 tok/s+14.98%
BS=1 TPOT7.653 ms6.643 ms−13.19%
并发 64 吞吐——+9.44%
128 token 短输入 TTFT——+4.93%(变差)

怎么读这张表:decode 阶段的瓶颈是带宽与 launch 开销,不是算力。所以小 batch 收益最大——BS=1 的 TPOT 改善(−13.19%)明显大于并发 64 的吞吐改善(+9.44%),因为 batch 越大,launch 开销被摊得越薄,能省的份额自然越小。而 TTFT 反而 +4.93%,是因为极短 prefill 上 persistent 内核的启动成本摊不平——这是同一个机制的另一面,不是 bug。

AMD 侧 #32340 修的是两个 V3 时代遗留的假设(bf16 correction bias、top-6 非 2 的幂),在 MI355X / TP4 低并发上拿到输出吞吐 +8~11%,GSM8K 精度保持。收益曲线形状和 NVIDIA 侧一致。

给部署的直接影响:两条路都以 flag 提供、默认不开。

  • B200/GB200 跑 DSv4:加 --moe-backend deep_gemm_mega_moe 就能吃到两位数收益。
  • MI355X 跑 V3/V4:升级到含 #32340 的构建。 不开就白丢 10%+。 但也要注意 TTFT 回退那一条——如果你的负载是短输入、低输出、对首 token 延迟敏感,先压测再上。

一、AI 产业与论文热点

论文:ResNet(Deep Residual Learning for Image Recognition)

算子:DeepNorm(GLM 深层稳定训练)

性能优化:梯度检查点(Gradient Checkpointing / 激活重计算)

产业速递

二、vLLM & SGLang 社区跟踪

近 72 小时三方均无新版本 tag(vLLM v0.27.1 / SGLang v0.5.17)。

vLLM

SGLang

常驻专题:Step 适配(本期首次出现实质进展)

vLLM #53174(08-20T23:13 开,仍 open) 同时修 Step-3.5 MTP 启动崩溃与 reasoning parser,这是跟踪以来 Step 方向的第一个实质动作。更重要的是它首次给出了量化证据:

只修 MTP、不修 parser 时,Step-3.5-Flash-FP8 在 tool_choice: required 下 50 个请求只有 18 次(36%)返回合法 tool call,30 次是 no_tool_call_empty。

这个数字说明什么:Step 模型在 vLLM 上的问题不只是「启动崩溃」这种显性问题,还有「能跑但 64% 的请求不按格式返回」这种静默功能缺失。只盯着 MTP 草稿头的人会完全漏掉这半边。

耦合代价也首次被讲清楚:Transformers v5 要求 layer_types 长度等于 num_hidden_layers,而 Step-3.5-Flash 是 48 vs 45(多出 3 个 MTP 尾层);此前 #38247 为了过校验直接裁剪,导致 MTP 层索引 layer_types[num_hidden_layers+i] 启动即 IndexError。 #53174 改为「裁剪只在 super().__init__() 校验时生效,之后恢复 45+3」。

其余 Step PR 全 open(vLLM #52115 / #49490 / #40070 / #49642,SGLang #35206 / #32325)。StepFun-ai org 仅 Step-Realtime-CLI 08-20 有推送,Step-3.7-Flash 停 06-01、Step-3.5-Flash 停 04-03、官方 vllm fork 停 05-28,本窗口无新开源模型与官方部署指南更新。

方法论收获:模型定义向 transformers 靠拢求广度、数据面向自研靠拢求确定性,这个「分层非二选一」是对的——但分层接缝处(config 校验 / 词表 padding / 层类型表)正是故障高发地。Step 的崩溃不发生在任何一层的内部,就发生在缝上。

三、一句话结论

共享专家融合在同一天被 NVIDIA 与 AMD 两侧独立验证(BS=1 吞吐 +14.98% / TPOT −13.19%,MI355X +8~11%),收益曲线形状一致说明它来自固定 launch 与 HBM 往返开销的消除,是结构性而非偶然——B200/GB200 跑 DSv4 的今天就该加 --moe-backend deep_gemm_mega_moe;而 vLLM #48915 把逐请求接受率写进响应体,意味着投机解码终于从「全服务平均值玄学」进入「按流量分桶归因」的阶段,这两件事叠加,才是本周真正可执行的收益。


信息来源:vLLM v0.27.1 Release(2026-08-11);vLLM PR #53040 / #48915 / #52998 / #52466 / #51777 / #51362 / #53174 / #38247;SGLang PR #27770 / #33370 / #35496 / #32340 / #29525 / #35568;SGLang v0.5.17 Release(2026-08-08);GitHub commits API(vllm-project/vllm、sgl-project/sglang,since 2026-08-19T01:00:00Z);StepFun-ai org 仓库推送时间核对。

觉得有用?欢迎点赞、收藏,或请作者喝咖啡 ☕️

支付宝收款码

支付宝

微信收款码

微信

💬 留言

评论由 Giscus 驱动(基于 GitHub Discussions)。 当前仓库 NaphJohn/LLM-blog 尚未启用 Discussions:请在 GitHub 仓库 Settings → General → Features 勾选 Discussions 后刷新本页,评论区即自动显示。