训练完成的那一刻成本才刚开始发生。推理是把训练投资变现的环节也是工程优化的主战场同等能力的单 Token 价格在两三年里下降了两个数量级而支撑这个数字的不是模型变小而是服务侧工程的一整套组合拳——调度、显存管理、量化、投机解码。把这些技术拆开看它们全部服从同一条第一性原理解码阶段瓶颈在显存带宽而非算力一切优化都在省字节、摊字节或用空闲算力换字节。本文先证明这条原理再看每项技术如何演绎它。一、两种完全不同的算子Prefill 与 Decode自回归推理的显性特征是分两个阶段且两阶段的硬件画像截然相反Prefill预填充把整个 prompt 一次性并行算出 KV Cache。大量 Token 同时过模型矩阵乘满血发挥算力受限compute-bound。决定首 Token 延迟TTFT。Decode解码逐 Token 生成每步前向只有一个 Token。决定后续每个 Token 的间隔TPOT和整体吞吐。Decode 的受限于什么可以精确算出来。生成一个 Token每参数做一次乘加约 2 FLOPs同时每参数必须从显存读一次权重无法驻留 SRAMdefdecode_is_memory_bound():N70e9# 70B 参数flops2*N# 每 Token 计算量bytes2*N# bf16 权重读入量intensityflops/bytes# ≈ 1 FLOP / byte# H100: 990 TFLOPS bf16 密集算力 vs 3.35 TB/s HBM 带宽machine_balance990e12/3.35e12# ≈ 296 FLOP / byteprint(f算术强度/机器平衡点 {intensity/machine_balance:.3%})# ≈ 0.3% —— decode 时 99.7% 的算力在陪跑等数据decode_is_memory_bound()0.3%。这就是解码的本质GPU 的计算单元在算力上极度过剩Token 生成的速度被钉死在每秒能把权重读几遍上——70B bf16 模型在 3.35 TB/s 带宽上理论极限约每卡 24 Token/s与实测单请求吞吐同一量级。预填充则相反算力利用接近满血。两阶段共享同一个批处理池还是分开处理是后面调度层所有设计的分歧点。二、调度层Continuous Batching传统静态批处理凑够一个 batch 一起进出的浪费是结构性的序列长度不同短序列生成完了只能空等同批长序列GPU 大量时间在跑 padding。OrcaOSDI 2022提出的迭代级调度即 continuous batching改写了游戏规则调度的粒度从请求级降到单次前向迭代级classContinuousBatcher:def__init__(self,max_batch):self.running,self.queue[],[]# 在跑/排队中的请求self.max_batchmax_batchdefstep(self,engine):# 1. 每次迭代先收割: 完成的请求立即腾出坑位self.running[rforrinself.runningifnotr.finished()]# 2. 再补位: 新请求随时插入新 prompt 走 prefillwhilelen(self.running)self.max_batchandself.queue:self.running.append(self.queue.pop(0))# 3. 单步前向: 所有在跑序列同解一步, 长度不齐由 kernel 内处理engine.forward(self.running)# step 级而非 request 级每个迭代周期都是收割—补位—前向的循环请求到达即插入、完成即离场批的构成随时重组。配合 vLLM 的 PagedAttention碎片问题此前拆注意力性能时已讲过不再展开吞吐相对静态批普遍翻倍以上。单批内部还有第二个矛盾prefill 是算力任务decode 是带宽任务混在一个批次里跑长 prompt 的 prefill 会让同批所有 decode 请求的 TPOT 突然恶化。Chunked prefillSarathi 系的解法是把长 prompt 切成固定大小的块分散到多次迭代里消化让每次迭代的负载均匀化生产系统则进一步走向预填充/解码分离DistServe、Mooncake 路线两类算子放进不同的硬件池各自按自己的瓶颈优化KV Cache 通过池间搬运传递。这条分离路线的代价是架构复杂度收益是 TTFT 和 TPOT 两个 SLO 可以独立规划——评测口径也随之升级为goodput满足 SLO 前提下的有效吞吐而不是裸吞吐。三、显存层KV Cache 的容量经济学服务系统的并发上限不是想开多大 batch 就多大而是一道显存除法defmax_concurrency(vram_gb80,weights_gb140/8,kv_per_req_gb2.0):# weights_gb: 70B 模型 8 卡张量并行, 每卡 17.5GB# kv_per_req_gb: 4K 上下文 GQA 架构单请求 KV (第2篇算过 ≈2GB)returnint((vram_gb-weights_gb)/kv_per_req_gb)print(max_concurrency())# 31 个并发请求/卡 —— 这就是服务的天花板三个变量对应三类扩容手段权重显存靠量化下一节、单请求 KV 靠 GQA 与 KV 量化、剩余空间靠碎片治理。碎片之外更值钱的是复用企业场景里 system prompt 千人一面重复计算是纯浪费。Prefix cachingvLLM 的 automatic prefix caching、SGLang 的 RadixAttention把 KV 块按内容哈希索引成树新请求的 prompt 前缀命中即直接挂载现成 KV首 Token 延迟从秒级砍到毫秒级。对多轮对话、RAG 系统模板、Few-shot 场景这是免费午餐里最大的一份。KV 本身也可以量化int8 近乎无损int4 需要技巧——K 矩阵RoPE 之前有显著的离群通道对量化最敏感KIVI 类方案对 K 按通道、对 V 按 Token 分别处理来压回误差。单请求 KV 减半直接意味着上式分母减半、并发翻倍。四、量化把字节打薄权重是解码带宽的大头量化是最直接的省字节手段。主流三档方案形式权重显存/带宽质量代价适用bf16 基线—2B/参数——W8A8权重激活均 int81B/参数近无损高吞吐在线服务W4A16权重 int4激活 bf160.5B/参数小幅退化端侧/单卡低并发W4A16 只量化权重、激活保持高精度是因为激活分布里存在离群值大幅超出正态范围的通道直接 int8 会砸精度。W8A8 的配套技术 SmoothQuant 的思路就是解决它用缩放因子把量化难度从激活迁移到分布更规整的权重侧。权重 int4 不是简单取整GPTQ 与 AWQ 两个代表方案都在利用校准数据补偿误差# GPTQ 核心: 逐列量化, 误差沿着 Hessian 信息转移到未量化列# 目标函数: min ||(W - Q)X||², H 2XX^T# 每量化一列 w_j, 量化误差 Δ 按海森逆矩阵的比例加到剩余列上# —— 知错能改: 后面的列可以抵消前面犯的错# AWQ 另辟蹊径: 激活幅度前 ~1% 的通道是关键通道# 对它们做 per-channel 预缩放保护, 其余通道放心低精度实测规律值得记住两点。其一误差随规模衰减同样的 W4 方案7B 模型掉分明显70B 模型常常近乎无感——大模型的冗余性天然吸收量化噪声。其二量化的收益结构不均匀它省的是带宽因此在低 batch带宽受限区加速显著batch 打大后系统转入算力受限区权重读入被大量请求摊薄W4A16 相对 bf16 的优势快速收窄。选量化方案前先看自己的负载落在哪个区而不是无脑上最低比特。五、投机解码用空闲算力换带宽第一节算过账解码时 99% 的算力闲置。投机解码Leviathan et al., 2023把这些算力变成了燃料——用小模型起草大模型一次性验证draft: 小模型(1B)连写 k 个 Token: d1 d2 d3 d4 verify: 大模型(70B)一次前向, 并行算出 d1..d4 各自位置的正确分布 accept: 逐位比对, 前缀一致的整段收下; 拒绝处修正, 之后的草稿作废验证kkk个草稿 Token 只需一次大模型前向——权重读一遍同时干kkk份活。带宽单价没变Token 产量翻了数学上它还精确保持目标模型的输出分布不是近似靠的是拒绝采样修正importnumpyasnpdefspeculative_verify(p_t,p_d,draft,rng):p_t: (k1, V) 目标模型分布; p_d: (k, V) 草稿分布; draft: k 个草稿 tokenout[]fori,tinenumerate(draft):ifrng.random()min(1.0,p_t[i,t]/p_d[i,t]):out.append(t)# 接受else:residualnp.clip(p_t[i]-p_d[i],0,None)# 修正分布residual/residual.sum()out.append(rng.choice(len(residual),presidual))returnout,False# 拒绝即停, 后续草稿作废bonusrng.choice(len(p_t[-1]),pp_t[-1])# 全接受: 白赚下一个 tokenreturnout[bonus],True收益的上界由接受率和草稿长度共同决定。设每 Token 接受率α\alphaα、草稿长kkk每步期望产出defexpected_tokens(alpha,k):return(1-alpha**(k1))/(1-alpha)defspeedup(alpha,k,draft_cost0.1):tauexpected_tokens(alpha,k)step_timek*draft_cost1.0# k 次小模型 1 次大模型验证returntau/step_timeprint(fα0.8, k4: 期望{expected_tokens(0.8,4):.2f}token/步, f加速{speedup(0.8,4):.1f}x)# 3.36 token/步, 2.4x几何级数自然衰减——接受率 0.8、草稿 4 个 Token 时每步期望产出 3.36 个扣除草稿成本净加速 2.4 倍。加速的全部来源是α\alphaα两个分布的契合度于是草稿器演化成一条独立赛道从外挂小模型到 Medusa 的多头并行预测再到 EAGLE 的特征层自回归在隐藏层而非 Token 层起草接受率显著更高当前效率最高的一系。另一个极端是零成本草稿n-gram 匹配直接从上文复制片段prompt lookup decoding对编辑、摘要、RAG 引用这类答案就在上下文里的任务几乎是免费的加速。同样要写进账本的还有衰减条件投机解码赚的是带宽受限的钱。服务端 batch 打大后GPU 逐渐转入算力受限区验证kkk个 Token 的算力开销从免费变成显性成本——大流量在线服务里投机解码收益缩水低并发本地部署里它大杀四方同一枚硬币的两面。六、收束技术作用机理省下/摊薄什么代价Continuous batching迭代级调度补位GPU 空转时间调度复杂度Chunked / 分离部署拆开异质负载TTFT 与 TPOT 互扰架构复杂度Prefix cachingKV 复用重复 prefill 算力命中率依赖场景W4A16 / W8A8 量化权重字节打薄带宽与显存精度、区域依赖收益KV int8/int4缓存打薄显存 → 并发K 离群值需处理投机解码并行验证草稿带宽用闲置算力换草稿质量、batch 效区衰减这些技术没有一个在改模型的数学——输出分布逐位不变是其中好几项的卖点。全部收益来自让硬件的物理事实带宽稀缺、算力过剩、显存有限与负载的统计事实长度不齐、前缀重复、答案局部可预测对上频率。推理工程的下一程是把这些手段与 MoE 的稀疏激活、长上下文的层级缓存组合起来但分母始终是同一个每秒能从显存里搬出多少个有效的参数字节数。