Bulan lalu saya mengambil alih sebuah proyek layanan pelanggan cerdas, dan pihak bisnis meminta untuk mengintegrasikan tiga model besar sekaligus: DeepSeek, Tongyi Qianwen, dan Doubao, dengan alasan "mana yang lebih murah pakai itu, mana yang kena rate limit beralih ke yang lain". Kedengarannya masuk akal, tapi begitu mulai dikerjakan baru sadar: cara autentikasi, skema penagihan, dan strategi timeout serta retry dari ketiga SDK itu benar-benar tiga logika yang berbeda. DeepSeek menggunakan Bearer Token, Tongyi lewat API-KEY plus signature dari DashScope, sedangkan field autentikasi Doubao berbeda lagi. Dari sisi penagihan, ada yang menghitung token input dan output secara terpisah, ada yang menggabungkan perhitungannya, dan ada juga yang memberi diskon saat cache hit. Timeout lebih merepotkan lagi, satu default-nya 30 detik, satu lagi 60 detik, jumlah retry dan strategi backoff semuanya harus ditulis sendiri.
Setelah kode selesai ditulis, saya hitung-hitung, hanya lapisan adaptasi untuk membungkus tiga klien itu saja sudah lebih dari 800 baris, belum termasuk pemetaan kode error. Inilah alasan mengapa konsep model gateway, sejak tahun lalu, terus dibicarakan di kalangan engineering AI dalam negeri. Ringkasnya dalam satu kalimat: model gateway adalah lapisan perantara yang menyembunyikan perbedaan dari berbagai API model besar, dan mengekspos antarmuka yang seragam ke lapisan bisnis di atasnya.
Koneksi Langsung, Bangun Sendiri, Platform Agregasi: Tiga Biaya Engineering dari Tiga Pendekatan
Pertama, mari bicara tentang koneksi langsung ke SDK resmi. Tiga model berarti tiga set autentikasi, tiga set penanganan error, tiga set logika retry. Di dalam kode bisnis penuh dengan if-else untuk menentukan mau lewat yang mana. Menambah satu model baru berarti lapisan adaptasi harus diubah lagi. Kami sudah menghitung, memelihara kode adaptasi untuk tiga koneksi langsung menghabiskan sekitar 15% dari total beban kerja backend proyek. Jika jumlah model mencapai lima atau lebih, proporsi ini akan lepas kendali.
Membangun gateway sendiri adalah pilihan kedua. Ide intinya adalah menulis sendiri satu lapisan proxy, yang meneruskan request ke API masing-masing penyedia. Keuntungannya terkendali, kerugiannya adalah Anda harus menangani sendiri konversi protokol, rotasi kunci, antrian rate limiting, dan statistik penggunaan. Kami sudah mengevaluasi secara internal, sebuah gateway buatan sendiri yang layak produksi setidaknya membutuhkan dua engineer dengan investasi enam sampai delapan minggu, dan setelahnya masih harus terus memelihara perubahan versi API dari masing-masing penyedia. Untuk tim kecil dan menengah, hitungan ini kurang menguntungkan.
Yang ketiga adalah platform agregasi AI API. Platform semacam ini membungkus API dari berbagai model besar secara terpadu, dan menyediakan satu set antarmuka ke luar. Biaya engineeringnya paling rendah, siklus integrasinya biasanya dihitung dalam hitungan hari. Di proyek kami menggunakan SiCore TokenWorks, yang kompatibel dengan OpenAI SDK, cukup ubah satu baris base_url untuk beralih. Di sini ada satu jebakan yang perlu diperhatikan: platform agregasi yang berbeda memiliki strategi default yang berbeda untuk timeout dan retry. Sebelum integrasi, pastikan apakah platform mendukung kustomisasi waktu timeout, jika tidak, request dengan respons panjang yang kadang muncul di produksi akan diputus lebih awal oleh lapisan platform, dan pesan error-nya bahkan tidak bisa menunjukkan apakah itu timeout gateway atau timeout model.
Empat Kemampuan Inti Model Gateway
Normalisasi protokol adalah dasarnya. Menyatukan format request, format response, dan kode error dari masing-masing penyedia menjadi satu set standar. Dalam kondisi ideal, lapisan bisnis di atasnya hanya mengenal satu format antarmuka, dan beralih model hanya mengubah konfigurasi tanpa mengubah kode. Inilah alasan antarmuka yang kompatibel dengan OpenAI populer di dalam negeri, hampir semua toolchain ekosistem mendukung format ini.
Strategi routing adalah nilai jual dari gateway. Bisa routing berdasarkan jenis tugas, misalnya tanya jawab sederhana lewat Doubao, penalaran kompleks lewat DeepSeek; bisa juga routing berdasarkan biaya, mana yang harganya sedang rendah lewat yang itu; bisa juga routing berdasarkan ketersediaan, ketika satu penyedia kena rate limit otomatis beralih ke cadangan. Saat kami menguji routing multi-model SiCore TokenWorks, kami menemukan bahwa strategi pemisahan berdasarkan kompleksitas tugas, dalam skenario layanan pelanggan, dapat menekan biaya pemanggilan keseluruhan cukup signifikan, karena sebagian besar pertanyaan sederhana tidak perlu memanggil model dengan kemampuan penalaran terkuat.
Rate limiting, degradasi, dan agregasi penggunaan adalah kebutuhan mutlak di lingkungan produksi. Rate limiting harus bisa mengenali error 429 dan otomatis mengantri serta retry, degradasi harus bisa beralih ke model cadangan ketika satu layanan tidak tersedia. Sedangkan agregasi penggunaan adalah menyatukan volume pemanggilan, konsumsi token, dan biaya yang tersebar di berbagai penyedia, untuk memudahkan perhitungan biaya dan kontrol anggaran. Dua hal ini kalau dibangun sendiri beban kerjanya tidak sedikit, terutama agregasi penggunaan, karena skema penagihan masing-masing penyedia tidak sama, logika rekonsiliasinya harus ditulis terpisah.
Implementasi Bertahap Sesuai Kematangan Bisnis
Jika proyek baru dimulai dan hanya terhubung ke satu model, koneksi langsung ke SDK resmi sudah cukup, tidak perlu pakai gateway, menambah satu lapisan justru menambah satu titik kegagalan. Setelah bisnis stabil dan ingin terhubung ke model kedua, baru pertimbangkan untuk memperkenalkan lapisan gateway, saat itu biaya peralihannya masih rendah.
Jika bisnis sudah terhubung ke tiga penyedia atau lebih, dan ada persyaratan ketersediaan, disarankan langsung menggunakan platform agregasi AI API, dan mengalihdayakan biaya adaptasi serta operasional. Saat memilih, fokus pada tiga hal: apakah kompatibel dengan OpenAI SDK, apakah mendukung kustomisasi timeout dan retry, apakah statistik penggunaannya jelas. Adapun gateway buatan sendiri, kecuali ada persyaratan kepatuhan khusus atau tim memiliki tenaga operasional yang cukup, tidak disarankan untuk diinvestasikan pada tahap awal bisnis.
Model gateway menyelesaikan masalah kompleksitas engineering dari integrasi multi-model, bukan masalah kemampuan model. Memilih solusi yang tepat memungkinkan tim mengembalikan fokus ke logika bisnis itu sendiri.