perf(dsv4 hc_pre): widen linear split-K LINEAR_OK 4->8 (align with hc_head) - #804
perf(dsv4 hc_pre): widen linear split-K LINEAR_OK 4->8 (align with hc_head)#804wangqin1723-max wants to merge 1 commit into
Conversation
Align hc_pre_linear's split-K factor with hc_head (both LINEAR_OK = 8). Each cube task's K reduction halves (4096 -> 2048) and the decode task count doubles (4 -> 8); K_CHUNK (256) and L0B pressure are unchanged, and the result is bit-identical (same atomic-add reduction, same K order per slice). Matches hc_head's LINEAR_OK = 8. A/B (DSv4 moe EP2 decode, even primary dies, 6 interleaved rounds): - hc_pre_linear kernel Exec: 9.75 -> 6.51 us (-33%) - comb_sinkhorn Exec: ~14.7 us (unchanged -- the actual pole) - hc_pre decode wall (isolated): 45.4 -> 44.2 us (-2.6% mean; paired diffs scattered, p~0.19 -- not yet statistically significant) linear is not hc_pre's pole today (linear 6.5 < rms 9.8 < sinkhorn 14.7 us), so the kernel speedup does not reliably move the end-to-end wall. Kept for hc_head consistency and to pre-stage the split-K widening for when a later change shifts the pole onto linear.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesLinear split-K configuration
Estimated code review effort: 2 (Simple) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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 |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request increases LINEAR_OK from 4 to 8 in models/deepseek/v4/hc_pre.py to test performance handoffs, matching the configuration in hc_head. The reviewer suggests adding safety assertions to ensure that HC_DIM is divisible by LINEAR_OK and that the resulting split K dimension is divisible by LINEAR_K_CHUNK to prevent potential silent correctness issues.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| # Each task's K halves (4096 -> 2048); K_CHUNK (256) and L0B pressure unchanged. | ||
| # Counter-pressure: 2x atomic-add producers on the same mixes_raw[0:16,0:32] | ||
| # tile at the handoff. Matches hc_head's LINEAR_OK = 8. | ||
| LINEAR_OK = 8 |
There was a problem hiding this comment.
To prevent silent correctness issues or out-of-bounds slicing if LINEAR_OK or HC_DIM are modified in the future, we should add safety assertions to ensure that HC_DIM is divisible by LINEAR_OK and that the resulting split K dimension is divisible by LINEAR_K_CHUNK. This aligns with the safety checks present in hc_head.py.
| LINEAR_OK = 8 | |
| LINEAR_OK = 8 | |
| assert HC_DIM % LINEAR_OK == 0 and (HC_DIM // LINEAR_OK) % LINEAR_K_CHUNK == 0 |
References
- When assuming specific invariants or configuration coverages in a kernel, make this invariant explicit with a module-level assertion to prevent silent correctness issues if configurations change.
1 participant
What
Align
hc_pre_linear's split-K factor withhc_head:LINEAR_OK 4 -> 8. Each cube task's K reduction halves (4096 -> 2048); decode task count doubles (4 -> 8).K_CHUNK(256) and L0B pressure are unchanged, and the result is bit-identical (same atomic-add reduction, same K order per slice). Matcheshc_head'sLINEAR_OK = 8.Why
hc_headalready usesLINEAR_OK = 8for the same linear split-K structure; aligninghc_preremoves a needless divergence.hc_pre_linearkernel itself gets faster (shortermatmul_accchain).A/B (DSv4 moe EP2 decode, even primary dies, 6 interleaved rounds)
hc_pre_linearkernel Execcomb_sinkhornExecThe linear kernel speedup is real (-33%), but it does not reliably move the end-to-end wall:
linear(6.5us) sits belowrms(9.8us) and well below the actual polecomb_sinkhorn(14.7us, the 20-iter serial Sinkhorn recurrence). The -2.6% wall mean is not statistically significant at n=6 (paired diffs are scattered around zero, p ~ 0.19).Kept for
hc_headconsistency and to pre-stage the split-K widening for when a later change shifts the hc_pre pole ontolinear.Validation
python models/deepseek/v4/hc_pre.py -p a2a3 --enable-l2-swimlane-- golden PASS (decode B=4 S=2 + prefill T=128;x_mixed/post/comball within tolerance).