Ortak GPU havuzunda kota ile istek önceliği farklı kararlar verir

Ortak GPU havuzu komşu işin boş kapasitesini kullanabilir; bunun için iş kabulü, yerleştirme ve istek sıralaması ayrılmalıdır. Aksi halde etkileşimli ürün gece işlemleriyle tek kuyrukta yarışır, ekip planlama sorununu gidermek için donanım rezervi satın alır.

Red Hat'ın 20 Ekim yazısı, AI 3.5'te llm-d ile öncelikli serving'i anlatıyor. Kubernetes'in 14 Ekim incelemesi Kueue kabulünü Headlamp üzerinden izliyor; ilgili eklenti alpha ve eklediği görünümler salt okunur. Ai2'nin 9 Ekim yazısı GPU zamanı bütçelerini ve hiyerarşik adil paylaşımı açıklıyor. NVIDIA'nın 15 Ekim yayını GB300 üzerinde Muse Spark Open ile prefill/decode ayrımını ele alıyor. Bunlar doğrulanmış bütünleşik ürün değil, farklı katmanlardır.

Beklemek üç ayrı anlama gelebilir

İş, Pod oluşmadan kota kabulünü bekleyebilir. Kabul edilmiş iş uygun düğümü bekleyebilir. Çalışan model sunucusu ise diğer kullanıcıların yükü nedeniyle tek bir isteği geciktirebilir. Her durumda düğüm eklemek doğru çözüm değildir.

Kaynaklar kıtlığı farklı yerde görünür kılıyor. Kueue kabul sınırını, Ai2 zaman tahsisinin ekonomik anlamını, serving sıralaması mevcut çıkarım kapasitesinin kullanıcılar arasındaki dağılımını ele alıyor. Donanım ve yürütme mimarisi de gerçek verimi belirliyor.

Katmanlar uyumluysa gece işleri boş kapasiteyi kullanırken gündüz arayüzü öncelik alır. Her yük sınıfı için ayrı tam tepe rezervi gerekmeyebilir. Ancak uzun süren etkileşimli talep geceye kayarsa toplu işin beklenen boşluğu bulamayacağı teslim vaadine yansıtılmalıdır.

Burada ürün fırsatı da var: aynı altyapı üzerinde farklı hizmet sınıfları sunulabilir. Fiyat veya iç tahsis, verilen sözü yansıtabilir. Ölçüm kullanıcının yaşadığı sınırda yapılmalıdır. Yüksek toplam GPU doluluğu bütün ürünlerin sağlıklı olduğunu göstermez.

Öncelik gecikmeyi başkasına taşır

Yüksek öncelik kıt olduğunda anlamlıdır. Her ekip her isteği acil ilan ederse hiyerarşi seçim ifade etmez. Zaman bütçesi ve anlaşılmış hizmet sınıfı, kimin kapasite alacağını ve diğer işlerin neye katlanacağını açıklaştırır.

Sıkı yalıtım, kesilemeyen uzun işler veya farklı model ayarı için özel havuz mantıklı kalır. Bedeli başkasına verilemeyen boş rezervdir. Ortak havuz rezervi azaltabilir; işlerin kuyruk beklemesine ve operatörlerin adaleti yönetmesine ihtiyaç duyar.

Prefill ve decode donanımdan farklı şeyler ister. Uzun girdiyi işlemekle sırayla token üretmek aynı kaynak profiline bağlı olmak zorunda değildir. Ayırmak uzmanlaşmış kaynakların kullanımını artırabilir; durum aktarımı, yönlendirme ve işletim karmaşıklığı ekler. Kendi istek karışımı ölçülmeden üreticinin tepe hız grafiğinden sonuç çıkarılmamalıdır.

İş hesabı gecikmenin bedelini de kapsamalıdır. Toplu iş operasyon süresini kaçırıyorsa düşük altyapı faturası cazip olmayabilir. Düşük değerli rapor için tamamen boş rezerv tutmak da gereksiz olabilir. Seçim yükün değeri ve esnekliğine bağlıdır.

Varsayımsal ürün: gündüz sohbet, gece belgeler

Bu tasarım örneğinde etkileşimli yardımcının sınırlı yüksek öncelik sınıfı vardır. Arşiv belgeleri kalan kapasitede, anlaşılmış son tarihle işlenir. Kabul beklemesi, yerleşme süresi ve ilk token süresi ayrı ölçülür.

Sohbet yavaşken toplu işler henüz kabul edilmediyse rekabetin kaynağı onlar olmayabilir. Kabul edilen işler yerleşemiyorsa düğüm sınırları incelenir. Kuyruk çalışan model servisinin içindeyse Kueue kotasını değiştirmek kullanıcı yanıtını düzeltmeyebilir. Bu ayrım yatırımın gerçek darboğaza gitmesini sağlar.

Kısa ve bağımsız tepeler paylaşım fırsatı yaratır. Sürekli doygun yük az ödünç kapasite bırakır. GPU satın almadan önce talebi zamana göre çıkarın, toplu işin ne kadar kaydırılabileceğini değerlendirin. Bazen takvimi veya hizmet sınıfını değiştirmek hızlandırıcı sayısını ikiye katlamaktan değerlidir.

Arka plan işleri rehberi uygulama kuyruğunu açıklar. Google Cloud'da Debian vakası işletim bağlamını sunar. Altyapıyı konuşurken yük sınıfı ve sonuç süresinden başlayabiliriz; donanım seçimi bunları izler.