研究日期：2026-10-02。这里的“token 工厂”指持续接收请求、运行模型并交付输出的推理基础设施：从模型、算子、显存，到网络、调度、缓存与服务质量。重点是文本自回归大模型；MoE、长上下文、推理模型与多模态入口也纳入边界。训练优化仅在它改变推理结构、精度或草稿能力时讨论。

先建立一张直觉地图

把推理服务想成一家需要随时接单的翻译工厂。模型权重是工人的知识，GPU 算力是脑力，HBM 带宽是翻阅资料的速度，KV cache 是已读材料的笔记，调度器是领班，网络是车间之间的运输带。这只是教学类比：权重、KV 和请求数据的寿命、布局与可共享范围并不相同。

一条请求先经过 prefill（预填充）：阅读已有输入，计算各层状态；随后进入 decode（解码）：依据已有状态逐步生成。常规自回归生成中，后一个 token 依赖前一个已经选定的 token，因此不能简单把一句话的每个位置当作互不相关的任务同时生成。推测解码通过“先猜、再批量验证”改变执行方式，而不是取消这种概率依赖。

最常见的优化可以归为六个动作：少算、少搬、少存、少重做、少等待、少用昂贵资源。这六项会互相影响。压缩 KV 既少存也少搬；减少显存碎片能放进更多请求，但过大的 batch 又会拉长单人等待。

三种成本必须分开看

以下是本教程统一使用的分析定义，属于成本建模，不是某个厂商的计费规则。

这里的“合格”是教程为比较定义的门槛：服务满足预先固定的质量和延迟要求。质量通常在样本或任务级验收，不能把每个 token 独立判成正确或错误。若把失败请求从分母剔除，仍必须把它消耗的资源留在分子，同时报告拒绝率和完成率，防止通过拒绝困难请求“优化”成绩。

设观测窗口总成本为 C、满足条件的输出数为 N，则 c = 10⁶ × C / N。若一套系统每小时成本 H、实测合格输出速率 G token/s，则 c = 10⁶ × H / (3600 × G)。所有空闲时段、网络/CPU/存储、草稿模型、失败请求、重计算都要计入相同窗口。自建用折旧、电力、机房和运维；租赁用实际租赁账单，不能在租赁价之上重复计提硬件折旧。

教学算例：基线每小时 100 元，合格输出 10,000 token/s，成本为 2.78 元/百万输出 token。优化后每小时 120 元、合格输出 15,000 token/s，成本为 2.22 元，下降 20%。吞吐提高 50%，但每小时资源支出也增加 20%，因此成本并没有下降 50%。这些数字是演示假设，不是产品报价或实测。

再看任务成本：假设 A 每次尝试 0.08 元，B 每次 0.05 元，但完成同样任务 A 平均尝试 1 次、B 平均尝试 2 次，则 A 为 0.08 元、B 为 0.10 元。便宜的尝试可能得到昂贵的结果；还要检查最终任务成功率是否相同。

成本曲线为什么比峰值 TPS 更重要

MLPerf Endpoints 同时观察系统总吞吐、每用户生成速度、首 token 延迟和并发数，随负载变化形成性能曲线。实际选择应在同样服务要求下比较曲线上的可行点。[1]

版本细节也会改变比较口径：检索时 Endpoints 展示页以 v0.7 的 TTFT P95 解释曲线，而 GitHub v1.0 草案明确改用 P90。二者不是同一个统计量，本教程不把草案当作已冻结通用标准。[1][2]

找瓶颈：先看是哪一种“忙”

以下公式是教学近似，用于建立因果关系；真实性能还受流水重叠、缓存命中、并行通信、批大小和实现影响。

单步时间下界 ≳ max（所需 FLOPs / 有效计算吞吐，所搬字节 / 有效内存带宽，通信量 / 有效网络带宽），另外还有无法重叠的调度与启动开销。只有实际处在某项瓶颈，优化该项才可能显著改善端到端成本。硬件标称峰值不能直接作为“有效”吞吐。

一个常见误解是“prefill 必然计算受限、decode 必然带宽受限”。应改成：常见长输入 prefill 和小批量 decode 倾向于这些瓶颈；长上下文 attention、大 batch、MoE通信或短请求启动开销都可能改变主导因素。

为什么加速倍数不能连乘

教学算例：假设一步耗时 10 ms，其中 8 ms 读权重、2 ms 做其他事。量化把这 8 ms 降到 4 ms，总时间为 6 ms，加速只有 1.67 倍。再引入一种同样减少权重读取的优化，不能把它在原始基线上的加速倍数直接乘上去：第一次优化已改变瓶颈。不同优化是否互补，取决于是否改善不同的剩余成本。

这也是 Amdahl 思路：若可优化部分占 p、局部加速 s，则整体加速 1 / ((1−p)+p/s)。现实中还要加入优化自己的开销，并重新测量质量、排队和吞吐。

路线选择：先做哪件事

下面是依据各章机制综合形成的工程判断，不是对所有模型通用的性能排序。

应用层也会改变工厂负载

模型路由、级联与蒸馏

直观地说，先判断一张工单需要普通工人还是专家。RouteLLM 训练路由器，在强、弱模型间选择，以平衡成本和回答质量；它有公开实现。[5][6]

具体做法：先用真实任务建立各模型的质量—延迟—成本表；给路由器输入问题特征；达到阈值时使用较小模型，否则升级。级联则先尝试便宜模型，再根据判别结果追加一次更强模型调用。路由器成本、错误分流、二次调用和更长输出都应计入。蒸馏是提前让小模型学习特定能力；其训练与评测成本应按未来请求量摊销，且必须复核目标业务质量。

教学判断：如果便宜模型处理80%请求，每次成本为强模型的1/5，剩余20%直接走强模型，忽略路由开销时平均成本为0.8×0.2+0.2×1=0.36。这个64%的节省只成立于假设的分流率和同等合格率；它不是RouteLLM实验结果。

Prompt压缩、检索与输出约束

LLMLingua 通过预算控制和逐token压缩等方式缩短输入，是改变所需处理量的算法路线。[8] 教学类比是把一箱文件整理成重点材料。收益来自更少的prefill计算和KV占用；压缩器自己也耗算力，删除证据可能损害回答，改写前缀还可能降低缓存复用。因此要评估“压缩成本 + 压缩后推理成本 + 质量损失引起的补救”。

RAG的检索、重排和合理top-k、去除重复工具返回、结构化输出和合适的最大输出预算，也能减少无效工作。它们降低的是完成任务所需的token数量，不能直接宣称底层每个token算得更快；改变上下文后还需做任务级回归。

推理预算与提前退出

s1 的 budget forcing 展示了通过终止或延长思考来控制测试时计算量。[11] 但2026-09的预印本指出，在其研究的模型与基准中，反复得到相同中间答案并不足以证明推理已完成。[12]

教学类比是：学生重复说同一个答案，可能只是还没发现自己的错误。可以按难度设思考预算、用验证器判断或做分档服务，但判断器也需要算力，必须计入“节省的生成 − 额外判断 − 更多失败”。这种方法改变生成策略和质量，不属于具有同分布保证的精确推测采样。

功耗控制：省电与省总成本的差别

GreenLLM 研究按prefill/decode阶段和SLO余量调整GPU频率。其论文使用8张A100 40GB、Qwen3-14B和Qwen3-30B-MoE、Dynamo v0.3.1及流量回放，摘要报告相对默认DVFS最多34%能耗下降，并有额外SLO违规，而非普遍零代价节能。[4]

本教程的推导：若电力只占总成本的15%，即使电费下降30%，在其他条件不变时总成本也只下降4.5%；若吞吐下降需要增加机器，还可能抵消收益。租用固定时价实例时，节电收益是否传导给租户还取决于计费方式。

从研究结果到可上线结果：一份最小实验协议

1. 固定模型版本、tokenizer、权重精度、KV精度、输出采样与业务质量门槛；能改变模型的路线另设质量匹配对照。
2. 保存输入/输出长度分布、共享前缀比例、到达时间、并发和冷热缓存状态；用真实trace以及长尾/突发压力样本。
3. 记录每套方案的设备数、设备型号、TP/PP/EP/CP、软件commit、网络拓扑、批大小和内存预算。
4. 扫描多个负载点；同时测TTFT、ITL/TPOT、完成率、拒绝率、系统TPS、GPU/CPU/网络/存储、能耗与全窗口成本。
5. 做逐项消融：基线 → 单个优化 → 组合优化，解释瓶颈转移；既测稳态，也测冷启动、故障恢复和缓存未命中。
6. 以“质量达标 + SLO达标”约束下的成本比较方案，给置信区间或重复运行波动；不能只挑最好一次。
7. 从影子流量开始，再小比例放量；保留回退配置。达到业务指标才把实验性方法升级为生产候选。

2026-09的MLPerf v6.1已纳入端到端RAG和Agentic Edge等基准，GPT-OSS-120B的Interactive场景允许推测解码，提示行业评估正从单次模型运行扩展到更完整的工作流。[7] 本教程据此判断：未来降本比较应同时报告制造效率和任务结果，而不只展示峰值token吞吐。

读图与证据等级

发展图谱中的时间是代表性论文/发布节点，不表示所有团队在那一年同时采用。箭头标识“解决前一阶段剩下的瓶颈或在其上组合”，不自动表示作者传承或论文引用关系。多个分支长期共存，旧技术不会因为新论文发布就失效。

证据按三类阅读：论文/预印本支持机制和论文内实验；官方代码/文档支持该实现当前公开的功能和限制；标准化基准/公开配置支持特定条件下的性能。官方营销口径、作者自报、未复现实验都明确标注；它们不能替代目标工作负载的成本实验。

本教程的公式、算例和交互实验是教学推导，标为“教学假设”，不把它们混入实测性能。公开资料无法穷尽所有闭源优化和客户成本，本次“完备性”限定为所定义技术范围的覆盖闭环，而非声称收录世界上所有推理论文。

技术发展图谱

六条路线，从单步计算到整座工厂。点选节点，查看它解决了什么、还留下什么。

横向箭头表示问题驱动的演进与可组合关系，不等同代码继承。具体发布日期与基线见相应教程。多个分支长期共存。

先按问题选入口

图谱节点连接到详细教程；技术之间的互补、竞争与前提条件见审查章的12组关联矩阵。既有方法、条件性工程方法与前沿研究的落地次序见2026前沿。

Token 工厂：执行内核、KV 生命周期与长上下文的技术演进

调研基准日：2026-10-02。此稿依据原论文全文、作者博客与框架官方文档。最晚核实的研究是 2026-09-03 的 FP4 attention 预印本，最晚核实的工程趋势包括 2026-08-07 的 vLLM DCP 官方报告；这不代表穷尽截至基准日全部新论文。成熟度是本文对公开证据的判断，不是厂商部署承诺。方括号编号属于本稿独立 ledger，合并时应按 URL 重编号。

1. 先判断哪条传送带堵住

想象一家餐厅：模型权重是固定菜谱，KV cache 是每桌已经读过的点菜单笔记，HBM 是大仓库，片上 SRAM/寄存器是小操作台，矩阵单元是厨师，CPU 发射 kernel 是服务员下工单。顾客先递来一整张菜单（prefill），然后每问一句，厨房才知道下一句怎么答（decode）。这是教学比喻；算力容量、内存容量、内存带宽、网络带宽分别对应不同约束，不能合并成一个“GPU 不够快”。

Transformer 于 2017 年提出；自回归推理缓存过去 token 的 K/V，避免每生成一个 token 都重算整个历史，形成 prefill 与逐步 decode 的分工。KV cache 没有免除读取历史 K/V 和计算新 query 对它们的注意力。[40][41]。

一张可操作的账单：对一个阶段，理想下界可写成 max(F/C, M/B)，其中 F 是运算量，C 是该精度有效算力，M 是搬运字节，B 是有效带宽；实际还需加未重叠的通信、启动、同步、排队。它是估算下界而非延迟预测器。大矩阵 prefill 往往计算受限；小批次 decode 的线性层容易受读权重带宽限制；长上下文 decode 又会受读 KV 限制。批量增大可复用同一份权重，却不消除各请求自己的 KV 流量。GQA、MLA、投机验证及不同 kernel 会改变具体 roofline，不能把“decode 永远只受 HBM 限制”当定律。[41]

自制教学算例，非硬件实测：假设每步读 20 GB 权重、每请求读 0.5 GB KV，有效带宽 1 TB/s，忽略算力和通信。batch=1 的带宽时间约 20.5 ms、总吞吐约 48.8 token/s；batch=16 约 28 ms、总吞吐约 571.4 token/s，每用户却只有约 35.7 token/s。这说明“总吞吐增大”与“单用户更快”不是同一指标，超过延迟约束的吞吐不能拿来证明单 token 成本下降。

测量顺序建议：先定模型、精度、输入/输出长度分布、并发和质量门槛，再观察显存占用、HBM 流量、kernel 启动空隙和通信占比；最后比较相同 TTFT/TPOT 服务目标下的成功输出 token/s 与每小时全系统成本。这里只给方法，不虚构任何真实降本百分比。

2. FlashAttention 家族：菜不落地，流水线不断粮

2.1 FlashAttention 1（2022）：不把整张注意力表搬回仓库

普通实现先写出 QKᵀ，再做 softmax，再乘 V，N×N 中间表反复经过 HBM。FlashAttention 将 Q/K/V 切成片上可容纳的小块，每块维护局部最大值、指数和与加权输出，用 online softmax 把它们合并，最后写回结果。像一边称量、一边累加，不需要把所有中间小票铺满地板。它保留全注意力的数学语义，计算复杂度仍是二次；核心节省是中间存储和 IO，浮点顺序可有差异。训练反向还可能用额外重算换更少 IO，尤其不能说“FA1 的加速来自 FLOPs 减少”。[42][89]。

适用与反例：较长 prefill 是直观收益场景；若请求时间主要耗在 MLP、网络或排队，attention kernel 加速不会同比变成端到端加速。FlashAttention 也不自动缩小需要长期保存的 KV cache；它消除的是注意力中间矩阵。成熟度：基础机制已广泛实现，具体设备与 dtype 支持依后端核对。[42][48]

2.2 FlashAttention 2（2023）：把活分到更多厨师手里

FA2 针对 FA1 的并行度与线程分工：减少非矩乘工作，把单头的 query 序列切给更多 thread blocks，提高 occupancy；改进 warp 内分工，减少共享内存交换。不是换一道模型，也不是只“再压缩一次显存”。论文 A100 上的特定 attention/训练结果不能直接作为任意推理服务的倍数。[43][90]。

边界：batch、head 数、序列长度、head dimension 决定任务是否足够填满 SM。更碎的工作也需要归并开销。与 KV 分页可以互补：一个优化片上工作分配，一个决定 KV 在 HBM 哪里存；实际需要支持两者的融合实现，不能把两个库名称相加就宣称收益相乘。成熟度：生产基础选项。[43][48]

2.3 FlashAttention 3（2024）：切菜、炒菜、上菜重叠

Hopper 的 Tensor Core 与 TMA 支持异步工作，FA3 用 warp specialization 将搬运与计算分工，再交叠矩阵乘与 softmax；另有面向 FP8 的分块量化与数值处理。比喻是下一锅备料时，上一锅正在炒，另一组做调味。论文在 H100 80GB SXM5、FP16 的实验中，相对 FA2 验证了 attention forward 加速；这属于特定 shape、精度和后端的算子比较，不是整套服务的成本倍数。[44][91]。

边界：Hopper 优化不能直接等同于所有 GPU 优化；FP8 路径须独立验证误差。机制与分页、批处理互补，但框架需提供相符的 shape、cache layout 和 graph 路径。成熟度：硬件适配型生产内核，具体功能应按版本验证。[44]

2.4 FlashAttention 4（2026）：新厨师太快，调味台成了瓶颈

FA4 于 2026-03-05 发表。Blackwell 矩阵单元增长快于指数运算和共享内存带宽，瓶颈转移到非矩乘单元。FA4 重排完全异步的 MMA 流水线；交叠两组 tile 的矩乘/softmax；把部分指数运算分给 FMA 多项式近似；条件性跳过不必要的 softmax rescaling。反向使用 TMEM 和 2-CTA 降低共享内存流量/原子归约，这一反向收益不能算进纯推理。它使用 CuTeDSL，缩短编译周期，但编译时间下降不是请求运行时同倍加速。[45][46]。

原论文在 B200 BF16、序列长度 1k–32k 且总 token 数固定为 32k 的 attention 前向测试中，优于论文选定的 cuDNN 9.13 与 Triton 基线；但论文图4也指出，较新的 cuDNN 已采用许多相关技术，达到与 FA4 相近的表现。因此应按实际部署版本比较，不能按技术名称选择永久冠军。[45] 工程趋势：PyTorch 同日提供 FlexAttention+FA4，将自定义 score/mask 与 block sparse 变体接入该流水线；发布时要求较新的 nightly 与 FA checkout，提示代码仍在演进。成熟度：已公开实现与框架集成，仍要逐版本核实兼容性。[58]。

截至 2026-09 的探索分支：独立作者的《Hardware-Aware FP4 FlashAttention-4》把 score 直接转成 FP4 概率操作数。Direct-P 的最高 2.13× 是 GB200 上有利 shape 的非因果 forward 比较；不是通用自回归 decode benchmark，也不代表全模型 FP4。该预印本同时披露测试中的 MXFP4 P/V 分布式训练轨迹发散。应标为数值与硬件协同的实验前沿，不能写成官方 FA4 已保证的普适能力。[57]。

3. Kernel fusion、CUDA Graphs 与编译：别让工单比做菜慢

Fusion 是把 RMSNorm、激活、残差或矩乘 epilogue 等相邻操作合成较少 kernel，减少中间张量读写与 kernel 启动；不等于减少模型规定的主要矩乘。CUDA Graphs 是先记录一串 GPU 工单，再低开销重放，降低 CPU/driver 发射开销；本身不自动减少 GPU 计算量。torch.compile 可做图捕获、融合、代码生成与 autotune，reduce-overhead 模式借助 CUDA graphs 面向小 batch，可能付出额外 workspace 显存。[49][50]。

三步教程：先在 profiler 看数十个微小 kernel 间是否有 CPU 空隙；再比较融合前后 HBM 读写与 kernel 数；最后把稳定执行路径 graph capture，并测冷启动/预热之外的稳态表现。若每个请求 shape 都变，重编译、padding 或多份 graph 的显存成本可能抵消收益。若主要算子本来已很大，减少启动的占比自然较低。成熟度：生产基础设施，但“开一个开关所有场景都更快”不成立。[49][50]

教学算例：假设执行 30 个微 kernel，每个计算 2 μs、发射空隙 3 μs。串行估算 150 μs；消除大部分空隙最多回收 90 μs，这个上界不代表减少了 60% 模型运算。若另有 3 ms 大矩乘，局部优化对整步只贡献约 3% 的量级。数字为自制，用于解释 Amdahl 效应。

4. FlashInfer（2025 论文）：给不同订单自动分工

FlashInfer 面向 serving 的实际动态性：请求长短不一，KV 可以连续、分页或共享。它以可组合布局和 block-sparse 表达适配 cache，plan 为变长任务建立负载均衡工作队列，run 执行；通过固定 grid、workspace 指针等约束兼容 CUDA Graphs。CPU plan 不在 graph 中，但同一步的计划可跨层复用。像领班先把大小订单拆成均匀小单，再交给固定流水线。[48]。

成本路径：减轻长短请求造成的 SM 不均衡，保持 GPU 连续工作，减少多样布局的额外搬运。它不是模型压缩算法。收益受 scheduler 开销、请求形状与后端组合影响；同名 FlashAttention kernel 不等于端到端 engine 相同。论文中的框架集成和实验支持其工程成熟度，但本文不把单一 benchmark 百分比外推到全行业。[48]

5. PagedAttention（2023）：按页发笔记本，别给每桌预留整本

假设餐厅给每桌预留 100 页笔记，实际只用 11 页，剩余纸虽然空着也不能分给别人。PagedAttention 把 KV 切成固定 token 数的小块，通过 block table 将逻辑连续映射到物理不连续位置；随着生成按需增配；相同前缀/分支可共享块，写入分叉时 copy-on-write。它主要消除预留浪费与外部碎片，最后一块仍可能有空位，并未把每个 K/V 数值变小。[47][92]。

原始教学例：最大长度 100、实际长度 11，每页 4 token。整段预留占 100 槽，分页占 12 槽，其中 1 槽浪费。这个差距仅说明该假设下的分配效率，不是任意 vLLM 的实测节省率。小块降低尾部浪费，却增加页表管理和潜在访存开销；大块反之。

何时降本：内存不足原本限制并发时，腾出的 HBM 能装更多请求，摊薄权重读取与设备成本。若只有一个短请求且显存富余，分页通常不是最大瓶颈。它和 continuous batching、prefix caching、KV quantization 互补；实际速度受分页 kernel 的内存合并能力限制。成熟度：生产基础设施。原论文 2–4× 是对当时 FasterTransformer/Orca 的系统比较，不应对现代优化后基线重复套用。[47]

6. KV 优化必须分成四件事

6.1 Prefix caching：不重读大家共有的菜单前言

新请求与已缓存请求拥有相同前缀时，复用对应 KV，跳过该前缀 prefill。它复用的是计算状态，不是复用上一次答案；不会免除后续每个 decode token 对保留 KV 的注意力访问。相同后缀但前文不同一般不能直接复用，因为 KV 依赖前文和位置。[47][54]。

三步：把稳定 system prompt/文档放在前部；按真实前缀一致性命中块；让请求调度落到拥有缓存的位置。后一步是缓存亲和的工程推论，需要与负载均衡折中。适合多轮对话、同文档多问；随机独立短 prompt 或长输出负载收益有限。持久 KV 会占容量，缓存替换与隔离也是成本组成。成熟度：生产基础选项；本节引用的是固定历史版本的机制说明，不是宣称当前开关默认值。[54]

6.2 KIVI（2024）：把笔记写得更紧密，保留内容

KIVI 根据 K/V 不同的数值分布采用两种分组：K 在每个 channel 内跨一组 token 共享量化参数；V 在每个 token 内对 channel 分组量化。最近或尚未凑满组的数据保留在高精度 residual 区域。它减少 KV 字节与读带宽，但有量化参数、残差区和反量化开销，且数值是近似的。[51][93]。

不能误算：16bit→2bit 只是 payload 位宽比 8:1，不等于整个服务显存缩小八倍。权重、workspace、scales 都还在。论文在单 A100 80GB、Llama-2-7B 及其 ShareGPT 合成负载中，通过扩大可容纳 batch 提高吞吐：对照 FP16，两种 residual 长度为32/128，平均输入161、输出338 token，各自增加 batch 直至容量上限。这不是固定 batch 的同倍率延迟改善。短上下文或权重带宽占主导时，新增反量化可能未被足够的 KV 节省抵消。成熟度：KV 量化已进入工程栈；KIVI 极低位配置仍需任务与 kernel 联合验证。[51]

6.3 H₂O（2023）：只保留常翻的旧笔记和最近几页

H₂O 动态累计注意力相关的重要性，保留历史 heavy hitters 与近期 token，淘汰低价值 KV。它减少保存/访问的 token 数，改变可用上下文，因此属于有损选择，和数值量化不是一回事。[52][94]。

三步：给 token 维护访问重要性；固定预算在历史重要部分与近期部分间分配；超预算时驱逐。危险反例是先前少被注意、最后才被问到的合同条款或密码。重要性统计本身有成本，而且读取 attention 分数可能要求定制 FlashAttention kernel。成熟度：研究和受控工作负载优化；不能用平均困惑度替代长程检索、代码准确率等质量测试。[52]

6.4 StreamingLLM（2023）：保留开场锚点，让窗口持续滚动

只留最新 token 的简单滑窗，在超出窗口后可能破坏某些预训练模型；StreamingLLM 保留初始 attention sinks 加近期窗口，维持流式语言建模稳定。它让服务可持续处理更长输入流，但被丢弃的中间内容并没有仍以完整 KV 保存。[53][95]。

教学反例：可以稳定接着聊很多轮，不意味着能逐字找回 200 轮前被淘汰的订单号。需要历史检索时，应保留或恢复相关证据，或选择真正支持该上下文的模型/系统。若模型原生训练使用 sliding-window attention，应遵守其层级与全局注意力设计，不能把任意全注意力模型的窗口砍短当无损优化。成熟度：流式方案已清晰，应用质量边界必须显式说明。[53]

7. Context Parallel：多人分读同一本书，不是每人各复印一本

Ring Attention（2023）：各设备负责一段 query，KV 块在环中传递，边接收边做 blockwise attention，并正确合并 softmax 统计。它扩展单请求可处理长度，没有删除注意力连接；通信被完全掩盖需要块计算时间足够长。名称里的 near-infinite 不是免费无限注意力，密集 attention 总算量依然随长度二次增长。[59][96]。

2024 的推理专用演进：《Context Parallelism for Scalable Million-Token Inference》区分 pass-KV 与 pass-Q，在 full prefill、已有 KV 的增量 prefill、decode 等情况下选择传较小/更合适的对象。教学上，整班各写一章时交换参考资料合理，只问一句时把问题发给持有资料的人更合理；真实算法还要处理归约与掩码。[61][97]。

2026 的工程重点 DCP：GQA 的 KV heads 少于 TP ranks 时，按 head 切已经切不动，KV 会重复；MLA 的共享潜变量也有此问题。DCP 沿 sequence 分 KV，传 query、分别算局部 attention，再用 log-sum-exp 统计合并正确输出。2026-08-07 的 vLLM 官方文给出近期实现与长上下文 agent 工作负载，说明焦点从“能装下”转为“相同 GPU 组装下更多并发请求”。[60]。

成本与边界：去掉冗余副本和缩短每卡 KV 扫描可降本，但通信、归约、跨节点尾延迟要计入。单短请求、弱互联或已经没有复制浪费时收益可能变小。与 MLA/GQA、分页、KV 量化互补，不过越压缩 KV，越可能让通信占比上升。成熟度：已有生产框架支持的条件性选项，不是所有 model/backend/MTP/PD 组合自动兼容。[60]

8. CPU/GPU/磁盘异构：扩大资源池，不能把慢路当快路

8.1 FlexGen（2023）：把仓库也纳入计划，追求批量产出

FlexGen 将 GPU、CPU、磁盘的存储/计算纳入放置与访问规划，通过线性规划搜索方案，并结合压缩与大批次复用。它原本面向延迟不敏感的批量任务。权重只搬一次却供很多样本使用，可摊薄 PCIe/磁盘 IO；若每生成一个 token 都需反复从慢存储搬大量权重，单用户延迟可能极差。[55][98]。

论文在16 GB T4 加208 GB CPU内存的平台，以4bit压缩和大批次完成 OPT-175B 离线生成；输入512、输出32 token 的示例批次耗时可达数千秒。该压缩方案把权重与 KV 装入 CPU 内存，避免磁盘卸载。这说明资源受限下能够运行大模型，不构成在线交互可用性的证据。成熟度：有实现的研究方案和离线场景参考；核心贡献是资源受限下可运行且提高批处理吞吐，而非任意云端推理通用替代品。[55]

8.2 PowerInfer（2023 起）：热工具放灶边，冷工具留后厨

PowerInfer 利用神经元激活稀疏性与热点分布：高频神经元权重放 GPU，冷神经元留 CPU 计算，用预测器判断当前需要哪些神经元，再合并结果，避免把所有权重搬进显存。和 FlexGen 的层/张量级放置相比，它将放置/计算细化到神经元。[56][99]。

关键前提：模型存在可利用的稀疏性和足够集中热点，CPU 算冷部分不能拖慢关键路径；预测错误也要测质量。修订全文包含 SwiGLU 评测，不能说“只适用 ReLU”；但报告对 SwiGLU 的收益显著弱于高稀疏 ReLU 族。更换激活函数或使用专门模型属于模型条件变化，不能与同模型无损 serving 优化混为一谈。成熟度：个人设备与稀疏模型的条件性方案，不代表任意数据中心异构池都能得到相同倍数。[56]

异构池化的通用自制算例：某 GPU 作业 8 ms，其中每步必须搬 1 GB，链路有效 25 GB/s 就至少增加约 40 ms 传输，除非重叠/复用/减少搬运。多一块廉价设备并不自动降低每 token 成本；应优化的是“每次搬运能服务多少有用计算”。这个算例可配交互滑块演示链路带宽和批量复用的临界点。

9. 可直接用于教程的发展图谱

下列箭头表示“技术问题推动/可组合”，不意味着每条都存在论文继承关系；年份为上文已引文核实的首次论文节点，2026 工程节点另标。

该分支已汇入交互发展图谱；原始Mermaid保留在研究稿中。

10. 完备性与理解性复核

本模块已覆盖：读权重/读 KV/算力/发射/通信五类瓶颈；无损语义重排、数值近似、上下文淘汰三种不同质量风险；单 kernel、单卡服务、多卡序列并行、CPU 卸载四种边界。未在本模块展开的权重量化、MoE、投机解码、PD 分离、全局调度和计费经济性，需要由总教程其它章节承接，不能据本模块宣称全栈已完备。

容易讲错的十二处已显式补正：FA 不等于线性算量；FA 不自动缩 KV；融合不等于删矩乘；graph 不等于动态请求被静态化；PagedAttention 不等于量化；prefix 命中不等于 decode 零成本；KV 2bit 不等于总显存八分之一；H₂O/滑窗不等于无损长程记忆；Ring 的零额外开销有重叠条件；DCP 与 TP 不同；offload 的容量收益不等于延迟收益；2026 FP4 探索不能外推到普遍自回归部署。

用于 HTML 的理解检验：①给出三个场景让读者选技术：单人短回答→启动/权重搬运；同文档多人问答→prefix；长历史并发显存不足→分页、KV 压缩、DCP。答案必须补充“先测实际瓶颈”，允许场景有多个解。②演示四页 KV：拖动页面体现分页，改变位宽体现量化，删除页体现驱逐，连线体现共享；让读者直观看到这四项完全不同。③在每张优化卡展示“省了哪种工作、付出了什么、什么条件会失败”，避免只有比喻没有机制。

教程的可理解性验收题

读完后应能回答：显存剩余很多却生成慢，为什么增加分页技巧可能帮助有限？量化之后 batch 上限提高，为什么单用户延迟仍可能变差？共享一段文档的 KV 后，为什么每个新问题仍要读它？给更多 GPU 分摊长上下文，为什么便宜的低带宽网络可能让成本更高？答案分别指向瓶颈识别、吞吐与延迟折中、缓存的计算边界，以及通信成本。若读者只能背出技术名称而无法解释这四个场景，就需要回到对应动态图补上“优化前的数据流—优化后的数据流—剩余工作”。

Token 工厂：模型与算法层的降本机制、教程与演进

研究截止：2026-10-02。此稿只覆盖模型结构、数值精度、生成算法；调度、异构池化、网络与算子由主报告整合。最新已读、带明确发布日期的一手进展为 2026-09-10 DeepSeek-V4.1-Flash 官方发布与模型卡。技术报告、官方工程文档、作者仓库分别提供算法机制、实现支持和可复现入口；都不自动构成第三方生产成本证明。

1. 先明确降的是什么成本

把推理看作印刷厂：模型权重是印刷机的模具，KV cache 是当前订单的工作记录，算力是压印动作，HBM 带宽是搬运通道。Prefill 先读完订单；decode 逐 token 出货。三种改动作用不同：量化让模具与记录更轻；注意力结构让每次少翻记录；推测解码让一次搬模具尽量多产几件。

本稿的判断框架（分析推导）：

单个合格输出 token 成本 = 统计窗口内的总服务成本 / 满足质量与延迟要求的输出 token 数

如果设备数量、单价与运行时间不变，有效吞吐从 100 提到 150，单位成本才近似降到原来的 100/150。若加速需要第二台机器、输出更多无用思考、让质量下降后重试，就必须重新计账。显存缩小、FLOPs 减少、单请求变快、集群降本是四个不同结论。

一个有用的近似是：一次 decode 时间 ≈ max(需要搬的字节 / 有效带宽, 需要算的 FLOPs / 有效算力) + 未被隐藏的通信和调度时间。它是选实验的简化模型，不是所有内核的严格时延公式。小 batch 常值得先减少权重搬运；长上下文要关注 KV；大 batch 可能更需要低精度矩阵运算；MoE 多机还要关注通信。

2. 量化：给数字换更小的包装

2.1 必须先分清五个概念

W4A16 表示权重 4 bit、激活 16 bit；W8A8 表示两者均为 8 bit。KV 精度另算，不能由 W/A 标签推断。PTQ 是训练完成后校准量化；QAT 是训练时让模型适应量化误差。GPTQ/AWQ/SmoothQuant 是生成量化模型的算法，INT4/FP8/NVFP4 是数值表示，Marlin/CUTLASS 等是执行它们的内核。不能拿不同类别的名字当互斥选项。官方服务框架还按 GPU 架构、量化格式与算子设置支持矩阵。[33]

教学算例：只算裸权重，70B 参数 × 2 字节 = 140 GB，4 bit 则为 35 GB。但真实显存还包括 scale、少数高精度层、KV、工作空间、碎片和通信缓冲，因此不能由 35 GB 直接断言“一张 40 GB 卡足够”。

2.2 GPTQ：一边取整，一边补偿邻居

痛点与比喻：把精密零件都就近换成标准尺寸，单个误差不大，组合起来机器却可能失准。GPTQ 不只逐个取整，还调整尚未取整的邻件以补偿总体偏差。

机制：2022 年 GPTQ 用少量校准输入构造层输出重建问题，目标是让 量化后的 W × X 接近 原来的 W × X；借近似二阶信息评估参数相关性；按列/块量化，把误差传给未量化部分，再用批量更新与稳定的分解方法控制离线成本。它主要压缩权重，原论文明确不把收益解释为乘法本身变快。[17]

成本因果：更小的权重 → 少占 HBM、少读权重 → 原先受权重带宽约束的 decode 更容易加速，也可能减少模型并行卡数。失效条件：校准分布失配、超低 bit 破坏质量、缺少融合反量化内核，或大 batch 已经算力受限。关系：与 KV 量化互补；和 AWQ 常是同一权重压缩任务的替代配方，不能把两个论文的倍数相乘。成熟度是“框架已有实现、需要逐模型验收”，不是“所有 GPTQ 模型必快”。[17][33]

2.3 AWQ：先保护真正敏感的通道

比喻：打包一箱仪器，敏感部件应有更精细的垫片；不能只看部件本身大小，要看它承担的负载。AWQ 通过激活统计识别重要权重通道。

机制：2023 年 AWQ 先观察校准激活，找出容易放大量化误差的通道；对权重放大、对应输入反向缩小，量化前的数学乘积保持相同；搜索合适 scale，使低精度取整后的误差较小。论文用少数权重保持高精度的实验说明“敏感性”，最终方法并不是简单留下 1% FP16 参数。配套 TinyChat 还做权重打包、实时反量化与算子融合。[18]

因果与边界：W4A16 对小 batch、权重搬运占主导的场景有吸引力；它不会自动把激活或 KV 降到 4 bit。别把相对 Hugging Face FP16 的 TinyChat 加速，直接搬到已高度优化的服务引擎。新领域、多模态、长推理仍要做任务级质量验收；格式装得下不等于吞吐更高。AWQ 与 GPTQ 都可配合分页 KV、批处理与推测解码，但后者节省搬运后，前者的边际收益可能变小。[18]

2.4 SmoothQuant 与 FP8：从“少搬”走向“低精度也能算”

SmoothQuant 比喻：一班学生中有少数人特别高，统一缩放会让多数人只剩几个可分辨刻度。把异常大的激活通道缩小，并把相应比例移到权重，能让两侧更适合低精度表示。

机制：2022 年 SmoothQuant 用离线等价缩放平衡权重与激活的动态范围，再做 W8A8 INT8 矩阵乘法；不是删掉异常值，也不是训练一个新模型。收益可能同时来自容量、搬运和原生 INT8 运算。过度把困难转移到权重也会出问题；应依据校准结果选平滑程度。[19]

FP8 的意义是用指数表示更宽的动态范围，并在支持硬件上执行低精度矩阵运算；仍需 scale、校准、选择保留高精度的敏感部分。推理结论：吞吐优化应比较 W4A16 和 W8A8/FP8 在目标 batch 下的实测，不能假设 bit 越少就越快。框架支持 FP8 存储、回退执行和原生 FP8 运算也不是同一个能力。[33]

2.5 NVFP4 与 QAD：连包装标签也一起设计

比喻：把全仓货物共用一把粗尺，容易误伤小件；给每小箱自己的细尺，再给全仓一个总比例，会更准确。NVFP4 用 E2M1 表示数据，每 16 个值共享 E4M3 FP8 scale，另有每 tensor 的 FP32 scale。按主数据与块 scale 算为 4.5 bit/值，并非恰好 4 bit，所以相对 FP16 的裸数据压缩约为 16/4.5，而不是精确 4 倍。MXFP4 的典型块长与 scale 编码不同，两个“FP4”不能混称。[23]

机制步骤：分块 → 求 scale → 数值映射到 FP4 → 按硬件支持的布局打包 → 原生内核执行 → 验证任务质量。低精度存储允许权重更大或 batch 更大，原生低精度运算有机会增加吞吐；但峰值 FLOPS 的提升不是端到端加速，也不是单位美元降幅。[23]

2026 年 QAD 进一步处理小模型 PTQ 后质量受损：冻结原 BF16 教师，让量化学生匹配教师输出分布，以 KL 散度作为训练信号。它是精度恢复流程，不是“无训练的更好量化”；离线训练和数据费用需要摊销。官方发布了 Nemotron 量化 checkpoint 和训练示例，支持“有可运行交付”的判断，不能据此认定任意模型均近乎无损。[24]

2.6 KV 量化：压缩随对话变长的工作记录

只压权重，长上下文仍可能被 KV 占满。KV 量化把缓存的 K/V 用更少 bit 保存，读取时按 scale 使用。它与权重量化作用对象不同，适合单列实验；框架文档列出不同校准办法、可跳过的敏感层和各类缓存格式。[39]

教学推导：如果原显存里权重 40 GB、KV 40 GB，权重砍半后总量仍是 60 GB；再把 KV 减半才到 40 GB，且尚未算其他开销。KV 变小优先释放容量、允许更长上下文或更多并发；若注意力计算仍先反量化，单请求时延不一定同比下降。需要检查长距检索、代码复现、工具参数等精度敏感任务。低 bit、MLA 与稀疏注意力可组合，但每一层压缩都可能消耗额外质量余量。

3. 从 MHA 到 GQA、MLA：少存什么，而不是只换包装

3.1 MQA/GQA：多位读者共用几份档案

MHA 每个 query 头各有 K/V。MQA 让所有 query 头共用一组 K/V；GQA 折中，让每组 query 头共用一组。比喻：32 位研究员无需各自保存完整档案，可以分成 8 组共享，但每人仍提出自己的问题。2023 年 GQA 论文还研究把已有 MHA checkpoint 转换、再训练的路径；不是改一个配置就能无损使用旧权重。[20]

教学公式：KV 字节 ≈ 2 × 层数 × token 数 × KV头数 × 每头维度 × 每元素字节，其中 2 对应 K 与 V。假设层数、维度和精度不变，KV 头从 32 到 8，KV 主体为原来的 1/4；query 头与其他计算并没有一同缩小 4 倍。收益通常来自 KV 容量与读取，代价是表达能力约束，需要训练补偿。与 KV 量化乘在不同维度，但“缓存缩小倍数相乘”仍不等于端到端速度相乘。[20]

3.2 MLA：保存压缩底稿，读的时候换一种计算方式

比喻：传统办法保存每位研究员展开后的完整笔记；MLA 保存一份短底稿，各人的投影规则留在模型中。它是学习到的数值隐空间，不是自然语言摘要。

机制：DeepSeek-V2（2024）把 K/V 联合投影到低维 latent；decode 缓存该 latent，加上单独的位置相关 key；把上投影矩阵吸收到 query/output 侧的计算，避免每一步重新展开所有历史 KV。解耦 RoPE 很关键，否则位置变换夹在矩阵之间会妨碍这种吸收。[34]

因果与边界：每 token 每层保存的元素从 2 × 头数 × 头维度 变为 latent维度 + RoPE维度，直接降低缓存容量与访问；同时改变计算形状，因此需要专用内核和 prefill/decode 路径选择。不是任意已训练 GQA 模型的开关，也不能只把所有层 KV 拉低秩后假定质量保持。与分页管理互补；与 GQA 是架构选择上的不同方案；与更低精度可以组合，但需重新做数值验收。[34]

4. MoE：每件产品只叫来部分专家

比喻：医院有许多专科医生，一次就诊不用召集所有人。MoE 用路由器给每个 token 选择少量专家，加上共享专家，而不是运行全部前馈网络。DeepSeek-V3 报告的 671B 总参数与每 token 激活 37B 就是两种不同口径。[29]

机制与因果：路由打分 → 选专家 → 分发 token → 分组矩阵运算 → 汇合输出。与同等总参数的 dense 模型相比，活跃计算减少；实际应比较同等任务质量的 dense/MoE，而不是凭总参数造一个不公平基线。专家权重通常仍需驻留或可及时取到；不同 token 选择不同专家，batch 大后访问集合也会变大。失败原因：热门专家拥塞、小专家 batch 算不满、跨卡 all-to-all、低负载却保留大量卡。V3 的推理部署章节专门处理专家放置和冗余专家，说明“稀疏计算”必须由系统兑现。[29]

工程推导：MoE 与专家并行、负载均衡、通信重叠强相关；与量化可互补。但把专家散在慢网络异构卡上，可能用省下的计算换来更昂贵的等待。总参数决定存储压力，活跃参数只是计算压力的近似指标，二者不能互换。

5. 推测解码：学徒先写，师傅批量审

5.1 精确 speculative decoding 的关键不是“猜中就过”

比喻：老师逐字写很慢，学徒先起草 4 个字，老师一次看完；通过的一段一起交付，遇到错误才纠正。GPU 一次验证多个候选能复用权重读取，利用单 token decode 尚未用满的计算能力。

步骤：草稿模型按分布 q 起草 → 目标模型并行算候选位置的 p → 逐个按接受规则检查 → 第一个拒绝点从修正残差分布采样 → 丢弃其后候选并继续。标准算法中接受概率为 min(1,p(x)/q(x))，拒绝后的分布校正是保持目标采样分布的关键；贪心推理则可验证 argmax 一致。它保障的是理想算法下目标分布，不意味着固定随机种子时文本字节完全一样。[31]

教学成本模型：每轮平均交付 A 个正式 token，草稿/验证/管理耗时分别为 Td/Tv/To，则每 token 时间约 (Td+Tv+To)/A。当它大于普通 decode 的 Tb 时，推测反而亏损。这解释了为何要同时记录接受长度、草稿耗时、验证耗时和 KV 占用；不能只优化接受率。草稿太强、太长、目标 batch 已经很大或任务不易预测，都可能失效。

“无损”只相对于被验证的那个目标模型；把目标量化之后，它相对原 BF16 的质量变化仍存在。复杂采样处理、工具约束和数值误差也需由实现验证。这是成本和正确性两个实验。

5.2 EAGLE-3：让学徒学会读老师不同层次的线索

早期外置小模型独立起草，EAGLE 系列利用目标模型特征。EAGLE-3（2025）融合多层特征、直接预测 token，并通过 training-time test 缩小训练与实际起草过程的差异；它需要对应目标模型的草稿训练与运行时支持。[21]

有条件的证据：论文 SGLang v0.4.4 实验使用单 H100、Llama-3.1-8B-Instruct、MT-Bench、链长 3、无树结构；batch 64 的吞吐为无推测基线的 1.38 倍。这比泛称“最高 6.5 倍，所以成本降 85%”更可用。若相同资源、相同时间和 SLO 下都成立，1.38 倍吞吐对应的理想单位成本比例约 1/1.38，但论文没有替用户证明这些生产条件。[21]

作者仓库提供训练与推理入口，可证明不是只有摘要的方案；成熟度仍应按目标模型、运行时版本和负载评估。量化会减少目标模型的搬运时间，因此可能降低推测的额外收益；同样可能腾出空间容纳草稿，两种效应需实测。[22]

5.3 MTP：训练时就培养“向前看”的分支

MTP 让模型训练时预测多个未来 token。DeepSeek-V3 的附加模块按因果链依次预测，并共享 embedding 与输出头；推理时可以不用，也可以作为推测草稿，再由主模型验证。不要把“多 token 训练目标”当成“自动一次生成所有正确 token”。[29]

取舍：相比额外训练独立 drafter，它能复用主模型表示与已有分支；但模型必须有匹配权重，服务引擎要支持相应架构。vLLM 有专门 MTP 文档，说明存在部署路径，并不等于所有 MTP checkpoint 都支持所有量化、并行和缓存组合。[38]

6. 少看历史：稀疏注意力、压缩注意力与线性状态

6.1 DSA：先查目录，再读精选页

FlashAttention 类方法是在不改注意力数学结果的前提下少搬中间结果；稀疏注意力则改变本次要读哪些历史位置。DSA 的 lightning indexer 先便宜地评分，再选择少量 token 给昂贵主注意力；其训练需让 indexer 学会与主注意力对齐，并让模型适应稀疏模式。[30]

核心边界：报告中主注意力复杂度由 O(L²) 到 O(Lk)，但索引器本身仍有 O(L²) 部分，只是常数和精度更低；不能声称整个模型严格线性。文中每 query 选 2,048 个 KV token，短 prefill 还采用 masked MHA 路径。成本估计来自 H800 服务测量和每 GPU 小时 2 美元的假设，不是公开 API 售价、更不是任何硬件上的固定降幅。[30]

教学推导：越长的上下文，精选阅读越可能覆盖目录成本；短文档可能“查目录比读全文还慢”。选择性读取不等于可永久删除未选 KV，因为下一次查询可能需要另一页。必须分别测存储量、每步读取量、索引时间和任务质量。

6.2 2026 的压缩与稀疏合流：CSA/HCA

DeepSeek-V4 将“先合并几页记录”和“再选择重点记录”组合：CSA 对 token 维度压缩后做稀疏读取；HCA 更强地压缩历史，再配合局部滑窗保留近处细节。主 KV 与未完成压缩的尾部状态需要不同管理，并专门处理共享前缀与磁盘缓存。[28]

报告在 1M 上下文下，估算 V4-Pro 单 token 的等效 FP8 FLOPs 与 KV 量分别为 V3.2 的 27% 和 10%；这是指定模型、指定长度与精度口径下的资源比较，不是实测“账单只剩 10%”。它还说明 FP4×FP8 在现有硬件上的峰值能力并不自动高于 FP8×FP8，足以反驳“换 FP4 必有两倍算速”。[28][26]

分析：这是模型与缓存系统共同设计的方向。改了每层的缓存形态，页大小、前缀命中、状态回滚和跨设备搬运都要跟着改；不能把通用服务引擎的旧 KV 假设原封不动套上。

6.3 线性注意力：从逐页档案变成可更新的状态表

比喻：不是把所有历史记录带在身上，而是随时更新一张有限大小的状态表：读新信息、遗忘旧内容、修正关联，再按查询读取。状态大小可以不随序列线性增长，但容量有限，精确回忆大量细节更困难。

Kimi Linear（2025）用 KDA 的逐通道遗忘门和 delta 更新管理状态，配合 chunkwise 并行算法；每 3 层 KDA 配 1 层全注意力 MLA，在降低缓存的同时保留全局检索。论文明确指出纯线性注意力的长上下文检索是瓶颈，因此混合结构是有意的质量折中。[32]

边界：线性的是该模块对序列长度的某些成本，不是模型参数量、整个混合网络或所有硬件耗时。混合层仍保存历史 KV；新的 recurrent state 也需要缓存、回滚与前缀复用支持。它是模型架构选择，需要训练与部署实现，不能把 softmax 任意换成递归公式后期待同样质量。长上下文有吸引力，短输入下固定开销可能抵消收益。[32]

6.4 2026-09 的最新已核验方向：跨层复用与阶段不对称

DeepSeek-V4.1-Flash 的官方模型卡给出三项相关设计：CED 将因果 encoder/decoder 分工，prefill 与 decode 激活参数口径不同；CSA2 让不同层复用 KV 与稀疏索引，后续索引只在早期候选集合内工作；FP4 main-KV 与 SWA bounded replay 减轻缓存和持久化负担。还列出 DSpark 的半自回归草稿与按置信度安排验证。[27][36]

本次成功读取模型卡和发布页，也确认了[35]，但 PDF 正文抓取失败；因此这里只定性归入“已有官方模型交付的新架构”，不展开未读证明、不把模型卡的缓存指标变成独立成本结论。下一步关键验证是 CED 对输入/输出长度比例的敏感性、跨层复用的检索质量、以及状态重放和推测回滚能否协同。

7. 扩散与并行解码：同时填空，解决依赖

比喻：自回归像从左往右写句子；扩散解码像先铺满空格，再多轮填写、修正，允许一轮填多个位置。问题在于两个位置可能互相依赖，独立填对局部词不代表整句一致；双向状态随填空变化，也不天然兼容传统 KV cache。

Fast-dLLM v2（2025）把 AR 模型微调为块扩散，块间保留已完成历史、块内双向建模；用块与子块两级缓存，以及置信度阈值控制同时确认多少 token。它改变了生成模型，不具备标准精确 speculative decoding 那样对原目标分布的同一性保证。[25]

论文 GSM8K 实验中，7B 模型、阈值 0.9、子块缓存，在 A100/H100、batch 64 时分别报告相对 AR 基线最高约 1.5/1.8 倍吞吐。它是特定模型、任务与阈值的质量/速度比较，不是“任意聊天场景无损两倍”。官方仓库已经公开训练、推理和 checkpoint，2026 扩展到视觉语言及驾驶；但仓库仍把 vLLM 支持列为待推进项，不能由模型发布直接推出成熟通用服务集成。[25][37]

分析：并行生成要把分母记成最终交付 token，不能把多轮修正中过手的全部 token 算成产出。还应测首 token、流式交付间隔、质量、长尾请求和批处理公平性；块内吞吐快并不保证交互体验好。

8. 一张发展图谱：五条相互交汇的路线

下图是本稿依据所引论文整理的路线图，箭头表示问题与设计的延续，并不表示所有后项都严格继承前项代码或作者谱系。

该分支已汇入交互发展图谱；原始Mermaid保留在研究稿中。

9. 技术相关性与完备性复查

复查后补入了六个通常被漏掉的条件：量化中的 scale 与反量化开销；MLA 的位置分支；MoE 的总参数/活跃参数区别；DSA 索引器的剩余复杂度；推测的残差校正；扩散的缓存和输出依赖。这些都是“算法听起来正确，但落地账不对”的高发原因。

落地优先级是条件判断，不是统一排行榜：已有 dense 模型、小 batch，先测成熟 W4A16 与 FP8、分页/批处理，再测 EAGLE/MTP；长上下文服务先量清 KV 与 attention 占比，再评估 KV 量化和可用的高效架构；大规模 MoE 先把专家通信和负载打通；CSA2/CED、混合线性和扩散属于需要模型、内核和状态管理一起验收的路线。

“完备”在这里是覆盖主要成本因果与已确认路线，不能理解为囊括全部论文。蒸馏/模型路由、上下文裁剪、推理预算控制会改变工作负载或质量分配，主报告应另列；训练优化（如优化器）只有改变推理结构/质量成本前沿时才进入本技术地图，不能把训练提速直接算作推理降本。

Token 工厂的集群推理：调度、拆分、缓存与异构池化

检索截点：2026-10-02。本文聚焦 serving 与集群层；截至本次检索，最新明确日期的一手工程材料是 2026-09-22 的 LMCache Raw Block 文章，最新纳入的研究预印本发布于 2026-09-17。main 与 latest 文档表示检索时页面状态，不据此倒推功能发布日期。数值示例凡未标注论文实验，均为教学假设。

1. 工厂究竟在优化什么

把一次模型调用想成餐厅订单：prefill 是读完订单、备齐食材；decode 是持续一道一道上菜；KV cache 是已备好的中间材料；GPU 是灶台，HBM 是灶台边的工作台，网络是不同厨房间的运输通道。这个类比的边界是：模型在每一层有严格的数据依赖，不能因为还有空灶就随意把同一份计算交给任何设备。

应优化的主指标是：质量与延迟达标条件下，每个实际交付输出 token 的全成本。一个可复算口径是：

C_good = 一段时间的全系统成本 / 该时间内满足约定质量与SLO的请求所交付输出token数。

成本分子应包括租赁或折旧、电力、网络、CPU/内存/SSD，以及为峰值保留的空闲容量；分母不能把被拒请求、无用草稿 token、失败重试或超时产物全部当成交付。它是本文的经营分析口径，不是所有论文统一采用的指标。论文中的 goodput 也常按「达标请求/秒」计量，必须明确单位。DistServe 正是把 TTFT 与逐 token 延迟约束纳入服务容量优化，而不是只追求离线吞吐。[64]

一个纯教学例：系统 A 每小时花 100 元，产生 100 万输出 token，但只有 70% 属于达标请求，合格百万 token 成本是 142.9 元；B 每小时花 110 元、只产生 90 万 token，却全部达标，成本是 122.2 元。B 的原始吞吐更低，真实可交付成本反而低约 14.4%。

TTFT 是首 token 等待；ITL 是相邻 token 间隔；TPOT 常指首 token 之后的平均每 token 时间。平均 TPOT 很好不代表 p99 ITL 无卡顿。吞吐、时延、缓存命中与硬件利用率都应进入同一张账，而不能各自挑最好看的数字。

2. 从固定拼桌到每轮换客：continuous batching

痛点。 固定 batch 好比要求整桌人同时入座、等最慢的人吃完才能重新开桌。短回答结束以后，该请求的席位可能仍被浪费；新请求也不能及时补位。

技术流程。 Orca 把调度单位从完整请求缩小到一次模型迭代：执行一轮、移走已完成请求、补入新请求、再执行。其 selective batching 对不同操作采用不同批处理方式，解决当时不同请求进度造成张量形状不同的问题。这是后来 continuous/in-flight batching 的关键演进节点，不意味着今天所有引擎都仍逐字照搬其 attention 实现。[62]

自己算一遍。 假设三个位置里 A/B/C 还需 2/5/8 轮，固定方式提供 24 个「席位×轮」，有效工作仅 15 个；连续方式在 A、B 离开后补进 D、E，可以使用原本空掉的 9 个席位。这是填补空转的解释，并不是保证提高 24/15 倍：实际时间还受 batch 变化、上下文长度、KV容量与新请求 prefill 影响。

为什么降本。 同一次读权重与 kernel 启动服务更多实际 token，减少因为输出长度不一致而空耗的 GPU 时间。流量低到没有新请求可补时，收益自然消失。增加 batch 还可能拉长每轮延迟，并挤占 KV 显存；「batch 越大越便宜」只在尚未触碰延迟与容量边界时成立。

关联。 连续批处理管谁在这一轮上场；分页 KV 管这些人的状态如何分配；FlashAttention 管一轮中的 attention 如何执行。它们解决不同层次的问题，常可组合。成熟度：主流引擎中的基础能力，但调度政策与边界行为仍因引擎版本不同。

3. 把大单切片：chunked prefill 与 Sarathi-Serve

痛点。 即使每轮能换人，突然插入一份长达几万 token 的新订单，也可能让正在说话的用户停顿。大 prefill 与短 decode 混在同一轮时，单轮耗时差别很大。

Sarathi-Serve 把长 prefill 分成 token 块，以每轮 token 预算组织混合 batch，优先保证进行中的 decode，并用余量填 prefill。预算需根据模型与设备 profiling 确定：块太小，重复 KV 读取和启动开销增加；块太大，decode 卡顿重新出现。论文在 Yi-34B、TP=2 的分块实验中，512-token 小块带来的 prefill 时间开销最高约 25%，说明切块本身并非免费。[63]

形象流程。 每轮有 1,024 张「计算工票」，64 位老客各领 1 张来生成下一 token，剩余 960 张给新来的长订单。下一轮继续，而不是让 8,000-token 大单一次占住整个厨房。这个预算只是一阶控制量：64 个长上下文 decode token 与64个短上下文 decode token 的 attention 工作量不同，最终仍须量测每轮耗时。

降本条件。 高并发、输入长度混杂、输出需要稳定流式体验时，减少干扰可提高相同延迟约束下的可服务流量。纯离线长文处理、无逐 token 延迟约束时，完整 prefill 可能更高效。分块不是近似删除上下文，通常不改变模型语义；过小分块的主要损失是系统开销。

与拆分的关系。 这里是一个厨房内调整工作顺序；P/D disaggregation 是分成两个厨房。两者既竞争又可嵌套：P 池内部仍可分块，D 池也可在混合架构里承担少量 prefill。

4. 两个专业厨房：P/D disaggregation

机制。 Prefill 与 decode 分别在不同实例执行。前者完成 prompt 的 KV 状态并传给后者，后者从该状态继续生成。DistServe 联合考虑阶段并行策略、实例配置与放置位置；带宽受限时，布局必须确保关键 KV 传输走足够快的通道。它不只是加一台服务器。[64]

为什么阶段适合分工。 较长 prefill 往往能形成较大矩阵乘，计算密集；decode 在小批量下往往受权重或 KV 搬运限制。但这不是永久硬件属性：大批量、MoE、很长上下文或不同量化策略会改变瓶颈。Splitwise 据此研究 H100 做 prompt、A100 做 token 等搭配，也利用逐层传输隐藏一部分 KV 搬运。它还允许混合池缓解纯两池资源比例不匹配。[65]

一条完整请求的旅程。 路由器先检查已有缓存与两端负载；P实例读取输入并构造KV；传输层注册/组织缓冲并搬到D实例；D实例装入符合本地布局的页，接着生成；请求结束后释放活动页，值得复用的状态可留在缓存层。第一 token 可以由 P 端产生，因此搬运开销未必全部算在 TTFT：某些设计主要表现为第一与第二 token 之间的空档。测量必须覆盖整个流式过程。

4.1 拆分成本方程：先算账，再选架构

下面是教学分解式，不是对真实调度器的完整性能模型：

T_split = Q_P + T_P + T_X_visible + Q_D + T_D

T_X_raw ≈ 启动延迟 + KV字节数/有效带宽 + 布局重排 + 同步开销

T_X_visible ≈ max(0, T_X_raw − 可重叠部分)。

GQA/MHA 下粗略的单请求 KV 大小为：

S_KV = 2 × 层数 L × token数 N × KV头数 H_kv × 头维度 d × 每元素字节 b。

前面的2代表K和V；不能将 query 头数直接代替 GQA 的 KV 头数；该式也不直接适用于 MLA 压缩状态或混合状态空间模型。分片后每卡的数据可能减少，但跨池总传输量不能机械地再除一次卡数。

算例 A：搬运是否吃掉收益。 假设 L=32、N=8192、H_kv=8、d=128、BF16 的 b=2，KV 约为1 GiB。以20 GB/s有效带宽搬运需约54ms；以2 GB/s需约537ms，尚未加布局与排队。若拆分消除了200ms干扰，前一种网络有可能获益，后一种可能反而变慢。若上下文翻四倍，而其他条件不变，搬运也近似翻四倍。这些是十进制 GB/s 与二进制 GiB 换算后的教学值。

算例 B：买便宜的D节点有用吗。 假定旧合并池每小时成本120元、达标吞吐12万输出token，百万token成本1000元；拆分后P池35元、D池65元、网络与缓存10元，达标吞吐14万，成本约786元，降21.4%。但若实际流量只有每小时4万token且两套实例必须一直开，拆分要2750元/百万token；可缩到60元/小时的合并池只需1500元。峰值压测省钱，全天账单却可能更贵。

反例与成熟度。 少请求、短输入、弱网络、两池比例失衡、权重复制增加、P池显存闲置、D池缓存爆满，都可能抵消收益。vLLM 当前功能页仍标为 experimental，特别提醒拆分不直接提高 throughput；这与研究论文的 goodput 提升不矛盾：消除干扰与针对SLO配置资源，改善的是达标服务容量，不是凭空削减所有算术操作。[72]

5. 异构算力池化：统一派单，不是把显存倒进一个无限大桶

最重要的拆解。 「异构」至少有设备代际、厂商、内存层级、阶段角色四种差异；「池化」则至少有下面四种层次。它们不能互相替代。

这张表是对系统边界的教学归纳。两种设备都能运行 vLLM，不意味着它们能共同执行任意一个分布式 kernel；同属一个入口，也不意味着两端共享同一个虚拟地址空间。

5.1 一次异构派单的算法

以下是适合工程实现与实验的简化策略，不宣称是某一论文原样算法：

1. 能力过滤。 从池中排除装不下模型、缺少所需算子、精度或上下文配置不支持、模型版本不一致的设备。
2. 分阶段估计。 根据输入长度、预测输出长度、缓存命中、batch、设备，估算P时间、D时间与KV占用。
3. 列出路径。 同机P+D、A类设备P→B类设备D、已有缓存节点直接继续，都是候选；加入网络拥塞与数据重排代价。
4. 约束先行。 去掉预计违反TTFT/ITL、显存、安全隔离或拓扑约束的路径。
5. 按边际成本选择。 比较多接这个请求增加多少GPU秒、网络字节与排队，而不是只按设备租金排序。
6. 反馈修正。 用真实时延与命中率更新估计，迁移或扩容时计入预热和缓存损失。

举例：设备A租金每小时10元，处理某类请求每秒100输出token；B只要6元，但同类流量下只有40token/s。先忽略其他成本，A约27.8元/百万token，B约41.7元；便宜设备未必有便宜token。反过来，若B专门decode能达到80token/s，它变成20.8元/百万token，阶段分工才体现价值。

5.2 为什么跨厂商比同厂商更难

需要逐项核对：同一模型权重/版本/tokenizer与位置编码；量化方法、scale和舍入语义；KV的dtype、维度顺序、页大小与头分片；CUDA/ROCm等运行时对应的算子覆盖；设备内存注册和网络传输后端；TP/EP组规模及collective实现；故障恢复与服务观测。传输层能送字节，只解决其中一部分。

一个已经落地的具体障碍是异构TP：P端TP=4与D端attention TP=1的KV布局不同。SGLang当前文档采用GPU staging buffer：P端先将KV头分片聚成连续缓冲，经RDMA批量传输，D端再散到本地KV页；该路径注明面向非MLA模型，不能对所有模型直接开启。这里「异构」首先是并行配置不同，并不自动等于跨GPU厂商。[73]

由此可以理解为何成熟方案常从「兼容同一模型的不同副本池」开始，再走向「跨设备阶段拆分」。一开始就把不同厂商卡混成一个细粒度TP组，通常更难解释和验证性能。这里是工程判断，不是说跨厂商TP在原理上不可能。

5.3 2026年9月的真实跨厂商案例

Cisco 2026-09-21的一手工程文章描述：8张NVIDIA H200做GPT-OSS-120B prefill，8张AMD MI350X做decode；两边使用兼容的FP8 KV布局，通过NIXL与UCCL的RDMA路径连接。这表明至少存在同一请求跨厂商P/D执行，已经超出「不同请求发给不同副本」的层次。[83]

MLCommons的公开汇总CSV可核对该配置：Cisco_UCS_H200x8_MI350Xx8_G200_2x2_TOR，Closed、Available、Datacenter、两节点16卡、vLLM；GPT-OSS-120B Server记录73,357.6token/s、MXFP4，accuracy exact_match为83.434658...。这里MXFP4是汇总精度标签，与前述FP8 KV不是矛盾，两者对应不同张量。[84]

Cisco正文以两套独立系统吞吐之和70,085.48token/s为基线，报告组合后达到104.67%；这个比较不能直接读成「token成本降低4.67%」，因为还缺价格、功耗、网络摊销与全天流量。相应详细run日志和系统JSON本次抓取未成功，不能补造p99数字或配置细节。MLCommons总报告中的厂商自述与公开结果表应分别标识：结果表能佐证提交成绩，自述提供实现说明。[7]

6. 把KV从一次性备菜变成可管理库存

6.1 缓存复用省的是哪些工作

若多次请求拥有相同前缀，已算出的前缀KV可以复用，减少重复prefill。共享一篇文档不一定就是相同前缀：它前面的指令、排列位置和上下文变了，KV一般也会变。普通精确prefix cache不能随意拼接任意旧文档KV；LMCache的非前缀复用借助CacheBlend进行选择性重算以恢复质量，应单独验证。[77]

库存有两种。 正在decode的请求所需KV是「活动工作集」；下一次相似请求可能复用的KV是「可复用库存」。把后者放到SSD再按需取回，与每生成一个token都把全部历史从SSD读一遍，是完全不同的性能路径。

缓存价值的教学判据：

预期收益 ≈ 再次命中概率 × 避免的prefill成本 − 存储成本 − 写入成本 − 取回成本 − 对其他热点的挤占成本。

一段KV算一次要150ms，取回只需20ms且很快会命中，值得保留；只要10ms就能重算，却要40ms从远端取回，命中也不代表划算。缓存命中率必须配合「命中后节省多少GPU时间」看。

6.2 Mooncake：围绕KV而不是围绕一台GPU组织集群

Mooncake把P/D拆分与全局KV缓存、调度结合，利用GPU集群中CPU、DRAM、SSD与NIC资源；核心不是无条件缓存一切，而是协调计算与状态驻留，遵守SLO。FAST 2025论文页报告长上下文场景与真实trace下的有效容量收益，部署数字属于作者系统，不应用于所有业务。[66]

Mooncake项目当前区分Transfer Engine与Store，并给出与vLLM、SGLang、LMCache等集成路径；2026-08的更新还覆盖ROCm工程和RL rollout数据移动。用于教程时，应把Transfer Engine解释为高效搬运通道，Store解释为状态仓库，而不是将两者都叫「推理框架」。[67]

6.3 分层缓存：台面、冰箱、仓库各司其职

GPU HBM留活动KV；CPU DRAM放近端热缓存；NVMe/远端放更大的可复用库存。LMCache当前还提供独立进程部署，使状态生命周期不必随引擎进程结束；但独立进程不等于自动持久化成功，恢复能力仍取决于具体存储后端。[77]

2026-09-22的Raw Block工程文章展示新方向：固定槽位、对齐直写、io_uring、设备端恢复元数据，让NVMe成为可恢复KV层。作者明确披露，一次Qwen2.5-14B、TP=2功能验证虽然有78/78次L2前缀命中，却尚未观察到查询TTFT优于预热。这是「功能正确」与「成本获益」不能混为一谈的很好案例。[78]

6.4 缓存感知路由：去有备菜的厨房，但别排两小时

Dynamo当前KV路由依赖worker发布缓存生命周期事件，以估算前缀重叠；没有事件时会退为以负载评分为主，或按配置预测缓存状态。其文档还明确把拓扑感知KV传输与普通副本选择区分开。[79]

可用下面的教学评分理解路由目标：预计完成代价 = 排队 + 未命中prefill + 状态搬运 + decode。A节点命中90%但排队2秒，B节点没有缓存但0.3秒完成prefill，不能盲目坚持A。共享前缀极热时要适量复制，否则缓存局部性会演变为单点热点；过度复制又浪费缓存。缩容与路由也会互相影响：关闭一台热点节点可能节省GPU租金，却丢失大量可复用KV。

7. MoE expert parallel：让专家少等快递

MoE像一个专科会诊中心：每个token先由gate选择少量专家，把激活dispatch给专家所在GPU，专家计算后combine回来。节省的是只激活部分专家的算术量；如果专家分散到多节点，all-to-all传输与负载偏斜可能成为新瓶颈。

DeepEP提供面向MoE dispatch/combine的高吞吐、低延迟通信kernel及低精度传输。检索时main已是V2/V2.5相关说明，明确指出EP dispatch/combine仍占GPU SM，不能把旧版本或其他collective的「零SM」表述套到所有EP路径；实验性PP/CP/DP/Engram能力也应与成熟EP功能分开。[70]

算法应如何拆开理解。 第一层是路由选专家；第二层是expert放置/复制，避免热门专家只有一个工位；第三层是打包、低精度搬运和批量dispatch；第四层是通信与GEMM交叠；第五层按拓扑选择机内高速域和跨机网络。它们共同决定 一轮时间≈计算关键路径+未隐藏通信+最慢expert等待。这是教学分解，真实执行存在更复杂的重叠。

例如四张卡原本每张处理25份工作，其中一位专家突然吸引60份，其余三张各约13份；总平均利用率不能消除最慢专家的等待。复制热点专家可改善，但增加权重驻留、同步及调度复杂度。把所有专家分到尽可能多的卡，也可能让小batch decode的通信超过计算。EP解决模型容量与专家并行，DP解决请求复制，TP解决张量切分，三者不能只用「多卡并行」一词带过。

8. 从手动配卡到SLO控制：Dynamo、llm-d与autoscaling

Dynamo Planner当前按队列、KV利用率与引擎性能模型调整P/D副本数量；SLA模式使用forward-pass estimates及在线FPM校准/回归，观测batch组成、token数、队列和轮次耗时。它说明控制面正从「GPU利用率高了就加卡」走向「预测当前请求能否达标」。[68]

llm-d当前架构以Router、InferencePool与Model Server划分职责，提供P/D、KV管理与预测时延信号。尤其要注意版本变化：检索时main文档已将WVA标为deprecated，描述的是EPP指标经KEDA Prometheus scaler创建/管理HPA的伸缩方式；旧架构图不能当作2026年现状。[69]

为什么普通CPU服务的伸缩直觉失效。 有的请求输入短、输出长，有的输入极长、只回答一句；同样「10个请求」的工作量完全不同。新增副本还需加载权重、编译/预热、准备KV，不能等到所有SLO已坏才启动。缩容要处理正在生成的请求，并考虑缓存迁移。控制回路需要升降阈值分离与稳定窗口，避免扩缩容震荡。以上为控制系统层面的工程推导。

建议的控制周期。 采集输入/输出长度分布、TTFT/ITL尾部、等待token数、KV容量与命中；用近期实际吞吐拟合每种设备/配置；计算满足目标所需P/D数量；加入启动时间与安全余量；执行后核对偏差。利用率是输入信号，不是唯一目标函数。

9. 2025—2026的新方向与证据边界

固定合并/固定拆分走向混合。 TaiChi（2025-08）通过P-heavy与D-heavy实例、不同chunk大小、长度感知prefill与流动decode调度，统一P/D合并和拆分设计空间。含义是「按SLO分配干扰预算」，而非宣布拆分已经过时；论文最佳配置仍依赖离线搜索和负载变化后的重配。[74]

异构资源配置走向联合优化。 2026-04初稿、2026-06-05修订的研究，把模型选择、GPU类型、TP/PP、路由、质量与预算约束联合建模，并以可行性过滤、贪心与局部搜索降低配置求解成本。证据主要是建模与仿真实验；求解器快很多，不等于每token计算快很多。[81]

伸缩走向可解释性能模型。 2026-09-17预印本用每轮固定开销、每token计算、每token KV访问三个参数构造近似排队模型。它在H100上验证Llama-3.1-8B/Qwen2.5-14B的平均时延，控制实验涵盖四倍流量变化；但报告的是控制周期均值而不是周期内p99，且单次运行没有方差估计。较少SLO违约还可能来自更多副本，不能直接当作降本证明。[80]

异构从API兼容走向状态兼容；缓存从内存优化走向存储系统。 Cisco跨厂商P/D案例证明特定格式与传输栈已可跑通；LMCache最新工程则表明，状态恢复、I/O对齐、生命周期和缓存价值开始与kernel速度同样重要。这是根据上述一手来源作出的趋势归纳，不代表所有厂商组合已经无缝互通。[83][78]

10. 技术演进与依赖图谱

该分支已汇入交互发展图谱；原始Mermaid保留在研究稿中。

图中实线表达「问题与能力的关联/依赖」，不是严格的代码继承关系，也不表示后者普遍替代前者。最有希望的组合通常是：单机高效kernel与分页KV作为底座，连续批处理填补空闲，以chunk或P/D控制干扰，再用状态复用和路由避免重算，最后以SLO控制面配置各类设备。

11. 完备性审查：还必须验证什么

技术完整性。 本文已覆盖批处理、干扰控制、P/D、异构层次、KV传输、复用与层级、路由、MoE通信、集群控制。整份token工厂教程还需与单机计算章节连接：量化/低精度、attention kernel、GQA/MLA、KV压缩、投机解码、模型路由与输出预算；这些不是本文已完整证明的内容。

相关性。 每个方案要能指向账单的一项：少算prefill、少读权重/KV、少空转、少传字节、少排队超时、少保留无效容量。只提高某个microbenchmark却没改善端到端达标吞吐，不能直接称为降低token成本。

可理解性。 读者应该能回答：长输入与长输出为什么需不同配置？命中缓存为什么仍可能更慢？多卡总显存为什么不是任意可用的单一显存？跨厂商同入口与跨厂商同请求有什么区别？P/D为何可能在高负载省钱、低负载亏钱？如果不能，优先重做这些边界例子，而不是继续堆术语。

必须补的实验矩阵。 相同模型与质量门槛，覆盖短入短出、长入短出、短入长出、长入长出；冷热缓存；低/中/饱和/突发流量；同构与异构；快/慢/拥塞网络；正常和单节点故障。报告完整SLO达标率、拒绝率、p50/p95/p99、实际GPU小时、网络与缓存资源，而非只给最高TPS。跨租户缓存还应检查命名空间、模型版本、权限与删除语义，避免错误复用。

结论强度。 Continuous batching是成熟基础；chunked prefill是广泛采用的调度手段；P/D与层级KV已经工程化，但收益高度依赖负载和拓扑；跨厂商P/D存在可核对的2026年基准案例，不能推成普遍即插即用；联合配置、混合P/D与模型驱动伸缩是活跃方向，理论/仿真/单次实验各自需要真实业务复测。

把技术接成系统：补齐边界与接口

DP、TP、PP、EP、CP：五种“多找人帮忙”

这些并行方式分割的对象不同。vLLM 文档提供单卡、张量并行、流水并行以及MoE部署的选择路径；具体可组合方式随模型与版本变化。[16]

教学推导：两张卡不是自动两倍速度。假设单卡计算10 ms，分两卡后计算5 ms，但同步通信4 ms，整体只有10/9≈1.11倍。如果通信6 ms，反而变慢。多卡首先可能解决“放得下”，其次才是“跑得快”，最后还要问“增加卡数后每token是否更便宜”。

P/D分离则按推理阶段分工，不等于按模型层分工的PP。异构设备可以先放到不同副本，也可以在P/D边界交接状态；若把它们塞进每层都同步的同一个TP组，最慢设备和通信约束往往更难处理。这是拓扑与依赖关系带来的工程判断，而不是对某个厂商的性能排序。

剪枝：删掉连接，还需要会跳过零的机器

SparseGPT（2023）把剪枝表述为层输出重建问题，选择哪些权重归零，同时补偿保留权重；还研究2:4等半结构化稀疏。[15]

类比是撤掉闲置工位：只有生产路线也跟着改，搬运员才会不再绕行。非结构化稀疏只是矩阵里多了零，通用dense GEMM仍可能照算；结构化剪枝删除整行、整头或整层，更容易映射到稠密内核，但表达能力损失和再训练要求不同；2:4等模式需要匹配硬件与库。

降本逻辑是减少有效乘法与存储，条件是稀疏表示/索引开销小于跳过工作所得收益。失效情形包括稀疏率不够、索引读取占带宽、低bit加剪枝共同损伤质量、服务引擎回退到dense。“50%权重为零”既不保证显存减半，也不保证成本减半。它和MoE的区别是：剪枝改变一个网络中的连接，MoE按输入动态选择子网络。

多租户与多LoRA：共享底座，不重复开整座工厂

LoRA用较小的低秩增量适配一个基础模型。S-LoRA 将基础模型计算与适配器增量计算分开批处理，按需把适配器从主存载入GPU，用统一分页管理适配器权重与KV，并配专门内核。[13]

类比是许多客户共用印刷机，只换各自的小版片。只有一个固定客户时，预先合并权重可能更简单；客户多且交错到达时，为每个客户启动一个完整模型副本会重复保存底座、分散batch。统一服务可减少这种重复，但适配器rank差异、切换、冷加载和租户隔离都需处理。KV缓存键必须包含适配器身份与版本；同样文字经过不同权重得到的KV不能直接互换。教程因此把“多LoRA池化”列为同底座多租户的独立路线，而不是一般异构GPU池的同义词。

结构化生成：别让CPU语法检查成为GPU的瓶颈

JSON/工具调用需要屏蔽不合法的下一个token。XGrammar 2（2026-01）研究动态工具调用与条件语法，使用TagDispatch、JIT编译、跨语法缓存、解析算法与重复结构压缩，减少结构化生成开销。[14]

类比是自动生产线上有一个质检员负责格式，若每件产品都翻完整手册，机器再快也得等待。可以预先编译共用规则，把常见结构缓存起来，并让CPU检查与GPU执行重叠。收益既可能是减少CPU等待，也可能是少生成不合法结果、少重试；语法合法不保证业务语义正确。语法编译冷启动、复杂schema、分词词表大小、推测验证与grammar状态回滚，都应纳入整体实验。

四种缓存不能混为一谈

这是设计分类。精确响应缓存与语义相似缓存也不同：后者判断“够相似”可能返还过期或不适用答案，必须定义业务可接受性。KV缓存是因果状态，同一段文字出现在不同前文后，通常也不能当成相同KV拼接。缓存收益还取决于存储成本、命中频率和回填时间；“命中率高”不是唯一指标，应该看省下的计算成本。

多模态、实时服务与状态故障

多模态工厂常包括视觉/音频编码、prefill、decode以及输出解码等环节。此处给系统设计边界，不对某个多模态实现作未经验证的性能承诺。将编码器单独profile、按阶段分配资源、避免重复编码，是与P/D分离相同的成本分析方法；具体切分是否划算取决于跨阶段传输的特征体积和实时deadline。图片patch、音频帧与文本token不应直接合并成同一吞吐单位。

状态越多，故障成本越重要。一个decode worker丢失后，恢复可能需要从最近可用KV继续，或重新prefill；提前取消的请求若未及时释放KV，会占住后续容量。缓存持久化可省重算，但增加写放大、失效管理与恢复测试。多租户的缓存命名空间、权限、加密传输以及最长保存周期也是使复用正确的条件。这些都应体现在总成本分子里，而不是当作“免费基础设施”。

最小完整架构：一条请求经过什么

请求/租户身份 → 输入与token处理 → 质量/成本模型路由 → 缓存查找 → 队列与准入 → P工作池 → KV交接或本地保留 → D工作池/草稿验证 → 格式约束与流式输出 → 完成/取消 → KV回收或分层保存。

旁路控制包括：测量延迟和成本、预测容量、扩缩容、故障恢复、模型版本与缓存格式管理。每一处优化都应在这条路径上找到自己的输入、输出、状态和性能指标，才能与其他技术正确组合。

术语速查：把缩写还原成可观察的东西

这是对前文章节用词的统一教学解释；具体实现与证据仍以对应技术章为准。

早期演进补点：2019年的MQA

2019-11-06的《Fast Transformer Decoding》已明确提出多query头共享K/V，以降低增量解码中反复读取KV的带宽开销。因此GQA的历史应理解为在MHA与MQA之间重新寻找质量/共享程度的折中，MLA则从另一维度学习压缩状态，而不是把所有KV压缩都归为2023年后的发明。[100]

检索截至2026-10-02；本文补充两个不能被“多卡并行”和“前缀缓存”完全替代的技术点。

Attention/FFN disaggregation：厨房里面再分专科

P/D拆分按请求阶段分工；AFD按每层算子分工。Attention侧保留请求调度与KV，FFN侧接收隐藏状态和路由信息、计算后返回。EP是把不同expert分到不同设备；AFD则进一步让Attention与expert/FFN服务独立配置，两者可以组合。[85]

类比：P/D是“备菜厨房→出菜厨房”；AFD像在每一道工序里，把查阅病历交给记忆专科，把会诊计算交给专家中心。前者主要交接一次阶段状态，后者每经过一个拆开的层都要发送激活、等待返回；decode又逐步重复。KV通常留在Attention侧，不能把AFD画成“每层搬运完整历史KV”。

教学上可写：额外未隐藏延迟≈输出步数×拆分层数×每层未隐藏往返成本。例如60层、生成100步、每层多20微秒，完全串行时累计120ms；微批流水可隐藏部分，但不能免费消除依赖。AFD设计空间研究正将高频A/F流量优先放在高速scale-up域，把相对低频的P/D状态交接放到scale-out域。[86]

它潜在省钱的地方是Attention容量与FFN计算分别配比、让多个Attention批次合并喂给FFN；代价是层间往返、负载偏斜、额外缓冲和空转。配比不当或小batch、弱互联时可能更慢。AFD不是“拆得越细越好”，也不必然使用不同厂商。

验证时应同时看每层等待、网络拥塞、专家负载与整机有效产出：FFN速度更快但Attention等待返回更久，可能只是把瓶颈搬了位置。拓扑图要画出双向箭头，并把P/D交接与A/F高频交换用不同颜色标识，避免读者误以为它们都是同样的一次搬运。

成熟度必须标清。 vLLM插件仍实验性；官方展示的受控性能实验使用强制专家均衡，改变模型输出，部分prefill实验仅保留10层，不能当作同质量完整模型降本证据。[85]更新至2026-08-04的HeteroPanacea还探索P/D/A/F四路专用硬件与精度联合设计，但主要是仿真，正文承认端到端调度、批处理尚未验证。[87]

RadixAttention：把共同前缀画成树，才能保留正确的共同记忆

SGLang的RadixAttention把token序列与KV映射放入压缩前缀树：到来时查最长已缓存前缀，只算新后缀；结束后保留可复用状态；显存紧张时淘汰无活动引用的冷叶子，尽量保住共享祖先。它是状态索引与调度设计，不是近似attention kernel。[88]

系统指令 1000 token
├─ 文档A 4000 token
│  ├─ 问题1 20 token
│  └─ 问题2 20 token
└─ 文档B 3000 token
   └─ 问题3 20 token

教学假设三个请求全部就绪、状态能留住：独立存储的前缀长度和是14,060，树上不重复路径只有8,060，少重复6,000个token的前缀状态。这不是速度提高42.7%的承诺，attention工作量、后缀与decode仍需计算。

最适用的是同一系统提示、多轮对话、few-shot模板，以及工作流fork后产生多个候选分支。共享必须从根开始相同：同一文档前面换了系统指令，不能仅凭“文档相同”复用全部KV；格式化或工具输出改变也会使匹配提前结束。

树上的“共享”也不意味着把三个分支的回答合并成一个答案：每个分支继续保有自己的后缀状态和输出。树是管理共同历史的目录，KV张量仍驻留在具体设备或存储层；如果请求被派到没有该状态的机器，还需要路由、搬运或重算。

结构化工作流知道哪些调用可并行、哪些依赖前一步输出，因此既可提前安排独立分支，又能把共享前缀请求靠近执行。原论文给出最长共享前缀优先；其最优命中证明限于特定离线条件，在线场景还可能饿死低命中请求，必须保留公平性和延迟预算。树共享减少重复状态，连续批处理填补空座，两者互补。[88]

五个可交互的教学实验

拖动参数，观察收益何时出现、何时消失。

所有数值都是显式假设，不是硬件报价、性能预测或本文实测。实验互相独立；每个实验都附公式与限制。

2026：从更快的单卡，走向更便宜的整条生产线

检索截点为2026-10-02；下列日期是实际公开材料的发布日期。滚动文档以访问日标记，不能当作功能首发日。以下“趋势判断”是对本次证据的归纳，不是市场份额统计，也不是未来性能承诺。

已核实的新进展

本表每行附一手来源；完整条件与证据范围见对应技术章。

趋势一：把低比特变成整条执行路径的能力

从“权重装进4bit”走向权重、激活、KV、通信格式与原生kernel共同设计。NVFP4的小块缩放、QAD的质量恢复说明，少几个bit既是数值问题，也是训练、打包和硬件执行问题。[23][24]

本教程判断：值得持续跟踪的是同质量下的实际kernel覆盖率、反量化成本和精度恢复成本，而不是仅比较标称位数。新精度可能先解决容量，后解决速度；两者时间点未必相同。

趋势二：KV成为可调度、可恢复的状态资产

分页解决单卡分配，前缀复用避免重算，Mooncake/LMCache让状态跨设备和存储层流动，DCP降低组内重复。新的工程挑战转向哪些状态值得保存、放在哪里、何时搬回、故障时如何恢复。[67][77][60]

本教程判断：KV不能只以“缓存命中率”评估，应该测“每花一元缓存与传输费用，省了多少合格GPU工作”。更强的压缩也可能降低迁移门槛，使P/D池化更有价值；反之，更低计算成本又可能让重算优于读取。

趋势三：异构从统一入口走向状态兼容的协作

Cisco案例展示跨厂商同请求P/D协作；SGLang不同TP配置的KV交接则展示，即便不跨厂商，布局转换仍需要专门机制。[83][73]

本教程判断：真正的竞争点是能力发现、性能预测、状态格式、可观测性和拓扑调度的组合。对存量设备而言，先找到它擅长的请求或阶段，比仅比较峰值FLOPS更接近单位成本决策。公开案例不能证明任意品牌、量化格式和网络都能自由混合。

趋势四：模型本身开始为阶段与状态布局而设计

MLA、稀疏/压缩注意力、混合线性结构以及V4.1模型卡描述的CED、CSA2，让模型结构直接改变prefill、decode和KV形态。[28][32][36]

本教程判断：“训练出一个模型，再让系统适配”正在与“训练时就考虑推理形状”并行发展。收益可能很大，但迁移成本也高：需要权重、kernel、缓存、草稿与回滚机制一起验收。它不像升级一个库即可普遍套用。

趋势五：推测从单请求小技巧走向负载自适应

EAGLE-3研究多层特征和训练/起草一致性，MTP提供模型原生草稿，扩散分支研究块内并行生成。[21][38][25]

本教程判断：应按任务接受率、batch、内存余量和SLO动态选择草稿长度甚至关闭推测。块扩散是另一类生成模型，不能借用精确推测的同分布保证；其流式延迟和服务栈成熟度仍需单独验证。

趋势六：调度器不只数请求，也预测工作和状态

Dynamo的性能模型/规划、llm-d的推理指标驱动伸缩、联合异构配置和排队模型研究，都在利用比“当前有多少请求”更丰富的信息。[68][69][80]

本教程判断：负载预测错误、输出长度不确定、缓存丢失和冷启动是必须纳入控制器的代价。平均延迟模型适合做估计，但不自动保证p99；多开机器能改善SLO，不代表成本优化已经成立。

趋势七：衡量单位从token扩展到成功任务

MLPerf正在纳入更完整的应用路径；推理预算控制与模型路由，也让同一个任务的调用数和生成长度不再固定。[7][5][11]

本教程判断：token制造成本仍是基础指标，但应与任务成功率、首次通过率、重试和总时延并列。只把token做便宜却增加无效思考，不一定创造更便宜的产品。

哪些路线现在值得先试

这是部署优先级建议，基于机制、公开实现与实施代价综合判断，不是厂商性能排名。

不要先问“哪项技术排名第一”。先拿到该业务的质量—时延—吞吐—成本曲线，再选择能消除当前最昂贵瓶颈的组合。

完备性、关联性与可理解性审查

本次完成的是有明确边界的全栈覆盖审查：文本自回归推理为主线，覆盖主要模型结构、执行内核、状态、调度、集群与成本；纳入多模态接口及扩散等相邻方向。闭源生产系统的内部算法、全量论文和真实客户TCO不可穷尽，未将“没有读到”写成“行业不存在”。

技术覆盖：用成本来源反查遗漏

覆盖的关键维度是“机制—成本路径—前提—代价—失败案例—证据”。没有把论文标题数量当作完备性的替代指标。

技术相关性：每个组合都需要重新记账

这张关系表是教程根据机制形成的综合判断；技术事实和实现限制的出处见对应章节。

已发现并关闭的缺口

1. 只有“快”没有账单。 补充统一观测窗口、合格输出成本、成功任务成本、空闲/失败资源，以及输入输出结构固定的比较条件。
2. 模型优化漏掉剪枝。 补SparseGPT与非结构化/半结构化/结构化区别，说明零权重不自动加速dense kernel。
3. 池化概念过宽。 拆成请求、阶段、模型内部、缓存四层，并纳入跨厂商状态兼容与Cisco可核对案例。
4. 并行策略混用。 单独比较DP/TP/PP/EP/CP，并区分P/D与AFD的切分位置和通信频率。
5. 缓存只看命中率。 补活动工作集/复用库存、重算vs取回，以及78/78命中仍未改善TTFT的工程反例。
6. 只看GPU。 补CPU启动、Graph、结构化输出检查、adapter切换、存储/网络、故障重算与DVFS。
7. 历史停在2025。 新增真实可检索的2026年FA4、QAD、DCP、跨厂商P/D、可恢复NVMe等节点，并标日期和证据层次。
8. 数字口径不全。 删减或限定FA3/FA4、KIVI、FlexGen等倍数，注明不同batch、旧基线、附加CPU内存与离线时延。
9. 教学式有歧义。 推测期望末项改为α的γ次幂；修复池化打平显示；明确GiB/GB换算与两个实验独立参数。
10. 前沿结果过度解释。 AFD强制专家均衡会改变输出，四路拆分仿真未证明端到端调度；模型卡不等于已读PDF或独立复现。

三份独立审查记录保留在交付包 research/review_model.md、review_kernels.md、review_serving.md；记录可能先列原问题，后列修正，最终HTML以已修订正文为准。

理解检验：能否把术语用到新场景

以下题目没有用“记住年份和论文名”代替理解。先自己回答，再展开解释。

仍然需要真实部署才能回答的事

这里没有运行GPU模型性能实验，没有拿到企业采购合同、电价、机房PUE或全天真实流量，因此没有输出虚构的“最省钱供应商”或通用降本百分比。模型卡/滚动文档中部分内容未固定commit；已给检索日与来源范围。真实部署需补相同模型质量下的端到端测量，这属于部署验收，而不是用更多论文可以替代的工作。

在本次定义的范围内，主要技术层、成本因果与理解障碍已形成闭环；跨章关联有明确解释，发现的技术和教学缺口均已补入。可理解性经过结构、算例和独立审查；尚未做真人学习效果实验，不把自检等同于所有读者必然理解。

来源与证据边界

引用编号统一按URL登记。论文、同篇论文的摘要/正文版本、模型卡和工程文档是来源条目，不能当作彼此独立的实验。外部链接需联网，教程和实验本身不需要。

三类主证据：原论文支持机制与论文内实验；官方实现支持功能存在与限制；基准结果支持特定配置成绩。本文没有本地GPU复现实验，所有教学算例均另行标明。

1. [1]MLPerf Endpoints — performance curves and operating points访问：2026-10-02
2. [2]MLPerf Endpoints Rules — v1.0 draft (P90 vs P95)访问：2026-10-02
3. [4]GreenLLM: SLO-Aware Dynamic Frequency Scaling访问：2026-10-02
4. [5]RouteLLM: Learning to Route LLMs with Preference Data访问：2026-10-02
5. [6]RouteLLM official implementation访问：2026-10-02
6. [7]MLPerf Inference v6.1 — Working Group chairs analysis访问：2026-10-02 · 材料日期：2026-09-17核验范围：MLCommons report; vendors own quoted implementation claims; does not disclose TCO.
7. [8]LLMLingua: Compressing Prompts for Accelerated Inference访问：2026-10-02
8. [11]s1: Simple test-time scaling访问：2026-10-02
9. [12]Stable Answers, Unfinished Reasoning — full paper访问：2026-10-02
10. [13]S-LoRA — author technical article访问：2026-10-02
11. [14]XGrammar 2 — full paper访问：2026-10-02
12. [15]SparseGPT — original paper访问：2026-10-02
13. [16]vLLM Parallelism and Scaling — current documentation访问：2026-10-02
14. [17]GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers访问：2026-10-02 · 材料日期：2022-10-31; read v2 2023-03-22核验范围：Read PDF pages 0-4 including limitations. No production cost assertion.
15. [18]AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration访问：2026-10-02 · 材料日期：2023-06-01; read v5 2024-07-18核验范围：Read sections 3 and 4. Report avoids transplanting TinyChat-vs-HF speedups into optimized servers.
16. [19]SmoothQuant: Accurate and Efficient Post-Training Quantization for Large Language Models访问：2026-10-02 · 材料日期：2022-11-18; version-specific HTML accessed核验范围：Paper full HTML opened; no numeric speedup reused.
17. [20]GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints访问：2026-10-02 · 材料日期：2023-05-22核验范围：Paper HTML and ACL PDF read; cache example is explicitly a teaching derivation.
18. [21]EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test访问：2026-10-02 · 材料日期：2025-03-03; read v3核验范围：Read mechanism and Table 3. Text/Table 5 hardware inconsistency (RTX3090 versus A100) noticed; Table 5 excluded.
19. [22]SafeAILab EAGLE official implementation访问：2026-10-02 · 材料日期：rolling repository; observed 2026-10-02核验范围：README and repository structure; no unverified claims about production deployment.
20. [23]Introducing NVFP4 for Efficient and Accurate Low-Precision Inference访问：2026-10-02 · 材料日期：2025-06-24核验范围：Read original blog body, not AI summary. Marketing cross-generation energy efficiency numbers deliberately excluded.
21. [24]Enable NVFP4 Inference for Nemotron with Quantization-Aware Distillation访问：2026-10-02 · 材料日期：2026-01-20核验范围：Full official article read. Peak FLOPS not reused as serving acceleration.
22. [25]Fast-dLLM v2: Efficient Block-Diffusion LLM访问：2026-10-02 · 材料日期：2025-09-30核验范围：Read sections 3-4 and appendix training settings. Approximate-1B abstract training data is not generalized to 1.5B model, whose appendix reports 3.15B tokens.
23. [26]DeepSeek-V4 arXiv abstract访问：2026-10-02 · 材料日期：2026-06 arXiv identifier; earlier official launch 2026-04-24核验范围：Discovery only; report citations use full HTML source 12.
24. [27]Introducing DeepSeek-V4.1-Flash: smarter, faster, more efficient访问：2026-10-02 · 材料日期：2026-09-10核验范围：Official publication opened and followed to author's Hugging Face model/report.
25. [28]DeepSeek-V4: Towards Highly Efficient Million-Token Context Intelligence访问：2026-10-02 · 材料日期：2026-06 arXiv version; official model release 2026-04-24核验范围：Read architecture, efficiency and cache-management sections. Resource estimates explicitly not measured total cost.
26. [29]DeepSeek-V3 Technical Report访问：2026-10-02 · 材料日期：2024-12; read v2 2025-02-18核验范围：Read sections 2 and 3.4. Paper 1.8x MTP claim not reused because benchmark settings are insufficiently complete.
27. [30]DeepSeek-V3.2: Pushing the Frontier of Open Large Language Models访问：2026-10-02 · 材料日期：2025-12-02核验范围：Read section 2 including complexity and cost methodology; API pricing not confused with resource costs.
28. [31]Fast Inference from Transformers via Speculative Decoding访问：2026-10-02 · 材料日期：2022-11; ICML 2023核验范围：Full PDF opened; no fixed speedup promised. Teaching break-even formula separately marked as derivation.
29. [32]Kimi Linear: An Expressive, Efficient Attention Architecture访问：2026-10-02 · 材料日期：2025-10-30核验范围：Read sections 3-5. Hardware-unqualified headline 6x not reused as production cost estimate.
30. [33]vLLM Quantization访问：2026-10-02 · 材料日期：rolling documentation; observed 2026-10-02核验范围：Read support table and backend selection section. Rolling latest state is not version-pinned deployment certification.
31. [34]DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model访问：2026-10-02 · 材料日期：2024-05; read v5核验范围：Read 2.1 formulas including cache size and position incompatibility; no model-wide speedup reused.
32. [35]DeepSeek-V4.1 technical-report file page访问：2026-10-02 · 材料日期：2026-09 release核验范围：File landing page opened, PDF fetch failed. Do not cite this source as paper-body verification.
33. [36]DeepSeek-V4.1-Flash official model card访问：2026-10-02 · 材料日期：2026-09-10 release; rolling model card observed 2026-10-02核验范围：Read author-written introduction, not auto-generated deployment snippets; mechanisms summarized only at model-card level, no independent production validation.
34. [37]NVlabs Fast-dLLM official repository访问：2026-10-02 · 材料日期：2025-10-08 v2 code; 2026-04-10 dVLM; 2026-05-26 dDrive核验范围：Read repository News and TODOs. Visual/action headline speedups not transferred to text serving.
35. [38]vLLM MTP (Multi-Token Prediction)访问：2026-10-02 · 材料日期：rolling documentation; observed 2026-10-02核验范围：Official feature documentation opened; not a guarantee of every model/quantization combination.
36. [39]vLLM Quantized KV Cache访问：2026-10-02 · 材料日期：rolling documentation; observed 2026-10-02核验范围：Official page sections/table of contents verified. No claim that lower KV bytes necessarily gives proportional latency reduction.
37. [40]Attention Is All You Need访问：2026-10-02 · 材料日期：2017-06-12核验范围：原论文HTML全文；仅用架构起点，不把训练结果当推理收益
38. [41]All About Transformer Inference — How To Scale Your Model访问：2026-10-02 · 材料日期：2025-02-04核验范围：Google DeepMind作者教程全文；式子是简化下界，非实际基准预测
39. [42]FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness访问：2026-10-02 · 材料日期：2022-05-27核验范围：原论文HTML全文；区分forward与反向重算
40. [43]FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning访问：2026-10-02 · 材料日期：2023-07-17核验范围：原论文HTML全文；A100训练/算子实验不外推任意服务
41. [44]FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision访问：2026-10-02 · 材料日期：2024-07-11核验范围：原论文HTML全文；H100 FP16 1.5–2x为特定kernel比较
42. [45]FlashAttention-4: Algorithm and Kernel Pipelining Co-Design for Asymmetric Hardware Scaling访问：2026-10-02 · 材料日期：2026-03-05核验范围：v1全文；B200 BF16算子最高1.3x cuDNN9.13/2.7x Triton；反向不计推理
43. [46]FlashAttention-4 — Tri Dao author blog访问：2026-10-02 · 材料日期：2026-03-05核验范围：作者正文；用于与论文交叉核实版本和机制，未把博客1605与论文1613混用
44. [47]Efficient Memory Management for Large Language Model Serving with PagedAttention访问：2026-10-02 · 材料日期：2023-09-12核验范围：原论文HTML全文；2–4x只相对当时系统基线
45. [48]FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving访问：2026-10-02 · 材料日期：2025-01-02核验范围：v1全文第3.3–3.4节；CPU plan不被graph捕获
46. [49]torch.compile — PyTorch documentation访问：2026-10-02 · 材料日期：undated; retrieved 2026-10-02核验范围：官方搜索索引返回参数全文相关段落；open发生重定向而未返回正文，不宣称完整文档逐行审阅
47. [50]Accelerating Generative AI with PyTorch: Segment Anything, Fast访问：2026-10-02 · 材料日期：2023核验范围：PyTorch官方正文；只引用通用机制，不把SAM性能变成LLM性能
48. [51]KIVI: A Tuning-Free Asymmetric 2bit Quantization for KV Cache访问：2026-10-02 · 材料日期：2024-02-05核验范围：原论文HTML全文；峰值2.6x含权重；Llama2-7B A10080GB batch上限下2.35–3.47x吞吐
49. [52]H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models访问：2026-10-02 · 材料日期：2023-06核验范围：原论文HTML全文；有损选择与任务质量条件
50. [53]Efficient Streaming Language Models with Attention Sinks访问：2026-10-02 · 材料日期：2023-09-29核验范围：原论文HTML全文；无限流不等于无限历史可检索
51. [54]Automatic Prefix Caching — vLLM v0.9.2访问：2026-10-02 · 材料日期：historical fixed version; retrieved 2026-10-02核验范围：官方固定版本说明；不推断当前默认配置
52. [55]FlexGen: High-Throughput Generative Inference of Large Language Models with a Single GPU访问：2026-10-02 · 材料日期：2023-03-13核验范围：原论文HTML全文；OPT175B单16GB GPU约1token/s是effective batch144聚合吞吐
53. [56]PowerInfer: Fast Large Language Model Serving with a Consumer-grade GPU访问：2026-10-02 · 材料日期：2023-12-16; revised HTML includes 2024 studies核验范围：修订全文含SwiGLU 1.47–1.7x评测，不能称仅支持ReLU
54. [57]Hardware-Aware FP4 FlashAttention-4访问：2026-10-02 · 材料日期：2026-09-03核验范围：独立预印本v1全文；非因果forward最高2.13x GB200；不是全模型/通用自回归推理
55. [58]FlexAttention + FlashAttention-4: Fast and Flexible访问：2026-10-02 · 材料日期：2026-03-05核验范围：PyTorch官方正文；发布时nightly+recent checkout并提示breaking changes
56. [59]Ring Attention with Blockwise Transformers for Near-Infinite Context访问：2026-10-02 · 材料日期：2023-10-03核验范围：原论文HTML全文v4；零额外开销以块计算覆盖传输为条件
57. [60]Efficient Decode Context Parallelism with vLLM for Long Context Workloads访问：2026-10-02 · 材料日期：2026-08-07核验范围：官方全文；8xB200 KimiK2.6 NVFP4长输入短输出trace，未引用口径不充分的tok/s数
58. [61]Context Parallelism for Scalable Million-Token Inference访问：2026-10-02 · 材料日期：2024-11核验范围：原论文HTML全文；区分计算、通信、持久KV场景
59. [62]Orca: A Distributed Serving System for Transformer-Based Generative Models访问：2026-10-02 · 材料日期：2022-07核验范围：Paper body, OSDI 2022; historical design, not a modern engine benchmark.
60. [63]Sarathi-Serve: Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve访问：2026-10-02 · 材料日期：2024-07核验范围：Paper sections 4 and 5 read; Yi-34B TP2 experiment for approximately 25% maximum overhead with 512 chunks, not universal.
61. [64]DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving访问：2026-10-02 · 材料日期：2024-07核验范围：Paper sections 3-4 and bandwidth discussion; simulated high-bandwidth results must be distinguished from real low-bandwidth testbed.
62. [65]Splitwise: Efficient Generative LLM Inference Using Phase Splitting访问：2026-10-02 · 材料日期：2023-11 / ISCA 2024核验范围：arXiv v2 body; specific H100/A100 platform prices and power assumptions, not current universal cost ordering.
63. [66]Mooncake: Trading More Storage for Less Computation访问：2026-10-02 · 材料日期：2025-02核验范围：USENIX FAST 2025 paper presentation page; performance outcomes are author workloads, not independent general TCO.
64. [67]Mooncake official repository访问：2026-10-02 · 材料日期：2026-10-02 retrieved; dated news through 2026-08-24核验范围：Current repository README; news timestamps establish dated integrations but do not prove all cross-vendor combinations.
65. [68]NVIDIA Dynamo Planner Guide访问：2026-10-02 · 材料日期：2026-10-02 retrieved; live documentation核验范围：Current official documentation; implementation capabilities, not measured token-cost savings.
66. [69]llm-d architecture访问：2026-10-02 · 材料日期：2026-10-02 retrieved; main branch核验范围：Current main README; differs from old versioned WVA documentation.
67. [70]DeepEP official repository访问：2026-10-02 · 材料日期：2026-10-02 retrieved; main branch核验范围：Current main requirements and notes; no blanket zero-SM claim; experimental collectives distinguished from EP.
68. [72]vLLM Disaggregated Prefilling (experimental)访问：2026-10-02 · 材料日期：2026-10-02 retrieved; latest docs核验范围：Official feature page; warning concerns raw throughput and does not negate workload-specific goodput improvements.
69. [73]SGLang PD Disaggregation访问：2026-10-02 · 材料日期：2026-10-02 retrieved; current docs核验范围：Official heterogeneous TP section; heterogeneous TP is not itself proof of cross-vendor GPU support.
70. [74]TaiChi: Prefill-Decode Aggregation or Disaggregation?访问：2026-10-02 · 材料日期：2025-08核验范围：arXiv v1 sections 3 and 4; inference-system research, not a universal recommendation to split.
71. [77]LMCache official documentation访问：2026-10-02 · 材料日期：2026-10-02 retrieved; dated updates through 2026-06核验范围：Current official docs; vendor-neutral interface does not guarantee arbitrary model state interchange.
72. [78]Raw Block in LMCache: Building a Fast, Recoverable NVMe Tier for KV Cache访问：2026-10-02 · 材料日期：2026-09-22核验范围：Official engineering article; Qwen2.5-14B TP2 functional validation: 78/78 prefix hits, no tuned TTFT advantage.
73. [79]NVIDIA Dynamo Router Guide访问：2026-10-02 · 材料日期：2026-10-02 retrieved; live docs核验范围：Official routing guide; feature description, not benchmark.
74. [80]An Approximate Queueing Model of LLM Inference Serving for SLO-Driven Autoscaling访问：2026-10-02 · 材料日期：2026-09-17核验范围：Preprint v1 full text; Llama3.1-8B/Qwen2.5-14B, light-moderate load; control comparison one run per arm, no variance estimate and extra replicas can explain lower violations.
75. [81]Scalable Joint Resource Allocation for SLO-Constrained LLM Inference in Heterogeneous GPU Clouds访问：2026-10-02 · 材料日期：2026-04-08 first / 2026-06-05 v2核验范围：Preprint v2 full text and algorithm; numerical/simulation evidence, faster allocation solver does not mean same-factor token speedup.
76. [83]Industry’s first MLPerf Inference benchmarking across multi-vendor accelerators访问：2026-10-02 · 材料日期：2026-09-21核验范围：Cisco first-party engineering description; 73357.62 vs 70085.48 summed standalone tokens/s baseline, no cost/power accounting.
77. [84]MLPerf Inference v6.1 raw summary.csv访问：2026-10-02 · 材料日期：2026-09; retrieved 2026-10-02核验范围：Public original CSV row 68 verifies throughput 73357.6 tokens/s and exact_match 83.43465835281891. Detailed system JSON and run log fetch failed, so no p99 numbers reproduced.
78. [85]Announcing vLLM AFD Plugin访问：2026-10-02 · 材料日期：2026-07-23核验范围：官方实现文章全文；同步decode与异步prefill路径不同，实验精度与完整模型限制已读。
79. [86]How Far Can Disaggregation Go?访问：2026-10-02 · 材料日期：2026-05-27核验范围：预印本正文及附录6.2；设备kernel测量结合网络仿真，不宣称所有结果为完整集群实测。
80. [87]When Does Disaggregation Pay? HeteroPanacea访问：2026-10-02 · 材料日期：2026-08-04核验范围：预印本结论与局限；custom NPU研究是仿真，不是采购或普遍降本结论。
81. [88]SGLang: Efficient Execution of Structured Language Model Programs访问：2026-10-02 · 材料日期：NeurIPS 2024; original preprint 2023-12-12核验范围：原论文§3、定理3.1、附录A；教学例数字为自行构造，不引用论文最高加速倍率。
82. [89]FA1 全文访问：2026-10-02
83. [90]FA2 全文访问：2026-10-02
84. [91]FA3 全文访问：2026-10-02
85. [92]原论文访问：2026-10-02
86. [93]KIVI 全文访问：2026-10-02
87. [94]H₂O 全文访问：2026-10-02
88. [95]论文访问：2026-10-02
89. [96]Ring Attention访问：2026-10-02
90. [97]论文访问：2026-10-02
91. [98]FlexGen 全文访问：2026-10-02
92. [99]PowerInfer 全文访问：2026-10-02
93. [100]Fast Transformer Decoding: One Write-Head is All You Need (MQA, 2019)访问：2026-10-02

明确保留的证据缺口

DeepSeek-V4.1报告PDF未成功读取，相关机制依据官方模型卡；Cisco详细run日志与system JSON未成功抓取，正文只使用已读工程说明和公开汇总CSV；部分滚动文档未固定commit；未核验厂商报价和实际客户TCO。这些限制不会用作者自报最高倍数填补。