# 📊 文章摘要：Splitwise: Efficient Generative LLM Inference Using Phase Splitting > **原文**：[2023-11-30_Splitwise.md](./2023-11-30_Splitwise.md) > **原文链接**：https://arxiv.org/abs/2311.18677 > **来源**：arXiv > **作者**：Pratyush Patel, Esha Choukse, Chaojie Zhang, Aashaka Shah, Íñigo Goiri, Saeed Maleki, Ricardo Bianchini（华盛顿大学、微软） > **发布日期**：2023-11-30 > **摘要日期**：2026-08-06 > **价值评级**：⭐⭐⭐ 高 --- ## 核心命题 > **相位拆分** — LLM 推理的两阶段（计算密集的 prompt 处理、内存密集的 token 生成）对硬件的需求截然不同，把它们拆分到各自合适的机器（含异构、降配硬件），是突破"GPU 算力与内存带宽增长失衡"约束的成本与功耗优化路径。 --- ## 文章概要 本文用生产 trace 对 A100/H100 上的 LLM 推理做表征分析，发现同一请求的两个阶段特性对立：prompt 计算阶段吃算力（FLOPs），token 生成阶段受内存带宽与容量约束、即使最优批处理也浪费算力。由此提出 Splitwise：把两阶段拆分到不同机器，用层级异步传输把 KV cache 的迁移开销与 prompt 计算重叠（小 prompt 走串行传输），并利用生产 trace + 事件驱动模拟器探索同构/异构集群设计（AA、HH、HA、HHcap 四类）。相比现有集群，Splitwise 可在成本降低 20% 的同时提升 1.4× 吞吐，或在同等成本与功耗预算下提供 2.35× 吞吐。局限：KV cache 传输是固有开销、依赖数据中心高速互连（InfiniBand/NVLink），集中式调度器在超大集群下可能成为扩展性瓶颈。 --- ## 关键要点 1. **硬件失衡是动因** — H100 相对 A100 算力提升 3.43×、功耗提升 1.75×，但内存带宽仅增长 1.6×、容量零增长；最新 GPU 的算力优势在内存密集的 token 生成阶段被浪费。`[分类: 共识]` 2. **两阶段资源画像对立** — prompt 阶段计算密集、受 FLOPs 约束；token 生成阶段内存带宽/容量受限，即使 state-of-the-art 批处理也显著低效利用算力，可降配硬件运行。`[分类: 范式突破]` 3. **拆分而非解耦竞争** — 与 DistServe 同期提出阶段拆分思路，但出发点不同：DistServe 追求 goodput/SLO，Splitwise 强调异构硬件选型与成本/功耗优化（Perf/$ 与 Perf/W）。`[分类: 共识]` 4. **KV cache 传输的工程化优化** — 逐层异步传输与 prompt 计算重叠，使 E2E 延迟影响仅 0.8%（串行传输为 3%）；第二 token 延迟增加 16.5%（串行方案 64%），用户几乎无感知；传输总开销 <7% 的 prompt 计算时间。`[分类: 范式突破]` 5. **异构集群设计矩阵** — 四种设计：AA（A100 全同构）、HH（H100 全同构）、HA（H100 跑 prompt + A100 跑 token，token 阶段 A100 更划算）、HHcap（H100 双池但 token 机功耗上限 70%、单 GPU 限 50% 功耗——token 阶段对功耗限制不敏感）。`[分类: 范式突破]` 6. **量化收益** — 同等功耗预算下：40 台 H100 baseline 被 55 prompt + 15 token 的 Splitwise-AA 方案超越；相比现有集群吞吐提升 1.4× 且成本降 20%，同成本同功耗下吞吐可达 2.35×。`[分类: 共识]` 7. **模拟驱动的集群供给** — 事件驱动模拟器 + 分段线性性能模型（MAPE < 3%，与真实硬件实验交叉验证，端到端 5 万+ 迭代验证），在 TTFT/TBT/E2E 九个 SLO 约束下搜索异构机群配比（如 70 RPS 目标的成本最优配置为 27 prompt + 3 token 机器）。`[分类: 未探索]` 8. **可靠性以重启为代价** — 节点故障时从头重启请求；论文提出可将 KV cache 检查点化到内存数据库以跳过 prompt 重算，但安全高效的故障恢复留作未来工作。`[分类: 未探索]` --- ## 批判性分析 ### 假设前提 - GPU 集群存在（或未来将出现）供异构部署的多种机型，且异构机型间的价格/功耗/可用性差异足以驱动拆分决策。 - 数据中心普遍具备高速后端互连（InfiniBand 等），KV cache 跨机传输可被有效隐藏。 - token 生成阶段使用上一代或降配硬件不影响 SLO 达标（对交互式负载尤其依赖此假设）。 - 生产请求的 prompt/token 长度分布可表征，且集群按峰值负载供给（论文只考虑供给功耗而非动态功耗）。 ### 论据与逻辑 - 论据扎实：表征数据来自真实硬件（Azure 上的 DGX-A100/H100）+ 生产 trace；KV cache 传输开销有端到端实测（0.8% E2E、16.5% 第二 token）；模拟器性能模型 MAPE <3% 且经 5 万+ 迭代端到端验证，结论的量化支撑较强。 - 逻辑链条完整：硬件失衡观测 → 阶段资源画像差异 → 拆分设计 → 传输优化 → 异构供给搜索 → 收益量化。 - 弱点：1.4×/2.35× 等收益来自模拟器而非全系统真实部署；"第二 token 延迟"这类交互体验指标的受众感知评估主观；对大规模集群下集中式调度器（CLS）瓶颈仅以"正交于 Splitwise"带过，未量化。 ### 边界与局限 - 结论适用于两阶段分离收益大于传输开销的场景：batch 处理类任务（摘要等）收益最大，交互式任务受第二 token 延迟影响。 - 前提是高速互连数据中心；无 InfiniBand/NVLink 级带宽的环境下拆分收益会显著缩水。 - 未来若 GPU 缓存技术（如长上下文缓存避免重算）改变 prompt 阶段的内存画像，表征结论可能失效（论文自身也承认此点）。 - 容错、调度器扩展性、动态功耗等生产关键问题未解决。 --- ## 可引用金句 > "Unlike prompt computation, token generation does not need the compute capability of the latest GPUs and can be run with lower power and cost." > （与 prompt 计算不同，token 生成并不需要最新 GPU 的计算能力，可以用更低的功耗与成本运行。） > "Running both phases on the same machine often leads to inconsistent end-to-end latencies due to the arbitrary batching of prompt and token phases." > （在同一台机器上运行两个阶段，常因 prompt 与 token 阶段的随意混合批处理而导致端到端延迟不稳定。） --- ## 总体评价 **亮点**： - 系统化表征了 LLM 推理两阶段的硬件资源画像差异，数据一手且翔实（A100/H100 实测） - "异构降配 + 功耗上限"的集群设计思路（HA、HHcap）直接把成本/功耗优化落到集群拓扑层面，工程可操作性强 - KV cache 逐层异步传输的工程方案精炼，与 Mooncake 的逐层 prefill 形成呼应 - 模拟器 + 性能模型方法论严谨（MAPE <3%），可复用于集群供给规划 **不足**： - 收益数字主要来自模拟器评估，缺大规模真实部署验证 - 对调度器扩展性、容错等生产约束讨论偏简略 - 未考虑动态功耗、缓存普及对未来硬件画像的影响 **适用场景**：云厂商推理集群规划者、追求成本/功耗优化的 serving 基础设施团队；研究异构调度与数据中心级 LLM 部署的研究人员。 **关联建议**：与 DistServe（goodput 视角的阶段解耦）、TetriInfer（混合负载干扰）、Mooncake（生产系统 KVCache 中心化）对照，可形成"解耦 serving"的完整谱系；后续可关注微软相关后续工作与 vLLM 解耦功能的演进。 --- ## 配图 ![-](../../金鹏/20260806/20260806-006.png)