Ollama 在 Cloud Mac AI Stack 裡是私有推理層，不是本機玩模型

在上一篇裡，我們把 L1（GitHub Runner） 說清楚：git push 之後要有可稽核的 Fact（定義見 Runner 篇 · Stack 語言）。接下來很多團隊會在同一台 Cloud Mac 上裝 Claude Code，順便 brew install ollama——然後發現主力編碼仍 100% 走 Claude API，Ollama 行程常年空轉，還佔著 6–8GB 統一記憶體。

這不是「Ollama 沒用」，而是還沒回答更關鍵的問題：為什麼 Inference 必須單獨成為一層，而不是併進 Claude Code？本篇不是 Ollama 安裝百科，也不重複16GB vs 24GB 記憶體實測或M4 vs GPU 雲成本；只界定 L2 的存在理由、邊界，以及和 L3（Diff）的關係（L3 詳見 Claude Code 工作站）。

L2 產出物：Inference 是什麼

在 Cloud Mac AI Stack 裡，我們用產出物而不是工具品牌來分層（完整鏈條見Runner 篇 · Stack 語言）：

記憶鏈 · 五種產出物（非呼叫順序）

  Context  →  Inference  →  Diff  →  Fact  →  Workflow
  (MCP)      (Ollama 等)    (Claude Code)  (Runner)  (OpenHands)

五層結構圖仍按 L0–L5 畫元件；產出物鏈把 Inference 與 Context/Diff/Fact/Workflow 並列，避免「橫切補丁」感

Inference 在這裡指：在你控制的 macOS 行程裡完成的模型前向——輸入 prompt / embedding，輸出 completion / 向量，不經過第三方推理 API（或僅把 API 用於 L3 主路徑，而 L2 處理必須留在本機的 token）。Ollama 是目前最常見的 L2 實作，不是唯一選項；Core ML 與 MLX 也可承擔部分 Inference，但 Ollama 的模型生態與維運路徑較統一，適合作為 L2 的預設敘事。

L2 形態：Inference Service，不是偶爾 ollama run

只說 Inference，讀者仍可能把它理解成「又一個本機模型工具」。在 Stack 裡，我們更強調形態——每層對應一種可長期依賴的系統角色：

ollama run qwen3:8b 與 ollama serve + 健康檢查 + cron 呼叫的差異，就像「SSH 裡手動跑測試」與「Runner 監聽 push」的差異：

ollama run     →  人坐在終端機前的一次性推理（像試跑）
Inference Service  →  11434 常駐、可 pin 模型、可被 Runner / 腳本 / Agent 反覆呼叫

為什麼 Inference 須單獨成 L2，而不是 Claude Code 的一部分

很多開發者會問：「Claude API 不也是推理嗎？」 是——但 Cloud Mac AI Stack 按產出物分層，不是按「有沒有神經網路」分層。

Claude Code 的職責是產生 Diff——改哪些檔案、怎麼改、PR 裡呈現什麼 patch。Inference 的職責是產生 Token——任意模型前向的文字或向量輸出。Diff 只是 Token 的一種用途。

同樣屬於 Inference、卻不該塞進「編碼 Agent」主路徑的工作，還包括：

• 日誌摘要、分類、審核、路由
• Embedding、RAG、rerank
• Agent 記憶整理、知識庫清洗
• 夜間批處理、定時日報

因此關係是：

Claude Code  ⊂  Inference 的應用場景之一

而不是：

Inference  ⊂  Claude Code

把 L2 獨立出來，不是因為 Ollama 比 Claude「更底層」，而是因為整台 Cloud Mac 上可能同時存在多條推理管線：L3 走 API 產 Diff；L2 在本機產必須私有的 Token；二者並行，互不替代。若把 Inference 折進 Claude Code，讀者會誤以為「裝了 Claude 就等於 Stack 推理層齊了」——這正是空轉 Ollama 的根源。

Ollama vs Claude Code：為什麼不是二選一

搜尋裡常見「Ollama 還是 Claude Code」——在 Stack 語境下，這個問題本身問錯了方向。二者對應不同產出物，不是替代關係。

實務口訣：編碼問 Claude Code；「哪些 token 不能出機、要定時跑」問 Ollama。 同機記憶體排班見 L2-Q03 續篇；本篇只釘死「不是二選一」。

「玩模型」與「私有推理層」差在哪

同樣是在終端機裡跑 ollama run qwen3:8b，兩種心態對應兩種架構結果：

一句話：玩模型關心「能不能跑」；L2 關心「跑什麼、何時跑、誰依賴它的輸出」。 若團隊沒有任何工作負載必須落在私有 Inference 上，L2 可以整層跳過——不必為了「完整 Stack」硬裝 Ollama。

L2 與 L1 / L3 如何分工

三層最容易混在一起的分界如下：

L2 不生產 Diff，也不生產 Fact。 它不會讓 PR 自動變綠，也不會取代 xcodebuild。典型接法是：Claude Code 改完程式碼 → Runner 驗證 → 某 step 或 sidecar 腳本呼叫 Ollama 做日誌摘要、漏洞模式比對、私有 embedding 寫入向量庫——這些輸出進入 Context（L4）或人工 review，而不是直接等同「建置通過」。

五層圖裡的 L2：層級 ≠ 呼叫順序

全系列共用的五層結構見 Runner 篇 · 五層結構圖。圖中 Ollama 位於 Claude Code 下方，表示職責上 Inference 托住「私有算力」這一塊地基，不是說開機必須先 ollama serve 才能開 Claude Code。

摘錄 · 詳見 Runner 篇完整圖

  Claude Code  L3 · Diff
       ↑ 並行，非依賴
  Ollama       L2 · Inference Service（可選）
       ↑
  GitHub Runner L1 · Fact
       ↑
  Cloud Mac    L0 · 基礎設施

理解 L2 時請記住：Claude API 與 Ollama 可以同時存在——前者服務編碼主路徑產 Diff，後者服務本機 Inference。這與「本機模型取代 Claude」的敘事不同，也是 Cloud Mac AI Stack 與「單機 All-in-One 聊天」產品的分界。

除合規外：L2 的持續運算價值

L2 常被寫成「金融 / 醫療 / 大企業才需要」——合規確實是強訊號，但 Cloud Mac 上大量使用者是獨立開發者、AI 創業者、小團隊，未必有合規工單，卻同樣需要 L2。

核心差異在工作形態：

Claude Code（L3）· 按需
  你開啟它 → 開始推理
  你關閉它 → 主路徑推理結束

Ollama（L2）· 可 24/7
  行程常駐 → cron / sidecar 隨時呼叫
  不依賴你是否坐在終端機前

這類任務不是 Agent 對話，不是 CI，也不是日常 Coding，卻是真實的長期推理服務，例如：

• 每小時整理 Runner / 應用日誌
• 每晚重建 embedding、清洗知識庫
• 自動產生日報、異常歸類、路由草稿
• 在 Claude Code 離線時仍更新 Context（L4）側資料

筆電合蓋就停，很難把這些當成「基礎設施」；與 L1 錯峰後，白天 Fact、夜間 Inference，對小團隊往往比「再買一張 GPU 雲」更現實——前提是 L2 已按 Service 來營運，而不是偶爾開終端機試模型。

本機 Mac 能跑，Cloud Mac 能營運

有人會問：「我家 Mac mini 也能 brew install ollama，為什麼非要 Cloud Mac？」 他說得對——本機 Mac = 可以跑；本篇講的差異在能不能當基礎設施營運。

選型與 L0 邊界見 Cloud Mac vs 本機 Mac AI 工作站；本篇不重複租機參數，只釘死：Stack 敘事裡，L2 要落在「能營運」的節點上。

L2 該接哪些工作負載

值得把 Ollama 當成 L2 基礎設施（而不只是試玩）的訊號，通常長這樣：

• 合規 / 氣隙邊界——程式碼與日誌可上 Cloud Mac，但推理請求不能進公有 API；L2 跑脫敏後的子任務（分類、摘要、PII 偵測）。
• Embedding / rerank——CodeGraph 或 RAG 管線需要穩定、可 pin 版本的本機向量模型，避免 API embedding 計費與資料路徑不可控。
• 高頻、小模型、可批處理——例如每晚對 CI 日誌做歸類；7B–14B 量化模型在 Apple Silicon 上性能够用，且成本可預測（對照固定節點 vs 按小時 GPU）。
• 與 L3 錯峰——白天 Claude Code + Runner 佔滿記憶體；夜間 ollama run 批處理，不把 24GB 機器當成「全天同時滿負載」。
• 多 Agent 裡的「快路徑」——複雜改動仍走 Claude；分類、路由、草稿產生走本機 8B，降低 API token（OpenHuman 等桌面 Agent 也常採用類似拆分，見OpenHuman 手記）。

反過來說，若你只做 iOS 交付、編碼全靠 Claude API、也沒有任何需要定時跑的本機推理，L2 的優先順序應低於 L1 Runner——先讓 push 有 Fact，再考慮私有 Inference。

系列閱讀順序：Runner → Ollama → Claude Code

若你按 Stack 系列追讀，建議順序與產出物一致：

1. L1 · Fact — GitHub Runner 執行引擎：push 之後程式碼是否真的建置、測試、交付。
2. L2 · Inference Service — 本篇：哪些 Token 必須留在 Cloud Mac 上，並以服務形態被呼叫。
3. L3 · Diff — Claude Code 工作站：儲存庫該怎麼改（多數走 API）。

底座與選型：Cloud Mac vs 本機 Mac AI 工作站。Context（L4）與 CodeGraph 等會在後續篇目接上 Inference 輸出。

典型誤判：裝了 Ollama，Stack 仍只有 API

1. 在 Cloud Mac 上 brew install ollama，拉了兩個模型，團隊慶祝「AI 棧齊了」。
2. 日常開發仍 100% Claude Code + Anthropic API；Ollama 一週未被任何腳本或 Agent 呼叫。
3. 記憶體常年被閒置模型佔用；Claude Code 與 Runner 搶占剩餘統一記憶體，Swap 升高（記憶體事實見16GB vs 24GB 文）。
4. 負責人問：「我們為什麼還要有 Cloud Mac？」——因為L0 只有機器，沒有定義 L2 工作負載。

修正方式不是再裝一個 GUI，而是指定 1–2 個必須走 L2 的 pipeline（例如：僅 CI 失敗日誌摘要走 Ollama；僅 embedding 走 nomic-embed-text），並 pin 模型版本、監控 11434 健康檢查。並行排班見 L2-Q03 · 記憶體排班。

誰可以跳過 L2

與已發實測文的關係（本篇不重複）

儲存庫裡已有幾篇「Ollama 相關」長文，分工如下，避免讀者以為重複選題：

• L2-Q02 · 16GB vs 24GB——記憶體與 Swap 實測；回答「買哪檔機器」，不回答「Ollama 在 Stack 哪一層」。
• L2-Q04 · M4 vs GPU 雲——帳單與規模邊界；本篇不比價。
• L2-Q05 · Core ML——Apple 原生推理路徑；可與 Ollama 並存，但是不同執行階段。
• L3 · Claude Code 工作站——編碼體驗；本篇補 L2，說明 API 編碼與本機 Inference 如何並存。

落地順序：Fact 之後再疊 Inference

與Runner 篇 · 接入順序一致，我們更推薦：

1. L0——Cloud Mac 常駐 macOS。
2. L1——Runner，讓 push → 綠/紅 可重複。
3. L2——Ollama 只接已定義的私有 Inference 管線（本篇）。
4. L3–L5——Claude Code、MCP、OpenHands，在 Fact +（可選）Inference 穩定之後擴展。

先堆 L2 再補 L1，會出現：本機模型摘要跑得歡，xcodebuild 仍在 Linux 上失敗——Inference 不能替代 Fact。

L2 專題連載

本篇是 L2 基石（定位與邊界）。同專題後續：

五層職責總圖仍錨定在 Cloud Mac AI Stack 五層結構圖。

常見問題

Claude API 也是推理，為什麼還要單獨一層 Inference？
Claude Code 產 Diff；L2 產 Token（摘要、embedding、批處理等）。關係是 Claude Code ⊂ Inference 應用，不是反過來。

Ollama 和 Claude Code 是二選一嗎？
不是。編碼走 L3 API；必須本機或定時跑的推理走 L2，見上文 對照表。

必須先裝 Ollama 才能用 Claude Code 嗎？
不必。L2 可選，與 L3 並行。

沒有合規需求還需要 L2 嗎？
若需要 24/7 持續推理（日誌、embedding、日報），獨立開發者與小團隊同樣值得立 L2；僅偶爾試模型可跳過。

本機 Mac mini 能跑 Ollama，為什麼還要 Cloud Mac？
本機能跑；Cloud Mac 能營運 Inference Service——24/7、與 Runner/Agent 同棧、可排班可觀測。見 本機 vs Cloud Mac。

Ollama 和 GitHub Runner 誰先誰後？
建議先 L1 再 L2。圖上的上下關係是職責層級，不是啟動順序。

本篇和 16GB vs 24GB 文有什麼不同？
本篇講 Stack 定位；記憶體實測見 16GB vs 24GB 文，成本見 M4 vs GPU 雲文。