ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

MergeKit 贡献指南:从环境搭建、CLA 签署到 Pull Request 合入的完整开发者流程

MergeKit 贡献指南:从环境搭建、CLA 签署到 Pull Request 合入的完整开发者流程 大模型模型优化AI 应用【免费下载链接】mergekitTools for merging pretrained large language models.项目地址https://gitcode.com/gh_mirrors/me/mergekit点击查看免费下载MergeKit 是一套面向预训练大语言模型合并merging的工具集无论是新增一个合并算法、修复合并流程中的缺陷还是改进文档与测试社区贡献都是其持续演进的重要来源。本文以仓库根目录的 CONTRIBUTING.md 为主线结合 pyproject.toml、.pre-commit-config.yaml、.github/workflows 与 tests/ 目录中的真实实现完整梳理从提交 Issue、签署 CLA、搭建开发环境、完成贡献工作流到提交并合入 Pull Request 的全过程。读完本文你将掌握一套可直接照做的 MergeKit 开发者入门流程并清楚每个环节背后对应的仓库依据。报告问题Reporting Issues高质量 Issue 的七个要素在动手贡献代码之前报告问题是参与 MergeKit 最直接的起点。遇到 Bug 或有新功能需求时应当先搜索已有 Issue确认问题或建议没有被重复报告过再决定是否新建。当需要提交 Issue 时请尽量提供足够详细的信息CONTRIBUTING.md 明确列出了以下要素清晰且有描述性的标题clear and descriptive title复现步骤steps to reproduce the issue预期行为expected behavior实际行为actual behavior合并配置merge configuration如果适用——对 MergeKit 而言YAML 合并配置是定位问题的关键输入例如 examples/ 目录下的linear.yml、slerp.yml等配置文件所对应的内容相关日志或错误信息any relevant logs or error messages运行环境environment操作系统、Python 版本、MergeKit 版本由于 MergeKit 的运行强依赖torch、transformers、safetensors等库见 pyproject.toml 的dependencies列表环境的微小差异可能导致行为不同因此在 Issue 中注明 Python 版本与依赖版本能显著提升排查效率。签署 Contributor License AgreementCLA在贡献被接受之前每位贡献者都必须签署 CLA.md 中的贡献者许可协议。这是一次性流程通过 CLA Assistant 机器人自动化完成当你提交第一个 Pull Request 时机器人会在 PR 评论中给出电子签署指引按要求回复签署语句即可。仓库中的 .github/workflows/cla.yml 是这一流程的自动化实现依据该工作流监听issue_comment与pull_request_target事件当评论内容为I have read the CLA Document and I hereby sign the CLA或recheck时触发 CLA Assistant 动作contributor-assistant/github-actionv2.6.1并将签名记录写入独立的签名仓库同时通过allowlist: bot*,dependabot*为机器人账号放行。从 CLA.md 的正文可以看出该协议是 Arcee 标准的贡献者许可协议核心内容包括贡献者授予 Arcee 及软件分发接收方永久、全球性、非独占、免许可费、不可撤销的版权许可与专利许可第 2 节放弃与贡献相关的精神权利第 2.3 节并作出关于贡献所有权、雇主授权等声明与保证第 3 节。签署它保护的是贡献者本人以及 Arcee 及其用户双方的利益同时不改变你对自己贡献的其他使用权利。开发环境搭建Development Environment Setup1. Fork 仓库点击仓库页面右上角的 Fork 按钮在个人账号下创建一份仓库副本。后续所有修改都在你的 fork 上进行。2. 克隆你的 Forkgit clone YOUR-FORK-URL cd mergekit将YOUR-FORK-URL替换为你 fork 出来的仓库地址。3. 配置 upstream 远程仓库为便于拉取上游的最新更新建议添加一个指向原仓库的远程引用git remote add upstream UPSTREAM-REPO-URL之后即可用git fetch upstream同步上游main分支的进展。4. 创建虚拟环境推荐CONTRIBUTING.md 推荐使用 uv 管理虚拟环境uv venv .venv source .venv/bin/activate # Windows 下为 .venv\Scripts\activate也可以使用venv、virtualenv或conda等任何你熟悉的工具例如python3 -m venv .venv source .venv/bin/activate5. 安装依赖editable 模式以可编辑模式安装 MergeKit同时安装开发与测试依赖uv pip install -e .[test,dev] # 或直接使用 pip # pip install -e .[test,dev]这一命令对应的依赖定义可以在 pyproject.toml 中查到项目要求requires-python 3.10运行时依赖包括torch2.0.0、safetensors~0.5.2、accelerate~1.6.0、transformers5.0,6.0、peft0.18.0等dev可选依赖包含black~25.1.0、isort~6.0.1、pre-commit~4.2.0test可选依赖为pytest~8.4.0。此外还有evolveray、cma、lm_eval、wandb与vllm等按需启用的额外依赖组。安装成功后pyproject.toml 的[project.scripts]段会注册mergekit-yaml、mergekit-legacy、mergekit-moe、mergekit-evolve、mergekit-tokensurgeon等命令行入口你可以用它们快速验证开发环境是否就绪。6. 安装 pre-commit 钩子MergeKit 使用 pre-commit 做自动化代码格式化与静态检查安装钩子pre-commit install仓库根目录的 .pre-commit-config.yaml 定义了实际生效的检查项包括check-added-large-files阻止误提交大文件、check-yaml、check-json、check-ast语法检查、isortimport 排序采用 black profile见 pyproject.toml 的[tool.isort]、black代码格式化行宽 88见[tool.black]以及trailing-whitespace与end-of-file-fixer两个收尾清理钩子。贡献工作流Contribution Workflow1. 同步本地main分支新建分支前先确保本地main与上游main同步git checkout main git fetch upstream git merge upstream/main # 或使用 rebase git push origin main # 可选保持 fork 的 main 分支同步2. 创建功能分支从最新的main分支切出新分支建议采用有意义的命名例如fix/readme-typo或feat/new-merge-algorithmgit checkout -b my-feature-branch3. 进行修改编写代码、补充测试并按需更新文档。提交方式可以随个人习惯因为 PR 在合入前总是会被 squash 压缩为一个提交无需过分纠结提交历史是否整洁。对 MergeKit 而言新增合并算法这类功能改动通常涉及 mergekit/merge_methods/ 目录注册新方法与 tests/test_basic_merges.py 中的对应测试纯文档类改动则可能集中在 docs/ 目录。4. 运行 pre-commit 钩子git commit时钩子会自动运行也可以手动对所有文件执行检查pre-commit run --all-files该命令会完成代码格式化并检查 lint 问题。所有检查必须通过否则 PR 无法合入。对应地仓库的 CI 工作流 .github/workflows/pre-commit.yml 也会在每次推送时以--show-diff-on-failure --all-files方式执行同一套 pre-commit 检查。5. 运行测试运行完整测试套件确认没有引入回归pytest tests/[pytest.ini_options]在 pyproject.toml 中指定了testpaths [tests]并配置了对huggingface_hub等第三方库警告的过滤。测试目录 tests/ 中的测试文件覆盖了合并方法test_basic_merges.py、架构转换test_architecture_conversion.py、图执行test_graph.py、IOtest_io.py等模块。值得一提的实用细节测试共享夹具定义在 tests/common.py 中通过make_picollama、make_picogranite、make_gpt2size、make_picoLlaVa等函数生成极小规模的微型模型如 2 层、hidden_size 32 的 Llama并由run_and_check_merge在临时目录中执行合并、校验输出是否含 NaNcheck_nan、张量是否完整check_tensors。这意味着绝大多数测试无需下载真实大模型即可运行非常适合本地开发调试。所有测试必须全部通过贡献才能被合入。6. 推送你的修改git push origin my-feature-branch若因远程分支不存在而报错可加--set-upstream参数git push --set-upstream origin my-feature-branch提交 Pull RequestSubmitting a Pull Request打开 Pull Request推送分支后GitHub 通常会检测到 fork 中新推送的分支并提示创建 PR若没有提示点击 New pull request 按钮手动创建。确认目标分支确保 PR 的 base 仓库是原仓库arcee-ai/mergekit、base 分支为mainhead 仓库是你的 forkcompare 分支为my-feature-branch。撰写标题与描述标题清晰、简洁描述中解释改动的是什么what与为什么why通过输入#加 Issue 编号关联相关 Issue例如Closes #123可在 PR 合入时自动关闭对应 Issue若 PR 尚在进行中可以先创建为草稿draftPR待完成后标记为 ready for review。Pull Request 审查与合入流程Review Process自动化检查CI提交 PR 后CI 会自动运行。依据 .github/workflows/pre-commit.ymlCI 会先执行 pre-commit 检查随后在 Python3.10、3.11、3.12三个版本的矩阵上运行uv run pytest超时上限 5 分钟。若检查失败请查看日志、修复问题并重新推送PR 会自动更新。维护者审查一位或多位维护者会审阅 PR可能提出修改意见、建议或澄清请求。处理反馈针对评论逐条回应并推送更新PR 会随新提交自动更新。批准与合入一旦 PR 获得批准且所有检查通过维护者会合入你的贡献。进一步阅读README.mdMergeKit 的功能总览与快速上手。docs/create_a_merge_method.md编写自定义合并方法的分步指南适合准备实现新合并算法的贡献者。docs/merge_methods.md已内置合并方法的详细说明可作为实现参考。tests/测试套件贡献代码时建议对照 tests/common.py 与 tests/test_basic_merges.py 的写法补充对应测试。从提交高质量 Issue、签署 CLA到完成环境搭建、通过 pre-commit 与 pytest 检查并最终合入 PR这套流程既是 MergeKit 对贡献者的基本要求也是理解其工程质量标准的窗口。无论你的目标是修复一个小问题还是为它新增一种合并算法按本文的步骤走完一遍就能以规范的方式把你的改动带进这个项目。赞分享大模型模型优化AI 应用【免费下载链接】mergekitTools for merging pretrained large language models.项目地址https://gitcode.com/gh_mirrors/me/mergekit点击查看免费下载相关推荐SiP (AscendSiPBoost) 社区贡献指南从签署 CLA 到 Pull Request 合入的完整流程SiP AscendSiPBoost 社区贡献指南从签署 CLA 到 Pull Request 合入的完整流程 本文为 CANN 开放项目 SiPAscen算子库高性能计算CANNAscendChocolateychoco开源贡献指南从 CLA 签署到 Pull Request 合并的完整流程Chocolateychoco开源贡献指南从 CLA 签署到 Pull Request 合并的完整流程 Chocolatey 是 Windows 平台的包包管理器CLI开发工具OGX 贡献指南从环境搭建到合并 Pull Request 的完整开发流程OGX 贡献指南从环境搭建到合并 Pull Request 的完整开发流程 OGXOpen GenAI Stack是一个开源的、OpenAI 兼容的 APAI应用API网关后端模型推理服务创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表