AI agentik akan terbentur kendala infrastruktur sebelum terbentur batas kecerdasan

Model berkembang lebih cepat daripada kemampuan kita untuk melayani apa yang diminta darinya.

Sebagian besar perdebatan tentang arah perkembangan agen AI berkisar pada kemampuannya. Bisakah model menyusun rencana dengan andal? Bisakah model memperbaiki kesalahannya sendiri? Bisakah model dipercaya untuk melakukan tindakan yang memiliki konsekuensi?

Itu semua pertanyaan yang penting. Namun, pertanyaan-pertanyaan itu bukanlah yang akan menentukan apakah agen diterapkan secara luas dalam beberapa tahun ke depan, karena ada kendala yang lebih dekat dan dampaknya akan terasa lebih cepat. Biaya penyediaan layanan untuk agen sulit dikelola, dan masalah ini kian besar seiring penambahan kemampuan yang justru diinginkan semua orang.

Chatbot dan agen adalah beban kerja yang berbeda

Permintaan percakapan hanya memerlukan satu kali bolak-balik: prompt masuk, token keluar, lalu koneksi ditutup. Anda bisa memprosesnya secara berkelompok, menyimpan awalan prompt dalam tembolok, dan memperkirakan throughput dengan satu angka.

Permintaan kepada agen berlangsung dalam bentuk sesi. Agen memanggil alat, menunggu, membaca hasilnya, memutuskan langkah berikutnya, memanggil alat lain, lalu akhirnya memberikan jawaban. Tugas sederhana pun mungkin memerlukan enam atau delapan kali pemanggilan model, dengan jeda menunggu di antaranya.

Perbedaan itu penting karena alasan yang tidak ada hubungannya dengan kecerdasan. Di antara langkah-langkahnya, agen menyimpan status—percakapan, keluaran alat, dan penalaran yang telah terkumpul. Di sisi penyediaan layanan, status tersebut berada di memori GPU sebagai tembolok KV, dan terus menggunakan memori sepanjang sesi, termasuk selama agen menunggu API eksternal.

Dengan demikian, kapasitas tidak lagi diukur dengan “permintaan per detik”, melainkan dengan “sesi serentak yang tersimpan di memori”. Sistem yang mampu menangani seribu permintaan percakapan per detik dengan mudah mungkin hanya sanggup melayani beberapa puluh sesi agen secara serentak pada perangkat keras yang sama.

Waktu tunggu adalah bagian yang mahal

Inilah hal yang tidak mengenakkan. Saat pemanggilan alat berlangsung, agen tidak melakukan apa-apa. Tidak ada token yang dihasilkan. Tidak ada komputasi yang digunakan. Namun, memori GPU tetap terpakai karena mengeluarkan konteks dari memori lalu menghitungnya kembali membutuhkan biaya lebih besar daripada membiarkannya tersimpan.

Perangkat keras Anda yang paling mahal dialokasikan untuk permintaan yang saat itu hanya menunggu hasil kueri basis data.

Dalam sistem terdistribusi konvensional, masalah ini sudah lama teratasi: sumber daya dilepas, lalu pekerjaan dilanjutkan saat respons tiba. Untuk melakukan hal yang sama pada penyediaan layanan model, tembolok KV harus dipindahkan ke memori host atau disk, lalu dipulihkan. Biaya pemindahannya cukup tinggi sehingga kebanyakan sistem tidak melakukannya. Penelitian tentang hal ini sedang berlangsung, dan alasannya adalah karena masalah ini mahal.

Eksekusi berurutan memperburuk keadaan

Hampir semua kerangka kerja agen menjalankan pemanggilan alat satu per satu. Model meminta pencarian cuaca, menerima hasilnya, meminta pemeriksaan kalender, menerima hasilnya, lalu meminta pencarian penerbangan dan menerima hasilnya.

Sering kali, ketiga pemanggilan itu tidak saling bergantung. Ketiganya bisa dijalankan secara bersamaan. Jika dijalankan berurutan, latensinya adalah jumlah waktu setiap pemanggilan. Jika dijalankan serentak, latensinya hanya selama pemanggilan yang paling lama.

Ini bukan pengamatan baru tentang agen—prinsip struktural yang sama berlaku pada sistem apa pun yang menjalankan beberapa model atau layanan dalam satu anggaran latensi. Latensi total seharusnya ditentukan oleh jalur terpanjang dalam grafik dependensi, bukan jumlah waktu setiap tahap. Hal ini lebih penting bagi agen karena sesinya menetap di memori GPU sepanjang waktu. Jadi, mempersingkat waktu keseluruhan bukan hanya meningkatkan pengalaman pengguna, tetapi juga secara langsung menambah jumlah sesi yang dapat ditangani perangkat keras.

Jika durasi sesi dipangkas setengahnya, kapasitas serentak kira-kira akan berlipat ganda pada GPU yang sama, tanpa mengubah model.

Percobaan ulang berlipat ganda dengan cara yang tak pernah dirancang siapa pun

Kerangka kerja agen mewarisi pengaturan bawaan untuk percobaan ulang dari pustaka HTTP yang mendasarinya. Biasanya, tiga kali percobaan.

Model juga mencoba lagi dengan caranya sendiri. Ketika alat mengembalikan hasil yang tidak membantu, model penalaran sering kali mencoba pendekatan lain—yang berarti percobaan ulang, hanya saja tidak ada yang mengonfigurasinya.

Jika keduanya digabungkan, kebijakan tiga kali percobaan yang membungkus model yang secara mandiri menalar hingga mencoba tiga pendekatan lagi akan menjadi kebijakan sembilan kali percobaan yang tidak pernah ditetapkan secara tertulis. Setiap percobaan tersebut merupakan pemanggilan model penuh, dengan token dan waktu penggunaan GPU masing-masing.

Saat sebuah dependensi melambat, amplifikasi ini mengubah penurunan kinerja menjadi gangguan layanan. Biaya setiap percobaannya pun beberapa orde magnitudo lebih tinggi daripada panggilan REST yang dicoba ulang.

Seperti apa kendalanya sebenarnya

Bukan batas kemampuan. Kendalanya lebih biasa: masalah keekonomian per unit yang menghentikan proyek saat beralih dari uji coba ke produksi.

Uji cobanya berhasil. Penggunanya sepuluh orang, latensinya dapat diterima, dan tagihannya nyaris tak berarti. Lalu, seseorang membuat proyeksi untuk sepuluh ribu pengguna dan kebutuhan GPU-nya menjadi tidak masuk akal—bukan karena modelnya lambat, melainkan karena setiap sesi serentak menggunakan memori sepanjang masa aktifnya, termasuk saat menunggu.

Inilah tahap ketika banyak demo internal yang menjanjikan diam-diam terhenti.

Apa yang Menggeser Tembok

Tidak ada yang aneh, dan semuanya merupakan urusan infrastruktur, bukan pemodelan:

Jalankan pemanggilan alat yang saling independen secara bersamaan. Peningkatan terbesar yang bisa diperoleh saat ini tanpa perangkat keras baru.

Gunakan durasi sesi sebagai ukuran kapasitas. Bukan jumlah token per detik. Bukan utilisasi GPU. Ukur berapa lama state tetap berada di memori dan berapa banyak sesi yang dapat ditampung.

Atur batas percobaan ulang di seluruh sistem, bukan untuk setiap pemanggilan. Batas global—dengan jumlah percobaan ulang dibatasi sebagai persentase kecil dari total lalu lintas—mencegah efek berantai yang dijelaskan di atas. Praktik SRE Google dalam menangani kelebihan beban dan anggaran percobaan ulang Envoy sama-sama menerapkan gagasan ini di luar tumpukan AI.

Pisahkan penalaran dari eksekusi. Gunakan model besar untuk menyusun rencana dan model yang jauh lebih kecil untuk langkah-langkah mekanis. Sebagian besar tugas agen tidak memerlukan model tercanggih.

Buat pengeluaran konteks dari memori menjadi murah. Cache KV terkuantisasi, mekanisme atensi berbasis halaman, dan jalur pemindahan beban untuk sesi yang tidak aktif. Inilah bidang yang saat ini mengalami perkembangan paling menarik dalam teknologi penyajian model.

Model-model akan terus membaik. Hal itu tampaknya sudah pasti. Apakah agen menjadi bagian dari infrastruktur atau tetap sekadar demo bergantung pada sesuatu yang tidak terlalu glamor—apakah kita mampu melayani beban kerja yang menahan memori mahal selama menunggu, dan apakah kita berhenti membayar total durasi seluruh rangkaian ketika yang seharusnya kita bayar hanyalah durasi jalur terpanjangnya.

Saya menerbitkan model eksekusi yang mendasari poin terakhir itu—eksekusi serentak atas pemanggilan model yang saling bergantung dalam satu batas latensi—dalam “Eksekusi Graf Inferensi Asinkron untuk Perutean Model dalam Sistem Pembelajaran Mesin”, International Journal of Computer Trends and Technology 72(10), Oktober 2024. Untuk pembahasan khusus tentang integrasi model generatif ke dalam sistem pengambilan keputusan yang dibatasi latensi, lihat “Platform Perdagangan dan Pengambilan Keputusan yang Ditingkatkan LLM: Menjembatani Kecerdasan Generatif dengan Sistem Pengambilan Keputusan Keuangan”, Journal of Information Systems Engineering and Management 11(1s), 2026.