Qwen3.8-Flash-Nextbenchmark results

Measured speed and quality

Speed (single user)

Source: fleet-bench/dgx1-overnight-2026-10-05/RESULTS.md, fleet-bench/2026-10-02-best-model-per-tier-results.md, ai11/RESULTS-2026-10-12-qwen38-flash.md

Aggregate throughput

Source: fleet-bench/dgx1-overnight-2026-10-05/RESULTS.md, fleet-bench/2026-10-02-best-model-per-tier-results.md

Prefill and latency

Source: fleet-bench/dgx1-overnight-2026-10-05/RESULTS.md, fleet-bench/2026-10-02-best-model-per-tier-results.md

Context

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md

Power and efficiency

Source: fleet-bench/dgx1-overnight-2026-10-05/RESULTS.md, fleet-bench/2026-10-02-best-model-per-tier-results.md

Other measurements

Source: fleet-bench/2026-09-25-dgx1-best-model-eval.md, fleet-bench/2026-10-03-cmmc-rag-v3-results.md, ai11/RESULTS-2026-10-12-qwen38-flash.md, ai11/RESULTS-2026-10-13-model-sweep.md

What it is

Qwen3.8-Flash-Next is a compact assistant-class model that Petronella Technology Group, Inc. runs as a workhorse for private deployments. It is small enough to live on a single desktop-class machine, yet in our measured runs it answered the same retrieval and agentic battery as far larger models, which is why it kept coming back as the reference configuration in our fleet benchmarks. We measured it in NVFP4 on the DGX-class hardware and as a Q4_K_XL build on unified-memory desktops, and it held up in both contexts.

The interesting property of this model is how it scales across a pod. One pair of units serves a small team comfortably. Four units hold the same floor for more simultaneous users. Eight units push aggregate throughput higher still, although not as efficiently as two separate four-unit engines. On the DGX Station the same model turns into a different animal entirely: prefill speeds that read like the cluster numbers and a single-user decode rate that leaves the desktop boxes far behind. That spread across hardware classes is exactly what a buyer needs to understand before committing to a box, and this page lays it out from our own measurements.

Where it runs best

In our fleet the model has a natural home on each hardware class, and each class buys something different.

On the two-unit GB10 pod (spark1 and spark2 in a tensor-parallel pair, vLLM nightly with the oxbyte multi-token engine at draft four and expert parallel, NVFP4) it is the serving model. That pair held the single-user floor with the batch ceiling reached at the same aggregate throughput, which is the profile you want when a handful of people share one small appliance and nobody should notice whose request is in flight. Its retrieval and agentic score on our CMMC RAG battery, run strict at the two-unit configuration, tied the much larger Qwen3.8-27B hosted on the H200 server. For a small office that wants one box to be both the throughput leader and the quality reference, that pairing is hard to argue with.

On the four-unit pod (spark1 through spark4, TP4, same engine flags) the floor rises and the ceiling roughly doubles. The MSI-variant units matched the Spark pair within a few percent, so mixed-unit pods behave like homogeneous ones for this model. This is the layout we would pick when the same appliance must serve a full department rather than a team.

On the eight-unit pod as one engine the single-user speed improves again, and the aggregate ceiling climbs further, but the efficiency story turns: the eight-way engine reaches a lower tokens-per-joule figure than either smaller layout, and our notes record that two separate four-unit engines of the same model would beat one eight-way engine on aggregate. So the eight-unit configuration makes sense when you specifically want one big context pool and the simplest possible serving topology, not when you want maximum tokens per watt.

On the DGX Station GB300 (dgx1, single GPU, vLLM, NVFP4 checkpoint with bf16 KV cache) it is a different league. Single-user generation is roughly four to five times the desktop numbers, aggregate throughput at the standard user count is far above anything the pod produces, peak aggregate climbed much higher at larger user counts, and prefill at both short and long prompts ran at rates that make interactive document work feel instant. It also passed a very long context check at a verified context length near the quarter-million-token mark, which is the single biggest capability gap between it and the desktop class.

On ai11, the Minisforum desktop with the AMD Ryzen AI Max+ PRO chip and Radeon graphics, running the unsloth GGUF build (UD-Q4_K_XL), it was the best overall pick of our model sweep. It scored highest on our combined MMLU-Pro and HumanEval battery among the candidates we tested, it handled tool calls, and it passed the long-needle generation test. This is the configuration for a single user who wants a capable private assistant on a machine that fits under a desk.

Measured speed

The table numbers below are the checker-verified values from our records; here we describe what they mean in practice.

On the two-unit pod, prose generation per user sits in the mid-thirties of tokens per second, code generation is faster at fifty-plus, and the pair reaches its aggregate ceiling at a user count in the low thirties. Prefill holds nearly flat from an eight-thousand-token prompt to a thirty-two-thousand-token prompt, which tells you the engine is not falling off a cliff as conversations grow. Energy efficiency is the best of the three pod layouts at over one token per joule.

On the four-unit pod, per-user prose generation rises to the low forties and code generation into the low sixties, with the user ceiling doubling to sixty-four and the aggregate at that ceiling well over six hundred tokens per second. The trade is energy: the tokens-per-joule figure drops below the two-unit number, and only recovers to a slightly better value when you drive the pod at its full sixty-four-user ceiling.

On the eight-unit pod as a single engine, per-user prose generation reaches the mid-forties and code generation the mid-sixties, the ceiling stays at sixty-four users, and the aggregate at the ceiling approaches seven hundred seventy tokens per second. But the tokens-per-joule figure falls to well under one, the worst of the three pod layouts, and our notes flag that two separate four-unit engines would have delivered materially more aggregate throughput. The eight-way layout is for single-user speed and simplicity, not efficiency.

On the DGX Station the story changes completely. Single-user generation runs at over two hundred tokens per second for both prose and code, aggregate throughput at the standard user count is about three thousand tokens per second, and the peak measured aggregate at the largest user count was roughly double that. Prefill at eight thousand tokens runs above forty-three thousand tokens per second, and it holds that rate essentially unchanged at thirty-two thousand and even at a one-hundred-twenty-eight-thousand-token prompt, which is the single most impressive number in this model's records. The measured module power at load was eight hundred fifty watts and the energy figure is over three tokens per joule, though we note in the records that the power reading is module draw, which flatters the efficiency number somewhat.

On ai11 with the Gufo ROCm engine and multi-token prediction at draft seven, single-user prose generation runs in the mid-forties and code at nearly forty-eight tokens per second, with prefill on a thirty-nine-thousand-token prompt around seventeen hundred tokens per second. Turning multi-token prediction off drops prose generation to about twenty-nine and a half tokens per second, so the draft model is worth roughly half again in speed. The Vulkan build of llama.cpp with multi-token prediction at draft three is a middle option: prose in the mid-thirties, code in the mid-forties, but prefill only around four hundred tokens per second. Without multi-token prediction the Vulkan build is the slowest measured configuration at twenty-seven tokens per second. On Windows the same Vulkan build with multi-token prediction manages thirty-two tokens per second of prose, and the Windows prefill figures are the lowest of the desktop builds. For long prompts the ROCm and Vulkan llama-bench numbers are close to each other, and the Windows baseline trails both.

One honest note: we do not have a single-user speed record for this model on the H200 or on any smaller single-GB10 unit. The pod records start at two units, and the DGX and desktop records cover the single-device case for their own classes. If your plan is a one-box Spark with this model, we have not measured that layout yet.

Quality and accuracy

Quality is where this model earns its place despite its size. On our CMMC retrieval and agentic battery run in the strict mode, the two-unit NVFP4 configuration scored near the top of the entire fleet at close to a perfect score, tying the much larger Qwen3.8-27B running in FP8 on the H200. That tie matters: it means a buyer who needs both strong retrieval behavior and meaningful throughput can get both from two small units rather than a datacenter card.

On the DGX Station we also ran a closed-book CMMC knowledge check where the model answered from its own weights with no retrieval help, and it got eleven of thirty-five items right under vendor sampling. Read that honestly: closed-book recall of narrow regulatory detail is weak, which is exactly why we deploy it with retrieval attached. It is not a compliance oracle on its own; it is a strong reasoner over documents you feed it.

On ai11, the combined battery of forty MMLU-Pro items and twenty HumanEval items came back thirty-seven and eighteen respectively, the best overall result of the sweep we ran that day. Tool calling worked, and the long-needle test, where the model must find and use a planted fact deep inside a thirty-nine-thousand-token prompt, passed.

How we ran it

All pod and DGX numbers come from our own fleet benchmark harness. The pod runs used vLLM with the oxbyte multi-token engine at draft four and expert parallel, NVFP4 checkpoints, a serving configuration validated on the first of October and re-measured on the second. Each pod layout was swept across escalating user counts until throughput stopped climbing, and we recorded the user count where the per-user floor was still intact as the ceiling. Correctness checks passed on all pod runs; the notes record eight of eight tasks green on each configuration.

The DGX Station overnight run used two repetitions per level and a RadixArk NVFP4 checkpoint with bf16 KV cache. The source file for that run carries an explicit caveat that its cross-platform ratios are not cleared for publication, so we present only the absolute numbers above and do not derive comparisons from them. Power on dgx1 is module-level draw, which slightly flatters the tokens-per-joule figure; treat the DGX efficiency number as an upper bound.

The ai11 runs used the unsloth GGUF build at UD-Q4_K_XL across three engines: Gufo under ROCm with multi-token draft seven, the unsloth llama.cpp build under Vulkan RADV and under ROCm at draft three, and the same builds with multi-token prediction disabled. We also ran the Windows dual-boot side with llama.cpp Vulkan at draft three and without. Prefill was measured on a thirty-nine-thousand-token prompt, and the llama-bench micro-benchmarks at the standard prompt and generation lengths are recorded separately from the assistant-style runs. Multi-token prediction raised generation speed everywhere it was enabled but left prefill essentially unchanged, which is the expected behavior and a useful sanity check on the measurements.

We publish the per-user floor, the aggregate throughput at the standard and ceiling user counts, prefill at several prompt sizes, and energy where the hardware exposes a trustworthy power reading. Every number on this page traces to a file in our benchmark source snapshot, and the tables the generator renders carry those source paths.

When to pick it

Pick this model on a two-unit pod when you want the best balance on our fleet of throughput, efficiency, and measured retrieval quality, and your user count sits in the low thirties or below. It was the serving workhorse of the pod for good reason: the best tokens-per-joule of the pod layouts, a near-top agentic score, and prefill that stays fast as prompts grow.

Pick it on four units when the same workload grows past the two-unit ceiling and you need the doubled user count more than you care about the modest efficiency drop. It delivered the highest-throughput four-unit layout we measured.

Pick it on the DGX Station when single-user latency and very long contexts matter more than cost. A verified context near a quarter million tokens, prefill above forty thousand tokens per second at every measured length, and generation past two hundred tokens per second make it the clear answer for long-document work on one box.

Pick it on ai11-class desktops when one person wants a private assistant on a quiet machine: best overall in our sweep there, fast prefill for long prompts, and the Gufo engine with multi-token prediction as the configuration to choose. Avoid the Windows side and the no-draft builds unless you have a specific reason; they are measurably slower.

Skip it, or check our other model pages, when closed-book factual recall on narrow regulatory content is the primary job, when you need a single one-unit pod result (unmeasured for this model), or when your efficiency target cannot tolerate the eight-unit engine's energy profile.

Where to go next

• LLM benchmarks hub
• Leaderboards
• How we measure
• Model tier list
• Private AI solutions
• Private LLM guide
• CMMC compliance

FAQ