升级要管三个制品
版本升级实际上涉及三个独立制品：镜像（代码与依赖）、权重（模型文件）、配置（启动参数）。三者各自版本化与锁定，升级流程先在预发对比基准，再灰度单个实例、观察一段，最后全量。把它们混在一起改，出问题时根本无法归因。
基本信息
| 镜像 | 引擎版本、运行时与依赖，用不可变标签 |
|---|---|
| 权重 | 目录与修订号，与镜像解耦 |
| 配置 | 启动参数与模板，纳入版本管理 |
| 流程 | 预发对比、灰度、观察、全量 |
| 回退 | 旧制品保持可用 |
典型使用场景
- 引擎版本升级
- 模型权重替换
- 调整启动参数
- 三类变更集中发布时的流程设计
- 为每次升级保留一份变更单，写清三个制品与回退指向
- 做版本对比前先确认预发与生产的制品版本已经对齐
灰度观察点
灰度观察点
curl -s http://127.0.0.1:8001/metrics | grep -E 'num_requests|time_to_first_token'
# 另核对：错误率、KV 水位、首字与单 token 时间，与旧版本对比
# 观察窗口内不通过则回退指向旧制品三类制品的回退
| 制品 | 版本化方式 | 回退动作 |
|---|---|---|
| 镜像 | 不可变标签 | 指回旧标签 |
| 权重 | 目录或修订号 | 指回旧目录 |
| 配置 | 纳入版本管理 | 恢复上一版参数 |
回退路径要保持可用：旧镜像与旧权重在观察期内不要删除，回退只需要改指向，不必重新构建。
三类制品尽量分开升级：一次只动一个，观察窗口里的指标变化才有归因价值。
三类制品要有统一的版本记录：某次升级对应哪套镜像、哪份权重、哪版配置，必须能一眼查出来。
预发环境要尽量贴近生产：显存规格与流量结构差太多时，预发得到的结论无法外推。