Cara Benchmark Server LLM: Mengukur Latency, Throughput,
September 6, 2026
- Srengseng Sawah, Jagakarsa Jakarta Selatan
- Sen - Jum: 07:00 -17:00WIB
Cara menghindari CUDA Out of Memory saat menjalankan model AI menjadi penting ketika perusahaan mulai menggunakan GPU server untuk Large Language Model (LLM), deep learning, computer vision, maupun aplikasi generative AI. Error ini sering muncul ketika model tidak dapat dimuat, proses training berhenti di tengah jalan, atau chatbot mengalami kegagalan saat menerima banyak permintaan. Meskipun terlihat seperti masalah kapasitas GPU, penyebabnya tidak selalu sesederhana VRAM yang terlalu kecil.
CUDA Out of Memory dapat terjadi karena ukuran model, batch size, panjang context, penggunaan memory oleh proses lain, hingga cara framework mengelola alokasi GPU. Pada beberapa kasus, model sebenarnya dapat dijalankan setelah konfigurasi software dioptimalkan tanpa harus mengganti hardware. Namun, jika kebutuhan memory memang melebihi kapasitas perangkat, perusahaan perlu mempertimbangkan GPU dengan VRAM lebih besar atau arsitektur multi-GPU yang sesuai.
Artikel ini membahas penyebab CUDA Out of Memory, cara membaca penggunaan VRAM, langkah optimasi untuk training dan inference, serta kapan upgrade GPU server mulai diperlukan. Dengan memahami akar masalahnya, perusahaan dapat menghindari solusi sementara yang tidak menyelesaikan bottleneck sebenarnya.
CUDA Out of Memory atau CUDA OOM adalah kondisi ketika aplikasi tidak dapat memperoleh alokasi memory GPU yang dibutuhkan untuk menjalankan proses komputasi. Error ini sering ditemukan pada framework seperti PyTorch ketika model, tensor, activation, atau data tambahan membutuhkan ruang yang melebihi kapasitas memory yang tersedia. Akibatnya, proses dapat berhenti dan menampilkan pesan seperti RuntimeError: CUDA out of memory.
Sebagai contoh, sebuah GPU mempunyai kapasitas VRAM 24 GB, tetapi sebagian besar memory sudah digunakan oleh model dan proses lain. Ketika aplikasi membutuhkan alokasi tambahan untuk memproses input baru, kapasitas yang tersisa mungkin tidak mencukupi. Kondisi tersebut dapat menyebabkan error meskipun model sebelumnya berhasil dimuat dan digunakan.
Namun, CUDA OOM tidak selalu berarti seluruh VRAM benar-benar habis. Framework dapat mengelola memory melalui caching allocator, sementara alokasi yang terfragmentasi atau tensor yang masih mempunyai referensi juga dapat memengaruhi ketersediaan memory. Karena itu, langkah pertama sebaiknya adalah membaca kondisi penggunaan GPU sebelum mengubah konfigurasi secara acak.
Penyebab CUDA OOM berbeda antara training dan inference, tetapi keduanya berkaitan dengan kebutuhan memory yang berubah selama workload berjalan. Model yang berhasil dimuat belum tentu mempunyai ruang cukup untuk memproses batch berikutnya, menyimpan activation, atau menangani request tambahan. Beberapa faktor berikut merupakan penyebab yang paling sering perlu diperiksa.
Model AI mempunyai kebutuhan memory yang dipengaruhi oleh jumlah parameter dan format precision yang digunakan. Model 8B pada FP16, misalnya, membutuhkan sekitar 16 GB hanya untuk bobotnya, belum termasuk cache dan alokasi runtime. Jika GPU mempunyai VRAM 16 GB, kapasitas tersebut belum tentu cukup untuk menjalankan model dengan konfigurasi tersebut secara stabil.
Quantization dapat mengurangi kebutuhan memory bobot, tetapi tidak menghilangkan seluruh kebutuhan tambahan. Model tetap membutuhkan ruang untuk proses komputasi, context, dan komponen lain yang digunakan oleh inference engine. Karena itu, ukuran file model tidak boleh dianggap sebagai kebutuhan VRAM akhir.
Batch size menentukan jumlah data yang diproses dalam satu langkah komputasi. Pada training, batch yang lebih besar dapat meningkatkan kebutuhan activation dan memory sementara yang harus disimpan selama forward maupun backward pass. Jika kapasitas GPU tidak mencukupi, proses dapat mengalami OOM meskipun model yang sama berhasil dijalankan menggunakan batch lebih kecil.
Pada LLM inference, panjang context dan jumlah pengguna bersamaan dapat meningkatkan kebutuhan KV cache. Chatbot yang berjalan normal untuk satu pengguna mungkin mengalami OOM ketika menerima banyak request dengan dokumen panjang. Kondisi ini sering terjadi ketika server hanya diuji menggunakan prompt pendek, tetapi kemudian digunakan untuk workload produksi yang jauh lebih berat.
GPU server dapat digunakan oleh beberapa aplikasi, container, atau anggota tim secara bersamaan. Jika satu proses sudah menggunakan sebagian besar VRAM, aplikasi lain mungkin tidak mempunyai ruang cukup untuk memuat model atau menjalankan inference. Karena itu, penggunaan GPU perlu dipantau sebelum menjalankan workload baru, terutama pada lingkungan server bersama.
Pada beberapa aplikasi, penggunaan memory dapat terus meningkat karena tensor atau computation graph masih disimpan oleh program. Misalnya, training loop menyimpan loss tensor ke dalam sebuah list tanpa melepaskan hubungan dengan graph komputasi. Akibatnya, memory yang seharusnya dapat digunakan kembali tetap tertahan dan proses akhirnya mengalami OOM.
Langkah pertama saat menghadapi CUDA OOM adalah memeriksa kondisi GPU secara menyeluruh. Administrator perlu mengetahui kapasitas total, memory yang sedang digunakan, proses yang aktif, serta apakah penggunaan VRAM meningkat secara bertahap atau langsung penuh ketika model dimuat. Informasi tersebut membantu membedakan masalah kapasitas hardware dari masalah konfigurasi aplikasi.
Pada server NVIDIA, pemeriksaan awal dapat dilakukan menggunakan perintah berikut:
nvidia-smiPerintah tersebut menampilkan informasi GPU, penggunaan memory, dan proses yang sedang menggunakan perangkat. Jika terdapat proses lama yang tidak lagi dibutuhkan, administrator dapat menghentikannya melalui mekanisme aplikasi atau container yang sesuai. Hindari menghentikan proses milik pengguna lain secara sembarangan karena tindakan tersebut dapat mengganggu workload yang sedang berjalan.
Untuk aplikasi PyTorch, pemeriksaan dapat dilanjutkan menggunakan statistik memory allocator. Fungsi memory_allocated() menunjukkan memory yang digunakan tensor, sedangkan memory_reserved() menunjukkan memory yang dikelola caching allocator. Perbedaan kedua angka tersebut membantu memahami mengapa penggunaan VRAM yang terlihat pada sistem tidak selalu sama dengan memory tensor yang masih aktif.
import torch
print(torch.cuda.memory_summary())Dokumentasi resmi PyTorch CUDA Memory Management menjelaskan bagaimana caching allocator bekerja, cara memantau penggunaan memory, serta berbagai pengaturan yang dapat digunakan untuk menganalisis masalah alokasi GPU. Referensi tersebut dapat menjadi dasar teknis sebelum perusahaan melakukan perubahan pada konfigurasi allocator atau framework.
Mengurangi batch size merupakan salah satu langkah paling sederhana ketika CUDA OOM terjadi selama training. Batch yang lebih kecil membuat jumlah data yang diproses dalam satu langkah berkurang, sehingga kebutuhan activation dan memory sementara juga dapat menurun. Namun, perubahan ini dapat memengaruhi throughput dan karakteristik proses training, sehingga hasilnya tetap perlu dievaluasi.
Sebagai contoh, jika training mengalami OOM pada batch size 32, perusahaan dapat mencoba menurunkannya menjadi 16, 8, atau lebih kecil sesuai kapasitas GPU. Perubahan sebaiknya dilakukan secara bertahap sambil memantau peak memory usage dan waktu training. Dengan begitu, tim dapat menemukan konfigurasi yang cukup stabil tanpa menurunkan efisiensi secara berlebihan.
Jika effective batch size tertentu tetap dibutuhkan, gradient accumulation dapat menjadi alternatif. Teknik ini mengumpulkan gradient dari beberapa langkah dengan micro-batch lebih kecil sebelum melakukan optimizer step. Pendekatan tersebut dapat mengurangi kebutuhan memory per langkah, meskipun waktu training dan pengaturan optimasinya perlu diperhatikan.
Precision mempunyai pengaruh besar terhadap kebutuhan memory model AI. Format FP32 menggunakan lebih banyak memory untuk bobot dibandingkan FP16 atau BF16, sedangkan quantization dapat mengurangi kebutuhan bobot lebih jauh melalui representasi 8-bit atau 4-bit. Namun, penghematan aktual tetap bergantung pada arsitektur model, framework, serta komponen lain yang digunakan selama proses komputasi.
Untuk inference LLM, quantization sering menjadi salah satu pendekatan yang paling efektif ketika model tidak dapat dimuat pada GPU yang tersedia. Model yang sebelumnya membutuhkan VRAM besar dapat menjadi lebih ringan setelah menggunakan format quantization yang didukung. Meski demikian, kualitas output, latency, dan kompatibilitas harus diuji sebelum digunakan pada aplikasi perusahaan.
Pada training, mixed precision juga dapat membantu mengurangi kebutuhan memory tertentu dan meningkatkan efisiensi komputasi. Namun, penggunaan FP16 atau BF16 tidak berarti seluruh kebutuhan memory otomatis berkurang setengah karena optimizer state, gradient, dan komponen lainnya tetap perlu diperhitungkan. Karena itu, konfigurasi precision harus disesuaikan dengan hardware dan metode training yang digunakan.
Untuk LLM inference, penggunaan VRAM tidak hanya ditentukan oleh bobot model. KV cache dapat meningkat seiring panjang context dan jumlah sequence yang diproses, sehingga aplikasi dengan prompt panjang membutuhkan memory lebih besar. Jika server mengalami OOM ketika banyak pengguna aktif, pengaturan context dan concurrency perlu menjadi bagian dari troubleshooting.
Perusahaan dapat membatasi panjang input, mengatur jumlah token output, serta menentukan batas request yang diproses secara bersamaan. Pada sistem RAG, jumlah dokumen yang dimasukkan ke prompt juga perlu dioptimalkan agar context tidak menjadi terlalu panjang tanpa memberikan manfaat tambahan. Pendekatan ini dapat membantu mengurangi penggunaan memory sekaligus menjaga response time.
Namun, pembatasan context tidak boleh dilakukan tanpa mempertimbangkan kebutuhan aplikasi. Context yang terlalu pendek dapat membuat model kehilangan informasi penting, terutama pada analisis dokumen atau percakapan panjang. Karena itu, perusahaan perlu mencari keseimbangan antara kualitas jawaban, kebutuhan memory, dan performa inference.
Aplikasi yang hanya menjalankan inference tidak membutuhkan computation graph untuk proses backward propagation. Karena itu, penggunaan mode inference yang sesuai dapat membantu mengurangi overhead memory dan komputasi yang tidak diperlukan. Pada PyTorch, aplikasi dapat menggunakan torch.inference_mode() ketika menjalankan model untuk prediksi.
Contoh sederhananya adalah sebagai berikut:
model.eval()
with torch.inference_mode():
output = model(**inputs)Contoh tersebut mengasumsikan model dan input sudah disiapkan sebelumnya. model.eval() mengatur perilaku layer tertentu untuk evaluasi, sedangkan torch.inference_mode() menonaktifkan pencatatan autograd yang tidak diperlukan pada proses inference. Keduanya mempunyai fungsi berbeda dan sebaiknya digunakan sesuai kebutuhan aplikasi.
Gradient checkpointing merupakan teknik yang dapat membantu mengurangi penggunaan memory selama training. Alih-alih menyimpan seluruh activation yang diperlukan untuk backward pass, sistem hanya menyimpan sebagian dan menghitung ulang activation lainnya ketika dibutuhkan. Pendekatan ini menukar sebagian kemampuan komputasi tambahan dengan pengurangan kebutuhan memory.
Teknik tersebut dapat membantu ketika model sudah hampir memenuhi kapasitas VRAM, tetapi training masih membutuhkan ruang untuk activation. Namun, gradient checkpointing tidak selalu menyelesaikan seluruh masalah karena bobot model, optimizer state, dan komponen lain tetap membutuhkan memory. Waktu training juga dapat meningkat karena sebagian perhitungan harus dilakukan ulang.
Untuk fine-tuning LLM, perusahaan dapat mempertimbangkan kombinasi gradient checkpointing, gradient accumulation, dan metode seperti LoRA atau QLoRA. Kombinasi tersebut dapat membuat kebutuhan hardware lebih efisien dibandingkan full fine-tuning pada konfigurasi tertentu. Namun, pemilihan teknik tetap harus mengikuti dukungan framework dan hasil benchmark model yang digunakan.
torch.cuda.empty_cache() Bisa Mengatasi OOM?torch.cuda.empty_cache() sering disebut sebagai solusi ketika GPU mengalami CUDA Out of Memory. Fungsi ini dapat melepaskan memory cache yang tidak sedang digunakan oleh tensor aktif sehingga memory tersebut dapat tersedia bagi aplikasi GPU lain. Namun, fungsi tersebut tidak membebaskan memory yang masih digunakan oleh tensor dan tidak menambah kapasitas fisik VRAM.
Karena itu, menjalankan empty_cache() berulang kali bukan solusi utama apabila model memang membutuhkan memory lebih besar daripada kapasitas GPU. Jika memory terus meningkat akibat referensi tensor yang masih aktif, aplikasi perlu diperiksa dan objek yang tidak lagi diperlukan harus dilepaskan dengan benar. Restart proses atau kernel dapat membantu membersihkan alokasi dari proses tersebut, tetapi hanya boleh dilakukan setelah memastikan workload dan data yang sedang berjalan tidak terganggu.
Pada beberapa kasus, CUDA OOM dapat berkaitan dengan cara memory dialokasikan dan digunakan kembali oleh framework. Memory fragmentation dapat menyebabkan alokasi baru mengalami kesulitan meskipun masih terdapat memory yang belum digunakan sepenuhnya. Namun, masalah ini perlu dibedakan dari kondisi ketika seluruh kapasitas GPU memang sudah terpakai oleh model dan tensor aktif.
PyTorch menyediakan pengaturan allocator melalui environment variable PYTORCH_ALLOC_CONF, sementara nama lama PYTORCH_CUDA_ALLOC_CONF masih tersedia sebagai alias kompatibilitas. Beberapa opsi allocator dapat membantu pada pola alokasi tertentu, tetapi tidak sebaiknya digunakan sebagai solusi universal. Pengaturan perlu disesuaikan dengan versi PyTorch, backend allocator, dan hasil analisis memory yang menunjukkan masalah sebenarnya.
Jika pesan error menyarankan pengaturan tertentu, administrator sebaiknya memeriksa dokumentasi versi framework yang digunakan sebelum menerapkannya. Perubahan allocator juga perlu diuji pada lingkungan development terlebih dahulu karena dapat memengaruhi performa dan perilaku memory aplikasi. Jika masalahnya adalah model terlalu besar, pengaturan allocator tidak akan menggantikan kebutuhan VRAM tambahan.
Optimasi software mempunyai batas. Jika model tetap tidak dapat dimuat setelah menggunakan precision yang sesuai, batch size sudah dikurangi, dan proses lain sudah dibersihkan, kapasitas VRAM mungkin memang tidak mencukupi. Pada kondisi tersebut, perusahaan perlu mengevaluasi GPU dengan memory lebih besar atau konfigurasi multi-GPU yang mendukung pembagian model.
Namun, menambah GPU tidak otomatis menggabungkan seluruh VRAM menjadi satu memory pool. Dua GPU dengan VRAM masing-masing 24 GB tidak langsung menjadi satu GPU 48 GB tanpa dukungan model parallelism atau metode pembagian lainnya. Karena itu, pemilihan multi-GPU harus mempertimbangkan framework, interconnect, serta kemampuan server dalam mendukung konfigurasi tersebut.
Perusahaan yang sedang menentukan kebutuhan hardware dapat melihat solusi GPU Server Indonesia dari Sparta Server Indonesia. Konfigurasi GPU, CPU, RAM, storage, dan networking dapat disesuaikan dengan workload AI yang akan dijalankan, termasuk kebutuhan model besar dan penggunaan multi-GPU.
Walaupun CUDA OOM berkaitan langsung dengan memory GPU, komponen server lainnya tetap perlu diperhatikan. RAM yang cukup membantu proses loading model, preprocessing data, dan penggunaan CPU offloading pada konfigurasi tertentu. Namun, RAM tidak dapat menggantikan VRAM secara langsung karena bandwidth dan latency akses memory berbeda.
Storage juga mempunyai peran penting dalam menyimpan model, dataset, checkpoint, serta hasil eksperimen. NVMe dapat membantu mempercepat proses loading dan pipeline data, tetapi storage yang lebih cepat tidak otomatis menyelesaikan OOM apabila kebutuhan memory GPU tetap melebihi kapasitas. Karena itu, perusahaan perlu membedakan bottleneck storage, RAM, dan VRAM sebelum menentukan upgrade.
Untuk perencanaan yang lebih menyeluruh, perusahaan dapat melihat solusi Core Server & Infrastruktur Sparta Server Indonesia. Pendekatan ini membantu memastikan GPU server didukung CPU, RAM, storage, networking, power supply, dan cooling yang sesuai dengan kebutuhan operasional.
Mencegah CUDA OOM lebih baik daripada hanya memperbaikinya setelah aplikasi berhenti. Perusahaan perlu melakukan benchmark menggunakan workload yang mendekati kondisi produksi, termasuk prompt panjang, jumlah pengguna bersamaan, dan ukuran batch tertinggi yang diperkirakan. Pengujian tersebut membantu menemukan peak memory usage sebelum sistem digunakan secara luas.
Selain itu, monitoring GPU perlu dilakukan secara berkelanjutan agar peningkatan penggunaan VRAM dapat terdeteksi lebih awal. Tim IT dapat mengatur batas concurrency, membatasi resource setiap aplikasi, serta menerapkan mekanisme antrean atau penolakan request ketika kapasitas server sudah mencapai batas aman. Pendekatan ini membantu menjaga layanan tetap stabil ketika terjadi lonjakan penggunaan.
Untuk kebutuhan menjalankan model bahasa secara lokal, perusahaan juga dapat membaca artikel Server untuk Menjalankan LLM Lokal. Pembahasan tersebut membantu memahami hubungan antara ukuran model, GPU, RAM, storage, dan kebutuhan pengguna sebelum menentukan konfigurasi produksi.
CUDA Out of Memory merupakan salah satu masalah yang cukup umum ketika menjalankan model AI, terutama pada workload dengan kebutuhan memory tinggi. Penyebabnya dapat berasal dari kapasitas VRAM yang tidak mencukupi, batch size, context length, penggunaan GPU oleh proses lain, maupun cara aplikasi mengelola memory. Karena itu, solusi terbaik harus dimulai dari pemeriksaan kondisi GPU dan pengukuran kebutuhan workload yang sebenarnya.
Optimasi seperti quantization, pengurangan batch size, gradient checkpointing, dan pengaturan concurrency dapat membantu mengurangi penggunaan memory pada kondisi tertentu. Namun, jika kebutuhan model tetap melebihi kapasitas hardware, perusahaan perlu mempertimbangkan GPU dengan VRAM lebih besar atau konfigurasi multi-GPU yang sesuai. Keputusan upgrade sebaiknya didasarkan pada benchmark agar investasi server tidak berlebihan tetapi tetap mampu memenuhi kebutuhan produksi.
Sparta Server Indonesia menyediakan solusi GPU Server dan AI Server untuk kebutuhan perusahaan, mulai dari perencanaan hardware hingga instalasi dan konfigurasi environment AI. Melalui Jasa Instalasi Server AI, perusahaan dapat memperoleh dukungan dalam menyiapkan infrastruktur yang sesuai dengan model, framework, dan workload yang akan dijalankan. Konsultasikan kebutuhan melalui Sparta Server Indonesia agar konfigurasi GPU, VRAM, RAM, storage, dan komponen pendukung dapat dirancang secara menyeluruh. WhatsApp kami +62 878‑2224‑1000
Kondisi ini dapat terjadi apabila penggunaan memory meningkat secara bertahap selama training. Salah satu penyebabnya adalah tensor atau computation graph yang terus disimpan tanpa dilepaskan, misalnya ketika loss tensor dikumpulkan untuk pencatatan statistik. Tim perlu memeriksa training loop dan membandingkan penggunaan memory pada setiap epoch untuk mengetahui apakah terdapat pola peningkatan yang tidak wajar.
Tidak. CUDA OOM umumnya menunjukkan bahwa aplikasi tidak memperoleh alokasi memory yang dibutuhkan, bukan berarti GPU mengalami kerusakan fisik. Namun, jika error disertai masalah driver, GPU tidak terdeteksi, atau gangguan hardware lainnya, administrator perlu melakukan pemeriksaan lebih lanjut untuk membedakan masalah software dari kerusakan perangkat.
Tidak secara langsung. Swap merupakan mekanisme memory virtual pada sistem operasi dan bukan tambahan VRAM fisik pada GPU. Beberapa framework mendukung CPU offloading atau mekanisme memory tertentu, tetapi penggunaannya harus dikonfigurasi secara khusus dan dapat menyebabkan performa menurun akibat perpindahan data antara CPU dan GPU.
nvidia-smi dan PyTorch?Perbedaan tersebut dapat terjadi karena PyTorch menggunakan caching allocator untuk mengelola memory GPU. Selain memory yang digunakan tensor aktif, framework dapat menyimpan memory yang sudah dialokasikan agar dapat digunakan kembali dengan lebih efisien. Karena itu, statistik memory_allocated() dan memory_reserved() perlu dibaca bersama informasi penggunaan GPU dari sistem.
Tidak selalu, terutama jika workload dan jumlah pengguna dapat berubah secara dinamis. Namun, risikonya dapat dikurangi melalui capacity planning, pembatasan concurrency, monitoring VRAM, pengaturan resource, dan pengujian beban sebelum deployment. Perusahaan juga dapat menyiapkan mekanisme recovery agar satu request yang gagal tidak selalu menyebabkan seluruh layanan AI berhenti.