Mengukur Latensi Sebelum Membakar Budget: Mengapa Tools Seperti Llmspeed Krusial bagi Hardware Sizing
Banyak tim engineering melakukan kesalahan mendasar saat merencanakan infrastruktur inferensi lokal: mereka menyamakan spesifikasi TFLOPS kartu grafis dengan kecepatan generasi token. Hasilnya adalah over-budget pada hardware enterprise yang utilisasinya rendah, atau sebaliknya, terjebak dengan rig workstation yang menghasilkan throughput tidak memadai untuk kebutuhan produksi.
Kemunculan proyek seperti Llmspeed (llmspeed.dev) yang baru-baru ini ramai diperdebatkan di Hacker News menyoroti kesenjangan besar antara lembar spesifikasi vendor dan performa aktual inferensi Large Language Models (LLM). Utilitas ini memungkinkan engineer merasakan latensi nyata (Time to First Token/TTFT dan throughput token per detik) dari berbagai kombinasi model, kuantisasi, dan hardware target langsung di browser sebelum menandatangani pengadaan bernilai ribuan dolar.
Bagi tim teknis, utilitas semacam ini bukan sekadar demo interaktif biasa. Ini adalah simulasi berbasis data yang mengekspos karakteristik mekanis inferensi LLM: dominasi memory bandwidth di atas raw compute.
---
Mekanisme di Balik Layar: Batasan Autoregressive Decoding
Mengapa simulator inferensi bisa dipetakan secara akurat tanpa harus menjalankan model secara penuh di client? Jawabannya terletak pada sifat mekanis inferensi autoregresif itu sendiri.
Inferensi LLM terbagi menjadi dua fase dengan profil beban kerja yang bertolak belakang:
1. Fase Prefill (Prompt Processing)
Fase ini bersifat compute-bound. GPU memproses seluruh token input secara paralel menggunakan operasi matrix-matrix multiplication (GEMM). Di fase ini, raw compute (TFLOPS) dan kapasitas Tensor Core memegang peranan krusial dalam menentukan Time to First Token (TTFT).
2. Fase Decoding (Token Generation)
Fase ini hampir murni bersifat memory-bandwidth bound. Karena model menghasilkan token satu per satu, setiap forward pass mengharuskan sistem membaca miliaran parameter dari memory (VRAM) ke register prosesor hanya untuk menghasilkan satu token baru.
Hubungan matematis kasarnya sangat sederhana:
Throughput Maksimal (token/detik) ≈ frac{Memory Bandwidth (GB/s)}{Ukuran Model Aktif (GB)}
Sebagai contoh:
- Model Llama-3-8B dengan kuantisasi 4-bit (sekitar 5.5 GB di memory).
- Dijalankan pada NVIDIA RTX 4090 dengan memory bandwidth teoritis sekitar 1.008 GB/s.
- Secara teori batas throughput maksimalnya berada di kisaran 180 token/detik (sebelum menghitung overhead sistem, KV cache access, dan kernel latency).
- Jika model yang sama dijalankan pada Apple Silicon M3 Max (300 atau 400 GB/s bandwidth), throughput akan berada di kisaran 50 hingga 70 token/detik.
- Namun jika dijalankan pada chip CPU desktop standar dengan DDR5 dual-channel (bandwidth sekitar 60-80 GB/s), throughput akan jatuh ke level 10 hingga 14 token/detik.
Llmspeed memanfaatkan metrik empiris yang ditarik dari backend runtime populer seperti llama.cpp, vLLM, atau ExLlamaV2. Simulator ini memetakan footprint model terkuantisasi, alokasi KV cache per context-length, dan batasan bandwidth dari hardware target, lalu memutar pacing output token di antarmuka web sesuai kurva distribusi latensi tersebut.
---
Analisis Trade-off: Menghitung Biaya vs Kompleksitas
Sebelum membeli rig fisik untuk deployment on-premise atau edge, ada trade-off arsitektural yang tidak tercantum dalam benchmark sintetis:
Apple Silicon vs Discrete GPUs (NVIDIA)
Apple Silicon menawarkan unified memory architecture (UMA) hingga 128 GB atau 192 GB pada varian Mac Studio M2/M3 Ultra. Ini adalah rute termurah untuk memuat model parameter besar (seperti 70B atau Qwen-72B) ke dalam satu node memory tanpa kompresi ekstrem.
Namun kelemahannya jelas: UMA Apple memiliki memory bandwidth yang mentok di 800 GB/s (pada tier Ultra tertinggi), dan compute core-nya lambat untuk operasi prefill paralel. Rig ini ideal untuk single-user interactive use case, tetapi hancur jika dihantam concurrent batch processing di production.
Sebaliknya, ekosistem NVIDIA (RTX 4090 atau tier enterprise A100/H100) unggul telak pada konkurensi dan software ecosystem (CUDA, PagedAttention, TensorRT-LLM), namun engineer menghadapi VRAM wall. Membagi model 70B ke beberapa GPU consumer memerlukan interkoneksi PCIe yang lambat tanpa NVLink, memperkenalkan transfer overhead yang langsung memangkas performa inferensi.
Kuantisasi: Kecepatan vs Degradasi Performa
Mengompresi model dari FP16 ke INT4 atau INT2 menghemat footprint VRAM secara dramatis dan meningkatkan throughput memory bus. Namun, kuantisasi ekstrem merusak representasi internal model pada task logika tingkat tinggi atau penulisan kode.
Dalam arsitektur produksi, memilih ukuran hardware yang memaksa penggunaan kuantisasi agresif (misalnya EXL2 2.5-bit demi muat di satu RTX 3090) seringkali merupakan optimasi prematur yang mengorbankan akurasi tugas bisnis.
Skalabilitas KV Cache
Banyak engineer menghitung kapasitas hardware hanya berdasarkan parameter weight. Padahal, kebutuhan context window yang panjang (misalnya 32k hingga 128k context) memakan VRAM secara linear berdasarkan jumlah concurrent users.
Jika hardware dibeli tanpa buffer VRAM untuk KV cache, performa akan drop drastis ketika context window terisi penuh karena sistem terpaksa melakukan CPU offloading atau context truncation.
---
Takeaways Konkret untuk Tim Engineer
- Jadikan Memory Bandwidth Metrik Utama, Bukan Clock Speed:
Saat sizing hardware untuk low-concurrency autoregressive generation (seperti internal coding assistant atau agent processing), abaikan perdebatan core clock. Prioritaskan hardware dengan bus memory terlebar dan bandwidth tertinggi per dolar yang dapat dibeli.
- Gunakan Metrik Pengalaman Pengguna Nyata:
Mata manusia membaca pada kecepatan rata-rata 5 sampai 8 kata per detik (sekitar 7 sampai 11 token per detik). Untuk kebutuhan interactive UI, hardware yang menghasilkan 20-30 token/detik sudah masuk kategori memuaskan. Mengejar 100+ token/detik untuk use-case single-user adalah pemborosan modal, kecuali sistem tersebut melayani streaming backend untuk downstream summarization atau batch workers.
- Simulasikan Sebelum Procurement:
Gunakan tools seperti Llmspeed untuk menetapkan batas minimum ekspektasi performa di level stakeholder. Jangan biarkan tim operasional menghabiskan budget modal puluhan juta rupiah hanya untuk mendapati bahwa model 70B yang mereka butuhkan berjalan di kecepatan 4 token per detik akibat keterbatasan PCIe bus di workstation rakitan.
- Validasi Batas Konkurensi:
Jika arsitektur target adalah production endpoint yang melayani lebih dari 5 request simultan, tinggalkan benchmark inferensi single-token desktop. Fokuskan sizing pada throughput prefill, dukungan FP8/FP16 native, dan efisiensi penanganan continuous batching pada platform GPU enterprise.
