Ollama atau vLLM: Pelayan LLM Mana Patut Dipilih?

Ollama berbanding vLLM, dalam satu perenggan

Ollama ialah pengurus model dengan pelayan terbina dalam: ia memuat turun pemberat terkuantum, memuatkannya dan memberikan respons pada 127.0.0.1:11434, menggunakan CPU jika itu sahaja yang tersedia pada mesin. vLLM ialah enjin daya pemprosesan: ia memastikan GPU terus digunakan sepenuhnya dengan menjalankan banyak permintaan pada masa yang sama, dan merupakan alat yang tidak sesuai untuk mesin tanpa GPU. Itulah keseluruhan keputusan tersebut. Perbualan seorang pengguna dengan pembantu setempat ialah tugas Ollama. Aplikasi yang memberikan perkhidmatan kepada sebuah pasukan ialah tugas vLLM.

Kedua-duanya menyediakan API HTTP yang serasi dengan OpenAI, jadi kod klien boleh dipindahkan antara kedua-duanya dengan menukar URL asas. API itu bukan perbezaannya. Perbezaannya ialah perkara yang berlaku apabila permintaan kedua tiba ketika permintaan pertama masih menjana token.

Apakah Ollama sebenarnya

Ollama ialah lapisan kemudahan. Ollama menyediakan pendaftaran model (ollama pull llama3.1:8b), stor setempat untuk pemberat model, gesaan sembang, perkhidmatan systemd dan API HTTP melalui satu arahan pemasangan. Model yang disediakan ialah fail GGUF, biasanya dikuantumkan kepada 4 bit. Oleh itu, model 7B atau 8B menggunakan kira-kira 5 GB ruang cakera, bukan 16 GB. Kuantifikasi membolehkan inferens CPU dijalankan.

Pelarinya dibina berasaskan llama.cpp, iaitu pustaka inferens C++ yang menjadikan kuantifikasi GGUF praktikal pada perkakasan biasa. Ollama kemudiannya menambah enjin sendiri untuk beberapa keluarga model yang lebih baharu, tetapi llama.cpp masih menjadi asas kepada kebanyakan model yang disediakannya. Oleh itu, apabila orang membandingkan Ollama dengan llama.cpp, mereka sebenarnya membandingkan lapisan kemudahan penggunaan dengan komponen yang dibungkusnya.

Reka bentuknya menyasarkan seorang pengguna. Setakat July 2026, nilai lalai untuk OLLAMA_NUM_PARALLEL ialah 1. Ini bermaksud satu model memproses satu permintaan pada satu masa, manakala permintaan lain menunggu dalam baris gilir yang secara lalai boleh menampung 512 entri (OLLAMA_MAX_QUEUE). Anda boleh meningkatkan tetapan selari, dan bahagian di bawah menerangkan kosnya. Jika anda belum pernah menjalankan Ollama, mulakan dengan mengehos Ollama pada VPS dan memastikan port 11434 ditutup, kerana API ini tidak mempunyai sebarang bentuk pengesahan.

Apakah vLLM sebenarnya

vLLM ialah pelayan inferens dan tiada fungsi lain. Ia tidak mengurus pustaka model, tidak menyediakan gesaan sembang, dan tidak akan mengambil model untuk anda semasa permintaan dibuat. Anda menentukan repositori Hugging Face semasa pelancaran, vLLM memuatkan model itu sahaja dan menyediakannya sehingga anda menghentikan proses tersebut.

Kelebihan skop yang terhad ini ialah daya pemprosesan. Dua mekanisme melaksanakannya. PagedAttention menyimpan cache KV (cache nilai-kunci, iaitu keadaan perhatian setiap token yang disimpan oleh model untuk setiap permintaan aktif) dalam blok bersaiz tetap, seperti sistem pengendalian memetakan memori. Permintaan tidak lagi memerlukan satu peruntukan bersebelahan yang besar dan bersaiz untuk keadaan terburuk. Oleh itu, memori yang sebelum ini diperuntukkan tetapi tidak digunakan boleh tersedia untuk lebih banyak permintaan serentak. Continuous batching membolehkan permintaan baharu menyertai kelompok yang sedang berjalan pada langkah penyahkodan seterusnya, tanpa menunggu kelompok semasa selesai. Urutan yang selesai meninggalkan kelompok serta-merta dan slotnya diisi semula.

Hasil praktikalnya: pada satu GPU, peningkatan daripada satu pengguna serentak kepada tiga puluh pengguna meningkatkan jumlah token sesaat dengan ketara, manakala kelajuan setiap pengguna menurun jauh lebih sedikit daripada jangkaan. Dengan konfigurasi lalai Ollama, peningkatan daripada satu pengguna kepada tiga puluh pengguna hanya menyebabkan dua puluh sembilan orang menunggu.

Batching berterusan ialah perbezaan utama

Bayangkan lima permintaan tiba pada setiap pelayan pada masa yang sama, dengan perkakasan yang sama.

Ollama dengan tetapan lalai memproses permintaan pertama hingga selesai, kemudian permintaan kedua, dan seterusnya. Pemanggil kelima menunggu empat penjanaan penuh. Jumlah daya pemprosesan kira-kira sama dengan kelajuan satu penjanaan, kerana pemproses hanya memproses satu jujukan pada satu-satu masa.

vLLM menyahkod kesemua lima permintaan dalam hantaran ke hadapan yang sama. Menjana satu token untuk lima jujukan hampir tidak lebih mahal daripada menjana satu token untuk satu jujukan, kerana bahagian yang mahal ialah membaca pemberat model daripada memori, dan bacaan itu dikongsi oleh seluruh kelompok. Ini ialah fakta lebar jalur memori yang sama yang menyebabkan inferens CPU menjadi perlahan: kosnya datang daripada pemindahan pemberat, bukan pengiraan aritmetik.

Anda boleh menetapkan OLLAMA_NUM_PARALLEL=4 dan memperoleh sebahagian daripada manfaat ini. Kosnya ialah memori. Setiap slot selari memerlukan cache KV sendiri, dan Ollama membahagikan tetingkap konteks merentas slot. Oleh itu, empat permintaan selari terhadap model yang dikonfigurasikan untuk 8192 token memberikan setiap permintaan konteks sebanyak 2048 token. Cache berhalaman vLLM mengelakkan pertukaran ini kerana blok diperuntukkan kepada sesuatu permintaan apabila permintaan itu benar-benar berkembang.

Pasang dan sediakan 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 kadar token sesaat sebenar pada mesin itu. Utamakan nilai ini berbanding mana-mana angka yang diterbitkan.

Untuk meningkatkan keserentakan, gunakan drop-in systemd supaya peningkatan versi tidak menulis ganti 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, manakala lajur PROCESSOR menunjukkan keadaan sebenar. 100% CPU bermaksud tiada GPU digunakan. Ini ialah penjelasan sebenar bagi kebanyakan laporan bahawa Ollama perlahan.

Pasang dan sediakan dengan vLLM

vLLM memerlukan Linux dan Python 3.10 hingga 3.13. Pasang vLLM dalam persekitaran maya tersendiri kerana vLLM memuatkan binaan PyTorch tertentu:

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

Kemudian sediakan model. Nama tersebut ialah ID repositori Hugging Face, bukan tag ringkas:

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

Permulaan pertama mengambil masa kerana vLLM memuat turun pemberat model, kemudian memprofil GPU untuk menentukan bilangan blok cache KV yang boleh dimuatkan. vLLM mendengar pada port 8000. Semak perkhidmatan itu 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 dipasang pada pelayan, imej rasmi mengelakkan kerja menyediakan 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 dikongsi, dan peruntukan memori dikongsi lalai Docker terlalu kecil untuk inferens selari tensor.

Dalam persekitaran produksi, flag yang paling penting ialah --max-model-len (tetingkap konteks yang anda sanggup bayar), --gpu-memory-utilization (pecahan memori kad yang boleh digunakan vLLM, lalai 0.92 setakat Julai 2026), --tensor-parallel-size untuk membahagikan satu model merentas beberapa GPU, dan --api-key.

Pengesahan ialah satu bendera pada vLLM dan tiada pada Ollama

vLLM menguatkuasakan token bearer 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 menerima HTTP 401. Namun, ini masih bukan alasan untuk menerbitkan port 8000 pada antara muka awam, kerana vLLM tidak mempunyai pengehad kadar dan token dalam HTTP biasa boleh dibaca semasa penghantaran. Walau bagaimanapun, ini bermakna pelayan mempunyai konsep tentang pemanggil.

Ollama tidak mempunyai ciri ini. Tiada kunci, tiada log masuk dan tiada senarai benarkan. Mana-mana proses yang boleh mencapai 11434 boleh menjalankan, menarik atau memadam model. Kekalkan Ollama pada gelung balik dan capainya melalui VPN WireGuard yang anda hos sendiri, atau melalui proksi songsang yang memerlukan pengesahan dan menamatkan TLS (keselamatan lapisan pengangkutan).

Perkakasan: keperluan setiap satu

Ollama berjalan pada CPU. Model yang dikuantumkan kepada 4-bit menggunakan kira-kira setengah gigabait RAM bagi setiap bilion parameter, ditambah kira-kira satu gigabait overhed masa jalan serta ruang tambahan untuk konteks. Oleh itu, model 3B memerlukan kira-kira 4 GB ruang kosong dan model 8B kira-kira 8 GB. Kelajuan pada vCPU dikongsi ialah antara satu digit hingga digit berganda rendah token sesaat. Ini disebabkan oleh lebar jalur memori, bukan salah konfigurasi, dan tiada flag yang boleh membaikinya.

vLLM mengandaikan penggunaan GPU. Laluan lalainya menyediakan weight tanpa kuantisasi pada ketepatan 16-bit, yang menggunakan kira-kira 2 GB bagi setiap bilion parameter. Model 8B memerlukan kira-kira 16 GB memori video untuk weight sahaja, sebelum mengambil kira cache KV yang diperlukan untuk keserentakan yang menjadi sebab anda memasang vLLM. Pada kad 24 GB, masih terdapat ruang cache yang mencukupi. Pada kad 16 GB, ruang itu tidak mencukupi. Oleh itu, anda perlu memilih model yang lebih kecil atau menghantar --quantization dengan checkpoint yang dikuantumkan. Backend CPU tersedia, tetapi wheel standard tidak dibina untuknya. Backend itu juga menghapuskan sebab utama untuk menjalankan vLLM.

Oleh itu, soalan perkakasan biasanya menentukan pilihan perisian. Jika tiada GPU, gunakan Ollama. Jika GPU sewaan hanya mencapai penggunaan 5 peratus kerana permintaan diproses secara bersiri, gunakan vLLM.

Pilih mengikut beban kerja anda

• Seorang pengguna, VPS CPU, untuk menyediakan draf dan membuat ringkasan: Ollama. Kelajuannya memadai dan tiada pilihan lain yang lebih mudah.
• Pembantu pengekodan, atau pelayan MCP yang menghubungkan alatan anda dengan model tempatan, yang hanya anda panggil: Ollama. Keselarasan satu permintaan ialah beban kerja sebenar.
• Membandingkan lima model minggu ini: Ollama. Menarik dan memadam model bertanda ialah perkara yang dilakukannya dengan baik, manakala vLLM memerlukan proses dimulakan semula bagi setiap model.
• Aplikasi dalaman, produk sembang atau saluran paip perolehan dengan pengguna sebenar: vLLM. Di sinilah pemprosesan berkumpulan berbaloi dengan kos GPU.
• Kerja kelompok yang menilai seratus ribu dokumen semalaman: vLLM, dengan --max-num-seqs yang tinggi. Daya pemprosesan ialah satu-satunya metrik yang penting dan kependaman setiap dokumen tidak penting.
• Platform ejen yang mempunyai beberapa ejen AI yang dihoskan sendiri mengakses model pada masa yang sama: vLLM, kerana trafik ejen bersifat tidak sekata dan sememangnya berjalan secara selari.

Mod kegagalan, dengan rentetan yang akan anda lihat

vLLM enggan bermula dengan ralat cache KV. Mesej tersebut menyatakan 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 pemberat dimuatkan. Kurangkan nilai tersebut dengan --max-model-len 8192, atau tingkatkan --gpu-memory-utilization jika tiada proses lain menggunakan kad itu. Meningkatkan penggunaan melebihi kira-kira 0.95 biasanya menukar ralat permulaan ini kepada ranap kehabisan memori CUDA kemudian, semasa beban kerja berlangsung. Itu lebih buruk daripada kedua-duanya.

Ollama mencetak Killed semasa penjanaan. Pembunuh proses kehabisan memori Linux menghentikan proses tersebut kerana model memerlukan lebih banyak RAM daripada yang tersedia pada pelayan. Sahkan dengan sudo dmesg | grep -i oom. Penyelesaiannya ialah menggunakan model yang lebih kecil atau dikuantumkan dengan lebih tinggi, bukan mengubah tetapan.

Ollama memberikan jawapan dengan baik secara bersendirian tetapi tersekat apabila menerima beban. Tiada ralat dipaparkan di mana-mana. Permintaan hanya mengambil masa yang lebih lama apabila bilangan pemanggil meningkat kerana OLLAMA_NUM_PARALLEL=1 memprosesnya secara bersiri. Tingkatkan nilainya dan terima konteks yang lebih kecil bagi setiap permintaan, atau pindahkan beban kerja ke vLLM.

vLLM mengembalikan 401 bagi setiap panggilan. Anda memulakannya dengan --api-key, tetapi klien tidak menghantar pengepala Authorization. Kebanyakan pustaka klien OpenAI menghantar apa sahaja nilai yang anda berikan sebagai kunci. Oleh itu, tetapkan nilai tersebut dalam klien dan jangan buang flag itu.

vLLM menyatakan bahawa model tidak ditemui. Ollama mengambil model apabila diperlukan, manakala vLLM tidak berbuat demikian. Medan model dalam isi permintaan mesti sepadan dengan ID repositori yang anda gunakan semasa melancarkannya, atau dengan nilai --served-model-name jika anda menetapkannya. Sahkan rentetan yang tepat dengan curl http://localhost:8000/v1/models.

Menjalankan kedua-duanya ialah pilihan yang munasabah

Kedua-duanya tidak saling mengecualikan. Susunan yang biasa ialah vLLM pada instans GPU untuk menyediakan perkhidmatan kepada aplikasi, manakala Ollama dijalankan pada VPS biasa di sebelahnya untuk skrip setempat, tugas cron dan mencuba keluaran model baharu. Kedua-dua endpoint serasi dengan OpenAI, jadi satu pustaka klien dan pertukaran base URL sudah memadai. Kawalan kos lebih penting dalam situasi ini berbanding enjin yang digunakan, kerana GPU yang tidak aktif tetap dikenakan caj yang sama seperti GPU yang sibuk, dan memastikan kos ejen dan inferens kekal boleh dijangka ialah disiplin yang berbeza daripada memilih pelayan.

FAQ

Adakah vLLM lebih pantas daripada Ollama?

Untuk satu permintaan pada GPU yang sama, perbezaannya kecil kerana kedua-duanya melaksanakan pengiraan yang sama. Untuk banyak permintaan serentak, vLLM jauh lebih pantas kerana continuous batching menyahkod setiap jujukan aktif dalam satu forward pass, manakala konfigurasi lalai Ollama menjalankannya satu demi satu. Pada mesin CPU sahaja, soalan ini tidak terpakai: Ollama boleh berjalan di situ, manakala vLLM pada praktiknya tidak.

Bolehkah vLLM berjalan tanpa GPU?

Tidak secara praktikal. Pakej standard menyasarkan GPU NVIDIA atau AMD. Sebab utama vLLM digunakan, iaitu memastikan accelerator sentiasa digunakan sepenuhnya dengan permintaan yang diproses secara berkumpulan, tidak lagi relevan pada CPU. Backend CPU tersedia untuk kerja pembangunan. Untuk inferens CPU sebenar, gunakan Ollama atau llama.cpp secara terus.

Apakah perbezaan antara Ollama dengan llama.cpp?

llama.cpp ialah pustaka inferens, manakala GGUF ialah format weight terkuantisasinya. Runner Ollama dibina berasaskannya dan menambah komponen yang perlu anda sediakan sendiri jika menggunakan llama.cpp: model registry, muat turun automatik, server residen, unit systemd dan endpoint yang serasi dengan OpenAI. Ollama telah menambah engine sendiri untuk sesetengah keluarga model yang lebih baharu. Oleh itu, kedua-duanya tidak lagi sama sepenuhnya pada lapisan asas.

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

Pada ketepatan 16-bit, weight sahaja menggunakan kira-kira 16 GB, iaitu lebih kurang 2 GB bagi setiap bilion parameter. KV cache juga memerlukan ruang tambahan. Kad 24 GB biasanya mencukupi. Kad 16 GB memerlukan checkpoint terkuantisasi atau model yang lebih kecil. vLLM menggunakan pecahan kapasiti kad yang ditetapkan oleh --gpu-memory-utilization, yang lalai kepada 0.92 setakat July 2026.

Adakah saya perlu mengubah kod aplikasi untuk bertukar antara kedua-duanya?

Biasanya, anda hanya perlu mengubah URL asas, kunci API dan nama model. Ollama menyediakan permukaan serasi OpenAI pada http://127.0.0.1:11434/v1 dan mengabaikan kunci tersebut, manakala vLLM menyediakan http://localhost:8000/v1 dan menguatkuasakan kunci itu jika anda menetapkannya. Format nama model juga berbeza: llama3.1:8b untuk Ollama dan ID repositori penuh seperti Qwen/Qwen2.5-1.5B-Instruct untuk vLLM.