跳到内容

贡献 vLLM-Omni

感谢您对贡献 vLLM-Omni 的兴趣！本文档提供了贡献的指南和说明。

注意

我们每周二太平洋时间晚上 7:30 举行面向开发者的在线会议，讨论里程碑和更新。会议链接以及过去的会议记录可以在 此处 找到。

入门

vLLM-Omni 使用 uv 作为环境管理器，用于创建和管理 Python 环境。请遵循文档安装 uv。安装 uv 后，您可以使用以下命令创建一个新的 Python 环境

uv venv --python 3.12 --seed
source .venv/bin/activate

vLLM 的开发环境

vLLM-Omni 基于 vLLM 的稳定版 0.11.0 构建。您可以直接安装 vllm==0.11.0，或者如果您需要检查、修改或调试 vLLM 的源代码，可以从源代码安装该库。

vLLM-Omni 的开发环境

从源代码安装 vLLM-Omni 并包含开发依赖项

git clone https://github.com/vllm-project/vllm-omni.git
cd vllm-omni
uv pip install -e ".[dev]"

提示

vLLM-Omni 兼容 Python 3.10 至 3.12 版本。但是，我们建议使用 Python 3.12 进行开发，以最大程度地减少本地环境与我们的 CI 环境发生冲突的可能性。

代码风格检查

vLLM-Omni 使用 pre-commit 对代码库进行代码风格检查和格式化。如果您不熟悉 pre-commit，请参阅 pre-commit 文档。设置 pre-commit 非常简单，只需执行以下操作：

uv pip install pre-commit
pre-commit install

vLLM-Omni 的 pre-commit 钩子现在会在您每次提交时自动运行。

提示

您可以使用以下命令手动运行 pre-commit 钩子：

pre-commit run     # runs on staged files
pre-commit run --show-diff-on-failure --color=always --all-files  # runs on all files (short for --all-files)

文档

MkDocs 是一个快速、简单且极其美观的静态站点生成器，旨在构建项目文档。文档源文件使用 Markdown 编写，并通过单个 YAML 配置文件 mkdocs.yml 进行配置。

开始使用

uv pip install -e ".[docs]"

MkDocs 带有一个内置的开发服务器，可以让您在工作时预览文档。从仓库的根目录运行：

mkdocs serve                           # with API ref (~10 minutes)
API_AUTONAV_EXCLUDE=vllm_omni mkdocs serve  # API ref off (~15 seconds)

一旦在日志中看到 Serving on http://127.0.0.1:8000/，实时预览就已准备就绪！在浏览器中打开 http://127.0.0.1:8000/ 查看。

有关其他功能和高级配置，请参阅

测试

vLLM-Omni 使用 pytest 测试代码库。

# Run all tests
pytest tests/

# Run tests for a single test file with detailed output
pytest -s -v tests/test_omni_llm.py

警告

目前，并非所有单元测试在 CPU 平台上都能通过。如果您没有 GPU 平台可以在本地运行单元测试，请暂时依赖持续集成系统来运行测试。

问题

如果您遇到 Bug 或有功能请求，请先搜索现有问题，看看是否已有报告。如果没有，请提交一个新问题，并尽可能提供相关的详细信息。

重要

如果您发现安全漏洞，请通过创建带有 security 标签的 GitHub 问题来报告。

Pull Requests & 代码审查

感谢您为 vLLM-Omni 做出贡献！在提交 Pull Request 之前，请确保 PR 符合以下标准。这有助于 vLLM-Omni 保持代码质量并提高审查过程的效率。

DCO 和 Signed-off-by

当贡献此项目时，您必须同意 DCO。提交必须包含 Signed-off-by: 头部，以证明同意 DCO 的条款。

在 git commit 中使用 -s 将自动添加此头部。

提示

您可以通过 IDE 启用自动签名

  • PyCharm：在 Commit 窗口中，点击 Commit and Push... 按钮右侧的 Show Commit Options 图标。这将弹出一个 git 窗口，您可以在其中修改 Author 并启用 Sign-off commit。
  • VSCode：打开 Settings 编辑器，并启用 Git: Always Sign Off (git.alwaysSignOff) 字段。

PR 标题和分类

只有特定类型的 PR 才会被审查。PR 标题应加上适当的前缀以表明更改类型。请使用以下前缀之一：

  • [Bugfix] 用于 Bug 修复。
  • [CI/Build] 用于构建或持续集成改进。
  • [Doc] 用于文档修复和改进。
  • [Model] 用于添加新模型或改进现有模型。模型名称应出现在标题中。
  • [Frontend] 用于 vLLM-Omni 前端（例如，OpenAI API 服务器，OmniLLM 类等）的更改
  • [Kernel] 用于影响 CUDA 内核或其他计算内核的更改。
  • [Core] 用于 vLLM-Omni 核心逻辑（例如，OmniProcessor，OmniARScheduler 等）的更改
  • [Hardware][Vendor] 用于特定硬件的更改。供应商名称应出现在前缀中，例如 [Ascend] 用于 Ascend NPU。
  • [Misc] 用于不符合上述类别的 PR。请谨慎使用。

注意

如果 PR 跨越多个类别，请包含所有相关的前缀。

代码质量

PR 需要满足以下代码质量标准：

  • 我们遵循 Google Python 风格指南和 Google C++ 风格指南。
  • 通过所有 linter 检查。
  • 代码需要有充分的文档，以确保未来的贡献者可以轻松理解代码。
  • 包含足够的测试以确保项目保持正确和健壮。这包括单元测试和集成测试。
  • 如果 PR 修改了 vLLM-Omni 的用户可见行为，请在 docs/ 目录中添加文档。这有助于 vLLM-Omni 用户理解和利用新功能或更改。

关于重大更改的说明

请尽量保持更改的简洁。对于重大的架构性更改（超过 500 行代码，不包括内核/数据/配置/测试），我们希望有一个 GitHub issue (RFC) 来讨论技术设计和理由。否则，我们将将其标记为 rfc-required，并且可能不会处理该 PR。

审查预期

vLLM-Omni 团队的目标是成为一个透明的审查机器。我们希望使审查过程透明且高效，并确保没有任何贡献者感到困惑或沮丧。然而，vLLM-Omni 团队规模不大，因此我们需要优先处理某些 PR。以下是您对审查过程的预期：

  • PR 提交后，PR 将被分配给一名审查员。每位审查员将根据其专业知识和可用性来处理 PR。
  • PR 分配后，审查员将每 2-3 天提供一次状态更新。如果 PR 在 7 天内未得到审查，请随时 ping 审查员或 vLLM-Omni 团队。
  • 审查后，如果需要更改，审查员将在 PR 上添加 action-required 标签。贡献者应处理评论并 ping 审查员以重新审查 PR。
  • 请在合理的时间范围内回复所有评论。如果某条评论不清楚或您不同意某个建议，请随时请求澄清或讨论该建议。

额外资源

谢谢

最后，感谢您花时间阅读这些指南并对贡献 vLLM-Omni 感兴趣。您的所有贡献都将使 vLLM-Omni 成为一个对大家来说都很棒的工具和社区！