Ollama vs vLLM: Mana yang Tepat untuk LLM?

Ollama vs vLLM, dalam satu paragraf

Ollama adalah pengelola model dengan server terpasang: Ollama mengunduh bobot terkuantisasi, memuatnya, lalu menjawab di 127.0.0.1:11434, menggunakan CPU jika hanya itu yang tersedia pada mesin. vLLM adalah mesin throughput: vLLM menjaga GPU tetap sibuk dengan banyak permintaan yang berjalan secara bersamaan, sehingga bukan alat yang tepat untuk mesin tanpa GPU. Itulah seluruh pertimbangannya. Satu orang yang berinteraksi dengan asisten lokal adalah tugas Ollama. Aplikasi yang melayani sebuah tim adalah tugas vLLM.

Keduanya menyediakan HTTP API yang kompatibel dengan OpenAI, sehingga kode klien dapat berpindah di antara keduanya dengan mengubah base URL. API bukanlah perbedaannya. Perbedaannya terlihat saat permintaan kedua tiba ketika permintaan pertama masih menghasilkan token.

Apa sebenarnya Ollama

Ollama adalah lapisan kemudahan. Dengan satu perintah instalasi, Ollama menyediakan registri model (ollama pull llama3.1:8b), penyimpanan bobot lokal, prompt chat, layanan systemd, dan API HTTP. Model yang dilayani berupa file GGUF, biasanya dengan kuantisasi 4-bit. Karena itu, model 7B atau 8B berukuran sekitar 5 GB di disk, bukan 16 GB. Kuantisasi memungkinkan inferensi CPU.

Runner Ollama dibangun di atas llama.cpp, yaitu pustaka inferensi C++ yang membuat kuantisasi GGUF praktis pada perangkat keras biasa. Ollama kemudian menambahkan engine sendiri untuk beberapa keluarga model yang lebih baru. Namun, llama.cpp masih menjadi dasar bagi sebagian besar model yang dilayani Ollama. Jadi, ketika orang membandingkan Ollama dengan llama.cpp, mereka pada dasarnya membandingkan lapisan ergonomi dengan komponen yang dibungkusnya.

Sasarannya adalah penggunaan oleh satu pengguna. Per Juli 2026, nilai default untuk OLLAMA_NUM_PARALLEL adalah 1. Artinya, satu model memproses satu permintaan pada satu waktu, sedangkan permintaan lainnya menunggu dalam antrean yang secara default menampung 512 entri (OLLAMA_MAX_QUEUE). Anda dapat menaikkan pengaturan paralel, dan bagian di bawah ini menjelaskan biayanya. Jika Anda belum pernah menjalankan Ollama, mulai dengan menghosting Ollama di VPS dan menjaga port 11434 tetap tertutup, karena API ini tidak memiliki autentikasi apa pun.

Apa sebenarnya vLLM

vLLM adalah server inferensi dan tidak memiliki fungsi lain. vLLM tidak mengelola pustaka model, tidak memiliki prompt chat, dan tidak akan mengambil model untuk Anda saat permintaan diterima. Anda menentukan repositori Hugging Face saat menjalankan vLLM. vLLM memuat satu model tersebut dan menyediakannya sampai proses dihentikan.

Keunggulan dari cakupan yang terbatas ini adalah throughput. Dua mekanisme menjalankan fungsi tersebut. PagedAttention menyimpan cache KV (cache key-value, yaitu status attention per token yang disimpan model untuk setiap permintaan aktif) dalam blok berukuran tetap, seperti sistem operasi melakukan paging memori. Permintaan tidak lagi memerlukan satu reservasi memori kontigu berukuran besar yang ditentukan berdasarkan kebutuhan terburuk. Dengan demikian, memori yang sebelumnya dicadangkan tetapi tidak digunakan dapat tersedia untuk lebih banyak permintaan secara bersamaan. Continuous batching memungkinkan permintaan baru bergabung ke batch yang sedang berjalan pada langkah decoding berikutnya, tanpa menunggu batch saat ini selesai. Urutan yang selesai segera keluar dari batch dan slotnya diisi kembali.

Hasil praktisnya: pada satu GPU, peningkatan pengguna secara bersamaan dari satu menjadi tiga puluh meningkatkan total token per detik secara tajam, sedangkan kecepatan per pengguna menurun jauh lebih sedikit daripada perkiraan Anda. Dengan pengaturan default Ollama, peningkatan pengguna dari satu menjadi tiga puluh hanya membuat dua puluh sembilan orang menunggu.

Batching kontinu adalah seluruh perbedaannya

Bayangkan lima permintaan tiba di setiap server pada saat yang sama, dengan perangkat keras yang identik.

Dengan pengaturan default, Ollama menjalankan permintaan pertama hingga selesai, lalu permintaan kedua, dan seterusnya. Pemanggil kelima harus menunggu empat proses generasi penuh. Throughput total kira-kira sama dengan kecepatan satu proses generasi, karena prosesor hanya memproses satu urutan pada satu waktu.

vLLM mendekode kelimanya dalam satu forward pass yang sama. Menghasilkan satu token untuk lima urutan biayanya hampir sama dengan menghasilkan satu token untuk satu urutan, karena bagian yang mahal adalah membaca bobot model dari memori, dan pembacaan tersebut digunakan bersama oleh seluruh batch. Inilah fakta bandwidth memori yang sama yang membuat inferensi CPU lambat: biaya utamanya berasal dari pemindahan bobot, bukan dari operasi aritmetika.

Anda dapat mengatur OLLAMA_NUM_PARALLEL=4 dan memperoleh sebagian manfaat ini. Konsekuensinya adalah penggunaan memori. Setiap slot paralel memerlukan cache KV sendiri, dan Ollama membagi jendela konteks di antara slot-slot tersebut. Dengan demikian, empat permintaan paralel pada model yang dikonfigurasi untuk 8192 token hanya memberi setiap permintaan konteks sebesar 2048 token. Cache berpaginasi milik vLLM menghindari kompromi tersebut, karena blok dialokasikan untuk suatu permintaan saat permintaan itu benar-benar bertambah.

Instal dan sajikan 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 instalasi membuat pengguna sistem ollama, menginstal biner, dan mendaftarkan ollama.service yang terikat ke 127.0.0.1:11434. Baris eval rate yang dicetak oleh --verbose menunjukkan jumlah token per detik sebenarnya pada mesin tersebut. Gunakan nilai ini, bukan angka yang dipublikasikan.

Untuk meningkatkan konkurensi, gunakan drop-in systemd agar pemutakhiran 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 menampilkan komponen yang dimuat, dan kolom PROCESSOR menunjukkan kondisi sebenarnya. 100% CPU berarti tidak ada GPU yang digunakan. Ini adalah penjelasan yang sebenarnya untuk sebagian besar laporan bahwa Ollama berjalan lambat.

Instal dan jalankan dengan vLLM

vLLM memerlukan Linux dan Python 3.10 hingga 3.13. Instal vLLM ke dalam lingkungan virtualnya sendiri karena vLLM mengambil build PyTorch tertentu:

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

Kemudian jalankan model. Namanya adalah ID repositori Hugging Face, bukan tag singkat:

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

Proses startup lambat pada kali pertama karena vLLM mengunduh bobot, lalu membuat profil GPU untuk menentukan jumlah blok cache KV yang sesuai. vLLM mendengarkan pada port 8000. Periksa layanan ini sebelum menulis kode 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 terpasang di server, image resmi menghindari pekerjaan pengaturan dependensi 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 wajib digunakan, bukan sekadar hiasan: PyTorch meneruskan tensor antarproses melalui memori bersama, sedangkan alokasi memori bersama bawaan Docker terlalu kecil untuk inferensi tensor-paralel.

Flag yang paling penting dalam produksi adalah --max-model-len (jendela konteks yang bersedia Anda biayai), --gpu-memory-utilization (fraksi GPU yang boleh digunakan vLLM, dengan nilai default 0.92 per Juli 2026), --tensor-parallel-size untuk membagi satu model ke beberapa GPU, dan --api-key.

Autentikasi di vLLM hanya memerlukan satu flag, sedangkan di Ollama tidak tersedia

vLLM memberlakukan token bearer jika Anda memberikannya:

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

Nilai yang sama dapat berasal dari variabel lingkungan VLLM_API_KEY. Permintaan tanpa token tersebut akan menerima HTTP 401. Hal ini tetap bukan alasan untuk memublikasikan port 8000 pada antarmuka publik, karena vLLM tidak memiliki pembatasan laju dan token HTTP biasa dapat dibaca saat transit. Namun, hal ini berarti server memiliki konsep tentang pemanggil.

Ollama tidak memiliki autentikasi. Tidak ada key, login, atau allow-list. Proses apa pun yang dapat menjangkau 11434 dapat menjalankan, mengunduh, atau menghapus model. Pertahankan layanan pada loopback dan akses melalui VPN WireGuard yang Anda host sendiri, atau melalui reverse proxy yang melakukan autentikasi dan mengakhiri TLS (keamanan lapisan transport).

Perangkat keras: kebutuhan masing-masing

Ollama berjalan pada CPU. Model terkuantisasi 4-bit memerlukan sekitar setengah gigabita RAM untuk setiap miliar parameter, ditambah sekitar satu gigabita overhead runtime dan memori tambahan untuk konteks. Karena itu, model 3B memerlukan sekitar 4 GB memori bebas, sedangkan model 8B memerlukan sekitar 8 GB. Kecepatan pada vCPU bersama berkisar dari satu digit hingga belasan token per detik. Hal ini disebabkan oleh bandwidth memori, bukan salah konfigurasi, dan tidak dapat diperbaiki dengan flag apa pun.

vLLM mengasumsikan penggunaan GPU. Jalur default-nya menyajikan bobot tanpa kuantisasi pada presisi 16-bit, yang memerlukan sekitar 2 GB untuk setiap miliar parameter. Model 8B memerlukan sekitar 16 GB memori video hanya untuk bobot, belum termasuk cache KV yang menyediakan konkurensi sebagai alasan Anda memasang vLLM. Pada kartu 24 GB, kapasitas tersebut menyisakan cache yang memadai. Pada kartu 16 GB, kapasitas tersebut tidak memadai. Karena itu, pilih model yang lebih kecil atau teruskan --quantization dengan checkpoint terkuantisasi. Backend CPU tersedia, tetapi wheel standar tidak dibuat untuk backend tersebut. Penggunaannya juga menghilangkan alasan utama menjalankan vLLM.

Karena itu, pertanyaan tentang perangkat keras biasanya menjawab pertanyaan tentang perangkat lunak. Jika tidak ada GPU, gunakan Ollama. Jika GPU sewaan hanya digunakan 5 persen karena permintaan diproses secara serial, gunakan vLLM.

Pilih yang sesuai dengan beban kerja Anda

• Satu pengguna, VPS CPU, untuk menyusun draf dan membuat ringkasan: Ollama. Kecepatannya memadai dan tidak ada opsi yang lebih sederhana.
• Asisten pemrograman atau server MCP yang menghubungkan alat Anda ke model lokal yang hanya Anda gunakan: Ollama. Konkurensi satu adalah beban kerja sebenarnya.
• Membandingkan lima model minggu ini: Ollama. Mengunduh dan menghapus model bertag adalah fungsi yang sangat sesuai untuknya, sedangkan vLLM memerlukan mulai ulang proses untuk setiap model.
• Aplikasi internal, produk obrolan, atau pipeline retrieval dengan pengguna nyata: vLLM. Dalam skenario ini, batching sepadan dengan biaya GPU.
• Pekerjaan batch yang menilai seratus ribu dokumen dalam semalam: vLLM, dengan --max-num-seqs yang tinggi. Throughput adalah satu-satunya metrik yang penting, sedangkan latensi per dokumen tidak penting.
• Platform agen yang menerima akses serentak dari beberapa agen AI yang di-hosting sendiri ke model: vLLM, karena traffic agen bersifat burst dan secara alami berjalan paralel.

Mode kegagalan, beserta string yang akan Anda lihat

vLLM menolak untuk dimulai karena error cache KV. Pesan tersebut menyebutkan kedua angka:

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 menetapkan jendela konteks yang lebih besar daripada memori yang tersisa setelah bobot dimuat. Kurangi nilainya dengan --max-model-len 8192, atau naikkan --gpu-memory-utilization jika tidak ada proses lain yang menggunakan kartu tersebut. Penggunaan di atas sekitar 0.95 cenderung mengganti error saat startup ini dengan crash CUDA out-of-memory saat beban meningkat. Kondisi kedua lebih buruk.

Ollama mencetak Killed di tengah proses generasi. Linux out-of-memory killer menghentikan proses karena model memerlukan RAM lebih besar daripada yang tersedia di server. Konfirmasikan dengan sudo dmesg | grep -i oom. Solusinya adalah menggunakan model yang lebih kecil atau model dengan kuantisasi yang lebih tinggi, bukan mengubah pengaturan.

Ollama memberikan jawaban dengan baik saat digunakan sendiri, tetapi macet saat menerima beban. Tidak ada error yang muncul di mana pun. Permintaan hanya membutuhkan waktu lebih lama ketika jumlah pemanggil bertambah karena OLLAMA_NUM_PARALLEL=1 memprosesnya secara serial. Naikkan nilainya dan terima konteks per permintaan yang lebih kecil, atau pindahkan beban kerja ke vLLM.

vLLM mengembalikan 401 pada setiap pemanggilan. Anda memulainya dengan --api-key, tetapi klien tidak mengirim header Authorization. Sebagian besar pustaka klien OpenAI mengirim nilai apa pun yang Anda berikan sebagai key. Karena itu, tetapkan key di sana, bukan dengan menghapus flag tersebut.

vLLM menyatakan bahwa model tidak ditemukan. Ollama mengambil model sesuai kebutuhan, sedangkan vLLM tidak. Field model dalam body permintaan harus sama dengan repository id yang Anda gunakan saat menjalankannya, atau sama dengan nilai --served-model-name jika Anda menetapkannya. Konfirmasikan string yang tepat dengan curl http://localhost:8000/v1/models.

Menjalankan keduanya adalah pilihan yang masuk akal

Keduanya tidak saling eksklusif. Pola yang umum adalah menjalankan vLLM pada instans GPU untuk melayani aplikasi, serta Ollama pada VPS biasa di sebelahnya untuk skrip lokal, tugas cron, dan mencoba rilis model baru. Kedua endpoint kompatibel dengan OpenAI, sehingga satu pustaka klien dan pengalihan base URL sudah mencukupi. Pengendalian biaya lebih penting dalam hal ini daripada memilih salah satu engine, karena GPU yang menganggur dikenai biaya yang sama seperti GPU yang sibuk, dan menjaga biaya agen dan inferensi tetap dapat diprediksi merupakan disiplin yang terpisah dari pemilihan server.

FAQ

Apakah vLLM lebih cepat daripada Ollama?

Untuk satu permintaan pada GPU yang sama, perbedaannya kecil karena keduanya melakukan perhitungan yang sama. Untuk banyak permintaan serentak, vLLM jauh lebih unggul karena continuous batching melakukan decoding pada setiap sequence aktif dalam satu forward pass, sedangkan konfigurasi default Ollama menjalankannya satu per satu. Pada mesin yang hanya menggunakan CPU, pertanyaan ini tidak berlaku: Ollama dapat berjalan di sana, sedangkan vLLM secara praktis tidak.

Apakah vLLM dapat berjalan tanpa GPU?

Tidak secara efektif. Paket wheel standar ditujukan untuk GPU NVIDIA atau AMD. Alasan utama vLLM digunakan, yaitu menjaga accelerator tetap sibuk dengan permintaan yang diproses secara berkelompok, tidak berlaku pada CPU. Backend CPU tersedia untuk pekerjaan pengembangan. Untuk inference pada CPU, gunakan Ollama atau llama.cpp secara langsung.

Apa perbedaan antara Ollama dan llama.cpp?

llama.cpp adalah pustaka inference, sedangkan GGUF adalah format bobot terkuantisasi yang digunakan olehnya. Runner Ollama dibangun di atasnya dan menambahkan komponen yang harus Anda siapkan sendiri jika hanya menggunakan llama.cpp: model registry, pengunduhan otomatis, server yang tetap berjalan, unit systemd, dan endpoint yang kompatibel dengan OpenAI. Ollama telah menambahkan engine-nya sendiri untuk beberapa keluarga model yang lebih baru, sehingga keduanya tidak lagi sepenuhnya identik di balik layar.

Berapa banyak memori GPU yang diperlukan vLLM untuk model 8B?

Pada presisi 16-bit, bobotnya saja berukuran sekitar 16 GB, atau kira-kira 2 GB untuk setiap satu miliar parameter. KV cache juga memerlukan ruang tambahan. Kartu 24 GB cukup memadai. Kartu 16 GB memerlukan checkpoint terkuantisasi atau model yang lebih kecil. vLLM menggunakan sebagian kapasitas kartu yang ditentukan oleh --gpu-memory-utilization, yang secara default bernilai 0.92 per Juli 2026.

Apakah saya perlu mengubah kode aplikasi untuk berpindah di antara keduanya?

Biasanya Anda hanya perlu mengubah base URL, API key, dan nama model. Ollama menyediakan antarmuka yang kompatibel dengan OpenAI di http://127.0.0.1:11434/v1 dan mengabaikan key tersebut, sedangkan vLLM menyediakan http://localhost:8000/v1 dan mewajibkan key jika Anda menetapkannya. Format nama modelnya berbeda: llama3.1:8b untuk Ollama dan ID repositori lengkap seperti Qwen/Qwen2.5-1.5B-Instruct untuk vLLM.