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ę
| Wariant | Rozmiar | 2× 128 GB | Skąd wiemy |
|---|---|---|---|
| BF16 | ok. 598 GiB | nie | wg źródła |
| FP8 (oryginał) | ok. 306–328 GB | nie | wg źródła |
| NVFP4 (RedHatAI / NVIDIA / LibertAIDAI) | 184–190 GiB | tak, na dwóch | zmierzone u nas |
| EXL3 4 bpw (TensorFold) | 164 GiB | tak, na dwóch | zmierzone u nas |
| GGUF UD-Q4_K_XL (Unsloth) | ok. 200 GB | za dużo na jedną jednostkę | wg źródła · nie testowaliśmy |
| GGUF UD-Q2_K_XL (Unsloth) | ok. 109 GB | na jednej jednostce — wg źródła 17,7 tok/s | wg źródła · nie testowaliśmy |
| EXL3 2,05 bpw | ok. 85 GB | na jednej jednostce | wg 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/s | Czas do pierwszego tokenu | |
|---|---|---|
| proza | 24,3 (23,6–25,9) | 273 ms |
| kod | 32,3 | 343 ms |
| JSON | 32,0 | 315 ms |
| 4 rozmowy naraz | 16,3 na rozmowę, 55,9 łącznie | 480 ms |
| 6 rozmów naraz | 14,6 na rozmowę, 70,6 łącznie | 516 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
kod
JSON
4 rozmowy naraz, łącznie
| vLLM + NVFP4 (wariant A) | TensorFold + EXL3 (wariant B) | |
|---|---|---|
| proza | 24,3 tok/s | 36,0 tok/s |
| kod | 32,3 | 67,0 |
| JSON | 32,0 | 71,2 |
| 4 rozmowy naraz, łącznie | 55,9 | 85,7 (29,3 na rozmowę) |
| czas do pierwszego tokenu | 273–343 ms | 145–184 ms |
| okno / pula KV | 262K / 485K | 1 048 576 / 1 183 744 |
| obrazy | do 80 (wolna pamięć spada do 2,2 GB) | do 50 (wolne ≥ 14,5 GB; 50/50 w 16 s) |
| wolne po pomiarze | ok. 10 / 12 GB | 16,4 / 17,9 GB |
| start | 8,5–10 min | ok. 6 min za pierwszym razem, potem 2–6 |
| licencja całości | MIT | niekomercyjna (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
TensorFold + EXL3 · okno 1M · 10.10.2026
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.
| Ustawienie | Nasza wartość | Co się dzieje przy złej |
|---|---|---|
block-size | 2304 | model odpowiada, ale treść jest uszkodzona |
| backend MoE | marlin | flashinfer_cutlass: pętle tokenów od pierwszego słowa; u innych użytkowników zamroził oba hosty |
| parser narzędzi | glm47 | glm jest przyjmowany bez błędu, ale agenci milczą |
| parser rozumowania | glm45 | źródła się spierały — rozstrzygnęliśmy testem |
| tryb eager | włączony | grafy CUDA przy TP=2 nie dały nic (±0%) |
| pamięć podręczna KV | fp8_e4m3 | BF16 przy oknie 262K nie wstaje |
| spekulacja | MTP, 3 tokeny | natywna i na MIT; tak samo szybka jak niekomercyjny DFlash2 |
gpu-memory-utilization | 0,83 | przepisy 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
- Z.ai, karta modelu GLM-5.3-Flash (320 mld / 18 mld aktywnych, MIT, architektura) i config.json (288 ekspertów, 8 aktywnych, 45 warstw + MTP, okno 1 048 576); dokumentacja Z.ai — okno 1 mln, wejście wideo, wyniki na benchmarkach, zalecane próbkowanie.
- TechNode, Zhipu identifies Ox Alpha as GLM-5.3-Flash and releases model weights (27.08.2026).
- Checkpointy NVFP4: RedHatAI, NVIDIA, LibertAIDAI.
- Przepisy na 2× DGX Spark: tonyd2wild, himorishige (wyniki MTP 3, bez spekulacji i przy 8 rozmowach), barrydeen; Classmethod, GLM-5.3-Flash NVFP4 na dwóch DGX Spark z vLLM.
- vLLM: przepis GLM-5.3-Flash i zgłoszenie #57578 (
pe_dim must be 64). - TensorFold: silnik (Apache-2.0), przepis MiaAI-Lab na 2× DGX Spark, wagi Mia-AiLab EXL3 4 bpw, moduł incoai DFlash2 (CC-BY-NC-ND-4.0).
- Unsloth, GLM-5.3-Flash-GGUF — rozmiary UD-Q4_K_XL i UD-Q2_K_XL, gałąź llama.cpp od Unsloth.
- Forum NVIDIA, 60 tok/s GLM 5.3 Flash on a single DGX Spark (03.09.2026) — EXL3 2,05 bpw, ok. 85 GB, zgłaszane zawieszenia przy równoległych zapytaniach.
- Pomiary i testy: własne, klaster ailone 2× DGX Spark / ASUS GX10, 23–24.09 (vLLM) i 10.10.2026 (TensorFold).
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.