你要是自己拿 vLLM 跑过多卡推理服务，大概率见过这个场面：空载的时候一切顺滑，TTFT 几十毫秒，token 一个接一个吐得稳稳的。并发一上来，一条长提示词混进一堆正在流式输出的请求里，所有回复集体"卡顿"一下，像被人按了暂停键。于是你开始调参数：加 max-num-seqs、调 max-num-batched-tokens、开 Chunked Prefill。调一调确实好点，但你永远调不到"一直好"——因为 chunk 该切多大，高度依赖流量分布，流量一变就得重调。
这不是你的配置问题，是一个进程同时干三件性质完全不同的活：Prefill 要算力、Decode 要显存带宽、模板渲染和解析要 CPU 核。硬塞在一起，它们天然互相抢。
9 月 29 日，vLLM 官方博客发了一篇《Taking vLLM Apart》，中文实用指南这几天传遍了知乎。B 站上也已经有人把四张 5060Ti 的机器从 0.28 升到 0.30.0，发了升级实测。这一波更新的核心不是"某个核又快了几个百分点"，而是 vLLM 官方开始帮你把这个进程拆开。我把官方博客的测试、知乎的源码导读和消费卡实测评测拼到一起，发现这笔账对不同的人完全不同——分三本算。知乎哔哩哔哩
第一本账：分离省的是 p99，不是平均——这是最容易读反的一条
官博里那组对比测试的条件要记清楚，因为后面的结论全绑在这些前提上：两台 NVIDIA L40S（48GB、PCIe、无 NVLink），模型 Qwen2.5-7B-Instruct，约 8k token 输入、256 token 输出，100 条泊松到达请求。聚合模式是 `vllm serve --data-parallel-size 2`（两张卡各跑一个副本）；P/D 模式是一台 Prefiller 加一台 Decoder，中间走 NIXL。同样的两张卡。知乎
结果最容易骗人的地方在这：0.4–0.6 req/s 这个负载区间里，两种架构的中位数延迟几乎一样，都是 21–24ms。但聚合模式的 p99，是分离式的约 6 倍。知乎
也就是说，那 1% 最倒霉的请求，正好撞上了一条长 prompt 的 Prefill，整台机器上所有 Decode 流都得停下来等它。你的监控面板上平均延迟岁月静好，用户那边已经在骂"有时候卡一下"。
这能解释这半年社区里各种"调不动"的症状：这周知乎上就有人在问"vllm 为什么没在 prefill 阶段支持 cuda graph"——和 Chunked Prefill 见缝插针一样，都是聚合架构里调度器在抢 GPU 的不同侧面。分离式服务的答案粗暴一些：让抢 GPU 的两种活根本不在同一台实例上。知乎
一句话版本：如果你的痛点是"平均吞吐不够"，P/D 分离帮不了你；如果你的痛点是"尾延迟随负载上升开始破 SLO"，这是它最核心、目前不可替代的价值。
第二本账：每 10k token 收 65ms 的税——没有快网络的人，先别急着拆
拆开的代价藏在"接力棒"里。P/D 之间传的是 KV Cache：以 BF16 精度的 Llama-3.1-70B 为例，每个 token 要存 320 KiB，一条 10k token 的 prompt，KV Cache 就有约 3GB。400 Gb/s 的网络线速下，光传输就要约 65 毫秒——这还没算协议和拷贝开销，而这笔时间全部算在用户感知的 TTFT 头上。知乎
更隐蔽的是完成通知机制：Decode 不会在传完的瞬间被打断，它只能在自己的前向步骤间隙轮询，才能发现传输已经完成。知乎
所以 Goodput 提升的那些漂亮数字，官方给的前提是 KV 传输走 RDMA（InfiniBand 或 RoCE）或者单机内 NVLink / GPU P2P。传输一慢，收益就被税吃掉。知乎
拿这个前提对一下国内玩家最常见的两种机器：
数据中心 8 卡机、有 NVLink 或 RDMA：税基本感知不到，第一本账的收益能拿到。
消费卡拼的多卡机（四张 5060Ti、双 4090 这类）：卡间走 PCIe，65ms 的账要按实际链路重算。B 站那位四张 5060Ti 的机主 9 月 29 日发了结论，0.28 升级到 0.30 性能提升了一些，推荐升级。注意，这是原地升级的收益，不是 P/D 分离的收益，别把两本账混成一本。PCIe 机器上跑分离，很可能 TTFT 先恶化。哔哩哔哩
这个税太显眼，以至于这个月的生态几乎都在拆同一颗雷。NVIDIA 在 2026 年 4 月开源的 Dynamo，做的就是推理引擎之上的编排层：多节点部署时的请求路由、KV 缓存复用、prefill/decode 分离、自动扩缩容，这些问题没有一个引擎能独立解决。知乎
SGLang 的 HiCache 则把前缀缓存从 GPU 空闲显存扩成了三级缓存，L3 后端里就包括 Mooncake 和 NIXL。知乎
无问芯穹在 2026 WAIC 上公布的 PDD 架构，把传统 PD 分离链路解构成"P-RLD-MD"三级，用广域以太网"中继接力"传 KV，实测首 Token 延迟降低 51.5%、单 Token 成本降低 37.5%。知乎
10 月 3 日刚出的文章讲的是 vLLM-Ascend 配 Mooncake 把 KV Cache 池化进 DDR，用同步加载、异步加载、Layerwise 逐层读写三种执行安排，把传输藏到计算后面。知乎
vLLM 0.30 回答的是"活怎么分工"，这帮邻居回答的都是"棒子怎么传得快"。你在选型时看到的每个"提速 X%"，先问它把棒子走的是哪条线。
第三本账：无 GPU 前端——被搬走的不是算力，是你最贵的 GPU 时间
0.30 容易被忽略的另一刀：新增 render/derender 接口后，GPU 引擎可以只做 token 进、token 出，聊天模板、工具调用解析这些 CPU 杂活整个挪到纯 CPU 层，独立扩缩容。
官方给的测量很直白：对 Qwen2.5-7B 渲染一条 9k token 的聊天 prompt，只要约 15ms CPU 时间；单个 render 服务默认配置能跑到 73 req/s，只占一个核出头。反过来看聚合模式下 p99 崩掉的那个 0.4 req/s 负载——render 层占用不到一个核的 1%。这层几乎不会成为瓶颈，而且它便宜：CPU 实例的价格你清楚，GPU 机器的核时价格你也清楚。知乎
知乎上岳京杭的 v0.29 源码导读笔记（0.30 同一条演进线）给了佐证：代码里 `entrypoints/scale_out/` 已经放着 render/derender/token_in_token_out 的跨实例路由，`renderers/` 目录下 OnlineRenderer/OnlineDerenderer 已经落地。这不是 PPT 功能，是已经进了主干的工程件。知乎
拆之前，两个坑和一个顺手优化
坑一：vLLM 仓库 `tests/` 下的 toy proxy 只适合开发验证，生产要用 llm-d 或 Dynamo。自己拿 toy proxy 顶生产，等于把"多了一个要监控的进程"这个复杂度白付了。知乎
坑二：多轮对话开 `bidirectional_kv_xfer`（Proxy 靠 conversation_id 追踪会话 KV 块，让 Prefill 只算新增 token）很香，但对推理模型有个静默雷：Decode 的 KV 块里包含它生成的思考链，而下一轮 prompt 如果把思考链去掉了——Qwen3 的 chat template 就会自动这么做——Prefill 的 prompt 和 Decode 手里的 KV 块就对不上了。目前 vLLM 不会自动检测这种不匹配，开双向传输之前，先把你的 chat template 检查一遍。知乎
顺手优化：走 /v1/chat/completions 时，Prefill 已经分过词，可以在 Prefill 请求里带上 `return_token_ids`，把 token ID 通过 kv_transfer_params 直接传给 Decode，省掉 Decode 再分一遍词。<#&!53#&!>知乎
这笔账按四类人分开
自托管规模化服务、有 RDMA 或 NVLink、SLO 盯 p99 的：这轮值得升，值得试 P/D。TTFT 是你们的观测重点，别只看吞吐。
多轮对话类产品：你们的第一价值点是 bidirectional_kv_xfer，动手前先核对 chat template 会不会丢思考链。
消费卡多卡玩家（PCIe 互联）：原地升 0.30 吃工程优化收益就好，分离式先别碰，65ms 的税是真金白银。
低流量、突发性、延迟不敏感的：聚合模式依然简单可靠。拆架构的运维复杂度是一笔持续付的成本，vLLM 官方自己都说了这不是银弹。
下一步盯什么
0.30.x 各 KV Connector 的默认稳定状态、社区有没有把"模板丢思考链"做成自动检测、llm-d 和 Dynamo 的生产案例落地情况。这三个信号出来之前，P/D 分离在国内的普及水位，大概率就停在这周的讨论热度上。
一句话收口：vLLM 0.30 不会让你的平均延迟变快，它做的是把藏在尾部的卡顿变成一条可以用钱和网络解决的路径——前提是你的网络配得上它，而你的负载值得为它多维护一组进程。
