Litellm這名字第一次看到的時(shí)候我還以為是個(gè)輕量級(jí)模型訓(xùn)練框架。真正用起來(lái)才發(fā)現(xiàn)人家干的是網(wǎng)關(guān)的活——把幾十家模型服務(wù)的API全部“翻譯”成同一種格式讓團(tuán)隊(duì)接入大模型就像調(diào)用一個(gè)統(tǒng)一接口那樣簡(jiǎn)單。這篇文章我就想把litellm從定位、核心功能到自托管部署完整地拆一遍盡量把那些踩過(guò)的坑和配置細(xì)節(jié)都寫(xiě)清楚。今年幾乎每個(gè)研發(fā)團(tuán)隊(duì)都在接大模型但接的過(guò)程遠(yuǎn)比想象中痛苦。今天換一個(gè)模型服務(wù)商明天換一套鑒權(quán)方式后天又要給不同業(yè)務(wù)線配不同的權(quán)限和預(yù)算。明明只是調(diào)個(gè)API硬生生搞成了中間件研發(fā)。litellm就是在這個(gè)時(shí)候出現(xiàn)的。它把常見(jiàn)的模型服務(wù)統(tǒng)一成同一套請(qǐng)求格式提供代理轉(zhuǎn)發(fā)、密鑰管理、成本追蹤、負(fù)載均衡這些能力相當(dāng)于在應(yīng)用和模型之間加了一層標(biāo)準(zhǔn)化網(wǎng)關(guān)。這篇文章適合正在做模型接入的技術(shù)負(fù)責(zé)人、后端開(kāi)發(fā)、算法工程和運(yùn)維同學(xué)尤其適合那些手上有多個(gè)模型服務(wù)、需要統(tǒng)一管理的團(tuán)隊(duì)。1. 為什么需要統(tǒng)一網(wǎng)關(guān)多模型混用場(chǎng)景下的真實(shí)痛點(diǎn)1.1 各模型服務(wù)接口不統(tǒng)一的麻煩先說(shuō)說(shuō)沒(méi)有網(wǎng)關(guān)之前我遇到的實(shí)際問(wèn)題。當(dāng)時(shí)團(tuán)隊(duì)同時(shí)用了兩個(gè)閉源模型服務(wù)商還自建了一套開(kāi)源的模型推理服務(wù)。三套接口三種鑒權(quán)方式三份SDK依賴代碼里到處是分支判斷。有一次一個(gè)模型服務(wù)臨時(shí)調(diào)整了返回格式我們的解析邏輯直接崩了排查了半天才發(fā)現(xiàn)是上游變更。如果只是接口格式不統(tǒng)一咬咬牙寫(xiě)個(gè)適配層也就算了。真正麻煩的是業(yè)務(wù)側(cè)的訴求不同業(yè)務(wù)線要用不同模型有的看重效果、有的看重成本、有的對(duì)延遲敏感。我們沒(méi)法簡(jiǎn)單地把某個(gè)模型服務(wù)商寫(xiě)死在代碼里因?yàn)槟Ｐ托Ч蛢r(jià)格都在快速變化今天效果最好的模型下周可能就被另一個(gè)替代了。這意味著路由、切換、灰度這些邏輯都要在應(yīng)用層實(shí)現(xiàn)工作量非常大。還有一個(gè)更痛的場(chǎng)景是成本控制。模型API都是按token收費(fèi)的但不同服務(wù)商的計(jì)費(fèi)口徑不一致有的按輸入輸出分開(kāi)計(jì)有的直接給一個(gè)綜合單價(jià)。月底對(duì)賬的時(shí)候財(cái)務(wù)給的賬單和研發(fā)記錄的對(duì)不上光核對(duì)就花了好幾天。密鑰管理也做得稀爛測(cè)試環(huán)境用的key和生產(chǎn)環(huán)境一樣部分同事離職后權(quán)限沒(méi)有及時(shí)回收造成很多安全隱患。1.2 litellm的核心定位解決“接口統(tǒng)一”和“治理統(tǒng)一”兩層問(wèn)題litellm解決的其實(shí)是我上面說(shuō)的所有問(wèn)題。它的核心思路是做一個(gè)中間層代理所有模型請(qǐng)求都發(fā)到litellm由litellm負(fù)責(zé)轉(zhuǎn)發(fā)到對(duì)應(yīng)的模型服務(wù)商。對(duì)應(yīng)用來(lái)說(shuō)永遠(yuǎn)只需要對(duì)接litellm一個(gè)地址請(qǐng)求格式統(tǒng)一對(duì)模型服務(wù)商來(lái)說(shuō)litellm就是一個(gè)普通客戶端密鑰都保存在litellm這一層。這個(gè)設(shè)計(jì)第一眼看上去很簡(jiǎn)單但實(shí)際帶來(lái)的收益非常大。首先應(yīng)用代碼里不再需要耦合某個(gè)具體的模型服務(wù)商切換模型只是改配置的事情。其次密鑰從應(yīng)用側(cè)收歸到了網(wǎng)關(guān)側(cè)應(yīng)用不再直接持有上游密鑰而是使用litellm生成的虛擬key方便做權(quán)限控制和撤銷。最后所有請(qǐng)求都經(jīng)過(guò)litellm自然就能在上面做計(jì)費(fèi)統(tǒng)計(jì)、速率限制、緩存、灰度路由這些統(tǒng)一治理。我把litellm理解為“模型接入層的操作系統(tǒng)”。就像操作系統(tǒng)統(tǒng)一管理硬件資源一樣litellm統(tǒng)一管理所有模型服務(wù)的通信、權(quán)限、成本和穩(wěn)定性。團(tuán)隊(duì)接入新模型的時(shí)間從幾周縮短到幾個(gè)小時(shí)業(yè)務(wù)方只需要提需求說(shuō)要用哪個(gè)模型運(yùn)維在litellm后臺(tái)配置一下就能生效。2. litellm核心能力拆解路由、密鑰、成本一個(gè)都不少2.1 模型路由、重試與負(fù)載均衡的實(shí)現(xiàn)機(jī)制litellm的路由能力很符合實(shí)際生產(chǎn)需要。它支持的模型服務(wù)商非常廣泛閉源的、開(kāi)源的、自建的都有對(duì)應(yīng)的接入方式。在litellm里每個(gè)模型都有一個(gè)全局唯一的模型名通常結(jié)構(gòu)是“服務(wù)商/模型名”但也可以自定義別名。應(yīng)用調(diào)用時(shí)只認(rèn)這個(gè)別名完全不用關(guān)心背后是哪個(gè)服務(wù)商。路由可以配策略。最簡(jiǎn)單的模式是固定路由指定某個(gè)請(qǐng)求只走某個(gè)模型。更實(shí)用的模式是fallback比如配置首選使用服務(wù)商A的模型當(dāng)A的調(diào)用失敗、超時(shí)或者觸發(fā)限流時(shí)自動(dòng)切換去調(diào)用服務(wù)商B的同級(jí)別模型。這功能在生產(chǎn)環(huán)境特別管用因?yàn)槟Ｐ头?wù)商不可能做到100%可用偶爾的限流和5xx錯(cuò)誤很常見(jiàn)。以前需要應(yīng)用自己做故障轉(zhuǎn)移現(xiàn)在直接在litellm配置里聲明就行。負(fù)載均衡也內(nèi)置了支持按權(quán)重分發(fā)和按優(yōu)先級(jí)分發(fā)。比如你有多個(gè)不同規(guī)格的實(shí)例或者同時(shí)買了幾家服務(wù)可以通過(guò)權(quán)重控制流量分配比例。litellm還支持健康檢查它會(huì)記錄每個(gè)模型最近的錯(cuò)誤率和延遲情況自動(dòng)把流量切到更健康的實(shí)例上。這些能力單獨(dú)做出來(lái)都要寫(xiě)不少代碼litellm用配置就能完成。2.2 虛擬密鑰、多租戶隔離與權(quán)限控制密鑰管理是litellm讓人越用越舒服的功能。上游模型服務(wù)的密鑰統(tǒng)一配置在litellm環(huán)境變量或者配置文件中不對(duì)業(yè)務(wù)方暴露。業(yè)務(wù)方需要接入時(shí)在litellm后臺(tái)生成一個(gè)虛擬key這個(gè)key對(duì)應(yīng)特定的模型權(quán)限、速率限制和預(yù)算上限。一個(gè)典型的場(chǎng)景是這樣的A部門要使用某個(gè)模型做客服機(jī)器人B部門要使用同一個(gè)模型做內(nèi)容分析。兩個(gè)部門的虛擬key是獨(dú)立的可以分別限制每日調(diào)用量、每分鐘請(qǐng)求數(shù)、每月預(yù)算還能設(shè)置過(guò)期時(shí)間。如果B部門某個(gè)同學(xué)離職了直接在后臺(tái)把對(duì)應(yīng)的key禁用掉而不會(huì)再影響其他部門。相比以前大家共用一把key這個(gè)管控粒度是一個(gè)質(zhì)的提升。多租戶隔離在litellm里做得很自然。你可以在配置里定義不同的團(tuán)隊(duì)或用戶每個(gè)虛擬key都?xì)w屬于某個(gè)團(tuán)隊(duì)。所有請(qǐng)求日志、token消耗、成本數(shù)據(jù)都會(huì)自動(dòng)打上團(tuán)隊(duì)的標(biāo)簽。這樣月底出成本報(bào)表時(shí)按團(tuán)隊(duì)、按項(xiàng)目、按key一拉就出來(lái)了再也不用拿Excel對(duì)著賬單手工整理了。提示虛擬key的生成依賴master key。部署時(shí)一定要保管好master key和salt key丟失了會(huì)導(dǎo)致已有虛擬key無(wú)法解析所有客戶端都要重新生成。2.3 成本追蹤、速率限制與預(yù)算控制怎么做成本追蹤是litellm被很多團(tuán)隊(duì)選中的直接原因。它會(huì)對(duì)每一次請(qǐng)求記錄三樣?xùn)|西輸入token數(shù)、輸出token數(shù)、使用的模型單價(jià)。把這兩個(gè)數(shù)字乘起來(lái)就得到了單次請(qǐng)求的成本。litellm支持為每個(gè)模型配置單價(jià)每個(gè)服務(wù)商的價(jià)格不一樣就在模型配置里逐個(gè)登記。預(yù)算控制可以做到用戶級(jí)和key級(jí)?？梢越o一個(gè)虛擬key設(shè)置每月1000元的預(yù)算上限當(dāng)消耗達(dá)到這個(gè)額度時(shí)litellm會(huì)直接拒絕新的請(qǐng)求返回預(yù)算超限的錯(cuò)誤。這個(gè)能力對(duì)內(nèi)部工具型應(yīng)用尤其重要之前經(jīng)常出現(xiàn)某個(gè)人寫(xiě)了個(gè)腳本不小心死循環(huán)調(diào)用模型一天跑掉幾千塊。有了預(yù)算限制之后這類事故最多損失的就是單個(gè)key的限額。速率限制支持每分鐘請(qǐng)求數(shù)RPM和每分鐘token數(shù)TPM兩個(gè)維度。限制可以作用在全局、用戶、key三個(gè)層面。設(shè)置的時(shí)候建議先看模型服務(wù)商本身的限流規(guī)格把litellm的限流值配得比上游略低一點(diǎn)這樣litellm就能在應(yīng)用側(cè)提前攔掉超限請(qǐng)求避免打到上游觸發(fā)服務(wù)商的限流懲罰。litellm還有一個(gè)緩存功能值得單獨(dú)說(shuō)。它可以緩存請(qǐng)求的響應(yīng)結(jié)果支持按prompt的精確匹配也支持語(yǔ)義相似度匹配。對(duì)于客服問(wèn)答、知識(shí)庫(kù)檢索這類請(qǐng)求重復(fù)度高的場(chǎng)景命中緩存能省掉大量token成本。緩存可以放在內(nèi)存里也可以放在Redis里生產(chǎn)環(huán)境建議用Redis一方面多實(shí)例共享緩存另一方面重啟不丟數(shù)據(jù)。3. 自托管部署實(shí)操?gòu)牧愦罱ㄒ惶卓捎玫拇砭W(wǎng)關(guān)3.1 組件準(zhǔn)備選擇一個(gè)最穩(wěn)的部署方式litellm最推薦的部署方式是用Docker Compose拉起一套服務(wù)。一個(gè)最小的生產(chǎn)部署需要四個(gè)組件litellm主服務(wù)、PostgreSQL數(shù)據(jù)庫(kù)、Redis緩存、以及一個(gè)用于存放配置文件的目錄。如果只是在本地跑著玩可以不接Redis但連接數(shù)據(jù)庫(kù)是必須的因?yàn)樘摂Mkey、預(yù)算、日志這些數(shù)據(jù)都存在數(shù)據(jù)庫(kù)里。我在選擇組件時(shí)花了一些時(shí)間對(duì)比。PostgreSQL是必須的嗎litellm也支持SQLite但只適合單機(jī)測(cè)試生產(chǎn)環(huán)境多個(gè)實(shí)例并發(fā)寫(xiě)SQLite會(huì)出問(wèn)題所以直接上PostgreSQL更省心。Redis也不是可選項(xiàng)生產(chǎn)環(huán)境強(qiáng)烈建議接上。除了緩存之外限流計(jì)數(shù)、請(qǐng)求追蹤也需要用到Redis如果缺失部分功能會(huì)退化成不好用的形態(tài)。數(shù)據(jù)庫(kù)連接串的格式大概是postgresql://用戶名:密碼地址:5432/數(shù)據(jù)庫(kù)名這里要注意密碼里有特殊字符的話需要做URL編碼。Redis連接串格式則是redis://地址:6379如果Redis設(shè)置了密碼同樣需要體現(xiàn)在連接串里。3.2 配置文件逐行講解模型、路由與密鑰參數(shù)litellm的配置核心是一個(gè)YAML文件官方通常叫config.yaml。下面是一份我在測(cè)試環(huán)境常用配置的結(jié)構(gòu)說(shuō)明每類配置的關(guān)鍵字段我都標(biāo)注了含義model_list: - model_name: gpt-entry # 統(tǒng)一對(duì)外暴露的模型名應(yīng)用側(cè)只認(rèn)這個(gè) litellm_params: model: provider-a/llm-v1 # 實(shí)際的服務(wù)商模型標(biāo)識(shí) api_key: os.environ/PROVIDER_A_API_KEY # 從環(huán)境變量讀取上游密鑰 model_info: cost_per_token: 0.00001 # 每token的成本用于費(fèi)用統(tǒng)計(jì) - model_name: chat-alt litellm_params: model: provider-b/chat-large api_key: os.environ/PROVIDER_B_API_KEY router_settings: routing_strategy: usage-based-routing # 基于用量的路由策略 model_group_alias: # 定義模型組方便做fallback chat-all: models: - gpt-entry - chat-alt這份配置要解釋幾個(gè)關(guān)鍵點(diǎn)。model_name是應(yīng)用直接感受的模型名它是整個(gè)配置體系的入口。model字段指定的是litellm翻譯后實(shí)際請(qǐng)求的目標(biāo)模型。cost_per_token是成本統(tǒng)計(jì)的基礎(chǔ)數(shù)據(jù)一定要和上游報(bào)價(jià)對(duì)得上不然成本報(bào)表就是錯(cuò)的。router_settings這段是生產(chǎn)環(huán)境里的重頭戲。model_group_alias可以定義一個(gè)模型組組內(nèi)按順序排列多個(gè)模型。當(dāng)組內(nèi)第一個(gè)模型失敗或超時(shí)時(shí)litellm會(huì)自動(dòng)用下一個(gè)模型重試這就是最基礎(chǔ)也最有效的fallback機(jī)制。我建議所有重要模型都配上fallback成本可以接受穩(wěn)定性提升非常明顯。3.3 用Docker Compose啟動(dòng)服務(wù)并完成初始化準(zhǔn)備好config.yaml和docker-compose.yml之后啟動(dòng)流程很簡(jiǎn)單。先創(chuàng)建需要掛載的目錄然后通過(guò)環(huán)境變量文件傳入master key、salt key和數(shù)據(jù)庫(kù)連接串。這里有一份docker-compose.yml的關(guān)鍵結(jié)構(gòu)可以參考services: litellm: image: ghcr.io/litellm/litellm:main-latest ports: - 4000:4000 volumes: - ./config.yaml:/app/config.yaml environment: - LITELLM_MASTER_KEYsk-master-xxxxx - LITELLM_SALT_KEYsk-salt-xxxxx - DATABASE_URLpostgresql://user:passpostgres:5432/litellm - REDIS_URLredis://redis:6379/0 depends_on: - postgres - redis postgres: image: postgres:16 environment: POSTGRES_USER: user POSTGRES_PASSWORD: pass POSTGRES_DB: litellm volumes: - pgdata:/var/lib/postgresql/data redis: image: redis:7 volumes: - redisdata:/data啟動(dòng)命令就是常規(guī)的docker compose up -d。第一次啟動(dòng)litellm會(huì)自動(dòng)建表并初始化數(shù)據(jù)庫(kù)。初始化完成后訪問(wèn)主機(jī)的4000端口就能看到管理后臺(tái)用master key登錄進(jìn)入后臺(tái)創(chuàng)建一個(gè)虛擬key然后就可以開(kāi)始測(cè)試了。有個(gè)細(xì)節(jié)要注意默認(rèn)的master key和salt key絕不能在生產(chǎn)環(huán)境使用。master key相當(dāng)于整個(gè)網(wǎng)關(guān)的root權(quán)限salt key用于加密虛擬key這兩個(gè)key必須改成足夠隨機(jī)的長(zhǎng)字符串建議至少32位。如果生成虛擬key之后修改了salt key之前生成的所有虛擬key都會(huì)失效所以要提前規(guī)劃好密鑰管理方案。3.4 把現(xiàn)有代碼切換到litellm的兩種方式接入litellm有兩種常見(jiàn)方式按需選擇。第一種方式是更換base_url適用于已經(jīng)使用兼容行業(yè)通用接口協(xié)議格式的客戶端的情況。只需要把代碼里設(shè)置API地址的地方改成litellm服務(wù)的地址把API key改成在litellm后臺(tái)生成的虛擬key即可。這種方式改動(dòng)最小應(yīng)用代碼幾乎不需要?jiǎng)?。第二種方式是使用litellm的官方SDK。對(duì)于新項(xiàng)目或者需要更靈活控制的場(chǎng)景建議直接用litellm封裝好的客戶端。它提供了與通用聊天接口一致的調(diào)用方法但內(nèi)部會(huì)自動(dòng)處理路由、重試、fallback這些邏輯。用Python寫(xiě)一個(gè)簡(jiǎn)單調(diào)用長(zhǎng)這樣from litellm import completion response completion( modelgpt-entry, messages[{role: user, content: 你好}], ) print(response.choices[0].message.content)這個(gè)簡(jiǎn)單調(diào)用的背后litellm做了很多事情解析模型名、查詢路由策略、讀取對(duì)應(yīng)的上游配置、發(fā)起真實(shí)請(qǐng)求、處理重試和fallback、記錄token和成本數(shù)據(jù)。應(yīng)用層只需要關(guān)心傳入了哪些消息、拿到了什么回復(fù)這就是網(wǎng)關(guān)該有的樣子。如果應(yīng)用已經(jīng)用別的SDK封裝好的對(duì)話邏輯我建議先用第一種方式快速切換驗(yàn)證功能正常后再?zèng)Q定要不要逐步重構(gòu)到新SDK上。遷移這件事步子邁得小一點(diǎn)反而穩(wěn)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 請(qǐng)求超時(shí)與重試策略的常見(jiàn)坑使用litellm一段時(shí)間后我遇到過(guò)幾次問(wèn)題整理下來(lái)最有代表性的是以下幾類。第一個(gè)是請(qǐng)求超時(shí)時(shí)間設(shè)置過(guò)短。模型推理本身就是高延遲操作遇到高峰時(shí)段或者模型負(fù)載高時(shí)單次請(qǐng)求耗時(shí)可能超過(guò)30秒。如果應(yīng)用側(cè)或litellm側(cè)的超時(shí)設(shè)置小于模型實(shí)際耗時(shí)就會(huì)造成局部成功但整體報(bào)錯(cuò)的現(xiàn)象。排查這類問(wèn)題先看litellm日志里的具體錯(cuò)誤信息確認(rèn)是超時(shí)還是沒(méi)有響應(yīng)然后針對(duì)性調(diào)整timeout配置。我習(xí)慣把超時(shí)時(shí)間設(shè)為60秒以上給慢請(qǐng)求留出余量。第二個(gè)是重試導(dǎo)致的重復(fù)扣費(fèi)。litellm默認(rèn)會(huì)在請(qǐng)求失敗或超時(shí)時(shí)自動(dòng)重試重試是好事但如果不改配置在“請(qǐng)求已經(jīng)發(fā)送、響應(yīng)超時(shí)”的情況下重試可能造成用戶實(shí)際只發(fā)起一次請(qǐng)求上游卻被扣了兩次費(fèi)用。解決辦法是把重試策略和冪等機(jī)制配合好在業(yè)務(wù)代碼里生成請(qǐng)求唯一標(biāo)識(shí)模型側(cè)支持冪等參數(shù)時(shí)盡量帶上減少重復(fù)扣費(fèi)的可能性。4.2 模型配置不生效與權(quán)限認(rèn)證失敗第二個(gè)常見(jiàn)問(wèn)題改了config.yaml發(fā)現(xiàn)不生效。這個(gè)問(wèn)題多半是沒(méi)重啟服務(wù)。litellm的部分配置支持熱加載但新增模型列表這種核心配置建議在修改后重啟容器或者確認(rèn)配置熱加載的機(jī)制是否已開(kāi)啟。有一次我改了模型別名以為已經(jīng)生效結(jié)果線上調(diào)用還是走的舊配置浪費(fèi)了不少排查時(shí)間。第三種問(wèn)題是權(quán)限認(rèn)證失敗。表現(xiàn)是請(qǐng)求被拒絕返回認(rèn)證相關(guān)的錯(cuò)誤。排查步驟很固定先確認(rèn)請(qǐng)求用的key是虛擬key還是在后臺(tái)創(chuàng)建的測(cè)試key再確認(rèn)該虛擬key是否綁定了對(duì)應(yīng)的模型權(quán)限最后檢查master key是否被誤用。master key是管理后臺(tái)用的不能當(dāng)作正常業(yè)務(wù)key放在應(yīng)用里嚴(yán)格區(qū)分這兩種key能減少很多認(rèn)知混亂。有時(shí)認(rèn)證失敗的時(shí)間點(diǎn)也很關(guān)鍵。如果是一次性生成的一批key突然全部失效大概率是salt key變了或者數(shù)據(jù)庫(kù)被重置了。這種情況沒(méi)有快捷恢復(fù)方式只能重新生成key并下發(fā)所以生產(chǎn)環(huán)境的密鑰保存和備份策略要提前設(shè)計(jì)好。4.3 成本統(tǒng)計(jì)偏差與緩存誤傷的應(yīng)對(duì)思路成本統(tǒng)計(jì)偏差也值得單獨(dú)講一下。多數(shù)情況是模型單價(jià)配置得不對(duì)或者模型版本更新后計(jì)費(fèi)規(guī)則變化了而litellm配置沒(méi)同步更新。建議定期核對(duì)自己使用的每個(gè)模型的實(shí)際計(jì)費(fèi)價(jià)格更新到config.yaml里。另外如果使用了緩存功能命中緩存的請(qǐng)求不會(huì)計(jì)費(fèi)成本報(bào)表會(huì)顯示聚合成本偏低這是正常現(xiàn)象但要在做成本分析時(shí)把緩存命中率一起納入?yún)⒖疾挪粫?huì)誤判。緩存的副作用還有“誤傷”。語(yǔ)義緩存如果相似度閾值設(shè)置過(guò)低可能把兩個(gè)語(yǔ)義相近但內(nèi)容不同的請(qǐng)求當(dāng)成同一個(gè)請(qǐng)求來(lái)處理返回了舊結(jié)果。解決方式很簡(jiǎn)單對(duì)需要高準(zhǔn)確率、不允許內(nèi)容偏差的場(chǎng)景不要開(kāi)啟語(yǔ)義緩存只開(kāi)精確匹配緩存或者干脆全關(guān)掉對(duì)百科問(wèn)答、標(biāo)準(zhǔn)流程查詢這類允許近似回答的場(chǎng)景再考慮語(yǔ)義緩存。4.4 運(yùn)維安全日志、端口與數(shù)據(jù)庫(kù)備份最后是一些運(yùn)維層面的建議。litellm的日志里包含完整請(qǐng)求和響應(yīng)內(nèi)容這些數(shù)據(jù)可能涉及用戶隱私和業(yè)務(wù)敏感信息生產(chǎn)環(huán)境部署時(shí)一定要做好日志存儲(chǔ)和訪問(wèn)權(quán)限控制不能開(kāi)著默認(rèn)配置就把服務(wù)暴露在公網(wǎng)。管理后臺(tái)端口建議只對(duì)內(nèi)網(wǎng)開(kāi)放需要遠(yuǎn)程訪問(wèn)時(shí)走帶身份認(rèn)證的跳板方案不要直接把4000端口裸奔到公網(wǎng)。數(shù)據(jù)庫(kù)和Redis同樣需要注意安全。虛擬key、預(yù)算數(shù)據(jù)、請(qǐng)求記錄都存里面一定要設(shè)置強(qiáng)密碼定期備份。我自己的經(jīng)驗(yàn)是每周做一次全量備份每天做一次增量備份并且定期演練恢復(fù)流程。備份不是光把數(shù)據(jù)導(dǎo)出來(lái)就行還要確認(rèn)恢復(fù)后服務(wù)能正常起來(lái)否則真出事時(shí)才發(fā)現(xiàn)備份是個(gè)空殼就太晚了。最后再說(shuō)一點(diǎn)實(shí)際經(jīng)驗(yàn)litellm引入團(tuán)隊(duì)后真正有價(jià)值的并不是它省了多少接入代碼而是它把模型接入變成了一個(gè)可治理的過(guò)程。以前模型變更動(dòng)一發(fā)牽全身現(xiàn)在只是改配置、切流量、觀察數(shù)據(jù)。這種架構(gòu)上的靈活性在模型快速迭代的當(dāng)下比省幾行代碼重要得多。如果你團(tuán)隊(duì)也面臨多模型接入的混亂期花一兩天把litellm部署起來(lái)后面會(huì)省下非常多功夫。