Rekan-rekan yang mengerjakan backend dan pengembangan aplikasi AI, mungkin pernah mengalami momen seperti ini: membuka tagihan cloud di akhir bulan, dan menemukan pengeluaran API model besar mencapai 3 kali lipat dari anggaran. Bukan karena serangan, bukan karena lonjakan bisnis, hanya saja layanan percakapan online diam-diam menghabiskan uang. Artikel ini akan membedah dari perspektif engineering di mana sebenarnya uang bocor, dan bagaimana menutupnya dengan cara teknis.
Jebakan Pertama: Pembengkakan Jendela Konteks Tanpa Kendali
Sumber biaya yang paling mudah diabaikan dalam percakapan multi-putaran adalah pengiriman ulang seluruh riwayat pesan. Misalkan dalam skenario layanan pelanggan, rata-rata setiap putaran memiliki konteks 800 token, ketika pengguna mencapai putaran ke-20, input satu kali permintaan mendekati 16000 token. Dengan tarif input GPT-4o $2.5/1M token, biaya input satu kali permintaan sekitar $0.04, dengan 50.000 panggilan sehari berarti $2000. Yang benar-benar fatal adalah, dari 16000 token ini mungkin 70% adalah obrolan ringan yang sudah tidak relevan sejak tiga putaran lalu.
Ide optimasinya adalah sliding window + kompresi ringkasan. Pertahankan N putaran terakhir dalam bentuk asli, percakapan yang lebih lama dikompresi dengan model ringan menjadi ringkasan di bawah 200 token. Di proyek kami, setelah mengubah jendela dari "seluruhnya" menjadi "6 putaran terakhir + ringkasan", token input satu kali turun dari 12000 menjadi sekitar 3500, biaya input langsung terpotong tujuh puluh persen. Perhatikan bahwa ringkasan itu sendiri juga harus menggunakan model murah, menggunakan model flagship untuk membuat ringkasan sama saja tidak menghemat.
Jebakan Kedua: Model Flagship Mengerjakan Pekerjaan Kasar
Ini adalah pemborosan yang paling umum dan paling disayangkan. Klasifikasi intent, penilaian sentimen, ringkasan konten, konversi format, tugas-tugas ini bisa mencapai akurasi di atas 95% dengan DeepSeek-V3 atau Qwen-Max, tetapi banyak tim demi kepraktisan, semuanya menggunakan Claude 4 Sonnet atau GPT-4o. Berapa selisih harganya? Harga satuan input model flagship seringkali 10 hingga 20 kali lipat model ringan.
Inti dari pemanggilan model berlapis adalah routing. Tugas yang masuk secara otomatis dinilai kompleksitasnya, klasifikasi menggunakan model ringan, penalaran kompleks baru menggunakan flagship. SiCore TokenWorks mendukung pemilihan model optimal secara otomatis berdasarkan tugas, setelah digunakan di proyek kami, biaya menurun signifikan setelah tugas klasifikasi dialihkan ke model ringan. Nilai dari platform agregasi API AI semacam ini adalah, Anda tidak perlu memelihara satu set SDK dan Key secara terpisah untuk setiap model, satu antarmuka yang kompatibel dengan OpenAI sudah bisa beralih. Berikut adalah contoh perubahan minimal:
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # ubah satu baris, kompatibel dengan OpenAI SDK
)
# tugas ringan menggunakan model murah
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "Menilai sentimen komentar ini: pengiriman cepat tetapi kemasan rusak"}],
max_tokens=16
)
print(resp.choices[0].message.content)Strategi routing bisa dimulai dengan aturan: beri label pada jenis tugas, klasifikasi/ringkasan/ekstraksi menggunakan model ringan, pembuatan kode/penalaran kompleks menggunakan flagship. Setelah berjalan beberapa waktu, statistik tingkat hit aktual setiap model baru disesuaikan, jangan langsung menerapkan routing semantik yang kompleks, biaya pemeliharaannya lebih tinggi daripada uang yang dihemat.
Jebakan Ketiga: Mekanisme Retry yang Tidak Terkendali
Retry timeout adalah pengganda tersembunyi. Banyak SDK secara default melakukan retry 2 hingga 3 kali, jika ambang timeout diatur terlalu pendek (misalnya 10 detik), sedangkan latensi P99 aktual adalah 25 detik, maka banyak permintaan akan di-retry setelah timeout, satu panggilan menjadi tiga kali. Lebih buruk lagi, permintaan retry itu sendiri juga memakan konkurensi, mungkin memicu rate limiting, rate limiting memicu retry lagi, membentuk avalanche.
Kami pernah mengalaminya: latensi P99 suatu antarmuka 28 detik, timeout diatur 15 detik, retry 3 kali, volume panggilan aktual adalah 2,4 kali volume bisnis. Kemudian ambang timeout diatur naik 30% dari P99, retry diubah menjadi exponential backoff dan maksimal 1 kali, volume panggilan turun kembali ke 1,1 kali. Selain itu retry harus membedakan jenis error, hanya 429 dan 5xx yang di-retry, error parameter 400 di-retry sepuluh ribu kali juga tidak ada gunanya.
Jebakan Keempat: Kurangnya Agregasi Penggunaan dan Peringatan
Ini adalah masalah paling mendasar. Banyak tim melakukan statistik kasar berdasarkan proyek atau berdasarkan Key, tetapi tidak tahu secara spesifik fitur mana, pengguna mana, Prompt mana yang membakar uang. Baru setelah tagihan keluar baru menyadari Key lingkungan pengujian tertentu belum dimatikan, atau sesi super panjang seorang pengguna menghabiskan anggaran.
Caranya adalah memberi label berdasarkan dimensi: setiap panggilan membawa tiga label team, feature, user_id, disimpan ke log atau time-series database. Keuntungan menggunakan gateway API AI sebagai pintu masuk terpadu ada di sini, semua panggilan melewati satu lapisan proxy, pelabelan dan agregasi penggunaan diselesaikan di sisi gateway, tidak perlu mengubah kode setiap pihak bisnis. Ambang peringatan disarankan diatur dua tingkat, penggunaan harian mencapai 60% anggaran memberi peringatan, mencapai 85% memicu degradasi (misalnya secara otomatis mengalihkan fitur non-inti ke model ringan).
Perbandingan Biaya dan Referensi Pemilihan
Setelah menerapkan empat poin di atas, kami membandingkan tiga cara akses: koneksi langsung resmi model tunggal, routing mandiri, platform agregasi. Koneksi langsung resmi paling praktis tetapi tidak bisa melakukan pelapisan model, biaya bersifat kaku; routing mandiri fleksibel tetapi harus memelihara banyak set Key, banyak set SDK, banyak set logika penagihan, minimal dua orang-bulan; platform agregasi memiliki kemampuan siap pakai dalam pergantian model dan agregasi penggunaan, penagihan berdasarkan penggunaan, biaya lebih optimal. Dalam pemilihan, fokus pada tiga hal: apakah kompatibel dengan OpenAI SDK (biaya migrasi), apakah mendukung cakupan penuh model domestik (kepatuhan dan biaya), apakah memiliki antarmuka agregasi penggunaan (observabilitas).
Optimasi biaya bukanlah proses sekali jadi, tetapi proses observasi dan penyesuaian berkelanjutan. Mulailah dengan agregasi penggunaan, lihat dengan jelas ke mana uang pergi, baru optimalkan satu per satu konteks, pelapisan model, strategi retry. Jangan membalik urutannya, jika tidak Anda mengoptimalkan setengah hari, mungkin yang dioptimalkan bukanlah yang terbesar.
Penulis: Chen Jingxing
Tanggal Publikasi: 3 Oktober 2026