fix(ds4): reuse MHC autotuning output buffers - #782
voipmonitor wants to merge 1 commit into
Conversation
Allocate one output set per preparation candidate so repeated CUDA graph timing samples do not accumulate functional-output copies beyond the primed memory budget. Serving kernels, operation queries, candidate search and caller-owned scratch are unchanged. Validation: 13 native SM120 tests pass, including exact functional parity and changed-input CUDA graph replay at 3 and 4096 tokens. The baseline fails output-pointer reuse. DS4 TP2 completes weights preparation; end-to-end serving remains gated by KV admission capacity. Co-authored-by: Codex <noreply@openai.com> Signed-off-by: Martin Vit <martin@voipmonitor.org>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughB12x mHC preparation now preallocates output tensors and passes them to the relevant implementations. New CUDA tests cover all mHC operations, two token counts, repeated preparation, and CUDA graph replay. ChangesmHC output reuse
Priority: ⬇️ Low Estimated code review effort: 3 (Moderate) | ~25 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The output-reuse change preserves the preparation operation contracts across all covered branches, with no concrete merge-blocking risk identified. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@coderabbitai review |
|
|
Combined serving qualification with #783 and #784 passes on stock RTX PRO 6000 Workstation GPUs, TP2, DSpark K5 and a 4096-token batch budget. MHC preparation completes without OOM; full/piecewise capture, four arithmetic/prefix checks and all six warmed C1/C8 cells pass. Medians: C1 194.82 tok/s, C8 679.58 tok/s, uncached 32K prefill 13,910 tok/s. This is qualification of the source composition, not an isolated kernel speedup claim. DS4 Vision remains under test. |
Behavior and reason
Status: implemented; native correctness and startup preparation qualified.
DeepSeek V4 MHC autotuning owns one output-buffer set per candidate and reuses
it during priming, timing and CUDA graph capture. The existing native kernels
already accept caller-provided outputs. Serving dispatch, arithmetic,
precision, scratch ownership and the candidate search space are unchanged.
Without these buffers, functional output allocation creates additional copies
inside each candidate's graph pool. The tuner budgets primed residency before
those copies exist. On TP2 RTX PRO 6000 Workstation, DSpark K5 and a 4096-token
budget,
post_pre.m4096exhausted VRAM with 18 measured candidates plus acarried candidate: each primed candidate held 336,199,680 bytes, then each graph
capture reserved another 379,584,512 bytes. A 128 MiB output allocation failed
with 74.88 MiB driver-free. Reusing the outputs allows all 160 weight-stage
declarations to prepare without changing the tuner or reducing the search.
Validation
Native SM120, CUDA 13.4.1, PyTorch 2.14, B12X
f832e568c078:python -m pytest -q tests/model_executor/kernels/test_b12x_linear.py \ -k 'mhc_preparation_reuses_outputs or mhc_declares_the_operations'stable and adds no live allocation; comparisons use zero tolerance.
The DS4 TP2 startup check also needs a separate collective-owner lifetime fix
and the TileLang runtime dependency. Weight preparation succeeds, but serving
is not qualified: the 1M-token KV admission check has only 6.14 GiB available
against 6.95 GiB required. No end-to-end speedup or memory-capacity claim is made.
No existing open PR was found for this preparation-output ownership correction.
The change is separate from serving-scratch reuse and graph-aware MoE tuning.
AI-assisted implementation and validation; submitted for maintainer review.
Summary by CodeRabbit
Performance
Reliability