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, prompt sembang, servis systemd dan API HTTP, semuanya melalui satu arahan pemasangan. Kebanyakan model yang disediakannya ialah fail GGUF, biasanya dikuantisasi kepada 4-bit, itulah sebabnya model 7B atau 8B bersaiz sekitar 5 GB pada cakera dan bukannya 16 GB. Kuantisasi mengurangkan memori yang diperlukan untuk inferens CPU. Pada Mac Apple Silicon, ia juga boleh menjalankan model berasaskan safetensors melalui enjin MLX, dan sejak v0.40.0 (September 2026), seni bina yang disokong berjalan pada MLX di sana secara automatik.

Pelari GGUF miliknya dibina berasaskan llama.cpp, iaitu pustaka inferens C++ yang menjadikan kuantisasi GGUF praktikal pada perkakasan biasa. Setakat Oktober 2026, Ollama menyokong dua enjin, llama.cpp dan MLX, dan binaan Linux juga menyokong inferens MLX dengan CUDA. Panduan pembangunan mendayakan backend tersebut dengan cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, dengan prasyarat CUDA 13+ dan cuDNN 9+. 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 Oktober 2026, nilai lalai untuk OLLAMA_NUM_PARALLEL ialah 1, yang bermaksud satu model memproses satu permintaan pada satu masa dan semua yang lain menunggu dalam baris gilir yang memuatkan 512 entri secara lalai (OLLAMA_MAX_QUEUE). Anda boleh meningkatkan tetapan selari, dan bahagian di bawah menjelaskan kosnya kepada anda. Jika anda belum pernah menjalankan Ollama sebelum ini, mulakan dengan mengehoskan Ollama pada VPS dan memastikan port 11434 ditutup, kerana API tempatan tidak memerlukan pengesahan.

Apakah vLLM sebenarnya

vLLM hanyalah pelayan inferens dan tiada yang lain. Ia tidak mengurus pustaka model, ia menyediakan vllm chat klien untuk pelayan yang sedang berjalan, dan ia tidak akan memuat turun 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, 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 (batch) yang sedang berjalan pada langkah penyahkodan seterusnya dan bukannya menunggu kelompok semasa selesai. Urutan yang telah selesai meninggalkan kelompok dengan serta-merta dan slotnya diisi semula.

Hasil praktikalnya: pada satu GPU, beralih daripada seorang pengguna serentak kepada tiga puluh 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 kitaran penjanaan penuh. Jumlah throughput adalah lebih kurang sama dengan kelajuan satu penjanaan, 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 menambah kos 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 pengiraan aritmetik.

Anda boleh menetapkan OLLAMA_NUM_PARALLEL=4 dan mendapatkan sebahagian daripada kelebihan ini. Kosnya ialah memori. Setiap slot selari memerlukan KV cache sendiri, dan Ollama mendarabkan peruntukan konteks dan bukannya membahagikannya: FAQ-nya menyatakan RAM yang diperlukan berskala mengikut OLLAMA_NUM_PARALLEL kali OLLAMA_CONTEXT_LENGTH. Jadi, empat permintaan selari terhadap model yang dikonfigurasikan untuk 8192 token akan mengekalkan 8192 token setiap satu, tetapi pelayan perlu menyimpan cache untuk 32768 token secara keseluruhan. Nilai 8192 itu sendiri adalah satu pilihan dan bukannya nilai tetap, jadi meningkatkan num_ctx dan menentukan saiz RAM yang diperlukan adalah langkah yang menentukan sama ada empat slot boleh dimuatkan atau tidak. Paged cache vLLM adalah mekanisme yang mengelakkan tempahan tetingkap penuh untuk setiap slot di awal, kerana blok diperuntukkan kepada permintaan mengikut pertumbuhan sebenar permintaan tersebut. Walau apa pun, had bilangan pengguna yang boleh dilayani oleh satu pelayan pada 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 kotak tersebut. Percayai nilai ini berbanding sebarang angka yang diterbitkan. Satu bacaan daripada satu gesaan (prompt) hanyalah titik permulaan dan bukannya angka kapasiti, jadi menentukan masa token sesaat merentas imbasan konkurensi adalah perkara yang memberitahu anda sama ada kotak 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 kotak 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 tempoh senyap sehingga setengah jam daripada menanggung masa muat penuh sekali lagi. Jika tempoh senyap anda berjalan lebih lama daripada itu, tetapkan nilai yang lebih panjang.

Memasang dan menghidangkan dengan vLLM

Binaan GPU vLLM memerlukan Linux (macOS pada Apple Silicon mempunyai sokongan CPU sahaja dengan wheel prabina dalam keluaran 0.32.0, dan pecutan GPU pada Mac tersebut datang daripada vLLM-Metal, iaitu pemalam kendalian komuniti yang dibina di atas MLX). Pada Python, keluaran semasa (0.32.0, Oktober 2026) menerima versi 3.11 hingga 3.14, dan panduan pemasangan menyenaraikan julat yang sama. Python 3.10 telah digugurkan dalam 0.32.0, jadi 3.12, yang digunakan di bawah, merupakan pilihan yang selamat. Pasang ia ke dalam persekitaran maya (virtual environment) sendiri, kerana ia akan menarik binaan PyTorch yang khusus:

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

Baris terakhir terdapat dalam panduan pemasangan NVIDIA vLLM setakat Oktober 2026. Ia memasang kernel prabina FlashInfer. Tanpanya, vLLM akan memuat turun dan menyusun kernel semasa permulaan, yang menurut panduan tersebut boleh menambah masa beberapa minit pada GPU Hopper dan yang lebih baharu. Jalankan semula arahan ini selepas setiap naik taraf vLLM, kerana FlashInfer akan gagal diimport apabila kernel tidak sepadan.

Kemudian, hidangkan model. Nama tersebut 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. Semak 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 memberikan kontena akses kepada memori kongsi hos; meningkatkan --shm-size adalah satu lagi pilihan. PyTorch menghantar tensor antara proses melalui memori kongsi, terutamanya untuk inferens selari tensor (tensor-parallel inference).

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, secara lalai 0.92 setakat Oktober 2026), --tensor-parallel-size untuk memecahkan satu model merentasi beberapa GPU, dan --api-key.

Pengesahan adalah satu flag pada vLLM dan tiada pada API tempatan 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 ke laluan /v1 tanpa token tersebut akan mendapat HTTP 401. Walau bagaimanapun, kunci ini tidak meliputi keseluruhan pelayan. Panduan keselamatan vLLM, dan kod pengesahan dalam sumber 0.32.0, hanya menggunakannya pada endpoint di bawah awalan laluan /v1, /v2, /inference, dan /cohere. Teks bantuan --api-key pada halaman vllm serve hanya menyenaraikan tiga yang pertama, tetapi kod tersebut menyemak kesemua empat. Kedua-dua panduan dan teks bantuan menyatakan bahawa endpoint lain, terutamanya /invocations, yang mendedahkan inferens yang sama seperti /v1, tidak disahkan. Itu adalah alasan yang cukup untuk tidak menerbitkan port 8000 pada antara muka awam. Panduan keselamatan vLLM juga menyerahkan pengehadan kadar (rate limiting) kepada reverse proxy di hadapannya, dan token yang dihantar melalui HTTP biasa boleh dibaca semasa transit, tetapi flag tersebut bermakna pelayan mempunyai konsep pemanggil.

API tempatan Ollama tidak memerlukan pengesahan. Model awan, penerbitan model, dan muat turun model peribadi memerlukan log masuk; akses API terus ke ollama.com memerlukan API key. Mana-mana proses yang boleh mencapai 11434 boleh menjalankan, menarik, atau memadam model. Pastikan ia berada pada loopback dan capai ia melalui VPN WireGuard yang anda hos sendiri, atau melalui reverse proxy pengesahan yang 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 ruang bebas 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 lalainya menyajikan weight tidak terkuantisasi 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, ia tidak mencukupi, jadi anda perlu memilih model yang lebih kecil, menggunakan --quantization (dengan checkpoint terkuantisasi, atau untuk mengkuantisasi weight berketepatan penuh semasa dimuatkan), atau menolak sebahagian weight ke dalam RAM sistem dengan --cpu-offload-gb, yang mengekalkan ketepatannya tetapi lebih perlahan, kerana weight tersebut perlu merentas ke GPU pada setiap forward pass. Backend CPU memang wujud, dengan pakej tersendiri, tetapi ia menafikan tujuan utama menjalankan vLLM.

Oleh itu, persoalan perkakasan biasanya menjawab persoalan perisian. Tiada GPU bermakna Ollama. GPU sewaan yang berada pada 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: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

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.

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

Ollama menjawab dengan baik secara bersendirian dan terhenti di bawah beban. Tiada ralat muncul di mana-mana. Permintaan mengambil masa lebih lama apabila terdapat lebih ramai pemanggil, kerana OLLAMA_NUM_PARALLEL=1 menyerialisasikannya. Jawapan yang panjang memburukkan lagi baris gilir, memandangkan satu 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 berapa lama mana-mana giliran tunggal boleh memegang pelayan. Tingkatkan tetapan selari dan terima kos RAM tambahan bagi setiap konteks slot, atau pindahkan beban kerja ke vLLM.

vLLM mengembalikan 401 pada setiap panggilan /v1. 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 adalah kecil kerana kedua-duanya melakukan pengiraan aritmetik yang sama. Bagi banyak permintaan serentak, vLLM jauh lebih pantas kerana continuous batching menyahkod setiap jujukan aktif dalam satu forward pass, manakala tetapan lalai Ollama menjalankannya secara berturutan. Pada mesin yang hanya menggunakan CPU, kedua-duanya mempunyai laluan inferens yang disokong, dengan vLLM menggunakan wheel CPU yang berasingan.

Bolehkah vLLM berjalan tanpa GPU?

Ya, melalui backend CPU-nya. Wheel standard menyasarkan GPU NVIDIA atau AMD, dan sebab utama vLLM wujud—iaitu memastikan pemecut sentiasa tepu dengan permintaan berkelompok—tidak lagi relevan pada CPU. Backend CPU wujud dengan wheel berasingan untuk x86 dan Arm. 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. Ollama menggunakannya untuk inferens GGUF dan menambah pendaftaran model, muat turun bertag, pengurusan model serta unit systemd. Ollama juga membekalkan enjin MLX yang menjalankan model berasaskan safetensors pada Apple Silicon dan menyokong binaan CUDA pada Linux, jadi kedua-duanya tidak sentiasa serupa di bahagian dalam.

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

Pada ketepatan 16-bit, pemberat sahaja adalah kira-kira 16 GB, secara kasarnya 2 GB bagi setiap bilion parameter, dan cache KV memerlukan ruang tambahan di atas jumlah tersebut. Kad 24 GB adalah mencukupi. Kad 16 GB memerlukan model terkuantisasi, model yang lebih kecil, atau --cpu-offload-gb untuk memindahkan sebahagian pemberat ke dalam RAM sistem dengan kos kelajuan. vLLM menuntut sebahagian daripada kad yang ditetapkan oleh --gpu-memory-utilization, yang secara lalainya ialah 0.92 setakat Oktober 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 pada laluan /v1 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.