加速不是把每层都调快而是删掉 SLO 关键路径上最贵的一笔
同一个“慢”可能是请求还没进 GPU、长 Prefill 卡住在途 Decode、权重或 KV 搬太多、目标模型步数太串行，也可能是跨卡与 KV 传输。先冻结工作负载和四只钟，再用 profile 写资源账，最后选择真正删除那笔成本的机制。
没有工作负载和 SLO，就没有“最快配置”
聊天、批量摘要、代码补全和 Agent 循环可能使用同一 checkpoint，却处在完全不同的最优点。批处理愿意牺牲首 token 换总吞吐；交互产品要约束尾部 TTFT 与卡顿；Agent 还会把一次业务动作放大成多轮短请求。优化前先把“谁来、输入多长、输出多长、怎样到达、什么才算成功”写成合同。
生成语义
model revision、tokenizer、Chat Template、采样、停止条件、结构化输出与 LoRA。它们改变，结果和实际输出长度就可能改变。
真实流量
输入/输出联合分布、prefix 重复率、流式方式、到达率、burstiness、并发上限、超时、取消和重试，而非一个平均长度。
体验与成功
客户端 TTFT、每请求平均推进、逐 response/chunk 间隔、E2E、成功率与 goodput 的分位数和分母；离线任务则可换成 deadline 与每批成本。
资源与拓扑
GPU 型号/数量、互联、CPU、内存、runtime/driver、引擎 commit、kernel、功耗模式、并行切法和故障域。
车速快，不等于从家到公司快
Kernel 像某一段路的限速；队列是收费站，Prefill 是长匝道，Decode 是必须依次经过的路口，KV 是随车携带并反复读取的行李。只测一段空路的最高车速，回答不了早高峰 P99，也回答不了一小时能准时送到多少人。
Open-loop（开环）按预定时间产生请求，系统变慢也继续到达；固定并发通常在请求完成后才补新请求，系统变慢会自动降低到达率。vLLM 当前工具同时暴露 request-rate、Gamma/Poisson burstiness 与 max-concurrency，但两种曲线不能直接互换。I01
先写“每请求平均”还是“逐响应间隔”，再谈工具里的 TPOT、ITL 与 ICL
指标名不是跨工具标准。vLLM 当前 serving benchmark 把每个成功请求的 (E2E−TTFT)/(Nout−1) 叫 TPOT（Time Per Output Token），把实际流式响应间隔集合叫 ITL（Inter Token Latency）；NVIDIA AIPerf v0.11 则把前一种每请求平均量叫 ITL，把逐 response chunk 的间隔分布叫 ICL（Inter Chunk Latency）。报告必须先冻结公式、观测单位和 chunk/token 语义，再记录工具别名。I02I03
从客户端发送到首个可见响应
包含网络、网关、排队、Prefill、第一步生成与 flush。若只从服务端入队计时，必须换名字并同时保留客户端值。
首 token 后的平均推进时间
一个请求得到一个平均值，适合请求级 SLO；它会把中间一次 500ms 卡顿和许多 10ms 间隔摊平。
相邻流式 response/chunk 的实际间隔
更接近“文字有没有突然停住”。一个 chunk 若携带多个 token，逐 chunk 间隔不能冒充逐 token 间隔。
每秒满足既定 SLO 的完成请求
AIPerf 的 goodput = good_request_count / benchmark_duration；另报 good_request_fraction = good_request_count / (request_count + error_request_count)。取消、拒绝与客户端超时是否进入 attempted 口径，需由适配器策略预先声明并单列。I04
“GPU 利用率 95%”不是诊断；先问时间花在哪个阶段、搬了什么状态
Prefill 常以较大的 token 矩阵提高并行度，Decode 则在时间维串行，并反复读取权重与历史 KV；但 batch、上下文、MoE、并行与 kernel 都会改写这个形态。Roofline Model（屋顶线模型）以 min(P_peak, BW_attainable × OI_DRAM) 给上界：BW_attainable 应由匹配硬件和访问模式的独立表征 benchmark 测出；目标 workload 的 achieved bandwidth 只用来衡量离屋顶还有多远。I25
先查队列、CPU 和同步
Tokenizer、Python event loop、scheduler、host-to-device、同步等待与请求不足都可能让 GPU 饿着；此时换更快 GEMM 未必动 TTFT。
把字节拆成权重、KV 与中间量
权重量化、KV 量化、GQA/MLA、FlashAttention 与 batch 复用删的是不同字节，不能都写成“省显存”。
回看并行度与拓扑
Tensor Parallel、Pipeline Parallel、Expert Parallel 分别引入不同 collective、stage bubble 和消息形态；卡数更多不保证单请求更快。
先算裸下界，才能看懂量化、分页和缓存究竟改了哪一项
下列公式是逻辑容量或理想传输下界，不是显存峰值和产品速度承诺。真实系统还要放激活、workspace、allocator、图捕获、通信 buffer、采样状态、碎片和副本；Tensor/Pipeline 分片又会改变单卡账。
M_weight = P × bits / 88B Dense、BF16 的裸权重是 16.0 GB（十进制）≈14.90 GiB。INT4 裸码下界是 4.0 GB，但 scale、zero point、padding、未量化层与 runtime 另算。
M_KV = B × T × L × 2 × H_kv × D_h × bytes2 是 K/V；这是标准稠密注意力的逻辑状态。滑窗、MLA、稀疏/线性状态或跨层共享要换公式。
t_step ≥ bytes_moved / BW_attainable可达/可持续 DRAM 带宽来自匹配硬件、NUMA/拓扑与访问模式的独立表征，不是目标 workload 自己的 achieved bandwidth，也不是宣传页 pin 峰值。
16.0 GB ÷ 1.6 TB/s = 10 ms / target step
假设 batch 很小、每个目标模型步从 HBM 流过一次 BF16 权重，并由独立表征得到匹配访问模式下的 BW_attainable=1.6 TB/s（均按十进制）。它对应约 100 个 target steps/s 的理想上限；KV、计算、launch、采样与通信只会再加时间。batch 共享权重或推测验证多个 token 后，它也不等于“单用户 100 token/s”。
32 层 × 8K × 8 KV 头 × 128 维 × K/V × BF16 = 1 GiB / 序列
取 B=1, T=8192, L=32, Hkv=8, Dh=128, bytes=2，每新增一个 token 的逻辑 KV 是 128 KiB，8K 共 1 GiB。16 个同长活跃序列的逻辑账就是 16 GiB，尚未计物理 block、分片、metadata 和余量。
当前 vLLM 以父 block hash、block tokens 和附加 hash 识别完整块；LoRA ID、多模态输入与 cache salt 都可能进入附加键，多租户还需隔离时序侧信道。命中跳过的是重复 Prefill 计算，后续 Decode 仍要运行。I07
连续批处理、FlashAttention、量化和推测解码，并不是四种“让 GPU 更快”
Iteration-level Scheduling（迭代级调度）在每轮补入/移出序列，减少静态批次空洞；FlashAttention 通过 IO-aware 分块少物化中间 Attention；量化减少某类表示字节并依赖对应硬件 kernel；推测解码则减少目标模型的串行步数。若不写明机制，就无法决定看 queue、HBM、kernel time 还是 accepted length。I05I12
优化 Attention 执行，不包办整条请求
FlashAttention 保持非近似的 Attention 数学语义（算法级 exact，不承诺不同 kernel / 精度逐位一致），主要减少 HBM IO；FlashAttention-2 再改 GPU 工作分工。FlashInfer 进一步面对 paged/ragged KV、动态请求和 tree decode。MLP、queue、collective 与网络仍在账上。I13I14
减少重复 launch 的 CPU 开销
CUDA Graph 将操作图先定义/实例化再重复启动，短 kernel 多、shape 可复用时更有价值；捕获、实例化、动态控制和 graph variant 也有成本。它不减少模型 FLOPs 或 KV 字节。I15
先写 W/A/KV，再写位宽和 kernel
AWQ 是 weight-only 路线，SmoothQuant 面向 W8A8，KIVI 处理 KV；当前 TensorRT-LLM 还支持多种 FP8/FP4 与 AWQ/GPTQ 组合。模型体积、矩阵计算、KV 容量和质量是四本账。I16I17I26
Chunked Prefill 是同机时间切片；P/D 分离是换部署边界
长 Prefill 可能让已经在流式输出的请求停住。Sarathi-Serve 将 Prefill 切成接近固定 token 预算的块，并与 Decode 组成更均匀的 batch；P/D Disaggregation（Prefill/Decode 分离）则让两阶段独立扩容、选择不同并行度，但必须把 KV 交给 Decode。两者可以组合，也可能都不适合短 prompt、低并发或慢网络。
论文设置中最高 2.6×、3.7×、5.6× serving capacity
作者分别报告 Mistral-7B/单 A100、Yi-34B/双 A100 与 Falcon-180B/Pipeline Parallel 的上限结果，且都绑定其尾延迟约束、模型和基线；它证明调度干扰值得测，不是任意引擎可复制的倍率。I08
论文设置中 7.4× 请求容量或 12.6× 更紧 SLO
作者相对其对比系统报告在超过 90% 请求满足约束下的结果；收益来自阶段隔离、资源与并行共同规划，不应只归因于“把两台机器拆开”。I09
KV 成为跨节点数据面
Mooncake 将 KV 存储/传输放在架构中心；当前 Dynamo 明确提醒：短输入、小模型、低并发或缺少快速 KV transfer 时，聚合部署可能更简单、更快；TCP fallback 甚至会主导 TTFT。I10I11
推测解码赢在“每次昂贵验证推进多少 token”，不是草稿一次猜了多长
经典 Speculative Decoding（推测解码）由便宜草稿模型提出一段候选，目标模型并行评分，再用修正拒绝采样保持目标分布；并非所有 greedy shortcut、tree verifier 或自定义采样实现都继承这一保证。真实速度还要扣除 draft、验证 kernel、被拒位置后的浪费、batch capacity 和调度开销。I20
草稿 / 多头提出
记录 draft latency、候选长度与每请求策略；猜得长不代表被接受得长。
目标模型并行评分
记录 verification batch、tree/attention kernel 与被浪费的验证位置。
按语义合同接收/修正
记录 accepted length 分布，而非只报平均 acceptance rate。
回到同 arrival rate
同时看每请求平均推进、逐 response/chunk 间隔、吞吐、goodput、显存和输出一致性；大 batch 可能吃掉单用户收益。
每轮净收益 ∝ accepted target tokens ÷ (draft + verify + schedule + wasted capacity)输出很短、草稿与目标不匹配、验证不能高效合批或系统已经 compute-bound 时，分子不够大；投机可能变慢。
预测多个未来 token，可以训练后丢弃，也可转成 proposer
ICML 2024 MTP 用多个未来 token 监督共享主干；DeepSeek-V3 使用顺序 MTP 模块，并在其报告环境中给出第二 token 接受率 85%–90%、1.8× TPS。数字只属于该模型与实现。I21I22
同一论文里，“最高加速”与大 batch 吞吐已是两种数
作者报告最高 6.5× speedup，同时在 SGLang batch 64 报告 1.38× throughput improvement。它恰好说明：单用户 latency、固定 batch 吞吐和在线 goodput 不能互相代替。I23
开始把验证长度和服务负载一起调度
DSpark 用半自回归 drafter 和置信度调度验证长度；v1 预印本自报在 DeepSeek-V4 live traffic、matched throughput 下相对 MTP-1 提升 60%–85% per-user generation speed。截至 2026-07-17 尚是作者自报，不能当成跨模型定律。I24
每次只改变一个主变量，并保留客户端体验、服务端归因与语义回归
“INT4 比 BF16 快 2×”若同时换了框架、kernel、并行度、prompt 分布和采样，就只能归因给整套栈。上线实验要冻结 run manifest，按真实到达过程重放，报告实际输入/输出 token、失败与超时，再用相同质量集、长上下文和安全回归证明语义没有倒退。
按目标 arrival rate 扫负载
先 warm up，再进入稳态；用真实 trace 或联合长度分桶，保留 prefix reuse、流式、LoRA、取消和重试。固定并发只回答另一类问题。
分位数、分母与失败一起报
TTFT、每请求平均推进、逐 response/chunk 间隔、E2E、request/token throughput、goodput、good request fraction、拒绝/失败/超时/取消、显存、功耗和成本；同时记录工具指标名，至少保留 P50/P95/P99 与样本数。
用 stage event 解释差异
queue、prefill、decode、batch composition、cache hit、KV bytes、preemption、kernel、collective、NIC 与 CPU 对齐同一 request id。
Shadow → Canary → Ramp / Rollback
预先写质量和 SLO 门槛、置信区间、止损条件与完整旧 manifest；不以“平均更快”覆盖某一租户、长度桶或 P99 的退化。
目标流量下，满足语义和质量约束的 SLO goodput 提升，且新增复杂度可以观测、回滚
这才是推理加速的终点：不是某个 kernel 的 microbenchmark，不是单请求空载 TPS，也不是显存刚好放得下，而是同一产品合同下有更多请求按时、正确、稳定地完成。
一手来源与证据边界
优先使用论文、官方文档、官方模型卡和代码仓库。页面中的数字只代表来源所述设置，不自动外推到其他模型与数据。
当前 vLLM bench serve 的 request rate、burstiness、max concurrency 与 ramp-up 负载模型。
TPOT、ITL、TTFT、E2E、goodput 与失败请求在当前 benchmark 实现中的计算边界。
当前 AIPerf 的 TTFT、每请求平均 ITL、逐 chunk ICL、请求时延、吞吐与指标计算阶段。
goodput 与 good_request_fraction 的不同分母、错误请求口径，以及约束必须随 benchmark 声明。
Iteration-level Scheduling（迭代级调度）与选择性批处理的原始系统设计。
PagedAttention 的逻辑块—物理块映射、KV 内存碎片控制与共享边界。
完整 KV block 的 hash 复用、LoRA/多模态附加键、LRU，以及多租户 cache salt 隔离。
Chunked Prefill 与 stall-free batching 如何降低长 Prefill 对在途 Decode 的干扰。
Prefill/Decode 分离、分阶段 TTFT/TPOT SLO、资源分配和带宽感知放置。
当前 P/D 分离工作流、KV transfer 关键路径、RDMA/TCP 边界，以及“不自动更快”的官方说明。
KVCache-centric 分离架构、跨层状态存储与调度的生产系统证据。
通过 tiling 和 online softmax 减少 HBM↔SRAM 往返的 IO-aware 精确注意力算法。
线程块与 warp 分工、occupancy 和非 MatMul FLOPs 的后续优化；论文数字只绑定其硬件与 Shape。
多种 KV layout、动态请求、JIT 模板、负载均衡调度与 CUDA Graph 兼容的 serving kernel 证据。
将重复工作图预先实例化、降低 CPU launch 成本，以及动态工作流和复用次数的适用边界。
通过等价缩放把激活量化难度迁移到权重，实现 W8A8 PTQ 的原始方法。
Activation-aware Weight Quantization（激活感知权重量化）的低比特 weight-only 路线。
Key 按通道、Value 按 token 的 KV 量化观察及 2-bit 方法；页面不外推论文倍率。
Grouped-Query Attention（分组查询注意力）通过减少 KV 头数改变逻辑 KV 状态。
草稿提出、目标模型并行验证与修正采样保持目标分布的经典推测解码。
Multi-Token Prediction（多 Token 预测）作为训练目标和并行预测头的原始研究。
顺序 MTP 模块、第二 token 接受率 85%–90% 与论文环境 1.8× TPS 的模型特定结果。
多层特征融合的 EAGLE-3 proposer，以及延迟与大 batch 吞吐倍率明显不同的正式论文证据。
半自回归 drafter 与按置信度/负载调节验证长度；截至核查日属于作者自报预印本。
以峰值计算、独立表征的可持续 DRAM 带宽和 Operational Intensity 给性能上界的原始 Roofline 模型。
当前 FP8/FP4、AWQ/GPTQ、权重/激活/KV 配方与硬件支持矩阵，说明算法名必须落到真实 kernel。