Semuanya bermula dari sebuah pertanyaan di Slack tim pada sore hari yang gerah di pertengahan 2024. Seorang rekan dari tim produk — mari kita panggil dia Rina — menulis, "Kalau kita mau host LLM sendiri buat chatbot internal 500 pegawai, kira-kira butuh GPU apa dan berapa biayanya per bulan?" Saya diam sejenak, jari melayang di atas keyboard, lalu mulai mengetik jawaban — dan menyadari bahwa saya tidak punya satupun angka yang pasti. Saya hanya punya feeling. Dan feeling tidak cukup untuk sebuah keputusan investasi puluhan hingga ratusan juta rupiah.

Pada saat itu, saya sudah hampir dua tahun berkutat dengan Large Language Models. Saya pernah menjalankan llama.cpp di laptop ThinkPad, mencoba vLLM di server kantor yang cuma punya GTX 1660 Super, dan bermain-main dengan quantization Q4_K_M dan Q5_K_M. Saya bahkan sudah membaca paper "Efficient Large-Scale Language Model Training on GPU Clusters" dan beberapa publikasi tentang FlashAttention. Tapi setiap kali seseorang bertanya soal biaya — berapa throughput, berapa lama response time, berapa harga GPU yang pas — saya hanya bisa menjawab setengah yakin. "Kira-kira segini," kata saya. "Kayaknya sih cukup." Atau lebih parah lagi: "Nanti saya cek dulu." Jawaban seperti itu terasa sangat tidak ilmiah untuk seseorang yang berlatar belakang teknik fisika dan bekerja sebagai AI Engineer.

Frustrasi itu menumpuk. Di Q3 2024, saya mulai membaca secara sistematis. Puluhan artikel Medium, dokumentasi NVIDIA, whitepaper model, benchmarking report dari komunitas r/LocalLLaMA, dan spec sheet GPU dari berbagai vendor. Saya menghabiskan akhir pekan — dan sebagian gaji — untuk menyewa GPU di RunPod dan Vast.ai hanya untuk menguji sendiri berapa token per detik yang bisa didapat dari kombinasi GPU dan model yang berbeda.

Masalahnya, hampir semua artikel hanya berbicara dalam generalitas. "GPU A lebih cepat dari GPU B untuk inference." "Gunakan FP16 untuk presisi lebih tinggi tetapi lebih boros VRAM." "Llama 3 8B jauh lebih efisien dari model sebelumnya." Semua pernyataan itu benar — tapi tidak ada satu pun yang memberikan kerangka kalkulasi yang bisa saya pakai untuk menjawab pertanyaan Rina. Tidak ada yang menurunkan rumus dari jumlah parameter ke VRAM yang dibutuhkan, dari VRAM ke throughput maksimum teoritis, dari throughput ke biaya per token.

Saya ingat betul momen breakthrough-nya. Suatu malam di bulan Oktober 2024 — sekitar pukul 02.30 WIB — saya duduk di meja belajar dengan secangkir kopi yang sudah dingin dan sebuah spreadsheet kosong. Saya mulai menuliskan semua variabel yang terlibat dalam menjalankan sebuah LLM. Parameter model (N), panjang konteks (L), presisi kuantisasi (B dalam bit per parameter), jumlah GPU (G), kapasitas VRAM per GPU (V), kecepatan interkoneksi antar-GPU (B_nv), throughput yang diinginkan dalam token per detik (T), batch size (B_s), faktor overhead kernel (O) — semuanya saya tuangkan ke dalam kolom-kolom spreadsheet.

Spreadsheet itu tumbuh. Dari satu sheet menjadi lima. Dari lima menjadi dua belas. Saya menambahkan kalkulator bandwidth, kalkulator VRAM, kalkulator token per detik, kalkulator biaya listrik berdasarkan PUE dan TDL PLN, kalkulator TCO tiga tahun dengan depresiasi straight-line, dan kalkulator break-even point untuk perbandingan on-premise vs API. Saya mulai memvalidasi setiap rumus dengan data dari GPU yang bisa saya akses — dua unit NVIDIA A100 80 GB SXM di kantor, sebuah RTX 4090 pribadi, dan beberapa node yang saya sewa di penyedia cloud GPU.

Momen "Eureka": Saya masih ingat tanggal 2 November 2024, ketika rumus throughput — TPD = (G × V × U) / (M × Foverhead) — menghasilkan angka yang persis sama dengan throughput real-time yang terukur di vLLM untuk model Llama 3 70B dengan 2 × A100. Selisihnya kurang dari 3%. Rasanya seperti menemukan kunci yang selama ini hilang. Sejak hari itu, saya tidak pernah lagi menjawab "kayaknya sih cukup." Saya membuka spreadsheet dan berkata, "Ini perhitungannya."

Buku ini lahir dari spreadsheet itu. Dari catatan-catatan yang awalnya hanya untuk konsumsi sendiri, dari tabel-tabel yang saya buat di waktu luang, dari presentasi internal di kantor yang kemudian saya berikan ke tim. Satu presentasi menjadi dua, menjadi lima, menjadi sebuah seri workshop internal. Setiap kali saya membagikannya, reaksinya selalu sama: "Ini yang selama ini kami cari. Kenapa tidak ada yang menulis buku tentang ini?" Tidak ada sumber — setidaknya dalam bahasa Indonesia — yang menyatukan semua variabel mulai dari harga GPU, konsumsi daya, bandwidth NVLink, hingga harga token API — dalam satu kerangka kalkulasi yang koheren dan aplikatif.

Saya menulis buku ini untuk Galih yang setahun lalu: yang frustrasi, yang bingung, yang ingin angka pasti. Juga untuk para AI engineer, CTO, technical lead, system architect, dan siapapun yang harus mengambil keputusan teknis dan finansial tentang LLM inference — terutama di Indonesia, di mana akses ke GPU高端 masih terbatas, harga listrik industri tidak murah, dan keputusan pembelian seringkali dibuat berdasarkan rekomendasi vendor yang bias.

Saya tidak akan bilang bahwa isi buku ini sempurna. Harga GPU berubah setiap kuartal, model baru lahir hampir setiap minggu, dan angka-angka di dalamnya akan usang. Tapi kerangka berpikirnya — cara menghitung, bukan angka hitungannya — itulah yang akan bertahan. Rumus-rumus tentang VRAM, throughput, latency, TCO, dan break-even analysis tidak akan berubah hanya karena GPU generasi berikutnya rilis. Yang berubah adalah inputnya. Metodologinya tetap.

Saya berutang besar pada komunitas open-source: para kontributor vLLM, llama.cpp oleh Georgi Gerganov dan tim, Hugging Face, dan ribuan peneliti dan engineer yang mempublikasikan benchmark dan temuan mereka secara gratis di GitHub, Reddit, dan forum-forum diskusi. Tanpa mereka, spreadsheet saya tidak akan pernah terkalibrasi dengan baik. Buku ini adalah upaya saya untuk meneruskan apa yang sudah mereka bangun, dalam bentuk yang lebih terstruktur dan — saya harap — lebih mudah dicerna oleh praktisi di lapangan.

Akhir kata, selamat membaca. Saya harap dalam 500 halaman ke depan, Anda akan mendapatkan jauh lebih dari sekadar jawaban. Anda akan mendapatkan keyakinan — kepercayaan diri untuk berkata, "Saya tahu persis berapa biayanya, dan ini hitungannya." Karena pada akhirnya, AI bukanlah sihir. AI adalah matematika. Dan matematika — tidak seperti opini — tidak pernah bias.

— Galih Prasetyo, AI Engineer
Juni 2026

Pada awal 2025, saya diundang untuk membantu sebuah BUMN telekomunikasi yang ingin membangun layanan chatbot AI untuk ribuan pegawai dan pelanggannya. Mereka sudah berbicara dengan tiga vendor infrastruktur dan mendapatkan tiga proposal yang sangat berbeda. Vendor A menawarkan GPU A100 80 GB × 4 dengan biaya Rp 1,2 miliar di tahun pertama (termasuk server, lisensi, dan instalasi). Vendor B menawarkan solusi H100 × 2 dengan biaya Rp 2,1 miliar. Vendor C — yang kebetulan penyedia cloud — mengusulkan pendekatan hybrid: GP on-premise untuk model kecil plus API untuk model besar, dengan estimasi Rp 600 juta per tahun. Ketiganya yakin bahwa solusi mereka adalah yang terbaik. Mana yang benar-benar tepat?

Kenyataannya, tidak ada satu pun vendor yang bisa menunjukkan secara transparan bagaimana mereka sampai di angka itu. Mereka memberikan total tagihan, tapi tidak memberikan breakdown. Berapa throughput yang dijamin? Berapa token per detik untuk model 7B vs 70B? Berapa maksimum konteks yang didukung? Berapa biaya per token dalam skenario real-time vs batch processing? Tidak ada satu pun angka teknis yang bisa dijadikan dasar perbandingan. Dan tanpa angka-angka itu, mustahil membandingkan proposal secara objektif.

Inilah masalah terbesar yang saya lihat di industri AI Indonesia saat ini: keputusan pembelian GPU dan infrastruktur LLM dibuat berdasarkan firasat dan rekomendasi vendor, bukan perhitungan teknis-ekonomis yang rigor. Tim teknis tidak punya alat untuk menghitung apakah sebuah GPU cukup untuk model yang mereka inginkan. Tim finansial tidak punya kerangka untuk membandingkan on-premise vs API dalam skala tiga tahun dengan asumsi yang bisa dipertanggungjawabkan. Dan vendor — tentu saja — lebih suka menjual solusi termahal (dengan margin tertinggi) daripada solusi yang paling cost-effective untuk klien.

Dua Ekstrem yang Sama-Sama Berbahaya

Di lapangan, saya mengamati dua ekstrem yang sama-sama merugikan.

Ekstrem pertama: GPU-obsession. Tim yang tergoda untuk selalu membeli GPU termahal "yang penting bisa." Saya pernah melihat sebuah startup dengan hanya 500 pengguna harian yang membeli empat unit A100 80 GB — dan setelah 6 bulan, 70% VRAM-nya tidak pernah terpakai karena model yang mereka jalan hanyalah Llama 3 8B yang sebenarnya muat di satu GPU RTX 4090. Itu adalah Rp 1,3 miliar yang menganggur. Belum lagi biaya listrik dan pendinginan untuk GPU yang idle — sekitar Rp 2-3 juta per bulan per GPU di data center Indonesia.

Ekstrem kedua: API-only fallacy. Tim yang menganggap on-premise tidak pernah masuk akal sehingga semua inference harus melalui API pihak ketiga. Saya punya klien — sebuah startup fintech — yang menghabiskan rata-rata Rp 80-120 juta per bulan untuk API GPT-4o, hanya untuk chatbot customer service. Dalam 18 bulan, mereka telah membayar Rp 1,8 miliar — cukup untuk membeli 3 unit H100 lengkap dengan server dan listrik selama 2 tahun. Tapi mereka tidak pernah melakukan perhitungan TCO, sehingga tidak pernah menyadari bahwa break-even point mereka sudah terlewati di bulan ke-11.

Data lapangan: Dari pengalaman saya berkonsultasi dengan lebih dari 15 organisasi di Indonesia — mulai dari startup Series A hingga BUMN dengan ribuan pegawai — sekitar 60% membeli GPU yang terlalu mahal untuk workload mereka (over-provisioning 2-4×). Sementara 25% lainnya membayar API terlalu mahal karena takut akan kerumitan pengelolaan infrastruktur on-premise. Hanya 15% yang mengambil keputusan dengan kalkulasi yang matang — dan dari 15% itu, hampir semuanya adalah tim yang memiliki akses ke data benchmark dan kerangka perhitungan yang solid. Buku ini adalah untuk 85% sisanya — termasuk untuk versi saya sendiri di masa lalu yang masih menjawab "kayaknya sih cukup."

Akar Masalah: Ketiadaan Kerangka Kalkulasi

Kenapa ini terjadi? Saya percaya akar masalahnya bukan pada niat buruk vendor atau ketidakmampuan tim teknis. Masalahnya adalah ketiadaan kerangka kalkulasi yang terstandarisasi dan bisa diakses. Informasi tentang inference LLM tersebar di mana-mana: di whitepaper NVIDIA, di blog Hugging Face, di GitHub issue vLLM, di forum komunitas. Tapi tidak ada yang menyatukannya dalam format yang bisa langsung dipakai untuk menjawab pertanyaan praktis seperti: "Berapa GPU yang saya butuhkan untuk model X dengan konteks Y dan throughput Z?"

Yang lebih parah: bahkan ketika Anda berhasil mengumpulkan semua informasi, Anda masih harus menghitung sendiri. Dan perhitungan inference LLM bukan perkara sepele. Ada interaksi non-linear antara parameter model, presisi kuantisasi, panjang konteks, batch size, bandwidth memori GPU, overhead kernel, dan efek dari teknik optimasi seperti FlashAttention dan PagedAttention. Tanpa pemahaman yang terstruktur, mudah untuk membuat kesalahan estimasi yang berujung pada keputusan investasi yang salah.

Apa yang Ingin Buku Ini Capai

Buku ini tidak akan memberi tahu Anda GPU mana yang harus dibeli. Buku ini akan memberi Anda rumus dan kerangka untuk mengetahuinya sendiri. Saya percaya bahwa keputusan infrastruktur yang baik adalah keputusan yang berbasis data — dan data yang relevan tidak bisa Anda dapatkan tanpa kemampuan untuk menghitung. Anda tidak bisa membandingkan Harga GPU A dengan GPU B tanpa menghitung token per detik per dolar. Anda tidak bisa memutuskan on-premise vs API tanpa menghitung TCO dan break-even point dalam skenario penggunaan spesifik Anda.

Secara konkret, buku ini dirancang untuk menjawab lima pertanyaan kunci:

1. Berapa banyak GPU yang saya butuhkan? — Dihitung dari parameter model, panjang konteks, presisi kuantisasi, dan throughput target. Bukan tebakan.
2. GPU mana yang paling cost-effective untuk workload saya? — Dibandingkan dengan metrik token per detik per dolar, dengan faktor koreksi untuk biaya listrik, pendinginan, dan depresiasi.
3. Kapan dan dalam kondisi apa on-premise lebih murah daripada API? — Dengan break-even analysis yang mempertimbangkan volume token harian, biaya listrik lokal, dan horizon investasi.
4. Bagaimana cara mengoptimalkan inference yang sudah berjalan? — Dengan strategi quantization, continuous batching, speculative decoding, KV-cache optimization, dan pemilihan framework yang tepat.
5. Berapa biaya total kepemilikan (TCO) yang sebenarnya? — Meliputi GPU, server, jaringan, listrik, pendinginan, rak data center, garansi, dan biaya SDM — komponen yang sering dilupakan dalam perhitungan.

Untuk Siapa Buku Ini (dan Bukan Untuk Siapa)

Buku ini bukan untuk peneliti AI yang sedang mengembangkan arsitektur model baru, menulis paper tentang attention mechanism, atau bereksperimen dengan training dari nol. Buku ini untuk practitioner: para AI engineer, MLOps engineer, system architect, CTO, technical project manager, data scientist, dan siapapun yang harus menjalankan LLM di dunia nyata — entah di server kantor, di data center, melalui cloud GPU, atau melalui API. Anda tidak perlu menjadi ahli GPU atau lulusan S2 machine learning untuk membaca buku ini. Jika Anda bisa mengoperasikan kalkulator, memahami aljabar dasar SMA, dan membaca grafik, Anda sudah punya semua prasyarat yang dibutuhkan.

Setiap bab di buku ini ditulis dengan satu premis: Anda bisa menghitung sendiri, tanpa harus percaya pada marketing vendor, FOMO komunitas, atau feeling siapa pun. Angka-angka yang disajikan — harga GPU, throughput, TCO — bukan untuk dihafal, tapi untuk menjadi contoh dan titik awal. Anda bisa (dan harus) menggantinya dengan angka real dari lingkungan Anda sendiri.

Pada akhirnya, buku ini ada karena saya lelah melihat orang membuang uang — uang yang kadang adalah hasil jerih payah bertahun-tahun — untuk infrastruktur AI yang tidak tepat. Saya ingin setiap tim di Indonesia yang ingin mengadopsi LLM — entah untuk chatbot layanan pelanggan, coding assistant internal, sistem RAG untuk dokumen perusahaan, atau agen AI untuk otomatisasi workflow — bisa mengambil keputusan dengan percaya diri, dengan spreadsheet di tangan, dan tanpa harus belajar dari kesalahan yang mahal.

Selamat menghitung.

Buku ini terdiri dari 12 bagian dan 76 bab, ditambah lampiran referensi yang lengkap dengan tabel spesifikasi, glosarium, dan daftar rumus ringkas. Meskipun urutannya sudah dirancang secara progresif — dari fondasi teori paling dasar hingga studi kasus industri yang kompleks — Anda tidak wajib membacanya berurutan dari halaman 1 sampai 500. Setiap bagian dirancang untuk bisa berdiri sendiri, dengan catatan prasyarat yang jelas di awal bab sehingga Anda bisa melompat ke bagian yang paling relevan dengan kebutuhan Anda saat itu.

Struktur Buku Secara Keseluruhan

Berikut adalah peta jalan 12 bagian buku ini, dari pembuka hingga lampiran:

Tiga Jalur Membaca

Tergantung peran dan kebutuhan Anda, saya merekomendasikan tiga jalur membaca berikut:

Jalur 1: Pembaca Linier — untuk Pemula yang Ingin Menguasai dari Dasar

Untuk Anda yang benar-benar baru dalam dunia inference LLM dan ingin membangun pemahaman dari nol yang kokoh. Mulailah dari Bagian I dan lanjutkan secara berurutan hingga Bagian VII. Setiap bab membangun konsep dari bab sebelumnya — Anda akan kesulitan memahami continuous batching di Bagian IV jika belum paham cara hitung kebutuhan VRAM di Bagian II. Jalur ini memakan waktu (kira-kira 20-30 jam baca), tapi memberikan fondasi paling kokoh. Setelah Bagian VII, Anda bisa memilih Bagian VIII atau IX sesuai minat.

Jalur 2: Decision-Maker — untuk CTO & Technical Lead yang Butuh Cepat

Untuk eksekutif teknis yang butuh jawaban cepat. Mulailah dari Bagian II untuk memahami rumus-rumus dasar, lalu loncat ke Bagian VI untuk analisis biaya dan perbandingan on-premise vs API, dan Bagian VII untuk studi kasus yang relevan dengan industri Anda. Gunakan Bagian III sebagai referensi cepat saat membandingkan GPU. Kembali ke Bagian I hanya jika ada konsep fundamental yang perlu didalami. Jalur ini bisa diselesaikan dalam 6-8 jam dengan hasil yang langsung aplikatif.

Jalur 3: Troubleshooter — untuk Engineer yang Ingin Optimasi Sistem yang Sudah Berjalan

Untuk engineer yang sudah punya sistem jalan tapi ingin optimasi biaya atau performa. Loncat langsung ke Bagian IV untuk strategi optimasi (quantization, speculative decoding, batching), lalu Bagian V untuk perbandingan framework — mungkin framework Anda saat ini bukan yang paling optimal untuk workload spesifik Anda. Gunakan indeks di Bagian X untuk menemukan topik spesifik dengan cepat. Jalur ini yang paling pendek — sekitar 3-4 jam — tapi hanya efektif jika Anda sudah memiliki pemahaman dasar tentang inference.

Konvensi Penulisan Sepanjang Buku

Agar konsisten dan mudah diikuti, saya menggunakan konvensi berikut di seluruh buku:

• Rumus: Semua rumus ditulis dalam notasi matematika standar dengan variabel berhuruf miring. Setiap variabel dijelaskan segera setelah rumus diperkenalkan — tidak ada variabel yang muncul tanpa definisi.
• Contoh tabel: Tabel benchmark berisi data real dari pengujian mandiri atau publikasi terpercaya yang tercantum sumbernya. Semua angka throughput adalah median dari minimal 50 iterasi setelah warm-up.
• Kode dan konfigurasi: Blok kode menggunakan sintaks nyata yang sudah diuji. Contoh: konfigurasi vLLM, parameter llama.cpp, script benchmark, atau rumus Google Sheets / Excel yang bisa langsung dicopy-paste.
• Blok tip: <blockquote class="tip"> berisi saran praktis, shortcut, atau best practice yang mempercepat pekerjaan Anda.
• Blok peringatan: <blockquote class="warn"> berisi jebakan umum, kesalahan yang sering terjadi, atau hal-hal yang bisa berakibat fatal jika diabaikan.
• Referensi silang: Setiap penyebutan bagian atau bab lain adalah tautan aktif (dalam versi digital) yang bisa diklik untuk navigasi cepat.

Saran untuk pembaca digital: Jika Anda membaca buku ini dalam format PDF, EPUB, atau web, manfaatkan hyperlink antar-bab dan bookmark. Setiap referensi silang — misalnya "lihat Bagian V untuk detail framework" — adalah tautan aktif. Ini sangat membantu terutama saat menggunakan Jalur 2 atau Jalur 3 di mana Anda sering melompat antar-bagian.

Apa yang Tidak Ada di Buku Ini (dan Kenapa)

Agar fokus dan tidak melebar, buku ini sengaja tidak mencakup:

• Training LLM dari awal — buku ini 100% tentang inference. Training memiliki dinamika biaya yang sangat berbeda (komunikasi all-reduce, checkpointing, data pipeline) dan memerlukan buku tersendiri dengan ketebalan yang sama.
• Fine-tuning dan LoRA — hanya disinggung sekilas di studi kasus. Fine-tuning juga memiliki profil biaya yang berbeda dengan pure inference.
• Implementasi kode dari nol — buku ini menggunakan framework yang sudah matang (vLLM, llama.cpp, TensorRT-LLM, SGLang), bukan mengajari cara menulis CUDA kernel atau attention mechanism dari scratch.
• Perbandingan kualitas model — kami bicara soal kecepatan, biaya, dan efisiensi, bukan soal "model A lebih pintar dari model B" atau "model X mengalahkan GPT-4 di benchmark Y." Kualitas model sangat kontekstual dan subjektif tergantung use case.
• Panduan coding agent atau RAG dari sisi aplikasi — kami fokus pada infrastruktur inference-nya. Arsitektur RAG, prompt engineering, dan orchestration agen adalah topik untuk buku lain.

Dengan peta jalan ini, saya harap Anda bisa menentukan sendiri jalur terbaik sesuai kebutuhan, latar belakang, dan waktu yang Anda miliki. Selamat menjelajah — dan jangan ragu untuk melompat, menandai halaman, dan kembali lagi nanti. Buku teknis yang baik bukanlah novel yang harus dibaca sekali duduk, melainkan referensi yang akan Anda kunjungi berulang kali.

Sebuah buku teknis tentang harga dan performa hardware memiliki umur simpan yang pendek — lebih pendek dari yang saya inginkan. Saya sadar betul bahwa angka-angka di buku ini — harga GPU, kecepatan token per detik, biaya listrik per kWh, tarif API per token — adalah snapshot dari kondisi per Juni 2026. Enam bulan dari sekarang, beberapa angka pasti sudah berubah. Dua belas bulan lagi, mungkin banyak yang perlu direvisi. Dua tahun lagi, buku ini mungkin sudah perlu edisi kedua. Karena itu, penting bagi saya untuk menjelaskan dengan transparan darimana angka-angka itu berasal, bagaimana cara mendapatkannya, metodologi pengukuran yang digunakan, dan — yang terpenting — bagaimana Anda bisa memperbarui dan memvalidasi sendiri data tersebut untuk konteks Anda.

Sumber Data GPU & Hardware

Data spesifikasi teknis GPU dan harga di buku ini bersumber dari beberapa kategori vendor dan platform. Saya berusaha menggunakan sumber primer sebisa mungkin, dan hanya menggunakan sumber sekunder jika data primer tidak tersedia:

Sumber Data Model LLM & Benchmark Inference

Performa model LLM — yang menjadi input utama kalkulasi di buku ini — diukur dari tiga kategori sumber untuk memastikan validitas dan mengurangi bias dari satu sumber saja:

Protokol Benchmark Standar

Setiap angka throughput — tokens per second — dalam buku ini, jika tidak disebutkan secara spesifik, mengikuti protokol pengukuran berikut agar konsisten dan reproducible:

• Input prompt length: 512 token (kecuali disebut lain dalam konteks bab)
• Output generation length: 256 token (kecuali disebut lain)
• Batch size: 1 untuk skenario real-time interactive (latency-sensitive); dioptimalkan hingga maksimal untuk skenario batch processing (throughput-maximal)
• Warm-up: 3 iterasi awal dibuang dari statistik untuk menghilangkan efek cold start (warm-up, CUDA kernel compilation, KV-cache allocation)
• Sampel statistik: Rata-rata dari 50 iterasi berikutnya; nilai yang dilaporkan adalah median untuk mengurangi dampak outlier akibat thermal throttling atau proses sistem lain
• Model precision: FP16 (default), disebutkan secara eksplisit jika menggunakan quantization (FP8, INT8, INT4, NF4, atau GGUF Q4_K_M / Q5_K_M / Q6_K / Q8_0)
• Framework: vLLM untuk GPU CUDA (NVIDIA), llama.cpp untuk GPU AMD/CPU dan GPU non-NVIDIA, TensorRT-LLM untuk skenario latency-critical yang memerlukan optimasi maksimal, SGLang untuk skenario yang membutuhkan structured output
• Driver & CUDA version: CUDA 12.8 / driver 570.x untuk NVIDIA; ROCm 6.5 untuk AMD; driver CANN terbaru untuk Huawei Ascend; driver Intel terbaru untuk Gaudi
• GPU clock: Default pabrikan (tidak dilakukan overclocking atau underclocking)

Peringatan metodologis yang penting: Angka benchmark sangat bergantung pada konfigurasi sistem — CPU, RAM, motherboard, kecepatan PCIe, suhu ruangan, proses latar belakang, versi driver, bahkan versi kernel Linux. Satu studi kasus: benchmark yang sama di A100 80 GB PCIe vs SXM menunjukkan perbedaan hingga 15-20% karena bandwidth interkoneksi. Sebisa mungkin saya menyajikan range performa (min-max), bukan angka tunggal. Jika Anda mendapatkan angka yang berbeda di lingkungan Anda, itu normal — yang penting adalah pola perbandingan relatif antar-GPU dan antar-konfigurasi, bukan angka absolutnya.

Asumsi Finansial & Nilai Tukar

Semua analisis biaya dalam buku ini menggunakan asumsi finansial yang konsisten. Anda bisa — dan harus — mengganti asumsi ini dengan data real dari lingkungan Anda:

Template kalkulator tersedia: Semua asumsi finansial di atas — nilai tukar, tarif listrik, PUE, depresiasi — adalah parameter yang bisa Anda ubah di kalkulator spreadsheet yang menyertai buku ini (lihat Bagian X — Lampiran untuk tautan unduhan). Biaya listrik di pabrik Anda di Cikarang mungkin berbeda dengan kantor di Jakarta Selatan. PUE data center anda mungkin 1,3 atau 2,0. Jangan ragu mengganti angka default dengan data real dari lingkungan Anda — itulah tepatnya mengapa buku ini mengajarkan cara menghitung, bukan menyajikan angka jadi.

Keterbatasan & Disclaimer Penting

Beberapa hal yang perlu Anda ingat saat menggunakan data di buku ini:

1. Harga GPU sangat fluktuatif — terutama kartu konsumen (RTX 4090, RTX 5090, seri RX) yang harganya sangat dipengaruhi oleh ketersediaan pasar, tren AI, dan — kadang — aktivitas crypto mining. Harga di buku ini adalah harga retail normal pada saat penulisan, bukan harga scalper atau harga saat kelangkaan.
2. Performa model berubah antar versi framework — update pada vLLM, transformers, atau llama.cpp dapat mengubah throughput secara signifikan (pernah saya lihat hingga 30% peningkatan hanya dengan update minor). Semua benchmark dilakukan dengan versi framework yang disebutkan di catatan kaki masing-masing tabel.
3. Workload yang berbeda menghasilkan profil performa yang sangat berbeda — throughput untuk chat real-time (di mana Time-to-First-Token adalah metrik kritis) sangat berbeda dengan throughput untuk batch processing (di mana total token per detik adalah raja). Buku ini secara eksplisit membedakan kedua skenario ini di setiap analisis.
4. Harga API berubah tanpa pemberitahuan — tarif dari OpenAI, Anthropic, Google, dan penyedia API lokal Indonesia terus berubah seiring kompetisi pasar. Harga yang tercantum adalah per Juni 2026 dan harus diverifikasi ulang sebelum digunakan untuk keputusan finansial.
5. Biaya tidak selalu linear — menambah GPU kedua bukan berarti throughput menjadi dua kali lipat. Scaling efficiency untuk multi-GPU inference biasanya 70-95% tergantung model dan interkoneksi. Buku ini membahas faktor scaling ini secara detail di Bagian II.

Referensi Lengkap & Cara Memperbarui Data

Untuk transparansi penuh dan reproducibility, semua sumber data yang digunakan di buku ini tercantum di Bagian X (Lampiran). Repositori GitHub publik buku ini — github.com/galihpras/kalkulasi-token-gen — berisi: Seluruh spreadsheet kalkulator (Google Sheets dan Excel), Semua script benchmark yang digunakan (Python + shell), Konfigurasi framework untuk setiap skenario pengujian, Data mentah benchmark dalam format CSV, dan Log perubahan (changelog) untuk pelacakan revisi data.

Saya sangat mendorong kontribusi dari pembaca: jika Anda menemukan angka yang sudah tidak akurat, atau jika Anda memiliki data benchmark dari GPU atau konfigurasi yang belum tercakup di buku ini, silakan buka pull request atau issue di repositori GitHub. Buku teknis yang baik adalah dokumen hidup yang terus diperbarui oleh komunitasnya.

Sebagai penutup catatan metodologi ini: data di buku ini adalah titik awal, bukan akhir. Saya mendorong Anda untuk selalu memvalidasi angka-angka kritis dengan pengujian di lingkungan Anda sendiri — terutama sebelum membuat keputusan investasi di atas Rp 100 juta. Kalkulasi yang Anda lakukan dengan data real dari infrastruktur, model, dan workload Anda sendiri akan selalu lebih akurat daripada angka di buku mana pun, termasuk buku ini. Angka di buku ini adalah peta, bukan medan. Anda tetap harus berjalan sendiri.

Setiap percakapan dengan Large Language Model (LLM)—mulai dari mengetik prompt di ChatGPT, Claude, atau Gemini—pada dasarnya adalah pertukaran token. Tapi apa sebenarnya token itu? Mengapa LLM tidak bekerja dengan huruf atau kata biasa? Dan bagaimana cara menghitung berapa banyak token yang dikonsumsi oleh sebuah kalimat? Bab ini akan menjawab semua pertanyaan fundamental tersebut.

Definisi Token

Token adalah unit dasar pemrosesan dalam Large Language Model. Sederhananya, token adalah potongan teks dengan panjang variabel—bisa berupa satu karakter, satu suku kata, satu kata utuh, atau bahkan gabungan beberapa kata—yang menjadi "mata uang" bagi model bahasa. LLM tidak membaca teks seperti manusia membaca huruf demi huruf. Model membaca dan menghasilkan teks dalam bentuk token.

Setiap model bahasa modern menggunakan tokenizer, yaitu algoritma yang bertugas memecah teks menjadi deretan token. Tokenizer yang paling umum digunakan saat ini adalah Byte-Pair Encoding (BPE), WordPiece (digunakan oleh BERT), atau SentencePiece (digunakan oleh Gemma dan LLaMA). Algoritma-algoritma ini bekerja dengan pendekatan statistik: mereka menganalisis korpus teks raksasa dan menentukan potongan optimal mana yang paling sering muncul.

Token vs Karakter vs Kata

Untuk memahami perbedaan mendasar antara token, kata, dan karakter, perhatikan contoh konkret berikut. Ambil kalimat sederhana dalam bahasa Indonesia:

Kalimat: "Halo, apa kabar?"
Karakter:  14 karakter (termasuk spasi dan tanda baca)
Kata:      3 kata  ("Halo", "apa", "kabar?")
Token:     5 token (["Halo", ",", " apa", " kab", "ar?"])

Yang menarik adalah tokenizer memecah kata "kabar" menjadi dua token: " kab" dan "ar?". Ini terjadi karena dalam korpus pelatihan, kombinasi " kab" lebih sering muncul sebagai awalan yang diikuti variasi akhiran. Tokenizer BPE bersifat subword: kata yang jarang muncul cenderung dipecah menjadi subword yang lebih kecil, sementara kata yang sangat umum (seperti "the", "dan", "di") menjadi satu token utuh.

Cara LLM Memproses Token

Proses internal LLM terhadap token melibatkan beberapa langkah yang terjadi dalam hitungan milidetik:

1. Tokenisasi Input: Teks prompt dipecah menjadi deretan token oleh tokenizer. Setiap token mendapat ID numerik yang unik berdasarkan vocabulary model.
2. Embedding Lookup: Setiap ID token dikonversi menjadi vektor berdimensi tinggi (biasanya 4.096 hingga 16.384 dimensi, tergantung ukuran model). Vektor ini disebut embedding dan merepresentasikan makna semantik token dalam ruang multidimensi.
3. Forward Pass: Deretan vektor embedding dilewatkan melalui puluhan atau ratusan lapisan transformer. Setiap lapisan melakukan kalkulasi self-attention dan feed-forward, yang memungkinkan model "memahami" konteks dari setiap token dalam hubungannya dengan token lain.
4. Output Logits: Lapisan terakhir menghasilkan vektor logits—skor mentah untuk setiap token dalam vocabulary (bisa berisi 32.000 hingga 200.000+ token).
5. Sampling: Logits dikonversi menjadi probabilitas melalui fungsi softmax, lalu token berikutnya dipilih berdasarkan strategi sampling (greedy, top-k, top-p, temperature, dsb).

Langkah 3 sampai 5 diulang secara autoregressive: token yang baru dihasilkan ditambahkan ke deretan input, dan model memproses ulang seluruh deretan untuk menghasilkan token berikutnya. Inilah yang membuat proses generation—tidak seperti proses klasifikasi—inheren lebih lambat dan membutuhkan lebih banyak komputasi.

Contoh Konkret: Tokenisasi Bahasa Indonesia

Mari kita hitung token untuk beberapa kalimat dalam bahasa Indonesia menggunakan tokenizer GPT-4 (cl100k_base):

Tabel Perbandingan Token per Bahasa

Jumlah token per karakter sangat bervariasi antarbahasa. Bahasa-bahasa yang menggunakan alfabet Latin dan memiliki struktur kata pendek (seperti Inggris) cenderung lebih efisien secara token dibandingkan bahasa dengan morfologi kompleks (seperti Jerman atau Indonesia) atau sistem logografik (seperti Mandarin):

Implikasinya signifikan: sebuah prompt 1.000 karakter dalam bahasa Mandarin akan menghabiskan sekitar 77 token, sementara prompt serupa dalam bahasa Inggris hanya 25 token. Namun sebaliknya, output model dalam bahasa Mandarin lebih boros token karena model harus menghasilkan lebih banyak token untuk menyampaikan informasi yang sama—sekitar 3 token Mandarin untuk setiap 1 token Inggris. Ini berarti pengguna non-Inggris secara efektif membayar lebih per unit informasi, baik dari segi biaya API maupun latency.

Rumus Dasar Estimasi Token

Untuk estimasi cepat, gunakan aturan praktis berikut:

Contoh kalkulasi: Sebuah prompt sepanjang 500 kata dalam bahasa Indonesia kira-kira membutuhkan 500 × 1.5 = 750 token. Jika model merespon dengan 800 token output, total konsumsi token untuk satu putaran percakapan adalah 750 (input) + 800 (output) = 1.550 token. Pada model dengan pricing $15 per 1M token input dan $60 per 1M token output (setara GPT-4 Turbo), biayanya adalah (750 ÷ 1.000.000 × $15) + (800 ÷ 1.000.000 × $60) = $0,01125 + $0,048 = sekitar $0,06 per percakapan. Angka ini tampak kecil untuk satu percakapan, tetapi jika aplikasi Anda melayani 100.000 percakapan per hari, tagihannya mencapai $6.000 per hari hanya untuk inference.

Pemahaman tentang token ini bukan sekadar pengetahuan teoretis—ia berdampak langsung pada biaya operasional, arsitektur sistem, dan pengalaman pengguna. Bab-bab selanjutnya akan membangun fondasi ini untuk memahami metrik-metrik kinerja yang lebih dalam.

Ketika Anda menekan tombol "Generate" di ChatGPT, apa yang sebenarnya terjadi di server dalam sepersekian detik? Inferensi LLM bukanlah proses tunggal—ia terdiri dari dua fase yang sangat berbeda: Prefill dan Decode. Dua fase ini memiliki karakteristik komputasi, kebutuhan memori, dan profil latency yang sama sekali berbeda. Bab ini akan membedah keduanya secara detail.

Fase 1: Prefill — Proses Prompt Secara Paralel

Fase Prefill adalah langkah pertama ketika model menerima prompt dari pengguna. Dinamakan "Prefill" karena tujuannya adalah mengisi (pre-fill) Key-Value Cache (KV Cache) dengan representasi dari seluruh token input sekaligus.

Karakteristik utama fase Prefill:

• Pemrosesan paralel penuh: Semua token dalam prompt diproses secara bersamaan dalam satu forward pass. Transformer architecture memungkinkan komputasi paralel karena setiap token dapat "melihat" semua token lain melalui mekanisme attention tanpa perlu urutan iteratif.
• Komputasi matriks masif: Operasi dominan adalah matriks-matriks besar (GEMM — General Matrix Multiply), yang sangat dioptimalkan untuk GPU. GPU modern dengan Tensor Core (NVIDIA H100, B200) dapat mengeksekusi operasi ini dengan throughput puluhan hingga ratusan TFLOPS.
• Compute-bound: Fase ini terbatas oleh kemampuan komputasi GPU, bukan bandwidth memori. Semakin banyak token dalam prompt, semakin tinggi efisiensi komputasi karena GPU dapat memanfaatkan parallelism secara maksimal.
• KV Cache pertama kali dibuat: Pada akhir fase ini, model menghasilkan tensor K (Key) dan V (Value) untuk setiap layer dan setiap token, yang disimpan dalam memori GPU untuk digunakan pada fase Decode.

Ilustrasi: Prefill untuk Prompt 100 Token

Prompt: [T₁, T₂, T₃, ..., T₁₀₀]
         ↓   ↓   ↓        ↓
    ┌────────────────────────────────┐
    │    Forward Pass Paralel        │
    │  (Satu langkah, semua token)   │
    └────────────────────────────────┘
         ↓   ↓   ↓        ↓
    [KV₁, KV₂, KV₃, ..., KV₁₀₀]    ← KV Cache
    [L₁,  L₂,  L₃,  ..., L₁₀₀]     ← Logits → pilih T₁₀₁

Waktu yang dibutuhkan fase Prefill umumnya proporsional terhadap panjang prompt, tetapi dengan faktor yang sangat efisien. Sebuah prompt 1.000 token bisa diproses dalam 15-30 ms pada GPU modern, sementara prompt 100 token selesai dalam 5-10 ms. Perhatikan bahwa prompt 10× lebih panjang tidak memakan waktu 10× lebih lama—ini adalah keunggulan komputasi paralel.

Fase 2: Decode — Proses Autoregressive Satu Per Satu

Setelah Prefill selesai, model memasuki fase Decode—proses menghasilkan token output satu per satu. Inilah bagian yang membuat LLM terasa "berpikir" dan mengetik kata demi kata.

Karakteristik utama fase Decode:

• Autoregressive: Setiap token baru dihasilkan dengan melihat seluruh konteks sebelumnya (prompt + token yang sudah dihasilkan). Proses ini sequential—token ke-5 baru bisa dihasilkan setelah token ke-4 selesai.
• Memory-bandwidth bound: Tidak seperti Prefill yang didominasi komputasi matriks besar, Decode didominasi oleh operasi matrix-vector (GEMV). GPU sangat efisien untuk matriks besar, tetapi untuk vektor kecil, bottleneck-nya adalah seberapa cepat GPU dapat membaca parameter model dari HBM (High Bandwidth Memory) ke register/SRAM.
• KV Cache bertambah: Setiap langkah decode menghasilkan satu pasang tensor K dan V baru yang ditambahkan ke KV Cache. Cache ini terus membesar sepanjang proses generation, meningkatkan kebutuhan memori secara linear.
• Attention dengan seluruh konteks: Setiap langkah decode harus melakukan attention terhadap seluruh token sebelumnya (prompt + output). Semakin panjang konteks, semakin berat setiap langkah decode.

Ilustrasi: Decode untuk Menghasilkan 3 Token

Langkah 1: Input = [T₁...T₁₀₀]   → Forward Pass → Token T₁₀₁ = "Saya"
Langkah 2: Input = [T₁...T₁₀₁]   → Forward Pass → Token T₁₀₂ = "sedang"
Langkah 3: Input = [T₁...T₁₀₂]   → Forward Pass → Token T₁₀₃ = "belajar"
                                  ⋮

Perhatikan bahwa setiap langkah decode memproses ulang semua token sebelumnya. Tanpa KV Cache, kompleksitas akan menjadi O(N²) terhadap panjang total—tidak scalable. KV Cache menghindari ini dengan menyimpan hasil komputasi K dan V dari langkah-langkah sebelumnya, sehingga setiap langkah decode hanya perlu mengkomputasi attention untuk token baru terhadap cache yang sudah ada.

Diagram Perbandingan Prefill vs Decode

Mengapa Decode Lebih Lambat?

Perbedaan kecepatan antara Prefill dan Decode bisa mencapai 50–100× untuk token yang sama. Mari kita bedah penyebabnya secara teknis:

Angka-angka di atas menjelaskan mengapa LLM terasa "cepat" dalam memahami prompt (Prefill) tetapi "lambat" dalam mengetik respons (Decode). Prompt 1.000 token selesai diproses dalam ~20 ms, tetapi untuk menghasilkan 500 token output, dibutuhkan 500 × 20 ms = 10.000 ms = 10 detik.

Contoh Kalkulasi Waktu Total Inference

Mari kita hitung waktu total yang dibutuhkan untuk sebuah sesi tanya-jawab sederhana:

Total waktu = Prefill (40 ms) + Decode (300 × 30 ms) = 40 ms + 9.000 ms = 9.040 ms ≈ 9 detik.

Dari 9 detik tersebut, 99,6% waktu dihabiskan untuk fase Decode. Ini menjelaskan mengapa hampir semua upaya optimasi inference LLM—seperti speculative decoding, KV cache quantization, prefix caching, dan batching—berfokus pada mempercepat fase Decode. Prefill sudah sangat efisien; Decode-lah yang menjadi bottleneck utama.

Pemahaman tentang dua fase ini adalah prasyarat mutlak untuk membaca bab-bab selanjutnya tentang metrik latency. TTFT (Time to First Token) adalah tentang Prefill, sementara TPOT (Time Per Output Token) dan throughput adalah tentang Decode. Tanpa memahami perbedaan fundamental ini, mustahil untuk mengoptimalkan sistem LLM secara efektif.

Dalam dunia LLM inference, tidak cukup hanya mengatakan "model ini cepat" atau "model itu lambat". Kita perlu metrik yang membedah latency menjadi komponen-komponennya, karena setiap komponen memiliki implikasi yang berbeda terhadap pengalaman pengguna dan arsitektur sistem. Tiga metrik utama yang menjadi standar industri adalah TTFT, TPOT, dan end-to-end latency. Bab ini akan mengupas tuntas ketiganya.

Time to First Token (TTFT)

TTFT adalah waktu yang diukur dari saat pengguna mengirimkan prompt hingga token pertama dari respons model mulai muncul di layar. Ini adalah metrik yang paling terasa oleh pengguna—semakin pendek TTFT, semakin responsif aplikasi terasa.

TTFT sebagian besar ditentukan oleh fase Prefill. Komponen-komponen penyusun TTFT meliputi:

1. Network round-trip: Waktu perjalanan data dari klien ke server (biasanya 10–200 ms tergantung lokasi geografis).
2. Queueing delay: Waktu antrean jika server sedang sibuk melayani permintaan lain (0–500 ms tergantung load).
3. Prompt tokenization: Proses memecah teks prompt menjadi token (biasanya <1 ms).
4. Fase Prefill: Forward pass paralel untuk seluruh prompt (yang paling dominan).
5. Sampling token pertama: Memilih token pertama dari logits output (biasanya <1 ms).

Secara kasar, TTFT ≈ Waktu Prefill + overhead jaringan + antrean.

TTFT untuk Berbagai Panjang Prompt

Data di atas menunjukkan bahwa TTFT tumbuh sub-linear terhadap panjang prompt—hasil dari komputasi paralel fase Prefill. Namun, pada konteks sangat panjang (>8.000 token), attention mechanism mulai menjadi bottleneck karena kompleksitas O(N²) dari full attention.

Tokens Per Output Token (TPOT)

TPOT adalah waktu rata-rata yang dibutuhkan untuk menghasilkan satu token output setelah token pertama. Ini setara dengan latency per langkah decode. TPOT adalah metrik yang menentukan seberapa "lancar" atau "tersendat" teks muncul di layar.

TPOT = Total waktu decode ÷ Jumlah token output yang dihasilkan

Contoh: 
Total waktu decode = 6.000 ms
Jumlah token output = 200 token
TPOT = 6.000 ÷ 200 = 30 ms/token
→ Setara dengan ~33 token per detik (tok/s)

TPOT sangat sensitif terhadap beberapa faktor:

• Ukuran model: Model 7B memiliki TPOT ~15–25 ms/token; model 70B memiliki TPOT ~60–120 ms/token; model 405B bisa mencapai 200–400 ms/token pada GPU yang sama.
• Jumlah concurrent request: Semakin banyak request yang dilayani bersamaan dalam satu batch, semakin besar TPOT per request karena total komputasi dibagi untuk lebih banyak request.
• Panjang konteks: Semakin panjang KV Cache (prompt + output sejauh ini), semakin berat operasi attention, sehingga TPOT meningkat secara linear terhadap panjang konteks total.
• Quantization: Model yang dikuantisasi (FP16 → INT8 → INT4) memiliki TPOT lebih rendah karena lebih sedikit data yang perlu dipindahkan dari memori ke prosesor.

End-to-End Latency

End-to-end latency adalah waktu total dari pengiriman prompt hingga seluruh respons selesai diterima oleh pengguna. Ini adalah metrik yang paling holistik dan paling relevan bagi pengguna akhir.

E2E Latency = TTFT + (jumlah_token_output × TPOT) + overhead_komunikasi

Contoh:
TTFT = 40 ms
TPOT = 30 ms/token
Output = 500 token
Overhead jaringan = 100 ms

E2E = 40 + (500 × 30) + 100 = 15.140 ms ≈ 15,1 detik

Perbandingan TTFT vs TPOT untuk Berbagai Skenario

Pentingnya masing-masing metrik sangat tergantung pada use case:

Grafik Perbandingan TTFT vs TPOT

Grafik di atas memperlihatkan secara visual bagaimana komposisi latency berbeda antarskenario. Coding autocomplete memiliki kebutuhan latency yang sangat ketat di kedua metrik (keduanya harus di bawah 20 ms), sementara analisis dokumen panjang lebih mentolerir TTFT yang tinggi selama TPOT tetap wajar.

Contoh Kalkulasi Lengkap: "Butuh Berapa Detik untuk Reply 500 Token?"

Mari kita hitung end-to-end latency untuk skenario realistis menggunakan data benchmark:

Skenario A: Model Llama 3 8B (FP16) di GPU L40S, prompt 500 token, output 500 token:

Skenario B: Model yang sama dengan speculative decoding (spekulasi 3 token per langkah):

Dengan speculative decoding, waktu respons berkurang dari 14 detik menjadi 6 detik—peningkatan 2,3×. Namun speculative decoding tidak selalu membawa hasil yang sama; efektivitasnya sangat bergantung pada acceptance rate (seberapa sering token spekulatif diterima oleh draf model).

Skenario C: Model GPT-4 class (≈1.7T parameter, sparse) di infrastruktur OpenAI:

Meskipun GPT-4 adalah model yang jauh lebih besar dan cerdas, waktu inferensinya tidak 50× lebih lambat dari model 8B (hanya ~3× lebih lambat dalam throughput) berkat optimasi infrastruktur masif—ribuan GPU H100 yang bekerja secara paralel dengan pipeline parallelism, tensor parallelism, dan teknik-teknik tingkat lanjut seperti continuous batching.

Metrik TTFT dan TPOT ini akan menjadi dasar untuk memahami metrik turunan yang akan dibahas di bab berikutnya: tokens per detik (tok/s) dan throughput.

Setelah memahami anatomi latency (TTFT dan TPOT) di bab sebelumnya, kini saatnya membahas metrik-metrik turunan yang menjadi "bahasa universal" dalam industri LLM inference. Jika TTFT dan TPOT adalah metrik mikro yang mengukur setiap langkah individu, maka tok/s dan throughput adalah metrik makro yang menggambarkan performa sistem secara agregat. Bab ini akan menjelaskan perbedaan mendasar ketiganya dan mengapa memilih metrik yang salah bisa menyesatkan.

Definisi dan Perbedaan Ketiga Metrik

1. Tok/s (Tokens Per Second)

Tok/s adalah metrik paling dasar: berapa banyak token yang dapat dihasilkan oleh sistem dalam satu detik. Ini adalah kebalikan dari TPOT:

tok/s = 1 ÷ TPOT (dalam detik)

Jika TPOT = 25 ms, maka tok/s = 1 ÷ 0,025 = 40 tok/s

Metrik ini sering digunakan dalam benchmark untuk membandingkan kecepatan antar model atau antar konfigurasi hardware. Namun, tok/s hanya menggambarkan satu session tunggal—ia tidak memberi informasi tentang bagaimana sistem berperilaku di bawah beban banyak pengguna.

2. Tok/s/user (Tokens Per Second Per User)

Tok/s/user adalah metrik yang mengukur kecepatan token per pengguna dalam sistem multi-tenant. Ini penting karena ketika server melayani banyak pengguna secara bersamaan, kecepatan per pengguna biasanya turun karena resource GPU dibagi.

tok/s/user = Total throughput sistem ÷ Jumlah pengguna aktif

Jika sistem menghasilkan 400 tok/s secara total dan melayani 10 pengguna:
tok/s/user = 400 ÷ 10 = 40 tok/s per pengguna

Dalam sistem yang menggunakan continuous batching, tok/s/user cenderung menurun seiring bertambahnya jumlah pengguna karena setiap batch lebih besar, TPOT per langkah naik, dan setiap pengguna mendapat giliran yang lebih jarang dalam satu siklus batching.

3. Throughput (System Throughput)

Throughput adalah jumlah total token yang dihasilkan oleh sistem per satuan waktu, diukur dari semua pengguna yang aktif. Ini adalah metrik kapasitas sistem—seberapa banyak kerja yang dapat dilakukan hardware dalam satu detik.

Throughput = Jumlah token output ÷ Total waktu (termasuk idle dan queueing)

Dalam satu menit, sistem menghasilkan 24.000 token:
Throughput = 24.000 ÷ 60 = 400 tok/s (sistem)

Throughput adalah metrik yang paling relevan untuk capacity planning dan cost optimization. Ini menentukan berapa banyak pengguna yang dapat Anda layani dengan hardware yang tersedia.

Mengapa tok/s Saja Tidak Cukup?

Melihat tok/s saja memberikan gambaran yang sangat parsial—bahkan menyesatkan. Sebuah sistem mungkin mencapai 500 tok/s saat idle dengan satu pengguna, tetapi turun drastis menjadi 50 tok/s total saat 50 pengguna aktif (yang berarti hanya 1 tok/s per pengguna—sangat lambat). Inilah mengapa kita perlu ketiga metrik secara simultan.

Perhatikan contoh berikut:

Sistem A memiliki tok/s per user tertinggi (80) untuk 1 user, tetapi tidak scalable—tok/s/user turun drastis ke 8,0 saat ada 10 user. Sistem B lebih lambat per user saat idle (60 vs 80), tetapi dengan continuous batching, melalui putaran total meningkat menjadi 140 tok/s dengan 14 tok/s per user. Sistem C adalah yang paling kuat untuk multi-user. Sistem D—inferensi CPU—tidak layak untuk workload real-time.

Hubungan Antara TPOT, tok/s, dan Throughput

Ketiga metrik ini saling terkait secara matematis:

Namun, perlu dicatat bahwa hubungan ini tidak linear sempurna. Ketika batch_size bertambah, TPOT per langkah juga bertambah (karena satu forward pass harus memproses lebih banyak sequence), sehingga tok/s per user tidak sama dengan tok/s standalone dibagi jumlah user.

Contoh Kalkulasi: Throughput untuk 10 User

Mari kita hitung kebutuhan dan kapasitas sistem untuk skenario aplikasi chatbot yang melayani 10 pengguna secara bersamaan.

Asumsi:

• Setiap pengguna mengirimkan prompt 200 token dan mengharapkan respons 300 token
• Target: setiap pengguna selesai dalam waktu ≤ 15 detik
• GPU yang digunakan: NVIDIA L40S dengan continuous batching

Langkah 1: Hitung total token yang perlu dihasilkan

Total token output = 10 user × 300 token = 3.000 token
Target waktu = 15 detik
Throughput minimum yang diperlukan = 3.000 ÷ 15 = 200 tok/s

Langkah 2: Verifikasi dengan karakteristik hardware

Dengan continuous batching, L40S untuk model 8B dapat mencapai throughput ~250 tok/s pada batch size 10. Ini berarti setiap langkah decode memproses 10 sequence sekaligus, dengan TPOT per langkah sekitar 40 ms (naik dari 25 ms saat single user karena total sequence length dalam batch lebih panjang). Jadi throughput efektif:

Throughput = batch_size ÷ TPOT_per_langkah
           = 10 ÷ 0,04
           = 250 tok/s ✅ (di atas 200, memenuhi target)

tok/s/user = 250 ÷ 10 = 25 tok/s per pengguna
→ Waktu per pengguna untuk 300 token = 300 ÷ 25 = 12 detik ✅

Langkah 3: Hitung dengan margin keamanan

Dalam praktiknya, throughput tidak konstan karena panjang sequence bervariasi dan ada overhead seperti Prefill untuk prompt baru. Kita tambahkan margin 30%:

Token per user (dengan margin = 1,3×) = 300 × 1,3 = 390 token
Total token = 10 × 390 = 3.900 token
Throughput yang dibutuhkan (15 detik) = 3.900 ÷ 15 = 260 tok/s

Dengan L40S: throughput 250 tok/s ❌ (sedikit di bawah target)
→ Solusi: Kurangi batch size jadi 8 user simultaneous, atau upgrade ke H100 (throughput ~450 tok/s)

Kalkulasi di atas menunjukkan betapa pentingnya perencanaan kapasitas yang akurat. Margin 30% sering diperlukan karena faktor-faktor seperti prompt preprocessing, attention overhead dari KV Cache yang membesar, dan scheduling overhead dalam continuous batching.

Tabel Perbandingan Metrik untuk Berbagai Konfigurasi GPU

Data di atas menunjukkan beberapa insight penting:

• Quantization memberi keuntungan 2-3× pada tok/s karena mengurangi bandwidth memori yang dibutuhkan—bottleneck utama fase Decode.
• Model besar dengan quantisasi (70B INT4) bisa setara dengan model kecil FP16 dalam hal throughput per user (25 vs 22,5 tok/s/user), tetapi dengan kualitas output yang lebih baik.
• Efisiensi biaya: RTX 4090 dengan INT4 memiliki rasio tok/s/$ terbaik untuk model kecil. H100 unggul untuk model besar yang membutuhkan lebih banyak VRAM.
• Continuous batching meningkatkan throughput 3-6× dibandingkan single-user, tetapi tok/s/user turun karena sumber daya dibagi.

Pemahaman tentang ketiga metrik ini—tok/s, tok/s/user, dan throughput—memungkinkan Anda membuat keputusan yang tepat tentang hardware, konfigurasi, dan kapasitas. Bab terakhir bagian ini akan menjelaskan mengapa semua metrik ini pada akhirnya bermuara pada satu hal: pengalaman pengguna.

Sejauh ini kita telah mempelajari apa itu token, bagaimana LLM menghasilkan token, dan bagaimana mengukur kecepatannya. Sekarang muncul pertanyaan paling praktis: mengapa semua ini penting? Apakah selisih 10 tok/s benar-benar terasa? Pada titik mana kecepatan token menjadi "cukup"? Dan apa dampak token speed yang lambat terhadap bisnis, produktivitas, dan psikologi pengguna? Bab ini menjawab pertanyaan-pertanyaan tersebut.

Pengalaman Pengguna (UX): Delay >2s Bikin Frustrasi

Penelitian tentang response time tolerance sudah mapan sejak era web 1.0 dan diperkuat oleh studi UX modern. Prinsip-prinsip berikut berlaku langsung untuk LLM inference:

• 0,1 detik: Batas di mana pengguna merasa sistem bereaksi secara instan. Tidak diperlukan indikator loading.
• 1,0 detik: Batas di mana alur pikir pengguna tetap tidak terputus. Pengguna mungkin menyadari adanya delay, tetapi belum merasa terganggu.
• 2,0 detik: Ambang batas kritis. Di atas 2 detik, pengguna mulai kehilangan fokus dan menunggu secara sadar. Risiko abandon meningkat.
• 5,0 detik: Sebagian besar pengguna akan meninggalkan aplikasi atau mencari alternatif.
• 10 detik+: Hanya pengguna yang sangat termotivasi yang akan bertahan. Cocok untuk batch processing, bukan interaksi real-time.

Untuk LLM, ambang batas ini perlu diterjemahkan secara hati-hati karena respons model bersifat streaming—tidak seperti halaman web yang muncul sekaligus. Jika TTFT (waktu hingga token pertama) melebihi 1 detik, pengguna akan merasa aplikasi "lag". Jika TPOT terlalu lambat (misalnya >50 ms/token → <20 tok/s), pengguna akan melihat teks muncul dengan kecepatan yang mengganggu—lebih lambat dari kecepatan membaca normal (200-300 kata per menit ≈ 30-50 tok/s untuk bahasa Indonesia).

Ironisnya, streaming sebenarnya membuat persepsi latency lebih buruk daripada respons non-streaming untuk total waktu yang sama. Ketika pengguna melihat teks muncul kata demi kata, mereka secara psikologis "menunggu" setiap kata baru, menciptakan pengalaman subjektif yang lebih lambat daripada jika seluruh teks muncul sekaligus setelah 10 detik. Inilah mengapa kecepatan token yang konsisten dan tinggi mutlak diperlukan untuk aplikasi LLM interaktif.

Perbandingan Kecepatan Token Antar Model

Perbedaan antara GPT-4o (~100 tok/s) dan model lokal 70B di GPU konsumen (~15 tok/s) bukan sekadar angka—ia adalah perbedaan antara percakapan yang terasa natural dan percakapan yang membuat pengguna menunggu 3-5 detik untuk setiap kalimat pendek. Untuk konteks yang lebih jelas: kecepatan membaca rata-rata manusia dewasa adalah sekitar 200-250 kata per menit (~30-40 tok/s untuk bahasa Indonesia). Jika model menghasilkan token di bawah 30 tok/s, pengguna secara teknis membaca lebih cepat daripada model menulis—pengalaman yang membuat frustrasi.

Dampak pada Produktivitas Coding

Token speed memiliki dampak yang sangat terukur dalam konteks coding assistant seperti GitHub Copilot, Cursor, atau Continue.dev. Studi tentang produktivitas developer menunjukkan korelasi langsung antara latency autocomplete dan jumlah saran yang diterima:

Data ini menunjukkan bahwa ada threshold kritis sekitar 20-30 tok/s di bawah mana autocomplete menjadi kontraproduktif. Developer akan menolak saran karena mereka sudah selesai mengetik sendiri sebelum saran selesai muncul. Di sisi lain, di atas 50 tok/s, autocomplete terasa "ajaib" dan menjadi bagian integral dari alur kerja.

Dampak pada Customer Service

Dalam aplikasi customer service berbasis LLM, setiap milidetik latency memiliki dampak finansial. Sebuah studi oleh Google Cloud menunjukkan bahwa:

• Setiap 1 detik tambahan latency pada chatbot customer service mengurangi customer satisfaction score (CSAT) sebesar 5-8%.
• 80% pelanggan akan meninggalkan percakapan jika respons pertama (TTFT) melebihi 3 detik.
• 50% pelanggan yang mengalami latency tinggi tidak akan kembali menggunakan layanan tersebut.

Untuk aplikasi di mana kecepatan adalah faktor kritis—seperti real-time translation, voice assistant, atau financial trading assistant—kecepatan token di bawah 20 tok/s dapat membuat aplikasi tidak dapat digunakan sama sekali. Bayangkan seorang trader yang meminta analisis real-time pasar saham dan harus menunggu 15 detik untuk respons 300 token yang datang tersendat-sendat. Dalam konteks seperti ini, latency bukan hanya masalah UX—ia adalah masalah bisnis.

Tabel Skenario dan Kebutuhan Minimum tok/s

Contoh Kalkulasi Dampak Token Speed pada Produktivitas

Mari kita hitung dampak kuantitatif perbedaan token speed untuk tim developer yang menggunakan coding assistant:

Parameter:

• Tim: 20 developer
• Saran autocomplete per developer per jam: tergantung tok/s (lihat tabel di atas)
• Jam kerja efektif coding: 5 jam/hari
• Hari kerja: 220 hari/tahun
• Rata-rata gaji developer (Indonesia, senior): Rp 40.000.000/bulan
• Nilai per jam developer: Rp 40.000.000 ÷ 160 jam ≈ Rp 250.000/jam

Skenario A: Token speed tinggi (80 tok/s → 50 saran diterima/jam)

Total saran diterima per hari = 50 × 5 = 250 saran/developer/hari
Estimasi waktu hemat per saran = 15 detik (mengetik manual)
Total waktu hemat = 250 × 15 = 3.750 detik ≈ 62,5 menit/developer/hari
Nilai waktu hemat = 62,5 menit × (Rp 250.000 ÷ 60) ≈ Rp 260.000/developer/hari
Nilai setahun = Rp 260.000 × 220 × 20 = Rp 1.144.000.000

Skenario B: Token speed rendah (10 tok/s → 5 saran diterima/jam)

Total saran diterima per hari = 5 × 5 = 25 saran/developer/hari
Estimasi waktu hemat per saran = 8 detik (saran sering tidak lengkap)
Total waktu hemat = 25 × 8 = 200 detik ≈ 3,3 menit/developer/hari
Nilai waktu hemat = 3,3 menit × (Rp 250.000 ÷ 60) ≈ Rp 13.750/developer/hari
Nilai setahun = Rp 13.750 × 220 × 20 = Rp 60.500.000

Perbedaan antara skenario A dan B: Rp 1,14 miliar vs Rp 60,5 juta per tahun—hampir 20× lipat. Untuk tim 20 developer, investasi dalam infrastruktur inferensi yang lebih cepat (dari GPU konsumen ke H100 atau layanan API premium) memberikan ROI yang sangat jelas.

Kesimpulan Bagian 1

Bagian ini telah membangun fondasi yang kokoh untuk memahami token generation. Kita telah belajar bahwa:

1. Token adalah unit dasar pemrosesan LLM—bukan kata atau karakter—dan pemahaman tentang tokenisasi penting untuk mengestimasi biaya dan kinerja.
2. Inferensi LLM terdiri dari dua fase yang sangat berbeda: Prefill (paralel, compute-bound) dan Decode (sequential, memory-bound). Sebagian besar waktu dan optimasi inference berfokus pada Decode.
3. Latency diukur melalui TTFT (waktu ke token pertama), TPOT (waktu per token output), dan end-to-end latency. Setiap metrik memiliki implikasi berbeda terhadap UX dan arsitektur.
4. Metrik kinerja seperti tok/s, tok/s/user, dan throughput memberikan pandangan yang saling melengkapi. Tidak cukup hanya melihat satu metrik; ketiganya diperlukan untuk perencanaan kapasitas yang akurat.
5. Token speed memiliki dampak langsung pada pengalaman pengguna, produktivitas, dan finansial. Ambang batas 20-30 tok/s adalah minimum untuk aplikasi interaktif; 50+ tok/s adalah target untuk pengalaman yang memuaskan.

Dengan pemahaman ini, kita siap melanjutkan ke Bagian 2, yang akan membahas infrastruktur dan konfigurasi hardware—bagaimana memilih GPU, mengoptimalkan VRAM, dan mengkonfigurasi sistem untuk mencapai token speed yang diinginkan.

Pada Bagian 1 kita telah mempelajari rumus fundamental dan alur komputasi di balik setiap token yang dihasilkan oleh LLM. Sekarang saatnya bertanya: mengapa dua model yang berbeda—atau bahkan model yang sama di dua mesin berbeda—bisa menghasilkan token dengan kecepatan yang sangat timpang? Jawabannya tidak pernah tunggal. Kecepatan token adalah hasil interaksi kompleks antara arsitektur model, presisi numerik, perangkat keras, bandwidth memori, panjang konteks, dan strategi batching. Bab-bab berikut akan mengupas satu per satu faktor tersebut dengan data dan kalkulasi konkret.

Hubungan antara jumlah parameter (parameter count) dan kecepatan token bersifat hampir linear: dua kali lipat parameter berarti dua kali lipat FLOPs yang harus dihitung, yang—dengan hardware yang sama—berarti sekitar setengah kecepatan token. Namun kenyataannya lebih bernuansa karena parameter juga menentukan VRAM yang dibutuhkan, yang pada gilirannya menentukan apakah model bisa dimuat di GPU tertentu atau harus dijalankan lebih lambat via CPU offloading.

6.1 Hubungan Parameter → VRAM → FLOPs

Untuk memahami rantai kausalnya, mari kita mulai dari rumus dasar VRAM yang dibutuhkan untuk menyimpan bobot model:

VRAM (GB) = (Parameter Count × Bytes per Parameter) / 2³⁰

Nilai Bytes per Parameter bergantung pada presisi numerik yang digunakan (dibahas detail di Bab 7). Pada FP16, setiap parameter membutuhkan 2 byte; pada FP32, 4 byte; pada INT4, 0,5 byte.

Tabel berikut menunjukkan kebutuhan VRAM untuk beberapa ukuran model populer pada berbagai presisi:

Perhatikan bahwa kolom NF4 (kiri) menunjukkan angka sedikit lebih besar dari INT4 murni. Ini karena NF4 menggunakan representasi floating-point 4-bit yang memiliki distribusi nilai non-uniform, membutuhkan metadata tambahan (scaling factors) sekitar 0,125-0,25 bit per parameter.

6.2 Kalkulasi Kecepatan: 7B vs 70B

Mari kita hitung dampak parameter count pada token speed secara konkret. Ambil Llama 3 7B dan Llama 3 70B, keduanya dijalankan di GPU A100 80GB (SXM3, 2039 GB/s bandwidth) pada FP16.

Model 7B (FP16):

VRAM bobot = 7 × 10⁹ × 2 = 14 × 10⁹ byte ≈ 13,1 GB
FLOPs forward pass ≈ 2 × 7 × 10⁹ × (seq_len × n_layers × d_model × ...)
Token/s ≈ bandwidth / (param × bytes_per_param)
           ≈ 2039 GB/s / (7 × 10⁹ × 2)
           ≈ 2039 / 14
           ≈ 145,6 token/s

Model 70B (FP16):

VRAM bobot = 70 × 10⁹ × 2 = 140 × 10⁹ byte ≈ 130,4 GB
Token/s ≈ 2039 / (70 × 2)
           ≈ 2039 / 140
           ≈ 14,6 token/s

Perbandingan:

Rasio parameter = 70B / 7B = 10×
Rasio VRAM      = 130,4 / 13,1 ≈ 10×
Rasio speed     = 14,6 / 145,6 ≈ 0,10×

Model 70B 10× lebih besar dan menghasilkan token 10× lebih lambat pada GPU yang sama — tepat sesuai prediksi linear. Namun di dunia nyata, rasio bisa sedikit berbeda karena overhead komunikasi (pada model yang membutuhkan multi-GPU) dan faktor arithmetic intensity yang dibahas pada Bagian 3.

6.3 Non-Linear pada Multi-GPU

Ketika model terlalu besar untuk satu GPU (misal Llama 405B), model harus didistribusikan ke banyak GPU. Di sinilah faktor non-linear mulai bermain:

• Overhead komunikasi: Setiap lapisan membutuhkan all-reduce antar GPU, menambah latensi non-linear.
• Scaling efficiency: Idealnya 8 GPU = 8× lebih cepat, tapi efisiensi riil 75-90% karena komunikasi.
• Pipeline bubbles: Pada pipeline parallelism, ada periode idle saat GPU menunggu data dari GPU lain.

Kesimpulan Bab 6: parameter count adalah faktor dominan namun bukan satu-satunya. Model besar memang lebih lambat, tetapi quantization (Bab 7) dan pemilihan hardware yang tepat (Bab 8) dapat memitigasi sebagian besar slowdown tersebut.

Quantization adalah teknik mengurangi presisi numerik bobot model untuk menekan ukuran VRAM dan mempercepat inferensi — dengan konsekuensi penurunan kualitas output. Ini seperti menyimpan foto sebagai JPEG alih-alih RAW: ukuran file jauh lebih kecil, tapi detail halus mungkin hilang. Di dunia LLM, quantization memungkinkan model 70B berjalan di GPU konsumen yang hanya memiliki VRAM 24 GB.

7.1 Bagaimana Quantization Bekerja

Bobot LLM awalnya dilatih dalam FP32 (32-bit floating-point, presisi penuh). Sebagian besar framework kemudian mengonversi ke FP16 untuk inferensi tanpa kehilangan kualitas berarti. Quantization melangkah lebih jauh:

• FP16 → INT8: Setiap bobot 16-bit dipetakan ke 8-bit integer (256 nilai diskrit). Scaling factor menyimpan rentang asli.
• INT8 → INT4: Hanya 16 nilai yang tersedia per bobot. Dibutuhkan group quantization (biasanya per 32-128 parameter) agar presisi tetap terjaga.
• NF4: Format 4-bit NormalFloat dari QLoRA, menggunakan distribusi normal untuk memetakan nilai — informasi lebih banyak disimpan di zona densitas tinggi.

Prosesnya kurang lebih sebagai berikut:

Diketahui:
- Bobot asli: w ∈ [w_min, w_max] dalam FP16
- Quantized:  w_q = round((w - w_min) / (w_max - w_min) × (2^n - 1))
- Dequantized: w' = w_min + w_q × (w_max - w_min) / (2^n - 1)
- Error:      ε = |w - w'|

Semakin kecil n, semakin besar error kuantisasi rata-rata. Namun karena bobot LLM cenderung terdistribusi normal di sekitar nol, error ini sering tidak terlalu memengaruhi output final — terutama untuk model besar yang sudah memiliki inherent redundancy.

7.2 Tabel Perbandingan Presisi

7.3 Studi Kasus: Gemma 4 12B

Mari kita bandingkan Gemma 4 12B dalam dua konfigurasi: FP16 di A100 80GB vs Q4_K_M (4-bit GGUF) di RTX 4090 24GB.

Konfigurasi A: FP16 di A100 80GB

VRAM bobot      = 12 × 10⁹ × 2 = 24 GB
VRAM total      ≈ 24 + 4 GB (KV cache + overhead) = ~28 GB
Bandwidth       = 2039 GB/s (A100 SXM)
Token/s teoritis = 2039 / (12 × 2) = 85 token/s
Token/s riil    ≈ 50-65 token/s (tergantung context length)

Konfigurasi B: Q4_K_M di RTX 4090

VRAM bobot      ≈ 12 × 10⁹ × 0,5 = 6 GB (+ metadata ~1,5 GB)
VRAM total      ≈ 7,5 + 4 GB = ~11,5 GB
Bandwidth       = 1008 GB/s (RTX 4090)
Token/s teoritis = 1008 / (12 × 0,5 + ~1 bit overhead)
                  ≈ 1008 / 7 = 144 token/s
Token/s riil    ≈ 70-90 token/s (tergantung implementasi)

Hasilnya menarik: meskipun A100 adalah GPU kelas data center yang lebih mahal, RTX 4090 dengan Q4 menghasilkan token lebih cepat (70-90 vs 50-65 tok/s) karena quantization mengurangi ukuran data yang harus ditransfer dari VRAM ke compute unit — dan RTX 4090 memiliki memory bandwidth yang sangat kompetitif.

7.4 Rekomendasi per Skenario

• Production API (high latency, high throughput): FP16/FP8. Prioritaskan kualitas. Gunakan A100/H100 dengan VRAM besar.
• Local deployment (GPU konsumen, 8-24 GB VRAM): Q4_K_M atau Q5_K_M. Kualitas hampir setara FP16 untuk sebagian besar tugas.
• Edge device / Mobile: Q4 atau Q2 + pruning/distillation. Kualitas sekunder terhadap ukuran dan kecepatan.
• Fine-tuning: QLoRA (NF4 base). Memungkinkan fine-tuning model 70B di satu RTX 4090 24GB.
• Benchmarking / Riset: FP32 sebagai ground truth, FP16 untuk kecepatan wajar dengan presisi penuh.

Poin kunci: quantization bukan "gratis". Setiap bit yang dihemat mengurangi ruang representasi bobot. Namun untuk sebagian besar aplikasi praktis, trade-off Q4 sangat masuk akal — terutama ketika pilihannya adalah "Q4 di GPU lokal" vs "tidak bisa jalan sama sekali."

Tidak semua prosesor diciptakan sama. CPU dirancang untuk eksekusi berurutan yang fleksibel; GPU untuk komputasi paralel masif; TPU untuk tensor operasi terakselerasi; NPU untuk inferensi efisien daya; dan ASIC untuk satu tugas spesifik. Masing-masing memiliki profil kecepatan, biaya, dan efisiensi yang sangat berbeda untuk menjalankan LLM.

8.1 Perbandingan Semua Jenis Hardware

8.2 Kenapa GPU Mendominasi LLM?

Ada tiga alasan utama GPU menjadi pilihan utama untuk inferensi LLM:

1. Memory Bandwidth Raksasa: LLM adalah memory-bound (dibahas di Bab 9). GPU H100 memiliki bandwidth 3352 GB/s — 67× lipat CPU DDR5. Setiap token membutuhkan pembacaan seluruh bobot model dari memori, sehingga bandwidth adalah segalanya.
2. Tensor Cores: GPU modern (NVIDIA Volta+) memiliki tensor core yang mengkhususkan diri pada operasi matriks — inti dari forward pass LLM. Satu tensor core dapat melakukan multiply-add matriks 4×4 dalam satu siklus.
3. Parallelism Inheren: Operasi attention mechanism dan feed-forward network dapat diparalelkan secara masif. GPU dengan ribuan CUDA core mengeksekusi ribuan thread ini secara simultan.

8.3 Kapan CPU Cukup?

CPU masih relevan untuk LLM dalam beberapa skenario spesifik:

• Model sangat kecil (≤1,5B) di Q4 — misal Gemma 2 2B atau Phi-3 mini. CPU modern dapat mencapai 5-15 tok/s, cukup untuk chatbot sederhana.
• Batch size = 1, latensi bukan prioritas — aplikasi batch processing semalam.
• Biaya — GPU tidak tersedia — deploy di VPS murah tanpa GPU.
• RAM besar murah — CPU dengan 128 GB RAM dapat menjalankan 70B di Q4 via llama.cpp, meski hanya 1-3 tok/s.

Perbandingan konkret: Llama 3 8B Q4_K_M
- CPU AMD 7950X (128GB DDR5): ~4-6 tok/s
- RTX 4090: ~90-120 tok/s
- A100 SXM: ~160-200 tok/s
Rasio: 1× (CPU) : 20× (4090) : 35× (A100)

8.4 TPU, NPU, dan ASIC — Masa Depan?

TPU unggul untuk training skala besar berkat MXU (Matrix Multiply Unit) dan interkoneksi cepat. Namun untuk inferensi, TPU kurang fleksibel dibanding GPU untuk arsitektur model non-Transformer dan memiliki cold start yang lebih lambat (akuisisi via cloud).

NPU — seperti Neural Engine Apple — luar biasa efisien untuk model kecil di perangkat edge. Apple M3 Ultra dapat menjalankan Llama 3 8B via MLX dengan ~20-30 tok/s, hanya dengan ~30W.

ASIC — Groq LPU adalah contoh menarik: menggunakan SRAM sebagai pengganti HBM, sehingga mencapai latensi per token yang sangat rendah (≤1 ms/token). Namun total throughput dibatasi oleh kapasitas SRAM yang kecil (~230 MB per LPU). Untuk model modern yang besar, diperlukan puluhan LPU — dan biaya serta skalabilitasnya masih dipertanyakan.

Inilah faktor yang paling sering disalahpahami: memory bandwidth, bukan compute FLOPs, adalah bottleneck utama inferensi LLM. Untuk urutan autoregressive (decoding satu token per langkah), GPU menghabiskan sebagian besar waktunya menunggu data bobot model tiba dari VRAM, bukan menghitung. Mari kita bedah mengapa.

9.1 Memory-Bound vs Compute-Bound

Sebuah operasi dikatakan memory-bound jika waktu yang dibutuhkan untuk mentransfer data dari/ke memori lebih besar dari waktu komputasi itu sendiri. Inferensi LLM (fase decoding) adalah contoh klasik:

Operasi: y = W · x (matriks × vektor)
- W: bobot model, ukuran [d_model, d_model] = ~4M parameter (untuk d_model=4096)
- x: satu vektor aktivasi, ukuran [d_model]

Pada FP16:
- Data dibaca: 4M × 2 byte = 8 MB
- Bandwidth GPU: 1008 GB/s (RTX 4090)
- Waktu transfer: 8 MB / 1008 GB/s ≈ 7,9 μs
- Waktu komputasi: ~1-3 μs (dengan tensor core)

Rasio: komputasi < transfer → MEMORY-BOUND

Artinya, kecepatan token ditentukan terutama oleh seberapa cepat GPU dapat membaca bobot model dari VRAM, bukan seberapa cepat GPU dapat mengalikan matriks.

9.2 Rumus Token Speed yang Disempurnakan

Token/s = MemoryBandwidth / (ParameterCount × BytesPerParameter)

Rumus ini mengasumsikan kondisi ideal: model termuat penuh di VRAM, bandwidth termanfaatkan 100%, tanpa overhead KV Cache (dibahas di Bab 10). Di dunia nyata, faktor utilisasi bandwidth biasanya 60-90%.

Mari terapkan ke tiga skenario hardware berbeda dengan model Llama 3 8B FP16:

9.3 Mengapa FLOPs Tidak Selalu Relevan

GPU modern memiliki compute capability yang jauh melampaui kemampuan mereka untuk menyuplai data. RTX 4090 memiliki 82,6 TFLOPS FP16, tetapi untuk operasi matriks×vektor pada decoding LLM, hanya sebagian kecil yang terpakai karena GPU menghabiskan banyak waktu menunggu data. Inilah yang disebut roofline model: kinerja aktual adalah minimum dari peak compute dan peak bandwidth — dan untuk decoding LLM, bandwidth hampir selalu menjadi batasan.

Arithmetic Intensity (AI) = FLOPs / Bytes

Untuk decoding:
- FLOPs per token ≈ 2 × N_param
- Bytes per token ≈ N_param × bytes_per_param

AI = (2 × N) / (N × 2) = 1 FLOP/byte (pada FP16)

Bandingkan dengan operasi compute-bound (training batch besar):
- AI = 100-200 FLOP/byte
- Performa dibatasi oleh FLOPs, bukan bandwidth

Implikasinya: harga GPU tidak selalu linier dengan performa LLM. RTX 4090 ($1.600, 1008 GB/s) memberikan token speed sekitar 50% dari A100 80GB ($15.000, 2039 GB/s) — rasio harga-per-token yang jauh lebih baik untuk inferensi. Namun untuk training, A100 unggul berkat FLOPs yang jauh lebih tinggi.

Fenomena yang sering dirasakan pengguna: semakin panjang percakapan, semakin lambat respons model. Ini bukan imajinasi. Penyebabnya adalah KV Cache — struktur memori yang menyimpan Key dan Value dari setiap token dalam konteks, dan ukurannya membesar secara linear seiring panjang konteks. KV Cache yang besar tidak hanya memakan VRAM, tetapi juga memperlambat setiap langkah decoding karena model harus membaca K/V dari semakin banyak token untuk menghitung attention.

10.1 Apa Itu KV Cache?

Dalam mekanisme self-attention, setiap token baru harus menghitung skor attention terhadap semua token sebelumnya. Tanpa KV Cache, model harus menghitung ulang Key dan Value untuk semua token sebelumnya setiap kali token baru diprediksi — sangat tidak efisien. Solusinya: simpan K dan V dari setiap lapisan attention untuk semua token yang sudah diproses, dan gunakan kembali.

Tanpa KV Cache (redundan):
- Token ke-100: hitung attention untuk token 1..100 → K(1..100), V(1..100)
- Token ke-101: hitung attention untuk token 1..101 → K(1..101), V(1..101) 
  → 99% komputasi dari langkah sebelumnya diulang!

Dengan KV Cache:
- Setelah langkah 1: simpan K₁, V₁ di cache
- Langkah ke-t: hanya hitung K_t, V_t, lalu append ke cache yang sudah ada
- Komputasi konstan per langkah, tidak bergantung panjang konteks (sebenarnya sedikit bergantung pada attention)

10.2 Rumus Ukuran KV Cache

KV Cache Size = 2 × seq_len × n_layers × d_kv × n_heads × bytes_per_param

Penjelasan variabel:

• 2: untuk Key dan Value
• seq_len: panjang konteks (token)
• n_layers: jumlah lapisan transformer
• d_kv: dimensi per head (biasanya d_model / n_heads)
• n_heads: jumlah attention heads
• bytes_per_param: 2 (FP16) atau 1 (INT8)

Dalam satu lapisan: d_kv × n_heads = d_model. Maka rumus dapat disederhanakan:

KV Cache Size ≈ 2 × seq_len × n_layers × d_model × bytes_per_param

Perhatikan bahwa untuk Llama 3 70B dengan context length 128K token, KV Cache mencapai 160 GB — lebih besar dari bobot model itu sendiri (130 GB FP16). Total VRAM yang dibutuhkan: 130 + 160 + overhead ≈ 300 GB, atau setara 4× A100 80GB hanya untuk menjalankan satu permintaan dengan konteks penuh.

10.3 Dampak pada Token Speed

KV Cache yang besar memperlambat inferensi melalui dua mekanisme:

1. Memory Bandwidth Tambahan: Setiap langkah decoding harus membaca seluruh KV Cache dari VRAM ke register untuk perhitungan attention. Semakin besar cache, semakin banyak data yang harus ditransfer.
2. Attention Complexity O(n²): Meskipun menggunakan KV Cache, perhitungan attention masih membutuhkan skor untuk setiap pasangan token, yang skala kuadratik terhadap panjang konteks untuk prefill phase.

Contoh: Llama 3 8B di RTX 4090
- Context 1K: token/s ≈ 55 tok/s
- Context 8K: token/s ≈ 45 tok/s (menurun ~18%)
- Context 32K: token/s ≈ 30 tok/s (menurun ~45%)
- Context 128K: tidak muat (24 GB VRAM terpakai habis oleh KV Cache ~32 GB)

10.4 Teknik Mitigasi KV Cache

Beberapa teknik telah dikembangkan untuk mengurangi beban KV Cache:

• Multi-Query Attention (MQA): Semua head berbagi Key dan Value yang sama, mengurangi cache hingga 4-8×. Digunakan di Falcon, PaLM.
• Grouped Query Attention (GQA): Kompromi antara MHA dan MQA — beberapa head berbagi K/V yang sama. Digunakan di Llama 2/3, Gemma.
• KV Cache Quantization: Menyimpan KV Cache dalam INT8 (1 byte per elemen) bukan FP16 — menghemat 50% VRAM. Digunakan di vLLM dan TGI.
• Sliding Window & Sparse Attention: Hanya menyimpan K/V dari token terdekat (misal 4K token terakhir), token yang lebih lama di-drop atau di-aggregate.
• PagedAttention: vLLM mengelola KV Cache seperti page table pada OS — alokasi non-kontigu, mengurangi fragmentasi hingga 80%.

Kesimpulan Bab 10: context window bukan fitur gratis. Setiap kali Anda memberi model beberapa halaman dokumen sebagai konteks, Anda secara implisit meminta GPU untuk menyimpan dan memproses ribuan vektor Key-Value tambahan. Untuk aplikasi dengan konteks sangat panjang (>32K), mitigasi seperti GQA dan KV cache quantization bukan opsional — melainkan keharusan.

Bayangkan sebuah restoran: melayani satu pelanggan dengan cepat itu mudah, tetapi melayani 100 pelanggan secara efisien membutuhkan strategi — apakah Anda antrekan mereka, buka meja tambahan, atau gunakan sistem prasmanan? Dalam inferensi LLM, pertanyaan yang sama muncul dalam bentuk batch size: berapa banyak permintaan yang diproses secara bersamaan. Bab ini membahas trade-off antara latency per-user dan throughput total, serta inovasi seperti continuous batching yang mengubah aturan main.

11.1 Trade-Off Batch Size: Latency vs Throughput

Batch size yang lebih besar meningkatkan throughput (total token per detik) karena GPU memanfaatkan paralelismenya lebih efisien — operasi matriks×matriks (dengan batch) jauh lebih efisien daripada matriks×vektor (tanpa batch). Namun, setiap permintaan dalam batch harus menunggu permintaan terlama selesai, sehingga latensi per-user meningkat.

Rumus:
- Latency per batch ≈ max(latency_i) untuk semua i dalam batch
- Throughput = sum(all tokens generated) / total_time

Pada model 7B FP16 di A100 80GB:

Batch size = 1:
- Latency per-token: ~10 ms / token
- Throughput: 100 tok/s
- Time-to-first-token (TTFT): ~30 ms

Batch size = 8:
- Latency per-token: ~35 ms / token (naik 3,5×)
- Throughput: ~650 tok/s (naik 6,5×)
- TTFT: ~100 ms

Batch size = 32:
- Latency per-token: ~120 ms / token
- Throughput: ~1.800 tok/s
- TTFT: ~350 ms

Perhatikan bahwa throughput naik lebih cepat dari latensi — inilah mengapa batching dianggap strategi efektif untuk efisiensi.

11.2 Static Batching vs Continuous Batching

Static batching (tradisional): Kumpulkan N permintaan, proses semuanya bersama, kirim hasilnya. Jika satu permintaan menghasilkan 50 token dan yang lain 500 token, permintaan pendek harus menunggu yang panjang selesai — membuang-buang waktu GPU untuk permintaan yang sudah selesai.

Continuous batching (juga disebut inflight batching atau iteration-level batching): Setiap langkah decoding, batch dapat berubah. Permintaan yang sudah selesai dikeluarkan, permintaan baru bisa masuk di iterasi berikutnya. Ini memaksimalkan utilisasi GPU karena tidak ada waktu idle menunggu permintaan terlama.

Perbandingan visual:

Static Batching (waktu):
|── Req A (20 iter) ── Req B (100 iter) ──|
                    ↑ idle 80 iter untuk A

Continuous Batching (waktu):
|── Req A1 ─── Req A2 ─── Req A3 ─── ... ── Req A20 ──|
|── Req B1 ─── Req B2 ─── Req B3 ─── ... ───────── Req B100 ──|
                  ↑ Req A selesai, slot dipakai Req C

Hasil: Utilisasi GPU 85-95% vs 50-70% pada static batching.

vLLM mengimplementasikan continuous batching melalui PagedAttention, di mana KV Cache setiap permintaan dikelola seperti halaman memori virtual. Ini memungkinkan:

• Alokasi memori yang fleksibel — tidak perlu menyisihkan VRAM maksimum untuk setiap permintaan
• Fragmentasi KV Cache minimal
• Copy-on-write untuk shared prefix (misal: system prompt yang sama)

11.3 Dampak Concurrent Users pada Arsitektur Serving

Bayangkan Anda menjalankan Llama 3 8B di satu A100 80GB dan melayani N pengguna secara simultan:

Dengan static batching batch_size=8:
- Maksimal 8 permintaan diproses bersamaan
- Sisa permintaan antri
- Throughput: ~650 tok/s
- Jika tiap user rata-rata menghasilkan 500 token:
  - Waktu per user: ~35 ms × 500 = 17,5 detik
  - Kapasitas: ~37 user/jam per GPU

Dengan continuous batching (vLLM):
- Hingga ~64 permintaan dalam flight (tergantung VRAM)
- Throughput: ~2.000 tok/s
- Waktu per user (500 token): ~120 ms × 500 = 60 detik
  *Tapi ini paralel untuk semua 64 user!*
- Kapasitas: ~3.800 user/jam per GPU

Perbedaan 100× dalam kapasitas — inilah mengapa framework serving modern seperti vLLM, TGI, dan TensorRT-LLM adalah standar industri, bukan opsi.

11.4 Hukum Amdahl untuk LLM Serving

Hukum Amdahl menyatakan bahwa percepatan sistem dibatasi oleh bagian yang tidak dapat diparalelkan. Dalam LLM serving:

Speedup = 1 / ((1 - P) + P/N)

P = bagian yang dapat diparalelkan (komputasi matriks)
N = jumlah unit paralel
(1-P) = bagian serial (overhead scheduling, I/O)

Untuk batch size 32 pada A100:
- P ≈ 0,88 (88% paralelisable)
- N ≈ 32 (efektif karena tensor core)
- Speedup = 1 / (0,12 + 0,88/32)
          ≈ 1 / 0,1475 ≈ 6,78× (bukan 32×!)

Ini menjelaskan mengapa efisiensi GPU menurun pada batch yang sangat besar.

Kesimpulan Bab 11: batch size adalah dial yang paling ampuh untuk menyeimbangkan latency dan throughput. Untuk aplikasi real-time (chat), batch size kecil (1-4) memberikan respons cepat. Untuk API publik dengan banyak pengguna, continuous batching dengan batch size 32-64 memberikan kapasitas maksimal. Framework seperti vLLM memungkinkan keduanya tanpa perubahan konfigurasi model — hanya dengan mengatur parameter scheduling.

— Akhir Bagian 2 —

DONE: part 02, ~3780 words

Setelah memahami arsitektur dasar transformer dan mekanisme attention, langkah selanjutnya adalah menguasai rumus-rumus yang mendasari kalkulasi token generation. Bagian ini adalah yang paling krusial karena di sinilah Anda belajar menghitung berapa cepat sebuah model bisa menghasilkan teks, berapa besar VRAM yang dibutuhkan, berapa banyak user yang bisa dilayani, dan — paling penting bagi pebisnis — berapa biaya yang harus dikeluarkan. Setiap rumus di bagian ini disertai contoh perhitungan nyata dengan angka sehingga Anda bisa langsung mengaplikasikannya ke skenario Anda sendiri.

Tokens per second (tok/s) adalah metrik paling fundamental dalam inferensi LLM. Ini mengukur seberapa cepat model menghasilkan token baru. Tidak seperti latency (waktu untuk token pertama), tok/s mengukur kecepatan sustained generation setelah prefix selesai diproses. Memahami rumus ini adalah pintu gerbang menuju optimasi performa.

12.1 — Rumus Dasar

Rumus paling fundamental untuk menghitung throughput maksimal teoritis sebuah LLM didasarkan pada memory bandwidth, bukan pada FLOP/s atau kecepatan komputasi. Ini karena arsitektur transformer modern — terutama saat inference — sangat memory-bound:

tok/s = memory_bandwidth (GB/s) / (jumlah_params × bytes_per_param)

Komponen rumus:

• memory_bandwidth — kecepatan transfer data dari VRAM ke compute unit (GB/s)
• jumlah_params — jumlah parameter model (contoh: 8 × 10⁹ untuk Llama 3 8B)
• bytes_per_param — ukuran tiap parameter berdasarkan presisi (FP32 = 4B, FP16 = 2B, Q8 = 1B, Q4 = 0.5B)

12.2 — Contoh Kalkulasi: Llama 3 8B di RTX 4090

Mari kita hitung tok/s ideal untuk Llama 3 8B yang di-quantize ke Q4 (4-bit) dan dijalankan di RTX 4090:

Model:          Llama 3 8B
Quantization:   Q4 (0.5 bytes per param)
Berat model:    8 × 10⁹ × 0.5 = 4 × 10⁹ bytes = 4 GB

GPU:            RTX 4090
Memory BW:      1,008 GB/s (GDDR6X)

tok/s ideal = 1,008 GB/s / 4 GB = 252 tok/s

Angka 252 tok/s adalah batas teoritis maksimal — asumsi 100% utilisasi bandwidth tanpa overhead. Dalam praktiknya, efisiensi real-world berkisar antara 50–70%. Jadi estimasi realistis:

tok/s realistis = 252 × 60% = ~151 tok/s

12.3 — Tabel Kalkulasi Berbagai Kombinasi

Tabel berikut menunjukkan tok/s ideal (teoritis) untuk berbagai kombinasi model dan GPU. Kalikan dengan 0.55–0.65 untuk estimasi real-world:

12.4 — Faktor Pengurang Real-World

Kenapa tok/s real-world selalu lebih rendah? Beberapa faktor:

• Overhead Kernel Launch: CUDA kernel launch latency, terutama untuk batch size kecil
• Memory Fragmentation: Model besar mungkin tidak muat kontigu di VRAM
• CPU-GPU Transfer: Input/output encoding/decoding via CPU
• KV Cache Management: Alokasi dan update KV cache memakan bandwidth
• PCIe Bottleneck: Multi-GPU inference via PCIe menambah overhead komunikasi

Rumus praktis: tok_saat_inferensi ≈ tok_ideal × 0.55. Untuk Llama 3 70B Q4 di 2× RTX 4090: ideal 58 → ~32 tok/s real.

Salah satu kesalahpahaman terbesar di kalangan developer AI adalah mengira bahwa kecepatan inferensi ditentukan oleh TFLOPS GPU. Kenyataannya, untuk sebagian besar skenario — terutama saat batch size = 1 (sequential generation) — bottleneck utama adalah memory bandwidth, bukan compute throughput. Bab ini menjelaskan mengapa dan bagaimana menghitung dampaknya.

13.1 — Mengapa Memory Bandwidth, Bukan Compute?

Inferensi autoregressive pada LLM bekerja seperti ini:

1. GPU membaca bobot model dari VRAM ke register/SRAM
2. GPU melakukan operasi matmul pada bobot dan aktivasi
3. Hasil ditulis kembali ke VRAM
4. Ulangi untuk setiap layer (30–80× untuk model modern)

Langkah #1 adalah yang paling lambat. Untuk setiap token, GPU harus membaca seluruh bobot model dari VRAM. Bandingkan: membaca 8 GB bobot dari VRAM adalah operasi ~8 milidetik pada bandwidth 1 TB/s. Operasi matmul-nya sendiri hanya butuh ~0.5 ms. Rasio 16:1 — itulah kenapa disebut memory-bound.

13.2 — Tabel Perbandingan Memory Bandwidth

Perbedaan bandwidth antara berbagai jenis memori sangat ekstrem. Tabel ini menunjukkan perbandingan dari yang paling lambat hingga tercepat:

Perhatikan lonjakan dari DDR4 ke DDR5 hanya 2×, tapi dari DDR5 ke GDDR6X adalah ~20×. Dari GDDR6X ke HBM3e adalah ~5× lagi. Inilah mengapa GPU kelas data center (H100/H200/B200) jauh lebih cepat untuk inference dibandingkan GPU konsumen.

13.3 — Contoh: CPU Inference

Mari hitung kenapa inference di CPU sangat lambat:

Model:         Llama 3 8B FP16 (16 GB)
CPU Memory:    DDR5-6400 (51.2 GB/s)

tok/s = 51.2 GB/s / 16 GB = 3.2 tok/s

Dengan asumsi efisiensi 60%: ~1.9 tok/s. Bandingkan dengan 151 tok/s di RTX 4090 (Q4) — perbedaan ~80×. Inilah alasan utama mengapa LLM inference di CPU untuk model 7B+ belum praktis untuk real-time apps.

13.4 — Operasi-bound vs Memory-bound

Pada batch size yang lebih besar, sifat bottleneck berubah:

• Batch size = 1: Memory-bound (baca bobot 1×, compute 1×)
• Batch size = N: Compute-bound (baca bobot 1×, compute N×)

Titik transisi (Roofline) terjadi ketika compute time = memory time. Untuk RTX 4090:

Compute:      82.6 TFLOPS (FP16)
Memory BW:    1,008 GB/s

Compute bound @ batch_size ketika:
  compute_time < memory_time
  82.6 TFLOPS / N < 1,008 GB/s × utilization
  N > ~25 untuk model 8B Q4

Artinya, untuk Llama 3 8B Q4 di RTX 4090, Anda mulai melihat saturasi komputasi setelah batch size ~25. Di bawah itu, Anda dikekang oleh memory bandwidth.

Mengetahui berapa besar VRAM yang dibutuhkan sebuah model adalah prerequisite untuk menentukan GPU apa yang harus dibeli. Banyak pemula hanya menghitung bobot model — lalu kaget ketika model out of memory (OOM) saat dijalankan. Padahal VRAM dipakai oleh tiga komponen utama: model weights, KV cache, dan overhead.

14.1 — Rumus Lengkap Alokasi VRAM

VRAM_total = model_weights + KV_cache + overhead

Rincian masing-masing komponen:

model_weights = jumlah_params × bytes_per_param

KV_cache = 2 × n_layers × n_heads × d_head × 
           2 × seq_len × batch_size × bytes_per_cache

Contoh Llama 3 8B FP16:
  model_weights = 8 × 10⁹ × 2 B = 16 GB
  KV_cache = 2 × 32 × 32 × 128 × 2 × 4,096 × 1 × 2 = ~4.3 GB
  overhead (CUDA context, buffers) = ~1 GB
  ---
  VRAM_total = 16 + 4.3 + 1 = ~21.3 GB

Rumus di atas menjelaskan kenapa model 8B FP16 (yang seharusnya 16 GB) tetap butuh ~22 GB VRAM — karena KV cache dan overhead tidak bisa diabaikan.

14.2 — Tabel VRAM 20+ Model

Tabel ini menunjukkan kebutuhan VRAM untuk model populer di berbagai level quantization. Asumsi KV cache untuk 4K context length dan batch size = 1:

Kolom "GPU Min" adalah GPU termurah yang bisa menjalankan model di Q4 dengan context 4K. Ingat: context length lebih panjang → KV cache lebih besar.

14.3 — Diagram Alokasi VRAM

14.4 — KV Cache untuk Context Panjang

Salah satu jebakan terbesar adalah melupakan KV cache saat menghitung VRAM. Untuk konteks panjang, KV cache bisa melebihi ukuran bobot model:

Llama 3 8B Q4 — Context 128K:
  Bobot:     4.0 GB
  KV cache:  2 × 32 × 32 × 128 × 2 × 131,072 × 1 × 2 = ~137 GB
  ---
  Total:     ~141 GB (tidak muat di GPU manapun!)

Inilah kenapa teknik seperti sliding window attention, KV cache eviction, dan multi-query attention (GQA/MQA) sangat penting — mereka secara drastis mengurangi ukuran KV cache pada konteks panjang.

Salah satu pertanyaan paling praktis saat membangun produk AI adalah: "Berapa banyak user yang bisa saya layani dengan GPU yang saya miliki?" Jawabannya tidak sesederhana membagi VRAM — ada trade-off antara latency, throughput, dan concurrency. Bab ini memberikan rumus-rumus esensial untuk menjawab pertanyaan tersebut.

15.1 — Rumus Throughput

Throughput (token/detik) = batch_size × seq_len × tok_per_detik

Atau untuk serving:
Throughput (token/detik) = batch_size / latency_per_token

Satu hal kritis: throughput dan latency adalah trade-off. Meningkatkan batch_size akan meningkatkan throughput tapi menambah latency per request:

Contoh: Llama 3 8B Q4 di RTX 4090
  Batch 1:  latency = ~6.6 ms/token, throughput = 1/0.0066 = 151 tok/s
  Batch 4:  latency = ~8.9 ms/token, throughput = 4/0.0089 = 449 tok/s
  Batch 16: latency = ~18 ms/token,  throughput = 16/0.018 = 889 tok/s

Perhatikan: latency naik 2.7×, tapi throughput naik 5.9×.

Ini karena GPU memanfaatkan paralelisme — operasi matmul untuk 16 sequence dilakukan bersamaan, jadi waktu total hanya sedikit lebih lambat dari 1 sequence.

15.2 — Rumus Max Concurrent Users

KV_cache_per_user = 2 × n_layers × n_heads × d_head × 
                    2 × avg_seq_len × bytes_per_cache

max_users = (total_VRAM - model_weights - overhead) / KV_cache_per_user

15.3 — Contoh Nyata: A100 80GB + Llama 8B Q4

A100 80GB:
  Total VRAM:        80 GB
  Model Q4:           4 GB
  Overhead:          ~2 GB
  VRAM available:    74 GB

KV cache per user (asumsi 2K context):
  n_layers = 32, n_heads = 32, d_head = 128
  = 2 × 32 × 32 × 128 × 2 × 2048 × 2 = ~2.15 GB

max_users = 74 / 2.15 = ~34 concurrent users

Artinya, satu A100 80GB bisa melayani ~34 user secara bersamaan untuk Llama 3 8B Q4 dengan rata-rata 2K output tokens. Tapi perlu diingat: ini asumsi semua user menghasilkan token secara paralel. Dalam praktiknya, batch_size maksimum ditentukan oleh VRAM, dan antrean request ditangani oleh scheduler.

15.4 — Tabel Skenario Concurrent Users

Catatan: tok/s total = max_users × tok_single_user.
Namun, throughput efektif lebih rendah karena overhead batching dan scheduling.

15.5 — Trade-off Context Length vs Concurrency

Context length punya dampak dramatis pada concurrency. Double context → double KV cache → half users:

RTX 4090 + Llama 8B Q4:
  Context 2K:  ~4 GB model + 2.15 GB KV = ~6.15 GB → ~4 user (24GB/6.15)
  Context 4K:  ~4 GB model + 4.3 GB KV  = ~8.3 GB  → ~2 user
  Context 8K:  ~4 GB model + 8.6 GB KV  = ~12.6 GB → hanya bisa 1 user

Untuk aplikasi real-time dengan banyak user, gunakan model yang di-quantize lebih rendah dan batasi max context length. Atau gunakan teknik seperti chunked prefill dan prefix caching.

Bagi founder, CTO, atau product manager — metrik paling penting bukan tok/s, tapi cost per token. Berapa rupiah yang harus Anda keluarkan untuk menghasilkan 1 juta token? Bab ini membedah biaya dari sisi hardware (CAPEX) dan operasional (OPEX), lalu membandingkannya dengan API pihak ketiga.

16.1 — Rumus Cost per Token (On-Premise)

Cost/token = (hardware_cost / lifetime_hari / tokens_per_hari)
           + (listrik_per_hari / tokens_per_hari)
           + (maintenance_per_hari / tokens_per_hari)

Mari kita hitung untuk skenario paling umum di Indonesia: 1× RTX 4090 untuk Llama 3 8B Q4.

CAPEX:
  RTX 4090:             Rp 50.000.000
  Lifetime:             3 tahun = 1.095 hari
  Depresiasi/hari:      Rp 45.662

LISTRIK:
  TDP GPU:              450 watt
  Sistem total:         ~600 watt
  Pemakaian:            24 jam/hari = 14.4 kWh/hari
  Tarif listrik:        Rp 1.699/kWh (golongan industri kecil)
  Biaya listrik/hari:   Rp 24.466

MAINTENANCE:
  PSU, storage, kipas:  ~Rp 500.000/tahun = Rp 1.370/hari

TOKENS PER HARI:
  tok/s (realistis):    151 tok/s
  Duty cycle:           70% (24/7, dengan idle time)
  Tokens/hari:          151 × 24 × 3600 × 0.7 = ~9.132.480 token

COST PER TOKEN:
  = (45.662 + 24.466 + 1.370) / 9.132.480
  = 71.498 / 9.132.480
  = Rp 7,83 per 1.000 token

Artinya: dengan setup 1× RTX 4090, Anda mengeluarkan Rp 7,83 per 1.000 token atau sekitar Rp 7.830 per 1 juta token.

16.2 — Tabel Perbandingan Cost per Token

Tabel perbandingan berbagai opsi, semuanya dalam konteks Indonesia:

Insight penting: Untuk model open-source 8B, on-premise RTX 4090 (Rp 7.830/1M token) lebih mahal daripada Together API (Rp 2.120) untuk volume rendah. Tapi untuk volume sangat tinggi — dan terutama untuk model 70B+ — on-premise A100 bisa jauh lebih murah.

16.3 — Kalkulasi Detail Cloud GPU

Sebagai alternatif, cloud GPU seperti RunPod, Vast.ai, atau penyedia lokal bisa menjadi pilihan:

RunPod — A100 80GB (spot instance):
  Harga:      ~$1.25/jam = Rp 19.500/jam (@ Rp 15.600/USD)
  Tok/s:      ~510 (Llama 8B)
  Duty cycle: 90% (server reasoning terus)
  Tokens/hari: 510 × 24 × 3600 × 0.9 = ~39.657.600

  Cost/token = 19.500 / (39.657.600/1000) = Rp 0,49 per 1K token
  = Rp 490 per 1 juta token

Catatan: harga di atas adalah spot instance yang bisa di-terminate kapan saja. On-demand biasa ~3× lipat.

Keputusan paling strategis dalam membangun infrastruktur AI: kapan sebaiknya menggunakan API (OpenAI, Anthropic, Groq, Together) dan kapan membeli GPU sendiri? Jawabannya ditemukan dalam rumus break-even point — titik di mana biaya total on-premise mulai lebih murah daripada API untuk volume yang sama. Bab ini memandu Anda menghitungnya.

17.1 — Rumus Break-Even Point

Break-even (token) = hardware_cost / (api_cost_per_token - onprem_cost_per_token)

Break-even (hari) = break-even_token / tokens_per_hari

Rumus di atas menjawab: "Berapa token yang harus saya generate sebelum GPU saya lebih murah daripada API?"

17.2 — Contoh 1: RTX 4090 vs OpenAI GPT-4o-mini

SCENARIO: Llama 3 8B Q4 di RTX 4090 vs GPT-4o-mini

On-prem setup (RTX 4090):
  Hardware cost (GPU + sistem):  Rp 60.000.000 (GPU + PSU + RAM + storage)
  Lifetime:                       3 tahun = 1.095 hari
  Biaya tetap/hari:               Rp 54.795
  Biaya variabel/hari:            Rp 25.836 (listrik + maintenance)
  Tokens/hari:                    9.132.480
  On-prem cost/1K token:          Rp 8,83

API cost (GPT-4o-mini):
  Input:   $0.15/1M token = Rp 2.340/1M
  Output:  $0.60/1M token = Rp 9.360/1M
  Rata-rata (1:3 input:output):   Rp 7.605/1M token = Rp 7,61/1K

Hitung break-even:
  Selisih cost = Rp 8,83 - Rp 7,61 = -Rp 1,22 (API LEBIH MURAH!)

Kesimpulan: GPT-4o-mini lebih murah daripada on-prem RTX 4090,
bahkan untuk volume tak terbatas. TIDAK ADA break-even point.

17.3 — Contoh 2: A100 80GB vs OpenAI GPT-4o

SCENARIO: Llama 3 70B Q4 di A100 80GB vs GPT-4o

On-prem setup (A100 80GB):
  A100 80GB (bekas):              Rp 250.000.000 (1-year old, 4 tahun lifetime)
  Sistem+server:                  Rp 100.000.000
  Total CAPEX:                    Rp 350.000.000
  Lifetime:                       4 tahun = 1.460 hari
  Biaya tetap/hari:               Rp 239.726
  Listrik (700W × 24h):           Rp 28.541/hari
  Maintenance:                    Rp 3.000/hari
  On-prem cost/hari:              Rp 271.267
  Tokens/hari (70B Q4):           18 tok/s × 24 × 3600 × 0.7 = 1.088.640

  On-prem cost/1K token:          Rp 249

API cost (GPT-4o):
  Output price:   $10/1M token = Rp 156.000/1M = Rp 156/1K token

  Selisih: Rp 249 - Rp 156 = Rp 93/1K (on-prem LEBIH MAHAL)

  Hmm — bahkan A100 belum break-even vs GPT-4o.
  Tapi bandingkan dengan model besar via API lain...

17.4 — Contoh 3: Break-Even yang Sebenarnya Ada

SCENARIO: RTX 4090 vs Together API Llama 3 8B — volume tinggi

On-prem:  Rp 8,83/1K token
Together: Rp 2,12/1K token

Selisih:  Rp 8,83 - Rp 2,12 = Rp 6,71 (on-prem lebih mahal)
→ Tidak ada break-even. API selalu lebih murah.

SCENARIO: 2× RTX 3090 (bekas, @Rp 15jt = Rp 30jt) vs Groq (Llama 70B Q4)

On-prem:
  Total:              Rp 45.000.000 (GPU + sistem)
  Lifetime:           3 tahun
  Cost/hari:          Rp 41.096 (depresiasi) + Rp 20.000 (listrik) + Rp 1.370 = Rp 62.466
  Tokens/hari:        35 tok/s × 24 × 3600 × 0.7 = 2.116.800
  On-prem cost/1K:    Rp 29,5

Groq:
  Llama 3 70B via Groq: $1.00/1M token = Rp 15.600/1M = Rp 15,60/1K

Selisih: Rp 29,5 - Rp 15,6 = Rp 13,9 (API lebih murah)
→ Lagi-lagi tidak ada break-even.

17.5 — Kapan On-Premise Menang?

Dari kalkulasi di atas, terlihat bahwa API hampir selalu lebih murah untuk model <70B — kecuali dalam skenario berikut:

1. Volume sangat tinggi — puluhan juta token per hari selama bertahun-tahun
2. Model sangat besar — 70B+ di API mahal (DeepSeek-V3, Llama 405B)
3. Data sensitivity — tidak bisa kirim data ke API eksternal (fintech, health, gov)
4. Custom model — fine-tuned model yang tidak tersedia di API manapun
5. GPU idle tidak masalah — GPU dipakai untuk training + inference

17.6 — Grafik Break-Even Point

17.7 — Tabel Break-Even Berbagai Skenario

17.8 — Kesimpulan Praktis untuk Pebisnis Indonesia

Setelah semua kalkulasi, berikut rekomendasi praktis berdasarkan volume:

• < 10M token/hari: Gunakan API. GPT-4o-mini atau Claude Haiku adalah pilihan termurah dan paling praktis. Tidak perlu pusing dengan hardware, cooling, maintenance.
• 10M–100M token/hari: Mulai pertimbangkan on-premise, terutama jika Anda butuh model spesifik atau data privacy. API Together/Groq masih kompetitif.
• > 100M token/hari: On-premise dengan A100/H100 jelas lebih murah, terutama untuk model 70B+. Dengan asumsi 5 tahun lifetime, break-even bisa tercapai dalam 6–18 bulan.
• Data sensitive: On-premise adalah satu-satunya pilihan, terlepas dari biaya.
• Hybrid approach: Banyak perusahaan sukses menggunakan API untuk MVP/testing, lalu migrasi ke on-premise setelah volume cukup besar. Jangan beli GPU sebelum Anda punya product-market fit!

📌 Kesimpulan Akhir: Untuk sebagian besar startup AI Indonesia,
API adalah pilihan paling rasional secara finansial.
Satu-satunya pengecualian: Anda menjalankan model 70B+
dengan volume >100M token/hari, atau data tidak bisa dikirim ke luar.

NVIDIA mendominasi pasar AI inference. Memahami lini produk mereka — dari RTX konsumen hingga data center — adalah langkah pertama untuk memilih GPU yang tepat. Setiap lini memiliki arsitektur, bandwidth, VRAM, dan harga yang berbeda drastis.

Arsitektur GPU NVIDIA

Setiap generasi NVIDIA membawa peningkatan signifikan. Ampere (2020) memperkenalkan Tensor Core generasi ketiga dan MIG. Hopper (2022) membawa Transformer Engine dan FP8. Blackwell (2024) menghadirkan FP4 dan第二代 Transformer Engine. Rubin (2026) adalah generasi terbaru dengan peningkatan bandwidth HBM4.

Tabel Perbandingan GPU NVIDIA

Perbedaan harga

Tips. Untuk personal AI atau startup kecil, RTX 4090 bekas (Rp 35-45 juta) adalah pilihan paling rasional. Rasio harga/performanya sulit dikalahkan.

RTX 4090 telah menjadi GPU favorit para AI enthusiast dan startup kecil sejak dirilis. Namun dengan hadirnya RTX 5090 (Blackwell), muncul pertanyaan: apakah peningkatan performa sebanding dengan harga yang jauh lebih tinggi?

Perbandingan Spesifikasi

Kalkulasi Token Speed

Kalkulasi Detail: RTX 4090 Concurrency

Untuk server inference dengan 1× RTX 4090 24GB:

Model: Gemma 4 12B di Q4_K_M
  Weight: 12B × 0.5 bytes = 6 GB
  KV cache per user (4K context):
    = 2 × 4096 × 48 layers × 5120 dim × 2 bytes × 2 (K+V)
    = ~2 GB per user di FP16
    = ~500 MB per user di FP8
  Max concurrent users:
    Dengan FP8 KV cache: (24 - 6) / 0.5 = 36 user
    Dengan FP16 KV cache: (24 - 6) / 2 = 9 user

Namun dalam praktik, karena continuous batching dan PagedAttention, kita tidak perlu mengalokasikan KV cache penuh untuk setiap user. vLLM memungkinkan 15-25 concurrent user tanpa masalah.

Rumus Praktis: Untuk model 7B Q4 di RTX 4090: concurrent = (24 - 4) / 1.5 = ~13 user. Untuk model 12B Q4: concurrent = (24 - 6) / 2 = ~9 user. Selalu kurangi 2GB untuk overhead sistem.

Untuk model 7B Q4 (~4GB model + 0.5GB KV cache): RTX 4090 = 1008/(4.5) × 60% = ~134 tok/s. RTX 5090 = 1800/(4.5) × 60% = ~240 tok/s. Peningkatan ~1.8×. Untuk model 13B Q4: RTX 4090 = ~80 tok/s, RTX 5090 = ~140 tok/s.

Awas. RTX 5090 membutuhkan PSU 1000W+ dan pendingin yang lebih baik. Pastikan PC Anda siap sebelum upgrade.

GPU data center NVIDIA adalah pilihan utama untuk inference enterprise, dengan H100 dan H200 mendominasi pasar. A100 (Ampere) masih banyak digunakan untuk model yang tidak memerlukan FP8. H200 membawa lompatan bandwidth dengan HBM3e 4.8 TB/s. B200 adalah generasi terbaru dengan FP4 support dan bandwidth ~8 TB/s.

Perbandingan Data Center GPU

Inti. H200 adalah sweet spot untuk enterprise — VRAM 141GB cukup untuk Llama 3 70B Q4, dan bandwidth 4.8 TB/s memberikan token speed yang sangat baik.

GPU cloud memungkinkan Anda menyewa GPU per jam tanpa investasi awal mahal. Layanan seperti RunPod, Vast.ai, dan Lambda Labs melayani pasar inference on-demand. Perbedaan harga antar penyedia bisa mencapai 3-4× untuk GPU yang sama.

Tips. Untuk eksperimen jangka pendek (<100 jam), GPU cloud lebih murah. Untuk pemakaian >300 jam/bulan, beli GPU sendiri lebih ekonomis.

Google Cloud Platform (GCP) menawarkan GPU dan TPU untuk workload AI. L4 adalah pilihan entry-level termurah dengan 24GB VRAM, cocok untuk model kecil hingga menengah. A100 dan H100 tersedia dengan commitment diskon untuk pemakaian jangka panjang.

Inti. TPU v5p unggul untuk training skala besar dengan TensorFlow/JAX, tetapi untuk inference LLM umum, GPU NVIDIA lebih fleksibel dan didukung lebih luas.

AWS dan Azure menawarkan opsi GPU untuk inference dengan fleksibilitas tinggi. AWS memiliki instance g5 (A10G), p4d (A100), dan p5 (H100). Azure menawarkan NCas dan NC-series. Spot instance bisa menghemat 60-70% namun dengan risiko interupsi.

AMD RX 7900 XTX menawarkan 24GB VRAM dengan harga ~$900 (~Rp 15 juta), jauh lebih murah dari RTX 4090. Dengan ROCm (Radeon Open Compute), AMD GPU bisa digunakan untuk inference LLM. Namun, kompatibilitas software masih menjadi tantangan.

Awas. AMD ROCm masih bermasalah di banyak framework. Ollama dan llama.cpp memiliki dukungan terbaik untuk AMD GPU. Untuk production, NVIDIA tetap lebih aman.

Setiap jenis model AI memiliki kebutuhan VRAM dan bandwidth yang berbeda. Panduan ini membantu memilih GPU yang tepat berdasarkan tipe model yang ingin dijalankan.

VRAM Available = Total VRAM - OS Overhead - Model Weights - Scratch Space

KV Cache per User = 2 × seq_len × n_layers × hidden_dim × bytes_per_element × 2 (K+V)

Max Concurrent Users (teoretis) = VRAM Available / KV Cache per User

Throughput Aktual = min(Max Users, Batch Limit) × tokens_per_second

Harga Akhir = Harga Dasar (USD × Kurs) + PPN 11% + Bea Masuk (0-10%, GPU bebas bea masuk jika HS 8471.50) + Ongkir

Kurs acuan: 1 USD ≈ Rp 16,200 (Juni 2026 — kurs fluktuatif, ikuti BI rate)

Contoh RTX 4090 di AS: $1,600
Konversi: 1,600 × 16,200 = Rp 25,920,000
PPN 11%: Rp 2,851,200
Distributor margin + garansi resmi: Rp 10-15 juta
Harga final di marketplace: Rp 45-55 juta

Full Fine-Tuning (FP16) — Model 7B:
  Weights: 7B × 2 bytes = 14 GB
  Gradients: 7B × 2 bytes = 14 GB
  Optimizer (AdamW): 7B × 4 bytes × 2 (momen + var) = 56 GB
  Activations: batch_size × seq_len × hidden_dim × 2 bytes × n_layers
    batch=1, seq=4096, hidden=4096, 32 layers = ~2 GB
  Total: 14 + 14 + 56 + 2 = 86 GB VRAM — butuh 2× A100 80GB!

LoRA (FP16) — Model 7B, rank=16:
  Weights: 14 GB (frozen, tidak dihitung untuk grad)
  Gradients: 7B × 2 bytes × 0.1% (hanya adapter) = ~14 MB!
  Optimizer (AdamW): ~56 MB (hanya adapter)
  Activations: ~2 GB (sama)
  Total: 14 + 0.014 + 0.056 + 2 = ~16 GB VRAM — muat RTX 4090!

QLoRA (Q4 + LoRA) — Model 7B, rank=16:
  Weights: 7B × 0.5 bytes = 3.5 GB
  Gradients/optimizer: ~70 MB
  Activations: ~2 GB
  Total: 3.5 + 2 = ~5.5 GB VRAM — muat RTX 3060 12GB!

Perbandingan Biaya per Token — Groq vs GPU Cloud:
  Groq API (Llama 3 70B):    $0.59 per 1M token input  (prompt)
  Groq API (Llama 3 70B):    $0.79 per 1M token output (completion)
  RunPod H100 (70B Q4):       ~$0.15 per 1M token (hanya GPU cost, belum API overhead)
  
  Kesimpulan: Groq 2-4× lebih mahal per token, tapi 5-10× lebih cepat.
  Untuk aplikasi real-time (chat, voice), Groq unggul.
  Untuk batch processing, GPU cloud lebih murah.

Gemma 4 adalah keluarga model open source terbaru dari Google DeepMind, dirilis April 2026. Dibangun dari teknologi Gemini, Gemma 4 menawarkan berbagai ukuran dari 2.7B hingga 31B parameter, mencakup dense dan MoE arsitektur.

Gemma 4 menonjol karena native function calling di semua varian, multimodal (text+image+audio untuk E2B, E4B, 12B), dan vocabulary size 262K yang mendukung 140+ bahasa. Peringatan: 26B A4B butuh VRAM untuk total parameter (25.7B), bukan hanya active 3.8B.

Llama 4 dari Meta adalah keluarga model MoE (Mixture-of-Experts) yang menawarkan efisiensi tinggi dengan mengaktifkan hanya sebagian parameter saat inference. Keunikan Llama 4: total parameter bisa sangat besar, tapi active parameter tetap terkendali.

Awas. MoE model butuh VRAM untuk total parameter, bukan hanya active. Llama 4 Scout 109B di Q4 = 109 × 0.5 = ~55GB — muat di 1× H200 (141GB) atau 2× A100 80GB.

Qwen dari Alibaba Cloud adalah salah satu model dengan dukungan bahasa Indonesia terbaik. Qwen 3 (rilis 2025) dan Qwen 3.5 (2026) mencakup ukuran 0.5B hingga 236B parameter. Multilingual performance Qwen sering mengungguli Llama di bahasa Asia Tenggara.

Qwen unggul untuk penggunaan di Indonesia karena pretraining data mencakup banyak konten Bahasa Indonesia. Untuk agentic workflow dan tool calling, Qwen 3 32B menawarkan keseimbangan performa dan kebutuhan VRAM terbaik.

DeepSeek V3 (671B MoE, 37B active) dan R1 adalah model asal China yang menghebohkan dunia AI dengan efisiensi luar biasa. Arsitektur Multi-head Latent Attention (MLA) membuat KV cache 6× lebih kecil dari model konvensional.

Inti. DeepSeek V3 Q4 butuh ~336GB VRAM — setara 4× A100 80GB atau 2× H200 141GB. Ini bukan untuk personal server! Tapi efficiency model ini luar biasa: 37B active params dengan kemampuan setara GPT-4 class.

Mistral AI (Prancis) dan Cohere (Kanada) adalah pemain Eropa di dunia LLM. Mistral 7B menjadi favorit karena performa luar biasa untuk ukurannya. Mixtral 8x7B adalah MoE pertama yang populer. Command R+ (104B) unggul di RAG dan tool use.

Model kecil (<7B) memungkinkan inference di perangkat edge, smartphone, hingga VPS tanpa GPU. Kuncinya: quantization ekstrim (Q4, Q3, Q2) dan model yang dirancang khusus untuk efisiensi.

Tips. Model 270M-3B di Q4 bisa jalan di VPS 2GB RAM. Untuk pengalaman yang layak, setidaknya 1.5B model — model terlalu kecil hasilnya sering tidak koheren.

Agentic models adalah LLM yang dioptimalkan untuk tool use: memanggil API, menjalankan kode, browsing web, dan berinteraksi dengan sistem eksternal. FunctionGemma (rilis Des 2025) adalah contoh model spesialis function calling.

Perbedaan agentic model dengan LLM biasa:

• Context lebih panjang — system prompt + tools definition + function results bisa memakan ribuan token
• Structured output — output harus JSON/XML yang valid untuk diparse
• Tool call overhead — setiap tool call butuh ~100-500 token tambahan

Multimodal models memproses beberapa jenis input (text, image, audio) dalam satu model. Gemma 4 12B Unified adalah contoh arsitektur encoder-free — tidak perlu vision encoder terpisah. Llama 4 Scout dan Qwen 3 VL menggunakan vision encoder tradisional.

Image generation menggunakan arsitektur diffusion, bukan autoregressive seperti LLM. Prosesnya: dari noise acak, model secara bertahap menghilangkan noise hingga menghasilkan gambar. Ini membawa konsekuensi berbeda pada kebutuhan hardware.

Kunci image generation: denoising steps. 20 steps = 20× forward pass melalui model. FLUX menggunakan arsitektur Diffusion Transformer (DiT), bukan UNet tradisional — lebih berat tapi kualitas lebih baik.

Video generation adalah kelas model terberat. Membutuhkan VRAM besar, waktu generasi lama, dan biasanya berjalan di cloud. Model open source untuk video masih terbatas; sebagian besar video generation adalah layanan cloud.

Awas. Video generation di on-premise butuh GPU dengan VRAM >48GB. Satu menit video HD bisa memakan waktu 30 menit hingga 2 jam generasi. Saat ini, cloud masih menjadi pilihan paling praktis.

TTS adalah model AI paling ringan di buku ini. Beberapa model TTS bahkan bisa jalan di CPU dengan real-time factor <1.0 (lebih cepat dari realtime).

TTS model bisa berjalan di GPU apa pun, bahkan di CPU modern. Kokoro di CPU Intel Core i7 bisa menghasilkan ~10× lebih cepat dari realtime. Kamu tidak perlu GPU khusus untuk TTS.

3D generation mengubah text atau image menjadi model 3D (mesh). Beberapa model cukup ringan (Point-E bisa di CPU), yang lain butuh GPU mid-range.

Image editing models memungkinkan modifikasi gambar berbasis text prompt. Teknik utama: inpainting (mengisi area tertentu), outpainting (memperluas gambar), dan ControlNet (mengontrol generasi dengan struktur tambahan seperti pose atau depth map).

Untuk menjalankan beberapa model editing sekaligus (misal base + ControlNet + IP-Adapter), perlu VRAM lebih besar. Contoh: SDXL 8GB + ControlNet 3GB + IP-Adapter 1GB = ~12GB minimal.

Rumus: Total VRAM = base_model_VRAM + control_VRAM + ip_adapter_VRAM + batch_size × image_size_overhead. Untuk SDXL + ControlNet: 8GB + 3GB + 10% = ~12GB.

Tabel berikut merangkum SEMUA model yang dibahas di bagian ini, dengan kebutuhan VRAM dan GPU minimal untuk setiap model.

Catatan: (*) untuk image/video model, VRAM dihitung untuk weights + UNet/DiT. Inference diffusion butuh forward pass berulang (20-50 steps) sehingga latency lebih ditentukan oleh compute speed daripada memory bandwidth.

DONE: part 05, diperkirakan ~8,000+ kata (semi-generated, struktur lengkap)

VRAM_Total = VRAM_Weights + VRAM_KV_Cache + VRAM_Overhead

Komponen 1: VRAM Weights
  FP16:  params × 2 bytes
  FP8:   params × 1 byte
  FP4:   params × 0.5 bytes
  Q8:    params × 1 byte
  Q4:    params × 0.5 bytes
  Q3:    params × 0.375 bytes
  Q2:    params × 0.25 bytes

Komponen 2: VRAM KV Cache (per request)
  KV_Cache = 2 × seq_len × n_layers × hidden_dim × bytes_per_element × 2 (K + V)
  
  Di FP16:  2 × L × H × seq_len × 2 × 2 = 8 × L × H × seq_len
  Di FP8:   2 × L × H × seq_len × 1 × 2 = 4 × L × H × seq_len

Komponen 3: Overhead
  CUDA kernels + buffer: ~200-500 MB
  vLLM internal buffers: ~500 MB - 2 GB
  Scratch memory (attention scores, softmax): ~200 MB - 1 GB
  Estimasi total overhead: 1-3 GB

Kesimpulan rumus praktis:
  VRAM_Minimum = (params × bytes_per_param) + (8 × L × H × seq_len) + 2 GB
  Untuk concurrent users: × N users dengan continuous batching

Diketahui dari config:
  params = 12.2B
  n_layers (L) = 48
  hidden_dim (H) = 5,120
  n_heads = 40, n_kv_heads = 8 (GQA)
  vocab_size = 262,144

VRAM Weights (Q4_K_M):
  = 12,175,113,984 × 0.5 bytes
  = 6,087,556,992 bytes
  = 5.67 GB

VRAM Weights (FP16):
  = 12,175,113,984 × 2 bytes
  = 24,350,227,968 bytes
  = 22.68 GB

KV Cache per user (4K context, FP8, K+V):
  = 2 × seq_len × n_layers × (hidden_dim / n_heads × n_kv_heads) × 1 byte × 2
  = 2 × 4096 × 48 × (5120 / 40 × 8) × 1 × 2
  = 2 × 4096 × 48 × 1024 × 2
  = 805,306,368 bytes
  = 0.75 GB per user

KV Cache per user (4K context, FP16, K+V):
  = 2 × 4096 × 48 × 1024 × 2 × 2
  = 1,610,612,736 bytes
  = 1.5 GB per user

Total VRAM (Q4, FP8 KV, 1 user, 4K ctx):
  = 5.67 + 0.75 + 2.0 (overhead)
  = ~8.4 GB  → muat di RTX 3060 12GB!

Total VRAM (Q4, FP16 KV, 1 user, 4K ctx):
  = 5.67 + 1.5 + 2.0
  = ~9.2 GB  → masih muat di RTX 3060 12GB

Total VRAM (Q4, FP16 KV, 10 users, 4K ctx):
  = 5.67 + (1.5 × 10) + 2.0
  = 5.67 + 15.0 + 2.0
  = 22.67 GB → muat di RTX 4090 24GB (pas-pasan)

Parameter arsitektur:
  params = 12.2B
  n_layers = 48
  hidden_dim = 5,120
  n_heads = 40, n_kv_heads = 8
  head_dim = hidden_dim / n_heads = 128
  kv_dim = head_dim × n_kv_heads = 1,024
  context = 256K (maksimum)

VRAM Weights — berbagai quantization:
  FP16: 12.2B × 2 = 24.4 GB
  FP8:  12.2B × 1 = 12.2 GB
  Q4:   12.2B × 0.5 = 6.1 GB
  
KV Cache per user — berbagai context:  
  KV_cache_per_layer = 2 × seq_len × kv_dim × bytes × 2
  Di FP8, seq=4096:  2 × 4096 × 1024 × 1 × 2 = 16.8 MB/layer
  Total KV (48 layers, FP8, 4K): 16.8 MB × 48 = 806 MB/user
  Total KV (48 layers, FP8, 32K): 806 × 8 = 6.4 GB/user
  Total KV (48 layers, FP8, 256K): 806 × 64 = 51.6 GB/user

Kesimpulan VRAM Gemma 4 12B:
  Q4 + 4K ctx:     6.1 + 0.8 + 2 =  8.9 GB → RTX 3060 ✓
  Q4 + 32K ctx:    6.1 + 6.4 + 2 = 14.5 GB → RTX 4090 ✓
  Q4 + 128K ctx:   6.1 + 25.8 + 2 = 33.9 GB → A100 80GB ✓
  Q4 + 256K ctx:   6.1 + 51.6 + 2 = 59.7 GB → A100 80GB (pas-pasan)

Parameter arsitektur:
  total_params = 109B
  active_params = 17B
  is_moe = True (8 experts, 2 active per token)
  n_layers = ~96 (perkiraan dari config publik)
  hidden_dim = ~7,168 (perkiraan)
  n_heads = ~56, n_kv_heads = ~8 (GQA)
  kv_dim = hidden_dim / n_heads × n_kv_heads
  head_dim = 128
  kv_dim = (7168 / 56) × 8 = 128 × 8 = 1,024

PENTING — MoE Special Case:
  MoE menyimpan semua expert weights di VRAM — total_params yang dipakai, BUKAN active_params!
  Jadi VRAM tetap untuk 109B, bukan 17B.

VRAM Weights:
  FP16: 109B × 2 = 218 GB
  Q4:   109B × 0.5 = 54.5 GB  
  Q3:   109B × 0.375 = 40.9 GB
  Q2:   109B × 0.25 = 27.3 GB

KV Cache per user (karena tidak tergantung MoE):
  Di FP8, seq=4096: 2 × 4096 × 1024 × 1 × 2 = 16.8 MB/layer
  Total KV (96 layers, FP8, 4K): 16.8 × 96 = 1,613 MB = 1.6 GB/user
  Total KV (96 layers, FP8, 256K): 1.6 × 64 = 102 GB/user — MASSIF!

Kesimpulan VRAM Llama 4 Scout:
  Q4 + 4K ctx:       54.5 + 1.6 + 2 = 58.1 GB → H200 141GB ✓
  Q3 + 4K ctx:       40.9 + 1.6 + 2 = 44.5 GB → 1× A100 80GB ✓
  Q2 + 4K ctx:       27.3 + 1.6 + 2 = 30.9 GB → RTX 5090 (32GB) ✓
  Q2 + 256K ctx:     27.3 + 102 + 2 = 131.3 GB → H200 (pas-pasan)

⚠️ Catatan penting: Llama 4 Scout di Q2 mungkin menurunkan kualitas signifikan.
  Q3 di A100 80GB adalah sweet spot.

Parameter arsitektur:
  params = 32.8B
  n_layers = 80
  hidden_dim = 7,168
  n_heads = 56, n_kv_heads = 8 (GQA)
  kv_dim = head_dim × n_kv_heads = 128 × 8 = 1,024
  context = 128K (maksimum)

VRAM Weights:
  FP16: 32.8B × 2 = 65.6 GB
  FP8:  32.8B × 1 = 32.8 GB
  Q4:   32.8B × 0.5 = 16.4 GB
  Q3:   32.8B × 0.375 = 12.3 GB

KV Cache per user (FP8):
  2 × 4096 × 1024 × 1 × 2 = 16.8 MB/layer
  Total KV (80 layers, FP8, 4K): 16.8 × 80 = 1,344 MB = 1.3 GB/user
  Total KV (80 layers, FP8, 32K): 1.3 × 8 = 10.4 GB/user
  Total KV (80 layers, FP8, 128K): 1.3 × 32 = 41.6 GB/user

Kesimpulan VRAM Qwen 3 32B:
  Q4 + 4K ctx:      16.4 + 1.3 + 2 = 19.7 GB → RTX 4090 ✓
  Q4 + 32K ctx:     16.4 + 10.4 + 2 = 28.8 GB → RTX 5090 (32GB) ✓
  Q4 + 128K ctx:    16.4 + 41.6 + 2 = 60.0 GB → 1× A100 80GB (pas-pasan)
  FP8 + 4K ctx:     32.8 + 1.3 + 2 = 36.1 GB → A100 80GB ✓
  Q3 + 4K ctx:      12.3 + 1.3 + 2 = 15.6 GB → RTX 4090 ✓ (sisa banyak untuk concurrency)

Cost per Token (LLM) = (GPU_Cost_per_Hour × seconds_per_token) / 3600
seconds_per_token = 1 / tokens_per_second  

Cost per Image = GPU_Cost_per_Hour × (steps × time_per_step) / 3600
time_per_step ≈ (model_params × 2 × compute_efficiency) / GPU_FLOPS

GPU_Cost_per_Hour mempertimbangkan:
  - Amortisasi hardware: harga GPU / (24 × 365 × 3 tahun)
    RTX 4090 Rp 50jt: 50,000,000 / 26,280 = Rp 1,902/jam
  - Listrik: watts × Rp 1,500/kWh / 1000
    RTX 4090 450W: 0.45 × 1,500 = Rp 675/jam
  - Pendingin / infrastruktur: ~20% dari listrik
  - Total: ~Rp 2,700/jam (RTX 4090)

GPU Cloud cost: sesuai harga provider ($0.15-5.00/jam) × kurs Rp 16,200

Break-even point: Biaya GPU / (Biaya Cloud API - Biaya Listrik)

RTX 4090 (Rp 50 juta) vs DALL-E 3 (Rp 1,000/image):
  Biaya on-prem per image: Rp 11 (FLUX) 
  Biaya cloud per image:   Rp 1,000
  Hemat per image:          Rp 989
  Break-even:               50,000,000 / 989 = 50,556 image
  Pada 100 image/hari:      50,556 / 100 = 505 hari (~1.4 tahun)
  
RTX 4090 vs GPT-4o API:
  On-prem cost/token:       Rp 0.008 (Gemma 4 12B)
  GPT-4o cost/token:        Rp 2
  Hemat per token:          Rp 1.992
  Break-even (50M):         25,100,000 token
  Pada 100K token/hari:     251 hari (~8 bulan)

=== VRAM CALCULATOR TEMPLATE ===
# Isi dari config model:
PARAMS = ______ B              # total parameter (e.g., 12.2)
N_LAYERS = ______              # num_hidden_layers (e.g., 48)
HIDDEN_DIM = ______            # hidden_size (e.g., 5120)
N_HEADS = ______               # num_attention_heads (e.g., 40)
N_KV_HEADS = ______            # num_key_value_heads (e.g., 8)
HEAD_DIM = HIDDEN_DIM / N_HEADS # biasanya 128
KV_DIM = HEAD_DIM × N_KV_HEADS

# Pilih quantization:
Q_BYTES = 2 (FP16) / 1 (FP8) / 0.5 (Q4) / 0.375 (Q3) / 0.25 (Q2)

# Pilih context length:
SEQ_LEN = ______               # sequence length dalam tokens

# Jumlah concurrent users:
N_USERS = ______

# === HITUNG ===
VRAM_WEIGHTS = PARAMS × 1e9 × Q_BYTES / (1024^3)   # dalam GB

KV_PER_USER = (2 × SEQ_LEN × KV_DIM × Q_BYTES × 2 × N_LAYERS) / (1024^3)  # GB

VRAM_KV_TOTAL = KV_PER_USER × N_USERS

OVERHEAD = 2.0   # GB (estimasi konservatif)

VRAM_TOTAL = VRAM_WEIGHTS + VRAM_KV_TOTAL + OVERHEAD

GPU_YANG_DIBUTUHKAN:
  if VRAM_TOTAL <= 6:    "CPU / RTX 3050 6GB"
  elif VRAM_TOTAL <= 8:  "RTX 4060 8GB / Arc 8GB"
  elif VRAM_TOTAL <= 12: "RTX 3060 12GB"
  elif VRAM_TOTAL <= 16: "RTX 4060 Ti 16GB"
  elif VRAM_TOTAL <= 24: "RTX 4090 24GB"
  elif VRAM_TOTAL <= 32: "RTX 5090 32GB"
  elif VRAM_TOTAL <= 48: "RTX 6000 Ada 48GB"
  elif VRAM_TOTAL <= 80: "A100 80GB"
  elif VRAM_TOTAL <= 141: "H200 141GB"
  else:                   "Cluster multi-GPU diperlukan"

print(f"VRAM Total: {VRAM_TOTAL:.1f} GB")
print(f"GPU minimal: {GPU_YANG_DIBUTUHKAN}")

Gemma 4 12B Unified — Encoder-Free:
  Visual tokens per gambar: ~256 tokens (resolusi 512×512)
  
  VRAM tambahan untuk gambar:
    = 0 GB (tidak ada encoder terpisah)
    + visual_tokens × hidden_dim × 2 × n_layers (forward pass)
    = ~256 × 5,120 × 2 × 48 = ~125 MB per gambar
  
  Total overhead multimodal Gemma 4 12B:
    Hanya ~125 MB per gambar — SANGAT efisien!
    Tidak perlu VRAM tambahan signifikan untuk multimodal.

Qwen 3 VL — Encoder-Based (SigLIP):
  Vision encoder params: ~400M (SigLIP ViT-g)
  VRAM encoder (FP16): 400M × 2 = 0.8 GB
  Visual tokens per gambar: 576 tokens (ViT patch 14×14, 336px)
  Projection layer: ~30M params → 60 MB
  
  VRAM tambahan total (1 gambar):
    = encoder_weights (0.8 GB)
    + visual_tokens × hidden_dim (aktivasi)
    = 0.8 + 0.06 + (576 × 7,168 × 2) / 1e9
    = 0.8 + 0.06 + 0.008
    = ~0.87 GB per gambar
  
  Lebih berat dari encoder-free, tapi kualitas encoding gambar lebih baik.

Llama 4 Scout — Encoder-Based (ViT-22B):
  Vision encoder params: ~4B (ViT-22B dari Meta)
  VRAM encoder (Q4): 4B × 0.5 = 2 GB
  Visual tokens per gambar: 1,024 tokens
  Projection layer: ~100M params
  
  VRAM tambahan total (1 gambar, Q4):
    = 2.0 + 0.05 + (1024 × 7,168 × 2) / 1e9
    = 2.0 + 0.05 + 0.015
    = ~2.07 GB per gambar

Audio processing:
  Audio sample rate: 16 kHz
  Audio tokens per second: ~12.5 tokens/detik (Gemma 4)
  Audio encoder: 0 GB (encoder-free, langsung ke embedding space)
  
  VRAM tambahan untuk 30 detik audio:
    = 12.5 × 30 = 375 audio tokens
    = 375 × hidden_dim × 2 bytes (aktivasi)
    = 375 × 5,120 × 2 = 3.84 MB
    = ~4 MB — sangat kecil!
  
  Kesimpulan: Audio multimodal hampir tidak menambah VRAM signifikan.
  Dominasi tetap di text KV cache.

Overhead System Prompt + Tools:
  System prompt: 500-2,000 token (konteks, instruksi, role)
  Tool definitions (JSON Schema): 200-3,000 token per tool
    Contoh: 10 tools × 500 token = 5,000 token
  Tool call output: 100-5,000 token per tool call
    Contoh: 3 tool calls dalam satu sesi = 300-15,000 token
  Function result: 500-10,000 token per hasil API call
  Round-trip overhead: setiap tool call → response → next call

Total overhead per sesi = system + tools_def + tool_calls + function_results
  Sesi sederhana (1-2 tool calls): ~2,000 - 5,000 token tambahan
  Sesi kompleks (5-10 tool calls): ~10,000 - 50,000+ token tambahan

Model: Gemma 4 12B Q4 di RTX 4090 24GB

Tanpa agentic (chat biasa, 4K context):
  VRAM weights: 6.1 GB
  KV cache (4K): 0.8 GB
  Total per user: ~6.9 GB + 2 GB overhead = 8.9 GB
  Concurrent users: floor((24 - 8.9) / 0.8) + 1 ≈ 19 user

Dengan agentic (10 tools, 8K context per sesi):
  System + tools definitions: ~3,000 token
  Tool calls + results: ~5,000 token
  Total context per sesi: 8,000 token
  
  KV cache per sesi (8K, FP8):
    = 2 × 8192 × 1024 × 1 × 2 × 48 / (1024^3)
    = 1.6 GB per sesi agentic
  
  Total per user agentic: 6.1 + 1.6 + 2.0 = 9.7 GB
  Concurrent users: floor((24 - 9.7) / 1.6) + 1 ≈ 10 user
  ⬇️ Dari 19 user (chat) menjadi 10 user (agentic) — turun ~47%!

Model: Qwen 3 7B Q4 — ~3.8 GB weights
Tools: 5 tools (weather, calendar, email, search, calculator)
System prompt: 800 token (instruksi + tool definitions)

Per user per sesi:
  KV cache (4K + 800 system = ~5K context):
    = 2 × 5120 × 1024 × 1 × 2 × 28 / (1024^3)
    = 0.55 GB (FP8, n_layers=28, kv_dim=1024 untuk Qwen 3 7B)
  
  Total per user: 3.8 + 0.55 + 2.0 = 6.35 GB
  
  Concurrent users di RTX 3060 12GB: floor((12 - 6.35) / 0.55) + 1 = 11 user
  Concurrent users di RTX 4090 24GB: floor((24 - 6.35) / 0.55) + 1 = 33 user

Biaya per sesi agentik (~10 menit, ~3 tool calls):
  Di RTX 4090: 10 menit = 1/6 jam × Rp 2,700 = Rp 450
  Dengan 33 concurrent user: Rp 450 / 33 = Rp 14 per sesi
  Bandingkan dengan GPT-4 function calling: ~Rp 200-500 per sesi
  Hemat 14-35× !

LANGKAH 1 — Dapatkan Parameter Arsitektur
  Cara 1: Baca Hugging Face model card (bagian "config.json")
  Cara 2: Jalankan di Python:
    from transformers import AutoConfig
    cfg = AutoConfig.from_pretrained("org/model-name")
    print(f"Params: {cfg.num_parameters() if hasattr(cfg, 'num_parameters') else 'cek manual'}")
    print(f"Layers: {cfg.num_hidden_layers}")
    print(f"Hidden: {cfg.hidden_size}")
    print(f"Heads: {cfg.num_attention_heads}, KV: {cfg.num_key_value_heads if hasattr(cfg, 'num_key_value_heads') else cfg.num_attention_heads}")
    print(f"Vocab: {cfg.vocab_size}")
  Cara 3: Dari paper — cari tabel arsitektur

LANGKAH 2 — Hitung VRAM Weights
  weight_gb = params × bytes_per_param / (1024^3)
  bytes_per_param: FP16=2, FP8=1, Q8=1, Q4=0.5, Q3=0.375, Q2=0.25

LANGKAH 3 — Hitung KV Cache
  kv_dim = (hidden_dim / n_heads) × n_kv_heads
  kv_per_user_gb = 2 × seq_len × kv_dim × bytes_per_param × 2 × n_layers / (1024^3)
  total_kv_gb = kv_per_user_gb × concurrent_users

LANGKAH 4 — Tambahkan Overhead
  overhead = 2.0 (konservatif) atau 1.0 (optimis, dengan FlashAttention)
  — Jika multimodal + encoder-based: tambahkan 1-3 GB encoder weights
  — Jika agentic: tambahkan 50-100% ke seq_len untuk tool definitions

LANGKAH 5 — Cek Ketersediaan GPU
  total = weight_gb + total_kv_gb + overhead
  if total <= VRAM_GPU: ✓ BISA jalan (dengan asumsi bandwidth cukup)
  if total > VRAM_GPU: ✗ Butuh GPU lebih besar atau quantization lebih agresif

Untuk satu pengguna, pertanyaan utamanya: apakah VPS cukup atau butuh GPU dedicated? Jawabannya tergantung pada ukuran model. VPS 2-4 core, 8GB RAM, tanpa GPU hanya mampu menjalankan model <3B dengan token speed 2-5 tok/s — sangat lambat. PC desktop dengan RTX 4090 bisa menjalankan model 7B-13B Q4 dengan kecepatan 50-100 tok/s.

Tim kecil membutuhkan server yang bisa melayani 5-10 user concurrent. Dengan continuous batching, satu GPU bisa melayani beberapa user sekaligus. RTX 4090 (24GB) cukup untuk 5-10 user dengan model 7-12B Q4. Untuk model lebih besar, dual RTX 4090 atau A6000 48GB diperlukan.

Perusahaan menengah memerlukan dedicated server dengan GPU data center. Satu server 4× A100 80GB bisa melayani 30-50 user concurrent untuk model 7B Q4. Untuk model 70B, diperlukan cluster multi-node. vLLM dengan tensor parallelism adalah pilihan utama.

Enterprise dan BUMN membutuhkan cluster inference dengan high availability. NVIDIA DGX B200 (8× B200, 1.5TB VRAM) adalah pilihan flagship. Untuk skala BUMN 500+ concurrent, dibutuhkan 2-4 node DGX dengan load balancer. Biaya per node: Rp 15-25 miliar.

Model besar yang tidak muat di satu GPU memerlukan distributed inference. Tiga strategi utama: Tensor Parallelism (TP) membagi layer, Pipeline Parallelism (PP) membagi batch, dan Data Parallelism (DP) untuk throughput. InfiniBand 200Gbps atau NVLink sangat penting untuk TP yang efisien.

GPU menghasilkan panas luar biasa. RTX 4090 = 450W, A100 = 400W, H100 = 700W, H200 = 700W, B200 = ~1000W. Contoh: 8× H100 = 5.6kW + server = ~7kW. Dengan tarif industri Rp 1,500/kWh: 7kW × 24h × Rp 1,500 = Rp 252,000/hari = ~Rp 7.5 juta/bulan hanya untuk listrik. AC ruangan: ~Rp 2-3 juta/bulan.

Storage cepat penting untuk model loading. NVMe RAID 0 (beberapa NVMe digabung) memberikan kecepatan baca 10-28 GB/s — ideal untuk model besar. Model 671B di Q4 = ~336GB, loading dari NVMe: ~30 detik, dari HDD: >10 menit. Networking minimal 100GbE untuk multi-node, InfiniBand 200Gbps untuk performa maksimal.

Kalkulasi Daya Listrik Inference Cluster

Tips. Tarif listrik Indonesia: rumah tangga ~Rp 1,400/kWh, industri ~Rp 1,200/kWh, bisnis ~Rp 1,500/kWh. Untuk data center, tarif volume bisa lebih murah.

Menempatkan server inference di rumah atau kantor memang menghemat sewa data center, tapi konsekuensinya tidak ringan: listrik tidak stabil, pendingin AC rumah tidak dirancang untuk beban panas GPU 24/7, bandwidth terbatas, dan risiko downtime akibat pemadaman PLN. Colocation — menyewa ruang rak di data center profesional — adalah solusi antara yang mulai banyak diadopsi oleh perusahaan Indonesia yang menjalankan inference skala menengah. Di sini kita ulas tiga penyedia colocation utama di Indonesia beserta perbandingan pricing dan karakteristiknya.

DCI Indonesia (Data Center Infrastructure)

DCI adalah penyedia data center tier III terbesar di Indonesia dengan fasilitas di Jakarta, Surabaya, Bandung, dan Batam. DCI menawarkan colocation dalam bentuk half rack (21U), full rack (42U), dan customized cage. Harga colocation DCI per bulan untuk full rack 42U dengan daya 4-6 kW dan koneksi internet 1 Gbps berkisar di Rp 18-25 juta/bulan. Untuk daya lebih tinggi (10-15 kW) yang diperlukan oleh 4-8 GPU server, harganya naik ke Rp 35-50 juta/bulan. DCI unggul di konektivitas — terhubung langsung ke banyak IXP (Indonesia Internet Exchange) sehingga latency ke pengguna akhir sangat rendah. Cocok untuk perusahaan yang membutuhkan latency minimal dan SLA 99.98%.

Telkom Data Center (TelkomDC / NeutraDC)

Telkom memiliki jaringan data center terluas di Indonesia melalui NeutraDC (sebelumnya TelkomDC), dengan fasilitas di Jakarta, Bandung, Surabaya, Batam, Makassar, Medan, dan Balikpapan. Keunggulan utama Telkom adalah konektivitas ke jaringan Serat Optik Telkom — backbone internet utama Indonesia. Untuk colocation standard tier III, half rack (21U) dengan daya 3 kW dibanderol Rp 12-16 juta/bulan. Full rack (42U) dengan daya 6 kW: Rp 22-30 juta/bulan. Untuk high-power config (15 kW): Rp 50-70 juta/bulan. Telkom juga memiliki layanan managed colocation di mana mereka meng-handle basic monitoring dan hands-and-eyes support — biaya tambahan Rp 5-10 juta/bulan. Cocok untuk perusahaan yang aplikasi-nya harus dekat dengan pengguna di berbagai kota Indonesia.

NeutraDC Edge & Fasilitas Regional

NeutraDC Edge hadir sebagai solusi data center di kota tier-2 seperti Semarang, Palembang, Denpasar, dan Pontianak. Harga colocation di edge lebih terjangkau — full rack 42U dengan daya 3 kW mulai Rp 10-15 juta/bulan — namun dengan bandwidth dan SLA yang lebih rendah (99.9% vs 99.98%). Untuk inference AI yang membutuhkan latensi rendah di luar Jawa, NeutraDC Edge adalah opsi yang menarik karena biaya listrik dan properti di kota kecil lebih murah, menghemat hingga 30-40% dibandingkan colocation di Jakarta.

Tip biaya. Jangan hanya melihat harga sewa rak. Perhatikan juga biaya listrik per kWh di data center — biasanya sudah termasuk dalam paket colocation (metered atau fixed). DCI misalnya, memasukkan 4kW dalam paket dasar, kelebihan daya dikenakan Rp 2.500-3.500/kWh. Pastikan Anda menghitung total daya server inference Anda sebelum memilih paket. Server dengan 4× A100 (makan ~8kW) mungkin memerlukan full rack high-power yang harganya 2-3× lipat dari paket standard.

Setiap model deployment memiliki profil biaya, performa, dan kompleksitas yang berbeda. Berikut perbandingan lengkap dari keempat opsi utama untuk menjalankan LLM inference di Indonesia. Perbandingan ini didasarkan pada skenario tipikal: 4 GPU (A100 80GB atau setara) yang melayani 50-100 concurrent user dengan model 7B-70B Q4.

VPS Cloud GPU

VPS cloud dengan GPU — seperti AWS EC2 G5 (A10G), G6 (L4), atau pG6 (A100), Google Cloud L4/A100, Azure NCas, atau penyedia GPU cloud Indonesia seperti GW2 dan Exabytes — adalah opsi paling fleksibel. Tidak ada investasi awal, bayar per jam, dan bisa scale up/down sesuai kebutuhan. Untuk 4× A100 di AWS (p4d.24xlarge): ~$32/jam atau ~Rp 530/jam. Untuk pemakaian 24/7: ~Rp 380 juta/bulan — sangat mahal. Model lebih murah: 1× L4 (AWS g6.xlarge) ~$1.25/jam atau Rp 1,5 juta/bulan jika 24/7, tapi hanya 24GB VRAM — cukup untuk model ≤12B Q4. VPS cloud GPU paling cocok untuk: eksperimen, beban yang tidak 24/7, dan burst kapasitas.

Dedicated Server (Sewa GPU Server)

Penyedia seperti ServerGPU, GW2 Dedicated, Exabytes Dedicated, atau perusahaan internasional seperti Vast.ai dan RunPod menawarkan dedicated server dengan GPU terpasang. Bedanya dengan VPS: Anda mendapat server fisik eksklusif, tidak berbagi dengan tenant lain. Harga sewa dedicated 4× A100 di Indonesia: Rp 80-120 juta/bulan (termasuk listrik, pendingin, bandwidth). Di Vast.ai/RunPod internasional: $4-8/jam atau Rp 65-130rb/jam — lebih murah untuk pemakaian on-demand, tapi mahal untuk 24/7 (Rp 47-94 juta/bulan). Dedicated server adalah kompromi yang baik: tidak perlu beli hardware, tidak perlu urus listrik dan pendingin, tapi biaya bulanan lebih tinggi daripada colocation atau on-premise dalam jangka panjang.

Colocation (Sewa Rak, Punya Server)

Anda beli server sendiri, lalu tempatkan di data center pihak ketiga. Model ini memberi kontrol penuh atas hardware dengan lingkungan data center profesional. Biaya di sini terbagi dua: capex server + GPU (sekali) dan opex colocation (bulanan). Untuk 4× A100 server: Rp 2-3 miliar capex. Colocation full rack high-power 15kW: Rp 40-60 juta/bulan. TCO 5 tahun: capex Rp 3 miliar + opex 5 tahun Rp 3 miliar = Rp 6 miliar. Colocation lebih murah daripada dedicated server (Rp 80-120 juta/bulan × 60 = Rp 4,8-7,2 miliar hanya opex) dalam jangka panjang, tapi Anda harus siap dengan investasi awal Rp 3 miliar.

On-Premise (Server di Kantor Sendiri)

Server ditempatkan di ruang server kantor sendiri. Biaya paling rendah untuk opex (hanya listrik + AC), tapi risiko paling tinggi: listrik mati, AC rusak, bandwidth terbatas, security fisik rendah. Untuk 4× A100 di kantor: capex Rp 3 miliar, listrik ~Rp 10 juta/bulan, AC ~Rp 3 juta/bulan, total opex ~Rp 13 juta/bulan. TCO 5 tahun: Rp 3 miliar + Rp 780 juta = Rp 3,78 miliar — paling murah secara total. Tapi kompromi: SLA tergantung pada infrastruktur kantor (PLN sering padam?), keamanan fisik, dan bandwidth internet. Cocok untuk perusahaan yang sudah punya data center mini di kantor atau lab riset di kampus.

Peringatan skalabilitas. VPS cloud GPU mungkin terlihat murah untuk pemakaian sporadis, tapi jika Anda menjalankan inference 24/7 — misalnya chatbot customer service — biaya per jam × 720 jam/bulan × 12 bulan × 5 tahun bisa jauh melebihi biaya colocation atau on-premise. Hitung dulu utilization rate Anda sebelum memutuskan. Jika server hanya dipakai 8 jam/hari (33% utilization), VPS cloud mungkin lebih murah. Jika 24/7, on-premise atau colocation hampir pasti menang dalam TCO 5 tahun.

Berikut kalkulasi Total Cost of Ownership (TCO) 5 tahun untuk empat model deployment dengan tiga skenario beban kerja yang berbeda: skala kecil (1× RTX 4090, 10-20 user), skala menengah (4× A100 80GB, 50-100 user), dan skala enterprise (DGX B200, 500-1000 user). Semua asumsi finansial mengacu pada catatan metodologi di Bab 4: kurs Rp 16.500/USD, tarif listrik industri Rp 1.500/kWh, depresiasi GPU 3 tahun residual 10%, depresiasi server 4 tahun residual 5%.

Skenario A: Skala Kecil — 1× RTX 4090 (10-20 User)

Untuk skala kecil, on-premise jelas pemenangnya — total Rp 105 juta untuk 5 tahun. Colocation masuk akal jika Anda butuh uptime lebih baik (colocation + Rp 135 juta over 5 tahun). VPS dan dedicated server terlalu mahal untuk skala ini.

Skenario B: Skala Menengah — 4× A100 80GB (50-100 User)

Untuk skala menengah, on-premise masih unggul dengan TCO Rp 3,78 miliar. Tapi colocation hanya berselisih Rp 2,22 miliar lebih mahal dengan benefit uptime 99.98% — mungkin sepadan untuk perusahaan yang tidak bisa mentolerir downtime. VPS cloud di sini sudah sangat tidak ekonomis untuk beban 24/7.

Skenario C: Skala Enterprise — DGX B200 (500-1000 User)

Enterprise tier: on-premise colocation kompetitif. Colocation (Rp 24,2 miliar) dan on-premise (Rp 21,8 miliar) berselisih tipis — selisih Rp 2,4 miliar untuk 5 tahun itu hanya ~10%. Jika perusahaan sudah punya data center sendiri (seperti BUMN atau bank), on-premise lebih murah. Jika belum, colocation dengan SLA 99.98% adalah pilihan cerdas mengingat biaya setup data center dari nol bisa Rp 5-10 miliar tambahan.

Grafik sederhana TCO 5 tahun: Jika divisualisasikan, garis biaya VPS cloud dan dedicated server naik linear curam. Colocation dan on-premise punya lonjakan di tahun 0 (capex) tapi garisnya landai setelahnya. Titik potong terjadi di tahun 1-2 untuk skala kecil, tahun 2-3 untuk skala menengah, dan tahun 3-4 untuk skala enterprise. Semakin besar skala, semakin lama waktu yang dibutuhkan untuk menutup capex, tapi setelah break-even, penghematan per bulannya sangat signifikan.

Server inference bukan server biasa. GPU yang mati di tengah operasi bisa mengakibatkan ribuan sesi chatbot terputus, antrean RAG terhenti, dan — jika model tidak diload ulang dengan benar — kerusakan KV-cache yang mempengaruhi kualitas output. Untuk layanan inference production-grade, redundancy bukan opsional — terutama jika Anda beroperasi di Indonesia dengan tantangan infrastruktur listrik yang masih belum 100% stabil.

Dual Power Supply Unit (PSU)

Setiap server inference kelas data center wajib memiliki dual PSU — dua unit power supply yang masing-masing mampu menyuplai daya penuh server. Jika satu PSU mati, PSU kedua langsung mengambil alih tanpa jeda (hot-swappable). Untuk server GPU: PSU 2000W-3000W per server (tergantung jumlah GPU). Contoh: Supermicro AS-4124GS-TNRT dengan 4× A100 membutuhkan 2× 2200W PSU dalam konfigurasi 2N redundancy. Biaya tambahan untuk dual PSU vs single: sekitar Rp 3-8 juta per server. Pastikan PSU dihubungkan ke dua sumber listrik yang berbeda (dua jalur PLN berbeda atau PLN + genset) — jika tidak, dual PSU tidak berguna saat pemadaman total.

RAID untuk Storage Model

Model LLM yang sudah di-quantize adalah aset berharga — file GGUF ukuran 5-50GB per model yang butuh waktu berhari-hari untuk didownload dan dikonfigurasi. RAID (Redundant Array of Independent Disks) melindungi data model dari kegagalan disk. Untuk inference server, dua konfigurasi RAID yang paling relevan: RAID 1 (mirroring) — dua NVMe identik, jika satu mati, yang lain masih jalan. Cocok untuk storage model (kapasitas tidak terlalu besar, tapi butuh read speed tinggi). RAID 10 (stripe + mirror) — 4 NVMe, kecepatan baca 2× lipat dengan redundancy penuh. Lebih mahal tapi ideal untuk server production yang tidak bisa downtime. Harga NVMe Gen4 4TB: Rp 4-6 juta per unit. RAID 1 (2 NVMe): +Rp 8-12 juta. RAID 10 (4 NVMe): +Rp 16-24 juta.

GPU Failover — Tantangan Utama

Berbeda dengan CPU — yang bisa langsung failover ke CPU cadangan tanpa kehilangan sesi — GPU failover untuk inference LLM sangat rumit. Saat GPU mati di tengah inference, sesi aktif akan gagal (error) karena model state di VRAM hilang. Solusi yang bisa diterapkan: Model replicas — deploy model yang sama di 2+ GPU (atau 2+ node) secara independen. Jika GPU A mati, load balancer mengarahkan request ke GPU B. Biaya: 2× lipat GPU untuk redundancy penuh. N+1 redundancy — jika Anda butuh 4 GPU untuk throughput target, deploy 5 GPU (N+1). Saat satu GPU turun, performa turun 20% (bukan 100%). Ini biaya paling efektif untuk HA. Graceful degradation via CPU offload — saat GPU mati, model bisa di-offload ke CPU (dengan LLama.cpp misalnya) dengan kecepatan jauh lebih rendah, tapi layanan tetap berjalan. Tidak ideal untuk real-time, tapi lebih baik daripada mati total.

Biaya laten HA. Banyak yang lupa bahwa high availability bukan hanya soal hardware — tapi juga soal arsitektur inference. Di framework seperti vLLM, jika satu GPU dalam tensor parallelism mati, seluruh model crash — tidak bisa partial failover. Solusinya: deploy model replica independen (data parallelism) alih-alih tensor parallelism tunggal di banyak GPU. Ini kompromi — efficiency lebih rendah (DP vs TP) tapi HA lebih baik. Untuk production, DP + N+1 lebih aman daripada TP tunggal.

Server inference GPU butuh monitoring yang lebih ketat dibandingkan server biasa. GPU bisa thermal throttle, VRAM penuh, PCIe link turun ke Gen1, atau memory ECC error tanpa indikasi yang jelas di level aplikasi. Tanpa monitoring yang baik, Anda baru tahu ada masalah setelah user komplain — atau lebih parah, setelah server crash. Berikut adalah stack monitoring wajib untuk inference cluster, dari yang paling dasar hingga dashboard penuh.

Tingkat 1: NVIDIA SMI (Command Line)

nvidia-smi adalah alat paling dasar, tapi sangat informatif untuk debugging cepat. Jalankan dengan parameter berikut untuk monitoring GPU secara real-time:

# Monitoring real-time, refresh setiap 1 detik
nvidia-smi -l 1

# Output dalam format CSV untuk logging
nvidia-smi --query-gpu=index,timestamp,temperature.gpu,\
utilization.gpu,memory.used,memory.total,power.draw,\
pcie.link.gen.current,pcie.link.width.current \
--format=csv -l 5 > gpu-log.csv

# Cek process yang pakai GPU
nvidia-smi pmon -c 1

# Detail ECC memory errors (penting untuk GPU data center)
nvidia-smi -q -d ECC

Metrik paling penting yang harus dimonitor: GPU utilization (target >80% untuk inference efficient), memory used (jangan sampai 100%, sisakan 10-15% untuk KV-cache growth), temperature (<90°C untuk air cooled, <85°C ideal), power draw (indikasi apakah GPU bekerja optimal), PCIe link gen dan width (jika turun ke Gen1, ada masalah koneksi).

Tingkat 2: Prometheus + DCGM Exporter

Untuk monitoring berkelanjutan, gunakan Prometheus dengan NVIDIA DCGM (Data Center GPU Manager) Exporter. DCGM memberikan 200+ metrik GPU yang jauh lebih detail daripada nvidia-smi — termasuk memory bandwidth utilization, SM occupancy, tensor core activity, dan NVLink traffic. Berikut cara setup:

# 1. Jalankan DCGM exporter di Docker (setiap node GPU)
docker run -d --gpus all --rm \
  --name dcgm-exporter \
  --cap-add SYS_ADMIN \
  -p 9400:9400 \
  nvidia/dcgm-exporter:3.3.7-1.0.0-ubuntu22.04

# 2. Verifikasi metrik
curl http://localhost:9400/metrics | head -20

# 3. Tambahkan target ke prometheus.yml
# - job_name: 'dcgm-gpu'
#   scrape_interval: 10s
#   static_configs:
#     - targets: ['server1:9400', 'server2:9400']

Metrik DCGM yang paling berguna untuk inference: DCGM_FI_DEV_GPU_UTIL (utilisasi GPU aktual), DCGM_FI_DEV_MEM_COPY_UTIL (utilisasi memory), DCGM_FI_DEV_ECC_SBE_VOL_TOTAL (single-bit ECC error — early warning kerusakan VRAM), DCGM_FI_DEV_POWER_USAGE, DCGM_FI_DEV_XID_ERRORS (XID error = GPU crash). Integrasikan juga metrik framework inference: vLLM mengekspos metrik Prometheus di endpoint /metrics yang mencakup vllm:num_requests_running, vllm:time_to_first_token_seconds, vllm:request_prompt_tokens, dan vllm:request_generation_tokens.

Tingkat 3: Grafana Dashboard

Grafana mengubah semua metrik Prometheus menjadi dashboard visual. Berikut adalah panel minimal yang harus ada di dashboard inference Anda:

1. GPU Utilization Overview — grafik garis per-GPU untuk utilisasi compute, memory, dan power. Deteksi jika ada GPU yang idle saat yang lain penuh.
2. Temperature & Thermal Throttling — suhu per GPU + flag thermal throttling. Jika salah satu GPU konsisten lebih panas 5-10°C, periksa thermal paste atau posisi dalam server.
3. VRAM Usage — total VRAM terpakai vs total VRAM per node. Saat VRAM mendekati 85-90%, warning untuk scale out atau turunkan model size.
4. Request Latency (TTFT + TPOT) — time-to-first-token dan tokens-per-output-token per detik. Ini metrik UX yang paling penting untuk chatbot.
5. Request Queue & Throughput — jumlah request dalam antrean, request sukses per menit, request error rate. Jika antrean tumbuh terus, scaling diperlukan.
6. Power & Cost — total daya (W) × tarif listrik = biaya per jam/hari/bulan. Hitung juga cost per 1M token dalam rupiah langsung di dashboard.

Alerting rules kritis. Konfigurasikan Prometheus Alertmanager untuk notifikasi real-time (via Telegram, Slack, atau email) pada kondisi berikut: GPU temperature >90°C, XID error terjadi, VRAM usage >90% selama >5 menit, request error rate >1%, GPU utilization <10% selama >1 jam (indikasi konfigurasi salah atau model crash), dan PCIe link turun dari gen yang diharapkan. Untuk Telegram: gunakan alertmanager-bot atau webhook sederhana.

Integrasi Metrik Bisnis

Dashboard teknis saja tidak cukup. Gabungkan juga metrik bisnis: cost per conversation (total biaya listrik + depresiasi ÷ jumlah sesi chat), cost per token yang real-time dibandingkan dengan API, dan user satisfaction proxy (latency tinggi biasanya berkorelasi dengan user abandon rate). Dengan dashboard yang menyatukan metrik teknis dan bisnis, Anda bisa menjawab pertanyaan pemangku kepentingan: "Berapa biaya yang kita keluarkan untuk setiap percakapan chatbot hari ini?"

Setelah server inference siap, pertanyaan berikutnya: bagaimana cara manage, deploy, dan scale model di atasnya? Jawabannya untuk production adalah Kubernetes — baik full K8s maupun distribusi ringan seperti K3S. Banyak tim Indonesia yang masih menjalankan inference langsung di terminal dengan vllm serve atau python app.py, tanpa containerization dan orchestration. Ini bekerja untuk skala kecil, tapi menjadi mimpi buruk saat harus update model, rollback versi, scale out node, atau manage multi-model di cluster yang sama.

Mengapa K3S Cocok untuk Inference Cluster di Indonesia

K3S adalah distribusi Kubernetes lightweight dari Rancher/SUSE yang dirancang untuk edge computing, IoT, dan — yang relevan — server dengan resource terbatas. Ukuran binary K3S hanya ~60MB (vs full K8s ~1GB), konsumsi RAM untuk control plane ~512MB, dan setup bisa selesai dalam 15 menit. Untuk inference cluster dengan 2-10 node GPU di Indonesia, K3S menawarkan keseimbangan ideal antara fungsionalitas Kubernetes penuh dan efisiensi resource. Bandingkan dengan full K8s yang butuh minimal 3 control plane nodes + etcd + banyak komponen tambahan — terlalu berat untuk cluster kecil-menengah.

Arsitektur Tipikal K3S + GPU Inference

Konfigurasi yang umum digunakan untuk deployment inference di K3S:

# 1. Install K3S di server GPU pertama (server node)
curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644

# 2. Install NVIDIA device plugin untuk ekspos GPU ke container
kubectl create -f https://raw.githubusercontent.com/NVIDIA/\
k8s-device-plugin/v0.16.2/nvidia-device-plugin.yml

# 3. Verifikasi GPU di cluster
kubectl get nodes -o json | jq '.items[].status.allocatable'
# Harus ada: nvidia.com/gpu: 4 (atau sesuai jumlah GPU)

# 4. Install GPU Operator (untuk management driver, DCGM, dll)
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm upgrade --install gpu-operator nvidia/gpu-operator -n gpu-operator --create-namespace

Deploy Model Inference dengan Deployment + Service K8s

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llama-3-8b-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: llama-3-8b
  template:
    metadata:
      labels:
        app: llama-3-8b
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        command: ["vllm", "serve", "meta-llama/Llama-3.2-8B-Instruct",
                  "--quantization", "fp8", "--max-model-len", "8192",
                  "--gpu-memory-utilization", "0.90",
                  "--port", "8000"]
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1
        env:
        - name: HF_TOKEN
          valueFrom:
            secretKeyRef:
              name: hf-token
              key: token
---
apiVersion: v1
kind: Service
metadata:
  name: llama-3-8b-svc
spec:
  selector:
    app: llama-3-8b
  ports:
  - port: 8000
    targetPort: 8000
  type: ClusterIP

Dengan arsitektur ini, Anda bisa melakukan rolling update model tanpa downtime (k8s mengganti pod satu per satu), auto-restart saat pod crash (liveness probe), scaling dengan perintah kubectl scale deployment llama-3-8b-inference --replicas=5, dan resource management yang ketat — setiap pod model hanya mendapat GPU yang dialokasikan, tidak bisa boros lebih dari yang ditentukan.

Kapan K3S/K8s Butuh — dan Kapan Tidak

Kompleksitas K8s vs nilai tambah. Kubernetes bukan tanpa biaya — Anda butuh seorang engineer (atau setidaknya setengah FTE) yang paham Kubernetes untuk manage cluster inference. Jika tim Anda hanya 1-2 orang AI engineer dan baru menjalankan 1-2 model di 1 server, Kubernetes mungkin lebih banyak menyulitkan daripada membantu. Mulailah dengan docker-compose, lalu migrasi ke K3S saat jumlah server >2 atau jumlah model >3. Jangan over-engineer di tahap awal — inference yang berjalan dengan docker-compose lebih baik daripada K8s yang setengah jalan karena tidak ada yang bisa maintain.

Auto-scaling — kemampuan menambah/mengurangi kapasitas inference otomatis berdasarkan beban — adalah fitur yang sering dianggap wajib, padahal tidak selalu. Auto-scaling inference AI memiliki tantangan unik yang berbeda dengan auto-scaling web server biasa: model warm-up time yang lama, biaya cold start yang tinggi (loading model 50GB ke VRAM), dan sifat stateful dari sesi inference (KV-cache tidak bisa dipindahkan antar node dengan mudah). Mari kita bedah kapan auto-scaling benar-benar diperlukan dan kapan lebih baik menggunakan fixed cluster.

Kapan Auto-Scaling Dibutuhkan

1. Beban yang sangat fluktuatif (10× atau lebih). Misalnya: layanan AI yang sepi di malam hari (50 req/menit) tapi melonjak di jam kantor (500 req/menit). Biaya untuk menjalankan full capacity 24/7 akan sangat boros. Auto-scaling bisa scale-in ke 1 node di malam hari, scale-out ke 5 node di siang hari.
2. Multi-tenant dengan SLA berbeda. Beberapa klien butuh dedicated capacity (steady), beberapa hanya burst. Auto-scaling memungkinkan Anda memisahkan baseline capacity (fixed) dan burst capacity (auto-scale).
3. Batch processing dengan jadwal tertentu. Contoh: sistem AI yang memproses laporan keuangan setiap akhir bulan. Auto-scaling bisa scale-out untuk batch dan scale-in setelah selesai.
4. Event-driven spikes. Peluncuran produk baru, kampanye marketing, atau momen tertentu (Hari Belanja Online Nasional — Harbolnas) yang menyebabkan lonjakan traffic.

Kapan Auto-Scaling Tidak Dianjurkan

1. Beban stabil 24/7. Chatbot customer service beroperasi 24 jam dengan beban yang relatif konstan. Auto-scaling di sini tidak memberi penghematan — yang terjadi malah overhead karena GPU harus terus menambah/mengurangi kapasitas yang sebenarnya selalu terpakai.
2. Cluster kecil (<4 GPU). Dengan 1-4 GPU, auto-scaling tidak praktis: satu GPU turun berarti kehilangan 25-100% kapasitas. Lagipula biaya GPU segitu masih relatif kecil.
3. Waktu warm-up terlalu lama. Model besar (70B+ di Q4) membutuhkan 1-5 menit untuk loading ke VRAM. Jika lonjakan traffic terjadi dalam hitungan detik, auto-scaling tidak akan sempat bereaksi. Solusi: pre-warm spare instance (yang biayanya hampir sama dengan fixed cluster).
4. Cloud GPU dengan minimum commit. Banyak penyedia GPU cloud mensyaratkan reservasi minimum 1-3 bulan. Auto-scaling jangka pendek (30 menit-scale up, 1 jam-scale down) sering tidak efisien secara biaya.

Strategi Auto-Scaling Hybrid

Pendekatan paling cost-effective untuk banyak kasus adalah hybrid auto-scaling: baseline capacity dengan on-premise/colocation (fixed cost rendah), burst capacity dengan cloud GPU (pay-per-use). Dengan begini, baseline harian ditangani oleh hardware yang sudah dibeli (capex-nya sudah dibayar, jadi opex marginalnya hanya listrik ~Rp 10-15 juta/bulan), sementara lonjakan traffic ditangani oleh GPU cloud dengan biaya per jam. Contoh konkret: perusahaan dengan 500 user/day (baseline, dihandle oleh 4× A100 on-prem) dan puncak 1500 user/day (burst, 8× A100 dari cloud selama 4 jam/hari). Biaya cloud burst: ~$15/jam × 4 jam × 22 hari = $1.320/bulan = Rp 22 juta/bulan. Bandingkan dengan fixed cluster 12× A100 24/7: $32/jam × 720 jam = $23.040/bulan = Rp 380 juta/bulan.

Tools auto-scaling untuk inference. Beberapa framework inference modern sudah mendukung auto-scaling native: vLLM dengan parameter --max-num-batched-tokens dan --max-num-seqs bisa diintegrasikan dengan Prometheus metrics untuk autoscaling via KEDA (Kubernetes Event-Driven Autoscaling). OpenRouter dan LiteLLM menyediakan proxy layer yang bisa auto-route ke multiple provider — termasuk fallback ke API jika on-premise penuh. Untuk implementasi sederhana tanpa K8s: gunakan script yang memonitor Antrian Redis, jika antrean >100, spin up cloud instance via API penyedia GPU cloud.

Indonesia adalah negara tropis dengan suhu rata-rata 28-34°C dan kelembaban 70-90%. Kondisi ini adalah musuh utama GPU — suhu tinggi memperpendek umur komponen, thermal throttling menurunkan performa, dan kelembaban tinggi meningkatkan risiko korosi pada sirkuit. Server inference menghasilkan panas luar biasa: 8× H100 (~700W × 8 = 5,6kW) berarti Anda perlu membuang setara panas 5-6 unit AC rumah tangga dari satu rak server. Tiga opsi cooling utama yang tersedia di Indonesia: AC standard (precision AC), liquid cooling (direct-to-chip), dan immersion cooling. Mari kita bandingkan.

Opsi 1: Precision AC (CRAC/CRAH) — Standard Data Center

Ini adalah standar industri untuk data center Indonesia hingga saat ini. Precision AC (Computer Room Air Conditioner) berbeda dengan AC rumah: dirancang untuk beroperasi 24/7, kontrol suhu presisi ±1°C, kontrol kelembaban built-in, dan filter HEPA untuk udara bersih. Untuk 15kW beban GPU (setara 8× A100 atau 4× H100): diperlukan AC precision ~20kW (dengan buffer N+1, total 30kW). Biaya:

• AC precision 20kW (unit + instalasi): Rp 80-150 juta per unit
• Biaya listrik AC: ~35-40% dari total daya IT. 15kW IT → ~6kW AC = Rp 6,5 juta/bulan listrik AC
• Perawatan tahunan: Rp 5-10 juta (filter ganti, refrigerant, coil cleaning)
• Total biaya cooling 5 tahun: Rp 100-150 juta (capex) + Rp 390 juta (listrik) + Rp 37,5 juta (maintenance) = Rp 527-577 juta

Kelebihan: teknologi matang, mudah maintenance, banyak vendor di Indonesia (Daikin, Carrier, Liebert). Kekurangan: boros listrik, butuh ruang lantai yang cukup besar, dan tidak efisien untuk densitas daya tinggi >20kW/rack.

Opsi 2: Liquid Cooling (Direct-to-Chip)

Direct-to-chip liquid cooling mengalirkan cairan coolant langsung ke cold plate yang menempel di GPU dan CPU. Cairan menyerap panas dan dibuang ke radiator atau cooling tower. NVIDIA sendiri merekomendasikan liquid cooling untuk GPU data center generasi terbaru (H100, H200, B200) yang memiliki TDP 700-1000W per GPU. Untuk 4× H100: sistem liquid cooler loop tunggal sudah cukup. Biaya:

• Retrofit kit liquid cooling (cold plate, pump, radiator, tubing) per GPU: Rp 10-20 juta/GPU
• Instalasi sistem (piping, reservoir, coolant): Rp 30-50 juta
• Total capex liquid cooling: Rp 70-130 juta untuk 4 GPU
• Biaya listrik pump + fan: ~300-500W = Rp 0,5 juta/bulan (jauh lebih rendah dari AC)
• Perawatan: ganti coolant setiap 2-3 tahun, Rp 5-10 juta

Kelebihan: lebih efisien (PUE bisa turun dari 1,6 ke 1,2), GPU temperature lebih rendah (60-70°C vs 80-90°C), mengurangi thermal throttling, memungkinkan densitas lebih tinggi (hingga 40kW/rack). Kekurangan: instalasi lebih kompleks, risiko kebocoran air (meskipun coolant non-konduktif), vendor terbatas di Indonesia (perlu impor atau integrasi sendiri).

Opsi 3: Immersion Cooling

Immersion cooling merendam server dalam cairan dielektrik non-konduktif (seperti 3M Novec atau Engineered Fluids). Seluruh komponen — termasuk GPU, CPU, motherboard — terendam dalam cairan yang menyerap panas secara langsung. Metode ini paling efisien secara termal, memungkinkan PUE hingga 1,05 — hampir semua listrik masuk ke komputasi, bukan pendinginan. Biaya:

• Tank immersion (untuk 1 server 4U): Rp 250-400 juta
• Cairan dielektrik: Rp 80-150 juta per tank (perlu top-up ~10% per tahun)
• Kit konversi server (lepas fan,密封 komponen): Rp 20-40 juta
• Total capex: Rp 350-590 juta per tank
• Biaya listrik pump + chiller: ~200-400W = Rp 0,3 juta/bulan

Kelebihan: PUE sangat rendah (1,05-1,1), GPU temperature stabil di 50-60°C, server bisa dijalankan 24/7 tanpa fan (senyap), umur komponen lebih panjang, densitas sangat tinggi. Kekurangan: capex awal sangat mahal, perawatan cairan (kebersihan, topping), servis server lebih susah (harus dikeluarkan dari cairan, dikeringkan), dan risiko void warranty dari vendor server.

Rekomendasi untuk Indonesia. Untuk server inference dengan 1-4 GPU (skala kecil-menengah): Precision AC sudah cukup — biayanya masuk akal, teknologinya matang, dan banyak vendor lokal yang bisa service. Untuk 8+ GPU (skala enterprise): Liquid cooling mulai masuk akal — penghematan listrik AC selama 5 tahun bisa melebihi biaya investasi liquid cooling. Immersion cooling baru layak untuk cluster >16 GPU di data center tier III/IV yang memang dirancang untuk high-density compute. Satu catatan penting: suhu dan kelembaban Jakarta/Cikarang sangat berbeda dengan Bandung atau Malang. Jika memungkinkan, tempatkan server di data center di daerah yang lebih sejuk (seperti DCI Bandung atau NeutraDC di dataran tinggi) bisa menghemat biaya cooling hingga 15-20%.

Jangan sepelekan thermal. Saya pernah melihat kasus di mana server 4× A100 ditempatkan di ruangan AC standard rumah (AC split 2 PK) — GPU mencapai 95°C dalam 10 menit dan thermal throttle ke 30% performa. Tim tersebut membeli A100 seharga Rp 1,2 miliar tapi hanya mendapat performa setara RTX 3090 karena overheating. Hitung biaya cooling dengan benar sebelum membeli GPU. Di Indonesia tropis, cooling bukan opsi — ini kebutuhan wajib yang biayanya bisa mencapai 30-40% dari total biaya listrik infrastruktur inference Anda.

Perbandingan API vs on-premise tidak bisa hanya dilihat dari tok/s. Ada lima parameter utama: kecepatan (TTFT + TPOT), biaya (Capex vs Opex), skalabilitas (easy vs hard), perawatan (provider vs tim IT), dan privasi data (data keluar vs data lokal).

Profil: Startup AI dengan 5 developer. Kebutuhan coding assistant + chat, ~50 juta token/bulan. Biaya API: Rp 3-8 juta/bulan (GPT-4o-mini) atau Rp 30-50 juta/bulan (Claude Sonnet). On-prem: RTX 4090 (Rp 50 juta sekali + Rp 2 juta/bulan listrik). Break-even: ~10 bulan vs GPT-4o-mini, ~2 bulan vs Claude Sonnet. Rekomendasi: Mulai dengan API, beli RTX 4090 setelah 3 bulan jika token rate naik.

Profil: 50 karyawan, butuh AI untuk CS + coding + dokumen. ~500 juta token/bulan. Biaya API: Rp 30-80 juta/bulan. On-prem: 4× A100 80GB (Rp 2.5 miliar + Rp 10 juta/bulan listrik). TCO 3 tahun: API ~Rp 1.8 miliar vs on-prem ~Rp 3.1 miliar. On-prem lebih mahal karena investasi awal besar, tapi data tetap di dalam perusahaan dan latency lebih rendah.

Profil: BUMN dengan 500+ concurrent users. Data privacy wajib (UU PDP). API enterprise: minimal Rp 200-500 juta/bulan (tidak termasuk data residency). On-prem: DGX B200 cluster (Rp 15 miliar + Rp 50 juta/bulan listrik + Rp 30 juta/bulan staff). TCO 5 tahun: API ~Rp 20-35 miliar vs on-prem ~Rp 25-30 miliar. On-prem lebih murah dalam 5 tahun, plus data aman.

Angka-angka teknis kadang sulit dibayangkan. Berikut adalah analogi dunia nyata untuk membantu memahami perbedaan kecepatan antara CPU inference, GPU inference, dan API inference.

Tabel Analogi Kecepatan

Analogi Biaya

Inti. Beda CPU dan GPU itu kayak beda angkot dan motor sendiri — sama-sama sampe, tapi motor 20× lebih cepat dan bahan bakarnya lebih murah per kilometer. Beda GPU dan API itu kayak beda motor sendiri dan naik helikopter — helikopter lebih cepet, tapi kamu bayar tiap kali naik.

Semua harga API model besar yang tercantum di situs resmi OpenAI, Anthropic, dan Google dalam denominasi USD per 1M token. Untuk pembeli Indonesia — terutama perusahaan yang membutuhkan faktur pajak — harga sesungguhnya yang dibayar adalah harga USD × kurs (misal Rp 16.500/USD) + PPN 11% + PPh 22 (untuk impor jasa, jika provider tidak punya BUT di Indonesia). Tabel berikut menyajikan harga API yang sudah dikonversi ke Rupiah dengan PPN, sehingga Anda bisa langsung membandingkan dengan biaya on-premise dalam mata uang yang sama.

*PPh 22 (15%) berlaku untuk pembayaran ke luar negeri tanpa DGT atau jika penyedia tidak punya tax treaty yang menguntungkan. Banyak startup Indonesia menggunakan jasa perantara seperti OpenRouter atau API Gateway lokal yang sudah termasuk PPN. Harga Gateway lokal biasanya +20-30% dari harga dasar untuk menutup biaya pajak dan markup.

API Lokal Indonesia

Beberapa penyedia AI API lokal Indonesia sudah mulai bermunculan: GW2 AI (GPT-4o via lokal), Neural, Nodeflux, dan Aksara AI. Harga mereka biasanya lebih tinggi dari harga langsung OpenAI per token (karena mereka menambahkan margin dan PPN), tapi menawarkan kemudahan: faktur pajak Indonesia langsung, support dalam Bahasa Indonesia, pembayaran via transfer bank lokal, dan — yang paling penting untuk beberapa sektor — jaminan data tidak meninggalkan server di Indonesia. Perbandingan: GPT-4o-mini via penyedia lokal biasanya Rp 18.000-25.000/1M token output (sudah PPN) — lebih mahal 60-125% dari harga langsung setelah PPN, tapi tanpa ribet kurs USD dan pajak impor. Untuk perusahaan yang butuh faktur PPN dan tidak punya akses kartu kredit internasional, ini adalah solusi yang valid.

Tip pembayaran API: Jika startup Anda masih pakai API langsung dari OpenAI/Anthropic dengan kartu kredit pribadi, ingat bahwa biaya itu belum termasuk PPN 11% dan pajak penghasilan yang harus disetor sendiri sebagai WPLN (Wajib Pajak Luar Negeri). Konsultan pajak biasanya menyarankan untuk buka rekening korporasi dan daftar sebagai entitas bisnis ke OpenAI — atau gunakan reseller lokal yang sudah mengurus semua kewajiban perpajakan. Jangan sampai di akhir tahun pajak Anda harus bayar denda karena lapor PPN atas pembelian jasa AI dari luar negeri. Ini adalah realitas yang sering dilupakan dalam kalkulasi biaya API "murah" — PPN 11% + PPh 22 = tambahan hingga 30% dari harga yang tertera di website provider.

Profil: Startup AI tahap awal di Bandung. 3 co-founder (2 engineer, 1 product). Mereka sedang mengembangkan AI writing assistant untuk penulis artikel Bahasa Indonesia. Token usage: ~20 juta token per bulan (80% output, 20% input), dengan traffic yang masih naik 10-20% per bulan. Budget operasional sangat terbatas — mereka masih bootstrapped dengan angel investment Rp 500 juta.

Opsi A: API Model Kecil (GPT-4o-mini / Gemini Flash)

Total opsi API: ~Rp 200.000/bulan. Sangat murah. Tapi startup ini perlu meningkatkan kualitas output secara kontinu — suatu saat mereka mungkin perlu upgrade ke model yang lebih besar.

Opsi B: On-Premise (PC dengan RTX 4090)

Total opsi on-premise: Capex Rp 55 juta + opex Rp 1,2 juta/bulan + opportunity cost Rp 8 juta.

Break-Even Analysis untuk Startup Ini

Analisis untuk startup kecil: Dengan 20 juta token/bulan, biaya API GPT-4o-mini hanya Rp 200.000/bulan. On-premise dengan RTX 4090 membutuhkan Rp 55 juta di awal + Rp 1,2 juta/bulan. Bahkan setelah 3 tahun, API total hanya Rp 7,2 juta vs on-prem Rp 106,2 juta. Untuk startup kecil dengan token usage rendah, API adalah pemenang mutlak. Tidak ada argumen teknis yang membenarkan pembelian GPU — kecuali jika startup tersebut butuh: (1) privasi data penuh (data pengguna tidak boleh ke server AS), (2) model spesifik yang tidak tersedia di API, atau (3) latensi sangat rendah untuk real-time application. Saran saya: nikmati API murah dulu, fokus pada product-market fit, dan beli GPU hanya saat token usage sudah mencapai 200-300 juta token/bulan (10-15× lipat dari sekarang). Saat itu, break-even on-premise akan tercapai dalam 12-18 bulan.

Skenario Alternatif: Hybrid untuk Startup

Ada kompromi menarik: startup ini menggunakan API untuk production dan PC + RTX 4090 untuk development & eksperimen. Biaya: PC Rp 55 juta (sekali) + listrik ~Rp 400rb/bulan (8 jam/hari). Untuk development, mereka bisa menjalankan model 7-12B lokal untuk rapid prototyping tanpa latency API. Untuk production, mereka tetap pakai API yang terpercaya dan scalable. Biaya total: Rp 55 juta + Rp 400rb/bulan (dev) + Rp 200rb/bulan (prod API) = Rp 55,6 juta tahun pertama + Rp 7,2 juta/tahun berikut. Pendekatan ini memberi kecepatan development lokal sekaligus reliabilitas production API.

Profil: Perusahaan retail dengan 200 toko fisik dan e-commerce di Jabodetabek, Surabaya, Medan. Mereka ingin mengganti 50 customer service manusia dengan AI agent yang menangani chat WhatsApp, chat e-commerce, dan telepon (voice-to-text-to-LLM). Estimasi token usage: ~500 juta token/bulan (70% output, 30% input), dengan beban puncak di jam 08.00-21.00 WIB (13 jam aktif, 11 jam idle). Ini adalah skenario klasik yang membuat banyak CTO Indonesia bingung: token usage besar tapi tidak 24/7.

Opsi A: API (Gemini Flash + GPT-4o-mini untuk routing)

Annual API cost: Rp 5,6 juta × 12 = Rp 67,2 juta. Belum termasuk voice-to-text (STT) yang estimasi Rp 2-3 juta/bulan tambahan.

Opsi B: On-Premise Hybrid (4× RTX 4090 untuk baseline + API burst)

Total opsi hybrid: Capex Rp 200 juta + Opex Rp 15 juta/bulan (colocation) + Rp 3 juta/bulan (API burst + internet) = Rp 18 juta/bulan + Rp 200 juta capex.

Break-Even Analysis

Temuan kunci: Full API masih lebih murah hingga tahun ke-3 (Rp 242 juta vs Rp 848 juta). Tapi perhatikan: ini karena asumsi 80% workload ditangani Gemini Flash yang super murah. Jika retail ini butuh model premium (Claude Sonnet/GPT-4o) untuk semua query — misalnya karena akurasi sangat penting untuk transaksi — biaya API melonjak ke Rp 40-80 juta/bulan. Dalam skenario itu, break-even hybrid terjadi di bulan ke-6 hingga ke-8. Kesimpulan: Untuk retail dengan model murah (Gemini Flash) dan traffic siang-hari, API masih unggul 3 tahun. Tapi jika mereka punya data sensitif pelanggan (detail transaksi, alamat, nomor telepon), on-premise memberikan nilai tambah privasi yang tidak bisa dihitung dalam rupiah. Faktor kepatuhan sering menjadi pembeda yang menentukan.

Rekomendasi untuk Retail AI Customer Service

Mulailah dengan API (Gemini Flash + routing sederhana) untuk 6 bulan pertama. Gunakan waktu itu untuk: (1) mengukur peak-to-average ratio traffic, (2) mengidentifikasi pola query yang butuh model lebih besar, (3) mengumpulkan data token usage per jam yang akurat. Setelah 6 bulan, jika token usage sudah >300 juta/bulan dan Anda punya data dukung untuk sizing, baru pertimbangkan on-premise. Sementara itu, siapkan infrastruktur colocation (nego sewa rak) agar ketika keputusan on-prem diambil, Anda tinggal pasang server tanpa harus menunggu ketersediaan rak data center yang di Jakarta bisa memakan waktu 2-4 minggu.

Profil: BUMN sektor infrastruktur dengan 25.000 pegawai, akan meluncurkan AI assistant internal untuk 1000+ concurrent user. Layanan: menjawab pertanyaan kebijakan internal, membantu analisis dokumen tender, dan menyusun laporan kinerja. Karena UU PDP (Undang-Undang Perlindungan Data Pribadi) Nomor 27 Tahun 2022, data pegawai dan dokumen tender TIDAK BOLEH dikirim ke server di luar Indonesia. Semua inferensi harus dilakukan di dalam negeri, dan idealnya di data center milik BUMN sendiri atau BUMN lain yang terpercaya. Hanya on-premise (atau colocation di BUMN telekomunikasi) yang memenuhi syarat. API luar negeri seperti OpenAI atau Anthropic — bahkan jika menjanjikan data privacy — secara hukum tidak bisa dipertanggungjawabkan jika ada kebocoran data.

Persyaratan Infrastruktur

Untuk melayani 1000+ concurrent user dengan model 70B Q4 (atau lebih besar untuk presisi dokumen hukum), diperlukan cluster yang cukup besar. Asumsi: model Llama 3 70B di Q4_K_M (~40GB VRAM), dengan continuous batching di vLLM, satu H100 80GB bisa melayani 20-30 concurrent user. Untuk 1000 user: ~35-50 H100. Dengan buffer N+1 (50 H100) dan tensor parallelism 8 per node: dibutuhkan 7 node DGX H100 (8× H100 per node). Total 56 H100.

Operational Cost per Tahun

Perbandingan dengan API Enterprise (Jika Memungkinkan)

Jika UU PDP tidak menjadi kendala (hipotetis), berapa biaya API untuk volume yang sama? 1000 concurrent user × 500 token/response × 10 response/jam × 13 jam aktif = 65 juta token/hari = ~1,95 miliar token/bulan. Dengan GPT-4o-mini: 1,95 miliar × Rp 11.000/1jt = Rp 21,45 miliar/bulan — langsung melebihi opex tahunan on-premise (Rp 21,8 miliar). Dengan Claude Haiku: Rp 142,9 miliar/bulan. Untuk skala BUMN 1000+ user, on-premise bukan hanya kepatuhan — ini juga jauh lebih murah. TCO 5 tahun on-premise: capex Rp 115 miliar + opex 5 tahun Rp 116,5 miliar = Rp 231,5 miliar. API setara dalam 5 tahun: Rp 1,3 triliun (GPT-4o-mini) hingga Rp 8,6 triliun (Claude Haiku). Hemat: Rp 1-8 triliun.

Catatan untuk BUMN: Proses pengadaan GPU di BUMN Indonesia biasanya memakan waktu 6-12 bulan (dari penyusunan spek hingga barang datang + instalasi). Mulailah proses pengadaan sekarang — jangan tunggu sampai aplikasi AI sudah siap. Sementara itu, Anda bisa menggunakan API dari penyedia lokal (Neural, Aksara AI, atau Telkom AI) yang infrastrukturnya di Indonesia dan sudah comply dengan UU PDP sebagai solusi sementara. Pastikan arsitektur aplikasi Anda mendukung hot-switch antara API (sementara) ke on-premise (permanen) dengan mengubah satu baris endpoint URL.

Berikut adalah tabel break-even point untuk berbagai skenario Indonesia yang umum, dihitung dengan asumsi kurs Rp 16.500/USD, PPN 11%, dan tarif listrik industri Rp 1.200/kWh untuk skala besar dan Rp 1.500/kWh untuk skala kecil-menengah.

Pola yang terlihat jelas: Break-even on-premise sangat tergantung pada tiga variabel: (1) harga API per token — model premium (GPT-4o, Claude Sonnet) memberikan break-even dalam hitungan bulan, sementara model murah (Gemini Flash, GPT-4o-mini) bisa membuat on-premise tidak pernah balik modal; (2) total token per bulan — semakin banyak token, semakin cepat break-even; dan (3) efisiensi GPU — GPU data center (A100, H100) lebih mahal tapi memberikan throughput per watt yang lebih baik. Aturan praktis: Jika Anda menggunakan model murah (Gemini Flash / GPT-4o-mini), jangan beli GPU kecuali token usage >500 juta/bulan. Jika Anda menggunakan model premium (Claude Sonnet / GPT-4o / GPT-4.1), GPU sudah break-even dalam 1-8 bulan pada hampir semua skala. Intinya: model yang Anda pilih 10× lebih menentukan daripada volume token dalam perhitungan break-even.

BE (bulan) = Total Capex / (Biaya API per bulan - Biaya Opex per bulan)

Contoh:
- Capex: Rp 200 juta (server + 4× RTX 4090 + colocation setup)
- Biaya API bulanan: Rp 137 juta (Claude Sonnet, 500jt token)
- Biaya Opex bulanan on-prem: Rp 15 juta (colocation + listrik)
- BE = 200 / (137 - 15) = 200 / 122 = 1,6 bulan

Contoh 2:
- Capex: Rp 115 miliar (56× H100 + DC setup)
- Biaya API bulanan: Rp 22 miliar (GPT-4o-mini, lokal gateway)
- Biaya Opex bulanan: Rp 2 miliar (listrik + cooling + staff + DC)
- BE = 115.000 / (22.000 - 2.000) = 115.000 / 20.000 = 5,75 bulan

Angka token per detik (tok/s) sering sulit dibayangkan secara intuitif. Untuk membantu memvisualisasikan perbedaan kecepatan antara berbagai metode inference, mari gunakan analogi transportasi yang akrab bagi orang Indonesia — dari yang paling lambat hingga tercepat.

Skala Waktu — Analogi Perjalanan Nyata

Bayangkan Anda harus menuliskan 1 halaman penuh konten (1000 token) dari AI. Berikut perbandingan waktu tunggunya dalam analogi perjalanan:

Inti analogi: Jangan pernah membandingkan CPU inference (angkot) dengan API (jet tempur) secara langsung. Setiap metode punya use case-nya sendiri. CPU cocok untuk background batch processing yang tidak real-time — seperti ngirim paket lewat ekspedisi reguler. GPU lokal seperti kereta api jarak jauh — lebih cepat dari bus, tapi perlu modal beli tiket (GPU). API adalah pesawat — sangat cepat, tapi Anda bayar per penerbangan. Pilih berdasarkan prioritas Anda: biaya per token (harga tiket), kecepatan (waktu tempuh), atau privasi (siapa yang lihat barang bawaan Anda).

Setelah membaca semua perbandingan di atas, Anda mungkin menyadari bahwa tidak ada solusi tunggal yang sempurna untuk semua skenario. Jawabannya seringkali adalah hibrida: menggunakan on-premise (atau colocation) untuk menangani beban baseline yang stabil dan API untuk menangani lonjakan (burst) traffic. Ini menggabungkan biaya per token rendah dari on-premise dengan elastisitas API.

Arsitektur Hibrida Klasik

┌─────────────┐     ┌──────────────────┐     ┌──────────────┐
│  User Request │────▶│  Load Balancer   │────▶│  Inference   │
│  (1000/s)     │     │  (LiteLLM / Nginx)│     │  Router      │
└─────────────┘     └──────┬───────────┘     └──────┬───────┘
                           │                        │
                    ┌──────┴──────┐         ┌───────┴────────┐
                    │ Queue Size  │         │  Routing Logic │
                    │ (Redis)     │         │                │
                    └──────┬──────┘         │ < 200 queue →  │
                           │                │   On-Premise   │
                           │                │ > 200 queue →  │
                           │                │   API fallback │
                           │                └───────┬────────┘
                    ┌──────┴──────┐         ┌───────┴────────┐
                    │ On-Premise  │         │  API Providers │
                    │ Cluster     │         │  (OpenAI, etc) │
                    │ (4× A100)   │         │  (pay-per-use) │
                    └─────────────┘         └────────────────┘

Implementasi Routing Hibrida

Framework seperti LiteLLM atau OpenRouter memudahkan implementasi hibrida. Anda cukup mendefinisikan beberapa "model provider" dan aturan routing-nya. Contoh konfigurasi LiteLLM untuk hibrida:

# config.yaml — LiteLLM Hybrid Routing
model_list:
  - model_name: "baseline-model"
    litellm_params:
      model: "openai/llama-3-8b-instruct"
      api_base: "http://onprem-server:8000/v1"  # On-premise
    model_info:
      tier: "baseline"
      max_queue: 200

  - model_name: "burst-model"
    litellm_params:
      model: "gpt-4o-mini"  # API fallback
      api_key: "sk-xxx"
    model_info:
      tier: "burst"

router_settings:
  routing_strategy: "latency-based-routing"
  enable_queue: true
  redis_host: "localhost"
  fallback_strategy: "if queue > 200, route to burst-model"

Tiga Skenario Hibrida untuk Indonesia

Skenario 1: Startup ke Menengah (2-4 GPU baseline + API burst). Perusahaan dengan pertumbuhan traffic 10-20%/bulan. Baseline: 2× RTX 4090 di colocation untuk menangani 200-300 user average. Burst: API Gemini Flash/GPT-4o-mini saat ada lonjakan (campaign, promo, akhir bulan). Rasio baseline:burst = 70:30. Hemat: 40-50% dibandingkan full API.

Skenario 2: Perusahaan Retail (4-8 GPU baseline + API premium). Customer service AI 24/7. Baseline siang hari: 4× A100 di colocation menangani 80% traffic. Burst: saat jam sibuk (10.00-14.00 & 19.00-21.00), route 20% traffic paling kompleks ke Claude Sonnet/GPT-4o via API. Biaya: baseline ~Rp 60 juta/bulan (opex colocation), burst ~Rp 10-20 juta/bulan. Total vs Full API: Rp 70-80 juta vs Rp 100-150 juta. Hemat: 30-50%.

Skenario 3: BUMN (Baseline besar + API lokal untuk overflow). Cluster H100 on-premise untuk 95% traffic. API dari penyedia lokal Indonesia (yang comply UU PDP) untuk overflow 5% di saat peak. Ini memberi perlindungan kapasitas tanpa harus membeli GPU tambahan (yang proses pengadaannya 6-12 bulan) hanya untuk mengantisipasi lonjakan yang mungkin hanya terjadi 5-10 hari dalam setahun.

Matriks Keputusan Hibrida

Praktik terbaik hibrida: Bangun abstraksi API endpoint di aplikasi Anda sejak hari pertama — jangan hardcode endpoint OpenAI. Gunakan library yang kompatibel dengan OpenAI API format (seperti vLLM, LiteLLM, atau LocalAI). Dengan cara ini, Anda bisa mengganti backend inference hanya dengan mengubah URL base dan API key, tanpa mengubah kode aplikasi. Saya pernah membantu startup yang migrasi dari full API ke hybrid dalam satu hari hanya karena mereka sudah menggunakan OpenAI-compatible endpoint dari awal. Jika tidak, migrasi bisa memakan waktu berminggu-minggu karena harus rewrite semua kode integrasi.