NVIDIA: Nemotron 3.5 Lightning (free)

NVIDIA Nemotron 3.5 Lightning to model językowy do rozumowania, rozmów i wyspecjalizowanych procesów agentowych. Ma 30 mld parametrów łącznie, z czego 3 mld są aktywne, i wykorzystuje hybrydową architekturę z przeplatanymi warstwami Mamba-2, mixture-of-experts oraz uwagi. Warstwy Multi-Token Prediction dodają sygnały treningowe dla przyszłych tokenów i wspierają zoptymalizowane procedury generowania modelu. Model przetwarza tekst i tworzy tekst, w tym wyjaśnienia, kod oraz odpowiedzi oparte na dostarczonych materiałach.

Producent opisuje zastosowania w chatbotach, generowaniu wspomaganym wyszukiwaniem, wykonywaniu instrukcji i agentach. Aby uzyskać odpowiedź z bazy wiedzy, podaj pytanie oraz odpowiednie fragmenty z trwałymi oznaczeniami źródeł. Poproś model o odpowiedź na podstawie tych fragmentów, wskazanie, który z nich uzasadnia każde ważne twierdzenie, oraz określenie, co pozostaje nieznane. Na przykład: „Na podstawie tych artykułów pomocy wyjaśnij różnicę między dwiema metodami instalacji i zwróć wymagania wstępne, kroki oraz kontrole dla każdej z nich”. Pozostaw brakujące wymaganie wstępne wyraźnie zaznaczone, zamiast skłaniać model do jego wymyślenia.

Przy programowaniu dostarcz odpowiedni kod, oczekiwane zachowanie i zaobserwowany błąd. Praktyczne polecenie prosi o ukierunkowaną poprawkę oraz wyjaśnienie przypadków, których dotyczy. Jeśli agent połączony z narzędziami uruchamia kontrolę, przekaż jej rzeczywisty wynik przed poproszeniem o następną zmianę. Trening modelu obejmuje kod, wieloetapowe użycie narzędzi i zadania z ustrukturyzowanym wynikiem, ale ukończony materiał nadal musi odpowiadać pierwotnemu wymaganiu. Poproś o poprawiony kod, uzasadnienie każdej istotnej zmiany oraz obserwacje potrzebne do ustalenia, że problem został rozwiązany.

Producent dokumentuje domyślnie włączone myślenie oraz tryb bezpośredniej odpowiedzi, w którym myślenie wyłącza się za pomocą szablonu rozmowy. Tryb rozumowania jest przydatny przy zadaniu z kilkoma zależnymi warunkami, a bezpośrednia odpowiedź może pasować do prostej transformacji lub wyodrębniania danych. Producent zaleca w przykładach klienta temperaturę 1,0 i top-p 0,95. Traktuj je jako ustawienia procedury producenta i wyraźnie określ strukturę końcowej odpowiedzi, na przykład zwięzłe wyjaśnienie, tabelę porównawczą albo odpowiedź z następującymi po niej dowodami.

Model obsługuje kontekst do 1 mln tokenów. Opublikowane procedury wdrażania BF16 rozróżniają tę możliwość modelu od konfiguracji wykorzystujących okno 256 tys. tokenów ze względu na ograniczenia pamięci. Przygotuj długi materiał dla właściwego okna roboczego, zachowując strukturę dokumentów i pozostawiając miejsce na odpowiedź. Długi kontekst jest najbardziej przydatny, gdy polecenie określa relację, którą należy znaleźć: sprzeczności między dokumentami, zależności między plikami źródłowymi lub dowody uzasadniające wniosek. Nie jest to powód, aby dodawać niezwiązaną historię ani zakładać, że końcowa odpowiedź może zająć całe okno.

Główny nacisk położono na język angielski i języki programowania; wymieniono również hiszpański, francuski, niemiecki, włoski i japoński. Określ wymagany język wyjściowy i zachowaj nazwy, identyfikatory oraz cytowane terminy źródłowe, gdy ich pisownia ma znaczenie. Przy pracy z dokumentami wielojęzycznymi sprecyzuj, czy należy je tłumaczyć, podsumować czy porównać; te polecenia prowadzą do różnych rezultatów. Poproś o oznaczenie niepewnych terminów, aby płynne tłumaczenie nie zmieniło po cichu znaczenia technicznego.

NVIDIA publikuje referencyjną wersję BF16 przede wszystkim do dostosowywania i badań z pełną precyzją oraz osobną wersję NVFP4 ze zoptymalizowanymi procedurami wnioskowania. To rozróżnienie ma znaczenie przy porównywaniu wskazówek wdrożeniowych: konfiguracja sprzętu lub wynik przepustowości jednej wersji nie opisuje automatycznie innej. Nazwa modelu identyfikuje rodzinę Lightning, a dokładny checkpoint i konfiguracja udostępniania określają procedurę. Oddziel możliwości modelu od założeń dotyczących wydajności i pamięci właściwych konkretnej procedurze.

Przy pracy z narzędziami dostarcz jasne opisy funkcji i zwracaj rzeczywisty wynik każdego wykonanego kroku. Proponowana operacja staje się użytecznym dowodem dopiero wtedy, gdy otaczająca aplikacja ją wykona i zapisze, co się wydarzyło. Poproś, aby końcowa odpowiedź rozróżniała obserwacje ze źródeł, wyprowadzone wnioski i niedokończone kontrole. Gdy obliczenie, polecenie lub pobrany fragment jest sprzeczny z planowanym wynikiem, wykorzystaj tę sprzeczność do zmiany wniosku, zamiast tworzyć dopracowane podsumowanie niesprawdzonego założenia.