GLM-5.3-Flash as Maya-S (IQ2_XXS) on one DGX Spark, Project Maya v1.1.53

How fast it runs

Long prompts

Method: code+prose; 2 run(s) each; 512 tokens; 1 warm-up(s); median; context steps: prompts of exactly 16K, 32K and 64K tokens and of 130,048 tokens for the 128K step, which is reduced so that prompt plus 512 output tokens fit the 131,072 window (a filler log first, the code or prose task prompt last), 2 runs per step, 512 output tokens; decode = tokens after the first / time after the first token; prefill = prompt tokens / time to first token of the same request, median over its requests; requests at once: C1,C2,C4,C8 at once; 2 rounds each; 512 tokens per request; prose prompt; total = all tokens / wall time, per request = tokens / end-to-end time; median over the rounds. Measured 2026-11-04 to 2026-11-05. Raw files: speed result · speed contract · log · long answer.

The speed test ran with Project Maya version 1.1.53 (mw00/project-maya, tag v1.1.53 = commit 7c4aa56e of 4 Nov 2026) and the author's own installer, answered with his recommended choices: ./setup.sh --plain --yes --download-model --no-start --model glm-maya-s --context 131072. The installer built the engine on the box (CUDA 13.0.88, sm_121, aarch64), downloaded the three shards of Maya-S-v2-IQ2_XXS (96.47 GB, revision a1c2a554 of peasantsmith/GLM-5.3-Flash-Maya-GGUF) and checked their sha256 against the table that is pinned in the author's code. The context of 131,072 tokens is the README's "DGX Spark, 128K context" row (the installer's own default is 32,768). No --parallel (the author's default is 1 slot), no calibration run (the installer offers none with --yes), no memory settings of my own. I started the server with the config the installer wrote, through a small wrapper of mine that adds --plain and a log file, drops the shards from the page cache before the start and stops the server if free memory falls below 6 GiB or the GPU gets hotter than 90 C; it never fired. The engine's start log, which is not among the raw files here, says: ready after 47 s, all 12,096 experts in the GPU pool (80.17 GB), prompt chunks of 32,768 tokens (--prefill auto), and no fall back to "token by token" prompt reading. A first speed run, started on 4 Nov 2026 at 23:45, was stopped at 23:54, because its prefill step got an error (HTTP 404): the copy of the test tool on this box was older than the one used on the other boxes. Nothing from that run is on this page. I updated the tool and started again at 23:56; this page shows that second run. Sampling is the model card's: temperature 1.0, top_p 0.95; seed 42; the request flag for no thinking; no cached tokens in the 61 requests that were checked. The headline 16.02 tok/s is the mean of the code prompt (16.03) and the prose prompt (16.01), medians of two runs each (spread 0.2 % and 0.1 %). The server has 1 slot, as in the author's setup, so the requests-at-once test (1, 2, 4 and 8) measures the queue: the total stays at about 14.7 tok/s (14.3, 14.6, 14.7 and 14.7), and each request gets less (14.3, 11.0, 6.1 and 3.3 tok/s). The decode speed falls from 15.3 tok/s at 16K to 14.5 tok/s at 128K of prompt (code prompt), and the prompt at the largest depth had 130,048 tokens: the prompt plus 512 output tokens must fit the window of 131,072. The project's README lists this hardware with Maya-S at 128K context: "16.5 tokens/s" and "~730 tokens/s (6K prompt)" (a community report on version 1.1.15, line 150 of the README at the commit I ran). My decode is 16.02 tok/s, about 3 % lower. My prefill at 8K is 689 tok/s, about 6 % lower, at another prompt length and with a newer version. I think part of the prefill gap is the clock cap of my boxes (2200 MHz; the chip ran at about 2177 MHz under load and its maximum is 3003 MHz): prefill is limited by compute and decode by memory. I have not tested it without the cap, and the cap stays. My prefill number is the prompt tokens divided by the time to the first token, which includes the request. The engine's own log agrees with it: it reads prompts of 16,384, 32,768 and 65,536 tokens in 22.8 to 22.9, 46.4 to 46.7 and 95.4 to 95.6 s, against my first-token times of 23.0, 46.9 and 95.9 s, so the way I count explains at most about 1 to 2 % of the gap. The load guard (a sample every half second) saw other processes together above 25 % CPU in 113 of 7,855 samples, up to 104 %: mostly a firmware query tool (34 samples), the Docker daemon (28), package-manager checks (25), nvidia-smi calls (10), the box's update-check script (7) and the scheduled firmware-update notifier (7). It threw away two tries and repeated them: the prefill at 32K (run 1: the firmware-update notifier, up to 76 %) and the code run at 128K (run 2: a package-manager check, up to 101 %); the second tries are the ones that count, and no other step had to be repeated. The guard ignores one kernel thread (kcompactd0, the kernel's memory compaction, caused by the large model resident in memory). The guard's sample file and the quiet-check file are not among the raw files here; the speed contract lists the guard's steps and the tries it threw away. The ten-second quiet-check file of this test lists the Maya server itself as the busiest process in all 391 samples (about 198 % of one core; I think because the wrapper started the server and not the tool). That file cannot show foreign load, and the guard above is the record of it.

python3 speed2.py --base-url http://127.0.0.1:43195/v1 --label maya1153-glm53-0411b-speed-r0 --prompts $BENCH/repos/rigmark-v2/prompts-v2.json --output $RUN/maya1153-glm53-0411b-speed-r0/maya1153-glm53-0411b-speed-r0/speed2 --contract $RUN/maya1153-glm53-0411b-speed-r0/maya1153-glm53-0411b-speed-r0/speed2/speed-contract.json --parts decode,prefill,conc,l1,ctx --prefill-depths 2048,8192,32768 --prompt-ids code,prose --runs 2 --max-tokens 512 --warmups 1 --prefill-runs 3 --conc-levels 1,2,4,8 --conc-rounds 2 --conc-max-tokens 512 --conc-prompt prose --ctx-depths 16384,32768,65536,131072 --ctx-runs 2 --ctx-max-tokens 512 --sampling {"temperature": 1.0, "top_p": 0.95} --sampling-source Project Maya's own default for GLM (Maya-S has no quant-specific sampling; only Maya-XS does): maya_quants.py:38 MODEL_DEFAULTS glm {temperature 1.0, top_p 0.95}, maya.py:122 and glm_sampling maya.py:3265-3272, written to the config by write_config; same as the zai-org GLM-5.3-Flash generation_config. No top_k. Seed 42 for speed/quality. Thinking per request: reasoning effort none (instruct parts) / on (think part); the probe checks it. --model glm-5.3-flash --no-cache-prompt --server-log $RUN/server-A.log --engine-version-file $RUN/engine-version.txt --server-slots 1 --server-slots-source mw00/project-maya @7c4aa56e: the author's GLM setup writes no --parallel (maya.py:3284-3287 write_config args); --parallel defaults to 1 (docs/MODELS.md:44 'optional, up to 8'; docs/SETTINGS.md:434); speed2 also asks the server (/props) and flags a mismatch. --server-ctx 131072 --server-ctx-source mw00/project-maya @7c4aa56e README.md:150 (DGX Spark row 'Maya-S, 128K context') and maya.py:114 (CONTEXTS menu 8192/32768/65536/131072); setup flag --context 131072; written to the config as --max-context

How well it answers

LiveCodeBench had not finished on this setup when this page was built (5 Nov 2026), and the thinking test was not run, so the page shows no value for them.

Thinking off. Seed 42. Sampling from the model card. A cut-off answer counts as wrong. Measured 2026-11-05.

Note from the run: MMLU-Pro (400 questions), GPQA Diamond (198) and IFEval (200) ran in one session on 5 Nov 2026 with thinking off, the model's sampling (temperature 1.0, top_p 0.95) and seed 42, one question at a time (the slot count of the server). MMLU-Pro and GPQA Diamond ran with an answer limit of 1,024 tokens (my usual limit for these two is 48; the card of this setup sets 1,024 as for the other GLM setups, because GLM writes the answer letter first and may explain after it), first-letter extraction. IFEval has a limit of 4,096 tokens, the long-text tests (RULER at 8K and 32K tokens, 40 tasks each, in a second session on a freshly started server) 128 tokens. No answer was cut off at its limit: 0 of 400, 0 of 198, 0 of 200 and 0 of 80; an answer that is cut off counts as wrong. I ended the first session with a stop signal after IFEval, because LiveCodeBench's first problem was still writing after 11 minutes (10,800 of 32,768 tokens) and I wanted to run LiveCodeBench last; the session's contract file was rebuilt from the answer files (marked "recovered"; that file is not among the raw files here), and I recounted the three percentages from the answer files: 252 of 400, 95 of 198 and 162 of 200. LiveCodeBench (40 problems, thinking off, up to 32,768 tokens per answer) had not finished on this setup when I built this page, so the page shows no value for it. The thinking test (GPQA with thinking on) was started once and stopped after 9 minutes, so that LiveCodeBench could run; it has no result. The tests ran with the same server settings as the speed test; the memory test and sparkDash each ran in their own session on a freshly started server. These quality tests have no foreign-load guard; their sampling files (not among the raw files here) list the busiest other process every 10 seconds: in the session with MMLU-Pro, GPQA and IFEval 6 of 634 samples were above 25 % CPU (up to 95 %: package-manager checks and a firmware query), in the long-text session none of 247 samples was (the kernel's memory reclaim thread was the busiest process in nearly all samples, at 1 % or less). These are my own tests, and no other run of this setup is mixed into the numbers on this page.

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts mmlupro --job maya1153-glm53-0411b

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts gpqa --job maya1153-glm53-0411b

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts ifeval --job maya1153-glm53-0411b

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts ruler --job maya1153-glm53-0411b

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts ruler --job maya1153-glm53-0411b

How much context fits

Memory test. The recipe fixes the context (131,072 tokens), so the server is started once with the recipe's own command and reserves its memory up front. Then, for each size (4K, 8K, 16K ... up to the largest size tested), one prompt that fills about 95 % of that size is sent, and the model must answer. The largest size that answered counts; it is the highest size tested, not a limit of the setup. Decode speed is measured on every answer. Peak memory is, on each of the one boxes, the rise of used memory (MemTotal - MemAvailable) over the idle value before the step; the table and the number show the highest of the one boxes. Unified memory, so GPU and CPU share it. Measured 2026-11-05. Raw files: result of every step · log · contract.

Note from the run: fit memory per node, highest rise over idle: local 93.9 GiB The context is fixed by the author's config (131,072 tokens, 1 slot), so the server is started once and takes its memory up front. Every size from 4K to 128K was sent as a prompt of about 95 % of the size and answered (96 tokens asked; the answers at 4K and 64K ended by themselves, after 63 and 76 tokens). The largest size tested, 131,072 tokens, is the window of this setup and the highest size in my list. The memory number is the rise of used memory over the idle value measured before the server started (unified memory, so GPU and CPU share it). The number shown (93.87 GiB) is the highest rise, at the largest size; it was between 93.35 and 93.87 GiB at all six sizes, because the model and its expert pool are loaded at the start. The decode speed shown (13.9 tok/s) is that of a reply of 96 tokens at the largest size. The prefill column is the server's own figure for that one request, on a server that has just been started; it is not the prefill of Speed v2.

bash tools/quality2/measure_all.sh tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json --parts fit --job maya1153-glm53-0411b

Also made this possible

• Maya-S weights (Maya-S-v2-IQ2_XXS, revision a1c2a554)GGLM-5.3-Flash-Maya-GGUFHugging Face
• ModelZ.ai (GLM-5.3-Flash)Hugging Face @Zai_org GitHub Website

Run it yourself

What you need and how to start it, step by step. The results below come from exactly this setup.

What you need

Hardware

1x NVIDIA DGX Spark class box (an ASUS Ascent GX10, GB10 chip, 128 GB unified memory), GPU clock capped at 2200 MHz. Driver 580.173.02, kernel 6.17.0-1031-nvidia, CUDA 13.0.88

Model

peasantsmith/GLM-5.3-Flash-Maya-GGUF Maya-S-v2-IQ2_XXS @a1c2a554 (Project Maya's own quant of zai-org GLM-5.3-Flash, 321B MoE, 18B active, sha256 equal to the pinned table of v1.1.53)

Maya-S weights (Maya-S-v2-IQ2_XXS, revision a1c2a554)

huggingface.co/peasantsmith/GLM-5.3-Flash-Maya-GGUF/tree/a1c2a554ea72a7e8e66cc28b3eaf5036c9313860

Engine

PeasantSmith's Project Maya at commit 7c4aa56e with his Maya-S quant of GLM-5.3-Flash, 131,072 tokens of context, 1 slot, the model's own MTP block as drafter — the program that loads the model and answers requests · github.com/mw00/project-maya

Steps

1. Get the engine and the model files from the list above.

2. Start the server with this command. It loads the model into memory. When the model has loaded, the server waits for requests on port 8080.

   Copy

   .venv/bin/python maya.py \
     --config maya-maya-s-v2-iq2_xxs.json \
     --port 8080 \
     --plain (engine build/maya, config written by ./setup.sh \
     --model glm-maya-s \
     --context 131072); via maya-ctl.sh start

   The file names are the ones we used. Run the command in the folder that holds them, or put the full path in front of each name.

   What the parts mean

   • --model glm-maya-sthe model file it loads
   • --port 8080the network port the server listens on

Project Maya (Strata engine) v1.1.53 (mw00/project-maya @7c4aa56e), built by the author's setup on box-2, CUDA 13.0.88, sm_121, aarch64, 1 GB10, MTP block as drafter; .venv/bin/python maya.py --config maya-maya-s-v2-iq2_xxs.json --port 8080 --plain (engine build/maya, config written by ./setup.sh --model glm-maya-s --context 131072); via $HOME/maya-1153-0411/maya-ctl.sh start

Mia's own benchmark, run unchanged

This is Mia's own benchmark tool (commit 21a3511), run unchanged. It has its own section on this page, and it is never mixed with my numbers. A cut-off answer counts as wrong here, so a value can differ from sparkDash's own screen.

Seed 1234 applies to the two quality tests; decode, prefill and tool eval send no seed. The benchmark client ran on a separate machine that is never part of the measured group. Measured 2026-11-05. Version 2.50.0, commit 21a3511.

QA. Quality QA, 150 items, seed 1234, temperature 0, thinking off, 4 requests at once (Mia's default). An answer cut off at the token limit counts as wrong. ± is the 95 % margin (Wilson).

MMLU. Quality MMLU, 285 items (5 for each of 57 subjects, 4 answers), seed 1234, temperature 0, thinking off. An answer cut off at the token limit counts as wrong. ± is the 95 % margin (Wilson).

Decode. Decode bench, 1 request at once, 400 tokens, prompt type structured, temperature 0, thinking off. No seed is sent.

Prefill. Prefill bench at 4K, 8K, 16K and 32K tokens. sparkDash skips a size that does not fit into the context. No seed is sent.

Tool Eval Quick. Tool Eval Quick: tool-eval-bench (SeraphimSerapis, commit c61319b), 15 core scenarios (--short), --no-think, --timeout 120. Score 0 to 100. No seed is sent.

Note from the run: sparkDash 2.50.0 (commit 21a3511) runs its own tests: its own QA (150 questions) and MMLU (285 questions) at temperature 0, thinking off, a cut-off answer counts as wrong (0 of the 150 QA answers and 0 of the 285 MMLU answers were cut off); its decode and prefill tests use their own prompts, so these values are not comparable with Speed v2 above. Speed v2 and Quality v2 stay in their own columns; no sparkDash number is mixed into them. The sparkDash client ran on another machine and was never part of the measured group.

python3 tools/quality2/sparkdash_client.py tools/quality2/cards/glm53-flash-maya-s-v2-iq2xxs-v1153-1x-0411.json <box> --client <client machine> --job maya1153-glm53-0411-sd --out $RUN

tool-eval-bench --base-url http://127.0.0.1:<port> --model glm-5.3-flash --short --no-think --timeout 120 --json-file $BENCH/sparkdash-client/runs/maya1153-glm53-0411-sd-sparkdash-r0/tooleval/result.json --no-live