用到达率、服务时间和资源池解释吞吐上限，设计能暴露排队问题的负载实验。
本文于 2026-09-12 补充整理，按 2026-07 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
先估算系统同时处理多少任务
假设入口平均每秒到达 5 个请求，一次任务平均耗时 12 秒。在近似稳态且边界一致时，Little 定律给出系统内平均请求数约为：
L = λ × W = 5 × 12 = 60
这里的 L 包含该测量边界内等待和执行的任务。不能把 p95 延迟代入后声称得到“p95 并发数”，也不能在系统持续积压时把这个稳态关系当作容量保证。
这只是量级估算。真正容量还受模型并发、连接池、数据库、事件缓冲和租户公平性约束。
先找最窄的资源池
如果模型网关只有 20 个并发许可，单次模型调用平均 8 秒，忽略其他因素时对应的服务能力约为每秒 2.5 次调用。若每个任务平均调用两次，任务吞吐上限还会进一步下降。
增加 Java 工作线程无法跨越这个瓶颈。无限排队只会把拒绝变成更迟的超时，并增加内存占用。应该设置有界队列、最大等待时间和入口降载行为。
不同任务的资源需求不同。知识问答可以走短队列，复杂排障可以进入异步队列；否则少数长任务会占住全部许可。
开环与闭环负载回答不同问题
闭环负载中，虚拟用户收到结果后再发送下一次请求。系统变慢时，发送速率也降低，可能掩盖真实流量持续到达时的队列堆积。
开环负载按预定速率发送，更适合观察到达率超过处理能力后的行为。压测工具若跟不上计划发送速率，也需要记录漏发和延迟发送，不能只统计实际成功发出的请求。
建议先使用可控模拟模型服务测试排队，再在允许的费用预算内少量验证真实模型。模拟服务无法代表真实答案质量，所以两类结果要分开报告。
负载模型要包含长尾
场景 A：固定 2 秒响应，验证基准开销
场景 B：多数 2 秒、少数 30 秒，验证许可占用
场景 C：部分请求返回限流，验证退避与预算
场景 D：客户端慢读，验证 SSE 缓冲
场景 E：一个租户突发，验证其他租户隔离
上述时间和比例由实验设置确定。不能只用一个立即返回固定字符串的接口压测，再推断 AI 服务能够支撑多少真实用户。
记录排队时间、执行时间、任务成功率、拒绝率、取消率和内存。只统计成功请求的延迟，会让大量超时的系统看起来依然很快。
并发实现不是全部答案
虚拟线程、响应式调用与传统线程池可以使用相同的资源隔离和截止时间设计。JEP 444解释了虚拟线程的适用方式，但它不替代模型配额或业务入场控制。
多实例扩容时，还需要检查供应商全局上限。实例从 2 个扩到 8 个，若每个实例都保留同样本地限额，可能瞬间放大全局调用压力。
怎样输出一份可复查的报告
报告应写明机器、JDK、依赖版本、实例数、下游模拟分布、输入 token 分布、到达模型、预热时间和采样时长。图表旁边保留原始结果文件与配置。
验收不一定要求“所有请求都成功”。过载时有界拒绝、正常租户保持可用、流量回落后队列可恢复，往往比追求短时间峰值 QPS 更有意义。
没有完成这些实验前，容量数字应保持为设计假设，而不是写进简历的性能成果。
