架構說明請先看 先前的 Hermes 三層記憶專文；本篇則是在相同的 Bot 權杖、相同的模型 Provider、相同的 cron 摘要間隔下連跑 30 天的運維筆記。對象是三種主機：（1）2 vCPU / 4GB / 80GB NVMe 的共用 Linux VPS（月費約 $12）、（2）家用 Raspberry Pi 5 8GB 加 USB3 SSD（電費與線路由自費）、（3）依 控制台 Runbook 開通的 NUKCLOUD 獨佔 Mac Mini M4 16GB 月租。Telegram 閘道器與夜間 FTS5 維護全程開啟，每週記錄 state.db 體積、Skill 條目數與閘道器重啟次數。先講結論：三台的「記憶變聰明」在第二週後都能體感，但留在生產閘道器上的只有 Mac 月租；VPS 降為開發用 API 代理，樹莓派退回實驗沙箱。
0030 天實驗設計：公平對照的前提
為避免比較失真，各主機均以 curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash 安裝同一主版本，MEMORY.md 與 USER.md 的初始範本也保持一致。模型統一走 OpenRouter 的同一中階方案，不啟用本地 LLM，只觀察閘道器負載。Telegram 方面，生產 Bot 只掛在 Mac 上；VPS 與樹莓派則用獨立測試 Bot，每週兩次投遞相同問題集，對照回覆品質與延遲。
觀測指標有四項：（A）閘道器可用率（launchd 或 systemd 自動重啟日誌）、（B）state.db 與 skills/ 的週增量、（C）摘要工作的 p95 耗時、（D）月度總成本（VPS 帳單、樹莓派電費概算、Mac 按量月租）。三層記憶的理論背景見 為何需要一直開著的 Mac；本文在其上驗證「便宜底座是否也能讓記憶複利」。
0130 天後的三方對照表
| 觀測項 | 共用 Linux VPS | Raspberry Pi 5（家用） | Mac Mini M4 月租 |
|---|---|---|---|
| 閘道器可用率 | 約 94%（每週一次夜間維護需手動重啟） | 約 91%（停電 1 次、SD 過熱降頻 2 次） | 99.2%（僅計畫內重啟 1 次） |
| Skill 條目（第 30 天） | 37 | 41 | 44 |
| state.db 體積 | 1.1 GB | 1.3 GB | 1.4 GB |
| 摘要 p95 | 48–120 秒（CPU steal 時） | 35–90 秒（USB SSD 飽和時） | 18–32 秒 |
| 月度成本感 | 約 $12 固定 | 硬體攤提加電費約 NT$800/月 | 全時常駐為按量；可夜間停機調 OpEx |
| 生產適配 | 低（超賣、頻寬抖動） | 中（家用線路、實體單點） | 高（租戶磁碟、SSH 可稽核） |
單看數字，樹莓派似乎「更便宜、Skill 也更多」。但在 Telegram 生產場景，使用者感受的是回覆是否斷線，而非條目數。VPS 與樹莓派上的 USER.md 同樣變厚，然而摘要拖長的夜里，閘道器一旦堵塞，第二層 Skill 蒸餾就可能半途被打斷。Mac 月租節點則與 Metal 推理 Runbook 一樣，用留有餘裕的 SKU 拿掉了磁碟與記憶體瓶頸。
02共用 VPS：便宜，卻扛不住「記憶的夜班」
VPS 安裝最快、接 Bot 也最快，符合官方「五美元起」的敘事。痛點出在第二週之後的夜間批次：FTS5 重建索引與 LLM 摘要疊加時，鄰居租戶的 CPU steal 讓 load average 衝到 8 以上，Hermes 閘道器兩次被 OOM killer 結束。重啟後 state.db 仍在，但曾出現蒸餾中的 Skill 以半成品 Markdown 留在 skills/，需手動清理。
Linux 上 Hermes 能跑，卻與 macOS 專屬開發流（Xcode、Swift 6、嚴格並發 CI 門禁）分家。30 天後，VPS 只保留為「廉價 Hermes 實驗機」，生產 Telegram 閘道器已遷出。若團隊要把 Apple 工具鏈與 Agent 放在同一租戶，僅靠 VPS 不夠。
03樹莓派 5：記憶會長，SRE 負擔也會長
樹莓派最接近「在家放一台常駐 Agent」的想像。把 USB3 SSD 當 root，~/.hermes/ 掛在持久卷上，三層記憶檔案就穩定。30 天內 Skill 條目超過 VPS，USER.md 也足夠厚。隱形成本是家用維運：IPv4 變更導致 Telegram webhook 需重登錄一週；夏季機殼溫度讓 CPU 降頻，摘要 p95 超過 90 秒的日子有 4 天。
樹莓派適合「養記憶」的實驗，卻不適合多位工程師共用同一 Bot 的生產依賴——停電、路由器重啟、實體安全都要寫進內部 SLA。實驗結束時，樹莓派只留作離線 Skill 試作與 cron 原型，生產閘道器收斂到 Mac。若還要疊 Metal 推理，8GB 樹莓派不如直接看 定價頁 的 24GB 雲端 Mac。
04Mac Mini M4 月租：30 天後值得「留下」的理由
NUKCLOUD 獨佔 Mac 可經 GitHub Agent 工作空間 Runbook 同一套 控制台 開通，租戶邊界與其他 CI 節點一致。30 天內閘道器可用率逾 99%，摘要 p95 穩定，週次 rsync 備份 ~/.hermes/ 的流程也與 說明中心 的 SSH 範例對齊。
相較一次性 CapEx 的 Mac Mini 自購，月租的優勢是30 天就能測損益：平日夜間關 Bot 省按量，週末 24 小時常駐加速學習。自購 Mini 動輒 NT$18,000 起，利用率低的月份仍要付電費與修補。「記憶夠聰明了再買」之前，先用租賃確認聰明狀態——這是本次實驗最實務的收穫。
- 統一記憶體：日後可讓 Hermes 與 modest 本地推理同機共存。
- NVMe：
state.db成長到 GB 級，FTS5 仍維持可用延遲。 - 稽核：「誰能讀磁碟」比共用 VPS 池更易向合規團隊舉證。
05該留誰：決策框架
30 天後團隊採用的判定如下。
-
01
是否承載生產 Telegram / Discord：若要，VPS 與樹莓派單獨都不夠，須在 Mac 月租或自購 Mini 中二選一並收斂。
-
02
是否每月 720 小時全時常駐：若是，試算自購 Mini 的 OpEx；若否，優先看 定價頁 按量。
-
03
是否與 Apple 工具鏈同居：需要則 Linux VPS 只做輔助，macOS 節點為主（見 六步 Runbook）。
-
04
是否保留實驗槽：樹莓派做低成本 Skill 試作，VPS 改接 CI 以外的輕量 API 代理。
-
05
備份：生產 Mac 的
~/.hermes/每週離站；三層記憶越聰明，遺失越痛。 -
06
下一個 30 天：從 下單頁 升到 24GB SKU，並把 三層記憶生產 Runbook 第 4–6 步套到生產閘道器。