Ollama vs llama.cpp: Mana Sesuai untuk VPS?

Ollama lwn 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 perhatian. 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 memakan 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 (throughput). Keluaran ditanda mengikut nombor binaan dan bukannya versi semantik. Tag semasa ialah b10224, diterbitkan pada 2 Ogos 2026, dan tag baharu muncul 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 pelayan yang hanya menggunakan CPU). Tiada apa-apa yang diteka 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 nilai lalai berdasarkan VRAM yang tersedia, dan pelayan 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 kerana ia hanya membaca separuh daripada fail tersebut. Tingkatkan nilai ini dengan OLLAMA_CONTEXT_LENGTH pada daemon, atau dengan PARAMETER num_ctx dalam Modelfile. llama.cpp juga tidak mempunyai nilai lalai yang boleh dipercayai. Tetapkan -c secara eksplisit dan ketahui apa yang anda tetapkan.

Aritmetik memori yang tidak ditunjukkan kepada anda

Fail model bukanlah kos keseluruhan. KV cache (key/value cache) menyimpan satu entri bagi setiap layer untuk setiap token konteks, dan ia berkembang seiring dengan perkembangan perbualan.

Kira untuk Llama 3.1 8B. Model ini mempunyai 32 layer, 8 head key/value dan dimensi head 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 layer. Merentasi 32 layer, 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 berat (weights), ditambah kira-kira 0.5 GiB 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 secara langsung dengan free -h semasa model dimuatkan, dan jangan percaya anggaran yang tidak anda ukur sendiri. Jika anda membuat saiz untuk sesuatu yang jauh melebihi 8B, aritmetik yang sama yang diselesaikan untuk model 27B pada VPS CPU sahaja menunjukkan apa yang sebenarnya boleh ditampung oleh setiap peringkat daripada 8 hingga 64 GB.

Ollama menggandakan perkara ini. OLLAMA_NUM_PARALLEL secara lalai ditetapkan 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. Aritmetik yang sama menetapkan had maksimum pengguna serentak anda, kerana setiap permintaan serentak memerlukan bahagian KV cache sendiri, yang merupakan sebab pelayan yang terasa lancar untuk seorang pengguna terhenti 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 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 cakera sebelum ia boleh menjawab, jadi muat semula 4.58 GiB menukarkan balasan dua saat kepada tiga puluh saat pada storan yang perlahan. Keep-alive yang panjang membetulkan kependaman tersebut dan menggunakan RAM secara kekal. Kedua-duanya adalah kos sebenar. Pilih yang kurang membebankan.

llama.cpp tidak menyediakan 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. 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 pemeriksaan kesediaan (readiness probe), /props untuk tetapan model yang dimuatkan, /slots untuk status 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 (authentication) untuk anda. Kedua-duanya menggunakan loopback secara lalai atas sebab yang wajar. Capai pelayan tersebut melalui SSH tunnel 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 apa-apa 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 pada empat saat setiap satu mengambil masa seminit sebelum ia menghasilkan apa-apa. Jika pembantu pengekodan memang menjadi rancangan anda, menghalakan ejen kepada model yang anda hoskan sendiri menjelaskan tugasan yang benar-benar sesuai untuk model tempatan kecil dan tugasan yang perlu kekal pada API berhos.

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

Memasang llama.cpp, dipinkan pada binaan tertentu

Kedua-dua projek ini dikemaskini setiap minggu, jadi rekodkan versi yang anda gunakan. Skrip satu baris daripada hulu (upstream) akan 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 sebaliknya. 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 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 HTTPS. Proses kompilasi mengambil masa beberapa minit dan memerlukan lebih banyak RAM berbanding pelan pelayan yang paling kecil, jadi bina pada mesin yang lebih besar dan salin fail binari jika mesin kecil kehabisan memori.

Memasang Ollama, ditetapkan pada versi tertentu

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 lebih suka tidak 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. Turunkan satu baris kuantisasi, rendahkan panjang konteks, atau pilih model yang lebih kecil.

llama.cpp tidak gagal, tetapi berjalan sangat perlahan. llama.cpp melakukan memory-map pada GGUF secara lalai, jadi fail yang lebih besar daripada RAM masih boleh bermula. Kernel kemudian menukar berat model masuk dan keluar dari cakera pada setiap token, dan penjanaan menurun 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 mendapat 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 tepat 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 mahu model diuruskan untuk anda dan memerlukan endpoint berbentuk OpenAI tanpa perlu melakukan konfigurasi tambahan. Ini adalah pilihan lalai yang tepat untuk penggunaan kali pertama, dan untuk sebarang situasi di mana pilihan model akan kerap 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 disediakan oleh Ollama. Ini adalah pilihan yang jujur pada VPS di mana model hampir tidak muat, kerana tetapan yang membolehkan model itu dimuatkan adalah tetapan yang sama yang dipilih oleh Ollama bagi pihak anda.

Menjalankan kedua-duanya adalah perkara biasa. Gunakan Ollama untuk eksperimen, dan llama.cpp untuk model tunggal yang anda letakkan dalam pengeluaran (production) dan tidak mahu diubah lagi.

FAQ

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

Hampir tepat, tetapi pembungkus tersebut melakukan tugas yang sebenar. README Ollama menyenaraikan llama.cpp sebagai backend inferensnya (disemak pada 2 Ogos 2026). Selain itu, Ollama menambah pendaftaran model, templat prompt yang menukarkan mesej sembang kepada prompt, set parameter pensampelan lalai, daemon dengan fungsi penyahmuatan (unloading) melahu, dan API HTTP. Apabila anda membandingkan token sesaat pada tetapan yang sama, anda sebenarnya membandingkan enjin yang sama. 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 serupa. Perbezaan yang dilaporkan pengguna biasanya berpunca daripada tetapan lalai yang berbeza, paling kerap pada 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 dalam pendaftaran.

Berapa banyak RAM yang saya perlukan untuk model 8B?

Peruntukkan saiz fail, ditambah dengan cache KV, serta 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.