MiniMax-M3 on Two Sparks: The Measured W4A16 Lane

The model family is current; these particular tests retain their July date.

MiniMax-M3 has several community deployment recipes, but their evidence should not be collapsed into a single “best” configuration. The tonyd2wild report distinguishes a lane independently reproduced on its own two Sparks from two alternative lanes still under test. This note retains that distinction, the original July measurement date, short-probe timing and a negative transport experiment. It offers a concrete deployment reference without turning unfinished recipes into completed benchmarks.

Keep the measurement date attached to the model

Lane A is verified on July 5, 2026. Reading it today as a MiniMax-family deployment reference does not make its results October measurements. Its hardware is two DGX Sparks with 128 GB unified memory each, connected by direct 200G RoCE and serving through TP2. This is distinct from a three-Spark layer split or an offload configuration on a discrete GPU workstation.

The target is Sebesky/MiniMax-M3-W4A16-GPTQ, with a separate Sebesky/MiniMax-M3-EAGLE3-RTN-INT4 draft. The report describes the full, unpruned model and a vLLM+b12x path. It names an execution image tag and a short source reference, but does not retain a full executed image digest or full target/draft weight revisions. Those fields remain null. Looking up a current model repository today would not establish which exact files ran in July.

The source credits a3refaat's upstream recipe and clearly labels where its own reproduction begins. Attribution is important here: a reference number quoted from the upstream author is not an additional independent measurement by the second reporter. The catalog points below are restricted to the reporter's measured lane A.

The measured lane uses one stream

The default-configuration document selects EAGLE3 depth three, b12x NVFP4 KV, a 196,608-token configured context and a 208,128-token KV pool. All published lane-A speed observations use max_num_seqs=1. A configured large context does not mean those short probes contain that many input tokens or test the whole window.

The original result document specifies 256-token probes, temperature zero, one stream and a warm engine. The first request after boot is excluded because b12x compilation warmup can take about a minute. Actual per-probe input counts, completion counts and repeated-run dispersion are not supplied. Although the source table says “decode,” its stated denominator is completion_tokens / wall, including request wall time. The article and JSON keep that definition.

These four observations are useful for their own prompt classes. They are not a concurrency curve, a full-context curve or a confidence interval. Thinking disabled and adaptive can also produce different work, so the rate difference alone does not establish the same change in complete task time. No general quality score accompanies this experiment.

The denominator is whole request wall time, despite the source table calling the values decode speed.

For a latency-sensitive application, the next relevant evidence would record actual input and completion lengths, first-token latency, the complete request time and successful output checks under the intended mode. The existing table cannot supply those missing measurements. Keeping them explicit is more useful than filling them from another MiniMax report on a different engine or date.

The allocation bracket explains a reproducibility trap

The reporter finds that GMU 0.93 fails a startup free-memory check by 0.02 GiB. Reducing to 0.925 starts the engine but leaves a KV pool below the desired context requirement. The chosen 0.929 reaches the target pool with approximately 100 MB startup margin. The source preserves the bracket because one seemingly reasonable rounded parameter can change whether the recipe starts and whether it has enough configured capacity.

That margin is measured at startup in the reporter's boot state. It is not a sampled worst-case workload margin and does not show safe headroom for simultaneous long prefills. File-cache state, other resident processes and temporary runtime allocations can differ across systems. The published bracket does not justify a universal GMU recommendation or a guarantee that the same fraction works on every Spark pair.

The approximately 100 MB startup margin is not a workload safety allowance.

The 208,128-token pool is measured/configured KV capacity, in tokens. The 196,608-token ceiling is a per-request setting. They are not memory in bytes, and neither value is whole-model peak unified RAM. The source does not provide a paired peak-memory time series for a long request or multi-user load. Those unknowns remain null rather than being estimated from weight-file size or a nominal machine total.

A transport change that made this workload slower

The report tests NCCL_PROTO=LL with NCCL_MAX_NCHANNELS=2. In the code workload, stock NCCL gives 31.8 tokens/s and the LL/two-channel setting gives 28.8. The JSON workload also declines in the source's observed range. This negative result is retained rather than selecting only the fastest headline.

The author suggests that a larger MoE's communication pattern may explain why a setting useful on another model loses here. That is a hypothesis, not an isolated mechanism test. The evidence supports a narrower conclusion: this exact change did not improve the tested lane-A workloads on this pair. It does not identify a universally best NCCL protocol, prove a model-class law or replace measurements on another interconnect.

Source hypothesis about model class is interpretation, not a separately isolated mechanism.

Why the other two lanes stay references

Lane C proposes a different KVarN KV path plus EAGLE3 for speed, and lane B proposes a drafterless context-oriented path. Their numbers in this repository are attributed to the upstream author's own hardware. The second reporter labels both lanes under test and leaves its own result checkboxes incomplete. This article does not publish their quoted speeds as reproduced lane-A data or add them to the selected result points.

The same restriction applies to proposed concurrency and repetition-penalty experiments. A checklist item is a plan. It cannot be turned into a success case because the surrounding recipe is detailed. Any later measured lane should retain its own boot evidence, KV pool, exact runtime identity, prompts, output limits, timing definitions and validation outcomes before joining this series.

For deployment selection, lane A is the supported starting reference in this source. Use its original reproduction inventory to understand the required kernel path, two-node transport and draft model, then account for missing identities and workload telemetry. The useful result is a bounded, reproducible question: whether the same lane satisfies a specified application's response and memory requirements. The published four short rates alone cannot answer the broader questions of maximum concurrency, long-context reliability, peak memory or standardized model quality.