1. 为什么 JMeter 压测大模型时 TTFT 这么难拿TTFTTime to First Token指的是从你发出请求到模型吐出第一个 token 的这段时间。它跟总耗时Total Latency完全是两码事一个模型可能整体要 8 秒才答完但首 token 只等了 300ms用户体感就是秒回反过来总耗时 3 秒、首 token 却卡了 2.5 秒用户会觉得这模型半天不吭声。所以做压测时TTFT 是判断交互流畅度的核心指标尤其对聊天、代码补全、Agent 这类流式场景。问题在于JMeter 天生是给请求-响应这种一次性返回的接口设计的。你发一个 HTTP 请求它等完整响应体回来才记录时间。可大模型的流式接口SSEtext/event-stream是一块一块往回吐的JMeter 默认会把整个流读完才算一次采样结束于是你拿到的Sample Time是最后一个 token 的时间而不是第一个 token 的时间。这就是很多人压测完发现延迟数据大得离谱、跟实际体验对不上的原因。我试过直接在 JMeter 里对 SSE 接口压测如果不做特殊处理结果里根本区分不出首 token 和尾 token。要拿到 TTFT核心思路只有一条在客户端记录请求发出的时刻再从流式响应里抓出第一个非空数据块到达的时刻两者相减。这篇就围绕这个思路用 JMeter 的 HTTP 采样器 JSR223 后置脚本把 TTFT 采出来同时用 TaoToken 的统一 Key 和 API 通道来发请求省去在多个模型厂商之间来回配 Key 的麻烦。适合谁看需要给大模型接口做性能基线、写压测报告、或者要给流式接口做 SLA 监控的测试和后端同学。跟着做能产出一份可复用的 TTFT 统计结果。2. 前置准备TaoToken 统一 Key 与 API 通道在动手写脚本前先把请求通道搭好。压测大模型最烦的一点是你要测的模型可能来自不同厂商每家 Key 格式、鉴权头、endpoint 都不一样压测脚本得写好几套。TaoToken 在这里的作用是提供一个统一的 API 入口和统一的 Key你换模型时只改请求体里的model字段鉴权和地址都不用动压测脚本可以复用。具体要准备的东西一个 TaoToken 账号登录后在控制台创建 API Key。地址是https://taotoken.net/api-keys创建后复制那串sk-开头的 Key只显示一次记得存好。确认你要压测的模型名。可以在模型对话页面先手动发一条消息确认这个模型能正常返回再拿去压测。模型对话入口https://taotoken.net/model-chat。记下 API 基地址https://taotoken.net/api。流式对话接口走的是 OpenAI 兼容格式路径是/v1/chat/completions请求体里带上stream: true就是流式。注意API Key 属于敏感凭证压测脚本里不要硬编码明文提交到代码仓库。建议用 JMeter 的用户定义变量或者从环境变量读取本地调试时再临时填。鉴权方式跟 OpenAI 一致请求头里放Authorization: Bearer 你的KeyContent-Type: application/json。这样一套配置无论你后面把model换成哪个JMeter 侧都不用改。3. 可复制配置线程组、HTTP 采样器与 JSR223 脚本这一节是全文重点配置能直接抄。整体结构是一个线程组 → 一个 HTTP 请求采样器发流式请求→ 一个 JSR223 后置处理器算 TTFT→ 一个聚合报告或结果树看数据。3.1 线程组配置新建线程组参数按你的压测目标来。做 TTFT 基线测试时建议先用小并发摸清楚单请求表现再逐步加压参数建议值说明线程数用户数1 → 5 → 20 递增先单线程验证脚本正确性Ramp-Up 时间与线程数相同避免瞬时冲击导致数据失真循环次数10 起单请求 TTFT 波动大需要多次采样调度器按需勾选做持续压测时用单线程先跑通是因为 TTFT 脚本一旦写错多线程下你根本分不清是脚本问题还是并发问题。3.2 HTTP 采样器配置添加HTTP 请求采样器关键配置如下协议https服务器名称或 IPtaotoken.net端口443方法POST路径/api/v1/chat/completions勾选Use KeepAlive在HTTP 请求的高级里把超时设成足够大比如 60000ms流式响应慢的时候别被超时打断请求头管理器里加两条Content-Type: application/json Authorization: Bearer ${TAOTOKEN_KEY}其中${TAOTOKEN_KEY}来自你在用户定义变量里配的变量别写死。请求体Body Data这样写{ model: gpt-4o-mini, stream: true, messages: [ {role: user, content: 用一句话解释什么是首 token 延迟} ] }stream: true是必须的否则服务端一次性返回你采不到首块这个概念。model换成你在 TaoToken 上确认可用的任意模型即可。3.3 JSR223 后置处理器抓首块时间戳这是整个方案的核心。在 HTTP 采样器上右键 → 添加 → 后置处理器 → JSR223 PostProcessor语言选Groovy脚本如下import org.apache.jmeter.samplers.SampleResult // 请求发出的时刻毫秒 long startTime prev.getStartTime() // 拿到完整响应体JMeter 已把流读完 String responseBody prev.getResponseDataAsString() // 按 SSE 行切分找第一个带 content 的数据块 String[] lines responseBody.split(\n) long firstTokenTime -1L for (String line : lines) { line line.trim() if (line.startsWith(data:) !line.contains([DONE])) { String jsonPart line.substring(5).trim() // 只要这个块里有非空 content就认为是首个 token if (jsonPart.contains(\content\) !jsonPart.contains(\content\:\\)) { // 用当前时间近似首块到达时刻 firstTokenTime System.currentTimeMillis() break } } } if (firstTokenTime 0) { long ttft firstTokenTime - startTime vars.put(TTFT_MS, String.valueOf(ttft)) log.info(TTFT ttft ms) } else { vars.put(TTFT_MS, -1) log.warn(未从响应中解析到首个 token) }这里要坦白一个精度问题JMeter 的 HTTP 采样器默认会把整个流读完才交给后置处理器所以上面用System.currentTimeMillis()拿到的时间其实是脚本执行时刻而不是首块真正到达网卡的时刻。它比服务端真实 TTFT 偏大偏大的量约等于剩余流读取时间。要更精确得让 JMeter 边收边解析那就要用BSF或自定义Java Request去接管流读取复杂度陡增。所以务实的做法是用这个脚本拿到的是客户端观测 TTFT 上界做横向对比不同模型、不同并发下的相对趋势完全够用要绝对值还是优先看推理框架自己暴露的指标。这一点在压测报告里要写清楚别把客户端值当服务端真值。3.4 把 TTFT 写进结果文件光在日志里看不够要能统计。加一个聚合报告或用 Simple Data Writer把结果落盘。更推荐的做法是在 JSR223 里把 TTFT 写进一个 CSVimport java.io.File long ttft vars.get(TTFT_MS) as Long File f new File(ttft_result.csv) f.append(${ttft}\n)压测跑完这个文件里就是每次请求的 TTFT 序列后面用 Python 或 awk 算平均值、P95、P99 都行。4. 验证请求跑一次看 TTFT 是否采到配置完先别急着上并发单线程跑一次看三件事。第一看察看结果树里响应是不是流式的。正常的话响应体里会是一行行data: {...}最后一行data: [DONE]。如果返回的是一整块 JSON、没有data:前缀说明stream没生效检查请求体。第二看 JMeter 日志里有没有打印TTFT xxx ms。有值说明脚本解析到了首块打印未从响应中解析到首个 token说明切分逻辑没匹配上多半是响应格式跟预期不同把responseBody前几百字符打出来看看实际长什么样。第三看ttft_result.csv有没有追加数据。跑 10 次循环文件里应该有 10 行。一个正常的单请求结果大概是这样TTFT 在几百毫秒量级总响应时间JMeter 的 Sample Time在几秒量级两者明显拉开差距说明你确实采到了首块而不是尾块。如果两个值几乎相等那基本可以断定脚本没生效采到的还是完整响应时间。验证通过后再把线程数往上加观察 TTFT 随并发的变化。通常并发升高时 TTFT 会先平稳后陡增那个拐点就是你要找的容量边界。5. 本篇常见错排查报 401 或 403Key 没带对。检查请求头是不是Authorization: Bearer sk-xxx中间有空格Bearer后面一个空格再跟 Key。变量没替换成功也会这样去察看结果树的请求头里确认实际发出去的值。响应不是流式、没有data:前缀请求体里stream没设成true或者被别的配置覆盖了。也有可能是模型本身不支持流式换个模型试。TTFT 一直是 -1脚本没匹配到首个 token。常见原因是响应里 content 字段的格式跟脚本假设的不一样比如有的返回content:你有的返回content: 你带空格。把判断条件放宽或者先把responseBody打印出来对照着改。TTFT 数值大得离谱、跟总耗时差不多说明脚本在流读完之后才执行采到的是尾块时间。这是 JMeter 默认行为的固有限制不是脚本 bug。要么接受它是上界值要么改用能边收边解析的方案。多线程下 CSV 写入错乱多个线程同时 append 同一个文件会互相覆盖。给文件名加上线程号比如ttft_result_${__threadNum}.csv或者用 JMeter 自带的监听器落盘再后处理。压测中途连接被断流式响应时间长检查 HTTP 采样器的超时设置以及是否有中间层对长连接做了限制。6. 后续怎么把这套配置用起来脚本跑通之后这套配置的复用价值在于TaoToken 的统一 Key 让你换模型时只改一个model字段JMeter 侧的线程组、采样器、JSR223 脚本全都不用动。你可以把不同模型的 TTFT 曲线放在同一张图里对比压测报告的说服力会强很多。如果后面要做长期的编码类、Agent 类压测请求量大、调用频繁可以了解下 Coding Plan 这类按周期计费的方案比按量付费更适合持续压测场景入口在https://taotoken.net/coding-plan。接入细节和鉴权说明统一看文档https://taotoken.net/doc。要新建或轮换 Key 就去控制台https://taotoken.net/console。最后提醒一句客户端采到的 TTFT 是上界写报告时标注清楚采集口径别和服务端指标混着用。真正要卡 SLA服务端指标才是准绳客户端值用来做趋势和回归对比最合适。
