Gerçek Zamanlı Yerel AI için Akış Çıkarım Mimarisi

Akış Neden Yerel AI için Önemlidir

AI sistemleriyle etkileşen kullanıcılar, saniyeler değil milisaniyelerle ölçülen yanıt hızı bekler. 500 tokenlik bir yanıt üreten büyük bir dil modeli tamamlanması için 8-12 saniye sürebilir, ancak ilk tokeni 200ms içinde akıtmak sinir bozucu bir bekleyişi akıcı bir konuşma deneyimine dönüştürür. Bulut AI sağlayıcıları bu deseni öncülük etti ve kullanıcılar artık yerel dağıtımlardan da aynı yanıt hızını bekliyor.

Yerel ortamda akış çıkarımı oluşturmak, yönetilen bulut hizmetlerinin soyutladığı zorlukları beraberinde getirir: WebSocket bağlantılarını ölçekte yönetmek, istemciler modelin ürettiğinden daha yavaş token tükettiğinde geri basınç uygulamak, kısmi yanıt önbelleklemesini ele almak ve yukarı akış modellerinin aşağı akış modelleri için artımlı olarak giriş ürettiği çoklu model hatlarında akışı koordine etmek. Bu kılavuz, kendi altyapınızda güvenilir akış çıkarımını mümkün kılan mimari desenleri kapsar.

Token Akışı Temelleri: GPU'dan İstemciye

Otoregresif dil modelleri tokenleri sıralı olarak üretir; her biri önceki tüm tokenlere bağımlıdır. Bu sıralı doğa aslında akış için bir avantajdır: tam yanıtı beklemeden her tokeni üretildikten hemen sonra iletebilirsiniz. Mimari zorluğu, GPU belleğinden istemciye minimum tamponlama gecikmesiyle verimli bir yol inşa etmektir.

Temel akış yolu şunlardan oluşur: çıkarım motorunun token geri çağrımı, bir olay serileştirme katmanı, bir taşıma protokolü ve istemci tarafı yeniden oluşturma. Her katman potansiyel gecikme ekler ve minimum ek yük için tasarlanmalıdır.

Çıkarım motoru entegrasyonu: vLLM, TensorRT-LLM ve text-generation-inference (TGI) gibi çerçeveler akış geri çağrımlarını destekler. Çıkarım motorunuzu, üretim tamamlanana kadar tamponlamak yerine her token çözme adımından sonra bir geri çağrım çalıştıracak şekilde yapılandırın. vLLM ile bu, KV önbelleğinden çözüldükçe bireysel token kimliklerini veren asenkron akış arayüzünü kullanmak anlamına gelir.

Olay serileştirmesi: HTTP tabanlı akış için Server-Sent Events (SSE) veya çift yönlü iletişim için WebSocket çerçeveleri kullanın. SSE daha basittir ve özel yapılandırma olmadan standart HTTP altyapısı (yük dengeleyiciler, proxy'ler) üzerinden çalışır. İstemciden sunucuya akışa (ses girişi, gerçek zamanlı düzeltmeler) veya ikili yük verimliliğine ihtiyacınız olduğunda WebSocket'i seçin.

Bağlantı Yönetimi ve Geri Basınç

Akış bağlantıları uzun ömürlüdür ve altyapınızın bağlantı ekonomisini temelden değiştirir. Akış yapmayan bir çıkarım uç noktası, bir isteği tek bağlantı yaşam döngüsünde işler. Akış uç noktası ise tüm üretim süresi boyunca bağlantıları açık tutar; uzun yanıtlar için bu 30-60 saniye olabilir. Bu, bağlantı kapasitenizin yalnızca saniye başına istekler için değil, eşzamanlı aktif üretimler için boyutlandırılması gerektiği anlamına gelir.

Ağ geçidi katmanında istemci başına ve genel olarak açık sınırlarla bağlantı havuzlaması uygulayın. Bağlantı sınırlarına ulaşıldığında, yeni istekleri doğrudan reddetmek yerine kuyruğa alın ve ilk bağlantı yanıtı aracılığıyla tahmini bekleme süreleri sağlayın.

Geri basınç yönetimi, istemcilerin modelin ürettiği kadar hızlı token tüketemedikleri durumlarda kritiktir. Bu, yavaş ağlardaki mobil istemcilerde, odak kaybeden tarayıcı sekmelerinde (JavaScript yürütme önceliğini düşürür) veya tokenleri tamponlayan ve işleyen aşağı akış hizmetlerinde meydana gelir. Geri basınç olmadan, sunucu tamponlarınız sınırsız büyür ve sonunda tüm bağlantılarda bellek baskısına neden olur.

Yapılandırılabilir yüksek su işaretine sahip bağlantı başına çıkış tamponu uygulayın. Tampon bu işareti aştığında, çıkarım motoruna o belirli istek için üretimi duraklatma sinyali verin. vLLM'nin sürekli toplu işlemesiyle, bir isteği duraklatmak aynı toplu işlemdeki diğerlerini engellemez; zamanlayıcı tampon boşalana kadar o dizinin çözme adımını atlar. Bu işbirlikçi geri basınç, bir yavaş istemcinin diğer eşzamanlı istekler için hizmeti bozamamasını sağlar.

Çoklu Model Hatları Üzerinden Akış

Gerçek dünya AI uygulamaları nadiren tek bir model içerir. Tipik bir hat bağlam alabilir, yanıt üretebilir, korumalar uygulayabilir ve çıktıyı biçimlendirebilir. Zorluk, bir sonrakinin başlamasından önce her aşamanın tamamlanmasını beklemeden bu zincir boyunca akış semantiklerini korumaktır.

Her aşamanın tokenleri artımlı olarak işlediği hat akışı uygulayın:

Alma aşaması üretimden önce tamamlanır (token değil bağlam üretir), bu nedenle ilk token süresine gecikme katkısı yapar ancak üretim başladığında akışı etkilemez. Bu başlangıç gecikmesini en aza indirmek için almayı agresif şekilde optimize edin: gömmeleri önceden hesaplayın, sık sorguları önbelleğe alın ve sıkı gecikme sınırlarıyla yaklaşık en yakın komşu araması kullanın.

Koruma modelleri kayan pencere yaklaşımı kullanarak kısmi çıktı üzerinde çalışabilir. Yapılandırılabilir sayıda token (genellikle 10-20) tamponlayın ve her pencere üzerinde sınıflandırma çalıştırın. Bir pencere güvenlik filtresini tetiklerse, akışı derhal sonlandırın ve bir değiştirme yanıtı gönderin. Bu, gerçek zamanlı içerik filtrelemesi sağlarken minimum gecikme (bir pencerelik tamponlama) ekler.

Yanıt biçimlendirmesi (markdown oluşturma, alıntı enjeksiyonu, yapılandırılmış çıktı) akış dönüşümü olarak çalışır. Bireysel tokenleri tüketen ve biçimlendirilmiş çıktı tokenleri yayan durum makineleri olarak biçimlendiriciler uygulayın. Yapılandırılmış çıktı (JSON modu) için, ayrı bir biçimlendirme aşaması ihtiyacını tamamen ortadan kaldıran son işleme yerine çıkarım motoru düzeyinde kısıtlı çözme kullanın.

Kısmi Yanıt Önbellekleme ve Kurtarma

Akış bağlantıları ağ kesintileri, istemci bağlantı kopmaları veya yuvarlanan güncellemeler sırasında sunucu yeniden başlatmaları nedeniyle üretim ortasında başarısız olur. Kurtarma mekanizması olmadan, istemciler kısmen alınan yanıtları kaybeder ve zaten yatırılan GPU hesaplamasını boşa harcayarak üretimi sıfırdan yeniden başlatmak zorunda kalır.

Bir akış kontrol noktası sistemi uygulayın: üretim durumunu (KV önbelleği, şimdiye kadar üretilen tokenler, örnekleme durumu) periyodik olarak hızlı depolamaya kaydedin. Her anlık görüntüyü, istemcinin bağlantı kurulumunda aldığı bir akış kimliğiyle etiketleyin. İstemci bir akış kimliğiyle yeniden bağlandığında, sıfırdan başlamak yerine en yakın kontrol noktasından üretimi sürdürün.

Tam kontrol noktası ek yükünün aşırı olduğu daha kısa yanıtlar için yanıt tekrarı uygulayın: istek hash'ine göre anahtarlanmış, yakın zamanda tamamlanan veya devam eden yanıtların kısa ömürlü bir önbelleğini tutun. Yeniden bağlantıda, şimdiye kadar üretilen tüm tokenleri hemen tekrarlayın, ardından canlı akışa devam edin. İstemci, önbelleğe alınmış tokenlerin kısa bir patlamasını ve ardından canlı üretimi görür; bu sorunsuz bir kurtarma deneyimi yaratır.

Yuvarlanan dağıtımlar sırasında bağlantı boşaltma uygulayın: kapatma için işaretlenen düğümlerde yeni akış bağlantılarını kabul etmeyi durdurun, ancak mevcut akışların bir hoşgörü süresi içinde tamamlanmasına izin verin. Üretim hoşgörü süresi içinde tamamlanamazsa, istemcinin yeni bir düğümde devam edebilmesi için bir kontrol noktası tetikleyin.

Performans Optimizasyonu: İlk Token Süresini Azaltma

İlk token süresi (TTFT), akış çıkarımı için birincil gecikme metriğidir. Kullanıcılar, toplam üretim süresinden bağımsız olarak TTFT'yi sistemin yanıt hızı olarak algılar. TTFT'yi optimize etmek, üretim öncesi yoldaki her bileşene dikkat gerektirir.

İstem önbellekleme: İstemlerin ortak önekler paylaştığı uygulamalar (sistem istemleri, az örnekli örnekler) için istekler arasında KV önbellek paylaşımı uygulayın. vLLM'nin otomatik önek önbeleklemesi, ortak önekler için hesaplanmış dikkat durumlarını depolar ve gereksiz ön doldurma hesaplamasını ortadan kaldırır. 2000 tokenlik bir sistem istemi için bu, aynı öneke sahip sonraki isteklerde TTFT'yi 800ms'den 100ms'nin altına düşürebilir.

Model ısınması: Boşta kalma süresinden sonraki ilk gerçek istekte GPU saat ölçeklemesinin performansı düşürmesini önlemek için modelleri periyodik sahte çıkarımla GPU belleğinde yüklü tutun. NVIDIA GPU'lar boşta kalma sırasında saat hızlarını agresif şekilde düşürür ve geri yükselme ilk isteğe ölçülebilir gecikme ekler.

Spekülatif ön doldurma: Öngörülebilir istem desenlerine sahip uygulamalar için, kullanıcı tam istemi göndermeden yazmaya başladığında spekülatif olarak ön doldurma hesaplamasına başlayın. Spekülatif KV önbelleğini akıtın ve gönderimde gerçek isteme karşı doğrulayın. Spekülasyon doğru olduğunda (sabit sistem istemlerine sahip sohbet uygulamaları için yaygın), TTFT sıfıra yaklaşır.

TTFT'yi p50, p95 ve p99 seviyelerinde izleyin. Sağlıklı bir akış çıkarım sistemi, çoğu kurumsal iş yükü için p95 TTFT'yi 500ms'nin altında tutar. p99 2 saniyeyi aşarsa, kuyruk gecikmelerinin, GPU çekişmesinin veya soğuk başlatma olaylarının sorumlu olup olmadığını araştırın.

Öne çıkan görsel: Adrien tarafından Unsplash'ta paylaşılmıştır.