推理服务做A/B测试，本质上不是比谁跑分高，而是用流量分层把新旧模型放在同一业务场景里，让真实用户反馈替你做决定。落地方式其实不复杂：搭建一个推理网关，把请求按规则切给旧模型和新模型，同时记录业务指标，最后用统计学方法判断谁更值得上线,下面按实操顺序拆解。
推理服务A/B测试怎么做？先搞懂三个关键变量
很多团队上线新模型前只盯离线指标，比如BLEU、ROUGE或者公开榜单，但线上效果往往和离线指标脱节，尤其是大模型在真实对话中的表现，用户感知强烈的可能是回复风格、响应速度，甚至偶尔的“胡说八道”，所以推理服务的A/B测试，核心不是模型本身，而是实验设计。
流量切分：别用用户ID，用请求特征
最常见的错误是按用户ID分桶，但大模型场景下，一个用户可能同时发起多个并发请求，如果新旧模型落在不同桶里，用户会在一次交互中感受到两套回答风格,体验非常割裂。
行业共识认为，按会话ID或者请求来源特征（比如设备类型、渠道来源）做流量切分更合理,具体做法：
- 在网关层读取请求头中的
session_id字段,用哈希取模分配模型版本。 - 保证同一会话的所有请求都路由到同一个模型。
- 灰度初期可以采用5%流量，逐步提升到50%。
这里有个细节：如果业务有“连续对话”需求，必须把上下文缓存也按模型版本隔离，否则新旧模型会共享同一份历史消息,导致实验数据被污染。
指标口径：线上效果不等于离线指标
A/B测试的指标要分两层看，第一层是技术指标，包括首Token延迟、端到端延迟、吞吐量、错误率，第二层是业务指标，比如用户点击率、对话轮次、任务完成率、投诉率。
单独看任何一层都不够，技术指标好，不代表用户喜欢；业务指标好，也可能只是运气，建议同时监控两层，并定义“北极星指标”。
比如做客服助手场景，北极星指标可以是“问题解决率”，技术指标则关注“首Token延迟”是否超过2秒，如果新模型延迟高但解决率也高,就需要结合成本去判断。
实验周期：新模型需要跑多久才可信
不少团队跑两三天就急着看结果，很容易被偶然性误导，实验周期取决于两件事：业务本身的日活流量，以及新版模型带来的效果提升幅度，业内专家指出，
流量越少，需要的时间越长，通常建议至少跑满7个自然日,覆盖工作日和周末的行为差异。
同时要避开大促、节假日等流量异常时段，如果测试期间发生线上事故，或者开发者改了提示词,应该果断重置实验。
大模型A/B测试对比方案：从模型网关到业务报表的完整链路
有了基础认知，下面落地一套可复制的方案，整体链路包含三个环节：网关路由、数据采集、统计决策。
第一步：搭建推理服务网关，实现双模型路由
网关是整个实验的枢纽，不需要自己从零开发，可以直接用开源方案，Envoy 配合自定义过滤器，或者用云厂商的API网关,核心配置就两块：
- 路由策略：根据请求中的实验标记,转发到旧模型服务地址或新模型服务地址。
- 权重调整：通过控制台动态调整新旧模型流量比例,避免重新发布。
伪代码逻辑如下：
if experiment_group == "control":
target = old_model_endpoint
else:
target = new_model_endpoint
proxy_request(target, payload)注意新模型服务最好独立部署，不要和旧模型混用同一个GPU实例,否则资源争抢会直接干扰延迟指标。
第二步：埋点采集与数据打通
网关转发的同时，要把请求和响应信息记录到日志系统,最少需要采集这些字段：
- 请求时间戳、会话ID、实验分组
- 模型名称与版本号
- 首Token延迟、完整响应耗时长度、错误码
- 业务侧上传的用户行为结果（比如是否点击、是否下单）
业务侧的数据通常存在数据仓库里，要打通两套数据，建议给每条响应生成一个全局唯一的 request_id,业务方在处理结果时带上这个ID回传。
第三步：用显著性检验判断胜出模型
拿到两份数据后，别直接比平均值，先做显著性检验，对于业务指标这类二值数据，用卡方检验；对于延迟这类连续数据,用t检验。
业界常用的置信水平是95%，p值小于0.05才认为差异不是随机波动，同时也关注效应量，比如新模型转化率提升了0.1%，即使显著,业务上可能也无关痛痒。
如果结果不显著，不要强行上线，可以考虑延长实验周期,或者调整流量比例让两组的样本量更接近。
推理服务成本与效果如何权衡？基于A/B测试的决策框架
很多时候新模型效果更好，但推理成本也更高，尤其自部署大模型，GPU资源开销直接决定项目盈亏，这时候A/B测试不只是看效果,还要把成本拉进公式里。
对话场景，关注首字延迟和用户留存
在实时对话场景，用户耐心有限，新模型如果参数量更大，生成质量高但首Token延迟增加，可能导致用户流失，有团队在实验中发现自己微调的7B模型虽然回复不如13B“有深度”，但用户留存反而更高,因为响应速度快。
这类场景建议用单位业务价值成本来做决策,公式为：
每千次对话成本 = GPU租用成本 / 实验期间对话总数 × 1000结合A/B测试中的用户留存率，算出“每提升1%留存需要多花多少钱”，如果项目预算有限，效果提升不匹配成本时,宁可不上线。
批量推理场景，关注吞吐和单位成本
离线批量推理（比如日志分类、文档摘要）没有实时压力，重点看吞吐量和性价比，新模型能同时处理的请求数,决定了单位成本。
下面是一个典型的对比表格（数据为示意，非实测）：
| 模型版本 | 单GPU吞吐（requests/s） | 平均准确率 | 单次推理成本（元） |
|---|---|---|---|
| 旧模型 | 12 | 86% | 0042 |
| 新模型 | 8 | 91% | 0065 |
新模型准确率高了5个百分点，但吞吐下降33%，单次成本上涨55%，如果业务对准确率没有硬性要求，上新模型就不划算，反之，如果金融、医疗场景要求高精度,成本翻倍也值得。
关于GPU推理服务价格对比，各地云厂商定价差异较大，比如国内某主流云厂商的A10实例按小时计费，包年比按量便宜一半左右，如果把模型部署在自建机房，还需摊销服务器折旧和电费，这些都应纳入A/B测试的最终对比报告。
线上模型替换的注意事项与常见坑
即使A/B测试结果显示新模型胜出，直接切换也可能翻车,下面几个坑需要提前规避。
坑一：缓存污染导致A/B数据失真
很多推理服务会做结果缓存，比如相同的用户问题直接返回历史答案，如果新旧模型共用缓存，新模型的请求可能命中旧模型的缓存结果,导致实验无效。
解决办法是在缓存key中加入模型版本号，同时实验期间可暂时关闭缓存,等观察稳定后再开启。
坑二：忽略模型版本间的相互影响
如果业务有“推荐”和“搜索”两条链路，新模型只应用在推荐链路，但搜索结果却变了（因为用户行为被推荐改变），进而影响后续推荐模型的预测，这是典型的数据分布偏移。
解决思路是尽量缩小实验范围，或者使用分层实验，把流量先按业务线划分,再在内部做实验。
坑三：实验样本量不足就下结论
统计显著性依赖样本量，小流量下跑24小时，几百个请求就下结论，不靠谱，可以用最小样本量公式提前估算，一般需要让“旧模型在实验期内的成功事件数”不低于几十个量级。
如果短时间内拿不到足够样本，可以降低显著性水平到90%,但要在报告中明确说明置信度不足。
推理服务A/B测试常见问题解答
Q1：A/B测试中，新旧模型的提示词需要保持一致吗？
需要，提示词对模型输出影响极大，实验期间只允许模型权重或推理参数不同，提示词必须保持完全一致，否则无法定位效果差异来自哪个变量，如果同时改提示词和模型,就需要设计更复杂的多因素实验。
Q2：测试完成后，如何平滑切换到新模型？
先通过网关把新模型流量逐步提升到10%、30%、50%、100%，每阶段观察1-2小时，如果出现错误率上升，立即回退到上一个稳定版本，切换完成后保留旧模型服务一段时间,方便快速回滚。
Q3：怎样选择A/B测试用的模型效果评估工具？
不建议只依赖单一工具，可以先用离线评估框架（如 lm-evaluation-harness）做快速筛查，再结合自建的线上监控看板，商业化的模型观测平台往往带A/B实验模块，但数据通常存储在他们服务器上，出于合规考虑，自建网关加Prometheus/Grafana也是个成本可控的路子。
推理服务的A/B测试没有完美方案，但有清晰的落地路径：设计干净的实验、收集可靠的数据、结合业务成本做决策，只要坚持这套方法，新模型能不能上、什么时候上,就不再靠拍脑袋了。