当团队同时使用本地大模型、云端模型和不同业务模型时，应用往往需要维护多套地址、鉴权方式与调用逻辑，后续还会遇到成本难统计、权限难隔离、流量难控制等问题。将 Ollama 放在模型运行层，再以 LiteLLM 作为统一网关，可以把模型访问、路由、鉴权和配额管理集中到一个入口中，让现有应用以接近 OpenAI API 的方式调用不同模型。🚀
一、整体架构与适用场景
Ollama 负责下载、运行和管理本地模型，并提供 HTTP API。LiteLLM 位于应用与 Ollama 之间，对外暴露统一接口，对内根据模型别名、路由规则和可用状态转发请求。业务应用不再直接访问 Ollama 的 11434 端口，而是统一调用 LiteLLM Proxy，例如通过 4000 端口访问聊天补全接口。
这种组合适合内部知识问答、研发助手、内容生成、模型评测和混合云 AI 平台。开发环境可以优先调用本地模型，降低外部依赖；生产环境则可以按任务类型选择本地或云端模型，并通过回退策略提高可用性。Ollama 已提供部分 OpenAI API 兼容能力，具体支持范围可查看 Ollama 官方文档。
二、准备 Ollama 与本地模型
首先安装并启动 Ollama，然后拉取准备使用的模型。模型名称应根据实际硬件资源、上下文需求和授权条件选择，不建议仅凭参数规模判断效果。完成下载后，可先直接访问 Ollama API，确认模型能够正常返回结果。
ollama pull qwen3:8b
ollama list
ollama serve
默认情况下，Ollama 服务通常监听本机 11434 端口。如果 LiteLLM 与 Ollama 分别运行在不同容器或主机上，需要确保网络连通，并避免在配置中误用 localhost。容器访问宿主机时，可按操作系统和容器网络情况使用宿主机地址、服务名或 host.docker.internal。🔌
三、配置 LiteLLM 统一模型入口
安装 LiteLLM Proxy 后，可以在配置文件中声明模型列表。对外的 model_name 是业务使用的稳定别名，对内的 model 则指向真实提供方和模型。例如，业务只需要认识 local-chat，而无需了解底层究竟运行哪个 Ollama 模型。
model_list:
- model_name: local-chat
litellm_params:
model: ollama/qwen3:8b
api_base: 来源链接
general_settings:
master_key: sk-local-admin
随后使用配置文件启动代理：
litellm --config config.yaml --port 4000
客户端调用时，将基础地址改为 LiteLLM，并在请求头中携带网关密钥。LiteLLM Proxy 的定位、配置方式和接口能力可参考 LiteLLM AI Gateway 文档。统一入口最大的价值不是少写几行代码，而是让模型替换、权限控制和策略调整不再侵入业务系统。
四、实现多模型路由与故障回退
如果同一别名配置多个部署，LiteLLM 可以在这些部署之间执行路由。实践中可为“快速问答”“复杂推理”“代码生成”等场景分别设置逻辑模型名，再将每个逻辑名称映射到一个或多个真实模型。这样既能避免客户端随意指定底层模型，也便于后续调整模型组合。🧭
- 按能力划分：为聊天、代码、向量化和视觉任务设置不同别名。
- 按环境划分：测试环境优先使用本地模型，生产环境配置更严格的回退链路。
- 按成本划分：普通请求走低成本模型，高价值或高难度任务再进入能力更强的模型。
- 按可用性划分：主模型超时或不可用时，自动切换到备用部署。
路由策略上线前，应通过并发测试观察首个 Token 延迟、总响应时间、显存占用和失败率。若本地机器只能稳定运行少量并发任务，盲目增加路由节点并不会提升吞吐，反而可能触发频繁换入换出或内存不足。
五、调用配额与权限管理
统一网关还可以通过虚拟密钥、用户、团队或模型访问范围实施配额管理。管理员可为不同项目签发独立密钥，并限制允许调用的模型、预算周期、请求速率或 Token 速率。达到限制后，由网关统一拒绝请求，而不是让各业务系统分别实现限流逻辑。🔐
- 使用主密钥完成管理操作，不要把主密钥下发给普通客户端。
- 为每个团队或应用创建独立虚拟密钥，避免多人共享同一凭据。
- 设置允许访问的模型列表，阻止客户端绕过业务分级策略。
- 结合 RPM、TPM 和预算周期设置限制，并为关键业务保留合理余量。
- 定期检查调用日志，识别异常高频请求、重复请求和模型滥用。
需要注意的是，本地 Ollama 模型通常没有真实的云端账单，但仍然消耗 GPU、内存、电力和运维资源。如果要使用金额预算，应先确认 LiteLLM 能否识别对应模型价格，或按照官方方式维护自定义成本信息。否则，更适合优先使用请求次数、Token 数量和并发限制来衡量本地资源消耗。
LiteLLM 支持按提供方和时间周期追踪预算，并可在多实例部署中借助 Redis 共享状态；相关配置和限制应以 预算路由官方说明为准。配额不应只设置一个总额，建议同时建立团队级、密钥级和模型级边界，避免单个异常应用占满全部资源。
六、生产部署中的关键细节
生产环境不要直接暴露 Ollama 端口，应只开放 LiteLLM 网关，并通过防火墙、反向代理或内部网络限制访问范围。主密钥、数据库密码和 Redis 凭据应放入环境变量或密钥管理系统，不要写入公开仓库。
此外，应为请求设置合理的连接超时、模型超时和重试次数。重试过多可能让一次故障放大为多次推理任务，造成资源雪崩。日志中可以记录模型别名、Token 使用量、耗时、状态码和请求来源，但应避免保存敏感提示词、个人信息及未经脱敏的业务数据。📊
总结
Ollama 与 LiteLLM 的组合能够形成清晰的分层架构：Ollama 专注本地模型运行，LiteLLM 负责统一协议、模型路由、访问控制和配额治理。落地时应先完成单模型连通，再逐步增加别名路由、备用模型、虚拟密钥和预算限制。相比让每个应用直接连接模型服务，这种网关化方案更便于维护、审计和扩展，也为未来接入更多本地或云端模型保留了统一入口。✅
