做LLM应用开发一年半我最大的体会是选模型这件事靠官网的benchmark榜单和别人的推荐基本等于盲人摸象。公开榜单测的是智力题实际业务要的是稳定、便宜、低延迟。DeepSeek、智谱、OpenRouter上挂的各种开源模型宣传语一个比一个漂亮但到了你的网络环境、你的Prompt结构、你的并发压力下表现可能完全两样。所以我花了两周多做了一个叫Uni LLM Bench的自托管轻量化基准测试平台专门干一件事把主流LLM API拉到同一条起跑线上用你自己定义的Prompt、参数和并发量去压最后生成一份能直接指导选型的量化报告。这篇文章就把整个项目的设计思路、部署过程、配置细节和踩过的坑完整拆给你。1. 为什么需要自托管的LLM API基准测试1.1 公开榜单和真实业务场景之间隔着一条鸿沟先聊一个很现实的问题为什么不能直接看MMLU、HumanEval这些公开榜单来选模型公开榜单测的是模型的知识储备和推理能力它回答的问题是这个模型聪明不聪明。但你在业务里接入一个API你在意的不只是聪明不聪明还有它响应快不快、高并发下稳不稳、跑一次要花多少钱。举个例子我有个项目做文档问答用户的Prompt固定在一千字左右要求模型输出控制在两百字以内。这个场景下计算量主要集中在输入侧首Token延迟就成了决定用户体验的关键指标。可这个指标在公开榜单里根本看不到。更麻烦的是同一个模型在不同API服务商手里的表现也不一样。同样的Llama 3.1 70B在A平台部署和B平台部署推理优化不同、底层硬件不同tokens/s可能差出一倍。你说你看谁的评价只能自己测。这是我和团队早期最痛的教训。当时选了一个在某榜单上排名靠前的模型结果上线后发现首Token延迟平均3.8秒用户反馈转圈转到怀疑人生。后来我搭了Uni LLM Bench做对比测试才发现同价位有个模型TTFT只有0.9秒整体体验立刻上了一个台阶。榜单分高不代表服务体验好这两件事不搭界。1.2 自托管跑测试的三个硬理由那为什么不用现成的云端基准测试服务非要自己部署一个第一是数据安全。你测试用的Prompt大概率接近真实业务数据可能是技术文档片段、客服对白、甚至带业务逻辑的指令。把这些数据提交到第三方基准测试平台等于把业务底牌亮给别人看。自己部署所有测试流量只从你的机器到API服务商中间不经过任何第三方。第二是密钥安全。测试时必须配置各家API的Key温度、并发、时长这些参数也需要频繁调整。第三方平台意味着你的密钥要存在别人的服务器上一旦对方被拖库你的钱包就危险了。自托管的话密钥留在自己的环境变量里配合下文要讲的注入方式能把泄露面压到最小。第三是可定制性。云端基准测试平台通常只提供固定的测试用例和压测模式。但实际业务里你是要做流式问答测试还是非流式批量总结是测128K长上下文还是几百字的短对话这些场景差异巨大只有本地部署的工具才能完全按你的需求来设计脚本和指标。一句话总结自托管不是折腾是刚需。谁用谁知道。2. Uni LLM Bench的核心设计思路2.1 轻量化架构的取舍Uni LLM Bench从一开始就定了三条铁律单容器可部署、零外部中间件、配置即场景。整个平台就三个核心模块。Provider适配层负责把不同API服务商的接口差异抹平OpenAI兼容接口直接走标准路径非兼容的单独写适配器压测引擎用异步并发模型驱动请求通过配置控制并发数和持续时间结果存储直接用SQLite报告由内置的Web面板生成。前端只有一个页面展示测试进度和结果对比表。有人会问为什么不用PostgreSQL存数据为什么不用Kafka做消息队列答案是没必要。基准测试是低频任务一次跑几分钟数据量撑死几万行。PostgreSQL和Kafka在这里是纯纯的过度设计反而增加部署负担。SQLite单文件存储备份就是拷个文件恢复就是放回去配合Docker的volume映射足够用了。架构上唯一的重组件是压测引擎。它不能简单的用多线程去并发请求那会在高并发时把线程数撑爆。我用的是异步事件循环加信号量控制并发单进程能扛住数百并发请求而不炸内存。这部分是整个项目里调试最久的往下会细说。2.2 测量指标的定义和计算逻辑衡量一个LLM API服务的质量我把它拆成六个指标这六个指标是Uni LLM Bench报告的核心首Token延迟TTFT是从请求发出到收到第一个Token的时间。它决定用户感受到的响应速度。计算公式很简单从发送请求到流式响应返回第一个字节的耗时。普通网络环境下这个值超过2秒用户就会烦躁。生成速度tokens/s是模型生成后续Token的平均速率。计算方式为总生成Token数除以首Token到结束的耗时。它影响用户等待完整回答的总时间。Chat类模型一般能达到20-50 tokens/s低于10就要警惕是不是服务端过载了。端到端延迟是完整请求的总耗时等于TTFT加上生成阶段耗时。在非流式场景下用户只感知这个值。吞吐量Requests Per MinuteRPM是单位时间能处理的请求数。它和并发数、单请求耗时强相关。做B端服务必须关注这个指标它直接决定你要不要做限流、要不要加缓存。成功率是请求成功的比例。重试后成功的算一次失败重试逻辑应该是业务层的事情基准测试要反映的是原始成功率。最后是成本效率计算每千Token的实际支出。不同API定价模式不一样有的按输入输出分别计价有的统一计价。Uni LLM Bench统一折算为每千输出Token成本方便横向比较。这四个指标全部来自请求日志字段没有埋额外的点做到零侵入。基准测试本身不该影响被测系统的行为这是底线。3. 部署和配置实操3.1 用Docker十分钟跑起来Uni LLM Bench的部署极简因为设计目标就是一条命令起服务。前提是你的机器装了Docker别的要求没有了。docker run -d --name uni-llm-bench \ -p 8080:8080 \ -v $(pwd)/data:/app/data \ -v $(pwd)/config:/app/config \ -e UNI_LLM_BENCH_DATA_DIR/app/data \ -e UNI_LLM_BENCH_CONFIG_DIR/app/config \ unl1m/uni-llm-bench:latest这里几个关键参数说明一下。-p 8080:8080暴露Web面板端口习惯用什么端口就映射什么。-v挂载两个目录data存SQLite数据库和测试报告config放所有配置文件。强烈建议把这两个目录挂出来不然容器一删数据全没了别问我怎么知道的。启动成功后浏览器访问http://localhost:8080看到登录页说明服务正常。默认没有认证因为设计上是内网工具如果你要暴露到公网务必在前面挂一层反向代理加上Basic Auth别裸奔。3.2 密钥管理与Provider配置安全这一块我单独多说几句因为不少朋友在这上面踩过坑而且是大坑。密钥管理的第一个原则是密钥绝不写进配置文件。Uni LLM Bench的Provider配置里只引用环境变量名不填实际密钥值providers: deepseek: base_url: https://api.deepseek.com/v1 api_key_env: DEEPSEEK_API_KEY models: - deepseek-chat - deepseek-reasoner openrouter: base_url: https://openrouter.ai/api/v1 api_key_env: OPENROUTER_API_KEY models: - anthropic/claude-3.5-sonnet - meta-llama/llama-3.3-70b-instruct上面配置里的api_key_env字段对应的是一个环境变量名你需要在启动容器时通过-e DEEPSEEK_API_KEYsk-xxx传进去或者使用Docker Secrets。这样配置文件即使泄露里面的信息也不足以让对方盗刷你的额度。第二个原则是Provider级限流。API Key泄露最可怕的是被盗刷我在平台里加了请求配额控制每个Provider可以设定单日最大请求数和最大消费金额超过阈值自动熔断。这个功能救过我一次——某次调试时我不小心把Key提交到了公开仓库对方拿到后疯狂调用但因为配额限制损失被控制在了几十块钱。没有配额的话一晚上刷几千块也不是不可能。第三个原则是测试隔离。专门用一个低权限的测试账号来跑基准测试跟生产环境用的Key分开。测试Key的额度上限调低出了事不会影响线上业务。3.3 设计测试场景三种常用的配置模板建好Provider后下一步是定义测试场景。场景配置就是告诉压测引擎用什么Prompt、请求参数是什么、并发多少、跑多久。我提供三种模板覆盖大多数业务场景。第一种是通用对话模板。适合大多数Chat场景比如客服、知识库问答。Prompt用一段相对固定的问句温度设0.7max_tokens设1024模拟正常用户请求scenarios: general_chat: prompt: 写一篇800字的文章主题是城市公共交通优化 max_tokens: 1024 temperature: 0.7 concurrency: 10 duration: 60第二种是推理密集型模板。适合代码生成、数学推理、逻辑分析场景。这类请求通常输出更长推理更耗计算。温度设0.2甚至0max_tokens设2048因为推理模型会先生成很长的思考过程。并发要降下来否则触发服务端限流的概率大增scenarios: reasoning_task: prompt: 给定一个整数数组找出其中两个数相加等于目标值返回下标。请先用文字描述你的解题思路再给出代码 max_tokens: 2048 temperature: 0.2 concurrency: 4 duration: 120第三种是流式响应模板。适合需要打字机效果的场景。这个场景会额外记录首个Token到达时间并单独统计流式传输的稳定性——如果流式传输过程中出现卡顿说明网络或者服务端有瓶颈scenarios: streaming_chat: prompt: 讲一个关于程序员的有趣故事 max_tokens: 512 temperature: 0.8 concurrency: 5 duration: 60 stream: true一个容易被忽略的点是duration参数。我建议单次测试至少跑60秒不要只发几个请求就结束。LLM API服务的性能波动很大短时间内的样本量不足以反映真实分布60秒可以覆盖到服务端的自动扩缩容周期数据更有参考价值。测试场景可以叠加Uni LLM Bench支持在同一批测试中依次跑多个场景最后汇总报告。比如上午跑通用对话下午跑推理任务中间不用手动干预。4. 运行测试和结果解读4.1 启动一次完整测试的两种方式配置完成后启动测试有两种方式命令行和Web面板。命令行适合写进CI/CD脚本或者定时任务。安装CLI后直接执行uni-llm-bench run --config ./config/scenarios.yaml --providers deepseek,openrouter引擎会按场景顺序开始压测实时打印当前进度。日志会标记每个Provider的当前并发数、已发请求数、失败数、当前TTFT滑动平均值。看到这个输出你对整个压测的进展就了然于胸了。Web面板适合交互式使用。你可以在页面上直接选择要测试的Provider、模型和场景点击运行前端通过WebSocket实时接收进度数据绘制TTFT和tokens/s的实时曲线。这个实时曲线很直观而且你会立刻发现一些有意思的现象某个模型在测试刚开始时速度很快10秒后突然变慢大概率是触发了服务端的算力调度机制。这里要特别说明并发数的选择逻辑。并发不是越大越好。我踩过的坑是刚开始做基准测试时图省事把所有场景的并发都设成50结果测出来全是429限流错误数据直接报废。正确的做法是阶梯式加压先用并发1跑一遍拿到单请求延迟基线再逐步提高并发观察吞吐量拐点和错误率变化。Uni LLM Bench支持并发阶梯配置concurrency_profile: - 1 - 5 - 10 - 20 - 50每个并发级别跑30秒这样可以画出一条吞吐量-并发数曲线。你会发现大部分API服务在某个并发点之后吞吐量不再上升甚至下降那个点就是实际生产环境应该设置的最大并发数上限。4.2 报告解读不要只看平均数测试跑完后进入结果分析环节。Uni LLM Bench会输出一份Markdown格式报告核心是一张对比表指标DeepSeek-chatClaude 3.5 Sonnet (OpenRouter)Llama 3.3 70BTTFT p50 (ms)81215431877TTFT p95 (ms)145028944213生成速度 (tokens/s)42.631.222.8端到端耗时 p50 (s)8.9012.1517.32成功率98.5%96.8%93.2%每千输出Token成本 (元)0.321.970.68解读报告时我的第一个建议是不要只看平均数和p50要看p95。只看平均数的坏处是数据分布不均匀时平均数毫无意义。假设100个请求里99个快、1个超时平均耗时可能还不错但真实用户体验里有1%的概率遇到超时这个风险在高并发时会被放大。p95表示95%的请求耗时都低于这个值p95和p50的差值越大说明服务的抖动越严重。第二个建议是综合成功率和成本效率一起看。有些模型虽然生成速度快但经常触发重试实际有效吞吐反而更低。上表里Llama 3.3 70B虽然便宜但成功率只有93.2%如果业务对响应可靠性要求高比如客服工单系统这张表的结论就不是选最便宜的而是选DeepSeek因为它在成本和成功率之间最平衡。第三个建议是记录测试时间和测试时段的上下文。LLM API的性能有明显的峰谷差异晚高峰普遍比凌晨慢20%-30%。第一次测试跑在下午、第二次测试跑在晚上两次的对比数据天然不可比。所以做横向对比时确保所有Provider在相同时间段跑最好在同一天内跑完。我通常安排在凌晨两三点跑正式对比测试那个时段网络干净、服务端空闲数据能反映服务的真实上限。5. 常见问题排查实录5.1 400、401和429三类高频报错逐一拆解用Uni LLM Bench跑测试时最常见的报错有三类排查思路完全不同。第一类是HTTP 400错误。典型的报错是api error: 400 this models maximum context length is 1048576 tokens。这个报错的原因很直白你的Input加上Output超过了模型的上下文窗口。排查路径是看你场景配置里max_tokens和Prompt长度是不是加起来超过了窗口限制。长上下文模型比如支持1M token的模型反而不容易撞墙容易撞墙的是那些只有32K窗口的模型。这种问题改配置就行把max_tokens调小或者精简Prompt。另一种400报错是模型名不对比如api error: 400 the supported api model names are deepseek-flash, deepseek-v4。这说明配置里的model字段和服务商实际支持的模型名不匹配。服务商升级模型后下线了旧名字或者你抄的配置模板过时了。解决办法很简单去服务商文档查最新的模型列表改配置里的models字段。第二类是401鉴权错误。排查这个问题的步骤是先确认环境变量真的传进了容器。可以用docker exec进容器看环境变量或者看启动日志里有没有自动脱敏的密钥加载记录。很多时候环境变量名拼错或者容器重启后忘了重新传就会出现这个问题。另外注意某些平台需要用请求头而非请求体传Key如果你的Provider适配器没有正确实现这一点也会报401。第三类是429限流。报错信息通常是api error: 429 you have exceeded the 5-hour usage quota。这说明你触发了服务端的调用频率配额或用量配额。处理方式分两个层面一是把并发数调低回退到合理的区间这个直接在场景配置里改concurrency就行二是如果业务确实需要更高的并发去服务商控制台申请提高配额但申请理由要写清楚。提示Uni LLM Bench在压测引擎内置了自动退避逻辑收到429后会按指数退避重试。但你要区分引擎自动重试和测试成功。如果一次请求连续重试3次都429它会放弃请求并记为失败。这个设计是为了让报告反映真实服务可靠性重试只能掩盖问题不能解决问题。5.2 超时、网络和并发调试的经验如果你测试的是一个部署在境外服务器上的API或者你的服务器和API所在地之间的网络链路比较复杂你可能会遇到大量超时。现象是TTFT高达5秒以上甚至直接读秒超时。这时候先别急着怀疑模型性能用网络质量分析工具测一下到API服务端的网络延迟和丢包率很可能是物理链路的问题。针对网络抖动我在平台里加了三个层级的防护第一层是请求超时设置。建议设成三档连接超时10秒、TTFT超时30秒、端到端超时120秒。这个设计借鉴了业务系统的超时治理思路避免某个慢请求卡住整个压测流程。第二层是动态重试。对于超时的请求最多重试2次重试之间有0.5秒的抖动间隔避免重试风暴。这个重试策略是可配置的如果你做的是追求真实失败率的测试可以把重试次数设成0。第三层是并发控制。前面提到的信号量机制配合一个简单的滑动窗口算法在请求速率超过设定值时主动延后请求保证压测本身不会因自激效应导致数据失真。还有一个经验值得分享p95 TTFT的优化方向不是靠加并发。我在测试中发现有些模型并发数从5提到20后p95 TTFT翻倍但p50变化很小。这说明服务端有排队机制高并发时部分请求被排到了后面。如果你的业务对响应时间很敏感宁可保持低并发、用更多的实例去做负载均衡也不要在单连接上盲目提高并发。6. 更进一步扩展思路写到这里Uni LLM Bench的核心功能已经介绍完了。最后聊几个我最近在琢磨的扩展方向算是抛砖引玉。第一是支持自定义评测集。现在的基准测试用的是预设Prompt但比这更有价值的是把你自己线下积累的真实业务Prompt导入进来比如整理成JSONL格式这样测出来的数据跟线上表现几乎一致。我计划在下一个版本加入数据集导入功能让基准测试直接复用业务数据资产。第二是多轮对话模拟。目前大多数基准测试都是单轮请求但实际业务里有大量多轮对话场景——用户连续追问、上下文不断累积。多轮对话对API的上下文管理能力要求完全不同我准备增加一个会话模拟器按预设的对话路径自动跑多轮记录每轮的TTFT和整体连贯性。第三是成本预算告警。前面说到了配额熔断现在想进一步做成本预测根据历史测试数据输入预估的日调用量自动预测月成本。这个功能对于做预算申报的团队会很实用。最后就我的实战体会做一个总结做LLM API基准测试没有一顿操作猛如虎的复杂方案核心就是控制变量这四个字——固定的Prompt、固定的参数、固定的测试时长、固定的时间段。Uni LLM Bench做的事就是用工具把这些变量固化下来把测量结果量化成表格。真正有价值的是你基于这些数据做的决策判断。工具永远只是手段理解指标背后的含义才是做好模型选型的关键。
