大模型推理部署优化：显存、KV Cache、量化与调度实战

大模型落地到最后一步永远绕不开推理部署这件事。模型权重拿到了、评测跑通了、业务 demo 也做出来了可一旦要扛住真实流量问题就全冒出来了显存不够、首包慢、并发一上去吐字就跟卡带一样、几张卡跑出来的吞吐还不如一张。这些坑我在过去几年里反复踩过从早期拿单卡硬塞十几 B 的模型到后来做几十 B 规模的在线服务中间换过的推理框架、量化方案、调度策略加起来能列一长串。这篇内容想聊的就是大语言模型的优化与加速推理部署——它的核心是把一个“能跑”的模型变成一个“跑得起、跑得稳、跑得便宜”的在线服务。适合三类人看一是手里有模型、正准备上线但不知道从哪下手调优的同学二是已经在线上跑了、但吞吐和延迟指标不达标的同学三是对量化、KV Cache、投机解码这些名词听过但没系统串起来过的同学。我会把显存与算力的账算给你看把量化、缓存管理、算子融合、解码加速、框架选型这几条主线拆开讲每个环节都给出可复现的参数和踩坑记录。文中涉及具体数值的地方都是量级示意你按自己的硬件和模型换算即可。1. 先把账算清楚推理瓶颈到底在哪很多人拿到一个慢吞吞的服务第一反应是换框架、调线程数、加并发参数折腾一圈指标纹丝不动。我的习惯是先算三笔账显存够不够、算力和带宽哪个先见底、指标到底卡在首包还是卡在出字。这三笔账算不清楚后面的调优全是碰运气。下面三小节就是我每次接手一个新模型时必做的核算流程你也可以照着套。1.1 显存账权重、KV Cache、激活值三块怎么分推理时的显存基本被三块吃掉。第一块是模型权重算法很简单参数量乘以每个参数占的字节数。一个 70B 的模型用 FP16 存就是 140GB单张 80GB 的卡根本放不下必须做量化或者切分。换成 INT4 之后权重降到 35GB 左右再加上 group scale 和 zero point 的额外开销实际占用普遍在 38~42GB 之间这就是很多“大模型能塞进单卡”的来源。第二块是 KV Cache也是新手最容易算漏的一块。每个 token 需要缓存的字节数等于 2K 和 V 各一份乘以层数、乘以 KV 头数、乘以 head_dim、再乘以数据类型字节数。拿一个常见配置举例32 层、hidden size 4096、8 个 KV 头GQA、head_dim 128、FP16 存储单个 token 就是 2×32×8×128×2 131072 字节也就是 128KB。八K上下文就是 1GB三十二路并发同时跑满上下文就是 32GB这一下就把权重省下来的空间吃回去了。如果这个模型是传统 MHA、32 个 KV 头同样的上下文长度下每 token 就是 512KB八K上下文单请求 4GB并发根本撑不起来。这也是为什么新模型几乎都在往 GQA 甚至 MLA 的方向走——不是跟风是显存账单逼出来的。第三块激活值相对小但上下文长、batch 大的时候也不可忽略通常留 2~4GB 余量比较稳妥。1.2 算力账prefill 与 decode 的两种完全不同负载大模型推理分两个阶段这两个阶段的瓶颈完全相反这也是很多调优手段“按下葫芦浮起瓢”的根本原因。prefill 阶段要把整段 prompt 一次性算完是个大矩阵乘属于算力受限decode 阶段每生成一个 token都要把全部权重从显存里读一遍属于带宽受限算力利用率低得可怜。给一个直观的估算70B 模型 INT4 量化后约 40GB假设显存带宽 2TB/s那么光把权重读完一遍就要 40GB ÷ 2TB/s 20ms也就是说单请求的理论出字速度上限是 50 token/s。实际 kernel 效率打个六七折30 token/s 上下就是单请求的常态。想提高吞吐唯一的出路是批处理——一次读权重同时算几十个请求把带宽成本摊薄。prefill 那边则是另一套算法FLOPs 大约等于 2 乘以参数量乘以 token 数。70B 模型处理 4096 个 token 的 prompt大约是 5.7×10^14 次浮点运算也就是 573 TFLOPs。假设卡的 FP16 峰值算力是三百多 TFLOPs、实际利用率四成这个 prefill 就要跑四秒多。这就是长上下文场景下首包时间动辄好几秒的物理原因跟框架好坏没关系是算力决定的。1.3 指标账TTFT、TPOT、吞吐、并发别混着谈指标这块必须先统一语言否则团队内部讨论半天说的不是一回事。下面这张表是我团队里通用的口径你可以直接拿去对齐。指标含义典型劣化原因主要优化手段TTFT从请求发出到第一个 token 返回prompt 太长、prefill 抢占、排队chunked prefill、前缀缓存、减少排队TPOT / ITL相邻两个 token 的间隔batch 太大、KV 读取慢、调度抖动控制批大小、KV 量化、算子融合输出吞吐系统每秒产出的 token 总数批处理效率低、显存不足连续批处理、提高并发、量化有效吞吐满足 SLO 前提下的吞吐长尾请求拖累分级部署、超时熔断这里最容易犯的错是拿“平均 TPOT”汇报掩盖了 P99 的抖动。线上用户感知最强的是长尾一个请求卡两秒体验就崩了。还有一个概念叫有效吞吐——只有满足延迟目标的吞吐才算数把所有请求塞进一个大 batch 换来吞吐数字好看结果每个用户都在等那是自欺欺人。反过来推算容量也很实用如果业务要求 TPOT 不超过 50ms单请求就是 20 token/s并发 32 路系统输出吞吐目标就是 640 token/s。再拿这个数字去反推需要几张卡思路就清晰了。我习惯先定 SLO再谈优化顺序反了容易做无用功。2. 量化把权重和 KV 压下去的第一刀量化是投入产出比最高的一步几乎没有之一。同一张卡FP16 跑不动的模型INT4 量化后能跑起来而且吞吐往往翻倍。但量化也是最容易出事故的一步指标看着没问题上线后用户投诉“答非所问”“数字算错”“代码少个括号”排查半天才发现是量化把某些敏感层压坏了。这一节讲清楚路线选择和验证方法。2.1 权重量化的几条路线与取舍目前主流路线大致分四档从高精度到激进压缩依次是 BF16/FP16、FP8、INT8、INT4。FP8 需要硬件原生支持好处是几乎无损、无需校准改造成本极低属于有条件就优先上的方案INT8 一般配 W8A8 方案激活也量化需要对激活做平滑处理来压掉离群值工程上稍微麻烦一点INT4 是显存最紧张的场景下的主力常见实现是 GPTQ 和 AWQ 两派。GPTQ 走的是逐层重建误差最小化的路子用 Hessian 近似决定每个权重的重要性校准集跑一遍就能出结果。AWQ 的思路不一样它认为只有少量“显著权重”重要靠激活值的分布来识别这些通道对这些通道做保护性缩放。实操感受是AWQ 在指令跟随和对话类任务上更稳一些GPTQ 在纯语言建模的困惑度上略占优两者差距不大但 AWQ 对校准集分布更敏感。有一点必须纠正预期INT4 相对 FP16 的理论压缩是 4 倍但实际 decode 加速普遍只有 2~2.5 倍。原因是权重变小了KV Cache 和激活值的读取占比就上来了而且反量化本身有开销。谁跟你说 INT4 能带来四倍加速那大概率是没在真实负载上测过。2.2 校准与精度验证怎么判断能不能上线校准集的挑选比算法选择更影响结果。我的做法是从真实业务流量里采样 256~512 条覆盖所有任务类型和长度区间千万别图省事拿通用语料凑数。之前有个项目校准集全是短问答量化后长文档摘要任务的输出开始出现重复片段排查了两天才定位到是校准分布偏移。验证环节也别只看困惑度。困惑度对量化不敏感涨个零点几看不出问题但业务指标可能已经掉了。我的验证清单是这样的任务级指标必须测比如分类准确率、抽取任务的 F1、代码生成的通过率再挑一批“敏感样本”专门看包括含大量数字的、含代码块的、含罕见专有名词的、超长上下文的。量化后的 bad case 高度集中在这几类基本上一测一个准。注意量化验证必须在真实推理框架里做不能只在转换脚本里跑。有些框架会对特定层做回退比如把第一层和最后一层保留高精度你在别处测的结果和线上不一致很容易误判。2.3 KV Cache 量化省显存但容易翻车的细节权重压完显存大头往往就变成 KV Cache 了尤其是长上下文和高并发场景。KV Cache 量化到 FP8 通常是安全的收益也实在——同样是 32GB 的缓存占用直接砍半。INT8 就要谨慎INT4 我基本不建议在在线服务上用。细节上K 和 V 的敏感度不一样K 对量化的敏感度普遍高于 V很多实现会给 K 用更细的粒度比如 per-channel 或者 per-head 的 scaleV 用 per-token 的 scale。校准方式上per-tensor 的静态 scale 实现简单但精度损失大per-token 动态计算更准但多了一点开销长上下文场景我建议用 per-token。还有一个隐蔽的坑KV 量化的误差会随着上下文变长而累积短 prompt 测不出来几千 token 之后才开始劣化。验证的时候一定要用满你线上的最大上下文长度去测短样本测出来的结论没有参考价值。3. 显存与调度的工程活KV Cache 管理与连续批处理量化解决的是“装不装得下”调度解决的是“装下之后跑得快不快”。同样一张卡、同一个模型调度策略好坏能带来两三倍的吞吐差距。这块的工程量最大也最考验对底层机制的理解。3.1 PagedAttention 与显存碎片的治理早期的 KV Cache 实现是给每个请求预分配一块连续显存按最大长度预留。问题很明显一个请求实际只用了 500 token但按 4096 预留浪费八成而且请求长度参差不齐反复分配释放之后显存碎片严重最后明明总量够却分配不出来。分页的思路借鉴了操作系统的虚拟内存把 KV Cache 切成固定大小的块比如每块 16 个 token用一个块表把逻辑位置映射到物理块。这样一来请求按需增长用多少占多少块之间也不需要连续。实测下来显存浪费能从六成以上压到个位数百分比同样的卡能多扛好几倍并发。块大小的选择是个小权衡块太小块表本身占内存、寻址开销大块太大最后一个块内部浪费多。16 是常见的默认值长上下文为主且请求长度整齐的场景可以试 32短请求密集的场景可以试 8差异不会特别大别在这上面花太多时间。3.2 连续批处理与 chunked prefill 的参数拿捏连续批处理的意思是不等整个 batch 里所有请求都结束某个请求一结束就立刻腾出位置给新请求。这一招把 GPU 的空转时间压到很低是吞吐提升的关键。但配套的参数得调最核心的是单批最大 token 数。这个参数设太大一个超长 prompt 的 prefill 会占满整个批次正在 decode 的请求全被卡住用户看到的就是“打字突然停顿”。设太小prefill 被切得太碎算子效率上不去。我的经验区间是 2048 到 8192短对话场景取下限长文档场景取上限配合 chunked prefill 把长 prompt 切成几段插到 decode 的间隙里跑。还有一个参数是最大并发序列数它直接决定 KV Cache 的峰值占用。设得比显存能承受的还大框架会在运行时做抢占把某些请求的缓存换出到内存再换回来这一换一回的延迟非常难看。稳妥做法是先用公式算出显存能支持多少并发再把这个值设成算出来的八成左右留出余量。3.3 前缀缓存多轮对话场景的隐形加速器多轮对话、固定系统提示、few-shot 模板这三类场景有个共同点每次请求的开头一大段是完全重复的。前缀缓存把这段重复内容的 KV 直接复用跳过重复计算长系统提示的场景下首包时间能降一大截。实现上通常用前缀哈希来做匹配要注意几个细节。一是缓存的淘汰策略块池满了之后按 LRU 淘汰如果你的流量里有一批低频但超长的历史会话它们会把有价值的短前缀挤掉二是前缀必须严格从第一个 token 开始匹配中间插入了动态内容比如时间戳就完全失效所以系统提示里别放会变的东西三是多租户场景要隔离别让 A 用户的缓存被 B 用户命中那是数据安全问题。4. 算子与编译优化从注意力算子到图级别融合前面的手段偏“资源管理”这一层开始动计算本身。说实话这块的收益不像量化那么立竿见影但在延迟敏感的场景里最后的几百毫秒往往就藏在这些地方。4.1 注意力算子融合与 FlashAttention 的版本选择标准注意力实现要把完整的注意力矩阵算出来写到显存再读回来上下文一长这个中间矩阵就是几百 MB显存读写成了瓶颈。分块计算加在线 softmax 的思路是把 Q、K、V 切块边算边归一化中间结果始终留在片上高速缓存里不落显存。这一改动让长上下文的注意力和显存占用都从平方级降下来。选版本的时候看几个点head_dim 是否在支持范围内常见实现支持到 256超过就得换方案、是否支持 GQA 的 KV 头复用、是否支持滑动窗口注意力、数据类型是否匹配。踩过的坑是版本和硬件代际不匹配——老卡上用了只对新架构优化的实现编译能过跑起来反而比朴素实现还慢白折腾。升级框架的时候记得回归压测一遍别默认新版一定更快。4.2 图编译、CUDA Graph 与算子融合的实践decode 阶段每生成一个 token要启动几百上千个 kernel每次启动都有几微秒的固定开销累积起来能占总时间的两成。CUDA Graph 的做法是把整个 decode 步骤的 kernel 调用序列录下来后续直接回放把启动开销压到接近零。用的时候要注意动态 shape 的问题batch 大小和序列位置每步都在变直接录制会失效。常见做法是为几个固定的 batch 尺寸分别录制图运行时按实际 batch 就近取用或者用 padding 把尺寸对齐到固定值。padding 会带来一点算力浪费但换来的是稳定的延迟在线服务里这笔交易通常是划算的。算子融合这边效果比较明显的是 RMSNorm 加 QKV 投影融合、RoPE 位置编码融合、SiLU 加逐元素乘融合。融合的本质是减少中间结果的显存往返一次读写搞定多步计算。这类优化大部分主流框架已经内置自己动手前先确认是不是已经开了。4.3 并行切分TP、PP、EP 的适用边界单卡放不下就得切。张量并行是把每一层的矩阵按列或按行切开分到多张卡上每层计算完要同步一次通信极其频繁所以强依赖卡间的高速互联。没有高速互联硬上张量并行通信开销能把收益吃干净甚至比单卡还慢这个坑我见过太多次。流水并行是按层切分把模型的不同层放到不同卡上通信量小很多但存在流水气泡——前一段在算、后一段在等。适合跨节点部署配合足够多的微批次能把气泡填掉大半。专家并行是针对 MoE 架构的把不同专家分到不同卡上路由决定通信模式属于另一套体系。粗略的经验是能塞进单卡就别切非要切优先在节点内做张量并行卡数不超过 8跨节点用流水并行微批次数量至少是流水段数的四倍以上。5. 解码加速投机解码与约束输出的实战到这里资源利用率和算子效率都榨得差不多了剩下的空间在解码算法本身。投机解码是我认为近两年最实用的一类加速手段但它的收益高度依赖任务类型用错地方会白忙一场。5.1 投机解码的收益条件和加速比估算思路很直白用一个小模型或者额外的预测头先快速“猜”出后面几个 token然后让大模型一次性验证这几个 token验证通过的直接接受。因为验证是并行的一次前向就能确认多个位置等于用一次大模型前向换了多个 token。加速比可以估算。设草稿长度是 k、草稿模型的单步成本相对大模型是 c小模型通常 c 在 0.03~0.1 之间、每个位置的接受率是 α那么一轮期望产出的 token 数是 (1 - α^(k1)) / (1 - α)一轮的成本是 1 k·c两者相除就是加速比。代入数字感受一下α0.7、k4、c0.05期望产出 (1-0.168)/0.3 ≈ 2.77 个 token成本 1.2加速约 2.3 倍。如果 α 掉到 0.5期望产出变成 1.94加速就只剩 1.6 倍了。α 低于 0.4 基本没什么意思还不如把这部分资源拿去加并发。关键结论接受率决定一切。而接受率又取决于任务分布——代码补全、文本改写、翻译、摘要这类“高确定性”任务α 能到 0.7 以上开放式创作、头脑风暴这类多样性高的任务α 经常掉到 0.5 以下。所以别指望一个配置通吃所有场景按业务线分别开关才是正解。5.2 草稿来源的几种选型对比草稿模型不一定要独立的小模型常见有四条路线。独立小模型最通用同系列的小尺寸版本效果最好因为词表和训练分布一致接受率天然更高。自投机是用大模型自己的部分层做草稿省一份模型显存但实现复杂。额外预测头比如在模型上加几个头直接预测后续 token不需要第二份模型显存开销小适合显存紧张的场景。还有一种是 n-gram 或前缀匹配直接从 prompt 和历史里找重复片段当草稿对 RAG 问答、文档改写这类“大量复制原文”的场景奇效几乎零成本。我自己的搭配习惯是RAG 和摘要类业务优先上 n-gram 匹配成本最低收益最直接代码和结构化输出业务上小模型草稿开放对话默认不开把它做成可配置开关按租户或按场景灰度。5.3 结构化输出与约束解码的加速JSON 输出、枚举分类、固定格式抽取这类需求用约束解码能同时拿到“格式绝对正确”和“速度更快”两个好处。原理是在每个解码步用状态机把不合法的 token 直接屏蔽掉搜索空间小了出错重试的次数也少了——很多人没算过重试的成本一次格式错误导致的重试比任何算子优化都贵。要注意的是掩码本身的开销。词表动辄十几万每步都全量算一遍掩码在小 batch 下这个开销能占到两三成。优化方式是预编译状态转移表把“当前状态 已生成前缀”到“合法 token 集合”的映射提前算好运行时只做查表和按位与。另外把 JSON schema 转成状态机的时候要小心递归结构嵌套太深的状态机会爆炸最好在业务层限制嵌套层数。6. 部署选型与压测从能跑到扛得住前面讲的是“怎么优化”这一节讲“怎么验证优化是真的”。我见过太多团队优化做完指标是拿固定长度、固定并发、跑十分钟测出来的一上真实流量全线崩盘。压测方法错了比不压测更危险。6.1 推理框架的选型维度选框架别只看跑分跑分榜上的配置几乎都不是你的场景。我一般按这几个维度排优先级硬件支持是否完整你的卡、你的互联、你的量化格式、调度能力连续批处理、前缀缓存、抢占策略、量化生态主流量化格式是否原生支持、可观测性能不能导出细粒度指标、以及运维成本。通用服务型框架的优势是迭代快、社区方案多、量化格式支持广适合绝大多数在线服务编译型方案在特定硬件上能把 kernel 榨得更狠首包和吞吐通常更好看但量化格式受限、模型适配周期长、调参空间小适合模型固定、流量稳定的场景轻量本地方案适合端侧和离线批处理量化激进、依赖少但并发调度能力弱别拿它扛在线流量。方案类型吞吐表现首包延迟量化灵活度适配成本适用场景通用服务框架中高中高低在线服务主力编译型方案高低中低高模型固定、流量稳定轻量本地方案低中高低端侧、离线批处理6.2 压测方法论造对负载比调对参数更重要第一件事是把输入输出长度的分布做对。真实流量的长度分布是长尾的用固定长度压测会严重高估性能——因为调度器最怕的就是长度参差。我的做法是从线上日志采样统计输入和输出长度的分位数然后用对数正态分布去拟合生成压测请求保证 P50、P90、P99 都对得上。第二件事是爬坡找拐点。从低并发开始每轮加一定并发观察输出吞吐和 TPOT 两条曲线。吞吐随着并发上升而上升到某个点开始走平甚至下降同时 TPOT 快速恶化那个点就是系统的容量拐点。生产环境把并发控制在拐点的七成左右留出应对突发的余量。第三件事是看对指标。GPU 利用率要区分是算力利用率还是显存带宽利用率decode 阶段以后者为准。还要盯显存峰值随时间的曲线看有没有缓慢增长的泄漏迹象。P99 一定要单独看均值和中位数会骗人。# 显存需求快速估算用于上卡前的容量规划 def estimate_memory(num_params_b, layers, kv_heads, head_dim, weight_bytes, kv_bytes, seq_len, concurrency, overhead_gb3.0): # 权重显存参数量 x 每参数字节INT4 约 0.55 计入 scale 开销 weight_gb num_params_b * 1e9 * weight_bytes / (1024 ** 3) # 单 token KV 字节K 和 V 各一份 per_token 2 * layers * kv_heads * head_dim * kv_bytes kv_gb per_token * seq_len * concurrency / (1024 ** 3) total weight_gb kv_gb overhead_gb return round(weight_gb, 1), round(kv_gb, 1), round(total, 1) # 示例一个 32 层、8 个 KV 头、head_dim 128 的模型 # 权重 INT4、KV FP16、8K 上下文、32 路并发 print(estimate_memory(70, 32, 8, 128, 0.55, 2, 8192, 32))跑一下这段权重约 35.8GB、KV 约 32GB、加上预留合计七十多GB单张 80GB 卡刚好卡在边缘——这时候要么把并发降到 24要么把 KV 量化到 FP8两条路都能走通选哪条取决于你对输出质量的要求。6.3 一份可参考的启动配置配置没有标准答案但结构是通用的。下面这份是长上下文问答场景的起点参数含义我标在注释里你可以按实测结果微调。server: max_model_len: 16384 # 最大上下文直接影响 KV 峰值 gpu_memory_utilization: 0.90 # 留一成给框架和碎片别贪到 0.98 max_num_seqs: 24 # 并发上限按显存反推后打八折 max_num_batched_tokens: 4096 # 单批 token 上限长文档场景取大值 enable_chunked_prefill: true # 长 prompt 切块避免卡住 decode enable_prefix_caching: true # 系统提示固定的场景必开 block_size: 16 # KV 分页块大小 kv_cache_dtype: fp8 # 长上下文场景开短对话可关 quantization: awq_int4 # 权重格式与转换时保持一致 speculative: enabled: true # 按业务线灰度别全局开 draft_len: 4 # 草稿长度4 是通用起点 acceptance_threshold: 0.55 # 低于该值自动关闭调参的顺序建议是先定 max_model_len 和并发跑一轮基准再开 chunked prefill 和前缀缓存看首包是否改善然后上 KV 量化和投机解码每步单独测、单独记录。一次改多个参数出问题根本定位不到是哪一项导致的。7. 常见问题与排查实录线上问题基本逃不出三类吞吐上不去、质量掉下来、延迟抖得厉害。下面是我整理的排查路径按命中率排序遇到问题从上往下试。7.1 吞吐上不去的典型原因先看 GPU 利用率。如果利用率长期低于四成说明瓶颈不在算力八成是批处理没跑满或者请求排队机制有问题——检查并发上限是不是被设得太小或者上游连接池限制了实际并发。如果利用率很高但吞吐还是低看显存带宽利用率带宽跑满说明是 decode 阶段受限这时候提高并发能把带宽摊薄收益最直接。还有一种情况是请求长度极不均衡长请求堵在队列前面短请求全在等。解决办法是分队列长短请求走不同的实例或者开启抢占式调度让短请求优先。另外检查一下是不是把张量并行开在了没有高速互联的机器上这个错误非常常见通信开销能把大部分算力吃掉。7.2 输出质量下降的定位路径质量问题的定位要二分法先切回 FP16 全精度跑同样的输入如果问题消失那就是量化或者 KV 缓存搞的如果还在那问题在采样参数、提示词或者上下文截断。量化方向再细分把 KV 量化关掉只留权重量化看是否恢复能快速区分是权重问题还是缓存问题。权重问题一般是校准集不匹配重新采样校准集再转一次缓存问题大多是长上下文累积误差把 KV 精度提上去或者缩短最大上下文。还有一种很隐蔽的情况是上下文被静默截断。max_model_len 设小了超长输入被悄悄截掉前半部分模型表现就是“忘了前面说的”。日志里一般有警告但要主动去看。7.3 OOM 与长尾延迟的应急手段OOM 最常见的原因不是权重而是并发估算错误。先按 6.2 节的脚本反推真实并发上限把配置改小。第二个常见原因是内存碎片长时间运行后显存碎片化严重重启能缓解但要治本得靠分页机制和定期清理前缀缓存。第三个是批处理中的超长请求一个 32K 上下文的请求进来直接把缓存池撑爆解法是在入口做长度校验和分流。长尾延迟多数来自抢占和排队。检查日志里有没有缓存换出记录有的话说明并发设超了再看队列等待时间分布如果 P99 排队时间远大于平均那就是流量突刺或者某个实例不健康需要做负载均衡的健康检查。给请求加超时和降级策略也很必要宁可快速失败也别让用户等到天荒地老。现象高频原因快速验证方式吞吐低但 GPU 闲并发上限过小、上游限流提升并发看吞吐是否线性增长吞吐低且 GPU 忙decode 带宽受限、并行通信开销看显存带宽利用率、关并行对比首包特别慢长 prompt prefill、前缀缓存未命中拆短 prompt 对比、查缓存命中率出字忽快忽慢批大小波动、抢占换出看 TPOT 分布、查换出日志质量下降量化误差、上下文截断切回全精度、关 KV 量化对比我在实际项目里的体会是推理优化这件事最忌讳“一次性大招”。真正有效的做法是把每一项改动单独量化、单独压测、单独记录形成一个可回滚的配置矩阵。很多时候你以为的瓶颈和你实际改的东西根本不是一个只有一轮一轮对比才有答案。另外别迷信跑分榜那些数字的硬件配置、输入分布、并发模型几乎都和你不一样拿自己的流量压一遍比看十篇评测都管用。最后一个容易被忽略的点把优化开关做成运行时配置而不是编译期常量。业务的流量特征会变今天是短问答下个月可能是长文档参数跟着调才不至于推倒重来。上线前留一个“一键回退到保守配置”的通道关键时刻能救命。