Çok Modelli Ajan Hatlarında Gecikme Bütçesi Yönetimi

Çok Modelli Mimarilerde Gecikme Sorunu

Tek bir model çağrısının öngörülebilir gecikmesi vardır. Ölçersiniz, optimize edersiniz ve bir zaman aşımı belirlersiniz. Ancak modern yapay zeka ajan sistemleri nadiren tek bir çağrı yapar. Tipik bir ajan hattı, bir kullanıcı sorgusunu niyet sınıflandırıcısından geçirebilir, vektör veritabanından bağlam alabilir, dil modeliyle yanıt üretebilir, korkuluk modeliyle güvenlik kontrolü yapabilir ve yapılandırılmış çıkarma modeliyle çıktıyı biçimlendirebilir. Her adım gecikme ekler ve toplam, kullanıcıların veya alt sistemlerin tolere edebileceğini kolayca aşabilir.

Zorluk şirket içi ortamlarda daha da belirgindir. Bulut sağlayıcıları gecikme sorunlarına dinamik olarak daha fazla donanım atayabilir. Şirket içi ekipler sabit GPU havuzları, sabit ağ bant genişliği ve sabit bellekle çalışır. Beş model aynı çıkarım kümesini paylaştığında, bir hat aşamasındaki artış tüm sisteme zaman aşımları olarak yayılabilir.

Gecikme bütçesi yönetimi, toplam kabul edilebilir yanıt süresini hattın her bileşeninde açıkça tahsis edilmesi, izlenmesi ve uygulanması gereken sınırlı bir kaynak olarak ele alır.

Uçtan Uca Bütçenin Ayrıştırılması

Uçtan uca gecikme hedefini tanımlayarak başlayın. Bu, kullanıcı deneyimi gereksinimlerinden, SLA taahhütlerinden veya üst sistem zaman aşımlarından gelir — altyapının neyi başarabileceğinden değil. Müşteriye yönelik bir sohbet robotu 3 saniye içinde yanıt gerektirebilir. Dahili bir belge işleme hattı 30 saniyeyi tolere edebilir. İşlemsel bir sisteme gömülü bir onay iş akışı alt saniye yanıtlara ihtiyaç duyabilir.

Toplam bütçeye sahip olduğunuzda, hattaki her adımı numaralandırın ve her adıma bir gecikme tahsisi atayın. Yararlı bir buluşsal yöntem, gerçekçi yük altında her bileşenin P50 ve P99 gecikmesini ölçmek, ardından varyans için pay bırakarak orantılı maliyete göre tahsis yapmaktır. Beş aşamalı bir hat için 3 saniyelik toplam bütçede:

Niyet sınıflandırma (SLM, ~100M parametre): 80ms tahsis. Vektör arama (gömme + arama): 150ms tahsis. Yanıt üretimi (LLM, ~7B parametre): 2000ms tahsis. Güvenlik kontrolü (sınıflandırıcı): 120ms tahsis. Yapılandırılmış çıkarma (SLM): 150ms tahsis.

Bu, ağ ek yükü, kuyruk bekleme süreleri ve serileştirme için 500ms'lik tampon bırakır. Yük testi sırasında ölçülen gecikmeler tahsisleri aşarsa, hangi bileşenlerin optimizasyona ihtiyacı olduğu veya hangi bütçe bölünmelerinin ayarlanması gerektiği hakkında somut bir sinyaliniz olur.

Uygulama Mekanizmaları

Uygulama olmadan bütçe tahsisi anlamsızdır. Hat orkestratörü geçen süreyi takip etmeli ve bileşenler sınırlarına yaklaştığında uyarlanabilir kararlar almalıdır.

En basit mekanizma aşama bazlı zaman aşımlarıdır. Yanıt üretim modeli 2000ms bütçesini aşarsa, orkestratör çağrıyı keser ve kısmi bir sonuç döndürür veya önbelleğe alınmış bir yanıta geri döner. İstemci tarafı uygulaması, sunucunun gözlemleyemediği ağ gecikmesini hesaba kattığı için daha güvenilirdir.

Daha sofistike bir yaklaşım kalan bütçe yayılımıdır. Orkestratör, kalan gecikme bütçesini her isteğe meta veri olarak ekler. Her aşama kalan bütçeyi okur, kendi beklenen gecikmesini çıkarır ve azaltılmış bütçeyi aşağı akışa iletir. Bir aşama yetersiz kalan bütçeyle istek alırsa, daha hızlı bir yürütme yolu seçebilir.

Üretim modelleri için gecikmeyi max_tokens aracılığıyla kontrol edebilirsiniz. Token üretimi, dil modellerinde gecikme varyansının birincil kaynağıdır. max_tokens'ı sabit bir değer yerine kalan bütçeye göre ayarlamak, üretim aşamasının hattın karşılayabileceğinden daha fazla süre tüketmemesini sağlar.

Her hat aşamasında devre kesiciler uygulayın. Bir bileşenin P99 gecikmesi sürekli olarak bütçesini aşarsa, devre kesici açılır ve orkestratör istekleri alternatif bir yol üzerinden yönlendirir.

GPU Zamanlama ve Önceliklendirme

Şirket içi GPU kümeleri aynı anda birden fazla modele hizmet verir. Dikkatli zamanlama olmadan, uzun süren bir üretim istekleri grubu küçük sınıflandırıcı modellerin GPU zamanını tüketebilir ve aşağı akışa yayılan gecikme artışlarına neden olabilir.

Öncelik tabanlı zamanlama, gecikmeye duyarlı modellere daha yüksek öncelik atar. Niyet sınıflandırıcıları ve güvenlik kontrolleri — sıkı gecikme bütçelerine ve kısa yürütme sürelerine sahip olan — GPU kaynakları çekişme altındayken daha uzun süren üretim görevlerini öncelemelidir.

vLLM ve TensorRT-LLM tarafından desteklenen sürekli gruplama, istekleri katı gruplar halinde işlemek yerine aynı modele gelen istekleri serpiştirir. Bu, tek bir uzun isteğin gruptaki tüm diğerlerini geciktirdiği satır başı engellemeyi azaltır. Çok modelli hatlar için üretim modelinde sürekli gruplama genellikle mevcut en büyük gecikme iyileştirmesidir.

Gecikme kritik hat aşamalarına belirli GPU'ları ayırmayı düşünün. Niyet sınıflandırıcısı ile yanıt üretecisinin bir GPU'yu paylaşması öngörülemeyen çekişme yaratır. Sınıflandırıcıyı kendi GPU'sunda izole etmek, üretim modelinin ne yaptığından bağımsız olarak tutarlı 100ms altı performansı garanti eder.

Gecikme Bütçelerinin Ölçülmesi ve İzlenmesi

Her hat aşamasını yalnızca ortalamalarla değil, gecikme histogramlarıyla enstrümante edin. Ortalamalar, gerçek kullanıcıları etkileyen kuyruk gecikmesini gizler. Her aşama için bağımsız olarak ve uçtan uca hat için P50, P95 ve P99'u takip edin. Herhangi bir aşamanın P95'i tahsis edilen bütçeye yaklaştığında uyarı verin.

Yapılandırılmış günlükleme, orijinal bütçeyi, her aşamada tüketilen süreyi ve aşağı akışa iletilen kalan bütçeyi içermelidir. Bu, her istek için bir gecikme şelalesi oluşturur ve uçtan uca gecikme hedefleri aşıldığında hangi aşamanın sorumlu olduğunu belirlemeyi kolaylaştırır.

Bütçe kullanımını yüzde olarak görselleştiren gösterge panelleri oluşturun. P50'de bütçesinin %40'ını kullanan bir aşama sağlıklı bir marjinal alana sahiptir. P50'de %85'ini kullanan bir aşama risk altındadır. Bu kullanım metrikleri, ham gecikme sayılarından daha eyleme dönüştürülebilirdir.

Patlayıcı varışlar ve karışık sorgu karmaşıklığı dahil üretim trafik kalıplarını simüle eden yük testleri çalıştırın. Gerçekçi koşullar altında bütçe uygulamasını stres testi yapmak için daha yüksek işlem hacminde yeniden oynatılan üretim istek günlüklerini kullanın.

Ödünleşmeler ve Pratik Rehberlik

Gecikme bütçesi yönetimi karmaşıklık getirir. Ek meta veri yayılımı, aşama bazlı zaman aşımları ve uyarlanabilir yönlendirme, test edilmesi ve sürdürülmesi gereken kod yolları ekler. Soru, bu karmaşıklığın karşılığını verip vermediğidir.

İki veya üç aşamalı hatlar için basit aşama bazlı zaman aşımları ve max_tokens sınırları genellikle yeterlidir. Tüm hattı kafanızda çözümleyebildiğinizde tam bütçe yayılımının ek yükü haklı değildir.

Dört veya daha fazla aşamalı, kalan bütçeye dayalı dinamik yönlendirmeli veya farklı gecikme gereksinimlerine sahip birden fazla kullanım durumuna hizmet eden hatlar için bütçe yönetimi altyapısına yatırım hızla karşılığını verir. O olmadan, yük kalıpları değiştikçe bileşenler arasında yer değiştiren gecikme sorunlarını hata ayıklamak için artan miktarda zaman harcarsınız.

Ölçümle başlayın. Hattınızı enstrümante edin, temelleri belirleyin ve yük altında hangi aşamaların gecikmeye hakim olduğunu tespit edin. Ardından gözlemlenen davranışa göre bütçeleri tahsis edin ve en yüksek varyansa sahip aşamadan başlayarak uygulayın. Oradan ilerleyin.

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