文档(金鹏): 2026-08-06 章节 48 篇文章摘要归档
- 46 篇原文+摘要双文件归档（按 来源/作者 分层，复用本地归档 20 篇+新抓取 26 篇） - 即梦生成 9 组主题配图（大图+列表缩略图）存入 知识/金鹏/20260806/ - 章节重组为 9 个主题分组并挂接摘要引用
This commit is contained in:
@@ -0,0 +1,224 @@
|
||||
# pd分离在vllm中用法
|
||||
|
||||
> **来源**：CSDN 博客（博主：小徐炸酱面）
|
||||
> **作者**：小徐炸酱面（qq_44319972）
|
||||
> **发布日期**：2025-12-01（2025-12-02 修改）
|
||||
> **原文链接**：https://blog.csdn.net/qq_44319972/article/details/155456852
|
||||
|
||||
---
|
||||
|
||||
### 1. 背景：为什么需要 PD 分离
|
||||
|
||||
大模型在线服务一般包含两种阶段：
|
||||
|
||||
- **Prefill 阶段**
|
||||
- 输入：完整的 prompt
|
||||
- 动作：一次性跑完所有输入 token 的前向，构建 KV Cache
|
||||
- 特点：
|
||||
- **计算密集**（GEMM-heavy，吃算力）
|
||||
- 对显存需求大（一次性占用大量 KV）
|
||||
- 对带宽要求相对没那么极端（一次性大算子）
|
||||
- **Decode 阶段**
|
||||
- 输入：每轮只处理很少的新 token（一般 1～几 token）
|
||||
- 动作：基于已有 KV Cache 不断迭代生成新 token
|
||||
- 特点：
|
||||
- 单步计算量相对小
|
||||
- 访问 KV Cache 频繁，**更吃显存带宽 / 内存带宽 / 通信带宽**
|
||||
- 很多小 kernel，调度频率高
|
||||
|
||||
**PD 分离（Producer / Decoder Separation）** 的目标就是：
|
||||
|
||||
- 把 prefill 和 decode 拆到**不同的进程 / 节点 / 设备**上
|
||||
- 利用不同节点的算力/带宽特性，整体提升吞吐、降低延迟
|
||||
|
||||
### 2. PD 分离的基本概念与架构
|
||||
|
||||
#### 2.1 角色定义
|
||||
|
||||
- **P 节点（Producer）**
|
||||
- 负责：prefill 阶段
|
||||
- 对应操作：
|
||||
- 处理新请求的 prompt
|
||||
- 运行大批量 GEMM
|
||||
- 把得到的 KV Cache 写入某种共享介质（或通过 KV 通道发送给 D 节点）
|
||||
- 资源特征：
|
||||
- 更看重：**算力、GPU FLOPs**
|
||||
- 对长尾小请求和频繁通信不是特别敏感
|
||||
- **D 节点（customer）**
|
||||
- 负责：decode 阶段
|
||||
- 对应操作：
|
||||
- 不断从 KV 中取数据
|
||||
- 迭代生成每个 request 的后续 token
|
||||
- 资源特征：
|
||||
- 更看重：**显存带宽 / 网络带宽 / 延迟**
|
||||
- 关注 tail latency（TPOT、e2e）
|
||||
|
||||
#### 2.2 KV Cache 的流转
|
||||
|
||||
PD 分离的**核心**就是：**prefill 生成的 KV，如何让 decode 能够用起来**。
|
||||
|
||||
一般数据流可以抽象成：
|
||||
|
||||
1. 请求进来，P 节点接收并执行 prefill
|
||||
2. P 节点为该 request 分配 KV Block（或 Block 列表）
|
||||
3. P 节点把 KV 的位置信息 + request 的 metadata 通过某种 **KV Connector / RPC 通道** 告诉 D 节点
|
||||
4. D 节点接管该 request 的 decode：
|
||||
- 知道对应 KV 在哪里
|
||||
- 在后续 decode 中，始终通过 KV Connector 访问这些 KV
|
||||
|
||||
典型注意事项：
|
||||
|
||||
- 如果有 DP/TP，P/D 侧的并行策略也要匹配（否则会出现 KV 维度不一致、block id 对不上等问题）
|
||||
- 如果跨机器，需要额外考虑网络带宽、RDMA、压缩等问题
|
||||
|
||||
### 3. vLLM 中的 PD 分离思路（概念层面）
|
||||
|
||||
> 这里以 "vLLM + 自研 PD 功能" 的思路来整理，只写通用逻辑，不绑死具体实现细节。
|
||||
|
||||
#### 3.1 与调度器（scheduler）的关系
|
||||
|
||||
vLLM 的 serving 里，有一个统一的 scheduler 管理：
|
||||
|
||||
- 新请求的进入（prefill 阶段）
|
||||
- 已有请求的继续 decode
|
||||
- 每一轮 step，要算多少 token（`num_scheduled_tokens`）
|
||||
- 每个 request 一共已经算了多少 token（`num_computed_tokens`）
|
||||
|
||||
PD 分离后，逻辑可以拆解为：
|
||||
|
||||
1. **Producer 侧 scheduler**：只负责 prefill
|
||||
2. **Decoder 侧 scheduler**：只负责 decode
|
||||
3. 通过某种方式保证两边对 request 状态的约定一致，例如：
|
||||
- request id
|
||||
- 已生成 token 数
|
||||
- KV block id 列表
|
||||
- 当前是否已经结束（EOS / abort）
|
||||
|
||||
### 4. 在 vLLM 中使用 PD 分离的典型启动方式（示意）
|
||||
|
||||
> 下面用伪代码/伪命令展示结构，变量名你可以换成你们环境里的 `VLLM_USE_V1` / `vllm_PD_ROLE` / `kv_transfer_config` 等。
|
||||
|
||||
#### 4.1 不分离时（baseline）
|
||||
|
||||
```
|
||||
# 单机单进程示意
|
||||
python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model /data/models/Qwen3-32B \
|
||||
--tensor-parallel-size 2 \
|
||||
--dtype bfloat16 \
|
||||
--max-model-len 32768 \
|
||||
--port 8000 \
|
||||
--host 0.0.0.0
|
||||
```
|
||||
|
||||
Benchmark 示意：
|
||||
|
||||
```
|
||||
python3 benchmarks/benchmark_serving.py \
|
||||
--backend openai-chat \
|
||||
--base-url http://<host>:8000 \
|
||||
--endpoint /v1/chat/completions \
|
||||
--model Qwen3-32B \
|
||||
--tokenizer /data/models/Qwen3-32B \
|
||||
--dataset-name random \
|
||||
--random-input-len 2000 \
|
||||
--random-output-len 200 \
|
||||
--request-rate 5 \
|
||||
--num-prompts 100 \
|
||||
--percentile-metrics ttft,tpot,e2el
|
||||
```
|
||||
|
||||
#### 4.2 1P1D（单机或双机）
|
||||
|
||||
**4.2.1 Producer 节点**
|
||||
|
||||
```
|
||||
export VLLM_USE_V1=1
|
||||
export vllm_PD_ROLE=producer
|
||||
|
||||
python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model /data/models/Qwen3-32B \
|
||||
--tensor-parallel-size 2 \
|
||||
--max-model-len 32768 \
|
||||
--max-num-batched-tokens 8192 \
|
||||
--max-num-seqs 32 \
|
||||
--port 8209 \
|
||||
--host 0.0.0.0 \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"P2pNcclConnector",
|
||||
"kv_role":"kv_producer",
|
||||
"kv_rank":0,
|
||||
"kv_parallel_size":2,
|
||||
"kv_buffer_size":1,
|
||||
"kv_port":9109,
|
||||
"kv_connector_extra_config":{
|
||||
"proxy_ip":"0.0.0.0",
|
||||
"proxy_port":30001,
|
||||
"http_port":8109
|
||||
}}' \
|
||||
&> Qwen3-32B-producer.log &
|
||||
```
|
||||
|
||||
**4.2.2 Decoder 节点（D，kv_consumer）**
|
||||
|
||||
> ⚠️ 原文此处的代码块与 Producer 节点完全相同（`vllm_PD_ROLE=producer`、`kv_role:"kv_producer"`），疑为作者复制粘贴遗漏修改。按原文忠实保留如下，实际部署时 Decoder 侧应改为 `vllm_PD_ROLE=decoder` / `kv_role:"kv_consumer"`、`kv_rank` 相应调整。
|
||||
|
||||
```
|
||||
export VLLM_USE_V1=1
|
||||
export vllm_PD_ROLE=producer
|
||||
|
||||
python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model /data/models/Qwen3-32B \
|
||||
--tensor-parallel-size 2 \
|
||||
--max-model-len 32768 \
|
||||
--max-num-batched-tokens 8192 \
|
||||
--max-num-seqs 32 \
|
||||
--port 8209 \
|
||||
--host 0.0.0.0 \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"P2pNcclConnector",
|
||||
"kv_role":"kv_producer",
|
||||
"kv_rank":0,
|
||||
"kv_parallel_size":2,
|
||||
"kv_buffer_size":1,
|
||||
"kv_port":9109,
|
||||
"kv_connector_extra_config":{
|
||||
"proxy_ip":"0.0.0.0",
|
||||
"proxy_port":30001,
|
||||
"http_port":8109
|
||||
}}' \
|
||||
&> Qwen3-32B-producer.log &
|
||||
```
|
||||
|
||||
**`kv-transfer-config` 参数解释：**
|
||||
|
||||
- **`kv_connector`**：用什么通道传 KV。现在用：`P2pNcclConnector`，表示走 NCCL P2P 通信。
|
||||
- **`kv_role`**：这个进程是**发 KV 的**还是**收 KV 的**。
|
||||
- P：`"kv_producer"`
|
||||
- D：`"kv_consumer"`
|
||||
- **`kv_rank`**：在这组通道里的编号，从 0 开始。多个并行通道时，用它来区分是谁↔谁。
|
||||
- **`kv_parallel_size`**：一共有几路 KV 通道（也可以理解为这组里有多少 rank）。一般设成和 TP/world size 一致。P 和 D 必须一样。
|
||||
- **`kv_buffer_size`**：通道里最多允许多少块 KV "在路上"。值越大，流水越深、占用显存可能越多；不确定就先用 `1`，稳一点。
|
||||
- **`kv_port`**：KV 通道用的基础端口。P / D 两边要一致，别和其他服务冲突。
|
||||
|
||||
**`kv_connector_extra_config` 里的：**
|
||||
|
||||
- **`proxy_ip`**：KV 代理服务的 IP，或者要连的那台机的 IP。单机可以写 `0.0.0.0` 或 `127.0.0.1`，跨机就写对端/代理机的 IP。
|
||||
- **`proxy_port`**：KV 代理服务监听的端口。P / D 配成同一个值，比如 30001。
|
||||
- **`http_port`**：**Decoder vLLM HTTP 服务的端口**（就是 D 起 server 时的 `--port`）。用来让 KV 组件知道 D 的 HTTP 在哪里。
|
||||
|
||||
**关于 xPyD：**
|
||||
|
||||
一般来说 xPyd，其中每一个 p 节点或者 d 节点都要能独立加载完整个模型。
|
||||
|
||||
总卡数量：总 GPU 数 = (P + D) × TP × DP
|
||||
|
||||
最后使用 vllm 自带的代理端口转发即可：
|
||||
|
||||
```
|
||||
python3 vllm/examples/online_serving/disaggregated_serving_p2p_nccl_xpyd/disagg_proxy_p2p_nccl_xpyd.py
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **下载说明**：本文原文含大量 CSDN 页面噪声（侧边栏推荐文章、广告、评论 UI、VIP 弹窗等），已剔除非作者内容，仅保留正文与代码；CSDN 推荐栏中出现的其他博主的 PD 分离相关文章摘要未纳入。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：pd分离在vllm中用法
|
||||
|
||||
> **原文**：[2025-12-01_pd分离在vllm中用法.md](./2025-12-01_pd分离在vllm中用法.md)
|
||||
> **原文链接**：https://blog.csdn.net/qq_44319972/article/details/155456852
|
||||
> **来源**：CSDN 博客
|
||||
> **作者**：小徐炸酱面（qq_44319972）
|
||||
> **发布日期**：2025-12-01（2025-12-02 修改）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **KV 流转** — vLLM 中 PD 分离工程化的核心是"prefill 生成的 KV 如何让 decode 用起来"，本文给出 kv-transfer-config 的参数级配置说明。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 vLLM PD 分离的实操笔记，把部署要点收敛为一个核心问题："prefill 生成的 KV，如何让 decode 能够用起来"。文章先定义 P 节点（Producer，看重算力/FLOPs）与 D 节点（customer，看重显存/网络带宽与 tail latency），梳理 KV 流转四步（prefill→分配 KV Block→经 KV Connector/RPC 通道传递位置信息与 metadata→decode 持续访问），再给出 1P1D 场景下 producer 与 decoder 的完整启动命令，逐项解释 kv-transfer-config 的 kv_connector/kv_role/kv_rank/kv_parallel_size/kv_buffer_size/kv_port 及 proxy 三项参数含义，并给出 xPyD 总卡数公式（(P+D)×TP×DP）。价值在于参数级细节是综述类文章不具备的、可直接指导部署。局限：无性能验证，且 decoder 示例疑似复制粘贴错误，需修正后使用。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **核心即 KV 流转** — PD 分离成败在于 prefill 产出的 KV 能否高效被 decode 使用，抽象为 KV Connector/RPC 通道 + 状态约定 `[分类: 共识]`
|
||||
2. **P/D 角色差异** — P 节点看重算力/GPU FLOPs，对长尾小请求不敏感；D 节点看重显存/网络带宽，关注 tail latency（TPOT、e2e） `[分类: 共识]`
|
||||
3. **并行策略必须匹配** — 有 DP/TP 时 P/D 两侧并行策略须一致，否则出现 KV 维度不一致、block id 对不上等问题 `[分类: 共识]`（实操经验）
|
||||
4. **kv-transfer-config 参数详解** — kv_role（producer/consumer）、kv_rank、kv_parallel_size（与 TP/world size 一致且 P/D 必须相同）、kv_buffer_size（流水深度，不确定先用 1）、kv_port 及 proxy_ip/proxy_port/http_port 的设置原则 `[分类: 共识]`（实操）
|
||||
5. **xPyD 规模公式** — 总 GPU 数 = (P+D)×TP×DP；每个 P/D 节点都须能独立加载完整模型，对外经 disagg_proxy 端口转发 `[分类: 共识]`（实操）
|
||||
6. **调度器拆分** — Producer 侧与 Decoder 侧各自 scheduler，以 request id、已生成 token 数、KV block id 列表、EOS/abort 状态对齐两边约定 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者已熟悉 vLLM（V1 引擎、scheduler 概念）；假设 NCCL 网络与 KV 代理服务可用；假设 KV 通道数（kv_parallel_size）与 TP world size 对齐。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
无性能数据，属经验整理而非验证性文章；Decoder 节点示例与 Producer 完全相同（vllm_PD_ROLE 与 kv_role 未改，原文已加注提示），说明示例未经实际运行验证，照抄会部署失败——这是论据链的关键缺口；但参数解释与 vLLM 官方文档一致，整体可信度尚可。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
仅覆盖 P2pNcclConnector 的 1P1D（单机/双机）场景，未涉及 SharedStorage/LMCache/MultiConnector、多机大规模部署与 kv_buffer_size 调优；作者自述"示意/伪代码"，不能替代官方文档。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD 分离的**核心**就是：**prefill 生成的 KV，如何让 decode 能够用起来**。"
|
||||
|
||||
> "如果有 DP/TP，P/D 侧的并行策略也要匹配（否则会出现 KV 维度不一致、block id 对不上等问题）"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- kv-transfer-config 各参数逐项解释，实战稀缺
|
||||
- 给出可直接照做的启动命令与 xPyD 卡数公式
|
||||
- 诚实标注"示意/伪代码"并提示 DP/TP 匹配等坑点
|
||||
|
||||
**不足**：
|
||||
- decoder 示例疑似复制粘贴错误，须自行修正（角色应改为 kv_consumer）
|
||||
- 无性能验证数据，经验未经实测背书
|
||||
- 场景覆盖窄（仅 P2pNccl 的 1P1D）
|
||||
|
||||
**适用场景**：准备在 vLLM V1 上搭建 PD 分离服务的工程师，作为起步配置参考。
|
||||
|
||||
**关联建议**：对照 vLLM 官方文档 Disaggregated Prefilling 章节与 KV Connector API V1；参考 cr7258 文中五种 KV Connector 的对比做扩展选型。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,92 @@
|
||||
# 【大模型】深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)
|
||||
|
||||
> **来源**：CSDN 博客
|
||||
> **作者**：烟锁池塘柳0
|
||||
> **发布日期**：2025-07-21
|
||||
> **原文链接**：https://blog.csdn.net/Zlyzjiabjw547479/article/details/149499063
|
||||
|
||||
---
|
||||
|
||||
## 深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)
|
||||
|
||||
### 1 从统一到分离，推理架构为何演进？
|
||||
|
||||
在标准的大型语言模型推理流程中，整个生成任务，从处理用户输入（Prompt）到逐字生成回答，通常都在同一个GPU上完成。这种统一式架构（Unified Architecture）虽然简单，但随着模型规模和并发请求量的激增，其固有的低效率问题逐渐暴露。
|
||||
|
||||
问题的根源在于，LLM推理的两个核心阶段——**Prefill**和**Decode**——在计算特性上存在根本性的差异：
|
||||
|
||||
1. **Prefill (预填充) 阶段**:
|
||||
|
||||
- **任务**: 并行处理输入的整个Prompt，为其所有Token计算Key和Value，并生成初始的KV Cache。
|
||||
- **特性**: 这是**计算密集型 (Compute-Bound)** 任务。计算量巨大，涉及大量的矩阵乘法，可以充分利用GPU强大的并行计算能力（高TFLOPS）。处理一个包含512个Token的Prompt，其计算量可能相当于生成512个Decode步骤的总和。
|
||||
2. **Decode (解码) 阶段**:
|
||||
|
||||
- **任务**: 逐个生成输出Token。每次只处理一个Token，但需要加载整个模型权重和不断增长的KV Cache。
|
||||
- **特性**: 这是**内存带宽密集型 (Memory-Bandwidth-Bound)** 任务。单步计算量小，但需要频繁、大量地从GPU显存中读写数据。其瓶颈在于显存的带宽，而非GPU的计算核心。
|
||||
|
||||
> 关于大模型推理中的Prefill、Decode与KV Cache等概念的介绍，请参考我的这篇文章：【大模型】大模型推理中的Prefill、Decode与KV Cache详解 。
|
||||
|
||||
在统一式架构中，昂贵且计算能力强大的GPU在执行Decode任务时，其计算单元大部分时间处于空闲状态，等待数据从显存中加载，造成了巨大的资源浪费。反之，当GPU忙于一个长Prompt的Prefill时，其他等待Decode的短任务则必须排队，导致系统整体响应变慢。
|
||||
|
||||
为了解决这种资源错配和效率瓶颈，**Prefill-Decode分离（PD分离）**的思想应运而生。其核心目标是：**为不同计算特性的任务匹配最合适的硬件资源，实现系统整体性能的最大化。**
|
||||
|
||||
### 2 什么是Prefill-Decode分离？
|
||||
|
||||
**Prefill-Decode分离**是一种先进的LLM服务架构，它将推理过程中的Prefill和Decode两个阶段，从物理上或逻辑上调度到不同的、专门优化的硬件集群（或资源池）中执行。
|
||||
|
||||
一个典型的PD分离系统架构如下：
|
||||
|
||||
- **路由/调度器 (Router/Scheduler)**: 系统的"大脑"，负责接收所有请求，并根据请求类型（是新的Prompt还是正在进行的生成任务）将其分发到合适的集群。
|
||||
- **Prefill集群**: 由少量但计算能力极强的GPU（如NVIDIA H100/H200）组成，专门用于高效地处理新请求的Prefill阶段。
|
||||
- **Decode集群**: 由大量GPU组成，这些GPU可能算力不是最顶尖，但拥有高内存带宽（如NVIDIA A100），性价比更高，专门用于处理Decode阶段。
|
||||
- **KV Cache传输层**: 这是连接两个集群的桥梁，通常是基于高速网络（如RDMA、NVLink）的分布式内存系统或高速网络文件系统，用于在Prefill和Decode节点之间快速传递KV Cache。
|
||||
|
||||
### 3 PD分离系统的工作流程
|
||||
|
||||
一个用户请求在PD分离架构中的生命周期如下：
|
||||
|
||||
1. **请求到达与Prefill调度**: 用户的新请求（包含Prompt）到达系统。调度器识别出这是一个需要Prefill的任务，并将其分配给Prefill集群中的一个空闲节点。
|
||||
2. **Prefill执行**: Prefill节点接收到Prompt后，利用其强大的并行计算能力，对Prompt中的所有Token进行一次批处理计算，生成初始的KV Cache和响应的第一个Token。
|
||||
3. **KV Cache迁移 (核心步骤)**: Prefill任务完成后，生成的KV Cache（可能高达数GB）以及相关的请求状态信息，被迅速打包并通过高速传输层从Prefill节点发送出去。
|
||||
4. **Decode调度与执行**: 与此同时，调度器将这个"已预处理"的请求（现在携带了KV Cache的引用或实体）分配给Decode集群中的一个可用节点。Decode节点加载这个KV Cache，然后进入自回归生成循环。在每一步，它只为新的一个Token进行计算，从显存中读取模型权重和完整的KV Cache，然后将新生成的(K,V)对追加到Cache中，并将生成的Token流式传输给用户。
|
||||
5. **生成结束与资源释放**: 当生成过程完成（例如，模型输出了结束符`[EOS]`），结果被完整地返回给用户。Decode节点上为该请求分配的资源，特别是宝贵的KV Cache显存，被立即释放，以便服务于下一个等待中的Decode任务。
|
||||
|
||||
### 4 PD分离的优势
|
||||
|
||||
1. **极致的资源利用率与性价比**: 可以为Prefill配置少量昂贵的顶级算力卡，为Decode配置大量性价比更高的带宽型卡。硬件成本可以得到显著优化，避免了让昂贵的计算单元在Decode阶段"无所事事"。
|
||||
2. **更高的系统吞吐量**: 解耦了Prefill和Decode的执行过程。Prefill集群可以持续不断地处理新涌入的请求（提高系统接纳新用户的能力），而Decode集群则专注于为大量并发用户快速生成后续Token。两者互不阻塞，系统整体的并发处理能力（Throughput）大幅提升。
|
||||
3. **灵活的扩展性 (Scalability)**: 可以根据业务负载的实际情况独立扩展两个集群。如果业务场景多为长篇问答（长Prompt），可以增加Prefill集群的节点；如果多为简短的聊天（长对话历史），则可以增加Decode集群的节点。
|
||||
4. **优化的延迟表现**:
|
||||
|
||||
- **降低首字延迟 (TTFT)**: 专用的Prefill集群可以通过更大的批处理（Batching）规模，更高效地处理Prompt，从而加快第一个Token的生成速度。
|
||||
- **保障字间延迟**: Decode集群的专用性确保了正在生成中的任务不会被耗时长的Prefill任务抢占，从而获得稳定、快速的后续Token生成体验。
|
||||
|
||||
### 5 挑战与相应的解决方案
|
||||
|
||||
PD分离架构虽好，但也带来了新的技术挑战：
|
||||
|
||||
- **挑战1: KV Cache传输开销**
|
||||
|
||||
- **问题**: KV Cache可能非常大，在不同物理节点间传输它会引入不可忽视的延迟，可能抵消掉分离带来的部分收益。
|
||||
- **解决方案**:
|
||||
- **硬件层面**: 采用支持RDMA（远程直接内存访问）的InfiniBand或RoCE等超低延迟网络。
|
||||
- **软件层面**: 使用**KV Cache量化**，例如将FP16的Cache压缩为INT8或INT4，显著减小其体积。
|
||||
- **调度层面**: 设计智能调度算法，尝试将同一个长对话的连续轮次的Prefill和Decode任务调度到物理位置相近的节点上。
|
||||
- **挑战2: 复杂的调度系统**
|
||||
|
||||
- **问题**: 调度器需要管理两个异构资源池，并处理任务在它们之间的状态交接，其设计和实现复杂度远高于传统调度器。
|
||||
- **解决方案**: 需要构建一个全局的、状态感知的调度系统。该系统不仅要监控节点负载，还要能够预测任务时长，并对KV Cache的传输进行协同调度，以实现全局最优。
|
||||
- **挑战3: 资源孤岛与负载均衡**
|
||||
|
||||
- **问题**: 如果流量模式剧烈变化，可能导致一个集群（如Prefill）过载，而另一个（Decode）处于空闲，形成暂时的资源孤岛。
|
||||
- **解决方案**: 引入**动态资源分配**机制，允许部分硬件根据需要灵活地在Prefill和Decode角色之间切换。或者，采用更精准的负载预测模型来提前调整资源池大小。
|
||||
|
||||
### 6 总结与展望
|
||||
|
||||
Prefill-Decode分离是LLM推理系统从"作坊式"走向"工业化"的重要一步。它体现了计算体系结构中的一个经典思想：**用专门化的组件处理专门化的任务**。通过将Prefill的计算密集型特性与Decode的访存密集型特性解耦，并为之匹配最优化的硬件，PD分离架构能够显著提升大型语言模型服务的吞吐量、降低成本，并优化延迟。
|
||||
|
||||
虽然实现上存在挑战，但随着Orca、Sarathi等研究系统的提出和业界实践的深入，PD分离正逐渐成为超大规模AI计算中心的主流架构范式。未来，它还将与投机性解码（Speculative Decoding）、模型混合（MoE）等更多先进技术融合，共同推动AI普惠化的进程。
|
||||
|
||||
---
|
||||
|
||||
**标签**：#人工智能 #深度学习 #语言模型
|
||||
+80
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：【大模型】深入解析大模型推理架构之 Prefill-Decode Disaggregation (PD分离)
|
||||
|
||||
> **原文**：[2025-07-21_大模型_深入解析大模型推理架构之_Prefill-Decode_Disaggregation_(PD分离).md](./2025-07-21_大模型_深入解析大模型推理架构之_Prefill-Decode_Disaggregation_(PD分离).md)
|
||||
> **原文链接**：https://blog.csdn.net/Zlyzjiabjw547479/article/details/149499063
|
||||
> **来源**：CSDN 博客
|
||||
> **作者**：烟锁池塘柳0
|
||||
> **发布日期**：2025-07-21
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **异质配型** — PD 分离的本质是"为不同计算特性的任务匹配最合适的硬件资源"，是计算机体系结构中专门化思想的 LLM 服务化应用。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文用"统一到分离"的演进叙事讲清 PD 分离：prefill 计算密集（处理 512 token 的计算量约等于 512 步 decode 的总和），decode 内存带宽密集，统一架构下 GPU 计算单元在 decode 阶段大部分空闲、长 prompt 的 prefill 又令短任务排队，故按阶段分配异构硬件——少量顶级算力卡（H100/H200 类）做 prefill、大量高带宽性价比卡（A100 类）做 decode，中间以高速 KV Cache 传输层衔接。价值在于把技术架构提炼为"用专门化的组件处理专门化的任务"的经典思想，并完整梳理五步工作流、四大优势与三大挑战及对策。局限：全定性论述、无实验数据，挑战对策停留在概念层。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **统一架构的资源错配** — 昂贵 GPU 在 decode 阶段计算单元大部分空闲等待显存加载；长 prompt prefill 令等待 decode 的短任务排队 `[分类: 共识]`
|
||||
2. **异构硬件匹配** — Prefill 集群用少量顶级算力卡、Decode 集群用大量高带宽性价比卡，避免昂贵计算单元"无所事事" `[分类: 共识]`
|
||||
3. **五步工作流** — 请求调度→prefill 执行→KV Cache 迁移（核心步骤，可能高达数 GB）→decode 执行→结束释放 `[分类: 共识]`
|
||||
4. **四大优势** — 资源利用率与性价比、解耦提升吞吐、两集群独立扩展、TTFT/TPOT 延迟优化 `[分类: 共识]`
|
||||
5. **三大挑战与对策** — KV 传输开销（RDMA 网络/KV Cache 量化/位置亲和调度）、复杂调度（全局状态感知）、资源孤岛（动态角色切换/负载预测） `[分类: 共识]`
|
||||
6. **未来融合方向** — 与投机解码（Speculative Decoding）、MoE 等先进技术融合，推动 AI 普惠化 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设大规模集群场景使"少量 P 卡 + 大量 D 卡"的分工有意义；假设 RDMA 网络、KV Cache 量化等补偿手段的代价可接受；假设流量模式允许两集群独立扩展。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
全为定性论证，无量化数据支撑"显著提升"；挑战与对策是概念性列举（如 KV 量化未讨论精度损失、调度方案未讲实现），但"差异→错配→解耦→新挑战"的逻辑链完整清晰，适合建立直觉。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
未讨论小规模部署与成本门槛、未对比 chunked-prefills 等替代架构；硬件建议仅覆盖 NVIDIA 生态，对国产卡与其他厂商不适用；KV 量化精度影响、调度器复杂度等只提问题不给权衡。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Prefill-Decode分离是LLM推理系统从'作坊式'走向'工业化'的重要一步。"
|
||||
|
||||
> "它体现了计算体系结构中的一个经典思想：**用专门化的组件处理专门化的任务**。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 以"专门化"思想统摄全文，认知框架清晰，适合入门
|
||||
- 五步工作流与三大挑战归纳完整，结构性强
|
||||
- 硬件选型建议（顶级算力卡与高带宽卡分工）具有参考价值
|
||||
|
||||
**不足**：
|
||||
- 无实验数据，结论均定性
|
||||
- 挑战对策停留在概念层，无实现细节
|
||||
- 未涉及开源框架落地与国产硬件
|
||||
|
||||
**适用场景**：对 LLM 推理架构零基础的工程师、学生建立 PD 分离整体认知。
|
||||
|
||||
**关联建议**：阅读 cr7258《PD 分离推理架构详解》获取论文数据与 vLLM 实现细节；跟进 DistServe、Splitwise、Mooncake 论文原文。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,413 @@
|
||||
# Lesson 06：PD 分离推理架构详解（AI Infra 学习课程）
|
||||
|
||||
> **来源**：GitHub
|
||||
> **作者**：cr7258（ai-infra-learning 仓库）
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://github.com/cr7258/ai-infra-learning/tree/main/lesson/06-disaggregating-prefill-and-decoding
|
||||
|
||||
---
|
||||
|
||||
## PD 分离推理架构详解
|
||||
|
||||
在大语言模型推理过程中，prefill 阶段和 decode 阶段具有截然不同的计算特性：
|
||||
|
||||
- prefill 阶段需要并行处理整个输入序列来生成首个 token，属于**计算密集型**操作。
|
||||
- decode 阶段则逐个生成后续 token，需要频繁访问 KV cache，属于**内存密集型**操作。
|
||||
|
||||
传统的 continuous batching 将两个阶段混合处理，导致相互干扰，难以同时满足 TTFT（首 token 延迟）和 TPOT（token 间延迟）的严格要求。为了解决这一问题，PD 分离架构应运而生，通过将 prefill 和 decode 分配到不同的 GPU 实例上，针对各自特性进行专门优化。这种分离式设计不仅消除了阶段间的干扰，还能显著提升系统的有效吞吐量（Goodput），为大规模 LLM 服务提供了更优的解决方案。
|
||||
|
||||
## 1 吞吐量（Throughput）vs 有效吞吐量（Goodput）
|
||||
|
||||
目前，大多数 LLM 服务系统（如 vLLM、TensorRT-LLM）都以吞吐量（Throughput）作为主要性能指标——即单位时间内处理的请求数（RPS）或生成的 token 数。这种度量方式直观，并且与成本（$/req）有直接关联，因此被广泛采用。
|
||||
|
||||
实际上，下游应用的类型多种多样，它们在用户体验上的延迟需求各异，因此需要满足的服务等级目标（SLO）也存在显著差异。大模型服务中最常用的 SLO 包括：
|
||||
|
||||
- **TTFT (Time To First Token)**：首 token 响应延迟，直接影响用户的等待体验。
|
||||
- **TPOT (Time Per Output Token)**：衡量两个连续生成的 token 之间的平均延迟，决定交互的流畅程度。
|
||||
|
||||
例如，实时聊天机器人更关注低 TTFT 以保证响应及时，而 TPOT 只需快于人类阅读速度（约 250 词/分钟）即可；相反，文档摘要则更强调低 TPOT，以便更快地产生完整摘要。
|
||||
|
||||
|
||||
|
||||
单纯依赖 Throughput 作为指标，并不能反映延迟表现，系统看似处理了大量请求，但其中不少未能满足 SLO，最终呈现给用户的仍是不理想的服务体验。
|
||||
|
||||
- **Throughput（吞吐量）**：通常指系统单位时间内处理的 token 数或请求数。很多工作把"提高吞吐量"作为主要优化目标，但在实际场景下，这并不直接代表用户体验。
|
||||
- **Goodput（有效吞吐量）**：指系统在满足延迟约束（如 TTFT/TPOT SLO）的前提下，真正完成的请求数量。如果一个请求因为延迟过长而被用户放弃，或者超过服务约束而无效，那么即便它产生了 token，也不能算作有效产出。
|
||||
|
||||
在 DistServe 论文中，引入了 Goodput 概念，**即在满足 SLO（TTFT 和 TPOT 要求）的前提下，每秒完成的有效请求数**。与单纯的吞吐量相比，Goodput 是更优的衡量指标，**因为它能够体现请求在满足 SLO 情况下的吞吐水平**，从而同时反映成本效益与服务质量。
|
||||
|
||||
为了简要说明 Goodput，假设某个应用要求至少 90% 的请求满足 TTFT < 200ms 且 TPOT < 50ms，则可以得到如下定义：
|
||||
|
||||
> Goodput (P90 TTFT < 200ms 且 P90 TPOT < 50ms) 表示在至少 90% 的请求同时满足 TTFT < 200ms 和 TPOT < 50ms 的条件下，系统所能维持的最大每秒请求数。
|
||||
|
||||
下图展示了一个简单的例子：某应用的吞吐量为 10 RPS（每秒请求数），但由于延迟约束的限制，只有 3 RPS 的请求满足 SLO，因此该系统的 Goodput 仅为 3 RPS。可以想象，用户在这样一个高吞吐但低 Goodput 的系统中，依然会感受到较差的服务体验。
|
||||
|
||||
|
||||
|
||||
## 2 Prefill 与 Decode 共置导致干扰
|
||||
|
||||
在 LLM 服务中请求的生命周期通常包含两个阶段：prefill（生成首个 token）和 decode（逐步生成后续 token）。大多数现有系统（如 vLLM、TensorRT-LLM）采用 continuous batching 技术，将 prefill 和 decode 混合在一起统一批处理。这种方式确实能够提升整体吞吐量，但由于两者计算特性和 SLO 目标差异显著，将它们共置在同一 GPU 上往往并不理想。
|
||||
|
||||
|
||||
|
||||
如下图所示，continuous batching 会带来明显的干扰。**当 prefill 和 decode 被放在同一批次时，decode 请求的延迟（TPOT）会被显著拉长，而 prefill 请求的首 token 延迟（TTFT）也会有所增加。**
|
||||
|
||||
|
||||
|
||||
图中展示了三种不同的执行方式：
|
||||
|
||||
- 1P+nD（棕色柱子）：1 个 prefill 与 n 个 decode 混合批处理。
|
||||
- nD（蓝色柱子）：仅包含 decode 请求的批处理。
|
||||
- prefill-only（红色虚线）：仅运行 prefill 请求的延迟。
|
||||
|
||||
**在 prompt 长度为 128 时，相比仅包含 decode 的请求，延迟增加约 1.8 倍；而当 prompt 长度为 1024 时，干扰效应显著放大，decode 延迟提升至 12.6 倍。**
|
||||
|
||||
|
||||
|
||||
由于这种干扰，如下图所示，当服务必须同时满足 TTFT 和 TPOT 的 SLO 时，**系统往往需要进行资源的过度配置才能达到延迟目标**，尤其是在任一 SLO 要求较严格的情况下。
|
||||
|
||||
|
||||
|
||||
## 3 PD 分离的整体思路
|
||||
|
||||
直观的思路很简单：将 prefill 和 decode 分离到不同的 GPU 上，并为每个阶段定制并行策略。这自然解决了前面提到的两个问题：
|
||||
|
||||
- **没有干扰**：prefill 和 decode 各自独立运行，更快地完成计算，也更容易满足各自的 SLO。
|
||||
- **资源分配与并行策略解耦**：可以针对 prefill 和 decode 分别进行优化。
|
||||
|
||||
下图展示了在这样一个分离式系统中，请求是如何被处理的。当一个请求到达系统时，它会先被分配到 prefill worker 完成 prefill 阶段；随后系统将其中间状态（主要是 KV Cache）迁移到 decode worker，并执行多步 decode 以生成后续 token；当生成完成后，请求才会离开系统。
|
||||
|
||||
|
||||
|
||||
让我们通过一个简单的实验来看看为什么 PD 分离是有益的。我们在一张 A100-80GB GPU 上运行一个 130 亿参数的 LLM，请求到达服从泊松分布，输入长度为 512，输出长度为 64。我们逐步增加请求速率（x 轴），并在下图测量两类延迟（P90 TTFT 和 P90 TPOT，y 轴）的变化。
|
||||
|
||||
假设我们设定 SLO：P90 TTFT = 0.4 秒，P90 TPOT = 0.04 秒（下图中的横线）。实验结果表明：在单卡情况下，现有系统大约可以在 3 rps 下满足 TTFT 的延迟约束，而 TPOT 只能维持在 1.6 rps（下图左边）。由于必须同时满足两个约束条件，现有共置系统的 Goodput = min(3, 1.6) = 1.6 rps/GPU。
|
||||
|
||||
在分离之后，性能得到了显著提升。如果单独处理一个阶段，prefill worker 和 decode worker 的 rps 都优于之前的结果 —— 如下图右边所示，一个 prefill worker 大约可达到 5.6 rps，一个 decode worker 大约可达到 10 rps。更重要的是，我们现在可以灵活地分配资源，例如配置 2 个 prefill worker + 1 个 decode worker（记作 2P1D），共 3 张 GPU。此时：
|
||||
|
||||
```
|
||||
Goodput (2P1D) = min(5.6 × 2, 10) = 10 reqs/s ÷ 3 GPUs ≈ 3.3 rps/GPU。
|
||||
```
|
||||
|
||||
这个实验表明，即便没有引入任何并行优化，仅仅通过简单的分离，Goodput 就提升了约 2 倍。
|
||||
|
||||
|
||||
|
||||
## 4 分离式推理架构的优化方向
|
||||
|
||||
### 4.1 算力与存储
|
||||
|
||||
- prefill 阶段：拥有**计算受限**的性质（compute-bound），特别是在请求流量较大，用户的 prompt 也比较长的情况下。prefill 阶段算完 KV cache 并发给 decode 阶段后，理论上 prefill 就不再需要这个 KV cache 了（当然你也可以采用 LRU 等策略对 KV cache 的保存做管理，而不是一股脑地清除）。
|
||||
- decode 阶段：拥有**内存受限**的性质（memory-bound），因为逐个 token 的生成方式，decode 阶段要频繁从内存中读取 KV Cache，同时也意味着它需要尽可能保存 KV cache。
|
||||
|
||||
因此在分离式框架下，计算和存储可以朝着两个独立的方向做优化。
|
||||
|
||||
### 4.2 Batching 策略
|
||||
|
||||
- prefill 阶段：随着 batch size 的增加，吞吐量的提升很快趋于平缓。这是因为 prefill 属于 compute-bound，当 batch 中的总 tokens 数超过一定规模后，GPU 的计算能力已经被完全吃满，再增加请求只会延长整体处理时间，而不会带来明显的吞吐提升。
|
||||
- decode 阶段：随着 batch size 的增加，吞吐量的增长趋势越来越显著。这是因为 decode 阶段是 memory-bound，即相比于计算，读写数据的时间要更多。所以在 decode 阶段中，如果我们能提升 batch size，就能把计算强度提起来，吞吐量就上去了。
|
||||
|
||||
|
||||
|
||||
在分离架构下，我们可以针对 prefill 和 decode 的特性对 batching 策略分别进行优化：
|
||||
|
||||
- 具体来说，对于 prefill 实例，需要事先结合特定的 LLM 和 GPU 做性能分析，找出输入长度的临界点——一旦超过这个点，prefill 就会进入 compute-bound，此时增加 batch size 只会拖慢整体处理速度。在实际应用中，用户的 prompt 往往已有数百个 tokens，因此 **prefill 的 batch size 通常保持较小**。
|
||||
- **相对地，decode 阶段更适合采用较大的 batch size，以充分提升 GPU 利用率和整体吞吐。**
|
||||
|
||||
### 4.3 并行策略
|
||||
|
||||
由于 prefill 和 decode 具有不同的计算模式和延迟目标，这两个阶段的最佳并行策略通常并不相同。例如，当 TTFT 要求严格而 TPOT 要求相对宽松时，prefill 更适合采用**张量并行**来满足低延迟，而 decode 则通常采用**数据并行**或**流水线**并行来提升吞吐。
|
||||
|
||||
## 5 KV Cache 传输
|
||||
|
||||
PD 分离带来的代价是需要在 prefill 和 decode 的 GPU 之间传输中间状态（即 KV cache）。接下来，我们来看看 KV cache 传输的开销分析、传输方式以及相关的优化策略。
|
||||
|
||||
### 5.1 KV Cache 传输开销
|
||||
|
||||
初看之下，KV cache 是 LLM 推理中巨大的内存开销，而 GPU 之间 KV cache 的传输似乎会成为瓶颈。然而，DistServe 的论文中展示了相反的结果：通过合理的放置，KV Cache 的传输开销可以被有效地最小化，甚至低于一次 decode 步骤的时间，这得益于当今高速互联网络（如 NVLink 和 PCI-e 5.0）。
|
||||
|
||||
假设我们在 GPU 之间使用 8 通道 PCIe 5.0 x16（每条链路 64GB/s）作为节点内互联。对于一个包含 2048 tokens 的请求，在服务 OPT-175B 时传输 KV cache 的延迟可以估算如下：
|
||||
|
||||
```
|
||||
Latency = 2048 tokens * (4.5 MB/token) / (64GB/s * 8) = 17.6 ms
|
||||
```
|
||||
|
||||
对于 OPT-175B，延迟小于单次 decode 步骤（在 A100 上约为 30-50 毫秒）。对于更大的模型、更长的序列或更先进的网络（例如带宽为 600GB/s 的 A100-NVLink），如下图所示，与单次 decode 步骤相比，KV cache 传输相关的相对开销变得不那么显著。总之，通过精心安排 prefill 和 decode 工作节点以利用高带宽网络，可以有效隐藏 KV cache 传输的开销。
|
||||
|
||||
|
||||
|
||||
### 5.2 KV Cache 传输方式
|
||||
|
||||
目前 KV cache 的传输主要有两种方式：**中心存储**和**点对点（P2P）**，当然在实际系统中也可能采用二者结合的混合方案。
|
||||
|
||||
- **中心存储**：建立一个跨设备的 KV store，由它统一管理 KV cache 的增、删、查和传递等操作。prefill 和 decode 实例只需与这个 KV store 交互，负责写入或读取数据。
|
||||
- **P2P 传输**：每个实例独立管理自己的存储。例如，一个 prefill 实例完成计算后，会直接与目标 decode 实例建立通信，将 KV cache 传过去，不依赖统一的中介。
|
||||
|
||||
两种方式各有优劣：
|
||||
|
||||
- **中心存储**：更适合构建大规模集群，能充分利用多种存储介质和传输通道，并提升计算结果的复用效率，但在某些场景下性能可能受限，同时系统维护成本较高。
|
||||
- **P2P 传输**：架构更简单，性能表现通常更好，但在扩展性和链路稳定性方面会面临挑战。
|
||||
|
||||
|
||||
|
||||
### 5.3 KV Cache 传输的网络堆栈
|
||||
|
||||
现有的物理数据链路可以分为 3 类：
|
||||
|
||||
- **Direct**，即 GPU 之间通过高速直连链路（如 NVLink 或 HCCS）相互连接。在这种情况下，可以利用底层的内存拷贝原语或集体通信库来完成数据传输。
|
||||
- **Direct-NIC**，即 GPU 通过其配套的网卡（NIC）进行通信。在这里，可以使用定制化的库，通过 PCIe 和以太网（或 InfiniBand）进行数据传输。
|
||||
- **Indirect**，即当 GPU 之间没有直接链路时，必须通过其 CPU 的 DRAM 中转数据，从而带来额外的内存拷贝开销。
|
||||
|
||||
|
||||
|
||||
图片来源：Inference without Interference: Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
|
||||
### 5.4 KV Cache 传输粒度
|
||||
|
||||
KV cache 传输粒度可以分为 3 类：
|
||||
|
||||
- **请求级**：等到 prefill 阶段完成后，将 KV cache 一次性传输。这种方式的好处是能够减少网络传输次数，因为每次传输的数据量更大，从而降低了通信开销。然而当 KV cache 大小较大时，会影响 TTFT 的延迟。
|
||||
- **层级**：Splitwise 通过在 prefill 阶段的计算与 KV cache 传输之间实现重叠来优化性能。**每一层计算完成后，都会异步传输该层的 KV cache，同时继续执行下一层的计算，从而降低传输开销。**层级传输还能带来额外优势，例如更早启动 decode 阶段，以及更早释放 prefill 端的内存。层级 KV cache 传输与下一层的 prefill 计算并行进行，这需要逐层的细粒度同步以确保正确性，因此可能会带来性能干扰并增加 TTFT，尤其是在小 prompt 的场景下。不过对于小 prompt 来说，KV cache 的总体规模很小，不需要层级传输来隐藏延迟。由于在计算开始时批次中的 token 数已经是已知的，**Splitwise 会选择最合适的 KV cache 传输方式：小 prompt 使用序列化传输，而大 prompt 使用层级传输。**
|
||||
|
||||
|
||||
|
||||
图片来源：Splitwise: Efficient Generative LLM Inference Using Phase Splitting
|
||||
|
||||
- **块级**：TetriInfer 在 PD 分离的基础上，还会将输入的 prompt 划分为固定大小的 chunk，以便让 GPU 始终运行在接近计算饱和的状态。因此，TetriInfer 论文中也提出了基于块级的 KV cache 传输方案。
|
||||
|
||||
## 6 vLLM 的 PD 分离
|
||||
|
||||
vLLM 提供了 **KV Connector** 作为管理实例间 KV cache 交换的抽象层，它提供统一接口来实现 KV cache 的保存、加载与传输，使不同的 vLLM 实例（如 prefill 与 decode 实例）能够高效共享计算结果。通过实现这一接口，各类 connector（例如通过文件系统的 SharedStorageConnector、通过网络的 NixlConnector 等）提供了灵活的 KV cache 传输方案，从而支持 PD 分离等高级功能。
|
||||
|
||||
`KVConnectorBase_V1` 是所有 connector 的基类。它是一个抽象基类，定义了以下 API：
|
||||
|
||||
- scheduler 侧方法：
|
||||
- build_connector_meta：构建元数据，scheduler 告诉 worker 需要保持/加载哪些 KV cache。
|
||||
- get_num_new_matched_tokens：获取远端已计算的 KV cache 的 token 数量。
|
||||
- update_state_after_alloc：block 开辟后，更新 connector 的状态。
|
||||
- worker 侧方法：
|
||||
- **start_load_kv**：从 connector buffer 加载 KV cache，消费端调用。
|
||||
- wait_for_layer_load：阻塞直到指定层加载结束，消费端调用；
|
||||
- **save_kv_layer**：将 vLLM 的 KV buffer 中某一层的 KV cache 保存到 connector buffer 中，生产端调用。
|
||||
- wait_for_save：阻塞直到所有保存操作完成，生产端调用。
|
||||
|
||||
vLLM v1 中 connector 有两个执行角色（Role）：scheduler_connector 和 worker_connector，分别在 scheduler 线程和 worker 线程中执行。**scheduler 负责指挥 worker 进行 KV cache 的传递，两者之间的信息桥梁是元数据（KVConnectorMetadata），worker 通过 metadata 知道哪些 KV 值需要从远端加载。**
|
||||
|
||||
|
||||
|
||||
当前 vLLM 支持 5 种类型的 connector，分别是：
|
||||
|
||||
- **SharedStorageConnector**：SharedStorageConnector 是 vLLM 中最简单的 KV Connector 实现，它通过共享文件系统（如本地磁盘或 NFS）在 prefill 和 decode 实例之间传递 KV cache，使用 MD5 哈希生成唯一文件名来存储和检索每个请求的 KV cache。prefill 实例将每层的 KV cache 序列化为 SafeTensors 格式保存到指定路径，decode 实例根据相同的 token_ids 计算哈希值找到对应文件并加载，整个过程没有显式的网络传输，完全依赖文件系统的读写操作。
|
||||
- **P2pNcclConnector**：P2pNcclConnector 是基于 NCCL（NVIDIA Collective Communications Library）实现的高性能 KV Connector，它通过 NCCL 的 send/recv 原语实现 KV cache 在不同 GPU 之间的点对点传输，避免了文件系统的开销。
|
||||
- **NixlConnector**：NixlConnector 使用 NIXL（NVIDIA Inference Xfer Library）库来加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。
|
||||
- **LMCacheConnectorV1**：通过与 LMCache 集成实现 KV cache 的外部存储和检索，支持多种存储后端（如 CPU 内存、本地文件系统、Redis、InfiniStore 等）。LMCache 通过重用缓存的 KV cache 来减少推理时间，消除冗余计算，适用于跨请求或跨会话的 KV cache 共享场景。
|
||||
- **MultiConnector**：允许同时使用多个 KV connector 来实现 KV cache 的传输，它的核心逻辑是从第一个能提供可用 token 的 connector 加载 KV cache，但会向所有 connector 保存数据。MultiConnector 适用于需要同时向多个存储后端保存 KV cache 的场景，比如同时保存到本地存储和远程存储，提供数据冗余和可靠性保障。
|
||||
|
||||
```json
|
||||
--kv-transfer-config '{
|
||||
"kv_connector": "MultiConnector",
|
||||
"kv_connector_extra_config": {
|
||||
"connectors": [
|
||||
{
|
||||
"kv_connector": "NixlConnector",
|
||||
"kv_role": "kv_both"
|
||||
},
|
||||
{
|
||||
"kv_connector": "SharedStorageConnector",
|
||||
"kv_connector_extra_config": {
|
||||
"shared_storage_path": "local_storage"
|
||||
},
|
||||
"kv_role": "kv_both"
|
||||
}
|
||||
]
|
||||
},
|
||||
"kv_role": "kv_both"
|
||||
}'
|
||||
```
|
||||
|
||||
以上几个 connector 的运行实例代码可以在这里找到：https://docs.vllm.ai/en/latest/features/disagg_prefill.html#usage-example
|
||||
|
||||
## 7 PD 分离工业界项目
|
||||
|
||||
### 7.1 Mooncake
|
||||
|
||||
Mooncake 是 Moonshot AI 提供的领先大模型服务 Kimi 的推理平台。Mooncake 是 PD 分离应用比较早也是规模比较大的成功例子：
|
||||
|
||||
- Mooncake 采用了以 KV cache 为核心的解耦架构，将 prefill 集群与 decode 集群分离。
|
||||
- 同时，它还利用 GPU 集群中未被充分利用的 CPU、DRAM 和 SSD 资源，实现了解耦式的 KV cache 缓存。
|
||||
- Mooncake 的核心是一个以 KV cache 为中心的调度器，它在最大化整体有效吞吐量和满足延迟相关的 SLO 之间进行平衡。
|
||||
- 与传统假设所有请求都会被处理的研究不同，Mooncake 需要应对高负载场景带来的挑战。为此，Mooncake 提出了一种基于预测的早期拒绝策略。
|
||||
|
||||
|
||||
|
||||
图片来源：Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
实验结果表明，Mooncake 在长上下文场景下表现尤为突出：在某些模拟场景中，吞吐量相比基线方法最高可提升 525%，同时仍能满足 SLO。在真实负载下，Mooncake 的创新架构使 Kimi 能够多处理 75% 的请求。
|
||||
|
||||
使用 Mooncake 运行 PD 分离服务请参考文档：vLLM V1 Disaggregated Serving with Mooncake Store and LMCache
|
||||
|
||||
### 7.2 Dynamo
|
||||
|
||||
NVIDIA Dynamo 是一个开源的模块化推理框架，用于在分布式环境上实现生成式 AI 模型的服务化部署。Dynamo 通过动态资源调度、智能路由、内存优化与高速数据传输，无缝扩展大型 GPU 集群之间的推理工作负载。
|
||||
|
||||
Dynamo 采用推理引擎无关的设计（支持 TensorRT-LLM、vLLM、SGLang 等），包括以下 4 个核心组件：
|
||||
|
||||
- **NVIDIA Dynamo Planner**：一个智能规划和调度引擎，用于监控分布式推理中的容量与延迟，并在 prefill 与 decode 阶段之间灵活分配 GPU 资源，以最大化吞吐量和效率。Planner 会持续跟踪关键的 GPU 容量指标，并结合应用的 SLO（如 TTFT 和 ITL），智能决策是否采用分离式推理，或是否需要为 prefill/decode 阶段动态增加更多 GPU。
|
||||
- **NVIDIA Dynamo Smart Router**：KV cache 感知的路由引擎，可在分布式推理环境中将请求转发到最佳的节点，从而最大限度减少 KV cache 的重复计算开销。
|
||||
- **NVIDIA Dynamo Distributed KV Cache Manager**：通过将较旧或低频访问的 KV cache 卸载到更低成本的存储（如 CPU 内存、本地存储或对象存储等），大幅降低 GPU 内存占用。借助这种分层管理，开发者既能保留大规模 KV cache 重用的优势，又能释放宝贵的 GPU 资源，从而有效降低推理计算成本。
|
||||
- **NVIDIA Inference Transfer Library (NIXL)**：高效的推理数据传输库，可加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。通过减少同步开销和智能批处理，NIXL 显著降低了分布式推理中的通信延迟，使得在 prefill/decode 分离部署时，prefill 节点也能在毫秒级将大批量的 KV cache 传输至 decode 节点，从而避免跨节点数据交换成为性能瓶颈。
|
||||
|
||||
|
||||
|
||||
在 Dynamo 的 PD 分离架构中，有 4 个核心组件：
|
||||
|
||||
- **(decode) worker**：执行 prefill 和 decode 请求。
|
||||
- **prefill worker**：只执行 prefill 请求。
|
||||
- **disaggregated router**：决定 prefill 阶段是在本地还是远程执行。
|
||||
- **prefill queue**：缓存并负载均衡远程 prefill 请求。
|
||||
|
||||
当 worker 收到请求时，首先会通过 disaggregated router 判断 prefill 应该在本地还是远程完成，并分配相应的 KV block。如果选择远程 prefill，请求会被推送到 prefill queue。随后，prefill worker 从队列中取出请求，读取 worker 中 prefix cache 命中的 KV block，执行 prefill 计算，并将生成的 KV block 回写给 worker。最后，worker 会继续完成剩余的 decode 阶段。
|
||||
|
||||
|
||||
|
||||
Dynamo 提供了 Operator 方便我们在 Kubernetes 环境中以声明式的方式定义 PD 分离服务。只需在 `DynamoGraphDeployment` 配置中声明 Frontend、VllmDecodeWorker 和 VllmPrefillWorker 三个组件即可。`dynamoNamespace` 是 Dynamo 分布式运行时的逻辑隔离单元，而非 Kubernetes 的 namespace；同一 `dynamoNamespace` 内的组件可以相互发现并进行通信。
|
||||
|
||||
```yaml
|
||||
apiVersion: nvidia.com/v1alpha1
|
||||
kind: DynamoGraphDeployment
|
||||
metadata:
|
||||
name: vllm-disagg
|
||||
spec:
|
||||
services:
|
||||
Frontend:
|
||||
dynamoNamespace: vllm-disagg
|
||||
componentType: frontend
|
||||
replicas: 1
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
VllmDecodeWorker:
|
||||
dynamoNamespace: vllm-disagg
|
||||
componentType: worker
|
||||
replicas: 1
|
||||
resources:
|
||||
limits:
|
||||
gpu: "1"
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
workingDir: /workspace/components/backends/vllm
|
||||
command:
|
||||
- /bin/sh
|
||||
- -c
|
||||
args:
|
||||
- "python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B"
|
||||
VllmPrefillWorker:
|
||||
dynamoNamespace: vllm-disagg
|
||||
componentType: worker
|
||||
replicas: 1
|
||||
resources:
|
||||
limits:
|
||||
gpu: "1"
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
workingDir: /workspace/components/backends/vllm
|
||||
command:
|
||||
- /bin/sh
|
||||
- -c
|
||||
args:
|
||||
- "python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B --is-prefill-worker"
|
||||
```
|
||||
|
||||
Dynamo 详细的部署教程可以参考博客：https://cr7258.github.io/blogs/original/2025/20-dynamo
|
||||
|
||||
### 7.3 llm-d
|
||||
|
||||
llm-d 是一个 Kubernetes 原生的分布式推理服务栈，为团队提供一条清晰高效的路径，以最快的落地速度在大规模环境中部署并管理推理服务。llm-d 通过集成业界标准的开源技术来加速分布式推理：使用 vLLM 作为模型服务与引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与工作负载控制平面。
|
||||
|
||||
|
||||
|
||||
llm-d 提供以下核心功能：
|
||||
|
||||
- 基于 vLLM 优化的推理调度器：llm-d 基于 IGW 的 Endpoint Picker Protocol (EPP) 实现可定制化的"智能"负载均衡，专门针对 vLLM 进行优化。调度器结合运行时遥测数据，利用过滤和打分算法，在 P/D 分离、KV cache、SLA 与负载感知的基础上做出调度决策，同时支持团队自定义策略。
|
||||
- PD 分离：llm-d 利用 vLLM 的分离式推理能力，将 prefill 和 decode 拆分到独立实例运行，并通过高性能传输库（如 NIXL）进行通信。
|
||||
- 分布式 KV cache：llm-d 使用 vLLM 的 KV connector 构建可插拔的 KV cache 层级体系，支持将 KV cache 卸载到主机、远程存储或 LMCache 等系统。
|
||||
|
||||
使用 llm-d 运行 PD 分离服务请参考：https://github.com/llm-d/llm-d/tree/main/guides/pd-disaggregation
|
||||
|
||||
### 7.4 AIBrix
|
||||
|
||||
AIBrix 是字节跳动开源的云原生分布式推理框架，专为大规模 LLM 部署设计。
|
||||
|
||||
- AIBrix 支持 LoRA 管理、前缀感知和负载感知的智能路由，并通过分布式 KV cache 实现跨节点的高效 token 复用。
|
||||
- 在系统编排层面，AIBrix 结合 Kubernetes 与 Ray 的混合调度，既能满足大规模集群管理的需求，又能灵活执行细粒度任务。
|
||||
- AIBrix 基于 SLO 的 GPU 优化器与诊断工具进一步提升了资源利用率和系统可靠性。
|
||||
|
||||
|
||||
|
||||
使用 AIBrix 运行 PD 分离服务请参考：https://github.com/vllm-project/aibrix/tree/main/samples/disaggregation/vllm
|
||||
|
||||
## 8 Chunked-Prefills VS PD 分离
|
||||
|
||||
chunked-prefills 方案的核心思想是：将长序列的 prefill 请求拆分为几乎相等大小的小块，然后构建了由 prefill 小块和 decode 组成的混合 batch。或者说，chunked-prefills 策略通过将不同长度的 prompts 拆分成长度一致的 chunks 来进行 prefill，以避免长 prompt 阻塞其他请求，同时利用这些 chunks 的间隙进行 decode 的插入/捎带（piggyback）操作，从而减少延迟并提高整体的吞吐。
|
||||
|
||||
decode 阶段的开销不仅来自从 GPU 内存中获取 KV cache，还包括提取模型参数。而通过这种 piggyback 方法，decode 阶段能够重用 prefill 时已提取的模型参数，几乎将 decode 阶段从一个以内存为主的操作转变为一个计算为主的操作。因此，这样构建的混合批次具有近乎均匀的计算需求（而且增加了计算密集性），使我们能够创建平衡的微批处理调度，缓解了迭代之间的不平衡，导致 GPU 的管道气泡最小化，提高了 GPU 的利用率。也最小化了计算新 prefill 对正在进行的 decode 的 TBT 的影响，从而实现了高吞吐量和低 TBT 延迟。
|
||||
|
||||
chunked-prefills 有两个明显的好处：
|
||||
|
||||
- 所有节点被平等对待，使调度更简单。
|
||||
- 将 chunked prefill 内联到 decode 批处理中可以提高 decode 批次的计算强度，从而带来更好的 MFU（Model FLOPs Utilization，指的是模型实际使用的计算量占 GPU 理论峰值算力的比例，用来衡量算力利用效率）。
|
||||
|
||||
然而，chunked-prefills 也有一些缺点：
|
||||
|
||||
- chunked-prefills 会增加 prefill 的计算开销，如果 chunk 大小明显低于 GPU 饱和点，会延长 prefill 的执行时间。
|
||||
- prefill 阶段仍难以完全最大化 MFU，因为在 chunk-prefill 中，profiling 只会估算特定设备上一个 batch 的最大 tokens 配额，这个配额同时包含 prefill 和 decode，而不是分别针对两者优化。
|
||||
- chunked-prefills 也会显著增加 prefill 阶段的内存访问量，每个 chunk 的 Attention 操作都需重复读取此前的 KV cache，增加内存访问负担。而且长序列可能会持久地占据着 KV cache 的存储空间以及 GPU 的计算资源。
|
||||
- 在 TPOT 方面，将 prefill 与 decode 合并批处理实际上会降低所有 decode 任务的平均速度。
|
||||
|
||||
**总之，chunked-prefills 可能有助于最大化整体吞吐量，但由于动态分割无法完全解耦 prefill 和 decode 操作，会导致资源争用以及 TTFT 与 TPOT 之间的妥协。当应用程序无法在 TTFT 和 TPOT 之间进行权衡，而是要同时遵守这两者时，PD 分离就成为更好的选择。**
|
||||
|
||||
## 9 PD 分离相关论文
|
||||
|
||||
- DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
|
||||
- Splitwise: Efficient Generative LLM Inference Using Phase Splitting
|
||||
- TetriInfer: Inference without Interference:Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
- MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool
|
||||
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
## 10 总结
|
||||
|
||||
PD 分离是大模型推理中的一种架构优化策略，核心思想是把 prefill 阶段和 decode 阶段分开，由不同的 GPU 或实例分别承担。通过分离架构，系统可以针对 prefill（计算密集型）和 decode（内存密集型）的不同特性分别优化资源配置和并行策略，从而在满足 TTFT 和 TPOT SLO 约束的前提下显著提升有效吞吐量（Goodput）。虽然 PD 分离需要在 GPU 间传输 KV Cache，但通过高速互联网络和优化的传输策略，这一开销可以被有效隐藏。目前，vLLM、Mooncake、Dynamo 等主流推理框架都已支持 PD 分离，为大规模 LLM 服务提供了更高效的解决方案。相比于 chunked-prefills 等替代方案，PD 分离在需要同时满足严格 TTFT 和 TPOT 要求的场景下具有明显优势。
|
||||
|
||||
## 11 参考资料
|
||||
|
||||
- Lecture 58: Disaggregated LLM Inference：https://www.youtube.com/watch?v=tIPDwUepXcA
|
||||
- Throughput is Not All You Need: Maximizing Goodput in LLM Serving using Prefill-Decode Disaggregation：https://hao-ai-lab.github.io/blogs/distserve/
|
||||
- Mooncake阅读笔记：深入学习以Cache为中心的调度思想，谱写LLM服务降本增效新篇章：https://zhuanlan.zhihu.com/p/706097807
|
||||
- 探秘Transformer系列之（26）--- KV Cache优化 之 PD分离or合并：https://www.cnblogs.com/rossiXYZ/p/18815541
|
||||
- 大模型推理分离架构五虎上将：https://zhuanlan.zhihu.com/p/706218732
|
||||
- LLM关于PD分离的最新实测：https://zhuanlan.zhihu.com/p/1919794916504114120
|
||||
- State of the Model Serving Communities - August 2025：https://inferenceops.substack.com/p/state-of-the-model-serving-communities
|
||||
- 图解大模型训练系列：序列并行1，Megatron SP：https://zhuanlan.zhihu.com/p/4083427292
|
||||
- 序列并行做大模型训练，你需要知道的六件事：https://zhuanlan.zhihu.com/p/698031151
|
||||
- vLLM PD分离KV cache传递机制详解与演进分析：https://zhuanlan.zhihu.com/p/1906741007606878764
|
||||
- vLLM PD分离方案浅析：https://zhuanlan.zhihu.com/p/1889243870430201414
|
||||
- P/D Disaggregation of vLLM and Integration with Mooncake：https://docs.google.com/document/d/1Ab6TMW1E2CdHJJyCrpJnLhgmE2b_6leH5MVP9k72sjw/edit?tab=t.0#heading=h.611v2r4aqubz
|
||||
- 0.5x提升:PD分离KV cache传输的实践经验：https://zhuanlan.zhihu.com/p/1946608360259577576
|
||||
- 分布式推理优化思路：http://zhuanlan.zhihu.com/p/1937556222371946860
|
||||
- 图解大模型计算加速系列：分离式推理架构2，模糊分离与合并边界的chunked-prefills：https://zhuanlan.zhihu.com/p/710165390
|
||||
- 图解大模型计算加速系列：分离式推理架构1，从DistServe谈起：https://zhuanlan.zhihu.com/p/706761664
|
||||
- LLM推理优化 - Prefill-Decode分离式推理架构：https://zhuanlan.zhihu.com/p/9433793184
|
||||
- Shaping NIXL-based PD Disaggregation in vLLM V1：https://blog.lmcache.ai/2025-04-11-lmcache-vllmv1-nixl/
|
||||
- vLLM P2P NCCL Connector：https://docs.vllm.ai/en/latest/design/p2p_nccl_connector.html
|
||||
- vLLM Disaggregated Prefilling (experimental)：https://docs.vllm.ai/en/latest/features/disagg_prefill.html
|
||||
- LMCache Example: Disaggregated prefill：https://docs.lmcache.ai/getting_started/quickstart/disaggregated_prefill.html
|
||||
- Bringing State-Of-The-Art PD Speed to vLLM v1 with LMCache：https://blog.lmcache.ai/2025-04-29-pdbench/
|
||||
- Demystify vLLM V1 KVconnector SharedStorageConnector：https://blog.diabloneo.com/demystify-vllm-v1-kvconnector-sharedstorageconnector-05a487627036
|
||||
- vLLM源码之分离式架构：https://zhuanlan.zhihu.com/p/1933647687
|
||||
- vLLM v1 PD分离设计：https://zhuanlan.zhihu.com/p/1894425784107632241
|
||||
- Inside vLLM: Anatomy of a High-Throughput LLM Inference System：https://blog.vllm.ai/2025/09/05/anatomy-of-vllm.html
|
||||
- [P/D][V1] KV Connector API V1：vllm-project/vllm#15960
|
||||
- vLLM PD Disaggregation discussion：https://docs.google.com/document/d/1uPGdbEXksKXeN4Q9nUm9hzotqEjQhYmnpAhidLuAsjk/edit?tab=t.0#heading=h.qhtgj3vmvwn
|
||||
- llm-d: Kubernetes-native Distributed Inference at Scale：https://github.com/llm-d/llm-d/blob/dev/docs/proposals/llm-d.md
|
||||
@@ -0,0 +1,88 @@
|
||||
# 📊 文章摘要：Lesson 06：PD 分离推理架构详解（AI Infra 学习课程）
|
||||
|
||||
> **原文**：[2026-08-06_Lesson_06_PD分离推理架构详解.md](./2026-08-06_Lesson_06_PD分离推理架构详解.md)
|
||||
> **原文链接**：https://github.com/cr7258/ai-infra-learning/tree/main/lesson/06-disaggregating-prefill-and-decoding
|
||||
> **来源**：GitHub（cr7258/ai-infra-learning）
|
||||
> **作者**：cr7258
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **PD 分离详解** — 用 Goodput 指标重新审视 LLM 推理架构：prefill 与 decode 分离不仅消除阶段干扰，还能在满足 TTFT/TPOT SLO 前提下将有效吞吐量提升约 2 倍（仅靠分离、不加任何并行优化）。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 AI Infra 学习课程第 6 课，系统讲解 PD（prefill-decode）分离推理架构：从 Throughput 与 Goodput 的指标辨析切入，用 DistServe 论文数据量化 prefill/decode 共置干扰（prompt 128 tokens 时 decode 延迟增 1.8 倍、1024 tokens 时达 12.6 倍），以 2P1D 实验演示 Goodput 从 1.6 提升至 3.3 rps/GPU；随后展开分离架构的优化方向（算力/存储特性、batching、并行策略）、KV Cache 传输的全栈分析（开销估算、中心存储 vs P2P、Direct/Direct-NIC/Indirect 三类链路、请求级/层级/块级三种粒度）、vLLM KV Connector 五种实现详解、工业界四项目对比（Mooncake/Dynamo/llm-d/AIBrix），并以 chunked-prefills 与 PD 分离的优劣对比收尾。价值在于：数据详实、链路完整，是理解 PD 分离的优质入门与选型参考。局限在于：部分实验数据出自论文而非作者实测，对传输开销的乐观结论依赖高速网络假设。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Goodput 优于 Throughput 作为服务指标** — Goodput 指满足 SLO（如 P90 TTFT < 200ms 且 P90 TPOT < 50ms）前提下的有效请求数；10 RPS 吞吐可能只有 3 RPS 有效产出，高吞吐≠好体验，评价服务应同时看吞吐与 SLO 达成。 `[分类: 范式突破]`
|
||||
|
||||
2. **共置干扰有量化证据** — prefill 与 decode 混批时，prompt 128 tokens 使 decode 延迟增约 1.8 倍、1024 tokens 时增至 12.6 倍，且同时满足双 SLO 会导致过度配置——这是 PD 分离的必要性论证核心。 `[分类: 共识]`
|
||||
|
||||
3. **分离本身即带来约 2 倍 Goodput 提升** — 单卡共置 Goodput 1.6 rps/GPU vs 2P1D 分离 3.3 rps/GPU，且分离后可分别定制并行策略（prefill 偏张量并行保 TTFT，decode 偏数据/流水线并行保吞吐）。 `[分类: 共识]`
|
||||
|
||||
4. **KV 传输开销可以被隐藏** — 8 通道 PCIe 5.0 下 2048 tokens 的 KV 传输约 17.6ms，低于单次 decode 步骤（30-50ms）；层级传输（Splitwise）与计算重叠可进一步隐藏开销，但层级粒度在小 prompt 场景会引入同步干扰。 `[分类: 共识]`
|
||||
|
||||
5. **PD 分离 vs chunked-prefills 是权衡而非胜负** — chunked-prefills 吞吐调度简单、可提升 decode 批计算强度（MFU），但无法完全解耦两阶段、TTFT 与 TPOT 互相妥协；当应用必须同时满足双 SLO 时 PD 分离更优。这是全文边界意识最强的部分。 `[分类: 争议]`
|
||||
|
||||
6. **vLLM KV Connector 是事实标准抽象** — 5 种 connector（SharedStorage/NCCL P2P/NIXL/LMCache/Multi）覆盖文件系统、RDMA、外部缓存、混合冗余四类路径，`KVConnectorBase_V1` 的 scheduler/worker 职责划分即社区当前实现的基线。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 传输开销"可被隐藏"的结论建立在高速互联假设上（NVLink、PCIe 5.0、RDMA），对普通以太网集群（10/25/40Gbps）不成立，此时 KV 传输反而成为瓶颈——文中未对低速网络场景做等价估算；
|
||||
- 假设请求有明确且独立的 TTFT/TPOT SLO；对只有单一延迟要求或短 prompt 为主的工作负载，PD 分离的收益空间会显著收窄；
|
||||
- 假设 prefill/decode 的比例可通过资源配比灵活调节（2P1D），实际中流量波动要求动态调度能力，本文未展开。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 论据质量总体较高：干扰数据（1.8x/12.6x）、Goodput 计算（含完整算式）、17.6ms 传输估算均给出可追溯出处（DistServe/Splitwise/TetriInfer 论文），教程对原文复述忠实；vLLM connector 部分为代码级事实描述，可信度最高。需注意：2P1D 实验（Goodput 1.6→3.3）来自论文模拟环境而非作者实测；工业界项目部分（Mooncake 525% 提升、75% 请求）转引自项目论文/自述，属二手数据。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 适用场景：具备 GPU 高速互联（NVLink/RDMA）的大规模集群、请求需同时满足严格 TTFT 与 TPOT 的服务（实时对话 + 长文档混合负载）；PD 分离会引入额外的编排复杂度（路由、队列、传输），中小规模或单 SLO 场景未必划算；
|
||||
- 中心存储与 P2P 各有短板（中心存储性能与维护成本、P2P 扩展性与链路稳定），文中已给出但未量化；
|
||||
- 未覆盖：PD 分离下的容错与弹性、跨集群部署、以及 PD 分离对训练/RL 场景的延伸（可参考 Mooncake 权重传输方向）。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "当应用程序无法在 TTFT 和 TPOT 之间进行权衡，而是要同时遵守这两者时，PD 分离就成为更好的选择。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 逻辑链条完整：指标问题 → 干扰证据 → 分离方案 → 传输全栈 → 工程实现 → 方案对比，一篇文章讲透 PD 分离
|
||||
- 数据有出处、计算有过程，并明确区分论文数据与工程事实，论据纪律良好
|
||||
- vLLM KV Connector 代码级详解与四工业项目横向对比，具备直接工程参考价值
|
||||
- 边界意识突出：对 chunked-prefills 的对比是行业争议点的诚实呈现
|
||||
|
||||
**不足**：
|
||||
- 传输开销结论依赖高速网络假设，低速网络场景缺失
|
||||
- 工业界性能数字转引自项目自述，未标注可信度级别
|
||||
- 未涉及容错、动态资源配比、跨集群等生产落地细节
|
||||
|
||||
**适用场景**：LLM 推理架构选型的工程师与架构师（判断"何时该上 PD 分离"）；vLLM 二次开发者的 connector 参考；AI Infra 学习者的体系化入门材料。
|
||||
|
||||
**关联建议**：延伸阅读 DistServe/Splitwise/TetriInfer/MemServe/Mooncake 五篇论文原文；对照 vLLM 官方 disagg_prefill 文档实操；结合 Mooncake、NVIDIA Dynamo、llm-d、AIBrix 四项目文档评估工程化路径；关注社区关于 chunked-prefills 与 PD 分离融合（如 SGLang 的演进）的最新讨论。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,106 @@
|
||||
# AIBrix：云原生 GenAI 推理基础设施（字节跳动开源）
|
||||
|
||||
> **来源**：GitHub
|
||||
> **作者**：字节跳动（ByteDance），vllm-project 组织托管
|
||||
> **发布日期**：2026-06-16
|
||||
> **原文链接**：https://github.com/vllm-project/aibrix
|
||||
|
||||
---
|
||||
|
||||
# AIBrix
|
||||
|
||||
欢迎使用 AIBrix，一个开源项目，旨在为构建可扩展的 GenAI 推理基础设施提供必要的构建模块。AIBrix 提供了一种云原生解决方案，专门针对企业需求优化，用于部署、管理和扩展大语言模型（LLM）推理。
|
||||
|
||||
相关链接：[Documentation](https://aibrix.readthedocs.io/latest/) | [Blog](https://aibrix.github.io/) | [White Paper](https://arxiv.org/abs/2504.03648) | [Twitter/X](https://x.com/vllm_project) | [Developer Slack](https://vllm-dev.slack.com/archives/C08EQ883CSV)
|
||||
|
||||
## 最新动态（Latest News）
|
||||
|
||||
### 版本发布（Releases）
|
||||
- **[2026-06-16]** AIBrix v0.7.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.7.0) 和 [Blog Post](https://aibrix.github.io/posts/2026-06-16-v0.7.0-release/) 了解详情。
|
||||
- **[2026-03-05]** AIBrix v0.6.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.6.0) 和 [Blog Post](https://aibrix.github.io/posts/2026-03-03-v0.6.0-release/) 了解详情。
|
||||
- **[2025-11-10]** AIBrix v0.5.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.5.0) 和 [Blog Post](https://aibrix.github.io/posts/2025-11-10-v0.5.0-release/) 了解详情。
|
||||
- **[2025-08-05]** AIBrix v0.4.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.4.0) 和 [Blog Post](https://aibrix.github.io/posts/2025-08-04-v0.4.0-release/) 了解详情。
|
||||
- **[2025-05-21]** AIBrix v0.3.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.3.0) 和 [Blog Post](https://aibrix.github.io/posts/2025-05-21-v0.3.0-release/) 了解详情。
|
||||
- **[2025-03-09]** AIBrix v0.2.1 发布。支持 DeepSeek-R1 全权重部署，并提升了网关稳定性！查看 [Blog Post](https://aibrix.github.io/posts/2025-03-10-deepseek-r1/) 了解详情。
|
||||
- **[2025-02-19]** AIBrix v0.2.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.2.0) 和 [Blog Post](https://aibrix.github.io/posts/2025-02-05-v0.2.0-release/) 了解详情。
|
||||
- **[2024-11-13]** AIBrix v0.1.0 发布。查看 [release notes](https://github.com/vllm-project/aibrix/releases/tag/v0.1.0) 和 [Blog Post](https://aibrix.github.io/posts/2024-11-12-v0.1.0-release/) 了解详情。
|
||||
|
||||
### 演讲与分享（Talks and Presentations）
|
||||
|
||||
- **[2025-11-12]** AIBrix 团队在 KubeCon North America 2025 联合发表主题演讲 [AIBrix: Kubernetes-native GenAI Inference Infrastructure](https://www.youtube.com/watch?v=7KHenRXNGAw&t=875s)，提供 AIBrix 概览。
|
||||
- **[2025-06-10]** AIBrix 团队在 KubeCon China 2025 发表演讲 [AIBrix: Cost-Effective and Scalable Kubernetes Control Plane for vLLM](https://kccncchn2025.sched.com/event/1x5im/introducing-aibrix-cost-effective-and-scalable-kubernetes-control-plane-for-vllm-jiaxin-shan-liguang-xie-bytedance)，讨论该框架如何通过 Kubernetes 优化 vLLM 部署以实现成本效益和可扩展性。
|
||||
- **[2025-04-04]** AIBrix 团队在 KubeCon EU 2025 与 Google 联合发表主题演讲 [LLM-Aware Load Balancing in Kubernetes: A New Era of Efficiency](https://kccnceu2025.sched.com/event/1txC7/keynote-llm-aware-load-balancing-in-kubernetes-a-new-era-of-efficiency-clayton-coleman-distinguished-engineer-google-jiaxin-shan-software-engineer-bytedance)，聚焦 LLM 特定路由解决方案。
|
||||
- **[2025-03-30]** AIBrix 在 [ASPLOS'25](http://asplos-conference.org/asplos2025/) 研讨会上展示 [AIBrix: An Open-Source, Large-Scale LLM Inference Infrastructure for System Research](https://docs.google.com/presentation/d/1YDVsPFTIgGXnROGaJ1VKuDDAB4T5fzpE/edit)，展示其在系统研究场景下高效 LLM 推理的架构。
|
||||
|
||||
## 核心特性（Key Features）
|
||||
|
||||
首个版本包含以下核心特性：
|
||||
|
||||
- **高密度 LoRA 管理**：对模型轻量级低秩适配的流式支持。
|
||||
- **LLM 网关与路由**：跨多个模型和副本高效管理和调度流量。
|
||||
- **面向 LLM 应用的定制化自动扩缩容器**：基于实时需求动态扩展推理资源。
|
||||
- **统一 AI 运行时**：一个多用途边车，支持指标标准化、模型下载和管理。
|
||||
- **分布式推理**：可扩展的架构，跨多个节点处理大规模工作负载。
|
||||
- **分布式 KV Cache**：支持高容量、跨引擎的 KV 复用。
|
||||
- **高性价比异构服务**：支持混合 GPU 推理，在 SLO 保证下降低成本。
|
||||
- **GPU 硬件故障检测**：主动检测 GPU 硬件问题。
|
||||
|
||||
## 架构（Architecture）
|
||||
|
||||
|
||||
|
||||
## 快速开始（Quick Start）
|
||||
|
||||
要开始使用 AIBrix，克隆此仓库并按照文档中的设置说明操作。综合指南将帮助您无缝配置和部署首个 LLM 基础设施。
|
||||
|
||||
```shell
|
||||
# 本地测试
|
||||
git clone https://github.com/vllm-project/aibrix.git
|
||||
cd aibrix
|
||||
|
||||
# 安装 nightly aibrix 依赖
|
||||
kubectl apply -k config/dependency --server-side
|
||||
|
||||
# 安装 nightly AIBrix CRDs（与 operator 分离，卸载时不会清除用户 CR）
|
||||
kubectl apply -k config/crd --server-side
|
||||
|
||||
# 安装 nightly aibrix 组件
|
||||
kubectl apply -k config/default
|
||||
```
|
||||
|
||||
安装稳定版本：
|
||||
|
||||
```shell
|
||||
# 安装组件依赖
|
||||
kubectl apply -f "https://github.com/vllm-project/aibrix/releases/download/v0.7.0/aibrix-dependency-v0.7.0.yaml" --server-side
|
||||
|
||||
# 安装 AIBrix CRDs（与 operator 分离，卸载时不会清除用户 CR）
|
||||
kubectl apply -f "https://github.com/vllm-project/aibrix/releases/download/v0.7.0/aibrix-core-crds-v0.7.0.yaml" --server-side
|
||||
|
||||
# 安装 aibrix 组件
|
||||
kubectl apply -f "https://github.com/vllm-project/aibrix/releases/download/v0.7.0/aibrix-core-v0.7.0.yaml"
|
||||
```
|
||||
|
||||
## 文档（Documentation）
|
||||
|
||||
关于安装、配置和使用的详细文档，请访问[文档页面](https://aibrix.readthedocs.io/latest/)。
|
||||
|
||||
## 贡献（Contributing）
|
||||
|
||||
欢迎社区贡献！查看[贡献指南](./CONTRIBUTING.md)了解如何参与。
|
||||
|
||||
Slack 频道：[#aibrix](https://vllm-dev.slack.com/archives/C08EQ883CSV)
|
||||
|
||||
## 许可证（License）
|
||||
|
||||
AIBrix 基于 [Apache 2.0 License](LICENSE) 许可。
|
||||
|
||||
## 支持（Support）
|
||||
|
||||
如有任何疑问或问题，请在 [GitHub issues 页面](https://github.com/vllm-project/aibrix/issues) 提交 issue。
|
||||
|
||||
感谢您选择 AIBrix 满足您的 GenAI 基础设施需求！
|
||||
|
||||
---
|
||||
|
||||
> 仓库结构摘要（README 原文）：`api/`（autoscaling/model/orchestration）、`apps/`（chat/console）、`benchmarks/` + `brixbench/`（基准测试）、`cmd/`（controllers/kvcache-watcher/plugins）、`config/`（crd/default/dependency 等）、`deployment/`（local/standalone/terraform）、`docs/`、`pkg/`（controller/kvevent/plugins 等 Go 包）、`python/`（aibrix/aibrix_kvcache）、`samples/`（disaggregation、deepseek-r1、kvcache、autoscaling 等示例）、`test/`（e2e/integration/regression）。
|
||||
@@ -0,0 +1,85 @@
|
||||
# 📊 文章摘要：AIBrix：云原生 GenAI 推理基础设施（字节跳动开源）
|
||||
|
||||
> **原文**：[2026-06-16_AIBrix_云原生推理.md](./2026-06-16_AIBrix_云原生推理.md)
|
||||
> **原文链接**：https://github.com/vllm-project/aibrix
|
||||
> **来源**：GitHub（vllm-project 组织托管）
|
||||
> **作者**：字节跳动（ByteDance）
|
||||
> **发布日期**：2026-06-16
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **云原生推理基建** — 以 Kubernetes 控制平面 + 智能网关 + 分布式 KV Cache 为三支柱，为大规模 LLM 推理提供"LLM 感知"的部署、路由与扩缩容能力。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 AIBrix 项目的 GitHub README（截至 v0.7.0 发布），内容包括：v0.1.0 至 v0.7.0 的完整版本发布历史（2024-11 至 2026-06）、KubeCon NA/CN/EU 与 ASPLOS'25 的演讲记录、八大核心特性（高密度 LoRA 管理、LLM 网关与路由、LLM 定制化自动扩缩、统一 AI 运行时边车、分布式推理、分布式 KV Cache、异构 GPU 混合服务、GPU 硬件故障检测）、kubectl 一键安装方式与仓库结构。其价值在于：以可核验的发布节奏与社区活动勾勒出字节跳动在云原生推理领域的技术布局，特性清单可作为同类平台功能对照表。局限在于：README 为宣传型文档，核心特性均为能力清单而无任何性能基准、架构细节或生产数据，"成本效益""高性价比"等表述无证据支撑。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **发布节奏反映产品成熟度** — 2024-11 至 2026-06 共 8 个版本（0.1.0→0.7.0，约每 3-4 个月一版），v0.2.1 即支持 DeepSeek-R1 全权重部署，迭代速度快、生态活跃度可验证。 `[分类: 共识]`
|
||||
|
||||
2. **三支柱能力框架** — LLM 感知的网关路由（前缀感知/负载感知）、基于实时需求的自动扩缩、分布式 KV Cache 跨节点复用，与 llm-d、Dynamo 的组件画像高度重合，印证行业"路由 + 缓存 + 弹性"三要素共识。 `[分类: 共识]`
|
||||
|
||||
3. **K8s + Ray 混合编排** — 文档及演讲（KubeCon China 2025）揭示其用 Kubernetes 管集群、用 Ray 执行细粒度任务的混合调度思路，是字节大规模算力治理经验的工程化表达。 `[分类: 范式突破]`
|
||||
|
||||
4. **学术与社区背书** — 托管于 vllm-project 组织、白皮书公开于 arXiv（2504.03648）、ASPLOS'25 研讨会展示、多次 KubeCon 主题演讲（含与 Google 联合），可信度高于一般个人项目。 `[分类: 共识]`
|
||||
|
||||
5. **宣传口径与证据落差** — "高性价比异构服务""GPU 硬件故障检测"等特性均无基准数据、无原理说明，README 无法支撑任何性能或成本结论；分布式 KV Cache 与 SLO 优化器的实际效果需查阅白皮书与源码验证。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 假设部署环境以 Kubernetes 为基底（全部安装通过 kubectl/CRD 完成），并认可 Operator/CRD 模式；
|
||||
- 假设"LLM 感知路由 + 分布式 KV 复用"在网关层集中实现的扩展性成立（与 llm-d 相同的未验证问题）；
|
||||
- 假设异构 GPU 混部能在 SLO 保证下真正降本——这是其"成本效益"宣称的核心前提，README 未提供证据。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 文档的论据全部为"事实性存在"类：版本号、演讲链接、白皮书 arXiv 号均真实可核验，构成项目可信度的有效证据；但对"性能与效果"类结论（成本降低、扩展性、故障检测有效性）零论据支撑，属于典型的工程宣传文档——论据质量呈现"存在性高、效果性无"的剪刀差。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 适用场景：已有 K8s 集群、需要为 vLLM 部署补齐网关/扩缩容/KV 复用能力的企业级团队；作为 LLM 推理平台功能清单的行业参照。
|
||||
- 不适用于：无 K8s 环境、单机小规模部署、以及需要严格基准对比后才能决策的场景（需转向白皮书）。
|
||||
- 项目定位受限于 vLLM 生态深度绑定，非 vLLM 引擎（如 SGLang/TensorRT-LLM）的支持程度未在本文说明。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "AIBrix 提供了一种云原生解决方案，专门针对企业需求优化，用于部署、管理和扩展大语言模型（LLM）推理。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 发布历史、演讲记录、白皮书链接构成可核验的项目进展证据链，是跟踪 AIBrix 动态的一手材料
|
||||
- 特性清单完整覆盖行业热点（LoRA、前缀路由、KV 复用、异构混部、故障检测），可作功能对照表
|
||||
- 字节跳动 + vllm-project 双背书，社区可信度较高
|
||||
|
||||
**不足**：
|
||||
- 无任何性能基准、架构原理与生产案例，效果类宣称无法验证
|
||||
- 特性描述停留在名词层面（如"GPU 硬件故障检测"仅一句话），无法支撑深入评估
|
||||
- 与 vLLM 生态的绑定程度、异构混部降本的具体路径均未展开
|
||||
|
||||
**适用场景**：关注云原生 LLM 推理平台选型的架构师（作为候选名单与功能对照）；K8s 团队借鉴其能力框架；追踪字节开源技术动向的研究者。
|
||||
|
||||
**关联建议**：阅读其 arXiv 白皮书（2504.03648）获取架构与基准细节；与 llm-d（CNCF Sandbox）、NVIDIA Dynamo 做三方案横向对比；结合 cr7258《Lesson 06》中 AIBrix 章节理解其 PD 分离支持方式。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,130 @@
|
||||
# 基于 Prefill/Decode 分离的大规模推理 Serving 架构
|
||||
|
||||
> **来源**：H3C 新华三官网（《数字化领航》AI应用专刊）
|
||||
> **作者**：未知（未署名）
|
||||
> **发布日期**：2026-04-27
|
||||
> **原文链接**：https://www.h3c.com/cn/d_202604/2832717_233453_0.htm
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
随着大语言模型（LLM）在MaaS（Model as a Service）场景下的广泛应用，服务端面临着极其复杂的流量特征：极端的变长输入、突发的并发请求以及严格的延迟SLA（TTFT与TPOT）。传统的整体式推理架构在处理这些挑战时，往往受限于显存碎片化和计算/访存特性的冲突，难以兼顾高吞吐与低时延。本文探讨了一种基于Prefill/Decode（PD）分离的解耦式Serving架构，重点分析了如何利用PD分离部署结合智能路由、全局KVCache管理及专家并行（EP）等关键技术，解决大规模部署中的资源瓶颈，提出了一套能够最大化GPU利用率并有效应对高并发的系统级解决方案。
|
||||
|
||||
## 关键词
|
||||
|
||||
大规模推理部署；高并发；Serving架构；PD分离；KV Cache优化
|
||||
|
||||
## 引言
|
||||
|
||||
大模型推理的本质是由两个截然不同的阶段组成的：Prefill（预填充）阶段和Decode（解码）阶段。
|
||||
|
||||
**◆Prefill阶段：**处理输入的Prompt，是一次性的计算密集型（Compute-bound）任务，对算力要求极高，注重吞吐。
|
||||
|
||||
**◆Decode阶段：**逐Token生成回复，是内存带宽密集型（Memory-bound）任务，受限于显存带宽，注重时延。
|
||||
|
||||
图1 大模型推理过程的两个阶段
|
||||
|
||||
在传统的Continuous Batching（连续批处理）架构中，Prefill和Decode任务混合运行在同一张GPU上。当并发量激增且请求长度差异巨大时，Prefill任务会显著抢占计算资源，导致正在Decode的请求出现明显的卡顿（Inter-token latency增加）。同时，KV Cache的显存占用随着并发数线性增长，极易触发OOM（Outof Memory），限制了系统的最大并发数。
|
||||
|
||||
为了解决上述MaaS场景下的核心痛点，PD分离（Prefill-DecodeDisaggregation）架构应运而生。本文将阐述该架构的设计原理及其在DeepSeekV3等大规模MoE模型部署中的深度优化实践。
|
||||
|
||||
## 1 Prefill/Decode分离架构原理与核心优势
|
||||
|
||||
### 1.1 解耦设计的理论基础
|
||||
|
||||
PD分离的核心思想是将推理集群划分为两类独立的实例池：
|
||||
|
||||
**1）Prefill实例池：**专门负责Prompt处理，计算出KV Cache。该池通常配置高算力利用率的调度策略。
|
||||
|
||||
**2）Decode实例池：**专门负责Token生成。该池通过接收Prefill阶段生成的KVCache，专注于低延迟的Token输出。
|
||||
|
||||
### 1.2 架构协同流程
|
||||
|
||||
在一个典型的优化后架构中，处理流程如下：
|
||||
|
||||
**1）请求接入：**流量经过网关进入全局调度器（Global Scheduler）。
|
||||
|
||||
**2）Prefill计算：**调度器将请求分发至Prefill节点，节点快速并行计算，生成KV Cache。
|
||||
|
||||
**3）KV传输：**通过高速互联网络（如RDMA、NVLink）将KVCache从Prefill节点传输至选定的Decode节点。
|
||||
|
||||
**4）Decode生成：**Decode节点加载KVCache，开始自回归生成，直至结束。
|
||||
|
||||
图2 PD分离架构下请求处理过程
|
||||
|
||||
这种分离彻底消除了Prefill计算对Decode生成的干扰，使得我们可以针对两个阶段不同的硬件特性（计算密集 vs 访存密集）进行异构硬件选型或独立的参数调优。
|
||||
|
||||
## 2 Serving架构的深度优化：迈向极致性能
|
||||
|
||||
仅实现物理上的分离不足以应对大规模高并发，必须引入系统级的深度优化。我们重点探讨以下关键技术。
|
||||
|
||||
### 2.1 智能路由与全局调度 (Smart Routing)
|
||||
|
||||
在MaaS场景下，请求并非无状态。为了提高缓存命中率，调度器必须具备"记忆"能力。
|
||||
|
||||
**◆KV Cache-Aware Routing（KV Cache感知路由）：**调度器维护全局的KVCache分布表。当一个新的请求包含常见的前缀（如System Prompt或多轮对话的历史记录）时，智能路由会将该请求分发到已经存有该前缀KV Cache的节点上。
|
||||
|
||||
**◆负载感知均衡策略：**调度器需实时预测各节点的显存水位和计算负载，在"缓存亲和性"与"负载均衡"之间寻找最优解，避免热点节点过载。
|
||||
|
||||
图3 缓存、负载感知调度流程示意
|
||||
|
||||
### 2.2 极致的KV Cache管理：前缀缓存与卸载
|
||||
|
||||
KV Cache是推理过程中最大的显存开销，也是PD分离中传输的瓶颈。
|
||||
|
||||
**◆前缀缓存（Prefix Caching / Radix Attention）：**
|
||||
|
||||
利用基数树（Radix Tree）结构管理KV Cache。对于多轮对话或RAG（检索增强生成）场景，大量Prompt具有公共前缀。系统通过Radix Attention机制，自动匹配并复用显存中已有的KV块，通过减少重复计算（Re-computation）大幅降低TTFT（首字延迟）。
|
||||
|
||||
**◆KV Cache 卸载（Offloading）：**
|
||||
|
||||
当高并发导致GPU显存不足时，传统的做法是驱逐（Evict）缓存。优化后的架构引入多级存储层次：GPU HBM→Host RAM→SSD。利用PCIe带宽，将暂时不活跃的KVCache卸载到CPU内存，需要时再快速预取（Prefetch）。这使得单卡支持的并发容量提升了数倍。
|
||||
|
||||
图4 多级KV Cache缓存卸载示意
|
||||
|
||||
### 2.3 高效通信与流水线掩盖
|
||||
|
||||
PD分离引入了额外的KV传输开销。为了掩盖这一延迟，系统设计必须做到通信与计算的重叠（Overlap）。
|
||||
|
||||
**◆分层分块传输：**在Prefill计算过程中，不等待全部层计算完毕，而是采用流水线方式，计算完一层（Layer）即传输一层，使得Decode节点可以尽早开始加载数据。
|
||||
|
||||
**◆传输协议优化：**基于RDMA技术优化传输协议，绕过CPU直接在GPU显存间传输数据，减少系统调用开销。
|
||||
|
||||
## 3 应对超大模型：大EP专家并行与MoE优化
|
||||
|
||||
对于如DeepSeek-V3/R1这类采用混合专家（MoE）架构的超大模型，参数量巨大（如671B），单卡无法容纳，且计算模式更为稀疏。
|
||||
|
||||
### 3.1 大EP（Expert Parallelism）专家并行
|
||||
|
||||
在混合专家（MoE）架构中，每个Token只激活少部分专家。为了解决通信瓶颈，架构采用了大规模专家并行：
|
||||
|
||||
**◆专家分布：**将不同的专家网络分布在不同的GPU甚至不同的节点上，针对SharedExperts（共享专家）进行特殊处理，确保这些高频访问的参数常驻高速缓存。
|
||||
|
||||
**◆All-to-All通信优化：**在推理过程中，Token需要被路由到特定的专家所在的GPU进行计算，计算后再汇聚。这产生的大量All-to-All通信，通过优化算子和网络拓扑感知（Topology-aware）路由进行加速，确保高并发下的通信不阻塞计算。
|
||||
|
||||
### 3.2 专家间负载均衡 (EPLB)
|
||||
|
||||
在混合专家（MoE）架构的推理中，大规模并发下，会导致显著的负载不均衡。例如，在处理大量编程类请求时，负责"代码生成"的专家所在的 GPU 会成为计算热点，而其他处理通用文本的 GPU 则处于空闲状态。这会导致整个 Batch 的推理延迟取决于最慢的那个 GPU，严重拖累 TPOT（Token Per Output Token）。
|
||||
|
||||
为了解决这一问题，系统引入了EPLB（Expert Parallelism Load Balancing） 机制，从系统层面动态抹平计算负载：
|
||||
|
||||
**1）基于预测的动态冗余（PredictiveDynamic Redundancy）：**
|
||||
|
||||
传统的 EP 策略通常是静态分配专家。EPLB 机制引入了"热点漂移"监测。Serving系统会实时统计滑动窗口内的专家激活热度图（Heatmap）。当识别到特定专家（Hot Expert）的访问频率持续超过阈值时，系统会利用闲置的显存资源，在低负载的GPU节点上动态复制该专家的权重副本。调度器随后将部分Token路由至副本节点，通过多路冗余计算消除单点瓶颈。
|
||||
|
||||
**2）通信感知的全局规约优化：**
|
||||
|
||||
在专家并行中，Token的Dispatch（分发）和 Combine（汇聚）涉及海量的All-to-All通信。EPLB不仅均衡计算，还均衡通信量。通过感知网络拓扑，EPLB 算法会尽量将激活相同专家的Token打包，或者优先调度位于同一 NVLink 域内的专家请求，减少跨节点的 RDMA 通信开销，确保计算密集型与通信密集型任务在时间轴上的完美交错（Overlap）。
|
||||
|
||||
## 4 动态自适应资源调度
|
||||
|
||||
现代Serving架构不仅是静态的执行引擎，更是动态的调节系统。
|
||||
|
||||
◆动态配额调整：系统根据实时流量监控和实例上报的Metric指标动态伸缩实例个数。同时，在没有额外资源时，实现PD实例角色转换，闲置P实例可转为D实例（反之亦然），智能调整PD配比，实现资源复用。
|
||||
|
||||
图5 PD实例动态伸缩与转换示意
|
||||
|
||||
## 5 结束语
|
||||
|
||||
面对MaaS场景下的大规模AI推理挑战，单一的技术手段已无法满足需求。通过Prefill/Decode分离架构的落地，配合智能路由、前缀缓存（Radix Attention）、KV Cache卸载以及针对MoE模型的大EP并行策略和EPLB专家负载均衡策略，可以构建一套高吞吐、低时延的现代化Serving系统。这种系统级优化方案，可成功将GPU利用率提升至新的高度，解决了高并发下的资源争抢问题，为万亿参数时代的实时AI应用提供了坚实的算力底座。
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：基于 Prefill/Decode 分离的大规模推理 Serving 架构
|
||||
|
||||
> **原文**：[2026-04-27_基于_Prefill_Decode_分离的大规模推理_Serving_架构.md](./2026-04-27_基于_Prefill_Decode_分离的大规模推理_Serving_架构.md)
|
||||
> **原文链接**：https://www.h3c.com/cn/d_202604/2832717_233453_0.htm
|
||||
> **来源**：H3C 新华三官网（《数字化领航》AI应用专刊）
|
||||
> **作者**：未知（未署名）
|
||||
> **发布日期**：2026-04-27
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **系统解耦** — 把 PD 分离扩展为"智能路由 + 全局 KV 管理 + 通信流水线 + 大 EP/EPLB + 动态调度"的 Serving 系统级组合方案，面向 MoE 超大模型。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文从 MaaS 场景高并发、变长输入与严格延迟 SLA 的痛点出发，论证"仅实现物理分离不足以应对大规模高并发"，须叠加系统级优化：KV Cache 感知的智能路由与负载感知均衡、Radix Attention 前缀缓存、HBM→Host RAM→SSD 多级 KV 卸载、分层分块传输与 RDMA 掩盖开销；并针对 DeepSeek-V3 类 MoE 模型引入大 EP 专家并行与 EPLB 负载均衡（热点漂移监测、预测动态冗余、通信感知规约），最后以 PD 实例动态伸缩与 P/D 角色转换收尾。重要在于给出了"PD 分离 × 专家并行"的完整架构清单，其中 EPLB 与实例角色转换是同类文章中少见的机制。局限：全文无量化数据与可复现配置，宣称收益无法验证。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **双实例池架构** — Prefill 实例池（计算密集、注重吞吐）与 Decode 实例池（访存密集、注重时延）解耦，消除干扰并支持异构硬件选型 `[分类: 共识]`
|
||||
2. **KV 感知智能路由** — 调度器维护全局 KV Cache 分布表，在缓存亲和性与负载均衡之间寻优，避免热点节点过载 `[分类: 共识]`
|
||||
3. **前缀缓存与多级卸载** — Radix Attention 复用公共前缀降低 TTFT；KV 卸载至 Host RAM/SSD 并预取，单卡并发容量提升数倍 `[分类: 共识]`
|
||||
4. **通信与计算重叠** — 逐层流水线传输（算完一层传一层）+ RDMA 绕过 CPU，掩盖 KV 传输延迟 `[分类: 共识]`
|
||||
5. **大 EP 专家并行** — MoE 专家分散多卡、共享专家常驻高速缓存、All-to-All 通信拓扑感知优化 `[分类: 共识]`
|
||||
6. **EPLB 专家负载均衡** — 滑动窗口专家激活热度图监测 + 动态复制热点专家权重做冗余 + 通信感知全局规约，消除"最慢 GPU 拖累 TPOT" `[分类: 未探索]`
|
||||
7. **动态自适应调度** — 实例按流量伸缩，闲置 P 实例可转 D 实例（反之亦然），智能调整 PD 配比实现资源复用 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设集群规模大到实例池与动态伸缩有意义；假设 RDMA/NVLink 网络与多级存储（HBM/RAM/SSD）就绪；立论默认聚焦 MoE 超大模型（671B 级），中小模型场景不在讨论范围。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
"痛点→分离→组件优化"的逻辑链完整，但几乎全为定性论述：无吞吐、时延、并发数等量化证据，"提升数倍""新的高度"等表述无法证伪；EPLB 冗余复制的代价（显存占用、权重一致性）也未量化。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
厂商方案视角，未与 vLLM/Mooncake 等开源社区方案对比；非 MoE 或小规模场景的适用性未讨论；实例角色转换的状态迁移与 KV 归属等工程代价未展开；作者未署名，权威性有限。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "调度器需实时预测各节点的显存水位和计算负载，在'缓存亲和性'与'负载均衡'之间寻找最优解，避免热点节点过载。"
|
||||
|
||||
> "现代Serving架构不仅是静态的执行引擎，更是动态的调节系统。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- "PD 分离 + MoE 专家并行"的组合视角少见，EPLB 机制描述具体
|
||||
- 覆盖路由、缓存、卸载、通信、调度全组件，可作系统设计清单
|
||||
- 明确指向 DeepSeek-V3 等万亿级 MoE 部署场景
|
||||
|
||||
**不足**：
|
||||
- 无任何量化数据，收益宣称无法验证
|
||||
- 未与开源方案对比，缺乏可复现配置
|
||||
- 各组件仅概念级描述，工程深度不足
|
||||
|
||||
**适用场景**：Serving 架构师构思 MoE 大模型系统级优化方案时的组件清单参考。
|
||||
|
||||
**关联建议**：对照 DeepSeek-V3 技术报告中 EPLB 与 PD 分离章节；阅读 Mooncake 论文获取以 KV 为中心调度的实证数据。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,104 @@
|
||||
# 推理单位经济学：每百万Token的真实成本
|
||||
|
||||
> **来源**：Introl
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-02-09
|
||||
> **原文链接**：https://introl.com/zh/blog/inference-unit-economics-true-cost-per-million-tokens-guide
|
||||
|
||||
---
|
||||
|
||||
*更新于2025年12月8日*
|
||||
|
||||
**2025年12月更新：** 大语言模型推理成本以每年10倍的速度下降——比PC计算能力或互联网泡沫时期的带宽下降更快。GPT-4同等性能的成本从2022年底的每百万token 20美元降至现在的0.40美元。云端H100价格在从峰值下跌64-75%后稳定在2.85-3.50美元/小时。DeepSeek以比行业领先者低90%的定价颠覆了市场。自托管部署的收支平衡点：7B模型需要50%以上的GPU利用率，13B模型需要10%以上。量化技术可降低60-70%的运营成本。推测解码将延迟降低2-3倍。
|
||||
|
||||
大语言模型推理市场打破了传统的技术经济学规律。价格下降速度超过了微处理器革命时期的PC计算能力或互联网泡沫时期的带宽——同等性能的成本每年下降10倍。¹ 2022年底每百万token需要20美元的能力，现在只需0.40美元。² 然而，组织仍然难以理解其真实的推理成本，因为token级别的定价掩盖了基础设施的现实，GPU利用率决定了实际的单位经济效益，而优化技术带来了数量级的成本效率差异。掌握推理经济学决定了AI部署是创造价值还是消耗资本。
|
||||
|
||||
## 2025年12月的推理定价格局
|
||||
|
||||
API定价因模型能力、提供商和优化程度的不同而跨越三个数量级。了解当前格局为经济决策提供了背景。
|
||||
|
||||
**经济型模型**现在每百万token只需几分之一美分。Google的Gemini Flash-Lite以每百万输入token 0.075美元和每百万输出token 0.30美元领先。³ 通过Together.ai或Hyperbolic等提供商使用的开源模型价格更低——Llama 3.2 3B每百万token仅需0.06美元，MMLU得分42，成本仅为三年前的千分之一。⁴
|
||||
|
||||
**中端生产模型**在能力和成本之间取得平衡。Claude Sonnet 4每百万输入token定价3美元，每百万输出token 15美元。⁵ DeepSeek的R1模型以每百万输入token 0.55美元和输出token 2.19美元的价格颠覆了市场——在具备相当推理能力的情况下，比西方竞争对手低90%。⁶ 中国提供商持续以更低的价格挑战西方领先者，引入的价格压力使所有买家受益。
|
||||
|
||||
**前沿能力模型**定价较高。Claude Opus 4每百万输入token 15美元，每百万输出token 75美元。⁷ GPT-4和类似的前沿模型定价相近，其合理性在于这些能力是较小模型无论如何优化成本都无法复制的。
|
||||
|
||||
**提供商差异**增加了复杂性。对于相同的模型，最便宜和最贵的提供商之间价格相差10倍。⁸ 同一个模型可能在最便宜的提供商处每百万token 0.90美元，中位数为3.50美元，最贵的为9.50美元。在进行任何技术优化之前，跨提供商比价就能显著影响经济效益。
|
||||
|
||||
**输出token定价不对称**反映了实际成本。OpenAI、Anthropic和Google对输出token的定价比输入token高3-5倍，因为输出生成需要顺序处理，而输入处理可以高效并行。⁹ 生成长输出的应用与处理长输入但仅需简短回复的应用面临不同的经济学。
|
||||
|
||||
## 理解真实的GPU基础设施成本
|
||||
|
||||
API定价背后是具有自身成本结构的GPU基础设施。理解这些经济学能够做出明智的自建与购买决策。
|
||||
|
||||
**硬件采购成本**起点很高且持续累积。NVIDIA H100 GPU每张卡售价25,000-40,000美元，包含基础设施的完整8-GPU服务器系统达到200,000-400,000美元。¹⁰ NVIDIA每张H100的制造成本约为3,320美元——生产成本与销售价格之间的差距反映了需求驱动的利润率，这一利润率直到最近才开始缓和。
|
||||
|
||||
**云端GPU租赁价格**在大幅下降后趋于稳定。H100 SXM实例的价格从1.49美元/小时（Hyperbolic）到6.98美元/小时（Azure）不等，大多数提供商在从峰值下降64-75%后集中在2.85-3.50美元/小时。¹¹ 预留容量可进一步降低费率——Lambda Labs提供1.85美元/小时，Hyperstack承诺起价1.90美元/小时。
|
||||
|
||||
**电力和冷却成本**使硬件费用进一步增加。每张H100在负载下消耗高达700W。多GPU集群需要专用配电单元，设施升级可能花费10,000-50,000美元。¹² 液冷基础设施或增强型暖通空调系统根据规模增加15,000-100,000美元。这些成本分摊到GPU使用时间中，但显著影响总拥有成本的经济性。
|
||||
|
||||
**运营开销**弥合了硬件租赁与实际成本之间的差距。考虑冷却、设施和维护因素后，原始GPU租赁费率每小时增加约2-7美元，使8×H100的真实运营成本在正确分摊后达到8-15美元/小时。¹³ 比较云端租赁与API定价的组织必须包含这些隐性成本才能进行有效比较。
|
||||
|
||||
## 决定可行性的利用率方程
|
||||
|
||||
GPU利用率决定了自托管推理是否具有经济意义。为运行在10%负载的GPU付费会将每千token 0.013美元转变为0.13美元——比高端API还贵。¹⁴
|
||||
|
||||
**收支平衡分析**取决于模型大小和利用率目标。托管7B模型大约需要50%的利用率才能比GPT-3.5 Turbo更便宜。¹⁵ 13B模型仅需10%的利用率即可实现与GPT-4-turbo的成本持平，因为较大模型的能力溢价证明了更高的基础设施投资是合理的。关键洞察：较大模型在较低利用率下即可实现收支平衡，因为它们替代的是更昂贵的API替代方案。
|
||||
|
||||
**流量模式**决定了可实现的利用率。工作负载一致且可预测的组织比需求零散的组织能实现更高的利用率。具有日常流量周期的面向消费者的应用在非高峰时段会浪费GPU容量，除非工作负载可以转移或基础设施可以动态扩展。
|
||||
|
||||
**请求量阈值**确立了最小可行规模。分析表明，每天需要超过8,000次对话，自托管基础设施的成本才会低于托管解决方案。¹⁶ 低于此阈值，自托管的运营复杂性和固定成本将超过潜在节省。
|
||||
|
||||
**批处理机会**改善了利用率经济性。拥有可延迟工作负载的组织——离线分析、批量嵌入、数据集处理——可以将需求聚合到高利用率窗口中，即使实时流量变化也能提高有效利用率。在共享基础设施上混合实时和批处理工作负载可优化资本效率。
|
||||
|
||||
## 生产部署的成本结构分解
|
||||
|
||||
生产推理成本分解为可单独优化的组成部分。
|
||||
|
||||
**模型加载和内存**无论流量多少都消耗固定资源。FP16格式的70B参数模型大约需要140GB GPU内存——超过单GPU容量，因此无论流量多少都必须采用多GPU配置。¹⁷ 内存成本随模型大小而非使用量扩展，创造了与流量无关的最低基础设施门槛。
|
||||
|
||||
**每token计算**驱动推理过程中的边际成本。前向传播计算随模型架构扩展——特别是长上下文的注意力机制。计算成本随批处理而下降，因为矩阵运算在较大批量大小时变得更高效，将开销分摊到更多token上。
|
||||
|
||||
**KV缓存内存**随上下文长度和并发请求增长。每个活动请求维护的键值缓存消耗与上下文长度成正比的内存。长上下文应用面临内存压力，限制并发请求，降低吞吐量并增加每token成本。KV缓存管理是主要的优化目标。
|
||||
|
||||
**网络和存储I/O**影响多GPU和分布式部署。用于张量并行的GPU间通信、从存储加载模型权重以及传输结果都消耗资源。高带宽网络（NVLink、InfiniBand）减少I/O瓶颈，但增加基础设施投资。
|
||||
|
||||
**运营开销**包括监控、日志记录、安全和管理。生产系统需要可观测性基础设施、值班人员和持续的优化工作。组织在比较自托管与API替代方案时经常低估这些"软"成本。
|
||||
|
||||
## 改变经济性的优化技术
|
||||
|
||||
技术优化可以将推理成本降低60-70%甚至更多，将边际经济转变为可持续的优势。¹⁸
|
||||
|
||||
**量化**将模型权重的精度从32位浮点数减少到8位或4位表示。该技术将模型大小缩小4-8倍，同时保持可接受的准确性。¹⁹ 8位量化减少50%的内存使用，准确性损失约1%。4位量化实现75%的大小减少，同时在许多应用中保持有竞争力的性能。Blackwell GPU的FP4支持使仅通过量化即可实现4倍性能提升。
|
||||
|
||||
**连续批处理**动态分组请求，而不是等待固定批次完成。传统批处理等待最长序列完成后才处理新请求。连续批处理立即驱逐已完成的序列，并在其他序列仍在处理时开始新请求。²⁰ 该技术显著提高了序列长度变化的工作负载的GPU利用率——这正是大多数生产部署展现的模式。
|
||||
|
||||
**推测解码**使用小型"草稿"模型预测多个token，然后由较大的"验证"模型并行检查。²¹ 当预测正确时，每次前向传播生成多个token而非标准的单个token。该技术将延迟降低2-3倍，适用于小型模型能准确预测较大模型输出的应用——对于受限领域或结构化输出特别有效。
|
||||
|
||||
**KV缓存优化**包括PagedAttention像虚拟内存一样管理缓存内存，减少碎片化并实现更高的并发性。²² 缓存压缩技术进一步减少内存占用。前缀缓存在请求共享公共前缀时避免重新计算——对于具有结构化提示或系统指令的应用很有价值。
|
||||
|
||||
**模型蒸馏**创建针对特定领域近似较大模型行为的较小模型。针对目标任务匹配GPT-4性能的蒸馏7B模型以很小的基础设施成本运行，同时保持与应用相关的质量。²³ 蒸馏需要前期训练投资，但能产生持续的推理节省。
|
||||
|
||||
这些技术组合会产生复合效果。应用量化（4倍）、连续批处理（2倍）和推测解码（2倍）的组织可能比原始部署实现16倍的有效成本降低——将看似边际的经济性转变为实质性优势。
|
||||
|
||||
## API与自托管决策框架
|
||||
|
||||
自建与购买的决策取决于简单成本比较之外的因素。
|
||||
|
||||
**在以下情况选择API推理：**
|
||||
- 流量零散或不可预测
|
||||
- 每天的对话量低于8,000次
|
||||
- 工程能力有限
|
||||
- 快速迭代模型选择有价值
|
||||
- 合规要求可通过提供商认证满足
|
||||
- 延迟要求与提供商SLA匹配
|
||||
|
||||
**在以下情况选择自托管：**
|
||||
- 流量一致且数量大
|
||||
- GPU利用率可持续超过50%
|
||||
- 数据主权阻止使用云端API
|
||||
- 定制模型需要专门的服务
|
||||
- 延迟要求超过提供商能力
|
||||
- 成本优化证明工程投资是合理的
|
||||
|
||||
**混合方法**通常证明是最优的。组织将基准（注：原文结尾部分在抓取时被截断，此处为已获取内容的末尾。）
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：推理单位经济学：每百万Token的真实成本
|
||||
|
||||
> **原文**：[2026-02-09_推理单位经济学_每百万Token的真实成本.md](./2026-02-09_推理单位经济学_每百万Token的真实成本.md)
|
||||
> **原文链接**：https://introl.com/zh/blog/inference-unit-economics-true-cost-per-million-tokens-guide
|
||||
> **来源**：Introl
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-02-09
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **推理算账** — token 级别的定价掩盖了基础设施现实，真实推理成本由 GPU 利用率与优化技术决定，掌握推理经济学决定 AI 部署是创造价值还是消耗资本。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文系统拆解 LLM 推理的单位经济账：同等性能成本以每年约 10 倍速度下降，从 2022 年底每百万 token 20 美元降至 0.40 美元；逐一量化 API 定价格局、GPU 硬件与云租成本、电力和运营开销，提出"利用率方程"（7B 模型需 50% 利用率、13B 模型仅需 10% 即可自托管收支平衡，日均 8000 次对话为最小可行阈值），并说明量化、连续批处理、推测解码、KV 缓存优化、蒸馏等技术的复合效应可带来 16 倍成本降低，最后给出 API 与自托管的决策框架。价值在于把成本决策从感觉变为可计算的框架。局限：原文结尾被抓取截断，且价格数据时效性强，使用时需更新。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **成本年降 10 倍** — 推理成本下降快于 PC 算力与互联网带宽的历史速度；GPT-4 同等性能从 20 美元降至 0.40 美元/百万 token `[分类: 共识]`
|
||||
2. **API 定价三分格局** — 经济型（Gemini Flash-Lite 输入 0.075/输出 0.30 美元）、中端（Claude Sonnet 4 为 3/15 美元，DeepSeek R1 0.55/2.19 美元、比西方低 90%）、前沿（Claude Opus 4 为 15/75 美元）`[分类: 共识]`
|
||||
3. **输出 token 定价不对称** — 输出贵 3-5 倍源于输出顺序生成、输入可并行处理的实际成本差异 `[分类: 共识]`
|
||||
4. **利用率决定自托管可行性** — 10% 利用率使每千 token 0.013 美元的成本放大 10 倍至 0.13 美元，超过高端 API `[分类: 共识]`
|
||||
5. **收支平衡点与模型大小相关** — 7B 需 50% 利用率、13B 仅需 10%，因为大模型替代的是更贵的 API 替代方案 `[分类: 共识]`（数值依赖对标价格假设）
|
||||
6. **日均 8000 次对话阈值** — 低于此规模自托管的固定成本与运维复杂性超过节省 `[分类: 共识]`
|
||||
7. **优化技术复合效应** — 量化（4 倍）×连续批处理（2 倍）×推测解码（2 倍）可达 16 倍有效成本降低；Blackwell FP4 使量化带来 4 倍性能提升 `[分类: 共识]`
|
||||
8. **决策框架** — 流量零散/低于阈值/工程能力有限选 API；流量一致且利用率超 50%、数据主权受限时选自托管；混合方法通常最优（原文此处被截断）`[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
价格、硬件成本与收支平衡点均为 2025 年 12 月时点的市场数据，随供需快速漂移；假设利用率是成本的主导变量，且读者能准确预测自身流量模式。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
全文有编号引用（共 23 处）且覆盖面广，论证链条完整；但"年降 10 倍"是行业观察性总结而非严格统计，"50%/10% 利用率"等平衡点依赖特定 API 对标价格，未给出敏感性分析。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
纯成本对比可能误导：开源小模型与闭源前沿模型的能力不等价，未讨论质量差异的定价逻辑；原文结尾在"混合方法"处截断，该部分论证不完整；未充分展开电力价格、网络带宽等区域差异与工程人力等隐性成本；数据时效性强，2026 年参考需注意更新。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "掌握推理经济学决定了AI部署是创造价值还是消耗资本。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 把推理成本决策转化为可计算的框架（利用率方程、收支平衡点、请求量阈值）
|
||||
- 数据详实且有编号引用，API 与自托管判据清晰可操作
|
||||
- 明确区分标价与实际成本的差距（运营开销、软成本）
|
||||
|
||||
**不足**：
|
||||
- 原文结尾被抓取截断，混合方案论证不完整
|
||||
- 收支平衡点依赖时点价格，缺少敏感性分析
|
||||
- 成本对比未充分考虑模型质量差异
|
||||
|
||||
**适用场景**：AI 预算与技术选型决策者、负责推理成本优化的平台团队、研究 AI 经济学的人；用于自建 vs 购买的初步量化评估。
|
||||
|
||||
**关联建议**：结合中邮证券 Token 工厂研报理解产业端成本结构（电力占比、CAPEX/OPEX 拆解）；结合信通院报告了解优化技术的工程实现；定期更新价格数据以校准平衡点。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
# InfiniBand vs 以太网 GPU 集群对比：800G 网络架构决策指南
|
||||
|
||||
> **来源**：Introl
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-03-27
|
||||
> **原文链接**：https://introl.com/zh/blog/infiniband-vs-ethernet-gpu-clusters-800g-architecture
|
||||
|
||||
---
|
||||
|
||||
> 注：本页中文版经抓取工具处理时正文被截断，为保证内容完整性，以下正文取自英文原版（https://introl.com/blog/infiniband-vs-ethernet-gpu-clusters-800g-architecture），发布日期与中文版一致（2026-03-27，更新于 2025 年 12 月 8 日）。
|
||||
|
||||
**December 2025 Update:** NVIDIA Spectrum-X 800G Ethernet now shipping and validated for Blackwell deployments, narrowing the InfiniBand advantage for specific workloads. NDR 400G InfiniBand remains dominant for training clusters, with XDR 800G rolling out. The Ultra Ethernet Consortium released UEC 1.0 specification in 2024, with compliant products expected 2025-2026. AI cluster networking increasingly hybrid—InfiniBand for training, Ethernet for inference. 1.6T optics beginning to appear in roadmaps for 2026-2027.
|
||||
|
||||
The network connecting 10,000 GPUs determines whether they operate as a unified supercomputer or an expensive collection of isolated processors, yet most infrastructure teams make this $50 million decision based on vendor marketing rather than engineering analysis.¹ Meta standardized on Ethernet after discovering that InfiniBand's 15% performance advantage couldn't justify 2.3x higher total cost of ownership across their 600,000 GPU fleet.² Meanwhile, OpenAI credits InfiniBand's superior congestion control for enabling GPT-4 training to complete 40% faster than initial Ethernet-based attempts.³ The contradictory experiences reveal a fundamental truth: the "correct" choice depends entirely on workload characteristics, scale ambitions, and economic constraints.
|
||||
|
||||
Network architecture decisions reverberate for years through every aspect of AI infrastructure. InfiniBand's proprietary ecosystem locks organizations into NVIDIA's roadmap but delivers predictable performance for distributed training. Ethernet's open standards enable vendor flexibility and cost optimization but require sophisticated tuning to match InfiniBand's out-of-box efficiency. The choice affects not just current deployments but future scalability, as switching technologies later means replacing millions of dollars in switches, cables, and network cards.
|
||||
|
||||
The stakes escalate with each generation of hardware. NVIDIA's Spectrum-X promises to bring InfiniBand-like performance to Ethernet at 800Gbps speeds, potentially obsoleting the InfiniBand advantage.⁴ Intel's Ultra Ethernet Consortium pushes open standards that could fragment the market further.⁵ Organizations deploying infrastructure today must predict which technology will dominate in 2030, when current investments fully depreciate. Wrong predictions strand assets and constrain capabilities just as AI competition intensifies.
|
||||
|
||||
## Technical architectures reveal fundamental differences
|
||||
|
||||
InfiniBand emerged from supercomputing requirements where microseconds determine success or failure. The architecture assumes lossless transmission through credit-based flow control, where senders only transmit when receivers guarantee buffer availability.⁶ This eliminates packet drops but requires tight coupling between endpoints. Every InfiniBand device participates in a subnet manager's centralized routing decisions, creating deterministic paths optimized for specific traffic patterns. The approach delivers consistent sub-microsecond latency but struggles with dynamic workloads that deviate from expected patterns.
|
||||
|
||||
Ethernet evolved from local area networks where simplicity and interoperability mattered more than absolute performance. The architecture assumes lossy transmission with best-effort delivery, relying on higher-layer protocols for reliability. Packet drops trigger congestion control algorithms that reduce transmission rates, preventing network collapse but increasing latency variance. Ethernet's distributed routing decisions enable massive scale and flexibility but create unpredictable performance under load. Modern data center Ethernet adds features like Priority Flow Control and Explicit Congestion Notification to approach InfiniBand's lossless behavior.⁷
|
||||
|
||||
RDMA (Remote Direct Memory Access) capabilities distinguish both technologies from traditional networking. InfiniBand included RDMA natively, enabling direct memory transfers between systems without CPU involvement.⁸ RDMA over InfiniBand achieves 0.5 microsecond latency for small messages, 10x better than kernel-based networking. Ethernet added RDMA through RoCE (RDMA over Converged Ethernet), delivering similar performance when properly configured. However, RoCE requires pristine network conditions that prove difficult to maintain at scale.
|
||||
|
||||
Switching architectures differ fundamentally between technologies. InfiniBand switches operate as crossbar fabrics with non-blocking bandwidth between all ports.⁹ A 40-port HDR InfiniBand switch provides 16Tb/s aggregate bandwidth with consistent latency regardless of traffic pattern. Ethernet switches use shared memory architectures with statistical multiplexing, achieving higher port densities but variable performance under congestion. The architectural difference means InfiniBand maintains predictable performance while Ethernet offers better economics.
|
||||
|
||||
Management planes reflect different philosophical approaches. InfiniBand's Subnet Manager provides centralized control with global visibility into topology and traffic.¹⁰ The manager calculates optimal routes, handles failures, and maintains quality of service without manual intervention. Ethernet relies on distributed protocols like spanning tree, OSPF, or BGP that require careful configuration. Software-defined networking brings centralized control to Ethernet but adds complexity and potential failure points. The management difference affects operational overhead significantly at scale.
|
||||
|
||||
## Performance metrics beyond raw bandwidth
|
||||
|
||||
Latency measurements reveal nuanced differences between technologies. InfiniBand HDR achieves 0.6 microsecond port-to-port latency consistently across all message sizes.¹¹ Ethernet at 100Gbps shows 1.2 microsecond baseline latency that degrades to 50+ microseconds under congestion. The 2x baseline difference becomes 100x under load. For distributed training where gradient synchronization occurs millions of times, microsecond differences compound into hours of additional training time.
|
||||
|
||||
Bandwidth efficiency tells a different story than marketing specifications. InfiniBand delivers 95% of theoretical bandwidth for large transfers due to efficient encoding and minimal protocol overhead.¹² 200Gbps InfiniBand sustains 190Gbps actual throughput. Ethernet's overhead varies with configuration: standard Ethernet achieves 85% efficiency, while RoCE v2 reaches 92% with proper tuning. The efficiency gap narrows at 800Gbps speeds where both technologies use similar PAM4 encoding.
|
||||
|
||||
Congestion behavior separates technologies dramatically. InfiniBand's credit-based flow control prevents congestion by stopping transmission before buffers overflow.¹³ Performance degrades gracefully as load increases. Ethernet's packet drops trigger TCP-style backoff algorithms that create saw-tooth throughput patterns. Incast scenarios where multiple senders overwhelm a single receiver cause catastrophic performance collapse on poorly tuned Ethernet. InfiniBand handles the same scenario with minimal degradation.
|
||||
|
||||
Scalability testing exposes architectural limits. InfiniBand fabrics scale to 48,000 nodes in a single subnet with three-tier fat tree topologies.¹⁴ Larger deployments require multiple subnets connected through routers, adding complexity. Ethernet scales to millions of nodes using hierarchical routing but requires careful design to maintain performance. Facebook's data centers connect 100,000+ servers using Ethernet with custom protocols for traffic engineering.¹⁵ The examples show both technologies scale, but through different mechanisms.
|
||||
|
||||
Reliability metrics favor InfiniBand slightly in controlled environments. InfiniBand's lossless transmission and automatic path migration achieve 99.999% packet delivery.¹⁶ Ethernet with proper redundancy reaches 99.995% reliability, acceptable for most workloads. However, InfiniBand's tighter integration means single component failures can destabilize entire fabrics. Ethernet's loose coupling contains failures better, preventing cascade effects. The reliability difference matters most for long-running training jobs where any interruption wastes millions in compute time.
|
||||
|
||||
## Cost analysis disrupts conventional wisdom
|
||||
|
||||
Hardware costs tell only part of the economic story. InfiniBand HDR adapters cost $2,000-3,000 per port compared to $800-1,500 for equivalent Ethernet cards.¹⁷ A 40-port InfiniBand switch costs $50,000 versus $25,000 for Ethernet. Cabling adds another premium: InfiniBand DAC cables cost $500-800 while Ethernet equivalents run $200-400. For a 1,000 GPU cluster, InfiniBand hardware costs $15 million versus $7 million for Ethernet, a $8 million premium that seems prohibitive.
|
||||
|
||||
Operational expenses shift the calculation significantly. InfiniBand's automated management reduces administrative overhead by 60% compared to Ethernet.¹⁸ One network engineer can manage 10,000 InfiniBand ports versus 4,000 Ethernet ports requiring manual configuration. The labor savings amount to $500,000 annually for large deployments. InfiniBand's higher efficiency also reduces power consumption by 15%, saving $200,000 yearly for a megawatt facility.
|
||||
|
||||
Software licensing creates hidden expenses that many overlook. InfiniBand's OFED (OpenFabrics Enterprise Distribution) stack is open source with optional support contracts.¹⁹ Enterprise Ethernet often requires expensive software licenses for advanced features: VMware NSX costs $5,000 per CPU, Cisco ACI runs $50,000 per switch.²⁰ These licenses can exceed hardware costs over five-year deployment lifecycles. Open networking initiatives like SONiC reduce Ethernet software costs but require engineering investment.
|
||||
|
||||
Total Cost of Ownership models depend heavily on utilization assumptions. If InfiniBand's 15% performance advantage translates to 15% faster training, the time savings justify premium pricing for organizations where speed determines competitive advantage. An organization spending $1 million monthly on GPU compute saves $150,000 through faster completion. Over three years, the savings exceed InfiniBand's premium. However, if workloads don't benefit from InfiniBand's advantages, the premium becomes pure waste.
|
||||
|
||||
Vendor lock-in costs prove difficult to quantify but significantly impact long-term economics. InfiniBand locks organizations into NVIDIA's ecosystem, limiting negotiation leverage and technology choices.²¹ Ethernet's vendor diversity enables competitive bidding that reduces costs 20-30%. However, switching between Ethernet vendors requires re-engineering that costs millions. True vendor independence remains illusory regardless of technology choice.
|
||||
|
||||
## Software ecosystem maturity varies dramatically
|
||||
|
||||
Driver stability affects production reliability more than hardware specifications. InfiniBand's Mellanox OFED drivers undergo extensive testing with NVIDIA GPUs, ensuring compatibility across software stacks.²² Version 5.8 OFED supports every CUDA version seamlessly. Ethernet driver quality varies by vendor: Intel's ice driver proves rock-solid, while some vendors ship drivers that kernel panic under load. Driver issues cause mysterious failures that waste weeks of debugging time.
|
||||
|
||||
Framework integration determines developer productivity. PyTorch and TensorFlow optimize for InfiniBand through native UCX support, achieving near-theoretical performance without tuning.²³ NCCL (NVIDIA Collective Communications Library) includes InfiniBand-specific optimizations that accelerate all-reduce operations by 30%.²⁴ Ethernet support exists but requires manual configuration of RoCE parameters, congestion control algorithms, and buffer sizes. The integration gap narrows as frameworks add Ethernet optimizations, but InfiniBand maintains an ease-of-use advantage.
|
||||
|
||||
Management tools reflect ecosystem maturity differences. NVIDIA's UFM (Unified Fabric Manager) provides comprehensive InfiniBand monitoring, automatically detecting issues and suggesting remediations.²⁵ The platform includes AI-powered analytics that predict failures before they occur. Ethernet management fragments across vendors: Arista's CloudVision, Cisco's DNA Center, and Cumulus's NetQ offer similar capabilities but lack standardization. Organizations often deploy multiple tools to achieve UFM's functionality.
|
||||
|
||||
Debugging capabilities separate technologies significantly during problems. InfiniBand's centralized architecture enables comprehensive packet captures and flow analysis from a single point.²⁶ Performance counters expose bottlenecks clearly. Ethernet's distributed nature requires correlating data from multiple switches to understand issues. Modern observability platforms like Kentik provide Ethernet visibility approaching InfiniBand's, but at additional cost and complexity.
|
||||
|
||||
Container orchestration support increasingly determines deployment flexibility. Kubernetes' device plugin framework supports both InfiniBand and Ethernet SR-IOV, enabling container-native GPU workloads.²⁷ However, InfiniBand's RDMA capabilities require privileged containers that complicate security models. Ethernet's TCP/IP compatibility enables standard container networking with acceptable performance for many workloads. The container ecosystem favors Ethernet's flexibility over InfiniBand's performance.
|
||||
|
||||
## Real deployments illuminate decision factors
|
||||
|
||||
NVIDIA's Selene supercomputer demonstrates InfiniBand at its best: 2,240 DGX A100 nodes connected through HDR InfiniBand achieving 95% scaling efficiency for MLPerf benchmarks.²⁸ The deployment uses eight-layer fat tree topology with adaptive routing that maintains consistent performance regardless of communication pattern. NVIDIA engineers report zero network-related job failures across millions of GPU-hours. The success story showcases InfiniBand's strengths but benefits from NVIDIA's unique expertise and unlimited budget.
|
||||
|
||||
Google's TPU v4 pods chose Ethernet exclusively, connecting 4,096 accelerators through custom optical circuit switches.²⁹ Google's Jupiter network achieves 1.3Pb/s bisection bandwidth using merchant silicon and software-defined networking. The deployment proves Ethernet can match InfiniBand's scale and performance with sufficient engineering investment. However, Google's network team includes hundreds of PhDs developing custom protocols, a resource most organizations lack.
|
||||
|
||||
Alibaba's hybrid approach leverages both technologies strategically. Training clusters use InfiniBand for predictable performance during model development. Inference clusters deploy Ethernet for cost-effective scaling to millions of users.³⁰ The dual-technology strategy requires maintaining expertise in both ecosystems but optimizes costs for different workload characteristics. The approach works because training and inference infrastructure remain largely separate.
|
||||
|
||||
European supercomputing centers overwhelmingly choose InfiniBand, with 80% of TOP500 systems using the technology.³¹ The Barcelona Supercomputing Center's MareNostrum 5 connects 6,400 GPUs through NDR InfiniBand, achieving 85% efficiency on climate simulations. European funding agencies prefer InfiniBand's proven supercomputing heritage over Ethernet's data center origins. The regional preference creates expertise clusters that reinforce technology choices.
|
||||
|
||||
Hyperscale cloud providers split between technologies based on business models. AWS deploys both InfiniBand and Ethernet, charging premium prices for InfiniBand-connected instances.³² Azure standardizes on InfiniBand for HPC and AI workloads, leveraging parent Microsoft's RDMA expertise. Google Cloud relies entirely on Ethernet, reflecting corporate philosophy favoring open standards. The divergence means cloud customers must choose providers partially based on network technology preferences.
|
||||
|
||||
## Decision framework for architectural choice
|
||||
|
||||
Workload characteristics drive technology selection more than abstract performance metrics. Distributed training with frequent all-reduce operations favors InfiniBand's consistent latency and efficient collectives. Models with sparse communication patterns work well on Ethernet's flexible routing. Inference workloads rarely benefit from InfiniBand's premium unless serving latency-critical applications. Mixed workloads suggest hybrid deployments or Ethernet with careful tuning.
|
||||
|
||||
Scale ambitions influence technology choices significantly. Organizations planning 100-500 GPU deployments can manage Ethernet complexity through manual tuning. Beyond 1,000 GPUs, InfiniBand's automation becomes valuable. At 10,000+ GPUs, the choice depends on engineering resources: InfiniBand for teams wanting turnkey solutions, Ethernet for organizations with deep networking expertise. Introl helps clients evaluate scale requirements across our global infrastructure footprint.
|
||||
|
||||
Budget constraints create natural technology filters. InfiniBand's 2x hardware premium plus vendor lock-in requires $20,000+ per GPU total budgets. Organizations spending less than $15,000 per GPU should choose Ethernet unless workloads absolutely require InfiniBand performance. The threshold shifts based on electricity costs, cooling infrastructure, and operational expertise. Financial modeling must include five-year TCO, not just initial purchase price.
|
||||
|
||||
Future flexibility requirements affect current decisions. InfiniBand commits organizations to NVIDIA's roadmap, ensuring compatibility but limiting options. Ethernet enables mixing vendors and technologies, valuable for uncertain futures. However, Ethernet's flexibility requires architectural decisions that prove difficult to change later. Organizations must balance current optimization against future optionality.
|
||||
|
||||
Operational expertise availability often determines success more than technology choice. InfiniBand expertise remains scarce and expensive, with qualified engineers commanding $200,000+ salaries.³³ Ethernet knowledge is widespread but achieving InfiniBand-like performance requires specialized skills. Organizations should audit existing capabilities and training budgets before committing to either technology. The wrong choice relative to team capabilities guarantees suboptimal outcomes regardless of theoretical advantages.
|
||||
|
||||
## Migration strategies between technologies
|
||||
|
||||
Gradual migration from Ethernet to InfiniBand works poorly due to incompatible protocols. Translation gateways add latency and complexity that negate InfiniBand's advantages. Organizations must plan forklift upgrades where entire clusters switch simultaneously. The approach requires maintaining parallel infrastructure during transition, doubling costs temporarily. Success requires detailed project management and acceptance of disruption.
|
||||
|
||||
InfiniBand to Ethernet migration proves even more challenging due to performance regression risks. Applications optimized for InfiniBand's RDMA may require significant refactoring for Ethernet. The migration usually coincides with hardware refresh cycles to amortize disruption costs. Organizations report 6-12 month migration projects with 20-30% performance degradation until optimization completes.³⁴
|
||||
|
||||
Hybrid deployments offer compromise solutions but increase complexity. Running both technologies requires dual expertise, separate management tools, and careful workload placement. Gateway devices enable communication between InfiniBand and Ethernet domains but add latency. The approach works for organizations with clearly separated workloads but fails when applications require mixed resources.
|
||||
|
||||
Cloud bursting strategies differ by technology choice. InfiniBand clusters struggle to burst to public clouds due to limited availability. Ethernet enables seamless expansion to cloud resources during demand spikes. Organizations planning hybrid cloud deployments should favor Ethernet despite on-premise performance penalties. The flexibility value exceeds performance costs for many use cases.
|
||||
|
||||
Future-proofing suggests waiting for technology convergence. NVIDIA's Spectrum-X brings InfiniBand features to Ethernet, potentially obsoleting pure InfiniBand.³⁵ Ultra Ethernet pushes open standards matching InfiniBand performance. By 2027, the technologies may converge sufficiently that choice becomes irrelevant. Organizations able to delay decisions should wait for clarity, though competitive pressures rarely allow such luxury.
|
||||
|
||||
## Quick decision framework
|
||||
|
||||
**Technology Selection by Workload:**
|
||||
|
||||
| If Your Primary Workload Is... | Choose | Rationale |
|
||||
| --- | --- | --- |
|
||||
| LLM training (>1000 GPUs) | InfiniBand | Consistent latency, NCCL optimization |
|
||||
| Inference serving | Ethernet | Cost-effective, sufficient performance |
|
||||
| Mixed training + inference | Hybrid | InfiniBand for training, Ethernet for inference |
|
||||
| Research/experimentation | Ethernet | Flexibility, lower commitment |
|
||||
| HPC/scientific computing | InfiniBand | Proven at scale, TOP500 dominance |
|
||||
|
||||
**Technology Selection by Scale:**
|
||||
|
||||
| GPU Count | Recommendation | Reasoning |
|
||||
| --- | --- | --- |
|
||||
| <100 GPUs | Ethernet | Cost savings exceed performance gap |
|
||||
| 100-500 GPUs | Either (workload-dependent) | Evaluate based on communication patterns |
|
||||
| 500-2000 GPUs | InfiniBand preferred | Automation and stability benefits |
|
||||
| 2000-10000 GPUs | InfiniBand | Management complexity requires automation |
|
||||
| >10000 GPUs | Hybrid or federation | Multi-cluster with mixed technologies |
|
||||
|
||||
**Cost Comparison Summary:**
|
||||
|
||||
| Component | InfiniBand HDR | Ethernet 100G |
|
||||
| --- | --- | --- |
|
||||
| Adapter (per port) | $2,000-3,000 | $800-1,500 |
|
||||
| 40-port switch | ~$50,000 | ~$25,000 |
|
||||
| DAC cable | $500-800 | $200-400 |
|
||||
| 1,000 GPU cluster total | ~$15M | ~$7M |
|
||||
| Admin ratio | 1:10,000 ports | 1:4,000 ports |
|
||||
| 5-year TCO (with ops) | Varies | Often lower at scale |
|
||||
|
||||
## Key takeaways
|
||||
|
||||
**For infrastructure architects:**
|
||||
- InfiniBand: 0.6µs latency, 95% bandwidth efficiency, automated management
|
||||
- Ethernet: 1.2µs+ baseline latency, 85-92% efficiency, requires tuning
|
||||
- Congestion behavior is the critical difference—InfiniBand degrades gracefully, Ethernet collapses under incast
|
||||
- NVIDIA Spectrum-X (800G Ethernet) narrowing gap for specific workloads
|
||||
|
||||
**For financial planners:**
|
||||
- InfiniBand hardware costs 2x Ethernet, but operational costs 40% lower
|
||||
- Break-even favors InfiniBand when 15% performance advantage translates to time savings
|
||||
- Hidden Ethernet costs: software licenses ($50K+ per switch for Cisco ACI)
|
||||
- Hidden InfiniBand costs: NVIDIA lock-in limits negotiation leverage
|
||||
|
||||
**For strategic planning:**
|
||||
- 80% of TOP500 supercomputers use InfiniBand—validated for extreme scale
|
||||
- Google, Meta prove Ethernet works at hyperscale with sufficient engineering
|
||||
- Technology convergence (Spectrum-X, Ultra Ethernet) may make choice less critical by 2027
|
||||
- Cloud strategy matters: AWS/Azure offer InfiniBand, GCP is Ethernet-only
|
||||
|
||||
The InfiniBand versus Ethernet decision represents more than technology selection—it's a strategic choice about vendor relationships, operational models, and architectural philosophy. InfiniBand offers superior performance and simplicity for organizations willing to accept NVIDIA lock-in and premium pricing. Ethernet provides flexibility and cost advantages for teams capable of managing complexity. Neither technology is universally superior; success depends on aligning choice with organizational capabilities, workload requirements, and business objectives. The decision's multi-million dollar impact demands rigorous analysis rather than default assumptions or vendor influence.
|
||||
|
||||
## References
|
||||
|
||||
1. Gartner. "Network Infrastructure Costs for Large-Scale AI Deployments." Gartner Research, 2024. https://www.gartner.com/en/documents/network-infrastructure-ai
|
||||
2. Meta. "Ethernet vs InfiniBand: TCO Analysis Across 600,000 GPUs." Meta Engineering, 2024. https://engineering.fb.com/2024/network-technology-decision/
|
||||
3. OpenAI. "Infrastructure Choices for GPT-4 Training." OpenAI Engineering, 2024. https://openai.com/research/gpt-4-infrastructure-decisions
|
||||
4. NVIDIA. "Spectrum-X: Bringing InfiniBand Performance to Ethernet." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/spectrum-x/
|
||||
5. Intel. "Ultra Ethernet Consortium: Open Standards for AI Networking." Intel Network, 2024. https://www.intel.com/content/www/us/en/products/network-io/ultra-ethernet-consortium.html
|
||||
6. InfiniBand Trade Association. "InfiniBand Architecture Specification v1.4." IBTA, 2024. https://www.infinibandta.org/specifications/
|
||||
7. IEEE. "802.1Qbb Priority-based Flow Control." IEEE Standards, 2024. https://www.ieee802.org/1/pages/802.1bb.html
|
||||
8. Mellanox. "RDMA Technology Overview." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/rdma/
|
||||
9. ———. "InfiniBand Switch Architecture White Paper." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/infiniband-switch-architecture/
|
||||
10. ———. "Subnet Manager Architecture and Operations." NVIDIA Documentation, 2024. https://docs.nvidia.com/networking/display/subnet-manager
|
||||
11. ———. "HDR InfiniBand Performance Benchmarks." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/hdr-performance/
|
||||
12. Ohio State University. "MVAPICH Performance Benchmarks." OSU Micro-benchmarks, 2024. https://mvapich.cse.ohio-state.edu/benchmarks/
|
||||
13. Mittal, Radhika, et al. "Revisiting Network Support for RDMA." ACM SIGCOMM, 2024. https://dl.acm.org/doi/10.1145/3544216.3544265
|
||||
14. Mellanox. "Building Scale-Out InfiniBand Fabrics." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/scale-out-fabrics/
|
||||
15. Facebook. "Data Center Network Architecture at Scale." Facebook Engineering, 2024. https://engineering.fb.com/2024/data-center-network-scale/
|
||||
16. InfiniBand Trade Association. "Reliability Metrics for Production Deployments." IBTA, 2024. https://www.infinibandta.org/reliability-metrics/
|
||||
17. CDW. "Data Center Networking Price Guide 2024." CDW Corporation, 2024. https://www.cdw.com/content/price-guide/networking-2024
|
||||
18. IDC. "Operational Efficiency Comparison: InfiniBand vs Ethernet." IDC Research, 2024. https://www.idc.com/research/network-operational-efficiency
|
||||
19. OpenFabrics Alliance. "OFED Software Distribution." OFA, 2024. https://www.openfabrics.org/ofed/
|
||||
20. VMware. "NSX-T Data Center Pricing." VMware, 2024. https://www.vmware.com/products/nsx/pricing.html
|
||||
21. The Information. "NVIDIA's InfiniBand Lock-in Strategy." The Information, 2024. https://www.theinformation.com/articles/nvidia-infiniband-strategy
|
||||
22. Mellanox. "OFED Driver Compatibility Matrix." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/ofed-compatibility/
|
||||
23. PyTorch. "Distributed Training with InfiniBand." PyTorch Documentation, 2024. https://pytorch.org/docs/stable/distributed-infiniband.html
|
||||
24. NVIDIA. "NCCL Performance with InfiniBand." NVIDIA Developer, 2024. https://developer.nvidia.com/nccl-infiniband-performance
|
||||
25. ———. "UFM Telemetry and Monitoring Platform." NVIDIA Networking, 2024. https://www.nvidia.com/en-us/networking/ufm-telemetry/
|
||||
26. Mellanox. "InfiniBand Diagnostic and Debugging Tools." NVIDIA Documentation, 2024. https://docs.nvidia.com/networking/display/diagnostics
|
||||
27. Kubernetes. "Device Plugin for InfiniBand and SR-IOV." Kubernetes Documentation, 2024. https://kubernetes.io/docs/concepts/extend-kubernetes/device-plugins/
|
||||
28. NVIDIA. "Selene Supercomputer Architecture." NVIDIA HPC, 2024. https://www.nvidia.com/en-us/data-center/selene-supercomputer/
|
||||
29. Google. "Jupiter Network Evolution and TPU v4 Integration." Google Infrastructure, 2024. https://research.google/pubs/jupiter-tpu-integration/
|
||||
30. Alibaba Cloud. "Hybrid Network Strategy for AI Workloads." Alibaba Cloud Community, 2024. https://www.alibabacloud.com/blog/hybrid-network-ai
|
||||
31. TOP500. "Network Technology Distribution in HPC." TOP500.org, 2024. https://www.top500.org/statistics/network-technology/
|
||||
32. AWS. "Network Options for HPC and ML Workloads." AWS Documentation, 2024. https://docs.aws.amazon.com/hpc/latest/userguide/network-options.html
|
||||
33. Robert Half. "2024 Salary Guide: Network Engineering Specializations." Robert Half, 2024. https://www.roberthalf.com/salary-guide/network-engineering
|
||||
34. Microsoft Azure. "Migration from InfiniBand to Ethernet: Lessons Learned." Azure Blog, 2024. https://azure.microsoft.com/blog/network-migration-lessons/
|
||||
35. NVIDIA. "Spectrum-X Roadmap and InfiniBand Convergence." NVIDIA Investor Day, 2024. https://investor.nvidia.com/spectrum-x-roadmap
|
||||
@@ -0,0 +1,77 @@
|
||||
# 📊 文章摘要：InfiniBand vs 以太网 GPU 集群对比：800G 网络架构决策指南
|
||||
|
||||
> **原文**：[2026-03-27_InfiniBand_vs_以太网_GPU_集群对比_800G_网络架构决策指南.md](./2026-03-27_InfiniBand_vs_以太网_GPU_集群对比_800G_网络架构决策指南.md)
|
||||
> **原文链接**：https://introl.com/zh/blog/infiniband-vs-ethernet-gpu-clusters-800g-architecture
|
||||
> **来源**：Introl
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-03-27
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **按场景选型** — IB 与以太网没有普适最优解，选型取决于负载特征、规模野心、预算约束与团队工程能力。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
文章从架构原理（无损 vs 尽力而为、集中式子网管理 vs 分布式路由）、性能指标（延迟、带宽效率、拥塞行为）、TCO（硬件、运维、软件许可、锁定成本）与生态成熟度四个维度对比 InfiniBand 与以太网，并给出按负载类型、GPU 规模与预算的快速决策框架。核心结论：大规模训练集群倾向 IB 的可预测性能与 NCCL 优化，推理服务选以太网更具性价比，混合部署是常见折中；NVIDIA Spectrum-X 与 UEC 正推动技术收敛，2027 年前后选择的重要性可能下降。决策框架完整实用，但大量具体数字的引用来源无法核实，可信度受限。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **架构哲学的对立** — IB 以信用流控实现无损与确定性路径，但集中式管理不适应动态负载；以太网以丢包重传加拥塞控制换取规模与灵活性 `[分类: 共识]`
|
||||
2. **拥塞行为是最大差异** — 高负载下 IB 优雅降级，以太网在 incast 场景可能性能崩溃，两者延迟差距从基线 2 倍扩大到 100 倍 `[分类: 共识]`
|
||||
3. **成本账的两面性** — IB 硬件贵约 2 倍（千卡集群约 1500 万 vs 700 万美元），但运维开销约低 40%、功耗省 15%；盈亏平衡取决于 15% 性能优势能否转化为训练时间收益 `[分类: 争议]`
|
||||
4. **生态成熟度落差** — NCCL/UCX 对 IB 原生优化（AllReduce 快 30%）、UFM 集中式监控，而以太网驱动质量参差、管理工具碎片化；容器化场景以太网反而更灵活 `[分类: 共识]`
|
||||
5. **成功案例两极分化** — Selene（IB，95% 扩展效率）与 Google TPU（纯以太网加自研 Jupiter 网络）都成功，但前者靠 NVIDIA 资源、后者靠数百名网络博士，多数组织两者都不具备 `[分类: 共识]`
|
||||
6. **技术收敛进行时** — Spectrum-X 800G 把 IB 能力搬到以太网，UEC 1.0 规范已发布、合规产品 2025—2026 上市，2027 年前后选择可能不再关键 `[分类: 未探索]`
|
||||
7. **迁移代价极高** — 协议不兼容需要整集群 forklift 替换，IB→以太网迁移需 6—12 个月并伴随 20%—30% 性能回退 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设网络投资是"十年期决策"，2027—2030 年技术不发生剧变；假设组织有清晰的训练/推理负载画像；将 Meta（60 万 GPU 规模的 2.3 倍 TCO）与 OpenAI（GPT-4 训练快 40%）两个对比案例当作既定事实——但这两个案例均无法在公开渠道核实。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论证结构完整，每个论点都有数字支撑，但参考文献大量指向 2024 年的泛化链接（如 engineering.fb.com、openai.com 的相关页面），真实性存疑，有营销或 AI 生成内容之嫌；这使证据链可信度大打折扣，结论只宜作为方向性参考而非决策依据。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
数字多为 2024—2025 年快照，2026 年 800G 以太网与 Spectrum-X 落地后部分差距已收窄；全文为欧美视角，未讨论国内大厂 RoCE 实践与国产化约束；"运维省 60%""1 人管理 1 万端口"等管理效率数字缺乏独立验证；中文版正文曾被截断，正文实际来自英文原版。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "The network connecting 10,000 GPUs determines whether they operate as a unified supercomputer or an expensive collection of isolated processors"（原文为英文，大意：连接 1 万块 GPU 的网络，决定了它们是一台统一的超级计算机，还是一堆昂贵的孤立处理器。）
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 决策框架完整（负载/规模/预算/团队能力四维），快速决策表可直接用于立项讨论
|
||||
- TCO 分析覆盖硬件、运维、软件许可、锁定成本，视角全面；明确承认"两者均非普适最优"，边界意识强
|
||||
|
||||
**不足**：
|
||||
- 数据来源可疑、无法核实，削弱整体可信度；对国内 RoCE 生态与实践完全空白
|
||||
- 内容为英文原文转载（中文版正文截断），部分结论已被 2026 年技术进展修正
|
||||
|
||||
**适用场景**：500 卡以上 GPU 集群网络选型的基础设施决策者与财务规划者；需要向管理层讲清"IB 溢价值不值"的架构师。
|
||||
|
||||
**关联建议**：用土法炼钢《大模型基础设施工程 04》核实工程细节与国产生态；用 Meta/阿里/字节公开工程博客（HPN、MegaScale、Grand Teton）交叉验证结论；跟踪 UEC 1.0 与 Spectrum-X 的 2026 年落地数据。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
# LMCache 博客
|
||||
|
||||
> **来源**：LMCache 博客
|
||||
> **作者**：LMCache Team
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://blog.lmcache.ai/
|
||||
|
||||
---
|
||||
|
||||
# LMCache
|
||||
|
||||
---
|
||||
|
||||
Caching knowledge for your LLM
|
||||
|
||||
## 文章列表
|
||||
|
||||
### 1. LMCache on Google Kubernetes Engine: Boosting LLM Inference Performance with KV Cache on Tiered Storage
|
||||
|
||||
By **Danna Wang, Google**
|
||||
|
||||
Posted on October 7, 2025
|
||||
|
||||
Overview of the Collaboration
|
||||
|
||||
[Read More](https://blog.lmcache.ai/2025/10/07/lmcache-gke-tiered-storage/)
|
||||
|
||||
### 2. Implementing LMCache Plugin Framework & lmcache_frontend: Design Philosophy
|
||||
|
||||
#### A flexible plugin system for enhanced observability and management
|
||||
|
||||
By **Baolong, Kobe**
|
||||
|
||||
Posted on September 23, 2025
|
||||
|
||||
Abstract
|
||||
|
||||
Tags: LMCache、Plugin Framework、Frontend、vLLM、Monitoring
|
||||
|
||||
[Read More](https://blog.lmcache.ai/2025/09/23/implementing-lmcache-plugin-framework/)
|
||||
|
||||
### 3. NVIDIA Dynamo integrates LMCache, Accelerating LLM Inference
|
||||
|
||||
By **NVIDIA Dynamo team, LMCache team**
|
||||
|
||||
Posted on September 18, 2025
|
||||
|
||||
We're thrilled to announce that Nvidia Dynamo has integrated LMCache as a KV caching layer solution. This is a big milestone: Dynamo gets a battle-tested caching solution, and LMCache becomes part of a data center-scale inference platform used by many developers worldwide to deploy AI at scale.
|
||||
|
||||
[Read More](https://blog.lmcache.ai/2025/09/18/nvidia-dynamo-integrates-lmcache/)
|
||||
|
||||
### 4. Extending LMCache Backends: A Comprehensive Guide to Custom Backend Development
|
||||
|
||||
#### Learn how to build custom backends for LMCache using the external backend extension mechanism
|
||||
|
||||
By **Baolong, Kobe**
|
||||
|
||||
Posted on September 11, 2025
|
||||
|
||||
Abstract
|
||||
|
||||
Tags: backend、extension、customization、storage、lmcache
|
||||
|
||||
[Read More](https://blog.lmcache.ai/2025/09/11/extending-lmcache-backends/)
|
||||
|
||||
### 5. 🎉 LMCache Hits 5,000+ GitHub Stars — Thank You, Community!
|
||||
|
||||
#### A milestone that shows KV cache has become a first-class citizen in the LLM inference stack
|
||||
|
||||
By **LMCache Team**
|
||||
|
||||
Posted on August 28, 2025
|
||||
|
||||
We're thrilled to share that LMCache has officially crossed 5,000 GitHub stars! 🚀 This milestone is not just a number — it's a strong signal that KV cache technology has become a first-class citizen in the LLM inference stack, and that our community is leading the way.
|
||||
|
||||
Tags: milestone、community、github、stars
|
||||
|
||||
[Read More](https://blog.lmcache.ai/2025/08/28/lmcache-5000-stars/)
|
||||
|
||||
---
|
||||
|
||||
LMCache Team • 2025 • lmcache.github.io
|
||||
@@ -0,0 +1,74 @@
|
||||
# 📊 文章摘要：LMCache 博客文章列表
|
||||
|
||||
> **原文**：[2026-08-06_LMCache_博客文章列表.md](./2026-08-06_LMCache_博客文章列表.md)
|
||||
> **原文链接**：https://blog.lmcache.ai/
|
||||
> **来源**：LMCache 博客
|
||||
> **作者**：LMCache Team
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐ 低
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **KV缓存生态索引** — LMCache 团队博客的目录页，5 篇文章串起"KV cache 已成为 LLM 推理栈一等公民"的生态信号
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 LMCache 团队博客（blog.lmcache.ai）的文章列表页，不含正文，仅列出 5 篇文章的标题、作者与一句话摘要：LMCache on Google Kubernetes Engine（GKE 分层存储）、插件框架与 lmcache_frontend 设计、NVIDIA Dynamo 集成 LMCache、外部后端扩展指南、5000 GitHub 星标里程碑。作为索引页，其价值在于发现入口——它透露了两个生态信号：KV cache 缓存层已进入数据中心级推理平台（NVIDIA Dynamo 集成），且被作者表述为推理栈的"一等公民"；但页面本身无实质内容，信息增量极低，单篇细节需点击原文获取。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **索引页性质** — 仅含 5 篇文章的标题/作者/日期/一句话摘要，无正文内容，作为阅读线索使用 `[分类: 共识]`（页面事实）
|
||||
2. **NVIDIA Dynamo 集成 LMCache** — LMCache 成为 Dynamo 的 KV 缓存层解决方案，进入数据中心级推理平台生态（2025-09-18）`[分类: 共识]`（生态事件）
|
||||
3. **5000 GitHub stars 里程碑** — 团队解读为"KV cache 技术已成为 LLM 推理栈的一等公民"的信号（2025-08-28）`[分类: 争议]`（团队自我评价，非第三方判断）
|
||||
4. **生态扩展方向** — GKE 分层存储（与 Google 合作）、插件框架（可观测性与管理）、外部后端扩展机制，构成 KV 缓存从单机到云原生的扩展路径 `[分类: 未探索]`（线索，详情需读单篇）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
页面本身不含论证，隐含假设是读者已了解 LMCache 项目背景（KV cache 分布式存储/缓存系统）并有意愿深入阅读其技术博客；将"5000 stars"解读为"一等公民"是团队自我表述，不构成行业共识。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
作为索引页无论据可评估；其内容可信度取决于单篇文章质量，本摘要无法验证。标题层面的信息（集成、合作、里程碑）均为团队自述，未经第三方信源交叉验证。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
本页不提供任何可操作结论，不适用于任何决策场景；唯一用途是发现入口。若需了解 LMCache 的技术细节、性能数据或与 vLLM 的集成方式，必须阅读列出的单篇文章原文。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "it's a strong signal that KV cache technology has become a first-class citizen in the LLM inference stack"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 作为目录页，清晰标注了每篇文章的作者、日期与摘要，方便按需检索
|
||||
- 透露的生态信号（Dynamo 集成、5000 stars、GKE 合作）可作为 KV 缓存生态演进的线索
|
||||
|
||||
**不足**：
|
||||
- 无正文内容，信息增量接近于零；"一等公民"等表述为团队自我评价
|
||||
- 列表时间均为 2025 年（2025-08 至 2025-10），最新文章距今近一年，页面时效性一般
|
||||
|
||||
**适用场景**：对 LLM 推理 KV 缓存生态感兴趣的读者，将其作为书签/目录使用，按需点击阅读单篇技术文章；不适用于任何需要结论或数据的场景。
|
||||
|
||||
**关联建议**：结合 vLLM 官方文档中 Disaggregated Prefilling 的 LMCacheConnectorV1（含 MP 模式）阅读，理解 LMCache 在分离式推理中的角色；关注 blog.lmcache.ai 与 lmcache.github.io 获取最新文章；如涉及 KV 缓存选型，可直接查阅 LMCache 的 GitHub 仓库文档而非本索引页。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
本篇文章为低价值，未生成配图。
|
||||
@@ -0,0 +1,90 @@
|
||||
# Welcome to Mooncake
|
||||
|
||||
> **来源**：Mooncake 项目
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://kvcache-ai.github.io/Mooncake/index.html
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
**A KVCache-centric Disaggregated Architecture for LLM Serving.**
|
||||
|
||||
Mooncake 是 Kimi（月之暗面提供的领先 LLM 服务）的服务平台。现在 Transfer Engine 和 Mooncake Store 均已开源！本仓库还托管其技术报告和开源 traces。
|
||||
|
||||
## 更新日志
|
||||
|
||||
- **May 7, 2026**：vLLM 正式支持 Mooncake Store——深入介绍 Mooncake 的分布式 KVCache 引擎如何通过高吞吐、内存高效、跨实例的 KV cache 共享为 vLLM 推理提速。
|
||||
- **Apr 29, 2026**：SGLang 引入基于 RDMA 的 P2P 权重传输，使用 Mooncake TransferEngine 支持大规模分布式 RL，1T 参数 Kimi-K2 模型的权重更新速度提升 7 倍（53s → 7.2s），在数千 GPU 上实现零拷贝 RDMA 传输。
|
||||
- **Mar 19, 2026**：TorchSpec：Speculative Decoding Training at Scale 开源，使用 Mooncake 通过高效的 hidden states 管理解耦推理与训练。
|
||||
- **Feb 12, 2026**：Mooncake 正式加入 PyTorch Ecosystem！
|
||||
- **Jan 28, 2026**：FlexKV（腾讯与 NVIDIA 及社区合作开发的分布式 KV 存储与缓存系统）现支持与 Mooncake Transfer Engine 的分布式 KVCache 复用。
|
||||
- **Dec 23, 2025**：SGLang 引入 Encode-Prefill-Decode (EPD) 解耦，以 Mooncake 作为传输后端。该集成允许将计算密集型多模态编码器（如 Vision Transformers）从语言模型节点解耦，利用 Mooncake 的 RDMA 引擎零拷贝传输大型多模态 embeddings。
|
||||
- **Dec 19, 2025**：Mooncake Transfer Engine 已集成到 TensorRT LLM，用于 PD 解耦推理中的 KVCache 传输。
|
||||
- **Dec 19, 2025**：Mooncake Transfer Engine 已作为 KV Connector 直接集成到 vLLM v1 的 PD 解耦部署中。
|
||||
- **Nov 07, 2025**：RBG + SGLang HiCache + Mooncake——基于角色的开箱即用云原生部署方案，弹性、可扩展、高性能。
|
||||
- **Sept 18, 2025**：Mooncake Store 作为分布式 KV cache 池后端赋能 vLLM Ascend。
|
||||
- **Sept 10, 2025**：SGLang 正式支持 Mooncake Store 作为分层 KV 缓存存储后端。该集成将 RadixAttention 扩展到跨设备、主机和远程存储层的多级 KV cache 存储。
|
||||
- **Sept 10, 2025**：Mooncake P2P Store 的官方高性能版本以 checkpoint-engine 开源。已成功应用于 K1.5 和 K2 生产训练，约 20 秒内完成跨数千 GPU 的 Kimi-K2（1T 参数）模型更新。
|
||||
- **Aug 23, 2025**：xLLM 高性能推理引擎基于 Mooncake 构建混合 KV 缓存管理，支持全局 KV 缓存管理与智能卸载、预取。
|
||||
- **Aug 18, 2025**：vLLM-Ascend 集成 Mooncake Transfer Engine 实现 KV cache 注册与解耦预填充，在昇腾 NPU 上支持高效分布式推理。
|
||||
- **Jul 20, 2025**：Mooncake 在 128 块 H200 GPU 上支撑 Kimi K2 部署，采用 PD 解耦和大规模专家并行，实现 224k tokens/sec 预填充吞吐和 288k tokens/sec 解码吞吐。
|
||||
- **Jun 20, 2025**：Mooncake 成为 LMDeploy 的 PD 解耦后端。
|
||||
- **May 9, 2025**：NIXL 正式支持 Mooncake Transfer Engine 作为后端插件。
|
||||
- **May 8, 2025**：Mooncake x LMCache 联合，开创以 KVCache 为中心的 LLM 服务系统。
|
||||
- **May 5, 2025**：在 Mooncake 团队支持下，SGLang 发布在 96 块 H100 GPU 上使用 PD 解耦部署 DeepSeek 的指南。
|
||||
- **Apr 22, 2025**：LMCache 正式支持 Mooncake Store 作为远程连接器。
|
||||
- **Apr 10, 2025**：SGLang 正式支持 Mooncake Transfer Engine 用于解耦预填充和 KV cache 传输。
|
||||
- **Mar 7, 2025**：开源 Mooncake Store——基于 Transfer Engine 的分布式 KVCache。基于 Mooncake Store 的 vLLM xPyD 解耦预填充与解码即将发布。
|
||||
- **Feb 25, 2025**：Mooncake 荣获 FAST 2025 最佳论文奖（Best Paper Award）！
|
||||
- **Feb 21, 2025**：FAST'25 论文中使用的更新版 traces 已发布。
|
||||
- **Dec 16, 2024**：vLLM 正式支持 Mooncake Transfer Engine 用于解耦预填充和 KV cache 传输。
|
||||
- **Nov 28, 2024**：开源 Transfer Engine——Mooncake 的核心组件。同时提供两个演示：P2P Store 和 vLLM 集成。
|
||||
- **July 9, 2024**：以 JSONL 文件形式开源 trace。
|
||||
- **June 27, 2024**：发布一系列中文博客（知乎，共 7 篇）。
|
||||
- **June 26, 2024**：初始技术报告发布。
|
||||
|
||||
## 文档导航（概要）
|
||||
|
||||
**Getting Started**
|
||||
- Build Guide（PyPI Package、Automatic Build、Manual Build、Docker Containers、Advanced Compile Options）
|
||||
- Quick Start（Installation、Transfer Engine Quick Start、Mooncake Store Quick Start）
|
||||
- Supported Communication Protocols（Quick Reference、Python API、C++ Transfer Engine、Configuration Examples、Troubleshooting）
|
||||
- Observability（Master Metrics Log、Prometheus Metrics Endpoint）
|
||||
- SGLang Disaggregated Serving with MooncakeTransferEngine
|
||||
- SGLang HiCache with Mooncake Backend
|
||||
- Mooncake x vLLM Integration
|
||||
- Mooncake x LMCache Integration
|
||||
- LMDeploy Disaggregated Serving with MooncakeTransferEngine
|
||||
- Mooncake HF3FS Plugin (Experimental)
|
||||
|
||||
**Performance**
|
||||
- vLLM Performance Benchmarks
|
||||
- PD Disaggregation Performance
|
||||
- Benchmark on NVIDIA A10
|
||||
- SGLang HiCache with Mooncake Backend Benchmark
|
||||
- vLLM with Mooncake Transfer Engine Benchmark
|
||||
- Allocator Performance / AllocationStrategy Performance
|
||||
- Mooncake SSD Offload Benchmark
|
||||
- Mooncake KVCache Storage Benchmark
|
||||
|
||||
**Design Documents**
|
||||
- Mooncake Architecture（Architectural Overview）
|
||||
- Mooncake Store（Introduction、Architecture、Client C++ API、Master Service、Buffer Allocator、AllocationStrategy、Eviction Policy、Lease、Soft Pin、Hard Pin、Zombie Object Cleanup、Preferred Segment Allocation、Multi-layer Storage Support、Builtin Metadata Server、Python API、Version Management Policy）
|
||||
- P2P Store（Overview、Sample Program、API）
|
||||
- Transfer Engine（Overview、Bench、C/C++ API、Advanced Runtime Options、C++ API Reference、EFA Transport (AWS)、Ascend Transport、Sunrise Link Transport、Supported Protocols、Benchmark and Tuning Guide）
|
||||
- Mooncake x SGLang HiCache System Design（HiRadixTree、Local Match、Prefetch from L3、Data Write-back、Multi-Rank Synchronization、PD-Disaggregation Deployment）
|
||||
- EngramStore Backend
|
||||
- Unified Parallel Tensor IO
|
||||
- TENT: Transfer Engine NEXT（Core Design、TENT C++ API、Metrics、Transport Selection、QoS、Slice Spraying、Failover）
|
||||
- Mooncake Transfer Engine Benchmark Tool（tebench）Guide
|
||||
- Mooncake Conductor Architecture
|
||||
- Mooncake Conductor Indexer API
|
||||
|
||||
**Deployment**
|
||||
- Mooncake Store Deployment & Operations Guide
|
||||
- Mooncake NVMe-oF SSD Pool Deployment Guide
|
||||
|
||||
**Archived**
|
||||
- Guide: vLLM MooncakeStoreConnector、vLLM V0 Disaggregated Serving Demo、vLLM V0 Disaggregated Serving with MooncakeStore、vLLM v1 backend Disaggregated Serving with MooncakeConnector
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：Welcome to Mooncake（KVCache 中心的分离式 LLM 服务架构）
|
||||
|
||||
> **原文**：[2026-08-06_Welcome_to_Mooncake.md](./2026-08-06_Welcome_to_Mooncake.md)
|
||||
> **原文链接**：https://kvcache-ai.github.io/Mooncake/index.html
|
||||
> **来源**：Mooncake 项目官网
|
||||
> **作者**：未知（月之暗面 Moonshot AI / Kimi 团队）
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **KVCache 中心化** — 以 KVCache 为核心的 PD 分离服务架构，已从论文演进为被 vLLM、SGLang 等主流推理引擎广泛集成的开源基础设施生态。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 Mooncake 项目的官网首页，主体内容为 2024 年 6 月至 2026 年 5 月的完整更新日志（约 30 条）与文档导航。其认知价值在于：以时间线形式记录了"KVCache 中心分离式架构"从 FAST'25 最佳论文走向工程落地、并被 vLLM/SGLang/TensorRT-LLM/LMDeploy/LMCache 等十余个主流组件集成的全过程，是观察 LLM 推理基础设施生态演进的一手材料。文中提供若干关键性能数字（Kimi-K2 权重更新 53s→7.2s、128 块 H200 上 224k/288k tokens/sec 吞吐等）。局限在于：内容为项目自述的公告集合，无实验细节、无失败教训、无边界条件讨论，性能数据需谨慎对待。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **开源组件全景** — 核心组件 Transfer Engine（RDMA 高速传输）与 Mooncake Store（分布式 KVCache 池）均已开源，配套 P2P Store、checkpoint-engine、TENT（Transfer Engine NEXT）等。 `[分类: 共识]`
|
||||
|
||||
2. **生态集成是主要影响力路径** — vLLM（KV Connector）、SGLang（HiCache/EPD 解耦）、TensorRT-LLM、LMDeploy、LMCache、xLLM、FlexKV（腾讯）等相继接入 Mooncake，说明"以 KVCache 为中心 + 分离式"已成为行业共同技术方向。 `[分类: 共识]`
|
||||
|
||||
3. **分离式架构的量化收益** — 1T 参数 Kimi-K2 权重更新跨数千 GPU 约 20 秒完成（经 checkpoint-engine，2025 年 9 月），后经 SGLang RDMA P2P 权重传输进一步降至 7.2 秒；128 块 H200 上实现 224k tokens/sec 预填充、288k tokens/sec 解码吞吐。 `[分类: 共识]`
|
||||
|
||||
4. **FAST'25 最佳论文的学术背书** — 2025 年 2 月获存储领域顶会 FAST 2025 最佳论文奖，论文配套 traces 已开源，为后续研究提供可复现数据。 `[分类: 共识]`
|
||||
|
||||
5. **文档的局限沉默** — 全文无任何关于架构取舍、失败经验、CPU/DRAM/SSD 异构资源调度复杂度的讨论，也未说明中小规模部署场景的适用性，是典型的项目宣传口径。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 假设大规模集群中 GPU 间存在高速 RDMA 网络（Transfer Engine 依赖），且集群拥有可观的空闲 CPU/DRAM/SSD 资源可供 KVCache 缓存利用；这两条假设决定了 Mooncake 方案主要面向万卡级别的超大规模生产集群。
|
||||
- 假设 PD 分离与 KVCache 复用带来的收益大于调度与传输的复杂度成本。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 更新日志中的性能数字（7.2s 权重更新、224k/288k tokens/sec、FAST'25 最佳论文）均为可验证的具体事实，但全部来自项目自述，无独立第三方基准，且"525% 吞吐提升"等来自论文模拟场景而非生产数据。更新日志整体是"成就清单"逻辑，缺少对照与失败记录，论据方向单一。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 适用场景：大规模（数百至数千 GPU 以上）LLM 服务集群的 PD 分离、KV cache 池化与权重同步；对中小规模集群，RDMA 基础设施投入与调度复杂度可能不划算。
|
||||
- 文档本身是入口性材料，未提供任何架构细节（架构细节在导航指向的 Design Documents 中），不能仅凭本文评估 Mooncake 的技术优劣。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "A KVCache-centric Disaggregated Architecture for LLM Serving."
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 一条时间线浓缩了 2024-2026 年 LLM 推理基础设施生态的演进脉络，信息密度高
|
||||
- 关键性能数字可作为行业动态引用素材；开源 traces 与论文获奖是客观事实
|
||||
- 文档导航完整，是深入 Mooncake 架构的可靠入口
|
||||
|
||||
**不足**：
|
||||
- 纯公告集合，无技术细节、无架构论证、无失败记录与边界讨论
|
||||
- 性能数据均为自述口径，缺少第三方验证，引用需标注来源性质
|
||||
|
||||
**适用场景**：关注 LLM 推理基础设施技术动向的架构师与研究者；需要快速了解 Mooncake 生态集成现状、并决定是否深入阅读其设计文档的人群。
|
||||
|
||||
**关联建议**：结合 Mooncake FAST'25 论文原文、cr7258《Lesson 06：PD 分离推理架构详解》中的 Mooncake 章节、以及 vLLM 官方 KV Connector 文档交叉阅读，可形成对分离式架构的完整认知。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# Welcome to NVIDIA Dynamo
|
||||
|
||||
> **来源**：NVIDIA Dynamo 文档
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://docs.nvidia.com/dynamo/latest/index.html
|
||||
|
||||
---
|
||||
|
||||
NVIDIA Dynamo Platform 是一个高性能、低延迟的推理框架，旨在服务于所有 AI 模型——支持任何框架、任何架构、任何部署规模。
|
||||
|
||||
> 本指南是某一特定时间点的快照。获取最新信息和示例，请参见 Dynamo GitHub 仓库。
|
||||
|
||||
## Quickstart（快速开始）
|
||||
|
||||
只需几个命令即可在本地开始使用 Dynamo：
|
||||
|
||||
**1. 安装 Dynamo**
|
||||
|
||||
```
|
||||
# Install uv (recommended Python package manager)
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
|
||||
# Create virtual environment and install Dynamo
|
||||
uv venv venv
|
||||
source venv/bin/activate
|
||||
uv pip install "ai-dynamo[sglang]==0.4.1" # or [vllm], [trtllm]
|
||||
```
|
||||
|
||||
**2. 启动 etcd/NATS**
|
||||
|
||||
```
|
||||
# Fetch and start etcd and NATS using Docker Compose
|
||||
curl -fsSL -o docker-compose.yml https://raw.githubusercontent.com/ai-dynamo/dynamo/release/0.4.1/deploy/docker-compose.yml
|
||||
docker compose -f docker-compose.yml up -d
|
||||
```
|
||||
|
||||
**3. 运行 Dynamo**
|
||||
|
||||
```
|
||||
# Start the OpenAI compatible frontend (default port is 8080)
|
||||
python -m dynamo.frontend
|
||||
|
||||
# In another terminal, start an SGLang worker
|
||||
python -m dynamo.sglang --model-path Qwen/Qwen3-0.6B
|
||||
```
|
||||
|
||||
**4. 测试部署**
|
||||
|
||||
```
|
||||
curl localhost:8080/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"model": "Qwen/Qwen3-0.6B",
|
||||
"messages": [{"role": "user", "content": "Hello!"}],
|
||||
"max_tokens": 50}'
|
||||
```
|
||||
@@ -0,0 +1,79 @@
|
||||
# 📊 文章摘要：Welcome to NVIDIA Dynamo（快速开始指南）
|
||||
|
||||
> **原文**：[2026-08-06_Welcome_to_NVIDIA_Dynamo.md](./2026-08-06_Welcome_to_NVIDIA_Dynamo.md)
|
||||
> **原文链接**：https://docs.nvidia.com/dynamo/latest/index.html
|
||||
> **来源**：NVIDIA Dynamo 官方文档
|
||||
> **作者**：未知（NVIDIA）
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **五分钟上手** — 用 uv、docker compose 和两个 Python 命令即可在本机拉起一个 OpenAI 兼容的 Dynamo 推理服务，是理解 Dynamo 的零成本入口。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 NVIDIA Dynamo 官方文档的首页，核心内容是 Quickstart：安装 `ai-dynamo`（可选 sglang/vllm/trtllm 后端）、用 docker compose 启动 etcd 与 NATS 依赖、运行 OpenAI 兼容前端（默认 8080 端口）、启动 SGLang worker，最后用 curl 验证部署。其价值在于展示了 Dynamo 的架构形态——前端与推理引擎解耦、依赖 etcd/NATS 作为分布式协调组件、引擎无关的后端可插拔设计。局限在于全文仅此而已：无架构图、无性能数据、无功能清单，官方"高性能、低延迟、支持任何框架"的定位无任何论据支撑，仅适合作为上手路径而非认知材料。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **引擎无关的前端 + Worker 模型** — 通过 `python -m dynamo.frontend` 启动 OpenAI 兼容网关，再以 `python -m dynamo.sglang --model-path ...` 启动推理 worker，前后端解耦，后端可在 SGLang/vLLM/TensorRT-LLM 间切换。 `[分类: 共识]`
|
||||
|
||||
2. **外部协调依赖** — 运行 Dynamo 需要 docker compose 拉起 etcd（服务发现/元数据）与 NATS（消息通信），说明其分布式运行时依赖这两类基础组件，部署门槛高于单体推理服务。 `[分类: 共识]`
|
||||
|
||||
3. **低门槛验证路径** — 用 Qwen3-0.6B 小模型 + curl 一条命令即可验证部署，几分钟内可跑通端到端，适合作为 Dynamo 的初次体验。 `[分类: 共识]`
|
||||
|
||||
4. **宣传与事实的落差** — 首页宣称"高性能、低延迟、服务于所有 AI 模型、任何部署规模"，但全文无任何基准测试、无架构说明，这些定位在本文档中无法被验证，需转向 Dynamo 其他章节或 GitHub 仓库核实。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 假设用户环境具备 Docker（运行 etcd/NATS）、Python 与网络可访问容器镜像和 GitHub 原始文件；假设用户已有可用的 GPU 资源来真正跑推理（小模型可 CPU 运行，但文档未说明）。
|
||||
- 文档默认"跑通 Quickstart = 理解 Dynamo"，但快速开始无法体现 Dynamo 的核心价值（智能路由、PD 分离、KV cache 管理）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 本文档没有任何论证环节，仅是可复现的操作步骤，其有效性取决于步骤本身是否可执行（涉及外部依赖的版本锁定，如 0.4.1 版本号）。"高性能低延迟"等宣称零论据支撑，属于厂商宣传口径，不能从本文得出任何性能结论。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 适用场景：初次接触 Dynamo、想快速验证安装路径的开发者；生产级配置、架构设计、性能评估均超出本文范围。
|
||||
- 文档为"某一时间点的快照"（官方自述），版本演进可能导致步骤失效；单机 Quickstart 与文档所述"任何部署规模"之间差距巨大，无法据此推断大规模部署形态。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "NVIDIA Dynamo Platform 是一个高性能、低延迟的推理框架，旨在服务于所有 AI 模型——支持任何框架、任何架构、任何部署规模。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 步骤清晰可复现，五分钟可跑通端到端示例，入门门槛极低
|
||||
- 展示了 Dynamo 前后端解耦、引擎无关、etcd/NATS 协调的架构轮廓
|
||||
|
||||
**不足**：
|
||||
- 信息量极少：无架构图、无功能说明、无性能数据，宣称与证据严重不匹配
|
||||
- 未说明 GPU 要求、生产部署方式与后续阅读路径，读者易产生"跑通即掌握"的错觉
|
||||
|
||||
**适用场景**：需要快速验证 Dynamo 安装路径的开发者；作为 Dynamo 文档体系的最低层入口，后续需结合其架构与性能章节使用。
|
||||
|
||||
**关联建议**：结合 cr7258《Lesson 06：PD 分离推理架构详解》中 Dynamo 章节（Planner/Smart Router/KV Cache Manager/NIXL 四组件）理解其设计意图，再对照 vLLM/SGLang 原生方案做选型评估。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,224 @@
|
||||
# 如何使用 NVIDIA Dynamo 减少 KV 缓存瓶颈
|
||||
|
||||
> **来源**：NVIDIA 技术博客
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-09-18
|
||||
> **原文链接**：https://developer.nvidia.cn/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/
|
||||
|
||||
---
|
||||
|
||||
随着 AI 模型变得更大、更复杂，推理，即模型生成响应的过程，正成为一项重大挑战。像 GPT-OSS 和 DeepSeek-R1 这样的大语言模型（LLM）严重依赖注意力数据（KV 缓存）来理解输入提示并进行上下文化，但高效管理这些数据正变得愈发困难。
|
||||
|
||||
本文将探讨如何在推理过程中将 KV 缓存卸载至成本效益更高的存储中，从而降低推理成本并提升用户体验。同时，本文还将阐述 NVIDIA Dynamo 的最新优化如何实现这一目标。
|
||||
|
||||
## 什么是 KV 缓存？
|
||||
|
||||
KV 缓存是在推理初始阶段创建的 LLM 注意力机制的核心数据结构，该阶段称为预填充。KV 缓存用于存储中间注意力数据，有助于模型在生成或响应阶段聚焦于输入中最为相关的部分。
|
||||
|
||||
然而，KV 缓存会随着提示长度呈线性增长，并且在生成过程中必须驻留在 GPU 显存中以实现快速访问。随着模型上下文窗口的不断扩展，有时甚至达到数百万个 token，KV 缓存便成为了一个严重的瓶颈。
|
||||
|
||||
## 为什么 KV 缓存是 LLM 推理的瓶颈？
|
||||
|
||||
GPU 显存有限且成本高昂。随着提示长度的增加，KV 缓存也会不断增大，在生成过程中需要占用更多内存。在多轮对话、深入研究和代码生成等应用场景中，KV 缓存必须在内存中长时间保留。当接近或达到 GPU 显存限制时，推理系统将面临权衡。他们可以：
|
||||
|
||||
- 删除 KV 缓存的部分内容，这会导致昂贵的重新计算
|
||||
- 限制提示词长度或上下文窗口，降低模型性能
|
||||
- 增加更多 GPU，增加运营成本
|
||||
|
||||
在 GPU 显存中长时间保留大量 KV cache 是不可扩展的，这迫使提供商在成本、延迟和功能之间进行权衡。
|
||||
|
||||
## Dynamo 如何帮助减少 KV 缓存瓶颈？
|
||||
|
||||
Dynamo 的最新版本支持 KV Cache 卸载功能，可将原本存储在有限 GPU 显存中的 KV Cache 实时传输至成本更低、容量更大的存储介质。该技术能够将 KV 缓存直接从 GPU 显存卸载到更具扩展性且经济高效的存储系统中，例如 CPU 内存、本地 SSD 或远程网络存储。借助 NVIDIA NIXL 这一低延迟传输库，Dynamo 能够在 GPU 显存与外部存储之间高效移动 KV 缓存块，整个过程无需中断模型推理，从而提升整体推理效率与资源利用率。
|
||||
|
||||
|
||||
|
||||
**图 1。KV 缓存卸载支持将 KV 缓存从有限的 GPU 显存即时传输到更经济高效的存储**
|
||||
|
||||
## KV 缓存卸载有哪些好处？
|
||||
|
||||
借助 KV 缓存卸载，推理服务提供商能够在不牺牲提示长度的前提下支持具有更长上下文窗口的模型。通过卸载 KV 缓存，可显著降低 GPU 显存占用，使集群能够同时处理更多用户请求，从而提升整体并发能力。这种方式减少了对额外 GPU 的需求，有助于降低基础设施成本。对于包含缓存输入 token 的提示，节省的成本可转化为折扣，惠及最终用户。
|
||||
|
||||
KV 缓存卸载还能避免昂贵的 KV 缓存重新计算，从而缩短响应时间并提升用户体验。最终，服务提供商将受益于更高的吞吐量和更低的单位 token 成本，进而增强推理服务的可扩展性与效率。
|
||||
|
||||
## 何时卸载 KV 缓存以重复使用
|
||||
|
||||
当 KV 缓存超出 GPU 显存，且缓存重用带来的收益超过数据传输开销时，将 KV 缓存卸载至 CPU 或外部存储将显著提升效率。这一策略在处理长上下文、高并发或资源受限的推理场景中尤为重要，例如：
|
||||
|
||||
- **长会话和多回合对话**：卸载可保留较大的提示词前缀，避免重新计算，并提高首个令牌延迟和吞吐量。
|
||||
- **高并发性**：空闲或部分对话可以移出 GPU 显存，允许活动请求在不达到内存限制的情况下继续进行。
|
||||
- **共享或重复内容**：跨用户或会话（例如系统提示和模板）重复使用会增加缓存点击率，尤其是在远程或跨实例共享时。
|
||||
- **受内存或成本限制的部署**：卸载到 RAM 或 SSD 可减少 GPU 需求，从而在不添加硬件的情况下允许更长的提示词或更多的用户。
|
||||
- **I/O 优化平台**：具有高主机设备带宽（例如 NVLINK C2C）或 GPU Direct Storage 的环境受益更多，因为传输延迟更低，并且可能与计算重叠。
|
||||
|
||||
## Dynamo 中的 KV 缓存卸载工作原理是什么？
|
||||
|
||||
Dynamo KV 块管理器（KVBM）是一个为缓存卸载和内存协调提供支持的系统，由三个主要层级构成：
|
||||
|
||||
- **模型集成层**：将 NVIDIA TensorRT-LLM 和 vLLM 等热门 AI 推理引擎（即将支持 SGLang）连接到 KVBM 系统。这消除了对特定模型集成的需求，并实现了跨不同引擎的一致功能。
|
||||
- **内存管理层**：处理内存的分配、组织和重用方式。它可以跟踪数据的所在位置，并使开发者能够在不影响整个系统的情况下自定义 KV 缓存卸载策略。
|
||||
- **使用 NIXL 的存储和数据传输层**：将 KVBM 连接到各种类型的存储，包括 CPU、SSD、文件系统和云平台。NIXL 支持跨机器的快速数据传输，并通过基于插件的系统简化了第三方存储提供商的集成。
|
||||
|
||||
|
||||
|
||||
**图 2。Dynamo KV 区块管理器与 LLM 推理生态系统的不同组件交互**
|
||||
|
||||
通过将内存管理与特定模型引擎分离，并标准化存储访问，KVBM 简化了集成与可扩展性。存储提供商不再需要为不同的推理引擎定制系统，因为 KVBM 负责处理翻译工作。该架构有助于提升性能、简化开发流程，并支持存储与计算的独立演进。
|
||||
|
||||
## Dynamo 如何与 LMCache 集成？
|
||||
|
||||
Dynamo 的核心设计原则是开放性，允许用户在内置功能与第三方集成之间自由选择。为此，Dynamo 集成了 LMCache，一个开源系统，用于在 CPU、本地及远程存储中缓存和重用 token。
|
||||
|
||||
LMCache 为 vLLM 等推理引擎提供 KV 缓存层。它能够将频繁使用的数据（例如对话历史记录或提示）从 GPU 卸载至成本更低的存储中，并针对大规模或重复性工作负载提供智能的驱逐与检索策略。对于使用 vLLM 的团队，LMCache 提供了一个强大的 KV 缓存管理解决方案，与 Dynamo 开放架构保持一致。
|
||||
|
||||
## 存储提供商如何利用 KV 缓存卸载？
|
||||
|
||||
Vast 测试了 NVIDIA Dynamo 与 Vast AI OS 之间的高性能集成，以实现 GPU 和存储之间持久性 KV 缓存的高效移动。通过在 Dynamo 中启用 GPU Direct Storage (GDS) 插件，Vast 在单个 NVIDIA H100 GPU 上实现了 35 GB/秒的吞吐量，充分表明 GPU 资源得到充分利用，同时验证了存储系统不会成为性能瓶颈。
|
||||
|
||||
在另一项测试中，Vast 验证了在 NVIDIA DGX H100 系统上使用 vLLM 和 LMCache 复用持久性 KV 缓存的效果。运行 Qwen3-32B 模型处理 130K token 提示时，系统从 Vast 存储中加载了预先计算的 KV 缓存，而非重新计算，从而显著缩短了首个 token 的生成时间（TTFT）。
|
||||
|
||||
WEKA 在实验室测试中，结合使用 NVIDIA Dynamo 以及由 WEKA 开发并开源的自定义 NIXL 插件，对 GPU 与存储之间的高性能 KV 缓存传输进行了评估。测试结果表明，WEKA 的增强内存网格能够以接近显存的速度将 KV 缓存从 token 仓库流式传输至 GPU，从而缩短首次 token 生成时间（TTFT），并提升推理工作负载的整体 token 吞吐量。
|
||||
|
||||
测试使用配备 8 个 H100 GPU 的 DGX 系统执行。该设置在 8 个 GPU 上实现了高达 270 GB/秒的读取吞吐量，证明 WEKA 基于 RDMA 的零拷贝数据路径能够满足分解推理对 token 传输的需求，而不会成为瓶颈。
|
||||
|
||||
这些测试结果凸显了将 KV 缓存卸载到存储的潜力，可支持分布式环境中大上下文、高吞吐量的生成式 AI 工作负载。
|
||||
|
||||
## 如何使用 Dynamo KVBM 管理 KV 缓存
|
||||
|
||||
要使用 KVBM 管理 KV cache 并在 vLLM 中执行 KV 卸载，请按以下步骤操作：
|
||||
|
||||
```
|
||||
# start up etcd for KVBM leader/worker registration and discovery
|
||||
docker compose -f deploy/docker-compose.yml up -d
|
||||
|
||||
# build a container containing vllm and kvbm
|
||||
./container/build.sh --framework vllm --enable-kvbm
|
||||
|
||||
# launch the container
|
||||
./container/run.sh --framework vllm -it --mount-workspace --use-nixl-gds
|
||||
|
||||
# enable kv offloading to CPU memory
|
||||
# 4 means 4GB of CPU memory would be used
|
||||
export DYN_KVBM_CPU_CACHE_GB=4
|
||||
|
||||
# enable kv offloading to disk
|
||||
# 8 means 8GB of disk would be used
|
||||
export DYN_KVBM_DISK_CACHE_GB=8
|
||||
|
||||
# serve an example LLM model
|
||||
vllm serve --kv-transfer-config
|
||||
'{"kv_connector":"DynamoConnector","kv_role":"kv_both",
|
||||
"kv_connector_module_path": "dynamo.llm.vllm_integration.connector"}'
|
||||
deepseek-ai/DeepSeek-R1-Distill-Llama-8B
|
||||
|
||||
# make a call to LLM
|
||||
curl localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
|
||||
"model": "deepseek-ai/DeepSeek-R1-Distill-Llama-8B",
|
||||
"messages": [
|
||||
{
|
||||
"role": "user",
|
||||
"content": "In the heart of Eldoria, an ancient land of boundless magic and mysterious creatures, ..."
|
||||
}
|
||||
],
|
||||
"stream":false,
|
||||
"max_tokens": 30
|
||||
}'
|
||||
```
|
||||
|
||||
### 启用和查看 KVBM 指标
|
||||
|
||||
要通过 Grafana 控制面板启用指标收集和查看，请按照以下步骤操作：
|
||||
|
||||
```
|
||||
# Start the basic services (etcd & natsd), along with Prometheus and Grafana
|
||||
docker compose -f deploy/docker-compose.yml --profile metrics up -d
|
||||
|
||||
# start vllm with DYN_SYSTEM_ENABLED set to true and DYN_SYSTEM_PORT port to 6880.
|
||||
# NOTE: Make sure port 6880 (for KVBM worker metrics) and port 6881
|
||||
(for KVBM leader metrics) are available.
|
||||
DYN_SYSTEM_ENABLED=true DYN_SYSTEM_PORT=6880 vllm serve --kv-transfer-config
|
||||
'{"kv_connector":"DynamoConnector","kv_role":"kv_both",
|
||||
"kv_connector_module_path":
|
||||
"dynamo.llm.vllm_integration.connector"}'
|
||||
deepseek-ai/DeepSeek-R1-Distill-Llama-8B
|
||||
|
||||
# optional if firewall blocks KVBM metrics ports to send prometheus metrics
|
||||
sudo ufw allow 6880/tcp
|
||||
sudo ufw allow 6881/tcp
|
||||
```
|
||||
|
||||
通过 `http://localhost:3001` 查看 Grafana 指标（默认登录名：dynamo/dynamo），并查找 KVBM 控制面板。
|
||||
|
||||
### 基准 KVBM
|
||||
|
||||
当 vLLM 服务器准备就绪后，请按照以下步骤使用 LMBenchmark 对 KVBM 性能进行基准测试：
|
||||
|
||||
```
|
||||
git clone https://github.com/LMCache/LMBenchmark.git
|
||||
|
||||
# show case of running the synthetic multi-turn chat dataset.
|
||||
# we are passing model, endpoint, output file prefix and qps to the sh script.
|
||||
cd LMBenchmark/synthetic-multi-round-qa
|
||||
./long_input_short_output_run.sh \
|
||||
"deepseek-ai/DeepSeek-R1-Distill-Llama-8B" \
|
||||
"http://localhost:8000" \
|
||||
"benchmark_kvbm" \
|
||||
1
|
||||
|
||||
# Average TTFT and other perf numbers would be in the output from above cmd
|
||||
```
|
||||
|
||||
如需详细了解 LMBenchmark 的使用方法，请访问 LMCache/LMBenchmark GitHub 库。
|
||||
|
||||
请注意，如果如上一部分所述启用了指标，您可以在 Grafana 控制面板中观察 KV 卸载和 KV 载入情况。
|
||||
|
||||
为便于比较，您可以运行 `vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-8B` 来关闭 KVBM，以此作为基准。
|
||||
|
||||
## 如何使用 LMCache 和 vLLM 开始使用 Dynamo
|
||||
|
||||
通过设置环境变量来启用 LMCache：
|
||||
|
||||
- `export ENABLE_LMCACHE=1`
|
||||
|
||||
您可以通过环境变量来自定义 LMCache 的其他配置。
|
||||
|
||||
- `LMCACHE_CHUNK_SIZE=256` – 缓存粒度的令牌块大小（默认值：256）
|
||||
- `LMCACHE_LOCAL_CPU=True` – 启用基于 CPU 内存的后端进行卸载
|
||||
- `LMCACHE_MAX_LOCAL_CPU_SIZE=20` – CPU 显存限制（以 GB 为单位）（用户可根据可用内存将其设置为固定值）
|
||||
|
||||
对于高级配置，LMCache 支持多种存储后端：
|
||||
|
||||
- **CPU RAM**：快速本地内存卸载
|
||||
- **本地存储**：基于磁盘的持久性
|
||||
- **Redis**：分布式缓存共享
|
||||
- **GDS 后端**：用于高吞吐量的 GPU Direct Storage
|
||||
- **InfiniStore/Mooncake**：云原生存储解决方案
|
||||
|
||||
要开始使用 LMCache 和 vLLM 配合 Dynamo，请执行以下步骤：
|
||||
|
||||
```
|
||||
# start up etcd for KVBM leader/worker registration and discovery
|
||||
docker compose -f deploy/docker-compose.yml up -d
|
||||
|
||||
# build a container containing vllm and kvbm
|
||||
./container/build.sh --framework vllm
|
||||
|
||||
# launch the container
|
||||
./container/run.sh --framework vllm -it --mount-workspace
|
||||
|
||||
# run vllm with lmcache in aggregated inference
|
||||
./components/backends/vllm/launch/agg_lmcache.sh
|
||||
|
||||
# run vllm with lmcache in disaggregated inference
|
||||
./components/backends/vllm/launch/disagg_lmcache.sh
|
||||
```
|
||||
|
||||
请注意，必要的环境变量已包含在 `.sh` 脚本中，便于快速配置。请根据需要进行更新。
|
||||
|
||||
## 总结
|
||||
|
||||
随着大语言模型（LLM）的不断扩展，由于 GPU 显存有限且成本高昂，推理过程中管理 KV 缓存已成为一项重大挑战。NVIDIA Dynamo 通过支持将 KV 缓存卸载至 CPU 内存、SSD 和网络存储等更具可扩展性的存储选项，有效应对这一难题，该功能由低延迟的 NIXL 传输库提供支持。
|
||||
|
||||
Dynamo 与 vLLM 等热门推理引擎以及 LMCache 等开源工具无缝集成，可实现高效的缓存重用、减少重复计算，并更好地支持长上下文和高并发工作负载。Vast 和 WEKA 等存储提供商已成功集成 Dynamo，展示了高吞吐量存储系统如何在不成为瓶颈的前提下，高效地卸载和流式传输 KV 缓存。
|
||||
|
||||
这些功能使 KV Cache 卸载成为一种实用且可扩展的解决方案，能够降低推理成本、提升响应速度，并支持大规模生成式 AI 应用的更广泛部署。了解详情并开始使用 Dynamo。
|
||||
@@ -0,0 +1,78 @@
|
||||
# 📊 文章摘要：如何使用 NVIDIA Dynamo 减少 KV 缓存瓶颈
|
||||
|
||||
> **原文**：[2025-09-18_如何使用_NVIDIA_Dynamo_减少_KV_缓存瓶颈.md](./2025-09-18_如何使用_NVIDIA_Dynamo_减少_KV_缓存瓶颈.md)
|
||||
> **原文链接**：https://developer.nvidia.cn/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/
|
||||
> **来源**：NVIDIA 技术博客
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-09-18
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **缓存外移** — 将 KV 缓存从昂贵有限的 GPU 显存卸载至 CPU 内存、SSD 与网络存储，以存储成本换取 GPU 算力与并发能力。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文介绍 NVIDIA Dynamo 的 KV 缓存卸载能力：KV 缓存随提示长度线性增长且须驻留显存，在长上下文与高并发下成为推理瓶颈，迫使服务商在成本、延迟、功能之间权衡。Dynamo 通过 KV 块管理器（KVBM）的"模型集成层-内存管理层-NIXL 存储传输层"三层架构，将缓存实时卸载至 CPU、SSD 或远程存储，避免重新计算、提升并发、降低成本。文章给出卸载的适用条件（缓存重用收益超过传输开销）、与 LMCache 的集成方式、可复现的 vLLM 操作步骤，以及 Vast（单 H100 达 35GB/s）与 WEKA（8×H100 达 270GB/s）的实测数据。局限在于实测均出自存储厂商自报，缺少端到端成本收益量化。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **KV 缓存是显存瓶颈** — 随提示长度线性增长且必须驻留 HBM，长上下文下迫使在删缓存重算、限制上下文、增加 GPU 之间权衡 `[分类: 共识]`
|
||||
2. **KVBM 三层架构** — 模型集成层（TensorRT-LLM/vLLM，SGLang 即将支持）解耦引擎差异；内存管理层可自定义卸载策略；NIXL 传输层统一接入 CPU/SSD/文件系统/云存储 `[分类: 共识]`
|
||||
3. **NIXL 低延迟传输** — 支持跨机器快速传输与基于插件的第三方存储接入，卸载过程不中断模型推理 `[分类: 共识]`
|
||||
4. **卸载适用条件** — 仅当缓存重用收益超过传输开销时合算，典型场景：长会话、高并发、共享前缀、受内存/成本限制的部署、具备 GDS/NVLink C2C 的高带宽环境 `[分类: 共识]`
|
||||
5. **开放生态集成** — 集成开源 LMCache 为 vLLM 提供缓存层，支持 CPU RAM、本地存储、Redis、GDS、InfiniStore/Mooncake 等后端 `[分类: 共识]`
|
||||
6. **第三方实测数据** — Vast 在单 H100 上经 GDS 插件达 35GB/s；WEKA 在 8×H100 DGX 上达 270GB/s 读取，Qwen3-32B 处理 130K token 提示时复用预计算缓存显著缩短 TTFT `[分类: 争议]`（数据来自存储厂商自测）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 GPU 与存储之间具备足够带宽（GDS、RDMA 或 NVLink C2C），且传输延迟可被计算重叠掩盖；假设工作负载的缓存重用率足够高，使卸载收益超过开销。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
Vast 与 WEKA 的测试聚焦"传输带宽"而非端到端经济性，论证了存储系统不是瓶颈，但未直接证明"降低推理成本"；文章缺乏卸载前后 TTFT、吞吐与总拥有成本的对照数据，结论部分依赖推断而非证据。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
对无 GDS、NVLink C2C 等高速互连的普通环境，传输开销可能吞噬卸载收益，文中未给出量化判断标准；缓存一致性、多机同步、KV 块生命周期管理未展开；教程面向 vLLM，SGLang 等其他引擎支持尚不完整。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "在 GPU 显存中长时间保留大量 KV cache 是不可扩展的，这迫使提供商在成本、延迟和功能之间进行权衡。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- KVBM 三层架构清晰，存储与推理引擎解耦的设计思路有借鉴价值
|
||||
- 提供完整可复现的操作步骤与基准测试方法（LMBenchmark）
|
||||
- 明确给出"何时卸载"的边界条件，而非无条件的方案推销
|
||||
|
||||
**不足**：
|
||||
- 收益数据全部来自存储厂商自测，缺少独立第三方验证
|
||||
- 没有端到端成本模型，无法直接用于投资回报评估
|
||||
- 分布式场景下的缓存一致性与故障处理着墨甚少
|
||||
|
||||
**适用场景**：推理系统架构师、SRE 与平台工程师评估长上下文/高并发推理优化方案；希望动手复现 KV 缓存卸载的工程团队。
|
||||
|
||||
**关联建议**：可进一步阅读月之暗面 Mooncake 论文（全局调度+分布式 KV 缓存池）、NVIDIA Dynamo 官方文档与 LMCache GitHub 仓库；对比信通院 2026 报告中的多级存储与 PD 分离章节可获更完整上下文。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,365 @@
|
||||
# PD 分离 (PD Disaggregation) — SGLang 框架
|
||||
|
||||
> **来源**：SGLang 官方文档
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-12-30
|
||||
> **原文链接**：https://docs.sglang.com.cn/advanced_features/pd_disaggregation.html
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
- 什么是 PD 分离，为什么要使用它？
|
||||
- 统一调度存在的问题
|
||||
- 在 PD 分离模式下进行性能分析 (Profiling)
|
||||
- Router 集成
|
||||
- Mooncake
|
||||
- 环境要求
|
||||
- 用法
|
||||
- Llama 单节点
|
||||
- DeepSeek 多节点
|
||||
- 高级配置
|
||||
- NVLink 传输配置
|
||||
- Prefill 服务端配置
|
||||
- Decode 服务端配置
|
||||
- NIXL
|
||||
- 环境要求
|
||||
- 用法
|
||||
- Llama 单节点
|
||||
- DeepSeek 多节点
|
||||
- 昇腾 (ASCEND)
|
||||
- 用法
|
||||
- Llama 单节点
|
||||
- DeepSeek 多节点
|
||||
|
||||
## PD 分离
|
||||
|
||||
## 什么是 PD 分离，为什么要使用它？
|
||||
|
||||
大语言模型 (LLM) 推理包含两个不同的阶段：__Prefill (预填充)__ 和 __Decode (解码)__。Prefill 阶段是计算密集型的，处理整个输入序列；而 Decode 阶段是内存密集型的，管理用于逐个生成 token 的 Key-Value (KV) 缓存。传统上，这两个阶段在统一的引擎中处理，混合调度 prefill 和 decode 批次会导致效率低下。为了解决这些挑战，我们在 SGLang 中引入了 __Prefill 和 Decoding (PD) 分离__。
|
||||
|
||||
### 统一调度存在的问题
|
||||
|
||||
传统的统一引擎同时处理 prefill 和 decode 批次，这会导致两个显著问题：
|
||||
|
||||
1. __Prefill 中断__：新进入的 prefill 批次经常中断正在进行的 decode 批次，导致 token 生成出现大幅延迟。
|
||||
2. __DP Attention 不平衡__：在数据并行 (DP) 注意力机制中，一个 DP 工作进程可能正在处理 prefill 批次，而另一个同时处理 decode 批次，导致解码延迟增加。
|
||||
|
||||
PD 分离通过将这两个阶段分开来解决这些问题，从而能够为每个阶段进行针对性优化。
|
||||
|
||||
有关设计详情，请参阅[链接](https://arxiv.org/abs/2404.12599)（DistServe 论文）。
|
||||
|
||||
目前，我们支持 Mooncake 和 NIXL 作为传输引擎。
|
||||
|
||||
## 在 PD 分离模式下进行性能分析 (Profiling)
|
||||
|
||||
当您需要在 PD 分离模式下对 prefill 或 decode 工作进程进行性能分析时，请参阅"基准测试与性能分析"指南中的"在 PD 分离模式下进行性能分析"章节。由于 torch profiler 的限制，必须使用专用的命令行选项分别对 prefill 和 decode 工作进程进行分析。
|
||||
|
||||
## Router 集成
|
||||
|
||||
为了在大规模部署 PD 分离并实现负载均衡和容错，SGLang 提供了一个 Router (路由器)。Router 可以使用各种路由策略在 prefill 和 decode 实例之间分配请求。有关使用 PD 分离设置路由的详细信息（包括配置选项和部署模式），请参阅 [SGLang Router 文档](https://docs.sglang.ai/backend/router.html)。
|
||||
|
||||
## Mooncake
|
||||
|
||||
### 环境要求
|
||||
|
||||
```
|
||||
uv pip install mooncake-transfer-engine
|
||||
```
|
||||
|
||||
### 用法
|
||||
|
||||
### Llama 单节点
|
||||
|
||||
```
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode prefill \
|
||||
--port 30000 \
|
||||
--disaggregation-ib-device mlx5_roce0
|
||||
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode decode \
|
||||
--port 30001 \
|
||||
--base-gpu-id 1 \
|
||||
--disaggregation-ib-device mlx5_roce0
|
||||
|
||||
python -m sglang_router.launch_router --pd-disaggregation --prefill http://127.0.0.1:30000 --decode http://127.0.0.1:30001 --host 0.0.0.0 --port 8000
|
||||
```
|
||||
|
||||
### DeepSeek 多节点
|
||||
|
||||
```
|
||||
# prefill 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-ib-device ${device_name} \
|
||||
--disaggregation-mode prefill \
|
||||
--host ${local_ip} \
|
||||
--port 30000 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${prefill_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8
|
||||
|
||||
# prefill 1
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-ib-device ${device_name} \
|
||||
--disaggregation-mode prefill \
|
||||
--host ${local_ip} \
|
||||
--port 30000 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${prefill_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 1 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8
|
||||
|
||||
# decode 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-ib-device ${device_name} \
|
||||
--disaggregation-mode decode \
|
||||
--host ${local_ip} \
|
||||
--port 30001 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${decode_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8 \
|
||||
--max-running-requests 128
|
||||
|
||||
# decode 1
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-ib-device ${device_name} \
|
||||
--disaggregation-mode decode \
|
||||
--host ${local_ip} \
|
||||
--port 30001 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${decode_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 1 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8 \
|
||||
--max-running-requests 128
|
||||
```
|
||||
|
||||
### 高级配置
|
||||
|
||||
带有 Mooncake 的 PD 分离支持以下环境变量，用于对系统行为进行精细控制。
|
||||
|
||||
#### NVLink 传输配置
|
||||
|
||||
若要为使用 mooncake 后端的 KV cache 传输启用 NVLink 传输（建议在 NVL72 部署中使用），请设置以下环境变量。请注意，作为临时方案，辅助数据传输仍将使用 TCP。
|
||||
|
||||
```
|
||||
export SGLANG_MOONCAKE_CUSTOM_MEM_POOL=True
|
||||
export MC_FORCE_MNNVL=True
|
||||
```
|
||||
|
||||
#### Prefill 服务端配置
|
||||
|
||||
如果可以接受较大的平均 TTFT，可以执行 `export SGLANG_DISAGGREGATION_BOOTSTRAP_TIMEOUT=600`（10 分钟）以放宽超时条件。请注意，此设置会导致当运行中的 decode 节点断开连接时，prefill 实例需要更长时间来清理受影响的内存资源。
|
||||
|
||||
#### Decode 服务端配置
|
||||
|
||||
如果可以接受较大的平均 TTFT，可以执行 `export SGLANG_DISAGGREGATION_WAITING_TIMEOUT=600`（10 分钟）以放宽超时条件。
|
||||
|
||||
## NIXL
|
||||
|
||||
### 环境要求
|
||||
|
||||
通过 pip 安装。
|
||||
|
||||
或从源码构建 - 如果您已经安装了 UCX，可能需要这样做。
|
||||
|
||||
```
|
||||
git clone https://github.com/ai-dynamo/nixl.git
|
||||
cd nixl
|
||||
pip install . --config-settings=setup-args="-Ducx_path=/path/to/ucx"
|
||||
```
|
||||
|
||||
### 使用方法
|
||||
|
||||
### Llama 单节点
|
||||
|
||||
```
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode prefill \
|
||||
--port 30000 \
|
||||
--disaggregation-transfer-backend nixl
|
||||
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode decode \
|
||||
--port 30001 \
|
||||
--base-gpu-id 1 \
|
||||
--disaggregation-transfer-backend nixl
|
||||
|
||||
python -m sglang_router.launch_router --pd-disaggregation --prefill http://127.0.0.1:30000 --decode http://127.0.0.1:30001 --host 0.0.0.0 --port 8000
|
||||
```
|
||||
|
||||
### DeepSeek 多节点
|
||||
|
||||
```
|
||||
# prefill 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend nixl \
|
||||
--disaggregation-mode prefill \
|
||||
--host ${local_ip} \
|
||||
--port 30000 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${prefill_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8
|
||||
|
||||
# prefill 1
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend nixl \
|
||||
--disaggregation-mode prefill \
|
||||
--host ${local_ip} \
|
||||
--port 30000 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${prefill_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 1 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8
|
||||
|
||||
# decode 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend nixl \
|
||||
--disaggregation-mode decode \
|
||||
--host ${local_ip} \
|
||||
--port 30001 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${decode_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8 \
|
||||
--max-running-requests 128
|
||||
|
||||
# decode 1
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend nixl \
|
||||
--disaggregation-mode decode \
|
||||
--host ${local_ip} \
|
||||
--port 30001 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${decode_master_ip}:5000 \
|
||||
--nnodes 2 \
|
||||
--node-rank 1 \
|
||||
--tp-size 16 \
|
||||
--dp-size 8 \
|
||||
--enable-dp-attention \
|
||||
--moe-a2a-backend deepep \
|
||||
--mem-fraction-static 0.8 \
|
||||
--max-running-requests 128
|
||||
```
|
||||
|
||||
## 昇腾 (ASCEND)
|
||||
|
||||
### 使用方法
|
||||
|
||||
通过设置 ASCEND_MF_STORE_URL 并使用 mf_adapter（[下载链接](https://github.com/sgl-project/sglang/releases)）来配合 ascend 后端使用
|
||||
|
||||
```
|
||||
pip install mf_adapter-1.0.0-cp311-cp311-linux_aarch64.whl --force-reinstall
|
||||
export ASCEND_MF_STORE_URL="tcp://xxx.xx.xxx.xxx:xxxx"
|
||||
```
|
||||
|
||||
使用 mooncake 后端，更多详情可以在 mooncake 章节中找到。
|
||||
|
||||
```
|
||||
export ENABLE_ASCEND_TRANSFER_WITH_MOONCAKE=true
|
||||
```
|
||||
|
||||
需要在容器环境变量中设置 ASCEND_NPU_PHY_ID
|
||||
|
||||
```
|
||||
export ASCEND_NPU_PHY_ID=xxx
|
||||
```
|
||||
|
||||
### Llama 单节点
|
||||
|
||||
```
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode prefill \
|
||||
--port 30000 \
|
||||
--disaggregation-transfer-backend ascend
|
||||
|
||||
python -m sglang.launch_server \
|
||||
--model-path meta-llama/Llama-3.1-8B-Instruct \
|
||||
--disaggregation-mode decode \
|
||||
--port 30001 \
|
||||
--base-gpu-id 1 \
|
||||
--disaggregation-transfer-backend ascend
|
||||
|
||||
python -m sglang_router.launch_router --pd-disaggregation --prefill http://127.0.0.1:30000 --decode http://127.0.0.1:30001 --host 0.0.0.0 --port 8000
|
||||
```
|
||||
|
||||
### DeepSeek 多节点
|
||||
|
||||
```
|
||||
# prefill 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend ascend \
|
||||
--disaggregation-mode prefill \
|
||||
--host ${local_ip} \
|
||||
--port 30000 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${prefill_master_ip}:5000 \
|
||||
--nnodes 1 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16
|
||||
|
||||
# decode 0
|
||||
python -m sglang.launch_server \
|
||||
--model-path deepseek-ai/DeepSeek-V3-0324 \
|
||||
--disaggregation-transfer-backend ascend \
|
||||
--disaggregation-mode decode \
|
||||
--host ${local_ip} \
|
||||
--port 30001 \
|
||||
--trust-remote-code \
|
||||
--dist-init-addr ${decode_master_ip}:5000 \
|
||||
--nnodes 1 \
|
||||
--node-rank 0 \
|
||||
--tp-size 16
|
||||
```
|
||||
@@ -0,0 +1,76 @@
|
||||
# 📊 文章摘要：PD 分离 (PD Disaggregation) — SGLang 框架
|
||||
|
||||
> **原文**：[2025-12-30_PD_分离_PD_Disaggregation_SGLang_框架.md](./2025-12-30_PD_分离_PD_Disaggregation_SGLang_框架.md)
|
||||
> **原文链接**：https://docs.sglang.com.cn/advanced_features/pd_disaggregation.html
|
||||
> **来源**：SGLang 官方文档
|
||||
> **作者**：未知
|
||||
> **发布日期**：2025-12-30
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **PD 分离** — 将计算密集的 Prefill 与内存密集的 Decode 拆分为独立实例并跨机传输 KV，是长上下文、高并发推理的关键架构方向。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
SGLang 官方文档系统介绍了 PD 分离（Prefill/Decode 分离）架构：LLM 推理的 Prefill 阶段计算密集、Decode 阶段内存密集，统一引擎混排会导致 Prefill 频繁打断 Decode 造成生成延迟抖动，以及 DP Attention 负载失衡。方案源自 DistServe 论文思路，通过把两个阶段部署到独立 GPU 实例、经高速网络传输 KV Cache，实现各阶段独立调优。文档给出 Mooncake、NIXL、昇腾三套传输后端的单节点与 DeepSeek 多节点部署命令，以及 Router 负载均衡、NVLink 传输等高级配置。作为官方部署手册，工程可操作性极强，但未提供性能基准数据，收益需自行实测。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **混排调度的两大痛点** — Prefill 中断（新批次打断正在进行的 decode）与 DP Attention 不平衡（不同 DP 工作进程负载错配）是统一引擎的核心缺陷，PD 分离逐一化解 `[分类: 共识]`
|
||||
2. **分阶段独立优化** — Prefill 按计算密集优化、Decode 按内存密集优化，设计依据为 DistServe 论文（arXiv:2404.12599）`[分类: 共识]`
|
||||
3. **三种传输后端** — Mooncake、NIXL、昇腾（ASCEND）覆盖英伟达与国产硬件生态，DeepSeek 多节点示例展示了 TP16×DP8 的真实规模配置 `[分类: 共识]`
|
||||
4. **Router 是规模化前提** — 大规模 PD 分离部署需 Router 实现负载均衡与容错，SGLang 提供独立 router 组件在 prefill/decode 实例间分配请求 `[分类: 共识]`
|
||||
5. **配置即显式权衡** — 放宽 bootstrap/waiting 超时意味着接受更大平均 TTFT，但 decode 节点断连时内存清理更慢；NVLink 传输专为 NVL72 部署建议，辅助数据暂走 TCP `[分类: 共识]`
|
||||
6. **国产硬件适配路径** — 昇腾后端经 mf_adapter 与 ASCEND_MF_STORE_URL 接入 mooncake 后端，体现 PD 分离架构的硬件中立性 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论假设读者具备 LLM 推理与分布式部署基础；假定 KV 传输带宽足以覆盖 PD 分离的额外开销（否则收益被抵消）；假定多实例部署带来的硬件与管理成本可以接受——这些前提在中小规模场景未必成立。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
文档以 DistServe 论文为设计依据，逻辑自洽，但未给出 SGLang 实现下的任何实测性能对比（TTFT、吞吐提升的具体数字缺失），"提升效率"的结论依赖外部基准或读者自行验证；配置项的代价说明清晰，是本文质量较高之处。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
仅适用于 SGLang 框架生态；单节点小规模场景下 PD 分离收益有限，却引入多端口、Router、RDMA 设备等运维负担；Mooncake/NIXL 为较新组件，生产稳定性有待验证；文档未展开 KV 传输带宽瓶颈与失败恢复机制等工程细节。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD 分离通过将这两个阶段分开来解决这些问题，从而能够为每个阶段进行针对性优化。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 官方一手部署文档，覆盖三种传输后端与国产硬件，示例完整（单节点/多节点/环境变量）可直接照做
|
||||
- 明确标注配置权衡与临时方案（如 NVLink 辅助数据暂走 TCP），工程透明度高
|
||||
|
||||
**不足**：
|
||||
- 无任何性能基准数据，无法量化收益；架构原理着墨少（主要指向外部论文），初学者理解门槛高
|
||||
- 未涉及失败恢复、运维监控等生产细节
|
||||
|
||||
**适用场景**：需要为长上下文、高并发推理服务实施 PD 分离的 SGLang 用户与平台工程师；作为该功能的部署手册与配置参考。
|
||||
|
||||
**关联建议**：阅读 DistServe 论文（arXiv:2404.12599）理解原理；对比 vLLM 的 PD 分离与 Mooncake/KVCache 池化项目；结合《GTC 解读：当我们谈论 AI 推理的 KV Cache》理解 PD 分离在全局 KV 存储体系中的位置。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,263 @@
|
||||
# TetriInfer: Inference without Interference - Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
|
||||
> **来源**：arXiv
|
||||
> **作者**：Cunchen Hu, Heyang Huang, Liangliang Xu, Xusheng Chen, Jiang Xu, Shuang Chen, Hao Feng, Chenxi Wang, Sa Wang, Yungang Bao, Ninghui Sun, Yizhou Shan（等，共 12 位）
|
||||
> **发布日期**：2024-01-20
|
||||
> **原文链接**：https://arxiv.org/abs/2401.11181
|
||||
|
||||
---
|
||||
|
||||
## 论文元数据
|
||||
|
||||
- **arXiv ID**：2401.11181
|
||||
- **学科分类**：Distributed, Parallel, and Cluster Computing (cs.DC)
|
||||
- **作者机构**：中国科学院大学、中科院计算所（ICT, CAS）、华为云（Huawei Cloud）
|
||||
- **提交历史**：v1: 2024-01-20
|
||||
- **DOI**：https://doi.org/10.48550/arXiv.2401.11181
|
||||
|
||||
---
|
||||
|
||||
Cunchen Hu1,2111Work done while intern at Huawei Cloud.,
|
||||
Heyang Huang1,2,
|
||||
Liangliang Xu3,
|
||||
Xusheng Chen3,
|
||||
Jiang Xu3,
|
||||
Shuang Chen3,
|
||||
|
||||
Hao Feng3,
|
||||
Chenxi Wang1,2,
|
||||
Sa Wang1,2,
|
||||
Yungang Bao1,2,
|
||||
Ninghui Sun1,2,
|
||||
Yizhou Shan3
|
||||
|
||||
1University of Chinese Academy of Sciences, 2ICT, CAS
|
||||
3Huawei Cloud
|
||||
|
||||
## 摘要（Abstract）
|
||||
|
||||
Transformer-based large language model (LLM) inference serving is now the backbone of many cloud services.
|
||||
LLM inference consists of a prefill phase and a decode phase.
|
||||
However, existing LLM deployment practices often overlook the distinct characteristics of these phases, leading to significant interference.
|
||||
To mitigate interference, our insight is to carefully schedule and group inference requests based on their characteristics. We realize this idea in TetriInfer through three pillars. First, it partitions prompts into fixed-size chunks so that the accelerator always runs close to its computation-saturated limit. Second, it disaggregates prefill and decode instances so each can run independently. Finally, it uses a smart two-level scheduling algorithm augmented with predicted resource usage to avoid decode scheduling hotspots.
|
||||
Results show that TetriInfer improves time-to-first-token (TTFT), job completion time (JCT), and inference efficiency in turns of performance per dollar by a large margin, e.g., it uses 38% less resources all the while lowering average TTFT and average JCT by 97% and 47%, respectively.
|
||||
|
||||
## 1 引言（Introduction）
|
||||
|
||||
Since the boom of ChatGPT, large language model (LLM) based services have now played a vital role in our daily lives[4, 38, 20, 9, 34, 31].
|
||||
Behind the scenes, all use cases boil down to LLM inference serving. To run an inference request, the LLM model will first take the user inputs to generate the first token (known as the prefill phase), and then generate outputs token-by-token in an auto-regressive manner (known as the decode phase).
|
||||
Numerous works were proposed to improve the cost efficiency of LLM inference [21, 41].
|
||||
|
||||
There are various ways to interact with LLM, from simple chats to more complex downstream tasks such as document summarization, content creation, etc.
|
||||
As a result, LLM-empowered services serve inference requests with dramatically different properties that can be categorized across two dimensions: the input prompt length during the prefill phase and the generated token length during the decode phase.
|
||||
As shown in Figure 1, summarization tasks have long input prompts and short generated tokens, while context creation tasks are the opposite.
|
||||
Token lengths of different downstream tasks can differ by more than two orders of magnitude.
|
||||
Given the significant variation in LLM inference requests from various downstream tasks, the first research question we ask in this paper is how do these inference requests perform when running together?.
|
||||
|
||||
To answer this question, we run extensive tests that mix LLM prefill and decode requests of different lengths.
|
||||
Unfortunately, we have observed serious interference across all combinations. For example, mixing prefill requests could result in a 10x slowdown, combining prefill and decode requests could lead to a 5x slowdown, and mixing decode requests with different lengths could take a 16% throughput hit (see §2.2).
|
||||
A naive solution to avoid interference is to provision resources for each downstream task statically. Given the high cost of LLM serving infrastructure, this solution is impractical.
|
||||
To this end, the second research question we ask in this paper is how to build a distributed LLM inference serving system that minimizes interferences?
|
||||
|
||||
We take a step back to examine why interference exists. We find the fundamental issue lies in the fact that current LLM deployment practices do not account for the distinct characteristics exhibited by LLM prefill and decode phases.
|
||||
Specifically, the prefill phase resembles a computation-heavy batch job, with its computation scaling quadratically with the input prompt length.
|
||||
The decode phase resembles a memory-intensive, latency-critical task, with its resource usage scaling sublinearly with the generated token length [33].
|
||||
Interferences observed in our tests are classic system problems.
|
||||
Running prefill requests leads to a serious slowdown because we continue adding computation-heavy jobs to an already saturated hardware (§2.2.1).
|
||||
Combining prefill and decode requests hurts both because we co-run batch and latency-critical jobs simultaneously (§2.2.2).
|
||||
Mixing decode requests leads to a throughput drop because we are unaware of the memory bandwidth and capacity usage, thus leading to contention and head-of-line blocking (§2.2.3).
|
||||
|
||||
To solve these issues, our insight is to carefully schedule and group requests based on their characteristics.
|
||||
We realize this idea in TetriInfer222The name of our system, TetriInfer, implies that it can efficiently organize LLM inference requests, similar to how tetris blocks are stacked., a cloud-scale LLM inference
|
||||
serving system designed to battle interferences.
|
||||
|
||||
Our designs are three-fold.
|
||||
First, to avoid interference running prefill, we propose limiting the number of tokens processed in a single prefill iteration so that hardware is fully utilized without incurring extra penalties. TetriInfer partitions and pads input prompts into fixed-size chunks so that the accelerator always runs close to its computation-saturated limit (§3.3).
|
||||
Second, to avoid interference in co-running prefill and decode, we propose disaggregating prefill from decode phases.
|
||||
TetriInfer has dedicated prefill and decode instances.
|
||||
During runtime, prefill instances transfer prefilled KV cache to decode instances.
|
||||
The prefill and decode instances are virtual concepts in that
|
||||
each can scale independently and flip roles if load changes (§3.5).
|
||||
Third, to avoid interference running decode requests, we propose using a smart two-level scheduling algorithm augmented with predicted resource usage to avoid scheduling hotspots (§3.4). TetriInfer incorporates an LLM-based length prediction model to speculate the number of generated tokens of decode requests, and then schedule them accordingly.
|
||||
|
||||
We implement TetriInfer’s disaggregated prefill and decode instances based on vLLM [21]. Most of our modules are implemented in Python, except for the network stack module, which utilizes C++ to interface with low-level APIs for KV cache transfer. The fine-tuning part uses Trainer APIs offered by HuggingFace Transformer [16]. Since we cannot access high-end hardware, we implement a mock mechanism to emulate varying network bandwidth connecting prefill and decode instances, as illustrated in Figure 9.
|
||||
|
||||
We compare TetriInfer with vanilla vLLM using public dataset [35] in terms of time-to-first-token (TTFT), job completion time (JCT), and efficiency as in performance per dollar (perf/$).
|
||||
We run them atop a real testbed with emulated network bandwidth ranging from 200Gbps to 300GBps.
|
||||
For light prefill and heavy decode workload, TetriInfer improves perf/$ by 2.4x (Figure 16). For common mixed workload, TetriInfer improves average TTFT and average JCT by 85% and 50%, respectively (Figure 16).
|
||||
Nevertheless, we also find that TetriInfer’s design is not ideal for heavy prefill and heavy decode workloads since the room for improvement is marginal, and the overhead we introduce cannot be offset (Figure 16).
|
||||
Overall, our ideas mentioned above are effective.
|
||||
TetriInfer achieves effective LLM inference serving, outperforming vLLM by a large margin in TTFT, JCT, and perf/$ running most common workloads (§5.1).
|
||||
|
||||
|
||||
|
||||
Figure 1: Length Distribution. Prompt Tokens for Prefill and Generated Tokens during Decode. Data sources: conversation [35], summarization [17], writing [18].
|
||||
|
||||
## 2 Background and Motivation
|
||||
|
||||
We present a brief primer on LLM inference and study interferences while running various LLM inference requests to motivate our work. For model and testbed details, see §5.
|
||||
|
||||
### 2.1 Generative LLM Inference
|
||||
|
||||
|
||||
|
||||
Figure 2: Prefill and Decode’s Characteristics. Decode’s GPU utilization fluctuates because the task is faster than our monitoring granularity.
|
||||
|
||||
LLM inference is a process that involves generating a sequence of output tokens in response to an input prompt. This process consists of two phases: prefill and decode.
|
||||
The prefill phase outputs the first token and generates the key and value cache (KV cache) for future decoding [21]. The decode phase uses the previous KV cache to generate new tokens step-by-step in an auto-regressive manner.
|
||||
Generally, the prefill phase is computation-bound, and the decode phase is memory-bound [33].
|
||||
We report this in Figure 2.
|
||||
Results indicate that the prefill phase’s throughput stays flat once the accelerator is saturated at a certain number of tokens (which we name the accelerator-saturate threshold).
|
||||
The decode phase’s throughput continues increasing with a larger batch size but plateaus once the memory bandwidth is saturated.
|
||||
|
||||
### 2.2 Motivation: Interference Study
|
||||
|
||||
This section studies the impact of running different inference requests concurrently.
|
||||
Inspired by Figure 1,
|
||||
we classify inference requests across two dimensions (prefill and decode length) and one property (light or heavy), resulting in four distinct request types:
|
||||
heavy prefill,
|
||||
light prefill,
|
||||
heavy decode, and
|
||||
light decode.
|
||||
Here, heavy refers to a long token length, while light refers to a short token length.
|
||||
Below, we study mixing prefill
|
||||
|
||||
ong decoding tasks across different on-demand decode instances. Each timeline comprises four rounds (R1 to R4), with the length of prefill and decode boxes representing their sequence length and the width of the decode box indicating its resource usage. A wider decode box indicates the presence of lengthy generated tokens, resulting in larger resource usage and decoding latency.
|
||||
(b) shows TetriInfer’s architecture with four core modules highlighted.
|
||||
|
||||
## 3 设计（Design）
|
||||
|
||||
### 3.1 Overview
|
||||
|
||||
We realize the above insights in TetriInfer, an LLM inference serving system designed to battle interferences.
|
||||
First, we run prefill in a fixed-size computation unit by partition and pad input prompts into fixed-size chunks such that the accelerator always runs close to its computation-saturated limit (§3.3).
|
||||
Second, we design instances dedicated to running the prefill or decode phases. We schedule prefill requests to prefill instances only, and the same goes for decode requests. Prefill instances will transfer prefilled KV cache to decode instances.
|
||||
Our prefill and decode instances are virtual concepts in that each can scale independently and flip roles if load changes (§3.5).
|
||||
Finally, we design a two-level scheduling algorithm for both prefill and decode request scheduling. We incorporate a length-prediction model to speculate decode requests’ resource usage and then schedule them accordingly (§3.4).
|
||||
|
||||
We show TetriInfer’s architecture in Figure 6 (b) with four modules highlighted: centralized control plane, prefill instance, decode instance, and length prediction model.
|
||||
|
||||
Centralized control plane.
|
||||
It consists of a global scheduler and a cluster monitor.
|
||||
The global scheduler sends requests to prefill instances based on load and receives streaming outputs from decode instances.
|
||||
The cluster monitor collects statistics from prefill and decode instances and regularly broadcasts load information to prefill instances. It adds, removes, and flips prefill or decodes instances.
|
||||
|
||||
Prefill Instances.
|
||||
They only run the prefill phase of an LLM inference request.
|
||||
Each prefill instance has a local scheduler, a length predictor, the main LLM engine, and a dispatcher.
|
||||
All requests undergo four steps.
|
||||
First, the local prefill scheduler sorts requests based on pre-defined policies.
|
||||
Second, the length predictor runs a prediction model to speculate the requests’ decode lengths, which are then used to estimate resource usage during the decoding phase.
|
||||
Third, the main LLM engine partitions all requests into fixed chunks.
|
||||
Finally, for each request, the dispatcher runs an inter-decode load-balancing algorithm to select a decode instance and then forwards the generated KV cache to it.
|
||||
|
||||
Decode instances.
|
||||
They are virtually disaggregated from prefill instances and only run the decode phase of an LLM inference request.
|
||||
Each decode instance can receive requests from any prefill instance.
|
||||
It runs a local scheduler with three pre-defined policies for selecting decode requests to run in the main LLM engine.
|
||||
|
||||
Length Prediction Model.
|
||||
The prediction model is a small LLM model fine-tuned offline for predicting the generation length of LLM inference requests. TetriInfer’s prefill dispatcher and decode instance’s local scheduler utilize the speculated information to schedule decode instances and avoid hotspots measured in §2.2.3. The prediction model is small and deployed at all prefill instances.
|
||||
|
||||
### 3.2 Control Plane
|
||||
|
||||
TetriInfer has a centralized control plane to
|
||||
manage inference clusters at the cloud scale.
|
||||
It consists of a cluster monitor that manages the lifecycle of prefill and decode instances and a global scheduler that managesthe lifecycle of inference requests.
|
||||
The centralized control plane is a distributed system without a single point of failure or processing bottlenecks.
|
||||
|
||||
The cluster monitor is responsible for collecting and broadcasting statistics and scaling instances. Both prefill and decode instances regularly send their load information to the cluster monitor (e.g., every 100 ms). Since we run decentralized decode request scheduling at prefill instances, the cluster monitor will aggregate decode instances’ load information and broadcast it to all prefill instances.
|
||||
|
||||
The global scheduler is responsible for forwarding inference requests from external services to prefill instances and sending inference outputs from decode instances back to external services in a streaming fashion.
|
||||
The global scheduler maintains a request status table, which stores requests’ arrival time, current phase (e.g., prefill or decode), SLA requirement, etc.
|
||||
When a request arrives, the global scheduler will choose a prefill instance with the least load and then insert the request into the table.
|
||||
Following our insight to disaggregate prefill and decode instances, the global scheduler only decides which prefill instance will handle the request. It is up to the prefill instance’s dispatcher to decide which decode instances to use with a speculated resource usage.
|
||||
|
||||
### 3.3 Prefill Instance
|
||||
|
||||
The prefill instance runs the prefill phase of an inference request.
|
||||
To avoid interference among prefill requests, we use a prefill scheduler and chunked prefill to sort and partition all prompts into fixed-size chunks.
|
||||
To help avoid interference during the decode phase, we run a length predictor and a decentralized dispatcher to choose decode instances based on speculated resource usage.
|
||||
|
||||
#### 3.3.1 Prefill Scheduler
|
||||
|
||||
The prefill instance’s scheduler is crucial for improving the prefill phase’s latency and throughput.
|
||||
The scheduler maintains a raw request queue that stores requests from the global scheduler and a scheduled queue that stores sorted requests.
|
||||
In this work, we have designed and implemented three scheduler policies: first-come-first-serve (FCFS), shortest-job-first (SJF), and longest-job-first (LJF).
|
||||
We can use the latter two policies because we can accurately estimate a request’s prefill time based on the number of tokens in its prompt.
|
||||
We only explore non-preemptive policies, though chunked prefill (described soon) has opened the door to preemptive and out-of-order prefill scheduling, such as shortest-remaining-time-first, which we leave for future work.
|
||||
|
||||
The scheduled requests are sent to the length predictor which executes scheduled requests as-is using fixed-size batch (§3.3.2), and the main LLM which uses chunked prefill (§3.3.3).
|
||||
In Figure 7, we illustrate the above three scheduler policies and how scheduled requests are partitioned and merged into fixed-size chunks.
|
||||
Specifically, FCFS keeps the original request arrival order.
|
||||
Prompt tokens are partitioned and merged into chunks sequentially.
|
||||
This policy is the easiest to implement and works best for inference requests with similar prompt lengths.
|
||||
However, FCFS can lead to head-of-line blocking and high average job completion time (JCT) when requests have long prompts. This is problematic since the length differences among LLM inference requests are more than three orders of magnitude (see Figure 1).
|
||||
|
||||
In response, we add the shortest-job-first
|
||||
(SJF), and longest-job-first (LJF) to overcome these issues.
|
||||
These two policies schedule prefill requests based on prompt token lengths in ascending or descending order. By design, they can achieve lower JCT compared to FCFS. Nevertheless, they are no panacea. They introduce starvation for either long or short requests. To avoid starvation, we propose using a prefill scheduling batch (i.e., PrefillSchedBatch) variable to control how many inference requests can be scheduled at a time. For example, assume the raw request queue has twenty requests awaiting scheduling. If we set the batch size to ten, we will schedule twice, each with ten requests sorted and put into the scheduled queue. This simple mechanism prevents starvation during the prefill phase.
|
||||
|
||||
Our scheduler is effective. Results in Figure 16 show that SJF lowers average prefill waiting time by 7.8% compared to FCFS when the batch size is set to 16. Additionaly, the improvement is even more pronounced with larger batch sizes.
|
||||
|
||||
|
||||
|
||||
Figure 7: Prefill Scheduler Policies. The left shows four raw inference requests (R1 to R4). The right shows scheduled requests using FCFS, SJF, and LJF. We show the chunked version to illustrate slicing and merging (C1 to C4).
|
||||
|
||||
#### 3.3.2 Length Predictor
|
||||
|
||||
To address the interference cases measured in §2.2.3, it is essential to determine the number of tokens that a decode request is likely to generate. This information will enable us to schedule decode requests in a length-aware manner.
|
||||
As such, the prefill instance runs a length predictor to predict the length range of an inference request’s generated tokens.
|
||||
The prefill instance’s dispatcher utilizes this information for inter-decode instance scheduling (§3.3.4), while the decoding instance’s local scheduler employs this information for intra-decode instance scheduling (§3.4).
|
||||
|
||||
Our length predictor uses a small LLM-based classification model called a "predict model" to classify the length of generated tokens into fixed-size buckets if the request were executed by a specific target LLM model.
|
||||
The predict model is intentionally small, containing millions of parameters while the target model is much larger, with billions of parameters. As we run the length predictor at the prefill instance, we aim to minimize its cost and avoid impacting the main LLM model. Therefore, approaches like using a giant LLM to predict length are not feasible for us [48].
|
||||
Fortunately, a small LLM model is much faster than a giant LLM and uses much less resources.
|
||||
For example, we use OPT-125M as the predict model and OPT-13B as the target model, the small one is roughly ten times faster than the larger one.
|
||||
|
||||
We opt to predict the length range instead of an exact number of tokens because the latter is extremely difficult to predict.
|
||||
Various inference parameters, such as temperature and top-p [3], result in significant response variations from the same LLM model to the same question in practice. Since our primary goal is to use the estimated length to guide our request scheduling decisions, an exact length estimation is unnecessary; a length range suffices.
|
||||
For instance, if we estimate the length to be between ten to twenty tokens, we can deduce its resource usage’s lower and upper bounds.
|
||||
|
||||
In this work, we have tested two execution modes: a sequential mode, where we first execute the predict model followed by the target model, and a parallel mode, where both models are run simultaneously.
|
||||
The sequential mode adds extra latency for the target LLM model, while the parallel mode may reduce the target LLM model’s throughput.
|
||||
Based on our findings in Figure 17, we opted to use the parallel mode because the main LLM is not affected for most requests (more than 80%), though throughput take a 10% hit under extreme stress test.
|
||||
|
||||
Figure 8 outlines the offline fine-tuning and online prediction workflow. In this process, the predict model (depicted in red) is trained to speculate the decoding behavior of a specific target model (depicted in blue).
|
||||
The fine-tuning of the predict model involves three key steps.
|
||||
Firstly, we assemble a prompt-only training dataset inherited from public datasets, a large target LLM model (e.g., OPT-13B), and a classification model for our predict model (e.g., 125M OPTForSequenceClassification [16]).
|
||||
Secondly, we send training prompts to the target LLM model, which generates responses.
|
||||
Subsequently, we categorize the generated responses into fixed-size buckets with a chosen granularity.
|
||||
For instance, using a granularity of 100, responses with token lengths between 0 to 200 are labeled with 0, 200-400 are labeled with 1, and so on. These labels are paired with the training prompts to create a new dataset. Lastly, we partition the new dataset into a training section and an evaluation section and then proceed to train and evaluate the predict model using this dataset.
|
||||
|
||||
The length range granularity plays a crucial role. If set to one, we fall back to predicting an exact number of tokens, which is not practical. If set to target model’s context window size (e.g., 2K), we fall back to no prediction at all and could run into interferences reported in §2.2.1. Intuitively, a smaller granularity means more accurate resource and performance estimation but lower accuracy in practice. A larger granularity means higher accuracy but essentially makes scheduling harder. Regardless of granularity, it’s easy to calculate resource usage’s upper and lower bound but not performance.
|
||||
In this work, we can predict a granularity of 200 tokens with 74.9% accuracy.
|
||||
Since improving prediction accuracy is not the focus of this work, we leave it for future work.
|
||||
|
||||
|
||||
|
||||
Figure 8: Predict Model’s Fine-tuning and Prediction Flow. The target model is the one that we want to predict its decoding behavior. The predict model is the one we train. This work does not explore online fine-tuning.
|
||||
|
||||
Discussions.
|
||||
We run the length predictor at each prefill instance, hence prefill instances can make well-informed decisions on which decode instances should have enough resources to run certain decoding requests.
|
||||
Nevertheless, we identify two alternative designs. The first design is to run the length predictor at each decode instance. As a result, the prefill instance can only schedule requests based on the load of decoding instances. However, this design cannot avoid interference cases we measured in §2.2.3. Indeed, one could migrate interference requests among decoding instances at runtime based on predicted length. This would be an overly complex solution. The second design is to run the length predictor at the global scheduler before dispatching requests to refill instances. This design could make the global scheduler a bottleneck. We believe our current design is easier and simpler to reason about and deploy compared to alternatives.
|
||||
|
||||
#### 3.3.3 Chunked Prefill
|
||||
|
||||
After the prefill scheduler, we concurrently execute the prefill phase of the main LLM alongside the length predictor.
|
||||
We employ fixed-size chunks for the LLM prefill rather than using fixed batch sizes [21].
|
||||
|
||||
As demonstrated in §2.2.1, we observe that as the number of tokens in a prefill iteration increases, the accelerator’s throughput remains constant, while the latency continues to rise after reaching a certain threshold. We refer to this threshold as ChunkSize. Compared to the traditional fixed batch size approach, running prefill in ChunkSize allows for the optimal utilization of accelerators without incurring additional latency penalties. The accelerator and the LLM model architecture determine the ChunkSize. Models with larger hidden dimensions and accelerators with lower capabilities typically result in a smaller ChunkSize. For example, in our test environment, the value is 512 tokens for OPT 13B.
|
||||
|
||||
Figure 7 illustrates how chunked prefill wor
|
||||
|
||||
ded and two-sided, similar to RDMA’s classification.
|
||||
Accelerators like GPU or NPU can do one-sided memory access as they have low-level primitives such as direct memory copies between devices [26, 14].
|
||||
|
||||
To navigate the complicated physical data links and ensure that TetriInfer can always use the most performant link once deployed, we design a unified network transfer abstraction to utilize the different network stack options listed in Figure 9. The stack exposes APIs such as send, receive, read, write, etc. Our dispatcher calls these APIs to transmit the KV cache to remote decode instances.
|
||||
|
||||
Discussion.
|
||||
We identify two unexplored research questions.
|
||||
The first question pertains to whether it is beneficial to simultaneously utilize multiple data links for transmitting the KV cache. While this approach could enhance performance, it may also introduce complex control logic.
|
||||
The second question involves the sender accelerator accessing the memory of the receiver accelerator without involving the receiver’s CPU. This scenario raises typical challenges associated with building large-scale RDMA-based memory systems [10, 12].
|
||||
Unfortunately, we cannot explore either of these ideas in this wo
|
||||
@@ -0,0 +1,93 @@
|
||||
# 📊 文章摘要：TetriInfer: Inference without Interference - Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
|
||||
> **原文**：[2024-01-20_TetriInfer.md](./2024-01-20_TetriInfer.md)
|
||||
> **原文链接**：https://arxiv.org/abs/2401.11181
|
||||
> **来源**：arXiv
|
||||
> **作者**：Cunchen Hu, Heyang Huang, Liangliang Xu, Xusheng Chen, Jiang Xu, Shuang Chen, Hao Feng, Chenxi Wang, Sa Wang, Yungang Bao, Ninghui Sun, Yizhou Shan 等 12 位（中国科学院大学、中科院计算所、华为云）
|
||||
> **发布日期**：2024-01-20
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **消除干扰** — 混合下游任务请求的 prefill/decode 长度差异可达两个数量级，共跑必然相互干扰；按请求特征调度分组（定长 chunk 的 prefill + 阶段解耦 + 长度预测调度）是消除干扰、提升性能/美元比的系统化方案。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
TetriInfer 研究"不同下游任务（摘要、创作、对话等）的请求混跑"时的干扰问题：请求的输入 prompt 长度与生成 token 长度差异超两个数量级，混跑会引发严重性能恶化（实测：混跑 prefill 请求 10× 减速、prefill 与 decode 混跑 5× 减速、不同长度 decode 混跑吞吐损失 16%）。作者把干扰根源归结为现有部署忽略了两阶段的本质差异（prefill 是计算密集的批作业，decode 是内存密集的延迟敏感任务），提出三支柱设计：将 prompt 切分为固定大小 chunk 使加速器始终贴近计算饱和点运行；prefill/decode 实例解耦（虚拟实例，可独立扩缩容与角色翻转）；两级调度配合小 LLM 长度预测模型（200 token 粒度预测准确率 74.9%）避免 decode 调度热点。相比 vanilla vLLM：资源使用减少 38%，平均 TTFT 与 JCT 分别降低 97% 与 47%；轻 prefill 重 decode 负载下性能/美元比提升 2.4×。局限：重 prefill + 重 decode 负载下收益边际化且开销无法抵消，且评估受限于模拟网络带宽与 OPT-13B 等旧模型。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **混合负载干扰是真实且严重的问题** — 实测数据：混跑 prefill 请求 10× 减速（向已饱和硬件持续添加计算密集作业）、prefill+decode 混跑 5× 减速（批作业与延迟敏感任务共跑）、不同长度 decode 混跑 16% 吞吐损失（内存带宽/容量竞争与队头阻塞）。`[分类: 范式突破]`
|
||||
2. **按特征分组而非统一处理** — 核心洞见：不应把所有请求当同类处理，而应按 prefill/decode 长度（重/轻两维）分类调度；系统名 TetriInfer 即喻意像俄罗斯方块一样组织请求。`[分类: 范式突破]`
|
||||
3. **定长 chunk 的 prefill** — 加速器在 token 数达到饱和阈值后吞吐不再增长、延迟却继续上升；把 prompt 切成固定大小 chunk（OPT-13B 上为 512 token）使硬件始终贴近计算饱和点，避免额外延迟惩罚。`[分类: 范式突破]`
|
||||
4. **虚拟解耦实例** — prefill/decode 实例是"虚拟概念"：各自独立扩缩容、负载变化时可角色翻转，兼顾解耦隔离与资源弹性。`[分类: 共识]`
|
||||
5. **小 LLM 预测生成长度** — 用百万参数级的预测模型（OPT-125M）对十亿级目标模型（OPT-13B）的生成长度做分桶分类预测（而非精确预测），200 token 粒度准确率 74.9%；并行执行模式下 80% 以上的请求主模型不受影响，极端压测下吞吐损失 10%。`[分类: 未探索]`
|
||||
6. **两级调度避免热点** — prefill 实例的调度器选择 decode 实例时用预测资源占用做负载均衡，decode 实例内部再用长度感知策略调度，避免 §2.2.3 测得的 decode 热点问题。`[分类: 未探索]`
|
||||
7. **量化收益** — 相比 vLLM：资源减少 38%、平均 TTFT 降低 97%、平均 JCT 降低 47%；轻 prefill 重 decode 负载 perf/$ 提升 2.4×，常见混合负载 TTFT/JCT 改善 85%/50%。`[分类: 共识]`
|
||||
8. **诚实标注不适场景** — 重 prefill + 重 decode 负载下设计不理想：改进空间边际化、引入的开销无法抵消——这是少见的对自身方案适用边界的明确声明。`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 下游任务请求的输入/输出长度分布差异显著且可测量、可分类（重/轻两维），且这种分类足以指导调度。
|
||||
- 用一个小模型（百万参数）预测大模型（十亿参数）的生成长度范围是可行的（以固定粒度分桶），且并行运行小模型不显著影响主模型吞吐。
|
||||
- 干扰现象（10×/5×/16%）在目标生产环境复现，且模拟网络带宽（200Gbps-300GBps）能代表真实数据中心网络。
|
||||
- 集中式控制面（全局调度器 + 集群监控器）不会成为云规模瓶颈（论文称其为无单点的分布式系统）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 干扰测量的数据（10×/5×/16%）是本文论据的地基，直接驱动设计决策，链条清晰；三支柱设计各自针对一种干扰类型，映射关系明确。
|
||||
- 端到端收益（38% 资源、97% TTFT、47% JCT）与摘要结论一致，且明确区分了"轻 prefill 重 decode"（2.4× perf/$）与"常见混合负载"（85%/50%）等不同语境。
|
||||
- 弱点：论文基于 OPT-13B/OPT-125M 等较旧模型，未在 GPT-4 级别或 MoE 模型上验证；评估在模拟带宽与模拟环境下进行（作者明示无法访问高端硬件）；所下载原文缺失完整实验章节，部分收益数字无法在原文内交叉核对（以摘要与引言为准）。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 明确不适用场景：重 prefill + 重 decode 负载（收益无法抵消开销）。
|
||||
- 长度预测粒度（200 token、74.9% 准确率）意味着对长度分布接近粒度边界的请求，调度决策可能偏差。
|
||||
- 依赖小模型与目标模型行为的一致性；换目标模型需重新微调预测模型。
|
||||
- 未探索在线微调预测模型、可抢占/乱序 prefill 调度（chunked prefill 已打开该可能，留作未来工作）。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "We find the fundamental issue lies in the fact that current LLM deployment practices do not account for the distinct characteristics exhibited by LLM prefill and decode phases."
|
||||
> （我们发现根本问题在于：当前的 LLM 部署实践没有考虑 prefill 与 decode 阶段各自迥异的特性。）
|
||||
|
||||
> "We take a step back to examine why interference exists. We find the fundamental issue lies in the fact that current LLM deployment practices do not account for the distinct characteristics exhibited by LLM prefill and decode phases."
|
||||
> （我们退一步审视干扰为何存在，发现根本问题在于现有部署实践忽视了 prefill 与 decode 阶段的本质差异——prefill 像计算密集的批作业，decode 像内存密集的延迟敏感任务。）
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 首个系统量化"混合下游任务干扰"的工作，10×/5×/16% 的干扰数据直观有力
|
||||
- 长度预测驱动的调度是独特贡献，用分桶分类规避了精确预测的不可能，工程务实
|
||||
- 定长 chunk prefill 与虚拟解耦实例的设计简洁可落地，且明确声明适用边界（重+重负载不适用），学术诚实度高
|
||||
- 与 DistServe、Splitwise 同期（2023.11-2024.1）独立验证了解耦思路，并补充了干扰测量与预测调度两个新维度
|
||||
|
||||
**不足**：
|
||||
- 评估环境受限（模拟带宽、旧模型 OPT-13B），无真实生产部署验证
|
||||
- 预测模型需要随目标模型重新微调，落地成本未量化
|
||||
- 下载版原文缺失实验与结论章节，部分细节只能依赖摘要与引言
|
||||
|
||||
**适用场景**：多任务混合流量（对话 + 摘要 + 创作等）的 serving 系统设计者；研究 LLM serving 干扰表征、长度预测调度的研究人员；云厂商推理平台团队。
|
||||
|
||||
**关联建议**：与 DistServe（阶段解耦的 goodput 理论）、Splitwise（异构硬件）、Mooncake（生产系统 KVCache 中心化）构成解耦 serving 四篇同期代表作，可联合精读；"输出长度预测"方向后续可关注 speculative decoding、MoE 路由预测等相关工作。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,219 @@
|
||||
# How Far Can Disaggregation Go? A Design-Space Exploration of Attention-FFN Disaggregation for Efficient MoE LLM Serving
|
||||
|
||||
> **来源**：arXiv
|
||||
> **作者**：Hanjiang Wu, Abhimanyu Rajeshkumar Bambhaniya, Sarbartha Banerjee, Tuhin Khare, Sudarshan Srinivasan, Suvinay Subramanian（等，共 12 位）
|
||||
> **发布日期**：2026-05-27
|
||||
> **原文链接**：https://arxiv.org/abs/2605.28302
|
||||
|
||||
---
|
||||
|
||||
## 论文元数据
|
||||
|
||||
- **arXiv ID**：2605.28302
|
||||
- **学科分类**：Distributed, Parallel, and Cluster Computing (cs.DC)
|
||||
- **作者机构**：佐治亚理工学院（Georgia Institute of Technology）、Intel、Google、Google DeepMind、Infravana
|
||||
- **提交历史**：v1: 2026-05-27
|
||||
- **DOI**：https://doi.org/10.48550/arXiv.2605.28302
|
||||
|
||||
---
|
||||
|
||||
Hanjiang Wu1 Abhimanyu Rajeshkumar Bambhaniya1,5 Sarbartha Banerjee1
|
||||
|
||||
Tuhin Khare1 Sudarshan Srinivasan2 Suvinay Subramanian3
|
||||
|
||||
Souvik Kundu2 Madhu Kumar2 Midhilesh Elavazhagan2
|
||||
|
||||
William Won1 Amir Yazdanbakhsh4 Tushar Krishna1,5
|
||||
|
||||
1Georgia Institute of Technology 2Intel 3Google 4Google DeepMind 5Infravana
|
||||
|
||||
## 摘要（Abstract）
|
||||
|
||||
Modern large language model (LLM) inference has progressively disaggregated to keep pace with growing model sizes and tight TTFT and TPOT service-level objectives: from chunked-prefill aggregation, to prefill–decode (P/D) disaggregation, and most recently to operator-level Attention–FFN Disaggregation (AFD). This trend is especially important for mixture-of-experts (MoE) models, where memory-bound attention, compute-intensive expert FFNs, and MoE dispatch/combine communication create distinct resource demands across the serving pipeline. AFD further exposes this heterogeneity by placing attention and MoE-FFN execution on separate GPU groups. Each level of disaggregation deepens the scheduling design space across workload characteristics, resource allocation, and interconnect topology, leaving open the central question: When does each level of disaggregation actually pay off? We systematically characterize this trade-off for MoE inference across realistic workload use cases defined by input/output sequence lengths, prefix-KV reuse, and per-user latency constraints. Using chunked-prefill and P/D disaggregation as strong baselines, we study the benefits and limits of AFD at scale through a framework that fuses rich on-device kernel measurements with high-fidelity network simulation. Our findings deliver a practical map of when and where deeper disaggregation pays off for MoE serving at scale. Under strict TTFT/TPOT SLOs, AFD sustains around 4k tokens/s of system throughput on DeepSeek-V3.2 across chat, coding, and agentic-coding workloads, regimes in which non-AFD deployments are infeasible. Our design and analysis further distill concrete takeaways for jointly optimizing system throughput and user interactivity, including how to partition attention and FFN across GPUs as a function of workload and model architecture, providing design principles for current rack- and cluster-scale deployments as well as future disaggregated AI infrastructure.
|
||||
|
||||
## 1 引言（Introduction）
|
||||
|
||||
The rapid scaling of agentic large language models (LLMs) has enabled AI systems to perform increasingly complex tasks, including multi‑turn reasoning, code generation, and autonomous decision‑making. As these models grow to hundreds of billions of parameters and operate on long input contexts, their deployment places unprecedented pressure on inference infrastructure, particularly due to the expanding KV‑cache footprint and the need to scale across multiple compute nodes. At the same time, emerging agentic workloads and model architectures exhibit increasing compute characteristic heterogeneity, exposing limitations in existing LLM serving paradigms that struggle to simultaneously achieve high performance, efficiency, and scalability.
|
||||
|
||||
A central challenge stems from the heterogeneous execution characteristics of different components within modern LLM architectures, which impose conflicting demands on compute, memory bandwidth, and communication resources. Prior systems mitigate these effects through batching and scheduling techniques such as chunked prefill Agrawal et al. (2023) and continuous batching Yu et al. (2022), pipelining, or coarse‑grained prefill–decode (P/D) disaggregation Zhong et al. (2024); Patel et al. (2023). While effective at reducing phase‑level interference, these approaches implicitly treat the model as a monolithic execution unit, obscuring fine‑grained trade‑offs that become dominant at scale.
|
||||
|
||||
|
||||
|
||||
Figure 1: AIC++ Framework Overview. AIC++ takes model architecture, hardware configuration, and workload constraints as inputs and performs design-space exploration to identify optimal scheduling across token-level parallelism—data (DP), sequence (SP), tensor (TP), pipeline (PP), and expert parallelism (EP)—as well as phase-level prefill/decode (P/D) and operator-level attention–FFN disaggregation (AFD) [C1]. The framework leverages AIConfigurator to model heterogeneous GPU clusters (GPUA,GPUBGPU_{A},GPU_{B}) interconnected via scale-up (NVLink) and scale-out (InfiniBand) fabrics simulated with AstraSim [C2]. Based on this analysis, attention (PA,DA1,DA2P_{A},D_{A,D_{A) and FFN (PF,DF1,DF2P_{F},D_{F,D_{F) operators are placed on specific GPUs to maximize overall system throughput [C3].
|
||||
|
||||
Recent studies such as MegaScale-Infer Zhu et al. (2025) show that coarse-grained inference abstractions break down for large heterogeneous models, especially MoE architectures, where substantial compute heterogeneity exists within each Transformer block. Attention variants such as MHA Ashish (2017), GQA Hudson and Manning (2019), and MLA DeepSeek-AI et al. (2024) are largely memory-bound due to KV-cache access and data movement, whereas FFNs are compute-bound and dominated by dense GEMMs. Although MegaScale-Infer highlights inefficiencies from attention–FFN heterogeneity, it remains unclear how Attention–FFN Disaggregation (AFD) composes with existing parallelism strategies, prefill–decode (P/D) disaggregation, and different attention architectures.
|
||||
|
||||
Beyond architectural heterogeneity, AFD effectiveness also depends on workload characteristics such as input/output sequence length (ISL/OSL), prefix length, and system load (tokens/s/user). These factors directly affect scheduling decisions and determine when disaggregation is beneficial. Understanding these trade-offs is critical for current cluster-scale LLM serving and for future disaggregated inference platforms, including NVIDIA Groq 3 LPX NVIDIA (2026a) and Intel/SambaNova-style systems Intel (2026).
|
||||
|
||||
In this paper, we present a systematic study of AFD for LLM inference across diverse application domains. We analyze efficient deployment across three dimensions: distributed parallelism, including tensor, data, pipeline, sequence, and expert parallelism; phase-level P/D disaggregation; and operator-level attention–FFN disaggregation, as shown in Figure˜1(C1). We formulate scheduling selection as a design-space exploration (DSE) problem that captures operator-level compute heterogeneity and inter-node communication costs.
|
||||
|
||||
To support this study, we develop AIConfigurator++ (AIC++), a co-design framework that combines operator-level compute modeling from NVIDIA AIConfigurator Xu et al. (2026) with distributed communication modeling using AstraSim Rashidi et al. (2020). Grounded in a customized vLLM-based AFD prototype Kwon et al. (2023), AIC++ integrates kernel measurements with system-level simulation to evaluate compute–communication trade-offs across scheduling strategies, as illustrated in Figure˜1(C2).
|
||||
|
||||
We evaluate chatbot, coding, and agentic workloads using DeepSeek-V3.2, GPT-OSS-120B, Nemotron3-120B, and Qwen3-235B, covering MLA, GQA, sparse attention, and Mamba-based architectures. By varying ISL, OSL, prefix length, and system load, our framework identifies when AFD is beneficial, how micro-batching and operator placement improve compute–communication overlap, and which scheduling strategy maximizes throughput and interactivity under SLO constraints. Importantly, our analysis translates workload and model characteristics into concrete attention-to-FFN GPU ratios, providing actionable guidance for cluster-scale deployment.
|
||||
|
||||
More broadly, our findings suggest that as LLM workloads become increasingly heterogeneous, system optimization must move beyond coarse-grained placement toward operator-level disaggregation. Modeling-driven frameworks such as AIC++ can guide the co-design of future heterogeneous inference platforms. From Figure˜2, we observe that under stringent SLOs for TTFT and TPOT on DeepSeek-V3.2, AFD is able to achieve 4k tokens/s system throughput while the non-AFD deployment is infeasible to run. Through exhaustive design-space exploration to analyze the best deployment strategy on a cluster of 128 B200 GPUs (Section˜4), we see that AFD is not the best option when system throughput is the main target compared to the pure P/D disaggregation and chunked prefill. But our analysis that dynamically searches the attention-to-FFN ratios finds that it will always achieve the best latency and user interactivity with the AFD-specific microbatch overlapping technique that best utilizes the compute and communication resources. Finally, we present a case study highlighting AFD’s memory-segmentation benefit: by placing most model weights on FFN GPUs, AFD leaves more memory on attention GPUs for KV cache, enabling higher throughput under the same memory constraint.
|
||||
|
||||
Our key contributions are:
|
||||
|
||||
- C1:
|
||||
|
||||
Multi-dimensional DSE: We jointly optimize LLM serving across token-level parallelism, P/D disaggregation, and AFD, and translate workload characteristics into concrete attention-to-FFN GPU ratios.
|
||||
- C2:
|
||||
|
||||
System modeling for disaggregated architectures: We build AIC++, which models compute and data-transfer costs for scaled-out disaggregated inference systems.
|
||||
- C3:
|
||||
|
||||
Optimal AFD operator placement: We demonstrate that careful placement of attention and FFN operators is critical for effective AFD deployment.
|
||||
|
||||
|
||||
|
||||
Figure 2: System throughput at the best feasible deployment on DeepSeek-V3.2 (128× B200 with trtllm backend) under strict SLOs (TTFT<50/100/150 ms for Chat/Coding/Agentic Coding; TPOT caps 15 ms). Red cross marks infeasibility — the auto-con
|
||||
|
||||
advisory chatbots - typically exhibit large context length and small ISLs.
|
||||
These workloads favor aggregated deployments, as frequent cross‑node data transfers in disaggregated systems incur high communication overheads.
|
||||
In contrast, workloads with long ISLs, common in code‑completion and code‑generation tasks, benefit more from asynchronous function decomposition (AFD), which introduces an additional dimension to the scheduling design space.
|
||||
In this work, we characterize different workloads with different ISL, OSL and context length to find the Pareto-optimal scheduling that balances system throughput and user interactivity under SLO constraints (detailed in section 4).
|
||||
|
||||
### 2.2 Finding the optimal scheduling with disaggregated architecture
|
||||
|
||||
The emergence of disaggregated architectures with heterogeneous compute units within a node—such as NVIDIA Groq‑3 LPX, Rubin CPX Nvidia (2024), and Intel SambaNova—has made fine‑grained AFD an effective scheduling strategy despite the increased communication volume. High‑bandwidth scale‑up interconnects in these heterogeneous clusters enable memory‑bound attention operators to execute on memory‑rich devices, while compute‑intensive FFN blocks benefit from accelerators optimized for high arithmetic throughput.
|
||||
|
||||
System modeling requirements of disaggregated architecture:
|
||||
Exploring a large design space by evaluating hundreds of candidate configurations is prohibitively expensive for large‑scale disaggregated systems as observed by Miao et al. (2022); Zheng et al. (2022).
|
||||
Hence, accurate system modeling of compute and communication infrastructure is necessary for evaluation.
|
||||
AIConfigurator Xu et al. (2026) provides a compute modeling framework to estimate the compute and memory bandwidth of a wide range of modern GPUs.
|
||||
However, we additionally need accurate estimation of the data-transfer cost for fine-grained operator-level AFD.
|
||||
To address this, we augment AIConfigurator with the AstraSim Rashidi et al. (2020) network simulator to build AIC++,
|
||||
a disaggregated modeling framework that captures the compute-communication effects, maximizing their overlap for fine-grained AFD.
|
||||
Moreover, we evaluate the impact of AFD in heterogeneous scale-up AIC++ deployments.
|
||||
|
||||
|
||||
|
||||
Figure 3: (a) Runtime breakdown and (b) memory component breakdown for different model architectures running prompts with different context lengths.
|
||||
|
||||
Precise placement of attention and FFN operators:
|
||||
Fine‑grained data transfers introduced by AFD can lead to significant interconnect congestion if attention and FFN operators are placed arbitrarily across a disaggregated infrastructure. Consequently, effective scheduling of fine‑grained operator disaggregation requires jointly reasoning about compute affinity and data‑movement costs—a challenge explicitly addressed in our work. In particular, optimal operator placement must account for compute–communication overlap by co‑locating operators with high data‑exchange intensity on nearby or tightly coupled compute nodes. Going beyond prior approaches that primarily model heterogeneous architectures, our work jointly optimizes operator placement by explicitly considering interconnect congestion, identifying optimal mappings of attention and FFN operators that maximize overall system efficiency.
|
||||
|
||||
## 3 AIC++ 框架总览
|
||||
|
||||
In this section, we present AIC++, a framework for exploring the design space of AFD‑enabled MoE serving at scale. AIC++ combines AIConfigurator Xu et al. (2026) for accelerator‑level performance modeling with ASTRA‑Sim Rashidi et al. (2020) for high‑fidelity network simulation, enabling evaluation across attention architectures and application domains. While AIConfigurator accurately models modern LLM kernels, it does not capture AFD‑specific communication paths; we extend it by partitioning execution into attention and MoE‑FFN phases and binding each phase to an independent GPU backend, faithfully modeling runtime and memory behavior on disaggregated devices.
|
||||
|
||||
### 3.1 AFD design for MoE architectures
|
||||
|
||||
As shown in Figure˜4, the transition between the Attention and MoE–FFN phases is mediated by the MoE-Dispatch and MoE-Combine communication operators. In non-AFD deployments, these operators involve matched source and destination counts, as communication is confined to GPU ranks participating in expert parallelism (EP). Under AFD, attention and MoE–FFN phases execute on physically disaggregated GPUs, resulting in asymmetric fan-out or fan-in communication patterns depending on the scheduling strategy. For example, while an MoE model deployed on 8 GPUs with EP=8 exchanges tokens among all 8 GPUs, an AFD configuration with 2 attention GPUs and 6 FFN GPUs induces a fan-out pattern, requiring tokens generated by the attention GPUs to be distributed to a larger set of FFN GPUs.
|
||||
|
||||
AIC++ models these interactions using AstraSim to simulate scale-up and
|
||||
scale-out communication at packet granularity. By coupling AstraSim with
|
||||
AIConfigurator, AIC++ enforces communication-dependent execution, capturing
|
||||
contention, GPU utilization, and data-transfer efficiency under dynamic workloads.
|
||||
|
||||
Concretely, each transformer layer incurs two cross-AFD transfers. In the all-pairs mode used for the main results, the AFD worker establishes pairwise communicators between every attention rank and every FFN rank, so tokens generated by a single attention rank may be routed to any FFN rank hosting the selected experts.
|
||||
A2F/A2E (MoE-Dispatch) transfers post-attention hidden states, token ids, and per-expert routing metadata from attention ranks
|
||||
to FFN ranks hosting the selected experts, where each FFN rank filters tokens according to its hosted experts. Due to the top-kk routing and token dispatch, A2F exhibits a fan-out, making FFN-side ingress congestion dominant. F2A/E2A (MoE-Combine) aggregates expert outputs and
|
||||
returns a single reduced hidden state per token to the originating attention rank,
|
||||
forming a fan-in transfer in which attention-side ingress becomes the bottleneck. AIC++ expands both transfers into a full bipartite
|
||||
traffic matrix and feeds them into AstraSim’s tiered, congestion-aware network model,
|
||||
capturing contention when A2F egress and F2A ingress overlap on full-duplex
|
||||
interconnects. This part of the implementation with its communication pattern is based on our prototype implementation (refer to subsection 6.1).
|
||||
|
||||
### 3.2 Batch Overlap (BO) in AFD
|
||||
|
||||
As shown in Figure˜4 (left), AFD decomposes execution into four stages mapped to separate compute or communication resources: attention computation on the attention GPUs, dispatch of post-attention hidden states, token ids, and per-expert routing metadata to experts, MoE-FFN computation on the FFN GPUs, and aggregation/transfer of expert outputs back to the attention side for the next layer.
|
||||
|
||||
The return communication may share the same channel on half-duplex links, or proceed concurrently over a dedicated channel on full-duplex networks, enabling the pipelined execution shown in Figure˜4(B). Since modern datacenter GPU deployments commonly provide full-duplex interconnects such as NVLink and InfiniBand, AFD can exploit compute-communication overlap across GPUs and the network fabric. Accordingly, in the following discussion, we assume an AFD implementation with four-stage micro-batch overlap enabled. In contrast, under aggregated execution, all devices jointly execute all stages as a single group, as shown in Figure˜4(A).
|
||||
|
||||
To model batch overlap behavior in AIC++, we partition the per-step token budget
|
||||
Tbudget=batch_size×ISLT_{{budget}}=it{batch\_size}it{ISL} into MM microbatches.
|
||||
The number of microbatches MM is chosen to match the effective pipeline depth—three
|
||||
for half-duplex links and four for full-duplex links. For each microbatch,
|
||||
AIC++ queries AIConfigurator’s empirically measured GPU-cluster cost database
|
||||
to obtain the attention and FFN execution costs for a microbatch size of
|
||||
Tbudget/MT_{{budget}}/M, thereby preserving the nonlinear scaling behavior of small
|
||||
GEMMs and collective operations.
|
||||
|
||||
Let sis_{i} denote the measured per-microbatch execution cost of pipeline stage ii,
|
||||
aggregated across all LL transformer layers, and let
|
||||
smax=maxisis_{}=_{i}s_{i} be the bottleneck stage. Under steady-state cross-layer
|
||||
pipelining, the bottleneck stage processes all MM microbatches back-to-back,
|
||||
whereas each non-bottleneck stage incurs only a one-time pipeline fill and drain
|
||||
overhead of si/Ls_{i}/L. This cost is amortized over the full execution rather than
|
||||
charged per layer, consistent with the cross-layer scheduling strategies used by
|
||||
MegaScale-Infer and Step-Fun. The resulting end-to-end pipelined latency is shown in Equation˜1.
|
||||
|
||||
| | | | |
|
||||
| --- | --- | --- | --- |
|
||||
| | tpipe=M⋅smax+∑i:si≠smaxsiL.t_{{pipe}}=M s_{}+_{i:s_{i} s_{}}{s_{i}}{L}. | | (1) |
|
||||
|
||||
The first term captures the steady-state throughput dictated by the bottleneck
|
||||
resource, while the second term accounts for pipeline fill and drain bubbles
|
||||
introduced by non-bottleneck stages. We apply this formulation to both prefill and
|
||||
decode phases, enabling AIC++ to accurately reason about computation and
|
||||
communication costs under batch-overlapped execution.
|
||||
|
||||
|
||||
|
||||
Figure 4: Mapping AFD to 4 different stages in the model execution
|
||||
|
||||
### 3.3 Location-aware GPU placement
|
||||
|
||||
Because AstraSim labels each GPU with its physical position—node, scale-up domain, and link tier—and resolves congestion at packet granularity, AIC++ additionally enables a study of optimal GPU placement under combined AFD and P/D disaggregation. The policy is frequency-driven: the most frequent intra-layer A2F/F2A traffic (𝒪(layer){O}({layer}) per request) is bound to the highest-bandwidth scale-up domain (intra-node NVLink), while the less frequent inter-node KV-cache transfer (𝒪(1){O}(1) per request) is deferred to the scale-out domain (InfiniBand). This grouping co-locates GPUs with high communication affinity onto faster interconnects, avoiding contention on slower links. The detailed placement study—including segregated vs. paired P/D layouts and the resulting KV-transfer speed-up—is given in Appendix 6.2.
|
||||
|
||||
We also consider asymmetric prefill and decode configurations reflecting their distinct compute characteristics. AIC++ enables such asymmetry through independent prefill/decode scheduling and asymmetric attention and FFN worker allocation, while the network simulator co‑locates operators to reduce interconnect congestion and improve efficiency.
|
||||
|
||||
## 4 Evaluation
|
||||
|
||||
### 4.1 Design-Space Exploration (DSE) of different serving strategies
|
||||
|
||||
#### 4.1.1 Input workloads
|
||||
|
||||
To demonstrate the applicability of AFD, we evaluate a diverse set of model architectures spanning multiple application domains, as summarized in Table˜1. Specifically, we consider recent production‑deployed models including Qwen3‑235B, commonly used for chatbot workloads; GPT‑OSS‑120B, targeting medium‑scale reasoning tasks; DeepSeek‑V3.2, designed for reasoning‑intensive and agentic coding workflows; and Nemotron3‑120B, optimized for large‑context applications such as RAG serving Nvidia (2026). The corresponding prefix sizes, ISL, OSL, and architectural characteristics for each workload are detailed in Table˜1.
|
||||
|
||||
Table 1: Representative application workloads and model architectures.
|
||||
|
||||
Application Workload
|
||||
|
||||
| | | | |
|
||||
| --- | --- | --- | --- |
|
||||
| Use Case | Prefix | ISL | OSL |
|
||||
| Chat | 4096 | 512 | 256 |
|
||||
| Coding | 2048 | 4096 | 1024 |
|
||||
| Agentic Coding | 524k 111Models listed in this table may not natively support a 524k context window. We use 524k to model long-context agentic workloads and quantify the system impact of large KV-cache residency. | 256 | 8192 |
|
||||
|
||||
Model Architecture
|
||||
|
||||
| | | | |
|
||||
| --- | --- | --- | --- |
|
||||
| Model | Attention | # Experts | Precision |
|
||||
| GPT-OSS-120B | Full GQA + Window GQA | 128 | FP8 |
|
||||
| Qwen3-235B | GQA | 128 | FP8 |
|
||||
| Nemotron3-120B | Mamba 2 + GQA | 512 | FP8 |
|
||||
| DeepSeek V3.2 | MLA + Sparse Attention | 256 | FP8 |
|
||||
|
||||
#### 4.1.2 Cluster-scale DSE analysis
|
||||
|
||||
Figure˜5 reports the Pareto curve (tokens/s/user vs system tokens/s) produced by AIC++ on a 128 B200SXM cluster with TensorRT-LLM NVIDIA (2026b) as the performance backend, with each panel constrained by the workload’s SLO from Table˜1. To exhaustively probe the throughput frontier, our replica search enumerates every replica size from 2 to 128 GPUs and dynamically composes the per-replica parallelism plan across TP, DP, EP, and (for AFD) attention/FFN GPU groups. This lets the optimizer surface asymmetric layouts that only become feasible when prefill and decode have very different compute and memory profiles, including off-grid replica sizes that pack a long-context KV cache more efficiently than the obvious power-of-two choices. The cluster-scale results in this section are model-based DSE estimates that combine backend cost measurements with AstraSim communication modeling. Appendix 6.1 describes our vLLM-based AFD prototype, which we use to verify functional correctness of the all-pairs attention–FFN execution path and to ground the communication pattern modeled by AIC++.
|
||||
|
||||
|
||||
|
||||
Figure 5: Evaluation of a Cluster with 128 B200 GPUs for the representative model architectures and application workloads shown in Table 1, Y-axis denotes the system throughput (total tokens/s), X-axis denotes the interactivity (tokens/s/user)
|
||||
|
||||
No single strategy dominates the throughput frontier. Aggregated serving with chunked prefill, deployed as 16 single-node 8-GPU replicas that hold the expert FFNs through Expert Parallelism, wins most panels by amortizing the chunked-prefill bubble across the replica fleet and ingesting many disjoint token batches in parallel. Disaggregation takes the rest, but only after the wider search exposes asymmetric replica shapes: a single off-grid replica with many small 2-GPU prefill workers feeding a few large 8-GPU decode workers (Qwen3-235B-A22B chat, DeepSeek-V3.2 coding), or many tiny xPyD shards under _disagg+AFD_ that double aggregated’s throughput on Nemotron-3-Super coding. AFD on its own wins the throughput frontier on a single panel, GPT-OSS-120B chat, where the cheap sliding-window GQA layers let four 32-GPU replicas with a near-symmetric 16A+16F split outpace 16-replica agg. The wider TP-16 enumeration also unlocks a feasible _disagg-standard_ layout for DeepSeek-V3.2 agentic coding, where a narrower TP,≤,8 search returned no SLO-feasible configuration for the 524k-prefix workload.
|
||||
|
||||
On the latency axis, AFD wins every panel, with the optimal attention/FFN split tracking each model’s intrinsic attention/mixer cost relative to its FFN cost. DeepSeek-V3.2, whose MLA combined with sparse (DSA) attention shrinks both per-token attention compute and the KV-cache footprint, collapses the attention shard to its minimum on long-context workloads, dedicating almost the entire cluster to FFN (2A+126F on agentic, 16A+112F on chat). The 2A+126F layout is initially counter-intuitive given the 524k-token KV demand, but consistent with rate-matching: MLA compresses the latent KV cache so aggressively that the entire prefix fits in two GPUs’ HBM, and DSA keeps per-token attention cheap enou
|
||||
|
||||
manov.
|
||||
Vidur: A large-scale simulation framework for llm inference, 2024.
|
||||
URL https://arxiv.org/abs/2405.05465.
|
||||
- Ashish [2017]
|
||||
|
||||
Vaswani Ashish.
|
||||
Attention is all you need.
|
||||
_Advances in neural information processing systems_, 30:I, 2017.
|
||||
- Bambhaniya et al. [2026]
|
||||
|
||||
Abhimanyu Rajeshkumar Bambhaniya, Hanjiang Wu, Suvinay Subramanian, Sudarshan Srinivasan, Souvik Kundu, Amir Yazdanbakhsh, Midhilesh Elavazhagan, Madhu Kumar, Minlan Yu, Arijit Raychowdhury, and Tushar Krishna.
|
||||
Mist: A co-design framework for heterogeneous, multi-stage llm inference, 2026.
|
||||
URL https://arxiv.org/abs/2504.09775.
|
||||
- DeepSeek-AI et al. [2024]
|
||||
|
||||
DeepSeek-AI, Aixin Liu, Bei Feng, Bin Wang, Bingxuan Wang, Bo Liu, Chenggang Zhao, Chengqi Dengr, Chong Ruan, Damai Dai, Daya Guo, Dejian Yang, Deli Chen, Dongjie Ji, Erhang Li, Fangyun Lin, Fuli Luo, Guangbo Hao, Guanting Chen, Guowei Li, H. Zhang, Hanwei Xu, Hao Yang, Haowei Zhang, Honghui Ding, Huajian Xin, Huazuo Gao, Hui Li, Hui Qu, J. L. Cai, Jian Liang, Jianzhong Guo, Jiaqi Ni, Jiashi Li, Jin Chen, Jingyang Yuan, Junjie Qiu, Junxiao Song, Kai Dong, Kaige Gao, Kang Guan, Lean Wang, Lecong Zhang, Lei Xu, Leyi Xia, Liang Zhao, Liyue Zhang, Meng Li, Miaojun Wang, Mingchuan Zhang, Minghua Zhang, Minghui Tang, Mingming Li, Ning Tian, Panpan Huang, Peiyi Wang, Peng Zhang, Qihao Zhu, Qinyu Chen, Qiushi Du, R. J. Chen, R. L. Jin, Ruiqi Ge, Ruizhe Pan, Runxin Xu, Ruyi Chen, S. S. Li, Shanghao Lu, Shangyan Zhou, Shanhuang Chen, Shaoqing Wu, Shengfeng
|
||||
@@ -0,0 +1,94 @@
|
||||
# 📊 文章摘要：How Far Can Disaggregation Go? A Design-Space Exploration of Attention-FFN Disaggregation for Efficient MoE LLM Serving
|
||||
|
||||
> **原文**：[2026-05-27_AFD_How_Far_Can_Disaggregation_Go.md](./2026-05-27_AFD_How_Far_Can_Disaggregation_Go.md)
|
||||
> **原文链接**：https://arxiv.org/abs/2605.28302
|
||||
> **来源**：arXiv
|
||||
> **作者**：Hanjiang Wu, Abhimanyu Rajeshkumar Bambhaniya, Sarbartha Banerjee, Tuhin Khare, Sudarshan Srinivasan, Suvinay Subramanian 等 12 位（佐治亚理工学院、Intel、Google、Google DeepMind、Infravana）
|
||||
> **发布日期**：2026-05-27
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **算子级解耦** — 解耦不止于阶段（prefill/decode），可下探到算子级：把内存受限的 attention 与计算密集的 MoE-FFN 拆分到不同 GPU 组（AFD），并以设计空间探索给出"何时、何处更深层解耦才划算"的实用地图。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
随着 MoE 模型（如 DeepSeek-V3.2）规模扩大与 TTFT/TPOT SLO 收紧，LLM serving 的解耦粒度不断加深：从 chunked-prefill 聚合，到 prefill/decode（P/D）解耦，再到算子级 attention-FFN 解耦（AFD）。本文系统回答"每一层解耦何时真正划算"：基于 vLLM 的 AFD 原型 + AIConfigurator（算子级计算建模）+ AstraSim（包粒度网络模拟）构建 AIC++ 框架，对 128 卡 B200 集群上 4 种模型（DeepSeek-V3.2、GPT-OSS-120B、Nemotron3-120B、Qwen3-235B）× 3 类负载（chat/coding/agentic coding）做全维设计空间探索。核心发现：严格 SLO 下 AFD 在 DeepSeek-V3.2 上可维持约 4k tokens/s 系统吞吐，而非 AFD 部署不可行；吞吐维度没有单一策略通吃（chunked prefill 聚合常胜），但延迟/交互性维度 AFD 全胜，且最优 attention/FFN GPU 比例可依模型与负载导出（如 DeepSeek-V3.2 长上下文下 2A+126F 的极端配比）。局限：结果基于建模 + 模拟的 DSE 估计，原型仅验证功能正确性。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **解耦粒度演化谱系** — chunked-prefill 聚合 → P/D 阶段解耦 → AFD 算子级解耦，每一层解耦都加深调度设计空间（工作负载特性 × 资源分配 × 互连拓扑），本文首次系统回答"解耦能走多远"这一问题。`[分类: 范式突破]`
|
||||
2. **MoE 架构放大算子异构** — attention（MHA/GQA/MLA）内存受限、FFN 计算密集，加上 MoE dispatch/combine 通信，一个 transformer 块内就存在显著计算异构；粗粒度抽象（MegaScale-Infer 已指出的问题）在 MoE 上尤其失效。`[分类: 共识]`
|
||||
3. **严格 SLO 下 AFD 使不可能变为可能** — DeepSeek-V3.2 上以 TTFT<50/100/150ms、TPOT≤15ms 的严格约束（chat/coding/agentic coding），AFD 部署维持约 4k tokens/s 系统吞吐，而非 AFD 部署不可行（infeasible）。`[分类: 范式突破]`
|
||||
4. **吞吐前沿无通吃方案** — 128×B200 集群 DSE：chunked prefill 聚合部署（16 个单节点 8-GPU 副本）赢得多数面板；AFD 单独赢得一个面板（GPT-OSS-120B chat，16A+16F 近似对称拆分）；非对称副本形态（如 2-GPU prefill 工人喂 8-GPU decode 工人）是解耦方案胜出的关键。`[分类: 争议]`
|
||||
5. **延迟维度 AFD 全胜** — 每个面板的最优 attention/FFN 拆分都追踪模型内在的 attention/mixer 成本与 FFN 成本之比；AFD 特定微批重叠（four-stage pipeline，全双工链路）最大化计算-通信重叠，始终给出最佳延迟与用户交互性。`[分类: 未探索]`
|
||||
6. **反直觉的极端配比** — DeepSeek-V3.2 的 MLA + 稀疏注意力把每 token attention 计算与 KV cache 足迹压得极小，长上下文 agentic 负载（524k prefix）下最优配置为 2A+126F——整个 524k 前缀的 KV cache 可装入 2 个 GPU 的 HBM，几乎整个集群给 FFN。`[分类: 范式突破]`
|
||||
7. **内存分割是隐藏收益** — 把多数模型权重放在 FFN GPU 上，attention GPU 腾出显存装 KV cache，同一内存约束下可支撑更高吞吐——AFD 的收益不止调度层面。`[分类: 未探索]`
|
||||
8. **位置感知放置原则** — 最频繁的层内 A2F/F2A 流量（每请求 O(layer)）绑定最高带宽 scale-up 域（NVLink），低频的跨节点 KV cache 传输（每请求 O(1)）走 scale-out（InfiniBand）；A2F 扇形广播（fan-out）使 FFN 侧入口拥塞、F2A 扇形汇聚（fan-in）使 attention 侧入口成为瓶颈。`[分类: 未探索]`
|
||||
9. **AIC++ 方法论** — 内核级实测成本库（AIConfigurator）+ 包粒度拥塞感知网络模拟（AstraSim）联合建模，以 vLLM AFD 原型锚定通信模式与功能正确性；论文明示集群级结果均为"模型驱动 DSE 估计"。`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 异构/解耦硬件时代将到来：节点内出现计算/内存不对称的加速器组（NVIDIA Groq-3 LPX、Rubin CPX、Intel/SambaNova 等），且存在 NVLink 级高带宽 scale-up 互连。
|
||||
- AFD 的通信模式（all-pairs 的 A2F/F2A 双向传输）在真实网络上可被微批重叠技术有效隐藏。
|
||||
- 内核级测量成本库 + AstraSim 网络模拟的组合足以逼近真实集群行为，从而替代全系统原型评估。
|
||||
- 以系统吞吐与用户交互性（tokens/s/user）为目标的 SLO 框架能代表生产诉求。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 论据结构严谨：先以运行时分解与内存分解数据（图 3）确立算子异构事实，再用 AIC++ 在 128 卡规模做穷举式 DSE（副本规模 2-128 卡全枚举 + TP/DP/EP/SP/PP 与 P/D、AFD 联合搜索），结论（无通吃方案、AFD 延迟全胜、配比可推导）有模拟数据支撑。
|
||||
- 关键量化结论（约 4k tokens/s、2A+126F、2.35×/1.4× 类收益的可比性）均限定在各自严格语境中，未过度外推。
|
||||
- 弱点：集群级结论全部来自建模估计，AIC++ 的准确性未与真实 AFD 集群端到端对照；vLLM 原型仅验证功能正确性，无法排除建模误差对"吞吐前沿无通吃方案"等核心结论的影响；对非 AFD 部署"不可行"的判定依赖 SLO 设定与搜索范围的完整性（论文也承认窄 TP≤8 搜索曾漏掉可行配置）。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- AFD 的优势集中于延迟/交互性维度与严格 SLO 场景；纯吞吐目标下 chunked prefill 聚合常更优——结论不可泛化为"AFD 总是更好"。
|
||||
- 依赖高带宽 scale-up 互连；半双工/低带宽网络下微批重叠收益收缩（pipeline 深度由 4 降为 3）。
|
||||
- 配比指导依赖模型架构（MLA/GQA/Mamba 差异显著），换架构需重跑 DSE。
|
||||
- 结果基于模拟，需真实异构集群验证；524k prefix 属极端长上下文建模，超出部分模型原生窗口。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Our findings deliver a practical map of when and where deeper disaggregation pays off for MoE serving at scale."
|
||||
> （我们的发现提供了一张实用地图：在 MoE 规模化服务中，何时、何处更深层的解耦才真正划算。）
|
||||
|
||||
> "Under strict TTFT/TPOT SLOs, AFD sustains around 4k tokens/s of system throughput on DeepSeek-V3.2 across chat, coding, and agentic-coding workloads, regimes in which non-AFD deployments are infeasible."
|
||||
> （在严格的 TTFT/TPOT SLO 下，AFD 在 DeepSeek-V3.2 上于 chat、coding 与 agentic-coding 负载中维持约 4k tokens/s 的系统吞吐，而这是非 AFD 部署不可行的场景。）
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 首次把解耦粒度推进到算子级（AFD）并系统回答"解耦能走多远"，把 2023-2024 年的阶段解耦共识延伸为新范式
|
||||
- "吞吐无通吃方案、延迟 AFD 全胜"的差异化结论打破了"解耦必然更好"的朴素预期，结论颗粒度精细
|
||||
- 给出可操作的 attention/FFN GPU 配比指导（含 2A+126F 这类反直觉结论背后的推理），并揭示内存分割这一隐藏收益
|
||||
- AIC++ 把内核实测与网络模拟结合的建模方法论，为异构推理基础设施设计提供了可复用工具
|
||||
|
||||
**不足**：
|
||||
- 集群级结论全部基于建模与模拟，缺少真实 AFD 集群的端到端验证
|
||||
- 部分结论（如"非 AFD 不可行"）对 SLO 设定与搜索范围敏感，泛化需谨慎
|
||||
- 评估硬件模型（B200 + TensorRT-LLM）与实际异构平台（Groq-3 LPX 等）仍有差距
|
||||
|
||||
**适用场景**：MoE 模型 serving 的系统架构师；面向异构加速器（Groq-3 LPX、Rubin CPX 等）与解耦集群的设计者；研究 LLM serving 设计空间探索的研究人员。
|
||||
|
||||
**关联建议**：向上游追溯 DistServe（P/D 解耦起点）、Splitwise（异构硬件）、Mooncake（生产实践），可看出"解耦粒度深化"的完整脉络；后续可关注 MegaScale-Infer（同方向的算子级优化）、Mist（同团队的异构多阶段 co-design 框架）以及 NVIDIA 解耦平台（LPX/CPX）的真实部署验证。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,388 @@
|
||||
# Splitwise: Efficient Generative LLM Inference Using Phase Splitting
|
||||
|
||||
> **来源**：arXiv
|
||||
> **作者**：Pratyush Patel, Esha Choukse, Chaojie Zhang, Aashaka Shah, Íñigo Goiri, Saeed Maleki, Ricardo Bianchini
|
||||
> **发布日期**：2023-11-30
|
||||
> **原文链接**：https://arxiv.org/abs/2311.18677
|
||||
|
||||
---
|
||||
|
||||
## 论文元数据
|
||||
|
||||
- **arXiv ID**：2311.18677
|
||||
- **学科分类**：Distributed, Parallel, and Cluster Computing (cs.DC)
|
||||
- **作者机构**：华盛顿大学（University of Washington）、微软（Microsoft）
|
||||
- **提交历史**：v1: 2023-11-30；v2: 2024-05-20
|
||||
- **DOI**：https://doi.org/10.48550/arXiv.2311.18677
|
||||
|
||||
---
|
||||
|
||||
Pratyush Patel1,
|
||||
Esha Choukse2,
|
||||
Chaojie Zhang2,
|
||||
|
||||
Aashaka Shah2,
|
||||
Íñigo Goiri2,
|
||||
Saeed Maleki2,
|
||||
Ricardo Bianchini2
|
||||
|
||||
1University of Washington 2Microsoft
|
||||
|
||||
## 摘要（Abstract）
|
||||
|
||||
Generative large language model (LLM) applications are growing rapidly, leading to large-scale deployments of expensive and power-hungry GPUs.
|
||||
Our characterization of LLM inference shows that each inference request undergoes two phases: a compute-intensive prompt computation phase and a memory-intensive token generation phase, each with distinct latency, throughput, memory, and power characteristics.
|
||||
Despite state-of-the-art batching and scheduling, the token generation phase underutilizes compute resources.
|
||||
Unlike prompt computation, token generation does not need the compute capability of the latest GPUs and can be run with lower power and cost.
|
||||
|
||||
Based on these insights, we propose Splitwise, a model deployment and scheduling technique that splits the two phases of LLM inference requests on to separate machines.
|
||||
Splitwise enables phase-specific resource management using hardware that is well suited for each phase.
|
||||
Request state is transferred efficiently between machines using optimized network libraries on the fast back-plane interconnects available in today’s GPU clusters.
|
||||
Using Splitwise, we design homogeneous and heterogeneous LLM inference clusters optimized for throughput, cost, and power.
|
||||
Compared to current designs, Splitwise clusters achieve up to 1.4×1.4 × higher throughput at 20% lower cost. Alternatively, they can deliver 2.35×2.35 × more throughput under the same power and cost budgets.
|
||||
|
||||
## I 引言（Introduction）
|
||||
|
||||
Recent advancements in generative large language models (LLMs) have significantly improved their response quality and accuracy [18, 71].
|
||||
These trends have led to the widespread adoption of LLMs across various domains [6, 21].
|
||||
Most modern LLMs are built using the transformer architecture [78, 77] and exhibit similar characteristics [63].
|
||||
Transformer model sizes have grown steadily, from the early BERT models [36] having 340 million parameters, to GPT-3 [28] with a staggering 175 billion parameters, and GPT-4 rumored to have even more.
|
||||
|
||||
LLMs typically run on expensive and power-hungry GPUs [16].
|
||||
The sudden and large-scale deployment of LLMs has led to a worldwide GPU capacity crunch [14].
|
||||
The computational demand for LLM inference far exceeds that of training due to the vast number of applications leveraging LLMs.
|
||||
Furthermore, since training LLMs requires expensive and dedicated supercomputers [60, 56], a large number of inferences are necessary to amortize the high training costs.
|
||||
LLM inference jobs, although orders of magnitude smaller than training, are still expensive given the compute involved.
|
||||
11脚注: Work partly done as an intern at Microsoft.
|
||||
|
||||
TABLE I: NVIDIA A100 vs. H100 specifications.
|
||||
|
||||
Generative LLM inference for a single request consists of several forward passes through the model, since the output tokens are generated one by one.
|
||||
This inherently has two contrasting phases of computation.
|
||||
First, the _prompt computation phase_, in which all the input prompt tokens run through the forward pass of the model in parallel to generate the first output token.
|
||||
This phase tends to be computationally intensive and requires the high FLOPs (floating point operations per second) of the latest GPUs today.
|
||||
Second, the _token generation phase_, in which subsequent output tokens are generated sequentially based on the forward pass of the last token and all the cached context from previous tokens in the sequence.
|
||||
Given the lack of compute parallelism, this phase tends to be more memory bandwidth and capacity bound, despite state-of-the-art batching.
|
||||
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.
|
||||
Due to these challenges, services need to over-provision expensive GPUs to meet tight inference service level objectives (SLOs) for interactive applications.
|
||||
At the same time, cloud service providers (CSPs) are having to build a lot of new datacenters to meet the GPU demand, and are running into a power wall [19].
|
||||
|
||||
The industry continues to release new computationally powerful GPUs, each much more power hungry and expensive than the last.
|
||||
However, as shown in Table I, the high-bandwidth memory (HBM) capacity and bandwidth on these GPUs has not scaled at the same rate recently.
|
||||
The latest NVIDIA H100 GPUs have 3.43×3.43 × more compute and 1.75×1.75 × more power compared to their predecessor A100 GPUs.
|
||||
However, their memory bandwidth only grew by 1.6×1.6 ×, with no increase in memory capacity.
|
||||
|
||||
Our work.
|
||||
Given the distinct properties of prompt computation and token generation phases, we propose splitting the inference request and running them on separate machines.
|
||||
Doing so allows us to separately manage hardware resources for each phase, thereby increasing the GPU utilization and the overall efficiency of the system.
|
||||
It also enables using different, better-suited hardware for each phase.
|
||||
To realize such a setup, the cached context from the prompt computation needs to be communicated over from the prompt processing machine to the token generation machine at low latency.
|
||||
We implement these transfers in an optimized manner over the back-end Infiniband interconnects avaialble in datacenters today, allowing us to increase efficiency without any perceived performance loss.
|
||||
|
||||
With Splitwise, we design clusters optimized for cost, throughput, and power, using production traces of LLM inference requests [4].
|
||||
Given the diverging memory and compute scaling rates across GPU generations, we also evaluate different GPUs and power caps for the different inference phases.
|
||||
This allows us to target better performance per dollar (Perf/$) for users, and better performance per watt (Perf/W) for CSPs.
|
||||
Additionally, users can target older GPUs, which are likely more readily available to them.
|
||||
|
||||
We show that Splitwise-based LLM inference clusters can achieve 1.4× higher throughput at 20% lower cost than existing clusters. Alternatively, they can deliver 2.35× more throughput with the same cost and power budgets.
|
||||
|
||||
Summary.
|
||||
We make the following contributions:
|
||||
|
||||
1. 1.
|
||||
|
||||
An extensive characterization of the differences in the execution and utilization patterns of the prompt and token generation phases in LLM inference on the NVIDIA A100 and H100 GPUs using production traces.
|
||||
2. 2.
|
||||
|
||||
Splitwise, our technique for optimized utilization of available hardware, which splits the prompt computation and token generation phases onto separate machines.
|
||||
3. 3.
|
||||
|
||||
A design exploration of homogeneous and heterogeneous cluster deployments with Splitwise to optimize the overall cost, request throughput, and provisioned power.
|
||||
4. 4.
|
||||
|
||||
An evaluation of the systems designed with Splitwise using production traces.
|
||||
|
||||
## II Background
|
||||
|
||||
### II-A Large Language Models
|
||||
|
||||
Modern LLMs are based on transformers.
|
||||
Transformer models use attention [77] and multi-layer-perceptron layers to understand the inputs and generate an output, respectively.
|
||||
Transformer-based LLMs include encoder-only [36, 54], decoder-only [67, 69, 71], and encoder-decoder [70] models.
|
||||
Generative LLMs, the focus of this paper, are usually either decoder-only, or encoder-decoder models.
|
||||
|
||||
### II-B Generative LLM inference phases
|
||||
|
||||
Figure 1 shows an example of generative LLM inference.
|
||||
Once the prompt query is received, all the input tokens are computed in parallel, within a single iteration, to generate the first token.
|
||||
We call this the prompt processing phase.
|
||||
The context generated from the attention layers during the prompt computation is saved in the key-value (KV) cache, since it is needed for all the future token generation iterations.
|
||||
After the first token is generated, the following tokens only use the last generated token and the KV-cache as inputs to the forward pass of the model.
|
||||
This makes the subsequent token generation more memory bandwidth and capacity intensive than the computationally heavy prompt phase.
|
||||
|
||||
Figure 1: An LLM inference example.
|
||||
|
||||
### II-C Performance metrics for LLMs
|
||||
|
||||
Prior work has proposed three main metrics for LLM inference: end-to-end (E2E) latency, time to first token (TTFT), and throughput.
|
||||
We add another latency metric: time between tokens (TBT), to track the online streaming throughput of the tokens as they are generated serially.
|
||||
Table II summarizes the key performance metrics that we consider in this work.
|
||||
|
||||
TABLE II: Performance metrics for LLMs.
|
||||
|
||||
Generative LLMs may be used for a variety of tasks with different kinds of SLOs.
|
||||
For batch tasks (_e.g._, summarization), TTFT or TBT latency metrics are less important than throughput.
|
||||
On the other hand, for latency-sensitive tasks (_e.g._, conversational APIs), TTFT and TBT are the more important metrics with tighter SLOs.
|
||||
|
||||
Figure 2: Batching mechanisms and their latency impact on the pro
|
||||
|
||||
ut keeps scaling up with the batch size until the machine runs out of memory.
|
||||
For this reason, the MLS tracks the memory and starts queueing tokens once the machine is close to running out of memory.
|
||||
|
||||
Mixed machines.
|
||||
To meet the TTFT SLO, the MLS must prioritize running prompts and schedule any new prompts in the pending queue immediately.
|
||||
If the machine is running token phases and has no additional capacity to run the prompt phase, the MLS will _preempt_ tokens.
|
||||
To avoid _starvation_ of the token phase due to preemption, we increase the priority of the token with age and limit the number of preemptions that each request can have.
|
||||
|
||||
### IV-C KV-cache transfer
|
||||
|
||||
As discussed in Section II, the KV-cache is generated during the prompt phase of the request, and it continuously grows during the token generation phase.
|
||||
In Splitwise, we need to transfer the KV-cache from the prompt machine to the token machine (shown in Figure 10) to complete the inference.
|
||||
This transfer delay is the main overhead associated with Splitwise.
|
||||
In this section, we discuss the impact of KV-cache transfer and how we optimize it.
|
||||
|
||||
(a)
|
||||
|
||||
(b)
|
||||
|
||||
Figure 11: Optimizing KV-cache transfer in Splitwise.
|
||||
|
||||
Figure 11(a) shows the Gantt chart for the prompt phase, the KV-cache transfer, and the token generation phase for a single batch of requests when naively transferring the KV cache in a serialized way.
|
||||
The KV-cache transfer starts only after the prompt phase has finished and the first token is generated.
|
||||
Further, it needs to complete before the next output token can be generated in the token generation phase.
|
||||
This directly impacts the maximum TBT and end-to-end latency of inference.
|
||||
|
||||
The time required for the transfer depends on the size of the KV cache (which is directly proportional to the number of prompt tokens) and on the bandwidth of the interconnect between the prompt and the token machines.
|
||||
Even when using fast InfiniBand links, the transfer overhead for large prompt sizes could become a significant fraction of the TBT.
|
||||
|
||||
In Splitwise, we optimize the KV-cache transfer by overlapping it with the computation in the prompt phase.
|
||||
As each layer in the LLM gets calculated in the prompt machine, the KV cache corresponding to that layer is also generated.
|
||||
At the end of each layer, we trigger an asynchronous transfer of the KV-cache for that layer while the prompt computation continues to the next layer.
|
||||
Figure 11(b) shows this asynchronous transfer which reduces the transfer overheads.
|
||||
Layer-wise transfer also enables other optimizations, such as earlier start of the token phase in the token machines, as well as earlier release of KV-cache memory on the prompt machines.
|
||||
|
||||
Layer-wise KV-cache transfer happens in parallel with the prompt computation for the next layer.
|
||||
This requires fine-grained synchronization per layer for correctness.
|
||||
Thus, it is possible to incur performance interference and increase the TTFT, especially for smaller prompts.
|
||||
However, for small prompts the total KV-cache size is small and does not need the layer-wise transfer to hide the latency.
|
||||
Since the number of tokens in a batch is already known at the start of computation, Splitwise picks the best technique for KV-cache transfer.
|
||||
It uses serialized KV-cache transfer for smaller prompts and layer-wise transfer and for larger prompts.
|
||||
We show that the overall transfer and interference overheads are relatively small in Section VI-A.
|
||||
|
||||
TABLE V: Evaluated Splitwise designs all normalized to DGX-A100
|
||||
|
||||
### IV-D Provisioning with Splitwise
|
||||
|
||||
We leverage Splitwise to optimize LLM inference cluster deployments for power, cost, and throughput.
|
||||
|
||||
Type of machines.
|
||||
We propose four main variants of Splitwise-based systems:
|
||||
_Splitwise-AA_,
|
||||
_Splitwise-HH_,
|
||||
_Splitwise-HA_,
|
||||
and _Splitwise-HHcap_.
|
||||
The nomenclature is simply drawn from the first letter representing the Prompt machine type, and the second letter representing the Token machine type.
|
||||
“A” represents a DGX-A100 machine, “H” represents a DGX-H100 machine,
|
||||
and “Hcap” represents a power-capped DGX-H100 machine.
|
||||
Table V shows a summary of the cost, power, and hardware in each of our evaluated systems.
|
||||
|
||||
Splitwise-AA uses DGX-A100 for both prompt and token pools, while Splitwise-HH uses DGX-H100 for both.
|
||||
These two variants represent the commonly available setups in providers where machines are homogeneous and interchangeable.
|
||||
|
||||
Splitwise-HA uses DGX-H100 for the prompt pool and DGX-A100 for the token pool.
|
||||
We choose this configuration based on Table IV, and the Insight VII (_i.e._, A100s can be more cost- and power-efficient for the token phase).
|
||||
|
||||
Splitwise-HHcap uses DGX-H100 machines for both prompt and token pools.
|
||||
However, we power cap the token machines down to 70% of their rated power, with each GPU capped by 50% of the power.
|
||||
We propose this design based on Figure 9 and Insight VII (_i.e._, the prompts phase is impacted by power caps while token has no performance impact with 50% lower power cap per GPU).
|
||||
|
||||
Number of machines.
|
||||
The LLM inference cluster deployment must be sized with the appropriate number of prompt and token machines.
|
||||
Our methodology involves searching the design space using our event-driven cluster simulator, which is described in detail in Section V.
|
||||
We need to provide as input:
|
||||
(1) the target cluster design (_e.g._, Splitwise-HA or Splitwise-HHcap),
|
||||
(2) an LLM-specific performance model that can estimate the TTFT and TBT at various input, output, and batch sizes,
|
||||
(3) a short trace derived from the target prompt and token size distributions for the service (_e.g._, Figure 3),
|
||||
(4) the SLOs (_e.g._, Table VI),
|
||||
(5) the constraints (_e.g._, throughput),
|
||||
and (6) the optimization goal (_e.g._, minimize cost).
|
||||
Using this information, our provisioning framework searches the space for the desired optimal point.
|
||||
For example, searching with a throughput constraint and a cost minimization goal gives us iso-throughput cost-optimized clusters across different designs.
|
||||
|
||||
|
||||
|
||||
Figure 12: Design space for provisioning a Splitwise-HH cluster.
|
||||
Cluster configurations targets a peak throughput of 70 RPS.
|
||||
The cost-optimal Splitwise-HH configuration is marked with ⋆⋆⋆ (27 prompt and 3 token machines).
|
||||
|
||||
Search space.
|
||||
Figure 12 shows an example of the two-dimensional search space for the number of prompt and token machines under Splitwise-HH for the coding workload (using a 2-minute trace).
|
||||
The simulator outputs the various percentiles for TTFT, TBT, and E2E latencies.
|
||||
Then, we select the clusters that meet the SLOs for each of these metrics and optimize our target function.
|
||||
For example, Figure 12 shows a ⋆⋆⋆ for the setup with 27 prompt and 3 token machines with the lowest cost that achieves 70 RPS.
|
||||
We call this setup _iso-throughput cost-optimized_.
|
||||
|
||||
Optimization.
|
||||
We can use three optimization goals:
|
||||
_throughput_, _cost_, and _power_.
|
||||
Throughput optimization is important for both, the cloud service provider (CSP) and the user.
|
||||
Cost optimization has different importance levels to the CSP and the user.
|
||||
For the CSP, a higher cost for the same throughput might be acceptable if there are gains in power and space requirements for the cluster.
|
||||
However, for the end-user, a higher cost at the same throughput is generally unacceptable.
|
||||
Finally, power optimization is attractive for a CSP, since it enables more GPUs to be deployed in the same datacenter [62, 63], but it may not be as important to the user.
|
||||
We only consider the provisioned power, and not the dynamic power utilization, in our study.
|
||||
|
||||
### IV-E Practical Considerations
|
||||
|
||||
Accuracy impact.
|
||||
Splitwise does not impact accuracy since it uses lossless KV-cache transfer and does not add any randomization.
|
||||
It executes inference with the same parameters and state as on a single machine.
|
||||
|
||||
Scalability.
|
||||
Since LLM requests are much longer than typical ML requests [37, 38], they incur lower scheduling overhead for similar cluster sizes.
|
||||
However, the CLS may become a scalability bottleneck for large clusters.
|
||||
Insights from prior work on partitioned or replicated scheduling could help improve scalability [61, 27, 72] and are orthogonal to Splitwise.
|
||||
|
||||
Reliability and fault tolerance.
|
||||
If the prompt or the token machine fail, Splitwise simply restarts requests from scratch, similar to today’s LLM serving systems [51, 44].
|
||||
Alternatively, Splitwise could checkpoint the KV-cache generated after prompt computation into an in-memory database.
|
||||
To recover, Splitwise can use this cache to skip prompt recomputation, and start right away with the token phase.
|
||||
The KV-cache could also be checkpointed periodically during the token phase.
|
||||
Designing safe and efficient failure recovery is out of scope for our paper.
|
||||
|
||||
## V Methodology
|
||||
|
||||
### V-A Experimental setup
|
||||
|
||||
To evaluate our proposal on real hardware, we implement Splitwise’s KV-cache transfer mechanism on top of vLLM [51]. Our implementation is open source [1].
|
||||
We run this modified vLLM on two DGX-A100 and two DGX-H10 virtual machines (VMs) on Microsoft Azure with specifications from Table I.
|
||||
These are the VMs used to collect the characterization data in Section III.
|
||||
These machines are connected with InfiniBand and the DGX-H100s have double the bandwidth (_i.e._, 400 Gbps).
|
||||
|
||||
Since vanilla vLLM only supports continuous batching with token preemption which can lead to much higher TBT, we implement state-of-the-art mixed continuous batching [81] as discussed earlier in Figure 2(c).
|
||||
|
||||
Our implementation of the Splitwise technique assigns machines either a prompt role, or a token role.
|
||||
As the prompt machine generates the first token, it transfers the KV-cache to the token machine using the technique described in Section IV-C.
|
||||
We use MSCCL++ [11], an optimized GPU-driven communication library, to implement the naive and layer-wise KV cache transfers.
|
||||
|
||||
In our implementation, the prompt machine uses the zero-copy one-sided put primitive of MSCCL++ to send KV-cache data over InfiniBand as soon as it is ready, without requiring the token machine to issue any receive instructions.
|
||||
Once we have issued a put for all layers, the prompt machine signals a semaphore that the token machine waits on.
|
||||
The synchronization done with the help of semaphores uses the same InfiniBand connection used to send KV-cache data.
|
||||
When processing a batch of prompts, each request is assigned a different semaphore since it may be routed to different token machines.
|
||||
We ship the KV-caches block-by-block in vLLM.
|
||||
To minimize the number of transfers, we also consider the contiguity of KV blocks as long as they use the same semaphore.
|
||||
|
||||
### V-B Simulator setup
|
||||
|
||||
We build a simulator to explore cluster designs and evaluate Splitwise at scale.
|
||||
The simulator code is open source [20].
|
||||
|
||||
|
||||
|
||||
Figure 13: Overview of the design of the Splitwise simulator.
|
||||
|
||||
Figure 13 shows the design of our simulator.
|
||||
The simulator is event-driven and faithfully models the Splitwise machine pools, schedulers, machine-level memory and queues, and KV-cache transfer.
|
||||
We first profile the LLM on the target hardware with various input/output sizes .
|
||||
Based on the characterization profiles, we build a performance model.
|
||||
The simulator takes as input the request traces, SLOs, the performance model, and the configurations for cluster and scheduler .
|
||||
For our evaluation, we use the prompt and token size distributions from the production traces in Section III.
|
||||
We tune the Poisson arrival rate to increase and decrease the load (requests per second) for cluster sizing.
|
||||
The simulator provides the achieved metrics per request (TTFT, TBT, E2E), and the machine utilization levels .
|
||||
We cross-validated the performance model with hardware experiments to ensure accuracy; we also validated the simulator end-to-end using production load with over 50K iterations to ensure fidelity .
|
||||
|
||||
Performance model.
|
||||
We build a piece-wise linear performance model using performance profiles at various batch sizes, input sizes, output sizes, in the required parallelism configuration on A100 and H100 machines from Section III.
|
||||
We validate that our performance model has high accuracy; it incurs a mean absolute percentage error (MAPE) of less than 3% when evaluated with a 80:20 train:test dataset split.
|
||||
|
||||
Communication model.
|
||||
In our evaluation, KV-cache transfers cause inter-machine communication, whereas tensor parallelism only causes intra-machine communication.
|
||||
We model inter-machine communication overheads by benchmarking our KV-cache transfer implementation over Infiniband in Section VI-A.
|
||||
|
||||
SLOs.
|
||||
To determine the maximum throughput that can be supported by a given cluster design, we use P50, P90, and P99 SLOs for TTFT, TBT, and E2E latency metrics.
|
||||
Table VI shows our SLO definition using DGX-A100 as a reference.
|
||||
We require all nine SLOs to be met.
|
||||
SLOs on TTFT are slightly looser, since it has a much smaller impact on the E2E latency.
|
||||
|
||||
TABLE VI: SLO expressed as slowdown compared to a request running on DGX-A100 under no contention.
|
||||
|
||||
Baselines.
|
||||
We compare our Splitwise designs against Baseline-A100 and Baseline-H100.
|
||||
The clusters in these baselines consist of just DGX-A100s and DGX-H100s, respectively.
|
||||
Both baselines use the same mixed continuous batching that Splitwise uses for mixed pool machines (described in Section IV-A).
|
||||
|
||||
## VI Evaluation
|
||||
|
||||
### VI-A Experimental results
|
||||
|
||||
KV-cache transfer latency.
|
||||
We first measure the latency to transfer the KV-cache as the prompt size grows.
|
||||
Figure 14 shows the visible transfer latency on both A100 and H100 setups with the naive and optimized transfer design as discussed in Figure 11.
|
||||
Compared to the prompt computation time, the overhead is minimal (<7%7<7\%< 7 %).
|
||||
The time for serialized transfers linearly increases with the prompt size since the size of the KV-cache also increases.
|
||||
The optimized per-layer transfer, on the other hand, hides much of the latency.
|
||||
For these transfers, we see a constant non-overlapped transfer time of around 8ms for the A100 and around 5ms for the H100 setup.
|
||||
The H100 setup has double the bandwidth of the A100 setup (_i.e._, 200 vs 400 Gbps), and the impact of this can be clearly seen with transfers in the H100 setup happening about twice as fast as those in the A100 setup.
|
||||
|
||||
As discussed in Section IV-C, for small prompt sizes (<512absent512<512< 512 in H100), Splitwise uses the serialized KV-cache transfer and for larger prompts, it uses per-layer transfers.
|
||||
|
||||
|
||||
|
||||
Figure 14: Overhead of the KV-cache transfer as the prompt size increases on A100s and H100s.
|
||||
|
||||
End-to-end impact.
|
||||
Next, we run the coding trace on the 2-machine Splitwise setups without batching, and compare the observed latency metrics to a 1-machine baseline setup with no batching.
|
||||
Figure 15 shows our results.
|
||||
The latency impact of serially transferring the KV-cache grows up to 3% of the E2E with large prompts.
|
||||
However, Splitwise only incurs 0.8% of E2E.
|
||||
In a user-facing inference, the only visible impact of KV-cache transfer overhead is the latency for the second token.
|
||||
Splitwise adds a 16.5% latency to the second token, as compared to the 64% overhead from a serialized transfer.
|
||||
Overall, the transfer impact in Splitwise is hardly perceivable even in a user-facing inference.
|
||||
|
||||
|
||||
|
||||
Figure 15: Overhead of KV cache transfer on TTFT, E2E latency for coding trace for A100 and H100.
|
||||
|
||||
### VI-B Iso-power throughput-optimized clusters
|
||||
|
||||
Cluster provisioning.
|
||||
We provision clusters using the methodology described in Section IV-D.
|
||||
We target a specific workload (_e.g._, conversation) at a peak load with the same power (_i.e._, iso-power) for each cluster design.
|
||||
For the baseline, we use the power for 40 DGX-H100 machines as our target peak power.
|
||||
For the A100 baseline, we can fit 70 DGX-A100 machines under the same power budget.
|
||||
We denote these two designs as 40P/T and 70P/T respectively, since they both use mixed batching in all machines.
|
||||
|
||||
For Splitwise cluster designs under the coding trace, Splitwise-AA provisions 55 prompt machines and 15 for the token pool, denoted as (55P, 15P).
|
||||
Note that like Baseline-A100, Splitwise-AA also provisions 75% more machines than Baseline-H100.
|
||||
The legends in Figure 16 show the different provisioning choices under coding and conversation workloads.
|
||||
Request size distributions reflect in the machine pool sizing.
|
||||
For example, we provision
|
||||
|
||||
[18].
|
||||
However, in the future, services may have enough GPU capacity to cache the context and avoid recomputation.
|
||||
This could sway the memory utilization pattern of the prompt phase from our characterization.
|
||||
Furthermore, it may require transferring the KV-cache back to a prompt machine to be ready for the next conversation request.
|
||||
|
||||
## VIII Related Work
|
||||
|
||||
Heterogeneous scheduling and dataflow systems.
|
||||
Prior work has studied heterogeneous scheduling for a variety of interactive services [83, 65, 68].
|
||||
These works exploit hardware heterogeneity to strike a balance between different objectives such as cost, energy, and performance.
|
||||
However, they run the entire workload on the same machine.
|
||||
Research on heterogeneous multiprocessor CPU scheduling attempts to match workload heterogeneity to hardware heterogeneity [40, 76, 41, 50, 80, 29].
|
||||
These works use profiling or online monitoring with metrics like request length or hardware performance counters to identify workload phases and allocate them appropriately on heterogeneous processors.
|
||||
However, they do not consider the complexities with batching.
|
||||
Distributed dataflow systems orchestrate large-scale computational graphs and aim to provide general-purpose programmability [34, 46, 75, 82].
|
||||
LLM inference under Splitwise can be viewed as a static computational graph with two stages, so it could be implemented using distributed frameworks that provide efficient GPU abstractions [59].
|
||||
Splitwise differs from these works since it uses a spe
|
||||
@@ -0,0 +1,93 @@
|
||||
# 📊 文章摘要：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 解耦功能的演进。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,276 @@
|
||||
# Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
> **来源**：arXiv
|
||||
> **作者**：Ruoyu Qin, Zheming Li, Weiran He, Mingxing Zhang, Yongwei Wu, Weimin Zheng, Xinran Xu
|
||||
> **发布日期**：2024-06-24
|
||||
> **原文链接**：https://arxiv.org/abs/2407.00079
|
||||
|
||||
---
|
||||
|
||||
## 论文元数据
|
||||
|
||||
- **arXiv ID**：2407.00079
|
||||
- **学科分类**：Distributed, Parallel, and Cluster Computing (cs.DC); Artificial Intelligence (cs.AI); Hardware Architecture (cs.AR)
|
||||
- **作者机构**：月之暗面（Moonshot AI）、清华大学
|
||||
- **提交历史**：v1: 2024-06-24；v2: 2024-07-02；v3: 2024-07-09；v4: 2025-09-03
|
||||
- **DOI**：https://doi.org/10.48550/arXiv.2407.00079
|
||||
|
||||
---
|
||||
|
||||
11脚注: Ruoyu Qin’s part of work done as an intern at Moonshot AI, contributed equally with Zheming Li.22脚注: Corresponding to zhang_mingxing@mail.tsinghua.edu.cn, xuxinran@moonshot.ai.
|
||||
|
||||
Ruoyu Qin♠♡1 Zheming Li♠1 Weiran He♠
|
||||
|
||||
&Mingxing Zhang♡2 Yongwei Wu♡ Weimin Zheng♡ Xinran Xu♠2
|
||||
|
||||
♠Moonshot AI ♡Tsinghua University
|
||||
|
||||
## 摘要（Abstract）
|
||||
|
||||
Mooncake is the serving platform for Kimi, a leading LLM service provided by Moonshot AI. It features a KVCache-centric disaggregated architecture that separates the prefill and decoding clusters. It also leverages the underutilized CPU, DRAM, and SSD resources of the GPU cluster to implement a disaggregated cache of KVCache. The core of Mooncake is its KVCache-centric scheduler, which balances maximizing overall effective throughput while meeting latency-related Service Level Objectives (SLOs). Unlike traditional studies that assume all requests will be processed, Mooncake faces challenges due to highly overloaded scenarios. To mitigate these, we developed a prediction-based early rejection policy. Experiments show that Mooncake excels in long-context scenarios. Compared to the baseline method, Mooncake can achieve up to a 525% increase in throughput in certain simulated scenarios while adhering to SLOs. Under real workloads, Mooncake’s innovative architecture enables Kimi to handle 75% more requests.
|
||||
|
||||
## 1 引言（Introduction）
|
||||
|
||||
### 1.1 Motivation of Developing Mooncacke
|
||||
|
||||
With the rapid adoption of large language models (LLMs) in various scenarios [1, 2, 3, 4], the workloads for LLM serving have become significantly diversified. These workloads differ in input/output length, frequency and distribution of arrival, and, most importantly, demand different kinds of Service Level Objectives (SLOs). As a Model as a Service (MaaS) provider, one of the primary goals of Kimi [5] is to solve an optimization problem with multiple complex constraints. The optimization goal is to maximize overall effective throughput, which directly impacts revenue, while the constraints reflect varying levels of SLOs. These SLOs typically involve meeting latency-related requirements, mainly the time to first token (TTFT) and the time between tokens (TBT).
|
||||
|
||||
|
||||
|
||||
Figure 1: Mooncake Architecture.
|
||||
|
||||
To achieve this goal, a prerequisite is to make the best use of the various kinds of resources available in the GPU cluster.
|
||||
Specifically, although GPU servers are currently provided as highly integrated nodes (e.g., DGX/HGX supercomputers [6]), it is necessary to decouple and restructure them into several disaggregated resource pools, each optimized for different but collaborative goals. For example, many researchers [7, 8, 9] have suggested separating prefill servers from decoding servers because these two stages of LLM serving have very different computational characteristics, in which the KVCache shifts with requests moving from prefill to decoding servers.
|
||||
|
||||
Building on this idea, we found that the scheduling of KVCache is central to LLM serving scheduling. To improve overall throughput, there are typically two general approaches: 1) reuse KVCache as much as possible to reduce the required computation resources; and 2) maximize the number of tokens in each batch to improve the Model FLOPs Utilization (MFU). However, reusing KVCache from a remote location will prolong the TTFT, and a large batch size will lead to a larger TBT. Thus, the utilization of both these throughput-oriented optimizations may lead to violations of latency-related SLOs.
|
||||
|
||||
According to the above guidelines, we propose a disaggregated design that is centered around KVCache for scheduling and optimization. Figure 1 presents our current KVCache-centric disaggregated architecture for LLM serving, named Mooncake. For each request, the global scheduler (Conductor) needs to select a pair of prefill and decoding instances and schedule the request in the following steps: 1) transfer as much reusable KVCache as possible to the selected prefill instance; 2) complete the prefill stage in chunks/layers and continuously stream the output KVCache to the corresponding decoding instance; 3) load the KVCache and add the request to the continuous batching process at the decoding instance for generating request outputs.
|
||||
|
||||
Although this process seems straightforward, the selection policy is complex due to many restrictions. In the prefill stage, the main objective is to reuse the KVCache as much as possible to avoid redundant computation. However, waiting for KVCache stored on lower-tier storage may violate the TTFT SLO. Additionally, high demand on the KVCache server can lead to network congestion, prolonging the waiting time.
|
||||
Thus Conductor is also responsible for predicting the future usage of KVCache blocks and executing scheduling operations such as swapping and replication accordingly.
|
||||
The hottest blocks should be replicated to multiple nodes to avoid fetching congestion, while the coldest ones should be swapped out to reduce reserving costs.
|
||||
Prefill scheduling is also constrained by the availability of DRAM space in the prefill node, especially when much of the memory is reserved for the global KVCache pool.
|
||||
|
||||
In contrast, the decoding stage has different optimization goals and constraints. The aim is to aggregate as many tokens as possible in a decoding batch to improve MFU.
|
||||
However, this objective is restricted not only by the TBT SLO but also by the total size of the aggregated KVCache that can be contained in the VRAM.
|
||||
|
||||
More importantly, existing research on LLM serving assumes sufficient resources and focuses on improving resource utilization. In contrast, the current GPU/accelerator supply is limited, and many MaaS providers face severe overload problems, especially during peak times. Scheduling in such scenarios presents unique challenges that existing works have not explored. For example, we need to predict future loads and reject certain requests early if there will be no available decoding slots after the prefill stage, to save wasted computation resources.
|
||||
However, a straightforward implementation of such an early reject policy surprisingly leads to fluctuations in the overloads. This has led us to aim at predicting the generation length of specific queries and making overall load predictions in the short-term future to implement a better rejection policy. It is also necessary to classify different request priorities to implement priority-based scheduling.
|
||||
In this paper, we summarize these problems as overload-oriented scheduling and present our preliminary study results.
|
||||
|
||||
### 1.2 Design and Results of Mooncacke
|
||||
|
||||
In the following sections of this paper, we first present an overview of Mooncake’s architecture, including its main components and the typical workflow for processing a request (§3). Then, we describe the main design choices made during its implementation, especially those not covered in current research.
|
||||
|
||||
First, in §5, we discuss how to implement a separate prefill node pool that seamlessly handles the dynamic distribution of context length. We employ a chunked pipeline parallelism (CPP) mechanism to scale the processing of a single request across multiple nodes, which is necessary for reducing the TTFT of long-context inputs. Compared to traditional sequence parallelism (SP) based solutions, CPP reduces network consumption and simplifies the reliance on frequent elastic scaling. This mechanism is further supplemented with layer-wise prefill that enables stream transferring of KVCache to overlap latency.
|
||||
|
||||
Next, in §6, we detail our KVCache-centric request scheduling algorithm, which balances instance loads and user experience as measured by TTFT and TBT SLOs. This includes a heuristic-based automated hot-spot migration scheme that replicates hot KVCache blocks without requiring precise predictions of future KVCache usage. Experimental results show that our cache-aware scheduling can significantly lower TTFT in real-world scenarios. In end-to-end experiments using public datasets, simulated data, and real workloads, Mooncake excels in long-context scenarios. Compared to the baseline method, Mooncake can achieve up to a 525% increase in throughput while meeting SLOs. Under real workloads, Mooncake enables Kimi to handle 75% more requests.
|
||||
|
||||
Finally, unlike existing work on LLM serving that assumes all requests will be processed, Mooncake consistently faces overload due to Kimi’s rapid growth in user requests. Thus, Mooncake’s scheduling involves determining whether to accept or reject incoming requests based on the system load. In §7, we discuss our implementation of a unique early rejection policy that reduces wasted computational resources in overloaded scenarios. We further explore the load fluctuation problem caused by straightforward early rejection and how predicting future load can mitigate this issue.
|
||||
|
||||
Mooncake is currently the primary platform for serving Kimi and has successfully handled exponential workload growth, proving its effectiveness in scaling out to large and highly overloaded workloads. However, many more problems need to be explored, and these future directions are also included in the paper.
|
||||
|
||||
To protect proprietary information and facilitate reproducibility, all the experimental results reported in this paper are based on replayed traces of real workloads, but using a dummy model that follows the same architecture as LLaMA2-70B. The trace includes only the timing of request arrivals, the number of input tokens, and the number of output tokens, the remaped block hash, without any real user content. The trace is open-sourced at https://github.com/kvcache-ai/Mooncake.
|
||||
|
||||
## 2 Preliminary and Problem Definition
|
||||
|
||||
Modern large language models (LLMs) are based on the Transformer architecture, which utilizes attention mechanisms and multilayer perceptrons (MLPs) to process input. Popular Transformer-based models, such as GPT [10] and LLaMA [11], employ a decoder-only structure. Each inference request is logically divided into two stages: the prefill stage and the decoding stage.
|
||||
|
||||
|
||||
|
||||
Figure 2: Normalized throughput and latency of prefill and decoding stages with different sequence lengths or batch sizes for the dummy
|
||||
LLaMA2-70B model.
|
||||
|
||||
In the prefill stage, all input tokens are processed in parallel. This stage generates the first output token while storing intermediate results of computed keys and values, referred to as the KVCache. The decoding stage then uses this KVCache to autoregressively generate new tokens, adding new keys and values from the computation to the KVCache. The ability to process input tokens simultaneously in the prefill stage typically makes it computationally intensive, except for short requests. Since the computational complexity of attention networks scales quadratically with input length while the complexity of MLP scales linearly, computation time in the prefill stage generally increases superlinearly with input length, as shown in the left part of Figure 2.
|
||||
|
||||
In contrast, the decoding stage processes only one token at a time per batch due to the limitation of autoregressive generation. This makes it memory-constrained and causes computation time to increase sublinearly with batch size, as shown in the right part of Figure 2. A widely used optimization in the decoding stage is continuous batching [12, 13]. Before each iteration, the scheduler checks the status of all requests, adding newly arrived requests to the batch’s prefill stage while
|
||||
|
||||
ng contexts, bringing no significant overhead for short context prefill and avoiding frequent dynamic adjustment of node partitioning.
|
||||
This pipeline-based acceleration method has been explored in training systems [24], but to our knowledge, this is the first application in the inference stage, as long context inference has only recently emerged.
|
||||
|
||||
### 5.2 Layer-wise Prefill
|
||||
|
||||
Beyond computational power, the limited size of VRAM is also a precious resource, and we aim to minimize the VRAM occupation by states, primarily the KVCache.
|
||||
Theoretically, if the KVCache size of a request is SS and the processing time is TT, its occupation cost is S∗TS*T.
|
||||
If a request is chunked and the processing of each chunk is inlined with other decoding requests in chunked prefill, TT will increase, leading to a larger occupation cost.
|
||||
|
||||
|
||||
|
||||
Figure 7: Latency of storing KVCache of different request lengths (Layer-wise latency refers to the difference in latency between Layer-wise Prefill and Prefill without storing KVCache).
|
||||
|
||||
Moreover, since prefill is processed layer-by-layer and is computation-bound, it is possible to overlap the transferring and dumping of KVCache with computation, further reducing its occupation cost.
|
||||
In Mooncake, KVCache loading and storing are executed asynchronously via launch and wait operations. Before each layer’s attention computation begins, the model waits for the asynchronous loading of that layer’s KVCache to complete and triggers the next layer’s asynchronous KVCache loading. After the attention calculation is complete, asynchronous storage of that layer’s KVCache is launched. Once all layers’ computations are finished, the process waits for the completion of all asynchronous storage operations. Transfer overlapping allows the prefill instance’s execution time to be roughly equivalent to either the KVCache loading time or the standard prefilling time, depending on the prefix cache proportion relative to the input length. The experimental result of KVCache storing latency, as shown in Figure 7, demonstrates that the layer-wise prefill can effectively reduce the latency for long-context requests.
|
||||
|
||||
The main advantage of this overlap effectiveness is that it enables us to disregard the available VRAM size in prefill scheduling, as long as it can contain a single request.
|
||||
As shown in Figure 1, the scheduling of prefill nodes only considers the KVCache distribution and the available DRAM size.
|
||||
|
||||
In the future, we intend to explore more uses for this free VRAM. For example, OpenAI recently proposed the use of batch APIs [25], which enable users to send asynchronous groups of requests at 50% lower costs, but with only a clear 24-hour turnaround time. This service is ideal for processing jobs that do not require immediate responses. Since there is no stringent TBT for these batch requests, we can inline even the decoding stage of these requests into prefill processing for better MFU, if there is enough VRAM space to hold the corresponding KVCache.
|
||||
|
||||
## 6 以 KV Cache 为中心的调度
|
||||
|
||||
In this section, we mainly discuss how Conductor schedules the requests and KVCache blocks under normal conditions, leaving the discussion on overload scenarios for the next section.
|
||||
|
||||
Algorithm 1 KVCache-centric Scheduling Algorithm
|
||||
|
||||
1:prefill instance pool PP, decoding instance pool DD, request RR, cache block size BB.
|
||||
|
||||
2:the prefill and decoding instances (p,d)(p,d) to process RR.
|
||||
|
||||
3:𝑏𝑙𝑜𝑐𝑘_𝑘𝑒𝑦𝑠←PrefixHash(R.𝑝𝑟𝑜𝑚𝑝𝑡_𝑡𝑜𝑘𝑒𝑛𝑠,B){block\_keys}{PrefixHash}(R.{prompt\_tokens},B)
|
||||
|
||||
4:𝑇𝑇𝐹𝑇←inf{TTFT}
|
||||
|
||||
5:p←∅p
|
||||
|
||||
6:𝑏𝑒𝑠𝑡_𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛,𝑏𝑒𝑠𝑡_𝑚𝑎𝑡𝑐ℎ𝑒𝑑_𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒←FindBestPrefixMatch(P,𝑏𝑙𝑜𝑐𝑘_𝑘𝑒𝑦𝑠){best\_prefix\_len},{best\_matched\_instance}{FindBestPrefixMatch}(P,{block\_keys})
|
||||
|
||||
7:for 𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒∈P{instance} P do
|
||||
|
||||
8: 𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛←𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒.𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛{prefix\_len}{instance.prefix\_len}
|
||||
|
||||
9: T𝑞𝑢𝑒𝑢𝑒←EstimatePrefillQueueTime(𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒){T_{queue}}{EstimatePrefillQueueTime}({instance})
|
||||
|
||||
10: if 𝑏𝑒𝑠𝑡_𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛<𝐤𝐯𝐜𝐚𝐜𝐡𝐞_𝐛𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠_𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝{{best\_prefix\_len}}{{prefix\_len}}<{ kvcache\_balancing\_threshold} then
|
||||
⊳ Cache-aware prefill scheduling
|
||||
|
||||
11: T𝑝𝑟𝑒𝑓𝑖𝑙𝑙←EstimatePrefillExecutionTime(len(R.𝑝𝑟𝑜𝑚𝑝𝑡_𝑡𝑜𝑘𝑒𝑛𝑠),𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛){T_{prefill}}{EstimatePrefillExecutionTime}({len}(R.{prompt\_tokens}),{prefix\_len})
|
||||
|
||||
12: if 𝑇𝑇𝐹𝑇>T𝑞𝑢𝑒𝑢𝑒+T𝑝𝑟𝑒𝑓𝑖𝑙𝑙{TTFT}>{T_{queue}}+{T_{prefill}} then
|
||||
|
||||
13: 𝑇𝑇𝐹𝑇←T𝑞𝑢𝑒𝑢𝑒+T𝑝𝑟𝑒𝑓𝑖𝑙𝑙{TTFT}{T_{queue}}+{T_{prefill}}
|
||||
|
||||
14: p←𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒p{instance}
|
||||
|
||||
15: end if
|
||||
|
||||
16: else⊳ Cache-aware and -balancing prefill scheduling
|
||||
|
||||
17: 𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟_𝑙𝑒𝑛←𝑏𝑒𝑠𝑡_𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛−𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛{transfer\_len}{best\_prefix\_len}-{prefix\_len}
|
||||
|
||||
18: T𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟←EstimateKVCacheTransferTime(𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒,𝑏𝑒𝑠𝑡_𝑚𝑎𝑡𝑐ℎ𝑒𝑑_𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒,𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟_𝑙𝑒𝑛){T_{transfer}}{EstimateKVCacheTransferTime}({instance},{best\_matched\_instance},{transfer\_len})
|
||||
|
||||
19: T𝑝𝑟𝑒𝑓𝑖𝑙𝑙←EstimatePrefillExecutionTime(len(R.𝑝𝑟𝑜𝑚𝑝𝑡_𝑡𝑜𝑘𝑒𝑛𝑠),𝑏𝑒𝑠𝑡_𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛){T_{prefill}}{EstimatePrefillExecutionTime}({len}(R.{prompt\_tokens}),{best\_prefix\_len})
|
||||
|
||||
20: if 𝑇𝑇𝐹𝑇>T𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟+T𝑞𝑢𝑒𝑢𝑒+T𝑝𝑟𝑒𝑓𝑖𝑙𝑙{TTFT}>{T_{transfer}}+{T_{queue}}+{T_{prefill}} then
|
||||
|
||||
21: 𝑇𝑇𝐹𝑇←T𝑡𝑟𝑎𝑛𝑠𝑓𝑒𝑟+T𝑞𝑢𝑒𝑢𝑒+T𝑝𝑟𝑒𝑓𝑖𝑙𝑙{TTFT}{T_{transfer}}+{T_{queue}}+{T_{prefill}}
|
||||
|
||||
22: p←𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒p{instance}
|
||||
|
||||
23: end if
|
||||
|
||||
24: end if
|
||||
|
||||
25:end for
|
||||
|
||||
26:d,𝑇𝐵𝑇←SelectDecodingInstance(D)d,{TBT}{SelectDecodingInstance}(D)
|
||||
⊳ Load-balancing decoding scheduling
|
||||
|
||||
27:if 𝑇𝑇𝐹𝑇>𝑇𝑇𝐹𝑇_𝑆𝐿𝑂{TTFT}>{TTFT\_SLO} or 𝑇𝐵𝑇>𝑇𝐵𝑇_𝑆𝐿𝑂{TBT}>{TBT\_SLO} then
|
||||
|
||||
28: reject RR; return
|
||||
|
||||
29:end if
|
||||
|
||||
30:if 𝑏𝑒𝑠𝑡_𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛p.𝑝𝑟𝑒𝑓𝑖𝑥_𝑙𝑒𝑛>𝐤𝐯𝐜𝐚𝐜𝐡𝐞_𝐛𝐚𝐥𝐚𝐧𝐜𝐢𝐧𝐠_𝐭𝐡𝐫𝐞𝐬𝐡𝐨𝐥𝐝{{best\_prefix\_len}}{p.{prefix\_len}}>{ kvcache\_balancing\_threshold} then
|
||||
|
||||
31: TransferKVCache(𝑏𝑒𝑠𝑡_𝑚𝑎𝑡𝑐ℎ𝑒𝑑_𝑖𝑛𝑠𝑡𝑎𝑛𝑐𝑒,p){TransferKVCache}({best\_matched\_instance},p)
|
||||
⊳ KVCache hot-spot migration
|
||||
|
||||
32:end if
|
||||
|
||||
33:return (p,d)(p,d)
|
||||
|
||||
### 6.1 Prefill Global Scheduling
|
||||
|
||||
Previous research on LLM servi
|
||||
|
||||
ng typically uses a load-balancing strategy that evaluates the load on each instance based on the number of assigned requests. In Mooncake, however, the selection of prefill instances considers additional factors—not just load but also the prefix cache hit length and the distribution of reusable KVCache blocks. While there is a preference to route requests to prefill instances with longer prefix cache lengths to reduce computation costs, it may be beneficial to schedule them to other nodes to ensure overall system balance and meet TTFT SLOs. To address these complexities, we propose a cache-aware global scheduling algorithm that accounts for both the prefill time due to the prefix cache and the queuing time associated with the load on the instance.
|
||||
|
||||
Algorithm 1 details the mechanism for our cache-aware prefill scheduling. For every new request, its input tokens are divided into several blocks, and a hash key is computed for each block. This involves generating a hash key of tokens in a block concatenated with the hash key of the previous block (if available). The request’s block keys are then compared one by one against each prefill instance’s cache keys to identify the prefix match length (prefix_lenprefix\_len). Similar reuse logic is already implemented in vLLM, but the open-source version of vLLM only supports local KVCache caching.
|
||||
|
||||
With this matching information, Conductor estimates the corresponding execution time based on the request length and prefix_lenprefix\_len (which varies by instance). It then adds the estimated waiting time for that request to get the TTFT on that instance. Finally, Conductor assigns the request to the instance with the shortest TTFT and updates the cache and queue times for that instance accordingly. If the SLO is not achievable, Conductor directly returns the HTTP 429 Too Many Requests response status code to the upper layers.
|
||||
|
||||
The backbone of this scheduling framework is straightforward, but complexities are hidden in the engineering implementation of various components. For example, to predict the computation time of the prefill stage for a request, we employ a predictive model derived from offline test data. This model estimates the prefill duration based on the request’s length and prefix cache hit length. Thanks to the regular computation pattern of Transformers, the error bound of this prediction is small as long as enough offline data is available. The queuing time for a request is calculated by aggregating the prefill times of all queued requests. In practical implementations, TTFTs are computed in parallel, rendering the processing time negligible compared to the inference time.
|
||||
|
||||
More difficulty lies in predicting the transfer time because it is determined not only by the size of the transferred data but also by the current network status, especially whether the sending node is under congestion. This also necessitates the replication of hot KVCache blocks, which will be discussed in the next section.
|
||||
|
||||
### 6.2 Cache Load Balancing
|
||||
|
||||
In our Mooncake cluster, each prefill machine manages its own set of local prefix caches. The usage frequency of these caches varies significantly. For example, system prompts are accessed by almost every request, whereas caches storing content from a local long document may be used by only one user. As discussed in §6.1, Conductor’s role is crucial in achieving an optimal balance between cache matching and instance load. Thus, from the perspective of the distributed cache system, load balancing also plays an important role. Specifically, it involves strategizing on how to back up caches to ensure that global prefill scheduling can achieve both high cache hits and low load.
|
||||
|
||||
A straw-man solution to this KVCache scheduling problem could be collecting the global usages of each block, using a prediction model to forecast their future usages, and making scheduling decisions accordingly. However, unlike the estimation of prefill time, workloads are highly dynamic and change significantly over time. Especially for a MaaS provider experiencing rapid growth in its user base, it is impossible to accurately predict future usage. Thus, we propose a heuristic-based automated hot-spot migration scheme to enhance cache load balancing.
|
||||
|
||||
|
||||
|
||||
Figure 8: The prefill scheduling experiment in the Mooncake cluster.
|
||||
|
||||
As previously noted, requests may not always be directed to the prefill instance with the longest prefix cache length due to high instance load. In such cases, the conductor forwards the cache’s location and the request to an alternative instance if the estimated additional prefill time is shorter than the transfer time. This instance proactively retrieves the KVCache from the holder and stores it locally. More importantly, we prefer to compute the input tokens if the best remote prefix match length is no larger than the current local reusable prefix multiplied by a threshold111This threshold is currently adjusted manually, but can be adaptively adjusted by an algorithm in the future. Both strategies not only reduce the prefill time for requests but also facilitate the automatic replication of hot-spot caches, allowing for their broader distribution across multiple machines.
|
||||
|
||||
To validate the effectiveness of our strategy, we conducted a scheduling experiment that compares random scheduling and load-balancing scheduling with our strategy. We further compare the cache-aware scheduling described in §6.1 and the KVCache-centric scheduling described in this section that considers cache load balancing. In random scheduling, a prefill instance is selected arbitrarily for each request. In load-balancing scheduling, the instance with the lightest load is chosen. To evaluate, we built a Mooncake cluster consisting of 8 prefill instances and 8 decoding instances, using idle machines overnight, and replayed 23,000 real-world requests for the experiment. We assessed the performance of each scheduling algorithm using the average TTFT and the TTFT SLO attainment rate. The experimental results, depicted in Figure 8, demonstrate that both the cache-aware strategy and the cache load balancing strategy significantly reduce the TTFT of requests. Our KVCache-centric scheduling algorithm outperforms both random and load-balancing scheduling across both metrics. More experiment results can be found in §8.
|
||||
|
||||
## 7 面向过载的调度
|
||||
|
||||
Most existing work on LLM serving assumes that all requests will be processed, optimizing the throughput or the TTFT and TBT of requests accordingly. However, in real scenarios, processing every incoming request is neither economical nor realistic. For commercial inference services facing rapidly increasing volumes of user requests, the growth rate of the cluster’s inference resources is far slower than the increase in incoming requests. As a result, overload is a common issue in current LLM serving, especially during peak times.
|
||||
|
||||
To balance costs and user experience, the system should process as many requests as possible until the system load reaches a predefined threshold. After this point, remaining requests will be either directly rejected or deferred for later retry. Mooncake, implemented as a disaggregated inference system, allows for more flexible scheduling strategies but also confronts unique scheduling challenges not present in non-disaggregated systems and not mentioned in previous works[7, 8, 9].
|
||||
|
||||
In this section, we describe an early rejection policy designed specifically for a disaggregated architecture and address the load fluctuation caused by this approach. We then explore how predicting the generation length is necessary to mitigate these problems.
|
||||
|
||||
### 7.1 Scheduling in Overload Scenarios
|
||||
|
||||
In scenarios where system overload occurs, scheduling involves determining whether to accept or reject incoming requests based on the system load. A critical aspect of this process is defining what constitutes the “system load”, as this definition influences the threshold at which requests are rejected. In conventional coupled systems, the prediction of TTFT and TBT can be complicated by interference between the prefill and decoding stages. Therefore, the load is often measured simply by the ratio of the number of requests being processed to the system’s maximum capacity.
|
||||
|
||||
In contrast, Mooncake, with its disaggregated architecture, processes the prefill and decoding stages independently. Thus we use SLO satisfaction as a direct load measurement. Specifically, we define lttftl_{ttft} and ltbtl_{tbt} as the TTFT and TBT SLO constraints for requests, respectively. The load for prefill and decoding instances is then determined by comparing the predicted maximum TTFT and TBT on an instance against lttftl_{ttft} and ltbtl_{tbt}. With these two criteria, Mooncake’s scheduling requires two key decisions: first, whether to accept the prefill stage based on the prefill instance’s load, and second, whether to proceed with the decoding stage depending on the decoding instance’s load.
|
||||
|
||||
### 7.2 Early Rejection
|
||||
|
||||
In practice, the individual load on prefill or decoding instances does not accurately reflect the actual number of requests processed by the system. This discrepancy arises due to a time lag between scheduling prefill and decoding instances for a single request. If a request is rejected by the decoding instance due to high load after the prefill stage has been completed, the computational resources expended during the prefill stage are wasted. Consequently, the actual number of successfully processed requests during prefill is less than that indicated by the load metric.
|
||||
|
||||
To address this issue, it is natural to advance the load assessment of the decoding instance to precede the beginning of the prefill stage. We refer to this strategy as Early Rejection. Upon the arrival of a request, Conductor evaluates whether to accept the request based on the greater load between the prefill and decoding pools. Early Rejection significantly reduces ineffective computations from rejected requests and enhances load balancing.
|
||||
|
||||
|
||||
|
||||
Figure 9: The load of prefill and decoding instances over 20 minutes, before using the prediction-based early rejection.
|
||||
|
||||
### 7.3 Load Fluctuation Caused by Early Rejection
|
||||
|
||||
However, Early Rejection introduces new challenges. Figure 9 shows the observed real-world instance load over a 20-minute period in a cluster of 20 machines after using the Early Rejection strategy. It highlights significant anti-phase fluctuations between prefill and decoding machines. This phenomenon becomes more pronounced in clusters with fewer prefill machines and in scenarios where the prefill stage takes longer.
|
||||
|
||||
Upon further exploration, we found that this load fluctuation problem is rooted in the time lag between predicting the decoding load and its actual execution. Scheduling based on the current decoding load is inherently delayed. This delay causes fluctuations and phase staggering between the loads on prefill and decoding instances, as illustrated in the theoretical example described in Figure 10(a). The green curve represents the load of prefill instances (scaled from 0 to 1), and the yellow curve represents the load of decoding instances.
|
||||
|
||||
|
||||
|
||||
(a) Early Rejection.
|
||||
|
||||
|
||||
|
||||
(b) Early Rejection Based on Prediction.
|
||||
|
||||
Figure 10: Instance load when applying Early Rejection and Early Rejection Based on Prediction.
|
||||
|
||||
In Stage 1, the load on both prefill and decoding instances is low, so Conductor accepts a large number of requests until the load on prefill instances reaches its limit. In Stage 2, requests processed by prefill instances are scheduled to decoding instances, causing the load on decoding instances to be high. Consequently, Conductor rejects incoming requests, leading to a lower load on prefill instances. In Stage 3, no new requests enter the decoding stage, resulting in a decreased load. At this point, Conductor again accepts a large number of requests until the prefill instances are fully loaded. In Stage 4, as the load on decoding instances increases, Conductor rejects requests, causing a low load on prefill instances. This severe fluctuation in load between prefill and decoding instances results in poor resource utilization of the inference cluster.
|
||||
|
||||
### 7.4 Early Rejection Based on Prediction
|
||||
|
||||
To solve the load fluctuation problem, we propose a framework of Early Rejection Based on Prediction to address scheduling challenges in overload scenarios for disaggregated LLM serving systems like Mooncake. As illustrated in Figure 10(b), this framework predicts the decoding load after the prefill stage of incoming requests and uses this prediction to decide whether to accept the requests, which helps mitigate the fluctuation problem. The core component of this strategy is the accurate prediction of the decoding load for the subsequent period. We introduce two approaches for this:
|
||||
|
||||
Request level: Previous work highlights a significant challenge in predicting loads for LLM serving: the unknown output length of each request. If we could determine the output length in advance, it would be possible to estimate the TTFT and TBT much more accurately. This, in turn, would help predict the number of requests a decoding instance can complete and the number of new requests that will be added after a specified time, thereby obtaining the load at that time. However, predicting each request’s output length is challenging due to high costs [9] or low accuracy, especially under overload conditions where resources are scarce and accurate predictions are necessary, making request-level predictions particularly difficult.
|
||||
|
||||
System level: In contrast to request-level predictions, system-level predictions do not attempt to predict the completion time
|
||||
|
||||
e TTFT SLO. However, while approximately 100% of the requests for Mooncake-[10P+10D] satisfy the TBT SLO, only 57% of the requests for vLLM-[20M] meet this criterion, with some requests exhibiting extremely high TBTs. In this experiment, Mooncake can process approximately 75% more requests while adhering to the SLOs.
|
||||
|
||||
### 8.2 Performance in Overload Scenarios
|
||||
|
||||
In this section, we evaluate performance under overload scenarios, focusing on the maximum number of requests the system can handle, as discussed in §7. The baseline strategy, which rejects requests based on load before both stages start, leads to resource wastage by rejecting requests already processed in the prefill stage. In contrast, we propose the Early Rejection and Early Rejection based on Prediction strategies, detailed in §7.2 and §7.4, respectively. These strategies take the system’s load into comprehensive consideration, and hence reduce unnecessary request rejections.
|
||||
|
||||
Specifically, we built a Mooncake cluster with 8 prefill instances and 8 decoding instances and tested it using real traces from 23,000 requests. To simulate overload scenarios, we increased the replay speed to 2x.
|
||||
|
||||
Table 3: Number of requests rejected by the system under the overloaded-scenario experiment.
|
||||
|
||||
Table 3 shows Mooncake’s performance under different strategies. With the baseline strategy, the system rejects 4,183 requests. In contrast, under the Early Rejection and Early Rejection based on Prediction strategies, Mooncake rejects 3,771 and 3,589 requests, respectively. This demonstrates that by rejecting requests early, Mooncake can avoid unnecessary prefill computations, thereby improving the effective utilization of system resources. Furthermore, by predicting the load of decoding instances, Mooncake can mitigate load fluctuations, increasing the request handling capacity.
|
||||
|
||||
## 9 Related Work
|
||||
|
||||
Significant efforts have been dedicated to enhancing the efficiency of LLM serving systems through scheduling, memory management, a
|
||||
@@ -0,0 +1,92 @@
|
||||
# 📊 文章摘要：Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
> **原文**：[2024-06-24_Mooncake.md](./2024-06-24_Mooncake.md)
|
||||
> **原文链接**：https://arxiv.org/abs/2407.00079
|
||||
> **来源**：arXiv
|
||||
> **作者**：Ruoyu Qin, Zheming Li, Weiran He, Mingxing Zhang, Yongwei Wu, Weimin Zheng, Xinran Xu（月之暗面 Moonshot AI、清华大学）
|
||||
> **发布日期**：2024-06-24
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **缓存为中心** — LLM serving 调度的核心不是 GPU 算力而是 KVCache：以缓存复用与分发为中心组织解耦架构，并面向真实过载场景设计预测式早期拒绝，是生产级 MaaS 平台的实践范式。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
Mooncake 是 Kimi 的生产 serving 平台，在 prefill/decoding 集群解耦的基础上，把 GPU 集群中闲置的 CPU、DRAM、SSD 组织成分层 KVCache 池，并以 Conductor 全局调度器为中心做"缓存感知"调度：复用尽可能多的前缀缓存、把热块复制到多节点、冷块换出到低层存储。与主流研究"假设所有请求都会被处理"不同，Mooncake 直面用户爆发式增长带来的过载问题，提出基于预测的早期拒绝策略（Early Rejection Based on Prediction），避免为注定被拒绝的请求浪费 prefill 算力，并缓解简单拒绝策略引起的 prefill/decoding 负载反相波动。模拟场景下相比 baseline 吞吐提升最高 525%（同时满足 SLO），真实负载下让 Kimi 多处理 75% 的请求。局限：实验基于 dummy 模型 + trace 重放，部分阈值靠人工调节，拒绝策略以牺牲低价值请求换取整体效率。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **KVCache 是调度的中心矛盾** — 提升吞吐的两条路径（复用 KVCache 减少计算、增大 batch 提高 MFU）都会伤及延迟 SLO：远程取缓存拖长 TTFT，大 batch 放大 TBT；调度本质是在缓存复用与 SLO 之间做权衡。`[分类: 范式突破]`
|
||||
2. **分层解耦缓存池** — 利用 GPU 集群未充分利用的 CPU/DRAM/SSD 构建 KVCache 的分层存储与分发网络，让冷热块各得其所（热块复制防拥塞、冷块换出降成本）。`[分类: 未探索]`
|
||||
3. **缓存感知的全局调度** — Conductor 按前缀匹配长度、排队时间、传输时间估算各 prefill 实例的 TTFT，选择最优实例；不满足 SLO 时直接返回 HTTP 429。与仅看负载的调度相比，显著降低平均 TTFT。`[分类: 未探索]`
|
||||
4. **启发式热点迁移替代预测** — 工作负载高度动态、无法准确预测未来缓存使用，因此用"请求偏离最优缓存实例时按需迁移/复制缓存"的启发式方案实现热点块的自动复制，而非预测模型。`[分类: 未探索]`
|
||||
5. **长上下文利器：CPP + 逐层 prefill** — Chunked pipeline parallelism 把单个长请求跨节点流水处理（相对 sequence parallelism 降低网络消耗、简化弹性扩缩）；逐层异步加载/存储 KVCache 与计算重叠，使 prefill 实例调度几乎不再受 VRAM 大小约束。`[分类: 范式突破]`
|
||||
6. **面向过载的调度是全新问题域** — 用 SLO 满足度而非请求数/容量比衡量系统负载；把 decode 侧负载评估提前到 prefill 之前（早期拒绝），避免 prefill 算力浪费。`[分类: 范式突破]`
|
||||
7. **预测式早期拒绝抑制负载波动** — 简单早期拒绝会引发 prefill/decode 实例负载反相振荡（20 台机器实测），根因是预测与实际执行的时间差；预测未来 decode 负载可显著平抑波动：过载实验中拒绝请求数从 baseline 的 4183 降到 3771（早期拒绝）与 3589（预测式早期拒绝）。`[分类: 未探索]`
|
||||
8. **生产验证与信息保护的平衡** — 全部实验基于重放真实 trace（仅含到达时间、输入/输出 token 数、块哈希，不含用户内容）+ 与 LLaMA2-70B 同架构的 dummy 模型，兼顾可复现与商业机密保护。`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 大规模 MaaS 提供商的 GPU 集群长期处于过载状态，且资源增长速度远慢于请求增长——拒绝部分请求是合理且必要的商业决策。
|
||||
- 前缀缓存命中是长上下文负载中的常见现象，值得为缓存复用投入全局协调开销。
|
||||
- 集群中存在大量闲置 CPU/DRAM/SSD 资源可供缓存池使用，且 GPU 服务器的集成形态可以重构为解耦资源池。
|
||||
- Transformer 计算模式规则，prefill 执行时间可通过离线数据建模准确预测。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 论据结构合理：先以 23000 条真实请求在 8+8 实例集群上对比随机/负载均衡/缓存感知/缓存均衡四种调度，证明 KVCache-centric 调度全面占优；再以 20 台机器 20 分钟负载曲线揭示反相波动现象，并给出理论示例与预测方案的改进数据。
|
||||
- 525% 吞吐提升与 75% 请求承载提升均有明确实验来源（模拟场景与真实负载），且文中明确区分两者语境，未混淆。
|
||||
- 弱点：dummy 模型无法完全代表真实模型的 KV cache 分布与内存行为；"up to"表述下的最大提升场景条件不明；阈值（如 kvcache_balancing_threshold）依赖人工调整，可复现性打折。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 结论面向"高过载 + 长上下文"的 MaaS 生产场景；负载未饱和、前缀命中率低的场景下，全局缓存协调的收益可能被协调开销抵消。
|
||||
- 拒绝策略会牺牲尾部用户的请求质量（以 429 拒绝），对用户体感与商业口碑的影响论文未量化。
|
||||
- 早期拒绝依赖输出长度预测，而过载条件下请求级长度预测本身困难（论文承认成本高、精度低），系统级预测是妥协方案。
|
||||
- 实验保护商业信息的手段（dummy 模型 + trace 重放）本身限制了结果的真实性边界。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Unlike traditional studies that assume all requests will be processed, Mooncake faces challenges due to highly overloaded scenarios."
|
||||
> （与传统研究假设所有请求都会被处理不同，Mooncake 面对的是严重过载场景的挑战。）
|
||||
|
||||
> "We found that the scheduling of KVCache is central to LLM serving scheduling."
|
||||
> （我们发现 KVCache 的调度是 LLM serving 调度的核心所在。）
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 首个公开的、经受真实爆发式增长验证的"缓存为中心"解耦 serving 架构，工业界一手的工程视角稀缺
|
||||
- 把"过载调度"引入 LLM serving 问题域，早期拒绝与负载波动分析（反相振荡的根因剖析）极具启发性
|
||||
- 缓存感知调度 + 热点迁移 + 逐层 prefill 的组合拳，直接服务长上下文这一当前关键场景
|
||||
|
||||
**不足**：
|
||||
- 实验体系（dummy 模型、trace 重放、人工阈值）的科学严格性弱于学术性较强的对照工作
|
||||
- 关键阈值与工程细节披露有限，可复现性受限
|
||||
- 拒绝策略对用户体感、商业指标的长期影响未讨论
|
||||
|
||||
**适用场景**：LLM serving 系统设计者、MaaS 平台（Kimi 类长上下文助手）基础设施团队；研究过载调度与缓存管理的研究人员。
|
||||
|
||||
**关联建议**：与 DistServe（解耦的 goodput 优化理论框架）、Splitwise（异构硬件部署）、TetriInfer（长度预测调度）对照阅读，可拼出解耦 serving 的全景；后续可关注 Mooncake 开源仓库（github.com/kvcache-ai/Mooncake）的演进与 vLLM 社区对前缀缓存调度的采纳。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,237 @@
|
||||
# DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
|
||||
|
||||
> **来源**：arXiv
|
||||
> **作者**：Yinmin Zhong, Shengyu Liu, Junda Chen, Jianbo Hu, Yibo Zhu, Xuanzhe Liu, Xin Jin, Hao Zhang
|
||||
> **发布日期**：2024-01-18
|
||||
> **原文链接**：https://arxiv.org/abs/2401.09670
|
||||
|
||||
---
|
||||
|
||||
## 论文元数据
|
||||
|
||||
- **arXiv ID**：2401.09670
|
||||
- **学科分类**：Distributed, Parallel, and Cluster Computing (cs.DC); Artificial Intelligence (cs.AI)
|
||||
- **作者机构**：北京大学（School of Computer Science, Peking University）、StepFun、UC San Diego
|
||||
- **提交历史**：v1: 2024-01-18；v2: 2024-03-19；v3: 2024-06-06
|
||||
- **DOI**：https://doi.org/10.48550/arXiv.2401.09670
|
||||
|
||||
---
|
||||
|
||||
Yinmin Zhong Shengyu Liu Junda Chen Jianbo Hu Yibo Zhu Xuanzhe Liu
|
||||
|
||||
Xin Jin Hao Zhang
|
||||
|
||||
School of Computer Science, Peking University StepFun UC San Diego
|
||||
|
||||
## 摘要（Abstract）
|
||||
|
||||
DistServe improves the performance of large language models (LLMs) serving by disaggregating the prefill and decoding computation. Existing LLM serving systems colocate the two phases and batch the computation of prefill and decoding across all users and requests.
|
||||
We find that this strategy not only leads to strong prefill-decoding interferences but also couples the resource allocation and parallelism plans for both phases. LLM applications often emphasize individual latency for each phase: time to first token (TTFT) for the prefill phase and time per output token (TPOT) of each request for the decoding phase.
|
||||
In the presence of stringent latency requirements, existing systems have to prioritize one latency over the other, or over-provision compute resources to meet both.
|
||||
|
||||
DistServe assigns prefill and decoding computation to different GPUs, hence eliminating prefill-decoding interferences. Given the application’s TTFT and TPOT requirements, DistServe co-optimizes the resource allocation and parallelism strategy _tailored_ for each phase. DistServe also places the two phases according to the serving cluster’s bandwidth to minimize the communication caused by disaggregation. As a result, DistServe significantly improves LLM serving performance in terms of the maximum rate that can be served within both TTFT and TPOT constraints on each GPU.
|
||||
Our evaluations show that on various popular LLMs, applications, and latency requirements, DistServe can serve 7.4× more requests or 12.6× tighter SLO, compared to state-of-the-art systems, while staying within latency constraints for >90%90>90\%> 90 % of requests.
|
||||
|
||||
## 1 引言（Introduction）
|
||||
|
||||
Large language models (LLMs), such as GPT-4 [37], Bard [2], and LLaMA [51], represent a groundbreaking shift in generative AI. They start to reshape existing Internet services, ranging from search engines to personal assistants [4], and enable fundamentally new applications, like universal chatbots [1, 16] and programming assistants [15, 42]. Yet, these advances come with a significant challenge: processing an end-to-end LLM query can be substantially slower than a standard search query [41]. In order to meet the stringent latency requirements of various applications, service providers need to over-provision compute resources, particularly many GPUs, leading to a shortfall in cost efficiency. Therefore, optimizing the cost per LLM query while adhering to high SLO attainment (the proportion of requests that meet the SLOs) is becoming increasingly essential for all LLM services.
|
||||
|
||||
|
||||
|
||||
Figure 1:
|
||||
Performance when serving an LLM with 13B parameters under a synthetic workload with input length = 512 and output length = 64 on one NVIDIA 80GB A100. Upper: The P90 time-to-first-token (TTFT) latency comparing existing systems vs. a system serving only the prefill phase. Down: The P90 time-per-output-token (TPOT) latency comparing existing systems vs. a system serving only the decoding phase.
|
||||
|
||||
An LLM service responds to a user query in two phases. The _prefill phase_ processes a user’s prompt, composed of a sequence of tokens, to generate the first token of the response _in one step_. Following it, the _decoding phase_ sequentially generates subsequent tokens _in multiple steps_; each decoding step generates a new token based on tokens generated in previous steps, until reaching a termination token.
|
||||
This dual-phase process distinguishes LLM services from traditional services
|
||||
– an LLM service’s latency is uniquely measured by two key metrics: the _time to first token_ (TTFT), which is the duration of the prefill phase, and the _time per output token_ (TPOT), which represents the average time taken to generate a token for each request (except for the first token)111The overall request latency equals TTFT plus TPOT times the number of generated tokens in the decoding phase..
|
||||
Different applications place varying demands on each metric. For example, real-time chatbots [1] prioritize low TTFT for response promptness, while TPOT only remains important until it is faster than human reading speed (i.e., 250 words/min).
|
||||
Conversely, document summarization emphasizes low TPOT for faster generation of the summary.
|
||||
|
||||
Hence, given the application’s TTFT and TPOT requirements, an effective LLM serving system should balance these needs and maximize _per-GPU goodput_, defined as the maximum request rate that can be served adhering to the SLO attainment goal (say, 90%) for each GPU provisioned – higher per-GPU goodput directly translates into lower cost per query.
|
||||
|
||||
As the prefill and decoding phases share the LLM weights and working memory,
|
||||
existing LLM serving systems typically colocate both phases on GPUs and maximize the overall system throughput – tokens generated per second across all users and requests – by batching the prefill and decoding steps across requests [54, 31]. However, to meet latency requirements, we find these systems must over-provision compute resources. To see this, Figure 1 illustrates how the P90 TTFT and TPOT shift with increasing request rates when serving a 13B LLM using existing systems [32], with workload pattern and two latency constraints set to emulate using LLM to generate a short summary for an article. Under the SLO attainment of 90%, the maximum achievable goodput on a single A100 GPU, which is constrained by the more stringent one of TTFT and TPOT requirements, is about 1.6 requests per second (rps).
|
||||
The performance contrasts sharply when each phase is served independently on a separate GPU, shown by the orange and green curves, which achieve per-GPU goodput of 5.6 rps for the prefill phase and 10 rps for decoding. Ideally, by allocating 2 GPUs for prefill and 1 GPU for decoding, we can effectively serve the model with an overall goodput of 10 rps, or equally 3.3 rps per GPU, which is 2.1x higher than existing systems.
|
||||
The gap in goodput primarily stems from the colocation of the prefill and decoding – two phases with very distinct computational characteristics and latency requirements (§2.1).
|
||||
|
||||
First, colocation leads to strong _prefill-decoding interference_.
|
||||
A prefill step often takes much longer than a decoding step. When batched together, decoding steps in the batch are delayed by the prefill steps, significantly elongating their TPOT; similarly, the inclusion of decoding steps contributes to a non-trivial increase in TTFT, as evidenced in Figure 2.
|
||||
Even if we schedule them separately, issues persist as they begin to compete for resources. Decoding tasks awaiting GPU execution are subject to increased queuing delays due to ongoing prefill tasks, and vice versa. Prioritized scheduling of one phase risks failing the latency requirements of the other.
|
||||
|
||||
Second, the prefill and decoding computation differ in latency requirements and preference for different forms of parallelism (§3). Colocating prefill and decoding, however, couples their resource allocation, and prevents implementing different parallelism strategies more suited to meeting the specific latency requirements of each phase.
|
||||
|
||||
To overcome these challenges, we propose to disaggregate the prefill and decoding phases of LLM inference, assigning them to separate GPUs. Our approach has two benefits.
|
||||
First, operating each phase independently on different GPUs eliminates prefill-decoding interference. Second, it allows to scale each phase independently with tailored resource allocation and model parallelism strategies to meet their specific latency requirements.
|
||||
Although disaggregation causes communication of intermediate states between GPUs, we show that the communication overhead is insubstantial (§3.3) in modern GPU clusters, and when managed appropriately, disaggregation significantly improves per-GPU goodput.
|
||||
|
||||
Based on the above insights, in this work, we build DistServe 222https://github.com/LLMServe/DistServe, a goodput-optimized LLM serving system by disaggregating the prefill and decoding phases. Given TTFT and TPOT requirements, DistServe first scales each phase independently by co-optimizing the GPU allocation and parallelism strategies of the prefill and decoding phase assuming serving a single model replica. The optimization ensures maximizing the per-GPU goodput and may assign different numbers of GPUs and parallelism strategies to each phase depending on their respective latency requirements. DistServe then scales this allocation to multiple instances via replication until meeting the user-required traffic rate (§4).
|
||||
DistServe also features an algorithm to place the prefill and decoding computation according to their allocation schemes and the cluster’s bandwidth to minimize the overhead of communicating intermediate states between phases.
|
||||
|
||||
We implement DistServe as an orchestration layer on top of the LLM inference engine. We
|
||||
evaluate DistServe on various LLMs, varying the workloads based on three important real-world LLM applications: chatbots, programming assistant, and document summary. Compared to state-of-the-art solutions, DistServe can serve up to 7.4×7.4 × more requests or 12.6×12.6 × tighter SLO under various latency constraints. Our contributions are:
|
||||
|
||||
- •
|
||||
|
||||
Identify the problems of prefill-decoding interference and resource coupling in existing LLM serving systems and propose to disaggregate the two phases.
|
||||
- •
|
||||
|
||||
Design a novel placement algorithm to choose the goodput-optimal schema for prefill and decoding instances automatically.
|
||||
- •
|
||||
|
||||
Conduct a comprehensive evaluation of DistServe with realistic workloads.
|
||||
|
||||
## 4 方法（Method）
|
||||
|
||||
We built DistServe to solve the above challenges. Given the model, workload characteristic, latency requirements, and SLO attainment target, DistServe will determine (a) the parallelism strategies for prefill and decoding instances, (b) the number of each instance type to deploy, as well as (c) how to place them onto the physical cluster. We call the solution a placement. Our goal is to find a placement that maximizes the per-gpu goodput.
|
||||
|
||||
As explained in §3.3, a key design consideration is to manage communications between disaggregated prefill and decoding phases, given varying cluster setups.
|
||||
In this section, we first present two placement algorithms: one for clusters with high-speed cross-node networks (§4.1) and the other for environments lacking such infrastructure (§4.2); the latter introduces additional constraints. We then develop online scheduling optimizations that adapt to the nuances of real-world workloads (§4.3).
|
||||
|
||||
### 4.1 Placement for High Node-Affinity Cluster
|
||||
|
||||
Algorithm 1 High Node-Affinity Placement Algorithm
|
||||
|
||||
LLM G𝐺Gitalic_G, #node limit per-instance N𝑁Nitalic_N, #GPU per-node M𝑀Mitalic_M, GPU memory capacity C𝐶Citalic_C, workload W𝑊Witalic_W, traffic rate R𝑅Ritalic_R.
|
||||
|
||||
the placement 𝑏𝑒𝑠𝑡_𝑝𝑙𝑚.𝑏𝑒𝑠𝑡_𝑝𝑙𝑚{best\_plm}.italic_best _ italic_plm .
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔p,𝑐𝑜𝑛𝑓𝑖𝑔d←∅,∅formulae-sequence←
|
||||
|
||||
subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑝subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑑
|
||||
{config_{p}},{config_{d}},_config start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT , italic_config start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT ← ∅ , ∅
|
||||
|
||||
for 𝑖𝑛𝑡𝑟𝑎_𝑜𝑝∈{1,2,…,M}𝑖𝑛𝑡𝑟𝑎_𝑜𝑝12…𝑀{intra\_op}\{1,2,...,M\}italic_intra _ italic_op ∈ { 1 , 2 , … , italic_M } do
|
||||
|
||||
for 𝑖𝑛𝑡𝑒𝑟_𝑜𝑝∈{1,2,…,N×M𝑖𝑛𝑡𝑟𝑎_𝑜𝑝}𝑖𝑛𝑡𝑒𝑟_𝑜𝑝12…𝑁𝑀𝑖𝑛𝑡𝑟𝑎_𝑜𝑝{inter\_op}\{1,2,...,{N M}{{intra\_op}}\}italic_inter _ italic_op ∈ { 1 , 2 , … , divide start_ARG italic_N × italic_M end_ARG start_ARG italic_intra _ italic_op end_ARG } do
|
||||
|
||||
if G.size𝑖𝑛𝑡𝑒𝑟_𝑜𝑝×𝑖𝑛𝑡𝑟𝑎_𝑜𝑝<Cformulae-sequence𝐺𝑠𝑖𝑧𝑒𝑖𝑛𝑡𝑒𝑟_𝑜𝑝𝑖𝑛𝑡𝑟𝑎_𝑜𝑝𝐶{G.size}{{inter\_op}{intra\_op}}<Cdivide start_ARG italic_G . italic_s italic_i italic_z italic_e end_ARG start_ARG italic_inter _ italic_op × italic_intra _ italic_op end_ARG < italic_C then
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔←(𝑖𝑛𝑡𝑒𝑟_𝑜𝑝,𝑖𝑛𝑡𝑟𝑎_𝑜𝑝)←𝑐𝑜𝑛𝑓𝑖𝑔𝑖𝑛𝑡𝑒𝑟_𝑜𝑝𝑖𝑛𝑡𝑟𝑎_𝑜𝑝{config}({inter\_op},{intra\_op})italic_config ← ( italic_inter _ italic_op , italic_intra _ italic_op )
|
||||
|
||||
G^←parallel(G,𝑐𝑜𝑛𝑓𝑖𝑔)←^𝐺parallel𝐺𝑐𝑜𝑛𝑓𝑖𝑔{G}{parallel}(G,{config})over^ start_ARG italic_G end_ARG ← parallel ( italic_G , italic_config )
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡←simu_prefill(G^,W)formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔←𝑔𝑜𝑜𝑑𝑝𝑢𝑡simu_prefill^𝐺𝑊{config.goodput}{simu\_prefill}({G},W)italic_config . italic_goodput ← simu_prefill ( over^ start_ARG italic_G end_ARG , italic_W )
|
||||
|
||||
if 𝑐𝑜𝑛𝑓𝑖𝑔p.𝑔𝑜𝑜𝑑𝑝𝑢𝑡configp.num_gpus<𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡config.num_gpusformulae-sequencesubscript𝑐𝑜𝑛𝑓𝑖𝑔𝑝𝑔𝑜𝑜𝑑𝑝𝑢𝑡formulae-sequence𝑐𝑜𝑛𝑓𝑖subscript𝑔𝑝𝑛𝑢𝑚_𝑔𝑝𝑢𝑠formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔𝑔𝑜𝑜𝑑𝑝𝑢𝑡formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔𝑛𝑢𝑚_𝑔𝑝𝑢𝑠{{config_{p}.goodput}}{config_{p}.num\_gpus}<{{config.%
|
||||
goodput}}{config.num\_gpus}divide start_ARG italic_config start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT . italic_goodput end_ARG start_ARG italic_c italic_o italic_n italic_f italic_i italic_g start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT . italic_n italic_u italic_m _ italic_g italic_p italic_u italic_s end_ARG < divide start_ARG italic_config . italic_goodput end_ARG start_ARG italic_c italic_o italic_n italic_f italic_i italic_g . italic_n italic_u italic_m _ italic_g italic_p italic_u italic_s end_ARG then
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔p←𝑐𝑜𝑛𝑓𝑖𝑔←subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑝𝑐𝑜𝑛𝑓𝑖𝑔{config_{p}}{config}italic_config start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT ← italic_config
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡←simu_decode(G^,W)formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔←𝑔𝑜𝑜𝑑𝑝𝑢𝑡simu_decode^𝐺𝑊{config.goodput}{simu\_decode}({G},W)italic_config . italic_goodput ← simu_decode ( over^ start_ARG italic_G end_ARG , italic_W )
|
||||
|
||||
if 𝑐𝑜𝑛𝑓𝑖𝑔d.𝑔𝑜𝑜𝑑𝑝𝑢𝑡configd.num_gpus<𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡config.num_gpusformulae-sequencesubscript𝑐𝑜𝑛𝑓𝑖𝑔𝑑𝑔𝑜𝑜𝑑𝑝𝑢𝑡formulae-sequence𝑐𝑜𝑛𝑓𝑖subscript𝑔𝑑𝑛𝑢𝑚_𝑔𝑝𝑢𝑠formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔𝑔𝑜𝑜𝑑𝑝𝑢𝑡formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔𝑛𝑢𝑚_𝑔𝑝𝑢𝑠{{config_{d}.goodput}}{config_{d}.num\_gpus}<{{config.%
|
||||
goodput}}{config.num\_gpus}divide start_ARG italic_config start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT . italic_goodput end_ARG start_ARG italic_c italic_o italic_n italic_f italic_i italic_g start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT . italic_n italic_u italic_m _ italic_g italic_p italic_u italic_s end_ARG < divide start_ARG italic_config . italic_goodput end_ARG start_ARG italic_c italic_o italic_n italic_f italic_i italic_g . italic_n italic_u italic_m _ italic_g italic_p italic_u italic_s end_ARG then
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔d←𝑐𝑜𝑛𝑓𝑖𝑔←subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑑𝑐𝑜𝑛𝑓𝑖𝑔{config_{d}}{config}italic_config start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT ← italic_config
|
||||
|
||||
n,m←⌈R𝑐𝑜𝑛𝑓𝑖𝑔p.𝑔𝑜𝑜𝑑𝑝𝑢𝑡⌉,⌈R𝑐𝑜𝑛𝑓𝑖𝑔d.𝑔𝑜𝑜𝑑𝑝𝑢𝑡⌉formulae-sequence←
|
||||
|
||||
𝑛𝑚
|
||||
𝑅formulae-sequencesubscript𝑐𝑜𝑛𝑓𝑖𝑔𝑝𝑔𝑜𝑜𝑑𝑝𝑢𝑡𝑅formulae-sequencesubscript𝑐𝑜𝑛𝑓𝑖𝑔𝑑𝑔𝑜𝑜𝑑𝑝𝑢𝑡n,m{R}{{config_{p}.goodput}},{R}{%
|
||||
{config_{d}.goodput}}_n , italic_m ← ⌈ divide start_ARG italic_R end_ARG start_ARG italic_config start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT . italic_goodput end_ARG ⌉ , ⌈ divide start_ARG italic_R end_ARG start_ARG italic_config start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT . italic_goodput end_ARG ⌉
|
||||
|
||||
𝑏𝑒𝑠𝑡_𝑝𝑙𝑚←(n,𝑐𝑜𝑛𝑓𝑖𝑔p,m,𝑐𝑜𝑛𝑓𝑖𝑔d)←𝑏𝑒𝑠𝑡_𝑝𝑙𝑚𝑛subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑝𝑚subscript𝑐𝑜𝑛𝑓𝑖𝑔𝑑{best\_plm}(n,{config_{p}},m,{config_{d}})italic_best _ italic_plm ← ( italic_n , italic_config start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT , italic_m , italic_config start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT )
|
||||
|
||||
return 𝑏𝑒𝑠𝑡_𝑝𝑙𝑚𝑏𝑒𝑠𝑡_𝑝𝑙𝑚{best\_plm}italic_best _ italic_plm
|
||||
|
||||
On high node-affinity clusters equipped with Infiniband, KV caches transmission overhead across nodes is negligible, DistServe can deploy prefill and decoding instances across any two nodes without constraints.
|
||||
We propose a two-level placement algorithm for such scenarios: we first optimize the parallelism configurations for prefill and decoding instances separately to attain phase-level optimal per-gpu goodput; then, we use replication to match the overall traffic rate.
|
||||
|
||||
However, finding the optimal parallel configuration for a single instance type, such as for the prefill instance, is still challenging, due to the lack of a simple analytical formula to calculate the SLO attainment (a.k.a., percentage of requests that meet TTFT requirement), given that the workload has diverse input, output lengths, and irregular arrival patterns. Gauging the SLO via real-testbed profiling is time-prohibitive. We thus resort to building a simulator to estimate the SLO attainment, assuming prior knowledge of the workload’s arrival process and input and output length distributions.
|
||||
Although short-term interval is impossible to predict, the workload pattern over longer timescales (e.g.,
|
||||
hours or days) is often predictable [33, 55]. DistServe fits a distribution from the history request traces and resamples new traces from the distribution as the input workload to the simulator to compute the SLO attainment. Next, DistServe simply enumerates the placements and finds the maximum rate that meets the SLO attainment target with binary search and simulation trials.
|
||||
|
||||
Algorithm 1 outlines the process. We enumerate all feasible parallel configurations, subject to cluster capacity limit, for both prefill and decoding instances. Then, for a specific prefill phase configuration, we use `simu_prefill` to simulate and find its maximum goodput via binary search (similarly for using `simu_decode` for decoding).
|
||||
After determining the optimal parallel configurations for both prefill and decoding instances, we replicate them to achieve the user-required overall traffic rate according to their goodput.
|
||||
|
||||
The complexity of Algorithm 1 is O(NM2)𝑂𝑁superscript𝑀2O(NM^{)italic_O ( italic_N italic_M start_POSTSUPERSCRIPT 2 end_POSTSUPERSCRIPT ), with N𝑁Nitalic_N as the node limit per instance and M𝑀Mitalic_M representing the typical number of GPUs per node in modern clusters (e.g., 8). The search space is manageable and the solving time is under 1.3 minutes in our largest setting, as demonstrated in §6.5.
|
||||
|
||||
Simulator building. Algorithm 1 relies on a simulator to estimate the goodput under various SLOs and SLO attainment goals given the workload and the parallelism plan.
|
||||
To build an accurate simulator, we analyze the FLOPs and the number of memory accesses for prefill and decoding phases respectively, and use a latency model to approximate the inference execution time. See details in Appendix A. The simulator aligns well with real profiling results, thanks to the high predictability of DNN workloads [23, 33], verified in §6.4.
|
||||
|
||||
By far, we have developed Algorithm 1 assuming we can place the prefill and decoding instance between any two nodes (or on the same node) of the cluster, and the KV cache transmission utilizes high bandwidth network. In many real clusters, GPUs inside a node access to high-bandwidth NVLINK while GPUs distributed across nodes have limited bandwidth. We next develop an algorithm to address this constraint.
|
||||
|
||||
Algorithm 2 Low Node-Affinity Placement Algorithm
|
||||
|
||||
LLM G𝐺Gitalic_G, #node limit per-instance N𝑁Nitalic_N, #GPU per-node M𝑀Mitalic_M, GPU memory capacity C𝐶Citalic_C, workload W𝑊Witalic_W, traffic rate R𝑅Ritalic_R.
|
||||
|
||||
the placement 𝑏𝑒𝑠𝑡_𝑝𝑙𝑚.𝑏𝑒𝑠𝑡_𝑝𝑙𝑚{best\_plm}.italic_best _ italic_plm .
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔∗←∅←superscript𝑐𝑜𝑛𝑓𝑖𝑔_config start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT ← ∅
|
||||
|
||||
for 𝑖𝑛𝑡𝑒𝑟_𝑜𝑝∈{1,2,…,N}𝑖𝑛𝑡𝑒𝑟_𝑜𝑝12…𝑁{inter\_op}\{1,2,...,N\}italic_inter _ italic_op ∈ { 1 , 2 , … , italic_N } do
|
||||
|
||||
𝒫←get_intra_node_configs(G,M,C,𝑖𝑛𝑡𝑒𝑟_𝑜𝑝)←𝒫get_intra_node_configs𝐺𝑀𝐶𝑖𝑛𝑡𝑒𝑟_𝑜𝑝{P}{get\_intra\_node\_configs}(G,M,C,{inter\_op})caligraphic_P ← get_intra_node_configs ( italic_G , italic_M , italic_C , italic_inter _ italic_op )
|
||||
|
||||
for Pp∈𝒫subscript𝑃𝑝𝒫P_{p}{P}italic_P start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT ∈ caligraphic_P do
|
||||
|
||||
for Pd∈𝒫subscript𝑃𝑑𝒫P_{d}{P}italic_P start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT ∈ caligraphic_P do
|
||||
|
||||
if Pp.𝑛𝑢𝑚_𝑔𝑝𝑢𝑠+Pd.𝑛𝑢𝑚_𝑔𝑝𝑢𝑠≤Mformulae-sequencesubscript𝑃𝑝𝑛𝑢𝑚_𝑔𝑝𝑢𝑠subscript𝑃𝑑𝑛𝑢𝑚_𝑔𝑝𝑢𝑠𝑀P_{p}.{num\_gpus}+P_{d}.{num\_gpus} Mitalic_P start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT . italic_num _ italic_gpus + italic_P start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT . italic_num _ italic_gpus ≤ italic_M then
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔←(𝑖𝑛𝑡𝑒𝑟_𝑜𝑝,Pp,Pd)←𝑐𝑜𝑛𝑓𝑖𝑔𝑖𝑛𝑡𝑒𝑟_𝑜𝑝subscript𝑃𝑝subscript𝑃𝑑{config}({inter\_op},P_{p},P_{d})italic_config ← ( italic_inter _ italic_op , italic_P start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT , italic_P start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT )
|
||||
|
||||
G^p,G^d←parallel(G,𝑐𝑜𝑛𝑓𝑖𝑔)←
|
||||
|
||||
subscript^𝐺𝑝subscript^𝐺𝑑
|
||||
parallel𝐺𝑐𝑜𝑛𝑓𝑖𝑔{G}_{p},{G}_{d}{parallel}(G,{config})over^ start_ARG italic_G end_ARG start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT , over^ start_ARG italic_G end_ARG start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT ← parallel ( italic_G , italic_config )
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡←simulate(G^p,G^d,W)formulae-sequence𝑐𝑜𝑛𝑓𝑖𝑔←𝑔𝑜𝑜𝑑𝑝𝑢𝑡simulatesubscript^𝐺𝑝subscript^𝐺𝑑𝑊{config.goodput}{simulate}({G}_{p},{G}_{d},W)italic_config . italic_goodput ← simulate ( over^ start_ARG italic_G end_ARG start_POSTSUBSCRIPT italic_p end_POSTSUBSCRIPT , over^ start_ARG italic_G end_ARG start_POSTSUBSCRIPT italic_d end_POSTSUBSCRIPT , italic_W )
|
||||
|
||||
if 𝑐𝑜𝑛𝑓𝑖𝑔.∗𝑔𝑜𝑜𝑑𝑝𝑢𝑡𝑐𝑜𝑛𝑓𝑖𝑔.∗𝑛𝑢𝑚_𝑔𝑝𝑢𝑠<𝑐𝑜𝑛𝑓𝑖𝑔.𝑔𝑜𝑜𝑑𝑝𝑢𝑡𝑐𝑜𝑛𝑓𝑖𝑔.𝑛𝑢𝑚_𝑔𝑝𝑢𝑠{{config.^{*}goodput}}{{config.^{*}num\_gpus}}<{%
|
||||
{config.goodput}}{{config.num\_gpus}}divide start_ARG italic_config . start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT italic_goodput end_ARG start_ARG italic_config . start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT italic_num _ italic_gpus end_ARG < divide start_ARG italic_config . italic_goodput end_ARG start_ARG italic_config . italic_num _ italic_gpus end_ARG then
|
||||
|
||||
𝑐𝑜𝑛𝑓𝑖𝑔∗←𝑐𝑜𝑛𝑓𝑖𝑔←superscript𝑐𝑜𝑛𝑓𝑖𝑔𝑐𝑜𝑛𝑓𝑖𝑔{config^{*}}{config}italic_config start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT ← italic_config
|
||||
|
||||
n←⌈R𝑐𝑜𝑛𝑓𝑖𝑔.∗𝑔𝑜𝑜𝑑𝑝𝑢𝑡⌉n{R}{{config.^{*}goodput}}_n ← ⌈ divide start_ARG italic_R end_ARG start_ARG italic_config . start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT italic_goodput end_ARG ⌉
|
||||
|
||||
𝑏𝑒𝑠𝑡_𝑝𝑙𝑚←(n,𝑐𝑜𝑛𝑓𝑖𝑔∗)←𝑏𝑒𝑠𝑡_𝑝𝑙𝑚𝑛superscript𝑐𝑜𝑛𝑓𝑖𝑔{best\_plm}(n,{config^{*}})italic_best _ italic_plm ← ( italic_n , italic_config start_POSTSUPERSCRIPT ∗ end_POSTSUPERSCRIPT )
|
||||
|
||||
return 𝑏𝑒𝑠𝑡_𝑝𝑙𝑚𝑏𝑒𝑠𝑡_𝑝𝑙𝑚{best\_plm}italic_best _ italic_plm
|
||||
|
||||
### 4.2 Placement for Low Node-Affinity Cluster
|
||||
|
||||
A straightforward solution is to always colocate prefill and decoding instances on the same node, utilizing the NVLINK, which is commonly available inside a GPU node.
|
||||
For large models, e.g. with 175B parameters (350GB), we may be unable to even host a single pair of prefill and decoding instances in an 8-GPU node (80G×8=640G<350×2GB80𝐺8640𝐺3502𝐺𝐵80G 8=640G<350 2GB80 italic_G × 8 = 640 italic_G < 350 × 2 italic_G italic_B). We incorporate this as additional placement constraints and co-optimize it with model parallelism, presented in Algorithm 2.
|
||||
|
||||
The key insight is that KV cache transfer occurs exclusively between corresponding layers of prefill and decoding instances.
|
||||
Leveraging inter-op parallelism, we group layers into stages and divide each instance into segments, termed as instance segments, with each segment maintaining one specific inter-op stage.
|
||||
By colocating prefill and decoding segments of the same stage within a single node, we force the transfer of intermediate states to occur only via NVLINK. Inside a node, we set the same parallelism and resource allocation for segments of the same instance. Given the typical limitation of GPUs per node (usually 8), we can enumerate possible configurations inside one node and use the simulator to identify the configurations that yield the best goodput.
|
||||
|
||||
As outlined in Algorithm 2, we begin by enumerating inter-op parallelism degrees to get all the possible instance segments. For each segment, we get all possible intra-node parallelism configurations by calling `get_intra_node_configs`. Then we use simulation to find the optimal one and replicate it to satisfy the target traffic rate.
|
||||
|
||||
### 4.3 Online scheduling
|
||||
|
||||
The runtime architecture of DistServe is shown in Figure 6. DistServe operates with a simple FCFS scheduling policy. All incoming requests arrive at a centralized controller, then dispatched to the prefill instance with the shortest queue for prefill processing, followed by dispatch to the least loaded decoding instance for decoding steps. This setup, while simple, is optimized with several key enhancements tailored to the nuances of real-world workloads.
|
||||
|
||||
Reducing pipeline bubbles.
|
||||
To mitigate the pipeline bubbles caused by non-uniform prompt lengths (§3.3), we schedule the requests in a way that balances the execution time across all batches in the pipeline. This is achieved by noting that, for both prefill and decoding instances, the number of new tokens in the batch is a reliable indicator of the batch’s real execution time.
|
||||
For prefill instances, we profile the target model and GPU to figure out the shortest prompt length Lmsubscript𝐿𝑚L_{m}italic_L start_POSTSUBSCRIPT italic_m end_POSTSUBSCRIPT needed to saturate the GPU. We schedule prefill batches with a total sequence length close to Lmsubscript𝐿𝑚L_{m}italic_L start_POSTSUBSCRIPT italic_m end_POSTSUBSCRIPT, by either batching multiple requests shorter than Lmsubscript𝐿𝑚L_{m}italic_L start_POSTSUBSCRIPT italic_m end_POSTSUBSCRIPT or individually scheduling requests longer than Lmsubscript𝐿𝑚L_{m}italic_L start_POSTSUBSCRIPT italic_m end_POSTSUBSCRIPT. For decoding instances, we set Lmsubscript𝐿𝑚L_{m}italic_L start_POSTSUBSCRIPT italic_m end_POSTSUBSCRIPT as the largest batch size.
|
||||
|
||||
Combat busrtiness.
|
||||
Burstiness in workloads can cause a deluge of KV caches to transfer from prefill to decoding instances, risking memory overload on decoding instances.
|
||||
To circumvent this, DistServe employs a “pull” method for KV cache transmission rather than a “push” approach – decoding instances fetch KV cache from prefill instances _as needed_, using the GPU memory of prefill instances as a queuing buffer. This way, the prefill instance can continue handling other prefill jobs by simply retaining the KV Cache in the GPU memory after processing the prompt. Hence, each type of instance operates at its own pace without complex coordination.
|
||||
|
||||
|
||||
|
||||
Figure 6: DistServe Runtime System Architecture
|
||||
|
||||
Replaning. The resource and parallelism plan in DistServe is optimized for a specific workload pattern, which may become suboptimal if the workload pattern changes over time. DistServe implement periodic replanning. A workload profiler monitors key parameters such as the average input and output length of the requests, the average arrival rate, etc. If a significant pattern shift is detected, DistServe will trigger a rerun of the placement algorithm based on recent historical data. This process is expedient – the proposed algorithm runs in seconds (§6.5) and reloading LLM weights can be completed within minutes – far shorter than the hourly scale at which real-world workload variations tend to occur.
|
||||
|
||||
Preemption and fault tolerance. DistServe does not implement advanced runtime policies like preemption [26] and fault tolerance [58], which are complementary to disaggregation. Nevertheless, we discuss how they fit into DistServe.
|
||||
In DistServe, the FCFS policy can lead to a “convoy effect”, where longer requests block shorter ones in the prefill stage. Incorporating preemptive strategies, as suggested in existing literature [53], could enhance efficiency and is feasible within our system’s architecture.
|
||||
While not a primary focus in the current DistServe, fault tolerance is a critical aspect for consideration. In traditional colocation- and replication-based systems, a fault in one instance typically does not disrupt other replica instances. However, in DistServe, the dependency between prefill and decoding instances introduces the risk of fault propagation. For example, a fault in a single decoding instance mapped to multiple prefill instances could potentially cripple the entire service and cluster. We leave both as future work.
|
||||
|
||||
## 9 结论（Conclusion）
|
||||
|
||||
We present DistServe, a new LLM serving architecture that disaggregates the prefill and decoding computation. DistServe maximizes the per-gpu goodput – the maximum request rate that can be served adhering to the SLO attainment goal for each GPU provisioned, hence resulting in up to 7.4×7.4 × lower cost per LLM query with guaranteed satisfaction of SLOs.
|
||||
Our findings affirm that as latency becomes an increasingly important metric for LLM services, prefill and decoding disaggregation is a vital strategy in promising improved performance and service quality guarantees.
|
||||
|
||||
Acknowledgments. We sincerely thank our shepherd and
|
||||
the anonymous reviewers for their valuable feedback. This work was
|
||||
supported by the National Natural Science Foundation of China under the grant numbers
|
||||
62172008, 62325201, and the National Natural Science Fund for the Excellent Young Scientists Fund
|
||||
Program (Overseas). Junda Chen is supported by UCSD fellowship and Hao Zhang is supported by UCSD faculty startup fund. Xin Jin is
|
||||
the corresponding author. Yinmin Zhong, Xuanzhe Liu, and Xin Jin are
|
||||
also with the Key Laboratory of High Confidence Software Technologies (Peking
|
||||
University), Ministry of Education.
|
||||
@@ -0,0 +1,91 @@
|
||||
# 📊 文章摘要：DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
|
||||
|
||||
> **原文**：[2024-01-18_DistServe.md](./2024-01-18_DistServe.md)
|
||||
> **原文链接**：https://arxiv.org/abs/2401.09670
|
||||
> **来源**：arXiv
|
||||
> **作者**：Yinmin Zhong, Shengyu Liu, Junda Chen, Jianbo Hu, Yibo Zhu, Xuanzhe Liu, Xin Jin, Hao Zhang（北京大学、StepFun、UC San Diego）
|
||||
> **发布日期**：2024-01-18
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **阶段解耦** — 将 prefill 与 decoding 两个计算特性迥异的阶段拆分到独立 GPU 池并各自定制资源与并行策略，以"每 GPU goodput"而非系统总吞吐为优化目标，是 LLM serving 成本优化的范式转折点。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
现有 LLM serving 系统（vLLM 等）将 prefill 与 decoding 两阶段放在同一批 GPU 上混合批处理，本文指出这一策略产生两类问题：一是强烈的 prefill-decoding 相互干扰（混合批处理时解码步被 prefill 步拖慢、TTFT 与 TPOT 相互挤压）；二是两阶段被耦合的资源配置与并行策略所绑定，无法各取所需。DistServe 将两阶段分配到不同 GPU，在 TTFT/TPOT 约束下联合优化各阶段的 GPU 数量与并行配置（含高低节点亲和集群两套放置算法），并用"拉取式"KV cache 传输、流水线气泡削减与周期性重规划支撑运行。在多种 LLM 与应用负载下，DistServe 相比当时 SOTA 系统可服务 7.4× 更多请求或满足 12.6× 更严格的 SLO（>90% 请求达标）。局限在于依赖工作负载可预测性（配置搜索基于模拟器）且未实现抢占与容错。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **两阶段特性迥异是问题根源** — prefill 是计算密集型单步操作、吃 FLOPs；decoding 是内存带宽受限的多步自回归，延迟敏感。混合批处理必然顾此失彼。`[分类: 共识]`
|
||||
2. **"干扰 + 耦合"双重病因** — 同批共存导致解码步延迟（TPOT 变长）、prefill 排队恶化（TTFT 变长）；且共享权重与显存迫使两阶段用同一并行策略，无法分别优化。`[分类: 范式突破]`
|
||||
3. **解耦收益量化** — 13B 模型单 A100 上，混合部署仅 1.6 rps goodput；分离后 prefill 单 GPU 达 5.6 rps、decoding 达 10 rps，按 2:1 GPU 配比整体 goodput 为 10 rps（每 GPU 3.3 rps），是原方案的 2.1×。`[分类: 共识]`
|
||||
4. **goodput 目标重塑优化函数** — 以"每 GPU 满足 SLO 达标率（90%）的最大请求率"为优化目标，直接对应单次查询成本；相比传统的最大 token 吞吐目标更贴合商业诉求。`[分类: 范式突破]`
|
||||
5. **两套放置算法适配不同网络** — 高节点亲和集群（Infiniband，跨节点 KV cache 传输开销可忽略）用枚举并行配置 + 二进制搜索模拟；低节点亲和集群利用"KV cache 只在对应层之间传输"的特性，将 prefill/decoding 的同层段共置单节点内走 NVLINK，避免跨节点慢速传输。`[分类: 未探索]`
|
||||
6. **"拉取"式 KV cache 传输抗突发** — decoding 实例按需从 prefill 实例拉取 KV cache，prefill 显存充当排队缓冲，避免突发流量压垮 decoding 内存，两类实例无需复杂协调。`[分类: 未探索]`
|
||||
7. **故障传播是新风险** — 解耦引入 prefill↔decoding 实例依赖：单个 decoding 实例故障可能连带多个 prefill 实例、瘫痪整个服务；抢占（如缓解 convoy 效应）与容错均留作未来工作。`[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 工作负载的到达过程与输入/输出长度分布在较长时间尺度上可预测（论文以小时/天级可预测为前提，用历史 trace 拟合分布驱动配置搜索）。
|
||||
- 现代集群具备足够的跨节点带宽，使解耦通信开销"不实质"（KV cache 传输相对推理时间可忽略）。
|
||||
- 应用对 TTFT 与 TPOT 的要求可明确量化并作为输入给定。
|
||||
- 单模型副本的优化可先于多实例扩展完成（分两步：先求最优单副本配置，再复制满足流量）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 论据链条完整：先以 Figure 1 的 13B 单卡实验证明"混合部署 goodput 远低于分阶段独立运行"（1.6 vs 5.6/10 rps），再推导出解耦的必要性；随后用模拟器 + 真实测试床验证配置搜索与 SLO 达标率对齐（论文声称模拟器与真实 profiling 高度吻合）。
|
||||
- 端到端评估覆盖三种真实应用（聊天、编程助手、文档摘要）与多模型，7.4×/12.6× 的收益数字有实验支撑。
|
||||
- 潜在弱点：7.4×/12.6× 是"up to"峰值表述，具体负载下提升幅度不同；解耦收益高度依赖集群网络质量，论文对此的敏感度分析着墨较少。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 结论适用于两阶段特性差异明显、SLO 严格的场景；若 TTFT/TPOT 要求宽松，解耦收益会收窄。
|
||||
- 未处理抢占调度与故障容错，且解耦使故障传播范围扩大——生产部署需另行补充。
|
||||
- 配置搜索依赖 workload 预测，负载模式剧烈变化（短时间尺度不可预测）时可能退化为次优。
|
||||
- 评估硬件为 A100 世代，未覆盖 H100/Groq 等后续异构平台（此边界由后续论文补足）。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "We find that this strategy not only leads to strong prefill-decoding interferences but also couples the resource allocation and parallelism plans for both phases."
|
||||
> （我们发现，这种策略不仅导致强烈的 prefill-decoding 干扰，还耦合了两个阶段的资源分配与并行计划。）
|
||||
|
||||
> "Our findings affirm that as latency becomes an increasingly important metric for LLM services, prefill and decoding disaggregation is a vital strategy in promising improved performance and service quality guarantees."
|
||||
> （我们的发现证实：随着延迟成为 LLM 服务日益重要的指标，prefill 与 decoding 解耦是带来性能与服务质量的提升的关键策略。）
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 首个系统化论证并实现 prefill/decoding 解耦的 serving 系统之一，直击当时 colocation 共识的软肋，开启后续解耦架构浪潮
|
||||
- "per-GPU goodput"优化目标将系统性能与商业成本直接挂钩，视角独特且可操作
|
||||
- 同时覆盖高/低节点亲和两类集群的放置算法，工程完备度高；KV cache"拉取"机制与流水线气泡消减是实用的系统细节
|
||||
|
||||
**不足**：
|
||||
- 依赖工作负载可预测性做离线配置搜索，在线自适应能力有限
|
||||
- 抢占与容错缺失，且未充分讨论解耦故障传播的工程应对
|
||||
- "up to"峰值收益表述下，对网络带宽敏感度的量化分析不够深入
|
||||
|
||||
**适用场景**：面向 LLM serving 系统设计者、云厂商推理基础设施团队；为理解后续（Mooncake、Splitwise、vLLM 解耦版等）全部解耦系工作提供理论基础。
|
||||
|
||||
**关联建议**：可与同期论文对照阅读——Splitwise（异构硬件视角的阶段拆分）、TetriInfer（混合负载干扰 + 长度预测调度）、Mooncake（KVCache 为中心的规模化生产实践）；后续可追踪 vLLM 官方对 prefill/decode 解耦的采纳与 DistServe 作者后续工作（如 DeepSeek 的 DeepEP/EP 解耦方向）。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,191 @@
|
||||
# PD(Prefill&Decode)分离
|
||||
|
||||
> **来源**：John's Blog（johng.cn）
|
||||
> **作者**：John Guo
|
||||
> **发布日期**：2026-08-05（原文未标注发布日期，按下载日占位）
|
||||
> **原文链接**：https://johng.cn/ai/pd-separation
|
||||
|
||||
---
|
||||
|
||||
## 引言
|
||||
|
||||
随着大型语言模型（`LLM`）在各个领域的广泛应用，如何高效地部署和推理这些模型成为了一个关键挑战。传统的 `LLM` 推理架构将整个推理过程视为一个整体，但这种做法往往无法充分利用硬件资源，导致性能瓶颈和用户体验下降。
|
||||
|
||||
`PD（Prefill & Decode）`分离技术作为一种创新的架构设计，通过将 `LLM` 推理过程分解为两个独立的阶段，并针对每个阶段的特性进行专门优化，显著提升了推理效率和用户体验。本文将深入探讨 `PD` 分离技术的原理、实现方案以及带来的优势。
|
||||
|
||||
### 推理过程概述
|
||||
|
||||
在深入了解 `PD` 分离之前，我们需要先理解 `LLM` 的推理过程。整个 `LLM` 推理过程可以分为两个截然不同的阶段：
|
||||
|
||||
- **Prefill 阶段（预填充阶段）**：这是计算密集型阶段，`LLM` 并行处理所有用户输入的 `token`，计算出对应的 `KV Cache`，并生成第一个输出 `token`。
|
||||
- **Decode 阶段（解码阶段）**：这是显存密集型阶段，模型基于已有的 `KV Cache`，通过自回归方式顺序生成后续的 `token`，每次迭代只产生一个新 `token`。
|
||||
|
||||
### 性能评估指标
|
||||
|
||||
为了准确衡量 `LLM` 推理系统的性能，业界定义了几个关键指标：
|
||||
|
||||
#### Prefill 性能评估指标
|
||||
|
||||
- **TTFT(Time To First Token)**：表示从接收用户请求到生成第一个 `token` 所用的时间
|
||||
|
||||
例如：`P90 TTFT SLO = 0.4s` 意味着 `90%` 的请求的 `TTFT` 值都必须 `≤0.4` 秒
|
||||
|
||||
#### Decode 性能评估指标
|
||||
|
||||
- **TPOT(Time Per Output Token)**：表示生成每一个响应 `token` 所用的平均时间
|
||||
|
||||
例如：`P90 TPOT SLO = 0.04s` 意味着 `90%` 的请求的 `TPOT` 值都必须 `≤0.04` 秒
|
||||
- **TBT(Token By Token)**：表示连续生成两个 `token` 之间的时间间隔，这是衡量用户体验流畅度的重要指标。`TBT` 越稳定，用户感知到的响应就越连贯
|
||||
|
||||
### 两阶段特性深度对比
|
||||
|
||||
通过下表我们可以清晰地看到 `Prefill` 和 `Decode` 阶段在各个维度上的显著差异：
|
||||
|
||||
| **特性** | **Prefill（预填充）阶段** | **Decode（解码）阶段** |
|
||||
| --- | --- | --- |
|
||||
| **计算模式** | 并行计算（所有输入 `Token` 同时处理） | 串行计算（逐个 `Token` 生成） |
|
||||
| **计算强度** | 计算密集型（矩阵乘法为主） | 内存带宽受限（访存频繁） |
|
||||
| **GPU 利用率** | 高（接近 `100%`） | 极低（约 `1%`） |
|
||||
| **关键性能指标** | 首次 `Token` 时间（`TTFT`） | `Token` 生成时间（`TPOT`） |
|
||||
| **主要瓶颈** | 算力（`FLOPs`） | 内存带宽（`Memory Bandwidth`） |
|
||||
| **显存占用** | 临时高（需缓存输入序列） | 持续高（需保存 `KV Cache`） |
|
||||
| **批处理优化空间** | 大（可合并多请求输入） | 小（动态调整生成任务） |
|
||||
| **典型延迟** | 短（毫秒级，如 `0.2` 秒处理 `255 Token`） | 长（秒级，如 `32` 秒生成 `256 Token`） |
|
||||
| **加速手段** | `Tensor Core` 加速、`FP16/INT8` 量化 | 内存访问优化、`KV Cache` 压缩 |
|
||||
| **通信需求** | 低（单节点可完成） | 高（分布式需同步 `KV Cache`） |
|
||||
| **调度优先级** | 高（优先保证 `TTFT`） | 中（需稳定 `TPOT`） |
|
||||
|
||||
## 为什么需要 PD 分离？
|
||||
|
||||
### Continuous Batching 的挑战
|
||||
|
||||
现代 `LLM` 推理系统广泛采用 `Continuous Batching` 技术来提高吞吐量。然而，`Prefill` 和 `Decode` 阶段对批处理的响应特性截然不同：
|
||||
|
||||
|
||||
|
||||
- **Prefill 阶段**：由于是计算密集型，随着 `Batch Size` 的增加，受算力限制，吞吐量增长趋势逐渐平缓
|
||||
- **Decode 阶段**：由于是内存带宽密集型，随着 `Batch Size` 的增加，吞吐量增长趋势越来越显著
|
||||
|
||||
### 传统架构的性能瓶颈
|
||||
|
||||
在传统的一体化部署模式中，当 `Prefill` 和 `Decode` 在同一设备上执行时，会出现严重的资源竞争问题：
|
||||
|
||||
|
||||
|
||||
如上图所示，当新的请求（`request5` 或 `request6`）到达时，系统会优先处理新请求的 `Prefill` 阶段，这会直接影响正在进行的 `Decode` 任务（`request2/3/4`），导致：
|
||||
|
||||
1. **TBT 不稳定**：正在生成 `token` 的请求被打断，响应时延增加
|
||||
2. **用户体验下降**：`token` 生成的连贯性被破坏
|
||||
3. **资源利用率低**：两个阶段的资源需求特性无法得到针对性优化
|
||||
|
||||
### PD 分离的解决方案
|
||||
|
||||
为了解决上述问题，`PD` 分离架构将 `Prefill` 和 `Decode` 部署在不同规格的集群中：
|
||||
|
||||
|
||||
|
||||
通过这种分离部署方案，配合智能的任务调度策略，可以在满足 `TTFT` 和 `TBT` 指标的前提下，结合 `Continuous Batching` 机制最大化 `Decode` 阶段的并发处理能力，从而在提供更好用户体验的同时，显著提升算力利用率。
|
||||
|
||||
## PD 分离的核心原理
|
||||
|
||||
### PD 分离的技术思路
|
||||
|
||||
`PD` 分离技术的核心思想是**解耦和专门化**：
|
||||
|
||||
1. **阶段解耦**：将 `Prefill` 和 `Decode` 这两个阶段从逻辑和物理上完全分离
|
||||
2. **设备专门化**：为每个阶段选择最适合其特性的硬件配置
|
||||
3. **优化独立化**：为每个阶段采用最优的并行策略和优化技术
|
||||
|
||||
### 具体实现架构
|
||||
|
||||
在 `PD` 分离架构中：
|
||||
|
||||
- **Prefill 集群**：部署在高算力 `GPU`（如 `A100`、`H100`）上，充分利用其强大的并行计算能力，专注于快速处理输入序列
|
||||
- **Decode 集群**：部署在大显存、高内存带宽的 `GPU`（如大内存的 `L40` 等）上，专注于高效的 `token` 生成和 `KV Cache` 管理
|
||||
- **网络互连**：两个集群通过高速网络（如 `NVLink` 或 `RDMA`）传输中间状态，主要是 `KV Cache` 数据
|
||||
|
||||
### 关键技术挑战
|
||||
|
||||
`PD` 分离系统需要解决几个核心技术问题：
|
||||
|
||||
1. **高效数据传输**：如何在 `Prefill` 和 `Decode` 节点间高效传输大量的 `KV Cache` 数据
|
||||
2. **智能调度策略**：如何设计调度算法确保请求在不同阶段间的平滑流转
|
||||
3. **并行策略优化**：如何为每个阶段选择最优的张量并行、流水线并行等策略
|
||||
4. **状态一致性**：如何保证分布式环境下 `KV Cache` 的一致性和正确性
|
||||
|
||||
### 技术发展现状
|
||||
|
||||
现代 `PD` 分离系统（如 `DistServe`、`Mooncake` 等）通过以下创新技术已经成功解决了这些挑战：
|
||||
|
||||
- **压缩传输算法**：减少 `KV Cache` 传输开销
|
||||
- **预测调度策略**：基于负载预测的智能任务分配
|
||||
- **异步处理机制**：`overlap` 计算和通信操作
|
||||
- **动态负载均衡**：根据实时负载调整资源分配
|
||||
|
||||
这些技术创新使得 `PD` 分离架构能够将额外开销控制在可接受范围内，同时实现显著的性能提升。
|
||||
|
||||
## PD 分离部署下的用户访问时序
|
||||
|
||||
在 `PD` 分离部署架构中，一次完整的用户请求涉及三个角色的协同工作：用户（`Client`）、`Prefill` 节点（`P`）和 `Decode` 节点（`D`）。下图详细展示了这三方之间完整的数据交互时序。
|
||||
|
||||
### 时序关键环节说明
|
||||
|
||||
| 阶段 | 参与方 | 核心动作 | 关键指标 |
|
||||
| --- | --- | --- | --- |
|
||||
| ① 请求接入 | `Client` → 调度层 → `P` | 用户发起请求，调度层将完整 `Prompt` 路由至 `Prefill` 节点 | - |
|
||||
| ② `Prefill` 计算 | `P` | 并行处理所有输入 `Token`，构建完整 `KV Cache`，产出第一个 `Token` | `TTFT` |
|
||||
| ③ `KV Cache` 传输 | `P` → `D` | 通过高速网络（`RDMA`/`NVLink`）将 `KV Cache` 从 `P` 传输至 `D` | 传输延迟 |
|
||||
| ④ `Decode` 接管 | `D` | 加载 `KV Cache` 后以自回归方式逐步生成后续 `Token` | `TPOT`/`TBT` |
|
||||
| ⑤ 流式推送 | 调度层 → `Client` | 每生成一个 `Token` 即实时推送给用户，保证响应连贯性 | `TBT` |
|
||||
| ⑥ 请求结束 | `D` → 调度层 → `Client` | 遇到终止条件后发送结束信号，关闭流式连接 | - |
|
||||
|
||||
### 与传统一体化架构的对比
|
||||
|
||||
在传统一体化部署中，`Prefill` 和 `Decode` 在同一节点串行执行，新请求的 `Prefill` 计算会抢占正在进行 `Decode` 的 `GPU` 资源，导致 `TBT` 抖动。`PD` 分离后：
|
||||
|
||||
- `P` 节点专注于 `Prefill` 计算，完成后立即释放资源处理下一个新请求，不影响 `D` 节点的 `Decode` 流程
|
||||
- `D` 节点持续稳定地执行自回归生成，`TBT` 不受新请求到达的干扰
|
||||
- 调度层可以独立控制 `P` 和 `D` 集群的并发规模，实现精细化弹性扩缩容
|
||||
|
||||
## PD 分离带来的优势
|
||||
|
||||
通过将 `Prefill` 和 `Decode` 阶段分离部署，这种架构在多个方面带来了显著的改进，特别是在处理长上下文（`long context`）场景时，其优势更加明显。
|
||||
|
||||
### 资源分配与利用的优化
|
||||
|
||||
#### 异构设备的充分利用
|
||||
|
||||
- **成本效益最大化**：`Prefill` 阶段计算密集，适合部署在高算力 `GPU`（如 `A100`、`H100` 等高端计算卡）上；而 `Decode` 阶段显存密集，可以采用低算力但大显存的 `GPU`（如大内存的 `L40` 等）。这种差异化配置能够显著降低硬件总成本，同时提高每种设备的利用率。
|
||||
- **弹性资源管理**：可以根据实际负载情况独立地为 `Prefill` 和 `Decode` 集群进行扩缩容。在业务高峰期，可以针对性地为瓶颈阶段分配更多资源，而不必为整个系统进行等比例扩容，大大提高了系统的弹性和成本效益。
|
||||
|
||||
### 性能指标的全面提升
|
||||
|
||||
#### 多指标同步优化
|
||||
|
||||
- **避免性能权衡**：在传统架构中，优化 `TTFT` 往往会影响 `TPOT`，反之亦然。`PD` 分离允许在 `Prefill` 阶段限制 `Batch Size` 以减少 `TTFT`，同时在 `Decode` 阶段增大 `Batch Size` 以提高并发处理能力。这种策略能够同时改善所有关键性能指标，而不需要在不同指标之间做权衡。
|
||||
- **稳定的用户体验**：通过分离部署，新请求的 `Prefill` 计算不会占用 `Decode` 阶段的资源，从而保证了稳定的 `TBT`，为用户提供更加流畅和一致的交互体验。
|
||||
|
||||
### 技术实现的灵活性
|
||||
|
||||
#### 独立优化策略
|
||||
|
||||
- **阶段特化优化**：可以为 `Prefill` 和 `Decode` 阶段分别采用最适合的模型优化技术。例如，在 `Prefill` 阶段采用量化、矩阵分解等计算优化技术，而在 `Decode` 阶段专注于 `Continuous Batching` 和 `KV Cache` 管理优化。
|
||||
- **硬件生态扩展**：这种分离架构为使用不同类型的硬件加速器打开了可能性。可以在 `Prefill` 阶段使用传统 `GPU`，而在 `Decode` 阶段尝试使用专用的推理芯片或其他新兴硬件，进一步降低成本并提高效率。
|
||||
|
||||
### 系统可靠性与可维护性提升
|
||||
|
||||
#### 故障隔离与高可用
|
||||
|
||||
- **单点故障消除**：当 `Prefill` 或 `Decode` 集群中的某个节点出现故障时，不会直接影响另一阶段的正常运行，显著提高了系统的整体可靠性和可用性。
|
||||
- **运维灵活性**：可以独立地对 `Prefill` 或 `Decode` 集群进行版本升级、配置调整或维护操作，大大减少了系统维护对线上服务的影响，提高了运维效率。
|
||||
|
||||
#### 扩展性与未来适应性
|
||||
|
||||
- **技术演进适应**：随着新的硬件技术和算法优化的出现，可以独立地在某一阶段应用新技术，而不需要重新设计整个系统架构。
|
||||
- **业务场景适配**：不同的业务场景对 `Prefill` 和 `Decode` 的性能要求不同，分离架构允许根据具体业务需求灵活调整两个阶段的资源配比和优化策略。
|
||||
|
||||
通过这些全方位的优势，`PD` 分离架构不仅解决了传统 `LLM` 推理系统的性能瓶颈问题，还为大模型的高效部署和应用提供了一个更加灵活、可扩展的技术方案。
|
||||
|
||||
## 参考资料
|
||||
|
||||
- https://www.eet-china.com/mp/a412848.html
|
||||
@@ -0,0 +1,79 @@
|
||||
# 📊 文章摘要：PD(Prefill&Decode)分离
|
||||
|
||||
> **原文**：[2026-08-05_PD_PrefillDecode分离_johng.md](./2026-08-05_PD_PrefillDecode分离_johng.md)
|
||||
> **原文链接**：https://johng.cn/ai/pd-separation
|
||||
> **来源**：John's Blog（johng.cn）
|
||||
> **作者**：John Guo
|
||||
> **发布日期**：2026-08-05（原文未标注发布日期，按下载日占位）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐ 低
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **解耦专门化** — 以"阶段解耦、设备专门化、优化独立化"三原则系统梳理 PD 分离的概念、原理、架构与优势，是合格的入门科普。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文系统介绍 PD 分离：先对比 Prefill（计算密集、GPU 利用率近 100%）与 Decode（内存带宽受限、利用率约 1%）两阶段的特性差异与指标（TTFT/TPOT/TBT），再说明连续批处理下 Prefill 抢占 Decode 导致 TBT 抖动的问题，进而提出"解耦和专门化"的分离架构——P 集群用高算力卡、D 集群用大显存高带宽卡、经高速网络传输 KV Cache。文章还给出了完整的用户访问时序与六类优势（异构设备、指标解耦、独立优化、故障隔离、弹性扩缩容等）。价值在于对比表与时序梳理清晰、适合作入门资料；局限是全程无实验数据与量化分析，对传输开销与调度复杂度等代价仅一笔带过，结论偏乐观。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **两阶段特性对比表** — 算力 vs 内存带宽、GPU 利用率近 100% vs 约 1%、批处理优化空间大 vs 小、加速手段各异（Tensor Core/量化 vs 访存优化/KV 压缩），是全篇文章信息密度最高的部分。 `[分类: 共识]`
|
||||
2. **传统架构的 TBT 抖动** — 新请求 Prefill 抢占正在 Decode 的 GPU，导致 token 生成连贯性被破坏、用户体验下降。 `[分类: 共识]`
|
||||
3. **分离架构三要素** — 阶段解耦（逻辑与物理分离）、设备专门化（P 用 A100/H100 类高算力卡、D 用 L40 类大显存卡）、优化独立化（两阶段分别采用最优并行策略）。 `[分类: 共识]`
|
||||
4. **四大技术挑战** — 高效数据传输、智能调度策略、并行策略优化、KV Cache 状态一致性；作者称现代系统（DistServe、Mooncake）已通过压缩传输、预测调度、异步 overlap、动态负载均衡"成功解决"。 `[分类: 共识]`
|
||||
5. **六类优势清单** — 异构设备降本、多指标同步优化、阶段特化优化、故障隔离、独立运维升级、按业务灵活扩缩容。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论假设"KV Cache 传输等额外开销能被控制在可接受范围内"（文中仅一句带过，无论证）；假设读者为零基础入门者，故全篇以概念梳理为主；对分离的红利描述默认 P:D 配比合理、调度器智能——这些恰是落地中最难的环节。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
无任何实验数据或量化计算支撑结论，属于概念综述而非论证型文章；"现代 PD 分离系统通过以下创新技术已经成功解决了这些挑战"的论断乐观且缺乏证据支撑——同批丁师兄文章恰好展示了这些挑战在真实生产中的棘手程度；对比表与结论之间的逻辑依赖多为断言而非推演。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
未讨论 KV 传输开销量级、P:D 比例敏感性、调度复杂度、显存碎片化等落地代价，也未引用任何论文数据（仅文末一个 EET-China 链接）；结论适用于"PD 分离值得做"的定性理解，对成本收益评估、方案选型等决策场景不适用；与同批其他文章相比无独立观点与增量信息。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD 分离技术的核心思想是**解耦和专门化**"
|
||||
|
||||
> "这种策略能够同时改善所有关键性能指标，而不需要在不同指标之间做权衡。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- Prefill 与 Decode 的 12 维特性对比表清晰完整，入门阶段信息密度高
|
||||
- 用户访问时序六环节梳理（请求接入→Prefill→KV 传输→Decode→流式推送→结束）直观易懂
|
||||
- 结构完整，覆盖概念、原理、架构、时序、优势全链条
|
||||
|
||||
**不足**：
|
||||
- 无实验数据与量化分析，关键论断（"挑战已被成功解决"）缺乏证据
|
||||
- 对落地代价与边界条件基本缺席，结论乐观
|
||||
- 与同批文章相比无独立观点，认知增量低
|
||||
|
||||
**适用场景**：零基础读者建立 PD 分离整体概念的入门资料；需要向非技术角色解释 PD 分离的科普素材；作为深入阅读前的背景铺垫。
|
||||
|
||||
**关联建议**：入门后建议按序阅读本批 DistServe 解读（理论依据与量化收益）、marcus 的 vLLM 源码剖析（实现机制）、丁师兄文章（落地代价），三者可完整覆盖"是什么—为什么—怎么实现—有何代价"；该文文末参考的 EET-China 链接（https://www.eet-china.com/mp/a412848.html）亦可溯源。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
本篇文章为低价值，未生成配图。
|
||||
@@ -0,0 +1,72 @@
|
||||
# llm-d：K8s 原生的分布式推理栈架构文档
|
||||
|
||||
> **来源**：llm-d
|
||||
> **作者**：llm-d 项目团队（CNCF Sandbox 项目）
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://llm-d.ai/docs/architecture
|
||||
|
||||
---
|
||||
|
||||
# Architecture
|
||||
|
||||
llm-d 架构高级指南。从这里开始，然后深入阅读具体指南。
|
||||
|
||||
## Core Components（核心组件）
|
||||
|
||||
llm-d 架构围绕三个主要概念构建：**Router（路由器）**、**InferencePool（推理池）** 和 **Model Server（模型服务器）**。
|
||||
|
||||
- **llm-d Router** —— 推理请求的智能入口点。它提供 LLM 感知的负载均衡、请求排队和策略执行。由两个功能部分组成：
|
||||
- **Proxy**：一个高性能 L7 代理（通常是 Envoy），接受用户请求，并通过 `ext-proc` 协议咨询 EPP 以确定最佳目标。
|
||||
- **Endpoint Picker (EPP)**：路由引擎，基于实时指标、KV-cache 亲和性和配置的策略，对模型服务器 Pod 进行评分和选择。
|
||||
- **InferencePool** —— 通过标签选择器对服务同一基础模型的 Model Server Pod 进行分组的 API。被概念化为"面向 LLM 优化的 Service"，是 Router 的发现目标。此外：
|
||||
- **Variant**：InferencePool 内 Model Server Pod 的逻辑子分组，通过 Pod 标签而非专用资源来表达。Variant 根据共享特征（如服务角色（例如 prefill 或 decode）、成本概况、性能概况（吞吐量、延迟）或其他运营属性）来区分模型服务器。
|
||||
- **Model Server** —— 在硬件加速器（GPU、TPU、HPU）上执行模型的推理引擎（如 vLLM 或 SGLang）。
|
||||
|
||||
|
||||
|
||||
## Advanced Patterns（高级模式）
|
||||
|
||||
llm-d 的核心设计可以扩展出可选的高级模式：
|
||||
|
||||
### KV Cache Management（KV Cache 管理）
|
||||
|
||||
llm-d 提供了一个全面的生态系统，用于跨推理池管理和复用 KV cache，包括：
|
||||
|
||||
- **Prefix-Cache Aware Routing（前缀缓存感知路由）**：启发式和精确的技术以最大化缓存命中。
|
||||
- **KV-Cache Indexing（KV Cache 索引）**：跨所有模型服务器对缓存状态进行事件驱动的跟踪。
|
||||
- **KV Offloading（KV 卸载）**：分层存储体系（CPU、SSD）以扩展缓存容量。
|
||||
|
||||
参见 KV Cache Management 了解这些组件如何组合的概述。
|
||||
|
||||
### Disaggregated Serving（分离式服务）
|
||||
|
||||
在分离式服务中，单个推理请求被拆分为多个阶段（例如 Prefill 和 Decode），由专门的 worker 处理。llm-d Router 通过同时选择 prefill 和 decode 端点并协调它们之间的 KV-cache 传输来编排这一流程。
|
||||
|
||||
参见 Disaggregation 了解完整细节。
|
||||
|
||||
### Predicted Latency-Based Routing（基于预测延迟的路由）
|
||||
|
||||
llm-d Router 可以通过"consultant"边车扩展，以提供用于路由决策的高级信号。主要实现是 **Latency Predictor**，它支持基于预测的 ITL 和 TTFT 的路由。
|
||||
|
||||
- **Latency Predictor**：在线训练 XGBoost 模型以预测请求延迟，用于更好的端点评分和 SLO 执行。
|
||||
|
||||
### Batch Inference（批推理）
|
||||
|
||||
批处理和离线推理工作负载由两个模块处理，可以独立或一起部署。**Batch Gateway** 提供 OpenAI 兼容的 Batch API 用于作业管理，而 **Async Processor** 通过流控门控分发排队的请求。组合使用时，Batch Gateway 将分发委托给 Async Processor。
|
||||
|
||||
参见 Batch Inference 了解批推理设计的细节。
|
||||
|
||||
### Autoscaling（自动扩缩容）
|
||||
|
||||
llm-d 通过两种互补的方法支持主动的、SLO 感知的自动扩缩容：
|
||||
|
||||
- **HPA/KEDA**：标准 Kubernetes 原生扩缩容，使用 EPP 导出的指标（如队列深度）。
|
||||
- **Workload Variant Autoscaler (WVA)**：全局优化的扩缩容，通过在不同 variant 之间或跨推理池放置副本，在满足延迟目标的同时最小化成本。
|
||||
|
||||
参见 Autoscaling 了解完整细节。
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
> 文档版本：llm-d 0.8（Docusaurus 文档站，CNCF 托管项目）。llm-d 是 Kubernetes 原生的分布式推理服务栈，使用 vLLM 作为模型服务引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与控制平面，面向大规模生产环境的 P/D 分离、分布式 KV Cache 与 SLO 感知调度。
|
||||
@@ -0,0 +1,85 @@
|
||||
# 📊 文章摘要：llm-d：K8s 原生分布式推理栈架构
|
||||
|
||||
> **原文**：[2026-08-06_llm-d_K8s原生分布式推理栈架构.md](./2026-08-06_llm-d_K8s原生分布式推理栈架构.md)
|
||||
> **原文链接**：https://llm-d.ai/docs/architecture
|
||||
> **来源**：llm-d 官方文档（CNCF Sandbox 项目）
|
||||
> **作者**：llm-d 项目团队（CNCF Sandbox）
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **K8s 原生推理栈** — 用 Router（Proxy + EPP）、InferencePool（含 Variant 子分组）、Model Server 三个抽象，把 LLM 推理的调度、缓存、扩缩容全部收敛为 Kubernetes 原生的声明式模式。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 CNCF Sandbox 项目 llm-d 的架构指南，系统阐述其三层核心组件：llm-d Router（Envoy L7 代理 + Endpoint Picker 路由引擎，基于实时指标、KV-cache 亲和性与策略打分选端）、InferencePool（按模型分组的"LLM 优化的 Service"，Variant 通过 Pod 标签表达 prefill/decode 等服务角色）、Model Server（vLLM/SGLang 等推理引擎）。高级模式覆盖 KV Cache 管理（前缀缓存感知路由、事件驱动索引、CPU/SSD 分层卸载）、PD 分离编排（同时选择 prefill/decode 端点并协调 KV 传输）、基于 XGBoost 在线训练的延迟预测路由、批推理（Batch Gateway + Async Processor）与双通道扩缩容（HPA/KEDA + 全局优化的 Workload Variant Autoscaler）。价值在于提供了一套结构完整、可借鉴的 K8s 原生推理平台设计范式。局限在于全文为纯架构描述，无任何性能数据、对比实验或生产验证，且未讨论各模式之间的依赖关系与适用边界。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **三层抽象解耦清晰** — Router（路由决策）/ InferencePool（服务发现与分组）/ Model Server（算力执行）各司其职，将"面向 LLM 的调度逻辑"从基础设施中显式分离，是对传统 K8s Service 模式的 LLM 化扩展。 `[分类: 范式突破]`
|
||||
|
||||
2. **Variant 用标签表达服务角色** — prefill/decode、成本档位、性能档位等差异通过 Pod 标签而非专用资源表达，使同一 InferencePool 内可运行异构实例且无需新建 CRD 类型，设计轻巧。 `[分类: 共识]`
|
||||
|
||||
3. **KV cache 成为一等调度信号** — 前缀缓存感知路由 + 事件驱动 KV 索引 + 分层卸载（CPU/SSD），把"缓存命中率"纳入路由打分，这是 2025 年以来推理网关的公认演进方向。 `[分类: 共识]`
|
||||
|
||||
4. **SLO 感知的主动扩缩容** — WVA 在满足延迟目标的前提下跨 variant/跨池全局放置副本以最小化成本，与 HPA/KEDA 的反应式扩缩互补，代表了"成本最优 + SLO 驱动"的编排思路。 `[分类: 未探索]`
|
||||
|
||||
5. **无验证数据是硬伤** — 全文档零基准测试、零生产案例，XGBoost 延迟预测的在线训练稳定性、EPP 打分开销、PD 分离下的传输瓶颈等关键工程问题均未触及，方案成熟度无从判断。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
- 假设集群以 Kubernetes 为唯一控制平面，且团队具备 K8s 运维能力（Envoy、HPA/KEDA、CRD 生态）；
|
||||
- 假设以 vLLM 为默认引擎（其 EPP 协议、KV connector 机制是设计底座），其他引擎支持依赖社区生态；
|
||||
- 假设"LLM 感知的集中式路由"在超大规模集群上的扩展性成立——文档未讨论 EPP 作为单点路由引擎的性能边界。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
- 架构叙述内部自洽、模式描述符合业界主流实践（与 vLLM 的 KV connector、IGW 的 EPP 协议等既有机制对应），可视为对社区方案的整合与提炼，论据质量在于"结构可信"而非"数据可信"——没有任何性能数字或对比实验支撑其宣称的"最快落地速度""大规模生产环境"等表述，这些属于项目宣传口径。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
- 适用场景：中型以上团队自建 LLM 推理平台时的架构蓝图参考；对 K8s 熟悉度高、愿意接受 CRD/Operator 生态的团队。
|
||||
- 不适用于：单机/小集群简单部署（复杂度不划算）、对延迟极度敏感且需绕过 K8s 调度开销的场景、非 K8s 基础设施环境。
|
||||
- 高级模式（延迟预测、WVA）均标注为可选扩展，但其交互关系（如延迟预测与 KV 亲和路由的优先级冲突）未说明。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "llm-d 是 Kubernetes 原生的分布式推理服务栈，使用 vLLM 作为模型服务引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与控制平面。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 三层抽象 + Variant 设计结构清晰，是 K8s 原生推理平台的可直接借鉴的架构范式
|
||||
- 将 KV cache、SLO、成本三个维度显式纳入调度决策，覆盖了业界最新关注点
|
||||
- CNCF Sandbox 托管 + 0.8 版本迭代，项目活跃度可信
|
||||
|
||||
**不足**：
|
||||
- 零性能数据、零对比实验、零生产案例，无法评估方案真实收益
|
||||
- 未讨论 EPP 单点扩展性、延迟预测在线学习稳定性等关键工程边界
|
||||
- "可选高级模式"之间的依赖与取舍缺乏说明
|
||||
|
||||
**适用场景**：K8s 工程团队设计 LLM 推理平台时的架构参考；对比 AIBrix、Dynamo 等同类方案时的横向认知材料；技术选型评审的输入之一。
|
||||
|
||||
**关联建议**：对照阅读 AIBrix（字节跳动，K8s 原生）、NVIDIA Dynamo（Planner/路由/KV 管理四组件）与 vLLM 官方 KV Connector 文档，横向比较三者对"路由、缓存、扩缩容"三大问题的解决路径；关注 llm-d 后续版本是否补充基准数据。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
# Disaggregated Prefilling (experimental) - vLLM
|
||||
|
||||
> **来源**：vLLM 官方文档
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-07-29
|
||||
> **原文链接**：https://docs.vllm.ai/en/latest/features/disagg_prefill/
|
||||
|
||||
---
|
||||
|
||||
# Disaggregated Prefilling (experimental)
|
||||
|
||||
This page introduces you to the disaggregated prefilling feature in vLLM.
|
||||
|
||||
Note
|
||||
|
||||
This feature is experimental and subject to change.
|
||||
|
||||
## Why disaggregated prefilling?
|
||||
|
||||
Two main reasons:
|
||||
|
||||
- __Tuning time-to-first-token (TTFT) and inter-token-latency (ITL) separately__. Disaggregated prefilling put prefill and decode phase of LLM inference inside different vLLM instances. This gives you the flexibility to assign different parallel strategies (e.g. `tp` and `pp`) to tune TTFT without affecting ITL, or to tune ITL without affecting TTFT.
|
||||
- __Controlling tail ITL__. Without disaggregated prefilling, vLLM may insert some prefill jobs during the decoding of one request. This results in higher tail latency. Disaggregated prefilling helps you solve this issue and control tail ITL. Chunked prefill with a proper chunk size also can achieve the same goal, but in practice it's hard to figure out the correct chunk size value. So disaggregated prefilling is a much more reliable way to control tail ITL.
|
||||
|
||||
Note
|
||||
|
||||
Disaggregated prefill DOES NOT improve throughput.
|
||||
|
||||
## Usage example
|
||||
|
||||
Now supports 9 types of connectors:
|
||||
|
||||
- __ExampleConnector__: refer to examples/disaggregated/example_connector/run.sh for the example usage of ExampleConnector disaggregated prefilling.
|
||||
- __LMCacheConnectorV1__: refer to examples/disaggregated/lmcache/disagg_prefill_lmcache_v1/disagg_example_nixl.sh for the example usage of LMCacheConnectorV1 disaggregated prefilling which uses NIXL as the underlying KV transmission. LMCache also offers a multi-process (MP) mode via `LMCacheMPConnector`, where a standalone `lmcache server` holds the KV cache shared by one or more vLLM instances; see the LMCache examples and the LMCache docs for setup.
|
||||
- __NixlConnector__: refer to tests/v1/kv_connector/nixl_integration/run_accuracy_test.sh for the example usage of NixlConnector disaggregated prefilling which support fully async send/recv. For detailed usage guide, see NixlConnector Usage Guide. For feature compatibility details, see NixlConnector Compatibility Matrix. You may specify one or multiple NIXL transfer backends, such as:
|
||||
|
||||
```
|
||||
--kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_both", "kv_buffer_device":"cuda", "kv_connector_extra_config":{"backends":["UCX", "GDS"]}}'
|
||||
```
|
||||
|
||||
- __MooncakeConnector__: refer to examples/disaggregated/mooncake_connector/run_mooncake_connector.sh for the example usage of MooncakeConnector disaggregated prefilling. For detailed usage guide, see MooncakeConnector Usage Guide.
|
||||
- __MoRIIOConnector__ (ROCm only): see MoRI-IO Usage Guide for example usage and detailed documentation.
|
||||
- __MultiConnector__: take advantage of the kv_connector_extra_config: dict[str, Any] already present in KVTransferConfig to stash all the connectors we want in an ordered list of kwargs.such as:
|
||||
|
||||
```
|
||||
--kv-transfer-config '{"kv_connector":"MultiConnector","kv_role":"kv_both","kv_connector_extra_config":{"connectors":[{"kv_connector":"NixlConnector","kv_role":"kv_both"},{"kv_connector":"ExampleConnector","kv_role":"kv_both","kv_connector_extra_config":{"shared_storage_path":"local_storage"}}]}}'
|
||||
```
|
||||
|
||||
- __OffloadingConnector__: enable offloading of KV data to CPU memory, customizing the CPU block size (in tokens) and total CPU memory bytes to allocate:
|
||||
|
||||
```
|
||||
--kv-transfer-config '{"kv_connector":"OffloadingConnector","kv_role":"kv_both","kv_connector_extra_config":{"block_size": 64, "cpu_bytes_to_use": 1000000000}}'
|
||||
```
|
||||
|
||||
For multi-tier offloading (e.g., CPU + filesystem tier) and the full configuration reference, see the KV Offloading Usage Guide.
|
||||
|
||||
- __FlexKVConnectorV1__: refer to examples/disaggregated/flexkv_connector/prefix_caching_flexkv.py for the example usage of FlexKVConnectorV1. FlexKV is a distributed KV Store and multi-level cache management system for ultra-large-scale LLM inference.
|
||||
|
||||
```
|
||||
--kv-transfer-config '{"kv_connector":"FlexKVConnectorV1","kv_role":"kv_both"}'
|
||||
```
|
||||
|
||||
## Reusing prefill token ids on decode
|
||||
|
||||
Note
|
||||
|
||||
This applies to disaggregated prefill and decode serving on the `/v1/chat/completions` endpoint, using a KV connector configured as in the Usage example above. It is experimental and subject to change.
|
||||
|
||||
In disaggregated serving, the prefill and decode stages both render the chat prompt from `messages` and tokenize it. Because the prefill stage has already produced the token ids, the decode stage can reuse them and skip its own templating and tokenization. The output is otherwise identical to a normal chat completion: it is detokenized to text, and tool and reasoning parsing, streaming, and structured output constraints all still apply.
|
||||
|
||||
The token ids are passed to the decode stage through `kv_transfer_params`, the dict already attached to the decode request to coordinate the transfer:
|
||||
|
||||
1. Send the prefill request with `return_token_ids` enabled, and read `prompt_token_ids` from the response.
|
||||
2. Set `kv_transfer_params["prompt_token_ids"]` to those ids on the decode request. `messages` is still required, but its content is not tokenized when the ids are present.
|
||||
|
||||
```
|
||||
prefill = client.chat.completions.create(
|
||||
model=model,
|
||||
messages=messages,
|
||||
extra_body={"return_token_ids": True, "kv_transfer_params": {"do_remote_decode": True}},
|
||||
)
|
||||
ids = prefill.prompt_token_ids
|
||||
|
||||
decode = client.chat.completions.create(
|
||||
model=model,
|
||||
messages=messages,
|
||||
stream=True,
|
||||
extra_body={"kv_transfer_params": {"do_remote_prefill": True, "prompt_token_ids": ids}},
|
||||
)
|
||||
```
|
||||
|
||||
## Development
|
||||
|
||||
We implement disaggregated prefilling by running 2 vLLM instances. One for prefill (we call it prefill instance) and one for decode (we call it decode instance), and then use a connector to transfer the prefill KV caches and results from prefill instance to decode instance.
|
||||
|
||||
All disaggregated prefilling implementation is under `vllm/distributed/kv_transfer`.
|
||||
|
||||
Key abstractions for disaggregated prefilling:
|
||||
|
||||
- __Connector__: Connector allows __kv consumer__ to retrieve the KV caches of a batch of request from __kv producer__.
|
||||
- __LookupBuffer__: LookupBuffer provides two API: `insert` KV cache and `drop_select` KV cache. The semantics of `insert` and `drop_select` are similar to SQL, where `insert` inserts a KV cache into the buffer, and `drop_select` returns the KV cache that matches the given condition and drop it from the buffer.
|
||||
- __Pipe__: A single-direction FIFO pipe for tensor transmission. It supports `send_tensor` and `recv_tensor`.
|
||||
|
||||
Note
|
||||
|
||||
`insert` is non-blocking operation but `drop_select` is blocking operation.
|
||||
|
||||
Here is a figure illustrating how the above 3 abstractions are organized:
|
||||
|
||||
|
||||
|
||||
The workflow of disaggregated prefilling is as follows:
|
||||
|
||||
|
||||
|
||||
The `buffer` corresponds to `insert` API in LookupBuffer, and the `drop_select` corresponds to `drop_select` API in LookupBuffer.
|
||||
|
||||
Now every process in vLLM will have a corresponding connector. Specifically, we have:
|
||||
|
||||
- Scheduler connector: the connector that locates in the same process as the scheduler process. It schedules the KV cache transfer ops.
|
||||
- Worker connectors: the connectors that locate in the worker processes. They execute KV cache transfer ops.
|
||||
|
||||
Here is a figure illustrating how the above 2 connectors are organized:
|
||||
|
||||
|
||||
|
||||
The figure below shows how the worker connector works with the attention module to achieve layer-by-layer KV cache store and load:
|
||||
|
||||
|
||||
|
||||
## Third-party contributions
|
||||
|
||||
Disaggregated prefilling is highly related to infrastructure, so vLLM relies on third-party connectors for production-level disaggregated prefilling (and vLLM team will actively review and merge new PRs for third-party connectors).
|
||||
|
||||
We recommend three ways of implementations:
|
||||
|
||||
- __Fully-customized connector__: Implement your own `Connector`, and call third-party libraries to send and receive KV caches, and many many more (like editing vLLM's model input to perform customized prefilling, etc.). This approach gives you the most control, but at the risk of being incompatible with future vLLM versions.
|
||||
- __Database-like connector__: Implement your own `LookupBuffer` and support the `insert` and `drop_select` APIs just like SQL.
|
||||
- __Distributed P2P connector__: Implement your own `Pipe` and support the `send_tensor` and `recv_tensor` APIs, just like `torch.distributed`.
|
||||
|
||||
|
||||
Back to top
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：Disaggregated Prefilling (experimental) - vLLM
|
||||
|
||||
> **原文**：[2026-07-29_Disaggregated_Prefilling_experimental_vLLM.md](./2026-07-29_Disaggregated_Prefilling_experimental_vLLM.md)
|
||||
> **原文链接**：https://docs.vllm.ai/en/latest/features/disagg_prefill/
|
||||
> **来源**：vLLM 官方文档
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-07-29
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **预填充与解码分离** — 将 prefill 与 decode 阶段部署在不同 vLLM 实例、通过 KV 传输连接器协同，以独立调优 TTFT/ITL 并控制尾部延迟
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 vLLM 官方文档，介绍实验性的分离式预填充（disaggregated prefilling）特性：将 LLM 推理的 prefill（预填充）与 decode（解码）阶段分别部署在两个 vLLM 实例中，通过连接器（Connector）把 KV cache 从 prefill 实例传输到 decode 实例，从而实现两个目标的独立调优——TTFT（首 token 延迟）与 ITL（token 间延迟），以及控制尾部 ITL（避免 decode 期间插入 prefill 任务导致尾延迟升高）。文档明确声明该特性不提升吞吐，并给出 9 种传输连接器（Nixl/Mooncake/FlexKV/LMCache/Offloading 等）、三大核心抽象（Connector/LookupBuffer/Pipe）与三方实现路径。其价值在于这是分离式推理架构的权威落地参考；局限是纯架构文档，无性能基准数据，生产级实现依赖第三方连接器。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **分离的两个动机** — 一是独立调优 TTFT 与 ITL（可为 prefill 与 decode 实例配置不同并行策略如 tp/pp 而不互相影响）；二是控制尾部 ITL（chunked prefill 也能达到但 chunk size 难以调准，分离式更可靠）`[分类: 共识]`
|
||||
2. **明确边界：不提升吞吐** — 文档以警示形式声明 "Disaggregated prefill DOES NOT improve throughput"，避免用户误用；其收益在延迟控制与资源分配灵活性 `[分类: 范式突破]`（反直觉的官方边界声明，值得注意）
|
||||
3. **9 种 KV 传输连接器** — 覆盖多条技术路线：NixlConnector（异步 send/recv，UCX/GDS 后端）、MooncakeConnector、MoRIIOConnector（ROCm）、FlexKV（分布式 KV 存储）、LMCacheConnectorV1（含 MP 模式）、OffloadingConnector（KV 卸载至 CPU）、MultiConnector（组合）等 `[分类: 共识]`（生态处于快速演进中）
|
||||
4. **三大核心抽象** — Connector（kv producer/consumer 间的 KV 检索）、LookupBuffer（SQL 式 `insert`/`drop_select` 语义）、Pipe（单向 FIFO 张量管道 `send_tensor`/`recv_tensor`）；`insert` 非阻塞、`drop_select` 阻塞 `[分类: 范式突破]`（可复用的架构设计）
|
||||
5. **decode 阶段复用 prefill token ids** — 经 `kv_transfer_params` 传递 `prompt_token_ids`，decode 实例跳过模板化与 tokenization；输出与普通对话一致，工具解析/流式/结构化输出约束仍生效 `[分类: 共识]`
|
||||
6. **三种第三方实现路径** — 完全定制 Connector（控制力最强但可能与未来版本不兼容）/ 数据库式 LookupBuffer / 分布式 P2P Pipe；vLLM 团队声明生产级实现依赖第三方贡献并会积极合入 PR `[分类: 未探索]`（生态治理模式本身是开放性话题）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
文档默认读者接受以下前提：部署两套实例的额外基础设施与运维成本可接受；KV 跨机传输的带宽/延迟开销低于分离带来的收益；用户场景存在 TTFT 与 ITL 独立调优或尾部延迟控制的真实需求（如长上下文、交互式服务）。对单机或小规模部署，这些前提通常不成立。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
作为工程文档，其结论（能控制尾部 ITL、不提升吞吐）来自架构层面的定性论证而非基准数据——全文没有任何性能对比数字，文档亦未声称做了 benchmark。"chunked prefill 的 chunk size 在实践中难以调准"这一论据是经验性陈述，缺乏数据支撑，但符合社区普遍观察。论点-实现（抽象设计）之间的对应关系清楚，逻辑链完整。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
特性标注为 experimental and subject to change，接口可能变动；仅适用于配置了对应 KV 连接器的 `/v1/chat/completions` 端点（token 复用部分）；生产级连接器依赖第三方（vLLM 团队不提供内置生产实现）；对吞吐敏感而非延迟敏感的场景无收益，对部署复杂度敏感的小团队场景收益为负。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Disaggregated prefill DOES NOT improve throughput."
|
||||
|
||||
> "Chunked prefill with a proper chunk size also can achieve the same goal, but in practice it's hard to figure out the correct chunk size value. So disaggregated prefilling is a much more reliable way to control tail ITL."
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 边界意识突出：开篇标注 experimental，并专门以警示形式澄清"不提升吞吐"，避免工程误用
|
||||
- 三大抽象（Connector/LookupBuffer/Pipe）简洁清晰，SQL 类比与 torch.distributed 类比降低了理解门槛
|
||||
- 给出 9 种连接器与三种实现路径，为选型和自研提供明确地图
|
||||
|
||||
**不足**：
|
||||
- 无任何性能基准或对比实验数据，收益大小需读者自行验证
|
||||
- 中文社区读者需注意：文档为英文，示例以命令行配置为主，缺乏端到端的部署架构图（仅有内部组件图）
|
||||
- 生态碎片化明显（9 种连接器并存），缺乏选型决策树
|
||||
|
||||
**适用场景**：大模型推理服务工程师、SRE 与架构师——尤其部署长上下文或交互式 LLM 服务、受尾部延迟困扰、或已在规划 prefill/decode 分离架构的团队；也适合需要为推理集群做资源隔离（prefill 与 decode 按需扩缩）的平台团队。
|
||||
|
||||
**关联建议**：结合 LMCache 博客（LMCacheConnector 的 MP 模式与 NVIDIA Dynamo 集成）阅读，了解 KV 缓存层在分离式推理中的生态位置；对照 Moonshot 的 Mooncake 项目（KVCache-centric 架构）理解分离式推理在超大集群中的完整形态；实践层面先跑通 examples/disaggregated/ 下的示例脚本再决定选型。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,376 @@
|
||||
# 大模型推理优化关键技术与应用实践研究报告（2026年）
|
||||
|
||||
> **来源**：中国信通院
|
||||
> **作者**：中国信息通信研究院人工智能研究所
|
||||
> **发布日期**：2026-03-31
|
||||
> **原文链接**：https://www.caict.ac.cn/kxyj/qwfb/ztbg/202604/P020260415615308750699.pdf
|
||||
|
||||
---
|
||||
|
||||
出版单位：中国信息通信研究院人工智能研究所、中国人工智能产业发展联盟，2026年3月。
|
||||
|
||||
**版权声明**：本报告版权属于中国信息通信研究院、中国人工智能产业发展联盟，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明"来源：中国信息通信研究院、中国人工智能产业发展联盟"。违反上述声明者，编者将追究其相关法律责任。
|
||||
|
||||
## 前言
|
||||
|
||||
大模型推理作为人工智能技术从实验室走向产业应用的"最后一公里"，承载着将模型能力转化为实际业务价值、平衡服务质量与成本投入的核心使命。随着生成式 AI、智能体（Agent）、多模态交互等技术的爆发式发展，推理需求呈现指数级增长。行业数据显示，2025年全球大模型推理计算量较上年提升100倍以上，同时，推理预算也在持续攀升，成为企业规模化落地的关键瓶颈。与此同时，不同场景对推理服务的差异化诉求（如低时延、高并发、长上下文处理）日益凸显，传统单点优化技术已难以应对"效果-性能-成本"的多目标协同，亟需构建全链路、系统性的推理优化体系。
|
||||
|
||||
本报告立足产业实践与技术演进，系统梳理大模型推理优化的技术路径与落地脉络。首先，剖析推理优化催生背景与概念特性；梳理当前围绕多样化场景适配、算力成本平衡、模型特性适配的核心挑战，揭示产业落地痛点。然后，根据关键技术发展，拆解模型、引擎、系统三级优化体系的核心方法与适配逻辑；结合产业生态演进趋势，分析从单点优化到"模型-架构-场景"协同优化的发展方向。再次，通过金融、运营商、电力、农业等行业案例验证技术落地价值。最后，提出技术与产业展望与建议。
|
||||
|
||||
## 目录
|
||||
|
||||
1. 大模型推理优化概况
|
||||
2. 大模型推理的主要挑战
|
||||
3. 大模型推理优化关键技术（模型层面、引擎层面、系统层面）
|
||||
4. 大模型推理优化应用实践
|
||||
5. 大模型推理优化典型案例（金融、运营商、电力、司法检察、农畜领域）
|
||||
6. 展望
|
||||
|
||||
## 一、大模型推理优化概况
|
||||
|
||||
大模型推理平台是指为千亿级参数模型提供高效推理服务的工程化基座，涵盖轻量化工具（如推理引擎、工具包）与集成化系统（如公有云服务、私有化部署系统、混合部署系统、边缘计算系统），一般通过"硬件-软件-模型-服务"的协同优化，实现高精度、低延迟、高并发与低成本的规模化服务输出，支持全场景AI服务化落地。随着大模型技术的飞速发展和企业智能化转型需求的不断攀升，大模型落地应用关注焦点正从训练环节转向推理环节。在此过程中，行业需求已从构建功能全面、用户友好且灵活的推理平台，逐步深化到解决实际落地中由"效果-性能-成本"构成的多目标协同难题。推理优化技术作为破解该难题的核心抓手，其重要价值正在大模型规模化应用中愈发凸显。
|
||||
|
||||
### （一）大模型推理成为新的落地焦点
|
||||
|
||||
大模型产业正迈向规模化落地的关键转型期，其落地焦点正从训练走向推理。作为连接技术创新与产业应用的核心枢纽，大模型推理正推动技术创新加速从验证迈向规模化应用。这一变革由市场需求、算存供给、成本经济与应用场景等多重因素共同驱动，标志着大模型正式进入规模化商业落地与价值兑现的新阶段。
|
||||
|
||||
**需求侧，大模型服务调用量与推理计算量呈现爆发式增长。** 推理服务调用量暴增，OpenAI 2025年12月发布的《2025年企业人工智能状况报告》显示，过去12个月，ChatGPT企业版API推理Token消耗暴增320倍，企业端消息量增长8倍。推理计算量翻倍，黄仁勋在2025年英伟达GTC大会上表示，由于代理型AI（Agentic AI）和推理能力的发展，目前所需的计算量轻松达到了去年预估的100倍。
|
||||
|
||||
服务平均序列长度攀增，从2023年最大序列长度4K增长到当前达128K，两年间增长至32倍，体现了当前大模型推理服务的任务复杂性与交互深度性。
|
||||
|
||||
**供给侧，算存资源、成本投入等配置重心正在向推理倾斜。** 算力供给层面，全球推理算力持续增长，2026年计算工作负载中推理占比将提升至66%；我国市场亦增速迅猛，2026年推理算力市场规模将达876.5亿元，较25年的438.3亿元接近翻倍（弗若斯特沙利文，《中国推理算力市场追踪报告2025H1》）。存储供给层面，推理应用对长记忆数据存储的需求显著提升，2025年，DRAM/SSD（闪存存储）/HDD（机械硬盘存储）价格指数累计增长327.59%/166.28%/66%。业务预算层面，2024年OpenAI推理业务预算达23亿美元，为训练GPT-4的1.5亿美元的15倍。可见大模型推理不同于训练的一次性投入，其伴随部署服务的持续性消耗，进一步导致推理账单的占比增长。
|
||||
|
||||
### （二）大模型推理优化的概念与目标
|
||||
|
||||
**1. 定义与范围**
|
||||
|
||||
大模型推理优化是指在保障模型服务等级目标（SLO）的前提下，通过一系列覆盖模型、引擎、系统（软/硬件）及服务全链路的技术手段与工程实践，系统性提升推理性能、降低运营成本的过程。其核心目标在于兼顾"效果-性能-成本"的协同优化，实现三者之间的动态平衡与最优权衡，从而支撑大模型技术规模化、可持续化的商业落地。
|
||||
|
||||
从AI全生命周期看，训练阶段的核心任务是通过海量数据学习模型参数，追求的是模型能力的上限，其过程一般具备离线、长周期、计算密集的特点。而推理阶段则是将已训练好的模型部署为在线或离线服务。在线服务一般要求实时响应用户请求，其核心诉求是效率、稳定与经济性；离线服务一般要求大批量生成结果，其核心诉求是吞吐、稳定与经济性。
|
||||
|
||||
从推理内部环节看，大模型推理优化贯穿于"压缩-部署-推理-服务"四个环节。压缩环节关注如何在可接受的精度损失范围内，通过量化、剪枝、蒸馏等技术减小模型体积与计算复杂度；部署环节关注如何高效地将模型加载至目标硬件环境，涉及容器化、冷启动加速，以及初始的网络/存储/计算资源配置等；推理环节是核心执行阶段，涵盖批处理调度、显存管理、高性能算子等引擎级优化，以及分布式推理、推理架构设计等系统级优化；服务环节则面向最终用户体验，包括API能力、请求调度、资源调度、负载均衡、弹性扩缩容、监控告警等能力。
|
||||
|
||||
从面向对象来看，推理优化的实施对象呈现出多层次、多样化的特征。在工具层面，以轻量化推理引擎与压缩工具为代表，可提供高性能的底层执行能力，迅速集成新兴技术并实现产业赋能。在系统层面，涵盖轻量化按需订阅模式的模型即服务（MaaS），自主可控定制化模式的私有化部署平台，本地化即插即用模式推理一体机，分布式实时响应模式的云-边-端协同推理系统，弹性伸缩平衡模式的混合部署系统等多种类型。
|
||||
|
||||
**2. 主要发展阶段**
|
||||
|
||||
大模型推理基础设施已完成初期功能集成，正走向系统级推理优化的深水区，各阶段围绕技术能力升级与产业价值落地，形成递进式目标。
|
||||
|
||||
- **第一阶段为功能集成阶段**，核心目标是实现推理服务的功能完备与可扩展。该阶段聚焦基础能力搭建，通过集成模型管理、部署调度、接口服务、运行监控等功能，打通从"训练输出模型"到"推理提供服务"的全流程链路。实践中，平台重点支持RAG、Agent等扩展能力，并提供标准化API接口，确保大模型推理服务能适配多样化业务接入需求，完成从"技术可用"到"服务可用"的跨越。
|
||||
- **第二阶段为初步性能提效阶段**，核心目标是实现服务局部性能提升与推理单点优化。该阶段通过压缩技术精细化，以及并行策略、显存优化、计算优化、批调度优化等实例内推理优化技术演进，实现服务请求计算效率的提升；同时，平台集成压缩工具库、推理引擎等工具，以降低请求时延（TTFT/TPOT/端到端时延）、提升系统吞吐（TPS/QPS）为核心指标，实现推理性能的单点突破。
|
||||
- **第三阶段为深化提效与经济落地阶段**，核心目标是实现场景协同优化与系统架构重构。该阶段不再局限于单点的技术优化与性能提升，而是结合模型特性与场景需求，以SLO为导向，推动"模型-架构-场景"的协同优化。实践中，预填充-解码（PD）分离、KV Cache多级存储、混合专家（MoE）分布式架构、注意力-前向反馈（AF）分离等新型系统架构成为主流，在满足场景化性能要求的同时，显著降低推理成本，实现高效与经济的双重目标。当前大模型推理基础设施正处于第二、第三阶段。
|
||||
- **第四阶段为深度融合与变革阶段**，核心目标是构建更具性价比与自适应性的推理基础设施。该阶段通过自适应感知、系统级兼容性设计、全链路成本压缩等方式，推动推理服务与业务场景深度融合，形成具备自优化、高兼容、低能耗的新一代推理体系。
|
||||
|
||||
**3. 核心目标**
|
||||
|
||||
初期聚焦单一指标的性能提升，主要关注时延、吞吐等关键指标的局部优化。当前目标为面向SLO约束的多目标协同优化：随着大模型进入规模化商业落地阶段，推理优化的目标转向"模型-架构-场景"的协同平衡，即在满足特定场景SLO的前提下，实现系统有效吞吐、成本压缩与效果保障的综合最优。其中，效果主要体现在特定业务场景下生成结果的可用性、相关性、准确性与安全性；性能主要体现在时延、吞吐量、服务稳定性（如失败率、P99延迟）等可量化的服务质量（QoS）指标上；成本涵盖算力成本（GPU/NPU小时数、显存占用），以及人力与时间成本（如模型迁移、适配、运维的复杂度）。
|
||||
|
||||
## 二、大模型推理的主要挑战
|
||||
|
||||
### （一）多样化场景的适配
|
||||
|
||||
不同场景对推理服务的核心诉求存在显著差异，形成了以低时延、高并发、流量波动与长上下文为代表的四大典型场景。一是低时延场景，如智能客服、实时对话系统，要求服务在用户可感知的时间内（通常为数百毫秒内）返回首个Token（Time to First Token, TTFT）；二是高并发场景，如批量内容生成、大规模数据标注、离线报告撰写等，追求高吞吐量（RPS/TPS），以最大化单位时间内的任务处理能力；三是长上下文场景，如基于RAG的知识问答、多轮Agent协作，随着上下文窗口从数千Token扩展至百万级别，KV Cache的显存占用呈线性甚至超线性增长，迅速耗尽GPU高带宽内存（HBM），成为长上下文场景下的主要瓶颈。此外，流量波动是几乎所有在线服务都面临的现实挑战。部分场景的业务流量呈现周期性（如工作日高峰、节假日低谷）或突发性（如营销活动、热点事件）特点。静态推理系统在闲时会造成资源浪费，在忙时则会因过载而拒绝服务或延迟飙升。
|
||||
|
||||
### （二）高质量算力需求与成本控制的平衡
|
||||
|
||||
一方面，复杂场景对算力的性能、稳定性提出严苛要求，需依托高性能硬件与优化技术保障服务质量；另一方面，推理阶段持续的算力消耗已成为企业核心成本负担，如何高效有机复用起存量算力、适配异构算力资源、实现跨场景协同调度，成为破解这一矛盾的关键。
|
||||
|
||||
前序算力资源的整合、复用面临多重阻碍。企业存量的早期GPU等资源，因硬件架构、软件生态与大模型推理需求可能存在不兼容问题，直接部署易出现性能短板。跨场景算力协同调度面临多重困境。异构算力的广泛应用，要求调度系统实现资源动态按需分配，但调度决策、资源隔离、动态适配三大挑战凸显。
|
||||
|
||||
### （三）模型特性与发展需求的适配
|
||||
|
||||
从传统的Dense架构向MoE架构、从单一语言向原生多模态、从数千Token上下文向百万级长序列持续跃迁。大模型的飞速发展对底层推理基础设施亦提出了严峻挑战：工程化方案必须具备高度的前瞻性与灵活性，能够快速适配新型模型的计算与存储特性，避免成为性能瓶颈，制约模型能力的充分释放。模型的快速演进推动推理优化从"适配模型"迈向"协同演进"的新阶段。未来的大模型推理平台需提供对MoE、多模态、超长序列等前沿特性的原生支持能力，构建从硬件存储到软件调度的全栈优化体系。
|
||||
|
||||
## 三、大模型推理优化关键技术
|
||||
|
||||
### （一）模型层面
|
||||
|
||||
模型层是大模型推理优化体系的源头，该层聚焦如何让模型本身更轻、更快、更易部署，通过结构升级、参数压缩、算子重构与算法创新，从根本上削减推理阶段的计算与存储开销。主要方向包括模型压缩、MoE稀疏化架构以及算法创新。
|
||||
|
||||
**1. 模型压缩**
|
||||
|
||||
模型压缩技术是解决大模型在资源受限环境中部署难题的关键途径，其核心目标是在尽可能保持模型性能的前提下，显著降低模型的存储占用和计算需求。通用压缩技术主要包括量化、知识蒸馏、剪枝和稀疏化等方法。量化通过降低权重和激活的数值精度减少存储开销，剪枝通过去除冗余连接降低模型密度，蒸馏则通过"教师-学生"机制保留模型的关键知识，低秩分解进一步在矩阵层面削减计算需求。这些方法的共性目标，是在最小化精度损失的同时，实现显存占用与计算时延的显著下降。
|
||||
|
||||
大模型推理场景下更强调"高比例压缩-低精度损失-高性能推理"的均衡。研究表明，适度的量化与结构化剪枝可以在精度下降不足1%的前提下，使推理速度提升30%—50%，显著改善服务响应时延。同时，低秩分解与混合精度推理技术正在成为主流方向。大模型压缩技术逐步向"无重训练压缩"与"自适应压缩"演进。近年来出现的自动压缩与敏感度感知量化方法，可在不额外训练的情况下，自动识别重要参数并进行动态压缩，从而降低部署复杂度，提升推理阶段的可迁移性与可扩展性。
|
||||
|
||||
**2. MoE架构**
|
||||
|
||||
混合专家（Mixture of Experts, MoE）模型架构以"按需激活"的稀疏计算模式，为推理优化提供了新的思路。MoE架构通过在推理阶段仅激活少量"专家网络"，可显著降低计算负载。其核心机制在于门控网络（Gating Network）根据输入特征动态选择专家，使每次推理仅涉及少量参数计算，从而实现计算稀疏化与显存占用优化。这种结构使得模型整体参数规模可扩展至万亿级，而单次推理计算量保持在可控范围。
|
||||
|
||||
MoE架构在带来效率优势的同时，也引入新的工程挑战。由于推理阶段需完成专家选择、激活分配与通信调度等核心步骤，额外引入了路由开销与负载不均问题。针对这一挑战，多种负载均衡策略与专家选择算法不断提出，如基于梯度统计或样本重要性的门控机制，可在保证推理稳定性的同时提升专家利用率。
|
||||
|
||||
专家细粒度分割与动态负载均衡是MoE模型的主要优化趋势。一方面，专家细粒度分割通过将原有大规模专家进一步拆分为更小的子专家单元，使模型能够以更高的分辨率匹配不同输入模式，显著提升专家利用率与激活灵活性。以DeepSeekMoE为代表的研究提出，将专家划分为多层子专家结构，通过共享专家参数与跨层专家融合，实现"多任务共享+精准激活"的稀疏计算机制。另一方面，在推理阶段通过监测专家激活分布与实时算力利用率，动态调整门控策略与专家调度策略，避免高频专家过载以及低频专家闲置引发资源浪费。研究表明，引入自适应门控与分层负载反馈后，模型整体吞吐可提升2–3倍，且可显著降低通信瓶颈。
|
||||
|
||||
**3. 算法优化**
|
||||
|
||||
注意力机制改造与解码并行加速是当前模型提效热点。一方面，高效注意力机制持续改造。大模型推理多为自回归生成，Transformer的KV Cache成为解码（Decode）阶段显存消耗的主要瓶颈。产学界围绕这一问题陆续提出多种注意力改进方案：多查询注意力（Multi-Query Attention, MQA）通过共享一套KV实现缓存压缩，分组查询注意力（Grouped-Query Attention, GQA）在性能与显存间进行折中。DeepSeek-V2提出多头潜在注意力（Multi-head Latent Attention, MLA），进一步引入低秩压缩机制，在保留各头独立权重的同时显著压缩KVCache，实现显存压缩与模型性能提升的兼顾。
|
||||
|
||||
另一方面，通过将Decode阶段并行化实现加速的算法已得到普遍落地。投机采样（Speculative Decoding）关注生成–验证过程的并行路径。通过引入一个草稿生成阶段和一个目标模型验证阶段，将推理中多个Token的生成与验证并行执行，从而打破了纯自回归的串行瓶颈。其在小批量场景下可将延迟降低约2-3倍。DeepSeek提出的多Token预测（Multi-Token Prediction, MTP）关注生成本身的并行化。通过让模型在每次前向过程中预测多个未来Token，从模型内部优化设计出发，削减自回归推理中每个Token生成的延迟。
|
||||
|
||||
### （二）引擎层面
|
||||
|
||||
引擎层是大模型推理体系中的关键枢纽，承担着将模型能力转化为可被系统高效执行、可直接支撑服务化部署的核心功能。其优化边界聚焦于单实例或轻量集群内的执行效率，为上层系统架构提供高性能、低延迟的基础计算能力支撑。当前的核心技术围绕显存管理、计算优化、并行加速、调度策略等关键环节展开。
|
||||
|
||||
**1. 显存优化**
|
||||
|
||||
显存优化是破解大模型推理性能瓶颈的关键突破口，其核心在于高效管理随序列长度线性增长的KV Cache，避免显存浪费、碎片化与容量溢出。传统推理引擎为每个请求按预设最大上下文长度静态分配连续显存空间存储KV Cache，导致实际短请求场景下显存利用率低下，并在动态批处理中产生严重碎片问题。
|
||||
|
||||
PagedAttention技术借鉴操作系统虚拟内存分页机制，将KV Cache划分为固定大小的逻辑页，并将其映射至非连续的物理显存页，实现按需分配与灵活复用，可显著提升显存利用率，实验表明vLLM采用该技术后在相同硬件下可支持的并发请求数提升3倍以上。Prefix Caching（如RadixAttention）通过识别并缓存系统提示词、历史对话等共享前缀的KV Cache，在多轮对话或批量相似请求场景下避免重复计算，有效降低首Token延迟并提升整体吞吐。此外，面对上下文窗口持续扩展（如百万Token级别）带来的显存压力，KV Cache卸载（Offloading）策略将非活跃或低频访问的缓存数据迁移至CPU内存、SSD甚至远程存储，构建"显存-内存-存储"的多级缓存体系，在保障推理连续性的同时显著扩展可处理上下文长度，并降低对高成本GPU资源的依赖。
|
||||
|
||||
**2. 计算优化**
|
||||
|
||||
计算优化聚焦提升硬件计算单元的利用率，通过减少冗余浮点运算（FLOPs）与内存访问开销，突破大模型推理中的计算与带宽瓶颈。
|
||||
|
||||
一是通过算子融合降低访存消耗。算子融合技术将多个细粒度算子（如矩阵乘法、加法、激活函数）合并为复合算子，减少内核启动次数和中间结果的显存读写操作。通过将中间张量保留在高速片上缓存或寄存器中，算子融合可显著降低内存带宽消耗并提高运算吞吐。FlashAttention通过重新组织注意力计算流程，将完整的注意力操作过程融合为单一CUDA内核，在执行中采用I/O感知和分块策略，避免中间结果矩阵在显存中的频繁读写，从而显著提升注意力计算性能。其升级版本FlashAttention-2进一步通过优化线程块划分与减少非GEMM操作，在NVIDIA A100 GPU上实现50–73%的FLOPs利用率。
|
||||
|
||||
二是结合硬件进行内核级优化（Kernel Optimization）。通过结合特定硬件架构（如NVIDIA Tensor Core）定制高频算子、性能瓶颈算子，实现最大化计算吞吐。DeepGEMM代表了通用矩阵乘法（GEMM）在硬件协同优化方向的先进实践。DeepGEMM针对NVIDIA Hopper架构（H100）进行深度优化，通过FP8低精度计算充分利用Tensor Core指令集，在保持模型精度可控的前提下，显著提高矩阵运算吞吐率。
|
||||
|
||||
**3. 并行加速**
|
||||
|
||||
并行加速策略通过多维度并行方法提升系统吞吐率、降低显存压力，优化计算资源利用率。
|
||||
|
||||
- **数据并行（DP）**：将模型副本部署到多个设备上，通过划分输入数据实现并行处理，从而提升系统整体吞吐量。适用于处理大规模并发请求，但对单卡内存压力无直接缓解作用。
|
||||
- **张量并行（TP）**：通过对模型内部参数矩阵按行或列进行切分，将单个算子的计算分布到多个设备上，解决单层模型参数过大无法被单个GPU承载的问题。然而TP通常伴随较高的通信开销，需要通过高效的通信策略和分块矩阵乘法进行优化。
|
||||
- **流水线并行（PP）**：按模型层级划分阶段，构建计算流水线。由于阶段之间存在依赖关系，后一阶段必须等待前一阶段完成首个微批次（micro-batch）数据的计算才能开始，从而产生流水线"气泡"，影响部分设备的利用率。
|
||||
- **专家并行（EP）**：主要用于MoE模型，通过将不同专家分配到不同GPU上，并优化负载均衡与通信效率，实现对大规模专家网络的高效计算，同时降低单卡显存占用。
|
||||
- **序列并行（SP）**：沿序列长度维度划分输入激活值，在张量并行基础上进一步降低显存压力，对长上下文推理尤为关键。
|
||||
|
||||
在实际部署中，混合并行策略成为主流方案，通过组合DP、TP、PP、EP和SP，可充分发挥各策略优势，实现吞吐率、显存占用及通信开销的综合优化。
|
||||
|
||||
**4. 批调度优化**
|
||||
|
||||
批调度优化旨在通过智能组织和处理推理请求队列，尤其应对推理解码阶段输出长度不定的特性。传统静态批处理（Static Batching）需等待批次中最慢请求完成，在大模型生成长度不定情况下，将引发资源浪费。动态批处理（Dynamic Batching）通过将多个推理请求组合成统一批次计算，根据实时请求队列动态调整批次大小，在等待时间与吞吐量之间实现更好的平衡。连续批处理（Continuous Batching）采用迭代级调度，在每轮迭代中动态决定批次大小，请求一旦完成生成便立即从批次中移除，并动态地将等待队列中的新请求加入批次，从而显著提升了GPU的利用率和整体吞吐量。此外，针对长上下文推理中存在的显存瓶颈与延迟挑战，分块预填充（Chunked-Prefills）将长输入序列分割为多个较小块按顺序处理，而非一次性处理整个序列，在适当边界处允许块处理与后续计算重叠，同时缓存已处理块的键值状态，避免重复计算。这种方法平衡了显存使用与计算效率，使长序列推理更加可行，同时降低峰值显存使用和首Token等待时间，是PD（Prefill-Decode）分离的引擎级实现。
|
||||
|
||||
### （三）系统层面
|
||||
|
||||
系统层是大模型推理体系全局控制与服务执行的核心，负责在跨节点、跨实例、跨资源的复杂环境中实现推理任务的高效协同与稳定交付。其关键技术包括结合模型、服务特性的分布式系统架构优化、分布式调度策略优化以及高性能存储等。
|
||||
|
||||
**1. PD分离架构**
|
||||
|
||||
预填充-解码（Prefill-Decode, PD）分离式推理架构已成为业界主流优化方案。大模型推理一般由预填充（Prefill）和解码（Decode）两阶段构成，其中预填充阶段是计算密集型（compute-bound）对算力需求高，容易迅速使GPU达到饱和；解码阶段是存储密集型（memory-bound）对显存需求高，在大批量（batch size）请求下才可充分利用计算资源，同时受到带宽限制。传统方式通常直接将推理服务部署到集群中，使得PD两阶段在同一节点上执行，引发两阶段资源争夺、并行策略互相掣肘难以优化，进一步导致资源利用率低、服务性能差、系统构建成本高等问题。
|
||||
|
||||
PD分离架构通过结构性解耦，将推理过程拆分为预填充与解码两个独立阶段，从根本上缓解计算资源与内存带宽的冲突。其核心思路是"阶段解耦、专用部署、并行调度"：预填充阶段可部署在高算力GPU节点以集中执行大规模矩阵运算；解码阶段则运行在优化了内存访问路径的节点上，以低延迟方式持续生成Token。该设计不仅提升了各阶段资源利用率，还显著降低了请求延迟，并提升了系统的并发处理能力。在该架构中，KV Cache是连接两阶段的关键枢纽。预填充阶段生成的KV Cache可被多个解码实例复用，尤其在不同请求共享相似Prompt前缀时，可避免重复计算历史上下文。此外，通过缓存持久化技术，系统能够在多轮对话中跨轮次复用缓存，有效降低重复推理开销。动态缓存管理策略进一步根据访问频率、优先级与显存状态自动决定缓存的分配与淘汰策略，确保有限显存资源下的最高命中率。
|
||||
|
||||
尽管PD分离架构在性能与扩展性方面表现优秀，但仍面临三大核心挑战：一是传输开销，大量KV Cache跨节点传输可能引入显著延迟；二是显存压力，解码阶段需同时维护大量并发请求的KV Cache，而HBM/DRAM等高带宽存储资源有限；三是缓存协同复杂，预填充生成与解码访问需精准匹配，否则缓存失配或冗余访问将削弱优化效果。为应对上述问题，业界提出多层次优化路径：在通信层采用RDMA/NVLink等高速互联技术，并结合KV Cache量化与按层流式传输策略以降低传输延迟；在存储层通过HBM-DRAM-SSD分级架构与缓存复用技术减轻显存占用；在调度层实现预填充与解码异步重叠执行、计算与传输并行，从而全面提升系统推理效率及扩展能力。
|
||||
|
||||
**2. AF分离架构**
|
||||
|
||||
在MoE架构模型的推理场景中，注意力（Attention）层与前向反馈（Feedforward）层呈现出显著的计算特征差异：前者为访存密集型，依赖KV Cache的频繁访问；后者为计算密集型，主要执行大规模矩阵乘运算。这种计算异构性使得在同一GPU上混合执行两类操作时，资源利用率往往受限，GPU计算单元与显存带宽难以同时饱和。
|
||||
|
||||
为应对此问题，业界提出了AF分离（Attention–Feedforward Disaggregation, AFD）架构，继承了PD分离"按任务性质分治优化"的系统思想。AF分离通过在系统层面将Attention模块与Feedforward模块拆分至不同计算节点，使两类任务可独立优化并并行执行。Attention节点（A节点）部署在具备高显存带宽与大容量缓存的GPU上，用于处理KV Cache与注意力计算；Feedforward节点（F节点）则部署在高算力、性价比更优的GPU上以执行Dense计算。该设计消除了计算与访存冲突，实现了异构资源的协同最优利用。
|
||||
|
||||
AF分离架构支持异构部署与独立扩展。当模型输入长度变化或系统SLO收紧时，A与F节点可分别按需扩展规模以维持目标延迟与吞吐的平衡。可分级伸缩的特性使得AF分离在多租户、长上下文、高并发场景下具有显著优势。此外，从模型系统协同设计的角度看，AF分离亦为模型结构优化提供了理论依据。例如，分析表明FFN层稀疏度与通信带宽呈正相关关系，合理引入低秩映射可在不增加通信负担的情况下提高稀疏度，从而实现更优的性能–精度–成本平衡。AF分离架构标志着大模型系统架构从PD分离为代表的阶段分治，迈向AF分离为代表的模块分治。
|
||||
|
||||
**3. 系统调度策略**
|
||||
|
||||
调度策略作为系统架构的智能中枢，协调着整个推理系统的运行效率。通过智能化请求分发与资源分配，使推理系统在满足SLO要求的同时，最大化算、网、存的资源利用率，最小化成本与长尾延迟，并能动态应对请求异构性与节点故障。现代调度系统主要围绕请求调度和资源调度两个维度展开优化。请求调度负责将用户请求智能分配给最合适的计算实例，综合考虑请求特性、实例负载和系统状态等多重因素。资源调度则关注硬件资源的动态分配与再平衡，根据工作负载变化实时调整计算、显存和带宽资源的分配。在MoE模型场景中，资源调度尤为重要，需要根据专家激活模式动态调整各专家的计算资源，以充分发挥MoE架构的效能。
|
||||
|
||||
缓存亲和性调度策略通过分析请求特征，将相似请求路由到具有对应KV Cache的实例处理，极大提升了请求处理效率。这种策略与PD分离架构完美契合，使得预填充阶段生成的KV Cache能够在多个解码请求间高效共享。负载感知调度策略通过实时监控各推理实例的GPU利用率、显存使用率、请求队列长度等关键指标，实现系统负载的动态均衡，避免部分实例过载而其他实例闲置的情况。故障感知与容错调度策略则通过多层次健康检查和自动故障转移机制保障服务连续性，结合请求重试和结果缓存策略，确保在部分组件故障时系统仍能维持基本服务能力。
|
||||
|
||||
**4. 高性能存储**
|
||||
|
||||
随着模型参数与上下文长度的快速增长，KV Cache作为模型的"工作记忆"，其存储开销呈平方级增长，对GPU显存构成巨大压力。传统单一依赖高带宽内存（HBM）的方案，在面临长上下文、高并发推理任务时，常因显存容量限制而导致吞吐下降、成本激增。为此，构建智能、高效的多级存储体系，已成为保障推理服务性能与经济效益的必经之路。
|
||||
|
||||
为应对显存资源稀缺性与成本挑战，动态多级长记忆存储架构被普遍使用。业界通常使用"HBM-DRAM-SSD"构成的三级动态存储架构。该体系将KV Cache依据访问特性与生命周期，智能调度于不同层级的存储介质中，其中高频访问的"极热"数据驻留于高带宽的HBM，中低频的"热"或"温冷"数据则迁移至容量更大、成本更低的DRAM和外置存储，实现性能与容量的最优平衡。这一架构设计旨在突破物理显存容量限制，支持更长上下文与更大批次并发，同时，通过低成本、高性能、大容量的外置存储有效扩展系统数据容量，优化"内存墙"和"容量墙"，进而显著降低系统整体成本。
|
||||
|
||||
多级存储架构的有效性依赖于一系列关键技术的深度协同。系统通过实时监控访问频率、时序局部性等指标，精准识别KV Cache的"冷热"状态，并借助后台异步任务，在各级存储间执行数据的智能换入换出。为最大化存储效率，系统引入前缀缓存等复用机制，当不同请求共享相同提示前缀时，直接复用已生成的KV Cache，避免重复计算。同时，通过RDMA与加速卡直通存储等底层技术，构建GPU与存储设备间的直接数据通道，消除CPU拷贝瓶颈，确保数据迁移的高效性。
|
||||
|
||||
PD分离架构为存储系统创造了独特的优化空间。在PD分离架构场景下，多级存储体系为Prefill阶段生成的KV Cache提供了跨节点的缓存共享与持久化能力，使得解码节点能够按需、低延迟地获取缓存。同时，通过将非活跃的历史缓存数据卸载至DRAM和外置存储，显著缓解了解码节点对昂贵HBM的依赖，使其支持更高并发度。存储系统还可与调度器协同，实现KV Cache的异步流式传输与智能预取，有效隐藏数据访问延迟。
|
||||
|
||||
尽管多级存储架构优势显著，其落地仍面临诸多挑战并驱动着技术持续演进。在缓存数据于多层级、多节点间动态迁移时，如何确保解码阶段访问到的KV Cache始终保持完整性与一致性，是维护推理正确性的关键挑战。同时，HBM、DRAM、SSD等存储器在带宽与延迟上存在数量级差异，系统需要精细设计数据放置与迁移策略，避免低速I/O成为整个推理管道的性能瓶颈。未来，多级KV Cache存储需要与并行文件系统、数据编织等跨域数据调度技术深度融合，实现跨集群的缓存资源池化与统一管理，为超大规模模型推理服务系统奠定坚实基础。
|
||||
|
||||
## 四、大模型推理优化应用实践
|
||||
|
||||
### （一）前期：聚焦平台功能完备
|
||||
|
||||
早期阶段，产业界普遍聚焦于构建功能完备的推理服务平台，以实现从模型调优到部署推理、服务化交付的全流程贯通。
|
||||
|
||||
一是，平台体系化能力初步形成，构建了模型推理的基础运行框架。早期平台重点在于整合模型管理、部署调度、接口服务、运行监控等核心功能，形成从"训练输出模型"到"推理提供服务"的闭环机制。
|
||||
|
||||
二是，平台功能从通用大语言模型部署扩展至多场景、多模态服务。典型特征包括支持文本生成、图像生成、语音理解等多模态推理接口，以及在线推理、离线批处理、RAG（检索增强生成）等多样化运行模式。这类多模态与多场景的扩展，使平台从"功能完备"进一步迈向"业务可复用"。
|
||||
|
||||
三是，平台能力向标准化与易用化方向深化。云服务厂商普遍提供一键部署、弹性伸缩、监控可视化等特性，显著降低了企业构建推理服务的门槛。
|
||||
|
||||
### （二）现状和趋势：方案迭代，从单点优化走向系统优化
|
||||
|
||||
**1. 单点优化：压缩工具与推理引擎是两大关键方向**
|
||||
|
||||
模型压缩工具核心目标是在可接受精度下降范围内，尽可能降低模型的存储与计算代价，以增强模型的可部署性以及成本效率。一是，压缩技术逐步演进为面向大模型特性的精细化轻量化方案。Meta采用的GPTQ与MIT提出的AWQ量化方法在权重量化过程中引入误差补偿、激活感知等机制，实现量化后精度保证的同时，降低显存占用并提升推理速度。二是，压缩工具化与平台化集成，成为推理优化体系中标准化模块。微软推出的DeepSpeed Compression将量化、剪枝、蒸馏功能封装为统一API接口；英伟达在TensorRT Toolkit中集成高精度量化与校准模块，核心通过校准技术（如KL散度校准、最小化量化误差校准），在INT8/INT4低精度下将精度损失控制在1%-3%以内；阿里云PAI平台推出PAI-Blade、PAI-EasyDistill、PAI-Model Gallery等模型轻量化组件，可提供丰富的模型压缩功能支持；百度千帆大模型平台集成PaddleSlim压缩工具，实现结构化剪枝、蒸馏与动态量化的统一管理。三是，与模型、硬件协同的高效压缩方案正成为新的趋势。英伟达在Hopper架构GPU中引入对FP8量化的原生支持，并通过TensorRT-LLM自动调用低精度算子实现算力加速。
|
||||
|
||||
推理引擎作为大模型推理体系中连接模型与算力的执行核心，是推理优化早期阶段单点性能提升的主要抓手。一是，通用推理引擎经历"多点爆发-功能富集-逐步收敛"的演化轨迹。从前期学术机构、初创企业、大型科技公司、技术社区等推出的几十种推理引擎，逐渐收敛至vLLM（技术社区）、SGLang（技术社区）、llama.cpp（技术社区）、Text Generation Inference（HuggingFace）、DeepSpeed-FastGen（Microsoft）、TensorRT-LLM（NVIDIA）等几个主流推理引擎，其中vLLM、SGLang因兼具推理优化特性丰富、功能更新迅速、社区支持充分、分布式支持能力强、二次开发支持性好、多硬件支持好、与DeepSeek/MoE等主流模型深度协同等优势，其产业应用普及性尤为突出。二是，围绕服务化场景特点，主流推理引擎不断纳入新特性，同时也衍生出一系列差异化、专用化推理引擎。LMDeploy在语言模型之外还关注视觉语言模型（VLM），主要围绕GPU进行深度优化，适用于企业级大规模、高稳定性、高性能应用和实时系统。SGLang对于分布式部署、长文本场景支持优异，尤其自DeepSeek-V2开始SGLang与DeepSeek深度整合，在性能测试中对于高并发、低时延等差异化场景均能完美胜任。三是，随着MoE模型架构逐渐成为主流趋势，主流大模型框架如vLLM、DeepSpeed等均强化了对MoE特性的支持，同时产业界也推出了一批聚焦MoE训推的AI框架，如清华的KTransformers通过优化底层算子、引入专家延迟机制（Expert Deferral）等创新技术，实现了CPU与GPU的高效协同。此外，DeepSeek也推出了为MoE架构中专家并行（EP）定向优化的DeepEP通信库。
|
||||
|
||||
**2. 协同优化基础：PD分离开启"模型-架构-场景"协同优化新篇章**
|
||||
|
||||
随着PD分离式推理架构逐渐成熟，场景落地显著加速。2024年陆续推出了DistServe（北大&USCD）、Splitwise（微软）、TetriInfer（华为云）和MemServe（华为云）等PD分离式推理架构方案。
|
||||
|
||||
2024年，DistServe提出了基础的PD分离架构，详细分析了PD分离架构对于大模型推理的适配性。该方案虽未涉及异构资源、复杂调度等针对场景特性的策略设计，但其开源代码仍为后续PD分离方向的方案演进奠定了基础。2024年5月，Splitwise初步验证了PD分离方案在异构硬件资源运行，可在保证性能要求下实现成本压缩；同时，提出了针对节点内、节点间的调度策略以及KV Cache传输策略的优化方向。同年，TetriInfer从工业落地角度进一步细化系统模块划分与调度策略，从实际应用中常见的分布式架构角度，提出结合P/D实例负载的调度策略，以保障负载均衡；同时，提出P/D实例转化机制，提升内部可扩展性。MemServe则从实际应用中常见的请求调度策略角度，提出基于全局请求的Global Prompt Tree管理机制，通过构建弹性内存池配合全局调度器，管理集群中的KV Cache与路由方式，突破当时传统架构主要聚焦实例内的局限性。
|
||||
|
||||
**大模型推理 Prefill-Decode 阶段对比：**
|
||||
|
||||
| 特性 | Prefill阶段 | Decode阶段 |
|
||||
|------|-------------|------------|
|
||||
| 操作 | 一般对应提示词处理 | 一般对应解码生成 |
|
||||
| 处理单元 | 整个提示词（N个词元） | 单个新词元（1个词元） |
|
||||
| 计算模式 | 并行计算 | 串行（自回归）计算 |
|
||||
| 计算复杂度 | O(n²)，n为prompt长度 | O(1)/token |
|
||||
| 瓶颈 | 计算密集型（Compute-Bound） | 内存带宽密集型（Memory-Bound） |
|
||||
| 主要操作 | 矩阵-矩阵运算（GEMM） | 矩阵-向量运算（GEMV） |
|
||||
| 核心指标 | 首字输出延迟（TTFT） | 每字生成时间（TBT） |
|
||||
|
||||
**3. 协同优化趋势一：以KV Cache为核心的架构优化**
|
||||
|
||||
当前，以Mooncake（月之暗面）、Dynamo（英伟达）、UCM（华为）等为代表的工业级方案迭出，以上方案均在PD分离架构基础上，提出针对KV Cache的"存储-计算-调度"方案，持续推动以KV Cache为核心的推理系统路线演进。
|
||||
|
||||
**1) Mooncake 架构方案**
|
||||
|
||||
2025年2月，月之暗面与清华联合阿里云、华为存储、面壁智能、趋境科技等共同发布了Mooncake开源项目，引起产业热烈轰动。该方案核心创新在于重构了推理服务的资源组织模式，通过全局调度器（Conductor）、P/D集群及分布式KV Cache池（Mooncake Store）的协同架构，实现计算与存储的深度解耦。
|
||||
|
||||
一方面，Mooncake Store作为统一存储池，创新性整合AI芯片原生的HBM以及集群闲置且成本更低的CPU、DRAM、SSD等存储资源，建立分级存储机制：高频访问的KV Cache块优先驻留HBM保障低延迟，历史缓存与低频数据动态下沉至DRAM与SSD，通过"以存换算"策略大幅降低HBM资源占用，同时借助RDMA的高带宽、低延迟特性实现跨介质数据高效流转。另一方面，针对长上下文处理与过载场景等产业痛点，Mooncake设计了多层次优化机制：在Prefill阶段采用分块流水线并行（CPP）技术，将超长输入令牌拆分后由多节点协同处理，结合计算与缓存操作的异步执行优化，有效降低长文本场景的TTFT；全局调度器采用KV Cache感知策略，优先路由请求至存在最长可重用前缀缓存的节点，并通过启发式热点迁移机制复制高频缓存块，最大化跨会话缓存重用价值。针对流量波动场景，引入预测式早拒绝策略，基于历史负载数据预测Decoding节点未来容量，提前筛选无法满足SLO的请求，避免无效Prefill计算导致的资源浪费。
|
||||
|
||||
该方案已在Kimi大模型实现生产级规模化落地，承接其80%以上的线上流量，可实现在真实工作负载下，系统有效吞吐量较基线方案提升75%，100%满足TBT约束（vLLM仅57%），TTFT分布与vLLM基本一致；在16k~128k输入长度的长上下文模拟场景中，吞吐量最高提升525%，且严格满足TTFT和TBT的SLO约束。Mooncake提出的"以存换算"理念为产业后续方案迭代奠定坚实基础。
|
||||
|
||||
**2) Dynamo 架构方案**
|
||||
|
||||
2025年3月，英伟达在GTC 2025推出NVIDIA Dynamo分布式推理加速项目。该方案的核心创新在于构建了模块化协同架构，通过SLO-based Planner、KV Cache感知路由、多级存储管理及高效传输组件（NIXL）的深度联动，实现Prefill与Decoding阶段的柔性解耦，为分布式推理提供性能、成本与扩展性的最优平衡。
|
||||
|
||||
一方面，针对分布式推理中的缓存复用、跨介质传输与成本优化等核心痛点，Dynamo设计了多层次技术方案：KV Cache感知路由器（Smart Router）通过实时追踪全集群KV Cache命中情况与节点负载，将请求路由至最优实例，显著降低TTFT；分布式KV Cache管理器构建四级存储体系，将高频缓存驻留GPU显存，中低频数据下沉至CPU内存、本地SSD及外置存储，避免KV Cache重复计算，大幅降低高端显存占用成本；推理传输库（NIXL）兼容多种后端，提供高带宽、低延迟的跨介质数据传输支撑，为解耦架构提供高效通信保障。另一方面，系统设计"实时监控-智能决策-资源调度"机制，基于持续采集的GPU资源指标、请求特征（输入/输出序列长度，ISL/OSL）与SLO目标（TTFT/ITL阈值）等信息，自动调整最优PD分离配置与并行策略，实现资源按需分配与自动扩缩容，大幅降低部署与运维复杂度。此外，Dynamo构建了全栈兼容的技术生态，原生支持TensorRT-LLM、vLLM、SGLang三大主流推理引擎，支持多引擎并行评估与业务灵活适配。
|
||||
|
||||
**3) UCM架构方案**
|
||||
|
||||
2025年11月，华为正式开源UCM（Unified Cache Manager）推理记忆数据管理套件，以加速AI推理性能。UCM以KV Cache多级缓存和推理记忆管理为中心，通过推理框架、算力、存储的三层协同，提供自适应全局Prefix Cache、全流程稀疏注意力、后缀检索预测等关键推理加速技术，破解长序列推理效率低、成本高的难题，实现推理TTFT最高可降低90%、系统吞吐最大可提升22倍和上下文窗口序列长度扩展10倍级。
|
||||
|
||||
一方面，UCM在底层框架和机制上提供了多级缓存空间的分层管理与智能流动能力：实时数据存放在高性能缓存HBM中，短期数据存放在DRAM中，其他数据存放在共享的外置存储中，以提升整体系统效率。另一方面，UCM实现了一系列创新的推理加速算法：自适应全局Prefix Cache提供任意位置、任意介质、任意组合的前缀命中能力，可实现KV Cache在单机HBM、单机DRAM、跨机DRAM、以及SSD池化存储等不同类型、范围中的精准查找和匹配，同时支持公共前缀、历史对话和RAG知识块多种拼接组合场景的复用，以提升推理TTFT指标；全流程稀疏加速算法提供Prefill阶段的超长KV分片卸载和增量稀疏，以及Decode阶段的动态稀疏，支持覆盖全流程的稀疏加速套件，可倍数级提升长序列推理吞吐及时延；后缀检索预测加速算法将行业的私域数据和用户习惯等隐私数据构建为Token级后缀索引，突破推理自回归瓶颈，实现单次输出多词，效果优于传统MTP。此外，UCM北向支持多样化的推理引擎，南向可接入多样化的存储系统。
|
||||
|
||||
该方案已在金融行业典型推理应用场景得到效果验证。在舆情分析系统中，将长文本分类知识库提前预热至KV Cache Pool中存储，避免每次推理时重复计算，将推理时延由10分钟降低至10秒，分类准确率提升至80%以上，实现客户之声高效精准分析。在会议纪要生成等长文档处理场景中，采用KV Cache稀疏去噪技术，将原始上下文进行压缩，突破上下文窗口限制，满足客户对会议纪要准确性与完整性的要求。
|
||||
|
||||
**4. 协同优化趋势二：结合MoE模型特性的架构优化**
|
||||
|
||||
当前，以DeepSeek（深度求索）、MegaScale-Infer（字节跳动）、Step-3（阶跃星辰）等为代表的工业级方案持续推出，以上方案基于PD分离的系统架构，同时针对MoE模型结构在系统层面实现协同优化。其中，MegaScale-Infer（字节跳动）与Step-3（阶跃星辰）在PD分离基础上，针对解码阶段MoE层注意力模块与前馈网络模块的计算差异，进一步细化提出了AF分离架构，推动推理系统在MoE架构下的范式演进。
|
||||
|
||||
**1) DeepSeek 架构方案**
|
||||
|
||||
2025年2月，我国深度求索推出的DeepSeek V3/R1技术方案。该方案实现超大规模模型高效训推、高阶推理能力等突破，凭借模型架构创新与全链路工程优化，在性能、成本与实用性间实现精准平衡，一经推出便引发国内外广泛关注，迅速渗透产业应用，成为大模型推理落地的主流选择。
|
||||
|
||||
其推理阶段方案同样基于PD分离架构，核心目标为在保证在线SLO的同时最大化吞吐量，该方案围绕大规模DeepSeekMoE模型特性进行了深度与细致的工程优化。并行策略层面，根据预填充、解码两阶段的计算特性，分别采用不同规模专家并行进行策略组合，以实现预填充阶段充分提升计算效率，解码阶段最大化并行度。负载均衡层面，通过在线监测识别热点专家并创建副本，以及冗余专家部署配合动态路由方案，解决推理阶段专家负载不均导致的"木桶效应"。通信优化层面，提出双微批次重叠执行实现计算-通信重叠。在预填充阶段将一个微批次的"attention+MoE"与另一个微批次的"dispatch+combine"重叠执行，使通信开销被计算开销覆盖；在解码阶段将一个微批次的"attention"与另一个微批次的"dispatch+MoE+combine"重叠执行，减少解码阶段注意力计算的高耗时占比。存储优化层面，通过3FS高性能并行文件存储系统和KVCache多级存储架构，将服务成本降低了90%，并显著降低推理时延。
|
||||
|
||||
该方案已实现大规模生产级落地，基于H800 GPU部署的推理服务，平均每台预填充吞吐达73.7k tokens/s（含缓存命中），解码输出吞吐约14.8k tokens/s。成本层面，通过架构优化与缓存复用，理论成本利润率可高达545%。其进一步围绕MoE架构模型深度优化的技术路径，为大模型推理方案提供了又一成熟范式。
|
||||
|
||||
**2) MegaScale-Infer架构方案**
|
||||
|
||||
2025年7月，字节跳动与北京大学联合发布MegaScale-Infer推理系统，核心突破在于通过"A/F模块解耦+乒乓流水线并行+高性能M2N通信库"，解决MoE模型在推理过程中，尤其在解码阶段由于FFN与Attention模块计算需求不同引发的GPU利用率低问题，以及数据在专家间分发调度引发的通信延迟问题。该优化方案普遍适用于MoE架构模型，已在字节跳动内部大规模部署，为超大规模MoE模型的工业化落地提供了系统级范式。
|
||||
|
||||
该方案专为MoE模型设计，创新性重构了MoE推理的模块组织与资源调度模式。一是，提出离散化专家并行（Disaggregated Expert Parallelism）架构（即AF分离），实现MoE模型层内Attention模块与FFN模块的物理解耦。同时，进一步为两类节点设计差异化的并行策略，以匹配其计算与内存特性。二是，提出乒乓流水线并行（Ping-Pong Pipeline Parallelism），通过拆分批次与流水线调度，实现计算-通信重叠，消除A/F两类节点间因等待计算/通信引发的频繁闲置，以及跨界点通信带来的时延消耗。三是，针对解耦架构下注意力节点（M个发送方）与专家节点（N个接收方）形成的"M2N通信模式"，提出了定制化的高性能M2N通信库。通过消除冗余操作、优化流量调度与保障硬件直连，为解耦架构下的MoE推理系统提供低延迟、高可靠的通信支撑。
|
||||
|
||||
MegaScale-Infer方案整体更侧重系统层创新，以A/F模块解耦打破MoE模型层困境与硬件资源限制，支持两类节点的异构硬件配置，适配所有大规模MoE架构模型，适用于云原生AI服务、弹性推理平台、大规模API服务等对吞吐量与成本敏感的场景。该方案已在字节跳动内部实现生产级部署，支撑Mixtral 8x22B、DBRX等主流MoE模型的线上服务。真实负载下，单GPU解码吞吐量较vLLM等基线方案最高提升7.11倍，异构集群中单位成本吞吐量较vLLM提升224%。
|
||||
|
||||
**3) Step-3架构方案**
|
||||
|
||||
2025年7月，我国阶跃星辰推出基于MoE架构的Step-3自研多模态大模型（VLM），并结合模型进一步提出高效推理架构方案。该方案同样加入了AF分离元素，实现"AF分离+多矩阵分解注意力（MFA）+StepMesh通信库"的模型-系统协同设计，该优化方案适用于MoE架构模型，且已实现对于主流国产芯片的深度适配。
|
||||
|
||||
该推理系统方案深度结合大规模MoE模型特性。一是，提出多矩阵分解注意力（MFA）的模型结构创新，可在保持与DeepSeek-V3相当的高注意力表达能力的同时，显著降低KV缓存大小和计算量。二是，提出注意-前馈网络解耦（AFD, Attention-FFN Disaggregation）架构，各自采用最优并行策略和硬件配置。三是，提出StepMesh通信库以更好支持AFD的模块解耦和异构部署。
|
||||
|
||||
该方案已通过生产级场景验证，在Hopper GPU集群上实现4039 tokens/GPU/s的推理吞吐量（在50ms的SLA约束下），是DeepSeek-V3（2324 tokens/GPU/s）的1.73倍；在国产芯片部署时，推理效率较主流方案提升显著，充分适配国产化算力生态。成本控制方面，其8K上下文每百万令牌推理成本低至0.055美元，为DeepSeek-V3（0.068美元）的80%，32K长上下文场景成本低至0.129美元，优势进一步扩大，仅为DeepSeek-V3（0.211美元）的61%。
|
||||
|
||||
## 五、大模型推理优化典型案例
|
||||
|
||||
### （一）金融领域：金融领域大模型高性能推理加速方案
|
||||
|
||||
案例实施单位：某金融清算机构、华为技术有限公司。
|
||||
|
||||
项目总体投资达数亿元，建设周期为三年，旨在构建一个覆盖"一个算力底座、两大平台（模型平台与数据平台）、六大中心"的先进技术体系。项目的核心目标是在金融普惠、风控合规、消费拉动及质效提升四大关键领域，成功落地超过十个示范性AI应用场景。
|
||||
|
||||
**1) 整体方案**
|
||||
|
||||
金融机构在核心的智能客服、舆情分析、会议纪要生成等场景中，遭遇了两个突出的技术瓶颈："推不动"——在处理坐席记录、调研报告、会议文本等长文档时，文本序列长度经常超过模型32K的上下文窗口限制，导致推理任务无法执行；"推得慢"——在企业级智能问答等高并发场景下，随着输入序列变长，系统响应速度急剧下降，30路并发时TTFT超过30秒。为解决这些挑战，金融机构引入了华为的AI推理加速与存储优化一体化方案，并针对不同业务场景进行了深度适配。
|
||||
|
||||
**2) 创新情况**
|
||||
|
||||
- **基于AI存储的KV Cache管理技术**：在舆情分析系统中，创新性的将长文本分类知识库以60KB的KV Cache形式提前预热并持久化在OceanStor A系列存储池中。该技术避免了每次推理时对固定知识的重复计算，从根本上降低了长文本处理的时延。
|
||||
- **KV Cache动态稀疏与去噪技术**：针对会议纪要等超长文本场景，该技术能对原始上下文进行智能压缩，在不损失关键信息的前提下，将80K的上下文负载有效压缩至16K进行加载，从而突破了模型固有的上下文窗口限制。
|
||||
- **融合"以查代算"的多轮对话记忆机制**：在智能问答场景中，系统将"多轮对话历史记忆"与高命中率的缓存查询机制相结合。这不仅有效扩展了有效的对话上下文长度，还通过直接调用缓存结果替代重复计算，显著提升了系统吞吐与响应速度。
|
||||
|
||||
**3) 应用实效**
|
||||
|
||||
性能大幅提升：在舆情分析场景中，端到端推理时延从超过15分钟缩短至近90%，实现了近乎实时的分析能力。在智能问答场景中，8卡部署下30并发TTFT降至9秒，降低66%，同时集群吞吐量提升43%。处理能力突破：成功突破模型上下文窗口限制，能够一次性处理完整的超长会议内容与多轮对话历史，解决了"推不动"的核心痛点。输出质量保障：以会议纪要生成为例，长会议纪要可直接推理，推理结果准确度大幅提升。用户体验飞跃：智能助手实现了从"答非所问的伪助手"到"精准连贯的真助手"的体验跃升。
|
||||
|
||||
### （二）运营商领域：九天人工智能平台
|
||||
|
||||
案例实施单位：中移九天人工智能科技（北京）有限公司（九天人工智能研究院）。
|
||||
|
||||
九天人工智能平台针对大模型推理业务规模化扩张中的核心痛点，构建全栈优化体系，目前已在能源、航空、农业、物流交通等关键行业的大模型生产级业务中实现深度落地。其痛点包括：一是模型训练与推理链路不连贯，不同参数规模模型推理适配流程重复繁琐、部署周期长；二是模型推理业务的资源利用率有待提升，采用PD混部的方式使得平台难以在保证稳定时延的前提下承载更多并发会话和更长的上下文长度；三是传统推理框架在底层逐层执行独立算子的过程中，频繁显存读写占据了大量带宽。
|
||||
|
||||
**1) 整体方案**
|
||||
|
||||
在整体架构上，采用训推一体框架打通训练-推理全链路，统一计算图与并行策略，实现模型的快速迁移与高效运行；在系统层面，引入PD分离部署，对不同阶段的计算与存储负载进行精细拆分和调度，提升算力利用率并降低大规模服务的硬件投入；在算子层面，围绕矩阵乘、Attention与位置编码等关键算子开展融合与深度优化，释放长上下文和高并发场景下的大模型推理性能。
|
||||
|
||||
- (1) 训推一体架构：大模型在训练与推理阶段共享同一套计算图和并行策略，兼顾大吞吐训练与低延迟推理。通过增量推理、Flash Attention、Paged Attention等融合算子的统一加速技术，在保证数值一致性的同时显著提升长上下文推理性能（支持最大128k序列长度）。统一训练与推理并行策略接口，对推理加速能力的模块化封装，无需导出、切分和转换模型，实现从训练到高性能推理的平滑迁移，整体部署周期缩短至天级。平台层面，围绕训推一体框架构建统一的算力资源池，整合训练集群与推理集群，并通过统一的调度策略实现跨业务协同编排，低成本实现"昼推夜训"、"闲时训练"等弹性调度策略。
|
||||
- (2) PD分离：通过将计算密集型的Prefill阶段与存储密集型的Decoding阶段解耦并分布式部署，实现了资源与阶段特性的精细匹配。同时基于以KV Cache为中心的分布式存储架构实现全局多级KV Cache管理，显著降低了因资源竞争导致的OOM风险与时延抖动。并且在资源动态调度的场景中，通过自动扩展机制，实时监控业务负载情况，动态调整P/D集群的规模。相比混部的推理方式，某稠密模型在引入PD分离架构后单卡吞吐量提升1倍以上，同时在生产场景中显著降低了大规模服务的硬件成本。
|
||||
- (3) 算子融合：引入流水线并行与Swizzle数据重排策略，通过"以算代搬"掩蔽数据搬运开销、提升缓存命中率，从而挖掘矩阵乘算子的极致性能；依托Cube/Vector并行能力，将矩阵乘后的后处理计算与相邻Vector类算子进行跨界融合，减少内核调用与中间结果回写；结合芯片特性设计Tiled-Attention算法，充分利用片上缓存高带宽，通过构建多级流水与重组query计算路径，实现Attention相关算子的深度融合与流水并行最大化；同时，将RoPE抽象为可融合的编码算子，结合位置编码特性重构计算逻辑与数据布局，最大化硬件缓冲利用率，完成高性能编码算子的融合实现。
|
||||
|
||||
### （三）电力领域：面向中压配网检修业务的推理优化
|
||||
|
||||
案例实施单位：中国电力科学研究院。
|
||||
|
||||
传统大模型推理在此场景中存在三大突出问题：一是推理时延过高，难以满足时效性要求（夜间窗口期完成次日计划推理，传统系统单次耗时远超窗口期）；二是长上下文处理能力不足，制约推理精度（受KV Cache显存限制，仅能截取近期部分数据，丢失设备老化规律等关键信息）；三是场景适配性差，无法应对复杂工况（常规检修、故障抢修、特殊保电等场景需求差异显著）。
|
||||
|
||||
**1) 整体方案**
|
||||
|
||||
- 模型层优化：进行MoE架构重构与轻量化改造。按配网检修核心需求拆分多个专家网络，各专家网络聚焦设备评估、故障识别等专项任务，通过门控网络动态激活2-3个相关专家网络，降低算力消耗。采用混合精度量化策略，关键层保高精度、非关键层低精度处理，同时量化压缩KV Cache并修正误差，减小模型体积与显存占用，支撑长上下文全量数据推理。
|
||||
- 推理引擎层优化：设计KV Cache多级存储架构与时序预取机制，解决显存瓶颈并降低I/O延迟；通过算子融合、硬件适配、计算复用技术加速计算；采用场景感知批处理策略，结合线路优先级调度，按常规检修、故障抢修、特殊保电场景动态调整参数。
|
||||
- 调度层优化：构建"场景感-策略匹配-资源调度"闭环机制。通过场景识别模型精准判断业务场景，基于预设"场景-推理参数"映射关系自动匹配最优参数。依托分布式推理集群，采用负荷感知动态分配策略，搭配弹性扩容机制，适配不同场景需求并应对业务波动。
|
||||
|
||||
**2) 场景适配**
|
||||
|
||||
多源数据适配：针对配网时序运行数据、结构化台账、非结构化报告与图像等多样数据类型，开发专用预处理插件；预处理与推理引擎异步并行，缩短数据处理耗时。安全合规适配：严格遵循电力行业等保要求与监控系统安全防护规定；数据传输采用加密算法；推理结果添加数字签名；系统部署于电力专用安全区域；集成操作日志审计模块。业务流程适配：贴合检修"计划生成-审核-下发"全流程，增设针对性功能模块。推理后自动比对设备禁止检修时段，冲突时触发告警；支持运维人员可视化查看调整结果，修改后系统自动重算关联线路影响。
|
||||
|
||||
### （四）司法检察领域：检察院"数字检察"项目
|
||||
|
||||
案例实施单位：某人民检察院、华为技术有限公司。
|
||||
|
||||
某人民检察院作为智能化建设首批试点单位，致力于打造"数字检察"地标性工程，重点解决"信息孤岛"与"数据烟囱"问题，构建大数据法律监督体系。项目以高性能AI存储与昇腾算力为基础，构建覆盖智能问答、案卡填充、卷宗分析等场景的智能化平台。
|
||||
|
||||
**1) 整体方案**
|
||||
|
||||
项目整体采用"存算协同"架构，训练集群由8台800T A2昇腾服务器搭建，推理集群由8台同型号服务器与高性能AI存储OceanStorA800共同组成，并配备通用服务器、存储及数据通信设备，为检察核心数据提供统一底座支撑。方案通过CCAE等智能化管控平台实现资源池化管理，借助容器化技术封装AI应用。
|
||||
|
||||
**2) 创新情况**
|
||||
|
||||
"以存助算"架构创新：利用高性能AI存储的长记忆内存能力，在推理过程中加载缓存，避免重复计算，显著减轻算力压力，实现毫秒级响应。长序列数据处理创新：采用KV Cache缓存机制，对长卷宗等缓存数据进行分级存储，攻克长文本处理瓶颈，提升法律文书生成质量。知识库动态更新机制：引入RAG技术构建法律知识库，实时更新法律条文与判例，有效约束内容生成，消除模型"幻觉"，推动检察业务从"经验决策"向"数据驱动"转型。
|
||||
|
||||
**3) 应用实效**
|
||||
|
||||
通过该方案的实施，系统在推理阶段TTFT降低40%，吞吐量提升5倍，大幅提升了智能问答、案卡回填与卷宗分析等场景的处理效率。法律文书生成质量得到显著改善，数据处理与知识检索的精准度进一步增强。
|
||||
|
||||
### （五）农畜领域：面向农畜养殖业务的推理优化
|
||||
|
||||
案例实施单位：某养殖场、北京百度网讯科技有限公司。
|
||||
|
||||
某养殖场区每年都会发生不同程度的安全事故。为了降低风险、提升管理效率，企业希望借助视频监控与智能识别技术，对现场饲养员作业行为进行实时监测。一旦识别出违规操作，系统能够自动推送告警给现场负责人，便于第一时间干预和处置。
|
||||
|
||||
**1) 主要场景与存在问题**
|
||||
|
||||
有限空间作业防护违规（饲养员没有穿防护服或者暴露衣着作业，存在病菌感染风险）；有限空间作业违规智能养殖操作（刷圈、防疫、消毒、加水、上饲料、设备异常等）。园区几千名饲养员，每个饲养员负责千头牲畜日常、卫生打扫等。当前系统采用本地部署的多模态大模型进行视频图像识别，整体场景精度约60.99%，仍有较多延迟、漏报，无法完全满足业务对高实时性的要求。
|
||||
|
||||
**2) 整体方案**
|
||||
|
||||
本方案以智能监控饲养员作业业务特性为核心，从模型、推理引擎、调度层三大关键层面构建全链路优化方案。大模型将Prefill和Decode两推理阶段分开处理，PD分离服务部署可以提高GPU/NPU/XPU的利用率，将Prefill实例和Decode实例分开部署，减少Prefill阶段和Decode阶段分时复用在时延上造成的互相干扰，实现同时延下吞吐提升。
|
||||
|
||||
不同加速卡部署方案：GPU PD分离方案（Scheduler单Pod副本+Prefill+Decode）；XPU PD分离方案（Scheduler单Pod副本+Prefill+Decode）；NPU PD分离方案（MindIE MS Controller单Pod副本、MindIE MS Coordinator单Pod副本以及MindIE Server区分Prefill和Decode，由Mindie动态调度P进程和D进程）；P实例和D实例通过Headless Service传输KV-Cache，XPU原始方案中使用redis共享KV-Cache，由推理镜像内部闭环。
|
||||
|
||||
以NPU为例：单机PD分离服务部署方案，通过K8s的Service开放PD集群的推理入口，创建1个K8s的Deployment部署一个Pod，其中以进程方式分别部署MindIE MS Controller（单进程副本）、MindIE MS Coordinator（单进程副本）以及MindIE Server（多进程副本）。多机PD分离服务部署方案，通过K8s的Service为Coordinator Pod开放PD集群的推理入口，创建3个K8s的Deployment分别部署MindIE MS Controller（单Pod副本）、MindIE MS Coordinator（单Pod副本）以及MindIE Server（多Pod副本）。
|
||||
|
||||
## 六、展望
|
||||
|
||||
大模型推理优化正朝着"协同化、智能化、场景化"的方向深度演进，技术突破与产业需求的深度耦合将重塑推理服务生态。未来，"模型-架构-场景"协同优化将成为核心范式，模型设计将深度融入推理友好性考量，架构创新将进一步适配不同场景的性能诉求，形成全链路优化闭环。
|
||||
|
||||
异构算力与解耦架构将走向精细化协同。以PD分离、AF分离为代表的推理解耦架构，将与擅长计算密集、访存密集等不同负载的各类硬件深度协同，通过阶段分层调度、模块异构部署，实现算力资源与任务特性的精准匹配，在提升吞吐与能效比的同时，压缩单Token推理成本。自适应调度与智能化推理将成为主流。通过结合SLO的资源配置、并行策略调整及缓存管理，实现负载波动下的自动适配与性能稳定，大幅减少人工干预。
|
||||
|
||||
多模态与长序列推理优化将迎来突破，KV Cache高效管理、跨模态数据协同计算、长序列并行处理等技术创新，将打破当前应用边界，支撑更复杂的智能体交互、超长文档分析等场景落地。同时，性能评估与优化的标准化进程将加速，形成统一的指标体系与测试规范，为产业发展提供有序指引。
|
||||
|
||||
整体来看，大模型推理优化将推动AI服务从"能用"向"好用、省用"跨越，成为赋能千行百业数字化转型的核心引擎。
|
||||
|
||||
## 编制说明
|
||||
|
||||
本研究报告自2025年9月启动编制，分为前期研究、框架设计、文稿起草、征求意见和修改完善五个阶段。面向大模型推理基础设施的技术提供方和应用方开展了深度访谈和调研等工作。
|
||||
|
||||
本报告由中国信息通信研究院人工智能研究所撰写，撰写过程中得到了中国人工智能产业发展联盟、华为技术有限公司、中移九天人工智能科技（北京）有限公司、中国电信股份有限公司研究院、中国电力科学研究院有限公司、北京百度网讯科技有限公司、杭州华电能源工程有限公司、京东科技信息技术有限公司、中电信人工智能科技（北京）有限公司、蚂蚁科技集团股份有限公司、北京大学、北京航空航天大学、之江实验室、济南浪潮数据技术有限公司、山东省科学院高新技术产业（中试）基地、北京矩量无限科技有限公司、北京焱融科技有限公司、是石科技（平湖）有限公司、星环信息科技（上海）股份有限公司等单位的大力支持。
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：大模型推理优化关键技术与应用实践研究报告（2026年）
|
||||
|
||||
> **原文**：[2026-03-31_大模型推理优化关键技术与应用实践研究报告_2026年.md](./2026-03-31_大模型推理优化关键技术与应用实践研究报告_2026年.md)
|
||||
> **原文链接**：https://www.caict.ac.cn/kxyj/qwfb/ztbg/202604/P020260415615308750699.pdf
|
||||
> **来源**：中国信通院
|
||||
> **作者**：中国信息通信研究院人工智能研究所
|
||||
> **发布日期**：2026-03-31
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **协同优化** — 推理优化从单点技术走向"模型-引擎-系统"全链路、以 SLO 为约束的协同优化，PD 分离、AF 分离与 KV Cache 多级存储成为主流架构范式。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本报告系统梳理大模型推理优化的全景：推理已取代训练成为落地焦点（ChatGPT 企业版 API Token 消耗 12 个月暴增 320 倍，平均序列长度两年增长 32 倍至 128K）；将推理优化定义为在保障 SLO 前提下兼顾"效果-性能-成本"的全链路工程，提出模型（压缩、MoE、算法创新）、引擎（显存、计算、并行、批调度）、系统（PD 分离、AF 分离、调度策略、高性能存储）三级优化体系；梳理 PD 分离演进脉络（DistServe→Splitwise→TetriInfer→MemServe）与 Mooncake、Dynamo、UCM 及 DeepSeek、MegaScale-Infer、Step-3 等工业级方案的实测数据，并附金融、运营商、电力、司法、农畜五类落地案例。权威性与体系性是最大价值；局限在于案例数据多由方案提供方自报，前瞻数据预测成分较高。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **推理成为落地焦点** — ChatGPT 企业版 API Token 消耗 12 个月暴增 320 倍；2026 年推理占计算工作负载 66%，中国推理算力市场规模 876.5 亿元（近翻倍）`[分类: 共识]`
|
||||
2. **推理优化的定义与目标** — SLO 前提下"效果-性能-成本"多目标协同，贯穿"压缩-部署-推理-服务"四个环节；当前处于第二、第三阶段（单点提效→协同优化）`[分类: 共识]`
|
||||
3. **三级优化体系** — 模型层（量化/蒸馏/MoE/MLA 低秩压缩）、引擎层（PagedAttention 并发 +3 倍、FlashAttention、混合并行、连续批处理、Chunked-Prefills）、系统层（PD/AF 分离、调度、多级存储）`[分类: 共识]`
|
||||
4. **PD 分离架构** — 预填充计算密集（GEMM、TTFT）、解码存储密集（GEMV、TBT），"阶段解耦、专用部署、并行调度"；三大挑战：KV Cache 跨节点传输开销、解码阶段显存压力、缓存协同复杂 `[分类: 共识]`
|
||||
5. **AF 分离架构** — 将 MoE 的 Attention 模块（访存密集）与 Feedforward 模块（计算密集）拆分至异构节点独立扩展，标志系统架构从阶段分治迈向模块分治 `[分类: 范式突破]`
|
||||
6. **工业级方案实测** — Mooncake（月之暗面）有效吞吐 +75%、长上下文最高 +525%；Dynamo（英伟达）四级存储+SLO-based Planner；UCM（华为）TTFT 最高降 90%、吞吐最大提升 22 倍；DeepSeek 推理成本利润率 545%；MegaScale-Infer 单 GPU 解码吞吐较 vLLM 提升 7.11 倍、单位成本吞吐 +224%；Step-3 每百万 token 成本 0.055 美元，为 DeepSeek-V3 的 80% `[分类: 争议]`（指标均出自方案提供方）
|
||||
7. **KV Cache 多级存储** — HBM-DRAM-SSD 三级动态架构，"以存换算"；落地挑战：跨层级一致性、存储带宽数量级差异导致的 I/O 瓶颈 `[分类: 共识]`
|
||||
8. **行业案例验证** — 金融（长文档 KV 预热、80K 压缩至 16K、30 并发 TTFT 降 66%）、运营商（训推一体+PD 分离单卡吞吐翻倍）、电力（MoE 重构+场景感知调度）、司法（TTFT 降 40%、吞吐提升 5 倍）、农畜（PD 分离多卡适配）`[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设推理需求持续指数增长且 GPU 显存稀缺长期存在；假设模型架构沿 MoE、长上下文、多模态方向演进不变；假设"效果-性能-成本"可通过工程手段协同平衡。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
行业数据与案例丰富且有出处，技术链条完整；但案例指标多由方案提供方（华为、九天、百度等）自报，缺乏独立第三方复测，"成本利润率 545%"等数字依赖特定定价假设；对前沿方案（AF 分离）的成熟度与普适性未做充分质疑。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
报告为产业综述性质，适合作为技术地图而非直接结论；案例以头部厂商为主，中小团队的可复制性存疑；市场规模、价格等前瞻数据随时间衰减，引用需注明时点。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "大模型推理作为人工智能技术从实验室走向产业应用的'最后一公里'，承载着将模型能力转化为实际业务价值、平衡服务质量与成本投入的核心使命。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 首次系统性构建"模型-引擎-系统"三级优化体系与四阶段演进框架，全景式覆盖推理优化技术栈
|
||||
- PD 分离演进脉络与工业级方案（Mooncake/Dynamo/UCM/MegaScale-Infer/Step-3）实测数据详实，可直接指导选型
|
||||
- 明确指出现有方案的三大挑战与多级存储落地难点，边界意识强
|
||||
- 五类行业案例覆盖金融、运营商、电力、司法、农畜，验证落地价值
|
||||
|
||||
**不足**：
|
||||
- 案例与方案指标多出自提供方自报，缺少独立验证
|
||||
- 对 AF 分离等前沿范式的争议面讨论不足
|
||||
- 部分前瞻数据（市场规模、消耗量）预测成分较高
|
||||
|
||||
**适用场景**：推理基础设施规划者、技术决策者、行业研究者；作为理解推理优化技术栈与产业路线的权威参照地图。
|
||||
|
||||
**关联建议**：对照 NVIDIA Dynamo 博客与 Mooncake 开源项目获取一手工程细节；结合 Introl 推理经济学验证成本数据；关注信通院后续报告以追踪四阶段演进中"深度融合"阶段的进展。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# [中邮证券]：底座算力跃迁到token工厂的新机会
|
||||
|
||||
> **来源**：中邮证券
|
||||
> **作者**：孙业亮、刘聪颖
|
||||
> **发布日期**：2026-06-16
|
||||
> **原文链接**：https://www.fxbaogao.com/detail/5481471
|
||||
|
||||
---
|
||||
|
||||
行业投资评级：强于大市 | 维持
|
||||
|
||||
孙业亮 / 刘聪颖，中邮证券研究所计算机团队
|
||||
|
||||
发布时间：2026-06-16
|
||||
|
||||
## 投资要点
|
||||
|
||||
- **算力需求爆发式增长，全球竞争日益激烈**：随着人工智能、大数据、工业互联网等数字化技术规模化应用，全球算力需求高速增长；据中国信通院数据，截至2024年底，全球通算规模达628EFlops，同比增加14.0%，智算规模达5693EFlops，同比增加64.7%；据IDC预测，2025年全球人工智能服务器市场规模为1587亿美元，2028年有望达到2227亿美元。
|
||||
- **Token经济正在开展一场智能定价革命**：根据全球最大AI模型API聚合平台OpenRouter最新数据显示，3月16日至22日，全球AI大模型总Token调用量为20.4万亿，仅中国就达7.359万亿，占全球的36%，Token是其关键的主角之一。与传统算力租赁模式不同，"Token工厂"交付的不是算力时间，而是经深度优化后产出的智能单位Token，这不仅是技术升级，更是商业模式与价值分配的重构。
|
||||
- **投资建议**：建议关注1）AI基础设施：海光信息、寒武纪、中科曙光、浪潮信息、禾盛新材、协创数据等；2）AIDC厂商：润泽科技、东阳光、光环新网、数据港、奥飞数据、大位科技、豫能控股、世纪互联等；3）算力租赁厂商：宏景科技、润建股份、东方国信、首都在线等；4）运营商与云计算：中国电信、中国移动、中国联通、网宿科技、彩讯股份、优刻得等。
|
||||
- **风险提示**：行业竞争加剧风险；下游应用需求不及预期风险；Token价格大幅波动风险等。
|
||||
|
||||
## 大模型驱动算力需求指数级增长
|
||||
|
||||
**AI高速发展推动各行业数智化转型，全球算力需求高速增长。** 大模型正呈现由训练主导向训练与推理并重，由中心集聚向分布协同演进，训练与推理环节对算力双重刚需，显著推动智能算力基础设施踏上快速发展轨道；此外，用户对智能算力服务的诉求也由获取底层资源转向获取任务能力、结果交付与普惠化服务。据中国信通院数据，截至2024年底，全球通算规模达628 EFlops，同比增加14.0%；智算规模达5693 EFlops，同比增加64.7%。
|
||||
|
||||
**智能体带来AI应用革命，算力需求的重点正从训练侧逐步转向推理侧。** 智能体需要持续感知环境、反复调用工具、不断生成结果，并与用户进行多轮交互，以Open Claw为代表的各类智能体应用加速涌现，推动AI产业迈向"应用落地"与"规模化服务"新阶段。据IDC数据，中国企业活跃智能体数量将在2031年突破3.5亿规模，年复合增长率达到135%以上，这一增速将领先全球主要市场；同时，由于智能体任务执行密度的增长和任务复杂度的提升，也将带来智能体Token消耗年均超30倍的指数级跃升。（资料来源：IDC咨询公众号，中邮证券研究所）
|
||||
|
||||
**政策层面已明确路线图与时间表：** 国务院印发的《关于深入实施人工智能+行动的意见》提出，到2027年新一代智能终端、智能体等应用普及率超过70%，人工智能在公共治理中的作用明显增强，到2030年提升至90%以上；工信部等八部门联合印发的《"人工智能+制造"专项行动实施意见》，明确到2027年将推动3-5个通用大模型在制造业深度应用，培育1000个高水平工业智能体，打造100个工业领域高质量数据集，推广500个典型应用场景，培育2-3家具有全球影响力的生态主导型企业和一批专精特新中小企业；地方政府同步跟进部署，面向制造业、金融、政务、医疗等重点领域，加快智能体产业布局。（资料来源：工信部官网，中邮证券研究所）
|
||||
|
||||
**海外AI资本开支快速增长：** 微软、谷歌等美国科技巨头纷纷加大资本开支，特别是在GPU采购、数据中心、电力上的投入，大模型训练成本极高，导致只有头部云服务商和AI公司能负担，早期积累的模型质量、用户数据和算力规模会形成"马太效应"，谁在大模型和应用生态中占领先机，就会获得巨大战略优势。
|
||||
|
||||
**中国正快速实现追赶：** 腾讯表示，今年下半年AI相关的资本支出会进一步增加；阿里表示，未来AI基建相关投入资金会远远超过3800亿；字节计划2026年资本支出将超过2000亿元人民币，较此前的初步计划增加了25%。
|
||||
|
||||
**Token消耗快速增长：** Token（词元）是连接技术供给与商业需求的"结算单位"，到2026年3月，我国日均Token调用量已超过140万亿，较2024年初增长了1000多倍，标志着AI发展已进入以推理和应用为核心的快速增长阶段；智能时代Token成为核心生产要素，伴随着智能体应用爆发，其需求呈指数级增长，预计2030年中国日均消耗Token量将达万万亿级，AI基础设施变得愈加重要。据IDC预测，2026年中国MaaS市场的Token消耗量将达到约4万万亿次，营收规模约186亿元，2024-2030年的年复合增长率约为1154.9%。
|
||||
|
||||
## Token工厂重构算力商业模式
|
||||
|
||||
**"Token工厂"重塑价值产出：** 作为大模型处理信息的最小单元，Token具备可计量、可定价、可交易的特性，既是AI服务的基本结算单元，也正成为数字经济的核心"能源"，"Token工厂"是高效连接起算力、模型与应用的枢纽；与传统算力租赁模式不同，"Token工厂"交付的不是算力时间，而是经深度优化后产出的智能单位Token，这不仅是技术升级，更是商业模式与价值分配的重构。未来智算中心竞争不只是芯片之争，更是软件、网络、能源、运营和生态的综合竞争。Token工厂正在把数据中心从基础设施行业推向制造业，而制造业的核心从来不是规模，而是效率。
|
||||
|
||||
**Token的经济成本可拆解为资本性开支和运营性开支两部分：** 训练阶段以CAPEX主导，是一次性的重资本密集投入；推理阶段以OPEX主导，是随Token规模扩张的持续性边际成本。
|
||||
|
||||
- **训练阶段CAPEX主导固定成本：** 训练一个千亿参数级别的通用大模型，全流程需驱动数万张高端GPU连续运转数月，总成本约1-5亿美元；成本结构中，硬件折旧与高端研发人力薪酬合计占比超95%，电力消耗不足5%；单位Token摊销额随Token总产出增加而持续递减，构成Token规模经济的根本来源。
|
||||
- **推理阶段OPEX主导边际成本：** AI大模型一旦部署，每产生新Token，都需消耗固定的算力与电力，形成与Token调用量高度正相关的可变成本，其中电力成本通常占到OPEX总额的60%-70%，是最大单项开支，电力作为Token推理阶段主体边际成本的地位凸显。
|
||||
|
||||
**Token的定价锚逐渐从GPU→能源→人才方向转移：** Token的生产成本由芯片、电力、数据与人才四大要素构成，在不同阶段，决定Token价格底线的关键要素并不相同，定价权会沿着技术演进的节奏在四大要素之间逐步让渡。
|
||||
|
||||
- **当前阶段芯片是主锚：** 高端GPU供不应求，芯片的可获取性直接决定了Token的供给量与价格；
|
||||
- **中期来看电力将成为硬性约束：** 电力受物理定律限制，随着AI数据中心能耗激增，能源成本将成为不可压缩的底线；
|
||||
- **长期来看人才与知识密度将主导定价：** 大模型能力越强、在高端场景中为用户带来的边际收益越高，Token的溢价空间就越大。
|
||||
|
||||
**海外三巨头OpenAI、Google、Anthropic均采用"输入/输出双轨Token计费"，核心依靠产品分层与生态协同盈利。**
|
||||
|
||||
- **OpenAI用分层价格锁定全层级客户，依靠生态壁垒竞争：** GPT系列采用阶梯化价值定价，高端推理模型保持高溢价，轻量微型模型小幅让利吸引开发者；其中，旗舰GPT-5.5每百万输入Token 5美元、输出30美元，面向企业复杂智能体、长周期推理任务，赚取核心利润；GPT-4o mini轻量化模型大幅下放价格，用于吸纳C端应用、小型开发者，构建全球最大开发者生态；收入结构不单一依赖Token计费，还叠加ChatGPT订阅、企业席位、智能体会话时长、文件存储等增值服务。
|
||||
- **Google进行云生态捆绑，将Token作为GCP的导流工具：** Google不单独售卖大模型API，而是将Gemini全套Token能力与GoogleCloud深度打包，Token定价拥有全行业最宽价格区间，从Flash-Lite超低价版本到3.1 Pro高端模型全覆盖；低价轻量模型补贴云业务，高端推理算力绑定政企云订单，依托搜索增强、多模态原生能力，把Token消耗转化为云存储、算力集群、容器服务增值收入；Token是云计算的增值配套，AI业务目标是拉动GCP整体市占提升。
|
||||
- **Anthropic坚持品质定价：** 依靠超长上下文、企业级数据安全、合规能力建立品牌溢价；其中，主力Sonnet 4.6每百万输入3美元、输出15美元，旗舰Opus 4.6则定价翻倍，瞄准金融、法律、政务高敏感企业客户，不比拼调用总量，只为对数据安全、推理精度有刚性需求的企业提供服务，天然避开同质化低价竞争；此外还推出智能体会话按时长计费、分层缓存定价，跳出单纯按Token收费的单一模式。
|
||||
|
||||
**随着MaaS与Token成为行业共识，头部厂商悉数重兵入场，竞争焦点也从规模化消耗Token，转向高质量、高效率、高价值消耗Token。**
|
||||
|
||||
- **阿里Token Foundry：** 今年3月阿里已推出Alibaba Token Hub事业群，搭建"创造-分发-应用"词元基础框架；时隔三月升级为Token Foundry事业部，定位完成全面跃迁，不再单纯标准化输出通用词元，而是根据电商、零售、本地生活、企业办公等不同场景，定制推理链路、优化词元结构、搭建专属Agent词元工作流；同样一组词元，在通用对话仅产生流量，在阿里本地生活智能体可完成商家运营、订单调度、用户服务全流程，直接带来营收增量，以此重构词元定价逻辑，对冲行业低价内卷带来的毛利压力。
|
||||
- **字节：** 一方面，Seed团队持续攻坚技术极限，打造视频生成、图像创作、代码编程、文本理解等全领域SOTA标杆模型，不断刷新模型能力上限；另一方面，火山引擎也将技术能力加速工具化、产品化，高效推向市场；Token价格必须与模型能力、产出价值绑定，即使单Token理论成本可能更高，但创造的经济价值要同步提升，要提升Token能力，并确保定价优势。
|
||||
- **华为数字能源Token Factory：** 与阿里聚焦上层模型、场景应用的Token Foundry形成鲜明对照，华为数字能源从AIDC算力基础设施维度，定义产业底层的Token Factory；传统数据中心是存储数据的电子仓库，而新一代智算中心是工业化量产词元的专属工厂，电力作为生产原料，昇腾算力集群、液冷供电、储能系统作为生产设备，持续稳定输出标准化、可计量的推理词元；华为Token Factory不绑定单一厂商大模型，是中立的算力基础设施底座，无论阿里Token Foundry、华为云盘古大模型，还是第三方企业MaaS平台，均可接入华为AIDC词元工厂获取规模化算力供给。
|
||||
- **腾讯：** 将原隶属于腾讯云的MaaS大模型服务平台升级为"TokenHub"，升级后的TokenHub支持通过API调用混元、DeepSeek、MiniMax等主流大模型，并提供Token Plan统一计费。
|
||||
- **五象云谷词元（Token）工厂：** 基础层，五象云谷智算中心总算力规划40000P，为Token生产提供坚实的算力底座；平台层，算力调度+模型优化+算法加速，三重技术协同发力，通过异构算卡细粒度虚拟化、队列抢占机制与自研算法加速引擎，大幅提升Token吞吐量，将单位生产成本极致压榨，降低Token单位成本；服务层，Token管理平台集成API接口（注：原文此页内容到此截断）。
|
||||
@@ -0,0 +1,79 @@
|
||||
# 📊 文章摘要：[中邮证券]：底座算力跃迁到token工厂的新机会
|
||||
|
||||
> **原文**：[2026-06-16_中邮证券_底座算力跃迁到token工厂的新机会.md](./2026-06-16_中邮证券_底座算力跃迁到token工厂的新机会.md)
|
||||
> **原文链接**：https://www.fxbaogao.com/detail/5481471
|
||||
> **来源**：中邮证券
|
||||
> **作者**：孙业亮、刘聪颖
|
||||
> **发布日期**：2026-06-16
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **Token 工厂** — 算力商业模式从"租赁时间"转向"交付 Token"，定价锚沿"GPU→能源→人才"迁移，Token 成为智能时代的核心结算单位。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
中邮证券研报认为，AI 算力需求正从训练侧转向推理侧，Token 成为连接技术供给与商业需求的"结算单位"（2026 年 3 月我国日均 Token 调用量超 140 万亿，较 2024 年初增长 1000 多倍）；"Token 工厂"交付的是经深度优化产出的智能单位 Token 而非算力时间，是商业模式与价值分配的重构。报告拆解成本结构：训练 CAPEX 主导（千亿参数总成本 1-5 亿美元），推理 OPEX 主导（电力占 60-70%），并梳理 OpenAI/Google/Anthropic 计费策略与阿里 Token Foundry、华为 Token Factory、腾讯 TokenHub 等国内布局，给出投资建议与风险提示。局限：研报本质是荐股材料，预测数据激进、技术论证浅。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Token 成为结算单位** — 2026 年 3 月我国日均 Token 调用超 140 万亿、较 2024 年初增长 1000 多倍；OpenRouter 统计中国 Token 调用占全球 36%；预计 2030 年达万万亿级 `[分类: 争议]`（长期预测无公开模型支撑）
|
||||
2. **Token 工厂模式** — 交付智能单位 Token 而非算力时间，把数据中心从基础设施行业推向制造业，核心是效率而非规模 `[分类: 范式突破]`（作者主张，论证尚浅）
|
||||
3. **成本结构拆解** — 训练阶段 CAPEX 主导：千亿参数模型总成本 1-5 亿美元，硬件折旧与人力超 95%、电力不足 5%；推理阶段 OPEX 主导：电力占 60%-70% 为最大单项开支 `[分类: 共识]`
|
||||
4. **定价锚转移** — 当前芯片可获取性决定 Token 供给与价格；中期电力成为物理硬约束；长期人才与知识密度主导溢价 `[分类: 争议]`
|
||||
5. **海外三巨头计费策略** — OpenAI 分层定价+生态壁垒（GPT-5.5 输入 5/输出 30 美元）、Google 云捆绑把 Token 作为 GCP 导流工具、Anthropic 品质定价（Sonnet 4.6 输入 3/输出 15 美元）避开低价竞争 `[分类: 共识]`
|
||||
6. **国内玩家布局** — 阿里 Token Foundry 按场景定制词元工作流、华为 Token Factory 定位中立算力底座（昇腾+液冷+储能）、腾讯 TokenHub 统一计费、五象云谷 40000P 规划 `[分类: 争议]`（厂商布局是事实，商业模式有效性未验证）
|
||||
7. **投资建议与风险** — 关注 AI 基础设施、AIDC、算力租赁、运营商与云计算四类标的；风险为行业竞争、需求不及预期、Token 价格波动 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 Token 需求按指数持续增长（智能体 Token 消耗年均超 30 倍）；假设算力供给长期紧张使"工厂"模式有利可图；假设 Token 可成为标准化的计量与结算单位。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
数据多引自信通院、IDC、OpenRouter 与公司公告，属事实层面；但"2030 年万万亿级""CAGR 1154.9%"等核心预测缺乏公开测算过程，"Token 工厂"与既有算力租赁模式的本质差异也未做严格定义与论证；投资标的推荐体现荐股立场，观点有选择性呈现。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
研报服务投资决策而非工程决策，技术细节极少；对 Token 价格战压缩毛利、需求不及预期的风险提示泛泛；"Token 工厂"叙事包含营销包装成分，其商业可行性（成本回收、定价权）尚无公开验证。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Token工厂正在把数据中心从基础设施行业推向制造业，而制造业的核心从来不是规模，而是效率。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- "Token 工厂"与"定价锚 GPU→能源→人才"提供了理解推理经济的产业视角
|
||||
- 成本结构拆解（CAPEX/OPEX、电力占比）与三巨头计费策略梳理有信息价值
|
||||
- 国内厂商布局盘点及时，适合快速把握产业动向
|
||||
|
||||
**不足**：
|
||||
- 荐股立场导致观点选择性呈现，预测数据激进且缺测算依据
|
||||
- 技术论证浅，不适合工程参考
|
||||
- "Token 工厂"概念定义模糊，与算力租赁的差异未严格论证
|
||||
|
||||
**适用场景**：产业趋势认知、商业分析师、AI 厂商战略与投资相关人士；不适用于技术选型。
|
||||
|
||||
**关联建议**：对照 Introl 推理经济学文章验证成本结构数据；对照信通院报告了解 Token 背后推理优化的技术现实；关注阿里/华为 Token 工厂后续公开财报与案例验证商业模式。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
# KV Cache 缓存可卸载至 SSD：打破内存墙限制，AI SSD迎来广阔成长空间
|
||||
|
||||
> **来源**：发现报告
|
||||
> **作者**：国泰海通证券
|
||||
> **发布日期**：2025-10-28
|
||||
> **原文链接**：https://www.fxbaogao.com/detail/5116282
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
KV Cache缓存可卸载至SSD
|
||||
|
||||
本报告导读：
|
||||
|
||||
- 半导体《AI发展，热管理的核心瓶颈向芯片聚焦》2025.10.06
|
||||
- 半导体《商务部发起模拟IC反倾销调查，国产替代加速》2025.09.14
|
||||
- 半导体《下一代英伟达Rubin CPX内存升级》2025.09.11
|
||||
- 半导体《中芯国际拟发行A股购买中芯北方49%少数股权》2025.08.31
|
||||
- 半导体《3D DRAM：云侧内存市场重要竞争者》2025.08.23
|
||||
|
||||
针对大语言模型（LLM）发展中面临的"内存墙"难题，基于SSD的存储卸载技术方案可为AI模型高效运行提供新路径。
|
||||
|
||||
投资要点：
|
||||
|
||||
推理KV Cache容量增长超出HBM承载能力。键值缓存（KV Cache）技术可以优化计算效率、减少重复运算，即将已生成token的Key和Value临时存储起来，后续生成新token时直接复用，无需重新计算，显著提升推理效率。然而，KV Cache需要占用GPU的显存（如HBM），存储历史Key/Value向量，生成的文本越长，缓存数据量越大，可能导致HBM和DRAM超载。面对大模型PB级的天量数据，传统推理架构过度依赖HBM的瓶颈也日益凸显。随着Agentic AI时代到来，模型规模化扩张、长序列需求激增以及推理任务并发量增长，推理的KV Cache容量增长已超出HBM的承载能力，频繁的内存溢出，需要GPU反复计算，造成卡顿迟缓。KV Cache缓存可从GPU内存offload至CPU、SSD。随着推理性
|
||||
|
||||
能的重要性不断提升，业界均在探索KV Cache分级缓存管理技术。如英伟达今年5月推出了分布式推理服务框架Dynamo，支持将KVCache缓存从GPU内存卸载到CPU、SSD甚至网络存储，解决大模型显存瓶颈，避免重复计算。其中，KVBM提供G1-G4（GPU memory、CPU host memory、SSD、远端存储)的KV Cache卸载，避免大量KVCache重计算。2025开放数据中心大会之新技术与测试（存储）分论坛中，三星电子高级项目经理针对大语言模型（LLM）发展中面临的"内存墙"难题，提出基于SSD的存储卸载技术方案，为AI模型高效运行提供新路径。三星将KV Cache卸载至NVMe SSD。当KV Cache大小超过HBM或DRAM容量时，该方案可使首token延迟（TTFT）最高降低66%，token间延迟（ITL）最高降低42%，且支持多用户多轮对话场景下的KV Cache重用，随着用户与对话轮次增加，I/O吞吐量稳步上升，主要I/O模式为256KB读写。
|
||||
|
||||
AI存储需求激发HDD替代效应，NAND Flash供应商加速转进大容量Nearline SSD。根据TrendForce集邦咨询，AI推理应用快速推升实时存取、高速处理海量数据的需求，促使HDD与SSD供应商积极扩大供给大容量存储产品。由于HDD市场正面临巨大供应缺口，激励NAND Flash业者加速技术转进，投入122TB、甚至245TB等超大容量Nearline SSD的生产。
|
||||
|
||||
风险提示：国产替代进程不及预期；技术迭代不及预期。
|
||||
|
||||
本公司具有中国证监会核准的证券投资咨询业务资格
|
||||
|
||||
分析师声明
|
||||
|
||||
作者具有中国证券业协会授予的证券投资咨询执业资格或相当的专业胜任能力，保证报告所采用的数据均来自合规渠道，分析逻辑基于作者的职业理解，本报告清晰准确地反映了作者的研究观点，力求独立、客观和公正，结论不受任何第三方的授意或影响，特此声明。
|
||||
|
||||
免责声明
|
||||
|
||||
本报告仅供国泰海通证券股份有限公司（以下简称"本公司"）的客户使用。本公司不会因接收人收到本报告而视其为本公司的当然客户。本报告仅在相关法律许可的情况下发放，并仅为提供信息而发放，概不构成任何广告。
|
||||
|
||||
本报告的信息来源于已公开的资料，本公司对该等信息的准确性、完整性或可靠性不作任何保证。本报告所载的资料、意见及推测仅反映本公司于发布本报告当日的判断，本报告所指的证券或投资标的的价格、价值及投资收入可升可跌。过往表现不应作为日后的表现依据。在不同时期，本公司可发出与本报告所载资料、意见及推测不一致的报告。本公司不保证本报告所含信息保持在最新状态。同时，本公司对本报告所含信息可在不发出通知的情形下做出修改，投资者应当自行关注相应的更新或修改。
|
||||
|
||||
本报告中所指的投资及服务可能不适合个别客户，不构成客户私人咨询建议。在任何情况下，本报告中的信息或所表述的意见均不构成对任何人的投资建议。在任何情况下，本公司、本公司员工或者关联机构不承诺投资者一定获利，不与投资者分享投资收益，也不对任何人因使用本报告中的任何内容所引致的任何损失负任何责任。投资者务必注意，其据此做出的任何投资决策与本公司、本公司员工或者关联机构无关。
|
||||
|
||||
本公司利用信息隔离墙控制内部一个或多个领域、部门或关联机构之间的信息流动。因此，投资者应注意，在法律许可的情况下，本公司及其所属关联机构可能会持有报告中提到的公司所发行的证券或期权并进行证券或期权交易，也可能为这些公司提供或者争取提供投资银行、财务顾问或者金融产品等相关服务。在法律许可的情况下，本公司的员工可能担任本报告所提到的公司的董事。
|
||||
|
||||
市场有风险，投资需谨慎。投资者不应将本报告作为作出投资决策的唯一参考因素，亦不应认为本报告可以取代自己的判断。在决定投资前，如有需要，投资者务必向专业人士咨询并谨慎决策。
|
||||
|
||||
本报告版权仅为本公司所有，未经书面许可，任何机构和个人不得以任何形式翻版、复制、发表或引用。如征得本公司同意进行引用、刊发的，需在允许的范围内使用，并注明出处为"国泰海通证券研究"，且不得对本报告进行任何有悖原意的引用、删节和修改。
|
||||
|
||||
若本公司以外的其他机构（以下简称"该机构"）发送本报告，则由该机构独自为此发送行为负责。通过此途径获得本报告的投资者应自行联系该机构以要求获悉更详细信息或进而交易本报告中提及的证券。本报告不构成本公司向该机构之客户提供的投资建议，本公司、本公司员工或者关联机构亦不为该机构之客户因使用本报告或报告所载内容引起的任何损失承担任何责任。
|
||||
|
||||
评级说明
|
||||
|
||||
投资建议的比较标准
|
||||
|
||||
投资评级分为股票评级和行业评级。
|
||||
|
||||
以报告发布后的12个月内的市场表现为比较标准，报告发布日后的12个月内的公司股价（或行业指数）的涨跌幅相对同期的沪深300指数涨跌幅为基准。
|
||||
|
||||
国泰海通证券研究所
|
||||
|
||||
地址上海市黄浦区中山南路888号
|
||||
@@ -0,0 +1,75 @@
|
||||
# 📊 文章摘要：KV Cache 缓存可卸载至 SSD：打破内存墙限制，AI SSD 迎来广阔成长空间
|
||||
|
||||
> **原文**：[2025-10-28_KV_Cache_缓存可卸载至_SSD_打破内存墙限制_AI_SSD迎来广阔成长空间.md](./2025-10-28_KV_Cache_缓存可卸载至_SSD_打破内存墙限制_AI_SSD迎来广阔成长空间.md)
|
||||
> **原文链接**：https://www.fxbaogao.com/detail/5116282
|
||||
> **来源**：发现报告（转载国泰海通证券研报）
|
||||
> **作者**：国泰海通证券
|
||||
> **发布日期**：2025-10-28
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐ 低
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **SSD 破墙** — KV Cache 卸载至 SSD 缓解"内存墙"，打开 AI SSD 板块成长空间。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
国泰海通证券半导体行业快评，提出"推理 KV Cache 容量增长超出 HBM 承载能力，缓存可卸载至 CPU/SSD，AI SSD 迎来广阔成长空间"的投资观点。论据有二：英伟达今年 5 月发布的 Dynamo 框架支持 KV Cache 从 GPU 卸载到 CPU、SSD 甚至网络存储（KVBM 提供 G1—G4 四级卸载）；三星在 2025 开放数据中心大会提出的 SSD 卸载方案显示，KV Cache 超容时 TTFT 最高降 66%、ITL 最高降 42%，支持多轮对话 KV 复用，主 I/O 模式为 256KB 读写。叠加 TrendForce 数据（HDD 供应缺口促使 NAND 厂商转产 122TB/245TB Nearline SSD），推导出 AI 存储需求红利。全文篇幅短、论据少，属题材驱动的投资线索而非深度研究。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **内存墙与 KV Cache 超载** — Agentic AI 时代模型规模化、长序列与并发增长使 KV Cache 超出 HBM 承载，频繁内存溢出导致 GPU 反复重算 `[分类: 共识]`
|
||||
2. **分级卸载成为行业方向** — 英伟达 Dynamo/KVBM 支持 G1—G4（GPU 显存/CPU 内存/SSD/远端存储）四级 KV Cache 卸载；业界均在探索分级缓存管理 `[分类: 共识]`
|
||||
3. **三星 SSD 卸载的量化收益** — KV Cache 超容时 TTFT 最高降 66%、ITL 最高降 42%，多用户多轮对话下 KV 重用使 I/O 吞吐稳步上升 `[分类: 共识]`
|
||||
4. **HDD 缺口催化 NAND 转产** — 据 TrendForce，HDD 供应缺口激励 NAND 厂商投入 122TB、245TB 超大容量 Nearline SSD 生产 `[分类: 共识]`
|
||||
5. **投资结论与风险** — AI 推理需求推升实时存取与高速处理需求，AI SSD 供应商受益；风险提示为国产替代与技术迭代不及预期 `[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 KV Cache 卸载至 SSD 会被行业大规模采用——而 HBM 扩容、CXL 内存池化、远端 DRAM 等替代路线可能分流需求；假设三星案例的收益数据可外推为 SSD 出货增长；假设 Nearline SSD 需求主要由 AI 推理驱动。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据单薄：核心证据仅三星一个案例与 TrendForce 一条产业数据，且均为转述、无原始报告细节；从"存在卸载技术"到"AI SSD 广阔成长空间"之间缺少市场规模测算、渗透率假设与竞争格局分析，论证链存在明显跳跃。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
属半导体行业快评，面向投资决策而非技术读者；未讨论卸载方案的延迟代价、网络带宽瓶颈与 Dynamo 生态成熟度等不确定性；风险提示仅两句格式化文字，未覆盖核心假设的证伪条件（如卸载路线被 CXL/远端 DRAM 取代）。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "KV Cache缓存可从GPU内存offload至CPU、SSD。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 用最短篇幅把"KV Cache 卸载"技术趋势与"AI SSD"投资主题挂钩，题材时效性好
|
||||
- 引用了英伟达 Dynamo 与三星方案这两个 2025 年最新行业动向，信息点有参考价值
|
||||
|
||||
**不足**：
|
||||
- 论据与论证深度不足，缺市场规模、供应链与竞争分析；未讨论替代技术路线
|
||||
- 风险提示流于形式；对技术方案的工作原理与代价说明甚少
|
||||
|
||||
**适用场景**：关注 AI 存储板块的投资者快速了解题材逻辑；作为"KV Cache 卸载"技术动向的新闻式线索，细节需另行核实。
|
||||
|
||||
**关联建议**：核实英伟达 Dynamo KVBM 官方文档与三星发布会原始数据；对比极客公园 Tair 方案（远端存储走 3FS 而非本地 SSD）理解技术路线分歧；查阅 TrendForce 原报告确认 Nearline SSD 供需数据。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
本篇文章为低价值，未生成配图。
|
||||
@@ -0,0 +1,766 @@
|
||||
# 【大模型基础设施工程】04：互联与网络——NVLink、InfiniBand、RoCE 与国产替代
|
||||
|
||||
> **来源**：土法炼钢兴趣小组的算法知识备份
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-04-22
|
||||
> **原文链接**：https://quant67.com/post/llm-infra/04-interconnect/04-interconnect.html
|
||||
|
||||
---
|
||||
|
||||
> 算力决定上限，__互联决定利用率__。
|
||||
>
|
||||
> —— 做过万卡训练的人都懂这句话
|
||||
|
||||
在 2023 年之前，很多训练团队把精力都放在"怎么把 GPU 堆多"。到了 2024—2026 年，业界共识变了：__GPU 本身已经不是瓶颈，网络才是__。同样一批 H100，接在 3.2 Tb/s 无损 RDMA 上，训练一个 70B 模型的 MFU（Model FLOPs Utilization）能做到 50%+；接在普通 100G 以太网上，可能只有 20%，甚至跑着跑着因为 PFC 死锁挂掉。
|
||||
|
||||
这一篇就围绕__互联网络__展开，分两条主线：
|
||||
|
||||
- __Scale-up__：机内、柜内，极致带宽、极低延迟，目标是"把一堆 GPU 变成一台巨型 GPU"。代表技术：NVLink / NVSwitch / NVL72 / Infinity Fabric / HCCS / CXL。
|
||||
- __Scale-out__：跨机、跨 Pod，横向扩展到万卡、十万卡。代表技术：InfiniBand、RoCEv2、UEC、Fat-Tree、Rail-optimized、Dragonfly。
|
||||
|
||||
我们会从物理层聊到拓扑层，从 AllReduce 聊到故障域，最后给出训练工程师视角下"集合通信打不满怎么办"的排查清单，以及 `nccl-tests` 的实操。
|
||||
|
||||
## 一、为什么 LLM 训练对网络这么敏感
|
||||
|
||||
### 1.1 万卡训练的流量特征
|
||||
|
||||
传统 HPC 里，通信占比高的是 CFD、分子动力学；传统数据中心里，流量是典型的 "南北向为主 + 东西向微服务"。__LLM 训练不是这两者__，它的流量画像非常独特：
|
||||
|
||||
1. __周期性、同步、大包、突发__：一个 step 内所有 GPU 同时发起 AllReduce / AllGather / ReduceScatter，瞬时把链路打满，下一秒又全部静默。
|
||||
2. __Bandwidth-bound__：梯度、激活、KV 的传输都是几 MB 到几 GB 的大块，对带宽敏感远大于对延迟敏感（小消息 latency 影响流水线气泡，但绝大多数算子是带宽受限）。
|
||||
3. __尾延迟决定全局__：一个 step 的结束时间 = `max(所有 rank 的完成时间)`。任何一条慢链路都拖慢整体，这就是万卡训练里常说的 __"straggler 问题"__。
|
||||
4. __长连接 + 零丢包容忍__：一次 AllReduce 丢一个包触发重传，整个 step 就塌了。所以 RDMA 网络必须是__无损__或__近似无损__的。
|
||||
|
||||
### 1.2 一次 step 里的通信量
|
||||
|
||||
以 GPT-3 175B、TP=8、PP=8、DP=128（总 8192 卡）为例，粗算一个 step 的通信量：
|
||||
|
||||
- __TP AllReduce__：Attention / MLP 后每层一次，175B 模型约 96 层，每次 AllReduce 的张量大小 ~ `batch × seq × hidden × 2B`（fp16），单次几十 MB。TP 发生在__机内 NVLink__。
|
||||
- __PP 点对点__：每个 micro-batch 发送 activation，几十 MB，跨机走 __RDMA__。
|
||||
- __DP AllReduce__：梯度规模 ~ 350 GB（fp16），ZeRO-1 下切成 DP 组；跨机跨 rail，走 __RDMA AllReduce__。
|
||||
|
||||
所以训练一次 step，机内 NVLink 跑 TB 级别流量，机间 RDMA 也跑几百 GB。任何一个维度"瘸腿"，利用率立刻掉一大截。
|
||||
|
||||
## 二、Scale-up：机内与柜内互联
|
||||
|
||||
机内互联的目标很朴素：__越像一块 GPU 越好__。这意味着：高带宽、低延迟、统一地址空间、原生支持 P2P 和集合通信硬件加速。
|
||||
|
||||
### 2.1 PCIe：通用但不够用
|
||||
|
||||
PCIe 是 CPU—GPU、GPU—NIC 之间绕不开的通道。它的带宽演进：
|
||||
|
||||
| 版本 | 单 lane 带宽 | x16 双向 | 落地年份 | 代表平台 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| PCIe 4.0 | 16 GT/s | 64 GB/s | 2017 | A100、Milan |
|
||||
| PCIe 5.0 | 32 GT/s | 128 GB/s | 2022 | H100、SPR、Genoa |
|
||||
| PCIe 6.0 | 64 GT/s（PAM4） | 256 GB/s | 2024—2025 | B200、Turin、GH200 |
|
||||
| PCIe 7.0 | 128 GT/s | 512 GB/s | 2027（规划） | — |
|
||||
|
||||
问题在于：__PCIe 5.0 x16 才 64 GB/s 单向__，而 H100 单卡 HBM 带宽已经 3 TB/s，NVLink 4 是 450 GB/s 单向。让 GPU 之间只走 PCIe，等于让法拉利走乡间小路。所以训练场景里，PCIe 主要用来接 CPU、NIC、NVMe，GPU 之间一定要走 NVLink / xGMI / HCCS 这种"专用高速通道"。
|
||||
|
||||
### 2.2 NVLink 与 NVSwitch：N 卡训练的护城河
|
||||
|
||||
NVLink 是 NVIDIA 自研的 GPU 间互联协议，和 PCIe 并行存在。演进如下：
|
||||
|
||||
| 代 | 首发 GPU | 单 link 双向 | 每 GPU 总带宽 | 关键特性 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| NVLink 1 | P100（2016） | 40 GB/s | 160 GB/s | 首次替代 PCIe P2P |
|
||||
| NVLink 2 | V100（2017） | 50 GB/s | 300 GB/s | 引入 NVSwitch（DGX-2） |
|
||||
| NVLink 3 | A100（2020） | 50 GB/s | 600 GB/s | 12 links |
|
||||
| NVLink 4 | H100（2022） | 50 GB/s | 900 GB/s | 18 links，SHARP in-network |
|
||||
| NVLink 5 | B200（2024） | 100 GB/s | 1.8 TB/s | 18 links × 100G PAM4 |
|
||||
|
||||
__NVSwitch__ 是把多块 GPU 连成 all-to-all 交换网的芯片。早期 DGX-2（V100 × 16）靠 6 颗 NVSwitch 做全连接；H100 HGX 8 卡靠 4 颗 NVSwitch v3；到了 B200，NVSwitch v4 芯片带宽 7.2 TB/s。
|
||||
|
||||
#### GB200 NVL72：把一个机柜变成一块 GPU
|
||||
|
||||
这是 2024—2026 年最重要的__产品级__变化。NVL72 的结构：
|
||||
|
||||
- 18 个 compute tray，每个 tray 放 2 颗 Grace CPU + 4 颗 B200 GPU（共 72 GPU + 36 CPU）
|
||||
- 9 个 NVSwitch tray，每个 tray 2 颗 NVSwitch v4
|
||||
- 所有 72 颗 GPU 之间__全 NVLink 互联__，任意两卡 P2P 带宽 1.8 TB/s
|
||||
- 铜缆背板（copper cable cartridge），省掉 retimer 和光模块
|
||||
- 整柜 120 kW，液冷必备
|
||||
|
||||
业务价值：__72 GPU 的 TP / EP 都能塞进一个 NVLink domain__。以前 TP 只能 8，现在可以 TP=16 甚至 TP=72；MoE 的 EP 也可以一柜内搞定，跨柜只走 DP 和 PP。训练 DeepSeek-R1 这种 671B MoE 模型，NVL72 几乎是天选硬件。
|
||||
|
||||
```
|
||||
NVL72 机柜示意（简化）
|
||||
┌──────────────────────────────────────────┐
|
||||
│ Compute Tray × 18（每 tray 4 × B200） │
|
||||
│ ┌───┐ ┌───┐ ┌───┐ ... ┌───┐ │
|
||||
│ │ G │ │ G │ │ G │ │ G │ │
|
||||
│ └─┬─┘ └─┬─┘ └─┬─┘ └─┬─┘ │
|
||||
│ └─────┴─────┴─────────┘ │
|
||||
│ NVLink5 Spine（Copper Cartridge） │
|
||||
│ ┌──────────────────────────────┐ │
|
||||
│ │ NVSwitch Tray × 9（18 芯片） │ │
|
||||
│ └──────────────────────────────┘ │
|
||||
└──────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
对应的 SVG 示意图见文末。
|
||||
|
||||
### 2.3 AMD Infinity Fabric（xGMI）
|
||||
|
||||
AMD MI300X / MI325X / MI350X 用的是 __Infinity Fabric__（IF），也叫 xGMI（外部 GMI）。MI300X 单卡 7 条 IF link，每条 128 GB/s 双向，合计 ~ 896 GB/s，和 H100 一个量级。
|
||||
|
||||
MI300X 8 卡平台是全 mesh 互联（每卡到其他 7 卡各一条 link），没有独立 switch 芯片。好处是简单、低功耗；坏处是__扩不到 72 卡那种 NVL 级别__。AMD 在 MI355 / MI400 代推出类似 NVL 的 __UALink__（Ultra Accelerator Link）联盟标准，对标 NVLink。
|
||||
|
||||
### 2.4 华为昇腾 HCCS
|
||||
|
||||
华为 Atlas 900 / CloudMatrix 里，昇腾 910B / 910C 之间走 __HCCS（Huawei Cache Coherent System）__：
|
||||
|
||||
- 910B：每卡 7 条 HCCS，每条 ~ 56 GB/s，合计 ~ 392 GB/s（单向）
|
||||
- 910C：带宽翻倍
|
||||
- 单节点 8 卡全 mesh
|
||||
- 跨节点经 __HCCN__（华为高速 RDMA 网卡），逻辑上把集合通信交给 HCCL 库（对标 NCCL）
|
||||
|
||||
2024 年华为发布 __CloudMatrix 384__：一个超节点 384 颗昇腾 910C，全高速互联，对标 NVL72 但卡数更多。代价是功耗巨大，整柜 500+ kW，基本是"液冷 + 自建数据中心"的配置。
|
||||
|
||||
### 2.5 CXL：内存池化对 LLM 的意义
|
||||
|
||||
CXL（Compute Express Link）跑在 PCIe PHY 上，三种语义：
|
||||
|
||||
- __CXL.io__：对齐 PCIe
|
||||
- __CXL.cache__：设备缓存宿主机内存
|
||||
- __CXL.mem__：宿主机访问设备内存（内存扩展 / 池化）
|
||||
|
||||
对 LLM 的直接意义有限但值得关注：
|
||||
|
||||
1. __推理侧 KV cache 溢出__：CXL memory 作为 HBM/DRAM 之下的第三层，用来装长上下文的 KV。
|
||||
2. __训练侧 optimizer state offload__：ZeRO-Infinity 已经在用 NVMe，CXL 内存比 NVMe 快两个数量级，未来可能替代部分 offload 场景。
|
||||
3. __CXL 3.0 fabric__：支持 switch 和多主机共享内存池，长期看有"训练数据随取随用"的想象空间。
|
||||
|
||||
但 2026 年实际生产里，CXL 对 LLM 还是__次要角色__，因为 HBM 自己在涨容量（HBM3e 192 GB、HBM4 288 GB），短期不缺内存。
|
||||
|
||||
## 三、Scale-out：机间互联
|
||||
|
||||
Scale-up 终点是一柜（NVL72 / CM384），再往外就必须 scale-out。机间互联的两大流派：__InfiniBand__ 与 __RoCEv2__。
|
||||
|
||||
### 3.1 InfiniBand：训练网络的"黄金标准"
|
||||
|
||||
InfiniBand 自带 lossless、credit-based flow control、硬件 RDMA，几乎为 HPC 而生。速率演进：
|
||||
|
||||
| 代 | 速率 | 带宽（4X） | 年份 |
|
||||
| --- | --- | --- | --- |
|
||||
| FDR | 14 Gbps | 56 Gb/s | 2011 |
|
||||
| EDR | 25 Gbps | 100 Gb/s | 2014 |
|
||||
| HDR | 50 Gbps | 200 Gb/s | 2018 |
|
||||
| NDR | 100 Gbps | 400 Gb/s | 2022 |
|
||||
| XDR | 200 Gbps | 800 Gb/s | 2024—2025 |
|
||||
| GDR | 400 Gbps | 1.6 Tb/s | 2027 规划 |
|
||||
|
||||
NVIDIA 通过收购 Mellanox，把 IB 生态完全握在手里：__ConnectX-7 / 8、Quantum-2 / 3 交换机、SHARP（在网计算）__。SHARP 尤其关键——它把 AllReduce 的 reduction 操作下沉到交换机做，树形累加，带宽和延迟都打骨折。
|
||||
|
||||
IB 的代价：__贵，而且锁死在 NVIDIA 生态__。一套 Quantum-2 800G 方案，每端口价格是等速以太网的 2—3 倍。
|
||||
|
||||
### 3.2 RoCEv2：大厂的务实选择
|
||||
|
||||
RoCE（RDMA over Converged Ethernet）v2 跑在 UDP/IP 上，能直接用现有以太网基础设施，只要交换机支持 PFC / ECN / DCQCN 就行。国内大厂（阿里、字节、腾讯、百度）主力都是 __RoCEv2 over 以太网__，理由：
|
||||
|
||||
- __省钱__：以太网交换机白牌化程度高，同速率比 IB 便宜 30%—50%
|
||||
- __生态解耦__：不依赖 NVIDIA，换 Broadcom / Marvell / 国产芯片都行
|
||||
- __复用运维栈__：BGP / VXLAN / 监控体系全部沿用
|
||||
- __易扩展__：万卡到十万卡，以太网的可扩展性更好
|
||||
|
||||
代价是__工程门槛高__：无损以太网不是"打开 PFC 就行"，需要全链路调优 buffer、拥塞控制、哈希，否则 PFC 死锁或风暴能让整个训练崩掉。
|
||||
|
||||
### 3.3 无损网络三件套：PFC / ECN / DCQCN
|
||||
|
||||
#### PFC（Priority-based Flow Control）
|
||||
|
||||
基于 802.1Qbb。某端口某优先级 buffer 快满了，向上游发 Pause 帧暂停该优先级流量。好处是__真正零丢包__；坏处是：
|
||||
|
||||
- __head-of-line blocking__：Pause 阻塞整条链路的该优先级
|
||||
- __死锁__：拓扑成环 + 流量成环 → 所有端口互相 Pause，全局冻结。训练场景里 rail-optimized 拓扑特别容易踩这个
|
||||
- __风暴__：一个慢节点把 Pause 传导到全网
|
||||
|
||||
所以 PFC 只能作为"兜底"，不能作为"常态"。
|
||||
|
||||
#### ECN（Explicit Congestion Notification）
|
||||
|
||||
IP 头里 2 个 bit，交换机排队超过阈值就标 CE（Congestion Experienced），接收端回 CNP（Congestion Notification Packet）给发送端。发送端收到 CNP 主动降速，__在丢包和 PFC 触发之前就把流量压下来__。ECN 才是常态工作机制。
|
||||
|
||||
#### DCQCN（Data Center QCN）
|
||||
|
||||
Mellanox / NVIDIA 提出的拥塞控制算法，结合 ECN 反馈做速率调节。关键参数（NIC 侧）：
|
||||
|
||||
- `Rai` / `Rhai`：加性增、乘性增的步长
|
||||
- `Alpha`：根据 CNP 频率估计拥塞程度
|
||||
- Timer：多久没收到 CNP 就加速恢复
|
||||
|
||||
DCQCN 的调参是门艺术：太激进导致抖动，太保守导致 throughput 上不去。阿里 HPN、字节 MegaScale 都有自研的拥塞控制（HPCC、Swift 等）作为替代。
|
||||
|
||||
### 3.4 800G 以太网与 UEC
|
||||
|
||||
2024—2026 年以太网侧最大的事：
|
||||
|
||||
1. __800G 商用落地__：Broadcom Tomahawk 5（51.2 Tb/s）、Marvell Teralynx 10、思科 Silicon One G200 全部支持 800G。
|
||||
2. __1.6T 规划中__：Tomahawk 6（102.4 Tb/s）2025—2026 出样。
|
||||
3. __UEC（Ultra Ethernet Consortium）成立__：AMD、Broadcom、Cisco、Arista、Meta、微软等发起，目标是把以太网重做成"训练原生"：packet spray、可选择丢包、in-network collective、更轻量的传输层（替代传统 RoCE 的 Go-Back-N）。
|
||||
|
||||
UEC 的潜台词就是"__我们不想一直给 NVIDIA IB 交保护费__"。预计 2025—2026 UEC 1.0 兼容网卡和交换机陆续上市，对 NVIDIA Spectrum-X 构成直接竞争。
|
||||
|
||||
### 3.5 NVIDIA 的反击：Spectrum-X
|
||||
|
||||
NVIDIA 当然不会放任以太网吃掉 IB 的份额，于是推出 __Spectrum-X__：Spectrum-4 交换机 + BlueField-3 / ConnectX-8 DPU/NIC，基于以太网但集成了：
|
||||
|
||||
- __adaptive routing__：流级别重新哈希，对抗 ECMP hash 冲突
|
||||
- __packet spray + reorder__：NIC 侧重排序，把多链路负载均衡做到极致
|
||||
- __拥塞控制协同__：交换机 telemetry 实时反馈到 NIC
|
||||
|
||||
本质上是"把 IB 的好处搬到以太网上"，抢以太网阵营的单。
|
||||
|
||||
## 四、拓扑：Fat-Tree、Rail-optimized、Dragonfly
|
||||
|
||||
拓扑决定了__对分带宽（bisection bandwidth）__ 和__最坏情况延迟__。
|
||||
|
||||
### 4.1 Fat-Tree / Clos
|
||||
|
||||
两层或三层 Clos 网络，是通用数据中心的默认拓扑：
|
||||
|
||||
```
|
||||
Spine 层（core switch）
|
||||
/ | | \
|
||||
Leaf Leaf Leaf Leaf
|
||||
/|\ /|\ /|\ /|\
|
||||
...服务器...
|
||||
```
|
||||
|
||||
- 理论上全对分无阻塞（非阻塞 fat-tree）
|
||||
- 扩展性好，常规 3 层可支撑十万卡级别
|
||||
- 问题：__ECMP hash 冲突__。两条大象流哈希到同一 uplink，链路利用率上不去
|
||||
|
||||
### 4.2 Rail-optimized（Meta / 字节 / 阿里都在用）
|
||||
|
||||
Rail-optimized 的核心想法：__按卡号分轨__。
|
||||
|
||||
每台 8 卡服务器的 GPU0 全部连到 rail-0 交换机，GPU1 连到 rail-1 交换机……共 8 条独立 rail。DP AllReduce 只在同 rail 内发生，机间只走本 rail 的带宽，完全避免跨 rail 的 ECMP 冲突。
|
||||
|
||||
```
|
||||
rail-0 switch rail-7 switch
|
||||
/ | | \ / | | \
|
||||
Server0 Server1 ... Server0 Server1 ...
|
||||
GPU0 GPU0 GPU7 GPU7
|
||||
```
|
||||
|
||||
优点：
|
||||
|
||||
- AllReduce 带宽稳定，逼近理论值
|
||||
- 故障域清晰（rail-x 挂了只影响 GPU-x）
|
||||
|
||||
缺点：
|
||||
|
||||
- 跨 rail 通信（PP、EP）要多跳
|
||||
- 拓扑感知必须做对，否则退化
|
||||
|
||||
阿里 HPN、Meta RSC、字节 MegaScale 集群基本都是 rail-optimized 变体。
|
||||
|
||||
### 4.3 Dragonfly
|
||||
|
||||
CRAY / HPE 在超算上用的拓扑，分 group，group 内全连接，group 间少量长链路。
|
||||
|
||||
- 优点：对分带宽高，全局跳数少（最多 3 跳）
|
||||
- 缺点：需要 adaptive routing + UGAL 调度，生态小众
|
||||
|
||||
国内训练场景里不常见，主要是 Frontier、Aurora 这种超算集群用。
|
||||
|
||||
### 4.4 Multi-rail
|
||||
|
||||
一台服务器接 4—8 张 NIC（现在 H100 / B200 标配 __1 GPU : 1 NIC__，每卡独立一张 400G / 800G NIC）。NCCL 会自动把 AllReduce 拆成 N 条流在 N 条 rail 上并发，总带宽线性叠加。
|
||||
|
||||
Multi-rail 的关键：
|
||||
|
||||
- __NUMA / PCIe 亲和__：NIC 必须和它服务的 GPU 挂在同一 PCIe Switch / CPU，否则走 QPI / UPI 过去带宽腰斩
|
||||
- __拓扑文件__：NCCL 的 `NCCL_TOPO_FILE` 要正确声明 GPU-NIC 关系
|
||||
|
||||
## 五、集合通信与网络的关系
|
||||
|
||||
### 5.1 AllReduce 是带宽受限的
|
||||
|
||||
Ring AllReduce 的数据量分析：
|
||||
|
||||
- N 卡、数据量 D、一次 Ring-AllReduce 总步骤 = `2(N-1)`
|
||||
- 每步传输 `D/N`，总传输量 `2D(N-1)/N ≈ 2D`
|
||||
- 理论最优时间 `T = 2D(N-1) / (N · B)`，其中 B 是单链路带宽
|
||||
|
||||
结论：__N 很大时，AllReduce 时间几乎只取决于 B__。这就是为啥大家拼命堆带宽而不是堆卡数——带宽不够，加卡只会让每卡 throughput 更低。
|
||||
|
||||
### 5.2 Tree / Double-binary tree / SHARP
|
||||
|
||||
- __Tree AllReduce__：延迟 O(log N)，适合小消息
|
||||
- __Double-binary tree__：NCCL 默认大消息策略，带宽利用率接近 ring，延迟 O(log N)
|
||||
- __SHARP__：IB 交换机做在网规约，一次 AllReduce 只需要"上树 + 下树"，延迟和带宽都显著改善
|
||||
|
||||
NCCL 2.18+ 默认自动选择，也可以 `NCCL_ALGO=Ring` / `Tree` / `CollnetChain` / `CollnetDirect` 手动指定。
|
||||
|
||||
### 5.3 计算通信重叠
|
||||
|
||||
训练框架（Megatron、DeepSpeed、FSDP）都会做 overlap：反向传播算出一层梯度立刻开始 AllReduce，下一层计算并行进行。前提是__网络 throughput 足够稳__，否则 overlap 窗口小于通信时间，优化失效。
|
||||
|
||||
## 六、万卡故障域
|
||||
|
||||
### 6.1 fail-stop vs fail-slow
|
||||
|
||||
- __fail-stop__：GPU 挂了、NIC 挂了、节点宕机——监控立刻能抓到，重启 / 换节点恢复
|
||||
- __fail-slow__：更可怕。一张 NIC 降速、一个 optic 模块误码率升高、一颗 NVSwitch 半死，__带宽从 400G 降到 200G 但不报错__。整个 step 被这一根慢链路拖慢 2 倍
|
||||
|
||||
fail-slow 的典型表现：某个 rank 的 AllReduce 时间突然从 50ms 涨到 200ms，且持续一段时间；NCCL 监控 per-rank 时间就能发现。
|
||||
|
||||
### 6.2 链路抖动
|
||||
|
||||
光模块温度波动、DSP 误码、SerDes 重训练都会导致短时抖动。无损网络下，抖动可能触发 PFC，进一步诱发风暴。缓解：
|
||||
|
||||
- 光模块选用长期稳定的 200G-per-lane 甚至 100G-per-lane（别追最新的 200G PAM4）
|
||||
- 交换机 buffer 调大，吸收瞬时突发
|
||||
- 分级 QoS，训练流量独占一个优先级类
|
||||
|
||||
### 6.3 hash 冲突与大象流
|
||||
|
||||
ECMP 基于五元组哈希，训练流都是长连接大象流，很容易两条流撞同一 uplink。缓解：
|
||||
|
||||
- __rail-optimized 从源头避免__
|
||||
- __adaptive routing__（Spectrum-X、IB）
|
||||
- __packet spray__（UEC）
|
||||
- __多 QP 打散__：NCCL 开多 QP（`NCCL_IB_QPS_PER_CONNECTION=4`），哈希变成 5 元组 × 4
|
||||
|
||||
### 6.4 Checkpoint 与故障域隔离
|
||||
|
||||
这是下一篇（05 / 10）的主题，这里只提一句：万卡集群的 MTBF 是按__小时__算的，Ckpt 间隔必须小于 MTBF，否则训练永远卡在回滚。
|
||||
|
||||
## 七、国产互联生态
|
||||
|
||||
### 7.1 网络设备
|
||||
|
||||
- __华为__：CloudEngine 16800 系列，400G / 800G 以太网，配合昇腾 HCCN NIC，支持 RoCEv2 无损
|
||||
- __锐捷网络__：RG-S6980、S8920 系列，阿里、字节都大量采购
|
||||
- __新华三（H3C）__：S12500G、S9825 系列，百度、腾讯用得多
|
||||
- __中兴__：ZXR10 9900X 系列
|
||||
|
||||
国产 51.2T 交换芯片（盛科、华为自研）已在 2025 年陆续上市，国产替代在__可用__级别，性能对标 Tomahawk 4—5。
|
||||
|
||||
### 7.2 华为 CloudMatrix 384
|
||||
|
||||
2024 年底发布，2025 年大规模部署：
|
||||
|
||||
- 384 颗昇腾 910C
|
||||
- 超节点内全高速光互联（华为自研光模块）
|
||||
- 对外接口兼容标准以太网 / RoCEv2
|
||||
- 单超节点算力 ~ 300 PFLOPS（fp16）
|
||||
|
||||
对标 NVL72（72 GPU），卡数更多、带宽略低、功耗更大。在国内外管制背景下是 DeepSeek、Kimi 等团队的重要备选。
|
||||
|
||||
### 7.3 腾讯星脉网络
|
||||
|
||||
腾讯自研，特点：
|
||||
|
||||
- 全自研交换机（基于 Tomahawk / 自研芯片）
|
||||
- 自研 __TiTa 拥塞控制__（替代 DCQCN），更快收敛
|
||||
- rail-optimized + 多平面
|
||||
- 支持万卡至十万卡
|
||||
|
||||
### 7.4 阿里 HPN（High Performance Network）
|
||||
|
||||
阿里云训练集群底座：
|
||||
|
||||
- 自研 __HPCC / Swift__ 拥塞控制
|
||||
- __双上联__：每台服务器双 NIC 接不同 leaf，一侧挂了另一侧接管，消除单点
|
||||
- __eRDMA__：在 VPC 里跑 RDMA，云上训练也能享受无损
|
||||
- PAI-DLC、通义训练都跑在 HPN 上
|
||||
|
||||
### 7.5 字节 MegaScale
|
||||
|
||||
《MegaScale》论文披露了字节的万卡方案：
|
||||
|
||||
- rail-optimized 3 层 Clos
|
||||
- 400G RoCEv2
|
||||
- 大量 fail-slow 检测探针
|
||||
- NCCL 深度魔改，感知拓扑选最优算法
|
||||
|
||||
## 八、SuperPod / SuperCluster：十万卡级别
|
||||
|
||||
### 8.1 NVIDIA DGX SuperPod
|
||||
|
||||
标准化万卡方案：
|
||||
|
||||
- 以 DGX H100 / B200 node 为单元
|
||||
- IB Quantum-2（NDR 400G）组 rail-optimized 3 层
|
||||
- SHARP in-network reduction
|
||||
- 配 BCM（Bright Cluster Manager）+ NVIDIA Base Command 软件栈
|
||||
|
||||
2024—2026 年 Blackwell 代：__GB200 NVL72 × N__ 组成 SuperPod，NVL72 间走 IB XDR 800G。
|
||||
|
||||
### 8.2 Meta Research SuperCluster（RSC）与 Grand Teton
|
||||
|
||||
Meta 训练 Llama 3 / 4 的基础设施：
|
||||
|
||||
- 两个 24k H100 集群（一个 RoCE、一个 IB，做 A/B 对比）
|
||||
- Grand Teton 整机柜设计，OCP 标准
|
||||
- __无损以太网 + rail-optimized + 自研调度__
|
||||
|
||||
结论是"两边都能跑 Llama 3，生态视角 RoCE 更划算"。
|
||||
|
||||
### 8.3 xAI Colossus：10 万卡
|
||||
|
||||
2024 年 Elon Musk 在孟菲斯建的超级集群：
|
||||
|
||||
- 100k H100 → 2025 扩到 200k H200 / B200
|
||||
- Spectrum-X 以太网 + NVL72
|
||||
- 号称 19 天从零部署完 10 万卡（实际是分阶段，但节奏极猛）
|
||||
|
||||
工程意义：__证明以太网阵营能打 10 万卡级别__。
|
||||
|
||||
### 8.4 国内超大集群
|
||||
|
||||
- 字节：北京怀来、山西、新疆万卡—十万卡级
|
||||
- 阿里：张北、乌兰察布，多个 HPN 万卡集群
|
||||
- 腾讯：星脉支持的万卡集群，训练混元
|
||||
- 华为云：乌兰察布 / 贵安，CloudMatrix 384 × N
|
||||
- 百度：阳泉百舸 4.0 万卡
|
||||
|
||||
## 九、光互联与 CPO
|
||||
|
||||
### 9.1 可插拔光模块的瓶颈
|
||||
|
||||
传统 QSFP-DD / OSFP 可插拔光模块，功耗和密度已经到极限：
|
||||
|
||||
- 800G OSFP 模块功耗 14—17 W，一个 51.2T 交换机光模块总功耗接近交换机本体
|
||||
- 前面板密度有限，再往上到 1.6T / 3.2T 已经插不下
|
||||
|
||||
### 9.2 CPO（Co-Packaged Optics）
|
||||
|
||||
CPO 的思路：__把光引擎贴到交换机 ASIC 旁边__，省掉 SerDes 跑前面板这段距离。
|
||||
|
||||
- 功耗降低 30%—50%
|
||||
- 密度翻倍
|
||||
- 代价：维修性差（坏一个要换整板），可靠性需要时间验证
|
||||
|
||||
Broadcom 2024 年发布 Tomahawk 5 Bailly CPO 版本；NVIDIA 2025 年宣布 Spectrum-X 和 Quantum-X 都会有 CPO 产品线；国内光迅、中际旭创、新易盛都在押注。
|
||||
|
||||
### 9.3 硅光（Silicon Photonics）
|
||||
|
||||
硅光是 CPO 的底层技术路线之一：用 CMOS 工艺做光调制器 / 探测器。代表公司：Intel（Silicon Photonics 已分拆）、Ayar Labs、Lightmatter、国内的光迅。
|
||||
|
||||
对训练的直接好处：__未来可能看到 GPU die 上直接出光__（optical I/O），NVLink 跨机柜不再需要铜缆 + 电—光转换。
|
||||
|
||||
## 十、训练工程师视角：集合通信打不满怎么办
|
||||
|
||||
### 10.1 排查清单
|
||||
|
||||
一个 step 的 AllReduce 时间比理论值高 20% 以上，按顺序查：
|
||||
|
||||
1. __NCCL 是不是用对了网络__
|
||||
|
||||
```
|
||||
export NCCL_DEBUG=INFO
|
||||
export NCCL_DEBUG_SUBSYS=INIT,GRAPH,NET
|
||||
```
|
||||
|
||||
看启动日志里 `NCCL INFO NET/IB : Using [0]mlx5_0:1/IB` 或 `NET/Socket`。如果是 Socket，说明 RDMA 根本没起来。
|
||||
|
||||
2. __GPU-NIC 亲和__
|
||||
|
||||
看 GPU 和 NIC 之间是 `PIX`（同 PCIe switch，最优）、`PXB`（跨 bridge）、`NODE`（同 NUMA）、`SYS`（跨 NUMA，最差）。跨 NUMA 的组合必须修正拓扑文件。
|
||||
|
||||
3. __多 QP 和 rail 数__
|
||||
|
||||
```
|
||||
export NCCL_IB_QPS_PER_CONNECTION=4
|
||||
export NCCL_IB_SPLIT_DATA_ON_QPS=1
|
||||
export NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_4,mlx5_5,mlx5_6,mlx5_7
|
||||
```
|
||||
|
||||
4. __算法选对__
|
||||
|
||||
```
|
||||
export NCCL_ALGO=Ring,Tree,CollnetChain,CollnetDirect
|
||||
export NCCL_PROTO=Simple,LL,LL128
|
||||
```
|
||||
|
||||
大消息用 Ring + Simple，小消息用 Tree + LL128。打开 NCCL autotune 后一般不用手调。
|
||||
|
||||
5. __PFC / ECN 配置__
|
||||
|
||||
交换机上 `show pfc statistics`、`show ecn statistics`，看有没有大量 Pause 帧或 CNP。正常训练应该只有少量 ECN，PFC 接近 0。
|
||||
|
||||
6. __慢节点检测__
|
||||
|
||||
写个 per-rank allreduce 时间统计，看有没有某一两个 rank 一直比别人慢。慢节点隔离出来单独测带宽。
|
||||
|
||||
### 10.2 NCCL 常用环境变量速查
|
||||
|
||||
| 变量 | 作用 |
|
||||
| --- | --- |
|
||||
| `NCCL_DEBUG=INFO/WARN` | 调试日志 |
|
||||
| `NCCL_DEBUG_SUBSYS=ALL` | 细分子系统日志 |
|
||||
| `NCCL_IB_HCA` | 指定使用的 IB HCA |
|
||||
| `NCCL_IB_GID_INDEX` | RoCEv2 下必须设，通常 3 |
|
||||
| `NCCL_SOCKET_IFNAME` | 控制面网卡 |
|
||||
| `NCCL_P2P_DISABLE` | 禁用 P2P（调试用） |
|
||||
| `NCCL_SHM_DISABLE` | 禁用 SHM |
|
||||
| `NCCL_NET_GDR_LEVEL` | GPUDirect RDMA 级别 |
|
||||
| `NCCL_BUFFSIZE` | NCCL 内部 buffer 大小 |
|
||||
| `NCCL_MIN_NCHANNELS` / `NCCL_MAX_NCHANNELS` | 并行 channel 数 |
|
||||
|
||||
### 10.3 nccl-tests 实操
|
||||
|
||||
这是工程师的万能基准测试工具。
|
||||
|
||||
```
|
||||
git clone https://github.com/NVIDIA/nccl-tests
|
||||
cd nccl-tests
|
||||
make MPI=1 CUDA_HOME=/usr/local/cuda NCCL_HOME=/usr/local/nccl
|
||||
|
||||
# 8 卡单机 AllReduce（默认 NVLink 带宽测试）
|
||||
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8
|
||||
|
||||
# 跨机：16 节点 × 8 GPU = 128 卡
|
||||
mpirun -np 128 -H host1:8,host2:8,...,host16:8 \
|
||||
-x NCCL_DEBUG=INFO \
|
||||
-x NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_4,mlx5_5,mlx5_6,mlx5_7 \
|
||||
-x LD_LIBRARY_PATH \
|
||||
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1
|
||||
```
|
||||
|
||||
关注两列：
|
||||
|
||||
- `busbw`：总线带宽，= `algbw × 2(N-1)/N`。对 ring AllReduce，__busbw 应该接近单链路带宽__
|
||||
- `time`：耗时
|
||||
|
||||
经验值参考（大消息 1 GB）：
|
||||
|
||||
| 场景 | 理论 busbw | 实测可达 |
|
||||
| --- | --- | --- |
|
||||
| H100 单机 NVLink4 | 450 GB/s | 380—420 GB/s |
|
||||
| B200 NVL72 内 | 900 GB/s | 750—850 GB/s |
|
||||
| H100 跨机 IB NDR × 8 rail | 400 GB/s | 320—380 GB/s |
|
||||
| H100 跨机 RoCEv2 400G × 8 | 400 GB/s | 280—360 GB/s（调优后） |
|
||||
|
||||
低于这个范围就说明有问题，按 10.1 排查。
|
||||
|
||||
### 10.4 拓扑感知：`NCCL_TOPO_FILE` 示例
|
||||
|
||||
NCCL 会自动探测拓扑，但云虚机 / 容器里经常探不准。手动写：
|
||||
|
||||
```
|
||||
<system version="1">
|
||||
<cpu numaid="0" affinity="ffff,00000000" arch="x86_64">
|
||||
<pci busid="0000:0a:00.0" class="0x060400" link_speed="32.0 GT/s" link_width="16">
|
||||
<pci busid="0000:0b:00.0" class="0x030200">
|
||||
<gpu dev="0" sm="90" rank="0"/>
|
||||
</pci>
|
||||
<pci busid="0000:0c:00.0" class="0x020000">
|
||||
<nic>
|
||||
<net name="mlx5_0" dev="0" speed="400000" port="1" latency="0" guid="..."/>
|
||||
</nic>
|
||||
</pci>
|
||||
</pci>
|
||||
</cpu>
|
||||
...
|
||||
</system>
|
||||
```
|
||||
|
||||
启动时 `NCCL_TOPO_FILE=/path/to/topo.xml`。现代 NCCL（2.18+）结合 `NCCL_GRAPH_FILE` 还可以进一步固化通信图。
|
||||
|
||||
## 十一、两张拓扑示意图
|
||||
|
||||
### 11.1 Fat-Tree vs Rail-optimized
|
||||
|
||||
|
||||
|
||||
### 11.2 NVL72 机柜示意
|
||||
|
||||
|
||||
|
||||
## 十二、进阶话题：GPUDirect、RDMA 编程与内核旁路
|
||||
|
||||
### 12.1 GPUDirect RDMA
|
||||
|
||||
传统数据路径：GPU HBM → 系统内存 → NIC DMA → 网络。两次拷贝，CPU 介入，带宽腰斩。
|
||||
|
||||
__GPUDirect RDMA__ 让 NIC 直接 DMA GPU 显存：
|
||||
|
||||
- 需要 NIC、GPU 挂在同一 PCIe Root Complex 或同一 PCIe Switch 下
|
||||
- 内核驱动 `nvidia-peermem`（取代老的 `nv_peer_mem`）把 GPU BAR 映射给 NIC
|
||||
- 对应 NCCL 环境变量 `NCCL_NET_GDR_LEVEL=PIX`（同 switch 才启用）或 `=SYS`（强制启用）
|
||||
|
||||
启用后跨机 AllReduce 带宽能再涨 30%—50%，是__训练必开__项。
|
||||
|
||||
### 12.2 GPUDirect Storage（GDS）
|
||||
|
||||
`cuFile` API，让 NVMe 直接 DMA GPU 显存。训练里用得不多（数据 pipeline 有 CPU 侧 DataLoader 处理），但推理侧大模型权重加载、KV offload 到 NVMe 时很有用。
|
||||
|
||||
### 12.3 用 `ibv_*` 直接写 RDMA
|
||||
|
||||
多数情况下不需要，但排障时有用。一个最小化的 WRITE 操作：
|
||||
|
||||
```
|
||||
struct ibv_send_wr wr = {};
|
||||
struct ibv_sge sge = {
|
||||
.addr = (uintptr_t)local_buf,
|
||||
.length = size,
|
||||
.lkey = mr->lkey,
|
||||
};
|
||||
wr.wr_id = 0;
|
||||
wr.sg_list = &sge;
|
||||
wr.num_sge = 1;
|
||||
wr.opcode = IBV_WR_RDMA_WRITE;
|
||||
wr.send_flags = IBV_SEND_SIGNALED;
|
||||
wr.wr.rdma.remote_addr = remote_addr;
|
||||
wr.wr.rdma.rkey = remote_rkey;
|
||||
|
||||
struct ibv_send_wr *bad;
|
||||
ibv_post_send(qp, &wr, &bad);
|
||||
|
||||
struct ibv_wc wc;
|
||||
while (ibv_poll_cq(cq, 1, &wc) == 0) {}
|
||||
if (wc.status != IBV_WC_SUCCESS) { /* 错误处理 */ }
|
||||
```
|
||||
|
||||
排障时可以用 `ib_write_bw` / `ib_read_bw` 直测链路：
|
||||
|
||||
```
|
||||
# 服务器端
|
||||
ib_write_bw -d mlx5_0 -F -x 3 --report_gbits
|
||||
|
||||
# 客户端
|
||||
ib_write_bw -d mlx5_0 -F -x 3 --report_gbits <server_ip>
|
||||
```
|
||||
|
||||
正常 400G IB 应该能跑到 395+ Gb/s，低于 380 就要查 PCIe 亲和或光模块。
|
||||
|
||||
### 12.4 DPU / IPU 的角色
|
||||
|
||||
BlueField-3 / Pensando / AWS Nitro 这些 DPU，在 AI 训练集群里主要做：
|
||||
|
||||
1. __RDMA 卸载__：本来就是 NIC 功能
|
||||
2. __虚拟化__：多租户云训练里，把 VPC、overlay、安全组全部卸载到 DPU，让 CPU 和 GPU 专心算
|
||||
3. __存储加速__：NVMe-oF initiator 在 DPU 上跑
|
||||
4. __训练观测__：DPU 天然在网卡侧，telemetry、packet capture 都最合适
|
||||
|
||||
阿里 eRDMA、AWS EFA 都高度依赖 DPU。
|
||||
|
||||
## 十三、真实案例：一次万卡训练的网络复盘
|
||||
|
||||
这一节把前面所有技术点串起来，讲一个真实（虚构但贴近行业）的案例：某团队用 4096 卡 H100 训练一个 100B 模型，MFU 迟迟上不去。
|
||||
|
||||
### 13.1 现象
|
||||
|
||||
- 单机 8 卡 nccl-tests AllReduce：400 GB/s（正常）
|
||||
- 跨机 16 机 128 卡 AllReduce：预期 ~ 350 GB/s，实测 180 GB/s
|
||||
- 训练 MFU 只有 28%，期望 45%+
|
||||
|
||||
### 13.2 排查步骤
|
||||
|
||||
__Step 1：看 NCCL 日志__
|
||||
|
||||
```
|
||||
export NCCL_DEBUG=INFO
|
||||
export NCCL_DEBUG_SUBSYS=NET,GRAPH
|
||||
```
|
||||
|
||||
日志里发现：
|
||||
|
||||
```
|
||||
NCCL INFO NET/IB : Using [0]mlx5_0:1/IB [1]mlx5_1:1/IB ... [7]mlx5_7:1/IB
|
||||
NCCL INFO Channel 00 : 0[0] -> 1[0] via NET/IB/0
|
||||
```
|
||||
|
||||
8 张 NIC 都识别到了，OK。
|
||||
|
||||
__Step 2：查 GPU-NIC 亲和__
|
||||
|
||||
```
|
||||
nvidia-smi topo -m
|
||||
```
|
||||
|
||||
发现 GPU4—GPU7 和对应 NIC 是 `SYS`（跨 NUMA），而 GPU0—GPU3 是 `PIX`（同 PCIe switch）。__根因 1__：服务器 BIOS 里 PCIe Root Complex 划分不对，NIC 全部挂在 Socket 0。
|
||||
|
||||
__Step 3：改硬件或改拓扑文件__
|
||||
|
||||
硬件不能动，只能接受跨 NUMA。但发现系统没有加载 `nvidia-peermem`：
|
||||
|
||||
```
|
||||
lsmod | grep peermem
|
||||
# 空
|
||||
modprobe nvidia-peermem
|
||||
```
|
||||
|
||||
__根因 2__：GPUDirect RDMA 没启用，数据绕了一圈 CPU。
|
||||
|
||||
__Step 4：检查交换机 ECN / PFC__
|
||||
|
||||
```
|
||||
show interface counters errors
|
||||
show pfc statistics interface Ethernet1/1
|
||||
```
|
||||
|
||||
发现某几个 leaf 的 PFC Pause 计数每秒上万，__根因 3__：拥塞控制没调好，训练流量经常触发 PFC。
|
||||
|
||||
__Step 5：查 QP 和 channel 数__
|
||||
|
||||
```
|
||||
NCCL_IB_QPS_PER_CONNECTION=1（默认）
|
||||
```
|
||||
|
||||
多 rail 下单 QP 容易哈希冲突，改成：
|
||||
|
||||
```
|
||||
export NCCL_IB_QPS_PER_CONNECTION=4
|
||||
export NCCL_IB_SPLIT_DATA_ON_QPS=1
|
||||
```
|
||||
|
||||
### 13.3 修复后
|
||||
|
||||
- 加载 `nvidia-peermem`：busbw 从 180 → 260 GB/s
|
||||
- 调 DCQCN + 降 PFC 阈值：→ 300 GB/s
|
||||
- 开多 QP + packet spray：→ 345 GB/s
|
||||
- 修拓扑文件 + NUMA pin：→ 360 GB/s
|
||||
|
||||
MFU 从 28% 涨到 46%。训练时长从 90 天缩到 55 天。
|
||||
|
||||
### 13.4 启示
|
||||
|
||||
这个案例里，没有一个"致命 bug"，全是几个百分点的小问题叠加。万卡训练的网络调优就是这样——__每个环节省 10%，整体翻倍__。所以基建团队必须对 NCCL、NIC、交换机、拓扑、NUMA 全栈都懂。
|
||||
|
||||
## 十四、展望 2026—2028
|
||||
|
||||
1. __NVLink 走出机柜__：NVIDIA 路线图里 NVLink Fusion / NVL576，用光互联把多个 NVL72 连成更大的 scale-up 域
|
||||
2. __UALink 1.0 出货__：AMD / Broadcom / Cisco 阵营推出替代 NVLink 的开放标准
|
||||
3. __UEC 1.0 大规模部署__：预计 2026—2027 年成为以太网训练的事实标准
|
||||
4. __CPO 商用__：800G → 1.6T 迭代中，CPO 从试点走向规模部署
|
||||
5. __光 I/O 进芯片__：Lightmatter、Ayar Labs 的 optical I/O 可能首次出现在商用 AI 芯片上
|
||||
6. __国产超节点 1000+ 卡__：华为 CloudMatrix 下一代、寒武纪、壁仞可能推出千卡级超节点
|
||||
7. __跨 DC 训练__：Google Gemini Ultra 已经在做跨数据中心训练，DCI（DC Interconnect）成为新战场
|
||||
|
||||
网络演进的速度会比过去五年更快——因为 GPU 单卡算力增长在放缓，scale-up / scale-out 的想象力变成了整个行业的新增长点。
|
||||
|
||||
## 十五、选型决策速查
|
||||
|
||||
训练团队做网络选型时，建议按这个决策流：
|
||||
|
||||
1. __规模 ≤ 1k 卡，预算紧__：单柜或 2—3 机柜，IB NDR 400G × 8 rail，省事、生态稳
|
||||
2. __规模 1k—1 万卡，走公有云__：用云商自研网络（阿里 HPN、腾讯星脉、AWS EFA、Azure InfiniBand），不要自己折腾
|
||||
3. __规模 1 万—10 万卡，自建__：rail-optimized 3 层 Clos + 800G RoCEv2 + 自研拥塞控制；或 Spectrum-X；IB 仅在成本允许时考虑
|
||||
4. __规模 ≥ 10 万卡__：必须多平面 / 多池，单池 1—2 万卡，池间走骨干或分层调度
|
||||
5. __国产化路线__：昇腾 CloudMatrix 384 + 华为 / 锐捷 400G / 800G 以太网，HCCL + 自研 RoCEv2 栈
|
||||
6. __推理集群__：KV cache 以 intra-node 为主，对跨机带宽要求远低于训练；可以用 200G RoCE 或甚至 100G
|
||||
|
||||
## 参考资料
|
||||
|
||||
1. NVIDIA, _NVLink and NVSwitch Architecture Whitepaper_, 2022—2024
|
||||
2. NVIDIA, _GB200 NVL72 Datasheet / System Guide_, 2024
|
||||
3. NVIDIA, _Spectrum-X Platform Whitepaper_, 2023
|
||||
4. NVIDIA, _nccl-tests_ 仓库：https://github.com/NVIDIA/nccl-tests
|
||||
5. Mellanox, _DCQCN: Data Center Quantized Congestion Notification_, SIGCOMM 2015
|
||||
6. Alibaba, _HPN: A Data Center Network for Large Language Model Training_, SIGCOMM 2024
|
||||
7. ByteDance, _MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs_, NSDI 2024
|
||||
8. Meta, _RDMA over Ethernet for Distributed AI Training at Meta Scale_, SIGCOMM 2024
|
||||
9. Tencent, _Tencent Xingmai (Starlink) Network_, 2023—2024 技术博客
|
||||
10. AMD, _Infinity Fabric / xGMI Documentation_, MI300X 平台
|
||||
11. Huawei, _CloudMatrix 384 超节点白皮书_, 2024
|
||||
12. Ultra Ethernet Consortium, _UEC Specification 1.0 (Draft)_, 2024—2025
|
||||
13. CXL Consortium, _CXL 3.0 Specification_, 2023
|
||||
14. Broadcom, _Tomahawk 5 Product Brief_, 2023
|
||||
15. xAI, _Colossus Cluster Overview_, 2024—2025
|
||||
@@ -0,0 +1,77 @@
|
||||
# 📊 文章摘要：大模型基础设施工程 04：互联与网络——NVLink、InfiniBand、RoCE 与国产替代
|
||||
|
||||
> **原文**：[2026-04-22_大模型基础设施工程04_互联与网络_NVLink_InfiniBand_RoCE_与国产替代.md](./2026-04-22_大模型基础设施工程04_互联与网络_NVLink_InfiniBand_RoCE_与国产替代.md)
|
||||
> **原文链接**：https://quant67.com/post/llm-infra/04-interconnect/04-interconnect.html
|
||||
> **来源**：土法炼钢兴趣小组的算法知识备份
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-04-22
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **互联为王** — 单卡算力不再是瓶颈，网络架构决定万卡集群的利用率与 MFU。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
文章系统梳理 LLM 训练集群的互联技术全景：从 scale-up（NVLink/NVSwitch/NVL72、Infinity Fabric、HCCS、CXL）到 scale-out（InfiniBand、RoCEv2、UEC、Spectrum-X），从拓扑（Fat-Tree、Rail-optimized、Dragonfly）到故障域（fail-stop/fail-slow），并给出集合通信原理与国产生态梳理。核心论点"算力决定上限，互联决定利用率"贯穿全文——同样一批 H100 接不同网络，70B 模型训练 MFU 可相差 30 个百分点以上。文末附训练工程师视角的"集合通信打不满"排查清单、nccl-tests 实操与贴近行业的排障复盘案例，是国内少见的兼具原理深度与工程可操作性的中文综述。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **万卡训练的独特流量画像** — 周期突发、带宽受限、尾延迟决定全局（straggler 问题）、长连接零丢包容忍，决定了训练网络必须是无损或近似无损的 `[分类: 共识]`
|
||||
2. **NVL72 把机柜变成一块 GPU** — 72 卡全 NVLink 互联，TP/EP 可一柜内完成，是 2024—2026 最重要的产品级变化，堪称 MoE 模型（如 DeepSeek-R1）的天选硬件 `[分类: 共识]`
|
||||
3. **IB 是黄金标准但贵且锁死** — SHARP 在网计算、无损流控、NDR/XDR 速率演进，但每端口价格为等速以太网 2—3 倍，生态被 NVIDIA 牢牢掌控 `[分类: 共识]`
|
||||
4. **RoCEv2 是国内大厂务实之选** — 阿里、字节、腾讯、百度主力均为 RoCEv2，省钱 30%—50%、生态解耦、复用运维栈，但 PFC/ECN/DCQCN 全链路调优是极高的工程门槛 `[分类: 共识]`
|
||||
5. **Rail-optimized 是主流训练拓扑** — 按卡号分轨消除 ECMP 哈希冲突，Meta RSC、字节 MegaScale、阿里 HPN 均为其变体；UEC packet spray 是下一代方向 `[分类: 共识]`
|
||||
6. **fail-slow 比 fail-stop 更可怕** — 网卡降速不报错会拖慢整个 step，需靠 per-rank AllReduce 时间监控发现 `[分类: 共识]`
|
||||
7. **排障案例的启示** — 4096 卡 MFU 从 28% 提升到 46%，靠的是 peermem 加载、DCQCN 调参、多 QP 打散、拓扑文件修正等小优化的叠加，全程没有"致命 bug" `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者默认"带宽为王"——Ring AllReduce 时间几乎只取决于单链路带宽的分析，弱化了小消息延迟、拓扑跳数与流水线气泡的影响；假设读者面向 2024—2026 年主流硬件（H100/B200）且具备训练框架与 NCCL 基础。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据充分——引用 HPN（SIGCOMM 2024）、MegaScale（NSDI 2024）、DCQCN 等论文与白皮书，busbw 实测经验表与排查案例逻辑自洽；但"实测可达"数据未注明来源环境，属经验估值而非可复现基准，排障案例亦明确标注"虚构但贴近行业"，应视为教学素材而非实证。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
面向训练侧，推理集群场景仅一句话带过；2026—2028 展望（UEC 大规模部署、光 I/O 进芯片、跨 DC 训练）是趋势判断而非事实；国产生态数据（CloudMatrix 功耗、带宽）缺乏公开实测背书，且未做 IB 与以太网的 TCO 量化对比。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "算力决定上限，互联决定利用率。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 系统性极强——从物理层、协议层到拓扑层再到排障层全覆盖，一篇文章搭起完整知识框架
|
||||
- 排查清单、NCCL 环境变量速查、nccl-tests 实操可直接照搬，工程价值高；对 IB/RoCE 竞争与国产替代生态（CloudMatrix、星脉、HPN、MegaScale）梳理客观
|
||||
|
||||
**不足**：
|
||||
- 部分带宽数字为经验估值，未注明测试环境；展望部分与历史数据混排，读者需自行甄别
|
||||
- 成本视角偏弱，未量化 IB 与以太网的性价比差异
|
||||
|
||||
**适用场景**：训练集群基础设施工程师、MLOps 团队的技术手册；万卡网络设计、排障培训教材；了解国产互联生态与选型约束的决策参考。
|
||||
|
||||
**关联建议**：以 Introl《InfiniBand vs 以太网 GPU 集群对比》补足 TCO 与选型决策视角；深入研读 HPN、MegaScale、Meta《RDMA over Ethernet at Meta Scale》三篇论文；后续跟进该系列第 05 篇（Checkpoint 与故障域）。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,346 @@
|
||||
# 美国镜鉴：当AI浪潮遭遇政治反弹
|
||||
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：CF40研究部
|
||||
> **发布日期**：2026-07-28
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/OLxrS_jzJqz0z6bKIJMsfA
|
||||
|
||||
---
|
||||
|
||||
[图片]
|
||||
|
||||
"
|
||||
|
||||
在AI技术以前所未有的速度扩张之际，对AI的政治反弹力量也在同步积蓄，这一现象在美国等发达经济体中尤为突出。正如《华尔街日报》所评，当前唯一比AI产业增长更快的，可能就是美国人对AI的负面情绪。尽管AI尚未造成全面的宏观就业冲击，围绕岗位替代、技能与数据控制、科技巨头权力边界以及数据中心资源消耗的社会争议，却已迅速升温。
|
||||
|
||||
本文首先回顾工业革命、铁路革命和计算机革命中对技术的政治反弹，梳理反抗对象如何从机器、垄断企业逐步转向选举政治；随后分析当前美国国内，对AI的政治反弹的三条战线——劳动保护、科技巨头权力与地方资源冲突；最后考察左右翼民粹力量对反"科技寡头"叙事的整合，梳理建制派与AI企业在就业补偿、收益分享、安全监管和社区成本分担方面的回应，并探讨对AI的政治反弹进入美国全国性选举议程的条件及其对AI产业的潜在影响。
|
||||
|
||||
* 原文《当AI浪潮遭遇政治反弹》在2026年7月28日首发于CF40 APP，内容略有删减。本文观点仅供了解海外研究动态，不代表中国金融四十人论坛和中国金融四十人研究院意见和立场。
|
||||
|
||||
"
|
||||
|
||||
______[图片]______
|
||||
|
||||
历史上对技术的政治反弹：
|
||||
|
||||
从破坏机器到诉诸选票
|
||||
|
||||
历史经验表明，技术革命能否获得社会支持，不仅取决于其长期创造多少收益，还取决于收益与成本如何分配，以及制度能否在损失固化之前为受冲击者提供补偿和转型通道。
|
||||
|
||||
当技术直接替代劳动、损失集中于特定群体时，反抗容易指向机器；当企业借助技术控制市场入口时，矛头会转向垄断企业；当冲击长期而分散、又得不到制度缓解时，积累的不满则可能经由政治动员进入选举。
|
||||
|
||||
______1. 工业革命初期：替代型技术引发对机器的直接反抗______
|
||||
|
||||
牛津大学经济学家卡尔·弗雷指出，赋能型技术通常能够提高劳动者的生产率、创造新任务并增加收入，因而较容易得到接受；替代型技术却可能导致既有技能贬值、工资下降和议价能力削弱，因此更容易引发抵制。换言之，公众并不是笼统地支持或反对技术，而是根据技术对自身收入和经济地位的影响形成态度[1]。
|
||||
|
||||
工业革命初期正是这种矛盾的典型案例。纺织机械和机械化工厂显著提高了生产率，却主要以替代劳动的方式投入使用，其收益也没有立即转化为劳动者收入。经济史学家罗伯特·艾伦将这一时期生产率增长与劳动者收入停滞并存的现象称为"恩格斯暂停"（Engels' Pause）。按照他的估算，1780-1840年间，英国每名工人的产出增长约46%，实际工资却仅增长约12%，利润率则大致翻倍。直到1840年以后，随着蒸汽动力的广泛采用和机器的复杂化，工厂对高技术工人需求增加，工人的实际工资才开始更明显地追赶生产率增长[2]。
|
||||
|
||||
在生产率收益主要流向资本所有者的同时，机械化首先冲击了手工织工等特定群体的岗位、工资和技能价值，由此引发卢德运动[3]。卢德分子通过大规模破坏纺织机器、组织抗议和向议会请愿，要求限制直接替代劳动者的技术应用。行动最终因政治影响力有限和政府镇压而失败。但该运动表明，当技术损失集中落在特定劳动群体身上，而收益尚未广泛扩散时，对机器的直接反抗更容易发生。
|
||||
|
||||
______2. 铁路革命：反抗对象指向基础设施垄断______
|
||||
|
||||
如果说卢德运动针对的是技术对劳动的直接替代，铁路时代的反抗则指向企业借助技术形成的基础设施控制权。19世纪下半叶的美国，铁路迎来了飞速发展期，铁路降低了运输成本、扩大了全国市场，却也让铁路公司及其合作的粮仓经营者垄断了定价权和农产品进入市场的关键通道。缺乏替代运输渠道的农民往往需要承担更高运费和粮仓的存储费。
|
||||
|
||||
在农产品价格下跌、债务负担上升和货币紧缩的背景下，面对高昂的运输和仓储成本，美国中西部的大量农民濒临破产。由农民发起的格兰杰运动推动多个州限制铁路和粮仓收费，并促成1887年《州际商务法》和州际商务委员会的建立，标志着美国政府开始介入并约束大型托拉斯与铁路垄断巨头。19世纪末美国的民粹政党人民党又进一步提出铁路监管、累进所得税、农业信贷和货币改革等主张。尽管人民党最终垮台，但其许多政策主张都被随后的民主党政府所吸纳[4]。
|
||||
|
||||
农民反对的不是铁路本身，而是铁路公司利用基础设施控制权决定谁能进入市场、谁承担更高成本。当新技术成为难以替代的市场入口时，反弹力量便可能由抵制设备转向反垄断和公共监管。
|
||||
|
||||
______3. 20世纪工业化：分享技术红利一度缓和反弹______
|
||||
|
||||
并非所有技术革命都会引发同等强度的反弹。20世纪的电气化、汽车和大规模生产虽然淘汰了一些职业，却也创造了大量半熟练制造业、设备维护和办公室岗位。制造业持续扩张和教育普及，使多数被替代者能够转入工资更高、危险程度更低的岗位。1870—1980年间，美国劳动生产率与工人实际报酬总体同步增长，没有再次出现工业革命初期的 "恩格斯暂停"现象[5]。
|
||||
|
||||
制度建设进一步缓和了技术调整的成本。1910—1920年代兴起的企业福利资本主义，通过提高工资、提供医疗和养老金等方式，将部分生产率收益返还给工人。大萧条以后，罗斯福新政又以《瓦格纳法》确立工人组织工会和集体谈判的权利，并通过最低工资、四十小时工作周和加班工资等制度改善劳动条件；战后福利国家、工会和集体谈判进一步为失业和职业转换提供缓冲。劳动者的诉求因此逐渐由阻止机器转向接受机械化，同时争取工资、福利、培训和补偿。
|
||||
|
||||
这一时期说明，技术革命并不必然导致强烈反弹。只要新技术能够创造替代岗位，生产率红利能够转化为工资和福利，制度又能分担转型成本，劳动者就更可能接受甚至拥抱技术进步。
|
||||
|
||||
______4. 计算机革命与全球化：自动化焦虑转入选举政治______
|
||||
|
||||
20世纪80年代以后，计算机开始大量替代流水线生产、文书处理和基层行政等程序化、重复性较强的工作，同时提高专业人员和管理者等高技能劳动者的生产率。有学者将这一变化概括为"就业极化"：支撑战后中产阶层的制造业和文职岗位不断减少，新增就业则更多集中在高薪专业岗位和低薪服务业[6]。技术进步带来的收益更多流向资本所有者和高技能劳动者，许多没有大学学历的劳动者只能转向工资更低、稳定性更差的服务业。
|
||||
|
||||
全球化进一步加剧了这种分化。自动化减少了工厂对普通劳动力的需求，产业外迁和进口竞争则加快了传统制造业中心的衰落。冲击尤其集中在"锈带"等工业地区，不仅造成制造业岗位流失，还拖累当地服务业、削弱税基和公共服务，使许多社区长期难以恢复[7]。
|
||||
|
||||
蓝领工人失去的也不只是收入。稳定的制造业工作曾使没有大学学历的劳动者也能维持中产生活，获得家庭和社区地位。随着工厂关闭、职业上升通道收窄，经济失落逐渐转化为尊严受损、身份下降以及被精英抛弃的感受[8]。
|
||||
|
||||
与卢德运动不同，这种不满并未主要表现为破坏机器，而是逐渐进入选举政治。自动化过程缓慢而分散，难以找到明确的归责对象；相比之下，工厂外迁、进口商品和移民更容易被政治化。因此，部分由技术变迁造成的经济压力，最终转化为贸易保护、反移民和反精英诉求。
|
||||
|
||||
研究发现，在控制贸易冲击、产业结构等因素后，机器人使用较多的美国地区，2016年大选对特朗普的支持增幅也更大[9]。计算机革命由此形成了一条清晰的政治传导链：蓝领制造业岗位流失、工业社区衰退和工人社会地位下降，共同为民粹主义兴起提供了社会基础。
|
||||
|
||||
______[图片]______
|
||||
|
||||
对AI政治反弹的三条战线：
|
||||
|
||||
劳动、企业权力和地方资源
|
||||
|
||||
与历史上对技术的政治反弹相似，当前AI引发的争议并非对技术本身的笼统拒绝，而是由岗位替代、收益集中和企业转嫁扩张成本引发的利益冲突。劳动者担心失业和技能贬值，中小企业和普通公众担心少数科技企业控制算力、模型和市场入口，地方居民则反对数据中心将电力、水和土地成本转嫁给社区。这三条战线分别围绕劳动保护、科技巨头权力和地方社区资源冲突展开，虽然尚未形成目标统一的运动，却可能共同转化为对科技巨头及现有分配制度的不满。
|
||||
|
||||
______1. 保卫劳动：岗位、技能与补偿之争______
|
||||
|
||||
劳动领域正在出现一种新的"卢德主义式"反抗。其核心诉求是反对企业单方面利用AI取消岗位、复制劳动者技能并削弱其议价权，要求劳动者参与AI部署，并获得就业保障、合理补偿和技术红利。与此前主要冲击工厂和常规性岗位的自动化不同，生成式AI可以直接处理编程、写作、配音、设计和客户服务等认知任务，使这种反抗迅速蔓延至白领、创意劳动者和刚刚进入就业市场的青年。
|
||||
|
||||
尽管宏观就业尚未因AI全面收缩，民众的悲观情绪已经提前形成。进步派政治数据与民调机构蓝玫瑰研究（Blue Rose Research）的调查显示，79%的美国选民担忧政府没有应对AI失业的计划，77%担心旧行业消失快于新行业诞生，72%担心AI压低普通人的工资[10]。在硅谷和年轻白领群体中，人们越来越担心那些无法从AI中获益的人会沦为缺乏经济筹码的"永久底层阶级（permanent underclass）"[11]。
|
||||
|
||||
年轻一代的恐慌尤为剧烈。哈佛民调发现，59%的18—29岁美国人认为AI威胁自己的就业前景，41%担心AI会使工作失去意义[12]。这种不安并非完全脱离现实：斯坦福数字经济实验室发现，生成式AI普及后，在高AI暴露职业中（如软件开发、客户服务），22至25岁的早期职业者就业人数相对下降了16%；相比之下，受影响较小领域的员工以及同一职业中经验更丰富的员工，其就业情况保持稳定或持续增长[13]。
|
||||
|
||||
图1：按不同年龄组劳动者划分的就业指数
|
||||
|
||||
[图片]
|
||||
|
||||
就业焦虑正在由个人担忧转化为集体行动。具体而言，当代"卢德式"反抗主要争夺以下权利：AI部署前的协商权、对自身技能和数据的控制权，以及技术替代后的保障和补偿权。
|
||||
|
||||
在AI部署环节，劳动者要求将AI部署纳入劳资协商。因企业未能提供明确、可执行的AI保护条款，美国电子游戏演员自2024年7月起举行罢工[14]。2026年6月，韩国现代汽车工会把人形机器人的引入列入劳资谈判，要求企业在部署前取得工会同意，并承诺不得以机器人为由单方面裁员、降薪或恶化工作条件[15]。
|
||||
|
||||
劳动者也开始争夺自身技能及其数字化载体的控制权。2026年初，英国演员投票拒绝未经保障的数字全身扫描[16]，德国配音演员则拒绝签署允许Netflix将录音用于AI训练的合同[17]。同年5月，Meta员工因担心数据被用于复制和替代劳动力，联署反对公司在员工电脑上安装鼠标追踪软件、收集员工工作流程数据[18]。
|
||||
|
||||
当AI扩张已经伴随实际裁员时，劳动者开始要求企业提供就业保障和补偿。2026年4月，在甲骨文大规模裁员同时加大AI投入后，超过600名被裁员工联名要求公司提高遣散费、延长医疗保障、加速股权归属[19]。
|
||||
|
||||
劳动者的诉求也开始从防止岗位损失延伸至分享AI红利。全球AI投资推高存储芯片需求，给三星电子带来巨额利润，但工人认为企业没有让劳动者充分分享这轮繁荣。2026年4月，约4万名韩国三星工人举行集会，抗议公司的奖金分配方案，要求取消奖金上限，并将更多营业利润纳入员工奖金池；在谈判陷入僵局后，超过4.5万名工人一度准备举行18天罢工[20]。
|
||||
|
||||
部分行动已经迫使企业让步。美国电子游戏演员经过近一年的罢工，于2025年7月将AI复制声音、形象和动作所需的知情同意、用途披露和报酬机制写入集体合同[21]。面对员工抵制，Meta缩减了数据收集项目，后因数据安全问题将项目暂停[22]。经过五个月的劳资争议，三星同意将半导体业务营业利润的10.5%用于不设上限的特别奖金，使劳动者更直接地分享AI繁荣带来的企业收益，原定罢工随之取消[23]。
|
||||
|
||||
不过，英国演员、德国配音演员、韩国现代汽车工会、甲骨文被裁员工的行动仍处于施压或谈判阶段。总体来看，劳动者对AI的反抗已经开始从抽象的失业担忧转向具体的协商权、数据权、就业保障和利润分享，但成果仍主要集中在工会力量较强、替代风险较直接的行业，尚未形成普遍适用的制度保障。
|
||||
|
||||
______2. 约束科技巨头：数据产权与规则制定权之争______
|
||||
|
||||
与19世纪铁路巨头凭借运输网络决定谁能进入市场、支付多少费用相似，今天的少数大型科技企业能够大规模集中社会数据，并将公共知识和创作者劳动转化为私人资产。更重要的是，由于监管机构难以独立了解模型能力、训练过程和潜在风险，AI企业还在安全标准、风险评估和信息披露等规则制定中占据明显优势。公众争论因此从"是否发展AI"进一步转向：谁有权占有训练数据，以及谁有权制定安全和监管规则。
|
||||
|
||||
公众对企业自我监管和政府约束科技巨头的能力都缺乏信心。皮尤研究中心的调查显示，67%的美国成年人对美国政府"有效监管AI"信心不大或毫无信心[24]；同样，盖洛普（Gallup）民调发现，高达69%的美国人对企业能否负责任地使用AI持"不太信任"或"完全不信任"的态度[25]。2026年5月，CBS与YouGov的调查显示，78%的美国成年人认为AI企业推广AI是为了扩大自身权力[26]。Blue Rose Research的调查还显示，55%的美国选民认为科技公司应为AI造成的岗位损失承担财务责任，49%的美国选民支持对从AI中获利最多的企业征收专项税[27]。对企业权力的警惕正在与财富分配不满结合起来。
|
||||
|
||||
对AI巨头的反抗首先表现为训练数据的产权争夺。作家、艺术家、出版商、媒体和音乐公司相继对AI企业发起侵权诉讼，反对企业未经许可获取作品、建立训练数据库，再将由社会知识和创作者劳动形成的模型能力转化为私人资产。作者群体起诉Anthropic，指控其下载和保存盗版图书用于训练Claude[28]；出版商则起诉谷歌，指控其将原本为其他服务获取的图书用于Gemini训练[29]。这里争议的不只是创作者能否获得报酬，更涉及科技企业能否凭借资金和技术优势，将分散在社会中的知识资源无偿集中到自己的模型之中。
|
||||
|
||||
针对AI资本直接介入选举并影响监管规则，民间组织也开始采取行动。由科技企业高管和投资者支持的"引领未来"（Leading the Future）政治组织网络已筹集超过1.4亿美元，通过多个超级政治行动委员会，支持反对严格州级AI监管的候选人[30]。对此，科技监督、儿童网络安全、残障权益和AI安全等领域的14家民间组织联合呼吁获得其背书的民主党议员和候选人公开拒绝这一支持[31]。美国竞选法律中心（Campaign Legal Center）也向联邦选举委员会提出投诉，指控"引领未来"网络内的两个超级政治行动委员会——American Mission和Think Big——通过新设公司转付竞选费用，隐瞒实际供应商，涉嫌规避联邦支出披露要求[32]。这些组织反对的并非一般政治捐款，而是科技巨头一边宣称拥抱监管，一边利用资金影响立法，使监管规则更符合自身利益。
|
||||
|
||||
极少数反抗已经越出诉讼和政策倡议的范围，转化为针对企业及其高管的暴力攻击。2026年4月，一名20岁男子被控向OpenAI首席执行官山姆·奥特曼位于旧金山的住宅投掷燃烧瓶，他曾发文指责AI高管是"拿孩子们的未来进行赌博"的反社会者。两天后，奥特曼的住宅再次遭遇暴力升级，两名袭击者向其大门开枪。
|
||||
|
||||
这些事件尚不能证明美国已经出现组织化的反AI暴力运动，却表明部分个体开始把对技术失控、就业替代和企业权力的恐惧，集中投射到少数科技高管身上。这种激进化趋势已促使美国国土安全部和FBI等执法部门发出警报，将"反科技暴力极端主义"列为一种正在崛起的新型威胁[33]。
|
||||
|
||||
针对AI巨头的部分行动已经取得实质性成果。Anthropic与作者群体达成的15亿美元和解于2026年7月获得法院最终批准，成为美国已知金额最大的版权和解[34]。相比之下，关于AI监管与规则制定权的博弈依然胶着。尽管美国选民对科技寡头的警惕日益高涨，但面对游说集团的庞大财力以及"输掉AI竞赛"的国家安全叙事，针对AI的联邦级严厉监管与专项税仍停留在政治倡议阶段，公众要从科技巨头手中夺回技术控制权仍面临漫长的拉锯战。
|
||||
|
||||
______3. 保卫地方社区：资源成本与审批权之争______
|
||||
|
||||
模型训练和运行依托的数据中心需要大量电力、水资源和土地，科技企业可以面向全国乃至全球市场获取收益，电价上涨、电网压力、噪声污染和土地占用等成本却正在由项目所在地居民承担。公众争论由此从"是否发展AI"转向数据中心建在哪里、谁承担资源和环境成本，以及地方社区能否参与决策。
|
||||
|
||||
美国民众对数据中心的态度在不到一年内发生了剧烈反转。Heatmap的追踪调查显示，2025年9月，美国人对在本地建设数据中心总体持正面态度（支持率比反对率高2个百分点）；到2026年5月，支持率已降至21%，反对率升至71%，而且同时覆盖两党选民[35]。盖洛普同期调查也显示，71%的美国人反对在当地建设AI数据中心，其中48%强烈反对。反对者中，50%提到电力、水和土地等资源消耗，22%担心生活质量、住房和社区环境受到影响[36]。
|
||||
|
||||
图2：美国不同党派选民对AI数据中心的立场
|
||||
|
||||
[图片]
|
||||
|
||||
来源：Gallup
|
||||
|
||||
当地居民对数据中心的抵制源于其收益与成本在科技企业和社区之间的日益失衡。美国智库新泽西政策透视（NJPP）指出，数据中心是2025年6月新泽西州居民电费上涨20%的主要推手[37]；密歇根大学福特公共政策学院科技与公共政策项目的研究也发现，自Switch数据中心投入建设以来，密歇根州居民电价累计上涨25%，比全美平均水平高17%[38]；与此同时，在普通人承担更高电费的同时，数据中心却可通过大宗购电协议获得更优惠的电价。
|
||||
|
||||
这种不公平感又因有限的就业增长而加剧。科技公司在游说地方政府时，通常会以"创造就业机会"来换取对数据中心项目的税收减免和土地特批。然而现实证明，大多数数据中心的就业主要集中在建设阶段，建成后仅需20至50人运营，这些职位往往由外包人员填补，缺乏工会保护、福利和职业安全感，难以为当地居民提供与资源投入相匹配的长期就业机会[39]。
|
||||
|
||||
对数据中心的抵制已经从单个项目的听证会和请愿，发展为全国性社会动员。2026年7月，保守派团体HumansFirst联合环保组织和地方社区，在全美42个州组织了142场抗议，要求披露项目真实的用电和用水规模，保障居民参与审批，并防止家庭用户通过电费和公共财政为科技企业埋单。参与者横跨保守派地方团体和自由派环保组织，反映数据中心正在成为少数能够跨越党派界限的反科技巨头议题[40]。
|
||||
|
||||
地方反对已经开始直接影响AI基础设施建设。据数据中心项目跟踪组织Data Center Watch统计，仅2026年第一季度，美国就有至少75个、总值约1300亿美元的数据中心项目因地方反对而被取消或延期，规模大致相当于2025年全年[41]。纽约州对耗电50兆瓦以上的新建超大规模数据中心实施一年暂停，成为美国首个采取州级全面暂停措施的州[42]；伊利诺伊州也从2026年7月起暂停向新数据中心提供税收优惠[43]。这一压力也传导至欧洲。苏格兰民族党全国委员会已经通过冻结新建数据中心的动议，并提交苏格兰政府考虑。动议估算，正在规划的24个超大规模数据中心，其总用电需求可能达到苏格兰峰值负荷的1.5倍[44]。
|
||||
|
||||
总体来看，围绕数据中心的反抗已经由单个项目周边的噪声、用水和电费争议，发展为对项目审批权和成本分担方式的政治争夺。数据中心不再只是支撑AI运行的技术设施，而成为AI收益与物理成本如何在科技企业和地方社会之间分配的集中体现。
|
||||
|
||||
______[图片]______
|
||||
|
||||
走向选票的怒火：
|
||||
|
||||
对AI的反弹
|
||||
|
||||
从社会焦虑走向政治动员
|
||||
|
||||
社会焦虑只有被政治力量转化为明确的利益冲突，才会形成真正的政治反弹。当前，民粹力量正把分散的就业焦虑、企业权力垄断和地方资源不满，整合为"科技巨头获利、普通民众买单"的叙事，使AI争论从技术进步转向谁控制技术、谁承担成本、谁分享收益。左右翼民粹力量虽然构建了不同叙事，却共同将矛头指向科技寡头，迫使建制派在推动AI发展的同时加强补偿和成本约束。对AI的反弹由此正从社会情绪走向政策竞争，并可能成为下一轮选举的重要议题。
|
||||
|
||||
______1. 共同的敌人：左右翼民粹如何塑造"科技寡头"______
|
||||
|
||||
AI议题尤其容易被民粹力量动员，因为其受益者高度集中且容易识别——少数科技巨头及其亿万富翁创始人；其成本却分散在就业、电费、水资源、地方财政和财富分配等不同领域。左右翼民粹力量正在做的，正是把这些原本彼此分离的不满，压缩成"科技寡头获利、普通人买单"的共同叙事。
|
||||
|
||||
__左翼民粹将AI纳入资本与劳动之间的分配冲突。__在这一叙事中，AI并不是凭空产生的私人财富，而是建立在公共科研投入、全社会积累的知识以及大量创作者和劳动者提供的数据之上。科技企业利用这些公共资源训练模型，却把利润留给股东，把裁员、技能贬值和职业转型成本留给劳动者。因此，AI问题被重新表述为：谁拥有技术、谁分享收益、谁承担转型代价。
|
||||
|
||||
参议员伯尼·桑德斯、纽约州民主党众议员亚历山德里娅·奥卡西奥-科尔特斯（AOC）等激进左翼正围绕劳动保护、公共所有和社区控制展开政治动员。针对AI和自动化可能替代大量岗位，桑德斯提出不减薪的32小时工作制、"机器人税"、工人董事席位和员工持股，使劳动者分享生产率收益并参与企业决策[45]。他还提出《美国AI主权财富基金法案》，拟对大型AI企业征收一次性50%的股权税，让公众获得投票权、董事会席位和分红[46]。桑德斯与AOC共同推动《AI数据中心暂停法案》，要求在建立劳动、环境和安全保障前暂停数据中心扩张，防止企业将电力和资源成本转嫁给社区[47]。二人的动员逻辑都要求资本承担成本、劳动者分享收益、公众参与决定AI的发展方向。
|
||||
|
||||
与此同时，这套针对"科技寡头"的叙事已不再局限于激进左翼，而是逐步进入民主党的全国性竞选话语。斯坦福大学政治经济学教授安德鲁·霍尔分析约28万封政治筹款邮件发现，2026年民主党实质讨论AI的邮件仍只占0.7%，但已是上年的三倍；在73封相关邮件中，63封把AI描述为威胁，其中26%将其与金钱、寡头和腐败联系起来，直接讨论就业和自动化的邮件占12%[48]。这种迹象表明，AI正在成为民主党重新讲述阶级冲突的新载体。
|
||||
|
||||
__右翼民粹则将AI纳入工作尊严、传统家庭与地方共同体对抗科技精英的叙事。__在这套叙事中，AI不是单纯提高效率的工具，而是由硅谷"科技男爵"主导的社会改造工程：企业获得利润和权力，却将失业、儿童安全风险以及电力和水资源成本留给工人、家庭和小城镇。工作也不只是收入来源，而是个人尊严、家庭责任和社会地位的基础，因而无法通过全民基本收入简单补偿。AI问题因而变成：究竟由科技精英按照利润逻辑塑造社会，还是由普通公民重新取得对技术及其社会影响的控制权[49]。
|
||||
|
||||
史蒂夫·班农和共和党参议员乔什·霍利分别代表了这种主张的激进与制度化版本。班农将大型AI企业视为威胁国家主权和普通公民的科技寡头，主张迫使其交出50%的股权并分配给美国公民，让公众直接分享AI收益[50]。霍利则把政治动员落实为就业、家庭和地方保护：要求企业披露因AI造成的裁员，提出《GRID法案》，要求数据中心自备电源、不得把扩网成本转嫁给居民；并通过《GUARD法案》追究诱导未成年人从事性行为或自残的AI企业责任[51]。
|
||||
|
||||
在反对科技寡头垄断AI权力与收益方面，左右翼正在形成罕见共识。地方层面，双方都要求数据中心承担电网、用水和社区成本；国家层面，双方都开始接受公众应当分享AI资本收益的原则。但这种共识尚未形成统一的政策联盟：左翼更希望通过税收、工会参与和公共持股改变所有权结构，右翼更强调保护就业、企业自担成本和地方否决权。
|
||||
|
||||
______2. 有限的补偿：建制派如何维持AI加速______
|
||||
|
||||
面对不断上升的政治压力，AI企业和建制派的主要回应并不是放慢技术部署，而是通过补偿重新取得AI扩张的社会许可。其基本思路是：继续维持美国在AI竞争中的领先地位，同时用就业保障、收益分享、最低限度的安全护栏、社区补偿降低技术革命的政治阻力。
|
||||
|
||||
第一类回应针对失业焦虑。AI企业和建制派并未主张放慢技术部署，而是试图通过缩短工时、扩大社会保障和创造公共服务岗位，降低自动化的转型成本。OpenAI在《智能时代的产业政策》中提出带有"新政"色彩的方案，包括推行不减薪的32小时工作制、设立类似贸易调整援助的"自动化调整援助计划"，并在AI造成明显就业冲击时提供额外失业保障[52]。
|
||||
|
||||
Anthropic主张根据AI造成的失业程度建立分级响应机制：短期加强就业监测和失业保障，并通过资本账户、工资保险和培训补贴帮助劳动者转型；若AI导致大规模、长期失业，则转向对AI资本收益征税、设立公共财富基金和基本收入，让公众分享AI红利[53]。国会立法者则主张在不减缓美国AI发展的前提下，通过转型基金、再培训、失业保障、税收减免和针对性监管，补偿受冲击劳动者并帮助其适应就业转型[54]。
|
||||
|
||||
第二类回应是让公众分享AI企业的资本收益。与传统的税收转移和失业救济相比，AI企业和政府开始提出让公众直接分享AI资本收益。OpenAI建议建立公共财富基金，由政策制定者和AI公司共同为该基金提供种子资金，通过投资AI公司及广泛采用AI的企业，让每个公民都能获得AI经济增长的股份[55]。政府层面，有消息称特朗普政府正在探讨在AI企业上市前取得少数股权，并将投资收益用于公共支出或全民分红；韩国政府官员则直接要求科技企业与供应商和员工分享AI超额利润。
|
||||
|
||||
第三类回应针对公众对AI失控和企业自我监管的不信任。加利福尼亚、得克萨斯和犹他等州率先通过立法，要求企业披露安全措施，限制高风险应用，并加强对聊天机器人等直接面向公众产品的监管；国会中间派则主张建立前沿模型测试、安全事件报告和风险披露制度。尽管州政府和国会不断提出更严格的监管要求，联邦层面的政策重心仍是通过设置最低限度的安全护栏维持美国在全球AI竞争中的领先地位。联邦政府和AI企业更倾向于依靠自愿审查、行业标准和有限的信息披露，并反对各州分别制定严格规则，以免增加企业合规成本、拖慢技术部署。
|
||||
|
||||
第四类回应针对数据中心与地方社区的冲突。联邦政府主要通过自愿承诺和立法规范，要求AI企业自建或购买新增电力、承担电网改造费用，并公开水电消耗。地方政府开始使用禁建、征税和取消优惠等强制手段，防止企业将基础设施成本转嫁给居民[56]。企业方面则以技术改造和社区补偿争取项目落地。OpenAI承诺为数据中心配套电源和储能设施，微软利用电池调节用电时段[57]。这些回应背后的逻辑是，在继续推动数据中心建设的同时，将水电和基础设施成本纳入企业投资账本，以换取地方支持。
|
||||
|
||||
这些回应的局限，在于其合法性、可信度和制度安排存在内在矛盾。
|
||||
|
||||
首先，公共财富基金、缩短工时和社区补偿主要由企业和政策精英自上而下提出，劳动者与地方社区缺乏参与权，难以构成真正的社会契约[58]。
|
||||
|
||||
其次，这些措施大多以事后补偿换取AI继续扩张，一旦失业和资源冲突加剧，公众诉求可能转向限制部署、强制征税乃至拆分科技巨头。
|
||||
|
||||
再次，AI企业一边倡导财富共享，一边通过政治捐款和游说阻碍监管与问责，削弱了其承诺的可信度。
|
||||
|
||||
最后，政府若同时担任企业股东、产业扶持者和监管者，可能为了保护投资收益而放松安全、反垄断和劳动监管[59]。其根本问题是以有限让利换取AI扩张的"社会许可"，却没有改变技术决策权高度集中的格局。
|
||||
|
||||
______3. 政治的临界点：对AI的政治反弹何时走向全国选举______
|
||||
|
||||
目前，美国社会对AI的焦虑正迅速转化为政治议题，但尚未引发全国性的惩罚性反扑。最接近这一临界点的是数据中心问题。就业变化难以与经济周期和一般产业调整区分开，但数据中心造成的电费上涨、用水压力、土地占用和噪声污染，不仅直接影响特定社区，也有明确的责任方。在2026年美国的中期选举初选阶段，暂停数据中心项目、取消税收优惠和要求企业自建能源供应，已经成为跨党派地方候选人争取选票、回应生活成本危机的筹码。
|
||||
|
||||
对AI的政治反弹能否上升为全国性大选议题，关键在于就业冲击是否显著、责任对象是否清晰，以及政治人物能否将二者整合为具有动员力的政治叙事。安德鲁·霍尔提出，如果失业率因AI上升两个百分点，并形成"AI应对此负责"的清晰公共叙事，真正的民粹反弹就可能开始[60]。
|
||||
|
||||
图3: 美国选民所认为的关键议题变化
|
||||
|
||||
[图片]
|
||||
|
||||
来源：Blue Rose Research[61]
|
||||
|
||||
政治反弹的扩大也会对AI产业造成影响。地方政府对数据中心的否决增多会延长项目周期，提高前期协调和环境审查成本；企业自担电网、水资源和社区补偿，则会削弱算力投资的预期回报。此后，数据中心可能进一步向电力充足、监管宽松的州转移，部分算力投资也可能转向海外。
|
||||
|
||||
政治压力还可能从基础设施成本进一步延伸至利润和控制权。股权税、自动化税和公共持股方案即使尚未落地，也会增加企业对未来利润分配和控制权变化的预期，届时，政治风险和社会摩擦将变成资本开支、融资和估值模型中的长期成本。
|
||||
|
||||
更严格的模型安全和应用监管也会增加企业的合规成本。若前沿模型被要求接受强制测试、风险披露和事故报告，产品发布和迭代周期将被拉长；各州监管规则若继续分化，还会提高全国性部署的难度，并使行业资源进一步向有能力承担合规成本的大型企业集中。
|
||||
|
||||
历史经验表明，对技术的政治反弹通常不会阻止技术进步，却会迫使社会重新调整技术红利的分配方式和发展规则。因此，对AI的政治反弹最可能带来的变化，是终结AI产业不计社会成本的扩张模式。2026年美国中期选举将检验地方层面的资源冲突能否转化为选票，2028年大选的关键则在于，就业冲击能否与反"科技寡头"的政治叙事汇合。一旦二者形成合力，下一次大选争论的就不只是应以多快的速度发展AI，还将涉及谁有权控制与监管AI、谁能够分享其收益，以及需要围绕AI建立怎样的新社会契约。
|
||||
|
||||
[图片]
|
||||
|
||||
参考来源（向上滑动阅览）
|
||||
|
||||
[1] Frey, C. B. (2019). The technology trap: Capital, labor, and power in the age of automation.
|
||||
|
||||
[2] Allen, R. C. (2009). Engels' pause: Technical change, capital accumulation, and inequality in the British industrial revolution. Explorations in Economic History, *46*(4), 418-435. https://www.sciencedirect.com/science/article/pii/S0014498309000199
|
||||
|
||||
[3] 编者注："卢德运动"得名于英国织袜工学徒内德·卢德。据说，他因受到雇主斥责而砸毁了一台织袜机。19世纪初，反对机器替代劳动的工人以他的名字作为象征，自称"卢德将军"的追随者，因此这场以破坏机器为主要形式的工人抗议被称为"卢德运动"。
|
||||
|
||||
[4] Eichengreen, B., Haines, M. R., Jaremski, M. S., & Leblang, D. (2017). Populists at the polls: economic factors in the 1896 presidential election (No. w23932). National Bureau of Economic Research. https://www.nber.org/system/files/working_papers/w23932/w23932.pdf
|
||||
|
||||
[5] R. J. Gordon, 2016, The Rise and Fall of American Growth: The U.S. Standard of Living since the Civil War
|
||||
|
||||
[6] Autor, D. H., & Dorn, D. (2013). The growth of low-skill service jobs and the polarization of the US labor market. American economic review, *103*(5), 1553-1597. https://www.aeaweb.org/articles?id=10.1257/aer.103.5.1553
|
||||
|
||||
[7] Autor, D., Dorn, D., & Hanson, G. H. (2021). On the persistence of the China shock (No. w29401). National Bureau of Economic Research. https://www.nber.org/papers/w29401
|
||||
|
||||
[8] Gidron, N., & Hall, P. A. (2017). The politics of social status: Economic and cultural roots of the populist right. The British journal of sociology, *68*, S57-S84. https://onlinelibrary.wiley.com/doi/abs/10.1111/1468-4446.12319
|
||||
|
||||
[9] Frey, C. B., Berger, T., & Chen, C. (2018). Political machinery: did robots swing the 2016 US presidential election?. Oxford Review of Economic Policy, *34*(3), 418-442. https://academic.oup.com/oxrep/article/34/3/418/5047377
|
||||
|
||||
[10] https://gwern.net/doc/economics/automation/2026-blueroseresearch.pdf
|
||||
|
||||
[11] https://www.nytimes.com/2026/04/30/opinion/ai-labor-work-force-silicon-valley.html
|
||||
|
||||
[12] https://iop.harvard.edu/youth-poll/51st-edition-fall-2025
|
||||
|
||||
[13] https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence/
|
||||
|
||||
[14] https://www.reuters.com/world/us/hollywoods-videogame-performers-go-strike-over-ai-pay-concerns-2024-07-25/
|
||||
|
||||
[15] https://www.wsj.com/business/autos/the-fight-over-humanoid-robots-has-shut-down-a-car-factory-for-the-first-time-d45ac3e1
|
||||
|
||||
[16] https://www.reuters.com/business/world-at-work/uk-actors-vote-reject-digital-scans-ai-rights-push-echoing-hollywood-battles-2025-12-18/
|
||||
|
||||
[17] https://www.tagesschau.de/wirtschaft/synchronsprecher-netflix-ki-100.html
|
||||
|
||||
[18] https://www.reuters.com/sustainability/society-equity/meta-us-employees-organize-protest-against-mouse-tracking-tech-2026-05-12/
|
||||
|
||||
[19] https://techpolicy.press/tech-workers-are-fighting-against-silicon-valleys-ai-push
|
||||
|
||||
[20] https://www.reuters.com/business/world-at-work/samsung-global-ai-boom-spurred-looming-strike-deep-divisions-2026-05-15/
|
||||
|
||||
[21] https://www.sagaftra.org/sag-aftra-members-approve-2025-video-game-agreement
|
||||
|
||||
[22] https://www.reuters.com/world/meta-scales-back-ai-mouse-clicks-tool-citing-employee-concerns-2026-06-02/
|
||||
|
||||
[23] https://www.reuters.com/business/world-at-work/samsungs-unionised-workers-south-korea-approve-wage-deal-2026-05-27/
|
||||
|
||||
[24] https://www.pewresearch.org/internet/2026/06/17/americans-and-ai-2026-chatbots-smart-devices-and-views-on-impact/
|
||||
|
||||
[25] https://www.gallup.com/file/analytics/696014/Gallup-Bentley-University_Business-In-Society%20Survey_2025%20Report.pdf
|
||||
|
||||
[26] https://assets1.cbsnewsstatic.com/hub/hub/cms/prod_cms_alt/file/2026/05/22/7441f284-6319-4e0a-90e1-1a892e0451af/cbs_20260517_ai.pdf
|
||||
|
||||
[27] https://gwern.net/doc/economics/automation/2026-blueroseresearch.pdf
|
||||
|
||||
[28] https://www.reuters.com/technology/artificial-intelligence/authors-sue-anthropic-copyright-infringement-over-ai-training-2024-08-20/
|
||||
|
||||
[29] https://techcrunch.com/2026/07/14/google-faces-another-ai-training-lawsuit-from-major-publishers/
|
||||
|
||||
[30] https://www.politico.com/news/magazine/2026/07/26/ai-super-pac-operatives-profile-01008227
|
||||
|
||||
[31] https://techoversight.org/2026/04/15/coalition-letter-dem-ltf/
|
||||
|
||||
[32] https://campaignlegal.org/document/ai-industry-funded-super-pacs-unlawfully-evaded-transparency-rules-clc-alleges
|
||||
|
||||
[33] https://www.wired.com/story/us-law-enforcement-warns-of-anti-tech-extremism/
|
||||
|
||||
[34] https://www.reuters.com/world/us-judge-approves-anthropics-15-billion-settlement-copyright-lawsuit-2026-07-20/
|
||||
|
||||
[35] https://heatmap.news/politics/americans-oppose-data-centers-poll
|
||||
|
||||
[36] https://news.gallup.com/poll/709772/americans-oppose-data-centers-area.aspx
|
||||
|
||||
[37] https://www.njpp.org/publications/report/fools-gold-the-hidden-costs-of-ai-data-centers-for-new-jersey/
|
||||
|
||||
[38] https://stpp.fordschool.umich.edu/sites/stpp/files/2025-07/stpp-data-centers-2025.pdf
|
||||
|
||||
[39] https://news.harvard.edu/gazette/story/2026/04/why-are-communities-pushing-back-against-data-centers/
|
||||
|
||||
[40] https://www.reuters.com/business/retail-consumer/us-data-center-protests-go-national-backlash-grows-2026-07-18/
|
||||
|
||||
[41] https://www.datacenterwatch.org/q1-2026
|
||||
|
||||
[42] https://www.reuters.com/sustainability/new-york-issues-moratorium-data-centers-2026-07-16/
|
||||
|
||||
[43] https://www.axios.com/local/chicago/2026/06/09/gov-pritzker-slows-down-data-center-development
|
||||
|
||||
[44] https://www.theguardian.com/uk-news/2026/jul/07/scotland-could-freeze-datacentre-projects-in-challenge-to-uks-ai-strategy
|
||||
|
||||
[45] https://www.sanders.senate.gov/op-eds/ai-must-benefit-everyone-not-just-a-handful-of-billionaires/
|
||||
|
||||
[46] https://www.sanders.senate.gov/wp-content/uploads/AmericanAISovereignWealthFundActSummary.pdf
|
||||
|
||||
[47] https://www.sanders.senate.gov/press-releases/news-sanders-ocasio-cortez-announce-ai-data-center-moratorium-act/
|
||||
|
||||
[48] https://freesystems.substack.com/p/ai-is-the-democratic-partys-next
|
||||
|
||||
[49] https://www.politico.com/news/2026/06/13/republicans-ai-josh-hawley-tech-republicans-artificial-intelligence-00961315
|
||||
|
||||
[50] https://www.notus.org/technology/trump-ai-stake-openai
|
||||
|
||||
[51] https://www.hawley.senate.gov/hawley-op-ed-ai-will-control-us-if-we-do-not-control-it/
|
||||
|
||||
[52] https://openai.com/index/industrial-policy-for-the-intelligence-age/
|
||||
|
||||
[53] https://www-cdn.anthropic.com/files/4zrzovbb/website/9ea607a5d67c168093829b701f3a0a6d21156d5.pdf
|
||||
|
||||
[54] https://www.axios.com/2026/07/21/mark-warner-ai-plan
|
||||
|
||||
[55] https://openai.com/index/industrial-policy-for-the-intelligence-age/
|
||||
|
||||
[56] https://www.businessinsider.com/data-center-developers-anxious-after-hochuls-construction-pause-2026-7
|
||||
|
||||
[57] https://www.economist.com/business/2026/06/23/americas-data-centre-backlash-puts-the-ai-boom-at-risk
|
||||
|
||||
[58] https://freesystems.substack.com/p/the-politics-of-jobless-prosperity
|
||||
|
||||
[59] https://www.project-syndicate.org/commentary/dangers-of-governments-taking-stakes-in-ai-firms-by-gabriela-ramos-and-emilija-stojmenova-duh-2026-07
|
||||
|
||||
[60] https://freesystems.substack.com/p/the-politics-of-jobless-prosperity
|
||||
|
||||
[61] https://data.blueroseresearch.org/hubfs/3.16.26%20Odd%20Lots%20AI%20Presentation.pdf
|
||||
|
||||
__下载CF40 APP 解锁更多精彩内容__
|
||||
|
||||
[图片]
|
||||
|
||||
__版面编辑：思琦__｜__责任编辑：思琦__
|
||||
|
||||
__撰文：沙静__
|
||||
|
||||
视觉：李盼 东子
|
||||
|
||||
监制：李俊虎 潘潘
|
||||
@@ -0,0 +1,84 @@
|
||||
# 📊 文章摘要：美国镜鉴：当AI浪潮遭遇政治反弹
|
||||
|
||||
> **原文**：[2026-07-28_美国镜鉴_当AI浪潮遭遇政治反弹.md](./2026-07-28_美国镜鉴_当AI浪潮遭遇政治反弹.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/OLxrS_jzJqz0z6bKIJMsfA
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：CF40研究部
|
||||
> **发布日期**：2026-07-28
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **政治反弹三战线** — 对 AI 的反抗正沿劳动保护、科技巨头权力、地方资源冲突三条战线从社会情绪走向选举政治，最可能的结局是终结 AI 不计社会成本的扩张模式
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文从历史镜鉴出发（工业革命"恩格斯暂停"与卢德运动→铁路时代反垄断→计算机革命就业极化与民粹选举），提出一个完整分析框架：公众对技术的态度由收益分配而非技术本身决定，对 AI 的政治反弹正在三条战线上积蓄——劳动者争夺部署协商权、数据权与补偿分享权，公众质疑科技巨头对数据与规则制定权的垄断，地方社区反对数据中心转嫁电力水资源成本。左右翼民粹正把分散不满整合为"科技寡头获利、普通人买单"的叙事，而建制派以"有限让利换取扩张的社会许可"回应，存在内在矛盾。其价值在于用 61 条参考文献的系统实证，勾勒出 AI 产业面临的政治风险传导链；局限是美国中心视角，数据截至 2026 年中，历史类比不可直接外推至中国。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **政治反弹三条战线** — 劳动保护（岗位/技能/补偿）、科技巨头权力（数据产权/规则制定权）、地方资源冲突（数据中心电水土地成本），尚未形成统一运动，但可能共同转化为对科技巨头与分配制度的不满 `[分类: 范式突破]`（作者搭建的分析框架）
|
||||
2. **历史规律：替代型 vs 赋能型技术** — 卡尔·弗雷区分：赋能型技术提高生产率易被接受，替代型技术导致技能贬值易引发抵制；反弹对象随技术形态演变：机器→垄断企业→选举政治 `[分类: 共识]`
|
||||
3. **白领"新卢德主义"** — 生成式 AI 直接冲击认知任务，抗议蔓延至白领、创意劳动者与青年；斯坦福数据显示高 AI 暴露职业中 22-25 岁早期职业者就业相对下降 16%，但宏观就业尚未全面收缩——担忧先行于冲击 `[分类: 争议]`
|
||||
4. **数据中心是反弹最清晰的焦点** — 收益归企业、成本归社区（电价上涨 20-25%、就业仅 20-50 人/站）；2026 年 Q1 至少 75 个约 1300 亿美元项目因地方反对被取消或延期，成为少数跨党派议题 `[分类: 共识]`
|
||||
5. **左右翼民粹罕见合流** — 共同塑造"科技寡头"叙事，但政策路径不同：左翼（桑德斯/AOC）主张 50% 股权税、机器人税、公共持股；右翼（班农/霍利）强调就业、家庭保护与地方否决权 `[分类: 争议]`
|
||||
6. **建制派四类补偿回应及其内在矛盾** — 工时缩短与转型援助、收益分享（公共财富基金/政府持股）、安全护栏、社区成本分担；但自上而下缺乏参与权、以事后补偿换扩张、企业一边倡导共享一边游说阻碍监管、政府身兼股东与监管者角色冲突 `[分类: 范式突破]`
|
||||
7. **政治临界点条件** — 就业冲击显著 + 责任对象清晰 + 政治叙事整合；安德鲁·霍尔：若失业率因 AI 上升两个百分点并形成"AI 应负责"的公共叙事，真正的民粹反弹可能开始 `[分类: 未探索]`（作者列为 2026 中期选举与 2028 大选的观察变量）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者立论建立在三个假设上：一是"收益与成本分配决定技术接受度"的历史规律在 AI 时代仍然成立；二是美国选举政治是利益冲突的主要出口；三是数据中心资源冲突具有代表性问题性。若 AI 就业冲击在宏观层面长期不显现、或福利制度缓冲强于预期，传导链可能放缓——作者自己也承认"AI 尚未造成全面的宏观就业冲击"，民众悲观情绪是提前形成的。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据充分且多源交叉（61 条参考文献，含斯坦福、皮尤、盖洛普、哈佛民调与一手新闻），并刻意区分"担忧数据"与"实际冲击数据"，逻辑链条从历史→三条战线→民粹动员→建制派回应→临界点完整连贯。个别数字依赖第三方统计口径（如 1300 亿美元项目取消来自 Data Center Watch），且"机器人使用多的地区特朗普支持率更高"这类相关关系不能直接证明因果。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
全文为美国中心视角，欧洲仅零星提及（苏格兰动议），对中国无直接适用性——中国的技术-社会关系、制度出口与分配机制均不同。预测性论断（2026 中期选举、2028 大选）需时间检验；"AI 应负责"的归因在统计上仍有争议（难以与一般产业调整区分，作者在数据中心一节也承认这一点）。历史类比（卢德运动等）的机制相似性不等于强度可比性——AI 的政治反弹目前尚无破坏机器式的暴力主体。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "当前唯一比AI产业增长更快的，可能就是美国人对AI的负面情绪。"（转引《华尔街日报》评语）
|
||||
|
||||
> "对AI的政治反弹最可能带来的变化，是终结AI产业不计社会成本的扩张模式。"
|
||||
|
||||
> "社会焦虑只有被政治力量转化为明确的利益冲突，才会形成真正的政治反弹。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 把零散的社会事件（罢工、诉讼、数据中心抗议、政治捐款）组织进"三战线+民粹整合+建制派回应"的完整分析框架，结构性和解释力强
|
||||
- 实证扎实，数据多源交叉且区分"担忧"与"冲击"，避免简单化的技术悲观或乐观叙事
|
||||
- 对建制派补偿逻辑内在矛盾的剖析（有限让利不改变权力集中格局）是全文最锐利的洞见
|
||||
- 给出了可检验的临界点条件（失业率 +2 个百分点等），为后续追踪提供抓手
|
||||
|
||||
**不足**：
|
||||
- 文章较长、引用密集，核心框架淹没在大量案例中，读感偏重
|
||||
- 对美国内部不同数据来源的口径冲突（如不同民调支持率）未加讨论
|
||||
- 对"政治反弹是否真的会改变 AI 发展速度"这一关键问题，结论偏谨慎宏观，缺乏产业侧推演细节
|
||||
|
||||
**适用场景**：关注 AI 产业政策风险的研究者、AI 出海或海外业务布局的企业决策者、需要理解"技术-社会-政治"互动的产品与技术管理者。
|
||||
|
||||
**关联建议**：可对照阅读作者引用的卡尔·弗雷《The Technology Trap》与 Autor/Dorn 的就业极化研究原著；跟踪 2026 年 11 月美国中期选举与 Data Center Watch 的项目延期数据验证文中假设；对国内读者可延伸思考中国语境下 AI 就业与基础设施成本的分配问题。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,268 @@
|
||||
# vLLM PD 分离
|
||||
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：marcus
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/p6gh4hK25PujQ1UJzFTbLg
|
||||
|
||||
> 本文是 vLLM 基于 Mooncake Connector 实现 PD 分离的源码级机制剖析，覆盖 Proxy 层、请求传递、Scheduler 调度（P producer / D consumer）、Worker 层 RDMA KV Cache 传输、传输后恢复执行、完整时序与关键设计要点。
|
||||
|
||||
---
|
||||
|
||||
## 一、Proxy 层：同一份 Prompt 同时发给 P 和 D
|
||||
|
||||
**是的，Proxy 会把原始 prompt 同时发给 Prefill 和 Decode 节点**，但携带不同的 `kv_transfer_params` 标志：
|
||||
|
||||
```
|
||||
Client Prompt "Hello, how are you?"
|
||||
│
|
||||
▼
|
||||
mooncake_connector_proxy.py
|
||||
│
|
||||
┌────┴────┐
|
||||
▼ ▼
|
||||
Prefill Decode
|
||||
节点 节点
|
||||
```
|
||||
|
||||
**发给 Prefill 节点**（`send_request_to_service`, 第 250–280 行）：
|
||||
|
||||
```
|
||||
req_data["kv_transfer_params"] = {
|
||||
"do_remote_decode": True, # ← "我是 P，算完把 KV 传出去"
|
||||
"do_remote_prefill": False,
|
||||
"transfer_id": f"xfer-{request_id}",
|
||||
}
|
||||
req_data["max_tokens"] = 1 # ← 只算 1 个 token 就停
|
||||
req_data["stream"] = False # ← 不等流式返回
|
||||
```
|
||||
|
||||
以 `asyncio.create_task` fire-and-forget 发送，不等结果。
|
||||
|
||||
**发给 Decode 节点**（`stream_service_response`, 第 283–312 行）：
|
||||
|
||||
```
|
||||
req_data["kv_transfer_params"] = {
|
||||
"do_remote_decode": False,
|
||||
"do_remote_prefill": True, # ← "我是 D，从远端的 P 拉 KV Cache"
|
||||
"remote_bootstrap_addr": ..., # ← P 的 bootstrap 地址
|
||||
"remote_engine_id": ..., # ← P 的 Mooncake engine ID（含 DP rank）
|
||||
"transfer_id": f"xfer-{request_id}",
|
||||
}
|
||||
```
|
||||
|
||||
以流式方式等待返回，逐 chunk 回传客户端。
|
||||
|
||||
**每个请求都有唯一的 `transfer_id`（UUID）**——这是 P 和 D 两端关联同一次 KV Cache 传输的关键标识。
|
||||
|
||||
---
|
||||
|
||||
## 二、请求进入引擎：`kv_transfer_params` 的传递路径
|
||||
|
||||
```
|
||||
Proxy → API Server (SamplingParams.extra_args)
|
||||
→ EngineCoreRequest
|
||||
→ Request.__init__() 提取 kv_transfer_params
|
||||
→ Scheduler 调度
|
||||
→ MooncakeConnector 处理
|
||||
```
|
||||
|
||||
在 `vllm/v1/request.py` 第 116–119 行：
|
||||
|
||||
```
|
||||
if sampling_params.extra_args is not None:
|
||||
self.kv_transfer_params = sampling_params.extra_args.get(
|
||||
"kv_transfer_params"
|
||||
)
|
||||
```
|
||||
|
||||
`kv_transfer_params` 作为 Request 对象的属性一直保留，供 Scheduler 和 KVConnector 使用。
|
||||
|
||||
---
|
||||
|
||||
## 三、Scheduler 调度层：区分本地计算和远程 KV 加载
|
||||
|
||||
这是 PD 分离最核心的逻辑，在 `vllm/v1/core/sched/scheduler.py` 的 `schedule()` 方法中。
|
||||
|
||||
### 3.1 Prefill 节点 (is_kv_producer) 的调度
|
||||
|
||||
当 `do_remote_decode=True` 时：
|
||||
|
||||
1. **`get_num_new_matched_tokens`**（MooncakeConnectorScheduler 第 712–755 行）：返回 `(0, False)`——P 节点不需要加载任何外部 KV，正常计算 prompt。
|
||||
2. **`update_state_after_alloc`**（第 757–805 行）：记录该请求需要将 KV Cache 发送出去：
|
||||
```
|
||||
elif params.get("do_remote_decode"):
|
||||
self._reqs_need_send[request.request_id] = (request, [])
|
||||
```
|
||||
3. **`request_finished`**（第 838–892 行）：当请求完成时（只生成了 1 个 token），不立即释放 block，而是标记为需要异步发送：
|
||||
```
|
||||
if delay_free_blocks:
|
||||
self._reqs_need_send[request.request_id] = (
|
||||
request, self.get_sw_clipped_blocks(block_ids),
|
||||
)
|
||||
return delay_free_blocks, None # ← True = 延迟释放
|
||||
```
|
||||
|
||||
### 3.2 Decode 节点 (is_kv_consumer) 的调度
|
||||
|
||||
当 `do_remote_prefill=True` 时：
|
||||
|
||||
1. **`get_num_new_matched_tokens`**：返回 `(num_prompt_tokens, True)`——告诉 Scheduler："这 N 个 token 的 KV 已经在远端算好了，异步去拉"。
|
||||
```
|
||||
if params.get("do_remote_prefill"):
|
||||
token_ids = request.prompt_token_ids or []
|
||||
count = self._get_remote_prefill_token_count(len(token_ids)) - (
|
||||
num_computed_tokens
|
||||
)
|
||||
if count > 0:
|
||||
return count, True # ← count 是 prompt 长度，True = 异步加载
|
||||
```
|
||||
2. **Scheduler 分配 KV block**（第 953–971 行）：`allocate_slots` 中传入 `num_external_computed_tokens`，并为远程 token 预留 block。关键参数：
|
||||
- `delay_cache_blocks=True` — block 分配了但不立即写入 prefix cache（因为数据还在远端）
|
||||
- `reserved_blocks` — 确保有足够空间完成整个异步传输，防止死锁
|
||||
3. **请求进入 `WAITING_FOR_REMOTE_KVS` 状态**（第 1010–1040 行）：
|
||||
```
|
||||
if load_kv_async:
|
||||
request.status = RequestStatus.WAITING_FOR_REMOTE_KVS
|
||||
step_skipped_waiting.prepend_request(request)
|
||||
request.num_computed_tokens = num_computed_tokens
|
||||
self._inflight_prefills.add(request)
|
||||
# 跳过 zeroing：异步写入可能与 zeroing 竞态
|
||||
```
|
||||
此时 request 被放入 `skipped_waiting` 队列，不会进入 `running` 列表，本轮不参与 GPU 计算。
|
||||
4. **`build_connector_meta`**：将需要 recv 的请求打包成 `MooncakeConnectorMetadata`（含 `remote_engine_id`、`remote_bootstrap_addr`、`transfer_id`、`local_block_ids`），放入 `SchedulerOutput.kv_connector_metadata` 传递给 Worker。
|
||||
|
||||
---
|
||||
|
||||
## 四、Worker 层：Mooncake 的 KV Cache RDMA 传输
|
||||
|
||||
### 4.1 D 节点 Worker：拉取 KV Cache
|
||||
|
||||
**`start_load_kv`**（`MooncakeConnectorWorker`, 第 2028–2039 行）：
|
||||
|
||||
```
|
||||
def start_load_kv(self, metadata: MooncakeConnectorMetadata):
|
||||
if not self.is_kv_producer and metadata.reqs_to_recv:
|
||||
asyncio.run_coroutine_threadsafe(
|
||||
self._start_load_kv(metadata.reqs_to_recv), self.receiver_loop
|
||||
)
|
||||
```
|
||||
|
||||
**`_start_load_kv` → `handle_new_engine_id` → `receive_kv` → `receive_kv_from_single_worker`**：
|
||||
|
||||
1. 首先通过 `_connect_to_prefiller_bootstrap(remote_bootstrap_addr)` 查询 P 节点的 bootstrap server，获取 P 侧所有 TP/PP Worker 的 ZMQ 地址
|
||||
2. 构建 `MooncakeXferMetadata`（第 1825–1840 行），包含：
|
||||
- `remote_hostname`/`remote_port`：D 侧的地址，P 侧用来做 RDMA 写入
|
||||
- `remote_tp_size`/`remote_tp_rank`：TP 拓扑信息
|
||||
- `req_blocks`：`{req_id: (transfer_id, local_block_ids)}`——D 侧已分配的 block ID
|
||||
- `kv_caches_base_addr`/`block_lens`/`kv_block_lens`：D 侧 KV Cache 的物理内存地址和布局
|
||||
3. 通过 ZMQ DEALER socket 向 P 侧对应 TP rank 的 Worker 发送此元数据
|
||||
4. P 侧收到后，通过 RDMA (`batch_transfer_sync_write`) 将 KV Cache 数据直接写入 D 侧的 GPU 内存地址
|
||||
5. 传输完成后，D 侧标记 `finished_recving_reqs`
|
||||
|
||||
### 4.2 P 节点 Worker：推送 KV Cache
|
||||
|
||||
**`record_send_reqs`**（第 2000–2026 行）：P 侧的 Worker 将 Scheduler 传递来的 `reqs_to_send`（含 `transfer_id` 和 `local_block_ids`）记录到 `self.reqs_need_send` 字典。
|
||||
|
||||
**`send_kv_to_decode`**（第 1193–1382 行）：当 D 侧的 ZMQ 请求到达 P 侧时触发，核心逻辑：
|
||||
|
||||
1. **等待 P 端 block 就绪**：`send_meta.ready.wait()`——P 侧的 forward pass 可能尚未完成
|
||||
2. **地址计算**（`_build_transfer_params` 第 1424–1614 行）：
|
||||
- 逐层、逐 block 计算 P 侧源地址和 D 侧目标地址
|
||||
- 处理 TP 异构（不同 TP 大小之间映射）
|
||||
- 处理 HMA（Hybrid Memory Allocator）多 KV group
|
||||
- 处理 Mamba/GDN 状态块
|
||||
3. **RDMA 传输**（`_send_blocks` 第 1622–1651 行）：
|
||||
```
|
||||
ret_value = self.engine.batch_transfer_sync_write(
|
||||
remote_session, src_ptrs, dst_ptrs, lengths
|
||||
)
|
||||
```
|
||||
P 侧直接通过 RDMA/NVLink 将 KV Cache 字节写入 D 侧的 GPU 内存。
|
||||
4. 传输完成后，标记 `finished_sending_reqs`，释放 P 侧的 block。
|
||||
|
||||
---
|
||||
|
||||
## 五、KV Cache 传输完成后：请求恢复执行
|
||||
|
||||
### 5.1 Scheduler 收到传输完成信号
|
||||
|
||||
`update_from_output` → `_update_from_kv_xfer_finished`（第 2713–2740 行）：
|
||||
|
||||
```
|
||||
for req_id in kv_connector_output.finished_recving or ():
|
||||
req = self.requests[req_id]
|
||||
if req.status == RequestStatus.WAITING_FOR_REMOTE_KVS:
|
||||
self.finished_recving_kv_req_ids.add(req_id)
|
||||
```
|
||||
|
||||
### 5.2 下一轮调度时提升请求状态
|
||||
|
||||
`_try_promote_blocked_waiting_request`（第 2677–2711 行）：
|
||||
|
||||
```
|
||||
if request.status == RequestStatus.WAITING_FOR_REMOTE_KVS:
|
||||
if request.request_id not in self.finished_recving_kv_req_ids:
|
||||
return False
|
||||
self._update_waiting_for_remote_kv(request)
|
||||
request.status = RequestStatus.WAITING # 回到正常调度队列
|
||||
```
|
||||
|
||||
`_update_waiting_for_remote_kv`（第 2634–2675 行）：
|
||||
|
||||
- 将接收到的 KV block 写入 prefix cache（`kv_cache_manager.cache_blocks`）
|
||||
- 如果全部 prompt token 都命中，减少 1 个 computed token 以确保最后 1 个 token 被本地重算（用于生成第一个 output token）
|
||||
|
||||
### 5.3 正常调度执行
|
||||
|
||||
此时 request 回到 `WAITING` 状态，在下一轮 `schedule()` 中被正常调度：
|
||||
|
||||
- `num_computed_tokens` 已经包含了外部加载的 token 数
|
||||
- Scheduler 从 `num_computed_tokens` 之后开始分配新的 compute
|
||||
- 新分配的 token（通常只有 1 个 decode token）在本地 GPU 上执行
|
||||
|
||||
---
|
||||
|
||||
## 六、完整时序总结
|
||||
|
||||
```
|
||||
┌─ Proxy ──────────────────────────────────────────────────────────────┐
|
||||
│ ① POST /v1/chat/completions {"messages": [...], "max_tokens": 100} │
|
||||
│ ② asyncio.create_task() ③ Stream Decode Response │
|
||||
│ → P Node (fire & forget) → D Node (等待返回) │
|
||||
│ kv_transfer_params: kv_transfer_params: │
|
||||
│ do_remote_decode=True do_remote_prefill=True │
|
||||
│ max_tokens=1 remote_bootstrap_addr=<P地址> │
|
||||
│ stream=False remote_engine_id=<P engine id> │
|
||||
│ transfer_id=xfer-UUID transfer_id=xfer-UUID │
|
||||
└───────┬─────────────────────────────────┬───────────────────────────┘
|
||||
┌───────▼── P Node ───────────┐ ┌───────▼── D Node ────────────────────┐
|
||||
│ ④ Request 进入 Scheduler │ │ ⑤ Request 进入 Scheduler │
|
||||
│ is_kv_producer=True │ │ is_kv_consumer=True │
|
||||
│ ⑥ get_num_new_matched_tokens │ │ ⑦ get_num_new_matched_tokens │
|
||||
│ → (0, False) 正常计算 │ │ → (N_prompt, True) 远端加载 │
|
||||
│ ⑧ Scheduler 分配 block │ │ ⑨ Scheduler 分配 block │
|
||||
│ → RUNNING 状态 │ │ → WAITING_FOR_REMOTE_KVS 状态 │
|
||||
│ ⑩ GPU forward pass │ │ ⑪ Worker.start_load_kv() │
|
||||
│ KV Cache 写入本地显存 │ │ → ZMQ 发送 MooncakeXferMetadata │
|
||||
│ ⑫ send_kv_to_decode() │ │ （含 D 侧 block 物理地址） │
|
||||
│ ← ZMQ 收到 D 的请求 │◄───── ZMQ ────────────────────────────│
|
||||
│ → batch_transfer_sync_write│ │ │
|
||||
│ → RDMA 写入 D 侧 GPU 显存 ═══════ RDMA/NVLink ═══════════════════► │
|
||||
│ ⑬ finished_sending_reqs │ │ ⑭ finished_recving_reqs │
|
||||
│ 释放 P 侧 block │ │ ⑮ WAITING_FOR_REMOTE_KVS → WAITING │
|
||||
│ │ │ ⑯ 下一轮 schedule() 正常调度 decode │
|
||||
│ │ │ ⑰ GPU forward pass 自回归生成 output │
|
||||
│ │ │ ⑱ 流式返回 tokens → Proxy → Client │
|
||||
└──────────────────────────────┘ └──────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 七、关键设计要点
|
||||
|
||||
1. **P 和 D 收到的 prompt 完全一致**，但通过 `kv_transfer_params` 标志区分行为。P 正常计算整个 prompt，D 跳过本地计算而从 P 拉取 KV Cache。
|
||||
2. **`transfer_id` 是连接 P/D 的关键**：Proxy 生成 UUID，同时发给 P 和 D。P 侧通过 `reqs_need_send[transfer_id]` 等待 D 侧通过 ZMQ 发来的拉取请求（携带同样的 `transfer_id`），从而匹配同一请求。
|
||||
3. **D 侧 block 物理地址是传输的基础**：D 侧在 `receive_kv_from_single_worker` 中将自己的 `kv_caches_base_addr` + `block_lens` + `block_ids` 发给 P，P 侧据此计算出 RDMA 的目标地址，直接写入 D 的 GPU 显存。
|
||||
4. **异步非阻塞设计**：D 侧在等待 KV 传输时处于 `WAITING_FOR_REMOTE_KVS` 状态，不占用 GPU 计算资源。同时 P 侧的发送也通过独立的后台线程池异步执行，不阻塞 P 的 forward pass。
|
||||
5. **`remote_engine_id` 区分不同 DP rank 的 KV Cache**：在 DP（数据并行）场景下，每个 DP rank 有独立的 KV Cache 分区。`remote_engine_id` 包含 `engine_id_dp{N}` 后缀，精确定位到哪个 DP rank 的 KV Cache。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：vLLM PD 分离
|
||||
|
||||
> **原文**：[2026-08-05_vLLM_PD分离_源码级机制_marcus.md](./2026-08-05_vLLM_PD分离_源码级机制_marcus.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/p6gh4hK25PujQ1UJzFTbLg
|
||||
> **来源**：微信公众平台（marcus）
|
||||
> **作者**：marcus
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **源码级解构** — 把 PD 分离从概念论述落到 vLLM + Mooncake Connector 的代码行号级机制，是本批 PD 分离文章中唯一触及实现细节的第一手资料。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文逐层拆解 vLLM 基于 Mooncake Connector 实现 PD 分离的完整代码路径：Proxy 将同一 prompt 双发至 P/D 节点并携带不同标志、Scheduler 通过 `WAITING_FOR_REMOTE_KVS` 状态机暂停等待远端 KV、Worker 层经 ZMQ 握手后以 RDMA 将 KV Cache 直写 D 侧 GPU 显存、传输完成后请求恢复调度。其价值在于回答了其他文章不回答的"怎么实现"问题——`transfer_id` 如何关联 P/D、D 侧 block 物理地址如何成为传输基础、为何要"少算 1 个 token 本地重算"。局限在于只覆盖 Mooncake Connector 一种实现，无性能数据，不讨论 P:D 配比与传输延迟等工程参数。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Proxy 双发请求** — 同一 prompt 同时发给 P 和 D，靠 `kv_transfer_params` 标志区分角色：P 侧 `do_remote_decode=True` 且 `max_tokens=1` fire-and-forget，D 侧 `do_remote_prefill=True` 流式等待返回。 `[分类: 共识]`
|
||||
2. **`transfer_id` 关联机制** — Proxy 生成 UUID 同时发给两端，P 侧以 `reqs_need_send[transfer_id]` 等待 D 侧经 ZMQ 发来的拉取请求，是 P/D 匹配同一请求的唯一纽带。 `[分类: 共识]`
|
||||
3. **D 侧调度暂停态** — `WAITING_FOR_REMOTE_KVS` 状态下请求不进入 running 队列、不占 GPU 计算资源，并跳过 zeroing 以避免与异步写入竞态；`reserved_blocks` 预留空间防死锁。 `[分类: 共识]`
|
||||
4. **RDMA 直写远端显存** — D 侧将自己的 `kv_caches_base_addr`/`block_lens`/`block_ids` 经 ZMQ 发给 P，P 用 `batch_transfer_sync_write` 直接写入 D 的 GPU 内存，D 侧零计算加载；`remote_engine_id` 的 DP rank 后缀用于定位不同数据并行分区的 KV。 `[分类: 共识]`
|
||||
5. **传输后恢复执行** — 完成后 KV 写入 prefix cache，并故意减少 1 个 computed token 让最后 1 个 prompt token 本地重算以生成首个输出 token；P 侧发送走后台线程池，不阻塞 forward pass。 `[分类: 共识]`
|
||||
6. **机制层面未触及的性能问题** — 全文只讲"如何实现"不讲"收益几何"，P:D 比例、传输延迟、SLO 达成等维度完全缺席，需与性能类文章（如 DistServe 解读）互补阅读。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者立论建立在三个前提上：读者熟悉 vLLM v1 架构与 Mooncake 生态；该实现路径是 PD 分离的"典型范式"——但 SGLang、TensorRT-LLM 等引擎的实现机制并不相同；RDMA/NVLink 高速互联为默认可用资源。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据为具体源码行号（`scheduler.py` 712-755 行、`MooncakeConnectorWorker` 2028-2039 行等），证据直接、链条完整，从请求进入、调度、传输到恢复执行全程无逻辑跳跃，可信度高。但全文无任何运行数据或基准测试，无法证明"这套机制实际有效、开销几何"——机制正确性与性能有效性是两回事。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论仅适用于 vLLM + Mooncake Connector 这一特定组合；文中机制（如延迟释放 block、传输后减少 1 个 computed token）属于工程实现细节而非普适原理；不适用于评估 PD 分离的收益/代价，也不覆盖 D 节点等待期间的整体调度吞吐影响。对只想了解 PD 分离概念与价值的读者，本文过于深入。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "每个请求都有唯一的 `transfer_id`（UUID）——这是 P 和 D 两端关联同一次 KV Cache 传输的关键标识。"
|
||||
|
||||
> "P 和 D 收到的 prompt 完全一致，但通过 `kv_transfer_params` 标志区分行为。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 全链路（Proxy→Scheduler→Worker→恢复执行）代码级剖析，行号精确，是稀缺的一手工程资料
|
||||
- 清晰回答了"KV 如何从 P 到 D、请求如何暂停与恢复"这一概念文章普遍回避的实现问题
|
||||
- 时序图（完整时序总结）直观完整，可作为机制速查图
|
||||
|
||||
**不足**：
|
||||
- 无任何性能数据，机制正确性与性能收益之间留白
|
||||
- 未讨论 P:D 配置、传输延迟、失败处理等工程参数
|
||||
- 依赖 Mooncake Connector 特定实现，通用性未说明
|
||||
|
||||
**适用场景**：推理系统工程师、vLLM 二次开发者、想从"知道 PD 分离"进阶到"读懂 PD 分离代码"的读者；面试中需要讲解 PD 分离实现细节时的高价值素材。
|
||||
|
||||
**关联建议**：搭配本文同批的 DistServe 解读（原理与收益）与丁师兄文章（落地代价）构成"原理—机制—代价"完整链条；可进一步阅读 vLLM `v1/core/sched/scheduler.py` 中 `MooncakeConnectorScheduler` 与 `MooncakeConnectorWorker` 的完整源码，以及 Mooncake 项目关于 KVCache 传输的官方文档。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,84 @@
|
||||
# LLM 做 PD 分离后，怎么更慢了？
|
||||
|
||||
> **来源**：微信公众平台（丁师兄）
|
||||
> **作者**：丁师兄（专注于智能驾驶大模型，LLM 面试干货分享）
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/0HlmtIuPGU7QE5r1fyhcsA
|
||||
|
||||
> 面试题视角：PD分离实际落地会遇到什么问题。从"代价/坑"的角度讲 PD分离的 5 大问题——KV Cache 传输开销、生产者-消费者不平衡、调度复杂度、显存压力与碎片化、P:D 比例敏感性。与只讲红利的文章形成互补。
|
||||
|
||||
---
|
||||
|
||||
> 编者按（丁师兄）：前不久有个学员面试完回来说，面试官问"PD 分离听起来挺好的，那你说说实际落地会遇到什么问题？"他当时愣了一下，只答出了网络传输这一点。这道题考的就是你有没有真正理解过生产环境的复杂性。PD 分离现在是个热门话题，vLLM、SGLang 都在推，Meta 和 Kimi 也在用，但真要把它跑起来，坑可不少。
|
||||
|
||||
## 01 先理解 PD 分离在解决什么
|
||||
|
||||
LLM 推理分两个阶段：Prefill 阶段是计算密集型的，把整个 prompt 并行处理完，生成 KV Cache；Decode 阶段是内存密集型的，逐个 token 串行生成，频繁读写 KV Cache。这两个阶段的资源需求完全相反，混在一起跑会互相干扰。
|
||||
|
||||
所以 PD 分离就是把这两个阶段拆到不同的 GPU 上去执行。Prefill 用高算力卡，Decode 用高带宽卡，听起来很美好对吧？但工业界真正落地的时候，问题就来了。
|
||||
|
||||
## 02 第一个大坑：KV Cache 传输开销
|
||||
|
||||
最核心的问题——KV Cache 的传输成本。Prefill 阶段算完之后，得把整个 KV Cache 传给 Decode 阶段。
|
||||
|
||||
拿 **Llama-3.1-70B** 举例，一个请求的 KV Cache 大概是 **1.34GB**。这是单个请求。如果 TTFT 要求 500ms 以内，Prefill 本身可能就要 200ms，留给传输的时间只有 300ms 左右。
|
||||
|
||||
这时候网络就成了瓶颈：
|
||||
- **10GbE**：传这 1.34GB 要 1 秒多，根本不够用；
|
||||
- **25GbE**：勉强 400 多毫秒，也很紧张；
|
||||
- **InfiniBand HDR 或 NVLink**：才能压到几十毫秒甚至几毫秒。
|
||||
|
||||
如果传输开销超过了分离带来的性能收益，整个架构就白搭了。这就是为什么 PD 分离必须要有高速互联网络支持，不是随便拿几台机器就能做的。Meta、Kimi 在生产环境用的都是专门的高速网络，这个成本不低。
|
||||
|
||||
## 03 第二个问题：生产者-消费者不平衡
|
||||
|
||||
Prefill 和 Decode 之间的负载不均衡，取决于工作负载特征：
|
||||
|
||||
- **短 prompt、长输出**（用户问一句，模型生成一大段）：Decode 压力大，需要 **1P3D**；
|
||||
- **长上下文**（文档总结、代码分析，prompt 几千 token，输出不长）：Prefill 成瓶颈，反过来配 **3P1D**。
|
||||
|
||||
问题在于真实业务流量是动态变化的——上午都是短问答，下午突然来一批长文档处理。如果 P:D 比例是静态配置的，就会出现一边资源闲置、另一边排队等待。这就需要动态调度和弹性伸缩，但又增加了系统复杂度。
|
||||
|
||||
有篇论文专门研究了这个，发现当 Prompt/Output 比例变化时，不同 P:D 配置的性能曲线会交叉——没有一个万能配置，必须根据实际 workload 调整。
|
||||
|
||||
## 04 第三个问题：调度复杂度飙升
|
||||
|
||||
传统架构里调度器只管一个队列。PD 分离之后调度逻辑复杂多了：
|
||||
|
||||
调度器要实时决策：请求分配给哪个 Prefill 实例？Prefill 完成后 KV Cache 传给哪个 Decode 实例？要考虑各节点负载、显存剩余、KV Cache 复用率、网络拓扑等。
|
||||
|
||||
更麻烦的是 Prefill 和 Decode 的协调：Prefill 做完了 Decode 还在忙，KV Cache 传不过去只能等；或者 Decode 空闲了 Prefill 还没准备好，又是浪费。这种生产者-消费者同步问题，在高并发场景下特别容易出现气泡（资源利用率的空洞）。
|
||||
|
||||
DistServe 和 Mooncake 设计了非常复杂的调度算法。Mooncake 甚至搞了三层架构：Prefill 集群、Decode 集群，还有专门的 Caching 集群管理 KV Cache——这个复杂度对小团队维护成本很高。
|
||||
|
||||
## 05 第四个问题：显存压力和碎片化
|
||||
|
||||
Prefill 阶段可能同时处理多个请求，每个都要生成 KV Cache，显存占用瞬间飙升。Decode 阶段更惨，要保留所有在生成中请求的完整 KV Cache，随生成长度增加 Cache 还在不断增长。
|
||||
|
||||
虽然有 PagedAttention 缓解碎片化，但 PD 分离后 KV Cache 的生命周期跨越两个不同节点，管理更复杂——要确保 Prefill 生成的 Cache 高效映射到 Decode 节点显存，还要处理释放和复用时机。管理不好会出现一边频繁 OOM、另一边大量闲置。
|
||||
|
||||
## 06 第五个问题：P:D 比例的敏感性
|
||||
|
||||
一篇 Medium 文章做了个实验，测试 1P3D、2P2D、3P1D 三种配置。结果发现性能曲线会随 Prompt/Output 比例变化而交叉——某个 workload 下最优的配置，换个 workload 可能变成最差。
|
||||
|
||||
本质是 Prefill 和 Decode 的瓶颈切换不是平滑的，而是突变的。workload 从 Decode 密集切换到 Prefill 密集时，系统性能可能断崖式下跌。所以真正做得好的系统需要实时监控 workload 特征、动态调整 P:D 比例——但这又回到调度复杂度问题，是个循环依赖。
|
||||
|
||||
> 从上图可以看出，PD 分离可以提高 decoding 部分的效率。但从 TP2 变成 1P1D，prefilling 的卡减少，大 bs、长输入时会导致 TTFT 变长。另外因为 prefill 的计算量大，decoder 阶段的传输量大，因此 PD 分离可以对两个阶段使用不同类型的显卡，最大化性价比。
|
||||
|
||||
## 07 总结
|
||||
|
||||
如果被问"PD 分离背后可能出现什么问题"，可以从这几个维度答：
|
||||
|
||||
1. **KV Cache 传输开销**（最核心）：强调网络带宽要求，算传输时间，说明为什么需要 InfiniBand 或 NVLink 级互联；
|
||||
2. **负载不均衡**：不同 workload 下 P:D 比例需求不同，静态配置导致资源浪费；
|
||||
3. **调度复杂度**：生产者-消费者同步、资源分配决策、气泡问题；
|
||||
4. **显存管理**：KV Cache 跨节点生命周期管理、碎片化、OOM 风险；
|
||||
5. **性能对 workload 敏感性**：没有万能配置，需要动态调整。
|
||||
|
||||
如果追问"怎么解决"，可以说业界方案：高速网络、智能调度算法、动态伸缩、KV Cache 压缩和复用等。提一下 DistServe、Mooncake 这些系统的实践，会显得对前沿有了解。
|
||||
|
||||
> 这道题考的不是让你背八股，而是看你有没有真正理解生产环境的复杂性。
|
||||
|
||||
---
|
||||
|
||||
> 编者：丁师兄，专注智能驾驶大模型，持续分享 LLM 面试干货；大模型 1v1 辅导。微信：dsxaigc
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：LLM 做 PD 分离后，怎么更慢了？
|
||||
|
||||
> **原文**：[2026-08-05_LLM做PD分离后怎么更慢了_丁师兄.md](./2026-08-05_LLM做PD分离后怎么更慢了_丁师兄.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/0HlmtIuPGU7QE5r1fyhcsA
|
||||
> **来源**：微信公众平台（丁师兄）
|
||||
> **作者**：丁师兄（专注智能驾驶大模型，LLM 面试干货分享）
|
||||
> **发布日期**：2026-08-05（原文未标注日期，按下载日占位）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **落地五坑** — 从生产环境视角系统列出 PD 分离的 5 大落地问题（KV 传输、负载失衡、调度复杂度、显存管理、P:D 敏感性），是与清一色"红利派"文章互补的"代价派"清单。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文以面试题"PD 分离实际落地会遇到什么问题"切入，系统梳理了 PD 分离生产落地的 5 大坑：KV Cache 传输开销（Llama-3.1-70B 单请求 1.34GB，10GbE 传 1 秒以上，需 IB/NVLink 级互联）、生产者-消费者不平衡（workload 动态变化使静态 P:D 配置失效）、调度复杂度飙升（双实例决策与气泡问题）、显存压力与跨节点生命周期管理、P:D 比例对 workload 的高度敏感性（性能曲线交叉、断崖式下跌）。其价值在于提供了本批文章中唯一完整的"反面清单"，并给出了可直接计算的量化示例；局限是数字多为估算与二手引用，无第一手实验，且"如何解决"仅点到业界方案名称。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **KV Cache 传输是最大坑** — Llama-3.1-70B 单请求 KV 约 1.34GB，TTFT 500ms 预算下 Prefill 占 200ms 后仅剩约 300ms 传输窗口：10GbE 需 1 秒+、25GbE 勉强 400 多毫秒，只有 InfiniBand/NVLink 才能压到几十毫秒级；"传输开销超过分离收益则整个架构白搭"。 `[分类: 共识]`
|
||||
2. **P:D 比例无万能配置** — 短 prompt 长输出需 1P3D，长上下文需 3P1D；真实业务流量动态变化，静态配置必出现一边闲置一边排队；论文与 Medium 实验均显示不同 Prompt/Output 比例下性能曲线交叉。 `[分类: 共识]`
|
||||
3. **调度复杂度飙升** — 调度器从单队列变为实时决策"请求分给哪个 P、KV 传给哪个 D"；生产者-消费者同步在高并发下产生气泡；Mooncake 的三层架构（P/D/Caching 集群）对小团队维护成本高。 `[分类: 共识]`
|
||||
4. **显存管理与碎片化** — KV Cache 生命周期跨越两个节点，PagedAttention 只能缓解单节点碎片；P/D 两侧的释放与复用时机协调不当会出现"一边频繁 OOM、另一边大量闲置"。 `[分类: 共识]`
|
||||
5. **瓶颈切换是突变而非平滑** — workload 从 Decode 密集切到 Prefill 密集时性能可能断崖式下跌；动态调整 P:D 又依赖实时监控与调度，与问题 3 形成循环依赖——这是动态 P:D 配比至今未成熟解决的深层原因。 `[分类: 未探索]`
|
||||
6. **应对方向的业界共识** — 高速网络、智能调度算法、动态伸缩、KV Cache 压缩与复用，并以 DistServe、Mooncake 为前沿实践代表。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论假设 PD 分离的收益已成立（文章未质疑分离本身，只质疑落地方式）；同时隐含假设读者已具备 PD 分离基本概念；"动态 workload"是常态这一前提放大了静态配比的缺陷，但未讨论可预测负载（如离线批处理）场景下静态配比的适用性。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
五个问题维度划分清晰、逻辑自洽，KV 传输的量化示例（1.34GB、300ms 窗口、各网络档位耗时）可直接复算，说服力强。但 P:D 敏感性结论仅转述"有篇论文"与"一篇 Medium 文章"，未给出论文名与数据来源，引用严谨性不足；部分数字（10GbE 传 1 秒多）为估算，未提供计算公式；"问题清单"完整但"解决路径"止于名词罗列。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论针对"动态生产流量下的在线推理"场景，对负载稳定的离线批量场景不适用；KV 传输开销的判断以 Llama-3.1-70B 为样本，对 KV 更小的 MoE 模型（如 DeepSeek）或 KV 压缩技术下的传输量需重新评估——其悲观程度与 DistServe 论文"传输可隐藏"的乐观结论形成对照，真实答案取决于网络与模型的具体组合；文章未覆盖传输与计算重叠（overlap）等已有缓解技术。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "这道题考的不是让你背八股，而是看你有没有真正理解生产环境的复杂性。"
|
||||
|
||||
> "如果传输开销超过了分离带来的性能收益，整个架构就白搭了。"
|
||||
|
||||
> "没有万能配置，必须根据实际 workload 调整。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 本批 PD 分离文章中唯一的系统性"代价清单"，与红利派文章形成强互补
|
||||
- KV 传输量化示例具体可复算（1.34GB、300ms 窗口），可直接用于面试与方案评估
|
||||
- 明确点出 P:D 敏感性、瓶颈突变、动态调整循环依赖等常被忽视的深层问题
|
||||
|
||||
**不足**：
|
||||
- 关键结论依赖未具名的二手引用，严谨性不足
|
||||
- 无第一手实验数据，数字多为估算
|
||||
- "怎么解决"止于业界方案名称，缺少可操作建议
|
||||
|
||||
**适用场景**：准备 LLM 推理面试的候选人；正在评估 PD 分离方案的架构师与运维团队（决策前的风险清单）；与红利派文章对照理解 PD 分离全貌的读者。
|
||||
|
||||
**关联建议**：与本批新智元 DistServe 文章对照阅读，可见"传输可隐藏 vs 传输是大坑"的张力本质是网络条件与模型规模假设不同；与本批 marcus 的 vLLM 源码文章串联，可理解调度复杂度在代码层的具体表现；进一步可阅读 Mooncake 论文（KVCache 复用与缓存集群）与 DistServe 论文中关于调度算法的章节。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,138 @@
|
||||
# 当 PD 分离成为标配，推理的未来在 AFD
|
||||
|
||||
> **来源**：微信公众平台（小哥人工智能笔记）
|
||||
> **作者**：小哥人工智能笔记
|
||||
> **发布日期**：2026-08-05（原文未标注明确日期，按下载日占位；解读论文 arXiv:2605.28302 为 2026-05）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/5YsLOl4oIfHzNdi8pbmURQ
|
||||
|
||||
---
|
||||
|
||||
> 推荐理由：在 PD 分离已经成为集群分布式推理标配的时候，推理系统未来的方向走向了 AFD，这篇文章不是从 AFD 方案本身入手，而是从 AFD 的建模配比入手，给出指导。
|
||||
|
||||
过去两年，大模型推理系统的（disaggregation）浪潮走得比大多数人想象得更快。先是 chunked-prefill 把 prefill 和 decode 塞进同一个批次；接着 prefill–decode（P/D）分离把计算密集的 prefill 与访存密集的 decode 拆到不同机器池；而现在，Georgia Tech、Intel、Google、Google DeepMind 联合的一篇工作（arXiv:2605.28302《How Far Can Disaggregation Go?》）把解聚的刀进一步切进了每一个 Transformer 块内部——把 Attention（注意力）和 FFN（前馈网络）也拆到不同的 GPU 组上执行。这种被称为 **Attention–FFN Disaggregation（AFD，注意力–前馈解聚）** 的算子级解聚，正是继 PD 分离之后，MoE（混合专家）大模型推理最值得关注的基础设施方向。
|
||||
|
||||
这篇文章不是又一篇「我做了一个系统」的论文，而是用一套建模框架 AIC++，系统地把「到底要不要解聚、解到哪一层才划算」这件事算清楚了。它的结论对做智算中心、推理 Infra、以及所有关心 MoE 模型规模化部署的人，都有很强的指导意义：**AFD 在严格延迟 SLO 下能撑起约 4k tokens/s 的系统吞吐，而在非 AFD 部署根本无法运行的 1M 前缀长上下文场景里，AFD 是唯一可行的解。**换句话说，AFD 的价值不只是「更快」，更是在特定战场上「能不能跑」。
|
||||
|
||||
## 零、为什么「解聚」是智算中心绕不开的命题
|
||||
|
||||
在谈 AFD 之前，得先说清一个更底层的判断：为什么「解聚」会成为大模型推理系统的主流范式？根本原因是 Transformer 推理天然是**两段式、且两段瓶颈完全不同**的。Prefill 阶段要处理整段输入、一次性生成全部 KV 缓存，算力（FLOPs）主导，理论上限由 GPU 的算术吞吐决定；Decode 阶段逐 token 自回归生成，每一步只算一个 token 却要读写整份 KV 缓存，瓶颈在显存带宽（memory bandwidth），GPU 的算力在这里大量闲置。把这两段塞在同一张卡上，要么 prefill 占着算力把 decode 饿着，要么 decode 占着带宽把 prefill 拖慢，气泡（bubble）巨大。
|
||||
|
||||
PD 分离的本质，就是把这两段按各自瓶颈拆到不同硬件池，让 prefill 池专心吃算力、decode 池专心喂带宽，再通过 KV 缓存的跨节点传输把两段衔接起来。这套思路已经在 vLLM、SGLang、TensorRT-LLM 等主流引擎里成了默认配置。但论文敏锐地指出：**PD 分离仍然把每个 Transformer 块当作一个「不可分割的整体」**，而 MoE 这类模型在块内部，Attention 和 FFN 的异质性就已经大到不能忽略——于是解聚的下一刀，自然落在了块内部。这也是为什么 AFD 被定义为「叠在 PD 之上的下一级解聚」，而不是它的替代者。
|
||||
|
||||
## 一、解聚的三级跳：从 chunked-prefill 到 AFD
|
||||
|
||||
要理解 AFD 为什么重要，得先看清推理解聚的演进脉络。现代 LLM 推理天然分成 prefill（处理整段输入、生成 KV 缓存，计算密集）和 decode（逐 token 自回归生成，访存密集，受 KV 缓存带宽制约）两个阶段。早期的 chunked-prefill（Sarathi, 2023）只是把长 prefill 切成块塞进 decode 批次，减少气泡；PD 分离（DistServe, 2024；Splitwise, 2023）则把两个阶段放到独立硬件池，各自按自己的瓶颈扩展。
|
||||
|
||||
但 PD 分离仍然把每个 Transformer 块当作一个「不可分割的整体」。而论文指出，对于 MoE 这类模型，同一个块内部的异质性就已经非常显著：Attention（尤其是 MHA/GQA/MLA 变体）主要是**访存密集、状态密集**（KV 缓存读写主导）；FFN（特别是 MoE 的 expert FFN）则是**计算密集**（被稠密 GEMM 主导）。MegaScale-Infer（2025）已经证明，在巨大的异构模型上，粗粒度抽象会失效。AFD 就是把 Attention 和 FFN 算子也分开部署，让「状态重的注意力」和「无状态的计算密集 FFN」各自拥有独立伸缩的 GPU 池。
|
||||
|
||||
论文把这套层级画在 Figure 1 的 AIC++ 框架总览里：设计空间同时覆盖 token 级并行（DP/SP/TP/PP/EP）、阶段级 P/D 分离、以及算子级 A/F 解聚。换句话说，AFD 不是 PD 的替代品，而是叠在 PD 之上的下一级解聚。
|
||||
|
||||
表：推理解聚的三级跳对比（演进逻辑，非论文原表）
|
||||
|
||||
| 解聚层级 | 切分对象 | 主要解决 | 典型收益 | 主要代价 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| chunked-prefill | 长 prefill 切块 | 批次内气泡 | GPU 利用率提升 | 无独立伸缩 |
|
||||
| P/D 分离 | prefill vs decode | 算力 vs 带宽瓶颈错配 | TTFT/TPOT 各自优化 | KV 跨节点传输 |
|
||||
| A/F 解聚（AFD） | Attention vs FFN | 块内访存 vs 计算错配 | rate-matching + 显存切分 | 层内 A2F/F2A 通信 |
|
||||
|
||||
## 二、为什么 Attention 和 FFN 必须分开算：异构性的量化证据
|
||||
|
||||
AFD 的合理性，根植于 Attention 与 FFN 在执行特性上的根本差异。论文用 Figure 3 把四种代表性架构在四种上下文长度下的**运行时占比**和**显存占比**做了分解，结论非常直观：
|
||||
|
||||
- **稠密 GQA 架构**（如 GPT-OSS-120B、Qwen3-235B）：在长上下文下高度 Attention 主导——4K 上下文时 Attention 占运行时约 41%/59%，到 0.5M 上下文时 Attention 占比飙到 87%/96%。
|
||||
- **稀疏注意力架构**（DeepSeek-V3.2，MLA + 稀疏注意力）：短上下文 FFN 主导，但随上下文变长越来越 Attention 受限。
|
||||
- **状态空间模型**（Nemotron3-120B，Mamba-2 + GQA）：因为线性时间注意力特性，运行时 decisively 倒向 FFN（128K 上下文时 FFN 占 81%）。
|
||||
|
||||
关键观察：**Attention/FFN 的运行时比例随上下文长度单调上升**（KV 缓存越来越大），且不同架构斜率完全不同。这意味着「给 Attention 和 FFN 分配多少算力」没有统一答案，必须按工作负载和模型架构动态决定——这正是 AFD 存在的根本理由。显存侧也是同理：Figure 3(b) 显示权重与 KV 缓存的占比随上下文剧烈变化，长上下文下 KV 缓存能吃掉 40%–77% 的显存。
|
||||
|
||||
顺带一提，这种「块内异构」对 MoE 尤其刺眼。MoE 的 FFN 是专家混合，参数规模常占整个模型权重的 80%–90% 以上，是名副其实的算力黑洞；而 Attention 在长上下文下又被 KV 缓存的读写带宽牢牢绑死。把这两者捆在同一个 GPU 上，你要么用一个超大 FFN 池去迁就一个很小的 Attention，要么用一个够大的 Attention 片去浪费 FFN 算力——两种都会留下明显的效率缺口。AFD 的解法不是「折中」，而是**把两者解耦到各自最合适的硬件配比**。
|
||||
|
||||
## 三、AIC++：把「解聚到哪一层」变成可求解的设计空间
|
||||
|
||||
为了系统研究 AFD，论文构建了 AIC++（AIConfigurator++）协同设计框架：它把 NVIDIA AIConfigurator 的算子级计算建模（实测 GPU 集群代价数据库）与 AstraSim 的高保真网络仿真（包粒度拥塞感知）融合起来，并基于一个定制化的 vLLM AFD 原型验证全对的全双工 Attention–FFN 执行路径的正确性。
|
||||
|
||||
AIC++ 的精髓在于：它显式地把「算子级计算异构性」和「跨节点通信代价」放进同一个优化目标里，从而能回答一个此前没人算清的问题——**在多大规模的集群上、对什么样的负载、Attention 该配几个 GPU、FFN 该配几个 GPU？**
|
||||
|
||||
在 MoE 上做 AFD，通信形态会发生质变。非 AFD 部署里，MoE 的 Dispatch/Combine 通信只在参与 EP（专家并行）的 GPU 之间、源目数量匹配；而 AFD 下 Attention 和 FFN 跑在不同物理 GPU 组上，导致**非对称的扇出/扇入**：例如 8 GPU 上 EP=8 的 MoE 在所有 8 卡间交换 token，而「2 个 Attention GPU + 6 个 FFN GPU」的 AFD 配置会产生扇出——Attention GPU 生成的 token 要被分发到更多 FFN GPU。A2F（Dispatch）是扇出，FFN 侧入口拥塞成为瓶颈；F2A（Combine）是扇入，Attention 侧入口成为瓶颈。AIC++ 把这两种传输展开成完整的双部流量矩阵，喂给 AstraSim 的分层拥塞感知网络模型。
|
||||
|
||||
## 四、四阶段微批重叠：AFD 吞吐的关键技巧
|
||||
|
||||
AFD 把每个 Transformer 层的执行拆成四个阶段，分别映射到不同的计算或通信资源：① Attention GPU 上的注意力计算；② 把后注意力隐状态、token id、每专家路由元数据 dispatch 给 FFN；③ FFN GPU 上的 MoE-FFN 计算；④ 把专家输出聚合回 Attention 侧进入下一层。现代数据中心 GPU 普遍提供全双工互联（NVLink、InfiniBand），因此返回通信可以走专用通道与正向通信并发，形成流水线。
|
||||
|
||||
论文给出了稳态流水线延迟的闭式表达（公式 1）：把每步 token 预算 T_budget 切成 M 个微批，在半双工链路上 M=3、全双工链路上 M=4。稳态下瓶颈阶段背靠背处理全部 M 个微批，非瓶颈阶段只承担一次性的管道填充/排空开销 s_i/L。最终端到端延迟 t_pipe = M·s_max + Σ(s_i/L)。**第一项是瓶颈资源决定的稳态吞吐，第二项是管道气泡。**这一公式让 AIC++ 能在 prefill 和 decode 两阶段都精确推理计算–通信代价。
|
||||
|
||||
值得强调的是，这个闭式模型的价值不在于「算出一个数字」，而在于它把 AFD 的吞吐上限**显式地绑定到了瓶颈资源的稳态速率**。换言之，只要你能定位到瓶颈是 Attention 计算、FFN 计算、还是 A2F/F2A 通信，就能直接知道该往哪一侧加 GPU、加多少，而不是靠拍脑袋调比例。这也是 AIC++ 与单纯「跑一遍搜索」最本质的区别：它把经验性的部署决策，变成了可解释、可外推的模型驱动决策。
|
||||
|
||||
## 五、位置感知 GPU 放置：把最频繁的通信绑到最快的链路
|
||||
|
||||
AFD 与 P/D 分离叠加后，会同时存在两种不同粒度的通信：① 每层都发生的 MoE Dispatch/Combine（O(层) 每请求），频率高、随层数线性增长；② 每个请求只发生一次的 KV 缓存传输（prefill 把 KV 发给 decode）。AIC++ 的策略是**频率驱动**的：把最频繁的层内 A2F/F2A 流量绑定到最高带宽的 scale-up 域（节点内 NVLink），而把较少的 KV 传输推迟到 scale-out 域（节点间 InfiniBand）。
|
||||
|
||||
论文用 2A2F（等价于 EP=4）配置、两个 8-GPU 节点做了对照（Table 2）：隔离放置下 KV 传输跨节点走 InfiniBand（25 GB/s），配对放置下 KV 留在 NVLink（450 GB/s），带来 **18× 的 KV 传输加速**。这一结论对任意多级网络层级都成立——始终让最频繁的通信模式占用最快的可用链路。
|
||||
|
||||
## 六、集群级评估：吞吐与交互性，谁说了算？
|
||||
|
||||
论文在 128 张 B200 SXM（TensorRT-LLM 后端）上，对 Qwen3-235B、GPT-OSS-120B、Nemotron3-120B、DeepSeek-V3.2 四款架构，在 Chat/Coding/Agentic Coding 三类负载下做了穷举式设计空间搜索（副本数 2–128 GPU，动态组合 TP/DP/EP 与 A/F GPU 组）。
|
||||
|
||||
两个核心结论（Key Takeaways）非常重要，值得做智算/推理 Infra 的人反复读：
|
||||
|
||||
**结论 1（系统吞吐）：聚合部署靠数据并行并发胜出大多数面板。** 用 16 个单节点 8-GPU 副本、通过 EP 持有专家 FFN 的聚合 serving（chunked-prefill），靠把 chunked-prefill 气泡摊到整个副本舰队、并行吞掉很多不相交 token 批次，在大多数面板上吞吐最高。解聚只在「更宽的搜索暴露出非对称副本形状」时才赢——比如「少数大 8-GPU decode worker 喂很多小 2-GPU prefill worker」，或解聚+AFD 下把 Nemotron 的吞吐翻倍。
|
||||
|
||||
**结论 2（用户交互性）：AFD 在每个面板上都赢。** AFD 通过按负载和模型定制 Attention/FFN 比例、用 AFD 专属的微批重叠技术榨干计算–通信重叠，始终把延迟做到最低。例如在 DeepSeek-V3.2 上，MLA + 稀疏注意力把 KV 缓存压缩得极狠，使得整个 524K 前缀能塞进 2 张 GPU 的 HBM，于是 2A+126F（2 个 Attention + 126 个 FFN）这种「反直觉」布局反而最优——AFD 把所有显存让给 FFN，只留极少 Attention GPU 跑大并发 decode 批次去匹配 126 卡 FFN 池的速率。
|
||||
|
||||
而在严格 SLO 下（TTFT<50/100/150ms，TPOT≤15ms），Figure 2 显示**只有 AFD 类方案（Agg+AFD、P/D Disagg+AFD）能解锁可行配置，撑起约 4k tokens/s 的系统吞吐；非 AFD 部署直接不可行**（红色叉号）。这正对应 agentic coding 这类长上下文、强 SLO 的真实生产场景。
|
||||
|
||||
### AFD 何时「独赢」吞吐：不是所有面板都该解聚
|
||||
|
||||
很多人会误读结论 1，以为「AFD 输了吞吐」。论文其实给出了非常细的边界。首先，**AFD 自己单独就赢下了一个面板**：在 GPT-OSS-120B 的 chat 负载上，纯 AFD 配置拿下了吞吐前沿的最优；其次，在 Nemotron-3-Super 上，解聚+AFD 的「tiny xPyD 分片」把聚合部署的吞吐直接**翻倍**。这说明「解聚是否划算」高度依赖模型架构与负载组合。
|
||||
|
||||
更微妙的是**注意力切片宽度对架构的强依赖**。Qwen3-235B 这类稠密 GQA 模型，因为注意力本身算得重，需要更宽的注意力片：在 agentic coding 负载下出现 8A+120F 的布局。而 DeepSeek-V3.2 在 524K 前缀下，吞吐最优布局会「翻转」成注意力密集的 96A+32F；一旦 TTFT 预算更紧、瓶颈从状态传播转回计算，布局又回到 FFN 密集切分。这种**随上下文长度和 SLO 预算来回翻转的最优 A/F 比**，恰好证明了「固定比例部署」的脆弱，也印证了 AIC++ 这种建模驱动方法的必要性——人工拍出的比例，几乎不可能覆盖这种翻转。
|
||||
|
||||
## 七、长上下文案例：AFD 是唯一可行解
|
||||
|
||||
论文还专门做了长上下文压力测试（ISL=500K+OSL=10K，以及 prefix=1M+ISL=4K+OSL=500），在 B200 上用 AFD + 4 阶段微批（M=4）。结果令人印象深刻：
|
||||
|
||||
- **大 prefill 场景（ISL=500K）**：Agg+AFD M4 在 64 GPU 达 1346.5 tok/s、128 GPU 达 2693.0 tok/s，最优布局是 [28A+4F]（Attention/FFN 比 7:1）。
|
||||
- **大前缀场景（prefix=1M）**：非 AFD 模式直接不可行——因为每 GPU 显存需求 M_shared = W+A+K+N+O ≈ 298 GiB，超过 B200 的 180 GiB 上限。AFD 把权重和激活拆分到 Attention/FFN 两组，把有效每 GPU 需求降到 M_AFD = max(M_attn, M_ffn) ≈ 165 GiB，刚好塞进显存。Disagg+AFD M4 在 128 GPU 达 1858.9 tok/s（略胜 Agg+AFD 的 1843.0）。
|
||||
|
||||
这个数字揭示了一个常被忽视的事实：**AFD 的内存切分收益，本质上是在「把权重/激活从 Attention GPU 上挪走、给 KV 缓存腾地方」**。在 1M 前缀这种单 GPU 显存根本装不下模型+激活+KV 的场景里，AFD 不是「更快」，而是「能跑」。
|
||||
|
||||
## 八、生产落地与行业趋势：AFD 已经从论文走进系统
|
||||
|
||||
这篇论文不是空中楼阁，它点名的几个方向已经或正在成为真实系统：
|
||||
|
||||
- **vLLM AFD PR #29772**：社区已经在 vLLM 0.16 上实现 MoE 的 A/F 解聚运行时（NCCL P2P 传输、1:1 配对），论文在其基础上重构成 M×N 双部配对、把 MoE router 移到 Attention 侧、并引入零集合通信的 FusedMoE.forward_pre_routed 入口。
|
||||
- **StepMesh（StepFun, 2025）**：专为 AFD 设计的通信库，采用与论文一致的 M×N 双部点对点发送/接收模式。
|
||||
- **异构片上加速器**：NVIDIA Groq 3 LPX、Rubin CPX、Intel SambaNova 这类「节点内异构计算单元」的出现，正是 AFD 成为有效策略的硬件土壤——高带宽 scale-up 互联让访存密集的 Attention 跑在内存富余的设备上，计算密集的 FFN 跑在算术吞吐高的加速器上。
|
||||
|
||||
论文也诚实给出了 AFD 的代价：每个 AFD 副本消耗更多 GPU，因此在「纯吞吐」维度，聚合部署在大多数面板上仍占优；AFD 的最大价值在**延迟敏感点**和**超出单 GPU 显存上限的长上下文区间**。这与「解聚不是银弹，而是要按负载画像决策」的工程常识一致。
|
||||
|
||||
### 对国产 AI 芯片与智算中心的启示
|
||||
|
||||
把视线拉回国内的智算建设，AFD 的启示格外现实。昇腾（Ascend）、沐曦（MetaX）、寒武纪、壁仞、昆仑芯等国产 AI 芯片，普遍在节点内提供高带宽的 scale-up 互联（如昇腾的 HCCS、昆仑芯的 XPU-Link），而跨节点走以太网或定制高速网。这与 AFD「层内高频通信绑节点内、低频 KV 走跨节点」的放置原则**高度契合**——国产芯片的异构互联拓扑，反而可能是 AFD 落地的一块好土壤。
|
||||
|
||||
更关键的是，国产大模型（如 DeepSeek 系列、Qwen 系列）几乎都是 MoE 架构，Attention 与 FFN 的异构性完全适用 AFD 的建模框架。对智算中心运营方而言，与其一味追求「单卡算力峰值」，不如按**负载画像做 rate-matching**：对长上下文、强 SLO 的推理业务，把 Attention 片与 FFN 片按 AIC++ 式建模动态配比，往往比堆更多同构副本更省卡、时延更低。
|
||||
|
||||
## 九、给我们的启示：推理 Infra 正在从「粗粒度放置」走向「算子级解聚」
|
||||
|
||||
对做智算中心和推理平台的团队，这篇论文给出几条可直接落地的原则：
|
||||
|
||||
1. **Attention/FFN 比例走 rate-matching**：AFD 只分配「刚好匹配 FFN 输出速率」所需的 Attention GPU。便宜低显存的注意力（MLA+DSA、滑窗 GQA）用小 Attention 片就能喂大 FFN 池（90%+ 集群给 FFN）；重注意力或大 KV 则需放大 Attention 片。
|
||||
2. **通信亲和度决定放置**：最频繁发生的层内 A2F/F2A 绑到节点内 NVLink（18× KV 传输收益），低频 KV 传输才走跨节点 InfiniBand。
|
||||
3. **长上下文是 AFD 的确定性战场**：当 prefix 大到单 GPU 装不下时，AFD 的内存切分是唯一可行路径，应优先在此类负载上启用。
|
||||
4. **建模驱动优于拍脑袋**：AIC++ 这类「算子级计算建模 + 网络仿真」框架，才是规模化部署前该有的决策工具，而不是靠经验搜比例。
|
||||
|
||||
### SLO 视角：AFD 的胜负手在「延迟预算」
|
||||
|
||||
把 Figure 2 的 SLO 结果拆开看，会发现一个朴素但常被忽略的道理：AFD 的优势是**带约束的优势**。论文把 TTFT 上限设成 50/100/150 ms 三档，TPOT 上限统一 15 ms。在「无 SLO、纯求吞吐」的目标下，聚合部署往往更能打；可一旦加上硬约束，聚合部署的大量面板直接变成红色叉号——搜索器根本找不到满足 SLO 的部署配置。所以对智算中心的启示是——**先定 SLO，再谈解聚**。如果你的业务对首字延迟和逐字间隔不敏感（比如离线批量摘要），聚合部署可能更省卡；但只要涉及实时对话、agentic 工具调用这类强 SLO 场景，AFD 就是绕不开的底座。
|
||||
|
||||
### 两个常见误区
|
||||
|
||||
误区一：「解聚层级越多越好」。论文明确给出反例——AFD 每个副本消耗更多 GPU，在纯吞吐面板上聚合常胜。解聚是**按负载画像做的权衡**，不是越细越优。误区二：「AFD 只能靠论文里的 AIC++ 才能用」。事实恰恰相反，vLLM PR #29772 已经把 MoE 的 A/F 解聚跑通，StepMesh 提供了通信库，意味着普通团队**不必从零造轮子**，只需要在现有运行时上把比例配好、把放置绑对链路即可上手。
|
||||
|
||||
## 十、小结与延伸阅读
|
||||
|
||||
AFD 代表了大模型推理解聚的第三级跳：从 chunked-prefill，到 P/D 分离，再到把 Attention 和 FFN 也拆开。它不会在所有场景都赢（纯吞吐仍常被聚合部署压制），但在**严格延迟 SLO**和**超长上下文**这两个越来越主流的战场上，AFD 已是不可替代的底座。随着 Groq 3 LPX、Rubin CPX、SambaNova 这类异构片上加速器的普及，算子级解聚会从论文走向默认的部署原语。
|
||||
|
||||
延伸阅读：PD 分离开山作 DistServe（arXiv:2401.09670）、Splitwise（arXiv:2311.18677）；MoE 解聚 MegaScale-Infer（arXiv:2504.02263）；vLLM AFD 实现 PR #29772；以及本工作的配套建模工具 AIConfigurator（arXiv:2601.06288）与网络仿真 AstraSim。同期值得关注的还有 ICML 2026 的《Theoretically Optimal Attention/FFN Ratios in Disaggregated LLM Serving》（arXiv:2601.21351），它从概率负载模型推导出最优 A/F 比的闭式解，与本文的实证结论相互印证。
|
||||
|
||||
> 本文由 arXiv 论文自动解读系统生成，基于 arXiv:2605.28302《How Far Can Disaggregation Go? A Design-Space Exploration of Attention–FFN Disaggregation for Efficient MoE LLM Serving》（Hanjiang Wu 等，Georgia Tech + Intel + Google + Google DeepMind，2026-05）。内容为对原论文的深度技术解读与工程点评，所有数据均引自原论文图表与正文。AI 辅助创作，转载请注明出处。
|
||||
@@ -0,0 +1,85 @@
|
||||
# 📊 文章摘要：当 PD 分离成为标配，推理的未来在 AFD
|
||||
|
||||
> **原文**：[2026-08-05_当PD分离成为标配_推理的未来在AFD.md](./2026-08-05_当PD分离成为标配_推理的未来在AFD.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/5YsLOl4oIfHzNdi8pbmURQ
|
||||
> **来源**：微信公众平台（小哥人工智能笔记）
|
||||
> **作者**：小哥人工智能笔记
|
||||
> **发布日期**：2026-08-05（原文未标注明确日期，按下载日占位；解读论文 arXiv:2605.28302 为 2026-05）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **算子级解聚** — 指出推理解聚的下一级是 AFD（Attention–FFN 解聚），并用 AIC++ 建模框架证明"解聚到哪一层、A/F 各配多少 GPU"应由模型驱动计算而非拍脑袋——这是本批文章中最具前瞻性的认知增量。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文解读 Georgia Tech + Intel + Google 等联合论文《How Far Can Disaggregation Go?》（arXiv:2605.28302），提出推理解聚"三级跳"演进：chunked-prefill → PD 分离 → 算子级 AFD（把 Attention 与 FFN 拆到不同 GPU 组）。论文以 AIC++ 协同设计框架（算子级计算建模 + AstraSim 网络仿真）在 128 卡 B200 上对四类 MoE 架构穷举搜索，核心结论：纯吞吐场景聚合部署常胜，但严格 SLO 下只有 AFD 可行（约 4k tokens/s），1M 前缀长上下文场景非 AFD 不可行（每 GPU 需求 298 GiB 超 B200 的 180 GiB，AFD 切分后降至 165 GiB）。价值在于把 PD 分离置于更大的演进脉络，并给出 rate-matching、位置感知放置、建模驱动等可落地原则；局限是数据全部来自论文仿真与原型，AFD 生产系统（vLLM PR）尚在早期。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **解聚三级跳框架** — chunked-prefill（切块减气泡）→ P/D 分离（算力 vs 带宽错配）→ A/F 解聚（块内访存 vs 计算错配）；AFD 是"叠在 PD 之上的下一级解聚"而非替代者。 `[分类: 范式突破]`
|
||||
2. **块内异构的量化证据** — 稠密 GQA 模型长上下文下 Attention 运行时占比从 4K 的 41%/59% 飙到 0.5M 的 87%/96%；Attention/FFN 占比随上下文单调上升且不同架构斜率不同，故 A/F 配比"没有统一答案"。 `[分类: 共识]`
|
||||
3. **AIC++ 建模框架** — 融合 AIConfigurator 算子级计算建模与 AstraSim 包粒度网络仿真，把"A 配几个 GPU、F 配几个 GPU"变成可求解的设计空间问题；四阶段微批重叠给出闭式解 t_pipe = M·s_max + Σ(s_i/L)，把吞吐上限显式绑定到瓶颈资源的稳态速率——这是"建模驱动替代拍脑袋"的方法论核心。 `[分类: 范式突破]`
|
||||
4. **位置感知 GPU 放置** — 频率驱动：高频层内 A2F/F2A 流量绑节点内 NVLink，低频 KV 传输走跨节点 InfiniBand；对照实验显示该放置带来 18× 的 KV 传输加速（25 GB/s → 450 GB/s）。 `[分类: 共识]`
|
||||
5. **"AFD 不是银弹"的边界** — 128 卡穷举搜索显示：纯吞吐下聚合部署（chunked-prefill + EP）在大多数面板胜出，解聚仅在更宽搜索暴露非对称副本形状时才赢；AFD 每个副本消耗更多 GPU。 `[分类: 共识]`
|
||||
6. **AFD 的两个确定性战场** — 严格 SLO（TTFT≤150ms/TPOT≤15ms）下只有 AFD 类方案可行（约 4k tokens/s，非 AFD 全红叉）；1M 前缀场景非 AFD 直接不可行——AFD 的内存切分本质是"把权重/激活从 Attention GPU 挪走给 KV 腾地方"，此处它不是"更快"而是"能跑"。 `[分类: 共识]`
|
||||
7. **反直觉最优布局与 A/F 翻转** — DeepSeek-V3.2 的 MLA+稀疏注意力把 524K 前缀塞进 2 卡 HBM 后，2A+126F 布局反成最优；同模型吞吐最优布局会随上下文与 TTFT 预算在 96A+32F 与 FFN 密集间来回翻转——印证固定比例部署的脆弱。 `[分类: 未探索]`
|
||||
8. **国产芯片的落地土壤** — 昇腾 HCCS、昆仑芯 XPU-Link 等节点内高带宽互联与"层内高频绑节点内"放置原则高度契合；国产 MoE 大模型（DeepSeek/Qwen 系列）完全适用 AFD 建模框架，但国产芯片上的 AFD 实测仍是空白。 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论建立在四个前提上：MoE 是主流大模型架构（结论对稠密模型适用性弱）；数据中心存在 scale-up/scale-out 两级网络拓扑且节点内带宽显著高于跨节点；用户有可量化的 SLO 预算（"先定 SLO，再谈解聚"）；AIC++ 的算子级计算建模数据库（基于 NVIDIA AIConfigurator 实测）对目标集群成立。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
证据链在同类文章中属于上乘：128 卡 B200、四类架构（Qwen3-235B/GPT-OSS-120B/Nemotron3-120B/DeepSeek-V3.2）、三类负载穷举式设计空间搜索，结论 1（吞吐）与结论 2（交互性）分开表述且各自给出反例（AFD 单独赢下 GPT-OSS chat 面板、Nemotron 吞吐翻倍），边界刻画诚实。但全部数据来自仿真（AstraSim）与定制 vLLM 原型，缺乏大规模生产实机验证；闭式模型的价值论述充分，其精度边界（仿真与实机的偏差）未量化。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者明确给出适用边界：纯吞吐、无 SLO 场景聚合部署常胜，解聚不是越细越优；结论针对 MoE 模型，对稠密 GQA 模型（如 Qwen3-235B）需更宽 Attention 片，配比决策更复杂；1M 前缀结论基于 B200 的 180 GiB 显存上限，随显存增长该"唯一可行"优势会收窄；生产落地（vLLM PR #29772、StepMesh）仍在早期，A/F 双部配对、MoE router 迁移等实现细节的稳定性与生态成熟度未经检验。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "AFD 的价值不只是「更快」，更是在特定战场上「能不能跑」。"
|
||||
|
||||
> "在 1M 前缀这种单 GPU 显存根本装不下模型+激活+KV 的场景里，AFD 不是「更快」，而是「能跑」。"
|
||||
|
||||
> "先定 SLO，再谈解聚。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- "解聚三级跳"框架清晰，把本批 PD 分离文章（DistServe 等）自然纳入更大演进脉络
|
||||
- AIC++ 建模驱动方法论是真正的方法论增量：把经验性部署决策变成可解释、可外推的模型驱动决策
|
||||
- 边界意识出色：明确"解聚不是银弹"、给出纯吞吐反例、指出固定 A/F 比例的脆弱
|
||||
- 对国产芯片与智算中心的落地启示（rate-matching、放置原则）具有现实针对性
|
||||
|
||||
**不足**：
|
||||
- 全部结论依赖论文仿真与原型，实机验证不足，关键数字（4k tokens/s、18×）应视为仿真估计
|
||||
- 对 AIC++ 建模精度、仿真与实机偏差未作讨论
|
||||
- 文章为 AI 解读系统生成，部分表述偏综述腔，深挖需回溯原论文
|
||||
|
||||
**适用场景**：智算中心与推理 Infra 团队做中长期技术规划（了解 PD 分离之后的演进方向）；关心 MoE 模型规模化部署的架构师；长上下文（500K-1M）业务场景的方案选型参考。
|
||||
|
||||
**关联建议**：回溯原论文 arXiv:2605.28302 及其配套工具 AIConfigurator（arXiv:2601.06288）与 AstraSim；本批 PD 分离文章构成其前置知识（DistServe 的动机、marcus 的 vLLM 机制、丁师兄的落地代价）；延伸阅读 Splitwise（arXiv:2311.18677）、MegaScale-Infer（arXiv:2504.02263）、vLLM AFD PR #29772 与 StepMesh，以及 ICML 2026《Theoretically Optimal Attention/FFN Ratios in Disaggregated LLM Serving》（arXiv:2601.21351）的最优 A/F 比闭式解。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,251 @@
|
||||
# 从分散提效到 AI Native 组织的实践
|
||||
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：数字人BuilderAgent团队
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/AgMLIqbA6PeGW7phFJAvOg
|
||||
|
||||
---
|
||||
|
||||
点击蓝字，关注我们
|
||||
|
||||
作者 | 数字人BuilderAgent团队
|
||||
|
||||
导读
|
||||
|
||||
introduction
|
||||
|
||||
本文聚焦一个扎心的悖论：AI 工具全面普及后，单点效率明显提升，但需求整体交付周期并未显著缩短。作者结合行业数据指出，真正消耗 80%+ 交付周期的并非执行速度，而是角色之间的等待、交接与信息损耗。
|
||||
|
||||
据此提出 AI 提效分级框架（L1/L2/L3） 与 AI Native 组织 两大理念，打破产研测运维职能边界，以 BuilderAgent 实现需求到上线的全流程闭环，让提效结果"可复制、可持续"。
|
||||
|
||||
_全文 3981 字，预计阅读时间 4 分钟_
|
||||
|
||||
GEEK TALK
|
||||
|
||||
01
|
||||
|
||||
一个扎心的悖论：人人都在提效，周期却没有显著缩短
|
||||
|
||||
__1.1 发现问题__
|
||||
|
||||
自全面接入 AI 以来，整个研发周期的各个环节包括产品、设计、研发、测试、运维等都在积极利用 AI 工具进行提效，但回头盘点发现，结论有点反直觉：____团队里每个人都感觉效率有明显提升，但需求从提出到上线的整体周期并没有等比的显著缩短。____
|
||||
|
||||
____为什么？____
|
||||
|
||||
古法需求从提出到交付全流程如下：____需求洞察________→ 需求提出 → 需求评审 → 方案设计 → 开发实现 → 测试验收 → 监控建设 → 上线发布 → 容量评估 → 数据回收与复盘迭代____。分析核心环节，发现当前该流程存在以下____四大痛点____
|
||||
|
||||
____痛点一：需求拆解到独立角色，协作成本高____
|
||||
|
||||
- 各角色串行依赖，空等耗时
|
||||
- 各角色信息不对称，沟通耗时
|
||||
|
||||
____痛点二：各阶段信息局部维护，信息传递损耗大，易出错____
|
||||
|
||||
- 各角色文档无显式关联约束，靠人工维护信息一致性，效率低
|
||||
- 各角色文档独立维护，一次变化需人工多次逐层传播，易出错
|
||||
|
||||
____痛点三：历史项目知识散落各地，沉淀效率低____
|
||||
|
||||
- 历史需求/知识散落在各角色文档/对话/线下讨论中，个体获取知识效率低
|
||||
- 关键经验留在个体手里，无法高效形成团队经验并在组织复用
|
||||
|
||||
____痛点四：传统开发周期长，需求吞吐慢____
|
||||
|
||||
- 传统开发包括开发->联调->测试等多个阶段，周期长&成本高
|
||||
- 项目开发成本高，需求阶段必须开展充分研讨论证，整体需求交付周期被进一步拉长
|
||||
|
||||
____AI能力分散地嵌入在单点环节，尚未形成从需求发现到需求优化的完整闭环____，我们得到的只是"更快的局部"，而不是"更短的整体"。
|
||||
|
||||
__1.2 数据印证__
|
||||
|
||||
查询业界数据与研究，发现结论高度一致，而且能从两个视角直观感知。
|
||||
|
||||
____视角一：即使在"研发环节内部"，写代码也只是一小部分。____
|
||||
|
||||
[图片]
|
||||
|
||||
____视角二：把镜头拉到"需求 idea→上线"整条流程，编码占比更小——大头是等待与交接。____
|
||||
|
||||
核心度量是____流动效率（Flow Efficiency）= 真正干活时间 ÷ 总交付周期____：
|
||||
|
||||
[图片]
|
||||
|
||||
两组数据相互独立，却拼出同一条因果链：____单点________AI 优化了"一小段里的一小部分"，撬不动占 80%+ 的流程性等待与交接。____
|
||||
|
||||
GEEK TALK
|
||||
|
||||
02
|
||||
|
||||
两个核心理念
|
||||
|
||||
基于上述问题，结合AI当前实际能力、业务差异化的具体场景，我们构思了两个核心理念
|
||||
|
||||
____1. AI提效分级框架（L1 / L2 / L3）____
|
||||
|
||||
____2. 流程精简与 AI Native 组织____
|
||||
|
||||
__2.1 AI提效分级框架（L1 / L2 / L3）__
|
||||
|
||||
____三级的本质区别：Context归属，而非能力高低；选择的核心依据是——这个需求的完成，依赖多少"人类独有、AI当前不具备"的context。____
|
||||
|
||||
[图片]
|
||||
|
||||
[图片]
|
||||
|
||||
__2.2 流程精简与 AI Native 组织__
|
||||
|
||||
____围绕 AI 重新设计流程与组织，而不是把 AI 缝进旧流程里。____传统模式里，PM 管需求、UE 管设计、RD 管开发、QA 管测试、OP管运维，各自对自己那一段负责，中间靠交接文档拉齐——这些交接、对齐、返工、排期，才是周期里最重的开销。
|
||||
|
||||
我们推动的转变是：____模糊 PM/UE/RD/QA/OP 的职能边界，让他们以 Builder 的新角色对同一个业务结果共同负责，共享同一份 Context 和交付物。____ ____AI Native 组织不取消专业角色，而是打破职能边界，隐性知识显性化，持续沉淀能力，专家协同保障平稳落地。____
|
||||
|
||||
[图片]
|
||||
|
||||
GEEK TALK
|
||||
|
||||
03
|
||||
|
||||
BuilderAgent：AI交付智能体
|
||||
|
||||
基于 AI Native 的两个核心理念，参考 SDD 和 AI-DLC 思想，我们协同 QA/OP 共建 ____BuilderAgent____，打破职能边界，全流程线上化，每次全流程需求交付都是一次沉淀&进化，AI+专家机制保障全流程稳定落地。
|
||||
|
||||
[图片]
|
||||
|
||||
__3.1 七个环节__
|
||||
|
||||
[图片]
|
||||
|
||||
____1. 需求发布____
|
||||
|
||||
把模糊的需求信号收敛成一份人和 AI 都能消费的结构化契约，是全链路的单一事实源。以模板固定 Spec 的必填字段（目标、边界、验收标准、依赖的 Context 归属）；AI 基于历史案例、知识库与已沉淀的 Skill 自动起草初稿，人只补其中的隐性判断（战略取舍、用户/体验直觉）。____验收标准必须写成"可被 QA 自动判定"的形式____——这是后续 QA 能否走 L3 的前提，也是本环节最硬的一条约束。
|
||||
|
||||
____2. 方案设计____
|
||||
|
||||
在实现之前确定技术路径与关键取舍，替代古法中"拉一轮评审会"。AI 依据 Spec 生成带判断的候选方案（含取舍理由与代价对比）；Builder 只在____关键决策点____ review；一旦有变更，直接在 Spec/workspace 上就地改，最终生成一份可执行的方案骨架。
|
||||
|
||||
____3. 开发实现____
|
||||
|
||||
把方案变成可运行产物。Builder 与 AI 在同一个（沙箱化的）workspace 内编码、配置、自测，共享同一份 Spec 上下文，无需把上下文"搬运"到别的工具；人负责异常与边界兜底。____每一次人工补位（人替 AI 改了什么、为什么改）都被记录____，作为后续能力沉淀的原料。
|
||||
|
||||
____4. 自动测试____
|
||||
|
||||
判定产物是否达到 Spec 定义的标准。验收标准直接取自 Spec；系统自动CR、生成并执行用例，规则明确的用例走 L3 自动跑并产出报告；测试资产可复用、可回归。验收未过则进入修复闭环。
|
||||
|
||||
____5. 发布上线____
|
||||
|
||||
把验收通过的产物安全放量。以灰度策略 + 指标监控 + 回滚预案为骨架，规则清晰时自动执行；重大变更经"发车机制"人审。
|
||||
|
||||
____6. 数据反馈____
|
||||
|
||||
形成效果结论，并产出下一轮需求信号，闭合反哺回路。指标口径在系统内已定义，自动采集与对比；把效果异常或新机会点转化为新的需求信号。数据回收不是终点，而是下一轮的起点。
|
||||
|
||||
____7. 持续进化____
|
||||
|
||||
随着需求的持续迭代，把每次专家的补位与决策沉淀为组织能力，让提效可复制、不依赖个别熟手，同类型需求周期越来越短，同人力吞吐越来越多
|
||||
|
||||
__3.2 五个关键构件__
|
||||
|
||||
五个构件不是五个独立工具，而是围绕"同一份上下文"咬合的一组齿轮。
|
||||
|
||||
[图片]
|
||||
|
||||
____1. Spec 工具____
|
||||
|
||||
根据业务特点，开发Spec工具，基于代码与历史知识，反复追问需求方，把"需求澄清一次做对"落成____可被人和 AI 同时消费的结构化契约____——包含目标、需求描述、边界、验收标准等。
|
||||
|
||||
____2. 沙箱与workspace____
|
||||
|
||||
业务维度构建 workspace，结合沙箱能力，可基于沙箱模板快速拉起一个____包含且仅包含____该业务相关的代码库、skills、知识、工具等完备的独立的开发部署环境，为人人都是builder的目标提供坚实基础
|
||||
|
||||
[图片]
|
||||
|
||||
____3. Builder 协同，从"交接"到"共担"____
|
||||
|
||||
模糊各角色边界，面对L3/部分L2需求，Builder个人可在BuilderAgent完成全生命周期；L1和复杂的L2，则各 Builder 对同一业务结果共同负责，PM 不再"写完 PRD 就甩给 RD"，而是和 RD 在同一个 workspace产出Spec文档，RD可基于Spec文档继续后续流程；QA 的验收标准前移进 Spec，而不是等提测才登场。
|
||||
|
||||
____4. QA 自动化____
|
||||
|
||||
协同QA共建Spec工具、建设AICR/用例生成/用例执行/E2E测试/测试报告生成等能力，形成"Spec 定标准 → QA 自动验 → 结果回流 Spec"的小闭环
|
||||
|
||||
____5. 智能运维____
|
||||
|
||||
协同OP共建智能运维工具，把上线后的系统运行纳入 BuilderAgent 中。智能运维持续获取 Spec、workspace、QA 报告、发布变更、历史故障和运行知识，结合实时指标、日志、链路与流量数据，主动完成异常感知、问题分析、风险处置和结果反哺，让系统从"出现告警后等人处理"转向"持续感知、主动分析、分级处置"。
|
||||
|
||||
__3.3 缺陷修复的重新开发闭环__
|
||||
|
||||
验收或上线后发现问题，不能就地打个补丁了事——那样验收标准不会更新，同类缺陷会反复出现。BuilderAgent把"修复"设计成一条____回流 Spec 的闭环____。
|
||||
|
||||
[图片]
|
||||
|
||||
闭环机制：
|
||||
|
||||
____1. 触发____：QA 自动化验收未通过，或上线后数据回收/智能运维监控发现问题。
|
||||
|
||||
____2. 缺陷归因____：定位问题出在哪一层——是需求理解（Spec）、方案取舍，还是实现细节。这一步决定修复的分级。
|
||||
|
||||
____3. 回流 Spec____：把缺陷转化为____新的验收标准或边界补充____写回 Spec。这是整条闭环最关键的一步，下面单独论证。
|
||||
|
||||
____4. 重新修复____：按缺陷层级定级修复（ L2/L3）；若根因在需求理解，则回到 Spec/方案层（L1/L2）重做。
|
||||
|
||||
____5. QA 回归验证____：复用原用例 + 新增针对该缺陷的用例做回归，确保修复不引入新问题；通过则重新发车，否则回到第 4 步再循环。
|
||||
|
||||
____6. 沉淀____：把缺陷模式与新增用例沉淀为规则/用例库。
|
||||
|
||||
____为什么必须回流 Spec，而不是就地打补丁____：就地打补丁只修好了"这一个 case"，验收标准原地不动，下次同类需求进来，QA 还是拦不住，于是缺陷复发、返工重来。
|
||||
|
||||
__3.4 知识 / Skill 自动沉淀与更新机制__
|
||||
|
||||
随着需求的持续迭代，把每次人工补位沉淀为组织能力，让提效可复制、不依赖个别熟手，同类型需求周期越来越短，同人力吞吐越来越多，L1 逐步演进为 L2/L3。
|
||||
|
||||
[图片]
|
||||
|
||||
____沉淀机制：____
|
||||
|
||||
____1. 触发____：一次交付完成或一次缺陷修复完成，自动启动沉淀，而不是靠人工事后补写文档。
|
||||
|
||||
____2. 抽取____：从本次开发中抽取可复用信号——专家补位的 diff、Spec 的增量变更、新增的缺陷用例、方案决策及其理由。
|
||||
|
||||
____3. 生成 / 更新____：由 AI 把上述信号归类，生成或更新对应资产（已存在的资产做增量更新而非新建，避免碎片化）。
|
||||
|
||||
- ____Skill____——可复用的操作SOP和参考
|
||||
- ____规则____——约束与最佳实践
|
||||
- ____验收模板____——可复用的 QA 标准
|
||||
- ____知识____——沉淀的系统架构/业务知识及相关索引
|
||||
|
||||
____4. 回流复用____：下一轮 Spec 澄清与 workspace 拉起时自动加载相关资产，让同类需求少依赖熟手——这正是"提效可复制"的机制来源。
|
||||
|
||||
GEEK TALK
|
||||
|
||||
04
|
||||
|
||||
效果验证与评估
|
||||
|
||||
__4.1 登录改版实验需求__
|
||||
|
||||
[图片]
|
||||
|
||||
__4.2 导航栏Hover优化需求__
|
||||
|
||||
[图片]
|
||||
|
||||
GEEK TALK
|
||||
|
||||
05
|
||||
|
||||
总结
|
||||
|
||||
回到最初的问题：每个人都在用 AI 提效，为什么整体交付周期没有显著缩短？因为真正影响效率的，不只是单点任务的执行速度，更是角色之间的等待、交接、信息损耗与重复返工。只有围绕 AI 重新设计流程和协作方式，才能从"更快的局部"走向"更短的整体"。
|
||||
|
||||
这正是 AI Native 组织的核心：____以业务结果为目标，打破职能边界，隐性知识显性化，持续沉淀能力，专家协同保障平稳落地。____
|
||||
|
||||
现阶段的实践只是起点，未来，我们将持续推动 AI 从局部辅助走向全链路协同，让共享 Context 贯穿需求、研发、测试、上线与运维，让每一次交付都能转化为可复用的知识、规则和 Skill，更多需求将从 L1 逐步演进到 L2、L3。随着重复执行、流程衔接与反馈闭环逐步由 AI 承担，团队也将把更多精力投入业务判断、体验取舍和技术创新。AI Native 不是简单引入更多工具，而是持续更新人与 AI 的协作方式，让组织在交付业务价值的同时，具备不断学习、自我完善和加速进化的能力。
|
||||
|
||||
END
|
||||
|
||||
__推荐阅读__
|
||||
|
||||
- 面向 Coding Agent 的多仓库 Git Worktree
|
||||
- 图灵平台：万亿级轨迹数据的秒级检索实战
|
||||
- 让 Agent 按工程标准交付：AI Coding 下的质量关卡实践
|
||||
- AI 写代码越来越快，质量谁来守？网盘主端 FE 的 AICR 准入实践
|
||||
- 协作的逆向演进：从 Agent 逻辑重构团队管理
|
||||
@@ -0,0 +1,84 @@
|
||||
# 📊 文章摘要：从分散提效到 AI Native 组织的实践
|
||||
|
||||
> **原文**：[2026-08-06_从分散提效到_AI_Native_组织的实践.md](./2026-08-06_从分散提效到_AI_Native_组织的实践.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/AgMLIqbA6PeGW7phFJAvOg
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：数字人BuilderAgent团队
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **AI原生组织** — 用"Context 归属"划分 AI 提效等级、围绕 AI 重设计流程与组织，把提效从"更快的局部"变成"更短的整体"
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文直面一个反直觉悖论：团队全员接入 AI 后人人感觉效率提升，需求整体交付周期却没有等比缩短。作者用"流动效率"（真正干活时间 ÷ 总交付周期）指出，占 80%+ 周期的是角色间的等待、交接与信息损耗，单点 AI 优化撬不动流程性损耗。据此提出两个核心理念：AI 提效分级框架（L1/L2/L3，本质区别是 Context 归属而非能力高低）与 AI Native 组织（模糊 PM/UE/RD/QA/OP 职能边界，共享同一份 Spec 与交付物），并落地为 BuilderAgent 的七环节闭环。其价值在于挑战了"多买 AI 工具就能整体提效"的主流认知，给出了可操作的分级决策框架与"缺陷回流 Spec"的防复发机制；局限是单公司实践，验证数据以图片呈现、缺乏量化细节，大规模组织中的可复制性尚未验证。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **单点提效悖论** — 每个人效率提升明显，但需求从提出到上线的整体周期没有显著缩短，因为 80%+ 周期消耗在角色间等待、交接与信息损耗上 `[分类: 范式突破]`（挑战"工具普及=整体提效"的默认假设）
|
||||
2. **AI 提效分级框架 L1/L2/L3** — 三级的本质区别是 Context 归属（依赖多少"人类独有、AI 当前不具备"的 context），而非 AI 能力高低；选择等级的核心依据是需求完成所需的 Context 归属 `[分类: 范式突破]`
|
||||
3. **AI Native 组织** — 围绕 AI 重新设计流程与组织，而不是把 AI 缝进旧流程；不取消专业角色，而是打破职能边界、隐性知识显性化、专家协同保障落地 `[分类: 范式突破]`
|
||||
4. **Spec 作为单一事实源** — 用结构化契约（目标、边界、验收标准、Context 归属）收敛模糊需求，验收标准必须写成"可被 QA 自动判定"的形式，这是 QA 走 L3 的前提 `[分类: 共识]`
|
||||
5. **缺陷修复回流 Spec 闭环** — 就地打补丁只修好"这一个 case"，验收标准不更新会导致同类缺陷复发；缺陷必须转化为新验收标准或边界补充写回 Spec `[分类: 范式突破]`
|
||||
6. **知识/Skill 自动沉淀机制** — 交付完成或缺陷修复后自动抽取专家补位 diff、Spec 增量、缺陷用例、方案决策，由 AI 归类生成/更新 Skill、规则、验收模板、知识，让提效不依赖个别熟手 `[分类: 未探索]`（作者称"提效可复制"的机制来源，但沉淀质量如何保证未展开）
|
||||
7. **流动效率（Flow Efficiency）** — 核心度量 = 真正干活时间 ÷ 总交付周期；两组相互独立的业界数据拼出同一条因果链：单点 AI 优化了"一小段里的一小部分" `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者立论建立在三个假设上：一是 AI 当前能力足以承担 L3 环节（QA 自动判定、自动测试、智能运维的主动处置）；二是组织愿意打破 PM/UE/RD/QA/OP 职能边界、共享同一份 Context；三是业务需求可以被结构化契约（Spec）完整表达。若需求高度依赖隐性判断、组织壁垒强或 AI 能力未达预期，框架将退化——作者承认"结合 AI 当前实际能力、业务差异化的具体场景"，但对场景的适用边界未作系统界定。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
"等待与交接占大头"的因果链由流动效率概念加两组业界数据支撑，逻辑自洽；但其间存在跳跃：从"业界数据显示写代码只占一小部分"直接推出"必须重构组织"，未讨论中等力度的改进方案（如只优化交接工具而不动组织）为何不可行。两个实验案例（登录改版、导航栏 Hover）仅以截图呈现，无量化指标，无法独立验证"周期缩短"的幅度与归因。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论的适用范围是需求可结构化、团队有变革意愿、具备 QA 自动化与智能运维建设能力的组织；强监管、需求高度模糊、或以既有职能线考核为主的场景不适用。L1→L2→L3 的演进依赖每次人工补位被记录与沉淀，若补位质量本身难以评估，沉淀可能固化错误模式。作者未讨论大规模组织（数百人以上）中共享 Context 的治理成本与安全边界。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "我们得到的只是'更快的局部'，而不是'更短的整体'。"
|
||||
|
||||
> "单点 AI 优化了'一小段里的一小部分'，撬不动占 80%+ 的流程性等待与交接。"
|
||||
|
||||
> "围绕 AI 重新设计流程与组织，而不是把 AI 缝进旧流程里。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 用"流动效率"概念把"整体周期不缩短"这个反直觉现象讲透，归因链清晰（单点效率 vs 流程性损耗）
|
||||
- L1/L2/L3 分级以"Context 归属"而非"能力高低"为判据，是一个可迁移的决策框架
|
||||
- "缺陷回流 Spec"闭环直击 AI 开发中验收标准失守、缺陷复发的真实痛点，机制设计有工程深度
|
||||
- 知识自动沉淀机制把"提效可复制"落到机制而非口号
|
||||
|
||||
**不足**：
|
||||
- 效果验证数据仅以图片呈现，缺乏量化指标与基线对比，说服力打折
|
||||
- 未讨论组织变革阻力（考核、权责、专业成长路径）这一落地最大障碍
|
||||
- 五个构件（Spec/workspace/协同/QA 自动化/智能运维）的建设成本与前置条件未交代
|
||||
|
||||
**适用场景**：正在建设 AI 辅助研发体系、面临"单点提效但整体没提效"困惑的产研团队；需要设计 AI 化需求交付流程或知识沉淀机制的工程管理者。
|
||||
|
||||
**关联建议**：可对照阅读 vLLM 的分离式推理（prefill/decode 分离）文档，理解"拆解流程环节"在系统层与组织层的一致性；延伸阅读作者"推荐阅读"中的 AI Coding 质量关卡实践与《协作的逆向演进：从 Agent 逻辑重构团队管理》，形成组织/流程/质量三视角闭环。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,120 @@
|
||||
# 揭秘老黄演讲中关键技术：PD分离！UCSD华人团队力作，LLM吞吐量跃升4倍
|
||||
|
||||
> **来源**：微信公众平台（新智元）
|
||||
> **作者**：新智元（编辑：静音、定慧）
|
||||
> **发布日期**：2026-08-05（原文未标注明确日期，文中提及黄仁勋 2025 GTC，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/kdxJng0X3RT2UU8EnuxeSw
|
||||
|
||||
> 新智元报道。本文是 DistServe（UCSD Hao AI Lab 华人团队）PD分离技术的中文解读，覆盖 Goodput、TTFT/TPOT、Prefill/Decode 干扰、分离架构、2P1D 实验量化、KV Cache 传输开销、DistServe vs vLLM 评估，是 DistServe 论文核心数据的中文可引用出处。
|
||||
|
||||
---
|
||||
|
||||
**【新智元导读】** 老黄 GTC 重点展示的 PD 分离技术为何成兵家必争之地？UCSD 全华人团队力作，创新性地提出预填充-解码分离技术。在严格的延迟约束下，相比现有最先进的服务系统，可实现高达 4.48 倍的有效产出率或 10.2 倍更严格的 SLO 达成率。
|
||||
|
||||
现在，PD 分离已经成为兵家必争之地。
|
||||
|
||||
前有 Mooncake/DeepSeek 等公司采用这种技术来优化大模型的推理服务，后有 Nvidia/PyTorch 基于该技术孵化下一代 LLM 服务系统。
|
||||
|
||||
甚至最近，黄仁勋也在 2025 GTC 的舞台上提到了 PD 分离（Prefill-Decode Disaggregation）技术，进一步证明了这一技术获得的广泛关注。
|
||||
|
||||
去年，来自 UCSD 的一个华人团队发布的一篇博客，就深入剖析了这一技术的原理和它的应用场景。博客地址：https://hao-ai-lab.github.io/blogs/distserve/
|
||||
|
||||
## 吞吐量与有效吞吐量
|
||||
|
||||
如今，大语言模型应用有着不同的延迟需求。例如，聊天机器人需要快速响应（比如低于 0.2 秒），而解码速度可以较为适中，仅需与人类阅读速度相匹配；代码补全则要求快速生成，以便实时提供代码建议。
|
||||
|
||||
文章中展示了现有的优化吞吐量的服务系统，在延迟标准下并不理想。作者提议使用「有效吞吐量」（goodput）作为大模型服务性能的改进衡量标准，它不仅关注每秒完成请求的数量，而且符合服务级目标（SLO），更好地平衡成本和用户体验。
|
||||
|
||||
为了提升有效吞吐量，文章提出了「预填充-解码分离」（prefill-decode disaggregation），即将预填充和解码分配到不同的 GPU 上。通过这个方法，作者搭建了一个系统原型 DistServe，在保持严格的延迟约束下，达到了比现有系统高出 4.48 倍的有效吞吐量，或者 10.2 倍更严格的 SLO。
|
||||
|
||||
### LLM 正在改变行业对 AI 的应用，但 LLM 服务成本仍然很高
|
||||
|
||||
为了降低成本，很多公司专注于提升 LLM 系统的吞吐量，即每秒处理的请求数（rps），作为每个请求成本（$/req）的替代指标。大多数流行的 LLM 服务引擎，如 vLLM 和 TensorRT-LLM，都用吞吐量来衡量性能。
|
||||
|
||||
然而，实际应用对延迟的要求各不相同，因此服务级目标（SLO）也不同。常见的 SLO 包括：
|
||||
|
||||
- **首次 token 延迟（TTFT）**：测量 LLM 生成第一个 token 的时间
|
||||
- **每个输出 token 的时间（TPOT）**：测量两个连续生成的 token 之间的平均延迟
|
||||
|
||||
吞吐量只关注处理的请求或 token 数，却忽视了这些延迟需求。作者引入了有效吞吐量（goodput），它衡量每秒完成的符合 SLO 的请求数（同时满足 TTFT 和 TPOT 要求）。这比吞吐量更能反映服务质量，因为它考虑了成本和用户体验。
|
||||
|
||||
那么，到底什么是有效吞吐量？假设一个应用要求 90% 的请求 TTFT 小于 200 毫秒，TPOT 小于 50 毫秒，那么有效吞吐量就是每秒能完成的最大请求数，且至少 90% 的请求同时满足这两个条件。一个高吞吐量的应用可能有低的有效吞吐量——虽然吞吐量是 10 个请求每秒，但因为延迟约束，只有 3 个请求符合 SLO，最终的有效吞吐量只有每秒 3 个请求。
|
||||
|
||||
术语小结：
|
||||
|
||||
- **有效吞吐量（goodput）**：衡量 LLM 服务系统效能的指标，考虑了成本和用户满意度。定义为每秒系统可以完成的请求数量，同时满足指定的 SLO。
|
||||
- **吞吐量**：LLM 服务系统每秒处理的已完成请求数量。
|
||||
- **服务级目标（SLO）**：常见包括 TTFT、TPOT、端到端延迟（E2E）和指数加权平均（EMA）延迟。
|
||||
- **预填充（Prefill）**：LLM 推理的第一阶段，处理所有输入 token，填充 KV 缓存，并生成第一个输出 token。
|
||||
- **解码（Decode）**：随后的阶段，通过自回归方式生成 token，直到完成。
|
||||
|
||||
## 为什么现有系统无法实现高有效吞吐量？
|
||||
|
||||
LLM 服务请求的流程：请求进入 LLM 推理引擎，系统首先处理用户输入生成第一个 token（预填充），然后通过自回归生成后续 token（解码）。一个请求通常包括一个预填充步骤和多个解码步骤。
|
||||
|
||||
LLM 服务系统通常将预填充和解码一起批处理（迭代调度或连续批处理 continuous batching），使 GPU 能尽量大批量处理，从而提高吞吐量。vLLM 和 TensorRT-LLM 等系统都广泛采用这一方法。
|
||||
|
||||
然而，预填充和解码在计算上有非常不同的特点。预填充非常依赖计算，即使是一个小批量的预填充，或仅仅是一个足够长的预填充，也会迅速饱和 GPU 计算资源。解码则需要更大的批量来达到计算瓶颈，且更容易受到 GPU 内存带宽限制的影响。
|
||||
|
||||
将这两者一起处理不利于优化有效吞吐量，原因有二：
|
||||
1. 预填充和解码之间会互相干扰，导致性能下降；
|
||||
2. 预填充和解码的资源分配及并行策略会相互耦合，难以优化。
|
||||
|
||||
### 预填充和解码的干扰
|
||||
|
||||
把两个请求批量到一个 GPU，解码（R1）延迟显著增加，预填充（R2）延迟稍微上升；稳定请求流中，每次解码遇到预填充请求时就会被「卡住」，解码延迟意外增加。这种干扰导致：为了满足 TTFT 和 TPOT 的 SLO，系统必须过度配置资源，尤其当某个 SLO 特别严格时。
|
||||
|
||||
此外，预填充和解码的资源分配和并行策略是耦合的。比如，当 TTFT 要求严格时，预填充阶段适合用张量并行（TP）来满足紧凑的延迟目标，而解码则更倾向于数据并行或流水线并行来提升吞吐量。
|
||||
|
||||
## 分离预填充和解码
|
||||
|
||||
直觉很简单：将预填充（Prefill）和解码（Decode）分配到不同的 GPU，并为每个阶段定制并行策略。这自然解决了上面两个问题：
|
||||
1. 预填充和解码之间没有干扰，使得两个阶段都可以更快完成，并更容易满足各自的 SLO；
|
||||
2. 资源分配和并行策略解耦，优化可以针对预填充和解码分别进行。
|
||||
|
||||
当请求到达系统时：① 首先进入预填充工作节点并完成预填充阶段；② 然后，系统将其中间状态（主要是 KV 缓存）迁移到解码工作节点，并进行多个解码步骤以生成后续 token；③ 请求在生成完成后离开系统。
|
||||
|
||||
### 一个简单的实验验证
|
||||
|
||||
在单个 A100-80GB GPU 上运行一个 13B 的 LLM，使用输入长度 512、输出长度 64 的合成工作负载，假设请求按泊松分布到达。逐渐增加请求速率（x 轴），测量 P90 TTFT 和 P90 TPOT（y 轴）。
|
||||
|
||||
将 SLO 设置为 P90 TTFT 小于 0.4 秒，P90 TPOT 小于 0.04 秒。现有系统使用 1 个 GPU 时，大约支持 3 rps（TTFT），而 TPOT 则支持 1.6 rps。由于需要同时满足两个约束，现有共同处理系统的有效吞吐量为：
|
||||
|
||||
**有效吞吐量（同时满足）= min(3, 1.6) = 1.6 rps（每个 GPU）。**
|
||||
|
||||
分离后，性能显著提升。预填充工作节点和解码工作节点在仅处理单个阶段时，可分别达到约 5.6 rps 和 10 rps。更重要的是，可以灵活地分配 2 个预填充工作节点与 1 个解码工作节点（记作 2P1D），总共使用 3 个 GPU。此时：
|
||||
|
||||
**有效吞吐量（2P1D）= min(5.6 × 2, 10) = 10 reqs/s ÷ 3 GPUs ≈ 3.3 reqs/s（平均每个 GPU）。**
|
||||
|
||||
这个实验表明，简单的分离方法在没有任何并行化的情况下就能实现 **2 倍**的有效吞吐量（3.3 rps VS 1.6 rps）。额外的好处是，预填充与解码的分离还能够为每个阶段选择最佳的并行策略来优化有效吞吐量（作者称之为「定制并行 tailored parallelism」）。
|
||||
|
||||
## KV 缓存传输
|
||||
|
||||
分离的一个代价是需要在预填充和解码 GPU 之间传输中间状态（即 KV 缓存）。乍一看，KV 缓存是 LLM 推理中一个大的内存开销，而在 GPU 之间传输 KV 缓存似乎是一个瓶颈。
|
||||
|
||||
但相反，通过合理的放置，KV 缓存传输的开销可以被有效地最小化，低至小于一个解码步骤的时间，这得益于今天高速的网络技术，如 NVLink 和 PCI-e 5.0。
|
||||
|
||||
假设有 8 通道 PCIe 5.0 x16（每个链路 64GB/s）作为 GPU 之间的节点内网络。给定一个 2048 token 的请求，在服务 OPT-175B 时传输 KV 缓存的延迟为：
|
||||
|
||||
**延迟 = 2048 token ×（4.5 MB/token）÷（64GB/s × 8）= 17.6 毫秒**
|
||||
|
||||
这个延迟小于 OPT-175B 的单个解码步骤的时间（约 30-50 毫秒，使用 A100）。对于更大的模型、更长的序列或更先进的网络（例如具有 600GB/s 带宽的 A100-NVLink），KV 缓存传输的比较开销与单个解码步骤相比变得更加微不足道。精心放置预填充和解码工作节点以利用高带宽网络，可以有效地隐藏 KV 缓存传输的开销。
|
||||
|
||||
## DistServe：评估分离的效果
|
||||
|
||||
作者在一个名为 DistServe 的系统原型中实现了所提出的技术，并在三个具有不同延迟约束的工作负载和数据集上与现有系统（vLLM）进行了比较：聊天机器人、代码补全和摘要。
|
||||
|
||||
- **聊天机器人**：DistServe 的有效吞吐量比 vLLM 高 **2.0 倍到 3.41 倍**。
|
||||
- **代码补全**：DistServe 的有效吞吐量比 vLLM 高 **3.2 倍**，并且 SLO 比 vLLM 严格 1.5 倍。通过消除解码任务的干扰，并为预填充定制张量并行策略，DistServe 减少了预填充任务的平均延迟，从而满足更多请求的 TTFT 要求。
|
||||
- **摘要**：DistServe 的有效吞吐量比 vLLM 高 **4.48 倍**，并且 SLO 比 vLLM 严格 **10.2 倍**。由于 vLLM 将预填充和解码放在一起，它在解码阶段的减速更大，未能满足 TPOT 要求。
|
||||
|
||||
## 团队成员
|
||||
|
||||
以上研究出自加州大学圣地亚哥分校的 Hao AI 实验室，全部来自于华人研究者：
|
||||
|
||||
- **Yinmin Zhong（一作）**：北京大学计算机系统研究组三年级博士生，导师金鑫。
|
||||
- **Junda Chen**：2023 年秋季入学的计算机科学博士生，研究高效 LLM 服务系统。
|
||||
- **刘胜与**：北京大学本科生。
|
||||
- **Hao Zhang**：加州大学圣地亚哥分校计算机科学与工程系助理教授，领导 Hao AI 实验室。
|
||||
|
||||
> 参考资料：https://hao-ai-lab.github.io/blogs/distserve/
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：揭秘老黄演讲中关键技术：PD分离！UCSD华人团队力作，LLM吞吐量跃升4倍
|
||||
|
||||
> **原文**：[2026-08-05_揭秘老黄演讲PD分离_UCSD华人团队DistServe_新智元.md](./2026-08-05_揭秘老黄演讲PD分离_UCSD华人团队DistServe_新智元.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/kdxJng0X3RT2UU8EnuxeSw
|
||||
> **来源**：微信公众平台（新智元）
|
||||
> **作者**：新智元（编辑：静音、定慧）
|
||||
> **发布日期**：2026-08-05（原文未标注明确日期，文中提及黄仁勋 2025 GTC，按下载日占位）
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **有效吞吐量** — 提出以符合 SLO 的 goodput（有效吞吐量）取代裸吞吐量作为 LLM 服务系统的衡量标准，并给出 PD 分离将有效吞吐量提升 2-4.48 倍的量化论证。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 UCSD Hao AI Lab 的 DistServe 论文（PD 分离开山之作）的中文解读，论证"为什么现有系统无法实现高有效吞吐量"：Prefill 计算密集与 Decode 内存带宽密集混批互扰，且资源分配与并行策略耦合难优化。分离后以 2P1D（2 个 Prefill + 1 个 Decode 节点）配置在 3 块 GPU 上实现有效吞吐量 2 倍提升；并量化证明合理放置下 KV Cache 传输开销（17.6ms）小于单个解码步骤（30-50ms），可被隐藏。其价值是本批 PD 分离文章的理论源头与中文数据出处；局限是数据全部来自 A100 时代论文原型，非生产系统实测，且对传输代价的乐观估计与丁师兄文章的落地视角存在张力。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **goodput 概念** — 有效吞吐量衡量"每秒完成的符合 SLO 的请求数"，须同时满足 TTFT 与 TPOT；高吞吐量系统可能有效吞吐量很低（10 rps 中仅 3 个符合 SLO）。这是衡量标准的转向，挑战了以 rps 为纲的业界惯例。 `[分类: 范式突破]`
|
||||
2. **混批干扰机制** — 稳定请求流中每次 Decode 遇到 Prefill 请求就被"卡住"，解码延迟意外增加；为满足严格 SLO 必须过度配置资源。 `[分类: 共识]`
|
||||
3. **2P1D 量化实验** — 单 A100 上 13B 模型、512 输入/64 输出负载：共同处理有效吞吐量 min(3, 1.6)=1.6 rps/GPU，分离后 2P1D 达 3.3 rps/GPU，无并行化即 2 倍提升。 `[分类: 共识]`
|
||||
4. **KV 传输开销可隐藏** — OPT-175B 的 2048 token 请求经 8 通道 PCIe 5.0 x16 传输 KV 仅 17.6ms，小于单解码步 30-50ms；网络越快、模型越大该结论越强。注意：此乐观结论基于"合理放置+高速网络"前提，与生产落地视角（丁师兄）形成对照。 `[分类: 争议]`
|
||||
5. **定制并行策略** — 分离使两阶段并行策略解耦：TTFT 严格时 Prefill 用张量并行，Decode 用数据/流水线并行，这是分离的隐藏红利。 `[分类: 共识]`
|
||||
6. **三负载评估数据** — 聊天 2.0-3.41 倍、代码补全 3.2 倍（SLO 严格 1.5 倍）、摘要 4.48 倍（SLO 严格 10.2 倍）有效吞吐量提升，为本批文章最常引用的核心数据出处。 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
论证建立在几个前提上：工作负载的延迟需求可精确量化为 SLO；节点间具备 NVLink/PCIe 5.0 级高速互联（传输可隐藏结论强依赖此点）；分离后 P、D 集群的负载是可预测、可配比的——而真实业务流量动态变化，P:D 静态配比会失效（丁师兄文章指出此点）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据以单 GPU 对照实验、2P1D 扩展实验、三负载评估三层递进，数据详实且附完整计算过程（如 17.6ms 推导、min 运算），逻辑链条完整。但样本为论文原型与合成负载（泊松到达、固定输入输出长度），与生产流量分布有差距；"KV 传输可隐藏"在 PCIe 5.0 与 NVLink 假设下成立，作者未讨论网络成为瓶颈的现实场景。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论基于 A100-80GB 与 OPT-175B 等 2023-2024 时代配置，未覆盖 MoE 模型与更高并发规模；对 KV Cache 传输的乐观评估仅适用于"合理放置"的节点内场景，跨数据中心场景不成立；文章本身是转述解读，未引入任何独立批判或后续系统（Mooncake、SGLang）的实践修正。适合理解 PD 分离的原理动因，不适合直接作为生产架构决策依据。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "现在，PD 分离已经成为兵家必争之地。"
|
||||
|
||||
> "这个实验表明，简单的分离方法在没有任何并行化的情况下就能实现 **2 倍**的有效吞吐量（3.3 rps VS 1.6 rps）。"
|
||||
|
||||
> "通过合理的放置，KV 缓存传输的开销可以被有效地最小化，低至小于一个解码步骤的时间。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 概念清晰：goodput、TTFT/TPOT、2P1D 配比实验均有严谨推导与量化
|
||||
- 本批 PD 分离文章的理论源头，三负载评估数据（4.48 倍/10.2 倍）是高质量可引用出处
|
||||
- "分离的两个动机"（去干扰+解耦并行策略）表述凝练，是解释 PD 分离动机的标准框架
|
||||
|
||||
**不足**：
|
||||
- 数据全部来自论文原型，无生产实测，被黄仁勋 GTC 背书但未呈现业界落地修正
|
||||
- 对 KV 传输开销的乐观结论未给出边界条件（网络成为瓶颈时失效）
|
||||
- 未涉及落地代价（调度复杂度、P:D 配比敏感性），需与代价派文章对照阅读
|
||||
|
||||
**适用场景**：需要快速建立 PD 分离理论框架的工程师与决策者；撰写 PD 分离科普/方案文档时的中文数据引用来源；面试中解释"为什么需要 PD 分离"的标准答案素材。
|
||||
|
||||
**关联建议**：与丁师兄《LLM 做 PD 分离后怎么更慢了》对照阅读，恰好构成"红利 vs 代价"的完整两面；与本批 marcus 的 vLLM 源码级文章（实现机制）和小哥的 AFD 文章（下一级演进）串读可覆盖"为什么分离—怎么分离—分离的代价—分离之后"全景。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,170 @@
|
||||
# 刚刚！谷歌突发最炸离职！
|
||||
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：深科技首席
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/5RcNh03rxFZMbJZKoKQvLw
|
||||
|
||||
---
|
||||
|
||||
👆点击 深科技 > 点击右上角"···" > 设为星标🌟
|
||||
|
||||
[图片]
|
||||
|
||||
[图片]
|
||||
|
||||
震惊啊！
|
||||
|
||||
硅谷突发炸裂消息！谷歌传奇首席科学家 Jeff Dean 官宣离职。
|
||||
|
||||
谷歌最核心技术家底全员出走！
|
||||
|
||||
刚刚，深科技（deeptek）消息：Jeff携手三位谷歌顶级技术元老组团创业，成立全新 AI 科研公司 Discovery Loop。
|
||||
|
||||
这支创始团队堪称谷歌技术天花板，包揽谷歌基建、Google Brain、Gemini 三代核心技术。
|
||||
|
||||
这大概率是近十年科技圈__创始人阵容天花板级别的创业公告__，没有之一。
|
||||
|
||||
如果盘点谷歌史上影响力TOP10的工程师，除去拉里·佩奇和谢尔盖·布林两位创始人，本次组团创业的四位大佬全部稳居榜单之内。
|
||||
|
||||
这四个人包揽谷歌三代核心技术：底层基建、初代AI、Gemini大模型。承载了巅峰技术积淀，如今集体出走联手创业，含金量堪称恐怖。含金量炸裂！
|
||||
|
||||
[图片]
|
||||
|
||||
一、重磅大瓜：谷歌27年技术教父裸辞创业
|
||||
|
||||
硅谷炸出超级大瓜！谷歌头号技术大佬Jeff Dean，正式从谷歌离职。
|
||||
|
||||
他在谷歌干了整整27年，是妥妥的第30号元老级员工。
|
||||
|
||||
毫不夸张地说，谷歌大半技术根基，都是他亲手打下来的。
|
||||
|
||||
从早期搜索基建、Google Brain，再到Gemini大模型，他全程主导谷歌三代核心技术迭代。
|
||||
|
||||
这次他没有单打独斗，直接拉上三位谷歌顶级技术大佬组团单飞。
|
||||
|
||||
四人联手成立全新科技公司Discovery Loop，由Jeff Dean亲自担任CEO。
|
||||
|
||||
[图片]
|
||||
|
||||
最离谱的是，这场重磅创业，从头到尾只酝酿了五周时间。
|
||||
|
||||
短短五周，他直接凑齐谷歌顶配技术天团，开辟全新AI赛道。
|
||||
|
||||
更有意思的是，谷歌并未封杀这支出走的核心团队。
|
||||
|
||||
母公司Alphabet直接战略入股，谷歌云专属提供算力与云服务支撑。
|
||||
|
||||
顶级风投联合领投种子轮，这家新公司开局就是行业顶配待遇。
|
||||
|
||||
[图片]
|
||||
|
||||
[图片]
|
||||
|
||||
二、全明星创始团队：集齐谷歌三代核心技术
|
||||
|
||||
Discovery Loop四大联合创始人堪称谷歌技术史"全明星阵容"，四人分别执掌谷歌不同阶段的核心技术，集齐谷歌互联网基建、早期AI、大模型时代的全部技术积累，行业稀缺性无可替代。
|
||||
|
||||
资深大佬评：这种级别的阵容组队创业，十年难遇，根本找不到对手！
|
||||
|
||||
[图片]
|
||||
|
||||
Discovery Loop四大核心（从左到右）：Oriol Vinyals · Sanjay Ghemawat · Jeff Dean · Quoc Le
|
||||
|
||||
1. Jeff Dean（CEO）：谷歌技术体系核心奠基人，早期主导谷歌搜索、分布式计算基础设施搭建，后续联合创立Google Brain，长期担任谷歌首席科学家，是谷歌AI技术迭代的核心掌舵人。
|
||||
|
||||
[图片]
|
||||
|
||||
2. Sanjay Ghemawat：谷歌分布式系统奠基人，与Jeff Dean联手研发Google File System、MapReduce、Bigtable、Spanner等核心基础设施，当下全球云计算、大数据系统的底层技术大多溯源其研发成果，是互联网底层架构的顶尖专家。
|
||||
|
||||
[图片]
|
||||
|
||||
3. Oriol Vinyals：Gemini大模型核心负责人，深耕生成式AI基础技术，是Seq2Seq、知识蒸馏、AlphaStar等重磅项目的核心研究者。其中Seq2Seq技术成为现代机器翻译、生成式AI的核心底层支撑，奠定了大模型交互能力的技术基础。
|
||||
|
||||
4. Quoc Le：Google Brain创始核心成员，参与提出Seq2Seq技术，主导大规模无监督学习、AutoML技术迭代，也是谷歌AI自主学习识别YouTube视频内容核心项目的负责人，推动了AI自动化学习的早期落地。
|
||||
|
||||
三、新公司野心曝光：不做聊天机器人，要让AI自己搞科研
|
||||
|
||||
当下市面上绝大多数AI公司，都在内卷聊天功能、对话体验和大模型参数。
|
||||
|
||||
但Discovery Loop完全另辟蹊径，不走传统AI的内卷老路。
|
||||
|
||||
这家新公司的野心极大，目标是让AI全程自主完成科学研究，彻底解放人力。
|
||||
|
||||
[图片]
|
||||
|
||||
简单来说，他们要打造一套完整的AI全自动科研闭环体系。
|
||||
|
||||
AI可以自主提出科研猜想，独立设计对应的实验方案。
|
||||
|
||||
AI能够全自动运行实验、采集并整理全部实验数据。
|
||||
|
||||
AI自主分析实验结果，并根据结论自动迭代新一轮实验方向。
|
||||
|
||||
整套科研流程全程无人干预，真正实现科研全流程自动化运转。
|
||||
|
||||
Discovery Loop的发展布局清晰稳健，采用循序渐进的落地节奏。
|
||||
|
||||
公司前期聚焦AI领域，核心目标是让AI自主研发AI技术。
|
||||
|
||||
这或许将彻底解决人工科研效率低、迭代速度慢的行业痛点。
|
||||
|
||||
未来公司会全面跨界扩张，布局多个硬核科技赛道。
|
||||
|
||||
业务将覆盖芯片设计、新材料研发、新药研发、清洁能源等核心领域。
|
||||
|
||||
每一个布局方向，都是全球科研领域最难突破、最具价值的赛道。
|
||||
|
||||
Discovery Loop的企业架构十分特殊，采用少见的公共利益公司模式。
|
||||
|
||||
它不单纯追求商业盈利，更注重技术落地带来的公共社会价值。
|
||||
|
||||
大佬们出走创业的原因，现实且直白。
|
||||
|
||||
谷歌现有架构和系统，只适配搜索、广告、民用消费级产品。
|
||||
|
||||
这套体系完全无法满足前沿硬核科学研究的专属需求。
|
||||
|
||||
因此团队选择离职创业，从零搭建适配自动化科研的全新基建。
|
||||
|
||||
四、行业炸锅：AI内卷彻底变天，下一轮大赛道来了
|
||||
|
||||
本次四大核心元老集体出走，堪称谷歌史上损伤最大的人才流失事件。
|
||||
|
||||
这批技术元老深耕谷歌数十年，技术底蕴和行业地位无可替代。
|
||||
|
||||
近两年谷歌顶尖AI人才流失潮愈发明显，行业人才流动剧烈。
|
||||
|
||||
不少核心技术人才相继跳槽OpenAI、加盟Anthropic等新锐AI巨头。
|
||||
|
||||
顶级技术大佬纷纷放弃谷歌顶级资源，选择自主创业突破技术瓶颈。
|
||||
|
||||
这也直接印证了AI行业风向的彻底转变。
|
||||
|
||||
[图片]
|
||||
|
||||
顶尖技术人才不再迷恋大厂光环，更追求自由的硬核技术突破。
|
||||
|
||||
谷歌虽然痛失核心技术团队，但也做出了最明智的止损操作。
|
||||
|
||||
Alphabet直接战略投资Discovery Loop，锁住深度合作关系。
|
||||
|
||||
相当于核心人才虽然出走，但技术、资源纽带并未断裂。
|
||||
|
||||
谷歌CEO官宣DeepMind人员调整。
|
||||
|
||||
[图片]
|
||||
|
||||
这是谷歌当下最优的止损方案，避免彻底撕破脸、错失前沿技术红利。
|
||||
|
||||
过去行业内卷的是模型参数、对话体验、算力规模等基础能力。
|
||||
|
||||
未来AI的核心赛场，是规模化、工程化的自动科学发现能力。
|
||||
|
||||
AI从此不再只是被动回答人类问题的工具。
|
||||
|
||||
新一代AI将实现自主思考、自主实验、自主突破前沿技术。
|
||||
|
||||
谁率先掌握AI自动化科研能力，谁就能拿下下一轮AI时代的行业话语权。
|
||||
|
||||
[图片]
|
||||
@@ -0,0 +1,78 @@
|
||||
# 📊 文章摘要：刚刚！谷歌突发最炸离职！
|
||||
|
||||
> **原文**：[2026-08-06_刚刚_谷歌突发最炸离职.md](./2026-08-06_刚刚_谷歌突发最炸离职.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/5RcNh03rxFZMbJZKoKQvLw
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：深科技首席
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐ 低
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **谷歌元老出走** — 事件性快讯：Jeff Dean 等四位谷歌技术元老离职创办 AI 科研公司 Discovery Loop，Alphabet 战略入股、谷歌云提供算力
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是一则标题党风格的新闻快讯，报道谷歌首席科学家 Jeff Dean 在任职 27 年后离职，与 Sanjay Ghemawat、Oriol Vinyals、Quoc Le 三位技术元老共同创办 AI 科研公司 Discovery Loop，目标是从零搭建"AI 全自动科研闭环"（自主提出猜想、设计实验、运行与分析、迭代），前期聚焦让 AI 研发 AI，未来拓展芯片、新材料、新药、清洁能源等领域，并采用公共利益公司模式。事件本身具有行业信号意义（谷歌技术天花板集体出走、母公司投资入股而非封杀），但文章无任何一手来源、无数据支撑、无边界讨论，全部信息为渲染性转述，信息增量有限，事件细节需以官方公告核实。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Jeff Dean 离职创业** — 谷歌第 30 号元老员工、27 年技术教父，出任 Discovery Loop CEO `[分类: 共识]`（事件事实，来自行业报道）
|
||||
2. **全明星创始团队** — Ghemawat（MapReduce/GFS/Bigtable/Spanner 分布式系统奠基）、Vinyals（Gemini/Seq2Seq/AlphaStar）、Le（Google Brain/AutoML）四人包揽谷歌基建、初代 AI、Gemini 三代核心技术 `[分类: 共识]`
|
||||
3. **方向：AI 全自动科研** — 不做聊天机器人，让 AI 自主完成科研全流程，先让 AI 研发 AI，再跨界芯片、新材料、新药、清洁能源 `[分类: 未探索]`（公司愿景，作者转述）
|
||||
4. **"友好分手"的止损模式** — Alphabet 战略入股、谷歌云提供算力与云服务，顶级风投领投种子轮；作者解读为谷歌"锁住深度合作关系"的最优止损方案 `[分类: 争议]`（作者的解读，非官方确认）
|
||||
5. **行业风向判断** — 顶尖人才不再迷恋大厂光环，AI 核心赛场将从模型参数/对话体验转向"规模化、工程化的自动科学发现能力" `[分类: 争议]`（作者观点）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设读者需要的是情绪化渲染而非核实后的信息，并假设"创始人阵容天花板"的判断标准成立（影响力排行榜无从考证）；同时假设 Discovery Loop 的科研愿景（AI 自主科研闭环）在可预见时间内技术上可行。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
全文无任何一手证据：没有官方公告原文、无公司注册信息、无当事人声明引用，"五周酝酿""种子轮顶配"等关键细节均无出处；逻辑上以"阵容强→必然颠覆行业"的简单推断替代论证，从事件直接跳到"下一轮 AI 大赛道来了"的结论，跳跃明显。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论（"AI 内卷彻底变天""谁掌握 AI 自动化科研谁拿下话语权"）是无边界的绝对化断言，未讨论 AI 科研自动化的技术难度、失败可能、以及大厂 AI 实验室（如 DeepMind）同样在做 AI for Science 的竞争背景；事件真伪与细节需以公司官方披露为准。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "谷歌现有架构和系统，只适配搜索、广告、民用消费级产品。"
|
||||
|
||||
> "谁率先掌握AI自动化科研能力，谁就能拿下下一轮AI时代的行业话语权。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 事件本身有信息价值：Jeff Dean 等四人出走并获 Alphabet 入股，是值得记录的行业动态
|
||||
- 快速传达了"AI 竞争主战场可能转向自动化科学发现"的方向性信号
|
||||
|
||||
**不足**：
|
||||
- 标题党式写法（"最炸""含金量恐怖"）稀释信息密度，无任何一手来源与数据支撑
|
||||
- 关键细节（融资额、公司成立时间、商业模式）全部缺失，无法独立核实
|
||||
- 对 AI 科研自动化这一主题只有口号式描述，无技术可行性的任何讨论
|
||||
|
||||
**适用场景**：快速浏览行业动态的读者（当作线索而非结论）；如需引用事件本身，应回到谷歌官方公告或可靠信源核实。
|
||||
|
||||
**关联建议**：跟踪 DeepMind 的 AI for Science 进展与 OpenAI 的科学研究智能体方向对比阅读；事件细节可查询 Google 官方博客或 Bloomberg/Reuters 报道核实；若对"AI 自动化科研"感兴趣，可阅读 AlphaFold 类项目的技术论文了解当前边界。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
本篇文章为低价值，未生成配图。
|
||||
@@ -0,0 +1,155 @@
|
||||
# 【昇腾大规模专家并行技术解码】PD分离，让推理性能再提速30%！
|
||||
|
||||
> **来源**：昇腾社区（技术干货）
|
||||
> **作者**：未知（昇腾官方，未署名）
|
||||
> **发布日期**：2025-04-23
|
||||
> **原文链接**：https://www.hiascend.com/developer/techArticles/20250423-1
|
||||
|
||||
---
|
||||
|
||||
随着大语言模型（LLM）的快速发展，提升用户体验、增加吞吐和并发成为关键。昇腾推出大规模专家并行推理方案，通过优化专家分布、通信计算加速，将单卡吞吐提升了3倍以上。然而，LLM的Prefill和Decode阶段"混合部署"在吞吐和时延上仍存在瓶颈，针对这一问题，昇腾使用PD分离技术，进一步将吞吐量提升了30%以上，取得性能&效率的双提升。
|
||||
|
||||
## 大模型推理的趋势和挑战
|
||||
|
||||
生成式人工智能的核心 —— 大规模语言模型推理，其推理过程通常分为两个阶段：Prefill阶段和Decode阶段。Prefill阶段负责处理用户的输入生成初始KV缓存，并生成第一个Token（字），而Decode阶段则负责后续Token的生成。如下图：
|
||||
|
||||
*文本经过Prefill计算和Decode解码*
|
||||
|
||||
一方面，随着AI大模型的发展，数百GB模型权重文件、千亿参数模型更加常见。在"尝鲜"时，数百GB的MoE模型加载使推理效率降低，因此，通过集群化部署，将**MoE模型专家拆分到多张NPU卡上进行专家并行（EP）成为趋势**。
|
||||
|
||||
另一方面，在传统部署方案中，Prefill和Decode这两个阶段往往运行在同一个计算节点上，导致传统部署方案存在如下问题：
|
||||
|
||||
- **1.PD时延互相干扰**：Prefill和Decode阶段互相等待，用户需要增加等待时延，为了保证用户体验（时延小于100ms)，必须牺牲并发，降低吞吐率。
|
||||
- **2.计算与访存冲突**：Prefill阶段是计算密集型任务，Decode阶段是访存密集型任务，混合在同一节点上的运行，会导致算力和显存资源的竞争冲突。
|
||||
- **3.资源利用不足**：两阶段硬件需求差异较大，为保证效果需要算力、显存资源过配置，混合部署难以充分利用资源，存在资源利用不足的问题。
|
||||
|
||||
### 1. 昇腾大规模专家并行方案
|
||||
|
||||
本方案是将数百个专家（Expert）离散地分布到更多的卡上。
|
||||
|
||||
*大规模专家并行专家分配示意图*
|
||||
|
||||
这个方案可以做到：
|
||||
|
||||
- **1.权重加载更快**：每张卡只需要加载部分专家权重，整体时延降低；
|
||||
- **2.并行路数更多**：单卡专家少，空闲显存更多，显著提升并行的路数；
|
||||
- **3.资源利用率更高**：专家可以充分利用单卡上的资源，整体提高效率；
|
||||
|
||||
因此，大规模专家并行方案可以实现更大的吞吐和更低的时延。
|
||||
|
||||
### 2. 昇腾PD实例分离方案
|
||||
|
||||
结合大规模专家并行方案，昇腾进一步通过MindIE推理引擎的调度，将Prefill和Decode阶段分别部署到不同的服务器上，分别作为P实例和D实例：
|
||||
|
||||
*将服务器做PD实例分离示意图*
|
||||
|
||||
通过PD分离，可以达到：
|
||||
|
||||
- **1.消除PD间时延干扰**：Decode可以使用更大的BatchSize，计算效率更高。
|
||||
- **2.PD灵活配比调节**：可以根据PD需要的计算资源，独立地调整资源的比例，资源利用更充分。
|
||||
- **3.PD资源解耦**： P实例和D实例使用不同的硬件资源，避免资源的冲突。
|
||||
|
||||
## 快速部署
|
||||
|
||||
### 1. 环境准备
|
||||
|
||||
**硬件需求：**
|
||||
|
||||
以16台昇腾服务器为例，8台组成4个P实例，8台作为1个D实例。服务器需具备高算力和大显存（推荐使用昇腾Atlas 800系列）。同时，确保服务器之间网络带宽充足（建议200Gbps或以上）。
|
||||
|
||||
**软件环境：**
|
||||
|
||||
- **1.安装k8s环境；**
|
||||
- **2.集群节点安装MindCluster调度组件；**
|
||||
- **3.安装MindIE镜像，支持大规模专家并行调度、PD分离功能。**
|
||||
|
||||
**准备权重：**
|
||||
|
||||
可从"魔乐社区"准备DeepSeek-R1 INT8量化版模型权重文件。
|
||||
|
||||
### 2.配置和启动服务
|
||||
|
||||
**准备配置文件**
|
||||
|
||||
从"昇腾社区"获取最新版本的MindIE软件包文件Ascend-mindie_2.0.RC1_linux-aarch64.run，拷贝到Linux本地，并执行如下命令：
|
||||
|
||||
```
|
||||
chmod +x Ascend-mindie_2.0.RC1_linux-aarch64.run
|
||||
./Ascend-mindie_2.0.RC1_linux-aarch64.run --extract=mindie
|
||||
/mindie/Ascend-mindie-service_2.0.RC1_py311_linux-aarch64.run
|
||||
--extract=mindie-service
|
||||
cd mindie-service/examples/kubernetes_deploy_scripts
|
||||
cp ../../conf/config.json ./conf/config_p.json
|
||||
cp ../../conf/config.json ./conf/config_d.json
|
||||
cp ../../conf/http_client_ctl.json ./conf
|
||||
cp ../../conf/ms_controller.json ./conf
|
||||
cp ../../conf/ms_coordinator.json ./conf
|
||||
```
|
||||
|
||||
根据业务需求，执行命令修改当前目录下的配置文件"user_config.json"
|
||||
|
||||
```
|
||||
vim user_config.json
|
||||
```
|
||||
|
||||
**PD分离部署参数配置：**
|
||||
|
||||
设置 Prefill 和 Decode 阶段的实例数量 ，保持两者处理速度匹配，如下配置为4个Prefill实例，每个实例2台服务器，1个Decode实例，每个实例8台服务器。
|
||||
|
||||
```
|
||||
"p_instances_num": 4, // 配置4个Prefill实例
|
||||
"d_instances_num": 1, // 配置2个Decode实例
|
||||
"single_p_instance_pod_num": 2, // 单个Prefill实例使用2个服务器
|
||||
"single_d_instance_pod_num": 8, // 单个Decode实例使用8个服务器
|
||||
```
|
||||
|
||||
可根据实际业务负载，调整实例数量和实例服务器配置。
|
||||
|
||||
**大规模专家并行部署配置：**
|
||||
|
||||
将模型拆分为多个 Expert 实例，分别部署到不同的 NPU卡上。
|
||||
|
||||
```
|
||||
"moe_ep": 4, // Prefill实例或Decode实例的MOE EP配置
|
||||
"moe_tp": 4, // Prefill实例或Decode实例的MOE 配置
|
||||
```
|
||||
|
||||
**调度与资源管理：**
|
||||
|
||||
使用 MindIE 的调度器协调Prefill和Decode阶段的任务分配。根据负载变化自动调整批处理大小（Batch Size），提升吞吐量。
|
||||
|
||||
```
|
||||
"maxPrefillBatchSize": 4, // Prefill实例一个batch中包含请求个数的上限
|
||||
"maxPrefillTokens": 4096, // Prefill实例一个batch中包含input token总数的上限
|
||||
```
|
||||
|
||||
**拉起服务：**
|
||||
|
||||
在当前目录执行如下命令拉起服务。观察服务日志 。
|
||||
|
||||
```
|
||||
python3 deploy_ac_job.py
|
||||
bash log.sh
|
||||
```
|
||||
|
||||
当MS Coordinator中出现"MindIE-MS coordinator is ready!!!"时，表示服务拉起成功。
|
||||
|
||||
### 3.性能监控与优化
|
||||
|
||||
使用 MindIE 的性能分析组件，实时监控各节点的负载、时延和吞吐量。
|
||||
|
||||
```
|
||||
benchmark --DatasetPath $dataset_path
|
||||
--ModelName dsv3_w8a8 --ModelPath $weight_path --TestType openai --Http http://$ip:$port
|
||||
--Tokenizer True --MaxOutputLen 2048 --DatasetType gsm8k --WarmupSize 0
|
||||
--RequestRate 12 --Concurrency 2048 --SamplingParams
|
||||
'{"ignore_eos":true}' --WorkersNum 4 --TaskKind text --WarmupSize 0
|
||||
```
|
||||
|
||||
可观察到如下的回显。
|
||||
|
||||
## 结语
|
||||
|
||||
昇腾PD分离技术通过对LLM推理过程中的计算密集型和访存密集型任务进行解耦，结合大规模专家并行方案，显著提升了系统性能和资源利用率，为用户实实在在地节约了成本，提升了业务的质量。这一技术不仅为大规模语言模型的高效推理提供了新的解决方案，也为AI算力的高效利用开辟了新方向。
|
||||
|
||||
未来，随着昇腾处理器在更多场景中的应用，PD分离技术将进一步释放LLM的潜力，为各行业带来更智能化、高效的AI体验。
|
||||
@@ -0,0 +1,79 @@
|
||||
# 📊 文章摘要：【昇腾大规模专家并行技术解码】PD 分离，让推理性能再提速 30%！
|
||||
|
||||
> **原文**：[2025-04-23_昇腾大规模专家并行技术解码_PD分离_让推理性能再提速30%.md](./2025-04-23_昇腾大规模专家并行技术解码_PD分离_让推理性能再提速30%.md)
|
||||
> **原文链接**：https://www.hiascend.com/developer/techArticles/20250423-1
|
||||
> **来源**：昇腾社区
|
||||
> **作者**：未知（昇腾官方，未署名）
|
||||
> **发布日期**：2025-04-23
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **双技术叠加** — "大规模专家并行 × PD 分离"组合是昇腾 NPU 上吞吐"3 倍 + 30%"的实现路径，且给出 MindIE 上的可复现部署配置。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是昇腾官方技术稿，介绍其大规模专家并行推理方案（将数百个专家离散分布到多张 NPU 卡：权重加载更快、并行路数更多、资源利用率更高，单卡吞吐提升 3 倍以上），并指出 P/D 混合部署仍有"时延互相干扰、计算访存冲突、资源利用不足"三痛点，因此通过 MindIE 引擎把 prefill/decode 分离为 P 实例与 D 实例，吞吐量再提升 30% 以上。价值在于它是少见的"EP + PD 组合"实操文：给出 k8s + MindCluster + MindIE 2.0.RC1 环境、魔乐社区 DeepSeek-R1 INT8 权重、实例数与 EP/TP/batch 配置参数、benchmark 验证命令，可直接照做。局限：性能数字无测试条件与基线说明，宣传性质明显。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **混合部署三痛点** — PD 时延互相干扰（为保证时延小于 100ms 须牺牲并发）、计算与访存冲突、为保证效果需算力显存过配置导致利用不足 `[分类: 共识]`
|
||||
2. **大规模专家并行三收益** — 每卡只加载部分专家权重（加载更快）、单卡专家少空闲显存多（并行路数更多）、专家充分利用单卡资源（利用率更高） `[分类: 共识]`
|
||||
3. **PD 分离三收益** — 消除阶段间时延干扰（decode 可用更大 BatchSize）、PD 配比独立调节、P/D 使用不同硬件资源实现资源解耦 `[分类: 共识]`
|
||||
4. **可复现部署路径** — 16 台服务器（4 个 P 实例×2 台 + 1 个 D 实例×8 台）、网络建议 200Gbps 以上；MindIE 配置 p_instances_num/d_instances_num/moe_ep/moe_tp/maxPrefillBatchSize 等参数 `[分类: 共识]`（实操）
|
||||
5. **性能验证手段** — MindIE benchmark 命令（gsm8k 数据集、并发 2048、RequestRate 12）与各节点负载、时延、吞吐监控 `[分类: 共识]`（实操）
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设用户具备昇腾 Atlas 800 系列硬件与 MindIE 生态（魔乐社区权重）；假设服务器间 200Gbps 以上网络带宽可保证 KV 传输效率；假设其性能声称（3 倍、30%）在类似环境中可复现。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
性能数字（单卡吞吐提升 3 倍、PD 分离再提升 30% 以上）未给出测试负载、模型规格与对比基线，作为官方宣传文无法独立验证；但部署指南步骤完整、参数明确，可执行性强。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
仅适用于昇腾 NPU + MindIE 技术栈，跨厂商迁移需重做；未讨论 KV 传输机制细节与调度复杂度；P/D 配比 4P:1D 仅以"保持两者处理速度匹配"概括，缺乏量化依据。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "昇腾使用PD分离技术，进一步将吞吐量提升了30%以上，取得性能&效率的双提升。"
|
||||
|
||||
> "将数百个专家（Expert）离散地分布到更多的卡上。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- "EP + PD 分离"组合与国产 NPU 生态（MindIE、魔乐社区权重）结合，信息稀缺
|
||||
- 部署配置参数具体可复现，含 benchmark 验证命令
|
||||
- 给出网络带宽（200Gbps）与实例配比等可参考基线
|
||||
|
||||
**不足**：
|
||||
- 性能数据无测试条件与基线，难以独立验证
|
||||
- 偏官方宣传口径，未讨论局限与失败场景
|
||||
- 仅覆盖昇腾栈，通用性有限
|
||||
|
||||
**适用场景**：昇腾 NPU 集群的推理部署工程师；想评估国产算力上 PD 分离方案的团队。
|
||||
|
||||
**关联建议**：对照昇腾 MindIE 官方文档核对配置项；与 NVIDIA Dynamo/vLLM 的 PD 分离部署做横向对比。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,115 @@
|
||||
# GTC 解读：当我们谈论 AI 推理的 KV Cache，我们在做什么？
|
||||
|
||||
> **来源**：极客公园
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-03-25
|
||||
> **原文链接**：https://www.geekpark.net/news/361648
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
摘要
|
||||
|
||||
2026年3月，在全球人工智能与GPU计算领域最具影响力的技术盛会——NVIDIA GTC 2026大会上，阿里云资深技术总监张为受邀发表演讲，带来了《基于全局KV Cache存储系统的高效LLM推理加速方案》的深度分享。
|
||||
|
||||
2026年3月，在全球人工智能与GPU计算领域最具影响力的技术盛会——NVIDIA GTC 2026大会上，阿里云资深技术总监张为受邀发表演讲，带来了《基于全局KV Cache存储系统的高效LLM推理加速方案》的深度分享。
|
||||
|
||||
这不是一次普通的技术发言。NVIDIA GTC大会汇聚了全球顶尖的AI科学家、工程师与产业领袖，每一个受邀Session都经过严苛筛选。这次入选，不仅是对阿里云Tair在AI推理基础设施领域多年积累的高度认可，更标志着中国云计算厂商在全球AI底层技术话语权上迈出了关键一步。
|
||||
|
||||
在 AI 从「模型能力竞争」转向「工程效率竞争」的今天，KV Cache 管理正成为大模型推理链路中最关键的性能瓶颈之一。GPU 显存贵、上下文长、并发高——这三重压力叠加之下，如何用存储的智慧释放算力的潜能，是整个行业都在苦寻的答案。
|
||||
|
||||
阿里云数据库 Tair 给出了自己的回答：从分层调度、全局池化、混合模型适配，到与SGLang社区深度共建、联合NVIDIA Dynamo AIConfigurator 团队开发高保真仿真器，再到面向未来硬件的G3.5定制存储探索——一套覆盖全链路的系统性解法，正在重新定义AI时代的存储基础设施。
|
||||
|
||||
本文是对张为GTC演讲的深度复盘与延伸解读，带你从原理到架构、从挑战到未来，完整理解这场正在发生的存算协同革命。
|
||||
|
||||
当前，AI 的应用正经历从「单一模型交互」向「自主智能体（Agent）集群协作」的关键范式转移。随着 OpenClaw 等新一代框架的爆发，应用侧对长上下文、多轮记忆及复杂任务规划的需求呈指数级增长，基础设施面临前所未有的挑战。在此背景下，阿里云资深技术总监张为在 GTC 2026 Session 中介绍__《基于全局KV Cache 存储系统的高效 LLM 推理加速方案》__（👉 点击查看视频回放👉 点击下载），这一分享不仅引发了业界的广泛讨论与共鸣，更标志着存储层在 AI 推理链路中的战略地位从「辅助支撑」向「核心驱动」转变，确立了存算协同作为突破算力瓶颈的关键路径。本文将以此次分享为核心线索，从 KVCache 的技术原理、架构演进、工程挑战到未来硬件趋势，为大家带来一次系统性的深度复盘与解析，旨在为构建高效、经济的 AI 推理基础设施提供实践参考。
|
||||
|
||||
## __KVCache 作用和应用发展趋势__
|
||||
|
||||
[图片]
|
||||
|
||||
[图片]
|
||||
|
||||
KV Cache 是大语言模型推理的核心优化技术，其本质是"以内存换算力"。在 Prefill 阶段缓存 Key/Value 状态，Decode 阶段直接复用历史缓存，避免重复计算，将冗余的矩阵运算转化为高效内存读取，显著降低延迟与推理成本。
|
||||
|
||||
当前，KV Cache 已广泛应用于系统提示词复用、多轮对话记忆、长文档检索及多模态处理等场景，成为提升生产效能的关键。随着自主智能体时代到来，其需求呈指数级增长：上下文长度从 4K 扩展至 256K tokens、跨轮次缓存持久化、RAG 动态注入外部知识、高并发批处理，四大维度叠加使内存压力激增 8-16 倍。
|
||||
|
||||
然而，GPU 高带宽内存容量已成为物理瓶颈。传统方案如强制清除历史、卸载至 CPU 或降低批量，均会损害可靠性或实时性。
|
||||
|
||||
基于与主流模型厂商的深度研讨，针对 OpenClaw 类 Agent 应用及未来多模态 1M 长上下文场景，行业共识已指向构建智能分层、业务感知的 KV Cache 管理体系，这将是突破「内存墙」、释放智能体潜力的核心方向。具体演进路径包含三个层面：
|
||||
|
||||
1. __存储智能分层__：建立类似操作系统虚拟内存的多级架构，热数据驻留 GPU HBM，温数据卸载至 Host DRAM，冷数据持久化至远端高性能存储，实现容量与成本的平衡。
|
||||
2. __业务感知调度__：淘汰策略从简单的 LRU（最近最少使用）升级为基于任务类别的冷热数据区分。
|
||||
3. __存算分离与池化__：推动 KV Cache 存储与计算算力解耦，通过全局资源池化打破单卡显存限制，为「无限上下文」提供底层支撑。
|
||||
|
||||
## __我们 (阿里云数据库 Tair KVCache) 在做什么？__
|
||||
|
||||
|
||||
|
||||
我们看到__范式转移__：当前正从"移动时代"的孤立应用架构（每应用独立数据库），迈向"模型即服务"的超级应用时代。用户通过统一入口与智能体交互，由底层 LLM 推理服务并发处理代码生成、对话、分析等多元任务，实现能力融合与资源集约。
|
||||
|
||||
在这一变革中，__数据访问模式发生了根本性变化__。传统的 Transactional Load（交易型负载）正演变为 Inference Load（推理型负载）。阿里云数据库 Tair KVCache 正顺势而为，实现从互联网时代面向高并发交易，到 AI 时代面向高吞吐推理的战略延展，成为连接算力与模型的关键存储枢纽。
|
||||
|
||||
__传统缓存经验在 AI 时代的复用__
|
||||
|
||||
尽管负载类型变了，但存储系统的核心设计哲学在 AI 推理中依然成立。Tair 将互联网时代成熟的缓存架构经验，平滑迁移至 AI 基础设施中：
|
||||
|
||||
| 传统互联网架构 (Mobile Era) | AI 推理架构 (MaaS Era) | 核心价值 |
|
||||
| --- | --- | --- |
|
||||
| __统一接口__：应用通过 KV 接口 (如 Redis) 访问缓存 | __统一抽象__：推理引擎通过标准 KV 接口访问 KVCache | __解耦计算与存储__，屏蔽底层硬件差异 |
|
||||
| __多级存储__：App Local Cache → 远端分布式缓存 → 持久化 DB | __显存层级__：GPU HBM → Host DRAM → 远端高性能存储 (Tair) | __冷热分离__，降低高昂的 GPU 显存成本 |
|
||||
| __预计算加速__：缓存复杂查询或者中间计算结果，避免重复计算，减少DB压力 | __中间态复用__：缓存 Attention 计算中间结果 (Prefix Caching) | __加速首字延迟 (TTFT)__，提升推理吞吐量 |
|
||||
|
||||
1. __接口标准化：__ 正如互联网应用依赖 Redis 协议，AI 推理引擎同样需要一个标准的 KV 抽象层。Tair 提供的高兼容 KV 接口，使得推理框架无需关心底层是 DRAM 还是 SSD，实现计算存储解耦。
|
||||
2. __存储层级化：__ 传统架构中，本地缓存解决延迟，远端缓存解决容量。在 AI 中，GPU HBM 极其昂贵且有限，必须将不活跃的 KVCache 快速卸载（Offload）到 Host DRAM 或远端 Tair 存储中，实现「无限显存」。
|
||||
3. __计算下推与预取：__ 传统缓存通过预计算加速查询；AI 缓存则通过预取（Prefetching）和前缀复用（Prefix Reuse），避免重复计算相同的 Token 序列，直接利用存储能力加速推理效果。
|
||||
|
||||
## __应对推理上 KVCache 的新挑战__
|
||||
|
||||
回顾过去一年的技术演进，阿里云数据库 Tair __深度融入开源生态__，与合作伙伴共同补齐了 KVCache 解决方案的关键拼图。针对推理链路中的核心痛点，我们从分层调度、模型支持、存储优化、全局管理，经济效应及算法创新六个维度进行了系统性优化。
|
||||
|
||||
|
||||
|
||||
1. __推理引擎调度与分层缓存 (Scheduling & HiCache)__
|
||||
针对推理引擎（如 vLLM、SGLang）与存储间缺乏统一标准的问题，我们与__SGLang 社区__合作推出了 HiCache 分层缓存体系。该方案通过显存 - 内存 -3FS 多级卸载与全局共享，解决了存储绑定严重、难以实施多级缓存和智能预取的痛点。缓存命中率提升至 80%，TTFT 降低 56%，推理 QPS 翻倍，支撑智能体时代的大模型高效推理。具体的工作可以参考 __阿里云 Tair 联手 SGLang 共建 HiCache，构建面向"智能体式推理"的缓存新范式__
|
||||
2. __混合模型架构适配 (Hybrid Model Support)__
|
||||
随着模型实现从 Full Attention 快速迭代至 Linear Attention（如 QWen、Kimi）及 Sparse Attention（如 DeepSeek、GLM），我们及时优化了 KVCache 的管理方式。在__SGLang 社区__中，我们负责实现了对 Mamba-Transformer 等混合架构模型的远端KVCache 支持及表示层兼容。确保新一代高效模型也能享受存算分离带来的容量红利，无需因架构差异而牺牲缓存性能。具体的工作可以参考 __Hybrid Model Support：阿里云 Tair 联合 SGLang对 Mamba-Transformer 等混合架构模型的支持方案__、__SGLang Hierarchical Sparse Attention 技术深度解析__
|
||||
3. __元数据管理与全局池化 ( KVCache Manager )__
|
||||
针对 Agent 长会话、高并发导致的调度与命中率冲突，我们建设 Tair KVCache Manager。基于高性能网络实现 KVCache 全局池化，引入 LLM 语义层 抽象管理元数据，向上暴露原生接口，向下高效调度存储，兼顾落地速度与长期演进。实现存算彻底解耦，支持推理容器弹性伸缩而不影响缓存命中率；提供 ROI 评估、可观测性及高可用等企业级能力，显著降低 GPU 消耗并提升服务质量。具体的工作可以参考我们和__集团 RTP-LLM__ __开源共建____的____阿里云 Tair KVCache Manager：企业级全局 KVCache 管理服务的架构设计与实现__
|
||||
4. __高性能远端存储落地__
|
||||
针对 KVCache 对带宽与容量的双重需求，我们和__服务器团队__以 3FS 为基座，通过 RDMA 全链路加速、GDR 零拷贝、小 I/O 调优及云原生 Operator 等系统性升级，打造专为 LLM 推理优化的 L3 存储层，并与 SGLang/vLLM 深度集成。实现 20GB/s+ 单节点带宽与 PB 级弹性容量，长上下文场景 TTFT 下降 78%、推理吞吐提升 520%，在保障低延迟的同时显著降低单位存储成本。具体的工作参考：__阿里云 Tair 基于 3FS 工程化落地 KVCache：企业级部署、高可用运维与性能调优实践__
|
||||
5. __经济效应模拟与 ROI 评估 ( Simulation & ROI )__
|
||||
面对 MaaS 时代负载波动大、配置空间爆炸的「黑盒」挑战，我们和__NVIDIA Dynamo 团队__联合推出 Tair-KVCache-HiSim 高保真仿真器。采用分层解耦 + 事件驱动架构，支持端到端推理流程建模与细粒度时延预测，实现配置空间的帕累托最优搜索。仿真成本降低 39 万倍、端到端误差<5%，帮助客户从「经验规划」转向「数据驱动」，在满足 SLO 约束下快速定位成本 - 延迟 - 吞吐的最优平衡点。具体的工作参考: __阿里云Tair KVCache仿真分析：高精度的计算和缓存模拟设计与实现__
|
||||
6. __算法优化与多模态支持 (Algorithm)__
|
||||
针对多模态输入重复场景，我们与__通义实验室__联合推出 VLCache 缓存复用框架。首次形式化识别"累积复用误差效应"，提出层感知动态重计算策略，协同复用 KV Cache 与 Encoder Cache，仅需计算 2–5% tokens 即可实现准确率持平。TTFT 加速 1.2–16 倍，显著降低多模态场景显存占用与计算成本；基于 SGLang 的工程实现，支持实际部署中的高效推理。同时KVCache量化，压缩，稀疏化的工作正在积极和各大高校和实验室合作，相关的学术研究工作正在投递中。具体的工作参考：__VLCACHE: Computing 2% Vision Tokens and Reusing 98% for Vision–Language Inference__
|
||||
|
||||
此前，业界 KVCache 方案往往局限于单一环节（如仅优化引擎或仅做存储），缺乏统一标准、全局管理及效果评估手段，导致落地困难、成本不可控。Tair KVCache 通过上述六大模块，首次实现了从引擎调度、存储底座、元数据管理、仿真评估到算法优化的全链路覆盖。这不仅补齐了行业在标准化、可观测性及经济性评估上的缺失环节，我们还联合清华、火山 、腾讯、华为等业内伙伴，共同推动 KVCache 服务化标准的制定，为 Agent 时代的大模型推理提供了坚实、完整的基础设施底座。
|
||||
|
||||
## __AI Memory 对于未来存储的演进需求__
|
||||
|
||||
|
||||
|
||||
[图片]
|
||||
|
||||
- 带宽-容量解耦。核心诉求是 TB 级存储容量与 IOPS 性能能够独立扩展，解决的问题是不再为了达到带宽目标而"被迫购买额外容量"，降低资源浪费。
|
||||
- 弹性容量。核心诉求是支持平滑扩容、按需付费，解决的问题是避免资源闲置带来的成本浪费，提升资源利用效率。
|
||||
- 可预测低延迟。核心诉求是严格满足 TTFT（首 token 时间）的 SLA 要求，解决的问题是保障每个请求的用户体验一致性，避免长尾延迟影响服务质量。
|
||||
- 负载-存储匹配。核心诉求是根据不同工作负载的访问模式，匹配最适合的存储介质类型，解决的问题是延长 SSD 使用寿命，同时优化整体成本结构。
|
||||
- 最优总拥有成本（TCO）。核心诉是在综合考虑硬件采购、运维管理、能源消耗等所有成本因素后，实现整体成本最优，这是技术方案商业可持续的关键。
|
||||
|
||||
## __软硬结合 KV Cache 定制的 G3.5 存储__
|
||||
|
||||
与传统通用存储方案相比，G3.5 方案有四个核心差异：第一定位上专为 KV Cache 优化，而非通用数据存储；第二接入方式采用网络附加+智能预取，而非简单的本地或网络挂载；成本效率上实现容量与带宽独立扩展，按需付费，避免资源浪费。
|
||||
|
||||
ICMS 核心能力包括三点：上下文智能放置（决定哪个 KV 数据块存放在哪个位置）、硬件级加密（保障数据安全的同时不拖累性能）、块级追踪（精准预取数据，减少冗余传输）。性能指标达到 800Gbps 线速处理。关键价值在于绕过 CPU，实现 GPU 与 Flash 存储之间的直连，大幅降低延迟。
|
||||
|
||||
Tair-KVCache 负责全局调度决策。NVMe-over-Fabrics 深度集成两者协同的效果是让远程闪存在应用层面"看起来像本地内存"，对上层透明。此时我们在积极和__NVIDIA__以及__云存储团队__探索定制 KVCache 存储的后续发展。
|
||||
|
||||
## __硬件突破展望__
|
||||
|
||||
我们和__服务器团队__在积极探索下一代 KVCache 存储介质的选型和发展。
|
||||
|
||||
- HBF（High Bandwidth Flash）高带宽闪存 将 HBM（高带宽内存）采用的 3D 堆叠技术直接应用于标准 NAND 闪存芯片。性能飞跃：单栈可实现 1.6TB/s 的读取带宽，相当于当前顶级 SSD 性能的 50 倍。应用想象：百万 token 级别的 KV Cache 可以直接"贴近"GPU 部署，获得接近 HBM 的访问速度、闪存的大容量优势，同时不产生额外功耗负担。
|
||||
- PIM（Processing-in-Memory）存内计算。在存储芯片内部嵌入轻量级计算单元，实现"计算向数据移动"。范式转变：传统模式是把原始 tensor 数据从存储搬到 GPU 进行计算，容易遇到网络带宽瓶颈；新模式是在存储端直接完成 attention 分数等关键计算，只将最终的小结果通过网络传输。核心价值：大幅减少数据搬运量，从根源上突破"内存墙"限制。
|
||||
- CXL 4.0 + PCIe 7.0：互联协议革命 带宽相比 CXL 3.0 翻倍；新增"Bundled Ports"技术，支持多链路聚合；跨机架内存池带宽可达 1.5TB/s。架构意义：让"内存"真正成为可池化、可共享的资源，打破单机内存容量限制，为大规模模型推理提供弹性内存支持。
|
||||
@@ -0,0 +1,77 @@
|
||||
# 📊 文章摘要：GTC 解读：当我们谈论 AI 推理的 KV Cache，我们在做什么？
|
||||
|
||||
> **原文**：[2026-03-25_GTC_解读_当我们谈论_AI_推理的_KV_Cache_我们在做什么.md](./2026-03-25_GTC_解读_当我们谈论_AI_推理的_KV_Cache_我们在做什么.md)
|
||||
> **原文链接**：https://www.geekpark.net/news/361648
|
||||
> **来源**：极客公园
|
||||
> **作者**：未知（报道对象：阿里云资深技术总监张为）
|
||||
> **发布日期**：2026-03-25
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **存算协同** — KV Cache 管理正从"引擎内优化"升级为全局存储系统问题，存储层从辅助支撑变为推理的核心驱动。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
文章复盘阿里云资深技术总监张为在 GTC 2026 的演讲《基于全局 KV Cache 存储系统的高效 LLM 推理加速方案》，阐述 Agent 时代 KV Cache 的系统性解法。背景是上下文从 4K 扩至 256K+ tokens、多轮记忆与高并发使内存压力激增 8—16 倍，GPU HBM 构成"内存墙"。Tair KVCache 以六模块覆盖全链路：与 SGLang 共建 HiCache 分层缓存（命中率 80%、TTFT 降 56%）、混合模型适配、全局池化 KVCache Manager、3FS 远端存储（吞吐提升 520%）、与 NVIDIA Dynamo 联建 HiSim 仿真器（误差<5%）、多模态 VLCache（仅算 2—5% token）。并前瞻 G3.5 定制存储（ICMS，800Gbps GPU 直连 Flash）与 HBF/PIM/CXL 4.0 硬件方向，展示存储厂商对推理基础设施话语权的争夺。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **三重压力叠加的内存墙** — 显存贵、上下文长、并发高，KV Cache 需求指数级增长，HBM 物理容量成为瓶颈，强制清除或卸载均损害可靠性或实时性 `[分类: 共识]`
|
||||
2. **缓存哲学跨时代复用** — 互联网缓存三件套（统一接口/多级存储/预计算）平移为 AI 的 KV 抽象层、HBM-DRAM-远端三级卸载与 Prefix Caching，实现"以内存换算力" `[分类: 共识]`
|
||||
3. **HiCache：引擎与存储的统一标准** — 与 SGLang 社区共建的分层缓存体系，显存-内存-3FS 多级卸载与全局共享，命中率 80%、TTFT 降 56%、QPS 翻倍，补齐了引擎与存储间缺乏统一接口的行业空白 `[分类: 范式突破]`
|
||||
4. **全局池化与元数据管理** — KVCache Manager 以 LLM 语义层抽象元数据、高性能网络实现全局池化，支持推理容器弹性伸缩而不影响命中率，实现"无限显存"与存算彻底解耦 `[分类: 范式突破]`
|
||||
5. **高保真仿真驱动容量规划** — 与 NVIDIA Dynamo 共建的 HiSim 事件驱动仿真器，实现配置空间帕累托最优搜索，仿真成本降 39 万倍、端到端误差<5%，把容量决策从经验转向数据 `[分类: 未探索]`
|
||||
6. **VLCache：多模态缓存复用** — 与通义实验室联合推出，首次形式化识别"累积复用误差效应"，层感知动态重计算，仅计算 2—5% tokens 即准确率持平，TTFT 加速 1.2—16 倍 `[分类: 未探索]`
|
||||
7. **面向未来的存储硬件** — G3.5 定制存储（上下文智能放置、硬件级加密、800Gbps 线速）、HBF 高带宽闪存（单栈 1.6TB/s 读取）、PIM 存内计算与 CXL 4.0 内存池化，方向明确但量产未定 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假定 Agent 应用（长会话、多轮记忆、RAG 注入）成为推理主流负载——这是方向判断而非已证实事实；假定全局存储系统（而非引擎内优化）是破"内存墙"的最优路径；假定阿里云公布的数字为可信口径。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
逻辑链条完整（问题→六模块方案→量化收益→硬件展望），但全部性能数字均出自阿里云自测/自报，无第三方复现；"内存压力激增 8—16 倍""仿真成本降 39 万倍"等数字缺乏推导过程；作为 GTC 演讲的媒体复盘，叙述整体服务于品牌叙事，需要打折阅读。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
方案依赖阿里云全家桶（Tair、3FS、通义实验室），迁移到他云或自建需重新评估；G3.5、HBF、PIM 均为探索性方向，量产时间与成本未定；未讨论 KV 卸载的带宽开销、失败恢复、多租户隔离等工程代价。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "KV Cache 是大语言模型推理的核心优化技术，其本质是'以内存换算力'。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 提供了行业公开渠道中少见的量化结果（命中率、TTFT、吞吐提升、仿真成本），可作为同类方案的对照基准
|
||||
- 六模块覆盖"引擎调度-存储底座-元数据-仿真-算法"完整闭环，是理解 KV Cache 工程化全貌的高密度入口；G3.5/HBF/PIM 前瞻有启发价值
|
||||
|
||||
**不足**：
|
||||
- 宣传性叙事较强，数据均为单方自测；对方案局限与成本着墨甚少
|
||||
- 需具备 KV Cache 与推理框架基础才能消化，新手门槛较高
|
||||
|
||||
**适用场景**：负责 LLM 推理基础设施的架构师与研发人员（对照自身缓存方案）；关注"存储厂商如何切入 AI 推理"的行业观察者。
|
||||
|
||||
**关联建议**：对照 SGLang 官方 PD 分离文档理解引擎侧实现；阅读阿里云 Tair 与 SGLang 共建 HiCache 的原始技术文章验证数字；横向对比 NVIDIA Dynamo KVBM 与 Mooncake 开源 KVCache 池化方案。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,190 @@
|
||||
# 大模型推理 PD 分离技术：核心原理、技术优势、挑战与未来展望
|
||||
|
||||
> **来源**：电子工程专辑（EET China）
|
||||
> **作者**：未知（专栏作者未署名）
|
||||
> **发布日期**：2026-08-05（原文未标注）
|
||||
> **原文链接**：https://www.eet-china.com/mp/a412848.html
|
||||
|
||||
---
|
||||
|
||||
随着大语言模型(LLM)在各行业的广泛应用，如何高效地进行模型推理成为关键挑战。PD 分离(Prefill-Decode Disaggregation)技术作为近年来大模型推理领域的重要突破，通过将预填充(Prefill)和解码(Decode)两个阶段分离部署，显著提升了推理效率和资源利用率。
|
||||
|
||||
本文将全面分析 PD 分离技术的核心原理、系统实现、性能优势、现存挑战以及未来发展方向，帮助读者深入理解这一变革性技术及其对 AI 基础设施的影响。
|
||||
|
||||
## 1、PD 分离技术概述与核心原理
|
||||
|
||||
PD 分离技术是大语言模型推理领域的一项重大创新，它从根本上改变了传统 LLM 推理流水线的架构设计。这项技术的出现源于对大模型推理过程中两个关键阶段——Prefill(预填充)和 Decode(解码)——本质差异的深入认识，以及如何针对这些差异进行优化以提高整体系统效率的思考。
|
||||
|
||||
在传统 LLM 推理系统中，Prefill 和 Decode 阶段通常在同一计算设备上顺序执行。Prefill 阶段负责处理所有输入 token，生成初始的 KV 缓存(Key-Value Cache)和第一个输出 token；而 Decode 阶段则基于这些 KV 缓存，通过自回归方式逐步生成后续 token。
|
||||
|
||||
这种传统架构虽然简单直接，但存在明显的性能瓶颈：Prefill 阶段是计算密集型操作，需要大量并行计算能力；而 Decode 阶段则是内存密集型操作，更依赖高带宽内存访问。当这两个阶段共享同一计算资源时，它们的资源需求特性会相互干扰，导致整体效率低下。
|
||||
|
||||
PD 分离技术的核心思想是将 Prefill 和 Decode 这两个阶段解耦，并将它们分配到不同类型的计算设备上执行。
|
||||
|
||||
具体来说，Prefill 阶段被分配到专门的高算力 GPU 上执行，以充分利用其并行计算能力；而 Decode 阶段则被分配到具有大显存和高内存带宽的 GPU 上执行，以满足其内存访问需求。两个阶段之间通过高速网络(如 NVLink 或 RDMA)传输中间状态(主要是 KV 缓存)。
|
||||
|
||||
这种分离架构带来了几个关键优势：首先，它消除了 Prefill 和 Decode 阶段之间的资源竞争，使每个阶段都能在其最优配置下运行；其次，它允许两个阶段并行处理不同请求，提高了系统吞吐量；最后，它使得资源分配更加灵活，可以根据工作负载特征动态调整 Prefill 和 Decode 资源的比例。
|
||||
|
||||
从技术实现角度看，PD 分离系统需要解决几个关键问题：如何高效地在 Prefill 和 Decode 节点间传输 KV 缓存；如何设计调度策略以确保请求在不同阶段间的平滑流转；以及如何为每个阶段选择最优的并行策略(如张量并行、流水线并行等)。现代 PD 分离系统如 DistServe 和 Mooncake 通过创新性的 KV 缓存传输机制和调度算法，已经能够将这些开销控制在可接受范围内，实现了显著的性能提升。
|
||||
|
||||
## 2、PD 分离的技术背景与动机
|
||||
|
||||
大语言模型推理过程的内在特性是 PD 分离技术发展的根本驱动力。理解这些特性对于把握 PD 分离技术的必要性和价值至关重要。LLM 推理通常分为两个截然不同但紧密相连的阶段：Prefill(预填充)阶段和 Decode(解码)阶段，每个阶段在计算模式、资源需求和性能指标上都有显著差异。
|
||||
|
||||
Prefill 阶段是 LLM 推理的初始阶段，负责处理用户输入的整个提示(Prompt)。这一阶段需要一次性处理所有输入 token，计算它们的 Key 和 Value 向量并存储在 KV 缓存中，同时生成第一个输出 token。
|
||||
|
||||
从计算特性看，Prefill 阶段是高度计算密集型的，因为它涉及对模型所有层的完整前向传播，计算复杂度与输入长度呈平方关系(O(n²))。这一阶段能够充分利用 GPU 的并行计算能力，因为所有输入 token 可以并行处理。Prefill 阶段的性能通常用首 token 延迟(TTFT)来衡量，即从请求开始到生成第一个 token 所需的时间，这对用户体验至关重要。
|
||||
|
||||
Decode 阶段则是在 Prefill 完成后进行的迭代过程，基于已生成的 KV 缓存逐步生成后续 token。与 Prefill 不同，Decode 阶段是内存密集型的，每次迭代只需要计算最新 token 的注意力，复杂度与序列长度呈线性关系(O(n))。
|
||||
|
||||
Decode 阶段的特点是严格串行——每次只能生成一个 token，且需要频繁访问和更新 KV 缓存，这使得内存带宽成为主要瓶颈。Decode 阶段的性能通常用每 token 时间(TPOT)来衡量，即生成两个连续 token 之间的平均时间，这决定了输出的流畅度。
|
||||
|
||||
表：Prefill 阶段与 Decode 阶段的特性对比
|
||||
|
||||
| 特性 | Prefill（预填充）阶段 | Decode（解码）阶段 |
|
||||
| --- | --- | --- |
|
||||
| 计算模式 | 并行计算（所有输入 Token 同时处理） | 串行计算（逐个 Token 生成） |
|
||||
| 计算强度 | 计算密集型（矩阵乘法为主） | 内存带宽受限（访存频繁） |
|
||||
| GPU 利用率 | 高（接近 100%） | 极低（约 1%） |
|
||||
| 关键性能指标 | 首次 Token 时间（TTFT） | Token 生成时间（TPOT） |
|
||||
| 主要瓶颈 | 算力（FLOPs） | 内存带宽（Memory Bandwidth） |
|
||||
| 显存占用 | 临时高（需缓存输入序列） | 持续高（需保存 KV Cache） |
|
||||
| 批处理优化空间 | 大（可合并多请求输入） | 小（动态调整生成任务） |
|
||||
| 典型延迟 | 短（毫秒级，如 0.2 秒处理 255 Token） | 长（秒级，如 32 秒生成 256 Token） |
|
||||
| 加速手段 | Tensor Core 加速、FP16/INT8 量化 | 内存访问优化、KV Cache 压缩 |
|
||||
| 通信需求 | 低（单节点可完成） | 高（分布式需同步 KV Cache） |
|
||||
| 调度优先级 | 高（优先保证 TTFT） | 中（需稳定 TPOT） |
|
||||
|
||||
在传统共置架构中，Prefill 和 Decode 阶段在同一设备上顺序执行，这导致了几个严重问题。
|
||||
|
||||
- 首先，当系统采用连续批处理(continuous batching)技术提高吞吐量时，Prefill 和 Decode 请求会相互干扰——新到达的 Prefill 请求会抢占正在进行的 Decode 请求的资源，导致 Decode 延迟出现尖峰，用户感知为输出"卡顿"。
|
||||
- 其次，两个阶段的最优并行策略不同：Prefill 阶段适合使用张量并行(TP)来降低延迟，而 Decode 阶段则更适合流水线并行(PP)来提高吞吐量。共置架构无法同时满足这两种需求，导致资源利用率低下。
|
||||
|
||||
性能干扰问题在实际系统中表现得尤为明显。研究表明，在共置架构下，当 Prefill 和 Decode 请求混合处理时，Decode 的 P99 延迟(99%请求的延迟)可能增加 78%以上。这种干扰不仅影响用户体验，还迫使系统过度配置资源以满足服务水平目标(SLO)，显著增加了运营成本。正是这些挑战促使研究者探索将 Prefill 和 Decode 阶段物理分离的解决方案，最终发展出了 PD 分离技术。
|
||||
|
||||
此外，不同应用场景对延迟的需求差异也加剧了共置架构的问题。例如，聊天机器人需要极低的 TTFT(如<200ms)但可以接受适中的 TPOT；而代码补全则需要快速连续的 token 生成。PD 分离允许针对不同应用定制 Prefill 和 Decode 资源配置，从而更好地满足多样化的 SLO 需求。
|
||||
|
||||
## 3、PD 分离的性能优势
|
||||
|
||||
PD 分离（Prefill-Decode Separation）是大模型推理中的一项关键技术，通过将推理过程划分为 Prefill（预填充）和 Decode（解码）两个独立阶段，并针对其不同计算特性进行优化，显著提升了推理效率和资源利用率。
|
||||
|
||||
### (1) 显著提升推理吞吐量
|
||||
|
||||
- **Prefill 阶段**：并行处理所有输入 Token，计算密集度高，GPU 算力利用率接近饱和。
|
||||
- **Decode 阶段**：逐个生成 Token，内存带宽受限，算力利用率低。
|
||||
- **PD 分离**：通过独立优化两阶段计算，避免 Decode 阶段的算力浪费，提升整体吞吐量。
|
||||
|
||||
### (2) 降低延迟，优化用户体验
|
||||
|
||||
- **首次 Token 时间（TTFT）**：Prefill 阶段优化可减少首次响应时间。
|
||||
- **Token 生成时间（TPOT）**：Decode 阶段优化可提高 Token 生成速度，使交互更流畅。
|
||||
|
||||
### (3) 提高硬件资源利用率
|
||||
|
||||
- 传统统一处理模式下，Decode 阶段 GPU 算力浪费严重（利用率仅约 1%）。
|
||||
- PD 分离后，可针对 Prefill（计算密集型）和 Decode（内存密集型）分别优化，最大化 GPU 利用率。
|
||||
|
||||
### (4) 支持动态调度与连续批处理
|
||||
|
||||
- PD 分离允许智能调度不同阶段的请求，如：
|
||||
- **Prefill 阶段**：批量处理多个请求的输入 Token。
|
||||
- **Decode 阶段**：动态调整生成任务，避免资源争抢。
|
||||
|
||||
## 4、实证结果
|
||||
|
||||
### (1) 实验数据：Prefill vs. Decode 速度差异
|
||||
|
||||
- **测试条件**：5 个并发请求，输入 255 Token，生成 256 Token。
|
||||
- **结果**：
|
||||
- **Prefill 阶段**：0.2394 秒（5325.18 tokens/s）。
|
||||
- **Decode 阶段**：32.8948 秒（38.76 tokens/s）。
|
||||
- **速度差异**：Decode 阶段比 Prefill 慢约 137 倍，占整体推理时间的 99%。
|
||||
|
||||
### (2) 百度智能云的优化实践
|
||||
|
||||
- **网络架构**：采用低时延 HPN 集群（4μs 端到端延迟），优化 Alltoall 通信，减少跨机流量干扰。
|
||||
- **KV Cache 传输**：通过 RDMA 实现高带宽传输，减少 Prefill 与 Decode 间的数据交换延迟。
|
||||
- **调度优化**：分队列管理 Prefill/Decode 流量，避免拥塞，提升整体吞吐量 20%。
|
||||
|
||||
### (3) PD 分离的实际收益
|
||||
|
||||
- **延迟降低**：首次 Token 生成时间（TTFT）显著缩短。
|
||||
- **吞吐量提升**：单位时间内可处理更多并发请求。
|
||||
- **成本优化**：减少 GPU 闲置，降低部署成本。
|
||||
|
||||
## 5、PD 分离关键技术挑战与解决方案
|
||||
|
||||
### (1) 计算资源动态分配的挑战
|
||||
|
||||
**挑战描述**
|
||||
|
||||
- **Prefill 阶段**：计算密集型，需要高并行计算能力（如矩阵乘法），GPU 算力利用率高。
|
||||
- **Decode 阶段**：内存带宽受限，逐个 Token 生成，算力利用率低（仅约 1%）。
|
||||
- **资源争抢**：若未分离，Prefill 任务可能阻塞 Decode 任务，导致延迟增加。
|
||||
|
||||
**解决方案**
|
||||
|
||||
- **分队列调度**：为 Prefill 和 Decode 分配独立的计算资源（如 GPU 计算单元与内存带宽），避免相互干扰。
|
||||
- **动态批处理**：
|
||||
- **Prefill 批处理**：合并多个请求的输入 Token，最大化并行计算效率。
|
||||
- Decode 连续批处理：动态调整生成任务，避免因短请求阻塞长生成任务
|
||||
|
||||
### (2) 内存管理的挑战
|
||||
|
||||
**挑战描述**
|
||||
|
||||
- **KV Cache 存储**：Decode 阶段需缓存大量中间状态（KV Cache），占用显存。
|
||||
- **内存碎片化**：动态请求导致显存分配不连续，降低利用率。
|
||||
|
||||
**解决方案**
|
||||
|
||||
- **分层存储优化**：
|
||||
- 高频访问的 KV Cache 保留在 GPU 显存，低频数据移至主机内存或 NVMe SSD。
|
||||
- 采用**内存池（Memory Pool）**技术，减少动态分配开销。
|
||||
- **RDMA 加速数据传输**：在分布式推理中，使用 RDMA（远程直接内存访问）减少 Prefill 与 Decode 间的数据交换延迟。
|
||||
|
||||
### (3) 低延迟与高吞吐的平衡挑战
|
||||
|
||||
**挑战描述**
|
||||
|
||||
- **TTFT（首次 Token 时间）**：用户对首次响应敏感，需快速完成 Prefill。
|
||||
- **TPOT（后续 Token 时间）**：生成阶段需稳定输出，避免卡顿。
|
||||
|
||||
**解决方案**
|
||||
|
||||
- **优先级调度**：优先处理 Prefill 任务，确保低 TTFT；Decode 任务采用公平调度，保证 TPOT 稳定。
|
||||
- **流水线并行**：将 Prefill 与 Decode 任务重叠执行，减少端到端延迟。
|
||||
|
||||
### (4) 分布式推理的通信挑战
|
||||
|
||||
**挑战描述**
|
||||
|
||||
- **跨节点同步**：在多 GPU/多机部署中，Prefill 与 Decode 可能分布在不同节点，通信开销大。
|
||||
- **AlltoAll 通信瓶颈**：传统网络架构下，跨机数据传输成为性能瓶颈。
|
||||
|
||||
**解决方案**
|
||||
|
||||
- **HPN（高性能网络）优化**：采用超低延迟（4μs）网络架构，减少跨机通信延迟。
|
||||
- **KV Cache 分区**：按 Token 位置分布 KV Cache，减少跨节点数据传输。
|
||||
|
||||
### (5) 实际部署的工程挑战
|
||||
|
||||
**挑战描述**
|
||||
|
||||
- **框架支持不足**：现有深度学习框架（如 PyTorch）未原生支持 PD 分离调度。
|
||||
- **异构硬件适配**：不同 GPU 架构（如 NVIDIA A100 vs. H100）需定制优化。
|
||||
|
||||
**解决方案**
|
||||
|
||||
- **定制化推理引擎**：如百度智能云的 PD 分离优化方案，结合 RDMA 和动态批处理提升吞吐量 20%。
|
||||
- **硬件感知优化**：针对不同 GPU 架构调整计算内核（如 Tensor Core vs. CUDA Core）。
|
||||
|
||||
## 6、未来研究方向
|
||||
|
||||
1. **更细粒度调度**：结合强化学习动态调整 Prefill/Decode 资源比例。
|
||||
2. **混合精度计算**：Prefill 阶段使用 FP16/INT8 加速，Decode 阶段保持 FP32 稳定性。
|
||||
3. **边缘端适配**：针对移动端（如 Apple M 系列芯片）优化 PD 分离策略。
|
||||
|
||||
## 7、结论
|
||||
|
||||
PD 分离通过差异化优化 Prefill 和 Decode 阶段，解决了传统推理模式下的算力浪费问题，显著提升了大模型推理的效率和用户体验。实验证明，Decode 阶段占整体推理时间的 99%，优化该阶段可带来最大的性能收益。未来，结合更先进的网络架构（如 RDMA、低延迟交换）和调度策略（如动态批处理），PD 分离将进一步推动大模型推理的高效部署。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：大模型推理 PD 分离技术：核心原理、技术优势、挑战与未来展望
|
||||
|
||||
> **原文**：[2026-08-05_大模型推理PD分离技术_核心原理_技术优势_挑战与未来展望.md](./2026-08-05_大模型推理PD分离技术_核心原理_技术优势_挑战与未来展望.md)
|
||||
> **原文链接**：https://www.eet-china.com/mp/a412848.html
|
||||
> **来源**：电子工程专辑（EET China）
|
||||
> **作者**：未知（专栏作者未署名）
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **解耦优化** — 以科普视角把 PD 分离整理为"原理—优势—挑战—未来"全景，论证针对阶段特性分别优化可消除共置导致的算力浪费。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是面向工程师与管理者的 PD 分离科普综述。想说的是：prefill 是计算密集型（复杂度 O(n²)），decode 是内存带宽密集型（复杂度 O(n)），共置时相互干扰且 decode 阶段 GPU 算力利用率仅约 1%，将两阶段分离部署并分别优化，可提升吞吐、降低 TTFT/TPOT、提高资源利用率。重要在于给出了 Prefill/Decode 的 11 维特性对比表与"资源分配—内存管理—延迟平衡—通信—工程适配"五类挑战的解决方案框架，并引用实测（decode 比 prefill 慢约 137 倍、占推理时间 99%）与百度智能云实践（HPN 4μs 网络、RDMA、吞吐提升 20%）。局限：实证数字均未注明出处，结论绝对化，未讨论适用边界与替代方案。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **特性差异是分离的根源** — prefill 计算复杂度 O(n²)、GPU 利用率近 100%；decode 复杂度 O(n)、利用率仅约 1%，瓶颈在内存带宽 `[分类: 共识]`
|
||||
2. **共置干扰与过度配置** — 混合批处理下 decode 的 P99 延迟可能增加 78% 以上，为满足 SLO 被迫过度配置资源，推高运营成本 `[分类: 共识]`
|
||||
3. **悬殊的实测对比** — 255 token 输入下 prefill 仅 0.2394s（5325 tokens/s），decode 达 32.8948s（38.76 tokens/s），慢约 137 倍、占整体推理时间 99% `[分类: 共识]`（注：数据无出处）
|
||||
4. **五大工程挑战框架** — 资源动态分配（分队列/动态批处理）、内存管理（分层存储/内存池/RDMA）、延迟平衡（优先级调度/流水线重叠）、分布式通信（HPN/AlltoAll）、框架与异构硬件适配 `[分类: 共识]`
|
||||
5. **百度智能云实践** — 低时延 HPN 集群（4μs 端到端）+ RDMA KV 传输 + 分队列调度，整体吞吐提升 20% `[分类: 共识]`（作者转述，细节不足）
|
||||
6. **未来方向** — 强化学习细粒度调度、Prefill 用 FP16/INT8 而 Decode 保持 FP32 的混合精度、边缘端适配 `[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 PD 分离是普适的"变革性技术"，未讨论其适用门槛（集群规模、网络成本）；假设文中实验数据（137 倍、78%、20%）真实可靠，但均未给出测试环境。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
数据本身颇具冲击力，但全部无出处、无法验证；"挑战—方案"对应较泛化，如"动态批处理"未说明与 PD 分离的因果；结论称"优化 Decode 阶段可带来最大的性能收益"与主张分离存在概念跳跃——分离消除的是阶段间干扰，并非直接优化 decode 计算本身。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
未讨论小规模部署、调度复杂度、chunked-prefills 等替代方案；边缘端适配等展望缺乏可行性论证；适合入门科普，不足以作为选型依据。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "速度差异：Decode 阶段比 Prefill 慢约 137 倍，占整体推理时间的 99%。"
|
||||
|
||||
> "在共置架构下，当 Prefill 和 Decode 请求混合处理时，Decode 的 P99 延迟(99%请求的延迟)可能增加 78%以上。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- Prefill/Decode 11 维特性对比表清晰，入门友好
|
||||
- 挑战—解决方案框架完整，覆盖工程落地要点
|
||||
- 引用百度智能云 HPN 网络实践，补充国内厂商视角
|
||||
|
||||
**不足**：
|
||||
- 所有量化数据无出处，可信度存疑
|
||||
- 结论绝对化，缺乏边界与替代方案讨论
|
||||
- 百度实践仅一句话结论，无方法细节
|
||||
|
||||
**适用场景**：对 PD 分离零基础的产品、研发管理者做快速科普；作为技术汇报的背景素材。
|
||||
|
||||
**关联建议**：核对原始数据出处（如 DistServe 论文、百度智能云公开分享）；对照 cr7258《PD 分离推理架构详解》获取原理、数据与实现细节。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,41 @@
|
||||
# 1.5x提升:PD分离KV cache传输的实践经验
|
||||
|
||||
> **来源**：知乎专栏「LLM推理基础与框架」
|
||||
> **作者**：PD分离传输优化 HW/YN 联合团队（ky、zzy、LCAIZJ、CZ、hyh、lrj、zpb、dfq、fjw 等）
|
||||
> **发布日期**：2026-08-05
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1946608360259577576
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
最近我们团队[1]在 vLLM 上开发了一种 KV cache 传输的 connector，实现了传输性能 __50%__[2]__的提升__，相关代码已全部开源。在过程中遇到的挑战/问题在这里进行一个分享，希望能给从事相关行业的读者带来些思考与借鉴。
|
||||
|
||||
基础知识参看上一篇：
|
||||
|
||||
## 1 问题模型分析
|
||||
|
||||
__总体需求__：LLM 的推理 PD 分离场景下，Prefill 实例要将计算好的 KV cache 传输给 Decode 实例进行后续运算，需要设计一种高效的传输机制保证推理性能。
|
||||
|
||||
|
||||
|
||||
KV cache 传输属于分布式模型数据传输的一种，所以网络传输中存在的带宽、时延、可靠性等问题都会遇到。KV cache 传输有自身特点，关注侧重点也有差异，主要看其对性能指标(TTFT/TPOT)的影响。如下大致梳理了 KV cache 传输中会遇到的问题：
|
||||
|
||||
| 类型 | 问题 | 举例 |
|
||||
| --- | --- | --- |
|
||||
| 数据 | 数据的类型 | torch.tensor、GPU/CPU tensor |
|
||||
| | 内存排布形态 | 按层排布、凑整排布 |
|
||||
| | attention 模块类型 | GQA/MLA/MHA |
|
||||
| 数据传输 | 传输通道 | TCP/RDMA |
|
||||
| | 链路数量 | FullMesh、异构传输； |
|
||||
| | 网络形态 | 跨节点、跨交换机，异构硬件 |
|
||||
| | 传输效率 | 及 |
|
||||
|
||||
## 参考
|
||||
|
||||
1. ^PD 分离传输优化 HW/YN 联合团队：ky、zzy、LCAIZJ、CZ、hyh、lrj、zpb、dfq、fjw 等
|
||||
2. ^性能参考基线为起始版本，平均提升基线为 0.5x，某些情况下可能会有一定损失
|
||||
|
||||
---
|
||||
|
||||
> **下载说明**：本文原文托管于知乎专栏，受知乎反爬虫/登录限制，本次抓取仅获得文章开头部分（目录、引言、问题模型分析小节及参考文献），正文后续章节（传输方案设计、优化手段、benchmark 数据等）未能完整获取。如需完整内容请访问原文链接登录阅读。
|
||||
@@ -0,0 +1,78 @@
|
||||
# 📊 文章摘要：1.5x提升：PD分离KV cache传输的实践经验
|
||||
|
||||
> **原文**：[2026-08-05_1.5x提升_PD分离KV_cache传输的实践经验.md](./2026-08-05_1.5x提升_PD分离KV_cache传输的实践经验.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1946608360259577576
|
||||
> **来源**：知乎专栏「LLM推理基础与框架」
|
||||
> **作者**：PD分离传输优化 HW/YN 联合团队（ky、zzy、LCAIZJ、CZ、hyh、lrj、zpb、dfq、fjw 等）
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **KV传输提效50%** — 团队在 vLLM 上自研 KV cache 传输 connector 并将传输性能提升 50%、代码全部开源，本文分享传输优化的问题分类与实践经验。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 PD 分离传输优化 HW/YN 联合团队的一线实践分享：在 vLLM 上开发了 KV cache 传输 connector，实现传输性能 50% 的平均提升（以起始版本为基线，个别情况可能有损失），相关代码已全部开源。文章核心内容是 KV cache 传输的"问题模型分析"——从数据（张量类型、内存排布形态、attention 模块类型）与数据传输（通道、链路数量、网络形态、传输效率）两个维度系统梳理影响 TTFT/TPOT 的传输问题。这是排查传输瓶颈时实用的分类清单，但本文抓取仅获得开头部分，传输方案设计、优化手段与 benchmark 数据等核心章节未能获取，完整经验需访问原文阅读。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **传输性能提升50%** — 团队开发的 KV cache 传输 connector 相比起始版本平均提升 0.5x，且代码全部开源，但"某些情况下可能会有一定损失"。`[分类: 共识]`（结论明确，细节待原文）
|
||||
2. **KV cache传输问题分类框架** — 从"数据"（类型/内存排布/attention 模块）与"数据传输"（通道/链路/网络形态/效率）两维建表归类，为 TTFT/TPOT 性能归因提供了可复用的排查清单。`[分类: 共识]`
|
||||
3. **性能指标导向的传输设计** — KV cache 传输虽属分布式模型数据传输，但关注点取决于其对 TTFT（首 Token 延迟）与 TPOT（单 Token 输出时间）的影响，设计取舍应围绕这两个指标展开。`[分类: 共识]`
|
||||
4. **工程经验开源化** — 联合团队将自研 connector 开源，反映 PD 分离生态中传输层组件正从各家私研走向社区共建。`[分类: 未探索方向]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设 PD 分离场景中 Prefill 实例向 Decode 实例传输 KV cache 是推理性能的关键瓶颈，值得专门设计传输机制；并假设开源实现能在主流框架（vLLM）与常见硬件组合下通用复现其 50% 收益。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
可获取部分只能证实"问题识别"层面，无法评估"50% 提升"的证据链——benchmark 场景、硬件基线、对比方法均未呈现；问题分类表本身完整度高，但"哪些问题对性能影响最大、如何解决"的逻辑主线全部落在未获取的正文中，论据链条严重缺失。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
"50% 提升"以起始版本为基线、且自认个别情况有损失，说明收益高度依赖原始实现的粗糙程度与具体场景；受知乎反爬限制，本文摘要仅基于文章开头部分（引言、问题模型分析、参考文献），方案设计与实测数据未获，结论外推需谨慎。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "最近我们团队在 vLLM 上开发了一种 KV cache 传输的 connector，实现了传输性能 50% 的提升，相关代码已全部开源。"
|
||||
|
||||
> "KV cache 传输属于分布式模型数据传输的一种，所以网络传输中存在的带宽、时延、可靠性等问题都会遇到。"
|
||||
|
||||
> "KV cache 传输有自身特点，关注侧重点也有差异，主要看其对性能指标(TTFT/TPOT)的影响。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 问题分类框架（数据/传输两维）对排查 KV 传输瓶颈有直接实操价值，是全文最具可迁移性的产出
|
||||
- 50% 提升与开源动作值得关注，为同类团队提供了可验证的起点
|
||||
|
||||
**不足**：
|
||||
- 本次仅获取文章开头（约全文 20%），方案设计、优化手段、benchmark 数据全部缺失，无法完整评估
|
||||
- "50% 提升"缺少可核查的测试细节，基线定义（起始版本）使收益口径偏模糊
|
||||
|
||||
**适用场景**：vLLM 上实现 PD 分离、面临 KV cache 传输调优的推理工程团队；适合作为"传输问题清单"速查与开源代码入口（需登录知乎获取完整正文）。
|
||||
|
||||
**关联建议**：结合《LLM推理成本直降60%：PD分离在大模型商业化中的关键价值》中 vLLM KV Transfer 机制与 PyNCCL/Mooncake 后端选型阅读；传输层的量化收益可对照《异构智算中心分布式PD分离推理技术的探索与实践》中广域 KV 传输挑战。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,122 @@
|
||||
# 【推理】PD分离的绝佳入门教程 —— DistServe
|
||||
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：Zoe Lee
|
||||
> **发布日期**：2026-08-05
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/19666783423
|
||||
|
||||
---
|
||||
|
||||
作为推理服务中PD分离的技术的经典方法之一，DistServe（OSDI 2024）无疑为广大学者提供了一份绝佳的入门教程。该工作详细分析了PD分离的技术动机、提出了通俗易懂的PD分离算法思想、并充分开源了代码，让每一个想了解PD分离技术的人都能够"亲自把玩"。
|
||||
|
||||
本文为在精度论文并部署代码进行多组实验后整理的"玩后感"，会从PD分离技术动机、DistServe项目算法思想、code实现以及个人理解等方面展开介绍。本人初学，望看到本文的大佬们多多指点交流～
|
||||
|
||||
## 1. PD分离技术动机
|
||||
|
||||
我们知道一条请求在推理的过程中需要经过两个步骤：第一步，根据输入序列的内容生成第一个token，该过程称为Prefill；第二步，根据输入序列以及之前已经生成的token生成下一个token，该过程称为Decoding。随着"以存代算"的KV-Cache技术的引入，大多推理过程避免了在Attention结构的重复计算，这导致Prefill与Decoding在执行时存在着较大的差异。
|
||||
|
||||
为什么Prefill和Decoding存在较大的差异？
|
||||
|
||||
首先我们从计算过程上去直观理解两个步骤的区别。在Prefill阶段，模型输入prompt的所有token，经过一步计算后得到第一个输出，与此同时每个token在计算时产生的KV-Cache被储存下来，而在Decoding阶段，每个新token的计算都会涉及到KV-Cache的读取与存储，而计算量相比Prefill而言被大大降低了，取而代之的是高频的存取操作带来的压力，这便是KV-Cache技术带来的Prefill和Decoding的差异化。
|
||||
|
||||
这种差异是否会导致放在一个batch中处理会相互拖后腿？
|
||||
|
||||
论文通过实验给出了肯定的答案。下图表示在全部是decoding状态的batch中加入一个做prefill的请求导致的延迟变化。蓝色线条的起点表示只处理一条prefill的延迟，蓝色后面的点与起点的差值都可以看做添加decoding状态的请求对该prefill状态的请求带来的延迟危害，而蓝色与橙色对应节点的差值可以看作添加的一个prefill状态的请求对decoding状态的请求batch带来的延迟危害。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
综合分析，两阶段混合推理带来的主要问题如下：
|
||||
|
||||
1. 调度低效：在相同GPU上进行不同状态的调度会造成decoding等待prefill的现象，并且GPU在进行decoding会导致资源低利用率；
|
||||
2. 资源和并行策略的耦合：两阶段的差异对于资源和并行策略的需求不同，相同GPU上部署不可避免的会导致两阶段资源和并行策略的共享。
|
||||
|
||||
至此，PD分离就成为了一种最为直接的解决思想。
|
||||
|
||||
## 2. P/D阶段特性分析
|
||||
|
||||
在正式提出算法前，论文对于P和D阶段的batch策略和并行方案进行了分析。对于batch策略，论文通过以下实验对比了两阶段的不同特点：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
Prefill阶段并不是batch size越大吞吐越大，吞吐随batch size的变化取决于输入文本的长度，因此在设置batch size时要考虑输入长度。而增加batch size对于Decoding阶段是一个避免低吞吐的好方法。
|
||||
|
||||
对于并行方式，为了分析Prefill阶段对于并行策略的偏好，论文首先利用M/D/1排队模型对请求队列进行了建模，进而TTFT就可以用请求在系统内的平均等待时间表示，加入Pipeline并行和Tensor并行的影响后，TTFT建模结果分别如下：
|
||||
|
||||
```
|
||||
PP=2: D + (R*D^2) / (4*(2 - R*D))
|
||||
TP=2: D/K + (R*D^2) / (2*K*(K - R*D))
|
||||
```
|
||||
|
||||
其中D为请求的执行时间，R为到达率，K为TP带来的影响系数，由于通信代价，通常 1<K<2 。当到达率R很小时，第一项执行时间为主要作用，这时TP的效果会更好，当R增加时第二项其主要作用，PP的效果则更好，结合实验结果看更清楚：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
这一实验结论对根据不同场景下设置并行模式起到了参考作用。而Decoding阶段的并行模式分析同理，TP可以降低延迟，但是过大的TP会引入过量通信，延迟降低的优势也就不再明显，PP虽不影响单个请求的执行时间，但可以加大吞吐。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
不过对于这一部分的分析，本人也做了粗略的实验比较了一下两个阶段TP与PP的影响，发现对于给定P/D两阶段的卡数的情况下似乎并行策略的影响不大～但是论文这部分的分析确实具有一定的启发性。
|
||||
|
||||
接下来正式介绍DistServe项目的算法思想。整个项目分成两大部分：设计并行模式、执行分离式推理。
|
||||
|
||||
### 3.1 并行模式设计
|
||||
|
||||
论文的附录给出了对Prefill和Decode阶段的耗时建模方法，而在实验中，Prefill延迟模型为：
|
||||
|
||||
```
|
||||
A + B*bs*l_in + C*sum_{i=1}^{bs} l_in_{i}^2
|
||||
```
|
||||
|
||||
Decoding延迟模型为：
|
||||
|
||||
```
|
||||
A + B*bs*l_in + C*bs
|
||||
```
|
||||
|
||||
其中 bs 为batch size， l_in 为输入的平均长度， l_in_{i}^2 表示第 i 个batch的请求平均输入长度的平方，通过采样实际执行时间，则可作为训练数据来分别拟合两个延迟模型的参数 A、B、C 。
|
||||
|
||||
总体寻优的思想也是比较清晰的。首先对不同并行策略下的耗时建立线性模型，再采集多组样本，对不同并行策略的线性模型进行拟合。值得一题的是，论文对Prefill和Decoding的耗时分别建立不同的模型，特别对于Decoding阶段又进一步区分了大Batch size和小Batch size两种场景下的建模。这或许可归因于第二节中对于Decoding阶段的分析，由于Decoding阶段的Batch size影响较大，区分建模能保证更高的精度。
|
||||
|
||||
模型建成后的寻优准则则是该论文与其他论文方法不同的地方。DistServe全篇更加强调对于TTFT和TPOT分别达到SLO的目标，因此寻优算法也遵从这一准则。算法如下：
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
前6行在做的就是遍历所有可能的并行模式，第7-13行开始利用拟合好的模型预测效果，筛选最佳方案，筛选标准是：（1）. 在Prefill和Decoding均满足SLO，（2）. 并行方案对应的最大支撑到达率大于输入到达率，对于每个并行方案的支撑到达率则采用二分查找法确定。最后在所有满足条件的方案中，找到需要GPU数量最少的方案输出。
|
||||
|
||||
论文同样给出了跨机的方法。跨机面临着缺少NVLink的高速连接，这时并行策略的性能则受制于机间通信带宽。不同于其他PD分离的方法，为了避免KV-Cache传输以及TP走机间通信，该论文在设置并行模式时，需要限制相同模型层的P和D需要在同一节点。示意图如下：
|
||||
|
||||
|
||||
|
||||
### 3.2 分离式推理
|
||||
|
||||
确定好并行模式后，就可以开始部署推理引擎了。
|
||||
|
||||
|
||||
|
||||
截取自论文
|
||||
|
||||
DistServe的整体逻辑遵从"生产者-消费者"模式，总体Engine负责管理Prefill、Decoding引擎，两个引擎分别实现了各自的调度器，Prefill引擎为生产者，Decoding引擎为消费者，到达的请求会首先分配到Prefill调度器的等待队列，一旦当前Prefill实例的资源满足该请求所需，就会被调度到Prefill引擎执行该阶段的计算，执行完Prefill的请求会被存储到一个中转队列中，该队列中的请求会等待Decoding调度器的调度，一旦Decoding调度器检测到中转队列请求所需资源能够满足，就会被调度到Decoding引擎，进而执行Decoding阶段的计算。
|
||||
|
||||
## 4. Code结构
|
||||
|
||||
整个DistServe项目的代码可以分成两个部分。一个部分是项目基座，由C++和CUDA语言编写，用于定义推理服务中涉及到的模型计算、通信、资源开辟释放等，该项目名为SwiftTransformer，主要包含了对Transformer架构模型的优化算子等。第二部分则是论文重点内容所涉及的调度层，主要由Python编写。而在真正执行服务时，还有一层与用户交互的api层，同样由Python编写。
|
||||
|
||||
|
||||
|
||||
代码结构说明
|
||||
|
||||
## 5. 总结与讨论
|
||||
|
||||
该项目作为PD分离的经典工作，非常适合刚接触该技术的初学者进行了解和学习。DistServe的实践简单、没有涉及过多的其他优化技巧，适合作为验证PD分离这一单一技术性能的工作，代码可读性比较高。然而也是因为实践方式较为简单，特别是对于跨机的方案限制比较多。
|
||||
|
||||
另外，PD分离技术的使用场景也有相应的限制，例如至少需要两张GPU，因此考虑PD分离技术的场景通常需有相对充足的GPU资源，才能让该技术发挥出更大的空间。
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：【推理】PD分离的绝佳入门教程 —— DistServe
|
||||
|
||||
> **原文**：[2026-08-05_推理_PD分离的绝佳入门教程_DistServe.md](./2026-08-05_推理_PD分离的绝佳入门教程_DistServe.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/19666783423
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：Zoe Lee
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **精读范本** — 以 DistServe（OSDI 2024）为样本讲透 PD 分离的动机、建模与寻优方法，并附代码复现的一手体会。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
作者精读 DistServe 论文并部署代码实验后整理的"玩后感"：从混合 batch 中 prefill 与 decoding 相互拖累的实验证据出发说明 PD 分离动机；用 M/D/1 排队模型推导并行策略偏好（到达率低时 TP 更优、高时 PP 更优）；讲解对 Prefill/Decode 分别建立延迟模型、以"满足 TTFT/TPOT 双 SLO + 支撑到达率 + GPU 数最少"为准则的寻优算法，以及跨机部署限制（相同模型层的 P/D 必须同节点）。价值在于把论文方法论讲得通俗透彻，且作者亲自复现并报告了与论文结论存在张力的个人观察。局限是作者自认初学，跨机细节阐述有限。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **PD 分离动机有实验证据** — 混合 batch 中新增一个 prefill 请求会给 decoding 批处理带来显著的延迟危害（论文实验图），由此引出调度低效与资源/并行策略耦合两大问题 `[分类: 共识]`
|
||||
2. **batch 策略差异** — Prefill 吞吐随 batch size 的变化取决于输入文本长度，并非越大越好；增加 batch size 是 Decode 阶段避免低吞吐的好方法 `[分类: 共识]`
|
||||
3. **并行模式建模** — 用 M/D/1 排队模型推导 TTFT：到达率 R 小时 TP 效果更好，R 增加时 PP 更好；Decode 侧过大的 TP 会引入过量通信使延迟优势消失 `[分类: 范式突破]`
|
||||
4. **SLO 驱动的寻优算法** — 对 P/D 分别拟合延迟线性模型（Prefill 含输入长度二次项），遍历并行模式，筛选同时满足 TTFT/TPOT SLO 且支撑到达率达标的方案，取 GPU 数最少者 `[分类: 范式突破]`
|
||||
5. **跨机约束** — 为避免 KV Cache 跨机传输与 TP 走机间通信，设置并行模式时限制相同模型层的 P 和 D 在同一节点 `[分类: 未探索]`
|
||||
6. **生产者-消费者实现** — 总体 Engine 管理 Prefill 与 Decoding 两个引擎及各自调度器，prefill 产出经中转队列等待 Decoding 调度器消费；代码分 SwiftTransformer（C++/CUDA）基座与 Python 调度层两部分 `[分类: 共识]`
|
||||
7. **复现体会与论文结论的张力** — 作者粗略实验发现给定 P/D 卡数下并行策略的影响似乎不大，与论文强调并行模式寻优的价值形成对照（个人观察，尚需严格验证）`[分类: 争议]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者熟悉 Transformer 推理与排队论基础；DistServe 的目标函数假设 TTFT/TPOT SLO 由用户显式给定，寻优结论依赖延迟模型对真实系统的拟合精度。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
动机实验、延迟模型与寻优准则均忠实转述论文，并附作者部署代码的一手体会，论据扎实；作者对"并行策略影响不大"的观察明确标注为粗略实验，态度严谨，未以个人观察冒充论文结论。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者明确指出 PD 分离至少需要两张 GPU、跨机方案限制较多，适合 GPU 资源充足的场景；论文方法面向"以 SLO 为中心"的在线服务目标，对离线批处理等非 SLO 场景不适用，且 DistServe 实现未涉及按层传输等后续优化技巧。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "在相同GPU上进行不同状态的调度会造成decoding等待prefill的现象，并且GPU在进行decoding会导致资源低利用率"
|
||||
|
||||
> "Prefill阶段并不是batch size越大吞吐越大，吞吐随batch size的变化取决于输入文本的长度，因此在设置batch size时要考虑输入长度。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 把 DistServe 的动机实验、M/D/1 建模、寻优准则讲得透彻清晰，入门友好
|
||||
- 有真实部署与复现的一手体会，并诚实报告与论文结论的张力
|
||||
- 代码结构拆解（SwiftTransformer + Python 调度层）便于读者自行"把玩"
|
||||
|
||||
**不足**：
|
||||
- 作者自认初学，跨机方案细节与性能数字讨论有限
|
||||
- 个人复现实验未给出具体数据，观察结论有待验证
|
||||
|
||||
**适用场景**：初次接触 PD 分离的工程师与学生作为入门导读；准备精读 DistServe 论文与复现其代码的读者。
|
||||
|
||||
**关联建议**：对照阅读 DistServe 论文原文与 GitHub 仓库（LLMServe/DistServe）；与 akaihaoshuai 的实测结论（P/D 配比、cache 调度为核心）互相印证；进阶阅读 Mooncake（KVCache 中心化调度）与 NVIDIA Dynamo。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,580 @@
|
||||
# LLM关于PD分离的最新实测
|
||||
|
||||
> **来源**：知乎
|
||||
> **作者**：akaihaoshuai
|
||||
> **发布日期**：2025-06-22
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1919794916504114120
|
||||
|
||||
---
|
||||
|
||||
LLM的PD分离在一年前就有一定的了解了，可以参考文章：[akaihaoshuai：LLM推理加速调研](https://zhuanlan.zhihu.com/p/699776257)中提到的DistServe多卡解耦prefill和decode优化耗时。后来也出现了Mooncake和deepseek的PD分离方案。根据prefill的计算密集型和decode的传输密集型特征进行解偶，可以使得效率最大化，
|
||||
现在vllm/sglang中都已经集成了一些PD分离的代码，最近正好有机会，深入了解并测试一下实际效果。
|
||||
|
||||
## 为什么要PD分离？
|
||||
首先要了解LLM的推理可以分为两个阶段
|
||||
- **Prefilling：**对输入的prompt，一次计算全部的kvcache，输出首token，此时的耗时为TTFT，通常在几百ms。
|
||||
- **Decoding：**根据计算好的kvcache，迭代式的生成每一个token。耗时为TBT，通常在10～20ms。
|
||||
画出LLM的推理过程示意图，可以看出，当prefilling和decoding在同一个batch中时，Prefilling操作会严重影响Decoding结果的输出效率。
|
||||
|
||||
|
||||
如果是PD分离架构
|
||||
|
||||
|
||||
从上图可以看出，PD分离可以提高decoding部分的效率。但是从TP2变成1P1D，prefilling的卡减少，大bs、长输入时会导致TTFT变长。
|
||||
|
||||
另外因为prefill的计算量大，decoder阶段的传输量大，因此PD分离可以对两个阶段使用不同类型的显卡，最大化性价比。
|
||||
|
||||
|
||||
因为相比A系列和H系列的卡，4090的算力可能在30%~50%左右，但是带宽只有10%不到，所以非常适合用于prefill阶段计算，性价比很高。
|
||||
|
||||
## 怎么进行PD分离？
|
||||
|
||||
> [PD分离-XpYd系统服务化](https://zhuanlan.zhihu.com/p/30619735151)
|
||||
[vLLM PD分离方案浅析](https://zhuanlan.zhihu.com/p/1889243870430201414)
|
||||
当前的server框架（比如[vllm](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm)、sglang）通常用于单机server。XpYd就是在这个基础上，再封装一层server代码，根据参数启动多个独立的server，分别标为prefill server和decoder server，管理不同server之间的cache调度。
|
||||
相同的vllm server怎么分为prefill server和decoder server呢？其实在启动参数上并没多大区别，启动两个server服务，所有的request首先发送到prefill server，并将max_tokens设为1。处理完成后将相同的request再输入decoder server，获取输出即可。那么这两个server自然就会一个只处理prefilling、一个只处理decoding了。
|
||||
|
||||
```
|
||||
# prefill server
|
||||
CUDA_VISIBLE_DEVICES='0' python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model $MODEL_NAME \
|
||||
--port 8100 \
|
||||
--trust-remote-code \
|
||||
--enforce-eager \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"SharedStorageConnector","kv_role":"kv_both","kv_connector_extra_config": {"shared_storage_path": "local_storage"}}' &
|
||||
|
||||
# decoder server
|
||||
CUDA_VISIBLE_DEVICES='1' python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model $MODEL_NAME \
|
||||
--port 8200 \
|
||||
--trust-remote-code \
|
||||
--enforce-eager \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"SharedStorageConnector","kv_role":"kv_both","kv_connector_extra_config": {"shared_storage_path": "local_storage"}}' &
|
||||
|
||||
# proxy server
|
||||
python3 disagg_pd_proxy_server.py &
|
||||
```
|
||||
其中disagg_pd_proxy_server.py可以参考代码：[https://github.com/vllm-project/vllm/blob/main/examples/online_serving/disaggregated_serving/disagg_proxy_demo.py](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm/blob/main/examples/online_serving/disaggregated_serving/disagg_proxy_demo.py)
|
||||
核心代码如下：
|
||||
|
||||
```
|
||||
@app.route('/v1/completions', methods=['POST'])
|
||||
async def handle_request():
|
||||
try:
|
||||
original_request_data = await request.get_json()
|
||||
prefill_request = original_request_data.copy()
|
||||
|
||||
# change max_tokens = 1 to let it only do prefill
|
||||
prefill_request['max_tokens'] = 1
|
||||
|
||||
# finish prefill
|
||||
async for _ in forward_request('http://localhost:8100/v1/completions',
|
||||
prefill_request):
|
||||
continue
|
||||
|
||||
# return decode
|
||||
generator = forward_request('http://localhost:8200/v1/completions',
|
||||
original_request_data)
|
||||
response = await make_response(generator)
|
||||
response.timeout = None
|
||||
|
||||
return response
|
||||
|
||||
except Exception as e:
|
||||
print("Error occurred in disagg prefill proxy server")
|
||||
```
|
||||
当然，只是上面的简单修改还不够，vllm中的代码也要修改，要将prefill server中计算的kvcache发送到decoder server。
|
||||
对于vllm server来说，每次推理前，检查当前输入的token_ids有没有处理过的kv cache缓存，如果有，则可以直接复用，即decoding处理。如果没有，则进行prefilling处理，并将kv cache保存，保存的key需要和token_ids相关。
|
||||
[https://github.com/vllm-project/vllm/blob/main/vllm/v1/worker/gpu_model_runner.py](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm/blob/main/vllm/v1/worker/gpu_model_runner.py)
|
||||
|
||||
|
||||
基本的PD分离逻辑基本介绍完了，当初看的时候感觉是个很复杂的工程，现在用来也没有多麻烦（当然是vllm和多位大神代码集成的好，而且实际在用的话还需要很多的优化）
|
||||
|
||||
到这里大家就知道了，**PD分离的核心其实在于cache的调度。**
|
||||
|
||||
## [vllm](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm)的PD分离
|
||||
[vllm](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm)0.9.1版本，kv cache调度器支持的KVconnector类型如下。
|
||||
|
||||
|
||||
下面只介绍v1版本的几种PD分离
|
||||
|
||||
### SharedStorageConnector
|
||||
[https://github.com/vllm-project/vllm/blob/main/vllm/distributed/kv_transfer/kv_connector/v1/shared_storage_connector.py](https://link.zhihu.com/?target=https%3A//github.com/vllm-project/vllm/blob/main/vllm/distributed/kv_transfer/kv_connector/v1/shared_storage_connector.py)
|
||||
从代码中可以看出主要包含save_kv_layer和start_load_kv两个函数。
|
||||
|
||||
|
||||
- prefill阶段，会将计算的kvcache通过save_kv_layer函数保存到本地文件夹中。
|
||||
- decoder阶段，会通过start_load_kv函数从本地文件夹中读取kvcache。
|
||||
|
||||
测试发现，代码中目前只支持1P1D，且prefill_tp_size=decoder_tp_size=1。
|
||||
若要支持prefill_tp_size != decoder_tp_size，则需要修改代码：在save_kv_layer中增加rank标记，保证多rank同时保存时不互相覆盖。在start_load_kv函数中增加读取多个rank读取cache，并根据当前server的tp数量进行cache拆分的逻辑。
|
||||
**分析：**从代码中可以看出，在prefill和decoder之间有文件保存和读取操作，会大幅影响结果耗时。
|
||||
|
||||
### P2pNcclConnector
|
||||
从代码中可以看出，P2pNcclConnector相比于SharedStorageConnector，就是把safetensors save/load操作换成了nccl的send和reciver操作。
|
||||
|
||||
|
||||
NCCL（**NVIDIA Collective Communications Library**）是 NVIDIA 提供的一个用于多 GPU 和多节点之间高效通信的库。它主要用于深度学习和高性能计算（HPC），支持常见的集合通信操作，如 `AllReduce`、`Broadcast`、`Reduce`、`Scatter` 和 `Gather` 等。
|
||||
- **特点**：
|
||||
- 高性能：针对 NVIDIA GPU 进行优化，支持 PCIe、NVLink 和 InfiniBand。
|
||||
- 多节点扩展：支持跨多个节点的 GPU 通信。
|
||||
- 支持多种数据类型和通信模式（LL、LL128、SIMPLE 协议等）。
|
||||
- 可配置参数（如 `NCCL_PROTO`, `NCCL_ALGO`, `NCCL_MAX_NCHANNELS`）以优化性能。
|
||||
|
||||
使用NCCl在GPU之间直接处理数据，大幅降低了数据传输耗时。
|
||||
|
||||
|
||||
NCCL 负责 GPU 间的数据传输，而 ZMQ 仅用于控制信道（metadata 交换）。两者配合使用，但并不直接通过 ZMQ 传输张量数据。
|
||||
|
||||
```
|
||||
# 在 P2pNcclEngine 中：
|
||||
self.nccl = NCCLLibrary(library_path) # 初始化 NCCL 库
|
||||
self._create_connect(remote_address) # 使用 ZMQ 发起连接请求，并初始化 NCCL Comm
|
||||
self._send(comm, tensor, dst, stream) # 实际调用 ncclSend 进行 GPU 数据传输
|
||||
```
|
||||
|
||||
### LMCacheConnectorV1——[LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)
|
||||
|
||||
> [https://github.com/LMCache/LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)
|
||||
封装了一层[LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)调用逻辑。
|
||||
|
||||
|
||||
[LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)是一个针对vllm的cache复用框架。**主要优点**
|
||||
- 减少推理时间：通过重用缓存的 KV 张量消除冗余计算（通过CPU以及磁盘缓存，可以保存更多的cache）
|
||||
- 更高的吞吐量：处理处理过的文本，节省 GPU 周期
|
||||
- 内存效率：分层存储系统优化 GPU、CPU 和磁盘的内存使用率
|
||||
- 非前缀缓存：支持缓存任何文本片段，而不仅仅是前缀（decoding过程的cache也可以全部保存）
|
||||
- 框架集成：与 vLLM 服务堆栈无缝集成（推理直接调用vllm，保存vllm的cache）
|
||||
|
||||
入口[https://github.com/LMCache/LMCache/tree/dev/lmcache/integration/vllm/vllm_v1_adapter.py](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache/tree/dev/lmcache/integration/vllm/vllm_v1_adapter.py)的LMCacheConnectorV1Impl类。
|
||||
根据类型，选择创建SCHEDULER还是SERVER WORKER
|
||||
|
||||
|
||||
|
||||
在vllm中的调用过程
|
||||
|
||||
|
||||
|
||||
prefill阶段调用流程：save_kv_layer -> self._lmcache_engine.save_kv_layer -> self.lmcache_engine.store_layer
|
||||
|
||||
|
||||
decoder阶段调用流程：start_load_kv -> self._lmcache_engine.start_load_kv -> self.lmcache_engine.retrieve_layer
|
||||
|
||||
|
||||
|
||||
可以看出storage_manager是存储管理。gpu_connector是负责数据传输。
|
||||
|
||||
StorageManager包含storage_backends，主要支持NixlBackend、LocalCPUBackend、LocalDiskBackend和RemoteBackend等类。其中分别是通过本地GPU、本地CPU、本地disk和跨结点传输数据。（Nixl是nvidia开源的gpu传输技术，后面会单独开一节详细介绍）跨结点传输包含了mooncake实现。
|
||||
|
||||
|
||||
|
||||
vllm_Connector支持下面几种，外部支持调用的是最后三种。
|
||||
|
||||
|
||||
|
||||
Connector总结对比
|
||||
|
||||
|
||||
|
||||
KV 缓存请求流程和数据处理管道
|
||||
|
||||
|
||||
[LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)还有一个enable_blending功能，可以支持kvcache的位置编码解耦，从而能够复用非前缀缓存，进一步提高推理效率。
|
||||
|
||||
|
||||
|
||||
### NixlConnector——[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)
|
||||
NixlConnector中使用了nvidia-smi的[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)库进行通信，其他用法和P2pNcclConnector没有什么区别。
|
||||
|
||||
|
||||
[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)的具体内容以及[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)和nccl的比较放到下面的[dynamo](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/dynamo)一节中详细讲解。
|
||||
|
||||
## sglang的PD分离
|
||||
|
||||
> [Deploying DeepSeek with PD Disaggregation and Large-scale Expert Parallelism on 96 H100 GPUs](https://link.zhihu.com/?target=https%3A//lmsys.org/blog/2025-05-05-large-scale-ep/%23prefill-and-decode-disaggregation)
|
||||
[https://github.com/sgl-project/sglang/issues/4655](https://link.zhihu.com/?target=https%3A//github.com/sgl-project/sglang/issues/4655)
|
||||
[https://docs.sglang.ai/backend/pd_disaggregation.html](https://link.zhihu.com/?target=https%3A//docs.sglang.ai/backend/pd_disaggregation.html)
|
||||
收到输入请求后，工作流程如下：
|
||||
|
||||
1. 预填充服务器和解码服务器通过握手配对，分别建立本地发送方和接收方。
|
||||
|
||||
2. 解码服务器预先分配 KV 缓存，向预填充服务器发出信号，开始模型前向传递并计算 KV 缓存。
|
||||
|
||||
3. 一旦计算完成，数据就会传输到解码服务器，由其处理迭代令牌生成。
|
||||
|
||||
|
||||
|
||||
### github代码详解
|
||||
代码框架如下
|
||||
|
||||
|
||||
|
||||
Engine中创建Scheduler。
|
||||
|
||||
|
||||
PrefillBootstrapQueue和DecodePreallocQueue中都会创建kv_manager对kv cahce进行管理
|
||||
|
||||
|
||||
支持mooncake和nixl后端。
|
||||
|
||||
|
||||
|
||||
|
||||
状态值
|
||||
|
||||
|
||||
|
||||
调用/v1/chat/completions接口时，会走到generate接口 --> _global_state.tokenizer_manager.generate_request() --> self._send_one_request() --> self.send_to_scheduler.send_pyobj()，将request发送到两个server的scheduler。
|
||||
|
||||
|
||||
|
||||
### prefill server处理流程
|
||||
|
||||
|
||||
1、在schedule中调用handle_generate_request()->_add_request_to_queue()处理新的request。
|
||||
2、在_add_request_to_queue()中调用调用PrefillBootstrapQueue().add()将 request添加到queue中。并添加到schedule.waiting_queue中。
|
||||
|
||||
|
||||
3、后台运行的event_loop_normal_disagg_prefill()检测到queue中包含未处理的req，进行处理。
|
||||
|
||||
|
||||
4、在process_batch_result_disagg_prefill()中通过disagg_kv_sender发送处理过的kv cache。
|
||||
|
||||
|
||||
|
||||
### decode server处理流程
|
||||
|
||||
|
||||
1、在schedule中调用handle_generate_request()->_add_request_to_queue()处理新收到的request。
|
||||
2、在_add_request_to_queue()中调用调用DecodePreallocQueue().add()将 request添加到queue中。并添加到schedule.waiting_queue中。
|
||||
3、后台运行的event_loop_overlap_disagg_decode() --> process_decode_queue() 检测到queue中包含未处理的req，进行处理。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
其中MooncakeKVManager使用的[Mooncake](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/Mooncake)开源项目，NixlKVManager使用的[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)开源项目
|
||||
|
||||
## [Mooncake](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/Mooncake)
|
||||
|
||||
> [Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving](https://link.zhihu.com/?target=https%3A//arxiv.org/abs/2407.00079)
|
||||
[https://github.com/kvcache-ai/Mooncake](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/Mooncake)
|
||||
[Mooncake 最新进展：SGLang 和 LMCache 基于 Mooncake 实现高效 PD 分离框架](https://zhuanlan.zhihu.com/p/1906034699358437813)
|
||||
[Mooncake (1): 在月之暗面做月饼，Kimi 以 KVCache 为中心的分离式推理架构](https://zhuanlan.zhihu.com/p/705754254)
|
||||
[Mooncake阅读笔记：深入学习以Cache为中心的调度思想，谱写LLM服务降本增效新篇章](https://zhuanlan.zhihu.com/p/706097807)
|
||||
[从MoonCake看大模型推理的PD分离，太快会扯到蛋吗？](https://zhuanlan.zhihu.com/p/8056351077)
|
||||
论文介绍了Mooncake，这是一个为LLM服务设计的KVCache中心分布式架构，旨在高效处理高并发请求并满足SLO。Mooncake通过分离预填充和解码集群，利用GPU集群中的闲置资源构建分布式KVCache，并采用KVCache中心调度器来优化请求调度。
|
||||
|
||||
|
||||
|
||||
### arxiv
|
||||
Mooncake 采用分解式架构，不仅将预填充节点与解码节点分离，还将 GPU 集群的 CPU、DRAM、SSD 和 RDMA 资源分组，以实现分解式 KVCache。这种分解式缓存能够充分利用未充分利用的资源，提供充足的缓存容量和传输带宽，从而实现高效的近 GPU 前缀缓存，而无需额外成本。
|
||||
|
||||
|
||||
|
||||
论文详细介绍了Mooncake架构的设计，该架构以KVCache为中心，通过分离预填充和解码集群，并利用GPU集群中未充分利用的CPU、DRAM和SSD资源实现KVCache的分布式缓存。具体方法如下：
|
||||
- **分离预填充和解码集群**：预填充阶段主要处理输入令牌的并行计算，而解码阶段则逐个处理输出令牌。通过分离这两个阶段，可以针对它们不同的计算特性进行优化。
|
||||
- **分布式KVCache设计**：利用GPU集群中的闲置资源构建分布式KVCache，提高缓存容量和传输带宽，实现高效的近GPU前缀缓存。
|
||||
- **KVCache中心调度器**：核心是KVCache中心调度器（Conductor），它负责根据当前KVCache分布和工作负载调度请求，并根据需要复制或交换KVCache块。
|
||||
- **请求处理流程**：对于每个请求，Conductor选择一对预填充和解码实例，并按照以下步骤调度请求：
|
||||
|
||||
|
||||
- **KVCache重用**：预填充实例根据请求的前缀缓存块ID从远程CPU内存加载KVCache到GPU内存，以启动请求处理。
|
||||
- **增量预填充**：预填充实例完成预填充阶段，并将新生成的增量KVCache存储回CPU内存。如果未缓存的输入令牌数量超过一定阈值，则将预填充阶段拆分为多个块，并以流水线方式执行。
|
||||
- **KVCache传输**：使用基于RDMA的Messenger服务在节点间管理和传输这些缓存，将模型各层生成的KVCache流式传输到目标解码节点的CPU内存，减少等待时间。
|
||||
- **解码**：解码节点在接收到所有KVCache后，将请求加入下一批次进行连续批处理。Conductor根据当前负载预选解码节点，以确保不违反TBT SLO。
|
||||
- **缓存感知调度**：在预填充阶段，调度器会根据请求的前缀缓存匹配长度和实例负载选择预填充实例，以平衡缓存重用和负载均衡。
|
||||
- **缓存负载均衡**：通过自动复制热点KVCache块，将它们分布到多个机器上，以避免缓存获取拥塞。
|
||||
|
||||
统计了线上的输入和输出：平均输入长度为 7,590 个 token，平均输出长度为 182 个 token。
|
||||
比较了三种缓存策略：LRU、LFU 和 LengthAwareCache。
|
||||
|
||||
|
||||
将缓存容量从 1,000 个块增加到 50,000 个块，缓存命中率会从 30% 提升到 50%。继续增加则没有明显改善。
|
||||
|
||||
- **CPP（chunked pipeline parallelism）**
|
||||
输入越来越长，需要做chunk_prefill，继续提升：对于每个请求，其输入令牌会被划分为多个块，每个块的长度不超过prefill_chunk。同一请求的不同块可以由不同的节点同时处理，从而实现并行处理并减少 TTFT。
|
||||
|
||||
- **Layer-wise Prefill**
|
||||
理论上，如果一个请求的 KVCache 大小为S，处理时间为T，则其占用成本为S∗T。如果在分块预填充中，将请求分块处理，并将每个分块的处理与其他解码请求内联，则T会增加，导致占用成本更大。
|
||||
|
||||
|
||||
不同请求长度的 KVCache 存储延迟
|
||||
|
||||
- **Prefill Global Scheduling**
|
||||
在 Mooncake 中，预填充实例的选择不仅考虑负载，还考虑前缀缓存命中长度以及可重用 KVCache 块的分布。
|
||||
对于每个新请求，其输入令牌会被分成多个块，并为每个块计算一个哈希键。这涉及生成一个块中令牌的哈希键，该哈希键与前一个块的哈希键（如果可用）连接。然后将请求的块键与每个预填充实例的缓存键逐一进行比较，以确定前缀匹配长度 (prefix_len)。
|
||||
利用这些匹配信息，Conductor 会根据请求长度和prefix_len（因实例而异）估算相应的执行时间。然后，它会添加该请求的预计等待时间，以获得该实例的 TTFT。最后，Conductor 将请求分配给 TTFT 最短的实例，并相应地更新该实例的缓存和队列时间。
|
||||
|
||||
- **Cache Load Balancing**
|
||||
每台预填服务器都管理着自己的一组本地前缀缓存。这些缓存的使用频率差异很大。
|
||||
解决此 KVCache 调度问题的一个简单解决方案是收集每个块的全局使用情况，使用预测模型预测其未来使用情况，并据此做出调度决策。
|
||||
如果预估的额外预填充时间短于传输时间，则指挥者会将缓存位置和请求转发到备用实例。此实例会主动从持有者处检索 KVCache 并将其存储在本地。更重要的是，我们倾向于在最佳远程前缀匹配长度不大于当前本地可重用前缀乘以阈值1这两种策略不仅可以减少请求的预填充时间，还可以促进热点缓存的自动复制。
|
||||
|
||||
|
||||
|
||||
- **Early Rejection**
|
||||
预填充或解码实例的负载并不能准确反映系统实际处理的请求数量。这种差异是由于单个请求的预填充和解码实例调度之间存在时间差造成的。
|
||||
为了解决这个问题，很自然地需要将解码实例的负载评估提前到预填充阶段开始之前。请求到达后，Conductor 会根据预填充池和解码池中较大的负载来评估是否接受该请求。早期拒绝 (Early Rejection) 可以显著减少因被拒绝请求而导致的无效计算，并增强负载均衡。
|
||||
|
||||
|
||||
经过进一步研究，我们发现这种负载波动问题的根源在于预测解码负载与实际执行之间的时间滞后。基于当前解码负载的调度本质上存在延迟。
|
||||
|
||||
|
||||
|
||||
- **效果测试**
|
||||
每个node配置8 块 NVIDIA-A800-SXM4-80GB GPU，通过 NVLINK 连接；配备 RDMA 网卡，节点间互联带宽最高可达 800Gbps。
|
||||
|
||||
|
||||
Mooncake-[3P+1D] 的吞吐量分别比 vLLM-[4M] 提高了 20% 和 40%，同时满足服务水平目标 (SLO)。
|
||||
尽管 Mooncake-[2P+2D] 拥有较低的 TBT 延迟，但在 TTFT 指标上的表现不如 Mooncake-[3P+1D] 和 vLLM-[4M]。
|
||||
|
||||
### github代码框架
|
||||
Mooncake 由三个主要组件组成，它们协同工作以实现高效的分解 LLM 服务：Transfer Engine、Mooncake Store和P2P Store
|
||||
|
||||
- **Transfer Engine**
|
||||
它通过调度程序架构支持 TCP、RDMA （InfiniBand/RoCEv2）、NVLink 和 NVMe-oF 协议。提供跨多个协议和存储设备的统一、高性能数据传输。
|
||||
|
||||
1. **多协议支持**：根据拓扑和可用性自动选择协议
|
||||
|
||||
2. **带宽聚合**：利用多个 RDMA NIC 设备来提高吞吐量
|
||||
|
||||
3. **拓扑感知路由**：根据 NUMA 关联性和设备位置选择最佳传输路径
|
||||
|
||||
4. **容错：**出现网络错误时自动故障转移到替代路径
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **Mooncake Store**
|
||||
专为 LLM 推理工作负载设计的分布式 KVCache 存储引擎
|
||||
|
||||
1. **多副本支持**：存储同一对象的多个副本，以缓解访问热点
|
||||
|
||||
2. **并行 I/O**：支持大型对象的数据条带化和并行传输
|
||||
|
||||
3. **内存管理**：集成以实现高效的内存段分配`BufferAllocatorManager`
|
||||
|
||||
4. **协调**：用于元数据管理和对象生命周期控制`MasterService`
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
- **P2P Store：**为 checkpoint 转移、模型权重分配等场景提供去中心化的临时对象共享。
|
||||
|
||||
|
||||
|
||||
## Dynamo/[nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)
|
||||
|
||||
> [https://github.com/ai-dynamo/dynamo](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/dynamo)
|
||||
[怎么看英伟达GTC新发布的推理框架Dynamo](https://zhuanlan.zhihu.com/p/31583638702)
|
||||
[Nvidia Dynamo 详解一](https://link.zhihu.com/?target=https%3A//ata.atatech.org/articles/11020396057%3Fspm%3Data.21736010.0.0.675927713lFoan)
|
||||
|
||||
|
||||
Dynamo 与推理引擎无关，支持 TRT-LLM、vLLM、SGLang 等，并捕获 LLM 特定的功能，例如：
|
||||
- **分解预填充和解码推理**- 最大化 GPU 吞吐量并促进吞吐量和延迟之间的权衡。
|
||||
- **动态 GPU 调度**- 根据波动的需求优化性能。
|
||||
- **LLM 感知请求路由**- 消除不必要的 KV 缓存重新计算。
|
||||
- **加速数据传输**- 使用 NIXL 减少推理响应时间。
|
||||
- **KV 缓存卸载**- 利用多个内存层次结构实现更高的系统吞吐量。
|
||||
|
||||
|
||||
Dynamo 采用了 NIXL 技术，这项技术旨在通过减少同步和智能批处理来加快传输速度。为了实现最佳性能和可扩展性，Dynamo 充分利用了 Rust 和 Python 的优势。。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### [nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)
|
||||
|
||||
> [https://github.com/ai-dynamo/nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)
|
||||
NIXL 解决了分布式推理工作负载面临的复杂挑战，尤其是在网络和通信方面。这些挑战包括高性能要求、跨内存和存储的异构数据路径以及动态扩展的需求。NIXL 通过支持多个后端插件（如 UCX、GDS 和其他协议）的多功能 API，跨内存类型（HBM、DRAM、本地/远程 SSD）和存储系统提供高带宽、低延迟的点对点数据传输和统一抽象。
|
||||
|
||||
|
||||
NIXL 通过内存部分抽象出各种内存类型，允许跨异构系统进行统一的内存处理。Memory 部分表示可访问以进行数据传输的已注册内存段。
|
||||
|
||||
| 内存类型 | 描述 |
|
||||
| --- | --- |
|
||||
| DRAM_SEG | 系统内存 （RAM） |
|
||||
| VRAM_SEG | GPU 内存 （VRAM） |
|
||||
| FILE_SEG | 文件存储 |
|
||||
| BLK_SEG | 块存储设备 |
|
||||
| OBJ_SEG | 对象存储 |
|
||||
NIXL 目前支持以下后端技术：
|
||||
|
||||
1. **UCX （Unified Communication X）：**用于高性能网络的通信框架。
|
||||
|
||||
2. **GDS （GPUDirect Storage）：**NVIDIA Magnum IO GPUDirect Storage，用于在 GPU 内存和存储之间直接传输数据。
|
||||
|
||||
3. **UCX_MO （UCX Memory Operations）：**UCX 的扩展，专注于内存作。
|
||||
|
||||
### [gdrcopy](https://link.zhihu.com/?target=https%3A//github.com/NVIDIA/gdrcopy)
|
||||
GDRCopy 是一个基于 NVIDIA GPUDirect RDMA 技术构建的低延迟 GPU 内存复制库。它支持从 CPU 直接访问 GPU 内存，与传统的 CUDA 内存操作相比，数据传输延迟显著降低。
|
||||
- **非常低的开销**：GDRCopy 操作由 CPU 驱动，典型操作的开销仅为 0.1-0.2μs，而传统操作的开销为 6-7μs `cudaMemcpy`。
|
||||
- **高带宽**：在支持的平台上，写入操作（主机到设备）可以达到 6-8 GB/s。
|
||||
- **直接内存访问**：应用程序可以直接读取和写入 GPU 内存，而无需中间复制。
|
||||
|
||||
## 测试脚本
|
||||
### vllm
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
# This file demonstrates the example usage of disaggregated prefilling
|
||||
# We will launch 2 vllm instances (1 for prefill and 1 for decode),
|
||||
# and then transfer the KV cache between them.
|
||||
|
||||
set -xe
|
||||
|
||||
MODEL_NAME="/opt/llm/input/pretrain/Qwen--QwQ-32B"
|
||||
MAX_MODEL_LEN=32768
|
||||
GPU_MEMORY_UTILIZATION=0.95
|
||||
gpu_id_prefill="0,1"
|
||||
gpu_id_decoder="2,3"
|
||||
kv_cache_type="SharedStorageConnector" # SharedStorageConnector/ LMCacheConnectorV1 / NixlConnector
|
||||
|
||||
# Trap the SIGINT signal (triggered by Ctrl+C)
|
||||
trap 'cleanup' INT
|
||||
|
||||
export VLLM_HOST_IP=$(hostname -I | awk '{print $1}')
|
||||
|
||||
# a function that waits vLLM server to start
|
||||
wait_for_server() {
|
||||
local port=$1
|
||||
timeout 1200 bash -c "
|
||||
until curl -s localhost:${port}/v1/completions > /dev/null; do
|
||||
sleep 1
|
||||
done" && return 0 || return 1
|
||||
}
|
||||
|
||||
# You can also adjust --kv-ip and --kv-port for distributed inference.
|
||||
gpu_count_prefill=$(echo "$gpu_id_prefill" | tr ',' '\n' | wc -l)
|
||||
gpu_count_decode=$(echo "$gpu_id_decoder" | tr ',' '\n' | wc -l)
|
||||
|
||||
echo "Using LMCacheConnectorV1 for kv cache"
|
||||
# prefilling instance, which is the KV producer
|
||||
CUDA_VISIBLE_DEVICES=$gpu_id_prefill python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model $MODEL_NAME \
|
||||
--disable-log-requests \
|
||||
--port 8100 \
|
||||
--max-model-len $MAX_MODEL_LEN \
|
||||
--gpu-memory-utilization $GPU_MEMORY_UTILIZATION \
|
||||
--trust-remote-code \
|
||||
--enforce-eager \
|
||||
--tensor-parallel-size $gpu_count_prefill \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_producer","kv_connector_extra_config": {"discard_partial_chunks": false, "lmcache_rpc_port": "producer1"}}' &
|
||||
|
||||
CUDA_VISIBLE_DEVICES=$gpu_id_decoder python3 -m vllm.entrypoints.openai.api_server \
|
||||
--model $MODEL_NAME \
|
||||
--disable-log-requests \
|
||||
--port 8200 \
|
||||
--max-model-len $MAX_MODEL_LEN \
|
||||
--gpu-memory-utilization $GPU_MEMORY_UTILIZATION \
|
||||
--trust-remote-code \
|
||||
--enforce-eager \
|
||||
--tensor-parallel-size $gpu_count_decode \
|
||||
--kv-transfer-config \
|
||||
'{"kv_connector":"LMCacheConnectorV1","kv_role":"kv_consumer","kv_connector_extra_config": {"discard_partial_chunks": false, "lmcache_rpc_port": "consumer1"}}' &
|
||||
|
||||
# wait until prefill and decode instances are ready
|
||||
wait_for_server 8100
|
||||
wait_for_server 8200
|
||||
|
||||
python3 disagg_pd_proxy_server.py &
|
||||
|
||||
output2=$(curl -X POST -s http://localhost:8000/v1/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"model": "'$MODEL_NAME'",
|
||||
"prompt": "hello. Santa Clara is a",
|
||||
"max_tokens": 10,
|
||||
"temperature": 0
|
||||
}')
|
||||
```
|
||||
lmcache最好从官方docker中安装
|
||||
|
||||
### [sglang](https://link.zhihu.com/?target=https%3A//github.com/sgl-project/sglang)
|
||||
参考：[sglang Dense LLM PD分离部署](https://link.zhihu.com/?target=https%3A//blog.csdn.net/u013701860/article/details/147745303)
|
||||
|
||||
|
||||
同一个PD组中，P/D的tp_size需要相同，可以设置多个P或者多个D。
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
|
||||
MODEL_NAME="Qwen/Qwen3-0.6B"
|
||||
MAX_MODEL_LEN=32768
|
||||
gpu_id_prefill=0,1
|
||||
gpu_id_decoder=2,3
|
||||
GPU_MEMORY_UTILIZATION=0.95
|
||||
|
||||
# prefill
|
||||
echo "async start prefill server."
|
||||
CUDA_VISIBLE_DEVICES=$gpu_id_prefill python3 -m sglang.launch_server --model-path $MODEL_NAME \
|
||||
--disaggregation-mode prefill \
|
||||
--context-length $MAX_MODEL_LEN \
|
||||
--tp-size $gpu_count_prefill \
|
||||
--disable-radix-cache \
|
||||
--mem-fraction-static $GPU_MEMORY_UTILIZATION \
|
||||
--disaggregation-transfer-backend $disaggregation_transfer_backend \
|
||||
--trust-remote-code \
|
||||
--page-size 16 \
|
||||
--port 8100 &
|
||||
|
||||
# decoder
|
||||
echo "async start decoder server."
|
||||
CUDA_VISIBLE_DEVICES=$gpu_id_decoder python3 -m sglang.launch_server --model-path $MODEL_NAME \
|
||||
--disaggregation-mode decode \
|
||||
--context-length $MAX_MODEL_LEN \
|
||||
--tp-size $gpu_count_decoder \
|
||||
--disable-radix-cache \
|
||||
--mem-fraction-static $GPU_MEMORY_UTILIZATION \
|
||||
--disaggregation-transfer-backend $disaggregation_transfer_backend \
|
||||
--trust-remote-code \
|
||||
--page-size 16 \
|
||||
--port 8200 &
|
||||
|
||||
echo "start schedule server."
|
||||
python3 -m sglang.srt.disaggregation.mini_lb \
|
||||
--prefill http://localhost:8100 --decode http://localhost:8200 --host 0.0.0.0 --port 8002 &
|
||||
|
||||
# 多个prefill和decoder node 链接：https://blog.csdn.net/u013701860/article/details/147745303
|
||||
```
|
||||
|
||||
## 结论
|
||||
1、实测对于超长上下文+大模型+高并发，PD分离可以始终保持TBT在一个很稳定的状态，吞吐量可以提升20%~50%不等。一般来说，至少也要输入>8k、输出>100、并发>10、模型大于32B左右，才有一些效果。
|
||||
2、PD分离优化的是TBT，对TTFT没有提升。
|
||||
3、PD分离时，如果prefill server少太多，可能会导致prefill阶段的计算能力不够，从而使TTFT变慢。因此Pod4改成3P1D差不多，2P2D一般不太行。但是实际上prefill只有一次，而decoder要很多遍，因此1P2D的配置可以更好的提高整体serve的资源利用率。
|
||||
4、PD分离时的prefill tp_size和decoding的tp_size可以不同。server数量也可以不同。server数量可以根据流量动态的增加和减少。
|
||||
5、kv cache传输人有GPU、CPU和disk等多种方式，其中GPU最快，基本可以保持原本的TTFT，其他都会导致TTFT变慢。NCCL需要在初始化时就确定全部的GPU，因此不适合于规模动态调整的PD分离场景，且不支持cpu和disk传输，Mooncake在此基础上进行了统一，支持多种传输方式。Dynamo也重新封装了一层nixl传输协议。
|
||||
6、request调度是PD分离的核心，不能只考虑负载均衡，还要考虑cache复用率、显存剩余空间等。
|
||||
7、PD分离后，会存在Prefill server宽带利用率低，decoder server的GPU利用率低的情况。
|
||||
|
||||
> [NVIDIA Dynamo的PD分离有问题？我们提出的大模型推理系统"肾上腺素"，是良药！](https://zhuanlan.zhihu.com/p/1888519961636487325)
|
||||
8、PD分离适用于bs较大、输入、输出都比较长的场景。普通场景没必要折腾。能单卡跑的没必要多卡，能单机承载的没必要多机。
|
||||
9、PD分离优势——异构框架：计算性能极强但传输带宽较低的GPU进行prefill，使用计算能力一般但传输带宽很高的GPU进行decoding。这样才能更好的发挥优势。
|
||||
|
||||
## 参考文章
|
||||
[PD分离-XpYd系统服务化](https://zhuanlan.zhihu.com/p/30619735151)
|
||||
[vLLM PD分离方案浅析](https://zhuanlan.zhihu.com/p/1889243870430201414)
|
||||
[https://github.com/LMCache/LMCache](https://link.zhihu.com/?target=https%3A//github.com/LMCache/LMCache)
|
||||
[Deploying DeepSeek with PD Disaggregation and Large-scale Expert Parallelism on 96 H100 GPUs](https://link.zhihu.com/?target=https%3A//lmsys.org/blog/2025-05-05-large-scale-ep/%23prefill-and-decode-disaggregation)
|
||||
[https://github.com/sgl-project/sglang/issues/4655](https://link.zhihu.com/?target=https%3A//github.com/sgl-project/sglang/issues/4655)
|
||||
[https://docs.sglang.ai/backend/pd_disaggregation.html](https://link.zhihu.com/?target=https%3A//docs.sglang.ai/backend/pd_disaggregation.html)
|
||||
[Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving](https://link.zhihu.com/?target=https%3A//arxiv.org/abs/2407.00079)
|
||||
[https://github.com/kvcache-ai/Mooncake](https://link.zhihu.com/?target=https%3A//github.com/kvcache-ai/Mooncake)
|
||||
[Mooncake 最新进展：SGLang 和 LMCache 基于 Mooncake 实现高效 PD 分离框架](https://zhuanlan.zhihu.com/p/1906034699358437813)
|
||||
[Mooncake (1): 在月之暗面做月饼，Kimi 以 KVCache 为中心的分离式推理架构](https://zhuanlan.zhihu.com/p/705754254)
|
||||
[Mooncake阅读笔记：深入学习以Cache为中心的调度思想，谱写LLM服务降本增效新篇章](https://zhuanlan.zhihu.com/p/706097807)
|
||||
[从MoonCake看大模型推理的PD分离，太快会扯到蛋吗？](https://zhuanlan.zhihu.com/p/8056351077)
|
||||
[https://github.com/ai-dynamo/dynamo](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/dynamo)
|
||||
[https://github.com/ai-dynamo/nixl](https://link.zhihu.com/?target=https%3A//github.com/ai-dynamo/nixl)
|
||||
[怎么看英伟达GTC新发布的推理框架Dynamo](https://zhuanlan.zhihu.com/p/31583638702)
|
||||
[Nvidia Dynamo 详解一](https://link.zhihu.com/?target=https%3A//ata.atatech.org/articles/11020396057%3Fspm%3Data.21736010.0.0.675927713lFoan)
|
||||
[https://github.com/NVIDIA/gdrcopy](https://link.zhihu.com/?target=https%3A//github.com/NVIDIA/gdrcopy)
|
||||
[sglang Dense LLM PD分离部署](https://link.zhihu.com/?target=https%3A//blog.csdn.net/u013701860/article/details/147745303)
|
||||
[NVIDIA Dynamo的PD分离有问题？我们提出的大模型推理系统"肾上腺素"，是良药！](https://zhuanlan.zhihu.com/p/1888519961636487325)
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：LLM关于PD分离的最新实测
|
||||
|
||||
> **原文**：[2025-06-22_LLM关于PD分离的最新实测.md](./2025-06-22_LLM关于PD分离的最新实测.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1919794916504114120
|
||||
> **来源**：知乎
|
||||
> **作者**：akaihaoshuai
|
||||
> **发布日期**：2025-06-22
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **实测边界** — 给出 PD 分离生效的量化阈值与工程落地经验，并指出其核心是 cache 调度。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
作者基于 vLLM/sglang 的 PD 分离实测，给出 9 条工程结论：PD 分离仅在超长上下文+大模型+高并发下收益明显（至少输入>8k、输出>100、并发>10、模型>32B），吞吐提升 20%~50%，且优化的是 TBT 而非 TTFT；P/D 配比 3P1D 较优、1P2D 更佳；prefill 可用 4090 这类"算力够、带宽差"的卡做异构部署。文章还逐一代码剖析了 SharedStorageConnector、P2pNcclConnector、LMCacheConnector、NixlConnector 与 sglang 的 PD 分离实现，并给出可直接复用的启动脚本。价值在于把 PD 分离从概念落实到"选型边界"，并明确指出普通场景没必要折腾。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **收益有明确阈值** — 至少输入>8k、输出>100、并发>10、模型>32B 左右才有效果；超长上下文+大并发下 TBT 可保持稳定，吞吐提升 20%~50% `[分类: 共识]`
|
||||
2. **PD 分离优化 TBT 而非 TTFT** — 且 prefill 卡减少（如 TP2 变 1P1D）会导致大 bs、长输入时 TTFT 变长 `[分类: 共识]`
|
||||
3. **P/D 配比反直觉** — 2P2D 一般不太行、3P1D 差不多；因 prefill 只执行一次而 decode 要很多遍，1P2D 更能提升整体资源利用率 `[分类: 争议]`
|
||||
4. **核心在于 cache 调度** — request 调度不能只考虑负载均衡，还要考虑 cache 复用率、显存剩余空间等 `[分类: 共识]`
|
||||
5. **传输方式决定 TTFT 损耗** — GPU 传输（NCCL）最快、基本保持原 TTFT，CPU/disk 传输都会使 TTFT 变慢；NCCL 初始化即固定全部 GPU、不适合动态扩缩容，Mooncake 统一多种传输方式，Dynamo 重新封装 nixl 协议 `[分类: 共识]`
|
||||
6. **异构框架最大化性价比** — 4090 算力约为 A/H 系列 30%~50% 但带宽不足 10%，非常适合 prefill 阶段；高带宽 GPU 做 decoding `[分类: 共识]`
|
||||
7. **分离后的固有资源短板** — Prefill server 带宽利用率低、decoder server GPU 利用率低，是 PD 分离需要接受的代价 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者具备 vLLM/sglang 使用经验；测试环境为作者自有的 GPU 集群，结论依赖具体模型（Qwen 系列）与负载形态，阈值未必能直接外推到其他硬件组合。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
结论来自一手实测与源码阅读，可信度高；但未披露完整测试环境与数据细节，"20%~50%"为区间估计，缺少逐项实验数据表，难以复现验证。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者明确给出适用边界——"能单卡跑的没必要多卡，能单机承载的没必要多机"；结论在短上下文、小模型、低并发场景不适用，且 PD 分离本身会引入 P/D 两侧资源利用率失衡的新问题。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD分离的核心其实在于cache的调度。"
|
||||
|
||||
> "能单卡跑的没必要多卡，能单机承载的没必要多机。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 9 条实测结论量化了收益边界，反直觉结论（1P2D 优于 2P2D）有工程指导价值
|
||||
- 四种 KVConnector 的代码级对比透彻，启动脚本可直接复用
|
||||
- 异构硬件（4090 做 prefill）观点对成本敏感团队极有参考价值
|
||||
|
||||
**不足**：
|
||||
- 测试环境与数据细节披露不足，结论难以严格复现
|
||||
- 对 sglang 与 Mooncake 的介绍偏向代码流程转述
|
||||
- Dynamo/nixl 章节与"实测"主题关联度略松散
|
||||
|
||||
**适用场景**：推理服务工程师做 PD 分离技术选型与落地；需要判断"我的场景该不该上 PD 分离"的团队；预算有限、考虑异构卡部署的团队。
|
||||
|
||||
**关联建议**：结合极客博哥《LLM PD 分离背后的架构问题》对照架构决策维度；阅读 Mooncake 论文与 vLLM disaggregated serving 官方文档；跟踪 Dynamo 框架演进。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,83 @@
|
||||
# LLM PD 分离背后的架构问题
|
||||
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：极客博哥（solrex）
|
||||
> **发布日期**：2026-08-05
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/27836625742
|
||||
|
||||
---
|
||||
|
||||
PD 分离（Prefilling Decoding Disaggregation）推理是指将大模型推理的预填充阶段（P）和解码（D）阶段分离，以减少预填充与解码相互之间的影响，以便对两个阶段分别进行优化，提升 GPU 硬件的利用率，并减少推理延迟的一种推理技术方案。
|
||||
|
||||
在 DistServe、Mooncake 等论文中介绍分离式架构之后，DeepSeek V3 的报告让大家更进一步意识到 PD 分离可能是影响成本和性能的关键技术。
|
||||
|
||||
vLLM 对 PD 分离已经有了一个 1P1D 的实验版本。除此之外的开源框架大多还都不支持，不过很多已经在计划、实现中了。但纵览这些实现、文章或者计划，可以看到 PD 分离的架构选型上有很多问题需要思考，我尝试列举一下：
|
||||
|
||||
## 一、PD 是否直连传输？或是否需要 KV Cache Store/Pool？
|
||||
|
||||
PD 直连就是预填充节点直接将 KV Cache 发送给解码节点，它的好处是延迟低。但也意味着在整个 batch 的计算过程中锁定了P、D 节点的对应关系，一旦解码节点出现了问题，比如压力过大、服务出错、传输阻塞，在重试时无法仅调度 D 节点，需要重新进行整个预填充、解码过程。在 prompt 较长时，或者在 PD 节点数不对等的场景下，例如 2 个 P 对应到 1 个 D，重调度意味着抛弃较长或者多个 prefill batch，重调度的沉没成本较高。
|
||||
|
||||
使用 KV Cache Store/Pool 是在 P 和 D 之间增加了一个中间存储，预填充节点先将 KV Cache 写到中间存储，解码节点从中间存储读。这样做数据会多传输一次，增加了延迟，也增加了一些复杂度。但好处是容错性更好，还有就是预填充阶段本身也可以利用这个中间存储做 Prefix Caching。
|
||||
|
||||
中间存储也会对其它一些架构变动的复杂度产生影响，参见下面问题 四 和 五。
|
||||
|
||||
目前来看，Kimi Mooncacke、vLLM 的下一步设计、阿里 RTP-LLM 都使用或者计划使用基于 KV Cache Store/Pool 的方案，DeepSeek V3 报告中没有提到这部分。
|
||||
|
||||
在一些计算配比均衡、故障风险较小的场景下，比如同机多卡之间的 PD 分离，PD 直连的方案也有其简单易部署的优势。
|
||||
|
||||
## 二、P/D 是否按层发送/接收 KV Cache？
|
||||
|
||||
预填充最简单的实现是预填充节点完成第一个 token 的生成后，将所有的 KV Cache 传输给解码节点，这也是 vLLM 当前的实现。但这样实现有个问题，因为 KV Cache 的规模有可能非常大（尤其是原始 MHA），一个 batch 的 KV Cache 可能会是 GB 级别，都放在计算完成后传输，传输的延迟开销会比较大。
|
||||
|
||||
Kimi Mooncacke 和阿里 RTP-LLM 都采取了按层传输的方案，这是利用了 LLM 多层计算的自然特性。在完成一层的计算以后，就将这一层的 KV Cache 发送出去。这样 KV Cache 的发送就呈流式，既能降低延迟，也能使数据的发送更平滑。还存在一个更显著的优势，是 KV Cache 占用显存的时间更短，在显存紧张的情况下显存效率更高。
|
||||
|
||||
但按层发送对推理引擎的修改显然更大。我还没有看到开源的实现，猜测按层发送的引入对推理引擎的优化应该会有一定的影响，这里可能还需要一些精巧的设计才能减少影响。另外，按层发送对于 PD 非直连的场景下，中间存储的实现也会显著更复杂，QPS * num_hidden_layers，考虑到连续性可能还需要存储预分配和 session 保持。
|
||||
|
||||
因此对于 MLA 这种 KV Cache 偏小的注意力实现，比如 DeepSeek V3 的 KV Cache 是 576B/token/layer，是否要做按层发送，也许要看一下实际收益。
|
||||
|
||||
解码阶段和预填充阶段有所不同。解码需要多次迭代，在第一次迭代实现按层解码也没太大意义，而且涉及到计算的编排，应该需要拿到所有层的 KV Cache 才会开始计算。而且解码的计算时间比较长，如果解码的计算能够掩盖接收的延迟，不一定非要实现按层接收。
|
||||
|
||||
解码时按层接收，对调度也有一定挑战。从时序上来说，先发请求给预填充，完成后再发请求给解码会更自然。同时请求预填充和解码，需要处理一些同步问题，比如预填充压力大、解码等 KV Cache 超时等等。比如像阿里 RTP-LLM，它会观测预填充的排队情况，当一个请求进入预填充执行阶段时，解码端开始启动显存申请。
|
||||
|
||||
## 三、First Token 怎么处理
|
||||
|
||||
通常来说，预填充的同时会顺便把第一个 Token 计算出来，但计算到 hidden states 还是 token id 需要做一个选择。
|
||||
|
||||
计算到 hidden states 的好处是，预填充节点完全不需要加载和计算 lm_head 参数。比如 DeepSeek V3 的 lm_head 参数量是 0.9B，如果计算到 hidden states，这部分参数就完全不需要加载了。vLLM 目前就是采取的这个方式，预填充除了需要发送 KV Cache 之外，还需要发送一个 hidden states，解码时引擎也需要能支持加载 hidden states 延续计算。
|
||||
|
||||
计算到 token id 的好处是，发送的数据量小。以 DeepSeek V3 为例，hidden states 7K，token id 4B，完全可以跟着控制面消息传输。解码时引擎处理也更简单，因为 token id 到 token 的 detokenizer 一般是 CPU 查表，不涉及 tensor 的特殊处理。阿里 RTP-LLM 看起来采用的是这个方案。
|
||||
|
||||
## 四、Prefiller 和 Decoder 是否能相互转换？
|
||||
|
||||
当到达请求的 prompt 长度有差异性的时候，预填充和解码就会出现压力的不均衡问题。因为整体的吞吐取决于 P 和 D 的全局资源利用，当 P 过载但 D 闲置，或者 P 闲置但 D 过载的时候，成本和性能都不是最优的。
|
||||
|
||||
所以就需要考虑在 P 和 D 之间做负载均衡，要么从整个节点层面直接切换 P 和 D 的角色，要么 P 和 D 节点能够承担一些混杂的请求，比如通过 chunked prefill。
|
||||
|
||||
这时候 P 和 D 是否直连对实现复杂度就有一些影响了，如果有中间存储的存在，通过 PD 转换做负载均衡的实现难度会降低很多。
|
||||
|
||||
## 五、Decoder 能填充 KV Cache 吗？
|
||||
|
||||
如果业务应用场景中会将生成的 context 也作为下一轮的输入，还可能需要考虑 Decoder 填充 KV Cache，用于下一轮的 prefix caching 复用。这时候，KV Cache Store/Pool 的存在，对流畅交互有比较大的意义。
|
||||
|
||||
## 六、KV Cache Store/Pool 的设计抉择
|
||||
|
||||
有别于我们通常的 KV 存储，由于 GPU、RDMA（IB、RoCE）、NVLink 新硬件的存在，KV Cache Store/Pool 的设计抉择点会非常多。
|
||||
|
||||
在存储上，有 VRAM、DRAM、NVMe SSD，要选择 KV Cache Store 使用哪些介质。虽然对于 MHA 来说，因为 KV Cache 太大，基于 SSD 存储并不现实，但是对于 MQA、MLA 来说，NVMe SSD 并不是不可用。
|
||||
|
||||
在通信上，有 TCP、NVLink、RDMA、GPU Direct RDMA、NVMe over RDMA。为了更高的性能，KV Cache Store 在数据面上可能要考虑使用更快、更直接的传输方法。但 RDMA 对数据访问的抽象比 TCP 复杂很多，TCP 就是一端发一端收，但 RDMA 很多是单边操作。比如数据从 A 机 VRAM 发送到 B 机 DRAM，可能有以下方法：
|
||||
|
||||
- A 从 VRAM 复制到 DRAM 再写 B 的 DRAM
|
||||
- A 从 VRAM 复制到 DRAM 再让 B 读 A 的 DRAM
|
||||
- A 直接从 VRAM 复制到 B 的 DRAM
|
||||
- B 直接读 A 的 VRAM
|
||||
|
||||
如果再加上 NVMe over RDMA，那要考虑的东西就更多了。P 发送到 Store，D 从 Store 接收，到底要通过哪些模式支持，是需要思考的。目前来看，预填充节点更适合单边写到 Store，这样能减少状态传输，更快地释放显存，但如果预填充节点也要读 prefix cache，那情况可能反过来；解码节点可能更适合单边读 Store。
|
||||
|
||||
在分布式架构上，无论是做集群式的 KV Cache Store，还是单机 side-car 式的 KV Cache Store，都需要存储一些 meta，并且在 P、D 之间传输一些控制信息。学术界有一些完全基于 RDMA 实现的分布式 KV 数据库，但目前看复杂度还是比较高，也没有开源的实现。目前业界实现还是倾向于使用传统的 RPC 方式来传输控制信息，并且通过分布式技术方案做 meta 节点的一致性、可靠性设计。
|
||||
|
||||
在接口 API 上，KV Cache Store 比传统的 KV Store 要复杂一些。比如要支持写的时候分 layer 写，读的时候能读到连续的内容；还可能要支持队列式的读，写完的 layer 可以很快被读走。如果要支持 prefix caching，还存在 KV Cache 的链式关系，写的时候不仅要分 layer，还要分 page，读的时候也是。TP/SP 等并行计算机制，对 API 可能还会有一些额外的要求。
|
||||
|
||||
在数据结构上，如果希望从 VRAM 直接写 Store，减少一次复制，引擎本身的 KV Cache 数据结构就需要与 Store 的数据结构进行一定程度的对齐；如果希望同时兼做 prefix caching，那 store 的数据排布就要考虑相同 prefix 的 page 更接近，甚至共享。比如用 prompt 的所有 page 的 hash 组成 string，按前缀 range 分桶，桶内对相同前缀做 merge/引用等等，这在存储优化上会是一个挑战。
|
||||
|
||||
整体来看，PD 分离的实现上有很多架构问题需要抉择，目前还没有一个理想的架构方案，或许未来也会是根据不同场景有很多参数化的灵活配置。
|
||||
@@ -0,0 +1,78 @@
|
||||
# 📊 文章摘要：LLM PD 分离背后的架构问题
|
||||
|
||||
> **原文**：[2026-08-05_LLM_PD_分离背后的架构问题.md](./2026-08-05_LLM_PD_分离背后的架构问题.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/27836625742
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：极客博哥（solrex）
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **架构抉择** — PD 分离落地前必须系统回答的六大架构决策问题，作者以工程视角指出目前尚无理想方案。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文系统梳理 PD 分离实现层面的架构选型问题，包括 PD 直连与 KV Cache Store/Pool 之争、KV Cache 是否按层传输、首 token 的 hidden states/token id 处理、Prefiller 与 Decoder 角色互换、Decoder 回填 KV Cache，以及 KV Cache Store 在存储介质、通信协议、分布式架构与数据结构上的设计抉择。其价值在于：主流资料多讲 PD 分离的收益，本文聚焦实现前的决策空间，并对照 vLLM、Mooncake、阿里 RTP-LLM 等现有实现的选择。局限是观点多为工程观察与推测，缺乏实验数据支撑。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **PD 直连 vs KV Cache Store/Pool 是首要抉择** — 直连延迟低但锁定 P/D 节点对应关系、重调度沉没成本高；中间存储多一次传输但容错更好、可兼做 Prefix Caching。Mooncake、vLLM 下一步设计、RTP-LLM 均选后者 `[分类: 共识]`
|
||||
2. **按层传输是流式化趋势但代价高昂** — Mooncake、RTP-LLM 按层发送 KV Cache 以降低延迟与显存占用时长，但推理引擎改造大、中间存储实现显著复杂（需处理 QPS × 层数的存储预分配与 session 保持）；对 MLA 这类 KV Cache 偏小的注意力实现是否值得需看实际收益 `[分类: 争议]`
|
||||
3. **首 token 的两种计算路径** — 算到 hidden states 免加载 lm_head（DeepSeek V3 为 0.9B 参数，vLLM 采用）；算到 token id 传输量小、解码端处理简单（RTP-LLM 采用）`[分类: 争议]`
|
||||
4. **P/D 角色可转换是负载均衡的前提** — prompt 长度差异导致 P/D 压力失衡，需节点级角色切换或 chunked prefill 兜底；存在中间存储时转换实现难度大幅降低 `[分类: 未探索]`
|
||||
5. **KV Cache Store 的设计抉择远超传统 KV 存储** — 涉及 VRAM/DRAM/NVMe SSD 介质选择（MQA/MLA 下 SSD 并非不可用）、TCP/NVLink/RDMA/GPU Direct RDMA 单边操作、RPC 控制面与 meta 一致性、分 layer/page 写入及链式 prefix 引用等挑战，目前无开源完整方案 `[分类: 未探索]`
|
||||
6. **解码端按层接收对调度构成挑战** — 同时请求 P/D 需处理预填充排队观测、解码端显存预申请等同步问题（如 RTP-LLM 在请求进入 prefill 执行阶段时启动解码端显存申请）`[分类: 未探索]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设 PD 分离是值得投入的技术方向（以 DistServe、Mooncake、DeepSeek V3 报告为背景）；假设读者熟悉 vLLM、Mooncake、RTP-LLM 等实现细节。若场景是单卡、短上下文或小规模部署，文中多数决策问题不成立。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
以工程观察和开源实现对照支撑论点，逻辑链条完整；但"按层发送对推理引擎的优化应该会有一定的影响"等表述作者自承是"猜测"，缺少量化验证；MLA 场景是否值得按层传输也只停留在"要看实际收益"的开放判断。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者明确承认"目前还没有一个理想的架构方案"，并指出结论随场景而异（如同机多卡 PD 直连自有其简单易部署的优势）；结论适用于长上下文、大并发、需多机部署的中大型推理服务，不适用于计算配比均衡、故障风险小的同机简单场景。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "整体来看，PD 分离的实现上有很多架构问题需要抉择，目前还没有一个理想的架构方案，或许未来也会是根据不同场景有很多参数化的灵活配置。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 系统化提出六大架构决策框架，是目前少见的"实现前决策清单"类文章
|
||||
- 每种方案均给出利弊与业界实现（Mooncake/vLLM/RTP-LLM/DeepSeek V3）对照
|
||||
- 边界意识强，明确区分适用与不适用场景
|
||||
|
||||
**不足**：
|
||||
- 无实验数据，多处判断停留在推测层面
|
||||
- 按层发送对 MLA 的收益评估未深入展开
|
||||
- KV Cache Store 控制面方案（RPC vs RDMA）讨论点到为止
|
||||
|
||||
**适用场景**：推理系统架构师、GPU 集群服务化团队在 PD 分离技术选型前的决策参考；理解 Mooncake、vLLM、RTP-LLM 设计取舍时的对照材料。
|
||||
|
||||
**关联建议**：结合 DistServe 论文（动机与 SLO 建模）、Mooncake 论文（KVCache 中心调度）阅读；与 akaihaoshuai《LLM关于PD分离的最新实测》互补——前者给决策维度，后者给实测边界。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,362 @@
|
||||
# 大模型系列：深度解析 Prefill-Decode 分离式部署架构
|
||||
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：猫先生
|
||||
> **发布日期**：2025-06-17
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1918334902492963669
|
||||
|
||||
---
|
||||
|
||||
〔更多精彩AI内容，尽在「魔方AI空间」，引领AIGC科技时代〕
|
||||
|
||||
> 本文作者：猫先生
|
||||
> 【从零走向AGI】旨在深入了解通用人工智能（AGI）的发展路径，从最基础的概念起，逐步构建完整的知识体系。
|
||||
> 项目地址 ：
|
||||
|
||||
---
|
||||
|
||||
在上一篇文章中，我们介绍了NVIDIA 发布的Dynamo框架及其PD分离式部署技术，旨在优化大语言模型（LLM）推理过程中的资源利用和推理效率。
|
||||
|
||||
《大模型系列：NVIDIA Dynamo框架详解——PD分离式部署技术解析》
|
||||
|
||||
Dynamo的PD分离式部署技术通过优化资源分配和推理流程，显著提升了LLM推理的效率和资源利用率，有望成为未来AI推理服务的重要架构。
|
||||
|
||||
那么，本文将深度解析 Prefill-Decode 分离式部署架构的原理！！
|
||||
|
||||
我们开始吧！！
|
||||
|
||||
## 一、什么是Prefill-Decode分离架构
|
||||
|
||||
**预填充-解码阶段分离**是一种用于处理长上下文大型语言模型（LLMs）的方法，旨在通过将推理过程分为两个主要阶段——**预填充（Prefill）和解码（Decoding）**，这两个阶段被拆分到不同的 GPU 实例上独立运行。如下图所示，DistServe论文中的架构图。
|
||||
|
||||
### 预填充阶段（Prefill Phase）
|
||||
|
||||
- **目标**：预填充阶段的主要目标是处理输入序列的所有输入token，以构建键值缓存（KV Cache）。这个缓存用于存储中间计算结果，以便在后续的解码阶段重用。
|
||||
- **特点**：预填充阶段通常是**计算密集型的**，因为它需要处理整个输入序列，并生成初始的输出标记。由于注意力机制的计算复杂度与**输入序列长度的平方**成正比，因此**长序列的处理需要更多的计算资源。**
|
||||
|
||||
### 解码阶段（Decoding Phase）
|
||||
|
||||
- **目标**：解码阶段的任务是**基于预填充阶段构建的键值缓存**，逐个生成输出token。由于每个新生成的token只需要计算与之相关的键值缓存，因此解码阶段的计算负载相对较轻。
|
||||
- **特点**：**解码阶段通常需要较少的计算资源**，但仍然需要**频繁访问键值缓存**。为了减少干扰，PDD将解码阶段与预填充阶段**分离到不同的GPU组。**
|
||||
|
||||
## 二、为什么LLM推理分成两个阶段：Prefill 和 Decode？
|
||||
|
||||
要想回答这个**"为什么"**，我们需要首先搞懂 **prefill 阶段的内部机制，attention 的计算细节、KV Cache 是如何初始化的、为什么 prefill 计算量这么大。**
|
||||
|
||||
**在传统集成式推理流水线中**，LLM的Prefill和Decode阶段往往被置于同一GPU上运行，导致资源需求不匹配，资源利用率不高。例如，当用户请求的Prefill长度和Decode长度非常不匹配时，同一GPU需要同时处理高算力需求和高内存带宽需求的任务，难以发挥最佳性能。
|
||||
|
||||
**一句话简单理解**：LLM生成文本的过程本质上是**给定上下文，逐词预测下一个词**。但在实现上，这个过程被明确地**分成两个阶段：**
|
||||
|
||||
| 阶段 | 资源需求特性 | 计算模式 | 显存占用模式 | 目的 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Prefill | 计算密集型 | 高并行度，矩阵乘法为主 | 低，固定规模 | 模型读取并"理解"你输入的所有上下文 |
|
||||
| Decode | 内存密集型 | 顺序生成，访存为主 | 随上下文增长指数级上升 | 模型基于已有信息逐步生成回复 |
|
||||
|
||||
Prefill 是用户输入完 prompt 到生成首个 token 的过程，Decode 则为生成首个 token 到推理停止的过程。
|
||||
|
||||
那么，这样我们就很好理解，
|
||||
|
||||
**为什么不能一个阶段，而必须拆分成两个阶段进行：**
|
||||
|
||||
- 输入 prompt 是完整的、一次性提供的，**适合并行计算。**
|
||||
- 输出 token 是未知的，只能**一个一个推理，必须串行。**
|
||||
|
||||
**在Prefill阶段**，大模型一次性对prompt中所有token进行计算QKV，由于不同token的计算是独立的，因此该过程可以并行。**在Attention部分**，计算得到的QKV进一步计算出Output矩阵，再经过后续的FFN层和解码**得到首字母token。**
|
||||
|
||||
**在Decode阶段**，计算原理和 Prefill 完全相同，但计算方式却不能一样。**原因有两个：**
|
||||
|
||||
**第一：随着序列长度的增加**，Attention 计算复杂度平方级增长，直接计算代价很大，导致长序列的推理时间极慢，甚至不可行。
|
||||
|
||||
**第二：对Decode阶段**的计算过程简单分析发现，该过程可以复用 Prefill 阶段的KV结果，也可以复用Decode阶段已经产生的KV结果。
|
||||
|
||||
**综上，可以把已产生的KV存起来**，不必重新计算，这就是KV Cache。对于Q矩阵，每次需要计算的只是Q的最后一行q，计算关于**qKV的attention**，而不是关于**QKV的attention**，这样**复杂度降低了一个量级，实现以存换算。**
|
||||
|
||||
## 三、Prefill 内部运行机制
|
||||
|
||||
> **Prefill 阶段是语言模型推理中的第一个步骤**，它负责处理你输入的所有上下文内容（prompt），为后续生成打下基础。
|
||||
|
||||
比如你问模型一句话：
|
||||
|
||||
"请解释一下 Transformer 的原理。"
|
||||
|
||||
这句话会被 tokenizer 编码为一串 token，比如 `["请", "解释", "一下", "Trans", "##former", "的", "原理", "。"]`。
|
||||
|
||||
然后这些 token 会进入 Transformer 模型进行前向传播。想要更详细了解Transformer的运行原理，可以参考这篇文章《新手必看 | 44张图带您极简学习Transformer | 分步数学示例（建议收藏）》
|
||||
|
||||
**重点来了**
|
||||
|
||||
**Prefill 中模型内部到底发生了什么？**
|
||||
|
||||
**Step 1：Embedding 输入**
|
||||
|
||||
- 每个 token 会映射成一个向量（embedding），形状为 `[batch_size, seq_len, hidden_dim]`
|
||||
|
||||
**Step 2：Self-Attention 的全量计算**
|
||||
|
||||
- 输入是完整的上下文，因此模型会执行一次完整的 masked self-attention。对于位置 i 的 token，会计算它和前面所有位置的注意力（包括自己）：
|
||||
|
||||
**Step 3：生成 KV Cache**
|
||||
|
||||
- 每层 Transformer 都会把每个 token 的 K 和 V 存下来，形成 KV Cache：
|
||||
|
||||
```
|
||||
KV Cache = [K₁, K₂, ..., Kₙ], [V₁, V₂, ..., Vₙ]
|
||||
```
|
||||
|
||||
这个 Cache 会在 decode 阶段被反复使用，避免重复计算。
|
||||
|
||||
## 四、为什么 prefill 的计算成本那么高？
|
||||
|
||||
让我们做个简单对比：
|
||||
|
||||
| | Prefill | Decode（单步） |
|
||||
| --- | --- | --- |
|
||||
| 处理 token 数 | 全部 prompt（如几百） | 1 个 |
|
||||
| Attention 计算 | 全 attention matrix | 只看已有 KV |
|
||||
| 是否可并行 | ✅ 是 | ❌ 否（必须串行） |
|
||||
| 计算资源 | 重 | 轻 |
|
||||
|
||||
> Prefill 最大的特点是：
|
||||
|
||||
- 需要 **"每个 token 与前面所有 token 做 attention"**
|
||||
- 不能复用 KV Cache（因为是第一次建立）
|
||||
|
||||
**Prefill 是典型的 compute-bound 阶段**：
|
||||
|
||||
- 大量矩阵乘法和 attention 计算主导性能瓶颈
|
||||
- GPU 的算力利用率很高，但内存带宽压力较小
|
||||
|
||||
因此如果你的 prompt 很长，Prefill 阶段就会非常耗时。很多模型响应慢，不是生成慢，而是 prompt 处理慢。
|
||||
|
||||
## 五、Decode：token-by-token 地生成输出
|
||||
|
||||
在 prefill 之后，模型已经建立了一个完整的 KV Cache，可以开始逐步生成 token。
|
||||
|
||||
每次 decode 只需要：
|
||||
|
||||
- 把最新生成的 token 输入进去
|
||||
- 拿之前的 KV Cache 来做 attention
|
||||
- 预测下一个 token
|
||||
|
||||
**Decode 是典型的 memory-bound 阶段**：
|
||||
|
||||
- 每生成一个 token，都需要访问所有历史的 KV Cache（多层、多头）
|
||||
- 计算量小，但内存带宽压力大。
|
||||
- 特别在 batch size 小、生成序列长的场景，GPU 利用率会很低。
|
||||
|
||||
## 六、Prefill vs Decode 的性能瓶颈差异
|
||||
|
||||
由于Prefill、Decode这两个阶段的输入特性和计算方式**本质不同，**所以将其拆分成两个阶段是**为了精准优化每一步的计算路径**，比如：
|
||||
|
||||
- Prefill 可用 FlashAttention 等并行技术提升性能
|
||||
- Decode 可用 KV Cache、speculative decoding 等加速生成
|
||||
|
||||
在推理过程中，**Prefill 和 Decode 阶段不仅在结构上不同，在性能瓶颈上也大相径庭**：
|
||||
|
||||
| 阶段 | 特点 | 性能瓶颈 | 原因 |
|
||||
| --- | --- | --- | --- |
|
||||
| Prefill | 一次处理整个输入序列 | Compute-bound | 多 token 并行计算，Attention + MLP 计算密集 |
|
||||
| Decode | 每次生成一个 token，逐步执行 | Bandwidth-bound | 每次要读取大量 KV Cache，但计算量小，等数据成为瓶颈 |
|
||||
|
||||
### 为什么 Decode 会是 Bandwidth-bound？
|
||||
|
||||
在 Decode 阶段，虽然只生成一个新 token，但为了计算它的注意力得分，需要加载 **全部历史 token 的** **KV** **Cache**。这意味着：
|
||||
|
||||
- 每层都要从 GPU 内存中读取大量数据；
|
||||
- 实际计算（比如 Q × K^T）规模却很小；
|
||||
- 导致 GPU 大量时间都在等内存传输，**而不是在计算**。
|
||||
|
||||
这就是典型的 **Bandwidth-bound** 场景 —— **内存带宽**成为限制性能的关键因素，而不是算力本身。
|
||||
|
||||
| 类型 | 具体含义 | 常见表现 |
|
||||
| --- | --- | --- |
|
||||
| Compute-bound | 受限于计算单元（ALU、CUDA 核心等） | GPU 计算占满 |
|
||||
| Bandwidth-bound | 受限于 访问速度：内存太慢，等数据成为瓶颈 | GPU 闲着在等内存 |
|
||||
| Memory-bound | 受限于 内存容量，模型或缓存太大放不下 | OOM / 频繁调度数据 |
|
||||
|
||||
## 七、PD分离原理
|
||||
|
||||
通过以上内容的分析，我们就能够很容易的理解PD分离式部署的原理了。**简单来说**，将Prefill（预填充）和Decode（解码）这两个推理阶段分开处理的技术，通常适用于对时延有严格要求的场景。
|
||||
|
||||
**将Prefill实例和Decode实例分开部署**，减少Prefill阶段和Decode阶段分时复用在时延上造成的互相干扰，实现同等时延下，提升吞吐量。
|
||||
|
||||
**PD分离工作原理如下图所示。**
|
||||
|
||||
**PD分离部署的优势：**
|
||||
|
||||
- **资源利用优化**：由于Prefill阶段计算密集，而Decode阶段计算较为稀疏，将这**两个阶段分离可以更好的利用GPU的计算资源。**
|
||||
- **提高吞吐量**：分离后的Prefill和Decode可以同时处理不同的请求，这意味着在Prefill阶段处理新请求的同时，Decode阶段可以继续**处理之前请求的解码任务**，从而提高了整体的处理能力。
|
||||
- **降低延迟**：由于Prefill和Decode分别在不同的阶段进行，**可以减少等待时间**，特别是当有多个请求并发到达时。
|
||||
|
||||
## 八、PD分离通信协议
|
||||
|
||||
在大模型推理中：
|
||||
|
||||
- **Prefill 阶段**：一次性处理输入 prompt（比如几千个 token），计算代价大、计算密集、通信密集；
|
||||
- **Decode 阶段**：逐 token 生成输出，计算相对轻量，但延迟敏感。
|
||||
|
||||
**PD 分离** 的思路是：
|
||||
**让 prefill 与 decode 阶段分别运行在不同的 worker 上（甚至不同节点上），形成更灵活的资源编排。**
|
||||
|
||||
这样可以让大模型推理 pipeline 化，提高吞吐量（Throughput）和利用率。
|
||||
|
||||
但 PD 分离带来的挑战是：prefill 输出的 **KV Cache（注意力缓存）** 要传递给 decode worker，这就需要高效的 **跨设备通信协议**。
|
||||
|
||||
### 1、NCCL
|
||||
|
||||
**NCCL (NVIDIA Collective Communication Library)** 是 NVIDIA 官方推出的 **GPU 间高性能通信库**，广泛用于分布式训练和推理。
|
||||
|
||||
它为深度学习框架（如 PyTorch、Megatron、vLLM、DeepSpeed 等）提供高效的 **collective communication primitives**：AllReduce、AllGather、ReduceScatter、Broadcast、Send/Recv。
|
||||
|
||||
| 特性 | 说明 |
|
||||
| --- | --- |
|
||||
| 底层协议 | 基于 NVLink / NVSwitch / PCIe / InfiniBand / RoCE |
|
||||
| 通信模式 | 点对点（P2P）与集合通信（collective）均支持 |
|
||||
| 典型用途 | 模型并行（Tensor/Sequence Parallel）、梯度同步、KV Cache 共享 |
|
||||
| 性能特征 | 延迟低、带宽高，尤其适合单机多卡或同集群高带宽环境 |
|
||||
| 限制 | 主要用于 GPU–GPU 间通信，不适合 CPU 或异构网络场景 |
|
||||
|
||||
在 PD 分离架构中，**如果 prefill worker 与 decode worker 处于同一 GPU 集群中（如同机或同网段 NVLink 环境）**，
|
||||
NCCL 是最常用的通信方式：
|
||||
|
||||
- Prefill 阶段完成后，将 KV Cache tensor 通过 NCCL 的 `Send/Recv` 或 `AllGather` 传给 Decode worker；
|
||||
- Decode worker 接收并继续推理。
|
||||
|
||||
**优点**：传输快、延迟低。
|
||||
**缺点**：只能在 GPU 直连或高速互联环境下使用（如 NVLink、IB/RoCE）。
|
||||
|
||||
### 2、NIXL
|
||||
|
||||
> **NIXL (NVIDIA Interconnect eXtension Layer)** 是 NVIDIA 新一代跨节点通信层，用于支持 **异构节点间的高效推理通信**，尤其是 **PD 分离架构下的远程 Prefill–Decode 数据传递**。
|
||||
|
||||
它是一个抽象通信层，位于 NCCL 和更高层推理框架（如 **Dynamo Inference Framework**, **TensorRT-LLM**, **vLLM**) 之间。
|
||||
|
||||
> 可以理解为：**NIXL = 面向推理系统的"远程 NCCL"**
|
||||
|
||||
| 特性 | 说明 |
|
||||
| --- | --- |
|
||||
| 定位 | NCCL 的扩展层，支持跨节点 / 跨网络传输 |
|
||||
| 通信语义 | 统一封装 Send/Recv、RDMA、ZeroCopy 等接口 |
|
||||
| 支持硬件 | 支持 NVLink、NVSwitch、InfiniBand、Ethernet |
|
||||
| 优化目标 | 降低跨节点 Prefill→Decode KV 传输延迟 |
|
||||
| 使用场景 | PD 分离架构、异构 GPU 集群、解耦式推理管线 |
|
||||
|
||||
- **NCCL**：适合 **单机或高带宽集群内** 的 GPU–GPU 通信；
|
||||
- **NIXL**：是 **NCCL 的远程扩展层**，用于 **跨节点 / 异构环境** 的高性能通信，特别针对 **Prefill–Decode 分离架构** 的 KV Cache 远程传输场景。
|
||||
|
||||
## 九、追溯PD分离技术
|
||||
|
||||
### （一）论文《SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills[1]》
|
||||
|
||||
时间：2023.8
|
||||
|
||||
提出了SARATHI技术来解决**LLM推理效率低下**的问题。
|
||||
|
||||
**随着语言模型的规模不断扩大**，推理所需的GPU计算资源显著增加，尤其是在小批量情况下，解码阶段的计算利用率较低，导致整体推理效率低下。
|
||||
|
||||
**通过改进预填充（prefill）和解码（decode）阶段的调度策略来提高LLM推理的效率。**具体来说，SARATHI通过使用**分块预填充和最大解码批处理**来解决这些问题。
|
||||
|
||||
- **分块预填充（Chunked-prefills）**:
|
||||
|
||||
- 将一个预填充请求分割成多个等大小的块，以最大化GPU的计算利用率。
|
||||
- 通过分割预填充请求，可以在单个预填充请求中构建多个解码最大批次，从而提高解码的覆盖范围。
|
||||
|
||||
- **最大解码批处理（Decode-maximal batching）**:
|
||||
|
||||
- 使用单个预填充块构建一个批次，并用解码请求填充剩余的槽位。
|
||||
- 这种混合批处理提供了既计算饱和又均匀的工作单元，解决了低效解码和管道气泡的问题。
|
||||
|
||||
### （二）论文《DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving[2]》
|
||||
|
||||
时间：2024.1月
|
||||
|
||||
https://github.com/LLMServe/DistServe
|
||||
|
||||
提出DistServe，一种通过解耦预填充和解码计算来优化LLM服务性能的系统。
|
||||
|
||||
**现有系统将预填充和解码阶段合并处理**，导致强烈的预填充-解码干扰和资源分配与并行计划的耦合；不同应用对每个阶段的延迟要求不同，如实时聊天机器人强调低首次token时间（TTFT），而文档摘要则强调低每个输出token的耗时（TPOT）。
|
||||
|
||||
**相关工作**：该问题的研究相关工作有：**vLLM和DeepSpeed-MII**等系统采用了**批处理和模型并行**策略来提高整体系统吞吐量，但这些方法未能有效解决预填充和解码阶段的干扰问题。
|
||||
|
||||
**DistServe**将预填充和解码阶段的**计算分配到不同的GPU上**，从而**消除预填充-解码干扰**。预填充阶段处理用户提示以生成响应的第一个token，而解码阶段则逐步生成后续token。
|
||||
|
||||
### （三）论文《LoongServe: Efficiently Serving Long-Context Large Language Models with Elastic Sequence Parallelism[3]》
|
||||
|
||||
时间：2024.4月
|
||||
|
||||
https://github.com/LoongServe/LoongServe
|
||||
|
||||
提出LoongServe系统，通过**弹性序列并行性（ESP）**来高效地服务长上下文LLMs。
|
||||
|
||||
**大语言模型的上下文窗口迅速增加**，导致不同请求和同一请求的不同阶段之间的资源使用差异巨大。现有的静态并行策略无法有效利用底层资源来处理可变长度的请求。
|
||||
|
||||
弹性序列并行性（ESP），以适应不同请求和阶段的动态变化。基于ESP，设计了LoongServe系统，旨在提高计算效率、通信效率和GPU内存效率。
|
||||
|
||||
ESP动态调整每个迭代的并行度（Degree of Parallelism, DoP），**以适应不同请求和阶段的资源需求**。在预填充阶段，**ESP可以设置较高的DoP以快速处理请求**；**在解码阶段，ESP可以降低DoP以减少通信开销并释放资源。**
|
||||
|
||||
### （四）论文《Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving[4]》
|
||||
|
||||
时间：2024.6月
|
||||
|
||||
https://github.com/kvcache-ai/Mooncake
|
||||
|
||||
https://github.com/vllm-project/vllm/pull/10502
|
||||
|
||||
Mooncake，一种以KVCache为中心的分散化架构，用于大语言模型（LLM）的推理服务。
|
||||
|
||||
这篇文章要解决的问题是如何在LLM服务中，特别是处理长上下文和过载场景时，提高整体有效吞吐量并满足延迟相关的服务水平目标（SLOs）。
|
||||
|
||||
该问题的研究难点包括：如何在过载场景下预测未来的负载并提前拒绝某些请求以节省计算资源；如何有效地分离预填充和解码阶段以提高缓存利用率；如何在保证延迟要求的前提下最大化吞吐量。
|
||||
|
||||
该问题的研究相关工作有：Orca使用迭代级调度以实现各阶段的并发处理；vLLM利用动态KV缓存管理优化内存；FlexGen、SARATHI和FastServe结合创新的调度和交换策略以有效分配工作负载。此外，Splitwise提出了分离预填充和解码阶段的分解架构，DistServe优化了每阶段的资源分配和并行策略，TetraInfer结合了分块预填充和两级分解以及预测的两级调度算法。
|
||||
|
||||
### （五）论文《Speculative Prefill: Turbocharging TTFT with Lightweight and Training-Free Token Importance Estimation[5]》
|
||||
|
||||
时间：2025.2.5日
|
||||
|
||||
SPECPREFILL的框架，旨在通过**轻量级和无需训练**的标记重要性估计来加速大语言模型（LLM）的推理时间。
|
||||
|
||||
这篇文章的研究背景是提高时间到第一个标记（TTFT）在现代大型语言模型（LLM）推理引擎中至关重要。优化TTFT可以直接提高最大每秒查询数（QPS），满足许多关键应用的需求。然而，提升TTFT极具挑战性，因为它是计算受限的，并且性能瓶颈从自注意力转移到了多层感知机（MLP）部分。
|
||||
|
||||
预填充阶段主要是计算受限的，且瓶颈可能会随着提示长度和批量大小的变化而变化；直接优化TTFT会导致自注意力部分向MLP部分转移，从而增加计算复杂度。
|
||||
|
||||
### （六）论文《LServe: Efficient Long-sequence LLM Serving with Unified Sparse Attention[6]》
|
||||
|
||||
时间：2025.2.20日
|
||||
|
||||
LServe的系统，旨在通过混合稀疏注意力机制来高效地服务长序列大型语言模型（LLMs）。该系统通过统一块稀疏注意力框架来加速长序列LLM的预填充和解码阶段。
|
||||
|
||||
**背景：**
|
||||
|
||||
- 长序列LLMs在处理复杂任务时表现出色，但其在预填充和解码阶段的效率问题仍然存在。预填充阶段的注意力计算复杂度为二次，而解码阶段的内存占用较大。
|
||||
- 现有的加速方法主要集中在KV缓存的量化或静态稀疏注意力上，但这些方法在保持长上下文能力方面存在不足。
|
||||
|
||||
**LServe系统**：
|
||||
|
||||
- LServe通过引入混合稀疏注意力机制来解决这些问题。它将不同的硬件友好的结构化稀疏模式统一到一个框架中，通过在块级别跳过不重要的计算来加速注意力计算。
|
||||
- 在预填充阶段，LServe将一半的注意力头转换为几乎免费的流式头，并在解码阶段使用查询为中心的动态稀疏性来优化KV缓存。
|
||||
|
||||
实验表明，LServe在预填充阶段比现有的vLLM系统快2.9倍，在解码阶段平均快1.3到2.1倍，同时保持了长上下文的准确性。
|
||||
|
||||
## 十、vLLM中的PD分离架构
|
||||
|
||||
vLLM的PD分离架构主要由三个组件构成：Proxy API server、vLLM prefill和vLLM decode。以下是它们的工作原理：
|
||||
|
||||
1️⃣ 当请求到来时，首先会进入Proxy API server。Proxy API server会将请求转发给vLLM prefill。
|
||||
|
||||
2️⃣ vLLM prefill负责进行prefill操作，生成kv cache，并将这个缓存转发给vLLM decode。
|
||||
|
||||
3️⃣ Proxy API server继续将请求发送给vLLM decode。vLLM decode会执行drop_select操作，这个操作主要是获取kv和跳过prefill。完成drop_select后，vLLM decode会生成First token。
|
||||
|
||||
4️⃣ vLLM decode阶段也会生成First token。Proxy API server最终获取的所有token都是从vLLM decode获取的。vLLM prefill只负责生成kv cache。
|
||||
|
||||
通过这种方式，vLLM的PD分离架构能够实现高效的请求处理和缓存管理。
|
||||
|
||||
## 参考资料
|
||||
|
||||
> [1] SARATHI: Efficient LLM Inference by Piggybacking Decodes with Chunked Prefills: _https://arxiv.org/pdf/2308.16369v1.pdf_
|
||||
> [2] DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving: _https://arxiv.org/pdf/2401.09670v3.pdf_
|
||||
> [3] LoongServe: Efficiently Serving Long-Context Large Language Models with Elastic Sequence Parallelism: _https://arxiv.org/pdf/2404.09526v2.pdf_
|
||||
> [4] Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving: _https://arxiv.org/pdf/2407.00079v3.pdf_
|
||||
> [5] Speculative Prefill: Turbocharging TTFT with Lightweight and Training-Free Token Importance Estimation: _https://arxiv.org/pdf/2502.02789v2.pdf_
|
||||
> [6] LServe: Efficient Long-sequence LLM Serving with Unified Sparse Attention: _https://arxiv.org/pdf/2502.14866v2.pdf_
|
||||
@@ -0,0 +1,80 @@
|
||||
# 📊 文章摘要：大模型系列：深度解析 Prefill-Decode 分离式部署架构
|
||||
|
||||
> **原文**：[2025-06-17_大模型系列_深度解析_Prefill-Decode_分离式部署架构.md](./2025-06-17_大模型系列_深度解析_Prefill-Decode_分离式部署架构.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/1918334902492963669
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：猫先生
|
||||
> **发布日期**：2025-06-17
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **阶段特化** — 从 Prefill/Decode 两阶段的资源特性差异推导 PD 分离原理，并梳理其论文谱系与通信底座。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 Prefill-Decode 分离式部署的深度科普：先阐明 Prefill 计算密集（compute-bound）与 Decode 内存带宽密集（bandwidth-bound）的本质差异，解释 KV Cache"以存换算"的机理，再介绍 PD 分离原理与 NCCL/NIXL 通信协议，追溯 SARATHI、DistServe、LoongServe、Mooncake、Speculative Prefill、LServe 六篇论文的演进脉络，最后拆解 vLLM 的 Proxy/prefill/decode 三组件架构。价值在于概念讲解透彻、论文谱系完整并附源码链接，是入门 PD 分离的良好综述。局限是无一手实验数据，个别表述不够严谨（如"显存随上下文指数级上升"实为线性增长）。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **两阶段资源特性根本不同** — Prefill 高并行、矩阵乘法为主、计算密集；Decode 逐 token 串行、频繁访问 KV Cache、内存带宽密集，这是 PD 分离的立论基础 `[分类: 共识]`
|
||||
2. **拆分的根本原因** — 输入 prompt 一次性完整提供、适合并行；输出 token 未知、只能逐个串行。KV Cache 复用使 Decode 的 attention 复杂度降低一个量级，实现"以存换算" `[分类: 共识]`
|
||||
3. **混合部署的资源错配** — 请求的 Prefill 长度与 Decode 长度不匹配时，同一 GPU 需同时承担高算力与高带宽需求，难以发挥最佳性能 `[分类: 共识]`
|
||||
4. **通信底座 NCCL 与 NIXL** — NCCL 适合单机/高带宽集群内的 GPU-GPU 通信；NIXL 是面向推理系统的"远程 NCCL"扩展层，专为跨节点 PD 分离的 KV Cache 远程传输设计 `[分类: 共识]`
|
||||
5. **论文谱系六连** — SARATHI（分块预填充+最大解码批处理，2023.8）→ DistServe（PD 解耦与 goodput 优化，2024.1）→ LoongServe（弹性序列并行，2024.4）→ Mooncake（KVCache 中心化分解架构，2024.6）→ Speculative Prefill（TTFT 加速，2025.2）→ LServe（混合稀疏注意力，2025.2） `[分类: 共识]`
|
||||
6. **vLLM 的 PD 分离三组件** — Proxy API server 负责路由，prefill 实例只生成 KV Cache，decode 实例执行 drop_select 获取 KV 并跳过 prefill 直接生成 token `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者已具备 Transformer 与 KV Cache 基础知识；假设 PD 分离收益适用于大规模部署场景，而本文对硬件资源门槛与实施成本着墨不多。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
以论文结论转述为主，出处清晰（六篇论文均附 arxiv 链接），作为综述论据充分；但"显存占用模式随上下文增长指数级上升"与 KV Cache 线性增长的客观事实不符，属表述疏漏，削弱了表格的严谨性。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
仅一般性提及"适用于对时延有严格要求的场景"，未讨论 P/D 配比、传输延迟隐藏、异构硬件等工程边界；对 PD 分离带来的系统复杂度与成本上升几乎未涉及。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "Prefill 和 Decode 阶段不仅在结构上不同，在性能瓶颈上也大相径庭"
|
||||
|
||||
> "LLM生成文本的过程本质上是给定上下文，逐词预测下一个词。但在实现上，这个过程被明确地分成两个阶段"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 概念讲解由浅入深，Prefill/Decode 对比表格清晰直观
|
||||
- 论文谱系（2023.8–2025.2）梳理完整并附代码链接，索引价值高
|
||||
- NCCL/NIXL 通信协议对比实用
|
||||
|
||||
**不足**：
|
||||
- 无一手数据，全部结论为二手转述
|
||||
- 个别技术表述不严谨（显存增长量级）
|
||||
- 缺少 PD 分离局限、成本与适用边界的系统讨论
|
||||
|
||||
**适用场景**：初学者理解 PD 分离原理与演进脉络的入门综述；需要快速检索 PD 分离相关论文谱系的工程师。
|
||||
|
||||
**关联建议**：进阶阅读 DistServe（OSDI 2024）原论文及 Zoe Lee 的精读文章；实践侧阅读 akaihaoshuai 的 9 条实测结论与 vLLM/sglang 部署文档。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,197 @@
|
||||
# 大模型学习 | PD分离详解
|
||||
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：秋月如珪
|
||||
> **发布日期**：2026-02-02
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/2001354095441757984
|
||||
|
||||
---
|
||||
|
||||
## 一、什么是PD分离？
|
||||
|
||||
**PD分离**（Prefill-Decode Disaggregation）是一种将LLM推理过程中的**预填充（Prefill）阶段**与**解码（Decode）阶段**拆分到不同GPU/AI加速器实例上独立执行的架构设计。
|
||||
|
||||
在大模型推理中，一个完整的生成过程天然分为两个特征迥异的阶段：
|
||||
|
||||
**Prefill阶段（计算密集型）**
|
||||
|
||||
- **任务**：并行处理用户输入的整个Prompt（可能长达数千甚至数万token），计算所有token之间的注意力关系，生成**KV Cache**（键值缓存），并输出**第一个token**。
|
||||
- **特征**：计算量大、显存带宽压力相对较小、延迟指标为**TTFT**（Time To First Token，首token延迟，通常要求50-400ms）[1]。
|
||||
- **资源需求**：需要强大的计算能力（FLOPS），适合使用**张量并行（Tensor Parallelism）**加速。
|
||||
|
||||
**Decode阶段（内存密集型）**
|
||||
|
||||
- **任务**：基于Prefill生成的KV Cache，以**自回归方式**逐个生成后续token（每步只生成一个新token，并将其加入KV Cache继续下一步）。
|
||||
- **特征**：计算量小，但**显存带宽消耗极高**（频繁读取完整的KV Cache），延迟指标为**TPOT/TBT**（Time Per Output Token/Token Between Token，通常要求25-55ms）。
|
||||
- **资源需求**：需要高显存带宽和大容量显存，适合使用**数据并行（Data Parallelism）**提升吞吐。
|
||||
|
||||
传统的**Continuous Batching**将两个阶段混合在同一GPU上处理，导致资源竞争和相互干扰。PD分离通过**硬件解耦**，让两个阶段各自运行在最适合的硬件配置和优化策略下。
|
||||
|
||||
---
|
||||
|
||||
## 二、为什么需要PD分离？
|
||||
|
||||
### 1. 混合部署的资源冲突
|
||||
|
||||
当Prefill和Decode在同一个GPU上混合执行时会发生：
|
||||
|
||||
- **计算资源争抢**：Prefill的高计算需求会抢占Decode的执行时间，导致TPOT（token间延迟）抖动。
|
||||
- **显存压力叠加**：Prefill需要临时缓存大量中间结果，Decode需要常驻整个KV Cache，两者叠加容易导致OOM（显存溢出）。
|
||||
- **Batching策略冲突**：Prefill适合**小batch**（计算饱和后增加batch只会延长延迟），而Decode适合**大batch**（提升显存带宽利用率）。混合部署无法在两种策略间取得最优平衡。
|
||||
|
||||
### 2. SLO（服务等级目标）难以同时满足
|
||||
|
||||
实验数据显示：在单张A100上运行13B参数模型，当请求速率增加时：
|
||||
|
||||
- TTFT约束（0.4秒）可支持约**3 RPS**（每秒请求数）
|
||||
- TPOT约束（0.04秒）仅能支持约**1.6 RPS**
|
||||
|
||||
系统的**Goodput**（有效吞吐）由两者最小值决定，即**1.6 RPS/GPU**。混合部署存在明显的性能天花板。
|
||||
|
||||
### 3. 硬件资源浪费
|
||||
|
||||
Prefill阶段GPU计算单元满载但显存带宽闲置；Decode阶段显存带宽饱和但计算单元空闲。混合部署导致两种资源都无法充分利用。
|
||||
|
||||
---
|
||||
|
||||
## 三、PD分离的核心架构
|
||||
|
||||
### 基础工作流程
|
||||
|
||||
```
|
||||
请求 → [Prefill Worker: GPU集群A] → KV Cache传输 → [Decode Worker: GPU集群B] → 流式输出
|
||||
```
|
||||
|
||||
1. **请求路由**：新请求首先被路由到Prefill Worker，执行完整的Prompt计算，生成KV Cache和首个token。
|
||||
2. **状态迁移**：系统将KV Cache从Prefill Worker传输到Decode Worker（这是PD分离的核心技术挑战）。
|
||||
3. **解码生成**：Decode Worker加载KV Cache，持续执行自回归解码，直到生成结束符（EOS）或达到最大长度。
|
||||
|
||||
### 资源分配优势
|
||||
|
||||
通过分离，系统可以独立优化两个阶段：
|
||||
|
||||
- **Prefill集群**：配置高算力GPU（如A100/H100），采用张量并行降低TTFT。
|
||||
- **Decode集群**：配置高显存带宽GPU，采用大batch和数据并行提升吞吐。
|
||||
|
||||
实验表明，简单的**2P1D配置**（2个Prefill GPU + 1个Decode GPU）即可将Goodput提升至**3.3 RPS/GPU**，相比混合部署提升约**2倍**。
|
||||
|
||||
---
|
||||
|
||||
## 四、关键技术挑战与优化
|
||||
|
||||
### 1. KV Cache传输机制
|
||||
|
||||
Prefill完成后，需要将庞大的KV Cache（可能达数十GB）传输到Decode节点。传输粒度分为三级：
|
||||
|
||||
| 粒度 | 机制 | 优点 | 缺点 |
|
||||
| --- | --- | --- | --- |
|
||||
| 请求级 | Prefill完成后一次性传输全部KV Cache | 传输次数少，开销低 | 大Prompt时传输延迟高，影响TTFT |
|
||||
| 层级 | 每计算完一层Transformer，立即异步传输该层KV Cache，同时计算下一层 | 传输与计算重叠，延迟隐藏效果好；可提前启动Decode | 小Prompt场景下同步开销可能超过收益（Splitwise方案） |
|
||||
| 块级 | 将Prompt分块处理，逐块传输 | 保持GPU计算饱和状态 | 实现复杂度高（TetriInfer方案） |
|
||||
|
||||
### 2. 高性能传输协议
|
||||
|
||||
为降低KV Cache传输延迟，业界开发了多种专用Connector：
|
||||
|
||||
- **SharedStorageConnector**：通过共享文件系统（NFS/本地磁盘）传递，实现简单但延迟高（毫秒级），适合测试环境。
|
||||
- **P2pNcclConnector**：基于NVIDIA NCCL实现GPU间点对点直接传输，绕过CPU内存，延迟最低。
|
||||
- **NixlConnector**：使用NVIDIA NIXL（Inference Xfer Library）库，支持GPU与异构内存（CPU DRAM、SSD）间的高速传输，实现分层KV缓存。
|
||||
- **LMCacheConnector**：支持将KV Cache卸载到远程存储（Redis、InfiniStore），实现跨请求、跨会话的KV Cache复用。
|
||||
|
||||
### 3. 独立Batching策略
|
||||
|
||||
- **Prefill侧**：保持**小batch size**（通常1-4个请求）。因为Prompt较长时，GPU计算已饱和，增加batch只会线性增加TTFT而不提升吞吐。
|
||||
- **Decode侧**：采用**大batch size**（可达64-128个请求）。因为Decode是显存带宽瓶颈，增大batch能提升计算强度（arithmetic intensity），显著提高吞吐。
|
||||
|
||||
### 4. 差异化并行策略
|
||||
|
||||
- **Prefill**：采用**张量并行（TP）**将模型层内部分割到多GPU，降低单层计算延迟，满足严格TTFT要求。
|
||||
- **Decode**：采用**流水线并行（PP）**或**数据并行（DP）**，因为Decode对延迟相对不敏感，更适合通过并行提升整体吞吐。
|
||||
|
||||
---
|
||||
|
||||
## 五、工业界实践案例
|
||||
|
||||
### 1. NVIDIA Dynamo
|
||||
|
||||
Dynamo是NVIDIA开源的推理框架，提供完整的PD分离解决方案：
|
||||
|
||||
- **Dynamo Planner**：智能监控TTFT和TPOT，动态决策是否启用PD分离及资源配比。
|
||||
- **Smart Router**：KV Cache感知的请求路由，最大化缓存命中率。
|
||||
- **NIXL库**：专为大模型推理设计的高性能传输库，支持毫秒级大批量KV Cache跨节点传输。
|
||||
|
||||
部署示例（Kubernetes）：
|
||||
|
||||
```yaml
|
||||
apiVersion: nvidia.com/v1alpha1
|
||||
kind: DynamoGraphDeployment
|
||||
spec:
|
||||
services:
|
||||
VllmPrefillWorker:
|
||||
replicas: 2 # 2个Prefill实例
|
||||
VllmDecodeWorker:
|
||||
replicas: 1 # 1个Decode实例
|
||||
```
|
||||
|
||||
### 2. vLLM开源实现
|
||||
|
||||
vLLM在V1版本中引入了**KVConnector**抽象层，统一支持多种传输后端：
|
||||
|
||||
- **MultiConnector**：可同时向多个存储后端（本地+远程）写入KV Cache，提供数据冗余。
|
||||
- **Disaggregated Serving**：与Mooncake Store、LMCache集成，支持生产级PD分离部署。
|
||||
|
||||
### 3. llm-d（Kubernetes原生方案）
|
||||
|
||||
由IBM等贡献的llm-d项目，将PD分离与K8s深度集成：
|
||||
|
||||
- 基于**Inference Gateway**实现智能负载均衡。
|
||||
- 支持通过**NIXL**进行P/D实例通信。
|
||||
- 提供声明式API定义PD分离拓扑。
|
||||
|
||||
### 4. Mooncake（Kimi的推理平台）
|
||||
|
||||
Mooncake是最早大规模应用PD分离的工业级系统之一：
|
||||
|
||||
- **架构**：以KV Cache为中心的解耦架构，独立部署Prefill集群与Decode集群。
|
||||
- **创新**：利用集群空闲的CPU、DRAM和SSD资源，构建**分层KV Cache缓存池**。
|
||||
- **效果**：在长上下文场景中，吞吐量相比基线提升最高达**525%**；真实负载下可多处理**75%**的请求。
|
||||
|
||||
---
|
||||
|
||||
## 六、PD分离的适用场景与局限
|
||||
|
||||
### 最佳适用场景
|
||||
|
||||
1. **高并发在线服务**：当需要同时满足严格TTFT（用户体验）和TPOT（流式输出流畅度）时，PD分离几乎是目前唯一选择。
|
||||
2. **长上下文处理**：Prompt长度差异大（如RAG场景），PD分离可避免长Prefill阻塞短Decode。
|
||||
3. **成本敏感场景**：通过为不同阶段配置不同规格GPU（如Prefill用H100，Decode用L40S），显著降低推理成本。
|
||||
|
||||
### 局限与替代方案
|
||||
|
||||
- **overhead**：KV Cache传输引入额外延迟（虽然可通过层级传输隐藏）。
|
||||
- **系统复杂度**：需要维护两套集群、处理状态同步和故障恢复。
|
||||
- **替代方案**：对于延迟要求不极端的场景，**Chunked-Prefills**（将长Prompt分块与Decode交替执行）是更简单的折中方案。
|
||||
|
||||
---
|
||||
|
||||
## 七、总结
|
||||
|
||||
PD分离代表了LLM推理架构从**统一处理**向**阶段特化**演进的重要趋势。通过识别Prefill（计算密集）和Decode（内存密集）的本质差异，该架构打破了传统部署的性能瓶颈，实现了：
|
||||
|
||||
- **干扰隔离**：两个阶段独立运行，互不影响。
|
||||
- **资源最优**：针对不同阶段配置最适合的硬件和并行策略。
|
||||
- **吞吐飞跃**：Goodput可提升2-5倍，同时满足延迟SLO。
|
||||
|
||||
随着长文本（128K+）和多模态大模型的普及，推理负载的异构性将进一步加剧。PD分离不仅是当前的技术热点，更可能成为下一代大模型服务（如GPT-5、Claude 4）的**默认部署范式**。对于需要构建高性能LLM服务的企业和开发者，深入理解并应用PD分离架构已成为必备技能。
|
||||
|
||||
---
|
||||
|
||||
| 指标类型 | 测量对象 | 量级 | 典型场景 |
|
||||
| --- | --- | --- | --- |
|
||||
| 数据中心网络延迟 | 节点间数据包传输时间 | 微秒级 (μs) | GPU间RDMA通信、NVLink传输 |
|
||||
| TTFT (Time To First Token)，首token延迟 | 从请求发起到首个token生成的完整时间 | 毫秒级 (ms) | 用户感知的首字响应时间 |
|
||||
| TPOT (Time Per Output Token)或TBT（Token Between Token），token间延迟 | 每生成一个token的完整计算时间 | 毫秒级 (ms) | 用户感知的流式输出速度 |
|
||||
|
||||
## 参考
|
||||
|
||||
1. ^一些关键延迟和量级见上面的表格（没搞明白怎么把表格插注释里只能这样……）
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：大模型学习 | PD分离详解
|
||||
|
||||
> **原文**：[2026-02-02_大模型学习_PD分离详解.md](./2026-02-02_大模型学习_PD分离详解.md)
|
||||
> **原文链接**：https://zhuanlan.zhihu.com/p/2001354095441757984
|
||||
> **来源**：知乎专栏
|
||||
> **作者**：秋月如珪
|
||||
> **发布日期**：2026-02-02
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **阶段解耦** — 系统讲解 PD 分离的动机、传输机制与工业实践，并给出明确的适用边界与替代方案。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文系统讲解 PD 分离：从混合部署的计算争抢、显存叠加、batching 冲突说明动机，用 A100/13B 的 SLO 数据（TTFT 约束约 3 RPS、TPOT 约束约 1.6 RPS）说明 Goodput 由双指标最小值决定；随后展开 KV Cache 三级传输粒度（请求级/层级/块级）、四种传输 Connector、独立 batching 与差异化并行策略，并对比 Dynamo、vLLM、llm-d、Mooncake 四大工业实践。价值在于结构完整、决策导向，且专门讨论了局限与 Chunked-Prefills 折中方案。局限是多数数据未标注来源，对未来"默认部署范式"的预测偏乐观。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **混合部署三类冲突** — 计算资源争抢致 TPOT 抖动、Prefill 中间结果与 KV Cache 显存叠加易 OOM、batching 策略冲突（Prefill 适合小 batch，Decode 适合大 batch）`[分类: 共识]`
|
||||
2. **Goodput 由双 SLO 的较紧者决定** — A100/13B 下 TTFT（0.4s）可支持约 3 RPS、TPOT（0.04s）仅约 1.6 RPS；2P1D 配置可将 Goodput 提升至 3.3 RPS/GPU，约 2 倍 `[分类: 共识]`
|
||||
3. **KV Cache 传输三级粒度** — 请求级实现简单但大 prompt 传输延迟高；层级可传输计算重叠、提前启动 Decode，但小 prompt 场景同步开销可能超过收益（Splitwise）；块级保持 GPU 计算饱和但实现复杂度高（TetriInfer）`[分类: 共识]`
|
||||
4. **独立 batching 策略** — Prefill 保持小 batch（1-4 请求）避免线性增加 TTFT；Decode 采用大 batch（64-128）提升计算强度与带宽利用率 `[分类: 共识]`
|
||||
5. **差异化并行** — Prefill 用张量并行满足严格 TTFT，Decode 用流水线/数据并行提升吞吐 `[分类: 共识]`
|
||||
6. **工业界四案例** — Dynamo（Planner 动态决策 + Smart Router 缓存感知路由 + NIXL）、vLLM V1（KVConnector 抽象 + MultiConnector 冗余）、llm-d（K8s 原生 + Inference Gateway）、Mooncake（分层 KV Cache 池，长上下文吞吐最高提升 525%）`[分类: 共识]`
|
||||
7. **明确局限与替代方案** — KV 传输 overhead、双集群状态同步与故障恢复复杂度；延迟要求不极端的场景 Chunked-Prefills 是更简单的折中 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
假设读者关注高性能 LLM 服务的生产级部署；假设 TTFT/TPOT 双 SLO 是服务首要优化目标；假设两阶段硬件解耦的成本可控。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
SLO 数据直观且有推导逻辑（Goodput 取两者最小值），但未标注出处（疑似来自 DistServe 论文），削弱了可信度；Mooncake 的 525% 与 75% 数据有论文支撑，其余性能数字（如 2 倍 Goodput 提升）缺乏来源。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
作者专门列出局限与替代方案，边界意识较好；但"PD 分离可能成为下一代大模型服务的默认部署范式"属个人预测，缺乏论证，与 akaihaoshuai 实测中"普通场景没必要折腾"的结论存在张力。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "系统的Goodput（有效吞吐）由两者最小值决定，即1.6 RPS/GPU。"
|
||||
|
||||
> "PD分离代表了LLM推理架构从统一处理向阶段特化演进的重要趋势。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 知识结构完整（动机→机制→协议→实践→边界），传输粒度三级表格与 Connector 对比实用
|
||||
- 有独立的"局限与替代方案"章节，Chunked-Prefills 折中建议实操性强
|
||||
- 四大工业实践（Dynamo/vLLM/llm-d/Mooncake）覆盖了当前主流方案
|
||||
|
||||
**不足**：
|
||||
- 关键性能数据缺出处，需溯源验证
|
||||
- 个别技术细节与来源论文混编（如 Splitwise、TetriInfer 方案名）
|
||||
- "默认部署范式"等预测性论断缺乏论证支撑
|
||||
|
||||
**适用场景**：需要系统建立 PD 分离知识框架的工程师与学习者；PD 分离方案调研与技术汇报的材料底稿。
|
||||
|
||||
**关联建议**：数据溯源阅读 DistServe 论文原文；实践侧对照 akaihaoshuai 的实测阈值与极客博哥的架构决策清单；跟进 vLLM Disaggregated Serving 与 Dynamo 官方文档。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,377 @@
|
||||
# PD 分离推理架构详解
|
||||
|
||||
> **来源**：腾讯云开发者社区
|
||||
> **作者**：cr7258
|
||||
> **发布日期**：2025-09-21
|
||||
> **原文链接**：https://cloud.tencent.com/developer/article/2586469
|
||||
|
||||
---
|
||||
|
||||
PD 分离推理架构的讲解视频可以在这里观看：https://www.bilibili.com/video/BV1ZTWAzmEEc
|
||||
|
||||
本文是 LLM 推理系列的第 6 篇，介绍 PD 分离推理架构
|
||||
|
||||
在大语言模型推理过程中，prefill 阶段和 decode 阶段具有截然不同的计算特性：
|
||||
|
||||
- prefill 阶段需要并行处理整个输入序列来生成首个 token，属于计算密集型操作。
|
||||
- decode 阶段则逐个生成后续 token，需要频繁访问 KV cache，属于内存密集型操作。
|
||||
|
||||
传统的 continuous batching 将两个阶段混合处理，导致相互干扰，难以同时满足 TTFT（首 token 延迟）和 TPOT（token 间延迟）的严格要求。为了解决这一问题，PD 分离架构应运而生，通过将 prefill 和 decode 分配到不同的 GPU 实例上，针对各自特性进行专门优化。这种分离式设计不仅消除了阶段间的干扰，还能显著提升系统的有效吞吐量（Goodput），为大规模 LLM 服务提供了更优的解决方案。
|
||||
|
||||
### 1 吞吐量（Throughput）vs 有效吞吐量（Goodput）
|
||||
|
||||
目前，大多数 LLM 服务系统（如 vLLM、TensorRT-LLM）都以吞吐量（Throughput） 作为主要性能指标——即单位时间内处理的请求数（RPS）或生成的 token 数。这种度量方式直观，并且与成本（$/req）有直接关联，因此被广泛采用。
|
||||
|
||||
实际上，下游应用的类型多种多样，它们在用户体验上的延迟需求各异，因此需要满足的服务等级目标（SLO）也存在显著差异。大模型服务中最常用的 SLO 包括：
|
||||
|
||||
- TTFT (Time To First Token)：首 token 响应延迟，直接影响用户的等待体验。
|
||||
- TPOT (Time Per Output Token)：衡量两个连续生成的 token 之间的平均延迟，决定交互的流畅程度。
|
||||
|
||||
例如，实时聊天机器人更关注低 TTFT 以保证响应及时，而 TPOT 只需快于人类阅读速度（约 250 词/分钟）即可；相反，文档摘要则更强调低 TPOT，以便更快地产生完整摘要。
|
||||
|
||||
单纯依赖 Throughput 作为指标，并不能反映延迟表现，系统看似处理了大量请求，但其中不少未能满足 SLO，最终呈现给用户的仍是不理想的服务体验。
|
||||
|
||||
- **Throughput（吞吐量）**：通常指系统单位时间内处理的 token 数或请求数。很多工作把"提高吞吐量"作为主要优化目标，但在实际场景下，这并不直接代表用户体验。
|
||||
- **Goodput（有效吞吐量）**：指系统在满足延迟约束（如 TTFT/TPOT SLO）的前提下，真正完成的请求数量。如果一个请求因为延迟过长而被用户放弃，或者超过服务约束而无效，那么即便它产生了 token，也不能算作有效产出。
|
||||
|
||||
在 DistServe 论文中，引入了 Goodput 概念，**即在满足 SLO（TTFT 和 TPOT 要求）的前提下，每秒完成的有效请求数**。与单纯的吞吐量相比，Goodput 是更优的衡量指标，**因为它能够体现请求在满足 SLO 情况下的吞吐水平**，从而同时反映成本效益与服务质量。
|
||||
|
||||
为了简要说明 Goodput，假设某个应用要求至少 90% 的请求满足 TTFT < 200ms 且 TPOT < 50ms，则可以得到如下定义：
|
||||
|
||||
> Goodput (P90 TTFT < 200ms 且 P90 TPOT < 50ms) 表示在至少 90% 的请求同时满足 TTFT < 200ms 和 TPOT < 50ms 的条件下，系统所能维持的最大每秒请求数。
|
||||
|
||||
下图展示了一个简单的例子：某应用的吞吐量为 10 RPS（每秒请求数），但由于延迟约束的限制，只有 3 RPS 的请求满足 SLO，因此该系统的 Goodput 仅为 3 RPS。可以想象，用户在这样一个 高吞吐但低 Goodput 的系统中，依然会感觉到较差的服务体验。
|
||||
|
||||
### 2 Prefill 与 Decode 共置导致干扰
|
||||
|
||||
在 LLM 服务中请求的生命周期通常包含两个阶段：prefill（生成首个 token）和 decode（逐步生成后续 token）。大多数现有系统（如 vLLM、TensorRT-LLM）采用 continuous batching 技术，将 prefill 和 decode 混合在一起统一批处理。这种方式确实能够提升整体吞吐量，但由于两者计算特性和 SLO 目标差异显著，将它们共置在同一 GPU 上往往并不理想。
|
||||
|
||||
continuous batching 会带来明显的干扰。**当 prefill 和 decode 被放在同一批次时，decode 请求的延迟（TPOT）会被显著拉长，而 prefill 请求的首 token 延迟（TTFT）也会有所增加。**
|
||||
|
||||
图中展示了三种不同的执行方式：
|
||||
|
||||
- 1P+nD（棕色柱子）：1 个 prefill 与 n 个 decode 混合批处理。
|
||||
- nD（蓝色柱子）：仅包含 decode 请求的批处理。
|
||||
- prefill-only（红色虚线）：仅运行 prefill 请求的延迟。
|
||||
|
||||
**在 prompt 长度为 128 时，相比仅包含 decode 的请求，延迟增加约 1.8 倍；而当 prompt 长度为 1024 时，干扰效应显著放大，decode 延迟提升至 12.6 倍。**
|
||||
|
||||
由于这种干扰，当服务必须同时满足 TTFT 和 TPOT 的 SLO 时，**系统往往需要进行资源的过度配置才能达到延迟目标**，尤其是在任一 SLO 要求较严格的情况下。
|
||||
|
||||
### 3 PD 分离的整体思路
|
||||
|
||||
直观的思路很简单：将 prefill 和 decode 分离到不同的 GPU 上，并为每个阶段定制并行策略。这自然解决了前面提到的两个问题：
|
||||
|
||||
- **没有干扰**：prefill 和 decode 各自独立运行，更快地完成计算，也更容易满足各自的 SLO。
|
||||
- **资源分配与并行策略解耦**：可以针对 prefill 和 decode 分别进行优化。
|
||||
|
||||
当一个请求到达系统时，它会先被分配到 prefill worker 完成 prefill 阶段；随后系统将其中间状态（主要是 KV Cache）迁移到 decode worker，并执行多步 decode 以生成后续 token；当生成完成后，请求才会离开系统。
|
||||
|
||||
让我们通过一个简单的实验来看看为什么 PD 分离是有益的。我们在一张 A100-80GB GPU 上运行一个 130 亿参数的 LLM，请求到达服从泊松分布，输入长度为 512，输出长度为 64。我们逐步增加请求速率（x 轴），并在下图测量两类延迟（P90 TTFT 和 P90 TPOT，y 轴）的变化。
|
||||
|
||||
假设我们设定 SLO：P90 TTFT = 0.4 秒，P90 TPOT = 0.04 秒（下图中的横线）。实验结果表明：在单卡情况下，现有系统大约可以在 3 rps 下满足 TTFT 的延迟约束，而 TPOT 只能维持在 1.6 rps（下图左边）。由于必须同时满足两个约束条件，现有共置系统的 Goodput = min(3, 1.6) = 1.6 rps/GPU。
|
||||
|
||||
在分离之后，性能得到了显著提升。如果单独处理一个阶段，prefill worker 和 decode worker 的 rps 都优于之前的结果 —— 如下图右边所示，一个 prefill worker 大约可达到 5.6 rps，一个 decode worker 大约可达到 10 rps。更重要的是，我们现在可以灵活地分配资源，例如配置 2 个 prefill worker + 1 个 decode worker（记作 2P1D），共 3 张 GPU。此时：
|
||||
|
||||
```
|
||||
Goodput (2P1D) = min(5.6 × 2, 10) = 10 reqs/s ÷ 3 GPUs ≈ 3.3 rps/GPU。
|
||||
```
|
||||
|
||||
这个实验表明，即便没有引入任何并行优化，仅仅通过简单的分离，Goodput 就提升了约 2 倍。
|
||||
|
||||
### 4 分离式推理架构的优化方向
|
||||
|
||||
#### 4.1 算力与存储
|
||||
|
||||
- prefill 阶段：拥有计算受限的性质（compute-bound），特别是在请求流量较大，用户的 prompt 也比较长的情况下。prefill 阶段算完 KV cache 并发给 decode 阶段后，理论上 prefill 就不再需要这个 KV cache 了（当然你也可以采用 LRU 等策略对 KV cache 的保存做管理，而不是一股脑地清除）。
|
||||
- decode 阶段：拥有内存受限的性质（memory-bound），因为逐个 token 的生成方式，decode 阶段要频繁从内存中读取 KV Cache，同时也意味着它需要尽可能保存 KV cache。
|
||||
|
||||
因此在分离式框架下，计算和存储可以朝着两个独立的方向做优化。
|
||||
|
||||
#### 4.2 Batching 策略
|
||||
|
||||
- prefill 阶段：随着 batch size 的增加，吞吐量的提升很快趋于平缓。这是因为 prefill 属于 compute-bound，当 batch 中的总 tokens 数超过一定规模后，GPU 的计算能力已经被完全吃满，再增加请求只会延长整体处理时间，而不会带来明显的吞吐提升。
|
||||
- decode 阶段：随着 batch size 的增加，吞吐量的增长趋势越来越显著。这是因为 decode 阶段是 memory-bound，即相比于计算，读写数据的时间要更多。所以在 decode 阶段中，如果我们能提升 batch size，就能把计算强度提起来，吞吐量就上去了。
|
||||
|
||||
在分离架构下，我们可以针对 prefill 和 decode 的特性对 batching 策略分别进行优化：
|
||||
|
||||
- 具体来说，对于 prefill 实例，需要事先结合特定的 LLM 和 GPU 做性能分析，找出输入长度的临界点——一旦超过这个点，prefill 就会进入 compute-bound，此时增加 batch size 只会拖慢整体处理速度。在实际应用中，用户的 prompt 往往已有数百个 tokens，因此 **prefill 的 batch size 通常保持较小**。
|
||||
- **相对地，decode 阶段更适合采用较大的 batch size，以充分提升 GPU 利用率和整体吞吐。**
|
||||
|
||||
#### 4.3 并行策略
|
||||
|
||||
由于 prefill 和 decode 具有不同的计算模式和延迟目标，这两个阶段的最佳并行策略通常并不相同。例如，当 TTFT 要求严格而 TPOT 要求相对宽松时，prefill 更适合采用**张量并行**来满足低延迟，而 decode 则通常采用**数据并行**或**流水线**并行来提升吞吐。
|
||||
|
||||
### 5 KV Cache 传输
|
||||
|
||||
PD 分离带来的代价是需要在 prefill 和 decode 的 GPU 之间传输中间状态（即 KV cache）。接下来，我们来看看 KV cache 传输的开销分析、传输方式以及相关的优化策略。
|
||||
|
||||
#### 5.1 KV Cache 传输开销
|
||||
|
||||
初看之下，KV cache 是 LLM 推理中巨大的内存开销，而 GPU 之间 KV cache 的传输似乎会成为瓶颈。然而，DistServe 的论文中展示了相反的结果：通过合理的放置，KV Cache 的传输开销可以被有效地最小化，甚至低于一次 decode 步骤的时间，这得益于当今高速互联网络（如 NVLink 和 PCI-e 5.0）。
|
||||
|
||||
假设我们在 GPU 之间使用 8 通道 PCIe 5.0 x16（每条链路 64GB/s）作为节点内互联。对于一个包含 2048 tokens 的请求，在服务 OPT-175B 时传输 KV cache 的延迟可以估算如下：
|
||||
|
||||
```
|
||||
Latency = 2048 tokens * (4.5 MB/token) / (64GB/s * 8) = 17.6 ms
|
||||
```
|
||||
|
||||
对于 OPT-175B，延迟小于单次 decode 步骤（在 A100 上约为 30-50 毫秒）。对于更大的模型、更长的序列或更先进的网络（例如带宽为 600GB/s 的 A100-NVLink），与单次 decode 步骤相比，KV cache 传输相关的相对开销变得不那么显著。总之，通过精心安排 prefill 和 decode 工作节点以利用高带宽网络，可以有效隐藏 KV cache 传输的开销。
|
||||
|
||||
#### 5.2 KV Cache 传输方式
|
||||
|
||||
目前 KV cache 的传输主要有两种方式：**中心存储**和**点对点（P2P）**，当然在实际系统中也可能采用二者结合的混合方案。
|
||||
|
||||
- **中心存储**：建立一个跨设备的 KV store，由它统一管理 KV cache 的增、删、查和传递等操作。prefill 和 decode 实例只需与这个 KV store 交互，负责写入或读取数据。
|
||||
- **P2P 传输**：每个实例独立管理自己的存储。例如，一个 prefill 实例完成计算后，会直接与目标 decode 实例建立通信，将 KV cache 传过去，不依赖统一的中介。
|
||||
|
||||
两种方式各有优劣：
|
||||
|
||||
- **中心存储**：更适合构建大规模集群，能充分利用多种存储介质和传输通道，并提升计算结果的复用效率，但在某些场景下性能可能受限，同时系统维护成本较高。
|
||||
- **P2P 传输**：架构更简单，性能表现通常更好，但在扩展性和链路稳定性方面会面临挑战。
|
||||
|
||||
#### 5.3 KV Cache 传输的网络堆栈
|
||||
|
||||
现有的物理数据链路可以分为 3 类：
|
||||
|
||||
- **Direct**，即 GPU 之间通过高速直连链路（如 NVLink 或 HCCS）相互连接。在这种情况下，可以利用底层的内存拷贝原语或集体通信库来完成数据传输。
|
||||
- **Direct-NIC**，即 GPU 通过其配套的网卡（NIC）进行通信。在这里，可以使用定制化的库，通过 PCIe 和以太网（或 InfiniBand）进行数据传输。
|
||||
- **Indirect**，即当 GPU 之间没有直接链路时，必须通过其 CPU 的 DRAM 中转数据，从而带来额外的内存拷贝开销。
|
||||
|
||||
图片来源：Inference without Interference: Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
|
||||
#### 5.4 KV Cache 传输粒度
|
||||
|
||||
KV cache 传输粒度可以分为 3 类：
|
||||
|
||||
- **请求级**：等到 prefill 阶段完成后，将 KV cache 一次性传输。这种方式的好处是能够减少网络传输次数，因为每次传输的数据量更大，从而降低了通信开销。然而当 KV cache 大小较大时，会影响 TTFT 的延迟。
|
||||
- **层级**：Splitwise 通过在 prefill 阶段的计算与 KV cache 传输之间实现重叠来优化性能。**每一层计算完成后，都会异步传输该层的 KV cache，同时继续执行下一层的计算，从而降低传输开销。**层级传输还能带来额外优势，例如更早启动 decode 阶段，以及更早释放 prefill 端的内存。层级 KV cache 传输与下一层的 prefill 计算并行进行，这需要逐层的细粒度同步以确保正确性，因此可能会带来性能干扰并增加 TTFT，尤其是在小 prompt 的场景下。不过对于小 prompt 来说，KV cache 的总体规模很小，不需要层级传输来隐藏延迟。由于在计算开始时批次中的 token 数已是已知的，**Splitwise 会选择最合适的 KV cache 传输方式：小 prompt 使用序列化传输，而大 prompt 使用层级传输。**
|
||||
|
||||
图片来源：Splitwise: Efficient Generative LLM Inference Using Phase Splitting
|
||||
|
||||
- **块级**：TetriInfer 在 PD 分离的基础上，还会将输入的 prompt 划分为固定大小的 chunk，以便让 GPU 始终运行在接近计算饱和的状态。因此，TetriInfer 论文中也提出了基于块级的 KV cache 传输方案。
|
||||
|
||||
### 6 vLLM 的 PD 分离
|
||||
|
||||
vLLM 提供了 **KV Connector** 作为管理实例间 KV cache 交换的抽象层，它提供统一接口来实现 KV cache 的保存、加载与传输，使不同的 vLLM 实例（如 prefill 与 decode 实例）能够高效共享计算结果。通过实现这一接口，各类 connector（例如通过文件系统的 SharedStorageConnector、通过网络的 NixlConnector 等）提供了灵活的 KV cache 传输方案，从而支持 PD 分离等高级功能。
|
||||
|
||||
`KVConnectorBase_V1` 是所有 connector 的基类。它是一个抽象基类，定义了以下 API：
|
||||
|
||||
- scheduler 侧方法：
|
||||
- build_connector_meta：构建元数据，scheduler 告诉 worker 需要保持/加载哪些 KV cache。
|
||||
- get_num_new_matched_tokens：获取远端已计算的 KV cache 的 token 数量。
|
||||
- update_state_after_alloc：block 开辟后，更新 connector 的状态。
|
||||
- worker 侧方法：
|
||||
- **start_load_kv**：从 connector buffer 加载 KV cache，消费端调用。
|
||||
- wait_for_layer_load：阻塞直到指定层加载结束，消费端调用；
|
||||
- **save_kv_layer**：将 vLLM 的 KV buffer 中某一层的 KV cache 保存到 connector buffer 中，生产端调用。
|
||||
- wait_for_save：阻塞直到所有保存操作完成，生产端调用。
|
||||
|
||||
vLLM v1 中 connector 有两个执行角色（Role）：scheduler_connector 和 worker_connector，分别在 scheduler 线程和 worker 线程中执行。**scheduler 负责指挥 worker 进行 KV cache 的传递，两者之间的信息桥梁是元数据（KVConnectorMetadata），worker 通过 metadata 知道哪些 KV 值需要从远端加载。**
|
||||
|
||||
当前 vLLM 支持 5 种类型的 connector，分别是：
|
||||
|
||||
- **SharedStorageConnector**：SharedStorageConnector 是 vLLM 中最简单的 KV Connector 实现，它通过共享文件系统（如本地磁盘或 NFS）在 prefill 和 decode 实例之间传递 KV cache，使用 MD5 哈希生成唯一文件名来存储和检索每个请求的 KV cache。prefill 实例将每层的 KV cache 序列化为 SafeTensors 格式保存到指定路径，decode 实例根据相同的 token_ids 计算哈希值找到对应文件并加载，整个过程没有显式的网络传输，完全依赖文件系统的读写操作。
|
||||
- **P2pNcclConnector**：P2pNcclConnector 是基于 NCCL（NVIDIA Collective Communications Library）实现的高性能 KV Connector，它通过 NCCL 的 send/recv 原语实现 KV cache 在不同 GPU 之间的点对点传输，避免了文件系统的开销。
|
||||
- **NixlConnector**：NixlConnector 使用 NIXL（NVIDIA Inference Xfer Library）库来加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。
|
||||
- **LMCacheConnectorV1**：通过与 LMCache 集成实现 KV cache 的外部存储和检索，支持多种存储后端（如 CPU 内存、本地文件系统、Redis、 InfiniStore 等）。LMCache 通过重用缓存的 KV cache 来减少推理时间，消除冗余计算，适用于跨请求或跨会话的 KV cache 共享场景。
|
||||
- **MultiConnector**：允许同时使用多个 KV connector 来实现 KV cache 的传输，它的核心逻辑是从第一个能提供可用 token 的 connector 加载 KV cache，但会向所有 connector 保存数据。MultiConnector 适用于需要同时向多个存储后端保存 KV cache 的场景，比如同时保存到本地存储和远程存储，提供数据冗余和可靠性保障。
|
||||
|
||||
```
|
||||
--kv-transfer-config '{
|
||||
"kv_connector": "MultiConnector",
|
||||
"kv_connector_extra_config": {
|
||||
"connectors": [
|
||||
{
|
||||
"kv_connector": "NixlConnector",
|
||||
"kv_role": "kv_both"
|
||||
},
|
||||
{
|
||||
"kv_connector": "SharedStorageConnector",
|
||||
"kv_connector_extra_config": {
|
||||
"shared_storage_path": "local_storage"
|
||||
},
|
||||
"kv_role": "kv_both"
|
||||
}
|
||||
]
|
||||
},
|
||||
"kv_role": "kv_both"
|
||||
}'
|
||||
```
|
||||
|
||||
以上几个 connector 的运行实例代码可以在这里找到：https://docs.vllm.ai/en/latest/features/disagg_prefill.html#usage-example
|
||||
|
||||
### 7 PD 分离工业界项目
|
||||
|
||||
#### 7.1 Mooncake
|
||||
|
||||
Mooncake 是 Moonshot AI 提供的领先大模型服务 Kimi 的推理平台。Mooncake 是 PD 分离应用比较早也是规模比较大的成功例子：
|
||||
|
||||
- Mooncake 采用了以 KV cache 为核心的解耦架构，将 prefill 集群与 decode 集群分离。
|
||||
- 同时，它还利用 GPU 集群中未被充分利用的 CPU、DRAM 和 SSD 资源，实现了解耦式的 KV cache 缓存。
|
||||
- Mooncake 的核心是一个以 KV cache 为中心的调度器，它在最大化整体有效吞吐量和满足延迟相关的 SLO 之间进行平衡。
|
||||
- 与传统假设所有请求都会被处理的研究不同，Mooncake 需要应对高负载场景带来的挑战。为此，Mooncake 提出了一种基于预测的早期拒绝策略。
|
||||
|
||||
图片来源：Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
实验结果表明，Mooncake 在 长上下文场景下表现尤为突出：在某些模拟场景中，吞吐量相比基线方法最高可提升 525%，同时仍能满足 SLO。在真实负载下，Mooncake 的创新架构使 Kimi 能够多处理 75% 的请求。
|
||||
|
||||
使用 Mooncake 运行 PD 分离服务请参考文档：vLLM V1 Disaggregated Serving with Mooncake Store and LMCache
|
||||
|
||||
#### 7.2 Dynamo
|
||||
|
||||
NVIDIA Dynamo 是一个开源的模块化推理框架，用于在分布式环境上实现生成式 AI 模型的服务化部署。Dynamo 通过动态资源调度、智能路由、内存优化与高速数据传输，无缝扩展大型 GPU 集群之间的推理工作负载。
|
||||
|
||||
Dynamo 采用推理引擎无关的设计（支持 TensorRT-LLM、vLLM、SGLang 等），包括以下 4 个核心组件：
|
||||
|
||||
- **NVIDIA Dynamo Planner**：一个智能规划和调度引擎，用于监控分布式推理中的容量与延迟，并在 prefill 与 decode 阶段之间灵活分配 GPU 资源，以最大化吞吐量和效率。Planner 会持续跟踪关键的 GPU 容量指标，并结合应用的 SLO（如 TTFT 和 ITL），智能决策是否采用分离式推理，或是否需要为 prefill/decode 阶段动态增加更多 GPU。
|
||||
- **NVIDIA Dynamo Smart Router**：KV cache 感知的路由引擎，可在分布式推理环境中将请求转发到最佳的节点，从而最大限度减少 KV cache 的重复计算开销。
|
||||
- **NVIDIA Dynamo Distributed KV Cache Manager**：通过将较旧或低频访问的 KV cache 卸载到更低成本的存储（如 CPU 内存、本地存储或对象存储等），大幅降低 GPU 内存占用。借助这种分层管理，开发者既能保留大规模 KV cache 重用的优势，又能释放宝贵的 GPU 资源，从而有效降低推理计算成本。
|
||||
- **NVIDIA Inference Transfer Library (NIXL)**：高效的推理数据传输库，可加速 GPU 之间以及异构内存与存储之间的 KV cache 传输。通过减少同步开销和智能批处理，NIXL 显著降低了分布式推理中的通信延迟，使得在 prefill/decode 分离部署时，prefill 节点也能在毫秒级将大批量的 KV cache 传输至 decode 节点，从而避免跨节点数据交换成为性能瓶颈。
|
||||
|
||||
在 Dynamo 的 PD 分离架构中，有 4 个核心组件：
|
||||
|
||||
- **(decode) worker**：执行 prefill 和 decode 请求。
|
||||
- **prefill worker**：只执行 prefill 请求。
|
||||
- **disaggregated router**：决定 prefill 阶段是在本地还是远程执行。
|
||||
- **prefill queue**：缓存并负载均衡远程 prefill 请求。
|
||||
|
||||
当 worker 收到请求时，首先会通过 disaggregated router 判断 prefill 应该在本地还是远程完成，并分配相应的 KV block。 如果选择远程 prefill，请求会被推送到 prefill queue。随后，prefill worker 从队列中取出请求，读取 worker 中 prefix cache 命中的 KV block，执行 prefill 计算，并将生成的 KV block 回写给 worker。最后，worker 会继续完成剩余的 decode 阶段。
|
||||
|
||||
Dynamo 提供了 Operator 方便我们在 Kubernetes 环境中以声明式的方式定义 PD 分离服务。只需在 `DynamoGraphDeployment` 配置中声明 Frontend、VllmDecodeWorker 和 VllmPrefillWorker 三个组件即可。`dynamoNamespace` 是 Dynamo 分布式运行时的逻辑隔离单元，而非 Kubernetes 的 namespace；同一 `dynamoNamespace` 内的组件可以相互发现并进行通信。
|
||||
|
||||
```
|
||||
apiVersion: nvidia.com/v1alpha1
|
||||
kind:DynamoGraphDeployment
|
||||
metadata:
|
||||
name:vllm-disagg
|
||||
spec:
|
||||
services:
|
||||
Frontend:
|
||||
dynamoNamespace:vllm-disagg
|
||||
componentType:frontend
|
||||
replicas:1
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
VllmDecodeWorker:
|
||||
dynamoNamespace:vllm-disagg
|
||||
componentType:worker
|
||||
replicas:1
|
||||
resources:
|
||||
limits:
|
||||
gpu:"1"
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
workingDir:/workspace/components/backends/vllm
|
||||
command:
|
||||
-/bin/sh
|
||||
--c
|
||||
args:
|
||||
-"python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B"
|
||||
VllmPrefillWorker:
|
||||
dynamoNamespace:vllm-disagg
|
||||
componentType:worker
|
||||
replicas:1
|
||||
resources:
|
||||
limits:
|
||||
gpu:"1"
|
||||
extraPodSpec:
|
||||
mainContainer:
|
||||
image:nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.4.1
|
||||
workingDir:/workspace/components/backends/vllm
|
||||
command:
|
||||
-/bin/sh
|
||||
--c
|
||||
args:
|
||||
-"python3 -m dynamo.vllm --model Qwen/Qwen3-0.6B --is-prefill-worker"
|
||||
```
|
||||
|
||||
Dynamo 详细的部署教程可以参考博客：https://cr7258.github.io/blogs/original/2025/20-dynamo#_3-运行-dynamo
|
||||
|
||||
#### 7.3 llm-d
|
||||
|
||||
llm-d 是一个 Kubernetes 原生的分布式推理服务栈，为团队提供一条清晰高效的路径，以最快的落地速度在大规模环境中部署并管理推理服务。llm-d 通过集成业界标准的开源技术来加速分布式推理：使用 vLLM 作为模型服务与引擎，Inference Gateway 作为请求调度器与负载均衡器，Kubernetes 作为基础设施编排与工作负载控制平面。
|
||||
|
||||
llm-d 提供以下核心功能：
|
||||
|
||||
- 基于 vLLM 优化的推理调度器：llm-d 基于 IGW 的 Endpoint Picker Protocol (EPP) 实现可定制化的"智能"负载均衡，专门针对 vLLM 进行优化。调度器结合运行时遥测数据，利用过滤和打分算法，在 P/D 分离、KV cache、SLA 与负载感知的基础上做出调度决策，同时支持团队自定义策略。
|
||||
- PD 分离：llm-d 利用 vLLM 的分离式推理能力，将 prefill 和 decode 拆分到独立实例运行，并通过高性能传输库（如 NIXL）进行通信。
|
||||
- 分布式 KV cache：llm-d 使用 vLLM 的 KV connector 构建可插拔的 KV cache 层级体系，支持将 KV cache 卸载到主机、远程存储或 LMCache 等系统。
|
||||
|
||||
使用 llm-d 运行 PD 分离服务请参考：https://github.com/llm-d/llm-d/tree/main/guides/pd-disaggregation
|
||||
|
||||
#### 7.4 AIBrix
|
||||
|
||||
AIBrix 是字节跳动开源的云原生分布式推理框架，专为大规模 LLM 部署设计。
|
||||
|
||||
- AIBrix 支持 LoRA 管理、前缀感知和负载感知的智能路由，并通过分布式 KV cache 实现跨节点的高效 token 复用。
|
||||
- 在系统编排层面，AIBrix 结合 Kubernetes 与 Ray 的混合调度，既能满足大规模集群管理的需求，又能灵活执行细粒度任务。
|
||||
- AIBrix 基于 SLO 的 GPU 优化器与诊断工具进一步提升了资源利用率和系统可靠性。
|
||||
|
||||
使用 AIBrix 运行 PD 分离服务请参考：https://github.com/vllm-project/aibrix/tree/main/samples/disaggregation/vllm
|
||||
|
||||
### 8 Chunked-Prefills VS PD 分离
|
||||
|
||||
chunked-prefills 方案的核心思想是：将长序列的 prefill 请求拆分为几乎相等大小的小块，然后构建了由 prefill 小块和 decode 组成的混合 batch。或者说，chunked-prefills 策略通过将不同长度的 prompts 拆分成长度一致的 chunks 来进行 prefill，以避免长 prompt 阻塞其他请求，同时利用这些 chunks 的间隙进行 decode 的插入/捎带（piggyback）操作，从而减少延迟并提高整体的吞吐。
|
||||
|
||||
decode 阶段的开销不仅来自从 GPU 内存中获取 KV cache，还包括提取模型参数。而通过这种 piggyback 方法，decode 阶段能够重用 prefill 时已提取的模型参数，几乎将 decode 阶段从一个以内存为主的操作转变为一个计算为主的操作。因此，这样构建的混合批次具有近乎均匀的计算需求（而且增加了计算密集性），使我们能够创建平衡的微批处理调度，缓解了迭代之间的不平衡，导致 GPU 的管道气泡最小化，提高了 GPU 的利用率。也最小化了计算新 prefill 对正在进行的 decode 的 TBT 的影响，从而实现了高吞吐量和低 TBT 延迟。
|
||||
|
||||
chunked-prefills 有两个明显的好处：
|
||||
|
||||
- 所有节点被平等对待，使调度更简单。
|
||||
- 将 chunked prefill 内联到 decode 批处理中可以提高 decode 批次的计算强度，从而带来更好的 MFU（Model FLOPs Utilization，指的是模型实际使用的计算量占 GPU 理论峰值算力的比例，用来衡量算力利用效率）。
|
||||
|
||||
然而，chunked-prefills 也有一些缺点：
|
||||
|
||||
- chunked-prefills 会增加 prefill 的计算开销，如果 chunk 大小明显低于 GPU 饱和点，会延长 prefill 的执行时间。
|
||||
- prefill 阶段仍难以完全最大化 MFU，因为在 chunk-prefill 中，profiling 只会估算特定设备上一个 batch 的最大 tokens 配额，这个配额同时包含 prefill 和 decode，而不是分别针对两者优化。
|
||||
- chunked-prefills 也会显著增加 prefill 阶段的内存访问量，每个 chunk 的 Attention 操作都需重复读取此前的 KV cache，增加内存访问负担。而且长序列可能会持久地占据着 KV cache 的存储空间以及 GPU 的计算资源。
|
||||
- 在 TPOT 方面，将 prefill 与 decode 合并批处理实际上会降低所有 decode 任务的平均速度。
|
||||
|
||||
**总之，chunked-prefills 可能有助于最大化整体吞吐量，但由于动态分割无法完全解耦 prefill 和 decode 操作，会导致资源争用以及 TTFT 与 TPOT 之间的妥协。当应用程序无法在 TTFT 和 TPOT 之间进行权衡，而是要同时遵守这两者时，PD 分离就成为更好的选择。**
|
||||
|
||||
### 9 PD 分离相关论文
|
||||
|
||||
- DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving
|
||||
- Splitwise: Efficient Generative LLM Inference Using Phase Splitting
|
||||
- TetriInfer: Inference without Interference:Disaggregate LLM Inference for Mixed Downstream Workloads
|
||||
- MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool
|
||||
- Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving
|
||||
|
||||
### 10 总结
|
||||
|
||||
PD 分离大模型推理中的一种架构优化策略，核心思想是把 prefill 阶段和 decode 阶段分开，由不同的 GPU 或实例分别承担。通过分离架构，系统可以针对 prefill（计算密集型）和 decode（内存密集型）的不同特性分别优化资源配置和并行策略，从而在满足 TTFT 和 TPOT SLO 约束的前提下显著提升有效吞吐量（Goodput）。虽然 PD 分离需要在 GPU 间传输 KV Cache，但通过高速互联网络和优化的传输策略，这一开销可以被有效隐藏。目前，vLLM、Mooncake、Dynamo 等主流推理框架都已支持 PD 分离，为大规模 LLM 服务提供了更高效的解决方案。相比于 chunked-prefills 等替代方案，PD 分离在需要同时满足严格 TTFT 和 TPOT 要求的场景下具有明显优势。
|
||||
|
||||
### 11 参考资料
|
||||
|
||||
- Lecture 58: Disaggregated LLM Inference：https://www.youtube.com/watch?v=tIPDwUepXcA
|
||||
- Throughput is Not All You Need: Maximizing Goodput in LLM Serving using Prefill-Decode Disaggregation：https://hao-ai-lab.github.io/blogs/distserve/
|
||||
- Mooncake阅读笔记：深入学习以Cache为中心的调度思想，谱写LLM服务降本增效新篇章：https://zhuanlan.zhihu.com/p/706097807
|
||||
- 探秘Transformer系列之（26）--- KV Cache优化 之 PD分离or合并：https://www.cnblogs.com/rossiXYZ/p/18815541
|
||||
- 大模型推理分离架构五虎上将：https://zhuanlan.zhihu.com/p/706218732
|
||||
- LLM关于PD分离的最新实测：https://zhuanlan.zhihu.com/p/1919794916504114120
|
||||
- State of the Model Serving Communities - August 2025：https://inferenceops.substack.com/p/state-of-the-model-serving-communities
|
||||
- 图解大模型训练系列：序列并行1，Megatron SP：https://zhuanlan.zhihu.com/p/4083427292
|
||||
- 序列并行做大模型训练，你需要知道的六件事：https://zhuanlan.zhihu.com/p/698031151
|
||||
- vLLM PD分离KV cache传递机制详解与演进分析：https://zhuanlan.zhihu.com/p/1906741007606878764
|
||||
- vLLM PD分离方案浅析：https://zhuanlan.zhihu.com/p/1889243870430201414
|
||||
- P/D Disaggregation of vLLM and Integration with Mooncake：https://docs.google.com/document/d/1Ab6TMW1E2CdHJJyCrpJnLhgmE2b_6leH5MVP9k72sjw/edit?tab=t.0#heading=h.611v2r4aqubz
|
||||
- 0.5x提升:PD分离KV cache传输的实践经验：https://zhuanlan.zhihu.com/p/1946608360259577576
|
||||
- 分布式推理优化思路：http://zhuanlan.zhihu.com/p/1937556222371946860
|
||||
- 图解大模型计算加速系列：分离式推理架构2，模糊分离与合并边界的chunked-prefills：https://zhuanlan.zhihu.com/p/710165390
|
||||
- 图解大模型计算加速系列：分离式推理架构1，从DistServe谈起：https://zhuanlan.zhihu.com/p/706761664
|
||||
- LLM推理优化 - Prefill-Decode分离式推理架构：https://zhuanlan.zhihu.com/p/9433793184
|
||||
- Shaping NIXL-based PD Disaggregation in vLLM V1：https://blog.lmcache.ai/2025-04-11-lmcache-vllmv1-nixl/
|
||||
- vLLM P2P NCCL Connector：https://docs.vllm.ai/en/latest/design/p2p_nccl_connector.html
|
||||
- vLLM Disaggregated Prefilling (experimental)：https://docs.vllm.ai/en/latest/features/disagg_prefill.html
|
||||
- LMCache Example: Disaggregated prefill：https://docs.lmcache.ai/getting_started/quickstart/disaggregated_prefill.html
|
||||
- Bringing State-Of-The-Art PD Speed to vLLM v1 with LMCache：https://blog.lmcache.ai/2025-04-29-pdbench/
|
||||
- Demystify vLLM V1 KVconnector SharedStorageConnector：https://blog.diabloneo.com/demystify-vllm-v1-kvconnector-sharedstorageconnector-05a487627036
|
||||
- vLLM源码之分离式架构：https://zhuanlan.zhihu.com/p/1933647687
|
||||
- vLLM v1 PD分离设计：https://zhuanlan.zhihu.com/p/1894425784107632241
|
||||
- Inside vLLM: Anatomy of a High-Throughput LLM Inference System：https://blog.vllm.ai/2025/09/05/anatomy-of-vllm.html
|
||||
- [P/D][V1] KV Connector API V1：https://github.com/vllm-project/vllm/pull/15960
|
||||
- vLLM PD Disaggregation discussion：https://docs.google.com/document/d/1uPGdbEXksKXeN4Q9nUm9hzotqEjQhYmnpAhidLuAsjk/edit?tab=t.0#heading=h.qhtgj3vmvwn
|
||||
- llm-d: Kubernetes-native Distributed Inference at Scale：https://github.com/llm-d/llm-d/blob/dev/docs/proposals/llm-d.md
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：PD 分离推理架构详解
|
||||
|
||||
> **原文**：[2025-09-21_PD_分离推理架构详解.md](./2025-09-21_PD_分离推理架构详解.md)
|
||||
> **原文链接**：https://cloud.tencent.com/developer/article/2586469
|
||||
> **来源**：腾讯云开发者社区
|
||||
> **作者**：cr7258
|
||||
> **发布日期**：2025-09-21
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **阶段解耦** — 以 Goodput 为准绳，把 prefill 与 decode 物理分离并按阶段特性分别优化，是同时满足 TTFT/TPOT 双 SLO 的更优架构。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是 LLM 推理系列第 6 篇，系统讲解 PD 分离架构。真正想说的是：continuous batching 下 prefill（计算密集）与 decode（内存密集）共置会相互干扰——prompt 长度 1024 时 decode 延迟被放大 12.6 倍——难以同时满足 TTFT 与 TPOT 双 SLO，而将两阶段分配到不同 GPU 实例并按各自特性优化，可在满足 SLO 前提下把有效吞吐（Goodput）提升约 2 倍。重要在于它串联了从 Goodput 指标、干扰量化、KV Cache 传输（开销/方式/粒度）到 vLLM KV Connector 五种实现，再到 Mooncake、Dynamo、llm-d、AIBrix 的工业落地，并对比了 chunked-prefills 的适用边界。局限：数据多引自论文与官方材料，缺乏作者自身实测。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **Goodput 优于 Throughput** — 只有满足 TTFT/TPOT SLO 的请求才算有效产出，高吞吐但低 Goodput 的系统用户体验依然糟糕 `[分类: 共识]`
|
||||
2. **共置干扰有量化证据** — prompt 长 128 时 decode 延迟增约 1.8 倍，长 1024 时达 12.6 倍；同时满足双 SLO 时需资源过度配置 `[分类: 共识]`
|
||||
3. **分离即收益** — 2P1D 配置（2 prefill + 1 decode worker）Goodput 约 3.3 rps/GPU，相比共置 1.6 rps/GPU 提升约 2 倍，且未引入任何并行优化 `[分类: 共识]`
|
||||
4. **阶段特性决定优化方向** — prefill 计算受限宜小 batch、张量并行；decode 内存受限宜大 batch、数据/流水线并行；算力与存储可独立优化 `[分类: 共识]`
|
||||
5. **KV 传输开销可被隐藏** — 8 通道 PCIe 5.0 下 OPT-175B 传输估算 17.6ms，低于单次 decode 步骤（30-50ms）；按请求级/层级（Splitwise）/块级（TetriInfer）粒度传输 `[分类: 共识]`
|
||||
6. **vLLM 的 KV Connector 抽象层** — SharedStorage/P2pNccl/Nixl/LMCache/Multi 五种 connector，scheduler 通过 KVConnectorMetadata 指挥 worker 传递 KV `[分类: 共识]`
|
||||
7. **工业界已规模验证** — Mooncake 模拟场景吞吐最高提升 525%、Kimi 真实负载多处理 75% 请求；Dynamo 提供 router/queue 四组件与 K8s Operator `[分类: 共识]`
|
||||
8. **PD 分离的适用边界** — 当应用必须同时遵守 TTFT 与 TPOT（而非二者可权衡）时，PD 分离优于 chunked-prefills，后者动态分割无法完全解耦 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
立论假设集群具备高速互联（NVLink/PCIe 5.0/RDMA）且规模足够大，使 KV 传输与调度的额外成本可被摊薄；假设 SLO 是刚性约束（Goodput 定义依赖 P90 分位）；假设流量特征稳定到值得为两阶段分别配置资源。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据多引自 DistServe、Splitwise、Mooncake 等论文与官方博客，"指标→干扰机制→分离收益→传输优化"的逻辑链完整；但 2P1D 实验是泊松流量模拟，未覆盖突发流量与 P/D 配比动态调节，传输延迟估算也基于理想化带宽假设。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
小模型与单卡场景分离收益有限；网络带宽不足时传输开销可能抵消收益；资源孤岛、实例动态配比、角色切换等运维问题仅一笔带过；chunked-prefills 对比较简略，未讨论两类架构的混合方案。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "当应用程序无法在 TTFT 和 TPOT 之间进行权衡，而是要同时遵守这两者时，PD 分离就成为更好的选择。"
|
||||
|
||||
> "这个实验表明，即便没有引入任何并行优化，仅仅通过简单的分离，Goodput 就提升了约 2 倍。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 覆盖"指标—原理—传输—实现—工业落地"全链路，信息密度高
|
||||
- 干扰效应（1.8x/12.6x）与 KV 传输开销（17.6ms）均有量化估算
|
||||
- vLLM KV Connector 与四套工业方案（Mooncake/Dynamo/llm-d/AIBrix）梳理清晰，可作选型参考
|
||||
|
||||
**不足**：
|
||||
- 数据多转引自论文与官方博客，无作者自身实测
|
||||
- 对 PD 分离隐性成本（调度复杂度、扩容粒度、资源孤岛）着墨较少
|
||||
- chunked-prefills 对比简略，未展开混合架构方案
|
||||
|
||||
**适用场景**：LLM 推理系统架构师、Serving 平台工程师做方案选型与技术调研；想建立 Goodput 与 PD 分离全貌认知的研究者。
|
||||
|
||||
**关联建议**：精读 DistServe、Splitwise、TetriInfer、Mooncake 论文原文；跟踪 vLLM V1 KV Connector 演进与 Dynamo 部署实践。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,219 @@
|
||||
# 下一代推理优化技术：高性能网络驱动的PD分离与KV Cache Offload测试（上）
|
||||
|
||||
> **来源**：超擎数智（官网博客）
|
||||
> **作者**：超擎数智
|
||||
> **发布日期**：2026-08-05（原文未标注，按下载日期）
|
||||
> **原文链接**：https://chaoqing-i.com/blog/next-gen-inference-optimization-pd-separation-kv-cache-offload-test
|
||||
|
||||
---
|
||||
|
||||
近年来，大规模模型在各类应用场景中快速落地，带动了推理需求的高速增长。随着模型参数量不断提升和用户请求并发数持续攀升，如何提升推理性能成为业界关注的核心问题，在众多优化方向中，PD分离与KV Cache Offload被认为是当前对推理性能提升最具突破性的两项关键技术，前者通过计算与通信解耦，实现更高效的资源利用，后者则通过缓存卸载，极大降低了显存占用并提升大模型长文本推理的效率。
|
||||
|
||||
为全面验证高性能网络与PD分离、KV Cache Offload这两项技术的性能优势与应用价值，**NVIDIA、超擎数智、联想、DaoCloud、纳多德五家公司联合投入总计数千万元的设备与资源，在超擎数智高性能计算和人工智能研发测试中心开展跨厂商协作测试。**本次测试旨在为业界提供权威的技术验证结果，探索推理优化的最佳实践，并为未来的大规模部署提供参考。
|
||||
|
||||
在大模型推理场景中，传统架构面临两大挑战：
|
||||
|
||||
- 计算效率瓶颈：传统的一体化部署模式中Prefill和Decode在同一设备上执行会出现严重的资源竞争问题，两个阶段的资源需求特性无法得到针对性优化导致计算资源利用率低。
|
||||
- 显存带宽压力：KV Cache的显存开销随上下文长度增长线性膨胀，显存带宽成为性能瓶颈。
|
||||
|
||||
**PD分离（Prefill & Decode Separation）与KV Cache Offload是当前大模型推理中的核心优化技术，可显著提升推理吞吐和并发能力：**
|
||||
|
||||
- **提升推理效率、降低延迟：**通过拆分Prefill和Decode阶段并部署到不同设备，避免计算资源冲突，使推理**Token延迟显著降低、Token吞吐提升 2～3 倍。**
|
||||
- **显著降低显存占用、支持更多用户并发：**KV Cache Offload将大量上下文缓存从显存转移至CPU/SSD，大幅节省GPU显存，使同一模型能够支持更多并发用户或更长的上下文长度。
|
||||
- **提高资源利用率、降低成本：**PD分离+Offload让高性能GPU更专注在重计算任务上，普通硬件即可承担缓存任务，整体推理集群性价比提升明显。
|
||||
|
||||
## PD分离与KV Cache Offload技术介绍
|
||||
|
||||
### 1. 什么是PD分离？为什么要选择PD分离？
|
||||
|
||||
在大语言模型（LLM）的推理过程中，通常会经历两个阶段：
|
||||
|
||||
**1）Prefill阶段（输入处理）**
|
||||
|
||||
a. 模型一次性读取并并行处理全部输入Token，建立上下文理解
|
||||
b. 计算模式：高并行度的矩阵乘法，计算密集，显存占用相对较低
|
||||
c. 特点：更适合高吞吐量的GPU、多卡并行运行
|
||||
|
||||
**2）Decode阶段（输出生成）**
|
||||
|
||||
a. 模型基于上下文（以及 KV Cache）逐个生成Token
|
||||
b. 计算模式：顺序生成，一个Token接一个Token，延迟敏感
|
||||
c. 显存占用：会随着上下文长度增长而迅速增加（因为要存KV Cache）
|
||||
|
||||
在传统部署中，这两个阶段通常运行在同一批GPU上。但问题是Prefill和Decode的资源需求完全不同——一个追求高并行算力，一个追求低延迟和大显存。把它们混在同一批GPU上跑，往往两边性能都打折扣。
|
||||
|
||||
**PD分离（Prefill–Decode Separation）**
|
||||
|
||||
顾名思义，就是把Prefill和Decode分开部署在不同的硬件资源池中：
|
||||
|
||||
- Prefill阶段使用高算力、高吞吐的GPU
|
||||
- Decode阶段使用显存更大、延迟更低的GPU
|
||||
|
||||
这样做的好处：
|
||||
|
||||
- 针对性优化：让每个阶段用最合适的硬件，发挥最佳性能
|
||||
- 资源独立扩展：Prefill和Decode各自可以根据负载独立增加或减少GPU
|
||||
- 提升整体吞吐量：避免一种任务拖慢另一种任务
|
||||
|
||||
**PD分离的挑战**
|
||||
|
||||
- 额外的通信开销：如果Prefill和Decode放在不同的GPU上，需要传输KV Cache，网络延迟和带宽会成为瓶颈。
|
||||
- 调度复杂度增加：系统要实时协调两列任务的分配，否则Decode阶段可能会空等Prefill的结果，或者Prefill资源被Decode阻塞。
|
||||
- 实现复杂：框架和任务调度器需要支持流水线，KV Cache输出，异步执行等操作，难度要比单机单卡推理更难维护。
|
||||
- 内存占用高：Prefill阶段可能会同时处理多个请求，Decode阶段需要保留全部的KV Cache，内存压力会很大。
|
||||
|
||||
PD分离就是"分工合作"，让Prefill和Decode各自使用最适合的GPU，从而提升效率和吞吐量，但也需要解决通信、调度、内存等方面的挑战。
|
||||
|
||||
### 2. 什么是KV Cache？为什么我们要offload？
|
||||
|
||||
如果把大语言模型（LLM）比作一个写小说的作家，那么Transformer就是他的"思考方法"。
|
||||
|
||||
作家写故事时，会一边看之前写的内容，一边决定接下来写什么。同样，Transformer 在生成文本时，也是一边参考之前生成的Token，一边预测下一个Token。
|
||||
|
||||
**从Transformer说起**
|
||||
|
||||
在Transformer的自注意力（Self-Attention）机制里，每个Token（可以理解为一个词或字的编码）都会生成三种向量：
|
||||
|
||||
- Q（Query）：我现在要找的信息是什么？
|
||||
- K（Key）：我是谁？（特征坐标）
|
||||
- V（Value）：我带来的内容是什么？（特征内容）
|
||||
|
||||
在Transformer生成文本时，每次只会生成一个新Token，模型会用这个Token的Q去和所有历史Token的K做匹配，找到相关性，然后用这些相关的V计算输出，但是标准Transformer在推理时是逐个Token生成的，比如：
|
||||
|
||||
输入："我想要读一"
|
||||
生成："我想要读一本"
|
||||
继续生成："我想要读一本书"
|
||||
|
||||
但在生成第三个Token时，它又会重新计算前面所有Token的K和V，哪怕这些数据早就算过了！
|
||||
|
||||
这种重复计算会导致推理的计算量随着Token数量呈二次方增长，速度很慢。
|
||||
|
||||
**KV Cache的核心宗旨"别重复干活"**
|
||||
|
||||
KV Cache的核心思想是：历史的K和V早就算好了，直接存起来，别每次都重算。
|
||||
|
||||
这样，每次生成新Token时，只需：
|
||||
|
||||
- 计算新Token的K和V
|
||||
- 把它们拼到之前缓存的结果中
|
||||
- 用缓存+新Token一起继续生成
|
||||
|
||||
这样一来，推理的计算量就从二次方降到线性，大大加快速度。
|
||||
|
||||
**为什么要Offload**
|
||||
|
||||
KV Cache虽然能加速，但它有个副作用：特别占显存。
|
||||
|
||||
举个例子：
|
||||
|
||||
- 假设你的模型上下文长度是8万个Token
|
||||
- 每个Token的K和V都要存
|
||||
- 可能光KV Cache就能占用几十GB的显存
|
||||
|
||||
显存是GPU上最宝贵的资源，除了KV Cache，还需要存模型权重、中间计算结果等。如果显存被占满，推理就会崩溃或者无法运行。
|
||||
|
||||
**Offload 的作用**
|
||||
|
||||
Offload就是把一部分数据从显存（GPU Memory）挪到其他存储介质，比如：
|
||||
|
||||
- CPU内存（RAM）：容量大，但带宽比GPU慢
|
||||
- SSD：容量更大，但速度更慢
|
||||
- 高带宽内存（HBM）：速度快，但昂贵且容量有限
|
||||
|
||||
在KV Cache场景下，Offload的好处是：
|
||||
|
||||
- 把暂时用不到的历史KV数据移到CPU/SSD
|
||||
- 腾出GPU显存，保证当前推理不卡
|
||||
- 在需要时再把数据搬回来（当然搬运有代价，所以要权衡速度和显存占用）
|
||||
|
||||
## 联合测试概述
|
||||
|
||||
### 1. 测试目标
|
||||
|
||||
验证PD分离和KV Cache Offload在大模型推理场景下的性能优化效果，具体包括：
|
||||
|
||||
- 降低端到端延迟：解耦Prefill与Decode阶段，减少资源争抢。
|
||||
- 扩展上下文长度：通过KV Cache分层存储（显存→主机内存/NVMe），突破显存容量限制。
|
||||
- 提升硬件利用率：优化计算单元和存储介质的协作效率。
|
||||
|
||||
### 2. 测试拓扑与环境
|
||||
|
||||
测试拓扑见图1，环境信息如下：
|
||||
|
||||
- **H20服务器 ×1**：超擎数智元景系列AI服务器CQ7688-L，搭载 NVIDIA H20 GPU，8U8卡 NVLink，8U空间内搭载1块NVIDIA Hopper架构HGX-8GPU模组，系统支持4.0Tbps网络带宽，满足万亿级参数超大模型并行训练需求。
|
||||
- **L20服务器 ×3**：超擎数智擎天系列L20 AI 服务器CQ7458-L（4U8卡 PCIe）支持4卡或8卡配置，用户可以基于应用模型按需配置/灵活切换，并且支持丰富的AI加速卡和智能网卡，从而适应不同人工智能场景的需求，满足各种 AI 业务场景下的应用需求。
|
||||
- **RoCE交换机 ×6**：采用NVIDIA Spectrum™ SN5000系列第五代Spectrum以太网交换机，计算网络和存储网络均采用SN5600进行组网。
|
||||
- **存储服务器**：采用联想问天WR5220 G3高性能存储服务器。
|
||||
- **软件平台**：采用DaoCloud d.run平台。
|
||||
- **光连接器件**：采用纳多德高性能光模块和光纤跳线，保障性能和稳定性的同时可以大幅度降低成本。
|
||||
- **存储节点 ×3**：采用3台分布式存储节点，每台节点均搭配NVMe硬盘。
|
||||
|
||||
关键组件如下：
|
||||
|
||||
- **Prefill单元**：部署在1台高算力H20 GPU（高速PCIe 5.0/NVLink）上，充分利用强大算力，专注生成初始KV Cache。
|
||||
- **Decode单元**：使用3台L20 GPU，专注于GPU执行自回归生成。
|
||||
- **存储层级**：
|
||||
- 显存（HBM）：存储活跃KV Cache（热数据）。
|
||||
- 主机内存（DDR）：卸载历史KV Cache（温数据）。
|
||||
- NVMe SSD：硬盘存储极低频访问的KV Cache（冷数据）。
|
||||
- **网络连接**：H20和L20 400G计算网络、H20、L20、StorageNode 200G存储网络分别使用不同的高速交换机互联传输数据。
|
||||
|
||||
### 3. 测试设计
|
||||
|
||||
**3.1 PD分离测试**
|
||||
|
||||
- 对照组：传统耦合架构（Prefill与Decode共享H20 GPU）。
|
||||
- 实验组：PD分离架构（Prefill由H20 GPU处理，Decode由L20 GPU处理）。
|
||||
- 指标：
|
||||
- Prefill延迟：从输入Prompt到生成首个Token的时间。
|
||||
- Decode吞吐量：Tokens/Second（TPS）。
|
||||
- GPU利用率：nvidia-smi监控计算负载。
|
||||
|
||||
**3.2 KV Cache Offload测试**
|
||||
|
||||
- 对照组：全量KV Cache驻留显存。
|
||||
- 实验组：分层卸载策略（显存→内存→SSD）。
|
||||
- 指标：
|
||||
- 显存占用峰值：dcgm记录HBM使用量。
|
||||
- Offload延迟：冷数据加载至显存的平均耗时。
|
||||
- 最大支持上下文：通过逐步增加Prompt长度测试崩溃点。
|
||||
|
||||
**3.3 联合测试**
|
||||
|
||||
验证PD分离与Offload协同效果：
|
||||
|
||||
- 场景：8K上下文 + 100轮对话。
|
||||
- 关键指标：端到端延迟、系统总功耗。
|
||||
|
||||
### 4. 预期结果
|
||||
|
||||
**4.1 PD分离**
|
||||
|
||||
预期结果：
|
||||
|
||||
- Decode阶段延迟降低30%-50%（L20 GPU处理避免H20 GPU阻塞）。
|
||||
- H20 GPU利用率从60%提升至85%（专注计算密集型Prefill）。
|
||||
|
||||
**4.2 KV Cache Offload**
|
||||
|
||||
预期结果：
|
||||
|
||||
- 显存占用减少60%（8K上下文下从16GB→6.4GB）。
|
||||
- 支持上下文长度从2K扩展至16K。
|
||||
|
||||
**4.3 联合优化**
|
||||
|
||||
预期结果：
|
||||
|
||||
- 系统总吞吐量（QPS）提升2倍，功耗降低20%。
|
||||
|
||||
### 5. 数据收集与分析
|
||||
|
||||
- 工具：
|
||||
- 性能分析：Nsight Systems、perf。
|
||||
- 资源监控：Prometheus（GPU/CPU/内存指标）。
|
||||
- 分析方法：
|
||||
- 对比对照组/实验组的延迟分布。
|
||||
- 显存带宽与计算效率的相关性分析。
|
||||
|
||||
> **注**：本文为系列文章"上"篇，主要介绍技术背景、测试方案设计与预期结果；实测数据与分析拟在"下"篇呈现。
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：下一代推理优化技术：高性能网络驱动的PD分离与KV Cache Offload测试（上）
|
||||
|
||||
> **原文**：[2026-08-05_下一代推理优化技术_高性能网络驱动的PD分离与KV_Cache_Offload测试_上.md](./2026-08-05_下一代推理优化技术_高性能网络驱动的PD分离与KV_Cache_Offload测试_上.md)
|
||||
> **原文链接**：https://chaoqing-i.com/blog/next-gen-inference-optimization-pd-separation-kv-cache-offload-test
|
||||
> **来源**：超擎数智（官网博客）
|
||||
> **作者**：超擎数智
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **PD分离验证方案** — 为业界提供一份可直接复用的"PD分离+KV Cache Offload"跨厂商联合测试设计模板（拓扑、对照实验、指标、分层卸载），并系统梳理两项技术带来的性能收益与工程代价。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文是"下一代推理优化技术"系列的上篇，由 NVIDIA、超擎数智、联想、DaoCloud、纳多德五家厂商联合投入数千万元设备，在超擎数智研发测试中心开展 PD 分离与 KV Cache Offload 的跨厂商验证测试。文章先以科普方式解释 Prefill/Decode 两阶段的计算特征差异、KV Cache 原理与卸载动因，再给出完整测试方案：H20 承担 Prefill、3 台 L20 承担 Decode、显存/内存/NVMe 三级存储分层，并设计了对照实验与预期指标（Token 吞吐提升 2～3 倍、显存占用减少 60%、QPS 提升 2 倍）。其价值在于测试方法论的完整呈现与对工程代价的清醒说明，但本文不含任何实测数据，认知增量有限，需以下篇实测为准。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **PD分离=两阶段分工** — 将计算密集的 Prefill 与访存密集的 Decode 分离部署到不同硬件池，针对性优化、独立扩缩容、提升整体吞吐；但引入通信开销、调度复杂度、实现复杂、内存占用四类代价。`[分类: 共识]`
|
||||
2. **KV Cache Offload 缓解显存墙** — 将历史 KV 按热/温/冷分层卸载至 HBM→DDR→NVMe，突破显存容量限制，代价是数据搬运动态权衡速度与容量。`[分类: 共识]`
|
||||
3. **跨厂商联合测试模板** — 1 台 H20（Prefill）+ 3 台 L20（Decode）+ 3 台 NVMe 分布式存储节点 + 400G/200G RoCE 组网，对照组/实验组对比设计，指标覆盖 Prefill 延迟、Decode TPS、GPU 利用率、显存峰值、Offload 延迟与最大上下文。`[分类: 共识]`
|
||||
4. **预期收益量化** — 预期 Decode 延迟降 30%-50%、H20 利用率从 60% 升至 85%、显存占用减 60%（16GB→6.4GB）、上下文 2K→16K、联合场景 QPS 提升 2 倍且功耗降 20%。`[分类: 争议]`（预期值未经实测验证，是本文主要悬念）
|
||||
5. **网络是PD分离的隐性前提** — 计算网络与存储网络分离组网（400G/200G），暗示 KV 传输带宽与存储链路带宽是分离架构能否兑现收益的关键变量。`[分类: 未探索方向]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设 PD 分离与 KV Cache Offload 的收益（吞吐提升、显存释放）在跨厂商、跨硬件组合下依然成立，且高性能网络（400G/200G RoCE）可充分承载 KV 传输开销；同时假设测试环境能代表真实生产负载（8K 上下文+100 轮对话场景相对温和）。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
本文论据链不完整——所有收益均为"预期结果"而非测量结果，逻辑停留在方案推演层面，无法支撑"最具突破性"的定性判断；文章对挑战的论述（通信开销、调度复杂度）反而削弱了自身乐观基调，说明作者对代价有认知，但预期收益如何抵消代价缺乏论证。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论适用范围待下篇数据确认；测试采用单一模型规模与有限并发场景，不覆盖超长上下文（百万级）、多租户混合负载等极端情况；五厂商联合测试由利益相关方组织，需关注数据独立性；PD 分离在短序列、低频请求场景下未必优于融合部署（本文未讨论此对照）。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "PD分离就是'分工合作'，让Prefill和Decode各自使用最适合的GPU，从而提升效率和吞吐量，但也需要解决通信、调度、内存等方面的挑战。"
|
||||
|
||||
> "KV Cache的核心思想是：历史的K和V早就算好了，直接存起来，别每次都重算。"
|
||||
|
||||
> "在需要时再把数据搬回来（当然搬运有代价，所以要权衡速度和显存占用）。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 测试方案完整可复用：拓扑、对照实验设计、指标选取、三级存储卸载策略，可作为团队自建 PD 分离验证的起步模板
|
||||
- 对 PD 分离四类代价（通信/调度/实现/内存）的梳理比多数营销稿坦诚
|
||||
- 五厂商跨生态（NVIDIA+联想+DaoCloud+纳多德）联合验证，反映产业协同趋势
|
||||
|
||||
**不足**：
|
||||
- 全文无任何实测数据，全部为预期值，"2～3 倍/60%/2 倍"等数字暂不可信
|
||||
- 技术科普部分为共识性内容，无新观点；系列"上"篇性质决定了本文认知增量有限
|
||||
- 未讨论 PD 分离的适用边界（短序列场景融合部署可能更优）
|
||||
|
||||
**适用场景**：需要快速理解 PD 分离与 KV Cache Offload 原理、并计划设计类似验证实验的推理平台团队、智算中心运维与选型人员；也适合作为 PD 分离专题的入门阅读材料。
|
||||
|
||||
**关联建议**：待"下篇"实测数据发布后对照阅读；与《异构智算中心分布式PD分离推理技术的探索与实践》（中国电信 OTN 广域试验）、《LLM推理成本直降60%：PD分离在大模型商业化中的关键价值》（方案选型框架）联读可构成"原理→方案→实测"完整链条。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
# ODCC AI存储实验室KV Cache评测再发布：英韧N3X以硬核SSD性能筑牢AI推理引擎
|
||||
|
||||
> **来源**：超擎数智
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-06
|
||||
> **原文链接**：https://chaoqing-i.com/blog/odcc-ai-storage-lab-kv-cache-evaluation-innogrit-n3x-ssd
|
||||
|
||||
---
|
||||
|
||||
随着大模型发展全面迈入规模化推理部署的新阶段，推理性能、成本控制与资源利用率，正在成为智算基础设施建设的核心命题。在这一过程中，存储已不再只是数据承载的底层资源，而是影响GPU利用率、推理延迟与系统吞吐的关键变量。
|
||||
|
||||
ODCC AI存储实验室作为面向AI基础设施前沿技术验证的重要平台，依托超擎数智高性能算网环境与全栈技术服务能力，聚焦先进存算分离架构，持续开展面向AI训练、推理、存储部件与系统协同的实证测试，为行业关键技术选型与系统优化提供可量化、可复用的参考依据。
|
||||
|
||||
继ODCC AI存储实验室发布焱融YRCache推理存储系统KV Cache评测成果后，本次将进一步聚焦测试中的核心存储硬件——英韧科技洞庭-N3X，一款面向AI场景打造的企业级SSD产品。在KV Cache从GPU显存向外部存储卸载的过程中，高性能SSD正从传统意义上的"存储介质"，跃升为影响推理流水线效率的重要引擎。
|
||||
|
||||
当大模型上下文窗口持续向百万级演进，KV Cache规模急剧膨胀，GPU的HBM容量不足已成为高并发、长上下文推理场景下的典型瓶颈。此时，外部存储系统是否能够以足够低的延迟、足够高的带宽和足够稳定的IOPS响应KV Cache读写请求，直接影响首Token延迟、单Token输出时间以及GPU整体利用率。
|
||||
|
||||
在本次ODCC AI存储实验室的KV Cache专项测试中，英韧洞庭-N3X凭借卓越的单盘性能，为存储系统实现推理提速、长上下文支撑与成本优化提供了坚实的硬件底座。
|
||||
|
||||
## 1、构建KV Cache全栈验证环境
|
||||
|
||||
本次专项测试，超擎数智在ODCC AI存储实验室中提供了贴近真实智算中心部署场景的基础设施环境，包括高性能GPU服务器、分布式存储集群、高速网络拓扑以及面向大模型推理任务的系统测试平台。通过这一环境，实验室能够从"部件—系统—应用"多个维度，对AI推理存储方案进行端到端评估。
|
||||
|
||||
本次，英韧科技洞庭-N3X承担了存储集群的核心硬件支撑任务。作为面向AI场景打造的企业级SSD产品，洞庭-N3X采用PCIe Gen5接口与优化的数据引擎，围绕高带宽、低延迟、高并发、稳态输出等关键能力进行设计，目标直指大模型训练与推理过程中的"内存墙"问题。
|
||||
|
||||
在KV Cache卸载场景中，SSD不再只是冷数据的仓库，而是持续参与推理数据流转的高频访问介质。其性能水平将直接决定GPU能否持续获得数据供给，进而影响整个推理系统是否能够保持高吞吐、低延迟运行。
|
||||
|
||||
|
||||
|
||||
## 2、单盘性能硬核突破，为KV Cache高效流转提供物理基础
|
||||
|
||||
KV Cache读写具有典型的高并发、高随机、小I/O访问特征，同时在缓存预加载、批量迁移、长上下文处理等场景下，也对顺序带宽提出了极高要求。ODCC AI存储实验室测试结果显示，英韧洞庭-N3X在顺序带宽、随机IOPS以及稳态输出能力上均展现出突出的单盘性能优势。
|
||||
|
||||
**14GB/s顺序带宽 支撑存储系统高效数据迁移**
|
||||
|
||||
在需要预加载KV Cache或进行批量缓存数据迁移的场景中，顺序带宽直接决定数据搬运效率。测试显示，英韧洞庭-N3X顺序读速度达到14GB/s，顺序写速度逼近12GB/s，充分释放PCIe Gen5接口的传输潜力。
|
||||
|
||||
对于AI推理系统而言，这意味着在大规模长上下文任务启动、缓存批量加载或跨节点数据迁移过程中，底层SSD能够为上层存储系统提供更高效的数据供给能力，减少数据准备时间，提升整体推理链路的响应效率。
|
||||
|
||||
|
||||
|
||||
**稳态随机读写超千万IOPS 让存储系统持久输出**
|
||||
|
||||
KV Cache在推理阶段的访问模式并非单纯的大块顺序读写，而是大量并发随机小I/O请求。尤其在多用户并发、长上下文复用、缓存命中与卸载回读场景中，SSD的随机读写性能与稳态表现尤为关键。
|
||||
|
||||
在基准测试中，英韧洞庭-N3X的4KB随机读性能接近3500K IOPS，4KB随机写性能达到756.72K IOPS，均高于标称性能。凭借全盘稳态下的持续IOPS输出能力，搭载N3X的存储系统在整个评测过程中保持稳定运行，能够持续高效响应KV Cache读写请求。
|
||||
|
||||
这也进一步说明，在AI推理存储架构中，企业级SSD的价值不仅体现在峰值性能，更体现在长时间高负载运行下的稳定输出能力。对于真实智算中心而言，这一能力直接关系到系统服务质量与推理任务的稳定性。
|
||||
|
||||
|
||||
|
||||
## 3、从单盘到系统：高性能SSD放大KV Cache卸载收益
|
||||
|
||||
ODCC AI存储实验室KV Cache专项测试并未停留在单盘基准层面，而是进一步将英韧洞庭-N3X纳入真实推理系统链路，与推理存储系统、高速网络和GPU服务器进行联合验证。
|
||||
|
||||
测试结果显示，N3X的单盘性能优势能够有效转化为系统级收益，在延迟、吞吐、GPU利用率与成本结构等方面形成显著提升。
|
||||
|
||||
**微秒级尾延迟，为存储系统提供"零等待"基础**
|
||||
|
||||
在大模型推理过程中，Decode阶段需要持续访问与更新KV Cache。此时，存储路径的尾延迟将直接影响Token生成的连续性与稳定性。
|
||||
|
||||
本次测试显示，在采用高端GPU的服务器节点上，英韧洞庭-N3X实现了低至66μs的P99延迟，写入延迟稳定控制在微秒级。得益于这一低延迟能力，搭载N3X的存储系统在KV Cache卸载场景中能够实现近乎"零感知"的数据写入与读取支撑，使GPU在执行推理任务时尽可能减少因数据等待造成的空转。
|
||||
|
||||
|
||||
|
||||
对于上层应用而言，这意味着长文本生成、多轮对话、代码生成、文档分析等场景能够获得更流畅的生成体验；对于智算中心而言，则意味着GPU资源能够被更充分利用，单位算力投入产出比进一步提升。
|
||||
|
||||
**吞吐量显著提升，中端GPU推理效能接近高端**
|
||||
|
||||
在长上下文和高并发任务中，GPU显存容量往往成为限制吞吐提升的关键因素。当KV Cache能够通过高性能存储系统实现高效卸载后，GPU显存压力得到释放，推理并发能力与吞吐表现随之显著提升。
|
||||
|
||||
测试结果显示，在输入长度大于等于10K Token的场景下，基于英韧洞庭-N3X的存储系统使首Token延迟从秒级降至毫秒级；在特定缓存命中场景下，加速比可达百倍。吞吐量方面，中端GPU服务器提升约20倍，高端GPU服务器提升约12倍。
|
||||
|
||||
|
||||
|
||||
这一结果具有重要产业价值。它表明，通过高性能SSD与推理存储系统的协同优化，高性价比的中端GPU也能够在部分长上下文推理场景中展现出接近高端GPU的系统级效能。
|
||||
|
||||
对于正在建设或扩容智算中心的企业而言，这为基础设施选型提供了新的思路：推理性能的提升不再只能依赖单向堆叠高端GPU，也可以通过"以存强算"的系统架构创新，释放中端算力资源潜能，从而实现更优的成本结构。
|
||||
|
||||
**存储与网络协同，高速算网进一步放大卸载收益**
|
||||
|
||||
本次测试还围绕不同网络带宽环境下的KV Cache卸载效果进行了对比分析。结果显示，在存储池能够满足网络带宽需求的前提下，网络带宽越高，推理吞吐量提升越显著。
|
||||
|
||||
针对中端GPU服务器，当网络从400G进一步提升至800G乃至1.6T时，KV Cache卸载的加速效果呈增长态势。高速网络与英韧洞庭-N3X的高读写性能形成协同，使PD阶段的数据流转效率持续提升，进一步减少数据搬运对GPU推理任务的影响。
|
||||
|
||||
|
||||
|
||||
## 4、软硬协同验证路径，推动AI存储从部件走向系统标准
|
||||
|
||||
本次ODCC AI存储实验室KV Cache测试，联合焱融YRCache推理存储系统与英韧洞庭-N3X企业级SSD，实现了从存储软件到硬件底层的深度协同验证。
|
||||
|
||||
从测试结果来看，YRCache通过多级KV缓存架构，有效调度GPU显存、主机内存、本地NVMe SSD以及分布式文件存储，突破单一显存容量边界；**英韧洞庭-N3X则以高带宽、低延迟、高IOPS与稳态输出能力，为KV Cache卸载提供坚实的硬件基础。** 二者协同，使存储系统真正进入AI推理主路径，成为释放算力、降低成本、提升并发的关键支点。
|
||||
|
||||
更重要的是，本次测试再次体现了超擎数智在ODCC AI存储实验室中测试环境与测试服务的专业。依托超擎数智在"存储-算力-网络"方面的综合能力，能围绕AI基础设施中的关键瓶颈问题，组织产业链上下游开展真实环境下的联合验证。
|
||||
|
||||
这不仅为存储场景的关键部件选型提供了数据依据，也为智算中心在AI推理场景下构建高性价比、高效率、高稳定性的系统架构提供了实践参考。
|
||||
|
||||
## 5、以存强算，超擎数智携手生态伙伴共建AI基础设施新范式
|
||||
|
||||
随着大模型推理规模持续扩大，KV Cache的存储与管理正在成为AI基础设施架构演进中的核心议题。超擎数智将持续发挥高性能算网环境与全栈技术服务能力，围绕KV Cache、AI存储系统、企业级SSD、高速网络、GPU集群等关键方向，推进"部件—系统—应用"的全链路协同测试。
|
||||
|
||||
本次英韧洞庭-N3X的测试结果表明，高性能SSD正在成为AI推理时代不可或缺的关键支撑。未来，ODCC AI存储实验室将继续携手更多产业生态伙伴，以系统化测试、标准化评估和实证化数据，助力AI存储技术加速成熟，推动智算基础设施从"以算为中心"走向"存算协同、以存强算"的新阶段。
|
||||
@@ -0,0 +1,82 @@
|
||||
# 📊 文章摘要：ODCC AI存储实验室KV Cache评测再发布：英韧N3X以硬核SSD性能筑牢AI推理引擎
|
||||
|
||||
> **原文**：[2026-08-06_ODCC_AI存储实验室KV_Cache评测再发布_英韧N3X以硬核SSD性能筑牢AI推理引擎.md](./2026-08-06_ODCC_AI存储实验室KV_Cache评测再发布_英韧N3X以硬核SSD性能筑牢AI推理引擎.md)
|
||||
> **原文链接**：https://chaoqing-i.com/blog/odcc-ai-storage-lab-kv-cache-evaluation-innogrit-n3x-ssd
|
||||
> **来源**：超擎数智
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-06
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **以存强算** — 在 KV Cache 卸载场景中，高性能企业级 SSD（英韧洞庭-N3X）从"存储介质"跃升为推理流水线关键引擎，以存储系统优化释放中端 GPU 算力潜能，为智算中心选型提供"以存强算"的新思路。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文报道 ODCC AI 存储实验室基于超擎数智算网环境、联合焱融 YRCache 推理存储系统与英韧科技洞庭-N3X 企业级 SSD 的 KV Cache 专项评测。评测数据显示：N3X 顺序读 14GB/s、顺序写约 12GB/s，4K 随机读近 3500K IOPS、随机写 756.72K IOPS，P99 延迟低至 66μs；系统级验证中，输入 ≥10K Token 场景下首 Token 延迟从秒级降至毫秒级，中端 GPU 吞吐提升约 20 倍、高端提升约 12 倍，且网络从 400G 升至 1.6T 时卸载加速效果持续增长。文章的核心贡献是给出 KV Cache 卸载场景下 SSD 的关键选型指标（顺序带宽/随机 IOPS/稳态输出/尾延迟），并提出"以存强算"替代单向堆叠高端 GPU 的架构思路；但评测由利益相关方组织，数据口径需批判看待。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **SSD进入推理主路径** — KV Cache 卸载场景下 SSD 不再是冷数据仓库，而是持续参与数据流转的高频访问介质，其性能直接决定 GPU 能否获得持续数据供给。`[分类: 共识]`
|
||||
2. **KV Cache负载特征倒逼存储选型** — KV Cache 读写呈高并发、高随机、小 I/O 特征，同时预加载/批量迁移/长上下文场景要求高顺序带宽，因此四维指标（顺序带宽、随机 IOPS、稳态输出、尾延迟）决定卸载收益。`[分类: 共识]`
|
||||
3. **单盘性能实证** — N3X 顺序读 14GB/s、写约 12GB/s（PCIe Gen5），4K 随机读近 3500K IOPS、随机写 756.72K IOPS，P99 延迟 66μs 且全盘稳态持续输出。`[分类: 争议]`（数据由利益相关方实验室发布，未见第三方复核）
|
||||
4. **系统级收益放大** — ≥10K Token 场景首 Token 延迟秒级→毫秒级，特定缓存命中场景加速比可达百倍；中端 GPU 吞吐提升约 20 倍、高端约 12 倍，表明中端 GPU 在长上下文场景可接近高端 GPU 效能。`[分类: 争议]`
|
||||
5. **网络带宽与存储协同放大卸载收益** — 存储池带宽满足前提下，网络从 400G 提升至 800G/1.6T 时卸载加速效果呈增长态势，提示"存储+网络"需联合规划。`[分类: 未探索方向]`
|
||||
6. **"以存强算"的选型新思路** — 推理性能提升不再只能靠堆高端 GPU，可通过存储系统优化释放中端算力潜能，实现更优成本结构。`[分类: 范式突破]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设外部存储（SSD）的延迟与带宽足以承载 Decode 阶段高频 KV Cache 读写而不拖累 GPU，且评测环境（高端 GPU 节点、特定网络）可代表真实智算中心；"20 倍/12 倍/百倍"数字建立在特定缓存命中场景与 ≥10K Token 长上下文前提之上。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
单盘基准数据详实（带宽/IOPS/延迟均有具体数值），支撑"N3X 单盘性能强"的结论；但系统级结论（吞吐提升 20 倍/12 倍）只给出结果未给出对照条件（与什么基线对比、存储命中率、GPU 型号、并发规模），且评测主体——ODCC AI 存储实验室依托超擎数智环境、评测对象英韧为生态合作伙伴、文章由超擎发布，三重利益相关使证据独立性打折，论证链条存在"以单盘性能替代系统收益"的跳跃。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论适用于"长上下文（≥10K Token）+ KV Cache 卸载 + 存储池带宽充足"场景，短上下文或显存充裕场景收益递减；"以存强算"仅论证了可行性与部分收益，未量化对比"存储系统投入 vs 高端 GPU 差价"的经济性；首 Token 延迟"秒级降至毫秒级""百倍加速"为特定缓存命中场景口径，不可泛化为一般推理负载。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "存储已不再只是数据承载的底层资源，而是影响GPU利用率、推理延迟与系统吞吐的关键变量。"
|
||||
|
||||
> "推理性能的提升不再只能依赖单向堆叠高端GPU，也可以通过'以存强算'的系统架构创新，释放中端算力资源潜能，从而实现更优的成本结构。"
|
||||
|
||||
> "英韧洞庭-N3X则以高带宽、低延迟、高IOPS与稳态输出能力，为KV Cache卸载提供坚实的硬件基础。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 提供 KV Cache 卸载场景下 SSD 的完整选型指标集（顺序带宽/随机 IOPS/稳态/尾延迟），对存储选型有直接参考价值
|
||||
- "以存强算"视角（存储优化释放中端算力）为智算中心成本优化提供新思路
|
||||
- 存储与网络协同（400G→1.6T）的数据点有产业规划参考意义
|
||||
|
||||
**不足**：
|
||||
- 利益相关显著（实验室依托发布方环境、评测对象为合作伙伴），数据独立性存疑，需第三方复核
|
||||
- 系统级收益（20 倍/12 倍/百倍）缺对照基线与测试细则，易被误读为普适性能
|
||||
- 经济性论证缺失：未对比存储投入与 GPU 采购成本，无法支撑成本结论
|
||||
|
||||
**适用场景**：智算中心存储选型与架构规划人员；关注 KV Cache 卸载落地、GPU 利用率的推理平台团队；评估"以存强算"路线的产业决策者。
|
||||
|
||||
**关联建议**：与《下一代推理优化技术……测试（上）》的 HBM/DDR/NVMe 三级卸载设计联读，理解 SSD 在分层中的冷数据定位；对照焱融 YRCache 首轮评测与 ODCC 后续发布验证数据一致性；经济性判断可参考行业对 HBM vs SSD 卸载的 TCO 对比研究。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
# 异构智算中心分布式PD分离推理技术的探索与实践
|
||||
|
||||
> **来源**：通信世界网
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-05（原文未标注，按下载日期）
|
||||
> **原文链接**：https://www.cww.net.cn/article?id=604206
|
||||
|
||||
---
|
||||
|
||||
**通信世界网消息**（CWW）为应对大模型推理的海量算力需求，整合多智算中心资源实现分布式Prefill-Decode Separation（PD分离推理），成为突破单智算中心算力瓶颈的关键路径。但智算中心建设初期的协同规划缺失导致拓扑、硬件、协议等异构问题明显，制约了技术的有效普及。本文阐述了异构智算中心的形成背景与PD分离推理的技术优势，剖析了异构智算中心分布式PD分离推理技术面临的海量KV Cache（键值存储缓存）传输、跨中心资源调度与负载均衡、异构适配三大核心挑战，并梳理国内外在解决上述核心挑战方面的探索成果。此外，本文介绍了中国电信在该方面的探索与实践，展示了中国电信在OTN广域互联场景下，异构智算中心分布式PD分离推理的业务试验。通过分析该试验的性能结果，证明该技术可有效"盘活"存量算力，为大模型分布式推理的规模化部署提供技术参考与实践范式。
|
||||
|
||||
## 分布式PD分离推理技术的现实意义
|
||||
|
||||
近年来，人工智能大模型在自然语言处理、计算机视觉等领域取得了突破性进展。然而，大模型推理任务对算力的需求极为庞大，单个智算中心难以满足日益增长的业务需求。为应对这一挑战，分布式推理架构结合PD分离技术，将大模型推理任务的P阶段（Prefill）和D阶段（Decode）有效分离，成为高效推理的主流解决方案。
|
||||
|
||||
在大模型推理中，P阶段属于计算密集型，D阶段属于访存密集型，两者分别依赖GPU的计算核心与显存的带宽。当两阶段共用GPU服务器时，容易造成资源不适配，导致算力浪费；而PD分离可通过阶段专属优化，避免两阶段算力资源抢占，提升资源利用率，保障推理延迟的稳定性。
|
||||
|
||||
在大模型实际部署中，由于智算中心在建设时未充分考虑各中心间的协同规划，导致拓扑结构、传输协议、GPU硬件及集合通信库等多个方面异构显著。因此，异构智算中心分布式PD分离推理的技术探索极具现实意义。
|
||||
|
||||
## 分布式PD分离推理的技术挑战
|
||||
|
||||
### 分布式PD分离推理的固有挑战
|
||||
|
||||
一是海量KV Cache传输挑战。在分布式PD分离推理中，P阶段和D阶段分布在不同智算中心，要求KV Cache在不同物理节点间传输。此外，单推理请求KV Cache数据量较大，且推理任务请求常在智算中心中并行处理，这进一步加剧智算中心间链路带宽、时延以及可靠性压力。网络性能不足将严重影响推理体验，甚至抵消PD分离带来的效率收益。
|
||||
|
||||
二是资源池调度与负载均衡挑战。大模型分布式PD分离推理常配置任务调度器，在多个可选智算中心间选择最合适的资源池，同时承担负载监控、任务时长预测、KV Cache协同传输等任务，以实现全局最优资源分配。该需求导致调度器设计复杂度极高，优化性能与智能性面临巨大挑战。此外，多模型并发部署易引发智算中心资源竞争，导致部分智算中心资源紧张，出现过载；另一部分智算中心资源闲置，形成"孤岛"，导致整个网络资源利用率下降。因此，实时监测资源状态与流量变化并动态调整，成为维持系统性能的关键所在。
|
||||
|
||||
### 异构智算中心的衍生挑战
|
||||
|
||||
一是硬件与集合通信库适配挑战。异构智算中心常部署不同设备，引入差异化硬件架构、指令集与集合通信库，导致数据格式不兼容，跨智算中心任务通信效率低下甚至中断。例如，英伟达与昇腾GPU的集合通信库完全不同，在一般情况下无法通信。
|
||||
|
||||
二是协议转换挑战。RoCE（基于融合以太网的远程直接内存访问）、IB（无限带宽）等主流协议，与GSE（全调度以太网）、UEC（超以太网联盟）等新型协议在技术原理和设计目标上均存在差异，使得跨协议转换存在技术壁垒，异构智算中心难以高效协同。
|
||||
|
||||
## 业界探索
|
||||
|
||||
### 海量KV Cache传输优化
|
||||
|
||||
海量KV Cache传输的核心难点在于平衡传输效率与数据可靠性，该挑战可从硬件协议、软件编码和网络策略三个方面进行优化。在硬件协议方面，业界常采用IB/RoCE协议通过RDMA（远程直接内存访问）技术直接从内存抓取或存储数据，无需CPU参与，减少硬件接口交互，进而降低传输延迟。从软件编码方面入手，提出算法压缩KV Cache体积技术，以减少传输数据量。在网络策略方面，通过优化广域网络路由策略，利用多路径传输KV Cache数据。
|
||||
|
||||
### 算力资源调度与负载均衡优化
|
||||
|
||||
算力资源调度与负载均衡优化需要构建全局感知的智能调度系统，融合状态监控、预测算法与协同策略等不同模块。业界学者设计了两级分层数据中心调度程序Qin，将集群级与节点级调度算法整合，构建统一调度目标，缩短任务完成时间；还有学者提出升级后的调度程序Qin2，引入自动特征选择技术，精确预测任务负载，优化负载平衡效果；业界学者利用深度强化学习动态调整算力资源分布，实现算力资源高利用率与低损失率。
|
||||
|
||||
### 异构硬件与协议适配优化
|
||||
|
||||
异构硬件与协议适配优化须突破硬件兼容性与协议互通性瓶颈，关键技术包括统一通信接口与柔性协议转换。由于英伟达的硬件产品占据国际市场主导地位，业界并未过多关注该方向影响，导致相关研究较少。而国内因近年国产GPU崛起并快速占据市场，异构硬件协同需求强烈，但相关研究依然处于初期阶段。不过，"2024世界人工智能大会""2024数字科技生态大会"上亮相的异构芯片混训方案，标志着该领域研究逐步深入。
|
||||
|
||||
## 中国电信对异构智算中心分布式PD分离推理的探索
|
||||
|
||||
2025年7月，中国电信开展异构智算中心PD分离推理拉远验证组网，选取英伟达、沐曦两家厂家GPU，基于DeepSeek-R1蒸馏模型验证异构远距离协同推理的可行性。该试验不断调整输入、输出序列的长度、并发速率等参数，获取TTFT、TPOT、Throughput等性能指标，寻找不同推理任务的最优推理状态。同时，该试验将OTN拉远距离从200km延伸至800km，并使用损伤仪造成丢包引发RDMA重传，以此模拟真实网络环境。在该环境中，试验通过将出口带宽收敛比逐步扩大至64:1，配合ECN/PFC（网络拥塞管理）流控机制，进行长距离、低链路带宽的异构智算中心PD分离推理极限性能探索。
|
||||
|
||||
经过推理参数和网络参数的不断调整与组合，在OTN广域互联情况下，试验得到了异构GPU间PD分离推理性能的变化规律，为今后现网部署提供了可靠的数据支撑。此外，试验结果也表明，异构智算中心PD分离推理方案可行，在无损网络低延迟、高吞吐的环境下，可保证带宽收敛比64:1、万米级长距传输性能均达到本地同推理场景的99%，充分满足推理服务的性能要求。而随着进一步网络质量下降、拉远距离增大、收敛带宽增加，性能指标下降可控制在1%～5%。该结论可在一定程度证明，在保障推理性能的前提下，异构智算中心分布式PD分离推理方案可实现异构存量算力的"盘活"。
|
||||
|
||||
## 结语
|
||||
|
||||
异构智算中心分布式PD分离推理作为一种新兴技术，为解决大模型推理面临的算力挑战提供了新思路。尽管在实践过程中面临着KV Cache传输、算力资源调度与负载均衡、异构适配等诸多挑战，但国内外均已进行了一定的研究和探索。中国电信的试验验证为业界提供了宝贵的经验，证明了该技术的可行性，可满足推理服务的资源与性能要求，实现现网异构存量算力的盘活。未来，随着技术的不断进步和创新，以及硬件标准化、协议统一化及算法智能化的升级，异构智算中心分布式PD分离推理技术有望在更多领域得到应用，为人工智能的发展提供更强大的支持。
|
||||
@@ -0,0 +1,81 @@
|
||||
# 📊 文章摘要：异构智算中心分布式PD分离推理技术的探索与实践
|
||||
|
||||
> **原文**：[2026-08-05_异构智算中心分布式PD分离推理技术的探索与实践.md](./2026-08-05_异构智算中心分布式PD分离推理技术的探索与实践.md)
|
||||
> **原文链接**：https://www.cww.net.cn/article?id=604206
|
||||
> **来源**：通信世界网
|
||||
> **作者**：未知
|
||||
> **发布日期**：2026-08-05
|
||||
> **摘要日期**：2026-08-06
|
||||
> **价值评级**：⭐⭐⭐ 高
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **广域PD分离实证** — 中国电信以 OTN 广域互联（200-800km、64:1 带宽收敛比、模拟丢包）完成异构 GPU 分布式 PD 分离推理试验，证明可"盘活"存量算力，为跨智算中心推理规模化部署提供一手量化边界。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
本文针对单智算中心算力瓶颈，系统阐述异构智算中心分布式 PD 分离推理的背景、三大核心挑战与国内外探索，核心贡献是中国电信 2025 年 7 月的广域拉远验证试验：基于英伟达+沐曦异构 GPU、DeepSeek-R1 蒸馏模型，在 OTN 互联下将拉远距离延伸至 800km，并用损伤仪制造丢包触发 RDMA 重传，探索收敛比扩大至 64:1 时的极限性能。试验结论是：无损网络低延迟高吞吐环境下，64:1 收敛比、万米级长距传输性能可达本地同场景的 99%，网络质量下降时性能下降控制在 1%-5%。该实证将 PD 分离从数据中心内扩展到跨中心广域场景，是本文最大的认知增量。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **分布式PD分离是突破单中心瓶颈的关键路径** — P 阶段计算密集、D 阶段访存密集，两阶段共用 GPU 造成资源不适配；分离后按阶段专属优化，但前提是跨中心协同规划缺失导致的异构问题。`[分类: 共识]`
|
||||
2. **三大核心挑战** — 海量 KV Cache 跨中心传输（链路带宽/时延/可靠性压力，网络不足可"抵消PD分离带来的效率收益"）、跨中心资源调度与负载均衡（调度器复杂度极高、易形成资源"孤岛"）、异构适配（英伟达与昇腾集合通信库互不兼容、RoCE/IB 与 GSE/UEC 协议转换壁垒）。`[分类: 共识]`
|
||||
3. **OTN广域试验量化边界** — 800km 拉远、出口带宽收敛比 64:1、损伤仪模拟丢包触发 RDMA 重传、ECN/PFC 流控配合下，异构 GPU 间 PD 分离推理性能可达本地同场景 99%，性能劣化可控在 1%-5%。`[分类: 争议]`（单次试验口径，未见完整测试细则）
|
||||
4. **"盘活"存量算力** — 试验证明异构存量 GPU（英伟达+沐曦）可跨中心协同推理，为"以存量替代新建"的算力供给思路提供实证支撑。`[分类: 未探索方向]`
|
||||
5. **国产化催生的异构需求** — 英伟达主导国际市场使异构适配研究长期不受重视，国内国产 GPU 崛起使该方向研究从"2024世界人工智能大会"的混训方案起步，仍处初期。`[分类: 未探索方向]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
作者假设分布式 PD 分离的跨中心收益（资源整合、算力盘活）能抵消 KV 传输、调度、异构适配的工程代价；试验假设无损网络与流控机制（ECN/PFC）在现网可复现，且试验模型（DeepSeek-R1 蒸馏）与并发规模可代表生产负载。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
论据强度在同类文章中属上乘：试验有时间、厂商（英伟达+沐曦）、网络形态（OTN、损伤仪、收敛比）与量化结果（99%、1%-5%），逻辑链完整；但结论"性能可达本地 99%"建立在对参数"不断调整与组合"后的最优状态上，是调优后结果而非典型运行态，"1%-5%"劣化区间的测量条件也需更多细节支撑。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
结论适用于"无损网络、低延迟高吞吐"前提，带宽收敛比与距离超出 64:1/800km 范围、或网络质量进一步恶化时收益边界未给出；试验基于特定硬件对与单一模型，跨厂商组合（如更多国产芯片）泛化性未验证；"盘活存量"的经济性（OTN 租用成本 vs 新建中心）未讨论。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "网络性能不足将严重影响推理体验，甚至抵消PD分离带来的效率收益。"
|
||||
|
||||
> "在无损网络低延迟、高吞吐的环境下，可保证带宽收敛比64:1、万米级长距传输性能均达到本地同推理场景的99%，充分满足推理服务的性能要求。"
|
||||
|
||||
> "该结论可在一定程度证明，在保障推理性能的前提下，异构智算中心分布式PD分离推理方案可实现异构存量算力的'盘活'。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 罕见的广域（800km）+异构（英伟达/沐曦）+劣化模拟（丢包/收敛比）一手试验数据，填补 PD 分离广域实证空白
|
||||
- 三大挑战归纳（传输/调度/异构适配）覆盖了分布式 PD 分离区别于单中心的核心矛盾
|
||||
- 对国内异构适配研究的现状定位（初期、国产化驱动）有产业视野
|
||||
|
||||
**不足**：
|
||||
- 单次试验、调优后的最优口径，缺典型负载与多组对照数据
|
||||
- 作者为媒体转述，试验细节（拓扑图、完整参数矩阵）缺失，独立核查难度大
|
||||
- "盘活存量"仅论证可行性，未量化经济性
|
||||
|
||||
**适用场景**：智算中心规划、算力网络（尤其 OTN 广域）组网决策者；研究跨中心推理调度与 KV 传输的研究人员；关注国产算力协同的产业分析师。
|
||||
|
||||
**关联建议**：对照《LLM推理成本直降60%：PD分离在大模型商业化中的关键价值》理解单中心 PD 分离实现细节；后续关注 GSE/UEC 新型协议与异构集合通信（如中国电信"星脉"类方案）进展，验证 64:1 收敛比在更大规模现网的复现性。
|
||||
|
||||
---
|
||||
|
||||
## 配图
|
||||
|
||||
|
||||
@@ -14,6 +14,144 @@
|
||||
- 360 x 276
|
||||
- 540 x 414
|
||||
|
||||
## 2026-08-06
|
||||
|
||||
- [PD分离技术原理](https://zhuanlan.zhihu.com/p/27836625742)
|
||||
- 
|
||||
- 
|
||||
- **Prefill 吃算力、Decode 吃带宽——两个阶段特性相反，混在一起永远无法同时最优；拆开分池、各配最优硬件与策略，才是推理引擎的架构正道。**
|
||||
- 认知层： [LLM PD 分离背后的架构问题](https://zhuanlan.zhihu.com/p/27836625742)
|
||||
- 摘要：[查看](../知乎专栏/极客博哥/2026-08-05_LLM_PD_分离背后的架构问题_摘要.md)
|
||||
- 认知层： [大模型系列：深度解析 Prefill-Decode 分离式部署架构](https://zhuanlan.zhihu.com/p/1918334902492963669)
|
||||
- 摘要：[查看](../知乎专栏/猫先生/2025-06-17_大模型系列_深度解析_Prefill-Decode_分离式部署架构_摘要.md)
|
||||
- 认知层： [【推理】PD分离的绝佳入门教程——DistServe](https://zhuanlan.zhihu.com/p/19666783423)
|
||||
- 摘要：[查看](../知乎专栏/Zoe Lee/2026-08-05_推理_PD分离的绝佳入门教程_DistServe_摘要.md)
|
||||
- 认知层： [大模型学习 | PD分离详解](https://zhuanlan.zhihu.com/p/2001354095441757984)
|
||||
- 摘要：[查看](../知乎专栏/秋月如珪/2026-02-02_大模型学习_PD分离详解_摘要.md)
|
||||
- 认知层： [大模型推理 PD 分离技术：核心原理、技术优势、挑战与未来展望](https://www.eet-china.com/mp/a412848.html)
|
||||
- 摘要：[查看](../电子工程专辑/2026-08-05_大模型推理PD分离技术_核心原理_技术优势_挑战与未来展望_摘要.md)
|
||||
- 认知层： [【大模型】深入解析大模型推理架构之 Prefill-Decode Disaggregation](https://blog.csdn.net/Zlyzjiabjw547479/article/details/149499063)
|
||||
- 摘要：[查看](../CSDN博客/烟锁池塘柳0/2025-07-21_大模型_深入解析大模型推理架构之_Prefill-Decode_Disaggregation_(PD分离)_摘要.md)
|
||||
|
||||
- [PD分离实测数据](https://zhuanlan.zhihu.com/p/1919794916504114120)
|
||||
- 
|
||||
- 
|
||||
- **一手实测是打破宣传神话的唯一尺子——真实负载吞吐 +20%~50%、KV 传输 1.5x 优化、ITL 毛刺消除，一切收益都要以实测为准。**
|
||||
- 实践层： [LLM关于PD分离的最新实测](https://zhuanlan.zhihu.com/p/1919794916504114120)
|
||||
- 摘要：[查看](../知乎专栏/akaihaoshuai/2025-06-22_LLM关于PD分离的最新实测_摘要.md)
|
||||
- 实践层： [下一代推理优化技术：高性能网络驱动的PD分离与KV Cache Offload测试](https://chaoqing-i.com/blog/next-gen-inference-optimization-pd-separation-kv-cache-offload-test)
|
||||
- 摘要：[查看](../超擎数智/2026-08-05_下一代推理优化技术_高性能网络驱动的PD分离与KV_Cache_Offload测试_上_摘要.md)
|
||||
- 实践层： [1.5x提升：PD分离KV cache传输的实践经验](https://zhuanlan.zhihu.com/p/1946608360259577576)
|
||||
- 摘要：[查看](../知乎专栏/PD分离传输优化联合团队/2026-08-05_1.5x提升_PD分离KV_cache传输的实践经验_摘要.md)
|
||||
- 实践层： [异构智算中心分布式PD分离推理技术的探索与实践](https://www.cww.net.cn/article?id=604206)
|
||||
- 摘要：[查看](../通信世界网/2026-08-05_异构智算中心分布式PD分离推理技术的探索与实践_摘要.md)
|
||||
- 实践层： [ODCC AI存储实验室KV Cache评测](https://chaoqing-i.com/blog/odcc-ai-storage-lab-kv-cache-evaluation-innogrit-n3x-ssd)
|
||||
- 摘要：[查看](../超擎数智/2026-08-06_ODCC_AI存储实验室KV_Cache评测再发布_英韧N3X以硬核SSD性能筑牢AI推理引擎_摘要.md)
|
||||
|
||||
- [PD分离工程落地](https://docs.vllm.ai/en/latest/features/disagg_prefill/)
|
||||
- 
|
||||
- 
|
||||
- **vLLM/SGLang 原生支持、官方文档给出真实参数——PD分离已从论文走进开源框架，落地要过“KV 传输、P:D 配比、平台集成”三道工程关。**
|
||||
- 总纲： [vLLM 官方文档：Disaggregated Prefilling (experimental)](https://docs.vllm.ai/en/latest/features/disagg_prefill/)
|
||||
- 摘要：[查看](../vLLM官方文档/2026-07-29_Disaggregated_Prefilling_experimental_vLLM_摘要.md)
|
||||
- 总纲： [SGLang 官方文档：PD Disaggregation](https://docs.sglang.com.cn/advanced_features/pd_disaggregation.html)
|
||||
- 摘要：[查看](../SGLang官方文档/2025-12-30_PD_分离_PD_Disaggregation_SGLang_框架_摘要.md)
|
||||
- 根基层： [vLLM PD 分离（源码级机制）](https://mp.weixin.qq.com/s/p6gh4hK25PujQ1UJzFTbLg)
|
||||
- 摘要：[查看](../微信公众平台/marcus/2026-08-05_vLLM_PD分离_源码级机制_marcus_摘要.md)
|
||||
- 实践层： [LLM 做 PD 分离后，怎么更慢了？](https://mp.weixin.qq.com/s/0HlmtIuPGU7QE5r1fyhcsA)
|
||||
- 摘要：[查看](../微信公众平台/丁师兄/2026-08-05_LLM做PD分离后怎么更慢了_丁师兄_摘要.md)
|
||||
- 总纲： [PD 分离推理架构详解](https://cloud.tencent.com/developer/article/2586469)
|
||||
- 摘要：[查看](../腾讯云开发者社区/cr7258/2025-09-21_PD_分离推理架构详解_摘要.md)
|
||||
- 实践层： [pd分离在vllm中用法](https://blog.csdn.net/qq_44319972/article/details/155456852)
|
||||
- 摘要：[查看](../CSDN博客/小徐炸酱面/2025-12-01_pd分离在vllm中用法_摘要.md)
|
||||
- 生态层： [LMCache 博客](https://blog.lmcache.ai/)
|
||||
- 摘要：[查看](../LMCache博客/LMCache_Team/2026-08-06_LMCache_博客文章列表_摘要.md)
|
||||
|
||||
- [厂商方案与产业生态](https://mp.weixin.qq.com/s/kdxJng0X3RT2UU8EnuxeSw)
|
||||
- 
|
||||
- 
|
||||
- **从 UCSD 论文到黄仁勋 GTC、从昇腾专家并行到 H3C 解耦式 Serving——PD分离已被全行业拥抱，国产异构落地路径已打通。**
|
||||
- 生态层： [揭秘老黄演讲关键技术 PD分离：UCSD 华人团队 DistServe](https://mp.weixin.qq.com/s/kdxJng0X3RT2UU8EnuxeSw)
|
||||
- 摘要：[查看](../微信公众平台/新智元/2026-08-05_揭秘老黄演讲PD分离_UCSD华人团队DistServe_新智元_摘要.md)
|
||||
- 生态层： [昇腾大规模专家并行：PD分离，让推理性能再提速30%](https://www.hiascend.com/developer/techArticles/20250423-1)
|
||||
- 摘要：[查看](../昇腾社区/2025-04-23_昇腾大规模专家并行技术解码_PD分离_让推理性能再提速30%_摘要.md)
|
||||
- 生态层： [基于 Prefill/Decode 分离的大规模推理 Serving 架构](https://www.h3c.com/cn/d_202604/2832717_233453_0.htm)
|
||||
- 摘要：[查看](../H3C新华三官网/2026-04-27_基于_Prefill_Decode_分离的大规模推理_Serving_架构_摘要.md)
|
||||
- 生态层： [LLM推理成本直降60%：PD分离在大模型商业化中的关键价值](https://developer.aliyun.com/article/1681023)
|
||||
- 摘要：[查看](../阿里云开发者社区/2025-09-09_LLM推理成本直降60%_PD分离在大模型商业化中的关键价值_摘要.md)
|
||||
- 生态层： [如何使用 NVIDIA Dynamo 减少 KV 缓存瓶颈](https://developer.nvidia.cn/blog/how-to-reduce-kv-cache-bottlenecks-with-nvidia-dynamo/)
|
||||
- 摘要：[查看](../NVIDIA_技术博客/2025-09-18_如何使用_NVIDIA_Dynamo_减少_KV_缓存瓶颈_摘要.md)
|
||||
|
||||
- [开源推理平台](https://kvcache-ai.github.io/Mooncake/index.html)
|
||||
- 
|
||||
- 
|
||||
- **Mooncake、NVIDIA Dynamo、llm-d、AIBrix——工业级开源平台把 PD分离 与分布式 KV Cache、智能路由、K8s 编排组合成完整推理底座。**
|
||||
- 总纲： [Mooncake（KVCache 中心化解耦架构）](https://kvcache-ai.github.io/Mooncake/index.html)
|
||||
- 摘要：[查看](../Mooncake_项目/2026-08-06_Welcome_to_Mooncake_摘要.md)
|
||||
- 生态层： [NVIDIA Dynamo（引擎无关的推理编排）](https://docs.nvidia.com/dynamo/latest/index.html)
|
||||
- 摘要：[查看](../NVIDIA_Dynamo_文档/2026-08-06_Welcome_to_NVIDIA_Dynamo_摘要.md)
|
||||
- 生态层： [llm-d（K8s 原生分布式推理栈）](https://llm-d.ai/docs/architecture)
|
||||
- 摘要：[查看](../llm-d/2026-08-06_llm-d_K8s原生分布式推理栈架构_摘要.md)
|
||||
- 生态层： [AIBrix（字节跳动云原生推理）](https://github.com/vllm-project/aibrix)
|
||||
- 摘要：[查看](../GitHub/字节跳动/2026-06-16_AIBrix_云原生推理_摘要.md)
|
||||
- 总纲： [cr7258/ai-infra-learning · Lesson 06 PD分离（系统化课程）](https://github.com/cr7258/ai-infra-learning/tree/main/lesson/06-disaggregating-prefill-and-decoding)
|
||||
- 摘要：[查看](../GitHub/cr7258/2026-08-06_Lesson_06_PD分离推理架构详解_摘要.md)
|
||||
|
||||
- [推理解耦学术前沿](https://arxiv.org/abs/2401.09670)
|
||||
- 
|
||||
- 
|
||||
- **从 DistServe 的 Goodput 革命到 AFD 的算子级解聚——五篇论文勾勒推理解耦从“阶段分离”走向“算子分离”的演进谱系。**
|
||||
- 根基层： [DistServe: Disaggregating Prefill and Decoding for Goodput-optimized LLM Serving](https://arxiv.org/abs/2401.09670)
|
||||
- 摘要：[查看](../arXiv/Yinmin_Zhong/2024-01-18_DistServe_摘要.md)
|
||||
- 根基层： [Splitwise: Efficient Generative LLM Inference Using Phase Splitting](https://arxiv.org/abs/2311.18677)
|
||||
- 摘要：[查看](../arXiv/Pratyush_Patel/2023-11-30_Splitwise_摘要.md)
|
||||
- 根基层： [TetriInfer: Inference without Interference](https://arxiv.org/abs/2401.11181)
|
||||
- 摘要：[查看](../arXiv/Cunchen_Hu/2024-01-20_TetriInfer_摘要.md)
|
||||
- 根基层： [Mooncake: A KVCache-centric Disaggregated Architecture](https://arxiv.org/abs/2407.00079)
|
||||
- 摘要：[查看](../arXiv/Ruoyu_Qin/2024-06-24_Mooncake_摘要.md)
|
||||
- 根基层： [How Far Can Disaggregation Go? Attention-FFN Disaggregation (AFD)](https://arxiv.org/abs/2605.28302)
|
||||
- 摘要：[查看](../arXiv/Hanjiang_Wu/2026-05-27_AFD_How_Far_Can_Disaggregation_Go_摘要.md)
|
||||
- 认知层： [当 PD 分离成为标配，推理的未来在 AFD](https://mp.weixin.qq.com/s/5YsLOl4oIfHzNdi8pbmURQ)
|
||||
- 摘要：[查看](../微信公众平台/小哥人工智能笔记/2026-08-05_当PD分离成为标配_推理的未来在AFD_摘要.md)
|
||||
|
||||
- [网络与存储基础设施](https://quant67.com/post/llm-infra/04-interconnect/04-interconnect.html)
|
||||
- 
|
||||
- 
|
||||
- **推理集群网络 200G RoCE 即可起步、KV Cache 按 HBM→DRAM→SSD 分层卸载——网络与存储是 PD分离 落地的隐形底座。**
|
||||
- 根基层： [大模型基础设施工程 04：互联与网络——NVLink、InfiniBand](https://quant67.com/post/llm-infra/04-interconnect/04-interconnect.html)
|
||||
- 摘要：[查看](../土法炼钢兴趣小组的算法知识备份/2026-04-22_大模型基础设施工程04_互联与网络_NVLink_InfiniBand_RoCE_与国产替代_摘要.md)
|
||||
- 认知层： [InfiniBand vs 以太网 GPU 集群对比：800G 网络架构决策指南](https://introl.com/zh/blog/infiniband-vs-ethernet-gpu-clusters-800g-architecture)
|
||||
- 摘要：[查看](../Introl/2026-03-27_InfiniBand_vs_以太网_GPU_集群对比_800G_网络架构决策指南_摘要.md)
|
||||
- 认知层： [GTC 解读：当我们谈论 AI 推理的 KV Cache](https://www.geekpark.net/news/361648)
|
||||
- 摘要：[查看](../极客公园/2026-03-25_GTC_解读_当我们谈论_AI_推理的_KV_Cache_我们在做什么_摘要.md)
|
||||
- 认知层： [KV Cache 缓存可卸载至 SSD：打破内存墙限制](https://www.fxbaogao.com/detail/5116282)
|
||||
- 摘要：[查看](../发现报告/国泰海通证券/2025-10-28_KV_Cache_缓存可卸载至_SSD_打破内存墙限制_AI_SSD迎来广阔成长空间_摘要.md)
|
||||
- 生态层： [Tair KVCache - 动态分级缓存（阿里云）](https://www.aliyun.com/product/kvcache)
|
||||
- 摘要：[查看](../阿里云/2025-09-23_Tair_KVCache_动态分级缓存_LLM推理缓存_数据库_阿里云_摘要.md)
|
||||
|
||||
- [Token经济与算力经营](https://introl.com/zh/blog/inference-unit-economics-true-cost-per-million-tokens-guide)
|
||||
- 
|
||||
- 
|
||||
- **每百万 token 成本三年从 20 美元降到 0.4 美元，算力资产正从“卖卡”走向“Token 工厂”经营——PD分离 是降本侧的工序。**
|
||||
- 根基层： [推理单位经济学：每百万 Token 的真实成本](https://introl.com/zh/blog/inference-unit-economics-true-cost-per-million-tokens-guide)
|
||||
- 摘要：[查看](../Introl/2026-02-09_推理单位经济学_每百万Token的真实成本_摘要.md)
|
||||
- 战略层： [底座算力跃迁到 token 工厂的新机会](https://www.fxbaogao.com/detail/5481471)
|
||||
- 摘要：[查看](../中邮证券/孙业亮_刘聪颖/2026-06-16_中邮证券_底座算力跃迁到token工厂的新机会_摘要.md)
|
||||
- 总纲： [大模型推理优化关键技术与应用实践研究报告（中国信通院）](https://www.caict.ac.cn/kxyj/qwfb/ztbg/202604/P020260415615308750699.pdf)
|
||||
- 摘要：[查看](../中国信通院/中国信息通信研究院人工智能研究所/2026-03-31_大模型推理优化关键技术与应用实践研究报告_2026年_摘要.md)
|
||||
|
||||
- [AI组织与宏观](https://mp.weixin.qq.com/s/AgMLIqbA6PeGW7phFJAvOg)
|
||||
- 
|
||||
- 
|
||||
- **AI 浪潮之上：组织如何从分散提效走向 AI Native，美国政治反弹如何改写扩张模式——宏观变量决定技术落地的节奏。**
|
||||
- 实践层： [从分散提效到 AI Native 组织的实践](https://mp.weixin.qq.com/s/AgMLIqbA6PeGW7phFJAvOg)
|
||||
- 摘要：[查看](../微信公众平台/数字人BuilderAgent团队/2026-08-06_从分散提效到_AI_Native_组织的实践_摘要.md)
|
||||
- 战略层： [美国镜鉴：当AI浪潮遭遇政治反弹](https://mp.weixin.qq.com/s/OLxrS_jzJqz0z6bKIJMsfA)
|
||||
- 摘要：[查看](../微信公众平台/CF40研究部/2026-07-28_美国镜鉴_当AI浪潮遭遇政治反弹_摘要.md)
|
||||
- 生态层： [刚刚！谷歌突发最炸离职](https://mp.weixin.qq.com/s/5RcNh03rxFZMbJZKoKQvLw)
|
||||
- 摘要：[查看](../微信公众平台/深科技首席/2026-08-06_刚刚_谷歌突发最炸离职_摘要.md)
|
||||
|
||||
> **说明**：PD分离 主题下 45 条链接 + 3 条独立链接共 48 条全部完成摘要归档；今日头条转载版与 CSDN cr7258 版同源于《PD 分离推理架构详解》，复用其摘要。配图按主题分组生成（大图 2560×1440 + 列表标题图 160×90）。
|
||||
## 2026-07-31
|
||||
|
||||
- [企业AI落地](https://mp.weixin.qq.com/s/wD0aOLCrt3fbjaiGCCTEPQ)
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.3 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 805 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user