2C4G 小 VPS 跑 10 个 AI Agent：压测记录与成本

要点

• 2C4G VPS 上 10 个 AI Agent 并发全部完成，峰值内存 2.72G，单 worker 平均约 169MB，可用内存降至 936MB。
• 遇到的问题都与硬件无关：配置不热加载、gateway 存在自杀保护、误归档了 14 个真实任务。
• 24 个任务总成本约 1.5 美元（按全价计算：10.8M 输入 × $0.14/M）。
• 未压到失败点，10 并发是已验证的安全值，不是极限值。

一、为什么做压测

Kanban 用了一段时间，一直只跑单任务。如果同时放进 10 个任务，这台 2C4G 的 VPS 能否承受，我心里没有把握：内存不足时 worker 会不会被 OOM 杀掉，dispatcher 会不会长时间排队，DeepSeek 的 API 费用会不会失控。

于是利用周末做了三轮压测。结果比预期乐观，但过程中有三个问题差点出事，记录下来供参考。

二、测试方法

先说明测了什么、没测什么。Grafana k6 把压测分为六类¹：冒烟（smoke）、平均负载（average-load）、压力（stress）、突发（spike）、拐点（breakpoint）和长稳（soak）。

这次属于向 stress / breakpoint 方向逐步加压：6、8、10 并发三轮递增，但没有压到失败点，因此不能称为极限压测。

施压方式也有所不同。Hermes Kanban 的 dispatcher 每 60 秒 tick 一次²，任务不会同时启动，而是创建后逐个派发。这和 k6、JMeter 直接发送 HTTP 请求的压测不同，测的是进程级的资源边界，而不是请求级的吞吐。

测试任务为轻量任务：每个 worker 执行 sleep 90 秒并上报内存，模型统一使用 DeepSeek Flash。它不代表竞品分析、视频处理这类真实业务负载，数据只反映「调度开销 + 最小常驻内存」这一场景。

因此没有使用 k6、JMeter、Locust 等工具。它们适合测 HTTP 流量，不适合测 Agent 进程的资源占用。这次的方法很直接：真实运行，观察内存。

三、过程与数据

测试环境：

项目	配置
VPS	腾讯云新加坡 2C4G
Kanban	Hermes Agent，dispatcher 运行在 gateway 进程内
模型	DeepSeek V4 Flash（非思考模式）
任务	sleep 90s + 上报内存的轻量 researcher
施压	每轮一次性创建 N 个任务，由 dispatcher 按 60s tick 派发

三轮结果：

并发数	峰值内存	可用内存	结果
6	2.34G	—	全部完成
8	2.47G	—	全部完成
10	2.72G	约 936MB（低于 1G 警戒线）	全部完成

其他数据：

• 单 worker 内存：平均约 169MB，区间 150–300MB。
• 24 个任务全部成功。
• Swap 基本没有变化（第一轮 319MB，第三轮几乎没有增长）。

全部完成不等于可以继续加量。10 并发时可用内存已降至 936MB，接近 1G 警戒线。按单 worker 150–300MB 的消耗推算，12 并发很可能超线，但这一点没有实测，不能下结论。

四、三个问题

1. 并发上限配置不热加载

Kanban 有一个 max_in_progress 配置项，用于限制同时运行的任务数。官方文档的说明是：供慢速 worker（本地 LLM、资源受限的主机）使用，让它们先完成手上的任务再领取新任务，避免堆积超时²。

三轮压测时我没有设置这个值，dispatcher 把所有任务一次性派出，内存依次升到 2.34G、2.47G、2.72G。压测结束后补设安全配置，先设为 max_in_progress=2，没有生效，又改了几次也没有变化。

原因是 dispatcher 运行在 gateway 进程内²，不是独立服务，修改配置后必须重启 gateway 才会生效。重启后设为 max_in_progress=6 再验证：放入 8 个任务，只运行 6 个，另外 2 个排队，配置才算生效。

2. gateway 的自杀保护

设好并发上限后，我想让 agent 帮忙重启 gateway 来验证，agent 拒绝执行。

实测发现，Hermes 禁止 agent 在会话内 kill 或重启自己所在的 gateway 进程。这个设计是合理的，否则 agent 会中断自己的运行环境。

但这也意味着无法通过 agent 自动运维 gateway。修改配置、重启服务等操作需要 SSH 登录手动完成，或者在外部写独立脚本。

3. 误归档 14 个真实任务

压测结束后清理看板。Kanban 的批量归档很方便，选中一批任务即可全部归档。

当时没有仔细核对列表，压测任务和真实任务混在一起，结果把 14 个真实任务也一并归档了。数据没有丢失，事后都恢复了。

教训是压测前先备份看板，最好让生产环境和压测环境分开。这次在同一块看板上测试，本身就有风险。

五、成本

24 个任务，DeepSeek API 总计约 1.5 美元。

项目	数值
API 调用次数	48 次
输入 tokens	约 10.8M
输出 tokens	约 21K
总成本	约 $1.5

计算方式按 DeepSeek 官方定价³：Flash 输入 $0.14/M，输出 $0.28/M。10.8M × $0.14 ≈ $1.51，输出 21K × $0.28 ≈ $0.006，合计约 $1.5。这是按全价、无缓存折扣计算的结果。

API 面板显示有缓存命中，但实际账单按全价计费。一种可能是不同 Kanban session 之间不共享缓存，面板统计的是 session 内的重复读取，计费时不计入折扣。本文不深究缓存计费细节，只看实际支出。

如果缓存折扣全部生效（读取价降至 $0.014/M），理论最低成本约 $0.16，相差近 10 倍。但在多 session 场景下很难达到，不建议以此做预算。

定价截至 2026-08：Flash 输入 $0.14/M，输出 $0.28/M，缓存命中时读取价再降 90%。

六、局限

这不是一份完整的压测报告，以下内容本轮没有覆盖：

指标	状态
CPU 使用率	未采集
任务耗时（p50/p95）	未记录 ready→done 时长
错误率 / 重试次数	只有「全部完成」的结论，无明细
队列长度时序	只有「放入 8 个、运行 6 个、2 个排队」的定性描述
空闲基线	压测前未记录 free -m
长稳（soak）	未做 1 小时持续负载
失败点（breakpoint）	未测 12 及以上并发

方法上的局限：

• 样本只有 24 个任务，远低于计算 P99 所需的约 1,000 个样本⁴，结论仅供定性参考。
• 轻量任务（sleep 90s）不等于真实业务负载。
• 没有空闲内存基线对照，峰值 2.72G 无法区分 Kanban 本身和系统基础开销。

复现步骤：

1. 准备 Hermes Kanban，确认 dispatcher 运行在 gateway 内（默认如此）。
2. 创建轻量 worker profile：执行 sleep 90s 并上报 free -m 的 researcher。
3. 设置 max_in_progress=6，然后重启 gateway。
4. 分批创建 6、8、10 个任务，观察内存变化。
5. 记录每轮的峰值内存、完成时间和失败数。

七、小结

2C4G 运行 10 个轻量 Agent 是够用的，但已经接近边界。设置好 max_in_progress（建议 6）、做好看板备份、记住改配置后要重启 gateway，这台 VPS 可以稳定支撑日常使用。

这个结果不适用于 10 个重负载 worker。单 worker 已经占用 150–300MB，真实业务的消耗只会更高，不能线性外推。

Atlassian 在对 Jira Data Center 做性能测试时，会先定义非功能需求阈值（NFR），例如「查看看板的 90 分位延迟不超过 5 秒」⁵。如果要把 Kanban 用于正式工作，也应先确定自己的阈值，比如 10 并发下任务 5 分钟内完成、CPU 不超过 75%，再按阈值测试，而不是只看内存一项。

下一步计划：测 12 并发找到拐点，跑 1 小时长稳观察是否泄漏，并用官方 inspect 接口²获取队列数据。

Footnotes

1. Grafana k6《Types of load testing》https://grafana.com/load-testing/types-of-load-testing ↩

2. Hermes Agent 官方文档《Kanban (Multi-Agent Board)》https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban ↩ ↩² ↩³ ↩⁴

3. DeepSeek API 官方定价页 https://api-docs.deepseek.com/quick_start/pricing ↩

4. Latitude《Ultimate Guide to LLM Load Testing》https://latitude.so/blog/ultimate-guide-llm-load-testing ↩

5. Atlassian《Performance and scale testing (Jira DC 10.3)》https://confluence.atlassian.com/spaces/ADMINJIRASERVER103/pages/1489808376/Performance+and+scale+testing ↩