跳到内容

治理流程

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

原则

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

设计原则

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

协作原则

  1. 紧密协作、快速迭代：我们的维护者团队在愿景、理念和路线图上保持一致。我们紧密合作，互相解除障碍，并快速推进。
  2. 个人贡献：无人可以通过金钱买入治理权。提交者身份属于个人，而非公司。我们奖励贡献、维护和项目管理。

项目维护者

维护者根据持续、高质量的贡献和对我们设计理念的认同，形成一个等级体系。

核心维护者

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

项目负责人

职责

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

首席维护者

虽然核心维护者承担项目的日常职责，但首席维护者负责项目的整体方向和战略。以下委员会目前分担此角色，责任划分明确。

职责

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

提交者和领域负责人

提交者拥有写访问权限和合并权限。他们通常在特定领域拥有深厚的专业知识，并为社区做出贡献。

职责

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

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

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

提名流程

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

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

提交者身份的选拔非常严格且基于贡献。

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

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

  • 被接受的 RFC 或设计的主要作者，该设计对项目方向产生了实质性影响
  • 在核心路径中实现了可衡量的、被广泛采用的性能或可靠性改进
  • 长期负责一个子系统，并展现出质量和稳定性的提升
  • 显著的跨项目兼容性或生态系统赋能工作（模型、硬件、工具）

虽然没有量化门槛，但过去提交者已经：

  • 提交了约 30 多个高质量、大范围的 PR。
  • 为约 10 多个外部贡献者的 PR 提供了高质量的审查。
  • 在 issues/forums/Slack 中解决了社区的多个问题和疑问。
  • 主导了关于 RFC 及其实现的集中式工作，或在项目范围内被采纳的显著性能或可靠性改进。

工作组

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

咨询委员会

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

流程

项目路线图

项目负责人发布季度路线图作为 GitHub issue。这些路线图阐明了当前的优先级。未列出的主题并非被排除在外，但可能会获得较少的审查关注。请参阅https://roadmap.vllm.ai/。

决策制定

我们在 Slack 和 GitHub 上使用 RFC 和设计文档来制定技术决策。讨论可能发生在其他地方，但我们保留了重大变更的公开记录：问题陈述、理由和考虑的替代方案。

代码合并

贡献者和维护者经常在代码更改上进行密切合作，尤其是在组织内部或特定领域。维护者应根据更改的重要性，给予他人适当的审查机会。

PR 需要至少一名提交者的审查和批准。如果代码由 CODEOWNERS 覆盖，则 PR 应由 CODEOWNERS 审查。对于一些微小更改或热修复，PR 可以由首席维护者直接合并。

在 CI 未能通过且与 PR 无关的情况下，PR 可以由首席维护者使用“强制合并”选项合并，该选项将覆盖 CI 检查。

Slack

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

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

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

会议

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