Ollama mencantumkan gemma3:270m dengan ukuran sekitar 292 MB. Angka ini berguna untuk menghitung kebutuhan storage, tetapi bukan kebutuhan RAM. Nilai tersebut menggambarkan data model yang dikemas untuk varian default Ollama, yang memakai quantization Q8_0. Ketika inferensi berjalan, runtime juga membutuhkan memori untuk metadata model, execution buffer, state token, dan key-value cache yang dipakai attention.

Perbedaan ini penting pada mesin dengan RAM kecil. Perangkat dengan RAM 512 MB sekilas terlihat cukup jika hanya dibandingkan dengan file model 292 MB, padahal sisa memori juga harus menampung Ollama dan sistem operasi. Konfigurasi context dapat mengubah total kebutuhan secara signifikan.

File model hanya menetapkan komponen awal memori

Ollama saat ini menyediakan beberapa varian Gemma 3 270M dengan ukuran file yang berbeda cukup jauh:

Varian Format weight Ukuran yang dipublikasikan
gemma3:270m Q8_0 292 MB
gemma3:270m-it-qat Q4_0 241 MB
gemma3:270m-it-fp16 F16 543 MB
gemma3:270m-it-bf16 BF16 543 MB

Jadi, model 270M default tidak berangkat dari image Q4 berukuran 150 MB. Artifact Ollama saat ini menggunakan Q8_0 dan berukuran 292 MB. Varian QAT Q4_0 mengurangi ukuran weight yang disimpan, sedangkan F16 atau BF16 hampir menggandakan storage weight dibanding artifact default.

Budget runtime secara kasar dapat ditulis sebagai

[ M_{total} \approx M_{weights} + M_{KV} + M_{buffers} + M_{runtime} + M_{OS} ]

Semua komponen tersebut tidak bertambah atau berkurang dengan pola yang sama. Quantization pada weight mengurangi (M_{weights}), tetapi tidak otomatis mengecilkan setiap alokasi lain dengan rasio yang sama.

Context menambah memori yang tidak terlihat pada ukuran download

Gemma 3 270M mendukung context window 32K di Ollama. Context yang dikonfigurasi panjang membutuhkan state yang tidak tersimpan sebagai bagian dari ukuran file model statis.

Pada generasi autoregresif, transformer attention menggunakan kembali key dan value dari posisi token sebelumnya. Serving runtime menyimpan state tersebut di KV cache sehingga seluruh prefix tidak perlu dihitung ulang setiap kali satu token baru dihasilkan.

Secara konseptual, penggunaan memori KV cache bertambah mengikuti besaran seperti:

[ M_{KV} \propto L \times T \times H_{KV} \times D \times B ]

dengan (L) sebagai jumlah layer yang relevan, (T) sebagai panjang context yang disimpan, (H_{KV}) sebagai jumlah key-value head, (D) sebagai lebar state per head, dan (B) sebagai jumlah byte per elemen yang disimpan. Alokasi persis bergantung pada arsitektur model serta implementasi Ollama/llama.cpp, sehingga persamaan ini merupakan model scaling, bukan jaminan nilai RSS tertentu.

Metadata Ollama untuk gemma3:270m mencatat 18 block, context length 32.768 token, empat attention head, satu KV head, serta key/value length 256. Pilihan arsitektur tersebut membantu menjaga model tetap ringkas, tetapi context besar tetap memiliki biaya runtime.

Karena itu, pernyataan tunggal seperti “Gemma 270M membutuhkan RAM 300 MB” terlalu presisi. Angka tersebut mencampur satu ukuran artifact yang tetap dengan beberapa alokasi yang dinamis.

Quantization tidak membagi total RAM dengan rasio yang sama

Anggap representasi weight diubah dari F16 ke format quantized. Komponen weight turun tajam, tetapi proses masih membutuhkan code, stack, allocator bookkeeping, inference workspace, dan state yang bergantung pada context.

Budget tersebut lebih mudah dilihat seperti ini:

memori runtime
|
+-- model weights        <- sangat dipengaruhi quantization weight
+-- KV/cache state       <- dipengaruhi context dan representasi cache
+-- compute buffers      <- dipengaruhi backend dan bentuk eksekusi
+-- Ollama/runtime       <- overhead proses
+-- sistem operasi       <- tidak tersedia untuk model

Hal ini juga menjelaskan mengapa ukuran download model dan RSS proses tidak seharusnya dianggap sama. Memory mapping membuat hubungannya semakin tidak sederhana: mapped model pages, resident pages, shared pages, dan anonymous allocations merupakan pengukuran yang berbeda.

Untuk capacity planning, angka yang relevan adalah penggunaan memori puncak pada workload yang akan dijalankan, bukan ukuran yang tercetak di samping tag model.

Mesin 512 MB hampir tidak memiliki ruang tersisa

Artifact default gemma3:270m sendiri berukuran 292 MB. Pada mesin dengan RAM fisik 512 MB, hanya sekitar 220 MB yang tersisa sebelum sistem operasi, Ollama, inference buffer, dan context state diperhitungkan. Itu bukan budget kapasitas yang layak dijadikan asumsi umum.

Image Linux minimal dapat mengurangi overhead sistem operasi, dan swap dalam konfigurasi tertentu dapat mencegah proses langsung dihentikan karena kehabisan memori. Namun, swap tidak mengubah storage menjadi RAM inferensi yang setara. Paging berat dapat membuat generasi token jauh lebih lambat dan tekanan memori tetap dapat berakhir dengan kegagalan ketika working set membesar.

Untuk kelas deployment ini, RAM 1 GB merupakan titik awal yang jauh lebih praktis daripada 512 MB, tetapi tetap harus diperlakukan sebagai target kapasitas yang perlu diuji, bukan jaminan universal. Context length, request bersamaan, backend, versi Ollama, dan proses lain di host dapat mengubah hasilnya.

Ukur model yang sudah dimuat, bukan hanya menghitung parameter

Ollama menyediakan informasi model yang sedang dimuat melalui:

ollama ps

Pengukuran ini lebih berguna daripada sekadar mengalikan 270 juta parameter dengan jumlah byte nominal per parameter, karena tag Ollama yang digunakan sudah menentukan quantization konkret dan runtime memiliki alokasi tambahan.

Pada level sistem operasi, pengukuran proses memberikan sudut pandang lain:

ps -o pid,rss,vsz,comm -C ollama

Di Linux, RSS menunjukkan resident memory proses, sedangkan VSZ menunjukkan virtual address space dan tidak boleh dibaca sebagai penggunaan RAM fisik.

Pengujian yang dapat diulang juga perlu mengendalikan pengaturan context dan workload. Membandingkan server idle dengan model yang sedang memproses prompt panjang berarti membandingkan dua kondisi berbeda.

Urutan pengukuran yang berguna:

1. catat memori sistem sebelum model dimuat
2. muat gemma3:270m
3. catat memori loaded model dari Ollama
4. jalankan context length dan bentuk prompt target
5. catat puncak memori sistem dan proses
6. ulangi dengan concurrency yang akan dipakai

Nilai puncak pada langkah 5 atau 6 adalah angka yang relevan untuk menentukan apakah RAM mesin mencukupi.

Model kecil menggeser bottleneck, bukan menghilangkannya

Gemma 3 270M cukup kecil sehingga fixed runtime cost terlihat sebagai bagian yang lebih besar dari total memori. Pada model berukuran beberapa gigabyte, beberapa ratus megabyte state di luar weight dapat terlihat sekunder. Pada artifact model 292 MB, kelas overhead yang sama dapat menentukan apakah proses dapat berjalan atau tidak.

Batas praktisnya bukan “270M parameter sama dengan nilai RAM tertentu”, melainkan apakah seluruh inference working set dapat masuk bersama sistem operasi dengan headroom yang cukup agar tidak terus-menerus melakukan paging atau dihentikan karena kehabisan memori.

Untuk varian Gemma 3 270M Ollama saat ini, ukuran file yang dipublikasikan memberikan titik awal yang pasti: 292 MB untuk model default Q8_0, 241 MB untuk varian Q4_0 QAT, dan 543 MB untuk F16 atau BF16. Penggunaan RAM aktual dimulai dari weight tersebut lalu ditambah state runtime. Pada hardware terbatas, ukur working set lengkap pada context length dan concurrency yang benar-benar akan digunakan aplikasi.

Referensi

Kecerdasan Buatan Ollama Gemma Inferensi Memori