Belajar MLOps - Cost & GPU Optimization

#Pendahuluan

Setelah episode 21 membangun platform GenAI, saatnya bicara hal yang biasanya baru disadari setelah tagihan cloud pertama datang: biaya. GPU adalah komponen hardware termahal yang biasa dipakai MLOps, dan dengan GenAI, biaya tidak lagi hanya soal instance — ia juga soal token yang dibayar per pemakaian.

Mengapa cost optimization penting? Karena model yang bagus tapi terlalu mahal tidak akan bertahan. Di industri, perbedaan antara tim yang modelnya di-deploy dan yang hanya jadi riset sering kali bukan kualitas model, melainkan ekonominya — berapa rupiah per seribu prediksi. Episode ini membedah GPU utilization, quantization, batching, dan strategi cost management.

#Mengukur GPU Utilization: Mulai dari Data

Anda tidak bisa mengoptimalkan apa yang tidak diukur. GPU utilization bukan soal seberapa keras GPU bekerja sesekali — ia soal seberapa produktif GPU mengisi waktu-nya.

nvidia-smi --query-gpu=utilization.gpu,memory.used \
  --format=csv -l 5

Untuk pengukuran berkelanjutan di produksi, gunakan DCGM (Data Center GPU Manager) yang diekspor ke Prometheus (episode 12). Target utilization yang sehat untuk inference biasanya 50-80%; di bawah itu, kalian membayar GPU yang menganggur.

#Quantization: Presisi Rendah, Biaya Rendah

Model dilatih di FP32, tetapi untuk inference tidak semua presisi itu diperlukan. Quantization menurunkan presisi angka sehingga model lebih kecil, lebih cepat, dan hemat memory:

• FP16/BF16 — setengah presisi; hampir tanpa kehilangan kualitas, standar untuk training dan inference modern.
• INT8 — seperempat presisi; penurunan kualitas kecil, cocok untuk serving.
• INT4 — ekstrem untuk LLM (dipakai banyak model terkuantisasi).

Contoh quantisasi dinamis dengan PyTorch:

model_int8 = torch.quantization.quantize_dynamic(
    model, {torch.nn.Linear}, dtype=torch.qint8
)

Aturan wajib: quantisasi tanpa evaluasi itu berbahaya — selalu bandingkan metrik model original vs terkuantisasi pada dataset evaluasi (episode 15) sebelum promosi.

#Batching: Mengisi GPU

GPU dirancang untuk komputasi paralel besar. Satu request kecil memakai GPU yang sama dengan satu batch besar, hanya lebih boros. Dynamic batching menggabungkan beberapa request yang datang bersamaan menjadi satu batch — throughput naik drastis, dengan trade-off latency per request sedikit naik (pembahasan lanjutan di episode 23).

Tanpa batching:  10 request × 20ms (berurutan)  → 200ms per batch slot
Dengan batching: 10 request × 25ms (satu batch) → 25ms per request

Frameworks serving seperti Triton, TorchServe, dan KServe mendukung dynamic batching bawaan — aktifkan, lalu ukur trade-off latency vs throughput.

#Knowledge Distillation: Model Kecil

Model besar mengajarkan model kecil: distillation melatih student model agar meniru teacher model yang lebih akurat. Hasilnya: model dengan sebagian kecil ukuran dan biaya, mempertahankan sebagian besar kualitas. Ini keputusan arsitektur paling efektif untuk inference cost jangka panjang — satu kali investasi training, hemat di setiap prediksi.

#Strategi Cost Management

• Spot/preemptible instance untuk training — training toleran terhadap interrupt; diskon hingga 60-90%.
• Autoscaling dan scale-to-zero — inference yang sepi di malam hari tidak perlu instance 24/7 (episode 17).
• Budget alert di semua level — per instance, per model, per tim.
• Weight/model cache — jangan unduh ulang weights besar di tiap job; cache di artifact store (episode 5).
• Pilih model yang tepat — model kecil sering cukup; "selalu pakai model terbesar" adalah cara tercepat membakar budget (episode 21).

Untuk LLM via API, biaya adalah per token — maka metric biaya per pertanyaan menjadi wajib di platform:

cost_per_question = (input_tokens × input_price + output_tokens × output_price)

#Praktik: Kurangi Cost Inference

Alur yang disarankan, dari yang paling mudah:

1. Ukur utilization — cari GPU yang menganggur.
2. Aktifkan batching di serving framework.
3. Terapkan quantization (FP16, lalu INT8) dengan evaluasi.
4. Autoscale — matikan instance saat sepi.
5. Jika masih mahal: distillation untuk model yang lebih kecil.

Setiap langkah diukur sebelum dan sesudah — cost per 1000 prediksi adalah satu-satunya metrik yang menentukan.

#Common Pitfalls

• Utilisasi rendah tapi instance tetap 24/7 — pemborosan terbesar yang paling mudah diperbaiki.
• Quantisasi tanpa evaluasi kualitas — model rusak diam-diam; selalu bandingkan metrik.
• Batching menaikkan latency melewati SLO — ukur p95 setelah batching aktif (episode 23).
• Mengabaikan biaya token LLM — API model besar bisa lebih mahal daripada GPU sendiri.
• Optimasi tanpa pengukuran — tebakan, bukan engineering; ukur dulu.

#Penutup

Pada episode 22 ini, kalian telah mengoptimalkan biaya dan GPU.

Inti yang harus dibawa pulang:

• Ukur utilization dulu — target sehat 50-80%, di bawahnya GPU menganggur.
• Quantization (FP16 → INT8) mengecilkan dan mempercepat model; selalu dievaluasi.
• Dynamic batching mengisi GPU, throughput naik dengan trade-off latency.
• Distillation memberi model kecil dengan kualitas tinggi — hemat jangka panjang.
• Cost per prediksi adalah metrik yang menentukan kelangsungan hidup model.

Di episode 23 selanjutnya kita akan membahas performance & latency tuning — latency SLO, optimisasi model, caching hasil prediksi, dan teknik menurunkan latensi inference. Sampai jumpa di episode 23!