模型工程系列新篇。传统服务灰度看错误率、延迟——推理服务的灰度判据完全不同：代码没 bug 不等于模型没问题，质量退化不抛异常、不超时，只是悄悄地把译文翻得差一点。这篇聊推理服务灰度的三套判据和一套节奏。
为什么传统判据会漏
新模型版本上线，错误率 0%、延迟正常、吞吐持平——监控全绿。三天后用户反馈「翻译质量变差了」：新版本在长句上指代错误率翻倍。模型的质量维度是隐变量，业务指标不代理。灰度判据必须直接测质量。
三套判据，按成本递增
判据一：金丝雀集回归（必配）
上线前准备 500~1000 条「金丝雀集」：覆盖核心场景的真实样本（长短句、高频领域、历史 badcase）。灰度时新版本持续跑金丝雀集，对比基线：
- 硬指标：词级差异率（译文与基线的编辑距离分布）——分布右尾变长=行为漂移预警
- 质量指标：抽 50 条人工盲评「退化/持平/变好」——退化率 >5% 即熔断回滚
- 成本：人工盲评 50条约 30 分钟，自动化部分零边际成本
判据二：线上影子对比（重要场景配）
灰度流量的请求复制一份给新版本（影子执行，结果不返回用户），新旧译文离线攒批比对。这比金丝雀集更真实（真流量分布），但要做脱敏与配额（影子流量别打爆预算）。
判据三：用户侧信号（放大期盯）
灰度到 50%+ 后盯用户信号：翻译功能的「重新翻译」点击率、复制译文率、页面停留——这些间接信号对质量退化敏感（用户用脚投票比评测快）。设置对照组（新旧版本各 50% 用户）才能归因。
灰度节奏：五步走
- 0%→1%（2 小时）：只看错误率/延迟——先确认工程层没炸
- 1%→10%（半天）：金丝雀集回归全跑，硬指标+盲评过线才继续
- 10%→50%（1 天）：影子对比上线，用户信号开始采集
- 50%→100%（1 天）：对照组关闭前的最后一轮盲评
- 100% 后 72 小时：仍保留一键回滚——灰度结束不等于安全期结束，慢热型质量退化（特定领域才触发）往往第三天才冒头
回滚判据的「或」逻辑
满足任一立即回滚，不等凑齐证据：盲评退化率>5% ｜ 金丝雀集词级差异右尾异常 ｜ 用户信号对照组显著劣化 ｜ 错误率/延迟任一工程指标异常。灰度期怀疑优先于证明——证明的代价由用户买单。
一个组织层面的提醒
灰度判据里最贵的是人工盲评（每次 30 分钟），容易被「下次再评」省掉。把盲评做成固定轮值（谁受益谁评：翻译业务的 oncall 评翻译质量），制度化比自觉可靠。
（模型工程系列：扩缩容 → 混部 → 冷启动 → 安全边界 → 输出缓存 → 过载保护 → 本文：灰度发布）
