資料不出內網是硬要求時，先別急著買卡——把「跑得動」和「跑得穩」分開算，硬體預算能差一半
| 維度 | 架構 A：全本地部署 | 架構 B：混合部署 | 架構 C：內網 API 閘道 |
|---|---|---|---|
| 資料邊界 | 全部留在內網，模型和推理都在自己機房 | 敏感資料本地，通用問答走外部 API | 資料在內網，模型可自建也可外接 |
| 硬體投入 | 高：GPU 伺服器 + 機房 + 維運 | 中：小規格 GPU 或純 CPU 兜底 | 低到中：閘道主機 + 按需算力 |
| 效果上限 | 受本地模型能力限制 | 敏感場景受本地限制，通用場景不受限 | 取決於背後接的模型 |
| 上線週期 | 2–6 週（含採購） | 1–2 週 | 1–3 週 |
| 適合場景 | 金融、醫療、法務等強合規場景 | 大部分企業內部助手 | 多部門統一入口、要稽核和配額 |
一句話：強合規選 A，多數企業選 B，多部門統一管選 C。最常見的錯誤是「一刀切全本地」——把不敏感的通用問答也壓到本地小模型上，效果差、硬體貴，最後業務不用。
很多人上來就問「跑 70B 要幾張卡」，但真正決定硬體的是峰值併發。同一張卡跑單路對話很流暢，10 個人同時問就開始排隊，因為顯存要同時裝下權重和每個會話的 KV Cache。
先把業務需求翻譯成模型檔位，別直接跳到「越大越好」：
| 檔位 | 典型用途 | 量化後顯存參考 | 硬體參考 |
|---|---|---|---|
| 7B–9B | 分類、抽取、摘要、簡單問答 | 約 5–8 GB | 單張 16GB 消費級顯卡可跑 |
| 14B–32B | 企業助手、客服答疑、文件問答 | 約 10–24 GB | 單張 24GB 顯卡起步 |
| 70B 級 | 複雜推理、長文分析 | 約 40–48 GB | 2 張專業卡或 1 張 80GB 卡 |
注意：上表是單路推理的權重佔用。併發上去後，KV Cache 會額外佔用顯存，長上下文場景尤其明顯。
併發不是「公司有多少人」，而是同一分鐘有多少人在等回覆。經驗做法：
例如 200 人的部門，峰值在線 20 人，同時提問約 3–4 路，按 1.5 倍餘量準備 6 路併發即可，不需要按 200 路買卡。
模型權重、推理服務、向量庫、日誌全部在內網，物理上不存在資料外發路徑。這是金融、醫療、法務等場景的常見選擇。
要點：
代價也很明確：效果上限被本地模型能力鎖住，硬體採購週期長，維運要有人兜底。
把請求按敏感級別分流：涉及客戶資訊、合約、財務資料的走本地模型，通用知識問答、文案潤色走外部 API。這樣既守住了合規紅線，又不用為通用能力買最貴的卡。
風險點：分流規則寫錯一次就是資料外發。上線前必須用脫敏樣本做一輪「敏感資料誤放行」測試。
不管背後是本地模型還是外部 API，所有請求先過一層內網閘道。閘道負責四件事：驗證、配額、稽核、路由。
閘道的價值在規模上來後才明顯：單部門自用時是負擔，三五個部門接入後就是剛需。
現象：單路測試正常，接入 IM 後幾分鐘就崩。
✅ 修法：顯存預算裡給 KV Cache 單獨留出空間，按目標併發數壓測再定卡數；限制單次請求的最大上下文長度，防止個別長對話吃光顯存。
現象：按「70B 需要 2 張卡」採購，結果 20 人同時用就排隊幾十秒。
✅ 修法：先算峰值併發，再算顯存總量 = 權重 + 併發數 × 單路 KV Cache；併發高的場景，多張小卡往往比一張大卡更划算。
現象：換了新版本模型，效果變差，但舊版本已被覆蓋，只能臨時找備份。
✅ 修法：模型檔案按版本號目錄存放，設定裡寫版本號而不是路徑；保留上一版權重，切換即改一行設定；上線前跑固定回歸問題集。
現象：知識庫一變大，推理服務開始變慢甚至被系統殺掉。
✅ 修法：向量庫獨立部署，給推理服務設記憶體上限並預留餘量；知識庫索引更新放在業務低峰期執行。
現象：懷疑有人問了敏感內容，但日誌裡只有請求量，沒有內容歸屬。
✅ 修法：閘道層記錄使用者標識、時間、模型、耗時和脫敏後的請求摘要；日誌單獨儲存並設保留期，別和業務日誌混在一起被輪轉掉。
現象：上線時效果不錯，半年後沒人維護，模型和知識庫都過期了。
✅ 修法：上線時就把「模型季度評估、知識庫月度更新、日誌月度抽檢」寫進維運計畫，指定負責人；沒有運營的私有化部署，半年後基本會被棄用。
| # | 檢查項 | 通過標準 |
|---|---|---|
| 1 | 資料分級 | 敏感級別已定義，且每級都明確了允許的模型路徑 |
| 2 | 併發壓測 | 按峰值併發 × 1.5 壓測通過，無 OOM、無逾時堆積 |
| 3 | 上下文上限 | 單請求最大長度已限制，長對話有截斷策略 |
| 4 | 模型版本管理 | 版本號可追溯，回滾只需改設定 |
| 5 | 權限與配額 | 按人/部門發金鑰，有配額上限，離職可即時回收 |
| 6 | 稽核日誌 | 可查到「誰、何時、用了哪個模型、問了什麼（脫敏）」 |
| 7 | 敏感資料誤放行測試 | 用脫敏樣本跑一輪，無敏感內容走到外部通道 |
| 8 | 維運計畫 | 模型評估、知識庫更新、日誌抽檢的頻次和負責人已確定 |
私有化部署的難點不在「把模型跑起來」，而在把併發、合規、維運三件事同時算清楚。硬體買多了浪費預算，買少了業務不用；資料邊界劃錯了是合規事故；沒有運營計畫，半年後就是一堆閒置機器。
如果你正在評估私有化方案，建議先做兩件事：把資料分級表寫出來，把峰值併發估出來。這兩張表一出來，架構選型和硬體預算基本就定了。