Kurum İçi LLM Çıkarımında Token Bütçe Yönetimi ve Maliyet Atıflandırması

Kurum İçi Yapay Zekadaki Gizli Maliyet Görünürlük Sorunu

Bulut LLM sağlayıcıları maliyet görünürlüğünü varsayılan olarak çözer — her API çağrısı bir token sayısı döndürür ve her tokenin bir fiyatı vardır. Çıkarımı kurum içine taşıdığınızda, veri ve gecikme süresi üzerinde kontrol kazanırsınız ancak bu yerleşik maliyet şeffaflığını kaybedersiniz. Donanım maliyetleri sabittir (GPU'lar, ağ, soğutma için sermaye harcaması) ve kullanım ekipler arasında paylaşılır, bu da bireysel çıkarım isteklerinin ücretsiz olduğu yanılsamasını yaratır.

Bu yanılsama israf dolu tüketime yol açar. Maliyet sinyalleri olmadan uygulama ekipleri aşırı bağlam pencereli istemler yazar, başarısız istekleri geri çekilme olmadan yeniden dener ve yüzlerce çıkarım çağrısının yeterli olacağı yerlerde binlerce çağrı yapan özellikler oluşturur. Kapasitesinde çalışan paylaşımlı bir kurum içi GPU kümesi ücretsiz değildir — bu, bir ekibin isteklerinin sıraya alındığı anlamına gelirken, başka bir ekibin verimsiz istemleri daha iyi tasarımla üç kat daha fazla trafiğe hizmet edebilecek kaynakları tüketmektedir.

Token bütçe yönetimi, bulut maliyet atıflandırmasının disiplinini kurum içi altyapıya getirir. Gerçek para talep etmesi gerekmez — amaç tüketimi görünür kılmak, kapasiteyi adil dağıtmak ve ekiplere kullanımlarını optimize etmek için ihtiyaç duydukları bilgiyi vermektir.

Ölçümleme: Gateway Düzeyinde Token Sayma

Doğru ölçümleme temeldir. Her çıkarım isteği, alt akışta atıflandırma ve bütçeleme kararlarını destekleyecek yeterli ayrıntı düzeyinde sayılmalıdır.

En pratik ölçümleme noktası, uygulama istemcileri ile çıkarım arka uçlarınız arasında yer alan bir API gateway'dir. Bu gateway zaten yönlendirme, kimlik doğrulama ve hız sınırlama işlemlerini yönetir — token ölçümlemesi eklemek doğal bir genişlemedir. Her istek için gateway şunları kaydeder: girdi token sayısı (istem uzunluğu), çıktı token sayısı (tamamlama uzunluğu), model tanımlayıcısı (farklı modellerin farklı kaynak maliyetleri olduğundan), talep eden ekip veya hizmet kimliği ve istek zaman damgası ve gecikme süresi.

Token sayımı, sunulan modelle aynı tokenizer kullanılarak yapılmalıdır. Genel bir kelime sayısı yaklaşımı kullanan bir ölçümleme sistemi, zamanla biriken atıflandırma hataları üretecektir. Çoğu çıkarım çerçevesi (vLLM, TGI, Triton) yanıt meta verilerinde token sayılarını sunar — bunları bağımsız olarak hesaplamak yerine çıkarın.

Ölçümleme verilerini ekip, uygulama, model ve istek türü etiketleriyle bir zaman serisi veritabanında (Prometheus, InfluxDB veya TimescaleDB) saklayın. Saklama politikaları, kapasite planlaması ve bütçe müzakerelerini desteklemek için yüksek çözünürlüklü veriyi en az 30 gün, toplu veriyi ise 12 ay tutmalıdır.

Maliyet Atıflandırması: Tokenlardan Para Birimine

Ham token sayıları, organizasyonel karar alma için maliyetlere dönüştürüldüğünde faydalı hale gelir. Kurum içi maliyet atıflandırması, token tüketimini altyapıyı çalıştırmanın gerçek masraflarına eşleyen bir maliyet modeli gerektirir.

Sunduğunuz her model için tam yüklü token başına maliyetinizi hesaplayarak başlayın. Çıkarım altyapısıyla ilişkili tüm maliyetleri toplayın — GPU kirası veya amortisman, elektrik, soğutma, ağ, depolama ve operasyon ekibinin zamanı — ve aynı dönemde işlenen toplam tokenlara bölün. Bu, kurum içi yatırım getirinizi doğrulamak için doğrudan bulut API fiyatlandırmasıyla karşılaştırılabilecek harmanlanmış bir token başına maliyet verir.

Farklı modellerin farklı token başına maliyetleri vardır çünkü farklı miktarlarda GPU belleği ve hesaplama tüketirler. 70 milyar parametreli bir model dört A100 GPU'da çalışırken, tek bir GPU'daki 7 milyar parametreli bir modelden yaklaşık sekiz kat daha fazla token başına maliyete sahiptir. Maliyet modeliniz bu farklılıkları yansıtmalıdır, böylece kullanım durumları için daha küçük, daha verimli modeller seçen ekipler tasarrufları atıflandırma raporlarında görebilir.

Maliyet atıflandırma raporlarını en az haftalık olarak yayınlayın. İlk birkaç rapor insanları şaşırtacaktır — kullanımlarının mütevazı olduğuna inanan ekipler genellikle en büyük tüketiciler arasında olduklarını keşfeder. Bu görünürlük tek başına, herhangi bir zorlama olmaksızın, ekiplerin en bariz israf kalıplarını optimize etmesiyle toplam tüketimi tipik olarak %15-25 azaltır.

Bütçe Tahsisi ve Kota Tasarımı

Ölçümleme ve atıflandırma stabil hale geldiğinde bütçeleri tanıtabilirsiniz. Bütçe, bir ekibe veya uygulamaya belirli bir dönem için tahsis edilen, ekibin meşru ihtiyaçlarına ve organizasyonun toplam kapasitesine göre belirlenen bir token kotasıdır.

Kota sisteminizi üç katmanlı tasarlayın. Garantili kota, ekibin herhangi bir zamanda rekabet olmaksızın tüketebileceği temel tahsistir — bu sınıra kadar istekleri asla sıraya alınmaz veya reddedilmez. Anlık artış kotası, kümenin boş kapasitesi olduğunda mevcut olan ek kapasitedir, en iyi çaba temelinde sunulur. Kesin üst sınır, mevcut kapasite ne olursa olsun aşılamayan mutlak tavandır.

Garantili kotaları, ölçümleme sisteminizden elde edilen geçmiş tüketim verilerine göre belirleyin ve büyüme için %20-30 dolgu ekleyin. Aşırı tahsisten kaçının — tüm garantili kotaların toplamı kümenizin sürdürülebilir iş hacmi kapasitesini aşarsa, garantiler anlamsızdır. Anlık artış katmanı, muhafazakar garantili kotaları çalışır kılan esneklik tamponunu sağlar.

Kota devri konusunda dikkatli olun. Kullanılmayan kotanın birikmesine izin vermek ters teşvikler yaratır. Daha iyi bir yaklaşım, garantili kotaları gerçek kullanıma göre üç ayda bir gözden geçirip ayarlamaktır.

Uygulama: Hız Sınırlama, Sıraya Alma ve Zarif Bozulma

Uygulaması olmayan bütçeler birer öneriden ibarettir. API gateway'iniz, kota sınırlarını gelen istekler için gerçek zamanlı kabul kararlarına dönüştüren bütçe uygulaması gerçekleştirmelidir.

Uygulama akışı şöyle çalışır: bir istek geldiğinde, gateway talep eden ekibin mevcut tüketimini kotalarıyla karşılaştırır. Ekip garantili kotası dahilindeyse istek hemen devam eder. Garantili kotasını tüketmiş ancak anlık artış kapasitesi mevcutsa istek daha düşük zamanlama önceliğiyle devam eder. Kesin üst sınırına ulaşmışsa istek, kotanın ne zaman yenileneceğini gösteren bir Retry-After başlığıyla birlikte 429 durum kodu alır.

Uzun süren veya akış istekleri için bir token rezervasyon mekanizması uygulayın. Büyük girdi bağlamına sahip bir istek geldiğinde, toplam token maliyetini (girdi artı beklenen çıktı) tahmin edin ve çıkarıma başlamadan önce bu miktarı ekibin kotasından ayırın.

Uygulama ekiplerinizin çıkarım API'siyle etkileşim kurmak için kullandıkları maliyet bilincine sahip istemci kütüphaneleri oluşturun. Bu kütüphaneler ekibin mevcut tüketimini ve kalan kotasını açığa çıkarmalı, sınırlara yaklaşıldığında otomatik olarak üstel geri çekilme uygulamalı ve gönderim öncesi istem düzeyinde maliyet tahminleri sağlamalıdır.

Operasyonel Panolar ve Optimizasyon Geri Bildirim Döngüleri

Son parça, maliyet verilerini optimizasyon fırsatlarını ortaya çıkaran ve zaman içindeki ilerlemeyi izleyen panolar aracılığıyla eyleme dönüştürülebilir kılmaktır.

Ekip düzeyinde bir pano oluşturun: kotaya karşı mevcut tüketim (eğilim çizgileriyle), mevcut dönemdeki en pahalı 10 istek, ekibin toplam kullanımı içindeki uygulama bazlı dağılım ve organizasyonel kıyaslamalara karşı istem verimliliği (girdi tokeni başına çıktı tokeni) karşılaştırması. En pahalı isteklerini gören ekipler, genellikle bir özetin eşdeğer sonuçlar üreteceği yerlerde tüm belgeleri bağlam olarak gönderdiklerini keşfeder.

Platform ekibi için toplam kullanımı, model başına maliyet eğilimlerini ve kapasite tahminlerini gösteren bir altyapı düzeyinde pano oluşturun. Kullanım sürekli olarak toplam kapasitenin %80'ini aştığında, ya donanım ekleme ya da en yüksek tüketici ekiplerle optimizasyon üzerinde çalışma zamanıdır.

Platform ekibinin her uygulama ekibiyle tüketim kalıplarını gözden geçirdiği, optimizasyon fırsatlarını tartıştığı ve bir sonraki çeyrek için kotaları ayarladığı üç aylık bir maliyet incelemesi oluşturun. Bu incelemeler, maliyet yönetimini yukarıdan dayatılan bir emirden işbirlikçi bir mühendislik pratiğine dönüştürür.

Öne çıkan görsel: 2H Media tarafından Unsplash'ta yayınlanmıştır.