Ragmux ile proje başına LLM harcamasını takip edin

Her uygulama tek bir sağlayıcı API anahtarını paylaşıyorsa, “bu özellik geçen ay bize ne kadara mal oldu” sorusuna yalnızca sağlayıcının kendi fatura panosuna sorarak cevap verebilirsiniz — o pano da hangi uygulamanızın hangi çağrıyı yaptığı hakkında hiçbir şey bilmez. Ragmux’un cevabı, harcamanın atfedildiği, bütçelendiği ve export edildiği birimi elinizde o an bulunan API anahtarı değil, project yapmaktır.

Somut bir örnek: üç müşteri arasında chargeback

Bir LLM özelliği barındıran ve aynı Ragmux deployment’ından her biri farklı bir planda üç müşteriye hizmet veren bir SaaS ürününü ele alalım. Her müşteri kendi project’ini alır — bunlara acme-support, initech-support, globex-support diyelim — her biri kendi sk-proj-… anahtarıyla oluşturulur ve o müşterinin uygulamasının kendi instance’ına bağlanır. Bu kurulumda uygulama kodunun faturalandırıldığını bilmesini gerektiren hiçbir şey yoktur; herhangi bir OpenAI endpoint’ine karşı yapacağı gibi, kendisine verilen anahtarla /v1/chat/completions’ı çağırır, hepsi bu.

Baştan verilmeye değer kararlar bütçelerin kendisidir. Giriş seviyesi bir plandaki müşteri, o planın fiyatlandırıldığı miktara göre boyutlandırılmış bir budget_monthly_tokens alır; böylece kendi tarafındaki kontrolden çıkmış bir entegrasyon, SaaS’ın üstlendiği faturasız bir maliyete dönüşmek yerine planın kendi tavanında durur. Sınırsız bir kurumsal plandaki müşteri ise bilinçli olarak 0 (sınırsız) alır; bir tavan uygulamak yerine GET /admin/api/projects/{id}/usage içindeki tahmin izlenir. Bir fatura döneminin sonunda, müşteri project’i başına bir kez çalıştırılan GET /admin/api/projects/{id}/metrics.csv?window=720h, üç CSV dosyasına dönüşür — müşteri başına biri, maliyet sütunu dahil — ve bunlar üç faturadaki üç kalem üzerine doğrudan oturur; maliyetlerin müşteriler arasında yanlış bölüşülebileceği manuel bir atfetme adımı hiç yoktur.

Project’ler sonradan akla gelen değil, atfetme sınırının kendisidir

Bir Ragmux project’i bir model connection’ı, opsiyonel bir RAG store’u, bir system prompt’u ve kendi sk-proj-… anahtarını, bir uygulamanın çağırdığı tek bir şeyde birleştirir. Maliyet takibi için önemli olan her alan aynı project’e asılıdır: rate limit’leri (rate_limit_rpm, rate_limit_tpm), token bütçeleri (budget_daily_tokens, budget_monthly_tokens) ve o anahtarla yapılan her çağrı için request_logs’un yazdığı her satır. Bu atfetme, çağıran uygulamanın kendi isteklerini doğru etiketleyeceğine güvenmeye hiç dayanmaz — bir isteğin ait olduğu project, onu doğrulayan anahtarla sabittir; bu yüzden “support-bot’un harcaması” ile “internal-tools’un harcaması” kazara birbirine karışamaz.

Bu aynı zamanda ekip ya da müşteri başına maliyet merkezlerini basitleştiren şeydir: maliyet merkezi başına bir project, project başına bir bütçe, project başına bir CSV export’u. Aynı gateway’den birkaç müşteriye hizmet veren bir SaaS, her müşterinin entegrasyonuna kendi project’ini verebilir ve GET /admin/api/projects/{id}/metrics’i okuyarak o müşterinin trafiğinin tam olarak neye mal olduğunu görebilir — bir finans ekibinin dahili bir ekip bütçesi için isteyeceğiyle tıpatıp aynı şekil.

Token’lar uygulanır. Dolarlar tahmindir.

Burada “bütçe”nin ne anlama geldiği konusunda net olmakta fayda var, çünkü bunun para anlamına geldiğini varsaymak ve önemli bir şekilde yanılmak kolay. budget_daily_tokens ve budget_monthly_tokens, UTC gün ve takvim ayı sınırlarına hizalanmış olarak prompt-artı-completion token’larını sayar, ve sayılan pencere aşıldığı anda bir istek reddedilir — bu ret her çağrıda gerçek ve uygulanır. Yanındaki dashboard maliyet rakamı — her istek logu satırındaki cost_micros ve cost_usd — model adıyla eşleştirilen ayrı, düzenlenebilir bir fiyat tablosundan gelir ve açıkça bilgilendirici niteliktedir: hiçbir istek bir dolar rakamı için reddedilmez, yalnızca bir token sayısı için.

Bu bilinçli bir takas, bir gözden kaçırma değil: token sayıları, gateway’in her sağlayıcının kendi usage bloğundan kesin olarak bildiği şeydir; bir dolar rakamı ise birinin güncel tutması gereken bir fiyat tablosuna bağlıdır. Harcamaya görünürlük değil de sabit, uygulanan bir dolar tavanı asıl gereksinimse, bu gerçek bir boşluktur — başka bir self-hosted gateway’in para birimi cinsinden bütçeleri doğrudan nasıl ele aldığı için Ragmux vs LiteLLM sayfasına bakın.

Bir project içinde harcamayı atfetmek

Bir project’in kendi harcaması, her çağrıyı yapan kullanıcıya ait anahtara göre daha da bölünebilir. Her istek logu api_key_id ve user_id taşır — project’in kendi varsayılan anahtarıyla yapılan çağrılar için ikisi de null, bir ekip arkadaşının ya da bir servisin kendi sk-user-… anahtarıyla yapılan bir çağrı için doldurulmuş olur. Metrics özetinin recent listesi ve CSV export’u bu iki sütunu da taşır; böylece “bu project içinde hangi entegrasyon gerçekten pahalı” sorusu, project’i daha küçük birkaçına bölmeye gerek kalmadan cevaplanabilir.

CSV export’u (GET /admin/api/projects/{id}/metrics.csv ya da instance genelindeki GET /admin/api/metrics/requests.csv) tam olarak bunun için tasarlanmıştır: en eskiden başlayarak istek başına bir satır, ucuz bir isteğin hiçe yuvarlanmaması için altı ondalık basamağa yazılmış cost_usd, yanında model adı, token sayıları, gecikme ve isteğin retrieval kullanıp kullanmadığı. Yeni sütunlar yalnızca sona eklenir; böylece sütunları pozisyona göre okuyan bir spreadsheet ya da faturalama pipeline’ı upgrade’ler boyunca çalışmaya devam eder.

Birkaç entegrasyon bir project’i paylaştığında

Her maliyet merkezi tek bir project’e temiz şekilde oturmaz. Dahili bir platform ekibi, birkaç servisin çağırdığı tek bir internal-tools project’i çalıştırıyor olabilir — bir Slack botu, gece çalışan bir rapor üretici, birkaç mühendisin doğrudan kullandığı ad-hoc bir CLI — burada her birini kendi project’ine ayırmak, hiçbir gerçek fayda olmadan her birinin kendi model connection’ını ve system prompt’unu üç kez tekrarlaması demek olurdu. Bu şekil için, project geneli bir bütçe toplamı yine sınırlar, ama kontrolden çıkmış bir gece işini herkesin gerçekten bağımlı olduğu Slack botundan ayırt edemez.

Anahtar alt limiti tam olarak bunun için var: entegrasyon başına ayrı bir sk-user-… anahtarı basın (internal-tools/slack-bot, internal-tools/nightly-report), her biri kendi rate_limit_rpm ya da budget_daily_tokens’ıyla, project’in kendi tavanının altında ikinci bir tavan olarak kontrol edilir. Token tabanlı limitler — günlük ve aylık bütçeler, dakika başına token — aylık, sonra günlük, sonra dakika-başına-token sırasıyla, önce project sonra anahtar olacak şekilde değerlendirilir; fiilen aşılan ilk olan 429 üretir. Dakika başına istek limiti farklı çalışır: hem project’in hem anahtarın dakika slotları atomik olarak, önce project olacak şekilde rezerve edilir; böylece bir patlama iki kontrol arasından sızamaz. Her iki durumda da yanıt header’ları, hangi katmanın daha az alanı kaldıysa onu raporlar; böylece bir client her zaman bir sonraki gerçekten çarpacağı kısıtı görür, sadece project’inkini değil. Bu, “bu project bütçeyi aştı” ile “gece raporu işi bütçeyi aştı, Slack botunun hâlâ alanı var” arasındaki farktır — söyleyebilmeye değer olan ikincisidir.

Fatura gelmeden önce harcamayı izlemek

GET /admin/api/projects/{id}/usage, geçmişe dönük CSV’nin canlı karşılığıdır: mevcut dakika, gün ve ay pencerelerini yapılandırılmış limitlerine karşı raporlar, ve son 60 dakikalık tüketimi doğrusal olarak ileriye uzatıp bir bütçenin gerçekte ne zaman tükeneceğini öngören bir forecast nesnesi sunar. Bu tahmin, bir bütçeyi sonradan keşfedilen sabit bir dur noktasından, bir project sahibinin önceden görebileceği bir uyarıya çevirir — dashboard’un project sayfası aynı rakamları, bir endpoint’i sürekli sorgulamak yerine bir sayfaya bakmayı tercih eden ekipler için sıfırlanma geri sayımlı bir ilerleme halkası olarak sunar.

Bu aracın doğru araç olmaktan çıktığı yerler

“Harcama takibi”nin birkaç şekli yukarıda anlatılanın dışında kalır; entegrasyonun ortasında keşfetmek yerine baştan adını koymakta fayda var:

• Token değil, para birimi cinsinden sabit bir tavan. Bunu açıkça tekrarlamakta fayda var çünkü bu özelliğin karşılamadığı en yaygın beklenti bu: Ragmux’ta hiçbir şey bir dolar rakamını aştığı için değil, yalnızca bir token sayısını aştığı için bir isteği reddeder. “500 dolarda dur”un yalnızca görünür değil, uygulanır olmasını isteyen bir ekibin bunu bugün Ragmux’un dışında kurması gerekir — metrics endpoint’inden ya da requests CSV’sinden cost_usd’yi okuyup (usage raporu token sayaçlarını ve tahminleri taşır, maliyeti değil), kendi tanımladığınız bir eşik aşıldığında bir anahtarı programatik olarak iptal etmek ya da durdurmak gibi; gateway’in kendisi bunu sizin için yapmaz.
• UTC takvim ayına hizalanmayan fatura döngüleri. budget_monthly_tokens, bir müşterinin kendi sözleşme yıldönümünde ya da mali döneminde değil, UTC takvim ayının başında sıfırlanır; 15’inden 15’ine faturalandıran bir plan, bütçe sıfırlamasının faturasıyla hizalandığını görmez — yalnızca doğrudan sizin kontrol ettiğiniz CSV export’unun kendi window parametresi hizalanır.
• Bir pencerede 50.000’den fazla isteği kapsayan bir CSV çekimi. Her iki metrics CSV endpoint’i de tek bir yanıtı 50.000 satırla sınırlar; bunu bir export penceresi içinde aşacak kadar hacim üreten bir project, export’u daha dar zaman pencerelerine bölüp dosyaları birleştirmelidir — tek bir çağrının keyfi olarak büyük bir dönemi kapsamasını beklemek yerine.
• Sağlayıcının kendi faturasıyla mutabakat yapmayı gereksiz kılacak kadar hassas bir maliyet rakamı. cost_micros/cost_usd açıkça düzenlenebilir bir fiyat tablosundan gelen bir tahmindir, sağlayıcının fiilen faturaladığı şey değil — bunu harcamanın nerede yoğunlaştığını söyleyen rakam olarak değerlendirin ve kendi faturanıza geçmeden önce toplamı sağlayıcının kendi panosuyla mutabık kılın.