本地优先的 AI 技术栈：把数据和成本重新握在自己手里

为什么会想”把 AI 搬回本地”

过去两年，几乎所有 AI 能力都走云端 API。它方便、强大，但也带来三个绕不开的问题：

成本不可控：用多少付多少，随着业务量上升，账单是线性增长的。

数据要出境：客户资料、内部文档、医疗记录的每一次调用，都是一次数据外发。

体验受制于人：模型更新、限流、停服、价格调整，都不由你决定。

“本地优先（Local-First）“的思路是：默认在本地跑，只有确实需要时才上云。

本地优先栈的四层结构

第 1 层：模型层

本地需要可运行的模型。开源模型已经能覆盖大量任务：分类、抽取、摘要、改写、简单对话。参数量从几十亿到几百亿，消费级显卡或统一内存设备就能跑起不少。

关键认知：本地模型不需要对标旗舰云端模型。它只需要在你选定的窄任务上”够用”。

第 2 层：推理服务层

直接用脚本调模型不现实，需要一个本地推理服务来统一管理：模型加载、量化、批处理、并发、缓存。

考虑因素：量化等级（影响质量与显存）、上下文长度、并发能力。量化是本地部署的核心技巧——用少量质量损失换大幅显存节省。

第 3 层：编排层

和云端一样需要编排：检索、工具调用、记忆、路由。区别是路由器要能决定”这个请求本地够不够，不够就上云”。

这一层是混合架构的大脑。

第 4 层：数据层

本地向量库、本地文档索引、本地日志。这一层的意义是：敏感数据在本地闭环，不以全文形式外发。

什么该留本地，什么该上云

一个实用的判据：看数据的敏感度和任务的难度。

留本地：

• 涉及个人身份、健康、财务的数据
• 高频、低难度的批量任务（分类、抽取、格式转换）——本地跑省钱且无延迟
• 需要离线可用的场景（现场、内网）

上云：

• 高难度推理、复杂代码、长文深度分析
• 低频但重要的关键任务
• 需要最新知识的检索增强场景

混合：大部分请求本地处理，少量困难的自动升级到云端。这就是本地优先栈的核心形态。

三个必须面对的现实

现实一：本地模型确实更弱

同样任务，本地模型在复杂推理上会明显不如云端旗舰。所以要按任务选模型，而不是指望一个本地模型打天下。

现实二：运维是隐性成本

本地部署意味着你要自己管机器、管显存、管升级、管故障。云端把这些都省掉了。如果团队没有工程能力，本地优先可能得不偿失。

现实三：能力更新慢

云端模型隔几个月就换代，本地模型需要你主动跟进，还要验证新版是否真的更好。

一条可行的渐进路径

不必一开始就全本地化。建议：

1. 先统计请求构成：多少是简单任务，多少是困难任务。
2. 把简单任务迁到本地：立竿见影的成本和延迟收益。
3. 敏感数据全流程本地：确保不因某个环节外发。
4. 保留云端作为能力上限：困难任务继续上云。

收益测算的简单框架

判断值不值得，算三个数：

• 当前云端月成本 vs 本地硬件摊销 + 运维人力
• 敏感数据外发风险（合规成本、客户信任）
• 延迟改善带来的体验收益

如果数据敏感度很高，决策往往在第二项就已经定了。

小结

本地优先不是”拒绝云端”，而是把控制权拿回来：数据留在本地闭环，简单任务本地消化，困难任务按需上云。

它的核心判据只有两条：数据有多敏感，任务有多难。想清这两点，架构自然就清楚了。