[Perf] Reuse DSpark probability distance across loss and metrics - #87
Open
Levius-Fubuki wants to merge 3 commits into
Open
[Perf] Reuse DSpark probability distance across loss and metrics#87Levius-Fubuki wants to merge 3 commits into
Levius-Fubuki wants to merge 3 commits into
Conversation
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
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.
[Perf] Reuse DSpark probability distance across loss and metrics
Purpose
DSpark currently computes the same draft/target probability distance once for
acceptance-rate metrics and again when the L1 distillation loss is enabled:
This PR computes the per-token L1 probability distance once and reuses it for:
accept_rate = clamp(1 - 0.5 * l1_distance, 0, 1);It removes one pair of vocabulary-sized FP32 softmax results and one duplicate
probability-difference reduction. The public loss API, loss definitions,
confidence targets, metric definitions, and distributed normalization remain
unchanged. The implementation stays on the portable PyTorch path with no
custom kernel, architecture gate, or device-specific tuning.
Test Plan
Regression and equivalence tests
The tests verify:
torch.softmaxtwice instead of four times;Repository test suite
RTX 4090 loss-path microbenchmark
The standalone harness measures
_collect_local_termsplus backward with L1loss enabled. Baseline and candidate run from separate worktrees at the same
upstream base commit. Each row uses 20 warmups and 100 measured iterations.
Hardware/software: NVIDIA RTX 4090 (SM89), CUDA 13.0, PyTorch 2.12.1+cu130,
Python 3.12.3. No GPU configuration changes.
For the 512-row case, the complete local loss collection and backward path is
approximately 32.5% faster and uses approximately 22.2% less peak allocated
memory.
An isolated probability-distance sweep covered vocabulary sizes 32,768,
65,536, and 151,936 with 128, 512, and 2,048 token rows. The larger shapes
showed 1.51x-1.57x median speedups, and all tested shapes completed without OOM.
Test Result
The focused suite, repository-wide pytest invocation, Python syntax compilation,
and
git diff --checkpassed locally.Limitations
These are isolated DSpark loss-path measurements from one RTX 4090, not
end-to-end training throughput. No performance claim is made for other GPU
architectures, CPU execution, distributed training, or configurations with L1
loss disabled. The smallest isolated shapes were sensitive to GPU measurement
order; the reported whole-loss results use DSpark's large-vocabulary regime.
The benchmark harness is intentionally not part of this patch. It compares the
exact original and candidate expressions and separate upstream/candidate
worktrees; the production patch contains only the loss refactor and focused
regression tests.
AI assistance
AI assistance was used during implementation, testing, benchmarking, and PR
drafting. The human contributor reviewed and takes responsibility for the
change and evidence.