DFlash 2 vs MTP Speculative Decoding on RTX PRO 6000

Speculative decoding is the cheapest speed anyone is selling for a dense model on a single card this year. Guess a few tokens ahead with something small, let the big model check all the guesses in one pass, keep what matches. No retraining, no quality loss, and on paper a 2x to 3x faster stream. Everyone serving a 27B-class model on one 96 GB GPU is being asked whether to take the next step, which is a dedicated drafter: a second, smaller model living on the same card whose only job is to guess for the first.

The candidate this month is DFlash 2, the official block-diffusion drafter for Qwen3.8-27B. Its model card reports 2.7x to 3.4x over plain decoding at one request on an H200. NVIDIA’s write-up of the method says up to 15x on Blackwell. Those numbers land on the most expensive line in a serving budget: tokens per second per GPU.

Here is the catch for us. Our 27B already speculates. It ships with its own multi-token prediction head, MTP, and we ran it in production at three draft tokens. So the question is narrower than “is speculative decoding worth it”: is a second model on the card worth more than the drafter the checkpoint already carries, on our card, on our traffic?

So we put both on one RTX PRO 6000 Blackwell Max-Q, the 300 W workstation edition, with the same harness, prompts and power meter, next to plain autoregressive decoding. The profile now serving on the card, DFlash 2 on vLLM 0.33.0 with the drafter in FP8, decodes code at 303.3 tokens per second on one stream, 2.16x what our old production MTP profile did, and math at about the same speed (295.9 on the BF16-drafter arm). On free-form prose it does 162.6, 1.51x, because the drafter guesses prose much worse than arithmetic. At 32 concurrent streams it delivers 1,617.5 tokens per second, 3.18x the old profile, and almost none of that last number is the drafter: against an MTP profile with the same memory and request slots, the lead at 32 streams is inside the noise. Most of what looked like an MTP ceiling was one setting in our own production profile. This profile has served on the card since November 7.

Why One Card Matters More This Year

This card has quietly become the standard edge inference box, and it has done so while getting harder to buy. The RTX PRO 6000 Blackwell launched in March 2025 at $8,565. NVIDIA’s own store raised it to $13,250 in June 2026, 55% over launch, and to $16,000 in August, 87% over launch, where it still stood in November with the listing out of stock and resellers asking $16,000 and up for new units. The NVIDIA Inception partner newsletter this autumn quoted members a 32-week lead time on it. The data-center parts are on the same curve for the same reason: memory. TrendForce reported in January that GDDR7 and GDDR6 prices had risen several hundred percent in a few months and that the H200, at $30,000 to $40,000, would rise further because each one carries six stacks of HBM3E whose supply price had climbed about 20%.

So the shape of inference hardware is changing under us. A 96 GB card that a workstation or a 2U box can take, bought when it can be bought, is what most teams outside the hyperscalers will actually run a 27B-class model on, and it will serve more traffic than it was sized for before a second one arrives. That is why a software result like this one is worth a careful measurement rather than a model-card glance: when the card is the constraint, tokens per second per card is the number that decides how many users one box carries, and speculative decoding is the one lever that moves it without touching the weights or the quality.

It is worth pausing on why this was not supposed to be possible. A dense model has no shortcut in decode: every token walks through every layer, and every layer’s weights come off the memory bus to do it. One token costs one full read of the weights, and this target is about 21 GiB of them on a bus rated at 1.8 TB/s, so the card cannot read them much more than 80 times a second no matter how clever the kernels are; our plain-decoding arm, at 62 tokens per second, was already close to that wall. Until a year ago the only lever on that physics was quantization, which makes each read lighter, and this checkpoint had already taken that lever to 4 bits. Speculative decoding does not break the law, it changes what one read buys: the same pass over the weights now verifies seven candidates instead of producing one token, and the bus cost is amortized over however many the target accepts. That is the whole trick, and the surprise is how well a small drafter conditioned on the target’s own hidden states can guess. One user on one card, with the same model and the same answers, went from 62 to over 300 tokens per second on code and math, and a fine-tuned 27B serving a person or a small team above the 200-tokens-per-second mark is now a configuration, not a research result.

It also makes the engineering behind the drafter worth naming. DFlash is the work of Jian Chen, Yesheng Liang and Zhijian Liu, published as Block Diffusion for Flash Speculative Decoding with code at z-lab/dflash; the same team, now Inco AI, released DFlash 2 in August 2026 with a path selector and two small convolutions that lift the accepted block length about 21% over the first version at under 1.5% extra latency per cycle. The numbers below are what that work buys on one card at 300 W, measured rather than quoted. It is a very good piece of work.

The Incumbent Already Speculates

Qwen’s MTP head is one extra transformer layer trained alongside the model and stored inside the same checkpoint. It takes the model’s last hidden state and guesses the next token; to guess three, it runs three times, each pass reading the guess it just made. The full model then verifies all three in one forward pass, keeps the longest prefix that matches what it would have produced itself, and adds one token of its own. Best case, four tokens for one big pass plus three small ones.

It earned its place in production the hard way. In our August campaign on this card, the same checkpoint decoded one stream at 60 tokens per second without speculation and 114 with MTP at three drafts, at a 1k-token context. Two drafts netted behind three everywhere, even though each draft was accepted more often. Five crashed with an illegal memory access at the first 32k-token prefill. Three was the best number that survived, at a cost of about 130,000 tokens of KV pool and no extra weights. None of this is universal: on a different model on this same card, MTP made decoding slower, not faster. Speculation is a property of the model, the card and the traffic together.

Seven Guesses in One Pass

DFlash changes how the guessing is done, not how it is checked.

Picture a Saturday at home. You are cooking, and your kid is fetching from the pantry. With MTP, you call out one item, wait for it to arrive, look at it, and call out the next. Three items cost three trips. DFlash is handing the kid a basket and a list of seven, and he comes back once. Now scale that to a distribution center: the trips are forward passes on a GPU, the basket is a block of tokens, and the person at the loading dock who checks the basket is the target model. The checker does not care how the basket was filled. They open it, accept everything up to the first wrong item, and throw the rest away. If the dock is quiet, a bigger basket is free speed. If trucks are already lined up out the gate, every wrong item in the basket is dock time stolen from a real delivery.

That last sentence is the whole economics of speculative decoding, and we will come back to it.

Mechanically, the DFlash paper replaces the autoregressive drafter with a small block-diffusion model, conditioned on features from several target layers injected into the key and value projections of every draft layer. It receives the last real token plus a block of mask positions and fills them all in one forward pass, attending across the block in both directions, so drafting cost is close to flat in the block length. DFlash 2, trained for Qwen3.8-27B, keeps the top 16 candidates at every position, adds a small selector that traces one coherent path through them, and uses two-tap dynamic convolutions to keep the draft from decaying toward the end of the block. Block size is 8, so 7 draft tokens per step. Verification is the standard speculative rule, so greedy output matches the target exactly and sampling preserves its distribution.

The price is that the drafter is a real model: five layers, about 1.9B parameters, 3.6 GiB in BF16, borrowing the target’s embeddings and output head, resident on the same 96 GB as the model it serves.

What the Brochure Measured

Read the model card’s tables to the bottom, because the headline lives in the first row and the operating truth lives in the last one. On one H200 with SGLang, at temperature 1.0 and maximum reasoning effort, DFlash 2 averaged 4.1 to 5.5 accepted tokens per step depending on the task. At one request it ran 2.7x to 3.4x faster than plain decoding; at eight, 2.3x to 2.9x; at thirty-two, 1.0x to 1.45x, and 1.01x on MT-Bench, the most chat-like task in the set. MTP at seven drafts, at 32 requests, was slower than no speculation on four of five tasks.

The 15x from NVIDIA is real and specific: gpt-oss-120b on TensorRT-LLM across eight GPUs in a DGX B300, measured at 500 to 600 tokens per second per user. Useful, and not a statement about a 27B dense model on one 300 W card. The vendors published the falloff; it just never makes the headline, and the headline is what gets quoted in the meeting where someone decides to buy.

How We Measured

One RTX PRO 6000 Blackwell Max-Q (sm_120, 96 GB, 300 W limit), driver 595.91.07, CUDA 13.3, in the workstation we call ai02. The target is unsloth/Qwen3.8-27B-NVFP4: a dense 27B with a hybrid body (48 Gated DeltaNet linear-attention layers, 16 full-attention layers), its first 56 MLP blocks in 4-bit NVFP4 weights and activations and the rest of its linear layers in FP8. The drafter is incoai/Qwen3.8-27B-DFlash2. Both pinned by commit.

The memory-matched arm and the engine controls keep this article honest. Compared against the old production profile alone, the drafter would get credit for everything the newer engine and the bigger memory and slot budget bought on their own.

Workloads: 512-token essays at 1 to 32 concurrent streams, the first 200 GSM8K problems graded by exact match, 32 HumanEval prompts, and single 1.3k to 79k-token prompts for prefill. Greedy at low reasoning effort, as in production, plus a pass at the drafter card’s sampling (temperature 1.0, top-p 0.95, top-k 20).

Nothing forced generation past its natural end. The common shortcut, ignore_eos, is poison for speculative decoding: past its natural end a model drifts into repetition, repetition is the easiest thing in the world to predict, and the benchmark reports a speedup on text no user will ever receive. Our own harness had it on for decode probes the day before, on a different model. We banned it. (The essays are long enough to run to their 512-token cap; math and code answers stop where the model stops.)

The metric we trust most is acceptance length, the mean number of tokens kept per verification step, read from the engine’s own counters. Tokens per second moves with the engine, the batch and the clock. Acceptance length is the drafter’s grade on your traffic, and it travels to another card. Board power was sampled every two seconds. Run-to-run noise was about 3% at one stream and 5% at eight.

One Stream: Where the Drafter Should Win

At one stream, DFlash 2 is the fastest thing we have run this model with, and how much faster depends almost entirely on what you ask it to write.

Read the GSM8K row against the vendor’s: 236.1 tokens per second and an acceptance length of 5.46 on an H200 at temperature 1.0, against our 295.9 and 6.21, greedy. That is not our card beating an H200; greedy decoding at low reasoning effort is friendlier to a drafter. It does say the drafter loses nothing on workstation silicon at one stream.

The essay row is the one to plan with if your traffic is conversation: the served profile is 1.51x the old production profile and 1.40x MTP on the same new engine. Good, and nowhere near the math numbers. Prefill did not move: every arm landed between 6,976 and 9,005 tokens per second up to a 20k-token prompt.

Under Load, and the Batch-Size Schedule

Single-stream speed is what a person at a keyboard feels. Aggregate throughput is what the card earns, and speculation trades one for the other.

This is the loading dock with trucks lined up, and on this card it fills early: the Max-Q drew about 299 W in every DFlash 2 and plain-decoding level from one stream upward, with no spare power for verification to soak up. Static seven drafts delivered 1,209.3 tokens per second at 32 streams against 1,366.7 for plain decoding on the same engine, after leading 791.6 to 446.4 at eight. The findings put the crossing at about 24 streams.

The fix is a batch-size schedule. vLLM lets the speculative config change the draft length with the number of running requests (num_speculative_tokens_per_batch_size). We set seven drafts from 1 to 12 requests and three from 13 to 32. That recovered 32-stream throughput from 1,209.3 to 1,551.9 in the sweep, and above 12 requests the profile behaves like MTP at three drafts, with the same acceptance length of about 2.6, which is the point.

Now the uncomfortable part, which is ours. Against the old production profile, the served DFlash 2 profile is 1.62x at 8 streams and 3.18x at 32. Most of that is not the drafter. The production profile was capped at 6 request slots, so at 32 streams it was queueing, with a median time to first token of 24.2 seconds. The same engine with the same MTP head and 32 slots delivered 1,545.9. Against that arm the served profile is +15.2% at 8 streams and +4.6% at 32, the second inside our noise; on GSM8K at 8 streams the gap is real, 1,369.6 against 835.7, +63.9%. That ceiling was a setting we chose in August for a handful of agents, and nothing had pushed against it since.

Queueing, not the drafter, decides time to first token. At 8 streams the production profile’s p95 was 5,401 ms; DFlash 2’s was 198 ms and the memory-matched MTP arm’s 219 ms.

Acceptance Is the Honest Number

The drafter’s grade depends on the subject. On GSM8K and HumanEval it kept 6.2 tokens per step out of a possible 8, against 3.6 out of 4 for MTP. On free-form essays it kept 3.31, against 2.73. (The served FP8 drafter gives up a little of that on prose, 3.04, and none on math, 6.20.) The card’s 4.1 to 5.5 sits between our extremes, which is what a task set mixing chat and math should produce. Prose is open-ended: at any word there are several good next words, and a drafter guessing seven ahead is right about the first and increasingly on its own after that. Arithmetic and code are closer to dictation.

At the card’s sampling, acceptance dropped as it should and the advantage held: 2.9 on essays, 5.91 on code and 5.92 on GSM8K (at 8 streams), against 2.51, 3.5 and 3.51 for the production MTP profile.

Lossless is a claim worth checking, so we graded it. Every arm answered the same 200 GSM8K problems at every level and scored between 193 and 197; the BF16-drafter arm scored 196 at 8 streams, the same as the production profile, and the served FP8-drafter arm 195. That spread is batch and engine noise, and it agrees with the mechanism.

Where the Speed Came From

On GSM8K at one stream, moving MTP from vLLM 0.27.1 to 0.32.0 with the same request budget took it from 140.4 to 162.4 tokens per second, +15.7%. Swapping MTP for DFlash 2 on 0.32.0 took it to 294.7, +81.5%. Moving to 0.33.0 added +0.4%. On essays the same steps were +10.2%, +28.1% and +3.0%. Most of the speed is the drafter. A real slice is the engine, and that slice applies to MTP too.

What the Sweep Taught Us

About twenty configurations went through the sweep on vLLM 0.32.0, one factor at a time against a base of seven static drafts, and most of what we learned came from the ones that lost.

Draft length. Three drafts was the best at 32 streams (1,672.8) and the worst at one (121.5). Five was within noise of seven on essays and clearly behind on GSM8K at eight streams (1,127.8 against 1,245.5), where the longer draft pays. Nine, above the trained block size, was accepted by the engine without complaint and pushed GSM8K acceptance to 6.99, the highest number in the run, while throughput at eight streams fell from 791.6 to 644.7. More tokens accepted per step, more verification work per step, less output. Remember that the next time someone quotes an acceptance length without a throughput beside it.

The schedule was the only knob that moved 32-stream throughput by more than noise in the right direction, +28% for the one we chose. A variant that set zero drafts above 24 requests did not behave like plain decoding in this engine: 998.8 tokens per second at 32 streams, below plain decoding’s 1,366.7. We do not know why yet; it lost, and it is in the chart. CUDA graphs: piecewise, our production mode, cost 8% at one stream and 10% at eight; full graphs cost 5% and 8%, and 15% on GSM8K. The default, full graphs for decode plus piecewise for prefill, won everywhere. Draft attention: the log confirms it, Using FlashInfer for draft model non-causal attention; Triton was within noise, and FlashAttention is not offered on sm_120 at all. Nothing: a doubled prefill budget, and the KV dtype, because this checkpoint ships its own static FP8 KV scheme and auto already uses it. Halving request slots to 16 made 32 streams queue (-15%).

Workstation Blackwell Is Not Datacenter Blackwell

Every headline number in this field was measured on a datacenter part. The model card is an H200 with FlashAttention 3, a Hopper kernel. NVIDIA’s numbers are B200 and B300, the sm_100 class. Our card reports sm_120: same marketing name, different compile target, different kernels. When we tested an aggressive KV-cache quantizer on this card, every preset loaded and then died at the first prefill with an unsupported-PTX error. “Supported on Blackwell” had meant datacenter Blackwell.

This time the stock path held. Three vLLM builds ran the drafter on this card from published wheels, and every startup log was clean of Marlin, the weight-only fallback that quietly replaces native 4-bit compute when the fast path is missing. The cost was time: 21.5 minutes for the first start on 0.33.0, most of it FlashInfer compiling kernels for the 12.0a target.

We also tried b12x, the kernels written for this class of card. On the 4-bit layers the b12x GEMM tied the default, a geometric mean of about 1.00 across ten matching cells. FlashInfer’s b12x variant was 3% to 5% slower. Selecting b12x for every linear layer failed at load, because the checkpoint’s per-channel FP8 layers have no b12x kernel. And b12x attention cannot run on this model: it needs KV pages of 64 or 128 tokens, and the hybrid architecture forces a 1,664-token page so attention blocks line up with the linear-attention state, the same alignment mechanic that decided the KV budget in our cache quantization work. It is also causal-only, so the drafter could never have used it. Four honest “no” answers; the default is the right path on this card today, and credit belongs to the people who made it the default.

The other difference is the power limit. An H200 runs at up to 700 W. A method that converts spare compute into speed has less to convert on a card already at its ceiling. Physics doesn’t negotiate, even with a very clever drafter.

SGLang or vLLM for DFlash 2?

On this card and this checkpoint, vLLM, by a wide margin, and the drafter is not the reason.

The prior that SGLang is the faster home for this drafter is reasonable: every number DFlash 2’s authors published is an SGLang number, SGLang merged DFlash 2 two days before vLLM’s support, and its cookbook has a recipe for exactly this card. What we could not find was a published head-to-head of the two engines for this drafter. The prior was a timeline and a vendor table.

So the same harness ran against SGLang 0.5.23 (torch 2.14.1, FlashInfer 0.7.2, its kernel wheel shipping sm_120a binaries), same target, same drafter, greedy, block size 8:

Same acceptance length, 35% slower at one stream. The no-speculation row says where the gap lives: in the target’s own forward pass, not in the drafter. SGLang ran the 48 linear-attention layers on its Triton path, Linear attention kernel backend: decode=triton, prefill=triton, verify=triton, where vLLM picks FlashInfer’s kernels on this card automatically.

Three operational findings matter as much as the speed. A correctness trap: with BF16 KV cache, SGLang’s output was fluent and ignored the prompt entirely, 0 of 40 GSM8K problems right. FP8 KV fixed it, with the engine noting Using FP8 KV cache but no scaling factors provided. Defaulting to scaling factors of 1.0., which means it ignored the checkpoint’s own calibrated scales. Nothing failed; the answers were just wrong, which is the most dangerous kind of failure because it reads fine. Capacity: max_running_requests is capped to 11 by the mamba state cache (max_mamba_cache_size=59, 5 state slots per request), so the 32-stream level could not be measured at all without changing the linear-attention state to BF16, a deviation from the checkpoint. And per-request reasoning_effort was silently ignored (enable_thinking was honored), and the launch needed two fixes before it served correctly. The first boot spent 1,175 seconds compiling kernels; later boots took 50 to 100.

We planned block sizes 6 and 4, the kernel toggle and the full suite, and skipped them. With one stream never approaching 140 tokens per second, against 153.4 on vLLM, no smaller block could close the gap, and the GPU hours were better spent on the next two questions. vLLM 0.33.0 is the served engine, and it is the one with the batch-size schedule SGLang lacks.

Does the Quantized Target Cost Acceptance?

There was a reason to suspect the drafter was fighting with one hand tied. The checkpoint we serve is a post-training quantization, with Unsloth’s own figures putting its top-1 agreement with the BF16 model at 92% to 97%. The drafter was almost certainly trained against a BF16 or FP8 target, per the SpecForge recipe that matches its layout (Inco has not published its own run, so that is an inference). Every disagreement between the 4-bit target and the BF16 model would reject draft tokens for reasons unrelated to the drafter, and our own research note estimated a 10% to 20% loss in acceptance length.

It did not hold. Same drafter, same flags, vLLM 0.33.0, with the original BF16 model as the target:

Within about 4% in both directions. Quantizing the target to NVFP4 costs no measurable acceptance length, so re-training the drafter on the quantized model’s outputs, a GPU-day or more with the card out of service, is not worth doing. The estimate was wrong, and I would rather print that than quietly drop it. The tok/s row is the other lesson: verifying against a BF16 target reads twice the bytes per step, and the whole stack barely beats 4-bit decoding with no drafter at all.

The drafter in FP8. At one stream the drafter is about 15% of the bytes read per step, so quantizing it is a bounded bet: at most about 7% for FP8 at one stream, close to nothing at 32. We quantized the BF16 drafter to FP8 per-tensor on load ("quantization":"fp8_per_tensor" in the speculative config). The log confirmed it, Selected CutlassFP8ScaledMMLinearKernel for Fp8PerTensorOnlineLinearMethod on the draft layers, and model memory fell from 24.98 to 23.26 GiB. A first single run came in at +4.7% on one stream, which is not enough to ship on, so it went through a confirmation arm at the production utilization of 0.83 with four gates set before it ran:

All four gates passed, and the FP8 drafter shipped. Read the headline with its error bar: +6.0% at one stream is about twice our run-to-run noise there, from one run per cell. The drafter gives up a little acceptance on prose (3.04 against 3.31) and wins it back in bytes; on math it loses nothing. GSM8K at one stream, prefill and code at 8 streams were not re-run on the FP8 configuration, which is why the one-stream GSM8K figure stays the BF16-drafter arm’s 295.9.

The Bill: Watts, Joules and Gigabytes

With the card at its limit from the first request, energy per token tracks throughput. At one stream on essays the production MTP profile delivered 0.37 tokens per joule at 281.6 W, plain decoding 0.20 at 299.3 W, and the served DFlash 2 profile 0.50 at 298.8 W: a little more power, the work finished much sooner. On GSM8K at 8 streams it was 4.58 tokens per joule against 2.21 for the production profile. At 32 streams on essays, 5.39 against 5.17 for memory-matched MTP.

Then the memory. MTP costs no weights, only a slice of KV pool for its draft positions. DFlash 2 brings its own weights, its own KV for the draft layers and its own CUDA graphs. On vLLM 0.32.0 at the same 0.85 utilization, the MTP control’s KV pool held 1,558,219 tokens and the DFlash 2 arm’s 848,173: the drafter cost 710,046 tokens, 46% of the pool. That is the second model on the card, in the only unit capacity planning cares about. On 0.33.0 the pool came back: 1,122,468 tokens at 0.85 with the BF16 drafter, and 1,146,396 tokens, 4.37 full 262k-token contexts, in the served unit at 0.83 with the FP8 drafter. Sampling raised peak card memory by 1,156 to 2,052 MiB over greedy on the benchmark arms (to 84,186 MiB on the 0.33.0 BF16-drafter arm), which is why production runs at 0.83 rather than the 0.85 we benchmarked. This card also hosts speech-to-text and a text-to-speech service; those gigabytes have names.

What runs on the card now, since the cutover on November 7 at 23:31 UTC, replacing the MTP profile:

Measured in production, through the same API the clients use, with thinking off and greedy decoding: 145.5, 712.0 and 1,574.3 tokens per second at 1, 8 and 32 streams. That is a little below the benchmark arm, because of the lower utilization and the probe traffic sharing the card, and it is the number we plan with.

For whoever signs for the hardware: a drafter is a capital-free speedup you pay for in KV capacity and must tell when to stop, so it is worth exactly as much as your traffic is interactive and structured. If most tokens go to one person waiting on code, math or tool calls, it is the best deal on the card, 2x on the stream they are watching. If most go to a full batch of open-ended prose, it is a few percent and a slice of context capacity, and the bigger win may be the request slots you never raised.

Keep It Honest

This is one model, one card and one day. The essays run to a 512-token cap, so they measure steady-state prose, not a full conversation. Our acceptance lengths are greedy at low reasoning effort and the vendor’s sampled at maximum effort, comparable in shape, not in value. Power is board power, not wall power. The SGLang result is one configuration of an engine whose linear-attention kernels have not caught up on this card; it is a verdict on today, not on SGLang. And the benchmarks ran with nothing else on the card, the cleanest case a drafter will ever get.

Some losses we have not explained: the zero-draft tier in the schedule was slower than plain decoding, and the 8-stream sampled level stalled on 0.32.0 and 0.27.1 (not 0.33.0) with a 1.6-second median time to first token, common to both engines, cause unknown. And the biggest number in this piece, 3.18x at 32 streams, is mostly a request-slot setting we should have raised months ago. The useful finding is the other one: against MTP given the same memory and slots, the drafter is worth about 2x on structured work at one stream, about 1.3x on prose, and very little at 32 streams.

That is still the best deal on the card for the way this lab uses it: one or two people waiting on code, math and tool calls, most of the time. A bigger basket is free when the dock is quiet. When the trucks line up, the schedule hands the job back to three drafts, and the dock never knows the difference.

Sources

• DFlash paper: Jian Chen, Yesheng Liang, Zhijian Liu, DFlash: Block Diffusion for Flash Speculative Decoding, arXiv 2602.06036, February 2026; project page z-lab.ai/projects/dflash, code github.com/z-lab/dflash.
• DFlash 2 drafter for Qwen3.8-27B, model card and H200 tables: incoai/Qwen3.8-27B-DFlash2 (mirror: z-lab/Qwen3.8-27B-DFlash2).
• Inco AI, DFlash 2: Keep Drafting Parallel, 18 August 2026 (path selector, two-tap dynamic convolutions, +21% acceptance length over DFlash on Qwen3.5-4B).
• RTX PRO 6000 Blackwell pricing: Tom’s Hardware, Nvidia raises RTX Pro 6000 Blackwell GPU pricing to $13,250, June 2026; Thunder Compute, NVIDIA RTX PRO 6000 Blackwell Pricing (November 2026) ($16,000 list since August 2026). The 32-week lead time is from the NVIDIA Inception partner newsletter, autumn 2026 (members only).
• Memory-driven GPU price increases: TrendForce, NVIDIA, AMD Reportedly Plan Price Hikes Starting 1Q26, 5 January 2026.
• NVIDIA Technical Blog, Boost Inference Performance up to 15x on NVIDIA Blackwell Using DFlash Speculative Decoding.
• vLLM documentation, Speculative Decoding; the Qwen3.8-27B serving recipe; DFlash 2 support, vLLM PR #52816.
• SGLang DFlash 2 support, PR #35371.
• Target checkpoint and quantization notes: unsloth/Qwen3.8-27B-NVFP4, Unsloth Qwen3.8 guide; drafter training recipe: SpecForge, Qwen3.8-27B DFlash2.