Ollama atau llama.cpp untuk VPS CPU sahaja?

Ollama berbanding llama.cpp: lapisan yang manakah anda mahu jalankan?

Ollama dan llama.cpp bukan pesaing seperti yang tersirat dalam soalan itu. llama.cpp ialah enjin inferens: ia memuatkan fail model dan menukarkan prompt kepada token. Ollama ialah pengurus model, daemon latar belakang dan API HTTP yang berjalan di atas enjin tersebut. README Ollama masih menyenaraikan llama.cpp sebagai backend inferensnya (disemak pada 2 August 2026). Jadi, persoalan sebenar ialah lapisan yang manakah anda mahu kendalikan pada VPS anda, bukannya yang mana lebih pantas.

Jalankan Ollama apabila anda mahu servis yang mengambil model mengikut nama dan terus berfungsi tanpa pemantauan berterusan. Jalankan llama.cpp secara terus apabila pelayan itu kecil dan anda perlu memilih fail model, saiz konteks serta bilangan thread yang tepat, kerana pada VPS kecil setiap tetapan tersebut menggunakan memori yang terhad.

Apakah sebenarnya setiap projek ini

llama.cpp ialah pelaksanaan inferens transformer dalam C dan C++ yang dibina berasaskan pustaka ggml. Ia membaca fail GGUF. GGUF (GGML universal file format) ialah bekas satu fail yang mengandungi pemberat, tokenizer dan metadata yang diperlukan oleh enjin untuk menjalankan model. Projek ini menyediakan binari berasingan untuk tugas yang berbeza. llama-server ialah pelayan HTTP, llama-cli ialah gesaan interaktif dan llama-bench mengukur daya pemprosesan. Keluaran ditandai mengikut nombor binaan, bukan versi semantik. Tag semasa ialah b10224, diterbitkan pada 2 Ogos 2026, dan tag baharu biasanya dikeluarkan pada kebanyakan hari bekerja.

Ollama ialah program Go. Daemon latar belakang yang dimulakan dengan ollama serve memuatkan model dan menjawab permintaan HTTP, manakala klien baris perintah berkomunikasi dengan daemon itu. Di belakang kedua-duanya terdapat registry di ollama.com yang menyimpan model yang telah dipakejkan. Ollama menggunakan versi semantik dan v0.32.5 dikeluarkan pada 27 Julai 2026. ollama pull memuat turun GGUF bersama templat prompt dan set parameter lalai, kemudian menyimpannya di bawah /usr/share/ollama/.ollama/models pada Linux. Fail tersebut berada pada cakera root dan setiap satunya boleh mencapai beberapa gigabait. Oleh itu, pada VPS dengan volum root 25 GB, anda wajar mengetahui apa yang ditinggalkan oleh pull dan cara memindahkan direktori model ke lokasi lain sebelum muat turun ketiga memenuhi ruang cakera.

Itulah keseluruhan perbezaannya. Ollama menentukan kuantisasi, templat dan panjang konteks untuk anda, serta memberikan satu nama untuk diingati. llama.cpp tidak menentukan apa-apa dan memberikan anda flags.

Paksi 1: kawalan model dan pengkuantuman

Pengkuantuman mengecilkan setiap pemberat daripada 16 atau 32 bit kepada 4, 5 atau 8 bit. Inilah yang membolehkan model dengan 8 bilion parameter dimuatkan dalam RAM VPS biasa. Penamaan GGUF mudah dibaca apabila anda mengetahui polanya: Q4_K_M bermaksud kuantum K 4 bit dengan saiz sederhana. Nombor yang lebih tinggi mengekalkan lebih banyak ketepatan dan menggunakan lebih banyak memori.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Itulah saiz fail yang diterbitkan dalam repositori bartowski/Meta-Llama-3.1-8B-Instruct-GGUF di Hugging Face, dibaca pada 2 August 2026 dan ditukar daripada bait kepada GiB. Terdapat 6 binaan untuk satu model, dan yang paling kecil ialah 2.96 GiB berbanding 7.95 GiB untuk yang paling besar. Pilihan lalai yang biasa, Q4_K_M, ialah 4.58 GiB. Pada VPS 4 GiB, pilihan itu sahaja menentukan sama ada model dapat dimuatkan. Saiz hanya separuh daripada keputusan itu kerana baris yang mampu anda gunakan tidak semestinya berbaloi digunakan, dan kos sebenar Q4, Q8 dan fp16 terhadap kualiti jawapan menentukan sama ada gigabait tambahan itu memberikan peningkatan yang dapat anda lihat.

Dengan llama.cpp, anda menyatakan nama fail, jadi anda sendiri memilih baris tersebut.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c ialah saiz konteks dalam token, -t ialah bilangan thread, dan -ngl menetapkan bilangan lapisan yang dipindahkan ke GPU (0 pada mesin CPU sahaja). Tiada apa-apa yang dianggarkan untuk anda.

Dengan Ollama, kuantuman disertakan bersama tag yang anda tarik, dan ollama ls menunjukkan kandungan sebenar pada cakera. Apabila registry tidak menyediakan binaan yang anda mahu, import sendiri GGUF. Tulis Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Kemudian bina dan semak hasilnya:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Panjang konteks ialah tetapan yang sering menyebabkan masalah. Ollama memilih nilai lalai berdasarkan VRAM yang tersedia, dan mesin tanpa GPU menggunakan kumpulan paling kecil: 4096 token. Jika anda menghantar dokumen 20,000 token kepadanya, token tambahan dibuang sebelum model melihatnya. Akibatnya, jawapan boleh kelihatan yakin tetapi salah tentang fail yang hanya dibaca separuh oleh model. Tingkatkan nilai itu dengan OLLAMA_CONTEXT_LENGTH pada daemon, atau dengan PARAMETER num_ctx dalam Modelfile. Jika hanya satu tugas memerlukan tetingkap yang lebih besar, num_ctx boleh ditetapkan bagi setiap permintaan dan bukannya untuk seluruh pelayan, supaya cache tambahan tidak digunakan oleh tugasan lain yang diproses oleh daemon. llama.cpp juga tidak mempunyai nilai lalai yang boleh dipercayai. Tetapkan -c secara eksplisit supaya anda mengetahui nilai yang digunakan.

Aritmetik memori yang jarang ditunjukkan

Fail model bukan satu-satunya kos. Cache KV (cache kunci/nilai) menyimpan satu entri bagi setiap lapisan untuk setiap token dalam konteks, dan saiznya bertambah apabila perbualan berkembang.

Kira untuk Llama 3.1 8B. Model ini mempunyai 32 lapisan, 8 kepala kunci/nilai dan dimensi kepala 128. Setiap token menyimpan kunci dan nilai, masing-masing pada 2 bait dalam f16, jadi 2 x 8 x 128 x 2 = 4096 bait bagi setiap lapisan. Merentas 32 lapisan, jumlahnya ialah 128 KiB bagi setiap token. Konteks 4096 token oleh itu memerlukan 512 MiB, manakala konteks 32,768 token memerlukan 4 GiB.

Jadi, model Q4_K_M 8B dengan konteks 4k memerlukan kira-kira 4.58 GiB untuk pemberat, ditambah kira-kira 0.5 GiB untuk cache serta runtime itu sendiri. Ia tidak muat dalam RAM 4 GiB. Ia muat dalam 8 GiB dengan ruang yang mencukupi untuk beroperasi. Jika konteks dinaikkan kepada 32k pada mesin 8 GiB yang sama, cache sahaja akan menggunakan semua ruang lebihan. Pantau penggunaan secara langsung dengan free -h semasa model dimuatkan, dan jangan percaya anggaran yang tidak diukur. Jika anda membuat anggaran untuk model yang jauh melebihi 8B, pengiraan yang sama bagi model 27B pada VPS CPU sahaja menunjukkan kapasiti sebenar setiap peringkat dari 8 hingga 64 GB.

Ollama menggandakan kesannya. OLLAMA_NUM_PARALLEL ditetapkan kepada 1 secara lalai, dan memori yang diperlukan oleh model meningkat mengikut hasil darab nilai itu dengan panjang konteks. Jika kedua-duanya dinaikkan serentak, daemon secara senyap-senyap meminta RAM beberapa kali ganda daripada jangkaan anda. Pengiraan yang sama juga menetapkan had pengguna serentak, kerana setiap permintaan serentak memerlukan bahagian cache KV sendiri. Inilah sebab pelayan yang lancar untuk seorang pengguna tersekat apabila digunakan oleh lima orang.

Paksi 2: daemon yang perlu anda kendalikan

Skrip pemasangan Ollama menulis unit systemd, mencipta pengguna sistem ollama dan mendayakan servis tersebut. Anda mendapat pengurusan kitar hayat tanpa perlu menulis semua konfigurasi itu sendiri. Konfigurasi dilakukan melalui systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE lebih penting pada VPS CPU berbanding persekitaran lain. Model disimpan dalam memori selama 5 minit secara lalai, kemudian dinyahmuat. Permintaan seterusnya perlu membaca semula seluruh fail daripada cakera sebelum dapat memberikan jawapan. Oleh itu, pemuatan semula fail berukuran 4.58 GiB boleh mengubah masa jawapan daripada dua saat kepada tiga puluh saat pada storan yang perlahan. Nilai keep-alive yang panjang menghapuskan kelewatan ini, tetapi menggunakan RAM secara berterusan. Kedua-duanya ialah kos sebenar. Pilih pilihan yang kurang menjejaskan sistem. Jika anda mahu model kekal berada dalam memori, menetapkan keep_alive supaya model kekal aktif semasa tempoh tidak aktif dan selepas reboot hanya memerlukan beberapa baris serta mengelakkan anda memanaskan model secara manual setiap kali pelayan dimulakan semula.

llama.cpp tidak menyediakan daemon. Oleh itu, anda perlu menulis unit tersebut sendiri sebagai /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Dayakannya dengan sudo systemctl enable --now llama-server. Proses itu kemudian mengekalkan model sepanjang kitar hayatnya. Model tidak dinyahmuat ketika tidak aktif. Ini mengelakkan pemuatan semula yang tidak dijangka, tetapi anda tidak dapat mendapatkan semula memori tanpa menghentikan servis. Jika anda masih baharu dalam penulisan unit, coraknya sama seperti menjalankan servis sendiri di bawah systemd pada VPS.

Paksi 3: API yang akan digunakan oleh aplikasi anda

Paksi ini telah mengecil dengan ketara. Kedua-dua projek kini menyokong format chat OpenAI, jadi kebanyakan pustaka klien boleh digunakan dengan mana-mana satu projek selepas hanya menukar URL asas.

Ollama mendengar pada 127.0.0.1:11434. Laluan yang serasi dengan OpenAI ialah http://localhost:11434/v1/chat/completions, dan Ollama turut menyediakan API natif pada /api/chat. Laluan yang serasi dengan Anthropic juga didokumenkan.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server mendengar pada 127.0.0.1:8080 dan menyediakan /v1/chat/completions, /v1/completions dan /v1/embeddings, selain endpoint /completion sendiri serta UI web terbina dalam. Ia juga menyediakan laluan operasi yang tiada pada Ollama: /health untuk probe kesediaan, /props untuk tetapan model yang dimuatkan, /slots untuk menunjukkan tindakan setiap slot permintaan, dan /metrics dalam format Prometheus. Jika anda merancang untuk memantau servis ini, perbezaan tersebut mungkin menjadi faktor penentu.

Tiada satu pun pelayan ini mengaktifkan pengesahan untuk anda. Kedua-duanya menggunakan loopback secara lalai atas sebab yang munasabah. Aksesnya melalui tunnel SSH atau dari belakang reverse proxy, dan jangan sekali-kali membuka port 11434 atau 8080 kepada internet.

Perkara yang boleh dilakukan dengan jujur oleh VPS CPU sahaja

VPS CPU sahaja boleh menjalankan model kecil dengan perlahan. Itulah ringkasan yang jujur. Perkara yang penting ialah mengetahui hadnya. Buat pengukuran sebelum mereka bentuk apa-apa yang bergantung padanya:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Lajur pp ialah kelajuan pemprosesan prompt dan lajur tg ialah kelajuan penjanaan token. Kedua-duanya diukur dalam token sesaat. Pada pelan vCPU dikongsi, model 8B pada Q4_K_M biasanya mencapai kelajuan rendah, iaitu beberapa token sesaat sahaja, untuk tg. Pemprosesan prompt ialah bahagian yang paling membebankan: keseluruhan prompt diproses sebelum token output pertama muncul. Oleh itu, system prompt yang panjang menambah masa menunggu pada setiap permintaan. Panjang balasan ialah bahagian kos yang boleh anda kawal, kerana pada kelajuan tiga token sesaat, model yang menghasilkan 600 token akan menggunakan VPS itu selama tiga minit. Oleh itu, mengehadkan output dengan num_predict ialah cara paling murah untuk mengelakkan satu balasan yang terlalu panjang daripada menyebabkan timeout.

Boleh digunakan pada CPU: model 1B hingga 4B untuk klasifikasi, pengekstrakan, ringkasan pendek atau penghalaan. Balasan diterima dalam beberapa saat dan penggunaan memori sesuai dengan pelan biasa. Untuk contoh terperinci pada saiz tersebut, bukannya julat saiz, Nemotron 3.5 Lightning yang dimuat turun dan diukur pada VPS memberikan tag tepat, jumlah RAM yang sebenarnya diperlukan dan kelajuan yang dicapainya tanpa GPU. Tidak sesuai digunakan pada CPU: chat interaktif pada kelajuan membaca, pembantu pengekodan, pemprosesan dokumen panjang atau apa-apa yang mempunyai gelung ejen yang membuat banyak panggilan secara berturutan. Gelung yang membuat dua belas panggilan dengan masa empat saat setiap satu mengambil masa seminit sebelum menghasilkan apa-apa. Jika pembantu pengekodan memang diperlukan, menetapkan ejen kepada model yang dihoskan sendiri menerangkan tugas yang benar-benar dapat dilakukan oleh model tempatan kecil dan tugas yang perlu kekal pada API yang dihoskan.

Terdapat dua pilihan apabila angka tersebut tidak memadai. Jika masalahnya ialah keserentakan, iaitu ramai pengguna mengakses satu model pada masa yang sama, pilihan enjin perlu diubah. Perbandingan Ollama dengan vLLM untuk penyajian serentak menerangkan perkara tersebut. Jika masalahnya ialah kelajuan mentah, jawapannya ialah VPS dengan GPU yang dipasang, apabila -ngl mula memberikan makna. Sebelum memilih mana-mana pilihan itu, dapatkan garis dasar untuk perkakasan itu sendiri, kerana lebar jalur cakera dan memori turut mempengaruhi masa pemuatan, sama seperti CPU. Penanda aras VPS yang boleh diulang berbaloi dilakukan selama sejam.

Pasang llama.cpp dengan binaan yang ditetapkan

Kedua-dua projek berubah setiap minggu. Oleh itu, catat versi yang anda gunakan. One-liner huluan memasang binaan semasa:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Untuk menetapkan binaan tertentu, gunakan tarball prabina daripada halaman releases. Binaan b10224 ialah tag semasa pada 2 August 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Atau bina tag yang sama daripada kod sumber:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev ialah dependency yang didokumenkan untuk ciri HTTPS. Proses kompilasi mengambil masa beberapa minit dan memerlukan lebih banyak RAM daripada yang disediakan oleh pelan paling kecil. Oleh itu, lakukan binaan pada mesin yang lebih besar dan salin binari jika mesin kecil tidak mempunyai RAM yang mencukupi.

Pasang Ollama dengan versi yang ditetapkan

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Skrip ini membaca OLLAMA_VERSION. Dengan itu, anda boleh mengekalkan keluaran yang diketahui stabil tanpa mengambil keluaran yang baru diterbitkan pagi ini. v0.32.5 diterbitkan pada 27 July 2026. Terdapat juga kaedah manual jika anda tidak mahu menyalurkan skrip terus ke shell:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Kaedah manual tidak mencipta unit systemd atau pengguna servis. Oleh itu, anda perlu menciptanya sendiri. Panduan lengkap Ollama pada VPS menerangkan langkah persediaan servis tersebut.

Mod kegagalan dan rentetan yang akan anda lihat

Ollama enggan memuatkan model. ollama run mengembalikan baris dalam bentuk ini:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama menyemak saiz sebelum memuatkan model, lalu gagal dengan cepat dan menyatakan sebabnya. Turunkan satu baris kuantisasi, kurangkan panjang konteks atau pilih model yang lebih kecil.

llama.cpp tidak gagal, tetapi menjadi sangat perlahan. Secara lalai, llama.cpp memetakan GGUF ke memori menggunakan memory mapping, jadi fail yang lebih besar daripada RAM masih boleh dimulakan. Kernel kemudian membaca masuk dan mengeluarkan weight dari disk untuk setiap token, lalu penjanaan mengambil masa beberapa saat bagi setiap token dengan penggunaan disk pada 100 peratus. Hantar --no-mmap untuk memaksa peruntukan sebenar supaya proses gagal serta-merta dan bukannya merosot prestasinya. Apabila kernel campur tangan, dmesg menunjukkan sebabnya:

Out of memory: Killed process 1234 (llama-server)

Fail model langsung tidak boleh dimuatkan. GGUF yang dibina untuk keluarga model yang lebih baharu daripada engine anda akan menghasilkan ralat yang menyatakan architecture yang tidak dikenalinya:

error loading model architecture: unknown model architecture: 'qwen3next'

Penyelesaiannya ialah menaik taraf engine, bukan menggunakan fail lain. Inilah kos pinning, dan sebabnya anda perlu mencatat nombor build. Anda perlu tahu versi asal yang sedang anda naik taraf.

API memberikan respons secara setempat tetapi bukan dari aplikasi anda. Ollama mengikat 127.0.0.1:11434, jadi host lain menerima ralat connection refused. Tetapkan OLLAMA_HOST=0.0.0.0:11434 melalui systemctl edit ollama hanya apabila port itu berada di belakang firewall atau rangkaian peribadi, kerana API tersebut tidak mempunyai authentication di hadapannya.

Respons pertama selepas jeda sangat perlahan. Model telah dinyahmuat selepas tidak aktif selama 5 minit dan sedang dibaca semula dari disk. ollama ps yang dijalankan sejurus sebelum permintaan tidak menunjukkan apa-apa yang dimuatkan, dan ini mengesahkannya. Tingkatkan OLLAMA_KEEP_ALIVE.

Jadi, yang manakah patut anda jalankan?

Jalankan Ollama apabila anda mahu model diuruskan secara automatik dan endpoint yang menyerupai OpenAI tanpa kerja tambahan. Ini ialah pilihan lalai yang sesuai untuk deployment pertama serta untuk keadaan apabila pilihan model akan kerap berubah.

Jalankan llama.cpp secara terus apabila memori cukup terhad sehingga anda perlu memilih baris kuantisasi sendiri, apabila anda mahu /health, /slots dan /metrics untuk pemantauan, atau apabila anda memerlukan flag yang tidak didedahkan oleh Ollama. Ini ialah pilihan yang tepat pada VPS apabila model hanya muat dengan sedikit lebihan ruang, kerana tetapan yang membolehkannya dimuatkan ialah tetapan yang dipilih oleh Ollama bagi pihak anda.

Menjalankan kedua-duanya ialah perkara biasa. Gunakan Ollama untuk eksperimen dan llama.cpp untuk satu-satunya model yang anda letakkan dalam production dan tidak mahu berubah.

FAQ

Adakah Ollama hanya pembalut untuk llama.cpp?

Hampir, tetapi pembalut itu menjalankan tugas sebenar. README Ollama menyenaraikan llama.cpp sebagai backend inferensnya (disemak pada 2 August 2026). Di atasnya, Ollama menambah pendaftaran model, templat prompt yang menukar mesej sembang kepada prompt, set parameter persampelan lalai, daemon dengan pemunggahan apabila melahu, dan API HTTP. Apabila anda membandingkan token sesaat dengan tetapan yang sama, anda membandingkan enjin yang sama dengan dirinya sendiri. Pilihan sebenar anda ialah lapisan pengurusan.

Yang manakah lebih pantas pada VPS CPU sahaja?

Kedua-duanya berkongsi enjin. Oleh itu, dengan fail model, kuantisasi, saiz konteks dan bilangan thread yang sama, prestasinya hampir sama. Perbezaan yang biasanya dilaporkan datang daripada nilai lalai yang berbeza, paling kerap panjang konteks dan bilangan thread, bukannya daripada enjin. Ukur menggunakan llama-bench -m <file> -p 512 -n 128 dan bandingkan lajur tg pada mesin anda sendiri sebelum mempercayai mana-mana angka yang diterbitkan.

Bolehkah saya menggunakan fail GGUF sendiri dengan Ollama?

Ya. Letakkan fail itu pada pelayan, tulis Modelfile yang baris pertamanya ialah FROM ./your-model.gguf, tambah mana-mana baris PARAMETER yang diperlukan seperti num_ctx, kemudian jalankan ollama create your-name -f ./Modelfile. ollama ls akan menyenaraikannya bersama item yang anda tarik daripada pendaftaran. Dengan cara ini, anda boleh menggunakan kuantisasi yang tidak disediakan dalam pendaftaran.

Berapa banyak RAM yang diperlukan untuk model 8B?

Peruntukkan saiz fail, cache KV dan runtime. Binaan Q4_K_M bagi Llama 3.1 8B berukuran kira-kira 4.58 GiB pada cakera, manakala konteks 4096 token menambah kira-kira 512 MiB cache. Oleh itu, 8 GiB RAM mencukupi, tetapi 4 GiB tidak mencukupi. Saiz cache meningkat mengikut konteks: model yang sama dengan konteks 32,768 token memerlukan kira-kira 4 GiB cache sahaja. Dengan Ollama, ingat bahawa keperluan itu turut meningkat mengikut OLLAMA_NUM_PARALLEL.