企业如何搭建 ai 中台

很多团队的中台是被需求推着长出来的：先接了某个模型做客服，又接了另一个做文档问答，半年后接口散在四五个项目里，账没人算得清，换模型要改一堆代码。这篇不讲概念，按落地顺序给一套可执行的搭建路径：先定范围和边界，再定统一接入层，然后做选型测算，最后灰度上线并留好维护口子。每步都说明什么情况下该停、该缩范围。

很多团队的中台不是规划出来的，是被需求推着长出来的：先接一个模型做客服，再换一个做文档问答，半年后接口散在四五个项目里，账算不清，换模型要改一堆代码。要收口，得按落地顺序走：先定范围和边界，再定统一接入层，然后做模型与算力测算，最后灰度上线并留好维护口子。

下面这套顺序适合已经有至少三个业务方在提模型需求、或者两个以上项目各自在写调用代码的团队。每步都写了什么情况下该停、该缩范围——中台不是越大越好，接得太早反而拖慢业务。

第一步：先把中台的范围划清

这一步的产出不是架构图，是一张「管什么、不管什么」的清单。先让每个业务方把要接的场景、预估调用量级、数据敏感程度填一栏，再判断统一入口和各自接哪种更省事。清单没填完就先别谈技术选型，否则后面全是返工。

• 场景清单：逐条写下要接的业务、预估调用频次、是否涉及用户隐私数据
• 职责边界：中台只管模型调用与密钥，还是把日志、计费、评测、数据回流一起收进来
• 负面清单：垂直业务里跟模型无关的逻辑别往中台塞，否则以后每次改需求都要排队排期
• 停手条件：全公司只有一两个项目在用模型时，先按项目直连，等第三个需求出现再收口

第二步：定统一接入层怎么设计

接入层不用做厚，但三件事必须解决：模型名与真实供应商解耦、密钥集中管理、调用日志可追溯。做法上，业务方只认中台给的模型别名，真实走哪家由中台配置决定；密钥只存在中台一侧，业务代码里不出现任何厂商 key。

接口格式尽量兼容主流的请求结构，这样切换供应商时业务侧只改配置不改代码。各家的实际接入方式与字段差异，到 /ai-nav/category/ai-api 对照当时的口径，别照抄某一家就当成通用标准。

不适用的情况也写清楚：对延迟极其敏感的场景，绕过多一层转发直连可能更合适，但要在中台登记备案，别形成谁都不知道的盲区。

第三步：模型来源与算力怎么配

先把任务分档：高频低难度任务走便宜档位，复杂推理单独走一档，别指望一个模型包打天下。然后对「调用官方 API」「用中转或聚合平台」「自己部署」三条路各算一遍账——涉及实际价格和跑分的数据，到 /price-watch 和 /rankings 核对当时的数字，不要拿别人截图里的旧数据做决策。

1. 分档按任务难度和调用频次把场景归成两三档，每档允许用的模型范围写进配置
2. 算账三条来源路径各估算月度成本与运维人力，自建部分按并发峰值而不是平均值算卡，显存与并发的测算口径顺着 /compute/sizing 走一遍
3. 定来源需要过合规或数据不出内网的业务，在这步就定死模型来源与日志留存方式，后面再改代价很大
4. 留后手每档至少留一个备选供应商，并记下切换时业务侧要改哪些配置

如果业务量还在早期、峰值不明显，可以先不自建，把两条外部路径用起来，等调用量和稳定性要求都上来了再评估自建。卡型与规格的现状到 /compute/gpus 核对，别按半年前的信息下单。

第四步：灰度上线与后续治理

上线别搞大爆炸。先挑一个内部工具类场景试点，重点不是效果，而是验证接入层、监控、计费口径三件事都对得上。跑通之后再往核心业务推，一次只放一个新业务进来，接入完跑稳两周再加下一个，避免问题叠加时分不清是谁引起的。

• 降级路径：模型不可用时业务侧返回什么，提前定好并演练一次
• 额度熔断：单个业务方打满上限时自动挡住，不影响其他人
• 回退方案：新一代模型切换后发现不合适，能在配置层切回上一档
• 定期复核：调用成本、命中率、失败率各看一遍，不划算的场景砍掉或换档

治理动作要落到人：谁负责看调用成本，谁负责批新业务接入，谁能在线上紧急切换供应商，写清楚。没人认领的复核机制，跑两个月就会停。