1. LiteLLM 到底解決什么問題一個 API 網(wǎng)關的誕生邏輯做 AI 應用做到某個階段你一定會遇到這樣一個問題代碼里的模型調(diào)用五花八門某家用 OpenAI 的格式某家用 Anthropic 的格式本地跑的去連 Ollama私有化部署又要走 vLLM光是記住各家 API 差異就夠?qū)懸黄夹g文檔了。我最后找到的最省事解法就是 LiteLLM——一個把幾十家模型接口統(tǒng)一成同一套格式的開源網(wǎng)關。說起來很有意思LiteLLM 這個名字容易讓人誤以為它是個“輕量級大模型”但實際它和模型本身無關。它就是一個純 Python 寫的中間層你依然用 OpenAI 那套 SDK 的寫法去調(diào)模型LiteLLM 在背后替你翻譯請求、轉(zhuǎn)發(fā)請求、管理密鑰、控制預算甚至幫你做負載均衡和失敗重試。換句話說你只需要學會一種接口格式就能調(diào)用市面上幾乎所有主流的大模型。我以前帶過一個項目最開始只用一家的模型代碼寫得很順手。后來業(yè)務需要同時對比三家模型的效果為了切模型我在代碼里寫了三層 if-else每層對應不同的 SDK光是統(tǒng)一超時配置就折騰了兩天。接入 LiteLLM 之后整個調(diào)用層縮成了不到二十行代碼切換模型只需要改一個字符串。這種體驗上的落差才是 LiteLLM 真正打動我的地方。那它具體適合誰如果你是個人開發(fā)者想在本地快速體驗不同模型LiteLLM 的 SDK 模式足夠輕量如果你在公司負責 AI 平臺需要給團隊統(tǒng)一模型入口、控制成本、審計調(diào)用記錄LiteLLM 的 Proxy 模式幾乎就是為你準備的。無論哪種場景它的核心價值都一樣把“接模型”這件事從一個月的工作量壓縮到一天。我在實際使用中反復確認過LiteLLM 并不僅僅是個“轉(zhuǎn)換器”它在轉(zhuǎn)換之外還做了三層很關鍵的事第一層是協(xié)議歸一把各家的請求體、返回體、錯誤碼都翻譯成 OpenAI 風格第二層是路由調(diào)度可以在多個模型、多個密鑰、多個供應商之間做分發(fā)第三層是治理能力密鑰管理、預算限額、審計日志這些都是企業(yè)級網(wǎng)關該有的東西。這三點合起來才構成一個完整的“LLM Gateway”。1.1 為什么會聊到“統(tǒng)一 API 格式”這件事要理解 LiteLLM 的價值得先承認一個現(xiàn)狀模型廠商之間從來沒有為開發(fā)者考慮過接口兼容。OpenAI 的 Chat Completions 有 messages 數(shù)組和 role 字段Anthropic 的 Messages API 卻用 system 獨立字段加 content 數(shù)組Google 的 Gemini 又是另一套 generationConfig 結構本地 Ollama 的 /api/chat 走的是精簡版 OpenAI 風格但不完全一致。每個 SDK 的安裝方式不同、錯誤類型不同、流式返回的數(shù)據(jù)片結構不同。這個問題的本質(zhì)是“模型接口碎片化”。對一個業(yè)務團隊來說每多接一家模型就要多維護一套調(diào)用代碼、一套錯誤處理邏輯、一套鑒權方式而且這些代碼往往只為了某一個供應商存在沒法復用。更麻煩的是當你想在幾個模型間做 A/B 對比時代碼改動的范圍會超出預期因為各家的超時時間、最大 token 限制、重試策略都是獨立的。LiteLLM 的統(tǒng)一思路很簡單既然 OpenAI 的 API 格式已經(jīng)被廣泛接受成了事實上的行業(yè)標準那就讓其他所有模型都“說”O(jiān)penAI 的話。你在代碼里寫一個client.chat.completions.create把相同結構的參數(shù)傳進去LiteLLM 會判斷目標模型屬于哪一家然后自動轉(zhuǎn)換成對方需要的請求格式。等于你做應用開發(fā)永遠只面對一套接口契約。1.2 LiteLLM 的雙層架構SDK 模式與 Proxy 模式LiteLLM 提供兩種使用形態(tài)初學者容易混淆我分開講清楚。第一種是 SDK 模式你在自己的 Python 代碼里直接import litellm調(diào)用litellm.completion()或者litellm.embedding()LiteLLM 作為庫被嵌入你的進程里。這種方式適合個人項目、小服務、腳本工具不需要額外部署任何東西venv 里裝個包就能跑。第二種是 Proxy 模式你啟動一個獨立的 LiteLLM 服務進程它對外暴露一個標準的 OpenAI 兼容接口也就是一個 HTTP 服務器。你的應用代碼不再直接碰 LiteLLM 庫而是像調(diào)用遠程 OpenAI 服務一樣去請求這個代理。Proxy 模式承載了更多企業(yè)級能力比如虛擬密鑰、預算控制、調(diào)用審計、多模型負載均衡這些都是 SDK 模式?jīng)]有的。兩者的選擇并不沖突。我個人的習慣是本地驗證想法用 SDK 模式一旦要上生產(chǎn)環(huán)境或者要交付給團隊統(tǒng)一使用立刻切換到 Proxy 模式。因為 Proxy 模式把模型接入的復雜度收攏到一個獨立服務里業(yè)務代碼完全感知不到底層有多個模型供應商這在多人協(xié)作、多服務部署的場景下優(yōu)勢極其明顯。1.3 用生活化的方式理解 LiteLLM 的工作位置我經(jīng)常給團隊同事打一個比方LiteLLM 就像你出差時隨身帶的多口轉(zhuǎn)換插頭。插座標準五花八門你不可能每去一個地方就買一套專用的電線你只需要一個轉(zhuǎn)換頭把任何插座都變成你能用的形式。LiteLLM 就是這個轉(zhuǎn)換頭只不過它轉(zhuǎn)換的不是電流而是各家模型的 API 協(xié)議。但它又比轉(zhuǎn)換頭多做了幾件事。它像一個有“腦子”的轉(zhuǎn)換頭知道哪個插座容量不夠時換另一個插座供電知道這棟樓的電費是多少并幫你記賬知道某個插座臨時故障時自動切換到備用口。對應到技術上就是模型選擇、成本控制、故障轉(zhuǎn)移。這也是我對 LiteLLM 定位的理解它不只是一個格式翻譯器更是一個 AI 應用的流量入口與策略引擎。2. SDK 層實操從安裝到統(tǒng)一調(diào)用那些模型先聊 SDK 模式因為它是理解 LiteLLM 內(nèi)部邏輯最快的路徑。日常開發(fā)里我用 LiteLLM 的 SDK 模式最多的地方就是寫腳本做模型效果評測、跑實驗對比、或者在小型服務里快速接一個模型。它最大的特點就是省事不需要維護多套 SDK也不用啟動任何額外服務。2.1 環(huán)境準備與安裝LiteLLM 是一個純 Python 庫安裝方式?jīng)]什么特別直接用 pip 就行。有一點需要注意它會順帶裝不少依賴比如 pydantic、openai 等如果在已有項目里安裝建議單獨建虛擬環(huán)境避免和項目里其他依賴打架。我一般在做模型接入相關的項目時會直接開一個新的 venv 或者 conda 環(huán)境。pip install litellm[proxy]這里我用了[proxy]的 extra 安裝因為我知道后面一定會用到代理服務。如果你只想要 SDK 模式裝pip install litellm就夠。安裝完成之后可以跑一下自帶的版本命令確認環(huán)境正常然后順手看一眼支持的模型列表。python -c import litellm; print(litellm.__version__) python -c import litellm; print(litellm.model_list)2.2 首次調(diào)通寫一段最簡單的模型調(diào)用裝好之后最快驗證通路的方式就是調(diào)一次litellm.completion()。大多數(shù)模型服務都需要 API 密鑰推薦的做法是用環(huán)境變量配置不要硬編碼在代碼里。LiteLLM 默認會讀取一些常見的環(huán)境變量名比如OPENAI_API_KEY、ANTHROPIC_API_KEY等這樣你在代碼里就不用寫api_key參數(shù)了。import os import litellm os.environ[OPENAI_API_KEY] your-openai-key os.environ[ANTHROPIC_API_KEY] your-anthropic-key # 調(diào)用 OpenAI 系模型 response_openai litellm.completion( modelgpt-4o-mini, messages[{role: user, content: 你好請簡單介紹一下自己}], ) # 調(diào)用 Anthropic 系模型 response_anthropic litellm.completion( modelanthropic/claude-3-5-sonnet, messages[{role: user, content: 你好請簡單介紹一下自己}], ) print(response_openai.choices[0].message.content) print(response_anthropic.choices[0].message.content)注意看第二段代碼模型名前面多了anthropic/前綴這是 LiteLLM 識別模型所屬供應商的方式。如果你要調(diào) Google 的 Gemini就寫gemini/gemini-1.5-pro調(diào)本地 Ollama 就寫ollama/llama3調(diào) Azure OpenAI 就寫azure/gpt-4o。這個前綴機制很重要后面我們講配置文件和排查問題時還會反復提到它。我第一次用的時候犯過一個錯直接把模型名寫成了claude-3-5-sonnet沒加anthropic/前綴結果 LiteLLM 把它當成 OpenAI 系的模型去請求然后報了一個模型不存在。這件事給我的教訓就是LiteLLM 的模型名規(guī)則是“供應商前綴 模型名”前綴不能省。想知道一個模型到底應該怎么寫去 LiteLLM 文檔的模型列表里查一次比在代碼里猜要快得多。2.3 進階用法流式、異步、函數(shù)調(diào)用模型調(diào)用進入真實業(yè)務場景之后光會completion()不夠。最常遇到的是流式輸出需求也就是像 ChatGPT 那樣一個字一個字地往外蹦。LiteLLM 對這個場景的支持很直接加一個streamTrue參數(shù)就能拿到生成器。response litellm.completion( modelgpt-4o-mini, messages[{role: user, content: 寫一段關于秋天的短文}], streamTrue, ) for chunk in response: delta chunk.choices[0].delta.content if delta: print(delta, end, flushTrue)流式返回的每個 chunk 結構基本上和 OpenAI 的流式格式一致所以如果你之前寫過 OpenAI 流式代碼幾乎可以無縫遷移。還有一點不同供應商的流式行為不一致有些是逐 token 返回有些是分塊返回但 LiteLLM 已經(jīng)在內(nèi)部幫你抹平了差異你在上層拿到的永遠是 OpenAI 風格的 chunk。再就是異步調(diào)用。在高并發(fā)場景下用異步能顯著提升吞吐量。LiteLLM 提供了litellm.acompletion()接口用起來和同步版本幾乎一樣只是需要配合await使用。import asyncio import litellm async def main(): response await litellm.acompletion( modelgpt-4o-mini, messages[{role: user, content: 寫一首五言絕句}], ) print(response.choices[0].message.content) asyncio.run(main())異步版的內(nèi)部實現(xiàn)實際上是把請求丟進了線程池去處理所以在某些嚴格限制線程數(shù)的環(huán)境里要注意別把線程池撐爆。另外函數(shù)調(diào)用Function Calling在 LiteLLM 里同樣做了統(tǒng)一各家模型只要支持都能識別 OpenAI 格式的tools參數(shù)這點我在多模型適配的業(yè)務里用過多次確實省心。2.4 SDK 層容易踩的幾個坑SDK 模式看著簡單實際用起來有幾個坑值得單獨提醒。第一個是環(huán)境變量大小寫問題。比如 Azure OpenAI 配置里有一堆像是AZURE_API_VERSION、AZURE_API_BASE之類的變量拼寫和大小寫必須和 LiteLLM 預期的一致否則認證就會失敗。排查這類問題最好的辦法是打開日志設置litellm.set_verbose True就能看到完整的請求日志。第二個坑是超時設置。LiteLLM 默認的請求超時時間有時會比較長而且不同供應商的默認值可能不一樣。如果你的業(yè)務對響應時間敏感一定要顯式設置request_timeout建議給一個你認為合理的值比如 30 秒而不是依賴默認值。第三點關于模型重試。LiteLLM 內(nèi)部自帶簡單的失敗重試機制但默認的重試次數(shù)、重試間隔不一定適合你的場景。遇到上游服務限流的問題重試反而會加劇限流所以要認真配置num_retries和retry_interval不要盲目提高重試次數(shù)。我現(xiàn)在習慣把 num_retries 控制在 2 次以內(nèi)讓錯誤快速暴露出來。3. Proxy 模式把模型接入做成一件事如果說 SDK 模式是給個人開發(fā)者準備的便利工具那 Proxy 模式就是給團隊、給生產(chǎn)環(huán)境準備的基礎設施。我一開始只用 SDK 模式后來同事多了人人都來問“你的 API Key 是什么”“我要接的模型怎么配”我才意識到統(tǒng)一網(wǎng)關是必然選擇。LiteLLM 的 Proxy 模式本質(zhì)上就是一個專為 LLM 場景設計的 API 網(wǎng)關。3.1 為什么團隊協(xié)作遲早要走到 Proxy讓大家各自拿著 SDK 接模型短期看著靈活時間一長就是災難。每個人的代碼里都有自己的模型配置、自己的密鑰管理方式有人把 API Key 寫死在代碼里有人根本沒設超時。一旦你要給團隊換一個底層模型就得通知所有人改代碼。這個場景下Proxy 模式的核心價值就出來了模型相關的所有配置全部收斂到一個服務里業(yè)務代碼只需要知道一個網(wǎng)關地址。除了配置收斂Proxy 模式還把一個很關鍵的能力帶出來了——密鑰隔離。你完全可以用一個網(wǎng)關主密鑰按團隊、按項目、按個人生成不同的虛擬密鑰每個虛擬密鑰可以綁定不同的模型白名單、不同的預算上限。這樣團隊成員各用各的密鑰互不干擾出問題比如某個密鑰被濫用時可以直接吊銷不影響其他人。還有審計日志。LiteLLM Proxy 會把每次調(diào)用的模型、Token 數(shù)、耗時、密鑰標識記錄下來配合數(shù)據(jù)庫存儲就能做成本分析、用量追蹤。這個能力在“模型費用分攤”“服務容量規(guī)劃”這些場景下特別有用。一個網(wǎng)關把模型接入這件事從“每個人的技術活”變成了“平臺的一項能力”。3.2 config.yamlProxy 的中樞神經(jīng)Proxy 模式的一切配置都圍繞一個 YAML 文件展開叫config.yaml。啟動代理時通過--config參數(shù)指定這個文件。這是整個 LiteLLM Proxy 最核心的部分我把一個生產(chǎn)環(huán)境用得比較多的配置寫出來逐字段解釋。model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY - model_name: local-llama litellm_params: model: ollama/llama3 api_base: http://localhost:11434 litellm_settings: drop_params: true set_verbose: false num_retries: 2 request_timeout: 30 cache: true cache_params: type: redis host: localhost port: 6379 general_settings: master_key: sk-your-master-key-here database_url: postgresql://user:passwordlocalhost:5432/litellm先看model_list它是路由的入口表。每個條目有一個model_name這是你對外暴露給調(diào)用方的名字業(yè)務代碼請求的時候只認這個名字。底下的litellm_params.model才是真正的供應鏈路由openai/、anthropic/、ollama/這些前綴決定請求會被翻譯成哪家格式、發(fā)到哪個地址。這里一個比較巧妙的設計是多個條目可以共用同一個model_name。比如我把同一個model_name配置到兩個不同的供應商上LiteLLM 就會在它們之間做負載均衡。這個能力在“多云容災”場景里很好用OpenAI 掛了流量自動轉(zhuǎn)到本地或者其他家。litellm_settings段是全局行為配置。drop_params: true值得專門講一下各家的請求參數(shù)并不完全一樣比如top_p、frequency_penalty這些參數(shù)有些供應商根本不支持如果傳過去就會報錯。打開drop_params后LiteLLM 會自動丟棄目標供應商不支持的參數(shù)這個開關我強烈建議在生產(chǎn)環(huán)境打開。general_settings段管的是網(wǎng)關自身的運維配置。master_key是代理服務的主密鑰所有管理接口的訪問都要用到它。另外建議開啟database_url把調(diào)用日志、密鑰信息持久化到數(shù)據(jù)庫里。沒有數(shù)據(jù)庫很多統(tǒng)計功能會退化為內(nèi)存模式重啟就丟數(shù)據(jù)。3.3 啟動代理與驗證通路配置文件寫好后啟動代理服務非常簡單。默認監(jiān)聽在 8000 端口你可以通過參數(shù)調(diào)整。litellm --config ./config.yaml --port 8000啟動成功后可以先用一個簡單的 curl 請求驗證通路。因為 LiteLLM Proxy 對外提供的是 OpenAI 兼容接口所以你可以用任何 OpenAI SDK 的客戶端去連它只需要把 base_url 指到代理地址即可。curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-master-key-here \ -d { model: claude-sonnet, messages: [{role: user, content: 你好}] }這里傳給model的參數(shù)是config.yaml里定義的model_name也就是claude-sonnet而不是真正的供應商模型名。這個隔離設計讓上層業(yè)務完全不用關心底層到底是哪個模型將來你把claude-sonnet背后的實現(xiàn)從 Anthropic 換成本地 vLLM業(yè)務代碼一行都不用改。3.4 虛擬密鑰、預算控制與負載均衡Proxy 模式有一個非常實用的管理接口體系都是通過 HTTP 調(diào)用的。我用得最多的是/key/generate這個端點用來創(chuàng)建虛擬密鑰。你可以限制這個密鑰能訪問哪些模型、能花多少錢甚至綁定到某個用戶或團隊。curl -X POST http://localhost:8000/key/generate \ -H Authorization: Bearer sk-your-master-key-here \ -H Content-Type: application/json \ -d { models: [gpt-4o-mini], budget: { budget_limit: 100, time_period: 30d } }返回結果里有一串以sk-開頭的 key把它發(fā)給對應的團隊成員他們就能用這個 key 請求代理。虛擬密鑰的價值在于第一真正的上游密鑰不會暴露給任何團隊成員第二每個密鑰的預算獨立誰超額了系統(tǒng)會自動攔截不需要人工干預。負載均衡的配置在前面說過原理在model_list里model_name相同、litellm_params不同的條目之間LiteLLM 默認會做輪詢分發(fā)。如果你需要不同權重可以用路由策略參數(shù)控制。這個能力我通常用在“主備切換”場景一個容量較大的主力供應商、一個成本較低的備用供應商主供應商限流時自動降級到備用。3.5 Proxy 生產(chǎn)化部署的關鍵經(jīng)驗Proxy 模式一旦跑在生產(chǎn)環(huán)境有幾個經(jīng)驗值得分享。第一個是 Docker 部署。LiteLLM 官方提供了現(xiàn)成的鏡像用 Docker Compose 可以很輕量地把代理服務和配套的 Redis、PostgreSQL 都編排起來隔離性比直接裸跑進程好很多。我一般會把config.yaml和.env文件掛載進容器不把密鑰寫進鏡像。第二個經(jīng)驗是端口與網(wǎng)絡。如果你的業(yè)務服務分布在不同的網(wǎng)絡區(qū)域要確保它們都能訪問到代理服務的端口同時做好訪問控制不要讓代理端口暴露到公網(wǎng)。建議在代理前面放一層網(wǎng)關比如自帶鑒權的 API 網(wǎng)關負責更細粒度的流量控制。還有個容易忽略的點代理服務的日志。日志里會包含完整的請求參數(shù)和響應內(nèi)容這些數(shù)據(jù)里可能有用戶輸入或生成結果要注意脫敏和訪問權限控制。尤其是在多租戶使用場景下日志數(shù)據(jù)的安全邊界要提前劃清楚別等出問題了再去亡羊補牢。4. 常見問題排查與避坑實錄技術文章寫到最后我一般都會把自己踩過的坑整理出來。LiteLLM 用久了問題是會集中出現(xiàn)在幾個地方系統(tǒng)性排查效率很高。下面這張表是我在多個項目里沉淀下來的高頻問題速查配合后面的詳細解釋一起看?，F(xiàn)象常見原因解決方案模型不存在錯誤模型名前忘了加供應商前綴檢查model參數(shù)確認前綴格式請求超時默認超時時間過長或模型響應慢顯式設置request_timeout參數(shù)報錯某些供應商不支持部分采樣參數(shù)打開drop_params: true流式輸出卡住上游接口不穩(wěn)定或超時配置太短檢查流式請求的超時適當調(diào)大密鑰鑒權失敗master_key 或虛擬密鑰配置不對檢查Authorization頭確認密鑰有效并發(fā)一高就失敗連接池或線程池太小調(diào)大并發(fā)數(shù)或考慮多實例部署緩存命中但結果奇怪緩存語義錯誤地命中了不同請求關閉緩存或細化緩存 key4.1 模型名前綴與格式問題這個是我見到開發(fā)者問得最多的。LiteLLM 的模型名規(guī)則可以理解為“目標供應商前綴/模型標識符”。比如 OpenAI 系的可以直接寫gpt-4o-mini也可以寫openai/gpt-4o-mini但 Anthropic 的必須寫anthropic/claude-3-5-sonnetGoogle 的寫gemini/gemini-1.5-pro本地的寫ollama/llama3。很多人剛上手時不習慣這個規(guī)則寫錯了就會得到模型不存在的報錯。判斷方法很簡單去 LiteLLM 官網(wǎng)的模型列表頁查一下你要用的模型名它寫了什么你就用什么。如果用了自定義模型名要確認litellm_params里面映射的model字段前綴正確。我排查這類問題上最快的動作就是打開 verbose 日志看實際發(fā)出的請求地址是什么。4.2 超時與重試策略怎么配才合理超時問題在接 Anthropic 和 Gemini 時特別容易遇到因為它們的推理速度可能比 OpenAI 更慢如果沿用 OpenAI 時代的超時設置就會頻繁超時。反過來如果你把所有超時都調(diào)成很大的值一旦上游真的掛了你的應用會長時間卡住。我的做法是分層設置第一層LiteLLM 的request_timeout設為業(yè)務可接受的上限比如 30 到 60 秒第二層依賴上游 SDK 自帶的超時比如有些供應商 SDK 默認連接超時是 10 秒讀取超時是 60 秒。兩層配合既能兜底又能快速暴露問題。重試策略上num_retries設 2 次我認為比較平衡間隔時間建議逐步擴大避免同時間打爆上游。4.3 緩存與日志的兩個深坑緩存是我用 LiteLLM Proxy 時最小心的地方。它的緩存機制可以緩存 LLM 的完整響應降低重復請求的開銷和費用。但大模型輸出天然帶有隨機性如果業(yè)務要求每次生成結果不同打開緩存反而會出問題。我建議只在確定性比較強的場景比如知識問答、關鍵詞提取里開緩存而且最好把緩存的 key 配置得細一點把 temperature、top_p 這些采樣參數(shù)都納入 key避免不同參數(shù)的請求互相污染。日志這塊前面已經(jīng)提醒過脫敏問題再補一個點LiteLLM 的日志是可配置的可以根據(jù)需求調(diào)整日志級別。生產(chǎn)環(huán)境建議把set_verbose關掉避免記錄過于詳盡的請求體既能減少存儲壓力也降低敏感信息泄露的風險。出了問題需要排查時臨時打開 verbose完事再關掉。5. 一個很實用的小技巧在網(wǎng)關層面做模型 A/B 測試最后分享一個我把 LiteLLM 用出額外價值的場景模型選型對比。很多團隊想在 OpenAI、Anthropic、本地開源模型之間做效果評估往往需要寫一套并行調(diào)用代碼然后手工整理結果。有了 LiteLLM Proxy 之后這個事變得非常簡單。思路是在config.yaml里把不同供應商的真實模型映射到同一個model_name下面然后輪流切換litellm_params.model指向的目標或者直接配置兩個不同名的模型入口。然后用一個腳本同時請求這兩個入口把返回結果、Token 消耗、響應耗時都記錄下來做對比。我實際用下來這套方案比在業(yè)務代碼里寫多供應商適配要省事得多。而且因為通過網(wǎng)關統(tǒng)計成本數(shù)據(jù)也是現(xiàn)成的直接就能算出每個模型回答一次的平均成本。我當時就是通過這種方式說服團隊把一部分高頻低復雜度的問題從商用模型遷移到本地模型成本降了將近一半效果差距卻很細微。LiteLLM 這個東西初看以為是工具用久了會發(fā)現(xiàn)它更像一種接入模型的“方法論”把復雜的、易變的模型生態(tài)屏蔽在業(yè)務視角之外。我個人到現(xiàn)在仍保持著一個小習慣——每次新項目起步接模型先把 LiteLLM 搭起來再去談業(yè)務邏輯這省下來的時間遠比想象中要多。如果你正在被多模型接入折磨不妨花一個下午把 Proxy 跑起來我相信你也會得出類似結論。