NVIDIA NeMo AutoModel przyspiesza dostrajanie modeli MoE: 3,7x wyższa przepustowość przy mniejszym zużyciu pamięci GPU
W skrócie
- NVIDIA NeMo AutoModel, zbudowany na bazie Transformers v5, osiąga 3,4–3,7x wyższą przepustowość trenowania i zużywa o 29–32% mniej pamięci GPU przy dostrajaniu modeli Mixture-of-Experts w porównaniu z natywnym Transformers v5.
- Biblioteka wymaga zmiany tylko jednej linii kodu (importu) i jest w pełni zgodna z API Hugging Face, a zapisane punkty kontrolne działają ze standardowymi narzędziami jak vLLM i SGLang.
- Kluczowe optymalizacje to Expert Parallelism, DeepEP — mechanizm nakładający komunikację na obliczenia eksperckie — oraz jądra TransformerEngine, niedostępne w samym Transformers v5.
Tło: rosnące wyzwania architektur MoE
Architektura Mixture-of-Experts (MoE) stała się dominującym podejściem w modelach granicznych. Jej popularność niesie jednak poważne wyzwania inżynieryjne: kierowanie tokenów do setek ekspertów, łączenie operacji macierzowych w pojedyncze jądra obliczeniowe, dzielenie wag między GPU oraz nakładanie komunikacji na obliczenia — to wszystko wymaga infrastruktury wykraczającej poza możliwości biblioteki ogólnego przeznaczenia huggingface.co.
Odpowiedzią Hugging Face było wydanie Transformers v5, które wprowadza natywne wsparcie dla MoE: mechanizm tzw. expert backends, dynamiczne ładowanie wag oraz plany równoległości tensorowej dla rozproszonego wykonania. Wersja v5 integruje też bezpośrednio PyTorch DeviceMesh z metodą from_pretrained(), czyniąc trening rozproszony elementem pierwszej klasy biblioteki huggingface.co.
NeMo AutoModel: ta sama składnia, znacznie lepsza wydajność
NVIDIA NeMo AutoModel to otwarta biblioteka będąca częścią frameworka NVIDIA NeMo, przeznaczona do budowania własnych generatywnych modeli AI na dużą skalę. Buduje ona na fundamencie Transformers v5, rozszerzając go o trzy kluczowe elementy niedostępne w samym v5 huggingface.co:
- Expert Parallelism (EP) — równoległe przetwarzanie przez wielu ekspertów na wielu GPU,
- DeepEP — mechanizm nakładający komunikację na obliczenia eksperckie (fused all-to-all dispatch),
- jądra TransformerEngine — zoptymalizowane operacje uwagi i warstw liniowych.
Dzięki temu, że NeMo AutoModel korzysta z odwracalnej konwersji wag z v5, może skupić wysiłek inżynieryjny na tych wielokrotnie używanych operacjach zamiast na obsłudze poszczególnych formatów punktów kontrolnych. Co istotne, metoda save_pretrained() nadal generuje standardowe punkty kontrolne Hugging Face, kompatybilne z narzędziami takimi jak vLLM i SGLang huggingface.co.
Kluczową zaletą z perspektywy programisty jest minimalna zmiana kodu — wystarczy podmienić jeden import:
# Zamiast:
from transformers import AutoModelForCausalLM
# Wystarczy:
from nemo_automodel import NeMoAutoModelForCausalLM
Reszta kodu pozostaje bez zmian. NeMoAutoModelForCausalLM jest podklasą AutoModelForCausalLM, więc każdy kod działający z modelami Hugging Face działa też z NeMo AutoModel huggingface.co.
Wyniki wydajnościowe
Zmierzone zyski są znaczące. W porównaniu z natywnym Transformers v5, NeMo AutoModel osiąga huggingface.co:
- 3,4–3,7x wyższą przepustowość trenowania przy dostrajaniu modeli MoE,
- 29–32% mniejsze zużycie pamięci GPU.
Testy obejmowały szeroki zakres modeli — od pełnego dostrajania NVIDIA Nemotron 3 Ultra 550B A55B rozłożonego na 16 węzłów, po modele na pojedynczym węźle, takie jak Qwen3-30B-A3B i Nemotron 3 Nano 30B A3B huggingface.co.
Dla popularnych architektur MoE — Qwen3, NVIDIA Nemotron, GPT-OSS i DeepSeek V3 — NeMo AutoModel dostarcza ręcznie dostrojone implementacje z uwagą TransformerEngine, scalonymi warstwami liniowymi i niestandardowymi jądrami eksperckimi. Dla pozostałych modeli biblioteka wraca do standardowej implementacji Hugging Face, nadal stosując optymalizacje takie jak łatanie jądrem Liger huggingface.co.
Jak działa skalowanie do wielu GPU
Aby uruchomić trening modelu Nemotron 3 Nano 30B A3B z Expert Parallelism na 8 GPU, wystarczy dodać konfigurację siatki rozproszonej. Biblioteka obsługuje strategię FSDP2 z konfigurowalnym rozmiarem równoległości eksperckiej (ep_size). Niezależnie od wybranej ścieżki optymalizacji, model jest gotowy do skalowania — przekazanie device_mesh uruchamia trening wieloGPU bez dalszych modyfikacji kodu huggingface.co.
Źródło przyspieszenia
Głównym elementem odróżniającym NeMo AutoModel od samego Transformers v5 jest DeepEP — mechanizm, którego v5 jeszcze nie posiada. Nakłada on komunikację między GPU na obliczenia eksperckie, eliminując przestoje wynikające z przesyłania danych. W połączeniu z jądrami TransformerEngine i Expert Parallelism daje to skumulowany efekt widoczny w wynikach benchmarków huggingface.co.
Co to oznacza
Dla zespołów pracujących z dużymi modelami językowymi opartymi na architekturze MoE, NeMo AutoModel oznacza możliwość znaczącego skrócenia czasu i kosztów dostrajania bez konieczności przepisywania istniejącego kodu. Redukcja zużycia pamięci GPU o 29–32% to w praktyce możliwość trenowania większych modeli na tym samym sprzęcie lub obniżenie kosztów infrastruktury chmurowej.
Ważny jest też aspekt ekosystemowy: biblioteka zachowuje pełną kompatybilność z formatem punktów kontrolnych Hugging Face, co oznacza, że modele dostrojone za pomocą NeMo AutoModel można bezpośrednio wdrażać przy użyciu popularnych silników wnioskowania, takich jak vLLM czy SGLang. Nie ma więc ryzyka uzależnienia od zamkniętego formatu.
Dla polskich firm i instytucji badawczych eksperymentujących z dostrajaniem modeli MoE — czy to na własnej infrastrukturze GPU, czy w chmurze — NeMo AutoModel obniża barierę wejścia. Dotychczas osiągnięcie podobnej wydajności wymagało głębokiej wiedzy o optymalizacji rozproszonych systemów. Teraz wystarczy zmiana jednej linii importu, by skorzystać z optymalizacji opracowanych przez inżynierów NVIDIA.
Warto obserwować dalszy rozwój Transformers v5 — część funkcji NeMo AutoModel, jak DeepEP, może z czasem trafić do głównej biblioteki, co jeszcze bardziej obniży próg dostępu do wydajnego trenowania modeli MoE dla całej społeczności open-source.
Szerszy kontekst
NVIDIA NeMo AutoModel osiąga 3,4–3,7x wyższą przepustowość trenowania i redukuje zużycie pamięci GPU o 29–32%. Biblioteka umożliwia pełne uruchomienie modelu Nemotron 3 Ultra 550B na 128 GPU H100. Dane pokazują, że ta optymalizacja umożliwia pełne dostrajanie wcześniej ograniczone przez limity pamięci. Wymagana jest tylko jedna zmiana w linii importu.
W systemie jednowęzłowym z 8 GPU H100 80GB, na przykładzie Qwen3-30B-A3B, NeMo AutoModel zwiększył TPS/GPU (przepustowość na GPU na sekundę) z 3 075 do 11 340, osiągając poprawę o 3,69x.
NeMo AutoModel buduje w sposób przejrzysty na bazie v5, dodając Expert Parallelism, scalony mechanizm DeepEP all-to-all dispatch oraz jądra TransformerEngine, i opiera się na dynamicznym ładowaniu wag v5, aby dostarczyć te optymalizacje do szerokiego i rosnącego zestawu rodzin modeli. Efektem jest 3,4–3,7x wyższa przepustowość trenowania i 29–32% mniejsze zużycie pamięci GPU przy dostrajaniu modeli MoE w porównaniu z natywnym Transformers v5, przy użyciu tego samego API from_pretrained(): jedna linia importu, bez żadnych innych zmian w kodzie.
Klaster 16 węzłów ze 128 GPU H100 przeprowadził pełne dostrajanie modelu Nemotron 3 Ultra 550B A55B. Bazowe uruchomienie Transformers v5 napotkało błędy braku pamięci. AutoModel ukończył to samo zadanie przy EP ustawionym na 64.
Analiza
Najważniejszym wnioskiem płynącym z tego ogłoszenia jest to, że NVIDIA skutecznie obniżyła barierę dostępu do wydajnego dostrajania modeli MoE, nie wymagając od programistów żadnej wiedzy o optymalizacji systemów rozproszonych. Zmiana jednej linii importu przekłada się na wzrost przepustowości trenowania z 3 075 do 11 340 tokenów na GPU na sekundę w przypadku modelu Qwen3-30B-A3B na węźle z 8 kartami H100 — czyli wzrost o 3,69x (wg kucoin.com). Co równie istotne, redukcja zużycia pamięci GPU o 29–32% nie jest jedynie oszczędnością kosztową, lecz w przypadku modelu Nemotron 3 Ultra 550B A55B stanowi warunek konieczny do uruchomienia treningu w ogóle — natywny Transformers v5 na konfiguracji 128 kart H100 po prostu kończy się błędem braku pamięci, podczas gdy NeMo AutoModel z równoległością ekspercką EP=64 realizuje to zadanie bez problemów (wg remio.ai).
Kluczem technicznym jest mechanizm DeepEP, który nakłada komunikację między GPU na obliczenia eksperckie, eliminując przestoje wynikające z przesyłania tokenów między ekspertami. W połączeniu ze scalonymi operacjami macierzowymi (grouped GEMM) i jądrami TransformerEngine, DeepEP zredukował koszt pojedynczej iteracji o 47% na modelu DeepSeek V3 671B w porównaniu z podejściem opartym na all-gather i pętlowym przetwarzaniu ekspertów (wg huggingface.co). Dla modelu Nemotron-3-Nano-30B-A3B z około 55 GiB wag eksperckich, równoległość ekspercka EP=8 zmniejsza ślad pamięciowy przypadający na jeden GPU z około 55 GiB do około 6,8 GiB — co zmienia jakościowo możliwości sprzętowe wymagane do treningu (wg huggingface.co).
Z perspektywy ekosystemu istotne jest, że NVIDIA nie zamknęła tych optymalizacji w zastrzeżonym formacie. Metoda save_pretrained() nadal generuje standardowe punkty kontrolne Hugging Face kompatybilne z silnikami wnioskowania takimi jak vLLM i SGLang, a sama biblioteka jest otwarta. Warto obserwować, czy mechanizmy takie jak DeepEP trafią z czasem do głównej gałęzi Transformers v5 — jeśli tak się stanie, obecna przewaga NeMo AutoModel stanie się standardem całego ekosystemu open-source, co jeszcze bardziej przyspieszy demokratyzację trenowania dużych modeli MoE.
Powiązane newsy
Następny przełom w AI: modele uczące się w trakcie pracy, nie tylko podczas treningu1 lipca 2026
GLM-5.2: chiński model open-source z kontekstem 1M tokenów rzuca wyzwanie Claude'owi Opus30 czerwca 2026
Hugging Face wdraża ARD – standard wyszukiwania narzędzi i agentów AI w czasie rzeczywistym30 czerwca 2026
OpenAI prezentuje GPT-5.6 Sol – najbardziej zaawansowany model AI do cyberbezpieczeństwa z ograniczonym dostępem30 czerwca 2026