分布式推理（Distributed Inference）

所属：01-fundamentals / 06-agent-infra
面试权重：★★★
来源：《深入理解 AI Infra：量化分析与系统设计》第 9 章（李博杰，github.com/bojieli/ai-infra-book）；书中数字均有实验条件与算式，非本仓库测量
相关知识点：vllm-pagedattention.md（分页与前缀复用）、batching-parallelism.md（TP/PP/DP/EP 与 KV 复制倍数）、latency-cost.md（PD 分离的边界）、10-agent-runtime.md（任务与工具执行层的资源、隔离与恢复 —— 本篇 §6 是实例级，那篇是任务级）、../01-llm-core/kv-cache.md（GQA 与 MLA 的字节布局）

一句话#

前六篇讲的都是「一张卡怎么跑得快」（连续批处理、分页、量化、前缀缓存）；这一篇讲的是「计算与状态放在哪里」—— 四种组织方式（加完整副本 / PD 分离 / AF 分离 / 共享 KV）各自改变系统的不同部分，也各自带来不同的新增约束。判断该用哪一种，靠的是算清三种量：资源占用时间、状态传输字节、以及排队与就绪谁先到。

为什么重要（面试角度）#

• 这是「单实例优化」的天花板之后的必然一问。 面试官问完 PagedAttention 和连续批处理，往下一定是「一个实例扛不住怎么办」。只会答「加机器」的人，和能答出「先算瓶颈在 P 还是 D、状态要搬多少字节、链路够不够」的人，立刻分层。
• 它有一堆能当场推的公式和能引用的实测数字，是「有没有真算过」的分水岭。KV 交接时间、T_first = max(Q,R)+C、专家副本回本批数 —— 这些都不是背出来的形容词。
• 它专门治一个高频错误答案：「PD 分离提升吞吐」。 同构硬件上分离反而更低 7%；吞吐大幅提升只出现在异构硬件。这个反转是最容易被打穿的一处，也最能体现判断力。
• 它把「缓存亲和性路由」讲清楚，而这是 Agent / 多轮场景的核心：长前缀反复复用，路由决策必须比较完成时间，而不是看有没有命中标记。
• 它和你的项目接得上：QueWI 那个 AI 网关做的是「模型路由」，而这一篇讲的是更下一层的「实例路由」—— 同一个问题的两个尺度。

⚠️ 边界声明：本篇是《AI Infra》第 9 章的知识梳理，不是你的实战经验。你没有自己搭过多机 PD 分离集群、没做过专家副本调度。面试时用「这套账我会这么算」的口径讲，不要说成"我们线上就是这么部署的"。

核心内容#

1. 先接受一个前提：状态可能比权重还大#

第 1 节先建立量级感。Qwen3-8B 的 BF16 权重约 15 GB；而 batch size 32、上下文 8704 token 时，KV 共占 43.5 GB，约为权重的 2.7 倍（第 9.2.3 节算例）。上下文再长，状态就彻底压过权重。

这解释了为什么「分布式推理」不是「把模型切开跑」那么简单 —— 切权重是一件事，放置和搬运状态是另一件事，而后者的量级可以更大。

四种基本组织方式，各自改变系统的一个不同部分：

选择顺序：先分析当前负载的资源需求。两个阶段需求相近 → 加副本就够了，分离只会增加交接开销；许多请求共享长前缀 → 跨实例缓存可能比继续拆计算更值。先把「资源占用」和「交接时间」分别算出来，再决定加副本、分阶段还是共享状态。

2. PD 分离：三个结论，一个反转#

为什么要分。 Prefill 一次处理许多新 token，矩阵计算能充分复用权重，计算受限；decode 每步只处理一个 token，却要反复读权重和上下文，带宽受限。混跑时，一次 8192 token 的 prefill 会独占一张 A100 约 0.86 秒，相当于让卡上所有在途请求错过约 16 个 55 ms 的 decode 步。分离把两个阶段放进独立队列、独立批处理、独立资源配比。

交接的是什么：上下文 KV。 逻辑状态大小

（$n$ 层、$L$ token、$h_{kv}$ 个 KV 头、每头 $d_h$ 维、每元素 $b$ 字节，系数 2 对应 K 和 V）。Qwen3-8B（36 层、8 个 KV 头、每头 128 维）BF16 下每 token 144 KiB，8192 token 的上下文 = 1.125 GiB。沿 200 Gbit/s 网卡（25 GB/s）纯载荷约 48.3 ms。

MLA 让这份交接减半。 DeepSeek-V3 缓存的是上投影之前的潜变量（61 层、$d_c=512$、$d_r=64$），BF16 下每 token 68.6 KiB，同样 8192 token 只占 549 MiB，25 GB/s 下传输 23.0 ms。原因不是"压缩"，而是按结合律把上投影移到了查询一侧执行（代价是 D 侧每 token 多算，见 §4 的紧凑路径代价）。

另一个常被漏掉的约束：交接期间两端同时占内存。 整份双缓冲交接时，传输结束前源端保留完整状态、目的端分配完整接收缓冲 —— GQA 状态两端各 1.125 GiB，合计 2.25 GiB。分块传输能让源端收到一块确认就提前释放一块，缩短重复驻留时间。

三个关键结论（按重要性排序）：

① 同构硬件上，PD 分离不提高吞吐 —— 反而更低。 八张 A100 跑同一个模型：共置时每张卡每请求占 $0.856+1.764=2.62$ GPU 秒，八张合计 3.05 请求/s；分离后只能按整数张卡划分，三张做 P 给 3.50、五张做 D 给 2.83，上限 2.83 请求/s，比共置低 7%。原因是每个请求消耗的 GPU 秒没变，而整数划分让两池能力无法恰好相等，多出的能力只能闲置。这才是同构场景的正确答案：先考虑分块 prefill（chunked prefill），而不是分离。

② 分离真正的价值是延迟稳定 + 配置自由，不是吞吐。 分离后 D 卡每步稳定在 55 ms，P 卡专心处理输入。在途请求的输出间隔不再被长 prefill 打断 —— 这是共置做不到的。同时两个池可以各自选最优的并行方式和 batch size，排队也彻底隔开。

③ 吞吐的大幅提升只出现在异构硬件。 4×A100 做 P + 4×H20 做 D：A100 prefill 比 H20 快一倍多（0.856 s vs 1.81 s），H20 decode 比 A100 快一倍（27.4 ms vs 55.1 ms，因为 H20 显存带宽 4096 GB/s ≈ A100 2049 GB/s 的两倍，而算力不到其一半）。各自避开弱项后：

从共置的 3.02 提到 4.55，1.51×。 反过来配（H20 做 P、A100 做 D）只剩 2.22 请求/s，不到正确分工的一半。异构的收益来自硬件本身的差异，分块替代不了（H20 一步 decode 的空闲算力只够捎带约 85 个 prefill token，理想分块共置也只有 4.17 请求/s < 4.55）。

配比要算，不能拍。 最优配比是让两池能力接近相等：把一张 A100 从 P 调到 D，P 从 4.67 降到 3.50，总吞吐被 P 限制；把一张 H20 从 D 调到 P，D 降到 3.42，同样变慢。一个池有富余能力也无法替另一个池干活。

收益边界随负载翻转（这段最能体现会算账）：

两个时间尺度：请求到达时选进哪个队列（决定眼前等待），负载分布持续变化时调整池规模（决定积压能否消退）。

3. 交接的代价：PD 付一次，AF 每步都付#

这是 PD 与 AF 最本质的差别，也是「为什么 AF 通常不划算」的答案。

• PD：每个请求只交接一次完整的上下文 KV，代价随上下文长度增长。
• AF（注意力 / FFN 分离，含专家分离）：每层、每步 decode 都要交接激活。Qwen3-8B 一步 decode 是 72 次交接、576 KiB —— 单次很小，但代价随生成步数重复发生。

以 25 GB/s 链路算：一步 AF 交接约 0.384 ms，看着比一次 PD 交接 48.3 ms 快得多。但放到整条请求上，1024 步 AF 交接累计约 393 ms，是 GQA 一次 PD 交接 48.3 ms 的 8.1 倍，是紧凑 MLA 一次交接 23.0 ms 的 17 倍。 输出越长，差距越大。

由此可以求临界启动开销 $\alpha^*$（让一次 PD 交接与一步 AF 交接耗时相等的每次启动时间）：

GQA 状态在 25 GB/s 下 $\alpha^*\approx680$ μs，MLA 状态约 324 μs（50 GB/s 下分别 340 / 162 μs）。实际启动只要几微秒，远低于临界值 —— 所以「AF 单步更快」是对的，但整条请求上不成立。而且注意 $\alpha^*$ 的走向：状态越小、链路越快，留给每次启动的预算越少 —— AF 的优势窗口在收窄。

AF 的正经用法是专家分离 + micro-batch 流水。 MoE 里把路由专家放到独立池，micro-batch 在注意力节点与专家节点之间交错：一个 micro-batch 做注意力时，另一个做专家计算。忽略交接，$q$ 个独立 micro-batch 的双阶段流水为

MegaScale-Infer 论文（Mixtral-8×22B / DBRX / 317B Scaled-MoE，八节点×八张 80GB Ampere，TPOT ≤ 150 ms）报告每 GPU decode 吞吐达 TensorRT-LLM 的 1.90 倍。⚠️ 这个数字是分离放置、并行选择、流水与通信库共同的效果，不能当作「只开启 EP 分离」的通用加速比 —— 论文自己也按专家热度配置冗余副本。

4. 专家放置与大 EP 的 skew#

先看局部性：专家该在 CPU 还是 GPU 上算？ 两条路径交付同样的输出，区别是跨链路传什么：传权重（把 36 MiB 的专家权重搬到 GPU），还是传激活（把输入交给 CPU，用本地主存里的权重算）。

以 KTransformers 论文的实验机（双 Xeon 8452Y、1 TB DDR5、A100 40GB PCIe、同插槽内存带宽 220 GB/s）为例，八个专家各处理不同 token 数时：

同一台机器、同一批请求，CPU 用哪套指令集就决定了专家该放哪一侧。 低复用时（每专家 1 个 token），避免搬 36 MiB 权重比提高矩阵算力更有价值（CPU 路径约 1.46 ms vs GPU 路径约 12.5 ms）；高复用时反过来。这就是「规模摊薄固定开销」在专家层的样子。

再看大 EP 放大 skew。 直觉上「EP 越大每卡专家越少越均衡」，事实相反。同一批 $n=1024, k=8, E=256$ 的分派，若其中一个专家收到平均值的 4 倍：

没有热点时同样成立：均匀随机路由下，EP8 的最忙卡平均只比每卡平均多 4%，EP256 多 52%（固定种子模拟 1000 批）。两个效应同源 —— EP 越大，每卡上能相互抵消的专家越少，而要等待的卡越多。 DeepSeek 公开的 decode 部署用 EP144（每卡 2 个路由专家），位于曲线右端，正是靠冗余专家 + 按负载调整副本来补偿。

注意通信是两次，不是一次。 dispatch（把 token 的隐状态按所选专家分组发出去）与 combine（把结果送回并按路由权重加权求和）各是一次 All-to-All，中间夹着专家计算。同样的 64 MiB 载荷，均衡分布时阶段屏障下界 0.827 ms，热点分布时 2.068 ms（专家 skew 从 1 变成 2.5）。总通信量和总计算量都没变，只是分布变了。

专家副本什么时候回本？ 判据是累计节省超过复制耗时：$N\Delta t>T_{copy}$。

• 同一台 HGX H100 内经 NVLink 复制：约 0.622 ms，每批节省 0.240 ms → 第 3 批回本（持续 16 批净省约 3.2 ms）。
• 跨服务器经 ConnectX-7：约 5.32 ms → 要到第 23 批才回本；热点只持续 16 批时反而净损失约 1.5 ms。

结论：跨机复制副本的成本高到要求「热点必须持续得够久」，而同机复制几乎只受显存余量限制。 另外要按层分配副本预算 —— CRAFT（基于 SGLang v0.4.8、八个 p4de 节点的 A100 集群）报告端到端吞吐平均达对照的 1.14 倍、最高 1.2 倍；但这是它自己的实验条件（输入 4096 token 分块、输出固定 256 token），不能直接替代线上的 p99 指标。

5. KV 的分布、共享与路由：缓存不是免费的，也不是越大越好#

① 缓存标识不只是「相同文本」。 模型与 adapter 版本、token 序列、位置索引、状态格式、编码配置都可能参与标识 —— 同样的 token 配上不同 adapter，投影后就是不同的 K/V；同样的后缀接在不同前文后面，注意力看到的东西也不同。滑动窗口或递推状态还要携带 token 位置索引与更新时刻。

② 四级存储，取回都比重新算快。 仍以 1.125 GiB 的 8K 前缀为例（DGX A100 每张卡分到的配置）：

四级的取回时间都远小于重算 —— 所以「放哪一级」不是关键问题。真正的限制是另外三个：能不能留到下次用、读取能不能和计算重叠、写下去值不值。

③ 容量必须和复用间隔挂钩。 一张 A100 连续做无命中的 8K prefill，每 0.856 s 产生一份 1.125 GiB 的 KV，产生速率 $r\approx1.41$ GB/s。要让间隔 $T$ 内再次到达的请求都命中：

HBM 只够存约 45 s 内产生的 KV，主机内存约 195 s，SSD 约 45 分钟。而实际复用间隔的分布是：

• 面向个人的对话负载：80% 的复用发生在 10 分钟以内；
• 面向企业的 API 负载：80% 的复用发生在 10 秒以内。

10 秒只需 14.1 GB（HBM 就能装下），10 分钟需要 846 GB（超过每卡 275 GB 的主机内存，得上 SSD）。「该不该上 SSD」的答案完全取决于谁在发起下一轮：人在打字是分钟级，程序调用是秒级。

④ 命中率会饱和 —— 这是「缓存越大越好」的反例。 Mooncake 公开的 Kimi 线上 trace（一小时采样、每块 512 token）在 LRU 淘汰下：

一半以上的块从未被再次使用，另一些被访问上万次（阿里云的 trace 同样集中：10% 的块贡献 77% 的复用）。所以容量规划要按「保留多久、避免几次重算、增加几次搬移」来算，而不是追求命中率。

⑤ 保存 vs 重算的判据。 状态将在未来复用 $k$ 次时：

对 1.125 GiB 前缀：重算 856 ms，25 GB/s 下写入 + 取回各 48.3 ms，复用一次（96.6 ms）就不到重算的八分之一，所以只要还会再用一次就值得存。但临界带宽只有约 1.41 GB/s —— 恰好等于产生速率 $r$（直觉：链路只要比 GPU 产生这份 KV 更快，取回就比重算快）。低于这个带宽（如 10 GbE 每方向 1.25 GB/s，取回一次约 966 ms）应该重算，或者把取回挪出关键路径。

⑥ 让读取和计算重叠，而不是「先读完再算」。 命中后只需算 256 个新 token（约 30.9 ms），而整份读入要 48.3 ms —— 先读后算共 79.2 ms，读取比计算还长。逐层预加载（算第 $i$ 层时预读后面的层）降到 49.2 ms，仍由读取决定。要彻底掩盖，需要在请求开始前先读入若干层，缓冲区大小就是读取比计算多出来的那部分字节：

代入 25 GB/s、48.3 ms、30.9 ms 得约 437 MB，略多于 13 层，按整层取 14 层。$T_{new}\ge T_{read}$ 就不需要缓冲区 —— 新输入达到约 400 个 token 时，计算本身就能掩盖从主机内存的读取（远端池要约 800 个，本地 SSD 要约 1400 个）。CachedAttention 在 LLaMA-13B 上测得：1K 历史 + 100 新 token 时，逐层预加载让 prefill 缩短 35%，再加 15 层缓冲后缩短 61%。

⑦ SSD 的真正瓶颈是写入寿命，不是带宽。 以 $r\approx1.41$ GB/s 写入只占 PCIe 带宽 5.6%、SSD 顺序写带宽 34%，看着很宽裕。但 D7-P5520 按 1 DWPD（五年内每天写满一次）计，3.84 TB 盘平均每秒只能写 44.4 MB —— 把全部新 KV 都写进去是额度的 31.7 倍，五年寿命不到两个月耗尽。长期看只有约 3.2% 的新 KV 能落 SSD。 所以写入前必须做准入判断（例如只写已被复用过的前缀、或尚未结束的多轮会话），而不是「有空间就写」。

⑧ 缓存亲和性路由：比较的是完成时间，不是命中标记。 设 GPU 最早可执行时刻为 $Q$、状态就绪时刻为 $R$、状态可用后的剩余计算为 $C$，则

这个式子的关键是它把「排队」和「取回」放进了同一个 max。 一个典型算例（8192 前缀 + 256 新输入）：

A 明明命中了却输给 B —— 因为 A 要等 250 ms。两边打平的带宽约 6.30 GB/s（50 GbE 的 6.25 略低于此，200 GbE 远高于此）；而取回与重算打平的带宽只有约 1.48 GB/s，所以在 A100 上重算 8K 前缀几乎总是最慢的选择。

再看「命中概率」这把刀。 路由器靠缓存事件预测位置，事件延迟或对象被淘汰会让预测失准。设 A 排队 80 ms、缓存以概率 $p$ 真正可用，命中 110.9 ms、全失效 967.2 ms，则

只要 $p>7.0\%$，均值就优于 B 的直接重算（907 ms） —— 看着很容易达标。但 $p=0.9$ 时，10% 的请求仍是 967 ms，这个两点分布的 p99 就是 967 ms，远达不到 220 ms 的目标（要 p99 达标，命中率得 ≥99%）。这是「优化均值 vs 优化尾延迟」最干净的一个例子。

⑨ 先确定优化目标，再决定路由。 缓存优先 vs 空闲优先的实测：缓存优先时目标请求约 1.38 s 完成、两个任务也同时结束；把目标请求移到空闲实例后，它缩短到 0.33 s，但两个任务要到 1.54 s 才全部完成 —— 目标请求快了 1.05 s，全局完成时刻推迟了 0.16 s。做路由决策之前必须问清：优化的是这条请求，还是全部任务。

6. 启动、扩缩容与故障恢复#

启动积压是可以算的。 到达率 $\lambda$、启动时间 $T_s$，就绪时积压约 $\lambda T_s$；就绪后服务率 $\mu>\lambda$，排空时间

沿用异构集群的例子：启动 10 秒、每秒到达 3.5 个 → 积压 35 个；直接 PD 就绪后 4.55 请求/s，每秒净消化约 1.05 个，约 33 秒排空，从开始启动算是第 43 秒。反推最低服务率：50 秒内消除 35 个积压同时还要接新请求，$\mu\ge4.2$ 请求/s。直接 PD 的 4.55 只余 8% 的余量 —— kernel 效率若只有假设值的九成，D 池掉到约 4.10，排空推迟到第 68.5 秒，错过期限。而共置（3.02）的积压会一直增长。

面试里这段的价值：它把「扩容」从一个直觉动作变成了一个带期限的算式。说得出「多出来的算力是用来消化启动积压的，不是用来提高稳态吞吐的」，就已经超过大多数答案。

运行中迁移要处理「源端还在增长」。 迁走一张 H20 上的 D worker：批内 32 条请求平均上下文 8704 token，KV 共约 41.1 GB；源端每秒追加约 0.172 GB，目标以 25 GB/s 复制，约 1.65 s 追上（50 GbE 则要约 6.76 s）。decode 追加 KV 的速率远低于网卡带宽，追赶时间几乎全由初始的 41.1 GB 决定。 更值得注意的是：若切换并行方式后还要建立通信组、准备执行图、恢复接收请求，这些串行软件准备可能占 9 秒 —— 此时网络传输从 2.63 s 压到 0.66 s（快 4 倍），总时间只从 11.6 s 变到 9.7 s，只缩短 17%。瓶颈从网络变成了软件准备，靠更快的链路解决不了。

部分故障的恢复要分两份记录。 输出记录决定「继续哪条序列」，KV checkpoint 决定「还要重做多少计算」 —— 两者末端不重合：输出已经返回，不表示对应的 KV 已经保存。做法是 token 级预写日志（WAL） 保存已确定的输出序列，配额 KV checkpoint；恢复时用已记录的 token 补算重建相同前缀，不必重新采样这些输出（重新采样会改变后缀，对 RL 的 rollout 还会改变样本生成过程）。故障影响范围由同步组决定：张量并行组或专家并行组丢一张卡，可能让整个实例上的请求停住；而其他完整副本可以继续服务 —— 这是「多副本」在容错维度上的价值。

常见面试问法#

Q：单实例优化到头了，接下来怎么办？ A：先别急着「加机器」。按改变系统的哪一部分分四类：加完整副本（改变请求分配，换更多并发）、PD 分离（改变两阶段的执行位置，换延迟稳定与配置自由）、AF 分离（改变层内算子位置，换异构利用）、共享 KV（改变状态的保存与读取范围，换跨请求复用）。选择的依据是先算清三件事：各阶段的资源占用时间、状态传输的字节数、以及排队与就绪谁先到。两阶段需求相近就加副本；请求共享长前缀就优先做共享缓存，而不是继续拆计算。

Q：PD 分离能提升吞吐吗？ A：要分硬件。 ① 同构硬件上不能，反而更低 —— 八张 A100 共置 3.05 请求/s，整数分池（3 张 P + 5 张 D）只能到 2.83，低约 7%：每个请求消耗的 GPU 秒没变，而整数划分让两池能力无法恰好匹配。② 吞吐大幅提升只出现在异构硬件 —— 4×A100 做 P + 4×H20 做 D（A100 prefill 快一倍多、H20 decode 快一倍，因为 H20 带宽是 A100 两倍而算力不到一半），各自避开弱项后从 3.02 提到 4.55 请求/s，1.51×；反过来配只剩 2.22。③ 分离真正稳赚的是延迟 —— D 卡每步稳定在 55 ms，不被长 prefill 打断；同构下通常应先试 chunked prefill。④ 配比要算：最优是让两池能力接近相等，偏了就有一个池成为瓶颈。

Q：PD 和 AF 有什么本质区别？ A：交接的频率和对象不同。 PD 每个请求只交接一次完整的上下文 KV，代价随上下文长度增长；AF 每层、每步 decode 都交接激活，Qwen3-8B 一步 72 次、576 KiB，代价随生成步数重复发生。单看一步，AF 交接（0.384 ms）比 PD（48.3 ms）快得多；但 1024 步累计约 393 ms，是 PD 一次交接的 8.1 倍（对 MLA 状态是 17 倍）。而且临界启动时间 $\alpha^*=(V_{KV}-V_{AF})/(71B)$ 只有几百微秒，状态越小、链路越快，AF 的优势窗口越窄。AF 的正经用法是 MoE 专家分离 + micro-batch 流水（MegaScale-Infer 报 1.90×，但那是分离放置、并行选择、流水与通信库的共同效果，不能当「只开 EP」的加速比）。

Q：专家并行（大 EP）是不是越大越均衡？ A：恰好相反 —— 大 EP 会放大 skew。 同一个 4 倍热点专家：EP8 时热点卡只比平均多 8%（被同卡其他 31 个专家冲淡），EP32 多 36%，EP256 时每卡只剩一个专家，多 400%。没有热点时同样成立：均匀随机路由下 EP8 最忙卡多 4%，EP256 多 52%。原因是每卡上能相互抵消的专家变少，而要等待的卡变多。DeepSeek 的 decode 部署用 EP144 并配 32 个冗余专家 + 按负载调整副本，正是补这个。另外通信是两次 All-to-All（dispatch 与 combine），同样 64 MiB 载荷下，均衡分布阶段屏障 0.827 ms、热点分布 2.068 ms —— 总量没变，只是分布变了。

Q：专家副本值得做吗？ A：看热点能持续多久和复制走哪条链路。 判据是累计节省超过复制耗时：同一台 HGX 内经 NVLink 复制约 0.622 ms，每批省 0.240 ms，第 3 批回本（热点持续 16 批净省约 3.2 ms）；跨服务器经 ConnectX-7 要约 5.32 ms，要到第 23 批才回本 —— 热点只持续 16 批时反而净亏约 1.5 ms。所以跨机复制要求热点足够持久，同机复制几乎只受显存余量限制。还要按层分配副本预算（把空间给最能缩短等待的层），CRAFT 报告平均 1.14×、最高 1.2×，但那是它自己的实验条件。不要改 top-k 或替换逻辑专家来做均衡 —— 那会改变模型行为，不属于透明的资源调整。

Q：多实例之间怎么共享 KV？容量要多大？ A：先说缓存标识：相同文本不足以唯一确定可复用状态，还要含模型与 adapter 版本、位置索引、状态格式。容量要按复用间隔定：$C\ge rT$，其中 $r\approx1.41$ GB/s 是单卡连续无命中 8K prefill 的产生速率 —— 10 秒只需 14.1 GB（HBM 够），10 分钟需要 846 GB（得上 SSD）。实测复用分布差异极大：个人对话负载 80% 的复用发生在 10 分钟内，企业 API 负载 80% 在 10 秒内。 但容量越大命中率提升越慢：Mooncake 的线上 trace 上，块数从 1,000 增到 50,000，命中率 30%→50%，不限容量也只有 51%，因为一半以上的块从未被再用。所以按「保留多久、避免几次重算、增加几次搬移」算，而不是追命中率。保存 vs 重算：$T_{write}+kT_{read}<kT_{recompute}$，临界带宽约 1.41 GB/s（恰好等于 $r$）。SSD 的真正瓶颈是写入寿命（1 DWPD 下只有约 3.2% 的新 KV 能长期落盘），必须先做准入判断。

Q：缓存亲和性与空闲优先，请求该路由到哪台机器？ A：比较完成时间，而不是看有没有命中标记。 首 token 时间为 $T_{first}=\max(Q,R)+C$（排队、状态就绪、剩余计算）—— 关键是排队和取回进的是同一个 max。典型算例：A 本地命中但要排队 250 ms → 281 ms；B 无缓存直接重算 → 907 ms；B 从 50 GbE 远端取回 → 282 ms；换成 200 GbE → 137 ms，反超 A。两边打平的带宽约 6.30 GB/s；取回与重算打平的带宽只有约 1.48 GB/s，所以在 A100 上重算 8K 前缀几乎总是最慢的选择。还要看尾延迟：命中概率 $p$ 只要 >7% 均值就优于重算，但 $p=0.9$ 时那 10% 仍是 967 ms，两点分布的 p99 就是 967 ms —— 要 p99 达标需要 ≥99% 命中。最后先确定优化目标：缓存优先能让目标请求从 1.38 s 缩到 0.33 s，但全局完成时刻反而推迟 0.16 s。

易错点#

自测#

1. 客户说「我们的推理服务扛不住了，加了几台机器做 prefill/decode 分离，结果吞吐反而降了」。你怎么解释，并给出下一步建议？

2. 你要为一个 Qwen3-8B 服务做 PD 分离，请算出：8192 token 上下文的交接时间、交接期间两端的内存占用、以及这条链路每秒最多支持多少次交接。

3. 有人主张「把每层的 FFN 放到另一组卡上，单次传输只有几百 KB，比 PD 一次传 1 GB 划算多了」。这个论证错在哪？

4. 一个 agent 产品的前缀很长（系统提示 + 工具定义 + 多轮历史），80% 的请求会复用同一段前缀。你会怎么设计缓存与路由？哪些数字决定容量？

5. 一个 8 卡实例从停止状态启动要 10 秒，到达率 3.5 请求/s，要求启动后 60 秒内清空积压。你会怎么判断方案是否可行？这套判据还能用在哪？