1. 从一次线上告警说起TTFT 突然翻倍问题却不在模型先说个真实场景。某天下午一个做 AI 客服的朋友发消息说他们产品的首字延迟从 0.6 秒涨到了 2.3 秒用户投诉发完消息半天不出字。他第一反应是模型服务挂了去查供应商状态页——一切正常。又怀疑是自己网络抖动ping 了一圈也没问题。最后把请求日志拉出来逐条看才发现是并发数从平时的 30 涨到了 90接近了账号的并发上限请求开始排队。这个案例里他一开始盯错了指标。首字延迟TTFT变差可能是模型慢、可能是网络慢、也可能是排队慢三者表现一样但根因完全不同。要定位这类问题你得先把大模型 API 的几个核心性能指标分清楚TTFT、TPOT、并发、TPM。这四个指标分别管多久出第一个字出字快不快同时能跑多少一分钟能搬多少 token任何一个出问题用户体验都会崩但排查方向完全不一样。这篇内容面向需要做大模型 API 选型、压测、SLA 评估的后端和平台工程师。我会用 TaoToken 的统一 Key 和 API 通道搭一套可复现的压测场景交付能直接跑的并发脚本和指标采集配置帮你建立自己的性能基线。TaoToken 在这里的角色是统一入口——一个 Key 打通多个模型压测时不用来回换配置指标口径也一致。你可以先注册账号拿到 Key后面所有脚本都基于它来跑。需要说明的是压测本身不复杂复杂的是测什么、怎么算、结果怎么解读。很多人跑完压测只看到一个平均延迟这远远不够。SLA 看的是 P90/P99容量规划看的是并发和 TPM 的交叉点体验优化看的是 TTFT 和 TPOT 的拆分。下面我会把这几个维度都覆盖到。2. TaoToken 前置准备统一 Key 与 API 通道配置在开始压测之前先把通道配好。TaoToken 提供统一的 API 入口Base URL 是https://taotoken.net/api你只需要一个 Key 就能调用多个模型。这样做压测的好处是切换模型只改一个 model 字段其他配置不动指标对比更干净。2.1 获取 API Key 与确认模型 ID登录 TaoToken 控制台在 API Keys 页面创建一个新 Key。建议压测单独用一个 Key避免和线上业务混在一起方便观察限流和用量。创建后复制保存后面脚本里会用到。模型 ID 需要和你实际要测的模型对应。TaoToken 的模型列表在文档里有常见的有gpt-4o、claude-3-5-sonnet、deepseek-chat等。压测时建议固定一个模型先把基线跑出来再换模型做横向对比。2.2 环境变量与依赖安装我习惯把 Key 放在环境变量里不写死在脚本中。Linux/macOS 下export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiPython 依赖只需要openai和httpx压测脚本用asyncio做并发pip install openai httpx如果你用 Node.js装openai包即可后面我也会给一个 Node 版本的采集片段。2.3 配置文件settings.json 与 auth.json 对照有些工具链比如 Claude Code、Codex CLI会读本地配置文件。如果你要在这些工具里接入 TaoToken配置要写全三件套Base URL、Key、Model ID。以 Claude Code 的settings.json为例路径通常在~/.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key, ANTHROPIC_MODEL: claude-3-5-sonnet } }Codex CLI 的auth.json路径一般在~/.codex/auth.json结构类似{ api_key: sk-你的key, base_url: https://taotoken.net/api, model: gpt-4o }注意不同工具的字段名不一样但核心就是这三样。少任何一个都会报 401 或 model not found。如果你用 Cline 或 CC Switch 这类插件MCP 配置里同样要填全 Base URL、Key、Model ID缺一不可。2.4 先做一次连通性验证配置完别急着压测先发一个最小请求确认通道通curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: ping}], max_tokens: 5 }返回里有choices字段就说明通了。如果报 401检查 Key 有没有复制错如果报 model not found检查模型 ID 拼写。这一步过了再往下走。3. 可复制配置并发压测脚本与指标采集这一节是核心。我会给一个完整的 Python 异步压测脚本能同时采集 TTFT、TPOT、总延迟、成功率和 TPM 消耗。脚本用流式请求因为 TTFT 和 TPOT 只有在流式模式下才有意义。3.1 压测脚本设计思路脚本要做几件事按指定并发数同时发请求每个请求记录首 token 到达时间TTFT和后续每个 token 的间隔TPOT统计 P50/P90/P99最后汇总总 token 数和耗时算出实际 TPM。为了让结果可复现请求内容固定max_tokens 固定温度设为 0。3.2 完整 Python 脚本import asyncio import time import os import statistics from openai import AsyncOpenAI API_KEY os.environ[TAOTOKEN_API_KEY] BASE_URL os.environ[TAOTOKEN_BASE_URL] MODEL gpt-4o CONCURRENCY 20 REQUESTS_PER_WORKER 5 PROMPT 请用200字介绍大模型推理的prefill和decode阶段。 client AsyncOpenAI(api_keyAPI_KEY, base_urlBASE_URL) async def single_request(worker_id, req_id): start time.perf_counter() ttft None token_times [] token_count 0 try: stream await client.chat.completions.create( modelMODEL, messages[{role: user, content: PROMPT}], max_tokens200, temperature0, streamTrue, ) async for chunk in stream: if chunk.choices and chunk.choices[0].delta.content: now time.perf_counter() if ttft is None: ttft now - start token_times.append(now) token_count 1 end time.perf_counter() tpot None if len(token_times) 1: intervals [token_times[i1] - token_times[i] for i in range(len(token_times)-1)] tpot statistics.mean(intervals) * 1000 return { worker: worker_id, req: req_id, ttft: ttft, tpot_ms: tpot, total: end - start, tokens: token_count, ok: True, } except Exception as e: return {worker: worker_id, req: req_id, ok: False, error: str(e)} async def worker(worker_id, results): for i in range(REQUESTS_PER_WORKER): r await single_request(worker_id, i) results.append(r) async def main(): results [] start time.perf_counter() tasks [worker(w, results) for w in range(CONCURRENCY)] await asyncio.gather(*tasks) elapsed time.perf_counter() - start ok [r for r in results if r[ok]] fail [r for r in results if not r[ok]] ttfts sorted([r[ttft] for r in ok if r[ttft]]) tpots sorted([r[tpot_ms] for r in ok if r[tpot_ms]]) total_tokens sum(r[tokens] for r in ok) def pct(data, p): if not data: return None idx int(len(data) * p / 100) return data[min(idx, len(data)-1)] print(f总请求: {len(results)}, 成功: {len(ok)}, 失败: {len(fail)}) print(f总耗时: {elapsed:.2f}s) print(fTTFT P50: {pct(ttfts,50):.3f}s P90: {pct(ttfts,90):.3f}s P99: {pct(ttfts,99):.3f}s) print(fTPOT P50: {pct(tpots,50):.1f}ms P90: {pct(tpots,90):.1f}ms P99: {pct(tpots,99):.1f}ms) print(f总输出 token: {total_tokens}) print(f实际 TPM: {total_tokens / elapsed * 60:.0f} token/min) if fail: print(失败样例:, fail[0][error]) if __name__ __main__: asyncio.run(main())这个脚本跑起来后你会看到类似这样的输出总请求: 100, 成功: 100, 失败: 0 总耗时: 42.31s TTFT P50: 0.612s P90: 1.204s P99: 2.031s TPOT P50: 18.3ms P90: 24.1ms P99: 41.7ms 总输出 token: 18640 实际 TPM: 26430 token/min3.3 参数调整与场景对照并发数CONCURRENCY和每 worker 请求数REQUESTS_PER_WORKER是你要调的。建议从 5 并发开始逐步加到 10、20、50观察 TTFT 和 TPOT 的变化曲线。当 TTFT 开始明显上升而 TPOT 基本不变时说明你撞到了并发墙——请求在排队但模型本身没变慢。max_tokens控制输出长度影响 TPOT 的统计样本量和总耗时。测 TTFT 时可以用小 max_tokens比如 50测 TPM 时用大 max_tokens比如 500让 token 量堆起来。如果你要测长输入场景把 PROMPT 换成一整篇长文档观察 prefill 阶段的耗时。这时候 TTFT 会显著变大因为输入 token 多prefill 时间长。3.4 Node.js 版本采集片段如果你用 Node核心采集逻辑类似import OpenAI from openai; const client new OpenAI({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, }); async function measure() { const start performance.now(); let ttft null; let last null; const intervals []; const stream await client.chat.completions.create({ model: gpt-4o, messages: [{ role: user, content: ping }], max_tokens: 100, stream: true, }); for await (const chunk of stream) { if (chunk.choices?.[0]?.delta?.content) { const now performance.now(); if (ttft null) ttft now - start; if (last ! null) intervals.push(now - last); last now; } } const tpot intervals.reduce((a, b) a b, 0) / intervals.length; console.log(TTFT: ${ttft.toFixed(0)}ms, TPOT: ${tpot.toFixed(1)}ms); } measure();两个版本逻辑一致选你顺手的用。4. 验证请求与成功结果建立你的性能基线脚本跑通只是第一步关键是把结果解读成可用的基线。这一节讲怎么验证请求成功、怎么读指标、怎么算出你的真实容量。4.1 验证请求成功的三个信号第一个信号是 HTTP 200 且返回体里有choices。第二个信号是流式模式下能持续收到delta.content如果中途断了说明连接被掐或超时。第三个信号是 token 计数和预期接近如果 max_tokens200 但只收到 20 个 token可能是被限流截断。压测时一定要统计失败率。失败请求里最常见的是 429限流和超时。429 说明你撞到了并发或 TPM 上限超时可能是网络或服务端排队。把失败原因分类统计比只看成功率更有用。4.2 读懂 TTFT 和 TPOT 的分位值回到开头那个案例。他看到的 TTFT 从 0.6 秒涨到 2.3 秒如果只看平均值可能只涨到 1.1 秒感觉没那么严重。但 P99 可能已经涨到 5 秒以上那 1% 的用户体验极差投诉就来自他们。我的建议是TTFT 看 P50 和 P90P50 代表普通用户P90 代表较差情况TPOT 看 P50 和 P99因为 TPOT 的波动通常比 TTFT 小P99 能抓到极端卡顿。SLA 承诺一般写 P90 或 P99别用平均值对外承诺。4.3 从压测结果算真实 TPM 与并发容量脚本最后输出的实际 TPM是你这次压测的真实吞吐。把它和账号的 TPM 规格对比就知道用了多少。比如你测出 26430 token/min账号规格是 200 万 TPM那只用了 1.3%。并发容量怎么算用 Littles Law并发数 ≈ RPS × 单请求平均耗时。假设你测出单请求平均耗时 2 秒想支撑 10 RPS那稳态并发约 20。如果你的账号并发上限是 50那还有余量如果上限是 15就会排队。这里有个容易踩的坑并发和 TPM 是两道独立的闸门先撞哪道取决于业务形态。长会话业务聊天、Agent占坑久先撞并发墙批量短任务槽位复用快先撞 TPM 墙。压测时两种场景都要模拟别只测一种。4.4 建立基线的实操步骤第一步固定模型和 prompt跑 5 并发、10 并发、20 并发三组记录 TTFT/TPOT 的 P50/P90/P99。第二步找出 TTFT 开始明显上升的并发点那就是你的实际并发容量。第三步用大 max_tokens 跑一组算出实际 TPM 消耗速率。第四步把这三组数据存成表格作为后续对比的基线。以后每次换模型、换版本、调参数都拿新结果和基线对比就能快速判断是变好了还是变差了。5. 本篇常见错排查401、429、超时与配置错误压测过程中最容易遇到几类报错这一节逐个拆解。5.1 401 UnauthorizedKey 或 Base URL 错报错长这样openai.AuthenticationError: Error code: 401 - {error: {message: Invalid API key}}原因通常是三个Key 复制时多了空格或换行环境变量没生效比如在错误的 shell 里 exportBase URL 写错比如漏了/api或写成了别的路径。排查方法先echo $TAOTOKEN_API_KEY确认 Key 存在且无空格再确认 Base URL 是https://taotoken.net/api。如果你在 Claude Code 里报 401检查settings.json里的ANTHROPIC_API_KEY字段有没有写对。5.2 429 Too Many Requests撞到并发或 TPM 墙报错长这样openai.RateLimitError: Error code: 429 - {error: {message: Rate limit exceeded}}429 分两种并发超限和 TPM 超限。区分方法是看压测时的并发数和 token 速率。如果并发数接近账号上限那是并发墙如果并发不高但 token 速率很高那是 TPM 墙。应对方式并发墙就降并发或加账号并发额度TPM 墙就降低单请求 token 量或做流量错峰。脚本里可以加退避重试import asyncio async def request_with_retry(fn, max_retry3): for i in range(max_retry): try: return await fn() except Exception as e: if 429 in str(e) and i max_retry - 1: await asyncio.sleep(2 ** i) else: raise5.3 超时与连接中断报错可能是httpx.ReadTimeout或Connection reset by peer。原因通常是服务端排队太久或者客户端超时设置太短。OpenAI SDK 默认超时 600 秒一般够用。如果你自己设了短超时调大一点。另外流式请求如果长时间没数据可能是 prefill 阶段在跑长输入耐心等或减小输入。5.4 配置类错误model not found 与 local proxy failedmodel not found说明模型 ID 拼错了或者你的账号没有该模型权限。去 TaoToken 文档核对模型列表。local proxy failed通常出现在工具链里比如 Claude Code 或 Cline 配置了本地代理但代理没启动。检查你的配置文件里 Base URL 是不是直接指向https://taotoken.net/api不要经过本地代理。如果你用了 CC Switch 或 MCP确认三件套Base URL、Key、Model ID都填了缺一个就会报这类错。5.5 指标异常TTFT 正常但 TPOT 很高这种情况说明首字来得快但后续出字慢。原因可能是模型在 decode 阶段负载高或者你的 max_tokens 太大导致后期变慢。排查方法换小 max_tokens 再测如果 TPOT 降下来说明是输出长度问题如果还是高可能是模型服务端 decode 瓶颈换个模型对比。6. 把压测变成日常持续监控与容量规划压测不是跑一次就完事。模型版本会更新你的业务量会增长账号规格可能调整所以性能基线要定期复测。我的做法是每周跑一次固定脚本把结果存进表格画成趋势图。一旦 TTFT 或 TPOT 的 P90 出现明显上升就提前排查别等用户投诉。容量规划上记住那个核心公式并发数 ≈ RPS × 单请求平均耗时。你的业务 QPS 乘以平均响应时间就是需要的并发数。再乘以单请求平均 token 量就是需要的 TPM。两个数都算出来和账号规格对比就知道该不该扩容。最后给一个实用技巧压测时把 prompt 和 max_tokens 固定成你线上业务的典型值别用ping这种超短请求。因为 TTFT 和 TPOT 都受输入输出长度影响用真实业务形态测出来的基线才有参考价值。如果你要测多个模型用 TaoToken 的统一 Key 切换 model 字段就行其他配置不动对比结果最干净。