-
Notifications
You must be signed in to change notification settings - Fork 230
[AgentX] Update vLLM DeepSeek-V4 B300 aggregate / 更新 vLLM DeepSeek-V4 B300 聚合配置 #2233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
+177
−100
Closed
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
fee87d8
feat(agentic): split DeepSeek-V4 B300 vLLM recipe
cquil11 2d1725b
docs(changelog): link B300 replacement PR
cquil11 407404b
chore: update conc
ivanium 29b6fa5
update dep8 args
majunze2001 5d3da84
add more tp configs
majunze2001 06101fe
dep8 reduce gpu mem util to 0.92
majunze2001 0a1612d
chore: update conc list
ivanium a918e55
Merge branch 'main' into agent/split-pr-2202-b300
majunze2001 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 The header comment (lines 15-16) says TP4 is always GPU-resident (
KV_OFFLOADING=none), but this same PR adds a newTP4 SimpleCPUdram-offload arm innvidia-master.yamlplus a dedicatedSIMPLE_LAZY_OFFLOADcode path for exactly that case. The comment should mention that plain TP4 can also run as a dram/SimpleCPU-offload arm; this is doc-only and has no runtime effect since the actual offload mode is driven by the per-armkv-offloadingconfig field, not the header prose.Extended reasoning...
What the bug is
The updated header comment in
dsv4_fp4_b300_vllm.sh(lines 15-16) reads:This asserts that plain TP4 (non-DP-attention) is only ever run GPU-resident. That statement is no longer accurate as of this same PR.
The contradicting code path this PR adds
This PR simultaneously adds a new
# TP4 SimpleCPUsearch-space entry toconfigs/nvidia-master.yaml:- { tp: 4, kv-offloading: dram, kv-offload-backend: { name: vllm-simple, version: "904e4ec" }, conc-list: [28, 32, 36, 40] }That is plain TP4 (
dp-attnunset/false) withkv-offloading: dram. Even more tellingly, the same PR adds a dedicated shell code path for exactly this arm:SIMPLE_LAZY_OFFLOADis set totrueprecisely whenDP_ATTENTION != true— i.e. for the plain-TP4-dram case introduced by the new yaml arm. The perf-changelog entry even documents it explicitly:"TP4 SimpleCPU lazy-offload at conc [28,32,36,40]".So the script now internally contradicts itself: the header claims TP4 is GPU-resident-only, while the body implements (and the changelog documents) a plain-TP dram-offload ladder. The stale mid-file comment near the
OFFLOAD_ARGScase statement ("TP4 remains GPU-resident") has the same issue.Why existing code does not prevent this
Nothing enforces the comment against the actual config —
KV_OFFLOADING/KV_OFFLOAD_BACKENDare supplied per-arm at invocation time fromnvidia-master.yaml, and the header is just prose. There is no lint or test tying documentation to the search-space definitions, so the two can silently drift, which is exactly what happened here.Step-by-step proof
configs/nvidia-master.yaml, iterates thedsv4-fp4-b300-vllm-agenticsearch space.# TP4 SimpleCPUentry:tp: 4,kv-offloading: dram,kv-offload-backend: vllm-simple, nodp-attn.dsv4_fp4_b300_vllm.shwithTP=4,KV_OFFLOADING=dram,KV_OFFLOAD_BACKEND=vllm-simple,DP_ATTENTIONunset/false.DP_ATTENTION != "true", soSIMPLE_LAZY_OFFLOAD=trueand the vllm-simple offload branch of thecasestatement runs, configuringSimpleCPUOffloadConnectorwithlazy_offload: true— a genuine CPU-offload run, not GPU-resident.Suggested fix
Update the header (and the mid-file comment) to something like: "TP8 and DEP8 are GPU-resident (KV_OFFLOADING=none). TP4 and DEP4 each have both a GPU-resident and a dram/SimpleCPU-offload arm; DEP4 additionally supports mooncake." This keeps the documentation in sync with the search-space entries and the new
SIMPLE_LAZY_OFFLOADcode path added by this PR.Impact
Purely cosmetic — the comment does not drive any runtime behavior, since offload mode is controlled by the
KV_OFFLOADING/KV_OFFLOAD_BACKENDenv vars set per-arm by the yaml config, not by the prose. No functional bug, just a doc inaccuracy worth a follow-up fix. Marking as nit, consistent with all verifier assessments.