# ADR-027：Primary Ollama 遷移至 GCP 高效能主機

- **Status**: Accepted
- **Date**: 2026-05-03
- **Decision Maker**: 統帥
- **Author**: Antigravity

## Context

為了提升 AI 處理速度與穩定性，並減輕本地 188 主機的負載，現已啟用一台位於 GCP 的高效能主機作為 Primary Ollama 伺服器。
原本地 188 或 111 的 Ollama 轉為 Fallback 節點。

## Decision

**1. 高效能主機配置**
- **Public IP**: `34.21.145.224`
- **服務端口**: `11434`
- **主要模型**:
  - `qwen2.5-coder:7b` (程式碼修復與開發)
  - `hermes3:latest` (Llama 3 級別，用於 Hermes 邏輯)
  - `bge-m3:latest` (Embedding 專用)

**2. 環境變數對應**
- `OLLAMA_HOST_PRIMARY`: `http://34.21.145.224:11434`
- `OLLAMA_HOST_FALLBACK`: `http://192.168.0.111:11434` (或 188 本地節點)

**3. 資源分工**
- **Primary (GCP)**: 承載 90% 以上的 LLM 推理與 Embedding 請求。
- **Fallback (Local)**: 當 GCP 連線超時或故障時，自動切換至本地節點（ Hermes Rule-based 或本地 Ollama）。

## Alternatives Considered

- **維持全本地**: 188 主機 Load 較高，且 GPU 資源競爭激烈。
- **全雲端 API (OpenAI/Gemini)**: 成本較高，且無法控制模型版本與延遲。

## Consequences

- **優點**: 推理速度提升，系統負載均衡，具備異地備援能力。
- **缺點**: 依賴外部網路連線，需注意 GCP 出口流量成本與安全性（目前採 IP Allowlist 保護）。

## Verification

- `curl http://34.21.145.224:11434/api/tags` 驗證模型列表正常返回。
- 測試 `qwen2.5-coder:7b` 與 `bge-m3:latest` 回應正常。

---

## 附錄（2026-05-03 戰役 v5.0 補述）

> **補述背景**：Operation Ollama-First v5.0 戰役 Phase 0/1/2/3 完成後，本附錄校正本 ADR 的主機架構與 fallback 鏈描述，並廢止「188 Ollama」概念。完整治理規則改由 ADR-028 / ADR-029 承接。

### 附錄 A：三主機架構（取代原 GCP / 111 二段描述）

戰役 v5.0 啟用第二台 GCP 高效能主機後，主機級聯升級為三層：

| 角色 | 公網 IP / 主機 | 儲存 | 規格 / 用途 |
|---|---|---|---|
| **Primary** | `34.143.170.20:11434` | SSD | 9× 加載 / 2× 推理（v5.0 戰役新主機）|
| **Secondary** | `34.21.145.224:11434` | SSD | 同等效能備援；本 ADR 原 Primary 降為次主 |
| **Fallback** | `192.168.0.111:11434`（HDD）| HDD | 統帥 Mac 上的 Ollama.app，最後一道本地防線 |

**程式契約**：所有 LLM 呼叫必須走 `services/ollama_service.resolve_ollama_host()`（Phase 2 A6 落地），按 Primary → Secondary → Fallback 順序探測：
- HTTP probe `GET /api/version`，2s timeout（取代原純 TCP 探測，B3 修補）
- 失敗主機 `mark_unhealthy()` 30s（B4），TTL 內直接跳下一台
- 寫死 IP 已全面消除（`services/aider_heal_executor.py:48-49` 與 `services/code_review_pipeline_service.py:218-225` 兩處 N2/N3 修補）

詳見 `docs/phase2_deploy_verify_20260503.md`。

### 附錄 B：4 條獨立 fallback 鏈（不存在「線性 LLM 鏈」）

戰役 v5.0 audit 證實系統實際有 4 條（嚴格說 5 條）獨立 fallback 鏈，語意各異不可合併：

1. **Ollama host 級**（基礎設施層）
   `gcp_ollama` (Primary) → `ollama_secondary` → `ollama_111`
   實作：`services/ollama_service.resolve_ollama_host()`

2. **Hermes 競價 / 意圖分類**（戰術層）
   Ollama → 規則引擎兜底
   實作：`services/hermes_analyst_service.py`（ADR-004）

3. **NemoTron 派遣**（行動層）
   NIM `meta/llama-3.1-8b` → Hermes 規則引擎
   實作：`services/nemoton_dispatcher_service.py`（ADR-004）

4. **OpenClaw Q&A**（戰略層 / Telegram）
   Gemini 2.5 Flash → NIM `deepseek-v3.2` → 字面 fallback
   Phase 3 A7 已切：Hermes qwen3:14b → 信心低升 Gemini → NIM
   實作：`services/openclaw_strategist_service.py` / `routes/openclaw_bot_routes.py:6784-6843`

5. **MCP 即時情報**（外部資訊層）
   Gemini Grounding L1 → Gemini Grounding L2 → Ollama L3 → 靜態字串
   實作：`services/mcp_collector_service.py:163-214`

### 附錄 C：廢止項

- **「188 Ollama」概念全面廢止**
  188 主機（`192.168.0.188`）僅作為以下用途：
  - SSH AutoHeal target（`docker restart` / log scan，ADR-013）
  - momo-pro Docker Compose 運行環境（ADR-008）
  - momo-postgres / momo-db / momo-scheduler / momo-telegram-bot 容器宿主
  - **不安裝、不運行 Ollama**（Ollama 全部走 GCP Primary / Secondary 或統帥 Mac 111）
  - 任何「188 Ollama」字樣的舊文件視為過時，以本附錄為準
- 原 `OLLAMA_HOST_FALLBACK = http://192.168.0.111:11434` env var 仍保留，但解析路徑改由 `resolve_ollama_host()` 統一管控，不再被任何呼叫點寫死引用

### 附錄 D：治理規則升級指引

戰役 v5.0 後，所有 LLM 治理決策改以以下文件為準：
- 路由白名單 / caller 清單 / Gemini 鎖定場景 → **ADR-028**
- Hermes 主塔 vs OpenClaw 副塔分工 → **ADR-029**
- 部署驗證劇本 → `docs/phase2_deploy_verify_20260503.md`
- DB 觀測層 schema → `migrations/024_create_ai_calls_table.sql` ~ `026_add_embedding_signature.sql`
- Logger 程式契約 → `services/ai_call_logger.py`

本 ADR-027 保留作為戰役起點的歷史紀錄，不再作為主要參照入口。
