Yeni yapay zeka özelliklerinizdeki sessiz katili hiç düşündünüz mü? Hayır, Skynet değil. Daha kötüsü. Fatura.
“Çalıştığım” bir ekip – onlara Masumlar A.Ş. diyelim – ilk LLM özelliğini iki haftada çıkardı. İki hafta! Sonra, altı hafta sonra, BAM. 47.000 dolarlık bir OpenAI faturası. Hem de ücretsiz tier bir ürün için. Vay canına.
Çok pahalı bir ders alarak bunu öğrendiler diyebiliriz.
Olay sonrası inceleme, ne yapmamak gerektiği konusunda bir ustalık dersiydi. Meğer bir kiracı, yeniden deneme mantığını yavaş günler için bir öneri sanmış, bir diğeri modele neşeyle “on bin token’da yanıt ver” demiş (neden olmasın ki?), üçüncüsü ise, nasıl desem, bir hevesli, API anahtarının aslında sınırsız olduğunu keşfetmiş ve tüm toplu işlem iş yükünü onun üzerinden çalıştırmaya karar vermiş. Direkt SDK çağrıları. Hız sınırı yok. Kiracı başına bütçe yok. Maliyet limiti yok. Denetim izi yok. Hiçbir şey. Sadece saf, işlenmemiş API istismarı, paylaşımlı bir anahtar sayesinde.
Eğer ekibiniz LLM özelliklerini hala aynı şekilde – sanki 1999 yılındayız ve bant genişliği bedava – geliştiriyorsa, bu yazı sizin için. Çünkü o şok edici faturayı almadan önce, koruma mekanizmalarına ihtiyacınız var. Bu iş tekerleği yeniden icat etmekle ilgili değil. Müşterileriniz ile LLM sağlayıcısı arasına yerleşen, çalışır durumda, kiracılı bir Spring Boot gateway’i inşa etmekle ilgili. Yapay zeka partiniz için barmen gibi düşünün.
API anahtarlarını, hız sınırlarını, token bütçelerini, önbelleği ve denetim günlüklerini zorunlu kılar. Üretime gitmeden önce ihtiyacınız olan sıkıcı, yetişkinlere yönelik şeyler, mali işler müdürünüz kabus görmeye başladıktan sonra değil.
Sorun: Tek Bir Hata Noktası
Uygulama kodunuz OpenAI’ı doğrudan çağırdığında, sağlayıcıya her istek aynı görünür. Tek bir API anahtarı, tek bir kaynak, tek bir fatura görürler. Kalabalık bir apartman binasındaki herkesin aynı tek posta kutusunu kullanması gibi. Kaos.
Bu şu anlama geliyor:
- Anahtarları kiracı bazında kapsamlayamazsınız. Tek bir paylaşımlı anahtar, kötü bir kiracının tüm ürünü çökertmesi anlamına gelir. Koordineli bir çoklu dağıtım olmadan rotasyon imkansızdır. Bununla ilgili bol şans.
- Kiracı başına harcamayı sınırlayamazsınız. Bir gateway olmadan, aylık bütçeyi aştığınızı fatura geldiğinde öğrenirsiniz. Gerçek zamanlı olarak kısıtlayamazsınız. Sürpriz!
- Kontrolden çıkmış yanıtları engelleyemezsiniz. On bin token isteyen hatalı bir prompt mutlu mesut çalışır. Sağlayıcı bunun yanlış olduğunu bilmez; siz sonradan öğrenirsiniz. Pahalı.
- Deterministik çağrıları önbelleğe alamazsınız.
temperature=0ile aynı istekler her seferinde ücretlendirilir. Paylaşımlı bir önbellek katmanı, paylaşımlı hiçbir şey anlamına gelmez. - Hiçbir şeyi denetleyemezsiniz. Bir müşteri, “yapay zekanız bana yanlış bilgi verdi” diye şikayet ettiğinde, ne gönderildiğini, ne geri geldiğini veya hangi modelin kullanıldığını yeniden oluşturamazsınız. Veriler, sorgulayamadığınız OpenAI’ın günlüklerinde bulunur. Dedektiflik oynamaya bol şans.
A standard fix is a gateway. The question is what controls it actually enforces. And how it enforces them.
Gateway’in Sekiz Kademeli Savunma Sistemi
Bu gateway sadece bir geçit değil. Her biri belirli bir endişeyi zorlayan sekiz aşamadan oluşan sofistike bir pipeline’dır. Yapay zeka istekleriniz için son derece organize, çok katı bir TSA kontrol noktası gibi düşünün.
Müşteri
POST /v1/chat/completions
Authorization: Bearer <tenant_api_key>
Aşama 1: Kimlik Doğrulama -> hash'lenmiş anahtar araması, kiracı çözme
Aşama 2: Girdi normalleştirme -> model/parametreleri kanonik hale getirme, baytları sayma
Aşama 3: Politika kararı -> İZİN VER / DÜŞÜR / ENGELLE
Aşama 4: Kota zorlama -> hız sınırı + bütçe kontrolü (Redis)
Aşama 5: Önbellek araması -> yalnızca temperature=0 ve politika izin verirse
Aşama 6: Sağlayıcı çağrısı -> sınırlı zaman aşımı, devre kesici
Aşama 7: Yanıt filtreleme -> sağlayıcı meta verilerini soyma, PII'yi gizleme
Aşama 8: Denetim + toplama -> PostgreSQL'e yazma, sayaçları artırma
Müşteri yanıtı alır
Mimari, üç depolama bileşenine dayanır. Kalıcı öğeler için PostgreSQL – kiracılar, anahtarlar, politikalar, denetim günlükleri. Hızlı yol için Redis – hız sınırı sayaçları, semaforlar, belki önbellek. Ve sonra, yük dengeleyicinin arkasında duran durumsuz gateway örnekleri. Yatay olarak ölçeklenir. Çok kolay.
Politika Sanatı: Tüm Engeller Eşit Değildir
Gateway’i yapan veya bozan tasarım kararı, politika zorlamasını nasıl ele aldığıdır. Çoğu ekip ya “limitleri aşan her şeyi engelle” ya da “her şeyi kaydet ama asla engelleme” moduna geçer. Her ikisi de… yanlış. Feci şekilde yanlış.
Gateway, kiracı başına, politika başına yapılandırılabilen üç mod destekler. Sihir burada gerçekleşir.
HARD — Limit aşıldığında isteği reddeder. Bir neden koduyla 429 (hız sınırı) veya 402 (bütçe aşıldı) döndürür. Bu, aşımın kabul edilmediği ücretli planlardaki kiracılar içindir. İstisna yok. Tartışma yok.
SOFT — İsteği reddetmek yerine düşürür. Gateway isteği yeniden yazar: daha ucuz bir modele geçer, max_tokens düşürür, parametreleri sıkılaştırır. Kullanıcı bir yanıt alır — sadece birinci sınıf kalite değil. Bir indirimli havayolu koltuğu almak gibi, ilk sınıftan ziyade. Hiç yoktan iyidir.
OBSERVE — İsteğe izin verir ancak denetim günlüğünde işaretler. Yeni bir politikayı yaygınlaştırmak için kritiktir. Hangi kiracıların aslında etkilenmeden engelleneceğini veya düşürüleceğini tam olarak görürsünüz. Politikayı HARD veya SOFT’a çevirmeden gerçek trafikle doğrularsınız. Bu, değişiklikleri uygulamak için tek mantıklı yol.
OBSERVE modu pratiktir. Politika eşiklerini ilk denemede asla doğru bulamazsınız. Bunları ayarlamak, OBSERVE modunda iki hafta çalıştırmak, engellenmiş/düşürülmüş trafiği incelemek ve ardından HARD veya SOFT’a geçmek tek güvenli yayılma yoludur.
Durum Yönetimi: Veritabanı Omurgası
Duyarlı durum için beş tablo yeterlidir. Zayıftır. Etkilidir.
tenants
id, name, status (ACTIVE/SUSPENDED), created_at
api_keys — anahtarlar asla düz metin olarak saklanmaz. Neyse ki.
id, tenant_id, key_hash, scopes, status,
created_at, last_used_at, rotated_at
policies — kiracı başına bir satır. Kuralların yaşadığı yer burasıdır.
tenant_id,
allowed_models (json),
max_prompt_tokens (integer),
max_completion_tokens (integer),
max_requests_per_minute (integer),
max_budget_usd (decimal),
// diğer ayarlar için vb. devam eder
usage_rollups — günlük toplamlar için. Çünkü büyük resmi görmeniz gerekir.
tenant_id, model, date, total_prompt_tokens, total_completion_tokens, total_cost_usd, total_requests
audit_logs — hata ayıklama ve uyumluluk için temel.
id, tenant_id, key_id, request_timestamp, request_body_hash, response_status, response_body_hash, model_used, prompt_tokens, completion_tokens, cost_usd, latency_ms
Gerçek MVP: Gözlemlenebilirlik
Bir müşteri arızalı yapay zeka çıktısı hakkında bağırırken, verilere ihtiyacınız var. Mazeretlere değil. Denetim günlükleri adli bir iz sağlar. Tam isteği, kullanılan modeli ve alınan yanıtı yeniden oluşturabilirsiniz. Bu sadece hata ayıklama için değil; uyumluluk ve anlaşmazlık çözümü için de temeldir. Günlükler olmadan 47.000 dolarlık bir faturayı açıklamaya çalışmayı hayal edin. Hoş değil.
Bu gateway sadece bir maliyet kontrol mekanizması değil; operasyonel bir gerekliliktir. LLM entegrasyonunu vahşi batı başıboşluğundan yapılandırılmış, yönetilebilir ve – cesaret edebilir miyim? – karlı bir çabaya dönüştürür. Bunu şimdi inşa etmek, gelecekte o ruh emici fatura çağrılarını yapan siz olmayacağınız anlamına gelir. Mali işler müdürünüz size teşekkür edecek. Geliştiricileriniz hatta uyuyabilecek.
