Metrik yang Hilang Antara Token dan Pengeluaran Cloud

Masalahnya bukan bahwa tim AI kekurangan data biaya. Melainkan dasbor token dan tagihan cloud menggambarkan sistem yang berbeda, dimiliki oleh tim yang berbeda, tanpa cara yang dapat diandalkan untuk menghubungkannya.

Seorang agen dukungan dapat menyelesaikan satu tiket setelah lima panggilan model, satu langkah pengambilan, dua panggilan alat, dan satu percobaan ulang. Bisnis mencatat satu kasus yang selesai. Infrastruktur mencatat sekumpulan permintaan, pod, memori, waktu akselerator, dan layanan bersama. Sampai catatan‑catatan itu cocok, optimalisasi biaya masih sebagian tebak‑tebakan.

Mengapa Metrik Token dan Tagihan Cloud Menceritakan Kisah yang Berbeda?

Jumlah token berguna. Mereka menunjukkan berapa banyak teks yang diterima dan dikembalikan oleh model, serta membantu tim membandingkan prompt, model, atau pilihan routing. Namun, mereka tidak memberi tahu apa yang terjadi di sekitar panggilan model, berapa banyak komputasi yang mendukung pengambilan dan penggunaan alat, berapa banyak percobaan gagal yang terjadi terlebih dahulu, atau apakah hasil akhir memberikan manfaat.

The State of FinOps 2026 menunjukkan seberapa cepat AI masuk ke pekerjaan FinOps biasa: 98 % responden kini mengelola pengeluaran AI, dibandingkan 63 % pada 2025. Namun, baris anggaran yang lebih besar tetap tidak memberi tahu alur kerja mana yang menghabiskan uang atau mengapa. 

Dua pekerjaan pemrosesan dokumen dapat menggunakan jumlah token yang kira‑kira sama. Salah satunya mungkin selesai dengan satu permintaan model. Yang lain dapat mengambil konteks dari beberapa penyimpanan, memanggil layanan eksternal, beralih ke model lain, dan menjalankan dokumen kembali setelah pemeriksaan validasi yang gagal yang tidak pernah dilihat pengguna. Total token tampak serupa sementara jalur eksekusinya tidak.

Unite.ai telah meneliti mengapa token counts don’t automatically represent business value. Langkah selanjutnya adalah menghubungkan jumlah tersebut dengan beban kerja yang menghasilkan mereka. Jika tidak, tim dapat meningkatkan biaya per token sambil membuat biaya per tugas yang selesai menjadi lebih buruk.

Seperti Apa Rantai Biaya Lengkap?

Rantai biaya yang berguna dimulai dengan hasil yang penting bagi bisnis. Itu bisa berupa kasus dukungan yang terselesaikan, dokumen yang diproses, perubahan kode yang diterima, atau alur kerja agen yang selesai. Semua yang berada di bawahnya memerlukan identitas yang dapat diikuti melalui sistem.

Lapisan aplikasi menyediakan koneksi pertama. ID permintaan, ID jejak, nama alur kerja, atau ID percakapan dapat mengaitkan beberapa operasi model dan alat dengan satu pekerjaan. Tanpa benang itu, sepuluh peristiwa terkait tampak seperti sepuluh biaya yang tidak terkait.

The OpenTelemetry conventions for GenAI agents menawarkan kosakata yang sedang berkembang untuk lapisan ini. Mereka mencakup operasi, penyedia, model yang diminta, agen, percakapan, penggunaan token, eksekusi alat, kesalahan, dan alur kerja. Konvensi tersebut masih ditandai sebagai dalam pengembangan, sehingga tim tidak seharusnya menganggapnya sebagai standar universal yang selesai. Mereka berguna karena membuat masalah korelasi menjadi konkret.

Selanjutnya adalah infrastruktur. split cost allocation data for EKS dapat menugaskan biaya komputasi dan memori bersama ke pod Kubernetes serta menampilkan detail seperti klaster, namespace, penyebaran, node, nama beban kerja, dan tipe beban kerja. Untuk instance yang dipercepat yang didukung, data tersebut juga mencakup reservasi GPU, Trainium, dan Inferentia.

Itulah setengah lain dari rantai. Jejak dapat menjelaskan apa yang coba dilakukan aplikasi; alokasi Kubernetes dapat menunjukkan sumber daya mana yang membawa pekerjaan. deploying and monitoring LLMs on Kubernetes menyediakan konteks produksi yang lebih luas, termasuk alokasi sumber daya, penskalaan, dan observabilitas.

Penggabungan tidak akan terjadi secara kebetulan. Tim membutuhkan pengidentifikasi yang stabil yang bertahan cukup lama untuk menghubungkan telemetri aplikasi dengan label beban kerja, catatan alokasi, atau lapisan pemetaan lainnya. Data pelanggan tidak boleh berada dalam tag Kubernetes. Tim harus menentukan pengidentifikasi berkapasitas rendah mana yang dapat dengan aman menghubungkan kategori alur kerja, layanan, atau fitur dengan sumber daya yang dikonsumsinya.

Setelah konteks aplikasi tersebut ada, tim dapat mulai tracking Kubernetes costs by workload dan menghubungkan penggunaan namespace, CPU, memori, dan GPU kembali ke pekerjaan yang dilakukan. Itu masih tidak memberi tahu apakah alur kerja menciptakan nilai bisnis, tetapi memberikan sisi infrastruktur perhitungan sesuatu yang konkret untuk dihubungkan. 

Metrik Unit Mana yang Harus Dipercaya Bisnis?

Tidak ada satu metrik biaya AI tunggal yang harus digunakan semua tim. Biaya per token menjawab pertanyaan tentang konsumsi model. Biaya per pod menjawab pertanyaan tentang alokasi infrastruktur. Kedua‑nya tidak memberi tahu pemilik produk apakah fitur tersebut menghasilkan nilai.

Penyebut terbaik biasanya adalah hasil terkecil yang dapat didefinisikan bisnis dengan jelas, dan dapat dipengaruhi tim produk. Operasi dukungan mungkin melacak biaya per kasus yang terselesaikan. Sistem dokumen mungkin menggunakan biaya per berkas yang berhasil diproses, sementara asisten pemrograman dapat memeriksa biaya per perubahan yang diterima daripada biaya per saran.

Keberhasilan mengubah perhitungannya.

Alur kerja dengan biaya per percobaan yang rendah dapat menjadi mahal jika sering gagal, memicu validasi berulang, atau mengirim terlalu banyak kasus ke tinjauan manusia. Itulah mengapa tim harus memisahkan biaya per percobaan dari biaya per penyelesaian dan, bila memungkinkan, biaya per hasil yang diterima. Angka terakhir seringkali paling berguna karena mencakup pekerjaan yang dihasilkan sistem tetapi bisnis tidak dapat menggunakannya.

Sistem agen membuat hal ini lebih sulit karena jalurnya dapat berubah dari satu eksekusi ke eksekusi berikutnya. the economics of scaling agentic AI workloads mencakup routing, panggilan alat, percobaan ulang, dan atribusi tingkat alur kerja. Perilaku tersebut masuk dalam metrik unit ketika mereka mengonsumsi sumber daya, bahkan ketika pengguna akhir hanya melihat satu jawaban.

Metrik tersebut masih tidak akan sempurna. Layanan bersama, hasil yang di‑cache, pekerjaan batch, dan pemrosesan yang tertunda dapat mengaburkan atribusi. Perkiraan yang berguna untuk keputusan lebih baik daripada presisi palsu, terutama ketika hal itu memberi tahu insinyur lapisan mana yang layak diselidiki.

Siapa yang Memiliki Angka Itu?

Bagian tersulit mungkin bersifat organisasi. Tim ML memahami panggilan model dan evaluasinya. Tim platform memahami beban kerja dan perilaku klaster. FinOps memahami data penagihan dan aturan alokasi. Tim produk tahu hasil mana yang penting.

Tidak ada satu tim pun yang memiliki seluruh rantai.

Hal itu menimbulkan argumen yang dapat diprediksi tentang dashboard siapa yang benar. Tim ML mungkin menunjukkan penggunaan token yang lebih rendah, sementara tim platform melihat jam GPU meningkat dan tim produk melihat lebih sedikit tugas yang selesai dibandingkan sebelumnya. Ketiga pengamatan tersebut dapat benar secara bersamaan. Metrik bersama harus menjelaskan hubungan di antara mereka.

Titk awal yang dapat bekerja adalah satu alur kerja produksi dengan peristiwa penyelesaian yang jelas. Beri ia pengidentifikasi yang stabil. Bawa konteks itu melalui jejak model dan alat, petakan ke layanan atau beban kerja yang berjalan di Kubernetes, dan pilih satu penyebut bisnis. Kemudian satukan tim ketika angka tersebut berubah secara tak terduga.

Tinjauan itu lebih penting daripada dashboard yang dipoles. Peningkatan tiba‑tiba dapat berasal dari prompt yang lebih panjang, jalur fallback baru, kapasitas GPU yang kurang dimanfaatkan, kebijakan autoscaling yang berubah, atau keputusan produk yang mengirim lebih banyak pekerjaan melalui fitur AI. Setiap penyebabnya dimiliki oleh pemilik yang berbeda.

Otomatisasi sebaiknya datang kemudian. Mesin rekomendasi hanya dapat bertindak atas label dan ambang yang diterimanya, dan penyebut yang buruk dapat membuat sistem yang efisien tampak boros atau memberi penghargaan pada alur kerja murah yang ditolak pengguna. Tim membutuhkan visibilitas bersama yang cukup untuk membedakan perilaku model dari desain aplikasi dan alokasi infrastruktur sebelum membiarkan sistem bertindak atas hasilnya. Jika tidak, perbaikan biaya otomatis dapat mengurangi kapasitas, meningkatkan latensi, dan memindahkan beban ke tempat yang kurang terlihat.

Rantai Biaya Harus Dibagi

Kontrol biaya AI akan tetap terfragmentasi selama setiap tim mengoptimalkan hanya lapisan yang mereka lihat. Token, jejak, pod, akselerator, dan faktur bukanlah ukuran yang bersaing. Mereka adalah bagian dari rantai biaya yang sama.

Perusahaan yang menghubungkannya tidak akan mendapatkan angka yang sempurna pada hari pertama. Yang penting adalah apakah tim dapat melacak tagihan tinggi kembali ke alur kerja yang menyebabkannya, menentukan apa yang berubah, dan memutuskan apakah hasilnya membenarkan biaya tersebut.