Model AI Apa yang Bisa Anda Host Sendiri?

Hal yang menentukan model AI yang dapat Anda host sendiri

Model AI yang dapat Anda host sendiri ditentukan oleh satu angka: RAM pada server. Keluarga model dan framework jauh kurang berpengaruh dibandingkan apakah bobot model dapat dimuat ke memori dengan kapasitas yang masih tersisa. Artikel ini menjelaskan perhitungannya. Menginstal runtime adalah pekerjaan terpisah, yang dibahas dalam panduan menjalankan Ollama pada VPS.

Dua biaya menentukan jawabannya. Bobot model adalah biaya tetap yang ditentukan oleh jumlah parameter dan kuantisasi. Context window adalah biaya saat berjalan, dan bagian inilah yang sering dilupakan hingga model yang kemarin berhasil dimuat tidak dapat dimuat hari ini.

Aritmetika kapasitas: bit per parameter

File model hampir seluruhnya terdiri atas bobot. Setiap bobot disimpan menggunakan sejumlah bit. Kuantisasi berarti menyimpan bobot menggunakan bit yang lebih sedikit daripada presisi saat model dilatih. Hal ini sedikit mengurangi akurasi, tetapi sangat menghemat memori. Ukurannya dapat dihitung langsung:

weights in GB = (parameters in billions x bits per weight) / 8

Model dirilis dengan presisi 16 bit, yaitu 2 GB per miliar parameter. Karena itu, hampir tidak ada yang menjalankan model dengan presisi rilis pada VPS. Berikut kuantisasi yang akan sering Anda temui, beserta rata-rata bit per bobot yang sebenarnya:

• Q8_0 menyimpan sekitar 8.5 bit per bobot, atau sekitar 1.1 GB per miliar parameter.
• Q6_K menyimpan sekitar 6.6 bit, atau sekitar 0.83 GB per miliar parameter.
• Q5_K_M menyimpan sekitar 5.7 bit, atau sekitar 0.71 GB per miliar parameter.
• Q4_K_M menyimpan sekitar 4.8 bit, atau sekitar 0.6 GB per miliar parameter.

Gunakan 0.6 GB per miliar parameter sebagai angka acuan. Q4_K_M adalah pilihan default yang masuk akal pada mesin dengan keterbatasan memori: penurunan kualitas dibandingkan 8 bit kecil pada sebagian besar tugas, sedangkan ukuran file hampir setengahnya. Di bawah 4 bit, penurunan kualitas meningkat dengan cepat. Karena itu, model 70B yang dipadatkan menjadi 2 bit biasanya memberikan jawaban yang lebih buruk daripada model 32B pada 4 bit dari generasi yang sama. Jika memori terbatas, turunkan kelas ukuran sebelum menurunkan presisi di bawah 4 bit.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

Kolom bobot di atas menerapkan aturan 0.6 GB per miliar parameter. File GGUF sebenarnya biasanya berada dalam kisaran beberapa persen dari angka tersebut karena embedding dan output layer disimpan dengan presisi yang lebih tinggi daripada bagian lainnya. Model 3B pada 4 bit berukuran sekitar 1.8 GB. Model 8B berukuran 4.8 GB. Model 32B berukuran 19.2 GB, sedangkan model 70B berukuran 42 GB.

Mengapa panjang konteks membutuhkan lebih banyak RAM daripada bobot model

KV cache (key value cache, yaitu state attention yang disimpan model untuk setiap token yang sedang ada dalam percakapan) adalah biaya kedua. Cache ini dialokasikan saat model dimuat, ukurannya ditetapkan berdasarkan panjang konteks yang diminta, dan bertambah secara linear mengikuti panjang tersebut.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Dengan context default Ollama, model 8B tersebut menggunakan setengah gigabyte untuk cache. Pada 8192 token, model tersebut menggunakan 1 GB. Pada context 128k yang diiklankan dalam kartu modelnya, model tersebut menggunakan 16 GB, lebih dari tiga kali ukuran bobotnya. Model 70B menunjukkan kondisi sebaliknya: cache-nya pada 128k berukuran 40 GB, lebih kecil daripada bobotnya sendiri, karena grouped query attention menjaga agar biaya per token tidak bertambah mendekati laju pertumbuhan jumlah parameter.

Panjang context default Ollama adalah 4096 token pada server yang hanya menggunakan CPU. Jika tersedia GPU, Ollama memilih default berdasarkan VRAM: 32k untuk 24 hingga 48 GiB, dan 256k untuk 48 GiB atau lebih. Naikkan nilainya menggunakan variabel OLLAMA_CONTEXT_LENGTH pada server, lalu periksa nilai yang benar-benar diterima model yang sedang berjalan pada kolom CONTEXT di ollama ps. Perhitungan penggunaan memori di balik pengaturan tersebut dibahas dalam post tentang num_ctx dan panjang konteks.

Ada dua cara untuk mengurangi kembali ukuran cache. Minta context yang Anda perlukan, bukan context yang diiklankan dalam kartu model, karena sebagian besar pekerjaan chat dan coding dapat ditangani dalam 8k hingga 32k. Atau, lakukan kuantisasi cache itu sendiri ke 8 bit sehingga ukurannya menjadi setengah, dengan konsekuensi tertentu pada kemampuan mengingat konteks panjang.

Model resident mempertahankan penggunaan RAM hingga ada proses yang membongkarnya

Ollama mempertahankan model di memori selama 5 menit setelah permintaan terakhir, lalu membongkarnya. Nilai default tersebut sesuai untuk laptop, tetapi tidak sesuai untuk server karena permintaan pertama setelah setiap periode tanpa aktivitas harus kembali menunggu waktu pemuatan.

ollama ps
ollama stop qwen3:4b

ollama ps menampilkan model yang berada di memori, dengan kolom SIZE yang menunjukkan jumlah memori yang digunakan dan kolom UNTIL yang menunjukkan waktu kedaluwarsanya. Untuk mempertahankan model secara permanen di memori, tetapkan OLLAMA_KEEP_ALIVE=-1 pada service. Nilai 0 membongkar model segera setelah setiap respons selesai.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

Kirim satu prompt, lalu jalankan ollama ps lagi 10 menit kemudian. Model tersebut masih tercantum. Inilah tujuannya: model tetap menggunakan RAM tersebut, terlepas dari ada atau tidaknya pengguna. Model yang dipertahankan di memori bukan kapasitas cadangan. Pada VPS 16 GB, model 8B dengan konteks 8k menggunakan sekitar 6 GB selama service berjalan. Karena itu, tentukan ukuran server berdasarkan model dan aplikasi Anda, bukan berdasarkan model saja. Mempertahankan model di memori membahas kompromi terhadap latensi cold start.

Yang berjalan pada VPS 4 GB

Sisihkan sekitar 1 GB untuk sistem operasi dan server model, sehingga tersisa sekitar 3 GB. Kapasitas ini cukup untuk model 1B hingga 4B pada 4 bit, dengan konteks default 4096 token. Per Agustus 2026, kelas ini mencakup Llama 3.2 pada 3B, Qwen 3 pada 1.7B dan 4B, serta rilis kecil Gemma dan Phi. Gunakan contoh tersebut hanya untuk menunjukkan ukuran, bukan sebagai rekomendasi. Nama model berubah setiap beberapa bulan, tetapi perhitungannya tidak berubah.

Perkirakan sekitar 6 hingga 14 token per detik. Model sekecil ini dapat menjalankan tugas yang sempit dengan baik: klasifikasi, ekstraksi tag, ringkasan singkat, dan penulisan ulang paragraf sesuai gaya yang ditetapkan. Model ini lemah dalam penalaran multilangkah dan kode yang mencakup beberapa file. Prompting sebanyak apa pun tidak dapat memperbaiki keterbatasan tersebut.

Mode kegagalan pada tingkat ini adalah swap. Jika model tidak muat di memori, Linux tidak menolak memuatnya. Linux memindahkan halaman memori ke disk. Karena pembuatan satu token membaca setiap weight sekali, kecepatan generasi turun menjadi beberapa detik per token. Pantau free -h serta kolom si dan so pada vmstat 1 saat model memberikan jawaban. Nilai swap in dan swap out yang bukan nol selama generasi berarti model terlalu besar untuk rencana tersebut.

Model yang dapat dijalankan pada VPS 8 hingga 16 GB

Pada kapasitas ini, model self-hosted mulai berguna untuk penggunaan umum. Pada 8 GB, Anda dapat menjalankan model 7B atau 8B pada 4 bit, dengan bobot sekitar 4.8 GB dan context 8k. Pada 16 GB, Anda dapat menjalankan model 13B atau 14B pada 4 bit, dengan bobot sekitar 8.4 GB, atau tetap menggunakan model 8B pada 8 bit jika Anda lebih memilih menggunakan memori untuk presisi daripada jumlah parameter.

Komprominya adalah kecepatan. Model 8B pada CPU menghasilkan sekitar 3 hingga 7 token per detik, sedangkan model 14B menghasilkan sekitar 1.5 hingga 3.5 token per detik. Seseorang membaca sekitar 5 hingga 10 token per detik, sehingga model 8B pada VPS dengan CPU terasa seperti melihat juru ketik yang lambat. Kecepatan ini cukup untuk tugas latar belakang, tetapi melelahkan untuk chat interaktif. Hasil pengukuran Qwen 3 pada 8B dan ukuran yang lebih besar di VPS menunjukkan kinerjanya dalam penggunaan nyata.

Model yang dapat dijalankan pada VPS 32 hingga 64 GB

Model 32B pada 4 bit berukuran sekitar 19.2 GB, sehingga dapat dijalankan pada paket 32 GB dengan context yang singkat dan berjalan dengan nyaman pada 48 GB atau 64 GB. Model 70B pada 4 bit berukuran sekitar 42 GB, sehingga memerlukan 64 GB bahkan sebelum Anda menambahkan cache apa pun.

Kemudian, baca kecepatannya secara realistis. Model 32B pada CPU berjalan sekitar 0.6 hingga 1.5 token per detik, sedangkan model 70B berjalan sekitar 0.2 hingga 0.5 token per detik. Jawaban sepanjang 500 token dari model 70B tersebut memerlukan sekitar dua puluh menit. Pada kecepatan itu, request biasanya terputus sebelum model selesai karena timeout pada client atau proxy di depan Ollama aktif terlebih dahulu. Dari situlah error context deadline exceeded berasal. Ini adalah tool untuk pemrosesan batch. Anda dapat memberinya antrean dokumen untuk diproses semalaman, sehingga kecepatan tidak menjadi masalah. Namun, jika tool tersebut digunakan di balik antarmuka chat, kecepatan sangat berpengaruh.

Routing mixture of experts mengubah perhitungan ini, dan ini adalah satu detail arsitektur yang perlu dipahami. Model MoE hanya mengirimkan setiap token melalui sebagian kecil bobotnya. Model dengan total 30B parameter dan 3B parameter aktif per token memerlukan memori seperti model 30B, tetapi menghasilkan token dengan kecepatan yang mendekati model dense 3B karena setiap token hanya membaca expert yang aktif. Pada mesin 32 GB, MoE dengan bentuk seperti ini jauh lebih mudah digunakan daripada model dense 30B. Aturan yang perlu diingat: total parameter menentukan kebutuhan memori, sedangkan parameter aktif menentukan kecepatan.

Seberapa cepat inferensi CPU, sebenarnya?

Untuk menghasilkan satu token, setiap bobot aktif harus dibaca dari memori satu kali. Tidak ada cara untuk menghindari hal itu. Karena itu, kecepatan generasi pada CPU ditentukan oleh bandwidth memori, bukan jumlah core. Batas maksimumnya adalah hasil pembagian bandwidth memori yang dapat digunakan dengan ukuran bobot dalam byte. Shared VPS kecil secara realistis menyediakan 10 hingga 25 GB per detik di seluruh vCPU-nya. Dengan demikian, model berukuran 4.8 GB biasanya mencapai maksimum sekitar 2 hingga 5 token per detik.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

Rentang tersebut umum dilaporkan pada hardware VPS biasa, bukan hasil benchmark dari satu mesin tertentu. Angka Anda bergantung pada generasi memori, jumlah channel pada host, dan jumlah tetangga yang bersaing menggunakan bandwidth tersebut. Ukur performa Anda sendiri dengan tag model yang sudah Anda miliki:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

Ringkasan yang dicetak setelah jawaban selesai diakhiri dengan baris yang berbunyi eval rate: ... tokens/s. Itulah kecepatan generasi Anda. Abaikan proses pertama dalam satu sesi karena load duration pada ringkasan yang sama juga mencakup pembacaan bobot dari disk. Mengukur token per detik dengan benar menjelaskan cara mendapatkan angka yang layak dibandingkan.

Ada dua hal yang sering mengejutkan orang. Menambahkan vCPU tidak lama kemudian berhenti membantu karena setelah sekitar 8 core, core tambahan menunggu memori alih-alih melakukan perhitungan. Pada paket shared, perintah yang sama juga dapat menghasilkan angka berbeda dari jam ke jam. Penyebabnya adalah CPU steal time dari tetangga yang membebani host, bukan kesalahan konfigurasi Anda.

Membaca prompt Anda merupakan tugas yang berbeda dari menghasilkan jawaban. Pemrosesan prompt dibatasi oleh kemampuan komputasi, sehingga skalanya meningkat dengan jumlah core. Pada tahap inilah GPU memiliki keunggulan terbesar. CPU memerlukan waktu beberapa menit untuk membaca dokumen panjang, sedangkan GPU hanya memerlukan beberapa detik. Inilah hambatan pertama yang Anda temui ketika mengarahkan coding agent ke model yang Anda host, karena setiap giliran harus mengirim ulang konteks file dan definisi tool sebelum satu token pun dari jawaban diterima.

Perubahan saat menambahkan GPU

Aritmetikanya tidak berubah, hanya kapasitas yang digunakan. VRAM adalah batas tetap, jadi hitung terlebih dahulu konfigurasi yang dapat ditampung sebelum menyewa:

• VRAM 8 GB dapat menampung model 7B atau 8B pada 4 bit dengan context yang pendek.
• VRAM 16 GB dapat menampung model 14B pada 4 bit dengan context yang cukup panjang, atau model 8B pada 8 bit.
• VRAM 24 GB dapat menampung model 32B pada 4 bit jika context dibuat pendek.
• VRAM 48 GB atau lebih dapat menampung model 70B pada 4 bit, dengan ruang untuk cache dan konkurensi.

Jika model tidak muat, Ollama membaginya: sebagian layer berjalan pada GPU, sedangkan sisanya berjalan pada CPU. ollama ps melaporkan pembagian tersebut pada kolom PROCESSOR, misalnya sebagai 78%/22% CPU/GPU. Anggap ini sebagai peringatan, bukan fitur. Bagian yang berjalan pada CPU menentukan kecepatan, karena setiap token tetap harus menunggu layer tersebut. Jadi, model yang seperempat layer-nya berjalan pada CPU akan berjalan jauh lebih dekat ke kecepatan CPU daripada kecepatan GPU. Jika Anda melihat pembagian yang tidak diinginkan, kurangi panjang context terlebih dahulu. Biasanya cache yang membuat penggunaan memori melewati batas.

Konkurensi adalah alasan lain untuk memilih kapasitas yang lebih besar. Bobot model digunakan bersama oleh request yang berjalan bersamaan, tetapi setiap request aktif memerlukan KV cache sendiri. Jadi, sepuluh pengguna bersamaan yang menggunakan model 8B dengan context 8k memerlukan cache sepuluh kali 1 GB, di luar kebutuhan memori untuk bobot model. Melayani pengguna secara bersamaan dari satu model self-hosted menjelaskan batas kapasitas tersebut.

Menentukan apakah GPU layak disewa juga merupakan persoalan aritmetika. Jawabannya bergantung pada jumlah token yang benar-benar Anda hasilkan setiap bulan. Titik impas antara GPU VPS dan token API memuat perhitungannya.

Hal yang tidak dapat Anda self-host

Ada dua kendala yang berbeda, dan penting untuk mengetahui kendala mana yang Anda hadapi.

Kendala pertama adalah bobot tertutup. Model komersial frontier tidak didistribusikan, sehingga tidak ada file yang dapat diunduh dan berapa pun jumlah RAM tidak akan mengubah hal tersebut. Anda dapat melakukan self-host pada semua komponen di sekitarnya: antarmuka, lapisan retrieval, loop agen, dan log. Modelnya sendiri tetap diakses melalui remote API. Apakah Claude dapat di-self-host membahas hal ini secara menyeluruh.

Kendala kedua adalah bobot terbuka yang ukurannya terlalu besar. Rilis open-weight terbesar menggunakan desain mixture of experts dengan total parameter hingga ratusan miliar. Aturan yang sama berlaku: model dengan total 400B parameter pada 4 bit memerlukan sekitar 240 GB hanya untuk bobot, belum termasuk cache. Ini memerlukan hardware khusus, dan menyewanya per bulan jauh lebih mahal daripada biaya token API yang dikeluarkan kebanyakan orang dalam setahun. Kebutuhan untuk melakukan self-host model kelas Kimi menjelaskan kebutuhan sebenarnya. Pembagian yang sama juga terlihat dalam library Ollama, tempat GLM 5.2 hanya tercantum sebagai model cloud dan versi saudaranya yang jauh lebih kecil adalah model yang benar-benar diunduh ke VPS.

Batas yang realistis antara keduanya adalah sebagai berikut: gunakan self-host saat beban kerja stabil dan data tidak boleh keluar dari server Anda. Gunakan token saat beban kerja bersifat bursty, atau saat kualitas jawaban frontier memang menjadi kebutuhan utama Anda.

Periksa kapasitas yang tersedia sebelum memilih

free -h
nproc
lscpu | grep 'Model name'

Buat perencanaan berdasarkan kolom available dari free -h, bukan kolom total, karena total mencakup memori yang sedang digunakan sistem. Kurangi sekitar 1 GB untuk sistem operasi dan server model. Bagi sisa kapasitas dengan 0.6 untuk mendapatkan jumlah parameter maksimum, dalam satuan miliar, yang dapat ditampung pada 4 bit. Kemudian kurangi kapasitas untuk cache KV sesuai konteks yang benar-benar ingin Anda gunakan. Sisa kapasitas tersebut adalah jawabannya. Berbeda dari daftar nama model, angka ini tidak cepat usang.

FAQ

Berapa RAM yang saya perlukan untuk menjalankan model 8B?

Sekitar 4.8 GB untuk bobot pada kuantisasi 4 bit, ditambah KV cache untuk panjang konteks Anda, serta sekitar 1 GB untuk sistem operasi dan model server. Pada konteks 8192 token, cache menambah sekitar 1 GB, sehingga paket 8 GB dapat digunakan, sedangkan paket 4 GB tidak mencukupi. Jika Anda ingin menggunakan konteks penuh 128k yang diiklankan pada model card, cache saja berukuran 16 GB. Dalam hal ini, Anda memerlukan paket 32 GB.

Mengapa model saya lambat meskipun VPS memiliki banyak vCPU?

Karena pembuatan token dibatasi oleh bandwidth memori, bukan jumlah core. Setiap token memerlukan seluruh kumpulan bobot aktif untuk dibaca dari RAM. Setelah beberapa core memenuhi kapasitas memory channel, core lainnya hanya menunggu. Penyebab umum lainnya adalah swap. Jika vmstat 1 menunjukkan nilai non-zero pada si dan so saat model memberikan jawaban, bobot tidak muat di RAM. Sebagian pemrosesan setiap token dilakukan dari disk, yang biayanya jauh lebih besar daripada yang terlihat.

Apakah context window yang lebih panjang benar-benar memerlukan lebih banyak memori?

Ya. Pertumbuhannya linear terhadap jumlah token. Model 8B umumnya menggunakan sekitar 128 KiB KV cache per token. Karena itu, 8192 token memerlukan 1 GB, sedangkan 131072 token memerlukan 16 GB. Cache dialokasikan saat model dimuat, bukan saat percakapan bertambah panjang. Jadi, permintaan konteks 128k langsung mencadangkan memori tersebut, meskipun setiap prompt yang Anda kirim hanya sepanjang 200 token.

Sebaiknya saya menjalankan model besar pada 2 bit atau model yang lebih kecil pada 4 bit?

Pilih model yang lebih kecil pada 4 bit. Kualitas menurun secara bertahap dari 8 bit ke 4 bit dan turun dengan cepat di bawah 4 bit. Karena itu, model 70B yang dipadatkan menjadi 2 bit biasanya menghasilkan jawaban yang lebih buruk daripada model 32B pada 4 bit dari generasi model yang sama. Kuantisasi agresif muncul sebagai pengulangan dan instruksi yang diabaikan, bukan sebagai pesan error. Hal ini membuat masalah tersebut mudah disalahkan pada prompt Anda. Anggap 4 bit sebagai batas minimum, lalu ubah jumlah parameter.

Bisakah saya melakukan self-hosting model yang kemampuannya setara dengan model komersial besar?

Tidak pada VPS biasa. Model open weight terkuat memiliki hingga ratusan miliar parameter. Pada 4 bit, model tersebut memerlukan lebih dari 200 GB RAM sebelum memperhitungkan KV cache. Model komersial terkuat bahkan tidak didistribusikan. Perangkat keras biasa dapat menjalankan model 8B hingga 32B yang baik untuk satu tugas tertentu. Untuk tugas yang sempit dan dengan prompt yang disusun dengan baik, model kecil sering kali dapat menyamai model umum. Jika Anda memerlukan kualitas setara model frontier, bandingkan biaya API dengan biaya perangkat keras sebelum membeli salah satunya.