Czym jest GLM 5.3 Flash

GLM 5.3 Flash to model chińskiej firmy Zhipu AI (marka Z.ai). Zanim opublikowano wagi, testowano go anonimowo na OpenRouterze jako „Ox Alpha”; wagi trafiły na Hugging Face 26–27.08.2026 wg źródła. Najważniejsze cechy:

  • 320 mld parametrów w architekturze MoE, 18 mld aktywnych na token: 288 ekspertów, z których pracuje 8.
  • Hybrydowa uwaga: rzadka (NoPE-MLA) przeplatana z liniową (KDA), do tego połączenia mHC; 45 warstw i jedna warstwa MTP do przewidywania kolejnych tokenów.
  • Multimodalny: tekst, obraz i wideo; okno natywne do 1 mln tokenów.
  • Licencja MIT.

Według producenta to najlepszy otwarty model na Terminal Bench 3.0, a na Z.ai Code Bench wypada o 50% lepiej niż GLM-5.2 wg źródła. Producent zaleca próbkowanie z temperaturą 1,0 i top_p 0,95.

GLM 5.3 Flash lokalnie: które wagi się zmieszczą — NVFP4, EXL3, GGUF

Oryginał w FP8 waży ok. 306–328 GB i nie zmieści się nawet na dwóch jednostkach DGX Spark (2× 128 GB). Na dwóch mieszczą się wersje 4-bitowe; na jednej — dopiero mocniej skompresowane.

Rozmiar wag a pamięć DGX Spark

rozmiary jak podają źródła (GB lub GiB) · │ 128 GB — jedna jednostka · │ 256 GB — dwie jednostki · ■ jedna jednostka ■ dwie ■ nie mieści się

BF16
598 GiB
FP8 (oryginał)
306–328
GGUF Q4_K_XL
~200 GB
NVFP4 · nasze
184–190
EXL3 4 bpw · nasze
164 GiB
GGUF Q2_K_XL
~109 GB
EXL3 2,05 bpw
~85 GB
WariantRozmiar2× 128 GBSkąd wiemy
BF16ok. 598 GiBniewg źródła
FP8 (oryginał)ok. 306–328 GBniewg źródła
NVFP4 (RedHatAI / NVIDIA / LibertAIDAI)184–190 GiBtak, na dwóchzmierzone u nas
EXL3 4 bpw (TensorFold)164 GiBtak, na dwóchzmierzone u nas
GGUF UD-Q4_K_XL (Unsloth)ok. 200 GBza dużo na jedną jednostkęwg źródła · nie testowaliśmy
GGUF UD-Q2_K_XL (Unsloth)ok. 109 GBna jednej jednostce — wg źródła 17,7 tok/swg źródła · nie testowaliśmy
EXL3 2,05 bpwok. 85 GBna jednej jednostcewg forum NVIDIA · nie testowaliśmy

GLM 5.3 Flash GGUF czy NVFP4?

Zapytań o „GLM 5.3 Flash GGUF” jest najwięcej, więc uczciwie: GGUF nie uruchamialiśmy. Unsloth publikuje GGUF w kilku stopniach kompresji. Q2_K_XL (ok. 109 GB) mieści się na jednym DGX Spark i według źródła daje tam 17,7 tok/s, ale wymagał gałęzi llama.cpp od Unsloth, a nie zwykłej Ollamy (stan na 12.09 — sprawdź aktualny, zanim zaczniesz) wg źródła. To droga na jedną jednostkę, kosztem mocnej kompresji.

Druga droga na jedną jednostkę to EXL3 2,05 bpw (ok. 85 GB). Według wątku na forum NVIDIA daje ok. 64 tok/s na treściach strukturalnych i 25 tok/s na prozie, ale użytkownicy zgłaszali zapętlenia i zawieszenia przy równoległych zapytaniach wg źródła.

My poszliśmy w NVFP4 i EXL3 4 bpw na dwóch jednostkach: to mniej kompresji i dwa sprawdzone silniki, a różnice między nimi opisujemy niżej.

Jak uruchomiliśmy GLM 5.3 Flash na 2× DGX Spark

Klaster jest ten sam co przy DeepSeek V4 Flash: dwie jednostki DGX Spark / ASUS GX10 połączone kablem QSFP56 200 Gb/s, model dzielony na dwie (tensor parallel = 2), obok działają czat, brama API i agenci. Metoda pomiaru też ta sama: mediana z 6 powtórzeń po 3 rozgrzewkowych, temperatura 0,6, osobno proza, kod i JSON. Sprzęt i połączenie opisujemy na stronie o klastrze DGX Spark.

Wariant A: vLLM + NVFP4 — w całości na MIT

Checkpoint: RedHatAI/GLM-5.3-Flash-NVFP4 (184,29 GiB, 92,27 GiB na jednostkę). Wybraliśmy go z powodu polskich znaków — szczegóły w sekcji o jakości. Oficjalny checkpoint NVIDII (z 09.09) jest w tym samym formacie ModelOpt co odrzucony przez nas LibertAIDAI i o 6 GiB większy.

Silnik: vLLM z łatkami społeczności. Czysty vLLM nie uruchamia GLM na GB10 — kończy się błędem pe_dim must be 64, bo jeden z kerneli napisano pod geometrię modeli DeepSeek, której GLM nie ma (zgłoszenie vLLM #57578 jest wciąż otwarte). Użyliśmy obrazu społeczności tonyd2wild v11 plus dwóch własnych dodatków:

  • łatki top-k — bez niej dekodowanie powyżej ok. 24 tys. tokenów kontekstu pada, bo kernel chce 128 KB pamięci współdzielonej, a GB10 ma ok. 99–101 KB;
  • własnego szablonu czatu z przełącznikiem namysłu (dlaczego — w pułapkach).

Spekulacja: natywny moduł MTP, 3 tokeny naprzód — tak samo szybki jak niekomercyjny DFlash2 na tym checkpoincie, a w całości na MIT. Pełna lista ustawień jest w sekcji o pułapkach, bo prawie każde z nich psuje model po cichu.

Wariant B: TensorFold + EXL3 — szybszy, ale niekomercyjny

  • Silnik TensorFold v0.6.0 (Apache-2.0) według przepisu MiaAI-Lab v1.10.
  • Wagi Mia-AiLab/GLM-5.3-Flash-EXL3-4bpw-TensorFold (164 GiB, eksperci w 4-bitowym EXL3).
  • Moduł spekulacyjny incoai/GLM-5.3-Flash-DFlash2 — na licencji CC-BY-NC-ND-4.0.
  • Warstwy gęste w FP8 zamiast domyślnych 4-bitowych. W teście autorów przepisu wariant 4-bitowy ucinał 12 z 48 krótkich odpowiedzi z kodem (nie kończył tury). U nas, z FP8 i po polsku: 0 z 48.

Wyniki: GLM 5.3 Flash benchmark na DGX Spark

vLLM + NVFP4

tok/sCzas do pierwszego tokenu
proza24,3 (23,6–25,9)273 ms
kod32,3343 ms
JSON32,0315 ms
4 rozmowy naraz16,3 na rozmowę, 55,9 łącznie480 ms
6 rozmów naraz14,6 na rozmowę, 70,6 łącznie516 ms

Zmierzone u nas 23.09.2026; mediana z 6, temperatura 0,6, aplikacje działające obok.

Pula pamięci podręcznej KV: 484 786 tokenów (1,85 × okno 262K); po pomiarze zostaje ok. 10 GB wolnego na jednostkę, czyli dokładnie nasz próg bezpieczeństwa. Start trwa ok. 8,5 minuty (pierwszy ok. 10, bo kompilują się kernele). Dla porównania przepis himorishige — bez aplikacji obok i z wyższym limitem pamięci 0,85 — podaje 26,5 tok/s z MTP 3, 14,6 tok/s bez spekulacji i ok. 76 tok/s łącznie przy 8 rozmowach wg źródła. Nasze 24,3 to ten sam rząd wielkości, w gorszych, bo realnych warunkach.

vLLM czy TensorFold: ten sam model, inny silnik

Zmiana silnika dała więcej niż jakiekolwiek strojenie parametrów: proza z 24,3 na 36,0 tok/s, kod z 32,3 na 67,0, a pierwszy token przychodzi dwa razy szybciej.

vLLM + NVFP4 kontra TensorFold + EXL3

tok/s · zmierzone u nas 23.09 (vLLM) i 10.10.2026 (TensorFold) · klaster 2× DGX Spark, aplikacje obok · ■ vLLM ■ TensorFold

proza

vLLM
24,3
TensorFold
36,0

kod

vLLM
32,3
TensorFold
67,0

JSON

vLLM
32,0
TensorFold
71,2

4 rozmowy naraz, łącznie

vLLM
55,9
TensorFold
85,7
vLLM + NVFP4 (wariant A)TensorFold + EXL3 (wariant B)
proza24,3 tok/s36,0 tok/s
kod32,367,0
JSON32,071,2
4 rozmowy naraz, łącznie55,985,7 (29,3 na rozmowę)
czas do pierwszego tokenu273–343 ms145–184 ms
okno / pula KV262K / 485K1 048 576 / 1 183 744
obrazydo 80 (wolna pamięć spada do 2,2 GB)do 50 (wolne ≥ 14,5 GB; 50/50 w 16 s)
wolne po pomiarzeok. 10 / 12 GB16,4 / 17,9 GB
start8,5–10 minok. 6 min za pierwszym razem, potem 2–6
licencja całościMITniekomercyjna (moduł DFlash2)

Długi kontekst: igła znaleziona przy 777 tys. tokenów

Test „igły w stogu siana”: w długim tekście ukrywamy jedno zdanie i pytamy o nie na końcu. Oba warianty znalazły igłę we wszystkich próbach, ale TensorFold z oknem 1 mln tokenów sięga dużo dalej. Wczytywanie trwa: 1 300–1 400 tok/s w vLLM (259 tys. tokenów → pierwszy token po 195 s) i 1 240–1 690 tok/s w TensorFold (777 tys. → po 629 s, czyli ok. 10,5 minuty).

Gdzie znalazł igłę

pozycja w kontekście, skala do 1 048 576 tokenów · ● igła znaleziona · podświetlenie = okno wariantu · zmierzone u nas

vLLM + NVFP4 · okno 262K · 23.09.2026

39K130K259K

TensorFold + EXL3 · okno 1M · 10.10.2026

39K169K337K777K

Jakość: polskie znaki, ucinane odpowiedzi i obrazy

Polskie znaki to test obowiązkowy

Checkpointy NVFP4 w formacie ModelOpt (u nas LibertAIDAI) gubiły bajt kontynuacji UTF-8 — ok. 2 błędne znaki (U+FFFD, czyli „�”) na 10 tysięcy. W angielskim tekście to prawie niewidoczne. Ale polskie litery z ogonkami zajmują w UTF-8 dwa bajty, więc błąd trafia właśnie w nie.

Dlaczego „ą” jest ryzykowne

schemat poglądowy · wynik zmierzony u nas

litera w UTF-8

ą

C4 85

dwa bajty: początek i bajt kontynuacji

checkpoint ModelOpt

ksi�żka

zgubiony bajt kontynuacji → „�”; ok. 2 na 10 tys. znaków

RedHatAI NVFP4

książka

0 błędów w 4 509 znakach z 289 ogonkami

Ucinane odpowiedzi: 0 z 48

W wariancie TensorFold autorzy przepisu zauważyli, że z warstwami gęstymi w 4 bitach model ucinał 12 z 48 krótkich odpowiedzi z kodem — po prostu nie kończył tury. Przy warstwach gęstych w FP8 na tych samych 48 zadaniach, po polsku, nie ucięło się u nas ani jedno.

Obrazy

GLM 5.3 Flash rozumie obrazy. W wariancie vLLM (profil z wieżą wizyjną, 24.09) zmierzone u nas:

9,3 s

opis wykresu

2,5 s

polska faktura: „Żubr”, „4 812,50 zł” odczytane poprawnie

20/20

obrazów w 6,3 s

80/80

obrazów w 167 s — ale wolna pamięć spadła do 2,2 GB

Wniosek praktyczny: bezpiecznie to ok. 40 dużych zdjęć w jednym zapytaniu. TensorFold ma limit 50 obrazów, ale zostawia ≥ 14,5 GB wolnej pamięci (50/50 w 16 s).

GLM 5.3 Flash był też sędzią w naszym teście modeli decyzyjnych — jako klasyfikator osiągnął 86,5% na polskich mailach, ale potrzebuje ok. 4 s na dokument.

Ciche pułapki: ustawienia, które psują model bez błędu

Przy GLM na vLLM prawie każde kluczowe ustawienie ma tę cechę, że zła wartość nie daje komunikatu o błędzie. Model startuje, odpowiada — tylko źle.

UstawienieNasza wartośćCo się dzieje przy złej
block-size2304model odpowiada, ale treść jest uszkodzona
backend MoEmarlinflashinfer_cutlass: pętle tokenów od pierwszego słowa; u innych użytkowników zamroził oba hosty
parser narzędziglm47glm jest przyjmowany bez błędu, ale agenci milczą
parser rozumowaniaglm45źródła się spierały — rozstrzygnęliśmy testem
tryb eagerwłączonygrafy CUDA przy TP=2 nie dały nic (±0%)
pamięć podręczna KVfp8_e4m3BF16 przy oknie 262K nie wstaje
spekulacjaMTP, 3 tokenynatywna i na MIT; tak samo szybka jak niekomercyjny DFlash2
gpu-memory-utilization0,83przepisy podają 0,85 — ale bez aplikacji obok; u nas 0,85 = zawieszenie
równoległość6 rozmów—

Szablon czatu GLM-5.3 nie ma przełącznika namysłu. Ma tylko reasoning_effort (low, high, max — domyślnie max) i zawsze kończy prompt znacznikiem <think>. Aplikacje, które wyłączają namysł — na przykład generowanie tytułu rozmowy w 40 tokenach — dostawały puste odpowiedzi, bo cały limit zjadał namysł. Dopisaliśmy do szablonu gałąź, która namysł wyłącza.

Do tego dochodzą pułapki wspólne dla GB10, opisane przy DeepSeek V4 Flash: jednostka bez pamięci zawiesza się zamiast zabić proces, a zła karta RDMA po cichu zabiera ok. 40% wydajności.

Licencja: co wolno firmie

  • Model GLM 5.3 Flash: MIT. Wolno używać komercyjnie, modyfikować i udostępniać klientom.
  • Checkpoint RedHatAI NVFP4: MIT. Wariant A (vLLM + NVFP4 + MTP) jest więc w całości na MIT.
  • Moduł DFlash2 (incoai/GLM-5.3-Flash-DFlash2): CC-BY-NC-ND-4.0 — tylko niekomercyjnie. Wariant B z tym modułem to konfiguracja do użytku własnego i niekomercyjnego.
  • Według autorów przepisu TensorFold może zamiast DFlash2 użyć wbudowanej głowicy MTP, co daje wariant czysty licencyjnie — ale obsługujący jedno zapytanie naraz wg źródła. Tego nie mierzyliśmy.

Dla firm: wariant A. Jest wolniejszy, ale nie ma w nim żadnego elementu z ograniczeniem komercyjnym.

GLM 5.3 Flash na tle DeepSeek V4 Flash i Qwen3.8-Flash-Next

Na tym samym klastrze GLM na vLLM jest najwolniejszy z trzech modeli (24,3 tok/s na prozie), za to z TensorFold najszybciej pisze kod i JSON (67,0 i 71,2 tok/s) i jako jedyny działa u nas z oknem 1 mln tokenów. DeepSeek V4 Flash szybciej wczytuje długie dokumenty (ok. 2 300 tok/s) i jest lepiej przetestowany na dokumentach i w pracy agentowej. Qwen3.8-Flash-Next najszybciej zaczyna odpowiadać i zostawia najwięcej wolnej pamięci, ale ma licencję wymagającą osobnej umowy przy udostępnianiu modelu stronom trzecim. Do udostępniania klientom: GLM na vLLM albo DeepSeek — oba na MIT. Pełne zestawienie trzech modeli, z wykresami i siedmioma lekcjami z uruchamiania: DeepSeek V4, GLM 5.3 czy Qwen 3.8 na DGX Spark.

Najczęstsze pytania o GLM 5.3 Flash

Czy GLM 5.3 Flash zmieści się na jednym DGX Spark?

Tylko w mocno skompresowanej wersji. Według Unsloth GGUF UD-Q2_K_XL ma ok. 109 GB, a według użytkownika forum NVIDIA EXL3 2,05 bpw ok. 85 GB — oba mieszczą się na jednej jednostce, ale żadnego nie testowaliśmy. Wersje, których używamy (NVFP4 184 GiB i EXL3 4 bpw 164 GiB), wymagają dwóch jednostek.

Który checkpoint NVFP4 GLM 5.3 Flash wybrać?

My używamy RedHatAI/GLM-5.3-Flash-NVFP4. Checkpointy w formacie ModelOpt gubiły bajt kontynuacji UTF-8 — ok. 2 błędne znaki na 10 tys., a polskie litery z ogonkami zajmują dwa bajty. RedHatAI u nas dał 0 błędów w 4 509 znakach z 289 ogonkami.

GLM 5.3 Flash GGUF czy NVFP4?

GGUF od Unsloth (UD-Q4_K_XL ok. 200 GB, UD-Q2_K_XL ok. 109 GB) uruchamia się w llama.cpp z poprawką Unsloth i pozwala zejść do jednej jednostki. NVFP4 (184–190 GiB) działa w vLLM na dwóch jednostkach i to tę drogę zmierzyliśmy: 24,3 tok/s na prozie i 70,6 tok/s łącznie przy sześciu rozmowach. GGUF nie testowaliśmy.

Ile tokenów na sekundę daje GLM 5.3 Flash na DGX Spark?

Na naszym klastrze 2× DGX Spark: w vLLM z NVFP4 24,3 tok/s na prozie i ok. 32 na kodzie i JSON-ie; w TensorFold z EXL3 36,0 na prozie, 67,0 na kodzie i 71,2 na JSON-ie. Przy kilku rozmowach naraz: 70,6 tok/s łącznie (6 rozmów, vLLM) i 85,7 tok/s (4 rozmowy, TensorFold).

Czy GLM 5.3 Flash można używać komercyjnie?

Sam model jest na licencji MIT, więc tak. Uwaga na dodatki: moduł spekulacyjny DFlash2 używany w szybszym wariancie z TensorFold jest na licencji CC-BY-NC-ND-4.0, czyli tylko do użytku niekomercyjnego. Dla firm właściwy jest wariant vLLM z NVFP4 i natywną spekulacją MTP — w całości na MIT.

Dlaczego vLLM wymaga łatek, żeby uruchomić GLM 5.3 Flash na GB10?

Czysty vLLM kończy się błędem „pe_dim must be 64”, bo jeden z kerneli napisano pod geometrię modeli DeepSeek, a GLM jej nie ma (zgłoszenie vLLM #57578). Druga łatka dotyczy kernela top-k: bez niej dekodowanie powyżej ok. 24 tys. tokenów kontekstu pada, bo kernel chce 128 KB pamięci współdzielonej, a GB10 ma ok. 99–101 KB.

Źródła

Stan na 11.10.2026. Obrazy społeczności, łatki i wersje silników zmieniają się co tydzień — liczby dotyczą konfiguracji opisanej wyżej. Pomiary to mediany z jednej serii, z aplikacjami działającymi obok.