vLLM 团队 8 月 6 日发了一篇博客：在 Qwen3.5 上把总吞吐做到单 GPU 约 25K TPS。这个数字背后，是一次对「混合架构」的服务化攻坚。
全注意力加 GDN 为什么让服务化变难？
Qwen3.5 不是纯 Transformer，而是把全注意力层与 Gated Delta Network（GDN）层叠在一起。GDN 属于线性/SSM 一路的高效结构，状态表示与注意力的 KV cache 完全不同。这带来两个工程难题：怎么在 Blackwell GPU 上把 GDN 算快，以及怎么在 prefill 与 decode worker 之间正确搬运这种异构状态。
25K TPS/GPU 这个数字是怎么挤出来的？
vLLM 的做法分两路：在算力侧针对 Blackwell 对 GDN 算子做专门加速；在通信侧扩展 NIXL 分离服务路线，让注意力 KV 与 GDN 状态都能跨 worker 传递。博客特别提到，SSM 支持 P/D 分离是社区沿着 NIXL 路线推出来的——这说明开源推理栈对新架构的适配速度，已经快到能跟上新模型发布节奏。
这对要上 Qwen3.5 的部署者意味着什么？
如果你要上 Qwen3.5 这类混合架构模型，别拿纯 Transformer 的经验直接套：prefix caching 的行为、P/D 分离的可用性、甚至默认参数都可能不同。上线前按官方部署提示逐项核对，尤其关注混合缓存开关。
混合架构给部署者提了什么醒？
25K TPS/GPU 证明了混合架构既能省显存、又能在新硬件上跑出高吞吐。未来模型不会再是清一色注意力，推理栈必须学会同时伺候两种状态。
部署 Qwen3.5 时要避开哪些坑？
混合架构模型的部署，经验不能直接从纯 Transformer 平移过来。第一，先确认你用的 vLLM 版本已经合入 GDN 加速算子，老版本会把 GDN 层退化成低效参考实现，25K TPS 想都别想。第二，P/D 分离对异构状态的搬运有额外开销，小规模部署可以先不拆，单机跑稳再上分离。第三，prefix caching 与混合缓存的交互要实测，别默认开。建议拿自己的真实请求分布做一遍吞吐与延迟压测，再决定并行度与量化档位。把这些坑踩在上线前，比事后回滚省心得多。
还值得一提的是，这次 25K TPS 是在 Blackwell 上跑出来的，换老一代硬件，GDN 加速算子未必齐备，数字会明显打折。选型时把硬件代际也算进账里，别拿新卡的标称吞吐去规划旧集群的容量。