# 推理服务与低成本部署：Grok 候选召回账

> 状态：`UNVERIFIED CANDIDATE LEADS`
>
> 生成方式：2026-07-29 使用本机 Grok CLI Headless 做候选召回。
>
> 使用边界：本文件只负责查漏，不承载正文事实、公式或数字。标题、年份、URL、归属和性能数字
> 必须由主代理回到论文、会议正式页、作者技术报告或官方仓库逐项核验。无法定位的一律淘汰，
> 不用“可能存在”的占位节点填满时间线。

## 1. Grok 收到的检索合同

围绕 2019–2026 的 LLM inference / serving，候选必须尽量覆盖：

1. KV Cache 容量公式、分页、碎片、共享与迁移；
2. request / iteration / continuous batching；
3. prefill 与 decode 的算力—带宽差异；
4. chunked prefill 与 tail latency；
5. FlashAttention、FlashDecoding、FlashInfer 等内核；
6. prefill–decode disaggregation；
7. prefix / radix cache、RAG 非前缀复用与外部缓存池；
8. speculative sampling、树验证、Medusa、EAGLE 与 MTP；
9. 权重、激活、KV Cache 量化与真实内核收益；
10. tensor / pipeline / expert parallel 与 MoE serving；
11. 调度、SLO、goodput、尾延迟、公平和过载；
12. DeepSeek MLA / DSA / FP4 与服务部署；
13. Mooncake、Kimi K2/K2.5/K3、KDA-aware cache；
14. 性能模拟、负载轨迹、能耗与成本口径。

## 2. 十八张候选问题账

| # | 账本 | 核心问题 |
|---|---|---|
| Q1 | 指标 | TTFT、TPOT、E2E latency、throughput、goodput 各测什么？ |
| Q2 | 权重 | 模型权重、量化 scale 与运行时 workspace 占多少显存？ |
| Q3 | KV | 每 token、每层、每请求的 KV Cache 怎样增长？ |
| Q4 | 碎片 | 预留容量与真实 token 为什么差这么多？ |
| Q5 | 阶段 | prefill 与 decode 为什么像两种不同工作负载？ |
| Q6 | 批处理 | static、iteration-level、continuous batching 的调度粒度有何不同？ |
| Q7 | 干扰 | 长 prefill 为什么会让正在 decode 的请求“卡一下”？ |
| Q8 | 内核 | FLOPs 少为什么仍可能慢？HBM、SRAM、融合与 launch 如何记账？ |
| Q9 | 前缀 | 哪些 KV 可以合法复用？位置、掩码和前序上下文怎样限制复用？ |
| Q10 | 分离 | PD 分离省下什么，又新增哪些 KV 运输与排队成本？ |
| Q11 | 推测 | 接受率、draft 成本与验证并行度怎样决定净加速？ |
| Q12 | 量化 | W/A/KV 分别量化到几位，速度与质量是否真的同时改善？ |
| Q13 | 并行 | TP、PP、DP、EP 应怎样映射到 prefill 与 decode？ |
| Q14 | MoE | 激活参数少，为何权重带宽、all-to-all 与专家倾斜仍昂贵？ |
| Q15 | 调度 | 平均 tokens/s、P99、fairness 与 SLO 为什么会互相冲突？ |
| Q16 | 集群 | 请求迁移、缓存亲和、故障切换和扩缩容怎样共同决策？ |
| Q17 | 成本 | `$ / 1M input tokens` 与 `$ / 1M output tokens` 为什么不能混算？ |
| Q18 | 谱系 | DeepSeek 与 Kimi 在模型结构、内核、缓存和 fleet 各改了哪一层？ |

## 3. Grok 候选节点

### 3.1 KV、分页与压缩

- PagedAttention / vLLM — `2309.06180`
- H2O — `2306.14048`
- StreamingLLM — `2309.17453`
- KVQuant — `2401.18079`
- KIVI — `2402.02750`
- SnapKV — `2404.14469`
- PyramidKV — `2406.02069`
- Quest — `2406.10774`
- InfiniGen — `2406.19707`

### 3.2 批处理与调度

- Clockwork — USENIX OSDI 2020
- Orca — USENIX OSDI 2022
- AlpaServe — `2302.11665`
- FastServe — `2305.05920`
- vLLM — `2309.06180`
- Fairness in Serving Large Language Models — `2401.00588`
- Sarathi-Serve — `2403.02310`
- Llumnix — `2406.03243`
- Preble — `2407.00023`

### 3.3 注意力与解码内核

- FlashAttention — `2205.14135`
- FlashAttention-2 — `2307.08691`
- FlashDecoding — Stanford CRFM 官方技术说明
- FlashDecoding++ — `2311.01282`
- FlashAttention-3 — `2407.08608`
- FlashInfer — `2501.01005`
- DeepSeek FlashMLA — 官方仓库
- DeepSeek DeepGEMM — 官方仓库
- Moonshot FlashKDA — 官方仓库

### 3.4 PD 分离与 KV 运输

- Splitwise — `2311.18677`
- DistServe — `2401.09670`
- DéjàVu — `2403.01876`
- MemServe — `2406.17565`
- Mooncake — `2407.00079`
- P/D-Serve — `2408.08147`

### 3.5 前缀和上下文复用

- Prompt Cache — `2311.04934`
- SGLang / RadixAttention — `2312.07104`
- Hydragen — `2402.05099`
- ChunkAttention — `2402.15220`
- CacheGen — `2310.07240`
- CacheBlend — `2405.16444`
- Preble — `2407.00023`
- MemServe — `2406.17565`

### 3.6 推测解码

- Fast Inference via Speculative Decoding — `2211.17192`
- Speculative Sampling — `2302.01318`
- SpecInfer — `2305.09781`
- REST — `2311.08252`
- Medusa — `2401.10774`
- EAGLE — `2401.15077`
- Lookahead Decoding — `2402.02057`
- EAGLE-2 — `2406.16858`
- LayerSkip — `2404.16710`
- EAGLE-3 — `2503.01840`
- DeepSeek-V3 MTP、K3 MTP→EAGLE-3 draft

### 3.7 量化

- LLM.int8 — `2208.07339`
- GPTQ — `2210.17323`
- SmoothQuant — `2211.10438`
- AWQ — `2306.00978`
- KVQuant — `2401.18079`
- KIVI — `2402.02750`
- QuaRot — `2404.00456`
- QServe — `2405.04532`
- DeepSeek-V4 FP4 QAT、K3 MXFP4/MXFP8 post-training

### 3.8 分布式与 MoE

- DeepSpeed-MoE — `2201.05596`
- FasterMoE — `2202.09368`
- Petals — `2209.01188`
- MegaBlocks — `2211.15841`
- FlexGen — `2303.06865`
- DeepEP — DeepSeek 官方仓库
- TensorRT-LLM、TGI、vLLM、SGLang — 官方 runtime 节点

### 3.9 DeepSeek / Kimi

- DeepSeek-V2 — `2405.04434`：MLA 与 DeepSeekMoE；
- DeepSeek-V3 — `2412.19437`：PD 分离、冗余专家、MTP；
- DeepSeek-V3.2 — `2512.02556`：DSA 的 prefill / decode 成本；
- DeepSeek-V4 — `2606.19348`：异构 cache、on-disk prefix cache、FP4；
- Mooncake — `2407.00079`：Kimi 生产 serving 平台；
- Kimi K2 — `2507.20534`：MLA / MoE 结构对服务成本的约束；
- Kimi Linear — `2510.26692`：KDA 的固定状态路线；
- Kimi K2.5 — `2602.02276`：多模态与 Agent 流量背景；
- Kimi K3 — `2607.24653`：KDA-aware cache、KDA decode replay、预算式准入。

### 3.10 负载与评测

- BurstGPT — `2401.17644`
- Vidur — `2405.05465`
- ShareGPT workload traces
- MLPerf Inference / GenAI
- LLMPerf / GenAI-Perf 官方负载生成器

## 4. Grok 输出中已识别的错误与淘汰项

以下不进入正式账本，除非后来找到一手来源：

- “MegaScale-Infer / MegaScale-MoE”无准确标题和 URL 的占位节点；
- “UGache”无可确认论文；
- 把 FastChat / Chatbot Arena 当 serving 性能基准；
- 把 Kimi k1.5 的推理能力报告当成生产 serving 论文；
- 把 Megatron-LM 训练论文直接当 MoE serving 证据；
- 把某个框架 README 的当前功能倒灌为原始论文贡献；
- 把所有 KV pruning / eviction 近似都写成无损；
- 把任何作者报告 speedup 当跨硬件、跨 workload 的常数。

## 5. 四个候选交互实验

1. **显存与 KV 账本**：MHA / GQA / MLA / KDA hybrid、精度、上下文、并发共同决定容量。
2. **批处理与阶段调度**：static / continuous / chunked / PD 对 TTFT、TPOT 和 goodput 的影响。
3. **推测接受率墙**：draft 长度、接受率、draft 成本和 target verification 成本共同决定 speedup。
4. **缓存与 fleet**：前缀命中、缓存亲和、故障副本和长短请求预算共同决定尾延迟。

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

1. 显存能装下权重，就能稳定服务。
2. 推理速度等于峰值 FLOPs。
3. prefill 和 decode 是同一种 kernel 工作负载。
4. batch 越大，所有用户都越快。
5. continuous batching 会自动解决队头阻塞。
6. PagedAttention 减少了模型的理论 FLOPs。
7. KV Cache 只与上下文长度有关，与 batch、层数和 KV heads 无关。
8. GQA、MLA、KDA 都只是同一种“压缩 KV”。
9. 前缀缓存可以复用任意相同文本块。
10. cache hit rate 是模型固有指标。
11. PD 分离一定比共置更便宜。
12. KV 迁移只需考虑带宽，不需考虑排队与拓扑。
13. 量化位数越低一定越快。
14. weight-only 量化会同比减少 KV Cache。
15. speculative decoding 保证 2–3×。
16. draft 越小越有利。
17. MoE 激活参数少，所以在线服务天然便宜。
18. 平均 latency 好就代表用户体验好。
19. tokens/s、requests/s、goodput 可以互换。
20. 官方技术报告的部署数字可直接当成跨系统可复现基准。

## 7. 转正式账本的硬闸门

- 每个正文节点必须有 canonical primary URL；
- 关键公式必须从架构维度推导或来自论文正文；
- 作者报告数字必须带模型、硬件、负载与对照边界；
- 教学模拟值必须标“解析模型 / 教学假设”，不得伪装成实测；
- DeepSeek 与 Kimi 必须按“模型结构—单机内核—缓存—集群调度”四层分别画；
- “推理”能力、test-time compute 与“推理服务”不得混为一章。