Llama-Factory 微调模型上线前的 A/B 测试实践

这个文件本身就是一次实验的'快照'。当我们需要复现或对比时，只需读取它即可还原整个训练上下文。这种可审计性对于 A/B 测试的结果归因至关重要。

有了候选模型，下一步是让它们'跑起来'。这里的关键不是单纯部署，而是并行共存。理想情况下，两个模型应作为独立服务运行，互不抢占资源。常见做法是将它们封装成 Docker 容器，并通过 Kubernetes 进行编排。

以 vLLM 为例，这是一个高性能推理引擎，支持 LoRA 动态切换。但我们仍建议为每个版本启动独立实例，原因如下：

• 避免 LoRA 热切换带来的性能抖动
• 便于单独监控 GPU 利用率、显存占用等指标
• 防止模型间相互影响导致结果偏差

部署脚本大致如下：

FROM vllm/vllm-openai:latest
# 加载模型 A
COPY outputs/qwen-lora-r8 /models/A/
CMD ["python", "-m", "vllm.entrypoints.openai.api_server", "--model", "Qwen/Qwen-7B-Chat", "--lora-path", "/models/A", "--host", "0.0.0.0", "--port", "8000"]

模型 B 同理，仅更换路径和端口。启动后，可通过 OpenAPI 接口直接访问：

curl http://model-a:8000/v1/completions -d '{ "prompt": "请简述光合作用的过程", "temperature": 0.7 }'

此时，两个模型已准备就绪，等待被'分配'流量。

真正的挑战出现在路由层。我们需要一个中间件，能够根据策略决定请求该发往哪一个模型。最简单的方案是随机分流：

import random

def choose_model():
    return "A" if random.random() < 0.5 else "B"

但这可能带来体验问题：同一个用户刷新页面，得到的回答风格完全不同。更好的方式是基于用户 ID 哈希固定分配：

def route_by_user_id(user_id: str) -> str:
    hash_code = hash(user_id) % 100
    return "A" if hash_code < 50 else "B"

这样能保证用户在整个会话期间始终面对同一模型，提升一致性。当然，如果你的产品没有登录体系，也可以用设备指纹或 Cookie 来做标识。

实际工程中，这类路由逻辑往往集成在 API 网关中。Nginx 可以通过 map 指令实现简单分流：

map $arg_userid $backend {
    ~^[0-9a-f]{32}$ model-$http_x_ab_version;
    default model-A;
}
upstream model-A {
    server 192.168.1.10:8000;
}
upstream model-B {
    server 192.168.1.11:8000;
}
server {
    location /infer {
        proxy_pass http://$backend;
    }
}

或者使用更现代的服务网格如 Istio，通过 VirtualService 配置权重：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: llm-ab-test
spec:
  hosts:
  - llm-service
  http:
  - route:
    - destination:
        host: llm-model
        subset: v1
      weight: 50
    - destination:
        host: llm-model
        subset: v2
      weight: 50

无论哪种方式，目标都是实现可控、可观测、可回滚的流量调度。

模型跑了，请求分了，接下来才是重头戏：数据收集与分析。

很多人以为 A/B 测试就是看点击率，但在大模型场景下，评估维度要复杂得多。我们至少需要关注以下几类指标：

其中，用户反馈尤为重要。可以考虑在前端添加'此回答是否有帮助？'的按钮，直接获取正负样本。一段时间积累后，甚至可以用这些数据做新一轮的偏好训练（如 DPO）。

数据分析阶段要特别注意统计显著性。不能只看均值差异，必须做假设检验。例如，使用 t-test 判断两组响应时间是否存在显著差别：

from scipy import stats

# 示例：两组响应时间（毫秒）
times_A = [1200, 1350, 1100, ...]
times_B = [1180, 1290, 1050, ...]

t_stat, p_value = stats.ttest_ind(times_A, times_B)
if p_value < 0.05:
    print("存在显著差异")
else:
    print("差异不显著")

如果 p 值大于 0.05，哪怕 B 组平均快 50ms，也不能说明它更好——可能是随机波动。

此外，还要警惕辛普森悖论：整体数据显示 B 优于 A，但按设备类型拆分会发现，其实只是在低端手机上表现更好，而在高端设备上反而更差。因此，务必做分层分析。

在整个过程中，有几个容易被忽视但极其重要的工程细节：

一是服务预热。新模型刚启动时，CUDA 内核未充分加载，缓存未命中，前几十个请求的延迟往往会偏高。如果不做处理，这部分数据会拉低整体表现，造成误判。建议在正式开始测试前，先用历史请求回放预热服务至少 5 分钟。

二是样本均衡性。确保 A/B 两组用户的分布一致。比如，不能让 A 组全是夜间活跃用户，B 组全是白天用户；也不能让 A 组集中于 iOS，B 组集中于 Android。否则任何结论都可能受混杂变量干扰。可通过卡方检验验证分类变量的分布是否一致。

三是资源预留。并行运行两个大模型意味着双倍显存消耗。一台 A10G（24GB）可能勉强跑一个 Qwen-7B+LoRA，但很难同时支撑两个实例。要么使用更大显存卡，要么采用时间错峰部署（不推荐），要么借助云弹性扩容。

四是伦理合规。虽然 A/B 测试是常规手段，但仍需在隐私政策中声明'我们可能会向您提供不同版本的服务以优化体验'，避免法律风险。同时，禁止在涉及医疗、金融等高敏感场景中进行未经审核的实验。

当一周测试周期结束，数据收齐，分析完成，最终决策也就水落石出了。也许你会发现，那个离线指标略胜一筹的 r16 模型，在线上反而因为生成过长而导致用户跳出率上升；而看似普通的 r8 版本，却因响应更快、内容更简洁赢得了更多点赞。

这正是 A/B 测试的价值所在：它把主观猜测变成了客观证据，把'我觉得'变成了'数据显示'。

而对于 Llama-Factory 来说，它的意义不仅是帮你训练出模型，更是让你能低成本、高频次地开展实验。当你拥有一个可复现、可管理、可部署的微调流水线时，模型优化就不再是'一次性的项目'，而成为持续演进的日常。

未来，随着自动化评估代理（Agent）的发展，我们甚至可以设想这样的场景：每当一个新的 LoRA 训练完成，系统自动将其接入灰度通道，跑一轮小流量测试，若关键指标提升超过阈值，则自动触发全量发布。整个过程无需人工干预。

那一天不会太远。而今天，我们可以先从一次规范的 A/B 测试做起——用 Llama-Factory 训练，用数据说话。