Senarai Model AI Yang Boleh Dihos Sendiri Mengikut RAM

Apa yang menentukan model AI yang boleh anda hos sendiri

Model AI yang boleh anda hos sendiri ditentukan oleh satu angka: jumlah RAM pada pelayan anda. Keluarga model dan kerangka kerja (framework) kurang penting berbanding sama ada pemberat (weights) model tersebut muat di dalam memori dengan ruang tambahan yang mencukupi. Catatan ini mengandungi pengiraan untuk menentukan perkara tersebut. Pemasangan runtime adalah tugas berasingan yang diterangkan dalam panduan menjalankan Ollama pada VPS.

Dua kos menentukan jawapannya. Pemberat adalah kos tetap yang ditetapkan oleh jumlah parameter dan kuantisasi. Tetingkap konteks (context window) pula adalah kos semasa, dan ini merupakan perkara yang sering dilupakan sehingga model yang dimuatkan semalam gagal dimuatkan hari ini.

Aritmetik saiz: bit bagi setiap parameter

Fail model hampir keseluruhannya terdiri daripada pemberat (weights). Setiap pemberat disimpan pada bilangan bit tertentu. Kuantisasi bermaksud menyimpannya pada bilangan bit yang lebih rendah daripada ketepatan asal semasa latihan, yang mengurangkan sedikit ketepatan tetapi menjimatkan banyak memori. Saiznya ditentukan secara langsung daripada faktor tersebut:

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

Model dikeluarkan pada 16 bit, iaitu 2 GB bagi setiap bilion parameter. Itulah sebabnya hampir tiada sesiapa yang menjalankan ketepatan keluaran (release precision) pada VPS. Berikut adalah kuantisasi yang akan anda temui, berserta purata bit sebenar bagi setiap pemberat:

• Q8_0 menyimpan kira-kira 8.5 bit bagi setiap pemberat, jadi secara kasarnya 1.1 GB bagi setiap bilion parameter.
• Q6_K menyimpan kira-kira 6.6 bit, jadi secara kasarnya 0.83 GB bagi setiap bilion.
• Q5_K_M menyimpan kira-kira 5.7 bit, jadi secara kasarnya 0.71 GB bagi setiap bilion.
• Q4_K_M menyimpan kira-kira 4.8 bit, jadi secara kasarnya 0.6 GB bagi setiap bilion.

Gunakan 0.6 GB bagi setiap bilion parameter sebagai angka kerja anda. Q4_K_M ialah tetapan lalai yang wajar pada mesin yang terhad memori: kehilangan kualiti berbanding 8 bit adalah kecil bagi kebanyakan tugasan, dan saiz fail hampir separuh lebih kecil. Di bawah 4 bit, kehilangan kualiti meningkat dengan cepat, jadi model 70B yang dimampatkan kepada 2 bit biasanya memberikan jawapan yang lebih buruk daripada model 32B pada 4 bit daripada generasi yang sama. Apabila memori terhad, kurangkan kelas saiz model sebelum anda menurunkan kuantisasi 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
  }
]

Lajur pemberat di atas adalah berdasarkan peraturan 0.6 GB bagi setiap bilion. Fail GGUF sebenar berada dalam lingkungan beberapa peratus daripada angka tersebut, kerana lapisan embedding dan output dikekalkan pada ketepatan yang lebih tinggi berbanding bahagian lain. Model 3B pada 4 bit adalah kira-kira 1.8 GB. Model 8B adalah 4.8 GB. Model 32B adalah 19.2 GB, dan model 70B adalah 42 GB.

Mengapa panjang konteks menggunakan lebih banyak RAM berbanding pemberat (weights)

KV cache (cache kunci-nilai, iaitu keadaan perhatian yang disimpan oleh model bagi setiap token dalam perbualan semasa) merupakan kos kedua. Ia diperuntukkan apabila model dimuatkan, dengan saiz mengikut panjang konteks yang anda minta, dan ia berkembang secara linear mengikut panjang tersebut.

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

Pada konteks lalai Ollama, model 8B tersebut menggunakan setengah gigabait untuk cache. Pada 8192 token, ia menggunakan 1 GB. Pada konteks 128k yang diiklankan oleh kad modelnya, ia menggunakan 16 GB, iaitu lebih tiga kali ganda daripada pemberatnya. Model 70B pula adalah kes sebaliknya: cache-nya pada 128k ialah 40 GB, kurang daripada pemberatnya sendiri, kerana grouped query attention menghalang kos bagi setiap token daripada berkembang secepat kiraan parameter.

Panjang konteks lalai Ollama ialah 4096 token pada pelayan yang hanya menggunakan CPU. Apabila GPU tersedia, ia memilih nilai lalai daripada VRAM: 32k antara 24 dan 48 GiB, dan 256k pada 48 GiB ke atas. Tingkatkan nilai ini dengan pemboleh ubah OLLAMA_CONTEXT_LENGTH pada pelayan, kemudian semak nilai yang sebenarnya diperoleh oleh model yang sedang berjalan dalam lajur CONTEXT bagi ollama ps. Aritmetik memori di sebalik tetapan tersebut diperincikan dalam hantaran mengenai num_ctx dan panjang konteks.

Terdapat dua cara untuk mengurangkan penggunaan cache. Minta panjang konteks yang anda perlukan dan bukannya konteks yang diiklankan oleh kad model, memandangkan kebanyakan kerja sembang dan pengekodan muat dalam lingkungan 8k hingga 32k. Atau, lakukan kuantisasi pada cache itu sendiri kepada 8-bit, yang akan mengurangkannya kepada separuh, dengan sedikit kesan terhadap keupayaan mengingat konteks yang panjang.

Model residen mengekalkan RAM tersebut sehingga sesuatu menyahmuatnya

Ollama mengekalkan model dalam memori selama 5 minit selepas permintaan terakhir, kemudian menyahmuatnya. Nilai lalai itu sesuai untuk komputer riba tetapi tidak tepat untuk pelayan, di mana permintaan pertama selepas setiap tempoh melahu akan menanggung semula masa pemuatan.

ollama ps
ollama stop qwen3:4b

ollama ps menyenaraikan apa yang residen, dengan lajur SIZE menunjukkan jumlah memori yang dipegang dan lajur UNTIL menunjukkan bila ia tamat tempoh. Untuk menyemat model secara kekal, tetapkan OLLAMA_KEEP_ALIVE=-1 pada servis tersebut. Nilai 0 akan menyahmuat model sebaik sahaja 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

Hantar satu gesaan, kemudian jalankan ollama ps semula sepuluh minit kemudian. Model tersebut masih disenaraikan, itulah tujuan sebenarnya: ia memegang RAM tersebut sama ada sesiapa menggunakannya atau tidak. Model yang disemat bukanlah kapasiti simpanan. Pada VPS 16 GB, model 8B dengan konteks 8k memegang kira-kira 6 GB selagi servis berjalan, jadi tentukan saiz pelayan berdasarkan model ditambah dengan aplikasi anda, bukan berdasarkan model sahaja. Menyemat model dalam memori membincangkan pertukaran antara latensi permulaan sejuk (cold start).

Apa yang boleh dijalankan pada VPS 4 GB

Peruntukkan kira-kira 1 GB untuk sistem pengendalian dan pelayan model, yang meninggalkan sekitar 3 GB. Ini memuatkan model 1B hingga 4B pada 4 bit, dengan konteks lalai 4096 token. Setakat Ogos 2026, kelas tersebut merangkumi Llama 3.2 pada 3B, Qwen 3 pada 1.7B dan 4B, serta keluaran Gemma dan Phi yang kecil. Anggap ini sebagai contoh saiz, bukan cadangan. Nama model berubah setiap beberapa bulan tetapi pengiraannya tetap sama.

Jangkakan kira-kira 6 hingga 14 token sesaat. Model sekecil ini berfungsi dengan baik untuk tugas khusus: klasifikasi, pengekstrakan tag, ringkasan pendek, dan menulis semula perenggan mengikut gaya tertentu. Model ini lemah dalam penaakulan berbilang langkah dan kod yang merangkumi beberapa fail, dan tiada teknik prompting yang dapat membetulkannya.

Mod kegagalan pada tahap ini ialah swap. Jika model tidak muat, Linux tidak akan menolak untuk memuatkannya. Sebaliknya, ia memindahkan memori ke cakera, dan memandangkan penjanaan satu token membaca setiap pemberat sekali, penjanaan akan merosot kepada saat bagi setiap token. Pantau free -h serta lajur si dan so dalam vmstat 1 semasa model menjana jawapan. Swap in dan swap out yang bukan sifar semasa penjanaan bermakna model tersebut terlalu besar untuk pelan yang digunakan.

Apa yang boleh dijalankan pada VPS 8 hingga 16 GB

Pada tahap ini, model yang dihoskan sendiri menjadi benar-benar berguna. Pada 8 GB, anda boleh menjalankan model 7B atau 8B pada 4 bit, iaitu kira-kira 4.8 GB berat model, dengan konteks 8k. Pada 16 GB, anda boleh menjalankan model 13B atau 14B pada 4 bit, iaitu kira-kira 8.4 GB, atau mengekalkan model 8B pada 8 bit jika anda lebih mengutamakan ketepatan berbanding jumlah parameter.

Kelajuan adalah kekurangannya. Model 8B pada CPU menjana kira-kira 3 hingga 7 token sesaat, manakala model 14B menjana kira-kira 1.5 hingga 3.5. Manusia membaca pada kadar sekitar 5 hingga 10 token sesaat, jadi model 8B pada VPS berasaskan CPU terasa seperti melihat seseorang menaip dengan perlahan. Ini memadai untuk tugasan latar belakang tetapi memenatkan untuk perbualan interaktif. Ujian larian Qwen 3 pada 8B dan saiz lebih besar di VPS menunjukkan gambaran sebenar dalam praktiknya.

Apa yang boleh dijalankan pada VPS 32 hingga 64 GB

Model 32B pada 4 bit memerlukan kira-kira 19.2 GB, jadi ia muat pada pelan 32 GB dengan konteks yang singkat dan berjalan dengan selesa pada 48 GB atau 64 GB. Model 70B pada 4 bit memerlukan kira-kira 42 GB, jadi ia memerlukan 64 GB sebelum anda menambah sebarang cache.

Seterusnya, nilai kelajuan dengan jujur. Model 32B pada CPU berjalan pada kelajuan kira-kira 0.6 hingga 1.5 token sesaat, manakala model 70B pada 0.2 hingga 0.5. Jawapan sepanjang 500 token daripada model 70B mengambil masa kira-kira dua puluh minit. Ini adalah alat kelompok (batch tools). Berikan barisan dokumen untuk diproses sepanjang malam dan kelajuannya tidak menjadi masalah. Jika diletakkan di sebalik tetingkap sembang, kelajuan menjadi sangat penting.

Penghalaan Mixture of Experts (MoE) mengubah pengiraan ini, dan ia merupakan satu perincian seni bina yang berbaloi untuk dipelajari. Model MoE menghantar setiap token melalui hanya sebahagian kecil daripada beratnya (weights). Model dengan 30B jumlah parameter dan 3B parameter aktif bagi setiap token memerlukan memori sebanyak 30B dan menjana kelajuan yang hampir dengan model padat 3B, kerana setiap token hanya membaca pakar yang aktif. Pada pelayan 32 GB, model MoE dengan bentuk tersebut jauh lebih boleh digunakan berbanding model padat 30B. Peraturan yang perlu diingat: jumlah parameter menentukan memori, parameter aktif menentukan kelajuan.

Sejauh manakah kelajuan inferens CPU, secara jujur?

Menjana satu token memerlukan pembacaan setiap pemberat (weight) aktif daripada memori sekali. Tiada cara untuk mengelakkan perkara ini, jadi kelajuan penjanaan pada CPU ditentukan oleh lebar jalur memori (memory bandwidth) dan bukannya bilangan teras (core count). Had maksimumnya ialah hasil bahagi: lebar jalur memori yang boleh digunakan dibahagikan dengan saiz pemberat dalam bait. VPS kongsi yang kecil secara realistik memberikan 10 hingga 25 GB sesaat merentasi vCPU-nya, jadi model bersaiz 4.8 GB akan mencapai had maksimum sekitar 2 hingga 5 token sesaat.

[
  {
    "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
  }
]

Itu adalah julat yang biasa dilaporkan pada perkakasan VPS biasa, bukan penanda aras bagi satu mesin tertentu. Angka anda bergantung pada generasi memori, bilangan saluran pada hos, dan berapa banyak jiran yang bersaing untuk mendapatkannya. Ukur kelajuan anda sendiri, menggunakan mana-mana tag model yang anda sudah miliki:

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

Ringkasan yang dicetak selepas jawapan berakhir dengan baris yang tertulis eval rate: ... tokens/s. Itu ialah kelajuan penjanaan anda. Abaikan larian pertama dalam satu sesi, kerana load duration pada ringkasan yang sama merangkumi proses membaca pemberat daripada cakera. Mengukur token sesaat dengan betul merangkumi cara untuk mendapatkan angka yang wajar untuk dibandingkan.

Dua keputusan sering mengejutkan pengguna di sini. Menambah vCPU akan berhenti memberi kesan dengan cepat, kerana selepas kira-kira 8 teras, teras tambahan hanya menunggu memori dan bukannya melakukan pengiraan aritmetik. Dan pada pelan kongsi, arahan yang sama akan memberikan angka yang berbeza dari jam ke jam, yang merupakan masa curi CPU daripada jiran yang bising (CPU steal time) dan bukannya disebabkan oleh sebarang konfigurasi yang anda buat dengan salah.

Membaca prompt anda adalah tugas yang berbeza daripada menjana jawapan. Pemprosesan prompt terikat dengan pengiraan (compute bound), jadi ia berskala dengan teras, dan di sinilah GPU jauh lebih unggul. Dokumen yang panjang mengambil masa beberapa minit untuk dibaca oleh CPU dan hanya beberapa saat oleh GPU. Itu adalah halangan pertama yang anda akan temui apabila menghalakan ejen pengekodan kepada model yang anda hos, kerana setiap pusingan akan menghantar semula konteks fail dan definisi alat sebelum satu token jawapan pun kembali.

Apakah perubahan apabila anda menambah GPU

Pengiraan aritmetik tidak berubah, hanya kumpulan sumber yang digunakannya sahaja yang berbeza. VRAM ialah had keras, jadi tentukan apa yang muat sebelum anda menyewa:

• 8 GB VRAM memuatkan model 7B atau 8B pada 4-bit dengan konteks yang singkat.
• 16 GB memuatkan model 14B pada 4-bit dengan konteks sebenar, atau 8B pada 8-bit.
• 24 GB memuatkan model 32B pada 4-bit dengan konteks yang dikekalkan singkat.
• 48 GB ke atas memuatkan model 70B pada 4-bit dengan ruang untuk cache dan konkurensi.

Apabila model tidak muat, Ollama akan memecahkannya: sebahagian lapisan pada GPU, selebihnya pada CPU. ollama ps melaporkan pecahan tersebut dalam lajur PROCESSOR, sebagai sesuatu seperti 78%/22% CPU/GPU. Anggap itu sebagai amaran dan bukannya ciri. Bahagian CPU menentukan kelajuan, kerana setiap token masih perlu menunggu lapisan tersebut diproses. Oleh itu, model dengan satu perempat lapisannya pada CPU akan berjalan lebih hampir kepada kelajuan CPU berbanding kelajuan GPU. Jika anda melihat pecahan yang tidak disengajakan, kurangkan panjang konteks terlebih dahulu. Cache biasanya merupakan punca ia melebihi had.

Konkurensi adalah sebab lain untuk meningkatkan saiz. Berat (weights) dikongsi antara permintaan serentak, tetapi setiap permintaan aktif memerlukan cache KV sendiri. Jadi, sepuluh pengguna serentak bagi model 8B pada konteks 8k memerlukan sepuluh kali ganda 1 GB cache sebagai tambahan kepada berat model. Menyediakan perkhidmatan kepada pengguna serentak daripada satu model yang dihoskan sendiri menghuraikan di mana had tersebut terletak.

Sama ada GPU berbaloi untuk disewa juga merupakan persoalan aritmetik, dan ia bergantung kepada berapa banyak token yang anda hasilkan setiap bulan. Titik pulang modal antara VPS GPU dan token API mengandungi angka-angka tersebut.

Perkara yang tidak boleh dihoskan sendiri

Terdapat dua halangan berbeza di sini, dan adalah berguna untuk mengetahui halangan mana yang sedang anda hadapi.

Yang pertama ialah pemberat tertutup (closed weights). Model komersial terkini tidak diedarkan, jadi tiada fail untuk dimuat turun dan tiada perubahan RAM yang boleh mengubah keadaan ini. Anda boleh menghoskan sendiri segala-galanya di sekeliling model tersebut: antara muka, lapisan perolehan (retrieval layer), gelung ejen, dan log. Model itu sendiri kekal sebagai API jauh. Sama ada anda boleh menghoskan sendiri Claude membincangkan perkara ini dengan lengkap.

Yang kedua ialah pemberat terbuka (open weights) yang terlalu besar. Keluaran terbuka yang terbesar adalah reka bentuk campuran pakar (mixture of experts) dengan jumlah parameter mencecah ratusan bilion. Peraturan yang sama terpakai kepada model ini: model dengan jumlah 400B parameter pada 4 bit memerlukan kira-kira 240 GB hanya untuk pemberat, sebelum mengambil kira sebarang cache. Ini memerlukan perkakasan khusus, dan menyewanya secara bulanan menelan kos yang jauh lebih tinggi daripada jumlah yang dibelanjakan kebanyakan orang untuk token API dalam setahun. Apa yang diperlukan untuk menghoskan sendiri model kelas Kimi memperincikan keperluan sebenar.

Garis panduan yang jujur antara kedua-duanya: hoskan sendiri apabila beban adalah stabil dan data tidak sepatutnya meninggalkan pelayan anda. Beli token apabila beban adalah tidak menentu (bursty), atau apabila kualiti jawapan tahap terkini adalah perkara yang sebenarnya anda perlukan.

Semak sumber yang anda miliki sebelum membuat pilihan

free -h
nproc
lscpu | grep 'Model name'

Rancang berdasarkan lajur available dalam free -h, bukan lajur total, kerana total merangkumi memori yang sedang digunakan oleh sistem. Tolak kira-kira 1 GB untuk sistem pengendalian dan pelayan model. Bahagikan baki tersebut dengan 0.6 untuk mendapatkan jumlah parameter terbesar dalam bilion yang boleh anda tampung pada 4 bit. Kemudian, tolak KV cache untuk konteks yang anda benar-benar perlukan. Hasil bakinya adalah jawapan anda, dan tidak seperti senarai nama model, nilai ini tidak akan menjadi lapuk.

FAQ

Berapakah jumlah RAM yang diperlukan untuk menjalankan model 8B?

Sekitar 4.8 GB untuk pemberat (weights) pada kuantisasi 4-bit, ditambah dengan KV cache untuk panjang konteks anda, serta kira-kira 1 GB untuk sistem pengendalian dan pelayan model. Pada konteks 8192 token, cache menambah kira-kira 1 GB, jadi pelan 8 GB mencukupi manakala pelan 4 GB tidak. Jika anda mahukan konteks 128k penuh seperti yang diiklankan pada kad model, cache sahaja memerlukan 16 GB dan anda memerlukan pelan 32 GB.

Mengapakah model saya perlahan walaupun VPS mempunyai banyak vCPU?

Ini kerana penjanaan dihadkan oleh lebar jalur memori (memory bandwidth), bukan oleh teras (cores). Setiap token memerlukan penarikan keseluruhan set pemberat aktif daripada RAM, jadi sebaik sahaja beberapa teras menepukan saluran memori, teras yang lain hanya akan menunggu. Punca biasa yang lain ialah swap. Jika vmstat 1 menunjukkan nilai bukan sifar pada si dan so semasa model sedang menjawab, pemberat tidak dimuatkan sepenuhnya ke dalam RAM dan sebahagian daripada setiap token dihidangkan daripada cakera, yang memakan kos jauh lebih tinggi daripada yang dijangkakan.

Adakah tetingkap konteks yang lebih panjang benar-benar memerlukan lebih banyak memori?

Ya, dan pertumbuhannya adalah linear mengikut token. Model 8B tipikal menggunakan kira-kira 128 KiB KV cache bagi setiap token, jadi 8192 token menelan kos 1 GB dan 131072 token menelan kos 16 GB. Cache diperuntukkan apabila model dimuatkan dan bukannya apabila perbualan berkembang, jadi menetapkan konteks 128k akan menempah memori tersebut serta-merta, walaupun setiap prompt yang anda hantar hanya sepanjang 200 token.

Patutkah saya menjalankan model besar pada 2-bit atau model lebih kecil pada 4-bit?

Pilih model yang lebih kecil pada 4-bit. Kualiti menurun secara perlahan daripada 8-bit kepada 4-bit dan menurun dengan pantas di bawah 4-bit, jadi model 70B yang dimampatkan kepada 2-bit biasanya memberikan jawapan yang lebih buruk daripada model 32B pada 4-bit daripada generasi model yang sama. Kuantisasi yang berat akan menyebabkan pengulangan dan arahan yang terlepas (dropped instructions) dan bukannya ralat, yang memudahkan anda menyalahkan prompt anda. Anggap 4-bit sebagai tahap minimum dan ubah bilangan parameter sebaliknya.

Bolehkah saya melakukan self-host model yang setanding dengan model komersial besar?

Tidak pada VPS biasa. Model berat terbuka (open weight) yang paling berkuasa mempunyai beratus-ratus bilion parameter, yang pada 4-bit bermakna lebih 200 GB RAM sebelum mengambil kira KV cache, dan model komersial yang paling berkuasa tidak diedarkan sama sekali. Apa yang boleh dilakukan oleh perkakasan biasa dengan baik ialah menjalankan model 8B hingga 32B yang bagus untuk satu tugasan khusus, di mana model kecil yang sempit dan mempunyai prompt yang baik sering kali setanding dengan model umum. Jika anda memerlukan kualiti tahap tertinggi, bandingkan harga API dengan perkakasan sebelum anda membeli mana-mana daripadanya.