DSpark corrupts output on the aprojq4-dense-attention branch (GB10/CUDA): intra-word syllable doubling, confined to the full-accept path

[adamlawi]

Reporting a DSpark output-corruption issue observed on GiorgioOppo's aprojq4-dense-attention branch (f0541235, the branch behind #952). This is a branch issue, not a property of the AProjQ4 requant — the requant measurements are in #952 and are clean.

Setup: NVIDIA GB10 (sm_121), DGX Spark, 121 GiB unified memory, CUDA backend, single GPU, no TP, no SSD streaming. CLI ./ds4, --temp 0 --nothink, -n 300, -c 131072, official DeepSeek-V4-Flash-DSpark-support-0731.gguf.

Symptom

With DSpark enabled, syllables get duplicated inside words: deklarklaracji, żadenaden, Brakujeuje, uznznąymi. The surrounding text stays coherent — this is not a loop and not degeneration. Most visible in morphologically rich languages (examples above are Polish), but it also occurs in English.

Scope

Zero such corruptions in every upstream build I tested, including c0a6119. Present on this branch with both the AProjQ4 model and the base IQ2_XXS model.

The part that may localize it

Two campaigns, eight runs, using the full=/partial= counters from DS4_DSPARK_STATS=1. Model AProjQ4, Polish prose. "Doublings" counted by regex \b\w*?(\w{3,})\1\w*\b on the generated text, digit-only matches excluded.

prompt	setting	drafter	full/partial	syllable doublings
8k	default threshold (0.7)	official	29 / 3	2
8k	--dspark-confidence 0.0	official	2 / 34	0
100k	default threshold	official	37 / 10	8
100k	--dspark-confidence 0.0	official	1 / 49	0
8k	default threshold	Q4_K experts	27 / 6	3
8k	--dspark-confidence 0.0	Q4_K experts	6 / 70	0
100k	default threshold	Q4_K experts	59 / 10	6
100k	--dspark-confidence 0.0	Q4_K experts	1 / 33	0

In all four runs where full accepts numbered 1–6, doublings are exactly zero; in all four where they numbered 27–59, doublings are present. That suggests the corruption arises in the full-block commit path, rather than in proposal, in verification as such, or in replay — replay handles the partial accepts, and those runs are clean.

What this does not show, stated explicitly: there is no dose–response. 59 full accepts produced 6 doublings while 37 produced 8. That fits a state-dependent fault better than a systematic arithmetic one. I predicted proportionality before running the second campaign and that prediction failed, so please treat the mechanism as open — the reliable part is the separation, not a diagnosis.

Reproduction

DS4_DSPARK_STATS=1 ./ds4 --temp 0 --nothink -n 300 -c 131072 \
  -m <AProjQ4.gguf> --dspark --mtp-model DeepSeek-V4-Flash-DSpark-support-0731.gguf \
  --prompt-file <~90k tokens of ds4 source + an instruction>

Then grep the output for repeated 3+ character sequences inside words, and compare against the same run without --dspark.

Ruled out by measurement

• the AProjQ4 requant itself (corruption also occurs with the base model on this branch)
• WaveCut's DSpark module vs the official one (identical behaviour)
• the last eight commits on this branch
• the absence of each of three upstream fixes, tested individually
• Polish tokenization (corruption also occurs in English)

Workaround for anyone on this branch

--dspark-confidence 0.0 produces clean output (zero doublings, 100% unique shingles), but the speedup drops to about +2% at a 100k prompt.