| 项目 | 内容 |
|---|---|
| 测试平台 | RK3568：4×Cortex-A55 @1.99GHz，4GB RAM，32GB eMMC，被动散热 |
| 系统 | Ubuntu 22.04.3 LTS（厂商内核 4.19.232，aarch64） |
| Agent | Hermes Agent v0.19.0（Nous Research），gateway 以 systemd 用户服务常驻 |
| 模型 | deepseek-v4-flash（DeepSeek 官方 API，云端推理） |
| 工具集 | terminal / file / code_execution / memory / web / todo |
| 测试日期 | 2026-08-03 ~ 08-04 |
| 报告版本 | v1.2（主线调整为 CPU 影响分析；v1.1 的形态对照数据移至附录） |
一、测试问题与方法
本报告回答三个问题：agent 运行消耗多少 CPU；CPU 规格（核数）对运行表现的影响；什么样的 CPU 配置构成下限、什么构成冗余。
- CPU 消耗测量：systemd cgroup
CPUUsageNSec前后差值（内核记账，无采样误差），除以档位轮数得到每轮核·秒成本。 - 限核实验：通过 systemd unit drop-in 设置
CPUAffinity，将 gateway 进程树（含工具子进程）分别钉至 1 核、2 核；每阶段以/proc/<pid>/status的Cpus_allowed_list验证生效，并校验档位前后 PID 一致（排除中途重启干扰）。实验期间曾发现一次限核指令未生效（systemctl set-property返回错误但脚本继续执行）与一次外部触发的服务重启污染采样，相关数据已作废并在修正后重测。 - 负载驱动：本机 webhook + HMAC 驱动 gateway，冷会话口径（每消息新建会话）；延迟取自框架毫秒级日志打点；档位含对话并发 1/2/4/8/16 与工具调用（真实终端执行）并发 1/2/4。
二、CPU 消耗画像
| 消耗项 | 实测值（A55@1.99GHz 口径） | 说明 |
|---|---|---|
| 每轮对话 | 0.9~1.2 核·秒 | 各核数配置下一致；主要为提示词组装、流式解析、会话读写 |
| 每轮工具调用 | 1.3~1.8 核·秒 | 含 2~3 次 API 往返与本地命令执行 |
| 进程冷启动（一次性） | 13~16 核·秒 | Python 导入与初始化，单线程 |
| 持续用量上限 | ≈1.2 核 | 单进程 GIL 与内部队列所致，与并发数无关 |
| 空载 | ≈0 | 等待 API 返回期间几乎不消耗 CPU |
单轮端到端延迟中，DeepSeek API 占 1.5~3s，板上处理约 1s；延迟以 API 耗时为主，CPU 性能对单轮体验影响有限。
三、限核实验：核数对运行表现的影响
同一负载在 1/2/4 核下的对比（冷会话口径；每阶段亲和性经 /proc 验证）：
| 指标 | 1 核 | 2 核 | 4 核基线 |
|---|---|---|---|
| 冷启动首轮 | 16.3~23.4s | 16.3s | 17.8s |
| 对话 ×1 并发 p50 / p95 | 2.6 / 2.6s | 2.6 / 3.1s | 2.6 / 2.6s |
| 对话 ×4 并发 p50 / p95 | 4.6 / 11.2s | 4.1 / 10.8s | 4.1 / 6.7s |
| 对话 ×4 吞吐（轮/分） | 36.9 | 41.7 | 50.5 |
| 工具 ×2 并发 p50 | 5.6s | 7.7s | 5.1s |
| 每轮 CPU 消耗（对话） | ≈0.9 核·秒 | ≈1.0 核·秒 | ≈1.1 核·秒 |
| 失败 | 0 | 0 | 0 |
主要观察：
- 单会话体验与核数无关：1 核与 4 核的单并发 p50 完全相同（2.6s）。
- 冷启动与核数无关：单线程执行，1/2/4 核均为 16~23s 区间。
- 核数的收益集中在并发尾部：4 并发 p95 从 6.7s（4 核）升至 11.2s（1 核）；吞吐下降 27%。
- 工具档位差异（5.1~7.7s）处于小样本 API 波动范围内，未呈现核数信号——工具轮的耗时同样由 API 往返主导。
四、并发上限形态
并发 8→16 时（4 核配置），gateway CPU 用量维持在约 1.2 核不再增长，延迟接近翻倍并出现框架层 429 限流拒绝。性能上限由框架单进程架构决定：提升核数或更换更高算力 CPU 均无法提高该上限，扩容路径为多实例部署或更换网关实现。
五、CPU 选型结论
| 配置 | 判定 |
|---|---|
| 1× 现代 ARM 小核（A55 级） | 可完整运行：单会话体验无损，并发尾部延迟上升 |
| 2× A55 级 | 并发中位延迟与 4 核持平，接近该框架的性能上限 |
| 4× A55 级（RK3568） | 对该框架冗余；余量可留给系统与工具子进程 |
| 更高算力 CPU | 对单轮体验与并发上限均无实质收益（瓶颈在框架与 API） |
选型时单核性能优先于核数；若需改善冷启动（13~16 核·秒），提升单核性能有效、增加核数无效。
六、CPU 之外的边界条件
- 内存：gateway RSS 峰值 <400MB；无桌面系统整机占用约 850MB。2GB 内存平台预计可运行纯对话入口；启用本地 Chromium 浏览器工具需另加 1~1.5GB。
- 散热：全部档位温度峰值 <59°C（被动散热），无降频。
- 外部网络依赖（部署风险项）：Hermes 每次新建会话同步刷新 models.dev 模型目录，失败结果不缓存；该域名在国内网络被 DNS 污染时每轮增加约 15s。处理：/etc/hosts 写入
127.0.0.1 models.dev与::1 models.dev，使其快速失败并回落磁盘缓存。portal.nousresearch.com 在高频建会话时返回 429（不在关键路径）。 - 服务形态：入口应配置为常驻进程（systemd + linger，验证断电重启自动恢复），避免每次冷启动。
附录 A：桌面/无桌面形态对照（v1.1 数据）
A.1 纯对话（延迟 p50 / p95，秒）
| 并发 | 带桌面 | 无桌面 | 成功率（两轮） |
|---|---|---|---|
| 1 | 3.1 / 3.1 | 2.6 / 2.6 | 100% / 100% |
| 2 | 3.1 / 5.6 | 3.1 / 9.7 | 100% / 100% |
| 4 | 3.6 / 9.2 | 4.1 / 6.7 | 100% / 100% |
| 8 | 6.2 / 8.2 | 7.7 / 9.8 | 100% / 100% |
| 16 | 12.0 / 19.2 | 15.3 / 24.5 | 84% / 94%（其余为 429 限流拒绝） |
A.2 工具任务（真实终端执行）
| 并发 | 带桌面 p50 | 无桌面 p50 | 成功率 |
|---|---|---|---|
| 1 | 3.6s | 5.1s | 100% |
| 2 | 4.6s | 5.1s | 100% |
| 4 | 5.2s | 7.7s | 100% |
A.3 资源占用
| 指标 | 带桌面 | 无桌面 |
|---|---|---|
| 空载系统可用内存 | 2889MB | 3303MB（桌面占用约 410MB） |
| gateway RSS 峰值 | 281MB | 398MB |
| 温度峰值 | 58.9°C | 57.2°C（均无降频） |
| zram 使用 / OOM | 0 / 无 | 0 / 无 |
两种形态的延迟差异处于跨日 API 波动范围内；桌面的主要成本为约 410MB 内存。
附录 B：未覆盖项
- 7×24 长期稳定性（内存增长趋势、eMMC 写入量、API 超时率）
- 持续会话口径（需接入实际 IM 平台）；冷会话数据为保守上界
- 长任务多轮工具循环、多模态输入的 CPU 形态
- 功耗测量
- 原始数据保留于测试板
~/hermes-bench/results/