LV.06 模型圖鑑與量化｜本地 LLM 冒險

這一關要打倒什麼？

Boss 是「記憶體爆表肥大症」。症狀很具體：你下載了一個看起來很厲害的模型，一載入，Mac 風扇狂轉、滑鼠變卡，活動監視器（Activity Monitor）的記憶體壓力條變紅，系統開始把資料換到硬碟（swap）。

這就像在一間 16 床的病房硬塞 30 位病人：不是醫療能力不夠，是床位不夠。本關的目標是學會「看懂模型的規格，事先算出它佔幾張床」。

本章的版本資訊與模型清單截至 2026-10，來源為作者整理的研究筆記（Hugging Face API、Ollama library 於 2026-10-06 的查詢結果）。這個領域每週都在變，上線後請以各模型官方頁面為準。

先講為什麼：模型的大小是由什麼決定的？

LLM 的「大腦」其實就是一大堆數字，叫做權重（weights）。參數量（parameters）就是這些數字的個數，例如 8B = 80 億個數字。每個數字要用幾個位元（bit）存，決定了它佔多少空間：

FP16 / BF16：每個數字 16 bit = 2 byte
Q8（8-bit 量化）：約 1 byte
Q4（4-bit 量化）：約 0.5 byte，實務上因為有額外的縮放資訊，常見約 4.5–4.9 bit 有效

所以有一條很好用的估算公式：

權重大小（GB）≈ 參數量（B）× 位元數 / 8

逐行解釋：

參數量（B）：以十億為單位，8B 就填 8。
位元數：FP16 填 16，Q8 填 8，Q4 填 4（保守一點可填 4.5）。
/ 8：1 byte = 8 bit，把位元換成位元組。
結果單位剛好是 GB（十億 byte），所以不用再換算。

例：8B 模型，FP16 = 8 × 16 / 8 = 16 GB；Q8 ≈ 8 GB；Q4 ≈ 4 GB（實務約 4.5–5 GB）。

公式的三個但書

多模態模型會偏大。研究筆記裡以 Qwen3.5-9B 為例：9.65B 參數，Q4_K_M 實際檔案 6.6 GB，約 0.68 GB／B，比純文字模型的 0.57–0.62 GB／B 高，因為裡面還有視覺模組與 embedding。
要另外預留 KV cache 與 runtime 開銷。KV cache 會隨 context（上下文）長度增加；教學上建議預留 2–4 GB（context 在 8k 以內）。
macOS 不會把全部記憶體給 GPU。研究筆記以「約三分之二」作為保守估計，但官方數字尚未查證，建議你先看自己的 Mac 實際行為，不要把它當定論。

下面的互動工具可以讓你輸入機型與模型，直接看估算結果。

輸入模型大小與設定，估算需要多少記憶體，並對照三種常見硬體。這是估算，實際依模型架構而異。

參數量（B = 十億）Context 長度（tokens）

模式

權重位元

估計記憶體

6.4 GB

權重: 4.8
KV cache: 0.6
執行環境: 1.0

16GB Mac綠燈：寬裕（可用約 10.7 GB）
32GB Mac綠燈：寬裕（可用約 21.3 GB）
Colab T4 15GB綠燈：寬裕（可用約 15.0 GB）

綠燈 = 估計值 ≤ 可用的 80%；黃燈 = ≤ 100%；紅燈 = 超過。Mac 預設約三分之二的統一記憶體可給 GPU（作者背景知識，未逐版本查證）；Colab 免費版通常分到 T4，但不保證。

實測對照

作者在 M5 32GB 的實測：Gemma 4 E2B（4-bit）、mlx-lm LoRA、batch 4、seq 2048，peak 記憶體 14.8 GB。本估算器對同設定給出 14.6 GB，其中 logits 就占 8.0 GB。 Gemma 4 的詞表有 262,144 個 token，每個位置都要算一整排分數再算 loss，batch × 長度 × 詞表一乘就很可觀；這也是為什麼「把 batch 從 4 降到 1」對省記憶體特別有效。Unsloth 這類框架用分塊計算 loss，這一項會小很多。結論：估算器適合判斷「大概放不放得下」，邊界附近請以實測為準，並預留餘裕。

公式與係數

權重 GB = 參數量（B）× 有效 bits ÷ 8；有效 bits：4-bit 約 4.8、8-bit 約 8.5、16-bit = 16。
推論 = 權重 + KV cache + 1 GB 執行環境；KV cache 以每 token 每 B 參數 0.02 MB 粗估。
LoRA / QLoRA = 權重 + 1 GB + 訓練暫存；暫存 = 係數 × 參數量（B）× (context ÷ 2048) × batch，係數 LoRA 0.3、QLoRA 0.15（假設有開 gradient checkpointing）。
logits（只在訓練、且框架會產生完整 logits 時）= batch × context × 詞表大小 × 4 bytes（bf16 分數 + 其梯度）。mlx-lm 屬於這種；Unsloth 的分塊 loss 可視為接近 0。
係數由作者對照 Unsloth 公布的最低 VRAM 表（3B–32B）擬合，僅為教學用粗估；logits 項用作者的實測校對過。

量化：像 JPEG 壓縮

一張病理切片數位影像，存成原始 TIFF 可能數百 MB，存成 JPEG 只要幾 MB，肉眼看起來差不多，但放大細看會有壓縮痕跡。量化（quantization）就是對模型權重做同樣的事：用較少的 bit 近似原本的數字。

好處：檔案小、載入快、需要的記憶體頻寬少，所以通常也跑得比較快。
代價：資訊有損。位元數壓得越低，品質下降越明顯。
有一份 2026 年的研究（PMID 42174969，Stud Health Technol Inform）在 105 份神經外科病歷上測試 Qwen3、DeepSeek-R1 家族（0.6B–70B）的多種量化，結果顯示約 4–5 bit 之後誤差進入平台期。但要注意：這是單一研究、單一任務、用 prompt 的情境，不代表你的 fine-tune 任務也一樣，仍建議自己量一次。

初學者的預設選擇：Q4 起步；如果發現輸出品質不穩，才往 Q8 升級並確認記憶體放得下。

兩種格式：GGUF 與 MLX

GGUF：llama.cpp 體系的單一檔案格式，檔名常見 Q4_K_M、Q8_0 這類後綴。Ollama、LM Studio 都能載入，跨 Mac／Windows／Linux。
MLX：Apple 為 Apple Silicon 打造的機器學習框架，權重通常是一個資料夾（safetensors + 設定檔）。mlx-lm 與 LM Studio 的 MLX 引擎使用它，只在 Apple Silicon 上能跑。

不用急著選邊站。本站主線在 Mac 上會用 MLX 訓練，再轉成 GGUF 匯入 Ollama（見後面 LV15），所以兩種都會碰到。

模型圖鑑（截至 2026-10）

下表整理自作者的研究筆記（research/03），大小為 Ollama 預設量化版的檔案大小，不含 KV cache。授權欄請以模型卡原文為準。

模型	參數	量化後約略大小	授權	備註
Qwen3.5-4B	4.66B	q4_K_M 3.3 GB	Apache-2.0	16 GB Mac 很輕鬆
Qwen3.5-9B	9.65B	q4_K_M 6.6 GB	Apache-2.0	16 GB Mac 推論主力
Gemma 4 E2B	effective 2B	qat 4.3 GB	Apache-2.0	本站主線的基底模型
Gemma 4 E4B	effective 4B（總參數約 8B）	qat 6.1 GB	Apache-2.0	多模態
Gemma 4 12B	11.96B	qat 7.2 GB	Apache-2.0	16 GB Mac 可推論
Gemma 4 26B-A4B（MoE）	25.8B 總／約 4B 活躍	qat 16 GB	Apache-2.0	32 GB Mac 推論；LV10 用來生成合成病歷
gpt-oss-20b	20.9B MoE	14 GB	Apache-2.0	16 GB Mac 太緊
Phi-4-mini	3.84B	—	MIT	繁中能力未見評測
SmolLM3-3B	3.08B	—	Apache-2.0	小而完全開放，適合練習

醫學專用模型

MedGemma 1.5 4B（2026-01 發布）是目前仍持續更新的官方醫學小模型，但它是 gated，授權是 Health AI Developer Foundations terms，需要你自己登入 Hugging Face 閱讀並同意。官方定位是「基礎模型，需自行 adapt／fine-tune，輸出不用於臨床診斷」。本站不會代你同意條款，也不散布它的權重。
Meditron、BioMistral、OpenBioLLM 等 2023–2024 年的醫學模型，在研究筆記中被判斷已落後於 2026 年的通用小模型，這裡只當歷史對照。作者沒有找到 MedGemma 1.5 4B 與 Qwen3.5-4B 在同條件下的公開對比，所以不宣稱誰比較好。

繁中模型：先不要下定論

台灣有 Gemma-3-TAIDE-12b、Llama-Breeze2 等模型，TAIDE 需要申請授權。繁中能力目前作者只找到一份第三方、單次的評測，設定未完整揭露，不適合當結論，所以本站改成「自己用 10 題在地題目測」。這比引用別人的數字更可靠。

依機型的建議上限（作者整理的推論值）

硬體	通常舒適	偏緊
16 GB Mac	約 9B 以下的 Q4	gpt-oss-20b、Gemma 4 26B-A4B
32 GB Mac	約 27B 以下的 Q4	31B、35B 級在長 context 時
Colab T4（通常分到，官方不保證）	推論約 14B 以下的 Q4	—

實作

🍎 Mac：LM Studio 比較 Q4 與 Q8

開啟 LM Studio，搜尋同一個模型（例如 Qwen3.5-4B）的 Q4 與 Q8 兩個版本，分別下載。
記錄兩個檔案大小。
用同一個問題各問一次，在聊天視窗底部讀取 tok/s（每秒產生的 token 數）。
打開活動監視器，觀察載入前後記憶體壓力。
把結果填進表格：檔案大小、tok/s、答案品質主觀印象。

作者的觀察只能當參考，因為你的機型不同；速度數字請以你自己的為準。

☁️ Colab：用 huggingface_hub 讀模型卡

from huggingface_hub import model_info

for repo in ["Qwen/Qwen3.5-4B", "google/gemma-4-E2B-it"]:
    info = model_info(repo, files_metadata=True)
    size_gb = sum(s.size or 0 for s in info.siblings) / 1e9
    print(repo, info.card_data.license if info.card_data else None, f"{size_gb:.1f} GB")

逐行解釋：

model_info(repo, files_metadata=True)：向 Hugging Face 查詢該模型的資訊，並要求附上每個檔案的大小。
sum(s.size or 0 for s in info.siblings)：把所有檔案大小加總；有些檔案沒有大小資訊就當 0。
/ 1e9：byte 換成 GB。
info.card_data.license：模型卡上宣告的授權。若是 gated 模型，部分欄位需要先登入才讀得到。

repo 名稱以你查到的實際名稱為準，這裡只是示範格式。再把大小套進前面的公式，對照一下哪個比較貼近。

打倒 Boss 的條件

在動手下載前，先花一分鐘做三件事：查授權、用公式估記憶體、確認是 GGUF 還是 MLX。下次看到「記憶體爆表」的症狀，你就知道問題出在哪裡。

本關重點

權重大小 ≈ 參數量 × 位元數 / 8，再預留 KV cache 與 runtime 開銷（教學上約 2–4 GB）。
量化像 JPEG：用少量資訊損失換記憶體；Q4 是常見起點，但要以自己的任務驗證。
GGUF（llama.cpp 體系、跨平台）與 MLX（Apple Silicon 專用）是兩種格式，本站主線會兩者並用。
讀模型卡先看授權與是否 gated；gated 模型要自己登入同意，不要用轉傳權重繞過。
繁中能力沒有可靠的公開數字，改用自己的在地題目測。模型版本資訊截至 2026-10，會過時。