1. 为什么输入一长首 Token 就慢半拍先说结论TTFTTime to First Token首 Token 延迟指的是从你发出请求到模型吐出第一个字之间的时间。它跟你最终生成多少字关系不大但跟你喂进去多少 Token关系极大。很多人调 API 时只盯着总耗时其实真正影响体感的是 TTFT——用户按下回车后那零点几秒到几秒的等待全压在这一个指标上。大模型推理分两个阶段。第一个阶段叫 Prefill预填充模型要把你输入的整段 prompt 一次性并行算完生成 KV 缓存第二个阶段叫 Decode解码一个 Token 一个 Token 往外蹦。TTFT 基本等于 Prefill 耗时加上网络往返和排队时间。所以输入 Token 越长Prefill 的计算量和显存带宽压力越大TTFT 就越长。而输出 Token 数量严格来说不进入 TTFT 的计算它影响的是总时长和后续每个 Token 的间隔TPOT。但这里有个容易被忽略的点输出长度会通过服务端的调度策略间接影响 TTFT。比如动态批处理会把多个请求打包如果你的请求预期输出很长调度器可能给它分配不同的优先级或资源导致首 Token 的等待时间波动。另外像投机解码这类加速手段有时会牺牲首 Token 速度来换取整体吞吐。我实测下来输入从 200 Token 涨到 2000 TokenTTFT 可能翻两三倍而输出从 50 涨到 500TTFT 几乎不动但总耗时线性上升。这个差异决定了优化方向想降 TTFT先砍输入想降总时长再管输出。那怎么在自己的业务里量化这件事最靠谱的办法是设计一组对照实验固定其他变量只改输入长度或输出长度把 TTFT 采集下来对比。下面我就用 TaoToken 的统一 Key 和 API 通道带你从零搭一套可复制的压测脚本。选它是因为一个 Key 能切多个模型省去反复换配置的麻烦对照实验时变量更干净。2. TaoToken 前置准备Key、Base URL 与模型 ID在 TaoToken 上做实验你只需要三样东西API Key、Base URL、Model ID。这三件套是后面所有脚本的基础缺一个都跑不起来。先到官网注册并进入控制台。地址是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 登录后在控制台左侧找到 API Keys 页面点新建复制那串以 sk- 开头的 Key。注意它只完整显示一次建议先存到本地环境变量里别直接写死在代码里。Base URL 统一用 https://taotoken.net/api 这是 OpenAI 兼容协议的入口后面不管是 curl、Python SDK 还是各种客户端填的都是它。Model ID 在模型列表里查比如你想测某个通用对话模型就复制它对应的 ID 字符串大小写和连字符都要一致。把 Key 写进环境变量Linux/macOS 下这样操作export TAOTOKEN_API_KEYsk-你的实际Key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows PowerShell 用$env:TAOTOKEN_API_KEYsk-你的实际Key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用的是 Claude Code 这类工具配置方式略有不同。它需要 Base URL、Key、Model ID 三件套同时填对。以 Claude Code 的 settings 为例配置文件里要写清楚{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的实际Key, ANTHROPIC_MODEL: 你的ModelID } }这里有个坑Claude Code 走的是 Anthropic 协议Base URL 后面不要自己加 /v1 之类的后缀填 https://taotoken.net/api 就行路径由客户端自己拼。填错会直接报 404 或连接失败。如果你用 Cline 或带 MCP 的客户端配置逻辑一样核心还是那三件套。MCP 的配置文件通常是 JSON把 Base URL 和 Key 填进对应字段Model ID 选对即可。Codex 的 auth.json 也是同理把 Key 和 Base URL 写进去Model ID 在请求时指定。准备好这三样先别急着压测用一条最简单的请求验证通道是否通。这一步能帮你排除掉 90% 的低级错误。3. 可复制配置对照实验的请求参数与压测脚本实验设计的关键是控制变量。我们要做两组对照第一组固定输出长度只改输入长度第二组固定输入长度只改输出长度。每组至少跑 5 次取中位数避免单次抖动误导结论。先看单次请求的配置。用 curl 发一个流式请求重点观察第一个数据块到达的时间。流式模式下服务端一生成首 Token 就会推过来所以我们可以用时间戳差来近似 TTFT。curl -s -N https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: 你的ModelID, stream: true, max_tokens: 50, messages: [ {role: user, content: 请用一句话介绍你自己} ] }参数说明stream 必须为 true否则你拿到的是完整响应测不出首 Token 时间max_tokens 控制输出上限第一组实验里固定它messages 里的 content 就是我们要伸缩的输入。为了批量构造不同长度的输入写一个 Python 脚本。它用 requests 发流式请求记录请求发出到收到第一个 chunk 的时间差。import os import time import requests API_KEY os.environ[TAOTOKEN_API_KEY] BASE_URL os.environ[TAOTOKEN_BASE_URL] MODEL_ID 你的ModelID def measure_ttft(prompt, max_tokens50): url f{BASE_URL}/chat/completions headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } payload { model: MODEL_ID, stream: True, max_tokens: max_tokens, messages: [{role: user, content: prompt}] } start time.perf_counter() first_token_time None with requests.post(url, headersheaders, jsonpayload, streamTrue) as resp: resp.raise_for_status() for line in resp.iter_lines(): if line and line.startswith(bdata: ): chunk line[6:] if chunk b[DONE]: break if first_token_time is None: first_token_time time.perf_counter() break if first_token_time is None: return None return (first_token_time - start) * 1000 # 毫秒 def build_prompt(target_tokens): # 用重复短语近似构造指定长度的输入实际可用 tiktoken 精确计数 base 请仔细阅读以下背景信息并回答问题。 filler 这是一段用于填充上下文的测试文本目的是增加输入长度。 prompt base while len(prompt) target_tokens * 2: prompt filler return prompt if __name__ __main__: for tokens in [200, 500, 1000, 2000, 4000]: prompt build_prompt(tokens) samples [] for _ in range(5): ttft measure_ttft(prompt, max_tokens50) if ttft: samples.append(ttft) time.sleep(0.5) samples.sort() median samples[len(samples) // 2] print(f输入约 {tokens} Token, TTFT 中位数: {median:.1f} ms)这个脚本里 build_prompt 用字符数粗略估算 Token实际项目建议装 tiktoken 精确计数避免误差。跑完第一组你会得到一条输入长度与 TTFT 的对照曲线。第二组实验把输入固定成短 prompt改 max_tokens 从 50 到 500观察 TTFT 是否变化。理论上它应该基本持平如果波动很大说明服务端调度或网络在捣乱。如果你更习惯用配置文件管理可以把参数抽成 JSON{ model: 你的ModelID, stream: true, max_tokens: 50, temperature: 0.7, messages: [ {role: system, content: 你是一个简洁的助手}, {role: user, content: {{PROMPT}}} ] }把 {{PROMPT}} 替换成不同长度的文本就能复用同一套请求模板。注意 system prompt 如果很长且固定每次都会重复 Prefill这会显著抬高 TTFT后面排障章节会细说。4. 验证请求与成功结果TTFT 数据长什么样脚本跑起来后先确认单次请求能正常返回。用 curl 那条命令你应该看到类似这样的流式输出data: {choices:[{delta:{content:你}}]} data: {choices:[{delta:{content:好}}]} data: {choices:[{delta:{content:}}]} data: [DONE]每个 data 行是一个 chunk第一个 chunk 到达的时间就是我们要的 TTFT。如果半天没有输出或者直接返回一个 JSON 错误体说明配置有问题先别往下走。跑 Python 脚本第一组实验的典型输出可能是这样输入约 200 Token, TTFT 中位数: 320.5 ms 输入约 500 Token, TTFT 中位数: 410.2 ms 输入约 1000 Token, TTFT 中位数: 620.8 ms 输入约 2000 Token, TTFT 中位数: 980.4 ms 输入约 4000 Token, TTFT 中位数: 1750.6 ms可以看到输入翻倍TTFT 大致也接近翻倍但不是严格线性因为 Prefill 阶段有并行计算和显存带宽的混合影响。低长度区间增长慢高长度区间增长快这符合内存带宽逐渐成为瓶颈的规律。第二组固定输入、改输出的结果可能是max_tokens50, TTFT 中位数: 320.5 ms max_tokens200, TTFT 中位数: 325.1 ms max_tokens500, TTFT 中位数: 318.9 ms基本持平波动在测量误差范围内。这就验证了输出长度不直接进入 TTFT 的计算。如果你测出来输出长度对 TTFT 影响很大那多半是服务端在做动态批处理或者你的请求被排在了长任务后面。成功采集到数据后建议把结果存成 CSV方便画图对比import csv with open(ttft_result.csv, w, newline) as f: writer csv.writer(f) writer.writerow([input_tokens, ttft_ms]) for tokens, ttft in results: writer.writerow([tokens, ttft])有了这份数据你就能跟团队说清楚我们的 TTFT 瓶颈主要在输入侧优化 prompt 长度比换模型更立竿见影。5. 本篇常见错排查401、local proxy failed 与 reading choices实验过程中最容易撞上的几个报错我一个个拆。401 Unauthorized。这个几乎都是 Key 的问题。检查三件事环境变量有没有真正 export 成功用 echo $TAOTOKEN_API_KEY 看一眼Key 有没有多余空格或换行请求头里是不是写成了 Bearer 加空格加 Key。如果 Key 是从网页复制的注意别把前后的引号也带进去。还有一种情况是 Key 被禁用或额度耗尽去控制台确认状态。local proxy failed / connection refused。这个报错通常出现在客户端工具里比如 Claude Code 或 Cline。它意味着客户端尝试走本地代理但没连上。检查你的 Base URL 是不是填成了 https://taotoken.net/api 别自己加端口或路径。如果你本地开了某些网络工具先关掉再试避免请求被劫持到错误的地址。另外确认系统代理设置没有强制走一个不存在的本地端口。Error reading choices / 返回体里没有 choices 字段。这多半是请求体格式不对或者 Model ID 写错了。先看返回的完整 JSON如果里面有 error 字段按提示改。常见的是 model 字段拼写错误或者 messages 结构不对比如 role 写成了 user 之外的值。还有一种可能是 max_tokens 设得太大超过了模型上限服务端直接拒绝。把 max_tokens 调小再试。OAuth 相关报错。如果你用的是 Claude Code 这类带 OAuth 流程的工具报 OAuth 错误说明认证方式没配对。Claude Code 应该用 API Key 模式而不是走 OAuth 登录。检查 settings 里是不是同时配了 OAuth 和 API Key两者冲突时会报错。把 OAuth 相关字段删掉只保留 ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL 三件套。TTFT 数据异常大几秒甚至十几秒。先排除网络因素用 ping 或 curl 测一下到 https://taotoken.net/api 的往返延迟。如果网络正常那可能是输入里包含了超长 system prompt每次都在重复 Prefill。把 system prompt 精简或者确认服务端是否支持 prompt 缓存。另外检查是不是并发太高多个请求抢资源导致排队。流式请求收不到第一个 chunk。确认 stream 参数是 true并且客户端没有做缓冲。有些 HTTP 库默认会等整个响应结束才返回需要显式开启流式读取。Python requests 里用 iter_lines 配合 streamTrue 就能逐行拿。排查顺序建议先看 HTTP 状态码再看返回体里的 error 信息最后查配置三件套。大部分问题都出在 Key、Base URL、Model ID 这三样上。6. 把实验结论落到日常调用里跑完这套对照实验你手里应该有一份自己业务的 TTFT 基线数据。接下来怎么用第一把输入长度当成一等公民来管理。每次拼 prompt 前用 tiktoken 估一下 Token 数超过阈值就告警。尤其是 RAG 场景检索回来的文档别一股脑全塞进去先做相关性排序和截断。第二固定不变的 system prompt 考虑缓存。如果你的服务端支持 prompt caching把角色设定、few-shot 示例这些固定内容标记为可缓存能省下 30% 到 50% 的 Prefill 时间。具体怎么标记看模型文档通常是加一个 cache_control 字段。第三输出长度用来控总时长不用来控 TTFT。用户体感的首字等待靠输入优化整体回答快慢靠 max_tokens 和模型选择。两者分开治理别混为一谈。第四压测要常态化。模型服务端的负载、调度策略会变今天测的 TTFT 明天可能就不一样。把上面那个脚本挂到定时任务里每天跑一次数据存下来看趋势。一旦发现 TTFT 突然抬升先查是不是输入变长了再查服务端状态。如果你想把实验做得更细可以按模型维度分组同一个输入长度下对比不同 Model ID 的 TTFT选出性价比最高的那个。TaoToken 的统一通道在这里省事换模型只改一个字符串其他配置不动。最后提醒一句测 TTFT 一定要用流式模式非流式拿到的是总耗时会把 TTFT 和 Decode 时间混在一起结论就失真了。流式加时间戳才是靠谱的测量方式。
