把健檢報告、用藥清單或長期量測紀錄交給 AI 整理時，很多人第一個會先想到：模型能不能在自己的電腦跑。資料是否離開家中網路、由哪一臺機器運算、誰能登入，分別由不同軟體層處理。

NVIDIA PAIR、Ollama、llama.cpp 與 Open WebUI 常被放在同一張比較表，四者的角色卻不相同。PAIR 負責把請求路由到區域網路中的可用設備；Ollama 與 llama.cpp 負責載入模型並執行推論；Open WebUI 則提供瀏覽器介面、帳號與多人協作能力。選擇的起點應是使用情境與風險邊界，之後才輪到版本、顯示卡與速度。

一、PAIR、Ollama、llama.cpp 與 Open WebUI 差在哪裡？

四者位於不同層級。PAIR 是跨設備路由器，Ollama 與 llama.cpp 是模型推論工具，Open WebUI 是供人登入、對話及管理內容的網頁介面。

先把角色分清楚，後面的比較才有意義。一次本機問答至少包含四個環節：使用者在介面輸入問題、介面把請求送到推論服務、推論服務載入模型運算、結果再回到介面。若有多臺電腦，還會多出「這次請求該送往哪一臺」的決策。

NVIDIA 官方將 Personal AI Router（PAIR）定義為本機推論路由器。應用程式只需連到工作電腦上的本機位址，PAIR 會查看叢集內各節點擁有的引擎、模型與工作負載，再選擇服務請求的設備。它目前提供 Ollama 相容及 LM Studio／OpenAI 相容代理，因此可以加入既有工具鏈，不必要求上層應用理解 PAIR 的存在。

Ollama 把模型下載、啟動、API 與硬體加速包成較容易操作的體驗，適合希望少碰編譯參數的個人。llama.cpp 更接近底層推論引擎與開發工具箱，可用 CMake 編譯 llama-server，也能精細調整模型、上下文、GPU offload 與伺服器參數，代價是操作者要承擔較多測試工作。

Open WebUI 不會憑空增加模型可用的記憶體。它可連接 Ollama 或其他相容後端，提供瀏覽器聊天、帳號、角色、群組與權限。若一家人要分開登入，或小型團隊需要管理誰能用哪些資源，這一層才是多人使用的主要入口。

「PAIR 不會把多臺裝置合成一張虛擬 GPU；各裝置仍各自處理平行工作。」— NVIDIA Personal AI Router 官方 FAQ

二、為什麼多一臺電腦，不代表單一模型一定跑得更大？

不能把 PAIR 理解成顯示記憶體合併器。官方說明的重點是分派彼此獨立的推論請求，並未把多臺設備組成一張虛擬 GPU。

這是本題最容易解錯的地方。假設一個模型在單一節點需要的記憶體超過該節點容量，多放一臺電腦進 PAIR 叢集，不會因此讓該模型自動跨機載入。PAIR 的價值出現在同時有多項工作時，例如一個代理把「整理量測趨勢」「比對藥名」「建立回診問題」拆成三個獨立請求，各節點便有機會平行服務。

NVIDIA 的 PAIR beta 支援圖形與終端介面，官方列出的驗證硬體包含 GeForce RTX 20 系列以上、Turing 以上 RTX PRO、DGX Spark，以及 Apple M4 以上裝置；頁面同時列出至少 8 GB RAM、建議 20 GB 儲存空間。這些數字是軟體可安裝或已驗證組合的門檻，不代表任何模型都能在 8 GB 記憶體內順利運作。

模型大小、量化格式、上下文長度與同時請求數，才會共同決定實際記憶體需求。Ollama 官方文件指出，增加上下文長度會提高記憶體使用量，並依顯示記憶體容量設定不同的預設上下文。要整理一整年份的健康紀錄，不能只問顯示卡型號，還要先估算文件切分方式、每次送入多少內容，以及是否真的需要長上下文。

llama.cpp v0.4.0 增加按需張量讀取、伺服器每個 slot 的上下文上限及多項後端改善，也持續擴充影像、音訊與影片輸入相關能力。這些功能讓技術使用者有更多調校空間，初始模型支援仍可能有待優化。官方伺服器文件也明確把多模態標為實驗性功能，涉及掃描報告或圖片辨識時應逐模型驗證，不宜只看「支援多模態」五個字。

PAIR 路由器把三個獨立請求分送至三臺電腦，旁邊以叉號標示不能將多機顯示記憶體合併。
PAIR 能分散彼此獨立的工作，但不會把多臺設備的顯示記憶體合成單一資源。

三、四種工具的硬體、部署、隱私與多人使用怎麼比？

應分別比較運算門檻、安裝維護、網路邊界與帳號治理。若只用速度或模型數量排名，很容易把不同層級的工具選錯。

工具在系統中的角色硬體與部署門檻隱私邊界多人使用
NVIDIA PAIR beta跨節點發現、配對與請求路由需官方驗證的平台與硬體；每臺參與設備都要安裝並配對請求可留在家中網路，節點間仍須建立可信任邊界能分散獨立請求，但不負責完整使用者帳號治理
Ollama v0.33.3模型管理與推論服務入門操作較集中；實際容量取決於模型、量化、上下文及 CPU／GPU預設本機使用較直觀，對外開放 API 後風險隨之改變可服務多個請求，帳號與細緻權限通常要交給上層介面
llama.cpp v0.4.0底層推論引擎、函式庫與伺服器可調範圍大，也較需要編譯、參數與相容性知識可只監聽本機位址；改成區網服務時需自行補安全控制有平行與 slot 設定，完整身分治理仍需其他元件
Open WebUI v0.11.3網頁介面、帳號、角色與內容管理官方快速安裝以容器為主；另需連接推論後端會保存帳號、聊天及設定，資料卷與備份也納入保護範圍原生支援多使用者、角色、群組及權限，較貼近共享入口需求

表中的版本是本文核對功能的時間切片，不應被當成永久建議。Ollama v0.33.3 的官方 release note 記載 MLX 引擎的 Gemma 4 新增影像與音訊支援，也更新 MLX、MLX-C 與 llama.cpp。這說明其整合速度快，但模型、引擎與硬體三者仍需一起核對。

Open WebUI v0.11.1 加入逐次工具核准，並重做串流機制以改善多人繁忙環境；v0.11.3 又修正資料庫升級失敗時仍半套啟動等問題。官方安裝文件建議正式環境固定特定版本，不要長期追隨浮動標籤。健康紀錄一旦進入聊天資料庫，升級前備份、還原演練與版本變更紀錄都屬於部署工作，不能只留下「容器有跑起來」的驗收結果。

四、本機運算為什麼仍不等於健康資料安全？

本機運算只降低資料傳往外部雲端的需求，無法代替帳號控管、磁碟加密、網路隔離、備份保護、更新與操作紀錄。

要先看問題背後的問題。雲端外洩只是風險之一；同住者共用帳號、瀏覽器保留對話、容器資料卷未加密、路由器密碼過弱、備份硬碟遺失，以及工具能讀取過多資料夾，都可能讓健康紀錄暴露。PAIR 官方說明跨節點流量採相互 TLS，叢集也會拒絕非成員設備，但配對 PIN 只是交換信任的便利碼，並非強式驗證。配對只能在信任的網路與設備間進行。

PAIR 把資料邊界從「一臺電腦」擴大為「所有已配對節點及區域網路」。容量增加的同時，修補、帳號、實體接觸與惡意程式的攻擊面也跟著增加。家中一臺多年未更新的舊電腦，加入叢集後就成為整體風險的一部分。

Open WebUI 的多人功能解決了登入入口，沒有自動完成全部治理。官方文件說明權限採累加模式，群組只會增加能力；API 金鑰會繼承建立者的完整權限。管理者因此要定期檢查群組、金鑰與待核准帳號，還要確認對話、上傳檔案、知識庫與備份各自存放在哪裡。

臺灣使用者若只整理自己的資料，仍應採取基本防護；若替家人、客戶、受試者或機構處理可識別健康紀錄，責任範圍會明顯擴大。部署時應逐項檢查加密、備份保護、傳輸安全、認證、異常存取監控、漏洞因應，測試階段也應避免使用真實個資。適用義務要依實際身分與用途確認，開源或本機部署不會讓責任消失。

「多模態支援目前仍屬實驗性功能。」— llama.cpp llama-server 官方文件

六張並列卡片呈現獨立帳號、磁碟加密、資料卷保護、可信任區網、備份防護與外部連線管制。
資料不送上雲端仍不等於安全，帳號、儲存、區網、備份與外部連線都必須分別設防。

五、個人、家庭與小型團隊各適合哪一種組合？

單人入門可先用 Ollama；需要細部調校可選 llama.cpp；多臺相容設備且有平行工作才評估 PAIR；需要多人登入與權限時，再加上 Open WebUI。

單人整理自己的報告：先縮小系統

若需求只是把一份已去識別的健檢資料整理成問題清單，一臺現有電腦、Ollama 與合適的小型模型通常較容易建立第一個可驗證流程。先測輸出是否忠實引用原始欄位，再評估是否增加視覺模型或更長上下文。Open WebUI 可作為較友善的介面，但單人使用也要保護它的資料卷。

llama.cpp 適合願意自行處理 GGUF 模型、量化、編譯後端與啟動參數的人。它能讓操作者更精準控制資源，對低階或特殊硬體也有探索空間。維護負擔同樣更高，模型更新、參數變更與輸出差異都要留下測試紀錄。

家中已有多臺相容電腦：先確認工作能否拆開

PAIR 適合的問題是「多個獨立請求擠在同一臺機器」，例如不同家庭成員各自使用，或代理同時執行數項任務。若真正瓶頸是一個超過單機容量的大模型，應改從較小模型、量化、縮短上下文或單機硬體升級評估。把不相干的舊設備全部加入，不一定能改善體驗。

PAIR 可使用既有 Ollama，官方入門文件也說明它能安裝或偵測 Ollama／LM Studio。部署時要區分 PAIR 的代理連接埠與各節點引擎連接埠，否則檢查到的可能是叢集模型清單，而非單機實際安裝內容。這類網路與服務辨識，會比圖形介面上的「已連線」更接近真正的維運需求。

家庭共用或小型團隊：把身分與資料分區

需要多人登入時，可用 Open WebUI 連接 Ollama 或相容後端，再按角色限制功能與資源。官方快速安裝提供 CPU、GPU 及內含 Ollama 的容器方式，也提醒切換成無登入的單人模式後，不能再改回多帳號模式。初始化以前就應決定是否共享，避免為了省一步而撤掉身分邊界。

健康資料不宜放進所有成員都能搜尋的共用知識庫。即使是家人，也要分開個人空間、共用資料與管理者權限；對外分享前先移除姓名、身分證字號、病歷號、地址與可回推個人的組合資訊。模型輸出只能協助整理與提出待確認問題，不能替代醫療專業判斷。

六、部署前怎麼做一次可回復的評估？

先用去識別的小樣本驗證單機流程，再量測容量、畫出資料流、設定權限與備份，最後才增加多人介面或 PAIR 節點。

  1. 定義資料與目的：列出要處理的欄位、資料來源、保存期限及預期輸出，先排除不需要送進模型的識別資訊。
  2. 選一個最小模型測試：用合成或去識別資料測正確性、速度、記憶體與上下文，不用真實病歷做第一次試跑。
  3. 畫出資料流：標示瀏覽器、Open WebUI、推論引擎、PAIR 節點、模型下載來源、聊天資料庫與備份位置。
  4. 鎖定版本與介面：記錄 Ollama、llama.cpp、Open WebUI、模型及驅動版本；正式環境固定映像標籤，升級前另建測試環境。
  5. 設定信任邊界：只監聽必要網路介面，為每位使用者建立獨立帳號，關閉不需要的工具與外部連線，保護磁碟及備份。
  6. 做失敗演練：測試節點離線、模型載入失敗、資料庫升級失敗與備份還原，確認失敗時不會轉送到未核准的雲端服務。
  7. 再決定是否擴充：單機請求排隊才考慮 PAIR；需要帳號隔離才加入 Open WebUI；需要深度調校才轉向 llama.cpp。

這套順序可以降低返工。先裝滿所有元件，出錯時很難知道根因位於模型、推論引擎、路由、介面或網路。從單機最小流程起步，才能把性能改善和風險變化分開觀察。

七個箭頭串聯的部署流程，從界定資料用途、去識別測試與資料流盤點，依序走到安全設定、還原演練及需求驗證後擴充。
先完成可驗證、可保護且可還原的單機流程，再依實際瓶頸增加介面或運算節點。

七、選擇結論：先選層級，再選產品

先找出目前缺的是推論引擎、跨機路由或多人介面，再選對應工具。健康紀錄的優先條件應是資料邊界可說明、權限可控、版本可回復，之後才比較效能。

PAIR 為家中多臺相容設備提供了新的調度方式，適合平行請求與代理工作流。Ollama 降低模型執行與管理門檻；llama.cpp 提供較深的硬體與推論控制；Open WebUI 補上多人操作、帳號與內容管理。它們可以組合，也可以只用其中一部分。

真正有效的設計，是從源頭減少不必要的資料流動。個人先從去識別、小模型、單機與本機監聽開始；需求證明單機不足後，再增加介面、節點與共享。每增加一個元件，都要能回答它讀了什麼、把資料送到哪裡、誰可存取，以及故障後怎麼還原。

  • PAIR 分派獨立請求，不會自動合併多臺電腦的顯示記憶體。
  • Ollama 偏向易用的模型執行與管理；llama.cpp 偏向可調校的底層推論。
  • Open WebUI 負責多人入口與權限，仍要保護聊天資料庫、上傳檔案及備份。
  • 本機只是一道資料邊界，還要搭配加密、認證、最小權限、更新與還原演練。
  • 健康資料先去識別並縮小範圍，AI 輸出只作整理與提問輔助。

常見問題

Q1: 沒有 NVIDIA 顯示卡，可以使用本機 AI 嗎？

可以。Ollama 支援 Apple Metal 與多種 NVIDIA、AMD 硬體，llama.cpp 也提供多種後端及 CPU 執行方式。速度與可用模型大小會因硬體而異。PAIR 則要依 NVIDIA 官方列出的驗證平台與硬體評估。

Q2: PAIR 可以讓兩張 8 GB 顯示卡直接跑需要 16 GB 的單一模型嗎？

不應如此假設。PAIR 官方定位是把獨立請求送到有容量的節點，各設備仍是分開的系統。單一模型是否能跨 GPU 或跨節點，要看推論引擎的特定能力與設定，不能由 PAIR 的多機路由推導。

Q3: Open WebUI 已有登入，就能直接放全家人的健康紀錄嗎？

還不夠。仍需分開帳號與資料空間、限制管理者及 API 金鑰、保護資料卷和備份，並確認每個後端連線的目的地。若處理他人或機構資料，還要確認同意、用途與適用規範。

Q4: 本機模型可以解讀健檢報告並直接給治療建議嗎？

可用於整理數值、摘要內容與產生回診提問，但模型可能誤讀單位、參考區間或病史脈絡。異常判讀、診斷及治療仍應由合格醫療專業人員依完整情況處理。