FastAPI 演進史（下）：付費團隊、FastAPI Cloud 與 vLLM

上篇回顧了 FastAPI 誕生至成熟的技術演進；下篇則要探討一個更具張力的核心課題：當一個開源專案成長為十萬星的全球基礎設施，它背負了哪些治理與架構代價？

2026 年 9 月的 FastAPI，在 GitHub 上突破 102,000 顆星，並在 JetBrains Python 開發者調查中以 38% 的使用率穩居第一；同時，它也是 vLLM 等大型語言模型（LLM）推論伺服器預設的 HTTP 服務層。

但在破紀錄的採用數字下，FastAPI 始終未發布 1.0 正式版、長期由創辦人一人高度集中決策，且近年成立了商業公司並在預設安裝中捆綁自家雲端服務。

下篇將依序檢視治理演變、商業化捆綁、競品定位、效能宣傳落差與 AI 時代的新角色，並為維運團隊整理具體的版本與架構指引。

治理與單一維護者風險：從個人把關到付費團隊

FastAPI 從第一天起就是 Sebastián Ramírez（tiangolo）一人主導的專案。這項事實具體呈現在專案的歷史資料中。

截至 2026 年 9 月的統計，在 FastAPI 儲存庫共 3,709 筆人類 commit 中，tiangolo 一人就貢獻了 2,258 筆，佔比高達 60.9%；前五名貢獻者合計佔比達 68.0%。

專案在 GitHub 上的 Open Issue 數量長期維持在極低水位（常態僅個位數），原因在於社群問答與功能提議很早就全面移往 GitHub Discussions。這項專案管理策略雖維持了 Issue 列表的整潔，但也將社群的焦慮轉移到了討論區。

2021 至 2022 年：社群瓶頸與作者自白

2021 年底，社群對開發進度停滯的不滿集中爆發。2021 年 10 月 1 日，開發者在 GitHub Discussions 發起〈對 FastAPI 緩慢的開發感到沮喪〉，直言大量 Pull Request（PR）長期未獲回應：

「感謝你所做的一切 @tiangolo，但你應該找更多維護者來幫忙。拜託！」（Thanks a lot for what you did @tiangolo but you should find additional mainteners to help. Please!）

同年 12 月 8 日，另一位開發者開立 Issue #4263〈為 FastAPI 尋找維護者〉，建議仿效 Flask 與 Django 的多維護者機制。該討論累積了 87 個表情反應與 36 則留言，延宕至 2023 年 2 月才正式關閉。

面對社群對審查速度緩慢的質疑，tiangolo 於 2022 年 1 月 7 日發表長篇回覆，完整闡述了他的品質哲學與維護底線：

「FastAPI 能成功的一個重要原因，是我親自、非常仔細地處理了所有事情，盡我所能做到最好。我現在不能放棄這一點，至少還不能，否則會冒著程式碼品質的風險。」

他解釋，絕大多數 PR 都需要經過他大幅修改才能達到品質標準，有時重新實作反而比審查更快；但他仍選擇保留原 PR 逐步修改，因而拖慢了吞吐量。他在品質一致性與合併速度之間，明確選擇了前者。

2026 年：付費核心團隊與合併權力結構

轉捩點發生在商業化注資之後。官方 FastAPI People 頁面已正式列出 7 人核心團隊（tiangolo、YuriiMotov、svlandeg、alejsdev、patrick91、luzzodev 與 Kludex），並註明「大部分維護工作由付費團隊成員執行」。

 PR Processing Times (2025–2026)

 +-----------------------+
 | Team PRs (87.3%)      |  Median: 1.0 hour
 +-----------------------+
 +-----------------------+
 | Community PRs (12.7%) |  Median: 327.6 hours (~13.7 days)
 +-----------------------+

 Source: Merged PR data over 12 months (fastapi/fastapi)

其中 Starlette 的主要維護者 Kludex 正式加入團隊，且 Starlette 官方儲存庫已移轉至 Kludex/starlette。FastAPI 最核心的底層依賴，其主要維護者如今就是 FastAPI 團隊的一員，上篇提到「地基由別人打」的風險因此降低。

截至 2026 年 9 月，過去 12 個月的 PR 合併統計顯示出清晰的治理變遷：團隊內部 PR 從開啟到合併的中位數僅需 1.0 小時，開啟中的 PR 降至 79 個；但 87.3% 的合併 PR 來自付費團隊成員，且 tiangolo 本人依然親自合併了超過 56% 的 PR。

這意味著「單一維護者風險」在 2026 年換了形式：它不再是創辦人個人的時間瓶頸，而是轉移為商業公司的營運狀況與財務續航力。

永遠的 0.x：ZeroVer 的彈性與維運成本

FastAPI 歷經八年演進，版本號依然停留在 0.x 系列。官方在〈關於 FastAPI 版本〉文件中明確指出：遵循語意化版本慣例，每個次版號（Minor Version，如 0.115 至 0.116）都可能包含破壞性變更（Breaking Changes），僅有修訂號（Patch Version）保證相容。

這種版本策略被社群稱為 ZeroVer（主版本號永遠為 0）。對作者而言，這保留了隨時重構架構的自由度，例如在 0.112.0 移除預設依賴、在 0.126.0 放下 Pydantic v1 支援，在語意化版本下都不必等到 2.0。

但對維運團隊而言，這等於作者將彈性留給自己，而將每次升級都必須完整回歸測試的成本轉嫁給使用者。

例如推論引擎 vLLM 的依賴定義檔中，即明確設定了狹窄的版本區間：

 fastapi[standard] >= 0.133.0, < 0.137.0

其註解特別載明：0.133.0 是支援 Starlette 1.0 的最低版本，而上限設在 < 0.137.0，則是為了避開一次內部路由樹的特定調整——該調整會破壞模型託管容器標準（Model Hosting Container Standards）的處理器覆寫機制。

商業化：FastAPI Cloud 與創投注入

開源專案長期仰賴個人無償投入或贊助平台，難以維持全職維護團隊。FastAPI 的轉捩點始於創投資金的注入。

從 Sequoia Fellowship 到 FastAPI Labs

2023 年，Sebastián Ramírez 獲選為紅杉資本（Sequoia Capital）首位「開源獎助計畫」（Open Source Fellowship）學者。2025 年 5 月 5 日，Sequoia 正式宣布領投 FastAPI Labs 的種子輪融資，由 Ramírez 創立並擔任 CEO，核心商業產品為 FastAPI Cloud。

Sequoia 在投資聲明中列舉了 BMW、美國運通（American Express）、Roche 與 NASA 太空望遠鏡科學研究所等跨國企業採用案例，指出雖然 FastAPI 大幅簡化了 API 開發，但應用程式的雲端部署與維運依然是開發者的主要障礙。

Ramírez 在社群平台 X 上感性寫道，自己小時候就注意到最好的科技公司都由 Sequoia 支持，「沒想到自己有一天也能建立一家獲得 Sequoia 支持的公司」。

這條商業化路徑，幾乎完全複製了核心依賴 Pydantic 的劇本。2023 年 2 月，Pydantic 創辦人 Samuel Colvin 成立 Pydantic Services 並獲 Sequoia 領投 470 萬美元種子輪。兩大緊密相依的開源核心，在兩年內先後轉型為由同一家創投支持的商業實體。

CLI 捆綁與預設依賴的爭議

商業化對使用者最直接的影響，體現在框架預設安裝包的改動。

自 0.116.0（2025 年 7 月）起，安裝官方推薦的 fastapi[standard] 會自動包含 fastapi-cloud-cli，在終端機中提供 fastapi deploy 一鍵部署指令。若不希望在環境中安裝商業 CLI 工具，開發者必須顯式指定：

pip install "fastapi[standard-no-fastapi-cloud-cli]"

官方首頁亦將 FastAPI Cloud 列為專案的「主要資金提供者與贊助商」。

FastAPI 目前維持寬鬆的 MIT 開源授權，也沒有任何改變授權的跡象；但在開源界頻繁發生授權變更（如 HashiCorp 將 Terraform 改為 BSL，即商業原始碼授權）的背景下，開源核心與商業雲端服務的邊界劃分，已成為維運架構師持續關注的焦點。

競品版圖：各自在解決 FastAPI 的什麼痛點？

FastAPI 建立的「型別提示 + 裝飾器路由 + 自動 OpenAPI」典範，成為後續現代 Python 框架的共同標準配備。但隨之湧現的競爭框架，各自切中了 FastAPI 的特定架構痛點。

          Python Modern Web Frameworks

 +-----------------------------------------------------+
 |                       FastAPI                       |
 |       Type-Driven API King (ASGI / Starlette)       |
 +-----------------------------------------------------+
       |                   |                   |
       v                   v                   v
 +-------------+     +-------------+     +-------------+
 | Litestar    |     | DjangoNinja |     | Robyn/Other |
 | Multi-Gov   |     | Django ORM  |     | Rust Core   |
 | Unbound Val |     | & Admin     |     | Multi-Core  |
 +-------------+     +-------------+     +-------------+

1. Litestar：擺脫單一依賴與委員會治理

Litestar 原名 Starlite，於 2021 年 12 月 6 日在 PyPI 發布首個版本，恰好發生在社群開立 Issue #4263 尋求維護者的前兩天。2023 年發布 2.0 版並更名，完全重寫脫離對 Starlette 的依賴。

Litestar 主要針對兩大痛點：

• 解耦資料驗證：不強制綁定 Pydantic，原生支援 msgspec、attrs、標準函式庫 dataclasses 與 TypedDict，並允許 Pydantic v1 與 v2 在同一個專案中並存。
• 架構擴充性：提供不綁定 App 物件的獨立函式路由註冊機制，根除大型專案常見的循環匯入（Circular Import）難題。

2. Django Ninja：守護 Django 既有資產

Django Ninja 首頁開宗明義致謝：「本專案深受 Sebastián Ramírez 開發的 FastAPI 啟發」。

它解決的核心痛點在於企業遷移成本：許多團隊已有龐大的 Django 專案，無需拋棄成熟的 Django ORM、資料庫遷移工具與 Admin 管理後台，就能獲得媲美 FastAPI 的型別驗證與自動 API 文件體驗。

3. WSGI 轉型與非同步效能派（Flask / Robyn）

面對 ASGI 浪潮，傳統框架與新興語言橋接框架亦提出各自解答：

• Flask 2.0+：雖加入 async def 支援，但底層仍為 WSGI 架構，每個請求依然佔用一個 Worker 行程。官方文件坦言此設計無法提升並行（Concurrency）吞吐量，並建議高非同步需求改用 Quart。
• Robyn：底層採用 Rust 打造非同步事件循環，主打極致的高吞吐量與多核擴充，直接回應社群對 Python 執行效能的苛求。

這些競品各自在單點上突破，但尚無一者能撼動 FastAPI 由完整文件、龐大社群與先行者累積建立的生態壁壘。

效能宣傳與工程現實：行銷詞彙與真實瓶頸

FastAPI 官方首頁最著名的宣傳標語之一，莫過於：

「快速：非常高的效能，與 NodeJS 和 Go 同級（感謝 Starlette 和 Pydantic）。最快的 Python 框架之一。」

「與 Go 同級」的論戰與基準測試局限

這句行銷標語自 2020 年起便在社群引發激烈討論。

在 GitHub Discussion #7320 中，開發者引用 TechEmpower（HTTP 框架效能評測專案）基準測試資料指出：純文字輸出測試下，Go 的 fasthttp 可達每秒近 600 萬次請求，Node.js 約 88 萬次，而 FastAPI 約為 16 萬次；相較於 Go 的基準，FastAPI 吞吐量僅有不到 3%，質疑兩者根本不在同一個量級。

FastAPI 在官方〈基準測試〉文件中給出理性說明：Uvicorn 是最精簡的伺服器層，Starlette 次之，封裝了完整驗證與序列化邏輯的 FastAPI 自然最具運算開銷。評估效能時，應與同樣提供資料驗證與 OpenAPI 生成的框架（如 NestJS）比較，而非純粹的 HTTP 轉發器。

隨著歷史悠久的 TechEmpower 儲存庫於 2026 年 3 月宣告封存，第三方通用基準測試的參考價值逐漸淡出，工程焦點轉向應用層的實務瓶頸。

生產環境的三大實質效能瓶頸

在實際後端維運中，框架本身的微秒級開銷很少成為瓶頸。最常導致效能雪崩的往往是以下三點：

1. 在 async def 中執行同步阻塞 I/O：FastAPI 的排程機制為：一般 def 路由會派發至外部執行緒池（Thread Pool）執行，避免阻塞主迴圈；但 async def 路由會直接在主事件迴圈執行。若在非同步路由內呼叫同步資料庫驅動程式或 requests，將徹底凍結事件迴圈，導致全伺服器並行崩潰。
2. I/O 延遲掩蓋驗證優勢：0.100.0 版本說明指出，真實應用的主要延遲來自資料庫查詢與第三方網路請求。即使 Pydantic v2 核心驗證速度提升 20 倍，反映至端到端（End-to-End）API 回應時間通常僅有 2 至 3 倍提升。
3. JSON 序列化開銷：在 0.126.0 卸下相容 Pydantic v1 的歷史包袱後，FastAPI 自 0.130.0 起在路由具備 Pydantic 回應型別或回應模型時，改由 Pydantic Rust 核心直接序列化 JSON 回應，使 JSON 產出速度提升 2 倍以上；0.140.0 則進一步最佳化了依賴注入的記憶體配置。

AI 與 LLM 時代的新角色：推論介面與 MCP 工具樞紐

在生成式 AI 與大型語言模型爆發的浪潮中，FastAPI 意外成為最大的受益者之一。

JetBrains 調查與 The Register 報導顯示，FastAPI 使用率從 29% 跳升至 38%，被分析者 Michael Kennedy 稱為 Python Web 框架中「最大的贏家」。

同期 Python 社群湧入大量新手（50% 受訪者工作經驗不到兩年、39% 在近兩年內才接觸 Python），Kennedy 推測這些新手沒有 Flask 或 Django 的包袱，加上許多機器學習開發者需要把模型包裝成 API，自然選擇了最熱門的 FastAPI。

調查本身並未直接證明成長由 AI 帶動，但下列案例為這項推測提供了相當的支持。

                 AI Workload Integration

 +--------------------------------------------------------+
 |                 OpenAI Compatible API                  |
 |                    (vLLM API Server)                   |
 +--------------------------------------------------------+
                            |
                            | from fastapi import FastAPI
                            v
 +--------------------------------------------------------+
 | FastAPI App Core                                       |
 | - StreamingResponse (SSE)   - Lifespan (Model Loading) |
 | - Depends (Auth / Limits)   - OpenAPI JSON Schema      |
 +--------------------------------------------------------+
                            |
                            | fastapi-mcp Bridge
                            v
 +--------------------------------------------------------+
 |              Model Context Protocol (MCP)              |
 |          Expose Endpoints as LLM Agent Tools           |
 +--------------------------------------------------------+

1. 模型推論伺服器的標準 HTTP 門戶

以開源推論引擎 vLLM 為例，其 OpenAI 相容 API 伺服器直接 from fastapi import FastAPI，並以 lifespan 管理啟動與關閉。這代表許多團隊部署大型語言模型時，即使自己沒寫過一行 FastAPI，推論服務的最外層也是 FastAPI；前述 0.x 版號的升級風險，同樣落在他們身上。

FastAPI 的現代特性高度吻合 AI 推論情境需求：

• Lifespan 生命週期管理：於 0.93.0 引入，成為在服務啟動時載入幾十 GB 權重檔、關閉時精確釋放 GPU 記憶體的標準做法。
• 原生 SSE 串流支援：0.135.0 加入的 Server-Sent Events（SSE）機制與 0.118.0 的串流資源清理修復，為 LLM 逐字輸出（Token Streaming）提供了開箱即用的基礎。

2. 「型別即規格」在 MCP 工具呼叫中的天然優勢

由 Anthropic 推出的 Model Context Protocol（MCP），旨在讓 AI Agent 能安全呼叫外部工具。FastAPI 憑藉「強型別宣告自動生成 OpenAPI 規格」的設計，在 MCP 生態中佔據天然優勢。

社群開發的 fastapi-mcp 擴充套件，能將既有 FastAPI 路由一鍵轉換為符合 MCP 規範的 Agent 工具，並完整保留原有的 Depends 認證與授權機制。在 AI 時代，原本為前端工程師準備的 OpenAPI Schema，直接轉化為 AI 代理理解與呼叫外部工具的通用規格。

同時，FastAPI 官方亦主動擁抱 AI 生態（如 0.133.1 引入 Agents Skill、0.140.0 引入 Library Skills 讓 AI 助理更精準理解框架語法）。

然而 AI 也帶來維護負擔：FastAPI People 過去用以表揚社群貢獻者的排行榜，因大量 AI 產生的垃圾貢獻試圖操弄排名而停止更新，只作為致敬保留。專案越熱門，越容易成為自動產生 PR 的目標，審查成本最終落在維護者身上。

現況盤點與維運實務指南

歷經八年演進，FastAPI 已從個人的實驗專案，轉型為由創投資金挹注、付費團隊維護，且深度嵌入 AI 推論基礎設施的關鍵元件。

長期觀察的五大關鍵指標

1. 何時發布 1.0 版本：當付費團隊與商業實體就位，是否願意承諾長期語意化版本穩定度，是治理成熟度的終極指標。
2. FastAPI Cloud 的商業獲利能力：專案全職人力的規模，未來將直接由雲端業務的營收表現決定。
3. 預設安裝與文件的中立性：關注 fastapi[standard] 是否持續捆綁商業產品，以及部署文件是否保持通用開源立場。
4. Python 3.14 型別底層整合：隨著 PEP 649（將型別註記改為延遲求值的提案）成為 Python 語言預設，觀察底層型別解析在極端情境下的相容性。
5. AI 輔助開發下的開源維護：在面對大量 AI 產生的自動化 PR 衝擊時，開源社群如何建立高效的過濾與協作邊界。

生產環境維運實務建議

針對負責部署與管理 FastAPI 服務的維運與 DevOps 工程師，本文彙整五項關鍵實踐：

• 嚴格鎖定次版號區間：依官方建議，在 requirements.txt 或 pyproject.toml 中一律指定次版號範圍（如 fastapi[standard]>=0.133.0,<0.134.0），切勿讓安裝版本自由浮動。
• 明確宣告安裝 Extras：在 CI/CD 流程中明確選用所需的 extra（例如偏好乾淨環境可指定 fastapi[standard-no-fastapi-cloud-cli]），避免因預設套件變更導致容器打包異常。
• 嚴格靜態審查 async def 路由：在程式碼審查與 Linter 規則中加入檢查，嚴禁在非同步函式內直接呼叫同步 I/O 驅動。
• 容器維持單行程原則：在 Kubernetes 環境中部署時，一個 Pod 容器內維持單一 Uvicorn 工作行程，將負載平衡與水平擴充（HPA）完全委由 Kubernetes 叢集排程。
• 主動監控 Starlette 安全修補：FastAPI 的安全修補多數源自底層 Starlette，應將 Starlette 的 CVE 與安全性公告納入獨立的相容性追蹤清單。vLLM 的依賴檔就曾為了一個 Starlette 的 CVE 設定最低版本。

FastAPI 的故事，從一個不想寫框架的人開始，走到一家有創投支持的公司。它正在面對每個成功的開源專案遲早會遇到的問題：當一個專案大到成為基礎設施，誰來負責它，又該對誰負責。