LLM 的 Latency 與 Throughput：API 買家該如何衡量速度

在評估模型 API 時，理解 LLM 延遲（Latency）與吞吐量（Throughput）之間的權衡，對於優化使用者體驗與基礎設施成本至關重要。延遲衡量的是模型回應查詢所花費的時間，而吞吐量則衡量系統在特定時間窗口內處理或生成的 token 數量。對於開發者與 AI 產品構建者而言，優化其中一項指標通常需要對另一項指標做出妥協。

選擇錯誤的速度指標可能會導致使用者介面反應遲鈍，或是產生不必要的昂貴 API 帳單。本分析提供了一套衡量這些指標的框架，協助您針對特定工作負載選擇合適的 API，並實施優化策略。

重點摘要

• 首字延遲 (Time to First Token, TTFT) 是聊天介面等互動式應用程式的關鍵延遲指標，直接影響使用者對速度的感知。
• 每秒 Token 數 (Tokens Per Second, TPS) 是背景處理任務（如文件摘要或大量資料提取）的主要吞吐量指標。
• 模型架構與規模決定了基準效能，較小的模型（如 DeepSeek V4 Flash 或 Gemini 3.5 Flash）通常比旗艦模型（如 Claude Fable 5 或 GPT-5.5）提供更快的速度。
• 多供應商路由 (Multi-provider routing) 允許開發者根據供應商的即時效能，動態優化延遲或吞吐量。

---

定義核心指標：延遲 vs. 吞吐量

為了在購買或路由 API 時做出明智的決策，開發者必須將「速度」拆解為不同的、可衡量的組成部分。

LLM API 請求時間軸：
[使用者發送請求] 
       │
       ▼ (網路傳輸 + 提示詞處理)
[首字延遲 (TTFT)] <--- 對互動式 UX 至關重要
       │
       ▼ (自回歸生成：每秒 Token 數)
[Token 間延遲 (ITL)]  <--- 決定閱讀舒適度
       │
       ▼ (生成完成)
[總延遲]              <--- 對非串流阻塞式呼叫至關重要

1. 首字延遲 (Time to First Token, TTFT)

TTFT 是指從發送 API 請求到接收到回應的第一個 token 之間的時間間隔。此指標包含網路往返時間、提示詞序列化，以及模型處理輸入 token 所需的時間（預填充階段）。對於互動式應用程式而言，TTFT 是最重要的指標，因為它決定了使用者多快能看到回應開始串流顯示。

2. Token 間延遲 (Inter-Token Latency, ITL)

ITL 是指在串流階段生成連續 token 之間所經過的平均時間。如果 ITL 過高，文字串流的速度會慢於人類閱讀的速度，導致令人沮喪的使用者體驗。穩定且較低的 ITL 可確保文字渲染順暢。

3. 每秒 Token 數 (Tokens Per Second, TPS)

TPS 代表模型的生成吞吐量。其計算方式為輸出的 token 總數除以總生成時間（不含預填充階段）。在評估吞吐量時，開發者必須區分：

• 單使用者 TPS： 單一活躍串流的生成速度。
• 系統吞吐量： API 供應商在所有活躍使用者中同時處理的 token 總數。

4. 總延遲 (Total Latency)

總延遲是 API 請求從開始到結束的完整持續時間。對於非串流請求（如結構化 JSON 提取或背景分類），總延遲是需要監控的主要指標。

---

架構權衡：為何速度會有所不同

LLM 延遲與吞吐量之間的權衡根源於 Transformer 架構的物理特性與硬體記憶體頻寬。在預填充階段（決定 TTFT），計算具有高度可並行性，因為整個輸入提示詞會被一次性處理。此階段通常受限於計算能力。

在生成階段（決定 TPS），模型會逐個生成 token。每個新 token 都需要將所有模型權重從高頻寬記憶體 (HBM) 載入到 GPU SRAM。此自回歸過程受限於記憶體頻寬。

由於這些限制，開發者必須將模型選擇與其主要的效能需求保持一致：

• 旗艦模型： 如 Claude Fable 5、Claude Opus 4.8 和 GPT-5.5 等模型，優先考慮推理深度而非原始速度。它們具有龐大的參數數量，導致較高的 TTFT 和較低的 TPS。
• 快速、低成本模型： 如 DeepSeek V4 Flash、Gemini 3.5 Flash 和 Laguna XS 2.1 等模型，針對速度進行了優化。它們使用較少的參數數量、投機解碼 (speculative decoding) 或蒸餾架構，以提供極低的 TTFT 和高 TPS。

開發者可以參考 TokenLab LLM API 開發者排行榜 來比較這些模型層級的即時速度指標。

---

決策框架：何時優先考慮延遲 vs. 吞吐量

延遲與吞吐量之間的優先順序完全取決於應用程式的使用場景。

使用場景	主要指標	次要指標	建議模型類別
互動式聊天機器人	首字延遲 (TTFT)	Token 間延遲 (ITL)	快速前沿模型 (如 Gemini 3.5 Flash)
程式碼助手	TTFT 與單串流 TPS	總延遲	專業程式碼模型 (如 Claude Sonnet 5, Kimi K2.7 Code)
大量資料提取	系統吞吐量	單次任務成本	低成本開放權重模型 (如 DeepSeek V4 Flash, GLM-5.2)
自主代理 (Agents)	總延遲 (非串流)	TTFT	高推理能力開放權重模型 (如 DeepSeek V4 Pro)
圖像/影片生成	總延遲	單張圖像成本	專業媒體 API (如 Nano Banana 2, Seedance)

互動式應用程式（延遲優先）

對於對話式 UI、客戶支援機器人和即時搜尋助手，如果系統反應遲鈍，使用者留存率就會下降。開發者應優先最小化 TTFT。即使總生成時間需要幾秒鐘，只要 TTFT 低於 300 毫秒，就能讓使用者保持參與感。

批次處理與管道（吞吐量優先）

對於離線任務（如處理數千份 PDF 發票、生成每日報告或執行批次評估），TTFT 無關緊要。目標是以最低成本最大化每分鐘處理的 token 總量。開發者應專注於系統吞吐量與成本效益。如需深入分析批次處理期間的成本優化，請參閱 TokenLab AI 模型路由基準測試：單次任務成本。

---

衡量 API 效能：實作程式碼範例

為了準確衡量 TTFT、ITL 和 TPS，開發者必須使用串流 API，並在請求生命週期的特定點記錄時間戳記。以下是一個可執行的 Python 指令碼，使用 OpenAI 相容客戶端來衡量給定模型的這些指標。

import time
import os
from openai import OpenAI

# 初始化客戶端 (配置為 OpenRouter 或任何相容供應商)
client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ.get("OPENROUTER_API_KEY", "your_api_key_here")
)

def measure_api_performance(model_name: str, prompt: str):
    print(f"正在評估速度指標：{model_name}")
    
    start_time = time.time()
    response = client.chat.completions.create(
        model=model_name,
        messages=[{"role": "user", "content": prompt}],
        stream=True
    )
    
    ttft = None
    token_timestamps = []
    total_tokens = 0
    
    for chunk in response:
        chunk_time = time.time()
        # 檢查 chunk 中是否存在文字內容
        if chunk.choices and chunk.choices[0].delta.content:
            content = chunk.choices[0].delta.content
            # 估算 token 數量 (粗略測量：1 token ≈ 4 個字元)
            estimated_tokens = max(1, len(content) // 4)
            total_tokens += estimated_tokens
            
            if ttft is None:
                ttft = chunk_time - start_time
                print(f"-> 首字延遲 (TTFT): {ttft:.3f} 秒")
            
            token_timestamps.append(chunk_time)
            
    end_time = time.time()
    total_duration = end_time - start_time
    generation_time = total_duration - ttft if ttft else total_duration
    
    # 計算 Token 間延遲 (ITL) 與每秒 Token 數 (TPS)
    if len(token_timestamps) > 1:
        intervals = [token_timestamps[i] - token_timestamps[i-1] for i in range(1, len(token_timestamps))]
        avg_itl = sum(intervals) / len(intervals)
        tps = total_tokens / generation_time if generation_time > 0 else 0
    else:
        avg_itl = 0
        tps = 0
        
    print(f"-> 總延遲: {total_duration:.3f} 秒")
    print(f"-> 平均 Token 間延遲 (ITL): {avg_itl:.3f} 秒")
    print(f"-> 預估吞吐量 (TPS): {tps:.2f} tokens/sec")
    print("-" * 50)

# 使用快速、低成本模型的範例
if __name__ == "__main__":
    test_prompt = "寫一篇關於計算歷史的 200 字短文。"
    # 使用當前的低成本路由模型範例
    measure_api_performance("google/gemini-3.5-flash", test_prompt)

---

API 買家的優化策略

如果您的測量結果顯示所選的 API 太慢或太昂貴，以下幾種優化策略可以改善效能。

1. 提示詞優化與預填充減少

由於預填充階段會隨著輸入提示詞的大小而擴展，減少提示詞長度可直接降低 TTFT。

• 移除冗餘指令。
• 如果供應商支援，請使用系統提示詞快取 (System prompt caching)。這允許 API 主機快取長系統提示詞的編譯狀態，從而跳過後續請求中的預填充計算。

2. 動態供應商路由

根據 OpenRouter 供應商選擇文件，模型的效能可能會因底層主機（供應商）的不同而有顯著差異。有些供應商針對低延遲進行了優化，而有些則以犧牲速度為代價提供更低的成本。

透過利用路由層，開發者可以：

• 查詢多個供應商以找到當前最低延遲。
• 設定備援路徑，以便在主要供應商發生延遲飆升時，請求自動路由至更快的替代方案。
• 根據特定的效能閾值篩選供應商。

3. 模型分層 (Model Tiering)

請勿將 Claude Fable 5 或 GPT-5.5 等旗艦模型用於可由較小模型處理的任務。實作一個路由分配器，將簡單查詢（如分類、格式化）發送給 DeepSeek V4 Flash 或 GLM-5.2，僅將昂貴的模型保留給複雜的推理步驟。

---

速度基準測試的限制

在評估速度指標時，開發者應注意以下限制：

• 網路變異： API 延遲高度依賴於您的應用程式伺服器與 API 供應商託管區域之間的物理距離。請務必從與生產環境部署區域相同的伺服器進行基準測試。
• 供應商擁塞： 吞吐量與延遲會根據全球流量模式在全天內波動。單次的基準測試結果無法代表一致的生產效能。
• Token 估算差異： 不同模型使用不同的分詞器 (tokenizer)。如果某個模型的 TPS 較高，但其分詞器將單字拆分為更小、更多的 token，那麼它實際上可能並不比競爭模型更快。

---

常見問題解答

更高的吞吐量 (TPS) 是否總是意味著更快的體驗？

不一定。如果 API 具有高吞吐量但 TTFT 表現不佳，使用者在文字突然出現在螢幕上之前，會經歷一段漫長且無回應的停頓。對於互動式應用程式，低 TTFT 比高 TPS 更為關鍵。

提示詞快取如何影響延遲？

提示詞快取可顯著降低長提示詞的 TTFT。透過快取系統指令或上下文文件的已處理 token，供應商在後續請求中可跳過計算密集的預填充階段，從而實現更快的回應時間。

為了獲得最佳速度，我應該選擇開放權重還是封閉原始碼模型？

這取決於託管基礎設施。像 Qwen3.7 Plus、GLM-5.2 或 DeepSeek V4 Pro 這樣的開放權重模型可以部署在專用的私有硬體上，讓您保證吞吐量。然而，託管的封閉原始碼 API 通常使用大規模、經過優化的基礎設施，這在私有實例上很難以具成本效益的方式複製。您可以在 TokenLab 模型排名上比較當前的效能排名。

---

後續步驟

為了優化應用程式的速度與成本效益，請先使用上述的串流指標衡量您當前的生產工作負載。

準備好為您的生產管道評估並比較最新的模型了嗎？立即開始使用 TokenLab 的綜合模型排名，為您的應用程式找到延遲、吞吐量與成本的最佳平衡點。