Çok Uygulamalı Kurum İçi Yapay Zeka İçin Paylaşılan Gömme Altyapısı

Gömme Yayılması Sorunu

Kuruluşlar kurum içinde daha fazla yapay zeka uygulaması dağıttıkça, israf yaratan ve mimari açıdan kırılgan bir kalıp ortaya çıkar: her ekip kendi gömme modelini çalıştırır. Müşteri destek ekibi bilet sınıflandırması için bir cümle dönüştürücü dağıtır. Bilgi yönetimi ekibi belge araması için aynı modelin başka bir örneğini çalıştırır. Ürün ekibi öneri özellikleri için bir kopyası daha kullanır. Her dağıtım GPU belleği tüketir, bağımsız bakım gerektirir ve en sorunlu şekilde birbirleriyle uyumlu olmayan gömmeler üretir.

Bu yayılmanın maliyeti önemlidir. Gömme modelleri, büyük dil modellerinden daha küçük olmalarına rağmen yine de kayda değer GPU kaynakları tüketir. 1,5 milyar parametreli bir gömme modelinin beş bağımsız örneğini çalıştırmak, kapasite fazlasıyla tek bir paylaşılan örneğe hizmet edebilecek GPU belleğini tüketir. Donanım maliyetlerinin ötesinde, operasyonel yük katlanır: beş dağıtım, beş güncelleme döngüsü, beş izleme yapılandırması ve beş potansiyel arıza noktası anlamına gelir.

Gömme üretimini paylaşılan bir serviste merkezileştirmek, bu fazlalıkları ortadan kaldırırken yeni mimari olanaklar yaratır — uygulamalar arası arama, tutarlı benzerlik metrikleri ve tek bir gömme modeli yönetişim noktası.

Paylaşılan Gömme Servisinin Mimarisi

Paylaşılan bir gömme servisi, gömmelere ihtiyaç duyan uygulamalar ile bunları üreten GPU altyapısı arasında yer alır. Temel tasarım üç katmana sahiptir: bir API ağ geçidi, bir hesaplama motoru ve bir gömme önbelleği.

API ağ geçidi, uygulamaların tükettiği kararlı bir arayüz sağlar. Metin (veya çok modlu modeller için görüntüler) kabul eder ve vektör gömmeleri döndürür. Ağ geçidi kimlik doğrulama, uygulama başına hız sınırlama, istek doğrulama ve uygun modele yönlendirme işlemlerini yönetir. Tekli öğe ve toplu gömme için uç noktaları olan basit bir REST veya gRPC API sunun. Toplu uç noktalar, dizinleme sırasında büyük belge koleksiyonlarını gömmesi gereken uygulamalar için kritiktir.

Hesaplama motoru, GPU donanımındaki gerçek gömme modellerini yönetir. Dinamik gruplama destekleyen bir sunum çerçevesi kullanın — Triton Inference Server, vLLM veya Text Embeddings Inference (TEI) gibi — farklı uygulamalardan gelen istekleri GPU-verimli gruplar halinde bir araya getiren. Dinamik gruplama, paylaşılan altyapıyı ekonomik yapan şeydir: her uygulamanın düşük kullanılan GPU belleğinin masrafını ödemesi yerine, paylaşılan servis uygulama sınırları boyunca grupları doldurur.

Gömme önbelleği, gereksiz hesaplamayı önlemek için daha önce hesaplanmış gömmeleri saklar. Birçok uygulama aynı içeriği gömmeye çalışır — bir şirketin ürün kataloğu arama ekibi, öneri ekibi ve analitik ekibi tarafından gömülebilir. Girdi metninin karma değeri ve model versiyonuna göre anahtarlanan bir önbellek, tekrarlanan istekleri bellekten sunarak GPU yükünü dramatik biçimde azaltabilir. Redis veya Memcached bu katman için iyi çalışır; TTL'ler kaynak içeriğin ne sıklıkla değiştiğine göre ayarlanır.

Model Sürümleme ve Geçiş

Paylaşılan gömme altyapısındaki operasyonel açıdan en zorlu tek konu model yükseltmeleridir. Bir gömme modelini yükselttiğinizde, yeni model eskisinden farklı bir uzayda vektörler üretir. Gömmeleri depolayan her alt akış uygulaması — her vektör veritabanı dizini, her önbelleğe alınmış benzerlik puanı, her önceden hesaplanmış küme ataması — bir gecede geçersiz hale gelir.

Bunu sürümlenmiş gömme ad alanı ile ele alın. Her gömme isteği ve yanıtı bir model sürüm tanımlayıcısı içerir. Uygulamalar gömmeleri sürüm etiketiyle birlikte depolar. Yeni bir gömme modeli dağıttığınızda, geçiş penceresi boyunca her iki sürümü aynı anda çalıştırın. Uygulamalar kendi hızlarında geçiş yapabilir: vektör depolarını yeni model sürümüyle yeniden dizinler, alma kalitesinin gereksinimlerini karşıladığını doğrular, ardından sorgularını yeni sürüme yönlendirir.

Her zaman en az bir önceki model sürümünü üretimde tutun. Bu sadece geçiş kolaylığı için değildir — geri dönüş yolunuzdur. Yeni gömme modeli yalnızca bir uygulamanın belirli kullanım durumunda ortaya çıkan ince bir kalite gerilemesi getirirse, o ekibin herkesi etkilemeden geri dönebilmesi gerekir.

Geçiş sinyalini otomatikleştirin. Yeni bir model sürümü dağıtıldığında, alt akış uygulamalarının tüketebileceği bir olay yayınlayın. Geçiş son tarihini, yeni modelin performans özelliklerini (boyutsallık, kıyaslama puanları, gecikme) ve geçiş kılavuzuna bir bağlantı ekleyin. Son tarihten önce geçiş yapmamış ekipler artan bildirimler alır.

Tutarlılık ve Kalite Garantileri

Paylaşılan altyapı, dağıtık dağıtımlarla imkansız olan bir tutarlılık garantisi oluşturur: paylaşılan servisi sorgulayan her uygulama, tam olarak aynı ön işleme ile tam olarak aynı modelden gömme alır. Bu göründüğünden daha önemlidir. Gömme modelleri girdi ön işlemeye duyarlıdır — farklı belirteçleme, farklı metin kısaltma uzunlukları veya farklı normalizasyon stratejileri farklı vektörler üretir. Her ekip kendi dağıtımını çalıştırdığında, bu ince farklılıklar uygulamalar arası benzerlik karşılaştırmalarını anlamsız kılar.

Ön işlemeyi istemci kütüphanelerinde değil, paylaşılan servisin kendisinde standartlaştırın. Servis metin temizleme, modelin bağlam penceresine kısaltma ve alana özgü ön işlemeleri (HTML ayıklama veya boşluk normalizasyonu gibi) ele almalıdır. İstemci uygulamalar ham metin gönderir; servis tutarlı gömmeler döndürür. Bu, bir ekibin gömmelerinin ön işleme farklılıkları nedeniyle diğerininkiyle uyumsuz olduğu bir hata sınıfını tamamen ortadan kaldırır.

Bilinen semantik benzerliğe sahip metin çiftleri olan bir çapa seti koruyarak ve bunların gömmelerini düzenli olarak üretim servisi üzerinden hesaplayarak sürekli kalite izlemesi uygulayın. Benzerlik puanları bir eşiğin ötesine kayarsa, izleme sistemi herhangi bir alt akış uygulaması bozulmayı fark etmeden önce uyarı vermelidir. Bu, ince yanlış hesaplamalar üreten GPU donanım arızaları gibi sorunları yakalar — nadir ama proaktif izleme olmadan tanılanması son derece zor bir arıza modu.

Çok Kiracılık ve Kaynak İzolasyonu

Farklı uygulamaların farklı gecikme gereksinimleri ve kullanım kalıpları vardır. Gerçek zamanlı bir arama uygulaması 50 milisaniyenin altında gömme üretimi isterken, bir gece toplu dizinleme işi istek başına saniyeleri tolere edebilir. Paylaşılan servis, toplu iş yükünün gerçek zamanlı tüketicileri aç bırakmasına izin vermeden her ikisini de ele almalıdır.

Gecikmeye duyarlı ve verimi duyarlı iş yükleri için ayrı işleme şeritleriyle öncelik kuyrukları uygulayın. Gerçek zamanlı istekler, ayrılmış GPU tahsisi ve katı gecikme SLO'ları olan yüksek öncelikli bir kuyruğa gider. Toplu istekler, kalan GPU kapasitesini kullanan düşük öncelikli bir kuyruğa gider. Gerçek zamanlı yük arttığında, toplu işleme otomatik olarak duraklar.

Tek bir tüketicinin servisi tekelleştirmesini önlemek için uygulama başına kotalar belirleyin. Kotalar hem istek oranını (saniyedeki istekler) hem de verimi (dakikadaki belirteçler) kapsamalıdır. Her uygulamanın kotasına karşı kullanımını, toplam servis kullanımını ve mevcut kapasite marjını gösteren bir kapasite panosu yayınlayın. Bu şeffaflık, ekiplerin kullanımlarını planlamalarına yardımcı olur ve kapasite planlama konuşmalarını politik değil veri odaklı hale getirir.

Katı veri izolasyonu gereksinimleri için — belirli departmanların başkalarıyla altyapı paylaşmaması gerektiğinde — gömme servisini ayrılmış GPU havuzlarıyla ayrı Kubernetes ad alanlarında dağıtın. Bu, sıkı izolasyon garantileri sağlama yeteneği için bir miktar verimlilikten ödün verir; bu, düzenlenmiş ortamlarda uyumluluk için gerekli olabilir.

Merkezileştirmenin Getirisini Ölçme

Platform yatırımını haklı çıkarmak ve kapasite kararlarını yönlendirmek için paylaşılan gömme altyapısının finansal ve operasyonel etkisini izleyin. Birincil maliyet metriği tasarruf edilen GPU saatleridir — merkezileştirmeden önce tüm uygulamalar arasındaki toplam GPU tahsisini, merkezileştirmeden sonra paylaşılan servisin tahsisiyle karşılaştırın. Pratikte, kuruluşlar merkezileştirmeden sonra toplam gömme GPU tüketiminde yüzde 40 ila 60 arasında bir azalma görür; bu dinamik gruplama verimliliği ve önbellekleme sayesindedir.

Operasyonel metrikler eşit derecede önemlidir. Üretimdeki gömme model sürümlerinin sayısını (hedef bir veya ikiye yakınsamadır), yeni bir gömme modelini tüm uygulamalara dağıtma süresini (geçiş araçları olgunlaştıkça azalmalıdır) ve çeyrek başına gömme ile ilgili olay sayısını izleyin.

Daha az somut ama genellikle daha değerli olan fayda, yeni kullanım durumlarını mümkün kılmasıdır. Gömme üretimi tam bir dağıtım projesi yerine basit bir API çağrısı olduğunda, ekipler daha özgürce deneme yapar. Bir ürün yöneticisi öğle arası boyunca semantik arama özelliği prototipleyebilir. Bir veri bilimci, GPU erişimi pazarlığı yapmadan departmanlar arası belge benzerliğini karşılaştırabilir. Bu kolaylaştırmayı, gömme servisini tüketen uygulama sayısını zaman içinde izleyerek ölçün — artan tüketici sayısı, platformun değer sunduğunun en net sinyalidir.

Öne çıkan görsel: Sam, Unsplash.