Belajar AI Engineer - Serving & Deploying LLMs
Mendeploy model open-weight di infrastruktur sendiri: vLLM, TGI, Ollama, dan llama.cpp. Kalian memahami perbedaan server inference, mengukur throughput dan latensi, serta memilih jalur serving yang tepat untuk kebutuhan produktype: text
#Pendahuluan
Selama dua puluh episode, semua produk kita memanggil model via API pihak ketiga. Episode ini membuka jalur kedua: self-host serving — menjalankan model open-weight di infrastruktur sendiri. Ini bukan hanya soal penghematan; ini soal privasi (episode 20), kustomisasi (episode 10), dan kemampuan untuk skala tanpa terikat penyedia.
Mengapa penting? Karena tidak semua data boleh keluar ke pihak ketiga, dan tidak semua workload butuh model frontier. Produk yang melayani jutaan request sederhana (klasifikasi, ekstraksi) bisa di-serve dengan model lokal berbiaya hampir nol. Menguasai serving berarti kalian punya kendali penuh atas stack — dari model sampai hardware.
#Peta Alat Serving
| Alat | Kelebihan | Cocok Untuk |
|---|---|---|
| vLLM | Throughput tertinggi, PagedAttention, continuous batching | Produksi skala besar, GPU kuat |
| TGI (Text Generation Inference) | Fitur lengkap, integrasi Hugging Face | Produksi skala menengah |
| Ollama | Instalasi 1 menit, model management mudah | Lokal, dev, eksperimen |
| llama.cpp / Ollama (GGUF) | Berjalan di CPU, RAM terbatas, edge | Model kecil, tanpa GPU |
Aturannya sederhana: vLLM/TGI untuk produksi GPU, Ollama untuk dev & prototipe, llama.cpp untuk edge/CPU.
#vLLM: Standar Serving Produksi
vLLM adalah server inference paling populer 2026. Keunggulan utamanya: continuous batching — request yang masuk dikelompokkan otomatis sehingga GPU tidak pernah menganggur, dan PagedAttention yang mengelola memori KV-cache seperti virtual memory OS.
pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct \
--port 8000 \
--max-model-len 8192 \
--gpu-memory-utilization 0.9Setelah berjalan, vLLM menyediakan OpenAI-compatible API — kode dari episode 3 langsung bisa memakainya:
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="vllm")
r = client.chat.completions.create(
model="Qwen/Qwen2.5-7B-Instruct",
messages=[{"role": "user", "content": "Jelaskan apa itu serving."}],
stream=True,
)
for chunk in r:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="", flush=True)Perhatikan: base_url berubah, kode tidak. Ini sebabnya kita membangun abstraksi penyedia di episode 2 — mengganti backend tidak menyentuh kode aplikasi.
#Mengukur Kinerja Serving
Dua metrik yang wajib diukur: throughput (request per detik saat banyak pengguna) dan latency (waktu satu request). Keduanya bertolak belakang — batching menaikkan throughput tapi menambah latensi per request.
python -m vllm.benchmarks.benchmark_serving \
--model Qwen/Qwen2.5-7B-Instruct \
--num-prompts 100 \
--request-rate 20Untuk produksi, lakukan load test dengan workload nyata (misal k6 atau Locust), bukan benchmark sintetis. Target umum: throughput cukup untuk peak traffic, dan p99 latency di bawah target produk (misal 2 detik untuk chat).
#Continuous Batching dan Throughput
Tanpa continuous batching, request diproses satu per satu — GPU setengah menganggur. Dengan batching, banyak request diproses bersamaan, berbagi satu model di memori. Dampaknya dramatis: throughput naik hingga puluhan kali lipat.
| Konfigurasi | Throughput | Latensi p99 |
|---|---|---|
| Tanpa batching (one-by-one) | Rendah | Konsisten, per-request cepat |
| Continuous batching | Tinggi | Naik sedikit (antrean) |
Keputusan desain: produk dengan volume tinggi lebih diuntungkan throughput; produk interaktif real-time perlu keseimbangan. Di episode 22 kita atur batching ini bersama strategi biaya.
#TGI dan Alternatif
TGI adalah pesaing utama vLLM dari Hugging Face — fitur lengkap (quantisasi bawaan, message streaming, dukungan tools), cocok untuk tim yang sudah di ekosistem Hugging Face:
docker run --gpus all -p 8080:80 \
ghcr.io/huggingface/text-generation-inference:latest \
--model-id Qwen/Qwen2.5-7B-Instruct \
--max-input-length 2048 --max-total-tokens 4096Pilihan vLLM vs TGI sering soal preferensi tim dan fitur; keduanya menyediakan API kompatibel OpenAI, jadi migrasi antar keduanya relatif mulus.
#Ollama dan llama.cpp untuk Lokal/Edge
Untuk prototipe dan edge, Ollama (sudah dipakai sejak episode 0) tetap pilihan tercepat. Untuk CPU/RAM terbatas, model GGUF lewat llama.cpp (backend Ollama) adalah jalannya:
ollama pull qwen3:1.5b
ollama run qwen3:1.5b "hallo"Model 1-4B di CPU tidak secepat GPU, tapi cukup untuk banyak tugas sederhana dan berjalan di laptop/Raspberry Pi.
Warning
Jangan membandingkan vLLM di GPU dengan Ollama di CPU lalu menyimpulkan "model lokal lambat". Serve yang benar = model yang benar + hardware yang benar. Model 1-4B di CPU OK untuk tugas sederhana; model 7B+ butuh GPU untuk produksi.
#Common Pitfalls
- Tanpa continuous batching: memakai server inference tanpa batching = GPU mahal menganggur.
- Model terlalu besar untuk GPU: pilih model/quantisasi yang muat di VRAM dengan sisa untuk KV-cache (episode 22).
- Tidak load test: deploy langsung tanpa mengukur = kejutan di traffic pertama.
- Mengabaikan OpenAI-compat API: memakai endpoint proprietary server inference mengunci kode ke satu vendor.
#Penutup
Inti yang harus dibawa pulang:
- Peta serving: vLLM/TGI produksi GPU, Ollama dev/lokal, llama.cpp edge/CPU.
- vLLM = continuous batching + PagedAttention; throughput jauh lebih tinggi.
- Ukur throughput dan p99 latency dengan load test workload nyata.
- Server inference modern menyediakan OpenAI-compatible API — abstraksi penyedia tetap bekerja.
Di episode 22 selanjutnya kita mengoptimasi sisi biaya: scaling & cost optimization — batching, caching, model routing, dan quantization untuk menekan biaya inference tanpa mengorbankan kualitas. Sampai jumpa di episode 22!