NVIDIA Dynamo: Çıkarım Motorlarının Etrafındaki Dağıtık Servis Katmanı

Video, Ron adında bir platform mühendisinin hikâyesiyle açılıyor: ekibi, modelleri zaten üretimde koşan bir yapay zekâ uygulamasını işletiyor ve çıkarım motorları sorunsuz yanıt veriyor. Bu noktada sorulan soru da haklı: motor işini yapıyorsa Dynamo hangi derde deva olacak?

Yanıt, Dynamo'nun konumunda gizli: NVIDIA'nın açık kaynak çerçevesi bir çıkarım motoru değil, motorların etrafına yerleşen dağıtık bir servis katmanı. SGLang, TensorRT-LLM veya vLLM jeton üretmeye devam ederken Dynamo istekleri yönlendiriyor, çalışanları eşgüdümlüyor, gereksiz işi eliyor ve çok GPU'lu kurulumun parçalarını tek mimaride topluyor.

Küçük kurulumlarda bu katmana gerek yok: istemci isteği gönderir, sunucu ön-doldurma ve kod-çözmeyi koşar, yanıt döner. Ama kullanıcı sayısı, istem uzunluğu ve model çeşitliliği büyüyüp gecikme hedefleri sıkılaşınca asıl dertler modelin ötesine taşınıyor; pahalı GPU kapasitesinde kimin, nereye, nasıl koşacağı sorusu öne çıkıyor.

Katmanın ilk işi, ön-doldurma ile kod-çözmeyi ayrı çalışan havuzlarında eşgüdümlemek. Ön-doldurma girdi istemini işleyip KV önbelleğini oluşturuyor, kod-çözme ise bu önbelleği kullanarak çıktı jetonlarını üretiyor. İki evrenin kaynak ihtiyacı farklı olduğu için iş yükü büyüyünce bunları ayrı havuzlarda koşmak verimi artırıyor.

İkinci iş, boşa giden işi kısmak: her isteği yalıtık sayan bir yığın, paylaşılan istem ön-eklerini sil baştan hesaplıyor, KV önbelleğini tekrar kullanma fırsatını kaçırıyor ve pahalı GPU'ları atıl bırakıyor. Dynamo, ortak işi bir kez yapıp sonucu paylaşarak bu israfı kapatmayı hedefliyor.

Üçüncü ve dördüncü işler, yönlendirme ile hata dayanımı. Çalışan sayısı birden fazlaya çıkınca istekleri dağıtmak kapasiteyi, çalışan durumunu ve modelin nerede durduğunu bilen bir akla ihtiyaç duyuyor. Üretimde çalışanlar çöküp düğümler yeniden başlayınca da servis katmanı sağlığı izleyip trafiği arızalı parçanın etrafından dolaştırıyor.

Beşinci iş, parçaları tek mimaride birleştirmek: istemciler, yönlendirme mantığı, motor koşan çalışanlar, planlayıcılar, kontrol düzlemi ve Kubernetes işleçleri özel yapıştırıcı kodlar yerine ortak bir çerçeveye oturuyor. Parçalar modüler olduğu için ekip hepsini birden almak zorunda değil; önyüzden, motordan ya da yönlendirmeden başlayıp büyüdükçe ekleyebiliyor.

Zamanlamanın sebebi de net: modeller büyüyor, uzmanlar-karışımı mimariler yaygınlaşıyor ve GB200 NVL72 gibi raf-ölçeği tasarımlar tek GPU'nun azami hızı sorusunu eskiritiyor. Yeni soru, çok GPU'lu kümenin verimli ölçeklenip güvenilir toparlanacağı, işi tekrar kullanacağı ve büyürken anlaşılır kalacağı; Dynamo 1.0 da Blackwell donanımında 7 kata varan işlem hacmi iddiasıyla bu soruya yanıt arıyor.