LLM 延迟与吞吐量：API 买家应如何衡量速度

在评估模型 API 时，理解 LLM 延迟与吞吐量之间的权衡对于优化用户体验和基础设施成本至关重要。延迟衡量的是模型响应查询所花费的时间，而吞吐量则衡量系统在特定时间窗口内处理或生成的 token 数量。对于开发者和 AI 产品构建者而言，优化其中一个指标往往需要对另一个指标做出权衡。

选择错误的性能指标可能会导致用户界面响应迟缓或产生不必要的 API 高额账单。本分析提供了一个衡量这些指标、为特定工作负载选择合适 API 以及实施优化策略的框架。

关键要点

• 首字延迟 (TTFT) 是聊天界面等交互式应用的关键延迟指标，直接影响用户感知的速度。
• 每秒 Token 数 (TPS)（按流计算）是文档摘要或批量数据提取等后台处理任务的主要吞吐量指标。
• 模型架构和规模决定了基准性能，DeepSeek V4 Flash 或 Gemini 3.5 Flash 等小型模型比 Claude Fable 5 或 GPT-5.5 等旗舰模型提供更快的速度。
• 多提供商路由允许开发者根据提供商的实时性能动态优化延迟或吞吐量。

---

定义核心指标：延迟与吞吐量

为了在购买或路由 API 时做出明智的决策，开发者必须将“速度”分解为不同的、可衡量的组成部分。

LLM API 请求的时间轴：
[用户发送请求] 
       │
       ▼ (网络传输 + 提示词处理)
[首字延迟 (TTFT)] <--- 对交互式 UX 至关重要
       │
       ▼ (自回归生成：每秒 Token 数)
[Token 间延迟 (ITL)]  <--- 决定阅读舒适度
       │
       ▼ (生成完成)
[总延迟]              <--- 对非流式阻塞调用至关重要

1. 首字延迟 (TTFT)

TTFT 是指从发送 API 请求到收到响应的第一个 token 之间的时间间隔。该指标包括网络往返时间、提示词序列化以及模型处理输入 token 所需的时间（预填充阶段）。对于交互式应用，TTFT 是最重要的指标，因为它决定了用户看到响应开始流式传输的速度。

2. Token 间延迟 (ITL)

ITL 是指在流式传输阶段生成连续 token 之间经过的平均时间。如果 ITL 过高，文本流动的速度会慢于人类阅读的速度，从而导致令人沮丧的用户体验。稳定且较低的 ITL 可确保文本渲染流畅。

3. 每秒 Token 数 (TPS)

TPS 代表模型的生成吞吐量。它的计算方式是输出 token 总数除以总生成时间（不包括预填充阶段）。在评估吞吐量时，开发者必须区分：

• 单用户 TPS： 单个活动流的生成速度。
• 系统吞吐量： API 提供商在所有活跃用户中并发处理的 token 总数。

4. 总延迟

总延迟是 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 等模型针对速度进行了优化。它们使用较小的参数量、推测解码或蒸馏架构，以提供极低的 TTFT 和高 TPS。

开发者可以参考 TokenLab LLM API 开发者排行榜来比较这些模型层级之间的实时速度指标。

---

决策框架：何时优先考虑延迟与吞吐量

延迟和吞吐量之间的优先级完全取决于应用场景。

使用场景	主要指标	次要指标	推荐模型类别
交互式聊天机器人	首字延迟 (TTFT)	Token 间延迟 (ITL)	快速前沿模型 (如 Gemini 3.5 Flash)
编程助手	TTFT & 单流 TPS	总延迟	专业编程模型 (如 Claude Sonnet 5, Kimi K2.7 Code)
批量数据提取	系统吞吐量	单任务成本	低成本开放权重模型 (如 DeepSeek V4 Flash, GLM-5.2)
自主智能体	总延迟 (非流式)	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。

• 删除冗余指令。
• 如果提供商支持，请使用系统提示词缓存。这允许 API 主机缓存长系统提示词的编译状态，从而在后续请求中跳过预填充计算。

2. 动态提供商路由

根据 OpenRouter 提供商选择文档，模型的性能可能会因提供请求的底层主机（提供商）而有很大差异。一些提供商针对低延迟进行了优化，而另一些则以牺牲速度为代价提供更低的成本。

通过利用路由层，开发者可以：

• 查询多个提供商以找到当前的最低延迟。
• 设置回退路径，以便在主提供商出现延迟峰值时，请求自动路由到更快的替代方案。
• 根据特定的性能阈值过滤提供商。

3. 模型分层

不要将 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 的综合模型排名，为您的应用找到延迟、吞吐量和成本的最佳平衡点。