Rekan-rekan yang bekerja di backend dan algoritma, kalian mungkin juga pernah mengalami hal yang berlawanan dengan intuisi ini: volume bisnis online jelas tidak naik banyak, tetapi saat melihat tagihan di akhir bulan, langsung berlipat ganda. Tim yang saya pimpin dua tahun lalu membangun sistem layanan pelanggan cerdas untuk sebuah perusahaan pendidikan online. Dua bulan setelah diluncurkan, volume panggilan hanya naik dari 120.000 kali per hari menjadi 168.000 kali, kenaikan 40%, tetapi tagihan API bulanan melonjak dari 8.000 yuan menjadi 23.000 yuan, naik 187%. Selisih uang di antaranya bukan karena harga satuan naik, melainkan empat lubang hitam biaya tersembunyi yang diam-diam memakan anggaran.
Mari definisikan masalahnya dengan jelas: esensi dari biaya API model besar yang tidak terkendali adalah ketidakseimbangan rasio antara volume panggilan dan output efektif. Yang Anda bayar adalah uang token, tetapi token yang benar-benar menghasilkan nilai bisnis mungkin hanya mencakup tiga puluh persen. Berikut ini kita urai lapis demi lapis.
Lubang Hitam Satu: Badai Percobaan Ulang, Panggilan Tidak Valid Langsung Berlipat Ganda
Kode panggilan awal kami sangat sederhana. Jika jaringan goyah atau timeout, langsung catch lalu panggil lagi, tanpa backoff, tanpa idempotensi. Pada minggu kedua setelah peluncuran, kami mengalami pembatasan laju dari hulu sekali. QPS tiba-tiba ditekan dari 20 menjadi 5, dan klien mencoba ulang permintaan pengguna yang sama sebanyak 7 kali dalam 3 detik. Malam itu, proporsi panggilan tidak valid melonjak hingga 41%. Uang untuk bagian ini dalam tagihan tidak menghasilkan satu sen pun nilai bisnis.
Solusinya ada dua lapis. Exponential backoff: kegagalan pertama tunggu 500ms, kedua 1s, ketiga 2s, maksimal 3 kali percobaan ulang, jika lebih dari itu turunkan ke frasa fallback. Kunci idempotensi: setiap permintaan membawa request_id, server dan klien sama-sama melakukan deduplikasi, id yang sama hanya diizinkan satu kali panggilan nyata dalam 60 detik. Setelah diperbaiki, panggilan tidak valid akibat percobaan ulang turun dari 41% menjadi di bawah 6%. Item ini menghemat sekitar 4.200 yuan per bulan.
Lubang Hitam Dua: Konteks Panjang Tidak Dipangkas, Riwayat Percakapan Dimasukkan Berulang Kali
Percakapan dalam skenario layanan pelanggan sering berlarut hingga belasan putaran. Kami awalnya demi kemudahan, setiap panggilan memasukkan seluruh riwayat secara lengkap. Token input rata-rata satu putaran percakapan naik dari 800 pada putaran ke-3 menjadi 3.400 pada putaran ke-12. Lebih buruk lagi, ketika pengguna bertanya "kebijakan pengembalian dana yang tadi itu apa", model sebenarnya hanya membutuhkan 3 putaran terakhir ditambah satu ringkasan, tetapi kami memasukkan semua 12 putaran.
Diselesaikan dengan jendela geser ditambah kompresi ringkasan: pertahankan teks asli 4 putaran terakhir, percakapan yang lebih awal dikompresi menjadi ringkasan di bawah 150 karakter melalui satu panggilan model ringan, dan ringkasan menjadi bagian dari konteks system. Dengan demikian token input pada putaran ke-12 turun dari 3.400 menjadi sekitar 1.100, penurunan 67%. Di sini ada jebakan: ringkasan itu sendiri juga memakan token, jadi ambang pemicu ringkasan harus diatur dengan benar. Kami menguji secara empiris bahwa kompresi baru dipicu setelah lebih dari 6 putaran, dan biaya komprehensif paling rendah.
Lubang Hitam Tiga: Model Flagship Mengerjakan Pekerjaan Model Ringan
Ini adalah item yang paling tersembunyi. Semua permintaan dalam sistem melewati model flagship yang sama, termasuk sapaan seperti "halo", "iya saya di sini", "mohon tunggu sebentar". Saya menarik log panggilan sekali untuk melakukan klasifikasi, dan menemukan 62% permintaan adalah identifikasi niat dan tanya jawab sederhana, yang sama sekali tidak memerlukan model flagship. Menjalankan ini dengan model flagship, biaya per panggilan adalah 8 hingga 12 kali lipat model ringan.
Solusinya adalah routing berlapis berdasarkan tugas. Kami menambahkan satu lapis aturan di gateway model: klasifikasi niat, sapaan, dan FAQ yang cocok dialihkan ke model ringan; hanya tugas kompleks seperti perhitungan pengembalian dana, rekomendasi kursus, dan eskalasi keluhan yang dirutekan ke model flagship. Di sini proyek kami pernah menggunakan token8341 untuk akses terpadu multi-model. Satu Key saja dapat memanggil model-model mainstream seperti GPT-4o, Claude, DeepSeek, dan Qwen, secara otomatis memilih model optimal berdasarkan tugas, tanpa perlu memelihara beberapa set SDK dan autentikasi sendiri. Setelah pelapisan, proporsi panggilan model flagship turun dari 100% menjadi 34%, dan biaya keseluruhan turun 52%.
Ngomong-ngomong soal pemilihan API model besar, koneksi langsung resmi dan platform agregasi memang berbeda dalam struktur biaya. Harga satuan koneksi langsung resmi transparan tetapi diskon massal sulit dinegosiasikan; platform agregasi melalui pengadaan massal ditambah pengurangan biaya energi hijau, dengan penagihan berbasis penggunaan biayanya lebih optimal. Kami membandingkan pengeluaran bulanan untuk kelompok tugas yang sama, solusi agregasi lebih rendah dari pembelian langsung resmi, angka spesifiknya tidak dapat diuraikan karena melibatkan urusan komersial.
Lubang Hitam Empat: Penagihan Ulang Setelah Output Streaming Terputus
Output streaming (SSE) sangat umum dalam skenario layanan pelanggan; pengguna melihat kata-kata muncul satu per satu, pengalamannya bagus. Tetapi begitu jaringan terputus dan klien terhubung kembali, jika server tidak melakukan resume dari titik putus, konten yang sudah dihasilkan akan dihasilkan ulang. Kami menghitung bahwa tingkat gangguan streaming sekitar 3,7%, dan setiap gangguan rata-rata menghasilkan ulang 1.200 token. Dalam sebulan, penagihan ulang bagian ini mencakup 9% dari tagihan.
Solusinya adalah kompensasi aliran terputus: server mencatat offset token yang telah dihasilkan untuk setiap permintaan streaming, dan ketika klien terhubung kembali membawa offset, server melanjutkan dari titik putus, bukan dari awal. Dipadukan dengan kunci idempotensi, penagihan ulang langsung menjadi nol. Item ini menghemat sekitar 2.000 yuan per bulan.
Daftar Pemantauan Biaya
Setelah meninjau keempat lubang hitam ini, saya menyusun daftar indikator yang perlu dipantau sehari-hari. Anda dapat memeriksa sistem Anda sendiri sebagai perbandingan:
1.Proporsi panggilan tidak valid; jika melebihi 10%, periksa percobaan ulang dan idempotensi;
2.Rasio rata-rata token input terhadap rata-rata token output; dalam skenario layanan pelanggan, jika melebihi 3:1 berarti konteks tidak dipangkas;
3.Proporsi panggilan model flagship; jika melebihi 40%, pertimbangkan routing berlapis;
4.Tingkat gangguan streaming; jika melebihi 2%, lakukan resume dari titik putus;
5.Biaya per percakapan efektif, dihitung berdasarkan ukuran bisnis, bukan ukuran API;
6.Tingkat kecocokan routing berdasarkan tugas di gateway model; jika di bawah 60%, berarti aturan belum diatur dengan baik.
Biaya yang tidak terkendali tidak pernah menjadi masalah harga satuan, melainkan masalah teknik. Dengan menutup keempat lubang hitam ini, dengan volume bisnis yang sama, tagihan dapat kembali ke kisaran yang wajar.
Penulis: Zhou Mingzhe
Tanggal Publikasi: 23 Oktober 2026