Memilih Ukuran Model LLM Sesuai Hardware

Belakangan ini hampir tiap developer yang saya temui punya pertanyaan yang sama: model LLM apa yang cocok dijalankan di mesin yang mereka punya? Pertanyaan ini jadi makin penting sejak makin banyak tim, termasuk saya sendiri di lingkungan sistem klinik, mulai menjalankan LLM secara lokal untuk alasan privasi data dan kontrol biaya. Masalahnya, "model besar pasti lebih pintar" itu benar, tapi ongkosnya bukan cuma soal kualitas jawaban — ada trade-off nyata di kecepatan, konsumsi memori, dan bahkan stabilitas layanan kalau dipakai untuk beban kerja produksi.

Di tulisan ini saya mau berbagi cara berpikir praktis soal memilih ukuran model LLM berdasarkan hardware yang tersedia, bukan cuma dari angka parameter di nama model.

Kenapa Ukuran Model Bukan Segalanya

Ukuran model biasanya disebut dalam jumlah parameter, misalnya 3B, 7B, atau 70B. Semakin besar jumlah parameter, secara umum semakin baik kemampuan model dalam menangkap nuansa bahasa, melakukan reasoning berlapis, dan mengikuti instruksi kompleks. Tapi ukuran ini punya konsekuensi langsung ke kebutuhan memori (VRAM atau unified memory) dan kecepatan inferensi.

Sebagai ilustrasi, model kelas 7B dengan kuantisasi 4-bit biasanya masih nyaman dijalankan di laptop dengan RAM terbatas, sementara model kelas 70B jelas butuh GPU kelas workstation atau unified memory besar seperti di lini Apple Silicon Max/Ultra. Prinsip kasarnya: makin besar model, makin besar juga jejak memori yang dibutuhkan, kira-kira sebanding dengan jumlah parameter dikali ukuran tiap bobot (tergantung level kuantisasi yang dipakai).

Memetakan Hardware ke Kelas Model

Daripada memulai dari model favorit lalu memaksakan ke hardware, saya biasanya mulai dari batasan hardware dulu:

  • Laptop/mesin dengan RAM terbatas: cocok untuk model kecil (di bawah ~7B) dengan kuantisasi agresif. Ini pas untuk tugas ringan seperti autocomplete, klasifikasi teks, atau asisten command-line.
  • Workstation dengan GPU consumer atau Apple Silicon kelas menengah-atas: bisa menangani model kelas menengah (sekitar 7B–14B) dengan kualitas jawaban yang jauh lebih stabil untuk tugas reasoning ringan-menengah.
  • Server dengan GPU kelas datacenter atau unified memory sangat besar: baru di sinilah model besar (puluhan miliar parameter ke atas) masuk akal dijalankan dengan latensi yang masih bisa diterima untuk layanan interaktif.

Kuantisasi (misalnya dari presisi 16-bit ke 4-bit) adalah alat penting di sini. Dengan kuantisasi yang tepat, model yang "seharusnya" butuh hardware kelas atas bisa jadi muat di hardware yang lebih terjangkau, meski ada trade-off kecil di akurasi.

Kecepatan vs Kualitas: Pilih Sesuai Kebutuhan Nyata

Satu kesalahan umum yang sering saya lihat: memilih model paling besar yang "bisa" dijalankan, padahal use case-nya sebenarnya tidak butuh reasoning berat. Untuk tugas seperti ekstraksi entitas, ringkasan pendek, atau klasifikasi terstruktur, model kecil-menengah sering kali sudah cukup dan jauh lebih cepat merespons — penting kalau sistemnya dipakai secara interaktif oleh banyak pengguna sekaligus.

Sebaliknya, untuk tugas yang butuh reasoning kompleks atau generasi teks yang harus sangat presisi secara medis maupun hukum, kualitas jawaban jadi prioritas, dan di situ model yang lebih besar biasanya sepadan dengan latensi tambahannya — asalkan hardware memang mendukung.

Strategi lain yang cukup efektif adalah kombinasi bertingkat: model kecil untuk menyaring atau melakukan tugas rutin, dan model besar hanya dipanggil untuk kasus yang memang butuh reasoning lebih dalam. Pendekatan ini membantu menjaga kecepatan rata-rata tetap tinggi tanpa mengorbankan kualitas di kasus-kasus penting.

Takeaway

Memilih ukuran model LLM itu soal mencocokkan tiga hal: kapasitas hardware, kebutuhan latensi, dan kompleksitas tugas — bukan sekadar mengejar model terbesar yang tersedia. Mulailah dari batasan hardware, manfaatkan kuantisasi untuk memperluas pilihan, dan jangan ragu memakai model kecil kalau tugasnya memang sederhana. Kombinasi model bertingkat sering jadi jalan tengah terbaik antara kecepatan dan kualitas.