Cara Menjalankan Qwen 3.8 27B di VPS dengan Ollama

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

Untuk menjalankan Qwen 3.8 27B pada VPS, anda perlu menggunakan tag model yang wujud. Setakat 4 August 2026, pustaka Ollama langsung tiada entri qwen3.8. Tag 27B terdekat yang telah dikeluarkan ialah qwen3.6:27b: 27.8 bilion parameter, kuantisasi Q4_K_M dan lesen Apache 2.0. Semua arahan dan nombor di bawah menggunakan tag tersebut pada Ollama v0.32.5, yang diterbitkan pada 27 July 2026.

Jawapan ringkasnya ialah ya, pada VPS dengan RAM 32 GB atau lebih, tetapi prestasinya perlahan. Model padat 27B pada Q4 memerlukan kira-kira 17 GB RAM hanya untuk bobot, sebelum satu token konteks pun disimpan. Oleh itu, pelan 8 GB dan 16 GB tidak mencukupi sama sekali. Pada VPS DDR4 dua saluran yang biasa, hadnya kira-kira 3 token sesaat, iaitu lebih perlahan daripada kadar bacaan kebanyakan orang.

Dari manakah datangnya angka 3.8 itu? Kemungkinan besar daripada bilangan parameter. Halaman Ollama untuk qwen3.6:27b melaporkan 27.8B parameter, dan angka 27.8 mudah diingati kemudian sebagai 3.8. Terdapat juga qwen3.5:27b, iaitu binaan Q4_K_M yang sama daripada keluaran terdahulu. Semak senarai semasa sebelum menyalin sebarang arahan di halaman tag qwen3.6 Ollama. Jika qwen3.8 sebenar dikeluarkan kemudian, pengiraan di sini masih terpakai kerana pengiraan tersebut bergantung pada bilangan parameter dan bit bagi setiap bobot, bukannya nombor versi.

Tag Ollama yang perlu ditarik dan cara menyemaknya

Percubaan menarik tag yang tidak wujud akan menghasilkan ralat yang jelas, jadi perkara ini boleh ditentukan dengan cepat pada pelayan itu sendiri. Tag yang wujud masih mungkin tidak boleh dijalankan secara setempat. Inilah yang sering mengelirukan pengguna apabila menggunakan GLM 5.2, yang disenaraikan dalam pustaka tetapi hanya disediakan melalui 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 seni bina, bilangan parameter, panjang konteks dan kuantisasi bagi tag yang sebenarnya anda miliki. Jika baris parameter memaparkan 27.8B dan baris kuantisasi memaparkan Q4_K_M, anda mempunyai binaan yang digunakan dalam panduan ini. Pustaka itu turut menyediakan qwen3.6:27b-q8_0 dan qwen3.6:27b-bf16 untuk pemberat yang sama pada ketepatan lebih tinggi, serta sekumpulan tag 35b-a3b yang merupakan model MoE (mixture of experts) dan berkelakuan sangat berbeza pada CPU. Perkara ini diterangkan dengan lebih lanjut di bawah.

Bilangan parameter didarab dengan 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"
  }
]

Formulanya terdiri daripada satu baris. Bait pemberat = parameter * bit bagi setiap pemberat / 8. Pada 4 bit tepat, 27.8 bilion parameter bersamaan 13.9 GB. Teg Q4_K_M yang dikeluarkan ialah 17 GB, yang bersamaan dengan 4.89 bit bagi setiap pemberat dalam amalan.

Perbezaan itu bukan ralat. Format kuantiti K tidak menyimpan setiap tensor pada lebar nominal. Tensor yang paling banyak kehilangan kualiti akibat pemampatan disimpan pada 5 atau 6 bit, manakala lapisan embedding token dan output biasanya dibiarkan pada Q6_K atau Q8_0. Nama format itu merujuk kepada purata, dan puratanya hampir kepada 4.9. Kesan yang sama dapat dilihat pada hujung skala yang satu lagi: 56 GB bagi BF16 bersamaan dengan 16.1 bit bagi setiap pemberat, bukannya 16 secara tetap, kerana fail itu turut membawa metadata dan jadual embedding berketepatan penuh.

Q5_K_M tidak mempunyai teg yang diterbitkan untuk model ini, jadi baris 19.8 GB dikira menggunakan 5.7 bit bagi setiap pemberat yang lazim bagi format itu, bukan berdasarkan ukuran. Q8_0 hampir menggandakan Q4 kepada 30 GB. Pada mesin CPU sahaja, penggandaan itu menggandakan trafik memori bagi setiap token, lalu kira-kira mengurangkan separuh kadar token sesaat. Atas sebab itu sahaja, Q4_K_M ialah pilihan lalai yang sesuai di sini. Jika anda ingin memahami aspek kualiti keputusan itu, bukan aspek memori, perbandingan lebih dekat antara Q4, Q8 dan fp16 menunjukkan titik output mula merosot.

Kos cache KV apabila konteks bertambah

Berat model ialah kos tetap. Cache KV (cache key dan value, iaitu keadaan attention yang disimpan oleh model bagi setiap token yang telah dilihat) bertambah secara linear mengikut panjang konteks. Di sinilah kebanyakan pengguna sebenarnya 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 tersebut mengandaikan struktur yang digunakan oleh Qwen pada model dense terbaharunya dalam kelas saiz ini: 64 lapisan, 8 kepala key/value di bawah GQA (grouped-query attention), dan dimensi kepala 128. Jumlahnya ialah 256 KiB bagi setiap token pada f16, iaitu 8 GB pada 32k token dan 32 GB pada 128k. Jangan anggap pengiraan ini tepat untuk mesin anda. Muatkan model dan baca lajur SIZE dalam ollama ps, yang melaporkan jumlah berat model, cache dan overhed sebagai satu angka.

Sebab itu konteks 256K pada kad model ialah angka utama, bukan rancangan penggunaan. Mengisinya pada f16 memerlukan cache sebanyak 64 GB sebagai tambahan kepada berat model, pada mesin yang telah menggunakan 17 GB untuk berat model. Ollama tidak memberikan keseluruhan tetingkap konteks secara lalai. Ia memuatkan tetingkap yang jauh lebih kecil, dan anda membesarkannya dengan sengaja menggunakan OLLAMA_CONTEXT_LENGTH. Pemboleh ubah seluruh pelayan itu bukan satu-satunya kawalan. Menetapkan num_ctx pada permintaan individu membolehkan anda mengekalkan lalai yang menjimatkan untuk semua permintaan lain, sementara satu tugas yang panjang mendapat tetingkap yang lebih besar. Tingkatkannya secara berperingkat dan semak ollama ps selepas setiap perubahan.

Dua tetapan boleh mengurangkan cache kepada separuh atau kurang. OLLAMA_KV_CACHE_TYPE=q8_0 menyimpan cache pada 8 bit dan bukannya 16 bit, lalu mengurangkan penggunaan bagi 32k token daripada 8 GB kepada 4 GB. Tetapan ini memerlukan flash attention, jadi tetapkan OLLAMA_FLASH_ATTENTION=1 juga dan sahkan pengurangan tersebut dalam ollama ps, bukannya menganggapnya telah digunakan. OLLAMA_NUM_PARALLEL=1 sama pentingnya. Ollama boleh menyediakan beberapa permintaan serentak, dan setiap slot mendapat bahagian konteksnya sendiri. Oleh itu, membiarkan parallelism pada nilai lalai akan meningkatkan cache yang anda anggarkan secara senyap. Jika lebih daripada seorang akan menggunakan mesin ini, penggandaan itulah yang biasanya menimbulkan masalah. Bilangan pengguna serentak yang boleh dilayan oleh model self-hosted ditentukan oleh slot cache dan kedalaman baris gilir jauh sebelum ditentukan oleh bilangan teras.

Perkara yang boleh 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 kedua-dua nombor itu sebagai ribuan token konteks yang boleh dimuatkan bersama weights, menggunakan cache f16, pada Linux VPS tanpa antaramuka grafik dengan kira-kira 1.5 GB diperuntukkan kepada sistem pengendalian serta sedikit margin tambahan. Nilai sifar bermaksud weights itu sendiri tidak muat, jadi tiada konteks yang boleh dimuatkan.

8 GB dan 16 GB bukan kes yang hampir mencukupi. 17 GB weights tidak muat dalam RAM 16 GB, dan tiada tetapan konteks yang boleh mengubahnya. Menambah swap juga tidak menyelesaikan masalah ini. Ollama memetakan fail GGUF ke memori, jadi apabila halaman resident melebihi kapasiti RAM, kernel mula mengeluarkan dan membaca semula halaman tersebut. Akibatnya, setiap token perlu membaca gigabait data daripada cakera. Pelayan akan mengalami iowait yang tinggi dan menghasilkan jauh kurang daripada satu token sesaat.

32 GB ialah titik permulaan. Weights menggunakan 17 GB dan terdapat kira-kira 13 GB yang tinggal. Kapasiti ini mencukupi untuk kira-kira 32k token konteks f16 dengan sedikit margin. Weights Q8_0 berukuran 30 GB langsung tidak muat pada tier ini.

64 GB memberikan ruang yang selesa. Q4 menyediakan ruang untuk kira-kira 128k token konteks, manakala weights Q8_0 muat dengan kira-kira 64k token yang masih tersedia. Sebelum membayar RAM 64 GB untuk menggunakan Q8, fahami perkara yang dibeli: output yang sedikit lebih baik pada separuh kelajuan, pada mesin yang sememangnya sudah perlahan. Bagi hampir semua pengguna, Q4 dengan konteks yang lebih panjang ialah pilihan yang lebih baik.

Seberapa pantas inferens CPU pada VPS?

Menjana satu token daripada model padat bermaksud membaca setiap pemberat dari memori sekali. Bukan sebahagian daripadanya. Kesemuanya. Oleh itu, had kelajuan bukan bilangan teras anda, tetapi lebar jalur memori dibahagikan dengan saiz pemberat. Pada Q4, jumlah trafik memori bagi setiap token ialah 17 GB.

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

Itu ialah had teori, bukan ukuran sebenar. Output sebenar biasanya mencapai kira-kira 50 hingga 70 peratus daripada angka tersebut kerana kependaman memori dan prefetching yang tidak sempurna menghalang anda daripada mencapai prestasi puncak teori. VPS DDR4-3200 dua saluran mempunyai had 3 token sesaat, jadi jangkakan kira-kira 2. Sistem DDR5-4800 dua saluran mempunyai had 4.5, jadi jangkakan kira-kira 3.

Baris pelayan yang besar disertakan dengan peringatan. Platform EPYC dua belas saluran mempunyai lebar jalur 460.8 GB/s dan had 27.1 token sesaat, tetapi anda tidak menyewa keseluruhan EPYC. Lebar jalur memori ialah sumber pada peringkat host yang dikongsi oleh setiap penyewa pada mesin tersebut. Oleh itu, slice 8 vCPU tidak disertakan dengan lebar jalur eksklusif dua belas saluran. Panduan yang berfokuskan GPU biasanya mengabaikan perkara ini. Inilah sebabnya dua pelan VPS dengan bilangan vCPU yang sama boleh berbeza sebanyak tiga kali ganda untuk model yang sama.

Menambah vCPU juga tidak membantu untuk tempoh yang lama atas sebab yang sama. Sebaik sahaja teras meminta data lebih pantas daripada kadar penghantaran pengawal memori, thread tambahan hanya menambah overhed penjadualan tanpa manfaat lain. Tetapkan OLLAMA_NUM_THREAD kepada bilangan teras fizikal anda, buat pengukuran, kemudian cuba separuh daripada jumlah tersebut. Pada banyak pelan yang dikongsi, tetapan yang lebih rendah adalah lebih pantas.

Pemprosesan prompt berkelakuan secara berbeza. Prefill, iaitu proses melalui input anda sebelum token pertama muncul, terikat pada pengiraan dan bukannya lebar jalur. Oleh itu, prestasinya meningkat mengikut bilangan teras. Kesan praktikalnya ialah jeda yang panjang sebelum output bermula apabila prompt besar digunakan, kemudian kadar stabil yang perlahan seperti di atas. Ukur kedua-dua bahagian secara berasingan dengan --verbose. Perintah ini mencetak prompt eval rate dan eval rate bagi setiap permintaan.

Jika model padat 27B terlalu perlahan, periksa tag qwen3.6:35b-a3b sebelum berputus asa menggunakan CPU. Tag tersebut mengaktifkan kira-kira 3 bilion parameter bagi setiap token, bukannya kesemua 27.8 bilion parameter. Oleh itu, trafik memori bagi setiap token berkurang hampir satu susunan magnitud, walaupun fail pada cakera lebih besar. Anda menukar jejak RAM untuk kelajuan. Pilihan runtime juga penting di sini, dan Ollama dan llama.cpp mendedahkan kawalan penalaan CPU yang berbeza untuk kod inferens asas yang sama.

Bila perlu menyewa GPU mengikut 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
  }
]

Formula yang sama apabila digunakan pada lebar jalur memori GPU yang diterbitkan menghasilkan jawapan dalam kategori yang berbeza. Kad pengguna 24 GB mempunyai had maksimum 59 token sesaat untuk pemberat ini. Kad pusat data semasa mencapai 197. Jurang ini tidak dapat diatasi hanya dengan melaraskan bilangan thread. Kad tersebut menjalankan memori pada 1008 GB/s, manakala VPS anda hanya mencapai puluhan GB/s.

Oleh itu, tentukan had berdasarkan beban kerja, bukan keutamaan. Inferens CPU ialah pilihan yang tepat apabila kerja berjalan secara tak segerak dan tiada sesiapa menunggu hasilnya: membuat ringkasan sekumpulan dokumen semalaman atau menjalankan tugas pengelasan setiap malam semasa anda tidur. Sewa GPU sebaik sahaja seseorang menunggu output, atau apabila permintaan tiba lebih kerap daripada sekali setiap 30 saat. Komputer yang hanya menggunakan CPU tidak mempunyai ruang untuk batching, lalu baris gilir terus bertambah.

Perbandingan kos tidak semudah yang disangka. VPS 64 GB mengenakan caj setiap jam sepanjang bulan, sama ada model dimuatkan atau tidak, manakala instance GPU hanya mengenakan caj bagi jam anda menggunakannya. Jika penggunaan sebenar anda ialah dua jam sehari, GPU yang disewa boleh menjadi lebih pantas dan lebih murah. Kira dahulu kitar tugas anda, kemudian bandingkan harganya. Memilih VPS dengan GPU menerangkan perkara yang perlu diperiksa pada instance itu sendiri, manakala vLLM mengatasi Ollama selepas anda menyediakan permintaan serentak pada GPU kerana vLLM mengumpulkannya dengan betul.

Terdapat pilihan ketiga yang sering dilupakan. Kekalkan model 27B pada CPU untuk kerja batch dan letakkan model API yang dihoskan di hadapan laluan interaktif. Tiada keperluan untuk satu model melayani kedua-dua kegunaan.

Pasang Ollama dan ukur pelayan anda sendiri

Skrip pemasangan ini ialah skrip rasmi, dan skrip tersebut menyediakan servis systemd yang berjalan sebagai pengguna khusus ollama.

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

ollama --version sepatutnya memaparkan 0.32.5 atau versi yang lebih baharu. Semak free -g sebelum anda menarik apa-apa kandungan. Jika lajur total pada baris Mem menunjukkan nilai di bawah 32, berhenti di sini dan pilih model yang lebih kecil. Menarik model berukuran 17 GB yang tidak dapat anda jalankan hanya membazirkan masa sejam dan ruang cakera yang banyak.

Tetapkan pilihan runtime dalam override systemd, bukan dalam shell anda. Model berjalan di dalam servis, jadi model tidak menerima 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 bilangan token sesaat semasa penjanaan. prompt eval rate ialah kelajuan prefill anda. load duration ialah tempoh yang diperlukan untuk membaca weights daripada cakera. Oleh itu, OLLAMA_KEEP_ALIVE=60m ditetapkan: pada CPU, memuatkan semula 17 GB daripada cakera bagi setiap permintaan mengambil masa lebih lama daripada memproses permintaan itu sendiri. Nilai tamat masa idle lalai ialah lima minit. Tempoh ini cukup singkat sehingga baris gilir batch yang mempunyai jarak antara item akan menanggung kos pemuatan tersebut berulang kali. Pilihan untuk mengekalkan model dalam memori merangkumi kedua-dua medan keep_alive bagi setiap permintaan dan cara mengekalkan tetapan itu selepas reboot.

Semasa model dimuatkan, semak penggunaan sumbernya dari terminal kedua.

ollama ps

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

Mod kegagalan dan rentetan tepat yang akan anda lihat

Model enggan dimuatkan. Ollama mencetak satu baris yang menamakan kedua-dua angka, dalam bentuk model requires more system memory (18.6 GiB) than is available (15.2 GiB). Ini ialah kegagalan yang baik kerana Ollama membuat semakan sebelum memperuntukkan memori, bukannya membiarkan kernel menanganinya. Kurangkan panjang konteks, gunakan tag yang lebih kecil atau beralih kepada pelan yang lebih besar.

Proses hilang semasa menjana jawapan. Klien tidak memaparkan maklumat yang berguna, manakala journalctl -u ollama -n 50 menunjukkan servis dimulakan semula. Jalankan dmesg -T | tail. Baris yang berbunyi Out of memory: Killed process ... (ollama) bermakna kernel OOM killer telah menghentikannya. Ini berlaku apabila semakan pramuat berjaya, tetapi cache berkembang melebihi anggaran semasa perbualan yang panjang. Kurangkan panjang konteks.

Operasi pull gagal serta-merta. Error: pull model manifest: file does not exist bermakna tag itu tiada dalam library. Menjalankan qwen3.8:27b menghasilkan mesej ini dengan tepat, begitu juga sebarang kesilapan menaip pada nombor versi. Sahkan tag pada halaman library sebelum menyalahkan rangkaian anda.

Semuanya berfungsi tetapi sangat perlahan. Kelajuan kurang daripada satu token sesaat pada pelayan yang mempunyai RAM mencukupi menunjukkan paging, bukannya masalah pengiraan. Jalankan vmstat 1 semasa model menjana output. Nilai bukan sifar dalam lajur si atau so bermakna kernel sedang menggunakan swap. Penyelesaiannya ialah mengurangkan konteks atau bilangan model yang dimuatkan. Nilai wa yang sentiasa tinggi tanpa aktiviti swap bermakna weight yang dipetakan ke memori sedang dibaca semula dari cakera. Ini menunjukkan weight tersebut sebenarnya tidak muat dalam memori.

Token pertama mengambil masa 30 saat, kemudian output menjadi lebih pantas. Itu ialah prefill dan keadaan ini normal. Prompt sistem yang panjang perlu diproses semula bagi setiap permintaan yang tidak menggunakan cache. Oleh itu, pendekkan prompt sistem sebelum melaraskan perkara lain.

Kegunaan sebenar 27B yang berjalan pada CPU sahaja

Tetapkan jangkaan berdasarkan angka, bukan harapan. Pada kelajuan dua hingga empat token sesaat, jawapan 500 token mengambil masa antara dua hingga empat minit. Kelajuan ini tidak sesuai untuk sembang, tetapi boleh digunakan dengan baik untuk baris gilir tugas. Model yang berfikir sebelum menjawab menjadikan pengiraan itu lebih lambat kerana token penaakulan tersembunyi dijana pada kadar perlahan yang sama seperti jawapan. Oleh itu, memadankan tahap usaha penaakulan dengan tugas ialah salah satu daripada beberapa cara untuk memendekkan jawapan tanpa menukar model. Ringkasan dokumen, penandaan pukal, pengekstrakan medan daripada timbunan fail dan semakan kod tanpa pengawasan masih sesuai kerana tiada sesiapa menunggu jawapan. Bantuan pengekodan berada tepat pada had itu. Oleh itu, menghalakan ejen pengekodan kepada model yang anda hoskan berbaloi untuk tugas latar seperti mesej commit dan rangka kod ujian, tetapi bukan untuk cadangan sebaris yang perlu anda tunggu.

Hujah privasi ialah faktor sebenar. Model berjalan pada perkakasan yang anda sewa dan kawal. Tiada permintaan meninggalkan pelayan itu dan tiada caj bagi setiap token. Ini sangat bernilai untuk data terkawal walaupun pada kelajuan tiga token sesaat. Bandingkan secara jujur dengan pilihan lain: self-hosting model berskala frontier memerlukan perkakasan yang lebih banyak mengikut satu tertib magnitud, manakala 27B pada CPU ialah titik paling murah pada lengkung itu yang outputnya masih berbaloi untuk dibaca.

Untuk menanda aras semua itu, anda memerlukan input berstruktur sebenar. Kebanyakan API data awam pula memerlukan akaun sebelum anda boleh mengukur throughput. Endpoint demo Strasmore (kami yang menjalankannya) menjawab SQL baca sahaja terhadap data pasaran AS selama 22 tahun tanpa key dan tanpa pendaftaran. GET kepada https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 mengembalikan JSON yang boleh terus disalurkan ke gelung prompt, bersama SQL tepat yang menghasilkannya. Dengan itu, model mempunyai bahan untuk diringkaskan dan hasilnya boleh anda semak secara bebas. Hadnya ialah 500 baris dan 20 saat bagi setiap panggilan. Had ini lebih daripada mencukupi untuk pelayan pada kelajuan dua token sesaat. Senarai lajur penuh tersedia di https://api.strasmore.com/v1/schema.

Jika ini ialah pemasangan Ollama pertama anda, panduan lengkap untuk menjalankan Ollama pada VPS menerangkan persediaan servis, HTTP API dan peraturan firewall yang diandaikan oleh panduan ini telah anda sediakan. Jangan dedahkan port 11434 kepada internet. Ollama tidak menyediakan pengesahan sendiri. Oleh itu, apa-apa yang mencapai port tersebut boleh menggunakan model anda dan membaca prompt anda.

FAQ

Adakah model Qwen 3.8 27B di Ollama?

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

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

32 GB ialah minimum yang praktikal untuk Q4_K_M. Berat model ialah 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 langsung tidak dapat memuatkan berat model, manakala swap tidak membantu kerana fail itu dipetakan ke memori dan kernel hanya membacanya semula dari cakera bagi setiap token. 64 GB memberikan ruang untuk konteks panjang atau berat Q8_0 berukuran 30 GB.

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

Bahagikan lebar jalur memori dengan saiz berat model, kemudian ambil 50 hingga 70 peratus daripada hasil itu. VPS DDR4-3200 dua saluran mempunyai had hampir 3 token sesaat dan menghasilkan kira-kira 2. Sistem DDR5-4800 dua saluran mempunyai had hampir 4.5 dan menghasilkan kira-kira 3. Platform pelayan dengan lebih banyak saluran kelihatan jauh lebih baik secara teori, tetapi lebar jalur memori dikongsi oleh setiap tenant pada hos. Oleh itu, ukur sistem 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 keadaan. Q8_0 ialah 30 GB berbanding 17 GB, jadi ia memerlukan pelan 64 GB dan memindahkan hampir dua kali ganda memori bagi setiap token. Ini mengurangkan token sesaat anda kira-kira separuh. Perbezaan kualiti antara Q4_K_M dan Q8_0 pada model 27B adalah kecil bagi kebanyakan tugas. Gunakan RAM itu untuk konteks yang lebih panjang kerana perkara tersebut mengubah keupayaan model, bukan cara model merumuskan ayat.

Bilakah menyewa GPU lebih murah berbanding VPS dengan RAM yang besar?

Apabila kitar tugas anda rendah atau seseorang sedang menunggu. GPU dengan memori 24 GB mencapai kira-kira 59 token sesaat untuk berat model ini, berbanding 2 atau 3 pada VPS biasa, dan caj hanya dikenakan untuk jam penggunaannya. VPS 64 GB mengenakan caj sepanjang bulan sama ada model dimuatkan atau tidak. Kira jumlah jam sehari yang benar-benar diperlukan untuk menjana token. Jika kurang daripada dua atau tiga jam, sewaan GPU mengikut jam biasanya lebih baik dari segi kelajuan dan kos. Kerja kelompok berkeutamaan rendah yang berjalan berterusan ialah keadaan yang memihak kepada VPS yang sentiasa aktif.