Kuantisasi Ollama: Pilih Q4, Q8, atau fp16

Perubahan kuantisasi Ollama

Kuantisasi Ollama menyimpan setiap bobot dalam model dengan jumlah bit yang lebih sedikit daripada file tempat model tersebut dilatih. Tag yang diakhiri q4_K_M menggunakan sekitar empat bit per bobot, sedangkan fp16 menggunakan enam belas bit. Dengan demikian, ukuran unduhan kira-kira menjadi seperempatnya, dan mesin membaca seperempat jumlah byte untuk menghasilkan setiap token. Bobot dibulatkan ke grid yang lebih kasar, bukan dibuang. Pada empat bit, sebagian besar model memberikan jawaban yang mendekati hasil pada presisi penuh.

Itulah kompromi keseluruhannya: jejak memori jauh lebih kecil dan jumlah token per detik lebih banyak, dengan konsekuensi sedikit penurunan akurasi. Bagian berikut menjelaskan cara memperkirakan kedua dampak tersebut untuk model tertentu pada mesin tertentu, sebelum Anda menghabiskan dua puluh menit untuk mengunduh file yang ternyata tidak muat.

Jika Ollama belum berjalan, mulai dengan menginstal Ollama pada VPS. Halaman ini mengasumsikan ollama ls sudah berfungsi.

Cara membaca tag kuantisasi Ollama seperti q4_K_M

Model lokal dirilis sebagai file GGUF, yaitu format yang digunakan llama.cpp untuk menyimpan bobot di disk. Ollama dibangun di atas llama.cpp, sehingga tag Ollama menggunakan nama kuantisasi llama.cpp tanpa perubahan.

Angka menunjukkan lebar target. q4 berarti sebagian besar tensor bobot dikemas dengan empat bit per bobot. q8 berarti delapan bit. fp16 tidak dik
uantisasi sama sekali: ini adalah model dengan floating point 16 bit, yaitu presisi yang digunakan saat sebagian besar model dirilis.

K menandai K-quant. Bobot dikelompokkan ke dalam blok-blok kecil, dan setiap blok menyimpan skala sendiri di samping nilai yang dikemas. Blok yang seluruh bobotnya berada di sekitar 0.01 mendapatkan skala yang lebih halus. Blok yang berisi satu outlier besar mendapatkan skala yang lebih kasar. Skala per blok tersebut membuat file empat bit tetap dapat digunakan. Skala ini juga menjadi alasan file empat bit tidak pernah benar-benar berukuran tepat empat bit per bobot.

Huruf terakhir menunjukkan campurannya. S, M dan L menentukan jumlah tensor yang dinaikkan di atas lebar target. Dalam q4_K_M, tensor yang paling terdampak oleh pembulatan disimpan dengan lebar yang lebih besar, sementara sebagian besar tensor tetap menggunakan empat bit. Karena itu, q4_K_M menghasilkan output yang lebih baik daripada q4_0 yang lebih lama dengan ukuran file yang hampir sama.

Tanyakan kepada Ollama apa yang tersimpan di disk, bukan menebak dari nama yang Anda ketik:

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 adalah sumber kebenaran untuk model yang Anda tarik beberapa bulan lalu dan tidak lagi Anda ingat pilih.

Bit per bobot menentukan ukuran file

Setiap estimasi ukuran dimulai dari satu angka: jumlah bit yang digunakan format per bobot, yang dirata-ratakan untuk seluruh file. llama.cpp menerbitkan angka hasil pengukuran untuk Llama 3.1 8B dalam dokumentasi quantize-nya, dan angka tersebut cukup berlaku untuk model dense dengan bentuk 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
  }
]

Hal yang mengejutkan pada tabel tersebut adalah kolom kedua. Q4_K_M bukan empat bit per bobot. Nilainya 4.89 bit, karena block scale dan tensor yang dipromosikan juga menggunakan ruang penyimpanan. Q8_0 bernilai 8.5 bit, bukan delapan, karena alasan yang sama. Gunakan angka hasil pengukuran agar hasil perhitungan mendekati ukuran file sebenarnya, dengan selisih beberapa persen:

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

Itulah file Q4_K_M berukuran 4.58 GiB, yang diperoleh dari dua angka. Angka tersebut juga cukup mendekati memori yang ditempati bobot setelah dimuat. Ollama tidak membongkar bobot saat dimuat. Bobot terkuantisasi tetap berada di memori dalam bentuk terpaket yang sama, dan setiap blok dikonversi saat digunakan.

Ukuran model yang benar-benar disediakan Ollama

Pustaka tersebut menyediakan tag q4_K_M, q8_0, dan fp16 untuk sebagian besar keluarga model. Berikut ukuran Qwen3 per Agustus 2026, berdasarkan daftar 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 default penting dalam konteks ini. ollama pull qwen3:8b mengunduh tepat 5.2 GB, sama seperti ollama pull qwen3:8b-q4_K_M, karena tag tanpa sufiks tersebut adalah build q4_K_M. Q4_K_M bukan kompromi yang ditawarkan pustaka dengan enggan. Format ini merupakan pilihan upstream sebagai default. Karena itu, mencocokkannya adalah langkah awal yang masuk akal untuk model apa pun yang belum Anda uji sendiri. Alasan yang sama mendasari pilihan tag dalam menjalankan Qwen 3 pada VPS.

Rasio tersebut berlaku pada setiap baris. Peralihan dari q4_K_M ke q8_0 membutuhkan sekitar tujuh puluh persen lebih banyak, bukan tepat dua kali lipat, karena tensor embedding dan output tidak bertambah dengan skala yang sama seperti bagian lainnya. fp16 berukuran kira-kira tiga kali q4_K_M. Model 32B pada q4_K_M memiliki bobot sebesar 20 GB. Ukuran ini sudah melampaui kapasitas server 16 GB jika masih harus menyediakan context window. Untuk gambaran yang lebih luas tentang model yang sesuai untuk setiap mesin, lihat model yang dapat Anda host sendiri.

Mengapa KV cache menjadi biaya kedua yang bergantung pada konteks

Bobot model adalah biaya tetap. KV cache (key dan value cache) adalah biaya variabel. Setiap token dalam context window menyimpan vektor key dan value untuk setiap layer, sehingga cache bertambah secara linear sesuai ukuran window yang Anda izinkan. Cache dialokasikan untuk seluruh window saat model dimuat, bukan saat percakapan bertambah panjang. Karena itu, window yang panjang tetap menggunakan memori meskipun prompt hanya terdiri dari satu kata.

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

Angka-angka model tersebut berasal dari konfigurasi model itu sendiri: 36 layer, 8 key/value head, dan dimensi head sebesar 128. ollama show menyediakan informasi tentang arsitektur dan jumlah parameter, sedangkan config.json milik model di Hugging Face menyediakan informasi lainnya. Kalikan biaya per token dengan ukuran window, dan cache tidak lagi dapat dianggap sebagai pembulatan kecil.

[
  {
    "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 window default Ollama sebesar 4096 token, cache menambahkan 0.6 GB di atas bobot model. Jika window dinaikkan menjadi 32k, cache saja mencapai 4.83 GB. Jumlah ini hampir setara dengan memori yang digunakan bobot terkuantisasi, sehingga kebutuhan minimum untuk seluruh model menjadi 10 GB. Disebut kebutuhan minimum karena buffer komputasi dan sistem operasi juga menggunakan memori. Baca angka sebenarnya dari kolom SIZE pada ollama ps setelah model dimuat.

Window ditetapkan pada server, bukan per request, saat Anda menjalankan Ollama sebagai service:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Untuk instalasi systemd, masukkan pengaturan tersebut ke dalam drop-in:

sudo systemctl edit ollama

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

Mulai ulang dengan sudo systemctl restart ollama, lalu periksa kolom CONTEXT pada ollama ps untuk memastikan window yang benar-benar digunakan saat model yang berjalan dimuat. OLLAMA_KV_CACHE_TYPE melakukan kuantisasi pada cache itu sendiri: f16 adalah nilai default, q8_0 menggunakan sekitar setengah memori yang digunakan f16, dan q4_0 menggunakan sekitar seperempatnya. Ini adalah opsi global, sehingga setiap model pada server tersebut mendapatkan perlakuan yang sama. Pada mesin dengan sumber daya terbatas dan window yang panjang, mengurangi ukuran cache hingga setengahnya membebaskan lebih banyak memori daripada perubahan tunggal lainnya. Mengatur num_ctx dan biayanya membahas window itu sendiri secara mendetail.

Yang dapat dijalankan pada VPS 8, 16, atau 32 GB

Alokasikan anggaran untuk bobot model dan KV cache, lalu sisakan headroom untuk sistem operasi serta proses lain yang berjalan. Headroom sebesar 2 GB cukup longgar untuk VPS kecil.

8 GB. Model 4B pada q4_K_M berukuran 2.6 GB dan masih menyisakan ruang untuk context window yang panjang. Model 8B pada q4_K_M dapat dijalankan dengan window default 4k, tetapi ruang sisanya sangat terbatas. Jangan merencanakan model 8B dengan window 32k pada VPS ini, karena kebutuhan minimum sebesar 10 GB saja sudah melebihi kapasitas VPS.

16 GB. Model 8B pada q4_K_M dengan window 16k atau 32k dapat dijalankan dengan nyaman. Model 14B pada q4_K_M menggunakan bobot sebesar 9.3 GB dan dapat dijalankan dengan window yang tidak terlalu besar. Model 8B pada q8_0 berukuran 8.9 GB, sehingga juga dapat dijalankan. Membandingkan kedua model tersebut menggunakan prompt Anda sendiri adalah cara paling bermanfaat untuk memahami perbedaan ini.

32 GB. Model 14B pada q8_0 (16 GB) dan model 32B pada q4_K_M (20 GB) dapat dimuat. Build 32B dengan window yang besar akan mendekati batas kapasitas, jadi pantau ollama ps dan jangan langsung menganggapnya aman.

Apa yang pertama kali mengalami penurunan akibat kuantisasi

Error kuantisasi tidak menyebar secara merata pada semua kemampuan model. Kelancaran bahasa bertahan paling lama. Justru karena itu, kerusakannya mudah terlewat: model yang dikuantisasi secara buruk masih dapat menulis kalimat yang rapi. Presisi menurun terlebih dahulu. Misalnya, kemampuan mengingat secara tepat nomor versi, tanda tangan API, atau tanggal. Rangkaian penalaran yang panjang juga terdampak, karena kesalahan kecil pada langkah kedua dapat menghasilkan jawaban yang salah pada langkah kedelapan. Format output yang ketat juga rentan; satu kurung yang salah dapat menyebabkan pemanggilan tool gagal.

Hal terakhir itu merupakan pengujian praktis. Ketika model harus mengembalikan JSON yang diproses oleh kode Anda, dampak kuantisasi muncul sebagai error parsing, bukan sekadar prosa yang terasa sedikit lebih buruk. Karena itu, Anda dapat melihat dampaknya pada hari yang sama. Coding agent merupakan bentuk pengujian yang paling berat, karena agent menjalankan model melalui pemanggilan tool berulang kali. Dengan demikian, mengarahkan agent ke server Ollama Anda akan menunjukkan kuantisasi yang terlalu agresif dalam beberapa jam.

Di bawah empat bit, penurunan kualitas menjadi tajam. q3 dan tipe dua bit ditujukan bagi pengguna yang ingin menjalankan model besar pada hardware kecil. Keduanya merupakan pilihan yang wajar jika alternatifnya adalah tidak menjalankan model sama sekali. Namun, keduanya bukan pilihan default yang baik. Perbedaan antara q4_K_M dan q8_0 cukup kecil sehingga tabel perplexity yang dipublikasikan tidak dapat menentukan pilihan untuk workload Anda. Jadi, jangan mencoba menentukannya dengan cara itu. Uji keduanya menggunakan tiga puluh prompt Anda sendiri, lalu baca outputnya.

Kapan q8_0 atau fp16 sepadan dengan penggunaan RAM

Gunakan q8_0 ketika memori benar-benar tersedia dan tugas sangat sensitif terhadap kesalahan kecil: ekstraksi terstruktur, pemanggilan alat, atau kode yang harus berhasil dikompilasi. Dalam kasus ini, Anda membeli jaminan keandalan, bukan model yang secara nyata lebih cerdas.

Gunakan fp16 hanya untuk dua alasan. Pertama, Anda melakukan kuantisasi model sendiri dan memerlukan file sumber. Kedua, Anda mengukur baseline agar dapat mengetahui seberapa banyak kualitas yang dikorbankan oleh build empat bit Anda. Menjalankan model dari fp16 menggunakan memori tiga kali lebih banyak daripada q4_K_M, sedangkan perbedaannya tidak dapat dibedakan oleh kebanyakan orang tanpa mengetahui hasilnya terlebih dahulu. Pada mesin yang hanya menggunakan CPU, fp16 juga menurunkan laju token menjadi sepertiga.

Aturan yang lebih kuat, dengan anggaran memori tetap: model yang lebih besar pada q4_K_M biasanya mengungguli model yang lebih kecil pada q8_0. 9.3 GB bobot 14B dibandingkan 8.9 GB bobot 8B menggunakan jumlah RAM (random access memory) yang hampir sama, tetapi model yang lebih besar memiliki lebih banyak pengetahuan. Uji hal tersebut dengan prompt Anda sendiri, bukan hanya menerimanya begitu saja.

Inferensi yang hanya menggunakan CPU dibatasi oleh bandwidth memori

Sebagian besar paket VPS tidak memiliki GPU, sehingga model berjalan di memori sistem pada CPU host. Proses generasi kemudian dibatasi oleh bandwidth memori, bukan oleh kemampuan komputasi aritmetika, karena untuk menghasilkan satu token, setiap bobot harus dibaca satu kali. Hal ini menetapkan batas atas yang tidak berkaitan dengan jumlah 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 adalah perkiraan angka teoretis untuk host dual-channel DDR4-3200. Bandwidth yang Anda dapatkan lebih kecil karena VPS berbagi bus tersebut dengan setiap tenant lain pada mesin yang sama. Karena itu, anggap angka tersebut sebagai batas atas yang tidak akan dicapai siapa pun. Polanya adalah bagian yang penting: pada CPU, mengurangi separuh bit per bobot kira-kira menggandakan laju token. Quantization adalah pengungkit kecepatan terbesar yang tersedia pada mesin tanpa GPU.

Pemrosesan prompt bekerja secara berbeda. Membaca prompt yang panjang lebih dibatasi oleh kemampuan komputasi daripada bandwidth, sehingga penambahan core membantu proses tersebut, tetapi hampir tidak meningkatkan kecepatan generasi. Mesin yang dapat memproses prompt 4k dengan cepat lalu menghasilkan token secara lambat berperilaku normal.

Jangan menerima perhitungan tersebut begitu saja. Ukur token per detik pada mesin Anda sendiri menggunakan prompt yang sama pada setiap quantization, lalu gunakan hasil pengukuran Anda sebagai acuan utama.

Membuat model terkuantisasi sendiri

Ollama dapat membuat model terkuantisasi dari sumber fp16 atau fp32. Ini berguna jika Anda telah melakukan fine-tuning dan tidak ada tag library yang tersedia. Arahkan Modelfile ke bobot yang belum dikuantisasi:

FROM /path/to/my/model/f16

Kemudian buat model dan lakukan verifikasi:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize menerima q8_0, q4_K_S, dan q4_K_M. Tidak ada opsi q6_K atau q5_K_M di sini. Untuk format tersebut, lakukan kuantisasi menggunakan alat bawaan llama.cpp, lalu impor file GGUF yang telah selesai. Baris quantization dari ollama show digunakan untuk memverifikasi bahwa build berjalan sesuai konfigurasi yang diminta.

Yang akan Anda lihat ketika terjadi masalah

Semua proses berjalan pada CPU, padahal Anda mengharapkan GPU. Baca kolom PROCESSOR:

ollama ps

Perintah tersebut menampilkan 100% GPU, 100% CPU, atau pembagian seperti 48%/52% CPU/GPU. Pembagian berarti bobot model dan cache KV tidak muat di VRAM (video RAM, yaitu memori pada kartu grafis), sehingga sebagian model ditempatkan di memori sistem. Kecepatan kemudian turun mendekati kecepatan CPU saja karena setiap token harus menunggu bagian yang lebih lambat. Kurangi ukuran jendela konteks, lakukan kuantisasi pada cache, atau gunakan build yang lebih kecil. Menambahkan core tidak akan membantu.

Model dihentikan saat dimuat. Periksa log kernel dan service:

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

Baris yang memuat Out of memory: Killed process berarti total bobot, cache KV, dan buffer melebihi kapasitas memori pada mesin. Pada VPS tanpa swap yang dikonfigurasi, seluruh mesin dapat berhenti merespons selama beberapa detik sebelum baris tersebut muncul.

Jawaban menjadi lebih buruk, padahal Anda tidak mengubah apa pun. Dua build dari model yang sama dapat berada berdampingan di ollama ls dengan tag yang berbeda, dan script yang mengambil nama tanpa sufiks akan mengikuti target yang saat ini digunakan library. Jalankan ollama show terhadap tag persis yang diminta client Anda, lalu baca baris quantization, bukan mengandalkan nama dalam file konfigurasi.

FAQ

Kuantisasi Ollama mana yang sebaiknya saya pull?

Mulai dengan q4_K_M. Itu adalah tag default yang dirilis oleh library Ollama untuk sebagian besar model, sehingga ollama pull qwen3:8b dan ollama pull qwen3:8b-q4_K_M mengambil file yang sama. Gunakan q8_0 hanya jika kapasitas memori masih tersedia dan tugas sangat terpengaruh oleh kesalahan kecil, seperti pemanggilan tool atau output JSON terstruktur. Jika anggaran memori tetap, model yang lebih besar pada q4_K_M biasanya mengungguli model yang lebih kecil pada q8_0. Karena itu, uji pasangan tersebut sebelum menggunakan RAM tambahan untuk presisi.

Apakah q4_K_M benar-benar berarti empat bit per bobot?

Tidak. Pada Llama 3.1 8B, hasil pengukuran menunjukkan 4.89 bit per bobot karena setiap blok bobot menyimpan skala sendiri, dan tensor yang paling sensitif dipromosikan ke tipe yang lebih lebar. Q8_0 menghasilkan 8.5 bit, bukan delapan, karena alasan yang sama. Gunakan angka hasil pengukuran saat membuat estimasi: jumlah parameter dikalikan bit per bobot, lalu dibagi delapan, menghasilkan ukuran file dalam byte.

Berapa RAM yang dibutuhkan model 8B pada VPS yang hanya menggunakan CPU?

Jumlahkan bobot, cache KV, dan ruang cadangan. Qwen3 8B pada q4_K_M menggunakan 5.2 GB untuk bobot. Pada jendela 4096 token default, cache menambah 0.6 GB, sehingga kebutuhan minimum mendekati 5.8 GB sebelum memperhitungkan buffer komputasi dan sistem operasi. Pada jendela 32k, cache saja menggunakan 4.83 GB. Sediakan 8 GB untuk jendela pendek dan 16 GB jika Anda memerlukan jendela panjang.

Mengapa model saya menggunakan CPU 100% padahal server memiliki GPU?

Jalankan ollama ps dan baca kolom PROCESSOR. 100% CPU atau pembagian seperti 48%/52% CPU/GPU berarti bobot dan cache KV tidak muat di VRAM, sehingga Ollama menempatkan sebagian atau seluruh model di memori sistem. Penyebab yang umum adalah jendela konteks lebih besar daripada kapasitas kartu, karena cache dialokasikan untuk seluruh jendela saat model dimuat. Kurangi jendela dengan OLLAMA_CONTEXT_LENGTH, atur OLLAMA_KV_CACHE_TYPE=q8_0 untuk membagi dua ukuran cache, atau pull kuantisasi yang lebih kecil.