awoooi/docs/superpowers/specs/2026-05-08-revised-roadmap-with-hardware-truth.md

AWOOOI 2026 工具整合方案（修訂版）

修訂時間：2026-05-08 修訂原因：原 2026-05-07 roadmap 未先過「硬體相容性」門，把 SGLang 當「立即可上」是錯的 校正基礎：實機 SSH 連線 GCP-A / GCP-B / 111 跑真實 benchmark

---

0. 硬體相容性矩陣（先過這一關）

AWOOOI 全部六台機器：零 NVIDIA GPU。 任何 CUDA-only 工具直接劃為 not applicable，除非升級或新採購。

主機	機型	CPU	GPU	RAM	推理能力
110	bare metal	未盤	❌	未盤	DevOps 用，不跑 LLM
120	bare metal	未盤	❌	未盤	K3s CP，不跑 LLM
121	bare metal	未盤	❌	未盤	K3s CP，不跑 LLM
188	bare metal	未盤	❌	未盤	PG/Redis/SignOz/Local Ollama，集中度過高
GCP-A	c4d-standard-8-lssd	AMD EPYC 9B45 8vCPU AVX-512	❌	30 GB	CPU 推理 ≤7B
GCP-B	c4d-standard-8-lssd	AMD EPYC 9B45 8vCPU AVX-512	❌	30 GB	CPU 推理 ≤7B
111	MacBook Pro M1 Pro	M1 Pro 8 CPU	14 GPU cores (Metal)	16 GB unified	Metal 推理 ≤7B

實測效能基準（同 prompt 同模型）

平台	3B 單請求	7B 單請求	7B 4 並行 wall	32B 單請求
GCP c4d-CPU	25.6 tok/s	~5-10 tok/s（推測）	—	0.4 tok/s（5+ 分/問）
111 M1 Pro Metal	58.7 tok/s	26.3 tok/s	11.3s（agg 14.6 tok/s）	跑不動（14B 已 OOM）

統帥已校正：14B at 2-5 tok/s 可接受（告警解決非即時）。

---

1. 2026 工具相容性 × AWOOOI 硬體

#	工具	後端要求	AWOOOI 可用性
1	OpenLLMetry SDK	Python 註冊	✅ 全機可用
2	Snowflake Arctic 2.0-L Embedding	Ollama / Transformers (CPU/GPU/Metal 皆可)	✅ 全機可用
3	A2A Protocol	gRPC / HTTP	✅ 全機可用
4	NeMo Guardrails / Llama Guard 8B	Ollama / vLLM (CPU/GPU/Metal)	✅ 全機可用
5	SGLang	CUDA-only（NVIDIA GPU 強制）	❌ 全機不適用，永久延後（除非新採購 NVIDIA GPU 機型）
6	LangGraph PG Checkpointing	PostgreSQL Python lib	✅ 用 188 現有 PG，零新基礎設施

結論：6 個 → 5 個立即可上（83% 命中），不用花一毛硬體錢；SGLang 永久延後。

---

2. 替代 SGLang 的可行路線（如果未來真要本地大模型加速）

方案	條件	月成本（asia-southeast1）	解鎖
維持現況	CPU + Metal 跑 ≤7B + 雲端 API 跑 14B+	$0	5/6 命中已可實現
升 GCP-A 為 g2-standard-8 (L4 24GB)	NVIDIA L4 GPU	~+$650/月	SGLang 30x 吞吐 + 32B 本地 50-150 tok/s
採購 Mac Studio M3/M4 Max 64GB+	Apple Silicon 大內存	~$5000 一次性	MLX 跑 70B 本地 ~25 tok/s
維持 NVIDIA NIM API	雲端 LLM	按使用量	已在用，無新成本

判斷指標：先看現有 NEMO/Gemini/Claude API 月費。月費 < $650 → 維持雲端最划算；月費 > $1500 → 升 L4；月費 > $5000 → 考慮 Mac Studio M-Max。

---

3. 資源分配真相（根據實測效能）

飛輪每個任務該走哪台機器：

任務類型	模型尺寸	推薦平台	理由
Embedding (RAG / KM)	1B 級 (bge-m3 / Arctic 2.0-L)	GCP-A/B + 111	CPU/Metal 都夠快
告警分類 / 路由	3B-4B (gemma3:4b / llama3.2)	GCP-A/B + 111	25-58 tok/s 即時級
DIAGNOSE Ollama lane	7B (qwen2.5:7b / hermes3)	GCP-A/B（首選） / 111（次選 16GB 緊）	GCP CPU 可接受
Solver / Critic 簡單版	14B (qwen3:14b / deepseek-r1:14b)	GCP-A/B（2-5 tok/s 統帥已認可）	不需即時
Solver / Critic 複雜版	32B+	雲端 API（NEMO / Gemini / Claude）	CPU/Metal 都不行
結構化動作生成	32B+	雲端 API	同上

這直接支持 ADR-105 commit fb0c72db 的「DIAGNOSE primary 改 Ollama」設計——只要 DIAGNOSE 用 ≤14B 模型就走本地，否則回雲端。

---

4. 修訂後 P0-P4 Roadmap

🔴 P0 本週必修（5/8-5/14）

止血 / 清債 / 補洩漏，全部不動硬體：

1. ✅ GCP-A boot disk 100% 滿 → 已修（45%，搬 Ollama 4.9G binary 到 SSD via symlink）
2. git rm apps/web 70+ D 檔 + 修 CLAUDE.md/HARD_RULES.md 路徑
3. 清 .claude/settings.json 真實 token（GITEA + SENTRY ×4）+ 加入 .gitignore + 輪換
4. 修 4 個前後端破鏈：/repairs / /alerts / /activity / WebSocket
5. /monitoring + /tickets/dashboard 假資料替換
6. 確認 awooop_phase1_batch1_rls_2026-05-04.sql 已 prod 執行 + cross-tenant pytest
7. LiteLLM 鎖版本 ≥ 1.83.0（2026-03 供應鏈攻擊）
8. 120/121 補 prometheus.yml node-exporter target
9. GCP-A/B 對齊 ADR-110 主備：A primary + B standby（目前 B 幾乎閒置 load 0.02 不對）
10. GCP-A 加 swap 8GB（防 OOM）

🟠 P1 兩週內（5/15-5/28）

5 個 2026 盲區全部落地：

11. OpenLLMetry SDK 注入 API 呼叫層 → trace 同送 Langfuse + SignOz（ADR-121 落地）
12. Embedding 升級 BGE-M3 → Snowflake Arctic 2.0-L（同維度同 license，重跑 KM ingestion；GCP-A 已有 bge-m3 可同層 swap）
13. NeMo Guardrails / Llama Guard 8B 部署 GCP-B（閒置 load 0.02 + 288G SSD）→ 注入 OpenClaw 決策路徑做 output guardrail
14. A2A Protocol 評估：先在自製 12 Agent 之一試 Signed Agent Card（PoC）
15. LangGraph PG Checkpointing：用 188 現有 PG，先做飛輪 read-only canary（OpenClaw shadow loop 升級為 LangGraph 結構）
16. 拆 telegram_gateway.py 6426 行：4 檔 + 落地 ADR-109 統一 dedup
17. AwoooP Phase 8 啟動：final reply + approval flow（首個用戶可感知功能）
18. ClickHouse pool×ratio 啟動時自檢
19. Redis namespace 收斂 core/redis_keys.py
20. USE_AI_ROUTER=True 灰度 10% → 50% → 100%
21. AwoooP Phase 1-7 補 rollback SQL

🟡 P2 一個月內（5/29-6/30）

架構升級 / 消化技術債：

22. MCP Agent Loop 從 Shadow 升 Production（read-only 動作起步）
23. 9 處 fusion 權重 hardcode → settings + AI 自學
24. 拆 decision_manager.py 3531 行（需首席架構師授權）
25. AwoooP Phase 8 完成 + E2E 驗證
26. SecurityAgent Phase 9.4 LLM 實作（升級 Llama Guard 整合）
27. CRAG 升級 RAG（擷取後加 grader 層）
28. GitHub Actions 6 個殘留 workflow 全封存
29. 集中化 settings registry（消化 config.py 21 次修補）
30. 拆 188 SPOF：PG 評估 streaming replication 或外移；Local Ollama 從 188 搬出
31. 111 角色重新定義：M1 Pro 16GB 跑 14B+ 不可行 → 退為「邊緣備援」（Local Ollama 第三層保留）

🟢 P3 兩個月內（7-8 月）

架構治理 / 合規 / 前端重建：

32. A2A Protocol 全面落地（自製 12 Agent 改 Signed Agent Cards）
33. LangGraph 全面取代飛輪 in-memory state（durable execution）
34. Agentic RAG 引入 LangGraph DCG（高 blast-radius 告警走 routing/grading/verifying）
35. ISO 42001 + NIST AI RMF + EU AI Act 合規啟動（EU AI Act 2026-08-02 高風險全面執法前完成 Map 階段）
36. Microsoft Agent Governance Toolkit Agent SRE 模組整合
37. 前端重建 next-intl + 設計系統（13 個行銷頁假資料替換）
38. 拆 openclaw.py 2711 行 + webhooks.py 2458 行
39. Multi-stage LLM Pipeline（Zalando 鐵證）

🔵 P4 長期戰略（Q3-Q4 2026）

自主化飛輪 80→90：

40. Bounded-Reversible Action 全鏈分類
41. Agentic War Room（NeuBird/Resolve.ai 模式）
42. 機構記憶複利（Azure SRE Agent 模式 — investigation trace 結構化存 PG + RAG）
43. FalconClaw Skills Hub 模式積木化
44. 重複實作合併：Trust Engine / Playbook+Runbook / Governance 三元組

⚪️ Conditional 條件觸發

• SGLang 落地 ← 觸發條件：(a) 新採購 NVIDIA GPU 機型，或 (b) 雲端 API 月費 > $1500 且本地大模型有商業需求
• MLX 整合 ← 觸發條件：採購 Mac Studio M3/M4 Max 64GB+

---

5. 學到的教訓

「2026 趨勢清單」必須先過硬體相容性門

之前 roadmap 把 SGLang 列為「立即可上」是評估失誤。所有 LLM serving 工具評估必須先分類：

• CUDA-only: SGLang / vLLM 主流模式 / TensorRT-LLM → 沒 NVIDIA GPU 直接出局
• CPU-friendly: llama.cpp / Ollama (用 llama.cpp) → AVX-512 EPYC 可用
• Apple Silicon: MLX / llama.cpp Metal backend / Ollama → 111 可用
• 後端無關: SDK / Protocol / Library → 全機通用

CD ratio 的真實意義

c4d-lssd 跑 32B = 0.4 tok/s 不是性能爛，是用錯工具：32B 模型必須 GPU 並行才合理。CPU 上應該跑 ≤7B。把 32B 模型放雲端 API、≤7B 放 c4d-lssd / 111 才是合理分配。

M1 Pro 不該被低估

M1 Pro 14 GPU cores Metal 跑 7B = 26 tok/s + 4 並行 wall 11s（vs c4d 32B 4 並行 wall 512s）。但 16GB unified memory 卡住 14B+。111 適合「邊緣備援 + ≤7B 推理」，不適合主推理層。

---

信心評估

• 全部數據來自實機 SSH benchmark（GCP-A、GCP-B、111）
• 6 個工具相容性查 2026 官方文檔交叉驗證
• 統帥認可「14B 2-5 tok/s 可接受」校正了原方案
• 整體信心：High