跳到内容

治理流程

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

Values

vLLM 旨在成为最快、最易用的 LLM 推理和服务引擎。我们紧跟技术发展，赋能创新，并支持多样化的模型、模态和硬件。

设计理念

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

协作理念

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

项目维护者

维护者根据持续的、高质量的贡献以及与我们设计理念的一致性形成一个等级制度。

核心维护者

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

项目负责人

职责

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

首席维护者

核心维护者承担项目的日常职责，而首席维护者则负责项目的总体方向和战略。以下委员会目前分担这一职责

职责

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

提交者和领域负责人

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

职责

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

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

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

提交者提名流程

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

  1. 提名：提交者向提交者群组发送电子邮件以提名候选人，重点介绍候选人的贡献（例如，指向 PR、审查、RFC、问题、基准和采纳证据的链接）以及他们如何符合以下标准。
  2. 讨论和投票：提交者群组讨论提名，进行投票，并在需要时表达顾虑。共同的顾虑可能会中止流程。对于顾虑，群组会讨论明确的重新提名该人的标准。大多数情况下通过共识决定；在有争议的情况下，首席维护者解决冲突并做出决定。
  3. 反馈期：在两周的反馈期后（留出时间接收任何最终意见或顾虑），如果没有出现阻碍性顾虑，并且提名者与首席维护者小组确认继续推进（通过邮件列表或提交者 Slack 频道），提名者将向候选人发送邀请，要求他们提交 PR 以更新其代码所有权（例如，CODEOWNERS 和提交者列表）。
  4. 权限和入职：同时，首席维护者在 GitHub 中分配必要的权限，并将新成员添加到提交者邮件列表、仅限提交者的 Slack 频道以及其他适当的沟通渠道。
  5. 最终确定：一旦 CODEOWNERS/提交者 PR 准备就绪且权限到位，该 PR 将被合并，并欢迎新的提交者。

提交者身份的授予高度严格且基于贡献。选择标准要求：

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

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

  • 被接受的、实质性塑造项目方向的 RFC 或设计作者
  • 核心路径中可衡量、被广泛采纳的性能或可靠性改进
  • 对子系统的长期所有权，并带来可证实的质量和稳定性提升
  • 重要的跨项目兼容性或生态系统支持工作（模型、硬件、工具）

虽然没有量化门槛，但过去的提交者通常具备：

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

工作组

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

顾问委员会

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

流程

项目路线图

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

决策制定

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

代码合并

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

PR 至少需要一名提交者审查和批准。如果代码由 CODEOWNERS 覆盖，则 PR 应由 CODEOWNERS 审查。在代码微不足道或属于热修复的情况下，PR 可以由首席维护者直接合并。

如果 CI 未通过是由于与 PR 无关的故障，首席维护者可以使用“强制合并”选项合并 PR，该选项会覆盖 CI 检查。

AI辅助贡献

AI 工具可以加速开发，但贡献者对其提交的所有代码负全责。如同《开发者原创证书》（Developer Certificate of Origin），这项政策的核心是责任制：贡献者必须相信他们有权在 vLLM 的开源许可下提交其贡献，无论代码是如何创建的。

所有 AI 辅助的贡献必须符合与其他代码相同的质量、测试和审查标准。贡献者在提交之前必须审查并理解 AI 生成的代码——确保它是优质代码。

  • 请勿提交“纯代理”PR。人类提交者负责审查所有更改的行、端到端验证行为并运行相关测试。
  • 归属声明维护法律清晰度和社区信任。贡献者必须在拉取请求中披露 AI 协助，并用适当的尾行（例如 Co-authored-by:）标记提交。
  • 避免一次性的“忙碌工作”PR（单个拼写错误、孤立的样式清理、一个可变默认值修复等）。将机械性的清理工作打包到清晰、系统的范围内。

警告

这些主题已在 AGENTS.md 中为代理概述，其中包含如何自主实现它们的说明。

Slack

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

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

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

会议

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