DScale: Scaling Block-Diffusion Speculative Decoding with Adaptive Verification

Your self-hosted model spends too long generating answers token by token.

What you would change

Check whether a compatible draft model and serving integration exist before renting compute.

Check whether a compatible draft model and serving integration exist before renting compute.

Compare against

The same target with speculation off, then your existing drafter if you have one.

1. Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.
2. Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.
3. Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.
4. Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test.

What to measure

Accepted draft length, tokens per second, tail latency, output quality, and total GPU cost.

When to keep it

Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation.

recommendation

test

research area

speculative decoding

technical change

Adaptive verification for block-diffusion speculative decoding

published

2026-09-29

The gains are measured on a single 40GB GPU with 4B-8B models at concurrency 8-32, which matches constrained infrastructure, but the method only applies if the reader already runs or is willing to adopt block-diffusion speculative decoding, so workload-specific validation on that stack is required before production commitment.

1. claim 01Paperraft inference
   Read the brief interpretation

   DScale replaces uniform-truncation verification in block-diffusion speculative decoding with path-aware tiles, dynamic verify-length packing, fixed-address graph-reusing workspaces, and a 112K-parameter acceptance predictor, while preserving drafter weights and full draft length. The cost is systems complexity: it requires an existing block-diffusion speculative decoding stack (it is benchmarked only against DFlash/DSpark/Domino on A100-40GB with Qwen3 models), plus integration of the predictor and custom workspace/graph management, not a drop-in change to standard autoregressive serving. It can fail if the reader's workload is autoregressive rather than block-diffusion, if acceptance behavior shifts on domains outside the four evaluated datasets (the predictor is frozen per target), or if the engineering cost of reimplementing the scheduling and graph-reuse machinery exceeds the throughput benefit at the reader's concurrency levels.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source
2. claim 02Paperraft inference

   Geometric-mean throughput gains of 43.9% (Qwen3-8B) and 48.8% (Qwen3-4B) over DFlash, 22.2-37.7% over DSpark, and 24.4-32.0% over Domino across four datasets at concurrency 8-32; complete decode-step time on GSM8K decreases by 30.8-52.5% relative to DFlash.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source