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

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