Ollama vs vLLM: Mana Satu Pilihan Terbaik?

Ollama berbanding vLLM, dalam satu perenggan

Ollama ialah pengurus model yang disertakan dengan pelayan: ia memuat turun pemberat terkuantisasi, memuatkannya, dan memberikan respons pada 127.0.0.1:11434, walaupun hanya menggunakan CPU jika itu sahaja perkakasan yang tersedia. vLLM ialah enjin pemprosesan (throughput): ia memastikan GPU sentiasa tepu dengan banyak permintaan yang berjalan serentak, dan ia merupakan alat yang salah untuk mesin tanpa GPU. Itulah penentu keputusan sepenuhnya. Seorang pengguna yang berinteraksi dengan pembantu tempatan adalah tugas untuk Ollama. Aplikasi yang melayani satu pasukan adalah tugas untuk vLLM.

Kedua-duanya menggunakan API HTTP yang serasi dengan OpenAI, jadi kod klien boleh bertukar antara satu sama lain hanya dengan menukar URL asas. Perbezaannya bukan terletak pada API. Perbezaannya terletak pada apa yang berlaku apabila permintaan kedua tiba semasa permintaan pertama masih menjana token.

Apakah sebenarnya Ollama

Ollama ialah lapisan kemudahan. Ia menyediakan pendaftaran model (ollama pull llama3.1:8b), storan berat tempatan, gesaan sembang, servis systemd dan API HTTP, semuanya melalui satu arahan pemasangan. Model yang disediakannya ialah fail GGUF, biasanya dikuantisasi 4-bit, itulah sebabnya model 7B atau 8B bersaiz sekitar 5 GB pada cakera dan bukannya 16 GB. Kuantisasi adalah perkara yang membolehkan inferens CPU dilakukan.

Pelarinya dibina berasaskan llama.cpp, iaitu pustaka inferens C++ yang menjadikan kuantisasi GGUF praktikal pada perkakasan biasa. Ollama sejak itu telah menambah enjinnya sendiri untuk beberapa keluarga model yang lebih baharu, namun llama.cpp masih menjadi substrat di bawah kebanyakan model yang disediakannya. Jadi, apabila orang membandingkan Ollama dengan llama.cpp, mereka sebenarnya membandingkan lapisan ergonomik dengan perkara yang dibungkusnya.

Sasaran reka bentuknya adalah untuk seorang pengguna. Setakat Julai 2026, nilai lalai untuk OLLAMA_NUM_PARALLEL ialah 1, yang bermaksud satu model memproses satu permintaan pada satu masa dan permintaan lain menunggu dalam baris gilir yang memuatkan 512 entri secara lalai (OLLAMA_MAX_QUEUE). Anda boleh meningkatkan tetapan selari, dan bahagian di bawah menjelaskan kos yang perlu ditanggung. Jika anda belum pernah menjalankan Ollama sebelum ini, mulakan dengan mengehoskan Ollama pada VPS dan memastikan port 11434 ditutup, kerana API tersebut tidak mempunyai sebarang bentuk pengesahan.

Apakah vLLM sebenarnya

vLLM hanyalah pelayan inferens dan tiada yang lain. Ia tidak mengurus pustaka model, ia tidak mempunyai gesaan sembang (chat prompt), dan ia tidak akan menarik model untuk anda semasa permintaan dibuat. Anda menamakan repositori Hugging Face semasa pelancaran, ia memuatkan model tersebut, dan ia menghidangkannya sehingga anda menghentikan proses tersebut.

Apa yang anda peroleh daripada kekhususan ini ialah daya pemprosesan (throughput). Dua mekanisme melakukan kerja ini. PagedAttention menyimpan KV cache (cache kunci-nilai, iaitu keadaan perhatian per-token yang disimpan oleh model untuk setiap permintaan aktif) dalam blok bersaiz tetap, seperti cara sistem pengendalian melakukan paging memori. Sesuatu permintaan tidak lagi memerlukan satu tempahan besar yang bersambung untuk kes terburuk, jadi memori yang sebelum ini dikhaskan dan tidak digunakan menjadi tersedia untuk lebih banyak permintaan serentak. Continuous batching membolehkan permintaan baharu menyertai kelompok yang sedang berjalan pada langkah penyahkodan seterusnya dan bukannya menunggu kelompok semasa selesai. Urutan yang selesai akan meninggalkan kelompok dengan serta-merta dan slotnya diisi semula.

Hasil praktikalnya: pada satu GPU, beralih daripada seorang pengguna serentak kepada tiga puluh akan meningkatkan jumlah token sesaat dengan ketara, manakala kelajuan per-pengguna jatuh jauh lebih rendah daripada yang anda jangkakan. Di bawah tetapan lalai Ollama, beralih daripada seorang pengguna kepada tiga puluh hanya menyebabkan dua puluh sembilan orang menunggu.

Continuous batching adalah perbezaan utama

Bayangkan lima permintaan sampai ke setiap pelayan pada saat yang sama menggunakan perkakasan yang serupa.

Ollama dengan tetapan lalai menjalankan permintaan pertama sehingga selesai, kemudian permintaan kedua, dan seterusnya. Pemanggil kelima perlu menunggu empat generasi penuh. Jumlah throughput adalah lebih kurang kelajuan satu generasi, kerana pemproses hanya bekerja pada satu jujukan pada satu-satu masa.

vLLM menyahkod kesemua lima permintaan dalam forward pass yang sama. Menjana satu token untuk lima jujukan hampir tidak menelan kos lebih berbanding menjana satu token untuk satu jujukan, kerana bahagian yang memakan kos adalah membaca pemberat model (model weights) daripada memori, dan bacaan tersebut dikongsi merentasi keseluruhan batch. Ini adalah fakta lebar jalur memori yang sama yang menyebabkan inferens CPU menjadi perlahan: anda membayar untuk memindahkan pemberat, bukan untuk aritmetik.

Anda boleh menetapkan OLLAMA_NUM_PARALLEL=4 dan mendapatkan sebahagian daripada kelebihan ini. Kosnya adalah memori. Setiap slot selari memerlukan KV cache sendiri, dan Ollama membahagikan tetingkap konteks merentasi slot tersebut, jadi empat permintaan selari terhadap model yang dikonfigurasikan untuk 8192 token akan meninggalkan setiap permintaan dengan 2048 token konteks. Nilai 8192 itu sendiri adalah satu pilihan dan bukannya nilai tetap, jadi meningkatkan num_ctx dan menetapkan saiz RAM yang diperlukan adalah langkah yang menentukan sama ada empat slot itu boleh digunakan atau tidak. Paged cache dalam vLLM adalah perkara yang mengelakkan pertukaran (trade-off) tersebut, kerana blok diperuntukkan kepada sesuatu permintaan apabila permintaan itu benar-benar berkembang. Walau apa pun, had bilangan pengguna yang boleh dilayan oleh satu kotak pada satu-satu masa bergantung kepada saiz KV cache, kos prefill, dan kedalaman baris gilir, yang merupakan sebab mengapa pelayan yang terasa lancar untuk seorang pengguna menjadi sangat perlahan apabila digunakan oleh lima orang.

Memasang dan menghidangkan dengan Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Skrip pemasangan mencipta pengguna sistem ollama, memasang binari, dan mendaftarkan ollama.service yang terikat pada 127.0.0.1:11434. Baris eval rate yang dicetak oleh --verbose ialah token sebenar anda sesaat pada mesin tersebut. Percayai nilai ini berbanding sebarang angka yang diterbitkan. Satu bacaan daripada satu gesaan (prompt) hanyalah titik permulaan dan bukannya nombor kapasiti, jadi mengukur token sesaat merentasi imbasan konkurensi adalah perkara yang memberitahu anda sama ada mesin tersebut mampu bertahan pada beban yang anda jangkakan, dan sama ada menyewa GPU lebih berbaloi daripada membayar setiap token.

Untuk meningkatkan konkurensi, gunakan drop-in systemd supaya naik taraf tidak menimpa perubahan tersebut:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps menunjukkan perkara yang dimuatkan, dan lajur PROCESSOR menyatakan perkara yang sebenar. 100% CPU bermaksud tiada GPU yang terlibat, yang merupakan penjelasan jujur bagi kebanyakan laporan bahawa Ollama adalah perlahan. Baris OLLAMA_KEEP_ALIVE=30m dalam drop-in tersebut adalah sama penting pada mesin yang tidak sibuk, kerana tetapan lalai akan memunggah model selepas lima minit tanpa permintaan, dan mengekalkan model dalam memori antara permintaan adalah perkara yang menghalang gesaan pertama selepas sejam melahu daripada menanggung masa muatan penuh sekali lagi.

Memasang dan menghidangkan dengan vLLM

vLLM memerlukan Linux dan Python 3.10 hingga 3.13. Pasang ia dalam persekitaran maya (virtual environment) sendiri, kerana ia menarik binaan PyTorch yang khusus:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Kemudian, hidangkan model. Namanya ialah id repositori Hugging Face, bukan tag ringkas:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Permulaan adalah perlahan pada kali pertama, kerana ia memuat turun pemberat (weights) dan kemudian membuat profil GPU untuk menentukan berapa banyak blok cache KV yang muat. Ia mendengar pada port 8000. Periksa ia sebelum menulis sebarang kod klien:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Jika Docker sudah ada pada mesin, imej rasmi mengelakkan kerja kebergantungan CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host diperlukan, bukan sekadar hiasan: PyTorch menghantar tensor antara proses melalui memori kongsi, dan peruntukan memori kongsi Docker lalai adalah terlalu kecil untuk inferens selari tensor.

Flag yang paling penting dalam pengeluaran (production) ialah --max-model-len (tetingkap konteks yang anda sanggup bayar), --gpu-memory-utilization (pecahan kad yang boleh dituntut oleh vLLM, 0.92 secara lalai setakat Julai 2026), --tensor-parallel-size untuk memecahkan satu model merentasi beberapa GPU, dan --api-key.

Pengesahan adalah satu flag pada vLLM dan tiada pada Ollama

vLLM menguatkuasakan bearer token jika anda memberikannya:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Nilai yang sama boleh datang daripada pemboleh ubah persekitaran VLLM_API_KEY. Permintaan tanpanya akan menerima HTTP 401. Ini masih bukan alasan untuk menerbitkan port 8000 pada antara muka awam, memandangkan vLLM tidak mempunyai pengehadan kadar (rate limiting) dan token HTTP biasa boleh dibaca semasa transit, tetapi ia bermakna pelayan mempunyai konsep pemanggil.

Ollama tidak mempunyai ciri ini. Tiada kunci, tiada log masuk, tiada senarai dibenarkan (allow-list). Mana-mana proses yang boleh mencapai 11434 boleh menjalankan, menarik (pull), atau memadam model. Pastikan ia berada pada loopback dan capai ia melalui VPN WireGuard yang anda hoskan sendiri, atau melalui reverse proxy yang mengesahkan identiti dan menamatkan TLS (transport layer security).

Perkakasan: keperluan setiap satu

Ollama berjalan pada CPU. Model terkuantisasi 4-bit memerlukan kira-kira setengah gigabait RAM bagi setiap bilion parameter, ditambah kira-kira satu gigabait overhead masa jalan dan lebih banyak lagi untuk konteks. Oleh itu, model 3B memerlukan sekitar 4 GB RAM kosong dan model 8B sekitar 8 GB. Kelajuan pada vCPU kongsi adalah dalam lingkungan satu digit hingga dua digit rendah token sesaat. Ini adalah had lebar jalur memori, bukan salah konfigurasi, dan tiada flag yang boleh membaikinya. Untuk melihat pengiraan tersebut berlaku pada release tertentu dan bukannya sekadar anggaran kasar, menjalankan Nemotron 3.5 Lightning pada VPS menentukan tag tepat untuk ditarik, jumlah RAM yang digunakan setelah dimuatkan, dan sama ada prestasi CPU sahaja cukup pantas untuk digunakan.

vLLM mengandaikan penggunaan GPU. Laluan lalai perisian ini menyediakan weight tanpa kuantisasi pada ketepatan 16-bit, iaitu kira-kira 2 GB bagi setiap bilion parameter: model 8B memerlukan kira-kira 16 GB memori video untuk weight sahaja, sebelum mengambil kira KV cache yang memberikan konkurensi yang menjadi sebab anda memasang vLLM. Pada kad 24 GB, ini meninggalkan ruang cache yang boleh digunakan. Pada kad 16 GB, ruang tersebut tidak mencukupi, jadi anda perlu memilih model yang lebih kecil atau menggunakan --quantization dengan checkpoint terkuantisasi. Backend CPU memang wujud, tetapi pakej standard tidak dibina untuknya, dan ia menghilangkan tujuan asal menjalankan vLLM.

Oleh itu, persoalan perkakasan biasanya menjawab persoalan perisian. Tiada GPU bermakna Ollama. GPU sewaan yang berada pada kadar penggunaan 5 peratus kerana permintaan diserialisasikan bermakna vLLM.

Pilihan yang sesuai untuk beban kerja anda

• Seorang pengguna, VPS satu CPU, untuk draf dan ringkasan: Ollama. Kelajuannya memadai dan tiada yang lebih ringkas daripada ini.
• Pembantu pengekodan, atau pelayan MCP yang menghubungkan alatan anda dengan model tempatan, yang hanya digunakan oleh anda: Ollama. Beban kerja sebenar hanyalah konkurensi satu.
• Membandingkan lima model minggu ini: Ollama. Ia sangat cekap dalam menarik dan memadam model bertag, manakala vLLM memerlukan proses dimulakan semula bagi setiap model.
• Aplikasi dalaman, produk sembang, atau saluran paip perolehan dengan pengguna sebenar: vLLM. Di sinilah pemprosesan kelompok (batching) memberikan nilai berbaloi bagi kos GPU.
• Tugasan kelompok yang memproses seratus ribu dokumen dalam tempoh semalaman: vLLM, dengan --max-num-seqs yang tinggi. Daya pemprosesan (throughput) adalah satu-satunya metrik yang penting dan latensi setiap dokumen tidak diambil kira.
• Platform ejen di mana beberapa ejen AI yang dihoskan sendiri mengakses model secara serentak: vLLM, kerana trafik ejen bersifat lonjakan dan selari secara semula jadi.

Mod kegagalan, berserta rentetan yang akan anda lihat

vLLM enggan bermula dengan ralat KV cache. Mesej tersebut menamakan kedua-dua nombor:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Model mengisytiharkan tetingkap konteks yang lebih besar daripada memori yang tinggal selepas memuatkan pemberat (weights). Rendahkannya dengan --max-model-len 8192, atau tingkatkan --gpu-memory-utilization jika tiada apa-apa lagi yang menggunakan kad tersebut. Menolak penggunaan melebihi kira-kira 0.95 cenderung menukar ralat permulaan ini kepada kegagalan CUDA out-of-memory kemudian, semasa beban, yang mana lebih buruk antara kedua-duanya.

Ollama mencetak Killed semasa penjanaan. Pembunuh out-of-memory Linux menghentikan proses tersebut kerana model memerlukan lebih banyak RAM daripada yang dimiliki oleh mesin. Sahkan dengan sudo dmesg | grep -i oom. Penyelesaiannya ialah model yang lebih kecil atau yang dikuantisasi dengan lebih berat, bukan melalui tetapan.

Ollama menjawab dengan baik secara bersendirian dan terhenti di bawah beban. Tiada ralat muncul di mana-mana. Permintaan hanya mengambil masa lebih lama apabila terdapat lebih ramai pemanggil, kerana OLLAMA_NUM_PARALLEL=1 menyerialisasikannya. Jawapan yang panjang memburukkan lagi baris gilir, memandangkan seorang pemanggil yang memegang satu-satunya slot sehingga model memutuskan untuk berhenti akan menyekat semua orang di belakangnya, jadi mengehadkan balasan dengan num_predict meletakkan siling pada tempoh masa mana-mana pusingan tunggal boleh memegang pelayan. Tingkatkan tetapan selari dan terima konteks per-permintaan yang lebih kecil, atau pindahkan beban kerja ke vLLM.

vLLM mengembalikan 401 pada setiap panggilan. Anda memulakannya dengan --api-key dan klien tidak menghantar pengepala Authorization. Kebanyakan pustaka klien OpenAI menghantar apa sahaja yang anda berikan sebagai kunci, jadi tetapkannya di sana dan bukannya membuang flag tersebut.

vLLM menyatakan model tidak ditemui. Ollama menarik (pull) atas permintaan, vLLM tidak. Medan model dalam badan permintaan mesti sepadan dengan id repositori yang anda gunakan semasa melancarkan, atau nilai --served-model-name jika anda menetapkannya. Sahkan rentetan tepat dengan curl http://localhost:8000/v1/models.

Menjalankan kedua-duanya adalah jawapan yang munasabah

Ia tidak bersifat eksklusif. Bentuk yang biasa digunakan ialah vLLM pada instans GPU yang melayani aplikasi, dengan Ollama pada VPS biasa di sebelahnya untuk skrip tempatan, cron jobs, dan mencuba keluaran model baharu. Kedua-dua endpoint adalah serasi dengan OpenAI, jadi satu pustaka klien dan penukaran base-URL sudah memadai untuk kedua-duanya. Kawalan kos lebih penting di sini berbanding mana-mana enjin, kerana GPU yang melahu tetap dikenakan caj yang sama seperti GPU yang sibuk, dan mengekalkan kos ejen dan inferens agar boleh diramal merupakan disiplin yang berasingan daripada pemilihan pelayan.

FAQ

Adakah vLLM lebih pantas daripada Ollama?

Bagi satu permintaan pada GPU yang sama, perbezaannya kecil kerana kedua-duanya melakukan pengiraan aritmetik yang sama. Bagi banyak permintaan serentak, vLLM jauh lebih pantas kerana continuous batching menyahkod setiap urutan aktif dalam satu forward pass, manakala tetapan lalai Ollama menjalankannya satu demi satu. Pada mesin yang hanya menggunakan CPU, soalan ini tidak relevan: Ollama boleh berjalan di sana manakala vLLM secara efektif tidak boleh.

Bolehkah vLLM berjalan tanpa GPU?

Tidak secara praktikal. Wheel standard menyasarkan GPU NVIDIA atau AMD, dan sebab utama vLLM wujud—iaitu memastikan pemecut sentiasa tepu dengan permintaan yang dikumpulkan (batched requests)—hilang pada CPU. Backend CPU wujud untuk tujuan pembangunan. Untuk inferens CPU sebenar, gunakan Ollama atau llama.cpp secara terus.

Apakah perbezaan antara Ollama dan llama.cpp?

llama.cpp ialah pustaka inferens, dan GGUF ialah format pemberat terkuantisasi (quantized weight) miliknya. Runner Ollama dibina di atasnya dan menambah bahagian yang ditinggalkan oleh llama.cpp untuk anda: pendaftaran model, muat turun automatik, pelayan residen, unit systemd, dan endpoint yang serasi dengan OpenAI. Ollama telah menambah enjinnya sendiri untuk beberapa keluarga model yang lebih baharu, jadi kedua-duanya kini tidak lagi serupa di bahagian dalam.

Berapakah memori GPU yang diperlukan oleh vLLM untuk model 8B?

Pada ketepatan 16-bit, pemberat sahaja adalah sekitar 16 GB, secara kasarnya 2 GB bagi setiap bilion parameter, dan KV cache memerlukan ruang tambahan di atasnya. Kad 24 GB adalah selesa. Kad 16 GB memerlukan checkpoint terkuantisasi atau model yang lebih kecil. vLLM menuntut sebahagian daripada kad yang ditetapkan oleh --gpu-memory-utilization, yang secara lalai adalah 0.92 setakat Julai 2026.

Adakah saya perlu menukar kod aplikasi saya untuk bertukar antara keduanya?

Biasanya hanya URL asas, kunci API, dan nama model. Ollama menyediakan antaramuka yang serasi dengan OpenAI pada http://127.0.0.1:11434/v1 dan mengabaikan kunci tersebut, manakala vLLM menyediakan http://localhost:8000/v1 dan menguatkuasakan kunci jika anda menetapkannya. Nama model berbeza dari segi format: llama3.1:8b untuk Ollama, dan ID repositori penuh seperti Qwen/Qwen2.5-1.5B-Instruct untuk vLLM.