Ketika Model AI Anda Lenyap dalam Semalam: Mendesain Failover untuk API AI

Pada 12 Juni 2026, kontrol ekspor AS memaksa Anthropic menonaktifkan Claude Fable 5 hampir tanpa peringatan, dan model tersebut tetap tidak aktif hingga kembali pada 1 Juli. Tim yang telah mengkodekan string model tertentu menghabiskan sembilan belas hari untuk berebut; tim dengan rantai failover membalik nilai konfigurasi dan kembali bekerja.

Pelajaran ini lebih besar dari satu insiden. Sebagian besar aplikasi berbasis LLM memperlakukan ketersediaan model sebagai konstanta, seperti DNS atau gravitasi. Itu adalah asumsi arsitektur, dan itu salah. Model adalah produk dengan eksposur hukum, batasan kapasitas, jadwal dekomisi, dan tim keamanan yang dapat menariknya kembali. Panduan ini membahas cara merancang failover untuk API AI sehingga hilangnya model berikutnya, penyedia mana pun yang terpengaruh, hanya membutuhkan perubahan konfigurasi alih-alih jembatan insiden.

Mengapa model menghilang

Model menghilang karena lebih banyak alasan daripada yang direncanakan sebagian besar tim:

• Regulasi. Penangguhan Fable 5 berasal dari kontrol ekspor, bukan kegagalan teknis. Peristiwa hukum dan kepatuhan tidak mengikuti jadwal dekomisi, dan mereka tidak mengirimkan pemberitahuan 90 hari. Berikut tampilan insiden tersebut dari luar saat sedang terjadi.
• Insiden penyedia. Setiap penyedia utama pernah mengalami gangguan berjam-jam. SLA Anda dengan pelanggan Anda tidak berhenti saat layanan mereka pulih.
• Dekomisi. Penyedia menghentikan model sesuai jadwal yang dipublikasikan. OpenAI mempertahankan halaman dekomisi yang terus diperbarui, dan Anthropic telah menghentikan versi Claude yang lebih lama dengan cara yang sama. Dekomisi adalah insiden yang bergerak lambat dengan tanggal kalender.
• Kapasitas. Selama minggu peluncuran dan lonjakan lalu lintas, penyedia mengurangi beban. Permintaan Anda mulai mengembalikan 429 dan 529 meskipun model "ada".
• Rollback keamanan. Penyedia dapat memblokir atau menarik model setelah menemukan masalah pasca-peluncuran. Ini terjadi secara diam-diam dan terkadang per akun.

Penyebab yang berbeda, gejala yang sama: ID model yang diandalkan kode Anda berhenti merespons. Perbaikannya sama terlepas dari penyebabnya, itulah sebabnya desain failover adalah pekerjaan abadi daripada respons insiden.

Hierarki failover

Failover bukanlah satu keputusan. Ada tiga level, dan sistem yang matang biasanya mengimplementasikan lebih dari satu.

Level 1: fallback penyedia yang sama. Rute ke model sejenis dari vendor yang sama, misalnya Fable 5 → Opus 4.8 → Sonnet 4.6. SDK yang sama, otentikasi yang sama, bentuk respons yang sama, sehingga peralihan murah dan cepat. Anthropic bahkan mendukung ini di sisi server melalui parameter fallbacks yang mencoba kembali permintaan yang ditolak pada model pengganti dalam panggilan API yang sama. Ketahui pasangan fallback Anda sebelum Anda membutuhkannya: perbandingan Fable 5 vs Opus 4.8 adalah jenis pekerjaan rumah yang membuahkan hasil pada pukul 3 pagi.

Level 2: fallback lintas penyedia. Rute ke vendor yang sama sekali berbeda. Ini melindungi dari gangguan di seluruh penyedia, penangguhan akun, dan pembatasan regional yang tidak dapat ditangani oleh rantai penyedia yang sama. Biayanya adalah SDK kedua, hubungan penagihan kedua, jalur otentikasi kedua, dan prompt yang berperilaku berbeda.

Level 3: mode terdegradasi. Sajikan sesuatu yang berguna tanpa model frontier sama sekali: jawaban yang di-cache untuk kueri berulang, model lokal kecil untuk tugas tingkat klasifikasi, atau fitur yang dinonaktifkan di balik pesan yang jelas. Fitur yang memburuk dapat diterima. Aplikasi yang rusak tidak.

Sebagian besar tim harus meluncurkan level 1 kuartal ini, menjaga level 3 sebagai batas bawah, dan hanya menambahkan level 2 ketika pendapatan yang berisiko membenarkan integrasi kedua.

Satu poin desain lagi: definisikan kondisi pemicu, bukan hanya tujuan. Sebuah rantai tidak lengkap sampai Anda memutuskan apa yang menggerakkan lalu lintas di dalamnya. Default yang masuk akal: 404 pada ID model segera gagal, penolakan mencoba kembali sekali pada model berikutnya, 429 mundur sebelum gagal, dan tiga batas waktu berturut-turut membuka pemutus sirkuit untuk model tersebut. Kodekan aturan-aturan itu di lapisan perutean sehingga keputusan pukul 3 pagi sudah dibuat.

Langkah desain yang membuat failover murah

Failover bisa murah atau mahal tergantung pada keputusan yang Anda buat jauh sebelum terjadinya gangguan.

Letakkan ID model di konfigurasi, bukan di kode. Jalankan grep cepat untuk string model Anda. Jika muncul di kode aplikasi daripada satu file konfigurasi, Anda tidak dapat melakukan failover tanpa penerapan. Daftar prioritas per rute adalah bentuk yang berhasil:

# config/model-routes.yaml
routes:
  chat-assist:
    primary: claude-fable-5
    fallbacks:
      - claude-opus-4-8
      - claude-sonnet-4-6
    degraded_mode: cached_answers
    max_output_tokens: 8192
    timeout_seconds: 120
  ticket-classifier:
    primary: claude-sonnet-4-6
    fallbacks:
      - claude-haiku-4-5
    degraded_mode: rules_engine

Kendalikan perutean di satu tempat. Baik itu layanan gateway atau wrapper seratus baris, hanya satu modul yang harus memutuskan model mana yang melayani permintaan, dan yang lainnya harus memanggilnya. Versi minimal terlihat seperti ini:

MODEL_CHAIN = ["claude-fable-5", "claude-opus-4-8", "claude-sonnet-4-6"]

def complete(prompt: str) -> str:
    last_error = None
    for model in MODEL_CHAIN:
        try:
            response = client.messages.create(
                model=model,
                max_tokens=8192,
                messages=[{"role": "user", "content": prompt}],
            )
            if response.stop_reason == "refusal":
                last_error = RefusalError(model)
                continue  # coba model berikutnya dalam rantai
            return response.content[0].text
        except (anthropic.NotFoundError, anthropic.RateLimitError,
                anthropic.APIStatusError) as err:
            last_error = err
            continue
    raise AllModelsUnavailable(MODEL_CHAIN) from last_error

Versi produksi menambahkan pemutus sirkuit dan batas waktu per model, tetapi prinsipnya berlaku untuk ukuran apa pun: pemanggil meminta penyelesaian, bukan model.

Tulis prompt berjenjang kemampuan. Prompt yang bergantung pada keanehan satu model membuat failover Anda menjadi fiksi. Tulis prompt inti yang menghasilkan output yang dapat diterima di seluruh set fallback Anda, lalu pisahkan trik khusus model (konfigurasi pemikiran tertentu, kebiasaan pemformatan yang telah Anda sesuaikan) dalam overlay per-model yang dapat dihilangkan tanpa merusak tugas. Uji prompt dasar pada fallback terlemah Anda, bukan yang terkuat. Ini lebih penting daripada kedengarannya: model frontier yang lebih baru seringkali menghargai prompt yang jarang dan berorientasi tujuan, sementara fallback yang lebih kecil membutuhkan struktur yang lebih eksplisit. Jika Anda menyetel semuanya untuk yang utama, fallback mewarisi instruksi yang tidak dapat diikutinya dengan baik; jika Anda menyetel untuk seluruh set, Anda kehilangan sedikit polesan pada yang utama dan mendapatkan rantai yang bekerja dari ujung ke ujung.

Jaga agar parameter permintaan juga portabel. Prompt bukanlah satu-satunya permukaan khusus model. Konfigurasi pemikiran, parameter pengambilan sampel, dan batas output berbeda di antara generasi model, dan parameter yang diterima oleh yang utama dapat mengembalikan 400 pada fallback. Simpan set parameter per-model di samping ID model dalam konfigurasi, dan minta lapisan perutean menerapkannya pada waktu pengiriman. Failover yang mati karena kesalahan parameter yang tidak valid adalah failover yang tidak Anda miliki.

Tangani respons secara agnostik penyedia. Normalisasi respons ke dalam bentuk internal Anda sendiri di batas perutean: teks keluar, bidang terstruktur divalidasi, alasan berhenti dipetakan ke enum Anda sendiri. Kode yang menjangkau objek respons spesifik penyedia dari dua belas tempat akan rusak pada hari Anda mengganti penyedia.

Anggarkan perbedaan biaya dan batas. Model fallback berbeda dalam harga per token, jendela konteks, dan output maksimum. Jatuh dari Fable 5 ke Opus 4.8 mengurangi biaya per-token kira-kira setengahnya, sementara Sonnet 4.6 lebih murah lagi tetapi membatasi output lebih rendah; periksa gambaran umum model saat ini daripada mempercayai angka dari ingatan. Lapisan perutean Anda harus membawa max_output_tokens per-model dan perilaku pemotongan sehingga fallback tidak secara diam-diam menghasilkan jawaban yang terpotong atau tagihan yang mengejutkan.

Pengujian kontrak di seluruh set fallback Anda

Jalur failover yang tidak pernah Anda latih adalah jalur yang akan gagal saat Anda membutuhkannya. Perlakukan rantai fallback Anda sebagai kontrak API dan ujilah seperti itu.

Pola yang berfungsi: simpan satu skenario pengujian di Apidog yang menjalankan prompt kritis Anda terhadap setiap model dalam rantai fallback, sesuai jadwal dan di CI. Untuk setiap model, pastikan tiga hal:

• Skema. Respons diuraikan, bidang yang diperlukan ada, dan output terstruktur divalidasi terhadap Skema JSON Anda. Ini menangkap kerusakan halus, seperti model fallback yang meng-escape JSON secara berbeda atau menghilangkan bidang yang diasumsikan oleh parser Anda.
• Latensi. p95 tetap di bawah anggaran yang Anda tetapkan untuk model tersebut. Fallback yang secara teknis berfungsi tetapi membutuhkan waktu 40 detik adalah jenis insiden yang berbeda.
• Sinyal kualitas. Pemeriksaan mekanis yang murah: output tidak kosong, dalam bahasa yang benar, berisi elemen yang diperlukan, dan tingkat penolakan di seluruh set prompt tetap mendekati garis dasar. Anda tidak menilai kefasihan di CI; Anda mendeteksi model yang berhenti melakukan pekerjaannya.

Strukturkan dengan satu lingkungan Apidog per model atau penyedia, menyimpan URL endpoint, kunci API, dan ID model sebagai variabel lingkungan. Skenario yang sama kemudian berjalan tanpa perubahan terhadap claude-fable-5, claude-opus-4-8, dan claude-sonnet-4-6 dengan beralih lingkungan, dan menambahkan model keempat ke rantai berarti menambahkan lingkungan, bukan menulis tes baru.

Pilih set prompt dengan sengaja. Anda tidak memerlukan ratusan kasus; Anda memerlukan sepuluh hingga dua puluh prompt yang mewakili lalu lintas produksi Anda: konteks terpanjang yang Anda kirim, output terstruktur paling ketat yang Anda parse, kasus batas yang pernah merusak parser Anda, dan setidaknya satu prompt di dekat batas sensitif domain Anda sehingga penyimpangan penolakan muncul dalam uji coba daripada tiket dukungan. Versikan set ini di samping prompt Anda, dan ketika produksi mengejutkan Anda, tambahkan kasus yang mengejutkan ke suite.

Ada bonus selama insiden: arahkan satu lingkungan ke server tiruan yang mengembalikan respons yang direkam, dan CI Anda terus memvalidasi segala sesuatu di hilir model saat penyedia tidak aktif. Apidog dapat menghasilkan tiruan itu dari spesifikasi API yang sama dengan yang sudah digunakan oleh tes Anda, sehingga insiden tidak juga memblokir pipeline rilis Anda.

Pada 12 Juni, perbedaan antara tim yang tenang dan tim yang panik bermuara pada hal ini. Beberapa memiliki bukti harian bahwa jalur Opus 4.8 mereka menghasilkan output yang valid untuk prompt teratas mereka. Yang lain hanya punya harapan.

Kesiapan operasional

Arsitektur memberi Anda kemampuan untuk melakukan failover. Operasi membuat keputusan dibuat dengan cepat dan bersih.

• Uji setiap model, bukan hanya yang utama. Jalankan prompt sintetis terjadwal terhadap setiap model dalam rantai, terpisah dari lalu lintas pengguna. Halaman status penyedia seperti status.anthropic.com berguna, tetapi mereka tertinggal, dan mereka menjelaskan dunia penyedia, bukan akun, wilayah, atau tingkat batas tarif Anda. Probe Anda sendiri gagal lebih dulu.
• Peringatkan tentang tingkat penolakan dan kesalahan, bukan hanya 5xx. Masalah tingkat model sering muncul sebagai tingkat penolakan yang meningkat, semburan kesalahan 404 model_not_found, atau 429, sementara dasbor tingkat HTTP tetap hijau.
• Tulis runbook cutover sebelum Anda membutuhkannya. Siapa yang memutuskan untuk melakukan failover, nilai konfigurasi mana yang berubah, apa yang dikatakan pengumuman kepada dukungan dan pelanggan, dan dasbor mana yang harus diawasi selama jam pertama. Selama gangguan Fable 5, tim tanpa runbook kehilangan lebih banyak waktu untuk memutuskan daripada untuk melakukan.
• Tahap pengembalian. Ketika yang utama kembali, jangan membalik 100% lalu lintas dalam satu gerakan. Canary sebagian kecil, bandingkan kualitas dan metrik penolakan terhadap baseline fallback Anda, lalu tingkatkan. Kami membahas mekanisme proses itu di cara beralih kembali ke API Fable 5, dan polanya berlaku untuk setiap utama yang kembali.
• Latihlah. Sekali dalam seperempat tahun, lakukan failover dengan sengaja di staging, atau di produksi untuk sebagian kecil lalu lintas jika toleransi risiko Anda memungkinkan. Latihan akan mengungkap kunci API yang kedaluwarsa di akun fallback, dasbor yang tidak dapat ditemukan siapa pun, dan nilai konfigurasi yang diganti namanya enam bulan lalu. Setiap hal tersebut lebih murah untuk ditemukan pada hari Selasa yang tenang.

Apa yang secara khusus diajarkan oleh episode Fable 5

Pengembalian 1 Juli membawa detail yang layak dibangun kebijakan di sekitarnya: Anthropic menerapkan kembali Fable 5 dengan pengklasifikasi keamanan yang dilatih ulang. ID model yang sama, permukaan API yang sama, tetapi bukan model yang sama persis yang offline. Batas penolakan bergerak. Prompt yang berhasil pada awal Juni bisa mendarat secara berbeda pada Juli, dan beberapa penolakan yang dulu aktif tidak lagi terjadi.

Aturan yang muncul dari ini: uji ulang saat kembali, jangan aktifkan kembali. Model yang kembali dari ketidakhadiran apa pun, baik penangguhan, rollback, atau jeda dekomisi yang panjang, harus diperlakukan sebagai versi model baru. Jalankan suite kontrak lengkap terhadapnya. Bandingkan metrik penolakan dan kualitas dengan baseline sebelum insiden Anda, bukan dengan angka fallback Anda. Canary sebelum Anda meningkatkan.

Ada pelajaran kedua yang lebih tenang. Sembilan belas hari cukup lama bagi fallback Anda untuk menjadi baseline de facto Anda. Pengguna beradaptasi dengan perilaku Opus 4.8; tim internal menyetel prompt terhadapnya. Pengembalian bukan hanya peristiwa teknis, tetapi juga perubahan produk, dan itu pantas mendapatkan perhatian yang sama seperti meluncurkan produk baru.

FAQ

Apakah rantai fallback penyedia yang sama sudah cukup, atau apakah saya memerlukan penyedia kedua?

Mulailah dengan penyedia yang sama. Ini mencakup dekomisi, insiden kapasitas, rollback keamanan, dan penangguhan khusus model dengan sebagian kecil dari biaya rekayasa, dan fitur seperti fallback sisi server Anthropic membuatnya hampir gratis untuk diadopsi. Tambahkan jalur lintas penyedia ketika gangguan penyedia penuh atau peristiwa tingkat akun akan merugikan Anda lebih dari biaya pemeliharaan integrasi kedua. Mode terdegradasi layak dibangun dalam kedua kasus.

Akankah pengguna menyadari ketika lalu lintas gagal beralih ke model yang lebih kecil?

Itu tergantung pada tugasnya, jadi ukur alih-alih menebak. Untuk ekstraksi dan klasifikasi, model yang lebih kecil dengan prompt yang baik seringkali tidak dapat dibedakan. Untuk penalaran bentuk panjang, kesenjangan terlihat; tolok ukur seperti perbandingan Fable 5 vs Opus 4.8 kami memberi Anda peta awal. Prompt berjenjang kemampuan dan teks UI yang jujur ("respons mungkin lebih singkat saat ini") semakin mempersempit kesenjangan yang dirasakan.

Seberapa sering jalur fallback harus diuji?

Setiap malam sesuai jadwal, di CI pada setiap perubahan prompt atau konfigurasi perutean, dan segera setelah pengumuman penyedia apa pun yang menyentuh rantai Anda. Biaya token untuk menjalankan dua puluh prompt teratas Anda terhadap tiga model sangat kecil dibandingkan dengan menemukan fallback yang rusak selama gangguan.

Ketersediaan model akan menjadi kurang dapat diprediksi, bukan lebih: regulasi yang lebih ketat, siklus rilis dan dekomisi yang lebih cepat, dan kapasitas yang berfluktuasi dengan setiap peluncuran. Tim yang berhasil melewati momen Fable 5 berikutnya adalah tim yang memperlakukan model sebagai komponen yang dapat diganti dengan cadangan yang telah diuji, bukan perlengkapan permanen. Pekerjaan ini cocok di file konfigurasi, wrapper perutean, dan suite kontrak yang berjalan setiap malam. Unduh Apidog dan sambungkan rantai fallback Anda ke tes terjadwal hari ini; gangguan berikutnya hanya masalah waktu.