1. 从一次真实的架构评审聊起为什么银行需要一个AI中台去年年底我参加过一次某金融机构的内部架构评审会会上争论最激烈的一个话题是算法团队想上一套新的推荐模型工程团队说你们直接给个API不就行了而运维团队则拍桌子说上次那个模型上线之后GPU利用率连15%都不到这次又要买卡。三方各执一词谁也说服不了谁。这个场景在金融行业里太常见了——算法、工程、运维、业务四条线各自为战模型从实验室到生产环境要经过漫长的翻译过程最后上线的东西往往和最初的设计目标差了十万八千里。这就是AI中台要解决的核心问题。它不是某一个具体的模型也不是某一套算法框架而是一层介于底层算力资源和上层业务应用之间的能力抽象层。用一句话概括AI中台让算法工程师不用关心GPU在哪台机器上、不用关心模型怎么打包成容器、不用关心流量怎么调度只需要专注于模型本身的训练和调优。而工程团队则通过中台提供的标准化接口像调用普通微服务一样调用AI能力。我之所以拿银行场景来聊这件事是因为金融行业对AI中台的需求比其他行业更迫切也更复杂。一方面银行有海量的结构化数据交易流水、征信记录、客户画像和非结构化数据客服录音、合同文本、监控视频这些都是AI模型的优质燃料另一方面银行受到的监管约束极严模型的可解释性、数据隐私保护、审计追溯都有硬性要求。你不能像互联网公司那样先上线再迭代任何一个模型出问题都可能引发合规风险。所以当我看到光大银行人工智能技术中台建设与思考这个题目时第一反应是这是一个典型的带着镣铐跳舞的工程问题。它要同时满足四个看似矛盾的目标——敏捷业务部门要快速看到AI效果、稳定7×24小时不能出故障、合规每一步操作都要可审计、成本可控不能无限堆GPU。下面我就从架构设计、核心模块、实操落地、踩坑经验四个维度把这件事拆开来讲。2. 整体架构设计四层解耦与三大核心原则2.1 为什么选择四层架构而不是大一统平台很多团队在建设AI中台时容易犯一个错误试图用一个平台解决所有问题。结果就是平台越做越臃肿算法团队觉得不好用工程团队觉得维护成本太高最后变成一个谁都不满意的四不像。我在实际项目中总结出来的经验是AI中台必须做分层解耦每一层只解决一类问题。具体来说我倾向于把AI中台划分为以下四层层级核心职责关键技术选型面向对象资源层GPU/CPU算力池化、存储管理、网络隔离Kubernetes 设备插件 分布式存储运维团队平台层训练调度、推理服务、模型仓库、特征商店容器编排 模型服务框架 特征平台算法团队能力层OCR、NLP、语音、风控等标准化AI能力预训练模型 微调流水线 API网关工程团队应用层智能客服、反欺诈、信贷审批等业务场景业务系统 中台SDK业务团队这个分层逻辑的核心思想是每一层只暴露标准接口给上一层层与层之间通过API契约解耦。资源层不需要知道上面跑的是什么模型平台层不需要知道下面用的是哪家厂商的GPU能力层不需要知道具体是哪个业务在调用。这样一来任何一层的技术升级都不会影响其他层。我见过一些团队为了省事把训练和推理混在同一套Kubernetes集群里结果训练任务把GPU显存吃满推理服务直接OOM。后来他们不得不做物理隔离反而增加了成本。所以我的建议是训练集群和推理集群从一开始就分开训练集群可以容忍一定的调度延迟追求的是吞吐量推理集群要求低延迟高可用追求的是稳定性。两者对硬件和调度的需求完全不同混在一起就是给自己找麻烦。2.2 三大核心设计原则可复用、可观测、可治理除了分层解耦还有三个原则贯穿整个中台的设计。第一个原则是可复用。银行内部不同业务线对AI能力的需求有大量重叠——比如OCR能力信用卡中心要用它识别身份证信贷部门要用它识别银行流水运营部门要用它识别合同扫描件。如果每个部门都自己搭一套OCR服务那就是巨大的浪费。中台的做法是把OCR封装成一个标准化能力通过API网关暴露出去所有部门共用同一套底层模型只是在上层做不同的后处理逻辑。这样既保证了模型的一致性又降低了维护成本。第二个原则是可观测。这一点在金融场景下尤其重要。监管要求你必须能回答这些问题这个模型是什么时候上线的用的是哪批数据训练的训练时的超参数是什么线上推理的延迟和准确率是多少如果出了问题能不能快速回滚到上一个版本所以中台必须内置完整的日志、监控、追踪体系。我的做法是每一次模型训练都生成一个唯一的版本号关联数据集版本、代码commit、超参数配置每一次推理请求都记录请求ID、模型版本、输入输出摘要、耗时。这些数据不仅用于排查问题也是合规审计的证据。第三个原则是可治理。AI中台不是法外之地必须纳入企业整体的IT治理体系。这包括权限管理谁能发布模型、谁能调用哪些能力、配额管理每个部门每月能用多少GPU小时、审批流程新模型上线需要经过哪些评审、安全策略敏感数据不能出隔离区。我见过一个反面案例某团队的中台没有配额限制结果一个算法工程师不小心提交了一个死循环的训练任务把整个集群的GPU占满了三天其他所有团队的工作全部停摆。从那以后配额管理就成了我设计任何中台系统的必选项。3. 核心模块拆解从GPU池化到模型服务化3.1 资源层GPU池化的三种方案与选型逻辑GPU资源管理是AI中台最底层、也最容易被低估的模块。很多团队觉得买几台GPU服务器装个Kubernetes就完事了但实际上GPU池化的复杂度远超普通CPU资源调度。目前主流的GPU池化方案有三种方案一整卡分配。每个训练任务独占一张或多张GPU卡通过Kubernetes的设备插件机制实现。优点是实现简单、性能无损缺点是利用率低一个任务哪怕只用10%的显存整张卡也不能给别人用。方案二显存切分。通过NVIDIA的MIGMulti-Instance GPU技术把一张物理GPU切分成多个逻辑实例每个实例有独立的显存和计算单元。优点是隔离性好、利用率高缺点是对GPU型号有要求目前主要支持A100及以上且切分粒度固定。方案三时间片轮转。多个任务共享同一张GPU通过时间片调度轮流使用。优点是灵活性最高缺点是任务间会相互干扰不适合对延迟敏感的推理场景。我在实际项目中的选择是训练场景用整卡分配推理场景用显存切分开发调试场景用时间片轮转。这个组合的逻辑是训练任务通常需要大显存和持续的高算力整卡分配能保证性能推理任务对延迟敏感但对算力需求波动大显存切分能让多个小模型共享一张卡开发调试场景对性能要求不高时间片轮转能让更多人同时使用。注意GPU池化不是越细越好。我见过一个团队把每张卡切成7份结果每个任务分到的显存连一个BERT-base都跑不起来最后不得不重新调整。切分粒度要根据实际模型大小来定一般建议单实例显存不低于16GB。3.2 平台层训练调度与推理服务的工程实现平台层是算法工程师直接接触的部分它的易用性决定了中台能否真正被用起来。训练调度方面核心要解决三个问题排队、优先级、抢占。银行内部的GPU资源永远是供不应求的所以必须有一套公平的调度机制。我的做法是引入两级队列一级是按部门划分的队列保证每个部门都有基础配额二级是部门内部的队列由部门管理员自行分配优先级。当GPU资源空闲时可以跨部门借用当资源紧张时按优先级和提交时间排序。训练任务的另一个痛点是环境依赖。算法工程师的代码往往依赖特定版本的PyTorch、CUDA、Python库如果每次都要手动配环境效率极低。中台的做法是提供标准化训练镜像基础镜像预装常用框架和CUDA算法工程师只需要在Dockerfile里声明额外的依赖即可。更进一步可以支持自定义镜像仓库让团队把自己的环境固化下来下次直接复用。推理服务方面核心要解决的是模型加载和流量调度。一个训练好的模型文件可能有好几个GB如果每次请求都重新加载延迟无法接受。所以中台需要维护一个模型缓存池常用的模型常驻显存不常用的模型按LRU策略淘汰。同时推理服务要支持多版本共存和灰度发布——新模型上线时先切5%的流量观察一段时间没问题再全量切换。这里有一个容易被忽略的细节模型预热。很多团队在模型上线后发现前几个请求特别慢就是因为模型还没加载到显存里。我的做法是在服务启动时主动发送一批预热请求把模型暖起来再接入流量。这个小小的优化能把P99延迟降低50%以上。3.3 能力层标准化AI能力的封装与复用能力层是中台对外的门面业务团队直接调用的就是这一层。它的设计目标是让不懂AI的人也能用上AI。以OCR能力为例一个标准的封装应该包含以下要素输入规范支持图片URL、Base64编码、二进制流三种输入方式输出规范统一返回JSON格式包含文字内容、置信度、坐标框错误码体系区分图片格式错误、图片过大、识别失败等不同错误限流策略每个调用方有独立的QPS配额超限返回429计费埋点记录每次调用的资源消耗用于内部成本分摊这些看起来都是工程细节但正是这些细节决定了中台能不能被大规模使用。我见过太多中台项目算法模型做得很好但API设计得一塌糊涂业务团队用了一次就不想再用第二次。能力层的另一个关键是版本管理。假设OCR能力从v1升级到v2识别准确率提升了但输出格式变了。如果直接替换所有调用方都会受影响。正确的做法是新旧版本并行运行调用方通过API版本号选择。等所有调用方都迁移到新版本后再下线旧版本。这个过程可能需要几个月但这是保证业务连续性的必要代价。4. 实操落地从零搭建一个AI中台的最小可行方案4.1 环境准备与基础组件安装如果你现在要在一个中小型团队里落地AI中台我建议不要一上来就追求大而全而是先做一个最小可行版本。下面是我在实际项目中验证过的一套方案可以在两周内跑通。硬件准备至少3台GPU服务器建议NVIDIA A10或A1001台管理节点CPU即可共享存储NFS或Ceph。基础软件栈# 1. 安装Kubernetes以v1.28为例 # 管理节点执行 kubeadm init --pod-network-cidr10.244.0.0/16 # 2. 安装GPU设备插件 kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.0/nvidia-device-plugin.yml # 3. 安装网络插件Calico kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/calico.yaml # 4. 验证GPU资源 kubectl describe node gpu-node-name | grep nvidia.com/gpu存储准备AI中台需要三类存储——数据集存储大容量、低性能要求、模型存储中等容量、高可靠性、日志存储高写入吞吐。我建议用NFS做数据集和模型存储用Elasticsearch做日志存储。镜像仓库搭建一个私有Harbor仓库用于存放训练镜像和推理镜像。这一步很关键因为银行内网通常无法直接访问外部镜像源。4.2 训练流水线的搭建与参数配置训练流水线的核心是把数据准备→模型训练→模型评估→模型注册这四个步骤串起来。我推荐用Kubeflow Pipelines或Argo Workflows来实现。以下是一个简化的训练流水线配置示例# training-pipeline.yaml apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: name: bert-finetune-pipeline spec: entrypoint: training-pipeline templates: - name: training-pipeline steps: - - name: prepare-data template:># config.pbtxt name: bert_classifier platform: pytorch_libtorch max_batch_size: 32 input [ { name: input_ids data_type: TYPE_INT64 dims: [128] } ] output [ { name: logits data_type: TYPE_FP32 dims: [2] } ] instance_group [ { count: 2 kind: KIND_GPU gpus: [0] } ] dynamic_batching { preferred_batch_size: [8, 16, 32] max_queue_delay_microseconds: 1000 }几个关键配置的说明max_batch_size最大批处理大小根据显存和延迟要求调整instance_group.count每个GPU上启动的模型实例数一般设为2-4dynamic_batching动态批处理能把多个小请求合并成一个大batch显著提升吞吐量max_queue_delay_microseconds最大排队延迟设太小批处理效果差设太大延迟高实测下来开启动态批处理后BERT模型的吞吐量能从200 QPS提升到800 QPS而P99延迟只增加了不到5ms。这个 trade-off 在大多数场景下都是值得的。5. 踩坑实录那些文档里不会写的经验教训5.1 常见问题速查表问题现象可能原因排查思路解决方案训练任务卡在数据加载存储IO瓶颈检查NFS带宽和IOPS改用本地SSD缓存或Ceph推理延迟突然飙升模型缓存被淘汰查看显存使用率和缓存命中率增加常驻模型数量或扩容显存GPU利用率长期低于20%任务粒度太小分析任务队列和GPU分配记录合并小任务或启用时间片轮转模型上线后准确率下降训练/推理数据分布不一致对比训练集和线上请求的特征分布重新采样训练数据或加特征对齐层多版本模型冲突依赖库版本不兼容检查各模型的requirements用独立容器隔离不同模型5.2 三个让我印象深刻的踩坑经历第一个坑GPU显存碎片化。早期我们的推理服务是每个模型一个进程跑了一段时间后发现明明显存总量够但新模型就是加载不进去。后来用nvidia-smi仔细看才发现显存被切成了很多小块没有一块能容纳新模型。原因是不同模型的生命周期不同频繁加载卸载导致显存碎片化。解决方案是引入显存池化机制预分配一大块显存由中台统一管理分配和回收。第二个坑训练数据版本混乱。有一次两个团队同时训练模型用的都是最新版数据集但结果差异很大。排查了半天才发现一个团队用的是当天上午的数据快照另一个用的是下午的。数据在中午更新过一次但没有人记录这个变更。从那以后我们强制要求每次训练必须指定数据集版本号数据集更新必须走审批流程并生成新版本。第三个坑模型上线没有回滚方案。一个新版本的风控模型上线后误杀率突然升高但旧版本已经被覆盖了无法快速回滚。我们花了四个小时重新训练和部署旧版本期间业务损失惨重。现在的做法是任何模型上线都必须保留至少两个历史版本且回滚操作必须能在5分钟内完成。5.3 独家避坑技巧给每个训练任务打标签包括提交人、部门、项目名称、预计时长。这样当资源紧张时可以快速判断哪些任务可以暂停。推理服务一定要做压测上线前用真实流量回放做压测观察P50、P95、P99延迟和错误率。我见过太多服务在低流量下没问题一上量就崩。监控要覆盖模型层面除了CPU、内存、GPU这些基础设施指标还要监控模型的输入分布、输出分布、置信度分布。这些指标能帮你提前发现数据漂移。定期做故障演练主动杀掉某个推理实例看服务能不能自动恢复主动断开存储看训练任务能不能优雅退出。这些演练能暴露很多平时发现不了的问题。6. 关于AI中台建设的一些个人思考做AI中台这几年我最大的体会是技术不是最难的部分组织和流程才是。你可以用两周时间搭出一套能跑的Kubernetes集群但要让算法团队愿意用、工程团队愿意维护、业务团队愿意调用可能需要两年。一个中台项目能不能成功往往取决于三个非技术因素第一有没有一个强势的推动者能在部门之间协调资源和利益第二有没有一套清晰的SLA明确中台团队和业务团队各自的责任边界第三有没有持续的运营投入中台不是建完就完了需要不断迭代和优化。另外我越来越觉得AI中台不应该追求大而全。与其做一个什么都想管的平台不如先聚焦一两个高频场景比如OCR和NLP把这两个场景做到极致让业务团队真正感受到价值然后再逐步扩展。贪大求全的结果往往是哪个场景都没做好最后被业务团队抛弃。最后分享一个我常用的判断标准如果一个中台功能业务团队用了一次就不想用第二次那这个功能就是失败的。中台的价值不在于技术多先进而在于能不能让业务团队用了还想用。这个标准听起来很简单但真正做到并不容易。