[edwingao28]

Summary

Run MiniMax-H3 video sweeps from native srt-slurm YAML recipes on SGLang v0.5.23. Each deployment seals media, request windows, GPU UUIDs and power; merge reuses only a run covering every selected deployment.

flowchart LR
    subgraph sweep["PR sweep: run-sweep.yml"]
        A["Config row + h3-v2.yaml"] --> B["srt-slurm job<br/>SGLang server + C1 client"]
        B --> C["Sealed bundle<br/>media, request windows,<br/>GPU UUIDs, power"]
        C --> D["validate-video-results"]
    end
    subgraph merge["After merge: merge-ingest.yml"]
        E["Re-validate reused bundles"] --> F["Publish to the InferenceX App"]
    end
    D -->|"/use run_id"| E

Loading

Results (final sweep, 035a2afb): MiniMax-H3 42ed227e BF16, C1, 124 frames, 1344×768, 49 steps.

GPU	Parallelism	Measured + warmup	Valid	p50 per clip	Max per clip
H100 ×4	TP2 + Ulysses2	20 + 1	20/20	74.46 s	74.61 s
B200 ×4	Ulysses4	20 + 1	20/20	36.27 s	36.85 s

Check	Result
CI	Canary, video jobs and validate-video-results pass
Server logs	49/49 steps; 0 IPC all-to-all fallbacks
Bundles	Media, power and GPU UUIDs verified
Current-head validator	Both bundles pass
Dashboard	Both published H3 points kept

Limits: Semantic quality is unjudged; H200 follows separately. Post-sweep commits (harness move, spec rename, failure-path fixes) ran CPU CI only. Merge with the reuse helper from this branch: main's /use check predates video artifacts.

Stacked on #4657 and #4658.

AI model disclosure

• Model/version: claude-opus-5-5 and claude-fable-5-1 for this revision; earlier commits could not be verified.
• Role: implementation, CI runs and PR text.

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
• If python -m infx.matrix.changed --base origin/main lists affected config keys, I have appended one new entry covering them to the physical end of inferencex-e2e/perf-changelog.yaml; if it lists none, I have added none. I have not edited historical entries
• If this PR appends an inferencex-e2e/perf-changelog.yaml entry, 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.

中文

通过原生 srt-slurm YAML 配方在 SGLang v0.5.23 上运行 MiniMax-H3 视频扫描。每个部署都会封存媒体、请求时间窗、GPU UUID 和功耗；合并时只复用覆盖全部选中部署的 run。流程见上方流程图。

结果（035a2afb 的最终扫描）：MiniMax-H3 42ed227e BF16，C1，124 帧，1344×768，49 步。

GPU	并行方式	测量 + warmup	有效	每段 p50	每段最大值
H100 ×4	TP2 + Ulysses2	20 + 1	20/20	74.46 s	74.61 s
B200 ×4	Ulysses4	20 + 1	20/20	36.27 s	36.85 s

检查项	结果
CI	canary、video job 和 validate-video-results 均通过
服务端日志	49/49 步；IPC all-to-all 回退 0 次
产物	媒体、功耗和 GPU UUID 均通过校验
当前 head 的校验器	两个产物均通过
仪表板	已发布的两个 H3 数据点都保留

限制： 尚未评估语义质量；H200 另行跟进。扫描之后的提交（harness 迁移、spec 重命名、失败路径修复）只跑了 CPU CI。main 上的 /use 检查早于 video 产物支持，合并时请在本分支上运行复用合并脚本。

基于 #4657 和 #4658。

AI 模型：本次修改使用 claude-opus-5-5 和 claude-fable-5-1，负责实现、CI 运行和 PR 文案；更早的提交无法确认所用模型。

[github-actions]

Thanks for the contribution! Please reach out to respective companies' CODEOWNER to fill in the latest PR_REVIEW_CHECKLIST.md before pinging core maintainer on Slack for review. In order for the signoff PR check bot to trigger, you must follow the PR_REVIEW_CHECKLIST.md template correctly, including the phrase As a PR reviewer and CODEOWNER, I have reviewed this and have.

For PR verification, add the full-sweep-fail-fast label (strongly recommended) to this PR — the benchmark sweep only runs on labeled PRs. Use full-sweep-enabled only if you need matrix jobs to keep running past a failure.

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. See GitHub's docs on re-running failed jobs

---

感谢你的贡献！请联系相应公司的 CODEOWNER 填写最新的 PR_REVIEW_CHECKLIST.md，然后再在 Slack 上联系核心维护者进行审阅。为了触发 signoff PR 检查机器人，你必须正确遵循 PR_REVIEW_CHECKLIST.md 模板，包括保留英文语句 As a PR reviewer and CODEOWNER, I have reviewed this and have。

如需进行 PR 验证，请为此 PR 添加 full-sweep-fail-fast 标签（强烈推荐）— 基准测试 sweep 仅在带有标签的 PR 上运行。仅当需要矩阵任务在失败后继续运行时才使用 full-sweep-enabled。

PR 作者有责任确保合并后所有 GitHub Action 任务完全通过。 很多时候失败只是偶发抖动（flake），重新运行失败的任务即可解决。参见 GitHub 关于重新运行失败任务的文档

[functionstackx]

Sorry, over the weekend, there was 2 major refactors to clean up the technical debt accumalated over the past 11 months of moving at the speed of light. We don't see any major refactors in the forthseeable future besides cleaning up AMD multinode AgentX pile of bash. As much, due to the refactors, u would need to ask your agent to rebase from remote main@latest. Thank you in advance for ur understanding

[edwingao28]

/use 41812249525