TLDR
- 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 扛得住吗？
内存不够 OOM 杀掉 worker？dispatcher 排队排到天荒地老？DeepSeek API 账单爆炸？
趁周末做了三轮压测。结论比预期乐观，但三个差点翻车的坑如果不写出来，别人大概率也会踩。
二、压测怎么测的（方法论）
先说清楚测了什么、没测什么。压测类型有标准框架——Grafana k6 官方把压测分成 6 类1：冒烟（smoke）→ 平均负载（average-load）→ 压力（stress）→ 突发（spike）→ 极限/拐点（breakpoint）→ 长稳（soak）。
这次做的本质是 stress/breakpoint 方向的逐步逼近——6→8→10 并发递增三轮，但没压到失败点，所以不能叫「极限压测」。
施压节奏也交代清楚：Hermes Kanban 的 dispatcher 每 60 秒 tick 一次2，任务不会瞬间全部启动，而是一批一批创建、逐个派发。这和传统 HTTP 压测（k6/JMeter 直接打请求）完全不同——测的是进程级资源边界，不是请求级吞吐。
压测任务是什么？轻量任务：每个 worker 跑 sleep 90s + 上报内存，全部用 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 个任务全部成功，成功率 100%
- Swap 几乎不动（第一轮 319MB，第三轮几乎没涨）
「全过」不代表随便加。 10 并发时可用内存已经掉到 936MB，距离 1G 警戒线一步之遥。结合单 worker 150-300MB 的消耗区间，12 并发大概率踩线——但没测，不能下结论。
四、三个差点翻车的坑
这三个坑全不是硬件问题，但每个都能让你的 Kanban 看板翻车。
坑一：保险丝不热加载
Kanban 有个 max_in_progress 配置项，作用是限制同时运行的任务数——官方文档的说法是给「慢 worker（本地 LLM、资源受限主机）用的，让它们跑完手上的活再领新的，避免堆到超时」2。
三轮压测（6→8→10）跑的时候，我完全没设这个值。 dispatcher 把所有任务一口气全派出去，内存飙到 2.34G→2.47G→2.72G。压测结束后，才想起来补安全配置——先设了 max_in_progress=2，没生效（dispatcher 不热加载，见下），反复改了三遍都不行。
坑在哪？ 这个配置不改就算了，改完必须重启 gateway 才生效。因为 dispatcher 跑在 gateway 进程内2，不是独立服务。我改了配置等了一分钟没反应，以为没写对——先试 max_in_progress=2，再试 6，反复改——最后重启 gateway 才反应过来。重启后设成 max_in_progress=6 再验证：8 个任务丢进去只跑 6 个，2 个排队——这回终于生效了。
坑二：gateway 实测有自杀保护
刚设好保险丝，想验证一下——让一个 agent 帮我把 gateway 杀掉再重启。「kill 自己的 gateway」这个指令发出去，agent 直接拒绝执行。
实测发现，Hermes 有自杀保护：agent 会话内禁止 kill 或重启自己所在的 gateway 进程。这逻辑对——真让 agent 把自己的运行环境杀了，谁给它收尸。
但意味着：你没法通过 agent 自动化运维 gateway。 改配置、重启这些操作必须 SSH 进去手动干，或者在外面写独立脚本。
坑三：误归档 14 个真实任务
压测完想清理看板。Kanban 的归档功能很方便——选一批任务、点一下，全进归档列。
手快，没细看列表。压测任务和真实任务混在一起，一把梭全归档了。14 个真实任务（数据没丢，抢救回来了），但当时看着归档列里一堆不该在这的东西，心态炸了半分钟。
教训：压测前先备份看板。 或者说，生产环境和压测环境分开。我是同一块看板上测的，不出事才奇怪。
五、成本账本
24 个任务，DeepSeek API 总共花了 ~$1.5。
拆开看：
| 项目 | 数值 |
|---|---|
| API 调用次数 | 48 次 |
| 输入 tokens | ~10.8M |
| 输出 tokens | ~21K |
| 总成本 | ~$1.5 |
$1.5 怎么算出来的？ 按 DeepSeek 官方定价3：Flash 输入 $0.14/M、输出 $0.28/M。10.8M × $0.14 ≈ $1.51，加上输出 21K × $0.28 ≈ $0.006，合计约 $1.5——这是全价、零缓存折扣的数字。
API 面板确实显示了 cache hit，但实际账单按全价计算——一种可能是不同 Kanban session 之间缓存不共享，面板统计的是 session 内的重复读取，计费侧不认这个折扣。这篇文章不深究 DeepSeek 的缓存计费细节，只看钱包：24 个轻量任务，$1.5。
如果缓存折扣全部生效（读价降到 $0.014/M），理论最低成本约 $0.16——差了近 10 倍。但这个数在分布式多 session 场景下极难达到，别拿它做预算。
定价标注：截至 2026-08 的 DeepSeek 官方定价。Flash 输入 $0.14/M、输出 $0.28/M（缓存命中时读价再降 90%）。
六、局限与诚实交代
这篇文章不是一份完整的压测报告。以下是本轮没做、应该做但暂时没做的事：
数据维度缺失：
| 该有的指标 | 状态 |
|---|---|
| CPU 使用率 | ❌ 未采集 |
| 任务耗时（p50/p95） | ❌ 未记录 ready→done 时长 |
| 错误率/重试次数 | ❌ 只有「全过」结论，无明细 |
| 队列长度时序 | ❌ 只有「8 丢 6 放、2 排队」的定性描述 |
| 空闲基线 | ❌ 压测前没记 free -m |
| 长稳（soak） | ❌ 没跑 1 小时持续负载 |
| 失败点（breakpoint） | ❌ 没压 12+ 并发 |
方法论局限：
- 样本量 24 个任务，远不到 P99 所需的最低 1000 样本4——所有结论只适合定性参考，别当统计精度用
- 轻量任务（sleep 90s）≠ 真实业务负载（竞品分析、视频处理等重任务）
- 没做 baseline（空闲内存）对照，峰值 2.72G 无法归因到 Kanban 本身 vs 系统基础开销
怎么复现：
- 准备 Hermes Kanban，确认 dispatcher 在 gateway 内（默认）
- 创建轻量 worker profile：sleep 90s + 报
free -m的 researcher - 设
max_in_progress=6，重启 gateway - 分批创建 6/8/10 个任务，观察内存曲线
- 记录每轮峰值、完成时间、失败数
七、结论
2C4G 跑 10 个轻量 Agent 够用，但已经接近边界。 配好 max_in_progress（推荐 6），做好看板备份，脑子里记着「改配置要重启 gateway」——这台小 VPS 能稳定扛住日常工作。
但别把它当 10 个重负载 worker 的通行证。单 worker 150-300MB 的消耗摆在那，12 并发大概率出事。真实业务（竞品分析、视频处理）每个 worker 消耗只会更高，不能线性外推。
Atlassian 压 Jira Data Center 的时候先定 NFR（非功能需求阈值），比如「View board 的 90 分位延迟 ≤5 秒」5。如果你也要给自己的 Kanban 上生产，先定你的 NFR——10 并发下任务 5 分钟内完成？CPU 不超过 75%？——然后对着 NFR 测，别只盯内存一个数。
下次补：12 并发 breakpoint 找极限、1 小时 soak 看泄漏、用官方 inspect 接口2 挖队列数据。
Footnotes
-
Grafana k6 官方《Types of load testing》https://grafana.com/load-testing/types-of-load-testing ↩
-
Hermes Agent 官方文档《Kanban (Multi-Agent Board)》https://hermes-agent.nousresearch.com/docs/user-guide/features/kanban ↩ ↩2 ↩3 ↩4
-
DeepSeek API 官方定价页 https://api-docs.deepseek.com/quick_start/pricing ↩
-
Latitude《Ultimate Guide to LLM Load Testing》https://latitude.so/blog/ultimate-guide-llm-load-testing ↩
-
Atlassian 官方《Performance and scale testing (Jira DC 10.3)》https://confluence.atlassian.com/spaces/ADMINJIRASERVER103/pages/1489808376/Performance+and+scale+testing ↩