GDN Tree-Scan: Served Tree Verification for Recurrent-Hybrid Language Models

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

watch

research area

speculative decoding

technical change

Tree speculative verification for recurrent-hybrid LLMs

published

2026-09-20

The method requires a specific GDN-hybrid checkpoint, a custom vLLM integration, and hardware headroom beyond one 24 GB GPU, while delivering a decode-throughput gain that does not translate into meaningful end-to-end latency improvement for typical prefill-heavy production workloads.

1. claim 01Paperraft inference
   Read the brief interpretation

   Replaces native sequential multi-token (MTP) decode verification in Gated-DeltaNet hybrid models with a tree verifier that replays branch-local recurrent state so each candidate is conditioned on its true root-to-node history, integrated into vLLM with FlashAttention-2 tree-bias attention and device-side draft commitment. Costs a custom serving stack (specialized kernels, scan/replay logic, accepted-chain-only state publication) and is demonstrated only on a 27B FP8 checkpoint that exceeds a 24 GB GPU budget. Can fail because correctness is shown only via recurrent-oracle p-rescore closure within the observed native flip floor rather than a full distribution-equivalence proof, and the decode-only gain shrinks to roughly 4% latency and little end-to-end improvement on prefill-heavy workloads.

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

   Inspect the source
2. claim 02Paperraft inference

   A six-node root-branch tree yields 23.88 vs 18.80 token-weighted decode tokens/s against native five-step MTP (a 27.0% decode-throughput gain) at batch one on Qwen3.6-27B-FP8, with +4.0% per-request-equal latency and prefill-dominated end-to-end wall time.

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

   Inspect the source