8.1 显存与调度调优：两条决策链

8.1 显存与调度调优：两条决策链

本节摘要：显存紧张与调度不适是运维期最常见的两类症状。本节把前七章的机制知识组织成两条决策链：显存紧张时按"降上下文 → 缓存降精度 → 权重量化 → 并行"的顺序出手；调度不适时按"并发对账 → 抢占频率 → 队列形态"的顺序排查。每一步都标注收益量级与代价，让调优从试错变成推演。

为什么同样的症状，有人一步就调到位，有人改了一天参数反而更糟？差别通常不在熟练度，而在出手顺序：调优动作之间有依赖与互斥，顺序错了，轻则无效，重则互相抵消。本节把散落在前七章的调优动作组织成两条可推演的决策链，每一步给出收益量级、代价与判断依据。

第一条链：显存紧张时的动作顺序

症状：块池水位长期贴顶、并发上不去、洪峰抢占频繁。按下面的顺序逐级出手，每级都先评估"够不够"，不够再下一级：

第一级 降上下文上限（max-model-len）
  收益：随下调比例线性放大。32K 降到 8K，单请求峰值缓存降到四分之一。
  代价：超限请求被拒或需截断。前提：业务真实长度上限明确。
  这是唯一"只有收益"的级别——但常被忽略，因为太朴素。

第二级 缓存降精度（kv-cache-dtype fp8）
  收益：块池容量翻倍上下。长上下文负载收益显著。
  代价：需要第 6.2 节的回归评测；老硬件无加速或直接不可用。

第三级 权重量化（quantization awq / gptq / fp8）
  收益：权重显存砍半以上，腾出的显存全是块池；decode 还会提速。
  代价：质量风险随任务敏感度上升，必须过自建评测。

第四级 并行扩容（tensor-parallel-size / pipeline-parallel-size）
  收益：容量按卡数倍增，解决"物理上装不下"。
  代价：通信与气泡是实打实的吞吐折扣，且成本按卡数线性上涨。
​

这条链的排序逻辑是代价递增：前两级只动软件配置，第三级引入质量风险，第四级引入真金白银的硬件开销。实践中大量"显存不足"的工单止步于第一级——先问一句"业务真的需要 32K 上下文吗"，比任何高级手段都划算。

一条反向的提醒：显存"用得满"不等于"紧张"。第 5 章讲过，前缀缓存会把空闲块池填满，水位高是设计使然。判断紧张与否要看的是抢占计数与等待队列，而不是水位曲线本身——水位九成加上零抢占，是健康状态；水位九成加上持续抢占，才是容量不足。

第二条链：调度不适时的排查顺序

症状：TBT 毛刺、TTFT 忽高忽低、吞吐不如压测成绩。排查按证据链走：

第一步 并发对账
  max-num-seqs × max-model-len 对应的峰值缓存，是否超出块池容量？
  超出 → 配置性饥饿，先改配置再谈别的。

第二步 抢占频率
  日志里 Preempted 计数：偶发（分钟级一次）属正常兜底；
  持续出现 → 容量不足或并发上限过激，回到第一条链。

第三步 队列形态
  等待队列长期为零但 TTFT 高 → 瓶颈在 prefill，看 8.2 的 prefill 配额；
  队列随流量波动 → 到达模式问题，考虑入口限流或平滑。

第四步 毛刺对齐
  TBT 毛刺时刻与抢占日志对齐 → 抢占毛刺，容量问题；
  对不齐 → 网络层或内核层，继续分流排查。
​

这条链的价值在第一步的"并发对账"：它是一个纯算术检查，两分钟做完，却拦截了最常见的配置性慢性病——并发上限与块池容量不匹配，调度器长期在刀尖上跳舞。

一张对照表：症状、根因与动作

⚠️ 调优纪律：一次只改一个变量。同时动三个参数后性能变化，你永远说不清是谁的功劳或过错；顺序执行、逐项验证，每步留下前后数据，两周后你就拥有一份自己业务的调优手册——它比任何通用指南都值钱。

案例：一次"换模型后吞吐腰斩"的完整复盘

把两条决策链串起来用一遍。某服务把 8B 模型换成 14B 后，同等压测口径下吞吐接近腰斩，团队最初怀疑"新模型质量差拖慢速度"。按决策链走：

显存对账：新模型权重翻倍，块池缩水近半；max-model-len 仍是 32K（旧模型的配置）。
第一级动作：按业务真实上限把上下文降到 8K —— 块池恢复到换模型前的可用规模。
复测：吞吐恢复九成。剩余差距来自权重搬运变长（decode 每步更慢，物理规律）。
补一刀：缓存降到 FP8（第二级），块池再宽一倍，抢占归零，P99 TBT 回稳。
结论：不是模型的问题，是换模型后没人重算显存账。
​

这个案例的价值在于揭示了最常见的那类事故：配置是跟着旧模型的特征调的，模型换了，账没跟着换。把"换模型必重跑显存对账与压测基线"写成变更流程的固定条目，此类事故即可绝迹。

两条链之外的第四类症状：偶发而不复现的慢请求

运维报告里还有一类麻烦：万里挑一的请求特别慢，复现困难。按本册的知识给一个排查框架：先拉该请求的追踪日志，看时间花在排队（到达时刻恰逢洪峰，等待队列的回溯）、抢占（被换出又恢复）、还是 prefill（超长输入）。三类对应三种处理——排队看容量与限流，抢占看 8.1 对账，prefill 长则属于用户输入本身的代价，产品侧做长度提示即可。偶发慢请求大多不是故障，是重尾流量与洪峰叠加的统计必然，有了框架就不必每次都当成事故来查。

调优的止损线：什么时候该停下来扩容

决策链走到尽头仍不达标时，要有一条止损线：块池对账无余量、量化已用、上下文已是业务下限、抢占仍持续——此时参数空间已经穷尽，继续调参的边际收益趋零，而每次实验都有引入回归的风险。扩容（加卡或加实例）看起来是最贵的选择，但换算成工程师的时间成本后常常是最便宜的。调优的目的是榨干已有资源，不是用无限的时间对抗物理上限——知道何时收手，也是这门手艺的一部分。

本节要点回顾

• 显存紧张按代价递增出手：降上下文 → 缓存降精度 → 量化 → 并行；多数工单止步于第一级。
• 水位高不等于紧张：判断看抢占计数与队列，不看水位本身。
• 调度排查从算术开始：并发对账两分钟，拦截最常见的配置性饥饿。
• 毛刺要靠日志对齐定位：抢占毛刺对得上日志，对不上的再查网络与内核。
• 一次一个变量：逐项验证留数据，攒出自己业务的调优手册。

决策链解决"往哪个方向调"，但调到什么程度算到头？下一节下探到内核与批参数层，看看最后的几个百分点藏在哪里。