Repository navigation
Extend probabilistic sampling for DFlash2 drafts - #30663
gaugarg-nv merged 2 commits into
Conversation
|
Adding the performance section as a separate comment for better visibility Performance
RTX 5090Qwen3.8-27B
Muse-Glimmer-30B
DGX SparkQwen3.8-27B
Muse-Glimmer-30B
RTX Pro 6000Qwen3.8-27B
Muse-Glimmer-30B
|
|
@gaugarg-nv, @ruixiang63 can you please take a look at this PR? |
|
The change looks good to me. |
|
I'll revisit #30213 tomorrow, other things came in the way last week. |
|
Do we have DFlash2 model for Muse-Glimmer-30B? @praneshgo |
Yes, there is a DFlash2 model for Muse-Glimmer-30B. I found the drafter model at https://huggingface.co/z-lab/Muse-Glimmer-30B-DFlash2-GGUF and the corresponding target model is at https://huggingface.co/meta-models/Muse-Glimmer-30B-GGUF |
| for (int32_t k = 0; k < top_k; ++k) { | ||
| sum += std::exp(scores[k] - scores[predecessor]); | ||
| probs[k] = std::exp((scores[k] - scores[predecessor]) / temp); | ||
| sum += probs[k]; | ||
| } | ||
| if (1.0f / sum < params.p_min) { | ||
| break; | ||
| } | ||
| for (int32_t k = 0; k < top_k; ++k) { | ||
| probs[k] /= sum; | ||
| } |
There was a problem hiding this comment.
I am thinking about params.p_min here: it still truncates on the draft’s max probability, which was a good proxy for greedy acceptance. Under rejection sampling the expected acceptance is Σ_x min(p(x), q(x)) = 1 − TV(p, q), which doesn’t depend on how peaked q is (draft token probability), so positions cut off by p_min could well have been accepted by the target. Ideally the cutoff would be an estimate of 1 − TV(p, q), but we don’t have p (target verified token probability) at draft time. Should we disable p_min when use rejection sampling?
There was a problem hiding this comment.
Good point, I agree. Under rejection sampling the acceptance at a position is 1 − TV(p, q), and the draft's top probability doesn't say much about that, so p_min can cut tokens the target would have accepted.
For this PR:
- p_min is 0 by default, so it only kicks in when it is set. All the numbers in the PR were measured with it not set.
- draft-simple and draft-mtp already apply p_min the same way in probabilistic mode (top probability of the draft distribution at the target's temperature), so DFlash2 follows the existing behavior.
Instead of changing it for DFlash2 alone here, I think p_min under rejection sampling should be handled for all three drafters together. draft-simple and draft-mtp run one draft forward pass per token, so stopping early also saves draft compute. Dropping the cutoff trades that saving for more tokens the target may accept. Finding out which side wins needs measuring, which I can take up in a follow-up PR.
There was a problem hiding this comment.
Please add a follow-up for this.
There was a problem hiding this comment.
PR #31294 addresses the above discussion.
|
It is approved. Can it be merged now? |
|
@gaugarg-nv can you please help merge this PR if it looks okay? Thank you. |
* spec : add probabilistic sampling for DFlash2 drafts * spec : apply review suggestions --------- Co-authored-by: Pranesh Gonegandla <pgonegandla@nvidia.com>
Overview
This PR is an extension of #27694. This PR adds probabilistic drafter for DFlash2 technique and reuses the same verify-accept-reject logic added in #27694 which is currently on upstream.
Adding some performance data taken over multiple HW running models from different families below:
Performance
RTX 5090
Qwen3.8-27B
Muse-Glimmer-30B
DGX Spark
Qwen3.8-27B
Muse-Glimmer-30B
RTX Pro 6000
Qwen3.8-27B
Muse-Glimmer-30B
Requirements