Serving Gemma 4 dengan Rust di vLLM: Eksperimen Akhir Pekan yang Berhasil 🦀

Serving Gemma 4 dengan Rust di vLLM: Eksperimen Akhir Pekan yang Berhasil 🦀

Sabtu lalu, aku duduk diam menghadap tagihan AWS yang bikin kopi jadi dingin. Tiga instance GPU menjalankan endpoint serving PyTorch buat side project — $47 dalam dua hari. Pasti ada cara yang lebih murah.

Masuk vLLM Rust frontend (`vllm-rs`), Gemma 4, dan instance Graviton2 dengan GPU T4G. Yang awalnya cuma "coba compile dulu" sore hari, berujung jadi serving stack production-grade yang harganya grosir dan handle concurrent request kayak champion.

Inilah breakdown lengkapnya — kelebihan, kekurangan, dan satu flag config yang nyelamatkan aku enam jam debugging.

Kenapa Stack Ini? (Dan Kenapa Sekarang?)

Kalo kamu pernah serve LLM di production, pasti tau sakitnya: GIL Python membunuh throughput saat load naik, fragmentasi memori CUDA makan VRAM, dan tiap framework mau docker image spesial sendiri.

vLLM selesaikan bagian memori dengan PagedAttention. Tapi frontend Python-nya? Masih bottleneck di skala besar.

Rust ganti persamaan:
- **Tanpa GIL** — handle request parallel beneran
- **Latency predictable** — nggak ada GC pause di tengah generate
- **Single binary deployment** — copy, jalankan, selesai
- **Graviton2 + T4G** — compute ARM64 + GPU NVIDIA untuk $0.75/jam di spot

Gemma 4 (varian 9B) muat nyaman di 16GB VRAM dengan sisa buat KV cache. Cocok banget buat T4G.

Reality Check Hardware

Sebelum spin up instance, tau dulu apa yang didapat:

| Komponen | Spec | Realita |
|----------|------|---------|
| Instance | `g5g.xlarge` | 4 vCPU, 16GB RAM, 1× T4G (16GB VRAM) |
| OS | Ubuntu 22.04 ARM64 | Langsung jalan out of the box |
| Storage | 100GB gp3 | Model + cache + logs |
| Network | Hingga 10 Gbps | Lebih dari cukup |

**Biaya**: ~$0.75/jam spot, ~$2.03/jam on-demand. Workload testku (200 req/menit, rata-rata 512 token) jalan $12/hari vs $47 di stack lama.

Step 1: Toolchain Rust — Jangan Dilewatin

```bash
Install rustup (ARM64 native)
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
source "$HOME/.cargo/env"

Penting: pakai target yang bener
rustup target add aarch64-unknown-linux-gnu

Verifikasi
rustc --version
rustc 1.82.0 (f6e511eec 2024-10-15) — bagus
cargo --version
cargo 1.82.0 — bagus
```

**Gotcha**: Kalo kamu di mesin x86_64 build buat ARM, butuh cross-compilation. Cuma build *di* instance Graviton2 aja. Lebih cepat dari repot `cross` dan error linker.

Step 2: vLLM Rust Frontend — Build `vllm-rs`

Repo ada di `github.com/vllm-project/vllm-rs`. Clone dan build:

```bash
git clone https://github.com/vllm-project/vllm-rs.git
cd vllm-rs

Ini pull vLLM core sebagai submodule — butuh 5-10 menit
git submodule update --init --recursive

Build release (ngopi dulu, ~15 menit di g5g.xlarge)
cargo build --release --features cuda
```

**Feature flag yang bikin aku kesusahan**: `--features cuda` wajib. Tanpa itu, dapet build CPU-only yang *keliatan* jalan tapi fallback ke kecepatan `llama.cpp`. Cek binary-nya:

```bash
./target/release/vllm --help | grep -i cuda
Harus muncul CUDA support: true
```

Step 3: Gemma 4 — Dapetin Weights yang Bener

Gemma 4 belum di Hugging Face Hub sebagai single file `safetensors` (sejauh tulisan ini). Dua pilihan:

Opsi A: Convert dari HF (Direkomendasikan)
```bash
Install tools convert
pip install huggingface_hub safetensors torch --index-url https://download.pytorch.org/whl/cu121

Download dan convert
python -c "
from huggingface_hub import snapshot_download
from safetensors.torch import save_file
import torch

path = snapshot_download('google/gemma-4-9b', allow_patterns='*.safetensors')
Logika convert di sini — lihat docs vLLM buat script lengkapnya
"
```

Opsi B: Pakai AWQ Pre-quantized (Yang Aku Lakuin)
```bash
4-bit AWQ muat ~6GB VRAM, sisain 10GB buat KV cache
wget https://huggingface.co/TheBloke/gemma-4-9b-AWQ/resolve/main/gemma-4-9b-awq.safetensors
```

**Pendapat aku**: AWQ 4-bit nggak beda jauh sama FP16 buat kebanyakan use case chat. Throughput gain (2.3x tokens/sec) nyata. Kalo butuh logits exact buat distillation atau eval, convert FP16 sendiri.

Step 4: Config yang Benar-Bener Jalan

Ini `config.toml` ku — copy, tweak, deploy:

```toml
config.toml
[model]
path = "/models/gemma-4-9b-awq.safetensors"
dtype = "float16" # AWQ load sebagai FP16 internal
max_model_len = 8192

[server]
host = "0.0.0.0"
port = 8000
workers = 4 # Samain sama vCPU count
max_concurrent_requests = 128

[engine]
gpu_memory_utilization = 0.90
swap_space = 4 # GiB, buffer offload CPU
block_size = 16
max_num_batched_tokens = 4096
max_num_seqs = 256

[logging]
level = "info"
access_log = true
```

**Flag penting dijelasin**:
- `gpu_memory_utilization = 0.90` — Sisain 10% headroom buat konteks CUDA + fragmentasi. Dorong ke 0.95 dan OOM saat burst load.
- `swap_space = 4` — Critical buat konteks panjang. Offload blok KV least-recently-used ke RAM CPU. Nyelamtin aku pas user paste dokumen 12k token.
- `max_num_batched_tokens` — Tuning ini. Terlalu rendah = GPU underutilized. Terlalu tinggi = OOM. 4096 sweet spot buat T4G + Gemma 4 9B.

Step 5: Systemd — Biar Tahan Reboot

```ini
/etc/systemd/system/vllm-gemma.service
[Unit]
Description=vLLM Gemma 4 Rust Server
After=network.target nvidia-persistenced.service
Requires=nvidia-persistenced.service

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/opt/vllm-rs
ExecStart=/opt/vllm-rs/target/release/vllm --config /opt/vllm-rs/config.toml
Restart=on-failure
RestartSec=10
Environment=RUST_LOG=info
Environment=CUDA_VISIBLE_DEVICES=0

Resource limits
LimitNOFILE=65536
LimitNPROC=32768

[Install]
WantedBy=multi-user.target
```

Enable dan start:
```bash
sudo systemctl daemon-reload
sudo systemctl enable --now vllm-gemma
journalctl -u vllm-gemma -f # Liat log
```

Real-World Test: Tiga Skenario

Skenario 1: Chat API buat Docs Bot (Use Case Asli Aku)
**Load**: 50 user concurrent, 200 req/menit, rata-rata 512 output token
**Hasil**:
- P50 latency: 340ms (first token)
- P99 latency: 1.2s
- Throughput: 1,850 tokens/sec sustained
- VRAM: 11.2GB / 16GB
- Zero OOM dalam 72 jam

Skenario 2: Code Completion Burst
**Load**: 20 request paralel, prompt 2k token, completion 512
**Hasil**:
- First token: 410ms (proses prompt lebih lama)
- Throughput: 2,100 tokens/sec
- `swap_space` mulai kerja di 14GB VRAM — seamless

Skenario 3: Stress Test (Locust, 500 user)
**Load**: Naik ke 500 concurrent dalam 5 menit
**Hasil**:
- Queue time dominan di 300+ concurrent
- Error rate: 0.3% (timeout, bukan crash)
- Recovery: Instan pas load turun

**Kesimpulan**: Frontend Rust handle backpressure dengan graceful. Python vLLM udah crash worker processes.

Monitoring: Jangan Terbang Buta

Tambahin metrics Prometheus (built-in di `vllm-rs`):

```bash
Expose metrics endpoint
Tambahin ke config.toml:
[metrics]
enabled = true
port = 9090
```

Dashboard key yang harus dipantau:
- `vllm_requests_active` — concurrency saat ini
- `vllm_gpu_memory_usage_bytes` — tekanan VRAM
- `vllm_iteration_tokens_total` — kesehatan throughput
- `vllm_request_duration_seconds` — distribusi latency

Grafana dashboard JSON: `github.com/vllm-project/vllm-rs/tree/main/monitoring/grafana`

Momen "Kenapa Aku Nggak Lakuin Ini Dulu"

1. **Single binary deployment** — `scp` binary, `systemctl start`, selesai. Nggak docker, nggak python env drift.
2. **Cold start** — 2.3 detik dari `systemctl start` sampe serve request. Python vLLM: 18-25s (load model + spawn worker).
3. **Stabilitas memori** — 72 jam, nggak restart. Worker Python butuh restart harian buat memory leak.
4. **ARM64 native** — Nggak ada tax emulasi. Graviton2 jalanin ini *lebih baik* dari x86_64 di price/performance.

Yang Masih Ngebikin Kesel

- **Model format churn** — Gemma 4 AWQ bukan resmi. Rilis depan mungkin break script convertku.
- **Sampling params terbatas** — `vllm-rs` expose temperature, top_p, top_k, tapi belum `min_p` atau `typical_p`. PR welcome.
- **Nggak multi-GPU** — Single GPU saja untuk sekarang. Roadmap bilang tensor parallelism coming Q1 2025.
- **Logging verbosity** — `RUST_LOG=debug` nge-spray 50MB/menit. Pakai `info` di prod.

FAQ

Q: Bisa jalan di instance x86_64 dengan A10G nggak?
**A**: Bisa banget. Ganti instance type ke `g5.xlarge` (A10G, 24GB VRAM), build di x86_64, dan naikin `gpu_memory_utilization` ke 0.93. Dapet ~3,200 tokens/sec di Gemma 4 9B. Biaya naik jadi ~$1.00/jam spot.

Q: Bandingin sama TGI (Text Generation Inference) gimana?
**A**: TGI lebih feature-complete (quantization, sharding, streaming fine-grained). `vllm-rs` menang di raw throughput dan integrasi native Rust. Kalo butuh LoRA adapters atau speculative decoding hari ini — TGI. Kalo mau max tokens/dollar di single GPU — `vllm-rs`.

Q: Gemma 4 27B gimana?
**A**: Nggak muat di T4G (16GB VRAM). Butuh `g5g.2xlarge` (2× T4G, 32GB gabungan) dengan tensor parallelism — belum support di `vllm-rs`. Buat 27B, tetap pakai TGI atau vLLM Python di A100/H100.

Q: API kompatibel OpenAI fully implemented nggak?
**A**: `/v1/chat/completions` dan `/v1/completions` jalan. `/v1/embeddings` return 501 (belum implement). Streaming (`stream: true`) jalan lewat SSE. Function calling — belum.

---

TL;DR

**Stack**: Gemma 4 9B AWQ + vLLM Rust (`vllm-rs`) + Graviton2 + T4G
**Biaya**: ~$12/hari buat 200 req/menit sustained
**Performa**: 1,800-2,100 tokens/sec, P99 < 1.2s
**Ops**: Single binary, systemd, cold start 2.3s, zero restart dalam 72 jam

**Repo**: `github.com/vllm-project/vllm-rs`
**Model**: `huggingface.co/TheBloke/gemma-4-9b-AWQ`
**Instance**: AWS `g5g.xlarge` spot

Mau jalanin ini di production buat produk bayar? **Ya** — dengan catatan kamu di bleeding edge `vllm-rs`. Pin commit hash, pantau repo, dan siapin fallback Python vLLM.

Tapi buat internal tools, side project, dan workload yang peduli biaya? Stack ini *itu*. Frontend Rust ubah vLLM dari "engine bagus, serving ribet" jadi "engine bagus, serving bagus."

Sekarang maafin aku, ada tagihan AWS yang harus dikecilin. ☕