NVIDIA Nemotron 3.5 Lightning to „koń roboczy” dla agentów AI

Liczby „30B” i „3B aktywnych parametrów” oznaczają dwie różne rzeczy:

• 30B parametrów łącznie — pełny zbiór wyuczonych parametrów modelu;
• około 3B parametrów aktywnych — przybliżona część sieci używana przy generowaniu każdego tokena.

Takie rzadkie, czyli selektywne, wykonywanie obliczeń może ograniczyć koszt generowania pojedynczego tokena. Nie oznacza to jednak, że można całkowicie pominąć przechowywanie lub zarządzanie pełnym modelem.

Model do wykonywania zadań, nie do wszystkiego

Autonomiczny agent często wykonuje wiele wywołań modelu w ramach jednego zadania. Po utworzeniu planu może wielokrotnie korzystać z narzędzi, analizować fragmenty danych, weryfikować wyniki i zwracać odpowiedzi w określonym formacie.

Wysyłanie każdej z tych próśb do największego modelu zwiększa opóźnienia i koszty. Lightning ma przejąć przewidywalną, wysokoczęstotliwościową część pracy, a większy model pozostać dostępny dla niejednoznacznych przypadków i decyzji wymagających głębszego rozumowania.

Przykładowy podział ról wygląda następująco:

1. Większy model interpretuje cel i przygotowuje plan.
2. Lightning wykonuje rutynowe kroki na narzędziach, dokumentach lub danych strukturalnych.
3. Większy model wraca do pracy, gdy pojawia się wyjątek, niepewność albo decyzja wymagająca bardziej zaawansowanego rozumowania.

NVIDIA przedstawia Nemotron 3 Ultra — model MoE z 550 mld parametrów łącznie i 55 mld aktywnych — jako rozwiązanie do rozumowania na najwyższym poziomie i orkiestracji. Kontrast z Lightningiem jest więc zamierzony: Ultra ma planować i koordynować, a Lightning realizować dużą liczbę konkretnych kroków.

Rola NeMo Switchyard

Taki układ wymaga routingu, czyli mechanizmu decydującego, który model powinien obsłużyć dany etap. Agent nie powinien wysyłać wszystkich próśb do tego samego punktu końcowego.

NeMo Switchyard to niezależny od dostawcy SDK do routingu. Pozwala opisywać żądania, definiować dostępne cele modeli i zarządzać połączeniami z wybranym dostawcą lub identyfikatorem modelu. W praktyce umożliwia zbudowanie hierarchii, w której Lightning obsługuje rutynowe operacje, a większy model otrzymuje przypadki trudniejsze lub bardziej niepewne.

To ważny punkt z perspektywy produktu: Lightning nie jest najbardziej interesujący jako samodzielny chatbot. Jego mocniejszą pozycją jest rola jednego z elementów routowanego, wielomodelowego systemu agentowego.

Kontekst i wdrażanie

Lightning ma deklarowaną pojemność kontekstu do 1 mln tokenów. Może to być przydatne w agentach utrzymujących długi stan zadania, analizujących obszerne dokumenty lub pracujących przez wiele kolejnych etapów. Rzeczywista użyteczna długość kontekstu i wydajność będą zależeć od konfiguracji oraz stosu do serwowania modelu.

Wariant NVFP4 jest przeznaczony przede wszystkim do wdrażania inferencji i korzysta ze specjalizowanych jąder NVIDIA na obsługiwanych generacjach procesorów graficznych. NVIDIA wymienia infrastrukturę lokalną, stacje robocze, centra danych i chmurę; model jest również dostępny za pośrednictwem Hugging Face oraz usług hostowanych.

AWS informuje, że Nemotron 3.5 Lightning można uruchomić przez SageMaker JumpStart — katalog modeli dostępny w konsoli Amazon SageMaker lub przez Python SDK. Osobną ścieżkę oferuje dokumentacja NVIDIA NIM, oparta na kontenerze i wymagająca określonych wersji systemu, CUDA, sterownika oraz Dockera.

Warto zachować ostrożność przy ocenie wymagań sprzętowych. Kwantyzowany checkpoint może ułatwić uruchomienie modelu, ale możliwość pracy na jednej karcie zależy m.in. od pamięci GPU, długości kontekstu, wybranej kwantyzacji, wielkości partii oraz oprogramowania serwującego. Nie należy automatycznie przenosić deklaracji dotyczących konkretnego sprzętu na każdy laptop lub komputer stacjonarny.

Deklaracje szybkości wymagają kontekstu

NVIDIA i AWS podają dla wybranych obciążeń agentowych nawet czterokrotnie wyższą przepustowość oraz do 30% krótszy czas realizacji zadań. Nie są to uniwersalne miary inteligencji modelu ani gwarancja identycznych wyników w środowisku produkcyjnym.

Rzeczywiste rezultaty mogą się zmieniać w zależności od:

• modelu bazowego użytego do porównania;
• generacji GPU i konfiguracji pamięci;
• rozmiaru partii oraz poziomu współbieżności;
• długości promptu i kontekstu;
• opóźnień narzędzi oraz sieci;
• ustawień dekodowania;
• dopuszczalnego poziomu błędów.

Dlatego Lightning warto testować na operacjach istotnych dla konkretnego agenta: dokładności ekstrakcji, niezawodności wywołań narzędzi, zgodności z wymaganym formatem oraz całkowitym czasie wykonania. Sama liczba tokenów generowanych na sekundę nie wystarczy do oceny przydatności modelu.

Ile kosztuje korzystanie z Lightninga?

Ceny usług hostowanych mogą być atrakcyjne przy dużej liczbie wywołań. DeepInfra podaje stawkę 0,05 dol. za 1 mln tokenów wejściowych i 0,20 dol. za 1 mln tokenów wyjściowych. Usługa rozlicza użycie i nie wymaga samodzielnego zarządzania infrastrukturą GPU.

Nie jest to jednak stała „cena modelu”. Stawki zależą od dostawcy, trasy, precyzji i obsługi cache’u, a poszczególne platformy publikują inne wartości. Przy porównywaniu Lightninga z większymi modelami trzeba więc policzyć koszt całego procesu, uwzględniając ponowienia, wywołania narzędzi, routing oraz te żądania, które nadal trafią do bardziej zaawansowanego modelu.

Wniosek: szybki pracownik w systemie wielomodelowym

Nemotron 3.5 Lightning jest przede wszystkim szybkim i konfigurowalnym modelem roboczym dla systemów agentowych. Najwięcej sensu ma tam, gdzie aplikacja generuje wiele podobnych wywołań, a zadania można wyspecjalizować, ograniczyć regułami lub dostroić do konkretnej domeny.

Nie jest przedstawiany jako uniwersalny zamiennik dużego modelu orkiestrującego. Złożone planowanie, niepewna ocena sytuacji i zadania, w których koszt błędu jest wysoki, nadal mogą wymagać Nemotron 3 Ultra albo innego modelu klasy frontier.

Praktyczny werdykt jest prosty: Lightning najlepiej pasuje do niskolatencyjnej warstwy wykonawczej w routowanym stosie agentowym. Jego 30 mld parametrów łącznie, około 3 mld parametrów aktywnych, otwarte materiały modelu, wariant NVFP4 i różne ścieżki wdrożenia mają sprawić, że rutynowa praca agentów będzie tańsza i szybsza. Deklarowane zyski należy jednak potwierdzić na własnym przepływie pracy przed wykorzystaniem modelu w produkcji.