这两年我先后参与过三个 AI 系统的架构设计与重构一个是从零搭起来的推荐类服务两个是接手别人跑得跌跌撞撞的存量系统。反复被验证的一个事实是AI 系统架构的复杂度几乎全在模型之外。很多人一听AI 系统架构下意识想到的就是选什么框架、用什么网络结构、怎么调参但真正上了生产决定系统上限的往往是数据管道怎么设计、推理服务怎么做高可用、模型版本怎么管理这些听起来不那么AI的环节。这篇文章我想完整梳理一套可落地的 AI 系统架构从业务需求如何映射成技术形态到数据层、训练层、推理服务层、应用集成层和平台治理层怎么衔接再到生产环境里最常见的故障长什么样、怎么排查。无论你是正准备从零搭建一个 AI 系统还是正在维护一个已经上线的 AI 服务这篇文章应该都能给你一张可以用来对照的架构地图。1. 先别画架构图把三个业务问题回答清楚1.1 AI 是业务的核心链路还是辅助决策工具这个问题的答案直接决定整套架构的可用性要求和成本投入。如果 AI 是业务的核心链路比如推荐系统、风控模型、智能客服机器人那它出问题用户会直接感知推荐变差了、审核漏过了、客服答非所问。这类系统的架构设计必须围绕高可用、低延迟、可降级来做模型服务要常驻资源要预留冗余发布要有灰度机制。反过来如果 AI 只是辅助决策工具比如给运营看的经营分析、给客服看的答案建议那它一次跑几个小时也没关系架构可以做得简单很多甚至复用已有的离线计算能力。我之前接过一个智能客服项目早期被当成辅助工具设计每天离线批量跑一轮答案用户提问要等很久才能拿到回复业务方觉得根本不智能。后来把它的定位改成核心链路架构完全重做才变成实时响应。这个案例说明定位判断错了后面所有技术选型都会白做。1.2 实时性需求毫秒级、秒级还是小时级实时性需求要拆成三个层级每个层级对应的架构形态完全不同场景类型典型业务延迟指标架构形态在线实时推荐、风控、智能客服P99 通常在 200ms 以内常驻推理服务资源持续占用需要容量规划和弹性扩缩容近线准实时内容理解、画像更新、批量打分秒级到分钟级定时任务或流式窗口触发资源可以错峰使用离线批处理报表分析、全量数据打分小时级到天级分布式批处理任务弹性拉起资源跑完释放很多团队会从离线批处理起步再逐步往在线演进。这个演进过程本身是合理的但要注意每次跨一个层级架构都要动刀子不是简单改个调用方式就行。先想清楚业务到底要哪个层级能省掉后面整个架构翻新的大成本。1.3 团队规模和维护能力决定架构复杂度这是我最想强调的一点。AI 系统架构最大的风险不是缺组件而是组件太多但没人维护。三五人的小团队不要一上来就铺微服务、搭完整平台层。把模型训好、用最简单的服务方式跑起来、留好监控比引入一套健全但没人会用的容器化平台实在得多。我见过一个很小的团队上了多集群架构半年后没人能说清楚依赖关系每次上线都像拆炸弹。我自己定的原则是架构复杂度必须用团队能看懂、能接手来约束。宁可多写文档不要多上组件。等到团队规模、业务复杂度确实撑得起平台化投入时再逐步加层次反而更稳。2. AI 系统骨架五层架构拆开揉碎2.1 数据层离线数据仓库与实时数据管道并存数据层是 AI 系统的地基但很多人对它理解得太简单。一个生产级 AI 系统的数据层至少要同时跑两条管道。离线管道负责把原始日志清洗成结构化数据经过加工落到数据仓库里形成宽表、特征表、样本表。训练要用的全量样本都是从这里来的。实时管道则处理业务事件经过消息队列进流处理引擎产出实时特征写入低延迟的特征存储供在线推理时查询。这两条管道会同时存在原因很朴素训练需要的是完整、准确、可回溯的数据在线服务需要的是快、可用的数据。为了两个目标并存同一份原始数据往往会在不同存储引擎里各存一份这是正常设计不是冗余。一份数据多种用途落到架构上通常就是多份副本、不同引擎。存储选型时要分清读写模式数据仓库系统要扛得住批量大查询在线特征存储要扛得住低延迟随机读两者需求完全相反别指望一个存储引擎通吃。2.2 训练层从单机实验到分布式训练训练层不仅仅是跑模型它由三部分构成开发环境、任务管理、实验跟踪。开发环境是算法工程师日常做实验的地方核心诉求是交互式、可试错。任务管理负责把训练任务提交到算力池做资源分配、排队、优先级调度。实验跟踪负责记录每次实验的数据集版本、代码版本、超参数和结果指标。对小模型来说一台训练机器可能就够了。但一旦模型规模上来、数据量大就要做分布式训练。分布式训练的核心不是框架怎么调用而是三件事算力怎么池化、通信怎么不拖后腿、断点怎么续。2.3 推理服务层在线、近线、离线三种形态同一个模型在真实系统里往往要同时以三种形态部署。在线推理是常驻服务接收 API 请求加载模型实时返回结果。它是延迟敏感型要专门做容量规划、弹性伸缩、动态批处理。近线推理是按固定窗口触发的比如每五分钟对新增的一批内容做理解打标它不苛求单个请求的延迟但要求窗口内能处理完。离线推理是对海量数据批量打分比如给全量用户算一遍推荐候选集它通常复用训练集群的空闲资源。这三种形态共享同一个模型产物架构上要对一次训练、多处部署有清晰支持。我见过很多团队只做了在线推理业务想跑个批量任务时发现没有入口只能临时写脚本这就是架构没把推理形态设计完整的典型表现。2.4 应用集成层业务方怎么调用 AI 能力推理服务之上通常还要有一层应用集成层核心是 API 网关和结果处理。网关负责统一入口、鉴权、限流、路由把业务方的请求转发给对应的推理服务。结果处理负责模型输出的后加工比如格式化、归因解释、兜底逻辑。这里有一个重要的设计原则业务方不应该感知到背后是模型还是规则API 契约在一开始就要定清楚。这样以后模型换规则、规则换模型对业务方都是透明的降级切换也不会惊动上游。降级方案也要在这一层提前设计。模型服务不可用时是返回规则引擎的结果还是返回缓存的历史结果还是快速失败这些决策要在架构阶段就想好而不是故障发生时在值班群里临时争论。2.5 平台治理层模型注册、版本管理与权限审计模型一多治理就不可避免。平台治理层解决的是哪个模型在线上、谁允许它上线、上线之后怎么回滚这些问题。模型注册中心是治理层的核心每个模型有唯一 ID、版本号、来源实验、训练数据范围、离线评估指标、上线记录。有了这个基础才能做到可追溯、可回滚。权限和审计则回答谁训练了它、谁批准了上线、谁改动过服务配置对多人协作的团队来说不是可选项是必需品。我维护存量系统时最大的教训就是没有治理层的系统模型一多必然失控。一个团队里有七八个模型同时在迭代如果不知道哪个版本在线上、上一次实验用的什么数据所有调优都变成玄学。3. 数据管道里最容易被低估的特征一致性问题3.1 特征一致性问题到底是什么特征一致性业内常说的训练服务偏差是 AI 系统里最隐蔽、最难排查的问题之一但它在架构层面的存在感一直被低估。训练样本里的特征是历史数据批量算出来的完整、干净、可以回溯。线上推理时的特征是实时从管道里取出来的可能有缺失、有延迟、单条计算。两边只要有一点口径不一致模型在服务端看到的特征分布就和训练时不一样效果会悄悄变差。举个例子一个最近 7 天购买金额的特征训练代码里按交易日历取最近七天线上实时服务按过去 168 小时的滚动窗口算。周末这种边界时刻两边算出来的数值就差一截。模型在训练时学会了对某个分布的理解上线后发现输入分布变了输出自然偏。这种问题不报错、不告警只会表现为业务指标缓慢下滑很难定位。3.2 特征平台的解题思路一套定义两套执行解决特征一致性问题的行业主流做法是建一个轻量级的特征平台核心思路就一句话特征定义只维护一份离线在线共用。具体落地是把每个特征的定义集中登记离线训练时根据这份定义生成批量计算逻辑在线服务时根据同一份定义生成实时计算逻辑。两边逻辑同源口径天然一致不会再出现训练一套、服务一套。同时还要在特征存储之间做周期性对齐校验。离线特征表和在线特征存储会定期跑对账任务把同一批实体的特征值拉出来对比发现不一致就告警。这相当于给特征管道装了体检系统问题在早期暴露而不是等到线上效果崩了才回头查。3.3 数据质量监控盯住缺失率、分布漂移和时效性数据质量监控至少要盯三件事。第一是特征缺失率。实时特征拿不到时系统通常会填默认值或前值。如果填充策略不合理线上会出现大量填充值模型在假数据上运行而不自知。这是最危险的情况因为一切指标看着都正常。第二是特征分布漂移。特征分布和训练期差异过大模型效果必然劣化。业界常用的量化指标是 PSI可以给每个关键特征设置漂移阈值超了就告警。第三是时效性。特征产出的延迟比如用户画像标签每天是否按时更新上游数据任务延迟会直接传导到推理质量。我建议把数据质量告警和核心业务指标联动分析。只看特征指标容易误报只看业务指标又定位不到根因两者对照才是完整的问题发现链路。4. 训练平台设计GPU 不是插上就能用4.1 算力池化与任务调度训练平台第一个要回答的问题是 GPU 资源怎么管理。我见过两种典型做法。做法 A物理机绑定一个人分到一台训练机器独占使用。简单直接小团队早期够用。缺点是利用率低——有人训练任务只跑一会儿机器大部分时间空着别人又用不了。做法 B容器化资源池。用户提交训练任务调度器自动分配资源支持多租户隔离。好处是资源利用率高任务可以排队、可以抢占空闲算力还能被离线推理任务利用。缺点是平台本身的搭建和维护成本高。如果团队已经到多个人同时训模型、GPU 开始闲置浪费的阶段就应该考虑做法 B。调度策略上要注意两点一是任务优先级线上紧急修复任务要能抢占批处理任务二是资源上限控制防止一个任务把池子吃光。4.2 实验管理与模型资产沉淀训练平台里最容易被忽略、后期最让人后悔的是实验管理。没有实验管理的时候算法团队的日常是这样的改了一版特征训练效果提升 2%但没人记得是改了哪几个特征三个月后发现当时那个实验的记录丢了只能重新试。这个问题在一个多人协作、长期迭代的团队里会放大到灾难级别。实验管理要记录的核心信息包括数据集版本、代码版本、超参数配置、评估指标、模型产物路径。更进一步是做模型注册每个模型训练完成后登记一张模型卡任务类型、训练数据范围、离线评估结果、已知失败模式。这张卡直接流转给部署环节部署的人不用去问算法这个模型怎么用、有什么坑。4.3 分布式训练的通信瓶颈与断点续训分布式训练不是卡越多越快。数据并行模式下每张卡独立算梯度然后做梯度同步这步跨卡通信在网络里走一圈特别耗时。有一个经验值可以参考从 8 卡扩到 16 卡、32 卡时超线性加速基本不要想。实际加速比通常只有 2.5 到 3 倍而不是理论上的 4 倍。通信开销、负载不均、数据读取都可能变成瓶颈。优化方向一般是梯度累积、混合精度训练、合理的通信拓扑但这些都是收益递减的工程调优要控制投入。另一个必须提前设计的是断点续训。大模型的训练任务动辄几百小时任何一个训练节点异常退出如果没有定期保存检查点前面所有计算全部作废。检查点的保存频率要在恢复成本和保存开销之间取平衡同时检查点存储本身也要做冗余不然存储坏了比节点坏了更致命。5. 推理服务架构在线服务设计的核心决策5.1 在线推理链路网关、动态批处理与排队在线推理服务的链路不算复杂请求先到 API 网关经过鉴权、限流、路由进入推理服务推理服务读取特征、跑模型、返回结果。真正的设计难点在推理服务内部的两个机制动态批处理和排队策略。动态批处理是 GPU 场景下的核心吞吐优化手段。GPU 擅长批量计算单个请求推理和多请求一起推理的耗时差距不大但吞吐差距很大。所以推理服务会短暂积攒请求比如攒 10 到 30 毫秒把一批请求合并推理。这个攒批窗口的时长是个关键参数窗口太大单请求延迟上升窗口太小批量效果差。正确做法是基于目标 P99 延迟反推最大可接受攒批时间。排队策略同样重要。当请求量超过服务容量要么排队、要么快速失败、要么降级。我的经验是宁可快速失败加降级也不要无限排队。排队时间一长用户体验不可控而且队列堆积后新旧请求一起涌入服务更容易雪崩。给队列设一个超时上限超时直接返回兜底结果是更稳的方式。5.2 批量推理任务高峰期怎么别打架在线推理服务和离线批量任务共享算力时有一种典型的资源打架现象白天在线流量高峰离线任务同时启动把 GPU 抢走一批在线延迟立刻恶化。解决办法是资源池隔离加错峰调度。在线推理服务要有独立的资源配额离线任务只能在剩余容量里运行不能越界抢占。离线任务还可以设置运行时间窗比如凌晨低峰时段跑大批量任务白天只跑小批量紧急任务。更进一步可以按优先级调度在线服务是最高优先级不可被抢占近线任务次之离线任务是可抢占的弹性负载。这样设计之后离线任务跑多少取决于在线服务的空闲容量而不是反过来挤压在线服务。5.3 模型加速与部署形态的选型思路模型加速有三个常见方向量化、蒸馏、剪枝。量化是把模型参数的精度降下来换取计算加速和显存节省蒸馏是用大模型教小模型把能力迁移到更小的网络上剪枝是去掉不重要的连接或通道。但在做这些之前先要搞清楚延迟瓶颈到底在哪。我见过不止一个团队花大力气压模型结果发现瓶颈根本不在模型计算而在特征查询的网络开销和数据反序列化。这种场景应该优先优化特征读取链路而不是动模型。部署形态上小模型用 CPU 实例往往就够成本比 GPU 低一个数量级大模型和在线高并发场景才需要 GPU。是否要上模型加速判断标准只有一个先量化评估确认模型计算确实占延迟大头再动手否则就是在错误的方向上优化。6. 生产环境的高频故障与排查经验6.1 故障一模型没动效果却突然变差了现象某推荐服务的核心指标连续一周下滑模型版本没变代码没发版流量也没波动。排查链路先看推理服务错误率和延迟正常再看模型输出分布略偏最后翻特征监控发现某个特征从某天凌晨开始缺失率从 2% 涨到 18%。根因是上游一个数据任务延迟下游实时特征管道在拿不到数据时静默填了默认值。模型在大量默认值特征上跑了一周输出自然偏移。修复动作分两层第一层特征缺失必须显式标记并在监控上可见不能静默填充第二层默认值策略要按特征单独配置有些特征填 0 合理有些特征填 0 等于灾难。这次之后我们把特征缺失率异常提升为最高优先级告警。6.2 故障二扩容反而把服务扩死了现象高峰期延迟上升触发了自动扩容结果新实例不断加入服务延迟不降反升最终大面积超时。复盘链路新实例启动后要加载模型冷启动耗时几十秒期间 CPU 被打满但实例一注册就立刻开始接流量新实例一边加载一边处理请求比旧实例还慢延迟进一步恶化又触发新一轮扩容形成雪崩循环。修复方案第一加启动健康检查模型加载完成之前不接流量第二扩容加冷却期避免抖动触发连环扩容第三限制单次扩容的步长避免瞬间拉起太多实例第四保持一定的最小实例数防止流量一波动就从零开始扩容。这套组合拳之后同样的流量冲击没有再出现过。6.3 故障三灰度发布时正确的 5% 流量切法现象新模型灰度上线按 5% 流量切业务方反馈部分用户体验不稳定有时候准有时候不准。排查链路灰度逻辑是按请求数随机切流同一个用户在两次连续请求里第一次落到新模型第二次落回旧模型感知结果完全不同。技术上没有报错但业务体验是模型抽风。真正的错误不是灰度比例而是灰度维度选错了。修复方案按用户维度做哈希分桶同一个用户的所有请求都落到同一个模型版本上。灰度期间还要同时盯新旧版本的业务指标对比而不只是离线评估指标。灰度灰度本质上是拿一小部分真实用户的体验做实验前提是实验单元要稳定不能同一个用户一会儿实验组一会儿对照组。6.4 故障四告警疲劳让核心故障被淹没现象监控告警数量太多团队已经麻木。一次核心服务 P99 延迟超标持续半小时竟然没有一个人响应。复盘链路告警系统配置了几百条规则大量低价值告警刷屏真正严重的问题被淹没。工程师默认告警都是狼来了值班时只看最高优先级的页面告警延迟超标这种中等级告警被忽视了。修复方案第一告警分级页面级告警对应极度严重问题及时通知的告警限制数量其余降级为日志记录第二收敛重复告警同一根因的告警合并为一条避免刷屏第三每条告警必须可行动附处理手册不能行动的告警直接关掉第四定期做告警演练让团队在模拟故障里走一遍真实处理路径。告警系统的目标不是多而是每个告警都值得被响应。最后说点个人体会。AI 系统架构没有银弹我经历过最顺的项目都不是一步设计到位的而是先跑通一个最小闭环再根据监控数据和真实故障逐步加组件。架构是长出来的不是画出来的。还有一个习惯我强烈建议保持任何架构讨论先从数据流画起而不是从技术栈画起。数据从哪来、怎么变成特征、特征怎么进模型、结果怎么回到业务这条主线理顺了技术选型只是沿着主线填空。这个习惯帮我避开了很多组件选得很先进、但连起来不解决业务问题的坑。