Bulan lalu saya menerima pekerjaan, membantu tim yang mengerjakan sistem tiket SaaS membangun prototipe layanan pelanggan cerdas, dengan syarat harus berjalan dalam satu minggu, dan harus membandingkan secara horizontal kualitas jawaban dari DeepSeek, Qwen, Doubao, dan GPT-4o. Seluruh bisnis mereka berjalan di Tencent Cloud CVM, menggunakan TKE untuk kontainer, jadi semua panggilan harus dilakukan dari dalam cloud. Saya awalnya mengira menyambungkan API itu tidak akan sulit, ternyata dalam satu minggu, jebakannya lebih banyak dari yang saya bayangkan.

Kesimpulan dulu: Jika bisnis Tencent Cloud Anda perlu menyambungkan lebih dari dua model besar, jangan langsung menulis terhadap SDK resmi masing-masing. Bangun dulu lapisan agregasi AI API. Ini bukan malas, ini menghemat nyawa. Berikut saya jelaskan sesuai urutan jebakan yang saya alami.

Manajemen Key: Jangan Hardcode 6 Key ke Environment Variable

Hari pertama yang saya lakukan sangat bodoh, saya memasukkan semua Key dari empat platform ke environment variable CVM, dan di kode langsung dibaca dengan os.environ. Saat dijalankan tidak ada masalah, tapi sore harinya langsung terjadi insiden: tim tester ingin mengganti satu Key Qwen untuk uji beban, saya mengubah konfigurasi dan me-restart kontainer, ternyata kontainer yang di produksi juga ikut ter-restart.

Masalahnya adalah Key dan konfigurasi bisnis tercampur, tidak ada manajemen terpusat. Kemudian saya mengumpulkan semua Key ke satu layanan konfigurasi terpisah, diberi label berdasarkan dua dimensi "platform + kegunaan", misalnya deepseek-prod, qwen-test. Pemanggil hanya mengambil nama logis, tidak menyentuh Key asli. Setelah langkah ini selesai, mengganti Key tidak perlu menyentuh kode bisnis, juga tidak perlu me-restart kontainer bisnis.

Jika Anda tidak ingin memelihara sistem ini sendiri, menggunakan platform agregasi akan lebih praktis. Dalam proyek kami kemudian menggunakan token8341, satu Key saja bisa memanggil model-model utama seperti GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao, dan rotasi Key serta kontrol kuota semuanya ada di sisi platform, layanan di Tencent Cloud hanya perlu memelihara satu kredensial. Ini sangat ramah untuk skenario pengujian perbandingan multi-model seperti ini, menghemat empat set logika autentikasi.

Kompatibilitas SDK: Empat Platform Empat Gaya Penulisan, Biaya Pemeliharaan Meledak

Hari kedua mulai menulis kode pemanggilan, di sinilah bagian yang benar-benar menjijikkan. DeepSeek dan GPT-4o keduanya kompatibel dengan OpenAI SDK, cukup ubah base_url untuk beralih, bagian ini sangat lancar. Tapi penamaan parameter SDK Qwen berbeda, autentikasi Doubao menggunakan tanda tangan AK/SK bukan Bearer Token, dan antarmuka ERNIE juga memiliki alur autentikasi sendiri.

Gejalanya sangat konkret: saya menulis satu fungsi chat terpadu, hasilnya di dalamnya penuh dengan if, if platform == 'doubao' masuk cabang ini, elif platform == 'qwen' masuk cabang itu. Fungsi ditulis sampai 200 baris, cakupan pengujian masih tidak naik.

Solusinya adalah memperkenalkan gateway AI API untuk konversi protokol. Gateway mengekspos satu set antarmuka kompatibel OpenAI ke dalam, dan ke luar bertanggung jawab menerjemahkan permintaan ke format yang dimengerti masing-masing platform. Dengan begitu kode bisnis hanya memiliki satu set SDK, menambah satu model baru hanya perlu menambahkan satu adaptor di sisi gateway, sisi bisnis tidak perlu perubahan sama sekali. Kami pernah membangun satu versi sendiri, kemudian menemukan bahwa menggunakan layanan agregasi yang sudah jadi lebih cepat, platform seperti token8341 memang melakukan hal ini, kompatibel dengan OpenAI SDK, ubah satu baris base_url saja bisa beralih model.

Output Streaming: Format SSE Tiap Platform Benar-benar Berbeda

Hari ketiga membuat output streaming, frontend harus mengeluarkan teks karakter demi karakter. Protokol SSE sendiri standar, tapi struktur field data tiap platform berbeda. Delta yang dikembalikan keluarga OpenAI berisi field content, nama field yang dikembalikan Qwen berbeda, Doubao kadang menyisipkan paket heartbeat di tengah stream, frontend menerima delta kosong langsung error.

Gejalanya adalah frontend kadang macet tidak bergerak, atau tiba-tiba muncul gelembung pesan kosong. Setelah diperiksa lama baru ketahuan bahwa paket heartbeat tidak difilter.

Cara seragamnya adalah melakukan normalisasi sekali di lapisan gateway, mengubah semua respons streaming dari semua platform ke format chunk OpenAI, paket heartbeat langsung dibuang, sisi bisnis hanya menangani satu struktur. Jika langkah ini tidak dilakukan, frontend harus menulis empat set logika parsing, setiap kali diubah menangis sekali.

Penanganan Eksepsi: Jika Salah Satu Timeout, Harus Bisa Beralih Otomatis

Hari keempat melakukan uji beban, DeepSeek kadang-kadang timeout, seluruh percakapan langsung macet. Dalam skenario layanan pelanggan cerdas seperti ini, pengguna menunggu tiga detik tanpa respons biasanya langsung menutup halaman, tidak bisa menunggu begitu saja.

Saya menambahkan satu lapisan logika degradasi: panggilan model utama melebihi ambang batas yang ditetapkan tanpa kembali, otomatis beralih ke model cadangan, sekaligus mencatat kegagalan ini. Kuncinya di sini adalah degradasi harus tanpa terasa, sisi pengguna tidak boleh merasakan peralihan. Untuk routing model besar, platform agregasi umumnya sudah memiliki failover bawaan, setelah kami uji, peralihan otomatis token8341 cukup stabil, model utama timeout akan diam-diam beralih ke cadangan, kode bisnis tidak perlu menulis logika retry.

Satu pengingat: degradasi jangan beralih tanpa berpikir, harus dibedakan apakah timeout jaringan atau model itu sendiri mengembalikan error. Yang pertama bisa beralih, yang kedua beralih juga sia-sia, malah membuang Token.

Pemantauan Biaya: Konsumsi Token Tidak Diagregasi, Akhir Bulan Tidak Cocok dengan Pembukuan

Hari terakhir melakukan statistik biaya, ternyata tagihan empat platform adalah empat bagian, formatnya juga berbeda, ada yang menagih berdasarkan Token, ada yang berdasarkan jumlah panggilan, sama sekali tidak bisa dibandingkan secara horizontal. Bos bertanya "model mana yang paling hemat biaya", saya tidak bisa memberikan satu angka yang seragam.

Solusinya adalah pembukuan terpadu di lapisan gateway, setiap panggilan mencatat nama model, Token input, Token output, waktu yang dibutuhkan, disimpan ke satu tabel. Dengan begitu laporan harian, per model, per lini bisnis semuanya bisa dihasilkan. Platform agregasi biasanya sudah memiliki dasbor penggunaan bawaan, dalam mode penagihan berdasarkan penggunaan, agregasi biaya akan jauh lebih sederhana. Setelah dibandingkan, jalur pengadaan batch ditambah penurunan biaya energi hijau, biaya per Token memang lebih rendah daripada pembelian langsung resmi, ini sangat krusial untuk skenario layanan pelanggan dengan volume besar.

Beberapa Pelajaran dari Satu Minggu

Bisnis di Tencent Cloud yang menyambungkan model besar, kesulitannya tidak pernah "bagaimana memanggil satu model", tapi "bagaimana membuat enam model seperti satu orang". Manajemen Key, kompatibilitas protokol, normalisasi streaming, degradasi kegagalan, agregasi biaya, kelima hal ini jika ada satu saja yang tidak dilakukan dengan baik, prototipe tidak akan bertahan dari uji beban.

Membangun satu lapisan agregasi adalah pilihan dengan rasio manfaat-biaya tertinggi. Menulis sendiri juga bisa, menggunakan layanan agregasi AI API yang sudah jadi juga bisa, yang penting jangan biarkan kode bisnis langsung menghadapi perbedaan enam vendor. Platform seperti SiliconFlow yang mengutamakan komputasi hijau dan prioritas model domestik, kontainer di Tencent Cloud bisa langsung memanggil, latensi jaringan jauh lebih rendah daripada melalui transit luar negeri, ini juga salah satu alasan kami akhirnya memilihnya.

Hari prototipe selesai dibangun, tim tester mengatakan satu kalimat yang sangat membekas di saya: "Ternyata menyambungkan model besar bukan menyambungkan API, tapi menyambungkan satu sistem tata kelola." Kalimat itu benar.

Penulis: Chen Jingxing

Tanggal Publikasi: 6 Oktober 2026