展开本页目录
开始前准备什么
- 先固定 prompt、完整结束条件、计时起止和网络环境。
- 本页示例不发请求，计时记录来自你自己的真实试验。
- 若要测 TTFT，保存流式首个可见内容事件，不用 HTTP 头到达替代。
- 定义计时口径
- 固定输出任务
- 轮换执行顺序
- 保留失败耗时
- 统计与解释
20个虚构任务、参考答案、可信测试与空记录模板。没有新模型成绩，不会调用API。
elapsedMs 为空直到真实测量；不预填 TTFT。
用于填写记录的CSV；转换为分析器JSON时还需附上configs。空值表示未测。
计费、重试与未运行占位规则。
三个时间，回答三个不同问题
连接、排队、网络和响应读取都可能影响客户端测量。TTFT 未测就保留未知；不把响应头、心跳或纯控制事件算作首个可见文本。
| 指标 | 起止范围 | 可以回答 |
|---|---|---|
| 客户端总耗时 | 发起请求→完整响应读完 | 用户等待了多久 |
| TTFT | 发起请求→首个可见文本内容 | 流式开始输出多快 |
| 有效结果时间 | 任务开始→获得已验收结果；包括必要重试 | 完成可用任务花了多久 |
- 指标
- 客户端总耗时
- 起止范围
- 发起请求→完整响应读完
- 可以回答
- 用户等待了多久
- 指标
- TTFT
- 起止范围
- 发起请求→首个可见文本内容
- 可以回答
- 流式开始输出多快
- 指标
- 有效结果时间
- 起止范围
- 任务开始→获得已验收结果；包括必要重试
- 可以回答
- 完成可用任务花了多久
本站绘制的内容说明图：本页定义三个不同指标；TTFT 未测保持未知，不能把整请求时间标成首字时间。
同题、同预算，输出长度也要记录
每个型号得到相同任务和验收标准。结果长度、推理档位、输出上限与缓存条件一起记录；更短但错误的回答不能获得“最快完成任务”的胜出。这个任务用于说明测量口径，不是已测延迟。
可复制的固定短任务
将下面的虚构展览费用行转换为 JSON 数组。每行字段仅含 recordId、amountYuan、quantity、unit。recordId 保留前导零并为字符串；amountYuan 为元单位两位小数字符串或 null；数量为整数或 null。- 表示缺失，负号表示调整款。万元乘以10000后再保留两位；不推断缺失值，不增加总计行。
| 编号 | 金额（元） | 数量 | 单位 |
|---|---:|---:|---|
| 0031 | -50.25 | 1 | 笔 |用单调时钟记录总耗时，TTFT 单列
示意中的注释需要换成你已经审查过的请求客户端；不能运行空片段后把接近零的值当模型耗时。每次失败也保存已等待时间和错误状态。
计时边界示意；不包含可执行 API 请求
from time import perf_counter
started = perf_counter()
# 此处执行你自己的请求，并读完响应；不要自动重试
# response = send_request_and_read_complete_body()
elapsed_ms = (perf_counter() - started) * 1000
# 未使用流式，ttft_ms 必须留 None
ttft_ms = None小样本先给原始值和中位数
P95 在很少的样本里主要受极端值和分位算法影响；先注明样本量和算法，不给“服务 SLA 达标”的结论。中位数也只是这次任务的中心位置。
每个型号可以使用独立 configId；先比较配置对象中的协议、参数和映射证据，再决定是否具备横比条件。相同 ID 不自动代表相同设置。
| 样本情形 | 建议报告 | 不能推断 |
|---|---|---|
| 每款只有 9 条 | 原始值、任务分布与中位数 | 稳定的高分位服务表现 |
| 任务长度不同 | 按 datasetId 与可追溯配置分组 | 总耗时均值代表模型通用速度 |
| 失败和超时较多 | 完成样本耗时与失败等待分开 | 只删失败后的平均速度 |
| 冷/热缓存混合 | 注明缓存条件或分层 | 把缓存差异全归因到型号 |
- 样本情形
- 每款只有 9 条
- 建议报告
- 原始值、任务分布与中位数
- 不能推断
- 稳定的高分位服务表现
- 样本情形
- 任务长度不同
- 建议报告
- 按 datasetId 与可追溯配置分组
- 不能推断
- 总耗时均值代表模型通用速度
- 样本情形
- 失败和超时较多
- 建议报告
- 完成样本耗时与失败等待分开
- 不能推断
- 只删失败后的平均速度
- 样本情形
- 冷/热缓存混合
- 建议报告
- 注明缓存条件或分层
- 不能推断
- 把缓存差异全归因到型号
本站绘制的内容说明图：此页统计边界防止删失败、混任务或缓存后制造速度排名；中位数仅属于当次样本。
截断快、失败快，也不能算任务完成快
| 情况 | 状态与记录 | 解释 |
|---|---|---|
| HTTP 200，但达到输出上限 | truncated；passed 不记通过 | 未取得完整回答 |
| 超时且提交情况不明 | unknown；保留等待时间 | 先查日志，再决定重发 |
| 完整 JSON，负号错了 | completed / passed=false | 完成了传输，没有完成合同 |
| 所有题通过但网络不同 | 保留环境差异 | 不能直接当纯模型推理速度 |
- 情况
- HTTP 200，但达到输出上限
- 状态与记录
- truncated；passed 不记通过
- 解释
- 未取得完整回答
- 情况
- 超时且提交情况不明
- 状态与记录
- unknown；保留等待时间
- 解释
- 先查日志，再决定重发
- 情况
- 完整 JSON，负号错了
- 状态与记录
- completed / passed=false
- 解释
- 完成了传输，没有完成合同
- 情况
- 所有题通过但网络不同
- 状态与记录
- 保留环境差异
- 解释
- 不能直接当纯模型推理速度
已有报告与新材料分开读
同档主力报告的 27 次请求已保存客户端完整请求耗时，并展示每款九次的中位数。它没有测量 TTFT，也没有对这套 20 个新任务产生成绩。新增更难任务后应创建新 datasetId，不与旧短任务混算。
怎样确认已经完成
- TTFT 与总耗时使用独立字段，缺测不填零。
- 相同输入、预算、完成状态和计时口径。
- 错误、截断与未知等待没有被删除。
- 样本量和缓存条件公开，不把中位数写成服务保证。
常见问题
非流式请求可以测 TTFT 吗？
不能从完整响应到达时间恢复首字时刻。需要单独接收流式事件，并定义首个可见内容的时间。
模型一秒就报错，算最快吗？
它只是很快失败，不是最快完成任务。完成样本耗时与失败等待时间要分开。
为什么九次结果不重点展示 P95？
少量样本的尾部指标不稳定。先提供原始记录、中位数与任务范围，更多样本和稳定条件后再讨论尾部延迟。