Apa Itu Routing LLM? Penjelasan Aturan, Bobot, dan Kebijakan Sadar Biaya

Apa Itu Routing LLM? Penjelasan Aturan, Bobot, dan Kebijakan Sadar Biaya

Routing LLM adalah proses memilih model, jalur penyedia, atau jalur fallback yang harus menangani permintaan AI tertentu. Keputusan dapat ditetapkan dalam kode aplikasi, dibuat berdasarkan aturan eksplisit, dihitung dari kriteria berbobot, atau didelegasikan kepada pengklasifikasi terlatih. Tujuannya bukan untuk membuat setiap permintaan menempuh jalur yang berbeda. Tujuannya adalah memastikan setiap jalur bersifat disengaja, dapat diuji, dan aman.

Jika Anda bertanya apa itu routing LLM, jawaban praktisnya adalah: ini merupakan lapisan kebijakan antara permintaan aplikasi dan pemanggilan model. Router mula-mula menyingkirkan opsi yang tidak dapat memenuhi permintaan, lalu memilih rute yang memenuhi syarat menggunakan prioritas yang ditetapkan tim Anda—seperti kapabilitas, kualitas, latensi, biaya, ketersediaan, dan kebijakan data.

Perbedaan tersebut penting. Model murah tidak otomatis menjadi default yang aman untuk alur kerja yang berhadapan dengan pelanggan. Model yang sangat mumpuni tidak otomatis menjadi pilihan tepat untuk pekerjaan klasifikasi sederhana. Dan fallback hanya berguna jika mempertahankan kontrak output, alat, dan data yang diharapkan aplikasi Anda.

Versi singkat: routing LLM yang baik dimulai dengan batasan ketat, memberi peringkat hanya pada kandidat yang kompatibel, mencatat alasan pemilihan, dan menggunakan fallback hanya ketika cadangannya aman terhadap kontrak.

Itulah standar yang harus dipenuhi oleh jawaban produksi atas apa itu routing LLM: keputusan yang dapat diperiksa, diuji, dan diubah oleh engineer tanpa perlu menebak aturan tersembunyi mana yang mengalihkan traffic.

Apa sebenarnya routing LLM?

Apa itu routing LLM? Ini adalah proses pengambilan keputusan yang memetakan permintaan masuk ke jalur eksekusi yang disetujui dan paling sesuai untuk permintaan tersebut. Jalur ini dapat mengidentifikasi model tertentu, penyedia, wilayah, grup model, atau fallback yang telah diuji.

Router dapat berada di aplikasi Anda, gateway API, atau layanan routing model terkelola. Sebagai contoh, Amazon Bedrock intelligent prompt routing memilih di antara model yang memenuhi syarat dalam sebuah keluarga berdasarkan prediksi kualitas respons dan biaya. Microsoft Foundry’s model router menyediakan mode routing berorientasi keseimbangan, kualitas, dan biaya. Keduanya merupakan implementasi dari gagasan mendasar yang sama: memilih secara sengaja, alih-alih memperlakukan setiap prompt sebagai identik.

Routing LLM tidak sama dengan:

• Penyeimbang beban. Penyeimbang beban mendistribusikan permintaan di antara server yang serupa. Router LLM juga mempertimbangkan kapabilitas model dan hasil tugas.
• Loop retry. Mencoba ulang rute yang sama dapat menyelesaikan kesalahan sementara; hal itu tidak menentukan apakah model lain valid untuk tugas tersebut.
• Pertukaran model tanpa peninjauan. Memindahkan permintaan ke cadangan yang mengubah bentuk JSON, perilaku alat, batasan privasi, atau kualitas jawaban dapat menimbulkan kegagalan yang lebih serius daripada kesalahan eksplisit.
• Pelatihan model. Routing memilih jalur penyajian pada waktu permintaan. Routing tidak mengubah bobot model.

Untuk pembahasan lebih luas tentang batas yang menaungi keputusan ini, lihat panduan kami tentang apa itu gateway LLM dan kapan gateway tersebut berguna.

Cara router LLM mengambil keputusan

Desain yang paling andal memisahkan kelayakan dari preferensi. Pertama, kecualikan opsi yang tidak dapat memenuhi permintaan. Kemudian, beri skor pada rute yang tersisa berdasarkan kelas traffic saat ini.

1. Terapkan batasan ketat sebelum pemberian skor

Batasan ketat tidak dapat ditawar. Model yang gagal memenuhi salah satunya tidak boleh tetap berada dalam kumpulan kandidat hanya karena model tersebut murah atau cepat.

Filter umum mencakup:

Urutan ini mencegah kesalahan routing yang umum: memperlakukan setiap model sebagai dapat dipertukarkan. Tidak demikian. Kompatibilitas perlu dibuktikan untuk endpoint dan kelas traffic yang tepat yang ingin Anda arahkan.

2. Beri skor pada kandidat yang memenuhi syarat

Setelah pemfilteran, suatu rute dapat menggunakan skor berbobot yang transparan. Salah satu pola sederhana adalah:

route score =
  quality_weight × expected_quality
  + latency_weight × (1 - normalized_latency)
  + cost_weight × (1 - normalized_cost)
  + reliability_weight × recent_route_health

Rumus ini adalah kerangka pengambilan keputusan, bukan tolok ukur universal. Bagian pentingnya adalah bahwa istilah-istilahnya dinormalisasi secara konsisten, bobotnya ditetapkan untuk kelas traffic, dan kebijakannya dapat dijelaskan setelah insiden.

Misalnya, tugas pemberian tag di latar belakang dapat memberikan bobot lebih besar pada biaya dan throughput. Agen dukungan yang berinteraksi langsung dengan pelanggan dapat memberikan bobot lebih besar pada kualitas, kompatibilitas tool, dan latensi ekor. Alur kerja yang diatur regulasi dapat menjadikan residensi data sebagai filter mutlak, bukan faktor penilaian.

3. Jalankan, amati, dan gunakan fallback dengan batasan

Router harus mencatat rute yang dipilih, input penilaian, versi kebijakan, ID permintaan, latensi, estimasi biaya atau catatan penggunaan, serta status hasil. Jika rute utama gagal, keputusan fallback memerlukan aturannya sendiri:

1. Apakah kesalahan tersebut cukup sementara sehingga percobaan ulang pada rute yang sama layak dilakukan?
2. Apakah permintaan bersifat idempoten, atau dapatkah percobaan ulang menduplikasi tindakan eksternal?
3. Apakah fallback mempertahankan kontrak output dan tool?
4. Apakah fallback diizinkan melampaui anggaran atau batas data permintaan?
5. Jika tidak, haruskah sistem mengantrekan permintaan, menurunkan layanan secara terkendali, atau mengembalikan kesalahan yang terkontrol?

Itulah sebabnya fallback adalah teknik routing, bukan sinonim untuk routing. Panduan strategi fallback model kami membahas keputusan pemulihan secara lebih terperinci.

Enam teknik routing LLM untuk digunakan secara terencana

Tidak ada satu router yang terbaik untuk semua kasus. Mulailah dengan teknik paling sederhana yang dapat memenuhi kebutuhan beban kerja, lalu tambahkan kompleksitas jika hasil pengukuran Anda mendukungnya.

1. Routing statis

Setiap permintaan dalam suatu beban kerja dikirim ke satu model atau endpoint yang telah ditentukan.

Gunakan ketika: Anda sedang menetapkan tolok ukur awal, membutuhkan target evaluasi yang stabil, atau memiliki beban kerja terbatas dengan satu model yang disetujui.

Waspadai: rute statis dapat menyembunyikan biaya penggunaan model berkemampuan tinggi untuk pekerjaan sederhana, atau risiko keandalan akibat ketergantungan pada satu jalur upstream.

2. Routing berbasis aturan

Kondisi eksplisit menentukan rute: kirim permintaan yang berisi gambar ke jalur yang mendukung pemrosesan gambar; kirim permintaan dengan pemanggilan tool hanya ke model yang mendukung kontrak tool yang disetujui; kirim ringkasan batch internal ke rute yang ekonomis.

Gunakan ketika: keputusan dapat dijelaskan berdasarkan metadata permintaan dan jumlah aturannya cukup sedikit untuk ditinjau.

Waspadai: aturan yang semakin banyak dan tersebar. Tempatkan aturan dalam file kebijakan atau layanan yang memiliki versi, alih-alih menyebarkan pemeriksaan penyedia di seluruh kode aplikasi.

3. Routing berbasis kemampuan

Router menggunakan registri kemampuan model sebagai titik awal, bukan hanya teks prompt. Router memfilter berdasarkan keluarga endpoint, konteks, modalitas yang didukung, perilaku tool, dukungan output terstruktur, wilayah, dan jatah akun.

Gunakan ketika: aplikasi memiliki beberapa jenis endpoint atau model dengan kontrak yang berbeda secara signifikan.

Waspadai: data katalog yang usang. Perlakukan ID model, kemampuan, dan informasi penghentian dukungan sebagai data operasional yang perlu diverifikasi secara berkala.

4. Routing berbobot berdasarkan biaya, kualitas, latensi, dan keandalan

Rute yang memenuhi syarat diberi skor berdasarkan tujuan saat ini. Ini adalah jawaban umum untuk pertanyaan apa itu routing LLM ketika sebuah tim menginginkan pendekatan yang lebih bernuansa daripada aturan tetap, tetapi tetap membutuhkan kebijakan yang dapat dijelaskan.

Gunakan ketika: Anda dapat menetapkan indikator penerimaan yang terukur dan memiliki telemetri rute yang cukup untuk membandingkan kandidat.

Waspadai: presisi semu. Kegunaan skor bergantung pada data kualitas, asumsi biaya, indikator kesehatan, dan bobot yang mendasarinya. Jangan menyiratkan bahwa skor desimal membuktikan satu model lebih baik secara universal.

5. Routing berbasis pengklasifikasi

Pengklasifikasi kecil atau pengklasifikasi berbasis LLM memberi label pada permintaan—misalnya ekstraksi sederhana, pembuatan kode, penalaran kompleks, atau konten yang sensitif terhadap keselamatan—lalu menyerahkannya ke kebijakan yang telah ditetapkan untuk kelas tersebut.

Gunakan ketika: maksud prompt merupakan prediktor kuat untuk menentukan tingkat model yang sesuai dan Anda dapat mengevaluasi kesalahan pengklasifikasi secara terpisah dari kesalahan model.

Waspadai: penambahan keputusan yang tidak transparan sebelum pemanggilan model. Sediakan jalur untuk hasil dengan tingkat keyakinan rendah, catat hasil klasifikasi, dan evaluasi pengklasifikasi menggunakan permintaan yang representatif.

6. Routing fallback yang mempertimbangkan kesehatan

Jalur utama dipilih seperti biasa, tetapi router merespons timeout, kelebihan beban, batas laju, atau penurunan kesehatan dengan percobaan ulang yang dibatasi, cadangan yang setara, antrean, atau kegagalan yang terkontrol.

Gunakan ketika: ketersediaan penting dan Anda telah mengidentifikasi cadangan mana yang kompatibel dengan kontrak.

Waspadai: pelanggaran batas semantik tanpa pemberitahuan. Fallback mungkin sesuai untuk penyelesaian teks yang dapat dicoba ulang, tetapi tidak untuk agen yang menggunakan tool, alur kerja yang mengubah status, atau output yang harus sesuai dengan skema ketat. Lihat panduan kami tentang routing agen multimodal untuk contoh ketika perubahan modalitas membuat aturan fallback lebih ketat.

Bangun kebijakan sadar biaya tanpa mengabaikan kualitas

Sadar biaya tidak berarti “selalu memilih model termurah.” Artinya, biaya diberi peran yang jelas setelah pemeriksaan kemampuan, kebijakan, dan kontrak yang diwajibkan terpenuhi.

Pola yang berguna adalah membuat kelas lalu lintas sebelum menetapkan bobot:

Kemudian bandingkan angka yang penting: biaya per hasil yang diterima, bukan hanya biaya per permintaan. Rute dengan harga lebih rendah yang menyebabkan percobaan ulang tambahan, tinjauan manusia, perbaikan skema, atau panggilan alat yang gagal mungkin memerlukan biaya lebih tinggi per tugas yang selesai.

Dokumentasi routing Amazon menyampaikan peringatan praktis yang sama dalam konteks berbeda: routing otomatis memiliki batasan, termasuk data pelatihan khusus rute dan batasan dukungan. Dokumentasi tersebut merekomendasikan peninjauan kinerja dan biaya secara berkelanjutan, alih-alih mengasumsikan keputusan routing akan tetap optimal selamanya. Kebijakan Anda sendiri harus dievaluasi terhadap campuran permintaan Anda sendiri.

Kebijakan routing yang aman, dalam pseudocode

Contoh sederhana ini menjaga agar keputusan dapat diaudit. Contoh ini tidak mengasumsikan bahwa setiap rute dapat menangani setiap permintaan.

const candidates = catalog
  .filter(route => route.isHealthy)
  .filter(route => route.supports(request.modality))
  .filter(route => route.supportsTools(request.requiredTools))
  .filter(route => route.allows(request.dataClass))
  .filter(route => route.withinBudget(request.budget));

if (candidates.length === 0) {
  return failClosed("No approved route for this request");
}

const primary = candidates
  .map(route => ({
    route,
    score: score(route, request.trafficClass),
  }))
  .sort((a, b) => b.score - a.score)[0];

const result = await call(primary.route, request);

if (isTransient(result.error) && request.isIdempotent) {
  return retryWithinBudget(primary.route, request);
}

if (canUseEquivalentFallback(result.error, request, primary.route)) {
  return call(selectApprovedFallback(candidates, primary.route), request);
}

return returnControlledError(result.error);

Kebijakan harus menghasilkan alasan rute seperti tool_contract_required, budget_preferred, primary_unhealthy, atau no_contract_safe_fallback. Detail kecil tersebut membuat sistem jauh lebih mudah di-debug daripada pesan umum “model gagal”.

Cara mengukur apakah routing LLM membantu

Routing tidak berhasil hanya karena menghasilkan nama model. Routing berhasil ketika meningkatkan hasil beban kerja yang telah ditentukan tanpa menciptakan risiko yang tidak dapat diterima.

Lacak hasil berdasarkan kelas trafik, versi kebijakan, dan rute yang dipilih:

• Tingkat hasil yang diterima: proporsi respons yang lolos uji penerimaan bisnis, skema, atau tinjauan manusia.
• Biaya per hasil yang diterima: total biaya model, percobaan ulang, dan remediasi dibagi dengan tugas yang diterima.
• Latensi P50, P95, dan P99: dikelompokkan berdasarkan ukuran permintaan dan rute; rata-rata dapat menyembunyikan latensi ekor yang menyakitkan.
• Tingkat pemulihan fallback: seberapa sering fallback menghasilkan hasil yang dapat diterima, bukan sekadar HTTP 200.
• Tingkat kegagalan kontrak: output terstruktur yang tidak valid, alat yang tidak didukung, ketidakcocokan streaming, atau kolom wajib yang hilang.
• Distribusi rute: apakah kebijakan baru secara tak terduga mengirim sebagian besar trafik ke jalur yang mahal atau terdegradasi.
• Tingkat penolakan kebijakan: seberapa sering tidak ada kandidat aman—sering kali merupakan sinyal untuk memperluas kapabilitas yang disetujui, bukan melonggarkan guardrail.

Untuk scorecard praktis, lihat metrik API routing AI yang benar-benar penting. Metrik tersebut sangat berguna ketika perubahan routing tampak menurunkan biaya token tetapi mengurangi hasil yang diterima.

Kapan Anda memerlukan routing LLM?

Anda mungkin tidak memerlukan router jika satu penyedia, satu endpoint, dan satu beban kerja yang stabil memenuhi kebutuhan Anda. Kunci model, tetapkan timeout dan percobaan ulang yang jelas, lalu ukur baseline terlebih dahulu.

Routing LLM menjadi bernilai ketika setidaknya satu dari hal berikut benar:

• Berbagai jenis permintaan memerlukan kapabilitas, batas biaya, atau sasaran latensi yang berbeda.
• Anda perlu menjaga pilihan penyedia, model, dan wilayah di balik batas kebijakan.
• Gangguan layanan, masalah kuota, atau penghentian penggunaan memerlukan jalur respons yang aman.
• Anda ingin membandingkan kandidat tanpa menulis ulang setiap pemanggil.
• Anda memerlukan catatan tentang rute mana yang menangani permintaan dan alasannya.

Jika itu terdengar seperti stack Anda, gateway dapat membuat batas operasional lebih mudah dikelola. Dokumentasi Flatkey menjelaskan base URL yang kompatibel dengan OpenAI dan satu kunci API untuk model yang didukung; pemanggil memilih ID model per permintaan, sementara platform mendokumentasikan failover upstream otomatis. Mulailah dengan menetapkan satu model dan mencatat hasilnya, lalu perkenalkan kebijakan routing eksplisit untuk kelas trafik yang benar-benar membutuhkannya. Untuk langkah arsitektural berikutnya, baca checklist persyaratan gateway API AI kami.

Untuk strategi routing, templat kebijakan, dan kode produksi, baca panduan routing model kami.

Pertanyaan yang sering diajukan

Apa perbedaan routing LLM dan fallback model?

Routing LLM adalah proses pengambilan keputusan yang lebih luas untuk memilih jalur eksekusi. Fallback model adalah salah satu tindakan pemulihan dalam proses tersebut, yang digunakan hanya ketika rute utama gagal dan rute alternatif disetujui untuk kontrak permintaan yang sama.

Apa itu routing LLM dalam API multi-penyedia?

Dalam API multi-penyedia, routing LLM dapat memilih jalur penyedia sekaligus model. Kebijakan harus memverifikasi kompatibilitas endpoint, kebijakan data, kapabilitas model, unit harga, kesehatan, dan perilaku fallback sebelum memperlakukan dua penyedia sebagai setara.

Teknik routing LLM mana yang sebaiknya digunakan tim baru sebagai awal?

Mulailah dengan routing statis ditambah pemeriksaan kapabilitas eksplisit dan observabilitas. Tambahkan aturan untuk kelas trafik yang jelas berbeda. Beralih ke routing berbasis bobot atau classifier hanya setelah Anda memiliki pengujian yang representatif dan cara untuk mengukur hasil yang diterima.

Dapatkah router LLM memilih model termurah secara otomatis?

Bisa, tetapi biaya tidak boleh melewati batasan keras. Saring terlebih dahulu berdasarkan kapabilitas yang disetujui dan kompatibilitas kontrak, lalu optimalkan harga di antara rute yang memenuhi syarat. Validasi hasilnya dengan biaya per hasil yang diterima, bukan hanya harga token.

Jawaban praktis untuk “apa itu routing LLM?”

Jawaban praktis untuk apa itu routing LLM bukanlah “pilih model yang cerdas.” Jawabannya adalah “kodekan pilihan yang dapat dipertanggungjawabkan oleh tim Anda.” Mulailah dengan kapabilitas yang disetujui dan batasan keras; gunakan bobot hanya untuk trade-off nyata; jaga fallback tetap terbatas dan aman bagi kontrak; serta catat setiap keputusan dengan cukup baik agar dapat ditingkatkan nantinya.

Jika Anda memusatkan akses model, gunakan batas tersebut untuk menjalankan eksperimen routing yang terkontrol alih-alih menyebarkan logika penyedia ke setiap layanan. Pelajari lebih lanjut dalam dokumentasi API Flatkey.

Sumber dan bacaan lebih lanjut

• Amazon Bedrock: Memahami routing prompt cerdas
• Microsoft Foundry: Menggunakan router model
• Buku Google SRE: Menangani kelebihan beban
• Dokumentasi Flatkey
• Flatkey: Persyaratan AI API Gateway