每日AI热点 · 2026-09-01：SGLang 的 NVFP4 + FP8 lm_head 会把输出变成无限重复，且 v0.5.18 装不上修复

关于本期来源：今天只有 vLLM / SGLang 社区跟踪摘要，没有对应的 AI 论文与产业热点日报。因此本期只有推理基础设施部分，产业与论文一节从缺。

★ 今日最值得关注

SGLang 的 NVFP4 模型 + FP8 lm_head bug：输出无限重复，而修复你装不上。

这是本期唯一一条”会直接毁掉你线上输出”的问题，而且它的麻烦之处不在 bug 本身，而在修复的可达性。

三层事实：

症状：带 FP8 lm_head 的 NVFP4 检查点，在 SGLang 上会产出无限重复的输出。不是轻微退化，是明显到用户第一时间就能发现。
修复：主干 PR #35228 已修。
问题：v0.5.18 分支早于该修复，而 PyPI 上 sglang[all]==0.5.18 是钉死的——你无法通过任何正常的 pip 安装路径拿到带修复的版本。

可执行结论：如果你要跑 FP8-lm_head 的检查点，要么换 vLLM，要么从 main 构建 SGLang。没有第三条路。

值得单独说的一点：这类”修复在 main，但发布通道被钉死”的情况，比 bug 本身更值得警惕。它意味着你的依赖管理策略里必须有一条从 main 构建的应急路径——不是因为你想追新，而是因为你需要在修复和下一个 tag 之间有个逃生舱。

二、vLLM & SGLang 社区跟踪

本期无 AI 论文与产业热点来源（见开头说明），以下为推理基础设施部分。

版本状态：近 72h 无新版本。vLLM v0.28.0（8/26，584 commits / 270 贡献者）；SGLang v0.5.18（8/22，710 PRs）。

vLLM v0.28.0

新特性：

DCP + 融合 FlashKDA + GEMM-RS
共享专家分片，每卡省 ~17 GiB
自适应投机 token 预算，使 DSpark TTFT 改善约 60%

破坏性变更：

变更	PR	影响
bitsandbytes 迁出核心 → 外置插件	#43529	量化路径需单独安装
Transformers 升 5.15.0	—	自定义模型定义大概率要改
移除 `reasoning_content` 输出	—	依赖该字段的下游需要改解析

⚠️ 小显存用户升级前必读：请重读 release notes 里的 7 行 breaking 条目，并重测容量。这一版同时动了量化依赖（bitsandbytes 外置）和默认批大小（见下），两件事都会改变你的显存峰值。

默认值变更：max_num_batched_tokens 8192 → 16384。单卡 / 小显存配置可能 OOM。

SGLang v0.5.18

性能：

引擎启动提速 2.38×（详见原理部分）
Kimi K3 在 AMD MI355X 吞吐 1.37–1.77×
NVFP4 检查点经在线 MXFP4 重量化在 AMD 上跑出 97.5–100% 精度

已知坑（见 ★ 部分）：NVFP4 模型的 FP8 lm_head bug（输出无限重复）；main PR #35228 已修，但 v0.5.18 分支早于修复、且 PyPI 上 sglang[all]==0.5.18 钉死无法安装 → 跑 FP8-lm_head 检查点请用 vLLM，或从 main 构建。

原理：vLLM 0.28 的分层 KV 缓存下沉磁盘

本期最值得理解的一条技术解读。

路径：GPU → CPU RAM → 本地盘。

这个改动的意义远不止”多了一层存储”。它意味着：

推理引擎正在从「管理显存的运行时」，变成「跨计算 / 显存 / 主存 / 磁盘调度模型状态的运行时」。

带来的直接好处：长上下文 Agent 负载不再需要为每个冷会话永久占用最贵的显存。一个挂在那儿半小时没动静的 Agent 会话，它的 KV 可以安静地躺在磁盘上，把 HBM 让给真正在跑的请求。

代价同样明确：冷恢复要付 I/O 尾延迟。以前从 HBM 直接读，现在可能要等一次磁盘回拷。这个延迟不影响稳态吞吐，但它会落在 P99 上——而 P99 恰恰是交互体验最敏感的地方。

运维指标必须同步扩展。以前你只看”KV cache 利用率”就够了，现在至少要加三个：

各层命中率（GPU / CPU / 磁盘分别命中多少）
层间迁移字节数（有多少数据在层之间搬来搬去）
恢复延迟分布（从磁盘捞回一次冷 KV 要多久）

我的判断：这条路线是对的，但它把推理引擎的复杂度推到了一个全新的量级——它开始像一个操作系统了。分层、换入换出、命中率、尾延迟，这些词以前属于存储系统，现在属于推理引擎。团队里如果还没有人专门盯这些指标，现在是时候指定一个了。

常驻专题

PD 分离：vLLM Model Runner V2 推进 E/P/D 分离 + 分层 KV 到磁盘；SGLang 侧为 DCP 解码上下文并行 / FlashInfer all-to-all 路由 MoE / DeepSeek-V4 FlashMLA 稀疏预填充默认开。

架构演进：投机解码三路线（EAGLE / MTP / 自适应预算，vLLM 的自适应预算使 DSpark TTFT 改善约 60%）、稀疏 MLA、FP8/INT4/KV 量化、多模态。

纯 PyTorch vs transformers：本周期无”脱离 transformers 自研栈”的新 PR，但 vLLM 把 Transformers 升 5.15.0 + bitsandbytes 外置，是明确的依赖解耦信号。趋势是最小化硬依赖、便于自定义算子。

Step 适配：

Step-3.7-Flash 的开源权重已在 Mac Studio M4Max / DGX Spark / AMD AI Max+395 上完成本地部署验证。→ 端侧与工作站侧的可达性已经打开。
Step-Audio 2.5 用 MTP 把 ASR 模式的 RTF 干到 0.0053——1 小时音频 → 19 秒。
具体 vLLM / SGLang 部署以 StepFun 官方仓库为准。

Step-Audio 那条值得注意：RTF 0.0053 意味着实时率的 189 倍。ASR 这类流式任务能吃到 MTP 的红利，说明投机解码的适用面正在从”文本生成”外溢到更广的自回归场景。1 小时音频 19 秒处理完，已经不是一个”加速”的量级，而是改变了这类任务能不能放进在线流水线。

三、一句话结论

没有新版本的日子里，最有价值的两条信息分属一正一反：正的是 vLLM 0.28 把 KV 下沉到磁盘，让推理引擎第一次像操作系统那样分层调度状态；反的是 SGLang v0.5.18 的 NVFP4 + FP8 lm_head 会让输出无限重复，而修复被钉死在发布通道之外——请现在就确认你的依赖管理里有一条从 main 构建的逃生路径。

📬 想持续收到这类每日追踪？留邮箱 / 加我列表就好 👉 1023628035@qq.com