说到这个延迟分布的问题，我最近正好在搞一个类似的场景，感触挺深的。用Locust做AI API压测，光看平均QPS确实容易踩坑，因为一旦混入几个长文本请求，平均延迟被拉高，但实际上大部分短请求响应很快，这时候看P99甚至P999才能发现问题。

我自己的做法是在Locust里自定义一个client，把请求的输入长度、模型推理时间、显存占用这些指标都打出来，然后配合Grafana看实时曲线。比如同样是并发50，短文本的P99可能才200ms，但长文本直接飙到5s，这时候如果只看QPS，可能还觉得系统扛得住，实际上长文本请求已经占满了GPU的算力，短文本都在排队。

另外你说的显存资源竞争，我补充一个坑：很多AI服务为了省显存，会做动态batch，但Locust默认的请求是独立的，不会模拟batch场景下的排队效应。我后来是在请求里加了一个随机sleep，模拟用户思考时间，这样反而更接近真实情况。不然并发一高，GPU显存分配不过来，直接OOM，但Locust那边显示QPS还挺正常的。

想问一下，你们在实际压测中是怎么处理长文本和短文本混合场景的？是分两个task跑，还是在同一个task里随机生成不同长度的输入？我试过后者，但结果很难拆开分析。

看了你的分析，确实点醒我了。我之前用Locust测过几个AI API，基本就是按Web那套流程走——配个用户数、设个等待时间，最后盯着QPS和平均响应时间看，完全没想过延迟分布的问题。你说的响应时间非对称性，我深有体会，同一个模型，输入一段代码和输入一篇论文，返回时间能差出好几秒，但测试脚本里根本没区分这种场景。

我有个实际问题想请教：你在用Locust压测AI服务时，是怎么模拟不同输入长度的？是直接写死几种固定长度的文本，还是动态生成随机长度的请求？我试过后者，但结果波动特别大，根本分不清是模型本身的问题还是测试脚本的问题。另外，你提到显存/算力竞争，这个在Locust里有什么好的监控办法吗？我平时只能靠nvidia-smi手动看，没法跟请求日志对上时间戳，感觉很难定位瓶颈到底在哪。

还有一个点想跟你确认——你说的请求内容相关性，是不是意味着压测时需要按实际业务场景来分层设计？比如先跑一批短文本，再跑一批长文本，而不是混在一起测？我最近在测一个文档摘要API，发现混着测的时候，短文本请求老是排队等长文本释放资源，这个现象正常吗？

你这帖子我太有共鸣了，尤其是“响应时间非对称性”这点。之前我们压测一个翻译模型，短句几十毫秒，长文本直接飙到十几秒，用Locust默认的统计方式一看，平均延迟还行，但p99惨不忍睹。后来才发现，那些长尾请求把整个服务的资源池给堵死了，短请求反而跟着遭殃。

关于你提到的显存竞争，我补充一个坑：Locust的并发模型是协程，但AI服务底层通常用多进程或多线程处理GPU请求，如果压测时没控制好请求的到达分布，很容易出现“瞬时洪峰”——比如几百个请求同时挤进来，GPU显存直接爆掉，然后所有请求都返回503，QPS瞬间归零。我现在的做法是在Locust里加一个think_time，模拟用户思考间隔，让请求间隔均匀一点，同时配合Prometheus监控GPU的显存利用率和算力利用率，比单看QPS靠谱太多。

另外，你帖子没写完，我想接着问：对于“请求内容相关性”，你是怎么在Locust里模拟不同输入长度的？是写死几个固定模板，还是用随机生成器？我试过用faker生成文本，但发现生成的随机文本语义不连贯，模型推理时的计算路径和真实用户请求差别挺大，感觉不够真实。有没有更好的思路？

看到这个帖子，我得先给楼主点个赞——确实戳中了很多团队在压测AI API时的认知盲区。我自己在三个不同的AI项目里踩过类似的坑，包括一个面向C端的聊天机器人和一个企业内部的知识库检索增强生成服务。说实话，如果只是把Locust当成一个高级版的curl来用，那测出来的数据基本只能用来应付PPT，真正上线后该崩还是崩。

关于响应时间非对称性这一点，我想补充一个更极端的案例。去年我们压测一个基于Llama 2-13B的文本生成服务，输入长度从100 tokens到4000 tokens不等。在固定并发数50的情况下，短输入的P50延迟只有120ms，但长输入的P50直接飙到2.8秒。更可怕的是，当短输入和长输入混合发送时，短输入的P99延迟也会被拖到1秒以上。这是因为GPU的算力调度是FIFO的，一个长请求占着计算单元，后面的短请求只能排队。所以单纯看平均延迟，你根本不知道是短请求被拖累了，还是长请求本身慢。我后来在Locust的测试脚本里加了一个参数化输入长度分布的逻辑，比如模拟真实用户场景中80%的请求是短文本、20%是长文本，然后分别记录不同分组的延迟指标。这样才能真正反映用户体验。

显存碎片化的问题，楼主提到连续压测30分钟后延迟升高，我完全遇到过类似的情况，而且比这个更诡异。有一次我们压测一个基于vLLM部署的模型，刚开始200并发时P99延迟稳定在800ms左右，但跑了大概15分钟之后，P99开始缓慢爬升，到40分钟时已经到1.5秒，而QPS反而下降了20%。当时排查了半天，发现vLLM的显存管理策略虽然比原生Transformers要好，但在长时间高并发下，显存中会积累大量未被及时回收的KV cache碎片。特别是一些变长输入，每次推理分配的显存块大小不一，导致后续请求分配到的不连续显存段，访问延迟增加。解决方案有两个方向：一是定时重启worker，比如每30分钟做一次优雅重启，但这对在线服务不友好；二是在部署框架层面开启显存整理功能，比如Triton Inference Server的显存池化策略，或者vLLM的prefix caching配合显存defragmentation。我们最后选择了后者，配合动态batch size调整，把连续压测8小时的延迟波动控制在了10%以内。

关于失败率随并发数变化的曲线，我觉得比QPS更能暴露问题。我见过一个典型的案例——某团队压测一个基于LoRA微调的Stable Diffusion服务，并发数从10增加到30时，QPS线性增长，看起来很不错。但并发数到40时，失败率突然从0%跳到15%，而且失败的都是显存不足导致的OOM错误。原因很简单，每个LoRA adapter需要额外加载到显存，当并发请求数超过GPU显存容量的1/N时，新的请求就无法被调度。如果你只看QPS曲线，可能会得出“系统能支撑30并发”的结论，但实际上30并发时显存利用率已经接近95%，稍微遇到一个输入尺寸异常的请求就会触发OOM。所以我在压测报告里通常会画一张图：横坐标是并发数，纵坐标是成功QPS和失败率的双轴图，并且标注出显存和GPU利用率的拐点。这样团队一眼就能看出真正的安全并发阈值在哪里。

楼主提到的“负载特征感知”测试方案，我非常认同。而且我想进一步说，这种测试方案不能只在压测阶段做，应该贯穿到整个发布流程中。比如我们在CI/CD pipeline里集成了一个基于Locust的混沌测试套件，它不只是发固定比例的长短文本，还会随机混入一些极端情况：比如空输入、超长输入（超过模型最大上下文窗口）、带特殊字符的prompt、以及需要大量推理步骤的复杂任务（比如数学推理或代码生成）。这些极端情况在线上虽然出现概率低，但一旦出现，往往会导致整个推理实例的延迟雪崩。我们曾因为一个用户输入了10万tokens的PDF内容（虽然模型上下文窗口只有8K），导致推理服务花了几十秒做tokenization，后续所有请求都被阻塞。后来我们加了输入长度检测和前置截断逻辑，才避免了这个问题。

另外，我想提一个很多人忽略的点：AI API的压测不能只看服务端指标，还要关注客户端超时和重试策略的交互。比如你用Locust压测一个OpenAI兼容接口，如果服务端偶尔返回503或429，客户端如果默认重试，那实际打到服务端的请求数会远超你设置的并发数。我见过一个项目，Locust设置了100并发，但因为客户端重试逻辑写成了指数退避加无限重试，在服务端出现短暂高延迟时，重试请求叠加，实际并发达到了300以上，导致服务端彻底崩溃。所以压测时一定要在同一个测试脚本里模拟客户端的合理超时和重试行为，否则测出来的数据是失真的。

最后聊一个行业趋势的观察。随着多模态模型和长上下文窗口（比如128K甚至1M tokens）的普及，传统的基于请求数的压测模型基本失效了。因为你没法用一个固定的“请求”概念来衡量负载——一个请求可能是10个token的文本，也可能是1000x1000像素的图片加10万tokens的文档。我最近在实验一种基于“计算等价单位”的压测方法，比如把一次推理的浮点运算次数（FLOPs）作为负载单位，然后通过输入输出长度和模型参数量来估算每个请求的FLOPs。这样压测时，我们可以设定目标总FLOPs/s，而不是目标QPS。虽然实现起来复杂一些，但能更准确地反映系统在不同负载特征下的真实吞吐能力。比如一个1.5B参数的模型，处理100 tokens输入生成100 tokens输出大概需要多少FLOPs，而处理1000 tokens输入生成1000 tokens输出需要多少，然后按比例分配压测流量。这样比单纯随机发请求要科学得多。

总的来说，AI服务的压测已经从“能不能撑住”进化到了“在什么负载特征下能撑住”的阶段。楼主提到的显存碎片化、延迟分布、负载特征感知，都是这个新阶段的核心问题。希望更多人能意识到，测AI API不是在测一个黑盒，而是在测一个包含显存管理、计算调度、推理框架、模型特性和客户端行为等多层因素的复杂系统。只有把这些因素都考虑进来，压测结果才能真正指导生产环境的容量规划和故障预防。

这个帖子说到点子上了。我最近刚好在调一个视觉模型的API，短文本请求20ms搞定，长文档一上来直接飙到800ms，用locust默认的统计方式根本看不出这种波动。另外显存竞争这块确实头疼，我们后来是自己写了个小插件，在locust里埋了nvidia-smi的监控，发现并发一上去显存碎片化特别严重，导致部分请求直接OOM。你后面是怎么处理请求内容相关性这个问题的？是预设了几类典型payload，还是动态生成的？

说实话，我最近也在折腾这个，用Locust压自己搭的一个文本生成模型，一开始也掉进QPS的坑里了。跑出来数据挺漂亮，结果一上线，用户反馈说卡得要死，排查半天，发现是长文本请求把显存占满了，短请求全在排队，延迟直接爆炸。

你提的这三点太准了。特别是响应时间非对称性，我这边实测过，同一个模型，输入128 token和输入2048 token，p99延迟能差出5倍。用Locust默认的统计方式，平均延迟根本看不出问题，反倒是画延迟分布的热力图或者百分位图更管用。我现在都是跑完压测先看p90和p99，再按请求长度分段看，才能看出瓶颈到底在哪。

还有个坑，就是并发上去之后，GPU的显存碎片化，Locust那个默认的响应时间监控根本抓不到这种隐性资源竞争。我后来加了自定义监听，把nvidia-smi的显存占用和温度也打到时序库里，再跟请求日志做关联，才发现某些模型实例在并发10的时候还能扛，到15就开始频繁OOM重启，延迟曲线直接锯齿状。

想问下，你那边有没有试过用Locust结合自定义的请求长度分布来模拟真实流量？比如把短文本和长文本按一定比例混着发，我试了几次，发现这样压出来的结果比均匀分布或者纯短文本要准得多，但配置起来挺麻烦的，不知道有没有现成的插件或者思路能简化这个流程。

正想补一句，我踩过的坑是：光靠Locust默认的统计方式根本看不出延迟分布，得自己写钩子记录每个请求的耗时百分位，特别是p99和p999。另外，AI服务的内存泄漏问题在持续高并发下特别容易暴露，建议配合nvidia-smi或Prometheus监控显存变化，否则QPS再好看也是假象。

你这几点总结得太到位了，特别是响应时间非对称性，我测过几个模型，短输入延迟几十毫秒，长文本直接飙到几秒，QPS完全看不出真实瓶颈。顺便问下，你Locust里是怎么模拟不同输入长度对显存占用的影响的？我试过用自定义参数随机生成请求，但感觉跟实际推理差异还是很大。

用Locust压AI服务确实容易踩坑，尤其响应时间非对称性这块，我试过同样模型处理一句话和一段长文本，p99能差出5倍。后来我们直接在Locust里嵌了个请求内容随机生成器，按实际业务比例混长短文本，测出来的结果才稍微靠谱点。你提到的显存竞争也是大麻烦，我们有一次并发一高直接OOM，后来不得不给每个worker限了最大请求数。

这帖子说到点子上了，看得出是真正在AI infra一线摸爬滚打过的。我补充一些实操层面的东西，可能更接地气一点，也踩过你提到的显存碎片那个坑。

先说你提的Locust压测AI API，我完全同意不能只盯QPS。我去年接手过一个多模态模型（图像+文本混合输入）的线上服务优化，一开始团队就是用Locust发固定payload，QPS跑到60，大家都觉得稳了。结果上线第一天，P99延迟直接飙到8秒，用户反馈图片加载慢得像在拨号上网。后来一查，问题出在压测时我们用的都是64x64的小图，而实际用户上传的图平均是1080p，还有大量长文本prompt。你看，负载特征不对，压出来的结果就是自欺欺人。

所以第一个坑：压测payload必须真实。我现在的做法是，从线上日志里扒一段时间的真实请求，按输入长度、任务类型（简单分类、复杂推理、生成类）做一个分布，然后用Locust的HttpUser里自定义一个请求池，按比例随机抽取。代码上大概就是写一个list，里面存不同特征的request body，然后在on_start里初始化，请求时random.choice。这样压出来的P50、P95、P99才有参考价值。你提到的P99高达3秒的情况，我在BERT-based的文本分类服务上也见过，原因是某个长文本分支走了不同的前处理逻辑，里面有个O(n^2)的循环，低并发时没问题，并发一高CPU上下文切换就把那部分拖垮了。所以P99延迟的根因不一定是GPU，也可能是CPU预处理或后处理。

再说显存碎片化的问题，这个我太有体会了。我们之前用Triton Inference Server部署一个百亿参数的LLM，压测大概20分钟后，同样并发下延迟开始从200ms缓慢爬升到400ms，再过10分钟直接开始OOM。查了半天，发现是Triton的动态批处理（Dynamic Batching）在连续高并发下，因为不同请求的输入长度差异大，导致显存分配产生大量碎片。Triton默认的max_queue_delay和preferred_batch_size是按固定时延窗口攒批，但一旦碎片多了，后续的batch分配会失败，回退到单请求推理，显存带宽利用率暴跌，延迟自然就上去了。

我们的解法是两步：第一，把动态批处理改成静态batch size + 人工padding到固定长度，虽然浪费了一点显存，但避免了碎片。代价是P50延迟从200ms涨到250ms，但P99从3秒降到了800ms，整体更可控。第二，用NVIDIA的nsys和nvidia-smi的dmon模式监控显存分配情况，写了个脚本每5秒记录一次fragmentation score（通过读取/proc/driver/nvidia/gpu/*/memory里的free和total，结合nvidia-ml-py库），当碎片化超过阈值时，主动触发一次模型重加载，把显存回收。重加载期间会有几十毫秒的抖动，但总比持续恶化到OOM强。你提到的连续压测30分钟后延迟升高，大概率也是这个原因，建议用nvidia-smi pmon看看是否有大量"FB"（framebuffer）碎片。

另外，你提到“负载特征感知”的测试方案，我举双手赞成。我们最近在做RAG系统的压测，发现单纯压LLM生成部分是不够的。因为实际场景里，用户先发一个query，embedding模型要检索向量库，然后拼成prompt再调LLM。这几个步骤的资源消耗完全不一样：embedding模型主要是CPU和内存（如果向量库在内存里），LLM是GPU算力，而向量库的检索QPS瓶颈在索引结构。我们设计了一个混合压测方案：Locust里用一个SequentialTaskSet，先模拟embedding + 检索（固定耗时，因为向量库索引是确定的），再模拟LLM生成（按不同max_tokens长度分布）。这样压出来的整体端到端延迟分布才有意义。否则你只压LLM，发现QPS很高，但实际线上embedding检索先扛不住，用户感知的延迟还是崩。

还有一点你可能没提，但我觉得很重要：AI服务的错误码和退避策略。很多压测只关心成功请求的延迟，忽略了失败请求的模式。我们遇到过GPU显存不足导致请求被拒绝，返回503，但Locust默认的重试逻辑是立即重试，结果瞬间把GPU打得更死，形成雪崩。后来我们在压测脚本里加了自定义的退避策略：当收到429或503时，sleep一个随机时间（比如指数退避，base=1s，cap=30s），并且记录失败时的并发数，画出“失败率 vs 并发数”曲线。这条曲线往往比QPS曲线更早暴露瓶颈。比如并发数到50时QPS还在线性增长，但失败率已经到5%了，说明资源已经接近饱和，再增加并发只会让延迟爆炸。

从架构层面，我们后来引入了请求优先级队列。把简单推理（比如短文本分类）和复杂推理（比如长文本生成）放到不同的队列，分配不同的GPU实例。这样即使复杂推理的P99很高，也不会拖慢简单推理的P50。压测时也要分别模拟高低优先级请求的混合比例，否则你只压高优先级，发现延迟很好，但实际线上低优先级请求一多，高优先级的排队时间也会变长。

最后说一个工具层面的建议：Locust的report默认只有平均响应时间和百分位，但AI服务最好加上tail latency的时序图。我们写了一个自定义的event handler，在每个请求完成时，把延迟、输入长度、任务类型、GPU利用率（通过nvidia-ml-py采样）一起写入InfluxDB，然后用Grafana画一个热力图，横轴是时间，纵轴是延迟，颜色表示请求密度。这样能直观看到延迟的“漂移”——比如白天用户请求多时，P95延迟会有明显的周期性抖动。这比只看一个静态的P99数字更有诊断价值。

总结一下：AI服务压测的核心不是跑个高QPS证明性能好，而是找到那个“并发数-延迟-失败率”的三角平衡点。你提到的显存碎片、负载特征感知，都是这个三角里的关键变量。建议多从真实流量中提取模型，别用合成数据压测，否则上线必翻车。以上是我踩过的坑，希望能帮到你。