大模型自动容量压测

公开版案例说明：以下内容只展示方法、对比思路和落地路径，不展示任何真实环境、配置路径、内部脚本名或具体厂商标识。

1. 背景：为什么要做自动容量压测

起点是模型选型评估。我们已有基于 Locust 的上下文容量矩阵压测方法，可以得到不同模型、不同上下文长度、不同并发档位下的容量数据：

• 成功率
• RPS
• 输出 tokens/s
• 总 tokens/s
• TTFT P95
• TPOT P95
• 端到端 P95
• SLA 是否通过

这些数据已经可以支撑容量矩阵、成本热力图、混合流量成本计算和服务器选型建议。

但 Locust 矩阵压测有一个根本问题：需要人工设定并发梯度，再观察每档表现，再决定是否继续加压、缩小范围或补充更高并发档位。这种方式适合做可控实验，但不适合长期自动化。具体表现为三个问题：

1. 压测周期长，人的等待和判断成本高
2. 容量边界不一定被准确打到，可能只得到一个粗略矩阵
3. 不同人执行时口径容易不一致，影响后续成本计算和横向对比

因此希望把容量测试从"人工跑矩阵"推进到"自动探测容量边界"。

2. EvalScope 在这个场景里能解决什么

EvalScope 是 ModelScope 体系下的大模型评测与压测框架，同时支持模型能力评测和 OpenAI-compatible API 的性能压测。在容量测试场景里，它的价值主要有三点：

1. 可以直接对 OpenAI-compatible 接口发起压测，不需要改造被测服务
2. 可以自动生成压测报告，包括 RPS、输出吞吐、TTFT、TPOT、端到端时延、成功率等指标
3. 支持自动调参能力，例如通过 --sla-auto-tune 搜索满足 SLA 的最大并发或最大请求速率

这意味着 EvalScope 不只是"另一个压测工具"。如果配置得当，它可以承担原来人工观察压力情况、逐步调整并发参数的部分工作；如果开启自动调参能力，容量边界搜索也可以由 EvalScope 执行，而不是由人一档档试。

3. 推荐的压测模式

建议把压测分成两种模式：固定矩阵模式和自动探测模式。

3.1 固定矩阵模式

固定矩阵模式与 Locust 手工阶梯压测方式一致，目标是和历史数据对齐、复用既有容量矩阵与成本模型。优势是口径一致、可直接横向对比；不足是仍需人工决定档位，未打到瓶颈时需要补跑。

3.2 自动探测模式

自动探测模式用于寻找容量边界。例如可以设定 SLA：

• 成功率 >= 99%
• TTFT P95 <= 1s
• TPOT P95 <= 20ms
• 端到端 P95 <= 10s
• 错误率 <= 1%

然后让工具自动搜索最大可承载并发或最大请求速率。

这种模式的目标不是铺完整矩阵，而是回答一个更直接的问题：

在这个上下文长度和输出限制下，这台服务器最多能稳定承载多少压力？

适用场景：

• 部署验收
• 回归验证
• 版本升级前后容量对比
• 自动生成"推荐容量档位"

建议两种模式都保留：固定矩阵用于横向分析和成本建模，自动探测用于找容量边界和减少人工调参。

4. POC 关键结果

在某个 35B 级大模型上做 EvalScope POC，矩阵覆盖 4K / 16K / 32K / 64K 上下文与 2 / 4 / 16 三个并发档位，所有档位成功率均为 100%。

上下文	最佳并发	RPS	输出 tok/s	TTFT Avg	TPOT Avg	成功率
4K	16	4.23	2111	482ms	6.4ms	100%
16K	16	3.14	1559	1131ms	8.0ms	100%
32K	16	2.10	1048	2144ms	10.8ms	100%
64K	16	1.23	613	5321ms	15.3ms	100%

从趋势看，上下文越长，RPS 和输出吞吐下降明显，TTFT 增长明显，符合长上下文推理的一般规律。但这组结果还不能直接作为最终容量结论。

5. 和历史 Locust 数据的对比

把 EvalScope POC 数据和历史 Locust 同口径数据做对比，差异趋势如下：

• 4K 全档位基本一致，差异在个位数百分比以内
• 16K 低并发接近，16K 高并发低约 20%
• 32K 高并发低约 40%
• 64K 高并发低超过 60%

因此问题不在 EvalScope 本身，而在 prompt 口径尚未对齐。

6. 当前最大风险：random prompt 口径不适合直接下结论

POC 使用的是 EvalScope 内置的 --dataset random，会生成随机 Unicode、多语言和特殊字符混合的 prompt。它不是业务真实中文长文，也不是历史 Locust 使用的固定 prompt 池。这带来几个问题：

1. Token 数不可控地膨胀
2. Prompt 形态和真实业务输入不同
3. 服务端 tokenizer、chat template、特殊字符处理可能带来额外开销
4. 长上下文场景下，这种差异会被放大

例如，目标 64K prompt 在 EvalScope 报告中的实际平均输入 token 达到约 72K（取自 result.prompt_tokens 字段），明显超过目标值。这也解释了为什么长上下文下 EvalScope 相比 Locust 明显更慢：实际打进去的输入更长，而且 prompt 内容更复杂。

报告里的 input token 更接近真实请求落库后的 token 统计，而不是"中文字数 × 0.6/0.7"的估算。

7. 推荐落地方案

为了让 EvalScope 真正替代或补充 Locust，建议按以下路径推进。

7.1 第一阶段：复用历史 prompt 池

把历史 Locust 使用的固定 prompt 池转换成 EvalScope 可读 dataset。目标：让 EvalScope 和 Locust 使用同一批输入数据，排除 prompt 差异。

7.2 第二阶段：建立固定矩阵对齐报告

继续使用固定矩阵：

contexts = 4K, 16K, 32K, 64K
concurrency = 2, 4, 16
max_tokens = 500
stream = true

跑完后比较 RPS、输出 tokens/s、TTFT、TPOT、端到端时延、成功率、实际 input tokens。如果同 prompt 下差异可接受，说明 EvalScope 可以进入下一阶段。

7.3 第三阶段：引入自动容量探测

在固定矩阵验证通过后，再启用 EvalScope 的自动 SLA 搜索能力。目标是让工具自动回答：

在某个上下文长度下，满足 SLA 的最大并发是多少？

这一步可以减少人工观察和补跑。

7.4 第四阶段：接入成本工具

最终将 EvalScope 输出适配到现有容量/成本工具的数据结构中：

service_id
vendor
model
context_tokens
concurrency
requests
success_rate
rps
output_tps
total_tps
ttft_p95_s
tpot_p95_ms
e2e_p95_s
source_path

这样就可以继续复用现有的容量矩阵、成本热力图、混合流量成本计算器、指标对比页和选型建议页。

8. 结论

EvalScope 可以作为大模型自动容量压测方案的核心工具，但不能简单地把 random prompt POC 结果直接替代历史 Locust 容量报告。

当前结论可以概括为：

1. EvalScope 能自动执行压测和生成报告
2. EvalScope 支持自动调参，有潜力替代人工观察压力情况
3. 本次 POC 证明链路可用，4K 和 16K 低并发结果与 Locust 接近
4. 长上下文和高并发差异明显，主要风险来自 prompt 口径不一致
5. 下一步必须复用历史 prompt 池，完成同 prompt、同上下文、同输出限制下的对齐验证
6. 对齐后，再使用 EvalScope 自动 SLA 搜索能力，建设真正可复用的自动容量探测流程

最终目标不是简单替换 Locust，而是形成一套更自动、更可复现、更容易接入成本计算的容量压测链路。