做过大模型服务压测的朋友应该都有体验接口的 QPS、错误率跑出来都很漂亮可是一丢进真实聊天界面用户照样说“卡死了”。大多数情况下问题不在吞吐而在 TTFT。TTFT 全称 Time To First Token指从客户端发出请求到模型流式返回第一个 token 的时间。对聊天机器人、写作助手这类流式交互应用来说TTFT 几乎等于用户界面上“打完字多久才开始反应”的那个白屏时长是最直接的体感指标。这篇文章是我在给一个电商客服大模型做压测时沉淀下来的目标是把你手把手获取 TTFT 的路线、脚本、服务端指标、对账方法和踩坑点一次性讲清楚。适合正在做 LLM 服务压测的后端同学、算法工程师和 MLOps 同学参考也适合刚接触大模型服务评测、不知道从哪个指标下手的初学者。下面内容我不保证讲得多“全”但保证都是我在真实压测环境里验证过的。1. 先搞清楚 TTFT 到底是什么以及为什么压测必须盯它1.1 用户口中的“卡”和 TTFT 基本是一个东西很多第一次压大模型服务的同学会习惯性地沿用传统 Web 服务的指标QPS、响应时间、错误率。传统接口的响应时间是“请求发出去到完整响应回来”因为传统接口一次性返回全部数据这个时间能代表用户体验。但大模型走的是流式返回接口把完整耗时切成了两段第一段是模型算完第一个 token 并把它送回客户端第二段是后续 token 逐个生成、逐个返回。用户感知到的“它开始理我了”的时刻其实就是第一段也就是 TTFT。我压过一个在线写作助手接口平均耗时只有 3 秒看起来还能接受可一问真实用户普遍抱怨“等半天才开始蹦字”。后来把 TTFT 单独拉出来看才发现并发上来以后 TTFT 的中位数已经到了 1.8 秒P95 冲到 6 秒而后续 token 生成速度反而很快。这时候用户体验的瓶颈被平均耗时掩盖了不单独统计 TTFT 根本定位不到问题。1.2 TTFT、TPOT、总耗时之间的换算关系大模型压测不能只报一个“平均耗时”要拆着看。我常用的三个指标是 TTFT、TPOT 和总耗时。TTFT 是首 token 延迟TPOT 是 Time Per Output Token也叫 token 级生成延迟近似等于“总耗时减去 TTFT 之后除以输出 token 数量”。它们之间存在一个近似关系总耗时 ≈ TTFT TPOT × (输出 token 数 - 1)注意这里减 1是因为 TTFT 已经覆盖了第一个 token 的生成时间。这个公式还要加上尾部传输和框架缓冲的开销但在大多数测试场景下够用来估算。只盯着总耗时的人容易犯一个错误把两个输出长度不一样的请求放在同一张图里对比结果生成 32 个 token 的请求耗时 2 秒生成 512 个 token 的请求耗时 8 秒误以为服务变差了其实 TTFT 和 TPOT 可能完全没变。所以我的习惯是压测报告里永远三件套一起给TTFT 反映首字体验TPOT 反映生成速度总耗时给业务方看整体表现。1.3 服务端角度TTFT 由哪几段拼出来TTFT 不是单一环节的时间它在服务端大概拆成四段网络往返、排队等待、调度延迟、以及 prefill 首 token 计算时间。大模型推理引擎收到请求后先把你的 prompt 做一次完整的前向计算这个阶段叫 prefill产出第一个 token之后进入 decode 阶段逐个生成后续 token。所以 prefill 的性能直接决定 TTFT 的下限而排队和调度决定 TTFT 的上限。理解这点对定位问题很重要。我以前遇到过一次 TTFT 突然恶化第一反应怀疑 GPU 算力不够后来把服务端指标单独拉出来发现 prefill 本身只慢了 10%但请求在队列里等了 2 秒多实际上是并发连接数和最大排队数没有配好。如果只看客户端 TTFT你会以为是模型变慢了方向就搞错了。2. 拿 TTFT 的四条路线客户端、服务端、网关、网络包2.1 客户端侧计时唯一能还原真实体感的切分点客户端侧计时是我最推荐的主方案因为用户就是在客户端等第一个字的从客户端测到的 TTFT 最接近真实体验。但有一个大前提必须按照“流式响应第一条数据”来切不能等整个响应读完。很多同学刚开始用 requests 库写压测脚本一次性拿到完整响应再去计算耗时得到的其实是总耗时不是 TTFT。正确做法是用能流式读取响应的 HTTP 客户端比如 httpx、aiohttp或者直接用原生 socket 解析 SSE 流。SSE 是 OpenAI 兼容接口最常见的流式协议格式长这样data: {choices:[{delta:{content:你}}]} data: {choices:[{delta:{content:好}}]} data: [DONE]客户端只要一行一行地读遇到第一个包含data:且不是[DONE]的行就算拿到了第一个 token此时用当前时间减去请求发起时间就是 TTFT。这个方案还有一个额外好处首包响应头的时间也能记下来便于和服务端网络指标对账。2.2 服务端侧指标vLLM、TGI 自带的 TTFT 聚合如果不想自己写解析逻辑也可以用推理框架自带的指标。vLLM 启动后默认会在:8000/metrics暴露 Prometheus 指标里面通常能找到vllm:time_to_first_token_seconds这类的直方图指标。TGI 也有类似命名比如tgi_time_to_first_token。服务端指标的口径是从请求进入推理引擎到生成第一个 token 的时间不含客户端网络往返所以在做跨地域压测时服务端指标比客户端数值更“纯”。不过服务端指标有个天然缺点它测不到用户真正感受到的链路上游延迟比如 API 网关排队、负载均衡转发、客户端解析缓冲等。而且不同框架、不同版本的指标名可能长不一样有的版本用冒号有的用下划线有的把直方图按模型和接口打了 label看的时候必须先把当前版本的 metrics 内容捞一遍确认指标名。2.3 网关埋点与网络抓包校准用的辅助手段客户端和服务端之间往往还有网关层。如果你们的部署架构里有 API 网关或自研的推理服务前置层我建议在网关里加一个简单的埋点记录请求进入和响应第一个字节发送出去的时刻这样能直接把 TTFT 拆成“网关前”和“网关后”。做高并发压测时这个埋点能帮你快速判断 TTFT 劣化到底是发生在网关排队、网络转发、还是模型推理引擎内部。网络抓包属于最后一道校准手段。小流量压测时可以用 tcpdump 抓取请求连接上的 TCP 报文观察第一个携带业务数据的包出现的时间点。但在大规模压测下抓包分析成本太高不适合常态使用我一般只在怀疑客户端或框架解析层有问题时才临时抓一次做交叉验证。2.4 四类方式怎么选一张表格说清楚获取方式反映的用户体感精确度实施成本适用场景客户端流式计时最直接取决于客户端网络环境低改脚本即可日常压测、对外验收集服务端 metrics只反映引擎内时间高排除网络干扰低curl 接口即可定位推理引擎瓶颈、容量规划网关层埋点能拆上游排队中高需要开发配合多层架构、网关压测网络抓包还原链路真实报文高高分析耗时小流量校准、疑难排查我的建议是主用第一种辅用第二种网关埋点看架构需要网络抓包只在出问题时上。四条路线不是互斥关系而是互为验证关系。3. JMeter 压测大模型获取 TTFT 的完整配置与脚本3.1 为什么 JMeter 默认的“首字节时间”不能直接用市面上的 JMeter 大模型压测教程不少但很多存在一个误区直接用“聚合报告”里的 Time to First Byte 当成 TTFT。JMeter 的 HTTP 请求采样器默认会把整个响应体读完才算完成它所统计的“首字节时间”指的是收到 HTTP 响应头的时刻而不是流式 body 中第一个 token 到达的时刻。对于 SSE 接口HTTP 响应头可以比第一个 token 早很多返回你在聚合报告里看到的首字节可能只有几十毫秒但真正等第一个字可能要一两秒。另外JMeter 自带的 HTTP 采样器默认不保留流式响应内容后置处理器虽然能拿到 body但那时整个流已经读完了时间戳已经失效。所以要拿到真实的 TTFT得绕开普通 HTTP 采样器走 JSR223 Sampler 自己实现流式读取和计时。3.2 推荐做法用 JSR223 Sampler 做流式读取与计时我在 JMeter 里的做法是新建一个线程组并发按需要设置然后在线程组下加一个 JSR223 Sampler语言选 Groovy写一段基于 HttpURLConnection 的流式读取脚本。核心逻辑很简单发起 POST 请求后用 BufferedReader 按行读响应读到第一个合法data:行就停止计时把这个 TTFT 数值写进 SampleResult这样聚合报告就能直接统计了。下面这段是我实测过的简化版脚本去掉鉴权和业务参数核心在流式读取和首 token 判定import java.io.BufferedReader import java.io.InputStreamReader import java.net.HttpURLConnection import java.net.URL import java.nio.charset.StandardCharsets String endpoint http://127.0.0.1:8000/v1/chat/completions String body {model:qwen2.5-14b,messages:[{role:user,content:你好请自我介绍一下}],stream:true,max_tokens:16} long startNanos System.nanoTime() URL url new URL(endpoint) HttpURLConnection conn (HttpURLConnection) url.openConnection() conn.setRequestMethod(POST) conn.setDoOutput(true) conn.setRequestProperty(Content-Type, application/json; charsetutf-8) conn.getOutputStream().write(body.getBytes(StandardCharsets.UTF_8)) conn.getOutputStream().close() double ttftMs -1 BufferedReader reader new BufferedReader(new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8)) String line while ((line reader.readLine()) ! null) { if (line.startsWith(data:) !line.contains([DONE]) line.contains(content)) { long elapsedNanos System.nanoTime() - startNanos ttftMs elapsedNanos / 1_000_000.0 break } } reader.close() conn.disconnect() SampleResult.setSuccessful(ttftMs 0) SampleResult.setResponseMessage(TTFT ttftMs ms) SampleResult.setResponseData(ttft_ms ttftMs, StandardCharsets.UTF_8.name())注意几个细节第一SampleResult是 JSR223 Sampler 内置变量直接操作它聚合报告就能按采样结果统计第二判断line.contains(content)是为了排除第一次只返回 role 的空 delta 块避免把没有 token 内容的空包算成首 token第三max_tokens建议设小一点压测只关心 TTFT 时没必要让模型生成一大段内容。3.3 从单机压测到分布式压测时间同步与结果采集JMeter 做单机小并发比如 5 到 50 个并发没问题但一旦压到 200 个并发以上单机容易把客户端自身变成瓶颈这时很多人会上分布式压测。分布式压测里有个特别容易忽略的坑Agent 机器的系统时间如果不一致客户端侧 TTFT 的跨机汇总会引入额外误差。我踩过一次两台 Agent 系统时间差了 4 秒最后聚合出来的 TTFT P95 直接变成负数排查了半天才发现是时间同步问题。所以分布式压测前先确保所有 Agent 和 Controller 用 NTP 同步过最好在脚本里加一个前置断言检查各机时间偏差小于 100ms。还有JMeter 分布式压测默认的聚合报告只汇总最终 SampleResult像 TTFT 这种“首 token 时间”需要靠脚本把每个采样点的ttft_ms写到响应数据里再用自定义监听器提取统计。3.4 拿到 TTFT 数据后怎么看趋势JMeter 的聚合报告里会给出 Mean、P50、P90、P95 等统计但光看最终聚合不够我建议再加一个“响应时间图”监听器把 TTFT 随时间变化的曲线拉出来。你会发现非常有价值的规律并发低的时候TTFT 曲线是一条平缓直线并发爬到某个阈值后TTFT 开始周期性跳高说明服务端已经进入排队状态。这时候再去看 GPU 利用率通常已经打满或者推理引擎的 KV cache 开始频繁争抢。我自己判断服务健康度的经验是第一梯队看三个数字TTFT P50、TTFT P95、错误率。如果 P50 稳定但 P95 明显恶化说明大部分请求快但有小部分请求被排队拖死这类长尾问题往往是并发不均或偶发调度抖动比整体慢更隐蔽。4. Python 方案更灵活的 TTFT 压测脚本4.1 httpx 流式请求核心计时代码JMeter 适合做标准化压测汇报但如果你想在压测过程里自由控制请求内容、动态统计分位数、做多模型横向对比Python 方案会更顺手。我用得最顺手的组合是 httpx 加 concurrent.futureshttpx 原生支持流式请求可以一行一行读 SSE而且线程安全多个并发线程可以共用同一个 Client 实例。核心计时代码长这样import httpx import time import concurrent.futures import statistics import csv URL http://127.0.0.1:8000/v1/chat/completions HEADERS {Content-Type: application/json} BODY { model: qwen2.5-14b, messages: [{role: user, content: 请你用 200 字介绍路由器的基本工作原理。}], stream: True, max_tokens: 128, } def measure_once(client): start time.perf_counter() first_byte_ms None ttft_ms None with client.stream(POST, URL, jsonBODY, headersHEADERS, timeoutNone) as resp: first_byte_ms (time.perf_counter() - start) * 1000 for line in resp.iter_lines(): if not line: continue if line.startswith(data:) and [DONE] not in line: ttft_ms (time.perf_counter() - start) * 1000 break return { first_byte_ms: round(first_byte_ms, 2), ttft_ms: None if ttft_ms is None else round(ttft_ms, 2), } def main(concurrency32, total200): rows [] with httpx.Client(http2False) as client: with concurrent.futures.ThreadPoolExecutor(max_workersconcurrency) as pool: futures [pool.submit(measure_once, client) for _ in range(total)] for f in concurrent.futures.as_completed(futures): rows.append(f.result()) ttfts sorted([r[ttft_ms] for r in rows if r[ttft_ms] is not None]) if not ttfts: print(no valid ttft data) return def percentile(p): return ttfts[min(len(ttfts) - 1, int(len(ttfts) * p))] print(ftotal{len(ttfts)}, mean{statistics.mean(ttfts):.2f}ms, fp50{percentile(0.50):.2f}ms, p95{percentile(0.95):.2f}ms, fp99{percentile(0.99):.2f}ms, max{max(ttfts):.2f}ms) with open(ttft_result.csv, w, newline) as f: writer csv.DictWriter(f, fieldnames[first_byte_ms, ttft_ms]) writer.writeheader() writer.writerows(rows) if __name__ __main__: main(concurrency32, total200)这个脚本我一直在用time.perf_counter()在 Linux 上走的是高精度时钟比time.time()稳得多统计分位数时不会被系统时间调整干扰。first_byte_ms和ttft_ms两个字段分开存后续对账时能看出响应头和首 token 之间的空隙。4.2 多并发统计均值、P95、P99 计算脚本里的 percentile 函数是手写的比依赖 numpy 更轻量。我之所以强调 P95 和 P99是因为大模型服务在并发压力下经常出现长尾P50 只有 600ms但 P95 有 3 秒P99 能到 8 秒。如果只看均值你根本不知道有 5% 的用户在忍受 3 秒的白屏等待。这里有个经验第一次压测时把 total 设到 500concurrency 分别跑 1、8、16、32、64每个档位跑完都导出 CSV观察 TTFT 分位数随并发的变化曲线。我做过一个典型测试并发从 8 升到 16 时P50 几乎没动P99 却从 1.2 秒跳到 4.5 秒说明服务端的排队已经出现明显长尾。这种信号如果只看均值可能要并发到 64 才能察觉但那时用户体验早就崩了。4.3 请求口径控制输入长度、生成长度、连接复用Python 脚本写起来容易但口径不统一会导致数据完全没法比。我有三个必做项第一固定输入 prompt 的长度最好用同一段文本因为输入越长prefill 耗时越长TTFT 天然就大第二固定 max_tokens否则不同请求的输出长度会影响服务端调度策略第三明确连接复用策略httpx 的 Client 默认会复用连接这符合线上真实情况但如果你每次请求都 new 一个 Client测出来的 TTFT 会额外包含 TCP 握手和 TLS 握手时间数值会虚高。我见过一个同事压测时每次请求都新建连接结果 TTFT 多出 50 毫秒左右单独看也就那样可一旦堆到几百并发连接建立本身也会成为瓶颈。所以脚本里我会在同一个 Client 实例下跑全部请求并且压测前先发几个预热请求让 DNS 缓存和连接池都热起来。5. 用服务端指标对齐 TTFT别被客户端环境带偏5.1 vLLM metrics 里的 TTFT 怎么读vLLM 部署的大模型服务通常自带 Prometheus metrics 接口默认路径是/metrics。压测过程中我习惯隔一段时间拉一次数据重点看 TTFT 相关的直方图curl -s http://127.0.0.1:8000/metrics | grep time_to_first_token输出里会看到类似vllm:time_to_first_token_seconds_bucket的一串直方图桶。直方图的好处是可以直接看分布不用自己保存全量样本。比如_bucket{le1.0} 200表示有 200 个请求 TTFT 小于等于 1 秒。你只需要计算相邻桶之间的差就能还原出分位数比客户端统计更贴近引擎真实状态。这里提醒一句不同版本的 vLLM 指标名可能不一样有的用冒号分隔Prometheus 规范允许有的用下划线还有的加了模型名的 label。第一次接触时先把curl | grep ttft的结果全量看一遍确认当前版本到底叫什么再写监控脚本不要直接照抄旧命令。5.2 客户端与服务端数据对不上的校准方法客户端 TTFT 和服务端 TTFT 对不上是常态不是 bug。服务端指标不包含网络时间客户端指标覆盖 DNS、TCP、TLS、发送、等待、接收等多个环节。低并发时两者的差值基本等于网络 RTT高并发时差值会变大变大的部分往往来自网关排队或客户端连接池等待。我做了个简单的对账表每次压测后填一下场景客户端 TTFT服务端 TTFT差值判断低并发 1 并发120ms80ms40ms接近网络 RTT正常中并发 32 并发900ms850ms50ms瓶颈在引擎网络影响不大高并发 128 并发3200ms900ms2300ms上游排队严重先查网关和负载均衡如果客户端差值和网络 RTT 基本一致说明链路干净如果差值在并发升高后突然放大说明瓶颈在网关或客户端连接管理不在推理引擎。这个表我每次压测汇报都会附上能让团队快速对齐“到底是模型慢还是链路慢”的争论。5.3 一套完整的 LLM 压测观察指标体系大模型压测不能只盯 TTFT 一个数。我的压测仪表盘上固定有六块内容TTFT 的 P50/P95/P99、TPOT、每秒生成 token 数吞吐、每秒请求数QPS、错误率、GPU 利用率与显存占用。这六块缺一不可因为指标之间会互相影响TTFT 很低但 TPOT 很高说明首字快但生成慢体验属于“开始快后面便秘”TTFT 很高但 TPOT 正常说明排队和 prefill 有问题两者都高那基本是整机资源不足。有个容易被忽略的维度是输入 token 长度分布。真实业务的 prompt 长度往往不是固定值压测时至少要准备两套数据集一套是短 prompt几百 token一套是长 prompt三四千 token分别跑 TTFT 对比。长 prompt 的 prefill 时间会明显拉高 TTFT如果你只用短 prompt 压测上线后遇到长文档输入TTFT 一定会爆。6. 常见坑与排查技巧拿到 TTFT 之后的那些事6.1 客户端 TTFT 比服务端 TTFT 还小正常吗有同学压测后跑来问我客户端测出来的 TTFT 居然比服务端 metrics 里的 TTFT 还小是不是脚本写错了正常情况下客户端包含更多网络开销应该更大才对但如果差距很小甚至出现负数大概率是两个口径不同。我遇到过一次原因是服务端指标统计的是“请求进入引擎”到“生成第一个 token”的时间而我当时压测的接口前面还有一层 API 网关网关提前返回了部分响应头客户端把响应头的到达时间当成了首 token 时间。SSE 流的响应头不需要等模型生成内容就能发出去所以客户端计算出来的 TTFT 偏小。解决办法是客户端必须严格按“第一个包含 content 的 data 行”来裁切而不是按响应头或空数据块裁切。如果脚本已经按行解析了还是比服务端小那要检查两端时钟是否一致特别是有网关层的多跳架构。6.2 并发一上来 TTFT 就跳高先查这四件事并发升高后 TTFT 跳高的原因通常是四选一服务端排队、GPU 打满、KV cache 频繁驱逐、prefill 和 decode 互相抢占计算资源。我排查的顺序是固定的先看vllm:time_to_first_token_seconds在并发升高后有没有同步跳高。如果服务端 TTFT 本身也跳高问题在引擎内部。再看 GPU 利用率。如果已经 95% 以上说明算力不够要么扩容要么限制并发。然后看请求队列深度。vLLM 这类服务一般有排队上限超过后会直接拒绝或无限延后表现就是 TTFT 出现极端长尾。最后检查显存和 KV cache 状态。显存不足时会触发抢占prefill 阶段被反复打断TTFT 会非线性恶化。我遇到过最典型的情况是显存刚好卡在临界值单请求压测 TTFT 只有 300ms并发到 16 时直接飙到 6 秒。表面看是算力瓶颈实际上是 KV cache 容量不够导致频繁驱逐每个请求都在抢预留给其他请求的 cache 空间。这时候加 GPU 不划算把 max_num_seqs 调低一点反而立竿见影。6.3 输入长度和预热对 TTFT 的干扰输入长度对 TTFT 的影响几乎是线性的因为 prefill 阶段要对整个 prompt 做一次前向传播。我实测过同一个模型500 token 的 prompt 和 4000 token 的 promptTTFT 能从 200ms 涨到 1.8 秒左右。所以压测报告里必须标注输入长度否则两个团队拿不同长度的压测数据互相 PK完全没有意义。预热也是个大坑。大模型服务刚启动时CUDA kernel 还没有加载权重还没有完全进显存前几个请求的 TTFT 会高出正常值很多有时能差 5 倍以上。我在压测脚本里固定先发 10 个预热请求等 TTFT 稳定后再开始正式统计。这个预热过程不计入结果也不参与分位数计算否则你会在报告里看到一个莫名其妙的“初始慢请求”长尾。6.4 请求 ID 贯通才是排查 TTFT 抖动的最优路径最后一个建议和压测本身无关但对排查问题特别有效压测时让脚本给每个请求生成一个唯一 request_id通过请求头传给服务端服务端日志里也记录这个 id。一旦发现 TTFT 抖动把客户端时间、服务端时间、网关时间三条日志串起来就能精确看出是哪个环节把时间吃掉了。我曾经排查过一个 500ms 的 TTFT 抖动客户端数据一切正常服务端 metrics 也正常最后靠 request_id 把日志串起来才发现是网关层限流器偶发触发请求在网关里等了一会儿才放行。没有 request_id这种偶发性问题很难定位。现在我的压测脚本默认不删这个逻辑压测即 trace省了很多扯皮时间。我个人在实际操作中的体会是TTFT 这个指标最好固化到日常回归里每次升级模型权重、改推理框架参数、调网关策略都跑一组固定并发、固定 prompt、固定输出长度的压测把 TTFT 的 P50 和 P95 存下来对比。很多人压测只是上线前临时做一次平时框架升级完全凭感觉结果出了问题才回头查非常被动。最后分享一个小技巧压测脚本里同时打印“首包响应头时间”和“首 token 时间”两者之间的差值能暴露很多隐藏问题。正常情况下响应头会先到首 token 比响应头晚几毫秒到几百毫秒不等。如果首 token 时间和响应头时间几乎一样说明模型生成很快瓶颈在网络如果两者差值特别大说明 prefill 慢或者框架在首块数据上做了缓冲。这一招在排查跨地域压测时尤其好用能帮你快速区分网络延迟和推理延迟。