摘要9-23 用 VeriBench 接CI 门禁卡住坏版本9-24 做生产监控发现坏版本但二者之间**怎么把好版本安全放出去一直是缺口。本文补齐持续交付**评测门禁 → 模型版本路由与流量切分接 9-25 网关→ 灰度指标与自动回滚接 9-24 监控→ 在线实验框架A/B / 影子 / 区间。传统服务回滚靠重启进程LLM 应用回滚靠’换模型 换上下文’——发布不是终点而是评测闭环在生产侧的延伸。一句话结论把 LLM 应用当成受版本治理约束的服务——门禁卡质量、网关做版本路由与流量切分、监控做灰度指标与自动回滚、实验框架做在线对比让每一次模型/提示词/上下文变更都可灰度、可回滚、可量化。1. 为什么 LLM 应用需要持续交付传统软件编译过就能上。LLM 应用模型会悄无声息地变笨——同样的 prompt换了个微调版本9-27/02、改了段 System 提示9-28/02、换了个 RAG 检索策略9-27/01效果可能断崖。环节9-23 / 9-24 已解决本文补的缺口上线前CI 门禁卡坏版本—上线后生产监控发现坏版本—之间—灰度发布 / 版本路由 / 自动回滚LLM 应用还有个特殊难点回滚对象不是二进制而是模型权重 提示词 上下文模板 RAG 配置的组合必须整体版本化。2. 流水线全景从门禁到灰度代码/提示词/模型变更 → 9-23 CI 门禁(VeriBench 通过率 ≥ 阈值) → 打版本标签(模型promptctxRAG 配置) → 9-25 网关注册新版本路由 → 灰度(1% → 10% → 50% → 100%) → 9-24 监控盯 SLO(延迟/成本/质量) → 达标全量 / 异常自动回滚 → 在线实验(A/B) 量化业务指标阶段负责失败动作门禁9-23 VeriBench阻断合并路由9-25 网关不出新版本灰度发布控制器暂停放量监控9-24 OTel触发回滚实验实验框架选优胜版本3. 模型版本路由与流量切分接 9-25 网关9-25 的统一网关天然支持按成本/能力路由持续交付把它扩展成版本级流量切分# 在 9-25 网关的 router 中增加版本权重ROUTING_TABLE{chat-prod:{candidates:[{model:kimi-k3-v2,weight:0.10},# 新版本先 10%{model:kimi-k3-v1,weight:0.90},# 旧版本兜底],sticky:True,# 同一用户会话 sticky 到同一版本}}defpick_version(user_id,table):importhashlib,bisect hint(hashlib.md5(f{user_id}.encode()).hexdigest(),16)%100cum0forcintable[candidates]:cumint(c[weight]*100)ifhcum:returnc[model]returntable[candidates][-1][model]stickyTrue很关键同一用户的多次请求要落到同一版本否则 A/B 数据失真、体验跳变。4. 灰度指标与自动回滚接 9-24 监控灰度期盯三类 SLO质量Faithfulness / 法官评分接 9-26、成本单请求 token 成本接 9-20/25、稳定性P95 延迟、错误率。任一越界自动回滚defwatch_canary(baseline,candidate,window300):metricsotel_query(window)# 9-24 的 OTel 数据deltas{faithfulness:candidate[faith]-baseline[faith],p95_latency:candidate[p95]-baseline[p95],cost:candidate[cost]-baseline[cost],}# 质量跌 2% 或成本涨 15% 或延迟涨 30% → 回滚ifdeltas[faithfulness]-0.02ordeltas[cost]0.15ordeltas[p95_latency]0.30:rollback_to(baseline[version])alert(f灰度回滚:{deltas})returnFalsereturnTrue指标回滚阈值示例说明Faithfulness跌 2%质量优先宁可慢发单请求成本涨 15%接 9-20 KV / 9-25 成本P95 延迟涨 30%体验底线错误率 1%稳定性底线5. 在线实验框架A/B / 影子 / 区间门禁只证明没坏但**哪个版本更好**要靠在线实验。实验怎么做适用A/B真实流量切分对比已确认安全比业务指标影子Shadow新版本旁路上线、只记录不服务上线前最后验证区间Holdback留 5% 旧版做对照基线长期监控回归experiment:name:ctx-v2-vs-v1variants:-version:ctx-v2# 9-28/02 新上下文编排traffic:0.5-version:ctx-v1traffic:0.5metrics:[faithfulness,task_success,cost_per_task]min_runtime:72hdecision_rule:faithfulness 不劣化且 task_success 提升 ≥1% 才全量影子实验呼应 9-24/03新版本在生产影子跑输出不返回用户只用来比对质量与成本是风险最低的上线前验证。6. 回滚与应急接 9-26 护栏回滚不是重启而是把版本路由权重一键拨回旧版并保留现场版本快照每次发布记录模型 prompt ctx 模板 RAG 配置的不可变快照一键回滚网关改权重即可秒级生效比传统回滚还快护栏兜底回滚期间若仍异常9-26 出站护栏可临时降级为只返回缓存/模板答案保可用性。defrollback_to(version):ROUTING_TABLE[chat-prod][candidates][{model:version,weight:1.0}]snapshot_save(version)# 存现场emit_event(rollback,version)7. 小结从能服务到敢发布至此生产级 LLM 平台骨架彻底闭合协议/安全9-19→9-23MCP 2.0 零信任网关网关/成本9-25/26统一路由 内容护栏 引擎吞吐评测9-20→9-26RLVR / VeriBench / 法官评测 / 黄金集业务落地9-27RAG / 微调 / 多 Agent手脚与大脑9-28工具调用动手 上下文工程记忆持续交付发布持续交付是最后一公里它让前面所有能力安全地抵达生产、可量化地迭代。下一阶段可延伸到多区域多模型容灾与模型生命周期自动退役——平台从建好走向自治。常见问题FAQQ1LLM 应用的回滚和传统服务有什么不同A传统回滚换二进制LLM 回滚换模型权重 提示词 上下文模板 RAG 配置的组合必须整体版本化快照否则回到的可能不是原来的行为。Q2灰度比例怎么定A新模型/新提示词风险高从 1%→10%→50%→100% 递增每档盯够一个监控窗口建议 ≥ 数小时覆盖峰谷纯配置微调可从 10% 起。Q3CI 门禁过了为什么灰度还会出问题A门禁用的是离线黄金集生产是真实分布 真实工具副作用9-28/01。影子实验 灰度监控正是补这个 gap。Q4A/B 实验要跑多久A至少覆盖一个完整业务周期建议 ≥72h让昼夜、工作日/周末波动都被采样否则结论会被时段偏差污染。Q5成本指标怎么算才准A按 9-20/25 的 per-request token 成本结合 9-24 的 OTel 归因排除缓存命中9-25 语义缓存的干扰否则会低估真实增量。Q6多个版本同时灰度会乱吗A用网关版本表 sticky 路由集中管理禁止子 Agent 自己硬编码模型名所有版本选择收口到 9-25 网关一处。Q7回滚后旧版还计费等吗A权重拨回后旧版即为主流量按正常计费回滚动作本身零成本只改路由比传统回滚的 downtime 损失小得多。参考资料Google《MLOps for LLM Applications》持续交付实践2026本专栏 9-23《评测驱动模型迭代》VeriBench 接 CI/CD 门禁本专栏 9-24《从 CI 门禁到生产监控》在线/影子/漂移监控本专栏 9-25《统一 LLM 推理网关实战》版本路由与成本感知本专栏 9-26《LLM-as-Judge 自动化评测流水线》质量 SLO 量化本专栏 9-28《函数调用与工具执行沙箱实战》《上下文工程实战》发布对象工具/上下文的版本化