Ollama 量化怎麼選？Q4、Q8 與 fp16 比較

Ollama 量化的變化

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

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

如果 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。 權重會分組成小型區塊，每個區塊都會在封裝值旁儲存自己的 scale。若某個區塊的權重都接近 0.01，便會使用較細的 scale。若某個區塊包含一個很大的離群值，則會使用較粗的 scale。這些區塊層級的 scale 讓 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
  }
]

該表格令人意外之處在於第 2 欄。Q4_K_M 並不是每個權重 4 位元。它實際上使用 4.89 位元，因為區塊 scale 與提升精度的 tensor 都會實際佔用空間。基於相同原因，Q8_0 實際使用的是 8.5 位元，而不是 8 位元。使用實測數值計算，結果會與實際檔案大小相差不到幾個百分點：

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 檔案，只需使用 2 個數字即可還原。這也大致等於載入後權重所佔用的記憶體。Ollama 載入時不會解包；量化權重會以相同的封裝形式保留在記憶體中，使用時才會逐一轉換各個區塊。

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

對大多數模型系列而言，該程式庫會發布 q4_K_M、q8_0 與 fp16 標籤。部分較新的模型系列不符合這項模式，在程式庫中僅顯示為雲端專用標籤，無論選擇哪種大小都沒有可供下載的內容。當你 嘗試在 VPS 上執行 GLM 5.2 時，就會遇到這項限制。以下是截至 August 2026 的 Qwen3 大小，資料取自模型頁面的標籤清單。以下所有數值都是模型實際佔用的磁碟空間，不是 RAM 用量；其中兩到三個模型就可能填滿小型 VPS 的 root 磁碟區。因此，在開始收集標籤前，先了解 Ollama 儲存下載模型的位置。

[
  {
    "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%，而不是正好變成兩倍，因為 embedding 與輸出 tensor 的縮放方式和其餘部分不同。fp16 約是 q4_K_M 的 3 倍。32B 模型使用 q4_K_M 時，權重就有 20 GB；若還要保留任何 context window，16 GB 的主機已經無法容納。若要更全面了解不同主機能容納哪些模型，請參閱 可自行代管的模型。

為何 KV cache 是第二項、且取決於上下文的成本

權重是固定成本。KV cache（key and value cache）則是可變成本。上下文視窗中的每個 token，都會為每一層保留其 key 與 value 向量，因此 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 head，以及 128 的 head 維度。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 及其成本會詳細說明視窗本身。Cache 也會按照並行請求 slot 的數量配置，而不是每台伺服器只配置一次。因此，讓 Ollama 同時回答 2 個提示，會使你剛才估算的數值加倍；這也是選擇並行 slot 數量與佇列上限背後的計算方式。

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 下可以容納，但幾乎沒有餘裕。這裡不要規劃使用 32k window 的 8B，因為 10 GB 的最低需求已超過此 VPS 的容量。

16 GB。 8B 使用 q4_K_M 搭配 16k 或 32k window 時相當寬裕。14B 使用 q4_K_M 時，模型權重為 9.3 GB，搭配適中的 window 即可容納。8B 使用 q8_0 時為 8.9 GB，因此也能容納；針對自己的提示詞比較這兩者，是在這個主題上最值得投入的一小時。

32 GB。 14B 使用 q8_0（16 GB）以及 32B 使用 q4_K_M（20 GB）都能載入。搭配大型 window 的 32B 版本會逼近容量上限，因此請監控 ollama ps，不要直接假設一定能正常運作。

量化會先降低哪些能力

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

最後一項是實務上的測試。模型必須傳回由程式解析的 JSON 時，量化損害會表現為解析錯誤，而不是略差的文字，因此你能在同一天發現問題。coding agent 是最嚴格的測試，因為它會讓模型連續執行工具呼叫。因此，讓 agent 連線到你的 Ollama 伺服器，通常能在半天內暴露過度激進的量化設定。

低於 4 bits 後，效能損失會明顯增加。q3 和 2 bit 類型是為了將大型模型壓縮到小型硬體上的使用者而存在；如果替代方案是完全無法執行模型，這些類型確實值得考慮。但它們不適合作為預設選項。q4_K_M 與 q8_0 之間的差距小到僅憑公開的 perplexity 表格，無法判定哪個更適合你的工作負載，因此不要用這種方式下結論。請分別以你自己的 30 個 prompts 測試兩者，再閱讀輸出結果。

何時值得使用 q8_0 或 fp16 的記憶體

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

只有兩種情況值得選用 fp16。第一種是自行量化模型，且需要來源檔案。第二種是測量基準，以確認四位元版本犧牲了多少效能。使用 fp16 執行服務所需的記憶體是 q4_K_M 的三倍，但多數人盲測時無法分辨其中差異；在僅使用 CPU 的主機上，token 速率也會降至三分之一。

在記憶體預算固定時，更可靠的原則是：q4_K_M 的較大型模型通常勝過 q8_0 的較小型模型。14B 權重的 9.3 GB 與 8B 權重的 8.9 GB 幾乎使用相同的 RAM（random access memory），但較大型模型掌握的資訊更多。請使用自己的提示詞進行測試，不要直接相信這項判斷。

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

大多數 VPS 方案沒有 GPU，因此模型會在主機 CPU 的系統記憶體中執行。此時生成速度受記憶體頻寬限制，而不是受算術運算能力限制，因為生成每個 token 都需要讀取所有權重一次。這會形成與購買多少 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 的主機上，量化是可用的最大加速手段。實際剩餘的速率是否可接受，取決於模型；VPS 上的 Nemotron 3.5 Lightning 以特定的 build、tag 及 RAM 數值，完整計算了其中一種配置。等待時間的另一半取決於模型決定輸出的長度，因為在每秒 10 個 token 的速度下，600 個 token 的回答需要整整 1 分鐘，因此使用 num_predict 限制回答長度，通常比再降低一級精度更能減少等待時間。

Prompt 處理的情況不同。讀取長 prompt 主要受運算能力限制，而不是受頻寬限制，因此增加 CPU 核心可提升這部分的速度，但幾乎不會提高生成速度。主機能快速讀入 4k prompt，接著緩慢生成內容，這是正常現象。

不要直接相信任何計算結果。請以相同的 prompt，在每種量化設定下於自己的主機上測量每秒 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 檔案。這種匯入方式本身有一項陷阱：chat template 不相符時，模型會回覆無意義的內容。將 GGUF 檔案匯入 Ollama 會逐步說明這個問題。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。增加 CPU 核心沒有幫助。

模型在載入時遭到終止。 請檢查 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，因此在計入計算緩衝區與作業系統前，最低約需 5.8 GB。使用 32k 視窗時，光是 cache 就需要 4.83 GB。短視窗請規劃 8 GB；若需要長視窗，請規劃 16 GB。

為什麼主機有 GPU，但模型執行時 CPU 使用率仍達到 100%？

執行 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 減半，或下載較小的量化版本。