Tokenlar ve Bulut Harcamaları Arasındaki Kaçırılan Ölçüt

Sorun, AI ekiplerinin maliyet verilerinden yoksun olması değil. Sorun, token panosu ve bulut faturasının farklı sistemleri, farklı ekiplerin sahip olduğu ve bunları bağlamak için güvenilir bir yolun olmamasıdır.

Bir destek ajanı, beş model çağrısı, bir getirme adımı, iki araç çağrısı ve bir yeniden deneme sonrasında bir bileti çözebilir. İş birimi bir tamamlanmış vakayı kaydeder. Altyapı ise bir dizi istek, pod, bellek, hızlandırıcı süresi ve ortak hizmeti kaydeder. Bu kayıtlar bir araya gelene kadar maliyet optimizasyonu kısmen tahmin yürütmek olur.

Token Metriği ile Bulut Faturaları Neden Farklı Hikayeler Anlatıyor?

Token sayıları faydalıdır. Bir modelin aldığı ve döndürdüğü metin miktarını gösterir ve ekiplerin istemleri, modelleri veya yönlendirme seçimlerini karşılaştırmasına yardımcı olur. Ancak model çağrısı etrafında ne olduğunu, getirme ve araç kullanımını destekleyen ne kadar işlem gücü harcandığını, kaç başarısız denemenin önce gerçekleştiğini veya sonucun gerçekten işe yarayıp yaramadığını söylemez.

State of FinOps 2026, AI’nın sıradan FinOps çalışmalarına ne kadar hızlı girdiğini gösteriyor: Katılımcıların %98’i artık AI harcamalarını yönetiyor, 2025’te %63 iken. Ancak daha büyük bir bütçe satırı hâlâ hangi iş akışının parayı harcadığını ya da nedenini söylemiyor.

İki belge işleme işi, yaklaşık aynı sayıda token kullanabilir. Biri tek bir model isteğiyle sona erebilir. Diğeri ise birkaç depodan bağlam getirir, harici bir hizmeti çağırır, başka bir modele geçer ve kullanıcının hiç görmediği bir doğrulama hatasından sonra belgeyi tekrar çalıştırır. Token toplamları benzer görünürken yürütme yolları farklıdır.

Unite.ai, token sayılarının otomatik olarak iş değerini temsil etmediğini zaten inceledi. token counts don’t automatically represent business value. Bir sonraki adım, bu sayıları onları üreten iş yüklerine bağlamaktır. Aksi takdirde, bir ekip token başına maliyeti iyileştirirken tamamlanmış görev başına maliyeti kötüleştirebilir.

Tam Bir Maliyet Zinciri Nasıl Görünür?

Faydalı bir maliyet zinciri, işletmenin önemsediği sonuçla başlar. Bu, çözülen bir destek vakası, işlenen bir belge, kabul edilen bir kod değişikliği veya tamamlanmış bir ajan iş akışı olabilir. Altındaki her şey, sistem içinde izlenebilen bir kimliğe sahip olmalıdır.

Uygulama katmanı ilk bağlantıyı sağlar. Bir istek kimliği, izleme kimliği, iş akışı adı veya konuşma kimliği, birkaç model ve araç işlemini tek bir iş parçasına bağlayabilir. Bu dizi olmadan, on ilişkili olay on ilişkili olmayan ücret gibi görünür.

The OpenTelemetry conventions for GenAI agents, bu katman için ortaya çıkan bir söz varlığı sunar. İşlemler, sağlayıcılar, istenen modeller, ajanlar, konuşmalar, token kullanımı, araç yürütme, hatalar ve iş akışları kapsanır. Bu kurallar hâlâ geliştirme aşamasında işaretlenmiştir, bu yüzden ekipler bunları tamamlanmış evrensel bir standart olarak görmemelidir. Korelasyon sorununu somutlaştırdıkları için faydalıdırlar.

Ardından altyapı gelir. AWS’nin split cost allocation data for EKS, paylaşılan işlem ve bellek maliyetlerini Kubernetes pod’larına atayabilir ve küme, ad alanı, dağıtım, düğüm, iş yükü adı ve iş yükü tipi gibi ayrıntıları ortaya çıkarır. Desteklenen hızlandırılmış örnekler için veri ayrıca GPU, Trainium ve Inferentia rezervasyonlarını da kapsar.

Bu, zincirin diğer yarısıdır. Bir iz, uygulamanın ne yapmaya çalıştığını açıklayabilir; Kubernetes tahsisi ise hangi kaynakların işi taşıdığını gösterebilir. Unite.ai’nin deploying and monitoring LLMs on Kubernetes rehberi, kaynak tahsisi, ölçekleme ve gözlemlenebilirlik dahil daha geniş üretim bağlamını sağlar.

Bağlantı tesadüfen gerçekleşmez. Ekipler, uygulama telemetrisi ile iş yükü etiketlerini, tahsis kayıtlarını veya başka bir eşleme katmanını bağlayacak kadar uzun ömürlü, sabit bir tanımlayıcıya ihtiyaç duyar. Müşteri verileri Kubernetes etiketlerinde bulunmamalıdır. Ekipler, bir iş akışı kategorisini, hizmeti veya özelliği tükettiği kaynaklarla güvenli bir şekilde bağlayabilecek düşük kardinaliteli tanımlayıcıları belirlemelidir.

Bu uygulama bağlamı kurulduğunda, ekipler tracking Kubernetes costs by workload‘a başlayabilir ve ad alanı, CPU, bellek ve GPU kullanımını yapılan işe geri bağlayabilir. Bu hâlâ iş akışının iş değeri yaratıp yaratmadığını söylemez, ancak altyapı tarafına somut bir bağlama verir.

İşletme Hangi Birim Ölçütüne Güvenmeli?

Her ekip için tek bir AI maliyet ölçütü yoktur. Token başına maliyet, model tüketim sorusuna yanıt verir. Pod başına maliyet, altyapı tahsis sorusuna yanıt verir. Hiçbiri ürün sahibine özelliğin değerini getirip getirmediğini söylemez.

En iyi payda genellikle işletmenin net bir şekilde tanımlayabildiği ve ürün ekibinin etkileyebildiği en küçük sonuçtur. Bir destek operasyonu, çözülmüş vaka başına maliyeti izleyebilir. Bir belge sistemi, başarıyla işlenen dosya başına maliyeti kullanabilir, bir kod asistanı ise öneri başına maliyet yerine kabul edilen değişiklik başına maliyeti inceleyebilir.

Başarı matematiği değiştirir.

Düşük deneme başına maliyeti olan bir iş akışı, sık başarısız olursa, tekrar doğrulama tetiklerse veya çok fazla vakayı insan incelemesine gönderirse pahalı hale gelebilir. Bu yüzden ekipler maliyeti deneme başına ve tamamlama başına ayırmalı ve mümkün olduğunda kabul edilen sonuç başına maliyeti ölçmelidir. Son sayı genellikle en faydalısıdır çünkü sistemin ürettiği fakat işletmenin kullanamadığı işi içerir.

Agent sistemleri, yolları bir çalıştırmadan diğerine değişebildiği için bunu daha da zorlaştırır. Unite.ai’nin the economics of scaling agentic AI workloads analizi, yönlendirme, araç çağrıları, yeniden denemeler ve iş akışı düzeyinde atıfları kapsar. Bu davranışlar, son kullanıcı yalnızca bir yanıt gördüğünde bile birim ölçüte dahil edilmelidir.

Ölçüt hâlâ mükemmel olmayacak. Paylaşılan hizmetler, önbelleğe alınmış sonuçlar, toplu işler ve gecikmeli işleme atıfları bulanıklaştırabilir. Karar vericiye faydalı bir tahmin, yanlış kesinlikten daha iyidir, özellikle de mühendislere hangi katmanın incelenmesi gerektiğini söyleyebiliyorsa.

Sayıyı Kim Sahipleniyor?

En zor kısmı organizasyonel olabilir. ML ekipleri model çağrılarını ve değerlendirmelerini anlar. Platform ekipleri iş yüklerini ve küme davranışını anlar. FinOps faturaları ve tahsis kurallarını anlar. Ürün ekipleri hangi sonucun önemli olduğunu bilir.

Hiçbir ekip tam zinciri sahip değil.

Bu, hangi panonun doğru olduğu konusunda öngörülebilir bir tartışma yaratır. ML ekibi daha düşük token kullanımına işaret ederken, platform ekibi GPU saatlerinin artığını, ürün ekibi ise önceki döneme göre daha az tamamlanmış görev gördüğünü görür. Üç gözlem aynı anda doğru olabilir. Paylaşılan ölçüt, bunlar arasındaki ilişkiyi açıklamalıdır.

Uygulanabilir bir başlangıç noktası, net bir tamamlama olayı olan bir üretim iş akışıdır. Sabit bir tanımlayıcı verin. Bu bağlamı model ve araç izlerine taşıyın, Kubernetes’te çalışan hizmete veya iş yüküne eşleyin ve tek bir iş denklemi seçin. Ardından sayı beklenmedik bir şekilde değiştiğinde ekipleri bir araya getirin.

Bu inceleme, cilalı bir panodan daha önemlidir. Ani bir artış, daha uzun istemlerden, yeni bir geri dönüş yolundan, düşük kullanılan GPU kapasitesinden, değişen otomatik ölçekleme politikasından veya AI özelliği üzerinden daha fazla iş gönderen bir ürün kararından kaynaklanabilir. Her neden farklı bir sahibine aittir.

Otomasyon daha sonra gelmelidir. Bir öneri motoru yalnızca aldığı etiketler ve eşiklere göre hareket edebilir ve hatalı bir payda, verimli bir sistemi israf gibi gösterebilir veya kullanıcıların reddettiği ucuz bir iş akışını ödüllendirebilir. Ekipler, sistemin sonuca göre hareket etmesine izin vermeden önce model davranışı ile uygulama tasarımı ve altyapı tahsisinin ayrımını yapabilecek kadar ortak görünürlük elde etmelidir. Aksi takdirde, otomatik bir maliyet düzeltmesi kapasiteyi azaltabilir, gecikmeyi artırabilir ve harcamayı daha az görünür bir yere kaydırabilir.

Maliyet Zinciri Paylaşılmalı

AI maliyet kontrolü, her ekip yalnızca görebildiği katmanı optimize ettikçe parçalı kalacaktır. Tokenlar, izler, podlar, hızlandırıcılar ve faturalar rekabetçi ölçümler değildir. Aynı maliyet zincirinin parçalarıdır.

Onları bağlayan şirketler ilk günde mükemmel bir sayı elde etmeyecek. Önemli olan, ekibin yüksek bir faturayı onu yaratan iş akışına geri izleyebilmesi, neyin değiştiğini anlayabilmesi ve sonucun maliyeti haklı çıkarıp çıkarmadığını karar verebilmesidir.