示例成品 · 平台演示，按左边这组点选真跑出来的
# 模型上线前检查清单（预发环境全链路）
> 适用：Triton 推理服务器 + 文本生成大模型
> 环境：预发环境全链路
> 优先级：P0 = 历史故障复现点/不通过不允许上线；P1 = 高风险；P2 = 常规确认。
> 执行人：______ 日期：______ 结论：______
## 0. 上线前准备
- [ ] 0.1 确认本次上线的模型版本、`config.pbtxt`、Triton 镜像 tag、配置 commit 一致，并记录在发布单。P0
- [ ] 0.2 上一版本模型和配置已备份，回滚步骤已写清楚。P0
- [ ] 0.3 预发环境与生产环境的差异点已列出，尤其是降级开关、模型路径、GPU 卡数、租户配置。P1
- [ ] 0.4 预发环境全链路确认：上游调用方、网关/鉴权、Triton、日志/监控链路已打通，使用与生产一致的调用路径。P1
## 1. 部署与启动
- [ ] 1.1 Triton 健康检查：`curl -s http://预发Triton:8000/v2/health/ready` 返回 `true`；`/v2/models/{模型名}/ready` 返回 `true`，模型状态 READY，无反复 loading/unloading。P0
- [ ] 1.2 版本正确：`/v2/models/{模型名}` 返回版本与本次上线一致，`config.pbtxt` 中 `version_policy` 没有误指向旧版本。P0
- [ ] 1.3 启动日志无错误：无 CUDA OOM、模型加载失败、配置解析错误。P0
- [ ] 1.4 资源占用：`nvidia-smi` 确认 GPU 显存占用在预期范围，预留至少 20% 余量；CPU/内存无异常。P1
- [ ] 1.5 模型加载方式：确认 Triton `--model-control-mode` 配置符合发布流程；模型仓库变更后能按预期加载新版本。P2
## 2. 核心功能回归（含上次已验证项）
- [ ] 2.1 **输入数据格式校验**（上次已验证，本次回归）
做法：用空 body、缺少 `prompt`、`prompt` 类型错误、`max_tokens` 超限/负数、temperature 越界、错误 JSON / 错误 tensor shape 分别打 HTTP 和 gRPC 接口。
预期：返回明确 4xx 业务错误码或错误信息，不崩服务，不输出堆栈。P1
- [ ] 2.2 **模型输出稳定性**（上次已验证，本次回归）
做法：固定 seed 或 `temperature=0`，同一 prompt 连续请求 20 次。
预期：输出一致或仅差标点/空格；随机模式下无乱码、无截断、无重复循环；`max_tokens` 和 stop 序列生效。P1
- [ ] 2.3 **Prometheus 监控埋点**（上次已验证，本次回归）
做法：访问 `http://预发Triton:8002/metrics`，确认 `nv_inference_request_success`、`nv_inference_request_failure`、`nv_inference_queue_duration_us`、`nv_inference_compute_infer_duration_us`、`nv_gpu_utilization` 等指标存在；打 10 个请求后计数增加，Grafana 看板能看到。
预期：监控指标准确，请求量/错误数/延迟可视化。P1
- [ ] 2.4 **降级开关真实生效**（P0 历史故障复现点）
做法：手动打开你们配置里的降级开关（如配置中心 `degrade.enabled=true` 或环境变量 `DEGRADE_MODE=1`），等待配置下发到预发实例；再关闭。
预期：打开后服务不再调用模型推理，返回预设降级响应/固定话术，接口不报 500，日志有降级标记，监控有降级计数；关闭后恢复正常推理。保留开关切换时间、操作人、截图/日志。P0
## 3. 重点专项测试（本次待重点测）
- [ ] 3.1 **异常输入兜底响应**
做法：发送空字符串、纯空格、超长 token（超过模型上下文）、非法 UTF-8、控制字符、SQL 注入/提示注入文本、只有特殊符号、多语言混杂、重复同一 token 等。
预期：每个异常输入都有明确兜底响应或错误码，不返回堆栈，不把异常内容当成正常 prompt 生成，服务不重启。P1
- [ ] 3.2 **敏感词拦截准确率**
做法：用评审过的敏感词测试集（至少覆盖政治/色情/暴力/违法/隐私等类别，敏感样本 ≥100 条，正常样本 ≥100 条）分别测输入侧和输出侧。
预期：敏感样本拦截率 ≥99%，正常样本误杀率 ≤1%（具体阈值按业务确认），拦截时返回统一安全提示，不输出敏感内容。P0
- [ ] 3.3 **多租户隔离验证**
做法：使用租户 A、租户 B 的独立密钥/namespace/配置分别请求；再用 A 的身份尝试访问 B 的模型配置、历史会话、缓存、日志。
预期：返回明确无权限或隔离错误，A 的输出和日志中不出现 B 的数据，`tenant_id` 在日志/指标中正确透传。P0
## 4. 性能与稳定性
- [ ] 4.1 并发压测：按生产预估 QPS 的 1.5 倍打流 30 分钟。预期：错误率 <0.1%，P99 延迟在 SLO 内，GPU 利用率稳定，无队列堆积。P1
- [ ] 4.2 长文本输入：使用接近模型最大上下文长度 80% 和 100% 的输入。预期：不超时、不截断、不 OOM。P1
- [ ] 4.3 超时与限流：设置客户端超时和 Triton 队列超时，超过阈值时返回明确超时/限流错误码，不积压请求。P1
- [ ] 4.4 动态批处理：开启 dynamic batching 后，检查不同 batch 大小下吞吐和延迟是否符合预期，无 batch 越大错误越多。P2
- [ ] 4.5 重启/重载：预发环境重启 Triton 服务或重载模型，确认模型能正常加载，请求不中断或中断时间可控。P1
- [ ] 4.6 全链路联调：从上游调用方按生产调用链发起请求，检查网关→Triton→日志/监控全链路 `request_id` 透传一致，各段耗时正常。P1
## 5. 监控、日志与告警
- [ ] 5.1 关键指标齐全：请求量、成功/失败数、延迟分位数、队列长度、GPU 利用率/显存、降级状态指标均能在 Prometheus 查到。P1
- [ ] 5.2 日志可追踪：日志包含 `request_id`、`tenant_id`、模型版本、耗时、错误码；不记录用户原始 prompt 和生成结果中的敏感明文。P0
- [ ] 5.3 告警验证：手动触发一次错误率上升/降级开关打开/GPU 显存过阈值，确认告警能发到值班渠道。P1
## 6. 安全与合规
- [ ] 6.1 接口鉴权：Triton HTTP/gRPC 接口需鉴权，未带 token/带错 token 的请求被拒绝。P0
- [ ] 6.2 权限最小化：确认预发环境使用的 token/密钥只有本次链路所需权限，无多余管理权限。P1
- [ ] 6.3 敏感词拦截与日志脱敏：与 3.2、5.2 一起验证，不单独放水。P0
## 7. 回滚与预案
- [ ] 7.1 回滚验证：执行一次回滚到上一版本模型/配置，确认服务恢复，接口正常。P0
- [ ] 7.2 降级开关演练：在生产配置相同条件下，打开降级开关并观察流量切换，再关闭恢复。P0
- [ ] 7.3 值班人确认：值班同学知道如何打开/关闭降级开关、如何回滚、如何看监控。P1
## 8. 上线前最终确认
- [ ] 所有 P0 项通过且记录可查
- [ ] 所有 P1 项通过或有明确风险接受人
- [ ] 本次上线说明包含：模型版本、配置变更、降级开关状态、回滚步骤、值班人
点左边「开工 · 直接出成品」，出一份你自己的版本（文字免费）