Jika Anda sedang membangun backend untuk integrasi multi-model, kemungkinan besar Anda pernah mengalami kehancuran ini: kode bisnis dipenuhi dengan if (vendor === 'openai') ... else if (vendor === 'claude') ..., satu antarmuka percakapan streaming ditulis dengan delapan ratus baris logika adaptasi, dan setiap kali menambahkan vendor baru, Anda harus mengubah seluruh jalur inti. Masalahnya bukan pada Anda, tetapi pada fakta bahwa protokol API dari berbagai model besar memang tidak pernah dirancang untuk disatukan.
Esensi dari gateway model adalah sebuah lapisan terjemahan protokol: mengubah request/response heterogen dari N vendor menjadi 1 set protokol standar internal. Artikel ini membahas secara bertahap dalam tiga bagian—prinsip, praktik, dan perbandingan—untuk menjelaskan dengan jelas bagaimana lapisan terjemahan seharusnya dibangun.
1. Empat Jenis Titik Heterogen: Mengapa Koneksi Langsung ke Banyak Vendor Pasti Tidak Terkendali
Mari kita lihat perbedaan nyata, masing-masing dengan angka.
Metode autentikasi: OpenAI menggunakan Authorization: Bearer sk-xxx, dengan panjang field header sekitar 51 karakter; Claude menggunakan x-api-key; Gemini menempatkan key di parameter query URL ?key=; Qwen dan ERNIE menggunakan Authorization tetapi algoritma signature-nya berbeda, access_token ERNIE berlaku default 30 hari, dan jika kedaluwarsa mengembalikan kode error 110. Empat vendor, empat cara penulisan.
Format pemotongan streaming SSE: chunk OpenAI adalah data: {"choices":[{"delta":{"content":"x"}}]}, dengan penanda akhir data: [DONE]; tipe event Claude adalah event: content_block_delta dengan data: {"delta":{"text":"x"}}, nama field berubah dari content menjadi text; Gemini menempatkan increment di candidates[0].content.parts[0].text, bersarang 3 lapis lebih dalam. Lapisan bisnis harus menulis empat set parser untuk mengurai kalimat yang sama.
Sistem kode error: ini yang paling menjengkelkan. OpenAI menggunakan status code HTTP + error.type, rate limit adalah 429; Claude mengembalikan 429 untuk rate limit tetapi type di body adalah rate_limit_error; Qwen untuk rate limit mungkin mengembalikan status code 200 tetapi dengan code: "Throttling" di body; ERNIE menggunakan error_code: 17 untuk menunjukkan kuota terlampaui. Hal yang sama, empat ekspresi berbeda.
Standar statistik Token: usage.total_tokens = prompt + completion pada OpenAI, baik bahasa Mandarin maupun Inggris dipotong berdasarkan BPE; Claude mengembalikan input_tokens dan output_tokens secara terpisah, dan granularitas pemotongan karakter Mandarin lebih halus, untuk paragraf Mandarin 500 karakter yang sama, jumlah token yang dihitung oleh kedua vendor bisa berbeda 20% hingga 35%. Dalam penagihan berbasis penggunaan, perbedaan ini langsung menjadi kesalahan tagihan.
Dengan koneksi langsung ke empat vendor, jumlah kode di lapisan bisnis akan membengkak menjadi 3 hingga 4 kali lipat dibandingkan satu vendor, dan biaya pemeliharaan meningkat secara linear seiring jumlah vendor.
2. Desain Lapisan Terjemahan: Format Terpadu, Normalisasi Streaming, Pemetaan Kode Error, Agregasi Penggunaan
Lapisan terjemahan harus melakukan empat hal, tidak boleh ada yang kurang.
Format request/response terpadu: mendefinisikan satu set Schema standar secara internal, dengan field yang selaras dengan gaya OpenAI (karena ekosistemnya paling luas). Request eksternal masuk dan terlebih dahulu diubah ke format internal, kemudian oleh adapter diubah ke format masing-masing vendor. Pola adapter, satu kelas per vendor, mengimplementasikan dua metode buildRequest() dan parseResponse().
Normalisasi pemotongan streaming: intinya adalah mengubah chunk SSE dari setiap vendor menjadi {delta: string, finish_reason: string|null} yang terpadu. Caranya adalah menulis state machine, yang mendistribusikan ke parser berbeda berdasarkan tipe vendor, dan mengeluarkan struktur terpadu. Poin kuncinya adalah penanganan batas: pemisah \n\n pada SSE, prefiks data:, penggabungan data multi-baris, semua ini harus ditangani di dalam parser. Jebakan yang pernah saya alami adalah event ping dan message_stop dari Claude, jika tidak diabaikan secara eksplisit, akan mendorong delta kosong ke frontend dan menyebabkan UI berkedip.
Tabel pemetaan kode error: memelihara pemetaan vendorCode -> unifiedCode, disatukan menjadi 6 kategori: AUTH_FAILED, RATE_LIMITED, QUOTA_EXCEEDED, INVALID_REQUEST, UPSTREAM_ERROR, TIMEOUT. Apa pun yang dikembalikan upstream, lapisan terjemahan mencari di tabel dan mengubahnya menjadi kode terpadu, lapisan bisnis hanya mengenali 6 kode ini.
Agregasi penggunaan: setelah setiap panggilan, konversi standar token dari setiap vendor secara terpadu ke token standar internal, dan saat menyimpan ke database sertakan vendor, model, request_id, untuk rekonsiliasi dan analisis biaya selanjutnya. Di sini perlu diperhatikan perbedaan standar, output_tokens Claude dan completion_tokens OpenAI tidak dapat langsung dijumlahkan, harus dinormalisasi ke basis yang sama berdasarkan koefisien konversi.
Dalam arsitektur berlapis, saya biasanya membagi menjadi empat lapisan: lapisan akses (autentikasi + rate limiting), lapisan routing (pemilihan model), lapisan terjemahan (konversi protokol), lapisan adaptasi (pemanggilan SDK vendor). Lapisan terjemahan adalah fungsi murni, tidak menyentuh IO, sehingga mudah untuk unit test.
3. Kode Praktik: Ubah Satu Baris base_url untuk Terhubung ke Gateway Agregasi
Jika Anda tidak ingin menulis lapisan terjemahan dari nol, menggunakan platform agregasi AI API yang sudah ada adalah pilihan yang lebih pragmatis. Dalam proyek kami, kami pernah menggunakan token8341, yang kompatibel dengan OpenAI SDK, cukup ubah satu baris base_url untuk beralih, dan pekerjaan lapisan terjemahan sudah dilakukan olehnya.
from openai import OpenAI
client = OpenAI(
api_key="your-key",
base_url="https://api.token8341.com/v1" # hanya ubah baris ini
)
resp = client.chat.completions.create(
model="deepseek-v3", # juga bisa diganti gpt-4o / qwen-max / claude-4-sonnet
messages=[{"role": "user", "content": "jelaskan tentang SSE"}],
stream=True
)
for chunk in resp:
delta = chunk.choices[0].delta.content
if delta:
print(delta, end="")Dalam kode ini, normalisasi pemotongan SSE, pemetaan kode error, dan agregasi penggunaan semuanya telah diselesaikan di sisi gateway, dan lapisan bisnis menerima format OpenAI standar. Routing multi-model juga tidak perlu dipikirkan lagi, gateway dapat secara otomatis memilih model optimal berdasarkan tugas, misalnya teks panjang Mandarin menggunakan Qwen, tugas penalaran menggunakan DeepSeek, dan skenario sensitif biaya menggunakan Doubao.
Pengingat jebakan: setelah beralih base_url, jangan langsung meneruskan parameter khas vendor. Misalnya logit_bias dari OpenAI, top_k dari Claude, gateway belum tentu mendukung semuanya, jika diteruskan mungkin akan diabaikan secara diam-diam, sehingga Anda mengira sudah berlaku padahal tidak. Sebelum rilis, jalankan skrip stress test untuk menguji kompatibilitas parameter.
4. Perbandingan: Routing Multi-Model vs Pengikatan Model Tunggal
Berikut adalah sekumpulan angka dari pengukuran aktual kami. Pengikatan model tunggal (koneksi langsung ke OpenAI): waktu integrasi sekitar 2 hari-orang, failover memerlukan perubahan kode dan rilis ulang, waktu pemulihan rata-rata 15 menit, tidak ada ruang optimasi biaya. Routing multi-model (melalui gateway): waktu integrasi sekitar 0,5 hari-orang, failover selesai secara otomatis, waktu pemulihan kurang dari 3 detik, biaya dapat dikurangi sekitar 30% hingga 40% melalui pembagian tugas.
Dalam hal kompleksitas pemeliharaan, kode adaptasi untuk koneksi langsung ke 4 vendor sekitar 2000 baris, setelah melalui gateway, kode adaptasi lapisan bisnis turun menjadi kurang dari 200 baris, berkurang 90%. Dalam hal latensi, gateway menambah satu hop, P99 meningkat sekitar 20 hingga 40ms, dibandingkan dengan biaya pemeliharaan dan fleksibilitas peralihan yang dihemat, overhead ini dapat diterima.
Tentu saja, gateway bukanlah peluru perak. Jika bisnis Anda hanya menggunakan satu model dan tidak akan pernah berganti, koneksi langsung lebih sederhana. Tetapi selama melibatkan multi-model, multi-vendor, dan optimasi biaya, lapisan terjemahan adalah infrastruktur yang wajib. Gateway model, API model besar, agregasi AI API—ketiga hal ini pada dasarnya adalah tiga cara penyebutan untuk masalah lapisan yang sama.
Satu pengingat terakhir: cakupan unit test lapisan terjemahan harus maksimal, terutama untuk kasus batas pemotongan streaming, ini adalah area dengan frekuensi tinggi insiden produksi.
Penulis: Liu Zhiyuan
Tanggal Publikasi: 28 Oktober 2026