Skip to content

Overview of my open PRs: what each fixes, dependencies, and an offer to bundle #674

Open

Description

@Peuqui

Update 2026-10-19, afternoon: #1237 fixes the rest of #739. With one visible device, the PLE offload process built its VllmConfig before reducing it to DP1 and asked for the device of its inherited local DP rank. The second test in #739 failed only after the first one, because that test restored local DP rank 1 as an envs attribute. 19 PRs are open, and all of them merge cleanly into current main (6f3557c).

Update 2026-10-19: thank you for #856 and #857 (merged on 2026-10-03), #873 and #874 (2026-10-04), and #1004 and #1005 (2026-10-09). #611 is closed in favor of #822, which keeps its history. I closed #1006 in favor of #1187: main had added the typed field itself, so only the default change was left. 18 PRs are open, listed below, and all of them merge cleanly into current main (6f3557c). Among themselves, #1217 builds on #1214, and #1216, #1217 and #1235 overlap only in the generated docs/design/architecture/runtime_reference.md (the line anchors of KernelConfig, which tools/generate_architecture_reference.py --write regenerates). A correction to #1226, #1228 and #1229: the boot-to-boot differences of the Flash-Next greedy texts mentioned there came from the bug that #1234 fixes. With #1234 on top (our fork commit 6bbcd40, which also contains those three changes), three boots per topology give byte-identical greedy texts.

Update 2026-10-03, afternoon: #742 is merged through #837, thank you. Native results for it are posted in #837: the 13 SM75 cases on a Quadro RTX 8000, complete-model runs, and a paired skinny on/off comparison. Two new fixes came out of those runs. #856: the PLE cascade never admitted ModelOpt checkpoints such as nvidia/Qwen3.8-Flash-Next-NVFP4, because the admission looked up the wrong layer under the wrong name, so a PP4 start tried to put the whole 47.69 GiB table on stage 0. #857: DeepSeek-V4 could not start on our V100/RTX 8000 rig, because the sparse policy was read through get_current_vllm_config() inside the forward pass, where the worker does not set it. Four PRs are open, and all of them merge cleanly into current main (8002bc1).

Update 2026-10-03, morning: thank you for the overnight round. #791 and #793 went in through #795, #623 through #797, #747 through #798, #604 through #804, #750 through #801, #740 through #808, #646 and #717 through #806, and #714 and #716 through #816. GPU results for #795, #797 and #798 are posted there. Three PRs are still open, and all of them merge cleanly into current main (3efe512).

Update 2026-10-02, evening: thank you for the integration round. #743, #710, #749 and #726 went in through #773, #720 through #776, #744 and #745 through #777, #667 through #765, and #711 is merged. #646 and #717 are rebased onto main after the hybrid PLE change of #786, and #747 and #750 onto main after #777 and #782; #750 now registers its switch in the env metadata of #782. #750 also got a test fix I had missed: its PP2xTP4 tests built Fp8LinearMethod without use_qpn8. Two new fixes: #791 for the DFlash/DSpark start that #748 broke, and #793, which settles the hybrid block size before the PLE KV estimate; with the cascade of #646, Qwen3.8-Flash-Next needs it to start. 14 PRs are still open, and all of them merge cleanly into current main (a3498d4).

Update 2026-10-02: #621 and #723 are merged, and #725, #741 and #752 went in through #757, #758 and #762, thank you. 21 PRs are still open, and all of them merge cleanly into current main (e0f3fed).

Update 2026-10-01, evening: one more, #752. It asserts that each request with drafts has at least draft_len + 1 query rows, so a scheduler/runner mismatch fails where it starts instead of verifying drafts against the preceding request's hidden states. One comparison per request. It has been in our fork since 2026-09-06 and has not fired in the logs we keep (back to 2026-09-21).

Update 2026-10-01, afternoon: two more. #750 lets every [128, 128] block-FP8 linear on Volta and Turing use the native QPN8 operators behind an opt-in switch (DeepSeek-V4 at PP5: prefill 16.7 -> 15.2 s, decode step 100 -> 85 ms, and no TurboMind tuning stall at new prompt lengths); stacked on #747. #749 checks the token ids the last pipeline stage hands to the others, so an out-of-vocabulary id is named instead of ending in an anonymous device-side assert. #744 now covers six test modules. Main plus our open PRs, with the #716 and #750 switches set, now produces output identical to our fork on DeepSeek-V4 (greedy and eight reference answers).

Update 2026-10-01, morning: three more PRs, all about DeepSeek-V4 before Ampere. #747 lets Turing take main's SM70 route (one capability-family predicate, so V100 and RTX stages of one pipeline declare the same backend) and gives wo_a a grouped fp16 path where Marlin serves block FP8. #745 decodes FP8 in software on every card without FP8 units, and #744 brings five DeepSeek-V4 test modules in line on pre-Ampere cards. #716 got a fix: its batched-matmul prefill read stale index slots past each token's length and hit a device assert on the first long prompt. Our fork now runs #747 + #716 instead of its own pre-Hopper path; on the same build that was 4 to 6 % faster (tables in #747). All 25 open PRs merge cleanly into current main (d304698).

Update 2026-09-30, evening: #742 is the MoE part of the v100-skinny proposal in #718, and #743 fixes a memory peak in the SM70 MXFP4 repack that kept DeepSeek-V4 off our V100 stages on the default path. Earlier that day: #740, #741 and the bug report #739. #727 is closed, since #733 covers the same ground more broadly. 22 of the PRs below are merged, thank you for going through them.

Still open

Bug report #739: the first test was fixed on main by 9170150, the second is fixed by #1237.

#718 proposed bringing the v100-skinny kernels into csrc; its MoE part, #742, is merged through #837. Block FP8 needs no port: main's native QPN8 kernels already match or beat it on DeepSeek-V4's shapes. A correction to what this overview said before: main does run DeepSeek-V4's MXFP4 MoE on Turing, through Marlin.

Merged

Background, from the original overview: all of these come from running 1Cat-vLLM on a mixed rig (3x V100 + 2x Quadro RTX 8000): DeepSeek-V4-Flash + DSpark with pipeline parallel over all five cards, Qwen3.8-Flash-Next with pipeline parallel over four cards, and Qwen3.8-27B with TP2 on the two RTX cards.

AI assistance was used to prepare this overview. The merge state of each open PR was checked against current main with git merge-tree, and the two tests of #739 were run again on current main.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YaG8VjXn5eN3Aq7eZrA3dp

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions