← 返回技術筆記

On-premise AI · 8 分鐘閱讀

地端 LLM 導入前,
要先確認的五件事

「資料不出場域」是選擇地端部署的重要原因,但不是完整需求。模型大小、同時使用人數、回答品質與維護責任,都會影響最後的架構。

地端模型、私有資料來源與使用介面構成的系統架構

地端 LLM 專案常從「找一個模型裝起來」開始,但真正困難的部分通常出現在模型之外。若沒有先把使用情境、資料流與維運條件寫清楚,即使 Demo 表現不錯,也可能無法安全地接進正式流程。

01

資料不能出去,具體是不能去哪裡?

「地端」需要被拆成可檢查的邊界:原始文件是否能進入模型服務、索引能否放在另一個網段、操作紀錄可以保存哪些欄位、軟體更新時能不能連外。不同答案會導向完全不同的部署方式。

先問清楚
  • 哪些資料屬於機敏、個資或受契約限制?
  • 模型、向量索引、日誌與備份分別放在哪裡?
  • 外部 API 是否完全禁止,還是允許去識別後的特定用途?
02

先定義工作負載,不要先定義模型

摘要一份長文件、讓十位使用者查詢知識庫,和讓多個 Agent 持續執行工具,是三種完全不同的工作負載。需要先估算輸入長度、輸出長度、尖峰同時使用量、可接受等待時間,以及是否需要視覺或語音能力。

這些條件決定硬體、排程方式與模型規模,也讓 POC 能測到正式環境真正會遇到的情況。

03

硬體容量要用情境測,不只看規格表

模型是否放得進顯示記憶體,只回答「能不能啟動」。正式使用還要看上下文長度、量化方式、同時請求數與輸出速度。若系統還包含文件解析、Embedding、重新排序或影像處理,這些服務也會共同競爭資源。

容量模型、上下文、快取是否能容納
延遲首字等待與完整回答時間
吞吐尖峰時能同時服務多少工作
穩定長時間運行與失敗復原能力
04

模型選擇是多條件取捨

模型評估不該只看公開排行榜。中文能力、專業詞彙、工具呼叫、長文理解、授權條件、硬體需求與可替換性,都可能比單一分數更重要。最可靠的做法,是用自己的去識別化任務集比較候選模型。

同時保留替換空間:讓應用層、檢索層與模型服務分離,未來才能在不重做整個系統的情況下更新模型。

05

最後要有人能維護,而不只是有人會 Demo

導入前就要確認誰負責模型版本、提示與知識庫更新,誰能查看日誌,錯誤時如何切回人工流程,以及硬體或套件更新由誰測試。這些工作若沒有責任窗口,地端反而可能變成無人維護的黑盒子。

最小可行檢核

  1. 資料流與禁止範圍已寫清楚
  2. 工作負載與使用量有合理估算
  3. 使用真實任務測過容量與品質
  4. 模型與應用保留替換界面
  5. 更新、監控、備份與人工接手有人負責
下一篇RAG 的驗收,不能只看回答像不像

正在規劃地端 AI?

先帶著資料邊界、使用情境與現有硬體來談,我們可以一起縮小可行範圍。

討論導入條件