第 8 章 性能调优与监控：让服务持续体面

第 8 章 性能调优与监控：让服务持续体面

章节摘要：主线场景的最后一程是运营：上线不是终点，流量会变、模型会换、故障会来。本章沿"闭环"这条追因线走：显存与调度怎么调（8.1）、内核与批参数怎么压榨（8.2）、用什么口径压测、盯哪些指标（8.3）。读完本章，你拥有一套可循环的运维方法——改配置、跑压测、看曲线、定位瓶颈、再改配置。

一条主线

主线场景的服务上线两周后，遇到了所有推理服务都会遇到的三件事：运营要做大促（流量翻数倍）、算法换了新版本模型（显存特征变了）、用户抱怨"有时候打字会卡一下"（偶发毛刺）。三件事指向同一个缺口：没有闭环。没有压测口径，容量规划靠拍脑袋；没有监控基线，故障定位靠猜；没有调优顺序，参数改动靠运气。

本章的任务就是把这个闭环搭起来。它不引入新机制——前七章的所有知识在这一章被组织成方法：8.1 把显存与调度参数的调优路径排成决策链；8.2 深入内核与批处理层的进阶压榨；8.3 定义压测口径与监控指标集，给出"从曲线到根因"的排查对照表。三条支线合起来是一个循环：度量 → 定位 → 调整 → 再度量。

沿途站点

• 8.1 显存与调度调优：把散落在前七章的调优动作串成两条决策链——显存紧张时的动作顺序（降上下文 → 缓存降精度 → 量化 → 并行）与调度不适时的检查顺序（并发对账 → 抢占频率 → 队列形态）。
• 8.2 内核与批参数压榨：CUDA 计算图与算子层级的进阶开关；prefill 分摊、批参数与延迟的三角关系；什么时候"关闭优化"反而是优化。
• 8.3 压测基准与监控指标：官方压测工具的使用口径（请求分布、并发斜坡、分位统计）；监控指标集（吞吐、TTFT/TBT 分位、块池水位、批大小、抢占计数）各自的正常形态与异常信号；从曲线到根因的排查对照表。

拐点与结论

本章的拐点是把性能当成过程而不是状态。一次性的调优会在下一个流量周期、下一个模型版本面前失效；只有"压测口径固定、监控基线在案、每次改动有前后对比"的团队，才能在变化中持续保持体面。第 7 章结尾那句话在这里成为制度：任何调参过压测口径——本章把这个要求落成可执行的流程。

结论层面，本册的追因线在此收拢：显存账（第 2 章）给了你预估容量的算尺，块表与批处理（第 3、4 章）给了你读懂曲线的能力，缓存与投机（第 5 章）给了你降本的两张牌，量化并行（第 6 章）给了你扩容的两条路，部署与参数（第 7 章）给了你动手的入口——本章把这些拧成一个可持续运转的方法论。

读完你应该

1. 为自己的业务定制一套压测口径：请求长度分布、并发斜坡、统计分位；
2. 画出本册提到的监控指标集，并写出每个指标的"正常形态"描述；
3. 按决策链处理一次显存紧张：说出每个动作的收益量级与代价；
4. 从"偶发 TBT 毛刺"出发完成一次完整排查，定位到抢占、网络或内核；
5. 为模型版本升级设计性能验收流程，避免"换模型悄悄丢了吞吐"；
6. 把本章闭环制度化：改动有对比、基线有存档、告警有阈值。

三个可以立刻自查的问题

进入正文前，先拿这三个问题自检现状：你的服务最近一次压测报告是什么时候、用的什么口径？值班同学收到告警时，能否在两分钟内判断是容量问题还是故障？最近一次参数改动，有没有留下改前改后的对比数据？三个问题都答不上来，说明闭环缺失，本章就是为你写的；都能答上来，本章的对照表与指标集可以作为查漏补缺的清单快速过一遍。

主线的终点

到这里，开篇那个问题——"同样一张卡，为什么有的部署吞吐差数十倍"——已经可以完整作答：差的不是算力，是对显存、时间与重复劳动的组织方式。把这条追因线走完的人，看到的将不再是一个推理框架，而是一套可以迁移到任何算力密集系统的资源组织方法论。