1. 先搞清楚延迟、吞吐量和正常运行时间到底测什么如果你正在为项目选型 LLM 服务或者已经在用但发现响应时快时慢、批量任务卡顿、偶尔服务不可用那直接看这三个指标比对比功能列表更有用。延迟是单次请求从发起到收到第一个字符的时间吞吐量是单位时间内能处理多少请求或 token正常运行时间则是服务稳定可用的比例。很多人容易混淆延迟和吞吐量——低延迟不代表高吞吐。比如某个服务商单条问答响应很快但一旦并发请求上去要么排队等待时间变长要么直接报错。而正常运行时间往往被忽略直到线上服务突然中断才后悔没提前测过。我一般会先明确测试场景是面向实时交互的低延迟优先还是侧重批量处理的高吞吐需求或是需要 7x24 小时稳定运行的生产环境。不同场景下同一组数据的重要性完全不同。2. 测试环境准备和指标定义2.1 硬件和网络基线测试环境不一致结果基本没有可比性。我的习惯是固定测试机配置例如 4 核 8G 内存、网络条件同一运营商、避免跨地域访问并记录测试时段。如果测试国内服务商尽量用同地域的云服务器测试国际服务商则明确是直连还是经过加速链路。关键是要先跑一次基线测试用ping和traceroute记录基础网络延迟用curl测几个静态接口确认网络稳定性。避免把网络波动误判为服务端性能问题。2.2 定义可量化的指标延迟通常看平均延迟avg latency和 P95/P99 延迟长尾请求。吞吐量一般用 RPMRequests Per Minute或 TPMTokens Per Minute衡量。正常运行时间可以用持续探测的可用率百分比表示。这里最容易漏掉的是超时设置比如设置 10 秒超时但服务实际响应需要 12 秒这时会计入错误而非高延迟。建议根据业务实际需求设置超时阈值并在结果中明确标注。3. 实测延迟单请求和并发场景3.1 单请求延迟测试先用最简单的一条请求测试例如 100 字以内的问答。用 Python 的requests库或curl记录从发送到接收第一个字节的时间。注意不要只测一次而是连续测 100 次以上去掉最高最低的 10% 取平均值。示例代码框架以 OpenAI 兼容接口为例import requests import time def test_single_latency(api_url, headers, prompt, rounds100): latencies [] for i in range(rounds): start time.time() response requests.post(api_url, json{messages: [{role: user, content: prompt}]}, headersheaders) end time.time() if response.status_code 200: latencies.append(end - start) else: print(fRequest failed: {response.status_code}) time.sleep(0.1) # 避免触发限流 avg_latency sum(latencies) / len(latencies) p95 sorted(latencies)[int(len(latencies) * 0.95)] return avg_latency, p95测试时注意请求体的 token 数量不同长度的输入对延迟影响很大。最好固定输入 token 数例如 512 tokens再做对比。3.2 并发下的延迟变化接着测试并发请求下的延迟。从并发数 1 开始逐步增加到 5、10、20观察平均延迟和 P95 延迟的变化。如果并发增加后延迟急剧上升或错误率增加说明服务端并发处理能力有限。注意不要一上来就开高并发先确认单请求正常。有些服务商在低频测试时表现良好但并发稍高就返回 429 限流错误。4. 吞吐量测试持续负载和峰值处理4.1 持续负载测试吞吐量测试需要持续发送请求并统计单位时间内成功处理的数量。可以用locust或wrk等压力测试工具设定固定并发数运行 5-10 分钟记录 RPM 和 TPM。关键是要区分峰值吞吐量和可持续吞吐量。有些服务商允许短时间内爆发高吞吐但几分钟后就开始限流或降级。生产环境更需要的是可持续吞吐量。4.2 令牌桶和限流策略测试过程中要留意服务商的限流策略。常见的有令牌桶token bucket或漏桶leaky bucket算法。如果收到 429 状态码说明触发了限流。这时需要查看响应头的X-RateLimit-*字段了解限制规则。实测时我会逐步增加并发直到出现限流或错误率超过 5%然后回退到稳定阈值。这个阈值就是该服务商在当前配置下的实际可用吞吐量上限。5. 正常运行时间与故障转移5.1 持续探测方案正常运行时间不能靠人工感觉需要用监控工具定期探测。简单的方式是用 UptimeRobot 或自建 Prometheus Blackbox Exporter每 1 分钟请求一次关键接口例如/v1/models统计可用率。探测点要分散在不同地域和运营商避免单点网络问题误判。建议至少运行 7 天覆盖工作日和周末的不同时段。5.2 故障切换和重试机制即使服务商承诺 99.9% 的可用性也要准备故障转移方案。测试时要记录服务不可用时的典型表现是直接连接超时、返回 5xx 错误还是响应变慢。在实际代码中需要实现重试机制例如指数退避和降级策略。例如from tenacity import retry, stop_after_attempt, wait_exponential retry(stopstop_after_attempt(3), waitwait_exponential(multiplier1, min4, max10)) def call_llm_with_retry(api_url, payload): response requests.post(api_url, jsonpayload, timeout30) response.raise_for_status() return response.json()6. 结果分析和选型建议6.1 数据可视化对比测试完成后把各服务商的延迟分布、吞吐量曲线、错误类型统计做成图表。延迟可以用箱线图显示中位数和离群点吞吐量用折线图展示并发数-RPM 的关系。重点关注 P95 延迟而不仅是平均值——用户体验往往被少数慢请求破坏。同时对比不同服务商的性价比即每元能买到的 TPM。6.2 根据场景选择实时交互场景如聊天机器人优先选 P95 延迟低且稳定的服务商吞吐量要求不高。批量处理场景如文档摘要更关注吞吐量和成本延迟只要在可接受范围内即可。生产级应用必须验证正常运行时间并准备多服务商故障转移方案。不要盲目追求单项指标最优。某个服务商可能延迟最低但价格昂贵另一个可能吞吐量高但偶尔不稳定。根据实际业务需求权衡选择。7. 长期监控和优化调整7.1 建立性能基线上线后要继续监控关键指标建立性能基线。当发现延迟逐步上升或吞吐量下降时可能是服务商负载增加或自身使用模式变化所致。定期如每季度重新跑一次完整测试对比历史数据。7.2 参数调优和适配不同服务商对参数敏感度不同。比如temperature、max_tokens等参数会影响响应时间和 token 消耗。可以针对常用场景做参数调优在质量、速度和成本间找到平衡点。同时关注服务商的更新日志——模型升级可能带来性能变化。重要升级前最好在测试环境验证兼容性和性能影响。真正落地时我会把测试脚本和配置模板保存下来后续扩增服务商或调整测试用例时直接复用。这样既能保证数据可比性也降低了长期维护成本。