一、为什么不能直接替换

（一）新版本未必更好

评测集上的分数提升，不等于线上真实请求上的表现提升。分布差异、长尾输入、特殊格式，都可能让新版本在某些请求上表现更差。全量上线之后再发现，代价要高得多。

（二）切换本身会有空档

直接替换意味着旧实例停止、新实例启动，这段时间内的请求要么失败要么等待。请求量越大，空档造成的影响越明显。

（三）回滚缺少抓手

一旦全量替换且旧版本已下线，想回退就要重新启动旧实例、重新准备模型文件，耗时不可控。保留共存是回滚能快速执行的前提。

二、影子模式：先跑不返回

1. 复制流量做对比

把线上请求复制一份发给新版本，新版本照常计算，但结果不返回给用户，只用于与旧版本对比。这样可以在零风险的前提下观察新版本的实际表现。

2. 对比哪些指标

除了时延与成功率，更要盯住输出内容的差异率。差异集中在哪类请求上，往往就是新版本的改进点或退步点，需要人工抽样确认方向是否正确。

3. 资源占用要预留

影子模式期间两套版本同时在跑，资源占用接近翻倍。提前预留额度，减少因为资源不足导致旧版本也受影响。

三、灰度放量：按比例推进

（一）起始比例怎么定

起始比例取决于流量规模与容错能力。流量足够大时，很小的比例也能得到有统计意义的样本；流量小的场景可以适当提高起始比例。

（二）每一步观察多久

观察时长要覆盖业务的峰谷周期。只看几分钟就继续放大，容易漏掉只在特定时段出现的问题。通常建议覆盖至少一个完整的日常波动周期。

（三）对齐的关键指标

时延的分位值、错误率、超时率，以及业务侧的转化或满意度。只看均值会掩盖长尾问题，分位值才是用户实际感受到的体验。

四、回滚：先把条件写成数字

把触发回滚的条件事先定成明确数字，减少临场争论：

① 错误率超过旧版本同期程度的某个固定幅度，且持续一段时间。

② 时延分位值明显抬升，超过事先约定的额度。

③ 业务侧指标出现下滑，或人工抽样发现输出质量下降的比例偏高。

五、批处理与流式的差别

（一）批处理任务的切换

批处理没有实时请求，切换更自由：可以新起一批任务用新版本，与旧版本结果对比后再决定是否全量。注意保留旧版本的输出，便于对比。

（二）流式返回的切换

流式场景下，连接一旦建立就难以中途切换版本，通常采用"新连接走新版本、存量连接自然结束"的方式，全量过程会比批处理慢一些。

（三）会话一致性

多轮对话场景要保证同一会话落在同一版本上，否则中途换版本会让上下文表现不连贯。按会话标识做路由是常见做法。

六、配套的工程细节

（一）模型文件的版本管理

每个版本的文件要有唯一标识与说明，记录训练数据版本与评测结果。文件可存放在天翼云存储，与计算实例分离，便于多版本共存。

（二）日志与追踪

每条请求记录所经过的版本标识，出问题时才能快速定位是哪个版本、哪一类请求。

（三）权限与审计

1. 版本切换属于变更操作，应当走审批留痕。配合天翼云安全的审计能力，事后可以完整还原时间线。

2. 访问密钥与访问权限要纳入天翼云安全的统一管理，定期轮换并记录使用情况，减少长期暴露的可能。

（四）请求、队列与超时配置

1. 批处理大小对吞吐与时延的影响方向相反，需要在两者之间按业务容忍度取值，而不是一味追求最大吞吐。

2. 请求队列长度要设额度。无界队列在流量高峰时会耗尽内存，反而拖垮整个服务。

3. 超时时间要与业务侧的容忍度对齐，设置过短会造成大量无效重试，设置过长会占住连接。批量接口的超时设置要比单条请求宽松，否则大批任务会在最后阶段无谓失败。

4. 错误响应要区分类型。是输入不合规、资源不足还是内部异常，分类清晰才能对症处理。

5. 流式返回能改善用户感知，但会增加连接保持的开销，需要按场景权衡。

6. 并发路数与单路时延之间存在取舍，路数提高会让单路变慢，按业务对时延的容忍度找到合适的取值，比单纯追求吞吐更符合实际需要。

（五）长度、缓存与成本控制

1. 长上下文请求的开销随长度增长很快，按长度分档路由到不同规格的实例更划算。

2. 输出长度要设额度。放任生成会让单次请求的开销失控，也会拖慢排队中的其他请求。

3. 输入长度的分布要提前摸清，按分布设计分档策略，比统一按最长处理要省得多。输入输出的长度分布决定了成本结构，先把真实请求的长度统计出来，再按分位数设定不同的处理策略，比统一按最长处理要省得多，也能让时延更稳定。

4. 缓存命中率对成本影响显著，重复前缀较多的场景尤其值得投入。

5. 请求去重与结果缓存可以显著降低重复开销，在高相似度的问答场景效果尤其明显。

（六）实例伸缩与预热

1. 预热不能省略。新实例启动后立即接收流量，首批请求的时延会明显偏高。

2. 实例数量的伸缩策略要按请求量的变化曲线设计，只看瞬时值会造成频繁扩缩，反而增加开销。

3. 扩容冷却时间不能太短，否则一次流量波动会触发多次无效调整。

4. 缩容要留缓冲，直接把所有空闲实例一次回收，遇到突发流量就会措手不及。

（七）压测与上线验证

1. 压测要用真实语料而非随机生成的文本，长度分布与真实请求差别过大时，结论会失真。

2. 服务上线前要跑一轮接近真实流量的压测，观察时延分位值与错误率的变化，提前发现排队与超时设置上的问题，减少上线之后的被动调整。

（八）天翼云组件与部署建议

1. 天翼云主机适合承担网关与路由层，把请求分发与鉴权从推理实例上剥离出来。

2. 模型文件与配置项建议统一放在天翼云存储，多版本共存时便于快速切换。

3. 天翼云数据库可用于保存会话与调用记录，便于对账与问题复现。

4. 模型切分到多张卡上运行，能解决单卡放不下的问题，但会引入额外的通信开销，是否值得取决于模型规模与请求量的组合。

结语：把换版当成一次可以中途撤销的操作，而不是一次性的替换，风险就可控了。影子验证、小比例放量、指标对齐、随时回滚，四步做完，绝大多数问题都会在全量之前暴露。真正需要额外准备的只有两件事：旧版本保留足够长的共存时间，以及把回滚的触发条件事先写成明确数字，减少临场争论。