2026-06-12

私有化部署大模型：開源閉源怎麼選，顯示記憶體併發合規怎麼算

私有化大模型選型為何讓團隊反覆卡殼？本文從工程角度拆解三個核心口徑：顯示記憶體不只看參數，KV Cache 才決定真實併發上限；併發需從延遲目標和 QPS 反推硬體數量；合規要把「滿足等保」轉化為可核對的硬約束。基於三口徑框架，理性比較開源與閉源方案，並附雲上自採利用率拐點測算與規模硬體對照表。

選型為什麼卡半個月：把「開源閉源」翻譯成三個工程口徑

私有化部署的決策卡點，很少出在「模型選項太少」。恰恰相反，能跑的開源權重越來越多，閉源廠商的私有化授權也都給得出方案，可擺在桌上的備選越多，拍板反而越難。我見過一家制造企業的技術負責人，前後評估了十幾個方案，耗了大半個月還在原地打轉——不是哪個模型明顯不行，而是沒有一把尺子能把這些方案量到同一個刻度上比。決策卡住的真因是維度沒量化，不是資訊不夠。

大多數選型文件會給出一套四維框架：資料安全等級、併發與效能要求、預算成本、團隊能力。這四個維度本身沒錯，缺一不可，問題是它們太粗，落不到一張採購單上。「資料不能出域」是一句立場，不是一個約束——它沒告訴你要買幾張卡、模型能不能量化、日誌要不要留審計。「效能要夠用」同樣是空的，夠用是多少 QPS、首 token 要壓到幾百毫秒、p99 能容忍多大抖動，全藏在「夠用」這兩個字底下。維度停在形容詞層面，評審會就只能反覆爭論傾向，爭不出可執行的結論。

把這套粗框架往下翻譯，其實能收斂成三個能算的工程口徑。第一個是顯示記憶體：模型參數決定了你的地板，但真正吃顯示記憶體的往往是推理時的 KV Cache，它隨併發數和上下文長度線性長，參數量只是帳單的一小半。第二個是併發：先定延遲目標和峰值 QPS，再反推單卡能扛多少路、總共要幾張卡，而不是先買硬體再看能跑多快。第三個是合規：把「滿足等保」這種說法拆成資料是否出域、模型權重能否落在自己機房、呼叫鏈路要留多久審計這類能逐條打勾的硬約束。這三個口徑的共同點是都能落到數字、落到採購單，評審時不再是比誰的立場更穩，而是比誰的數算得更實。

這麼拆之後，「開源還是閉源」這個老問題的位置也變了。它不該是選型的前提，而是三口徑算完之後自然掉出來的結果。舉個例子：合規口徑要求權重必須留在本地、連模型檔案都不能託管在廠商側，那閉源 API 這條路基本就被劃掉了，剩下的才是在開源權重裡挑哪個量級；反過來，如果資料出域在你的行業裡是被允許的，預算又緊、團隊也撐不起 GPU 維運，那閉源的私有化或專屬實例可能反而更省心。先站隊再找理由，容易把工程問題打成偏好之爭；先算口徑再看結果，開源閉源就退回成它本來的樣子——一個交付形態的選擇，而不是信仰。

所以這篇文章不打算給你一張「開源 vs 閉源」的對照表讓你站隊，而是先把顯示記憶體、併發、合規這三把尺子交到你手裡。後面幾節會逐個展開：顯示記憶體怎麼從參數和 KV Cache 算到真實佔用，併發怎麼從延遲目標反推卡數，合規怎麼拆成能核對的清單，再把三者合到成本和回本上，最後落成一張能直接報採購的規模—硬體對照表。等這三個口徑都算清楚了，開源還是閉源這個問題，多半你自己已經有答案了，根本不用糾結大半個月。

顯示記憶體口徑：參數只是地板，KV Cache 才是併發的真實帳單

很多團隊第一次做私有化選型，拿到模型參數量就去對顯示卡規格，結果上線後併發一放量就 OOM。根本原因是把「能裝下模型」和「能跑併發」混為一談。顯示記憶體需求分兩層，參數載入是地板，KV Cache 才是真正隨業務彈性增長的那一塊。

第一層：權重載入的靜態下限

FP16 精度下，每個參數佔 2 位元組，加上執行時框架開銷，經驗估算如下：

這組數字的意義是：單請求、空載狀態下的最低門檻。一張 80 GB 的 A100 裝 7B 綽綽有餘，裝 14B 也夠，但這只是起點，不是終點。

第二層：併發放大的 KV Cache 帳單

推理階段每個活躍請求都需要獨立維護一塊 KV Cache（Key-Value 快取，用於儲存注意力機制的中間狀態）。實際顯示記憶體佔用的完整公式是：

總顯示記憶體 = 權重顯示記憶體 + 併發請求數 × 單請求 KV Cache 大小

單請求的 KV Cache 體積取決於模型層數、注意力頭數和序列長度。以一箇中等規模模型為例，單請求 KV Cache 會隨序列長度佔用相當一部分顯示記憶體。這意味著權重載入之後，剩餘顯示記憶體能支撐的併發路數有限——而且這是上限，實際排程還要為系統預留餘量。

反過來看那個常見的踩坑場景：如果採購依據是「7B 只需要 20 GB」，買了一張 24 GB 消費級卡，權重上去之後只剩 4 GB 給 KV Cache，兩三個併發請求就把顯示記憶體打滿，直接觸發 OOM。參數規格沒說錯，但忽略了併發這一層，採購就錯了。

量化：顯示記憶體換精度的槓桿

當目標硬體的顯示記憶體無法容納 FP16 權重時，量化是最常用的工程手段。INT8 量化將權重從 16 位壓縮到 8 位，顯示記憶體佔用降低約 75%，而多數測評顯示精度損失在 2% 以內——對大多數企業內部問答、文件處理場景來說是可接受的代價。

實際效果：大模型經過 INT8 量化後顯示記憶體佔用明顯下降，從「必須多機」變成「單機可跑」。這不是精度無損的免費午餐，而是一個明確的工程權衡：用可量化的精度損失換取硬體成本的大幅壓縮。

INT4 量化可以把顯示記憶體壓得更低，但精度下降通常較為明顯，是否可用取決於具體任務對準確率的敏感度，需要在自有資料集上實測，不能只看通用 benchmark。

容量基準：7B 在 A100 80G 上的實測參考

7B 參數模型在單張 A100 80GB 上完整載入 FP16 權重，推理延遲可以穩定在 200ms 以下——這是一個值得記住的容量基準點。它的意義在於：你可以以此為錨，向上推算 14B 和 70B 需要多少卡，向下推算在更小的卡（如 A10 24G）上跑 7B 量化版本的延遲代價。

選型前先算這張賬

在進入「買幾張卡」的決策之前，建議先把以下三個數字確定下來：

• 峰值併發數：業務側能給出的最高同時線上請求數，這決定 KV Cache 預算
• 平均序列長度：輸入+輸出的 token 總長，直接影響單請求 KV Cache 體積
• 精度容忍度：業務場景能接受 INT8 還是必須 FP16，決定是否可以量化壓縮

三個數字確定之後，套上述公式就能算出最低顯示記憶體需求，再加 20%–30% 的安全餘量，才是真正的採購下限。跳過這一步直接對參數量買卡，是選型卡半個月甚至返工的主要原因之一。

併發口徑：從延遲目標和 QPS 反推該買幾張卡

很多團隊卡在選型上，根源不是不懂硬體，而是跳過了一個前置動作：先把延遲 SLA 寫成數字。「響應要快」這種描述對採購單沒有任何約束力；「首 Token 延遲不超過 1 秒」才是可以反推卡數的工程入口。

第一步：區分場景，SLA 差距決定配置差距

兩類場景的資源需求量級完全不同，混在一起估算會導致要麼嚴重超配要麼上線即崩：

• 即時對話（C 端或內嵌業務流程）：首 Token 延遲必須控制在 1 秒以內，否則使用者感知明顯示卡頓。這個約束直接限制了批大小（batch size）——批越大吞吐越高，但排隊等待時間同步拉長，兩者之間存在硬性張力，不能只盯吞吐數字。
• 內部工具 / 低併發後臺任務：幾十人同時線上的知識庫問答、程式碼審查、報告生成，延遲 3–5 秒完全可接受。這類場景的瓶頸是顯示記憶體容量而非延遲，可以用更大批次換更高吞吐，同等硬體下實際服務人數是即時對話場景的數倍。

這兩種場景混用同一套配置標準，要麼給低併發內部工具買了過貴的低延遲硬體，要麼把即時對話壓在一臺吞吐機上讓使用者一直等第一個字。

第二步：推理框架決定你能榨出多少吞吐

硬體是上限，推理框架決定你能用到上限的幾成。三個主流框架定位清晰，混用或選錯會讓同等硬體效果差一倍以上：

• Ollama：一條命令拉起，適合本地開發和概念驗證。沒有生產級併發管理，不要在真實負載下用它做效能基準。
• vLLM：目前社群最活躍的生產推理框架，核心是 PagedAttention 機制——把 KV Cache 按需分頁而非預分配連續塊，顯示記憶體碎片大幅減少，同顯示記憶體下可支撐的併發請求數顯著提升。生產高併發首選。
• TensorRT-LLM：NVIDIA 官方出品，針對自家 GPU 做了深度核心最佳化，延遲和吞吐的天花板高於 vLLM，但部署複雜度和維護成本更高。對延遲 SLA 極苛刻（比如即時語音、金融交易輔助）且維運團隊有 CUDA 經驗的場景值得投入。

第三步：用 QPS × 單請求 KV 估顯示記憶體，再用延遲校驗批大小

反推卡數的計算路徑分兩條線，取較大值：

顯示記憶體約束線：目標併發 QPS 乘以單請求 KV Cache 佔用（由上下文長度和模型層數決定，詳見本系列第 2 節），加上模型權重本身的顯示記憶體底座，得出峰值顯示記憶體需求。這條線給出「最少需要多少顯示記憶體」。

延遲約束線：首 Token 延遲 SLA 反過來限制了 prefill 階段允許的最大批大小。批越大、prefill 耗時越長、首 Token 越晚到。如果你的 SLA 是 1 秒，那就需要在目標 QPS 下測出滿足延遲的最大批大小，再確認該批大小下單卡/多卡的算力是否夠用。

兩條線都通過，卡數才算夠。只看顯示記憶體不看延遲，上線後首 Token 超時；只看延遲基準測試不看峰值顯示記憶體，高峰 OOM 直接崩服務。

規模與卡數的工程參照

以上數字來自行業部署實踐的普遍參照區間，具體值仍需以實際上下文長度、併發峰值和批大小測試結果為準。70B 跨到 8 張卡的場景，張間通訊頻寬（NVLink vs PCIe）會成為新的瓶頸，評估時需要同步確認互聯拓撲，不只是湊夠顯示記憶體總量。

結論是：併發口徑的選型不是查表，而是從你的 SLA 數字出發，經過框架選擇、KV 估算、延遲校驗三道過濾，最後得出一個可以寫進採購單的最小卡數。跳過任何一道，數字就會失真。

合規口徑：把「滿足等保」拆成可核對的硬約束

前面兩節算的是顯示記憶體和併發，那是「能不能跑得起來、跑得夠不夠快」的問題。但在金融、醫療、政務這類強監管行業，還有一道在算賬之前就生效的門：方案合規不達標，效能再漂亮也直接出局。這道門的麻煩之處在於，業務方常把它說成一句模糊的「要滿足等保」，而工程上根本沒法對一句口號做驗收。要讓它進得了評審、過得了審計，得先把這句話翻譯成幾條能逐項打勾的硬約束。

先說為什麼要單獨拎出來談。顯示記憶體和併發是連續量，差一點可以靠加卡、降併發、壓上下文來補救；合規不是連續量，它是布林值。一個方案要麼滿足「資料不出內網」，要麼不滿足，中間沒有「基本滿足」這種狀態。這意味著合規約束應該放在選型流程的最前面當過濾器用，而不是等架構定型、採購單都畫好了，再被安全或法務一票否決——那時候返工的成本是按周算的，前面那半個月的選型糾結，相當一部分就卡在這裡。

三條能逐項核對的項

把「滿足等保」攤開，對部署架構起決定作用的主要是三條，每一條都能落到具體的核對動作上：

• 資料本地化：訓練語料、推理時的輸入輸出、向量庫、日誌，這些資料物理上存放在哪。可核對的問法是「列出所有持有業務資料的儲存節點，它們的物理位置和歸屬主體分別是什麼」。只要有一份資料落在你不掌控的機房或第三方帳戶裡，這條就不過。
• 不出內網：推理鏈路上有沒有任何一跳穿過公網。這條最容易被忽視的不是主模型呼叫，而是那些「順手」接進來的外部能力——聯網檢索、第三方向量化服務、呼叫外部 API 做工具增強。可核對的問法是「畫出完整呼叫鏈，標出每一跳的網路邊界」，任何一條出網的箭頭都要能解釋清楚或被掐斷。
• 等保認證：系統按等級保護要求完成定級、備案、測評，並拿到對應等級的結論。金融、政務核心系統通常要求三級。這條核對的是流程證據，不是技術參數，但它會反過來約束你能用什麼樣的底層設施。

金融、醫療、政務在私有化選型時須滿足等保認證、資料本地化且不出內網，這一點在 2024 年的行業實踐裡已經是預設前提，不再是加分項。把它當硬約束寫進需求基線，後面的架構討論才有共同的邊界。

合規如何反向鎖死架構

真正影響選型的，是這三條約束的連鎖反應。這裡換個角度看會更清楚：不要問「我想用什麼部署形態」，而是問「在資料不出內網的前提下，哪些形態還活著」。

從這個角度倒推，公有云的按需推理服務第一個出局——它的本質就是把請求送到供應商的機房處理，「不出內網」和「按需呼叫公有云」在定義上互斥。閉源 SaaS 形態的大模型同理，無論它叫什麼名字，只要推理發生在你內網之外，就過不了第一道核對。這一步篩完，桌面上能留下的基本只剩兩類：把閉源模型以私有化授權方式裝進自己機房，或者乾脆用開源模型自行部署。

到這裡，「開源還是閉源」這個被反覆爭論的問題，已經被合規約束削掉了一半的選項空間。剩下的不是站隊之爭，而是在「私有化的閉源授權」和「自部署的開源」之間，按前幾節的顯示記憶體、併發口徑繼續算賬。合規沒有替你做完選擇，但它替你劃掉了一大片本來要糾結的方案，這是它最實際的價值。

還有兩個容易在落地時翻車的細節值得提前盯住。一是混合架構的誘惑：用本地小模型處理日常請求、把難題「兜底」轉給公有云大模型，這種設計效能和成本都好看，但只要那條兜底鏈路攜帶了真實業務資料出網，整套方案的合規性就被它一票拉低。二是更新通道：私有化部署的模型權重、依賴映象怎麼更新？如果靠從公網直接拉取，那是另一條隱性的出網路徑，審計時同樣要解釋。把這兩點想清楚，後面的硬體採購單才不會因為一次安全複核推倒重來。

一句話收口：合規口徑不參與「效能好不好」的討論，它只回答「這個方案有沒有資格上桌」。先用資料本地化、不出內網、等保認證這三條把候選方案過一遍，再去和顯示記憶體、併發算細賬——順序反了，前面算得越細，後面返工越疼。

開源 vs 閉源：用三口徑給可算判斷，而不是站隊

選型討論裡最容易跑偏的環節，就是把開源/閉源當成立場題來辯。工程上這個問題沒有陣營，只有在你的顯示記憶體預算、併發目標和合規邊界下，哪條路的 TCO 更低、風險更可控。

先把兩條路的成本結構擺清楚

開源模型（Llama 3、DeepSeek、Qwen、GLM 等）的許可證本身不收費，這是事實。但「免費」只是權利金為零，不是部署成本為零。真實帳單分三塊：

• 硬體資本支出：模型參數決定顯示記憶體地板，KV Cache 和併發目標決定實際採購量——這筆錢完全在你這邊，沒有人分擔。
• 維運人力：推理框架選型（vLLM / TGI / SGLang）、量化精度取捨、顯示記憶體碎片治理、版本升級迴歸——每一項都需要有人長期盯。按行業普遍觀察，一個從零搭建到穩定執行的私有化部署專案，算上調優和值班，通常需要若干名有 GPU 叢集經驗的工程師持續投入，初期尤其密集。
• 機會成本：團隊精力有上限。花在基礎設施上的人日，就是沒有花在業務功能上的人日。

閉源/商業方案的帳單結構剛好相反：資本支出低（或轉為訂閱），維運複雜度轉移給供應商，但客製化空間受合同和介面約束，且每月帳單是持續剛性支出，業務量越大費用越高，沒有「買斷」的概念。

三口徑下的切換線

與其給結論，不如給判斷邏輯。把前幾節的三個口徑直接套進來：

切換線不是非此即彼的，是加權的。三個口徑都指向同一側，判斷就很確定；兩個指向開源、一個指向閉源，那個「指向閉源」的口徑往往是瓶頸，要單獨解決（比如招一個維運工程師，或者把波動併發用彈性雲 GPU 承接）。

「開源免費」最常見的誤算方式

一個典型的錯誤決策路徑是：看到 Qwen 或 DeepSeek 可以免費下載，就在立項時把模型許可證費用填 0，然後在硬體採購和人力預算上低估，導致專案上線後成本遠超預期。

更準確的 TCO 演算法應該是：

• 顯示記憶體採購 = 按第二節的口徑算出卡數 × 單卡成本 + 備機冗餘
• 維運人力 = 工程師年薪 × 折算到該專案的時間佔比，至少按 1 人/年起算
• 機會成本 = 同等人力投入到產品功能的預期產出（這一項很難量化，但不能忽略）
• 對比基準 = 同等呼叫量下閉源 API 或託管方案的年費

當自採路線的顯示記憶體利用率長期低於 50%，TCO 拐點通常會倒向託管方案。這個拐點不是固定數字，取決於你的併發分佈和硬體折舊週期，但可以用第六節的利用率模型算出來。

開源的真實優勢在哪裡

去掉「免費」的光環之後，開源的核心價值有兩個：

第一是資料主權。權重在本地，推理在內網，日誌不出機房——這對金融、醫療、政務場景不是加分項，是准入門檻。閉源 API 在這個約束下根本無法參賽，不存在「哪個更好」的比較。

第二是深度客製空間。微調訓練資料、修改推理邏輯、串接私有知識庫的方式、調整輸出格式——開源模型在這些維度上的自由度，是任何商業 API 的提示詞工程都替代不了的。如果你的業務場景需要模型行為高度可控，這個自由度的價值會隨時間遞增。

閉源的真實優勢同樣明確：把基礎設施風險外包。推理框架升級、模型版本迭代、硬體故障恢復——這些事不是不重要，而是你不需要自己做。對於 AI 不是核心競爭力、只是工具的業務團隊，這種外包邏輯完全成立。

可操作的判斷流程

在進入具體選型之前，建議按以下順序回答三個問題：

• 資料和模型能否出內網？——能出，閉源 API 保持候選；不能出，直接鎖定私有化，再討論開源還是商業私有化版本。
• 團隊現在有沒有人能負責推理框架維運？——有，開源路線可行；沒有且短期內無法招募，優先考慮有託管支援的商業方案。
• 併發利用率能否支撐自採回本？——按第六節的拐點模型算，能過線則自採，過不了線則雲上按需付費。

這三個問題都有明確答案之後，開源還是閉源的選擇基本上已經被約束條件決定了，不需要再做「技術哲學」層面的判斷。

成本與回本：雲上還是自採，算利用率拐點

到這一步，前面三個口徑已經把「需要多少算力」框定了。剩下的問題只有一個：這些卡是租還是買。很多團隊在這裡憑直覺站隊——覺得「自己買才安心」或者「上雲才靈活」——但這是一道純粹的算術題，變數就是利用率。把利用率算清楚，結論會自己浮出來。

先看最常見的 7B 單卡場景，因為它是大多數私有化專案的起點。按目前市場行情粗估，租用雲上 GPU 實例跑一整年，費用大致在三到五萬元這個量級；如果選擇一次性把卡和機器買回來，前期投入大約是十到十五萬元。注意這兩個數字不在同一維度：前者是每年都要續的營運支出，後者是砸下去一次、之後逐年攤薄的資產。頻寬、儲存、機房這些配套成本兩邊都得另算，且自採這邊往往被低估——一臺伺服器進了機房，電費、維運人力、備件的隱性帳單會一直掛著。

真正決定結論的是回本週期，而回本週期由利用率倒推。換個更直觀的演算法：一臺配 A100 的本地伺服器，把三年的維護成本一起算進去，總投入差不多落在八萬美元的量級。同樣的算力如果走公有云按需計費，每小時成本大約五美元。把八萬美元除以每小時五美元，得到一萬六千小時左右的等效使用量。這就是臨界點——只要你的真實負載在兩年內能消耗掉這麼多機時，自採就開始比租用划算；跑得越久、越滿，省下的越多。

關鍵在「真實負載」這四個字。一萬六千小時聽起來很多，但如果一張卡是 7×24 常駐線上服務，一年就有八千多小時，兩年正好覆蓋。換句話說，對於一個穩定吃滿的推理服務，自採兩年回本之後，第三年往後幾乎是淨賺。但現實裡很少有負載能持續打滿。如果你的卡平均利用率只有三成，那一萬六千小時要拖到五六年才跑得完——而 GPU 三五年就該考慮換代了，回本視窗可能根本等不到。

所以拐點判斷可以歸納成兩類負載形態：

• 高利用率、長期常駐：典型如面向全員的內部問答、固定批處理管線、生產環境裡持續吞吐的線上服務。這類負載吃滿卡、跑得久，自採的一次性投入會被時間稀釋，長期算下來明顯更省，而且資料完全不出域，合規口徑也順帶滿足。
• 低頻、波動、突發：比如季度性的報告生成、不定期的實驗性專案、白天忙夜裡閒的人機互動場景。為峰值買一堆常年閒置的卡是最貴的浪費，按需租用才能讓成本貼著實際用量走，需求降了隨手就能縮容。

實際專案裡，這兩類往往同時存在。一個務實的做法是混合切分：把那部分穩定、可預測、必須本地化的核心負載用自採機器扛住，把彈性的、嚐鮮的、峰值的部分甩給雲上按需。這樣既守住了基線成本，又不為波動買單。

還有兩筆賬容易在拍板時被漏掉。其一是機會成本：自採的錢壓在硬體上，這部分資金本可以投到別處，而 GPU 一旦買定，型號就鎖死了，下一代價效比翻倍時你只能幹看著。其二是利用率的「虛高」陷阱——很多團隊把「卡開著」當成「卡在用」，但空轉的顯示記憶體不產生任何價值，回本算式裡要填的是有效推理時長，不是開機時長。建議上線後先用雲上按需跑一兩個月，把真實的日均請求量、峰谷比、平均利用率壓出來，再拿這些實測數字去套上面的臨界點公式。

一句話收口：雲還是自採，不是偏好問題，是利用率問題。先量出你的負載到底有多滿、跑多久，讓數字替你做決定，而不是反過來用採購決定去遷就一個拍腦袋的預期。

規模—硬體對照表：把口徑落到具體採購單

前幾節講的顯示記憶體、併發、合規三個口徑，最終都要落到一張採購單上。下面按參數規模分三檔，給出硬體配置的工程判斷，以及每檔適合的業務場景。

三檔規模對照

7B：驗證期的合理起點

7B 模型的權重本體約佔 14 GB 顯示記憶體（FP16），單張 24 GB 卡在載入完權重後還剩約 10 GB 給 KV Cache，支撐十幾路併發基本夠用。RTX 4090 適合預算敏感的內部測試環境，A10 的 ECC 顯示記憶體和資料中心散熱規格更適合常駐服務。如果團隊已有 A100 40G，直接複用即可，不必額外採購。

這一檔的核心價值是驗證：業務流程跑得通嗎？提示詞工程有沒有卡點？資料管道是否完整？用低成本硬體把這些問題跑清楚，比直接上大叢集再推倒重來要划算得多。

14B–40B：精度需求驅動多卡並行

當業務場景對準確率有明確要求——比如法律條款比對、科研文獻綜述、醫療影像報告生成——7B 的推理深度往往不夠。40B 量級的模型在這類任務上有結構性優勢，但代價是顯示記憶體需求超出單卡上限，必須做張量並行或流水線並行。

以放射科報告生成為例：在專科標註資料上對大模型做監督微調，術語準確率相比基線可以有明顯提升。這個提升幅度在很多臨床場景下是能否上線的分水嶺。同樣的微調策略用在 7B 上，受限於模型容量，提升空間要窄得多。

硬體側，更大規模的模型需要相應增加顯示卡數量做多卡並行。如果預算允許，H20 的顯示記憶體頻寬更高，在長序列推理下吞吐量更好。

70B–72B：中文長文本的上限配置

70B 模型的權重本體接近 140 GB，FP16 載入必須跨卡。多卡叢集是目前最常見的生產配置——除去權重和執行時開銷，KV Cache 仍有相當餘量，在長上下文下能支撐一定規模的併發，延遲維持在秒級。

中文最佳化的 72B 模型（如 Qwen-72B）在長文件理解、多輪對話連貫性上表現明顯好於同規模的非中文最佳化版本，這對國內企業部署的實際體感影響較大。如果業務裡有大量中文長文本處理，這一檔是值得認真評估的選項。

值得注意的是：8 卡叢集的採購和維運成本相當可觀，上這個配置前應當先用前幾節的併發口徑算清楚實際 QPS 需求。如果峰值併發不高，70B 更多是精度需求而非吞吐需求驅動的決策。

降本路徑：蒸餾而非降檔

很多團隊在 70B 跑通業務後，面臨的真實問題是：推理成本太高，但直接換成 7B 精度又掉得難以接受。知識蒸餾是這個矛盾的工程出口——用已經在業務資料上微調好的 70B 模型作為教師，指導 7B 模型的訓練過程。行業實踐中這條路徑在保留約 90% 效能的同時，可以將推理算力壓縮到原來的十分之一左右。

蒸餾不是銀彈：它需要高品質的教師模型輸出作為訓練訊號，對標註資料和訓練流程有額外要求。但對於已經在大模型上跑通業務邏輯、進入降本階段的團隊，這是比重新選型更穩妥的路徑。

選型決策順序

• 先定精度下限：業務對準確率的最低要求決定參數規模的下限，這一步不能靠拍腦袋，要用真實業務資料跑基準測試。
• 再算併發預算：用第二節的顯示記憶體公式，從目標 QPS 和上下文長度反推所需顯示卡數量。
• 核對合規約束：資料本地化、等保要求、審計日誌等硬約束影響部署架構，在採購前必須明確。
• 評估蒸餾可行性：如果精度需求指向大模型但成本壓力明顯，把蒸餾路徑的工程成本也算進來，再做最終決策。

硬體配置沒有通用答案，但三個口徑給了一套可以反覆代入具體數字的框架。把業務參數填進去，採購單自然就出來了。

FAQ：私有化選型裡最常被問到的四個問題

按「7B=20GB」買了卡，為什麼一上線就顯示記憶體爆了？

因為那個估算只算了權重這一塊地板，沒算上推理時真正吃顯示記憶體的幾個大頭。一張卡能不能扛住，得把四筆賬加在一起：模型權重、KV Cache、執行時框架本身的佔用、以及碎片化導致的浪費。

權重是固定的，FP16 精度下 7B 參數確實在 14GB 上下，加上一些常駐開銷湊到 20GB 沒錯。問題出在後面三筆。KV Cache 隨著併發請求數和上下文長度線性增長——同時掛著十幾個長上下文會話，這部分能輕鬆吃掉十幾 GB。推理框架自身要預留顯示記憶體池、快取編譯產物，也要佔幾個 GB。再加上動態分配帶來的碎片，標稱剩餘和實際可用之間往往差出一截。

所以更穩妥的做法是反過來推：先定下要支撐的併發數和最大上下文長度，按這個算出 KV Cache 的峰值需求，再疊加權重和框架開銷，最後留 15% 到 20% 的餘量。把上線場景的峰值算清楚，比套用「參數量乘以二」的口訣靠譜得多。如果你發現顯示記憶體剛好卡在臨界點，那基本等於沒留餘量，第一個流量高峰就會被打穿。

強監管行業是不是只能選開源私有化、不能用商業平台？

不是。這是把「合規」和「開源」兩個概念綁在了一起，但它們解決的根本不是同一件事。合規真正要求的是資料不出域、有審計鏈路、能定責追溯、模型行為可控這幾條硬約束。能不能滿足這些，取決於部署形態和合同條款，而不取決於模型權重是否公開。

很多商業大模型同樣提供私有化或專屬部署的交付方式，把推理服務整體放進你自己的機房或專屬網路區域裡，資料全程不離開邊界。這種形態下，它滿足資料不出域的能力和開源模型部署沒有本質區別。真正要核對的是幾個具體問題：服務是否完全在你的網路內執行、有沒有任何回傳遙測、日誌和審計能否串接你現有的安全體系、出了問題廠商能否配合定責。

反過來說，開源模型也不會自動合規。你自己部署一套開源模型，審計、訪問控制、資料脫敏這些工程仍然要自己搭。所以正確的問法不是「開源還是商業」，而是「這套交付方案能不能逐條滿足我的硬約束」。把合規清單列出來去對照，比按模型出身站隊要清醒。

首 Token 延遲小於 1 秒是硬指標嗎，內部用也要滿足嗎？

不是普適硬指標，它完全跟著使用場景走。對外的即時對話、客服問答這類場景，使用者盯著螢幕等響應，首 Token 慢一點體驗就垮，這時候延遲才算硬約束。但內部場景裡有大量任務根本不在乎這個。

典型的反例是批次處理：夜間跑文件摘要、批次生成報告、離線資料標註，這些任務關心的是單位時間能處理多少條，也就是吞吐量，而不是單條請求多快返回。對這類負載，你完全可以把批處理的 batch 開大、把延遲換成吞吐，同樣的卡能多幹好幾倍的活。如果硬套「首 Token 小於 1 秒」去配置，反而是在浪費算力。

所以定指標之前先分清楚負載型別：互動式的看首 Token 延遲和每秒出字速度，批處理的看整體吞吐和單位成本。混合負載最好在排程層面就把兩類請求分開，給互動請求留低延遲通道，把批處理塞進空閒時段。用一套延遲標準卡所有場景，要麼體驗不夠，要麼錢花冤了。

雲上和自採怎麼選，有沒有簡單演算法？

有一個夠用的近似判斷：算利用率。核心是把自採硬體的總持有成本攤到它的生命週期裡，折算成每小時的等效成本，再和雲上按量計費的單價比。

具體做法是先估你的真實負載曲線——平均每天有多少小時卡是真正在跑的。如果你的業務是全天候高負載、利用率長期壓在高位，自採的單位成本通常會明顯低於雲上租用，前期投入能在一到兩年內攤平。如果負載是明顯的波峰波谷、白天忙夜裡閒，或者總量還不大、需求還在變，那雲上的彈性更划算，你不用為閒置的卡持續付錢。

除了這條利用率拐點，還有幾個不進公式但要拍板的因素：自採意味著你得自己扛硬體維運、故障替換、機房和電力；雲上省心但長期看總賬可能更高，還要確認資料合規上能不能接受。一個穩妥的折中是混合——基礎穩定負載用自採兜底，峰值溢位用雲上彈性頂上。先別急著下單，把未來一年的負載曲線畫出來，拐點自然就顯現了。