运维与升级
每种变更先验证、各有回退点，看板要有质量一行
模型在企业自己的机房里跑，运维要保住的是服务质量，不只是容器。引擎镜像、模型权重、嵌入模型、向量索引、配置，每一种变更上线前都过同一道闸，也各有自己的回退点。只做试用、答案不进业务流程时，这道闸过重，不适用。
看板与监控
只看容量和温度的看板，抓不到质量退化：模型换了、索引重建了，GPU 照常运转，答案却可能变差。监控分层，每层回答不同的问题。下面以 Prometheus 抓取、Grafana 看板为例，引擎与 GPU 采集器是两个抓取目标。
| 层 | 指标 | 回答什么 |
|---|---|---|
| 引擎 | vllm:num_requests_waiting | 排队的请求是否在堆积 |
| 引擎 | vllm:kv_cache_usage_perc | KV 缓存是否接近用满 |
| 引擎 | vllm:time_to_first_token_seconds | 首个 token 的等待时间分布，与验收时的 TTFT 比 |
| 引擎 | vllm:prefix_cache_hits、vllm:prefix_cache_queries | 前缀缓存的命中情况，两个计数器之比 |
| GPU | DCGM_FI_DEV_GPU_UTIL、DCGM_FI_DEV_FB_USED | GPU 在不在忙，显存用了多少 |
| GPU | DCGM_FI_DEV_GPU_TEMP、DCGM_FI_DEV_POWER_USAGE | 温度与功耗是否异常 |
| GPU | DCGM_FI_DEV_XID_ERRORS | 驱动报出的 XID 错误 |
| 质量 | 评测集周期回放 | 引用正确率、应拒答的题是否拒答、回答是否忠于检索片段 |
指标名出自 vLLM 指标页与 DCGM Exporter 指标页，名称随版本变化，上线前对着实际的 /metrics 输出核对。DCGM Exporter 把 NVIDIA 显卡的状态转成 Prometheus 能读的文本，其他厂商的显卡按其工具另配。ECC 错误和降频原因在 DCGM Exporter 里默认不开，需要时在采集配置里打开（同一指标页）。
告警阈值不预设数值，取自验收时的基线：验收测得的 TTFT p95 和最高达标并发，是后续告警的参照。质量一行没有现成的指标，靠评测集周期回放得出，回放的周期和样本量按企业要求在合同中约定。
看板红了，能分清是容量问题、硬件问题，还是答案变差了。
变更分类与回退
下表是这类系统通行的变更分类与做法。每次变更的时间窗和检查项，写进部署记录。
| 变更对象 | 上线前验证 | 回退方式 | 是否中断服务 |
|---|---|---|---|
| 引擎镜像 | 能启动，接口返回正常，/metrics 有输出，评测集与压测不劣于验收基线 | compose 里的 tag 改回上一版并重建；上一版镜像与配置留存，不必重新导入 | 单机重建期间短暂中断 |
| 模型权重 | 评测集与压测都要重跑，模型换了，质量与容量都会变 | 新权重放在新目录，旧目录保留为只读；指回旧目录并重启 | 重启期间中断 |
| 嵌入模型 | 新模型重嵌入全库，建成新索引，再跑评测集比较检索命中 | 旧嵌入模型与旧索引保留到新索引通过为止；通过前随时切回 | 建新索引期间，旧索引继续服务；需要额外存储 |
| 向量索引（重建或改参数） | 同上，另看检索耗时 | 保留上一版索引 | 同上 |
| 配置（启动参数、出站规则、告警规则） | 启动参数会改变显存占用与并发，需要重跑压测；出站规则改动后复测一次失败的对外连接 | 还原上一份配置文件 | 视改动而定，改启动参数需重启 |
换嵌入模型必须重建整个索引，因为不同模型产生的向量，即使维度相同，也不在同一个空间里，不能混着比较。所以回退引擎镜像，回不到旧的检索质量；旧的嵌入模型和索引不留，就没有回退点。
回退点在变更之前建好，不在出了问题之后补。核心经营系统本身的上线与回滚，是另一套做法，见发布与回滚：库里的结构只加不改，回滚只切回上一版程序。推理服务这一侧回退的是镜像、权重、索引和配置这几样。
没有测试环境时的验证
「新版先在测试环境验证」对三档规模不是都做得到。
| 条件 | 做法 | 代价 |
|---|---|---|
| 一柜：两台推理机，每台都能独立装下所用模型 | 先在其中一台上验证，通过后再切另一台 | 验证期间只剩一台服务，容量降到一半，冗余暂时消失 |
| 一台：显存放得下新旧两份 | 同机另起一个新实例，用另一个端口验证，通过后切换 | 显存要容得下新旧两份权重与各自的 KV 缓存 |
| 一台：显存放不下两份 | 在约定的停机窗口内切换，失败就切回 | 窗口内服务中断 |
升级入口
升级包怎么进来，由签约前选定的受控入口决定：
| 入口 | 更新包怎么进 | 日志与指标 | 排障 |
|---|---|---|---|
| 现场 | SZV 工程师到机房，用机房内终端操作 | 留在机房内 | 要等人到场 |
| 介质闸口或单向网闸 | 更新包经审核后单向进入 | 留在机房内，看监控也要到场 | 不能远程排障 |
| 堡垒机加录屏 | 每次会话由企业审批开通，全程录屏，到时关闭 | 会话期间可看 | 会话期间有一条受控连接，承诺降为「出站受控」 |
新镜像和新权重都要先过交付与验收里的入闸检查，再进入上表的变更流程。升级时间窗由 SZV 与对接负责人商定。
固定 tag 与 digest
镜像用固定 tag 或 digest，不用 latest。Docker 官方的构建建议写明，镜像 tag 可变，发布者能把它指向新镜像；钉住 digest 才保证总是同一个版本，代价是放弃自动的安全更新。所以安全更新要主动跟进。离线环境没有联网提醒，安全更新靠什么途径发现、由谁负责，在合同中约定。
故障处理
企业的故障先报 SZV，由 SZV 定位范围。定位之后，范围不同，处理的人也不同。
| 范围 | 做法 | 谁处理 |
|---|---|---|
| 推理服务 | 看日志与指标，必要时按上面的分类回退 | SZV |
| 设备 | 一台档：整机备件是冷备，换机期间服务中断；一柜档：两台推理机互为备份，容量降到一半；一间档：机房级灾备 | SZV，机房负责人配合 |
| 机房供电、制冷与出口 | 按机房规范处理 | 机房负责人 |
| 接入的系统 | 一起排查 | SZV 与对接负责人 |
每次故障的原因和处理写入部署记录，下次遇到同类问题可以直接查。
故障分级的字段，合同里要有：等级、影响范围（不可用、降级、单卡故障）、首次响应时限、恢复目标、升级路径、通知对象。字段在这里列出，数值不在公开页写，写进合同。
限制与不适用
- 每次变更都要跑回归与压测，升级比换个镜像慢。
- 建新索引要额外存储，同机验证要显存放得下两份。
- 一台档没有冗余，换机期间服务中断。
- 故障的响应时限与恢复目标写进合同，公开页不写数值。
- 试用环境、答案不进业务流程时，这道闸过重。
其他做法
| 做法 | 它解决什么 | 为什么不用 |
|---|---|---|
| 运维用常开的远程隧道 | 排障最省事 | 隧道本身是一条出站连接，有了它，零出站再无法用测试证明，见私有部署概览 |
镜像用 latest 或可变 tag | 省去升级工作 | 同一份配置在不同时间可能起出不同的镜像，验收基线随之失效 |
与常见做法对照
通行做法里，下面的与这里不同：
| 通行做法 | 好处 | 在私有部署里的代价 |
|---|---|---|
| 只回退引擎镜像 | 一步操作 | 回不了嵌入模型与索引，也回不了权重 |
| 滚动更新或蓝绿切换 | 异常只影响一部分流量 | 需要多实例与分流；一台档不具备，一柜档的两台推理机可以类比，代价是验证期间冗余消失 |
验收时可以问的问题
- 请按本机所属的档位，说明新版在没有测试环境时怎样验证。
- 故障的首次响应时限与恢复目标，请在合同中写明；夜间与节假日由谁接，也一并写明。
- 评测集周期回放的周期和样本量，以及质量退化时由谁决定回退，请在合同中写明。
- 请现场查变更权限表与部署记录：谁有权发起一次权重、嵌入或索引的变更，变更写在哪份记录里。
- 安全更新靠什么途径发现、由谁负责、经哪个入口带入，请在合同中写明。
- 备份包括哪些内容、放在哪里、恢复演练怎样做，请在合同中写明。