<![CDATA[本地AI和云API混合架构：哪些留本地，哪些交给云]]>

站点：localaihub.com
风格：社区实践帖
联网检索日期：2026-05-22
写作日期：2026-05-22

本地 AI 和云 API 不是二选一。真正长期可用的 AI 应用，往往会走向混合架构：隐私敏感、低延迟、可离线、成本可控的部分留在本地；需要强推理、强多模态、稳定托管、全球可用和持续升级的部分交给云。问题不在于“本地好还是云好”，而在于怎样按数据、任务、风险、成本和体验做分工。

社区里常见两种极端判断。第一种是“全部本地化才安全”。这忽略了本地模型能力、硬件、运维、评测、更新和高峰并发成本。第二种是“全部交给云 API 才省事”。这忽略了敏感数据边界、网络依赖、供应商策略、成本波动和离线场景。生产级应用不能靠口号选型，而要把每类任务放到真实约束下评估。

这篇文章面向正在搭建本地 AI、团队知识库、AI 网关、智能体工具链和私有化应用的中文读者。重点回答几个实际问题：哪些数据应该留本地；哪些任务适合本地模型；哪些任务值得调用云 API；本地和云之间如何路由；怎样处理隐私、成本、延迟、可用性和评测；小团队如何从最小混合架构起步。

一、先给结论：按数据和任务分层，不按信仰站队

最实用的分工原则是：数据越敏感、越贴近本地系统、越需要低延迟或离线能力，越应该优先留本地；任务越需要顶级推理、多模态理解、复杂生成、外部工具生态和稳定托管，越适合交给云 API。两边之间用网关、数据分级、脱敏、缓存、审计和评测连接。

可以先用一张简单分层表理解：

强烈建议留本地：
原始私密文档、客户资料、内部日志、未公开代码、凭证、身份信息、设备控制指令、局域网知识库索引。

优先留本地，必要时脱敏上云：
企业知识检索、长文档预处理、文本切块、向量化、粗分类、摘要草稿、日志聚合、低风险助手问答。

适合云 API：
复杂推理、高质量写作、多语言润色、强多模态理解、复杂代码解释、长上下文综合、需要最新模型能力的任务。

适合混合：
RAG 问答、智能体执行、客服助手、代码助手、会议纪要、业务分析、内容生产、内部搜索。

这不是固定答案，而是初始判断。最终要看行业、法规、合同、用户承诺、模型能力、预算和实际评测。比如同样是“摘要”，员工公开培训材料可以上云处理，客户合同原文可能必须留本地，脱敏后的条款结构才可以交给云模型做风险解释。

混合架构的关键动作，是把“能不能上云”从一句主观判断，变成可执行的数据分级和路由策略。

二、为什么混合架构越来越常见

本地模型生态成熟后，很多团队发现它解决了云 API 的一部分问题：数据可以不出内网，局域网响应稳定，简单任务成本可控，离线场景可运行，模型和参数可自主管理。Ollama、llama.cpp、LocalAI 让个人和小团队更容易启动本地模型；vLLM、KServe、Ray Serve、Triton 等工具则面向更高吞吐、更复杂部署和平台化服务。

同时，云 API 仍然有明显优势。强模型更新快，复杂推理能力强，多模态能力完整，托管服务稳定，弹性和全球接入方便，工具生态成熟。对于很多任务，本地部署一个小模型省下的调用费，可能抵不过硬件折旧、运维时间、质量损失和故障成本。

混合架构出现，是因为 AI 应用的任务并不统一。一个企业知识助手可能同时需要本地读取内部文件、用本地向量库召回资料、用云模型综合回答、再把审计日志保存在内网。一个代码助手可能本地解析代码仓库和索引符号，只把最小必要片段交给云端强模型解释。一个智能客服系统可能用本地规则和小模型处理常见问题，把复杂投诉升级到云端模型或人工。

更重要的是，混合架构能降低单点依赖。云 API 不可用时，本地模型可以提供降级回答；本地 GPU 忙碌时，云端可以接管高峰；某个模型质量下降时，网关可以切换供应商；某类数据不允许出域时，路由器可以强制本地处理。

混合不是为了复杂而复杂。它的价值在于把不同能力放到合适位置。

三、本地 AI 适合承担什么

本地 AI 的最大价值不是“免费”，而是控制权。控制权包括数据位置、网络路径、模型版本、推理参数、服务暴露、日志保存、访问权限和降级策略。

第一类适合本地的是敏感数据预处理。文档清洗、切块、去重、格式解析、实体识别、敏感字段检测、日志压缩、代码结构抽取，都可以先在本地完成。这样即使后续调用云 API，也能只传必要片段，而不是把整个文件原文上传。

第二类是本地知识检索。RAG 系统中的文档库、向量索引、元数据、权限过滤，通常应该优先放在本地或私有环境。原因很直接：知识库包含企业语义资产，且检索阶段需要保留权限边界。云模型可以参与答案生成，但召回什么内容、用户能看什么内容，最好由本地系统控制。

第三类是低风险高频任务。分类、标签、粗摘要、标题候选、简单问答、格式转换、日志解释、数据抽取初筛，这些任务对顶级推理要求不高，调用频率却可能很高。用本地小模型处理，可以降低成本和外部依赖。

第四类是低延迟和离线任务。工厂设备、内网运维、个人桌面助手、局域网知识库、边缘设备交互，不一定能稳定访问外网。即使能访问，网络波动也可能影响体验。本地模型可以提供稳定的基础能力。

第五类是工具执行前的安全判断。比如本地智能体要改文件、执行命令、读数据库、操作内网系统，工具权限和执行环境本来就在本地。让本地策略层先判断数据和动作风险，再决定是否需要云端推理，通常更安全。

但本地 AI 也有明显边界。本地模型不是天然安全，也不是天然便宜。模型文件可能有供应链风险，服务端口可能被误暴露，推理日志可能保存敏感内容，GPU 成本可能远高于预期，小模型也可能产生幻觉。把模型搬到本地，只是改变责任归属，不是消除风险。

四、云 API 适合承担什么

云 API 的核心优势是能力密度和托管能力。强模型通常在复杂推理、长上下文、多语言、多模态、代码理解、指令遵循和安全对齐上领先。云服务还提供弹性、监控、模型升级、区域部署、访问控制、账单和企业支持。

第一类适合云端的是复杂推理和综合。比如跨多份资料写决策建议、分析复杂故障原因、根据长上下文生成结构化报告、把多种证据合并成用户能读懂的结论。这些任务常常需要强模型能力，使用本地小模型可能会节省调用费，却牺牲准确性和可信度。

第二类是高质量生成。对外发布的文章、客服回复、法务草案、商业邮件、产品说明、技术方案，如果对语言质量、语气、结构和细节要求高，云端强模型更有优势。当然，敏感原文仍需先做分级和脱敏。

第三类是多模态任务。图像理解、表格截图、票据识别、页面截图分析、音频转写、视频理解等能力，云端模型和托管工具链通常更完整。本地也能做部分任务，但部署、显存、模型组合和质量评测成本更高。

第四类是突发高峰。小团队很难为峰值并发长期购买硬件。云 API 可以承担临时高峰、本地故障、夜间批处理或大型任务。混合架构下，云端可以既是强能力层，也是弹性缓冲层。

第五类是需要最新模型能力的探索任务。AI 模型更新很快，新模型可能在工具调用、代码、数学、多模态、长上下文上明显提升。用云 API 做原型和高价值任务，可以避免团队在本地部署上过早固化。

云 API 的风险也不能忽略。数据会离开本地边界，调用成本受使用量影响，服务策略和模型版本可能变化，网络和供应商可用性会影响体验。即使云厂商提供企业数据不用于训练等承诺，团队也需要按合同、地区、行业和内部制度确认具体边界。不能把“云厂商说安全”当成架构设计的全部依据。

五、数据分级：决定路由前，先决定数据能去哪

混合架构最重要的不是模型路由，而是数据分级。没有数据分级，路由器只是在猜。建议至少把数据分成五类。

第一类是禁止外发数据。包括凭证、密钥、令牌、密码、身份证件、支付信息、客户个人敏感信息、未公开安全漏洞、生产数据库原始导出、严格合同保密材料。这类数据默认只能本地处理，且要限制日志、缓存和模型输入范围。

第二类是受控外发数据。包括内部文档片段、工单摘要、脱敏客户问题、代码局部片段、业务指标聚合结果。这类数据可以在脱敏、裁剪、授权和审计后交给云 API。

第三类是普通内部数据。包括团队流程、公开前的产品文案、一般会议纪要、非敏感知识库内容。它们可以更灵活地上云，但仍要注意最小必要原则。

第四类是公开数据。包括官网内容、公开文档、开源代码、公开论文、公开博客。这类数据上云风险较低，但要注意版权和引用准确性。

第五类是派生数据。包括摘要、标签、向量、聚合统计、风险评分、匿名样本。派生数据是否能上云取决于是否可反推出原始敏感信息。不要以为“摘要”就一定安全，摘要里可能仍包含客户姓名、合同金额或内部策略。

数据分级要落到系统字段，而不是写在制度文档里。每次任务输入都应该带数据等级、来源、用户权限、可用模型范围、保留策略和审计要求。路由器根据这些字段决定本地、云端还是拒绝。

一个简单路由规则可以这样写：

secret 或 regulated：只能本地处理，禁止进入云模型上下文。
internal_sensitive：先脱敏和裁剪，再按任务风险决定是否上云。
internal_normal：允许上云，但只传任务必要片段。
public：可本地或云端，按成本和质量路由。
derived：检查可逆性和敏感字段，再决定路由。

这类规则不应该由模型自由发挥。模型可以辅助识别敏感信息，但最终策略应由确定性代码和权限系统执行。

六、任务分级：同一份数据，不同任务路由不同

同一份数据在不同任务下，路由可能不同。比如一份内部会议纪要，如果任务是“提取待办事项”，本地小模型就够；如果任务是“根据会议内容写一封对外正式说明”，可能需要云端强模型，但要先删除参与者姓名、内部项目代号和未公开信息。

任务可以按能力需求分级。

低能力任务包括格式转换、简单分类、关键词提取、固定模板填充、短摘要、重复文本去重。这些优先本地处理。

中等能力任务包括多文档摘要、常见问答、基础代码解释、结构化信息抽取、日志原因初筛。本地模型可以先处理，云模型作为评审或升级路径。

高能力任务包括复杂推理、跨领域综合、长上下文规划、高质量写作、多模态分析、代码重构建议、重要决策支持。这些更适合云端强模型，但输入要经过本地数据治理。

高风险任务包括医疗、法律、财务、人事、合规、安全、生产变更、支付和删除操作。这类任务无论本地还是云端，都需要审计、人工确认、评测和明确责任边界。模型位置不是核心，流程控制才是核心。

任务路由还要考虑用户体验。低延迟互动可以先用本地模型生成即时反馈，再用云端补充高质量版本。长任务可以在后台云端处理。本地模型失败或置信度低时，可以升级到云端。云端不可用时，可以用本地模型降级回答并标注能力限制。

七、典型混合架构一：本地 RAG 加云端生成

最常见的混合架构，是本地 RAG 加云端生成。流程如下：

文档进入本地系统
  -> 本地解析、清洗、切块、脱敏
  -> 本地 embedding 和向量索引
  -> 用户提问进入权限过滤
  -> 本地召回相关片段
  -> 本地策略层裁剪和脱敏
  -> 云端强模型生成回答
  -> 本地保存审计日志和引用

这个架构的好处是，原始知识库和权限控制留在本地，云端只看到回答所需的少量片段。对于很多团队，这是质量和安全之间的合理平衡。

但它有几个陷阱。

第一，召回片段仍可能包含敏感信息。不能因为只传了几个片段，就默认安全。片段级脱敏和权限检查仍然必要。

第二，云端生成可能把片段外信息说成事实。回答必须要求引用来源，并在没有证据时明确说明不知道。对于重要场景，可以让本地评审器检查答案是否只基于召回内容。

第三，embedding 本身也可能泄露语义。向量库如果外包托管，要评估是否能反推出敏感内容、是否有访问控制、是否符合数据保留策略。

第四，长上下文不是召回质量的替代品。把大量片段塞给云模型，会增加成本，也会让模型更难定位关键证据。检索、排序、去重和片段压缩仍然重要。

适合这个架构的场景包括企业知识库、内部政策问答、技术文档助手、客服知识库、合同条款解释、研发资料搜索。前提是知识库权限、数据分级和引用机制要做好。

八、典型混合架构二：本地智能体执行，云端负责推理

智能体场景里，本地和云的分工更敏感。智能体不仅回答问题，还会调用工具、读文件、改配置、执行命令、提交工单。工具执行环境通常在本地或企业内网，因此本地控制层必须掌握权限。

一种实用架构是：

用户任务进入本地智能体控制器
  -> 本地解析任务和权限
  -> 本地读取必要上下文
  -> 云端模型做计划或复杂判断
  -> 本地控制器审查计划
  -> 本地执行只读工具或低风险工具
  -> 高风险动作请求用户确认
  -> 本地记录轨迹和结果

在这个架构中，云端模型可以提供强推理，但不能直接拿到无限工具权限。本地控制器负责决定哪些工具可用、哪些参数允许、哪些动作需要确认。云端模型输出的是计划、候选动作或解释，本地系统执行策略。

例如代码助手可以把相关代码片段交给云模型，让它建议修改；但真正写文件、运行测试、提交补丁由本地工具完成。运维助手可以让云模型分析日志摘要；但重启服务、修改配置、删除缓存必须由本地策略层控制。

这个模式能防止“过度代理”。模型越强，越容易被赋予更多行动能力，但行动能力必须有边界。OWASP LLM 风险中，过度代理就是关键问题之一。混合架构应该把“思考”和“执行”分层，而不是让云模型直接控制内网。

九、典型混合架构三：本地模型前置，云模型兜底

另一种常见架构是本地模型前置，云模型兜底。用户请求先进入本地模型；如果本地模型能高置信完成，就直接返回；如果遇到复杂问题、低置信、用户要求高质量、或本地资源繁忙，就升级到云 API。

适合前置本地的任务包括分类、短摘要、意图识别、常见问答、低风险聊天、格式整理、简单代码解释。升级条件可以包括：

本地模型无法遵循输出格式。
检索证据不足或冲突。
用户明确要求高质量版本。
任务涉及复杂推理或多步骤规划。
本地响应超过延迟阈值。
本地模型安全分类为高风险。

这个架构的优势是成本和延迟。大部分简单请求在本地完成，少量复杂请求交给云端。它也能提升可用性：云端不可用时，本地仍能处理基础任务。

风险是质量不稳定。如果路由器过于激进，把复杂问题留给本地小模型，用户会得到低质量答案。如果路由器过于保守，大部分请求都上云，成本优势消失。因此必须用真实任务评测路由策略，而不是凭感觉设置规则。

可以先用保守策略：本地处理低风险低复杂任务，其他升级云端。等积累数据后，再扩大本地覆盖范围。

十、典型混合架构四：云端生成，本地审查和落库

有些任务需要云端强生成，但最终结果必须经过本地审查才能进入系统。例如生成客服回复、营销文案、知识库条目、代码补丁、配置建议、数据分析报告。此时可以采用云端生成、本地审查和落库。

流程如下：

本地准备最小必要上下文
  -> 云端生成候选结果
  -> 本地规则检查格式、敏感词、引用、权限
  -> 本地模型或评审器检查事实和风险
  -> 必要时人工确认
  -> 通过后写入本地系统

这个架构适合对外输出和系统写入。云端负责能力，本地负责把关。比如 AI 写了一段客服回复，本地审查器要检查是否承诺了不该承诺的赔偿、是否包含客户隐私、是否引用了正确政策。再比如云模型生成 SQL，系统不能直接执行，必须先做只读限制、表权限检查、成本估算和人工确认。

本地审查不能只靠另一个模型。格式、敏感词、权限、链接、引用、文件范围、SQL 类型、测试退出码，都应该尽量用程序检查。模型适合检查语义风险和表达质量。

十一、模型服务选型：Ollama、llama.cpp、LocalAI、vLLM 和平台化服务

本地侧有多个层级，不能混为一谈。

Ollama 适合个人和小团队快速运行本地模型。它的优势是安装简单、模型管理方便、开发体验好。适合桌面助手、原型验证、内部低并发工具。它不是完整生产平台，外层仍要补认证、权限、监控、限流、审计和服务治理。

llama.cpp 适合轻量、跨平台、CPU 或低资源环境，也支持 server 方式和 OpenAI 兼容接口。它常用于边缘设备、个人电脑、低成本部署、量化模型实验。它的优势是轻和可控，边界是吞吐、管理和平台能力。

LocalAI 提供 OpenAI 兼容接口，目标是把本地推理包装成类似云 API 的服务体验。它适合希望用统一 API 接入多类本地模型的团队。仍需关注模型质量、硬件资源、并发和运维。

vLLM 更偏高吞吐 LLM 服务，支持 OpenAI 兼容服务、连续批处理等能力，适合需要更高并发和 GPU 利用率的场景。部署复杂度高于桌面工具，但更接近服务化生产需求。

KServe、Ray Serve、NVIDIA Triton 等工具更偏平台化推理服务。它们关注 Kubernetes、弹性、模型服务、批处理、监控、多模型管理和生产运维。适合已经有平台团队、集群和 MLOps 基础的组织。小团队不一定需要一上来就引入。

选型顺序可以是：

个人验证：Ollama 或 llama.cpp。
本地 API 原型：Ollama、LocalAI、llama.cpp server。
高并发 LLM 服务：vLLM。
平台化推理：KServe、Ray Serve、Triton。
统一访问层：自建 AI 网关或现有网关。

不要用“生产级”三个字吓自己，也不要用桌面工具冒充完整平台。按阶段选工具，按风险补能力。

十二、云端选型：不仅看模型能力，还要看数据政策和工程能力

云 API 选型常被简化成模型榜单。真实项目里，还要看数据处理政策、区域、访问控制、日志、服务等级、价格、限速、模型版本、工具生态和合同条款。

OpenAI、Azure OpenAI、AWS Bedrock、Google Vertex AI 等平台都提供企业级数据治理和隐私说明，例如客户数据是否用于训练、如何处理滥用监控、区域和访问控制等。具体口径会随服务、合同和地区变化，项目上线前应该阅读官方文档并让法务或安全团队确认。

工程上，要关注几个问题：

是否支持需要的模型和模态。
是否支持稳定 API、结构化输出和工具调用。
是否支持企业身份、密钥管理和审计。
是否有区域要求和数据驻留选项。
是否能限制或关闭数据保留。
是否提供足够的速率限制和配额。
是否能承受成本波动。
是否有备选供应商或降级路径。

云端不是一个抽象“强模型”，而是具体供应商、具体模型、具体区域、具体合同和具体调用策略。混合架构应该把云端能力包装在网关后面，避免业务代码和某个模型深度绑定。

十三、AI 网关：混合架构的控制平面

当本地和云端模型同时存在，AI 网关几乎是必需的。网关不只是转发请求，它是策略执行点。

一个合格的混合 AI 网关至少要承担这些能力：

模型路由：根据任务、数据等级、成本、延迟和健康状态选择模型。
数据治理：脱敏、裁剪、过滤、禁止外发。
统一接口：对上提供一致 API，对下适配本地和云端服务。
认证授权：控制谁能调用哪些模型和工具。
成本控制：预算、配额、限流、缓存、账单归因。
可观察性：记录请求、模型、耗时、token、错误和质量反馈。
降级策略：云端失败时转本地，本地繁忙时转云端。
评测闭环：把真实失败样本送回测试集。

没有网关时，业务代码会到处写模型选择逻辑。某个页面调用云模型，某个脚本调用本地模型，某个智能体直接拿 API key。久而久之，权限、成本和审计都会失控。网关把策略集中起来，业务只表达任务意图。

路由策略可以从规则开始，不必一开始就做复杂智能路由。例如：

数据等级为 secret：强制本地。
任务为 embedding：优先本地。
任务为 simple_classification：优先本地小模型。
任务为 long_reasoning：优先云端强模型。
用户为免费层：限制云端强模型次数。
云端错误率升高：临时降级到本地模型。

后续可以加入评分模型、质量反馈、A/B 测试和自动路由。但第一版必须可解释，否则排查问题很困难。

十四、隐私和合规：不要把“本地”当万能护身符

本地部署确实能减少数据外发，但本地不等于合规。本地服务如果没有认证，局域网任何人都能访问；日志如果保存完整提示，敏感信息仍会泄露；模型文件如果来源不明，可能带来供应链风险；向量库如果没有权限过滤，用户可能召回不该看的内容。

云端也不等于不安全。主流云平台会提供数据处理说明、企业控制、区域选项和合规能力。问题是团队是否正确配置、合同是否覆盖、数据是否允许、调用是否最小化、日志是否审计。

混合架构下，隐私治理应围绕数据流，而不是围绕部署位置。每个请求都要能回答：

输入数据来自哪里。
数据等级是什么。
哪些字段被发送到哪里。
发送前是否脱敏和裁剪。
哪个用户或服务发起调用。
模型输出是否进入本地系统。
日志保留多久。
用户能否追溯和删除相关数据。

对于高敏感数据，建议默认本地处理，并使用确定性脱敏、字段白名单、审计日志和人工确认。对于受控上云数据，建议使用最小必要上下文，不发送完整原文，不发送凭证，不发送无关历史，不把工具返回的敏感日志原样塞进模型。

NIST AI 风险管理框架强调治理、映射、测量和管理风险。把这个思路放到混合架构里，就是先识别 AI 使用场景和数据流，再测量风险和质量，最后用制度和技术持续管理。不要等事故发生后再补一个“隐私开关”。

十五、成本：本地不是免费，云端也不一定贵

很多团队选择本地模型，是因为想省 API 调用费。但本地成本包括硬件、显卡折旧、电力、散热、部署、监控、故障处理、模型更新、评测和工程时间。如果服务质量不足，还会产生隐性成本：用户不信任、人工返工、错误决策。

云端成本看起来按量付费，容易被 token 账单吓到。但它省掉了部分运维和硬件投入，也能按需使用强能力。对于低频高价值任务，云 API 往往更划算。对于高频低风险任务，本地模型可能更划算。

混合架构的成本策略不是“尽量不用云”，而是“把每类任务放在性价比最高的位置”。可以把请求分成三层：

本地低成本层：分类、抽取、短摘要、意图识别、缓存命中。
云端强能力层：复杂推理、高质量生成、多模态、长上下文。
人工或审批层：高风险、低置信、不可逆、合规敏感。

还要建立成本观测。每次调用记录模型、输入 token、输出 token、缓存命中、耗时、用户、任务类型、是否升级云端、是否返工。没有这些指标，团队只能凭账单猜哪里浪费。

常见降本手段包括本地预处理、上下文裁剪、RAG 去重、提示词瘦身、缓存、批处理、小模型前置、失败重试上限、低价值任务限额。注意不要为了省钱牺牲关键质量。高风险任务省一次强模型调用，可能换来更高人工和事故成本。

十六、延迟和可用性：用户体验比架构图更诚实

混合架构容易在架构图上很好看，在用户体验上很糟糕。请求先经过本地分类、再检索、再脱敏、再云端生成、再本地审核，如果每一步串行且没有流式输出，用户会等很久。

优化延迟，要从体验路径看。

第一，低风险短任务本地直接响应，不要为了统一架构绕远路。第二，长任务提供进度和后台完成，不要让用户盯着空白页面。第三，云端生成可以流式返回，但本地审查如果要求完整输出，就要设计好“草稿”和“已确认结果”的区别。第四，检索和预处理尽量缓存。第五，模型健康检查要实时，失败后快速降级，不要等长超时。

可用性方面，本地和云端可以互为降级，但降级不是等价替换。本地小模型替代云端强模型时，应该降低承诺，输出更保守结果。云端替代本地模型时，要重新检查数据等级，不能因为本地服务故障就把禁止外发数据传出去。

一个可用性策略可以这样设计：

本地模型不可用：
  public 和 internal_normal 可转云端。
  secret 和 regulated 返回本地服务暂不可用，不上云。

云 API 不可用：
  简单任务转本地。
  复杂任务进入后台重试或提示稍后处理。
  高风险任务不降级生成结论。

网关策略异常：
  默认拒绝高敏数据外发。
  保留审计日志。

降级策略要宁可保守，也不要为了可用性突破数据边界。

十七、评测：混合路由必须用真实任务证明

混合架构最容易出现“感觉合理”的路由，但真实质量不达标。例如团队规定“短问题走本地，长问题走云端”，结果短问题里包含复杂法律判断，本地模型答错；长问题只是格式整理，却浪费云端强模型。

评测集应该按任务类型和数据等级组织：

公开资料问答：比较本地、云端、混合的准确率和引用质量。
内部知识问答：检查权限过滤、召回质量和敏感信息外发。
简单分类抽取：评估本地模型是否足够稳定。
复杂推理写作：评估云端强模型收益是否明显。
智能体工具任务：检查计划质量、工具权限和高风险确认。
故障降级任务：模拟本地失败、云端失败和网络超时。

每条样例都要记录期望路由。比如“客户身份证号检测任务必须本地处理”“公开文档综合可上云”“脱敏合同摘要可上云但原文不可上云”。测试不仅看答案质量，还要看是否遵守路由策略。

评测指标可以包括准确率、引用覆盖、幻觉率、敏感字段泄露率、平均延迟、P95 延迟、每次任务成本、升级云端比例、本地失败率、人工确认率、用户满意度。只有这些指标持续可见，混合架构才能迭代。

不要让模型自己判断自己该不该上云。模型可以给置信度和风险提示，但策略评测必须有程序化检查和人工抽检。

十八、案例：小团队知识库助手怎么分工

假设一个小团队要做内部知识库助手，资料包括公开产品文档、内部 SOP、客户问题、研发记录和少量合同条款。目标是让员工用自然语言查询资料，得到带引用的回答。

第一步，数据分级。公开产品文档标为 public，内部 SOP 标为 internal_normal，客户问题标为 internal_sensitive，合同条款标为 regulated。凭证和客户身份字段禁止进入模型上下文。

第二步，本地建立文档管道。所有文档先在本地解析、清洗、切块、去重、权限标记和索引。embedding 可以本地完成，向量库保存在内网。每个片段带来源、更新时间、权限和数据等级。

第三步，问题进入本地网关。网关识别用户身份、问题类型和数据等级，先做权限过滤，再检索相关片段。对于 public 和 internal_normal 片段，可以裁剪后交给云端强模型生成回答。对于 regulated 片段，只允许本地模型摘要，或只返回“需要查看受控文档”的提示。

第四步，本地审查输出。回答必须包含引用，不能引用用户无权访问的片段。若输出包含客户姓名、证件号、合同金额等敏感字段，进入人工确认或自动遮盖。

第五步，记录反馈。用户点“有帮助”或“无帮助”，系统记录召回片段、模型、路由、耗时和问题类型。低质量样例进入评测集。

这个架构不是最复杂的，但它具备混合架构的关键能力：本地控制数据和权限，云端承担强生成，本地负责审计和持续改进。

十九、案例：代码助手怎么分工

代码助手是混合架构的高频场景。代码仓库通常包含未公开业务逻辑、内部接口、配置文件和潜在密钥。全部上传云端不合适，完全本地又可能能力不足。

合理分工是：本地负责仓库索引、符号搜索、依赖分析、文件读取、测试执行和补丁落地；云端负责复杂解释、重构建议、错误原因推理和高质量代码生成。发送给云端的内容应该是最小必要片段，不包括密钥、完整仓库和无关文件。

具体流程可以是：

用户提出问题
  -> 本地解析相关文件和符号
  -> 本地密钥扫描和敏感片段过滤
  -> 云端分析错误或生成修改建议
  -> 本地应用补丁
  -> 本地运行测试和格式化
  -> 本地生成变更说明

如果任务涉及生产配置、部署脚本、数据库迁移或权限策略，必须加入人工确认。云模型可以建议，但不能直接执行。对于开源项目，更多上下文可以上云；对于商业闭源项目，要更严格裁剪。

代码助手的评测不能只看模型生成代码是否“看起来对”。要运行测试、打开页面、检查真实行为。混合架构的优势在这里很明显：云端负责聪明，本地负责验证。

二十、案例：客服和运营助手怎么分工

客服助手通常面临两类压力：一边要快速回复，一边不能泄露客户信息或做错误承诺。混合架构可以这样分工。

本地系统保存客户身份、订单、工单、历史对话和权限。用户问题进入后，本地先识别意图、查询订单、召回政策、遮盖敏感字段。对于常见问题，本地小模型或模板直接生成初稿。对于复杂投诉、跨政策解释、情绪化表达或高价值客户，云端强模型生成更自然、更完整的回复建议。

但云端不应该看到完整客户档案。它只需要脱敏后的问题摘要、相关政策片段、允许承诺的范围和语气要求。最终回复回到本地后，还要检查是否包含敏感信息、是否违反政策、是否承诺退款或赔偿。高风险回复由人工确认。

运营助手也类似。本地保存用户数据和业务指标，云端可以帮助写活动文案、解释趋势、生成报告，但不应直接接收可识别个人的原始明细。统计聚合、匿名样本和脱敏摘要是更合适的输入。

这个场景说明，混合架构不是只解决技术部署，也解决组织责任。模型可以辅助员工，但最终承诺和业务动作必须由系统规则和授权流程约束。

二十一、从零开始的最小混合架构

小团队不需要一开始就搭完整平台。可以从最小闭环开始：

一个本地模型服务：Ollama、llama.cpp 或 LocalAI。
一个云 API 供应商：选择当前任务质量最好的模型。
一个简单网关：统一调用入口、记录日志、按规则路由。
一个数据分级字段：secret、internal、public。
一个脱敏模块：处理密钥、身份证、手机号、邮箱、客户名等。
一个评测集：二十到五十条真实任务。
一个审计表：记录请求、路由、模型、耗时、成本和错误。

第一版路由可以非常保守：secret 只走本地；public 复杂任务走云端；internal 先裁剪和脱敏，再按任务类型决定；本地无法处理时，不自动把 secret 传云端。这个规则看起来朴素，但比无规则强很多。

然后用真实任务扩展。发现本地分类稳定，就把更多分类任务留本地。发现云端写作明显更好，就把对外文案交给云端。发现某类内部问答容易泄露敏感片段，就加强脱敏和权限过滤。混合架构应该从观测中成长，而不是一次性设计完美。

二十二、常见误区

误区一：本地模型等于零成本。本地成本只是从账单变成硬件、运维、电力和质量成本。高频低风险任务适合本地，高价值复杂任务未必适合。

误区二：云 API 一定不合规。合规取决于数据类型、合同、区域、配置、审计和内部制度。云端可以安全使用，前提是数据治理和最小化做好。

误区三：只要脱敏就可以随便上云。脱敏有失败率，摘要也可能包含敏感信息。脱敏后仍要按数据等级和任务风险判断。

误区四：用小模型前置就能自动省钱。如果路由不准，小模型会制造低质量答案，后续返工成本更高。前置模型必须经过评测。

误区五：把路由交给模型自由决定。模型可以辅助判断，但策略必须由确定性规则、权限系统和评测约束。

误区六：忽略日志。提示、工具返回、模型输出、错误栈都可能包含敏感信息。日志同样需要分级、遮盖和保留策略。

误区七：没有降级边界。云端失败时，不是所有任务都能转本地；本地失败时，也不是所有数据都能上云。降级必须遵守数据策略。

误区八：只看平均延迟。用户感知常被 P95、失败重试和长任务卡顿决定。混合架构要关注真实用户路径。

二十三、落地检查清单

上线混合架构前，可以用这份清单检查：

数据分级是否落到字段和策略。
哪些数据禁止外发是否明确。
本地模型服务是否有认证、限流和日志策略。
云 API 数据政策是否阅读并通过内部确认。
路由规则是否可解释、可测试、可审计。
脱敏是否覆盖密钥、身份信息、联系方式和业务敏感字段。
RAG 是否做权限过滤和引用检查。
智能体工具是否由本地控制器执行权限。
高风险动作是否有人类确认。
本地和云端是否都有健康检查。
降级策略是否遵守数据边界。
成本、延迟、错误率和模型选择是否可观测。
评测集是否覆盖真实任务和失败场景。
最终用户界面是否只展示清晰结果，不暴露内部实现。

这份清单不复杂，但很多项目正是因为漏掉其中几项，才在后期遇到成本失控、隐私争议和质量不稳定。

二十四、社区项目里的现实取舍

在 localaihub 这样的社区语境里，混合架构要务实。很多人不是大厂平台团队，没有无限 GPU、法务团队和 MLOps 人员。现实做法应该是先把边界画清楚，再逐步增强能力。

个人开发者可以从本地模型加一个云 API key 开始，用简单脚本或轻量网关做路由。关键是不要把密钥和敏感文件随手发给模型。小团队可以增加本地知识库、审计日志和评测集。企业内部项目再考虑统一网关、身份权限、多供应商、私有部署和平台化推理。

不要为了“全本地”牺牲用户体验，也不要为了“云端强大”忽视数据边界。最好的架构往往很朴素：本地掌握数据和工具，云端提供强能力，网关执行策略，评测驱动迭代。

混合架构的成熟标志不是用了多少框架，而是团队能回答这些问题：某个请求为什么走了这个模型；哪些数据被发送出去了；如果云端失败会怎样；如果本地模型答错了怎么发现；一类任务迁移到本地后质量是否下降；账单上涨时是哪类任务造成的。

能回答这些问题，架构才真正可控。

二十五、生产故障：混合架构最怕边界失效

混合架构的故障通常不是某个模型“突然不聪明”，而是边界失效。常见第一类故障是路由失效：本应留在本地的敏感请求被升级到云端，本应交给强模型的复杂任务被低成本模型草率处理。前者带来隐私和合规风险，后者带来错误结论和用户不信任。路由失效往往来自元数据缺失，例如请求没有数据等级、任务类型不准、用户权限没有传到网关，或者降级策略只看服务可用性，不看数据是否允许外发。

第二类故障是降级失真。云端接口超时后，系统自动切到本地小模型，但界面仍然用同样语气给出确定答案；本地向量库不可用后，系统改用通用模型回答，却没有说明缺少企业资料支撑。这样的降级不是可靠性提升，而是把可见故障变成隐蔽错误。生产系统里的降级应该改变承诺等级：缺少检索证据时只给通用建议，缺少强模型时只处理低风险任务，缺少权限校验时宁可拒绝，也不能生成貌似完整的答案。

第三类故障是成本雪崩。一次云端失败触发多次重试，本地前置模型判断不准导致大量请求二次升级，RAG 召回过宽让长上下文费用成倍增加，评审模型和生成模型都读取完整材料，账单很快失控。成本故障不能只靠月底看账单处理，必须在请求链路中设置预算、缓存、重试上限和任务级配额。超过预算时，系统应该交付已完成部分、说明限制，或者请求用户选择更高质量路径，而不是在后台继续消耗。

第四类故障是观测断层。用户只看到“回答错了”，工程侧却查不到当时走了哪个模型、召回了哪些片段、是否发生脱敏、是否命中缓存、为什么触发降级。混合架构如果没有端到端追踪，就很难区分模型质量问题、检索问题、权限问题、路由问题和供应商故障。每次请求都应该留下可审计轨迹，但轨迹本身也要脱敏，避免把敏感提示和工具返回原样写进日志。

二十六、模型路由、权限和观测要一起设计

很多团队把模型路由当成性能优化，先按价格和速度选模型，等出现隐私或越权问题后再补策略。更稳妥的顺序是先设计权限边界，再设计路由策略，最后用观测数据调优。权限边界决定哪些人、哪些应用、哪些任务可以触发哪些模型和工具；路由策略只是在这个边界内做质量、成本和延迟取舍。没有权限边界的智能路由，越聪明越危险。

路由输入不应只有用户问题文本，还应包含数据等级、用户角色、业务场景、任务类型、输出用途、允许外发范围、实时性要求和历史质量反馈。比如同一句“帮我总结这份合同”，在公开模板、内部采购合同、客户真实合同、涉诉材料四种场景下，路由结果应该完全不同。公开模板可以交给云端强模型润色，客户真实合同需要本地脱敏和权限审查，涉诉材料可能只允许本地受控环境处理并进入人工审核。

权限边界也要覆盖工具，而不仅是模型。云端模型可以给出数据库查询建议，但不能直接拿到生产数据库连接；本地模型可以读取知识库片段，但不能绕过文档权限；客服助手可以生成回复草稿，但不能自动退款；运维助手可以解释日志，但不能未经确认重启关键服务。混合架构里，模型回答属于信息流，工具执行属于动作流，两者必须分开授权。

观测指标要能支持路由迭代。只看成功率不够，还要看本地命中率、云端升级率、敏感字段拦截次数、脱敏失败样本、每类任务平均成本、强模型调用占比、降级后用户追问率、引用缺失率、人工确认通过率和拒绝原因。指标不是为了装饰面板，而是为了回答一个具体问题：哪些任务应该继续留本地，哪些任务应该升级云端，哪些任务根本不该由模型自动处理。

隐私治理同样需要观测闭环。系统应该能统计哪些字段最常被拦截，哪些业务入口最容易携带敏感信息，哪些供应商和模型接收了哪些等级的数据，哪些用户或应用频繁触发高风险路径。没有这些数据，隐私策略只能停留在原则层面。真正可执行的隐私治理，是把数据分级、脱敏、路由、日志和审计连成一条链路。

最终，混合架构的可靠性来自可解释的控制面。用户请求进入系统后，网关知道它是什么任务、带什么数据、谁在调用、能走哪些模型、能用哪些工具、失败时怎么降级、结果能否落库。只要这些问题有明确答案，本地和云端就能互相补位；如果这些问题都靠模型临场判断，系统迟早会在成本、隐私或权限上出事故。

二十七、结语：把控制权留在系统里，把能力放到最合适的位置

本地 AI 和云 API 的混合架构，本质是能力和控制权的平衡。本地负责数据主权、权限、低延迟、离线、工具执行和成本底座；云端负责强模型能力、多模态、复杂推理、弹性和持续升级。中间的网关、数据分级、脱敏、审计、缓存、降级和评测，决定了这套架构是否能进入生产。

选择本地还是云，不要问哪个更先进，要问任务需要什么、数据允许什么、用户体验要求什么、团队能维护什么、失败后能否追溯和恢复。把这些问题答清楚，混合架构就不再是折中方案，而是 AI 应用走向生产的常态方案。

参考资料

]]>https://localaihub.com/topic/20/本地ai和云api混合架构-哪些留本地-哪些交给云RSS for NodeWed, 03 Jun 2026 18:50:35 GMTThu, 21 May 2026 21:28:02 GMT60