AI 学习笔记（十）：本地模型与云模型怎么协作，别把它做成二选一

前几篇我们把 API 接入、Provider 路由、MCP 和开发工具自动化串起来了，接下来进入 Phase 4。
这一阶段最容易遇到的一个问题是：本地模型和云模型到底怎么选？

很多讨论一上来就问“要不要全面切本地”，或者“是不是继续全走云 API 就行”。
但从工程落地看，这个问题通常就问错了。真正该问的是：
哪些任务更适合放本地，哪些任务更应该交给云，以及两边怎么协作才稳。

对大多数团队来说，本地和云不是替代关系，而是分工关系。
本地负责低成本、低风险、可控性更强的任务，云负责高质量推理、长上下文、多模态和外部可用性。
把这条边界画清楚，系统才不会一会儿成本爆掉，一会儿效果塌掉。

1. 先别问“选谁”，先问“任务属于哪一层”

我现在更推荐把 AI 任务先按 3 层拆开：

1. 轻任务
   比如分类、摘要、改写、关键词提取、简单代码解释、局部知识检索后的整理。
2. 中任务
   比如基于固定上下文生成初稿、对一段 diff 做风险归纳、对多个候选结果做比较。
3. 重任务
   比如复杂规划、跨多文件推理、长上下文综合、多轮工具调用后的最终决策。

这个拆法的价值很大，因为它会直接决定你该把请求放哪边：

• 轻任务 很适合先放本地，尤其是批量、重复、对措辞精致度不敏感的场景
• 中任务 可以根据延迟、敏感性和峰值负载在本地与云之间切换
• 重任务 往往更适合交给云模型兜底，尤其是高难度推理和最终输出

一句话总结：

别拿同一把尺子衡量所有任务，先做任务分层，再做模型分工。

2. 哪些任务优先放本地，哪些任务优先上云

如果只讲原则容易空，我更建议直接按场景判断。

2.1 更适合本地的任务

下面这些任务，我通常会优先考虑本地模型：

• 仓库内文档总结、标签分类、文本清洗
• 本地知识库检索后的二次整理
• 对敏感上下文做初步处理，比如日志脱敏、字段归类、草稿生成
• 高频批处理任务，比如一批 issue 摘要、一批工单归档、一批文档元数据补全
• 开发阶段的本地实验和 prompt 调试

原因不是“本地一定更强”，而是这些任务通常更看重：

• 单次调用便宜
• 数据边界更可控
• 离线或弱网环境也能继续跑
• 结果不满意时可以更方便地反复试

如果只是个人开发机或小范围试验，像 Ollama 这种本地运行时已经足够顺手；如果已经有共享 GPU 资源，要做团队级推理层，自建 OpenAI-compatible 服务会更合适。这里的判断，是基于官方产品定位做的工程推导。

2.2 更适合云的任务

下面这些任务，我更倾向直接走云：

• 复杂推理、规划、评审和最终决策
• 超长上下文综合
• 多模态任务，比如图片理解、音频转写后的高质量总结
• 用户直接可见、错误成本高的最终回复
• 对稳定可用性和峰值吞吐要求更高的线上接口

原因也很直接：

• 云模型通常在能力上限和通用性上更强
• 托管服务天然省掉一部分模型部署、扩容、升级和监控成本
• 当任务结果直接影响用户体验时，质量收益往往比单次调用价格更重要

所以真正常见的架构不是“全本地”或者“全云”，而是：
大部分低风险请求在本地消化，少量高价值请求上云完成。

3. 一条更稳的协作方式：统一接口 + 路由层 + 云兜底

如果你已经做过上一阶段的 Provider Router，这一篇其实只是把路由条件再往前推一层。
不要让业务代码到处写 if useLocal ... else useCloud ...，更稳的做法是统一成一层“任务路由器”。

最小结构可以只有 4 个部分：

• Task Classifier：判断任务类型、敏感级别、时延预算、质量要求
• Model Router：决定走本地还是云
• Provider Adapter：屏蔽不同模型接口差异
• Fallback Policy：本地失败时是否升级到云，云超时后是否降级返回草稿

下面这个示例更接近真实项目里的决策方式：

type TaskInput = {
  taskType: 'classify' | 'summary' | 'draft' | 'review' | 'plan';
  hasSensitiveData: boolean;
  latencyBudgetMs: number;
  qualityTier: 'normal' | 'high';
};

function selectLane(input: TaskInput): 'local' | 'cloud' {
  if (input.hasSensitiveData && input.taskType !== 'plan') {
    return 'local';
  }

  if (['classify', 'summary'].includes(input.taskType) && input.latencyBudgetMs < 1500) {
    return 'local';
  }

  if (input.qualityTier === 'high' || ['review', 'plan'].includes(input.taskType)) {
    return 'cloud';
  }

  return 'local';
}

这段逻辑看起来很普通，但它比“所有请求统一打一处”更接近工程现实。
因为真正影响结果的，往往不是模型名字，而是：

• 任务复杂度
• 数据敏感性
• 延迟预算
• 错误成本

本地失败怎么办？常见做法不是直接报错，而是按策略升级：

1. 本地先跑轻量模型
2. 结果置信度不够或命中失败条件时，升级到云
3. 云侧产出最终结果，本地保留中间证据和日志

这就是我最推荐的协作姿势：
本地吃掉大多数“便宜且可控”的请求，云只处理“少量但关键”的请求。

4. 真正的成本问题，不只是“本地便宜、云更贵”

很多人对成本的理解还停留在“云按 Token 计费，本地不按 Token 计费，所以本地更省”。
这只说对了一半。

本地模型的成本更像固定成本：

• GPU 或显存资源
• 模型加载时间
• 推理服务维护
• 模型升级、监控、容量管理

云模型的成本更像弹性成本：

• 按请求和 Token 付费
• 峰值来了就多花，闲时不占机器
• 托管能力和高质量模型一起打包

所以如果调用量并不大，或者团队没有稳定 GPU 资源，本地未必更省。
反过来，如果你有大量重复、结构类似的内部任务，把它们全扔云上，账单也会很难看。

还有一个常被忽略的点是：云侧也不是只有“硬扛单价”这一种优化方式。
像 OpenAI 官方文档里提供的 Prompt Caching，就适合处理重复前缀很多的请求，能把一部分高频调用成本打下来。
这意味着工程取舍不是“本地省钱 / 云一定贵”，而是：

• 重复批处理很多时，优先让本地消化
• 需要更高质量但提示前缀高度重复时，优先把云侧缓存能力用起来
• 不确定量级前，先做真实流量统计，不要靠感觉拍板

5. 本地不只是“能跑起来”，还要考虑服务形态

本地模型常见有两种落地方式：

1. 单机本地运行时
   适合个人开发、原型验证、离线实验
2. 团队共享推理服务
   适合多个工具、多个任务入口统一复用

如果你只是自己在电脑上调试，用本地运行时先把流程打通最省事。
但如果已经出现下面这些信号，就该考虑把“本地”升级成真正的服务层：

• 多个脚本或工具都在重复接模型
• 不同人要共用同一套模型和参数
• 需要统一限流、日志、模型版本和回放能力
• 要和现有网关、权限、审计体系接起来

像 vLLM 官方文档里明确支持 OpenAI-compatible Server，这对团队很有价值。
它意味着你可以把“本地/自建模型能力”先包装成一层统一接口，再把业务调用层稳定下来。
后面无论你换模型、调量化、加缓存还是扩 GPU，业务代码都不用跟着抖。

6. 真落地时，别漏这 6 个工程细节

6.1 路由规则要显式，不要靠 prompt 自己猜

“如果敏感就别外发”“如果复杂就走强模型”这类规则，应该写在工程里，不要只写进提示词。

6.2 本地和云要有统一输出契约

哪怕两边底层模型不同，也要统一成相同的结果结构，比如：

• answer
• confidence
• reason
• usage
• lane

否则后面很难做回放、评估和自动切换。

6.3 本地失败不等于系统失败

本地超时、显存不够、模型没热起来，都属于正常工程故障。
要把“升级到云”设计成标准路径，而不是异常补丁。

6.4 敏感数据不要一刀切

不是所有数据都必须永远留在本地，更常见的是：

• 先在本地做脱敏或摘要
• 再把必要的最小上下文发到云

这样通常比“完全不上云”更实用，也比“整段原文全发云”更稳。

6.5 可观测性要能回答“为什么这次走了这条路”

至少记录：

• taskType
• lane
• model
• latencyMs
• tokenUsage 或本地推理时长
• fallbackTriggered

没有这些字段，后面很难复盘路由是不是合理。

6.6 先做评估闭环，再谈大规模替换

不要因为本地跑通了几个 demo，就急着把所有请求迁过去。
应该先拿真实任务集比较：

• 完成率
• 延迟
• 成本
• 人工修正率

只有这些指标站住了，本地替换比例才值得继续扩大。

7. 一条我更推荐的演进路线

如果你现在准备开始做“本地 + 云”的协作，我更建议按这个顺序推进：

1. 先挑一类轻任务放本地，比如分类、摘要、草稿整理
2. 保留云模型做最终兜底，不要一上来就断掉云
3. 做统一路由层，显式写下升级和降级条件
4. 接入日志和评估，观察命中率、质量和成本
5. 命中稳定后，再逐步扩大本地覆盖面

这条路线的重点不是“最快把云费用打下来”，而是：
先让系统可控，再让成本下降。

总结

本地模型和云模型的关系，最适合被理解成“分层协作”，而不是“二选一”：

• 本地负责高频、低风险、敏感或需要低边际成本的任务
• 云负责高质量推理、复杂决策和最终兜底
• 路由、降级、评估和可观测性决定这套协作能不能长期跑稳

如果你现在只做一件事，我最推荐的是：

先把任务分层，再把路由规则写进工程里。

这一步做好后，你会发现“本地和云怎么协作”其实不是模型问题，而是一个很典型的系统设计问题。

下一篇继续 Phase 4：怎么把本地模型真正接进知识库和 RAG 流程，而不是只停留在本机聊天。

参考资料

• Ollama Documentation
• Ollama API
• vLLM OpenAI-Compatible Server
• vLLM Quickstart
• OpenAI Prompt Caching

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-local-vs-cloud-model-collaboration-engineering-tradeoffs/