Benchmark QEngine RTX 5090 raportuje 504 tok/s dzięki przewadze wynikającej z cache

Benchmark QEngine RTX 5090 raportuje 504 tokeny na sekundę dla Qwen3.8-Flash-Next, lecz ten szczytowy wynik wiąże się z warunkami, które zmieniają obraz konkurencji. Użytkownik LocalLLaMA przetestował QEngine 1.3.1 na dwóch kartach RTX 5090 i zgłosił znaczną przewagę w dekodowaniu pojedynczego strumienia, czyli szybkości generowania w jednej rozmowie. To samo porównanie stawia QEngine mniej więcej na równi ze Strata w teście opóźnienia promptu agenta, podczas gdy Strata szybciej przetwarza dłuższy prompt benchmarkowy.

Tester, publikujący jako Relative-Ant-9249, przypisuje zasługi deweloperowi bpx03 i wyraźnie zaznacza, że QEngine jest projektem kogoś innego. Jego benchmark lokalnej inferencji porównuje kilka silników na tej samej stacji roboczej. Czyni to raport użytecznym, choć nadal pozostaje on porównaniem przeprowadzonym przez użytkownika, bez niezależnej replikacji.

Główny kompromis jest już widoczny: najszybszy strumień wyjściowy nie zapewnia automatycznie najkrótszego oczekiwania podczas całej rozmowy. Powtarzane prompty sprzyjają adaptacyjnemu cache QEngine, długie wejścia sprzyjają Strata w zgłoszonym teście, a utrzymywanie bezczynnych rozmów dodatkowo zmienia opóźnienia. Deweloperzy wybierający między tymi silnikami muszą określić, które opóźnienie faktycznie przerywa ich pracę.

Co faktycznie zmierzono w benchmarku QEngine RTX 5090

Wynik 504 tok/s dotyczy konkretnego obciążenia, konfiguracji pamięci i wersji oprogramowania. Nie jest ani średnią z całego porównania, ani gwarancją dla każdej odpowiedzi.

Stacja robocza zawiera dwie karty RTX 5090, każdą z 32 GB pamięci wideo, oraz procesor Threadripper PRO 3975WX. Tester podaje 251 GB pamięci RAM systemu i skonfigurowany kontekst o wielkości około 262 000 tokenów. Tokeny to jednostki tekstu przetwarzane i generowane przez model, a nie bezpośrednia liczba słów.

QEngine używał kompilacji Flash-Next INT4 AutoRound, skompresowanej reprezentacji modelu wykorzystującej czterobitowe wagi całkowitoliczbowe. Tester twierdzi, że zmienił docelową architekturę kompilacji CUDA z 86 na 120, używając nvcc 13.3 i g++-13. Nie zgłasza innych zmian w źródłach ani 53-sekundowego odstępu między uruchomieniem a obsługą żądań.

To zachęcający raport o przenośności, choć udana kompilacja nie potwierdza ogólnego wsparcia sprzętowego. Pokazuje, że temu użytkownikowi udało się uruchomić tę kompilację na tej maszynie. Nie dowodzi równoważnego działania na innych płytach głównych, sterownikach, konfiguracjach pamięci ani środowiskach operacyjnych.

Test rozdziela generowanie tekstu narracyjnego od kodu, a to rozróżnienie ma znaczenie w całych wynikach. Przy domyślnej konfiguracji QEngine miał generować tekst narracyjny z szybkością 370 tok/s, a kod z szybkością 439 tok/s. Przeniesienie cache rozmów do RAM systemowego podniosło te wyniki odpowiednio do 406 i 504 tok/s.

Konfiguracja ISTA IQ3_S Strata miała osiągać 214 tok/s dla tekstu narracyjnego i 293 tok/s dla kodu. Konfiguracja UD-IQ4_XS uzyskała 180 i 239 tok/s. Są to różne skompresowane kompilacje modelu, co uniemożliwia traktowanie porównania jako czystego pomiaru implementacji silnika.

Dostrojona konfiguracja bucko vLLM osiągnęła 135 tok/s dla tekstu narracyjnego i 141 tok/s dla kodu. Jej dostarczana konfiguracja zmierzyła 120 i 118 tok/s. Tester wymienia także konfigurację Infernix na poziomie 14–18 tok/s, bez odpowiadającego pomiaru przetwarzania promptu.

Liczby te wskazują na istotną zgłoszoną różnicę na tej stacji roboczej. Ustalają też granice nagłówka: 504 tok/s to najwyższy wymieniony wynik generowania kodu. Wynik tego samego silnika dla tekstu narracyjnego jest niższy, a jego domyślna konfiguracja pamięci jest wolniejsza niż konfiguracja RAM.

Raport podaje, że wszystkie silniki używały tego samego skryptu benchmarkowego i promptów. Powiązane społecznościowe receptury serwowania zapewniają kontekst dla ekosystemu testowego, choć odnośnik do projektu benchmarkowego nie potwierdza niezależnie przesłanego wyniku.

Najbardziej uzasadniony opis jest zatem konkretny. QEngine 1.3.1 prowadził wśród konfiguracji testowanych przez tego użytkownika w generowaniu pojedynczego strumienia, a jego najwyższy zgłoszony wynik wystąpił przy kodzie. Szersze twierdzenia o najszybszym dostępnym silniku wymagają pełniejszej stawki i powtarzalnych, niezależnych testów.

Powtarzane prompty utrudniają uogólnienie przewagi w generowaniu

Zgłoszona przewaga QEngine jest istotna, lecz benchmark nagradza także zachowanie, którego zwykły ruch może nie odtworzyć. Tester bezpośrednio wskazuje to ograniczenie, co czyni je kluczowym dla interpretacji wyniku.

Według wpisu cache ekspertów QEngine dostosowuje się do niedawnego użycia. Cache ekspertów przechowuje często potrzebne części modelu, aby silnik mógł uzyskać do nich dostęp bez wielokrotnego pobierania ich z innych miejsc. Powtarzanie tych samych promptów zapewnia temu mechanizmowi korzystne obciążenie.

Ma to znaczenie, ponieważ benchmark powtarza prompty między uruchomieniami. Niedawne użycie staje się wtedy użytecznym predyktorem przyszłego użycia, co może ograniczyć przemieszczanie danych modelu. Wynikowa szybkość generowania opisuje korzystny stan pracy, a nie każdą możliwą rozmowę.

Tester przeciwstawia temu cache Strata, który według niego już przechowuje około 99,5% masy kierowanych ekspertów. W jego opisie powtórzenie promptu zapewnia więc Strata mniejszą dodatkową korzyść. To wyjaśnienie pochodzi od testera i nie zostało tu niezależnie potwierdzone.

Wpis podaje także wcześniejszą obserwację z różnorodnego ruchu: około 300–400 tok/s dla pojedynczego strumienia. Żądania w obciążeniu agenta testera miały mieścić się w zakresie 330–470 tok/s. Wyniki te nadal są szybkie, lecz sprawiają, że nagłówek o 504 tok/s wygląda bardziej na korzystny przypadek niż typowe oczekiwanie.

Tytuł opisuje przewagę około 1,5–1,9 raza nad kolejnym najlepszym testowanym silnikiem. Treść używa nieco szerszego szacunku, wynoszącego około 1,4–1,9 raza względem Strata po uwzględnieniu różnic w obciążeniu. Żaden z tych zakresów nie powinien stać się uniwersalnym mnożnikiem stosowanym do niepowiązanego sprzętu lub promptów.

W tym miejscu QEngine vs Strata staje się kwestią obciążenia. Deweloper wielokrotnie generujący podobny kod może skorzystać z innego wzorca cache niż osoba przełączająca się między niepowiązanymi dokumentami. Źródło nie ustala, jak długo którykolwiek wzorzec musi się utrzymywać, zanim zmierzona przewaga się zmieni.

Przydatne niezależne porównanie zachowałoby oba warunki. Powtarzane prompty pokazują, co silnik może zrobić, gdy ostatnia aktywność przewiduje przyszłe zapotrzebowanie. Zróżnicowane prompty ujawniają, jak dobrze radzi sobie z mniej sprzyjającą sekwencją żądań.

Żaden z warunków nie zasługuje na automatyczną preferencję w każdej ocenie. Powtarzalność może reprezentować rzeczywistą aplikację ze wspólnymi instrukcjami i powracającymi zadaniami. Różnorodność może reprezentować osobistego asystenta przechodzącego między programowaniem, badaniami, przeglądem dokumentów i nieznanymi projektami.

Praktyczny problem pojawia się, gdy korzystny warunek znika z nagłówka. Czytelnik, który widzi wyłącznie 504 tok/s, może oczekiwać takiej szybkości natychmiast po zmianie zadania. Dostępne dowody nie uzasadniają takiego oczekiwania.

Benchmark QEngine RTX 5090 wywiera więc presję na konkurencyjne silniki, aby wyjaśniały swoje zachowanie w porównywalnych warunkach cache. Wywiera też presję na autorów benchmarków, aby jasno ujawniali te warunki. Bez tego ujawnienia ranking wydajności może ukrywać powód, dla którego ranking istnieje.

Dla kupujących i deweloperów istotne pytanie brzmi, jak często ich rzeczywista praca przypomina powtarzany benchmark. Odpowiedź określa, jaką wagę należy przypisać szczytowemu wynikowi. Nieco niższa szybkość o stałym zachowaniu może lepiej obsługiwać niektóre przepływy pracy niż wyższa szybkość z większymi wahaniami.

Strata pozostaje konkurencyjna, zanim rozpocznie się odpowiedź

Przewaga QEngine w generowaniu nie przekłada się na wyraźną przewagę w całym żądaniu. Zgłoszone wyniki przetwarzania promptów dają Strata silniejszą pozycję wraz ze wzrostem długości wejść.

Prefill oznacza przetwarzanie wejścia, zanim model zacznie generować odpowiedź. Przy około 10 000 tokenów wejściowych domyślna konfiguracja QEngine miała przetwarzać około 5 700 tok/s. Jej konfiguracja z cache w RAM osiągnęła około 6 200 tok/s przy tej długości wejścia.

Konfiguracja ISTA IQ3_S Strata miała przetwarzać około 5 100 tok/s przy krótszym wejściu. Przy około 90 000 tokenów osiągnęła jednak około 10 000 tok/s. Domyślna konfiguracja QEngine zmierzyła około 7 300 tok/s przy tym dłuższym wejściu.

Wpis nie podaje odpowiadającego wyniku prefill dla 90 000 tokenów dla konfiguracji QEngine z RAM. Ten brakujący wynik powinien pozostać brakujący, zamiast być wywnioskowany z jej wydajności przy krótszym wejściu. Dostępne pomiary wspierają podzielony wynik: QEngine prowadzi przy krótszym prompcie, a Strata przy dłuższym.

To rozróżnienie ma bezpośrednie zastosowanie dla asystentów programistycznych. Asystent pracujący na podstawie niewielkiej, niedawnej wymiany poświęca inną część czasu na czytanie niż asystent analizujący duży kontekst repozytorium. Szybsze generowanie pomaga obu, ale nie eliminuje czasu poświęcanego na przetwarzanie ich wejść.

Test agenta dodaje kolejną istotną granicę. Obejmuje 12-turową sekwencję użycia narzędzi z kontekstem rosnącym do około 35 000 tokenów. Przy działającym cache prefiksów QEngine 1.3.1 miał odczytać prompt ostatniej tury w 1,75 sekundy.

Cache prefiksów oznacza ponowne wykorzystanie obliczeń dla niezmienionego początku promptu. Odpowiadający wynik Strata wyniósł 1,7–1,9 sekundy, co umieszcza QEngine w tym zgłoszonym zakresie. Tester trafnie opisuje oba silniki jako porównywalne w tym pomiarze.

Dostrojona konfiguracja bucko zajęła 4,36 sekundy w tym samym zgłoszonym porównaniu. Ustala to różnicę między tymi testowanymi konfiguracjami, lecz nie ustala wyniku dla każdego wdrożenia vLLM. Konfiguracja, reprezentacja modelu i obciążenie nadal są częścią porównania.

Ważne jest także, że zgłoszona liczba mierzy etap odczytywania promptu. Nie mierzy pełnego czasu potrzebnego na wykonanie narzędzi, sprawdzenie wyników, wygenerowanie kolejnych instrukcji i ukończenie zadania. Szybki etap może usprawnić agenta, nie determinując jednak całkowitego czasu realizacji zadania.

QEngine vs Strata nie ma więc jednego zwycięzcy we wszystkich ujawnionych pomiarach. QEngine prowadzi w generowaniu, podczas gdy Strata pozostaje konkurencyjna w promptach agenta z cache i silniejsza w zgłoszonym teście prefill dla długich wejść. To użyteczniejszy wniosek niż sprowadzenie wszystkiego do tokenów wyjściowych na sekundę.

Dla zespołów utrzymujących lokalnych asystentów presja ma charakter operacyjny. Muszą ustalić, czy użytkownicy najczęściej czekają na przetwarzanie wejścia, generowanie odpowiedzi czy narzędzia zewnętrzne. Zmiana silnika wpływa tylko na te części czasu oczekiwania, które silnik faktycznie kontroluje.

Wynik podważa również sposób prezentowania demonstracji lokalnej inferencji. Strumień szybko pojawiającego się kodu łatwo pokazać i łatwo zrozumieć. Cichsze opóźnienie przed rozpoczęciem tego strumienia może mieć równie duże znaczenie podczas powtarzanych interakcji z narzędziami.

Utrzymywanie bezczynnych rozmów w RAM zmienia inny rodzaj oczekiwania

Najbardziej praktycznym wynikiem może być odzyskiwanie starszych rozmów, a nie najwyższa szybkość generowania. Konfiguracja QEngine z RAM miała zachowywać użyteczny stan mimo pośredniego ruchu.

Pamięć podręczna KV przechowuje klucze i wartości związane z mechanizmem uwagi, umożliwiając modelowi ponowne wykorzystanie obliczeń z wcześniejszych tokenów. W tym teście QEngine mógł przechowywać tę pamięć w przypiętej pamięci RAM systemu, czyli pamięci hosta zarezerwowanej dla przewidywalnych transferów. Tester podaje pulę 13,5 GB, odpowiadającą w przybliżeniu milionowi tokenów łącznej pojemności pamięci podręcznej.

Rozmiar tej puli różni się od skonfigurowanego limitu kontekstu pojedynczej rozmowy. Łączna pojemność opisuje, ile stanu rozmów pula może zachować między sesjami. Nie oznacza to, że benchmark testował jedną rozmowę zawierającą milion tokenów.

Eksperyment z bezczynnymi sesjami rozpoczął się od ośmiu rozmów po około 58 000 tokenów każda. Następnie tester przesłał około 400 000 tokenów innego ruchu, zanim wrócił do pierwotnych rozmów. Ta sekwencja sprawdza, czy wcześniejsza praca pozostaje gotowa po tym, jak maszyna obsłuży coś innego.

Przy pamięci podręcznej w RAM wszystkie osiem rozmów podobno wróciło w stanie warm, co oznacza, że ich zachowany stan nadal nadawał się do ponownego użycia. Czas do pierwszej odpowiedzi wynosił od 1,56 do 2,01 sekundy. Mierzy to opóźnienie, którego użytkownicy doświadczają przy ponownym otwieraniu pracy, a nie późniejszą szybkość strumienia odpowiedzi.

Przy pamięci podręcznej w pamięci wideo tylko dwie rozmowy podobno pozostały warm. Pozostałe sześć wymagało ponownego przetworzenia wejścia, co zajęło 8,7–9,4 sekundy. Tester podaje odniesienie dla zimnego startu na poziomie 8,85 sekundy, dzięki czemu praktyczna konsekwencja jest łatwa do zauważenia.

Deweloper przechodzący między trwającymi projektami rozpoznałby ten wzorzec. Jedna rozmowa zawiera analizę debugowania, inna przegląd implementacji, a kolejna śledzi odrębną funkcję. Istotną korzyścią jest zachowanie już przetworzonej pracy, gdy uwaga przenosi się gdzie indziej.

To samo rozróżnienie ma znaczenie w przypadku przeszukiwalnej bazy wiedzy. Znalezienie właściwych materiałów i wznowienie wcześniejszych obliczeń modelu to odrębne problemy, choć oba wpływają na to, jak szybko ktoś wraca do użytecznej pracy.

Źródło podaje, że odpowiedzi pozostawały poprawne, gdy konfiguracja pamięci wideo musiała ponownie przetworzyć stare wejście. Zaobserwowaną karą było opóźnienie, a nie udokumentowana utrata poprawności odpowiedzi. To rozróżnienie zapobiega traktowaniu każdego chybienia pamięci podręcznej jako awarii rozumowania.

Istnieje również kompromis związany z współbieżnością, gdzie współbieżność oznacza obsługę wielu strumieni jednocześnie. Przy ośmiu współbieżnych strumieniach i kontekstach po 64 000 tokenów konfiguracja RAM podobno osiągała 124 tok/s na strumień. Konfiguracja pamięci wideo osiągnęła 139 tok/s na strumień.

Tester podsumowuje to jako około 10% wolniejsze działanie przy tym współbieżnym obciążeniu, mimo poprawy pojedynczego strumienia o około 10%. Ujawnia też, że przeprowadzono jeden rozruch na tryb i jedno przejście. To wystarcza, by wskazać kompromis wart zbadania, ale nie wystarcza do ustalenia jego pełnego rozkładu.

Szersza kwestia techniczna wykracza poza ten silnik. Dokumentacja hybrydowej pamięci podręcznej opisuje obsługę specyficzną dla Flash-Next i ogranicza deklarowaną walidację do generowania tekstu. Obsługa modeli, zachowywanie stanu i zakres obciążeń wymagają wyraźnej uwagi, a nie założeń opartych na nazwie produktu.

Dla indywidualnego asystenta zachowanie bezczynnej pracy może przeważać nad niższą współbieżną szybkością generowania. W przypadku współdzielonej usługi równowaga może się odwrócić. Opisane wyniki sprawiają, że obie możliwości warto ocenić, nie ustanawiając żadnej z nich wyborem domyślnym.

Kontrole jakości i konkurencyjne silniki ograniczają tezę o zwycięstwie

Raport uzasadnia dalsze testy QEngine, a nie stwierdzenie, że tworzy lepsze odpowiedzi lub pokonuje każdą alternatywę. Własne kontrole jakości i wątek dyskusji wyznaczają te granice.

Test asystenta podobno zwrócił 44 udane zadania na 44 w QEngine 1.3.1. Wcześniejsze uruchomienia 1.3 zwróciły 42 na 44 przy niskim wysiłku. Tester ostrożnie traktuje tę niewielką różnicę, zamiast przedstawiać ją jako potwierdzoną poprawę jakości.

Porównanie kodowania wymaga jeszcze ostrożniejszego przypisania wersji. Wersja kandydująca do wydania zwróciła 26 udanych zadań na 30 w zestawie testowym kodowania testera. Konfiguracje Strata zwróciły 24 i 25, podczas gdy powtarzane wyniki dla jednej konfiguracji mieściły się w przedziale od 24 do 26.

Tester wyraźnie zaznacza, że kontrola kodowania nie została ponownie uruchomiona na 1.3.1. Nie może więc służyć jako bezpośrednie potwierdzenie jakości dokładnej wersji stojącej za nagłówkiem. Dostarcza kontekstu dotyczącego wcześniejszej wersji i zaobserwowanej zmienności porównania.

Rozsądny wniosek jest taki, że te ograniczone kontrole nie ujawniły oczywistej wady QEngine w kodowaniu przy skompresowanym modelu. Nie potwierdzają one równej jakości we wszystkich zadaniach. Nie pokazują też, że poprawa szybkości generowania zachowuje każde zachowanie potrzebne aplikacji produkcyjnej.

Kwantyzacja, czyli kompresja numerycznych wag modelu, dodatkowo komplikuje porównanie silników. Różne skompresowane kompilacje mogą zmieniać zarówno wydajność, jak i wyniki. Benchmark porównujący kompletne konfiguracje wdrożeniowe odpowiada na praktyczne pytanie, ale nie izoluje każdej przyczyny wpływającej na rezultat.

Pole konkurencyjne również jest niepełne. W dyskusji deweloper Basalt sugeruje przetestowanie silnika zaprojektowanego specjalnie dla sprzętu NVIDIA Blackwell. Deweloper podaje wydajność z innej maszyny i benchmarku, więc tych wartości nie można włączyć do pierwotnego rankingu.

Mimo to istnienie obsługi inferencji Blackwell ma znaczenie przy interpretowaniu określenia „najszybszy silnik”. QEngine prowadził wśród konfiguracji zmierzonych przez autora posta. Nietestowana alternatywa pozostaje nietestowana, niezależnie od tego, czy jej deweloper podaje obiecujące liczby w innym miejscu.

Wątek źródłowy zawiera również entuzjastyczne reakcje użytkowników i prośby o pomoc w konfiguracji. Reakcje te wskazują na zainteresowanie, lecz ani entuzjazm, ani anegdota nie odtwarzają niezależnie benchmarku. Druga stacja robocza wymaga udokumentowanego testu, zanim doświadczenie jej właściciela będzie mogło potwierdzić to samo twierdzenie o wydajności.

Dryf wersji tworzy kolejny problem weryfikacyjny. W chwili sprawdzania repozytorium kodu źródłowego QEngine opisuje wersję 1.3.2 i dodatkowe funkcje Flash-Next. Tych obecnych opisów nie należy wstecznie przypisywać testowanej kompilacji 1.3.1.

Repozytorium określa projekt jako source-available i dokumentuje koncentrację na sprzęcie RTX 3090. Jego uwagi dotyczące kompilacji nadal wskazują architekturę 86 i opisują inne modele GPU jako nieprzetestowane. To sprawia, że kompilacja autora posta dla 5090 jest użytecznym dowodem indywidualnego wyniku, a nie ogólnym zobowiązaniem dotyczącym kompatybilności.

Niezależne odtworzenie powinno zatem zachować rzeczywistą rewizję oprogramowania, pliki modelu, wybory kompilatora i konfigurację uruchomienia. Aktualizacja wszystkiego do najnowszej wersji mogłaby przynieść interesujący wynik, ale odpowiadałaby na inne pytanie. Odtwarzalność zależy od zachowania tego, co zostało zmierzone.

Presja na QEngine polega teraz na przekształceniu obiecującego raportu użytkownika w niezawodny wzorzec działania. Presja na konkurentów polega na odpowiedzi porównywalnymi obciążeniami i przejrzystymi konfiguracjami. Żadne z tych zadań nie zostaje spełnione przez opublikowanie większej liczby z niepowiązanego sprzętu.

Trzy wyniki uczyniłyby następne porównanie bardziej użytecznym

Kolejnym użytecznym dowodem jest bardziej odtwarzalne porównanie między obciążeniami, a nie kolejny odizolowany rekord. Trzy konkretne sygnały wzmocniłyby lub osłabiły interpretację tego raportu.

Po pierwsze, warto obserwować niezależne odtworzenie na innej dwukartowej stacji roboczej RTX 5090. Użyteczny wynik wskazałby dokładną rewizję QEngine i kompilację modelu, a następnie podał wyniki zarówno dla powtarzanych, jak i zróżnicowanych promptów. Odtworzenie istotnej przewagi w generowaniu w obu warunkach wzmocniłoby argument, że korzyść wykracza poza pierwotną maszynę.

Mniejsza przewaga przy zróżnicowanych promptach zawęziłaby ten argument, nie czyniąc pierwotnego pomiaru bez znaczenia. Pokazałaby, że niedawna historia obciążenia odpowiada za większą część zaobserwowanego wyniku. Ta informacja pomogłaby użytkownikom wybrać silnik na podstawie własnego ruchu.

Niezależne testowanie powinno również zachować rozróżnienie między wynikiem narracyjnym a wynikiem kodu. Połączenie ich w jedną średnią ukryłoby różnicę, którą pierwotny raport już ujawnia. Raportowanie ich oddzielnych wyników daje czytelnikom większą szansę dopasowania benchmarku do ich aplikacji.

Po drugie, warto obserwować porównanie na tej samej maszynie, obejmujące alternatywę skoncentrowaną na Blackwell, taką jak Basalt. Wynik pierwotnego autora posta nie ustala miejsca tego silnika w rankingu. Przetestowanie go w tych samych warunkach odpowiedziałoby na konkretną lukę wskazaną w dyskusji.

Wiarygodne porównanie ujawniłoby różnice w skompresowanych kompilacjach modelu i ustawieniach jakości. Powinno też uwzględniać opóźnienie przetwarzania promptów i zachowanie wznawianej sesji obok szybkości generowania. W przeciwnym razie nowy zwycięzca odziedziczyłby tę samą niejednoznaczność co stary nagłówek.

Jeśli QEngine zachowa prowadzenie w tym rozszerzonym polu, twierdzenie konkurencyjne stanie się mocniejsze. Jeśli inny silnik dorówna w generowaniu, jednocześnie poprawiając opóźnienie długiego wejścia lub wznawianej sesji, wybór stanie się bardziej zależny od zachowania aplikacji. Każdy z tych wyników byłby bardziej informacyjny niż porównywanie niekompatybilnych zrzutów ekranu.

Po trzecie, warto obserwować powtarzane testy mieszanego obciążenia dotyczące zachowywania bezczynnych sesji i współbieżnego generowania. Opisany wynik RAM jest atrakcyjny, ponieważ dotyczy przerwy między sesjami pracy. Spowolnienie współbieżne pokazuje, dlaczego tę korzyść trzeba ocenić przy utrzymującym się użyciu.

Powtarzane uruchomienia ujawniłyby, czy odzyskiwanie sesji warm pozostaje spójne, gdy rozmowy się gromadzą i aktywność się zmienia. Pokazałyby również, jak często silnik ponownie przetwarza stare wejście, napotyka błędy lub zmniejsza szybkość na strumień. Te pomiary przetestowałyby praktyczną wartość stojącą za konfiguracją pamięci.

Spójne odzyskiwanie przy akceptowalnej wydajności współbieżnej wzmocniłoby argument za stanem rozmowy opartym na RAM. Częsta zmienność lub większe spowolnienie zawęziłyby jego atrakcyjność do lżejszych obciążeń. Żaden z wyników nie wymaga udawania, że każdy lokalny asystent obsługuje ten sam wzorzec żądań.

Dla deweloperów rozważających zmianę benchmark QEngine RTX 5090 dostarcza wiarygodnego powodu do zbadania tematu, wraz z wyjątkowo wyraźnymi ograniczeniami. Jego największy wkład polega na pokazaniu, że szybkość generowania, opóźnienie promptu i odzyskiwanie rozmowy mogą zmieniać się w różnych kierunkach.

Przed zastąpieniem istniejącego silnika porównaj oczekiwania, których faktycznie doświadczają użytkownicy. Zachowaj reprezentatywną długą rozmowę, wprowadź niepowiązany ruch i zmierz, co dzieje się po wznowieniu pierwotnej pracy. Uwzględnij zróżnicowane zadania obok powtarzanych promptów i zachowaj kontrole jakości odzwierciedlające pracę, którą musisz ukończyć. Zapisz testowaną wersję i konfigurację, aby późniejsze aktualizacje nie zatarły znaczenia porównania. Benchmark QEngine RTX 5090 przedstawia przekonujący argument za taką oceną, pozostawiając jednak ostateczny wybór zależny od dowodów z Twojego obciążenia. Czy Twój asystent spędza więcej czasu na generowaniu odpowiedzi, czytaniu rosnącego promptu czy odzyskiwaniu rozmowy, którą — jak oczekiwano — miał pamiętać?