llm-atlas/research/INFERENCE_SERVING_RESEARCH.md

# 推理服务与低成本部署：正式研究账本

> 状态：首版证据核验完成，供 Chapter 14 正文、原创图和交互实验使用。
>
> 核验日期：2026-07-29
>
> 锚点：Kimi K3 §4.1.4 / §5.1 / §5.3.1 / §5.4、Mooncake、DeepSeek-V2 §2、
> DeepSeek-V3 §2.1 / §3.4、DeepSeek-V3.2 §2.3、DeepSeek-V4 §2.3 / §3.5 / §5.2.1。
>
> 证据纪律：Grok 只做召回；正文事实只来自 P0 论文 / 技术报告或 P1 作者官方实现。
> 所有 speedup 都保留作者的模型、硬件、负载、SLO 与基线边界，不外推为通用常数。

---

## 0. 本章真正回答什么

训练完成只说明模型参数存在，不说明它能以可接受的成本、延迟和可靠性服务真实用户。
一个在线 LLM 请求同时穿过四层：

```text
模型结构
  attention / MoE / precision / draft
        ↓
单实例引擎
  KV allocator / batching / prefix cache / graph
        ↓
设备内核
  GEMM / attention / quantization / communication
        ↓
集群与产品
  routing / admission / SLO / failover / cost
```

任何一层都可能成为瓶颈。于是本章坚持四条总原则：

1. **prefill 与 decode 分账**：两者的并行度、算术强度和用户指标不同；
2. **权重与状态分账**：量化权重不等于压缩 KV Cache；
3. **吞吐与 goodput 分账**：超时后完成的 token 可能不产生产品价值；
4. **算法与实现分账**：低 FLOPs 不保证低延迟，内存流量、通信、kernel shape 和 batch 同样重要。

---

## 1. 十八张独立问题账

| # | 账本 | 本章要回答的问题 | 最常见误写 |
|---|---|---|---|
| Q1 | 服务指标 | TTFT、TPOT、E2E、throughput、goodput 各测什么？ | 只报 tokens/s |
| Q2 | 权重显存 | 权重、scale、workspace、runtime buffer 占多少？ | 参数量直接等于显存 |
| Q3 | KV 状态 | 每 token 的状态怎样随层数、KV heads、精度增长？ | 只看 context length |
| Q4 | 分配与碎片 | 连续预留为什么浪费，分页又留下什么边角？ | PagedAttention“零碎片” |
| Q5 | Prefill | 长 prompt 为什么常是算力密集？ | 只写成“生成第一个 token” |
| Q6 | Decode | 单步生成为什么常是带宽密集？ | FLOPs 少所以必然快 |
| Q7 | 批处理 | request / iteration / continuous batching 有何不同？ | 动态 batch 自动解决全部问题 |
| Q8 | 阶段干扰 | 长 prefill 如何抬高正在 decode 的 TPOT？ | 平均延迟掩盖停顿 |
| Q9 | 内核 | IO-aware、融合、图捕获与 shape 调度解决什么？ | FlashAttention 等于全栈 serving |
| Q10 | 前缀复用 | 何时可以合法跳过 prefill？ | 相同文本块都可直接复用 |
| Q11 | PD 分离 | 为什么拆，KV 又怎样跨设备？ | 分离一定降本 |
| Q12 | 推测解码 | 接受率和 draft 成本怎样决定净加速？ | 固定 2–3× |
| Q13 | 量化 | W / A / KV 各自压什么，内核是否吃得到？ | 位数越低越快 |
| Q14 | 并行 | TP / PP / DP / EP 怎样映射到服务阶段？ | 训练拓扑照搬推理 |
| Q15 | MoE | 激活参数少为何仍可能贵？ | 忽略权重流与 all-to-all |
| Q16 | 调度与 SLO | 公平、缓存亲和、尾延迟怎样冲突？ | P50 代表体验 |
| Q17 | Fleet | 扩缩、迁移、过载与故障怎样处理？ | 副本数等于瞬时容量 |
| Q18 | 谱系 | DeepSeek / Kimi 在四层各改了什么？ | 所有优化压成“模型更快” |

---

## 2. Q1：先把服务指标说清楚

设请求到达时间为 `t_arrive`，首个输出 token 到达为 `t_first`，最后完成为 `t_done`，
相邻输出 token 时间为 `t_i`：

```text
TTFT = t_first - t_arrive
TPOT_i = t_i - t_{i-1}
E2E latency = t_done - t_arrive
output throughput = 完成的输出 token / 时间
request throughput = 完成的请求 / 时间
```

### 2.1 指标不是同义词

- **TTFT / Time To First Token**：排队 + prefill + 首次 decode；
- **TPOT / Time Per Output Token**：流式输出的节奏，也常写 ITL / inter-token latency；
- **E2E latency**：TTFT 加上后续全部生成；
- **throughput**：系统做了多少工作，不保证工作及时；
- **goodput**：在给定 TTFT / TPOT / E2E SLO 内完成的有效请求率；
- **P50 / P95 / P99**：分位数，不可由平均值替代。

DistServe 明确把 per-GPU goodput 定义为满足延迟约束的最大请求率，并在其硬件、模型、
trace 与 SLO 设置下报告最高 `7.4×`；这个数字不是“PD 分离永远 7.4×”。

一手来源：[DistServe](https://arxiv.org/abs/2401.09670)

### 2.2 输入与输出成本必须分开

输入 token 主要支付 prefill；输出 token 每增加一个都要再走一次自回归 decode。
同样是 1M token：

- 1M 输入 + 1 输出；
- 1K 输入 + 999K 输出；

对 GPU 时间、KV 生命周期和用户等待完全不是一回事。任何 `$ / 1M tokens` 若不区分 input /
output、cache hit / miss、batch、上下文位置和 SLO，解释力都很弱。

---

## 3. Q2–Q3：权重显存与 KV Cache 是两张账

### 3.1 权重下界

若模型有 `P` 个参数，平均存储位宽为 `b_w`：

```text
WeightBytes ≈ P × b_w / 8
```

这是权重本体的解析下界，不含：

- 每组 scale / zero point；
- embedding / lm head 的特殊精度；
- CUDA graph、workspace、通信 buffer；
- runtime 元数据和临时 activation；
- speculative draft；
- 多副本或流水 stage。

### 3.2 标准注意力 KV 公式

对 batch `B`、已缓存 token 数 `T`、层数 `L`、KV head 数 `H_kv`、每头维度 `D_h`、
每元素字节 `s`：

```text
KVBytes = B × T × L × 2 × H_kv × D_h × s
                         └K+V┘
KVBytesPerToken = L × 2 × H_kv × D_h × s
```

这是**架构维度推导**，不是某个框架的实测显存。

教学例：

```text
L = 32, H_kv = 8, D_h = 128, BF16 = 2 bytes
KV / token / request = 32 × 2 × 8 × 128 × 2
                     = 131,072 bytes = 128 KiB
128K tokens ≈ 16 GiB
```

若同样模型使用 `H_kv = 32` 的 MHA，教学值会变成 `512 KiB/token`。这说明 GQA/MQA
主要改变 KV head 维度；它们没有把 attention 变成固定状态。

### 3.3 MHA、MQA、GQA、MLA、KDA 不能画成同一种压缩

| 结构 | 随序列增长的主状态 | 保留方式 | 关键边界 |
|---|---|---|---|
| MHA | 每层每个 KV head 的 K/V | 全量 token KV | 最大但直接 |
| MQA | 单组 K/V 供多 Q heads 共享 | 全量 token KV | KV heads 变少 |
| GQA | 若干组 K/V | 全量 token KV | MHA 与 MQA 之间 |
| MLA | 低维 latent KV + positional 分量 | 全量 token 的压缩表示 | 仍随 T 增长 |
| KDA | 每层固定大小 recurrent state | 状态递推 | 不保留逐 token KV，但更新/回滚更复杂 |

一手来源：

- [Fast Transformer Decoding / MQA](https://arxiv.org/abs/1911.02150)
- [DeepSeek-V2 / MLA](https://arxiv.org/abs/2405.04434)
- [Kimi Linear / KDA](https://arxiv.org/abs/2510.26692)
- [Kimi K3](https://arxiv.org/abs/2607.24653)

DeepSeek-V2 作者报告 MLA 相对其 DeepSeek 67B 对照减少 `93.3%` KV cache 并提高最大生成吞吐；
只能按该报告对照理解，不能写成“MLA 对任意 MHA 都固定减少 93.3%”。

---

## 4. Q4：PagedAttention 解决的是分配，不是模型数学

连续预留方案常按最大长度为请求留一整块显存，但真实输出长度未知：

```text
reserved waste = 预留但最终未使用
external fragmentation = 空闲空间存在却不连续
internal fragmentation = 最后一个分配块未填满
```

PagedAttention 借鉴虚拟内存：

```text
logical KV blocks
      ↓ block table
non-contiguous physical blocks in GPU pool
```

它让 KV 按需增长、可交换、可 copy-on-write 共享。vLLM 论文在其模型和 workload 上报告相对
当时系统 `2–4×` throughput，但核心机制不是减少 Transformer FLOPs。

### 4.1 “近零浪费”不等于零

若 block size 为 `S`，请求长度 `T`：

```text
blocks = ceil(T / S)
allocated tokens = blocks × S
internal waste = allocated tokens - T
```

每个请求最后仍可能浪费 `0 … S-1` 个位置；还有 block table、引用计数、调度与 kernel 形状成本。
block 太小增加元数据和寻址，太大增加内部碎片。

一手来源：[Efficient Memory Management for LLM Serving with PagedAttention](https://arxiv.org/abs/2309.06180)

---

## 5. Q5–Q6：Prefill 与 Decode 是两种工作负载

### 5.1 Prefill

一次处理整个输入序列：

- Q/K/V 与 MLP GEMM 能沿 token 维并行；
- 标准 dense attention 的配对随序列近似二次增长；
- 长 prompt 的 TTFT 对算力、attention IO 与 prefix hit 极敏感；
- 结果是后续 decode 所需的 KV / recurrent state。

### 5.2 Decode

每步通常只新增一个 token：

- 必须读取模型权重；
- dense attention 还需读取历史 KV；
- 单请求矩阵很“瘦”，GPU 计算单元不容易吃满；
- batch 可摊薄权重读取，但同时增长 KV 容量与排队。

因此常见直觉是：

```text
prefill：更偏 compute-bound
decode：更偏 memory-bandwidth-bound
```

这是常见 regime，不是硬定律。短 prompt、小模型、极大 batch、特殊 kernel、量化、MoE、稀疏/
线性 attention 都会移动瓶颈。

Splitwise 正是基于两阶段不同的计算、内存和功率特征做 phase splitting；论文在其集群设计和
工作负载下报告 `1.4×` throughput 且成本低 `20%`，或相同成本/功率 `2.35×` throughput。

一手来源：[Splitwise](https://arxiv.org/abs/2311.18677)

---

## 6. Q7：从固定 batch 到 iteration-level scheduling

### 6.1 Request-level batching 的队头阻塞

若一个 batch 必须等最慢请求结束：

```text
短输出：早已完成却不能及时离开
新请求：必须等整个 batch 结束
长输出：决定所有人的生命周期
```

### 6.2 Orca 的转折

Orca 把调度粒度降到每次模型 iteration，并用 selective batching 处理不同 operation：

- 已完成请求在 iteration 边界离开；
- 新请求可以加入下一轮；
- batch 组成随生成过程变化。

Orca 在论文的 GPT-3 175B 部署与对照下报告 `36.9×` throughput；硬件、系统代际和基线均
限定该数字。

一手来源：[Orca, OSDI 2022](https://www.usenix.org/conference/osdi22/presentation/yu)

### 6.3 Continuous batching 仍有决策

它不是一个开关，而是一组策略：

- 一轮准入多少 prefill / decode token；
- 是否抢占，以及 swap / recompute 哪个更便宜；
- 长短请求、优先级和租户怎样排队；
- batch token budget 如何限制；
- 何时触发 CUDA graph 或特定 kernel；
- KV 不够时驱逐谁。

FastServe 用可抢占调度降低长请求阻塞；Llumnix 进一步支持跨实例迁移请求及其 KV 状态。

一手来源：

- [FastServe](https://arxiv.org/abs/2305.05920)
- [Llumnix](https://arxiv.org/abs/2406.03243)

---

## 7. Q8：Chunked Prefill 在吞吐与停顿之间切账

长 prefill 整块插入 continuous batch 会让正在 decode 的请求等待。Sarathi-Serve 把 prompt
切成若干 chunk，并把 chunk 与 decode token 组成更均匀的 iteration：

```text
long prefill
  ├─ chunk 1 + decode batch
  ├─ chunk 2 + decode batch
  ├─ chunk 3 + decode batch
  └─ ...
```

收益：

- 限制单轮 stall；
- 提高 decode batch 的连续性；
- pipeline 下减少不均匀 iteration 的气泡。

代价：

- chunk 太小会增加调度、kernel launch 和中间状态成本；
- chunk 太大又回到 decode stall；
- 最优 token budget 依赖模型、GPU、并行度、prompt/output 分布与 SLO。

Sarathi-Serve 作者在 Mistral-7B / Yi-34B / Falcon-180B 的不同硬件设置下分别报告最高
`2.6× / 3.7× / 5.6×` serving capacity，必须逐设置引用。

一手来源：[Sarathi-Serve, OSDI 2024](https://arxiv.org/abs/2403.02310)

---

## 8. Q9：内核优化究竟省了什么

### 8.1 FlashAttention：精确 attention 的 IO 重排

FlashAttention 用 tiling 避免显式把完整 attention matrix 往返 HBM，并在片上做在线 softmax。
它是 exact attention：结果数学上不靠丢 token 近似；速度来自 IO-aware schedule。

FlashAttention-2 改善并行和 work partition；FlashAttention-3 面向 Hopper 的异步与低精度路径。

一手来源：

- [FlashAttention](https://arxiv.org/abs/2205.14135)
- [FlashAttention-2](https://arxiv.org/abs/2307.08691)
- [FlashAttention-3](https://arxiv.org/abs/2407.08608)

### 8.2 Decode kernel 与 prefill kernel 不是同一个最优形状

decode 的 query 很短、KV 很长；需要沿 KV 长度切分、归约并控制状态读取。FlashInfer 用组合式
KV format、JIT attention template、load-balanced scheduling 与 CUDA graph 兼容处理多种 serving
shape。论文报告的 ITL 降低范围仅适用于其模型、硬件和 compiler 对照。

一手来源：[FlashInfer](https://arxiv.org/abs/2501.01005)

### 8.3 Kernel 快不等于端到端快

端到端还包含：

- tokenizer、排队、RPC；
- KV 分配 / hash / transfer；
- all-reduce / all-to-all；
- sampling、logits processing、structured decoding；
- host launch、graph capture；
- draft 与 verifier；
- 请求迁移和故障路径。

所以 kernel microbenchmark、single-request latency 与 fleet goodput 必须分开报告。

---

## 9. Q10：前缀缓存何时合法

### 9.1 最安全的基本条件

可直接复用的通常是：

- 同一 checkpoint / adapter；
- 同一 tokenizer 与精确 token prefix；
- 相容的位置编码、attention mask 与 multimodal preprocess；
- 相同精度 / cache layout；
- cache 对应的所有模型状态完整且未被原地修改。

“两段文本内容相同”不够。若它们前面的上下文或位置不同，K/V 也可能不同。

### 9.2 三种复用层次

| 层次 | 代表 | 做法 | 边界 |
|---|---|---|---|
| 精确共同前缀 | vLLM / SGLang | block hash / radix tree | 只复用 prefix |
| 批内共享前缀 | Hydragen / ChunkAttention | 共享 prefix attention，再处理 suffix | 需要共享度 |
| 非前缀 chunk | CacheBlend | 复用后选择性重算部分 KV | 不是零重算 |

SGLang 的 RadixAttention 把请求前缀组织为 radix tree；其最高 `6.4×` throughput 是多个 structured
program workload 下的作者报告，不是 prefix cache 单机制常数。

一手来源：

- [SGLang](https://arxiv.org/abs/2312.07104)
- [Hydragen](https://arxiv.org/abs/2402.05099)
- [ChunkAttention](https://arxiv.org/abs/2402.15220)
- [CacheBlend](https://arxiv.org/abs/2405.16444)

CacheBlend 的关键是：非前缀 chunk 的预计算 KV 缺失与前序 chunk 的 cross-attention，不能整块
无条件复用；它选择少量 token 重算并与 cache load 重叠。论文报告的 TTFT `2.2–3.3×` 与 throughput
`2.8–5×` 只属于其模型、数据集、存储和对照。

### 9.3 CacheGen：运输也可以是瓶颈

CacheGen 压缩并流式传输 KV context，目标是让“加载已有状态”比重新 prefill 更划算。
压缩带来的质量、编码时间、网络和存储层次必须一起核算。

一手来源：[CacheGen](https://arxiv.org/abs/2310.07240)

---

## 10. Q11：Prefill–Decode Disaggregation

### 10.1 为什么拆

共置时，prefill 与 decode：

- 竞争 GPU；
- 需要妥协 batch / parallelism；
- 长 prefill 可抬高 decode TPOT；
- 两阶段无法独立扩容。

PD 分离让 prefill pool 和 decode pool 分别选择并行度、batch 和硬件。

### 10.2 新增的账

Prefill 完成后必须把状态交给 decode：

```text
transfer time ≥ KV bytes / effective network bandwidth
              + serialization / layout conversion
              + queueing / handshake
```

真实成本还包括：

- prefill / decode TP degree 不同时的重新布局；
- 目标 decode 节点的 HBM 容量；
- cache hit 与 transfer hit；
- NIC / PCIe / NVLink / RDMA 拓扑；
- 失败重传和 stale cache；
- 阶段资源比随流量变化。

### 10.3 三个关键节点

1. **Splitwise**：用不同机器匹配 prompt / generation 的不同特征；
2. **DistServe**：围绕 TTFT / TPOT SLO 最大化 per-GPU goodput；
3. **Mooncake**：把 KVCache 当作跨 GPU、CPU DRAM、SSD 的中心资源，并加入过载 early rejection。

Mooncake 是 Kimi 的生产 serving 平台。论文作者报告：

- 特定模拟长上下文场景最高 `525%` throughput increase；
- 真实 Kimi workload 在相同 SLO 下多处理 `75%` 请求。

这两个数字来自不同实验，不能合成“Mooncake 固定 5.25×”。

一手来源：

- [Splitwise](https://arxiv.org/abs/2311.18677)
- [DistServe](https://arxiv.org/abs/2401.09670)
- [Mooncake](https://arxiv.org/abs/2407.00079)
- [Mooncake official repository](https://github.com/kvcache-ai/Mooncake)

---

## 11. Q12：推测解码的数学与边界

### 11.1 核心协议

```text
draft q：便宜地提出 k 个候选
target p：一次并行评分这段候选
accept/reject：保留合法前缀，并在拒绝处校正
```

Leviathan 与 Chen 等工作的关键不是“近似输出”，而是用修正采样保持 target distribution
（在其数值假设下）。

一手来源：

- [Fast Inference via Speculative Decoding](https://arxiv.org/abs/2211.17192)
- [Speculative Sampling](https://arxiv.org/abs/2302.01318)

### 11.2 接受率是加速墙

每步 acceptance mass：

```text
a = Σ_x min(p(x), q(x))
```

若用一个极简教学假设：每个 draft token 独立以概率 `a` 接受，draft 长度 `k`，一次 target
verification 至少产出一个 token，则一次 target pass 的期望输出：

```text
E[tokens] = 1 + a + a² + ... + a^k
          = (1 - a^(k+1)) / (1 - a),  a ≠ 1
```

这只是教学模型。真实接受率随位置、上下文、采样温度、领域、树结构和 batch 变化。

若 target 单步成本 `C_t`，每个 draft token 成本 `C_d`，一次验证成本 `C_v(k)`：

```text
toy speedup = E[tokens] × C_t / (k × C_d + C_v(k))
```

`k` 太大可能增加无效 draft 与验证成本；draft 太小虽便宜，分布太差又会拉低 `a`。

### 11.3 从小模型到多头、树和 feature draft

| 路线 | 代表 | 草稿来自哪里 | 关键边界 |
|---|---|---|---|
| 独立 draft LM | Speculative Sampling | 小模型 | 两套权重 / cache |
| token tree | SpecInfer | 多候选小模型 | 树宽与验证成本 |
| retrieval draft | REST | 语料中的重复片段 | 领域重复性 |
| 多预测头 | Medusa | target 上的额外 heads | 需要训练 heads |
| feature autoregression | EAGLE | target 中间特征 | 模型耦合 |
| dynamic tree | EAGLE-2 | 置信度调树 | 校准决定树 |
| multi-layer fusion | EAGLE-3 | 低/中/高层特征 | 训练数据与实现 |

一手来源：

- [SpecInfer](https://arxiv.org/abs/2305.09781)
- [REST](https://arxiv.org/abs/2311.08252)
- [Medusa](https://arxiv.org/abs/2401.10774)
- [EAGLE](https://arxiv.org/abs/2401.15077)
- [EAGLE-2](https://arxiv.org/abs/2406.16858)
- [EAGLE-3](https://arxiv.org/abs/2503.01840)

EAGLE-3 报告最高 `6.5×` 单场景速度、SGLang batch 64 下 `1.38×` throughput。两者口径不同，
页面必须同时展示，不挑最高数字制造错觉。

---

## 12. Q13：量化必须分 W / A / KV

| 量化对象 | 主要省什么 | 可能加速哪段 | 不能自动得到什么 |
|---|---|---|---|
| Weight | 权重存储与读取 | decode、GEMM | KV 变小 |
| Activation | GEMM 输入/中间流量 | prefill / batched decode | 权重自动低位 |
| KV Cache | 上下文状态容量与 attention 读取 | 长 context decode | MLP 权重变小 |
| Router / indexer | 稀疏选择路径 | long-context selection | 主干全量低位 |

### 12.1 关键路线

- **LLM.int8**：离群维走高精度，主体 INT8；
- **GPTQ**：基于近似二阶信息的一次性 weight-only PTQ；
- **SmoothQuant**：等价缩放把 activation outlier 难度迁给 weights，做 W8A8；
- **AWQ**：用 activation 统计识别并保护少量显著 weight channels；
- **KVQuant**：per-channel key、pre-RoPE、非均匀与 dense-sparse KV；
- **KIVI**：key per-channel、value per-token 的 tuning-free 2-bit KV；
- **QServe**：W4A8KV4 与 kernel/system co-design。

一手来源：

- [LLM.int8](https://arxiv.org/abs/2208.07339)
- [GPTQ](https://arxiv.org/abs/2210.17323)
- [SmoothQuant](https://arxiv.org/abs/2211.10438)
- [AWQ](https://arxiv.org/abs/2306.00978)
- [KVQuant](https://arxiv.org/abs/2401.18079)
- [KIVI](https://arxiv.org/abs/2402.02750)
- [QServe](https://arxiv.org/abs/2405.04532)

### 12.2 低位不保证更快

需要同时验证：

- 硬件是否有对应 tensor core / vector path；
- dequant 是否落到慢 CUDA cores；
- scale / zero point 粒度；
- group size 与 layout；
- kernel 是否融合；
- batch / matrix shape 是否进入有利 regime；
- 精度回归是否覆盖实际工具、代码与长上下文任务。

QServe 正是指出云 serving 中 INT4 的 dequant overhead 可能抵消收益，并联合 W/A/KV 与 kernel
设计。其 `3×` 成本、不同 GPU 上的 throughput 数字只属于论文设置。

---

## 13. Q14–Q15：并行与 MoE Serving

### 13.1 四种并行的服务含义

- **TP**：一层权重分到多 GPU；降低单卡权重，但每层通信；
- **PP**：层分 stage；可容纳超大模型，但小 batch / 不均匀 iteration 会有 bubble；
- **DP**：复制模型实例；提高独立请求吞吐，但每副本要有权重；
- **EP**：专家分设备；只算所选专家，却引入 dispatch / combine all-to-all。

训练时最优拓扑不必是 prefill 或 decode 最优拓扑。

### 13.2 MoE 的三张隐藏账

1. **权重带宽**：小 batch 时每个激活专家权重仍需从 HBM 读取；
2. **通信**：token 要到专家所在 GPU，再 combine；
3. **倾斜**：热门专家决定 tail latency，平均 token 数无济于事。

DeepEP 提供高吞吐与低延迟两类 expert dispatch/combine 路径；DeepGEMM 提供 FP8/FP4、
fused MoE 等 kernel。它们是 P1 官方实现，不等于独立 peer-reviewed 性能结论。

一手来源：

- [DeepSpeed-MoE](https://arxiv.org/abs/2201.05596)
- [MegaBlocks](https://arxiv.org/abs/2211.15841)
- [DeepEP](https://github.com/deepseek-ai/DeepEP)
- [DeepGEMM](https://github.com/deepseek-ai/DeepGEMM)

---

## 14. Q16–Q17：调度、SLO、尾延迟与 Fleet

### 14.1 吞吐最大化与 SLO 最大化不同

把 batch 填满可能提高 tokens/s，却让：

- 新请求 TTFT 变长；
- 长 prefill 让 decode 停顿；
- 短请求被长请求阻塞；
- P99 越过 SLO。

因此 goodput 要把“及时完成”写入目标。

### 14.2 缓存亲和与负载均衡冲突

```text
route to cache owner → 少 prefill，可能形成热点
route to idle replica → 队列短，可能 cache miss
move KV → 两边折中，但支付网络与迁移
```

Preble 在其 prompt-sharing workloads 中报告平均延迟 `1.5–14.5×`、P99 `2–10×` 改善；
范围巨大本身说明 workload 的 prefix sharing 才是因变量，不能抽出一个常数。

一手来源：[Preble](https://arxiv.org/abs/2407.00023)

### 14.3 迁移与重调度

Llumnix 把正在运行请求及其 in-memory state 迁移到其他 instance，用于负载均衡、碎片整理、
优先级与 SLO 隔离。迁移不是免费：收益必须超过 KV copy、网络和同步成本。

一手来源：[Llumnix, OSDI 2024](https://arxiv.org/abs/2406.03243)

### 14.4 过载时“全接收”不是中立政策

如果到达率长期超过可服务率，队列只会增长。Mooncake 使用预测式 early rejection；K3 进一步
按请求类别设置 resource budget，让百万 token burst 不拖垮短请求。

页面必须解释：

- admission control 是容量保护，不是模型能力；
- rejection rate、goodput 与用户公平需要一起报告；
- 平均 request 不能代表 2K 与 1M token 混合流量。

---

## 15. Q18：DeepSeek 推理服务谱系

DeepSeek 的主线不是单一“更低精度”，而是四层协同：

```text
V2：MLA 压 KV + DeepSeekMoE
  ↓
V3：MLA/MoE + prefill/decode 分离 + 冗余专家 + MTP
  ↓
V3.2：DSA 用 lightning indexer 选择少量 KV
  ↓
V4：CSA/HCA + heterogeneous cache + on-disk prefix + FP4 QAT
```

### 15.1 DeepSeek-V2：先改模型状态

MLA 缓存低维 latent 表示，而非完整 head-specific K/V；DeepSeekMoE 降低每 token 激活计算。
这是模型结构层的成本改变，仍需要引擎与 kernel 才能兑现。

一手来源：[DeepSeek-V2](https://arxiv.org/abs/2405.04434)

### 15.2 DeepSeek-V3：公开写出两套部署拓扑

报告 §3.4：

- prefill 最小单元 `4 nodes / 32 GPUs`；
- attention `TP4 + SP + DP8`，MoE `EP32`；
- 部署 `32` 个冗余专家，每 GPU 原 8 个外再放 1 个；
- decode 最小单元 `40 nodes / 320 GPUs`；
- attention `TP4 + SP + DP80`，MoE `EP320`；
- decode 每 expert batch 通常不超过 `256 tokens`，作者称瓶颈是 memory access；
- 两个 micro-batches 交错 attention 与 dispatch/MoE/combine。

这些是 DeepSeek 的 H800 / IB 生产策略，不是“小团队部署建议”。报告自己把最小部署单元很大列为限制。

MTP 在 V3 的主要目的为训练，推理可丢弃；也可改作 speculative decoding。报告结尾的 `1.8×`
decode speed 是预期/探索语境，不能写成已经完整公开的通用生产基准。

一手来源：[DeepSeek-V3](https://arxiv.org/abs/2412.19437)

### 15.3 DeepSeek-V3.2：稀疏索引与真实服务成本

DSA 主 attention 从 `O(L²)` 变 `O(Lk)`，lightning indexer 仍有 `O(L²)` 但更轻。
报告 Figure 3 给出基于 H800 实际服务 benchmark、按 `$2/GPU-hour` 估算的 token-position cost；
云租价是作者设定，不是全球现价。

一手来源：[DeepSeek-V3.2](https://arxiv.org/abs/2512.02556)

### 15.4 DeepSeek-V4：PagedAttention 的假设被混合 cache 打破

V4 同时有：

- SWA 的固定窗口 state；
- CSA / HCA 的不同压缩比；
- 未到压缩边界的 tail state；
- lightning indexer 自己的 KV；
- 不同 layer 的 block 数、hit / eviction policy。

因此报告设计：

1. fixed-size **state cache** 管 SWA 与未压缩 tail；
2. classical **KV cache** 管 CSA/HCA 压缩条目；
3. cache block 覆盖 `lcm(m, m')` 个原 token；
4. sparse kernel 与 layout 共设计；
5. on-disk prefix cache 对 CSA/HCA 全存，对 SWA 提供 full / periodic checkpoint / zero-cache 三种权衡。

在 1M context 的作者估算中，V4-Pro 相对 V3.2 为 `27%` single-token equivalent FP8 FLOPs 与
`10%` KV cache；V4-Flash 为 `10%` FLOPs 与 `7%` KV。只可用于同报告的架构估算对照。

FP4 QAT 覆盖 MoE expert weights 与 CSA indexer QK path；报告的 selector `2×`、`99.7%` KV recall
是特定组件指标，不能写成整个模型 2×。

一手来源：[DeepSeek-V4](https://arxiv.org/abs/2606.19348)

### 15.5 DeepSeek 官方内核生态

- [FlashMLA](https://github.com/deepseek-ai/FlashMLA)：dense/sparse MLA prefill/decode、FP8 KV；
- [DeepGEMM](https://github.com/deepseek-ai/DeepGEMM)：FP8/FP4/BF16、MoE、indexer 等；
- [DeepEP](https://github.com/deepseek-ai/DeepEP)：expert dispatch/combine；
- [open-infra-index](https://github.com/deepseek-ai/open-infra-index)：官方基础设施索引。

仓库当前 benchmark 会随 commit、CUDA 和 GPU 变化；页面引用功能边界，不把 README 最新数字
倒灌为早期模型报告事实。

---

## 16. Kimi / Moonshot 推理服务谱系

```text
Mooncake：KV-centric PD disaggregation
    ↓
Kimi K2 / K2.5：MLA + 大规模 MoE 的服务约束
    ↓
Kimi Linear：KDA 固定 recurrent state
    ↓
Kimi K3：KDA/MLA hybrid cache + replay decode + fleet policy
```

### 16.1 Mooncake：先把 KV 变成集群一等公民

Mooncake：

- 分离 prefill 与 decode clusters；
- 利用 GPU 集群中未充分使用的 CPU、DRAM、SSD；
- 用 Transfer Engine 搬运 KV；
- 调度器同时优化 effective throughput 与 latency SLO；
- 过载时预测式 early rejection。

这条路线后来也服务 K3 的训练 activation remote offload，但训练复用不应覆盖本章的 serving 起点。

一手来源：

- [Mooncake paper](https://arxiv.org/abs/2407.00079)
- [Mooncake repository](https://github.com/kvcache-ai/Mooncake)

### 16.2 Kimi K2：服务约束反向影响架构搜索

K2 报告在架构对照中明确考虑 attention heads 与 active experts 的 inference overhead；
其 serving 图来自性能模拟器与 effective-parameter construction，不是真实生产 A/B。

因此页面只用 K2 说明“架构搜索包含服务成本”，不把模拟值当线上吞吐。

一手来源：[Kimi K2](https://arxiv.org/abs/2507.20534)

### 16.3 K3：两种 cache 必须在同一边界恢复

每个 K3 block 为 `3 KDA + 1 Gated MLA`：

- MLA KV 随 token 增长并分页；
- KDA 每层是固定大小 recurrent state；
- prefix hit 只有同时恢复二者才合法。

K3 §5.4.1 把两类 page 放进统一 byte-size block pool，共享 allocation、reference counting 与 eviction；
但类型和生命周期仍不同，不能说“KDA state 就是 KV”。

### 16.4 物理块、hash 块和 checkpoint 解耦

若 KDA state 很大，只能稀疏存 checkpoint，物理块被迫达到 `1024–6144 tokens`；若 hash granularity
也跟物理块绑定，小请求几乎无法命中。

K3 的解法：

```text
physical page：可很大，例如 6144 tokens
hash block：细粒度，例如 512 tokens
KDA checkpoint：只在部分 hash endpoints 持久化
hit boundary：MLA prefix 命中且所有 KDA groups 都有 checkpoint 的最长边界
```

报告 Figure 12 的教学案例：

```text
6144-token physical page
12 × 512-token hash blocks
request 前 2800 token 相同
合法 hit boundary = 2560 = 5 × 512
```

这是报告示例，不代表所有生产配置固定使用 6144/512。

### 16.5 并发一致性

K3 报告明确处理：

- 命中页在所有 cache groups 先 pin，再分配；
- 当前 scheduling step 刚 copy / register 的 block 暂不允许匹配；
- 任一 KDA group 驱逐 checkpoint，兄弟 checkpoint 原子失效；
- hit state 只读，恢复到请求私有 running state，避免原地污染共享前缀。

这说明 prefix cache 的难点不只是 hash，而是“命中状态是否真的对应那个 token prefix”。

### 16.6 KDA speculative decode 不能直接回滚

KDA state 每步原地更新。若 draft 后半被拒绝，state 已越过最后 accepted token。
逐 draft position 保存完整 state 会让 state traffic 爆炸。

K3 §5.4.2：

- 只 cache 比 state 小得多的 projected inputs；
- verification 后在片上 replay accepted tokens；
- 写回 verified 与 bonus token state；
- convolution、normalization、gate、KDA recurrence 融进同一 loop。

这与 ReplaySSM concurrent work 独立提出的思路相呼应。

### 16.7 MTP → EAGLE-3 draft

K3：

- 预训练有一层 MTP；
- post-training 冻结 target，只微调 draft layer 与 feature-fusion projection；
- EAGLE-3 draft 融合第 1、4、最后 AttnRes block 的低/中/高层特征；
- training-time draft unroll 7 steps；
- 直接最小化

```text
L_LK = -log Σ_x min(p(x), q(x))
```

即 acceptance mass 的负对数，而非只用 KL surrogate。报告没有公开整套生产 speedup 常数，
页面不自行补数。

### 16.8 Deployment-aware post-training

K3 从 SFT 起对 MoE expert weights 做 MXFP4、expert input activations 做 MXFP8 QAT；
non-expert modules 保持更高精度。RL rollout 与 training 使用同一量化 scheme，目标是减少
train–inference mismatch。

这不是“全模型 FP4”，也不是 weight-only PTQ。

### 16.9 Fleet 两条政策

1. **cache-aware affinity**
   - 报告举例：典型 coding input 有 400K prefix，只增 4K prefill；
   - primary cluster 保 cache；
   - consistent hash 预分配 secondary，故障时 secondary 重做 prefill；
   - secondary assignments 在 fleet 分散，避免一个故障把重算压到单点。

2. **budget-based admission**
   - 短请求 `<2K` 与最长 `1M` 成本跨度约三阶；
   - 不再用“平均请求”规划；
   - 不同 request classes 独立 resource budget；
   - long-context burst 只能消耗自己的份额。

一手来源：

- [Kimi K3](https://arxiv.org/abs/2607.24653)
- [Kimi K3 official repository](https://github.com/MoonshotAI/Kimi-K3)
- [FlashKDA](https://github.com/MoonshotAI/FlashKDA)

---

## 17. 一条清晰的历史脉络

### Wave A · 2019–2021：先理解生成式推理的内存墙

- MQA 减少 KV heads；
- Clockwork 把可预测执行与 SLO 隔离带入模型 serving；
- 通用 TP/PP 与 inference engine 证明超大模型可以跨设备跑。

### Wave B · 2022：服务粒度从“请求”降到“token iteration”

- Orca iteration-level scheduling；
- FlashAttention 从 IO 重排 exact attention；
- LLM.int8 与 DeepSpeed-MoE 打开低精度 / 稀疏服务路线；
- speculative decoding 证明可以保持 target distribution。

### Wave C · 2023：LLM 专用内存管理形成

- FlexGen 用 GPU/CPU/disk offload 提高单 GPU throughput；
- vLLM / PagedAttention 把 KV 变成分页对象；
- FastServe 做可抢占；
- SpecInfer、GPTQ、AWQ；
- CacheGen 开始把 KV 当可压缩、可运输数据；
- SGLang 把结构化程序和 radix cache 接起来。

### Wave D · 2024：单机优化进入阶段分离和缓存网络

- Splitwise / DistServe / Mooncake；
- Sarathi chunked prefill；
- Hydragen / ChunkAttention / CacheBlend；
- KVQuant / KIVI / QServe；
- Medusa / EAGLE / EAGLE-2；
- DeepSeek-V2 MLA、V3 公开部署拓扑。

### Wave E · 2025：kernel runtime 与 model draft 更深共设计

- FlashInfer；
- EAGLE-3；
- FlashMLA / DeepGEMM / DeepEP；
- DeepSeek-V3.2 DSA；
- Kimi Linear 固定状态。

### Wave F · 2026：混合状态、百万上下文与 fleet policy

- DeepSeek-V4 heterogeneous cache + on-disk prefix + FP4；
- Kimi K3 KDA/MLA joint cache、state replay、cache affinity、budget admission。

---

## 18. 正式论文 / 系统链（62 个节点）

| # | 年份 | 节点 | URL | 本章角色 |
|---:|---:|---|---|---|
| 01 | 2019 | Fast Transformer Decoding / MQA | https://arxiv.org/abs/1911.02150 | KV heads |
| 02 | 2020 | Clockwork | https://www.usenix.org/conference/osdi20/presentation/gujarati | SLO / predictability |
| 03 | 2022 | DeepSpeed-MoE | https://arxiv.org/abs/2201.05596 | MoE inference |
| 04 | 2022 | FlashAttention | https://arxiv.org/abs/2205.14135 | IO-aware exact attention |
| 05 | 2022 | ZeRO-Inference | https://arxiv.org/abs/2207.00032 | weight offload |
| 06 | 2022 | Orca | https://www.usenix.org/conference/osdi22/presentation/yu | iteration scheduling |
| 07 | 2022 | LLM.int8 | https://arxiv.org/abs/2208.07339 | outlier-aware INT8 |
| 08 | 2022 | Petals | https://arxiv.org/abs/2209.01188 | distributed pipeline |
| 09 | 2022 | GPTQ | https://arxiv.org/abs/2210.17323 | weight-only PTQ |
| 10 | 2022 | SmoothQuant | https://arxiv.org/abs/2211.10438 | W8A8 |
| 11 | 2022 | Speculative Decoding | https://arxiv.org/abs/2211.17192 | lossless draft / verify |
| 12 | 2023 | Speculative Sampling | https://arxiv.org/abs/2302.01318 | modified rejection |
| 13 | 2023 | AlpaServe | https://arxiv.org/abs/2302.11665 | model-parallel multiplexing |
| 14 | 2023 | FlexGen | https://arxiv.org/abs/2303.06865 | GPU/CPU/disk offload |
| 15 | 2023 | FastServe | https://arxiv.org/abs/2305.05920 | preemptive scheduling |
| 16 | 2023 | SpecInfer | https://arxiv.org/abs/2305.09781 | tree verification |
| 17 | 2023 | AWQ | https://arxiv.org/abs/2306.00978 | activation-aware W4 |
| 18 | 2023 | H2O | https://arxiv.org/abs/2306.14048 | approximate KV eviction |
| 19 | 2023 | FlashAttention-2 | https://arxiv.org/abs/2307.08691 | work partition |
| 20 | 2023 | vLLM / PagedAttention | https://arxiv.org/abs/2309.06180 | paged KV |
| 21 | 2023 | StreamingLLM | https://arxiv.org/abs/2309.17453 | streaming KV policy |
| 22 | 2023 | CacheGen | https://arxiv.org/abs/2310.07240 | KV compression / streaming |
| 23 | 2023 | Prompt Cache | https://arxiv.org/abs/2311.04934 | modular reuse |
| 24 | 2023 | REST | https://arxiv.org/abs/2311.08252 | retrieval draft |
| 25 | 2023 | Splitwise | https://arxiv.org/abs/2311.18677 | phase splitting |
| 26 | 2023 | SGLang | https://arxiv.org/abs/2312.07104 | RadixAttention |
| 27 | 2024 | DistServe | https://arxiv.org/abs/2401.09670 | PD goodput |
| 28 | 2024 | Medusa | https://arxiv.org/abs/2401.10774 | multi-token heads |
| 29 | 2024 | EAGLE | https://arxiv.org/abs/2401.15077 | feature draft |
| 30 | 2024 | BurstGPT | https://arxiv.org/abs/2401.17644 | workload trace |
| 31 | 2024 | KVQuant | https://arxiv.org/abs/2401.18079 | low-bit KV |
| 32 | 2024 | KIVI | https://arxiv.org/abs/2402.02750 | asymmetric 2-bit KV |
| 33 | 2024 | Hydragen | https://arxiv.org/abs/2402.05099 | shared-prefix batch |
| 34 | 2024 | ChunkAttention | https://arxiv.org/abs/2402.15220 | prefix-aware attention |
| 35 | 2024 | Lookahead Decoding | https://arxiv.org/abs/2402.02057 | parallel n-gram verification |
| 36 | 2024 | Sarathi-Serve | https://arxiv.org/abs/2403.02310 | chunked prefill |
| 37 | 2024 | LayerSkip | https://arxiv.org/abs/2404.16710 | self-speculative exit |
| 38 | 2024 | SnapKV | https://arxiv.org/abs/2404.14469 | approximate KV compression |
| 39 | 2024 | DeepSeek-V2 | https://arxiv.org/abs/2405.04434 | MLA |
| 40 | 2024 | QServe | https://arxiv.org/abs/2405.04532 | W4A8KV4 |
| 41 | 2024 | CacheBlend | https://arxiv.org/abs/2405.16444 | non-prefix reuse |
| 42 | 2024 | PyramidKV | https://arxiv.org/abs/2406.02069 | layerwise KV budget |
| 43 | 2024 | Llumnix | https://arxiv.org/abs/2406.03243 | live migration |
| 44 | 2024 | Quest | https://arxiv.org/abs/2406.10774 | query-aware KV sparsity |
| 45 | 2024 | EAGLE-2 | https://arxiv.org/abs/2406.16858 | dynamic draft tree |
| 46 | 2024 | MemServe | https://arxiv.org/abs/2406.17565 | elastic memory pool |
| 47 | 2024 | InfiniGen | https://arxiv.org/abs/2406.19707 | dynamic KV management |
| 48 | 2024 | Preble | https://arxiv.org/abs/2407.00023 | distributed prompt scheduling |
| 49 | 2024 | Mooncake | https://arxiv.org/abs/2407.00079 | KV-centric disaggregation |
| 50 | 2024 | FlashAttention-3 | https://arxiv.org/abs/2407.08608 | Hopper attention |
| 51 | 2024 | DeepSeek-V3 | https://arxiv.org/abs/2412.19437 | PD / redundant experts / MTP |
| 52 | 2025 | FlashInfer | https://arxiv.org/abs/2501.01005 | inference attention engine |
| 53 | 2025 | EAGLE-3 | https://arxiv.org/abs/2503.01840 | multi-layer draft |
| 54 | 2025 | DeepGEMM | https://github.com/deepseek-ai/DeepGEMM | low-precision kernels |
| 55 | 2025 | FlashMLA | https://github.com/deepseek-ai/FlashMLA | MLA kernels |
| 56 | 2025 | DeepEP | https://github.com/deepseek-ai/DeepEP | expert communication |
| 57 | 2025 | Kimi K2 | https://arxiv.org/abs/2507.20534 | architecture-cost co-design |
| 58 | 2025 | Kimi Linear | https://arxiv.org/abs/2510.26692 | fixed recurrent state |
| 59 | 2025 | DeepSeek-V3.2 | https://arxiv.org/abs/2512.02556 | DSA serving cost |
| 60 | 2026 | Kimi K2.5 | https://arxiv.org/abs/2602.02276 | multimodal / agent traffic |
| 61 | 2026 | DeepSeek-V4 | https://arxiv.org/abs/2606.19348 | heterogeneous cache / FP4 |
| 62 | 2026 | Kimi K3 | https://arxiv.org/abs/2607.24653 | hybrid cache / fleet |

---

## 19. 十五张原创视觉合同

1. **四层服务栈**：模型—引擎—内核—fleet；
2. **请求时钟**：queue → prefill → first token → streaming decode；
3. **KV 公式拆箱图**：batch、length、layers、heads、head dim、bytes；
4. **MHA/MQA/GQA/MLA/KDA 状态对照**；
5. **连续预留 vs paged allocator**；
6. **prefill / decode roofline 直觉图**；
7. **request batching → iteration batching → chunked prefill**；
8. **common-prefix radix tree 与 copy-on-write**；
9. **PD 分离的计算流与 KV 运输流**；
10. **speculative draft / verify / accept / correction 状态机**；
11. **W/A/KV 量化对象分层图**；
12. **TP/PP/DP/EP 服务拓扑对照**；
13. **DeepSeek V2→V4 四层谱系**；
14. **Mooncake→K3 hybrid cache 谱系**；
15. **缓存亲和与预算准入的 fleet 双目标图**。

图表规范：

- 全部为原创 HTML/CSS/SVG 重绘；
- 不复制论文原图；
- 每张注明“结构示意 / 解析模型 / 依据报告机制重绘”；
- 作者报告数字紧邻来源与设置；
- 页面颜色：蓝=状态流，铜=资源选择，绿=SLO/验证，紫=集群状态。

---

## 20. 四联交互实验合同

### Lab A · Memory & KV

输入：

- model parameters、weight bits；
- layers、Q heads、KV heads、head dim；
- attention preset：MHA / GQA / MLA teaching ratio / KDA hybrid；
- context length、concurrency、KV bits、block size；
- GPU HBM。

输出：

- weight GiB；
- KV KiB/token/request；
- active KV GiB；
- paged internal waste；
- theoretical concurrency；
- 状态：FIT / KV-LIMITED / OOM。

边界：MLA ratio 与 KDA state size 为显式教学假设；不冒充具体 checkpoint 精确配置。

### Lab B · Batch & Phase

输入：

- short/long prompt mix；
- decode length；
- strategy：static / continuous / chunked / PD；
- batch token budget、chunk size；
- prefill/decode capacity；
- TTFT / TPOT SLO。

输出：

- analytic TTFT / TPOT；
- head-of-line stall；
- request throughput；
- SLO goodput；
- bottleneck phase。

边界：离散事件教学模拟，不是 vLLM/Sarathi/DistServe 实测复现。

### Lab C · Speculative

输入：

- draft length `k`；
- acceptance `a`；
- draft cost / token；
- target step cost；
- parallel verification cost；
- mode：independent LM / Medusa / EAGLE-3 教学 preset。

输出：

- `E[tokens]`；
- expected accepted draft；
- toy speedup；
- wasted draft；
- 最优 `k` 扫描；
- NO GAIN 警告。

边界：独立 acceptance 是教学假设；不把 preset 当作者 benchmark。

### Lab D · Cache & Fleet

输入：

- prefix length / increment；
- hit rate；
- clusters；
- routing：round-robin / cache-affinity；
- secondary failure；
- short / long budgets；
- long-request burst。

输出：

- avoided prefill tokens；
- hot-cluster skew；
- failover recompute；
- short-request SLO；
- admitted / rejected；
- policy recommendation。

边界：K3 的 400K+4K 只作为报告案例 preset；模拟值不代表 Kimi 线上容量。

---

## 21. 二十个正文必须纠正的误解

1. **“显存放得下权重就能服务。”** KV、workspace 和并发才刚开始。
2. **“峰值 FLOPs 能直接推 tokens/s。”** decode 常受 HBM 和通信限制。
3. **“prefill 与 decode 只是同一 forward 的长短版。”** shape、并行与指标不同。
4. **“batch 越大所有用户越快。”** throughput 与 TTFT / TPOT 冲突。
5. **“continuous batching 是一个固定算法。”** 准入、抢占和 token budget 都是策略。
6. **“PagedAttention 降低 attention FLOPs。”** 它首先改内存分配。
7. **“PagedAttention 零碎片。”** 最后 block 仍有内部碎片。
8. **“KV 只由 context length 决定。”** batch、layers、KV heads、dim、precision 都参与。
9. **“GQA、MLA、KDA 是同一种 KV 压缩。”** 它们保留的状态不同。
10. **“相同文本块就能复用 KV。”** 前序上下文与位置改变状态。
11. **“prefix hit rate 是模型属性。”** 它首先是产品流量属性。
12. **“PD 分离一定降本。”** 网络、布局转换与队列可能反噬。
13. **“4-bit 一定比 8-bit 快。”** 没有 kernel path 时可能更慢。
14. **“weight quantization 会压 KV。”** 对象不同。
15. **“speculative decoding 固定加速 2–3×。”** 接受率和 batch 决定净收益。
16. **“draft 越小越好。”** 太弱会让 acceptance 崩溃。
17. **“MoE 只激活少量参数，所以天然便宜。”** 权重带宽和 all-to-all 仍昂贵。
18. **“平均 latency 代表体验。”** burst 和长请求首先出现在 P99。
19. **“tokens/s 就是 goodput。”** 过 SLO 的 token 仍消耗 GPU。
20. **“技术报告数字可以横向排名。”** 硬件、负载、SLO 和基线必须对齐。

---

## 22. 仍然开放的问题

1. K3 KDA/MLA unified page pool 的真实 page bytes、不同模型配置与命中分布未公开；
2. K3 projected-input replay 相对 state snapshots 的完整 latency / bandwidth 曲线未公开；
3. K3 EAGLE-3 draft 的 production acceptance / throughput / tail latency 未公开；
4. K3 budget classes、配额比例与真实 rejection traces 未公开；
5. DeepSeek-V4 三种 SWA on-disk policy 的生产选择分布未公开；
6. DeepSeek-V4 FP4 QAT 的端到端在线质量 / latency / power 消融仍有限；
7. 多模态视觉 Token、tool pauses、Agent KV retention 对传统 serving traces 的影响仍需真实数据；
8. 不同 runtime 对同一 checkpoint 的公平 benchmark 需要冻结 commit、CUDA、kernel 和 sampling；
9. 量化对 function calling、代码 diff、长 Agent 轨迹的细粒度回归证据不足；
10. prefix cache 的隐私、跨租户 side channel 与删除语义需单独安全章节。

---

## 23. 本地核验清单

本轮完整下载并抽取 26 份新增论文 PDF/TXT：

```text
2211.17192  speculative decoding
2302.01318  speculative sampling
2303.06865  FlexGen
2305.05920  FastServe
2305.09781  SpecInfer
2309.06180  vLLM / PagedAttention
2310.07240  CacheGen
2311.18677  Splitwise
2312.07104  SGLang
2401.09670  DistServe
2401.10774  Medusa
2401.15077  EAGLE
2401.18079  KVQuant
2402.02750  KIVI
2402.05099  Hydragen
2402.15220  ChunkAttention
2403.02310  Sarathi-Serve
2405.04532  QServe
2405.16444  CacheBlend
2406.03243  Llumnix
2406.16858  EAGLE-2
2406.17565  MemServe
2407.00023  Preble
2407.00079  Mooncake
2501.01005  FlashInfer
2503.01840  EAGLE-3
```

`2302.11665` AlpaServe 本轮 PDF 下载不完整，正式节点只依据 canonical arXiv 页面定位，
不计入“本地完整 PDF”数字。

复用已有完整缓存：

- FlashAttention / FlashAttention-2；
- LLM.int8 / GPTQ / SmoothQuant / AWQ；
- DeepSpeed-MoE / MegaBlocks / DeepEP；
- DeepSeek-V2 / V3 / V3.2 / V4；
- Kimi K2 / K2.5 / Kimi Linear / K3。

---

## 24. 章节发布闸门

- [ ] 18 张账在页面首屏可见；
- [ ] 62 个正式节点逐项链接；
- [ ] TTFT / TPOT / throughput / goodput 首次出现即区分；
- [ ] KV 公式可由交互实验复算；
- [ ] PagedAttention 不写成 FLOPs 优化或零碎片；
- [ ] prefill / decode 的“常见 regime”不写成不可变定律；
- [ ] prefix / non-prefix reuse 分开；
- [ ] PD 收益与 KV transfer cost 同图；
- [ ] speculative exactness、接受率和 toy 假设明确；
- [ ] W / A / KV 量化分开；
- [ ] DeepSeek V2→V4 四层谱系独立高亮；
- [ ] Mooncake→K3 hybrid cache 独立高亮；
- [ ] 所有作者 speedup 带设置与“作者报告”标签；
- [ ] 四个实验均支持键盘 tabs；
- [ ] 390px 无文档级横向溢出；
- [ ] 全站链接、构建与既有专题回归通过。