上个月帮一家企业做架构评审我打开他们的“AI中台”目录时愣了一下同一个BERT模型被复制成了七八份命名靠日期后缀有的在finetune之前有的在finetune之后更离谱的是只要拿到内网IP和端口任何服务都能直接调推理接口完全没有鉴权。这不是个例很多号称AI中台的项目本质上只是把训练脚本和模型文件挪到了一块共享盘上。这篇内容想聊的是企业级AI中台架构设计里最容易被忽略、也最影响成败的三件事模型管理、服务编排、权限控制。我会从架构设计角度拆开讲清楚每部分到底要解决什么问题为什么必须这么做以及在SpringBoot这类技术栈里落地时常见的坑。适合正在做中台建设的架构师、平台组工程师以及打算引入AI能力但不想把业务代码搞成一团乱麻的技术负责人。1. 大中台不是大杂烩先划清AI中台的职能边界1.1 中台与业务系统的三层关系很多团队一提中台就恨不得把能复用的东西全塞进去最后中台变成了一个巨大的业务系统改哪里都牵扯不清。AI中台首先要解决的是“边界”问题。我习惯把系统分成三层基础设施层、中台平台层、业务应用层。基础设施层提供GPU算力、存储、网络中台平台层负责把模型变成可复用、可治理、可观测的服务业务应用层则面向最终用户实现具体的交互和业务逻辑。AI中台应该收敛的是“模型全生命周期管理、服务化封装、服务编排、统一权限控制、监控审计”这些能力。它不应该替业务团队实现具体的规则逻辑也不应该直接面向C端用户。把这个边界画清楚后面所有的架构决策都会简单很多。1.2 四个必须收敛的公共能力我梳理过多个中台项目能称得上“中台”的至少要在平台层收敛四件事模型注册与版本管理所有模型必须在一个地方登记有唯一标识、状态、版本、元数据。模型推理服务化把模型包装成标准接口调用方不关心模型是TensorFlow、PyTorch还是ONNX。服务编排与组合多个模型服务可以按业务场景编排成一个流程而不是让业务系统自己串。统一认证与权限控制不管是人还是系统调模型必须有身份、有授权、有审计。这四件事缺了任何一件中台都会退化成“共享盘”。1.3 需要留在业务侧的边界同样重要的是明确什么不能收进中台。业务特征极强的数据处理、业务规则、前端流程、会话状态管理这些都应该留在业务应用层。举个例子知识库问答里的“文档解析规则”和“答案后处理”往往和业务强相关如果你强行把它们下沉到中台中台就得不断适配各种业务方的奇葩需求最终变成开发瓶颈。我见过一个失败案例中台团队花了两个月做了个通用文档解析器结果上线后每个业务方都要加自己的解析规则代码里全是if分支远比让各业务方自己用解析SDK更糟糕。核心原则中台管模型不管业务管服务编排不管界面流程管权限模型不替业务定义角色。2. 模型管理版本、血缘、评估和生命周期缺一个后面都会还债2.1 模型注册中心设计一份元数据描述一个模型模型管理的第一步不是建文件夹而是建注册中心。注册中心里每个模型都应该有唯一ID关联一组不可变版本版本下面再挂一份完整元数据。一个最小可用的模型元数据大概长这样{ model_id: text-cls-bert, model_name: 文本分类-BERT, owner: alg-platform, versions: [ { version: 1.3.0, framework: pytorch, format: torchscript, artifact_path: s3://models/text-cls-bert/1.3.0/model.pt, sha256: 9f2c92..., status: prod, input_schema: {text: string, max_len: 128}, output_schema: {label: int, probability: float}, train_metrics: {acc: 0.967, f1: 0.963}, code_version: release/2024.11.15, deploy_time: 2024-11-16T10:00:00Z } ] }我特别要强调code_version和artifact_path这两个字段。模型文件必须和训练/推理代码版本关联起来不然回滚模型时很可能发生“模型是旧的、代码是新的”这种错位问题。后面专门讲这个坑。2.2 版本管理与灰度发布同一个模型名背后是多个版本模型版本管理不能靠模型文件名带_v2、_final来维护。要用不可变地址指向模型文件每次发布一个模型版本就生成一个不可变的存储路径和哈希值。这样任何环境都能精确知道跑的是哪一版模型。有了版本之后灰度发布就成了必须能力。新模型先在staging环境验证再以金丝雀方式切5%流量确认指标没有回退后逐步扩大。模型注册中心里的状态机至少要有dev、staging、prod、deprecated、archive。生产环境的服务只能引用statusprod的版本从机制上避免乱发布。我当时给团队定的规则是模型版本一经发布就不可变想修改指标记录或元数据必须发新版本。虽然一开始大家嫌麻烦但三个月后做线上问题回溯时会感谢这个决定。2.3 数据血缘与评估记录模型不是调完参就完事了只记录acc和f1远远不够。企业级模型管理还要记录“这个模型是用哪份数据集训练出来的”“训练集和测试集如何划分”“评估集有哪些badcase”。这就是模型血缘。有了血缘才能回答三个实际问题线上效果变差是数据变了、模型过期了、还是上游特征变了这个模型能不能安全回滚某个用户投诉问题是否在测试集覆盖范围内我在模型注册中心里保留一份评估报告内容包括训练样本数、样本时间窗口、分布变化、各分位的预测置信度、典型badcase。数据量不大但价值极高。有一次业务方说模型“变笨了”我们通过血缘发现训练集里缺少最近一个月的增量数据问题在数据管道而非模型本身几分钟就定位了。2.4 多环境管理开发环境、预发、生产环境的模型隔离模型和代码一样需要环境隔离。如果开发环境的模型和生产环境共用一套存储那测试时一个误操作就会影响线上服务。建议按环境做命名空间隔离环境模型注册表推理服务数据库devdev-registrydev-inferencedev-metastagingstaging-registrystaging-inferencestaging-metaprodprod-registryprod-inferenceprod-meta每个环境的模型状态机独立模型从dev晋升到staging再到prod需要走审批流。审批流一方面是为了安全另一方面是强制记录“谁在什么时候把哪个版本提升到了生产”这本身也是审计需求。3. 服务编排从“接口直连”走向“可编排、可观测、可治理”3.1 为什么单模型接口不够用还需要编排层实际业务很少只调用一个模型。以智能客服为例一次请求往往要经历问题分类、情感识别、知识库检索、答案排序、大模型生成每一步可能调不同的模型服务。如果没有编排层这些调用顺序就被硬编码在业务代码里改一个环节就要重新发布业务系统而且看不到整个请求在哪个环节变慢。编排层的本质是把这个“调用链”从业务代码里抽出来变成一份可配置的DAG有向无环图。它至少要做四件事按依赖关系并发或串行调用模型服务对每个节点设置超时、重试、熔断在节点之间做数据格式转换和上下文传递记录每个节点的调用耗时和结果供监控分析。3.2 同步编排与异步任务编排的选型AI服务分两类场景在线推理和离线批量计算。它们的编排方式完全不同。在线推理场景用户请求必须实时返回编排引擎要极快且不能因为单个模型超时拖垮整个请求。适合用轻量级DAG引擎甚至直接在网关层做同步编排。异步任务场景比如批量文档向量化、定时模型评测允许几分钟甚至几小时的任务适合用消息队列加任务调度引擎。场景特征推荐手段关键指标在线推理低延迟、高并发、请求有终态同步DAG引擎 / API网关编排TP95延迟、成功率离线任务长时间、批量、可中断消息队列 分布式任务调度吞吐、失败重试很多人一开始就用重型工作流引擎跑在线推理结果全链路多了几十毫秒开销得不偿失。在线编排应该轻离线编排可以重这个千万别搞反。3.3 服务网关的一等公民限流、熔断、优先级模型推理服务是昂贵的资源尤其GPU。所以编排层前面必须有一层网关能做限流、熔断、优先级调度。限流不能只按全局QPS做要按“模型 调用方 资源池”组合来做。举个例子同一个文本分类模型A业务是核心交易链路B业务是内部测试两者并发很高时必须保证A业务的请求优先通过。实现上可以用令牌桶或漏桶算法在网关层为每个调用方分配配额同时设置最大并发数。扩容跟不上流量突增时快速失败比排队更有价值。我见过一个线上事故模型服务已经跑满网关还在继续往服务发请求结果每个请求都超时重试最终雪崩。正确做法是网关层设置并发信号量超过阈值直接返回503让上游业务走自己的降级逻辑而不是无限堆积。3.4 一个最小编排引擎的抽象设计如果你不想一开始就引入重引擎可以设计一个极简抽象graph: - id: intent_cls type: model model: text-cls-bert owner: alg-team timeout_ms: 300 retry: 1 - id: sentiment_cls type: model model: sentiment-roberta timeout_ms: 300 depends_on: intent_cls - id: kb_search type: model model: dense-retrieval timeout_ms: 800 depends_on: sentiment_cls - id: answer_gen type: deep_model model: llm-generator timeout_ms: 2000 depends_on: kb_search执行器解析这份配置依赖关系里depends_on为空或已完成就放到线程池并发执行每个节点有独立超时超时后按策略返回缓存或空结果最终把每个节点的结果聚合到一个上下文对象里。不需要K8s、不需要微服务编排平台一个常驻内存的有向无环图和优雅的超时控制就能解决80%的问题。系统复杂到需要水平扩展时再考虑组件化也不迟。4. 权限控制把人、服务、数据三层权限建清楚漏一层都出事4.1 RBAC和ABAC不是二选一中台场景建议先用RBAC再升级ABACAI中台的权限控制比其他业务系统更需要“多维度”。因为调用方有两种人以及系统服务。不能只做人的登录权限而忽略了服务之间的鉴权。权限模型上我建议大多数团队从RBAC基于角色的访问控制起步。先把用户、角色、权限三张表设计好再把“模型操作权限”和“服务调用权限”抽象成权限点。到了需要根据部门、项目、数据密级、时间等因素动态决策的场景再升级ABAC基于属性的访问控制。RBAC的核心设计并不复杂但有一个关键权限点要足够细。比如模型管理端查看模型、申请发布、审核发布、模型下线模型调用端调用某模型、查看某模型Metrics、访问某知识库数据端查看某知识库文档、导出某数据集。粒度粗了权限控制等于摆设粒度细了用户角色配置成本又高。解决方法是预置“角色模板”比如“算法工程师”“平台运维”“业务调用方”模板里预置一组权限点新用户加入时直接套模板。4.2 用户权限从登录到TokenSpringBoot能做什么热词里有人问“SpringBoot到底如何实现权限控制”这里给一条我已经验证过多次的实现路径。如果用SpringBoot Spring Security JWT最常见做法是用户登录成功后签发JWTJWT里携带用户ID、角色列表不要放敏感信息在Spring Security配置中增加自定义Filter解析JWT并设置SecurityContext通过注解PreAuthorize(hasAuthority(model:call:12345))控制接口权限数据库使用用户表、角色表、权限表、用户角色关联表、角色权限关联表。示例代码片段Slf4j public class JwtAuthFilter extends OncePerRequestFilter { private final JwtTokenProvider tokenProvider; Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String token resolveToken(request); if (token ! null tokenProvider.validateToken(token)) { var authentication tokenProvider.getAuthentication(token); SecurityContextHolder.getContext().setAuthentication(authentication); } filterChain.doFilter(request, response); } }然后在模型调用接口上做方法级控制PreAuthorize(hasAuthority(model:invoke: #modelId)) PostMapping(/models/{modelId}/invoke) public Result invoke(PathVariable String modelId, RequestBody InvokeRequest request) { return inferenceService.invoke(modelId, request); }这个方案的关键不是代码而是“权限模型必须来自数据库”而不是埋在代码里。理想情况下每次分配模型调用权限都应该走管理端配置而不是改代码发版。4.3 服务间权限mTLS与Token传递服务之间互相调用时用户的JWT不能直接透传给下游因为下游只想知道“这次调用是否有权限”而不需要知道用户的登录状态。更稳妥的方案是引入服务身份凭证。常用方案有两个每个服务申请独立的ClientId/Secret调用时使用客户端凭证模式申请短时Token更严格的环境使用mTLS做服务间双向证书校验。我更推荐组合使用对外部用户的身份用用户Token对内部服务调用用服务凭证同时配合内部网关做二次校验。因为AI中台是一个高度敏感的服务集群一旦某个内部服务被攻破如果缺少服务鉴权攻击者可以顺着网络横向调用所有模型。4.4 数据行级权限知识库如何控制权限到人“知识库如何控制权限到人”是知识类业务最常见的需求。权限不只是“能访问哪个知识库”还要精确到知识库里的某段文档、某个知识点对谁可见。知识库检索链路通常分三步文档解析、向量化、检索。权限控制最合理的位置在向量化阶段和检索阶段。错误做法只在应用层过滤答案。因为向量化是把整篇文档切块后存入向量库的如果你不做权限控制用户通过接口直接检索向量库可能把本不该看到的文档块也能捞出来。我建议采用方案B给每个文档块打权限标签。{ doc_id: doc-001, chunk_id: chunk-012, content: 关于产品退款政策的内部说明……, permission_tag: perm:refund:internal, tenant_id: tenant-a }检索时在向量数据库查询条件里强制加一个过滤条件where permission_tag in (用户标签集合) and tenant_id 用户租户ID。权限标签可以设计成从用户的部门和角色动态推导比如“财务部员工”自动获得perm:finance:*知识库创建时选择可见范围文档块继承这个范围。这样设置一次后续检索时始终强制过滤性能影响也不大。另外不要直接把向量数据库地址暴露给前端所有检索必须经过统一API服务把用户权限上下文注入检索SQL。4.5 审计日志与权限审批每一次调用都要可溯权限系统做到最后拖垮进度的往往是审计。但审计必须做。至少要为如下行为留下日志登录、注销、刷新Token模型发布、版本变更、下线模型调用记录谁调用、调哪个模型、输入是否可脱敏、返回码、耗时知识库权限变更谁给谁授予了哪个标签的访问权。权限变更要走审批流最好不要由管理员直接改库。后台接口、审批接口、日志接口分开审计日志只追加不修改。平时用不上一旦遇到客户数据投诉或内部违规事件这套记录就是救命稻草。5. 落地时最容易翻车的三个细节提前避开5.1 模型文件与代码版本不联动导致回滚回错这几乎是所有AI中台上线后必踩的坑。模型注册中心里只记录了模型文件忽略了推理代码版本当线上模型效果突然下降要回滚时运维直接回滚到上一个模型文件却发现推理代码已经变了导致输入输出解析全部错位。我现在的强制要求是模型版本与推理镜像标签必须原子发布。每次发模型版本时同时打一个包含模型文件地址和推理代码版本的镜像标签。回滚时一起回滚不允许只回滚模型文件。这是一个架构层面的约定比任何文档都管用。5.2 权限控制只做了接口层没做数据层很多团队给AI服务加了JWT校验就认为权限安全了。实际上还要检查两件事第一向量数据库、模型文件存储、消息队列这些基础组件是否直接暴露给了业务方如果是那么业务方完全可以绕过中台API直接访问底层数据。结论是所有基础组件必须在内网隔离区只有中台服务能访问。第二模型调用权限是否只控制了“能不能调接口”而没有控制“能调哪些模型”有些实现把所有模型放在同一个接口后面服务端用模型ID做路由但鉴权逻辑只检查接口权限没检查模型ID权限结果就是只要拿到接口访问权就能调用所有模型。必须用本文4.2节的方法级鉴权把模型ID作为权限点才好。5.3 流量突增时GPU排队导致超时雪崩模型服务的容量规划经常被忽略。假设一个GPU实例一次只能处理1个请求单次推理耗时100ms那么单个实例的极限QPS只有10。如果你想要60QPS就至少需要6个实例而且还要留出30%~50%冗余否则任何慢请求都会让排队时间急剧上升。很多时候问题不在于并发不够而在于网关没有做快速失败。我建议在线推理服务在网关层同时配置两个数字最大并发数和最大排队时间。超过最大并发直接返回503排队超过200ms也直接返回503。业务方看到503后可以走自己的降级逻辑这比所有请求都慢到30秒要好得多。以下是一份简单容量参考表假设单请求平均100ms目标QPS单实例并发数所需实例数建议实例数含50%冗余101126016910011015这个表格虽然简单但在评审阶段能快速说服业务方给出真实容量预期避免上线第一天就被流量冲垮。6. 从0到1的落地路线先解决最痛的点再逐步扩展6.1 阶段一模型统一注册与网关鉴权不要一上来就建设大而全的中台。第一阶段只做两件事把已有模型全部纳入注册中心并在所有推理服务前面加统一网关。时间周期一到两周。网关负责鉴权、基础限流、日志。注册中心负责记录模型版本和元数据。这个阶段结束后至少能回答“线上有哪些模型在跑、谁在调用、哪个版本、请求是否正常”这四个问题中台已经比大多数共享盘方案强很多了。6.2 阶段二模型环境隔离与灰度发布第二阶段解决“乱发布导致线上故障”的痛点。把开发、staging、生产环境彻底隔离模型注册表加审批流和状态机生产环境只允许已审批版本上线。同时引入灰度发布能力先切1%流量观察半小时再逐步扩展到5%、20%、100%。发现问题时使用一键回滚同时回滚模型和推理代码镜像。这一阶段大概是三到四周。做完后模型上线才开始变得“可控”。6.3 阶段三编排层与数据权限第三阶段再引入DAG编排引擎和知识库行级权限。这时候已经有清晰的模型目录和统一网关编排引擎只需要对接标准模型接口即可不会出现一边做编排一边还要处理各种模型协议差异的混乱局面。知识库权限先聚焦一种权限模式比如按租户或部门标签过滤。不要一上来就做ABAC否则规则引擎光配置就要写几十页。至于更高级的自动伸缩、成本分摊、模型自动评测那是在跑通以上链路之后的事。地基越干净上层功能越不容易翻车。给正在建设AI中台的团队一句实在话中台不是靠PPT建出来的是靠一条一条权限策略、一个一个模型版本、一张一张链路图磨出来的。先把最痛的那颗钉子拔掉后面的事会顺利得多。