顯示卡跑本地 AI 要幾多顯存？量化等級、Offload 代價同樽頸分辨規劃指南

2026-10-23 ｜ 顯示卡維修 ｜ 約 16 分鐘 ｜ HK GPU Fix 編輯部

重點摘要

本地AI顯存夠唔夠由模型大小、量化等級同上下文長度決定；顯存唔夠offload去系統記憶體，會明顯拖慢出字速度。

先講結論：顯存規劃要由模型行先

好多人買卡之前問嘅第一個問題係「呢張卡跑唔跑到本地 AI」，但呢個問題本身問得唔夠準。本地 AI 唔係一種負載，而係好多種負載：七十億參數嘅對話模型、幾百億參數嘅推理模型、圖像生成模型，佢哋對顯存嘅要求可以差十倍以上。問「跑唔跑到」之前，要先答三個問題：想跑幾大嘅模型、用幾高嘅量化精度、上下文要幾長。呢三個答案未定，任何「夠唔夠」嘅答案都係估。

規劃嘅正確次序係由模型行先，唔係由顯卡行先。先定模型同用途，再計顯存需求，最後先睇手頭張卡夠唔夠，或者買卡嗰陣應該點揀。倒轉行先，好容易買咗一張運算好強但顯存偏細嘅卡，結果想跑嘅模型根本放唔入；或者買咗一張顯存好大但自己根本用唔着嘅卡，白白使多咗錢。

本文講嘅係規劃方法同判斷邏輯，唔係故障維修指南。如果你部機跑本地 AI 嗰陣成日崩潰、報錯、花屏，嗰啲可能係另一類問題，應該按故障排查嘅邏輯處理，唔好同顯存規劃混為一談。

顯存入面裝咗啲乜：四個部分

要計顯存，首先要知道顯存入面裝咗啲乜。跑本地大語言模型嗰陣，顯存佔用主要來自四個部分。

第一係模型權重，呢個係最大頭。權重即係模型訓練出嚟嘅參數數值，推理嗰陣要成組放喺顯存入面先計到數。模型標示嘅參數量，例如七十億、一百三十億，就係權重數量嘅量級。

第二係 KV Cache。模型生成文字嗰陣，會將之前已經處理過嘅內容嘅鍵值暫存起嚟，之後生成新字嗰陣唔使由頭計過。呢個快取會隨住對話變長而不斷增長，長對話嘅顯存佔用會比短問答大得多。

第三係運算中途嘅 activation，即係每一層計數嗰陣產生嘅中間結果。呢部分通常比權重細，但喺批量較大、上下文較長嗰陣都唔可以忽略。

第四係固定開銷，包括驅動、推理框架本身、桌面顯示同其他常駐程式佔用嘅顯存。呢部分唔大，但佢解釋咗點解「理論上啱啱塞得入」嘅模型，實際跑起上嚟會差少少就爆。

記住呢四個部分，後面好多現象先講得通。特別係第二點 KV Cache，佢係「點解一開始跑到，寫寫下先爆」嘅關鍵。

權重容量點計：參數量乘以每個參數嘅位元組

權重容量可以用一條好簡單嘅算術估算：參數量乘以每個參數佔用嘅位元組數。唔同精度之下，每個參數佔用嘅位元組唔同：

• FP16 同 BF16：每個參數 2 位元組，精度最高，體積最大。
• FP8 同 INT8：每個參數約 1 位元組。
• Q8：每個參數約 1 位元組，連同量化用嘅 scale 資料一齊計，實際會略高少少。
• Q6：每個參數約 0.75 位元組。
• Q4：每個參數約 0.5 位元組，實際檔案視乎量化格式點樣儲存 scale 同 metadata 會略高。

用呢條算術，可以快速估算唔同規模模型嘅權重大約幾大：

要強調一次：呢個表只係權重本身嘅算術估算，未計 KV Cache、activation 同固定開銷。所以實際顯存需求一定比表入面嘅數字大，預留空間係必須嘅。舉例講，一個 Q4 嘅 70 億參數模型，權重約 4GB，但實際跑起上嚟，連同其他開銷，可能要用 6GB 上下；如果上下文開得好長，仲會再多。反過嚟講，如果張卡得 8GB 顯存，唔好以為「權重 7GB 所以入到」就等於跑得順，留返嘅餘量好可能唔夠應付長對話。

另一個規劃重點係：模型規模同量化等級要一齊睇，唔可以分開睇。一個 320 億參數嘅 Q4 模型，權重約 16GB；一個 700 億參數嘅 Q4 模型，權重約 35GB。兩者都係 Q4，但顯存需求差一倍有多。淨係講「我用 Q4」而唔講模型幾大，係計唔到數嘅。

量化等級點揀：唔係越低越抵，亦唔係越高越好

量化係將模型權重由高精度表示壓縮成低精度表示，用精度換體積。位元數越低，體積越細，顯存需求越低，但資訊損失越大。呢個取捨冇一個放諸四海皆準嘅答案，要按任務容忍度揀。

FP16 同 BF16 係參考基準，精度損失最細，但體積最大。顯存充裕嗰陣，用高精度最穩陣，唔使諗質素折損嘅問題。

Q8 係常見嘅平衡點，體積約為 FP16 嘅一半，質素變化一般較細。對於一般對話、摘要、寫作輔助呢類任務，Q8 通常已經夠用，係顯存同質素之間一個穩陣嘅選擇。

Q6 同 Q5 係中間檔，體積再細一截，質素變化開始因模型而異。呢個區間要實際試過先知接唔接受到，唔好憑感覺假設「差少少啫」。

Q4 體積最細，令大模型有機會塞入消費級顯卡，係好多人用大模型嘅唯一可行方法。但質素損失亦都最大，尤其係數學運算、程式碼生成、長推理呢類對精度敏感嘅任務，低精度量化嘅差異會較明顯；一般閒談可能感覺唔大，但較真嘅任務就會浮現。

揀量化等級嗰陣，有三個常見誤區要避。第一係「越低越抵」：Q4 入到顯存唔等於輸出合用，如果任務要求精度，低量化省返嘅顯存係用質素換返嚟。第二係「越高越好」：顯存根本放唔入高精度版本，堅持用 FP16 只會令模型完全跑唔到，退一級量化先係務實做法。第三係「量化等級可以跨模型比較」：同一個 Q4 等級，唔同模型、唔同量化格式嘅實際表現可以差好遠，唔好將 A 模型嘅經驗直接套落 B 模型。

實用建議係：先用你實際會用嘅任務試，唔好淨係試閒談。寫一段程式碼、計一條多步驟數學題、做一次長文件摘要，睇低量化版本嘅輸出係咪仍然可靠，先至決定用邊個等級。

上下文長度：點解短問答入到，長對話會爆

好多人遇到一個奇怪現象：同一個模型，短問短答跑得好順，對話寫長咗就突然報顯存不足。呢個唔係硬件突然出事，而係 KV Cache 嘅機制。

模型每處理一個 token，都會將相關嘅鍵值存入 KV Cache，之後生成新 token 嗰陣可以直接用，唔使重計。對話越長，KV Cache 越大；上下文窗口開得越大，KV Cache 嘅上限亦越高。所以顯存規劃一定要連上下文長度一齊計：你打算開幾長嘅上下文，就要預返相應嘅 KV Cache 空間。

呢個機制仲有一個實際含義：爆顯存嘅時機唔一定喺開始嗰陣。模型載入嗰陣只係權重入咗顯存，KV Cache 仲係細嘅；對話一路寫落去，KV Cache 一路脹，到某個位先至頂到上限。所以「一開始跑到」唔等於「全程都跑到」，規劃嗰陣要預長對話嘅情況，唔好只用三兩句測試就下結論。

如果你成日要處理長文件、長對話，規劃嗰陣就要特別留多啲顯存餘量，或者接受用較低量化等級去換取 KV Cache 空間。反過嚟講，如果你只係短問答，KV Cache 佔用有限，顯存壓力主要嚟自權重，規劃可以貼近權重數字多啲。

圖像生成：顯存佔用結構唔同，唔好用語言模型嘅算法照搬

圖像生成模型嘅顯存佔用結構同語言模型唔同，唔好將上面嘅權重算法直接搬過去。圖像生成嗰陣，顯存入面除咗主模型權重，仲有文字編碼器、VAE 解碼器同推理中途嘅 latent 中間結果。

影響圖像生成顯存需求嘅主要變數有幾個：輸出解析度、一次生成嘅張數、採樣步數同係咪做放大。解析度由 512 升到 1024，畫面像素變成四倍，中間結果同相關緩衝都會跟住脹，顯存需求可以差好遠。一次生成多張圖，佔用亦會跟住張數上升。放大步驟通常喺原圖基礎上再做一次較高解析度嘅處理，嗰段時間嘅顯存峰值可能比正常生成更高。

常見嘅節省顯存做法，係軟件提供嘅選項，例如分塊處理 VAE、切割注意力運算、用較低精度載入模型。呢啲選項嘅共通代價係速度：將一次過計完嘅嘢拆細嚟計，顯存峰值低咗，但總運算時間會變長。開呢啲選項之前，要明白自己換緊乜：用時間換顯存，唔係免費得到。

圖像生成爆顯存嘅典型訊號，係生成到某個階段先報錯，或者一加大解析度、一加多張數就出事。呢啲訊號指向嘅都係「峰值佔用超出顯存」，解決方向係降低解析度、減少張數、開節省顯存選項，或者換一個較細嘅模型，唔係一味重試。

VRAM 唔夠時 Offload 去系統記憶體：跑得到，但代價係速度

當模型放唔晒入顯存，一個常見做法係將部分模型層 offload 去系統記憶體：顯存放得落嘅層留喺顯存，放唔落嘅層暫存喺主機記憶體，運算嗰陣經 PCIe 通道來回搬運。呢個做法令「完全跑唔到」變成「跑得到」，但代價好實在。

代價嘅根源係頻寬差距。顯存頻寬通常以數百 GB 每秒計，PCIe 通道頻寬以數十 GB 每秒計，兩者數量級唔同。每次要用到 offload 咗嘅層，都要跨過呢條較慢嘅通道搬數據，時間就花喺搬運上面。

更關鍵嘅係，生成文字係逐個 token 進行嘅：每出一個新字，都要將相關權重過一遍。Offload 比例越高，每個 token 要跨通道搬運嘅數據越多，出字速度跌得越明顯。相反，處理輸入提示嗰段可以平行進行，Offload 對呢段嘅影響相對細。所以 Offload 最傷嘅係出字速度，唔係入提示速度；如果你覺得「入提示嗰陣仲好快，出字嗰陣慢到唔想等」，呢個正正就係 Offload 嘅典型表現。

Offload 嘅代價亦唔係線性嘅。少部分層 offload，可能只係慢少少，尚可接受；大部分層 offload，速度可以慢到難以實用。系統記憶體本身嘅容量同速度、CPU 參與運算嘅比例，都會影響最終表現，唔可以只睇 offload 比例一個數字。

邊界情況要講清楚：如果成個模型根本放唔入顯存，Offload 係「跑得到但慢」同「跑唔到」之間嘅取捨，唔係免費午餐。如果大部分層都 offload 晒，實際上已經接近純 CPU 推理，顯示卡嘅加速作用所剩無幾。呢個時候要諗嘅唔係「點樣 offload 得更盡」，而係「應唔應該換一個細一級嘅模型，或者用低一級量化」，令更多層可以留喺顯存入面。

點分辦係 VRAM 瓶頸定其他瓶頸

顯存唔夠同其他樽頸嘅表現有時好相似，唔分清楚就會換錯方向。以下係一套實用嘅分辨邏輯。

第一步，睇啱數字：一定要睇「專用顯存」用量，唔好睇「總可用圖形記憶體」。後者包括系統借出嘅共享記憶體，數字望落好大，但唔代表顯示卡本身有咁大顯存。判斷顯存夠唔夠，只睇專用顯存去到幾滿。

VRAM 瓶頸嘅典型訊號有幾個：專用顯存長期貼近上限；一加長上下文、一加大批量、一加高解析度就出顯存不足報錯或者明顯變慢；降低量化等級、縮短上下文、降低解析度之後問題即刻紓緩。如果改動顯存相關變數就有反應，顯存係樽頸嘅機會好高。

非 VRAM 瓶頸嘅訊號就唔同：顯存仲有大量空位，但速度仍然慢，呢個時候要懷疑運算核心能力、CPU、系統記憶體頻寬、磁碟 swap 或者散熱降頻。另一個分辨點係節奏：顯存爆滿嘅問題多數有個「臨界點」，過咗某個長度、某個解析度先突然出事；運算能力不足嘅慢，就由頭到尾平均地慢，冇明顯臨界點。

排查嗰陣要遵守一個原則：每次只改一個變數。量化等級、上下文長度、批量、解析度，每次只改一樣，記錄改動前後嘅專用顯存用量同生成速度，先至分得到邊個先係樽頸。一次過改幾樣，結果好咗都唔知邊樣改啱，結果差咗亦唔知邊樣累事。

仲有一個容易忽略嘅情況：系統記憶體本身唔夠。Offload 用嘅係系統記憶體，如果系統記憶體都逼爆，系統會用磁碟 swap 頂住，速度會再跌一個級數。呢個時候問題表面上似顯存唔夠，實際上係成個記憶體規劃都唔夠，淨係睇顯存數字會睇漏。

買卡同規劃清單：由用途出發，唔好淨係睇顯存數字

講到尾，規劃清單應該係咁行：

第一，定用途同模型：想跑幾大嘅模型、做對話定推理定圖像生成、上下文要開幾長。呢啲定咗，顯存需求先計得到。

第二，計權重再加餘量：用參數量乘以量化位元組計出權重大約數，再預留 KV Cache、activation 同固定開銷嘅空間。餘量唔好預得太貼，長對話同高解析度都會食多啲。

第三，揀量化等級要試真任務：用你實際會做嘅任務試低量化版本，唔好淨係試閒談。精度要求高嘅任務，寧願模型細一級但用高一級量化，都好過模型大一級但量化壓到質素唔合格。

第四，分清顯存同運算：顯存只決定放唔放得落，放得落之後嘅速度由運算核心同頻寬決定。買卡嗰陣兩個都要睇，淨係追顯存數字會買錯方向。

第五，接受 Offload 嘅定位：Offload 係後備方案，唔係同等速度嘅顯存。如果規劃結果係要長期 offload 大部分層，應該重新諗模型同量化選擇，唔好將 Offload 當成正常運作模式。

最後講返維修同檢查嘅分界：顯存規劃問題唔等於硬件故障，唔使急住懷疑張卡壞。但如果你按上面邏輯分完，發現顯存明明仲有空位、溫度正常、驅動正常，部機仍然成日崩潰或者出奇怪畫面，嗰個時候先值得懷疑硬件本身有問題，可以攞去檢查。檢查同維修收費按網站已公開嘅三級收費 HK$400 至 HK$2,800，實際以檢查後報價為準。

常見問題

問：8GB 顯存跑唔跑到本地大語言模型？

答：要睇模型幾大同用咩量化。70 億參數嘅 Q4 模型，權重約 4GB，連同其他開銷，8GB 顯存有機會應付短至中等長度對話；但 130 億參數以上嘅模型，或者要開好長上下文，8GB 就會好勉強。關鍵唔係「8GB」呢個數字本身，而係模型、量化、上下文三樣加埋嘅總需求。

問：Offload 開得多會唔會整壞張卡或者整壞系統記憶體？

答：Offload 本身係正常嘅軟件機制，唔會因為搬運數據而整壞硬件。佢嘅代價係速度，唔係硬件損耗。真正要留意嘅係系統記憶體夠唔夠：如果系統記憶體都逼爆再加磁碟 swap，成部機會變得非常慢，呢個係規劃問題，唔係硬件損壞。

問：量化壓得越低，係咪一定越差？

答：唔一定「一定越差」，但資訊損失一定越大，差異大定細要按任務睇。一般對話可能感覺唔大，數學、程式碼、長推理呢類任務差異會較明顯。唯一可靠嘅方法係用自己嘅實際任務試，唔好信感覺。

問：點解同一部機，短對話冇事，長對話先爆顯存？

答：因為 KV Cache 隨對話長度增長。模型載入嗰陣只係權重入咗顯存，對話一路寫落去，KV Cache 一路脹，到某個位先頂到上限。呢個係正常機制，解決方向係縮短上下文、降低量化等級或者換細一級模型。

問：圖像生成出到一半先報顯存不足，係咪張卡有問題？

答：未必。圖像生成嘅顯存峰值可能出現喺放大或者解碼階段，唔係一開始。先試降低解析度、減少一次生成張數、開節省顯存選項；如果顯存明明有空位都成日出奇怪錯誤，先再考慮其他原因。

如果你對本地 AI 嘅顯存規劃有疑問，或者部機跑 AI 負載嗰陣出現懷疑硬件引起嘅異常，可以帶部機去沙田石門達利廣場 1209 室檢查，電話 2186 8010，WhatsApp 6558 6806。本店無上門服務，檢查後會按實際情況報價。