Belajar AI - Scale & Cost Optimization

#Pendahuluan

Setelah di episode 18 kalian men-deploy model ke produksi dengan MLOps yang benar, episode ini membahas masalah yang paling banyak membuat CFO (dan founder) tegang: biaya. Inference LLM tidak murah, dan aplikasi yang tidak mengoptimalkan biaya bisa membakar ratusan ribu rupiah per hari tanpa disadari.

Mengapa episode ini penting? Karena skala dan biaya adalah keputusan arsitektur, bukan sekadar administrasi. Pilihan model, kuantisasi, caching, dan routing menentukan apakah produk AI kalian bisa sustain — atau mati sebelum sempat berkembang. Episode ini memberi toolkit lengkap untuk skala besar tanpa biaya besar.

#Memahami Biaya Inference

Harga inference ditentukan oleh tiga hal:

1. Jumlah token input + output (API) atau GPU-hours (self-host).
2. Ukuran model: model 7B vs 70B — perbedaan biaya per request bisa puluhan kali lipat.
3. Infrastruktur: GPU idle tetap berbayar di self-host; API membayar per pemakaian.

Rumus mental yang berguna: biaya = volume request × token per request × harga per token. Optimasi menyentuh ketiga pengali sekaligus.

#GPU Inference: Memahami Bottleneck

Inference LLM sering memory-bound, bukan compute-bound — bottleneck-nya memindahkan bobot model dari HBM ke register, bukan menghitung. Konsekuensi praktisnya:

• KV cache (mengalokasikan memori untuk konteks tiap request) adalah pembatas utama concurrency.
• Batching beberapa request bersama memanfaatkan GPU lebih efisien — ini alasan vLLM (episode 18) jauh lebih cepat dan murah daripada inference satu-per-satu.
• Ukuran model harus muat di VRAM GPU — menentukan pilihan GPU dan kuantisasi.

nvidia-smi

#Kuantisasi: GGUF, AWQ

Kuantisasi menurunkan presisi bobot model (dari 16-bit ke 8/4-bit), memangkas ukuran memori 2-4x dengan degradasi kualitas yang biasanya kecil. Dua pendekatan populer:

ollama run qwen3:8b-q4_K_M

Dampaknya: model 8B yang butuh 16GB VRAM di FP16 bisa jalan di 4-5GB dengan Q4 — satu tingkat kuantisasi biasanya cukup untuk memangkas kebutuhan hardware tanpa merusak kualitas.

#Caching: Jawaban Serupa Tidak Dihitung Dua Kali

Banyak request nyata berulang atau hampir sama. Caching menyimpan hasil untuk dipakai ulang:

• Exact cache: prompt yang persis sama → jawaban dari cache (misal pertanyaan FAQ, query yang sama dari banyak user).
• Semantic cache: prompt yang mirip (lewat embedding & threshold cosine similarity, episode 13) → kembalikan jawaban cache.

from sentence_transformers import SentenceTransformer
import numpy as np
 
model = SentenceTransformer("all-MiniLM-L6-v2")
cache: list[tuple[np.ndarray, str]] = []
 
def get_cached(prompt: str, threshold: float = 0.95):
    vec = model.encode([prompt])
    for key_vec, answer in cache:
        if np.dot(vec, key_vec.T) > threshold:
            return answer
    return None
 
def cache_answer(prompt: str, answer: str):
    cache.append((model.encode([prompt]), answer))

Kombinasi exact + semantic cache sering memangkas biaya 30-60% di aplikasi dengan lalu lintas berulang (chatbot support, FAQ, copilot).

#Batching dan Concurrency

Batching menggabungkan banyak request dalam satu forward pass. Di vLLM ini disebut continuous batching: request masuk dan keluar sepanjang waktu, GPU tidak pernah menganggur. Efeknya: throughput naik berkali lipat dengan hardware yang sama — biaya per request turun drastis. Jika kalian self-host LLM, pastikan memakai server yang mendukung continuous batching (vLLM, TGI), bukan inference satu-per-satu.

#Model Routing: Kecil untuk yang Mudah

Tidak semua request butuh model besar. Model routing mengarahkan request ke model yang sesuai tingkat kesulitannya:

Pola routing:

1. Rule-based: query yang cocok pola (FAQ, format tertentu) → model kecil.
2. Task-based: tugas spesifik (ekstraksi, klasifikasi) → model khusus kecil; tugas bebas → model besar.
3. Cascade: coba model kecil dulu; jika skor confidence rendah, naikkan ke model besar.
4. Learned routing: classifier (bisa model kecil sendiri) memutuskan rute.

Efeknya: 70-80% request diarahkan ke model kecil → biaya turun drastis, latency turun — tanpa mengorbankan kualitas request yang memang sulit.

#Hybrid: Self-Host vs API

Keputusan biaya terbesar adalah di mana model dijalankan:

Strategi hybrid memadukan keduanya:

• Baseline volume tinggi (chat umum, summarization rutin) → self-host model open-weight yang "cukup baik" → biaya marginal nyaris nol.
• Kasus sulit / kritis (reasoning kompleks, tugas high-stakes) → API model besar terbaik.
• Data sensitif → self-host wajib (episode 17).

Dengan routing di atas, hybrid memastikan model besar hanya dipakai saat benar-benar diperlukan.

#Common Pitfalls

• Self-host semua hal tanpa volume: GPU idle lebih mahal daripada API per-request.
• Tanpa caching: membayar berulang untuk jawaban yang sama.
• Tanpa batching: GPU bekerja 10%, biaya tetap 100%.
• Kuantisasi tanpa evaluasi: kualitas turun diam-diam.
• Model besar untuk semua request: membakar biaya untuk tugas yang bisa dikerjakan model kecil.

#Penutup

Inti yang harus dibawa pulang:

• Biaya inference = volume × token per request × harga per token; optimasi menyentuh ketiganya.
• Kuantisasi (GGUF, AWQ) memangkas kebutuhan hardware 2-4x — selalu evaluasi dampaknya.
• Caching (exact + semantic) dan batching memangkas biaya di lalu lintas berulang.
• Model routing (kecil untuk mudah, besar untuk sulit) dan strategi hybrid self-host + API adalah arsitektur biaya yang berkelanjutan.

Di episode 20 selanjutnya kita masuk ke batas terdepan: Multimodal AI — model yang memproses teks, gambar, audio, dan video sekaligus, use case seperti vision QA dan speech, plus praktik RAG multimodal dan pipeline image/audio understanding. Sampai jumpa di episode 20!