跳到內容

治理流程

vLLM 的成功得益於我們強大的開源社群。我們更傾向於非正式、基於貢獻的規範，而非正式的政策。本文件闡述了我們的治理理念和實踐。

價值觀

vLLM 旨在成為最快、最易用的 LLM 推理和推理引擎。我們緊跟技術進展，賦能創新，並支援多樣化的模型、模態和硬體。

設計價值觀

  1. 頂級效能：系統性能是我們的首要任務。我們監控開銷，最佳化核心，併發布基準測試。我們絕不犧牲效能。
  2. 易用性：vLLM 必須易於安裝、配置和操作。我們提供清晰的文件、快速的啟動、乾淨的日誌、有用的錯誤訊息和監控指南。許多使用者會 fork 我們的程式碼或深入研究，因此我們保持程式碼的可讀性和模組化。
  3. 廣泛覆蓋：vLLM 支援前沿模型和高效能加速器。我們使得新增新模型和硬體變得容易。vLLM + PyTorch 構成了一個簡單的介面，避免了複雜性。
  4. 生產就緒：vLLM 可在生產環境中 24/7 執行。它必須易於操作和監控健康狀況。
  5. 可擴充套件性：vLLM 是基礎的 LLM 基礎設施。我們的程式碼庫無法涵蓋所有用例，因此我們設計為易於 fork 和定製。

協作價值觀

  1. 緊密協作、快速推進：我們的維護者團隊在願景、理念和路線圖上保持一致。我們緊密合作，互相支援，並快速推進。
  2. 個人貢獻：沒有人可以透過金錢獲得治理權。提交者身份屬於個人，而非公司。我們獎勵貢獻、維護和專案管理。

專案維護者

維護者根據持續的高質量貢獻和與我們設計理念的一致性形成層級。

核心維護者

核心維護者相當於專案規劃和決策委員會。在其他約定中，他們可能被稱為技術指導委員會（TSC）。在 vLLM 的術語中，他們通常被稱為“專案負責人”。他們每週開會協調路線圖優先順序並分配工程資源。當前活躍的負責人：@WoosukKwon, @zhuohan123, @simon-mo, @youkaichao, @robertshaw2-redhat, @tlrmchlsmth, @mgoin, @njhill, @ywang96, @houseroad, @yeqcharlotte, @ApostaC

核心維護者的職責包括

  • 制定季度路線圖並負責各項開發工作。
  • 對 vLLM 和 vLLM 專案的技術方向或範圍進行重大更改。
  • 定義專案的釋出策略。
  • 與模型提供商、硬體供應商和 vLLM 的關鍵使用者合作，確保專案走在正確的軌道上。

首席維護者

雖然核心維護者承擔專案的日常職責，但首席維護者負責專案的整體方向和戰略。由 @WoosukKwon, @zhuohan123, @simon-mo 和 @youkaichao 組成的委員會目前分工承擔此角色。

首席維護者的職責包括

  • 在核心維護者之間無法達成共識時做出決定。
  • 採納對專案技術治理的更改。
  • 組織新提交者的投票流程。

提交者和領域負責人

提交者擁有寫入許可權和合並許可權。他們通常在特定領域擁有深厚的專業知識，並幫助社群。

提交者的職責包括

  • 審查 PR 並提供反饋。
  • 處理社群的 issue 和問題。
  • 負責程式碼庫和開發工作的特定領域：審查 PR，處理 issue，回答問題，改進文件。

特別地，提交者幾乎都是領域負責人。他們負責編寫子系統，審查 PR，重構程式碼，監控測試，並確保與其他領域的相容性。所有領域負責人都是在該領域具有深厚專業知識的提交者，但並非所有提交者都負責領域。

有關提交者及其各自領域的完整列表，請參閱 提交者 頁面。

提名流程

任何提交者都可以透過我們的私人郵件列表提名候選人。

  1. 提名：任何提交者都可以透過電子郵件向私人維護者列表提名候選人，並提供與現有標準相匹配的證據，包括 PR、評審、RFC、issue、基準測試和採用證據的連結。
  2. 投票：首席維護者將彙總支援或擔憂的意見。共同的擔憂可以停止該流程。投票通常持續 3 個工作日。對於擔憂，提交者共同討論再次提名該人士的明確標準。首席維護者將做出最終決定。
  3. 確認：首席維護者傳送邀請，更新 CODEOWNERS，分配許可權，新增到通訊渠道（郵件列表和 Slack）。

提交者身份具有高度選擇性和基於貢獻的原則。選擇標準要求

  • 領域專業知識：領導核心子系統的設計/實現，帶來專案範圍內的重要效能或可靠性改進，或接受了影響技術方向的 RFC。
  • 持續貢獻：跨版本的高質量合併貢獻和評審，對反饋的響應速度，以及對程式碼健康的維護。
  • 社群領導力：指導貢獻者，分類 issue，改進文件，並提升專案標準。

為了進一步說明，一名提交者通常滿足以下至少兩個成就模式

  • 接受的 RFC 或重大影響專案方向的設計的作者
  • 在核心路徑中可衡量的、被廣泛採用的效能或可靠性改進
  • 子系統的長期所有權，具有可證明的質量和穩定性提升
  • 重要的跨專案相容性或生態系統賦能工作（模型、硬體、工具）

雖然沒有量化標準，但過去的提交者

  • 提交了大約 30 多個高質量、有意義的 PR
  • 對大約 10 多個外部貢獻者的重要 PR 進行了高質量的評審
  • 在 issue/論壇/Slack 中處理了來自社群的多個 issue 和問題
  • 領導了集中於 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- 頻道用於圍繞特定主題的討論和協調。

專案維護者團隊還使用一個私人頻道進行高頻寬協作。

會議

我們每週舉行貢獻者同步會議，進行關於進展、障礙和計劃的站會式更新。您可以參考 standup.vllm.ai 上的筆記以獲取加入說明。