滚动更新

大模型服务上线最尴尬的时刻，是你满心欢喜部署了新模型版本，一次重启把在线请求全部打断，半小时后发现效果还不如旧版。用 HuggingFace TGI 做生产时，正确姿势不是停旧起新，而是金丝雀：先放一小部分流量到新模型，观察无误再全量。 金丝雀发布的架构怎么搭？ 起两个 TGI 实例：旧版本占主端口，新版本占另一个端口。前面放一层极薄的路由，例如 Nginx、Caddy 或任何支持按比例分流的网关，按权重把小部分流量导到新实例。关键是两个实例用不同的模型缓存目录，避免抢同一份权重文件。 放量时该盯哪几个指标？ 金丝雀不是只看延迟。至少盯三个：首 token 延迟、输出合格率（用一个小黄金集跑自动判定）、以及错误率。新模型可能更快但开始胡言乱语——只看延迟会翻车。建议每隔一段时间自动跑一批固定问题，对比新旧两版的回答质量。 发现问题怎么快速回滚？ 回滚要快。网关把权重拨回全部走旧实例只需改一行配置；新实例保留但不删，方便对比。切忌金丝雀发现问题后原地调试——把流量切走，在隔离实例上慢慢改。 TGI 有什么特有的坑？ TGI 加载大模型到显存需要时间，金丝雀切流前要确认新实例已经预热——空缓存的第一次请求会慢得离谱，让你误以为新模型崩了。等它跑完几批预热请求再放量。 流量比例该怎么逐级放？ 别从极小比例直接跳到全量。按五、二十、五十、一百这个梯度逐步放，每一档至少观察一个完整业务高峰再进下一档。很多问题只在高峰并发下才暴露——平峰看着一切正常，一到白天流量上来就崩。观察期内务必保留一键回滚的能力，真出问题时这比任何事后排查都值钱。 模型上线怎么才能不再赌一把？ 模型迭代越来越快，「每次上线都赌一把全量重启」的模式迟早出事。用 TGI 双实例加一层按比例路由，把金丝雀做成日常，上线风险就从一次赌博变成可控的小步实验。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：TGI金丝雀发布