Project Maya: MiniMax-M3.1-Flash (Maya-XS)

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, 64K and 128K tokens (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-03. Raw files: speed result · speed contract · log · long answer.

Requests at once: the server has 1 slot (installer default). C2, C4, C8 exceed the slots: the extra requests wait in the queue, and they were measured anyway. Setup: the speed test ran with the settings of the author's own installer. Project Maya v1.1.50 (mw00/project-maya, commit 10e69a0e of 2 Nov 2026, the newest release when I checked on 3 Nov 2026), set up with ./setup.sh --plain --yes --download-model --no-start --model minimax-maya-xs; nothing was changed afterwards, and the server ran with the config the installer wrote. My path differs from the author's in three points: I downloaded the three model files myself before the setup (first with the installer's own curl command, then, when the line slowed down, with a small parallel downloader of mine that fetches the same pinned revision 9d256f59; all three files match the author's sha256 table); I pointed the installer to my own CUDA 13.1 folder (--nvcc) and my own model folder (--models-dir); and I started the server through a small script that adds only --plain and a log file to the installer's run script. Sampling is the model card's and Maya's own default (temperature 1.0, top_p 0.95), seed 42, with the request flag for no thinking. Numbers: the headline 23.95 tok/s is the mean of the code prompt (24.35) and the prose prompt (23.56), medians of two runs each (spread 1.2 % and 1.5 %). Drafts were accepted at a rate of 75.9 %. All numbers come from one start of the server; the author's README says the first answers after a start are the slowest while the caches fill. The README has no speed row for Maya-XS and none for an RTX 5090 with MiniMax, so there is no author number to compare with. Requests at once: the server has one slot (the installer writes no --parallel; above 1, Maya would switch DSpark and KV streaming off), so 2, 4 and 8 requests at once wait in line: the total stays near 20 tok/s and the per-request numbers include the waiting. The 1-request value (19.7 tok/s) is lower than the decode headline because that test counts the whole answer time, including the wait for the first token (about 3.7 s here). Prefill: Maya's server has /tokenize but no /v1/completions route, so I extended my speed tool on 3 Nov 2026: for this setup it sends the prompt text through /v1/chat/completions and sizes it by an estimate of characters per token; the real size is the server's own count. The prompts named 2K, 8K and 32K therefore held 2,008 to 2,013, 7,297 to 7,774 and 28,714 to 30,648 tokens. The long-prompt table uses prompts of exactly 16,384, 32,768, 65,536 and 131,072 tokens, counted with the server's /tokenize and /detokenize. The two 32K rates differ (447 and 379 tok/s): the prefill part sends about 29K to 31K tokens, the long-prompt part exactly 32,768; I did not look into the difference. Cache: every request carried a new cache_salt and cache_prompt false, but Maya's server code knows neither field. Its conversation cache reused the first 161 to 177 prompt tokens of 60 of the 61 requests my tool checked (the start that my prompts of one kind share: the chat template's header and the words before the random nonce; the warm-up request had none). My tool's cold-prefill check flags this (cache check: not ok). For the prefill and long-prompt parts I allowed up to 256 cached tokens and count only the uncached ones: rate = (prompt tokens minus cached tokens) divided by the time to first token. Counting the cached tokens too would raise the rates by about 10 % at 2K, 2 % at 8K, 1 % at 16K and less than 1 % from 32K up. Attempts: this is the fifth attempt. The first four, on the same server and config, were stopped before they finished (their raw files are not published; the raw files of this page are those of the fifth): (a) the prefill part got HTTP 404 (no /v1/completions route) and the load guard stopped the 2-requests-at-once step because of kcompactd0; (b) the prefill steps at 2K and 8K were refused because 177 prompt tokens came from Maya's cache, and the guard stopped the 32K step because of kcompactd0; (c) the quiet check refused to start, with kcompactd0 at 60 % CPU right after the 93 GB model had loaded; (d) the guard stopped the 32K prefill step because of kcompactd0. Between the attempts I changed only my speed tool and the card (the chat route for prefill, the allowance for up to 256 cached tokens, the kcompactd0 exception below), not the server or its config (the config file has the same sha256 as right after the setup). Load guard: my tool throws away and repeats a step when one other process uses more than 25 % CPU for two samples in a row (samples every 0.5 s); after 3 repeats the step is invalid. In the stopped attempts kcompactd0, the kernel's memory-compaction thread, triggered it in decode and prefill steps at about 100 % of one core. The box has transparent huge pages set to always, and Maya pins nearly all free RAM for a 93 GB model on a 92 GiB box; I read kcompactd0 as a consequence of my own server's memory use, not another program, and I did not change the setting. For the fifth attempt the card tells the guard to ignore this one kernel thread. It still competes for CPU time with the server, so the speed numbers include whatever that costs. The guard still threw away and repeated 4 of its 38 steps (dockerd once at 56 %; khugepaged, the kernel's huge-page thread, three times at 98 to 100 % in the 64K and 128K steps), and every value shown is from a try that the guard accepted. In some accepted steps, short peaks of other processes still reached 47.8 % (apt-get, 64K prose run 1), 42 % (khugepaged, 128K code run 1) and 38 % (dockerd, 8 requests at once, round 2). The speed contract file lists the model server itself as the busiest other process (up to 1,127 % CPU, its CPU lane for the experts that are not in video memory); it is the program under test, not another program.

python3 speed2.py --base-url http://127.0.0.1:43935/v1 --label maya-xs-0311e-speed-r0 --prompts $BENCH/repos/rigmark-v2/prompts-v2.json --output $RUN/raw/maya-xs-0311e-speed-r0/maya-xs-0311e-speed-r0/speed2 --contract $RUN/raw/maya-xs-0311e-speed-r0/maya-xs-0311e-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 MiniMaxAI/MiniMax-M3.1-Flash README 'Recommended sampling settings: temperature=1.0 and top_p=0.95' (as quoted in the Nov 2 MiniMax cards; checkpoint generation_config.json @916e7ca1) and Project Maya's own default (maya.py:659 MM3_SAMPLING = tools/maya_quants.py:39 MODEL_DEFAULTS minimax {temperature 1.0, top_p 0.95}, written to the config by maya.py write_config_mm3; docs/SETTINGS.md:1721). No top_k. Seed 42 for speed/quality. Thinking per request: chat_template_kwargs enable_thinking false (instruct parts) / true (think part); the server honours it (serve/server.py:3139, :3268); the probe checks it. --model minimax-m3.1-flash --no-cache-prompt --server-log $RUN/logs/server-A.log --engine-version-file $RUN/logs/engine-version.txt --server-slots 1 --server-slots-source mw00/project-maya @10e69a0e: the author's MiniMax setup writes no --parallel (maya.py:6238-6358 write_config_mm3 args); --parallel defaults to 1 (docs/SETTINGS.md:434 and the engine option table docs/SETTINGS.md:1766 '--parallel | 1'); the server's places = max(1, engine multi) (serve/server.py:2275), so 1 place; speed2 also asks the server (/props) and flags a mismatch. --server-ctx 262144 --server-ctx-source card box-6-minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311 field ctx

How well it answers

LiveCodeBench was not run on this setup: its answers can be up to 32,768 tokens long, one answer that runs to that limit takes about 23 minutes at the 23.95 tok/s measured here (32,768 divided by the decode speed), and the 40 tasks could take about 15 hours.

Thinking off, except the last test. Seed 42. Sampling from the model card. A cut-off answer counts as wrong. Measured 2026-11-03.

Note from the run: Maya-XS is the small quant of Project Maya: its experts are stored at about 1.6 bits (IQ1_S, the most sensitive layers' tensors at IQ2_XXS) and the model takes 93.0 GB. The quant's own model card reports a next-token loss 5.0 % above the original and the same top token as the original for 82.6 % of the tokens on average (chat 66.5 %, reasoning 80.4 %, code 90.9 %). I did not run the original model or the larger Maya-S quant (about 2.1 bits, 122 GB) on this setup, so the numbers on this page do not say how much the quant costs. MMLU-Pro and GPQA Diamond ran with an answer limit of 1,024 tokens (my usual limit for these two tests is 48); same questions, seed 42, first-letter extraction. The model answered without thinking: the median answer of both tests is 2 tokens long. GPQA Diamond ran from the public mirror fingertap/GPQA-Diamond (198 questions), because the original is gated. Answers that hit their limit count as wrong: 3 of 400 MMLU-Pro answers and 1 of 198 GPQA Diamond answers (limit 1,024 tokens), 9 of 200 IFEval answers (limit 4,096) and 10 of 30 GPQA answers with thinking were cut off (limit 16,384 tokens, half of the engine's own thinking budget of 32,768); none of the 40 long-text answers at 8K (limit 128 tokens) was. The questions of each test ran one at a time, the slot count of the server. Sampling: temperature 1.0, top_p 0.95 (the model card's and Maya's own default). Thinking was off in all tests except GPQA with thinking. The load monitor of these runs named other processes at up to 58 % (MMLU-Pro and GPQA Diamond), 133 % (IFEval), 100 % (long text) and 100 % (thinking test) CPU. All 21 samples above 25 % (of 2,245 samples, taken every 10 s) were one-off commands: 18 short Python calls that request the server's own address (http://localhost:8080/), 2 pgrep calls and one man-page index update (mandb) by the system. The monitor shows a process's CPU time divided by its age (ps), so a command that lives for a fraction of a second reads high. The answers files of MMLU-Pro and IFEval are not published: the site's automatic filters held them back (in MMLU-Pro the model's answer to one question, a motor calculation, contains kW figures, which the filter for power units reads as a power reading; in IFEval the model's answers to two prompts contain a word that the filter for private machine names flags). Both rows were counted from the complete files. The load monitor's sample files and the quiet checks before and after each run are not published either: the site never publishes files with such names, because such logs can hold power readings. The contract files give the maxima. These are my own tests.

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts mmlupro --job maya-xs-0311q

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts gpqa --job maya-xs-0311q

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts ifeval --job maya-xs-0311q

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts ruler --job maya-xs-0311q

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts ruler --job maya-xs-0311q

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts think --job maya-xs-0311q

How much context fits

Memory test. The installer's config fixes the context (262,144 tokens), so the server is started once with the installer's run script 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 the GPU memory in use (nvidia-smi); the GPU was empty before each start. Measured 2026-11-03. Raw files: result of every step · log · contract.

Note from the run: The context is fixed in the config (--max-context 262144, the installer's recommendation), so the server was started once (up after 58 s) and the steps are prompt sizes of about 95 % of each context size from 4K to 256K. Every step answered, and the top step is the server's whole context window, not a limit found by failing. The model reaches 1M tokens, but the author's docs say the engine has not been run end to end beyond 256K, so I did not go further. The memory number is the video memory in use on the whole card (nvidia-smi): 30.59 GiB right after the load and 30.66 GiB at the highest reading, the same at every size. The rest of the model is not in that number: the engine's start lines of this test report 1,088 of 7,296 experts in video memory, 5,981 of the other 6,208 experts in a pinned RAM pool of 63 GB (the rest are read from the model files) and 15 GB of pinned RAM for the KV cache of 262,144 positions. The author's README says the engine pins all but about 6 GB of the free RAM, so other programs get little RAM while Maya runs. Each answer in this test is at most 96 tokens, so the decode speeds in the table are short samples.

bash tools/quality2/measure_all.sh tools/quality2/cards/minimax-m31-flash-maya-xs-mayamm3-1x-v1150-0311.json --parts fit --job maya-xs-0311q

Also made this possible

• ModelMMiniMaxHugging Face
• Maya-XS GGUF weights (revision 9d256f59)MMiniMax-M3.1-Flash-Maya-GGUFHugging Face
• Vision tower and DSpark drafter files, fetched by Maya's installer from this EXL3 repo (revision fe796c40)Mia's AI Lab@MiaAI_lab Hugging Face 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 GeForce RTX 5090 32 GB, AMD Ryzen 9 9950X, 96 GB RAM (92 GiB), 4 TB NVMe SSD (expert tier: the 93 GB model does not fit the card; 1,088 of its 7,296 experts sit in video memory, most of the rest in pinned RAM, the others are read from the SSD)

Model

peasantsmith/MiniMax-M3.1-Flash-Maya-GGUF Maya-XS (Project Maya's own quant of MiniMaxAI/MiniMax-M3.1-Flash, 428B-A23B, sha256 equal to the pinned table of v1.1.50)

Maya-XS GGUF weights (revision 9d256f59)

huggingface.co/peasantsmith/MiniMax-M3.1-Flash-Maya-GGUF

Vision tower and DSpark drafter files, fetched by Maya's installer from this EXL3 repo (revision fe796c40)

huggingface.co/Mia-AiLab/MiniMax-M3.1-Flash-EXL3-EAQ-v1-3.5-bpw

Engine

maya-mm3 v1.1.50 on one RTX 5090 with 96 GB RAM and NVMe (expert tier, the author's installer settings, 262,144 tokens of context) — the program that loads the model and answers requests · github.com/mw00/project-maya/releases/tag/v1.1.50Build and settings we used: Project Maya maya-mm3 v1.1.50 (mw00/project-maya @10e69a0e), CUDA 13.1-User-Toolkit-Build, sm_120

Context window

262,144 tokens: how much text the model can see at once

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-minimax-maya-xs.json \
     --port 8080 \
     --plain

   What the parts mean

   • --port 8080the network port the server listens on

Project Maya maya-mm3 v1.1.50 (mw00/project-maya @10e69a0e), CUDA 13.1-User-Toolkit-Build, sm_120; .venv/bin/python maya.py --config maya-minimax-maya-xs.json --port 8080 --plain (in the project-maya folder, after ./setup.sh --plain --yes --download-model --no-start --model minimax-maya-xs has written the config maya-minimax-maya-xs.json)