最近把本地跑的几套大模型服务统一收口到一个网关下面发现很多人还在用最原始的方式管模型——这个项目开个端口那个项目改个配置调用方写死IP和端口换个模型就要动代码。今天就把这套本地大模型网关的CLI使用方式完整写出来从为什么需要网关、怎么部署到日常命令、多模型路由、对接Codex CLI这类工具链再到我踩过的坑一次讲透。这篇东西适合谁看如果你本地同时跑了Ollama、LM Studio、vLLM好几个服务或者你正在用Codex CLI、Claude Code这类命令行编程工具但每次切换模型都要改环境变量、改配置文件那这篇文章能直接帮你省掉这些麻烦。就算你只有一个Ollama在跑网关也能给你带来日志审计、Key管理、模型路由这些单靠Ollama拿不到的能力。1. 先解决一个根本问题本地模型多了以后到底乱在哪1.1 单机多模型服务的现实困境我先描述一个很多本地部署玩家都遇到过的场景。你的电脑上可能同时装了Ollama用来跑Qwen系列的模型装了LM Studio用来跑一些GGUF格式的社区模型还可能在Docker里挂了一个vLLM服务用来做高并发的推理测试。这三个服务各自为政Ollama默认监听11434端口LM Studio默认的是1234端口vLLM如果你不指定默认是8000端口问题马上来了。你今天写了一个Python脚本调用Llama 3.1用的是http://localhost:11434/v1的地址明天想切到LM Studio里那个微调模型就要把代码里的base_url改成http://localhost:1234/v1顺便还要确认LM Studio已经开启了本地服务器。后天想试试vLLM的并发能力又要改一遍。这在只有一两个模型的时候还能忍一旦模型超过五个这边改代码、那边查端口纯粹是浪费时间。1.2 网关本质上做了一件什么事网关这个东西做网络的同学肯定不陌生本质上就是一个反向代理加一层控制面。你所有的模型请求先打到网关网关根据你配置的规则决定把请求转发给后端的Ollama、LM Studio还是vLLM。这样做有一个立竿见影的好处调用方永远只需要面对一个地址、一个端口、一套鉴权体系。你换模型、加模型、升级后端推理引擎调用方完全感知不到。就像你家里用路由器上网你不需要关心数据包到底走的是电信还是联通的光猫你只知道自己的电脑填了192.168.1.1这个网关地址。在本地大模型这个场景里网关把“模型路由”“Key管理”“调用日志”“负载均衡”这些事情全部收口了。调用方拿到的永远是一个标准的OpenAI兼容接口地址后面是什么推理引擎跟调用方没关系。1.3 本地场景下网关CLI比Web UI更实用现在市面上有不少带Web管理界面的AI网关项目比如One API、new-api这类界面做得确实漂亮点鼠标就能配置模型和渠道。但如果你是在命令行环境下工作或者你习惯用SSH连到一台无显示器的开发机上管理模型服务Web UI反而成了累赘。CLI的价值在于可脚本化、可远程、可集成进你现有的shell工作流。你可以写一个gateway model list去查看当前所有模型的状态可以在~/.zshrc里加一个alias一键切换默认模型可以写个cron脚本在模型服务挂掉之后自动重启并重新注册路由。所以这篇文章我讲的命令全都是终端里能直接敲的。从安装到配置从调模型到排查问题全程不碰浏览器。2. 从零搭建网关CLI和本地模型服务的正确连接方式2.1 底层的模型服务还是得先跑起来网关只负责路由不负责推理。所以在配置网关之前你得先把底层的模型服务趟好。我目前的主力方案是Ollama加一个vLLM容器简单说下我的初始状态Ollama跑在http://127.0.0.1:11434上面挂了qwen3:8b和llama3.1:8bvLLM容器映射到http://127.0.0.1:8000加载的是我自己转换的一个量化模型先把这两个服务分别测通确认单独调用没问题curl http://127.0.0.1:11434/v1/models curl http://127.0.0.1:8000/v1/models这一步千万别跳过。很多人在配置网关的时候遇到“model not found”之类的问题最后排查下来发现根本不是网关的锅是后端模型服务压根没起来或者端口填错了。基础服务没有自测通过之前不要去碰网关。2.2 安装网关CLI我用的网关是LiteLLM它同时提供Python包和CLI工具对OpenAI兼容接口的支持做得最完善。安装很简单pip install litellm[proxy]装完以后验证一下版本litellm --version如果你不想用LiteLLMOne API也有命令行工具但我个人建议新手直接上LiteLLM原因是它的配置语法和OpenAI的模型命名规则高度一致学习成本低而且社区活跃度高遇到问题容易搜到解决方案。提示LiteLLM的CLI是在litellm包基础上的如果之前装过旧版建议先pip install -U litellm升级到最新版有些命令参数在新老版本之间不兼容。2.3 通过CLI直接启动一个网关实例LiteLLM最简单的启动方式是直接用命令行参数指定要代理的模型litellm --model ollama_chat/qwen3:8b --port 4000这条命令的意思是在4000端口起一个OpenAI兼容的代理服务把请求路由到Ollama上的qwen3:8b这个模型。启动之后终端里会看到网关的地址通常是http://0.0.0.0:4000。这时候你本地就有了一个统一的模型入口。但这样一条命令只代理了一个模型离“网关”还差得远。真实的用法是把所有模型写进一个配置文件然后一条命令全部加载。我下面详细说。2.4 用配置文件统一管理多个模型在项目目录下创建一个config.yaml内容长这样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这里有几个设计意图需要解释一下model_name是你暴露给调用方的名字可以随意起比如qwen-local。调用方只认这个名字不关心后端到底是Ollama还是vLLM。litellm_params.model是实际转发给后端时用的模型标识。ollama_chat/前缀告诉LiteLLM走Ollama的chat接口openai/前缀告诉它走OpenAI兼容的chat接口。最后一个vLLM的配置里api_key填了什么不重要但必须填一个非空字符串因为LiteLLM在转发OpenAI兼容协议的时候默认会在请求头里带上AuthorizationvLLM如果配置了鉴权就会校验哪怕只是个dummy key也要占位。然后启动网关litellm --config config.yaml --port 4000看到日志里出现Uvicorn running on http://0.0.0.0:4000就说明成了。2.5 快速验证链路是否打通用标准OpenAI SDK来验证一下网关是否正常工作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传什么都可以只要你的网关没有开启鉴权。如果返回了正常的回复说明整条链路已经跑通SDK - 网关 - Ollama - 模型 - 返回。到这一步你已经把多个模型收口到了同一个端口。接下来的内容才是网关真正值钱的地方。3. 网关CLI的日常操作这些命令你必须烂熟于心3.1 查看已注册的模型列表和健康状态启动网关之后最常用的操作就是查看当前有哪些模型可用。LiteLLM提供了/v1/models接口但也有对应的CLI查询方式不过说实话CLI层面最实用的还是直接curl一记curl http://127.0.0.1:4000/v1/models返回的JSON里会列出所有通过配置文件注册的模型名。如果你配置了多个后端这里都会一并展示。但有些网关工具的健康检查不在这个接口里。比如LiteLLM有专门的/health/readiness和/health/liveliness接口你可以用curl验证网关本身是否活着的curl http://127.0.0.1:4000/health/liveliness我习惯在shell配置里写一个简短的alias方便随时看模型状态alias gwmcurl -s http://127.0.0.1:4000/v1/models | python3 -m json.tool这样在终端敲gwm就能看到当前所有可用模型比翻日志不知道方便到哪里去了。3.2 从命令行直接发起一次模型调用有时候不想写Python脚本就想在终端里快速测一下某个模型是否正常响应。用curl加网关地址就够了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来测试流式输出是否正常。CLI模式还有一个隐藏好处配合jq可以快速提取关键字段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实测下来这套组合拳在验证模型连通性的时候效率极高不用打开任何编辑器一条命令搞定。3.3 动态添加和移除模型不用重启网关配置文件的好处是持久化但缺点是你改完配置得重启网关才能生效。好在LiteLLM提供了运行时管理接口可以通过HTTP请求动态添加模型。添加模型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接口参数类似。这个功能我实际用下来最典型的场景是临时加载一个微调模型测效果测完直接删掉不需要为了一个临时实验去改配置文件。3.4 查看请求日志和token消耗网关的另一个价值在于日志。没有网关的时候Ollama自己也能看日志但那只是Ollama一个服务的访问日志。有了网关之后你可以在一个地方看到所有模型的调用记录、token消耗、响应延迟。LiteLLM的日志默认输出到终端stdout但你可以配置写入文件或者接入Prometheus监控。我本地的做法是配了一个简单的JSON日志文件方便后期用量分析在config.yaml里加上:general_settings: master_key: sk-1234 database_url: sqlite:///litellm.dbmaster_key是用来管理网关的超级密钥配置之后所有管理接口比如动态添加模型都需要带上这个Key才能访问。database_url是配置SQLite数据库这样LiteLLM会把每次调用的完整记录持久化到本地数据库方便以后查询“我上周到底调了多少次Qwen模型”。查询历史用CLI方式不直接我一般直接连SQLitesqlite3 litellm.db SELECT model, total_tokens, completion_tokens, prompt_tokens, response_time FROM LiteLLM_SpendLogs ORDER BY id DESC LIMIT 20;这个表格记录了每次请求的模型名、输入token、输出token、响应耗时。有了这个数据你就能算清楚本地跑模型的实际花销——虽然本地推理不花钱但token量和响应时间的统计对调优模型选择非常有价值。3.5 配置热更新和优雅关闭改完config.yaml之后不需要先kill再启动LiteLLM支持给主进程发送信号来完成优雅重载。在启动网关的终端里按CtrlC是直接停止更规范的做法是找到进程号然后发一个SIGHUP信号kill -HUP $(pgrep -f litellm --config)不过实测下来这个方式的可靠性跟版本有关有些版本对SIGHUP的支持不太好。如果你发现重载后模型列表没变化最稳妥的方式还是先停止网关再重新启动# 停止 pkill -f litellm --config # 重新启动 litellm --config config.yaml --port 4000启动命令你可以写成一个shell脚本或者用nohup让它后台常驻nohup litellm --config config.yaml --port 4000 gateway.log 21 这就是一个标准的常驻服务了终端关闭也不影响。4. 多模型路由与调度网关比单纯反向代理多出来的能力4.1 按模型名精确路由是基础能力前面配置的model_name其实已经是路由规则了。调用方请求qwen-local网关就转发到Ollama上的Qwen模型请求vllm-local就转发到vLLM上的模型。这叫“按模型名路由”是网关最基础的能力。但只有这个还不值得专门搭一个网关。你直接记端口也能做到。4.2 同模型多后端负载均衡和fallback现实中的场景是你同一个模型可能部署了多个副本比如Ollama上有一个量化版本vLLM上有一个原版精度版本。你希望请求优先打到某个后端如果它挂了就自动切换到另一个。这在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两个条目的model_name都是qwen-router但后端不同。LiteLLM会自动在这两个后端之间做负载均衡如果一个后端返回错误它会自动尝试另一个。这就实现了对调用方透明的高可用。你调qwen-router这个模型永远不需要关心当前Ollama是否挂了。有一次我Ollama进程因为显存不足直接崩了而我的代码还在正常跑因为网关自动把请求全部路由到了vLLM。这个体验没有网关的时候是做不到的。4.3 按成本或延迟路由本地场景下的取舍LiteLLM企业版支持基于成本预算或者延迟指标来做路由不过本地部署场景用不到那么重的东西。我更推荐的做法是根据任务类型手动分模型。比如我自己的用法是日常聊天、代码生成这类交互式任务走Ollama上的qwen3:8b因为响应快批量跑测试用例、批量文本分类这类不要求实时的任务走vLLM上的qwen2.5-14b因为精度更高、并发吞吐更大。在网关层面我维护两套模型名qwen-local-fast和qwen-local-heavy调用方按需选择。这比在代码里写死两个base_url要干净得多。4.4 配置模型组和优先级策略有些网关工具支持模型组的概念一个模型组下面挂多个模型实例并配置权重或者优先级。LiteLLM对权重的支持是通过router_settings来实现的配置方法是在config.yaml里加一段router_settings: routing_strategy: usage-based-routing model_group_alias: fast-models: [qwen-local, llama-local]这里的model_group_alias给fast-models取了一个别名调用方请求fast-models的时候网关会按策略从组里选一个模型。实测下来这种分组策略在你同时维护多个同量级模型、想交替验证不同模型效果的时候特别好用。你今天想试Qwen明天想试Llama调用方代码一行不用改只要改别名指向的组内模型就行。4.5 多Key管理与调用溯源网关还能帮你做多Key管理这一点在多人共用一台开发机、或者多个项目共用一个本地模型服务的时候特别关键。LiteLLM配置了master_key之后你可以给每个项目或者每个开发者发一个独立的虚拟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里会有一个新的key这个Key只能访问qwen-local这一个模型而且有1000美元的预算上限本地场景可以换成你自己定的token上限。好处非常实际项目A的Key出了问题、调用量暴涨你直接删掉那个Key就行不影响其他项目的正常使用。而且从日志表格里能看到每个Key的调用记录排查问题的时候可以精确追溯“是哪个项目在疯狂调模型”。5. 让Codex CLI、Dify这类周边工具统一走网关5.1 为什么周边工具都要走网关而不是直连Ollama如果你的周边工具链是Codex CLI、Claude Code、Dify这类它们默认都支持配置自定义的模型服务地址。很多人直接填Ollama的地址这能用但有两个问题第一Ollama的API只支持Ollama自己管理的模型你想让Codex CLI用一个跑在vLLM上的模型就做不到了。第二每个工具都要单独配一份模型信息换模型要改N个地方。正确的姿势是所有工具全部指向网关工具层面的模型名统一填网关里的model_name。这样你换底层的模型服务对工具完全透明。5.2 Codex CLI接入本地网关Codex CLI是OpenAI出的终端编程助手默认走OpenAI云端服务。要让它的请求走本地网关需要修改它的配置文件。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然后在环境变量里设置LOCAL_GATEWAY_KEY随便填一个非空字符串export LOCAL_GATEWAY_KEYsk-local配置完后启动Codex CLI让它使用本地providercodex --provider local实测下来Codex CLI在代码补全、简单代码生成这类任务上用本地8B模型确实能跑通响应速度取决于你的显存和模型大小。如果用的是14B以上模型响应会慢一些但对简单任务影响不大。5.3 Claude Code这类工具走网关的思路Claude Code是Anthropic的命令行工具它默认走Anthropic的API地址但同样支持自定义。它的配置文件里可以设置ANTHROPIC_BASE_URL环境变量指到网关。需要注意的一点是Claude Code走的是Anthropic协议而网关对外暴露的是OpenAI兼容接口。如果你要接Anthropic协议的工具需要网关层也支持Anthropic格式的转发。LiteLLM的/v1/messages接口可以兼容一部分Anthropic格式但实测下来有一定差异不是所有模型都能完美适配。我的建议是如果你主力用Claude Code就不要强行让它走本地模型了本地模型在复杂代码任务上的表现和云端大模型差距还是明显的。本地网关更适合接那些本身就用OpenAI协议的工具比如Codex CLI、Dify、各种自建应用。5.4 Dify接入本地网关Dify是一个很好用的AI应用开发平台支持配置自定义模型供应商。如果你用Dify操作本地部署的AI大模型官方有Ollama集成但为了统一管理我建议在Dify里配置OpenAI-API-compatible的供应商。在Dify的“设置 - 模型供应商 - OpenAI-API-compatible”里填写API Base URLhttp://127.0.0.1:4000/v1API Key你给Dify单独生成的虚拟KeyModel IDqwen-local就是网关里的模型名这样Dify上搭建的应用底层模型全走网关后续你想把某个应用从Qwen切到Llama只需要在Dify后台改模型ID或者干脆在网关层调整路由策略应用完全不用动。这里也能看出来做程序化开发或者AI应用集成的人网关联动的负载均衡和模型别名机制真的能省很多事。5.5 为远程开发场景开放网关端口本地模型跑在一台服务器上你人在笔记本上想通过CLI调用这时候需要让网关监听非回环地址。启动参数里把--host改成0.0.0.0litellm --config config.yaml --port 4000 --host 0.0.0.0这时候网关会监听所有网络接口局域网内其他设备就能通过http://你的服务器IP:4000/v1来访问。但这里有个安全意识要提醒如果不加鉴权内网任何人都能白嫖你的模型资源甚至通过SSRF风险点探测你内网的其他服务。所以开放网络访问之前务必在config.yaml里配置好master_key并且调用方都要带上正确的Authorization头。6. 踩坑记录网关CLI实战中我遇到的那些问题6.1 最常见的问题模型请求超时现象调用网关接口时模型迟迟不返回最后报超时错误。排查链路第一步确认后端模型服务是否正常。直接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}如果这里就超时说明问题在后端可能是模型正在加载、显存不足导致计算极慢或者Ollama的并发队列塞满了。第二步如果后端正常看是不是网关的request_timeout配置太短。LiteLLM默认超时是600秒正常不会触发但如果你改过配置把这个值调小过长文本生成就会频繁超时。第三步看网关日志里有没有Connection reset或者Read timeout之类的错误。如果有检查后端服务的并发配置比如Ollama默认OLLAMA_NUM_PARALLEL可能限制并发数请求排队超过一定量就会拖垮响应时间。6.2 模型名对不上导致404或者400现象调用网关时报model not found。这个坑绝大多数人都踩过。原因通常是model_name和实际的litellm_params.model搞混了。网关对外只认model_name你配置里写的是什么调用方就必须传什么而litellm_params.model是对后端用的也很有讲究。比如Ollama上的模型实际叫qwen3:8b你配置里写的是litellm_params: model: ollama_chat/qwen3:8b这里必须带ollama_chat/前缀如果只写qwen3:8bLiteLLM会尝试走OpenAI协议把请求发到默认的OpenAI地址而不是Ollama结果必然报错。排查方法是打开网关的debug日志看它实际转发到了哪个地址litellm --config config.yaml --port 4000 --debug日志里会明确打印出路由的目标URL一眼就能看出问题。6.3 网关端口被占用导致启动失败现象启动网关节时日志显示address already in use。这个最常见的原因是上一次启动的网关进程没有干净退出。用pkill -f litellm杀掉所有相关进程后再检查端口占用lsof -i :4000确认端口空了再启动。如果只是换配置重载不需要每次杀进程但如果你本地调试频繁建议写一个restart.sh脚本统一管理#!/bin/bash pkill -f litellm --config sleep 1 nohup litellm --config config.yaml --port 4000 gateway.log 21 echo Gateway restarted6.4 流式输出在部分客户端上不生效现象用curl加stream: true能正常看到流式输出但某些客户端工具比如一些Node.js库或者老版本SDK只拿到一次性返回。这个大多是客户端SDK版本问题跟网关关系不大。OpenAI兼容接口的流式规范已经非常成熟只要客户端支持stream_options或者SSE解析网关都能正常转发。如果遇到某个SDK不兼容可以检查网关日志里有没有SSE相关的报错。LiteLLM对流式转发的处理总体比较稳我实测用官方OpenAI Python SDK、LangChain、LlamaIndex都没问题。6.5 虚拟Key鉴权失败现象配置了master_key之后原来不带Authorization的请求全部报401。这是正常现象master_key一配置所有请求都需要鉴权。这时候你之前生成的虚拟Key就派上用场了。有一个容易踩的细节虚拟Key的生成和模型权限绑定如果你生成Key的时候只授权了qwen-local但请求的时候传的model是llama-local网关会拒绝。排查方法是用master_key先请求一次看看能不能通如果master_key能通而虚拟Key不能通就是Key的模型权限配置问题。6.6 本地网关和Docker网络互通问题如果你把网关跑在宿主机上但vLLM跑在Docker容器里注意容器端口映射和host地址的问题。在容器内部的程序访问宿主机服务时localhost是容器自己不是宿主机。要么你在容器启动时加了--networkhost要么就用host.docker.internal这个特殊域名来访问宿主机。这个坑在同时用Docker部署多个模型服务时很常见网关看到后端迟迟连不上第一反应是网络问题第二反应就是这种跨容器访问的地址问题。6.7 显存不足导致的进程崩溃最后说一个模型服务层面的坑。本地模型网关本身不吃太多显存但后端Ollama/vLLM会因为同时加载多个模型导致OOM。如果你在网关里注册了多个模型而调用方恰好同时请求了不同模型后端推理引擎可能因为显存不足直接崩溃。我的处理建议是如果你显存不够大比如8GB以下一次只加载一到两个模型其他模型用的时候再拉起来不用的时候Ollama会自动释放显存。另外可以在Ollama启动时限制并发大小OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve别贪多一次能用的模型数量少一点稳定性高很多。7. 还想补充的几个实用细节7.1 网关CLI在Windows环境下的差异我在Linux上用得最顺手但Windows终端也不是不能用。LiteLLM的Python包在Windows上运行没问题就是进程管理和信号控制不如Linux方便。Windows下用taskkill /F /IM litellm.exe杀进程或者干脆在PowerShell里用Stop-Process按进程号关。7.2 用systemd把网关做成开机自启服务如果你是在Linux服务器上常驻跑网关可以写一个systemd服务开机自动启动崩溃自动重启[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这样网关就成了一个真正的系统服务比你手动nohup要省心得多。7.3 结合现有网络架构做权限隔离既然聊到了网关就顺带提一个跟网络架构有关的经验。如果你的本地模型服务部署在公司或者工作室的局域网里而且旁边就是要对接政务网或者财务专线的机器我建议网关卡在NAT层后面网关单独用一个端口段模型服务本身只绑定内网IP不暴露到外网。网关是你所有模型请求的唯一入口同时它也是唯一需要进行访问控制的边界。这个思路和你设置固定网关地址、划分VLAN的思路是一样的网关收敛流量边界收敛风险。7.4 这是我个人最推荐的目录结构最后分享一个我实际用来管理这套网关的目录结构~/ai-gateway/ ├── config.yaml # 主配置文件 ├── gateway.log # 运行日志 ├── litellm.db # 调用记录数据库 ├── restart.sh # 重启脚本 └── models/ └── README.md # 记录每个模型的实际用途配置文件用Git管理每次改模型之前先备份。这些习惯看起来很简单但时间久了你会感谢自己当初的整理。我遇到过一个很现实的情况一个月前配置的模型我根本不记得它跑在哪个端口、哪个后端上全靠在models/README.md里的记录才想起来。这套本地大模型网关CLI的组合我大概用了三个月期间经历了Ollama崩溃、vLLM扩容、多个工具链切换模型等各种情况网关一直稳定地在中间层做路由和转译。如果你也在为本地多模型管理头疼可以按这篇文章里的思路逐步搭起来。先用一条命令把网关跑起来再慢慢把多模型路由、Key管理、日志统计这些东西加上去你会发现本地部署AI大模型这件事其实可以非常有条理。 LiteLLM网关CLI实战：统一管理Ollama与vLLM多模型
最近把本地跑的几套大模型服务统一收口到一个网关下面发现很多人还在用最原始的方式管模型——这个项目开个端口那个项目改个配置调用方写死IP和端口换个模型就要动代码。今天就把这套本地大模型网关的CLI使用方式完整写出来从为什么需要网关、怎么部署到日常命令、多模型路由、对接Codex CLI这类工具链再到我踩过的坑一次讲透。这篇东西适合谁看如果你本地同时跑了Ollama、LM Studio、vLLM好几个服务或者你正在用Codex CLI、Claude Code这类命令行编程工具但每次切换模型都要改环境变量、改配置文件那这篇文章能直接帮你省掉这些麻烦。就算你只有一个Ollama在跑网关也能给你带来日志审计、Key管理、模型路由这些单靠Ollama拿不到的能力。1. 先解决一个根本问题本地模型多了以后到底乱在哪1.1 单机多模型服务的现实困境我先描述一个很多本地部署玩家都遇到过的场景。你的电脑上可能同时装了Ollama用来跑Qwen系列的模型装了LM Studio用来跑一些GGUF格式的社区模型还可能在Docker里挂了一个vLLM服务用来做高并发的推理测试。这三个服务各自为政Ollama默认监听11434端口LM Studio默认的是1234端口vLLM如果你不指定默认是8000端口问题马上来了。你今天写了一个Python脚本调用Llama 3.1用的是http://localhost:11434/v1的地址明天想切到LM Studio里那个微调模型就要把代码里的base_url改成http://localhost:1234/v1顺便还要确认LM Studio已经开启了本地服务器。后天想试试vLLM的并发能力又要改一遍。这在只有一两个模型的时候还能忍一旦模型超过五个这边改代码、那边查端口纯粹是浪费时间。1.2 网关本质上做了一件什么事网关这个东西做网络的同学肯定不陌生本质上就是一个反向代理加一层控制面。你所有的模型请求先打到网关网关根据你配置的规则决定把请求转发给后端的Ollama、LM Studio还是vLLM。这样做有一个立竿见影的好处调用方永远只需要面对一个地址、一个端口、一套鉴权体系。你换模型、加模型、升级后端推理引擎调用方完全感知不到。就像你家里用路由器上网你不需要关心数据包到底走的是电信还是联通的光猫你只知道自己的电脑填了192.168.1.1这个网关地址。在本地大模型这个场景里网关把“模型路由”“Key管理”“调用日志”“负载均衡”这些事情全部收口了。调用方拿到的永远是一个标准的OpenAI兼容接口地址后面是什么推理引擎跟调用方没关系。1.3 本地场景下网关CLI比Web UI更实用现在市面上有不少带Web管理界面的AI网关项目比如One API、new-api这类界面做得确实漂亮点鼠标就能配置模型和渠道。但如果你是在命令行环境下工作或者你习惯用SSH连到一台无显示器的开发机上管理模型服务Web UI反而成了累赘。CLI的价值在于可脚本化、可远程、可集成进你现有的shell工作流。你可以写一个gateway model list去查看当前所有模型的状态可以在~/.zshrc里加一个alias一键切换默认模型可以写个cron脚本在模型服务挂掉之后自动重启并重新注册路由。所以这篇文章我讲的命令全都是终端里能直接敲的。从安装到配置从调模型到排查问题全程不碰浏览器。2. 从零搭建网关CLI和本地模型服务的正确连接方式2.1 底层的模型服务还是得先跑起来网关只负责路由不负责推理。所以在配置网关之前你得先把底层的模型服务趟好。我目前的主力方案是Ollama加一个vLLM容器简单说下我的初始状态Ollama跑在http://127.0.0.1:11434上面挂了qwen3:8b和llama3.1:8bvLLM容器映射到http://127.0.0.1:8000加载的是我自己转换的一个量化模型先把这两个服务分别测通确认单独调用没问题curl http://127.0.0.1:11434/v1/models curl http://127.0.0.1:8000/v1/models这一步千万别跳过。很多人在配置网关的时候遇到“model not found”之类的问题最后排查下来发现根本不是网关的锅是后端模型服务压根没起来或者端口填错了。基础服务没有自测通过之前不要去碰网关。2.2 安装网关CLI我用的网关是LiteLLM它同时提供Python包和CLI工具对OpenAI兼容接口的支持做得最完善。安装很简单pip install litellm[proxy]装完以后验证一下版本litellm --version如果你不想用LiteLLMOne API也有命令行工具但我个人建议新手直接上LiteLLM原因是它的配置语法和OpenAI的模型命名规则高度一致学习成本低而且社区活跃度高遇到问题容易搜到解决方案。提示LiteLLM的CLI是在litellm包基础上的如果之前装过旧版建议先pip install -U litellm升级到最新版有些命令参数在新老版本之间不兼容。2.3 通过CLI直接启动一个网关实例LiteLLM最简单的启动方式是直接用命令行参数指定要代理的模型litellm --model ollama_chat/qwen3:8b --port 4000这条命令的意思是在4000端口起一个OpenAI兼容的代理服务把请求路由到Ollama上的qwen3:8b这个模型。启动之后终端里会看到网关的地址通常是http://0.0.0.0:4000。这时候你本地就有了一个统一的模型入口。但这样一条命令只代理了一个模型离“网关”还差得远。真实的用法是把所有模型写进一个配置文件然后一条命令全部加载。我下面详细说。2.4 用配置文件统一管理多个模型在项目目录下创建一个config.yaml内容长这样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这里有几个设计意图需要解释一下model_name是你暴露给调用方的名字可以随意起比如qwen-local。调用方只认这个名字不关心后端到底是Ollama还是vLLM。litellm_params.model是实际转发给后端时用的模型标识。ollama_chat/前缀告诉LiteLLM走Ollama的chat接口openai/前缀告诉它走OpenAI兼容的chat接口。最后一个vLLM的配置里api_key填了什么不重要但必须填一个非空字符串因为LiteLLM在转发OpenAI兼容协议的时候默认会在请求头里带上AuthorizationvLLM如果配置了鉴权就会校验哪怕只是个dummy key也要占位。然后启动网关litellm --config config.yaml --port 4000看到日志里出现Uvicorn running on http://0.0.0.0:4000就说明成了。2.5 快速验证链路是否打通用标准OpenAI SDK来验证一下网关是否正常工作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传什么都可以只要你的网关没有开启鉴权。如果返回了正常的回复说明整条链路已经跑通SDK - 网关 - Ollama - 模型 - 返回。到这一步你已经把多个模型收口到了同一个端口。接下来的内容才是网关真正值钱的地方。3. 网关CLI的日常操作这些命令你必须烂熟于心3.1 查看已注册的模型列表和健康状态启动网关之后最常用的操作就是查看当前有哪些模型可用。LiteLLM提供了/v1/models接口但也有对应的CLI查询方式不过说实话CLI层面最实用的还是直接curl一记curl http://127.0.0.1:4000/v1/models返回的JSON里会列出所有通过配置文件注册的模型名。如果你配置了多个后端这里都会一并展示。但有些网关工具的健康检查不在这个接口里。比如LiteLLM有专门的/health/readiness和/health/liveliness接口你可以用curl验证网关本身是否活着的curl http://127.0.0.1:4000/health/liveliness我习惯在shell配置里写一个简短的alias方便随时看模型状态alias gwmcurl -s http://127.0.0.1:4000/v1/models | python3 -m json.tool这样在终端敲gwm就能看到当前所有可用模型比翻日志不知道方便到哪里去了。3.2 从命令行直接发起一次模型调用有时候不想写Python脚本就想在终端里快速测一下某个模型是否正常响应。用curl加网关地址就够了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来测试流式输出是否正常。CLI模式还有一个隐藏好处配合jq可以快速提取关键字段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实测下来这套组合拳在验证模型连通性的时候效率极高不用打开任何编辑器一条命令搞定。3.3 动态添加和移除模型不用重启网关配置文件的好处是持久化但缺点是你改完配置得重启网关才能生效。好在LiteLLM提供了运行时管理接口可以通过HTTP请求动态添加模型。添加模型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接口参数类似。这个功能我实际用下来最典型的场景是临时加载一个微调模型测效果测完直接删掉不需要为了一个临时实验去改配置文件。3.4 查看请求日志和token消耗网关的另一个价值在于日志。没有网关的时候Ollama自己也能看日志但那只是Ollama一个服务的访问日志。有了网关之后你可以在一个地方看到所有模型的调用记录、token消耗、响应延迟。LiteLLM的日志默认输出到终端stdout但你可以配置写入文件或者接入Prometheus监控。我本地的做法是配了一个简单的JSON日志文件方便后期用量分析在config.yaml里加上:general_settings: master_key: sk-1234 database_url: sqlite:///litellm.dbmaster_key是用来管理网关的超级密钥配置之后所有管理接口比如动态添加模型都需要带上这个Key才能访问。database_url是配置SQLite数据库这样LiteLLM会把每次调用的完整记录持久化到本地数据库方便以后查询“我上周到底调了多少次Qwen模型”。查询历史用CLI方式不直接我一般直接连SQLitesqlite3 litellm.db SELECT model, total_tokens, completion_tokens, prompt_tokens, response_time FROM LiteLLM_SpendLogs ORDER BY id DESC LIMIT 20;这个表格记录了每次请求的模型名、输入token、输出token、响应耗时。有了这个数据你就能算清楚本地跑模型的实际花销——虽然本地推理不花钱但token量和响应时间的统计对调优模型选择非常有价值。3.5 配置热更新和优雅关闭改完config.yaml之后不需要先kill再启动LiteLLM支持给主进程发送信号来完成优雅重载。在启动网关的终端里按CtrlC是直接停止更规范的做法是找到进程号然后发一个SIGHUP信号kill -HUP $(pgrep -f litellm --config)不过实测下来这个方式的可靠性跟版本有关有些版本对SIGHUP的支持不太好。如果你发现重载后模型列表没变化最稳妥的方式还是先停止网关再重新启动# 停止 pkill -f litellm --config # 重新启动 litellm --config config.yaml --port 4000启动命令你可以写成一个shell脚本或者用nohup让它后台常驻nohup litellm --config config.yaml --port 4000 gateway.log 21 这就是一个标准的常驻服务了终端关闭也不影响。4. 多模型路由与调度网关比单纯反向代理多出来的能力4.1 按模型名精确路由是基础能力前面配置的model_name其实已经是路由规则了。调用方请求qwen-local网关就转发到Ollama上的Qwen模型请求vllm-local就转发到vLLM上的模型。这叫“按模型名路由”是网关最基础的能力。但只有这个还不值得专门搭一个网关。你直接记端口也能做到。4.2 同模型多后端负载均衡和fallback现实中的场景是你同一个模型可能部署了多个副本比如Ollama上有一个量化版本vLLM上有一个原版精度版本。你希望请求优先打到某个后端如果它挂了就自动切换到另一个。这在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两个条目的model_name都是qwen-router但后端不同。LiteLLM会自动在这两个后端之间做负载均衡如果一个后端返回错误它会自动尝试另一个。这就实现了对调用方透明的高可用。你调qwen-router这个模型永远不需要关心当前Ollama是否挂了。有一次我Ollama进程因为显存不足直接崩了而我的代码还在正常跑因为网关自动把请求全部路由到了vLLM。这个体验没有网关的时候是做不到的。4.3 按成本或延迟路由本地场景下的取舍LiteLLM企业版支持基于成本预算或者延迟指标来做路由不过本地部署场景用不到那么重的东西。我更推荐的做法是根据任务类型手动分模型。比如我自己的用法是日常聊天、代码生成这类交互式任务走Ollama上的qwen3:8b因为响应快批量跑测试用例、批量文本分类这类不要求实时的任务走vLLM上的qwen2.5-14b因为精度更高、并发吞吐更大。在网关层面我维护两套模型名qwen-local-fast和qwen-local-heavy调用方按需选择。这比在代码里写死两个base_url要干净得多。4.4 配置模型组和优先级策略有些网关工具支持模型组的概念一个模型组下面挂多个模型实例并配置权重或者优先级。LiteLLM对权重的支持是通过router_settings来实现的配置方法是在config.yaml里加一段router_settings: routing_strategy: usage-based-routing model_group_alias: fast-models: [qwen-local, llama-local]这里的model_group_alias给fast-models取了一个别名调用方请求fast-models的时候网关会按策略从组里选一个模型。实测下来这种分组策略在你同时维护多个同量级模型、想交替验证不同模型效果的时候特别好用。你今天想试Qwen明天想试Llama调用方代码一行不用改只要改别名指向的组内模型就行。4.5 多Key管理与调用溯源网关还能帮你做多Key管理这一点在多人共用一台开发机、或者多个项目共用一个本地模型服务的时候特别关键。LiteLLM配置了master_key之后你可以给每个项目或者每个开发者发一个独立的虚拟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里会有一个新的key这个Key只能访问qwen-local这一个模型而且有1000美元的预算上限本地场景可以换成你自己定的token上限。好处非常实际项目A的Key出了问题、调用量暴涨你直接删掉那个Key就行不影响其他项目的正常使用。而且从日志表格里能看到每个Key的调用记录排查问题的时候可以精确追溯“是哪个项目在疯狂调模型”。5. 让Codex CLI、Dify这类周边工具统一走网关5.1 为什么周边工具都要走网关而不是直连Ollama如果你的周边工具链是Codex CLI、Claude Code、Dify这类它们默认都支持配置自定义的模型服务地址。很多人直接填Ollama的地址这能用但有两个问题第一Ollama的API只支持Ollama自己管理的模型你想让Codex CLI用一个跑在vLLM上的模型就做不到了。第二每个工具都要单独配一份模型信息换模型要改N个地方。正确的姿势是所有工具全部指向网关工具层面的模型名统一填网关里的model_name。这样你换底层的模型服务对工具完全透明。5.2 Codex CLI接入本地网关Codex CLI是OpenAI出的终端编程助手默认走OpenAI云端服务。要让它的请求走本地网关需要修改它的配置文件。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然后在环境变量里设置LOCAL_GATEWAY_KEY随便填一个非空字符串export LOCAL_GATEWAY_KEYsk-local配置完后启动Codex CLI让它使用本地providercodex --provider local实测下来Codex CLI在代码补全、简单代码生成这类任务上用本地8B模型确实能跑通响应速度取决于你的显存和模型大小。如果用的是14B以上模型响应会慢一些但对简单任务影响不大。5.3 Claude Code这类工具走网关的思路Claude Code是Anthropic的命令行工具它默认走Anthropic的API地址但同样支持自定义。它的配置文件里可以设置ANTHROPIC_BASE_URL环境变量指到网关。需要注意的一点是Claude Code走的是Anthropic协议而网关对外暴露的是OpenAI兼容接口。如果你要接Anthropic协议的工具需要网关层也支持Anthropic格式的转发。LiteLLM的/v1/messages接口可以兼容一部分Anthropic格式但实测下来有一定差异不是所有模型都能完美适配。我的建议是如果你主力用Claude Code就不要强行让它走本地模型了本地模型在复杂代码任务上的表现和云端大模型差距还是明显的。本地网关更适合接那些本身就用OpenAI协议的工具比如Codex CLI、Dify、各种自建应用。5.4 Dify接入本地网关Dify是一个很好用的AI应用开发平台支持配置自定义模型供应商。如果你用Dify操作本地部署的AI大模型官方有Ollama集成但为了统一管理我建议在Dify里配置OpenAI-API-compatible的供应商。在Dify的“设置 - 模型供应商 - OpenAI-API-compatible”里填写API Base URLhttp://127.0.0.1:4000/v1API Key你给Dify单独生成的虚拟KeyModel IDqwen-local就是网关里的模型名这样Dify上搭建的应用底层模型全走网关后续你想把某个应用从Qwen切到Llama只需要在Dify后台改模型ID或者干脆在网关层调整路由策略应用完全不用动。这里也能看出来做程序化开发或者AI应用集成的人网关联动的负载均衡和模型别名机制真的能省很多事。5.5 为远程开发场景开放网关端口本地模型跑在一台服务器上你人在笔记本上想通过CLI调用这时候需要让网关监听非回环地址。启动参数里把--host改成0.0.0.0litellm --config config.yaml --port 4000 --host 0.0.0.0这时候网关会监听所有网络接口局域网内其他设备就能通过http://你的服务器IP:4000/v1来访问。但这里有个安全意识要提醒如果不加鉴权内网任何人都能白嫖你的模型资源甚至通过SSRF风险点探测你内网的其他服务。所以开放网络访问之前务必在config.yaml里配置好master_key并且调用方都要带上正确的Authorization头。6. 踩坑记录网关CLI实战中我遇到的那些问题6.1 最常见的问题模型请求超时现象调用网关接口时模型迟迟不返回最后报超时错误。排查链路第一步确认后端模型服务是否正常。直接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}如果这里就超时说明问题在后端可能是模型正在加载、显存不足导致计算极慢或者Ollama的并发队列塞满了。第二步如果后端正常看是不是网关的request_timeout配置太短。LiteLLM默认超时是600秒正常不会触发但如果你改过配置把这个值调小过长文本生成就会频繁超时。第三步看网关日志里有没有Connection reset或者Read timeout之类的错误。如果有检查后端服务的并发配置比如Ollama默认OLLAMA_NUM_PARALLEL可能限制并发数请求排队超过一定量就会拖垮响应时间。6.2 模型名对不上导致404或者400现象调用网关时报model not found。这个坑绝大多数人都踩过。原因通常是model_name和实际的litellm_params.model搞混了。网关对外只认model_name你配置里写的是什么调用方就必须传什么而litellm_params.model是对后端用的也很有讲究。比如Ollama上的模型实际叫qwen3:8b你配置里写的是litellm_params: model: ollama_chat/qwen3:8b这里必须带ollama_chat/前缀如果只写qwen3:8bLiteLLM会尝试走OpenAI协议把请求发到默认的OpenAI地址而不是Ollama结果必然报错。排查方法是打开网关的debug日志看它实际转发到了哪个地址litellm --config config.yaml --port 4000 --debug日志里会明确打印出路由的目标URL一眼就能看出问题。6.3 网关端口被占用导致启动失败现象启动网关节时日志显示address already in use。这个最常见的原因是上一次启动的网关进程没有干净退出。用pkill -f litellm杀掉所有相关进程后再检查端口占用lsof -i :4000确认端口空了再启动。如果只是换配置重载不需要每次杀进程但如果你本地调试频繁建议写一个restart.sh脚本统一管理#!/bin/bash pkill -f litellm --config sleep 1 nohup litellm --config config.yaml --port 4000 gateway.log 21 echo Gateway restarted6.4 流式输出在部分客户端上不生效现象用curl加stream: true能正常看到流式输出但某些客户端工具比如一些Node.js库或者老版本SDK只拿到一次性返回。这个大多是客户端SDK版本问题跟网关关系不大。OpenAI兼容接口的流式规范已经非常成熟只要客户端支持stream_options或者SSE解析网关都能正常转发。如果遇到某个SDK不兼容可以检查网关日志里有没有SSE相关的报错。LiteLLM对流式转发的处理总体比较稳我实测用官方OpenAI Python SDK、LangChain、LlamaIndex都没问题。6.5 虚拟Key鉴权失败现象配置了master_key之后原来不带Authorization的请求全部报401。这是正常现象master_key一配置所有请求都需要鉴权。这时候你之前生成的虚拟Key就派上用场了。有一个容易踩的细节虚拟Key的生成和模型权限绑定如果你生成Key的时候只授权了qwen-local但请求的时候传的model是llama-local网关会拒绝。排查方法是用master_key先请求一次看看能不能通如果master_key能通而虚拟Key不能通就是Key的模型权限配置问题。6.6 本地网关和Docker网络互通问题如果你把网关跑在宿主机上但vLLM跑在Docker容器里注意容器端口映射和host地址的问题。在容器内部的程序访问宿主机服务时localhost是容器自己不是宿主机。要么你在容器启动时加了--networkhost要么就用host.docker.internal这个特殊域名来访问宿主机。这个坑在同时用Docker部署多个模型服务时很常见网关看到后端迟迟连不上第一反应是网络问题第二反应就是这种跨容器访问的地址问题。6.7 显存不足导致的进程崩溃最后说一个模型服务层面的坑。本地模型网关本身不吃太多显存但后端Ollama/vLLM会因为同时加载多个模型导致OOM。如果你在网关里注册了多个模型而调用方恰好同时请求了不同模型后端推理引擎可能因为显存不足直接崩溃。我的处理建议是如果你显存不够大比如8GB以下一次只加载一到两个模型其他模型用的时候再拉起来不用的时候Ollama会自动释放显存。另外可以在Ollama启动时限制并发大小OLLAMA_NUM_PARALLEL1 OLLAMA_MAX_LOADED_MODELS1 ollama serve别贪多一次能用的模型数量少一点稳定性高很多。7. 还想补充的几个实用细节7.1 网关CLI在Windows环境下的差异我在Linux上用得最顺手但Windows终端也不是不能用。LiteLLM的Python包在Windows上运行没问题就是进程管理和信号控制不如Linux方便。Windows下用taskkill /F /IM litellm.exe杀进程或者干脆在PowerShell里用Stop-Process按进程号关。7.2 用systemd把网关做成开机自启服务如果你是在Linux服务器上常驻跑网关可以写一个systemd服务开机自动启动崩溃自动重启[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这样网关就成了一个真正的系统服务比你手动nohup要省心得多。7.3 结合现有网络架构做权限隔离既然聊到了网关就顺带提一个跟网络架构有关的经验。如果你的本地模型服务部署在公司或者工作室的局域网里而且旁边就是要对接政务网或者财务专线的机器我建议网关卡在NAT层后面网关单独用一个端口段模型服务本身只绑定内网IP不暴露到外网。网关是你所有模型请求的唯一入口同时它也是唯一需要进行访问控制的边界。这个思路和你设置固定网关地址、划分VLAN的思路是一样的网关收敛流量边界收敛风险。7.4 这是我个人最推荐的目录结构最后分享一个我实际用来管理这套网关的目录结构~/ai-gateway/ ├── config.yaml # 主配置文件 ├── gateway.log # 运行日志 ├── litellm.db # 调用记录数据库 ├── restart.sh # 重启脚本 └── models/ └── README.md # 记录每个模型的实际用途配置文件用Git管理每次改模型之前先备份。这些习惯看起来很简单但时间久了你会感谢自己当初的整理。我遇到过一个很现实的情况一个月前配置的模型我根本不记得它跑在哪个端口、哪个后端上全靠在models/README.md里的记录才想起来。这套本地大模型网关CLI的组合我大概用了三个月期间经历了Ollama崩溃、vLLM扩容、多个工具链切换模型等各种情况网关一直稳定地在中间层做路由和转译。如果你也在为本地多模型管理头疼可以按这篇文章里的思路逐步搭起来。先用一条命令把网关跑起来再慢慢把多模型路由、Key管理、日志统计这些东西加上去你会发现本地部署AI大模型这件事其实可以非常有条理。