實作相容OpenAI API，但背後不是OpenAI的API服務 / Implementing OpenAI API-Compatible Services, But Not Powered by OpenAI
我們上次談到了不是背後說用到OpenAI模型的API不見得能相容OpenAI API，那我們這次就來做個能夠相容於OpenAI API的服務，但只會回答「喵」的「喵型語言模型」。
Last time we talked about how not all APIs that claim to use OpenAI models are necessarily compatible with the OpenAI API. This time, let's create a service compatible with the OpenAI API, but it only responds with "Meow." We'll call it the "Meow Language Model."
系統架構 / System Architecture
整個架構會由五個元件所組成：
- Python程式碼：不管你傳送什麼資訊，它只會回「喵」。
- Dify：AI應用程式框架的Dify裡面，可以用Code節點讓我們執行這段Python程式碼，然後把它包裝成Chatflow API。
- dify2openai：fatwang2開發的dify2openai將Dify的API模擬成OpenAI API格式。
- Cloudflare Tunnel：將運作在本地的API服務連接到Cloudflare提供的臨時網址上。
- FastGPT：使用自製的OpenAI API。
程式碼 / Source Code
https://github.com/pulipulichen/practice-Dify-OpenAI-API-2025.git
相關程式碼放在「practice-Dify-OpenAI-API-2025」保存庫裡面。這些程式碼是以Linux作業系統為主要環境，需要搭配Docker才能運作。這些程式碼並非給普通使用者執行，而是給開發者作為參考的資料。如果環境設置正確的話，執行 startup.sh 就能完成整個設定。
以下概述整個系統中需要設定的關鍵部分。
1. Python: Dify裡面的聊天流 / Python: The Chatflow in Dify
首先，我們在Dify中建立一個Chatflow，用來實作「喵型語言模型」。你可以用我事先準備好的DSL檔案來建立。DSL檔案的下載網址如下：
https://pulipulichen.github.io/practice-Dify-OpenAI-API-2025/dify-dsl/Cat_LLM.yml
我們可以看到應用程式裡面的「Code」揭露了「喵型語言模型」的秘密。
2. Dify：API的發佈 / Dify: Publish API Service
我們從「Publish」保存建立好的聊天流(chatflow)。
從左邊的「Monitoring」找到Backend Service API的「API Key」按鈕。
按下「Create new Secret key」，然後Dify會建立一個隨機的API Key，例如：「app-wUJxFJBqbPhZLUwkxGoI2qJQ」。我們複製它即可。
3. Dify2OpenAI：API轉換 / Dify2OpenAI: API Adapter
dify2openai的設定我已經在docker-compose.yml設定完成。它會連結Dify的服務(主要是Dify用來對外顯示網頁的nginx)，只要輸入正確的API Key就能順利呼叫。在我預設的設定下，dify2openai會模擬成OpenAI的o1模型。如果需要修改的話，可以在 .env 環境變數裡面宣告。
如果在瀏覽器輸入dify2openai預設的網址： http://localhost:18081 ，就會看到正常顯示的樣子。
4. Cloudflare Tunnel：將API轉換成公開網址 / Cloudflare Tunnel: Converting API into Public URL
我在startup.sh腳本裡面使用了Cloudflare Tunnel將dify2openai的網址連接到了Cloudflare上。Cloudflare Tunnel會隨機分配一個網址，例如「 https://exam-therapist-disclaimer-compromise.trycloudflare.com 」。每次連接所獲得的網址都不一樣。
5. FastGPT：使用API / FastGPT: Using the API
https://cloud.tryfastgpt.ai/account/thirdParty
接著我們到FastGPT裡面。FastGPT的Third Pary account可以讓我們設定OpenAI/OneAPI account，而在這之中我們可以設定API Key跟BaseUrl。API Key就是從Dify取得的API Key，而BaseUrl則是剛剛連接到Cloudflare Tunnel的網址，並在路徑上加上「/v1」，例如「https://exam-therapist-disclaimer-compromise.trycloudflare.com/v1」。
接著便可到Studio建立應用程式，模型選用OpenAI的o1。此時使用的o1模型其實是連接到Dify的「喵型語言模型」，因此不管使用者講什麼內容，模型一律都只會回「喵」。
如此一來，我們製作的相容於OpenAI API的「喵型語言模型」就打造完成了。這應該比花50美元打造蒸餾模型還要便宜喔？(誤)
結語 / Conclusion
這篇的做法的重點並不是在「喵型語言模型」，而是「能夠跟OpenAI API相容」的這一個特性。只要能將你的服務封裝成OpenAI API的相容格式，那麼就能將它跟目前大多數主流系統相互整合。
舉例來說，以為我們雖然可以用LightRAG打造更先進的RAG架構，但打造出來的結果卻難以跟其他系統整合。現在我們有這一套Dify跟Dify2OpenAI轉換的做法，那就可以利用Dify的靈活性，將LightRAG結合到Dify的Chatflow裡面，最後就能整合到任何支援OpenAI API的系統上。
當然，Dify2OpenAI實際上只實作了OpenAI API的大型語言模型接口，並沒有實作全部的功能，它也不能完全替代OpenAI API。儘管如此，能將我們製作的「喵型語言模型」整合在其他系統上，其實就有很多應用價值了。
這篇介紹如何打造OpenAI API相容服務的文章就到此為止了。文章的最後要來問大家的是，這個OpenAI API你認為還有什麼值得注意的價值呢？
- 1. 蒐集與記錄使用者的對談記錄。
- 2. 可以加上一些自訂的規則。
- 3. 跟客製化的RAG整合。
- 4. 背後介接Google Gemini模型。這難道是AI界的NTR？
- 5. 開發「汪型語言模型」。
- 6. 其他：歡迎在下面留言，分享你的看法吧！
