很多团队做大模型落地，第一步就是买卡、部署一个开源模型，然后发现业务接不上、成本算不清、换模型要重做一遍。问题往往不在模型，而在中间缺了一层把模型、算力、数据、权限、账目统一管起来的平台。这篇按「分层 + 上线顺序 + 验收口径」讲 AI 中台该搭哪些模块、每块先做到什么程度算及格，以及在什么情况下这套搭法并不适用。
很多团队做大模型落地，第一步就是买卡、部署一个开源模型，然后发现业务接不上、成本算不清、换模型要重做一遍。问题往往不在模型本身，而在中间缺了一层把模型、算力、数据、权限、账目统一管起来的平台。这层平台通常就叫 AI 中台。
这篇不讲概念定义，只讲三件事：中台分哪几层、每层先做到什么程度算及格、先上哪块后上哪块。最后说清楚在什么情况下这套搭法并不适用——不是所有公司都需要中台，硬搭反而多一层故障点。
先分层：中台到底要切几刀
比较稳的切法是四刀：接入层、调度层、能力层、治理层。接入层管谁能调、配额多少；调度层管这次请求走哪个模型、走本地还是走外部接口；能力层管知识库、提示词模板、工具调用；治理层管钱、日志、合规。层与层之间只暴露接口，不允许跨层直连。
千万别按部门切——研发一个、客服一个、销售一个。这样最后一定变成三套模型账号、三份账单、三份日志，等你想合并的时候，成本比一开始就统一还高。如果只想解决最痛的问题，先做接入层加治理层就能覆盖大部分团队「谁在花多少钱、出了事查不到」的诉求。
| 层 | 管什么 | 先做到什么算及格 |
|---|---|---|
| 接入层 | 身份、配额、限流 | 每个 key 有归属人和用途备注 |
| 调度层 | 选模型、路由、降级 | 换模型不改业务代码 |
| 能力层 | 知识库、模板、工具 | 同一问题不同人问出同一答案 |
| 治理层 | 账目、日志、合规 | 任意一次调用能查到来源与花费 |
模块清单与上线顺序
模块不用一次做全，但要按依赖关系排顺序。第一批解决「看不见」的问题，第二批解决「对不齐」的问题，第三批才碰重资产。下面的顺序是按依赖排的，跳步做通常会返工。
- 第一批：接入与账目统一调用网关（key 托管、限流、配额）、调用日志与用量归集、模型清单与切换开关。验收方式：随便挑一次历史调用，能在后台查到它的归属人、走的哪个模型、花了多少额度。
- 第二批：知识与模板集中把散在各人电脑上的向量库和 prompt 收拢到统一管理。验收方式：同一个业务问题，两个不同的人通过中台提问，答案口径一致。
- 第三批：重资产模块微调流水线、私有化推理集群、多租户计费。这些要依赖前两批产出的真实调用数据来定规格，没数据就上，规格基本靠猜。
自查顺序很简单：先问「现在有多少个模型 key 散在多少人手里」。答案超过一只手，就先做接入层，别急着讨论微调和私有化。
算力与额度：按调用量倒推，别按峰值买
算力规格不该拍脑袋定。用近一个月的日志统计三个数：日均请求数、平均输入输出长度、峰值与均值比。这三个数决定要几张卡、要不要留外部接口兜底。具体的量化档位、显存与并发的换算，到 /compute/sizing 按你的模型规模算一遍，再去 /compute/gpu-rental 比一轮租金。
还要把「稳定业务」和「试错业务」分池。稳定业务走固定部署保延迟，试错业务走按量接口，额度用完自动降级——别让实验把生产挤挂。这是中台调度层最值钱的一个功能，很多团队上线半年后才补，补的时候已经出过事故了。
- 统计周期至少覆盖一个完整业务月，避开促销或月末集中调用的干扰
- 峰值与均值比超过某个倍数时，优先考虑外部接口兜底而不是自建满配
- 稳定池和试错池的额度分开配置，试错池超限自动排队而不是静默失败
- 不适用：调用量小且波动极大时，自建卡池的闲置成本会高于按量付费，这时中台只做网关和账目即可
自建算力省不省钱，取决于闲置率，不取决于单价。
治理层：许可证、数据边界与回退
治理层不是加个日志就完事。每个上架的模型要记三项：许可证与商用边界、数据是否出内网、上游服务等级。这三项里有一项说不清，就不许上生产。合规与授权口径可以对着 /safety 和 /ai-dict/category/safety 逐条核，别用网上二手的结论。
统一出口做内容与敏感信息过滤，别指望各业务自己写。同时保留原始请求样本用于排查，但要脱敏并限定保存周期。模型换代必须预留回退：切换开关、灰度比例、效果对比入口三样齐备，新模型先接一小部分流量，指标不达标一键切回。
- 许可证与商用边界
- 记清楚这个模型能不能商用、有没有附加条款，写进模型清单而不是留在采购邮件里
- 数据是否出内网
- 标注调用链路是否经过公网，涉及敏感数据的场景只能走内网部署
- 上游服务等级
- 记下上游的可用性承诺与停服通知机制，作为回退预案的输入
- 灰度比例
- 新模型上线初期只接一部分流量，比例可调，不是一次全量
验收标准与常见返工点
中台做没做实，用四条及格线验一下：任意一次调用能查到来源与花费、换模型不改业务代码、额度超限自动降级、敏感数据不出内网。四条全过才算基础可用，缺哪条补哪条。
| 返工点 | 表现 | 正确做法 |
|---|---|---|
| 日志只记成功请求 | 排查超时和失败时找不到证据 | 成功、失败、超时都入库，带上 trace id |
| 模型清单写死在代码里 | 换一次模型要发版 | 清单放配置中心，切换走运行时开关 |
| 没有断供演练 | 上游停服后业务停摆 | 每季度演练一次切备选，记录切换耗时 |
指标数字别信二手转述，自己去站内看当时的：调用量级参考 /usage，价格与规格变动看 /price-watch 和 /official-api。每季度的断供演练也要记录切换耗时，切不了就说明中台没做实。
下一步想先看看别人家的接入方式和中转站可信度怎么判，可以翻站内的站点目录和检测口径，再决定自己第一刀切在哪层。→常见问题
预算有限，AI 中台能只做一半吗？
能，而且建议只做一半。优先做接入网关和用量账目这两块，它们不依赖算力投入，却能立刻解决 key 散落、成本说不清的问题。知识库、微调流水线、私有化集群都放到第二年，等真实调用数据出来再定规格，否则很容易按想象买卡然后闲置。
中台和直接用现成的开源平台有什么区别？
开源平台解决的是「跑起来」，中台解决的是「谁来管」。前者给的是部署和对话界面，后者要补上统一鉴权、多模型路由、额度与账单归集、许可证登记这些运营层面的东西。可以先拿开源平台做底座，把治理层自己补上，不必从零造。具体工具对比看 /stacks/frameworks 和 /stacks/vector-dbs。
怎么判断中台该不该继续投入？
看两个信号：一是业务方接新模型的平均耗时有没有下降，二是每次调用的成本能不能说清。这两个指标不动，说明中台只是多了层转发。反之如果接模型从几天缩到几小时、账单能按部门拆开，就值得继续加模块。前提是调用量足够大，量很小的时候收益体现不出来。
