Granite 4.2 30B vs Nemotron 3.5 Lightning: myśliciel i wykonawca

Granite 4.2 30B i Nemotron 3.5 Lightning to dwa modele o otwartych wagach 30B, które ukazały się w odstępie czternastu dni i mają niemal przeciwstawne zadania. Nemotron 3.5 Lightning, wydany przez NVIDIA 11 sierpnia 2026 roku, to hybrydowy model Mixture-of-Experts o łącznej liczbie 30B parametrów i 3B aktywnych — z warstwami przestrzeni stanów Mamba-2, MoE i uwagą — zaprojektowany jako warstwa wykonawcza systemów agentowych: szybkie wywołania narzędzi, pętle o dużej objętości, praca subagentów, działanie na pojedynczym GPU. Granite 4.2 30B, który IBM opublikował po cichu na Hugging Face 25 sierpnia 2026 roku, to gęsty model rozumowania z 29 miliardami parametrów — myśliciel, z wybieralnymi trybami myślenia i agentowym uczeniem przez wzmacnianie, również możliwy do samodzielnego hostowania. Oba są otwarte (Apache 2.0 wobec OpenMDW-1.1), oba mieszczą się na sprzęcie, który zespół może faktycznie posiadać, i oba są sierpniowymi wydaniami, których benchmarki są nadal w zasadzie raportowane przez dostawców. Ciekawe pytanie nie brzmi, który jest lepszy, ale którego potrzebujesz — planisty, wykonawcy, czy obu.

Ten podział na planistę/wykonawcę nie jest wymysłem redakcyjnym; to własny projekt NVIDIA. Nemotron 3.5 Lightning został destylowany ze znacznie większego Nemotron 3 Ultra dokładnie po to, aby czołowy model mógł obsługiwać planowanie, podczas gdy Lightning wykonuje pętlę, a NVIDIA wypuściła go razem z NeMo Switchyard, biblioteką routingu, która wdraża dokładnie ten podział pracy. Granite 4.2 30B, w przeciwieństwie, stara się być całym agentem w jednym pakiecie 30B.

Granite 4.2 30B, myśliciel

Flagowy model IBM Granite 4.2 to gęsty Transformer typu decoder-only z trzema trybami rozumowania — pełne myślenie (ujęte w think>.../think> znaczniki), myślenie o niskim nakładzie i brak myślenia — a także wywoływanie narzędzi zgodne z OpenAI i agentowe uczenie przez wzmacnianie, które wyszkoliło go do obsługi terminali, wykonywania kodu i przeszukiwania sieci w sandboxie. Jego natywny kontekst 128K można rozszerzyć do 512K. Karta modelu IBM deklaruje 89.17 na AIME 2025, 77.60 na MMLU-Pro i 57.00 na SWE-Bench Verified (w środowisku testowym) — wszystkie raportowane przez producenta, żaden nie został niezależnie odtworzony, a na Artificial Analysis nie ma jeszcze żadnego wpisu. Krótko mówiąc, to uniwersalny model rozumowania mocno ukierunkowany na pracę agentową, dostępny w kwantyzacjach BF16 oraz FP8, NVFP4/MXFP4 i GGUF, aby zespoły mogły faktycznie go uruchomić.

Nemotron 3.5 Lightning, człowiek czynu

Oferta NVIDIA ma zupełnie inny kształt. Nazwa „30B A3B” oznacza 30 miliardów parametrów łącznie, z czego tylko około 3 miliardy jest aktywnych na token — to architektura hybrydowa łącząca Mamba-2, MoE (mieszankę ekspertów) i mechanizm uwagi, która pozwala na szybkie i tanie generowanie. Model jest wyposażony we wbudowane spekulatywne dekodowanie: głowice Multi-Token Prediction oraz modele szkicowe DFlash i DSpark, dzięki czemu mały model szkicowy proponuje tokeny, a główny model weryfikuje je równolegle. NVIDIA twierdzi, że prędkość generowania jest nawet 4 razy większa niż w przypadku modeli o podobnej wielkości, a całość działa na pojedynczym GPU — RTX 5090, DGX Spark lub Jetson — albo przy kontekście 256K na jednym H100, przy czym model obsługuje zasadniczo kontekst do 1M. Jego licencja, OpenMDW-1.1, obejmuje wagi, dane treningowe i receptury.

Własne stanowisko NVIDII jest dosadne co do tego, czym Lightning nie jest: dostarczona przez firmę ewaluacja wykazała słabą wydajność Terminal-Bench jako głównego agenta — LLM Stats niezależnie potwierdziło około 24,6 w Terminal-Bench 2.1 — a zalecenie jest takie, aby używać go jako wykonawcy, a nie planisty. Według własnych deklaracji jego mocne strony to MMLU Pro 81,94, GPQA Diamond 75,44, SWE-Bench Verified 51,56 oraz PinchBench z dokładnością 86%, przy czym kończy zadania około 30% szybciej niż Qwen 3.6 35B przy podobnej dokładności. Każda z tych liczb pochodzi od samej NVIDII.

Tablica wyników, uczciwie oznaczona

Przydatne porównanie dotyczy kształtu kolumny, a nie wartości wierszy:

• Granite 4.2 30B — ~29B gęsty, wszystkie parametry aktywne; Apache 2.0; 128K natywnie / 512K rozszerzone; tryby rozumowania, które możesz wybrać dla każdego żądania; deklarowane przez producenta SWE-Bench Verified 57.00, Terminal-Bench 2.1 29.24; myśliciel.

• Nemotron 3.5 Lightning — 30B łącznie / 3B aktywnych, hybrydowy MoE; OpenMDW-1.1; kontekst 1M (256K praktycznie na jednym H100); dekodowanie spekulacyjne (MTP/DFlash/DSpark); wyniki deklarowane przez dostawcę: SWE-Bench Verified 51,56, ~24,6 Terminal-Bench 2.1 (zweryfikowane przez LLM Stats); wykonawca.

Interpretuj te wiersze tak, jak zamierza NVIDIA: słabość Lightninga w Terminal-Bench jest cechą jego konstrukcji — nie ma on planować, ma wykonywać. Wyniki Granite pochodzą od pojedynczego modelu, który twierdzi, że robi i jedno, i drugie. Żaden z tych zestawów nie został niezależnie odtworzony w momencie premiery; oba zostaną odtworzone w ciągu tygodni.

Stos, a nie model.

Te dwa modele są mniej konkurentami, a bardziej sąsiednimi komponentami tego samego systemu. Agent potrzebuje planisty do dekompozycji zadania oraz wykonawcy, który przemieli tysiące wywołań narzędzi. Granite 4.2 30B próbuje połączyć oba w jeden gęsty model; Nemotron 3.5 Lightning to wyraźnie połowa dwumodelowego stosu, z modelem granicznym jako drugą połową. NVIDIA nazywa ten stos NeMo Switchyard; warstwa routingu robi to samo z dowolną mieszanką modeli hostowanych i samodzielnie hostowanych.

To jest miejsce, w którym powinna znaleźć się uczciwa notatka o routingu. Żaden z modeli nie jest na OrcaRouter – nie kierujemy ruchu ani do Granite 4.2 30B, ani do Nemotron 3.5 Lightning, a linia dostępności dla obu to własny sprzęt lub kanały producenta. Ale wzorzec dwóch modeli, na który wskazują, jest dokładnie tym, do czego służy DSL routingu: skomponuj samodzielnie hostowany endpoint Granite dla przebiegów rozumowania i samodzielnie hostowany endpoint Lightning dla pętli wykonawczych, umieść hostowany model graniczny z przodu do planowania, które wymaga więcej przestrzeni, i zasilaj wszystkie trzy jednym kluczem API z automatycznym przełączaniem awaryjnym. Nie musisz wybierać między myślicielem a wykonawcą – możesz złożyć stos, który używa każdego z nich tam, gdzie jest silny, i pozwolić routerowi arbitrażować.

Który pierwszy

Jeśli chcesz mieć jeden model, jedną bazę kodu, jeden stos serwowania i powierzyć mu całą pracę związaną z rozumowaniem i wykonywaniem, zacznij od Granite 4.2 30B — ale poczekaj na pierwszy niezależny benchmark, zanim zaufasz liczbie 57.00 w SWE-Bench. Jeśli budujesz agenta o dużej przepustowości, w którym większość wywołań to krótkie kroki narzędziowe, a ograniczeniem jest opóźnienie, zacznij od Nemotron 3.5 Lightning i pozwól, aby myślenie przejął model graniczny lub endpoint Granite. Jeśli budujesz coś poważnego, odpowiedź brzmi: oba — a to decyzja, której porównanie wyłącznie modeli 30B nigdy by nie ujawniło.