Perbezaan Kuantisasi Ollama: Q4, Q8 dan FP16

Perubahan kuantisasi Ollama

Kuantisasi Ollama menyimpan setiap pemberat dalam model pada bit yang lebih rendah daripada fail asal semasa latihan. Tag yang berakhir dengan q4_K_M mengekalkan kira-kira empat bit bagi setiap pemberat manakala fp16 mengekalkan enam belas bit, jadi saiz muat turun adalah kira-kira satu perempat daripada saiz asal dan mesin membaca satu perempat jumlah bait untuk menghasilkan setiap token. Pemberat dibundarkan kepada grid yang lebih kasar, bukannya dibuang, dan pada empat bit kebanyakan model memberikan jawapan yang hampir sama dengan ketepatan penuh.

Itulah pertukaran keseluruhannya: penggunaan memori yang jauh lebih kecil dan lebih banyak token sesaat, dengan sedikit kehilangan ketepatan. Berikut adalah cara untuk meramalkan kedua-dua kesan tersebut bagi model tertentu pada mesin tertentu, sebelum anda menghabiskan masa dua puluh minit memuat turun fail yang tidak muat.

Jika Ollama belum berjalan, mulakan dengan memasang Ollama pada VPS. Halaman ini mengandaikan ollama ls sudah berfungsi.

Cara membaca tag kuantisasi Ollama seperti q4_K_M

Model tempatan diedarkan sebagai fail GGUF, iaitu format yang digunakan oleh llama.cpp untuk menyimpan pemberat (weights) pada cakera. Ollama dibina berasaskan llama.cpp, jadi tag Ollama mengekalkan nama kuantisasi llama.cpp tanpa perubahan.

Nombor tersebut ialah lebar sasaran. q4 bermaksud kebanyakan tensor pemberat dipadatkan kepada empat bit setiap satu. q8 bermaksud lapan bit. fp16 tidak dikuantisasi langsung: ia adalah model dalam format titik apung enam belas bit, iaitu ketepatan yang digunakan semasa kebanyakan model diterbitkan.

K menandakan K-quant. Pemberat dikumpulkan ke dalam blok kecil, dan setiap blok menyimpan skalanya sendiri di sebelah nilai yang dipadatkan. Blok yang semua pemberatnya berada berhampiran 0.01 mendapat skala yang halus. Blok yang mengandungi satu nilai luar (outlier) yang besar mendapat skala yang kasar. Skala per-blok inilah yang memastikan fail empat bit boleh digunakan, dan ia juga merupakan sebab fail empat bit tidak pernah tepat empat bit bagi setiap pemberat.

Huruf terakhir ialah campuran (mixture). S, M dan L menentukan berapa banyak tensor yang dinaikkan melebihi lebar sasaran. Dalam q4_K_M, tensor yang paling terjejas apabila dibundarkan akan disimpan dengan lebih lebar, manakala sebahagian besarnya kekal pada empat bit. Itulah sebabnya q4_K_M menghasilkan output yang lebih baik daripada q4_0 yang lebih lama pada saiz fail yang hampir sama.

Tanya Ollama apa yang ada pada cakera anda daripada meneka berdasarkan nama yang anda taip:

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

ollama show mencetak architecture, parameters, quantization, context length dan embedding length. Baris quantization ialah kebenaran mutlak (ground truth) bagi model yang anda muat turun berbulan-bulan dahulu dan tidak lagi ingat pilihan yang dibuat.

Bit per pemberat adalah punca saiz fail

Setiap anggaran saiz bermula daripada satu nombor: berapa banyak bit yang digunakan oleh format bagi setiap pemberat, yang dipuratakan merentasi keseluruhan fail. llama.cpp menerbitkan angka ukuran untuk Llama 3.1 8B dalam dokumentasi quantize miliknya, dan angka tersebut boleh diguna pakai untuk mana-mana model padat dengan bentuk yang serupa.

[
  {
    "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
  }
]

Perkara yang mengejutkan dalam jadual tersebut ialah lajur kedua. Q4_K_M bukan empat bit bagi setiap pemberat. Ia mengukur 4.89 bit, kerana skala blok dan tensor yang dipromosikan kedua-duanya memakan ruang sebenar. Q8_0 mengukur 8.5 bit dan bukannya lapan, atas sebab yang sama. Gunakan nombor yang diukur tersebut dan pengiraan aritmetik akan menghasilkan nilai dalam lingkungan beberapa peratus daripada saiz fail sebenar:

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

Itu adalah fail Q4_K_M bersaiz 4.58 GiB, yang diperoleh daripada dua nombor. Ia juga, secara kasarnya, merupakan memori yang diduduki oleh pemberat sebaik sahaja dimuatkan. Ollama tidak menyahpadat apa-apa semasa pemuatan: pemberat yang telah dikuantisasi kekal dalam memori dalam bentuk padat yang sama dan setiap blok ditukar semasa ia digunakan.

Apa yang sebenarnya disediakan oleh Ollama untuk setiap saiz model

Pustaka ini menerbitkan tag q4_K_M, q8_0 dan fp16 bagi kebanyakan keluarga model. Ini adalah saiz Qwen3 setakat Ogos 2026, yang dibaca daripada senarai tag pada halaman model.

[
  {
    "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
  }
]

Tag lalai adalah penting di sini. ollama pull qwen3:8b memuat turun 5.2 GB yang sama persis seperti ollama pull qwen3:8b-q4_K_M, kerana tag tanpa akhiran sememangnya binaan q4_K_M. Q4_K_M bukanlah satu kompromi yang ditawarkan secara terpaksa oleh pustaka tersebut. Ia adalah lalai yang dipilih oleh pihak hulu (upstream), jadi memadankannya adalah langkah pertama yang wajar bagi mana-mana model yang belum anda uji sendiri. Penaakulan yang sama mendorong pemilihan tag dalam menjalankan Qwen 3 pada VPS.

Nisbah ini kekal merentas setiap baris. Beralih daripada q4_K_M kepada q8_0 menelan kos kira-kira tujuh puluh peratus lebih tinggi dan bukannya tepat dua kali ganda, kerana tensor embedding dan output tidak berskala dengan cara yang sama seperti bahagian lain. fp16 adalah kira-kira tiga kali ganda daripada q4_K_M. Model 32B pada q4_K_M mempunyai berat 20 GB, yang sudah melebihi kapasiti yang boleh ditampung oleh mesin 16 GB dengan sebarang tetingkap konteks sekalipun. Untuk pandangan yang lebih luas tentang model yang sesuai dengan mesin tertentu, lihat model yang boleh anda hos sendiri.

Mengapa KV cache merupakan kos kedua yang bergantung pada konteks

Weight adalah kos tetap. KV cache (cache kunci dan nilai) pula adalah kos berubah. Setiap token dalam tetingkap konteks menyimpan vektor kunci dan nilainya untuk setiap lapisan, jadi cache berkembang secara linear mengikut tetingkap yang anda benarkan. Ia diperuntukkan untuk keseluruhan tetingkap apabila model dimuatkan, bukan semasa perbualan berlangsung; itulah sebabnya tetingkap yang panjang memakan memori walaupun pada gesaan satu perkataan.

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

Nombor model tersebut datang daripada konfigurasi model itu sendiri: 36 lapisan, 8 kepala kunci/nilai, dan dimensi kepala sebanyak 128. ollama show memberikan anda seni bina dan jumlah parameter, manakala config.json model tersebut di Hugging Face memberikan anda maklumat selebihnya. Darabkan kos per token dengan saiz tetingkap dan cache tersebut bukan lagi sekadar ralat pembundaran.

[
  {
    "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
  }
]

Pada tetingkap lalai Ollama sebanyak 4096 token, cache menambah 0.6 GB di atas weight. Tingkatkan tetingkap kepada 32k dan cache sahaja mencecah 4.83 GB, iaitu hampir sama banyak dengan memori weight yang telah dikuantisasi, dan lantai (floor) untuk keseluruhan model menjadi 10 GB. Ia dipanggil lantai kerana penimbal pengiraan (compute buffers) dan sistem pengendalian berada di atasnya. Baca angka sebenar daripada lajur SIZE dalam ollama ps selepas model dimuatkan.

Tetingkap ditetapkan pada pelayan, bukan bagi setiap permintaan, apabila anda menjalankan Ollama sebagai servis:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Untuk pemasangan systemd, letakkannya dalam fail drop-in sebaliknya:

sudo systemctl edit ollama

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

Mulakan semula dengan sudo systemctl restart ollama, kemudian semak lajur CONTEXT dalam ollama ps untuk mengesahkan tetingkap yang digunakan semasa model yang sedang berjalan dimuatkan. OLLAMA_KV_CACHE_TYPE mengkuantisasi cache itu sendiri: f16 adalah lalai, q8_0 menggunakan kira-kira separuh memori daripada f16, dan q4_0 kira-kira satu perempat. Ia adalah pilihan global, jadi setiap model pada pelayan tersebut mendapat layanan yang sama. Pada mesin kecil dengan tetingkap yang panjang, mengurangkan cache kepada separuh membebaskan lebih banyak memori berbanding perubahan tunggal yang lain. Menetapkan num_ctx dan kosnya membincangkan tetingkap itu sendiri secara terperinci.

Apa yang muat pada VPS 8, 16 atau 32 GB

Berat model, ditambah KV cache, serta ruang kepala untuk sistem pengendalian dan apa-apa proses lain yang berjalan. Ruang kepala sebanyak 2 GB adalah selesa pada VPS kecil.

8 GB. Model 4B pada q4_K_M bersaiz 2.6 GB dan meninggalkan ruang untuk tetingkap konteks yang panjang. Model 8B pada q4_K_M muat dengan tetingkap lalai 4k dan mempunyai ruang lebihan yang sangat sedikit. Jangan rancang untuk menggunakan 8B dengan tetingkap 32k di sini, kerana had minimum 10 GB sudah melebihi kapasiti pelayan.

16 GB. 8B pada q4_K_M dengan tetingkap 16k atau 32k adalah selesa. 14B pada q4_K_M mempunyai berat 9.3 GB dan muat dengan tetingkap yang sederhana. 8B pada q8_0 adalah 8.9 GB, jadi ia juga muat. Membandingkan kedua-dua model ini menggunakan prompt anda sendiri adalah cara paling berfaedah untuk menghabiskan masa dalam topik ini.

32 GB. 14B pada q8_0 (16 GB) dan 32B pada q4_K_M (20 GB) kedua-duanya boleh dimuatkan. Binaan 32B dengan tetingkap besar akan menghampiri had maksimum, jadi pantau ollama ps dan jangan sekadar membuat andaian.

Apakah kuantisasi yang merosot terlebih dahulu

Ralat kuantisasi tidak tersebar secara sekata ke atas apa yang dilakukan oleh model. Kefasihan bahasa bertahan paling lama, itulah sebabnya kerosakan ini mudah terlepas pandang: model yang dikuantisasi dengan teruk masih menulis ayat yang kemas. Ketepatan (precision) merosot terlebih dahulu. Ingatan tepat terhadap nombor versi, signatur API atau tarikh. Rangkaian penaakulan yang panjang, di mana ralat kecil pada langkah kedua menjadi jawapan yang salah pada langkah kelapan. Format output yang ketat, di mana satu kurungan yang salah menyebabkan panggilan alat (tool call) gagal.

Perkara terakhir itu merupakan ujian praktikal. Apabila model perlu mengembalikan JSON yang dihuraikan oleh kod anda, kerosakan kuantisasi muncul sebagai ralat penghuraian (parse error) dan bukannya sebagai prosa yang sedikit merosot, jadi anda akan melihatnya pada hari yang sama. Ejen pengekodan adalah versi paling keras bagi ujian tersebut, kerana ia mendorong model melalui panggilan alat demi panggilan alat, jadi menghalakan ejen ke pelayan Ollama anda akan mendedahkan kuantisasi yang terlalu agresif dalam masa satu petang.

Di bawah empat bit, kehilangan kualiti menjadi sangat ketara. Jenis q3 dan dua bit wujud untuk mereka yang memuatkan model besar ke dalam perkakasan kecil, dan ia merupakan pilihan sebenar apabila alternatifnya adalah tidak menjalankan model tersebut langsung. Ia adalah tetapan lalai yang lemah. Antara q4_K_M dan q8_0, jurangnya cukup kecil sehingga jadual perplexity yang diterbitkan tidak akan dapat menentukan kesesuaian untuk beban kerja anda, jadi jangan cuba menentukannya dengan cara itu. Jalankan kedua-duanya terhadap tiga puluh prompt anda sendiri dan baca outputnya.

Bilakah q8_0 atau fp16 berbaloi dengan RAM

Tarik q8_0 apabila memori benar-benar berlebihan dan tugasan tersebut tidak membenarkan ralat kecil: pengekstrakan berstruktur, panggilan alat, atau kod yang perlu dikompilasi. Anda membeli insurans di situ, bukan model yang jauh lebih bijak.

Tarik fp16 atas dua sebab sahaja. Sama ada anda melakukan kuantisasi pada model itu sendiri dan memerlukan fail sumber, atau anda sedang mengukur garis dasar supaya anda tahu berapa banyak prestasi yang hilang pada binaan empat bit anda. Menjalankan model daripada fp16 menggunakan memori tiga kali ganda berbanding q4_K_M untuk perbezaan yang kebanyakan orang tidak dapat kesan melalui ujian buta, dan pada mesin yang hanya menggunakan CPU, ia juga mengurangkan kadar token anda kepada satu pertiga.

Peraturan yang lebih kukuh, pada bajet memori yang tetap: model yang lebih besar pada q4_K_M biasanya mengatasi model yang lebih kecil pada q8_0. 9.3 GB pemberat 14B berbanding 8.9 GB pemberat 8B menggunakan jumlah RAM (random access memory) yang hampir sama dan model yang lebih besar mempunyai pengetahuan yang lebih luas. Uji perkara ini dengan prompt anda sendiri dan jangan hanya mempercayainya bulat-bulat.

Inference CPU sahaja dihadkan oleh lebar jalur memori

Kebanyakan pelan VPS tidak mempunyai GPU, jadi model berjalan dalam memori sistem pada CPU hos. Penjanaan kemudiannya dihadkan oleh lebar jalur memori, bukan oleh aritmetik, kerana penghasilan satu token memerlukan pembacaan setiap pemberat (weight) sekali. Ini mewujudkan had siling yang tidak berkaitan dengan jumlah teras (core) yang anda beli.

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

50 GB/s secara kasarnya merupakan angka teori bagi hos dual channel DDR4-3200. Bahagian anda adalah lebih kecil, kerana VPS berkongsi bas tersebut dengan setiap penyewa lain pada mesin itu, jadi anggap angka tersebut sebagai had siling yang tidak akan dicapai oleh sesiapa pun. Bentuk graf adalah bahagian yang berguna: pada CPU, mengurangkan bit bagi setiap pemberat kepada separuh akan menggandakan kadar token secara kasar. Kuantisasi (quantization) adalah tuil kelajuan terbesar yang tersedia pada kotak tanpa GPU.

Pemprosesan prompt berkelakuan berbeza. Membaca prompt yang panjang adalah terikat dengan pengiraan (compute bound) dan bukannya terikat dengan lebar jalur, jadi teras tambahan membantu dalam aspek tersebut walaupun hampir tidak memberi kesan kepada kelajuan penjanaan. Kotak yang memproses prompt 4k dengan pantas dan kemudian menjana dengan perlahan adalah berkelakuan seperti biasa.

Jangan terima sebarang aritmetik secara membuta tuli. Ukur token sesaat pada kotak anda sendiri dengan prompt yang sama pada setiap kuantisasi, dan biarkan angka anda mengatasi angka-angka ini.

Melakukan kuantisasi model sendiri

Ollama boleh membina model terkuantisasi daripada sumber fp16 atau fp32. Ini penting apabila anda telah melakukan fine-tuning pada sesuatu model dan tiada tag pustaka yang tersedia. Halakan Modelfile kepada weight yang belum terkuantisasi:

FROM /path/to/my/model/f16

Kemudian bina dan sahkan:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize menerima q8_0, q4_K_S dan q4_K_M. Tiada pilihan q6_K atau q5_K_M di sini, jadi untuk format tersebut, anda perlu melakukan kuantisasi menggunakan alat daripada llama.cpp sendiri dan mengimport fail GGUF yang telah siap. Baris quantization daripada ollama show ialah cara anda mengesahkan bahawa binaan tersebut telah melakukan apa yang anda minta.

Apa yang anda akan lihat apabila berlaku kegagalan

Segala proses berjalan pada CPU sedangkan anda menjangkakan GPU. Periksa lajur PROCESSOR:

ollama ps

Ia memaparkan 100% GPU, 100% CPU, atau pembahagian seperti 48%/52% CPU/GPU. Pembahagian bermaksud berat model (weights) berserta KV cache tidak dimuatkan sepenuhnya ke dalam VRAM (video RAM, iaitu memori pada kad grafik), maka sebahagian daripada model diletakkan di dalam memori sistem. Kelajuan kemudiannya jatuh hampir kepada kadar CPU sahaja, kerana setiap token perlu menunggu bahagian yang perlahan. Kurangkan tetingkap konteks (context window), lakukan kuantisasi pada cache, atau muat turun binaan (build) yang lebih kecil. Menambah teras (cores) tidak akan membantu.

Model dimatikan (killed) semasa proses pemuatan. Semak kernel dan log servis:

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

Baris yang mengandungi Out of memory: Killed process bermaksud jumlah berat model, KV cache, dan penimbal (buffers) telah melebihi kapasiti memori pada pelayan. Pada VPS yang tidak dikonfigurasikan dengan swap, keseluruhan mesin boleh terhenti selama beberapa saat sebelum baris tersebut muncul.

Jawapan menjadi semakin teruk sedangkan anda tidak mengubah apa-apa. Dua binaan bagi model yang sama boleh wujud bersebelahan dalam ollama ls di bawah tag yang berbeza, dan skrip yang menarik nama tanpa akhiran akan mengikut mana-mana versi yang ditunjuk oleh pustaka tersebut pada masa ini. Jalankan ollama show terhadap tag tepat yang diminta oleh klien anda dan baca baris quantization, daripada mempercayai nama dalam fail konfigurasi anda.

FAQ

Kuantisasi Ollama yang manakah perlu saya tarik?

Mulakan dengan q4_K_M. Ini ialah tag lalai yang dibekalkan oleh pustaka Ollama untuk kebanyakan model, jadi ollama pull qwen3:8b dan ollama pull qwen3:8b-q4_K_M akan mengambil fail yang sama. Beralih kepada q8_0 hanya apabila memori mencukupi dan tugasan tersebut sensitif terhadap ralat kecil, seperti panggilan alatan (tool calling) atau output JSON berstruktur. Apabila bajet memori adalah tetap, model yang lebih besar pada q4_K_M biasanya mengatasi model yang lebih kecil pada q8_0, jadi uji gandingan tersebut sebelum memperuntukkan RAM untuk ketepatan yang lebih tinggi.

Adakah q4_K_M benar-benar bermaksud empat bit bagi setiap pemberat (weight)?

Tidak. Berdasarkan ukuran pada Llama 3.1 8B, ia adalah 4.89 bit bagi setiap pemberat, kerana setiap blok pemberat menyimpan skala tersendiri dan tensor yang paling sensitif dinaik taraf kepada jenis yang lebih luas. Q8_0 mengukur 8.5 bit dan bukannya lapan atas sebab yang sama. Gunakan angka yang diukur semasa membuat anggaran: jumlah parameter didarab dengan bit bagi setiap pemberat, dibahagikan dengan lapan, akan memberikan saiz fail dalam bait.

Berapakah RAM yang diperlukan oleh model 8B pada VPS yang hanya menggunakan CPU?

Tambahkan pemberat, cache KV, dan ruang simpanan (headroom). Qwen3 8B pada q4_K_M memerlukan 5.2 GB untuk pemberat. Pada tetingkap lalai 4096 token, cache menambah 0.6 GB, menjadikan jumlah minimum hampir 5.8 GB sebelum mengambil kira penimbal pengiraan (compute buffers) dan sistem pengendalian. Pada tetingkap 32k, cache sahaja memerlukan 4.83 GB. Rancang untuk 8 GB bagi tetingkap pendek dan 16 GB jika anda memerlukan tetingkap yang panjang.

Mengapakah model saya berjalan pada 100% CPU sedangkan pelayan mempunyai GPU?

Jalankan ollama ps dan baca lajur PROCESSOR. 100% CPU, atau pembahagian seperti 48%/52% CPU/GPU, bermaksud pemberat serta cache KV tidak muat dalam VRAM, jadi Ollama meletakkan sebahagian atau keseluruhan model dalam memori sistem. Punca biasa ialah tetingkap konteks yang lebih besar daripada kapasiti kad, kerana cache diperuntukkan untuk keseluruhan tetingkap apabila model dimuatkan. Kecilkan tetingkap dengan OLLAMA_CONTEXT_LENGTH, tetapkan OLLAMA_KV_CACHE_TYPE=q8_0 untuk mengurangkan cache kepada separuh, atau tarik kuantisasi yang lebih kecil.