一、A/B 对比上线的本质：不是两个模型并列，而是一套决策系统

很多人以为 A/B 对比就是“左边部署旧模型，右边部署新模型，各发一半流量”。这只是最表层的形态。真正的 A/B 对比上线，本质是一套围绕模型版本做决策的系统：

它要决定流量怎么分，哪些用户进实验组、哪些留对照组；它要决定请求怎么路由，同一个 Prompt 是否同时送给两个模型用于离线评测；它要决定指标怎么算，延迟、首字耗时、吞吐、准确率、采纳率、投诉率能不能被统一归因；它还要决定实验结束之后怎么办，是新模型全量、旧模型保留兜底，还是回退到上一稳定版。

所以平台支持 A/B，不等于“能起两个服务”。它意味着训练、评测、部署、网关、观测、实验管理这几个环节被串起来了。训练侧产出模型版本，评测侧给出离线榜单，部署侧把版本变成可调用端点，网关侧做流量切分，观测侧采集线上信号，实验管理侧把信号转成可解释结论。缺任何一块，A/B 都只是“看起来能比”。

二、新旧模型同时跑：三种常见模式

全链路平台里，新旧模型同时跑通常有三种模式，适用场景不一样。

第一种是网关层流量分流。旧模型和新模型各自作为一个部署版本存在，推理网关按配置把一部分请求发给新模型、其余发给旧模型。用户无感知，后端同时有两个模型在服务。这种模式对业务侵入最小，适合面向真实用户做线上实验。优点是接近生产真实分布，缺点是需要处理用户一致性：同一个用户如果一会儿命中旧模型、一会儿命中新模型，体验会跳变，所以通常要按用户 ID、会话 ID 或租户做哈希分流。

第二种是镜像流量比对，也叫影子流量。真实请求仍然主要由旧模型响应，同时把请求复制一份送给新模型，新模型的结果不返回给用户，只记录耗时、输出、异常和评测分数。这种方式最安全，因为用户看到的一直是旧模型；但新模型看到的也是“真实流量”，能暴露提示词分布、长上下文、脏输入、超时、显存占用等线上问题。很多团队会先用影子流量跑几天，再决定是否进正式 A/B。

第三种是离线回放比对。把历史请求集、标注集或合成评测集同时送给新旧模型，逐条比对输出。它不算“线上同时跑”，但属于全链路平台里很重要的预上线对比。适合评测事实正确性、格式合规性、拒答边界、敏感内容处理等可离线判分的任务。离线回放跑不过真实分布，但成本低、可复现、方便回归。

三、流量路由与一致性：比“同时跑”更难的是“比得公平”

新旧模型能不能同时跑，是部署问题；跑出来的结果能不能信，是实验设计问题。

如果做用户级 A/B，最关键的是分流稳定性。同一个用户在一次会话里不应在旧模型和新模型之间来回跳；跨天回访时，最好也保持分组不变，否则前后交互风格不一致，用户会困惑，指标也会被污染。平台通常需要支持按用户、租户、会话、请求维度配置分流键，并支持白名单、内部员工流量、特定业务线流量单独处理。

另一个难点是请求公平性。如果新模型被分到难样本更多的流量，旧模型被分到简单样本，最后新模型指标差，不代表模型差，只代表流量歪了。全链路平台会提供流量均衡校验：两组在输入长度、语种、业务类型、时段、客户端类型上的分布是否接近。分布差太多，实验结论就不能直接采用。

还有一类场景叫同期全量对照：不切分用户，而是按时间窗切换，周一旧模型、周二新模型。这种做法实现简单，但会被“周一时段用户本来就更挑剔”这类时间因素干扰，所以通常只作为辅助，不作为主要 A/B 依据。

四、指标采集：延迟、质量、业务三类都要看

看效果不能只看“新模型回答更好不好”。全链路平台做 A/B 时，一般要把指标分成三类。

第一类是工程指标。首字延迟、整句耗时、吞吐、排队时间、显存占用、错误率、超时率、降级次数。新模型如果效果略好但延迟翻倍，线上未必值得上。尤其大模型推理里，上下文越长、解码步数越多，成本越敏感，工程指标往往决定能不能全量。

第二类是质量指标。准确率、事实一致性、格式遵从、工具调用成功率、拒答率、幻觉率、重复生成率、截断率。这类指标有的可自动打分，比如格式校验、单元测试式评测；有的需要人工抽检或大模型裁判，但裁判模型本身也要校准，不能把裁判偏好当成客观真相。

第三类是业务指标。点击率、采纳率、续聊率、任务完成率、工单解决率、转化率、投诉率、退订率。前两类再漂亮，业务指标掉下去，模型也不能全量。很多团队踩过的坑是：离线榜单第一的模型，上线后用户觉得“太啰嗦”“太爱说教”，采纳率反而下降。

平台如果把这三类指标统一到实验面板里，负责人就能看到一张完整画像：新模型延迟高 12%，事实一致性高 3 个点，但采纳率低 1.5 个点——这时候就不是“谁指标高谁赢”，而是业务方要不要为那 3 个点付出体验和成本代价。

五、评测集、标注与人工抽检：自动指标之外还得有人看

A/B 对比最容易迷信曲线。但大模型输出是语言，不是分类标签。两个模型可能得分接近，但一个更稳、一个偶尔惊艳也偶尔翻车；一个更守规矩，一个更会编故事。全链路平台再完整，也需要三层人工机制兜底。

一是种子评测集。把历史难例、边界输入、业务高频问题、过往出过事的样本固化成集，每次新模型上线前都跑一遍，保证“老问题不再犯”。这组集子不参与模型训练，避免自欺欺人。

二是人工抽检。从 A/B 流量里抽样，由业务同学、领域专家、标注人员看输出。看什么？看语气是否合适，看是否泄露内部信息，看是否把“不知道”说成“很确定”，看多轮对话里是否忘记前面约束。这些事自动打分很难完全覆盖。

三是用户反馈闭环。点赞、点踩、举报、追问、复制代码后运行失败，这些都是信号。平台把这些信号归因到模型版本，就能在实验后期发现自动评测发现不了的问题。比如新模型回答更完整，但复制出来的命令多带了破坏环境的操作，这种问题只有真实使用会暴露。

六、资源与隔离：两个模型同时跑，显存和调度怎么排

新旧模型同时跑，底层绕不开资源问题。一个大模型部署本来就很吃显存，两个版本并存意味着副本数、显存、批处理队列都要重新规划。

平台通常会用部署版本管理来解决：旧版本标记为 stable，新版本标记为 candidate，两者使用不同模型权重但共享同一套网关、日志、指标、鉴权。资源调度上，可以给旧模型保留最低服务副本，给新模型先给小流量副本；当实验通过，再逐步把 stable 的副本缩容、把 candidate 的副本扩容。

隔离也很关键。两个模型不能互相写坏对方缓存，不能共享未加锁的本地状态，不能因为新模型 OOM 把旧模型一起拖垮。推理进程、模型权重、分词器、适配器、提示词模板、业务插件都应按版本隔离。全链路平台如果只做到“都能调”，没做到“互不影响”，实验期间就可能出诡异问题：旧模型突然变慢，查半天发现是新模型把共享磁盘写满了。

七、实验周期、显著性与回滚：别拿一天曲线下结论

A/B 对比最忌讳“看了一小时就全量”。大模型效果受时段、热点事件、提示词传播、业务活动影响很大。今天新模型胜，可能只是碰上简单问题变多。

正规做法是先定实验假设：新模型在保持延迟不劣化前提下，把事实一致性提升至少某个阈值。再定样本量：需要多少请求、多少用户、多少业务线才能达到统计显著性。再定观察窗口：通常数小时到数天，覆盖工作日、周末、高峰和低峰。最后定决策规则：主指标显著且负向指标不越界才全量；主指标无显著差异就维持旧模型；新模型只在某个子群体更好，就做分群上线而不是全局替换。

回滚机制也必须前置。实验进行中如果发现新模型投诉率陡升、敏感内容放行、延迟雪崩、成本超预算，平台应能一键把流量切回 stable，且切回后用户会话尽量不中断或至少可恢复。模型版本是有状态的决策对象，不是静态文件；好平台会把“能退回去”当成一等能力。

八、从训练到上线的闭环：A/B 是最后一关，不是孤立功能

把视野拉回全链路：数据清洗、训练、微调、评测、注册、部署、监控、A/B、回滚，这些环节要是各管各的，模型上线就像押宝。全链路平台的价值，正是让 A/B 有上下文。

训练侧知道新模型用了什么数据、改了哪些超参；评测侧知道它在哪些基准上变好、哪些能力退化；部署侧知道它需要多少卡、什么批大小最稳；A/B 侧再把真实流量里的表现反馈回去。如果新模型线上幻觉变多，团队能反查是不是某批数据没过滤干净；如果旧模型在某个语种上其实更好，就不该被离线总分掩盖。

所以这时的 A/B 不是“新旧模型比谁强”，而是把训练里的假设、评测里的证据、线上的事实拼成同一张图。模型版本、数据集版本、提示词版本、插件版本、评测集版本，最好都能对应起来。否则线上出问题，没人说得清到底是模型新了、提示词改了，还是业务流量变了。

结语

大模型训练推理全链路平台完全可以支持 A/B 对比上线，新旧模型也能够同时跑起来看效果：通过网关分流让真实用户参与对照，通过影子流量让新模型在不出错给用户的前提下接触真实请求，通过离线回放在预上线阶段先排雷。但“能同时跑”只是入口，“比得公平、看得全面、退得回去”才是工程核心。延迟、质量、业务三类指标要一起看，自动评测和人工抽检要互补，资源隔离和回滚策略要提前就位。对新模型最负责的态度，不是训练完就全量替换，而是让它先在旧模型旁边跑一段时间，用真实流量证明自己不仅榜单更好，而且线上更稳、用户更愿意用、业务经得起推敲。当训练、评测、部署、实验、监控被同一条链路串起来时，A/B 对比就不再是两个模型打架，而是团队用工程方法把“我觉得新模型更好”变成“数据告诉我们该不该换”。