[xinli-sw]

Use latest configs for MiniMax M3.1 GB200 AgentX submission.

中文

更新 MiniMax M3.1 GB200 AgentX 提交配置。

AI model disclosure

Prepared by Codex with delegated agents. Exact model/version identifiers could not be verified from the runtime.

[github-actions]

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 任务通过。临时性失败通常可以通过重新运行恢复；参见重新运行失败任务的说明。

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[claude]

🟡 (optional) GB200 AgentX runs now pull whatever image the floating minimax-m31-flash tag points to, so results can change without any config change. The digest pin was dropped at nvidia-master.yaml:5621. The B200, H100 and H200 siblings still pin the same tag to @ sha256:86f582dae25ea92802353727164ae4eb03b37b18baf9119b805ffaec2a7ef07c. Fix: pin the image to a digest, e.g. vllm/vllm-openai:minimax-m31-flash@ sha256:86f582dae25ea92802353727164ae4eb03b37b18baf9119b805ffaec2a7ef07c (the multiarch manifest with the arm64 cu134 build), or keep the previous arm64 digest.

Why this was flagged

The base pinned vllm/vllm-openai:minimax-m31-flash-arm64-cu134@ sha256:5d76347628973fb80519a919a2f2740b6645b62cba3fe2bd87b25f111bd0e948. HEAD uses the bare tag vllm/vllm-openai:minimax-m31-flash (nvidia-master.yaml:5621). This is a model-named tag, not a version, and the vLLM day-zero tags get re-pushed when fixes land. Every GB200 sweep, and any /use <run_id> reuse, then resolves whatever the tag points to when the job pulls. So the published AgentX numbers no longer map to a fixed engine build. Sibling entries at nvidia-master.yaml:5281, 5304 and 5601 still pin the same tag by digest, so only this key loses reproducibility. CONTRIBUTING.md's compliance rules are written against "the pinned upstream image", and with a floating tag that baseline is undefined.

Verification: Trigger: Docker Hub's vllm/vllm-openai:minimax-m31-flash tag is re-pushed after this merges. nvidia-master.yaml:5621 changes to the bare image: vllm/vllm-openai:minimax-m31-flash. enroot_uri in infx/launch/backends/slurm/squash.py:76-87 keeps an immutable digest only when "@ sha256:" is present. GB200 run events therefore lose the engine provenance they had on the base branch.

[claude]

🟡 nit (optional): Nothing ties the hard-coded 450 GB DRAM offload budget to the matrix value. Published results could report a different DRAM allocation than the server actually used. The overrides set cpu_bytes_to_use 450000000000 but omit KV_OFFLOADING and TOTAL_CPU_DRAM_GB from benchmark.env. So the binder check at single_node.py:144-146 is skipped. Fix: add KV_OFFLOADING: dram and TOTAL_CPU_DRAM_GB: '450' to both overrides' benchmark.env, as the B200 sibling does. Then a drift fails the bind instead of mislabeling results.

Why this was flagged

The matrix derives total-cpu-dram-gb in agentic_dram_offload_gb (generate.py:421-459) from dram-utilization 1.0, gb200-nv available-cpu-dram-mib 860_160 (runners.yaml:579) and 2 of 4 GPUs, which gives 450. The workflow exports that as TOTAL_CPU_DRAM_GB (benchmark-tmpl.yml:142). Results record it as allocated_cpu_dram_gb (results/agentic/init.py:192). The recipe repeats the number by hand in kv-transfer-config cpu_bytes_to_use at agg-variants.yaml:62 and :79. validate_recipe (single_node.py:144-146) only compares CONC, KV_OFFLOADING and TOTAL_CPU_DRAM_GB when the recipe's benchmark.env declares them. These overrides declare only CONC. The B200 sibling override_tp4_c32_dram declares KV_OFFLOADING: dram and TOTAL_CPU_DRAM_GB: '1073', so its bind fails on a mismatch. Today both sides give 450, so current results are correct. But if dram-utilization or the runner's available-cpu-dram-mib changes later, the server keeps offloading 450 GB while results publish the new allocation, with no error.

Verification: validate_recipe in inferencex-e2e/infx/srt_slurm/single_node.py:144-146 only compares a value when the recipe declares it. In the new agg-variants.yaml, the benchmark.env of both overrides holds only CONC, while "cpu_bytes_to_use":450000000000 is hard-coded at lines 62 and 79. Today the matrix value is 450, so it matches the recipe. If either input changes and the recipe does not, the bind no longer fails.

[claude]

🟡 (optional) The zip_override_dep4 block in gb200-fp4-mtp/agentic.yaml, with its vllm-router frontend, stays in the repo after this change even though no config uses it. The TP4+EP4 dp-attn row was the only master row that selected that variant, and this diff deletes it. AGENTS.md says to delete recipes that no active config uses. Fix: delete zip_override_dep4 from minimaxm31flash/vllm/gb200-fp4-mtp/agentic.yaml, keeping zip_override_tp4, which line 5636 still uses. Merging that block into agg-variants.yaml would also remove the duplicated base.

Why this was flagged

On the base, the row { tp: 4, ep: 4, dp-attn: true, ..., conc-list: [64, 128], router: vllm-router, srt-recipe: agentic.yaml } selected the DEP4 variant of benchmarks/single_node/srt-slurm-recipes/minimaxm31flash/vllm/gb200-fp4-mtp/agentic.yaml (zip_override_dep4 with CONC ['64','128'], data-parallel-size 4 and setup_script vllm-router.sh). The diff removes that row, and only the TP4 conc 1-32 row stays at nvidia-master.yaml:5636. The recipe file is not touched, so zip_override_dep4 is now an orphan that matches no master row. AGENTS.md "Deprecating benchmark configs" says to delete recipes and assets that no active config uses. On top of that, the new agg-variants.yaml copies agentic.yaml's whole base block, so one recipe design now lives in two files that can drift apart.

Verification: Triggering condition: merging as-is. The diff deletes the only master row that used the DEP4 variant in nvidia-master.yaml. The recipe minimaxm31flash/vllm/gb200-fp4-mtp/agentic.yaml is untouched and still has zip_override_dep4. So the dep4 block is now a dead variant. AGENTS.md:74 says "Delete recipes, setup scripts and other assets that no active config uses any more".

[github-actions]

View unofficial run (performance): https://inferencex.semianalysis.com/inference?unofficialRun=40636603138

View unofficial run (accuracy): https://inferencex.semianalysis.com/evaluation?unofficialRun=40636603138

[xinli-sw]

/use 40636603138

[github-actions]

@xinli-sw staged run 40636603138.

• MiniMax-M3.1-Flash · agentic-traces · FP4 · gb200_dynamo-vllm · 2026-10-28

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

[RohitNagraj]

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:

• PR validation: sweep and eval run, attempt 1, on this PR head. Eval score validation passed; actual dispatch of the selected MegaMoE kernel remains to be verified.
• The committed DSpark golden acceptance setting was recorded for the benchmark jobs; eval-only jobs used real verification.
• Published vLLM recipe includes GB200 aggregate and disaggregated deployments; vLLM recipe PR #64283 is merged. Synthetic acceptance and result collection are benchmark-only controls.
• Draft precision: the public draft configuration declares BF16; the published checkpoint also contains FP8 weights and scale tensors. The run’s checkpoint revision and effective draft-weight precision under the pinned image have not been verified. Human review is needed.
• Power telemetry: the team guidance was added on October 28, after this PR was opened on October 24. This run did not retain GPU or CPU power samples.
• The AgentX client uses the chat-completions endpoint. The recipes contain no architecture overrides; eval logs show NVFP4 indexer selection. Further evidence of MegaMoE kernel dispatch is needed. Pareto evidence requires review. The changelog description needs to identify the newly added configurations and their serving settings. The PR currently has merge conflicts.
• Both configurations use a published vLLM image. They use an open-source engine, so vendor-engine ordering is not applicable. The reachable Mooncake setup installs the published transfer package; the srt-slurm patch concerns telemetry rather than the serving engine.
• Metrics collection and publication for Dynamo TRT-LLM is not applicable to these Dynamo-vLLM configurations. Append-only mode is not used.
• Prepared with assistance from Codex; exact model identifier could not be verified.

中文

• PR 验证：扫描与评测运行的第 1 次尝试针对当前 PR 提交完成。评测分数验证已通过；所选 MegaMoE 内核是否实际调用仍需验证。
• 基准任务记录了已提交的 DSpark 黄金接受长度；仅评测任务使用真实验证。
• 已发布的 vLLM 方案包含 GB200 聚合式和分离式部署；vLLM 方案 PR #64283已合并。模拟接受率及结果收集属于基准工具设置。
• 草稿精度：公开草稿配置声明为 BF16；已发布的检查点还包含 FP8 权重及其缩放张量。此次运行使用的检查点版本及固定镜像中草稿权重的实际精度尚未验证，需要人工审阅。
• 功耗遥测：团队指导于 10 月 28 日加入，晚于此 PR 在 10 月 24 日创建的时间。此次运行未保留 GPU 或 CPU 功耗采样。
• AgentX 客户端使用聊天补全端点。方案中没有架构覆盖设置；评测日志显示选择了 NVFP4 索引器。MegaMoE 内核的实际调用仍需进一步证据，Pareto 相关证据仍需审阅。变更日志需要说明新增配置及其服务设置。此 PR 目前存在合并冲突。
• 两个配置均使用已发布的 vLLM 镜像和开源引擎，因此厂商引擎的提交顺序规则不适用。实际使用的 Mooncake 安装脚本安装已发布的传输包；srt-slurm 补丁涉及遥测，并不修改服务引擎。
• Dynamo TRT-LLM 的指标收集和发布检查不适用于这些 Dynamo-vLLM 配置；此 PR 未使用 append-only 模式。
• 本审阅由 Codex 协助准备；无法验证准确的模型标识。

Signed: RohitNagraj

[github-actions]

❌❌❌ REJECTED ❌❌❌

⚠️ Pareto coverage needs additional review. At least 5 points per affected throughput-versus-E2EL frontier are highly recommended. Below 5, or when coverage cannot be verified, merge only with an explicit, recorded admin bypass for the assessed commit; this advisory comment does not grant or enforce a bypass.

@RohitNagraj Two checks block the merge. First, nothing shows that the selected DeepGEMM MegaMoE kernel actually ran in the evals. Second, the new perf-changelog.yaml entry does not describe the configurations it adds. Draft precision and Pareto coverage also need human review.

❌ Check 2 (Evals pass): FAIL — No eval shows that the MegaMoE path actually ran. The three disaggregated configs select --kernel-config '{"moe_backend":"deep_gemm_mega_moe"}' (disagg-mooncake.yaml, prefill and decode). Their evals in run 40636603138 at 25845c7 scored c256 0.9636, c280 0.9666 and c352 0.9704 gsm8k em_strict, but the job logs show only the launch flag, and the sign-off itself says dispatch is unverified. Provide server-log evidence (from the multinode_server_logs_*lm-eval_ artifacts) that MegaMoE was selected and did not fall back. Accuracy otherwise matches the sibling and cohort runs: every check_2_eval_gaps row is ok, on the same image digest.

❌ Check 18 (Recipe/image/sweep consistency): FAIL — (f2) The new inferencex-e2e/perf-changelog.yaml entry for minimaxm31flash-fp4-gb200-dynamo-vllm-agentic-dspark-agg and -disagg says only "Use latest configs for MiniMax M3.1 AgentX submission". It adds two new GB200 Dynamo-vLLM configs but omits the speculative method (7-token DSpark), the KV cache dtype (NVFP4 target KV and indexer, FP8 draft KV) and the checkpoint/precision (MiniMaxAI/MiniMax-M3.1-Flash, FP4). Entries are permanent, so rewrite it to name these settings. Sub-checks (a)-(e) and (g) pass: no generation errors, master and recipe GPU math agree, the image is already referenced and digest-pinned, Dynamo and Mooncake versions are pinned, and no points were removed.

⚠️ Check 13 (Draft precision): WARN — Draft precision could not be verified for either config, which use the checkpoint's built-in DSpark drafter. The sign-off records that the draft config declares BF16 while the published checkpoint also has FP8 weights and scale tensors, and that the checkpoint revision and the effective draft-weight precision under the pinned image vllm/vllm-openai:minimax-m31-flash-arm64-cu134@sha256:5d76347… are unverified. The speculative-config also sets draft kv_cache_dtype: fp8 while the target KV is nvfp4. Nobody has shown whether this matches or exceeds the pinned image's default draft KV dtype. Human review is needed. SGLANG_NVFP4_CKPT_FP8_NEXTN_MOE does not apply to this vLLM path.

⚠️ Check 14 (Pareto coverage): WARN — 4/5 frontier points on the one affected curve, MiniMax-M3.1-Flash / agentic-coding / gb200_dynamo-vllm / fp4 / run 40636603138 / p90 E2EL. The agg and disagg configs are one app series. I took the 9 measured points from the bmk_agentic_* artifacts of run 40636603138 at 25845c7. The frontier points are c16 (6.89 s, 29.0k tok/s/GPU), 3P1D-DEP16 c280 (9.91 s, 68.6k), 4P1D-DEP16 c352 (11.87 s, 70.1k) and 3P1D-DEP8 c256 (13.83 s, 80.8k). c1, c4, c8, c32 and c40 are dominated. I counted these by hand: the sandbox blocked feeding the input file to pareto_coverage. No admin bypass has been recorded for this SHA.

Passed and not applicable checks

✅ Check 0 (CODEOWNER): PASS — RohitNagraj is a named owner of inferencex-e2e/configs/nvidia-master.yaml and /inferencex-e2e/benchmarks/*_node/srt-slurm-recipes/**/gb200-*/. perf-changelog.yaml falls under the catch-all.

✅ Check 1 (Sweep on in-PR commit): PASS — At pinned head 25845c7 (the PR tip, unchanged), run 40636603138 attempt 1 ran all 9 multi-node agentic / jobs and all 6 multi-node agentic eval / jobs, and every one succeeded. No commits follow it.

✅ Check 3 (Upstream recipe): PASS — The published vLLM recipe comes from vllm-project/vllm#64283, MERGED 2026-10-28T19:17:13Z. Its gb200_agentx_agg and gb200_agentx_pd presets cover the agg (TP4, FLASH_ATTN draft, prefill graphs, SimpleCPUOffload 360 GB) and disaggregated (DEP4 prefill, DEP8/DEP16 decode, MegaMoE, NIXL+Mooncake MultiConnector, UCX/NCCL/MC env, Mooncake master, Dynamo KV-router frontend) settings. Synthetic acceptance is excluded as benchmark-only.

✅ Check 4 (Reuse command): PASS — /use 40636603138 posted by xinli-sw (COLLABORATOR) on 2026-10-28.

✅ Check 5 (Latest checklist): PASS — All 18 current template items are present. The unchecked draft-precision and Pareto items have notes in the additional detail section.

✅ Check 6 (Upstream images, engine-first): PASS — Both entries use the upstream vllm/vllm-openai:minimax-m31-flash-arm64-cu134@sha256:5d76347… image with framework: dynamo-vllm, an open-source engine.

✅ Check 7 (Deprecated models): PASS — minimaxm31flash agentic coding (vLLM DSpark) is active in MODELS.md with no deprecated scenarios.

✅ Check 8 (No architecture hacks): PASS — No --hf-overrides or model edits. The NVFP4 KV and indexer settings are covered by the agg and disagg evals and match the upstream recipe.

✅ Check 9 (Chat template): PASS — The AgentX benchmarks replay traces through the shared agentx profile client, and acceptance is pinned to the golden AL under Check 11.

✅ Check 10 (No engine patches): PASS — The reachable setup_script: vllm-mooncake.sh installs only the published mooncake-transfer-engine-cuda13==0.3.13.post1 KV-store client. The srt-slurm 573-participating-gpus.patch edits only power telemetry in srtctl/core/power/session.py.

✅ Check 11 (Golden AL): PASS — Job logs show the connector injecting "rejection_sample_method": "synthetic", "synthetic_acceptance_length": 4.04 into the agg and prefill/decode speculative configs. This matches the golden value in minimaxm31flash_dspark.yaml for thinking_on with 7 tokens (4.04).

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

➖ Check 15 (PR description): N/A — The PR body says only "Use latest configs for MiniMax M3.1 GB200 AgentX submission" and makes no verifiable technical claims.

✅ Check 16 (NVIDIA overview): PASS — MiniMax-M3.1-Flash has a vLLM entry in the Framework Recipes table of the NVIDIA overview.

➖ Check 17 (Metrics publication): N/A — These are Dynamo-vLLM configs. The Dynamo TRT-LLM metrics controls do not apply.

Assessed commit: 25845c731734bde9298eece5f9ed296e3b0745ca.

[xinli-sw]

confirmed that https://github.com/SemiAnalysisAI/InferenceX/actions/runs/40636603138 uses magemoe in evals

[github-actions]

Ingest report — ✅ Results ingested into the production database.

Ingest workflow · Merge Ingest run · Benchmark source run

Category	new	duplicate	skipped	unmapped	failed
benchmark	9	0	0	0	0
eval	6	6	0	0	0
trace	9	0	0	0	0
power	0	0	9	0	0

_{benchmarkFiles 9, rawBenchmarkRows 9, coveredByPerJobFiles 0, purgedPoints 0, failedRunRows 0, runStatsNew 0, runStatsDuplicate 0, evalSamplesNew 7914, gpuMetricSamplesNew 0, powerPublicationPoints 9, changelogEntriesWritten 1}

Counts cover only this run. Rows: benchmark_results, eval_results, agentic rows linked to a trace, gpu_metrics series. This comment updates if the ingest is rerun.

中文

Ingest 报告 — ✅ 结果已写入 production 数据库。

上表仅统计本次运行写入的数据，各行单位依次为 benchmark_results 行、eval_results 行、已关联 trace 的 agentic 行和 gpu_metrics 序列。重新运行 ingest 时本评论会原地更新。