为 vLLM 贡献力量#
感谢您有兴趣为 vLLM 做出贡献！我们的社区对所有人开放，欢迎各种贡献，无论大小。您可以通过以下几种方式为项目做出贡献
识别并报告任何问题或错误。
请求或添加对新模型的支持。
建议或实现新功能。
改进文档或贡献操作指南。
我们也相信社区支持的力量；因此，回答问题、提供 PR 审查和帮助他人也是备受推崇和有益的贡献。
最后，支持我们最有影响力的途径之一是提高对 vLLM 的认识。在您的博客文章中谈论它，并强调它如何推动您的出色项目。如果您正在使用 vLLM，请在社交媒体上表达您的支持，或者只是通过为我们的仓库加星标来表达您的赞赏！
招聘版#
不确定从哪里开始？查看以下链接，了解要处理的任务
许可证#
请参阅 LICENSE。
开发#
根据您想要进行的开发类型（例如 Python、CUDA），您可以选择编译或不编译 vLLM 进行构建。查看 从源代码构建 文档以了解详细信息。
测试#
pip install -r requirements/dev.txt
# Linting, formatting and static type checking
pre-commit install --hook-type pre-commit --hook-type commit-msg
# You can manually run pre-commit with
pre-commit run --all-files
# Unit tests
pytest tests/
提示
由于 docker/Dockerfile 附带 Python 3.12，因此 CI 中的所有测试（mypy 除外）均使用 Python 3.12 运行。
因此，我们建议使用 Python 3.12 进行开发，以最大限度地减少本地环境与我们的 CI 环境冲突的可能性。
注意
目前，仓库尚未完全通过 mypy 检查。
问题#
如果您遇到错误或有功能请求，请先搜索现有问题，看看是否已被报告。 如果没有，请提交新问题，并提供尽可能多的相关信息。
重要提示
如果您发现安全漏洞，请按照此处的说明进行操作。
拉取请求 & 代码审查#
感谢您为 vLLM 做出贡献！在提交拉取请求之前，请确保 PR 符合以下标准。 这有助于 vLLM 维护代码质量并提高审查过程的效率。
DCO 和 Signed-off-by#
当为此项目贡献更改时，您必须同意 DCO。 提交必须包含 Signed-off-by: 标头，以证明同意 DCO 的条款。
将 -s 与 git commit 一起使用将自动添加此标头。
PR 标题和分类#
只有特定类型的 PR 会被审查。 PR 标题会添加适当的前缀以指示更改类型。 请使用以下其中一项
[Bugfix]用于错误修复。[CI/Build]用于构建或持续集成改进。[Doc]用于文档修复和改进。[Model]用于添加新模型或改进现有模型。 模型名称应出现在标题中。[Frontend]用于 vLLM 前端的更改（例如，OpenAI API 服务器、LLM类等）[Kernel]用于影响 CUDA 内核或其他计算内核的更改。[Core]用于核心 vLLM 逻辑的更改（例如，LLMEngine、AsyncLLMEngine、Scheduler等）[Hardware][Vendor]用于特定于硬件的更改。 供应商名称应出现在前缀中（例如，[Hardware][AMD]）。[Misc]用于不属于上述类别的 PR。 请谨慎使用。
注意
如果 PR 跨越多个类别，请包含所有相关前缀。
代码质量#
PR 需要满足以下代码质量标准
我们遵守 Google Python 风格指南 和 Google C++ 风格指南。
通过所有代码检查工具检查。 请使用
pre-commit格式化您的代码。 如果您不熟悉pre-commit，请参阅 https://pre-commit.git-scm.cn/#usage。代码需要有良好的文档记录，以确保未来的贡献者可以轻松理解代码。
包含足够的测试，以确保项目的正确性和健壮性。 这包括单元测试和集成测试。
如果 PR 修改了 vLLM 的用户界面行为，请在
docs/source/中添加文档。 这有助于 vLLM 用户理解和使用新功能或更改。
添加或更改内核#
每个自定义内核都需要一个模式和一个或多个实现才能在 PyTorch 中注册。
确保自定义操作按照 PyTorch 指南注册：自定义 C++ 和 CUDA 运算符 和 自定义运算符手册。
返回
Tensors的自定义操作需要元函数。 元函数应在 Python 中实现和注册，以便可以自动处理动态维度。 有关元函数的描述，请参阅上述文档。使用 torch.library.opcheck() 测试任何已注册操作的函数注册和元函数。 有关示例，请参阅
tests/kernels。当更改现有操作的 C++ 签名时，必须更新模式以反映更改。
如果需要新的自定义类型，请参阅以下文档：PT2 中的自定义类支持。
大型更改注意事项#
请尽可能保持更改简洁。 对于主要的架构更改（>500 LOC，不包括 kernel/data/config/test），我们希望看到 GitHub 问题 (RFC) 讨论技术设计和理由。 否则，我们将使用 rfc-required 标记它，并且可能不会审查 PR。
对审查的期望#
vLLM 团队的目标是成为一个透明的审查机器。 我们希望使审查过程透明高效，并确保没有贡献者感到困惑或沮丧。 但是，vLLM 团队规模较小，因此我们需要优先考虑某些 PR 而不是其他 PR。 以下是您可以对审查过程的期望
PR 提交后，PR 将分配给审查员。 每个审查员将根据他们的专业知识和可用性选择 PR。
PR 分配后，审查员将每 2-3 天提供状态更新。 如果 PR 在 7 天内未被审查，请随时 ping 审查员或 vLLM 团队。
审查后，如果需要进行更改，审查员将在 PR 上贴上
action-required标签。 贡献者应解决评论并 ping 审查员以重新审查 PR。请在合理的时间范围内回复所有评论。 如果评论不清楚或者您不同意某个建议，请随时要求澄清或讨论该建议。
请注意，由于计算资源有限，并非所有 CI 检查都会执行。 当 PR 准备好合并或需要全面 CI 运行时，审查员将添加
ready标签到 PR。
谢谢#
最后，感谢您抽出时间阅读这些指南，并感谢您对为 vLLM 做出贡献的兴趣。 您的所有贡献都有助于使 vLLM 成为每个人的出色工具和社区！