Playbook Fallback Multi-Model untuk API AI yang Andal

Poin utama

Lakukan retry pada rute yang sama hanya untuk kegagalan sementara seperti timeout dan respons 429.

Lakukan fail over ke model yang memenuhi persyaratan kapabilitas dan kontrak output yang sama.

Tetapkan anggaran maksimum biaya dan latensi untuk seluruh permintaan, bukan untuk setiap percobaan.

Catat penyedia, model, kelas error, jumlah retry, dan rute akhir untuk setiap permintaan.

Pisahkan retry dari fallback

Retry mengirim permintaan ke rute yang sama lagi karena kegagalannya mungkin bersifat sementara. Fallback mengubah penyedia atau model karena rute awal tidak tersedia atau tidak sesuai.

Memperlakukan kedua tindakan ini sebagai satu loop retry generik membuat insiden lebih sulit didiagnosis dan dapat melipatgandakan biaya tanpa meningkatkan tingkat keberhasilan.

Retry: timeout, koneksi terputus, 429, atau respons 5xx sementara.
Fallback: kegagalan penyedia berulang, masalah kapasitas model, atau pembatasan kebijakan.
Hentikan: permintaan tidak valid, parameter tidak didukung, atau validasi output gagal.

Bangun tabel rute yang kompatibel dengan kapabilitas

Model fallback harus dikelompokkan berdasarkan kapabilitas, bukan merek. Permintaan vision tidak dapat melakukan fallback ke model text-only, dan alur kerja JSON yang ketat tidak boleh dirutekan ke model yang secara rutin melanggar skema.

Modality input dan output yang diperlukan.
Konteks minimum dan panjang output.
Dukungan tool calling dan structured-output.
Harga dan latensi maksimum yang dapat diterima.

Terapkan satu anggaran di level permintaan

Anggaran permintaan harus mencakup setiap percobaan retry dan fallback. Sebelum memulai percobaan berikutnya, periksa apakah latensi dan anggaran biaya yang tersisa masih mendukungnya.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Ukur kualitas fallback, bukan hanya ketersediaan

Permintaan yang berhasil kembali tetap bisa menjadi kegagalan produk. Lacak validasi output, tingkat koreksi pengguna, dan penyelesaian tugas setelah peristiwa fallback.

Dashboard yang direkomendasikan: keberhasilan rute, tingkat fallback, p95 latensi, estimasi biaya, tingkat lolos validasi, dan skor kualitas per model.

Pertanyaan umum

Apakah setiap permintaan AI yang gagal harus menggunakan model fallback?

Tidak. Parameter tidak valid, input yang tidak didukung, dan pemeriksaan keamanan yang gagal harus segera dihentikan. Fallback tepat digunakan ketika rute lain yang kompatibel dapat dengan realistis menyelesaikan tugas yang sama.

Berapa banyak percobaan fallback yang sebaiknya diizinkan untuk permintaan AI?

Sebagian besar alur kerja interaktif sebaiknya membatasi totalnya menjadi dua atau tiga percobaan. Batas yang tepat bergantung pada anggaran latensi yang tersisa, nilai tugas, dan estimasi biaya.