Fallback Otomatis Antar Model AI Saat Provider Down

Fallback otomatis adalah mekanisme yang membuat aplikasi berpindah ke model AI cadangan ketika model utama gagal menjawab, tanpa menunggu kamu turun tangan.

Kenapa ini penting? Hampir semua aplikasi AI modern bergantung pada API pihak ketiga. Provider sesekali mengalami gangguan, kelebihan beban, atau membatasi laju permintaan. Kalau chatbot pelangganmu hanya punya satu jalur, gangguan di provider berarti chatbot ikut mati. Dengan fallback, pelanggan mungkin mendapat jawaban dari model lain yang sedikit berbeda gayanya, tetapi layanan tetap berjalan.

Kegagalan apa saja yang perlu ditangani?

Tidak semua error perlu disikapi sama. Sebagian cukup dicoba ulang, sebagian perlu pindah model, dan sebagian justru tidak boleh dicoba ulang karena kesalahannya ada di permintaanmu.

Membedakan kelompok terakhir penting. Mencoba ulang permintaan yang memang salah hanya membuang waktu dan biaya, dan bisa membuat kuotamu habis lebih cepat.

Tiga lapis pertahanan

Lapis 1: Retry dengan jeda

Banyak gangguan berlangsung singkat. SDK resmi seperti openai-python sudah melakukan retry otomatis untuk error tertentu (secara default 2 kali, bisa diubah dengan max_retries). Prinsipnya: tunggu sebentar, coba lagi, dan perpanjang jeda setiap kali gagal (exponential backoff). Jangan retry tanpa jeda, karena kamu justru menambah beban provider yang sedang kewalahan.

Lapis 2: Model atau provider cadangan

Kalau retry tetap gagal, pindahkan permintaan ke model lain. Urutan yang umum: model utama, lalu model sejenis dari provider berbeda, lalu model lokal atau model lebih kecil sebagai jalur terakhir. Memilih cadangan dari provider berbeda lebih tangguh daripada model lain dari provider yang sama, karena gangguan sering terjadi di level provider.

Lapis 3: Cooldown

Kalau satu jalur gagal berkali-kali dalam waktu singkat, berhenti mencobanya untuk sementara. Pola ini mirip circuit breaker: permintaan berikutnya langsung diarahkan ke cadangan tanpa menunggu timeout di jalur yang jelas sedang bermasalah. Setelah jeda tertentu, jalur utama dicoba lagi.

Contoh konfigurasi dengan LiteLLM

Menulis semua logika di atas sendiri bisa, tetapi lebih rapi bila diletakkan di AI gateway, sehingga setiap aplikasi otomatis mendapat perlindungan yang sama. Dengan LiteLLM Proxy (cara pasangnya di panduan memasang LiteLLM), konfigurasinya kira-kira begini:

model_list:
  - model_name: utama
    litellm_params:
      model: openai/NAMA_MODEL_UTAMA
      api_key: os.environ/OPENAI_API_KEY
  - model_name: cadangan
    litellm_params:
      model: anthropic/NAMA_MODEL_CADANGAN
      api_key: os.environ/ANTHROPIC_API_KEY
  - model_name: darurat
    litellm_params:
      model: ollama_chat/llama3.2:3b
      api_base: http://IP_SERVER_OLLAMA:11434

litellm_settings:
  num_retries: 2
  request_timeout: 30

router_settings:
  fallbacks: [{"utama": ["cadangan", "darurat"]}]
  allowed_fails: 3
  cooldown_time: 60

Aplikasi cukup memanggil model utama. Bila gagal setelah retry, LiteLLM mencoba cadangan, lalu darurat. Jalur yang gagal lebih dari allowed_fails kali dalam rentang cooldown_time detik akan dilewati sementara. Dokumentasi LiteLLM juga menyediakan context_window_fallbacks untuk kasus konteks terlalu panjang dan content_policy_fallbacks untuk penolakan kebijakan konten.

Hal yang sering terlupa

• Batas waktu yang realistis. Tanpa timeout, permintaan bisa menggantung lama sebelum fallback sempat berjalan. Sesuaikan dengan jenis tugas: chat butuh cepat, ringkasan dokumen panjang boleh lebih lama.
• Streaming. Kalau jawaban sudah setengah terkirim lalu putus, pindah model di tengah jalan bisa membuat jawaban ganda atau tidak nyambung. Tentukan apakah aplikasi mengulang dari awal atau menampilkan pesan error yang sopan.
• Biaya cadangan. Model cadangan bisa lebih mahal per token. Pantau seberapa sering fallback terjadi agar tagihan tidak mengejutkan. Tips menekan biaya ada di cara menghemat biaya token API.
• Data sensitif. Kalau data tertentu hanya boleh diproses model lokal, jangan masukkan provider eksternal ke rantai fallback-nya.
• Pesan terakhir untuk pengguna. Saat semua jalur gagal, tampilkan pesan yang jelas dan tawarkan jalur lain, misalnya kontak admin, daripada error teknis.

Bagaimana menguji fallback?

Fallback yang tidak pernah diuji sering gagal tepat saat dibutuhkan. Dokumentasi LiteLLM per 7 November 2026 menyebut flag simulasi fallback kini hanya untuk pemanggilan SDK langsung, sehingga untuk proxy kamu perlu memicu error sungguhan di lingkungan uji. Caranya sederhana:

1. Siapkan salinan konfigurasi di server staging.
2. Isi kunci API model utama dengan nilai salah, atau arahkan api_base ke alamat yang tidak aktif. Kunci salah menghasilkan error 401, jadi cek apakah versi LiteLLM-mu mengalihkan error jenis ini. Alamat yang tidak aktif lebih mirip gangguan sungguhan.
3. Kirim permintaan dan periksa log: apakah retry terjadi, lalu berpindah ke cadangan?
4. Ukur waktu total sampai jawaban diterima. Kalau terlalu lama, turunkan timeout atau jumlah retry.
5. Ulangi pengujian setiap kali mengganti model atau versi LiteLLM.

Prinsip yang sama berlaku untuk server sendiri. Konsep redundansi yang lebih luas dibahas di apa itu high availability.