如何系统评估 LLM 服务商的延迟、吞吐量与可用性

在大语言模型的工程实践中，服务商选型常常被低估。开发者习惯于先确定模型——Claude、Llama、Gemini 或 DeepSeek——再将服务商视为可互换的基础设施。但现实是，同一个模型标识符背后可能对应多个服务商端点，每个端点在基础设施架构、路由行为、量化策略和故障模式上各有不同。用户和系统感受到的差异是具体而实际的：某家服务商可能首 Token 响应极快，但后续生成速度骤降；另一家可能在常规流量下表现优异，却在高并发时频繁失败。

OpenRouter 将服务商性能评估归纳为四项核心指标。首 Token 延迟衡量从发送请求到收到第一个生成 Token 的时间，对面向用户的聊天、智能体和流式交互场景至关重要。输出吞吐量衡量生成开始后每秒产出的 Token 数量，决定长文档、代码生成和批量摘要任务的实际效率。可用性与错误率反映服务商在生产环境中的稳定性，包括故障转移行为和错误恢复路径。量化精度则是影响模型输出质量的隐性变量，精度降低可以节省成本和显存，但在复杂推理和长上下文任务中可能导致明显的质量下滑。

平均延迟是一个具有欺骗性的指标。如果某服务商大多数请求响应迅速，但偶尔出现严重卡顿，平均值仍可能看起来可接受，而用户记住的却是那次卡顿体验。OpenRouter 采用滚动 5 分钟窗口内的百分位统计来追踪延迟和吞吐量：p50 描述典型请求，p90 反映尾部一致性，p99 揭示最坏情况下的行为。对于面向用户的聊天界面，p90 和 p99 延迟是关键参考；对于批处理任务，用户不需要等待每条响应启动，持续吞吐量才是更有意义的衡量维度。

量化精度是服务商评估中最容易被忽视的维度。两家服务商可能都声称提供同一模型，但实际运行的权重精度不同。较低精度的量化版本在简单任务上差异不明显，但在需要精确推理、复杂编码或长上下文理解的场景中，输出质量可能出现明显漂移。OpenRouter 建议在质量敏感的场景中通过 quantizations 字段明确指定精度要求，而不是依赖服务商的默认配置，以确保评估结果与生产环境保持一致。

服务商评估的最终目的是形成可执行的路由策略，而非产出一份静态的排名报告。单次基准测试只能反映特定端点在特定时刻的状态，无法代表真实工作负载下的持续表现。OpenRouter 建议将评估结果转化为路由逻辑：通过 provider.sort 设置排序优先级，配置百分位延迟阈值，指定量化精度要求，并设置故障转移路径。这样，服务商的选择始终与实际测量结果挂钩，而不是被硬编码的名称所固定，从而让应用在服务商性能波动时依然保持稳定。

要点

• 同一模型在不同服务商端点上的延迟、吞吐量和质量表现可能存在显著差异，服务商选型不应被视为次要决策。
• 应使用 p90、p99 等尾部百分位数衡量延迟，而非平均值，因为尾部延迟才是用户实际感知到的体验瓶颈。
• 量化精度是隐性质量变量，在复杂推理和长上下文任务中，不同精度版本的输出质量差异不可忽视，建议显式指定精度要求。
• 基准测试结果只能作为初筛参考，需结合自身实际工作负载进行验证，单次测试无法代表持续生产环境的表现。
• 评估结果应转化为动态路由策略，通过配置排序规则、阈值和故障转移路径，使服务商选择始终与测量数据保持一致。