Ollama 量化怎麼選：q4_K_M、q8_0 還是 fp16？

Ollama 量化的變化

Ollama 量化會將模型中的每個權重，以少於訓練時所使用檔案的位元數儲存。以 q4_K_M 結尾的標籤，表示每個權重約使用 4 個位元；fp16 則使用 16 個位元。因此，下載檔案的大小約為四分之一，機器為產生每個 token 所讀取的位元組也約為四分之一。權重會四捨五入到較粗略的數值網格，而不是直接捨棄；對大多數模型而言，使用 4 個位元時，回答方式仍接近完整精度。

這就是完整的取捨：大幅降低記憶體用量並提高每秒 token 數，但會付出些微的準確度損失。以下說明如何在下載檔案前，針對特定模型與特定主機，預估這兩方面的影響，避免花二十分鐘下載無法載入的檔案。

如果 Ollama 尚未執行，請先參閱在 VPS 上安裝 Ollama。本頁假設 ollama ls 已可正常運作。

如何讀取 Ollama 量化標籤，例如 q4_K_M

本機模型以 GGUF 檔案提供。這是 llama.cpp 用來在磁碟上儲存權重的格式。Ollama 建構於 llama.cpp 之上，因此 Ollama 標籤會原樣沿用 llama.cpp 的量化名稱。

數字代表目標位元寬度。 q4 表示大多數權重張量會以每個 4 位元的方式封裝。q8 表示 8 位元。fp16 完全未經量化：它是以 16 位元浮點數表示的模型，也是大多數模型發布時使用的精度。

K 表示 K-quant。 權重會分成多個小區塊，每個區塊會在封裝值旁儲存自己的尺度。一個權重都接近 0.01 的區塊會使用細緻的尺度。包含一個大型離群值的區塊則會使用較粗略的尺度。這些逐區塊尺度讓 4 位元檔案仍可實際使用，也是 4 位元檔案永遠不會真正做到每個權重恰好 4 位元的原因。

最後一個字母代表混合方式。 S、M 與 L 會決定有多少張量提升至高於目標位元寬度。在 q4_K_M 中，四捨五入後影響最大的張量會以較寬的格式儲存，其餘大部分仍維持 4 位元。因此，q4_K_M 的輸出品質會優於較舊的 q4_0，但檔案大小幾乎相同。

請直接詢問 Ollama 磁碟上有哪些內容，不要根據輸入的名稱猜測：

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show 會顯示 architecture、parameters、quantization、context length 與 embedding length。對於數個月前拉取、已不記得當時選擇哪個模型的情況，quantization 行才是實際狀態的依據。

每個權重的位元數決定檔案大小

所有大小估算都從一個數字開始：整個檔案平均每個權重使用多少位元。llama.cpp 在其 quantize 文件中公布了 Llama 3.1 8B 的實測數據；對於形狀相近的任何 dense model，這些數據也具有良好的參考價值。

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

表格中令人意外的是第二欄。Q4_K_M 並不是每個權重 4 位元，而是 4.89 位元，因為區塊縮放值與提升精度的張量都會實際占用空間。Q8_0 同樣不是 8 位元，而是 8.5 位元。使用實測數字計算，結果會與實際檔案大小相差不到幾個百分點：

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

這就是從兩個數字還原出的 4.58 GiB Q4_K_M 檔案。這個數字也大致等於載入後權重占用的記憶體。Ollama 載入時不會解開權重；量化權重會以相同的封裝形式留在記憶體中，使用各區塊時才會逐一轉換。

Ollama 實際為各模型大小提供的內容

對大多數模型系列，模型庫會發布 q4_K_M、q8_0 和 fp16 標籤。以下是截至 2026 年 8 月，從模型頁面標籤清單讀取的 Qwen3 大小。

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

預設標籤在這裡很重要。ollama pull qwen3:8b 下載的檔案大小與 ollama pull qwen3:8b-q4_K_M 完全相同，都是 5.2 GB，因為未加後綴的標籤本身就是 q4_K_M 版本。Q4_K_M 並不是模型庫勉強提供的折衷方案，而是上游選定的預設版本。因此，對於尚未自行測試的模型，優先採用相同版本是合理的做法。在 VPS 上執行 Qwen 3 時的標籤選擇也是基於相同原則。

這些比例適用於每一列。從 q4_K_M 改用 q8_0，所需空間約增加 70%，而不是剛好變成 2 倍，因為 embedding 和輸出 tensor 的縮放方式與其餘部分不同。fp16 的大小約為 q4_K_M 的 3 倍。32B 模型使用 q4_K_M 時，權重就有 20 GB，這已經超過 16 GB 主機在保留任何 context window 的情況下所能容納的大小。若要更完整地了解哪些模型適合哪些主機，請參閱可自行託管的模型。

為什麼 KV cache 是第二項、取決於內容的成本

權重是固定成本。KV cache（key and value cache）則是可變成本。內容視窗中的每個 token，都會為每一層保留自己的 key 和 value 向量，因此 cache 會隨允許的視窗大小呈線性增長。模型載入時會為整個視窗配置 cache，而不是等對話逐步填滿才配置。因此，即使提示只有一個字，較長的視窗仍會占用記憶體。

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

這些模型數值來自模型本身的設定：36 層、8 個 key/value heads，以及 128 的 head dimension。ollama show 提供架構與參數數量；模型在 Hugging Face 上的 config.json 則提供其餘資訊。將每個 token 的成本乘以視窗大小後，cache 的占用量就不再只是四捨五入誤差。

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

在 Ollama 預設的 4096 tokens 視窗下，cache 會在權重之外增加 0.6 GB。將視窗提高到 32k 後，單是 cache 就會占用 4.83 GB，幾乎與量化權重需要的記憶體相同，整個模型所需的記憶體下限也會變成 10 GB。之所以稱為下限，是因為還要額外容納計算緩衝區與作業系統。模型載入後，請從 ollama ps 的 SIZE 欄讀取實際數值。

以服務方式執行 Ollama 時，視窗是在伺服器端設定，而不是依個別請求設定：

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

若使用 systemd 安裝，請改用 drop-in 設定：

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

使用 sudo systemctl restart ollama 重新啟動，然後檢查 ollama ps 的 CONTEXT 欄，以確認執行中的模型實際載入的視窗大小。OLLAMA_KV_CACHE_TYPE 也會量化 cache 本身：f16 是預設值，q8_0 使用的記憶體約為 f16 的一半，而 q4_0 約為其四分之一。這是全域選項，因此該伺服器上的每個模型都會套用相同設定。對於視窗較長的小型主機，將 cache 減半所釋放的記憶體，會比其他任何單一變更都多。設定 num_ctx 及其成本會詳細說明視窗本身。

8、16 或 32 GB VPS 適合執行的模型

需要容納量化權重、KV cache、作業系統及其他執行中元件，並保留足夠餘裕。對小型 VPS 而言，保留 2 GB 餘裕較為穩妥。

8 GB。 4B 模型使用 q4_K_M 時為 2.6 GB，並可為較長的 context window 留出空間。8B 模型使用 q4_K_M 時，搭配預設的 4k window 可以執行，但剩餘空間很少。不要在此配置中規劃 8B 搭配 32k window，因為 10 GB 的最低需求已超過主機容量。

16 GB。 8B 使用 q4_K_M，搭配 16k 或 32k window 時有充足餘裕。14B 使用 q4_K_M 時，權重大小為 9.3 GB，搭配適中的 window 即可執行。8B 使用 q8_0 時為 8.9 GB，因此也能執行。使用自己的 prompts 比較這兩種配置，是釐清此問題最有效的方式。

32 GB。 14B 使用 q8_0（16 GB）以及 32B 使用 q4_K_M（20 GB）都能載入。32B build 搭配較大的 window 時會逼近容量上限，因此請監看 ollama ps，不要直接假設它一定能穩定執行。

哪些能力會先受到量化影響

量化誤差不會平均影響模型的所有能力。流暢度通常最後才會受影響，這正是問題容易被忽略的原因：量化不佳的模型仍能寫出通順的句子。最先下降的是精確度。包括準確回憶版本號、API 簽章或日期的能力，以及長串推理能力；在第 2 步出現的小錯誤，可能會在第 8 步導致錯誤答案。嚴格的輸出格式也會受影響，因為少一個括號就可能導致工具呼叫失敗。

最後一項是最實用的測試。模型必須回傳由程式解析的 JSON 時，量化造成的損害會以解析錯誤呈現，而不是模糊地表現為文字品質變差，因此你能在同一天發現問題。coding agent 是這項測試中最嚴格的版本，因為它會連續驅動模型執行工具呼叫。因此，將 agent 指向你的 Ollama 伺服器，通常不到一個下午就能暴露過度激進的量化設定。

低於 4 bits 後，品質損失會明顯加劇。q3 與 2 bit 類型是為了將大型模型壓縮到小型硬體上的使用者而存在；當替代方案是完全無法執行模型時，它們確實是可行選項。但它們不適合作為預設選擇。q4_K_M 與 q8_0 之間的差距小到僅憑已發表的 perplexity 表格，無法判斷哪個更適合你的工作負載，因此不要用這種方式下結論。請使用你自己的 30 個提示，分別執行兩者並閱讀輸出。

q8_0 或 fp16 何時值得使用 RAM

只有在記憶體確實有餘裕，且任務無法容忍小錯誤時，才使用 q8_0：例如結構化擷取、工具呼叫，以及必須通過編譯的程式碼。這是在購買保險，而不是換取一個明顯更聰明的模型。

使用 fp16 只有兩個理由。第一，你要自行量化模型，因此需要原始檔案。第二，你要測量基準，藉此確認 4 bit 版本犧牲了多少效能。使用 fp16 提供服務所需的記憶體是 q4_K_M 的 3 倍，但兩者的差異多數人盲測時無法分辨；在僅使用 CPU 的主機上，token 速率也會降至三分之一。

更實用的原則是，在記憶體預算固定時，較大的 q4_K_M 模型通常勝過較小的 q8_0 模型。9.3 GB 的 14B 權重，對比 8.9 GB 的 8B 權重，所需 RAM（random access memory）幾乎相同，而較大的模型掌握的資訊更多。請使用自己的提示詞測試，不要直接相信這項結論。

僅使用 CPU 進行推論會受記憶體頻寬限制

大多數 VPS 方案沒有 GPU，因此模型會在主機 CPU 上使用系統記憶體執行。生成速度會受記憶體頻寬限制，而不是算術運算能力限制，因為每生成 1 個 token，就必須讀取所有權重 1 次。因此，速度上限與你購買的 CPU 核心數無關。

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

雙通道 DDR4-3200 主機的理論值大約是 50 GB/s。你的可用頻寬會更低，因為 VPS 會與同一台機器上的其他租戶共用該記憶體匯流排。因此，應將這些數字視為實際無法達到的上限。真正有用的是其趨勢：在 CPU 上，每個權重的位元數減半，token 速率大致會加倍。對於沒有 GPU 的主機而言，量化是可用的最大速度調整手段。

提示詞處理的行為不同。讀取長提示詞主要受計算能力限制，而不是記憶體頻寬限制，因此增加 CPU 核心有助於提示詞處理，但對生成速度幾乎沒有幫助。主機能快速讀取 4k 提示詞，之後卻生成緩慢，這是正常情況。

不要直接相信任何算術結果。使用相同提示詞測量每種量化設定下自有主機的每秒 token 數：測量自有主機的每秒 token 數，並以你的實測數據為準。

自行量化模型

Ollama 可以從 fp16 或 fp32 來源建立量化模型。當您完成微調但沒有可用的 library tag 時，這項功能很重要。將 Modelfile 指向未量化的權重：

FROM /path/to/my/model/f16

接著建立模型並確認：

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize 接受 q8_0、q4_K_S 和 q4_K_M。這裡沒有 q6_K 或 q5_K_M 選項，因此您必須使用 llama.cpp 自有的工具進行量化，再匯入完成的 GGUF 檔案。ollama show 中的 quantization 行可用來確認建置結果符合要求。

發生問題時會看到的現象

預期使用 GPU，但所有工作都在 CPU 上執行。 查看 PROCESSOR 欄：

ollama ps

輸出會顯示 100% GPU、100% CPU，或像 48%/52% CPU/GPU 這樣的分割配置。分割表示權重加上 KV cache 無法容納於 VRAM（video RAM，顯示卡上的記憶體），因此模型的一部分被放入系統記憶體。速度會降至接近僅使用 CPU 的速率，因為每個 token 都必須等待較慢的部分。請縮小 context window、將 cache 量化，或改用較小的 build。增加核心數不會改善問題。

模型在載入期間被終止。 檢查 kernel 和服務日誌：

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

包含 Out of memory: Killed process 的行表示權重、KV cache 與緩衝區的總量超過主機的記憶體容量。在未設定 swap 的 VPS 上，該行出現前，整台機器可能會停頓數秒。

回答品質變差，但你沒有修改任何設定。 同一模型的兩個 build 可能在 ollama ls 中以不同 tag 並存，而提取未加後綴名稱的 script 會跟隨 library 目前指向的版本。請針對 client 要求的確切 tag 執行 ollama show，並讀取 quantization 行，不要只相信設定檔中的名稱。

FAQ

我應該下載哪一種 Ollama 量化版本？

從 q4_K_M 開始。這是 Ollama library 為大多數模型提供的預設 tag，因此 ollama pull qwen3:8b 和 ollama pull qwen3:8b-q4_K_M 會下載同一個檔案。只有在記憶體充足，且工作對小幅錯誤非常敏感時，才改用 q8_0，例如工具呼叫或結構化 JSON 輸出。記憶體預算固定時，q4_K_M 的較大模型通常優於 q8_0 的較小模型，因此在增加 RAM 用於提高精度前，先測試這種搭配。

q4_K_M 真的代表每個權重使用 4 bits 嗎？

不是。在 Llama 3.1 8B 上測得的數值是每個權重 4.89 bits，因為每個權重區塊都會儲存自己的 scale，而最敏感的 tensor 會提升至較寬的型別。基於相同原因，Q8_0 測得的數值是 8.5 bits，而不是 8 bits。估算時請使用測得的數值：參數數量乘以每個權重的 bits，再除以 8，即可得到檔案大小的 bytes。

僅使用 CPU 的 VPS 執行 8B 模型需要多少 RAM？

請將權重、KV cache 和預留空間一併計入。Qwen3 8B 使用 q4_K_M 時，權重大小為 5.2 GB。在預設的 4096 token 視窗下，cache 會增加 0.6 GB，因此在計入運算 buffer 和作業系統之前，最低需求接近 5.8 GB。在 32k 視窗下，cache 本身就需要 4.83 GB。短視窗規劃 8 GB；若需要長視窗，則規劃 16 GB。

為什麼主機有 GPU，但我的模型仍使用 100% CPU？

執行 ollama ps，查看 PROCESSOR 欄。100% CPU 或類似 48%/52% CPU/GPU 的分割配置，表示權重加上 KV cache 無法容納於 VRAM，因此 Ollama 將部分或全部模型放入系統記憶體。最常見的原因是 context window 大於 GPU 可容納的大小，因為模型載入時會為整個視窗配置 cache。使用 OLLAMA_CONTEXT_LENGTH 降低視窗大小，將 OLLAMA_KV_CACHE_TYPE=q8_0 設為讓 cache 減半，或下載較小的量化版本。