Benchmark Qwen3.8 Basalt raportuje 153 tokeny na sekundę przy 16 GB VRAM

Wyniki benchmarku Qwen3.8 Basalt opublikowane 25 października wskazują na 153 tokeny na sekundę na RTX 5080, mimo limitu 16 GB pamięci graficznej. Stacja robocza wykorzystywała także 54,1 GB pamięci systemowej. Nagłówek wpisu podkreśla generowanie przekraczające 250 tokenów na sekundę, lecz liczba ta opisuje krótki szczyt, a nie utrzymaną wydajność.

To rozróżnienie ma znaczenie dla programistów rozważających lokalnych asystentów programistycznych. Według autora wpisu sesja obsłużyła 103 żądania, podczas gdy osobny test przetwarzał nowe prompty przy różnych długościach kontekstu. Te obciążenia dostarczają przydatnych informacji o responsywności, choć żadne z nich nie potwierdza dokładności kodowania ani niezależnie zweryfikowanej wydajności.

Kluczowe napięcie dotyczy zmieszczenia dużego modelu w stacji roboczej przy zachowaniu użytecznej szybkości i akceptowalnej jakości odpowiedzi. Basalt, wyspecjalizowany silnik inferencyjny, konkuruje o takie obciążenia ze Strata oraz szerszymi alternatywami, takimi jak llama.cpp. Raport ten uzasadnia bliższe zbadanie tego podejścia, a nie ogólne twierdzenie, że pojemność pamięci graficznej przestała mieć znaczenie.

Benchmark Qwen3.8 Basalt oddziela szczyty od utrzymanej szybkości

Najbardziej użyteczne wartości generowania to zgłoszone średnie: 153,0 tokeny na sekundę podczas kodowania oraz 154,9 podczas testu kontekstu.

Token jest jednostką tekstu przetwarzaną lub generowaną przez model językowy. Tokeny na sekundę mierzą przepustowość, choć nie mierzą bezpośrednio, czy wygenerowany kod działa. Rozróżnienie autora między średnią a szczytową wydajnością powinno pozostać częścią każdego podsumowania tych wyników.

Benchmark RTX 5080 identyfikuje konfigurację modelu jako Qwen3.8-Flash-Next IQ3_S. IQ3_S to format kwantyzacji, co oznacza, że reprezentuje wagi modelu z obniżoną precyzją numeryczną. Ta konfiguracja jest częścią tożsamości wyniku, a nie wymiennym szczegółem.

Zgłoszona stacja robocza łączyła RTX 5080 z procesorem Core Ultra 9 285K oraz 62 GB pamięci DDR5-6800. Zużycie pamięci graficznej osiągnęło 15,7 GB. Silnik miał zajmować 54,1 GB pamięci systemowej, pozostawiając 5,2 GB wolne podczas kodowania i 5,1 GB podczas testu.

Sesja kodowania korzystała z opencode, interfejsu agenta programistycznego, w ramach 103 żądań i osiągnęła około 130 000 tokenów kontekstu. Kontekst to informacje dostępne dla modelu podczas tworzenia odpowiedzi. Źródło podaje skonfigurowaną pojemność wynoszącą około 262 000 tokenów, która przekracza zaobserwowaną głębokość sesji kodowania.

Według autora generowanie osiągało średnio 153,0 tokeny na sekundę dla wygenerowanych tokenów i czasu dekodowania. Czas dekodowania to okres poświęcony na tworzenie tokenów wyjściowych. Zgłoszony szczyt 262 tokenów na sekundę obejmuje najlepszą pojedynczą sekundę, a nie kompletne żądanie ani sesję.

Osobny test wykorzystywał nowe prompty o długości od około 15 000 do 207 000 tokenów. Średnia szybkość generowania wyniosła 154,9 tokeny na sekundę, przy szczycie 186,6. Autor opisuje te pomiary jako średnie dla żądań, przy odpowiedziach liczących 384 tokeny, temperaturze próbkowania 0,7 i dwóch uruchomieniach dla każdej głębokości.

Te definicje zapobiegają mylącej interpretacji. Maksimum z pojedynczej sekundy i średnia na poziomie żądania opisują różne obserwacje. Żadna z nich nie powinna zastępować drugiej tylko dlatego, że obie używają miary tokenów na sekundę.

Utrzymane wyniki czynią raport bardziej interesującym, niż sugeruje sam nagłówek. Przepływ pracy związany z kodowaniem potrzebuje spójnych odpowiedzi w kolejnych interakcjach. Krótki zryw pomaga scharakteryzować system, lecz programiści ostatecznie doświadczają kompletnych żądań, przerw, wykonywania narzędzi i poprawek.

Nadal są to pomiary zgłoszone przez autora. Dostępne dowody ustalają, co autor zgłosił, i wyjaśniają kategorie pomiarów. Nie dowodzą, że inna stacja robocza odtworzy wyniki ani że każde żądanie utrzymało zagregowaną średnią.

Ponowne wykorzystanie cache'u zmienia znaczenie czasu odpowiedzi

Zgłoszony medianowy czas rozpoczęcia odpowiedzi wynoszący 0,2 sekundy dotyczy sesji z ponownym wykorzystaniem 99,5% tokenów promptu z cache'u.

Cache promptów ponownie wykorzystuje wcześniej obliczone informacje z wcześniejszego wejścia zamiast ponownie przetwarzać ten sam materiał. Takie zachowanie ma znaczenie w sesjach kodowania, ponieważ kolejne żądania często współdzielą historię rozmowy, materiały repozytorium i instrukcje. Ponowne wykorzystanie tej pracy może sprawić, że trwająca sesja będzie odczuwalnie znacznie bardziej responsywna.

Autor podaje, że 99,5% tokenów promptu pochodziło z cache'u promptów. Mediana czasu do pierwszego tokenu wyniosła 0,2 sekundy. Czas do pierwszego tokenu mierzy opóźnienie przed rozpoczęciem generowania, a nie czas potrzebny na ukończenie odpowiedzi.

Rozpatrywane łącznie pomiary te opisują korzystne obciążenie oparte na powtarzanych interakcjach. Nie pokazują, że silnik potrafi przeczytać całkowicie nieznany, długi prompt repozytorium i rozpocząć odpowiedź z takim samym opóźnieniem. Nowe żądanie należy oceniać osobno.

Źródło częściowo uwzględnia to rozróżnienie poprzez pomiary przetwarzania bez cache'u. W przypadku sesji kodowania przetwarzanie promptów osiągało średnio 5 011 tokenów na sekundę i szczytowo 5 118. Autor twierdzi, że wartości te reprezentują dwa znaczące odczyty bez cache'u, zawierające około 10 700 i 8 000 nowych tokenów.

Przetwarzanie promptu to obliczenia wymagane do przyjęcia wejścia przed wygenerowaniem odpowiedzi. Jego przepustowość różni się od przepustowości generowania, ponieważ model wykonuje inną pracę na tych etapach. Łączenie ich w jedno twierdzenie o szybkości ukrywa informacje potrzebne czytelnikom.

Test nowych promptów zgłosił średnią przepustowość przetwarzania promptów na poziomie 5 475 tokenów na sekundę, przy szczycie 5 662. Zapewnia to osobną obserwację obsługi wejścia. Powinna towarzyszyć wynikom sesji kodowania intensywnie korzystającej z cache'u, gdy ktoś charakteryzuje responsywność silnika.

Dla programistów implikacje zależą od tego, jak ich praca akumuluje kontekst. Asystent, który wielokrotnie wraca do tego samego projektu, może korzystać z zachowanych obliczeń. Przepływ pracy, który często zastępuje dokumenty lub zmienia repozytoria, stanowi inne obciążenie.

Rozważmy agenta, który odczytuje projekt, proponuje zmianę, otrzymuje błąd kompilatora i poprawia łatkę. Znaczna część otaczających informacji pozostaje istotna między tymi turami. Zachowanie cache'u może zatem wpływać na doświadczenie, nawet gdy bazowa szybkość generowania modelu pozostaje niezmieniona.

Rozważmy teraz analityka otwierającego w ciągu dnia niezwiązane ze sobą kolekcje dokumentów. Powtarzanego materiału może być mniej. Zastosowanie medianowego opóźnienia odpowiedzi z sesji kodowania do takiego przepływu pracy wymagałoby dowodów, których wpis nie dostarcza.

Cache jest więc istotną częścią zgłoszonego wyniku. Wyjaśnia, dlaczego użytkownicy powinni przeanalizować własne wzorce żądań, zanim potraktują benchmark jako prognozę. Decydujące pytanie brzmi, ile obliczeń ich aplikacja rzeczywiście może ponownie wykorzystać.

Pamięć systemowa niesie ze sobą kompromis stacji roboczej

Karta graficzna z 16 GB pamięci stanowi podstawę tej konfiguracji, ale zgłoszone obciążenie zależy także od 54,1 GB pamięci systemowej.

VRAM to pamięć podłączona do procesora graficznego, podczas gdy systemowy RAM obsługuje szersze potrzeby komputera. Raport wykorzystuje oba rodzaje pamięci. Opisywanie wyniku wyłącznie przez pryzmat karty graficznej zaniża zasoby maszyny zaangażowane w test i zaciera praktyczne ograniczenia dla potencjalnych użytkowników.

Projekt pamięci ekspertów opisuje Basalt jako fork Strata przeznaczony dla sprzętu NVIDIA Blackwell. Uruchamia model mixture-of-experts, który wybiera wyspecjalizowane komponenty modelu do obliczeń. Eksperci przekraczający pojemność pamięci graficznej mogą znajdować się w systemowym RAM.

Ten projekt wyjaśnia ogólne podejście, nie potwierdzając niezależnie tego konkretnego benchmarku. Dokumentacja projektu ustala, że wykorzystywanie pamięci systemowej jest celowe. Pomiary z Reddita dostarczają zgłoszonych danych o szybkości i zużyciu pamięci dla określonej stacji roboczej.

Praktyczna presja dotyczy programistów decydujących, czy ich obecna maszyna może obsługiwać lokalnego asystenta. Sama pojemność pamięci graficznej daje niepełną odpowiedź. Dostępna pamięć systemowa, inne aplikacje oraz wymagania dotyczące kontekstu należą do tej samej oceny.

Na szczególną uwagę zasługują zgłoszone wartości wolnej pamięci. Pozostawienie 5,2 GB dostępnych podczas kodowania nie dowodzi niestabilności, ale opisuje ograniczony zapas pojemności na testowanej maszynie. Edytor, przeglądarka, proces kompilacji lub inna lokalna usługa wprowadzają dodatkowe zapotrzebowanie.

Nie oznacza to, że każda porównywalna stacja robocza zawiedzie podczas zwykłej pracy programistycznej. Oznacza to, że benchmark nie może zagwarantować komfortowej wielozadaniowości. Użytkownicy potrzebują pomiarów wykonywanych przy uruchomionym rzeczywistym środowisku programistycznym, a nie wtedy, gdy silnik inferencyjny działa w izolacji.

To samo rozumowanie dotyczy odczytu pamięci graficznej. Zgłoszone użycie 15,7 GB zbliża się do pojemności 16 GB wskazanej karty. Ta obserwacja powinna zniechęcać do zakładania dużego zapasu dla niezwiązanych obciążeń graficznych lub innych ustawień silnika.

W tym miejscu atrakcyjność nagłówka spotyka się z kompromisem operacyjnym. Raport opisuje strategię alokacji, która pozwala zmieścić obciążenie w dostępnych zasobach. Nie opisuje modelu działającego całkowicie w ramach skromnego budżetu pamięci graficznej.

Decyzja zakupowa powinna zatem zaczynać się od kompletnej stacji roboczej. Dodanie kompatybilnej karty graficznej do skądinąd ograniczonej maszyny nie odtwarza zgłoszonego środowiska. Ani dopasowanie pojemności pamięci nie musi odtworzyć zachowania procesora, ustawień oprogramowania czy utrzymanej przepustowości.

Aplikacje intensywnie korzystające z wiedzy wymagają jeszcze jednego rozważenia: organizowanie materiałów źródłowych pozostaje odrębne od uruchamiania modelu. Przeszukiwalna baza wiedzy dotyczy dostępu do dokumentów, podczas gdy ten benchmark dotyczy obliczeń po dotarciu danych wejściowych do silnika.

Użyteczny wniosek jest konkretny. Programiści oceniający tę konfigurację powinni zaplanować pamięć zarówno na inferencję, jak i otaczające ją narzędzia. Zgłoszona szybkość sprawia, że taka ocena jest warta wysiłku, lecz wymaganie dotyczące pamięci systemowej pozostaje kluczowe dla wyniku.

Strata i llama.cpp wymagają porównywalnych zestawień

Ten raport dotyczący stacji roboczej nie ustanawia kontrolowanego rankingu wydajności między Basalt, Strata i llama.cpp.

Tytuł wymienia razem Strata i Basalt, lecz opis dostarczonego obciążenia wskazuje Basalt jako użyty silnik. Czytelnicy powinni zachować to rozróżnienie. Wyniki forka nie powinny automatycznie stawać się twierdzeniami o wydajności projektu nadrzędnego.

Strata zapewnia rodowód Basalt, a llama.cpp stanowi kolejny istotny punkt odniesienia dla lokalnej inferencji. Ich obecność ustanawia kontekst konkurencyjny. Nie uzasadnia ogłoszenia zwycięzcy bez dopasowanych plików modeli, ustawień, sprzętu i sekwencji żądań.

Dokumentacja benchmarku inferencyjnego oddziela przetwarzanie promptów od generowania tekstu i wspiera testowanie przy określonych głębokościach kontekstu. Rejestruje także powtarzane pomiary. Kategorie te pokazują, dlaczego porównanie wymaga czegoś więcej niż zestawienia obok siebie nagłówkowych wartości przepustowości.

Porównywalne zestawienie powinno zachować rozpoznawalny charakter obciążenia między silnikami. Te same prompty, długości odpowiedzi, reprezentacja modelu i warunki kontekstu powinny stanowić podstawę ćwiczenia. W przeciwnym razie pozorna przewaga oprogramowania może obejmować różnice w innych elementach konfiguracji.

Warunki pamięci podręcznej zasługują na równie równe traktowanie. Porównanie rozgrzanej sesji kodowania z nieznanym promptem stawia tę drugą w gorszej pozycji jeszcze przed rozpoczęciem generowania. Oba scenariusze są użyteczne, ale odpowiadają na różne pytania operacyjne i powinny być przedstawiane jako odrębne wyniki.

Konfiguracja sprzętowa również musi pozostać niezmienna, gdy różnice przypisuje się silnikowi. Szybsza karta lub większy budżet pamięci innego użytkownika tworzą dodatkową zmienną. Informacje te mogą ukierunkować dalsze badania, ale nie dowodzą, jaki wkład wnosi samo oprogramowanie.

Zachowanie wyjścia stanowi kolejną komplikację. Dekodowanie spekulatywne wykorzystuje tokeny robocze, które model sprawdza przed zaakceptowaniem wyniku. Każde porównanie obejmujące takie przyspieszenie powinno ujawniać jego ustawienia i weryfikować, jakie zachowanie zachowuje mierzona konfiguracja.

Istotnym standardem jest przejrzystość dotycząca dokładnego przebiegu testu. Czytelnicy powinni móc zidentyfikować artefakt modelu, rewizję oprogramowania, konfigurację i metodę pomiaru. Znana nazwa modelu nie gwarantuje identycznych reprezentacji numerycznych ani identycznych wyników.

Ta sama ostrożność dotyczy stwierdzeń o zastępowaniu hostowanych usług kodowania. Ten raport mierzy zachowanie lokalnego wnioskowania podczas sesji kodowania. Nie zawiera porównywalnej oceny ukończonych zadań, interwencji programisty, niezawodności usługi ani nakładu integracyjnego względem hostowanej alternatywy.

Dla opiekunów silników presja konkurencyjna pozostaje jednak realna w węższym znaczeniu. Obiecujący raport ze stacji roboczej daje użytkownikom powód, by zbadać wyspecjalizowane implementacje. Liczy się odpowiedź w postaci odtwarzalnych dowodów pokazujących, gdzie każdy silnik działa dobrze.

Dla programistów bardziej uzasadniona jest krótka lista niż ranking. Basalt zasługuje na testy na kompatybilnym sprzęcie, ponieważ zgłoszone stabilne szybkości są istotne dla pracy interaktywnej. Strata i llama.cpp pozostają kandydatami do porównań, których zachowanie wymaga pomiarów w tych samych warunkach.

Szybkie generowanie nie potwierdza jakości kodowania

Brakującym ogniwem jest wydajność zadań: raport mierzy szybkość generowania, nie ustalając, jak niezawodnie wygenerowany kod rozwiązuje problemy.

Sesja kodowania zapewnia bardziej rozpoznawalne obciążenie niż odizolowane generowanie tekstu. Pokazuje, że interfejs agenta wysyłał powtarzające się żądania. Jednak sama liczba żądań nie ujawnia udanych edycji, zaliczonych testów, niepotrzebnych ponowień ani korekt wprowadzonych przez człowieka.

To rozróżnienie staje się szczególnie ważne przy kwantyzacji. Zmniejszenie precyzji numerycznej zmienia wykonywaną reprezentację modelu. Szybsza lub mniejsza konfiguracja nadal wymaga oceny na zadaniach, które użytkownicy zamierzają jej powierzać.

Opublikowana ocena modelu skwantyzowanego oferuje ograniczone dowody jakości, wykorzystując fragmenty tekstu i punkt odniesienia o wyższej precyzji. To porównanie pomaga scharakteryzować zachowanie modelu. Nie potwierdza dokładności napraw repozytoriów, niezawodnego użycia narzędzi ani skutecznego kodowania z długim kontekstem.

Długi kontekst tworzy powiązaną lukę w weryfikacji. System może przyjąć długi prompt, nie stosując niezawodnie każdego istotnego szczegółu. Zdolność przetwarzania i dokładność wyszukiwania w obrębie tego wejścia to różne właściwości, nawet jeśli obie wpływają na to samo doświadczenie użytkownika.

Przegląd kontekstu wspiera zatem ograniczoną interpretację. Raportuje przepustowość dla nowych promptów o różnych długościach. Nie ustala, że model konsekwentnie odnalazł ukryte wymaganie, pogodził sprzeczne instrukcje lub zachował ograniczenia projektu podczas edycji kodu.

Zagregowane szybkości generowania pozostawiają również niejasny rozkład doświadczeń. Średnia może podsumować sesję, ukrywając wolniejsze żądania. Programista czekający na trudną edycję może bardziej przejmować się tymi opóźnieniami niż najlepszym krótkim przyspieszeniem.

To samo ograniczenie dotyczy mediany czasu rozpoczęcia odpowiedzi. Mediana opisuje środkową obserwację. Nie określa najdłuższych oczekiwań, zachowania po chybieniu pamięci podręcznej ani czasu potrzebnego na otrzymanie kompletnej, użytecznej poprawki.

Współbieżność, czyli równoczesne żądania, dodaje kolejną granicę. Brief wskazuje współbieżność na poziomie jednego. Czyni to wynik istotnym dla pojedynczego strumienia, ale nie daje podstaw do szacowania przepustowości zespołu ani wydajności przy nakładających się żądaniach agentów.

Luki te powinny kształtować interpretację, nie przekreślając zgłoszonego osiągnięcia. Źródło podaje jawne definicje pomiarów i rozdziela typy obciążeń. Te szczegóły sprawiają, że twierdzenia są łatwiejsze do oceny niż niewyjaśniony zrzut ekranu pokazujący wyłącznie maksymalną prędkość.

Niezależna reprodukcja powinna dodać wyniki zadań do obecnych kategorii przepustowości. Użyteczna ocena kodowania rejestrowałaby, czy testy przechodzą pomyślnie, czy zmiany spełniają żądanie oraz jak często interweniuje człowiek. Powinna zachowywać informacje o niepowodzeniach, zamiast raportować wyłącznie udane przebiegi.

W przypadku benchmarku Qwen3.8 Basalt nierozstrzygnięte pozostaje pytanie, czy zgłoszona responsywność idzie w parze z niezawodną pracą. Dopóki nie pojawią się porównywalne dowody dotyczące zadań, szybkość pozostaje dowodem na wykonanie, a nie dowodem, że konfiguracja zapewnia lepszego asystenta programistycznego.

Trzy sygnały określą, jak daleko zajdzie ten wynik

Kolejne dowody powinny ustalić odtwarzalność, niezawodność kodowania oraz wydajność w mniej sprzyjających warunkach działania — w tej kolejności.

Pierwszym sygnałem jest niezależna reprodukcja na porównywalnej stacji roboczej RTX 5080. Użyteczna publikacja obejmowałaby dokładny artefakt modelu, rewizję silnika, konfigurację, sekwencję żądań i surowe zapisy czasowe. Powtarzane przebiegi powinny odróżniać sesje intensywnie korzystające z pamięci podręcznej od nowych wejść.

Zbliżona reprodukcja wzmocniłaby argument, że ta konfiguracja oferuje powtarzalną opcję dla indywidualnych programistów. Znaczna różnica wymagałaby zbadania przed przypisaniem jej sprzętowi, oprogramowaniu lub obciążeniu. Każdy z tych wyników poprawiłby zasób dowodów dostępnych użytkownikom.

Reprodukcja powinna zachować pierwotne rozróżnienia pomiarowe. Średnia generowania dla sesji, średnia generowania dla żądań oraz szczyty jednosekundowe powinny pozostać oddzielone. Dopasowanie wyłącznie najwyższego zaobserwowanego skoku pozostawiłoby nierozstrzygnięte najważniejsze twierdzenie o stabilnej wydajności.

Drugim sygnałem jest ocena kodowania przy użyciu tej samej skwantyzowanej konfiguracji. Jej wartość wynikałaby z ukończonych zadań i zarejestrowanych korekt, a nie z kolejnego wykresu szybkości generowania. Ocena powinna obejmować kontekst projektu, którego agent faktycznie potrzebuje.

Silne wyniki zadań uczyniłyby raport dotyczący przepustowości bardziej znaczącym dla tworzenia oprogramowania. Częste niepowodzenia ograniczyłyby jego atrakcyjność, nawet gdyby generowanie pozostało szybkie. Szybsze tworzenie bezużytecznej poprawki nie zmniejsza pracy potrzebnej do ukończenia zadania.

Trzecim sygnałem jest wydajność w szerszym zestawie warunków działania. Istotne dowody obejmują nieznane długie prompty, dłuższe wyniki, zwykłe aplikacje programistyczne działające równolegle z wnioskowaniem oraz nakładające się żądania. Każdy warunek sprawdza, czy zgłoszone doświadczenie przetrwa zmianę obciążenia.

Stabilne zachowanie wzmocniłoby argument za użyciem konfiguracji poza starannie obserwowaną indywidualną sesją. Presja na pamięć, dłuższe oczekiwania lub pogorszony wynik wskazałyby jej praktyczne granice. Granice te pomogłyby użytkownikom dobierać obciążenia zamiast od razu odrzucać silnik.

Żaden z tych sygnałów nie wymaga wymyślania daty premiery ani przewidywania nieuniknionego zwycięzcy. Są to konkretne formy dowodów, które opiekunowie i niezależni użytkownicy mogą publikować w nadchodzących miesiącach. Obecny wpis stanowi użyteczny punkt wyjścia dla tej pracy.

Szersza implikacja pozostaje konkretna. Stacja robocza z 16 GB pamięci graficznej miała podobno utrzymywać interaktywne generowanie także dzięki wykorzystaniu znacznej ilości pamięci systemowej. To sprawia, że ocena całego systemu jest bardziej istotna niż ocenianie lokalnego wnioskowania wyłącznie przez pryzmat pojemności pamięci graficznej.

Przed zmianą konfiguracji porównaj benchmark Qwen3.8 Basalt z sesją pochodzącą z własnej pracy. Zachowaj prompty, odnotuj, co ponownie wykorzystuje pamięć podręczna, i zarejestruj, czy wynikowe edycje przechodzą Twoje kontrole. Uwzględnij aplikacje, które zwykle pozostawiasz otwarte, ponieważ zgłoszona maszyna miała ograniczoną ilość wolnej pamięci systemowej. Oddziel opóźnienie rozpoczęcia odpowiedzi od czasu ukończenia i porównuj stabilny wynik ze stabilnym wynikiem. Decyzja powinna zależeć od użytecznej pracy ukończonej w Twoich warunkach. Czy odtwarzalny przebieg może dostarczyć poprawne zmiany, akceptowalny czas oczekiwania i wystarczająco dużo wolnej pamięci dla reszty środowiska programistycznego?