Files

T

wuyang db2b7d3570 feat: add inference serving chapter

2026-07-29 08:39:32 +08:00

46 KiB

Raw Blame History

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

状态：首版证据核验完成，供 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 请求同时穿过四层：

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

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

prefill 与 decode 分账：两者的并行度、算术强度和用户指标不同；
权重与状态分账：量化权重不等于压缩 KV Cache；
吞吐与 goodput 分账：超时后完成的 token 可能不产生产品价值；
算法与实现分账：低 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：

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

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：

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：

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

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

教学例：

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，但更新/回滚更复杂

一手来源：

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

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

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

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

PagedAttention 借鉴虚拟内存：

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：

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

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 容量与排队。

因此常见直觉是：

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

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

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

一手来源：Splitwise

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

6.1 Request-level batching 的队头阻塞

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

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

6.2 Orca 的转折

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

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

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

一手来源：Orca, OSDI 2022

6.3 Continuous batching 仍有决策

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

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

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

一手来源：

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

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

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

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 的异步与低精度路径。

一手来源：

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

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 单机制常数。

一手来源：

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

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：

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 三个关键节点

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

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

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

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

一手来源：

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

11.1 核心协议

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

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

一手来源：

11.2 接受率是加速墙

每步 acceptance mass：

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

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

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)：

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	低/中/高层特征	训练数据与实现

一手来源：

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。

一手来源：

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 的三张隐藏账

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

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

一手来源：

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

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

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

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

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

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

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

14.3 迁移与重调度

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

一手来源：Llumnix, OSDI 2024

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

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

页面必须解释：

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

15. Q18：DeepSeek 推理服务谱系

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

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

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

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

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

V4 同时有：

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

因此报告设计：

fixed-size state cache 管 SWA 与未压缩 tail；
classical KV cache 管 CSA/HCA 压缩条目；
cache block 覆盖 lcm(m, m') 个原 token；
sparse kernel 与 layout 共设计；
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

15.5 DeepSeek 官方内核生态

FlashMLA：dense/sparse MLA prefill/decode、FP8 KV；
DeepGEMM：FP8/FP4/BF16、MoE、indexer 等；
DeepEP：expert dispatch/combine；
open-infra-index：官方基础设施索引。

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

16. Kimi / Moonshot 推理服务谱系

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 起点。

一手来源：

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

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

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

一手来源：Kimi K2

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 的解法：

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

报告 Figure 12 的教学案例：

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；
直接最小化

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 两条政策

cache-aware affinity
- 报告举例：典型 coding input 有 400K prefix，只增 4K prefill；
- primary cluster 保 cache；
- consistent hash 预分配 secondary，故障时 secondary 重做 prefill；
- secondary assignments 在 fleet 分散，避免一个故障把重算压到单点。
budget-based admission
- 短请求 <2K 与最长 1M 成本跨度约三阶；
- 不再用“平均请求”规划；
- 不同 request classes 独立 resource budget；
- long-context burst 只能消耗自己的份额。

一手来源：

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. 十五张原创视觉合同

四层服务栈：模型—引擎—内核—fleet；
请求时钟：queue → prefill → first token → streaming decode；
KV 公式拆箱图：batch、length、layers、heads、head dim、bytes；
MHA/MQA/GQA/MLA/KDA 状态对照；
连续预留 vs paged allocator；
prefill / decode roofline 直觉图；
request batching → iteration batching → chunked prefill；
common-prefix radix tree 与 copy-on-write；
PD 分离的计算流与 KV 运输流；
speculative draft / verify / accept / correction 状态机；
W/A/KV 量化对象分层图；
TP/PP/DP/EP 服务拓扑对照；
DeepSeek V2→V4 四层谱系；
Mooncake→K3 hybrid cache 谱系；
缓存亲和与预算准入的 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. 二十个正文必须纠正的误解

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

22. 仍然开放的问题

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

23. 本地核验清单

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

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 无文档级横向溢出；
全站链接、构建与既有专题回归通过。

46 KiB Raw Blame History Unescape Escape

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

0. 本章真正回答什么

1. 十八张独立问题账

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

2.1 指标不是同义词

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

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

3.1 权重下界

3.2 标准注意力 KV 公式

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

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

4.1 “近零浪费”不等于零

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

5.1 Prefill

5.2 Decode

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

6.1 Request-level batching 的队头阻塞

6.2 Orca 的转折

6.3 Continuous batching 仍有决策

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

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

8.1 FlashAttention：精确 attention 的 IO 重排

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

8.3 Kernel 快不等于端到端快

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

9.1 最安全的基本条件

9.2 三种复用层次

9.3 CacheGen：运输也可以是瓶颈

10. Q11：Prefill–Decode Disaggregation

10.1 为什么拆

10.2 新增的账

10.3 三个关键节点

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

11.1 核心协议

11.2 接受率是加速墙

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

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

12.1 关键路线

12.2 低位不保证更快

13. Q14–Q15：并行与 MoE Serving

13.1 四种并行的服务含义

13.2 MoE 的三张隐藏账

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

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

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

14.3 迁移与重调度

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

15. Q18：DeepSeek 推理服务谱系

15.1 DeepSeek-V2：先改模型状态

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

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

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

15.5 DeepSeek 官方内核生态

16. Kimi / Moonshot 推理服务谱系

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

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

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

16.4 物理块、hash 块和 checkpoint 解耦

16.5 并发一致性

16.6 KDA speculative decode 不能直接回滚

16.7 MTP → EAGLE-3 draft

16.8 Deployment-aware post-training

16.9 Fleet 两条政策

17. 一条清晰的历史脉络

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

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

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

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

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

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

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

19. 十五张原创视觉合同

20. 四联交互实验合同

Lab A · Memory & KV

Lab B · Batch & Phase

Lab C · Speculative

Lab D · Cache & Fleet

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

22. 仍然开放的问题

46 KiB

Raw Blame History