本地 LLM 模型怎麼選?7B/70B、Q4/Q8 量化與 VRAM 一次搞懂

⚡ 站長快讀:核心重點

• 文章屬性:規格解析 / 深度解析(cornerstone)
• 適用對象:想在自己電腦上跑本地 LLM,卻搞不懂 Q4、Q8、7B、70B、VRAM 怎麼配的人
• 核心結論:本地 LLM 量化與參數量,決定了「模型聰不聰明」和「裝不裝得進你的顯示卡」——參數量拉高智商、量化壓低記憶體,兩條軸一起看才選得對
• 一句話心法:VRAM 裝得下的前提下,位元數(量化)挑能負擔的最高、參數量挑能塞的最大
• 資料誠信:本文所有檔案大小、位元數、速度數字皆引用 llama.cpp 官方 README 與模型廠官方文件公布之數據,非站長自有硬體實測,已逐筆標註來源層級

📌 快速答案

一句話答案:挑本地 LLM 量化版本的原則是「VRAM 裝得下就挑位元數最高的」——8GB 級顯示卡選 Q4_K_M、12～16GB 上 Q5_K_M 或 Q6_K、24GB 才玩 Q8_0;參數量(7B/70B)決定聰明度,量化(Q4/Q8)決定塞不塞得進記憶體。

🔍 故事的起點:卡住新手的不是「買哪張卡」,是「下載哪個檔」

很多人第一次想在自己電腦上跑 AI,查了一輪硬體之後,真正卡住的往往不是顯示卡,而是打開模型下載頁那一刻:同一個模型怎麼有十幾個檔案?Q4_K_M、Q5_K_S、Q8_0、IQ4_XS⋯⋯這串代號到底在講什麼,點錯了會怎樣?

先給結論:這串代號講的是量化(quantization),也就是「把模型的每個權重壓成幾位元」。它跟模型名字後面的 7B、14B、70B(參數量)是兩條不同的軸。參數量決定模型「有多聰明、記得多少知識」;量化決定「同一個模型要吃掉多少記憶體、跑多快」。選型的本質,就是在這兩條軸之間,找一個能塞進你 VRAM 的組合。

這篇不談「該買哪張顯示卡」(那是硬體端的問題,站長另外寫過本地端 AI 硬體指南:NPU 是智商稅嗎?),這篇專門解「手上這張卡,到底該下載哪個模型、哪個量化版本」——也就是模型端的選型。看完你會拿到三樣東西:一張看得懂的量化對照表、一條能自己估算 VRAM 的公式,還有一個「幾 GB VRAM 配什麼模型」的決策表。

🧪 原理拆解

一、參數量:7B、14B、70B 的「B」到底是什麼

先講重點:模型名字裡的 B 是 Billion(十億)個參數,參數越多通常越聰明,但記憶體也吃越兇。 一個 7B 模型有約 70 億個權重數字,70B 就是約 700 億個。這些數字就是模型從訓練資料學到的「知識」,存在一堆矩陣裡。

參數量直接決定兩件事。第一是能力:一般來說同一代模型,參數越多、越能處理複雜推理、長文理解、程式碼生成,幻覺也相對少一點。第二是記憶體占用:每個參數都要用一定的位元數存起來,參數越多、檔案越大、載入時吃的 VRAM 越多。這就是為什麼 70B 模型無法塞進一張 8GB 的顯示卡——光是權重就遠遠超過。

常見的參數量級距與適用情境,可以先有個粗略印象:

💡 截至 2026 年年中,消費級本地部署的主流開放權重家族包含 Qwen、Llama、Gemma、Mistral、DeepSeek、GLM 等,每個家族都提供從幾 B 到數百 B 的多種尺寸。型號與版本迭代很快,下載前請以該模型當前的官方頁面為準;本文聚焦「怎麼看規格、怎麼算記憶體」這種不會過期的觀念,而不是背特定型號。

二、量化:Q4、Q8 差在哪,為什麼 Q4_K_M 常被說是「甜蜜點」

先講重點:量化就是把每個權重從 16 位元浮點數,壓成更少的位元(如 8 位元、4 位元),用一點點精度換一大塊記憶體。 原始模型通常以 16 位元(FP16 / BF16)訓練與發布,一個權重占 2 個位元組;量化到 8 位元約占 1 位元組、4 位元約占 0.5 位元組。位元數砍半,檔案和 VRAM 幾乎也砍半。

關鍵問題是:壓下去會不會變笨?答案比多數人想的樂觀。根據 llama.cpp 官方以 Llama-3.1-8B 實測公布的數據,Q8_0 的品質幾乎與 FP16 無異(困惑度差異極小),而 Q4_K_M 用不到一半的體積,只換來很小的品質下降,這也是社群普遍把 Q4_K_M 當「甜蜜點」的原因。真正明顯掉品質的是 Q3、Q2 這種極低位元檔——除非記憶體真的很吃緊,否則不建議一開始就跳到那麼低。

以下是 llama.cpp 官方 README 針對 Llama-3.1-8B 公布的對照(檔案大小為該 8B 模型的實際數字,引用自 llama.cpp 官方,非站長硬體實測):

還有一個反直覺、但很實用的重點:量化越低,通常「生成速度」反而越快。 一樣是 llama.cpp 官方在同一測試機上的數字,同一個 8B 模型的文字生成速度,Q4_K_M 明顯快過 Q8_0、更遠快過 F16。原因是本地推論多半卡在記憶體頻寬——權重越小,每產生一個 token 要搬的資料越少,自然越快。所以量化不是只有「省空間」的好處,還順帶「跑更快」;這也是為什麼多數人日常用 Q4_K_M 而不是硬上 Q8_0。(速度數字依硬體而異,此處僅引用官方測試機的相對趨勢,非站長實測。)

三、GGUF 命名解碼:Q4_K_M 的 K 和 M 到底是什麼

先講重點:GGUF 檔名那串代號是有規則的——Q 後面的數字是目標位元數,_K 代表現代的 K-quant 方法,_S/_M/_L 代表混合精度的「保留程度」。 看懂這套命名,你就不會在下載頁前面發呆。

一段一段拆:

• Q + 數字:目標位元數。Q4 約 4 位元、Q8 約 8 位元。數字越大越精準、檔案越大。
• _K(K-quant):llama.cpp 現代的量化法。它把權重切成 256 個一組的「超級區塊(super-block)」,再細分小組,每組各自帶縮放與偏移量,用兩層結構讓低位元也能保有不錯的精度。有 _K 的比舊式 _0／_1(legacy)品質更好,是目前主流,優先選它。
• _S / _M / _L(Small / Medium / Large):同樣位元數下的混合精度配方。模型裡有些張量(層)比較關鍵,_M、_L 會把這些關鍵層保留在較高位元,_S 則壓得更平均。實務上 _M(Medium)是最常見的平衡點,Q4_K_M、Q5_K_M 都是這個道理。
• IQ 開頭(i-quant):進階的「重要性矩陣(importance matrix)」量化,能在很低位元(2～3 位元)時保住比傳統 K-quant 更好的品質,代價是製作時需要校準資料、在部分硬體上稍慢。記憶體極度吃緊要壓到 2～3 位元時才會考慮。

💡 一句話選法:一般人看到 Q4_K_M、Q5_K_M、Q6_K、Q8_0 這幾個就夠用了。優先 _K 系列、_M 配方;IQ 系列留給硬要壓超低位元的極端情況。llama.cpp 官方也是最常提供 4、5、6、8-bit 這幾個檔位。

四、算給你看:模型檔案大小與 VRAM 的估算公式

先講重點:你不用死背每個模型的數字,記一條公式就能自己估——檔案大小 ≈ 參數量(十億)× 每權重位元組數。 每權重位元組數大約是:FP16 = 2、Q8 ≈ 1、Q4 ≈ 0.5～0.6。

換算成「每 10 億參數(1B)大約吃多少 VRAM」,這是最好用的心算基準:

拿官方數字驗證一下就知道這公式夠準:llama.cpp 官方列出 Llama 3.1 8B 的 Q4_K_M 約 4.9 GB、70B 的 Q4_K_M 約 43.1 GB、405B 約 249.1 GB——和「0.5～0.6 GB × 參數量」幾乎吻合。

但光算模型檔案還不夠,實際 VRAM 占用要再往上加一截:

實際 VRAM ≈ 模型權重 + KV cache(隨 context 長度成長)+ 框架與運算暫存。經驗上,在中等 context 下,整體大約要在模型檔案大小之上再抓 15～20% 的餘裕;context 開很長時,KV cache 甚至可能比模型本身還吃記憶體(見下一節)。

所以看到「這個檔 4.6 GB」不代表 4.6GB 的卡就穩跑;抓到 5.5～6GB 才有安全邊際。這也是很多新手「檔案明明比 VRAM 小、卻還是爆掉」的主因。

五、被忽略的隱形吃 VRAM 大戶:KV cache 與 context 長度

先講重點:除了模型權重,推論時還要存「KV cache」,它會隨著你餵進去的 context(上下文)長度線性成長——context 開越長,VRAM 吃越多,長文場景常常是它先爆,而不是模型權重。 這是規格表上看不到、卻最容易翻車的一塊。

KV cache 是模型在生成時,為了不重算前面每個 token,把已算好的 Key／Value 暫存起來的機制。它的大小大致正比於:層數 × KV head 數 × head 維度 × context 長度。前面幾項是模型固定的,唯一由你控制的就是 context 長度——所以把 context 從 4K 開到 32K、128K,KV cache 會跟著翻好幾倍。

好消息是現代模型多半用了 GQA(Grouped-Query Attention,分組查詢注意力),大幅砍掉 KV cache。舉例來說,Llama 3 的 70B 只用 8 組 KV head,讓它的 KV cache 反而比舊式多頭注意力的小模型還省。這也是為什麼近年模型能把 context 拉到很長還不至於立刻爆卡。

兩個實用對策:

• context 開夠用就好,不要無腦拉到最大。日常問答、摘要,8K～16K 多半綽綽有餘;真的要餵長文件再往上加。
• KV cache 也能量化。多數本地推論工具(llama.cpp、Ollama、LM Studio 等)支援把 KV cache 壓成 8 位元,約可再省一半 KV 記憶體,對品質影響通常很小——長 context 快爆卡時的救命稻草。

六、決策表:幾 GB VRAM,配什麼模型 × 什麼量化

先講重點:把前面幾條合起來,就能對照自己的 VRAM 直接查該下載什麼。 以下以 Q4_K_M 為預設甜蜜點,搭配中等 context、已含 15～20% 餘裕估算(仍以實際模型與 context 為準):

📋 看表口訣:先用 VRAM 反推「能塞多大參數量」,同尺寸內再把量化位元數往上加到剛好塞得下。寧可 14B-Q4,也不要硬塞 14B-Q8 爆卡;但若同樣是 8B,VRAM 夠就選 Q6_K／Q8_0 拿更好品質。想先把模型跑起來、還沒裝環境的,可參考站長寫的 Windows 本機用 Ollama 跑 LLM 教學。

💡 總結:站長的選型心法

講到選型,站長我最想先破除的迷思是「位元數越高一定越好」。從 llama.cpp 官方公布的數字就看得很清楚:Q8_0 相對 Q4_K_M 多吃近一倍記憶體、生成還更慢,品質卻只多一點點。對絕大多數人,Q4_K_M 才是那個「花小錢辦大事」的檔位;硬上 Q8 常常是把 VRAM 浪費在感覺不太出來的差異上,還犧牲了速度與可用的 context 長度。

站長我的實際選型順序是這樣:先看手上的 VRAM → 反推能塞多大參數量的模型 → 同尺寸內把量化挑到剛好塞得下、並預留 15～20% 給 KV cache → context 開夠用就好。參數量優先於量化位元數——同樣的記憶體預算,一個 14B-Q4 通常比一個 8B-Q8 更聰明好用,因為「多一倍參數」帶來的能力提升,往往大於「多幾個量化位元」。

要提醒的是,本文所有量化位元數、檔案大小、速度趨勢,都是引用 llama.cpp 官方 README 與各模型廠官方文件公布的數據,不是站長在自有硬體上的實測;不同硬體、不同模型架構,實際數字會有出入,請以你要下載的那個模型當前官方頁面標示的檔案大小為準。硬體端「該買哪張卡、NPU 值不值得」的取捨,則屬於另一個題目——想一次把硬體選好的,建議搭配站長的本地端 AI 硬體指南一起看,一個管「買什麼硬體」、一個管「下載什麼模型」,兩篇合起來就是完整的本地 AI 上手地圖。

❓ 常見問題

Q:量化會讓模型變笨嗎?Q4 跟原版差很多嗎?

會掉一點,但沒你想的嚴重。依 llama.cpp 官方數據,Q8_0 幾乎與原始 FP16 無異,Q4_K_M 只換來很小的品質下降卻省一半以上記憶體,所以 Q4_K_M 被當甜蜜點。真正明顯變笨的是 Q3、Q2 這種極低位元,那是記憶體真的不夠時的救急選項,不是日常首選。

Q:同樣的 VRAM,我該選「大模型低量化」還是「小模型高量化」?

多數情況優先「大模型、量化到剛好塞得下」。參數量帶來的能力提升,通常大於多幾個量化位元的差別,例如 14B-Q4 一般比 8B-Q8 好用。但別壓到 Q3、Q2 那種會明顯掉品質的等級;如果為了塞大模型得犧牲到 Q2,那寧可退回小一號模型、用 Q4_K_M。

Q:我的模型檔案明明比 VRAM 小,為什麼還是跑不動或爆記憶體?

因為實際占用不只模型權重,還要加 KV cache(隨 context 長度成長)和框架暫存,通常要在檔案大小之上再抓 15～20% 餘裕。若你把 context 開得很長,KV cache 可能暴增甚至超過模型本身。對策是 context 別開過大,或開啟 KV cache 8 位元量化再省一半。

Q:GGUF、GPTQ、AWQ、MLX 這些格式差在哪?我該用哪個?

它們是不同的量化／打包格式,對應不同的執行工具。GGUF 是 llama.cpp 生態(含 Ollama、LM Studio)用的,CPU／GPU 通吃、最適合一般人在 Windows／Mac 上跑;GPTQ／AWQ 偏 NVIDIA GPU 的推論框架(如 vLLM);MLX 是 Apple 晶片專用。在自己電腦上入門,直接選 GGUF 的 Q4_K_M 最省事。

Q:純 CPU、沒有獨立顯示卡也能跑本地 LLM 嗎?

可以,但要放低期待。沒有獨顯時模型跑在系統記憶體(RAM)上、由 CPU 運算,速度會慢很多,建議選 4B 以下的小模型加 Q4 量化,拿來做即時補全、關鍵字抽取還算堪用;要跑 7B 以上並有互動體感,還是需要有足夠 VRAM 的顯示卡或 Apple 統一記憶體架構。

🔗 延伸閱讀

• 2026 本地端 AI 硬體指南:NPU 是智商稅嗎?GPU、VRAM 怎麼配
• 你的「AI PC」只是行銷騙局?本地端大模型實戰與 NPU 真實算力
• Windows 11 25H2 解放 NPU:本地端 AI 算力啟用與 Ollama 最佳化
• 拒絕訂閱制!Windows 本機跑 AI:Ollama + Open WebUI 教學
• Windows Copilot 完整教學:內建 AI 助理會找檔案、看螢幕

📎 參考資料來源

📖 第一級|官方文件與參考實作:

• llama.cpp 官方 quantize 說明(GGUF 量化方法、bits/weight 與檔案大小對照、記憶體需求表) — 2026-07-06 查證
• llama.cpp k-quants 原始討論(PR #1684) — 2026-07-06 查證
• Qwen 官方文件:以 llama.cpp 量化(K-quant 混合精度、imatrix、執行工具) — 2026-07-06 查證
• Hugging Face:Perplexity(困惑度)說明文件 — 2026-07-06 查證

📖 第二級|權威技術資料(交叉佐證,非規格最終權威):

• arXiv:llama.cpp 量化在 Llama-3.1-8B 上的統一評測 — 2026-07-06 查證

⚠️ 本文核心事實(位元數、檔案大小、記憶體需求)以第一級 llama.cpp 官方與模型廠官方文件為準,第二級為交叉佐證。所有數字為官方／第三方公布值,非站長自有硬體實測。

📅 本文查證戳記:2026-07-06 依 llama.cpp 官方文件與各模型廠公開資料撰寫。本地 AI 生態迭代快,型號與檔案大小請以下載當下的官方頁面為準,歡迎在留言區回報變動。