Berapa GPU yang dibutuhkan untuk serving LLM?
Serving large language model (LLM) berarti menjawab banyak pengguna sekaligus dalam batas target latency: berapa lama sampai token pertama jawaban muncul (time to first token), dan berapa lama tiap token berikutnya (time per output token). Jumlah GPU yang dibutuhkan ditentukan oleh tiga hal: kebutuhan memori tiap request, lama tiap forward pass, dan jumlah request yang datang per detik.
Studi kasus ini merencanakan deployment model chat 7 miliar parameter dari prinsip dasar. Setiap angka dihitung dari bentuk model dan GPU ilustratif berkapasitas 80 GB dengan bandwidth memori 2 TB/s dan komputasi 300 TFLOP/s, akselerator yang sama dengan penjelasan KV cache dan continuous batching. Tiap forward pass butuh waktu sebesar mana pun yang lebih lambat: aritmetikanya, atau pembacaan byte-nya dari memori. Inilah model roofline.
Ide utama
- Weight dimuat sekali per GPU, tetapi tiap request menyimpan KV cache-nya sendiri, jadi memori cache yang menentukan jumlah pengguna yang bisa dilayani satu GPU.
- Prefill dibatasi komputasi dan menentukan time to first token; decode dibatasi memori dan menentukan time per output token.
- Batching membagi setiap pembacaan weight ke banyak request, sehingga throughput naik, sementara waktu per token tiap pengguna naik perlahan.
- Batch terbaik adalah yang terbesar yang muat di memori dan menjaga waktu per token di bawah target.
- Hukum Little mengubah laju request dan latency menjadi jumlah request yang sedang berjalan, yang harus ditampung armada GPU sekaligus.
- Saat pembacaan cache mendominasi langkah decode, mengecilkan cache (GQA, cache int8, konteks lebih pendek) menghemat lebih banyak GPU daripada mengecilkan weight.
Pertanyaan umum
Kenapa model 7B butuh lebih dari satu GPU kalau muat di 13,5 GB?
Weight mudah dimuat, tetapi melayani banyak pengguna sekaligus dibatasi oleh KV cache dan waktu. Dengan prompt 1.000 token dan jawaban 300 token, tiap request butuh sekitar 0,68 GB cache, jadi sekitar 85 request muat di samping weight pada GPU 80 GB. Tiap GPU lalu menjawab sekitar 6 request per detik dengan target 50 ms per token, sehingga 50 request per detik butuh sekitar 11 GPU termasuk headroom untuk lonjakan.
Apa bedanya time to first token dan time per output token?
Time to first token adalah lama pengguna menunggu sampai jawaban mulai muncul. Waktu ini didominasi prefill, yaitu satu pass atas seluruh prompt. Time per output token adalah jarak antar-token berikutnya, yang ditentukan oleh satu pass decode atas batch saat itu. Pengguna merasakan yang pertama sebagai jeda dan yang kedua sebagai kecepatan baca.
Seberapa akurat angka ini untuk deployment sungguhan?
Angka ini menunjukkan cara deployment membesar, bukan angka pasti untuk vendor mana pun. Model ini mengasumsikan roofline ideal (bisa diatur di Asumsi), antrean request kosong, dan prefill yang tidak menahan decode. Server sungguhan hanya mencapai sebagian dari puncaknya, jadi ukur perangkat kerasmu sendiri dan pakai perencana ini untuk melihat perubahan mana yang paling berpengaruh.
Kenapa quantization int4 kurang membantu dibanding grouped-query attention di sini?
Pada kebutuhan bawaan, satu langkah decode dengan batch terpilih membaca sekitar 13,5 GB weight, tetapi sekitar 51 GB KV cache, jadi cache yang mendominasi. int4 hanya mengecilkan weight, dari 13,5 GB menjadi 3,4 GB. GQA dengan 8 KV head memangkas cache empat kali, jadi tiap langkah membaca jauh lebih sedikit dan GPU bisa menampung request empat kali lebih banyak.
Penjelasan terkait
- KV Cache · Kenapa LLM menyimpan key dan value di cache, dan berapa biayanya
- Quantization · Mengecilkan weight model menjadi 8 dan 4 bit
- Continuous Batching · Melayani banyak request sekaligus tanpa slot menganggur
- Decoder-Only Transformer · Arsitektur di balik GPT dan LLM modern
- FlashAttention · Attention eksak dengan lalu lintas memori GPU yang jauh lebih sedikit
- Speculative Decoding · Membuat draft token dengan murah dan memverifikasinya dalam satu pass
Referensi
- Williams, Waterman, and Patterson (2009), "Roofline: An Insightful Visual Performance Model for Multicore Architectures", Communications of the ACM
- Little (1961), "A Proof for the Queuing Formula: L = λW", Operations Research
- Pope et al. (2022), "Efficiently Scaling Transformer Inference"
- Ainslie et al. (2023), "GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints"
- Touvron et al. (2023), "Llama 2: Open Foundation and Fine-Tuned Chat Models"
- Kwon et al. (2023), "Efficient Memory Management for Large Language Model Serving with PagedAttention"
Terakhir diperbarui