跳到主要內容

【2026 最新】三台本機 AI 怎麼協作？LiteLLM Gateway 路由與 Agent 派工 5 步教學

最後更新： ·
三台本機 AI 協作 教學首圖

家裡一台桌機、一台 Mac mini、一台 Raspberry Pi 都跑得動本機模型，你想把它們接成一個 AI 幫手。這時最容易混淆的是：三台模型共用一個網址，和一件工作拆給三台完成，其實是兩個不同問題。這篇「三台本機 AI 協作」教學，帶你分開建置、逐層驗收。

本文寫給已經能在至少一台裝置啟動本機模型、但第一次碰 Gateway 與 Agent 派工的讀者。你會拿到一張三機拓樸、一份 LiteLLM 設定範本、一個 Planner／Worker 工作追蹤，以及斷線時的驗收方法；範例中的機型、模型與私網位址請換成自己的。

先說結論：三台本機 AI 協作有兩層

一句話記住：Gateway 決定「這次模型呼叫送去哪台」；Harness 決定「整件任務拆成哪些工作、誰做、怎樣驗收」。前者像總機，把一通電話接到指定分機；後者像專案負責人，先拆工作、派人、檢查結果，再決定要不要重做。

  • 只想讓不同 App 共用一個 OpenAI 相容入口：先做 Gateway。
  • 想讓桌機規劃、Mac 摘要、Pi 分類：另加 Planner／Worker 流程。
  • 想要斷線仍能交付：同時設計模型呼叫的回退，以及任務層的重新指派與驗收。

2026 年 9 月的一則 r/LocalLLaMA 三機提問 把痛點說得很具體，但它只是一個案例，不能代表普遍需求。以下方法以 LiteLLM 官方 Gateway 文件、LiteLLM 的 Ollama 接法 與 Ollama 網路設定 為準。

先畫三台機器：能力、位址、故障邊界

別先問哪個模型「最聰明」。先為每台裝置寫一張能力卡：它能穩定處理的任務、實際模型名稱、私網位址、誰會在它斷線時接手。以下是示意配置，不是硬體效能測量，也不是對任何模型能力的評分。

  • 桌機 A：192.168.1.10:11434；規劃與最後整合。先用你已驗收的較強模型。
  • Mac mini B：192.168.1.11:11434；長文摘錄與摘要。保留原文段落位置，讓桌機核對。
  • Raspberry Pi C：192.168.1.12:11434；有限標籤分類。先用有標準答案的小樣本檢查。
  • Gateway：放在能連到三台裝置的電腦，例子為桌機 A 的 127.0.0.1:4000。它本身也形成一個故障點。

先從 Gateway 主機逐一讀 http://192.168.1.10:11434/api/tags、B 與 C 的同一路徑，確認網路可達、模型名稱確實存在。Ollama 官方說預設綁在 127.0.0.1:11434；跨機連線要設定 OLLAMA_HOST，並按 macOS 或 Linux 的服務啟動方式重啟。只在可信私網開放對應連接埠，別把未加保護的模型服務直接暴露到公網。

三台本機模型經 Gateway 接入 Planner 與 Worker 派工流程
一條線表示一次模型呼叫；上方的 Planner／Worker 才決定工作如何拆分與驗收。

第一步：用 LiteLLM 把三台本機 AI 接成單一 API

先在各機跑好 Ollama，確認 ollama list 顯示你實際下載的模型名稱。LiteLLM 使用 model_name 當對外別名，litellm_params.model 指向後端模型。官方 Ollama provider 文件 建議聊天請求採 ollama_chat/ 前綴，並用 api_base 指向服務位址。

在 Gateway 主機把下面內容存成 litellm_config.yaml。YOUR_DESKTOP_MODEL 等三個值必須換成各機 ollama list 所見的完整名稱；私網 IP 也要換成自己的。

model_list:
  - model_name: desktop
    litellm_params:
      model: ollama_chat/YOUR_DESKTOP_MODEL
      api_base: http://192.168.1.10:11434
  - model_name: mac
    litellm_params:
      model: ollama_chat/YOUR_MAC_MODEL
      api_base: http://192.168.1.11:11434
  - model_name: pi
    litellm_params:
      model: ollama_chat/YOUR_PI_MODEL
      api_base: http://192.168.1.12:11434

依 LiteLLM 官方 CLI quick start，可用 uv tool install 'litellm[proxy]' 安裝後執行 litellm --config litellm_config.yaml。先從 Gateway 主機用 127.0.0.1:4000 發送測試請求，並用主機防火牆限制外部連入；要讓其他 App 從網路連進來，再依 官方 Gateway quickstart 配置認證與部署。

用同一個網址連續送三次請求，只換 model 為 desktop、mac、pi；對外 API 形狀相同，目標機器不同。

curl http://127.0.0.1:4000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"mac","messages":[{"role":"user","content":"請把這句話縮成十字內：三台電腦各自跑本機模型。"}]}'

如果你設定了 LiteLLM master key，請依官方文件加上 Authorization: Bearer <你的 key>。先逐台確認返回的是合法回應，再進入派工；三個 model alias 都可呼叫，只證明路由通了，還不代表任務能協作。

第二步：讓 Planner／Worker 真正派工

用一個「整理三份會議紀錄」的任務來看差別。桌機上的 Planner 先寫出任務清單：Mac 對每份紀錄各產生一段摘要並標明段落；Pi 只把每份紀錄分成「決策／待辦／背景」；桌機最後拿原文核對並整合。每個 Worker 回傳的是工作成果，不是直接把下一步權力交給另一台模型。

把任務拆成 5 個有收據的動作

  • ① 建立任務：記下任務 ID、輸入檔案雜湊、預期輸出與截止時間。原文仍保存在受控工作目錄。
  • ② 路由呼叫：Planner 對 Gateway 的 mac 別名送摘要請求，對 pi 送分類請求。Gateway 只處理這些獨立模型呼叫。
  • ③ Worker 回報：每個結果附任務 ID、模型別名、開始／結束時間、成功或錯誤、引用的原文片段位置。
  • ④ 人工可驗收：桌機對照原文，檢查摘要有沒有漏決策、分類是否符合事先寫好的標準答案。錯誤要能回到原片段。
  • ⑤ 完成或重派：只有檢查通過才標成完成。Mac 失聯時，Planner 可以把摘要改派桌機；Pi 分類失敗則先保留「待人工判定」。

這是流程偽程式碼，刻意省略了佇列持久化、併發控制、逾時後重複執行防護與檔案權限；要落地時應在每個 Worker 呼叫前後補齊這些控制。Agent Harness 實作篇把工作狀態與停止條件拆得更細。

job = save_job(input_hash, acceptance_rules)
summary = call_gateway(model="mac", task=job.summary_task)
labels  = call_gateway(model="pi", task=job.label_task)
if summary.error: summary = call_gateway(model="desktop", task=job.summary_task)
if labels.error:  labels = mark_for_human_review(job)
result = verify_against_original(summary, labels, acceptance_rules)
save_receipt(job.id, result)

特別留意 verify_against_original：它是應用程式與人的驗收步驟，不是多呼叫一次模型就能自動保證正確。若任務涉及改檔、送信或交易，還要另設權限與人工核准。

第三步：分開驗證路由回退與任務接力

LiteLLM 官方 fallback 文件 區分模型群組內的 retry，與失敗後轉到另一模型群組的 fallback；請求也可附 fallbacks 清單。你可先在低風險測試輸入中，請求 mac 並指定 desktop 作備援，關閉 Mac 服務後觀察回應與 Gateway 紀錄。

但回退成功，只代表某次呼叫拿到答案。如果 Mac 正在替整份文件分段摘要，原來的工作切片、已完成段落與接受標準仍由 Harness 保存；它應決定重派哪一段、如何避免重複、是否需要重新驗收。小模型也不能只因 API 相容就接手原先更難的任務。

  • 測路由：三個別名逐一成功；指定一台關閉後，記錄 HTTP 狀態、實際回退目標與總耗時。
  • 測派工：讓 Mac 在第二份摘要前失聯；檢查只重派未完成工作，最後能說明每段由誰完成。
  • 測品質：準備有人工標註答案的少量固定樣本，逐項核對摘要遺漏和 Pi 的錯誤分類。
  • 測延遲：同一批輸入分別跑單機與派工流程，各自記錄排隊、模型生成、網路與重試時間；不要只比一個總秒數。

本文沒有三台機器的第一手速度或正確率數值；讀者應保留自己的設定、版本、樣本與收據後再比較。LLM 故障演練教你把 5xx、429 與串流中斷放進同一張驗收表。

怎麼選：你需要 Gateway、Harness，還是兩者？

  • 只想統一入口：用 LiteLLM 的模型別名連三台，先驗收單次請求。
  • 想讓多台各做一段工作：要一個保存任務、結果與驗收規則的 Harness；Gateway 只是它呼叫模型的入口。
  • 想在一台失聯後仍完成：同時設計請求層 fallback 與任務層重新指派，並用故障注入驗收。

這也解釋了為什麼「三台都能回答」與「三台一起把事做對」距離很遠。Agent Harness 是什麼從單一 Agent 的循環說明執行層；LiteLM 路由教學則對照應用內 library 與完整 Gateway 的責任邊界。

常見的 4 個坑

  • 把 0.0.0.0 當成安全設定：它會讓服務綁到網路介面；先縮在可信私網，限制能連入的主機，再設 Gateway 認證。
  • 把別名當成任務角色：model_name: mac 只是一個路由名稱。要有工作拆解、狀態與驗收，才談得上派工。
  • 只看回答內容不看路徑：回退後應記錄實際模型、錯誤、耗時與輸入版本，不然很難分析品質漂移。
  • 讓小模型硬接難題：先用固定任務與標準答案檢驗。失敗時保留待人工判定，也是一種正確系統行為。

FAQ：三台本機 AI 協作的 8 個問題

LiteLLM 會自動把一個任務拆成三份嗎？

不會由上述 Gateway 設定做到。它把模型呼叫導向對應後端；任務拆分要在 Harness 裡寫清楚。

一定要三台機器嗎？

不用。一台機器開多個模型別名也能先練路由與派工流程；跨機才多了網路故障邊界。

三台平行跑一定比較快嗎？

不一定。最慢工作、網路、排隊、重試與整合驗收都影響完成時間。

Pi 的小模型能當分類 Worker 嗎？

先驗收再決定。拿固定標籤樣本測錯誤分類，達不到接受標準就保留人工流程。

模型別名和實際模型名稱一樣嗎？

不一樣。model_name 是 Gateway 對外名稱；litellm_params.model 是指向後端的模型標識。

Mac 斷線時 fallback 和重派有何不同？

fallback 補的是一次請求。重新指派還要判斷整件工作有哪些片段完成、哪些要重試。

可以把 Ollama 直接開在網際網路嗎？

先別這樣部署。跨機測試只需要受控私網；對外服務須另設認證、網路隔離與監控。

怎樣知道派工真的改善了系統？

拿同一批標準答案比較。同時記錄完成時間、正確率、失敗恢復與人工介入量。

給新手的 3 個重點

  • Gateway 是「這通電話接哪台」；Harness 是「整件工作誰做、怎樣交付」。
  • 先逐台驗收模型呼叫，再加任務狀態、收據與故障注入。
  • 比較派工價值時，把品質與恢復能力和延遲一起看。

結語：先接通，再派工，最後故意斷一次線

回到開頭那句話：Gateway 管一次呼叫的去向，Harness 管整件工作的拆分與驗收。今天先畫出你家三台裝置的能力卡，讓同一個 Gateway URL 逐一叫到三個模型別名；明天再拿一份可人工核對的小文件做 Planner／Worker 練習，最後關掉其中一台，確認收據能說清楚系統發生了什麼。想繼續系統學習，可從 AI 主題文章 與 AlphaLab 課程 挑下一步。

ALPHALAB 社群

有問題？來 Telegram 聊

和 Terry、編輯、其他網友一起討論這篇文章。提問、分享觀點，回覆更即時。

加入 Telegram 討論

📩 訂閱 AlphaLab 電子報

每週最多三封：一封 Weekly 週報與最多兩封關鍵 Alpha Signal。

我們不會 spam，隨時可退訂。