Report

vLLM auto picked the wrong MoE kernel for DeepSeek-V4-Flash on GB10

Serving DeepSeek-V4-Flash-0731 across two DGX Spark nodes: the image ships a MoE kernel built for this model's MXFP4 experts on this silicon — and auto-selection skips it. Picking it by hand is worth double-digit percent of decode. Recipe and raw outputs are public.

lab_single_run internal research August 3, 2026 · Funding: Self-funded internal research

Scope note. This study ran on the lab’s DGX Spark pair with its own pinned harness — image digest, model revision and metric formulas are in the repository’s run manifest, raw outputs in results/raw/. It is not yet part of the claim registry that backs our tested-configuration cards: the numbers below are quoted from the published repository, where they can be checked against the raw records.

The finding

DeepSeek-V4-Flash-0731 — a 284B-parameter MoE with ~13B active — serves across two DGX Spark (GB10) nodes over RoCE with tensor parallelism. The runtime image ships a FlashInfer MoE kernel built specifically for this model family’s native MXFP4 experts on this GPU generation. The runtime’s auto backend selection does not pick it.

Forcing it by hand (--moe-backend flashinfer_b12x) is worth +13.3% by mean and +16.6% by median on the client-measured decode metric at the card-like single-stream control — the series contains one outlier, so the repository reports both statistics. The check that the flag actually took effect is one log line: the server must report the B12X backend, not the DEEPGEMM fallback. Without that check the flag can silently do nothing.

Why this belongs in a qualification lab

A default is not a verdict. The kernel exists in the image, is faster on exactly this model-on-this-silicon combination, and is excluded from automatic selection — which means every out-of-the-box deployment of this pairing leaves double-digit decode percentage on the table without any error, warning, or visible sign. The only way to know is to measure the configuration you actually run, then read the logs to confirm what the runtime actually did. That is the lab’s whole argument in one incident.

What the repository provides

A head-first two-node launch script with the fabric pitfalls documented (the peer must not connect before the head’s store is listening), the benchmark harness with two load profiles and a pure-decode mode that measures and excludes TTFT, the pinned image digest and model revision, and the raw benchmark outputs. The benchmarked checkpoint is a community-quantized FP8 derivative pinned by revision; the official aligned checkpoint is listed but was not benchmarked — the repository says so explicitly, and so do we.

What this does not establish

No claim-registry numbers yet: the DGX Spark lane has not been through methodology v1 (frozen corpora, evidence bundles, derived claims) — that is the planned next step for this testbed. Single pass per configuration. No comparison with other devices, and nothing here transfers to the official checkpoint, other model sizes, or future image versions.

Evidence

The long-read version of this study is on Habr: DeepSeek 0731 на DGX Spark (Russian). Recipe, manifest and raw outputs: github.com/botAGI/dspark-0731-gb10. Our measurement harness for the qualification lanes: agmind-bench.

Cite this report

AGmind Systems Lab (2026-08-03). vLLM auto picked the wrong MoE kernel for DeepSeek-V4-Flash on GB10. Evidence level: lab_single_run. https://agmind.ai/reports/dsv4-flash-moe-backend-dgx-spark/
← Reports