首字延迟（TTFT）
从发出请求到收到第一个 Token 的等待时间，包含网络往返、排队与模型开始生成前的思考，越低越好。
AI API 速度测试
API SPEEDTEST大模型 API 基准测试用同一组提示词测试任意 OpenAI 兼容接口：分别记录请求发出、首个可见字符与最后一个 Token 的时间点，给出首字延迟（TTFT）、输出吞吐量（token/s）、完整响应耗时与多轮波动。默认流式请求，多轮按顺序执行不制造并发压力，结果只保存在当前浏览器，Key 不落盘。
- 首字延迟 TTFT
- 输出吞吐量
- 完整响应耗时
- 多轮取平均
免登录 · Key 不落盘
API SPEEDTEST 测什么
既测开始前的等待，也测输出后的速度
速度快不只意味着最终答案更早完成。我们记录请求发出、首个可见字符、最后一个 Token 的时间点，把排队等待与模型生成拆开，让不同服务商的表现可以公平比较。
输出吞吐量
首 Token 之后每秒生成多少 Token，数值越高，长回答完成得越快。
完整响应耗时
一次请求从发送到响应结束的平均时间，包含等待与完整生成过程。
LIVE API BENCHMARK
输入接口，跑一组真实数据
默认使用流式请求；测试只在当前页面内保存结果，API Key 仅用于本次请求，不写入历史记录。
02 / 测试结果READY
◌
等待开始
填写左侧连接信息后，测试进度和实时输出会显示在这里。
首字延迟输出吞吐量完整响应
准备第 1 / 3 轮
正在连接上游接口，等待第一个 Token…
本轮测试完成
COMPLETED—
每轮测量首字延迟 / 输出吞吐量 / 完整响应
最近一次 AI 输出—
查看原始测量明细
LOCAL HISTORY
最近测试记录
记录只保存在当前浏览器中，不包含 API Key。用于快速比较最近几次的速度表现。
完成一次测试后，这里会显示最近的模型与速度记录。
HOW TO READ
速度报告，应该怎么看
不同接口的计费方式和网络路径不同，建议同时观察等待、生成和稳定性，不要只看一个数字。
先看首字延迟
聊天体验的“反应快不快”主要由 TTFT 决定。它包含网络、排队和模型开始生成前的等待。
再看输出吞吐量
长文本、代码和 Agent 任务更依赖 Token / 秒。首字很快但持续输出很慢，体感仍然会卡。
最后看多轮波动
一次结果只能说明当下。使用 3–5 轮平均值，结合每轮明细，才能发现偶发的排队和限速。
HOW IT WORKS
怎么跑一次速度测试
- 填连接信息填 Base URL（基础地址）与 API Key，再填模型 ID；官方地址和中转站地址都行，点模型输入框右侧的按钮可以读取上游 /models 列表。建议使用临时 Key。
- 选测试参数提示词默认是一段解释性问答，可换成你真实业务里最长的那种请求。轮数选 3 轮（推荐）或 5 轮看稳定性，最大输出建议不低于 256 token，否则吞吐量会被截断影响判断。
- 跑测试点「开始速度测试」后按轮串行请求，页面实时显示进度、已收到的输出与每轮明细；保留「启用流式响应」才能测量首字延迟与输出吞吐量。
- 读报告结果区给出 Token 数、平均 RPM / TPM、首字时间、首 Token 到结束的生成时间、首字延迟、输出吞吐量与完整响应耗时，可展开每轮明细或下载 JSON 报告做横向对比。
DETAILS
三个指标与常见误判
首字延迟（TTFT）
从发出请求到收到第一个可见 Token 的等待时间，包含网络往返、排队与模型开始生成前的思考。聊天类产品的「反应快不快」几乎完全由它决定，单位是秒，越低越好。
输出吞吐量
首 Token 之后每秒生成多少 Token。长文、代码和 Agent 任务更依赖这个指标：首字很快但持续输出慢，体感依然会卡。它受模型档位、输出长度上限与上游带宽共同影响。
完整响应耗时
一次请求从发送到响应结束的平均时间，等于等待 + 完整生成过程，是最贴近用户「等多久拿到答案」的数字。跨天对比时要注意提示词长度必须一致。
为什么要测多轮
一次结果只能说明当下。上游的排队、限流与路由切换都会让单轮偏差很大，用 3–5 轮平均值配合每轮明细，才能分辨稳定的慢和偶发的抖动。
常见误判
「首字延迟低就等于快」是最常见的误判；只测一句短提示词也会低估长上下文的真实耗时。另外，开启非流式响应时无法测量 TTFT，页面会退回只统计总耗时。
数据留在哪里
测试进度与历史记录都在当前浏览器里，API Key 不写入历史、不上传服务器。换设备或清理浏览器数据后记录即消失，需要留档请先下载 JSON 报告。
FAQ
AI API 速度测试常见问题
首字延迟和响应总耗时有什么区别？
首字延迟（TTFT）只算到第一个 Token 出现，衡量「等多久才有反应」；响应总耗时算到最后一个 Token，衡量「等多久拿到完整答案」。长回答里两者差距可能是十几倍，选型时要分别看，不能只比较其中一个。
为什么必须开流式响应？
不开流式时，上游会把整段回答一次性返回，客户端拿到响应的时刻等于生成结束的时刻，无法区分排队等待与生成时间，也就测不出 TTFT 和输出吞吐量。页面默认开启流式正是为此。
测速会消耗多少额度？
按「轮数 × 提示词 + 最大输出」估算，3 轮 256 token 的默认配置大约消耗几千 token，用你自己的 Key 与额度结算，本站不收费用。把轮数降到 1、最大输出降到 128 可以快速试跑。
测试会不会给上游造成压力？
不会。多轮测试是串行执行的，一轮结束才开始下一轮，不会像压测工具那样并发打请求。如果你自己连续点多次，建议间隔几秒，避免被中转站按短时频率限流。
测出来的吞吐量比官方标称低很多，正常吗？
常见。官方标称值通常在理想条件下测得；中转站的并发排队、跨区域网络、以及你本地到上游的链路都会拉低实测值。把同一组参数在不同时段多跑几次，看的是相对差异而不是绝对值。
支持哪些接口和模型？
任何 OpenAI 兼容的 /chat/completions 接口都可以，官方与中转站地址都行，模型 ID 可以直接手工填。Anthropic、Gemini 原生协议接口需要先经中转层转换。
测试记录会上传或公开吗？
不会。结果与历史只写进当前浏览器的本地存储，不含 API Key，也不进入本站数据库或公开榜单；下载的 JSON 报告同样只存在你本地。
为什么同一接口两次结果差很多？
上游的排队深度、路由到哪台机器、以及是否命中缓存都会影响结果；跨区域链路的抖动也很明显。建议固定提示词、固定轮数，在相近时段对比，并把每轮明细一起看，避免用单次数字下结论。
RELATED
相关检测与工具
延迟与吞吐量由你填的上游接口当场返回；多轮取平均，反映检测时点的表现。