Agent 服务阶梯压测与容量承诺：拐点识别、SSE 判定与配额约束

导读：本文用一次完整实践回答 LLM/Agent 服务压测最常被问的三个问题——同时能撑多少人聊、瓶颈在哪、容量承诺怎么给。核心方法是 JMeter 阶梯加压逐档找软拐点（P95 抬头、稳定仍绿）与硬拐点（错误率抬头、连接层开始拒绝），并强调 SSE 流式接口"HTTP 200 但无可用 content 一律记失败"的判定口径（本次实测曾出现 3 并发档的空心 200）；关键结论是共享 LLM 配额下不能按节点数线性扩容（"10×3=30"仅在瓶颈全在本机时成立），最终以"常态 ≤10 并发/单实例、发版门禁错误率 ≤1%、

阅读全文 →

把 Agent 送进千问平台前，先过这 17 道性能关卡：一次 A2A 压测实录

质量工程实战 · 2026-07 · betae 环境

一、背景：Agent 要"上架"第三方平台，对方先甩来一份验收模板

我们的 Agent 服务要接入千问开放平台。对方给了一份性能验收模板，列了 17 项指标，分五大类：OAuth 授权、SSE 流式输出、对话性能、H5 页面、事件回调。不达标不接。

这份模板最大的价值不是"考试"，而是它把"一个 Agent 在第三方平台上会被用户怎么用、哪些环节会卡"拆成了可测的原子指标——这正是我们平时容易漏测的地方：多数团队自测 Agent 只测"回答正不正确、快不快

阅读全文 →

A2A vs HTTP：Agent 协议性能压测的指标口径陷阱

导读：本文对比同一套 Agent 服务走 A2A 协议通道与 HTTP 会话通道两种接入方式的阶梯压测结果，核心教训是"跨协议对比之前必须先对齐指标口径"：A2A 的 TTFT 指 task 帧到达（P50 约 1～2s，仅为服务端受理信号），HTTP 的 TTFT 指"首字"到达（P50 约 4～8s），两者直接比数字会得出"HTTP 慢三四倍"的假结论；真正可比的是完整时延，实测同阶梯下 HTTP 路径中位系统性快约 6s（约 -30%～-40%），且断连需区分 client 主动断与超时断，帧间隔要说明是相邻哪类帧。适合做跨

阅读全文 →

LLM API 账号限流容量估算：从 RPM/TPM 配额到业务容量

导读：本文解决"服务商只给 RPM/TPM 限流配额，业务却想知道能支撑多少用户与对话"的容量估算问题。核心方法是先用观测数据统计每轮对话的平均调用次数与 token 消耗，再按"容量 = min(RPM/每轮调用数, TPM/每轮token)"两个维度各除一次、取较小者；关键结论是长 prompt 场景下 token 维度几乎总是先撞墙（示意示例中 token 上限约 250 轮/分 vs 请求上限 2,500 轮/分），只看 RPM 会严重高估容量、上线后提早吃到 429。适合所有接入第三方 LLM API、需要做配额容

阅读全文 →

同一个 LLM：知识库（RAG）场景 QPS 为何比纯对话低一个数量级？

导读：文章通过同一自部署 LLM 在纯对话与知识库（RAG）两个场景的压测对比，揭示"加一个检索链路、QPS 掉一个数量级"：纯对话单节点稳定 QPS 120+、单问题约 1 秒输出，而 RAG 仅约 2–3 QPS、耗时 20 余秒，差距约 40–60 倍；原因分析聚焦利特尔定律与"向量检索 + 上下文组装 + Rerank + 长上下文解码"整条链路，并给出检索缓存、上下文裁剪、检索与生成服务解耦等优化方向。适合负责 LLM 容量评估、性能压测或 RAG 架构优化的工程师阅读。

分类：性能测试 ｜ 标签：RAG、大模

阅读全文 →

用 JMeter 做容量评估：从线上流量推导目标 QPS 到阶梯加压实战

导读：这篇讲容量评估的完整方法链:先不做"没有目标的压测",而是用线上近 1 日真实调用量反推目标 QPS(以最高频接口约 4.1 万次/天为基准,分钟峰值约 350,秒级约 6 QPS,放大 10 倍定为 60 QPS),再在测试、线上环境做 1/15/30/60/90 并发的阶梯加压,结果测试环境 90 并发约 270 QPS 轻松达标、线上约 467 QPS。最宝贵的部分是线上压测才碰得到的两个坑——服务治理层的限流、前端中间件的 CPU 告警都先于被测服务真实瓶颈出现,提醒要区分"到底是哪个组件先到瓶颈"。适合用

阅读全文 →

自部署 LLM 的并发压测：QPS 卡在 1.5，瓶颈到底在 CPU 还是显存？

导读：这篇记录了对自部署 LLM 对话接口从 1 并发加压到 100 并发的阶梯压测:QPS 无论怎么加压都稳定卡在 1.5 左右,50 并发起开始报"连接被关闭",100 并发时成功率崩到 42.86%。看似是模型算力不够,但资源监控显示显存/内存全程恒定、CPU 最高只到约 40%,结论是瓶颈在 HTTP 并发处理层而非 GPU/显存,并给出连接池、并发上限、超时与 keep-alive 等优先优化方向。适合评估自部署大模型服务并发上限的测试工程师与后端开发者阅读。

本文记录一次对自部署大模型对话接口的 JM

阅读全文 →

LLM 知识库(RAG)接口压测实录：为什么 20 并发就让接口崩掉

导读：这篇实录回答"RAG 知识库接口在并发下扛不扛得住":对"检索+生成"串行链路的知识库问答接口做 JMeter 阶梯压测,结论是 1 并发成功率 100%(平均响应 3.6s),到 20 并发时成功率跌到 87%、平均响应 47.8s、吞吐掉到约 1.4,接口基本崩掉。关键判断是瓶颈不在机器(显存/内存全程稳定),而在串行的检索与生成链路,并给出多线程调用、检索链路两个方向的优化建议。适合要压测 LLM/RAG 或知识库类接口的测试工程师与后端开发者阅读。

分类：性能测试 ｜ 标签：LLM、RAG、压测

背景：业务要

阅读全文 →

接口压测目标怎么定：从日访问量推导 QPS 目标的实用方法

导读：本文给出接口压测目标的可执行推导方法：有线上 QPS 的接口按"正常流量 10 倍且响应时间 200ms 内"设定目标，没有监控的接口用 80/20 法则从日访问量反推基准 TPS（TPS = 日访问量×80% /（活跃时长×3600×20%），如日访问 100 万约 46 TPS），再按 3 倍、10 倍分档加压直到报错以探明容量上限。适合需要为接口设定压测档位并同步盯机器、数据库、中间件指标的性能测试工程师。

分类：性能测试 ｜ 标签：性能测试、压测、QPS

做接口压测时，最常被问到的两个问题就是：压到多少 QPS 才算达

阅读全文 →

正则表达式提取器

有时候我们要测的接口参数需要另一个接口参数返回的结果时，就可以用正则表达式提取器

1. 右键你的http请求 --> 添加 --> 后置处理器 --> 正则表达式提取器
2. 要检查的响应字段 选择 主体
3. 其他填写例如下表：

# 当我们的响应数据为如下这种时
{
    "code":0,
    "hint":"success",
    "msg":"成功",
    "token":"123456",
}

阅读全文 →