先说我最近在搞的一个事。我在项目里同时接了两条大模型链路一条是本地用 Ollama 跑的边缘推理另一条是云端大模型 API。一开始图省事所有请求全走云端结果月底一看账单直接肉疼而且线上业务时不时因为网络抖动超时。后面我干脆把路由层做成了一套双轨大模型路由正常时按任务类型和成本策略分发请求云端连续异常时自动把流量降级到本地 Ollama本地挂了也能反过来切回云端兜底。这套容灾降级架构落地之后调用成本降了接近一半可用性也稳了不少。这篇文章就是把我这段时间踩的坑、测的参数、改的代码逻辑都拆出来重点讲清楚三件事为什么本地和云端必须双轨共存、Ollama 在端侧部署时那些折磨人的细节、以及路由和降级到底怎么设计才不会在故障时二次踩雷。适合正在做个人知识库、智能体应用或者想把本地开源模型和付费云端模型揉进一套系统里用的同学。1. 双轨路由架构的整体设计思路1.1 为什么本地和云端不能“二选一”很多人一开始的想法很简单要么全部用云端 API要么全本地 Ollama 跑开源模型。我两个都试过结论是纯单轨方案在真实业务里都撑不住。全云端的问题是最明显的。费用是一方面更关键的是延迟和不确定性。我接的云端 API 虽然大部分时间响应不错但总会碰到“偶发毛刺”——某个时刻突然从 800ms 飙到 10 秒以上甚至直接 TCP 超时。对于个人项目可能忍忍就算了一旦接进自动化流程或者对外服务这种超时就是实打实的故障。另外还有数据隐私问题某些内部数据我不可能为了调个模型就丢给第三方 API。全本地的方案也有硬伤。首先是硬件天花板单机显存就那么多跑 7B 模型和 70B 模型完全是两个概念。本地跑小参数模型简单翻译、摘要、意图识别够用但复杂推理、长文档分析、代码生成的质量和云端大模型还有明显差距。其次是“单点故障”本地机器断电、显卡驱动崩了、硬盘满整个服务就哑火了。所以我最后做成了双轨默认走云端拿高质量结果本地 Ollama 作为边缘推理节点处理三类流量——需要低延迟的简单请求、含敏感数据的请求、以及云端不可用时的降级兜底。反过来如果本地 Ollama 挂了路由层也能临时把流量切回云端保证服务不中断。这套思路跟传统架构里的“主备容灾”类似但区别在于不是被动等故障而是主动把不同质量的请求分发到不同算力上属于“负载均衡 容灾降级”的混合体。1.2 路由层要解决的三个核心问题把双轨从概念变成代码路由层要回答的问题其实就三个请求往哪发、故障怎么判、切换怎么顺。请求往哪发。不是所有请求都值得调云端大模型。我已经把请求分了三类简单任务关键词提取、翻译、文本分类直接走本地小模型稳且快中等任务摘要、改写走本地大模型复杂任务长文分析、代码生成、多轮深度对话走云端。这个分级要能在运行时动态调整不能写死因为本地模型能力会随模型更新变化。故障怎么判。这里我走了不少弯路。一开始只靠单次请求超时来判断结果网络一抖动就疯狂切换切来切去比不切还糟。后来改成了“失败计数 熔断窗口”的机制连续失败达到阈值才切换切换后不是立即切回而是先放少量探活请求成功率恢复后才全额回归。这个机制参照了微服务里的熔断器模式但针对大模型场景做了简化。切换怎么顺。从云端切到本地不仅是换个 base_url 的事。云端 API 和本地 Ollama 返回的格式基本兼容但模型能力有差异同一个 prompt 在两边输出风格可能完全不同。所以降级发生时不能静默切换我会在响应里标记当前 provider 和 model同时通知调用方“当前处于降级模式”避免后续逻辑拿本地模型的弱输出去做强校验。1.3 技术选型为什么边缘节点选了 Ollama端侧跑模型的方案不少llama.cpp、vLLM、LocalAI、Ollama 我都试过。最后长期用的是 Ollama理由有三个。第一是 API 兼容性。Ollama 原生提供 OpenAI 兼容的/v1/chat/completions接口这意味着我能用同一套客户端代码同时打云端和本地路由层不需要为每个 provider 单独写适配。第二是模型管理太省心。ollama pull一条命令就能拉模型模型文件统一放在一个目录ollama list一目了然。对比 llama.cpp 手动下载 GGUF 再写启动脚本Ollama 的开箱体验确实好得多。第三是资源占用可控。Ollama 自带模型常驻内存调度OLLAMA_KEEP_ALIVE可以控制模型卸载时间空闲时自动释放显存。对于一台既要跑业务又要跑模型的边缘机器来说这个特性很关键。当然 Ollama 也有短板比如高并发场景的吞吐不如 vLLM 优化得深。但如果只是边缘推理、日均几千次请求的规模Ollama 完全够用。我在这台边缘节点上的配置是 16 核 CPU 24G 显存跑 7B 量化模型单请求延迟 200~500ms并发 4~8 路没问题。2. Ollama 端侧部署的完整实操2.1 Windows 下安装与 D 盘迁移Windows 上装 Ollama 有两种方式一是官网下载安装包双击安装二是下载命令行版本自己解压。我建议用安装包版省事。但有一个痛点常年被吐槽——默认装到 C 盘模型文件越拉越多C 盘很快爆掉。我实际测试下来模型文件默认存在当前用户目录下的.ollama\models里也就是C:\Users\你的用户名\.ollama\models。一个 7B 量化模型差不多 4~6GB多拉几个模型 C 盘就吃紧了。解决办法是在安装前先设置用户环境变量OLLAMA_MODELS把它指向 D 盘目录# 以管理员身份打开 PowerShell创建模型目录 mkdir D:\ollama\models # 设置用户环境变量永久生效 [Environment]::SetEnvironmentVariable(OLLAMA_MODELS, D:\ollama\models, User)设置完环境变量之后重新启动 Ollama要彻底退出托盘图标再重新打开再执行ollama list或者ollama pull模型就会写到 D 盘了。如果已经安装过了把C:\Users\你的用户名\.ollama\models里的文件整个复制到 D 盘目录再重启 Ollama 也是一样效果不会丢模型。另外建议把OLLAMA_HOST也顺手配一下默认是127.0.0.1:11434。如果 Ollama 要提供给局域网内其他机器用就设置成0.0.0.0:11434并注意防火墙放行。但这里提醒一句如果是生产环境暴露到公网一定要加认证或只在内网用否则别人可以直接调用你本地的模型服务。2.2 下载慢问题的处理网络热词里“ollama下载太慢了”出现频率极高这个问题我深有体会。ollama pull qwen2.5:7b在默认配置下能从官方源拖几个小时甚至中途断掉。问题的根子在模型文件分发上。Ollama 拉模型是从官方模型仓库下载官方源在国内的连通性不稳尤其是几个 GB 的大模型文件经常下到一半就断。我实测下来下载速度经常在几十 KB/s 到一两百 KB/s 之间徘徊完全没法忍。我最后稳定的解决方案有两个方案一手动下载模型文件。去模型托管站点把 GGUF 格式的模型文件下下来然后手动导入。下载时可以用支持断点续传的下载工具速度稳定很多。导入命令是# 把本地的 qwen2.5-7b-instruct-q4_k_m.gguf 注册成 Ollama 模型 ollama create qwen2.5-7b -f ModelfileModelfile 内容很简单核心就是告诉 Ollama 模型文件路径FROM ./qwen2.5-7b-instruct-q4_k_m.gguf TEMPLATE {{ if .System }}|system|{{ .System }}/s{{ end }}|user|{{ .Prompt }}/s|assistant|注意FROM指向的 GGUF 文件路径要写对ollama create执行成功后用ollama list就能看到模型了。方案二配镜像加速站。现在有不少社区维护的 Ollama 镜像站点原理是把官方模型仓库的内容同步到国内服务器通过修改环境变量指向镜像地址来加速。我实际测试过部分镜像站的速度能到几 MB/s比官方源强太多。这里提醒一句用镜像站时尽量选择可信来源注意核对模型文件的哈希值避免下到被篡改的文件。2.3 模型管理与 API 调用要点日常用得最多的几个 Ollama 命令我给整理出来了命令作用我的使用频率ollama list查看本地已安装的模型极高ollama pull model下载模型高ollama run model交互式对话测试高ollama show model查看模型参数和元信息中ollama stop model停止加载在显存里的模型中ollama serve启动服务端一般常驻偶尔排障用ollama run适合在命令行里快速验证模型效果但真正接业务是要走 API 的。Ollama 的 OpenAI 兼容接口路径是/v1/chat/completions调用示例如下curl http://127.0.0.1:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [ {role: user, content: 用一句话总结双轨路由架构} ] }注意model字段必须和ollama list里显示的名字完全一致否则会报 model not found。Python 端我习惯用requests直接打一套代码兼容云端和本地。核心就是base_url不同——云端填官方 API 地址本地填http://127.0.0.1:11434。还有一个环境变量你们一定会用到OLLAMA_KEEP_ALIVE。它控制模型在显存里驻留的时间默认 5 分钟。如果你的业务是“请求密集一阵、空闲半天”这种节奏建议把时间调长减少重复加载模型的开销# 模型加载后常驻 30 分钟 [Environment]::SetEnvironmentVariable(OLLAMA_KEEP_ALIVE, 30m, User)这个参数尤其重要因为冷启动加载一个 7B 模型可能要几十秒如果每次请求都触发加载整个服务的延迟会翻好几倍。设为 -1 可以无限常驻但会一直占着显存要根据机器实际内存来。3. 路由层与容灾降级的核心实现3.1 健康检查与状态判定路由层要做出正确的降级决策前提是有可靠的“健康感知”。我的实现里健康检查分两层主动探活和被动失败计数。主动探活是一个后台线程每隔 10 秒分别向云端 API 和本地 Ollama 发一个轻量请求比如“ping”或者一个空消息。连续 3 次探活失败就把该通道标记为不可用请求不再路由过去。探活成功恢复后通道重新标记为可用。被动失败计数是在真实请求上做统计。每个请求如果超时我设的云端超时是 15 秒本地是 60 秒失败计数加一请求成功计数清零。连续失败达到 3 次触发熔断立刻把流量切到另一条链路。这里有个细节值得强调熔断和恢复都不能“一拍脑门”。我最初踩过的坑是云端恢复后立刻切回结果恢复初期往往不稳定切回去又开始失败形成“抖动循环”。正确的做法是切回前先发几个探活请求成功率超过 60% 才逐步放流量。下面是我在 Python 里封装的双客户端类云端和本地接口风格一致class CloudClient: def __init__(self, api_key, base_url): self.api_key api_key self.base_url base_url def chat(self, messages, modeldeepseek-chat): url f{self.base_url}/v1/chat/completions headers {Authorization: fBearer {self.api_key}} payload {model: model, messages: messages, stream: False} resp requests.post(url, jsonpayload, headersheaders, timeout(3, 30)) resp.raise_for_status() return resp.json()[choices][0][message][content] class OllamaClient: def __init__(self, base_urlhttp://127.0.0.1:11434): self.base_url base_url def chat(self, messages, modelqwen2.5:7b): url f{self.base_url}/v1/chat/completions payload {model: model, messages: messages, stream: False} resp requests.post(url, jsonpayload, timeout(3, 120)) resp.raise_for_status() return resp.json()[choices][0][message][content]路由层里维护一个简单的状态机状态就是健康、降级、恢复探测三态。每次请求进来先分级再路由。3.2 降级策略与代码骨架降级策略可以概括成一句话用牺牲部分输出质量的代价换取服务不中断。所以降级不是“一条路走到黑”而是有梯度的。我实现的降级路径分三层第一层云端失败流量切到本地 Ollama。这是最常用的降级动作保证服务基本可用。第二层本地也失败流量切回云端重试一次。这避免本地单点问题导致的全盘不可用。第三层两边都失败返回一个明确的错误码并附上“当前大模型服务不可用”的提示而不是让调用方拿到超时异常自己去猜。降级触发时的代码骨架我用了一个很轻量的 Router 类class Router: def __init__(self, cloud_client, ollama_client): self.cloud cloud_client self.ollama ollama_client self.cloud_failed 0 self.ollama_failed 0 self.mode cloud # 当前主用通道 self.cloud_threshold 3 self.ollama_threshold 3 def chat(self, messages, task_typesimple): if self.mode cloud: try: result self.cloud.chat(messages) self.cloud_failed 0 return result, cloud except Exception: self.cloud_failed 1 if self.cloud_failed self.cloud_threshold: self.mode edge else: try: result self.ollama.chat(messages) self.ollama_failed 0 return result, edge except Exception: self.ollama_failed 1 if self.ollama_failed self.ollama_threshold: self.mode cloud # 兜底重试逻辑 try: if self.mode cloud: result self.ollama.chat(messages) else: result self.cloud.chat(messages) return result, fbackup-{self.mode} except Exception as e: raise RuntimeError(all channels unavailable) from e这段代码是简化版真实落地时还要加上并发控制、上下文窗口管理、请求日志等。但核心逻辑就这么多连续失败计数、模式切换、兜底重试。另外一个很容易忽略的点降级模式要尽量“无感”但也不该完全“无痕”。我每次在响应里带上 provider 信息和 model 信息这样日志里能查到某次回答到底是哪条链路生产的。如果输出质量有明显下降排查时一眼就能定位。3.3 成本与性能的平衡控制双轨路由不只是容灾省钱才是很多人的真实诉求。云端 API 按 token 计费本地 Ollama 电费加折旧几乎可以忽略。所以我把“分级路由”和“成本控制”绑定在一起让简单任务尽可能多地落在本地。我总结了一套非常实用的分流比例经验值任务类型路由目标典型模型成本占比关键词提取、文本分类本地 Ollama7B 量化模型约 5%摘要、改写、翻译本地 Ollama14B 量化模型约 15%代码生成、长文分析云端 API云端大模型约 60%失败降级流量自动切换任意可用通道约 20%当然这个比例不是写死的。我在路由层加了一个动态开关根据当月云端调用量自动调整本地分流比例——如果云端调用已经逼近预算就把更多的中等任务压到本地。还有一个重要的优化点是“重复请求缓存”。同一段 prompt 在短时间内多次调用结果往往差不多。我在路由层前面加了一个简单的内容哈希缓存命中的请求直接返回缓存结果不经过任何模型。这个改动把整条链路的调用量又降了 10% 左右值得做。延迟方面实测下来本地 7B 模型单 token 生成速度在 20~40 token/s 之间云端大模型在 30~60 token/s 之间两者其实接近。但本地少了网络往返首 token 延迟明显更低因此交互类应用我会优先把流量打给本地。4. 常见问题与排查实录4.1 Ollama 本地的经典报错先说最经典的一个Error: could not connect to Ollama server, run ollama serve to start it。这个报错出现时不要慌先确认三件事Ollama 后台服务是否在运行环境变量OLLAMA_HOST是否指向了正确的地址防火墙是否拦截了 11434 端口。我遇到过一种隐蔽情况——Ollama 已经启动但用的是旧配置改了OLLAMA_HOST之后没重启导致服务还在监听 127.0.0.1。其次是显存不足报错。当模型参数量太大或者并发请求太多时Ollama 会直接 OOM。我在一台 12G 显存的机器上跑 14B 模型开 8 并发就爆显存了。解决办法是换更小的量化版本或者设置OLLAMA_NUM_PARALLEL降低并发数让请求排队而不是同时抢显存。还有模型加载慢的问题。前面提到的OLLAMA_KEEP_ALIVE没配好时每次请求都要冷加载模型首请求延迟能到几十秒。我在真实业务里把OLLAMA_KEEP_ALIVE设成了 -1无限常驻同时在空闲时段用定时任务发一个探活请求保证模型常驻显存用户体验提升非常明显。4.2 云端 API 的异常与降级触发云端 API 的问题比较多样我按出现频率排了个序限流、超时、内容安全拦截。限流通常表现为 429 状态码当你并发超过 API 提供的 RPM 限制时就会出现。我的处理方式是路由层检测到 429 时不把错误计入熔断而是先做一次指数退避重试如果重试仍失败再触发降级。超时的情况最烦人。有一个坑是云端 API 首 token 延迟其实很高尤其是复杂 prompt可能几十秒才返回第一个 token。如果客户端超时时间设太短就会误判为失败。我把读取超时设在 30 秒但首 token 超时单设 60 秒避免误触发降级。内容安全拦截则是另一类问题——prompt 触发云端的审核机制接口返回 400 或者特定错误码。这种情况不是网络故障不需要降级但要在日志里做标记方便你调整 prompt 措辞。实际跑了一段时间后我把这些异常整理成了一张速查表现象可能原因排查步骤解决方案请求全部超时云端网络链路问题curl 测试 API 连通性触发降级到本地观察恢复偶发 429并发超限查看 API 配额退避重试调低并发本地连接被拒Ollama 服务未启动ollama serve查看日志重启服务检查端口模型加载慢冷启动 无 keep-aliveollama ps看显存设置 OLLAMA_KEEP_ALIVE输出质量下降降级到本地小模型查看响应 provider 字段标记降级模式恢复正常后切回4.3 路由层自身的坑最后说一个路由层自己制造的问题重试风暴。我最初实现重试逻辑时想得很简单降级后如果本地也失败就立刻切回云端重试。这个逻辑在单请求场景没问题但一旦系统里同时有上百个请求打进来所有请求在同一瞬间感知到云端失败并同时切到本地、再同时切回来这个“协调风暴”会让本就脆弱的网络雪上加霜。解决办法是给路由层的切换动作加“随机抖动”。切换前等待一个随机的 100~500ms让请求错峰流动。另外熔断器一旦触发后续请求直接快速失败而不是每个请求都去试一遍底层链路。这个“快速失败 集中探活”的模式是藏在高可用设计里的经典经验放到大模型路由场景同样适用。还有一个细节是“上下文窗口不一致”。云端模型和本地模型的上下文长度可能不同同一个 long context 请求在云端能过切到本地直接报超限。我的处理是降级时对超出本地窗口的内容做截断并在返回结果里标记 truncation 字段这样调用方知道结果不完整。5. 这套架构还能往哪里扩展5.1 多模型路由与任务自动匹配目前我只是在两条链路之间路由但路由层本身可以轻松扩展成多模型池。比如本地不只放一个模型而是放一个 7B 小模型负责简单任务、一个 14B 大模型负责中等任务。路由层根据任务分级把请求路由到对应的本地模型上进一步压低云端调用量。任务自动匹配是一个值得做深的方向。我在路由层里写了一个“任务画像”模块根据 prompt 长度、关键词、语言类型等特征估算任务复杂度。比如 prompt 里包含“总结这份文档”“分析代码”就自动判定为复杂任务走云端包含“翻译”“分类”就定位为简单任务走本地。这个画像基于规则暂时不需要用模型来做性价比很高。5.2 扩展Embedding 与知识库场景双轨路由不仅适用于对话模型Embedding 同样适用。我在知识库场景里常遇到一个问题文档向量化用云端 API量一大费用就很敏感。后来我把 Embedding 也接到了本地 Ollama 上用开源 embedding 模型处理简单文档全部本地搞定只有模糊查询和复杂检索才调用云端。这个改造对知识库类应用来说成本优化效果不亚于对话模型的双轨路由。5.3 扩展开发工具链的接入最近很多人喜欢用 Ollama 接 Codex、Claude Code 这类命令行编程工具。实际上就是把这些工具的模型提供方从云端切到本地 Ollama。配置方式不复杂核心是让工具能够访问到一个 OpenAI 兼容的 API 地址把这个地址指向本地http://127.0.0.1:11434并填一个任意非空的 API key 占位。这种方式适合日常小改动、简单补全遇到复杂需求再切回云端大模型。如果在这个场景继续做深同样可以套用本文的双轨思路——平时本地开发大任务自动切云端。最后分享两个小经验双轨路由这套东西做完之后我最大的体会是容灾降级不是“出了问题再想办法”而是一开始就要把“故障是常态”这个前提写进设计里。云端 API 再稳定也有毛刺本地机器再可靠也有断电的时候只有把两条链路都做成“随时可切换”的状态服务才能真正稳下来。最后再补充一个小技巧给路由层的每一条链路都加一个“人工开关”。线上跑着跑着你可能会发现某个模型最近输出质量异常但又不想直接改代码。我的做法是在路由配置中心放三个开关——云端启用、本地启用、强制降级模式。平时都是自动状态需要时可以手动切。这个开关在排障时真的是救命级的功能强烈建议大家提前加上。