「本地」不是一個成本答案

當團隊開始在意資料不離開裝置，本地 AI inference 很自然會變成選項。討論通常很快收斂到模型有幾個參數、需要多少 VRAM，以及某張 GPU 能不能跑起來。但能跑起來，只代表一次推論成功，還不代表它適合成為可靠的產品元件。

本地部署的成本至少包含四層：硬體與電力、模型與 runtime、資料與更新流程，以及團隊維護的時間。如果只比較模型大小，很容易低估後三層。

先把需求分開

不同任務對 inference 的要求不一樣。個人筆記摘要在意的是互動延遲與安靜的背景運作；內部程式碼搜尋更在意 context 長度與索引更新；離線裝置可能最在意穩定性與電池。這些需求會決定你該優先投資在模型、硬體，還是資料處理。

可以先寫下四個問題：

  • 哪些資料因為隱私或連線限制，必須留在裝置上？
  • 使用者能接受幾秒的等待，還是需要接近即時的回應？
  • 模型輸出的錯誤，會造成不便、成本，還是安全風險？
  • 模型多久需要更新一次，更新時能否安全回滾？

把這些問題回答清楚後，模型大小才有比較的意義。

量化不是免費的縮小

Quantization 可以降低記憶體需求，讓較大的模型進入更小的裝置，但它同時改變了速度、品質與相容性。某些任務對數值精度很敏感，某些 runtime 則對特定格式有更好的支援。選擇量化版本時，應該用自己的工作資料做小型 benchmark，而不是只看檔案大小。

一個可行的 benchmark 不需要很複雜：準備一組不含敏感資料的代表性輸入，記錄首 token 延遲、完整回應時間、記憶體峰值與人工評分，再比較不同模型與 quantization level。最重要的是保留輸入與評分規則，讓下一次更新仍能重跑。

Runtime 與更新才是長期工作

本地模型不是放進應用程式就結束。你仍然需要處理 runtime 版本、不同晶片的 backend、模型檔案完整性、cache 佔用與失敗時的 fallback。若應用會在多種作業系統上運作，測試矩陣會比模型本身更快膨脹。

更新也應該被當成 deployment 流程的一部分。新模型先在固定 benchmark 上比較，再分批送出；保留上一個可用版本，並且讓使用者知道目前執行的是哪個 model revision。這些做法看似偏向傳統工程，卻是讓本地 AI 從 demo 走向產品的必要條件。

隱私帶來的收益，也帶來責任

資料不離開裝置可以降低某些傳輸風險，但不代表資料自動安全。log、cache、crash report 與模型輸入仍可能留在本機。設計本地 AI 時，應該一起檢查儲存、刪除與權限，並讓使用者知道資料會留在哪裡。

最後，本地 inference 值不值得，取決於它是否真的解決了你的限制。若主要需求是低延遲、離線或資料邊界，本地模型可能很合理；若需求是最高品質與快速更新，雲端服務可能仍更適合。好的架構不是堅持某一種部署，而是讓選擇可以被測量、被替換。