Yazı
Şirket içi Model Orkestrasyonu İçin Kurumsal Yapay Zeka Geçidi Oluşturma
Tüm şirket içi yapay zeka modelleriniz arasında birleşik erişim, politika uygulaması ve trafik yönetimi sağlayan merkezi bir AI geçidi nasıl tasarlanır ve dağıtılır?
Yayılma Sorunu
Kurumlar şirket içinde daha fazla yapay zeka modeli dağıttıkça tanıdık bir kalıp ortaya çıkar: her ekip kendi modellerini kendi hizmet altyapısı, kimlik doğrulama mekanizmaları ve izleme araçlarıyla dağıtır. NLP ekibi bir GPU kümesinde metin sınıflandırma servisi çalıştırır. Bilgisayarlı görü ekibi başka bir kümeden nesne algılama modeli sunar. Veri bilimi ekibinin özel bir Flask API arkasında üç deneysel modeli vardır. Aylar içinde organizasyon, birleşik yönetimi olmayan düzinelerce yapay zeka uç noktasına sahip olur.
Bu yayılma her düzeyde operasyonel sıkıntı yaratır. Güvenlik ekipleri model erişimini tutarlı bir şekilde denetleyemez. Platform mühendisleri iş yükleri arasında GPU kullanımını optimize edemez. Uygulama geliştiren geliştiriciler, her biri farklı kimlik doğrulama kalıplarına, istek biçimlerine ve hata işlemeye sahip birden fazla API ile entegre olmalıdır.
Bir yapay zeka geçidi, tüm model etkileşimleri için tek bir giriş noktası sağlayarak bunu çözer. Tüketen uygulamalar ile model servis altyapısı arasında oturarak kimlik doğrulama, hız sınırlama, istek yönlendirme, günlükleme ve politika uygulaması gibi kesişen konuları yönetir.
AI Geçidinin Temel Mimarisi
Şirket içi bir AI geçidi dört ana katmandan oluşur:
Giriş katmanı tüm gelen istekleri alır ve TLS sonlandırma, kimlik doğrulama ve ilk doğrulamayı gerçekleştirir. Birleşik bir API sunar — genellikle OpenAI uyumlu veya özel bir şema — böylece tüketen uygulamalar hangi modelin isteği işlediğinden bağımsız olarak tek bir arayüzle etkileşime girer.
Yönlendirme katmanı her isteği hangi model örneğinin işleyeceğini belirler. Yönlendirme kararları istek içeriğine, istemcinin açık model seçimine, maliyet ve gecikme gereksinimlerine veya mevcut yüke dayalı olabilir. Bu katman ayrıca model sürümlemeyi de yönetir — çoğunluk kararlı sürüme gitmeye devam ederken trafiğin bir yüzdesini canary testi için yeni bir model sürümüne yönlendirebilirsiniz.
Politika katmanı istekler modellere ulaşmadan önce ve yanıtlar üretildikten sonra organizasyonel kuralları uygular. Ön işleme politikaları içerik filtreleme, kişisel veri tespiti ve maskeleme, prompt enjeksiyon tespiti veya giriş uzunluğu uygulamasını içerebilir.
Gözlemlenebilirlik katmanı her istek için metrikleri, günlükleri ve izleri yakalar. Bu, gecikme analizleri, token kullanımı, hata oranları ve modele özgü performans göstergelerini içerir.
Uygulama Yaklaşımları
Şirket içi AI geçidi oluşturmak için üç pratik seçeneğiniz vardır:
Mevcut API geçidini genişletin. Altyapınızda zaten Kong, NGINX veya Envoy çalıştırıyorsanız, bunları AI'ye özel eklentilerle genişletebilirsiniz. Kong, model yönlendirme, token sayma ve prompt mühendisliğini yöneten bir AI geçidi eklentisi sunar. Avantajı mevcut altyapıyı ve operasyonel bilgiyi kullanmaktır. Sınırlama ise bu araçların AI iş yükleri için tasarlanmamış olmasıdır.
Amaca yönelik bir AI geçidi dağıtın. LiteLLM ve MLflow AI Gateway gibi projeler özellikle AI model orkestrasyonu için tasarlanmıştır. LiteLLM, herhangi bir model arka ucuna yönlendirebilen OpenAI uyumlu bir proxy sağlar — vLLM, TGI, Ollama, TensorRT-LLM veya özel uç noktalar. Model yedeklemesi, yük dengeleme, bütçe takibi ve erişim kontrolünü hazır olarak sunar.
Özel bir geçit oluşturun. Benzersiz gereksinimleri olan organizasyonlar için — son derece özelleştirilmiş yönlendirme mantığı, tescilli sistemlerle derin entegrasyon veya sıkı performans kısıtlamaları — FastAPI veya Go'nun net/http paketi gibi yüksek performanslı bir çerçeve üzerine kurulmuş özel bir geçit uygun olabilir. Bu maksimum esneklik sağlar ancak önemli mühendislik yatırımı gerektirir.
Temel Geçit Politikaları
Politika katmanı, bir AI geçidinin en fazla organizasyonel değer sunduğu yerdir. Her kurumun ilk günden uygulaması gereken politikalar:
Kimlik doğrulama ve yetkilendirme. Her istek bir kimliğe bağlı olmalıdır. Mevcut kimlik sağlayıcınızı (Active Directory, Okta, Keycloak) kullanın ve model düzeyinde rol tabanlı erişim kontrolü uygulayın. Her ekibin her modele erişmesi gerekmez.
Hız sınırlama ve kotalar. Token tabanlı hız sınırlama, herhangi bir tüketicinin GPU kaynaklarını tekelleştirmesini önler. Tüketici başına kotaları kapasite planlamanızla uyumlu olarak ayarlayın. Geçit, kotaları aşan istekleri servis altyapısını aşırı yüklemek yerine kuyruğa almalı veya reddetmelidir.
Giriş koruma rayları. Bir istek modele ulaşmadan önce geçit, prompt enjeksiyon girişimlerini, modele gönderilmemesi gereken kişisel verileri ve uzunluk sınırlarını aşan girişleri kontrol etmelidir. Guardrails AI ve LLM Guard gibi araçlar, geçit ara katmanı olarak entegre edebileceğiniz hazır dedektörler sağlar.
Çıktı günlükleme ve denetim izleri. Her model etkileşimi — giriş, çıktı, model sürümü, gecikme, tüketici kimliği — yalnızca ekleme yapılabilen bir denetim deposuna kaydedilmelidir. Bu, düzenlemeye tabi sektörler için tartışılmaz bir gerekliliktir.
AI İş Yükleri İçin Trafik Yönetimi
AI çıkarım iş yükleri, tipik API trafiğinden ayıran ve özelleştirilmiş trafik yönetimi gerektiren özelliklere sahiptir:
Değişken gecikme. 10 token üreten bir istek, 2.000 token üretenden çok daha kısa sürer. İstek sayısına göre yönlendiren standart yük dengeleyiciler gerçek hesaplama yükünü dengesiz dağıtır. Basit round-robin yerine her arka ucun mevcut kuyruk derinliğini ve aktif istek sayısını dikkate alan yük duyarlı yönlendirme uygulayın.
Akış yanıtları. Birçok LLM uygulaması, akış token üretimi için sunucu taraflı olayları (SSE) kullanır. Geçidiniz uzun ömürlü bağlantıları bağlantı havuzlarını engellemeden verimli bir şekilde yönetmelidir.
Toplu optimizasyon. Aynı model için kısa bir süre içinde birden fazla istek geldiğinde, bunları tek bir çıkarım çağrısında gruplamak GPU kullanımını önemli ölçüde iyileştirebilir. Geçit, gelen istekleri kısa bir arabellekte (5-20ms) tutarak ve uyumlu istekleri gruplayarak istek birleştirme uygulayabilir.
Zarif bozulma. Birincil modeller kullanılamadığında yedek davranışlar tanımlayın. Geçit otomatik olarak daha küçük bir yedek modele yönlendirebilir, benzer sorgular için önbelleğe alınmış yanıtlar döndürebilir veya istekleri gecikmeli işleme için kuyruğa alabilir.
Operasyonel Değerlendirmeler
Geçidin kendisini yüksek erişilebilirliğe sahip bir servis olarak dağıtın — tüm model trafiği üzerinden aktığında kritik bir yol bileşeni haline gelir. Sağlık kontrollü bir yük dengeleyici arkasında en az üç örnek çalıştırın. Geçidi durumsuz tutun, böylece örnekler koordinasyon olmadan eklenebilir veya çıkarılabilir.
Geçit yapılandırmanızı altyapı kodunuzla birlikte sürümlendirin. Yönlendirme değişiklikleri, politika güncellemeleri ve model eklemeleri, diğer altyapı değişiklikleriyle aynı inceleme ve dağıtım sürecinden geçmelidir. Bu özellikle önemlidir çünkü yanlış yapılandırılmış bir geçit, üretim trafiğini sessizce yanlış modele yönlendirebilir veya kritik koruma raylarını devre dışı bırakabilir.
Geçit gözlemlenebilirliğini model gözlemlenebilirliğinden ayrı planlayın. Geçidin kendisi sağlık metriklerini, operasyonel metrikleri ve iş metriklerini açığa çıkarmalıdır. Platform ekibinizin geçit davranışını bireysel model performansından bağımsız olarak anlamasını sağlayan panolar oluşturun.
Öne çıkan görsel: Albert Stoynov, Unsplash.