Gradio 使用者數突破 100 萬的歷程！
五年前，我們推出了 Gradio，這是一個簡單的 Python 庫，旨在讓斯坦福大學的研究人員能夠輕鬆地透過 Web 介面演示計算機視覺模型。
如今，Gradio 每月被超過 100 萬開發者用於構建和分享 AI Web 應用。這其中包括一些有史以來最受歡迎的開源專案，例如 Automatic1111、Oobabooga 的文字生成 WebUI、Dall-E Mini 和 LLaMA-Factory。
我們是如何走到這一步的？Gradio 是如何在競爭激烈的開源 Python 庫領域保持增長的？我經常收到那些正在構建自己的開源庫的人提出的這個問題。這篇文章總結了我過去幾年學到的一些經驗。
- 投資於良好的原語，而非高階抽象
- 將病毒式傳播直接嵌入到你的庫中
- 專注於一個（不斷增長的）利基市場
- 你唯一的路線圖應該是快速迭代
- 最大化使用者消費你庫輸出的方式
1. 投資於良好的原語，而非高階抽象
當我們最初推出 Gradio 時，我們只提供了一個高階類（gr.Interface），它可以從單個 Python 函式建立一個完整的 Web 應用。我們很快意識到開發者希望建立其他型別的應用（例如，多步驟工作流、聊天機器人、流媒體應用），但當我們開始列出使用者想要構建的應用時，我們意識到我們需要做什麼：向下探究。
我們沒有構建許多高階類來支援不同的用例，而是構建了一個名為 Gradio Blocks 的低階 API，它允許使用者從模組化元件、事件和佈局組裝應用程式。儘管使用起來通常需要更多工作，但今天的 gr.Blocks 佔據了 Gradio 80% 的使用量——包括上述高度流行的應用程式。
對於一個小型團隊來說，專注於低階抽象必然意味著我們無法追逐許多誘人的高階抽象。但這種專注使我們避免了兩個常見的陷阱：
定製-維護陷阱：高階抽象易於使用，但使用者會請求額外的引數來定製它們，這反過來導致維護負擔增加，因為每個抽象和引數都需要實現、維護和測試以避免錯誤。
生產力幻覺：使用高階抽象看起來工作量較少，直到使用者需要不支援的功能（這在專案開始時很難預測），迫使開發者進行代價高昂的重寫。
第一個問題浪費了我們作為 Gradio 維護者的時間，而第二個問題浪費了我們使用者的時間。直到今天，Gradio 只包含兩個高階抽象（gr.Interface 和 gr.ChatInterface），它們本身都是用 Blocks 構建的。
在 AI 輔助編碼時代，擁有良好原語的優勢更加顯著，我們發現 LLM 通常善於透過文件並利用原語構建複雜的應用程式（例如，看看所有用 three.js 構建的遊戲）。如果 AI 為你編寫程式碼，編寫低階程式碼並不會花費太多額外時間。
2. 將病毒式傳播直接嵌入到你的庫中
你的庫最好的“大使”不是你，而是一個熱心的使用者。因此，你應該找到方法讓使用者在他們的工作流程中分享你的庫或其產品。Gradio 的早期增長得益於我們的“分享連結”功能（它可以用一行程式碼為你的 Gradio 應用建立一個臨時公共連結）。Gradio 使用者無需擔心打包或在具有適當計算能力的 Web 伺服器上託管他們的程式碼，就可以立即與同事分享他們的應用。
加入 Hugging Face 後，我們還受益於成為 Hugging Face Spaces 的標準 UI——被機器學習研究社群廣泛使用。最受歡迎的 Spaces 吸引了數百萬訪客，使開發者接觸到 Gradio，他們反過來又分享和構建了自己的 Gradio 應用，並使用相同的 Spaces（其程式碼是公開的）作為學習如何使用 Gradio 的資源。
3. 為一個（不斷增長的）利基用例而構建
早期，我們面臨一個關鍵決定：Gradio 應該是一個通用 Python Web 框架，還是應該專注於構建機器學習 Web 應用？我們選擇了後者，這帶來了天壤之別。
在擁擠的 Python Web 庫生態系統中，我們經常被問到：“Gradio 與 X 有何不同？”我們簡潔的答案——Gradio 針對機器學習 Web 應用進行了最佳化——令人難忘且基本準確。每個 Gradio 應用都附帶特別適合 ML 工作流的功能，例如內建佇列，即使有數千併發使用者也能高效管理長時間執行的 ML 任務。我們設計的元件專門針對 ML 用例。另一方面，很長一段時間以來，Gradio 甚至不包含像連結按鈕這樣的功能，僅僅是因為我們的核心使用者從不需要它。透過縮小我們的關注點，Gradio 迅速成為機器學習開發者的首選——預設的“AI 使用者介面”。
當然，我們選擇了一個本身正在增長的利基市場，這讓我們受益匪淺。最近推動所有 AI 相關事物的逆風極大地幫助了我們，如果我們專注於資料科學或儀表板等領域，我們可能不會經歷同樣的增長。
4. 你唯一的路線圖應該是快速迭代
與其他一些庫不同，Gradio 不釋出路線圖。相反，我們跟蹤機器學習領域的新興趨勢並相應地釋出。在開源軟體（尤其是 AI）中，根據社群需求釋出功能（並棄用不再需要的功能）是持續增長的關鍵。作為一個具體的例子，在 Gradio 的早期版本中，我們構建了特定功能，允許開發者顯示其機器學習模型的“解釋”——因為這在 2020-21 年間是一個非常流行的用例。隨著對解釋的興趣減弱，我們棄用了此功能，並將精力投入到音訊/影片流和聊天相關功能中。
我們的內部流程也是去中心化的。Gradio 團隊的 11 名工程師和開發者倡導者都被鼓勵識別有影響力的想法，快速原型製作，並透過 GitHub、Hugging Face 和社交媒體直接與開源社群互動。每個團隊成員都會將這些想法帶回團隊，我們會不斷地圍繞哪些想法可能產生影響來建立和重建共識，因為我們會不斷地朝著最有影響力的方向發展。
5. 最大化使用者消費你庫輸出的方式
當你建立一個 Gradio 應用並“launch()”它時，你會在瀏覽器中得到一個 Web 應用。但這還不是全部——你還會得到每個 Python 函式的 API 端點，以及為每個端點自動生成的文件。這些端點可以透過我們團隊構建的 Python 或 JavaScript 客戶端消費，也可以直接使用 cURL。
我們這樣做是因為我們希望開發者使用 Gradio 的每一分鐘都儘可能有用。一個 Gradio 應用應該在本地執行或無需任何程式碼更改即可部署到 Hugging Face Spaces 或你自己的伺服器上，或者以程式設計方式整合到更大的應用程式中，甚至透過 MCPs 被 AI 代理利用（很快會詳細介紹！）。透過專注於最大化的可用性，我們希望開發者能夠繼續從 Gradio 庫中獲得越來越多的價值。
向 1000 萬用戶進發！
