關(guān)CLI實(shí)戰(zhàn)：統(tǒng)一管理Ollama與vLLM多模型)
最近把本地跑的幾套大模型服務(wù)統(tǒng)一收口到一個(gè)網(wǎng)關(guān)下面發(fā)現(xiàn)很多人還在用最原始的方式管模型——這個(gè)項(xiàng)目開個(gè)端口那個(gè)項(xiàng)目改個(gè)配置調(diào)用方寫死IP和端口換個(gè)模型就要?jiǎng)哟a。今天就把這套本地大模型網(wǎng)關(guān)的CLI使用方式完整寫出來從為什么需要網(wǎng)關(guān)、怎么部署到日常命令、多模型路由、對(duì)接Codex CLI這類工具鏈再到我踩過的坑一次講透。這篇東西適合誰看如果你本地同時(shí)跑了Ollama、LM Studio、vLLM好幾個(gè)服務(wù)或者你正在用Codex CLI、Claude Code這類命令行編程工具但每次切換模型都要改環(huán)境變量、改配置文件那這篇文章能直接幫你省掉這些麻煩。就算你只有一個(gè)Ollama在跑網(wǎng)關(guān)也能給你帶來日志審計(jì)、Key管理、模型路由這些單靠Ollama拿不到的能力。1. 先解決一個(gè)根本問題本地模型多了以后到底亂在哪1.1 單機(jī)多模型服務(wù)的現(xiàn)實(shí)困境我先描述一個(gè)很多本地部署玩家都遇到過的場(chǎng)景。你的電腦上可能同時(shí)裝了Ollama用來跑Qwen系列的模型裝了LM Studio用來跑一些GGUF格式的社區(qū)模型還可能在Docker里掛了一個(gè)vLLM服務(wù)用來做高并發(fā)的推理測(cè)試。這三個(gè)服務(wù)各自為政Ollama默認(rèn)監(jiān)聽11434端口LM Studio默認(rèn)的是1234端口vLLM如果你不指定默認(rèn)是8000端口問題馬上來了。你今天寫了一個(gè)Python腳本調(diào)用Llama 3.1用的是http://localhost:11434/v1的地址明天想切到LM Studio里那個(gè)微調(diào)模型就要把代碼里的base_url改成http://localhost:1234/v1順便還要確認(rèn)LM Studio已經(jīng)開啟了本地服務(wù)器。后天想試試vLLM的并發(fā)能力又要改一遍。這在只有一兩個(gè)模型的時(shí)候還能忍一旦模型超過五個(gè)這邊改代碼、那邊查端口純粹是浪費(fèi)時(shí)間。1.2 網(wǎng)關(guān)本質(zhì)上做了一件什么事網(wǎng)關(guān)這個(gè)東西做網(wǎng)絡(luò)的同學(xué)肯定不陌生本質(zhì)上就是一個(gè)反向代理加一層控制面。你所有的模型請(qǐng)求先打到網(wǎng)關(guān)網(wǎng)關(guān)根據(jù)你配置的規(guī)則決定把請(qǐng)求轉(zhuǎn)發(fā)給后端的Ollama、LM Studio還是vLLM。這樣做有一個(gè)立竿見影的好處調(diào)用方永遠(yuǎn)只需要面對(duì)一個(gè)地址、一個(gè)端口、一套鑒權(quán)體系。你換模型、加模型、升級(jí)后端推理引擎調(diào)用方完全感知不到。就像你家里用路由器上網(wǎng)你不需要關(guān)心數(shù)據(jù)包到底走的是電信還是聯(lián)通的光貓你只知道自己的電腦填了192.168.1.1這個(gè)網(wǎng)關(guān)地址。在本地大模型這個(gè)場(chǎng)景里網(wǎng)關(guān)把“模型路由”“Key管理”“調(diào)用日志”“負(fù)載均衡”這些事情全部收口了。調(diào)用方拿到的永遠(yuǎn)是一個(gè)標(biāo)準(zhǔn)的OpenAI兼容接口地址后面是什么推理引擎跟調(diào)用方?jīng)]關(guān)系。1.3 本地場(chǎng)景下網(wǎng)關(guān)CLI比Web UI更實(shí)用現(xiàn)在市面上有不少帶Web管理界面的AI網(wǎng)關(guān)項(xiàng)目比如One API、new-api這類界面做得確實(shí)漂亮點(diǎn)鼠標(biāo)就能配置模型和渠道。但如果你是在命令行環(huán)境下工作或者你習(xí)慣用SSH連到一臺(tái)無顯示器的開發(fā)機(jī)上管理模型服務(wù)Web UI反而成了累贅。CLI的價(jià)值在于可腳本化、可遠(yuǎn)程、可集成進(jìn)你現(xiàn)有的shell工作流。你可以寫一個(gè)gateway model list去查看當(dāng)前所有模型的狀態(tài)可以在~/.zshrc里加一個(gè)alias一鍵切換默認(rèn)模型可以寫個(gè)cron腳本在模型服務(wù)掛掉之后自動(dòng)重啟并重新注冊(cè)路由。所以這篇文章我講的命令全都是終端里能直接敲的。從安裝到配置從調(diào)模型到排查問題全程不碰瀏覽器。2. 從零搭建網(wǎng)關(guān)CLI和本地模型服務(wù)的正確連接方式2.1 底層的模型服務(wù)還是得先跑起來網(wǎng)關(guān)只負(fù)責(zé)路由不負(fù)責(zé)推理。所以在配置網(wǎng)關(guān)之前你得先把底層的模型服務(wù)趟好。我目前的主力方案是Ollama加一個(gè)vLLM容器簡(jiǎn)單說下我的初始狀態(tài)Ollama跑在http://127.0.0.1:11434上面掛了qwen3:8b和llama3.1:8bvLLM容器映射到http://127.0.0.1:8000加載的是我自己轉(zhuǎn)換的一個(gè)量化模型先把這兩個(gè)服務(wù)分別測(cè)通確認(rèn)單獨(dú)調(diào)用沒問題curl http://127.0.0.1:11434/v1/models curl http://127.0.0.1:8000/v1/models這一步千萬別跳過。很多人在配置網(wǎng)關(guān)的時(shí)候遇到“model not found”之類的問題最后排查下來發(fā)現(xiàn)根本不是網(wǎng)關(guān)的鍋是后端模型服務(wù)壓根沒起來或者端口填錯(cuò)了?；A(chǔ)服務(wù)沒有自測(cè)通過之前不要去碰網(wǎng)關(guān)。2.2 安裝網(wǎng)關(guān)CLI我用的網(wǎng)關(guān)是LiteLLM它同時(shí)提供Python包和CLI工具對(duì)OpenAI兼容接口的支持做得最完善。安裝很簡(jiǎn)單pip install litellm[proxy]裝完以后驗(yàn)證一下版本litellm --version如果你不想用LiteLLMOne API也有命令行工具但我個(gè)人建議新手直接上LiteLLM原因是它的配置語法和OpenAI的模型命名規(guī)則高度一致學(xué)習(xí)成本低而且社區(qū)活躍度高遇到問題容易搜到解決方案。提示LiteLLM的CLI是在litellm包基礎(chǔ)上的如果之前裝過舊版建議先pip install -U litellm升級(jí)到最新版有些命令參數(shù)在新老版本之間不兼容。2.3 通過CLI直接啟動(dòng)一個(gè)網(wǎng)關(guān)實(shí)例LiteLLM最簡(jiǎn)單的啟動(dòng)方式是直接用命令行參數(shù)指定要代理的模型litellm --model ollama_chat/qwen3:8b --port 4000這條命令的意思是在4000端口起一個(gè)OpenAI兼容的代理服務(wù)把請(qǐng)求路由到Ollama上的qwen3:8b這個(gè)模型。啟動(dòng)之后終端里會(huì)看到網(wǎng)關(guān)的地址通常是http://0.0.0.0:4000。這時(shí)候你本地就有了一個(gè)統(tǒng)一的模型入口。但這樣一條命令只代理了一個(gè)模型離“網(wǎng)關(guān)”還差得遠(yuǎn)。真實(shí)的用法是把所有模型寫進(jìn)一個(gè)配置文件然后一條命令全部加載。我下面詳細(xì)說。2.4 用配置文件統(tǒng)一管理多個(gè)模型在項(xiàng)目目錄下創(chuàng)建一個(gè)config.yaml內(nèi)容長(zhǎng)這樣model_list: - model_name: qwen-local litellm_params: model: ollama_chat/qwen3:8b api_base: http://127.0.0.1:11434 - model_name: llama-local litellm_params: model: ollama_chat/llama3.1:8b api_base: http://127.0.0.1:11434 - model_name: vllm-local litellm_params: model: openai/qwen2.5-14b api_base: http://127.0.0.1:8000/v1 api_key: dummy這里有幾個(gè)設(shè)計(jì)意圖需要解釋一下model_name是你暴露給調(diào)用方的名字可以隨意起比如qwen-local。調(diào)用方只認(rèn)這個(gè)名字不關(guān)心后端到底是Ollama還是vLLM。litellm_params.model是實(shí)際轉(zhuǎn)發(fā)給后端時(shí)用的模型標(biāo)識(shí)。ollama_chat/前綴告訴LiteLLM走Ollama的chat接口openai/前綴告訴它走OpenAI兼容的chat接口。最后一個(gè)vLLM的配置里api_key填了什么不重要但必須填一個(gè)非空字符串因?yàn)長(zhǎng)iteLLM在轉(zhuǎn)發(fā)OpenAI兼容協(xié)議的時(shí)候默認(rèn)會(huì)在請(qǐng)求頭里帶上AuthorizationvLLM如果配置了鑒權(quán)就會(huì)校驗(yàn)?zāi)呐轮皇莻€(gè)dummy key也要占位。然后啟動(dòng)網(wǎng)關(guān)litellm --config config.yaml --port 4000看到日志里出現(xiàn)Uvicorn running on http://0.0.0.0:4000就說明成了。2.5 快速驗(yàn)證鏈路是否打通用標(biāo)準(zhǔn)OpenAI SDK來驗(yàn)證一下網(wǎng)關(guān)是否正常工作from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:4000/v1, api_keysk-local ) resp client.chat.completions.create( modelqwen-local, messages[{role: user, content: 你好介紹一下你自己}] ) print(resp.choices[0].message.content)這里api_key傳什么都可以只要你的網(wǎng)關(guān)沒有開啟鑒權(quán)。如果返回了正常的回復(fù)說明整條鏈路已經(jīng)跑通SDK - 網(wǎng)關(guān) - Ollama - 模型 - 返回。到這一步你已經(jīng)把多個(gè)模型收口到了同一個(gè)端口。接下來的內(nèi)容才是網(wǎng)關(guān)真正值錢的地方。3. 網(wǎng)關(guān)CLI的日常操作這些命令你必須爛熟于心3.1 查看已注冊(cè)的模型列表和健康狀態(tài)啟動(dòng)網(wǎng)關(guān)之后最常用的操作就是查看當(dāng)前有哪些模型可用。LiteLLM提供了/v1/models接口但也有對(duì)應(yīng)的CLI查詢方式不過說實(shí)話CLI層面最實(shí)用的還是直接curl一記curl http://127.0.0.1:4000/v1/models返回的JSON里會(huì)列出所有通過配置文件注冊(cè)的模型名。如果你配置了多個(gè)后端這里都會(huì)一并展示。但有些網(wǎng)關(guān)工具的健康檢查不在這個(gè)接口里。比如LiteLLM有專門的/health/readiness和/health/liveliness接口你可以用curl驗(yàn)證網(wǎng)關(guān)本身是否活著的curl http://127.0.0.1:4000/health/liveliness我習(xí)慣在shell配置里寫一個(gè)簡(jiǎn)短的alias方便隨時(shí)看模型狀態(tài)alias gwmcurl -s http://127.0.0.1:4000/v1/models | python3 -m json.tool這樣在終端敲gwm就能看到當(dāng)前所有可用模型比翻日志不知道方便到哪里去了。3.2 從命令行直接發(fā)起一次模型調(diào)用有時(shí)候不想寫Python腳本就想在終端里快速測(cè)一下某個(gè)模型是否正常響應(yīng)。用curl加網(wǎng)關(guān)地址就夠了curl http://127.0.0.1:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-local \ -d { model: qwen-local, messages: [{role: user, content: 用一句話介紹你自己}], max_tokens: 128 }返回的id、model、usage這些字段和OpenAI官方接口完全一致。你甚至可以指定stream: true來測(cè)試流式輸出是否正常。CLI模式還有一個(gè)隱藏好處配合jq可以快速提取關(guān)鍵字段curl -s http://127.0.0.1:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-local \ -d {model:llama-local,messages:[{role:user,content:hi}],max_tokens:50} \ | jq .choices[0].message.content實(shí)測(cè)下來這套組合拳在驗(yàn)證模型連通性的時(shí)候效率極高不用打開任何編輯器一條命令搞定。3.3 動(dòng)態(tài)添加和移除模型不用重啟網(wǎng)關(guān)配置文件的好處是持久化但缺點(diǎn)是你改完配置得重啟網(wǎng)關(guān)才能生效。好在LiteLLM提供了運(yùn)行時(shí)管理接口可以通過HTTP請(qǐng)求動(dòng)態(tài)添加模型。添加模型curl -X POST http://127.0.0.1:4000/model/new \ -H Content-Type: application/json \ -H Authorization: Bearer sk-1234 \ -d { model_name: mistral-local, litellm_params: { model: ollama_chat/mistral:7b, api_base: http://127.0.0.1:11434 } }刪除模型就用/model/delete接口參數(shù)類似。這個(gè)功能我實(shí)際用下來最典型的場(chǎng)景是臨時(shí)加載一個(gè)微調(diào)模型測(cè)效果測(cè)完直接刪掉不需要為了一個(gè)臨時(shí)實(shí)驗(yàn)去改配置文件。3.4 查看請(qǐng)求日志和token消耗網(wǎng)關(guān)的另一個(gè)價(jià)值在于日志。沒有網(wǎng)關(guān)的時(shí)候Ollama自己也能看日志但那只是Ollama一個(gè)服務(wù)的訪問日志。有了網(wǎng)關(guān)之后你可以在一個(gè)地方看到所有模型的調(diào)用記錄、token消耗、響應(yīng)延遲。LiteLLM的日志默認(rèn)輸出到終端stdout但你可以配置寫入文件或者接入Prometheus監(jiān)控。我本地的做法是配了一個(gè)簡(jiǎn)單的JSON日志文件方便后期用量分析在config.yaml里加上:general_settings: master_key: sk-1234 database_url: sqlite:///litellm.dbmaster_key是用來管理網(wǎng)關(guān)的超級(jí)密鑰配置之后所有管理接口比如動(dòng)態(tài)添加模型都需要帶上這個(gè)Key才能訪問。database_url是配置SQLite數(shù)據(jù)庫(kù)這樣LiteLLM會(huì)把每次調(diào)用的完整記錄持久化到本地?cái)?shù)據(jù)庫(kù)方便以后查詢“我上周到底調(diào)了多少次Qwen模型”。查詢歷史用CLI方式不直接我一般直接連SQLitesqlite3 litellm.db SELECT model, total_tokens, completion_tokens, prompt_tokens, response_time FROM LiteLLM_SpendLogs ORDER BY id DESC LIMIT 20;這個(gè)表格記錄了每次請(qǐng)求的模型名、輸入token、輸出token、響應(yīng)耗時(shí)。有了這個(gè)數(shù)據(jù)你就能算清楚本地跑模型的實(shí)際花銷——雖然本地推理不花錢但token量和響應(yīng)時(shí)間的統(tǒng)計(jì)對(duì)調(diào)優(yōu)模型選擇非常有價(jià)值。3.5 配置熱更新和優(yōu)雅關(guān)閉改完config.yaml之后不需要先kill再啟動(dòng)LiteLLM支持給主進(jìn)程發(fā)送信號(hào)來完成優(yōu)雅重載。在啟動(dòng)網(wǎng)關(guān)的終端里按CtrlC是直接停止更規(guī)范的做法是找到進(jìn)程號(hào)然后發(fā)一個(gè)SIGHUP信號(hào)kill -HUP $(pgrep -f litellm --config)不過實(shí)測(cè)下來這個(gè)方式的可靠性跟版本有關(guān)有些版本對(duì)SIGHUP的支持不太好。如果你發(fā)現(xiàn)重載后模型列表沒變化最穩(wěn)妥的方式還是先停止網(wǎng)關(guān)再重新啟動(dòng)# 停止 pkill -f litellm --config # 重新啟動(dòng) litellm --config config.yaml --port 4000啟動(dòng)命令你可以寫成一個(gè)shell腳本或者用nohup讓它后臺(tái)常駐nohup litellm --config config.yaml --port 4000 gateway.log 21 這就是一個(gè)標(biāo)準(zhǔn)的常駐服務(wù)了終端關(guān)閉也不影響。4. 多模型路由與調(diào)度網(wǎng)關(guān)比單純反向代理多出來的能力4.1 按模型名精確路由是基礎(chǔ)能力前面配置的model_name其實(shí)已經(jīng)是路由規(guī)則了。調(diào)用方請(qǐng)求qwen-local網(wǎng)關(guān)就轉(zhuǎn)發(fā)到Ollama上的Qwen模型請(qǐng)求vllm-local就轉(zhuǎn)發(fā)到vLLM上的模型。這叫“按模型名路由”是網(wǎng)關(guān)最基礎(chǔ)的能力。但只有這個(gè)還不值得專門搭一個(gè)網(wǎng)關(guān)。你直接記端口也能做到。4.2 同模型多后端負(fù)載均衡和fallback現(xiàn)實(shí)中的場(chǎng)景是你同一個(gè)模型可能部署了多個(gè)副本比如Ollama上有一個(gè)量化版本vLLM上有一個(gè)原版精度版本。你希望請(qǐng)求優(yōu)先打到某個(gè)后端如果它掛了就自動(dòng)切換到另一個(gè)。這在LiteLLM的配置里可以這樣寫model_list: - model_name: qwen-router litellm_params: model: ollama_chat/qwen3:8b api_base: http://127.0.0.1:11434 model_info: mode: chat - model_name: qwen-router litellm_params: model: openai/qwen2.5-14b api_base: http://127.0.0.1:8000/v1 api_key: dummy兩個(gè)條目的model_name都是qwen-router但后端不同。LiteLLM會(huì)自動(dòng)在這兩個(gè)后端之間做負(fù)載均衡如果一個(gè)后端返回錯(cuò)誤它會(huì)自動(dòng)嘗試另一個(gè)。這就實(shí)現(xiàn)了對(duì)調(diào)用方透明的高可用。你調(diào)qwen-router這個(gè)模型永遠(yuǎn)不需要關(guān)心當(dāng)前Ollama是否掛了。有一次我Ollama進(jìn)程因?yàn)轱@存不足直接崩了而我的代碼還在正常跑因?yàn)榫W(wǎng)關(guān)自動(dòng)把請(qǐng)求全部路由到了vLLM。這個(gè)體驗(yàn)沒有網(wǎng)關(guān)的時(shí)候是做不到的。4.3 按成本或延遲路由本地場(chǎng)景下的取舍LiteLLM企業(yè)版支持基于成本預(yù)算或者延遲指標(biāo)來做路由不過本地部署場(chǎng)景用不到那么重的東西。我更推薦的做法是根據(jù)任務(wù)類型手動(dòng)分模型。比如我自己的用法是日常聊天、代碼生成這類交互式任務(wù)走Ollama上的qwen3:8b因?yàn)轫憫?yīng)快批量跑測(cè)試用例、批量文本分類這類不要求實(shí)時(shí)的任務(wù)走vLLM上的qwen2.5-14b因?yàn)榫雀?、并發(fā)吞吐更大。在網(wǎng)關(guān)層面我維護(hù)兩套模型名qwen-local-fast和qwen-local-heavy調(diào)用方按需選擇。這比在代碼里寫死兩個(gè)base_url要干凈得多。4.4 配置模型組和優(yōu)先級(jí)策略有些網(wǎng)關(guān)工具支持模型組的概念一個(gè)模型組下面掛多個(gè)模型實(shí)例并配置權(quán)重或者優(yōu)先級(jí)。LiteLLM對(duì)權(quán)重的支持是通過router_settings來實(shí)現(xiàn)的配置方法是在config.yaml里加一段router_settings: routing_strategy: usage-based-routing model_group_alias: fast-models: [qwen-local, llama-local]這里的model_group_alias給fast-models取了一個(gè)別名調(diào)用方請(qǐng)求fast-models的時(shí)候網(wǎng)關(guān)會(huì)按策略從組里選一個(gè)模型。實(shí)測(cè)下來這種分組策略在你同時(shí)維護(hù)多個(gè)同量級(jí)模型、想交替驗(yàn)證不同模型效果的時(shí)候特別好用。你今天想試Qwen明天想試Llama調(diào)用方代碼一行不用改只要改別名指向的組內(nèi)模型就行。4.5 多Key管理與調(diào)用溯源網(wǎng)關(guān)還能幫你做多Key管理這一點(diǎn)在多人共用一臺(tái)開發(fā)機(jī)、或者多個(gè)項(xiàng)目共用一個(gè)本地模型服務(wù)的時(shí)候特別關(guān)鍵。LiteLLM配置了master_key之后你可以給每個(gè)項(xiàng)目或者每個(gè)開發(fā)者發(fā)一個(gè)獨(dú)立的虛擬Keycurl -X POST http://127.0.0.1:4000/key/generate \ -H Content-Type: application/json \ -H Authorization: Bearer sk-1234 \ -d {models: [qwen-local], max_budget: 1000}返回的JSON里會(huì)有一個(gè)新的key這個(gè)Key只能訪問qwen-local這一個(gè)模型而且有1000美元的預(yù)算上限本地場(chǎng)景可以換成你自己定的token上限。好處非常實(shí)際項(xiàng)目A的Key出了問題、調(diào)用量暴漲你直接刪掉那個(gè)Key就行不影響其他項(xiàng)目的正常使用。而且從日志表格里能看到每個(gè)Key的調(diào)用記錄排查問題的時(shí)候可以精確追溯“是哪個(gè)項(xiàng)目在瘋狂調(diào)模型”。5. 讓Codex CLI、Dify這類周邊工具統(tǒng)一走網(wǎng)關(guān)5.1 為什么周邊工具都要走網(wǎng)關(guān)而不是直連Ollama如果你的周邊工具鏈?zhǔn)荂odex CLI、Claude Code、Dify這類它們默認(rèn)都支持配置自定義的模型服務(wù)地址。很多人直接填Ollama的地址這能用但有兩個(gè)問題第一Ollama的API只支持Ollama自己管理的模型你想讓Codex CLI用一個(gè)跑在vLLM上的模型就做不到了。第二每個(gè)工具都要單獨(dú)配一份模型信息換模型要改N個(gè)地方。正確的姿勢(shì)是所有工具全部指向網(wǎng)關(guān)工具層面的模型名統(tǒng)一填網(wǎng)關(guān)里的model_name。這樣你換底層的模型服務(wù)對(duì)工具完全透明。5.2 Codex CLI接入本地網(wǎng)關(guān)Codex CLI是OpenAI出的終端編程助手默認(rèn)走OpenAI云端服務(wù)。要讓它的請(qǐng)求走本地網(wǎng)關(guān)需要修改它的配置文件。Codex CLI的配置文件是~/.codex/config.toml在里面加一段model qwen-local [model_providers.local] name Local Gateway base_url http://127.0.0.1:4000/v1 env_key LOCAL_GATEWAY_KEY wire_api chat然后在環(huán)境變量里設(shè)置LOCAL_GATEWAY_KEY隨便填一個(gè)非空字符串export LOCAL_GATEWAY_KEYsk-local配置完后啟動(dòng)Codex CLI讓它使用本地providercodex --provider local實(shí)測(cè)下來Codex CLI在代碼補(bǔ)全、簡(jiǎn)單代碼生成這類任務(wù)上用本地8B模型確實(shí)能跑通響應(yīng)速度取決于你的顯存和模型大小。如果用的是14B以上模型響應(yīng)會(huì)慢一些但對(duì)簡(jiǎn)單任務(wù)影響不大。5.3 Claude Code這類工具走網(wǎng)關(guān)的思路Claude Code是Anthropic的命令行工具它默認(rèn)走Anthropic的API地址但同樣支持自定義。它的配置文件里可以設(shè)置ANTHROPIC_BASE_URL環(huán)境變量指到網(wǎng)關(guān)。需要注意的一點(diǎn)是Claude Code走的是Anthropic協(xié)議而網(wǎng)關(guān)對(duì)外暴露的是OpenAI兼容接口。如果你要接Anthropic協(xié)議的工具需要網(wǎng)關(guān)層也支持Anthropic格式的轉(zhuǎn)發(fā)。LiteLLM的/v1/messages接口可以兼容一部分Anthropic格式但實(shí)測(cè)下來有一定差異不是所有模型都能完美適配。我的建議是如果你主力用Claude Code就不要強(qiáng)行讓它走本地模型了本地模型在復(fù)雜代碼任務(wù)上的表現(xiàn)和云端大模型差距還是明顯的。本地網(wǎng)關(guān)更適合接那些本身就用OpenAI協(xié)議的工具比如Codex CLI、Dify、各種自建應(yīng)用。5.4 Dify接入本地網(wǎng)關(guān)Dify是一個(gè)很好用的AI應(yīng)用開發(fā)平臺(tái)支持配置自定義模型供應(yīng)商。如果你用Dify操作本地部署的AI大模型官方有Ollama集成但為了統(tǒng)一管理我建議在Dify里配置OpenAI-API-compatible的供應(yīng)商。在Dify的“設(shè)置 - 模型供應(yīng)商 - OpenAI-API-compatible”里填寫API Base URLhttp://127.0.0.1:4000/v1API Key你給Dify單獨(dú)生成的虛擬KeyModel IDqwen-local就是網(wǎng)關(guān)里的模型名這樣Dify上搭建的應(yīng)用底層模型全走網(wǎng)關(guān)后續(xù)你想把某個(gè)應(yīng)用從Qwen切到Llama只需要在Dify后臺(tái)改模型ID或者干脆在網(wǎng)關(guān)層調(diào)整路由策略應(yīng)用完全不用動(dòng)。這里也能看出來做程序化開發(fā)或者AI應(yīng)用集成的人網(wǎng)關(guān)聯(lián)動(dòng)的負(fù)載均衡和模型別名機(jī)制真的能省很多事。5.5 為遠(yuǎn)程開發(fā)場(chǎng)景開放網(wǎng)關(guān)端口本地模型跑在一臺(tái)服務(wù)器上你人在筆記本上想通過CLI調(diào)用這時(shí)候需要讓網(wǎng)關(guān)監(jiān)聽非回環(huán)地址。啟動(dòng)參數(shù)里把--host改成0.0.0.0litellm --config config.yaml --port 4000 --host 0.0.0.0這時(shí)候網(wǎng)關(guān)會(huì)監(jiān)聽所有網(wǎng)絡(luò)接口局域網(wǎng)內(nèi)其他設(shè)備就能通過http://你的服務(wù)器IP:4000/v1來訪問。但這里有個(gè)安全意識(shí)要提醒如果不加鑒權(quán)內(nèi)網(wǎng)任何人都能白嫖你的模型資源甚至通過SSRF風(fēng)險(xiǎn)點(diǎn)探測(cè)你內(nèi)網(wǎng)的其他服務(wù)。所以開放網(wǎng)絡(luò)訪問之前務(wù)必在config.yaml里配置好master_key并且調(diào)用方都要帶上正確的Authorization頭。6. 踩坑記錄網(wǎng)關(guān)CLI實(shí)戰(zhàn)中我遇到的那些問題6.1 最常見的問題模型請(qǐng)求超時(shí)現(xiàn)象調(diào)用網(wǎng)關(guān)接口時(shí)模型遲遲不返回最后報(bào)超時(shí)錯(cuò)誤。排查鏈路第一步確認(rèn)后端模型服務(wù)是否正常。直接curl后端的原始接口curl -X POST http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen3:8b,messages:[{role:user,content:hi}],max_tokens:10}如果這里就超時(shí)說明問題在后端可能是模型正在加載、顯存不足導(dǎo)致計(jì)算極慢或者Ollama的并發(fā)隊(duì)列塞滿了。第二步如果后端正?？词遣皇蔷W(wǎng)關(guān)的request_timeout配置太短。LiteLLM默認(rèn)超時(shí)是600秒正常不會(huì)觸發(fā)但如果你改過配置把這個(gè)值調(diào)小過長(zhǎng)文本生成就會(huì)頻繁超時(shí)。第三步看網(wǎng)關(guān)日志里有沒有Connection reset或者Read timeout之類的錯(cuò)誤。如果有檢查后端服務(wù)的并發(fā)配置比如Ollama默認(rèn)OLLAMA_NUM_PARALLEL可能限制并發(fā)數(shù)請(qǐng)求排隊(duì)超過一定量就會(huì)拖垮響應(yīng)時(shí)間。6.2 模型名對(duì)不上導(dǎo)致404或者400現(xiàn)象調(diào)用網(wǎng)關(guān)時(shí)報(bào)model not found。這個(gè)坑絕大多數(shù)人都踩過。原因通常是model_name和實(shí)際的litellm_params.model搞混了。網(wǎng)關(guān)對(duì)外只認(rèn)model_name你配置里寫的是什么調(diào)用方就必須傳什么而litellm_params.model是對(duì)后端用的也很有講究。比如Ollama上的模型實(shí)際叫qwen3:8b你配置里寫的是litellm_params: model: ollama_chat/qwen3:8b這里必須帶ollama_chat/前綴如果只寫qwen3:8bLiteLLM會(huì)嘗試走OpenAI協(xié)議把請(qǐng)求發(fā)到默認(rèn)的OpenAI地址而不是Ollama結(jié)果必然報(bào)錯(cuò)。排查方法是打開網(wǎng)關(guān)的debug日志看它實(shí)際轉(zhuǎn)發(fā)到了哪個(gè)地址litellm --config config.yaml --port 4000 --debug日志里會(huì)明確打印出路由的目標(biāo)URL一眼就能看出問題。6.3 網(wǎng)關(guān)端口被占用導(dǎo)致啟動(dòng)失敗現(xiàn)象啟動(dòng)網(wǎng)關(guān)節(jié)時(shí)日志顯示address already in use。這個(gè)最常見的原因是上一次啟動(dòng)的網(wǎng)關(guān)進(jìn)程沒有干凈退出。用pkill -f litellm殺掉所有相關(guān)進(jìn)程后再檢查端口占用lsof -i :4000確認(rèn)端口空了再啟動(dòng)。如果只是換配置重載不需要每次殺進(jìn)程但如果你本地調(diào)試頻繁建議寫一個(gè)restart.sh腳本統(tǒng)一管理#!/bin/bash pkill -f litellm --config sleep 1 nohup litellm --config config.yaml --port 4000 gateway.log 21 echo Gateway restarted6.4 流式輸出在部分客戶端上不生效現(xiàn)象用curl加stream: true能正常看到流式輸出但某些客戶端工具比如一些Node.js庫(kù)或者老版本SDK只拿到一次性返回。這個(gè)大多是客戶端SDK版本問題跟網(wǎng)關(guān)關(guān)系不大。OpenAI兼容接口的流式規(guī)范已經(jīng)非常成熟只要客戶端支持stream_options或者SSE解析網(wǎng)關(guān)都能正常轉(zhuǎn)發(fā)。如果遇到某個(gè)SDK不兼容可以檢查網(wǎng)關(guān)日志里有沒有SSE相關(guān)的報(bào)錯(cuò)。LiteLLM對(duì)流式轉(zhuǎn)發(fā)的處理總體比較穩(wěn)我實(shí)測(cè)用官方OpenAI Python SDK、LangChain、LlamaIndex都沒問題。6.5 虛擬Key鑒權(quán)失敗現(xiàn)象配置了master_key之后原來不帶Authorization的請(qǐng)求全部報(bào)401。這是正常現(xiàn)象master_key一配置所有請(qǐng)求都需要鑒權(quán)。這時(shí)候你之前生成的虛擬Key就派上用場(chǎng)了。有一個(gè)容易踩的細(xì)節(jié)虛擬Key的生成和模型權(quán)限綁定如果你生成Key的時(shí)候只授權(quán)了qwen-local但請(qǐng)求的時(shí)候傳的model是llama-local網(wǎng)關(guān)會(huì)拒絕。排查方法是用master_key先請(qǐng)求一次看看能不能通如果master_key能通而虛擬Key不能通就是Key的模型權(quán)限配置問題。6.6 本地網(wǎng)關(guān)和Docker網(wǎng)絡(luò)互通問題如果你把網(wǎng)關(guān)跑在宿主機(jī)上但vLLM跑在Docker容器里注意容器端口映射和host地址的問題。在容器內(nèi)部的程序訪問宿主機(jī)服務(wù)時(shí)localhost是容器自己不是宿主機(jī)。要么你在容器啟動(dòng)時(shí)加了--networkhost要么就用host.docker.internal這個(gè)特殊域名來訪問宿主機(jī)。這個(gè)坑在同時(shí)用Docker部署多個(gè)模型服務(wù)時(shí)很常見網(wǎng)關(guān)看到后端遲遲連不上第一反應(yīng)是網(wǎng)絡(luò)問題第二反應(yīng)就是這種跨容器訪問的地址問題。6.7 顯存不足導(dǎo)致的進(jìn)程崩潰最后說一個(gè)模型服務(wù)層面的坑。本地模型網(wǎng)關(guān)本身不吃太多顯存但后端Ollama/vLLM會(huì)因?yàn)橥瑫r(shí)加載多個(gè)模型導(dǎo)致OOM。如果你在網(wǎng)關(guān)里注冊(cè)了多個(gè)模型而調(diào)用方恰好同時(shí)請(qǐng)求了不同模型后端推理引擎可能因?yàn)轱@存不足直接崩潰。我的處理建議是如果你顯存不夠大比如8GB以下一次只加載一到兩個(gè)模型其他模型用的時(shí)候再拉起來不用的時(shí)候Ollama會(huì)自動(dòng)釋放顯存。另外可以在Ollama啟動(dòng)時(shí)限制并發(fā)大小OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve別貪多一次能用的模型數(shù)量少一點(diǎn)穩(wěn)定性高很多。7. 還想補(bǔ)充的幾個(gè)實(shí)用細(xì)節(jié)7.1 網(wǎng)關(guān)CLI在Windows環(huán)境下的差異我在Linux上用得最順手但Windows終端也不是不能用。LiteLLM的Python包在Windows上運(yùn)行沒問題就是進(jìn)程管理和信號(hào)控制不如Linux方便。Windows下用taskkill /F /IM litellm.exe殺進(jìn)程或者干脆在PowerShell里用Stop-Process按進(jìn)程號(hào)關(guān)。7.2 用systemd把網(wǎng)關(guān)做成開機(jī)自啟服務(wù)如果你是在Linux服務(wù)器上常駐跑網(wǎng)關(guān)可以寫一個(gè)systemd服務(wù)開機(jī)自動(dòng)啟動(dòng)崩潰自動(dòng)重啟[Unit] DescriptionLiteLLM Gateway Afternetwork.target [Service] ExecStart/usr/local/bin/litellm --config /etc/litellm/config.yaml --port 4000 Restartalways Useryour_username [Install] WantedBymulti-user.target把文件放到/etc/systemd/system/litellm-gateway.service然后sudo systemctl daemon-reload sudo systemctl enable --now litellm-gateway這樣網(wǎng)關(guān)就成了一個(gè)真正的系統(tǒng)服務(wù)比你手動(dòng)nohup要省心得多。7.3 結(jié)合現(xiàn)有網(wǎng)絡(luò)架構(gòu)做權(quán)限隔離既然聊到了網(wǎng)關(guān)就順帶提一個(gè)跟網(wǎng)絡(luò)架構(gòu)有關(guān)的經(jīng)驗(yàn)。如果你的本地模型服務(wù)部署在公司或者工作室的局域網(wǎng)里而且旁邊就是要對(duì)接政務(wù)網(wǎng)或者財(cái)務(wù)專線的機(jī)器我建議網(wǎng)關(guān)卡在NAT層后面網(wǎng)關(guān)單獨(dú)用一個(gè)端口段模型服務(wù)本身只綁定內(nèi)網(wǎng)IP不暴露到外網(wǎng)。網(wǎng)關(guān)是你所有模型請(qǐng)求的唯一入口同時(shí)它也是唯一需要進(jìn)行訪問控制的邊界。這個(gè)思路和你設(shè)置固定網(wǎng)關(guān)地址、劃分VLAN的思路是一樣的網(wǎng)關(guān)收斂流量邊界收斂風(fēng)險(xiǎn)。7.4 這是我個(gè)人最推薦的目錄結(jié)構(gòu)最后分享一個(gè)我實(shí)際用來管理這套網(wǎng)關(guān)的目錄結(jié)構(gòu)~/ai-gateway/ ├── config.yaml # 主配置文件 ├── gateway.log # 運(yùn)行日志 ├── litellm.db # 調(diào)用記錄數(shù)據(jù)庫(kù) ├── restart.sh # 重啟腳本 └── models/ └── README.md # 記錄每個(gè)模型的實(shí)際用途配置文件用Git管理每次改模型之前先備份。這些習(xí)慣看起來很簡(jiǎn)單但時(shí)間久了你會(huì)感謝自己當(dāng)初的整理。我遇到過一個(gè)很現(xiàn)實(shí)的情況一個(gè)月前配置的模型我根本不記得它跑在哪個(gè)端口、哪個(gè)后端上全靠在models/README.md里的記錄才想起來。這套本地大模型網(wǎng)關(guān)CLI的組合我大概用了三個(gè)月期間經(jīng)歷了Ollama崩潰、vLLM擴(kuò)容、多個(gè)工具鏈切換模型等各種情況網(wǎng)關(guān)一直穩(wěn)定地在中間層做路由和轉(zhuǎn)譯。如果你也在為本地多模型管理頭疼可以按這篇文章里的思路逐步搭起來。先用一條命令把網(wǎng)關(guān)跑起來再慢慢把多模型路由、Key管理、日志統(tǒng)計(jì)這些東西加上去你會(huì)發(fā)現(xiàn)本地部署AI大模型這件事其實(shí)可以非常有條理。 LiteLLM網(wǎng)關(guān)CLI實(shí)戰(zhàn)：統(tǒng)一管理Ollama與vLLM多模型
最近把本地跑的幾套大模型服務(wù)統(tǒng)一收口到一個(gè)網(wǎng)關(guān)下面發(fā)現(xiàn)很多人還在用最原始的方式管模型——這個(gè)項(xiàng)目開個(gè)端口那個(gè)項(xiàng)目改個(gè)配置調(diào)用方寫死IP和端口換個(gè)模型就要?jiǎng)哟a。今天就把這套本地大模型網(wǎng)關(guān)的CLI使用方式完整寫出來從為什么需要網(wǎng)關(guān)、怎么部署到日常命令、多模型路由、對(duì)接Codex CLI這類工具鏈再到我踩過的坑一次講透。這篇東西適合誰看如果你本地同時(shí)跑了Ollama、LM Studio、vLLM好幾個(gè)服務(wù)或者你正在用Codex CLI、Claude Code這類命令行編程工具但每次切換模型都要改環(huán)境變量、改配置文件那這篇文章能直接幫你省掉這些麻煩。就算你只有一個(gè)Ollama在跑網(wǎng)關(guān)也能給你帶來日志審計(jì)、Key管理、模型路由這些單靠Ollama拿不到的能力。1. 先解決一個(gè)根本問題本地模型多了以后到底亂在哪1.1 單機(jī)多模型服務(wù)的現(xiàn)實(shí)困境我先描述一個(gè)很多本地部署玩家都遇到過的場(chǎng)景。你的電腦上可能同時(shí)裝了Ollama用來跑Qwen系列的模型裝了LM Studio用來跑一些GGUF格式的社區(qū)模型還可能在Docker里掛了一個(gè)vLLM服務(wù)用來做高并發(fā)的推理測(cè)試。這三個(gè)服務(wù)各自為政Ollama默認(rèn)監(jiān)聽11434端口LM Studio默認(rèn)的是1234端口vLLM如果你不指定默認(rèn)是8000端口問題馬上來了。你今天寫了一個(gè)Python腳本調(diào)用Llama 3.1用的是http://localhost:11434/v1的地址明天想切到LM Studio里那個(gè)微調(diào)模型就要把代碼里的base_url改成http://localhost:1234/v1順便還要確認(rèn)LM Studio已經(jīng)開啟了本地服務(wù)器。后天想試試vLLM的并發(fā)能力又要改一遍。這在只有一兩個(gè)模型的時(shí)候還能忍一旦模型超過五個(gè)這邊改代碼、那邊查端口純粹是浪費(fèi)時(shí)間。1.2 網(wǎng)關(guān)本質(zhì)上做了一件什么事網(wǎng)關(guān)這個(gè)東西做網(wǎng)絡(luò)的同學(xué)肯定不陌生本質(zhì)上就是一個(gè)反向代理加一層控制面。你所有的模型請(qǐng)求先打到網(wǎng)關(guān)網(wǎng)關(guān)根據(jù)你配置的規(guī)則決定把請(qǐng)求轉(zhuǎn)發(fā)給后端的Ollama、LM Studio還是vLLM。這樣做有一個(gè)立竿見影的好處調(diào)用方永遠(yuǎn)只需要面對(duì)一個(gè)地址、一個(gè)端口、一套鑒權(quán)體系。你換模型、加模型、升級(jí)后端推理引擎調(diào)用方完全感知不到。就像你家里用路由器上網(wǎng)你不需要關(guān)心數(shù)據(jù)包到底走的是電信還是聯(lián)通的光貓你只知道自己的電腦填了192.168.1.1這個(gè)網(wǎng)關(guān)地址。在本地大模型這個(gè)場(chǎng)景里網(wǎng)關(guān)把“模型路由”“Key管理”“調(diào)用日志”“負(fù)載均衡”這些事情全部收口了。調(diào)用方拿到的永遠(yuǎn)是一個(gè)標(biāo)準(zhǔn)的OpenAI兼容接口地址后面是什么推理引擎跟調(diào)用方?jīng)]關(guān)系。1.3 本地場(chǎng)景下網(wǎng)關(guān)CLI比Web UI更實(shí)用現(xiàn)在市面上有不少帶Web管理界面的AI網(wǎng)關(guān)項(xiàng)目比如One API、new-api這類界面做得確實(shí)漂亮點(diǎn)鼠標(biāo)就能配置模型和渠道。但如果你是在命令行環(huán)境下工作或者你習(xí)慣用SSH連到一臺(tái)無顯示器的開發(fā)機(jī)上管理模型服務(wù)Web UI反而成了累贅。CLI的價(jià)值在于可腳本化、可遠(yuǎn)程、可集成進(jìn)你現(xiàn)有的shell工作流。你可以寫一個(gè)gateway model list去查看當(dāng)前所有模型的狀態(tài)可以在~/.zshrc里加一個(gè)alias一鍵切換默認(rèn)模型可以寫個(gè)cron腳本在模型服務(wù)掛掉之后自動(dòng)重啟并重新注冊(cè)路由。所以這篇文章我講的命令全都是終端里能直接敲的。從安裝到配置從調(diào)模型到排查問題全程不碰瀏覽器。2. 從零搭建網(wǎng)關(guān)CLI和本地模型服務(wù)的正確連接方式2.1 底層的模型服務(wù)還是得先跑起來網(wǎng)關(guān)只負(fù)責(zé)路由不負(fù)責(zé)推理。所以在配置網(wǎng)關(guān)之前你得先把底層的模型服務(wù)趟好。我目前的主力方案是Ollama加一個(gè)vLLM容器簡(jiǎn)單說下我的初始狀態(tài)Ollama跑在http://127.0.0.1:11434上面掛了qwen3:8b和llama3.1:8bvLLM容器映射到http://127.0.0.1:8000加載的是我自己轉(zhuǎn)換的一個(gè)量化模型先把這兩個(gè)服務(wù)分別測(cè)通確認(rèn)單獨(dú)調(diào)用沒問題curl http://127.0.0.1:11434/v1/models curl http://127.0.0.1:8000/v1/models這一步千萬別跳過。很多人在配置網(wǎng)關(guān)的時(shí)候遇到“model not found”之類的問題最后排查下來發(fā)現(xiàn)根本不是網(wǎng)關(guān)的鍋是后端模型服務(wù)壓根沒起來或者端口填錯(cuò)了?；A(chǔ)服務(wù)沒有自測(cè)通過之前不要去碰網(wǎng)關(guān)。2.2 安裝網(wǎng)關(guān)CLI我用的網(wǎng)關(guān)是LiteLLM它同時(shí)提供Python包和CLI工具對(duì)OpenAI兼容接口的支持做得最完善。安裝很簡(jiǎn)單pip install litellm[proxy]裝完以后驗(yàn)證一下版本litellm --version如果你不想用LiteLLMOne API也有命令行工具但我個(gè)人建議新手直接上LiteLLM原因是它的配置語法和OpenAI的模型命名規(guī)則高度一致學(xué)習(xí)成本低而且社區(qū)活躍度高遇到問題容易搜到解決方案。提示LiteLLM的CLI是在litellm包基礎(chǔ)上的如果之前裝過舊版建議先pip install -U litellm升級(jí)到最新版有些命令參數(shù)在新老版本之間不兼容。2.3 通過CLI直接啟動(dòng)一個(gè)網(wǎng)關(guān)實(shí)例LiteLLM最簡(jiǎn)單的啟動(dòng)方式是直接用命令行參數(shù)指定要代理的模型litellm --model ollama_chat/qwen3:8b --port 4000這條命令的意思是在4000端口起一個(gè)OpenAI兼容的代理服務(wù)把請(qǐng)求路由到Ollama上的qwen3:8b這個(gè)模型。啟動(dòng)之后終端里會(huì)看到網(wǎng)關(guān)的地址通常是http://0.0.0.0:4000。這時(shí)候你本地就有了一個(gè)統(tǒng)一的模型入口。但這樣一條命令只代理了一個(gè)模型離“網(wǎng)關(guān)”還差得遠(yuǎn)。真實(shí)的用法是把所有模型寫進(jìn)一個(gè)配置文件然后一條命令全部加載。我下面詳細(xì)說。2.4 用配置文件統(tǒng)一管理多個(gè)模型在項(xiàng)目目錄下創(chuàng)建一個(gè)config.yaml內(nèi)容長(zhǎng)這樣model_list: - model_name: qwen-local litellm_params: model: ollama_chat/qwen3:8b api_base: http://127.0.0.1:11434 - model_name: llama-local litellm_params: model: ollama_chat/llama3.1:8b api_base: http://127.0.0.1:11434 - model_name: vllm-local litellm_params: model: openai/qwen2.5-14b api_base: http://127.0.0.1:8000/v1 api_key: dummy這里有幾個(gè)設(shè)計(jì)意圖需要解釋一下model_name是你暴露給調(diào)用方的名字可以隨意起比如qwen-local。調(diào)用方只認(rèn)這個(gè)名字不關(guān)心后端到底是Ollama還是vLLM。litellm_params.model是實(shí)際轉(zhuǎn)發(fā)給后端時(shí)用的模型標(biāo)識(shí)。ollama_chat/前綴告訴LiteLLM走Ollama的chat接口openai/前綴告訴它走OpenAI兼容的chat接口。最后一個(gè)vLLM的配置里api_key填了什么不重要但必須填一個(gè)非空字符串因?yàn)長(zhǎng)iteLLM在轉(zhuǎn)發(fā)OpenAI兼容協(xié)議的時(shí)候默認(rèn)會(huì)在請(qǐng)求頭里帶上AuthorizationvLLM如果配置了鑒權(quán)就會(huì)校驗(yàn)?zāi)呐轮皇莻€(gè)dummy key也要占位。然后啟動(dòng)網(wǎng)關(guān)litellm --config config.yaml --port 4000看到日志里出現(xiàn)Uvicorn running on http://0.0.0.0:4000就說明成了。2.5 快速驗(yàn)證鏈路是否打通用標(biāo)準(zhǔn)OpenAI SDK來驗(yàn)證一下網(wǎng)關(guān)是否正常工作from openai import OpenAI client OpenAI( base_urlhttp://127.0.0.1:4000/v1, api_keysk-local ) resp client.chat.completions.create( modelqwen-local, messages[{role: user, content: 你好介紹一下你自己}] ) print(resp.choices[0].message.content)這里api_key傳什么都可以只要你的網(wǎng)關(guān)沒有開啟鑒權(quán)。如果返回了正常的回復(fù)說明整條鏈路已經(jīng)跑通SDK - 網(wǎng)關(guān) - Ollama - 模型 - 返回。到這一步你已經(jīng)把多個(gè)模型收口到了同一個(gè)端口。接下來的內(nèi)容才是網(wǎng)關(guān)真正值錢的地方。3. 網(wǎng)關(guān)CLI的日常操作這些命令你必須爛熟于心3.1 查看已注冊(cè)的模型列表和健康狀態(tài)啟動(dòng)網(wǎng)關(guān)之后最常用的操作就是查看當(dāng)前有哪些模型可用。LiteLLM提供了/v1/models接口但也有對(duì)應(yīng)的CLI查詢方式不過說實(shí)話CLI層面最實(shí)用的還是直接curl一記curl http://127.0.0.1:4000/v1/models返回的JSON里會(huì)列出所有通過配置文件注冊(cè)的模型名。如果你配置了多個(gè)后端這里都會(huì)一并展示。但有些網(wǎng)關(guān)工具的健康檢查不在這個(gè)接口里。比如LiteLLM有專門的/health/readiness和/health/liveliness接口你可以用curl驗(yàn)證網(wǎng)關(guān)本身是否活著的curl http://127.0.0.1:4000/health/liveliness我習(xí)慣在shell配置里寫一個(gè)簡(jiǎn)短的alias方便隨時(shí)看模型狀態(tài)alias gwmcurl -s http://127.0.0.1:4000/v1/models | python3 -m json.tool這樣在終端敲gwm就能看到當(dāng)前所有可用模型比翻日志不知道方便到哪里去了。3.2 從命令行直接發(fā)起一次模型調(diào)用有時(shí)候不想寫Python腳本就想在終端里快速測(cè)一下某個(gè)模型是否正常響應(yīng)。用curl加網(wǎng)關(guān)地址就夠了curl http://127.0.0.1:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-local \ -d { model: qwen-local, messages: [{role: user, content: 用一句話介紹你自己}], max_tokens: 128 }返回的id、model、usage這些字段和OpenAI官方接口完全一致。你甚至可以指定stream: true來測(cè)試流式輸出是否正常。CLI模式還有一個(gè)隱藏好處配合jq可以快速提取關(guān)鍵字段curl -s http://127.0.0.1:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-local \ -d {model:llama-local,messages:[{role:user,content:hi}],max_tokens:50} \ | jq .choices[0].message.content實(shí)測(cè)下來這套組合拳在驗(yàn)證模型連通性的時(shí)候效率極高不用打開任何編輯器一條命令搞定。3.3 動(dòng)態(tài)添加和移除模型不用重啟網(wǎng)關(guān)配置文件的好處是持久化但缺點(diǎn)是你改完配置得重啟網(wǎng)關(guān)才能生效。好在LiteLLM提供了運(yùn)行時(shí)管理接口可以通過HTTP請(qǐng)求動(dòng)態(tài)添加模型。添加模型curl -X POST http://127.0.0.1:4000/model/new \ -H Content-Type: application/json \ -H Authorization: Bearer sk-1234 \ -d { model_name: mistral-local, litellm_params: { model: ollama_chat/mistral:7b, api_base: http://127.0.0.1:11434 } }刪除模型就用/model/delete接口參數(shù)類似。這個(gè)功能我實(shí)際用下來最典型的場(chǎng)景是臨時(shí)加載一個(gè)微調(diào)模型測(cè)效果測(cè)完直接刪掉不需要為了一個(gè)臨時(shí)實(shí)驗(yàn)去改配置文件。3.4 查看請(qǐng)求日志和token消耗網(wǎng)關(guān)的另一個(gè)價(jià)值在于日志。沒有網(wǎng)關(guān)的時(shí)候Ollama自己也能看日志但那只是Ollama一個(gè)服務(wù)的訪問日志。有了網(wǎng)關(guān)之后你可以在一個(gè)地方看到所有模型的調(diào)用記錄、token消耗、響應(yīng)延遲。LiteLLM的日志默認(rèn)輸出到終端stdout但你可以配置寫入文件或者接入Prometheus監(jiān)控。我本地的做法是配了一個(gè)簡(jiǎn)單的JSON日志文件方便后期用量分析在config.yaml里加上:general_settings: master_key: sk-1234 database_url: sqlite:///litellm.dbmaster_key是用來管理網(wǎng)關(guān)的超級(jí)密鑰配置之后所有管理接口比如動(dòng)態(tài)添加模型都需要帶上這個(gè)Key才能訪問。database_url是配置SQLite數(shù)據(jù)庫(kù)這樣LiteLLM會(huì)把每次調(diào)用的完整記錄持久化到本地?cái)?shù)據(jù)庫(kù)方便以后查詢“我上周到底調(diào)了多少次Qwen模型”。查詢歷史用CLI方式不直接我一般直接連SQLitesqlite3 litellm.db SELECT model, total_tokens, completion_tokens, prompt_tokens, response_time FROM LiteLLM_SpendLogs ORDER BY id DESC LIMIT 20;這個(gè)表格記錄了每次請(qǐng)求的模型名、輸入token、輸出token、響應(yīng)耗時(shí)。有了這個(gè)數(shù)據(jù)你就能算清楚本地跑模型的實(shí)際花銷——雖然本地推理不花錢但token量和響應(yīng)時(shí)間的統(tǒng)計(jì)對(duì)調(diào)優(yōu)模型選擇非常有價(jià)值。3.5 配置熱更新和優(yōu)雅關(guān)閉改完config.yaml之后不需要先kill再啟動(dòng)LiteLLM支持給主進(jìn)程發(fā)送信號(hào)來完成優(yōu)雅重載。在啟動(dòng)網(wǎng)關(guān)的終端里按CtrlC是直接停止更規(guī)范的做法是找到進(jìn)程號(hào)然后發(fā)一個(gè)SIGHUP信號(hào)kill -HUP $(pgrep -f litellm --config)不過實(shí)測(cè)下來這個(gè)方式的可靠性跟版本有關(guān)有些版本對(duì)SIGHUP的支持不太好。如果你發(fā)現(xiàn)重載后模型列表沒變化最穩(wěn)妥的方式還是先停止網(wǎng)關(guān)再重新啟動(dòng)# 停止 pkill -f litellm --config # 重新啟動(dòng) litellm --config config.yaml --port 4000啟動(dòng)命令你可以寫成一個(gè)shell腳本或者用nohup讓它后臺(tái)常駐nohup litellm --config config.yaml --port 4000 gateway.log 21 這就是一個(gè)標(biāo)準(zhǔn)的常駐服務(wù)了終端關(guān)閉也不影響。4. 多模型路由與調(diào)度網(wǎng)關(guān)比單純反向代理多出來的能力4.1 按模型名精確路由是基礎(chǔ)能力前面配置的model_name其實(shí)已經(jīng)是路由規(guī)則了。調(diào)用方請(qǐng)求qwen-local網(wǎng)關(guān)就轉(zhuǎn)發(fā)到Ollama上的Qwen模型請(qǐng)求vllm-local就轉(zhuǎn)發(fā)到vLLM上的模型。這叫“按模型名路由”是網(wǎng)關(guān)最基礎(chǔ)的能力。但只有這個(gè)還不值得專門搭一個(gè)網(wǎng)關(guān)。你直接記端口也能做到。4.2 同模型多后端負(fù)載均衡和fallback現(xiàn)實(shí)中的場(chǎng)景是你同一個(gè)模型可能部署了多個(gè)副本比如Ollama上有一個(gè)量化版本vLLM上有一個(gè)原版精度版本。你希望請(qǐng)求優(yōu)先打到某個(gè)后端如果它掛了就自動(dòng)切換到另一個(gè)。這在LiteLLM的配置里可以這樣寫model_list: - model_name: qwen-router litellm_params: model: ollama_chat/qwen3:8b api_base: http://127.0.0.1:11434 model_info: mode: chat - model_name: qwen-router litellm_params: model: openai/qwen2.5-14b api_base: http://127.0.0.1:8000/v1 api_key: dummy兩個(gè)條目的model_name都是qwen-router但后端不同。LiteLLM會(huì)自動(dòng)在這兩個(gè)后端之間做負(fù)載均衡如果一個(gè)后端返回錯(cuò)誤它會(huì)自動(dòng)嘗試另一個(gè)。這就實(shí)現(xiàn)了對(duì)調(diào)用方透明的高可用。你調(diào)qwen-router這個(gè)模型永遠(yuǎn)不需要關(guān)心當(dāng)前Ollama是否掛了。有一次我Ollama進(jìn)程因?yàn)轱@存不足直接崩了而我的代碼還在正常跑因?yàn)榫W(wǎng)關(guān)自動(dòng)把請(qǐng)求全部路由到了vLLM。這個(gè)體驗(yàn)沒有網(wǎng)關(guān)的時(shí)候是做不到的。4.3 按成本或延遲路由本地場(chǎng)景下的取舍LiteLLM企業(yè)版支持基于成本預(yù)算或者延遲指標(biāo)來做路由不過本地部署場(chǎng)景用不到那么重的東西。我更推薦的做法是根據(jù)任務(wù)類型手動(dòng)分模型。比如我自己的用法是日常聊天、代碼生成這類交互式任務(wù)走Ollama上的qwen3:8b因?yàn)轫憫?yīng)快批量跑測(cè)試用例、批量文本分類這類不要求實(shí)時(shí)的任務(wù)走vLLM上的qwen2.5-14b因?yàn)榫雀?、并發(fā)吞吐更大。在網(wǎng)關(guān)層面我維護(hù)兩套模型名qwen-local-fast和qwen-local-heavy調(diào)用方按需選擇。這比在代碼里寫死兩個(gè)base_url要干凈得多。4.4 配置模型組和優(yōu)先級(jí)策略有些網(wǎng)關(guān)工具支持模型組的概念一個(gè)模型組下面掛多個(gè)模型實(shí)例并配置權(quán)重或者優(yōu)先級(jí)。LiteLLM對(duì)權(quán)重的支持是通過router_settings來實(shí)現(xiàn)的配置方法是在config.yaml里加一段router_settings: routing_strategy: usage-based-routing model_group_alias: fast-models: [qwen-local, llama-local]這里的model_group_alias給fast-models取了一個(gè)別名調(diào)用方請(qǐng)求fast-models的時(shí)候網(wǎng)關(guān)會(huì)按策略從組里選一個(gè)模型。實(shí)測(cè)下來這種分組策略在你同時(shí)維護(hù)多個(gè)同量級(jí)模型、想交替驗(yàn)證不同模型效果的時(shí)候特別好用。你今天想試Qwen明天想試Llama調(diào)用方代碼一行不用改只要改別名指向的組內(nèi)模型就行。4.5 多Key管理與調(diào)用溯源網(wǎng)關(guān)還能幫你做多Key管理這一點(diǎn)在多人共用一臺(tái)開發(fā)機(jī)、或者多個(gè)項(xiàng)目共用一個(gè)本地模型服務(wù)的時(shí)候特別關(guān)鍵。LiteLLM配置了master_key之后你可以給每個(gè)項(xiàng)目或者每個(gè)開發(fā)者發(fā)一個(gè)獨(dú)立的虛擬Keycurl -X POST http://127.0.0.1:4000/key/generate \ -H Content-Type: application/json \ -H Authorization: Bearer sk-1234 \ -d {models: [qwen-local], max_budget: 1000}返回的JSON里會(huì)有一個(gè)新的key這個(gè)Key只能訪問qwen-local這一個(gè)模型而且有1000美元的預(yù)算上限本地場(chǎng)景可以換成你自己定的token上限。好處非常實(shí)際項(xiàng)目A的Key出了問題、調(diào)用量暴漲你直接刪掉那個(gè)Key就行不影響其他項(xiàng)目的正常使用。而且從日志表格里能看到每個(gè)Key的調(diào)用記錄排查問題的時(shí)候可以精確追溯“是哪個(gè)項(xiàng)目在瘋狂調(diào)模型”。5. 讓Codex CLI、Dify這類周邊工具統(tǒng)一走網(wǎng)關(guān)5.1 為什么周邊工具都要走網(wǎng)關(guān)而不是直連Ollama如果你的周邊工具鏈?zhǔn)荂odex CLI、Claude Code、Dify這類它們默認(rèn)都支持配置自定義的模型服務(wù)地址。很多人直接填Ollama的地址這能用但有兩個(gè)問題第一Ollama的API只支持Ollama自己管理的模型你想讓Codex CLI用一個(gè)跑在vLLM上的模型就做不到了。第二每個(gè)工具都要單獨(dú)配一份模型信息換模型要改N個(gè)地方。正確的姿勢(shì)是所有工具全部指向網(wǎng)關(guān)工具層面的模型名統(tǒng)一填網(wǎng)關(guān)里的model_name。這樣你換底層的模型服務(wù)對(duì)工具完全透明。5.2 Codex CLI接入本地網(wǎng)關(guān)Codex CLI是OpenAI出的終端編程助手默認(rèn)走OpenAI云端服務(wù)。要讓它的請(qǐng)求走本地網(wǎng)關(guān)需要修改它的配置文件。Codex CLI的配置文件是~/.codex/config.toml在里面加一段model qwen-local [model_providers.local] name Local Gateway base_url http://127.0.0.1:4000/v1 env_key LOCAL_GATEWAY_KEY wire_api chat然后在環(huán)境變量里設(shè)置LOCAL_GATEWAY_KEY隨便填一個(gè)非空字符串export LOCAL_GATEWAY_KEYsk-local配置完后啟動(dòng)Codex CLI讓它使用本地providercodex --provider local實(shí)測(cè)下來Codex CLI在代碼補(bǔ)全、簡(jiǎn)單代碼生成這類任務(wù)上用本地8B模型確實(shí)能跑通響應(yīng)速度取決于你的顯存和模型大小。如果用的是14B以上模型響應(yīng)會(huì)慢一些但對(duì)簡(jiǎn)單任務(wù)影響不大。5.3 Claude Code這類工具走網(wǎng)關(guān)的思路Claude Code是Anthropic的命令行工具它默認(rèn)走Anthropic的API地址但同樣支持自定義。它的配置文件里可以設(shè)置ANTHROPIC_BASE_URL環(huán)境變量指到網(wǎng)關(guān)。需要注意的一點(diǎn)是Claude Code走的是Anthropic協(xié)議而網(wǎng)關(guān)對(duì)外暴露的是OpenAI兼容接口。如果你要接Anthropic協(xié)議的工具需要網(wǎng)關(guān)層也支持Anthropic格式的轉(zhuǎn)發(fā)。LiteLLM的/v1/messages接口可以兼容一部分Anthropic格式但實(shí)測(cè)下來有一定差異不是所有模型都能完美適配。我的建議是如果你主力用Claude Code就不要強(qiáng)行讓它走本地模型了本地模型在復(fù)雜代碼任務(wù)上的表現(xiàn)和云端大模型差距還是明顯的。本地網(wǎng)關(guān)更適合接那些本身就用OpenAI協(xié)議的工具比如Codex CLI、Dify、各種自建應(yīng)用。5.4 Dify接入本地網(wǎng)關(guān)Dify是一個(gè)很好用的AI應(yīng)用開發(fā)平臺(tái)支持配置自定義模型供應(yīng)商。如果你用Dify操作本地部署的AI大模型官方有Ollama集成但為了統(tǒng)一管理我建議在Dify里配置OpenAI-API-compatible的供應(yīng)商。在Dify的“設(shè)置 - 模型供應(yīng)商 - OpenAI-API-compatible”里填寫API Base URLhttp://127.0.0.1:4000/v1API Key你給Dify單獨(dú)生成的虛擬KeyModel IDqwen-local就是網(wǎng)關(guān)里的模型名這樣Dify上搭建的應(yīng)用底層模型全走網(wǎng)關(guān)后續(xù)你想把某個(gè)應(yīng)用從Qwen切到Llama只需要在Dify后臺(tái)改模型ID或者干脆在網(wǎng)關(guān)層調(diào)整路由策略應(yīng)用完全不用動(dòng)。這里也能看出來做程序化開發(fā)或者AI應(yīng)用集成的人網(wǎng)關(guān)聯(lián)動(dòng)的負(fù)載均衡和模型別名機(jī)制真的能省很多事。5.5 為遠(yuǎn)程開發(fā)場(chǎng)景開放網(wǎng)關(guān)端口本地模型跑在一臺(tái)服務(wù)器上你人在筆記本上想通過CLI調(diào)用這時(shí)候需要讓網(wǎng)關(guān)監(jiān)聽非回環(huán)地址。啟動(dòng)參數(shù)里把--host改成0.0.0.0litellm --config config.yaml --port 4000 --host 0.0.0.0這時(shí)候網(wǎng)關(guān)會(huì)監(jiān)聽所有網(wǎng)絡(luò)接口局域網(wǎng)內(nèi)其他設(shè)備就能通過http://你的服務(wù)器IP:4000/v1來訪問。但這里有個(gè)安全意識(shí)要提醒如果不加鑒權(quán)內(nèi)網(wǎng)任何人都能白嫖你的模型資源甚至通過SSRF風(fēng)險(xiǎn)點(diǎn)探測(cè)你內(nèi)網(wǎng)的其他服務(wù)。所以開放網(wǎng)絡(luò)訪問之前務(wù)必在config.yaml里配置好master_key并且調(diào)用方都要帶上正確的Authorization頭。6. 踩坑記錄網(wǎng)關(guān)CLI實(shí)戰(zhàn)中我遇到的那些問題6.1 最常見的問題模型請(qǐng)求超時(shí)現(xiàn)象調(diào)用網(wǎng)關(guān)接口時(shí)模型遲遲不返回最后報(bào)超時(shí)錯(cuò)誤。排查鏈路第一步確認(rèn)后端模型服務(wù)是否正常。直接curl后端的原始接口curl -X POST http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:qwen3:8b,messages:[{role:user,content:hi}],max_tokens:10}如果這里就超時(shí)說明問題在后端可能是模型正在加載、顯存不足導(dǎo)致計(jì)算極慢或者Ollama的并發(fā)隊(duì)列塞滿了。第二步如果后端正?？词遣皇蔷W(wǎng)關(guān)的request_timeout配置太短。LiteLLM默認(rèn)超時(shí)是600秒正常不會(huì)觸發(fā)但如果你改過配置把這個(gè)值調(diào)小過長(zhǎng)文本生成就會(huì)頻繁超時(shí)。第三步看網(wǎng)關(guān)日志里有沒有Connection reset或者Read timeout之類的錯(cuò)誤。如果有檢查后端服務(wù)的并發(fā)配置比如Ollama默認(rèn)OLLAMA_NUM_PARALLEL可能限制并發(fā)數(shù)請(qǐng)求排隊(duì)超過一定量就會(huì)拖垮響應(yīng)時(shí)間。6.2 模型名對(duì)不上導(dǎo)致404或者400現(xiàn)象調(diào)用網(wǎng)關(guān)時(shí)報(bào)model not found。這個(gè)坑絕大多數(shù)人都踩過。原因通常是model_name和實(shí)際的litellm_params.model搞混了。網(wǎng)關(guān)對(duì)外只認(rèn)model_name你配置里寫的是什么調(diào)用方就必須傳什么而litellm_params.model是對(duì)后端用的也很有講究。比如Ollama上的模型實(shí)際叫qwen3:8b你配置里寫的是litellm_params: model: ollama_chat/qwen3:8b這里必須帶ollama_chat/前綴如果只寫qwen3:8bLiteLLM會(huì)嘗試走OpenAI協(xié)議把請(qǐng)求發(fā)到默認(rèn)的OpenAI地址而不是Ollama結(jié)果必然報(bào)錯(cuò)。排查方法是打開網(wǎng)關(guān)的debug日志看它實(shí)際轉(zhuǎn)發(fā)到了哪個(gè)地址litellm --config config.yaml --port 4000 --debug日志里會(huì)明確打印出路由的目標(biāo)URL一眼就能看出問題。6.3 網(wǎng)關(guān)端口被占用導(dǎo)致啟動(dòng)失敗現(xiàn)象啟動(dòng)網(wǎng)關(guān)節(jié)時(shí)日志顯示address already in use。這個(gè)最常見的原因是上一次啟動(dòng)的網(wǎng)關(guān)進(jìn)程沒有干凈退出。用pkill -f litellm殺掉所有相關(guān)進(jìn)程后再檢查端口占用lsof -i :4000確認(rèn)端口空了再啟動(dòng)。如果只是換配置重載不需要每次殺進(jìn)程但如果你本地調(diào)試頻繁建議寫一個(gè)restart.sh腳本統(tǒng)一管理#!/bin/bash pkill -f litellm --config sleep 1 nohup litellm --config config.yaml --port 4000 gateway.log 21 echo Gateway restarted6.4 流式輸出在部分客戶端上不生效現(xiàn)象用curl加stream: true能正常看到流式輸出但某些客戶端工具比如一些Node.js庫(kù)或者老版本SDK只拿到一次性返回。這個(gè)大多是客戶端SDK版本問題跟網(wǎng)關(guān)關(guān)系不大。OpenAI兼容接口的流式規(guī)范已經(jīng)非常成熟只要客戶端支持stream_options或者SSE解析網(wǎng)關(guān)都能正常轉(zhuǎn)發(fā)。如果遇到某個(gè)SDK不兼容可以檢查網(wǎng)關(guān)日志里有沒有SSE相關(guān)的報(bào)錯(cuò)。LiteLLM對(duì)流式轉(zhuǎn)發(fā)的處理總體比較穩(wěn)我實(shí)測(cè)用官方OpenAI Python SDK、LangChain、LlamaIndex都沒問題。6.5 虛擬Key鑒權(quán)失敗現(xiàn)象配置了master_key之后原來不帶Authorization的請(qǐng)求全部報(bào)401。這是正常現(xiàn)象master_key一配置所有請(qǐng)求都需要鑒權(quán)。這時(shí)候你之前生成的虛擬Key就派上用場(chǎng)了。有一個(gè)容易踩的細(xì)節(jié)虛擬Key的生成和模型權(quán)限綁定如果你生成Key的時(shí)候只授權(quán)了qwen-local但請(qǐng)求的時(shí)候傳的model是llama-local網(wǎng)關(guān)會(huì)拒絕。排查方法是用master_key先請(qǐng)求一次看看能不能通如果master_key能通而虛擬Key不能通就是Key的模型權(quán)限配置問題。6.6 本地網(wǎng)關(guān)和Docker網(wǎng)絡(luò)互通問題如果你把網(wǎng)關(guān)跑在宿主機(jī)上但vLLM跑在Docker容器里注意容器端口映射和host地址的問題。在容器內(nèi)部的程序訪問宿主機(jī)服務(wù)時(shí)localhost是容器自己不是宿主機(jī)。要么你在容器啟動(dòng)時(shí)加了--networkhost要么就用host.docker.internal這個(gè)特殊域名來訪問宿主機(jī)。這個(gè)坑在同時(shí)用Docker部署多個(gè)模型服務(wù)時(shí)很常見網(wǎng)關(guān)看到后端遲遲連不上第一反應(yīng)是網(wǎng)絡(luò)問題第二反應(yīng)就是這種跨容器訪問的地址問題。6.7 顯存不足導(dǎo)致的進(jìn)程崩潰最后說一個(gè)模型服務(wù)層面的坑。本地模型網(wǎng)關(guān)本身不吃太多顯存但后端Ollama/vLLM會(huì)因?yàn)橥瑫r(shí)加載多個(gè)模型導(dǎo)致OOM。如果你在網(wǎng)關(guān)里注冊(cè)了多個(gè)模型而調(diào)用方恰好同時(shí)請(qǐng)求了不同模型后端推理引擎可能因?yàn)轱@存不足直接崩潰。我的處理建議是如果你顯存不夠大比如8GB以下一次只加載一到兩個(gè)模型其他模型用的時(shí)候再拉起來不用的時(shí)候Ollama會(huì)自動(dòng)釋放顯存。另外可以在Ollama啟動(dòng)時(shí)限制并發(fā)大小OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve別貪多一次能用的模型數(shù)量少一點(diǎn)穩(wěn)定性高很多。7. 還想補(bǔ)充的幾個(gè)實(shí)用細(xì)節(jié)7.1 網(wǎng)關(guān)CLI在Windows環(huán)境下的差異我在Linux上用得最順手但Windows終端也不是不能用。LiteLLM的Python包在Windows上運(yùn)行沒問題就是進(jìn)程管理和信號(hào)控制不如Linux方便。Windows下用taskkill /F /IM litellm.exe殺進(jìn)程或者干脆在PowerShell里用Stop-Process按進(jìn)程號(hào)關(guān)。7.2 用systemd把網(wǎng)關(guān)做成開機(jī)自啟服務(wù)如果你是在Linux服務(wù)器上常駐跑網(wǎng)關(guān)可以寫一個(gè)systemd服務(wù)開機(jī)自動(dòng)啟動(dòng)崩潰自動(dòng)重啟[Unit] DescriptionLiteLLM Gateway Afternetwork.target [Service] ExecStart/usr/local/bin/litellm --config /etc/litellm/config.yaml --port 4000 Restartalways Useryour_username [Install] WantedBymulti-user.target把文件放到/etc/systemd/system/litellm-gateway.service然后sudo systemctl daemon-reload sudo systemctl enable --now litellm-gateway這樣網(wǎng)關(guān)就成了一個(gè)真正的系統(tǒng)服務(wù)比你手動(dòng)nohup要省心得多。7.3 結(jié)合現(xiàn)有網(wǎng)絡(luò)架構(gòu)做權(quán)限隔離既然聊到了網(wǎng)關(guān)就順帶提一個(gè)跟網(wǎng)絡(luò)架構(gòu)有關(guān)的經(jīng)驗(yàn)。如果你的本地模型服務(wù)部署在公司或者工作室的局域網(wǎng)里而且旁邊就是要對(duì)接政務(wù)網(wǎng)或者財(cái)務(wù)專線的機(jī)器我建議網(wǎng)關(guān)卡在NAT層后面網(wǎng)關(guān)單獨(dú)用一個(gè)端口段模型服務(wù)本身只綁定內(nèi)網(wǎng)IP不暴露到外網(wǎng)。網(wǎng)關(guān)是你所有模型請(qǐng)求的唯一入口同時(shí)它也是唯一需要進(jìn)行訪問控制的邊界。這個(gè)思路和你設(shè)置固定網(wǎng)關(guān)地址、劃分VLAN的思路是一樣的網(wǎng)關(guān)收斂流量邊界收斂風(fēng)險(xiǎn)。7.4 這是我個(gè)人最推薦的目錄結(jié)構(gòu)最后分享一個(gè)我實(shí)際用來管理這套網(wǎng)關(guān)的目錄結(jié)構(gòu)~/ai-gateway/ ├── config.yaml # 主配置文件 ├── gateway.log # 運(yùn)行日志 ├── litellm.db # 調(diào)用記錄數(shù)據(jù)庫(kù) ├── restart.sh # 重啟腳本 └── models/ └── README.md # 記錄每個(gè)模型的實(shí)際用途配置文件用Git管理每次改模型之前先備份。這些習(xí)慣看起來很簡(jiǎn)單但時(shí)間久了你會(huì)感謝自己當(dāng)初的整理。我遇到過一個(gè)很現(xiàn)實(shí)的情況一個(gè)月前配置的模型我根本不記得它跑在哪個(gè)端口、哪個(gè)后端上全靠在models/README.md里的記錄才想起來。這套本地大模型網(wǎng)關(guān)CLI的組合我大概用了三個(gè)月期間經(jīng)歷了Ollama崩潰、vLLM擴(kuò)容、多個(gè)工具鏈切換模型等各種情況網(wǎng)關(guān)一直穩(wěn)定地在中間層做路由和轉(zhuǎn)譯。如果你也在為本地多模型管理頭疼可以按這篇文章里的思路逐步搭起來。先用一條命令把網(wǎng)關(guān)跑起來再慢慢把多模型路由、Key管理、日志統(tǒng)計(jì)這些東西加上去你會(huì)發(fā)現(xiàn)本地部署AI大模型這件事其實(shí)可以非常有條理。