2026-08-31

本地部署大模型顯示記憶體怎麼選：企業配置對比

詳解本地部署大模型顯示記憶體的計算方法，結合模型規模、量化方式、上下文長度與併發需求，對比單卡、多卡、Mac及CPU方案，幫助企業科學選型與採購。

一、企業選顯示記憶體，不能只看模型參數量

企業評估本地大模型時，最常見的誤區是把「參數規模」直接換算成「需要多大顯示記憶體」。參數量只能說明權重資料的基礎體量，不能代表服務執行後的完整佔用。真正可執行的估算，需要同時考慮四個變數：模型規模、權重精度、請求併發和上下文長度。缺少其中任何一項，採購結論都可能停留在「模型勉強啟動」，而不是「業務穩定執行」。

這四項並非彼此獨立。低位元量化可以壓縮權重，卻不會按相同比例消除執行時開銷；模型縮小後，如果併發數和上下文上限同步提高，節省出的顯示記憶體可能很快被快取消耗。反過來，同一模型在單人互動測試中執行正常，也不意味著它能承受多個長文本請求同時生成。因此，企業應先定義服務負載，再反推硬體，而不是先購買顯示卡，再尋找能夠塞進去的模型。

採購溝通中還要明確三個不同口徑，避免技術驗證與上線目標混為一談：

• 能載入：權重可以放入顯示記憶體，推理程序能夠啟動並完成少量請求。這只驗證了最低執行條件，通常不能說明延遲、吞吐和穩定性達標。
• 穩定可用：除權重外，還能容納注意力快取、推理框架工作區、臨時張量及必要的系統佔用，並在目標上下文範圍內連續執行，不因短時峰值頻繁溢位。
• 生產部署：在穩定執行的基礎上，應覆蓋業務併發高點，併為模型版本變更、推理引擎升級、提示詞增長以及監控元件保留空間。生產配置不宜把顯示記憶體長期壓到極限。

從工程順序看，顯示記憶體通常是本地推理首先需要跨過的門檻，但它不是唯一決定效能的部件。CPU會影響分詞、請求排程和部分運算元處理；系統記憶體不足時，模型載入、權重對映乃至程序穩定性都會受影響；儲存效能決定冷啟動和模型切換速度；多卡環境下，卡間通訊能力與拓撲結構會直接影響分片推理效率。顯示記憶體總量相同的兩套機器，如果一套依賴低速互聯，另一套能夠高效傳輸張量，其實際吞吐可能明顯不同。

因此，本節可先形成一個簡單判斷：模型規模與量化精度用於估算「靜態底座」，併發和上下文用於估算「動態增量」，再疊加框架開銷與工程餘量，才是企業應採用的顯示記憶體口徑。後續配置對比也應圍繞這一口徑展開，而不是用某張顯示卡能否啟動某個模型作為最終採購依據。

二、顯示記憶體怎麼算：模型權重只是第一筆賬

本地部署大模型時，最容易出現的誤判是把模型檔案大小當成顯示卡需求。模型檔案只反映靜態權重，實際推理還要為輸入輸出過程中的中間張量、上下文快取以及執行時管理結構留出空間。因此，「檔案能裝下」只能說明模型可能載入成功，不能說明它能穩定服務請求。

第一步可以先按下面的方式估算權重顯示記憶體：

權重顯示記憶體 ≈ 參數量 × 單參數佔用位元組數

例如，一個參數規模為 7B 的模型，FP16 權重的理論值約為 14GB，INT8 約為 7GB，INT4 約為 3.5GB。這裡的「約」很重要：量化格式通常還包含縮放因子、分組資訊和對齊開銷，實際檔案大小不會嚴格等於參數量乘以理想位元組數。模型載入時也可能發生格式轉換或額外複製，所以不能拿這個結果直接對照顯示卡標稱顯示記憶體。

三類顯示記憶體要分開記錄

更實用的做法，是在部署表裡拆出三個指標，而不是只登記一個模型大小。

• 靜態權重顯示記憶體：模型載入後長期佔用的基礎部分，通常由參數規模、量化方式和載入格式決定。
• 單請求峰值顯示記憶體：一條請求在預填充和生成過程中額外消耗的顯示記憶體，受輸入長度、輸出長度和模型結構影響。
• 目標併發峰值顯示記憶體：達到業務併發目標時的總峰值，重點受 KV Cache、請求長度分佈和排程策略影響。

在權重之外，啟用值是計算過程中的臨時空間，通常在預填充階段更明顯；KV Cache 則會隨著上下文長度和同時處理的請求數增加。對於長文件問答、程式碼補全、批次摘要等業務，KV Cache 往往比單個請求的短時啟用更容易成為瓶頸。推理框架本身還會佔用一部分顯示記憶體，包括運算元工作區、通訊緩衝區、記憶體管理結構和必要的臨時張量。

如果當前只有模型參數量和量化格式，可以先在權重結果之上增加約 30% 的空間，作為低併發、常規上下文下的篩選線。例如，權重估算為 14GB，初步預算可按約 18GB 觀察，而不是把 14GB 顯示卡當作合適配置。這只是早期排查工具，不是生產容量承諾。長上下文、多使用者並行或輸出長度波動較大的場景，額外空間可能明顯超過這個比例。

正式規劃時，建議建立一張簡單的容量記錄表：模型版本、量化格式、權重佔用、輸入長度、最大輸出長度、單請求峰值、目標併發和總峰值。壓測至少覆蓋短請求、典型請求和接近上限的請求，並記錄顯示記憶體峰值而非平均值。只有把業務請求分佈帶入測試，才能判斷是顯示記憶體不足，還是吞吐、排隊延遲先達到瓶頸。

採用帶 PagedAttention 的推理框架，可以把 KV Cache 按頁面管理，減少碎片並改善併發請求之間的顯示記憶體利用。它解決的是快取分配和複用效率問題，不會降低模型權重本身的常駐佔用；如果權重已經超過單卡容量，換框架不能替代量化、分卡或更換硬體。最終容量應以目標模型、上下文上限和併發壓測結果為準。

三、模型規模×量化方式：企業顯示記憶體配置對照表

模型參數量只能決定權重的大致體積，不能直接等同於機器需要的顯示記憶體。下面的數字按「權重載入到顯示卡、採用常見推理框架、保留基本執行空間」的工程口徑估算；它們適合做採購初篩，不應替代真實壓測。實際佔用還會受到量化格式、推理框架、上下文長度和併發請求數影響。

7B 是最容易落地的一檔。INT4 權重本身約佔 4—5GB，但 8GB 顯示記憶體並不意味著所有場景都能穩定執行：如果上下文較長，或者同時處理多個請求，快取和框架開銷會迅速壓縮可用空間。因此，8GB更適合單使用者、短輸入的內部工具；需要輕併發時，12—16GB更合理。FP16版本通常要按約16GB權重空間準備，實際執行最好再留出餘量。

13B—14B 是企業工作站中較常見的折中點。INT4大約需要9GB，12GB顯示卡可以完成基礎部署，但餘量較小；16GB更適合保留較長對話歷史、接入檢索結果，或承受少量併發。若堅持使用FP16，顯示記憶體需求會上升到約28GB，單張常規消費級顯示卡通常不再合適。

32B 的 INT4 權重約20GB，24GB顯示記憶體可以執行，但屬於「能啟動、需要精細控制」的檔位：上下文過長、批次增大或同時服務多個請求，都可能觸及上限。32GB則便於留出快取和執行空間。FP16版本約64GB，通常需要高顯示記憶體單卡或多卡切分，不宜按普通工作站方案採購。

70B 即使採用 INT4，權重也接近40GB，工程上應把48GB以上視為更可靠的起點。FP16約140GB，往往需要兩張80GB級資料中心卡，或者採用多卡並行與切分部署。這裡的「多卡可執行」不等於「多使用者可用」：卡間通訊、頻寬和框架相容性都會影響實際吞吐。

從選型順序看，先確定業務允許的模型檔位，再在 INT4、INT8 和 FP16 之間取捨。INT4適合顯示記憶體受限、以生成和問答為主的部署；INT8通常在資源和精度之間更保守；FP16則主要用於顯示記憶體充足、需要更穩定數值表現或已有資料中心資源的場景。表中的顯示記憶體只能作為起始邊界，最終仍要用目標上下文長度和目標併發量進行壓測確認。

四、併發與上下文：為什麼「能跑」不等於「能上線」

單輪短對話能正常返回，只能證明模型權重已經裝入顯示記憶體，並不能說明這臺機器適合長期提供服務。權重通常在模型載入後保持相對穩定；真正會隨著請求變化的，是推理過程中儲存的 KV Cache。每個請求的輸入越長、輸出越多，快取佔用就越大；同時處理的請求越多，快取還會按請求數疊加。模型層數、注意力頭配置以及 KV Cache 使用的資料精度，也會改變這部分開銷。

因此，顯示記憶體預算至少要拆成三部分：模型權重、KV Cache，以及推理框架和執行時的額外空間。後兩項決定了「載入成功」與「穩定執行」之間的差距。一個只輸入幾百字、一次只服務一個人的測試，往往看不出長文件檢索、連續追問和多人同時請求帶來的壓力。尤其是 RAG 場景，檢索結果會把輸入上下文迅速拉長；如果還要求模型輸出較完整的答案，快取會在生成階段繼續增長。

不建議使用「每增加一個併發就固定增加若干 GB」的經驗係數。不同模型的層數和注意力結構不同，量化格式也可能只壓縮權重而不壓縮快取；推理框架對快取分配和批處理的實現同樣會影響結果。更可靠的做法是鎖定模型檔案、量化方案、推理框架、最大輸入長度和最大輸出長度，然後按併發數逐級測試，例如從 1、2、4、8 路開始。每一級都記錄顯示記憶體峰值、首 token 延遲、完整響應時間、生成吞吐，以及請求失敗或排隊比例。

測試時還要覆蓋兩類邊界：一類是短輸入高併發，觀察多人同時訪問時是否迅速耗盡快取；另一類是長輸入低併發，驗證單個請求是否會因上下文上限觸發 OOM。若業務是 RAG，還應固定檢索片段數量或總 token 上限，否則每次測試的輸入規模不同，結論無法比較。最終配置不應只看平均值，而要看高峰時段的顯示記憶體峰值和最慢請求。

顯示記憶體接近上限時，處理順序通常應是先收緊最大上下文和最大生成長度，再限制批大小或同時處理的請求數；對突發流量，可以引入排隊，讓系統用可控的等待換取不崩潰。對於支援分頁管理 KV Cache 的框架，可評估 PagedAttention 一類機制。vLLM 專案對該機制的設計目標，就是減少快取碎片並提高併發下的顯示記憶體利用率，但它不能消除模型權重、長上下文和高併發本身帶來的資源需求。

只有當限制上下文、控制併發和最佳化快取管理後，業務仍達不到目標吞吐，才應考慮更換模型、增加顯示卡或拆分服務。顯示記憶體選型的結論，應該來自固定條件下的壓測曲線，而不是來自一次「能生成答案」的演示。

五、按企業業務場景選擇配置，而不是盲目追求大模型

顯示記憶體規劃應先從任務的錯誤成本、呼叫頻率和資料形態倒推，而不是先確定一個最大的模型。企業內部問答、合同審核、程式碼生成和核心 API 服務，對模型能力、響應穩定性與併發的要求並不相同。相同的模型，在單人試用和多人同時訪問時，也可能對應完全不同的硬體預算。

1. 辦公類任務：8GB 是驗證線，不一定是上線線

郵件改寫、會議紀要、材料壓縮和企業制度問答，通常不需要一開始就部署大參數模型。7B 級 INT4 模型可以作為入門方案，8GB 顯示記憶體能夠完成單使用者或低併發驗證。但實際部署還要容納較長上下文、檢索增強元件、服務框架以及後續版本切換，因此 12—16GB 往往更容易留下餘量。這裡的「餘量」不是為了追求更高規格，而是避免模型勉強裝入後，稍微增加輸入長度就發生顯示記憶體溢位。

2. 隱私文件與部門知識庫：先保證可控，再追求參數規模

合同初篩、制度檢索和部門級知識問答，問題通常帶有固定格式、專業術語和內部敏感內容。13B—14B 的 INT4 配置、16GB 顯示記憶體，可以作為較穩妥的起點。相比把更大的模型壓縮到幾乎沒有執行空間，保留足夠顯示記憶體給上下文、向量檢索和併發請求，往往更利於控制延遲。工程驗收時，應重點檢查引用是否準確、拒答邊界是否穩定、相似問題的答案是否一致，而不是只看通用評測分數。

3. 程式碼和複雜推理：顯示記憶體升級必須對應可觀測收益

程式碼生成、數學題和複雜結構化抽取，對推理鏈完整性與格式遵循能力更敏感。可以從 14B、16GB 顯示記憶體起步；如果內部測試顯示小模型在關鍵任務上頻繁出錯，再評估 32B INT4 和 24—32GB 顯示記憶體。測試集應來自真實程式碼倉庫、歷史工單、財務表格或業務文件，並記錄一次通過率、人工修改時長、格式錯誤率和響應時間。若模型變大卻沒有減少返工，就不應僅憑參數量增加採購顯示記憶體。

4. 核心推理服務：70B 方案要和呼叫經濟性一起評估

複雜分析、跨文件判斷和對品質要求較高的內部 API，才有理由考慮 70B INT4 級別的部署，顯示記憶體通常需要 48GB 以上。低頻呼叫時，本地多卡裝置可能長期閒置；高峰期呼叫則還要考慮顯示記憶體佔用、卡間通訊、故障切換和維運人力。因此應把本地裝置折舊、電力、機房、備件與維護成本，與雲端 GPU 的按量費用放在同一張表裡比較。模型能力越強，越不能只用「能否啟動」作為驗收標準。

最終選擇應以業務壓測收口：固定模型版本、量化方式、上下文長度和併發數，分別記錄首 token 延遲、完整響應時間、顯示記憶體峰值及錯誤率，再決定是否需要更大顯示記憶體。這樣得到的是面向任務的配置，而不是脫離使用場景的顯示卡清單。

六、單卡、多卡、Mac 與 CPU 方案怎麼取捨

顯示卡數量不是部署能力的直接指標。單卡的價值在於鏈路短、配置少、故障點少；多卡的價值在於把單張卡裝不下的模型拆開，或用並行提高吞吐。Apple Silicon 和純 CPU 則更適合特定成本、功耗或離線約束。選型時應先確定模型、量化格式、上下文長度和併發目標，再判斷硬體形態。

單卡：優先解決上線複雜度

如果模型在單張卡中有足夠餘量，單卡通常是企業第一選擇。8—16GB 顯示記憶體可以覆蓋不少 7B 至 14B 的 INT4 部署；24—32GB 更適合把 32B INT4 放進同一張卡，或者執行 14B 的 FP16 版本。顯示記憶體達到 48GB 左右後，才進入量化 70B 的可行區間。

這裡的「餘量」不能只按權重大小計算。推理程序還要分配執行時緩衝、CUDA 工作區和 KV Cache。若目標是固定單使用者、短上下文，勉強裝入可能可以接受；若要承載多人請求，建議把顯示記憶體使用率、首 token 延遲和持續生成速度一併納入驗收，而不是只看模型是否成功載入。

多卡：顯示記憶體可以協同，但不是簡單相加

多卡適用於兩類問題：模型權重和執行時記憶體超過單卡容量，或者單卡吞吐不足。採用張量並行前，必須確認推理框架和模型實現支援對應的並行方式；有些軟體只能讓不同程序各用一張卡，並不能把一個模型高效拆開。

跨卡傳輸會帶來額外成本。PCIe 通道較窄時，層間或張量間頻繁同步可能抵消增加的計算資源；具備高速互聯的伺服器通常更適合這類部署。兩張卡的顯示記憶體容量也不能在所有框架中無條件合併，實際可用空間取決於分片策略、顯示記憶體分配方式和通訊緩衝。採購前應使用目標框架跑一輪真實模型，而不是只做顯示記憶體數字相加。

Mac 與 CPU：適合低併發、離線和研發用途

Apple Silicon 的統一記憶體可以被模型和圖形處理單元共同使用，因此 64GB 統一記憶體的機器可用於量化 32B，並嘗試較緊湊的 70B 配置；128GB 檔能為量化 70B 留出更寬鬆的空間。不過，統一記憶體並不等同於專業 GPU 顯示記憶體。模型載入後還要與作業系統、上下文快取和應用程序競爭記憶體，且推理框架的運算元覆蓋、批處理能力和服務化介面需要單獨測試。

CPU 加系統記憶體是可行的保底路徑。以 32GB 記憶體執行 7B INT4，適合文件離線處理、開發除錯、低頻問答或災備節點；但生成速度通常只有每秒幾個 token，和 GPU 常見的幾十乃至更高水平存在明顯差距。因此，CPU 方案應明確定位為低頻任務或容災能力，不宜直接承擔即時高併發介面。

一個實用判斷是：單卡優先看穩定性，多卡優先看框架和互聯，Mac 優先看生態與記憶體餘量，CPU 優先看業務是否允許等待。最終選擇應由目標模型的實測吞吐和延遲決定，而不是由裝置的理論顯示記憶體總量決定。

七、採購與上線：用壓測結果確認最終顯示記憶體

顯示卡採購不應從「這張卡能否載入模型」開始，而應從「業務請求在什麼條件下會把顯示記憶體推到邊界」開始。模型能夠成功啟動，只能說明權重和基礎執行環境放得下，不能證明它能承受真實使用者的併發、長上下文和複雜工具鏈。採購前最好先凍結一份脫敏測試集，並讓候選硬體、模型版本、推理框架和量化配置使用同一套輸入，避免不同測試條件造成錯誤比較。

測試集不能只放幾條短問答。至少應覆蓋以下幾類請求：

• 短提示詞與接近業務上限的長提示詞，用來觀察上下文長度對 KV Cache 的影響；
• 常見回答長度與較長輸出，避免只按平均響應估算生成階段的資源佔用；
• 帶檢索片段的問答，把文件數量、片段長度和後設資料一併納入測試；
• 需要呼叫外部工具、分步執行或返回結構化結果的任務，驗證中間狀態是否造成額外峰值；
• 涉及權限判斷、合同審閱、財務資料處理等敏感業務任務，確認實際提示模板不會改變資源需求。

每種場景都應重複測試，而不是只記錄一次最好成績。建議把請求按目標併發分組，分別觀察單請求、低併發和目標併發下的表現，並保留原始日誌。驗收記錄至少包括：模型載入完成後的顯示記憶體佔用、單請求執行時的最高顯示記憶體、目標併發下的最高顯示記憶體、首個 Token 返回時間、後續生成速度、整體吞吐量，以及超時、異常退出和結果不完整等失敗情況。

壓測時要特別檢查系統的「退化路徑」。當顯示記憶體達到高位，推理框架是否會把部分資料轉移到記憶體，是否因此觸發 CPU 解除安裝，或者只是讓首 Token 和生成速度突然變慢。後兩種情況未必立刻報錯，卻可能使線上 SLA 失效。還要模擬峰值請求與普通請求同時到達，觀察一個長上下文任務是否拖慢整批請求。

最終配置不能按測試期間出現過的最高佔用來貼著採購。峰值是風險邊界，不是建議的長期執行點；還要為驅動、程序波動、快取增長、模型熱更新以及突發併發保留安全空間。餘量具體留多少，應結合測試結果、業務容忍的延遲和擴容週期確定，而不是套用一個脫離場景的固定比例。

採購評估也不能只比較顯示卡單價。應把整機功耗和電源規格、散熱能力、機箱可安裝空間、驅動與推理框架的適配情況納入總成本；如果需要多卡，還要核對卡間通訊、主機板通道和部署複雜度。最後估算維運投入與後續模型升級成本：更大的模型、更長的上下文或新的量化方案，可能改變顯示記憶體和軟體棧要求。只有把這輪壓測結果與完整執行成本放在一起，才能判斷配置是「能啟動」，還是足以穩定上線。

八、FAQ：本地部署顯示記憶體選擇的四個常見問題

8GB顯示記憶體到底能不能部署企業大模型？

能，但更準確的說法是：8GB顯示記憶體適合部署經過壓縮的小模型，或承擔低併發、短上下文的內部任務，不等於可以穩定承載所有企業模型。顯示記憶體首先要容納模型權重，執行時還要為上下文快取、推理框架、臨時張量和併發請求預留空間。權重剛好塞進去，往往意味著一拉長上下文或增加第二個請求就開始溢位。

實際判斷可以按三步做：先確認模型的量化格式和檔案大小，再給執行時開銷留下餘量，最後用真實業務提示詞測試連續請求。8GB裝置通常更適合知識庫問答、文本分類、欄位抽取等短輸入任務；程式碼生成、長文件總結、多使用者併發則應優先增加顯示記憶體或降低模型規模。不要只看「模型能載入」，要看在目標上下文長度下是否能持續服務。

兩張16GB顯示卡是否等於一張32GB顯示卡？

不等於。兩張卡可以通過模型切分或張量並行共同承載一個模型，但可用容量不是簡單相加後的單卡體驗。跨卡傳輸會帶來通訊開銷，主機板插槽、PCIe頻寬、顯示卡間互聯方式以及推理框架的並行實現都會影響結果；部分框架還會因為分配策略，使其中一張卡先達到上限。

如果模型本身能完整放入一張16GB卡，兩張卡主要增加的是併發能力，而不是自動把單請求速度翻倍。若模型必須拆到兩張卡上，則應確認目標框架支援對應量化格式和多卡推理，並檢查顯示記憶體是否均衡。採購前最好用目標模型、目標上下文和目標併發做壓測；「總顯示記憶體達到要求」只能說明存在可行路徑，不能直接代表生產效能。

INT4量化會不會明顯降低業務效果？

會有影響，但影響大小取決於任務，而不是由「INT4」三個字元單獨決定。量化把權重用更低精度表示，通常能顯著減少顯示記憶體佔用，並改善本地推理的部署門檻；代價是在複雜推理、嚴謹程式碼、長鏈路規劃和邊界案例上，錯誤率可能比高精度版本更容易上升。

對普通檢索問答、摘要、分類和結構化抽取，INT4往往是值得優先驗證的起點。對財務計算、專業法規、程式碼審查等高風險流程，應同時保留高精度基線，用一組脫敏業務樣本比較事實正確率、格式合規率、拒答品質和人工返工比例。若品質不達標，可以先換更穩健的量化方案或提高模型規模，而不是直接購買更大顯示卡。Q8通常更接近原始模型效果，但顯示記憶體和吞吐成本也更高。

沒有獨立顯示卡，能否用系統記憶體或Mac統一記憶體部署？

可以。CPU推理框架能夠把模型放進系統記憶體，Apple Silicon則可使用統一記憶體承載模型與執行時資料。不過，系統記憶體容量只是「裝得下」的條件，記憶體頻寬和處理器能力決定「跑得動」的程度。與GPU相比，CPU方案的首 token 延遲和持續生成速度通常更弱，適合低頻、離線、單使用者任務，不適合作為多人即時服務的預設配置。

普通電腦應重點檢查記憶體餘量、交換分割槽和長時間執行時的穩定性；不要讓模型佔滿全部記憶體，否則系統和框架沒有緩衝空間。Mac方案則要按統一記憶體總量扣除作業系統、應用和上下文快取後再估算可用容量。容量較大的統一記憶體機型可以執行更大的量化模型，但仍需通過實際提示詞測試響應速度。若業務要求穩定併發，應優先採用獨立GPU或專用多卡主機，而不是只按記憶體容量做判斷。