diff --git a/PROGRESS.md b/PROGRESS.md index d5f8ac7..3360d81 100644 --- a/PROGRESS.md +++ b/PROGRESS.md @@ -21,6 +21,7 @@ | 稀疏计算与 MoE | 完成首版 | 74% | 真实负载 traces 与专家特化案例 | | 长上下文专题 | 完成首版 | 72% | 真实模型配置、内核细节与失败案例 | | 大规模训练系统 | 完成首版 | 71% | 真实集群 traces、故障案例与精确 topology 配置 | +| 推理服务与低成本部署 | 完成首版 | 78% | 真实 GPU kernel / workload traces、功耗与跨框架复现 | | 数值精度、优化器与稳定性 | 完成首版 | 75% | 真实 kernel 吞吐、长程训练 traces 与逐图论文精读 | | 引用与事实检查 | 进行中 | 57% | 自动化外链复查与来源等级扩展 | | 开源仓库 | 已完成首版 | 100% | 持续提交研究与网站迭代 | @@ -35,10 +36,10 @@ - [x] 提炼参考网站的编辑设计语言。 - [x] 确认 `git.k1412.top` 为 Gitea/Forgejo 兼容服务且本机 HTTPS 凭据可用于既有仓库。 - [x] 使用 Grok CLI 检索并形成约 95 篇一手论文的补充路线，主代理已回查关键来源。 -- [x] 完成 355 篇关键论文索引，覆盖 14 个标签专题与 Kimi/DeepSeek 聚光主线。 +- [x] 完成 400 篇关键论文索引，覆盖 15 个标签专题与 Kimi/DeepSeek 聚光主线。 - [x] 完成可检索、可按专题筛选的论文库页面。 -- [x] 完成 K3、语言模型前史、Transformer 基础、DeepSeek 谱系、Scaling Laws、数据工程、长上下文、MoE、指令微调与人类偏好、推理、Agent、原生多模态、训练系统与数值优化十四篇首版长文。 -- [x] 完成 K3 三轴架构、语言模型前史四联实验、Transformer 四联实验、DeepSeek 谱系、长上下文、MoE 路由、推理三页签，以及训练系统、Scaling、数据工程、数值、Alignment、Agent 与原生多模态专题各四页签等四十三个原创交互视图。 +- [x] 完成 K3、语言模型前史、Transformer 基础、DeepSeek 谱系、Scaling Laws、数据工程、长上下文、MoE、指令微调与人类偏好、推理、Agent、原生多模态、训练系统、推理服务与数值优化十五篇首版长文。 +- [x] 完成 K3 三轴架构、语言模型前史四联实验、Transformer 四联实验、DeepSeek 谱系、长上下文、MoE 路由、推理三页签，以及训练系统、推理服务、Scaling、数据工程、数值、Alignment、Agent 与原生多模态专题各四页签等四十七个原创交互视图。 - [x] 完成长上下文首版：五张成本账、26 篇一手论文、10+ 机制图与 8 策略交互实验室。 - [x] 核验 FlashAttention、DeepSeek-V2/V3.2/V4、Kimi Linear/K3 等六份论文原文，并建立长上下文研究账本。 - [x] 核验 Switch、ST-MoE、DeepSeekMoE、Loss-Free、V3、LatentMoE 与 K3 原文，并建立 MoE 研究账本。 @@ -117,9 +118,16 @@ - [x] 原生多模态真实 Chrome 断言通过：视觉 Token 超预算、K3 五维原生训练、OCR 报告 / 插值 / 证据外边界、vision-in-the-loop、键盘 tabs 与 390px 移动端均正确响应。 - [x] Astro 类型检查、生产构建、18 个页面、875 个站内引用和 17 个跨页锚点通过；多模态页面桌面 / 移动端无文档级横向溢出。 - [x] 原生多模态首版以源提交 `9f56732`、不可变镜像 `20260728T235248Z-9f56732` 发布；NAS、VPS/Tailscale、NPM、DNS、HTTPS、证书、门户、公开 Forgejo 与十一套生产 Chrome 回归全链路通过。 +- [x] 启动推理服务与低成本部署专题：用十八本账拆开请求形状、SLO、权重、增长状态、内存分配、阶段、缓存、Kernel、推测、并行、网络、路由、故障与经济性。 +- [x] 使用 Grok Headless 扩展 70 个候选节点；正式账本回查 26 份完整 PDF/TXT、官方会议页与 DeepSeek/Kimi 报告，候选与证据永久分离。 +- [x] 完成推理服务首版：31 个正文目录、62 个一手节点、DeepSeek V2→V4 与 Mooncake→K3 双谱系，以及显存—阶段—推测—集群四联实验。 +- [x] 论文库新增「推理服务」标签与 vLLM、SGLang、DistServe、Sarathi、FlashInfer、EAGLE-3、DeepGEMM、FlashMLA 等 45 个节点，从 355 篇扩充至 400 篇。 +- [x] 推理服务真实 Chrome 断言通过：MHA OOM、chunked prefill 降低 stall、慢网络反噬 P/D、低验收率负加速、缓存故障重算、平均准入伤害短请求、键盘 tabs 与 390px 移动端均正确响应。 +- [x] Astro 类型检查、生产构建、19 个页面、962 个站内引用和 16 个跨页锚点通过；推理服务页面桌面 / 移动端无文档级横向溢出。 ## 正在进行 +- [ ] 推理服务二轮：真实 GPU kernel / workload traces、功耗与成本、跨 vLLM / SGLang / TensorRT-LLM 复现。 - [ ] 原生多模态二轮：真实视觉 Token traces、跨分辨率 / connector 消融、OCR 与视觉 Agent 安全失败案例。 - [ ] Agent 二轮：真实环境 traces、cross-harness ablation、Agent RL 训练曲线与提示注入案例。 - [ ] Transformer 二轮：多头电路逐图、Pre/Post-LN 真实 traces、Flash/KV kernel 与模型配置对照。 @@ -203,6 +211,11 @@ | 2026-07-29 | 光学压缩实验显式分三级证据 | DeepSeek-OCR 报告锚点、中间教学插值与超过已核范围的“不外推”在交互中使用不同状态 | | 2026-07-29 | 论文库扩充到 355 篇 | 新增 41 个视觉表示、连接器、分辨率、OCR、视频、统一生成、评测与视觉 RL 节点 | | 2026-07-29 | 原生多模态首版用不可变镜像 `20260728T235248Z-9f56732` 发布 | OCI digest `sha256:b9c66e4e…07955`；复用 `12010→8080`、NPM host 31 / cert 41、门户 order 180 与公开 Forgejo | +| 2026-07-29 | 推理服务拆成十八本彼此独立的账 | 权重、增长状态、分配、阶段、batch、cache、kernel、推测、量化、网络、路由、故障与经济性不再压成一个 tokens/s | +| 2026-07-29 | Grok 推理服务召回与正式证据永久分离 | 70 个候选节点只负责查漏；26 份完整 PDF/TXT、会议页、官方仓库和模型报告承载正文事实 | +| 2026-07-29 | DeepSeek 与 Kimi 服务谱系按状态对象重建 | MLA→V4 异构状态和 Mooncake→KDA→K3 混合缓存分开讲，精确 KV 公式不套到异构状态上 | +| 2026-07-29 | 论文库扩充到 400 篇 | 新增 45 个内存管理、调度、缓存、P/D 解耦、量化、推测解码、kernel 与真实 workload 节点 | +| 2026-07-29 | 推理服务首版用四个独立实验闭环 | 显存、阶段干扰、推测验收和集群状态分开建模；作者报告、教学估算与 benchmark 永久分级 | ## 未决问题 diff --git a/README.md b/README.md index c5ce915..9360046 100644 --- a/README.md +++ b/README.md @@ -17,9 +17,9 @@ - 持续进度：[PROGRESS.md](./PROGRESS.md) - 证据与写作规范：[research/METHODOLOGY.md](./research/METHODOLOGY.md) -当前里程碑包含 16 专题学习地图、355 篇关键论文索引、Kimi K3 完整导读， -语言模型前史、Transformer 基础、DeepSeek 技术谱系、Scaling Laws、数据工程、长上下文、MoE、指令微调与人类偏好、推理、工具使用与长程 Agent、训练系统与数值优化深度专题， -以及 43 个覆盖核心机制的原创交互视图。 +当前里程碑包含 16 专题学习地图、400 篇关键论文索引、Kimi K3 完整导读， +语言模型前史、Transformer 基础、DeepSeek 技术谱系、Scaling Laws、数据工程、长上下文、MoE、指令微调与人类偏好、推理、工具使用与长程 Agent、原生多模态、训练系统、推理服务与数值优化深度专题， +以及 47 个覆盖核心机制的原创交互视图。 其余专题按进度账本持续扩建。 ## 本地开发 diff --git a/ROADMAP.md b/ROADMAP.md index 3e891e5..7a37428 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -120,6 +120,14 @@ native、光学上下文压缩与 vision-in-the-loop 四个独立实验，所有 KV Cache、PagedAttention/vLLM、连续批处理、推测解码、Prefill/Decode 解耦、前缀缓存、集群调度；Mooncake 与 K3 KDA-aware serving。 +首版已完成：以请求形状、SLO、权重、增长状态、分配、Prefill、Decode、Batch、缓存、Kernel、 +推测、量化、并行、MoE、网络、路由、故障与经济性十八本账，串起 2019–2026 的 62 个一手节点。 +正文明确区分吞吐与 SLO goodput、标准 KV 公式与 MLA/KDA 状态、PagedAttention 的内存收益与 +Transformer FLOPs、作者报告值与教学估算；重点追踪 DeepSeek-V2 MLA → V3 FP8 / MoE 部署 → +V3.2 → V4 异构状态，以及 Mooncake → Kimi Linear → K3 的 69 KDA + 24 Gated MLA、page cache、 +EAGLE-3 draft、cache-aware affinity 与 token-budget admission。配套显存与 KV、Prefill/Decode、 +推测解码、缓存与集群四个独立实验。 + ### 15. 评测、安全与“到底强不强” 困惑度到 MMLU/GPQA/HLE，SWE-bench、OSWorld、BrowseComp；污染、harness、工具预算、LLM-as-a-judge、选择性报告与网络安全边界。 diff --git a/package.json b/package.json index 603270b..417d259 100644 --- a/package.json +++ b/package.json @@ -20,7 +20,8 @@ "check:transformer-browser": "node scripts/check-transformer-browser.mjs", "check:alignment-browser": "node scripts/check-alignment-browser.mjs", "check:agents-browser": "node scripts/check-agents-browser.mjs", - "check:multimodal-browser": "node scripts/check-multimodal-browser.mjs" + "check:multimodal-browser": "node scripts/check-multimodal-browser.mjs", + "check:inference-serving-browser": "node scripts/check-inference-serving-browser.mjs" }, "dependencies": { "@astrojs/sitemap": "3.7.3", diff --git a/research/INFERENCE_SERVING_GROK_LEADS.md b/research/INFERENCE_SERVING_GROK_LEADS.md new file mode 100644 index 0000000..9b4f41c --- /dev/null +++ b/research/INFERENCE_SERVING_GROK_LEADS.md @@ -0,0 +1,217 @@ +# 推理服务与低成本部署：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 与“推理服务”不得混为一章。 diff --git a/research/INFERENCE_SERVING_RESEARCH.md b/research/INFERENCE_SERVING_RESEARCH.md new file mode 100644 index 0000000..9a0694b --- /dev/null +++ b/research/INFERENCE_SERVING_RESEARCH.md @@ -0,0 +1,1226 @@ +# 推理服务与低成本部署：正式研究账本 + +> 状态：首版证据核验完成，供 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 无文档级横向溢出； +- [ ] 全站链接、构建与既有专题回归通过。 diff --git a/research/sources/README.md b/research/sources/README.md index 71a34e6..87eb182 100644 --- a/research/sources/README.md +++ b/research/sources/README.md @@ -54,3 +54,15 @@ Agent 首轮缓存位于 `agents/`（不提交 PDF/TXT）： DeepSeek-VL/VL2、Janus、OCR 三分支，Kimi 三代 MoonViT、十六张问题账、55 节点正文链与四实验合同见 `../MULTIMODAL_RESEARCH.md`；Grok Headless 候选召回只保存在 `../MULTIMODAL_GROK_LEADS.md`，不得作为正式事实来源。 + +推理服务首轮缓存位于 `inference-serving/`（不提交 PDF/TXT）： + +- Clockwork、Orca、vLLM / PagedAttention、SGLang、Sarathi、Llumnix、Splitwise 与 DistServe； +- speculative decoding / sampling、SpecInfer、Medusa、EAGLE / EAGLE-2 / EAGLE-3； +- GPTQ、SmoothQuant、AWQ、KVQuant、KIVI、QServe、FlashInfer 与 Mooncake； +- DeepSeek-V2/V3/V3.2/V4、Kimi Linear/K3 与 DeepGEMM/FlashMLA/DeepEP 复用既有报告或官方仓库缓存。 + +本轮完整校验 26 份新增 PDF/TXT；AlpaServe 只以 canonical arXiv 页面定位，未把不完整本地下载 +计入全文证据。十八本独立账、62 节点阅读链、DeepSeek 与 Kimi 服务谱系、十五组视觉合同和 +四实验合同见 `../INFERENCE_SERVING_RESEARCH.md`。Grok Headless 的 70 个候选只保存在 +`../INFERENCE_SERVING_GROK_LEADS.md`，不能越过一手来源核验进入正文。 diff --git a/scripts/check-agents-browser.mjs b/scripts/check-agents-browser.mjs index 806dec3..892bc04 100644 --- a/scripts/check-agents-browser.mjs +++ b/scripts/check-agents-browser.mjs @@ -217,7 +217,7 @@ if (!overview.title.includes("可靠行动")) failures.push("章节标题异常" if (overview.sections !== 28 || overview.tocLinks !== 28) failures.push("章节/目录数量异常"); if (overview.paperLinks !== 52) failures.push("正式论文链不是 52 个节点"); if (overview.labTabs !== 4 || overview.labPanels !== 4) failures.push("四联实验结构异常"); -if (overview.navLinks !== 17 || home.navLinks !== 17 || mobile.mobileLinks !== 17) failures.push("全站导航未同步 Agent 专题"); +if (overview.navLinks !== 18 || home.navLinks !== 18 || mobile.mobileLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (overview.documentOverflow > 1 || mobile.documentOverflow > 1) failures.push("桌面或移动端存在横向溢出"); if (loop.initial.finalState !== "UNVERIFIED" || loop.directSchema.finalState !== "FAILED") failures.push("控制循环终局状态异常"); if (!loop.directSchema.observation.includes("ERROR schema") || loop.directSchema.recovery !== "FRAGILE") failures.push("Direct/schema 故障传播异常"); @@ -228,8 +228,8 @@ if (numeric(reliability.initial.passAt) <= numeric(reliability.k2.passAt) || num if (reliability.nonIdempotent.sideRisk === "LOW") failures.push("非幂等写操作风险没有提升"); if (numeric(rl.wait.utilization) >= numeric(rl.full.utilization) || numeric(rl.wait.lostWork) <= numeric(rl.full.lostWork)) failures.push("wait-all 长尾/重算方向异常"); if (!rl.wait.takeaway.includes("wait-all") || rl.keyboardSelected !== "rl" || rl.keyboardVisible !== "rl") failures.push("长程 RL 解释或键盘导航异常"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") failures.push("首页 Agent 首发入口异常"); -if (home.paperCount !== "355" || papers.total !== 355 || !papers.hasAgentFilter || papers.agentVisible < 52) failures.push("论文库 Agent 标签或论文总数异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") failures.push("首页推理服务首发入口异常"); +if (home.paperCount !== "400" || papers.total !== 400 || !papers.hasAgentFilter || papers.agentVisible < 52) failures.push("论文库 Agent 标签或论文总数异常"); if (!mobile.menuVisible || mobile.menuOpen !== "true" || mobile.tabs !== 4) failures.push("移动端导航或实验异常"); if (exceptions.length) failures.push(`浏览器异常：${exceptions.join(" | ")}`); diff --git a/scripts/check-alignment-browser.mjs b/scripts/check-alignment-browser.mjs index d583b23..e84abbe 100644 --- a/scripts/check-alignment-browser.mjs +++ b/scripts/check-alignment-browser.mjs @@ -216,7 +216,7 @@ if (!overview.title.includes("真正与人协作")) failures.push("章节标题 if (overview.sections !== 22 || overview.tocLinks !== 22) failures.push("章节/目录数量异常"); if (overview.paperLinks !== 44) failures.push("正式论文链不是 44 个节点"); if (overview.labTabs !== 4 || overview.labPanels !== 4) failures.push("四联实验结构异常"); -if (overview.navLinks !== 17 || home.navLinks !== 17 || mobile.mobileLinks !== 17) failures.push("全站导航未同步后训练专题"); +if (overview.navLinks !== 18 || home.navLinks !== 18 || mobile.mobileLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (overview.documentOverflow > 1 || mobile.documentOverflow > 1) failures.push("桌面或移动端存在横向溢出"); if (sft.initial.active !== "6 / 10" || !sft.initial.lossStates.slice(0, 4).every((value) => value === "MASKED")) failures.push("SFT response-only mask 异常"); if (sft.unsafeAll.active !== "10 / 10" || numeric(sft.unsafeAll.nll) <= numeric(sft.initial.nll) || !sft.unsafeAll.reading.includes("错误")) failures.push("SFT 全序列/坏示范交互异常"); @@ -226,8 +226,8 @@ if (!update.steps[0].includes("Fixed preference")) failures.push("DPO 更新流 if (!recipe.family.includes("Multi-effort") || !recipe.regime.includes("9 RL experts") || !recipe.constraints.includes("verbosity")) failures.push("K3 配方合同异常"); if (!recipe.path.some((step) => step.includes("3 domains × 3 efforts")) || !recipe.path.some((step) => step.includes("MOPD"))) failures.push("K3 配方路径异常"); if (recipe.keyboardSelected !== "recipe" || recipe.keyboardVisible !== "recipe") failures.push("实验 tab 键盘导航异常"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") failures.push("首页 Alignment 首发入口异常"); -if (home.paperCount !== "355" || papers.total !== 355 || !papers.hasAlignmentFilter || papers.alignmentVisible < 35) failures.push("论文库后训练标签或论文总数异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") failures.push("首页推理服务首发入口异常"); +if (home.paperCount !== "400" || papers.total !== 400 || !papers.hasAlignmentFilter || papers.alignmentVisible < 35) failures.push("论文库后训练标签或论文总数异常"); if (!mobile.menuVisible || mobile.menuOpen !== "true" || mobile.tabs !== 4) failures.push("移动端导航或实验异常"); if (exceptions.length) failures.push(`浏览器异常：${exceptions.join(" | ")}`); diff --git a/scripts/check-data-browser.mjs b/scripts/check-data-browser.mjs index a1fd73d..791d23f 100644 --- a/scripts/check-data-browser.mjs +++ b/scripts/check-data-browser.mjs @@ -230,15 +230,15 @@ if (transform.keyboard.selected !== "transform" || transform.keyboard.visible != if (layout.articleSections !== 18 || layout.paperLinks !== 31 || layout.labTabs !== 4 || layout.views !== 4) { failures.push("章节、论文或实验数量异常"); } -if (layout.navLinks !== 17 || mobile.mobileLinks !== 17 || home.navLinks !== 17) failures.push("全站导航未同步数值专题"); +if (layout.navLinks !== 18 || mobile.mobileLinks !== 18 || home.navLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentOverflow > 0) failures.push("页面存在横向溢出"); if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible || mobile.menuOpen !== "true") failures.push("移动端菜单不可用"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") { +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") { failures.push("首页 Transformer 新章入口异常"); } -if (home.paperCount !== "355") failures.push(`首页论文总数异常：${home.paperCount}`); -if (!papers.hasDataFilter || papers.total !== 355 || papers.visible < 25) failures.push("论文库数据标签或论文总数异常"); +if (home.paperCount !== "400") failures.push(`首页论文总数异常：${home.paperCount}`); +if (!papers.hasDataFilter || papers.total !== 400 || papers.visible < 25) failures.push("论文库数据标签或论文总数异常"); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-inference-serving-browser.mjs b/scripts/check-inference-serving-browser.mjs new file mode 100644 index 0000000..e72e15f --- /dev/null +++ b/scripts/check-inference-serving-browser.mjs @@ -0,0 +1,280 @@ +import { writeFileSync } from "node:fs"; + +const cdpPort = process.env.CDP_PORT ?? "9227"; +const baseUrl = process.env.SITE_URL ?? "http://127.0.0.1:4327"; +const pages = await fetch(`http://127.0.0.1:${cdpPort}/json/list`).then((response) => response.json()); +const page = pages.find((entry) => entry.type === "page"); +if (!page) throw new Error(`CDP ${cdpPort} 没有可用页面`); + +const socket = new WebSocket(page.webSocketDebuggerUrl); +await new Promise((resolve, reject) => { + socket.addEventListener("open", resolve, { once: true }); + socket.addEventListener("error", reject, { once: true }); +}); + +let nextId = 0; +const pending = new Map(); +const exceptions = []; +socket.addEventListener("message", (event) => { + const message = JSON.parse(event.data); + if (message.id && pending.has(message.id)) { + const { resolve, reject } = pending.get(message.id); + pending.delete(message.id); + if (message.error) reject(new Error(message.error.message)); + else resolve(message.result); + } + if (message.method === "Runtime.exceptionThrown") { + exceptions.push(message.params.exceptionDetails.exception?.description ?? message.params.exceptionDetails.text); + } +}); + +const command = (method, params = {}) => new Promise((resolve, reject) => { + const id = ++nextId; + pending.set(id, { resolve, reject }); + socket.send(JSON.stringify({ id, method, params })); +}); +const pause = (milliseconds) => new Promise((resolve) => setTimeout(resolve, milliseconds)); +const evaluate = async (expression) => { + const result = await command("Runtime.evaluate", { expression, returnByValue: true, awaitPromise: true }); + if (result.exceptionDetails) throw new Error(result.exceptionDetails.exception?.description ?? result.exceptionDetails.text); + return result.result.value; +}; +const navigate = async (path) => { + await command("Page.navigate", { url: `${baseUrl}${path}` }); + for (let attempt = 0; attempt < 70; attempt += 1) { + await pause(100); + if (await evaluate("document.readyState === 'complete'")) return; + } + throw new Error(`${path} 加载超时`); +}; +const screenshot = async (path) => { + const result = await command("Page.captureScreenshot", { format: "png", captureBeyondViewport: false }); + writeFileSync(path, Buffer.from(result.data, "base64")); +}; + +await command("Page.enable"); +await command("Runtime.enable"); +await command("Emulation.setDeviceMetricsOverride", { + width: 1440, + height: 1100, + deviceScaleFactor: 1, + mobile: false, +}); +await navigate("/systems/inference/"); +await screenshot("/tmp/llm-atlas-inference-desktop.png"); + +const overview = await evaluate(`(() => ({ + title: document.querySelector("h1")?.textContent.trim(), + sections: document.querySelectorAll(".article-section").length, + tocLinks: document.querySelectorAll(".side-rail a").length, + paperLinks: document.querySelectorAll(".paper-chain a").length, + labTabs: document.querySelectorAll("[data-is-tab]").length, + labPanels: document.querySelectorAll("[data-is-panel]").length, + ledgers: document.querySelectorAll(".ledger-grid > article").length, + navLinks: document.querySelectorAll(".top-nav a").length, + documentOverflow: document.documentElement.scrollWidth - document.documentElement.clientWidth, +}))()`); + +const memory = await evaluate(`(() => { + const root = document.querySelector("[data-inference-lab]"); + const read = () => ({ + weight: root.querySelector("[data-memory-weight]").textContent.trim(), + perToken: root.querySelector("[data-memory-kv-token]").textContent.trim(), + request: root.querySelector("[data-memory-request]").textContent.trim(), + active: root.querySelector("[data-memory-active]").textContent.trim(), + fit: root.querySelector("[data-memory-fit]").textContent.trim(), + status: root.querySelector("[data-memory-status]").textContent.trim(), + note: root.querySelector("[data-memory-note]").textContent.trim(), + visible: root.querySelector("[data-is-panel]:not([hidden])").dataset.isPanel, + }); + const initial = read(); + root.querySelector('[data-memory-preset="mha"]').click(); + const params = root.querySelector("[data-memory-params]"); + const context = root.querySelector("[data-memory-context]"); + const concurrency = root.querySelector("[data-memory-concurrency]"); + params.value = "671"; + params.dispatchEvent(new Event("input", { bubbles: true })); + context.value = "131072"; + context.dispatchEvent(new Event("input", { bubbles: true })); + concurrency.value = "32"; + concurrency.dispatchEvent(new Event("input", { bubbles: true })); + const exploded = read(); + root.querySelector('[data-memory-preset="k3"]').click(); + const k3 = read(); + return { initial, exploded, k3 }; +})()`); + +const phase = await evaluate(`(() => { + const root = document.querySelector("[data-inference-lab]"); + root.querySelector('[data-is-tab="phase"]').click(); + const read = () => ({ + ttft: root.querySelector("[data-phase-ttft]").textContent.trim(), + tpot: root.querySelector("[data-phase-tpot]").textContent.trim(), + goodput: root.querySelector("[data-phase-goodput]").textContent.trim(), + stall: root.querySelector("[data-phase-stall]").textContent.trim(), + bottleneck: root.querySelector("[data-phase-bottleneck]").textContent.trim(), + status: root.querySelector("[data-phase-status]").textContent.trim(), + }); + const staticBatch = read(); + root.querySelector('[data-phase-strategy="chunked"]').click(); + const chunked = read(); + root.querySelector('[data-phase-strategy="pd"]').click(); + const network = root.querySelector("[data-phase-network]"); + network.value = "25"; + network.dispatchEvent(new Event("input", { bubbles: true })); + const slowPd = read(); + return { staticBatch, chunked, slowPd }; +})()`); + +const speculative = await evaluate(`(() => { + const root = document.querySelector("[data-inference-lab]"); + root.querySelector('[data-is-tab="speculative"]').click(); + const read = () => ({ + expected: root.querySelector("[data-spec-expected]").textContent.trim(), + speedup: root.querySelector("[data-spec-speedup]").textContent.trim(), + waste: root.querySelector("[data-spec-waste]").textContent.trim(), + status: root.querySelector("[data-spec-status]").textContent.trim(), + evidence: root.querySelector("[data-spec-evidence]").textContent.trim(), + tokens: root.querySelectorAll("[data-spec-strip] i").length, + }); + const k3 = read(); + const acceptance = root.querySelector("[data-spec-a]"); + acceptance.value = "20"; + acceptance.dispatchEvent(new Event("input", { bubbles: true })); + const lowAcceptance = read(); + return { k3, lowAcceptance }; +})()`); + +const fleet = await evaluate(`(() => { + const root = document.querySelector("[data-inference-lab]"); + root.querySelector('[data-is-tab="fleet"]').click(); + root.querySelector("[data-fleet-k3]").click(); + const read = () => ({ + avoided: root.querySelector("[data-fleet-avoided]").textContent.trim(), + skew: root.querySelector("[data-fleet-skew]").textContent.trim(), + recompute: root.querySelector("[data-fleet-recompute]").textContent.trim(), + admitted: root.querySelector("[data-fleet-admitted]").textContent.trim(), + rejected: root.querySelector("[data-fleet-rejected]").textContent.trim(), + shortSlo: root.querySelector("[data-fleet-short-slo]").textContent.trim(), + state: root.querySelector("[data-fleet-state]").textContent.trim(), + }); + const k3 = read(); + const failure = root.querySelector("[data-fleet-failure]"); + failure.checked = true; + failure.dispatchEvent(new Event("input", { bubbles: true })); + const failed = read(); + failure.checked = false; + failure.dispatchEvent(new Event("input", { bubbles: true })); + const admission = root.querySelector("[data-fleet-admission]"); + const burst = root.querySelector("[data-fleet-burst]"); + admission.value = "average"; + admission.dispatchEvent(new Event("input", { bubbles: true })); + burst.value = "100"; + burst.dispatchEvent(new Event("input", { bubbles: true })); + const bursty = read(); + const firstTab = root.querySelector('[data-is-tab="memory"]'); + firstTab.focus(); + firstTab.dispatchEvent(new KeyboardEvent("keydown", { key: "ArrowRight", bubbles: true })); + return { + k3, + failed, + bursty, + keyboardSelected: root.querySelector('[data-is-tab][aria-selected="true"]').dataset.isTab, + keyboardVisible: root.querySelector("[data-is-panel]:not([hidden])").dataset.isPanel, + }; +})()`); + +await evaluate(`document.querySelector("[data-inference-lab]").scrollIntoView({ block: "start", behavior: "instant" })`); +await pause(180); +await screenshot("/tmp/llm-atlas-inference-lab-desktop.png"); + +await navigate("/"); +const home = await evaluate(`(() => ({ + releaseCards: document.querySelectorAll(".release-card").length, + firstRelease: document.querySelector(".release-card h2").textContent.trim(), + firstHref: document.querySelector(".release-card").getAttribute("href"), + paperCount: document.querySelector(".hero-stats div:nth-child(3) b").textContent.trim(), + navLinks: document.querySelectorAll(".top-nav a").length, +}))()`); + +await navigate("/papers/"); +const papers = await evaluate(`(() => { + const button = [...document.querySelectorAll("[data-filter]")].find((node) => node.textContent.trim() === "推理服务"); + button?.click(); + return { + total: document.querySelectorAll("[data-paper]").length, + visible: document.querySelectorAll("[data-paper]:not([hidden])").length, + hasFilter: Boolean(button), + }; +})()`); + +await command("Emulation.setDeviceMetricsOverride", { + width: 390, + height: 844, + deviceScaleFactor: 1, + mobile: true, +}); +await navigate("/systems/inference/"); +const mobile = await evaluate(`(() => { + const root = document.querySelector("[data-inference-lab]"); + root.scrollIntoView({ block: "start", behavior: "instant" }); + const toggle = document.querySelector("#menu-toggle"); + toggle?.click(); + return { + documentOverflow: document.documentElement.scrollWidth - document.documentElement.clientWidth, + menuVisible: getComputedStyle(toggle).display !== "none", + menuOpen: toggle.getAttribute("aria-expanded"), + mobileLinks: document.querySelectorAll("#mobile-nav a").length, + tabs: root.querySelectorAll("[data-is-tab]").length, + offenders: [...document.querySelectorAll("body *")] + .filter((node) => !node.closest(".chunk-schedule, .formula, .paper-chain, .scheduler-board")) + .filter((node) => node.getBoundingClientRect().right > document.documentElement.clientWidth + 1) + .slice(0, 12) + .map((node) => ({ + tag: node.tagName, + className: typeof node.className === "string" ? node.className : "", + right: Math.round(node.getBoundingClientRect().right), + width: Math.round(node.getBoundingClientRect().width), + })), + }; +})()`); +await pause(180); +await screenshot("/tmp/llm-atlas-inference-mobile.png"); + +const report = { overview, memory, phase, speculative, fleet, home, papers, mobile, exceptions }; +console.log(JSON.stringify(report, null, 2)); + +const numeric = (value) => Number.parseFloat(value.replaceAll(",", "")); +const failures = []; +if (!overview.title.includes("千万人用得起")) failures.push("章节标题异常"); +if (overview.sections !== 31 || overview.tocLinks !== 31) failures.push("章节/目录数量异常"); +if (overview.paperLinks !== 62) failures.push("正式论文链不是 62 个节点"); +if (overview.ledgers !== 18) failures.push("十八本服务账结构异常"); +if (overview.labTabs !== 4 || overview.labPanels !== 4) failures.push("四联实验结构异常"); +if (overview.navLinks !== 18 || home.navLinks !== 18 || mobile.mobileLinks !== 18) failures.push("全站导航未同步推理服务专题"); +if (overview.documentOverflow > 1 || mobile.documentOverflow > 1) failures.push("桌面或移动端存在横向溢出"); +if (!memory.initial.weight.includes("32.6") || !memory.initial.perToken.includes("128") || memory.initial.visible !== "memory") failures.push("GQA 默认显存账异常"); +if (!memory.exploded.status.includes("OOM") || !memory.exploded.fit.includes("over")) failures.push("极端 MHA 配置没有触发 OOM"); +if (!memory.k3.note.includes("69") || !memory.k3.note.includes("24") || !memory.k3.note.includes("未伪造")) failures.push("K3 混合状态证据边界异常"); +if (numeric(phase.chunked.stall) >= numeric(phase.staticBatch.stall) || numeric(phase.chunked.tpot) >= numeric(phase.staticBatch.tpot)) failures.push("Chunked prefill 没有降低教学 stall / TPOT"); +if (!phase.slowPd.bottleneck.includes("慢网络") || !phase.slowPd.bottleneck.includes("KV")) failures.push("慢网络没有暴露 P/D 状态传输瓶颈"); +if (numeric(speculative.k3.speedup) <= 1 || speculative.k3.tokens !== 8 || !speculative.k3.evidence.includes("7 步")) failures.push("K3 7-step 推测预设异常"); +if (speculative.lowAcceptance.status !== "NO GAIN" || numeric(speculative.lowAcceptance.speedup) >= 1) failures.push("低验收率没有触发负加速"); +if (!fleet.k3.avoided.includes("320K") || fleet.k3.shortSlo !== "PROTECTED") failures.push("K3 coding trace 缓存 / 准入预设异常"); +if (!fleet.failed.state.includes("SECONDARY RE-PREFILL") || !fleet.failed.recompute.includes("FAILED PRIMARY")) failures.push("缓存故障没有触发原子失效后的重算"); +if (fleet.bursty.shortSlo !== "VIOLATED") failures.push("平均并发阈值没有暴露长请求突发"); +if (fleet.keyboardSelected !== "phase" || fleet.keyboardVisible !== "phase") failures.push("实验键盘 tab 导航异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") failures.push("首页推理服务首发入口异常"); +if (home.paperCount !== "400" || papers.total !== 400 || !papers.hasFilter || papers.visible !== 45) failures.push("论文库推理服务标签或总数异常"); +if (!mobile.menuVisible || mobile.menuOpen !== "true" || mobile.tabs !== 4) failures.push("移动端导航或实验异常"); +if (mobile.offenders.length) failures.push(`移动端越界元素：${JSON.stringify(mobile.offenders)}`); +if (exceptions.length) failures.push(`浏览器异常：${exceptions.join(" | ")}`); + +if (failures.length) { + console.error(`\nFAIL\n- ${failures.join("\n- ")}`); + process.exitCode = 1; +} else { + console.log("\nPASS inference serving browser regression"); +} + +socket.close(); diff --git a/scripts/check-moe-browser.mjs b/scripts/check-moe-browser.mjs index 29da270..3a61d35 100644 --- a/scripts/check-moe-browser.mjs +++ b/scripts/check-moe-browser.mjs @@ -177,7 +177,7 @@ if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentO } if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible) failures.push("移动端菜单按钮未显示"); -if (home.releaseCards !== 12) failures.push(`首页新章卡数量异常：${home.releaseCards}`); +if (home.releaseCards !== 13) failures.push(`首页新章卡数量异常：${home.releaseCards}`); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-multimodal-browser.mjs b/scripts/check-multimodal-browser.mjs index dec92e4..3265e40 100644 --- a/scripts/check-multimodal-browser.mjs +++ b/scripts/check-multimodal-browser.mjs @@ -234,7 +234,7 @@ if (!overview.title.includes("第一类输入")) failures.push("章节标题异 if (overview.sections !== 30 || overview.tocLinks !== 30) failures.push("章节/目录数量异常"); if (overview.paperLinks !== 55) failures.push("正式论文链不是 55 个节点"); if (overview.labTabs !== 4 || overview.labPanels !== 4) failures.push("四联实验结构异常"); -if (overview.navLinks !== 17 || home.navLinks !== 17 || mobile.mobileLinks !== 17) failures.push("全站导航未同步多模态专题"); +if (overview.navLinks !== 18 || home.navLinks !== 18 || mobile.mobileLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (overview.documentOverflow > 1 || mobile.documentOverflow > 1) failures.push("桌面或移动端存在横向溢出"); if (numeric(tokens.initial.patches) !== 5476 || numeric(tokens.initial.visual) !== 1369 || tokens.initial.visiblePanel !== "tokens") failures.push("视觉 Token 初始计算异常"); if (!tokens.overloaded.status.includes("超预算") || numeric(tokens.overloaded.share) <= 100) failures.push("超大视频没有触发上下文超预算"); @@ -246,8 +246,8 @@ if (ocr.unreported.status !== "OUT OF EVIDENCE" || ocr.unreported.accuracy !== " if (loop.toolsStart.state !== "OPEN" || loop.toolsEnd.state !== "VERIFIED" || loop.toolsEnd.evidence !== "97%" || loop.toolsEnd.tools !== "3") failures.push("vision-in-the-loop 终局异常"); if (loop.cotEnd.state !== "FAILED" || !loop.cotEnd.takeaway.includes("不能凭空增加")) failures.push("文字 CoT 与新观察没有分开"); if (loop.keyboardSelected !== "connector" || loop.keyboardVisible !== "connector") failures.push("实验键盘 tab 导航异常"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") failures.push("首页多模态首发入口异常"); -if (home.paperCount !== "355" || papers.total !== 355 || !papers.hasFilter || papers.multimodalVisible < 59) failures.push("论文库多模态标签或总数异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") failures.push("首页推理服务首发入口异常"); +if (home.paperCount !== "400" || papers.total !== 400 || !papers.hasFilter || papers.multimodalVisible < 59) failures.push("论文库多模态标签或总数异常"); if (!mobile.menuVisible || mobile.menuOpen !== "true" || mobile.tabs !== 4) failures.push("移动端导航或实验异常"); if (mobile.offenders.length) failures.push(`移动端越界元素：${JSON.stringify(mobile.offenders)}`); if (exceptions.length) failures.push(`浏览器异常：${exceptions.join(" | ")}`); diff --git a/scripts/check-numerics-browser.mjs b/scripts/check-numerics-browser.mjs index 4e9a06c..ec13360 100644 --- a/scripts/check-numerics-browser.mjs +++ b/scripts/check-numerics-browser.mjs @@ -273,15 +273,15 @@ if (stability.keyboard.selected !== "stability" || stability.keyboard.visible != if (layout.articleSections !== 19 || layout.paperLinks !== 36 || layout.labTabs !== 4 || layout.views !== 4) { failures.push("章节、论文或实验数量异常"); } -if (layout.navLinks !== 17 || mobile.mobileLinks !== 17 || home.navLinks !== 17) failures.push("全站导航未同步数值专题"); +if (layout.navLinks !== 18 || mobile.mobileLinks !== 18 || home.navLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentOverflow > 0) failures.push("页面存在横向溢出"); if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible || mobile.menuOpen !== "true") failures.push("移动端菜单不可用"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") { +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") { failures.push("首页 Transformer 新章入口异常"); } -if (home.paperCount !== "355") failures.push(`首页论文总数异常：${home.paperCount}`); -if (!papers.hasOptimizerFilter || papers.total !== 355 || papers.visible < 8) failures.push("论文库优化器标签或论文总数异常"); +if (home.paperCount !== "400") failures.push(`首页论文总数异常：${home.paperCount}`); +if (!papers.hasOptimizerFilter || papers.total !== 400 || papers.visible < 8) failures.push("论文库优化器标签或论文总数异常"); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-reasoning-browser.mjs b/scripts/check-reasoning-browser.mjs index 7331f25..f91e84e 100644 --- a/scripts/check-reasoning-browser.mjs +++ b/scripts/check-reasoning-browser.mjs @@ -289,7 +289,7 @@ if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentO } if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible || mobile.menuOpen !== "true") failures.push("移动端菜单不可用"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态")) failures.push("首页 Transformer 新章入口异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化")) failures.push("首页推理服务新章入口异常"); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-scaling-browser.mjs b/scripts/check-scaling-browser.mjs index 7e39e5f..b89530c 100644 --- a/scripts/check-scaling-browser.mjs +++ b/scripts/check-scaling-browser.mjs @@ -269,14 +269,14 @@ if (emergence.paths.some((length) => length < 500)) failures.push("涌现多指 if (layout.articleSections !== 16 || layout.paperLinks !== 29 || layout.labTabs !== 4 || layout.views !== 4) { failures.push("章节、论文或实验数量异常"); } -if (layout.navLinks !== 17 || mobile.mobileLinks !== 17 || home.navLinks !== 17) failures.push("全站导航未同步数值专题"); +if (layout.navLinks !== 18 || mobile.mobileLinks !== 18 || home.navLinks !== 18) failures.push("全站导航未同步推理服务专题"); if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentOverflow > 0) failures.push("页面存在横向溢出"); if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible || mobile.menuOpen !== "true") failures.push("移动端菜单不可用"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") { +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") { failures.push("首页 Transformer 新章入口异常"); } -if (home.paperCount !== "355") failures.push(`首页论文总数异常：${home.paperCount}`); +if (home.paperCount !== "400") failures.push(`首页论文总数异常：${home.paperCount}`); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-training-systems-browser.mjs b/scripts/check-training-systems-browser.mjs index 8e0352c..88f45c3 100644 --- a/scripts/check-training-systems-browser.mjs +++ b/scripts/check-training-systems-browser.mjs @@ -233,7 +233,7 @@ if (layout.articleSections !== 16 || layout.paperLinks !== 37 || layout.labTabs if (layout.documentOverflow > 0 || mobile.documentOverflow > 0 || home.documentOverflow > 0) failures.push("页面存在横向溢出"); if (layout.navGap < 0) failures.push(`桌面导航碰撞：${layout.navGap}px`); if (!mobile.menuVisible || mobile.menuOpen !== "true") failures.push("移动端菜单不可用"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态")) failures.push("首页 Transformer 新章入口异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化")) failures.push("首页推理服务新章入口异常"); if (exceptions.length) failures.push(`浏览器脚本异常：${exceptions.join("; ")}`); socket.close(); diff --git a/scripts/check-transformer-browser.mjs b/scripts/check-transformer-browser.mjs index 2e64065..913b46c 100644 --- a/scripts/check-transformer-browser.mjs +++ b/scripts/check-transformer-browser.mjs @@ -172,7 +172,7 @@ const home = await evaluate(`(() => ({ releaseCards: document.querySelectorAll(".release-card").length, firstRelease: document.querySelector(".release-card h2").textContent, firstHref: document.querySelector(".release-card").getAttribute("href"), - paperCount: [...document.querySelectorAll(".hero-stats b")].map((node) => node.textContent.trim()).find((value) => value === "355"), + paperCount: [...document.querySelectorAll(".hero-stats b")].map((node) => node.textContent.trim()).find((value) => value === "400"), }))()`); await navigate("/papers/"); @@ -236,8 +236,8 @@ if (block.family.trim() !== "Hybrid MoE" || !block.kv.includes("3 KDA : 1 Gated if (!block.path.some((step) => step.includes("KDA × 3")) || !block.note.includes("AttnRes")) failures.push("K3 Block 路径异常"); if (block.context.trim() !== "128K" || numeric(block.mha) !== 400 || numeric(block.kda) !== 1) failures.push("KV 成本缩放异常"); if (block.keyboardSelected !== "block" || block.keyboardVisible !== "block") failures.push("实验 tab 键盘导航异常"); -if (home.releaseCards !== 12 || !home.firstRelease.includes("原生多模态") || home.firstHref !== "/multimodal/") failures.push("首页 Transformer 首发入口异常"); -if (home.paperCount !== "355" || papers.total !== 355 || papers.transformerVisible < 30) failures.push("论文库或首页论文数量异常"); +if (home.releaseCards !== 13 || !home.firstRelease.includes("推理优化") || home.firstHref !== "/systems/inference/") failures.push("首页推理服务首发入口异常"); +if (home.paperCount !== "400" || papers.total !== 400 || papers.transformerVisible < 30) failures.push("论文库或首页论文数量异常"); if (!mobile.menuVisible || mobile.menuOpen !== "true" || mobile.tabs !== 4) failures.push("移动端导航或实验异常"); if (exceptions.length) failures.push(`浏览器异常：${exceptions.join(" | ")}`); diff --git a/src/components/InferenceServingLab.astro b/src/components/InferenceServingLab.astro new file mode 100644 index 0000000..90378d6 --- /dev/null +++ b/src/components/InferenceServingLab.astro @@ -0,0 +1,998 @@ +--- +const memoryPresets = [ + { + id: "mha", + name: "MHA", + subtitle: "每个 Q 头保存一组 K/V", + params: 70, + weightBits: 16, + layers: 80, + kvHeads: 64, + headDim: 128, + kvBits: 16, + note: "标准 MHA 教学配置：KV 随 batch、序列长度和层数线性增长。", + }, + { + id: "gqa", + name: "GQA", + subtitle: "多个 Q 头共享 K/V", + params: 70, + weightBits: 4, + layers: 32, + kvHeads: 8, + headDim: 128, + kvBits: 16, + note: "默认教学配置，不对应某个具体 checkpoint；用于观察减少 KV heads 的直接收益。", + }, + { + id: "mla", + name: "MLA", + subtitle: "缓存低维 latent", + params: 236, + weightBits: 8, + layers: 60, + kvHeads: 1, + headDim: 576, + kvBits: 16, + note: "把 MLA 的压缩 latent 写成“等效 1 个 576 维 KV 头”只为量纲教学，不是复刻 DeepSeek-V2 权重布局。", + }, + { + id: "k3", + name: "K3 HYBRID", + subtitle: "69 KDA + 24 MLA", + params: 1000, + weightBits: 4, + layers: 24, + kvHeads: 1, + headDim: 512, + kvBits: 8, + note: "K3 报告公开了 69 个 KDA 与 24 个 Gated MLA 层；这里仅估算会随上下文增长的 MLA latent，KDA 固定状态未伪造为精确字节。", + }, +]; + +const phaseStrategies = [ + ["static", "静态批处理", "等最长请求"], + ["continuous", "连续批处理", "完成即补位"], + ["chunked", "Chunked prefill", "切片交错 decode"], + ["pd", "P/D 解耦", "分开扩容与调度"], +]; + +const speculativePresets = [ + ["vanilla", "独立小模型", 5, 0.62, 0.12, 1.08], + ["medusa", "Medusa heads", 5, 0.72, 0.05, 1.14], + ["eagle3", "EAGLE-3", 6, 0.79, 0.07, 1.13], + ["k3", "K3 / 7-step", 7, 0.82, 0.08, 1.15], +]; +--- + +
+
+
+

INTERACTIVE / SERVING CONTROL ROOM

+

别只背系统名：亲手管四本推理账

+
+

+ 每个实验都公开公式、假设与证据边界。它们是可复算的教学模型，不是 GPU + benchmark，也不会把论文中的特定集群结果外推成普遍性能。 +

+
+ +
+ + + + +
+ +
+
+
LEDGER 01 / MEMORY

80 GB 到底装了什么？

+

先付权重，再付随请求增长的状态；分页只能减少浪费，不能让真实 KV 消失。

+
+ +
+ {memoryPresets.map((preset, index) => ( + + ))} +
+ +
+ + + + + + + + + + +
+ +
+ EXACT FOR MHA / MQA / GQA + KVBytes = B × T × L × 2 × Hkv × Dh × bytes +

“2”来自 K 与 V。MLA / KDA 的状态结构不同，必须另立口径，不能只改一个名字。

+
+ +
+
+ WEIGHTS32.60 GiB

未计 scale、元数据与 runtime workspace

+
+
+ KV / TOKEN128.00 KiB

单请求每新增一个位置

+
+
+ ONE REQUEST4.00 GiB

指定上下文长度的增长状态

+
+
+ ACTIVE SET64.60 GiB

权重 + 全部活动请求 KV

+
+
+ FIT / ONE GPU15.40 GiB left

能装下，但还没给 kernel workspace 留余量

+
+
+ +
+
+ PAGE TAIL WASTE + 0 B +

这里只有最后一个 block 的内部浪费；PagedAttention 还会改善非连续分配与共享。

+
+
+ EVIDENCE BOUNDARY + 默认 GQA 是量纲教学配置 +

选 K3 会切换为“增长状态等效估算”，同时保留固定 KDA 状态未公开的边界。

+
+
+
+ + + + + + + +
+ HOW TO READ + 先让实验失败，再寻找是哪一本账失衡。显存、延迟、算力、网络和 SLO + 不能互相替代，也不能用单一“tokens/s”概括。 +
+
+ + + + diff --git a/src/components/SiteHeader.astro b/src/components/SiteHeader.astro index 584e0b0..2097569 100644 --- a/src/components/SiteHeader.astro +++ b/src/components/SiteHeader.astro @@ -19,6 +19,7 @@ const items = [ { id: "agents", href: "/agents/", label: "Agent" }, { id: "multimodal", href: "/multimodal/", label: "多模态" }, { id: "training-systems", href: "/training-systems/", label: "训练系统" }, + { id: "systems-inference", href: "/systems/inference/", label: "推理服务" }, { id: "numerics", href: "/systems/numerics/", label: "数值" }, { id: "papers", href: "/papers/", label: "论文库" }, { id: "progress", href: "/progress/", label: "进度" }, diff --git a/src/data/chapters.ts b/src/data/chapters.ts index 276d504..2e855f9 100644 --- a/src/data/chapters.ts +++ b/src/data/chapters.ts @@ -203,12 +203,12 @@ export const chapters: Chapter[] = [ title: "推理服务与低成本部署", kicker: "INFERENCE", question: "模型训练完以后，怎样让千万人用得起？", - summary: "拆解 KV Cache、PagedAttention、批处理、推测解码、PD 解耦、前缀缓存与集群调度。", - status: "queued", - progress: 12, - papers: 20, + summary: "用十八本账拆开显存、KV Cache、PagedAttention、连续批处理、P/D 解耦、量化、推测解码与集群调度，并重点追踪 DeepSeek V2→V4 与 Mooncake→K3。", + status: "published", + progress: 78, + papers: 62, prerequisites: ["07", "08", "09"], - highlights: ["vLLM", "Mooncake", "KDA 缓存"], + highlights: ["十八本服务账", "DeepSeek / Kimi 谱系", "四联实验"], }, { number: "15", diff --git a/src/data/papers.ts b/src/data/papers.ts index 4732d0b..2ec32af 100644 --- a/src/data/papers.ts +++ b/src/data/papers.ts @@ -12,6 +12,7 @@ export type PaperTopic = | "推理" | "Agent" | "多模态" + | "推理服务" | "评测"; export interface Paper { @@ -2891,6 +2892,368 @@ export const papers: Paper[] = [ spotlight: "Kimi", verified: true, }, + { + year: 2020, + title: "Clockwork: Predictable and Efficient Deep Learning Inference", + url: "https://www.usenix.org/conference/osdi20/presentation/gujarati", + topics: ["推理服务", "训练系统"], + contribution: "用可预测执行、集中式调度和显式模型缓存控制 DNN 服务尾延迟。", + verified: true, + }, + { + year: 2022, + title: "ZeRO-Inference: Democratizing Massive Model Inference", + url: "https://arxiv.org/abs/2207.00032", + topics: ["推理服务", "训练系统", "低精度"], + contribution: "把巨量权重卸载到 CPU / NVMe，并通过分层预取和并行减少 GPU 容量门槛。", + verified: true, + }, + { + year: 2022, + title: "Orca: A Distributed Serving System for Transformer-Based Generative Models", + url: "https://www.usenix.org/conference/osdi22/presentation/yu", + topics: ["推理服务", "训练系统"], + contribution: "以 iteration-level scheduling 和 selective batching 奠定连续批处理主线。", + verified: true, + }, + { + year: 2022, + title: "Petals: Collaborative Inference and Fine-tuning of Large Models", + url: "https://arxiv.org/abs/2209.01188", + topics: ["推理服务", "训练系统"], + contribution: "让参与者跨互联网协作托管模型层，暴露异构、不可靠网络下的服务边界。", + verified: true, + }, + { + year: 2022, + title: "Fast Inference from Transformers via Speculative Decoding", + url: "https://arxiv.org/abs/2211.17192", + topics: ["推理服务", "推理"], + contribution: "用便宜 draft model 提议多个 Token，再由目标模型并行验收且保持目标分布。", + verified: true, + }, + { + year: 2023, + title: "Accelerating Large Language Model Decoding with Speculative Sampling", + url: "https://arxiv.org/abs/2302.01318", + topics: ["推理服务", "推理"], + contribution: "独立建立保分布的推测采样算法，减少昂贵模型的串行调用轮数。", + verified: true, + }, + { + year: 2023, + title: "FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU", + url: "https://arxiv.org/abs/2303.06865", + topics: ["推理服务", "训练系统", "低精度"], + contribution: "联合 GPU、CPU 与磁盘 offload，并以搜索策略优化吞吐导向的单卡大模型推理。", + verified: true, + }, + { + year: 2023, + title: "AlpaServe: Statistical Multiplexing with Model Parallelism for Deep Learning Serving", + url: "https://arxiv.org/abs/2302.11665", + topics: ["推理服务", "训练系统"], + contribution: "把统计复用、模型并行和模型放置结合，用于突发式大模型工作负载。", + verified: true, + }, + { + year: 2023, + title: "FastServe: Fast Distributed Inference Serving for Large Language Models", + url: "https://arxiv.org/abs/2305.05920", + topics: ["推理服务", "训练系统"], + contribution: "借鉴多级反馈队列和抢占，降低自回归请求的 head-of-line blocking 与尾延迟。", + verified: true, + }, + { + year: 2023, + title: "SpecInfer: Accelerating Generative Large Language Model Serving with Tree-based Speculative Inference and Verification", + url: "https://arxiv.org/abs/2305.09781", + topics: ["推理服务", "推理"], + contribution: "用树状候选和并行验证扩展推测解码，使一次目标调用覆盖多条草稿分支。", + verified: true, + }, + { + year: 2023, + title: "Efficient Memory Management for Large Language Model Serving with PagedAttention", + url: "https://arxiv.org/abs/2309.06180", + topics: ["推理服务", "长上下文", "训练系统"], + contribution: "vLLM 把 KV Cache 分页，支持非连续分配、共享与 copy-on-write。", + verified: true, + }, + { + year: 2023, + title: "CacheGen: KV Cache Compression and Streaming for Fast Large Language Model Serving", + url: "https://arxiv.org/abs/2310.07240", + topics: ["推理服务", "长上下文", "低精度"], + contribution: "压缩并流式传输 KV Cache，以降低远端上下文加载延迟。", + verified: true, + }, + { + year: 2023, + title: "SGLang: Efficient Execution of Structured Language Model Programs", + url: "https://arxiv.org/abs/2312.07104", + topics: ["推理服务", "Agent", "长上下文"], + contribution: "用 RadixAttention 自动复用共享前缀，并为结构化生成提供语言与运行时。", + verified: true, + }, + { + year: 2023, + title: "Splitwise: Efficient Generative LLM Inference Using Phase Splitting", + url: "https://arxiv.org/abs/2311.18677", + topics: ["推理服务", "训练系统"], + contribution: "将 prompt processing 与 token generation 拆到适配的硬件池并独立调度。", + verified: true, + }, + { + year: 2023, + title: "Prompt Cache: Modular Attention Reuse for Low-Latency Inference", + url: "https://arxiv.org/abs/2311.04934", + topics: ["推理服务", "长上下文"], + contribution: "用模块化 prompt schema 标注可复用片段并缓存中间注意力状态。", + verified: true, + }, + { + year: 2024, + title: "DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving", + url: "https://arxiv.org/abs/2401.09670", + topics: ["推理服务", "训练系统"], + contribution: "以满足 TTFT / TPOT SLO 的 goodput 为目标，分离并独立扩容 prefill 与 decode。", + verified: true, + }, + { + year: 2024, + title: "Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads", + url: "https://arxiv.org/abs/2401.10774", + topics: ["推理服务", "推理"], + contribution: "在目标模型上增加多个 decoding heads，构造树状候选并减少独立 draft 成本。", + verified: true, + }, + { + year: 2024, + title: "EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty", + url: "https://arxiv.org/abs/2401.15077", + topics: ["推理服务", "推理"], + contribution: "在 feature 层自回归预测并结合已知 Token，提升草稿准确率与推测解码速度。", + verified: true, + }, + { + year: 2024, + title: "KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization", + url: "https://arxiv.org/abs/2401.18079", + topics: ["推理服务", "低精度", "长上下文"], + contribution: "按通道量化 key、按 token 量化 value，并分离 outlier 以压缩长上下文 KV。", + verified: true, + }, + { + year: 2024, + title: "KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache", + url: "https://arxiv.org/abs/2402.02750", + topics: ["推理服务", "低精度", "长上下文"], + contribution: "利用 key / value 不同分布采用非对称 2-bit 量化，并保留近期高精度 residual。", + verified: true, + }, + { + year: 2024, + title: "Hydragen: High-Throughput LLM Inference with Shared Prefixes", + url: "https://arxiv.org/abs/2402.05099", + topics: ["推理服务", "长上下文"], + contribution: "将共享前缀与独有后缀注意力拆开，跨请求批量复用前缀计算。", + verified: true, + }, + { + year: 2024, + title: "ChunkAttention: Efficient Self-Attention with Prefix-Aware KV Cache and Two-Phase Partition", + url: "https://arxiv.org/abs/2402.15220", + topics: ["推理服务", "长上下文"], + contribution: "以前缀树组织共享 KV chunks，并用两阶段分区提高内存与计算复用。", + verified: true, + }, + { + year: 2024, + title: "Sarathi-Serve: Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve", + url: "https://arxiv.org/abs/2403.02310", + topics: ["推理服务", "训练系统"], + contribution: "用 chunked prefill 与 stall-free scheduling 缓和长 prefill 对 decode 的干扰。", + verified: true, + }, + { + year: 2024, + title: "QServe: W4A8KV4 Quantization and System Co-design for Efficient LLM Serving", + url: "https://arxiv.org/abs/2405.04532", + topics: ["推理服务", "低精度"], + contribution: "联合 W4A8KV4、数据布局和硬件友好 kernel 优化端到端服务。", + verified: true, + }, + { + year: 2024, + title: "CacheBlend: Fast Large Language Model Serving for RAG with Cached Knowledge Fusion", + url: "https://arxiv.org/abs/2405.16444", + topics: ["推理服务", "长上下文"], + contribution: "融合独立缓存的文本块，并选择性重算跨块依赖以接近完整 prefill。", + verified: true, + }, + { + year: 2024, + title: "Llumnix: Dynamic Scheduling for Large Language Model Serving", + url: "https://arxiv.org/abs/2406.03243", + topics: ["推理服务", "训练系统"], + contribution: "用跨实例实时迁移重平衡请求、处理碎片并支持主动容错。", + verified: true, + }, + { + year: 2024, + title: "MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool", + url: "https://arxiv.org/abs/2406.17565", + topics: ["推理服务", "长上下文", "训练系统"], + contribution: "把独立 KV 缓存池连接到弹性 prefill / decode 服务，形成存算分离架构。", + verified: true, + }, + { + year: 2024, + title: "Preble: Efficient Distributed Prompt Scheduling for LLM Serving", + url: "https://arxiv.org/abs/2407.00023", + topics: ["推理服务", "长上下文", "训练系统"], + contribution: "在分布式 prompt 服务中联合前缀复用、实例负载与路由决策。", + verified: true, + }, + { + year: 2024, + title: "FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision", + url: "https://arxiv.org/abs/2407.08608", + topics: ["推理服务", "低精度", "长上下文"], + contribution: "面向 Hopper 用异步、warp specialization 与低精度流水进一步优化精确注意力。", + verified: true, + }, + { + year: 2024, + title: "EAGLE-2: Faster Inference of Language Models with Dynamic Draft Trees", + url: "https://arxiv.org/abs/2406.16858", + topics: ["推理服务", "推理"], + contribution: "根据上下文置信度动态调整草稿树，而不是固定候选拓扑。", + verified: true, + }, + { + year: 2025, + title: "FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving", + url: "https://arxiv.org/abs/2501.01005", + topics: ["推理服务", "长上下文"], + contribution: "提供面向多种 KV 布局、batch 形状与生成阶段的可组合 attention / sampling kernel。", + verified: true, + }, + { + year: 2025, + title: "EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test", + url: "https://arxiv.org/abs/2503.01840", + topics: ["推理服务", "推理"], + contribution: "直接预测 Token，并融合低、中、高层特征构造更强的推测草稿。", + verified: true, + }, + { + year: 2025, + title: "DeepGEMM", + url: "https://github.com/deepseek-ai/DeepGEMM", + topics: ["推理服务", "低精度", "训练系统"], + contribution: "DeepSeek 官方开源 FP8 与低精度 GEMM kernel 库，覆盖 dense 与 MoE 形状。", + spotlight: "DeepSeek", + verified: true, + }, + { + year: 2025, + title: "FlashMLA", + url: "https://github.com/deepseek-ai/FlashMLA", + topics: ["推理服务", "长上下文", "训练系统"], + contribution: "DeepSeek 官方面向 Multi-head Latent Attention prefill / decode 的高效 kernel。", + spotlight: "DeepSeek", + verified: true, + }, + { + year: 2023, + title: "REST: Retrieval-Based Speculative Decoding", + url: "https://arxiv.org/abs/2311.08252", + topics: ["推理服务", "推理"], + contribution: "从历史语料检索连续 Token 构造免训练草稿，再由目标模型并行验证。", + verified: true, + }, + { + year: 2024, + title: "Lookahead Decoding: Parallel Decoding without a Draft Model or Data Store", + url: "https://arxiv.org/abs/2402.02057", + topics: ["推理服务", "推理"], + contribution: "用 Jacobi 迭代并行发现并验证 n-gram，无需独立草稿模型。", + verified: true, + }, + { + year: 2024, + title: "LayerSkip: Enabling Early Exit Inference and Self-Speculative Decoding", + url: "https://arxiv.org/abs/2404.16710", + topics: ["推理服务", "推理"], + contribution: "训练早退层作为同一模型的草稿，再由剩余层验证，形成自推测解码。", + verified: true, + }, + { + year: 2023, + title: "H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models", + url: "https://arxiv.org/abs/2306.14048", + topics: ["推理服务", "长上下文"], + contribution: "识别并保留 attention heavy hitters，在有限预算下淘汰其余 KV。", + verified: true, + }, + { + year: 2023, + title: "StreamingLLM: Efficient Streaming Language Models with Attention Sinks", + url: "https://arxiv.org/abs/2309.17453", + topics: ["推理服务", "长上下文"], + contribution: "保留初始 attention sinks 与近期窗口，使有限缓存支持持续流式文本。", + verified: true, + }, + { + year: 2024, + title: "SnapKV: LLM Knows What You are Looking for Before Generation", + url: "https://arxiv.org/abs/2404.14469", + topics: ["推理服务", "长上下文"], + contribution: "用 prompt 末端 observation window 选择各头重要位置，压缩长 prompt KV。", + verified: true, + }, + { + year: 2024, + title: "PyramidKV: Dynamic KV Cache Compression based on Pyramidal Information Funneling", + url: "https://arxiv.org/abs/2406.02069", + topics: ["推理服务", "长上下文"], + contribution: "依据层间信息聚合现象，为不同层分配递减的 KV 容量预算。", + verified: true, + }, + { + year: 2024, + title: "InfiniGen: Efficient Generative Inference of Large Language Models with Dynamic KV Cache Management", + url: "https://arxiv.org/abs/2406.19707", + topics: ["推理服务", "长上下文"], + contribution: "提前预测关键 KV，并从 CPU 内存选择性加载以减少 GPU 状态容量。", + verified: true, + }, + { + year: 2024, + title: "Quest: Query-Aware Sparsity for Efficient Long-Context LLM Inference", + url: "https://arxiv.org/abs/2406.10774", + topics: ["推理服务", "长上下文"], + contribution: "利用 page 级统计按 query 选择相关 KV pages，减少长上下文 decode 读取。", + verified: true, + }, + { + year: 2024, + title: "BurstGPT: A Real-world Workload Dataset to Optimize LLM Serving Systems", + url: "https://arxiv.org/abs/2401.17644", + topics: ["推理服务", "训练系统", "评测"], + contribution: "公开真实服务 trace，揭示突发、长度和模型混合对容量规划的影响。", + verified: true, + }, + { + year: 2023, + title: "TensorRT-LLM", + url: "https://github.com/NVIDIA/TensorRT-LLM", + topics: ["推理服务", "低精度", "训练系统"], + contribution: "NVIDIA 官方 LLM 推理运行时，整合低精度 kernel、并行、KV Cache 与动态批处理。", + verified: true, + }, ]; export const paperTopics: PaperTopic[] = [ @@ -2907,5 +3270,6 @@ export const paperTopics: PaperTopic[] = [ "推理", "Agent", "多模态", + "推理服务", "评测", ]; diff --git a/src/pages/index.astro b/src/pages/index.astro index 3711427..76ad026 100644 --- a/src/pages/index.astro +++ b/src/pages/index.astro @@ -17,6 +17,7 @@ const routes: Record = { agents: "/agents/", multimodal: "/multimodal/", "training-systems": "/training-systems/", + "systems/inference": "/systems/inference/", "systems/numerics": "/systems/numerics/", }; @@ -96,6 +97,7 @@ const paths = [ Agent 专题 原生多模态专题 训练系统专题 + 推理服务专题 数值与优化专题 @@ -106,7 +108,7 @@ const paths = [
16核心专题
151K3 报告来源
-
355关键论文索引
+
400关键论文索引
47pK3 技术报告
@@ -120,6 +122,22 @@ const paths = [
+ +
+

NEW / CHAPTER 14 MEMORY · TIME · FLEET

+

推理优化不是一句“更快”：显存、首字、字间、网络与 SLO 是五本不同的账

+

+ 用十八本账从 KV Cache、PagedAttention、连续批处理、chunked prefill、量化和推测解码， + 走到 DeepSeek V2→V4 的异构状态谱系，以及 Mooncake→Kimi K3 的混合缓存、亲和路由与预算准入。 +

+
+
+
LINEAGE
2019 → 2026
+
NODES
62 个一手节点
+
LAB
显存 · P/D · 推测 · 集群
+
+ +

NEW / CHAPTER 13 PIXELS · TOKENS · NATIVE MULTIMODALITY

@@ -545,6 +563,7 @@ const paths = [ transition: transform 180ms ease, border-color 180ms ease; } + .inference-release, .agent-release, .alignment-release, .transformer-release, @@ -558,6 +577,14 @@ const paths = [ min-height: 510px; } + .inference-release { + background: + radial-gradient(circle at 82% 18%, rgba(35, 86, 84, 0.22), transparent 31%), + radial-gradient(circle at 60% 76%, rgba(159, 91, 52, 0.13), transparent 27%), + repeating-linear-gradient(90deg, transparent 0 66px, rgba(35, 86, 84, 0.045) 66px 67px), + var(--paper-raised); + } + .agent-release { background: radial-gradient(circle at 82% 18%, rgba(56, 91, 128, 0.2), transparent 30%), @@ -688,6 +715,7 @@ const paths = [ padding-bottom: 76px; } + .inference-release, .alignment-release, .transformer-release, .foundation-release, diff --git a/src/pages/progress/index.astro b/src/pages/progress/index.astro index 897113e..dd69e16 100644 --- a/src/pages/progress/index.astro +++ b/src/pages/progress/index.astro @@ -22,6 +22,7 @@ const workstreams = [ { label: "稀疏计算与 MoE", value: 74, next: "补充真实集群 traces 与专家特化案例" }, { label: "长上下文专题", value: 72, next: "加入更多论文逐图笔记与真实模型配置对比" }, { label: "大规模训练系统", value: 71, next: "补真实集群 traces、故障案例与精确 topology 配置" }, + { label: "推理服务与低成本部署", value: 78, next: "补真实 GPU kernel / workload traces、功耗与跨框架复现" }, { label: "数值精度、优化器与稳定性", value: 75, next: "加入真实 kernel 吞吐、长程训练 traces 与逐图论文精读" }, { label: "引用与事实检查", value: 57, next: "自动化外链复查与来源等级扩展" }, { label: "开源与部署", value: 100, next: "每轮保留不可变镜像、提交与回滚点" }, @@ -47,7 +48,7 @@ const workstreams = [
OVERALL
专题平均 {average}%
READABLE
{published} 个首版可读专题
ACTIVE
{researching} 个研究/写作中
-
UPDATED
2026-07-29 07:46 CST
+
UPDATED
2026-07-29 08:34 CST
MODE
持续迭代，不锁死版本
@@ -57,7 +58,7 @@ const workstreams = [

01 WORKSTREAMS

-

十八条工作流同时推进，但不混淆“有页面”和“已核验”

+

十九条工作流同时推进，但不混淆“有页面”和“已核验”

内容首版优先打通全局脉络；随后每轮迭代选择一个专题推进到论文/工程层，并做独立事实复核。 @@ -94,8 +95,8 @@ const workstreams = [

✓

K3 报告已结构化拆解

47 页报告目录、151 条参考来源和架构/后训练/系统主线已经提取。

✓

16 专题知识图

从语言模型基础到评测安全，包含先修依赖和三条贯穿案例。

✓

编辑式网站系统

响应式导航、章节模板、侧栏、进度、论文链和证据提示组件。

-
✓

四十三个原创交互视图

K3、语言模型前史、Transformer、DeepSeek、长上下文、MoE、推理、Agent、多模态，以及训练系统、Scaling、数据工程、数值和 Alignment 专题。

-
✓

十四篇首版长文

K3、语言模型前史、Transformer、DeepSeek、Scaling、数据工程、长上下文、MoE、后训练、推理、Agent、原生多模态、训练系统与数值优化专题。

+
✓

四十七个原创交互视图

K3、语言模型前史、Transformer、DeepSeek、长上下文、MoE、推理、Agent、多模态，以及训练系统、推理服务、Scaling、数据工程、数值和 Alignment 专题。

+
✓

十五篇首版长文

K3、语言模型前史、Transformer、DeepSeek、Scaling、数据工程、长上下文、MoE、后训练、推理、Agent、原生多模态、训练系统、推理服务与数值优化专题。

✓

语言模型前史深度专题

八张独立问题账、33 个正式节点、20 段长文与概率—向量—记忆—对齐四联实验。

✓

Transformer 深度专题

十张独立问题账、40 个正式节点、21 段正文与 QKV—Mask—多头位置—Block 成本四联实验。

✓

Scaling Laws 深度专题

九张账、29 个一手节点、DeepSeek/Kimi 双谱系与曲面—部署—复用—涌现四联实验。

@@ -108,7 +109,8 @@ const workstreams = [
✓

指令微调与人类偏好深度专题

十二张账、44 个一手节点、DeepSeek/Kimi 后训练双谱系，以及 SFT—RM—PPO/DPO—配方四联实验。

✓

工具使用与长程 Agent 深度专题

十四张账、52 个一手节点、DeepSeek/Kimi Agent 双谱系，以及循环—工具契约—可靠性—长程 RL 四联实验。

✓

原生多模态深度专题

十六张账、55 个一手节点、DeepSeek 三分支、Kimi 三代 MoonViT，以及 Token—连接器—光学压缩—视觉闭环四联实验。

-
✓

355 篇关键论文索引

新增 ResNet、ALIGN、NaViT、DeepSeek-VL2、Janus、DeepSeek-OCR、Vision-R1 等 41 个多模态节点。

+
✓

推理服务与低成本部署深度专题

十八本账、62 个一手节点、DeepSeek V2→V4 与 Mooncake→K3 双谱系，以及显存—阶段—推测—集群四联实验。

+
✓

400 篇关键论文索引

新增 vLLM、SGLang、DistServe、Sarathi、FlashInfer、EAGLE-3、DeepGEMM、FlashMLA 等 45 个推理服务节点。

✓

公开仓库与自托管发布

源码公开到 git.k1412.top，网站由不可变镜像、Compose Manager 与 HTTPS 交付。

@@ -135,6 +137,7 @@ const workstreams = [
P1Alignment 二轮深化

真实偏好分歧 → RM 长度偏置 → PPO/DPO 小模型复现

数据案例 + 可复现实验
P1Agent 二轮深化

真实环境 traces → cross-harness ablation → Agent RL 曲线与提示注入案例

运行证据 + 安全案例库
P1原生多模态二轮

真实视觉 Token traces → 跨分辨率 / connector 消融 → OCR 与视觉 Agent 安全失败案例

运行证据 + 逐图笔记
+
P1推理服务二轮

真实 GPU kernel / workload traces → 功耗与成本 → 跨 vLLM / SGLang / TensorRT-LLM 复现

可复现实测 + 成本账
@@ -189,6 +192,8 @@ const workstreams = [
原生多模态按五层管道与十六张账组织

像素、视觉塔、压缩 / connector、主干与输出 / 工具闭环分开定位；“原生”再拆成数据、目标、优化、输入输出与 Agent 五维。

DeepSeek 多模态永久保留三分支

VL/VL2 的理解、Janus 的统一生成、OCR 的光学压缩不画成错误的单向代际谱系。

光学压缩实验分开报告值、教学插值与证据外区域

DeepSeek-OCR 的 <10× / 20× 锚点标成作者报告；中间只做显式教学插值，超过范围不外推。

+
推理服务按十八本账组织

权重、增长状态、分配、阶段、batch、cache、kernel、推测、网络、路由、故障与经济性不再压成单一 tokens/s。

+
DeepSeek 与 Kimi 服务谱系按状态对象重建

MLA→V4 异构状态与 Mooncake→KDA→K3 混合缓存分开说明；作者报告、精确公式和教学估算使用不同标签。

diff --git a/src/pages/systems/inference/index.astro b/src/pages/systems/inference/index.astro new file mode 100644 index 0000000..1f2e5ad --- /dev/null +++ b/src/pages/systems/inference/index.astro @@ -0,0 +1,981 @@ +--- +import BaseLayout from "@/layouts/BaseLayout.astro"; +import InferenceServingLab from "@/components/InferenceServingLab.astro"; + +const toc = [ + ["00", "compass", "先拆成十八本账"], + ["01", "stack", "一条请求的全栈"], + ["02", "metrics", "延迟、吞吐与 Goodput"], + ["03", "clock", "请求时钟"], + ["04", "weights", "权重显存账"], + ["05", "kv", "KV Cache 数学"], + ["06", "states", "MHA / GQA / MLA / KDA"], + ["07", "paging", "PagedAttention"], + ["08", "prefill", "Prefill 阶段"], + ["09", "decode", "Decode 阶段"], + ["10", "batching", "连续批处理"], + ["11", "chunked", "Chunked prefill"], + ["12", "kernels", "Kernel 与算子"], + ["13", "prefix", "前缀缓存"], + ["14", "pd", "Prefill / Decode 解耦"], + ["15", "quant", "量化不是一种开关"], + ["16", "speculative", "推测解码"], + ["17", "parallel", "并行与放置"], + ["18", "moe", "MoE 推理"], + ["19", "slo", "调度、SLO 与 Goodput"], + ["20", "fleet", "集群与故障"], + ["21", "deepseek-map", "DeepSeek 服务谱系"], + ["22", "deepseek-v23", "V2 → V3"], + ["23", "deepseek-v4", "V3.2 → V4"], + ["24", "kimi-map", "Kimi 服务谱系"], + ["25", "mooncake", "Mooncake"], + ["26", "k3-cache", "K3 混合状态缓存"], + ["27", "k3-spec", "K3 推测与准入"], + ["28", "lab", "四联交互实验"], + ["29", "checklist", "审计一套推理系统"], + ["↳", "papers", "62 个关键节点"], +]; + +const ledgers = [ + ["Q1 / PRODUCT", "请求形状", "输入、输出、并发与复用到底长什么样？", "聊天、代码 Agent、离线批处理和 1M context 的最优系统不相同。"], + ["Q2 / SLO", "体验契约", "用户在等首字，还是在等完整答案？", "TTFT、TPOT、E2E、deadline 与可用性要分别记录。"], + ["Q3 / WEIGHT", "权重", "模型本体怎样装进设备？", "精度、分片、复制、offload、专家放置与 runtime workspace。"], + ["Q4 / STATE", "增长状态", "每多一个 Token，要多存什么？", "标准 KV、压缩 latent、线性注意力状态与混合缓存。"], + ["Q5 / ALLOC", "内存分配", "空间够，为什么仍会 OOM？", "连续块、内部碎片、生命周期、共享与 copy-on-write。"], + ["Q6 / PREFILL", "预填充", "长 prompt 怎样变成可复用状态？", "通常算力密集；长度、chunk、缓存命中与排队共同决定首字。"], + ["Q7 / DECODE", "逐步生成", "一个 Token 为什么也很贵？", "通常受权重与状态读带宽限制；batch 能摊权重，却增加竞争。"], + ["Q8 / BATCH", "批处理", "不同长度请求怎样同车？", "静态、连续、iteration-level 与 token-budget scheduling。"], + ["Q9 / CACHE", "复用", "哪些旧计算可以安全命中？", "前缀哈希、page 对齐、版本、租户隔离、淘汰与失效。"], + ["Q10 / KERNEL", "算子", "理论 FLOPs 为何不是实测延迟？", "IO、融合、shape、量化布局、通信与硬件利用率。"], + ["Q11 / SPEC", "推测", "能否用便宜猜测减少串行步数？", "验收率、draft 成本、并行验证与回滚必须同账。"], + ["Q12 / QUANT", "精度", "少几个 bit 省在哪里，又伤在哪里？", "权重、激活、KV 与通信不是同一个量化对象。"], + ["Q13 / PARALLEL", "并行", "一份请求跨多少设备？", "TP、PP、DP、EP、CP 的通信、冗余与尾延迟不同。"], + ["Q14 / MOE", "专家", "激活参数少，为何部署仍然难？", "所有权重仍需放置，路由造成 all-to-all、热点与小 batch GEMM。"], + ["Q15 / NETWORK", "网络", "拆开阶段后，要搬多少状态？", "P/D 解耦、远端缓存和专家通信把网络变成一等资源。"], + ["Q16 / ROUTE", "路由", "送到空闲实例，还是有缓存的实例？", "负载、缓存亲和、数据局部性与租户边界需要共同优化。"], + ["Q17 / FAILURE", "故障", "缓存或 worker 消失时，状态还可信吗？", "pin、复制、原子失效、重算、降级和幂等必须定义。"], + ["Q18 / ECON", "经济", "便宜究竟按什么分母？", "每 Token 成本之外还要看 SLO goodput、利用率、功耗与拒绝率。"], +]; + +const waves = [ + ["2019–20", "先把单请求变得可预测", "MQA · Clockwork", "减少增长状态；用可预测执行与集中调度替代黑盒式服务。"], + ["2022", "批处理进入 iteration 粒度", "Orca · ZeRO-Inference · Petals", "请求完成即可补位；权重 offload 与分布式协作拓宽部署边界。"], + ["2022–23", "少走串行步数、少搬字节", "Speculative Decoding · FlexGen · GPTQ · SmoothQuant", "推测、offload 与量化成为三条互补主线。"], + ["2023", "KV Cache 成为显式系统对象", "vLLM · PagedAttention · SGLang · Prompt Cache", "page、前缀树和结构化语言运行时把状态复用提升为核心抽象。"], + ["2024", "按阶段、上下文与 SLO 拆服务", "Splitwise · DistServe · Sarathi · Mooncake", "prefill、decode、缓存与网络开始独立扩容和调度。"], + ["2024–25", "Kernel、压缩与推测共同优化", "FlashInfer · QServe · KVQuant · EAGLE-3", "性能来自算法、数据布局、精度和运行时的协同，不是单点技巧。"], + ["2024–26", "开放前沿模型反向定义系统", "DeepSeek V2→V4 · Kimi K2→K3", "MLA/KDA、MoE、FP8/FP4、分离服务与混合状态缓存一起设计。"], +]; + +const paperChain = [ + ["2019", "Fast Transformer Decoding / MQA", "https://arxiv.org/abs/1911.02150", "让多个 query heads 共享 K/V，直接减少 decode 状态读取。"], + ["2020", "Megatron-LM", "https://arxiv.org/abs/1909.08053", "模型内张量并行成为超大 Transformer 推理放置的基础坐标。"], + ["2020", "Clockwork", "https://www.usenix.org/conference/osdi20/presentation/gujarati", "以可预测执行、集中调度和模型缓存控制服务延迟。"], + ["2021", "ZeRO", "https://arxiv.org/abs/1910.02054", "分片状态的思想延伸到超大模型训练与服务。"], + ["2021", "DeepSpeed-MoE", "https://arxiv.org/abs/2201.05596", "把稀疏专家推理的并行、通信与延迟作为联合问题。"], + ["2022", "FlashAttention", "https://arxiv.org/abs/2205.14135", "用 IO-aware tiling 减少 HBM 往返，而不是近似注意力。"], + ["2022", "ZeRO-Inference", "https://arxiv.org/abs/2207.00032", "把巨量权重从 GPU 卸载并以带宽感知方式分层取用。"], + ["2022", "Orca", "https://www.usenix.org/conference/osdi22/presentation/yu", "iteration-level scheduling 与 selective batching 形成连续批处理主线。"], + ["2022", "Petals", "https://arxiv.org/abs/2209.01188", "跨互联网协作服务大模型，展示异构和不可靠网络边界。"], + ["2022", "LLM.int8()", "https://arxiv.org/abs/2208.07339", "混合精度处理 outlier，让超大模型 8-bit 推理更稳健。"], + ["2022", "GPTQ", "https://arxiv.org/abs/2210.17323", "逐层二阶近似的 post-training weight quantization。"], + ["2022", "SmoothQuant", "https://arxiv.org/abs/2211.10438", "把激活离群难度迁移到权重，实现 W8A8。"], + ["2022", "Speculative Decoding", "https://arxiv.org/abs/2211.17192", "用便宜草稿与目标模型验收，保持目标分布不变。"], + ["2023", "Speculative Sampling", "https://arxiv.org/abs/2302.01318", "独立建立保分布的推测采样与验收机制。"], + ["2023", "AlpaServe", "https://arxiv.org/abs/2302.11665", "把统计复用与模型并行放置用于突发式服务。"], + ["2023", "FlexGen", "https://arxiv.org/abs/2303.06865", "GPU、CPU、磁盘三层 offload 与线性规划式策略搜索。"], + ["2023", "FastServe", "https://arxiv.org/abs/2305.05920", "以抢占和跳级队列降低 autoregressive 服务尾延迟。"], + ["2023", "SpecInfer", "https://arxiv.org/abs/2305.09781", "树状草稿与并行验证拓展推测解码。"], + ["2023", "AWQ", "https://arxiv.org/abs/2306.00978", "保护少量显著权重的激活感知 weight-only 量化。"], + ["2023", "H2O", "https://arxiv.org/abs/2306.14048", "以 heavy-hitter oracle 选择性保留 KV。"], + ["2023", "FlashAttention-2", "https://arxiv.org/abs/2307.08691", "改善 work partitioning，减少非矩阵乘法开销。"], + ["2023", "vLLM / PagedAttention", "https://arxiv.org/abs/2309.06180", "把 KV Cache 分页，支持近零外部碎片与共享。"], + ["2023", "StreamingLLM", "https://arxiv.org/abs/2309.17453", "用 attention sinks 保持有限缓存下的流式长序列。"], + ["2023", "CacheGen", "https://arxiv.org/abs/2310.07240", "压缩 KV 的网络传输以加速上下文加载。"], + ["2023", "Prompt Cache", "https://arxiv.org/abs/2311.04934", "用模块化 prompt schema 复用中间状态。"], + ["2023", "REST", "https://arxiv.org/abs/2311.08252", "从检索到的历史 n-gram 构造免训练草稿。"], + ["2023", "Splitwise", "https://arxiv.org/abs/2311.18677", "拆分 prompt 与 token generation 阶段，按资源特征放置。"], + ["2023", "SGLang", "https://arxiv.org/abs/2312.07104", "RadixAttention 与结构化生成运行时复用共享前缀。"], + ["2024", "DistServe", "https://arxiv.org/abs/2401.09670", "以 goodput 为目标分离 prefill / decode 并独立扩容。"], + ["2024", "Medusa", "https://arxiv.org/abs/2401.10774", "在目标模型上增加多步预测 heads，减少独立 draft 开销。"], + ["2024", "EAGLE", "https://arxiv.org/abs/2401.15077", "在 feature 层自回归预测并结合 token，提高草稿准确率。"], + ["2024", "KVQuant", "https://arxiv.org/abs/2401.18079", "按通道 key、按 token value 与 outlier 分离量化 KV。"], + ["2024", "BurstGPT", "https://arxiv.org/abs/2401.17644", "真实服务 trace 揭示突发、长度与模型混合的工作负载。"], + ["2024", "KIVI", "https://arxiv.org/abs/2402.02750", "非对称 2-bit KV 量化并保留近期 residual。"], + ["2024", "Lookahead Decoding", "https://arxiv.org/abs/2402.02057", "用 Jacobi 迭代并行发现、验证 n-gram，无需 draft model。"], + ["2024", "Hydragen", "https://arxiv.org/abs/2402.05099", "共享前缀请求分解注意力，提升跨序列复用。"], + ["2024", "ChunkAttention", "https://arxiv.org/abs/2402.15220", "以前缀树组织 KV chunk 并共享计算。"], + ["2024", "Sarathi-Serve", "https://arxiv.org/abs/2403.02310", "chunked prefill 与 stall-free batching 缓和阶段干扰。"], + ["2024", "LayerSkip", "https://arxiv.org/abs/2404.16710", "训练早退层作为自推测草稿，并由后续层验证。"], + ["2024", "SnapKV", "https://arxiv.org/abs/2404.14469", "从 observation window 选择重要位置压缩长 prompt KV。"], + ["2024", "DeepSeek-V2", "https://arxiv.org/abs/2405.04434", "MLA 将增长 KV 压到 latent 表示，DeepSeekMoE 降低激活计算。"], + ["2024", "QServe", "https://arxiv.org/abs/2405.04532", "W4A8KV4 与硬件友好 kernel 的联合推理系统。"], + ["2024", "CacheBlend", "https://arxiv.org/abs/2405.16444", "融合独立缓存的文本块，并选择性重算跨块依赖。"], + ["2024", "PyramidKV", "https://arxiv.org/abs/2406.02069", "按层分配递减 KV 预算。"], + ["2024", "Llumnix", "https://arxiv.org/abs/2406.03243", "跨实例实时迁移请求以重平衡和避障。"], + ["2024", "Quest", "https://arxiv.org/abs/2406.10774", "以 page 级查询感知稀疏选择减少长上下文 decode 读量。"], + ["2024", "EAGLE-2", "https://arxiv.org/abs/2406.16858", "用上下文置信度动态调整草稿树。"], + ["2024", "MemServe", "https://arxiv.org/abs/2406.17565", "把分离 KV 缓存池与弹性服务连接成存算分离架构。"], + ["2024", "InfiniGen", "https://arxiv.org/abs/2406.19707", "提前预测关键 KV 并从 CPU 选择性加载。"], + ["2024", "Preble", "https://arxiv.org/abs/2407.00023", "在分布式 prompt 服务中联合前缀复用与负载。"], + ["2024", "Mooncake", "https://arxiv.org/abs/2407.00079", "以 KVCache-centric disaggregated architecture 服务长上下文。"], + ["2024", "FlashAttention-3", "https://arxiv.org/abs/2407.08608", "面向 Hopper 异步、低精度与 warp specialization 优化 attention。"], + ["2024", "DeepSeek-V3", "https://arxiv.org/abs/2412.19437", "FP8、MLA、MoE 与无损负载均衡共同改变部署形状。"], + ["2025", "FlashInfer", "https://arxiv.org/abs/2501.01005", "为多形态 LLM serving 提供可组合 attention / sampling kernel。"], + ["2025", "EAGLE-3", "https://arxiv.org/abs/2503.01840", "直接预测 token，并融合低中高层特征增强草稿。"], + ["2025", "DeepEP", "https://github.com/deepseek-ai/DeepEP", "DeepSeek 官方 MoE dispatch / combine 通信库。"], + ["2025", "DeepGEMM", "https://github.com/deepseek-ai/DeepGEMM", "DeepSeek 官方 FP8 / low-precision GEMM kernel 库。"], + ["2025", "FlashMLA", "https://github.com/deepseek-ai/FlashMLA", "DeepSeek 官方面向 MLA decode / prefill 的高效 kernel。"], + ["2025", "Kimi Linear", "https://arxiv.org/abs/2510.26692", "KDA 以门控 Delta Rule 形成固定大小 recurrent state。"], + ["2025", "DeepSeek-V3.2", "https://arxiv.org/abs/2512.02556", "稀疏注意力、长上下文与推理训练继续压低服务成本。"], + ["2026", "DeepSeek-V4", "https://arxiv.org/abs/2606.19348", "CSA/HCA/SWA 与异构状态缓存把上下文状态进一步分层。"], + ["2026", "Kimi K3", "https://arxiv.org/abs/2607.24653", "69 KDA + 24 Gated MLA、page cache、EAGLE-3 draft 与预算准入联合设计。"], +]; + +const audits = [ + ["工作负载", "prompt / output 长度分布、并发、突发、前缀复用和租户隔离是否来自真实 trace？"], + ["SLO", "TTFT、TPOT、E2E、deadline、可用性和拒绝率是否分别定义了分位数？"], + ["分母", "报告的是峰值吞吐、完成吞吐，还是满足 SLO 的 goodput？"], + ["权重", "参数量、精度、scale / metadata、workspace、复制和 offload 是否都入账？"], + ["状态", "MHA/GQA/MLA/KDA 的状态公式、精度、page 与回滚口径是否明确？"], + ["调度", "静态 / 连续 batch、token budget、chunk、抢占和 fairness 如何交互？"], + ["缓存", "key、page 边界、版本、命中有效长度、淘汰、租户隔离与失效怎样定义？"], + ["拆分", "P/D 分离后的 KV 传输字节、网络、放置、重试和失效成本是否入账？"], + ["量化", "W/A/KV/通信分别多少 bit？校准、QAT、fallback 与任务退化怎样测？"], + ["推测", "草稿长度、验收率、draft / verify / rollback 成本和分布正确性是否同时披露？"], + ["MoE", "总权重放置、激活专家、all-to-all、热点、冗余专家与小 batch GEMM 是否入账？"], + ["故障", "worker、缓存、网络和路由故障下，是重试、重算、降级还是拒绝？状态是否原子失效？"], + ["可比性", "硬件、软件版本、精度、模型、请求分布、SLO 与功耗是否相同？"], + ["边界", "作者报告值、教学估算、内部线上数与可复现实测是否用不同标签？"], +]; +--- + + +
+
+
+

INFERENCE / 14 MEMORY · TIME · FLEET

+

模型训练完以后，
怎样让千万人用得起？

+

+ 从一条请求的权重与 KV 字节账出发，穿过 PagedAttention、连续批处理、 + chunked prefill、P/D 解耦、量化和推测解码；再重点追踪 DeepSeek + 从 MLA 到 V4 异构缓存，以及 Kimi 从 Mooncake 到 K3 混合状态服务的完整谱系。 +

+
+
+
LEVEL
L0 直觉 → L3 集群
+
LEDGERS
18 本独立账
+
NODES
62 个一手节点
+
LAB
4 个交互实验
+
TIME
约 260–340 分钟
+
VERIFIED
2026-07-29
+
+
+
+ +
+ + +
+
+

00 EIGHTEEN LEDGERS

+

不要先问“哪个框架最快”，先问哪本账正在爆

+

+ 同一个模型可以在离线批处理里吞吐极高，却在聊天服务中首字很慢；可以靠缓存服务 + 400K 代码前缀，也可能因为亲和路由把一台机器压成热点。只有把十八本账分开，系统名才有意义。 +

+ +
+ PREREQUISITE / 07长上下文与高效注意力

先理解 KV、MLA、KDA 和上下文状态。

 + PREREQUISITE / 08大规模训练系统

并行、通信和 MoE 放置在推理端仍然存在。

 + PREREQUISITE / 09数值精度与稳定性

量化节省的是哪类字节，要从数值格式开始。

 +
+ +
+ {ledgers.map(([code, title, question, answer]) => ( +
{code}

{title}

{question}

{answer}

+ ))} +
+ +
+ ONE-SENTENCE MODEL +

推理服务是一间状态工厂：prefill 把 prompt 制造成可复用状态，decode 反复读取权重与状态产生下一个 Token，调度器则在 SLO 前提下决定谁先占用哪种资源。

+
+ +
+ {waves.map(([year, title, nodes, note], index) => ( +
{String(index + 1).padStart(2, "0")}

{title}

{nodes}

{note}

+ ))} +
+
+ +
+

01 REQUEST STACK

+

用户看到一个回答，机房里经过七层

+

+ API 网关只负责把请求送进来。真正决定成本的是：怎样排队、是否命中前缀、由谁做 + prefill、状态放在哪里、谁做 decode、每步调用哪些 kernel，以及流式输出能否按时送回。 +

+
+ {[ + ["01", "GATEWAY", "鉴权、限流、模型 / 租户选择", "失败不是 GPU 慢，而是入口排队。"], + ["02", "SCHEDULER", "SLO、token budget、优先级", "决定请求何时成为 active。"], + ["03", "CACHE INDEX", "前缀 hash、page、版本与租户", "命中必须同时语义有效与状态可用。"], + ["04", "PREFILL", "批量处理 prompt，生成状态", "常见情形偏 compute-bound，但不是定律。"], + ["05", "STATE FABRIC", "HBM / DRAM / SSD / remote KV", "容量、带宽、复制和失效都入账。"], + ["06", "DECODE", "逐步采样、draft、verify", "常见情形偏 memory-bandwidth-bound。"], + ["07", "STREAM", "首字、字间与最终状态", "用户体验由最慢分位数而非均值决定。"], + ].map(([n, title, body, foot]) => ( +
{n}{title}

{body}

{foot}
+ ))} +
+
+
模型 FLOPs≠

线上延迟

+
GPU 利用率≠

用户满意

+
Cache hit≠

有效复用

+
吞吐最高≠

单位 goodput 最便宜

+
+
+ +
+

02 METRICS

+

把“快”拆成五个彼此冲突的指标

+
+
TTFT

Time To First Token

入口排队、cache lookup、prefill、首轮调度与网络返回之和。长 prompt 首先打在这里。

+
TPOT / ITL

Time Per Output Token

流式输出相邻 Token 的间隔。decode 抖动会让回答“卡顿”。

+
E2E

End-to-End Latency

从请求进入到完整输出结束，受输出长度强烈影响。

+
THROUGHPUT

Tokens / second

系统总产出；若大量请求违约，峰值吞吐依然可能很漂亮。

+
GOODPUT

SLO-qualified throughput

同时满足 TTFT / TPOT 等约束的完成量，才可用于容量与成本决策。

+
+
+ Goodput = Σ completed work × 𝟙[all SLOs satisfied] / time + SLO 必须带分位数与请求类。例如“短聊天 TTFT P95 < 1 s、TPOT P99 < 80 ms”；只写平均延迟不足以复现。 +
+
PLAIN LANGUAGE

餐厅一小时做 300 道菜是吞吐；其中 280 道在承诺时间内送到，才是 goodput。为了第 301 道菜让所有桌都迟到，不叫优化。

+
+ +
+

03 REQUEST CLOCK

+

一次生成包含两种完全不同的计算节奏

+
+
QUEUE排队
+
PREFILL处理整个 prompt
+
TTFT首字返回
+
DECODE × N读状态 → 生成 → 更新
+
+
+
PREFILL

一次并行处理很多输入位置

  • 矩阵更大，通常更容易吃满算力
  • 长 prompt 延长 TTFT
  • 产物是后续可复用的状态
  • 可切成 chunk 与 decode 交错
+
DECODE

每一步只有新位置，循环很多次

  • 反复读取权重与历史状态
  • batch 增大能摊权重读取
  • TPOT 决定流式体验
  • 推测解码试图减少串行轮数
+
+
REGIME, NOT LAW

“prefill 算力受限、decode 带宽受限”是常见硬件与 shape 下的工作区间，不是所有模型、batch、长度与 kernel 都成立的物理定律。

+
+ +
+

04 WEIGHT MEMORY

+

权重是进门票，不是全部显存

+
Weight bytes ≈ parameter count × bits / 8真实部署还要加量化 scale / zero-point、embedding / head 特殊精度、临时 workspace、通信 buffer、allocator reserve 与框架开销。
+
+
70B / BF16约 130.4 GiB

单卡 80 GiB 放不下权重本体。

+
70B / INT8约 65.2 GiB

看似可放，留给 KV 与 workspace 的余量很窄。

+
70B / INT4约 32.6 GiB

容量改善显著，但速度取决于 kernel 与硬件路径。

+
+

+ 当模型跨卡时，还要选择复制还是分片。复制提高数据并行容量，却让每个副本承担全部权重； + tensor parallel 分片矩阵，却在层内频繁通信；pipeline parallel 减少单卡权重，却引入阶段气泡和请求微批约束。 +

+
+ +
+

05 KV CACHE MATH

+

上下文不是抽象长度，它是一笔逐 Token 增长的字节债

+
+ KVBytes = B × T × L × 2 × Hkv × Dh × bytes + B 并发请求，T 已缓存位置，L 层数，2 表示 K 与 V，Hkv 为 KV heads，Dh 为每头维度。这个式子精确适用于标准 MHA / MQA / GQA 口径。 +
+
+ {[ + ["B", "并发", "请求数翻倍，状态近似翻倍"], + ["T", "长度", "上下文翻倍，增长状态翻倍"], + ["L", "层数", "每个注意力层各存一份"], + ["2", "K + V", "两组历史张量"], + ["Hkv", "KV heads", "MQA / GQA 直接减少此项"], + ["Dh", "头维度", "每个位置每个头的宽度"], + ["bytes", "精度", "FP16=2，INT8=1，4-bit≈0.5"], + ].map(([symbol, title, note]) =>
{symbol}{title}

{note}

)} +
+

+ 最常见的错误是只算一个请求，或把模型参数精度当成 KV 精度。W4 不自动等于 KV4； + 量化权重后留下的空间，也可能很快被长上下文和高并发吃完。 +

+
+ +
+

06 STATE ARCHITECTURES

+

“KV Cache”已经不是一种统一形状

+
+
MHA
{Array.from({length: 16}).map(() => )}

每个 Q 头一组 K/V

表达直接，增长状态最大；decode 需要读更多历史字节。

状态 ∝ Hq × T
+
GQA / MQA
{Array.from({length: 4}).map(() => )}

多个 Q 头共享 K/V

以更少 KV heads 换容量与带宽，成为服务友好设计。

状态 ∝ Hkv × T，Hkv ≪ Hq
+
DEEPSEEK MLA

缓存低维 latent

通过低秩压缩与解耦 RoPE，避免保存完整每头 K/V。

仍随 T 增长，但每位置更小
+
KIMI KDA

固定 recurrent state

线性注意力用门控 Delta Rule 更新有限状态；局部精确回忆仍需混合 MLA。

核心 recurrent state 不随 T 线性增长
+
+
DO NOT SUBSTITUTE FORMULAS

不能把 MLA 的 latent 或 KDA 的 recurrent matrix 硬塞进标准 Hkv 公式并称为精确值。先确认状态对象，再谈字节。

+
+ +
+

07 PAGEDATTENTION

+

vLLM 的关键不是“少算注意力”，而是让状态不必连续居住

+
+
CONTIGUOUS ALLOCATION

为最大长度预留、不同寿命请求离开后留下洞；连续扩容困难。

+ → PAGE TABLE → +
PAGED KV
{Array.from({length: 12}).map((_, i) => )}

逻辑 block 映射到非连续物理 page；前缀可引用共享 page，写入时 copy-on-write。

+
+
+
按需分配

请求每增长一个 block 才取新 page，不必按最大长度预留。

+
生命周期管理

请求结束可逐 page 回收，避免必须寻找大连续区域。

+
共享

并行采样和共同前缀可以引用同一物理 page。

+
+

+ PagedAttention 解决的是内存管理和共享，不会降低 Transformer 本身的理论 FLOPs； + “近零浪费”也不等于绝对零，最后一个 block 仍有内部碎片，page table 和 kernel 也有开销。 +

+
+ +
+

08 PREFILL

+

长 prompt 是一项可排队、可缓存、可切片的生产任务

+
+
INPUT32K prompt

长度、模态与 padding 决定实际输入。

+ → +
FORWARD宽矩阵计算

每层同时处理大量位置，通常更容易利用算力。

+ → +
OUTPUTLayer states
{Array.from({length: 8}).map(() => )}

状态写入 HBM 或缓存层，供 decode 和后续请求读取。

+
+

+ 首字延迟不是单纯的 prefill kernel 时间：请求可能在 admission、batch 形成、cache lookup、 + page 分配与队列中停留。长 prompt 若一次占满调度迭代，还会让已经在流式输出的请求停止前进。 +

+
+ +
+

09 DECODE

+

每次只写一个新 Token，却要反复搬动整个模型与历史

+
+
01读取权重

batch 内请求共同摊一次矩阵权重访问。

→ +
02读取历史状态

attention 访问此前 K/V 或其他 recurrent state。

→ +
03采样一个 Token

logits、约束、采样与停止条件。

↺ +
+

+ decode 的“算术强度”常较低：每个新位置对应的计算量有限，却需读大量字节。增加 batch + 可以提升权重重用，但 batch 过大又会增加排队、KV 容量和 TPOT。系统优化目标因此是一个带 SLO 的工作点，而非无限扩大 batch。 +

+
+ +
+

10 CONTINUOUS BATCHING

+

静态 batch 等最慢者；连续 batch 在每一步补位

+
+
STATIC

整批一起开始，一起结束

短请求完成后留下空槽，直到最长请求结束。

+
ORCA / ITERATION-LEVEL

每次 decode 迭代重新组批

完成即补新请求，显著提高 slot 利用率；调度开销和公平性仍需管理。

+
+

+ continuous batching 不是把所有请求简单堆在一起。一个服务迭代可能包含 decode token、 + 新请求 prefill、被抢占请求恢复和 cache transfer；真正的调度单位越来越接近“token budget + 状态资源”。 +

+
+ +
+

11 CHUNKED PREFILL

+

把 128K prompt 切开，给流式请求留出呼吸

+
+ ITERATION123456 + MONOLITHICPREFILL 128KDD + CHUNKEDP 1DP 2DP 3D +
+

+ Sarathi-Serve 的核心直觉是把大 prefill 切成 chunk，与 decode 组合成更均匀的迭代。 + chunk 太大仍会 stall，太小则增加调度和 kernel 开销；它改善阶段干扰，不保证所有 workload 都降低 TTFT。 +

+
+ +
+

12 KERNELS

+

算法写下 FLOPs，kernel 决定字节怎么走

+
+ {[ + ["ALGORITHM", "Attention / MLA / MoE / quantization", "定义数学工作与可利用结构。"], + ["LAYOUT", "page、tile、group、scale、sparsity", "决定能否连续访问、复用和向量化。"], + ["KERNEL", "FlashAttention · FlashInfer · FlashMLA · DeepGEMM", "融合操作，安排 warp、共享内存与异步流水。"], + ["RUNTIME", "shape dispatch、graph、batch、stream", "为不同长度和并发选择实际实现。"], + ["HARDWARE", "HBM、tensor core、network", "最终受容量、带宽、指令和拓扑约束。"], + ].map(([title, nodes, note]) =>
{title}{nodes}

{note}

)} +
+
DEEPSEEK OPEN KERNELS

FlashMLA · DeepGEMM · DeepEP

分别覆盖 MLA attention、低精度 GEMM 与 MoE dispatch/combine。开源 kernel 让“模型架构如何要求系统实现”变得可检查，而不只是论文里的吞吐数字。

+
+ +
+

13 PREFIX CACHE

+

命中不是一个布尔值，而是一段有效状态的证明

+
+
ROOT
+ system prompt +
SHARED 8K
+
repo A
A / 120K
+
repo B
B / 86K
+
+
+
Key

模型 / adapter / tokenizer / 精度 / 内容 hash / 租户。

+
Extent

到底命中多少有效 Token，不是“有相似 prompt”。

+
Placement

page 在哪台 worker、哪层内存，搬运是否比重算便宜。

+
Validity

版本、过期、故障、写入和 copy-on-write 的原子语义。

+
+

缓存节省 prefill compute，却消耗容量、索引、网络与路由自由度。SGLang 的 RadixAttention、Prompt Cache、Hydragen、ChunkAttention、Preble 分别从程序结构、共享计算和分布式调度推进这条主线。

+
+ +
+

14 PREFILL / DECODE DISAGGREGATION

+

把两种节奏拆开扩容，但必须付状态搬运费

+
+
PREFILL POOL
compute-oriented

长 prompt、宽矩阵、cache creation

+ KV / STATE FABRICbytes · bandwidth · queue · retry +
DECODE POOL
bandwidth-oriented

持续小步、batch、streaming SLO

+
+

+ Splitwise 把 prompt 与 token generation 放到适配的机器；DistServe 以 goodput 与独立扩容为中心； + Mooncake 更进一步把 KVCache 作为存算分离系统的中心。拆分消除资源干扰，却新增 KV transfer、跨池排队和故障协调。 +

+
Disaggregate only if: interference saved > state transfer + extra queueing + failure overhead不是看到 prefill/decode 特征不同就自动应该拆。短 prompt、慢网络或小规模服务可能不划算。
+
+ +
+

15 QUANTIZATION

+

“4-bit 模型”至少漏掉三本精度账

+
+
W

Weights

GPTQ · AWQ · weight-only

省权重容量和读取；是否加速取决于反量化融合与低精度 GEMM。

+
A

Activations

SmoothQuant · W8A8 · FP8

离群值、累加精度和校准影响 tensor core 路径。

+
KV

Growing state

KVQuant · KIVI · QServe

长上下文直接获益；key/value、近期 / 远期状态可采用不同策略。

+
NET

Communication

dispatch · cache transfer

量化网络载荷可能省带宽，却增加转换和误差边界。

+
+

+ DeepSeek-V3 将 FP8 训练 / 推理和 MLA、MoE 一起设计；K3 从 SFT 进入 MXFP4/MXFP8 QAT， + 并保持非专家模块更高精度。QAT 是让模型适应目标数值路径，不等于所有层都用同一格式。 +

+
+ +
+

16 SPECULATIVE DECODING

+

目标模型一次验多步，减少最昂贵的串行轮数

+
+
DRAFT
ABCDE

小模型、额外 heads、feature predictor、检索或自推测产生候选。

+ → +
VERIFY IN PARALLEL

目标模型并行计算候选位置，并按算法逐项验收。

+ → +
COMMIT
ABC×

提交被接受前缀，再从目标分布纠正；状态必须可回滚。

+
+
+ a = Σx min(p(x), q(x))  ·  + E[tokens] = 1 + a + … + ak + 左式是目标分布 p 与草稿 q 的重叠质量；右式是假设每步独立、验收率固定为 a 的教学期望，不是所有实现的实测加速。 +
+

+ Vanilla speculative sampling 用独立小模型；Medusa 在主模型上加多步 heads；EAGLE 在 feature + 层预测，EAGLE-2 动态构树，EAGLE-3 融合多层特征。速度取决于验收率、草稿成本、验证 shape 和状态回滚，草稿越长并不总越快。 +

+
+ +
+

17 PARALLELISM

+

放不下是一类问题，放得下但通信太多是另一类

+
+
DPData Parallel

完整副本服务不同请求。扩吞吐自然，但每份权重都占容量。

+
TPTensor Parallel

层内矩阵跨卡，减少单卡权重；每层都有 collective。

+
PPPipeline Parallel

不同层跨阶段，降低单卡容量；气泡和逐 Token 流水复杂。

+
EPExpert Parallel

MoE 专家跨设备，激活按路由 all-to-all。

+
CP / SPContext / Sequence

长序列状态或计算跨设备，交换边界与聚合结果。

+
+

服务并行还要考虑请求级容错：TP 组中一张卡失败可能使整个 replica 失效；DP 副本则较易摘除。最少 GPU 数、最优 GPU 数和可容错 GPU 数不是同一个答案。

+
+ +
+

18 MOE INFERENCE

+

激活参数少，不等于只需要存激活专家

+
+
{Array.from({length: 12}).map((_, i) => {i + 1})}
+ ROUTER +
{Array.from({length: 8}).map((_, i) => E{i + 1})}
+
+
+
总权重

全部专家仍需放在 GPU、主存或分层存储中。

+
路由通信

Token dispatch / combine 带来 all-to-all 与拓扑敏感性。

+
热点

输入分布让少数专家拥挤；均值负载掩盖尾部。

+
小 GEMM

单专家 batch 过小，理论低 FLOPs 仍可能 memory-bound。

+
+

DeepSeek-V3 的部署报告把 prefill 与 decode 设成完全不同的 EP 规模，并使用冗余专家；DeepEP 则为 dispatch / combine 提供高吞吐与低延迟路径。模型路由和网络拓扑必须共同设计。

+
+ +
+

19 SCHEDULING & SLO

+

调度器不是把 GPU 塞满，而是在过载时决定谁不被伤害

+
+
REQUESTPROMPTOUTPUTDEADLINEDECISION
+
chat-311K200TTFT 800msADMIT
+
agent-08400K hit8KTPOT 90msAFFINITY
+
batch-92128K32K30 minDEFER
+
agent-771M miss16KTTFT 5sREJECT
+
+

+ 平均并发阈值看不见请求长度：1 个 1M 请求和 1 个 1K 请求都被计为“1”。 + token-budget admission 将预期 prefill、KV 和 decode 工作纳入预算；过载时拒绝或延后长任务，可能提高短请求 goodput。 +

+
FAIRNESS IS A PRODUCT CHOICE

保护短请求、优先付费租户、保证老请求不饿死、为长 Agent 保留配额，都是不同策略；不能只用系统吞吐替用户做决定。

+
+ +
+

20 FLEET & FAILURE

+

单机优化完成后，路由、热点和故障成为主问题

+
+
LOAD送到最空闲实例

减少排队，却可能放弃已有 400K 前缀。

+
LOCALITY送到有缓存实例

避免 prefill，却可能把热门 repo 挤到单点。

+
RESILIENCE复制与可重算

多副本增加成本；不复制则故障时重算和违约。

+
+

+ Llumnix 通过请求迁移重平衡实例；Preble 联合考虑前缀复用与负载；Mooncake / MemServe + 把状态放进独立缓存层。真实系统还必须定义 pin、复制中读写、版本升级、原子失效和 secondary re-prefill。 +

+
+ +
+

21 DEEPSEEK LINEAGE

+

DeepSeek 的低成本服务不是一项技巧，而是四代共同设计

+
+

MLA + DeepSeekMoE

从模型结构上减少每 Token KV 和激活计算。

STATE ARCHITECTURE
+ → +

FP8 + system co-design

训练、MoE 路由、专家通信与 P/D 部署一起设计。

FULL STACK
+ → +

Sparse attention

长上下文继续压缩 attention 工作，服务与推理训练协同。

LONG CONTEXT
+ → +

Heterogeneous state

CSA / HCA / SWA 把增长状态按功能与介质分层。

STATE HIERARCHY
+
+
READING KEY

架构降成本 × 数值降字节 × kernel 提利用率 × 服务分阶段

只复制 MLA 或只换 FP8，都不等于复制 DeepSeek 的整体经济性。

+
+ +
+

22 DEEPSEEK V2 → V3

+

先压每 Token 状态，再把 MoE 推理摊到两种集群

+
+
V2 / MLA

低秩 latent 代替完整每头 K/V

把增长缓存从“每个 KV 头的完整向量”压缩成共享 latent，并把 RoPE 部分解耦。

+
V2 / MOE

细粒度专家与 shared experts

总容量增加而每 Token 只激活部分专家；服务端承担专家放置与通信。

+
V3 / NUMERICS

FP8 与累加控制

减少权重、激活与通信字节，并以配方和 kernel 守住稳定性。

+
V3 / ROUTING

无 auxiliary-loss 负载均衡

模型训练中的路由平衡直接影响线上专家热点与硬件利用率。

+
+
+
AUTHOR-REPORTED DEPLOYMENT SHAPEDeepSeek-V3
+
PREFILL最少 4 nodes / 32 GPUs

TP4 · SP / DP8 · EP32 · 32 redundant experts

DECODE最少 40 nodes / 320 GPUs

TP4 · SP / DP80 · EP320；单专家 batch 通常 ≤256，偏 memory-bound

+
这是论文报告的部署形状与局限，不是运行 V3 的普遍最低硬件要求，也不能直接外推成本倍数。
+
+
+ +
+

23 DEEPSEEK V3.2 → V4

+

从压缩 KV 走到异构状态缓存

+
+
CSACompressed Sparse Attention

只选择与当前 query 相关的一部分历史。

+
HCAHierarchical / compressed state

用不同粒度保留全局记忆与可检索摘要。

+
SWASliding Window Attention

为局部精确依赖保留有限窗口。

+
STORAGEHBM → host → disk

冷状态可下沉，容量变大但访问和失败路径更复杂。

+
+
+ AUTHOR'S 1M-CONTEXT ESTIMATES / VS V3.2 +
V4-Pro27% FLOPs · 10% KV
+
V4-Flash10% FLOPs · 7% KV
+

这些是报告内特定配置的估算比例，不是任意工作负载的端到端延迟或成本倍数。磁盘缓存将容量收益换成 IO、预取与尾延迟风险。

+
+

V4 还报告了组件级 FP4 selector：特定选择器实验中 2× 加速、99.7% recall。它描述一个组件，不应写成“V4 整体 2× 且精度 99.7%”。

+
+ +
+

24 KIMI LINEAGE

+

Kimi 的主线是把超长 Agent 历史变成可管理的状态系统

+
+

KVCache-centric

prefill、decode 与缓存池分离，围绕长上下文复用组织系统。

DISAGGREGATION
+ → +

Agentic workload

长工具轨迹与代码前缀让缓存、调度和稳定流式输出更重要。

WORKLOAD
+ → +

KDA state

以 Gated Delta Rule 形成固定 recurrent state，降低长度增长债。

ARCHITECTURE
+ → +

Hybrid serving

KDA + Gated MLA、page cache、speculation、affinity 与 admission 联动。

FULL STACK
+
+
+ +
+

25 MOONCAKE

+

把 KVCache 从 GPU 附属品提升为分布式基础设施

+
+
PREFILL CLUSTERS

生成 KV，并写入分布式缓存。

+ ↕ +
CONTEXT CACHE
HBMDRAMSSD

以带宽、容量和热度管理状态。

+ ↕ +
DECODE CLUSTERS

读取状态并持续生成。

+
+
+ AUTHOR-REPORTED / KEEP THE DENOMINATOR +
特定模拟场景最高 525% throughput improvement
+
真实工作负载在 SLO 下多服务 75% requests
+

两者分母和条件不同，不能合并成“Mooncake 普遍 5.25×”。论文的核心贡献是体系结构与调度方法，不是一个脱离 workload 的营销倍数。

+
+
+ +
+

26 K3 HYBRID STATE CACHE

+

69 个 KDA 固定状态，与 24 个 MLA 增长缓存一起管理

+
+
× 3 KDA
+ + +
× 1 GATED MLA
+ REPEAT +
69 KDA24 MLA报告配置另列 96 attention heads
+
+

+ KDA 用固定 recurrent state 处理远距离历史，MLA 保留随上下文增长的精确注意力缓存。 + 因为两者生命周期与回滚语义不同，K3 不能只复用传统 KV page manager。 +

+
+
PHYSICAL PAGE6,144 tokens

报告示例中的物理管理粒度。

+
HASH BLOCK512 tokens

更细粒度索引内容匹配。

+
MATCH2,800 tokens

内容匹配长度不自动等于有效状态长度。

+
VALID HIT2,560 tokens

按 hash block 对齐后可安全复用的示例。

+
+

报告还定义并发 pin、copy 与原子 invalidation：复制中不能回收源页，失效后不能继续向路由器宣称命中。这里的难点是分布式状态一致性，不只是 hash 查表。

+
+ +
+

27 K3 SPECULATION & ADMISSION

+

草稿、回滚、缓存亲和与预算准入共同守住长 Agent

+
+
DRAFT

MTP → EAGLE-3 style

预训练 MTP 初始化 draft；feature fusion 读取第 1、第 4 和最终 AttnRes，训练时展开 7 步。

+
OBJECTIVE

Loss with acceptance mass

LLK = −log Σ min(p, q) 直接鼓励草稿分布与目标分布重叠。

+
ROLLBACK

Replay accepted state

KDA 不为每条草稿复制完整 recurrent state；缓存投影输入，按被接受前缀重放更新。

+
FLEET

Affinity + budget

优先路由到已有状态的实例，同时用 token budget 防止超长任务淹没短请求。

+
+
TYPICAL REPORT EXAMPLE400K cached code prefix+4K new increment

缓存价值来自迭代式 Agent 反复使用巨型 repo 状态；如果路由丢失亲和性，就会为很小增量重复付出巨大 prefill。

+

K3 的 QAT 从 SFT 阶段进入 MXFP4 / MXFP8，非专家模块保留更高精度。这里再次说明：模型架构、draft、数值路径、cache manager 与 admission policy 是一套系统，而非五个独立“加速插件”。

+
+ +
+

28 INTERACTIVE LAB

+

现在让系统亲手失败一次

+

四个实验分别管理容量、阶段干扰、串行轮数与集群状态。先使用默认 K3 / 长上下文场景，再故意把每项推到失败区。

+ +
+ +
+

29 AUDIT CHECKLIST

+

看到任何“吞吐提升 X 倍”，先跑完这十四问

+
+ {audits.map(([title, question], index) =>
{String(index + 1).padStart(2, "0")}{title}

{question}

)} +
+
+
REPORTED作者报告值

保留硬件、模型、工作负载、SLO 和分母，不跨场景外推。

+
REPRODUCED独立复现值

公开脚本、commit、环境与误差，才可作为可比较证据。

+
ESTIMATED教学 / 容量估算

公开公式与假设，用于量纲推理，不冒充 benchmark。

+
+
+ +
+

↳ PRIMARY-SOURCE CHAIN

+

62 个节点：从 MQA 到 Kimi K3

+

每个链接都指向论文、会议页或官方实现。历史顺序用于建立因果脉络，不代表后出的系统在所有工作负载上都更优。

+
+ {paperChain.map(([year, title, url, note]) => ( + +
{title}

{note}

↗ + + ))} +
+
+
+
+ + +