项目 QPS 有多高，如何压测和规划节点容量？

核心回答

项目容量应说明：在什么请求模型、部署规格和延迟及成功率要求下，系统能够持续处理多少流量。QPS 只是其中一个指标，要区分入口请求速率、成功完成速率和完整业务任务吞吐，并同时观察 P95/P99、错误率、积压与资源使用。

压测先固定场景、数据、版本和部署配置，建立低负载基线，再逐级加压，找到开始排队、超时或资源饱和的环节；随后验证目标负载下的稳定运行、突发流量和故障恢复。节点数量根据单节点的安全承载、目标峰值与故障冗余作初步估算，再通过多节点全链路测试确认，不能把单机最高瞬时 QPS 直接乘节点数。

在 Agent 服务中，还要单独统计模型调用次数、Token 吞吐、工具与检索耗时。一次用户请求可能触发多轮模型和工具调用，SSE 返回了第一个事件也不代表任务完成。应用副本增加后，模型配额、数据库或检索服务仍可能成为共享瓶颈。

先确定 QPS 的统计口径

接口报告中常把每秒请求数统称 QPS，更准确的 HTTP 指标是 RPS。业务任务吞吐则表示每秒完成多少次完整任务，例如生成一份研究结果。一次任务经过多个接口或多轮模型调用时，它们的速率不同。

统计时明确观察窗口、接口或任务范围，以及是否包含失败、重试和缓存命中。建议同时保留：

• 到达或实际发送的请求速率，以及结束的请求速率。
• 成功完成的业务任务速率、失败与超时比例。
• 平均延迟与 P95/P99，流式任务另看首个有效输出和完整结束时间。
• 活跃请求、等待队列、连接与内存等资源状态。

在线人数、压测虚拟用户数和在途请求数也不是同一个量。一个在线用户可能没有发请求，一个压测虚拟用户通常会循环执行脚本；一条脚本迭代又可能包含多个 HTTP 请求。

SSE 场景应消费并检查任务结束事件、错误和完整结果。只测建立连接或收到首包，可能得到很高的“成功率”，却遗漏后续生成失败、长连接中断或客户端取消后服务端仍在工作的情况。

压测怎样设计

用真实的工作分布建立基线

先确定业务目标，例如峰值期间的完成时限、可接受失败率和恢复要求。准备有代表性的问题长度、历史轮数、检索命中情况、工具分支和输出长度，保留不同场景的比例。

固定应用、模型、Prompt、数据、缓存策略和部署规格，并记录冷启动、预热和稳态阶段。缓存全命中的短请求，不能代表包含长文检索和多轮工具调用的容量；比较优化前后时也应使用同一负载模型。

可以先用受控模型或工具返回隔离应用层瓶颈，再验证包含实际依赖的链路。两类结果分别说明范围：模拟依赖得到的是相应模拟时延与返回分布下的应用能力，完整链路还受外部服务能力和配额影响。

选择与目标匹配的施压方式

固定虚拟用户数的闭环测试中，一个用户完成当前迭代后才发下一次。当服务变慢，发送速率会跟着下降。这适合研究固定并发用户下的表现，但可能低估持续新请求到达时的排队压力。

验证固定到达速率时，可以采用开放式到达模型，并检查实际启动了多少任务、是否存在未启动的迭代，以及施压端本身的 CPU、连接和网络是否足够。配置“每秒发起多少次”与实际完成多少次不是同一个结果。

逐级加压，每个档位留出观察稳定趋势的时间。接近容量边界后，继续看延迟、错误和队列怎样变化；流量撤回时，再看积压是否消退、连接是否释放。长时间稳定性测试关注内存、连接或队列是否持续增长，突发与实例退出则验证保护和恢复。

根据证据定位瓶颈

结合请求指标与分阶段 Trace，区分模型等待、检索、数据库、工具网络、应用计算和排队。例如：

• CPU 较高且主要耗在解析或序列化，可以优化计算与数据量，再验证扩副本收益。
• CPU 不高但连接池耗尽、事件循环被阻塞或队列增长，应先检查等待与资源释放。
• 模型侧限流、Token 预算或工具服务先饱和，单纯增加应用副本可能放大重试与竞争。

优化针对已定位环节，例如修正慢查询、限制无效重试、合并重复检索、为独立 I/O 使用适当并发。每次用相同场景复测吞吐、时延、错误和资源变化，不只展示一个最高 QPS。

怎样推导节点容量

这里的部署节点应说明是机器、容器副本还是服务进程；工作流中的逻辑节点数量不代表部署容量。

先确定满足业务时限与成功标准、能够持续运行且保有资源余量的单节点吞吐。再考虑目标峰值、负载分配、扩容耗时和实例故障。以下仅作容量换算示例：

假设目标是每秒完成 6 个任务，平均完整耗时为 10 秒。在统计边界一致、运行稳定时，Little 定律给出平均在途任务数约为 6 × 10 = 60。这里包括相应边界内的执行与等待，使用的是平均耗时，不能换成 P99，也不能把 60 当成在线用户数。

若同一场景下每个同构应用节点的安全吞吐假设为 2 个任务/秒，理想分配需要至少 3 个节点；若还要求失去一个节点后保持目标吞吐，初步需要至少 4 个，因为剩余 3 × 2 = 6。若每个任务平均调用模型两次，模型侧还需要承接约 12 次调用/秒，并满足相应 Token 负载。

这个估算依赖节点可分担负载、共享依赖容量足够等条件。实际还要验证热点会话、状态存储、缓存、下游限流与滚动发布期间的表现；容量报告应把这些条件和多节点测试结果一起给出。

项目结果怎样说明

可围绕“场景与观测窗口 → 机器及副本配置 → 施压方式 → 达标时的吞吐与延迟 → 瓶颈 → 改动及复测”组织说明。区分日常流量、典型峰值、短时极限与可持续容量，并保留压测脚本版本、负载数据和报告，便于解释数字。

如果项目只做过功能验证，可以具体说明已完成的接口、并发处理方式和容量验证方案，再把待测项列清楚。节点数、CPU 核数、模型卡数和工作流步骤分别承担不同角色，不能互相替代。

常见追问

提高并发数，QPS 为什么反而下降？

共享资源可能已经饱和，新增请求主要在排队；锁竞争、调度和重试也会增加额外工作。要看延迟、队列和瓶颈资源的变化，不能继续用低负载时的平均耗时作线性外推。

平均响应很快，能说明容量足够吗？

还需要看长尾、错误和成功业务吞吐。快速失败可能拉低平均耗时，少量长请求则可能长时间占用连接或工作资源。

异步能让一个研搜任务更快吗？

异步主要让多个任务在等待 I/O 时交错推进。单任务能否加速取决于哪些步骤可以独立并行，顺序依赖和模型本身的生成时间不会因为改成异步就自动缩短。

对应教程

参考资料