本周精读：Taking vLLM Apart: A Practical Guide to Disaggregated Serving。
作者：Martin Hickey（IBM Research）；发布平台：vLLM 官方博客；发布日期：2026-09-29；本期导读日期：2026-10-10。文章在近 30 天窗口内，原文已完整阅读；以下是原创导读，文中实验均为作者报告，本期未自行复测。
核心观点与证据
作者讨论两种拆分：GPU 上的 prefill/decode 分离，以及 CPU 前后处理与推理引擎分离。目标是满足延迟约束的有效吞吐量（goodput）；KV 搬运与额外服务会增加成本。详见原文架构与权衡部分。
最值得精读的是作者自己的反例实验：同一台机器、两张 48GB L40S，无 NVLink、GPU 间 P2P 不可用；模型 Qwen2.5-7B-Instruct，约 8k 输入、256 输出，关闭前缀缓存，每档 100 个泊松到达请求。共置基线使用 DP=2，拆分方案使用一个 prefill、一个 decode 和 NIXL。0.4 req/s 时，共置 p99 ITL 为 169ms，拆分为 29ms；但在 0.2 req/s 时，拆分的中位 TTFT 为 2.2s，共置为 0.7s。作者同时指出共置基线并非最强。条件与数字见原文实验。
文章也把双向 KV 复用、流式解析和配置一致性纳入讨论：性能之外，缓存与实际 token 序列是否一致也关系到正确性。见多轮会话部分。
为什么值得你关注
我的判断：这篇文章同时贴合你关注的推理架构、服务系统和性能分析。最有价值的阅读动作，是逐项追问“改善了哪个指标、代价落在哪条路径、对照是否公平”，而不是记住拆分后的服务数量。
可以先读实验与权衡，再沿请求路径检查缓存交接和结果解析。把它当作架构评审材料：每增加一个边界，写清状态归属、超时处理、失败后的恢复方式，以及可观测的延迟分量。这样的阅读收获能迁移到其他有状态计算服务。
阅读前置知识
- Prefill 与 decode：前者处理输入上下文，后者逐步生成；二者共享资源时，调度可能影响输出节奏。
- KV cache：保存注意力的中间状态以复用；理解它为何随上下文增长，才能估计搬运与存储代价。
- TTFT、ITL、p99 与 goodput：分别关注首 token、输出间隔、尾部体验及满足约束的负载。读实验时务必分清约束施加在单个 token 还是请求平均值上。
- 数据并行与互联拓扑：副本如何分配请求、GPU 如何传输数据，会改变同硬件比较的含义。
读完最该带走的 3 个结论
- 用完整的服务约束判断架构收益。 我的工程建议是先写出首 token 和输出节奏的验收线；一项改善不能代替另一项达标。适用于对交互延迟有要求的服务。
- 把状态搬运纳入关键路径预算。 根据本文反例，我会在扩容前分别测排队、计算、传输和接收等待，再决定是否拆分。显存容量与链路标称带宽不足以预测端到端结果。
- 用相同语义、相同硬件和真实负载比较。 我的评审要求是同时检查模板、缓存、解析结果和对照配置；单轮随机输入实验只回答特定问题，多轮与工具调用仍需单独验证。