分类标签归档：压测
导读：本文用一次完整实践回答 LLM/Agent 服务压测最常被问的三个问题——同时能撑多少人聊、瓶颈在哪、容量承诺怎么给。核心方法是 JMeter 阶梯加压逐档找软拐点（P95 抬头、稳定仍绿）与硬拐点（错误率抬头、连接层开始拒绝），并强调 SSE 流式接口"HTTP 200 但无可用 content 一律记失败"的判定口径（本次实测曾出现 3 并发档的空心 200）；关键结论是共享 LLM 配额下不能按节点数线性扩容（"10×3=30"仅在瓶颈全在本机时成立），最终以"常态 ≤10 并发/单实例、发版门禁错误率 ≤1%、
导读：本文对比同一套 Agent 服务走 A2A 协议通道与 HTTP 会话通道两种接入方式的阶梯压测结果，核心教训是"跨协议对比之前必须先对齐指标口径"：A2A 的 TTFT 指 task 帧到达（P50 约 1～2s，仅为服务端受理信号），HTTP 的 TTFT 指"首字"到达（P50 约 4～8s），两者直接比数字会得出"HTTP 慢三四倍"的假结论；真正可比的是完整时延，实测同阶梯下 HTTP 路径中位系统性快约 6s（约 -30%～-40%），且断连需区分 client 主动断与超时断，帧间隔要说明是相邻哪类帧。适合做跨
导读：文章通过同一自部署 LLM 在纯对话与知识库（RAG）两个场景的压测对比，揭示"加一个检索链路、QPS 掉一个数量级"：纯对话单节点稳定 QPS 120+、单问题约 1 秒输出，而 RAG 仅约 2–3 QPS、耗时 20 余秒，差距约 40–60 倍；原因分析聚焦利特尔定律与"向量检索 + 上下文组装 + Rerank + 长上下文解码"整条链路，并给出检索缓存、上下文裁剪、检索与生成服务解耦等优化方向。适合负责 LLM 容量评估、性能压测或 RAG 架构优化的工程师阅读。
分类：性能测试 ｜ 标签：RAG、大模
导读：这篇记录了对自部署 LLM 对话接口从 1 并发加压到 100 并发的阶梯压测:QPS 无论怎么加压都稳定卡在 1.5 左右,50 并发起开始报"连接被关闭",100 并发时成功率崩到 42.86%。看似是模型算力不够,但资源监控显示显存/内存全程恒定、CPU 最高只到约 40%,结论是瓶颈在 HTTP 并发处理层而非 GPU/显存,并给出连接池、并发上限、超时与 keep-alive 等优先优化方向。适合评估自部署大模型服务并发上限的测试工程师与后端开发者阅读。
本文记录一次对自部署大模型对话接口的 JM
导读：这篇实录回答"RAG 知识库接口在并发下扛不扛得住":对"检索+生成"串行链路的知识库问答接口做 JMeter 阶梯压测,结论是 1 并发成功率 100%(平均响应 3.6s),到 20 并发时成功率跌到 87%、平均响应 47.8s、吞吐掉到约 1.4,接口基本崩掉。关键判断是瓶颈不在机器(显存/内存全程稳定),而在串行的检索与生成链路,并给出多线程调用、检索链路两个方向的优化建议。适合要压测 LLM/RAG 或知识库类接口的测试工程师与后端开发者阅读。
分类：性能测试 ｜ 标签：LLM、RAG、压测
导读：本文给出接口压测目标的可执行推导方法：有线上 QPS 的接口按"正常流量 10 倍且响应时间 200ms 内"设定目标，没有监控的接口用 80/20 法则从日访问量反推基准 TPS（TPS = 日访问量×80% /（活跃时长×3600×20%），如日访问 100 万约 46 TPS），再按 3 倍、10 倍分档加压直到报错以探明容量上限。适合需要为接口设定压测档位并同步盯机器、数据库、中间件指标的性能测试工程师。
分类：性能测试 ｜ 标签：性能测试、压测、QPS
做接口压测时，最常被问到的两个问题就是：压到多少 QPS 才算达