自建 LLM 的三個隱形成本——硬體、隔離、架構
自建 LLM 的成本不只在算力，硬體、隔離、架構的決策都會產生隱形開銷——而且通常被低估。
硬體成本是真實的，不是優化問題
很多團隊在評估自建 LLM 時，會先問「用什麼模型」，然後問「怎麼量化」。但實際的瓶頸往往更早出現：120B 參數模型的顯存占用（70GB+）根本超過消費級顯卡的上限。量化能幫助降低成本，但它只是必要條件，不是充分條件。
這不是說不能用便宜卡。而是說硬體選擇的決策邏輯應該反過來：先確認生產環境的實際顯存需求，再看什麼卡能滿足，而不是反過來被消費級硬體的上限所困。很多團隊低估了這個差距，導致到了部署階段才發現架構要推倒重來。
容器隔離沒有你想的那麼安全
容器的吸引力很明顯：環境一致、部署簡單、隔離看起來很清楚。但如果你在跑敏感的推理任務——比如處理用戶數據或內部知識——容器本身並不能保證安全邊界。
更務實的做法是承認容器有侷限，然後根據威脅模型選擇隔離層級。一個參考方案是「隔離網段 + 開源驅動 + 容器」的組合：不依賴容器作為唯一的信任邊界，而是用多層防禦。這意味著你要明確回答一個問題：什麼攻擊面你最在乎？然後針對那個面設計隔離策略。
架構決策比防火牆規則更有效
團隊通常會優先考慮防火牆、加密、認證這些正向防禦。但有時候最簡單的安全設計是「根本上消除攻擊面」。
比如用 Unix socket 替代 TCP 來做本地推理服務的通信。這不是加密或限制，而是從架構層面決定：如果推理服務不需要跨網路，就不要暴露 TCP 端口。最安全的網路就是沒有網路。
這對自建系統特別重要。因為你不像雲服務商有專門的安全團隊，所以每個決策都要問：這個選擇會帶來什麼新的攻擊面？有沒有辦法在架構層面就避免它？有時候協議的選擇（TCP vs Unix socket）比防火牆規則更能決定系統的安全性。
隱形成本的共同點
硬體、隔離、架構這三個層面有個共同特徵：都很容易在規劃階段被低估，因為它們不像算法精度那樣有明確的指標。但到了生產環境，它們會直接影響成本和風險。
如果你在考慮自建 LLM，值得花時間問清楚：顯存真的夠嗎？隔離層級符合威脅模型嗎？有沒有辦法在架構層面簡化安全設計？這些問題的答案，往往比「選哪個模型」更決定成敗。
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。