spike(SPEC-DSPARK): scope DSpark semi-autoregressive block drafting - #211
Merged
Conversation
Commit the spike the 2026-08-08 grounding note promised, per POL-SPIKE-FIRST, for the developer goal "a full DSpark implementation in vllm.cpp, based on vLLM". Verified against the pin 555967922: DSpark's entire upstream surface is 1613 lines over 5 files, three of them `class X(DFlashY)` subclasses. Everything hard -- the non-causal in-block attention primitive, the multi-tap aux combine, context-KV precompute, the separate-draft loader, the --speculative-config plumbing and the verify/propose loop -- is already landed and gated under SPEC-DFLASH. The delta is A) a low-rank Markov logit-bias head (markov_rank=256 in every shipped checkpoint), B) sequential left-to-right block sampling, C) the sample_from_anchor N-query layout (the PrepareDflashInputs field already exists and is always false today; NumLookaheadTokens() already returns k for dspark), D) a reduced draft vocab with d2t remap, E) method/config resolution including the k >= dspark_block_size hard error, and F) Speculators-format config translation, of which we have none today. Draft checkpoints exist for BOTH gate models (RedHatAI/Qwen3.6-35B-A3B- speculator.dspark 1.90 GB, satgeze/Qwen3.6-27B-DSpark 8.80 GB) and for the 4B pair the upstream test itself uses, so the row is gateable without the DeepSeek-V4 hardware blocker; DSV4 DSpark stays out of scope. Records-only: no src/, include/, tests/ or examples/ change. SPEC-DSPARK moves INVENTORIED -> ACTIVE with the engine-matrix counters, the feature-matrix row, the coordination claim, NOW.md and the three public doc surfaces updated in the same change; the STATUS ratchet is re-pinned byte-tight at the reduced size. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
RED first: tests/vllm/config/test_speculative_dspark.cpp did not compile,
because ParseSpeculativeConfigJson rejected every method outside {mtp, dflash,
ngram, draft_model} (speculative.cpp:44) and SpeculativeConfig had no
ResolveDspark / IsDsparkDraft / use_dspark / parallel_drafting. 9/9 cases,
30/30 assertions green after the fix.
Mirrors the DSpark path of vllm/config/speculative.py __post_init__ exactly
@ 555967922:
* parallel_drafting = True for ("dflash", "dspark") :963-964
* n_predict defaults k when the draft config carries one :973-979
(only the Gemma4 branch maps block_size -> n_predict, :957-961; a native
Qwen3DSparkModel config carries block_size but NOT n_predict, so its k is
REQUIRED from the user -- which is why the upstream e2e test passes
num_speculative_tokens=7 explicitly)
* k above n_predict must be a multiple of it :980-988
* k missing with no n_predict is an error :990-994
* k below a DSV4-style dspark_block_size is a HARD error :1003-1027
("Smaller values produce incorrect output")
* IsDsparkDraft mirrors the auto-detection: name contains "dspark" OR
architectures name Qwen3DSparkModel / Gemma4DSparkModel :881-887
use_dspark() is deliberately NOT folded into use_dflash(): the scheduler
reserves k lookahead slots for DSpark against DFlash's k + 1
(scheduler.py:256-265), because DSpark's anchor query is itself the first
prediction rather than a separate bonus query. NumLookaheadTokens() already
returned k for dspark through use_eagle(); the test pins it.
The drafter itself (Markov head, sequential sampling, anchor layout) is W2-W5,
so model_loader refuses method "dspark" BY NAME rather than failing later with
a confusing message, and docs/USAGE.md says so. Nothing on the non-speculative
path changes.
Focused CPU gate on this tree: test_speculative_dspark 30/30, test_scheduler
423/423, test_speculative_draft_max_position_embeddings 10/10,
test_dflash_propose 31/31, test_model_registry 837/837.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
… layouts
W2, the Markov transition head (qwen3_dspark.py:36-67,132-147). DSpark IS the
DFlash draft plus this one head, and upstream says so structurally
(Qwen3DSparkModel(DFlashQwen3Model)), so Qwen3DSparkWeights COMPOSES the landed
Qwen3DFlashWeights rather than re-declaring it and every backbone forward is
reused unchanged on `.backbone`. New: markov_w1 [vocab, r] gathers the
PREVIOUSLY SAMPLED target token, markov_w2 [draft_vocab, r] projects it to the
draft-vocab logit bias, and map_draft_to_target applies the d2t OFFSET (the
table holds the offset, not the absolute id). markov_rank is 256 in every
shipped checkpoint.
W3, both checkpoint layouts. Verified against the two published families rather
than paraphrased: deepseek-ai/dspark_qwen3_4b_block7 (64 tensors, downloaded)
and RedHatAI/Qwen3.6-35B-A3B-speculator.dspark (66 tensors, safetensors header
read by range request). They ship the SAME unprefixed tensor spelling --
layers.N.*, embed_tokens, fc, hidden_norm, norm, lm_head,
markov_head.markov_w{1,2}, plus d2t (I64 offsets) and t2d (BOOL) when the draft
vocab is reduced -- and differ only in CONFIG: native is flat, Speculators nests
the backbone under transformer_layer_config. So one loader plus one config
translation (base.py:47-64,90-95 + algos.py:133-178), including the i-1
target_layer_ids and k from proposal_methods[0].speculative_tokens.
Faithful-mirror note recorded in the header: update_dspark does NOT consume
`sliding_window_non_causal` (only the DFlash updater does), so a DSpark draft's
per-layer causality comes from layer_types alone. Skipped exactly as upstream
skips them: t2d, mask_embedding, confidence_head.
Tests are RED-first and mutation-checked. test_qwen3_dspark_markov 71/71 --
scratch mutations "the head ignores the previous token" and "d2t read as an
absolute id" both KILL it (3 cases / 20 assertions), which is the point: the
prev-token dependence is the entire reason the head exists, and the DFlash
backbone alone cannot have it. test_qwen3_dspark_config 25/25 on the REAL
published 35B speculator config. test_qwen3_dspark_weights 33/33 on the real key
list, including the two silent-corruption cases (reduced vocab without d2t, and
a markov_w2 disagreeing with the config's draft vocab).
Still refused by name at the loader: the sequential sampler (W4) and the runner
(W5) are not here. Nothing on the non-speculative path changes.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…rface
W4, the sequential sampler (dspark/speculator.py:100-169). DFlash samples every
block row with one parallel argmax, so its k tokens are conditionally
independent given the context. DSpark samples left-to-right and adds a bias
derived from the token it just sampled, which is the whole point of the head.
Also the anchor-as-first-prediction layout: N query rows where every row
predicts (sample_pos = query_pos + 1), against DFlash's 1 + N fill-in. Our
landed PrepareDflashInputs already implemented BOTH (qwen3_dflash.cpp:126,
169-174) with sample_from_anchor dead at false; W4 makes it reachable.
The test's decisive fixture is a Markov head built so the bias DICTATES a chain
(markov_w1 = I, markov_w2[v][p] large iff v == (p+1) % V), so drafts must ramp
from the anchor. Scratch mutations kill it honestly: not chaining (feed the
anchor every step) fails 6 assertions, and always sampling from the anchor row
fails the 1+N layout case. 42/42 green.
W5, the runner and the surface. propose_drafts_dflash's 166-line body is
REFACTORED into a shared propose_drafts_block: everything through the aux
multi-tap, the per-request device KV store, the context accumulation and the
context-aware block forward is IDENTICAL for the two drafters (DSpark inherits
it upstream), so the two branches now differ only in num_query_per_req and in a
sampler callback. set_dspark_draft wires the inherited backbone through
set_dflash_draft, so the shared machinery is the same code. DFlash re-verified
after the refactor: test_dflash_propose 31/31, test_qwen3_dflash_forward 95/95.
The loader builds a DSpark draft from either config layout, translating the
Speculators one first. Three checkpoint-shaped details that would each fail
silently: a DSpark config keeps mask_token_id/target_layer_ids at the TOP level
(we synthesize the nested dflash_config the inherited helpers read, exactly as
upstream's getattr fallback does), sliding_window may be JSON null, and
rope_theta lives under rope_parameters. The draft's own embed_tokens/lm_head are
kept when shipped and only shared from the target when absent -- overwriting a
shipped reduced-vocab head with the target's would corrupt every draft.
Refused by name rather than silently degraded: a GGUF target (that axis is not
ported), and a missing num_speculative_tokens (a native DSpark config carries no
n_predict).
R1 IS ANSWERED -- the oracle RUNS DSpark. On dgx, one flock, worker parked:
Qwen/Qwen3-4B + deepseek-ai/dspark_qwen3_4b_block7 at k=7 loads and decodes, and
its DSpark-ON greedy output is TOKEN-IDENTICAL to its own spec-OFF output on
both prompts (48/48 tokens each). Recorded honestly: that oracle is the dgx
v0.25.0 stage, not the 0.26.0.dev0 pin, because the pin rebuild is a standing
residual. Evidence dgx:~/work/dspark-r1/{r1.log,r1_on.json,r1_off.json}.
Still open: W6, our engine gated against that stream. docs/ says exactly that --
"wired end to end, UNGATED", no correctness or speed number claimed.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…rafter INERT)
The e2e run is the point of the exercise and it found two things, one fixed here
and one left open and named.
FIXED: our DSpark arm on the 4B lane died at the FIRST propose with "missing
target aux multi-tap". Only the Qwen3.5/3.6 dense + MoE forwards implement
ForwardDeviceMultiTap, and BOTH block drafters condition on that tap, so classic
Qwen3ForCausalLM could never drive either -- latent for DFlash too. New
ModelBase::supports_aux_multi_tap() (default false, true on the two Qwen3.5
registrations, shaped like the existing supports_mtp_draft) plus a LOAD-time
refusal naming the method and the architecture instead of an engine-fatal
mid-run.
OPEN, and it corrects the reading of the 35B result: on
nvidia/Qwen3.6-35B-A3B-NVFP4 + RedHatAI/Qwen3.6-35B-A3B-speculator.dspark at k=8
(the reduced-vocab d2t + sample_from_anchor path) our DSpark arm runs to
completion and its text is byte-identical to our own spec-OFF decode -- but
re-running with VT_SPEC_TRACE=1 printed NO acceptance lines at all, so NO draft
token was ever verified. Identical output is therefore NOT evidence the
speculator works; it is exactly what an INERT drafter looks like, and 6.78 vs
37.34 tok/s (5.5x slower) is what paying for one buys. Recorded as the W6
blocker rather than dressed up as a pass.
The DFlash control that would have proved the trace harness itself works could
not be run: MakeDflashDraftConfig does c.at("rope_theta") and the z-lab 35B
DFlash draft carries rope_theta only under rope_parameters -- a pre-existing gap
in the landed DFlash lane, found incidentally, worth its own fix.
Also records R1 in the spike: the oracle RUNS DSpark and its DSpark-ON greedy
output is token-identical to its own spec-OFF output (48/48, both prompts), with
the v0.25.0-stage-not-the-pin caveat stated. Evidence dgx:~/work/dspark-{r1,w6}/.
docs/{FEATURES,BENCHMARKS,USAGE,SPECULATIVE-DECODING}.md say exactly this: runs,
zero verified draft tokens, no correctness or speed claim.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
mudler
force-pushed
the
row/SPEC-DSPARK
branch
from
August 10, 2026 00:59
56b7b60 to
76c404e
Compare
…ver installed
Adds VT_SPEC_TRACE instrumentation on the two sides the existing verify-side
trace could not distinguish, and uses it to correct the record.
What the trace shows on nvidia/Qwen3.6-35B-A3B-NVFP4 +
RedHatAI/Qwen3.6-35B-A3B-speculator.dspark at k=8:
[spec-propose] rows=1 nqpr=8 drafts/row=8 first=[13 198 12 2972 57590 ...]
one line per step, 24 of 24 steps: the drafter PROPOSES eight plausible
target-vocab ids every step from the anchor-layout block, so the Markov head,
the loader and the sequential sampler are doing their job on real weights.
And zero [spec-install] lines, so Scheduler::update_draft_token_ids is never
reached AT ALL -- not "reached and rejected". The break is between
pending_drafts_ / take_draft_token_ids() and EngineCore::post_step's install,
which localizes the W6 blocker to a three-call span instead of the whole lane.
CORRECTION, and it matters: the earlier commit reported our DSpark-ON text as
byte-identical to our spec-OFF text and read that as the self-consistency half
of the gate. A second run of the same binary, same prompt, temperature 0,
produced DIFFERENT text. The ON path is not deterministic and that identity was
a single-run coincidence, not a property. The claim is withdrawn; no correctness
claim of any kind stands. First mechanism to check: the aux multi-tap routes the
target through ForwardDeviceMultiTap, which may not be numerically neutral on
the 35B MoE NVFP4 the way it is on the gated 27B.
The scheduler traces cache their getenv in a static so the hot path pays one
branch when unset. docs/{FEATURES,BENCHMARKS,SPECULATIVE-DECODING}.md and the
spike all say the corrected thing.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…wo continues) The [spec-install] probe was placed after the request-not-found and is_prefill_chunk continues in update_draft_token_ids, so its silence proves the assignment never runs -- NOT that the function is never called. Says so, and names the one-line probe that decides it. Ruled out on the way, and recorded so the next session does not re-derive it: post_step IS on this path (max_concurrent_batches=1 => batch_queue_size_ == 1 => step_fn_ = &EngineCore::step, which calls post_step), and check_for_draft_tokens_ is satisfied by the dspark branch of ResolveSpecConfig. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…RY speculator's drafts were being discarded
Root cause of the SPEC-DSPARK W6 blocker, and it was never DSpark's.
EngineCoreProc's constructor called the base EngineCore(scheduler, executor,
structured_output_manager) WITHOUT the check_for_draft_tokens argument, so it
defaulted to false on the production path. post_step therefore returned at its
first guard, take_draft_token_ids() was never pulled, and no speculator's drafts
were ever installed on the scheduler. This affected MTP, DFlash, ngram and
DSpark alike through the CLI and the OpenAI server: correct output, one token
per step, full draft cost paid. The landed spec-decode gates did not catch it
because they drive the engine directly rather than through AsyncLLM ->
InprocClient -> EngineCoreProc.
Fixed by threading the flag through all four levels and passing
resolved_spec_config_.has_value() at the loader's AsyncLLM construction, plus
calling post_step(model_executed) in process_engine_step where a stale comment
("deferred; the sync EngineCore has no post_step yet") had left the proc loop
without it. post_step is idempotent -- take_draft_token_ids moves pending_drafts_
out -- so the step() path calling it internally cannot double-install.
How it was found, since none of it was visible from reading: VT_SPEC_TRACE
instrumentation on the propose side showed 24 proposals of 8 plausible ids in a
24-token run, the verify side showed zero, and a probe inside post_step showed
it was never reached past its guard.
After the fix, on nvidia/Qwen3.6-35B-A3B-NVFP4 + the RedHatAI dspark draft at
k=8, DSpark genuinely speculates:
[SPECTRACE] pos=8 k=8 ns=2 acc=1 draft=[3177 421 682 ...] emit=[3177 34756]
[SPECTRACE] pos=10 k=8 ns=3 acc=2 draft=[364 1141 12761 ...] emit=[364 1141 25438]
and throughput goes 6.78 -> 41.89 tok/s against 42.11 spec-off: from 5.5x slower
to parity.
STILL OPEN and stated as such in the docs: spec-on output is not yet
token-identical to spec-off and is not run-stable, so no correctness claim and
no speed win is recorded. The spec names the three next probes in order.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…ble on the 35B The earlier "ON diverges from OFF and is not run-stable" reading was a CONFOUND, and naming it matters: the spec-OFF arm had run with async scheduling ENABLED while the spec-ON arm forces it off, so the two arms differed in two variables. Re-run with BOTH arms on the synchronous path, 48 greedy tokens, nvidia/Qwen3.6-35B-A3B-NVFP4 + RedHatAI/Qwen3.6-35B-A3B-speculator.dspark, k=8: A spec-OFF sync 40.836 tok/s " Paris, a city renowned for its ..." B spec-OFF sync (repeat) 40.916 tok/s identical to A C DSpark k=8 40.174 tok/s identical to A D DSpark k=8 (repeat) 39.751 tok/s identical to A So on a gate model, with real draft acceptance behind it, speculative-on greedy output is token-identical to speculative-off and reproducible. That is the correctness invariant speculative decoding must satisfy, and it holds. SPEED IS NOT A WIN and is not claimed: ~2% BEHIND spec-off at c1. The sequential Markov stage is a host-side loop with a device round-trip per step, which the spike's R5 predicted, and acceptance from a bf16-trained draft over an NVFP4 target is modest. Still owed for a binding W6, and listed in the spec: the cross-engine comparison against the pinned oracle through the SACRED harness rather than an ad-hoc prompt, the acceptance-rate band, the speed A/B versus vLLM DSpark-on, and the 27B + Gemma4 (1+N layout) lanes. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
One conflict, in the docs/STATUS.md character ratchet, where main had landed two reductions (sm_110 build-list correction, BACKEND-TENSTORRENT W2) while this branch had landed one. Resolved per the keyed-record rule: main's comment history kept WHOLESALE, this branch's note appended, and the pin re-measured against the merged page rather than arithmetic (243582). NOW.md came back over its 6,000-character budget after the merge, so three of the longest rows are compressed in place -- BACKEND-ROCM, the state record and Vulkan 27B all keep their binding number and their next step, losing only restatement -- to pay for the SPEC-DSPARK row. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
…from the same draft The "~2% behind" number in the previous commit was a COLD single-shot measurement, where model load and first-request cost dominate. Warm (--repeat 3, c1, 128 tokens, same target + draft + k, one flock): ours spec-OFF 71.3 tok/s ours DSpark k=8 ~82 tok/s (79.5, 84.8) = 1.15x oracle spec-OFF 25.1 tok/s oracle DSpark 35.4 tok/s = 1.41x Acceptance accounting (VT_SPEC_TRACE, 48 tokens): 18 speculative steps emitted 48 tokens = 2.67 tokens/step, 1.67 accepted drafts/step out of k=8 = 20.8% acceptance. The honest comparison is the RATIO OF RATIOS, not the raw tok/s. The oracle arm ran enforce_eager with one generate() per prompt, which is not vLLM's production graphed config, and the house rule is that the denominator is graphed vLLM. Our 82 versus its 35.4 says nothing binding -- our own spec-off 71.3 versus its 25.1 is a 2.8x that the project's own 35B grid (0.93-1.03x) proves is an artifact of that handicap. What IS like-for-like is each engine's speculative speedup against ITSELF under identical settings: upstream 1.41x, ours 1.15x. So DSpark works and pays, and we leave roughly half the available speedup on the table. Named suspects in order: the sequential Markov stage is a host-side loop with a device round-trip per step where upstream captures the WHOLE draft step in one CUDA graph (dspark/speculator.py:22-24), and 20.8% acceptance wants checking against the upstream reference band before it is blamed on the draft checkpoint. Also worth recording: the oracle's own DSpark-ON output is NOT token-identical to its own spec-OFF on any of the 4 prompts, while ours is. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
Two conflicts, both keyed records, both resolved by the same rule: take the
target branch version WHOLESALE and reapply the scoped edit.
* .agents/engine-matrix.md counters -- main had added a Serving row (145 rows,
8 READY); this branch had moved SPEC-DSPARK INVENTORIED -> ACTIVE. Kept
main's table and reapplied only that move (Speculative 4 -> 5 ACTIVE,
11 -> 10 INVENTORIED; Total 22 -> 23 ACTIVE, 42 -> 41 INVENTORIED).
* the docs/STATUS.md ratchet -- kept main's comment history, appended this
branch's note, and re-measured the pin against the merged page (243572)
rather than doing arithmetic on it.
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: Claude Code:claude-opus-5 [Claude Code]
localai-bot
pushed a commit
that referenced
this pull request
Aug 10, 2026
PR #211's CI finished after the merge: 11 green (cuda-fat-build, both sanitizers, all three build-test lanes) and 3 red. Reproduced locally against the merged range rather than guessed at: pr-size REAL FAIL. Product changes total 2261 lines against a 900-line budget, and scripts/check-public-doc-tables.py was changed (the STATUS ratchet re-pin) with no accompanying mutation evidence in its test. The slices existed as separate commits, so splitting into six PRs was available and was not taken. agent-record PASSES on current main ("agent record OK: ENGINE=146 ..."). commit-protocol PASSES on current main ("OK: commit trailer contract"). The last two were stale-head/PR-base artifacts, and I checked that instead of assuming it. The first is a genuine budget breach. No retroactive waiver: POL-WAIVER-EXACT exists for a decision taken BEFORE the fact, not for laundering one after it. The record of the breach is the record. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
localai-bot
pushed a commit
that referenced
this pull request
Aug 10, 2026
Developer decision, on measured grounds rather than feel. Over the last 22 merged PRs the 900-line `product` budget was exceeded by 9 of them (41%): 71 76 78 129 178 182 237 338 340 479 596 605 895 | 1272 1306 1510 2261 2843 3224 4098 5282 6480 A gate that fires on four changes in ten is not a budget, it is noise that teaches people to waive it. Worse, tests are a third to a half of every large diff here (#211 909/2261, #197 684/1510, #240 931/2843, #196 2319/4098), so the budget charged RED-first mutation tests against the same allowance as kernel code, penalising exactly the discipline the rest of AGENTS.md demands. Size is now a review judgement: split a change when a reviewer would be better served by parts, not when a counter says so. WHAT IS NOT RETIRED, because dropping a size gate is not licence to drop the rules that shared its file: explicit path classification (no blanket directory exemptions), the fail-closed binary guard, the checker-change mutation-evidence contract, and the role check that keeps product paths on a PR. A new test pins all three so they cannot be deleted quietly alongside a constant. Evidence for this being a real checker-semantics change, per the contract this checker itself enforces: `test_no_line_budget_is_enforced_for_any_class` is RED against the pre-change checker (which exported PATH_CLASS_BUDGETS and rejected a 100k-line product change) and green after; the companion regression test is green on BOTH sides and asserts on the error, not its wording, so it is not coupled to a message the retirement reworded. Suite: 33 passed, 101 subtests. The `pr-size` CI job keeps its name because it is a required check; its comment and step name now say what it actually enforces. Re-running it over PR #211, the 2261-line change that prompted this, leaves exactly one error: the genuine missing mutation evidence for a checker edit. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude Code:claude-opus-5 [Claude Code]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commits the spike the 2026-08-08 grounding note promised (POL-SPIKE-FIRST), for the developer goal "a full DSpark implementation in vllm.cpp, based on vLLM".
What the spike found
Verified against the pin
555967922: DSpark's entire upstream surface is 1613 lines over 5 files, three of themclass X(DFlashY)subclasses. Everything hard — the non-causal in-block attention primitive, the multi-tap aux combine, context-KV precompute, the separate-draft loader, the--speculative-configplumbing, the verify/propose loop — is already landed and gated underSPEC-DFLASH.The delta over our DFlash lane:
markov_rank=256in every shipped ckpt)sample_from_anchorN-query layout (field already exists, alwaysfalsetoday;NumLookaheadTokens()already returnskfor dspark — verified)d2tremapk >= dspark_block_sizehard errorDraft checkpoints exist for both gate models (
RedHatAI/Qwen3.6-35B-A3B-speculator.dspark1.90 GB,satgeze/Qwen3.6-27B-DSpark8.80 GB) and for the 4B pair the upstream test itself uses, so the row is gateable without the DeepSeek-V4 hardware blocker. DSV4 DSpark stays out of scope.Scope of this PR
Records-only. No
src/,include/,tests/orexamples/change.SPEC-DSPARKmovesINVENTORIED→ACTIVE, with the engine-matrix counters, the feature-matrix row, the coordination claim,NOW.mdand the three public doc surfaces updated in the same change; the STATUS ratchet is re-pinned byte-tight at the reduced size.scripts/agent-preflight.sh --staged: 56 gates ok, exit 0.Implementation slices W1–W6 follow on this branch.