討論本機 LLM 時，往往從硬體開始：需要多少記憶體、哪張顯示卡合適，以及選哪種量化方式。對企業來說，這是第二個問題。第一個問題是：要改善哪個流程，什麼才算成功。同一個模型可能很適合為詢問分類，卻無法勝任具有法律效力的回覆草擬。
可以把選擇分成四個面向：資料敏感性、可接受延遲、負載特性，以及團隊營運服務的能力。只要其中一項未明確定義，模型比較就會淪為展示規格，而無法形成業務決策。
資料：本機不代表自動安全
本機模型減少對外傳輸次數，但不會取代存取控制、記錄、備份與工作裝置保護。文件即使留在內部網路，仍可能進入權限設定錯誤的共用記錄、快取、向量儲存或備份。先畫出從上傳到刪除的完整資料路徑。
對雲端也要提出相同問題：請求在哪裡處理、輸入是否保留、能否停用使用資料訓練，以及保存期限與合約保障如何安排。比較具體資料流與各方責任，而非「private」或「enterprise」等行銷用語。
延遲、上下文與實際負載
本機模型適合靠近資料進行短而頻繁的操作：分類、欄位擷取、草稿與內部搜尋。對偶發的尖峰請求，雲端往往更合理：無須讓加速器閒置，也不必自行擴充佇列處理能力。
對代理與程式碼任務而言，上下文成本尤其高。Ollama 明確指出，上下文視窗增加會提高記憶體消耗。因此，「模型回答了一個問題」這項測試，無法說明它能否支援需讀取數十份文件、呼叫工具，並同時服務多名使用者的流程。
硬體與量化：別迷信規格
llama.cpp 能在不同 CPU 與 GPU 上執行量化模型，包括將模型分配於處理器與顯示卡記憶體的混合方式。這降低了試行門檻，卻不保證品質符合需求。更高壓縮程度能節省記憶體，但可能犧牲準確度，特別是在複雜指令與結構化輸出中。
用自己的任務集測試三種模型規模。小型模型可能足以穩定處理郵件分流，中型模型負責擷取與摘要，複雜例外則交給雲端模型或人。混合架構往往比勉強讓一套系統包辦所有工作更省成本。
成功操作的成本
本機方案的成本包含硬體或租用、電力、備援、更新、監控、工程師時間與停機代價。雲端則包含 token、網路延遲、限制、儲存、企業功能與更換供應商的成本。共同的比較單位不是請求，而是企業無須人工重做便接受的操作。
- 無須修正即可接受的答案比例。
- 取得結果的平均時間與第 95 百分位數。
- 重試與人工檢查的成本。
- 存取事件、失敗與格式違規的次數。
- 團隊每週花在維護上的時間。
能夠結束的試行
選擇一個有明確負責人的流程，以及 50–100 個去識別化範例。訂出標準答案、品質標準與可接受的錯誤成本。使用相同資料比較本機、雲端與混合架構。試行為期兩週，最後做出決定：導入、調整任務，或放棄。
本機 LLM 是部署選項，而非信仰。當資料限制與負載特性能轉化為可衡量的優勢時，它才值得採用。如果團隊未準備好維護服務，或真實例外情況的品質低於門檻，雲端或混合方案會是更可控的選擇。
不自欺的計算範例
假設一個部門每月為 4 萬筆詢問分類。雲端模型連同重試請求，每月花費 9 萬盧布；本機伺服器一次支出 42 萬盧布，每月另需 7 萬盧布，支付營運與工程師部分工時。只比較 9 萬和 7 萬並不足夠：本機模型有 82% 的答案無須修改，雲端則有 94%，而人工處理一個例外需 25 盧布。品質差異會讓本機方案增加約 12 萬盧布的人工成本。如此一來，「自己的 token 比較便宜」便不再是有力論點。
接著進行敏感度分析。如果量加倍、雲端價格降低、需要備援伺服器，或新詢問格式導致品質下降，會怎樣？另外訂出一小時服務中斷的成本，以及團隊必須在多久內安裝安全更新。這能讓討論從顯示卡規格轉向服務承諾。
依資料與任務選擇部署方式的矩陣
- 公開文字與不規則負載：雲端通常能更快起步。
- 允許提供給供應商的內部文件：採用企業條款的雲端或混合方案。
- 不允許使用外部環境的受監管資料：檢查整條處理鏈後採用本機部署。
- 大量、範圍狹窄的分類：若樣本已驗證品質，可用小型本機模型。
- 少見的複雜例外：分流至更強的雲端模型或人員。
混合不代表對每個請求隨意選模型。分流規則應明確且固定：資料類型、任務類別、可接受延遲與信心門檻。記錄保存分流原因，但不保留多餘的請求內容。如果本機模型未遵守格式，或評分低於門檻，系統不臨場發揮，而是採用預先指定的安全路徑。