说实话，我一开始做模型延迟对比的时候，脑子里其实只有一根筋——拿个秒表，发个请求，看多久回。后来被现实打脸打多了才发现，延迟这事儿根本不是一个数字能讲清楚的。你跟产品经理聊延迟，他关心的是用户点完发送之后多久看到第一个字蹦出来。你跟运维聊延迟，他盯着的是GPU利用率跟队列积压。你跟老板汇报，他想知道的是这个月API账单为什么涨了。同一个"慢"字，背后站着的其实是三套完全不同的语言体系。
我习惯把响应延迟拆成三层来看。最外面那层是用户感知到的端到端时间，从点击到最后一个Token渲染完。中间那层是首Token延迟，TTFT，也就是请求发出去到第一个字回来之间的空白。最里面那层是吞吐量，单位时间内系统能处理多少Token、多少个请求。这三者之间不是简单的加减关系。你首Token压得极低，吞吐量上不去，高并发一来全堵在门口。你吞吐量刷得漂亮，用户盯着空白屏幕等三秒，体验照样崩。我见过太多团队只盯一个指标做优化，最后要么服务器烧钱烧到财务来找，要么用户流失率悄悄爬上去没人发现。
这一章我想把"测什么、为什么测、怎么测才不算白测"这件事摊开讲清楚。不是给你一套标准答案，而是把我踩过的坑、绕过的弯路摆出来，你自己对着业务场景挑着用。
1.1 从用户体验到系统性能：响应延迟、首Token延迟与吞吐量的关系界定
我先讲个真事。去年帮一个做AI写作工具的朋友看他们的延迟问题，他们后台监控面板上显示P95延迟是1.2秒，团队觉得还行，没到不可接受的地步。但我自己去用他们产品，输入一段话，等第一个字出来，明显感觉有卡顿感，那种感觉像什么，像你在餐厅点完菜，服务员说马上来，然后你盯着空桌子等了半天。后来一查，他们的1.2秒是端到端总时长，首Token延迟其实占了800毫秒，后面生成速度快，总时长被拉低了。用户对"等第一个字"的耐心，跟对"等全部写完"的耐心，完全不是一个量级。这个区别不搞清楚，优化方向就是歪的。
首Token延迟这东西，本质上测的是系统"启动成本"。模型要加载、上下文要编码、KV缓存要预热、请求要排队过调度器。这些环节里任何一个卡住，用户感受到的就是那个令人焦虑的空白期。我通常会把TTFT单独拎出来看，尤其是流式输出的场景，TTFT几乎决定了用户对"快不快"的第一印象。吞吐量测的是另一回事，它衡量系统在单位时间内的"消化能力"，Tokens每秒也好，请求每秒也好，反映的是资源利用效率和并发承载上限。这两者有时候是矛盾的，你把批处理尺寸调大，吞吐上去了，首Token延迟跟着涨，因为请求得等着凑批。
我的经验是，别试图用一个综合指标把这三层糊在一起。端到端延迟适合跟业务方对齐SLA，首Token延迟适合指导推理引擎调优，吞吐量适合做容量规划和成本核算。三个指标各看各的，交叉着看，才能拼出完整的性能画像。我现在做对比测试，报告里一定把这三个数分开列，谁也不许藏在平均值后面。
1.2 对比测试的目标设定：模型选型、API服务评估与容量规划
测延迟之前，我一般会先问自己一个问题：这次测完，我要拿这个数据做什么决定？这个问题听起来废话，但我见过太多测试做完，报告写了几十页，最后没人知道该拿它干嘛。目标不同，测试设计完全不一样。
如果是模型选型，比如你在几个开源模型和闭源API之间纠结，那测试重点应该放在同等工作负载下的延迟分布，尤其是P95和P99，别只看平均值。平均值这东西太会骗人了，一个模型平均200毫秒，但偶尔给你来个5秒的毛刺，线上体验就是灾难。选型阶段我还会特别关注长上下文场景下的延迟退化曲线，有些模型短文本飞快，上下文一拉到8K、16K，首Token延迟直接翻倍，这种坑不提前测出来，上线就是事故。
如果是评估API服务商，比如你在几家云厂商的推理服务之间做对比，那要测的东西更偏"服务品质"。同样一个模型，不同厂商的调度策略、限流机制、网络链路都不一样。我会模拟真实并发模式去打，看它在压力下的延迟稳定性，看它限流触发后的表现，看它流式输出有没有断流或者卡顿。这种测试有点像试驾，参数表都好看，真开起来才知道底盘调得怎么样。
容量规划又是另一套逻辑。这时候你关心的不是"谁快谁慢"，而是"我这套系统能扛住多少量，什么时候该扩容"。我会做阶梯式压测，逐步加并发，观察延迟拐点在哪里，吞吐量什么时候饱和。这个拐点数据比任何单点延迟数字都值钱，它直接告诉你预算该花在哪儿。目标定清楚了，测试方案自然就收敛了，不会东测一下西测一下，最后攒一堆用不上的数据。
1.3 测试范围与基准设计原则：可复现、公平性与业务场景映射
我最怕看到的测试报告，是那种"某模型比某模型快30%"的结论，然后底下什么测试条件都没写。这种数字毫无意义，甚至有害。不同的prompt长度、不同的并发数、不同的硬件环境、不同的采样参数，都能让结果天差地别。可复现是底线，我要求自己每次测试都把环境配置、请求构造、采样参数、测试时间窗口全部记录下来，换个人拿着这份记录能跑出一模一样的结果。做不到这一点，数据就是一次性的，没法复盘，没法对比，没法迭代。
公平性这事儿更微妙。你不能拿A模型在独占GPU上跑的延迟，去比B模型在共享集群上跑的延迟，然后说A比B快。要比就比同等条件下的表现，硬件规格对齐、并发模式对齐、输入分布对齐。我甚至会控制测试的时间段，避开业务高峰，减少外部干扰。有些API服务在凌晨和晚高峰的表现能差出一截，你不控制变量，测出来的就是噪声。
业务场景映射是我花心思最多的地方。实验室里跑benchmark，输入都是规规矩矩的短句子，真实业务里用户扔进来的可能是三千字的产品文档、带表格的PDF提取文本、或者一段夹杂表情符号的聊天记录。输入长度分布、输出长度分布、请求到达模式，这些都得尽量贴近真实。我现在做测试，会先从线上日志里采样一批真实请求做模板，构造测试集的时候按真实分布来配比。短请求占多少、长请求占多少、流式和非流式各占多少，都有讲究。测试环境跟生产环境差距越大，测出来的结论越容易误导决策。这一块偷懒，后面选型选错、容量估错，代价可比多花几天做测试大多了。
我干过一件挺蠢的事。早两年测一批模型的延迟，我挑了个风和日丽的下午，用一台闲置的A100，输入清一色两百字的小作文，串行发请求，测完一看数据，心里美得不行，觉得这几个模型性能都挺能打。结果上线第二天就被打脸，用户一上来就是几千字的长文档，并发量一冲，首Token延迟直接飙到七八秒。后来我才明白，测试条件跟真实负载之间差着一条马里亚纳海沟。这一章我把自己在首Token延迟和吞吐量这两个维度上摔过的跟头、摸出来的门道摆一摆，你挑着有用的拿。
2.1 首Token延迟测试：冷启动、长上下文与并发条件下的测量方法
冷启动这块我吃过暗亏。有一次对比三个推理API服务商，我习惯性地先拿一个请求去探活，等了几秒拿到回应，才慢悠悠开始正式测试。后来把日志翻出来细看，发现第一个请求的延迟是后续请求的十几倍。这就是冷启动的威力——模型权重加载、显存分配、内核预热，这些一次性开销全压在那第一个倒霉的请求上。你测首Token延迟，要是不单独把冷启动拎出来测，测出来的全是热态数据，看着漂亮，但用户第一次点进来就撞上冷启动墙，感受完全是另一回事。我现在做对比测试，会专门设计一个冷启动组：清空缓存、等待足够长的静默期、发单个请求、记录TTFT，重复几轮取分布。有些服务商在冷启动上做了预加载和保活，数据会好看不少，这种差异你不单独测就根本看不出来。
长上下文对首Token延迟的摧残，怎么强调都不过分。短prompt的时候，输入编码那点计算量可以忽略，瓶颈主要在调度和推理启动。上下文长度一过四千token，编码时间就开始线性甚至超线性地往上爬。我测过一个开源模型，2K上下文TTFT是300毫秒，8K直接干到900，32K的时候1.8秒都打不住。关键这还不只是编码的事，长上下文意味着KV缓存占用的显存更多，如果服务端没有做好分页管理，显存碎片一多，新请求排队等显存释放的时间也会算进TTFT里。我测长上下文TTFT的习惯是分桶测：2K、4K、8K、16K、32K各准备一组请求，每组至少几十条，看延迟曲线在哪里开始抬头。那个抬头的拐点，往往就是选型和容量规划里最值钱的数字。
并发条件下的首Token延迟测量，是另一个容易翻车的区域。你单线程发请求，测出来的是理想状态下的TTFT。真实线上环境，几十上百个请求同时挤进来，调度器怎么排、批处理怎么拼、优先级怎么给，全都会让TTFT分布发生形变。我一般的做法是阶梯式加并发，从1路开始，逐步加到5路、10路、20路、50路，每个并发档位跑够样本量，记录TTFT的P50、P95、P99。别只看平均值，平均值在并发场景下几乎没有参考价值。有些服务在低并发时TTFT很稳，一到某个并发阈值，P99直接起飞，那个阈值就是系统的实际容量边界。我还会同时记录错误率和超时率，因为有些服务在过载时不是变慢，而是直接拒绝或者断开，这种表现也得算进TTFT的对比里，光看成功请求的延迟数字会掩盖掉一部分真相。
2.2 吞吐量对比测试：Tokens每秒、请求吞吐与并发扩展性分析
Tokens每秒这个指标，说简单也简单，输出总token数除以总耗时，但怎么统计其实挺有讲究。我见过有人把输入token和输出token加在一起除以端到端时间，算出来的数字挺好看，但跟你实际关心的生成速度是两码事。输入token的处理是并行的，输出token是自回归一个个蹦出来的，这两种吞吐的物理意义完全不同。我测的时候会分开记：输入编码吞吐（tokens per second on prefill）和输出生成吞吐（tokens per second on decode）。输出生成吞吐更能反映推理引擎的解码效率，跟用户感知的生成快慢直接挂钩。输入编码吞吐则跟长文本场景的响应能力相关。两个数分开列，谁也不糊弄谁。
请求吞吐这个维度，我吃过只看token吞吐的亏。有个场景是大量短请求、每个请求输出也就几十个token，这时候token吞吐看着不高，但请求吞吐其实很关键，因为每个请求都有固定的调度开销，请求数量一多，调度器本身就成瓶颈了。我测请求吞吐的时候会固定输出长度分布，短输出和长输出各测一组，短输出组看的是系统每秒能处理多少个请求，长输出组看的是系统每秒能吐多少token。这两组数据合起来看，才大概能画出系统的处理能力轮廓。有些API服务在短请求场景下表现很好，内部做了请求合并和快速通道，但长输出场景下解码速度一般，这种差异得靠分开测才能暴露出来。
并发扩展性分析是我认为最能指导容量规划的实验。思路很简单：并发数从低到高逐步加，观察吞吐量怎么涨、延迟怎么变。理想的扩展曲线是吞吐随并发线性上升，到某个点开始趋平，再往上加并发吞吐不升反降，延迟飙升。那个趋平的拐点就是系统的最佳工作点。我测过一家云厂商的推理服务，并发1到10的时候吞吐几乎线性涨，到15以后开始抖动，20的时候吞吐反而掉下来，P99延迟翻了四倍。这个曲线一画出来，你心里就有数了：生产环境并发控制在什么范围、扩容阈值设在哪儿、预算该留多少余量。对比多个服务商的时候，把各自的扩展曲线叠在一张图上，谁的弹性好谁的上限高一目了然。这比任何单点吞吐数字都有说服力。
2.3 端到端响应延迟拆解：网络、排队、推理与流式输出影响
端到端延迟这个数，看起来最直观，拆起来最费劲。用户从点击发送到看到最后一个字渲染完，中间经过的环节比我妈的毛线团还乱。我习惯把它拆成四段：网络往返、服务端排队、推理计算、流式传输开销。网络往返这段相对好测，用curl发个空请求或者ping一下端点，大概能估出来，跨地域调用的时候这段能占到几百毫秒，不能忽略。服务端排队这段是最隐蔽的，你从客户端只能看到请求发出去到第一个字节回来的时间，但这里面排队占了多少、推理启动占了多少，得靠服务端指标或者多维度测试来推断。我会在同一个服务商的不同时间段、不同并发档位下反复测，用差值来估算排队分量的变化趋势。
推理计算这部分，拆解的关键是把首Token延迟和后续token的生成间隔分开看。TTFT对应的是预填充阶段，后续每个token之间的间隔对应解码阶段。我用流式接口逐token打时间戳，算平均token间隔和P95间隔，这两个数能反映解码引擎的稳定性和批处理策略。有些服务TTFT一般，但解码间隔很稳定，用户体验反而比TTFT快但解码抖动的服务更好。流式输出本身会引入额外的开销，比如SSE连接建立、chunk编码、客户端渲染节奏，这些在对比测试里也得考虑进去。我遇到过流式接口每个chunk之间强制等一个固定间隔的实现，吞吐数字看着还行，但用户实际感受到的生成速度被这个间隔拖慢了，这种坑不拆开看根本发现不了。
流式输出对延迟感知的影响，我觉得值得单独拎出来说。同样是首Token两秒、总生成十秒的服务，流式和非流式的用户感受天差地别。流式用户两秒后就开始看到字往外蹦，注意力被抓住了，后续等待感大幅降低。非流式用户盯着空白屏幕等十秒，心态早就崩了。我测端到端延迟的时候，会把流式和非流式分开跑，流式场景重点看TTFT和token间隔的分布，非流式场景重点看总时长。报告里这两组数据并列呈现，业务方自己就能判断该怎么选。很多团队在选型时只测非流式的总延迟，忽略了流式场景下的首Token延迟，等上线开了流式功能才发现体验不对，回头再补测，时间和预算都浪费了。
2.4 多模型与多API服务对比矩阵：指标口径、统计方法与结果解读
做多模型多服务对比，第一件要命的事是指标口径不统一。A家API文档说延迟是P50，B家说延迟是平均值，C家说延迟是P99，你直接拿来比，比出来的结论纯属自欺欺人。我吃过这个亏，早期做对比报告，把不同来源的数据直接堆在一起，被老板问了一句“这些数是一回事吗”当场噎住。后来我定了个规矩：所有参与对比的对象，必须用同一套测试客户端、同一组请求样本、同一个时间段跑，原始数据自己采，不拿厂商给的数字充数。延迟统一报P50、P95、P99，吞吐统一报tokens每秒和请求每秒，统计时间窗口统一，错误率和超时率单独列。口径对齐了，后面的对比才有意义。
统计方法这块我踩过的坑也不少。样本量不够是最常见的毛病，一个模型跑十几条请求就算平均延迟，置信区间宽得能跑马，稍微有点毛刺就把均值带偏。我现在要求每组测试至少几百条有效样本，延迟分布用分位数来呈现，不迷信均值。还有预热期的处理，前几十条请求受冷启动和缓存未命中影响，我会单独标出来，不计入稳态统计。不同时间段的波动也不能忽略，早高峰和深夜的延迟能差出不少，我通常选业务低峰期做测试，减少外部干扰，但也会在高峰期补测一轮，看看压力下的表现。这些统计细节写进报告里，别人才知道你测的到底是什么东西。
结果解读是最考验经验的部分。数据摆出来之后，怎么下结论、怎么给建议，比测试本身还难。我的原则是：不追求一个全能冠军，而是看谁在特定场景下更合适。有的模型在低并发下TTFT最快，但扩展性一般；有的服务商吞吐上限高，但冷启动慢；有的流式体验好，但长上下文退化明显。对比矩阵里我会按场景分列：短文本对话场景看哪个、长文档处理场景看哪个、高并发业务看哪个。每个场景给一个推荐排序，附上关键数据支撑。我还会把测试中的异常点和不确定性写清楚，比如某服务在测试期间出现过一次限流、某模型的P99受偶发毛刺影响偏大。数据是死的，场景是活的，把数据往场景里套，结论才能站得住脚。这一章讲的这些维度，你拧在一起看，基本就能搭出一个够用的对比框架了。
第2章把该测哪些维度聊透了，这一章聊怎么测。说实话我一开始以为工具是现成的，打开GitHub搜一圈，发现能直接拿来测LLM API延迟的成熟工具寥寥无几。通用压测框架一大堆，丢到LLM场景里都有点水土不服——它们不懂流式SSE，不知道怎么从chunk里抠出首Token时间戳，更不会按token数统计解码速度。我在不同项目里折腾过六七套工具组合，踩过的坑不比测模型本身少。这一章就把我这几年攒下来的工具清单和落地流程摆开，你看着挑。
3.1 主流基准测试工具与框架推荐：压测、监控与延迟剖析能力对比
先说通用压测工具这一档。Locust我用得比较多，Python写的，脚本灵活，想改请求体、想按token长度分桶、想在流式响应里打时间戳，都能自己动手改。它自带的分布式模式和Web UI对做阶梯并发很方便，缺点是高并发时Python的GIL会让客户端自己先成为瓶颈，几千并发以上就不太够看了。k6是另一个我常用的，Go写的性能好，脚本用JS，配合场景配置做阶梯加压很顺手，社区也有LLM相关的扩展。wrk2适合做固定速率下的延迟测试，能排除协调遗漏（coordinated omission）的干扰，但它不太适合测流式接口。JMeter我早年用过，配置界面化、报表全，但脚本维护成本高，测LLM这种需要精细解析响应的场景有点笨重。
LLM专用工具这两年开始多了起来。Anyscale出的LLMPerf我最早接触，专门针对LLM API设计，支持并发扫描、首Token延迟、tokens每秒这些指标，配置也简单，输入输出长度、并发数、请求总数几个参数就能跑。vLLM仓库里自带的benchmark_serving脚本也很实用，尤其是自建推理服务的时候，能直接压到服务端，还支持输出详细的latency breakdown。NVIDIA的GenAI-Perf基于Triton客户端构建，做多模型多端点的对比挺方便，指标口径也统一。这些专用工具的好处是开箱即用，坑在于灵活性，比如你想自定义请求模板、想模拟特定的流式读取节奏、想混入错误请求做健壮性测试，往往还得回去改源码。
延迟剖析这块，光靠压测工具不够，得配合可观测性工具一起看。我在自建服务上一般用Prometheus抓vLLM或TGI的指标，队列长度、KV缓存占用、批处理大小这些都能看到，配合Grafana画出来，客户端看到的延迟波动就能对上服务端的内部状态。用第三方API服务的时候，我会在客户端侧把每个请求的时间戳全部落盘，再用OpenLLMetry或者Langfuse这类工具做追踪，能把一次请求里网络、排队、首Token、解码各段拆开。Helicone用起来门槛低，改个base URL就能记录请求和延迟，做快速对比很方便。Arize Phoenix适合做更深入的trace分析。这些工具各管一段，谁也替代不了谁。
3.2 测试工具选型与组合方案：从单机脚本到可观测性平台
小团队或者刚起步做对比测试，我建议先别上重型工具，一个单机脚本就够。我自己最常用的组合是Python的asyncio加httpx，写个一百多行的脚本，支持流式请求、逐chunk打时间戳、并发控制、结果落JSONL。为什么不用现成的？因为对比测试的核心是控制变量和可复现，现成工具的参数黑盒太多，出了怪数据你都不知道是客户端的问题还是服务端的问题。自己写的脚本每一行都清楚，想加冷启动探测、想换请求模板、想按不同上下文长度分桶，改几行就行。这个阶段的重点是快速迭代和口径统一，不是压出多高的并发。
并发规模上去了，比如要测几百上千并发下的扩展性，单机脚本撑不住，就该上Locust或k6的分布式模式了。我一般的做法是拿一台独立的压测机跑Locust master，多台worker分摊负载，压测机的网络和CPU要单独监控，避免客户端成为瓶颈。如果预算允许，云厂商的压测服务也能用，弹性扩容省事，数据采集和报表也现成。这一层的工具选型关键看两点：能不能精确控制请求发送速率、能不能把延迟分位数和错误率完整导出。前者决定了测试的公平性，后者决定了报告的可信度。
再往上走，做长期的、常态化的对比监控，就得搭一套可观测性组合了。我的标准配置是：压测端固定一套脚本按计划定时跑，原始数据落到时序数据库；服务端接Prometheus抓内部指标；链路层用OpenTelemetry做追踪，把客户端时间戳和服务端span对起来。Langfuse和Helicone这类工具可以作为补充，记录请求内容、token用量、延迟分布，方便业务方自己看。这套东西搭起来费劲，但搭好之后，模型版本更新、服务商调价、线上出现抖动，你都能第一时间看到数据变化，不用每次都从零重启一轮测试。
3.3 对比测试实施流程与报告模板：环境控制、数据采集与结论呈现
环境控制这块我有过教训。有次对比两家API，结果A家的数据明显好于B家，我差点下结论，回头一查发现A家测试时客户端在同地域机房，B家走的是公网跨省，网络往返就差了上百毫秒。从那以后我定了规矩：所有对比对象必须从同一个客户端、同一个网络位置发起，测试时间窗尽量选在同一时段，客户端缓存、连接池、DNS解析全部预热，每组测试开始前清空本地状态。涉及自建服务的，模型加载方式、显存配置、批处理参数都要记录在案，不然过两周你自己都复现不出来。
数据采集我要求做到“原始可追溯”。每个请求落一条记录：请求ID、发送时间、首字节时间、首Token时间、最后Token时间、输入token数、输出token数、HTTP状态码、错误类型。流式接口用逐chunk读取，时间戳精度到毫秒。样本量按分位数报告的需求来定，关注P99就至少跑几百条，关注P999就得上千。错误请求单独归类，限流、超时、服务端5xx、连接断开分开统计，别混在成功请求的延迟里。这些原始数据我会留档，报告里呈现的是聚合结果，但有人质疑某个数字的时候，随时能翻回原始记录。
报告模板我习惯用“结论先行”的结构。开头一页把场景和推荐结论摆出来：短对话场景推荐哪家、长文档场景推荐哪家、高并发场景推荐哪家，每个推荐后附两三个关键数字。中间部分按测试维度展开，每个维度给P50、P95、P99三档，吞吐给tokens每秒和请求每秒两个口径，配扩展性曲线图。后面一定要留一节写“测试局限与不确定性”：某个服务商测试期间出现过一次限流、某个模型的P99受单次毛刺影响偏大、网络环境跟生产不完全一致，这些都得写清楚。最后附上完整的测试环境说明和参数配置，别人想复现随时能照着做。
3.4 常见误区与优化建议：避免指标失真并指导模型API选型
第一个坑是拿厂商文档里的延迟数字直接横向对比。我见过太多报告这么干，A家写“平均延迟200ms”，B家写“P99小于1秒”，往一张表里一放，结论就出来了。这些数字的测试条件、请求长度、并发状态你一概不知，比了等于没比。我的建议是：厂商数字只做参考，真要对比，全部自己测，用同一套客户端、同一组样本。第二个坑是客户端自己成了瓶颈。有一次我测一个高吞吐服务，测出来吞吐怎么都上不去，排查半天发现是压测机的网卡打满了，客户端先跪了。测之前先压一遍客户端自己，用mock端点跑满并发，看看客户端的CPU、内存、连接数能撑到什么量级，留足余量再正式开测。
连接复用和TLS握手是另一个容易被忽略的地方。每个请求都新建HTTPS连接的话，握手开销会算进延迟里，短请求场景下这个开销能占到三成以上。我一般测两组：一组强制复用连接池，模拟生产环境的长连接；一组每次新建连接，看握手带来的额外开销。两组数据分开报，业务方按自己的调用模式选。测试数据单一也是常见问题，全用两百字短prompt测出来的结论，套到长文档场景上就是灾难，按实际业务分布设计请求样本，长短混合、并发混合，测出来的数才有代表性。
最后一条建议是把测试常态化，别当成一次性任务。模型在更新、服务商在扩容、你的业务量在增长，上个月测出来的最佳选择，这个月可能就变了。我现在的做法是每周固定跑一轮基准测试，数据自动入库，做趋势图。某个服务商的P95连续两周上涨，或者新版本上线后首Token延迟跳变，趋势图上一眼就能看出来。选型决策不靠拍脑袋，靠的是持续积累的数据。工具和流程搭好之后，这部分维护成本其实很低，但带来的决策质量提升是实打实的。
