什么是混合部署？敏感的本地通用的上云

企业落地 AI 时最常见的僵局：业务方嫌云端接口慢半拍、怕数据出域，IT 方面又拿不出预算全套自建。混合部署就是解这个僵局的折中方案——敏感的留在本地，通用的搬上云。

一条架构两种活法

混合部署指同一套 AI 能力分成两条腿走路：涉及敏感数据的环节跑在本地机房，模型和推理服务都攥在自己手里；通用性强的环节直接调云端接口，用即付的费用换弹性。两条腿共用同一层应用入口，业务系统只管发请求，至于这条请求被分到哪条腿，由分流层说了算。

打个比方：家里做饭，贵重食材自己冰箱放着、自己厨房料理，安全；偶尔办大宴席，食材和灶台都租外面中央厨房的，省事。关键是分清哪些食材必须自己管，哪些外包出去没人会说什么。

分流的三条判断线

第一条线是数据敏感度：请求里要带内部文档、客户资料、经营数据的，走本地；只处理公开信息、模板化内容的，走云。第二条线是负载形态：稳定的基础负载走本地——自建设备跑得满、单位成本低；波动的峰值走云——不用为一年几天的洪峰常备硬件。第三条线是能力边界：云端独占的旗舰模型、多模态能力，本地没有的，按需调用，本地模型覆盖不了的补位工作交给云。

三条线画完，绝大多数请求的归宿就定了。剩下的灰色地带——数据半敏感、负载半波动——按业务方对风险的容忍度拍板，拿不准的一律按敏感处理，宁可多花点钱。

三条判断线各自怎么分，横向摆开更好比。

混合部署分流速查

• 带敏感数据的请求：本地链路，模型不出域
• 公开内容、日常问答：云端接口，用弹性换成本
• 本地覆盖不了的能力：调云上旗舰模型补位
• 拿不准的灰色请求：默认按敏感处理

分流规则越简单，越不容易出岔子。

混合架构里的衔接件

两条腿走路最容易摔跤的地方在衔接处。第一个衔接件是统一网关：所有请求先进一个门，分流、鉴权、限流、日志都在这一层做，业务系统感知不到背后有几朵云。第二个是路由策略：按数据标签自动分流，而不是靠每个调用方自己记得规则——靠自觉的架构迟早出错。第三个是体验对齐：两条腿的模型输出格式、错误码、超时行为要套同一层皮，否则用户一会见这个脾气一会见那个脾气。

还有一条容易被忽略的暗线：成本归属。云端开销按月结、本地开销按年摊，混合架构下账更容易混，网关层的调用日志要按链路打标，月底才知道哪条腿花了多少。

从哪一步开始动手

别一上来就画大架构。第一步，给现有调用做数据分级盘点：过一遍流量，标出哪些请求真带了敏感数据。第二步，把最敏感的那一小撮先迁回本地——往往只占流量的一两成，一台设备加一个开源模型就能接住，投入可控。第三步，立统一网关，把分流规则写进代码而不是写在文档里。走完这三步，混合架构的骨架就立住了，之后按负载变化逐步调分流比例。云端侧的服务承诺要白纸黑字，选型时盯着 SLA 条款看；本地侧也别忘了容灾，退路没有，混合就成了两处风险。

分流即分寸

混合部署的本质是按需分配信任和预算：数据敏感度决定哪条链路，负载形态决定怎么花钱。判断自己适不适合，先看数据盘点的结果——敏感流量占比高的，混合值得做；几乎不碰敏感数据的，直接全云更省事。云端承诺怎么看，读什么是 SLA？服务等级承诺，一个例子讲透；本地那部分怎么算账，见什么是私有化部署？企业自建 AI 的账本；把推理再往前推到设备旁边是什么是边缘部署？在设备侧推理，看完就会判断；本地服务怎么平滑升级看什么是蓝绿部署？两套环境切换，通俗版解释；两条链路的效果怎么比高下，用什么是模型 A/B？两套模型对比的方法说话。

关于混合部署的三个常问问题

• 混合部署是不是就是把本地和云各搭一套？：不止。核心在统一网关和分流规则，让两套环境对外表现为一个服务，各搭一套不打通只是两套负担。
• 分流规则会拖慢请求吗？：正规网关的分流判断是毫秒级开销，相对模型推理动辄秒级的耗时可以忽略，设计得当不构成瓶颈。
• 混合架构下数据还会有风险吗？：风险不会归零，但被切小了——敏感流量锁在本地链路，云端只接触可出域数据，泄露面的量级完全不同。