Setiap produk AI pada akhirnya akan melampaui satu model default. Bot dukungan, peninjau kode, extractor invoice, pembantu prompt gambar, dan agen riset internal tidak memerlukan target latensi, anggaran konteks, kedalaman penalaran, perilaku alat, aturan fallback, atau jejak persetujuan yang sama. Kebijakan routing model mengubah tradeoff tersebut menjadi kontrak operasional, bukan sekumpulan string model= ad hoc.
Tujuannya bukan memilih satu model "terbaik". Tujuannya adalah membuat pemilihan model dapat ditinjau. Kebijakan routing model yang baik memberi tahu engineer model kelas apa yang harus digunakan, kapan perlu mengeluarkan biaya lebih, kapan perlu mengoptimalkan latensi, kapan harus memblokir fallback, dan bukti apa yang harus ada sebelum suatu workflow dipindahkan ke produksi.
Flatkey penting dalam diskusi ini karena routing lebih mudah diatur ketika akses model, key, log request, analitik penggunaan, tinjauan harga, dan kontrol operasional berada di satu tempat. Gunakan kebijakan di bawah ini sebagai lapisan desain, lalu validasi katalog model Flatkey saat ini dan halaman harga sebelum peluncuran ke produksi.
Desain kebijakan routing model dalam satu tabel
Mulailah dengan kelas workflow, bukan nama provider. Tabel di bawah ini adalah langkah pertama yang praktis untuk kebijakan routing model.
| Kelas workflow | Rute utama | Aturan biaya | Aturan latensi | Aturan risiko | Aturan fallback | Bukti yang diperlukan |
|---|---|---|---|---|---|---|
| Klasifikasi cepat | Model teks kecil atau dengan penalaran rendah | Biaya terendah yang lolos evaluasi | Target p95 yang ketat | Risiko bisnis rendah | Aman untuk retry atau downgrade | Sampel akurasi, latensi p95, biaya per 1.000 panggilan |
| Chat pelanggan | Model seimbang dengan dukungan alat | Dibatasi per percakapan atau akun | p95 rendah dan streaming stabil | Risiko sedang | Fallback hanya ke model dengan tone dan perilaku alat yang telah diuji | Evaluasi percakapan, pengecekan refusal, keberhasilan panggilan alat, QA transkrip |
| Penalaran kode dan teknis | Model penalaran yang kuat | Hanya keluarkan biaya lebih untuk tugas yang sulit | Anggaran latensi lebih longgar | Risiko sedang hingga tinggi | Fallback ke rute peer yang telah ditinjau, bukan ke model yang lemah | Evaluasi tugas, ketepatan diff, jejak alat, jalur rollback |
| Ekstraksi terstruktur | Model dengan dukungan skema | Optimalkan per record valid | Batch atau mendekati real-time | Risiko sedang | Retry dengan rute yang sama atau lebih ketat sebelum fallback | Tingkat valid sesuai skema, akurasi field, taksonomi error |
| Peninjauan procurement atau keuangan | Rute model yang dipasangi pin dan telah ditinjau | Biaya sekunder dibandingkan auditabilitas | Async dapat diterima | Risiko tinggi | Tidak ada fallback otomatis tanpa persetujuan | Jejak sumber, versi model, log request, tanda tangan persetujuan reviewer |
| Ringkasan latar belakang | Rute biaya lebih rendah atau rute yang ramah batch | Minimalkan biaya per ringkasan yang diterima | Async | Risiko rendah hingga sedang | Fallback setelah anggaran retry habis | Kualitas sampel, tingkat retry, metrik cached-token |
Tabel ini bukan kebijakan final. Ini adalah permukaan keputusan. Setiap baris memerlukan gerbang yang terukur sebelum menjadi routing produksi.
Apa yang harus diputuskan oleh kebijakan routing model
Kebijakan routing model adalah aturan tertulis yang memetakan workflow ke kemampuan model, batas biaya, SLO latensi, perilaku fallback, dan persyaratan bukti. Kebijakan ini harus menjawab enam pertanyaan untuk setiap workflow produksi:
- Apa yang coba dioptimalkan oleh workflow: kecepatan, kualitas, biaya, keandalan, keamanan, modalitas, panjang konteks, atau auditabilitas?
- Kemampuan apa yang diperlukan: panggilan alat, output terstruktur, konteks panjang, input gambar, streaming, penalaran rendah, penalaran tinggi, atau dukungan endpoint khusus provider?
- Berapa anggaran kegagalan: retry, fallback, degradasi, antre, minta bantuan manusia, atau berhenti?
- Apa yang boleh berubah secara otomatis: provider, ukuran model, upaya penalaran, timeout, grup rute, atau tidak ada sama sekali?
- Apa yang harus dilog: model yang diminta, model yang dilayani, rute, status, unit penggunaan, biaya, percobaan fallback, dan pemilik?
- Bukti apa yang diperlukan sebelum peluncuran: skor evaluasi, sampel latensi, tes kuota, jejak penagihan, tinjauan keamanan, atau persetujuan procurement?
Pedoman GPT-5.5 OpenAI saat ini berguna di sini karena memperlakukan konfigurasi API sebagai bagian dari performa model, bukan sebagai renungan belakangan. Dokumentasi menyoroti penanganan state Responses API, reasoning effort, verbosity, structured outputs, prompt caching, desain alat, hosted tools, dan manajemen state sebagai faktor yang memengaruhi kecerdasan, keandalan, latensi, dan biaya. Itulah tepatnya dimensi yang harus dipertahankan oleh kebijakan routing model.
Dimensi kebijakan 1: risiko workflow
Risiko adalah pemisahan routing pertama karena hal ini mengontrol seberapa besar automasi yang diizinkan.
Workflow berisiko rendah biasanya dapat mentoleransi retry, rute yang lebih murah, dan fallback yang luas. Contohnya termasuk tagging internal, ringkasan ringan, saran draf, dan klasifikasi yang tidak kritis. Ini adalah kandidat yang baik untuk kontrol biaya agresif karena retry sesekali atau sampel tinjauan masih dapat diterima.
Workflow berisiko sedang membutuhkan tes penerimaan yang lebih kuat. Dukungan pelanggan, automasi workflow, saran kode, dan alat bantu penjualan mungkin tidak memerlukan tinjauan manusia setiap saat, tetapi tetap memerlukan pemeriksaan tone, pemeriksaan panggilan alat, dan bukti rute saat terjadi error.
Workflow berisiko tinggi harus lebih ketat dipatok. Tinjauan pengadaan, ringkasan hukum, persetujuan keuangan, keputusan keamanan, dan workflow yang diatur tidak boleh diam-diam beralih ke model atau penyedia lain hanya karena rute utama lambat. Kebijakan model routing harus mensyaratkan persetujuan eksplisit sebelum fallback mengubah postur risiko.
Aturan sederhananya: jika seorang manusia akan bertanya "model mana yang sebenarnya menjawab ini?" setelah hasil yang buruk, rute tersebut membutuhkan logging yang lebih kuat dan fallback otomatis yang lebih lemah.
Dimensi kebijakan 2: latensi dan pengalaman pengguna
Latensi termasuk dalam kebijakan karena model yang sama bisa dapat diterima untuk workflow asinkron dan tidak dapat diterima untuk produk interaktif.
Untuk chat interaktif, tetapkan ekspektasi p50, p95, timeout, dan streaming. Jika waktu ke token pertama penting, ukur secara terpisah dari total waktu penyelesaian. Untuk tugas latar belakang, tentukan maksimum waktu antre dan tenggat penyelesaian.
Jangan menetapkan aturan samar seperti "gunakan model yang cepat." Tulis kebijakan model routing sebagai target yang dapat diuji:
workflow: support_chat_triage
latency:
p95_first_token_ms: 1200
p95_complete_ms: 7000
timeout_ms: 10000
fallback:
on_timeout: use_reviewed_balanced_route
on_schema_error: retry_same_route_once
on_safety_or_policy_error: stop_and_escalate
Dokumentasi prompt caching OpenAI juga menjadi pengingat bahwa latensi bukan hanya soal pemilihan model. Prefix prompt yang stabil, cache key yang konsisten, dan pemantauan cache-hit dapat secara material mengubah latensi dan biaya token input untuk workload berulang. Jika caching menjadi bagian dari rencana, jadikan itu persyaratan kebijakan dan log metrik token yang di-cache.
Dimensi kebijakan 3: batas biaya
Kontrol biaya harus dinyatakan per hasil workflow, bukan hanya per token. Rute murah yang sering gagal bisa lebih mahal daripada rute yang lebih kuat dan berhasil pada percobaan pertama.
Gunakan tiga batas biaya:
| Batas | Contoh | Mengapa ini penting |
|---|---|---|
| Per request | Biaya maksimum untuk satu request, gambar, pekerjaan video, atau turn | Mencegah satu panggilan mengejutkan tim keuangan |
| Per workflow | Biaya maksimum untuk tiket, ekstraksi, jawaban, atau dokumen yang selesai | Memperhitungkan retry dan fallback |
| Per owner | Anggaran berdasarkan aplikasi, tim, pelanggan, lingkungan, atau kunci | Menjaga pengeluaran tetap terkait dengan akuntabilitas |
Halaman harga Flatkey berguna pada tahap ini karena memberikan tim model saat ini dan jalur peninjauan harga, sementara permukaan produk menekankan metering penggunaan, log request, analitik penggunaan, dan kontrol biaya. Sebelum routing ke produksi, periksa halaman /pricing yang الحالية dan konfirmasi baris model, keluarga endpoint, dan unit penggunaan untuk workflow yang sebenarnya.
Dimensi kebijakan 4: kecocokan kapabilitas
Desain kebijakan model routing harus dimulai dari kapabilitas yang dibutuhkan. Harga dan latensi baru penting setelah rute tersebut dapat menjalankan tugasnya.
Untuk setiap workflow, nilai kapabilitas berikut:
| Kapabilitas | Pertanyaan rute | Uji penerimaan |
|---|---|---|
| Penggunaan tool | Apakah rute memanggil tool yang diperlukan dengan benar? | Tingkat keberhasilan tool-call dan validasi argumen |
| Output terstruktur | Apakah rute memenuhi skema? | Tingkat JSON/skema valid plus akurasi tingkat field |
| Konsep panjang | Apakah rute mempertahankan instruksi dan konteks relevan? | Evaluasi dokumen panjang dengan sitasi atau field yang diharapkan |
| Vision atau file | Apakah rute menangani modalitas input yang sebenarnya? | Set sampel nyata dengan cakupan ukuran dan format |
| Streaming | Apakah rute mempertahankan bentuk event dan perilaku pemulihan? | Uji smoke SSE/streaming dan penanganan timeout |
| Perilaku keamanan | Apakah rute menolak atau melakukan eskalasi dengan benar? | Prompt red-team dan pengecekan penolakan/override |
Dokumentasi Structured Outputs OpenAI merekomendasikan output berbasis skema ketika aplikasi membutuhkan struktur yang andal. Untuk kebijakan routing, itu berarti rute yang tidak dapat memenuhi kontrak output seharusnya tidak digunakan untuk ekstraksi terstruktur hanya karena lebih murah.
Dimensi kebijakan 5: batas fallback
Fallback tidak otomatis baik. Ini dapat menyelamatkan uptime, tetapi juga dapat mengubah perilaku, penanganan konteks, harga, batas data, dukungan tool, atau bentuk output.
Tulis aturan fallback sebagai transisi eksplisit:
workflow: invoice_extraction
primary_route: extraction_schema_route
allowed_fallbacks:
- extraction_schema_route_backup
blocked_fallbacks:
- general_chat_route
- creative_writing_route
fallback_triggers:
retry_same_route_once:
- transient_5xx
- rate_limit
stop_and_queue:
- schema_invalid_after_retry
- unsupported_file_type
- compliance_flag
evidence:
log_requested_model: true
log_served_model: true
log_fallback_reason: true
log_usage_units: true
Kebijakan model routing yang matang memisahkan retry dari fallback. Retry berarti "coba kontrak yang sama lagi." Fallback berarti "ubah rutenya." Perubahan itu harus terlihat di log dan disetujui oleh pemilik workflow.
Dimensi kebijakan 6: observabilitas dan bukti penagihan
Routing tanpa bukti hanyalah tebakan. Kebijakan Anda harus mendefinisikan field yang harus diekspos oleh setiap request produksi.
| Bidang bukti | Mengapa ini termasuk dalam kebijakan |
|---|---|
| Nama workflow | Menghubungkan pengeluaran dan error ke suatu proses bisnis |
| App, tim, key, atau pemilik pelanggan | Memungkinkan chargeback dan kepemilikan insiden |
| Model yang diminta dan model yang dilayani | Menunjukkan apakah fallback atau substitusi route terjadi |
| Famili endpoint | Membedakan bentuk route chat, responses, image, video, Anthropic, Gemini, dan bentuk route lainnya |
| Status dan kelas error | Membedakan error penyedia, error gateway, penghentian kebijakan, dan error validasi |
| Satuan penggunaan | Memungkinkan finance merekonsiliasi penggunaan text, cache, image, audio, dan video |
| Dampak biaya atau saldo | Mengubah jejak engineering menjadi pengeluaran yang dapat ditinjau |
| Alasan fallback | Menjelaskan mengapa kebijakan mengubah route |
Template kebijakan routing model yang praktis
Gunakan template ini sebagai versi pertama dari standar routing internal Anda.
policy_name: customer_support_v1
owner:
team: support_platform
approver: product_and_finance
workflow:
description: classify, answer, and escalate support requests
environment: production
data_sensitivity: customer_content
route_selection:
primary_route: balanced_support_route
required_capabilities:
- tool_calling
- structured_outputs
- streaming
blocked_routes:
- experimental_models
- unreviewed_provider_routes
latency:
p95_first_token_ms: 1200
p95_complete_ms: 7000
cost:
max_cost_per_conversation: approved_budget
owner_key: support_platform_prod
risk:
human_review_required_when:
- refund_exception
- legal_or_policy_question
- confidence_below_threshold
fallback:
retry_same_route_once:
- transient_error
- rate_limit
fallback_to_backup_route:
- primary_route_unavailable
stop_without_fallback:
- safety_refusal
- schema_invalid_after_retry
- unapproved_data_region
evidence:
required_logs:
- workflow
- requested_model
- served_model
- endpoint_family
- route_status
- usage_units
- cost_or_balance
- fallback_reason
acceptance_tests:
min_eval_pass_rate: 0.95
max_schema_error_rate: 0.01
max_unreviewed_fallback_rate: 0
Nama route yang tepat akan berbeda menurut tim. Hal yang penting adalah kebijakan membuat pilihan model, fallback, biaya, latensi, dan bukti dapat ditinjau.
Acceptance test sebelum produksi
Jangan meluncurkan kebijakan routing model tanpa menjalankan test yang mensimulasikan jalur normal dan jalur gagal.
- Jalankan golden dataset melalui primary route dan catat kualitas, validitas skema, latensi, dan penggunaan.
- Picu jalur rate-limit atau transient-error dan verifikasi perilaku retry.
- Picu kegagalan skema dan pastikan kebijakan me-retry, berhenti, atau melakukan eskalasi seperti yang ditulis.
- Picu fallback yang diblokir dan pastikan gateway tidak mengubah route secara diam-diam.
- Bandingkan model yang diminta, model yang dilayani, famili endpoint, dan satuan penggunaan di log.
- Periksa apakah finance dapat merekonsiliasi sampel permintaan yang sama ke biaya, saldo prabayar, invoice, atau baris ekspor.
- Jalankan test rollback yang mengunci route sebelumnya atau menonaktifkan fallback.
Untuk konteks arsitektur gateway yang lebih mendalam, padukan daftar periksa ini dengan panduan Flatkey tentang AI API gateways, arsitektur LLM API gateway, dan load balancing dan failover AI API.
Di mana Flatkey berperan
Flatkey seharusnya tidak menggantikan kebijakan. Flatkey seharusnya membuat kebijakan lebih mudah ditegakkan dan ditinjau.
Gunakan Flatkey ketika tim menginginkan satu key untuk model AI yang terhubung, jalur peninjauan katalog harga dan model yang terkini, visibilitas penggunaan, bukti di tingkat request, kuota, dan percakapan penagihan yang lebih sederhana daripada akun provider yang tersebar. Kebijakan routing model tetap memerlukan penanggung jawab, tes penerimaan, batasan route, aturan fallback, dan rencana rollback.
Uji bukti Flatkey yang praktis terlihat seperti ini:
- Pilih satu workflow yang mirip produksi dan satu owner key.
- Konfirmasi baris model saat ini dan family endpoint di harga Flatkey.
- Kirim request normal, streaming, terstruktur, dan dengan kegagalan terkontrol jika workflow menggunakannya.
- Tinjau log request untuk model yang diminta, model yang dilayani, status, unit penggunaan, dan bukti fallback.
- Konfirmasi perilaku kuota dan peninjauan biaya atau saldo dengan pemilik workflow.
- Pindahkan hanya route yang telah diuji ke produksi, lalu perluas kebijakan baris demi baris.
Ini menjaga kebijakan routing model tetap berlandaskan bukti nyata, bukan diagram arsitektur.
Pertanyaan yang sering diajukan
Apa itu kebijakan routing model?
Kebijakan routing model adalah aturan tertulis yang memetakan setiap workflow AI ke route model yang disetujui, persyaratan kemampuan, batas biaya, target latensi, perilaku fallback, dan daftar periksa bukti.
Mengapa tidak merutekan setiap request ke model terkuat?
Route terkuat sering kali lebih lambat dan lebih mahal daripada yang dibutuhkan workflow. Kebijakan routing model memungkinkan workflow berisiko rendah menggunakan route yang efisien sambil mempertahankan route yang lebih kuat untuk penalaran berat, keputusan sensitif, atau pekerjaan bernilai tinggi.
Kapan fallback harus diblokir?
Blok fallback ketika perubahan route dapat mengubah penanganan data, postur kepatuhan, skema output, perilaku tool, kualitas yang terlihat oleh pengguna, atau kepemilikan penagihan. Dalam kasus-kasus tersebut, antrekan, ulangi, atau eskalasikan alih-alih mengubah route model secara diam-diam.
Seberapa sering tim harus memperbarui kebijakan routing model?
Tinjau setiap kali katalog model, unit harga, perilaku endpoint, persyaratan risiko, atau hasil eval berubah. Minimal, tinjau kebijakan produksi yang aktif setiap kuartal dan setelah migrasi model besar apa pun.
Metrik pertama apa yang harus dipantau?
Pantau biaya per hasil yang diterima, bukan hanya biaya per token. Lalu pasangkan dengan latensi p95, tingkat fallback, tingkat valid schema, dan bukti penagihan di tingkat request.
Bagaimana Flatkey membantu desain kebijakan routing model?
Flatkey dapat menyediakan satu permukaan gateway untuk akses model, peninjauan harga, routing, analitik penggunaan, log request, kuota, dan peninjauan penagihan. Itu memberi tim tempat praktis untuk memvalidasi apakah kebijakan routing model berjalan seperti yang tertulis.
Mulai dengan harga Flatkey, pilih satu workflow, lalu dapatkan key dan jalankan proof kecil yang memeriksa perilaku route, log, kuota, biaya, fallback, dan rollback sebelum peluncuran ke produksi.
