Płaska linia, która wszystko zdradziła
Dwa NVIDIA DGX Spark. Jeden duży model rozłożony na oba. Oczywiste pytanie: czy mogę odzyskać jedną z tych maszyn? Pierwszy eksperyment powiedział stanowczo, że nie — i mierzył nie to, co trzeba.
Punkt wyjścia
Dwa DGX Spark połączone bezpośrednio, uruchamiające DeepSeek V4 Flash rozłożony na oba GPU. Rozgrzane, porządnie zbenchmarkowane: 86,6 tok/s szczytowo, 66,4 średnio na zestawie różnych promptów.
Działa dobrze. Zjada też cały klaster. Inferencja tensor-parallel oznacza, że obie maszyny obsługują jeden model, więc nie zostaje druga skrzynka na nic innego. To realny koszt, kiedy ma się tylko dwie.
Więc: co, gdybym zamiast tego uruchomił mniejszy model na jednym węźle i odzyskał całą maszynę?
Eksperyment pierwszy: oczywista odpowiedź
Postawiłem Nemotron-3 Super od NVIDII — łącznie 120B parametrów, 12B aktywnych na token, wagi 4-bitowe — na jednym węźle. Ta sama uprząż benchmarku, te same prompty, ta sama dyscyplina rozgrzewki.
15,1 tok/s.
Wobec 66,4. Mniej więcej 4,4× wolniej. Wniosek pisze się sam: zwolnienie maszyny kosztuje większość prędkości, więc nie rób tego. Sprawa zamknięta.
Prawie na tym skończyłem.
Problem z tą liczbą
Między dwoma pomiarami zmieniły się dwie rzeczy. Zmienił się model i zmieniła się liczba węzłów. Jeden stosunek obejmujący obie mówi ci o sumie i nic o podziale.
To ważne, bo obie odpowiedzi prowadzą w przeciwne strony. Jeśli różnica to głównie sprzęt, druga maszyna wykonuje ciężką pracę i musi zostać. Jeśli to głównie model, druga maszyna jest prawie bez znaczenia i powinienem raczej szukać lepszego modelu na jeden węzeł.
Stosunek 4,4× pasuje do obu. To też dokładnie ten rodzaj liczby, którą ludzie cytują, jakby coś rozstrzygała.
Poprawka jest tania: uruchom ten sam model w obu ustawieniach i pozwól, żeby oś, którą kontrolujesz, się skróciła.
Eksperyment drugi: ten sam model, oba węzły
24,9 tok/s.
Teraz arytmetyka się zgadza:
Nemotron, 1 węzeł → 2 węzły : 15.1 → 24.9 = 1.65× sprzęt
Nemotron vs DeepSeek, oba na 2 węzłach: 24.9 → 66.4 = 2.70× model
─────
1.65 × 2.70 = 4.4× ← różnica, od której zacząłem
Druga maszyna jest warta 1,65×. Podliniowo, czego należało się spodziewać — podwajasz przepustowość pamięci, ale płacisz za to, że obie połowy muszą ze sobą rozmawiać.
Cała reszta, ten większy czynnik, to był model.
Miałem właśnie przypisać sprzętowi zasługę za coś, co robiło oprogramowanie.
Płaska linia
Trop cały czas leżał w surowym wyjściu. Oto oba modele na pięciu bardzo różnych promptach — liczenie do 300, tabliczka mnożenia, tablica JSON, binarne drzewo poszukiwań i krótkie opowiadanie:
Nemotron 15.1 15.2 15.2 15.1 15.1 ← płasko DeepSeek 86.6 81.8 77.0 67.5 29.6 ← rozrzut 2.9×
Jedna z nich to płaska linia. Druga zmienia się prawie 3× w zależności od tego, o co prosisz.
To nie szum. To odcisk palca.
DeepSeek używa speculative decoding: mały model szkicowy zgaduje kilka tokenów do przodu, duży model weryfikuje je w jednym przebiegu, a każde zgadnięcie, które przetrwa, to darmowa przepustowość. Co kluczowe, zgadywanie działa znakomicie na przewidywalnym tekście — tabliczce mnożenia, hurtowym JSON-ie — i słabo na prozie, gdzie następnym słowem naprawdę może być cokolwiek.
Prędkość serwera, który spekuluje, zależy więc od treści. Serwer, który nie spekuluje, liczy tyle samo za każdy token, jakkolwiek oczywisty by był.
Płasko znaczy brak spekulacji. I znaczy, że liczba jest uczciwa: 15,1 nie było złą próbką, to był cały rozkład.
To zmienia ujęcie całego porównania. Nie zmierzyłem „duży model kontra mniejszy” ani „dwie maszyny kontra jedna”. Zmierzyłem głównie to, że jeden model ma speculative decoding, a drugi nie — a żadna ilość dodatkowego sprzętu takiej różnicy nie zamknie.
Koda: podatek od myślenia
Podłączyłem mniejszy model do asystenta do kodowania, żeby go wyczuć. Pierwszy prompt: „Reply with exactly: NEMOTRON OK.”
Odpowiedział poprawnie. Wydał na to też 63 tokeny — 56 z nich na rozważania o dokładnym formatowaniu dwuwyrazowej odpowiedzi.
Z wyłączonym rozumowaniem ten sam prompt kosztował 7 tokenów.
Dziewięć razy więcej pracy za dwuwyrazową odpowiedź. A ponieważ te tokeny myślenia generowane są z tą samą prędkością co cała reszta, idą prosto z budżetu opóźnienia. Przy ~25 tok/s to różnica między dwiema i pół sekundy a jedną trzecią sekundy.
Benchmarki ukrywają to niemal idealnie. Generowanie 1500 tokenów amortyzuje stały wstęp rozumowania do zera, więc model dobrze wypada w benchmarku, a i tak wydaje się ociężały w krótkich turach, które dominują w prawdziwym interaktywnym użyciu.
Potem ostrzejsza krawędź. Ograniczyłem żądanie do 30 tokenów. Odpowiedź wróciła poprawnie sformatowana, bez błędu, finish_reason: length — i content: null. Rozumowanie zużyło cały budżet, zanim doszło do odpowiedzi. Każde narzędzie, które wysyła żądania z małym budżetem — generowanie tytułu, streszczanie, klasyfikacja — dostaje puste ciągi zamiast błędów.
Wskazówki dla czytelnika
Stosunek przy dwóch zmienionych zmiennych to nie wynik. Jeśli dwa systemy różnią się na kilka sposobów, zmieniaj jedno naraz, aż oś, którą kontrolujesz, się skróci. Jeden dodatkowy eksperyment zamienił bezużyteczne 4,4× w dwie liczby, na podstawie których mogłem działać — i odwrócił, która z nich miała znaczenie.
Szukaj odcisku palca, a nie tylko średniej. Rozrzut na poszczególnych promptach powiedział więcej niż średnia. Płaska przepustowość przy skrajnie różnej treści to mocny sygnał o mechanizmie, a nie tylko o wydajności. Średnie ukrywają dokładnie tę strukturę, której potrzebujesz.
Porównanie przez granicę funkcji mierzy tę funkcję. Jeśli jedna strona ma speculative decoding, a druga nie, benchmarkujesz speculative decoding. To całkiem dobra rzecz do zmierzenia, ale trzeba to powiedzieć, bo „model A jest 4,4× szybszy od modelu B” zachęca do wniosku, którego dane nie wspierają.
Przepustowość i opóźnienie to nie to samo twierdzenie. Model może mieć przyzwoitą liczbę tokenów na sekundę i nadal wydawać się wolny, jeśli spora część tych tokenów zostaje wydana, zanim zacznie się odpowiedź.
Obie maszyny zostały przy dużym modelu. Nie dlatego, że druga maszyna zarabia na siebie — dokłada skromne 1,65× — tylko dlatego, że nic, co miałem dostępne na jednym węźle, nie nadrobiłoby reszty.
To inny wniosek niż ten, od którego zacząłem, i wskazuje też gdzie indziej: nie na kupowanie sprzętu, tylko na znalezienie modelu na jeden węzeł, który spekuluje.