Bir panoda ayın toplam harcamasını görmek yararlıdır. Ama o sayı, aynı anda başlayan bir sonraki isteğin kabul edilip edilmeyeceğini tek başına belirlemez. Maliyet raporu geçmişe bakar; bütçe kontrolü henüz tamamlanmamış bir işlem hakkında karar verir.
Bu ayrım LLM çağrılarında belirginleşir. Girdi büyüklüğü hakkında çağrı öncesinde bir tahmin yapılabilir, fakat üretilen çıktı miktarı ancak üretim ilerledikçe netleşir. Başlangıçtaki tahmin ile tamamlanma sonrasındaki kullanım kaydını aynı değer gibi ele almak, hem raporlamayı hem limit davranışını belirsizleştirir.
Üç ayrı soruya üç ayrı cevap
Bütçe ekranındaki her değerin neyi temsil ettiği açık olmalı:
| Soru | Kullanılacak bilgi | Ne zaman bilinir? |
|---|---|---|
| Yeni çağrıyı başlatabilir miyiz? | Tahmini maliyet ve geçerli limit | Çağrı öncesinde |
| Çağrı ne kadar tüketti? | Gerçekleşen token kullanımı | Kullanım bilgisi geldiğinde |
| Dönemde ne kadar harcandı? | İşlenmiş kullanım kayıtları | Kayıtlar uzlaştırıldıkça |
Modelion'un hiyerarşik bütçe kontrolü, sağlayıcı çağrısından önce tahmini maliyeti ilgili kapsamlarla karşılaştırır. Gerçekleşen kullanım ise tamamlanma sonrasında bütçe ve kayıt hattını besler. Kontrol kararı ile sonradan oluşan kayıt farklı aşamalara aittir.
Eşzamanlılık basit hesabı değiştirir
Kavramsal bir örnek düşünün: kalan kapasite 10 birim, aynı anda gelen iki isteğin tahmini maliyeti 7'şer birim. İkisi de yalnızca aynı eski bakiyeyi okursa ayrı ayrı uygun görünebilir. Bir toplam göstermek, bu yarış durumunu çözmez.
Kesin bir üst sınır tasarlamak isteyen sistemlerin, kontrol ile kapasite ayırmayı ortak ve atomik bir işlem olarak ele alması gerekir. Rezervasyon kullanan bir tasarımda tamamlanma, iptal ve zaman aşımı yolları da bu ayrılmış kapasiteyi doğru biçimde sonuçlandırmalıdır. Bu, yalnızca bir sayaç ekleme meselesi değildir.
Redis'in işlem dokümanı, eşzamanlı istemcilerin ortak bir değeri güncellerken karşılaştığı yarışları ve koşullu işlemleri açıklar. Buradaki ders teknoloji seçiminden bağımsızdır: okuma ile yazma arasındaki değişikliği hesaba katın. Redis transactions.
Soft ve hard limit aynı beklentiyi doğurmamalı
Soft limit bir görünürlük veya uyarı eşiği olarak kullanılabilir; trafiği kesmeyebilir. Hard limit ise kontrolün kapsamındaki yeni çağrıları durdurmak için tasarlanır. Ekranda ikisine de yalnızca "limit" yazmak, kullanıcının yanlış bir durdurma garantisi varsaymasına yol açabilir.
Ayrıca kontrolün hata davranışı da önemlidir. Bütçe bilgisine ulaşılamadığında çağrı devam mı edecek, duracak mı? Bu seçim, normal limit hesabından ayrı bir operasyon kararıdır ve ilgili akış için açıkça belgelenmelidir.
Kapsamı doğru okuyun
Bir ekip kendi limitinin altında olabilir, ama organizasyonun ortak limiti dolmuş olabilir. Sanal anahtar, kullanıcı, ekip ve organizasyon seviyelerinin aynı isteğe nasıl uygulandığı anlaşılır olmalı.
Destek incelemesinde "kalan bütçe var" ifadesi tek başına yeterli değildir. Hangi kapsam, hangi dönem ve hangi kullanım kaydı üzerinden konuşulduğunu belirtin. Sonuç ancak aynı kapsam ve dönem karşılaştırıldığında anlamlıdır.
Rapor ile kontrolü birlikte tasarlayın
İyi bir bütçe deneyimi; reddedilen çağrının nedenini, bekleyen kullanımın durumunu ve gerçekleşen tüketimi birbirine bağlar. Kullanıcı yalnızca büyük bir toplam sayı değil, yeni bir çağrının neden kabul edildiğini veya durdurulduğunu da anlayabilmelidir.
