Model AI Apa yang Bisa Anda Jalankan Sendiri?

Yang menentukan model AI yang dapat Anda jalankan sendiri

Model AI yang dapat Anda jalankan sendiri ditentukan oleh satu angka: RAM pada server. Keluarga model dan framework jauh kurang berpengaruh dibandingkan apakah bobot model dapat dimuat ke memori dengan ruang yang masih tersisa. Artikel ini membahas perhitungannya. Memasang 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 berjalan, dan bagian inilah yang sering dilupakan sampai model yang kemarin berhasil dimuat tidak dapat dimuat hari ini.

Aritmetika ukuran: bit per parameter

File model hampir seluruhnya terdiri atas bobot. Setiap bobot disimpan dengan jumlah bit tertentu. Kuantisasi berarti menyimpan bobot dengan jumlah bit yang lebih sedikit daripada presisi saat model dilatih. Hal ini sedikit mengurangi akurasi, tetapi menghemat banyak memori. Ukurannya dapat dihitung langsung dari rumus berikut:

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 paling sering Anda temui, beserta rata-rata bit per bobot yang sebenarnya:

• Q8_0 menyimpan sekitar 8.5 bit per bobot, sehingga ukurannya sekitar 1.1 GB per miliar parameter.
• Q6_K menyimpan sekitar 6.6 bit, sehingga ukurannya sekitar 0.83 GB per miliar parameter.
• Q5_K_M menyimpan sekitar 5.7 bit, sehingga ukurannya sekitar 0.71 GB per miliar parameter.
• Q4_K_M menyimpan sekitar 4.8 bit, sehingga ukurannya 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 server yang dibatasi oleh memori: penurunan kualitas dibandingkan 8 bit kecil untuk sebagian besar tugas, sedangkan ukuran file hampir setengahnya. Di bawah 4 bit, penurunan kualitas meningkat dengan cepat. Karena itu, model 70B yang dipadatkan hingga 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 menggunakan kurang dari 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 hanya berbeda beberapa persen dari angka tersebut karena layer embedding dan output dipertahankan pada 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 disesuaikan dengan panjang konteks yang diminta, dan bertambah secara linear seiring panjang tersebut.

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

Pada konteks default Ollama, model 8B tersebut menggunakan setengah gigabyte untuk cache. Pada 8192 token, model tersebut menggunakan 1 GB. Pada konteks 128k yang diiklankan pada kartu modelnya, model tersebut menggunakan 16 GB. Jumlah ini lebih dari tiga kali ukuran bobotnya. Model 70B berada pada kondisi sebaliknya: cache-nya pada 128k berukuran 40 GB, lebih kecil daripada bobotnya sendiri, karena grouped query attention mencegah biaya per token bertambah mendekati laju pertambahan jumlah parameter.

Panjang konteks default Ollama adalah 4096 token pada server yang hanya menggunakan CPU. Jika tersedia GPU, Ollama memilih nilai default berdasarkan VRAM: 32k pada kapasitas antara 24 dan 48 GiB, serta 256k pada kapasitas 48 GiB atau lebih. Tingkatkan nilainya dengan 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 postingan tentang num_ctx dan panjang konteks.

Ada dua cara untuk mengurangi kembali ukuran cache. Minta panjang konteks yang Anda perlukan, bukan panjang konteks yang diiklankan pada kartu model, karena sebagian besar pekerjaan chat dan coding dapat ditangani dalam 8k hingga 32k. Cara lainnya adalah melakukan kuantisasi cache itu sendiri ke 8 bit. Ukurannya menjadi setengah, dengan sedikit penurunan kemampuan mengingat konteks panjang.

Model residen tetap berada di RAM sampai dibongkar

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

ollama ps
ollama stop qwen3:4b

ollama ps menampilkan model yang berada di memori. Kolom SIZE menunjukkan jumlah memori yang digunakan, sedangkan kolom UNTIL menunjukkan waktu kedaluwarsanya. Untuk mempertahankan model secara permanen, 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 yang sedang memakainya. Model yang dipertahankan bukan kapasitas cadangan. Pada VPS 16 GB, model 8B dengan konteks 8k menggunakan sekitar 6 GB selama service berjalan. Karena itu, sesuaikan kapasitas server dengan kebutuhan model dan aplikasi Anda, bukan hanya dengan kebutuhan model. Mempertahankan model di memori membahas komprominya terhadap latensi cold start.

Yang dapat dijalankan pada VPS 4 GB

Sisihkan sekitar 1 GB untuk sistem operasi dan server model. Dengan demikian, 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 dari Gemma dan Phi. Gunakan ukuran tersebut sebagai contoh kapasitas, bukan rekomendasi. Nama model berubah setiap beberapa bulan, tetapi perhitungannya tetap sama.

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

Masalah utama pada kelas ini adalah penggunaan swap. Jika model tidak muat di memori, Linux tidak menolak memuatnya. Linux memindahkan sebagian memori ke disk. Karena pembuatan satu token membaca setiap bobot satu kali, kecepatan generasi turun hingga 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 tidak nol selama generasi berarti model terlalu besar untuk paket tersebut.

Yang dapat dijalankan pada VPS 8 hingga 16 GB

Pada kapasitas ini, model self-hosted mulai berguna untuk berbagai keperluan. Pada 8 GB, Anda dapat menjalankan model 7B atau 8B pada 4 bit, dengan bobot sekitar 4.8 GB dan konteks 8k. Pada 16 GB, Anda dapat menjalankan model 13B atau 14B pada 4 bit, dengan ukuran sekitar 8.4 GB. Anda juga dapat mempertahankan model 8B pada 8 bit jika memori ingin digunakan untuk meningkatkan presisi, bukan 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. Karena itu, model 8B pada VPS dengan CPU terasa seperti mengamati juru ketik yang lambat. Kondisi 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 praktik.

Apa yang dapat dijalankan pada VPS 32 hingga 64 GB

Model 32B pada 4 bit berukuran sekitar 19.2 GB, sehingga dapat berjalan pada paket 32 GB dengan context yang pendek dan memiliki ruang yang cukup pada 48 GB atau 64 GB. Model 70B pada 4 bit berukuran sekitar 42 GB, sehingga memerlukan 64 GB sebelum menambahkan cache apa pun.

Selanjutnya, perhatikan kecepatannya secara realistis. Model 32B pada CPU berjalan sekitar 0.6 hingga 1.5 token per detik, sedangkan model 70B berjalan pada 0.2 hingga 0.5 token per detik. Jawaban 500 token dari model 70B tersebut memerlukan sekitar dua puluh menit. Tool ini cocok untuk pemrosesan batch. Masukkan antrean dokumen ke dalamnya semalaman, dan kecepatannya tidak menjadi masalah. Tempatkan model tersebut di balik antarmuka chat, dan kecepatannya sangat berpengaruh.

Routing mixture of experts mengubah perhitungan ini. Ini adalah satu detail arsitektur yang layak dipahami. Model MoE mengirim setiap token hanya melalui sebagian kecil dari bobotnya. Model dengan total parameter 30B dan 3B parameter aktif per token memerlukan memori seperti model 30B dan 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 dapat digunakan daripada model dense 30B. Aturan yang perlu diingat: total parameter menentukan kebutuhan memori, sedangkan parameter aktif menentukan kecepatan.

Seberapa cepat inferensi CPU, secara realistis?

Untuk menghasilkan satu token, semua 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 dibagi ukuran bobot dalam byte. Shared VPS kecil secara realistis menyediakan 10 hingga 25 GB per detik di seluruh vCPU-nya. Jadi, model berukuran 4.8 GB 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. Nilai Anda bergantung pada generasi memori, jumlah channel pada host, dan jumlah tetangga yang bersaing menggunakan bandwidth tersebut. Ukur performa Anda sendiri menggunakan 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 waktu membaca bobot dari disk. Mengukur token per detik dengan benar menjelaskan cara memperoleh angka yang layak dibandingkan.

Ada dua hasil yang sering mengejutkan pengguna. Menambahkan vCPU dengan cepat tidak lagi membantu, karena setelah sekitar 8 core, core tambahan hanya menunggu memori dan tidak menjalankan operasi aritmetika. Selain itu, pada paket shared, perintah yang sama dapat menghasilkan angka berbeda dari jam ke jam. Ini disebabkan oleh waktu steal CPU dari tetangga yang membebani host, bukan oleh kesalahan konfigurasi Anda.

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

Perubahan saat menambahkan GPU

Aritmetika tidak berubah, hanya kumpulan resource yang diterapkan. VRAM adalah batas tetap, jadi hitung terlebih dahulu model yang dapat dimuat sebelum menyewa:

• VRAM 8 GB dapat memuat model 7B atau 8B pada 4 bit dengan context pendek.
• VRAM 16 GB dapat memuat model 14B pada 4 bit dengan context yang memadai, atau model 8B pada 8 bit.
• VRAM 24 GB dapat memuat model 32B pada 4 bit jika context tetap pendek.
• VRAM 48 GB atau lebih dapat memuat model 70B pada 4 bit dengan ruang untuk cache dan concurrency.

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

Concurrency adalah alasan lain untuk memilih kapasitas yang lebih besar. Weight dibagi di antara request yang berjalan bersamaan, tetapi setiap request aktif memerlukan KV cache sendiri. Jadi, sepuluh pengguna bersamaan yang memakai model 8B dengan context 8k memerlukan cache sepuluh kali 1 GB, di luar kebutuhan untuk weight. Melayani pengguna 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 angka-angka tersebut.

Hal yang tidak dapat Anda self-host

Ada dua batasan yang berbeda. Mengetahui batasan yang Anda hadapi akan membantu.

Batasan pertama adalah bobot tertutup. Model komersial frontier tidak didistribusikan. Jadi, tidak ada file yang dapat diunduh, dan penambahan RAM tidak akan mengubah keadaan tersebut. Anda dapat self-host semua komponen di sekitarnya: antarmuka, retrieval layer, agent loop, dan log. Modelnya sendiri tetap berupa API jarak jauh. Apakah Anda dapat self-host Claude membahas hal ini secara lengkap.

Batasan kedua adalah bobot terbuka yang ukurannya terlalu besar. Rilis terbuka terbesar menggunakan desain mixture of experts dengan total parameter mencapai ratusan miliar. Aturan yang sama berlaku: model dengan total 400B parameter pada 4 bit memerlukan sekitar 240 GB hanya untuk bobot, bahkan sebelum cache diperhitungkan. Ini memerlukan perangkat keras khusus. Menyewanya per bulan jauh lebih mahal daripada biaya token API yang dikeluarkan kebanyakan orang dalam setahun. Yang diperlukan untuk self-host model kelas Kimi membahas kebutuhan sebenarnya.

Batas yang realistis antara keduanya adalah sebagai berikut: gunakan self-host saat beban kerja stabil dan data tidak boleh meninggalkan server Anda. Gunakan token saat beban kerja meningkat secara tiba-tiba, 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 pada free -h, bukan kolom total, karena total mencakup memori yang sudah 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 KV cache untuk konteks yang benar-benar Anda perlukan. Hasilnya adalah jawaban Anda. Berbeda dengan daftar nama model, hasil ini tidak cepat usang.

FAQ

Berapa banyak RAM yang saya perlukan untuk menjalankan model 8B?

Sekitar 4.8 GB untuk bobot dengan kuantisasi 4 bit, ditambah KV cache untuk panjang konteks Anda, serta sekitar 1 GB untuk sistem operasi dan server model. Pada konteks 8192 token, cache menambah sekitar 1 GB. Jadi, paket 8 GB dapat digunakan, sedangkan paket 4 GB tidak. Jika Anda ingin menggunakan konteks penuh 128k yang diiklankan pada kartu model, cache saja berukuran 16 GB. Anda perlu mempertimbangkan 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 dimuat dari RAM. Setelah beberapa core memenuhi kapasitas kanal memori, 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 proses untuk setiap token berjalan dari disk, dan biayanya jauh lebih besar daripada yang terlihat.

Apakah jendela konteks yang lebih panjang benar-benar memerlukan lebih banyak memori?

Ya. Pertambahannya linear terhadap jumlah token. Model 8B pada umumnya menggunakan sekitar 128 KiB KV cache per token. Jadi, 8192 token memerlukan 1 GB, sedangkan 131072 token memerlukan 16 GB. Cache dialokasikan saat model dimuat, bukan saat percakapan bertambah panjang. Karena itu, 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, lalu menurun 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 berat biasanya terlihat sebagai pengulangan dan instruksi yang diabaikan, bukan sebagai pesan error. Hal ini mudah disalahkan pada prompt Anda. Anggap 4 bit sebagai batas minimum, lalu ubah jumlah parameternya.

Apakah saya dapat menjalankan sendiri 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 KV cache diperhitungkan. Model komersial terkuat bahkan tidak didistribusikan. Perangkat keras biasa paling efektif untuk menjalankan model 8B hingga 32B yang baik pada satu tugas tertentu. Model kecil dengan prompt yang sempit dan dirancang dengan baik sering kali dapat menyamai model umum untuk tugas tersebut. Jika Anda memerlukan kualitas setara model frontier, bandingkan biaya API dengan biaya perangkat keras sebelum membeli salah satunya.