Skip to content

Qualify B200 DeepSeek-V4.1-Flash on vLLM nightly 0961bbae / 在 B200 上验证 DeepSeek-V4.1-Flash 的 vLLM nightly 0961bbae - #3393

Closed
xinli-sw wants to merge 1 commit into
mainfrom
config/dsv41flash-b200-vllm-nightly
Closed

xinli-sw wants to merge 1 commit into
mainfrom
config/dsv41flash-b200-vllm-nightly

Conversation

@xinli-sw

@xinli-sw xinli-sw commented Sep 23, 2026 •

Copy link
Copy Markdown
Collaborator

Pin the B200 DeepSeek-V4.1-Flash AgentX configuration to the upstream vLLM image vllm/vllm-openai:nightly-0961bbae2894d574be790d219651824eb199318e.

This enables the published Blackwell sparse-indexer configuration on B200 only: TP2 uses FLASHINFER_MLA_SPARSE_DSV41, TP4 uses FLASHMLA_MEGA_ATTN_DSV41, indexer KV uses MXFP4, and the target/draft KV cache uses FP8. The launcher supplies the B200-specific opt-in and a 7200-second engine-readiness timeout, so the shared H200, GB200, and GB300 script paths remain unchanged.

The vLLM tracking issue and published upstream recipe document these settings.

Validation

  • Exact-head full sweep run 35902738208, attempt 1 passed on commit 27126ca4fa42f301782ce5a4be4c20802f1da50b.
  • All 16 AgentX performance jobs passed: TP2 and TP4 at concurrency 1, 2, 4, 8, 16, 32, 64, and 128.
  • The matching GSM8K eval passed with strict exact match 0.9780136467 and n_eff=1319.
  • Repository validation, changelog validation, and CodeQL passed.

AI model disclosure

  • Claude (the GitHub integration did not expose the exact model/version) reviewed the implementation and identified the shared-script scope issue addressed in the current head.
  • OpenAI GPT-6 (the Codex runtime did not expose a more specific deployment version) independently audited the current head and updated this PR's title and description. It did not modify the branch or code.
中文

将 B200 DeepSeek-V4.1-Flash AgentX 配置固定到上游 vLLM 镜像 vllm/vllm-openai:nightly-0961bbae2894d574be790d219651824eb199318e。

此变更仅在 B200 上启用已发布的 Blackwell 稀疏索引器配置:TP2 使用 FLASHINFER_MLA_SPARSE_DSV41,TP4 使用 FLASHMLA_MEGA_ATTN_DSV41,索引器 KV 使用 MXFP4,目标模型与草稿模型的 KV 缓存使用 FP8。启动脚本传入仅适用于 B200 的显式开关和 7200 秒引擎就绪超时,因此共享脚本中的 H200、GB200 和 GB300 路径保持不变。

相关参数见 vLLM 跟踪问题和已发布的上游配方。

验证

  • 当前提交的完整扫描运行 35902738208,第 1 次尝试在提交 27126ca4fa42f301782ce5a4be4c20802f1da50b 上通过。
  • 16 个 AgentX 性能任务全部通过:TP2 和 TP4,并发数分别为 1、2、4、8、16、32、64 和 128。
  • 对应的 GSM8K 评测通过,严格精确匹配分数为 0.9780136467,n_eff=1319。
  • 仓库验证、性能变更日志验证和 CodeQL 均通过。

AI 模型披露

  • Claude(GitHub 集成未公开确切的模型和版本)审阅了实现,并发现了当前提交已修复的共享脚本作用域问题。
  • OpenAI GPT-6(Codex 运行时未公开更具体的部署版本)独立审计了当前提交,并更新了本 PR 的标题和描述;它没有修改分支或代码。

@github-actions

Copy link
Copy Markdown
Contributor

Thanks for the contribution!

  • Review: If this PR changes files owned by someone other than a repository admin or @SemiAnalysisAI/core, ask one eligible CODEOWNER to complete the latest PR_REVIEW_CHECKLIST.md before contacting a core maintainer on Slack. Follow the template exactly, including As a PR reviewer and CODEOWNER, I have reviewed this and have, so sign-off verification triggers.
  • PR verification: Sweeps only run on labeled PRs. Add full-sweep-fail-fast (strongly recommended); use full-sweep-enabled only when matrix jobs should continue after a failure.
  • After merging: PR authors must ensure all GitHub Actions jobs pass. Transient failures often pass on rerun; see how to rerun failed jobs.
中文

感谢你的贡献!

  • **审阅:**如果 PR 修改的文件归属于仓库管理员及 @SemiAnalysisAI/core 之外的 CODEOWNER,请先联系一位有资格的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md,再通过 Slack 联系核心维护者。必须严格遵循模板,并保留 As a PR reviewer and CODEOWNER, I have reviewed this and have,才能触发签核验证。
  • **PR 验证:**扫描仅在带有标签的 PR 上运行。强烈建议添加 full-sweep-fail-fast;仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled。
  • **合并后:**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

@xinli-sw
xinli-sw marked this pull request as ready for review September 23, 2026 17:53
@xinli-sw
xinli-sw requested a review from a team September 23, 2026 17:53
@claude

claude Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

Claude finished @xinli-sw's task in 3m 15s —— View job


Review of PR #3393

  • Gather context (diff against origin/main, read changed files)
  • Validate master config + perf-changelog (image accessibility, entry position)
  • Review benchmark script (EP pattern, --use-chat-template, flag correctness)
  • Review launcher change
  • Post review

Summary: One 🔴 blocking issue, posted inline on benchmarks/single_node/agentic/dsv41flash_fp4_vllm_mtp.sh. The new ATTENTION_ARGS block is gated only on GPU_MEM_MIB >= 150000, but this script is symlinked as the GB200, GB300 and H200 vLLM scripts, so the GB200 (nightly-cd10ed6f) and GB300 (nightly-af1c0149) TP2/TP4 arms also pick up the new --attention-config/--kv-cache-dtype fp8 flags on images that predate the nightly this PR pins. Those configs are not in the changelog entry and may fail argument parsing. Gating on a variable exported from the B200 launcher (like the existing VLLM_SAFETENSORS_LOAD_STRATEGY pattern) keeps the change scoped to the B200 arm.

Everything else checks out: the image is a public Docker Hub tag, perf-changelog.yaml is updated and the entry is appended at the end, the VLLM_ENGINE_READY_TIMEOUT_S=7200 export satisfies the script's check_env_vars on B200, and the arm remains AgentX replay (no benchmark_client, so the --use-chat-template rule does not apply). I could not verify the backend enum names or indexer_sparse_logits against vLLM source at 0961bbae because outbound network is blocked in this sandbox and the inferencemax-repos MCP server timed out; the GPU sweep will be the real check there.
· Branch

Comment on lines +83 to +91
ATTENTION_ARGS=()
if (( GPU_MEM_MIB >= 150000 )); then
if (( TP == 2 )); then
ATTENTION_CONFIG='{"backend":"FLASHINFER_MLA_SPARSE_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
else
ATTENTION_CONFIG='{"backend":"FLASHMLA_MEGA_ATTN_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
fi
ATTENTION_ARGS=(--attention-config "$ATTENTION_CONFIG" --kv-cache-dtype fp8)
fi

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 BLOCKING: This gate also fires on GB200 and GB300, which are not part of this PR.

Why it matters: dsv41flash_fp4_gb200_vllm_mtp.sh, dsv41flash_fp4_gb300_vllm_mtp.sh and dsv41flash_fp4_h200_vllm_mtp.sh are symlinks to this file. The GB200 arm (256 GiB per GPU, nightly-cd10ed6f, 2026-09-15) and the GB300 arm (277 GiB per GPU, nightly-af1c0149, 2026-09-16) both clear GPU_MEM_MIB >= 150000, and both run TP2 and TP4, so every one of their points now gets --attention-config {...DSV41...,"indexer_sparse_logits":true} --kv-cache-dtype fp8. The PR description says these settings need the 2026-09-22 nightly; on the older images an unknown backend name or indexer_sparse_logits key would fail at argument parsing, and even if they happen to parse, the GB200/GB300 recipes change without a perf-changelog.yaml entry (only dsv41flash-fp4-b200-vllm-agentic-dspark is listed). I could not confirm the flag availability at cd10ed6f/af1c0149 from this sandbox (no network, source MCP server timed out), so please treat the crash as unverified but the scope leak as certain.

Fix: Gate on a launcher-exported variable, the same way this script already handles VLLM_SAFETENSORS_LOAD_STRATEGY, and export it only from runners/launch_b200-nscale-slurm.sh next to the new VLLM_ENGINE_READY_TIMEOUT_S line:

Suggested change
ATTENTION_ARGS=()
if (( GPU_MEM_MIB >= 150000 )); then
if (( TP == 2 )); then
ATTENTION_CONFIG='{"backend":"FLASHINFER_MLA_SPARSE_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
else
ATTENTION_CONFIG='{"backend":"FLASHMLA_MEGA_ATTN_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
fi
ATTENTION_ARGS=(--attention-config "$ATTENTION_CONFIG" --kv-cache-dtype fp8)
fi
ATTENTION_ARGS=()
if [[ "${DSV41_BLACKWELL_SPARSE_INDEXER:-0}" == "1" ]]; then
if (( TP == 2 )); then
ATTENTION_CONFIG='{"backend":"FLASHINFER_MLA_SPARSE_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
else
ATTENTION_CONFIG='{"backend":"FLASHMLA_MEGA_ATTN_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
fi
ATTENTION_ARGS=(--attention-config "$ATTENTION_CONFIG" --kv-cache-dtype fp8)
fi

and in runners/launch_b200-nscale-slurm.sh inside the MODEL_PREFIX == "dsv41flash" block:

export DSV41_BLACKWELL_SPARSE_INDEXER=1

(Update the comment on lines 80-82 accordingly; it currently only mentions excluding H200.) If the intent really is to roll these settings out to GB200/GB300 as well, those images need bumping to a nightly that carries them and the changelog needs entries for both config keys.

Fix this →

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beyond the inline finding, I also checked the new ATTENTION_ARGS block and the VLLM_ENGINE_READY_TIMEOUT_S export against the repo's bash conventions (no ${VAR:-default} fallbacks, required vars validated via check_env_vars) — both comply: GPU_MEM_MIB/TP feed off already-validated/derived values and the timeout is an explicit assignment. I also looked for a model.container field to cross-check against the bumped image, but single-node recipes in this config don't carry one, so that convention doesn't apply here.

Extended reasoning...

The diff bumps a pinned vLLM nightly image and adds a GPU-memory-gated sparse-indexer attention block shared by benchmarks/single_node/agentic/dsv41flash_fp4_vllm_mtp.sh, plus a longer engine-ready timeout in runners/launch_b200-nscale-slurm.sh and the matching perf-changelog entry; no auth/crypto surface is touched. The confirmed inline finding (GB200/GB300 vllm configs, pinned to different older images per configs/nvidia-master.yaml, silently inherit the new untested attention backend via the shared script and its >=150000 MiB gate) is significant enough that a human should weigh in before merge. I additionally checked the new code against the repo's bash conventions (no default-fallback env vars, explicit timeout assignment) and found no violations, which I'm noting here rather than repeating the inline comment.

Comment on lines +83 to +91
ATTENTION_ARGS=()
if (( GPU_MEM_MIB >= 150000 )); then
if (( TP == 2 )); then
ATTENTION_CONFIG='{"backend":"FLASHINFER_MLA_SPARSE_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
else
ATTENTION_CONFIG='{"backend":"FLASHMLA_MEGA_ATTN_DSV41","indexer_kv_dtype":"mxfp4","indexer_sparse_logits":true}'
fi
ATTENTION_ARGS=(--attention-config "$ATTENTION_CONFIG" --kv-cache-dtype fp8)
fi

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 GB200/GB300 agentic runs pick up the new sparse-indexer attention flags via this shared script, even though those images weren't bumped for it. The GPU_MEM_MIB>=150000 gate at line 84 also fires for gb200-nv (256GB) and gb300-nv (277GB), since dsv41flash_fp4_gb200_vllm_mtp.sh and dsv41flash_fp4_gb300_vllm_mtp.sh are symlinks to this file. But configs/nvidia-master.yaml leaves their images unchanged: gb200 stays on nightly-cd10ed6f9f6b37a8ace9cf380007e66fe12ec0c3 (the exact build b200 is moving off in this PR) and gb300 on nightly-af1c01499b289be555c475669ba50a88e96d846e. If either predates the new FLASHINFER_MLA_SPARSE_DSV41/FLASHMLA_MEGA_ATTN_DSV41 backends, vllm serve rejects --attention-config on the next gb200/gb300 sweep. …

Why this was flagged

…Fix: gate ATTENTION_ARGS on the vLLM image/version that actually ships the backend, not on GPU memory alone, or bump gb200/gb300 images together with b200.

dsv41flash_fp4_gb200_vllm_mtp.sh and dsv41flash_fp4_gb300_vllm_mtp.sh are symlinks to dsv41flash_fp4_vllm_mtp.sh (verified via ls -la), so the new ATTENTION_ARGS block (lines 83-91) runs for them too. Its only gate is GPU_MEM_MIB>=150000 at line 84, true for GB200 (256GB) and GB300 (277GB) per the script's own comments at lines 50-51. configs/nvidia-master.yaml:8093 pins gb200-vllm-agentic-dspark to nightly-cd10ed6f9f6b37a8ace9cf380007e66fe12ec0c3, unbumped by this PR and identical to b200's pre-bump image; gb300 (line 8196) stays on nightly-af1c01499b289be555c475669ba50a88e96d846e, also untouched. On base, this script never passed --attention-config, so gb200/gb300 ran unaffected; now, if either nightly lacks the new backend keys, vllm serve fails to start for those SKUs on the next sweep.

Verification: Severity: normal. The gb200/gb300 agentic vLLM arms regress because the shared script now injects new attention flags onto their un-bumped images. Structural chain (all verified): - dsv41flash_fp4_gb200_vllm_mtp.sh and dsv41flash_fp4_gb300_vllm_mtp.sh are symlinks to dsv41flash_fp4_vllm_mtp.sh (ls -la: both "-> dsv41flash_fp4_vllm_mtp.sh"). So the new block added by the diff at lines 83-91…

@github-actions

github-actions Bot commented Sep 23, 2026 •

Copy link
Copy Markdown
Contributor

@Ankur-singh Ankur-singh changed the title Update B200 DeepSeek V4.1 Flash vLLM nightly / 更新 B200 DeepSeek V4.1 Flash vLLM nightly Qualify B200 DeepSeek-V4.1-Flash on vLLM nightly 0961bbae / 在 B200 上验证 DeepSeek-V4.1-Flash 的 vLLM nightly 0961bbae Sep 23, 2026
@Ankur-singh

Copy link
Copy Markdown
Collaborator

As a PR reviewer and CODEOWNER, I have reviewed this and have:

  • Verified that as of the moment of typing this, this is the latest version of PR_REVIEW_CHECKLIST.md
  • Verified that the general code quality meets the InferenceX standard and does not make the code quality any worse.
  • Verified that this PR has passed PR validation. Please link to GitHub Action workflow that shows this.
  • Verified that this PR passes evals. Please link to GitHub Action workflow that shows this.
  • Verified that speculative decoding PRs uses chat templates to align the AL distribution to real world
  • Verified that every draft model and draft head is served as it ships: the draft that ships with the served checkpoint, at its stored precision, through the pinned upstream image's default handling, with the shipped and effective draft precision recorded in the additional detail section. No submission-side quantization, dtype override, checkpoint substitution, or patch may lower draft precision below that default, regardless of eval results or AL. See Draft-model precision for what counts as the default and the MLPerf comparison.
  • For agentic workloads: verified that speculative-decoding configs (EAGLE / MTP / draft models) run with simulated synthetic acceptance, with the acceptance-length value taken from the committed golden AL curve in golden_al_distribution/ for that model, thinking mode, and draft length. A submission may choose any supported draft length, but it may not substitute a different acceptance target.
  • Verified against the current MODELS.md that this PR does not submit a deprecated model, scenario, or model-scenario combination.
  • Verified that the model architecture isn't changed with benchmark hacks like using --hf-overrides to skipping indexer for every x layers on models that don't natively support this. As a general rule, we won't accept optimizations that reduces the number of model architecture FLOPs. Anything that makes that same computation run faster is fair game; target/verifier FLOPs at lower precisions is fine, given that the config passes private evals, but this does not permit lowering draft-model or draft-head precision below what ships. As an general north star princple, we should only use optimizations which is used in production by customers that care about accuracy
  • If an company claims that they support vLLM/SGLang as first class LLM inference engines on their hardware, I have verified that the respective vLLM submission made using upstream https://hub.docker.com/u/vllm docker repo, upstream SGLang https://hub.docker.com/u/lmsysorg docker repo. The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet as supported by vLLM/SGLang community maintainers
  • If an company claims that they support vLLM/SGLang as first class upstream in-tree LLM inference engines on their hardware, I have have verified that the respective vLLM/SGLang submission has been made before additional frameworks (TRT-LLM, ATOM, etc.). The only exceptions are for new hardware, such as MI455X UALoE72, Vera Rubin NVL72, Rubin NVL8, etc., and for new model architectures where there is an actual reason why vLLM/SGLang does not fundamentally support them yet.
  • Verified that every single-node vLLM/SGLang recipe in this PR is documented in the official vLLM recipes and/or the SGLang cookbook:
    • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang repo and verified that it is MERGED before this InferenceX PR merges. An opened, draft, or closed-without-merge upstream PR does not satisfy this requirement. If the matching recipe was already published, I linked the published recipe/cookbook page in the additional detail section below.
  • Verified that this PR does not patch the inference engine or serving stack — the pinned image must run as shipped. This covers .patch files / git apply / patch, inline patches embedded in benchmark scripts (e.g. a python3/sed heredoc that rewrites installed engine sources before serving), in-place edits of site-packages, monkey-patching, overwriting container files, and installing forked/rebuilt engine wheels on top of the pinned image. The only exception is a patch covered by a filled-out waiver at docs/waiver/<PR_NUMBER>.md — named after the PR that introduces the patch and filed in that same PR, stating what is patched, why the unmodified upstream image cannot run this benchmark, the upstream PR/issue link, and the removal plan — which I have linked below in the additional detail section.
  • If this PR uses append-only: true, verified that it only adds generated points or recipe variants inside a selected existing config/scenario and existing same-image visual curve: every previously generated point remains present with the same recipe, no prior point is removed or rerun, and every benchmark-affecting change in the complete diff can affect only the corresponding newly appended points (never an existing point), regardless of which file contains it.
  • If any of the above criteria cannot reasonably be satisfied, I have provided additional reasoning below.
  • Reported measured throughput/E2EL Pareto counts and evidence per affected curve (≥5 points strongly recommended). Below 5 or unverifiable: tag a core maintainer for review; recorded admin bypass required before merge. N/A if no curves are affected. Details.

Additional detail section:

  • Assessed head: 27126ca4fa42f301782ce5a4be4c20802f1da50b.
  • Run 35902738208, attempt 1 passed on the assessed head and pinned image. All 16 AgentX performance cells passed across TP2/TP4 and concurrency 1–128; every benchmark and eval job used nodes:1.
  • The matching TP4 GSM8K eval passed with strict exact match 0.9780 ± 0.0040, n_eff=1319, above the 0.90 threshold. Eval artifact.
  • AgentX uses /v1/chat/completions. Performance runs use the committed five-token DSpark golden AL of 3.51; accuracy evaluation restores block rejection with adaptive verification.
  • Draft-as-shipped: the embedded DSpark heads come from checkpoint revision dba1be0a. The pinned vLLM commit 0961bbae loads them with their shipped MXFP4/FP8 quantization; the PR adds no draft-precision override, conversion, substitute checkpoint, or engine patch.
  • The B200 attention settings are scoped behind DSV41_BLACKWELL_ATTENTION=true; only the B200 vLLM launcher enables them. H200, GB200, and GB300 remain unaffected.
  • The model is active in MODELS.md, uses the upstream vllm/vllm-openai image, and introduces no reduced-FLOPs or architecture override. The matching B200 TP2/TP4 configuration is covered by the official DeepSeek-V4.1-Flash recipe.
  • append-only: true: N/A. The PR appends a normal perf-changelog.yaml entry and reruns the affected curve.
  • Pareto coverage: 16 valid measurements produce 7 frontier points for the affected AgentX P90 E2EL versus throughput-per-GPU curve, exceeding the five-point recommendation. Evidence comes from the AgentX artifacts in run 35902738208.
  • Reuse authorization: /use 35902738208 was posted by an authorized collaborator.

Signed: @Ankur-singh

@github-actions

Copy link
Copy Markdown
Contributor

✅✅✅ Verdict: PASS ✅✅✅

Passed and not applicable checks

✅ Check 0 (CODEOWNER): PASS — @ankur-singh is a named owner of configs/nvidia-master.yaml in .github/CODEOWNERS; the other three changed files fall to the * catch-all, which any recognized CODEOWNER satisfies.

✅ Check 1 (Passing sweep on in-PR commit): PASS — PR head 27126ca4 carries run 35902738208 with all 16 executed agentic / performance check-runs (TP2/TP4, c1–c128) and the agentic eval / check-run at success; fixed-sequence single-node */ and eval / jobs are skipped because this config is agentic-only.

✅ Check 2 (Evals pass): PASS — eval artifact agg_eval_all.json: GSM8K em_strict 0.9780 (n_eff 1319) on TP4 c128 with image vllm/vllm-openai:nightly-0961bbae…, above the infx/evals/thresholds.yaml default GSM8K bar of 0.90.

✅ Check 3 (Recipe linked, merged, complete): PASS — published DeepSeek-V4.1-Flash recipe (vllm-project/recipes models/deepseek-ai/DeepSeek-V4.1-Flash.yaml, b200: verified) matches the major args: model, TP2 as the B200 default, Blackwell --attention-config FLASHINFER_MLA_SPARSE_DSV41 with indexer_kv_dtype: mxfp4 and indexer_sparse_logits: true, --kv-cache-dtype fp8, --engram-config cpu_offload, 5-token DSpark --speculative-config, and the deepseek_v41 tokenizer/reasoning/tool parsers. The TP4 arm uses FLASHMLA_MEGA_ATTN_DSV41, a backend the same recipe publishes for Blackwell (DEP section) alongside its "use --tensor-parallel-size 4 for high interactivity" guidance. Informational InferenceX-specific diffs: --max-num-seqs/--max-num-batched-tokens/capture sizing, synthetic AL 3.51, VLLM_ENGINE_READY_TIMEOUT_S=7200.

✅ Check 4 (Reuse command): PASS — /use 35902738208 posted as a whole line by Ankur-singh (COLLABORATOR).

✅ Check 5 (Latest checklist template): PASS — all 17 items (including the merged-upstream sub-item) of the current docs/PR_REVIEW_CHECKLIST.md are present and checked.

✅ Check 6 (Upstream images, engine-first): PASS — dsv41flash-fp4-b200-vllm-agentic-dspark uses framework: vllm with upstream vllm/vllm-openai:nightly-0961bbae2894d574be790d219651824eb199318e; engine-first ordering is inherently satisfied for a vLLM entry.

✅ Check 7 (No deprecated models/scenarios): PASS — dsv41flash agentic coding is active in MODELS.md (added 2026-09-10) on the 2026-09-23 review date.

✅ Check 8 (No architecture hacks): PASS — no --hf-overrides/model-config edits; --attention-config and --kv-cache-dtype fp8 only select kernels and cache precision, not model FLOPs.

✅ Check 9 (Spec-decode via chat template): PASS — the AgentX replay client in benchmarks/benchmark_lib.sh (build_replay_cmd) targets /v1/chat/completions with --endpoint-type chat.

✅ Check 10 (No engine patches): PASS — the diff adds only launch flags and launcher env vars; no patch files, heredoc rewrites, site-packages edits, or wheel installs.

✅ Check 11 (Agentic golden AL): PASS — performance --speculative-config uses rejection_sample_method: synthetic with synthetic_acceptance_length: 3.51, equal to golden_al_distribution/dsv41flash_dspark.yaml thinking_on / 5 speculative tokens; evals use real block rejection.

➖ Check 12 (Append-only): N/A — the new perf-changelog.yaml entry does not set append-only: true.

✅ Check 13 (Draft runs as shipped): PASS — the draft is the embedded three-stage DSpark head (mtp.0–2.*) in checkpoint revision dba1be0a, stored quantized (expert w1/w2/w3 MXFP4 with .scale, attention/dense MXFP8 block [32,32] ue8m0 per quantization_config); vLLM 0961bbae vllm/models/deepseek_v41/nvidia/dspark.py loads those tensors through the default deepseek_v4_fp8 quant config (.scale → weight_scale/weight_scale_inv, e8m0 scales kept raw) with no dtype cast; the PR sets no draft quantization/dtype flag, and --kv-cache-dtype fp8 is an upstream-supported KV dtype applied consistently to target and draft.

✅ Check 14 (Pareto coverage): PASS — one affected curve, dsv41flash / agentic-coding / cluster:b200-nscale / fp4 / run 35902738208 attempt 1 / P90 E2EL / vllm/vllm-openai:nightly-0961bbae… (source SHA 27126ca4): 16 valid bmk_agentic_* measurements (per_gpu.total_tput_tps vs e2el.p90) yield 7 frontier points via infx.workflows.pareto_coverage (TP4 c8/c16/c32/c64/c128 and TP2 c8/c16); run artifacts.

Assessed commit: 27126ca4fa42f301782ce5a4be4c20802f1da50b.

@xinli-sw
xinli-sw force-pushed the config/dsv41flash-b200-vllm-nightly branch from 27126ca to d806a95 Compare September 25, 2026 01:08
@SemiAnalysisAI SemiAnalysisAI deleted a comment from Ankur-singh Sep 25, 2026
更新 B200 DeepSeek-V4.1-Flash vLLM nightly 配方,并在 TP2 和 TP4 使用 FlashInfer 稀疏注意力。
@xinli-sw
xinli-sw force-pushed the config/dsv41flash-b200-vllm-nightly branch from 58aa0a8 to 28647c9 Compare September 25, 2026 02:03
@functionstackx

Copy link
Copy Markdown
Collaborator

InferenceX has switched away from unmaintainable bash scripts to YAML files that don't repeat the same stuff over and over again. Please merge the latest main into this PR: we have migrated single-node AgentX onto native srt-slurm (#3428), so AgentX configs are now declarative YAML recipes, not per-config 1000+ line bash slop scripts. Please also delete the old benchmarks/single_node/** scripts (see this recipe for the new format).

functionstackx added a commit that referenced this pull request Sep 26, 2026
…LLM nightly-0961bbae with FlashInfer sparse indexer + fp8 KV

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@functionstackx

Copy link
Copy Markdown
Collaborator

Closing in favor of #3459, which ports this PR onto the srt-slurm recipe that #3428 switched dsv41flash-fp4-b200-vllm-agentic-dspark to: vLLM nightly-0961bbae, FlashInfer sparse attention with MXFP4 indexer KV and sparse logits at TP2 and TP4, fp8 KV cache, and a 7200 s engine readiness timeout. The shared legacy dsv41flash_fp4_vllm_mtp.sh script and the B200 launcher opt-in this PR edits are no longer on that config's path. Note: the description mentions MegaAttention at TP4, but the script (and your green sweep 35902738208) used FlashInfer at both TP sizes; #3459 follows the script. Thanks!

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

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants