本地AI和云API混合架构：哪些留本地，哪些交给云

admin

站点：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 应用走向生产的常态方案。

参考资料

Ollama Documentation：官方文档介绍本地运行和管理模型，用于本地模型服务定位。
llama.cpp GitHub README：项目文档说明本地推理、量化和 server 能力，用于轻量本地部署讨论。
llama.cpp server 文档：说明 HTTP server 和 OpenAI 兼容能力，用于本地 API 服务说明。
LocalAI Documentation：说明本地 OpenAI 兼容 API 和多模型支持，用于统一本地 API 讨论。
vLLM OpenAI-Compatible Server 文档：说明 vLLM 的 OpenAI 兼容服务能力，用于高吞吐本地服务讨论。
KServe Generative AI 文档：说明面向生成式 AI 的模型服务能力，用于平台化推理讨论。
Ray Serve LLM 文档：说明用 Ray Serve 部署和服务 LLM，用于弹性服务讨论。
NVIDIA Triton Inference Server 文档：说明推理服务、批处理和模型管理能力，用于平台化推理参考。
OpenAI API Data Usage Policies：说明 API 数据使用和保留政策，用于云 API 数据治理讨论。
OpenAI Enterprise Privacy：说明企业隐私、数据控制和训练使用口径，用于企业云端评估。
Azure OpenAI data privacy and security ：说明 Azure OpenAI 的数据处理、训练和安全边界，用于云端合规评估。
AWS Bedrock Data Protection：说明 Amazon Bedrock 数据保护和客户内容处理，用于云供应商对比。
Google Cloud Vertex AI Generative AI Data Governance：说明 Vertex AI 生成式 AI 数据治理，用于云端数据策略参考。
OWASP Top 10 for LLM Applications 2025：列出提示注入、敏感信息泄露、过度代理等风险，用于安全设计。
NIST AI Risk Management Framework 1.0：提供 AI 风险治理、映射、测量和管理框架，用于混合架构治理思路。
CISA Roadmap for Artificial Intelligence：说明安全机构对 AI 风险和安全采用的路线图，用于安全治理参考。
Model Context Protocol Documentation：说明 AI 应用连接外部工具和数据源的协议，用于本地工具和云模型协作参考。
OpenAI API 文档：Using tools：说明工具调用机制，用于智能体工具执行和权限分层讨论。

LocalAIHub 中文社区