Belajar MLOps - Performance & Latency Tuning

#Pendahuluan

Setelah episode 22 menekan biaya, kita berurusan dengan sisi lain dari keseimbangan: kecepatan. Model yang akurat dan murah tetapi lambat tidak akan dipakai — pengguna pergi sebelum jawaban tiba, dan SLO bisnis dilanggar. Latency adalah harga tiket untuk masuk ke produksi.

Mengapa latency tuning penting? Karena latensi yang buruk tidak selalu terlihat di p50 — ia meledak di p99: pengguna yang paling tidak beruntung, yang akhirnya paling vokal. Episode ini membahas menetapkan latency SLO, mengukurnya dengan benar, mengoptimalkan model, dan memakai caching — semuanya dengan pendekatan berbasis data, bukan intuisi.

#Latency SLO: Tentukan Target Dulu

Sebelum tuning, tentukan apa arti "cukup cepat" — dalam bentuk yang terukur:

SLO inference:  p95 < 300ms   (95% request selesai di bawah 300ms)
                p99 < 600ms
                error rate < 0.5%

SLO yang baik memecah budget latensi ke setiap komponen — karena optimasi tidak mungkin dilakukan di "seluruh sistem" sekaligus:

request masuk → auth (2ms) → feature lookup (15ms) → preprocess (8ms)
              → inference (90ms) → postprocess (3ms) → total ~118ms

Dengan breakdown ini, kalian tahu persis di mana bottleneck berada — dan di mana optimasi memberi dampak terbesar.

#Mengukur dengan Benar

Ukur dengan load test yang mewakili traffic nyata, bukan permintaan tunggal di lokal. k6 adalah alat yang sederhana dan banyak dipakai:

Load test dengan k6

import http from "k6/http";
 
export const options = {
  vus: 20,
  duration: "30s",
};
 
export default function () {
  http.post(
    "http://churn-svc:8080/predict",
    JSON.stringify({ age: 45, charges: 89.9 }),
    { headers: { "Content-Type": "application/json" } },
  );
}

Ingat: ukur di environment yang mirip produksi — hasil di mesin lokal hampir selalu menipu.

#Optimisasi Model

Lapisan optimasi, dari yang paling umum:

• Quantization — FP16/INT8 (episode 22): lebih kecil dan lebih cepat.
• Compilation — ekspor model ke format terkompilasi: ONNX Runtime atau TensorRT di GPU. Compiler mengoptimalkan graph operasi, terkadang 2-5x lebih cepat.

import torch.onnx
 
torch.onnx.export(
    model, dummy_input, "churn.onnx",
    opset_version=17,
    dynamic_axes={"input": {0: "batch"}},
)

• Pruning — buang bobot yang mendekati nol; graph lebih kecil dan sparse.
• Distillation — model kecil hasil mengajar model besar (episode 22).

#Caching Hasil Prediksi

Banyak request itu berulang — query yang sama, pengguna yang sama. Cache hasil prediksi menghilangkan kerja inference yang seharusnya tidak perlu diulang.

redis-cli SETEX "pred:age45:charges89" 3600 '{"churn_prob":0.83}'

Cache paling efektif ketika: input berulang tinggi, hasil tidak berubah sering, dan toleran terhadap sedikit basi. Fitur yang diambil dari online store (episode 14) juga memakai cache yang sama. Jangan lupa: cache harus di-invalidasi saat model baru dipromosikan.

#Teknik Khusus LLM

Untuk LLM, ada dua teknik yang menonjol:

• KV cache — hasil komputasi token yang sudah dihasilkan disimpan untuk prompt berikutnya; percepatan besar untuk multi-turn conversation.
• Speculative decoding — model kecil mendraft jawaban, model besar memverifikasi; percepatan nyata tanpa mengubah output.
• Prefetch/pipeline — generate token berikutnya sambil stream token sebelumnya.

Dua teknik pertama sudah didukung bawaan oleh serving framework modern — cukup diaktifkan dan diukur.

#Urutan Tuning yang Benar

Optimasi latency adalah iterasi berbasis data:

1. Ukur breakdown latency per komponen.
2. Profil — temukan komponen terbesar.
3. Perbaiki bottleneck terbesar (satu per satu).
4. Ukur ulang — verifikasi perbaikan, jangan asumsikan.
5. Ulangi sampai SLO tercapai, lalu berhenti.

#Common Pitfalls

• Optimasi tanpa SLO — tidak tahu kapan harus berhenti.
• Hanya melihat p50 — p99 adalah tempat masalah sebenarnya bersembunyi.
• Cache tanpa invalidasi — pengguna mendapat prediksi basi setelah model baru.
• Mengukur di environment non-produksi — hasil tidak merepresentasikan traffic nyata.
• Quantisasi model yang latency-nya sudah cukup — menambah risiko tanpa manfaat; ukur dulu.

#Penutup

Pada episode 23 ini, kalian telah men-tuning latensi inference.

Inti yang harus dibawa pulang:

• Tetapkan latency SLO (p95/p99) dan breakdown budget per komponen.
• Ukur dengan load test yang mewakili traffic nyata.
• Optimasi model: quantization, compilation (ONNX/TensorRT), pruning.
• Cache hasil prediksi untuk request berulang, dengan invalidasi yang benar.
• LLM: manfaatkan KV cache dan speculative decoding.
• Optimasi berbasis data: ukur → profil → perbaiki → ukur ulang.

Di episode 24 selanjutnya kita akan membahas multi-model & multi-cloud — merancang serving platform multi-tenant, model router, dan strategi menjalankan model di banyak cloud. Sampai jumpa di episode 24!