Teknovidia-Di 2025, optimasi komputasi saat inference menjadi faktor penentu biaya, kecepatan, dan kualitas pengalaman pengguna. Entah Anda menjalankan model visi di edge device, LLM di server GPU, atau rekomendasi real-time di aplikasi, trik ampuh optimasi komputasi saat inference bisa memangkas latensi, menghemat budget, dan memperpanjang umur hardware Anda. Pertanyaannya: teknik mana yang paling efektif, berapa dampak riilnya, dan bagaimana memulainya tanpa menghancurkan akurasi?
Masalah Utama yang Harus Diselesaikan: Latensi Tinggi, Biaya Membengkak, dan Model “Overkill”
Banyak tim ML/AI terjebak dalam pola yang sama: model akurat di laboratorium, tetapi lambat saat produksi dan mahal dijalankan. Biaya GPU melonjak karena throughput rendah. Latensi P95 jauh di atas SLO. Edge device kehabisan memori. Aplikasi GenAI terasa lemot saat memulai respons (TTFT tinggi), membuat pengguna “cabut” sebelum membaca jawaban. Intinya, tanpa optimasi inference, ROI AI susah dicapai.
Masalah umum yang kami lihat di banyak organisasi di 2025 meliputi: model oversize (misalnya LLM 70B untuk use case yang sebenarnya bisa dilayani 7B atau 13B dengan distilasi), pipeline yang tak efisien (tokenizer bottleneck di CPU, tidak ada batching dinamis), runtime generik (belum memakai engine optimized seperti TensorRT/ONNX Runtime/OpenVINO), dan tidak ada observabilitas yang kuat (pengukuran TTFT, TBT, P95/99, GPU util, mem bandwidth, NUMA, tidak konsisten).
Efeknya konkret. Aplikasi streaming video-analytics dengan model deteksi objek tak bisa real-time karena inference >70 ms per frame, padahal target 33 ms. Chatbot LLM memerlukan 1–2 GPU A100 per 50 pengguna aktif karena continuous batching belum dipakai. Startup ritel mengeluh biaya GPU 2–3 kali di atas proyeksi karena tidak menurunkan presisi ke FP16/INT8. Semua itu bisa dihindari dengan kombinasi optimasi arsitektur model, runtime, dan orkestrasi serving.
Hook untuk Anda: ada teknik yang secara umum memberi akselerasi 1,5–4x dan penghematan memori 2–4x, tanpa degradasi akurasi berarti pada banyak kasus praktis. Kuncinya adalah memilih strategi yang sesuai beban kerja dan mengukur dampaknya secara disiplin.
Strategi 1 — Optimasi Arsitektur Model: Kuantisasi, Pruning, dan Distilasi
Optimasi dimulai dari model itu sendiri. Tiga teknik paling berdampak adalah kuantisasi (quantization), pruning, dan distilasi pengetahuan (knowledge distillation). Ketiga teknik ini dapat digunakan terpisah atau dikombinasikan, bergantung pada target latensi, footprint memori, dan toleransi penurunan akurasi.
Kuantisasi menurunkan presisi bobot/aktivasi (mis. FP32 ke FP16/INT8). Dampak umum yang sering dilaporkan komunitas: FP16 memberi akselerasi 1,3–1,8x di GPU modern dengan dukungan tensor core; INT8 menghemat memori sampai ~4x dengan potensi speedup 1,5–3x, tergantung operator dan hardware. Untuk workload CPU/edge, INT8 sangat efektif, terutama bila menggunakan engine seperti ONNX Runtime atau OpenVINO. Agar akurasi terjaga, gunakan teknik post-training quantization (PTQ) dengan kalibrasi representatif, atau quantization-aware training (QAT) bila dataset training tersedia.
Pruning menghapus bobot/kanal yang kurang penting. Structured pruning (misalnya pruning channel/filter pada CNN) memudahkan speedup nyata di inference karena memetakan langsung ke kernel yang lebih kecil. Dampak tipikal: 20–50% pengurangan parameter dengan penurunan akurasi minimal setelah fine-tuning. Di edge vision, model YOLO/ResNet yang dipruning dengan baik sering masuk target latensi real-time pada CPU/GPU kelas menengah.
Distilasi mengecilkan model “guru” ke model “murid” yang lebih ringan. Untuk LLM, distilasi dari 70B ke 7–13B dengan data instruksi berkualitas bisa mempertahankan kemampuan inti untuk banyak tugas, dengan latensi dan biaya jauh lebih rendah. Di dunia visi dan NLP klasik, distilasi bertahun-tahun terbukti ampuh untuk memangkas ukuran tanpa kehilangan performa berarti. Distilasi sering dipasangkan dengan quantization dan pruning sehingga efeknya kumulatif.
Contoh skenario realistis: sebuah asisten penulisan internal awalnya memakai LLM 33B FP32. Setelah migrasi ke model 13B hasil distilasi + FP16 + beberapa layer di-prune ringan, tim melihat penghematan memori >60% dan percepatan throughput 2–3x, dengan kualitas jawaban yang tetap memuaskan berdasarkan evaluasi internal. Kuncinya adalah mengukur dampak pada metrik bisnis (CSAT, waktu tunggu) di samping metrik teknis (perplexity, BLEU, ROUGE, atau pass@k).
Rekomendasi praktis: mulailah dengan FP16 atau BF16 untuk GPU, INT8 untuk CPU/edge; terapkan PTQ dengan kalibrasi yang representatif; lakukan A/B terhadap akurasi dan latensi; lanjutkan ke QAT bila akurasi belum memadai. Gabungkan dengan structured pruning dan, bila perlu, distilasi untuk skala manfaat yang lebih besar.
Strategi 2 — Runtime dan Kompilasi: TensorRT, ONNX Runtime, OpenVINO, Core ML, dan XLA
Setelah model siap, pilih runtime yang dapat mengoptimalkan graf komputasi, melakukan operator fusion, memilih kernel terbaik, dan memanfaatkan akselerator hardware. Opsi populer: NVIDIA TensorRT untuk GPU NVIDIA; ONNX Runtime lintas platform (CPU, GPU, DirectML, TensorRT EP); OpenVINO untuk CPU/VPU Intel; Core ML Tools untuk Apple Silicon; serta ekosistem OpenXLA untuk kompilasi graf canggih.
TensorRT terkenal memberikan speedup signifikan untuk visi dan beberapa arsitektur transformer, sering kali 1,5–4x dibanding eksekusi eager, dengan latensi lebih stabil. ONNX Runtime mempermudah deployment lintas device dan integrasi backend (Execution Provider) berbeda, cocok untuk pipeline heterogen. OpenVINO mengoptimalkan inferensi di CPU Intel dengan memanfaatkan vektor instruksi dan layout memori yang efisien. Di perangkat Apple, konversi ke Core ML dan pemanfaatan Neural Engine dapat memangkas konsumsi daya sekaligus mempercepat inferensi.
Di PyTorch 2.x, gunakan torch.compile untuk memicu optimisasi graf, operator fusion, dan kernel khusus. Untuk workload tertentu, ini bisa memangkas latensi tanpa perubahan arsitektur. Pastikan profiling dengan input shape representatif; pertimbangkan teknik shape specialization untuk beban kerja dengan panjang input yang relatif tetap. Di TensorFlow/JAX, gunakan XLA untuk kompilasi just-in-time, terutama pada model dengan pola komputasi berulang.
Pengalaman lapangan yang sering terjadi: tim yang berpindah dari PyTorch eager ke ONNX Runtime/TensorRT dengan FP16 biasanya memperoleh penurunan latensi p50 30–60% dan throughput naik 1,5–2,5x, bergantung pada operator dan hardware. Tantangan utama ada di kompatibilitas operator dan waktu konversi; karena itu, lakukan audit operator (opset) sedari awal dan siapkan fallback. Lakukan cold-start vs warm-start measurement; beberapa engine memerlukan waktu warmup untuk mencapai performa puncak.
Tips cepat: cache engine yang sudah dikompilasi, aktifkan operator fusion, gunakan profil batch size yang sesuai, dan ukur overhead I/O (tokenizer, preprocessing). Jangan lupa memory pinning dan thread affinity di CPU. Di GPU multi-socket, perhatikan NUMA dan topologi PCIe untuk menghindari bottleneck tersembunyi.
Strategi 3 — Khusus LLM/Transformer: KV Cache, Flash/Paged Attention, dan Speculative Decoding
LLM memiliki pola komputasi unik: fase prefill (TTFT) dan decoding token-per-token (TBT). Untuk mengoptimalkannya, fokus pada cache dan perhatian (attention). KV cache menyimpan key/value antar langkah decoding sehingga model tak perlu menghitung ulang dari awal. Dengan sequence panjang, penghematan kompute sangat besar. Gunakan teknik memori efisien seperti Paged Attention (tersedia di vLLM) agar ratusan konteks bisa dilayani bersamaan tanpa fragmentasi memori.
FlashAttention meminimalkan akses memori luar dan melakukan perhatian yang lebih hemat bandwidth; banyak laporan menunjukkan percepatan 1,5–2x pada sequence panjang dengan penggunaan memori yang jauh lebih rendah. Implementasi modern tersedia di berbagai framework, termasuk integrasi di beberapa runtime LLM. Untuk skenario dengan SLO ketat, kombinasi KV cache + Flash/Paged Attention dapat menurunkan TTFT dan TBT secara nyata.
Speculative decoding menjalankan “draft model” yang lebih kecil untuk memprediksi beberapa token ke depan, lalu divalidasi oleh model besar. Jika valid, token diterima; jika tidak, model besar memperbaiki. Secara umum, teknik ini bisa meningkatkan throughput 1,3–2x pada workload tertentu tanpa penurunan kualitas berarti. Lihat paper awal di arXiv untuk landasan konsep: Speculative Decoding.
Untuk serving, pertimbangkan engine yang mendukung continuous batching seperti vLLM atau Hugging Face TGI. Continuous batching mengisi batch secara dinamis saat permintaan masuk sehingga utilisasi GPU lebih tinggi dan throughput meningkat signifikan. Banyak tim melaporkan 2–4x throughput dibanding server naïf single-request-per-stream. Padukan dengan paged KV cache untuk menjaga memori tetap efisien.
Contoh skenario: bot bantuan penulisan internal memakai model 13B dengan context 8k. Dengan vLLM, paged attention, dan continuous batching, throughput melonjak dari 20 ke 55 tok/detik/GPU pada beban puncak, sementara TTFT turun sekitar 30%. Penalaan max tokens, top_p/top_k, dan penjadwalan concurrency menstabilkan latensi P95 tanpa mengorbankan kreativitas output.
Strategi 4 — Orkestrasi Serving: Dynamic Batching, Concurrency, dan Autoscaling
Optimasi model tak akan maksimal tanpa orkestrasi serving yang tepat. Dynamic batching menggabungkan beberapa permintaan menjadi satu batch untuk memanfaatkan paralelisme hardware. Targetkan batch size yang menyeimbangkan throughput dan latensi; gunakan batching window kecil (mis. 2–10 ms) agar tidak memperburuk P95 secara agresif. Continuous batching untuk LLM menambah efisiensi melampaui batching statis.
Set parameter concurrency agar tiap instance memanfaatkan hardware tanpa thrashing. Di GPU, terlalu banyak concurrent streams dapat meningkatkan context switching dan mengurangi efisiensi cache. Mulailah dengan 1–2 stream per GPU untuk workload berat, ukur, lalu naikkan bertahap. Di CPU, atur thread pool dan affinities; hindari oversubscription. Perhatikan juga limit I/O: tokenizer, pre/post-processing, dan jaringan sering jadi bottleneck tersembunyi.
Autoscaling horizontal membantu menghadapi traffic burst. Gunakan metrik yang tepat: queue depth, TTFT, atau GPU utilization (bukan sekadar CPU). Implementasikan warm pool bila cold start mahal. Untuk rolling update, lakukan canary release dengan A/B sehingga Anda bisa membandingkan profil latensi/biaya secara adil sebelum memindahkan 100% traffic.
Pengelolaan memori dan storage krusial. Preload model ke GPU, gunakan lazy weight loading hanya bila perlu, dan pastikan shard model besar diatur konsisten. Untuk LLM LoRA adapter, pertimbangkan teknik merging di deployment untuk mengurangi overhead switching. Observabilitas end-to-end penting: tracing request dari gateway hingga kernel level, sehingga Anda tahu apakah bottleneck ada di decoding loop, attention kernel, atau jaringan.
Contoh implementasi praktis: sebuah layanan tanya-jawab produk menargetkan P95 <1,5 detik. Dengan dynamic batching 8–16, small batching window 5 ms, concurrency 2 per GPU, serta autoscaling berbasis queue length, biaya per 1k permintaan turun ~35% dengan stabilitas latensi meningkat. Kuncinya: eksperimen terkontrol dan metrik yang konsisten, bukan tebak-tebakan.
Strategi 5 — Benchmark dan Observabilitas: Ukur yang Benar agar Optimasi Tepat Sasaran
Tanpa pengukuran yang disiplin, optimasi mudah tersesat. Bangun suite benchmark yang mencerminkan beban produksi, lengkap dengan variasi panjang input, tipe permintaan, dan tingkat concurrency. Ukur metrik berikut: TTFT (Time To First Token) dan TBT (Time Between Tokens) untuk LLM; p50/p90/p95/p99 latency; throughput (req/s, tok/detik/GPU); utilisasi GPU/CPU; bandwidth memori; dan error rate.
Lakukan warmup sebelum pengukuran. Bedakan cold vs warm results. Gunakan input dataset representatif (mis. panjang konteks 256/1k/4k/8k untuk LLM). Catat konfigurasi persis: versi driver, CUDA/cuDNN, versi runtime (TensorRT/ONNX Runtime), flag kompilasi, dan batch window. Dengan begitu, hasil dapat direproduksi dan dibagikan lintas tim.
Untuk observabilitas produksi, pasang tracing end-to-end dan logging struktur: waktu di tokenizer, pre/post, serialisasi, jaringan, compute kernels. Tag permintaan dengan model id, quant level (FP16/INT8), dan mode engine. Set alarm pada P95 latency, TTFT, dan GPU mem usage. Visualisasikan korelasi: apakah lonjakan TTFT terjadi bersama GC, autoscaling, atau saturasi jaringan? Dengan insight tersebut, Anda bisa mengarahkan optimasi pada titik paling berdampak.
Data ringkas (kisaran umum, bergantung model/hardware):
– FP16 vs FP32: ~1,3–1,8x lebih cepat di GPU modern; mem turun ~2x.
– INT8 vs FP32: ~1,5–3x lebih cepat; mem turun hingga ~4x; akurasi perlu validasi.
– TensorRT/ONNX Runtime vs eager: ~1,5–4x speedup pada banyak workload visi/NLP.
– Continuous batching (vLLM/TGI): ~2–4x throughput untuk LLM di beban ramai.
– Flash/Paged Attention: latensi lebih rendah dan mem jauh lebih hemat pada context panjang.
Gunakan angka di atas sebagai titik awal, bukan janji absolut. Hasil akhir sangat dipengaruhi komposisi operator, arsitektur model, dan topologi hardware. Rujukan teknis tambahan: TensorRT, ONNX Runtime, OpenVINO, vLLM, TGI, dan OpenXLA.
Q & A: Pertanyaan yang Sering Diajukan
Q: Apakah quantization selalu menurunkan akurasi?
A: Tidak selalu. Dengan kalibrasi yang baik (PTQ) atau QAT, penurunan akurasi sering kali kecil dan bisa diterima. Selalu validasi pada dataset target dan ukur metrik bisnis, bukan hanya metrik akademik.
Q: Mana yang lebih penting: optimasi model atau runtime?
A: Keduanya saling melengkapi. Mulailah dari FP16/INT8 dan runtime teroptimasi; jika belum cukup, tambah pruning/distilasi. Orkestrasi serving dan batching juga sangat berpengaruh.
Q: Bagaimana menurunkan TTFT untuk LLM?
A: Gunakan continuous batching, kurangi beban pre/post-processing, aktifkan KV cache, optimalkan prefill (mis. FlashAttention), dan siapkan warm pool agar cold start minimal.
Q: Batch size berapa yang ideal?
A: Tergantung SLO dan hardware. Uji beberapa nilai dengan window batching kecil (mis. 2–10 ms) dan pantau p95/p99. Cari sweet spot antara throughput dan latensi target.
Q: Edge vs cloud: strategi optimasi sama?
<