如何跨延遲、吞吐量與正常執行時間評估大模型服務商效能

開發者通常會先挑選像 Claude、Llama、Gemini 或 DeepSeek 等模型來開始 LLM 選擇，之後再把供應商視為次要決策。這很合理。但單靠模型選擇並不能告訴你模型在特定供應商端點的表現。

同一個模型可以透過多個供應商端點執行，每個端點都可能帶來不同的基礎設施、路由行為、量化選擇以及失敗模式。使用者和系統會實際感受到這些差異。某個供應商可能會快速回傳第一個 token，但在其餘回應時速度放慢；另一個可能提供較低精度的變體，在較難的提示下表現漂移；再者，某個供應商在正常流量下表現良好，但在負載下失效。

供應商評估比較的是服務環境，而不是把模型視為獨立產品。它會詢問使用者等待第一個 token 的時間、其餘回應到達的速度、供應商在負載下的表現，以及模型執行時的精度等級。

本指南依照可執行的順序逐一處理這些問題：延遲、吞吐量、正常執行時間與量化。當你能量化這些權衡後，下一步就是將結果轉換為路由邏輯，避免應用程式僅根據單次基準測試中最快的供應商硬編碼。

簡而言之

• 同一模型在不同供應商端點的表現會不同。基礎設施、量化、負載處理與路由預設都會改變結果，即使模型標籤相同。
• 四項指標決定供應商表現：延遲（到達第一個 token 的時間）、吞吐量（每秒輸出 token 數）、正常執行時間與量化。
• 閱讀延遲時以 p90 / p99 為主，而非平均值。尾部延遲才是使用者介面實際感受到的；批次工作可以 p50 進行評估。
• 量化是隱藏的品質變數。兩個供應商可能以不同精度提供同一模型；在品質重要時，請用 quantizations 欄位固定。
• 先使用排行榜篩選，再用自己的提示進行驗證。基準測試只測量某一時刻的一個端點；你的工作負載並非基準測試的工作負載。
• 將評估轉換為路由策略。設定 provider.sort、百分位門檻、quantizations 以及回退機制，讓供應商選擇依賴你的測量，而非硬編碼名稱。

評估供應商表現的四項指標

聊天產品、檔案生成管線以及背景摘要工作不需要相同的效能配置。合適的供應商取決於工作負載。

一個供應商在回應開始時看起來很快，但到完整答案結束時仍可能感覺緩慢。首個 token 的時間（TTFT）捕捉了經驗的第一部分。輸出速度則捕捉第二部分，因為它測量的是生成開始後每秒產生的 token 數量。即使 TTFT 強的供應商，如果持續 token 速率下降，仍可能產生弱的長篇體驗；而即使吞吐量強的供商，如果第一個 token 遲到，聊天介面仍可能感覺不佳。

正常運作時間（Uptime）補足了速度指標無法涵蓋的生產層面。即使在基準條件下表現良好的供應商，如果在高峰使用時失效、意外限速，或產生錯誤尖峰迫使重試，仍可能對應用造成損害。

將這些測量分離後，下一步是以適當的置信水平閱讀它們。中位延遲能描述典型請求，但生產系統還需要知道有多少請求比典型請求耗時更久。此時百分位指標（如 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 欄位限制您的應用程式可使用的供應商端點：

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

您也可以排除供應商，如果評估顯示其端點對您的提示表現不佳：

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

模型名稱啟動評估，但供應商端點完成評估。量化是公共基準與實際行為可能分歧的原因之一。

如何閱讀供應商基準而不被誤導

一個 公開排行榜 可以幫助您縮小候選集合，但無法描述您的生產路徑。基準測試在特定時間測量選定的端點，使用自己的提示、引數、區域和評分方法。您的應用程式可能使用不同的端點、提示形狀或路由路徑，而非基準測試所測量的。

有用的供應商基準審查應先檢查基準發布的方法論，再將結果視為生產證據：

當基準結果能夠導向在您自己的工作負載下進行第二輪測試時，它才變得有用。如果排行榜指出某個供應商速度快，下一個問題是該端點在您的提示長度、路由路徑和品質要求下是否仍保持快速。如果是，將該結果轉換為路由規則。

將單一供應商硬編碼於靜態排名會造成脆弱的設定。供應商行為會因流量、停機、路由路徑與服務設定而變化。這正是我們路由層設計要處理的。

為何多供應商路由會改變供應商評估

僅評估單一供應商只會告訴您該供應商在測量條件下的表現。它不會告訴您當供應商達到速率限制、在負載下變慢或暫時無法使用時會發生什麼。若您的應用程式依賴單一供應商端點，所有供應商端失敗都會成為應用程式行為的一部分。

路由層將評估從一次性供應商選擇轉變為持續的選擇問題。您不再將每一次供應商停機、速率限制或減速視為應用程式失敗，而是可以自動繞過這些條件。

我們即時監控各供應商的回應時間、錯誤率與可用性，我們的預設路由會降低最近 30 秒內發生重大停機的供應商優先權，並在穩定且價格較低的供應商之間進行負載平衡，將其餘供應商保留作為備援。

多供應商路由並不能保證完美的正常運作時間。它透過在供應商失效或無法使用時提供備用路徑，降低對單一端點的依賴。

模型備援在供應商層級路由不足時，亦採用相同原則。若主要模型因供應商停機、速率限制或無法回答而無法完成請求，OpenRouter 可嘗試備援列表中的下一個模型。

實用的路由策略應回答三個問題：

將供應商評估轉換為路由政策

路由控制主要位於 provider 物件內。它們讓您對供應商進行排序、偏好效能閾值、選擇或避免供應商端點、按量化過濾，並決定備援是否可執行。模型備援使用 models 陣列。

最簡單的控制方式是 model suffixes。當請求應優先選擇吞吐量較高的供應商時，請加入 :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 個 token/秒且最便宜的模型與供應商端點。低於該門檻的端點不會從路徑中消失；它們會被移到首選選項後面，若所有首選端點失效，仍可使用。

聊天工作流程可使用相同模式結合延遲。若首個 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,
});

若完成可靠性比維持單一模型更重要，請使用 fallback list：

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. 先以外部基準與即時供應商資料篩選候選。使用 public leaderboards 確定候選者，然後在我們目錄中的 model’s page 檢視最新供應商資料。

3. 使用您自己的提示測試。執行代表產品實際工作負載的提示。包含短提示、長提示、易提示，以及通常會讓弱供應商失效的提示。同時測量速度、可靠性與輸出品質。

4. 檢查量化與供應商行為。若兩個供應商提供相同模型，但其中一個在困難提示上表現較差，先檢查服務路徑再責怪模型。若評估支援，則鎖定更高精度或排除較弱端點。

5. 透過路由強制執行結果。將評估轉換為 request settings。使用 sort、:nitro、:floor、preferred_min_throughput、preferred_max_latency、quantizations、ignore 以及回退，以保持應用程式與測量值同步。這樣供應商的選擇就與您的應用程式相關，而非一般市場排名，且隨著供應商行為隨時間改變，能重複進行效能評估。

常見問題

LLM 供應商的延遲與吞吐量有何差異？

延遲衡量使用者等待第一個 token 到達的時間。吞吐量衡量提供者在生成開始後每秒產生的輸出 token 數量。聊天介面通常優先考慮延遲，而長輸出工作流程則優先考慮吞吐量。

p50、p90 和 p99 在 LLM 延遲中代表什麼？

p50 為中位數請求體驗。p90 表示 90% 的請求在該延遲值或以下完成。p99 顯示分佈的遠端尾部，當你的應用程式必須對幾乎所有使用者都能可預測地回應時就需要它。

為什麼相同的模型在不同供應商之間會有差異？

供應商端點可能改變服務環境。量化、基礎設施、上下文支援、負載以及供應商預設值都可能影響輸出行為。模型 slug 標識模型族群，但供應商路徑會影響最終產出。

如何避免使用表現不佳的供應商？

確認問題隨供應商變化後，先用自己的 prompt 測試。若問題可重現，使用 provider.ignore 排除該供應商。若問題似乎與較低精度相關，使用 provider.quantizations 以偏好較高精度端點。

多供應商路由能提升正常運作時間嗎？

多供應商路由可透過在供應商失效、速率限制或宕機時加入備援路徑來提升可靠性。它降低了單一供應商的依賴，但仍取決於路由政策的品質與可用供應商。

不。請求的價格是以最終提供完成的模型與供應商端點計算。OpenRouter 不會對供應商定價做標記，失敗的請求不會被計費，無論你路由到一個供應商還是十個。

我應該如何路由到最快的供應商？

若你關心首個 token 的時間，使用 provider.sort: "latency"。若你關心長篇生成速度，使用 provider.sort: "throughput" 或 :nitro 字尾。若你需要可預測的表現而非單純速度偏好，請加入百分位數閾值。