tokens/s 实测：N tokens/s 到底意味着什么用户体验

💡 一句话总结：tokens/s 是一个被严重过度简化的指标。真正决定 UX 的是 TTFT + TPS + 抖动三个因素的组合——理解它们，你才能正确选择模型。

问题：tokens/s 这个指标为什么会骗人

随手翻一下任意 LLM 厂商的发布博客，几乎都会贴一张 tokens/s 对比图。但这个数字几乎从不被正确使用。看几个典型骗局：

骗局 1：峰值 vs 平均

厂商报的 tokens/s 通常是”峰值”——在某个特定 prompt 长度、特定输出长度、零负载条件下的最大吞吐。真实用户在高负载、长输入下的体验可能是这个数字的 30%-50%。

骗局 2：tokenizer 差异

中文场景特别明显。同一句话 “我今天吃了一碗牛肉面”：

• GPT-5 tokenizer：14 tokens
• Claude Sonnet 4.6 tokenizer：10 tokens
• Qwen3 tokenizer：7 tokens
• DeepSeek V4 tokenizer：8 tokens

同样 100 tokens/s，Qwen 实际生成的汉字数量是 GPT 的 2 倍。比 tokens/s 更公平的指标是 chars/s 或 words/s。

骗局 3：不报 TTFT

短回复场景下，TTFT（首字节时间）才是用户感知的主要来源。一个 TTFT 1.2 秒、TPS 200 的模型，对短回复体验比 TTFT 0.4 秒、TPS 80 的模型差得多。

骗局 4：忽略抖动

某些 API 的 tokens 输出极不稳定——平均 80 tokens/s，但中间会有 500ms 的卡顿。用户感知不是平均值，而是最长的等待间隔。

4 个真正重要的指标

Python 实测脚本

下面是我用的测试脚本，支持 OpenAI / Anthropic / 通义千问 / DeepSeek 等主流 API（基本都用 SSE 流式协议）：

import time
import json
import statistics
import httpx
from dataclasses import dataclass

@dataclass
class StreamMetrics:
    ttft: float            # 首字节时间（秒）
    tps: float             # 流式阶段 tokens/s
    chars_per_s: float     # 字符/s（公平比较中文）
    e2e: float             # 端到端总耗时
    jitter_max: float      # 最大 token 间隔
    total_tokens: int
    total_chars: int

def benchmark_openai_compatible(
    api_url: str,
    api_key: str,
    model: str,
    prompt: str,
) -> StreamMetrics:
    payload = {
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
        "stream": True,
        "max_tokens": 800,
    }
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json",
    }
    
    t_start = time.perf_counter()
    t_first = None
    token_times = []
    total_chars = 0
    total_tokens = 0
    
    with httpx.stream("POST", api_url, json=payload, headers=headers, timeout=120) as r:
        for line in r.iter_lines():
            if not line or not line.startswith("data:"):
                continue
            data_str = line[5:].strip()
            if data_str == "[DONE]":
                break
            try:
                chunk = json.loads(data_str)
            except json.JSONDecodeError:
                continue
            
            delta = chunk["choices"][0].get("delta", {}).get("content", "")
            if not delta:
                continue
            
            now = time.perf_counter()
            if t_first is None:
                t_first = now
            
            token_times.append(now)
            total_chars += len(delta)
            total_tokens += 1   # 简化为 chunk 计数；精确测量需要 tokenizer
    
    t_end = time.perf_counter()
    e2e = t_end - t_start
    ttft = (t_first - t_start) if t_first else e2e
    
    # 计算 token 间隔的最大值
    intervals = [t2 - t1 for t1, t2 in zip(token_times, token_times[1:])]
    jitter_max = max(intervals) if intervals else 0
    
    stream_duration = (t_end - t_first) if t_first else 0
    tps = total_tokens / stream_duration if stream_duration > 0 else 0
    chars_per_s = total_chars / stream_duration if stream_duration > 0 else 0
    
    return StreamMetrics(
        ttft=ttft, tps=tps, chars_per_s=chars_per_s,
        e2e=e2e, jitter_max=jitter_max,
        total_tokens=total_tokens, total_chars=total_chars,
    )


def run_benchmark(provider_config, prompts, n_runs=20):
    results = []
    for prompt in prompts:
        for _ in range(n_runs):
            m = benchmark_openai_compatible(
                provider_config["url"],
                provider_config["key"],
                provider_config["model"],
                prompt,
            )
            results.append(m)
            time.sleep(0.5)
    
    return {
        "ttft_p50": statistics.median(r.ttft for r in results),
        "ttft_p95": statistics.quantiles([r.ttft for r in results], n=20)[18],
        "tps_p50": statistics.median(r.tps for r in results),
        "tps_p95": statistics.quantiles([r.tps for r in results], n=20)[18],
        "chars_per_s_p50": statistics.median(r.chars_per_s for r in results),
        "jitter_max_p95": statistics.quantiles([r.jitter_max for r in results], n=20)[18],
    }

测试 prompt 集合用了三类（每类 5 个）：

• 短回复（<100 tokens）：技术问题、定义、单步推理
• 中等回复（300-500 tokens）：解释复杂概念、写函数
• 长回复（>1000 tokens）：写代码 + 文档、长篇分析

每个 prompt 跑 20 次（错峰跑 4 个不同时段），共 300 次/模型。

8 家 API 的真实数据

测试时间：2026-05-19 至 2026-05-20（48 小时内）。地理位置：美西 + 国内分别测。

表 1：TTFT 对比（中位数 / P95，单位毫秒）

表 2：流式 TPS 对比（中位数 / P95）

注意 chars/s 这一列——Qwen 输出 96 tokens/s 实际生成 137 个汉字/秒，比 GPT-5 的 84 tokens/s（56 字/秒）流畅得多。

表 3：E2E 时延对比（典型 500 tokens 回复）

表 4：Jitter 对比（P95 最大 token 间隔，毫秒）

DeepSeek 的抖动最大，常常出现 300+ ms 的卡顿——这种卡顿对流式 UX 体验影响很大。

人类感知阈值实测

我做了一个用户体验调研（N=42，混合了开发者和非开发者）。每个被试看 20 段不同速度的流式输出，对体验打分（1-10）：

关键发现：用户感知 不是线性的。

• 从 30 涨到 60 评分提升 1.5 分
• 从 100 涨到 200 评分只提升 0.2 分
• 超过 150 之后基本是边际效应

这意味着工程上没必要把 TPS 卷到 1000+。对于阅读密集型场景，80-100 tokens/s 已经是 “用户体验等价于无限快” 的阈值。

UX 设计建议

基于以上数据，可以给出几条产品级 UX 设计建议：

1. 优化 TTFT 优先

短回复场景下，TTFT 占用户感知 70% 以上。优先级：

• 关闭 thinking 模式（如果不必需）：TTFT 能降低 50%-80%
• 用更短的 system prompt
• 启用 prompt caching：再次访问时 TTFT 能降低 90%
• 边缘部署（CDN 之于 API）：地理距离每减少 5000 km，TTFT 降低 80-150 ms

2. 长回复用流式 + 渐进 UI

长回复场景下，TPS 关键。设计：

• 强制流式输出（不要等到全部生成再展示）
• 用打字机效果（visual stream）匹配用户阅读速度
• 实测：用户阅读速度约 50-80 chars/s（200-400 字/分钟），如果 TPS 显著高于此，用户会感觉”输出比阅读快”——这是好事，但可以用动画节流

3. 抖动比平均速度更重要

实验显示，用户对抖动比对平均速度更敏感。Anthropic 之所以体验好，不只是 TPS 高，而是 jitter P95 只有 84ms。建议：

• 监控 token 间隔分布而不仅是平均 TPS
• 把抖动 P95 控制在 200ms 以内
• 如果某个 chunk 等了 >500ms，前端可以显示”思考中…”提示安抚用户

4. 渲染开销不要被忽略

很多人忽略：客户端 Markdown 渲染、代码高亮、数学公式都会占用主线程时间。实测在低端手机上，渲染开销能吃掉 30% 的感知速度。建议：

• 用 requestAnimationFrame 批量渲染
• 大段代码块延迟到段落完成再高亮
• 数学公式（KaTeX）只在完整段落出现后渲染

5. 不要展示 tokens/s 给用户

最后一条反直觉的建议：不要把 tokens/s 显示给用户。

很多产品把这个数字摆在 UI 上炫耀。但用户根本不知道这个数字意味着什么——展示出来反而让用户产生”比较心态”，看到 50 tokens/s 会觉得慢，看到 200 tokens/s 觉得快。

更好的做法：展示流式输出本身就够了。用户的感知决定一切，数字是工程指标，不是 UX 指标。

结论

tokens/s 是一个被滥用的指标。真正决定用户体验的是 TTFT + TPS + 抖动 + 客户端渲染 的组合：

• TTFT 决定”开始的速度”，是短回复的核心
• TPS 决定”持续的速度”，是长回复的核心
• 抖动决定”流畅感”，比平均速度更影响感知
• 客户端渲染是被低估的隐形开销

工程上的优化优先级也很清楚：先优化 TTFT（用 cache），再控制 jitter（避免长 chunk），最后才是 TPS（80-100 已经够用）。不要被厂商发布会上的 tokens/s 数字误导，自己跑测试脚本测真实场景才靠谱。

测试脚本完整代码 + 8 家 API 的原始数据在我的 GitHub（链接见博客 footer）。HN 原帖讨论：mikeveerman.github.io/tokenspeed（273 赞，深度讨论了感知阈值）。