Seorang klien datang dengan tagihan AI yang diam-diam sudah membengkak jadi beberapa juta rupiah per bulan, semuanya berjalan di model paling canggih yang tersedia, untuk pekerjaan seperti menandai tiket support dan mengekstrak data dari invoice. Itulah pertanyaan model kecil vs model besar dalam bentuknya yang paling mahal: memakai model frontier untuk pekerjaan yang bisa ditangani sama baiknya oleh model yang jauh lebih kecil dan murah. Perbaikannya hanya butuh waktu satu sore, dan memangkas tagihan lebih dari separuh.
Ini salah satu peluang optimasi biaya paling jelas di dunia AI saat ini, dan kebanyakan bisnis melewatkannya begitu saja karena "pakai saja model terbaik" terasa seperti pilihan paling aman. Memang aman untuk akurasi. Tapi tidak aman untuk anggaran, dan di volume tinggi selisihnya membesar dengan cepat.
Apa yang Benar-Benar Dikuasai Model Kecil?
Model kecil, tier mini dan ringan yang kini ditawarkan setiap provider besar, sebenarnya sangat kuat untuk satu kategori pekerjaan tertentu: tugas yang inputnya bisa ditebak dan jawabannya punya satu bentuk yang jelas benar. Lima jenis pekerjaan berikut cocok masuk kategori itu:
- Klasifikasi: apakah email ini keluhan, pertanyaan, atau spam.
- Ekstraksi: ambil nomor invoice, tanggal, dan total dari teks dokumen ini.
- Penulisan singkat: buat balasan konfirmasi satu baris.
- Ringkasan sederhana: padatkan email lima paragraf jadi dua kalimat.
- Pemformatan terstruktur: ubah teks berantakan jadi objek JSON rapi sesuai skema.
Tugas-tugas ini punya kesamaan: ruang jawaban yang benar itu sempit, dan model tidak perlu penalaran mendalam atau pengetahuan dunia yang luas untuk menjawabnya dengan tepat. Model yang lebih kecil, yang dilatih dengan teknik dasar sama seperti "kakaknya" yang lebih besar, menangani tugas ini secara andal, seringkali dengan biaya per request sepuluh hingga dua puluh kali lebih murah.
Di Mana Model Frontier Layak dengan Harganya?
Model frontier layak dengan harganya yang lebih tinggi ketika tugas benar-benar membutuhkan kapabilitas yang tidak bisa dipalsukan oleh model kecil: penalaran yang berjalan lintas beberapa langkah, penilaian di mana nada bicara dan konteks sama-sama krusial, atau konteks yang begitu panjang sehingga satu detail terlewat bisa mengubah hasil. Empat kategori tugas berikut membutuhkan tier itu:
- Penalaran multi-langkah: menghitung skema harga dengan beberapa aturan kondisional.
- Penilaian yang nuansanya halus: menyusun balasan ke pelanggan yang sensitif, di mana nada bicara dan konteks sama-sama penting.
- Sintesis konteks panjang: membaca kontrak yang panjang dan menandai inkonsistensi antar bagian.
- Tugas ambigu atau open-ended: di mana input tidak mengikuti pola yang bisa diprediksi.
Kalau tugas Anda mirip salah satu di atas, jangan coba menghemat biaya dengan turun ke model yang lebih murah. Biaya kegagalannya, klausul kontrak keliru yang terlewat, balasan yang salah nada ke pelanggan yang sedang marah, akan jauh melebihi apa pun yang Anda hemat dari tagihan API.
Arsitektur sesungguhnya: tiered routing
Versi yang lebih matang dari ini bukan "pilih satu model untuk semuanya." Ini soal merutekan request ke tier termurah yang bisa menanganinya secara andal, dan meningkatkan (escalate) hanya bila perlu. Versi sederhananya seperti ini:
- Klasifikasi dulu, dengan murah. Model kecil melihat request yang masuk dan menandai jenis serta tingkat kompleksitasnya.
- Rutekan sesuai tier. Tugas rutin dan sempit masuk ke model kecil. Yang ditandai ambigu, sensitif, atau kompleks, dieskalasi ke model frontier.
- Pantau dan sesuaikan. Lacak seberapa sering eskalasi terjadi dan apakah output model kecil untuk tugas rutin benar-benar tetap konsisten kualitasnya, lalu sesuaikan aturan routing seiring waktu.
Ini instingsi arsitektur yang sama dengan pola workflow AI yang saya bahas di Otomasi Workflow: Menyambungkan AI ke Tools yang Sudah Anda Miliki: simpan sumber daya mahal, dalam hal ini panggilan model yang berbiaya tinggi, untuk kasus yang benar-benar membutuhkannya.
Versi yang lebih matang dari ini bukan "pilih satu model untuk semuanya." Ini soal merutekan request ke tier termurah yang bisa menanganinya secara andal, dan meningkatkan (escalate) hanya bila perlu.
- Ervandra Halim, konsultan adopsi AI
Perbandingan biaya nyata
Berikut ilustrasi kasar menggunakan volume representatif untuk operasi support skala menengah yang menangani sekitar 3,000 request berbantuan AI per bulan, campuran antara klasifikasi tiket dan penulisan balasan keluhan kompleks sesekali:
| Pendekatan | Request per bulan | Perkiraan biaya bulanan |
|---|---|---|
| Semua request di model frontier | 3,000 | Paling mahal, seringkali 5-10x pendekatan tiered |
| Semua request di model kecil | 3,000 | Paling murah, tapi ada risiko kualitas pada ~10% kasus kompleks |
| Tiered: model kecil mengklasifikasi, ~85% tetap di model kecil, ~15% dieskalasi | 3,000 | Titik tengah, mendekati biaya model kecil dengan kualitas setara frontier di kasus yang penting |
Angka kelipatan pastinya tergantung provider dan campuran tugas Anda, tapi polanya konsisten di setiap klien yang pernah saya ukur: tiered routing menangkap sebagian besar penghematan dari beralih penuh ke model murah, tanpa menanggung risiko kualitas memakai model kecil pada tugas yang tidak bisa ditanganinya secara andal.
Bagaimana Memulai Tanpa Over-Engineering?
Memulai tanpa over-engineering berarti tidak perlu langsung membangun sistem routing yang canggih di hari pertama. Mulai secara manual: lihat penggunaan AI bulan lalu, kelompokkan request berdasarkan kompleksitas sebenarnya, dan perkirakan berapa banyak yang bisa berjalan di tier lebih murah tanpa penurunan kualitas. Kalau jumlahnya cukup signifikan, biasanya 60 sampai 80 persen volume untuk tugas support dan back-office, bangun langkah klasifikasi sederhana, bahkan yang berbasis aturan (rule-based) sekalipun, sebelum beralih ke sesuatu yang lebih rumit. Ini instingsi bertahap yang sama dengan yang saya bahas di Mengotomasi Tugas Back Office yang Repetitif: Mulai dari Mana: mulai dari titik dengan volume tertinggi dan tingkat penilaian (judgment) yang dibutuhkan paling rendah.
Kesimpulan
Perdebatan model kecil vs model besar sebenarnya bukan soal mana yang "lebih baik." Ini soal mencocokkan biaya dengan tingkat kesulitan sebenarnya dari tugas yang ada di depan Anda. Sebagian besar pekerjaan yang dijalankan lewat AI hari ini cukup rutin untuk ditangani baik oleh model murah. Simpan tier mahal untuk kasus yang benar-benar sulit, bangun lapisan routing sederhana di antara keduanya, dan tinjau ulang pembagiannya setiap beberapa bulan seiring perubahan volume dan campuran tugas Anda. Bisnis yang menang dalam soal biaya AI tahun ini bukan yang memakai model murah di mana-mana. Mereka yang memakai model yang tepat untuk setiap pekerjaan.
