API Ağ Geçidinde LLM Harcama Limitlerini Zorunlu Hale Getirme

Sağlayıcı harcama sınırları yararlı destek noktalarıdır ancak bir şirketin gerçekte LLM harcamasına sahip olma şekliyle nadiren eşleşir. Finans, ekibe, uygulamaya, ortama, müşteriye, iş ortağına veya iş akışına göre sınırlamalar istiyor. Platform ekiplerinin, bir isteğin OpenAI, Anthropic, Gemini, Azure OpenAI veya başka bir model sağlayıcıya yayılmasından önce bu sınırların uygulanmasına ihtiyacı vardır. Doğru kontrol noktası genellikle her isteğin ilişkilendirilebildiği, tahmin edilebildiği, kabul edilebildiği, düzeyinin düşürülebildiği, bloke edilebildiği ve mutabakata varılabildiği API ağ geçididir.

Bu kılavuz AI API maliyet kontrolü için ağ geçidi katmanı uygulamasını açıklamaktadır. Geriye dönük ters ibraz raporlarına veya geniş kapsamlı maliyet optimizasyon programlarına değil, gerçek zamanlı bütçe uygulamasına odaklanır.

Sağlayıcı Harcama Kontrollerinin Yapabileceği ve Yapamayacağı Şeyler

Gerçek: Büyük sağlayıcılar yararlı kontroller sunar, ancak sağlayıcı tarafından tanımlanan sınırlarda çalışırlar. OpenAI aylık API harcama sınırlarını, kuruluş sınırları, proje sınırları, atanan kullanım sınırları ve biten ön ödemeli kredilerle ilgili belirgin hataların yanı sıra kuruluş ve proje düzeyinde belgeler. Anthropic, çalışma alanı harcamasını ve hız sınırlarını belgeliyor ve ayrıca dahili uyarı için yapılandırılmış organizasyon ve çalışma alanı sınırlarını almaya yönelik API'ler sağlıyor. Google Bulut bütçe uyarıları tek başına harcamayı otomatik olarak sınırlamaz; Google ayrıca Gemini API ve Agent Platform gibi uygun hizmetler için harcama sınırı olan bütçeleri de belgeler. Azure OpenAI kotası abonelik, bölge, model ve dağıtım türü başına dakika başına belirteç birimi cinsinden atanır ve hız sınırı hesaplamaları yalnızca son faturalandırılan belirteçleri değil, hızlı bir tahmin ve maksimum belirteçleri içerebilir.

Öneri: Son çare olarak sağlayıcıya özgü harcama sınırlarını etkin tutun. Bunları iç bütçeleri uygulamak için ana mekanizma olarak görmeyin. Çoğu sahiplik modeli için fazla kabadırlar ve genellikle istek yolu kontrolünüzden çıktıktan sonra tetiklenirler.

Tahmin: Sağlayıcı kontrolleri gelişmeye devam edecek ancak dahili maliyet sahipliği, sağlayıcı hesap yapılarından daha hızlı değiştiği için kuruluşların ağ geçidi düzeyinde politikalara ihtiyacı olmaya devam edecek.

Önce Bütçe Politikası Modelini Tanımlayın

Kodla değil politikayla başlayın. Ağ geçidi, kesin olarak tanımlanmayan bir bütçeyi zorunlu kılamaz.

Pratik bir politika kaydı şunları içermelidir:

• Bütçe sahibi: ekip, departman, müşteri, iş ortağı, uygulama veya iş akışı sahibi.
• Kapsam: team_id, app_id, environment, customer_id ve workflow_id gibi isteklerle eşleşen boyutlar.
• Sıfırlama aralığı: günlük, haftalık, aylık, sözleşme dönemi veya özel aralık.
• Yumuşak eşik: ağ geçidinin uyarı verdiği, düzeyini düşürdüğü, çıktı uzunluğunu azalttığı veya daha ucuz modellere yönlendirdiği nokta.
• Sert eşik: kritik olmayan trafiğin engellendiği nokta.
• İzin verilen modeller: bu kapsamın kullanabileceği modeller.
• Yedek modeller: Yumuşak bir eşikten sonra daha ucuz veya daha düşük kapasiteli modellere izin verilir.
• Kritiklik: iş yükünün üretim açısından kritik mi, kullanıcıya yönelik mi, dahili mi, toplu mu yoksa deneysel mi olduğu.
• Acil durum geçersiz kılma: sınırı kim, ne kadar süreyle ve hangi denetim takibiyle uzatabilir.
• Bildirim hedefleri: Gevşek kanal, e-posta grubu, olay hizmeti, web kancası veya finans kuyruğu.

Örnek politika:

{
  "budget_id": "budget_support_prod_monthly",
  "owner_type": "team",
  "owner_id": "customer_support",
  "scope": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production"
  },
  "currency": "USD",
  "limit": 5000.00,
  "reset_interval": "monthly",
  "soft_threshold_percent": 80,
  "hard_threshold_percent": 100,
  "allowed_models": ["premium-chat", "standard-chat", "economy-chat"],
  "fallback_models": ["standard-chat", "economy-chat"],
  "criticality": "user_facing_production",
  "on_soft_limit": ["notify", "downgrade_model", "reduce_max_output_tokens"],
  "on_hard_limit": ["block_noncritical", "allow_emergency_override"],
  "notification_targets": ["slack:#support-platform", "email:[email protected]"]
}

Her İstekte Sahiplik Meta Verilerini Gerektir

Bütçenin uygulanması ilişkilendirmeye bağlıdır. Bir istek bütçe kapsamıyla eşleştirilemiyorsa ağ geçidi güvenilir bir kabul kararı veremez.

Dahili istemcilerin kararlı sahiplik meta verileri göndermesini zorunlu kılın:

{
  "model": "premium-chat",
  "messages": [...],
  "max_tokens": 1200,
  "metadata": {
    "team_id": "customer_support",
    "app_id": "support_assistant",
    "environment": "production",
    "customer_id": "cust_48291",
    "workflow_id": "ticket_reply_draft"
  }
}

Öneri: Bunu aşamalı olarak kullanıma sunun. Öncelikle ilişkilendirilmemiş trafiği günlüğe kaydedin. O zaman uyarın. Daha sonra, sahiplerin istemcileri güncellemek için zamanları olduktan sonra, ilişkilendirilmemiş üretim trafiğini reddedin. Geliştirme trafiğini, üretim harcamasıyla karıştırmak yerine düşük tavanlı bir varsayılan bütçeyle karantinaya alın.

Ayrıca meta verileri kimlik sisteminize göre doğrulayın. Bir müşteri team_id'yi değiştirerek başka bir takımın bütçesini talep edememelidir. API anahtarlarını, hizmet hesaplarını veya iş ortağı kimlik bilgilerini izin verilen bütçe kapsamlarına bağlayın.

Göndermeden Önce Tahmini Maliyet

Ön kontrol tahmini, gerçek zamanlı yaptırımın temelidir. Ağ geçidi, isteği bir sağlayıcıya göndermeden önce olası maksimum maliyeti tahmin eder.

Tahmin edicinin ihtiyacı olan şeyler:

• Giriş, çıkış, önbelleğe alınmış giriş, toplu iş, araç kullanımı, resimler, yerleştirmeler veya diğer faturalandırılabilir boyutlar için fiyat tablolarını modelleyin.
• Model ailesi başına belirteç veya belirteç tahmin mantığı.
• İstem belirteci sayımı veya tahmini.
• İstenen max_tokens veya maksimum çıktı uzunluğu.
• İstem önbelleğe almanın faturalandırmayı etkilemesi durumunda önbellek varsayımları.
• Yeniden denemeler, araç çağrıları, akıl yürütme jetonları, görüntü oluşturma veya çok modlu giriş için sağlayıcıya özel faturalandırma kuralları.

Örnek tahmin aracı çıktısı:

{
  "request_id": "req_7f1b",
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "model": "premium-chat",
  "input_tokens_estimated": 1850,
  "max_output_tokens": 1200,
  "estimated_cost": 0.0845,
  "estimate_basis": "prompt_tokens_plus_max_output_tokens",
  "confidence": "conservative"
}

Öneri: Ön kontrol maliyetini, muhasebe gerçeği olarak değil, ihtiyatlı bir kabul tahmini olarak ele alın. Kullanıcı max_tokens: 4000 kodunu isterse, yanıt genellikle 700 jetonda dursa bile bu üst sınıra göre rezervasyon yapın. Bu, fazla harcama riskini azaltır ancak bütçenin altında tamamlanacak istekleri reddedebilir. Bu ödünleşim, sıkı finans kontrolleri açısından tercih edilir ve araştırma amaçlı dahili araçlar açısından daha az çekicidir.

İsteği Göndermeden Önce Bütçe Ayırın

Bütçeyi kontrol etmek, kullanılabilir bakiyeyi bulmak ve ardından harcama kaydedilmeden önce birçok eşzamanlı isteğin geçmesine izin vermek yaygın bir başarısızlık modudur. Çözüm rezervasyondur.

Kabul sırası şu şekilde olmalıdır:

1. Arayanın kimliğini doğrulayın.
2. Sahiplik meta verilerini doğrulayın.
3. Geçerli bütçe politikasını çözümleyin.
4. Talep maliyetini tahmin edin.
5. Bu tahmini maliyeti bütçe mağazasından atomik olarak ayırın.
6. Yalnızca rezervasyon başarılı olursa isteği sağlayıcıya gönderin.
7. Tamamlandıktan sonra kullanılmayan rezervasyonu iptal edin.
8. Nihai tahmini veya sağlayıcı tarafından bildirilen kullanımı kaydedin.

Rezervasyon mağazası atomik güncellemeleri desteklemelidir. Redis Lua komut dosyaları, PostgreSQL işlemleri veya özel bir defter hizmeti ile çalışabilir. Önemli olan özellik, iki isteğin aynı kalan bütçeyi harcayamamasıdır.

Örnek rezervasyon kaydı:

{
  "reservation_id": "res_9d42",
  "request_id": "req_7f1b",
  "budget_id": "budget_support_prod_monthly",
  "estimated_cost": 0.0845,
  "state": "reserved",
  "expires_at": "2026-09-28T12:45:00Z"
}

Terkedilen isteklerin bütçeyi sonsuza kadar kilitlememesi için rezervasyon sürelerinin kısa olmasını kullanın. Bir arka plan temizleyicisi, hiçbir zaman terminal durumuna ulaşmamış, süresi dolmuş rezervasyonları serbest bırakmalıdır.

Yumuşak Limitleri Sert Limitlerden Ayırın

Yumuşak ve sert limitler farklı davranmalıdır. Esnek limit bir politika sinyalidir. Kesin sınır, bir kabul kararıdır.

Esnek Limit Davranışı

Bir kapsam yumuşak eşiğini aştığında ağ geçidi, harcama baskısını azaltırken trafiğe hizmet vermeye devam edebilir. Yararlı yanıtlar şunları içerir:

• Bütçe sahibine ve finans veya platform kanalına uyarı gönderin.
• Sınır durumunu ve kalan bütçeyi gösteren yanıt başlıkları ekleyin.
• Kritik olmayan istekleri daha ucuz modellere yönlendirin.
• Ayrıntılı iş akışları için max_tokens sayısını azaltın.
• Çoklu örnek oluşturma gibi pahalı isteğe bağlı özellikleri devre dışı bırakın.
• Bu bütçe kapsamındaki yeni denemeler için onay gerektir.

Örnek yumuşak limitli yanıt meta verileri:

{
  "budget_scope": "team:customer_support/app:support_assistant/env:production",
  "limit_state": "soft_limit_exceeded",
  "estimated_cost": 0.0310,
  "remaining_budget": 912.44,
  "applied_policy": ["downgrade_model", "reduce_max_output_tokens"],
  "selected_model": "standard-chat"
}

Sert Limit Davranışı

Zor eşikte, ağ geçidinin kritik olmayan trafiği öngörülebilir bir hata sözleşmesiyle engellemesi gerekir.

{
  "error": {
    "type": "budget_limit_exceeded",
    "code": "llm_budget_hard_limit",
    "message": "The budget for this scope has been exhausted.",
    "budget_scope": "team:customer_support/app:support_assistant/env:production",
    "retry_after": "2026-10-01T00:00:00Z",
    "override_required": true
  }
}

Ağ geçidi bütçesi başarısızlıkları için sağlayıcı şeklindeki hataları döndürmeyin. Dahili müşterilerin, sağlayıcı ücreti sınırlarını, sağlayıcı harcama sınırlarını, ağ geçidi harcama sınırlarını, kimlik doğrulama hatalarını ve politika reddini birbirinden ayırması gerekir.

Akış İsteklerini Açıkça Ele Alın

Akış, farklı bir uygulama sorunu yaratır. İstek, ağ geçidi nihai çıkış jetonlarını bilmeden önce kabul edilir ve oluşturulan jetonlar, akış açıkken maliyet biriktirmeye devam edebilir.

Çalışılabilir bir model:

1. İstem belirteçlerine ve maksimum çıktı belirteçlerine göre makul bir miktar ayırın.
2. Mümkün olduğunda akış sırasında oluşturulan jetonları takip edin.
3. Ayrılmış tutar tükenirse oluşturmayı durdurun.
4. İstemcinin halledebileceği bir bitiş nedeni döndürün.
5. Sağlayıcı son kullanım meta verilerini gönderdikten veya ağ geçidi tahmini tamamlandıktan sonra gerçek kullanımı mutabakata varın.

Örnek akış sonlandırma etkinliği:

{
  "type": "response.completed",
  "finish_reason": "budget_exhausted",
  "budget_scope": "customer:cust_48291/workflow:ticket_reply_draft",
  "estimated_cost": 0.0845,
  "remaining_budget": 0.00
}

Ödünleşme: Bir akışın kesilmesi bütçeyi korur, ancak eksik çıktı üretebilir. Tam yapılandırılmış yanıtlar gerektiren iş akışları için akış başlamadan önce ön kontrol engellemeyi veya model düşürmeyi tercih edin. Sohbet tarzı deneyimler için, müşterinin kullanıcıdan daha sonra yeniden denemesini veya daha ucuz bir modelle devam etmesini isteyebilmesi durumunda, bütçeye uygun bir bitiş nedeni kabul edilebilir.

Bütçe Durumunu Müşterilere Açıklayın

Arayanlar ne olduğunu görebildikleri zaman bütçe uygulamasını benimsemek daha kolaydır. Dahili istemciler ve iş ortağı API'leri için yanıt üstbilgileri veya meta veriler ekleyin.

Yararlı alanlar şunları içerir:

• budget_scope
• limit_state: normal, soft_limit_near, soft_limit_exceeded, hard_limit_exceeded
• estimated_cost
• reserved_cost
• final_cost_when_available
• remaining_budget
• applied_policy
• selected_model

Genel iş ortağı API'leri için, ticari açıdan hassassa dahili ekip adlarının veya maliyet esasının sızdırılmasından kaçının. Bunun yerine remaining_quota, limit_state ve retry_after.

Tahminleri Sağlayıcı Kullanımıyla Uzlaştırın

İstek zamanı uygulaması ve muhasebe düzeyinde maliyet raporlama birbiriyle ilişkilidir ancak aynı şey değildir. Ağ geçidi tahmini belirsizlik altında kabul kararı verir. Sağlayıcı faturalandırma aktarımları, kullanım API'leri ve faturalar, finansın ilgileneceği kaydı sağlar.

Öneri: Ağ geçidi tarafından tahmin edilen harcamayı, en azından günlük olarak sağlayıcı tarafından bildirilen kullanımla uzlaştırın. Farklılıklar, belirteç uyumsuzluğu, istemi önbelleğe alma, toplu indirimler, yeniden denemeler, başarısız çağrılar, sağlayıcıya özel yuvarlama, resim veya araç kullanımıyla faturalandırma ve gecikmiş fatura dışa aktarmalarından kaynaklanabilir.

Mutabakat işi şunları yapmalıdır:

1. Sağlayıcı kullanımı ve maliyet verilerini içe aktarın.
2. Bunu ağ geçidinin kullanım şemasına göre normalleştirin.
3. Sağlayıcı kayıtlarını, mümkün olduğunda ağ geçidi istek kimlikleriyle eşleştirin.
4. Eşleşmeyen sağlayıcı harcamalarını bilinen en spesifik kapsama ayırın.
5. Bütçe defterlerini fazla veya az rezervasyona göre ayarlayın.
6. Sağlayıcıya, modele, ekibe, uygulamaya ve ortama göre farklılık raporları yayınlayın.

Giriş jetonları, çıkış jetonları, model, sağlayıcı, istek kimliği ve durum için normalleştirilmiş telemetri alanlarını kullanın. OpenTelemetry GenAI anlam kuralları, sağlayıcılar arasında kullanım telemetrisinin standartlaştırılmasına yardımcı olabilecek belirteç kullanım özelliklerini tanımlar.

Arıza-Açma veya Arıza-Kapatma Davranışını Kasıtlı Olarak Seçin

Bütçe deposu istek yolunun bir parçası haline gelir. Gerçek zamanlı yaptırımın ana mimari maliyeti budur.

Bütçe deposu kullanılamıyorsa ağ geçidinin tanımlanmış bir davranışa ihtiyacı vardır:

• Açıklama başarısız: isteklere izin verin ve bunları daha sonra mutabakat için işaretleyin. Bu, kullanılabilirliği korur ancak fazla harcamaya neden olabilir.
• Başarısız kapatıldı: Bütçe durumu kullanılabilir olana kadar istekleri engelle. Bu, harcamayı korur ancak üretim iş akışlarını bozabilir.
• Başarısızlık kısıtlı: yalnızca kritik üretim trafiğine izin verir, daha ucuz modeller kullanır, istek başına düşük sınırlar uygular ve denemeleri veya toplu iş yüklerini engeller.

Öneri: Çoğu iş sistemi için başarısızlık kısıtlamasını kullanın. Kritik üretim iş akışları, daha az maliyetle devam ederken isteğe bağlı iş yükleri, kontrol düzlemi düzelene kadar duraklatılır.

Uygulama Kontrol Listesi

• Bütçe kapsamlarını ve sahiplik meta verilerini tanımlayın.
• API anahtarı veya hizmet hesabını izin verilen kapsamlara bağlayın.
• Geçici sınırlar, kesin sınırlar, izin verilen modeller, geri dönüşler, geçersiz kılmalar ve bildirim hedefleriyle politika kayıtları oluşturun.
• Sağlayıcıyı tanıyan bir maliyet tahmin aracı oluşturun.
• Sağlayıcı gönderilmeden önce atomik bütçe rezervasyonlarını kullanın.
• Tamamlandıktan sonra kullanılmayan rezervasyonları iptal edin.
• Sabit sınır hatalarını istikrarlı bir sözleşmeyle uygulayın.
• Akış belirteci takibi ve bütçeye duyarlı bitiş nedenleri ekleyin.
• Bütçe durumunu dahili başlıklar veya yanıt meta verileri aracılığıyla gösterin.
• Sağlayıcı harcama sınırlarını geri döndürmez olarak etkin tutun.
• Ağ geçidi tahminlerini sağlayıcı kullanımı ve maliyet raporlarıyla günlük olarak bağdaştırın.
• Farklılık, ilişkilendirilmemiş trafik, tükenen bütçeler ve geçersiz kılma kullanımı hakkında uyarı.

Uygulanabilir Sonuç

LLM harcama sınırlarını güvenilir bir şekilde uygulamak için, isteklerin sisteminize gireceği yere karar verin. Sağlayıcı sınırları, hesap düzeyindeki hasarı durdurabilir ancak ağ geçidi politikası, liderlerin gerçekte istediği iş sınırlarını uygulayabilir: ekip, uygulama, ortam, müşteri, iş ortağı ve iş akışı bütçeleri.

Uygulanabilir minimum tasarım basittir: sahiplik meta verilerini zorunlu tutun, gönderimden önce maliyeti tahmin edin, bütçeyi atomik olarak ayırın, yumuşak ve sert eşikler uygulayın, akışı ayrı ayrı ele alın ve sağlayıcı kullanım verileriyle mutabakat sağlayın. İşin zor kısmı ilk blok kararı değil. İşin zor kısmı, sistemi, finansın ona güvenmesini ve üretim ekiplerinin bütçe baskı altındayken çalışmaya devam edebilmesini sağlayacak kadar öngörülebilir hale getirmektir.

İlgili okumalar

• ekip başına LLM maliyet defteri