Ollama quantization: Q4, Q8, atau fp16?

Perubahan yang dilakukan quantization Ollama

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

Itulah trade-off utamanya: jejak memori jauh lebih kecil dan jumlah token per detik lebih tinggi, dengan konsekuensi sedikit penurunan akurasi. Bagian berikut menjelaskan cara memperkirakan kedua dampak tersebut untuk model tertentu pada mesin tertentu, sebelum Anda menghabiskan waktu dua puluh menit mengunduh file yang tidak akan 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 tersebut menunjukkan lebar target. q4 berarti sebagian besar tensor bobot dikemas dengan lebar empat bit. q8 berarti delapan bit. fp16 sama sekali tidak dikuantisasi: ini adalah model dengan floating point 16 bit, yaitu presisi yang digunakan saat sebagian besar model dipublikasikan.

K menandai K-quant. Bobot dikelompokkan ke dalam blok-blok kecil, dan setiap blok menyimpan skalanya sendiri di samping nilai yang dikemas. Blok yang seluruh bobotnya berada di sekitar 0.01 mendapatkan skala yang lebih halus. Blok yang memiliki satu outlier besar mendapatkan skala yang lebih kasar. Skala per blok tersebut membuat file empat bit tetap dapat digunakan, dan juga menjadi alasan file empat bit tidak pernah benar-benar menggunakan 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, sedangkan sebagian besar tensor tetap menggunakan empat bit. Itulah sebabnya q4_K_M menghasilkan keluaran 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 berdasarkan nama yang Anda masukkan:

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

ollama show menampilkan architecture, parameters, quantization, context length, dan embedding length. Baris quantization adalah sumber informasi yang sebenarnya untuk model yang Anda tarik beberapa bulan lalu dan tidak lagi Anda ingat saat memilihnya.

Bit per bobot menentukan ukuran file

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

Hal yang mengejutkan pada tabel itu adalah kolom kedua. Q4_K_M bukan empat bit per bobot. Nilainya adalah 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 perhitungannya 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 terkemas yang sama, dan setiap block dikonversi saat digunakan.

Yang sebenarnya dirilis Ollama untuk setiap ukuran model

Library menerbitkan tag q4_K_M, q8_0, dan fp16 untuk sebagian besar keluarga model. Beberapa keluarga yang lebih baru tidak mengikuti pola tersebut dan muncul di library hanya sebagai tag cloud tanpa apa pun yang dapat diunduh pada ukuran apa pun. Kondisi ini menjadi kendala ketika mencoba menjalankan GLM 5.2 pada VPS. Berikut ukuran Qwen3 per August 2026, berdasarkan daftar tag pada halaman model. Setiap angka di bawah ini adalah ukuran di disk sebelum model dimuat ke RAM. Dua atau tiga model sekaligus dapat memenuhi volume root VPS kecil. Karena itu, pahami lokasi penyimpanan model yang diunduh Ollama sebelum mulai mengumpulkan tag.

[
  {
    "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 yang 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 library dengan enggan. Format ini dipilih sebagai default oleh upstream. Karena itu, mencocokkannya merupakan langkah awal yang tepat untuk model apa pun yang belum Anda uji sendiri. Alasan yang sama mendasari pilihan tag dalam menjalankan Qwen 3 pada VPS.

Rasionya tetap berlaku pada setiap baris. Peralihan dari q4_K_M ke q8_0 membutuhkan sekitar tujuh puluh persen lebih banyak ruang, 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 membutuhkan 20 GB untuk bobotnya. Ukuran ini sudah melebihi kapasitas mesin 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 cache KV merupakan biaya kedua yang bergantung pada konteks

Bobot model merupakan biaya tetap. Cache KV (cache key dan value) merupakan biaya variabel. Setiap token dalam jendela konteks menyimpan vektor key dan value untuk setiap layer, sehingga cache bertambah secara linear sesuai ukuran jendela yang diizinkan. Cache dialokasikan untuk seluruh jendela saat model dimuat, bukan saat percakapan bertambah panjang. Karena itu, jendela yang panjang tetap menggunakan memori besar meskipun prompt hanya berisi 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 model tersebut berasal dari konfigurasi model itu sendiri: 36 layer, 8 head key/value, dan dimensi head 128. ollama show memberikan informasi tentang arsitektur dan jumlah parameter, sedangkan config.json milik model di Hugging Face memberikan informasi lainnya. Kalikan biaya per token dengan ukuran jendela, dan penggunaan cache tidak lagi dapat diabaikan.

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

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

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

Untuk instalasi berbasis 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 ukuran jendela yang benar-benar digunakan saat model berjalan. OLLAMA_KV_CACHE_TYPE juga mengkuantisasi cache: f16 merupakan default, q8_0 menggunakan sekitar setengah memori f16, dan q4_0 sekitar seperempatnya. Ini merupakan opsi global, sehingga semua model pada server tersebut mendapatkan perlakuan yang sama. Pada mesin dengan sumber daya terbatas dan jendela panjang, mengurangi separuh ukuran cache membebaskan lebih banyak memori daripada perubahan tunggal lainnya. Menetapkan num_ctx dan biayanya membahas ukuran jendela secara terperinci. Cache juga dialokasikan satu kali untuk setiap slot request bersamaan, bukan satu kali untuk setiap server. Karena itu, jika Ollama diizinkan menjawab dua prompt sekaligus, angka yang baru Anda anggarkan menjadi dua kali lipat. Inilah dasar perhitungan untuk memilih jumlah slot paralel dan batas antrean.

Yang muat pada VPS 8, 16, atau 32 GB

Alokasikan anggaran untuk bobot model, cache KV, serta ruang cadangan bagi sistem operasi dan proses lain yang berjalan. Ruang cadangan 2 GB cukup aman pada 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 dimuat dengan context window default 4k, tetapi ruang sisanya sangat sedikit. Jangan merencanakan model 8B dengan context window 32k pada konfigurasi ini, karena batas minimum 10 GB saja sudah melebihi kapasitas mesin.

16 GB. Model 8B pada q4_K_M dengan context window 16k atau 32k masih memiliki ruang yang cukup. Model 14B pada q4_K_M memiliki bobot sebesar 9.3 GB dan dapat dimuat dengan context window yang tidak terlalu besar. Model 8B pada q8_0 berukuran 8.9 GB, sehingga juga dapat dimuat. Membandingkan kedua konfigurasi tersebut menggunakan prompt Anda sendiri adalah cara paling bermanfaat untuk memahami topik ini.

32 GB. Model 14B pada q8_0 (16 GB) dan model 32B pada q4_K_M (20 GB) dapat dimuat. Build 32B dengan context window yang besar akan mendekati batas kapasitas, jadi pantau ollama ps dan jangan berasumsi bahwa kapasitasnya selalu mencukupi.

Hal yang pertama menurun akibat kuantisasi

Kesalahan kuantisasi tidak memengaruhi semua kemampuan model secara merata. Kelancaran bahasa bertahan paling lama. Inilah alasan kerusakannya mudah terlewat: model yang dikuantisasi secara buruk masih dapat menulis kalimat yang rapi. Presisi menurun lebih dahulu. Contohnya, kemampuan mengingat secara tepat nomor versi, signature API, atau tanggal. Rangkaian penalaran yang panjang juga terdampak. Kesalahan kecil pada langkah kedua dapat menghasilkan jawaban yang salah pada langkah kedelapan. Format output yang ketat turut terdampak. Satu kurung yang salah dapat menyebabkan pemanggilan tool gagal.

Hal terakhir adalah pengujian praktisnya. Saat model harus mengembalikan JSON yang diparses oleh kode Anda, kerusakan akibat kuantisasi muncul sebagai error parsing, bukan sekadar prosa yang kualitasnya agak menurun. Dengan begitu, Anda dapat melihat dampaknya pada hari yang sama. Coding agent merupakan bentuk pengujian yang paling berat karena menjalankan model melalui pemanggilan tool secara berulang. Karena itu, mengarahkan agent ke server Ollama Anda akan menunjukkan kuantisasi yang terlalu agresif dalam waktu kurang dari satu sore.

Di bawah empat bit, penurunan kualitas menjadi tajam. q3 dan jenis dua bit ditujukan bagi pengguna yang ingin menjalankan model besar pada hardware kecil. Keduanya merupakan pilihan yang masuk akal 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. Karena itu, jangan mencoba menentukannya dengan cara tersebut. 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 tidak menoleransi kesalahan kecil: ekstraksi terstruktur, pemanggilan tool, atau kode yang harus berhasil dikompilasi. Dalam hal ini, Anda membeli perlindungan tambahan, bukan model yang secara nyata lebih cerdas.

Gunakan fp16 hanya untuk dua alasan. Pertama, Anda melakukan quantization model sendiri dan memerlukan file sumber. Kedua, Anda mengukur baseline agar dapat mengetahui seberapa besar penurunan kemampuan pada build four-bit Anda. Menjalankan model dari fp16 menggunakan memori tiga kali lebih besar daripada q4_K_M, sedangkan perbedaannya biasanya tidak dapat dikenali kebanyakan orang tanpa mengetahui model yang digunakan. Pada mesin yang hanya menggunakan CPU, fp16 juga menurunkan laju token hingga sepertiganya.

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 dengan 8.9 GB bobot 8B menggunakan jumlah RAM (random access memory) yang hampir sama, sementara model yang lebih besar memiliki pengetahuan lebih banyak. Uji hal tersebut dengan prompt Anda sendiri, bukan hanya menerimanya sebagai fakta.

Inferensi CPU saja 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 aritmetika, karena pembuatan satu token memerlukan pembacaan setiap bobot satu kali. Kondisi ini menetapkan batas 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 tersedia untuk VPS Anda lebih kecil karena bus tersebut digunakan bersama oleh semua tenant lain pada mesin yang sama. Karena itu, anggap angka tersebut sebagai batas atas yang tidak dapat dicapai. Polanya yang penting: pada CPU, pengurangan separuh jumlah bit per bobot kira-kira menggandakan laju token. Quantization adalah faktor peningkatan kecepatan terbesar yang tersedia pada mesin tanpa GPU. Apakah laju yang tersisa dapat diterima bergantung pada model. Nemotron 3.5 Lightning pada VPS menghitung pembagian tersebut untuk satu build dan tag tertentu, termasuk angka RAM yang digunakan. Separuh waktu tunggu lainnya ditentukan oleh jumlah teks yang dihasilkan model. Pada laju 10 token per detik, jawaban sepanjang 600 token memerlukan satu menit penuh. Karena itu, membatasi jawaban dengan num_predict sering kali mengurangi waktu tunggu lebih banyak daripada menurunkan presisi satu tingkat lagi.

Pemrosesan prompt bekerja secara berbeda. Pembacaan prompt yang panjang lebih dibatasi oleh komputasi daripada bandwidth. Karena itu, tambahan core membantu proses tersebut, tetapi hampir tidak meningkatkan kecepatan generasi. Mesin yang memproses prompt 4k dengan cepat lalu menghasilkan teks secara lambat bekerja secara normal.

Jangan menerima perhitungan apa pun 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 penting jika Anda telah melakukan fine-tuning dan tidak ada tag library yang sesuai. Arahkan Modelfile ke bobot yang belum dikuantisasi:

FROM /path/to/my/model/f16

Selanjutnya, lakukan build dan konfirmasi:

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 dengan alat bawaan llama.cpp, lalu impor file GGUF yang telah selesai. Rute impor ini memiliki masalah tersendiri, yaitu ketidakcocokan template chat yang menyebabkan model memberikan respons acak. mengimpor file GGUF ke Ollama menjelaskan proses tersebut. Baris quantization dari ollama show digunakan untuk memverifikasi bahwa build berjalan sesuai permintaan Anda.

Yang akan Anda lihat saat terjadi masalah

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

ollama ps

Kolom tersebut menampilkan 100% GPU, 100% CPU, atau pemisahan seperti 48%/52% CPU/GPU. Pemisahan 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 context window, lakukan kuantisasi pada cache, atau gunakan build yang lebih kecil. Menambah jumlah core tidak akan membantu.

Model dihentikan saat sedang 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 macet 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. Script yang mengambil nama tanpa suffix akan mengikuti target yang saat ini ditunjuk oleh library. Jalankan ollama show terhadap tag persis yang diminta client Anda, lalu baca baris quantization, bukan mempercayai nama dalam file konfigurasi.

FAQ

Kuantisasi Ollama mana yang harus saya pull?

Mulai dengan q4_K_M. Itulah tag default yang dirilis 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 memori masih tersedia dan tugas sangat sensitif terhadap 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 pengukurannya adalah 4.89 bit per bobot. Setiap blok bobot menyimpan skalanya sendiri, dan tensor yang paling sensitif dipromosikan ke tipe yang lebih lebar. Q8_0 berukuran 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 diperlukan 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 menambahkan 0.6 GB, sehingga kebutuhan minimum mendekati 5.8 GB sebelum memperhitungkan buffer komputasi dan sistem operasi. Pada jendela 32k, cache saja berukuran 4.83 GB. Siapkan 8 GB untuk jendela pendek dan 16 GB untuk jendela panjang.

Mengapa model saya menggunakan CPU 100% saat 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. Akibatnya, Ollama menempatkan sebagian atau seluruh model di memori sistem. Penyebab umumnya adalah jendela konteks yang 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.