Cara Menjalankan Qwen 27B di VPS Menggunakan Ollama

Bisakah Anda menjalankan Qwen 3.8 27B pada VPS tanpa GPU?

Untuk menjalankan Qwen 3.8 27B pada VPS, Anda pertama-tama memerlukan tag model yang tersedia, dan per 4 Agustus 2026 pustaka Ollama tidak memiliki entri qwen3.8 sama sekali. Tag 27B yang dirilis paling mendekati adalah qwen3.6:27b: 27,8 miliar parameter, kuantisasi Q4_K_M, lisensi Apache 2.0. Setiap perintah dan setiap angka di bawah ini menggunakan tag tersebut pada Ollama v0.32.5, yang diterbitkan pada 27 Juli 2026.

Jawaban singkatnya adalah bisa pada VPS dengan RAM 32 GB atau lebih, namun berjalan lambat. Model padat 27B pada Q4 memerlukan sekitar 17 GB RAM hanya untuk bobotnya saja, sebelum satu token konteks pun disimpan. Hal ini membuat paket 8 GB dan 16 GB sama sekali tidak memungkinkan. Pada VPS DDR4 dua kanal yang umum, batas kecepatannya kira-kira 3 token per detik, yang lebih lambat daripada kecepatan baca kebanyakan orang.

Dari mana angka 3.8 berasal? Kemungkinan besar dari jumlah parameter. Halaman Ollama untuk qwen3.6:27b melaporkan 27,8 miliar parameter, dan 27,8 mudah diingat kemudian sebagai 3.8. Terdapat juga qwen3.5:27b, build Q4_K_M yang sama dari rilis sebelumnya. Periksa daftar langsung sebelum Anda menyalin perintah apa pun, di halaman tag Ollama qwen3.6. Jika qwen3.8 yang asli dirilis nantinya, perhitungan di sini tetap berlaku, karena hal tersebut bergantung pada jumlah parameter dan bit per bobot, bukan pada nomor versinya.

Tag Ollama mana yang harus ditarik, dan cara memeriksanya

Menarik tag yang tidak ada akan menghasilkan error yang jelas, sehingga hal ini cepat diselesaikan langsung pada server. Tag yang tersedia pun bisa saja tidak dapat dijalankan secara lokal, yang sering kali membingungkan pengguna terkait GLM 5.2, tercantum di pustaka tetapi hanya dilayani dari cloud Ollama.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show mencetak arsitektur, jumlah parameter, panjang konteks, dan kuantisasi untuk tag yang Anda miliki saat ini. Jika baris parameter terbaca 27.8B dan baris kuantisasi terbaca Q4_K_M, Anda memiliki build yang digunakan dalam panduan ini. Pustaka tersebut juga menyediakan qwen3.6:27b-q8_0 dan qwen3.6:27b-bf16 untuk bobot yang sama pada presisi yang lebih tinggi, ditambah sekumpulan tag 35b-a3b yang merupakan model MoE (mixture of experts) dan berperilaku sangat berbeda pada CPU. Penjelasan lebih lanjut mengenai hal tersebut ada di bawah.

Jumlah parameter dikalikan byte per bobot

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Rumusnya terdiri dari satu baris. Byte bobot = parameter * bit per bobot / 8. Pada 4 bit murni, 27,8 miliar parameter akan berukuran 13,9 GB. Tag Q4_K_M yang dirilis berukuran 17 GB, yang secara praktis menghasilkan 4.89 bit per bobot.

Selisih tersebut bukanlah kesalahan. Format K-quant tidak menyimpan setiap tensor pada lebar nominal. Tensor yang paling banyak kehilangan kualitas akibat kompresi dipertahankan pada 5 atau 6 bit, dan lapisan embedding token serta output biasanya dibiarkan pada Q6_K atau Q8_0. Nama pada format tersebut adalah rata-rata, dan rata-ratanya berada di kisaran 4,9. Efek yang sama terlihat pada ujung skala lainnya: 56 GB untuk BF16 adalah 16.1 bit per bobot, bukan 16 bit rata, karena file tersebut juga membawa metadata dan tabel embedding presisi penuh.

Q5_K_M tidak memiliki tag yang dipublikasikan untuk model ini, sehingga baris 19.8 GB dihitung berdasarkan 5,7 bit per bobot yang lazim untuk format tersebut, bukan hasil pengukuran. Q8_0 hampir menggandakan Q4 menjadi 30 GB. Pada mesin yang hanya menggunakan CPU, penggandaan tersebut memakan dua kali lipat trafik memori per token, sehingga secara kasar juga memangkas kecepatan token per detik Anda menjadi setengahnya. Q4_K_M adalah default yang tepat di sini karena alasan tersebut. Jika Anda lebih mengutamakan sisi kualitas daripada sisi memori, perbandingan lebih mendalam antara Q4, Q8, dan fp16 menunjukkan di mana output sebenarnya mulai mengalami degradasi.

Biaya KV cache seiring bertambahnya konteks

Bobot model adalah biaya tetap. KV cache (key and value cache, yaitu status attention yang disimpan model untuk setiap token yang telah diproses) tumbuh secara linear seiring panjang konteks, dan di sinilah sebagian besar pengguna kehabisan RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Angka-angka tersebut mengasumsikan struktur yang digunakan Qwen pada model dense terbaru mereka di kelas ukuran ini: 64 layer, 8 head key/value di bawah GQA (grouped-query attention), dan dimensi head sebesar 128. Ini setara dengan 256 KiB per token pada f16, sehingga menjadi 8 GB pada 32k token dan 32 GB pada 128k. Jangan hanya mengandalkan perhitungan saya, lakukan verifikasi pada mesin Anda sendiri. Muat model tersebut dan baca kolom SIZE pada ollama ps, yang melaporkan bobot, cache, dan overhead sebagai satu angka total.

Inilah alasan mengapa konteks 256K pada kartu model hanyalah tajuk utama, bukan rencana operasional. Mengisinya pada f16 akan memakan 64 GB cache di luar bobot model, pada mesin yang sudah menghabiskan 17 GB untuk bobot. Ollama tidak memberikan jendela penuh secara default. Ollama memuat jendela yang jauh lebih kecil, dan Anda harus menaikkannya secara sengaja dengan OLLAMA_CONTEXT_LENGTH. Variabel tingkat server tersebut bukan satu-satunya kendali, dan mengatur num_ctx pada permintaan individu memungkinkan Anda mempertahankan nilai default yang hemat untuk tugas lain, sementara satu pekerjaan panjang mendapatkan jendela yang lebih besar. Naikkan nilainya secara bertahap dan periksa ollama ps setelah setiap perubahan.

Dua pengaturan dapat memangkas cache hingga setengahnya atau lebih. OLLAMA_KV_CACHE_TYPE=q8_0 menyimpan cache pada 8 bit, bukan 16 bit, sehingga mengurangi 32k token dari 8 GB menjadi 4 GB. Pengaturan ini memerlukan flash attention, jadi aktifkan juga OLLAMA_FLASH_ATTENTION=1, dan pastikan penurunan penggunaan memori terlihat di ollama ps alih-alih berasumsi pengaturan tersebut telah diterapkan. OLLAMA_NUM_PARALLEL=1 sama pentingnya. Ollama dapat melayani beberapa permintaan sekaligus, dan setiap slot mendapatkan bagian konteksnya sendiri, sehingga membiarkan paralelisme pada nilai default akan melipatgandakan cache yang telah Anda anggarkan. Jika lebih dari satu orang akan menggunakan mesin ini, perkalian tersebut adalah sumber masalahnya, dan jumlah pengguna konkuren yang dapat dilayani model self-hosted ditentukan oleh slot cache dan kedalaman antrean jauh sebelum ditentukan oleh jumlah core.

Kapasitas yang dapat ditampung oleh RAM 8, 16, 32, dan 64 GB

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Baca kedua angka tersebut sebagai ribuan token konteks yang dapat ditampung bersama bobot model, pada cache f16, di VPS Linux headless dengan sisa sekitar 1,5 GB untuk sistem operasi dan sedikit margin tambahan. Angka nol berarti bobot model tidak muat, sehingga tidak ada yang dapat ditampung.

Kapasitas 8 GB dan 16 GB bukanlah batas yang tipis. Bobot sebesar 17 GB tidak akan muat ke dalam RAM 16 GB, dan pengaturan konteks apa pun tidak akan mengubah hal tersebut. Menambahkan swap juga tidak akan membantu. Ollama melakukan memory-mapping pada file GGUF, sehingga begitu halaman residen melebihi kapasitas RAM, kernel akan mulai melakukan evict dan membaca ulang halaman tersebut, dan setiap token kemudian akan menarik gigabyte data dari disk. Server akan mengalami iowait yang tinggi dan menghasilkan kecepatan jauh di bawah satu token per detik.

32 GB adalah titik awal yang layak. Bobot memakan 17 GB dan Anda memiliki sisa sekitar 13 GB, yang mencakup sekitar 32k token konteks f16 dengan margin. Bobot Q8_0 sebesar 30 GB sama sekali tidak muat pada tingkatan ini.

64 GB adalah kapasitas yang nyaman. Q4 menyisakan ruang untuk sekitar 128k token konteks, dan bobot Q8_0 dapat dimuat dengan sisa sekitar 64k token di belakangnya. Sebelum membayar untuk 64 GB demi mendapatkan Q8, pahami apa yang Anda beli: output yang sedikit lebih baik dengan kecepatan setengahnya, pada mesin yang memang sudah lambat. Q4 dengan konteks yang lebih panjang adalah pilihan yang lebih baik bagi hampir semua orang.

Seberapa cepat inferensi CPU pada VPS?

Menghasilkan satu token dari model padat berarti membaca setiap bobot dari memori sebanyak satu kali. Bukan hanya sebagian. Semuanya. Jadi, batas kecepatannya bukan jumlah core Anda, melainkan bandwidth memori dibagi dengan ukuran bobot. Pada Q4, ini berarti 17 GB trafik memori per token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Angka tersebut adalah batas atas, bukan pengukuran nyata. Output aktual biasanya berada di kisaran 50 hingga 70 persen dari angka tersebut, karena latensi memori dan prefetching yang tidak sempurna membuat Anda tidak akan pernah mencapai puncak teoretis. VPS dengan DDR4-3200 dua kanal memiliki batas atas 3 token per detik, jadi perkirakan sekitar 2. Unit dengan DDR5-4800 dua kanal memiliki batas atas 4.5, jadi perkirakan sekitar 3.

Server dengan spesifikasi tinggi memiliki peringatan tersendiri. Platform EPYC dua belas kanal memiliki 460.8 GB/s dan batas atas 27.1 token per detik, namun Anda tidak menyewa satu EPYC utuh. Bandwidth memori adalah sumber daya host yang dibagi oleh setiap penyewa di mesin tersebut, sehingga slice 8 vCPU tidak mendapatkan dua belas kanal bandwidth eksklusif. Panduan yang berfokus pada GPU sering melewatkan hal ini, padahal inilah alasan mengapa dua paket VPS dengan jumlah vCPU identik bisa memiliki perbedaan kecepatan hingga tiga kali lipat pada model yang sama.

Menambah vCPU akan berhenti memberikan manfaat lebih awal karena alasan yang sama. Begitu core meminta data lebih cepat daripada kemampuan pengontrol memori untuk mengirimkannya, thread tambahan hanya akan menambah overhead penjadwalan tanpa memberikan peningkatan performa. Atur OLLAMA_NUM_THREAD ke jumlah core fisik Anda, lakukan pengukuran, lalu coba gunakan setengah dari jumlah tersebut. Pada banyak paket shared, pengaturan yang lebih rendah justru lebih cepat.

Pemrosesan prompt berperilaku berbeda. Prefill, yaitu proses melewati input Anda sebelum token pertama muncul, lebih dibatasi oleh komputasi daripada bandwidth, sehingga skalanya meningkat seiring jumlah core. Efek praktisnya adalah jeda yang lama sebelum output dimulai pada prompt yang besar, diikuti oleh kecepatan stabil yang lambat seperti di atas. Ukur waktu kedua bagian tersebut secara terpisah dengan --verbose, yang akan mencetak prompt eval rate dan eval rate untuk setiap permintaan.

Jika model padat 27B terasa terlalu lambat, periksa tag qwen3.6:35b-a3b sebelum menyerah pada CPU. Tag tersebut mengaktifkan sekitar 3 miliar parameter per token, bukan seluruh 27,8 miliar, sehingga trafik memori per token turun hampir satu orde besarnya meskipun ukuran file di disk lebih besar. Anda menukar penggunaan RAM demi kecepatan. Pilihan runtime juga berpengaruh di sini, dan Ollama dan llama.cpp mengekspos kontrol tuning CPU yang berbeda di atas kode inferensi dasar yang sama.

Kapan sebaiknya menyewa GPU per jam

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Rumus yang sama jika diterapkan pada bandwidth memori GPU yang dipublikasikan memberikan kategori jawaban yang berbeda. Kartu konsumen 24 GB memiliki batas atas 59 token per detik pada bobot ini. Kartu pusat data saat ini mencapai 197. Itu bukanlah celah yang bisa Anda tutup dengan menyesuaikan jumlah thread. Kartu tersebut menjalankan memorinya pada 1008 GB/s, sedangkan VPS Anda berjalan pada puluhan GB/s.

Jadi, tentukan batasan berdasarkan beban kerja, bukan berdasarkan preferensi. Inferensi CPU adalah jawaban yang tepat jika pekerjaannya bersifat asinkron dan tidak ada yang menunggunya: peringkasan tumpukan dokumen semalaman, atau pekerjaan klasifikasi malam hari yang berjalan saat Anda tidur. Sewa GPU saat seseorang menunggu output, atau saat permintaan datang lebih cepat dari satu kali setiap 30 detik, karena kotak yang hanya menggunakan CPU tidak memiliki ruang untuk batching dan antrean akan terus bertambah.

Perbandingan biayanya tidak sejelas yang terlihat. VPS 64 GB menagih setiap jam dalam sebulan terlepas dari apakah model dimuat atau tidak, sementara instance GPU hanya menagih jam saat Anda menjalankannya. Jika penggunaan nyata Anda adalah dua jam sehari, GPU sewaan bisa lebih cepat sekaligus lebih murah. Hitung siklus kerja Anda terlebih dahulu, baru tentukan harganya. Memilih VPS dengan GPU membahas apa yang perlu diperiksa pada instance itu sendiri, dan vLLM lebih unggul daripada Ollama saat Anda melayani permintaan konkuren pada GPU karena vLLM melakukan batching dengan benar.

Ada opsi ketiga yang sering dilupakan orang. Tetap gunakan 27B pada CPU untuk pekerjaan batch dan tempatkan model API yang di-host di depan jalur interaktif. Tidak ada aturan yang mengharuskan satu model untuk melayani keduanya.

Menginstal Ollama dan mengukur performa server Anda

Skrip instalasi yang digunakan adalah skrip resmi, yang akan menyiapkan layanan systemd dan menjalankannya sebagai pengguna ollama khusus.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version harus menampilkan 0.32.5 atau versi yang lebih baru. Periksa free -g sebelum Anda mengunduh apa pun. Jika kolom total pada baris Mem menunjukkan angka di bawah 32, hentikan proses di sini dan pilih model yang lebih kecil, karena mengunduh 17 GB yang tidak dapat Anda jalankan hanya akan membuang waktu satu jam dan banyak ruang disk.

Atur opsi runtime di dalam override systemd, bukan di shell Anda. Model berjalan di dalam layanan tersebut, sehingga tidak akan pernah mendeteksi lingkungan interaktif Anda.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

Output --verbose adalah pengukuran yang Anda cari. eval rate adalah jumlah token per detik selama proses generasi. prompt eval rate adalah kecepatan prefill Anda. load duration adalah durasi yang dibutuhkan untuk membaca bobot (weights) dari disk, itulah sebabnya OLLAMA_KEEP_ALIVE=60m diatur: pada CPU, memuat ulang 17 GB dari disk pada setiap permintaan memakan biaya waktu lebih besar daripada permintaan itu sendiri. Batas waktu idle default adalah lima menit, cukup singkat sehingga antrean batch dengan jeda antar item akan membayar biaya pemuatan tersebut berulang kali, dan opsi untuk menjaga model tetap residen mencakup kolom keep_alive per-permintaan serta cara agar pengaturan tersebut tetap bertahan setelah reboot.

Saat model dimuat, periksa penggunaan memori dari terminal kedua.

ollama ps

Kolom SIZE adalah penggunaan memori aktual termasuk KV cache, dan nilainya harus mendekati bobot ditambah baris untuk panjang konteks Anda pada tabel KV. Pada 8192 token dengan cache 8-bit, perkirakan penggunaan sekitar satu gigabyte di luar bobot, dibandingkan dengan 2 GB jika cache tetap pada f16. Kolom PROCESSOR harus menunjukkan 100% CPU. Jika tertulis hal lain, berarti ada sesuatu yang menggunakan GPU dan angka kecepatan dalam panduan ini tidak menggambarkan kondisi server Anda.

Mode kegagalan dan string tepat yang akan Anda lihat

Model menolak untuk dimuat. Ollama mencetak baris yang menyebutkan kedua angka tersebut, dalam bentuk model requires more system memory (18.6 GiB) than is available (15.2 GiB). Ini adalah kegagalan yang baik, karena Ollama melakukan pemeriksaan sebelum melakukan alokasi alih-alih membiarkan kernel yang menanganinya. Kurangi panjang konteks, turunkan ke tag yang lebih kecil, atau pindah ke paket yang lebih besar.

Proses menghilang di tengah jawaban. Klien tidak menampilkan apa pun yang berguna, dan journalctl -u ollama -n 50 menunjukkan layanan sedang melakukan restart. Jalankan dmesg -T | tail, dan baris yang bertuliskan Out of memory: Killed process ... (ollama) berarti OOM killer kernel telah menghentikan proses tersebut. Hal itu terjadi ketika pemeriksaan pra-muat berhasil tetapi cache membengkak melebihi estimasi selama percakapan yang panjang. Kurangi panjang konteks.

Proses pull gagal seketika. Error: pull model manifest: file does not exist berarti tag tersebut tidak ada di pustaka. Mengetik qwen3.8:27b menghasilkan pesan ini, begitu pula kesalahan ketik apa pun pada nomor versi. Konfirmasikan tag di halaman pustaka sebelum menyalahkan jaringan Anda.

Semuanya berfungsi tetapi sangat lambat. Kecepatan di bawah satu token per detik pada mesin dengan RAM yang cukup menunjukkan adanya paging, bukan masalah komputasi. Jalankan vmstat 1 saat proses pembuatan berlangsung. Kolom si atau so yang tidak bernilai nol berarti kernel sedang melakukan swapping, dan solusinya adalah mengurangi konteks atau mengurangi jumlah model yang dimuat. Nilai wa yang tinggi secara stabil tanpa aktivitas swap berarti bobot yang dipetakan ke memori (memory-mapped weights) sedang dibaca ulang dari disk, yang berarti bobot tersebut tidak benar-benar muat di memori.

Token pertama membutuhkan waktu 30 detik lalu kecepatan output meningkat. Itu adalah prefill, dan itu normal. System prompt yang panjang akan memakan waktu pada setiap permintaan yang tidak ada di cache, jadi persingkat system prompt sebelum melakukan penyesuaian lainnya.

Kegunaan sebenarnya dari model 27B berbasis CPU

Tetapkan ekspektasi berdasarkan angka, bukan harapan. Dengan kecepatan dua hingga empat token per detik, jawaban sepanjang 500 token membutuhkan waktu antara dua hingga empat menit. Kecepatan ini tidak layak untuk percakapan, namun sangat memadai untuk sistem antrean. Model yang berpikir sebelum menjawab akan memperburuk perhitungan tersebut, karena token penalaran tersembunyi dihasilkan pada kecepatan lambat yang sama dengan jawaban. Oleh karena itu, menyesuaikan tingkat upaya penalaran dengan tugas adalah salah satu dari sedikit cara untuk mempercepat respons tanpa mengganti model. Ringkasan dokumen, penandaan massal, ekstraksi kolom dari tumpukan file, dan tinjauan kode tanpa pengawasan dapat menoleransi kecepatan ini karena tidak ada pihak yang menunggu respons secara langsung. Bantuan pengodean berada tepat di ambang batas tersebut, sehingga mengarahkan agen pengodean ke model yang Anda host sendiri bermanfaat untuk tugas latar belakang seperti pesan commit dan pembuatan kerangka pengujian, bukan untuk saran inline yang mengharuskan Anda menunggu.

Argumen privasi adalah alasan yang sebenarnya. Model berjalan pada perangkat keras yang Anda sewa dan kendalikan, tidak ada permintaan yang keluar dari server, dan tidak ada tagihan per token. Hal ini sangat berharga untuk data yang diatur secara ketat, bahkan pada kecepatan tiga token per detik. Pertimbangkan secara jujur dengan alternatifnya: self-hosting model skala frontier membutuhkan perangkat keras sepuluh kali lipat lebih banyak, dan model 27B pada CPU adalah titik termurah dalam kurva tersebut di mana outputnya masih layak untuk dibaca.

Untuk melakukan benchmark, Anda memerlukan input terstruktur yang nyata, dan sebagian besar API data publik mewajibkan akun sebelum Anda dapat mengukur throughput. Endpoint demo Strasmore (yang kami kelola) menjawab SQL read-only selama 22 tahun data pasar AS tanpa kunci dan tanpa pendaftaran: GET ke https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 mengembalikan JSON yang dapat Anda masukkan langsung ke dalam loop prompt, beserta SQL tepat yang menghasilkannya, sehingga model memiliki sesuatu untuk diringkas yang dapat Anda periksa secara independen. Batasannya adalah 500 baris dan 20 detik per panggilan, jauh lebih dari yang dapat dikonsumsi oleh server dengan kecepatan dua token per detik. Daftar kolom lengkap ada di https://api.strasmore.com/v1/schema.

Jika ini adalah instalasi Ollama pertama Anda, panduan lengkap untuk menjalankan Ollama di VPS mencakup pengaturan layanan, HTTP API, dan aturan firewall yang diasumsikan sudah Anda miliki dalam panduan ini. Jangan ekspos port 11434 ke internet. Ollama tidak dilengkapi dengan autentikasi bawaan, sehingga siapa pun yang dapat mengakses port tersebut dapat menggunakan model Anda dan membaca prompt Anda.

FAQ

Apakah terdapat model Qwen 3.8 27B di Ollama?

Tidak. Per 4 Agustus 2026, pustaka Ollama tidak memiliki namespace qwen3.8. Tag 27B yang tersedia adalah qwen3.5:27b dan qwen3.6:27b, keduanya merupakan build Q4_K_M dari model padat dengan 27,8 miliar parameter. Angka 3.8 dalam istilah pencarian hampir pasti merupakan jumlah parameter 27,8B yang diingat sebagai nomor versi. Periksa https://ollama.com/library/qwen3.6/tags untuk daftar terkini, dan jalankan perintah pull qwen3.6:27b jika Anda menginginkan rilis 27B terbaru. Tag yang tidak ada akan gagal dengan pesan Error: pull model manifest: file does not exist.

Berapa banyak RAM yang saya butuhkan untuk menjalankan model Qwen 27B di VPS?

32 GB adalah batas minimum praktis untuk Q4_K_M. Bobot model berukuran 17 GB, sistem operasi membutuhkan sekitar 1,5 GB, dan KV cache menambahkan sekitar 1 GB untuk setiap 4000 token konteks pada f16. Paket 16 GB tidak dapat memuat bobot tersebut sama sekali, dan swap tidak membantu karena file dipetakan ke memori (memory-mapped) sehingga kernel akan terus membacanya kembali dari disk pada setiap token. Paket 64 GB memberikan ruang untuk konteks panjang atau untuk bobot Q8_0 sebesar 30 GB.

Berapa banyak token per detik yang dihasilkan model 27B pada CPU?

Bagi bandwidth memori Anda dengan ukuran bobot, lalu ambil 50 hingga 70 persen dari hasilnya. VPS dengan DDR4-3200 dua kanal memiliki batas atas mendekati 3 token per detik dan menghasilkan sekitar 2 token per detik. Unit dengan DDR5-4800 dua kanal memiliki batas atas mendekati 4.5 dan menghasilkan sekitar 3 token per detik. Platform server dengan kanal lebih banyak terlihat jauh lebih baik di atas kertas, namun bandwidth memori dibagi di antara semua penyewa pada host tersebut, jadi ukur milik Anda sendiri dengan ollama run qwen3.6:27b --verbose dan baca baris eval rate.

Haruskah saya menggunakan Q4 atau Q8 pada VPS yang hanya menggunakan CPU?

Q4_K_M, dalam hampir semua kasus. Q8_0 berukuran 30 GB dibandingkan dengan 17 GB, sehingga membutuhkan paket 64 GB dan memindahkan memori hampir dua kali lipat per token, yang memangkas kecepatan token per detik Anda menjadi sekitar setengahnya. Perbedaan kualitas antara Q4_K_M dan Q8_0 pada model 27B sangat kecil untuk sebagian besar tugas. Gunakan RAM tersebut untuk konteks yang lebih panjang, karena hal itu mengubah kemampuan model daripada sekadar cara model menyusun kalimat.

Kapan menyewa GPU lebih murah daripada VPS dengan RAM besar?

Saat siklus kerja Anda rendah atau saat ada pengguna yang menunggu. GPU dengan memori 24 GB mencapai sekitar 59 token per detik pada bobot ini, dibandingkan dengan 2 atau 3 pada VPS standar, dan biayanya hanya dihitung per jam saat digunakan. VPS 64 GB menagih biaya sepanjang bulan terlepas dari apakah model dimuat atau tidak. Hitung berapa jam sehari Anda benar-benar menghasilkan token. Di bawah dua atau tiga jam, sewa GPU per jam biasanya lebih unggul baik dari segi kecepatan maupun biaya. Pekerjaan batch prioritas rendah yang berkelanjutan adalah kondisi di mana VPS yang selalu aktif lebih unggul.