大模型A/B测试配置：零基础搭建流量分流与效果对比环境
大模型A/B测试配置的核心，是在同一个业务入口下，把用户请求按比例分给两个不同的模型服务，同时记录每次请求的模型标识和业务指标，最后对比效果。
如果你手里有两个模型（比如一个线上主力模型、一个待评估的新模型），想用真实流量判断哪个更合适，可以按下面的步骤在测试环境先跑通，再逐步放量。
先明确测试目标和前置条件
A/B测试不是配好分流就结束，开始前需要确认三件事：
- 对比什么指标：是回答准确率、用户点赞率、人工评分，还是接口延迟和成本。指标不同，采集字段和分流方式也不同。
- 流量从哪里来：如果是内部测试，可以直接用脚本模拟请求；如果是线上灰度，需要经过网关或反向代理。
- 两个模型服务是否已可用：本文假设你已经有两个可调用的模型API端点，例如通过HTTP接口提供服务的自建模型或第三方模型。
建议在测试环境操作，避免影响线上用户。
需要准备：一台能运行Docker的Linux服务器（本文以Ubuntu 22.04为例），已安装docker和docker compose，以及两个模型的API地址和密钥。
用Nginx做流量分流
最直接的方式是在两个模型服务前加一层Nginx，按权重把请求分发到不同上游。
下面是一个最小可用的配置片段，保存为/etc/nginx/conf.d/ab-test.conf：
upstream model_a {
server 127.0.0.1:8001;
}
upstream model_b {
server 127.0.0.1:8002;
}
split_clients "${remote_addr}${http_user_agent}${date}" $model_group {
50% model_a;
50% model_b;
* model_a;
}
server {
listen 8080;
location /v1/chat/completions {
proxy_pass http://$model_group;
proxy_set_header X-Model-Group $model_group;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}关键点说明：
split_clients根据请求特征哈希分流，同一个用户（相同IP和User-Agent）会稳定落到同一组，减少体验波动。- 分流比例通过
50%调整，初期建议小流量试探，比如10%给新模型。 X-Model-Group请求头会传给后端，方便模型服务记录本次请求属于哪一组。
修改后执行检查并重载：
sudo nginx -t
sudo systemctl reload nginx如果nginx -t报错，先检查split_clients模块是否可用（Nginx官方包默认包含），以及引号和中括号是否写错。
让模型服务返回分组标识并记录日志
仅靠Nginx分流还不够，后端需要把分组信息写入访问日志，后续才能按组统计。
假设你的模型服务用Python FastAPI编写，可以在中间件中读取X-Model-Group并记录到日志文件：
from fastapi import FastAPI, Request
import logging
app = FastAPI()
logger = logging.getLogger("ab_test")
logger.setLevel(logging.INFO)
handler = logging.FileHandler("/var/log/model_ab.log")
logger.addHandler(handler)
@app.middleware("http")
async def log_group(request: Request, call_next):
group = request.headers.get("X-Model-Group", "unknown")
response = await call_next(request)
logger.info(f"group={group} path={request.url.path} status={response.status_code}")
return response如果没有代码改造条件，也可以直接在Nginx的access_log中记录$model_group变量，例如：
log_format ab '$remote_addr - $model_group [$time_local] "$request" $status';
access_log /var/log/nginx/ab_access.log ab;把access_log加到server块内即可。
之后用grep model_a和grep model_b分别统计请求量和状态码。
避坑与效果验证
配置过程中容易踩的几个坑：
- 分流后两个模型返回格式不一致：如果模型A返回JSON字段名与模型B不同，前端会报错。建议在网关层做一次响应适配，或者先用小流量验证字段一致性。
- 没有记录分组标识：只配了分流但日志里没有组别，事后无法归因。务必在请求头或日志中保留分组信息。
- 分流比例改完没重载：修改
split_clients后必须执行nginx -t和reload，否则配置不生效。 - 测试期间流量过小：样本太少时对比没有意义，建议每个组至少积累几百次可评估请求再下结论。
验证分三步：先直接请求http://你的服务器:8080/v1/chat/completions，用curl -H "Content-Type: application/json" -d '{"messages":[{"role":"user","content":"你好"}]}'检查是否正常返回；
再查看/var/log/nginx/ab_access.log中是否出现两种分组标识；
最后用简单脚本统计两组请求数和错误率，确认分流比例接近设定值。
常见疑问
分流比例可以按用户ID而不是IP吗？
可以，把split_clients的哈希输入换成$http_x_user_id之类的变量即可，前提是业务请求里带有稳定的用户标识。
两个模型部署在不同机器上怎么办？
把upstream中的127.0.0.1:8001改成实际内网IP和端口，确保Nginx所在服务器能访问到两个模型服务。
测试结束后怎么关闭分流？
把split_clients中非目标组的比例改为0%，或直接让location固定proxy_pass到一个上游，然后重载Nginx。
大模型A/B测试配置并不复杂，关键是分流稳定、分组可追溯、指标可统计。
按本文步骤先在测试环境跑通，再根据样本量逐步调整比例，就能得到相对可靠的对比结论。
