Cara Jalankan Model Qwen 27B di VPS Menggunakan Ollama

Bolehkah anda menjalankan Qwen 3.8 27B pada VPS tanpa GPU?

Untuk menjalankan Qwen 3.8 27B pada VPS, anda terlebih dahulu memerlukan tag model yang wujud, dan setakat 4 Ogos 2026, pustaka Ollama tidak mempunyai sebarang qwen3.8. Tag 27B yang paling hampir dan telah dikeluarkan ialah qwen3.6:27b: 27.8 bilion parameter, kuantisasi Q4_K_M, lesen Apache 2.0. Setiap arahan dan setiap nombor di bawah menggunakan tag tersebut pada Ollama v0.32.5, yang diterbitkan pada 27 Julai 2026.

Jawapan ringkasnya ialah ya pada VPS bersaiz 32 GB atau lebih besar, namun ia berjalan dengan perlahan. Model padat 27B pada Q4 memerlukan kira-kira 17 GB RAM untuk berat (weights) sahaja, sebelum satu token konteks pun disimpan. Ini menolak pelan 8 GB dan 16 GB sepenuhnya. Pada VPS DDR4 dua saluran yang biasa, hadnya adalah sekitar 3 token sesaat, yang lebih perlahan daripada kelajuan membaca kebanyakan orang.

Dari manakah datangnya angka 3.8? Kemungkinan besar daripada jumlah parameter. Halaman Ollama untuk qwen3.6:27b melaporkan 27.8B parameter, dan 27.8 mudah diingat kemudian sebagai 3.8. Terdapat juga qwen3.5:27b, binaan Q4_K_M yang sama daripada keluaran sebelumnya. Semak senarai langsung sebelum anda menyalin sebarang arahan, di halaman tag Ollama qwen3.6. Jika qwen3.8 yang sebenar dikeluarkan kemudian, pengiraan di sini masih terpakai, kerana ia bergantung pada jumlah parameter dan bit setiap berat dan bukannya pada nombor versi.

Tag Ollama yang perlu ditarik, dan cara menyemaknya

Menarik tag yang tidak wujud akan memberikan ralat yang jelas, jadi perkara ini cepat diselesaikan pada pelayan itu sendiri.

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 seni bina, bilangan parameter, panjang konteks dan kuantisasi untuk tag yang anda miliki sekarang. Jika baris parameter memaparkan 27.8B dan baris kuantisasi memaparkan Q4_K_M, anda mempunyai binaan yang digunakan dalam panduan ini. Pustaka tersebut juga mengandungi qwen3.6:27b-q8_0 dan qwen3.6:27b-bf16 untuk pemberat yang sama pada ketepatan yang lebih tinggi, serta satu set tag 35b-a3b yang merupakan model MoE (mixture of experts) dan berkelakuan sangat berbeza pada CPU. Maklumat lanjut mengenai perkara tersebut ada di bawah.

Kiraan parameter darab bait bagi setiap pemberat

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

Rumus ini terdiri daripada satu baris. Bait bagi pemberat = parameter * bit bagi setiap pemberat / 8. Pada kadar 4 bit yang tepat, 27.8 bilion parameter akan menjadi 13.9 GB. Tag Q4_K_M yang dikeluarkan adalah 17 GB, yang secara praktikalnya menghasilkan 4.89 bit bagi setiap pemberat.

Jurang tersebut bukanlah satu ralat. Format K-quant tidak menyimpan setiap tensor pada lebar nominal. Tensor yang paling banyak kehilangan kualiti akibat pemampatan dikekalkan pada 5 atau 6 bit, manakala lapisan token embedding dan output biasanya dibiarkan pada Q6_K atau Q8_0. Nama pada format tersebut merupakan purata, dan purata tersebut berada pada sekitar 4.9. Kesan yang sama dapat dilihat pada hujung skala yang satu lagi: 56 GB untuk BF16 adalah 16.1 bit bagi setiap pemberat dan bukannya 16 bit rata, kerana fail tersebut juga membawa metadata dan jadual embedding berketepatan penuh.

Q5_K_M tidak mempunyai tag yang diterbitkan untuk model ini, jadi baris 19.8 GB dikira pada kadar biasa 5.7 bit bagi setiap pemberat untuk format tersebut dan bukannya diukur. Q8_0 hampir menggandakan Q4 kepada 30 GB. Pada mesin yang hanya menggunakan CPU, penggandaan tersebut meningkatkan trafik memori bagi setiap token sebanyak dua kali ganda, jadi ia juga secara kasarnya mengurangkan kelajuan token sesaat anda kepada separuh. Atas sebab itulah Q4_K_M merupakan pilihan lalai yang tepat di sini.

Kos cache KV apabila konteks berkembang

Berat model merupakan kos tetap. Cache KV (cache kunci dan nilai, iaitu keadaan perhatian yang disimpan oleh model bagi setiap token yang telah diproses) berkembang secara linear mengikut panjang konteks, dan inilah punca utama kehabisan RAM bagi kebanyakan pengguna.

[
  {
    "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 mengandaikan struktur yang digunakan oleh Qwen dalam model padat terbaharunya bagi kelas saiz ini: 64 lapisan, 8 kepala kunci/nilai di bawah GQA (grouped-query attention), dan dimensi kepala sebanyak 128. Ini menghasilkan 256 KiB bagi setiap token pada f16, iaitu 8 GB pada 32k token dan 32 GB pada 128k. Jangan hanya bergantung pada pengiraan saya; gunakan pengiraan anda sendiri. Muatkan model dan baca lajur SIZE dalam ollama ps, yang melaporkan jumlah berat, cache, dan overhead sebagai satu angka.

Inilah sebabnya konteks 256K pada kad model hanyalah tajuk utama dan bukannya pelan praktikal. Mengisinya pada f16 akan memakan 64 GB cache tambahan selain daripada berat model, pada mesin yang telah pun menggunakan 17 GB untuk berat tersebut. Ollama tidak memberikan tetingkap penuh secara lalai. Ia memuatkan tetingkap yang jauh lebih kecil, dan anda perlu meningkatkannya secara sengaja dengan OLLAMA_CONTEXT_LENGTH. Tingkatkan secara berperingkat dan semak ollama ps selepas setiap perubahan.

Dua tetapan boleh mengurangkan cache sebanyak separuh atau lebih. OLLAMA_KV_CACHE_TYPE=q8_0 menyimpan cache pada 8 bit dan bukannya 16, mengurangkan 32k token daripada 8 GB kepada 4 GB. Ia memerlukan flash attention, jadi tetapkan OLLAMA_FLASH_ATTENTION=1 juga, dan sahkan pengurangan tersebut dalam ollama ps dan bukannya menganggap ia telah diaplikasikan. OLLAMA_NUM_PARALLEL=1 juga sama pentingnya. Ollama boleh melayani beberapa permintaan serentak, dan setiap slot mendapat bahagian konteksnya sendiri, jadi membiarkan kesejajaran (parallelism) pada tetapan lalai akan menggandakan cache yang telah anda bajetkan secara senyap. Jika lebih daripada seorang pengguna akan menggunakan mesin ini, penggandaan itulah punca masalah bermula, dan bilangan pengguna serentak yang boleh dilayani oleh model yang dihoskan sendiri ditentukan oleh slot cache dan kedalaman baris gilir jauh sebelum ia ditentukan oleh bilangan teras (core count).

Kapasiti yang dimuatkan dalam 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 dua nombor tersebut sebagai ribuan token konteks yang dimuatkan bersama pemberat (weights), pada cache f16, di atas VPS Linux tanpa kepala (headless) dengan kira-kira 1.5 GB ruang yang ditinggalkan untuk sistem pengendalian serta sedikit margin tambahan. Sifar bermakna pemberat itu sendiri tidak muat, jadi tiada apa yang boleh dimuatkan.

8 GB dan 16 GB bukanlah kapasiti yang hampir mencukupi. Pemberat 17 GB tidak muat ke dalam RAM 16 GB, dan tiada perubahan tetapan konteks yang boleh mengatasinya. Menambah swap juga tidak akan membantu. Ollama melakukan pemetaan memori (memory-map) pada fail GGUF, jadi sebaik sahaja halaman residen melebihi RAM, kernel akan mula membuang dan membaca semula halaman tersebut, dan setiap token kemudiannya akan menarik gigabait data daripada cakera. Pelayan akan berada pada iowait yang tinggi dan menghasilkan kurang daripada satu token sesaat.

32 GB adalah titik permulaan. Pemberat mengambil 17 GB dan anda mempunyai baki kira-kira 13 GB, yang meliputi sekitar 32k token konteks f16 dengan margin. Pemberat Q8_0 pada 30 GB langsung tidak muat pada tier ini.

64 GB adalah kapasiti yang selesa. Q4 memberikan ruang untuk sekitar 128k token konteks, dan pemberat Q8_0 dimuatkan dengan baki kira-kira 64k token di belakangnya. Sebelum membayar untuk 64 GB bagi mendapatkan Q8, pastikan anda jelas tentang apa yang anda beli: output yang sedikit lebih baik pada separuh kelajuan, di atas mesin yang memang sudah perlahan. Q4 dengan konteks yang lebih panjang adalah pertukaran yang lebih baik untuk hampir semua orang.

Sejauh mana kepantasan inferens CPU pada VPS?

Menjana satu token daripada model padat bermakna membaca setiap pemberat daripada memori sekali. Bukan sebahagian daripadanya. Kesemuanya. Jadi, had kelajuan bukanlah bilangan teras anda, sebaliknya lebar jalur memori dibahagikan dengan saiz pemberat tersebut. Pada Q4, ini bersamaan dengan 17 GB trafik memori bagi setiap 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 had maksimum, bukan ukuran sebenar. Output sebenar biasanya berada pada sekitar 50 hingga 70 peratus daripada angka yang ditunjukkan, kerana kependaman memori dan prefetching yang tidak sempurna bermakna anda tidak akan mencapai kemuncak teori. VPS DDR4-3200 dwi-saluran mempunyai had 3 token sesaat, jadi jangkakan sekitar 2. Kotak DDR5-4800 dwi-saluran mempunyai had 4.5, jadi jangkakan sekitar 3.

Barisan pelayan besar disertakan dengan amaran. Platform EPYC dua belas saluran mempunyai 460.8 GB/s dan had 27.1 token sesaat, tetapi anda tidak menyewa keseluruhan EPYC. Lebar jalur memori ialah sumber seluruh hos yang dikongsi oleh setiap penyewa pada mesin tersebut, jadi bahagian 8 vCPU tidak didatangkan dengan dua belas saluran lebar jalur eksklusif. Panduan yang memfokuskan GPU mengabaikan perkara ini sepenuhnya, dan inilah sebab mengapa dua pelan VPS dengan bilangan vCPU yang sama boleh berbeza sehingga tiga kali ganda pada model yang sama.

Lebih banyak vCPU berhenti membantu lebih awal atas sebab yang sama. Apabila teras meminta data lebih pantas daripada yang boleh dihantar oleh pengawal memori, thread tambahan hanya menambah beban penjadualan dan tiada yang lain. Tetapkan OLLAMA_NUM_THREAD kepada bilangan teras fizikal anda, buat ukuran, kemudian cuba separuh daripada jumlah tersebut. Pada banyak pelan kongsi, tetapan yang lebih rendah adalah lebih pantas.

Pemprosesan prompt berkelakuan berbeza. Prefill, iaitu proses melintasi input anda sebelum token pertama muncul, terikat dengan pengiraan (compute bound) dan bukannya terikat dengan lebar jalur, jadi ia berskala mengikut bilangan teras. Kesan praktikalnya ialah jeda yang lama sebelum output bermula pada prompt yang besar, diikuti oleh kadar perlahan yang stabil seperti di atas. Ukur masa kedua-dua bahagian secara berasingan dengan --verbose, yang mencetak prompt eval rate dan eval rate untuk setiap permintaan.

Jika model padat 27B terlalu perlahan, lihat tag qwen3.6:35b-a3b sebelum berputus asa dengan CPU. Tag tersebut mengaktifkan kira-kira 3 bilion parameter bagi setiap token dan bukannya kesemua 27.8 bilion, jadi trafik memori bagi setiap token berkurangan hampir satu magnitud walaupun fail pada cakera lebih besar. Anda menukar penggunaan RAM untuk kelajuan. Pilihan masa jalan (runtime) juga penting di sini, dan Ollama dan llama.cpp mendedahkan kawalan penalaan CPU yang berbeza ke atas kod inferens asas yang sama.

Bilakah anda perlu menyewa jam GPU

[
  {
    "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 diaplikasikan pada lebar jalur memori GPU yang diterbitkan memberikan kategori jawapan yang berbeza. Kad pengguna 24 GB mempunyai siling sebanyak 59 token sesaat pada pemberat ini. Kad pusat data semasa mencapai 197. Itu bukanlah jurang yang boleh anda tutup dengan melaraskan kiraan thread. Kad tersebut menjalankan memorinya pada 1008 GB/s manakala VPS anda hanya berjalan pada kadar puluhan GB/s.

Oleh itu, tentukan pilihan berdasarkan beban kerja dan bukannya mengikut keutamaan. Inferens CPU adalah jawapan yang tepat apabila kerja bersifat tak segerak (asynchronous) dan tiada sesiapa yang menunggunya: ringkasan timbunan dokumen pada waktu malam, atau tugasan klasifikasi harian yang berjalan semasa anda tidur. Sewa GPU sebaik sahaja ada pengguna yang menunggu output, atau sebaik sahaja permintaan tiba lebih pantas daripada satu setiap 30 saat, kerana kotak yang hanya menggunakan CPU tidak mempunyai ruang untuk pemprosesan kelompok (batching) dan baris gilir akan terus berkembang.

Perbandingan kos tidaklah sejelas yang disangka. VPS 64 GB mengenakan bayaran setiap jam sepanjang bulan sama ada model dimuatkan atau tidak, manakala instans GPU hanya mengenakan bayaran untuk jam yang anda biarkan ia berjalan. Jika penggunaan sebenar anda adalah dua jam sehari, GPU sewaan boleh menjadi lebih pantas dan lebih murah. Tentukan kitaran tugas anda dahulu, kemudian buat penilaian harga. Memilih VPS dengan GPU merangkumi perkara yang perlu diperiksa pada instans itu sendiri, dan vLLM mengatasi Ollama apabila anda melayani permintaan serentak pada GPU kerana ia melakukan pemprosesan kelompok dengan lebih efisien.

Terdapat pilihan ketiga yang sering dilupakan orang. Kekalkan model 27B pada CPU untuk kerja kelompok dan gunakan model API yang dihoskan untuk laluan interaktif. Tiada syarat yang mewajibkan satu model untuk melayani kedua-dua keperluan tersebut.

Pasang Ollama dan ukur keupayaan pelayan anda

Skrip pemasangan yang digunakan adalah skrip rasmi, dan ia menyediakan servis systemd yang berjalan sebagai pengguna ollama khusus.

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

ollama --version sepatutnya memaparkan 0.32.5 atau lebih baharu. Semak free -g sebelum anda memuat turun apa-apa. Jika lajur total pada baris Mem menunjukkan nilai di bawah 32, berhenti di sini dan pilih model yang lebih kecil, kerana memuat turun 17 GB yang tidak boleh dijalankan hanya akan membazirkan masa selama satu jam dan banyak ruang cakera.

Tetapkan pilihan runtime dalam override systemd dan bukannya dalam shell anda. Model tersebut berjalan di dalam servis, jadi ia tidak akan melihat persekitaran 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 ialah ukuran yang anda perlukan. eval rate ialah jumlah token sesaat anda semasa penjanaan. prompt eval rate ialah kelajuan prefill anda. load duration ialah tempoh masa yang diambil untuk membaca pemberat (weights) daripada cakera, itulah sebabnya OLLAMA_KEEP_ALIVE=60m ditetapkan: pada CPU, memuatkan semula 17 GB daripada cakera bagi setiap permintaan menelan kos yang lebih tinggi daripada permintaan itu sendiri.

Semasa model dimuatkan, semak jejak memori daripada terminal kedua.

ollama ps

Lajur SIZE ialah jejak memori sebenar termasuk KV cache, dan ia sepatutnya berada hampir dengan nilai pemberat ditambah dengan baris untuk panjang konteks anda dalam carta KV. Pada 8192 token dengan cache 8-bit, jangkakan sekitar satu gigabait tambahan di atas pemberat, berbanding 2 GB jika cache kekal pada f16. Lajur PROCESSOR sepatutnya memaparkan 100% CPU. Jika ia memaparkan nilai lain, sesuatu telah menuntut GPU dan nombor kelajuan dalam panduan ini tidak menggambarkan keupayaan pelayan anda.

Mod kegagalan dan rentetan tepat yang akan anda lihat

Model enggan dimuatkan. Ollama mencetak satu baris yang menamakan kedua-dua angka tersebut, dalam bentuk model requires more system memory (18.6 GiB) than is available (15.2 GiB). Ini adalah kegagalan yang baik, kerana Ollama melakukan pemeriksaan sebelum melakukan peruntukan dan bukannya membiarkan kernel menyelesaikannya. Kurangkan panjang konteks, tukar kepada tag yang lebih kecil, atau beralih kepada pelan yang lebih besar.

Proses hilang di tengah-tengah jawapan. Pelanggan tidak menunjukkan apa-apa yang berguna, dan journalctl -u ollama -n 50 menunjukkan servis sedang dimulakan semula. Jalankan dmesg -T | tail, dan satu baris yang berbunyi Out of memory: Killed process ... (ollama) bermakna OOM killer kernel telah menamatkannya. Ini berlaku apabila pemeriksaan pra-muat lulus tetapi cache berkembang melebihi anggaran semasa perbualan yang panjang. Kurangkan panjang konteks.

Proses pull gagal serta-merta. Error: pull model manifest: file does not exist bermakna tag tersebut tiada dalam pustaka. Menaip qwen3.8:27b menghasilkan tepat perkara ini, begitu juga dengan sebarang kesilapan taip pada nombor versi. Sahkan tag tersebut pada halaman pustaka sebelum menyalahkan rangkaian anda.

Semuanya berfungsi tetapi sangat perlahan. Kurang daripada satu token sesaat pada kotak yang mempunyai RAM mencukupi menunjukkan paging dan bukannya masalah pengiraan. Jalankan vmstat 1 semasa penjanaan. Lajur si atau so yang bukan sifar bermakna kernel sedang melakukan swapping, dan penyelesaiannya adalah dengan mengurangkan konteks atau mengurangkan bilangan model yang dimuatkan. wa yang tinggi dan stabil tanpa aktiviti swap bermakna pemberat yang dipetakan memori (memory-mapped weights) sedang dibaca semula daripada cakera, yang bermaksud ia sebenarnya tidak muat.

Token pertama mengambil masa 30 saat dan kemudian kelajuan output meningkat. Itu adalah prefill, dan ia adalah perkara biasa. System prompt yang panjang perlu diproses pada setiap permintaan yang terlepas cache, jadi pendekkan system prompt sebelum melaraskan perkara lain.

Kegunaan sebenar model 27B berasaskan CPU

Tetapkan jangkaan berdasarkan angka, bukan harapan. Pada kelajuan dua hingga empat token sesaat, jawapan sepanjang 500 token mengambil masa antara dua hingga empat minit. Ini tidak sesuai untuk perbualan, tetapi sangat praktikal untuk sistem baris gilir (queue). Peringkasan dokumen, pelabelan pukal, pengekstrakan medan daripada timbunan fail, dan semakan kod tanpa pengawasan semuanya boleh menerima kelajuan ini, kerana tiada pengguna yang menunggu jawapan tersebut. Bantuan pengekodan berada tepat pada sempadan ini, jadi menghubungkan ejen pengekodan kepada model yang anda hoskan berbaloi untuk tugasan latar belakang seperti mesej komit dan rangka ujian, tetapi bukan untuk cadangan dalam talian (inline) yang memerlukan anda menunggu.

Hujah privasi adalah faktor yang paling utama. Model ini berjalan pada perkakasan yang anda sewa dan kawal, tiada permintaan keluar dari pelayan, dan tiada bil berdasarkan token. Ini sangat berharga untuk data yang dikawal selia walaupun pada kelajuan tiga token sesaat. Pertimbangkan dengan jujur berbanding alternatif lain: mengehos sendiri model berskala frontier memerlukan perkakasan yang jauh lebih besar, dan model 27B pada CPU adalah titik paling murah pada lengkung tersebut di mana outputnya masih berbaloi untuk dibaca.

Jika ini adalah pemasangan Ollama pertama anda, panduan lengkap untuk menjalankan Ollama pada VPS merangkumi penyediaan servis, API HTTP dan peraturan firewall yang dianggap sudah anda miliki dalam panduan ini. Jangan dedahkan port 11434 kepada internet. Ollama tidak disertakan dengan pengesahan (authentication) tersendiri, jadi sesiapa sahaja yang mencapai port tersebut boleh menggunakan model anda dan membaca prompt anda.

FAQ

Adakah model Qwen 3.8 27B tersedia di Ollama?

Tidak. Setakat 4 Ogos 2026, pustaka Ollama tidak mempunyai namespace qwen3.8. Tag 27B yang wujud ialah qwen3.5:27b dan qwen3.6:27b, kedua-duanya merupakan binaan Q4_K_M bagi model padat 27.8 bilion parameter. Angka 3.8 dalam istilah carian tersebut hampir pasti merujuk kepada jumlah 27.8B parameter yang tersilap ingat sebagai nombor versi. Semak https://ollama.com/library/qwen3.6/tags untuk senarai terkini, dan jalankan pull pada qwen3.6:27b jika anda mahukan keluaran 27B yang paling baharu. Tag yang tidak wujud akan gagal dengan ralat Error: pull model manifest: file does not exist.

Berapa banyak RAM yang diperlukan untuk menjalankan model Qwen 27B pada VPS?

32 GB adalah minimum praktikal untuk Q4_K_M. Berat model adalah 17 GB, sistem pengendalian memerlukan sekitar 1.5 GB, dan cache KV menambah kira-kira 1 GB bagi setiap 4000 token konteks pada f16. Pelan 16 GB tidak dapat memuatkan berat model tersebut sama sekali, dan penggunaan swap tidak membantu kerana fail dipetakan ke memori (memory-mapped) dan kernel akan membaca semula fail tersebut daripada cakera bagi setiap token. 64 GB memberikan ruang untuk konteks yang panjang atau untuk berat model Q8_0 pada 30 GB.

Berapa banyak token sesaat yang akan diberikan oleh model 27B pada CPU?

Bahagikan lebar jalur memori anda dengan saiz berat model, kemudian ambil 50 hingga 70 peratus daripada nilai tersebut. VPS DDR4-3200 dua saluran mempunyai had hampir 3 token sesaat dan memberikan kira-kira 2 token sesaat. Kotak DDR5-4800 dua saluran mempunyai had hampir 4.5 dan memberikan kira-kira 3 token sesaat. Platform pelayan dengan saluran lebih tinggi kelihatan jauh lebih baik di atas kertas, namun lebar jalur memori dikongsi merentasi setiap penyewa pada hos tersebut, jadi ukur prestasi anda sendiri dengan ollama run qwen3.6:27b --verbose dan baca baris eval rate.

Patutkah saya menggunakan Q4 atau Q8 pada VPS CPU sahaja?

Q4_K_M, dalam hampir semua kes. Q8_0 adalah 30 GB berbanding 17 GB, jadi ia memerlukan pelan 64 GB dan ia memindahkan hampir dua kali ganda jumlah memori bagi setiap token, yang mengurangkan kelajuan token sesaat anda kepada separuh. Perbezaan kualiti antara Q4_K_M dan Q8_0 pada model 27B adalah kecil untuk kebanyakan tugas. Gunakan RAM tersebut untuk konteks yang lebih panjang, kerana itu mengubah keupayaan model berbanding cara ia menyusun ayat.

Bilakah menyewa GPU lebih murah daripada VPS RAM besar?

Apabila kitaran tugas anda rendah atau terdapat pengguna yang menunggu. GPU dengan memori 24 GB mencapai kira-kira 59 token sesaat bagi berat model ini, berbanding 2 atau 3 pada VPS biasa, dan ia hanya mengenakan bayaran untuk jam ia beroperasi. VPS 64 GB mengenakan bayaran sepanjang bulan sama ada model dimuatkan atau tidak. Kira berapa jam sehari anda benar-benar menjana token. Di bawah dua atau tiga jam, sewaan GPU setiap jam biasanya lebih berbaloi dari segi kelajuan dan kos. Kerja kelompok berkeutamaan rendah yang berterusan adalah situasi di mana VPS yang sentiasa aktif lebih menguntungkan.