From many candidates to three profiles: Qwen3.8-27B with MTP and DFlash2

The fastest decoder did not automatically become the best everyday profile. That is the central result of this test series. On the same machine, with the same Qwen3.8-27B target family and weight quantization, MTP and DFlash2 configurations were tested in stages: a broad candidate screen, an identical-history rerun, an official-runtime migration, 40 isolated starts, image input, and finally a real read-only production-repository review.

The machine and the exact model base

Reasoning effort was not a controlled variable. Agent records contained reasoning-related fields, but this study did not select, sweep, or isolate reasoning effort. No speed or quality difference is attributed to it.

The wide screen

The first field included P0 without speculation, M3 and M3K with MTP, and D5 and D5K with DFlash2. M3K and D5K advanced. A combined KN route missed the required +3% gate, the n-gram-mod path starved, and K1/K2 tuning regressed.

This was not a two-profile showcase with a winner chosen in advance. Plausible configurations had to earn promotion.

The false winner

An early warm-history result appeared to put D5K 12.4% ahead of M3K. Review of the test code then found that the histories were not identical. The measurement stayed in the audit trail, but it was removed from winner selection.

With a golden, identical history, M3K finished in 53.614 seconds and D5K in 119.756 seconds. D5K also showed 9–21 second TTFT under a thin VRAM margin. The protocol correction mattered more than the apparent ranking: different histories do not produce a fair speed comparison.

Moving DFlash2 to the official runtime

Before promotion, DFlash2 was moved from the old fork to official llama.cpp b10658. In the warm nine-turn bridge, N=7 moved from 114.02 to 118.12 effective tok/s. N=4 and N=5 stayed nearly unchanged, and the non-speculative baseline remained in the same broad range on both builds. N=6 collapsed to roughly 34–37 tok/s at large context and was rejected.

DFlash2 also failed to produce usable image output in the tested path. It therefore remained a text-only candidate.

Why decode speed did not win every workload

On a filled 56,093-token prompt, D7K decoded at 124.13 tok/s, well ahead of M3K's 78.52. Yet M3K completed the whole request sooner: 34.367 seconds versus 36.840. Prompt evaluation dominated the complete request more than the decode segment did.

The sustained nine-turn agent history told the opposite story. D7K-90K finished in 44.064 seconds, D5K-100K in 47.255, and the two M3K candidates around 52.5 seconds.

This is why a single TPS leaderboard would be misleading. The prompt-heavy job and the sustained-generation job reward different parts of the pipeline.

Forty isolated starts

Four daily candidates went through 40 isolated server starts. All 40 requests ended naturally. There were no OOMs, empty responses, truncations, or request failures. All profiles passed near-cap retrieval. All produced functionally correct code that passed five executable tests after the surrounding Markdown fence was removed; all failed the same strict format rule because they added that fence.

M3K-128K offered no meaningful daily speed gain over 120K while reducing measured minimum headroom from 699 to 345 MiB. D5K-100K was dominated from both sides: D7K was faster for sustained text, while M3K-120K offered more context and more headroom.

Three profiles survived

The 120K MTP profile became the everyday local coding-agent default. It preserved almost all practical speed of the 128K candidate while leaving twice the minimum VRAM margin. The 90K DFlash2 profile became the sustained text specialist. The 90K MTP profile became the vision lane because DFlash2 remained text-only.

The vision check

The M3K-90K vision profile passed three independent image runs and one routed smoke test. Mean wall time was 2.034 seconds, TTFT 858 ms, prompt evaluation 1,323.92 tok/s, and decode 69.61 tok/s. MTP acceptance was 0.49020, mean accepted length 2.47, and minimum free VRAM 924 MiB.

The final lazy-load smoke returned the expected marker from all three promoted profiles: 7.830 seconds for vision, 9.212 seconds for M3K-120K text, and 9.793 seconds for D7K-90K text.

Synthetic winners meet a real repository

The final test was a read-only review of the same production repository. No source files were changed. This stage is not a pure model-only comparison: the two Qwen coordinators used Luna helpers, while direct gpt-5.6-luna used none.

The two local runs had almost identical raw decode throughput. M3K-120K still completed the recorded active work slightly sooner, reached first token faster, used cache more heavily, and avoided compaction.

M3K-120K completed all four helpers. In the D7K run, four of six helper launches hit usage limits; Qwen had to backfill their work and compacted once. This does not make D7K a poor decoder. It shows why end-to-end agent performance includes orchestration reliability.

The direct Luna run took 44:33.227 wall-clock time. At the 28-minute mark it was still inspecting the repository; the final writing phase took only about 27 seconds. It produced the strongest prioritization and the clearest critical-path analysis, especially around cross-channel apply idempotency and state-machine behavior.

The run recorded 94,028 output tokens, including 55,192 reasoning output tokens. The provider did not expose active inference time, decode duration, or TTFT. Dividing output by full wall time gives 35.174 output tokens per wall second, but that is not decode TPS and is not plotted against the local numbers.

Finding counts are coverage indicators, not a truth score. Luna's shorter list was more sharply prioritized; M3K-120K plus four completed helpers produced the broadest reported coverage in the shortest recorded active time.

The final operating model

The most useful answer is a layered workflow:

1. Broad first pass: Qwen3.8-27B-120K-Q8-M3K-Text coordinates the repository scan and delegates bounded checks to Luna helpers.
2. Critical adjudication: gpt-5.6-luna directly reviews high-severity state machines and resolves disputed findings.
3. Fast sustained local text: Qwen3.8-27B-90K-Q8-D7K-Official-TextOnly handles generation-heavy work when image support and maximum context are unnecessary.
4. Local image work: Qwen3.8-27B-90K-Q8-M3K-VisionVRAM handles mixed text-and-image input.

The experiment did not find one number that makes every decision. It found the point where each configuration stops being the right tool.

Limits and sources

The results are specific to this host, quantization, runtime build, context sizes, and workloads. The repository-review runs used different orchestration. Finding counts do not independently verify correctness. Luna telemetry cannot be converted into comparable decode TPS. Reasoning effort was not a controlled experimental variable.

• Qwen3 official repository
• llama.cpp official b10658 release
• DeepSeek Harness official repository
• OpenAI Codex official repository