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 registry model (ollama pull llama3.1:8b), penyimpanan bobot model lokal, prompt chat, service systemd, dan API HTTP melalui satu perintah instalasi. Sebagian besar model yang dilayani Ollama berupa file GGUF, biasanya dikuantisasi menjadi 4-bit. Karena itu, model 7B atau 8B berukuran sekitar 5 GB di disk, bukan 16 GB. Kuantisasi mengurangi memori yang diperlukan untuk inferensi CPU. Pada Mac dengan Apple Silicon, Ollama juga dapat menjalankan model berbasis safetensors melalui engine MLX. Sejak v0.40.0 (September 2026), arsitektur yang didukung otomatis berjalan pada MLX.

Runner GGUF Ollama dibangun di atas llama.cpp, yaitu library inferensi C++ yang membuat kuantisasi GGUF praktis pada hardware biasa. Per Oktober 2026, Ollama mendukung dua engine, yaitu llama.cpp dan MLX. Build Linux juga mendukung inferensi MLX dengan CUDA. Panduan pengembangan mengaktifkan backend tersebut dengan cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13, dengan prasyarat CUDA 13+ dan cuDNN 9+. Jadi, ketika orang membandingkan Ollama dengan llama.cpp, perbandingan tersebut pada dasarnya adalah antara lapisan ergonomi dan komponen yang dibungkusnya.

Target desainnya adalah satu pengguna. Per Oktober 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 meningkatkan pengaturan paralel tersebut. Bagian di bawah ini menjelaskan dampaknya terhadap penggunaan resource. Jika Anda belum pernah menjalankan Ollama, mulai dengan meng-host Ollama pada VPS dan menjaga port 11434 tetap tertutup, karena API lokal tidak memerlukan autentikasi.

Apa sebenarnya vLLM

vLLM adalah server inference dan tidak melakukan hal lain. vLLM tidak mengelola pustaka model, menyediakan client vllm chat untuk server yang sedang berjalan, dan tidak akan mengunduh model untuk Anda saat menerima request. Anda menentukan repository 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 disimpan model untuk setiap request aktif) dalam blok berukuran tetap, seperti sistem operasi melakukan paging memori. Request tidak lagi memerlukan satu reservasi besar yang berdampingan dan berukuran sesuai kondisi terburuk. Dengan demikian, memori yang sebelumnya dicadangkan tetapi tidak digunakan dapat tersedia untuk lebih banyak request secara bersamaan. Continuous batching memungkinkan request baru bergabung ke batch yang sedang berjalan pada langkah decoding berikutnya, tanpa menunggu batch saat ini selesai. Urutan yang selesai langsung dikeluarkan dari batch, lalu slot-nya diisi kembali.

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

Batching berkelanjutan adalah pembeda utamanya

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

Dengan pengaturan default, Ollama menjalankan request pertama sampai selesai, lalu request kedua, dan seterusnya. Pemanggil kelima harus menunggu empat proses generasi selesai. Throughput total kira-kira hanya sebesar kecepatan satu proses generasi karena prosesor hanya memproses satu sequence pada satu waktu.

vLLM melakukan decoding terhadap 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 juga 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 KV cache sendiri, dan Ollama mengalikan alokasi konteks, bukan membaginya: FAQ-nya menyatakan bahwa RAM yang diperlukan bertambah sebesar OLLAMA_NUM_PARALLEL kali OLLAMA_CONTEXT_LENGTH. Jadi, empat request paralel pada model yang dikonfigurasi untuk 8192 token tetap memiliki 8192 token masing-masing, tetapi server harus menyimpan cache untuk total 32768 token. Nilai 8192 itu sendiri merupakan pilihan, bukan nilai tetap, sehingga menaikkan num_ctx dan menyediakan RAM yang diperlukan adalah langkah yang menentukan apakah empat slot dapat digunakan. Paged cache milik vLLM menghindari reservasi seluruh window untuk setiap slot sejak awal 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 panjang antrean. Inilah alasan server yang terasa baik untuk satu pengguna menjadi lambat saat melayani lima pengguna.

Instal dan jalankan 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 system user ollama, menginstal binary, dan mendaftarkan ollama.service yang terikat ke 127.0.0.1:11434. Baris eval rate yang dicetak oleh --verbose menunjukkan jumlah token per detik aktual pada server tersebut. Gunakan nilai ini, bukan angka yang dipublikasikan. Satu pengukuran dari satu prompt hanya merupakan titik awal, bukan ukuran kapasitas. Karena itu, mengukur token per detik pada berbagai tingkat konkurensi akan menunjukkan apakah server mampu menangani beban yang benar-benar Anda harapkan dan apakah menyewa GPU lebih hemat daripada membayar per token.

Untuk meningkatkan konkurensi, gunakan drop-in systemd agar perubahan tidak ditimpa saat upgrade:

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 jeda hingga setengah jam membayar kembali waktu pemuatan penuh. Jika jeda penggunaan Anda lebih lama dari itu, tetapkan nilai yang lebih panjang.

Instal dan sajikan dengan vLLM

Build GPU vLLM memerlukan Linux. macOS pada Apple Silicon hanya mendukung CPU melalui wheel yang telah dibuat sebelumnya dalam rilis 0.32.0. Akselerasi GPU pada Mac tersebut disediakan oleh vLLM-Metal, yaitu plugin terpisah yang dikelola komunitas dan dibangun di atas MLX. Untuk Python, rilis saat ini (0.32.0, October 2026) mendukung versi 3.11 hingga 3.14, dan panduan instalasi mencantumkan rentang yang sama. Dukungan Python 3.10 dihapus pada 0.32.0. Karena itu, 3.12 yang digunakan di bawah adalah pilihan yang aman. Instal vLLM dalam virtual environment khusus karena paket ini menarik build PyTorch tertentu:

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

Baris terakhir tercantum dalam panduan instalasi NVIDIA vLLM per October 2026. Perintah tersebut memasang kernel bawaan FlashInfer yang telah dikompilasi. Tanpa kernel ini, vLLM mengunduh dan mengompilasi kernel saat start. Menurut panduan tersebut, proses ini dapat menambah waktu beberapa menit pada GPU Hopper dan yang lebih baru. Jalankan kembali perintah itu setelah setiap upgrade vLLM karena FlashInfer menolak melakukan import jika kernel tidak cocok.

Selanjutnya, sajikan sebuah model. Namanya adalah ID repositori Hugging Face, bukan tag singkat:

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

Start pertama kali berlangsung lambat karena vLLM mengunduh weight, kemudian membuat profil GPU untuk menentukan jumlah blok cache KV yang dapat ditampung. vLLM mendengarkan pada port 8000. Periksa terlebih dahulu 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 memberikan akses container ke shared memory pada host. Meningkatkan --shm-size adalah opsi lain. PyTorch meneruskan tensor antarproses melalui shared memory, terutama untuk inferensi tensor-parallel.

Flag yang paling penting dalam lingkungan produksi 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 October 2026), --tensor-parallel-size untuk membagi satu model ke beberapa GPU, dan --api-key.

Autentikasi pada vLLM hanya memerlukan satu flag, sedangkan API lokal Ollama tidak menyediakan autentikasi

vLLM memberlakukan bearer token jika Anda menetapkannya:

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

Nilai yang sama dapat berasal dari variabel lingkungan VLLM_API_KEY. Request ke /v1 tanpa token tersebut akan menghasilkan HTTP 401. Namun, key ini tidak mencakup seluruh server. Panduan keamanan vLLM dan kode autentikasi dalam source 0.32.0 hanya menerapkannya pada endpoint di bawah prefix path /v1, /v2, /inference, dan /cohere. Teks bantuan --api-key pada halaman vllm serve hanya mencantumkan tiga prefix pertama, tetapi kode memeriksa keempatnya. Panduan dan teks bantuan tersebut menyatakan bahwa endpoint lain, terutama /invocations yang menyediakan inference yang sama seperti /v1, tidak diautentikasi. Karena itu, jangan publikasikan port 8000 pada interface publik. Panduan keamanan vLLM juga menyerahkan rate limiting kepada reverse proxy di depannya. Selain itu, token yang dikirim melalui HTTP biasa dapat dibaca selama transmisi. Namun, flag ini menunjukkan bahwa server memiliki konsep tentang pemanggil.

API lokal Ollama tidak memerlukan autentikasi. Model cloud, publikasi model, dan download model privat memerlukan sign-in. Akses API langsung ke ollama.com memerlukan API key. Setiap proses yang dapat menjangkau 11434 dapat menjalankan, melakukan pull, atau menghapus model. Pertahankan API pada loopback dan akses melalui VPN WireGuard yang Anda kelola sendiri, atau melalui reverse proxy dengan autentikasi yang melakukan terminasi TLS (transport layer security).

Perangkat keras: kebutuhan masing-masing

Ollama berjalan pada CPU. Model terkuantisasi 4-bit membutuhkan kira-kira setengah gigabita RAM untuk setiap satu miliar parameter, ditambah sekitar satu gigabita overhead runtime dan kebutuhan tambahan untuk context. Karena itu, model 3B membutuhkan sekitar 4 GB memori bebas, sedangkan model 8B membutuhkan sekitar 8 GB. Kecepatan pada vCPU bersama berada pada kisaran satu digit hingga belasan token per detik. Ini disebabkan oleh bandwidth memori, bukan salah konfigurasi, sehingga tidak ada flag yang dapat memperbaikinya. Untuk melihat perhitungan tersebut pada release tertentu, bukan sekadar menggunakan aturan praktis, menjalankan Nemotron 3.5 Lightning pada VPS menetapkan tag yang tepat untuk di-pull, jumlah RAM yang digunakan setelah model dimuat, dan apakah mode CPU-only cukup cepat untuk digunakan sehari-hari.

vLLM mengasumsikan penggunaan GPU. Jalur default-nya menyajikan bobot yang tidak terkuantisasi dengan presisi 16-bit, yang membutuhkan kira-kira 2 GB untuk setiap satu miliar parameter. Model 8B membutuhkan sekitar 16 GB video memory hanya untuk bobot, sebelum memperhitungkan KV cache yang diperlukan untuk concurrency yang menjadi alasan Anda memasang vLLM. Pada GPU 24 GB, kapasitas tersebut masih menyisakan cache yang memadai. Pada GPU 16 GB, kapasitas tersebut tidak cukup. Anda harus memilih model yang lebih kecil, meneruskan --quantization (dengan checkpoint terkuantisasi atau untuk mengkuantisasi bobot presisi penuh saat model dimuat), atau memindahkan sebagian bobot ke system RAM dengan --cpu-offload-gb. Opsi terakhir mempertahankan presisi bobot, tetapi lebih lambat karena bobot tersebut harus dikirim ke GPU pada setiap forward pass. Backend CPU tersedia dengan wheel terpisah, tetapi penggunaannya menghilangkan alasan utama untuk menjalankan vLLM.

Karena itu, pertanyaan tentang perangkat keras biasanya menentukan pilihan software. Jika tidak ada GPU, gunakan Ollama. Jika GPU sewaan hanya digunakan 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 dan string yang akan Anda lihat

vLLM menolak berjalan dengan error KV cache. Pesan tersebut menyebutkan kedua angka:

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 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.

Ollama menampilkan Killed saat proses generation berlangsung. Linux out-of-memory killer menghentikan proses karena model memerlukan RAM lebih besar daripada yang tersedia pada server. Konfirmasikan dengan sudo dmesg | grep -i oom. Solusinya adalah menggunakan model yang lebih kecil atau quantization yang lebih tinggi, bukan mengubah setting.

Ollama menjawab dengan baik saat digunakan sendiri, tetapi macet saat menerima beban. Tidak ada error yang muncul di mana pun. Request hanya menjadi semakin lama ketika jumlah pemanggil bertambah karena OLLAMA_NUM_PARALLEL=1 memprosesnya secara serial. Jawaban yang panjang memperburuk antrean karena satu pemanggil yang memegang satu-satunya slot hingga model memutuskan berhenti akan memblokir semua pemanggil di belakangnya. Karena itu, membatasi jawaban dengan num_predict menetapkan batas durasi setiap turn dalam menggunakan server. Naikkan setting parallel dan terima tambahan RAM yang diperlukan context setiap slot, atau pindahkan workload ke vLLM.

vLLM mengembalikan 401 pada setiap panggilan /v1. Anda menjalankannya dengan --api-key, tetapi client tidak mengirim header Authorization. Sebagian besar library client OpenAI mengirim nilai yang Anda berikan sebagai key, jadi tetapkan key 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 sama dengan repository id yang Anda gunakan saat menjalankannya, 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 permintaan pada GPU yang sama, perbedaannya kecil karena keduanya melakukan perhitungan yang sama. Untuk banyak permintaan secara bersamaan, vLLM jauh lebih unggul 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, keduanya memiliki jalur inference yang didukung, dengan vLLM menggunakan CPU wheel terpisah.

Apakah vLLM dapat berjalan tanpa GPU?

Ya, melalui backend CPU-nya. Wheel standar ditujukan untuk GPU NVIDIA atau AMD. Alasan utama vLLM dibuat, yaitu menjaga accelerator tetap terpakai penuh dengan permintaan yang diproses secara batch, tidak berlaku pada CPU. Backend CPU tersedia dengan wheel terpisah untuk x86 dan Arm. Untuk inference yang benar-benar menggunakan CPU, gunakan Ollama atau llama.cpp secara langsung.

Apa perbedaan antara Ollama dan llama.cpp?

llama.cpp adalah library inference, sedangkan GGUF adalah format bobot terkuantisasi yang digunakannya. Ollama menggunakan llama.cpp untuk inference GGUF dan menambahkan model registry, tagged download, manajemen model, serta unit systemd. Ollama juga menyediakan engine MLX yang menjalankan model berbasis safetensors pada Apple Silicon dan mendukung build CUDA di Linux. Karena itu, keduanya tidak selalu menggunakan komponen internal yang sama.

Berapa banyak memori GPU yang dibutuhkan 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 model terkuantisasi, model yang lebih kecil, atau --cpu-offload-gb untuk memindahkan sebagian bobot ke RAM sistem dengan konsekuensi penurunan kecepatan. vLLM menggunakan sebagian kapasitas kartu yang ditetapkan oleh --gpu-memory-utilization, yang secara default bernilai 0.92 per Oktober 2026.

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

Biasanya Anda hanya perlu mengubah 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 memberlakukan key pada route /v1 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.