大模型推理服务上线检查清单：容量测试、监控告警、灰度与回滚

一、固定测试环境

上线前先冻结模型版本、量化方式、推理框架、CUDA与驱动版本、GPU型号、张量并行参数和启动命令。每次测试都记录镜像摘要和配置文件，避免结果无法复现。

准备三组输入：短提示词用于测首字延迟；接近真实长度的常规请求用于测稳定吞吐；超长上下文用于验证显存保护和超时策略。输出长度也应分档，不能只用十几个token的简单请求。

二、完成容量测试

逐步提高并发，记录每一级并发下的首字延迟、每token延迟、总吞吐、GPU利用率、显存、CPU、主机内存和网络。找到延迟开始急剧上升的拐点，并把生产限流设置在拐点之前。

容量结论应写成“在某输入长度、输出长度和延迟目标下，可稳定支持多少并发”，而不是只写每秒生成多少token。连续运行至少两小时，观察显存泄漏、请求积压和吞吐衰减。

三、设置保护边界

必须限制最大输入长度、最大输出长度、单用户并发和总队列长度。对超长请求提前估算token并拒绝或降级，避免一个请求占满KV缓存。设置连接超时、排队超时、首字超时和总请求超时，并区分可重试错误与不可重试错误。

四、建立监控与告警

基础指标包括请求量、成功率、各分位延迟、排队长度、生成token数、GPU利用率和显存。还应监控进程重启次数、CUDA错误、OOM、模型加载时间、节点温度和磁盘空间。

日志中保留请求ID、模型版本、输入输出token数、耗时和错误类型，但不要默认记录用户完整输入。涉及敏感数据时应做脱敏并设置日志保留期限。

五、灰度发布

新模型或新镜像先接入少量内部流量，再逐步扩大。灰度期间同时比较错误率、延迟、输出质量和资源消耗。不要只因为速度变快就直接替换旧版本。

回滚方案必须在发布前准备，包括旧镜像、旧模型权重、配置文件和流量切换命令。目标是发现异常后几分钟内恢复，而不是现场重新下载模型。

六、故障演练与验收

主动终止推理进程，确认健康检查能够摘除节点；模拟GPU故障和网络中断，确认请求不会无限等待；重启节点，验证模型自动加载和服务恢复。最终验收报告应同时包含容量边界、告警截图、故障演练结果和回滚耗时。

只有单次请求成功不代表服务已经可以上线。生产就绪的核心是容量可预测、异常可发现、故障可恢复、版本可回退。