- 人工智能
- 大模型
- 模型评测
- Agent 评测
【免费下载链接】InferenceX
Open Source AI Accelerator Research Platform Standard / 开源推理研究平台
InferenceX 是一个开源推理研究平台（Apache 2.0 许可），持续追踪 vLLM、SGLang 等主流推理框架在 Blackwell、AMD MI 系列等硬件上的性能表现。本文是一份面向新手的InferenceX 社区贡献完全指南，带你一步步搞懂：如何提交一个规范的 PR、如何跑绿基准测试 Sweep、如何通过 CODEOWNER 评审的 Review Checklist，最后借助/use命令完成合并。
官方贡献流程定义在 CONTRIBUTING.md，AI 协作规范在 AGENTS.md，动手前建议先通读这两份文件。
一、贡献全流程总览：4 步从 PR 到合并
整个评审合并链路设计得非常清晰，可概括为下面 4 步：
| 步骤 | 你要做什么 | 关键产物 |
|---|---|---|
| 1️⃣ PR 验证 | 创建双语标题的 PR，让基准测试 Sweep 跑绿 | 全绿（含 evals）的 full sweep |
| 2️⃣ CODEOWNER 评审 | 邀请对应模块的 CODEOWNER 填写签核清单 | PR Review Checklist 签核评论 |
| 3️⃣ 核心维护者批准 | 在 Slack 联系 core 维护者做最终批准 | 口头批准 |
| 4️⃣ 复用合并 | 维护者评论/use <run_id>，走 reuse 路径合并 | 合并到 main，结果被摄入发布 |
💡 为什么强调"跑绿 Sweep"？因为 GPU 基准测试非常昂贵，运行器由所有开放 PR 共享，所以已批准 PR 的 Sweep 只跑一次——合并时直接复用你的结果，main分支不会重跑。
二、快速上手：克隆仓库与熟悉目录结构
克隆仓库后即可浏览各模块（代码是只读参考，你的改动通过 fork 分支提交 PR）：
git clone https://gitcode.com/gh_mirrors/in/InferenceX.git仓库由几个平行的子项目组成，你在哪个目录改代码，就对应哪个 CODEOWNER：
| 目录 | 内容 | 代码归属 |
|---|---|---|
inferencex-e2e/ | 端到端推理服务基准测试（主战场） | 核心团队 + 按硬件配置的细分负责人 |
collectivex/ | 网络与集合通信基准（实验性 Beta） | CollectiveX 两位负责人 |
operatorx/ | 算子与 Kernel 级基准（实验性 Beta） | OperatorX 负责人 |
power_model/ | 系统级功耗建模 | 核心团队 |
experimental/ | 各类实验性基准 | Experimental 负责人 |
具体的文件级归属关系写在 .github/CODEOWNERS 中。例如 NVIDIA 主配置nvidia-master.yaml和 AMD 主配置amd-master.yaml分别由不同厂商的维护者共同负责，而collectivex/目录整体由固定两位维护者负责。改代码前先查 CODEOWNERS，就能知道自己该邀请谁来评审。
三、第一步：提交一个规范的 PR
3.1 标题必须中英双语
这是硬性要求：PR 标题必须采用<English title> / <中文标题>格式，例如：
Add GB300 NVL72 decode recipe / 新增 GB300 NVL72 解码配方纯英文标题属于不合规，会在进入评审前被打回。Issue 标题同样遵循此格式。
3.2 描述写法：先讲问题，行政信息折叠
打开 PR 时系统会套用官方模板 .github/PULL_REQUEST_TEMPLATE/pull_request_template.md，写法要点：
- Summary 先行：用简短几句话说明问题、改动内容和为什么重要，让评审人不用展开任何折叠块就能看懂 PR；重大风险、破坏性变更、未解决的失败必须留在显眼位置。
- 行政信息折叠：AI 披露、改动类型列表、作者检查清单等放进
<details><summary>…</summary>折叠块，且不要加open属性（保持默认折叠）。 - AI 模型披露必填：每个 PR 都要在折叠块里写明使用的具体 AI 模型/版本及各自角色；纯人工 PR 写
No AI used。只写工具名（如某个代码助手）是不够的。 - 只报告真实验证：验证结果只来自实际的集成或端到端运行，并附上运行链接；冗长日志折叠进
Validation details块。 - 双语正文：PR/Issue 描述与人工评论需同时包含英文和简体中文，中文放在折叠的
<details><summary>中文</summary>小节中。
3.3 影响性能的改动：必须追加 perf-changelog
凡是可能影响基准性能、或新增/修改 recipe 的改动，都必须在 inferencex-e2e/perf-changelog.yaml 的物理末尾追加一条新条目，且严禁修改历史条目（该文件按字节敏感，追加即可）。示例：
- config-keys: - dsv4-fp4-b300-vllm-mtp description: - "Add TP8 at concurrency 12 and 16 to the existing curve" append-only: true两个实用技巧：
- 一个 PR 只对应一个changelog 块，即使改动跨越多个 commit，也修订自己那个块而不是新增。
- 如果 PR 只是给已有曲线追加数据点，给条目加上
append-only: true，Sweep 会对比基线与头部的生成矩阵，只跑新增的点，大幅节省 GPU 时间。
四、第二步：通过 PR 验证并跑绿 Sweep
4.1 选择正确的 sweep 主标签
PR 验证由 run-sweep.yml 工作流驱动。只有改动了perf-changelog.yaml的同仓库 PR 才触发 Sweep，且必须带恰好一个主标签：
| 主标签 | 说明 | 适用场景 |
|---|---|---|
full-sweep-fail-fast | 全量矩阵 + 金丝雀 + 失败即停 | ✅推荐的默认选择 |
full-sweep-enabled | 全量矩阵，失败不停止 | 需要每个矩阵点都跑完时 |
non-canary-full-sweep-enabled | 全量矩阵，无金丝雀 | 特殊场景 |
可选修饰标签all-evals、evals-only、agentx-fast不能替代主标签；其中后两个会阻止合并时的结果复用，慎用。标签语义的完整说明见 inferencex-e2e/docs/ci-procedures.md。
4.2 Fork PR 的特殊流程
外部贡献者没有打标签的权限。当你的 PR 处于"开放、就绪、无合并冲突"状态时，由维护者代为打上标签（只批准当前 head SHA）；此后你每 push 一次，维护者都需要移除并重新添加主标签来触发新一轮 Sweep。
五、第三步：通过 CODEOWNER 评审与 Review Checklist
5.1 谁来签核？
当改动文件存在非管理员、非@SemiAnalysisAI/core的 CODEOWNER时，需要邀请一位有资格的 CODEOWNER 在你的审批评论中填写 PR Review Checklist 签核。规则要点：
- 📌每个 PR 只需要一份清单：发帖前先检查是否已有人填过，其他评审人无需重复。
- 补充或修正时，应由原评审人编辑自己的清单评论，而不是新发一份。
- 请始终从
main分支上最新的模板复制清单——清单模板会演进，旧模板签核会被标记为缺项。
5.2 填写 Checklist 的 3 个硬性要求
保留模板开头句，一字不差：
As a PR reviewer and CODEOWNER, I have reviewed this and have:
CI 工作流正是靠这句话触发验证，漏掉它签核将不会被自动复核。
只勾选你真实验证过的项——签核中的勾号"不被信任地接受"，CI 会独立复核。
补充"Additional detail section"：附上验证/eval 工作流运行链接、对应的上游 vLLM recipe 或 SGLang cookbook PR，以及任何例外理由。
5.3 CI 会自动复核你的签核
签核发布后，codeowner-signoff-verify.yml 工作流会独立重新核验清单中的每项声明，包括：CODEOWNER 身份、PR 内某 commit 上全绿的 Sweep 与 evals、链接的 recipe、/use复用命令、是否使用最新模板、上游镜像版本、无架构性基准作弊、投机解码的 chat template 使用，以及草稿模型权重与精度未变等。它会为每份签核生成一条裁决评论，只记录实际评估的 commit——裁决不会随后续 push 自动延续，修正后需重新评估。
六、第四步：/use命令复用 Sweep 结果并完成合并
这是 InferenceX 最有特色的一步，也是新手最容易漏的一步：
- ✅ 全绿 Sweep 出现后，由有权限的维护者（OWNER/MEMBER/COLLABORATOR）在 PR 评论
/use <run_id>（命令与 run ID 需在同一行），指定哪次运行作为结果来源。 - ⚠️复用是强制的：只有全绿 Sweep 还不够，如果没有留档的复用命令，
main上的运行会失败，PR 结果将永远不会被摄入。 - 合并到
main的运行只负责验证并摄入你 PR 的 Sweep 产物，从不重跑 Sweep。 - 有权限的维护者也可使用
merge_with_reuse工作流：它自动发帖、同步main、等待检查并 squash 合并。 - 机器人会以 👍/👎 回应命令的接受与否，详情见 Actions 运行摘要。
七、合并后：你仍是第一责任人
PR 作者有责任确保合并后所有 CI 作业全部通过。经验上，合并后的失败大多是偶发（flake），直接重跑失败的作业通常就能修复。养成合并后盯一会儿 CI 的习惯，是社区非常看重的贡献者素养。
八、高频踩坑清单：一次看懂
| ❌ 常见错误 | ✅ 正确做法 |
|---|---|
| PR 标题只有英文 | 一律<English title> / <中文标题>双语 |
| 漏写或猜测 AI 模型披露 | 写运行时给出的准确模型标识；无法确认就明说；纯人工写No AI used |
| 修改 changelog 历史条目 | 只在文件物理末尾追加新条目 |
| 同一 PR 打多个主标签 | 有且仅有一个主标签 |
| 多份重复的 Checklist | 全 PR 只一份，修正靠编辑原评论 |
| 签核评论漏掉模板开头句 | 逐字保留 "As a PR reviewer and CODEOWNER, I have reviewed this and have:" |
| 投机解码提交降低草稿精度 | 草稿必须"按发布原样运行"（as it ships），不得量化、替换或压低草稿精度 |
| AMD 集群容器以 root 写 runner 工作区 | 输出写到工作区外，或加清理 trap；取消的任务会留下 root 文件并卡死整条队列 |
九、延伸阅读：官方文档与关键路径
- 📖 贡献总规范：CONTRIBUTING.md
- 📖 协作与 AI 代理规范：AGENTS.md
- 📖 CI 流程详解（标签、手动派发、结果发布）：inferencex-e2e/docs/ci-procedures.md
- 📖 评审清单模板：inferencex-e2e/docs/PR_REVIEW_CHECKLIST.md
- 📖 文档总入口与任务路由表：inferencex-e2e/docs/index.md
- 🗂️ 代码归属：.github/CODEOWNERS
- 🗂️ PR 模板：.github/PULL_REQUEST_TEMPLATE/pull_request_template.md
写在最后：InferenceX 的评审链虽然比一般项目严格，但每一步都有明确的规则与自动化工具兜底。抓住"双语标题 → changelog 追加 → 跑绿 Sweep → 一份签核清单 →/use复用"这条主线，你的第一个 PR 就能顺利走完从提交到合并的全程。祝你在 InferenceX 社区的贡献之旅顺利！🚀
- 人工智能
- 大模型
- 模型评测
- Agent 评测
【免费下载链接】InferenceX
Open Source AI Accelerator Research Platform Standard / 开源推理研究平台
相关推荐
Hetty社区贡献指南：从提交PR到代码合并
Hetty社区贡献指南：从提交PR到代码合并 为什么贡献Hetty？ 你是否在安全测试中因工具限制而效率低下？Hetty作为开源HTTP安全测试工具，正致力于成
网络安全应用安全有限状态机在Gin Web中的应用：轻松实现复杂审批流程的终极指南
有限状态机在Gin Web中的应用：轻松实现复杂审批流程的终极指南 在现代化的企业应用中，审批流程管理是每个业务系统都绕不开的核心需求。无论是请假申请、报销审批
STK高级技巧：如何通过Modal与BandedWG创建专业级合成音色
STK高级技巧：如何通过Modal与BandedWG创建专业级合成音色 在音乐制作和音频开发领域，专业级合成音色的创建往往需要复杂的算法和精细的参数调整。 Sy
音频处理音频
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
