貢獻程式碼
提交 PR 前的檢查清單
以下是提交至 LiteLLM 的任何 PR 之核心需求：
- 簽署 Contributor License Agreement (CLA)
- 將範圍維持在盡可能獨立的範圍內 — 您的變更每次應只處理一個特定問題
- 遵循 Commit and Branch Conventions — PR 標題會受到 CI 把關
Proxy（後端）PR
- 新增測試 — 至少 1 個測試是硬性要求（詳細資訊）
- 確保您的 PR 通過：
- Unit Tests —
make test-unit - Formatting / Linting Tests —
make lint
- Unit Tests —
UI PR
- 確保 UI 能成功建置 —
npm run build - 確保所有 UI 單元測試都通過 —
npm run test - 如果您要新增新元件或新邏輯，請加入對應測試
貢獻者授權協議（CLA）
在向 LiteLLM 提交程式碼之前，您必須先簽署我們的 Contributor License Agreement (CLA)。這是所有貢獻要合併到主儲存庫的法律要求。CLA 透過清楚定義您貢獻內容的提供條款，來同時保護您與本專案。
重要： 我們強烈建議您在開始進行貢獻之前就先簽署 CLA，以避免審查流程延誤。您可以在這裡找到並簽署 CLA。
Commit 與分支慣例
LiteLLM 強制執行兩項社群規範：
- Commits 遵循 Conventional Commits 1.0.0 —
<type>(<scope>)!: <description> - Branches 遵循 Conventional Branches —
<type>/<description>
強制執行發生在兩個地方：.githooks/ 中可選用的本機 git hooks，以及 PR 標題上的必要 CI 檢查（因為 squash-merge 會使用 PR 標題作為 commit subject）。
Commit 訊息格式
<type>(<optional scope>)!: <description>
<optional body>
<optional footer>
<type>為以下之一：feat、fix、docs、style、refactor、perf、test、build、ci、chore、revert。<scope>是可選的且為小寫。!在:之前表示破壞性變更。<description>為必填，且必須以小寫字母開頭（數字與符號也可以；只有A–Z會被拒絕）。
範例：
feat(router): add weighted round-robin strategy
fix(bedrock): decouple STS region from aws_region_name
chore(deps): bump black to 26.3.1
refactor!: drop Python 3.8 support
PR 標題必須遵循相同格式 — squash-merge 會使用 PR 標題作為 commit subject，而 Conventional PR Title 工作流程會進行驗證。
分支命名
格式：<type>/<short-description>，其中 <type> 是 feature、bugfix、hotfix、release、chore 其中之一。
feature/weighted-round-robin
bugfix/streaming-empty-chunks
chore/bump-black
hotfix/auth-bypass
release/v1.45.0
永遠允許的分支（pre-push hook 會略過它們）：
mainlitellm_internal_stagingdependabot/*gh-readonly-queue/*
Tag push 與分支刪除也會被略過。
安裝 hooks
這些 hooks 位於 .githooks/，且為 opt-in。每個 clone 只需執行一次：
make install-hooks
這會為本機儲存庫設定 core.hooksPath=.githooks。之後：
git commit會執行commit-msg，用來驗證 subject line。git push會執行pre-push，用來驗證分支名稱。
在極少數緊急情況下，您可以針對每個指令略過任一 hook：
git commit --no-verify -m "..."
git push --no-verify
解除安裝：git config --unset core.hooksPath。
Proxy（後端）
1. 建立您的本機開發環境
步驟 1：複製 repo
git clone https://github.com/BerriAI/litellm.git
步驟 2：安裝開發相依套件
uv sync --group dev --extra proxy
2. 新增測試
- 將測試加入
tests/test_litellm/目錄。 - 此目錄與
litellm/目錄 1:1 對應，且應只包含 mocked tests。 - 請勿在此目錄中加入真實的 LLM API 請求。
tests/test_litellm/ 的檔案命名慣例
測試目錄的結構與 litellm/ 相同：
test_{filename}.py對應至litellm/{filename}.pylitellm/proxy/test_caching_routes.py對應至litellm/proxy/caching_routes.py
3. 執行單元測試
從 litellm 目錄的根目錄執行下列指令：
make test-unit
4. 執行 linting 測試
從 litellm 目錄的根目錄執行下列指令：
make lint
LiteLLM 使用 mypy 進行型別檢查。CI/CD 也會執行 black 進行格式化。
5. 提交 PR
- 將您的變更推送到 GitHub 上的 fork
- 從您的 fork 開啟 Pull Request
UI
1. 建立您的本機開發環境
步驟 1：複製 repo
git clone https://github.com/BerriAI/litellm.git
步驟 2：前往 UI 儀表板目錄
cd ui/litellm-dashboard
步驟 3：安裝相依套件
npm install
步驟 4：啟動開發伺服器
npm run dev
2. 新增測試
如果您要新增新元件或新邏輯，您必須新增對應的測試。
3. 執行 UI 單元測試
npm run test
4. 建置 UI
在提交您的 PR 之前，請確保 UI 可成功建置：
npm run build
5. 提交 PR
- 將您的變更推送到您在 GitHub 的 fork
- 從您的 fork 開啟 Pull Request
進階
建置 LiteLLM Docker 映像檔
如果您想自行建置並執行 LiteLLM Docker image，請遵循這些指示。
步驟 1：複製 repo
git clone https://github.com/BerriAI/litellm.git
步驟 2：建置 Docker image
使用 Dockerfile.non_root 進行建置：
docker build -f docker/Dockerfile.non_root -t litellm_test_image .
步驟 3：執行 Docker image
請確認 config.yaml 存在於根目錄中。這是您的 LiteLLM proxy 設定檔。
docker run \
-v $(pwd)/proxy_config.yaml:/app/config.yaml \
-e DATABASE_URL="postgresql://xxxxxxxx" \
-e LITELLM_MASTER_KEY="sk-1234" \
-p 4000:4000 \
litellm_test_image \
--config /app/config.yaml --detailed_debug
在本機執行 LiteLLM Proxy
- 前往
proxy/目錄：
cd litellm/litellm/proxy
- 執行 proxy：
python3 proxy_cli.py --config /path/to/config.yaml
# RUNNING on http://0.0.0.0:4000