1. 大模型压测到底在测什么TTFT、TPOT、TPS 与长尾分位数大模型压测指标一览这件事很多人第一次接触会以为跟传统 Web 压测差不多——看 QPS、看响应时间就完事了。但真正上手跑过一轮就会发现生成式模型的性能画像完全是另一套逻辑。传统接口返回一个 JSON 就结束了而大模型是逐 token 往外吐字的用户感知到的“快”和“慢”被切分成了好几个阶段多久开始出字、出字之间顺不顺、整体吐字速度够不够。这三个阶段分别对应 TTFT、TPOT、TPS也是本文要拆解的核心。先说 TTFTTime To First Token首字时间。它衡量的是从客户端发出请求到收到第一个 token 的时间间隔。这个指标直接决定用户对“响应速度”的第一印象。交互式对话场景里TTFT 超过 2 秒用户就会觉得系统卡了超过 5 秒大概率直接关掉页面。测量方式很直接在客户端记录请求发送时间戳 t_send 和第一个 token 到达时间戳 t_firstTTFT t_first - t_send。注意要统计多次请求的均值以及 p95、p99 分位数单次值没有参考意义。TPOTTime Per Output Token每令牌时间反映的是生成过程中的流畅度。它计算的是相邻两个 token 之间的平均时间间隔。比如生成第 2 个 token 与第 1 个间隔 50ms第 3 个与第 2 个间隔 60ms那 TPOT 就是 55ms/token。TPOT 越高用户越容易感觉到“一顿一顿”的。生成一段 100 字的文本TPOT100ms/token 需要 10 秒TPOT30ms/token 只要 3 秒体验差距非常明显。TPSToken Per Second每秒生成 token 数是综合效率指标。计算方式是 TPS (总 token 数 - 1) / (最后一个 token 时间 - 第一个 token 时间)。减 1 是因为第一个 token 的时间已经算进 TTFT 了避免重复计算。TPS 直接决定长文本任务的完成时间生成 1000 tokenTPS100 需要 10 秒TPS50 需要 20 秒。这里要区分单请求 TPS 和集群 TPS前者看单条链路效率后者看整个服务的总吞吐。除了这三个 LLM 特有指标通用性能指标同样不能忽略。响应时间分布里的 p50、p95、p99 比平均值更能反映真实体验——平均值会被极端值扭曲而 p99 能暴露长尾瓶颈。QPS 反映并发处理能力错误率反映稳定性资源利用率CPU、GPU、内存、网络则是定位瓶颈的关键。GPU 利用率低于 30% 通常说明推理效率有问题内存利用率超过 85% 就要警惕 OOM。把这些指标串起来看一次完整的压测应该同时采集TTFT 的 p50/p95/p99、TPOT 的均值与分位数、单请求 TPS 与集群 TPS、端到端响应时间分位数、QPS、错误率、GPU 利用率。缺了任何一块性能画像都是残缺的。而要在不同模型之间做横向对比最大的障碍往往不是压测脚本本身而是每个模型厂商的 API 地址、鉴权方式、参数格式都不一样切换一次就要改一遍代码。下面要讲的 TaoToken 统一 Key 通道解决的正是这个对比成本问题。2. TaoToken 统一 Key 通道多模型压测对比的前置准备做多模型压测对比时最烦的环节其实不是写压测脚本而是每换一个模型就要重新配一套 Base URL、API Key 和请求格式。OpenAI 一套、Claude 一套、国产模型又各有一套压测脚本里到处是 if-else 分支跑完一轮数据还没对齐人已经麻了。TaoToken 的思路是把这些差异收敛到一个统一入口用同一个 Key、同一个 Base URL 去访问不同模型压测脚本只需要改一个 model 字段就能切换目标。TaoToken 是什么简单说它是一个统一的大模型 API 通道对外暴露 OpenAI 兼容的接口格式。你拿一个 Key就能通过 https://taotoken.net/api 这个 Base URL 去请求它支持的各个模型。对压测场景来说这意味着你的采集脚本、指标计算逻辑、结果存储格式都可以复用唯一变化的就是请求体里的 model 参数。对比不同模型的 TTFT、TPOT、TPS 时客户端侧的开销完全一致数据可比性大大提升。它适合谁三类人最受益一是要做模型选型的团队需要横向对比多个模型在相同 prompt 下的延迟和吞吐二是做推理服务容量规划的工程师要摸清不同模型在并发下的性能拐点三是做 Agent 或长文本应用的开发者需要评估不同模型在真实业务 prompt 下的生成效率。如果你只是偶尔调一次 API 玩玩那直接用各家原生接口也行但只要涉及“对比”和“批量采集”统一通道的价值就出来了。前置准备其实就三样东西一个 TaoToken 的 API Key、一个能发 HTTP 请求的环境Python requests 或 httpx 就够、一个记录时间戳的采集逻辑。Key 的获取在控制台完成拿到后不要硬编码在脚本里用环境变量注入。Base URL 统一用 https://taotoken.net/api注意这个地址不带任何查询参数是纯粹的 API 入口。模型 ID 则根据你要压测的目标填写比如 gpt-4o、claude-3-5-sonnet、deepseek-chat 这类具体可用列表以控制台和接入文档为准。这里要强调一个压测场景的特殊点TTFT 和 TPOT 的测量精度高度依赖客户端的时间戳采集方式。如果你用流式请求streamtrue每收到一个 chunk 就记一次时间戳那 TTFT 就是第一个 chunk 到达的时间TPOT 就是相邻 chunk 的时间差均值。如果你用非流式请求那只能拿到端到端总时间TTFT 和 TPOT 都测不出来。所以压测脚本必须走流式模式这一点在下一节的配置里会具体体现。另外压测前建议先做一次连通性验证确认 Key 有效、Base URL 可达、目标模型可调用。这一步能排掉大部分低级错误避免跑了几百个请求才发现全是 401。验证方式很简单发一个最小请求看返回结构里有没有 choices 字段和正常的 content。连通性没问题后再进入正式的指标采集环节。3. 可复制的压测脚本配置流式采集 TTFT/TPOT/TPS这一节直接给可运行的配置和代码。核心思路是用 OpenAI 兼容的 SDK 指向 TaoToken 的 Base URL开启 stream 模式在迭代 chunk 的过程中记录每个 token 的到达时间戳最后统一计算 TTFT、TPOT、TPS 和端到端延迟。先看环境变量配置建议放在 .env 文件里不要写死在代码中# .env TAOTOKEN_API_KEYsk-你的Key TAOTOKEN_BASE_URLhttps://taotoken.net/api然后是压测脚本的核心部分。我用 Python 的 openai SDK 来写因为它天然兼容流式接口时间戳采集也直观import os import time import statistics from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(TAOTOKEN_API_KEY), base_urlos.getenv(TAOTOKEN_BASE_URL), ) def measure_once(model: str, prompt: str, max_tokens: int 256): 单次流式请求采集 TTFT / TPOT / TPS t_send time.perf_counter() token_times [] stream client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], max_tokensmax_tokens, streamTrue, temperature0.0, ) for chunk in stream: delta chunk.choices[0].delta if delta and delta.content: token_times.append(time.perf_counter()) if len(token_times) 2: return None ttft (token_times[0] - t_send) * 1000 # ms gaps [(token_times[i1] - token_times[i]) * 1000 for i in range(len(token_times) - 1)] tpot statistics.mean(gaps) # ms/token total_time token_times[-1] - token_times[0] tps (len(token_times) - 1) / total_time if total_time 0 else 0 e2e (token_times[-1] - t_send) * 1000 return { ttft_ms: round(ttft, 2), tpot_ms: round(tpot, 2), tps: round(tps, 2), e2e_ms: round(e2e, 2), tokens: len(token_times), }这段代码的关键点有三个。第一t_send 在发请求之前记录保证 TTFT 包含网络往返和首 token 推理时间。第二只有 delta.content 非空时才记时间戳避免把 role 声明之类的空 chunk 算进去。第三TPS 用 (token 数 - 1) / (最后时间 - 第一个时间)和前面定义一致。接下来是批量压测和分位数统计的配置。单次测量波动大必须跑多轮取分位数def run_benchmark(model: str, prompt: str, rounds: int 20): results [] for i in range(rounds): r measure_once(model, prompt) if r: results.append(r) time.sleep(0.5) # 避免触发限流 ttfts sorted([r[ttft_ms] for r in results]) tpots sorted([r[tpot_ms] for r in results]) tpss sorted([r[tps] for r in results]) def pct(data, p): idx int(len(data) * p / 100) return data[min(idx, len(data) - 1)] return { model: model, rounds: len(results), ttft_p50: pct(ttfts, 50), ttft_p95: pct(ttfts, 95), ttft_p99: pct(ttfts, 99), tpot_p50: pct(tpots, 50), tps_p50: pct(tpss, 50), tps_p95: pct(tpss, 95), }如果你用 Node.js 或 Go 写压测逻辑完全一样关键是流式迭代和 perf_counter 级别的时间戳。用 curl 也能做单次验证但批量采集还是脚本更靠谱。下面给一个 curl 的最小验证命令用来确认通道连通curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o, messages: [{role: user, content: 用一句话解释什么是TTFT}], stream: true, max_tokens: 64 }跑通这个 curl 后再用 Python 脚本做批量采集。压测 prompt 建议固定比如统一用“请用 200 字介绍大模型推理优化”这样不同模型之间的输出长度接近TPS 对比才有意义。如果 prompt 长度差异大TTFT 的可比性会下降因为 prefill 阶段的计算量不同。还有一个容易忽略的配置点并发压测。上面的脚本是串行的测的是单请求性能。如果要测集群 TPS 和 QPS需要用 asyncio 或线程池并发发请求然后统计单位时间内所有请求的总 token 数。并发场景下 TTFT 会明显上升因为请求在排队。建议先做单请求基线再做并发梯度测试比如 1、5、10、20 并发观察 TTFT 和 TPS 的变化曲线找到性能拐点。4. 验证请求与成功结果TTFT/TPOT/TPS 数值一致性核对脚本写完后第一件事不是跑全量压测而是做一次小规模验证确认采集到的 TTFT、TPOT、TPS 数值在逻辑上自洽。很多人跑完压测直接看结果结果发现 TPS 算出来是负数或者大得离谱回头排查浪费大量时间。验证环节能提前拦住这些问题。先跑单次请求打印原始时间戳和计算结果result measure_once(gpt-4o, 请用100字介绍大模型压测) print(result)预期输出类似{ ttft_ms: 420.35, tpot_ms: 18.72, tps: 53.42, e2e_ms: 2280.15, tokens: 100 }拿到这组数据后做三个一致性核对。第一TTFT 应该小于 e2e且 e2e 约等于 TTFT TPOT × (tokens - 1)。用上面的数验证420.35 18.72 × 99 2273.63和 e2e 的 2280.15 非常接近说明采集逻辑正确。第二TPS 应该约等于 1000 / TPOT。1000 / 18.72 53.42和输出的 tps 完全吻合。第三tokens 数量应该和 max_tokens 设置以及实际输出长度匹配如果 tokens 只有 1 或 2说明流式 chunk 解析有问题。如果这三个核对都通过说明单次采集链路是通的。接下来跑多轮看分位数是否合理summary run_benchmark(gpt-4o, 请用200字介绍大模型推理优化, rounds20) print(summary)预期输出{ model: gpt-4o, rounds: 20, ttft_p50: 435.2, ttft_p95: 680.5, ttft_p99: 920.1, tpot_p50: 19.1, tps_p50: 52.3, tps_p95: 58.7 }这里要关注 p50 和 p95 的差距。如果 p95 是 p50 的 3 倍以上说明长尾延迟严重可能是网络抖动或服务端排队。正常情况下 p95 在 p50 的 1.5 到 2 倍之间比较健康。TTFT 的 p99 如果超过 2 秒交互式场景就要谨慎了。验证通过后就可以做多模型对比了。用同一个 prompt、同样的 rounds分别跑不同模型把结果汇总成表格模型TTFT p50 (ms)TTFT p95 (ms)TPOT p50 (ms)TPS p50TPS p95gpt-4o43568019.152.358.7claude-3-5-sonnet51079022.444.649.2deepseek-chat38062016.859.565.1这张表就是压测的核心产出。注意所有模型都走同一个 TaoToken 通道客户端侧开销一致数据可比性有保障。如果某个模型的 TTFT 明显偏高可以进一步排查是 prefill 计算量大还是网络路由问题。如果 TPS 偏低但 TPOT 正常可能是输出 token 数太少导致统计噪声。还有一个验证技巧用非流式请求测端到端时间和流式采集的 e2e 做对比。两者应该接近如果差很多说明流式解析有额外开销或者 chunk 合并逻辑有问题。这个交叉验证能进一步确认数据可信度。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth压测过程中报错是常态关键是能快速定位。这一节把最常见的几类错误和排查路径列出来都是实际跑压测时踩过的坑。401 Unauthorized是最常见的。表现是请求直接返回 401连模型都没碰到。原因通常是 API Key 无效、过期或者没正确注入环境变量。排查步骤先确认 .env 文件里的 TAOTOKEN_API_KEY 没有多余空格或引号再确认脚本里 load_dotenv() 在 client 初始化之前执行然后用 curl 单独验证 Key 是否有效。如果 curl 也 401那就是 Key 本身的问题去控制台重新生成一个。注意不要把 Key 硬编码在代码里提交到仓库这是安全大忌。local proxy failed这类报错通常出现在客户端环境配置了本地代理但代理不可达或证书有问题。表现是连接超时或 SSL 握手失败。排查时先检查环境变量里有没有 HTTP_PROXY、HTTPS_PROXY 这类设置如果有但代理服务没开就会报这个错。解决方式是清掉这些环境变量或者确保代理服务正常运行。压测场景下建议直连避免代理引入额外延迟影响 TTFT 测量。reading choices 相关报错典型的是KeyError: choices或IndexError: list index out of range。这通常发生在流式解析时某个 chunk 的 choices 为空数组或者 delta 里没有 content 字段。上面的脚本里用if delta and delta.content做了保护但如果你自己写的解析逻辑没做判空就会崩。还有一种情况是请求体格式不对比如 messages 字段拼写错误服务端返回了错误结构客户端却按正常结构解析。排查方式是打印原始 chunk 看结构确认 choices 字段存在且非空。OAuth 相关错误一般出现在用某些 SDK 的默认鉴权流程时。OpenAI SDK 默认走 API Key 鉴权但如果你误用了 Azure 的配置或者某些企业版 SDK可能会触发 OAuth 流程。表现是提示 token 获取失败或 scope 不对。解决方式是确认 client 初始化时只传了 api_key 和 base_url没有多余的 azure_endpoint 或 token_provider 配置。TaoToken 走的是标准 Bearer Token 鉴权不需要 OAuth 流程。除了这四类还有几个压测特有的坑。一是限流错误 429表现是请求被拒绝原因是并发太高或请求频率太快。解决方式是在压测脚本里加退避重试或者降低并发梯度。二是超时错误流式请求如果长时间没有 chunk 到达客户端可能超时。建议设置合理的 timeout比如 60 秒并在超时后记录为失败请求计入错误率。三是 token 数统计偏差如果模型返回了空 content 的 chunk比如只包含 role 声明你的 token 计数会偏多导致 TPS 虚高。务必只统计 content 非空的 chunk。排查时建议打开详细日志把每个请求的 model、状态码、TTFT、token 数都打出来。这样一旦某个模型或某个并发级别出错能快速定位是全局问题还是局部问题。压测报告里除了性能指标错误率和错误类型分布也是重要产出能反映服务的稳定性边界。6. 从压测数据到模型选型统一通道下的对比与决策跑完压测、拿到数据之后真正的价值在于用这些数据做决策。TTFT、TPOT、TPS 不是孤立的数字它们对应不同的用户体验维度和业务场景。理解这一点才能把压测结果转化成可执行的选型结论。先看场景匹配。交互式对话场景最敏感的是 TTFT因为用户发出消息后盯着屏幕等第一个字出现这段时间的体感延迟最强烈。如果 TTFT p95 超过 1.5 秒用户就会觉得“卡”。这类场景选型时TTFT 的权重应该高于 TPS。相反长文本生成场景比如报告撰写、代码生成更看重 TPS因为用户对“开始出字”的容忍度较高但对“多久写完”很敏感。TPS 低 20%生成 2000 字就要多等好几秒。TPOT 则介于两者之间它影响的是生成过程中的流畅感TPOT 超过 50ms/token 时用户能明显感觉到字是一个一个蹦出来的。再看并发维度。单请求压测数据只能反映理想情况下的性能上限。真实服务要面对并发请求这时候 TTFT 会上升TPS 会下降因为 GPU 计算资源和显存带宽是共享的。压测时应该做并发梯度测试比如 1、5、10、20、50 并发记录每个梯度下的 TTFT p95 和集群 TPS。如果某个模型在 10 并发时 TTFT 就翻倍说明它的批处理效率或显存管理有问题。集群 TPS 的拐点就是服务的容量上限超过这个点错误率会快速上升。用 TaoToken 统一通道做对比时有一个额外好处客户端侧的网络开销和请求格式完全一致排除了“因为某个厂商 SDK 更重导致 TTFT 偏高”的干扰。所有差异都来自模型服务端本身数据更干净。你可以把多个模型的压测结果放在同一张表里按 TTFT p95 排序再按 TPS p50 排序看哪些模型在两项上都表现均衡。实际选型时建议设定硬性阈值和软性偏好。硬性阈值比如TTFT p95 必须小于 2 秒错误率必须小于 1%TPS p50 必须大于 30。不满足的直接淘汰。软性偏好则根据业务权重打分比如交互场景 TTFT 权重 0.5、TPS 权重 0.3、TPOT 权重 0.2算加权分排序。这样选出来的模型不是“某个指标最强”而是“综合最适合当前场景”。最后提醒一点压测数据有时效性。模型服务端会更新、量化版本会变化、负载情况会波动。建议把压测脚本和采集模板固化下来每次模型版本更新或服务扩容后重跑一轮对比历史数据看性能是否退化。TaoToken 的统一 Key 通道让这个重跑成本很低改个 model 字段就能复测不用重新配环境。压测不是一次性的任务而是持续的性能观测习惯。把 TTFT、TPOT、TPS 的采集自动化配合错误率和资源利用率监控才能真正守住大模型服务的体验底线。