Prompt Router untuk Developer Indonesia: Cara Memangkas Biaya LLM 40-70% Tanpa Menurunkan Kualitas Produk AI

TL;DR: Prompt Router adalah lapisan middleware di aplikasi LLM yang otomatis memilih model mana yang menangani setiap permintaan, berdasarkan kompleksitas, biaya, dan kebutuhan latensi. Untuk produk AI Indonesia, pola ini bisa memangkas biaya API LLM 40-70% dengan mengirim 60-80% permintaan sederhana ke model murah, dan menyisakan model flagship untuk kasus yang benar-benar butuh reasoning kuat.

Dalam beberapa proyek terakhir membantu klien Indonesia membangun produk berbasis AI, saya menemukan satu pola berulang. Mereka menggunakan model flagship (GPT-4 class, Claude Opus, Gemini Ultra) untuk semua permintaan, "demi aman". Hasilnya, biaya API bulanan bisa menembus 40-80 juta rupiah bahkan saat trafik masih kecil, padahal lebih dari setengah permintaan sebenarnya cukup ditangani model kelas Haiku, Mini, atau Flash.

Prompt Router adalah pola arsitektur yang mengatasi masalah ini. Lapisan middleware ini berfungsi seperti load balancer berbasis isi: setiap prompt dievaluasi singkat, lalu diarahkan ke model yang paling efisien untuk tugas itu.

Kenapa Prompt Router Mendesak di 2026

Per April 2026, harga model flagship dari OpenAI, Anthropic, dan Google masih 10-50 kali lipat lebih mahal dari model kelas mini di vendor yang sama. Sementara itu, kualitas model mini terus naik signifikan dalam 12 bulan terakhir untuk tugas seperti klasifikasi, ringkasan, ekstraksi entitas, dan tanya-jawab faktual sederhana.

Tanpa router, biaya scaling produk AI naik linier dengan trafik. Dengan router yang tepat, biaya bisa naik sublinear karena distribusi tugas yang masuk biasanya berekor panjang: mayoritas permintaan sederhana, minoritas yang benar-benar kompleks.

Dokumentasi resmi Anthropic tentang model selection dan OpenAI tentang routing strategi sama-sama menyebut routing sebagai pola optimasi pertama yang sebaiknya dilakukan sebelum fine-tuning atau caching agresif.

Empat Pola Prompt Router yang Layak Dipertimbangkan

Untuk tim kecil di Indonesia, saya selalu menyarankan mulai dari static rules. Pola ini bisa diimplementasi dalam beberapa jam dan sudah memberi penghematan 30-50% di banyak kasus. Cascading adalah upgrade alami berikutnya saat pola permintaan mulai jelas.

Studi Kasus: Aplikasi Q&A Internal Klien

Saat membantu salah satu klien Atmo (LMS Vito Atmo) membangun fitur Q&A berbasis RAG untuk dokumentasi internal, awalnya semua permintaan diarahkan ke model flagship. Setelah 30 hari operasional, analisis log menunjukkan distribusi pertanyaan sebagai berikut:

• 45% pertanyaan faktual sederhana (definisi, lokasi info)
• 30% ringkasan dokumen pendek
• 18% perbandingan antar dokumen
• 7% reasoning kompleks lintas dokumen

Tim memasang router cascading: 75% trafik diarahkan ke model mini, dengan fallback ke model flagship jika confidence response di bawah threshold. Hasilnya, biaya API bulanan turun sekitar 55-65% dengan kualitas user-perceived tetap stabil. Angka ini bukan klaim universal, melainkan hasil satu kasus dengan domain spesifik. Untuk produk Anda, distribusi tugas dan threshold yang tepat akan berbeda.

Pelajaran utama: tanpa data trafik nyata, optimasi router sering keliru. Jalankan dulu beberapa minggu dengan logging detail sebelum membangun classifier khusus.

Risiko dan Cara Memitigasinya

Tiga risiko utama yang sering muncul:

Pertama, kualitas turun di edge cases. Model mini bisa salah dalam reasoning yang halus, sementara user tidak selalu sadar. Solusinya, monitor Hallucination rate per arm router secara terpisah, bukan agregat.

Kedua, latency tambahan dari classifier. Jika router menggunakan model klasifier yang lambat, total latency justru naik. Pilih classifier yang berjalan dalam 50-100 ms, atau pakai static rules dulu.

Ketiga, debugging jadi lebih kompleks. Saat ada bug, sulit menentukan apakah masalah di routing logic atau di model itu sendiri. Pasang logging yang menyimpan model mana yang dipilih untuk setiap request, lengkap dengan reasoning routing-nya.

Untuk infrastruktur, kombinasi Prompt Caching di sisi vendor dan Rate Limiting di sisi aplikasi melengkapi router dengan baik. Keduanya menutup risiko biaya dari pola lain (cache hit dan abuse).

Arsitektur Implementasi Sederhana

Implementasi minimal hanya butuh tiga komponen:

1. Layer routing function yang menerima prompt + metadata
2. Mapping rules atau classifier yang mengembalikan model_id
3. Wrapper API yang memanggil model terpilih dan log hasilnya

Stack populer di Indonesia untuk implementasi ini: Next.js API routes + Vercel AI SDK, atau FastAPI Python + LiteLLM. Keduanya sudah punya helper untuk multi-model routing tanpa harus menulis dari nol. Pilih yang sesuai stack tim Anda, jangan terjebak optimasi prematur dengan framework baru.

Pertanyaan Umum

Apakah perlu router untuk MVP yang baru launch?

Tidak. Untuk MVP atau produk dengan trafik di bawah 1000 request per hari, satu model sudah cukup. Router mulai relevan saat biaya bulanan API LLM melebihi 8-10 juta rupiah atau ada variasi tugas yang signifikan.

Bagaimana cara menentukan threshold cascading?

Mulai dari threshold konservatif (eskalasi 30-40% trafik ke flagship), lalu turunkan bertahap berdasarkan analisis kualitas response. Praktik wajar di industri menyarankan A/B test threshold setiap 2-4 minggu.

Apakah router bisa menggunakan vendor LLM yang berbeda?

Bisa dan sering disarankan. Multi-vendor routing menambah resilience saat satu vendor down dan memberi leverage harga. Tools seperti LiteLLM, Portkey, atau OpenRouter memudahkan integrasi multi-vendor tanpa lock-in.

Bagaimana router menangani konteks panjang (long-context)?

Tugas dengan konteks di atas 32k token biasanya butuh model flagship dengan context window besar. Pasang static rule yang otomatis route long-context ke model yang mampu, jangan andalkan classifier.

Mulai dari yang Sederhana, Iterasi dari Data Nyata

Prompt Router bukan keajaiban. Manfaatnya muncul saat keputusan routing berdasarkan data trafik aktual, bukan asumsi. Mulai dari static rules sederhana, pasang logging detail, lalu naikkan kompleksitas sesuai kebutuhan. Tim yang melompat langsung ke classifier custom tanpa data sering menghabiskan waktu lebih lama dengan hasil lebih kecil dibanding tim yang iteratif.