# 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**
