一个叫“not much happened today”的更新日，真正有意思的地方，恰恰是没有大模型刷榜。
vLLM 0.20.0 把重点放在 KV cache、MoE Serving、量化和硬件适配上。它不负责让模型海报更好看，负责让模型在机房里少吃显存、少堵吞吐、少挑机器。
这才是推理时代的硬新闻。
发生了什么：三件事压缩看
| 事项 | 关键变化 | 该怎么读 |
|---|---|---|
| vLLM 0.20.0 | TurboQuant 2-bit KV cache 带来 4× KV capacity；fused RMSNorm 报告 2.1% 端到端延迟改善 | 利好长上下文和高并发，但不是所有模型一夜提速 |
| Poolside Laguna XS.2 | 33B total / 3B active MoE，Apache 2.0，单 GPU 可跑，表现接近 Qwen-3.5 的说法来自发布方与社区 | 开放 coder 开始卷“能部署”，不只是卷榜单 |
| NVIDIA Nemotron 3 Nano Omni | 30B / A3B 多模态 MoE，256K context，覆盖文本、图像、视频、音频、文档 | NVIDIA 继续把模型、硬件和分发入口绑在一起 |
vLLM 0.20.0 还补了不少硬件锚点：DeepSeek V4 MegaMoE on Blackwell、Jetson Thor、ROCm、Intel XPU、Grace-Blackwell。
SemiAnalysis 提到，在早期 DeepSeek V4 Pro Serving 工作负载里，B300 最高可到 H200 的 8×。这句话要拆开读：特定工作负载、早期结果、最高值。不能翻译成 B300 全面八倍于 H200。
更重要的是 Day-0 支持。
Poolside Laguna XS.2、Ling-2.6-flash、NVIDIA Nemotron 3 Nano Omni 刚出来，vLLM 以及 Ollama、OpenRouter、LM Studio、Unsloth、Fireworks、DeepInfra、Together、Baseten 等平台就跟上。模型发布不再只是把权重放出来，而是马上进入调用、测试、分发、收费链路。
对应用团队来说，这个变化很现实。以前看一个开放模型，先问“强不强”。现在还要问：有没有 vLLM 支持？有没有量化路径？能不能上现有 GPU？上线后吞吐会不会崩？
真变量：内存、MoE、量化和硬件迁移
我更在意的不是 vLLM 又多了几个功能，而是竞争指标变了。
过去大家盯参数、训练算力、benchmark。现在推理侧的关键问题更碎，也更要命：
| 变量 | 影响什么 | 现实约束 |
|---|---|---|
| KV cache | 长上下文、高并发、显存占用 | 2-bit KV cache 提高容量，但要看精度损失和具体负载 |
| MoE Serving | 专家调度、吞吐、延迟稳定性 | MoE 省计算，不等于调度免费 |
| 量化 | 显存、速度、部署门槛 | 动态量化灵活，静态量化可能更稳，但校准更麻烦 |
| 异构硬件 | 成本、供应链、迁移自由度 | CUDA 仍强，迁移不是改个配置文件 |
| Day-0 分发 | 模型从发布到可用的速度 | 平台接入快，不代表生产环境立刻稳 |
DeepGEMM MegaMoE 把 EP dispatch、EP combine、GEMMs、SwiGLU 往一个 mega-kernel 里融合。这个方向不性感，但很关键。推理成本常常不是死在一个大瓶颈上，而是死在一堆小开销里。
这有点像铁路早期的竞争。火车头当然重要，但货能不能便宜运到全国，最后还要看轨距、站场、调度和装卸效率。AI 现在也到了这个阶段：模型是火车头，推理栈是铁路网。
“天下熙熙，皆为利来。”落到今天，就是每家公司都在算同一笔账：同样一美元电费、同样一张卡、同样一段上下文，能多吐多少 token。
这也是 CUDA lock-in 松动的真正含义。
松动，不等于 NVIDIA 失势。DeepSeek 这类模型厂商会更想适配异构或本土加速器，TileKernels 这类路线也会更有吸引力。但 NVIDIA 没有站着挨打。Nemotron 3 Nano Omni 当天铺到多个平台，Blackwell、Grace-Blackwell 继续和 vLLM 深度绑定。
所以这不是“去 NVIDIA 化”的简单故事。更像是推理栈变成新的控制点：谁能让模型跑在更多硬件、更少显存、更低延迟里，谁就能把模型能力变成真实供给。
对谁影响最大：推理团队别只看版本号
最先受影响的是两类人。
一类是做推理部署的工程团队。vLLM 0.20.0 值得测，但不适合闭眼升级。该做的是拿自己的真实 workload 跑：上下文长度、并发、batch、MoE 路由、量化方案，都要单独看。
如果你服务的是长上下文、多轮对话、代码生成，TurboQuant 2-bit KV cache 的 4× KV capacity 很值得进测试队列。它可能直接影响显存预算和单机并发。
但 fused RMSNorm 的 2.1% 端到端延迟改善，只能当特定优化项看。它不是“全站性能提升 2.1%”的通用承诺。
另一类是小型 AI 应用团队和创业团队。Poolside Laguna XS.2 这种 33B total / 3B active、Apache 2.0、单 GPU 可跑的开放 coder，会让“先用开放模型搭一个可控版本”更有吸引力。
但这里也有边界。接近 Qwen-3.5，不等于全面超过 Qwen-3.5；单 GPU 可跑，也不等于生产环境便宜稳跑。真正该算的是延迟、并发、上下文长度、失败率，以及后续维护成本。
更具体一点：
| 角色 | 更现实的动作 | 不该做的事 |
|---|---|---|
| 推理平台团队 | 把 vLLM 0.20.0 放进灰度测试，重点测 KV cache、MoE、量化和异构硬件 | 只看发布说明就全量升级 |
| AI 应用创业团队 | 用 Laguna XS.2 这类模型做成本验证，比较闭源 API 与自部署账单 | 只看“单 GPU 可跑”就判断可商用 |
| 硬件采购团队 | 延后部分采购决策，等 B300、H200、ROCm、XPU 在自家 workload 里跑出数据 | 把“最高 8×”当成通用采购依据 |
接下来最该观察的不是谁又发了一个更大的模型，而是三个更硬的指标。
第一，2-bit KV cache 在真实长上下文任务里的质量损失是否可接受。容量上去，如果答案变差，账还是算不平。
第二，MoE Serving 在高并发下能不能稳。MoE 的纸面计算量很好看，但调度、通信和 kernel 融合才是落地门槛。
第三，异构硬件支持会不会从“能跑”变成“好跑”。能启动只是第一步，吞吐、稳定性、调试工具、生态文档，才决定团队敢不敢迁。
模型看着更强，产品反而可能更虚。模型没那么炫，但部署成本降下来，才会真的进入工作流。
这一天不热闹，但很实在。AI 基础设施的变化，往往不在舞台中央，而在显存账单、kernel 融合和硬件兼容表里。