Skip to content

config: update B300 MiniMax-M3 TRT-LLM AgentX to 1.4.0rc0 with 15 points / 配置:将 B300 MiniMax-M3 TRT-LLM AgentX 更新至 1.4.0rc0(15 个点位) - #3835

Closed
hshrivastava-droid wants to merge 7 commits into
mainfrom
minimaxm3-fp4-b300-trtllm-agentic
Closed

hshrivastava-droid wants to merge 7 commits into
mainfrom
minimaxm3-fp4-b300-trtllm-agentic

Conversation

@hshrivastava-droid

@hshrivastava-droid hshrivastava-droid commented Oct 8, 2026 •

Copy link
Copy Markdown
Collaborator

Summary

Update the B300 MiniMax-M3 TensorRT-LLM AgentX config (minimaxm3-fp4-b300-trtllm-agentic-mtp), its recipe, and the performance changelog.

  • Config: minimaxm3-fp4-b300-trtllm-agentic-mtp (aggregated trtllm-serve, EAGLE3 draft Inferact/MiniMax-M3-EAGLE3-GQA)
  • Image: nvcr.io#nvidia/tensorrt-llm/release:1.4.0rc0.dev202610070001 (was 1.3.0rc23.post1)

Points (15)

  • TP2: c10, c15, c20, c25, c30, c35, c40, c45
  • TP4: c1, c5, c10, c20, c25
  • TP8: c1, c5
  • Dropped from the published curve: TP4 c15 and TP4 c30.
  • Draft length: 7 at TP4 c1 and TP8 c1, 5 at TP4 c5 and c10, 3 elsewhere. Synthetic acceptance follows the minimaxm3_eagle3_gqa golden curve (thinking on).

Recipe changes

  • NVFP4 KV cache, block_reuse_config.policy: per_conversation, iteration/perf stats every 10 iterations, tokenization cache, MAXSMS=32.
  • TP4/TP8 use the extended capture_num_tokens ladder; TP2 keeps the short ladder.
  • Host KV pools follow the fix(launch): request explicit Slurm memory for single-node jobs and fit host pools to measured DRAM #3804 DRAM policy: host_cache_size 374,500,000,000 bytes per rank at TP2, 374,750,000,000 at TP4 and 309,237,645,312 at TP8 (TOTAL_CPU_DRAM_GB 749 / 1499 / 2999, dram-utilization 1.0).
  • Tool calls are parsed with trtllm-serve --tool_parser minimax_m3.
  • No engine patch: the TensorRT-LLM chat store patch (setup_script: minimaxm3-trtllm-agentx.sh) is removed.
  • Thinking mode is pinned on for the AgentX replay through chat_template_kwargs (AIPERF_EXTRA_INPUTS), matching the golden acceptance curve.
AI model disclosure
  • Model/version: claude-sonnet-5-5
  • Role: Prepared the config change and PR.
  • Model/version: claude-opus-5-5 (Claude Code, for @Ankur-singh)
  • Role: Removed the engine patch, pinned thinking mode, added the tool parser, adjusted the point list, merged main and updated this description.
PR checklist and change type

Type of Change

  • Bug fix
  • New feature
  • Configuration change
  • Documentation update
  • Other (please describe)

Checklist

  • I have completed the AI model disclosure and kept it current
  • I have tested my changes locally
  • I have updated documentation if necessary
  • For every change that can affect benchmark performance and every recipe addition or modification, I have appended a new entry to the physical end of inferencex-e2e/perf-changelog.yaml and have not edited historical entries
  • If this PR can affect benchmark performance or adds or modifies a recipe, it carries exactly one primary sweep label (a maintainer applies it on fork PRs): full-sweep-fail-fast (recommended), full-sweep-enabled, or non-canary-full-sweep-enabled. Optional modifiers all-evals, evals-only, and agentx-fast require a primary label; the last two block reuse while applied.
  • Before merging via reuse, an authorized maintainer (OWNER/MEMBER/COLLABORATOR) has commented /use <run_id> (or the legacy /reuse-sweep-run) on this PR. Do this only once there is a final full sweep that is all green with evals passing, since after this comment the primary sweep label will no longer automatically kick off new sweeps. Remove and re-add the primary sweep label to force a new sweep.
中文

概述

更新 B300 MiniMax-M3 TensorRT-LLM AgentX 配置(minimaxm3-fp4-b300-trtllm-agentic-mtp)、对应配方及性能变更记录。

  • 配置:minimaxm3-fp4-b300-trtllm-agentic-mtp(聚合式 trtllm-serve,EAGLE3 草稿模型 Inferact/MiniMax-M3-EAGLE3-GQA)
  • 镜像:nvcr.io#nvidia/tensorrt-llm/release:1.4.0rc0.dev202610070001(原为 1.3.0rc23.post1)
  • 点位(15 个):TP2 c10–c45(8 个);TP4 c1、c5、c10、c20、c25;TP8 c1、c5。从已发布曲线中移除 TP4 c15 与 TP4 c30。
  • 草稿长度:TP4 c1 与 TP8 c1 为 7,TP4 c5 与 c10 为 5,其余为 3;合成接受长度取自 minimaxm3_eagle3_gqa 黄金曲线(开启思考)。
  • 配方:NVFP4 KV 缓存、按会话复用块、迭代统计、分词缓存、MAXSMS=32;主机 KV 池遵循 fix(launch): request explicit Slurm memory for single-node jobs and fit host pools to measured DRAM #3804 的 DRAM 策略;使用 --tool_parser minimax_m3 解析工具调用;移除 TensorRT-LLM chat store 补丁;通过 chat_template_kwargs 为回放固定开启思考模式。

AI 模型披露

  • 模型/版本:claude-sonnet-5-5
  • 职责:准备配置变更及 PR。
  • 模型/版本:claude-opus-5-5(Claude Code,代表 @Ankur-singh)
  • 职责:移除引擎补丁、固定思考模式、添加工具解析器、调整点位、合并 main 并更新本说明。

改动类型

配置变更

@github-actions

github-actions Bot commented Oct 8, 2026

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 run only when the PR appends an inferencex-e2e/perf-changelog.yaml entry and carries exactly one primary label: full-sweep-fail-fast (strongly recommended; canary plus per-matrix fail-fast), full-sweep-enabled (canary; matrix jobs continue after a failure), or non-canary-full-sweep-enabled (no canary or fail-fast). The modifiers all-evals, evals-only, and agentx-fast require a primary label. On fork PRs, a maintainer applies the label. See sweep labels and reuse.
  • 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 在 inferencex-e2e/perf-changelog.yaml 末尾追加了条目,并且恰好带有一个主标签时,才会运行扫描:full-sweep-fail-fast(强烈推荐;canary 加逐矩阵 fail-fast)、full-sweep-enabled(有 canary;矩阵任务在失败后继续运行)或 non-canary-full-sweep-enabled(无 canary,也无 fail-fast)。修饰标签 all-evals、evals-only 和 agentx-fast 必须与主标签一起使用。fork PR 的标签由维护者添加。参见扫描标签与复用。
  • **合并后:**PR 作者必须确保所有 GitHub Actions 任务通过。临时性失败通常可以通过重新运行恢复;参见重新运行失败任务的说明。

@hshrivastava-droid hshrivastava-droid added the full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures label Oct 8, 2026

@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 on the pull/TBD placeholder, I also checked two other things and ruled them out: the health-check timeout comment removal (max_attempts/interval unchanged, so no regression even though the capture-time guidance was reworded) and the override_tp4_c15 point missing a max_draft_len override (it inherits the base speculative_config.max_draft_len: 3, same as most other points, rather than being left unset).

Extended reasoning...

The diff is a config-only change (benchmark recipe, master config, changelog) with a confirmed CI-blocking issue: the new changelog entry uses pr-link pull/TBD, which validate_perf_changelog.py's placeholder allowlist (only XXX or the literal .../pull/XXX) will reject. That alone warrants not approving; I additionally checked two other candidate concerns raised during the hunt (health-check timeout margin, tp4_c15 draft length) and found both unaffected by the change.

Comment thread inferencex-e2e/perf-changelog.yaml Outdated
description:
- "Update the B300 TRT-LLM MiniMax-M3 AgentX recipe to the 13 scheduled TP2/TP4/TP8 profiles with NVFP4 KV cache, EAGLE3 speculative decoding, and native DRAM KV offload."
- "Pin the recipe and master config image to nvcr.io#nvidia/tensorrt-llm/release:1.4.0rc0.dev202610070001."
pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/TBD

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.

🔴 The new changelog entry's pr-link placeholder 'pull/TBD' will fail CI validation and block merge of this PR. validate_perf_changelog.py's PR_LINK_PLACEHOLDERS only accepts the literal 'XXX' or 'https://github.com/SemiAnalysisAI/InferenceX/pull/XXX' for new entries (validate_perf_changelog.py:22-24); 'pull/TBD' matches neither that set nor the canonical pull/<pr_number> form, so validate_added_pr_link raises ChangelogValidationError. Fix: use the 'XXX' placeholder (or the real PR number) instead of 'TBD' for new entries' pr-link, matching the validator's accepted forms.

Why this was flagged

The new perf-changelog.yaml entry appended at the tail (around line 9421) sets pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/TBD. validate_added_pr_link in inferencex-e2e/infx/workflows/validate_perf_changelog.py:139-150 checks a new entry's pr-link against PR_LINK_PLACEHOLDERS = {'XXX', 'https://github.com/SemiAnalysisAI/InferenceX/pull/XXX'} (line 22-24) or the exact expected pull/<pr_number> link; 'pull/TBD' is neither, so it raises ChangelogValidationError(f"new PR entry must use {expected!r} or an XXX placeholder; found {link!r}"). This validator runs from .github/workflows/run-sweep.yml:106 (python -m infx.workflows.validate_perf_changelog), so CI fails and blocks merge until TBD is replaced with XXX or the real PR number.

Verification: The appended changelog entry (perf-changelog.yaml, final line) sets pr-link: https://github.com/SemiAnalysisAI/InferenceX/pull/TBD. Being new, compare_entries runs validate_added_pr_link on it (validate_perf_changelog.py:192-193). The link must be in PR_LINK_PLACEHOLDERS ("XXX" or the pull/XXX URL, lines 22-25) or equal the expected pull/{pr_number}; pull/TBD is neither, so ChangelogValidationError is raised (lines 148-150).

@github-actions

github-actions Bot commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

@hshrivastava-droid hshrivastava-droid changed the title config: update B300 MiniMax-M3 TRT-LLM AgentX / 配置:更新 B300 MiniMax-M3 TRT-LLM AgentX [WIP]config: update B300 MiniMax-M3 TRT-LLM AgentX / 配置:更新 B300 MiniMax-M3 TRT-LLM AgentX Oct 9, 2026
@hshrivastava-droid

Copy link
Copy Markdown
Collaborator Author

/use 37814368606

@github-actions

github-actions Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

@hshrivastava-droid staged run 37814368606.

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

@Ankur-singh

Copy link
Copy Markdown
Collaborator

/use 37814368606

@Ankur-singh

Ankur-singh commented Oct 23, 2026 •

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. Explicitly verified that SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE is not enabled in the effective recipe, including inherited settings; enabling it is prohibited going forward, and historical runs do not grant an exception. 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 infx/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
  • For affected Dynamo TRT-LLM benchmarks, verified that iteration/KV-cache metrics are collected and published under the pinned Dynamo implementation and effective engine settings. Resolve the installed Dynamo version separately from the container tag; use supported metrics controls without requiring KV events. Record the version and configuration evidence in the additional detail section. See verifier Check 17. N/A for unaffected serving paths or frameworks without these Dynamo settings.
  • 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 affected vLLM/SGLang production serving configuration in this PR, including Dynamo deployments, is documented in the official vLLM recipes and/or the SGLang cookbook, for both single-node and multi-node aggregated and disaggregated serving. The documentation covers production-useful flags, environment variables, and launch commands (including prefill, decode, and router/frontend commands for disaggregation); InferenceX-only benchmark/harness settings are excluded with reasoning in the additional detail section:
    • I linked the corresponding upstream PR in the vLLM recipe repo or SGLang cookbook source 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:

  • Known gaps, not resolved at 3a57440f:

    • Removed TP4 c15 is not dominated. The published point (run 33219853889, 22,342 tok/s/GPU at 308 tok/s/user) was on the frontier, and no head point beats it on both throughput and interactivity. The nearest head points are TP4 c10 (17,192 / 281) and TP4 c20 (34,433 / 186). TP4 c15 has to be restored, or replaced by a point that dominates it, before merge.
    • Four points ran on degraded nodes. TP2 c15 and TP2 c35 ran on dsxe-sa-b300-prd0-gpu-15; TP4 c5 and TP8 c5 ran on dsxe-sa-b300-prd0-gpu-17. Their time per output token is 1.5x–30x slower than the same point on other nodes or in the published curve (TP8 c5: 75 ms vs TP8 c1: 2.2 ms). In run 40011778426, TP2 c45 on gpu-17 was also about 3x slower than on other nodes. All four are off the frontier, but merging run 40384083329 would replace the published TP4 c5 and TP8 c5 values with these measurements: -63.5% and -82.4% tok/s/GPU. Rerunning them on healthy nodes is recommended.
  • Validation (head 3a57440f): run https://github.com/SemiAnalysisAI/InferenceX/actions/runs/40384083329 (attempt 1). All 15 agentic / jobs and all 16 agentic eval / jobs succeeded:

    • TP2: c10, c15, c20, c25, c30, c35, c40, c45
    • TP4: c1, c5, c10, c20, c25
    • TP8: c1, c5
    • records_error_dropped is 0–3 per point, 10 in total. There are no later commits.
  • Evals: all from the same run, on nvcr.io/nvidia/tensorrt-llm/release:1.4.0rc0.dev202610070001.

    • minimax_m3_full em_strict is 0.97–0.99 (n=102) on all 15 points.
    • gsm8k em_strict is 0.953 (n=1319) on TP2 c45.
    • No lane is materially weaker than its siblings or the ingested peer cohort.
  • Upstream recipe: N/A. This is a TensorRT-LLM trtllm-serve submission with no Dynamo, so the vLLM recipes / SGLang cookbook requirement does not apply.

  • Images and engine-first ordering: the PR uses NVIDIA's TensorRT-LLM release image 1.4.0rc0.dev202610070001, which resolves. The upstream vLLM entry minimaxm3-fp4-b300-vllm-agentic-mtp is already on main.

  • MODELS.md: MiniMax-M3 (minimaxm3) agentic coding is active. Inferact/MiniMax-M3-EAGLE3-GQA is a plan-of-record draft model. Additional non-vLLM/SGLang engines are allowed under the ordering guideline.

  • Chat template and thinking mode:

    • The server is trtllm-serve with --chat_template /model/chat_template.jinja --tool_parser minimax_m3.
    • The AgentX replay uses the chat endpoint (type: chat), with --extra-inputs '{"chat_template_kwargs":{"thinking_mode":"enabled"}}' in each benchmark_command.txt. This pins thinking on, which matches the thinking_on golden curve.
  • Golden AL (minimaxm3_eagle3_gqa.yaml, thinking_on):

    Draft length Golden AL Injected TLLM_SPEC_DECODE_FORCE_NUM_ACCEPTED_TOKENS Points
    3 2.78 1.78 TP2 (all), TP4 c20/c25, TP8 c5
    5 3.21 2.21 TP4 c5/c10
    7 3.52 2.52 TP4 c1, TP8 c1

    The per-job records show the matching value for all 15 points, and the job logs for TP2 c10, TP4 c10 and TP4 c1 confirm the injected values. The recipe sets no acceptance override.

  • Draft precision: the draft is Inferact/MiniMax-M3-EAGLE3-GQA at revision 96692486, a one-layer LlamaForCausalLMEagle3.

    • It is stored as torch_dtype: bfloat16 with no quantization_config.
    • TensorRT-LLM 1.4.0rc0.dev202610070001 loads it with default handling. speculative_config sets only decoding_type: Eagle3, max_draft_len and speculative_model. There is no draft quantization, dtype override or checkpoint substitution.
    • The target checkpoint sets no kv_cache_quant_algo. The recipe asks for dtype: nvfp4 (the base recipe used fp8). The image's MiniMax-M3 hybrid cache keeps the draft at FP8; the TP8 c1 worker log reports "57 sparse target layer(s)=NVFP4/P128, 3 dense target layer(s)=FP8/P128, 1 shared Eagle layer(s)=FP8/P128". So the draft KV stays at FP8, the same as before this PR and the same as the dense target layers.
    • SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE does not apply (TensorRT-LLM) and is absent.
  • Architecture: there are no --hf-overrides, model-config edits, or layer/expert pruning, and the MSA sparse-attention settings are unchanged from main. This PR changes:

    • KV dtype (NVFP4 on the sparse target layers, covered by the evals above)
    • capture ladders and draft length
    • MAXSMS=32
    • tokenization cache, iteration stats and block_reuse_config
  • Dynamo metrics (Check 17): N/A. This is a trtllm_serve frontend without Dynamo. enable_iter_perf_stats: true is set, and AIPerf validated trtllm_kv_cache_utilization on every job.

  • No engine patches: the TRT-LLM chat store patch (setup_script: minimaxm3-trtllm-agentx.sh) is removed. The PR adds no patch files, setup scripts, inline rewrites or engine wheels, so no waiver is needed.

  • append-only: not used.

  • Removed and retuned points:

    • The base curve has 11 published points from run 33219853889 (image 1.3.0rc23.post1).
    • TP4 c30 (40,379 / 159) is dominated by the published TP4 c25 (42,424 / 220).
    • TP4 c15: see Known gaps.
    • Retuned healthy points change throughput by -1% to +5% and interactivity by -31% to -0.4%. For example, TP2 c20: -0.1% / -27%; TP4 c25: -1.0% / -31%; TP8 c1: +4.7% / -0.4%.
  • Reuse: /use 40384083329 was posted by hshrivastava-droid (COLLABORATOR) and staged.

  • Pareto (run 40384083329, total tok/s/GPU vs P90 E2EL, one curve): 8 of 15 points are on the frontier.

    Point P90 E2EL tok/s/GPU
    TP4 c10 10.6 s 17.2k
    TP4 c20 14.1 s 34.4k
    TP4 c25 15.5 s 42.0k
    TP2 c20 21.0 s 59.4k
    TP2 c25 23.2 s 72.0k
    TP2 c30 28.0 s 79.1k
    TP2 c40 41.2 s 88.0k
    TP2 c45 48.7 s 89.7k

    P75 gives 9 of 15 points (TP2 c10 is added). Both meet the 5-point recommendation.

Signed: Ankur-singh

[by Claude Code]

@github-actions

github-actions Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

@Ankur-singh staged run 37814368606.

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

@github-actions

github-actions Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

❌❌❌ REJECTED ❌❌❌

@Ankur-singh Blocking: this PR removes the published TP4 c15 point, which was on the frontier, and no head point dominates it. Restore TP4 c15, or add a point that dominates it, then rerun the sweep before merge.

❌ Check 18 (Recipe, image, and sweep consistency): FAIL — Removed point is on the frontier and not dominated: minimaxm3-fp4-b300-trtllm-agentic-mtp TP4 c15 (run 33219853889: 22,342 tok/s/GPU, mean_intvty 300.3). It was on the base frontier (base TP4 c10 is 16,928/321.5, base TP4 c20 is 34,709/251.9), and signoff_facts dominance finds no head point in run 40384083329 that covers it (nearest: TP4 c10 17,192/280.9, TP2 c10 31,916/197.6). The removed TP4 c30 (40,379/153.8) is allowed because base TP4 c25 (42,424/213.2) dominated it. (a)-(f) pass: the config generates, the master entry and recipe agree, the 1.4.0rc0.dev202610070001 image resolves, and the changelog records the NVFP4 KV, image, and patch-removal changes. (h) The four degraded-node points (TP2 c15/c35 on gpu-15, TP4 c5/TP8 c5 on gpu-17) replace published TP4 c5 and TP8 c5 at -63.5% and -82.4% tok/s/GPU. Rerunning them on healthy nodes is recommended.

⚠️ Check 13 (Draft precision): WARN — minimaxm3-fp4-b300-trtllm-agentic-mtp: the draft weights (Inferact/MiniMax-M3-EAGLE3-GQA, speculative_config with no quantization or dtype override) and SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE (absent; TRT-LLM) are clean. The recipe changes kv_cache_config.dtype from fp8 to nvfp4, and the claimed "1 shared Eagle layer(s)=FP8/P128" is only in the TP8 c1 worker log inside srt-single-node-logs.tar.gz, which I could not inspect. The checkpoint torch_dtype: bfloat16 could not be fetched either. Human review is needed to confirm that the draft KV stays at FP8 under the pinned image.

Passed and not applicable checks

✅ Check 0 (CODEOWNER): PASS — @ankur-singh is listed for inferencex-e2e/configs/nvidia-master.yaml and srt-slurm-recipes/**/b300-*/; perf-changelog.yaml falls under the catch-all.

✅ Check 1 (Passing sweep on in-PR commit): PASS — pinned head 3a57440f has 15/15 agentic / and 15/15 agentic eval / successful in run 40384083329; no later commits.

✅ Check 2 (Evals): PASS — the same run used image 1.4.0rc0.dev202610070001; minimax_m3_full em_strict is 0.97-0.99 (n=102) on all 15 points and gsm8k is 0.953 (TP2 c45, vs 0.956 cohort in run 33219853889); no row is materially weaker than its sibling or the cohort, and the NVFP4 KV path is exercised by every eval lane.

➖ Check 3 (Upstream recipe): N/A — only a TensorRT-LLM trtllm_serve aggregated config without Dynamo is affected; no vLLM/SGLang serving configuration changes.

✅ Check 4 (Reuse command): PASS — /use 40384083329 was posted by hshrivastava-droid (COLLABORATOR) on 2026-10-27; it is the newest authorized command.

✅ Check 5 (Latest checklist template): PASS — all current template items are present and checked.

✅ Check 6 (Upstream images and engine-first ordering): PASS — the trt entry is a vendor framework, and the open-source entry minimaxm3-fp4-b300-vllm-agentic-mtp (runner cluster:b300-dsxe) is already on main.

✅ Check 7 (Deprecated models/scenarios): PASS — minimaxm3 agentic coding is active in MODELS.md, and the EAGLE3-GQA draft is plan-of-record.

✅ Check 8 (No architecture hacks): PASS — there are no --hf-overrides, model-config edits, or pruning, and MSA settings are unchanged; the NVFP4 target KV is covered by Check 2 evals.

✅ Check 9 (Spec-decode chat template): PASS — the AgentX replay uses the chat endpoint with --chat_template and chat_template_kwargs thinking on.

✅ Check 10 (No engine patches): PASS — setup_script: minimaxm3-trtllm-agentx.sh is removed and the pinned recipe has no patch, setup script, or wheel install.

✅ Check 11 (Agentic golden AL): PASS — the connector injected TLLM_SPEC_DECODE_FORCE_NUM_ACCEPTED_TOKENS 2.52 for TP4 c1 (draft 7, golden 3.52) and 1.78 for TP8 c5 (draft 3, golden 2.78) per the job logs, matching minimaxm3_eagle3_gqa.yaml thinking_on; the recipe hard-codes no acceptance value.

➖ Check 12 (Append-only): N/A — no append-only: true entry.

✅ Check 14 (Pareto coverage): PASS — one curve (minimaxm3 / agentic / B300 trt / fp4 / run 40384083329 / P90 E2EL vs tok/s/GPU) has 8 frontier points: TP4 c10, TP4 c20, TP4 c25, TP2 c20, c25, c30, c40, c45 (run 40384083329 bmk_agentic_* artifacts, image 1.4.0rc0.dev202610070001).

✅ Check 15 (PR description): PASS — the image, 15-point list, dropped TP4 c15/c30, draft lengths, NVFP4 KV, host-pool sizes, tool parser, and patch removal all match the pinned code.

➖ Check 16 (NVIDIA overview): N/A — the only affected NVIDIA config uses TensorRT-LLM, so there is no vLLM/SGLang pair.

➖ Check 17 (Metrics publication): N/A — trtllm_serve frontend with no Dynamo; enable_iter_perf_stats: true is set.

Assessed commit: 3a57440f325a9d66b70bcced7b7aa7891aba3b77.

@Ankur-singh Ankur-singh added full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures and removed full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures labels Oct 23, 2026
@hshrivastava-droid

Copy link
Copy Markdown
Collaborator Author

/use 40011778426

@github-actions

github-actions Bot commented Oct 26, 2026 •

Copy link
Copy Markdown
Contributor

@hshrivastava-droid staged run 40011778426.

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

@Ankur-singh Ankur-singh changed the title [WIP]config: update B300 MiniMax-M3 TRT-LLM AgentX / 配置:更新 B300 MiniMax-M3 TRT-LLM AgentX config: update B300 MiniMax-M3 TRT-LLM AgentX / 配置:更新 B300 MiniMax-M3 TRT-LLM AgentX Oct 26, 2026
@Ankur-singh Ankur-singh removed the full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures label Oct 26, 2026
@Ankur-singh Ankur-singh added the full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures label Oct 26, 2026
@Ankur-singh Ankur-singh changed the title config: update B300 MiniMax-M3 TRT-LLM AgentX / 配置:更新 B300 MiniMax-M3 TRT-LLM AgentX config: update B300 MiniMax-M3 TRT-LLM AgentX to 1.4.0rc0 with 15 points / 配置:将 B300 MiniMax-M3 TRT-LLM AgentX 更新至 1.4.0rc0(15 个点位) Oct 26, 2026
@Ankur-singh Ankur-singh added full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures and removed full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures labels Oct 26, 2026
@hshrivastava-droid

Copy link
Copy Markdown
Collaborator Author

/use 40384083329

@github-actions

github-actions Bot commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

@hshrivastava-droid staged run 40384083329.

This run remains available across future /stage-results requests. Staging the same run ID again updates its staged data. Staging workflow

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

Labels

full-sweep-enabled Full sweep with canary gate; matrix jobs run to completion despite failures

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants