Contributor questions: DFlash2 draft training data, checkpoint contributions, and which open work to review #714

Hi — I'm a contributor with no merge rights, working on Qwen3.8-27B decode speed on an M5 Pro (20-core GPU, 48 GiB). I have several open drafts and research issues, but I'd like to stop adding to the pile and aim at what you would actually review. Five short questions; one-line answers are plenty.

Where my measurements stand (details in #542, #543, #590):

• Decode looks bandwidth-bound: GPU time per cycle is about 72 ms at one lane and about 88 ms at four lanes, so weights are streamed once and shared.
• Kernel and tile micro-experiments gave 0–3% or regressed.
• 84.9% of first rejections are selection misses: the target token was already in the draft's top-16 set (6,144 natural greedy cycles, Investigate deployment-aware DFlash2 selector training before increasing draft capacity #542).
• A small frozen-feature selector fit did not transfer: +1.0% on validation, then −1.17% on 48 held-out cases (Evaluate quantization-aware DFlash2 adaptation against the deployed target #543). Full-draft or quantization-aware training is still untested because I lack the original corpus and recipe.

Questions:

1. Draft training: Is the corpus and recipe behind the released incoai/Qwen3.8-27B-DFlash2 checkpoint available, or at least its data mix and objective? If not, would you accept a retrained draft from a contributor, and if so what evidence (held-out emitted tokens per cycle, greedy output unchanged)?
2. Checkpoint delivery: If a better draft comes out of this, how should it be shipped? A model repo under a contributor account, or something you host?
3. Evidence standard: Wall-clock A/B runs on a laptop are noisy for me (thermal and power events). Would you accept emitted tokens per cycle and GPU ms per cycle from the existing counters as the primary evidence, with wall tok/s as confirmation?
4. Tree verifier: A 16-row tree verifier gave +12% (known prompts) and +7% (independent prompts) in cold-request tests, but ordinary and shader lifecycle runs differ from the unchanged build. Is a greedy "every committed token equals the raw target argmax" certificate plus a distribution check an acceptable correctness bar, or do you require identical text to the current build?
5. Review capacity: I have many drafts open (listed in Qwen3.8-27B on a 48 GiB M5 Pro: reproducible inference measurements and tuning results #580 and Investigate deployment-aware DFlash2 selector training before increasing draft capacity #542). Which one or two would you actually review? I'll close or park the rest and keep one active at a time.

Thank you.