通用大模型 API 性能测试台

面向 OpenAI 兼容接口的单页基准工具。直接在常见浏览器打开即可使用，支持自动列模型、输入长度阶梯测试、 多并发 serving case、流式 TTFT 计时、CSV 导出和浏览器侧兼容提示。

单文件 HTML 流式 TTFT 计时 Serving Case 聚合 截图导出 CSV 导出

计量口径

以 vLLM / SGLang 的 bench_serving 风格为目标：按 case 汇总 request throughput、output throughput、 total token throughput、TTFT、TPOT 和端到端时延，强调客户端可感知性能。

默认长度: 256 → 16K 默认并发: 1 / 2 / 4
若浏览器报跨域或混合内容错误，请确认 API 已放开 CORS，或把本页与 API 放在同源静态服务下访问。

测试配置

连接信息、长度计划、并发计划和高级请求参数都在这一页内完成。

Endpoint 为空时默认 /v1/chat/completions 模型列表默认 /v1/models

连接与模型

输入服务器地址后可自动拉取模型列表。若模型接口不可用，仍可手动填写模型名继续测试。

支持裸地址，未写协议时自动补 http://。

留空自动按 /v1/chat/completions 处理。

大多数兼容服务可直接使用 /v1/models。

等待输入服务器地址。

若此处填写，测试时优先使用该模型名。

默认以 Authorization: Bearer ... 发送。

包含长输入和大并发，默认给 180 秒。

用于缓和服务器抖动，默认 0.3 秒。

测试计划

每个输入长度 × 并发组合都会执行可选 warmup 和 1 轮测量请求；Request Rate=0 时按并发压满，>0 时按固定到达速率发起，再按 serving benchmark 口径聚合。

左侧快速选择常用档位，右侧可继续手动修改为任意整数。

逗号分隔，自动去重并升序处理。`1` 表示单线程，`2,4` 表示只跑 2 并发和 4 并发两组。

左侧快速选择常用档位，右侧可继续手动修改为任意整数。

长度档位 0
单线程 Case 0
并发 Case 0
预计总请求数 0
长度序列预览：-
并发计划预览：-
上下文预算预检：等待模型信息。

硬件与运行环境

自动识别当前浏览器所在机器可见的 CPU / 内存总量 / GPU / 系统信息；内存代际与频率、GPU 互联属性、推理框架与服务端关键特性可手动补充或修正。

不选，当前不标注服务端 feature
可多选或不选；会进入截图导出。

按 `单条规格 × 数量` 自动汇总，例如 `8 x 64 GB DDR5-5600 = 512 GB`。若只识别到总量，会显示浏览器可见总内存。

自动识别依赖浏览器能力：CPU 线程数、设备内存总量和 WebGL GPU 渲染器通常可获取；浏览器无法可靠识别内存代际 / 频率、GPU Link 拓扑，服务端 GPU / 推理框架 / Feature 也建议人工确认后补充。
提示词与高级选项 默认折叠；包含系统提示、思考控制、防缓存、warmup、请求速率与附加请求参数

提示词与高级选项

为提高跨模型稳定性，默认使用英文填充内容和固定词输出指令。你也可以补充系统提示，或调整 warmup、请求到达速率与附加请求体。

预热请求不计入结果，但会更新服务端缓存与调度状态。默认 0，更适合无缓存基线测试。

0 表示尽快打满并发；大于 0 时按固定到达速率发起请求。

思考控制状态：等待模型识别。
前缀缓存规避状态：等待配置。
严格可比模式要求：Temperature=0、思考控制=自动关闭、服务端返回 SSE 流式最终正文 token，并提供准确 usage.prompt_tokens / usage.completion_tokens。
核心字段 model、messages、stream 和输出 token 上限会由工具最终覆盖， 避免附加 JSON 误把测试逻辑改坏。

执行控制

测试按并发数量列表顺序执行；每个 case 会经历可选 warmup 和 1 轮测量请求。Request Rate=0 时闭环压满并发，>0 时按到达速率发起，再汇总为 serving benchmark 指标。

待开始
填写参数后可直接开始测试。
Ready
尚未执行任何 case 0 / 0
当前 case：-
开始时间：-　耗时：-

摘要面板

整体执行进度、成功率以及按请求聚合后的 serving benchmark 指标会在这里汇总。

Case 进度 0 / 0

还没有结果。

请求成功率 0%

成功请求数 / 总请求数。

TTFT P50 -

显示全局 TTFT P50，并附带 P95 / TPOT P50。

Total output tok/s -

显示全局 total output tok/s，并附带 req/s、total tok/s 与 E2EL P50。

Case 结果

每行表示一个 serving benchmark case；TTFT / TPOT / E2EL 使用每请求明细计算 percentiles。表格里的 Prefill tok/s 与 Decode tok/s 都按并发总吞吐展示。

Case 并发 目标输入档位 平均输入 Prefill tok/s Req/s Decode tok/s Total tok/s TTFT P50 TTFT P95 TPOT P50 E2EL P50 状态 错误
还没有结果。
1. Request throughput：按 case 成功请求数除以 case 总耗时计算。
2. Output / Total token throughput：分别按 sum(completion_tokens) / wall_clock 和 sum(prompt_tokens + completion_tokens) / wall_clock 计算。
3. TTFT：从发起请求到首个最终正文 token 的时间；若服务额外输出 reasoning，这里仍只统计最终回答。
4. TPOT：按 (请求总耗时 - TTFT) / max(completion_tokens - 1, 1) 近似每个输出 token 的平均生成时间。
5. E2EL：单请求端到端总耗时。
6. 严格可比模式：要求接口返回流式正文 token 和准确 usage.prompt_tokens / usage.completion_tokens，否则直接判为不可比。
7. 目标输入档位：页面会逼近目标长度；正式结果以接口返回的实际 token 数为准。
8. 前缀缓存规避：默认会在首个 message 开头注入唯一随机前缀，尽量打散 prefix cache；若需要硬保证，应在服务端直接关闭 prefix cache。

可视化

按输入上下文长度观察不同并发下的 prefill / decode 吞吐、TTFT P95 和 E2EL P95 变化。

Prefill Throughput

横轴为输入上下文长度，纵轴为 tok/s。按整组请求的 sum(prompt_tokens) / prefill 阶段 wall-clock 聚合，体现并发总吞吐。

执行后显示不同并发下的 prefill 吞吐量。

Decode Throughput

横轴为输入上下文长度，纵轴为 tok/s。按整组请求的 sum(completion_tokens - 1) / decode 阶段 wall-clock 聚合。

执行后显示不同并发下的 decode 吞吐量。

TTFT P95

这张图看的是较慢那部分请求的首字等待表现。它比平均值更容易暴露卡顿和抖动，越高说明用户越容易遇到“迟迟不出字”的情况。

执行后显示不同并发下的 TTFT P95。

E2EL P95

这张图看的是较慢那部分请求的完整等待时间。它更接近用户对“整条回复多久才结束”的真实感受，越高说明慢请求拖得越久。

执行后显示不同并发下的 E2EL P95。