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

开发者通常在选择 LLM 时，会先挑选 Claude、Llama、Gemini 或 DeepSeek 这样的模型，然后把提供商当作次要决策。这可以理解。但仅凭模型选择，并不能告诉你该模型通过某个特定提供商端点时的表现如何。

同一个模型可以通过多个提供商端点运行，而每个端点可能带来不同的基础设施、路由行为、量化选择和故障模式。你的用户和系统会以实际可感的方式看到这些差异。某个提供商可能很快返回第一个 token，但在响应剩余部分变慢。另一个提供商可能提供精度较低的变体，在更难的提示词上出现漂移。还有一个提供商可能在正常流量下表现良好，但在负载下失败。

提供商评估比较的是服务环境，而不是把模型当作一个独立产品来看待。它要问的是：用户等待第一个 token 要多久，响应剩余部分多快到达，提供商在负载下表现如何，以及模型以什么精度级别运行。

本指南按照你可以采取行动的先后顺序来逐一探讨这些问题：延迟、吞吐量、正常运行时间和量化。一旦你能够衡量这些权衡，下一步就是把结果转化为路由逻辑，这样你的应用就不会硬编码某次基准测试中看起来最快的那个提供商。

简而言之

• 同一个模型在不同提供商端点上的表现各不相同。即便模型 slug 完全相同，基础设施、量化、负载处理和路由默认设置都会改变结果。
• 4 项指标决定提供商表现：延迟（首 token 时间）、吞吐量（输出 token/秒）、正常运行时间和量化。
• 看 p90/p99 的延迟，而不是平均值。尾部延迟才是面向用户的应用真正感受到的；批处理任务可以按 p50 来评估。
• 量化是隐藏的质量变量。两家提供商可以用不同的精度服务同一个模型；当质量至关重要时，用 quantizations 字段将其固定下来。
• 用排行榜做初筛，然后在你自己的提示词上验证。基准测试衡量的是某一时刻的某一个端点；你的工作负载并不是基准测试的工作负载。
• 把评估转化为路由策略。设置 provider.sort、百分位阈值、quantizations 和回退方案，让提供商的选择始终与你的测量结果挂钩，而不是硬编码的名称。

评估提供商表现的 4 项指标

聊天产品、文档生成流水线和后台摘要任务并不需要相同的性能画像。合适的提供商取决于工作负载。

一个提供商可能在响应开始时看起来很快，但等到完整答案结束时仍然感觉缓慢。首 token 时间（TTFT）捕捉的是这一体验的前半部分。输出速度捕捉的是后半部分，因为它衡量的是生成开始后提供商每秒生成多少 token。一个 TTFT 表现强劲的提供商，如果其持续 token 速率下降，仍然可能带来糟糕的长文本体验；而一个吞吐量强劲的提供商，如果首个 token 到达很晚，在聊天界面中仍然可能感觉很差。

正常运行时间补上了速度指标无法覆盖的生产层面。一个在基准测试条件下表现良好的提供商，如果在使用高峰期出现故障、意外触发速率限制，或产生迫使重试的错误激增，仍然可能对应用造成损害。

一旦将这些测量指标区分开来，下一步就是在适当的置信水平上解读它们。中位数延迟可以描述典型请求的情况，但生产系统还需要知道有多少请求的耗时远高于典型请求。这正是 p50、p75、p90 和 p99 等百分位指标比平均值更有用武之地的地方。

如何解读百分位延迟和吞吐量

平均值会掩盖那些造成最差用户体验的请求。如果一个提供商能快速处理大多数请求，但偶尔会严重卡顿，平均值看起来可能仍然可以接受，但你的用户会记住那次卡顿的请求。

我们使用滚动 5 分钟窗口内的百分位统计数据，追踪每个模型和提供商的延迟与吞吐量指标。可用的百分位为 p50、p75、p90 和 p99。

p50 延迟值描述的是中位数请求，但它可能掩盖那些位于分布中更靠外位置的请求。一个提供商可能拥有出色的 p50 和糟糕的 p99，这意味着典型请求体验良好，而一小部分但占比可观的请求耗时足够长，从而造成可见的延迟。

正确的百分位数取决于延迟实际在何处损害工作流。在聊天界面中，延迟出现在首个 token 到达之前，因此 p90 和 p99 延迟表明体验在典型请求之外是否仍然保持一致。在批处理任务中，用户并不等待每个响应开始，因此持续输出速度能更好地反映系统在一段时间内能完成多少工作。

举一个具体的例子，在 2026 年 6 月 24 日 UTC，两个提供 anthropic/claude-sonnet-4.5 服务的提供商在 1 天窗口内显示出不同的延迟曲线，且两者的 p99 尾部都比其 p50 值所暗示的要宽得多。

百分位数展示了提供商响应的稳定性，但它们无法解释两个提供同一模型服务的提供商之间的所有差异。一旦延迟和吞吐量清楚了，下一个问题就是这两个提供商是否以相同的形式提供该模型。

为什么量化会改变提供商的结果

量化是最容易被忽视的提供商差异之一，因为模型名称并不总能揭示模型实际是以何种方式提供服务的。两个提供商可能暴露相同的模型 slug，却以不同的精度级别运行它。一条路由可能保留更多模型原始的权重精度，而另一条则可能降低精度以减少内存占用、提升服务效率，或让端点的运营成本更低。

降低精度会改变模型在不同类型提示词下的行为表现。较低的精度可以让模型服务更快、更便宜，但它也可能改变模型处理那些需要谨慎推理、代码正确性、长上下文或严格指令遵循的提示词的方式。

我们将量化作为一种路由决策暴露出来，因为提供商选择不应把每一个具有相同模型名称的端点都视为等价。quantizations 字段让你选择你的应用可以使用哪些精度级别，从而使质量风险成为路由策略的一部分，而不是一个隐藏的提供商细节。

把这张表当作一种判断依据，用来决定你的工作负载可以承受用多少精度去换取更低的推理服务成本或更高的速度。摘要流水线或许能容忍一个精度较低的端点，只要在你自己的测试集上输出保持稳定。而代码编辑工作流、工具调用智能体或推理密集型任务，留给静默质量损失的空间就更小，因为一点点漂移就可能改变答案、中断调用，或生成看起来合理但实际失败的代码。

当你的评估显示某个工作负载需要更高精度时，使用 quantizations 字段来限制你的应用可以使用的提供商端点：

{
  "provider": {
    "quantizations": ["fp16", "bf16"]
  }
}

如果你的评估显示某个提供商的端点在你的提示词上表现不佳，你也可以将其排除：

{
  "provider": {
    "ignore": ["provider-slug"]
  }
}

模型名称只是评估的起点，真正完成评估的是提供商端点。量化正是公开基准测试与生产环境表现可能出现分歧的原因之一。

如何读懂提供商基准测试而不被误导

一个公开排行榜能帮你缩小候选范围，但它无法描述你的生产路径。基准测试是在某个时间点，使用它们自己的提示词、参数、区域和评分方法，对选定的端点进行测量。你的应用可能使用与基准测试所测量的不同的端点、提示词形态或路由路径。

一次有用的提供商基准测试审查，应该在把结果当作生产环境证据之前，先检查该基准测试已发布的方法论：

当基准测试结果引导你在自己的工作负载下进行第二轮测试时，它才变得有价值。如果某个排行榜指向一个速度快的服务商，那么下一个问题就是：在你的提示词长度、路由路径和质量要求下，该端点是否依然保持快速。如果是，就把这一结果转化为一条路由规则。

根据静态排名硬编码单一服务商，会构建出一个脆弱的系统。服务商的行为会随流量、故障、路由路径和服务配置而变化。这正是我们的路由层所设计要处理的问题。

为什么多服务商路由改变了服务商评估方式

孤立地评估一个服务商，只能告诉你该服务商在你所测量的条件下表现如何。它无法告诉你，当该服务商触及速率限制、在负载下变慢或暂时不可用时会发生什么。如果你的应用依赖单一服务商端点，那么服务商侧的每一次故障都会成为你应用行为的一部分。

路由层将评估从一次性的提供商选择转变为一项持续进行的选择问题。与其把每一次提供商故障、速率限制或性能下降都当作应用故障来处理，你可以自动绕过这些状况进行路由。

我们实时监控各提供商的响应时间、错误率和可用性。我们的默认路由会降低在过去 30 秒内出现重大故障的提供商的优先级，在稳定的提供商之间进行负载均衡并倾向于更低的价格，同时将其余提供商保留为备用。

多提供商路由并不能保证完美的正常运行时间。它通过在某个提供商发生故障或变得不可用时提供替代路径，来减少对单一端点的依赖。

模型回退在提供商级路由不足以解决问题时应用同样的原则。如果主模型因其提供商宕机、受到速率限制或无法作答而无法完成请求，OpenRouter 可以尝试回退列表中的下一个模型。

一个实用的路由策略应当回答三个问题：

将服务商评估转化为路由策略

主要的 路由控制项 位于 provider 对象内部。它们让你可以对服务商排序、优先考虑性能阈值、选择或避开服务商端点、按量化方式过滤，以及决定是否允许回退运行。模型回退使用 models 数组。

最简单的控制方式是模型后缀。当请求应优先选择吞吐量更高的提供商时，添加 :nitro：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct:nitro",
    "messages": [
      { "role": "user", "content": "Write a concise product summary." }
    ]
  }'

当请求应优先选择更低价格时，添加 :floor：

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/llama-3.3-70b-instruct:floor",
    "messages": [
      { "role": "user", "content": "Write a concise product summary." }
    ]
  }'

当某一项偏好应当在请求中占据主导地位时，这些快捷方式就能派上用场。生产环境中的路由往往需要更精细的规则。例如，一个客服工作流可能需要最便宜的端点，同时该端点仍能维持足够的吞吐量以完成较长的摘要。在这种情况下，可以将价格排序与吞吐量偏好结合起来：

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({
  apiKey: process.env.OPENROUTER_API_KEY,
});

const completion = await openRouter.chat.send({
  models: [
    'anthropic/claude-sonnet-4.5',
    'openai/gpt-5-mini',
    'google/gemini-3-flash-preview',
  ],
  messages: [
    {
      role: 'user',
      content: 'Summarize this customer support thread and identify the next action.',
    },
  ],
  provider: {
    sort: {
      by: 'price',
      partition: 'none',
    },
    preferredMinThroughput: {
      p90: 50,
    },
  },
  stream: false,
});

该请求要求 OpenRouter 在所列模型中寻找并优先选择最便宜的模型和提供商端点，且该端点需在 p90 下达到每秒 50 tokens。低于该阈值的端点并不会从路由中消失。它们会被排到首选选项之后，这样当所有首选端点都失败时，它们仍然可用。

聊天工作流也可以用同样的模式来处理延迟。如果首 token 延迟造成了用户可见的瓶颈，可以将价格排序与延迟偏好结合起来：

const completion = await openRouter.chat.send({
  models: ['anthropic/claude-sonnet-4.5', 'openai/gpt-5-mini'],
  messages: [
    {
      role: 'user',
      content: 'Answer this user message in a support chat.',
    },
  ],
  provider: {
    sort: {
      by: 'price',
      partition: 'none',
    },
    preferredMaxLatency: {
      p90: 3,
    },
  },
  stream: false,
});

该请求在决策中保留了价格因素，但优先选择 p90 延迟低于 3 秒的端点。这一偏好来自提供商评估，而非固定的提供商选择。

同样的模式也适用于质量和可靠性决策。如果某个工作负载在更高精度的端点上表现更好，可以添加量化过滤器：

const completion = await openRouter.chat.send({
  model: 'deepseek/deepseek-v3.2',
  messages: [{ role: 'user', content: 'Review this code change for logic errors.' }],
  provider: {
    quantizations: ['fp16', 'bf16'],
  },
  stream: false,
});

如果某个提供商未通过你的测试集，或不符合你的运营要求，就把它从路由中排除：

const completion = await openRouter.chat.send({
  model: 'meta-llama/llama-3.3-70b-instruct',
  messages: [{ role: 'user', content: 'Draft a release note from these changes.' }],
  provider: {
    ignore: ['provider-slug'],
  },
  stream: false,
});

如果补全可靠性比坚持使用单一模型更重要，就使用回退列表：

const completion = await openRouter.chat.send({
  models: [
    'anthropic/claude-sonnet-4.5',
    'openai/gpt-5-mini',
    'google/gemini-3-flash-preview',
  ],
  messages: [
    {
      role: 'user',
      content: 'Summarize this incident report and list the next actions.',
    },
  ],
  stream: false,
});

路由策略应当出现在测量之后，而不是之前。在设定阈值之前，你需要一个简单的评估流程，来告诉你哪些阈值才重要。

提供商评估的 5 步清单

1. 先定义工作负载。不要从提供商开始，而要从你所需的产品行为开始。流式聊天应用应当测量首 token 时间和 p90 延迟。批量生成工作流应当测量吞吐量和总完成时间。推理密集型工作流则应增加质量检查和量化审查。

2. 借助外部基准和提供商的实时数据进行初筛。使用公开排行榜来识别候选者，然后在我们目录中的模型页面上查看当前的提供商数据。

3. 用你自己的提示词进行测试。运行能够代表你产品真实工作负载的提示词。要包含短提示词、长提示词、简单提示词，以及那些通常会让弱提供商崩溃的提示词。把速度、可靠性和输出质量放在一起衡量。

4. 检查量化方式和提供商行为。如果两个提供商提供同一个模型，但其中一个在困难提示词上给出的答案更差，在归咎于模型之前，先检查服务路径。当你的评估支持这一决定时，固定更高精度或排除较弱的端点。

5. 通过路由来落实结果。把评估转化为请求设置。使用sort、:nitro、:floor、preferred_min_throughput、preferred_max_latency、quantizations、ignore以及回退机制，让应用与测量结果保持一致。这样就能让提供商的选择与你的应用绑定，而不是与通用的市场排名绑定，并且随着提供商行为随时间变化，性能审查也变得可重复。

常见问题

对于 LLM 提供商来说，延迟和吞吐量有什么区别？

延迟衡量的是用户在第一个 token 到达之前等待的时间。吞吐量衡量的是生成开始后提供商每秒生成的输出 token 数量。聊天 UI 通常优先考虑延迟，而长输出工作流则优先考虑吞吐量。

对于 LLM 延迟来说，p50、p90 和 p99 分别是什么意思？

p50 是中位数请求体验。p90 意味着 90% 的请求在该延迟值或以下完成。p99 展示了分布的远端尾部，当你的应用必须为几乎所有用户提供可预测的响应时，你就需要它。

为什么同一个模型在不同提供商那里表现会有差异？

提供商端点会改变服务环境。量化、基础设施、上下文支持、负载以及提供商的默认设置都会影响输出行为。模型 slug 标识的是模型家族，但提供商路径会影响生产环境中的实际结果。

如何避免使用表现不佳的提供商？

在你确认问题确实因提供商而异之后，先用你自己的提示词进行测试。如果问题可以复现，使用 provider.ignore 来排除该提供商。如果问题似乎与较低精度有关，使用 provider.quantizations 来优先选择更高精度的端点。

多提供商路由能提升正常运行时间吗？

多提供商路由可以在某个提供商出现故障、触发速率限制或宕机时增加回退路径，从而提升可靠性。它降低了对单一提供商的依赖，但仍然取决于路由策略的质量以及可用提供商的情况。

使用故障转移会产生额外费用吗？

不会。请求是按照最终提供补全服务的模型和提供商端点来计费的。OpenRouter 不会在提供商定价上加价，失败的请求也不会计费，无论你是路由到一个提供商还是十个提供商。

我应该如何路由到最快的提供商？

当你关注首 token 延迟时，请使用 provider.sort: "latency"。当你关注长文本生成速度时，请使用 provider.sort: "throughput" 或 :nitro 后缀。当你需要可预测的性能而非简单的速度偏好时，请添加百分位阈值。