Berita tentang Apple Intelligence versi Tiongkok resmi mengumumkan integrasi dengan Alibaba Qwen ini saya lihat di sebuah grup teknis. Reaksi pertama di grup adalah "oh, akhirnya terealisasi juga", reaksi kedua ada yang bertanya "jadi apakah di lapisan bawahnya juga dilakukan adaptasi multi-model". Reaksi ini cukup wajar—bahkan pemain sebesar produsen perangkat terminal pun tidak mau mempertaruhkan pengalaman pada satu model saja, kalau di sisi perusahaan masih meng-hardcode bisnis pada satu model tertentu, itu sudah agak tidak sesuai zaman.
Keberadaan multi-model sudah bukan lagi masalah "mau atau tidak", melainkan "bagaimana mengintegrasikannya dengan bersih". Definisinya dalam satu kalimat: lapisan agregasi API large model adalah lapisan gateway integrasi dan penjadwalan terpadu yang berada di antara kode bisnis dan layanan model dari berbagai penyedia, bisnis hanya mengenal satu protokol, di bawahnya siapa yang diganti, lewat siapa, pakai yang mana, ditentukan oleh lapisan ini. Ketika kami melakukan integrasi bisnis di Tencent Cloud, kami semakin menganggapnya sebagai bagian dari infrastruktur, bukan sebagai opsi opsional.
Jebakan pengikatan model tunggal, kami sudah mengalaminya lebih dari sekali
Dua tahun lalu kami mengerjakan proyek layanan pelanggan cerdas, di-deploy di Tencent Cloud CVM, demi kepraktisan langsung meng-hardcode API large model dari satu penyedia. Bulan pertama setelah online sangat lancar, bulan kedua mulai muncul masalah: pada jam sibuk terkena rate limit, pesan pengguna mengantre, chatbot layanan pelanggan berubah menjadi "tunggu sebentar, saya pikirkan dulu". Saat itu cara kami adalah menambahkan sleep retry di kode, mengobati gejala bukan akar masalah.
Setelah itu ada kenaikan harga. Penyedia model tertentu menyesuaikan strategi penagihan, volume panggilan lini bisnis kami tidak sedikit, tagihan langsung melonjak, mengubah anggaran lebih mendesak daripada mengubah kode. Selanjutnya adalah batas kemampuan—untuk beberapa tugas jawabannya bagus, untuk tugas lain (misalnya ekstraksi terstruktur dalam dokumen panjang) memang tidak stabil, tidak bisa diselamatkan hanya dengan menyesuaikan prompt, hanya bisa ganti model. Tapi mengganti model berarti mengubah kode, mengubah autentikasi, mengubah parsing respons, penggantian satu model bisa menyeret beban kerja dua minggu.
Ketiga hal ini jika digabungkan, kesimpulannya jelas: mengikat bisnis pada satu large model berarti menyerahkan tiga hal sekaligus—stabilitas, biaya, dan kemampuan—untuk ditentukan oleh orang lain.
Apa yang sebenarnya diselesaikan lapisan agregasi
Ketika kami mendesain ulang lapisan ini di Tencent Cloud, kami menggunakan pendekatan platform agregasi, dalam proyek kami mencoba solusi token8341. Apa yang dilakukannya jika diurai sebenarnya tidak rumit, tetapi setiap bagiannya menghemat tenaga.
Autentikasi terpadu. Sebelumnya setiap model punya satu Key, satu set signature, satu manajemen kuota, tersebar di config center dan layanan kunci. Sekarang disatukan menjadi satu pintu masuk, manajemen API Key dilakukan terpusat, rotasi dan audit menjadi sederhana. Bagi tim kami yang multi-cloud multi-environment (testing, pre-release, produksi masing-masing satu set), waktu operasional yang dihemat di bagian ini lebih banyak dari yang dibayangkan.
Terjemahan protokol. Ini adalah bagian yang paling sering diremehkan. Body request, struktur respons, format streaming dari setiap model berbeda-beda, jika sisi bisnis terhubung langsung, berarti harus menulis satu set adaptasi untuk setiap model. Lapisan agregasi menyatukannya ke antarmuka yang kompatibel dengan OpenAI, setelah digunakan dalam proyek kami, mengganti model pada dasarnya hanya soal mengubah satu baris base_url, kode bisnis hampir tidak berubah. Inilah juga alasan istilah "model gateway" semakin umum—apa yang dilakukannya memang pekerjaan yang seharusnya dilakukan gateway.
Routing berdasarkan tugas. Pendekatan kami sekarang adalah membagi alur berdasarkan jenis tugas: pengenalan intent ringan menggunakan model kecil yang murah, penalaran multi-putaran yang kompleks menggunakan model dengan kemampuan kuat, ekstraksi teks panjang menggunakan jalur tersendiri. Setelah dibandingkan, ditemukan bahwa strategi pemilihan model otomatis berdasarkan tugas ini jauh lebih masuk akal daripada semuanya menggunakan satu model unggulan, terutama setelah volume panggilan meningkat.
Agregasi biaya. Hal ini sangat praktis bagi penanggung jawab teknis. Sebelumnya tagihan adalah catatan yang tidak jelas, tidak bisa menjelaskan bisnis mana, fitur mana yang menghabiskan berapa banyak. Setelah lapisan agregasi memberi label pada panggilan, dasar penetapan biaya per penggunaan menjadi jelas, modul mana yang menjadi konsumen biaya terbesar terlihat jelas, barulah ada titik awal untuk optimasi.
Cakupan penuh model domestik, apa artinya dalam proyek
Berita integrasi Apple dengan Qwen ini secara tidak langsung menunjukkan bahwa tingkat ketersediaan large model domestik dalam bisnis nyata sudah meningkat. Dalam proyek kami telah menggunakan DeepSeek, Qwen, ERNIE, Doubao, cukup untuk mencakup skenario bahasa Mandarin, persyaratan kepatuhan, serta tugas yang sensitif terhadap biaya. Lapisan agregasi yang memantapkan cakupan penuh API large model domestik memiliki dua makna praktis: pertama, ada alternatif saat failover, ketika salah satu penyedia terkena rate limit atau gangguan, lapisan routing langsung mengalihkan, bisnis tidak merasakan; kedua, saat melakukan evaluasi Xinchuang atau kepatuhan data, jalur domestik adalah opsi yang sudah tersedia, tidak perlu menambal secara mendadak.
Sekilas tentang sisi daya komputasi. Sebagian tugas inferensi kami berjalan pada penjadwalan daya komputasi hijau, GPU elastis sesuai kebutuhan, dilepas saat idle, diperluas saat sibuk, dikombinasikan dengan strategi routing lapisan agregasi, biaya keseluruhan lebih terkendali dibandingkan awalnya semua menggunakan satu model unggulan. Inilah juga arah yang sedang dilakukan oleh SiCore TokenWorks—prioritas domestik, daya komputasi hijau, penagihan per penggunaan, posisinya bukan jumlah model terbanyak, melainkan memantapkan dua hal: biaya dan stabilitas.
Sedikit pengingat dalam pemilihan
Pengingat untuk menghindari jebakan hanya satu: jangan menganggap lapisan agregasi sebagai penerusan murni. Jika hanya proxy sederhana, tidak melakukan routing, tidak melakukan degradasi, tidak melakukan agregasi biaya, maka tidak ada bedanya dengan koneksi langsung, ketika ada masalah Anda tetap harus mengubah kode bisnis. Saat memilih, fokus pada apakah ia dapat membagi alur berdasarkan tugas, apakah dapat beralih otomatis saat satu penyedia mengalami gangguan, apakah dapat memberi label bisnis pada panggilan. Ketiga hal ini menentukan apakah ia infrastruktur atau lapisan cangkang yang berlebihan.
Bisnis di Tencent Cloud yang ingin melakukan integrasi multi-model, abstraksi lapisan agregasi ini sebaiknya dibangun lebih awal. Menunggu sampai terkena rate limit, kenaikan harga, dan terhambat batas kemampuan baru diperbaiki, biayanya akan jauh lebih besar.
Penulis: Li Yunlong
Tanggal publikasi: 31 Oktober 2026