Tak — Qwen3-235B-A22B Q5_K_M ukończył nasze testy na jednej karcie GPU z pomocą CPU i RAM. W kontrolowanym pomiarze generował średnio 4,7 tokena/s, czyli fragmentów tekstu na sekundę. Osobno wykonaliśmy trzy krótkie zadania z widoczną odpowiedzią końcową.
To największy wariant sprawdzony w tej kampanii, nie deklaracja maksymalnego modelu dla tego serwera. Jego pliki zajmują 155,4 GiB, więc nie mieszczą się w pamięci samej karty. Podział obliczeń otwiera taką możliwość, ale trzeba jeszcze ocenić czas odpowiedzi i sposób wykorzystania pamięci.
Pomiar szybkości, użycie pamięci i praktyczne odpowiedzi to osobne sprawdziany. Ich znaczenie wyjaśnia wspólna metodyka testów LLM; ustawienia tej serii zachowujemy w szczegółach poniżej.
Jak duży model może korzystać z jednej karty?
235B oznacza około 235 miliardów parametrów, czyli danych opisujących model — nie 235 GB pamięci. Ten model ma konstrukcję MoE: składa się z wielu części nazywanych ekspertami, a przy kolejnym kroku obliczeń wybierana jest tylko część z nich.
To zmniejsza pracę wykonywaną w jednym kroku, lecz nie usuwa potrzeby dostępu do pozostałych danych. W naszym ustawieniu część obliczeń eksperckich trafiała do CPU i RAM, a reszta korzystała z GPU. Dlatego dużej liczby parametrów nie należy automatycznie utożsamiać ani z większą szybkością, ani z lepszą odpowiedzią.
Co oznacza to dla pamięci serwera?
Podczas mierzonych odpowiedzi najwyższe odczyty wyniosły 87,7 GiB pamięci karty i 51,5 GiB RAM przypisanego procesowi modelu. To pokazuje rzeczywiste zaangażowanie obu rodzajów pamięci, ale nie ich wspólny, jednoczesny szczyt. Przy ładowaniu sam proces potrzebował więcej RAM: najwyższy odczyt sięgnął 80,6 GiB. System i inne programy również potrzebują własnego miejsca.
W praktyce warto więc sprawdzić cały cykl: uruchomienie, przyjęcie tekstu i ukończenie odpowiedzi. Sam rozmiar plików nie mówi, ile pamięci pozostanie dla aplikacji, która ma pracować obok modelu. Ten wariant udało się uruchomić na stanowisku, ale nie wyznacza to bezpiecznej granicy dla dowolnie długich dokumentów czy kilku klientów jednocześnie.
Trzy przykłady: wynik, czas i format odpowiedzi
Sprawdziliśmy proste działanie arytmetyczne, wyciągnięcie wskazanych pól z tekstu i przypisanie kategorii. JSON to zapis danych w polach, który aplikacja może odczytać automatycznie. W każdym zadaniu prosiliśmy o sam obiekt JSON, bez dodatkowego formatowania.
| Zadanie | Pierwszy widoczny tekst | Ukończona odpowiedź | Sam JSON zgodnie z poleceniem |
|---|---|---|---|
| Arytmetyka | 4,4 s | 7,5 s | Nie — dodany blok Markdown |
| Wyciągnięcie pól z tekstu | 6,5 s | 10,5 s | Tak |
| Przypisanie kategorii | 6,2 s | 9,0 s | Nie — dodany blok Markdown |
Wartości odpowiedzi były poprawne we wszystkich trzech zadaniach. Ścisły test formatu zaliczył jeden wynik: pozostałe dwa model otoczył znacznikami bloku kodu Markdown. To różnica istotna dla automatyzacji, nie błędne wyliczenie czy kategoria. Każde zadanie wykonaliśmy raz; trzy przykłady nie stanowią rankingu jakości modelu. Osobny przegląd formatu odpowiedzi zachowuje rozróżnienie między poprawną wartością a zgodnością formatu.
Przykład z działaniem arytmetycznym dobrze pokazuje różnicę między rozmową a aplikacją. Człowiek bez trudu przeczyta poprawny wynik w ramce kodu. Program oczekujący wyłącznie określonych pól może taki wynik odrzucić. Przy własnym wdrożeniu warto więc z góry określić, co ma zostać zwrócone, i sprawdzać odpowiedź przed zapisaniem jej do systemu.
Kiedy takie rozwiązanie ma sens?
Do eksperymentów z większym modelem i zadań wykonywanych w kolejce — tak, jeśli czas odpowiada potrzebom aplikacji. Przykładem może być przygotowanie roboczego podsumowania dokumentu do późniejszej weryfikacji. To propozycja zastosowania, a nie wykonany tu test jakości podsumowań.
Do płynnego czatu albo obsługi wielu osób naraz nie wybieralibyśmy tej konfiguracji bez dalszych pomiarów. Pracował jeden klient, a dłuższa odpowiedź wymaga więcej czasu. Krótkie zadania z tabeli nie są odpowiedziami o długości 256 tokenów z testu szybkości.
Rozsądny następny krok to wybrać własny dokument i kryterium powodzenia: poprawne pola, zgodność podsumowania z tekstem albo trafna kategoria. Potem porównać wynik z mniejszym modelem, który mieści się na GPU. Jeżeli oba wykonują zadanie równie dobrze, krótszy czas może być ważniejszy niż większa liczba parametrów. Jeżeli większy model daje potrzebną przewagę, pomiar pokaże, jaki koszt oczekiwania jest akceptowalny. W tej publikacji nie mierzyliśmy jeszcze takiej przewagi jakościowej.
Ocena: większy model rzeczywiście może działać na jednym serwerze, korzystając z GPU i RAM. Zaletą jest dostęp do takiego wariantu; kosztem są czas generowania, wymagania pamięci i konieczność kontroli formatu odpowiedzi w aplikacji. Praktyczność zależy od konkretnego zadania, nie od samego „235B”.
Zobacz porównanie modelu 72B na GPU i z RAM, zobacz pozostałe sprawdzone modele lub opisz swoje zastosowanie. Konfigurację serwera znajdziesz w ofercie.
Szczegóły techniczne
Model, silnik i stanowisko
Użyliśmy Qwen3-235B-A22B-GGUF w przypiętej rewizji, format Q5_K_M, sześć plików wag o łącznej wielkości 155,4 GiB. To rozmiar plików, nie pomiar pamięci procesu. Model jest udostępniony na licencji Apache 2.0.
| Element | Konfiguracja pomiaru |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96 GB VRAM |
| Procesor | AMD EPYC 4565P, 16 rdzeni i 32 procesory logiczne |
| RAM systemowy stanowiska | 96 GB |
| Sterownik NVIDIA | 595.91.07 |
| Silnik | llama.cpp 0.5.0-dev, wydanie b11146 |
| Podział obliczeń | Żądane obliczenia eksperckie 44 warstw po stronie CPU; pozostała część na GPU |
| Wejście / odpowiedź syntetyczna | 2048 lub 8192 tokeny / 256 tokenów |
| Równoległość | Jedno zapytanie i jeden slot serwera |
| Powtórzenia syntetyczne | Jedna osobna rozgrzewka, następnie trzy mierzone odpowiedzi dla każdego wejścia |
| Zadania praktyczne | Trzy różne zadania po jednej próbie; limit odpowiedzi 1024 tokeny |
| Pula kontekstu | 8704 tokeny; KV cache F16 i Flash Attention |
| CPU / batch / ubatch | 16 wątków / 2048 / 512 |
| Limit mocy GPU i chłodzenie | 300 W; automatyczne sterowanie wentylatorami obudowy |
Silnik miał rewizję 7fe450e19305b828c199d602c23a8337aaa1f03b. Użyto mmap bez mlock; cache promptu, przesuwanie kontekstu, automatyczne dopasowanie pamięci i tryb lazy były wyłączone. Dla tego modelu wyłączono tryb thinking. Log podaje 95/95 warstw na GPU, lecz osobne ustawienie eksperckie kieruje część obliczeń na CPU — sam licznik warstw nie oznacza więc modelu pracującego wyłącznie na GPU. Bufory CPU i CUDA są przydziałami silnika, nie pomiarem rezydentnego RAM.
Szybkość przy dwóch długościach wejścia
| Tokeny wejścia | Pierwszy token — mediana | Cała odpowiedź — mediana | Generowanie — średnia | CPU procesu — średni udział mocy obliczeniowej serwera |
|---|---|---|---|---|
| 2048 | 16,5 s | 70,6 s | 4,7 tokena/s | 38,1 % |
| 8192 | 51,5 s | 105,6 s | 4,7 tokena/s | 26,6 % |
Każda grupa zawiera trzy mierzone odpowiedzi po 256 tokenów. W tej tabeli czas pierwszego tokena dotyczy syntetycznego strumienia testowego. W przykładach praktycznych powyżej mierzymy pierwszy widoczny tekst odpowiedzi końcowej; inne wejścia i długości wyjścia nie pozwalają porównywać tych czasów bezpośrednio.
Generowanie to średnia szybkość decode silnika, nie szybkość liczona z całego czasu odpowiedzi. W wydaniu b11146 licznik obejmuje 255 kroków decode dla 256 tokenów wyjścia, bo pierwszy token powstaje podczas przetwarzania wejścia. CPU jest średnim udziałem procesu w całkowitej pojemności 32 procesorów logicznych. To test szybkości i uruchomienia, nie ocena jakości odpowiedzi generowanych w próbach syntetycznych.
Ile pamięci zajmował model?
Najwyższa próbka VRAM z połączonych okien sześciu odpowiedzi syntetycznych wyniosła 87,7 GiB. Najwyższy PSS procesu, czyli jego rezydentna pamięć RAM z proporcjonalnym rozliczeniem obszarów współdzielonych, wyniósł w tych oknach 51,5 GiB. Dla całego przebiegu, obejmującego również ładowanie i rozgrzewkę, maksimum PSS wyniosło 80,6 GiB. To różne zakresy, nie sprzeczne odczyty.
Nie dodajemy tych wartości, aby dowodzić, że wszystkie 155,4 GiB wag stale mieściły się w RAM i VRAM. Pliki były mapowane, część danych może obsługiwać cache systemu, a przebieg obejmował odczyty z dysku podczas przygotowania. W obserwowanych przedziałach ukończonych odpowiedzi syntetycznych licznik procesu nie wykazał odczytanych bajtów z urządzenia blokowego; próbki nie obejmują jednak wszystkich krawędzi przedziałów. Nie jest to dowód pełnej rezydencji modelu ani ogólnej niezależności od NVMe.
Zakres pamięci w CSV obejmuje łącznie oba wejścia; powtórzenie tych samych maksimów w dwóch wierszach nie oznacza dwóch pomiarów przypisanych do poszczególnych długości. PSS nie jest bilansem całego hosta, a przydział bufora nie jest tym samym co faktycznie rezydentna pamięć. Wyjaśniamy też różnicę między RAM i cache.
Zakres oceny i konfiguracja pamięci systemowej
Seria ukończyła oba wejścia i trzy zadania praktyczne. W zapisanych próbkach nie zaobserwowano termicznego ograniczania szybkości; nie jest to wielogodzinny test stabilności tego modelu ani pomiar wielu równoległych klientów.
Osobny zapis SMBIOS raportuje moduły po 48 GiB w A0 i A1 kanału A, puste B0/B1 oraz skonfigurowaną szybkość 3600 MT/s. Jest to obserwacja firmware, nie fizyczna weryfikacja ani wykazanie przyczyny wydajności. Topologia i przepustowość RAM mają znaczenie dla pracy CPU; nie prognozujemy na tej podstawie wyników oferowanej konfiguracji 192 GB lub innego serwera.
Źródłowe wyniki i ustawienia są w przejrzanym JSON kampanii. Pierwotny ścisły wynik formatu pozostaje 1/3. Osobny przegląd dwóch odpowiedzi otoczonych blokiem Markdown stwierdza poprawne wartości wewnętrznych obiektów, lecz nie zmienia wyniku parsera dla całej odpowiedzi. Nie stosowaliśmy go jako automatycznej poprawki w mierzonym przebiegu.