如何评估不同 LLM 提供商在延迟、吞吐量和正常运行时间上的性能

一句话看懂：选择大模型时不能只看模型名字，同一模型在不同 API 提供商手中，延迟、吞吐量、稳定性和实际回答质量都可能天差地别；OpenRouter 发布的这份评估指南，为开发者提供了一套可量化、可操作的提供商性能衡量方法，帮助避免被单一基准测试误导。

事件核心：发生了什么

OpenRouter 在最新博客中系统梳理了评估 LLM 提供商性能的关键方法。文章指出，开发者通常先选模型（比如 Claude、Llama、Gemini、DeepSeek），再选提供商，但同一个模型通过不同提供商端点上运行时，基础设施、路由行为、量化精度和故障模式均不相同，最终用户体验差异明显。评估应聚焦四个核心指标：首 Token 延迟（TTFT）、输出吞吐量（每秒输出 Token 数）、正常运行时间和量化精度。

OpenRouter 特别强调，不能只看平均延迟，而要关注 p90/p99 百分位延迟，因为尾部延时才真正影响用户端对话体验；量化精度是隐藏质量变量，同一模型在不同提供商可能以不同精度运行，直接影响复杂问题的回答质量。

为什么重要

这篇指南的发布意味着大模型生态正在从“选模型”进入“选服务”阶段。随着开源模型和相同权重模型被多家厂商部署，提供商的 serving 环境成为决定生产系统表现的关键变量。过去行业习惯用单次 benchmark 结果判定模型性能，但该指南指出基准测试只反映一个端点、一个时刻的表现，与真实工作负载存在差距。OpenRouter 作为多提供商路由平台，给出的这套评估方法论可能成为行业标准——它把提供商的差异从“凭感觉选”变成“可量化比较”，对基础设施层竞争影响深远。

对用户/开发者/创作者的影响

对需要接入大模型 API 的开发者而言，这份指南提供了实用的决策框架：第一，交互式应用（如聊天、Agent）应优先关注 p90/p99 首 Token 延迟，而非平均速度；第二，批处理、文档生成、代码编写任务则应衡量稳定输出吞吐量；第三，如果任务涉及推理、长上下文或代码生成，务必检查提供商是否使用全精度量化，而非压缩版本；第四，生产环境必须设计故障切换策略，不能只依赖一个提供商的可用性。指南还建议将评估结果直接转化为路由策略，通过设置 provider.sort、百分位阈值、量化字段和回退机制，让模型选择与真实测量数据绑定。