用同一个 prompt 打了 8 个模型，测了每个的 TTFB 和总响应时间。结论比你想象中差异更大——某些"便宜小模型"比旗舰快了 10 倍以上。

做 AI 应用的时候，选模型很少只看效果，延迟同样关键。实时对话、IDE 代码补全、语音交互这些场景，用户对响应速度极其敏感——首 token 超过 3 秒，体验就会明显下降。

这篇文章记录了我用 TheRouter API 对 8 个主流大模型做的延迟基准测试，包括完整的测试代码和数据分析。

测什么：TTFB vs 总响应时间

延迟测量有两个关键指标：

  • TTFB（Time to First Byte）：从发出请求到收到第一个 token 的时间。决定用户"感觉到响应"的速度。
  • Total Time：完整响应输出完成的时间。决定整体吞吐效率。

对于实时交互场景，TTFB 比 Total Time 更重要。用户看到第一个字出来，焦虑感就会大幅下降，哪怕后续输出慢一些。

测试环境

  • 请求来源：阿里云华东 2（上海）节点
  • API 入口：api.therouter.ai（TheRouter 统一网关）
  • Prompt：固定文本，约 50 tokens
  • max_tokens：200（控制输出长度一致）
  • 测试轮次：每个模型独立请求 5 次，取中位数
  • 请求模式：Streaming（流式），这样才能精确测 TTFB

用 TheRouter 的好处是所有模型走同一个 API 入口，排除了"各家 API 文档不同、SDK 差异"带来的测量误差。

测试代码

import time
import statistics
import httpx
import json

API_KEY = "your-therouter-api-key"
BASE_URL = "https://api.therouter.ai/v1"
PROMPT = "请用 100 字左右简单介绍一下快速排序算法的核心思路，用中文回答。"

MODELS = [
    "anthropic/claude-sonnet-4",
    "openai/gpt-4o",
    "openai/gpt-4o-mini",
    "google/gemini-2.5-pro",
    "google/gemini-2.5-flash",
    "deepseek/deepseek-v3",
    "deepseek/deepseek-r1",
    "qwen/qwen-max",
]

def measure_latency(model: str, runs: int = 5) -> dict:
    """测量模型 TTFB 和总响应时间，返回中位数"""
    ttfb_list = []
    total_list = []

    for _ in range(runs):
        headers = {
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        }
        payload = {
            "model": model,
            "messages": [{"role": "user", "content": PROMPT}],
            "max_tokens": 200,
            "stream": True,
        }

        start = time.perf_counter()
        first_token_time = None

        with httpx.stream(
            "POST",
            f"{BASE_URL}/chat/completions",
            headers=headers,
            json=payload,
            timeout=60.0,
        ) as response:
            response.raise_for_status()
            for line in response.iter_lines():
                if line.startswith("data: ") and line != "data: [DONE]":
                    try:
                        data = json.loads(line[6:])
                        delta = data["choices"][0]["delta"].get("content", "")
                        if delta and first_token_time is None:
                            # 收到第一个有内容的 token
                            first_token_time = time.perf_counter() - start
                    except (json.JSONDecodeError, KeyError):
                        pass

        total_time = time.perf_counter() - start

        if first_token_time:
            ttfb_list.append(first_token_time * 1000)  # 转毫秒
        total_list.append(total_time * 1000)

    return {
        "model": model,
        "ttfb_median_ms": round(statistics.median(ttfb_list), 0),
        "total_median_ms": round(statistics.median(total_list), 0),
    }

if __name__ == "__main__":
    print(f"{'模型':<35} {'TTFB (ms)':>10} {'总时间 (ms)':>12}")
    print("-" * 60)
    results = []
    for model in MODELS:
        result = measure_latency(model)
        results.append(result)
        print(f"{result['model']:<35} {result['ttfb_median_ms']:>10} {result['total_median_ms']:>12}")

    # 按 TTFB 排序
    results.sort(key=lambda x: x["ttfb_median_ms"])
    print("\n--- 按 TTFB 排序 ---")
    for r in results:
        print(f"{r['model']:<35} TTFB: {r['ttfb_median_ms']} ms")

代码使用 httpx 的流式 HTTP 客户端，在真正收到第一个有内容的 delta chunk 时打点，是目前最准确的 TTFB 测量方式。

测试结果

延迟数据表

模型 TTFB 中位数 总响应时间 定性评价
google/gemini-2.5-flash 380 ms 2,850 ms 极快
openai/gpt-4o-mini 510 ms 3,100 ms 极快
deepseek/deepseek-v3 620 ms 3,600 ms 快
qwen/qwen-max 780 ms 4,200 ms 快
openai/gpt-4o 1,050 ms 5,800 ms 中等
anthropic/claude-sonnet-4 1,280 ms 6,400 ms 中等
google/gemini-2.5-pro 2,100 ms 9,200 ms 慢
deepseek/deepseek-r1 3,400 ms 18,500 ms 很慢

数据为阿里云上海节点测量，不同网络环境会有差异。DeepSeek R1 的"很慢"主要因为它是推理模型，响应前有较长思考过程。

可视化（ASCII 图）

TTFB 对比（ms，越短越好）

gemini-2.5-flash  ████  380
gpt-4o-mini       █████ 510
deepseek-v3       ██████ 620
qwen-max          ████████ 780
gpt-4o            ██████████ 1050
claude-sonnet-4   █████████████ 1280
gemini-2.5-pro    ████████████████████ 2100
deepseek-r1       ████████████████████████████████ 3400

结果分析

1. Flash / Mini 系列就是为速度而生

gemini-2.5-flash 和 gpt-4o-mini 的 TTFB 都在 500ms 以内，比旗舰模型快 2-3 倍。这类模型牺牲了部分推理深度，换来了极低的响应延迟，实时交互场景的首选。

2. 推理模型（R1）延迟是另一个量级

deepseek-r1 的 TTFB 高达 3400ms，总响应时间接近 20 秒。这不是网络问题——推理模型在生成"可见内容"之前，会先完成内部 Chain-of-Thought 推理，这个过程不输出 token，导致 TTFB 极高。

结论：推理模型（o1、R1 系列）不适合实时交互，适合离线批量任务。

3. 国产模型延迟表现不错

deepseek-v3 和 qwen-max 的延迟都在合理范围内，考虑到它们的价格明显低于 GPT-4o，性价比突出。

4. 影响延迟的关键因素

因素 影响程度 说明
模型规模 高 参数量越大，首 token 生成越慢
推理模式 极高 思维链推理在 TTFB 前有额外延迟
节点距离 中 国内调用 OpenAI 比调用国内模型有约 200ms 额外延迟
Prompt 长度 低 输入 token 影响不大，输出 token 影响总时间
并发负载 中 模型服务繁忙时 TTFB 会上升

场景选型建议

实时对话 / 聊天机器人

优先选 TTFB < 800ms 的模型：

# 实时对话推荐
REALTIME_MODELS = [
    "google/gemini-2.5-flash",  # 最快
    "openai/gpt-4o-mini",       # 快且效果好
    "deepseek/deepseek-v3",     # 国产快速，价格低
]

IDE 代码补全

要求极低延迟（< 500ms TTFB），否则补全出来光标早跑了：

# IDE 补全场景
IDE_MODEL = "google/gemini-2.5-flash"  # 380ms TTFB，首选
FALLBACK = "openai/gpt-4o-mini"        # 备选

文档生成 / 长内容输出

延迟要求低，重视输出质量和长度：

# 文档生成，延迟不敏感
DOC_MODELS = [
    "anthropic/claude-sonnet-4",   # 长文档质量好
    "openai/gpt-4o",               # 均衡
    "google/gemini-2.5-pro",       # 上下文窗口极大
]

复杂推理 / 数学/代码调试

接受高延迟，换取更深推理：

# 深度推理，接受等待
REASONING_MODEL = "deepseek/deepseek-r1"   # 慢但推理深
ALTERNATIVE = "google/gemini-2.5-pro"       # 推理强，延迟可接受

用 TheRouter 做自适应路由

实际项目中可以根据场景动态选择模型，TheRouter 的好处是所有模型用同一套 API，切换没有成本：

from openai import OpenAI

client = OpenAI(
    base_url="https://api.therouter.ai/v1",
    api_key="your-therouter-api-key",
)

def smart_completion(prompt: str, mode: str = "balanced") -> str:
    """根据场景自动选择模型"""
    model_map = {
        "realtime": "google/gemini-2.5-flash",   # 极速
        "balanced": "openai/gpt-4o-mini",          # 均衡
        "quality": "anthropic/claude-sonnet-4",    # 高质量
        "reasoning": "deepseek/deepseek-r1",       # 深度推理
    }
    model = model_map.get(mode, "openai/gpt-4o-mini")

    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=512,
        stream=True,
    )

    result = ""
    for chunk in stream:
        if chunk.choices[0].delta.content:
            result += chunk.choices[0].delta.content
    return result

# 实时对话场景
reply = smart_completion("你好，今天天气怎么样？", mode="realtime")

# 代码审查场景，质量优先
review = smart_completion("请审查这段代码：...", mode="quality")

总结

场景 推荐模型 理由
实时对话 gemini-2.5-flash TTFB 最低，380ms
IDE 补全 gemini-2.5-flash / gpt-4o-mini 低延迟，够用
日常开发 gpt-4o-mini / deepseek-v3 速度和质量均衡
文档/长文 claude-sonnet-4 长上下文质量好
深度推理 deepseek-r1 慢但推理能力最强

一句话：延迟敏感就选 flash/mini，质量优先就选旗舰，需要推理就接受等待。

TheRouter 支持上述所有模型，同一个 API Key，一行代码切换。注册：therouter.ai

# microsoft
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

RAG 特效药：高效提高你的 RAG 准确率

avatar AtomGit开源社区
cover

基于 Harmony 6.0 应用的家庭相册共享应用首页实现

avatar AtomGit开源社区
cover

【Linux 基础教程（四）】文件内容查看、打包压缩与搜索、重定向管道及环境变量

avatar AtomGit开源社区