HopBase先说答案:衡量大模型 API 的性能,看三个可测的东西——首字延迟(TTFT)的 P95/P99 分布、流式全程的稳定性(断流率)、以及 prompt cache 命中对两者的放大作用。总耗时和平均值都会骗人。「高性能」不该是供应商页面上的形容词,而应该是你终端里跑出来的数字,方法在下面,全部可复现。
为什么「总耗时」是个坏指标
一次生成的总耗时由输出长度主导:输出 2000 字自然比 200 字慢十倍,这和链路质量无关。流式场景下用户的真实体感是两段:首字什么时候出来(TTFT),之后出字稳不稳。TTFT 才是链路指标——它包含了接入、网关调度、上游排队的全部开销,链路上任何一环拥堵都会体现在这里。
看分布,别看均值
均值会被长尾抹平:100 次请求里 90 次 1 秒、10 次 8 秒,均值 1.7 秒看着不错,但你的用户每十次就撞上一次 8 秒。P95/P99 抖动大,说明链路在排队或重试——这正是保真检测里「工程质量面」的判据之一。实测要点:固定提示、温度 0、同一时段连续 N≥30 次,记录每次 TTFT 后看分位数,而不是平均。
断流率:最被忽视的性能指标
长输出中途静默截断,是流式场景最恶劣的故障形态:你拿到了一半内容,却没有任何错误码。测法很简单:让模型稳定输出长内容(比如 2000 字),重复 N 次,统计「流正常走完」的比例;同时检查流的收尾是否规范(SSE 是否有明确的结束标记)。断流率高的通道,再快的 TTFT 都没有意义。
缓存命中:性能与成本是同一枚硬币
prompt cache 命中时,输入侧按折扣价计费,TTFT 也显著下降——性能和成本在这里是同一件事。而命中率取决于通道拓扑:请求必须落在同一个上游账号上才可能命中,随机路由的池子命中率趋近于零。网关侧怎么用亲和调度保住命中率,见高并发网关工程实录;cache 的计费结构与省钱写法,见Prompt Cache 能省多少钱。
错误码与重试行为
性能测试里容易漏掉的一项:网关是否原样透传上游错误码。把 429 吞掉改造成超时的通道,会让你的客户端退避逻辑失效,高峰期性能雪崩。测法:故意触发限流或传错参数,对比返回行为与官方文档是否一致。
一条命令起步的测法
TTFT 用 curl 就能量(流式下 time_starttransfer 即首块到达时间):
curl -N -s -o /dev/null \
-w "TTFT %{time_starttransfer}s | total %{time_total}s\n" \
https://api.hop-base.com/v1/chat/completions \
-H "Authorization: Bearer $HOPBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"<模型ID>","stream":true,"messages":[{"role":"user","content":"用一句话介绍你自己"}]}'把它放进循环跑 30 次,再换高峰时段复测一轮,P95 和抖动就都有了。完整的评测纪律:固定任务集、温度 0、剔除首次冷启动、隔时段复测、官方直连与被测通道同条件对照。
我们自己怎么埋点
HopBase 对每个请求记录模型、用量、耗时、状态——这既是计费审计的留痕,也是我们自己的性能监控数据源;常驻探针持续拨测各通道,异常在用户感知之前处理。这也是我们敢把测法公开的原因:你测出来的数字,和我们看到的是同一条链路。
常见问题
TTFT 多少算「好」?
绝对值受模型、地域、接入点影响,横向可比的是同条件下的对照:官方直连与被测通道各跑一轮,差距和分布稳定性比绝对值更说明问题。
经过网关会比直连慢吗?
网关多一跳的固定开销是毫秒级;而调度带来的排队减少、缓存命中带来的 TTFT 下降是百毫秒到秒级。孰大孰小,用上面的方法各测一轮就有答案,不需要相信任何一方的说法。
怎么排除测试噪声?
温度 0、固定提示、N≥30、剔除首次冷启动、隔时段复测;对比测试必须同时段进行,跨时段对比会把上游的时段性波动误判成通道差异。