Ollama vs llama.cpp: Mana Sesuai untuk VPS?

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

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

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

Apakah sebenarnya setiap projek

llama.cpp ialah implementasi inferens transformer dalam C dan C++ yang dibina di atas pustaka ggml. Ia membaca fail GGUF. GGUF (GGML universal file format) ialah bekas fail tunggal yang menyimpan pemberat, tokeniser dan metadata yang diperlukan oleh enjin untuk menjalankan model. Projek ini mengeluarkan binari berasingan untuk tugasan berasingan. llama-server ialah pelayan HTTP, llama-cli ialah gesaan interaktif, dan llama-bench mengukur daya pemprosesan. Keluaran ditanda mengikut nombor binaan dan bukannya versi semantik. Tag semasa ialah b10224, diterbitkan pada 2 Ogos 2026, dan tag baharu 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 berhubung dengan daemon tersebut. Di sebalik kedua-duanya terdapat pendaftaran di ollama.com yang menyimpan model yang telah dipakejkan. Ollama menggunakan versi semantik, dan v0.32.5 dikeluarkan pada 27 Julai 2026. ollama pull mengambil GGUF bersama-sama templat gesaan dan set parameter lalai, kemudian menyimpannya di bawah /usr/share/ollama/.ollama/models pada Linux.

Pemakejan itulah satu-satunya perbezaan. Ollama menentukan kuantisasi, templat dan panjang konteks untuk anda, serta memberikan anda satu nama untuk diingati. llama.cpp tidak menentukan apa-apa dan memberikan anda flag.

Paksi 1: kawalan model dan kuantisasi

Kuantisasi mengecilkan setiap pemberat (weight) daripada 16 atau 32 bit kepada 4, 5 atau 8 bit. Inilah yang membolehkan model 8 bilion parameter dimuatkan ke dalam RAM VPS biasa. Penamaan GGUF mudah difahami setelah anda mengetahui polanya: Q4_K_M bermaksud kuantisasi K 4-bit, saiz sederhana. Nombor yang lebih tinggi mengekalkan lebih banyak ketepatan tetapi memerlukan 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
  }
]

Ini adalah saiz fail yang diterbitkan dalam repositori bartowski/Meta-Llama-3.1-8B-Instruct-GGUF di Hugging Face, dibaca pada 2 Ogos 2026 dan ditukar daripada bait kepada GiB. 6 binaan bagi satu model, dan yang terkecil ialah 2.96 GiB berbanding 7.95 GiB untuk yang terbesar. Pilihan lalai yang biasa, Q4_K_M, ialah 4.58 GiB. Pada VPS 4 GiB, pilihan tunggal ini menentukan sama ada model tersebut boleh dimuatkan atau tidak.

Dengan llama.cpp, anda menamakan fail tersebut, jadi anda memilih baris itu sendiri.

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 berapa banyak lapisan yang dipindahkan ke GPU (0 pada mesin yang hanya menggunakan CPU). Tiada apa-apa yang diagak untuk anda.

Dengan Ollama, kuantisasi disertakan bersama tag yang anda tarik, dan ollama ls menunjukkan apa yang sebenarnya ada pada cakera anda. Apabila registri tidak mempunyai binaan yang anda mahukan, import sendiri fail GGUF. Tulis satu Modelfile:

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

Kemudian bina fail tersebut dan semak hasilnya:

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

Panjang konteks adalah tetapan yang sering memerangkap pengguna. Ollama memilih tetapan lalai berdasarkan VRAM yang tersedia, dan mesin tanpa GPU akan jatuh ke dalam kategori terkecil: 4096 token. Jika anda menghantar dokumen 20,000 token, token tambahan akan digugurkan sebelum model sempat melihatnya, menyebabkan jawapan yang diberikan salah dengan yakin kerana ia hanya membaca separuh daripada fail tersebut. Tingkatkan nilainya dengan OLLAMA_CONTEXT_LENGTH pada daemon, atau dengan PARAMETER num_ctx dalam Modelfile. llama.cpp juga tidak mempunyai tetapan lalai yang boleh dipercayai. Tetapkan -c secara eksplisit dan ketahui nilai yang anda tetapkan.

Aritmetik memori yang jarang ditunjukkan

Fail model bukanlah satu-satunya kos. KV cache (key/value cache) menyimpan satu entri bagi setiap lapisan untuk setiap token konteks, dan ia membesar seiring dengan perbualan.

Mari kita kira untuk Llama 3.1 8B. Model ini mempunyai 32 lapisan, 8 kepala key/value dan dimensi kepala sebanyak 128. Setiap token menyimpan kedua-dua key dan value pada 2 bait setiap satu dalam f16, jadi 2 x 8 x 128 x 2 = 4096 bait bagi setiap lapisan. Merentasi 32 lapisan, ini adalah 128 KiB bagi setiap token. Oleh itu, konteks 4096 token menelan kos 512 MiB, dan konteks 32,768 token menelan kos 4 GiB.

Jadi, model Q4_K_M 8B pada konteks 4k memerlukan kira-kira 4.58 GiB untuk pemberat (weights), 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 untuk beroperasi. Tingkatkan konteks kepada 32k pada kotak 8 GiB yang sama dan cache sahaja akan menghabiskan ruang yang ada. Pantau ia secara langsung dengan free -h semasa model dimuatkan, dan jangan percaya anggaran yang tidak anda ukur sendiri.

Ollama menggandakan perkara ini. OLLAMA_NUM_PARALLEL ditetapkan secara lalai kepada 1, dan memori yang diperlukan oleh model berskala mengikut nombor tersebut didarab dengan panjang konteks. Tingkatkan kedua-duanya serentak dan daemon akan meminta RAM beberapa kali ganda daripada yang anda jangkakan secara senyap.

Paksi 2: daemon yang perlu anda kendalikan

Skrip pemasangan Ollama menulis unit systemd, mencipta pengguna sistem ollama dan mendayakan servis tersebut. Anda mendapat pengurusan kitaran hayat tanpa perlu menulis sebarang kod. 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 tempat lain. Model disimpan dalam memori selama 5 minit secara lalai dan kemudian dinyahmuat. Permintaan seterusnya perlu membaca keseluruhan fail daripada storan sebelum ia boleh menjawab, jadi muat semula 4.58 GiB menukar balasan dua saat kepada tiga puluh saat pada storan yang perlahan. Keep-alive yang lama membetulkan kependaman tersebut dan menggunakan RAM secara kekal. Kedua-duanya adalah kos sebenar. Pilih yang kurang membebankan anda.

llama.cpp tidak memberikan anda daemon, jadi 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 tersebut kemudiannya memegang model sepanjang hayatnya. Tiada apa-apa yang dinyahmuat semasa melahu, yang bermaksud tiada kejutan muat semula dan tiada cara untuk menuntut semula memori selain menghentikan servis tersebut. Jika menulis unit adalah perkara baharu bagi anda, ia menggunakan corak yang sama seperti menjalankan servis anda sendiri di bawah systemd pada VPS.

Paksi 3: API yang akan dihubungi oleh aplikasi anda

Paksi ini telah menjadi semakin seragam. Kedua-dua projek kini menggunakan format sembang OpenAI, jadi kebanyakan pustaka klien boleh berfungsi dengan mana-mana satu projek hanya dengan menukar URL asas.

Ollama mendengar pada 127.0.0.1:11434. Laluan yang serasi dengan OpenAI ialah http://localhost:11434/v1/chat/completions, dan ia mengekalkan API asli pada /api/chat di sampingnya. Laluan yang serasi dengan Anthropic juga telah didokumentasikan.

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 serta /v1/embeddings, di samping titik akhir /completion miliknya sendiri dan UI web terbina dalam. Ia juga mendedahkan laluan operasi yang tidak dimiliki oleh Ollama: /health untuk prob kesediaan, /props untuk tetapan model yang dimuatkan, /slots untuk status setiap slot permintaan, dan /metrics dalam format Prometheus. Jika anda bercadang untuk memantau servis ini, perbezaan tersebut mungkin menjadi faktor penentu.

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

Keupayaan sebenar VPS yang hanya menggunakan CPU

VPS yang hanya menggunakan CPU menjalankan model kecil dengan perlahan. Itulah rumusan jujurnya, dan bahagian yang berguna adalah mengetahui di mana hadnya. Lakukan pengukuran sebelum anda mereka bentuk sebarang sistem di sekelilingnya:

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 dalam unit token sesaat. Pada pelan vCPU kongsi, model 8B pada Q4_K_M biasanya mencapai angka tunggal yang rendah untuk tg. Pemprosesan prompt adalah bahagian yang membebankan: keseluruhan prompt diproses sebelum token output pertama muncul, jadi prompt sistem yang panjang menambah masa menunggu bagi setiap permintaan.

Boleh digunakan pada CPU: model 1B hingga 4B untuk melakukan klasifikasi, pengekstrakan, ringkasan pendek atau penghalaan. Balasan tiba dalam beberapa saat dan memori mencukupi untuk pelan biasa. Tidak boleh digunakan pada CPU: sembang interaktif pada kelajuan membaca, pembantu pengekodan, kerja dokumen panjang, atau apa-apa sahaja dengan gelung ejen yang membuat banyak panggilan secara berturutan. Gelung yang membuat dua belas panggilan dengan empat saat setiap satu mengambil masa seminit sebelum ia menghasilkan sebarang output.

Terdapat dua jalan keluar apabila angka tersebut tidak memuaskan. Jika masalahnya ialah konkurensi, iaitu ramai pengguna mengakses satu model serentak, pilihan enjin perlu ditukar, dan perbandingan Ollama dengan vLLM untuk penyajian konkurensi merangkumi perkara tersebut. Jika masalahnya ialah kelajuan mentah, jawapannya ialah VPS dengan GPU yang dipasang, di mana -ngl mula membawa makna. Sebelum melakukan mana-mana pilihan, dapatkan garis dasar untuk perkakasan itu sendiri, kerana lebar jalur cakera dan memori mempengaruhi masa muat sama seperti CPU. Penanda aras VPS yang boleh diulang berbaloi untuk diluangkan masa selama sejam.

Memasang llama.cpp, dipinkan pada binaan tertentu

Kedua-dua projek ini dikemaskini setiap minggu, jadi rekodkan versi yang anda gunakan. Skrip sebaris daripada hulu (upstream) memasang binaan semasa:

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

Untuk memin (pin) binaan tertentu, ambil tarball prabina daripada halaman releases sebagai ganti. Binaan b10224 ialah tag semasa setakat 2 Ogos 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 dependensi yang didokumentasikan untuk ciri-ciri HTTPS. Proses kompilasi mengambil masa beberapa minit dan memerlukan lebih banyak RAM daripada pelan pelayan terkecil, jadi bina pada mesin yang lebih besar dan salin fail binari jika mesin kecil kehabisan memori.

Memasang 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, jadi anda boleh mengekalkan keluaran yang diketahui stabil dan bukannya mengambil apa sahaja yang dikeluarkan pagi ini. v0.32.5 telah diterbitkan pada 27 Julai 2026. Terdapat juga laluan manual jika anda tidak mahu menyalurkan skrip terus ke dalam 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

Laluan manual tidak mencipta unit systemd atau pengguna servis, jadi anda perlu menambahnya sendiri. Panduan lengkap Ollama pada VPS merangkumi langkah penyediaan servis tersebut secara terperinci.

Mod kegagalan dan rentetan yang akan anda lihat

Ollama enggan memuatkan model. ollama run akan memaparkan baris seperti ini:

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

Ollama menyemak saiz sebelum memuatkan, jadi ia gagal dengan pantas dan menyatakan sebabnya. Turun satu baris kuantisasi, rendahkan panjang konteks, atau pilih model yang lebih kecil.

llama.cpp tidak gagal, tetapi berjalan dengan sangat perlahan. llama.cpp melakukan pemetaan memori (memory-map) pada GGUF secara lalai, jadi fail yang lebih besar daripada RAM masih boleh bermula. Kernel kemudian akan menukar berat (weights) masuk dan keluar dari cakera pada setiap token, dan penjanaan menjadi perlahan kepada beberapa saat bagi setiap token dengan penggunaan cakera mencecah 100 peratus. Gunakan --no-mmap untuk memaksa peruntukan sebenar supaya ia gagal serta-merta dan bukannya merosot prestasinya. Apabila kernel mengambil alih, dmesg akan menunjukkan sebabnya:

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

Fail model tidak mahu dimuatkan langsung. GGUF yang dibina untuk keluarga model yang lebih baharu daripada enjin anda akan memberikan ralat yang menamakan seni bina yang tidak dikenali:

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

Penyelesaiannya adalah dengan menaik taraf enjin, bukan menukar fail. Ini adalah harga bagi penetapan versi (pinning), dan itulah sebabnya anda perlu mencatat nombor binaan. Anda perlu tahu versi asal yang anda gunakan sebelum menaik taraf.

API menjawab secara setempat tetapi tidak daripada aplikasi anda. Ollama mengikat 127.0.0.1:11434, jadi hos lain akan menerima ralat connection refused. Tetapkan OLLAMA_HOST=0.0.0.0:11434 melalui systemctl edit ollama hanya apabila port berada di belakang firewall atau rangkaian peribadi, kerana API tersebut tidak mempunyai pengesahan di hadapannya.

Balasan pertama selepas jeda sangat perlahan. Proses penyahmuatan (unload) melahu selama 5 minit telah berlaku dan model sedang dibaca semula daripada cakera. ollama ps yang dijalankan sejurus sebelum permintaan menunjukkan tiada apa-apa yang dimuatkan, yang mengesahkan perkara tersebut. Tingkatkan nilai OLLAMA_KEEP_ALIVE.

Jadi, yang mana satu patut anda jalankan?

Jalankan Ollama apabila anda mahukan model diuruskan untuk anda dan endpoint berbentuk OpenAI tanpa perlu melakukan kerja tambahan. Ini merupakan pilihan lalai yang tepat untuk penggunaan kali pertama, dan untuk sebarang situasi di mana pemilihan model akan sentiasa berubah.

Jalankan llama.cpp secara terus apabila memori sangat terhad sehingga anda perlu memilih baris kuantisasi sendiri, apabila anda mahukan /health, /slots dan /metrics untuk pemantauan, atau apabila anda memerlukan flag yang tidak didedahkan oleh Ollama. Ini adalah pilihan yang jujur pada VPS di mana model hampir tidak muat, kerana tetapan yang membolehkannya dimuatkan adalah tetapan yang sama yang dipilih oleh Ollama bagi pihak anda.

Menjalankan kedua-duanya adalah perkara biasa. Ollama untuk eksperimen, llama.cpp untuk satu model yang anda letakkan dalam pengeluaran (production) dan tidak mahu ia berubah.

FAQ

Adakah Ollama sekadar pelitup (wrapper) untuk llama.cpp?

Hampir tepat, tetapi pelitup tersebut melakukan kerja yang sebenar. README Ollama menyenaraikan llama.cpp sebagai backend inferensnya (disemak pada 2 Ogos 2026). Di atasnya, Ollama menambah pendaftaran model, templat prompt yang menukarkan mesej sembang kepada prompt, set parameter pensampelan lalai, daemon dengan penyahmuatan melahu, dan API HTTP. Apabila anda membandingkan token sesaat pada tetapan yang sama, anda sebenarnya membandingkan enjin yang sama dengan dirinya sendiri. Apa yang anda pilih sebenarnya ialah lapisan pengurusan.

Yang mana lebih pantas pada VPS yang hanya menggunakan CPU?

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

Bolehkah saya menggunakan fail GGUF saya sendiri dengan Ollama?

Boleh. Letakkan fail tersebut pada pelayan, tulis Modelfile yang baris pertamanya ialah FROM ./your-model.gguf, tambah sebarang baris PARAMETER yang anda perlukan seperti num_ctx, kemudian jalankan ollama create your-name -f ./Modelfile. ollama ls akan menyenaraikannya bersama mana-mana model yang anda tarik daripada pendaftaran. Inilah cara anda menggunakan kuantisasi yang tidak disediakan oleh pendaftaran tersebut.

Berapa banyak RAM yang saya perlukan untuk model 8B?

Peruntukkan saiz fail, ditambah cache KV, ditambah runtime. Binaan Q4_K_M bagi Llama 3.1 8B adalah kira-kira 4.58 GiB pada cakera, dan konteks 4096 token menambah kira-kira 512 MiB cache, jadi 8 GiB RAM adalah selesa manakala 4 GiB tidak mencukupi. Cache berskala mengikut konteks: model yang sama pada konteks 32,768 token memerlukan kira-kira 4 GiB cache secara sendirian. Dengan Ollama, ingat bahawa keperluan tersebut juga berskala mengikut OLLAMA_NUM_PARALLEL.