Self-Hosting Mistral Large 4: Pelajaran dari Kesalahan

Ketika Mistral merilis bobot untuk Mistral Large 4 — model berukuran sekitar 1 triliun parameter dengan sekitar 52 miliar parameter aktif — kotak masuk saya langsung penuh dengan pertanyaan yang sama: bisakah kami menjalankannya sendiri? Self-hosting open weights kini bukan lagi fantasi hobi, melainkan opsi arsitektur yang serius, dan itu berarti banyak tim bakal membuat kesalahan mahal. Saya sudah menyaksikan beberapa di antaranya. Tulisan ini adalah versi pelajaran yang sudah dipetik: cara-cara spesifik praktisi keliru dalam self-hosting, dan seperti apa perbaikannya.

Kesalahan 1: Menganggap "Open Weights" sebagai "Bebas Dipakai Sesuka Hati"

Kesalahan pertama terjadi bahkan sebelum ada yang menyentuh GPU. Mistral Large 4 dirilis dengan lisensi bergaya MIT yang dimodifikasi, dengan pengecualian penting: jika Anda atau afiliasi Anda menjalankan bisnis model-as-a-service, Anda membutuhkan lisensi komersial terpisah dari Mistral sebelum memakai model ini secara komersial. Untuk perusahaan yang menjalankan inferensi secara internal — misalnya merangkum dokumen atau menjalankan asisten coding untuk karyawan — itu kemungkinan besar aman. Untuk startup yang berencana menjual ulang inferensi, itu berarti berhenti total sampai Anda mengirim email ke mereka.

Praktisi sering keliru ke dua arah. Ada tim yang melihat kata "open" di siaran pers lalu membangun produk komersial di atas bobot tersebut, lalu baru menyadari pembatasannya saat audit due diligence pendanaan — waktu terburuk yang mungkin. Ada juga yang terlalu berhati-hati dan mengira lisensinya melarang semua penggunaan komersial, padahal sasarannya sebenarnya adalah penyedia inferensi pesaing. Solusinya membosankan tapi wajib: minta tim legal membaca teks lisensi yang sebenarnya, bukan postingan pengumumannya. Entah Anda menyebutnya "open weights" atau "weight-available" — perbedaan istilah yang diperdebatkan komunitas dengan sengit, dan tidak sepenuhnya tanpa alasan — keputusan engineering seharusnya didasarkan pada apa yang benar-benar diizinkan oleh syarat tersebut untuk bisnis Anda.

Satu catatan lagi: pola lisensi seperti ini sekarang menjadi norma di sebagian besar rilis bobot besar, bukan pengecualian. Jika arsitektur Anda bergantung pada pergantian antara Mistral, Qwen, dan model bobot frontier lainnya, Anda butuh matriks lisensi, bukan tinjauan sekali jalan. Buat spreadsheet itu sebelum Anda membangun cluster-nya.

Kesalahan 2: Menentukan Hardware dari Halaman Pemasaran, Bukan dari Perhitungan

Ini kesalahan yang paling banyak menguras uang. Seorang engineer membaca "1T parameter", melirik empat H200 di ruang server perusahaan, lalu menyimpulkan 540 GB VRAM sudah cukup. Ternyata tidak, dan alasannya adalah aritmetika yang butuh sembilan puluh detik untuk dihitung dan bisa menghemat satu kuartal rasa malu.

Pada presisi BF16, satu triliun parameter membutuhkan sekitar 2 TB memori hanya untuk bobot. Dengan kuantisasi 8-bit, angkanya mendekati 1 TB. Pada 4-bit, sekitar 500–560 GB — belum termasuk KV cache, aktivasi, dan overhead serving. Server 540 GB hanya muat untuk model 4-bit jika Anda nyaman dengan jendela konteks pendek dan segelintir pengguna bersamaan. Arsitektur mixture-of-experts (52B parameter aktif per token) membantu komputasi per token, tetapi tidak membantu memori sama sekali: semua triliun parameter tetap harus berada di tempat yang bisa dialamati, dan pada MoE bobot expert diakses secara tidak terduga, sehingga memindahkannya ke RAM CPU menghancurkan latensi dengan cara yang tidak terjadi pada model dense.

Solusinya adalah bekerja mundur dari kebutuhan serving Anda, bukan maju dari hardware yang sudah ada. Tentukan dulu panjang konteks target, konkurensi, dan token per detik, lalu tentukan tingkat kuantisasi yang terjangkau, baru tentukan hardware-nya. Jika hasilnya delapan H200 atau sepasang node kelas NVL72, dan angka itu membuat Anda meringis, bagus — rasa meringis itu berarti model bekerja sebagaimana mestinya. Kami sudah membahas masalah terkait di apa yang harus dilakukan saat GPU kehabisan VRAM, dan opsi di sana (offloading, kuantisasi lebih kecil, model lebih kecil) semuanya berlaku di sini, hanya dalam skala datacenter.

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

Perhatikan bahwa versi tabel yang jujur menyertakan KV cache dan overhead. Versi yang tidak jujur — hanya bobot — adalah alasan tim berakhir dengan model yang bisa dimuat tetapi tidak bisa melayani lebih dari tiga pengguna.

Kesalahan 3: Menganggap Kuantisasi Sebagai Makan Siang Gratis

Begitu tim sadar mereka perlu melakukan kuantisasi, kesalahan berikutnya adalah menganggap 4-bit itu "pada dasarnya model yang sama". Kadang memang begitu. Sering kali tidak, dan mode kegagalannya justru yang paling Anda pedulikan.

Polanya yang berulang kali saya lihat: sebuah tim mengukur deployment 4-bit mereka dengan benchmark pilihan ganda gaya MMLU, melihat penurunan 1%, lalu merilisnya. Lalu pengguna produksi melaporkan bahwa refactor kode multi-file yang panjang berantakan, atau JSON untuk tool-calling rusak secara halus dengan probabilitas rendah tetapi frekuensi tinggi. Kuantisasi agresif secara tidak proporsional merugikan tugas jangka panjang, terstruktur, dan bersuhu rendah — justru beban kerja agentic dan coding yang membenarkan penggunaan model frontier sejak awal. Rata-ratanya nyaris tidak bergerak; ekornya yang runtuh.

Solusinya adalah mengkuantisasi sejauh yang task eval Anda toleransi, bukan sejauh yang dipaksa oleh VRAM. Jalankan prompt dari beban kerja Anda sendiri pada build FP8, 4-bit, dan 3-bit, lalu bandingkan. Jika 3-bit lolos evaluasi Anda, selamat, tagihan hardware Anda langsung turun separuh. Jika gagal, tidak ada rata-rata benchmark yang bisa menyelamatkan Anda. Dan utamakan rilis terkuantisasi native jika lab-nya menyediakan. Mistral merilis varian NVFP4 bersama bobot BF16, dan kuantisasi resmi dengan selisih kualitas yang terukur lebih baik daripada konversi GPTQ komunitas yang hanya Anda validasi selama satu sore.

Tingkat kuantisasi adalah anggaran kualitas, bukan pengaturan kompresi. Belanjakan di tempat beban kerja Anda masih sanggup menanggung kerugiannya.

Kesalahan 4: Membandingkan Harga API dengan Harga GPU lalu Menyebutnya Analisis TCO

Spreadsheet klasiknya: "API berharga $2,10 per juta output token, node GPU reserved berharga $X per jam, jadi self-hosting balik modal di Y token per bulan." Spreadsheet ini hampir selalu salah, dan salahnya ke arah yang mahal.

Yang terlewat: utilisasi. API memberi Anda utilisasi 100% dari kapasitas milik orang lain, ditagih per token. Cluster self-hosted Anda memberi utilisasi sesuai pola trafik Anda, dan kebanyakan beban kerja internal itu bursty — ramai di jam kerja, menganggur di malam hari, melonjak saat rilis. Cluster yang di-sizing untuk puncak akan kosong separuh hari. Lalu tambahkan biaya yang tidak pernah masuk spreadsheet: rotasi on-call untuk stack serving yang kini mencakup upgrade vLLM, ketidakcocokan driver CUDA, dan pager jam 2 pagi saat KV cache terfragmentasi; kerepotan pembaruan model (apakah Anda memvalidasi ulang setiap rilis bobot baru? suite eval Anda bilang harus); dan biaya peluang dari ML engineer yang kini jadi pengasuh GPU alih-alih membangun produk.

Ada juga masalah target yang bergerak yang tidak pernah dihitung. Mistral memangkas harga API model ini hampir separuh antara preview dan rilis penuh — input token turun dari $1,36 menjadi $0,70 per juta. Setiap kalkulasi ROI self-hosting yang dibuat berdasarkan harga lama kini tidak relevan. Inferensi frontier menjadi lebih murah secara kuartalan, sementara hardware Anda terdepresiasi dalam siklus bertahun-tahun. Ketidakseimbangan itu adalah pembunuh diam-diam bagi bisnis case self-hosting.

Solusinya: self-host hanya untuk alasan yang tidak bisa diberikan API secara struktural. Alasan-alasan itu ada dan nyata — tetapi "lebih murah dalam skala besar" jarang menjadi salah satunya pada skala tempat kebanyakan perusahaan beroperasi.

Kapan Self-Hosting Benar-Benar Menang

Jadi kapan menjalankan bobot kelas Mistral secara lokal mengalahkan API? Setelah melihat tim yang melakukannya dengan benar dan salah, kasus kemenangannya bisa dikelompokkan menjadi empat kategori:

• Residensi dan kedaulatan data. Industri yang diatur, pekerjaan yang berkaitan dengan pertahanan, dan organisasi Uni Eropa dengan kewajiban yuridiksi yang ketat. Satu kendala praktisi yang saya temui: sebuah perusahaan dilarang menggunakan model berasal dari Tiongkok karena alasan kepatuhan — bobot terbuka dari lab Eropa dengan asal-usul yang bisa diaudit memecahkan masalah yang tidak bisa diselesaikan kontrak API mana pun.
• Lingkungan air-gapped atau koneksi terputus-putus. Jika jaringan tidak bisa dipercaya untuk selalu ada, bobot lokal adalah seluruh arsitekturnya. Kami membahas pola ini dalam membangun LLM yang bisa berjalan offline.
• Beban kerja volume tinggi yang berkelanjutan dan dapat diprediksi. Pemrosesan dokumen batch yang berjalan 24/7 dengan throughput stabil benar-benar bisa mengalahkan harga per token — karena secara konstruksi ia menyelesaikan masalah utilisasi.
• Fine-tuning dan modifikasi. Anda tidak bisa melakukan fine-tuning API milik orang lain melampaui yang diizinkan endpoint fine-tuning mereka. Memiliki bobot berarti memiliki loop pelatihan: continued pretraining pada korpus domain, alignment khusus, distilasi ke deployment yang lebih kecil.

Perhatikan apa yang tidak ada di daftar: latensi. Self-hosting MoE triliunan parameter tidak memberi latensi yang lebih rendah daripada API yang disediakan dengan baik, kecuali Anda mau membelanjakan banyak untuk speculative decoding dan serving yang dioptimalkan untuk batch-1. Dan perhatikan juga apa yang tidak ada di sana: "menghindari ketergantungan pada vendor". Bobot yang Anda unduh hari ini akan tertinggal dua generasi dalam setahun, dan Anda kembali ke titik keputusan yang sama — yang, kebetulan, merupakan argumen bagus untuk naluri arsip sebagian praktisi, yaitu menyimpan salinan lokal dari rilis bobot penting. Penyimpanan itu murah; opsi itu berharga.

Cara paling jujur melihatnya: open weights dan API adalah pelengkap, bukan pesaing. Beberapa tim yang saya kenal menjalankan model hybrid: API untuk trafik interaktif yang bursty, bobot lokal untuk porsi yang diatur atau berat di batch. Keahliannya bisa dipindahkan — konfigurasi vLLM, eval harness, dan template prompt Anda berfungsi di kedua dunia. Jika Anda ingin fondasi operasionalnya sebelum berkomitmen pada skala frontier, panduan kami tentang menjalankan large language model di perangkat keras Anda sendiri membahas stack serving dari awal sampai akhir.

Kesalahan 5: Mengevaluasi dengan Benchmark, Bukan dengan Beban Kerja Anda

Kesalahan terakhir adalah yang membatalkan semua yang lain. Sebuah tim melakukan semuanya dengan benar — lisensi ditinjau, hardware di-sizing, kuantisasi diuji di benchmark publik — lalu merilis model yang dibenci pengguna, karena evaluasinya tidak pernah mengukur apa pun yang sebenarnya dilakukan penggunanya.

Benchmark publik menjawab pertanyaan "apakah model ini secara umum mampu?" Benchmark tidak menjawab "apakah model ini mengklasifikasikan tiket dukungan kami dengan nada dan format yang kami butuhkan, pada 4-bit, di bawah beban konkurensi kami?" Kami pernah menulis tentang mengapa benchmark AI melewatkan 90% pekerjaan nyata, dan self-hosting membuat celah itu makin tajam, bukan makin tumpul: Anda kini bertanggung jawab atas setiap variabel yang dulu dikelola penyedia API. Stack deployment, pengaturan sampler, konvensi system prompt yang dilatihkan pada model — semuanya menjadi tanggung jawab Anda untuk diatur dengan benar.

Solusinya adalah eval tiga lapis yang Anda bangun sebelum berkomitmen pada hardware:

1. Golden set dari produksi. Beberapa ratus prompt nyata dengan output ideal yang sudah ditinjau, mencakup distribusi tugas Anda yang sebenarnya — termasuk kasus yang panjang, berantakan, dan multi-turn.
2. Regression harness. Setiap kandidat (API vs lokal, FP8 vs 4-bit, bobot lama vs rilis baru) dijalankan terhadap golden set secara otomatis. Nilai dengan model juri yang kuat ditambah tinjauan manusia sesekali; jangan percaya buta pada juri untuk output terstruktur.
3. Periode shadow. Jalankan deployment lokal berdampingan dengan API pada trafik langsung selama dua minggu, bandingkan output, dan ukur latensi nyata di bawah beban nyata. Di sinilah kesalahan sizing KV cache dan kegagalan ekor kuantisasi benar-benar muncul.

Harness ini akan terbayar begitu rilis bobot baru datang dan Anda bisa menjawab "apakah kita perlu upgrade?" dengan data dalam satu sore, bukan dengan firasat di rapat.

Pelajaran Sesungguhnya: Open Weights Mengubah Pertanyaannya, Bukan Jawabannya

Setahun lalu, "haruskah kami self-host model frontier?" masih hipotetis — frontier belum bisa diunduh. Mistral Large 4, bersama gelombang rilis model triliunan parameter lainnya, telah menjadikannya keputusan nyata dengan uang sungguhan yang dipertaruhkan. Tetapi kerangka keputusannya tidak berubah; ia hanya menjadi wajib.

Self-host ketika kedaulatan, konektivitas, volume berkelanjutan, atau kebutuhan memodifikasi model menuntutnya. Bayar API ketika trafik Anda bursty, tim Anda kecil, dan pembeda Anda adalah produknya, bukan stack inferensinya. Apa pun pilihannya, lakukan perhitungan memori sembilan puluh detik itu, baca lisensinya, dan bangun eval harness sebelum menandatangani apa pun. Bobotnya sudah terbuka sekarang. Kesalahannya, sayangnya, juga.