小模型、本地模型和大模型 API 如何取舍
模型选择不是排行榜选择题。
很多团队会问：我们应该用小模型、本地模型，还是直接调用大模型 API？这个问题没有固定答案，因为模型选择从来不是只看“聪不聪明”。它同时涉及成本、延迟、质量、隐私、部署复杂度、上下文长度、工具能力、可观测性、缓存策略和产品体验。
对前端和全栈工程师来说，更实用的做法是建立一个决策框架：先看任务，再看约束，最后设计路由。不要让所有请求都走同一个模型，也不要为了“可控”把所有东西都搬到本地。
三类模型不是同一问题的答案
先把概念分清楚。
小模型通常指参数规模较小、推理成本更低、延迟更短的模型。它可以是云端 API，也可以部署在本地或私有环境。小模型不等于本地模型，也不等于质量差。它适合明确、窄域、可校验、高频的任务。
本地模型指运行在用户设备、企业服务器、边缘节点或自有 GPU 上的模型。它的核心价值是数据控制、离线能力、低边际成本和可定制部署。它可能是小模型，也可能是较大的开源模型。
大模型 API 指调用外部 Provider 提供的强模型服务。它的优势是能力强、升级快、上下文长、生态完整、工具和多模态支持成熟。代价是单次成本、网络依赖、数据合规和供应商锁定。
这三类选择关注点不同：
先按任务分类
模型选择首先取决于任务类型。
不要从“我们要用哪个模型”开始，而要从“这个任务需要什么能力”开始。
低风险、可校验任务适合小模型。例如意图识别、分类、语言检测、敏感词初筛、标题生成、标签提取、简单字段抽取。它们输入短、输出短、质量容易用规则验证，即使用小模型偶尔错了，也可以通过置信度、规则或 fallback 兜底。
中等复杂任务适合通用模型。例如普通摘要、客服草稿、知识库问答、文案改写、结构化整理。它们需要一定语言能力和上下文理解，但不一定每次都要最强模型。
高复杂任务适合强模型 API。例如跨文档推理、复杂代码修改、长上下文分析、多工具规划、法律或医疗等高风险解释、复杂多模态理解。这些任务的失败成本更高，不能只看单次价格。
隐私敏感任务适合本地或私有部署。例如企业内部文档、个人设备数据、离线场景、受监管行业、不能出域的数据处理。但要注意：本地部署解决的是数据控制问题，不自动解决质量、权限和安全问题。
用成本、延迟、质量做三角权衡
模型选择通常逃不开三角权衡：成本、延迟、质量。
便宜模型不一定总成本低。如果它让用户重复提问、让 JSON 经常失败、让人工审核增加，真实成本可能更高。
快模型不一定体验最好。如果它首 token 很快但回答质量差，用户会花更多时间纠正它。
强模型不一定值得。如果任务只是分类、抽取或短文本转换，强模型的能力浪费会变成账单。
所以模型选择不应该靠感觉，而应该用自己的业务样例测试：同一批 Eval case，在不同模型上比较准确率、格式通过率、延迟、成本和失败类型。
本地模型适合什么
本地模型最大的价值是控制权。
它适合这些场景：
- 数据不能出设备或内网。
- 用户需要离线能力。
- 请求量高且任务稳定，希望降低边际成本。
- 输出质量要求可被规则或人工校验。
- 企业希望私有化部署和审计。
- 前端或桌面应用需要低延迟的轻量能力。
例如，浏览器端或桌面端可以用本地模型做轻量摘要、输入改写、模糊搜索增强、隐私文本分类、草稿建议。服务端本地模型可以做批量分类、日志归因、文档预处理、Embedding 或简单抽取。
但本地模型也有现实代价：
- 模型下载和更新成本。
- 设备性能差异。
- 浏览器 WebGPU 兼容性。
- 内存和电量消耗。
- 首次加载时间。
- 推理速度不稳定。
- 质量和强模型仍有差距。
- 监控、日志和版本管理更复杂。
前端尤其要关注设备体验。本地推理可能让高端电脑表现很好，但在低配设备上卡顿、发热、耗电。用户不会区分“这是本地模型的问题”，他们只会觉得应用变慢。
大模型 API 适合什么
大模型 API 的优势是能力和速度进入生产。
它适合这些场景：
- 任务开放、复杂、变化快。
- 需要长上下文或强推理。
- 需要多模态能力。
- 需要稳定的工具调用和结构化输出。
- 团队不想自建推理基础设施。
- 希望持续获得模型升级。
- 需要跨语言、跨领域能力。
对早期产品来说，大模型 API 往往是最快的验证路径。你可以先把产品体验、上下文系统、Eval 和业务闭环做出来，再逐步把高频低难度任务迁移到小模型或本地模型。
它的主要风险也很明确：
- 成本随使用量增长。
- 供应商限流或故障。
- 数据合规和区域要求。
- 模型升级导致行为变化。
- 请求延迟受网络和 Provider 负载影响。
- 业务代码可能被 Provider 协议绑定。
因此，生产系统最好不要让业务逻辑直接依赖某个 Provider SDK。应该通过 AI Gateway 做内部协议、路由、fallback、日志和预算控制。
小模型适合做系统里的“基础工”
小模型最适合承担高频、低风险、可拆分的基础任务。
例如：
- 请求意图分类。
- 是否需要检索。
- 是否需要工具。
- 用户语言检测。
- 输入风险初筛。
- 简单字段抽取。
- 标题和摘要候选。
- 长文本预处理。
- RAG query 改写。
- Agent 下一步候选过滤。
这些任务如果全部交给强模型，会让成本被大量基础操作抬高。用小模型承担前置步骤，可以让强模型只处理真正需要强能力的请求。
但要警惕“小模型级联”。
如果一个流程为了省钱拆成 8 个小模型调用，最后总延迟可能更高，失败面更多，调试更困难。小模型应该简化系统，而不是把一次强模型调用变成一串脆弱的微调用。
路由比单选更重要
真实系统很少只选一种模型。
更常见的是多模型路由：
一个实用路由策略通常包含：
- task type：任务类型。
- input size：输入长度和上下文规模。
- risk level：失败影响。
- privacy level：数据是否允许出域。
- user tier：用户套餐和预算。
- latency SLA：是否实时交互。
- model health：供应商是否限流或故障。
- eval score：该任务在不同模型上的历史表现。
路由决策要写入日志。否则当用户投诉“这次回答变差了”，团队很难知道是模型变了、路由变了、上下文变了，还是缓存命中了旧结果。
缓存策略也会随模型变化
不同模型选择会影响缓存设计。
大模型 API 适合使用 prompt prefix cache、response cache、retrieval cache 和 tool result cache 来降低单次调用成本。特别是长 system prompt、工具定义和固定文档前缀，如果 Provider 支持 prompt caching，收益会很明显。
小模型因为单次便宜，未必值得为每个输出做复杂缓存。但它常用于高频前置任务，适合缓存分类结果、embedding、query rewrite 或中间标签。
本地模型的边际成本看起来低，但不代表不需要缓存。本地推理会占 CPU、GPU、内存和电量。对前端来说，缓存本地摘要、embedding 或预处理结果，可以减少设备负担。
缓存还要考虑模型版本。模型换了，之前的缓存结果可能不再符合当前质量要求。cache key 里至少应该包含模型能力等级、prompt 版本、知识库版本和权限范围。
前端如何参与模型选择
前端不一定直接决定用哪个模型，但会影响路由输入和用户感知。
前端可以提供这些信息：
- 用户选择的输出长度。
- 当前任务入口。
- 是否需要实时结果。
- 用户是否上传了文件或图片。
- 用户是否点击了“深入分析”。
- 当前页面数据范围。
- 用户是否停止生成或重试。
前端也应该展示合理状态：
- 本地模型加载中。
- 后台任务排队中。
- 使用缓存结果。
- 正在升级到更强模型重试。
- 当前任务需要更长时间。
- 因隐私设置只能使用本地能力。
这些状态不是解释技术细节，而是让用户理解系统行为。AI 应用如果模型切换无感但质量波动明显，用户会觉得不可预测。
常见坑
第一个坑，是把本地模型当成免费。
本地模型没有按 token 付费，不代表没有成本。设备资源、下载体积、兼容性、发热、电量、更新、监控和支持都是真实成本。
第二个坑，是只看榜单不看业务样例。
公开 benchmark 只能提供参考。你的任务可能更依赖中文、表格、代码库、特定术语、格式稳定性或工具调用。必须用自己的 Eval case 比较。
第三个坑，是小模型没有置信度和 fallback。
小模型适合高频任务，但要有质量闸门。低置信度、规则校验失败或高风险场景，应该升级到更强模型或人工处理。
第四个坑，是大模型 API 直接散落在业务代码里。
这样会让 Provider 切换、成本统计、fallback 和权限控制变困难。应该通过统一调用层或 AI Gateway 管理。
第五个坑，是把所有隐私问题交给“本地”解决。
本地推理也要处理权限、日志、缓存、数据生命周期和用户同意。模型在哪里运行，只是隐私设计的一部分。
第六个坑，是多模型路由没有可观测性。
如果没有记录路由原因、模型版本、成本、延迟和质量结果，团队无法迭代路由策略。
小结
小模型、本地模型和大模型 API 不是谁取代谁的关系，而是不同约束下的工具组合。
小模型适合高频、低风险、可校验任务；本地模型适合隐私、离线和边际成本可控场景；大模型 API 适合复杂、开放、长上下文和高价值任务。
生产 AI 应用的关键不是选一个“最好的模型”，而是设计可观测、可评估、可降级的模型路由。让便宜模型处理便宜任务，让强模型处理强任务，让本地模型处理数据控制任务，再用缓存、预算和 Eval 保证系统既可负担，又可信赖。