DSpark acceptance rate seem seems quite a bit lower vs 0731

#11
by alexbi29 - opened

66–71% versus 83–85% for 0731. Is this expected, seems like DSpark model was undertrained and/or is old?

Per-workload datapoints from 2x DGX Spark (vLLM + DSpark, FP8 weights @ rev 86f746b) — the mixed-traffic 66–71% numbers hide a very wide per-content spread:

workload accept @k=5 tok/step accept @k=3 tok/step
count-to-300 0.974 5.88 0.997 4.00
code 0.464 3.31 0.642 2.93
prose 0.180 1.90 0.286 1.86

(prose accept nearly doubles at k=3, but tok/step barely moves, so throughput gains only ~9%.)

Two practical notes: (1) if you see 0.54 overall at k=5 on the DSpark recipe lineage, check the draft shared-expert loader fix ("Patch 4") first — its absence collapses the acceptance tail and mimics an undertrained drafter; (2) even with everything in place, code/prose acceptance stays well below the 0731 text model's, so ~12–17% lower tok/s on those workloads looks model-inherent. steps/s is flat across workloads at a given k (14.6–15.6 @k=5, ~16–17.3 @k=3) — the drafter, not step cost, is the lever.

I compared appearance rates on the same prompt 0731 vs new.

in sglang it got faster with only 1 nextn like 0731 instead of 3:
--json-model-override-args {"num_nextn_predict_layers":1}

I was comparing
DeepSeek-V4-Flash-Vision-Exp-UD-Q8_K_XL.gguf + dspark-DeepSeek-V4-Flash-0731-BF16.gguf and
DeepSeek-V4-Flash-Vision-Exp-UD-Q8_K_XL.gguf + dspark-DeepSeek-V4-Flash-Vision-Exp-BF16.gguf

And dspark-DeepSeek-V4-Flash-0731-BF16.gguf delivers a higher draft acceptance rate than the native model across all tested query types, including "Describe what is shown in this photo" (sik).

Sign up or log in to comment