推理服务上线后，最怕的不是接口返回500，而是模型更新后精度轻微下降、首字延迟从80ms涨到150ms、同批请求吞吐下降15%。这些问题不会让健康检查失败，却会逐渐拖垮用户体验。要让这类退化在发布前被识别，自动化测试不能只停留在接口冒烟层面，需要把回归测试和性能基准拆开设计，纳入持续集成流程。
一、推理服务测试为什么不能照搬普通接口测试
普通Web服务测试通常关注状态码、响应体字段和异常处理，因为输入与输出基本确定。推理服务则不同：同一个请求多次执行，输出 token 可能不同；模型从FP32切换到FP16后，数值精度会变化；GPU型号、驱动版本、推理引擎升级都可能影响结果。因此回归测试需要回答结果是否仍然正确，性能基准需要回答延迟与吞吐是否仍然达标。这两类测试的目标、工具和判定标准差异很大。
另一个容易被忽略的点是批处理。普通接口的响应时间大多与单次请求成正比，但推理服务为了提高GPU利用率通常启用动态批处理，batch size 变化会改变单个请求的等待时间。比如并发从1升到8，吞吐上升，但单请求延迟也可能升高。如果只用平均值评估性能，很容易掩盖长尾问题。后续小节会给出更合理的指标设计。
二、回归测试：用固定数据集和容差策略捕捉精度回退
回归测试的第一步是准备一份固定数据集，业内常称为 golden dataset。数据集要覆盖典型输入、边界输入和容易出错的样本。对于分类模型，可以保存输入文本和期望标签；对于生成模型，可以保存输入提示和参考答案，再用相似度或规则判断。固定数据集的意义在于排除数据变化带来的干扰，让每次测试结果可复现。
第二步是确定结果对比策略。分类任务可以精确比对 top1 标签，但生成任务不能直接比较字符串。常用方法是计算 ROUGE、BLEU、余弦相似度或让裁判模型打分，再设置阈值。例如文本摘要服务可以要求 ROUGE-L 不低于0.35。阈值若设得太严，大量非关键差异会导致测试不稳定；设得太松则会漏掉真正的退化。建议先在历史版本上跑一遍，统计指标波动范围，再根据业务可接受程度留出裕度。
import pytest
import requests
from rouge import Rouge
rouge = Rouge()
GOLDEN_CASES = [
("请总结这段文本的核心观点", "核心观点是自动化测试需要覆盖精度与性能"),
("将以下句子翻译成英文", "The model should be tested before release."),
]
@pytest.mark.parametrize("prompt,reference", GOLDEN_CASES)
def test_inference_quality(prompt, reference):
resp = requests.post("http://127.0.0.1:8000/v1/chat", json={
"prompt": prompt,
"max_tokens": 64,
}, timeout=30)
resp.raise_for_status()
output = resp.json()["result"]["text"]
scores = rouge.get_scores(output, reference)
score = scores[0]["rouge-l"]["f"]
assert score >= 0.35, f"ROUGE-L {score:.3f} lower than threshold"
上面的用例通过 pytest 参数化固定样本，调用本地推理服务并计算 ROUGE-L 分数。实际项目中不推荐在测试代码里重新加载模型，而是把服务作为黑盒访问，这样可以同时验证接口协议、序列化和推理结果。需要注意 max_tokens 等采样参数要固定，否则随机性会让分数抖动。对于开放式生成任务，还可以设置温度参数为0或使用固定随机种子。
回归测试还要与模型版本绑定。每次训练产出新模型时，在元数据中记录模型ID、数据集版本和推理引擎版本。测试报告中需包含这些信息，否则半个月后很难定位是哪次更新引入了问题。建议将 golden dataset 也纳入版本管理，避免测试集被无意修改后失去基准意义。
三、性能基准：分位数、吞吐和资源利用率一个都不能少
性能基准不适合只记录平均延迟。平均值会掩盖长尾，一个用户遇到3秒卡顿可能对应100个用户80ms流畅。推理服务更要关注 P95、P99 和最大延迟。举例来说，如果 P99 延迟从200ms恶化到900ms，即使平均延迟只增加20ms，也应该触发告警。吞吐量通常用 tokens per second 或 requests per second 表示，需要与并发阶梯结合观察。并发较低时吞吐可能线性增长，到达某个点后GPU计算单元饱和，继续加压只会推高排队延迟。
除了延迟和吞吐，GPU利用率和显存占用也是关键指标。显存泄漏或碎片化会导致服务运行几小时后性能下降，单次压测很难发现。长时间基准测试可以观察指标是否稳定。建议在相同硬件、相同驱动、相同推理引擎版本下执行基准，并尽量关闭其他占用GPU的进程。容器化环境可以使用独立的GPU节点，避免共享资源带来的噪声。
下面是一个基于 asyncio 和 aiohttp 的轻量压测脚本，统计并发请求的延迟分位数。
import asyncio
import time
import numpy as np
import aiohttp
async def send_request(session, url, payload):
start = time.perf_counter()
async with session.post(url, json=payload) as resp:
await resp.json()
return time.perf_counter() - start
async def benchmark(concurrency, total_requests):
url = "http://127.0.0.1:8000/v1/chat"
payload = {"prompt": "Hello", "max_tokens": 32}
all_latencies = []
async with aiohttp.ClientSession() as session:
pending = []
for index in range(total_requests):
pending.append(send_request(session, url, payload))
if len(pending) >= concurrency:
batch = await asyncio.gather(*pending)
all_latencies.extend(batch)
pending = []
if pending:
batch = await asyncio.gather(*pending)
all_latencies.extend(batch)
return all_latencies
latencies = asyncio.run(benchmark(concurrency=8, total_requests=200))
p50, p95, p99 = np.percentile(latencies, [50, 95, 99])
print(f"P50={p50*1000:.1f}ms P95={p95*1000:.1f}ms P99={p99*1000:.1f}ms")
该脚本每次同时发送固定数量请求，并记录每个请求的耗时。实际使用中需要分批等待，避免一次性创建过多协程导致客户端自身成为瓶颈。更完整的方案可以引入 Locust 或 k6，它们支持并发阶梯、断言和报告导出。性能基准的判定不应依赖单次数据，建议至少重复3轮，取中位数或稳定区间，避免突发抖动造成误报。
四、把回归测试和性能基准接入CI流水线
回归测试适合在每次模型变更或推理服务代码变更时触发。轻量级回归集可以在合并请求阶段跑，样本量控制在几十到几百条，耗时几分钟。全量回归集可以放在夜间流水线，覆盖更多语言、长度和边界场景。性能基准通常耗时较长，不建议每个提交都跑，可以在每日构建或发布候选阶段执行。两类测试失败后的处理策略也不同：回归失败直接阻断合并，性能退化超过阈值则标记为警告，需要负责人确认是否允许发布。
stages:
- regression
- benchmark
regression:
stage: regression
script:
- pytest tests/regression_inference.py --junitxml=report_regression.xml
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
benchmark:
stage: benchmark
script:
- python benchmark_inference.py --concurrency 1 4 8 --output benchmark_result.json
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
测试报告要保存为结构化文件，例如 JUnit XML 或 JSON，方便后续趋势分析。对于性能指标，可以每次运行后把 P50、P95、P99、吞吐和GPU利用率写入数据库，再通过可视化面板观察长期趋势。只看单次结果容易受环境抖动影响，连续三次基准都下降时才自动升级为阻塞问题，这样可以在灵敏度和稳定性之间取得平衡。
最后要注意测试数据与线上流量的差异。固定数据集适合发现精度回退，但无法覆盖真实分布变化。条件允许时，可以定期从线上采样脱敏数据补充回归集，或使用影子流量做在线评测。性能基准也应结合生产环境的典型请求分布，比如平均输入长度、最大输出长度和调用时间分布，这样压测结果才更贴近真实SLA。