Baseten Grid mengajak kita menghitung biaya menyelesaikan tugas coding

Agen coding menghasilkan perubahan yang rapi untuk sebuah pengujian yang gagal. Perubahan itu gagal di CI, jadi pengembang meminta agen mencoba lagi. Percobaan kedua menyentuh bagian repositori yang lebih luas, dan peninjau menghabiskan setengah jam memeriksa patch yang seharusnya hanya butuh lima menit. Model mana yang lebih murah?

Baseten memperkenalkan Grid dalam pratinjau publik pada 4 November. Layanan ini menggabungkan gateway untuk model yang disetujui, router, serta kontrol terpusat atas penggunaan dan batas pengaman. Grid dapat berada di antara alat coding yang didukung dan modelnya agar tim bisa menerapkan kebijakan yang sama pada berbagai permintaan. Halaman akses awalnya mengarahkan tim ke daftar tunggu.

Gunakan penyebut yang tepat

Biaya per tugas yang diterima. Ilustrasi asli Telli.sh.

Harga token mengukur satu unit penggunaan model. Tim perlu merilis hasil yang memenuhi kriteria penerimaan. Sebuah permintaan dapat menghasilkan jawaban, satu eksekusi dapat menghasilkan diff, dan tugasnya masih bisa belum selesai. Dengan menghitung tiap peristiwa secara terpisah, eksperimen perutean menghasilkan informasi yang berguna.

Misalkan dua rute masing-masing menerima 100 tugas serupa. Rute murah menghabiskan $50 untuk seluruh percobaan dan menyelesaikan 50 tugas yang memenuhi syarat. Rute lain menghabiskan $90 dan menyelesaikan 90 tugas. Dalam ilustrasi ini, keduanya menghabiskan $1 dalam penggunaan model per hasil yang diterima. Setelah waktu peninjauan manusia, biaya alat, dan waktu tunggu percobaan ulang ditambahkan, hasilnya bisa berbeda. Selisihnya bisa menguntungkan salah satu rute.

Masukkan kegagalan ke pembilang. Rute yang menyerah pada permintaan sulit bisa terlihat efisien jika biaya percobaan yang ditinggalkan hilang dari perhitungan. Pertahankan pula definisi keberhasilan. Untuk perubahan dokumentasi, diff yang disetujui mungkin cukup. Migrasi memerlukan pengujian atas data yang sudah ada serta cara untuk mengembalikan perubahan.

Jenis pekerjaan berpengaruh. Migrasi API di seluruh repositori bisa sulit karena menuntut konteks, koordinasi, dan banyak perubahan kecil. Patch satu baris bisa lebih sulit jika menyangkut bug konkurensi yang samar. Jumlah berkas dan panjang prompt berguna hanya jika keduanya membantu memprediksi hasil di lingkungan Anda.

Baca eksperimen router sebagai pilihan biaya dan hasil

Eksperimen perutean. Ilustrasi asli Telli.sh.

Laporan teknis Baseten membandingkan penggunaan Opus 5.5 untuk semua tugas dengan perutean di antara model itu dan GLM 5.3 Flash. Untuk gabungan tugas DeepSWE, SWE Atlas QnA, dan Terminal-Bench, perusahaan melaporkan satu titik dengan biaya 72% lebih rendah dan selisih tingkat kelulusan dalam 0,8 poin persentase dari penggunaan Opus secara eksklusif. Laporan itu membandingkan router dengan pemilihan rute acak pada biaya yang sebanding. Perbandingan ini penting karena mengirim lebih banyak pekerjaan ke model murah akan menurunkan rata-rata biaya model bahkan jika rutenya dipilih dengan lempar koin.

Ambang perutean mencerminkan nilai yang bersedia dibayar untuk peluang keberhasilan. Memberi prioritas lebih besar pada biaya dapat mengalihkan lebih banyak tugas ke rute yang murah. Setelan lain dapat memilih model yang lebih mampu ketika hasilnya lebih penting. Hasil Baseten menggambarkan model, tugas, dan asumsi harga yang mereka pilih. Komposisi pekerjaan dan biaya kegagalan tim Anda akan berbeda.

Pengumuman produk menyebut klaim terpisah yang dibulatkan, yaitu biaya hingga 70% lebih rendah pada tolok ukur awal. Bedakan klaim itu dari hasil eksperimen sebesar 72% beserta perbandingan tingkat kelulusannya. Laporan teknis berguna untuk melihat bagaimana biaya dan hasil berubah bersama. Tim dapat memilih titik yang sesuai dengan prioritasnya, lalu memeriksa apakah pilihan tersebut bertahan dalam pekerjaan nyata.

Gateway dapat membuat kebijakan terlihat

Pengumuman Grid menjelaskan model yang disetujui, kontrol di tingkat tim, dan visibilitas penggunaan. Tim platform dapat memberi pengembang akses ke model yang telah dievaluasi organisasi, sembari melihat bagaimana penggunaannya tersebar. Tim bisa mulai memahami pengeluarannya sebelum mendelegasikan pemilihan rute.

Ada beberapa keputusan praktis. Penyedia mana yang boleh melihat kode milik perusahaan? Model mana yang disetujui untuk repositori tertentu? Tim mana yang menanggung biaya percobaan ulang? Siapa yang dapat mengganti rute setelah insiden? Gateway dapat menempatkan keputusan di titik kendali bersama, asalkan administrator memahami cakupan kontrolnya.

Gateway model dan lingkungan eksekusi agen merupakan dua titik kendali terpisah. Gateway bisa menentukan model mana yang menerima permintaan. Alat atau lingkungan eksekusi menentukan apakah agen boleh membaca kredensial, menulis berkas, atau membuat panggilan jaringan. Pembatasan rute berguna jika bekerja bersama izin lingkungan eksekusi. Rute yang murah tetap perlu menerapkan batasan yang sama pada alat dengan hak istimewa.

Bukti yang disimpan juga perlu dipertimbangkan. Log perutean membantu menjelaskan perubahan biaya, tetapi jejak eksekusi bisa berisi kode, jalur berkas, dan detail insiden pelanggan. Tentukan apa yang boleh dicatat platform, siapa yang boleh melihatnya, dan berapa lama catatan disimpan. Kebijakan yang tidak dapat diperiksa pengembang sulit ditelusuri ketika sebuah permintaan ditolak atau dialihkan secara tak terduga.

Uji perutean sebelum mengganti pilihan baku

1. Pilih dua atau tiga kelompok tugas umum. Sertakan satu kelompok sederhana, seperti pembaruan pengujian rutin, serta kelompok yang lebih sulit, seperti migrasi dengan persyaratan kompatibilitas ke belakang.
2. Tentukan bukti penerimaan sebelum mulai. Untuk tugas coding, ini dapat mencakup uji regresi yang lulus, diff yang bersih, persetujuan peninjau, dan pemeriksaan terhadap perubahan berkas yang tidak terduga.
3. Catat hasil acuan dengan model baku saat ini. Sertakan percobaan yang gagal, percobaan ulang, dan pekerjaan yang diselesaikan pengembang secara manual. Pertahankan batasan keamanan dan data yang berlaku di produksi.
4. Bandingkan perutean pada tugas yang setara. Jika akses tersedia, periksa alat dan izin yang didukung gateway dalam dokumentasi resmi sebelum menyambungkan akun.
5. Tentukan kapan beralih model. Kegagalan percobaan pertama bisa memicu model kedua, tetapi percobaan ulang tanpa batas bisa lebih mahal daripada langsung memakai model yang lebih mampu. Tetapkan batas dan catat alasan eskalasi.
6. Sediakan cara memilih rute secara manual untuk tugas yang menimbulkan konsekuensi besar jika hasilnya keliru. Setelah uji coba, tinjau pengecualian bersama angka biaya dan penerimaan keseluruhan.

Untuk uji coba internal, bandingkan periode ketika pengembang memilih model sendiri dengan periode yang memakai perutean, menggunakan pekerjaan sejenis. Kelompok pertama bisa mendapat manfaat dari pemahaman pengembang atas repositori. Kelompok kedua bisa mendapat manfaat dari kebijakan yang konsisten dan visibilitas yang lebih baik. Catat perbedaan tugas agar perbandingan menunjukkan kapan otomatisasi membantu dan kapan penilaian manusia tetap berguna.

Tinjau log tugas yang sebanding

Titik awal yang berguna adalah satu bulan pull request yang selesai. Beri label pekerjaan sesuai permintaan awalnya, misalnya pembaruan dependensi, bug dengan pengujian yang bisa direproduksi, perubahan lintas repositori, atau penyelidikan deployment yang gagal dengan cakupan terbuka. Simpan revisi repositori dan pemeriksaan penerimaan untuk tiap tugas. Jalankan kembali sampel terhadap model acuan yang stabil dan router. Pakai alat, batas waktu, dan lingkungan pengujian yang sama di kedua proses.

Pembaruan dependensi adalah contoh dengan sedikit ambiguitas. Pekerjaan berhasil jika dependensi yang disebutkan berubah, pemeriksaan kompatibilitas lulus, dan pull request tidak memuat suntingan yang tidak terkait. Tugas yang menyentuh kontrak penagihan perlu peninjauan lebih ketat. Manusia mungkin juga perlu menafsirkan persyaratan yang belum lengkap. Membedakan kelompok tugas ini dapat menunjukkan sumber penghematan rata-rata. Jika rute murah unggul pada pembaruan dependensi tetapi perlu percobaan berulang untuk perubahan penagihan, tim bisa membedakan rute keduanya.

Catat waktu yang dihabiskan manusia untuk memutuskan apakah suatu hasil bisa diterima. Misalkan metode acuan menghasilkan 19 hasil yang diterima dari 20 tugas dengan biaya $19, sementara router menghasilkan 18 hasil yang diterima dengan biaya $9. Dalam ilustrasi ini biaya model per hasil yang diterima adalah $1,00 dan $0,50. Jika peninjau menghabiskan tambahan 20 menit untuk memperbaiki satu hasil perutean yang gagal, perbandingan biaya berubah. Organisasi dapat menghitung pekerjaan ulang itu sambil tetap memperlakukan biaya dan waktu sebagai ukuran yang berbeda.

Ketahui data yang digunakan router

Tulisan teknis Baseten menyebut DeepSWE 1.1, SWE Atlas QnA, dan Terminal-Bench 2.1. Studi itu membandingkan Claude Opus 5.5 dan GLM 5.3 Flash pada berbagai tugas serta mengevaluasi router dengan data yang disisihkan. Rincian ini penting untuk menentukan sejauh mana temuan bisa diterapkan. Pertanyaan navigasi repositori memiliki pola biaya yang berbeda dari tugas yang menjalankan shell, memakai alat eksternal, atau mengubah beberapa berkas. Evaluasi pelanggan perlu mewakili tugas yang benar-benar akan dikirim.

Tulisan teknis menjelaskan bahwa pilihan Cost, Balanced, dan Intelligence mengubah ambang perutean ketika permintaan dibuat. Tim produk dapat memakai pilihan itu untuk menjalankan perbandingan di balik layar. Bandingkan setelan dengan kumpulan tugas ulangan berizin yang tetap, lalu catat model terpilih jika integrasi menampilkannya. Periksa perbedaan keputusan. Jika pilihan mahal terutama terjadi pada tugas yang dianggap sensitif atau sulit, kebijakan mungkin bekerja dengan baik. Jika perbedaan terpusat pada satu tugas sederhana yang umum, ada baiknya menyesuaikan klasifikasi tugas atau kebijakan.

Perhatikan pekerjaan paling lambat dan mahal

Latensi rata-rata bisa menyembunyikan waktu tunggu pengguna untuk patch sulit yang melewati beberapa model. Catat waktu nyata dari permintaan hingga hasil diterima, dan beri tanda pada percobaan ulang, eskalasi, batas waktu terlampaui, atau pengalihan pekerjaan. Dasbor yang hanya menunjukkan waktu respons model pertama bisa menyatakan berhasil untuk tugas yang sebenarnya harus dimulai ulang oleh operator. Sertakan pengeluaran dan waktu setelah pengalihan.

Batasi uji coba sebelum mengaktifkannya secara luas. Gunakan anggaran untuk seluruh tugas dan aturan kapan berhenti atau beralih ke model yang lebih mampu. Percobaan yang gagal perlu meninggalkan cukup bukti agar percobaan berikutnya bisa melanjutkan pekerjaan. Hindari mengulang pengujian atau membaca kembali berkas yang sama hanya karena router memilih model lain. Ukuran yang berguna adalah sejauh mana pekerjaan telah berjalan.

Untuk penerapan bertahap, mulailah dari kelompok tugas kecil dengan aturan penerimaan otomatis dan pengecualian yang bisa diperiksa manusia. Berikutnya, tambahkan kelompok yang penerimaannya membutuhkan penilaian. Bandingkan secara terpisah biaya per tugas yang diterima, persentase eskalasi, dan waktu peninjauan. Jika manfaatnya bertahan, organisasi memiliki bukti yang lebih baik untuk menentukan pilihan baku.

Pertahankan acuan setelah model berubah

Hasil yang dikumpulkan dalam satu minggu bisa kedaluwarsa ketika salah satu model, alat, atau repositori berubah. Simpan pengenal model, revisi pengujian, dan aturan penerimaan bersama keputusan perutean. Jalankan ulang sedikit tugas yang representatif saat mengubah kebijakan. Sertakan beberapa kegagalan mahal karena biayanya mudah hilang dalam rata-rata.

Minta peninjau menilai perbedaan hasil antar-rute tanpa melihat model mana yang dipilih. Jika peninjau belum bisa menentukan hasil yang dapat diterima, perjelas pemeriksaan penerimaan sebelum mengumpulkan lebih banyak eksekusi. Kebijakan perutean lebih mudah dibandingkan saat tim sepakat tentang cara mengenali keberhasilan.

Kebijakan perlu berkembang bersama pekerjaan

Perutean berguna jika membebaskan tim dari keputusan kecil yang terus berulang. Manfaatnya semakin terlihat ketika kinerja dan harga dapat diukur pada unit pekerjaan yang sama. Seiring waktu, model, harga, dan repositori akan berubah. Simpan tugas tolok ukur dan perbarui set pengujian agar kebijakan perutean dapat mengikuti perubahan tersebut.

Angka yang layak dibawa ke rapat perencanaan adalah biaya yang dibayar tim untuk menyelesaikan pekerjaan yang diterima, dengan penjelasan yang jelas tentang komprominya. Dengan angka itu, pimpinan teknis dan pemilik anggaran punya dasar untuk mengambil keputusan bersama.

Sumber

• Pengumuman pratinjau Baseten Grid pada 4 November
• Laporan teknis Baseten Router pada 4 November

---

Untuk menyimpan catatan percakapan dan keputusan di balik pekerjaan Anda yang dapat ditelusuri, Buat akun Telli.sh.