Skip to content

治理流程

vLLM 的成功离不开我们强大的开源社区。我们更倾向于采用非正式的精英治理规范，而非正式的政策。本文档阐明了我们的治理理念和实践。

价值观

vLLM 致力于成为最快、最易用的 LLM 推理和服务引擎。我们紧跟技术进展，推动创新，并支持多样化的模型、模态和硬件。

设计价值观

  1. 顶级性能：系统性能是我们的首要任务。我们监控开销、优化内核并发布基准测试。我们绝不放过任何性能提升的机会。
  2. 易于使用：vLLM 必须易于安装、配置和操作。我们提供清晰的文档、快速启动、干净的日志、有用的错误消息和监控指南。许多用户会分叉我们的代码或深入研究，因此我们保持代码的可读性和模块化。
  3. 广泛覆盖：vLLM 支持前沿模型和高性能加速器。我们让添加新模型和硬件变得简单。vLLM + PyTorch 提供了一个简单的接口，避免了复杂性。
  4. 生产就绪：vLLM 可在生产环境中 24/7 运行。它必须易于操作和监控，以便及时发现健康问题。
  5. 可扩展性：vLLM 是基础 LLM 基础设施。我们的代码库无法覆盖所有用例，因此我们设计为易于分叉和定制。

协作价值观

  1. 紧密协作且快速推进：我们的维护者团队在愿景、理念和路线图上保持一致。我们紧密合作，互相支持，快速推进。
  2. 个人贡献：没有人可以通过购买方式进入治理层。提交者身份属于个人，而非公司。我们奖励贡献、维护和项目管理工作。

项目维护者

维护者根据持续的高质量贡献以及与我们的设计哲学的一致性形成层级结构。

核心维护者

核心维护者类似于项目规划和决策委员会。在其他惯例中，他们可能被称为技术指导委员会 (TSC)。在 vLLM 的术语中，他们通常被称为“项目负责人”。他们每周开会，协调路线图优先级并分配工程资源。

项目负责人：

职责：

  • 制定季度路线图，并负责每项开发工作。
  • 对 vLLM 和 vLLM 项目的技术方向或范围进行重大更改。
  • 定义项目的发布策略。
  • 与模型提供商、硬件供应商和 vLLM 的关键用户合作，确保项目走在正确的轨道上。

首席维护者

虽然核心维护者承担项目的日常职责，但首席维护者负责项目的整体方向和战略。以下委员会目前分担这一角色，并各有分工：

职责：

  • 在核心维护者无法达成共识时做出决策。
  • 采纳对项目技术治理的更改。
  • 组织新提交者的投票流程。

提交者和领域负责人

提交者拥有写入权限和合并权限。他们通常在特定领域拥有深厚的专业知识，并帮助社区。

职责：

  • 审查 PR 并提供反馈。
  • 解决社区的问题和疑问。
  • 负责代码库和开发工作的特定领域：审查 PR、解决问题、回答问题、改进文档。

特别说明，提交者几乎都是领域负责人。他们编写子系统、审查 PR、重构代码、监控测试，并确保与其他领域的兼容性。所有领域负责人都是在特定领域拥有深厚专业知识的提交者，但并非所有提交者都负责领域。

有关提交者及其各自领域的完整列表，请参阅提交者页面。

提名流程

任何提交者都可以通过我们的私人邮件列表提名候选人：

  1. 提名：任何提交者都可以通过电子邮件向私人维护者列表提名候选人，并引用与现有标准相对应的证据，包括 PR、审查、RFC、问题、基准测试和采用证据的链接。
  2. 投票：首席维护者将汇总支持或担忧的意见。共同的担忧可能会阻止流程。投票通常持续 3 个工作日。对于有担忧的情况，提交者将讨论该人再次提名的明确标准。首席维护者将做出最终决定。
  3. 确认：首席维护者发送邀请、更新 CODEOWNERS、分配权限、添加到通信渠道（邮件列表和 Slack）。

提交者身份是高度选择性的，基于贡献。选择标准要求：

  • 领域专业知识：主导核心子系统的设计/实现、项目范围内采用的重大性能或可靠性改进，或塑造技术方向的已接受 RFC。
  • 持续贡献：跨版本的高质量合并贡献和审查、对反馈的响应能力以及对代码健康的维护。
  • 社区领导：指导贡献者、分类问题、改进文档以及提升项目标准。

为了进一步说明，提交者通常至少满足以下两项成就模式：

  • 撰写了已接受的 RFC 或设计，对项目方向产生了实质性影响
  • 在核心路径中实现了可衡量且被广泛采用的性能或可靠性改进
  • 长期负责一个子系统，并展示了质量和稳定性的提升
  • 在跨项目兼容性或生态系统支持方面（模型、硬件、工具）做出了重大贡献

虽然没有明确的量化标准，但过去的提交者通常：

  • 提交了大约 30+ 个具有实质性质量和范围的 PR
  • 对大约 10+ 个外部贡献者的实质性 PR 提供了高质量的审查
  • 在问题/论坛/Slack 中解决了社区的多个问题和疑问
  • 领导了 RFC 及其实现的集中工作，或项目范围内采用的显著性能或可靠性改进

工作组

vLLM 运行非正式的工作组，例如 CI、CI 基础设施、torch compile 和启动 UX。这些工作组可以通过 vLLM Slack 中的 #sig-（或 #feat-）频道进行松散跟踪。一些小组有定期的同步会议。

顾问委员会

vLLM 项目负责人会与一个由模型提供商、硬件供应商和生态系统合作伙伴组成的非正式顾问委员会进行磋商。这体现在 Slack 中的协作渠道和频繁的沟通中。

流程

项目路线图

项目负责人以 GitHub 问题形式发布季度路线图。这些路线图阐明了当前的优先级。未列入路线图的主题不会被排除，但可能会得到较少的审查关注。请参阅 https://roadmap.vllm.ai/。

决策制定

我们在 Slack 和 GitHub 中使用 RFC 和设计文档做出技术决策。讨论可能在其他地方进行，但我们保留重大更改的公开记录：问题陈述、基本原理和考虑过的替代方案。

合并代码

贡献者和维护者通常在代码变更方面密切协作，尤其是在组织内部或特定领域。维护者应根据变更的重要性为他人提供适当的审查机会。

PR 需要至少一名提交者进行审查和批准。如果代码受 CODEOWNERS 管理，则 PR 应由 CODEOWNERS 进行审查。在某些情况下，如果代码是微不足道的或属于紧急修复（hotfix），则可由首席维护者直接合并。

如果 CI 未通过，但失败与 PR 无关，首席维护者可以使用“强制合并”选项来覆盖 CI 检查并合并 PR。

Slack

鼓励贡献者加入 #pr-reviews 和 #contributors 频道。

还有 #sig- 和 #feat- 频道，用于围绕特定主题进行讨论和协调。

项目维护者小组还使用一个私密频道进行高带宽协作。

会议

我们每周举行一次贡献者同步会议，以站会形式更新进展、障碍和计划。您可以参考 standup.vllm.ai 上的说明加入会议。