Ollama vs vLLM: Pilih Server LLM yang Tepat

Ollama vs vLLM, dalam satu paragraf

Ollama adalah pengelola model dengan server terintegrasi: Ollama mengunduh bobot terkuantisasi, memuatnya, lalu memberikan respons pada 127.0.0.1:11434, menggunakan CPU jika hanya itu yang tersedia pada mesin. vLLM adalah engine throughput: vLLM menjaga GPU tetap sibuk dengan banyak request yang berjalan secara bersamaan, dan merupakan pilihan yang keliru pada mesin tanpa GPU. Itulah seluruh dasar pengambilan keputusannya. Satu orang yang berinteraksi dengan asisten lokal adalah pekerjaan untuk Ollama. Aplikasi yang melayani sebuah tim adalah pekerjaan untuk vLLM.

Keduanya menyediakan HTTP API yang kompatibel dengan OpenAI, sehingga kode klien dapat dipindahkan di antara keduanya dengan mengubah base URL. API bukanlah perbedaannya. Perbedaannya terlihat dari apa yang terjadi ketika request kedua masuk saat request pertama masih menghasilkan token.

Apa sebenarnya Ollama

Ollama adalah lapisan kemudahan. Ollama menyediakan registri model (ollama pull llama3.1:8b), penyimpanan bobot lokal, prompt chat, service systemd, dan API HTTP melalui satu perintah instalasi. Model yang disajikannya 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 pada CPU.

Runner Ollama dibangun di atas llama.cpp, yaitu library inferensi C++ yang membuat kuantisasi GGUF praktis pada perangkat keras biasa. Ollama kemudian menambahkan engine-nya sendiri untuk beberapa keluarga model yang lebih baru, tetapi llama.cpp masih menjadi dasar dari sebagian besar model yang disajikannya. Jadi, ketika orang membandingkan Ollama dengan llama.cpp, mereka umumnya membandingkan lapisan ergonomi dengan komponen yang dibungkusnya.

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

Apa sebenarnya vLLM

vLLM adalah server inferensi dan tidak melakukan hal lain. vLLM tidak mengelola pustaka model, tidak menyediakan prompt chat, dan tidak akan mengunduh model untuk Anda saat menerima permintaan. Anda menentukan repositori Hugging Face saat menjalankannya, vLLM memuat satu model tersebut, lalu menyediakannya sampai proses dihentikan.

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

Hasil praktisnya: pada satu GPU, peningkatan dari satu pengguna bersamaan menjadi tiga puluh pengguna meningkatkan total token per detik secara signifikan, sementara kecepatan per pengguna turun jauh lebih sedikit daripada yang diperkirakan. Dengan default Ollama, peningkatan dari satu pengguna menjadi tiga puluh pengguna hanya membuat dua puluh sembilan orang menunggu.

Batching kontinu adalah pembeda utama

Bayangkan lima request masuk ke setiap server pada saat yang sama, dengan hardware yang identik.

Dengan pengaturan default, Ollama menyelesaikan request pertama, lalu request kedua, dan seterusnya. Pemanggil kelima harus menunggu hingga empat proses generasi selesai sepenuhnya. Total throughput kurang lebih sama dengan kecepatan satu proses generasi, karena prosesor hanya memproses satu sequence pada satu waktu.

vLLM mendekode kelima request dalam forward pass yang sama. Menghasilkan satu token untuk lima sequence hanya sedikit lebih mahal daripada menghasilkan satu token untuk satu sequence, karena bagian yang mahal adalah membaca bobot model dari memori, dan pembacaan tersebut digunakan bersama oleh seluruh batch. Inilah fakta tentang bandwidth memori yang sama yang membuat inference pada CPU lambat: biaya utama berasal dari pemindahan bobot, bukan dari operasi aritmetika.

Anda dapat menetapkan OLLAMA_NUM_PARALLEL=4 untuk memperoleh sebagian manfaat ini. Konsekuensinya adalah penggunaan memori. Setiap slot paralel memerlukan KV cache sendiri, dan Ollama membagi context window ke seluruh slot. Jadi, empat request paralel pada model yang dikonfigurasi untuk 8192 token akan memberi setiap request context sebanyak 2048 token. Nilai 8192 itu sendiri merupakan pilihan, bukan nilai bawaan, sehingga menaikkan num_ctx dan menyediakan RAM yang diperlukan menjadi langkah yang menentukan apakah empat slot benar-benar dapat digunakan. Paged cache milik vLLM menghindari trade-off tersebut karena blok dialokasikan ke request saat request tersebut benar-benar bertambah. Bagaimanapun, batas jumlah pengguna yang dapat dilayani satu server secara bersamaan ditentukan oleh ukuran KV cache, biaya prefill, dan kedalaman antrean. Inilah alasan server yang terasa baik untuk satu pengguna menjadi sangat lambat saat melayani lima pengguna.

Instal dan jalankan 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 pada 127.0.0.1:11434. Baris eval rate yang dicetak oleh --verbose menunjukkan jumlah token per detik sebenarnya pada server tersebut. Gunakan nilai ini, bukan angka yang dipublikasikan. Satu pembacaan dari satu prompt hanya merupakan titik awal, bukan ukuran kapasitas. Karena itu, mengukur token per detik pada berbagai tingkat konkurensi menunjukkan apakah server mampu menangani beban yang diharapkan dan apakah menyewa GPU lebih hemat daripada membayar per token.

Untuk meningkatkan konkurensi, gunakan drop-in systemd agar upgrade 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 konfigurasi yang dimuat, dan kolom PROCESSOR menunjukkan kondisi sebenarnya. 100% CPU berarti tidak ada GPU yang digunakan. Ini merupakan penjelasan yang tepat untuk sebagian besar laporan bahwa Ollama lambat. Baris OLLAMA_KEEP_ALIVE=30m dalam drop-in tersebut sama pentingnya pada server yang sedang tidak sibuk, karena konfigurasi default membongkar model setelah lima menit tanpa request. Mempertahankan model tetap berada di memori di antara request mencegah prompt pertama setelah satu jam tidak aktif harus kembali menunggu seluruh waktu pemuatan model.

Instal dan jalankan layanan dengan vLLM

vLLM memerlukan Linux dan Python 3.10 hingga 3.13. Instal vLLM dalam virtual environment tersendiri karena paket ini memasang build PyTorch tertentu:

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

Selanjutnya, jalankan model. Nama tersebut adalah repository id Hugging Face, bukan tag singkat:

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

Proses startup pertama kali berjalan lambat karena vLLM mengunduh weights, lalu membuat profil GPU untuk menentukan jumlah blok cache KV yang dapat ditampung. vLLM mendengarkan pada port 8000. Periksa layanan tersebut 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 tersedia pada server, image resmi menghindari konfigurasi 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 shared memory, sedangkan alokasi shared memory default Docker terlalu kecil untuk inferensi tensor-parallel.

Flag yang paling penting dalam production adalah --max-model-len (context window 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 hanya berupa satu flag pada vLLM dan tidak tersedia pada Ollama

vLLM menerapkan bearer token 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. Namun, hal ini tetap bukan alasan untuk mengekspos port 8000 pada antarmuka publik, karena vLLM tidak memiliki rate limiting dan token dalam koneksi HTTP biasa dapat dibaca selama transmisi. Meski demikian, server memiliki konsep tentang identitas pemanggil.

Ollama tidak memiliki autentikasi. Tidak ada key, login, atau allow-list. Setiap proses yang dapat menjangkau 11434 dapat menjalankan, mengunduh, atau menghapus model. Pertahankan layanan ini pada loopback dan akses melalui VPN WireGuard yang Anda host sendiri, atau melalui reverse proxy yang melakukan autentikasi dan terminasi TLS (transport layer security).

Hardware: kebutuhan masing-masing

Ollama berjalan pada CPU. Model terkuantisasi 4-bit membutuhkan sekitar setengah gigabita RAM untuk setiap miliar parameter, ditambah sekitar satu gigabita overhead runtime dan kapasitas tambahan untuk context. Jadi, model 3B membutuhkan sekitar 4 GB RAM kosong, sedangkan model 8B membutuhkan sekitar 8 GB. Kecepatan pada vCPU bersama berada pada kisaran satu digit hingga dua digit rendah token per detik. Ini disebabkan oleh bandwidth memori, bukan kesalahan konfigurasi, dan tidak dapat diperbaiki dengan flag apa pun. Untuk melihat perhitungan tersebut pada release tertentu, bukan sekadar menggunakan perkiraan umum, menjalankan Nemotron 3.5 Lightning pada VPS menetapkan tag yang tepat untuk di-pull, jumlah RAM yang digunakan setelah model dimuat, serta apakah mode CPU-only cukup cepat untuk digunakan sehari-hari.

vLLM mengasumsikan penggunaan GPU. Jalur default-nya menyajikan weight tanpa kuantisasi dengan presisi 16-bit, yang membutuhkan sekitar 2 GB untuk setiap miliar parameter. Model 8B membutuhkan sekitar 16 GB video memory hanya untuk weight, sebelum menghitung KV cache yang menyediakan concurrency sehingga vLLM layak digunakan. Pada kartu 24 GB, masih tersedia cache yang memadai. Pada kartu 16 GB, kapasitas tersebut tidak cukup. Anda harus memilih model yang lebih kecil atau meneruskan --quantization dengan checkpoint terkuantisasi. Backend CPU tersedia, tetapi standard wheel tidak dibuat untuk backend tersebut. Selain itu, penggunaan backend CPU menghilangkan alasan utama untuk menjalankan vLLM.

Karena itu, pertanyaan tentang hardware biasanya sekaligus menjawab pertanyaan tentang software. Tanpa GPU, gunakan Ollama. Jika GPU sewaan hanya berada pada utilisasi 5 persen karena request diproses secara serial, gunakan vLLM.

Pilihan untuk beban kerja Anda

• Satu orang, satu CPU VPS, untuk menyusun draf dan membuat ringkasan: Ollama. Kecepatannya memadai dan tidak ada pilihan 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 memang ditangani dengan baik, sedangkan vLLM memerlukan restart proses untuk setiap model.
• Aplikasi internal, produk chat, atau pipeline retrieval dengan pengguna nyata: vLLM. Pada kondisi ini, batching memberikan manfaat yang sebanding dengan biaya GPU.
• Tugas batch yang menilai seratus ribu dokumen semalaman: vLLM, dengan --max-num-seqs tinggi. Throughput adalah satu-satunya metrik yang penting, sedangkan latensi per dokumen tidak penting.
• Platform agen yang menjalankan beberapa agen AI self-hosted yang mengakses model secara bersamaan: vLLM, karena trafik agen bersifat bursty dan secara alami berjalan paralel.

Mode kegagalan, beserta string yang akan Anda lihat

vLLM menolak untuk start dengan error KV cache. Pesan tersebut mencantumkan 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 context window yang lebih besar daripada memori yang tersisa setelah weights dimuat. Kurangi nilainya dengan --max-model-len 8192, atau naikkan --gpu-memory-utilization jika tidak ada proses lain yang menggunakan card tersebut. Menaikkan utilisasi melewati sekitar 0.95 cenderung mengubah error saat startup ini menjadi crash CUDA out-of-memory di kemudian waktu, saat berada di bawah load. Itu merupakan hasil yang lebih buruk.

Ollama menampilkan Killed di tengah proses generasi. Linux out-of-memory killer menghentikan proses tersebut karena model membutuhkan RAM lebih besar daripada yang tersedia di server. Konfirmasikan dengan sudo dmesg | grep -i oom. Solusinya adalah menggunakan model yang lebih kecil atau dengan quantization yang lebih agresif, bukan mengubah setting.

Ollama memberikan jawaban dengan baik saat berjalan sendiri, tetapi macet saat menerima load. Tidak ada error yang muncul di mana pun. Request hanya membutuhkan waktu lebih lama ketika jumlah caller bertambah, karena OLLAMA_NUM_PARALLEL=1 memprosesnya secara serial. Jawaban yang panjang memperburuk antrean karena satu caller yang memegang satu-satunya slot hingga model memutuskan untuk berhenti akan memblokir semua caller di belakangnya. Karena itu, batasi jawaban dengan num_predict untuk menetapkan batas durasi setiap turn dalam menahan server. Naikkan setting parallel dan terima context per-request yang lebih kecil, atau pindahkan workload ke vLLM.

vLLM mengembalikan 401 pada setiap call. Anda menjalankannya dengan --api-key, tetapi client tidak mengirim header Authorization. Sebagian besar library client OpenAI mengirimkan nilai yang Anda berikan sebagai key, jadi tetapkan nilai tersebut di sana, bukan dengan menghapus flag.

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

Menjalankan keduanya adalah pilihan yang wajar

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

FAQ

Apakah vLLM lebih cepat daripada Ollama?

Untuk satu request pada GPU yang sama, perbedaannya kecil karena keduanya melakukan perhitungan yang sama. Untuk banyak request secara bersamaan, vLLM jauh lebih cepat karena continuous batching mendekode setiap sequence aktif dalam satu forward pass, sedangkan konfigurasi default Ollama menjalankannya satu per satu. Pada mesin yang hanya menggunakan CPU, pertanyaan ini tidak relevan: Ollama dapat berjalan di sana, sedangkan vLLM secara efektif tidak dapat digunakan.

Apakah vLLM dapat berjalan tanpa GPU?

Tidak secara praktis. Wheel standar ditujukan untuk GPU NVIDIA atau AMD, dan alasan vLLM dibuat—menjaga accelerator tetap digunakan secara optimal dengan request yang di-batch—tidak berlaku pada CPU. Backend CPU tersedia untuk pekerjaan pengembangan. Untuk inferensi CPU sungguhan, gunakan Ollama atau llama.cpp secara langsung.

Apa perbedaan antara Ollama dan llama.cpp?

llama.cpp adalah library inferensi, sedangkan GGUF adalah format weight terkuantisasi miliknya. Runner Ollama dibangun di atasnya dan menambahkan bagian yang harus Anda kelola sendiri jika menggunakan llama.cpp: model registry, download 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 dibutuhkan vLLM untuk model 8B?

Pada presisi 16-bit, weight saja berukuran sekitar 16 GB, atau kira-kira 2 GB per satu miliar parameter, dan KV cache membutuhkan ruang tambahan. GPU 24 GB cukup leluasa. GPU 16 GB memerlukan checkpoint terkuantisasi atau model yang lebih kecil. vLLM menggunakan sebagian memori GPU sesuai nilai --gpu-memory-utilization, yang secara default adalah 0.92 per Juli 2026.

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

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