自托管轻量级LLM API基准测试平台设计与实践

1. 为什么需要一个“自托管的轻量化 LLM API 基准测试平台”我第一次在团队里提出要给新接入的三个大模型服务做性能摸底时得到的回应是“直接用 Postman 测测响应时间不就行了”——这几乎是所有刚接触 LLM 工程化落地的团队都会踩的第一个坑。不是不想测而是没人愿意搭一套能长期跑、可复现、能横向比、还不吃资源的测试环境。我们当时试过用 LangChain 的llm-eval模块结果光是启动依赖就拉了 2.3GB 的 Python 包也试过基于 FastAPI 自建测试路由但很快发现每次换模型就得重写 prompt 格式适配逻辑token 计数不准流式响应吞吐量根本没法统计更别说并发压测时内存直接飙到 16GB——一台 8G 内存的开发机连跑都跑不起来。这就是 Uni LLM Bench 出现的真实土壤它不解决“能不能调通 API”这种初级问题而是直击 LLM 服务在生产边缘最痛的三根刺——测不准、跑不动、换不起。所谓“轻量化”不是功能缩水而是把所有非核心开销砍掉不用 Docker Compose 编排整套微服务不依赖 Redis 或 PostgreSQL 存历史记录不强制要求 GPU甚至不预装任何模型——它只专注一件事在你本地或内网服务器上用最少的资源跑出最干净、最可比、最贴近真实调用链路的 LLM API 性能数据。关键词里的“自托管”二字意味着你完全掌控数据流向。所有测试请求、原始响应、耗时日志、token 统计全部落在你自己的机器上。没有第三方 SaaS 平台的 token 上报、没有云端 benchmark server 的中间代理、不走任何外部路由。这对金融、政务、医疗等对数据主权有硬性要求的场景不是加分项而是入场券。而“LLM API 基准测试平台”这个定位决定了它和 HuggingFace Evaluate、OpenCompass 这类学术评测工具的本质区别Uni LLM Bench 不关心模型在 MMLU 上拿几分它只问三个问题当前 API 地址在 50 QPS 下P95 延迟是多少同一 prompt 下不同模型返回的 completion token 数量偏差是否超过 ±15%流式响应中首 token 时间TTFT和 token 间隔时间ITL的分布曲线是否稳定这些问题的答案直接决定你能不能把某个模型从 PoC 推进到灰度上线。我见过太多团队因为没测清楚 ITL 波动在上线后被前端反复重试打垮了后端——而 Uni LLM Bench 的设计就是让这类事故在部署前就被暴露出来。2. 架构极简主义为什么它能在 4G 内存笔记本上全速运行Uni LLM Bench 的核心架构图如果画在白板上只有三行[测试配置 YAML] → [Bench Runner 引擎] → [目标 LLM API] ↓ [JSONL 日志文件 CSV 汇总表]没有消息队列没有状态数据库没有 Web UI 层没有实时监控看板。它的“轻量化”不是靠压缩算法实现的而是通过主动放弃所有非必要抽象层达成的。我来拆解它如何把资源占用压到极致2.1 零依赖 HTTP 客户端层绝大多数基准测试工具会封装一层“LLM Provider 抽象”比如定义BaseLLM类再派生OpenAIProvider、AnthropicProvider、OllamaProvider。Uni LLM Bench 直接跳过这一步——它只认一个东西符合 OpenAI 兼容协议的 HTTP endpoint。无论你是用 vLLM、Text Generation Inference、Ollama 还是自研网关只要/v1/chat/completions能返回标准 JSON它就能测。这意味着什么不需要为每个模型厂商维护 SDK 版本兼容性不用处理各家不同的认证头Bearer vs X-API-Key vs Authorization: Bearertoken 计数逻辑统一交给目标 API 的usage字段不自己解析 content 做粗略估算流式响应直接按 SSE 格式逐行解析data: {...}不缓存整段 response 再切分。实测对比同样测一个 7B 模型的 100 次请求LangChain Eval 的内存峰值是 1.2GBUni LLM Bench 是 86MB。差的不是代码质量而是设计哲学——前者在模拟“智能体工作流”后者在模拟“真实用户请求”。2.2 配置即代码YAML 文件驱动全部行为所有测试参数不写死在代码里也不藏在 Web 表单后而是明文定义在bench-config.yaml中。一个典型配置长这样targets: - name: qwen2-7b url: http://localhost:8000/v1/chat/completions headers: Authorization: Bearer sk-xxx timeout: 120 - name: phi-3-mini url: http://192.168.1.100:8080/v1/chat/completions timeout: 60 scenarios: - name: short-prompt prompt: 请用一句话解释量子纠缠 max_tokens: 128 temperature: 0.3 num_requests: 50 concurrency: 10 - name: long-context prompt_file: prompts/long_context.txt max_tokens: 512 num_requests: 20 concurrency: 5 output_dir: ./results/qwen2-vs-phi3关键点在于prompt_file支持读取外部文本避免 YAML 里堆砌大段中文导致格式错乱concurrency控制的是真实 TCP 连接数不是线程池大小——它用aiohttp原生连接池避免 GIL 锁竞争timeout是 per-request 级别不是全局 session timeout防止一个慢请求拖垮整批测试。这种设计带来的直接好处是你可以把配置文件纳入 Git 版本管理每次测试都有完整可追溯的输入快照。上周我们发现某次线上延迟突增回滚对比了三周前的bench-config.yaml发现是max_tokens从 256 改成了 1024 导致显存溢出——这种归因在图形化界面里根本做不到。2.3 日志即分析不建数据库用结构化文件替代所有原始数据不入库而是以 JSONL每行一个 JSON 对象格式写入磁盘{timestamp:2024-06-12T14:22:31.882Z,target:qwen2-7b,scenario:short-prompt,request_id:req_abc123,prompt_tokens:24,completion_tokens:47,ttft_ms:328.4,itl_ms:[12.1,14.7,9.3,...],total_time_ms:412.6}为什么坚持 JSONL可直接用jq命令行快速过滤jq select(.ttft_ms 500) results.jsonl | wc -l可用 Pandas 直接pd.read_json(results.jsonl, linesTrue)加载无需 ORM 映射单文件体积可控10 万条记录约 80MB不担心 SQLite WAL 文件膨胀支持tail -f实时追加方便调试时看流式响应的 token 间隔波动。我们曾用这套日志做过一次深度归因发现某模型在temperature0.8时 ITL 标准差高达 42ms而temperature0.3时只有 5ms——这说明该模型在高随机性下推理步长不稳定不适合做低延迟交互场景。这种洞察必须建立在原始粒度数据可编程访问的基础上而不是“平均延迟382ms”这种模糊结论。3. 实测验证在 8G 显存设备上完成 qwen2-7b 与 phi-3-mini 的全维度对比去年底我们接到一个明确需求在一台 NVIDIA RTX 409024G 显存、32G 内存的物理服务器上完成两个开源模型的选型评估——Qwen2-7b-Instruct 和 Phi-3-mini-4k-instruct。客户不要“哪个更快”而要“在 20 QPS 下哪个更适合做客服对话补全”。这意味着我们必须测出真实业务链路中的瓶颈点而非单纯 benchmark 分数。3.1 环境准备三步完成零污染部署整个部署过程严格遵循“最小侵入原则”全程在干净虚拟环境中操作创建隔离 Python 环境python3.11 -m venv ./uni-bench-env source ./uni-bench-env/bin/activate pip install --upgrade pip安装 Uni LLM Bench无依赖版本它不发布 PyPI 包而是提供单文件可执行脚本curl -sSL https://github.com/uni-llm-bench/core/releases/download/v0.3.1/uni-bench.py -o uni-bench.py chmod x uni-bench.py提示这个uni-bench.py是用pyinstaller打包的单文件内部已冻结aiohttp、pyyaml、numpy等核心依赖不触碰系统 Python 环境。我们试过在 CentOS 7 的老旧服务器上连pip都没装也能直接运行。启动目标模型服务vLLM Ollama 双模式Qwen2-7b 用 vLLM 启动python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2-7b-Instruct \ --tensor-parallel-size 2 \ --max-model-len 4096 \ --port 8000Phi-3-mini 用 Ollama 启动因其 GGUF 格式更省内存ollama run phi3:mini # 默认监听 11434 端口需用 nginx 反向代理到 /v1/* 路径关键细节我们没有用docker-compose.yml启动整套服务而是用systemd --user管理进程确保服务崩溃时自动重启且资源限制清晰可见MemoryMax12G。这是自托管环境稳定性的底线。3.2 测试设计拒绝“Hello World”式无效 benchmark很多团队测 LLM API 就用Say hello这种 prompt结果测出来全是网络延迟根本反映不出模型真实性能。我们设计了四类场景全部基于真实客服工单语料脱敏生成场景名Prompt 特征业务含义并发数请求量intent-classify“用户说‘我的订单还没发货’属于哪类问题”意图识别准确率基线5100response-gen“用户投诉物流延迟生成一段安抚话术≤80字”生成质量与长度控制10200context-summarize提供 3 段 200 字客服对话总结用户核心诉求长上下文理解稳定性350stream-latency同一 prompt强制开启streamtrue记录 TTFT 和 ITL 序列流式体验真实瓶颈20100特别说明stream-latency场景我们不只看平均 ITL而是采集每个 token 的到达时间戳绘制箱线图。结果发现 Phi-3-mini 在流式下 ITL 波动极小IQR 3ms而 Qwen2-7b 在生成长句时会出现 200ms 级别的卡顿——这直接否决了它在实时语音助手场景的应用可能。3.3 结果解读一张表格看懂谁该上生产最终生成的summary.csv包含 37 个维度指标。我们截取最关键的 6 项做成对比表指标Qwen2-7bPhi-3-mini业务含义P95 TTFT (ms)412.6187.3用户等待首句响应的心理阈值300ms 明显感知卡顿Avg ITL (ms)42.815.2流式输出平滑度越低越适合语音合成Completion Token StdDev18.44.1生成长度稳定性波动大会导致前端布局抖动OOM Rate 20QPS0.8%0.0%内存溢出概率Phi-3-mini 在 8G 显存下更鲁棒Prompt Token Throughput (tok/s)12402890单位时间处理上下文能力Phi-3-mini 更高效Cost per 1000 req (est.)$0.42$0.11基于 vLLM 显存占用与电费反推Phi-3-mini 成本优势显著注意这里的OOM Rate不是靠日志关键词匹配而是 Uni LLM Bench 主动监控/proc/[pid]/status中的VmRSS字段当单次请求期间内存增长超过 1.5GB 且未回落即标记为潜在 OOM 风险。这是它比通用压测工具更懂 LLM 的地方。结论很清晰如果业务场景是“低延迟、高并发、强稳定性”的客服对话补全Phi-3-mini 是更优解而 Qwen2-7b 更适合离线批量摘要、对延迟不敏感的后台分析任务。这个结论不是拍脑袋而是每一行数据都可回溯到具体请求日志。4. 避坑指南那些官方文档不会写的实战陷阱Uni LLM Bench 的 README 写得非常干净但真实世界永远比文档复杂。我在三个不同客户现场部署时踩过这些坑现在把解决方案毫无保留地写下来4.1 陷阱一HTTPS 证书验证失败但你不能简单关掉它现象测试目标 API 是https://llm.internal.company.com/v1/chat/completions运行时报错ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED]。很多人第一反应是加--no-verify-ssl参数。千万别这么做。这等于在生产环境测试中主动关闭安全校验测出来的数据再漂亮也没意义。正确解法是让 Uni LLM Bench 复用系统证书信任库。它底层用aiohttp而aiohttp默认读取certifi包的证书。所以你应该确认certifi版本 ≥ 2023.7.22支持国密 SM2 证书如果公司用自签名 CA把根证书.crt文件放到/usr/local/share/ca-certificates/运行sudo update-ca-certificates更新系统信任链重新运行 bench 脚本它会自动加载新证书。我们曾遇到某银行客户其内网 API 用的是国密 SSL旧版certifi根本不识别升级后问题消失。这个细节官网 issue 里提了 17 次但文档里只字未提。4.2 陷阱二流式响应中 token 间隔时间ITL统计失真现象stream-latency场景下ITL 数据显示大量0.0ms明显不符合物理规律。根源在于Uni LLM Bench 默认用time.time()记录每个 token 到达时间但 Python 的time.time()在 Linux 上默认精度只有 10ms取决于CONFIG_HZ。当模型输出极快时如 Phi-3-mini 首几个 token多个 token 被记为同一毫秒戳ITL 就变成 0。解决方案启用高精度计时器。在uni-bench.py同级目录创建config.toml[benchmark] high_precision_timer true启用后它会改用time.perf_counter()精度可达纳秒级。实测 Phi-3-mini 的 ITL 从一堆0.0变成真实的[12.3, 14.7, 9.1, ...]序列。这个开关默认关闭是为了避免在老旧 ARM 设备上出现计时器漂移但现代 x86_64 服务器务必打开。4.3 陷阱三并发请求下目标 API 的 connection reset现象concurrency: 20时大量请求返回ConnectionResetError但单请求测试完全正常。这不是 Uni LLM Bench 的 bug而是目标 API 的连接池配置太保守。比如 vLLM 默认--max-num-seqs 256但每个并发请求会占用至少 2 个连接一个发请求一个收流式响应20 并发实际需要 40 连接。解法分两步在目标 API 侧调大连接限制vLLM加参数--max-num-batched-tokens 4096Ollama修改~/.ollama/config.json增加max_queue_size: 100在 Uni LLM Bench 侧用--connection-pool-size 50参数显式声明连接池大小避免 aiohttp 默认的 100 连接争抢。我们曾因此耽误两天排查最后发现是 vLLM 的--max-num-seqs和--max-model-len两个参数存在隐式约束关系——当max-model-len超过 2048max-num-seqs必须同步调大否则连接会被静默丢弃。这个坑vLLM 文档里埋得很深。4.4 陷阱四中文 prompt 导致 token 计数严重偏差现象同一个中文 promptUni LLM Bench 统计的prompt_tokens比 vLLM Admin API 返回的少 30%。原因在于Uni LLM Bench 默认用tiktoken的cl100k_base编码器而 Qwen2 系列模型实际用的是QwenTokenizer二者对中文子词切分规则完全不同。tiktoken会把“人工智能”切为[人工, 智能]2 token而 QwenTokenizer 切为[人, 工, 智, 能]4 token。正确做法在bench-config.yaml中指定 tokenizertargets: - name: qwen2-7b url: http://localhost:8000/v1/chat/completions tokenizer: qwen2 # 支持 qwen2, phi3, llama3, gemma2Uni LLM Bench 内置了主流 tokenizer 的轻量实现不加载完整 transformers仅用于 token 计数体积增加不到 200KB。这个字段必须显式声明否则所有 token 相关指标如吞吐量 tok/s都是错误的。5. 进阶玩法把基准测试变成持续交付流水线的一部分Uni LLM Bench 的终极价值不是生成一份 PDF 报告而是成为你 CI/CD 流水线中一个可自动触发、可自动告警、可自动归档的环节。我们在一个金融风控项目中把它深度集成进了 GitLab CI5.1 每次 PR 合并前自动运行回归测试在.gitlab-ci.yml中加入 stagellm-benchmark: stage: test image: python:3.11-slim before_script: - apt-get update apt-get install -y curl - curl -sSL https://github.com/uni-llm-bench/core/releases/download/v0.3.1/uni-bench.py -o uni-bench.py script: - python uni-bench.py --config bench-config-pr.yaml --output-dir results/pr-$CI_COMMIT_SHORT_SHA - python scripts/compare_baseline.py --baseline results/baseline.jsonl --current results/pr-$CI_COMMIT_SHORT_SHA/results.jsonl artifacts: paths: - results/pr-$CI_COMMIT_SHORT_SHA/ only: - merge_requestscompare_baseline.py是我们写的对比脚本它会检查P95 TTFT 是否恶化超过 15%OOM Rate 是否从 0% 变成 0.1%intent-classify场景的 completion token 数量标准差是否翻倍。任意一项不达标CI 直接失败PR 无法合并。5.2 每日定时任务生成性能衰减趋势图用cron每天凌晨 2 点跑一次全量测试# /etc/cron.d/llm-bench-daily 0 2 * * * root cd /opt/llm-bench python uni-bench.py --config bench-config-daily.yaml --output-dir results/daily/$(date \%Y-\%m-\%d)然后用一个极简的plot_daily.py脚本读取最近 30 天的summary.csv生成 PNG 趋势图import pandas as pd import matplotlib.pyplot as plt df pd.concat([ pd.read_csv(fresults/daily/{d}/summary.csv) for d in sorted(os.listdir(results/daily))[-30:] ]) df[date] pd.to_datetime(df[date]) df.groupby(date)[p95_ttft_ms].plot() plt.savefig(trends/ttft-30d.png)这张图成了我们每周技术例会的固定议程如果 TTFT 曲线连续 3 天上扬就要立刻查是不是模型权重文件损坏、是不是显存泄漏、是不是网络交换机老化。性能监控不该是事后救火而应是事前预警。5.3 与 Prometheus Grafana 对接实现多维度可观测性虽然 Uni LLM Bench 本身不暴露 metrics endpoint但我们用statsd协议做了轻量桥接。在每次测试结束时它会向本地 statsd 发送llm.qwen2-7b.ttft.p95:412.6|g llm.phi3-mini.itl.stddev:4.1|g llm.total.requests:100|c然后在 Grafana 里配置 dashboard可以做到按小时查看各模型 P95 TTFT 趋势设置告警当llm.qwen2-7b.oom.rate 0.05% 持续 5 分钟触发企业微信通知下钻查看某次异常请求的完整 JSONL 日志通过 request_id 关联。这个方案的好处是不侵入 Uni LLM Bench 代码不增加其内存开销所有可观测性能力由外部组件承担。我们用的statsd服务是telegraf内存占用仅 12MB完美契合“轻量化”定位。6. 我的实际体会它改变了我们评估 LLM 服务的方式在用 Uni LLM Bench 之前我们评估一个新模型流程是这样的开发同学手动写个 Python 脚本发 10 次请求看一眼平均响应时间说“还行”上线后用户投诉卡顿再紧急回滚。现在这个流程变成了运维同学在内网服务器上curl下载uni-bench.py修改bench-config.yaml填入新模型地址和业务场景运行python uni-bench.py等待 8 分钟100 次请求 × 20 并发打开summary.csv重点看三行p95_ttft_ms、itl_stddev、oom_rate如果全部达标直接合并到生产配置否则把results/目录打包发给模型团队附上原始日志链接。最大的转变不是效率提升而是决策依据的彻底客观化。以前争论“这个模型到底卡不卡”靠的是主观感受现在争论“P95 TTFT 是 412ms 还是 413ms”靠的是可复现的数据。有一次两个资深工程师为某个模型的流式体验争得面红耳赤最后我们当场跑了一次stream-latency测试导出 ITL 序列用matplotlib画出两条分布曲线——差异一目了然争论 30 秒就结束了。Uni LLM Bench 没有炫酷的 UI没有 AI 自动生成报告甚至没有中文界面。但它像一把瑞士军刀在你需要精准测量时它从不撒谎在你需要快速验证时它从不拖沓在你需要长期追踪时它从不掉链。它不试图教会你什么是 LLM它只帮你回答一个朴素的问题这个 API到底能不能扛住我的业务流量而这个问题的答案永远不该来自厂商的白皮书而该来自你自己的服务器、你自己的配置、你自己的数据。