Setiap beberapa minggu ada klien yang bertanya apakah mereka sebaiknya menjalankan AI di server sendiri alih-alih memanggil API. Small language model on-premise sudah jadi jauh lebih mumpuni tahun ini, cukup mumpuni untuk menjalankan klasifikasi, ekstraksi dokumen, dan tugas drafting dasar di hardware yang tidak eksotis. Tapi kapabilitas bukan faktor penentu. Keputusannya bergantung pada tiga pertanyaan: apakah data Anda secara hukum wajib tetap di tempat, apakah volume Anda membuat biaya per-call API terasa menyakitkan, dan apakah konektivitas Anda cukup andal untuk bergantung pada panggilan cloud di setiap transaksi.
Untuk sebagian besar bisnis yang saya tangani, jawaban ketiganya adalah tidak, dan cloud API tetap jadi opsi yang lebih sederhana, lebih murah, dan lebih terawat. Tapi untuk sebagian kecil yang nyata, biasanya di sektor keuangan, kesehatan, atau konteks operasional bervolume tinggi, small model on-premise sekarang menjadi keputusan engineering yang benar, bukan kompromi.
Ini bukan soal ideologis antara model open-source versus proprietary. Ini murni matematika, diterapkan secara jujur pada batasan spesifik Anda.
Apa yang berubah pada small language model tahun ini
Setahun lalu, "small model" berarti output yang jelas lebih buruk, pajak kapabilitas nyata yang harus dibayar demi menjalankannya secara lokal. Kesenjangan itu menyempit signifikan sepanjang 2025. Model dengan jumlah parameter lebih kecil kini bisa menangani tugas yang scope-nya jelas, klasifikasi dokumen, ekstraksi entitas, penarikan data terstruktur dari formulir, drafting berbasis template, pada level kualitas yang benar-benar layak dipakai produksi untuk tugas-tugas sempit.
Kata kunci pentingnya adalah sempit. Model-model ini masih kalah dari model cloud kelas frontier dalam penalaran open-ended, permintaan yang ambigu, atau tugas yang butuh pengetahuan dunia yang luas. Tidak ada yang sebaiknya menjalankan small model lokal untuk menangani percakapan customer service yang nuansanya rumit atau analisis kompleks. Tapi untuk tugas yang jelas dan repetitif, kesenjangannya sudah cukup menutup hingga berhenti jadi faktor penentu.
Tiga kriteria keputusan yang sesungguhnya
1. Data yang secara hukum atau kontraktual tidak boleh keluar dari lingkungan Anda
Ini kasus paling jelas. Jika Anda memproses catatan finansial pelanggan, data kesehatan, atau apa pun di bawah persyaratan residensi data yang ketat, dan tim legal atau compliance Anda sudah menyatakan data tidak boleh transit ke API pihak ketiga terlepas dari enkripsi atau ketentuan kontrak, on-premise bukan pilihan, itu keharusan. Saya pernah melihat batasan persis ini pada klien multifinance yang menangani data kredit pelanggan, di mana percakapan compliance sudah mengakhiri perdebatan sebelum percakapan biaya bahkan dimulai.
2. Ekonomi volume yang membuat biaya per-call terasa menggigit
Pricing cloud API bersifat per-token, yang baik-baik saja pada volume rendah hingga menengah dan menjadi item anggaran yang nyata pada skala besar. Jika Anda menjalankan jutaan panggilan klasifikasi atau ekstraksi per bulan, matematikanya bisa berbalik: biaya tetap hardware lokal ditambah upaya engineering untuk menjalankan dan merawat small model bisa teramortisasi di bawah pengeluaran API per-call yang berkelanjutan. Saya pernah menghitung ini untuk klien yang memproses ekstraksi dokumen bervolume tinggi, dan titik impasnya jatuh di sekitar beberapa ratus ribu panggilan per bulan, di bawah angka itu cloud API tetap lebih murah setelah memperhitungkan overhead engineering dan pemeliharaan.
3. Konektivitas yang tidak andal atau dibatasi
Lebih jarang terjadi di konteks bisnis perkotaan Indonesia, tapi nyata untuk operasi di wilayah dengan internet yang tidak stabil, atau lingkungan di mana kebijakan keamanan memblokir seluruh panggilan API keluar (beberapa lantai manufaktur, beberapa konteks yang berdekatan dengan pemerintahan). Jika panggilan cloud tidak bisa diandalkan untuk selesai, inference lokal bukan preferensi, itu satu-satunya opsi yang berfungsi.
Kapan cloud tetap menang, yang mana sebagian besar waktu
Jika tak satu pun dari tiga kriteria di atas berlaku bersih pada situasi Anda, cloud API tetap jadi pilihan yang lebih baik, dan saya mengatakan ini sebagai orang yang sebenarnya bisa menagih lebih banyak jam dengan membangun infrastruktur on-premise. Alasannya:
- Tidak ada infrastruktur yang perlu dirawat. Tidak ada pengadaan GPU, tidak ada update model, tidak ada keputusan scaling saat volume melonjak.
- Kualitas model lebih baik untuk apa pun di luar tugas sempit. Model cloud kelas frontier menangani ambiguitas dan edge case yang masih menjadi kesulitan bagi small model lokal.
- Total biaya lebih rendah pada volume rendah hingga menengah. Biaya tetap infrastruktur lokal tidak akan balik modal di bawah ambang volume yang nyata.
- Lebih cepat di-deploy. Integrasi API butuh waktu beberapa hari. Setup inference lokal kelas produksi butuh waktu berminggu-minggu hingga berbulan-bulan, termasuk hardening keamanan yang diperlukan.
Saya pernah menolak permintaan untuk membangun setup on-premise bagi klien yang volume dan sensitivitas datanya sebenarnya tidak membenarkan itu, karena rekomendasi jujurnya adalah integrasi cloud API yang bisa rilis dalam waktu jauh lebih singkat dengan biaya berkelanjutan jauh lebih rendah.
Kerangka keputusan yang bisa langsung dipakai
| Situasi Anda | Rekomendasi |
|---|---|
| Data teregulasi, persyaratan residensi kontraktual | On-premise, tidak bisa ditawar |
| Volume tinggi (ratusan ribu+ panggilan/bulan), tugas sempit | Hitung matematika biayanya, kemungkinan besar on-premise |
| Konektivitas jaringan tidak andal atau dibatasi | On-premise, karena keharusan |
| Volume rendah hingga menengah, tugas serba guna | Cloud API |
| Butuh penalaran luas atau permintaan yang ambigu | Cloud API, model frontier |
| Kecepatan time-to-deploy adalah prioritas | Cloud API |
Bagaimana ini masuk ke dalam pendekatan AI-native yang lebih luas
Ke mana pun keputusan ini berujung, ini seharusnya jadi pilihan infrastruktur yang disengaja, dibuat setelah tugasnya terdefinisi dengan jelas, bukan titik awal proyek. Saya pernah menulis tentang apa yang sebenarnya dimaksud dengan operasi AI-native bagi sebuah bisnis, dan polanya berlaku sama di sini: tentukan dulu tugas spesifik yang sempit, baru pilih infrastruktur yang cocok dengan batasannya, alih-alih memilih arsitektur model karena terdengar lebih canggih atau lebih privat.
Kesimpulan praktisnya
Hitung dulu matematikanya sebelum menjalankan modelnya. Jika data Anda harus tetap on-premise karena hukum atau kontrak, atau volume Anda membuat biaya per-call jadi item anggaran yang nyata, small model lokal sekarang cukup mumpuni untuk jadi keputusan engineering yang tepat. Selain itu, tetaplah pakai cloud API, karena lebih sederhana, lebih cepat di-deploy, dan lebih murah pada volume aktual Anda selalu mengalahkan "terdengar lebih canggih".