1. 直接把最直观的问题摆上台面AI系统不分层会怎样先说一个我见过很多次的场景一个团队花三个月训好了模型在Notebook里跑得好好的AUC也很漂亮于是信心满满开始做上线。上线第一版怎么写的很自然——一个Python脚本从HTTP接口接收图片中间经历鉴权、格式校验、图像解码、预处理、模型推理、后处理、结果落库最后返回JSON给前端。所有逻辑全写在同一个Handler函数里主流程加异常处理加日志加重试代码大概六七百行。跑起来那几天没什么问题因为QPS不到10模型还是单张显卡在扛。但一个月之后噩梦就来了业务方提出一个新需求请求里要增加一个用户ID字段用来做个性化提示词拼接。你以为是加一个参数的事结果发现这个字段得贯穿鉴权层、预处理层、模型输入构造三层每层都要改。紧接着模型团队更新了版本输入尺寸从224改成256你又得在推理代码里找所有写死224的地方。再后来流量涨到100 QPS你想把预处理单独拆出去多开几个Pod发现拆不动——因为预处理和后处理、业务逻辑全部耦合在一个进程里你根本没办法只扩容其中一段。这就是不分层的代价改一处牵全身、无法独立扩展、故障互相拖累、排查全靠人肉翻日志。你说它是AI系统其实它只是个能跑的脚本。AI系统之所以必须分层不是架构师有洁癖而是业务复杂度和工程规模到了某个临界点之后不分层根本没法继续演化下去。我在实际项目里见过不少反例也亲手重构过几个这样的系统。这篇文章我就把AI系统分层这件事从头到尾捋一遍为什么分、Workflow和Inference这两种核心模式到底有什么区别、真正落地时怎么选型、以及我踩过的那些坑。2. 分层到底在分什么从两个完全不同的运行模式说起2.1 先给Workflow和Inference一个准确的工作定义标题里提到的Workflow和Inference是AI系统里最核心的两个概念但很多人对它们的理解是模糊的。我先给一个准确但不学究气的定义。Inference推理指的是把训练好的模型部署起来对单个输入样本做一次前向计算得到一个预测结果。比如你传一张图片给分类模型模型给你返回猫或狗这就是一次推理。它的特征是单个输入、单个输出、耗时通常在毫秒到秒级别、本身没有复杂的业务分支逻辑。Workflow工作流指的是把一个完整的业务任务拆成多步让这些步骤按照预定义的顺序或条件分支依次执行。比如你要做一个商品评论自动审核系统流程可能是采集评论 → 判断有没有图片 → 有图片就过一遍OCR → 把文本和OCR结果一起送到情感分析模型 → 根据情感分数决定是放行还是转人工 → 写入审核结果。这就是一个典型的工作流。它的特征是多步骤、有顺序和分支、步骤之间可能要传递数据、整个流程的耗时可长可短从几秒到几小时甚至几天。注意一个关键区别Inference只解决单个智能动作Workflow解决多个动作怎么组织协同。打个比方Inference是厨师做一道菜Workflow是餐厅的整个出餐流程——从客人点单、下单到后厨、按前菜主菜甜品顺序出餐、上桌、结账。做菜和管流程是两个层面的问题。AI系统里这两个层面的问题都需要解决而且是不同的解决思路。你不可能用做菜的思路去管整个餐厅也不可能用管餐厅的思路去做菜。这就是为什么AI系统必须分层——因为这两件事的工程特性完全不同。2.2 从请求模式、状态管理、并发特征三个维度看本质差异对比维度Inference推理服务Workflow工作流编排请求模式同步为主请求-响应模型异步为主任务-事件驱动模型单个任务的耗时毫秒级到秒级秒级到小时级甚至天级状态管理无状态所有状态都从请求里拿有状态需要在步骤间持久化中间结果并发特征高并发、低延迟、吞吐优先并发任务数相对低但每个任务生命周期长失败处理快速失败、返回错误码重试、补偿、人工干预、死信归档典型工具vLLM、Triton、TensorRT-LLM、ONNX RuntimeAirflow、Argo Workflows、Temporal、Cadence这张表是理解分层的核心。你可以看到Inference和Workflow几乎在每一个维度上都是相反的。如果把这两种模式混在一个系统里你会被迫用一套方案去满足两种互相矛盾的需求结果往往是两头都不讨好。举一个具体的例子。我见过一个团队把多步推理流程做成了同步HTTP调用链用户请求进来服务A调用服务B服务B调用服务C三个模型串成一条链。看起来挺简单但问题是服务C如果是一个大模型推理可能要花10秒甚至更久服务A和服务B的HTTP连接池很快就被占满了后续请求全部排队最后雪崩。这就是典型的用Inference的模式去做Workflow的活。反过来也有问题。有些人把所有东西都丢进一个消息队列每个推理请求都要经过队列转发、Worker拉取、结果回传原本10毫秒能完成的单次推理被硬生生拖到200毫秒。这是用Workflow的模式去做Inference的活。正确的做法是把系统分成两层推理层负责短平快的智能计算工作流层负责长周期的业务编排。两层通过明确的接口通信。这既不是过度设计也不是理论空谈而是基于两种模式的根本差异推导出来的必然结论。2.3 分层不是目的是用代价换来的收益但我也得说一句公道话分层是有代价的。你多了一层就多了一次网络通信延迟必然增加多了一个组件就多了一个要维护的运维对象多了一套接口就多了一类联调问题。有一个真实的案例我印象很深某公司做智能客服最初是单体应用直接调用模型端到端延迟约200毫秒。架构师为了规范把系统分成意图识别服务、槽位填充服务、对话管理服务、回复生成服务四层每层之间走gRPC。结果端到端延迟变成800毫秒——这还是在低负载下测的。原因是每一次gRPC调用都要经过网络序列化反序列化四层串起来光网络开销就翻了四倍。所以分层必须分在对的地方。分层的核心依据不是别人都这么分而是看变更频率和资源特性是否真的不同。我的判断标准是三句话如果两段逻辑的变更频率不同它们就属于不同的层。比如模型模型迭代很快和业务规则业务规则变化相对慢应该分开。如果两段逻辑的资源需求不同它们就属于不同的层。比如CPU密集的预处理和GPU密集的模型推理必须分开否则CPU和GPU互相拖累扩容也没法独立做。如果两段逻辑的生命周期不同它们就属于不同的层。比如一次HTTP请求内的操作生命周期毫秒级和一笔跨天审批流程生命周期天级生命周期差了好几个数量级绝不可能用同一套机制管。这三句话我后面还会反复用也是我做所有AI系统分层设计的出发点。3. 落地时先画好一张图一张AI系统的标准分层地图3.1 从底层到顶层五层结构逐层拆解如果把一个通用的AI业务系统从下到上拆开大致是这么几层基础设施层GPU/CPU算力池、存储、网络、容器编排K8s。数据与特征层数据采集、清洗、特征计算、样本管理、特征存储、Label管理。模型层模型仓库、模型版本管理、模型推理服务Inference Server。编排层Workflow引擎、任务调度、状态机、人工审批流。应用接入层API网关、Web/App后端、消息队列入口、流控与鉴权。这五层之间层与层通过接口通信接口定义要稳定层内部可以随便改。我拿一个实际做过的商品图像审核系统来举例基础设施层K8s集群混合调度GPU节点跑图像模型CPU节点跑业务逻辑。数据层离线任务每天从商品库拉增量数据计算特征图片PHash、颜色直方图等存到特征库。在线推理需要特征时直接从特征库查而不是每次现场算。模型层部署了两个模型服务——违禁品检测模型目标检测GPU推理单次约120ms和OCR模型识别图片文字GPU推理单次约200ms。两个模型服务都是无状态的支持水平扩容。编排层Workflow引擎负责任务编排——用户提交一个商品图片Workflow先调违禁品检测如果违禁品检测得分高于阈值直接拒绝否则继续调OCR模型识别文字再用规则引擎检查违禁词最后把结果写入审核队列。应用接入层API网关接收商家的提交请求同步返回一个任务ID。前端拿任务ID轮询状态整个审核流程在几秒到几十秒内完成。这个架构里模型层和编排层的边界非常清晰模型层只做给我一张图返回检测结果编排层负责什么时候调哪个模型、结果出来之后怎么办。模型团队可以独立更新模型、独立扩容推理服务不影响编排层编排层可以独立调整审核策略也不影响模型层。3.2 画分层图最容易犯的错把图画成了部署拓扑我见过很多团队画的分层图其实画的是部署拓扑图。这里有个容易混淆的点我特别提醒一下。分层图Logical Architecture展示的是职责边界不是物理部署。两层逻辑上分开物理上完全可以跑在同一个进程里。相反逻辑上属于同一层的东西物理上也可能分散在不同集群。举个例子API网关和应用后端在分层图上属于同一层应用接入层但物理上它们可以拆成两个服务。反过来说数据预处理和模型推理在分层图上可能是两层但在某些高吞吐场景下它们可以被编译进同一个进程用Pipelines的方式避免网络开销。画分层图时我的习惯是先用职责把系统分块再在每块上标注部署方式和依赖关系而不是一上来就画一堆方框和箭头代表服务。分层图的标准是任何一个方框移动位置、拆分、合并都不影响其他方框的接口语义。如果挪一个框其他框就得跟着改说明分层边界画错了。3.3 一个特殊模式黑板模型Blackboard Model说到分层我还想提一个很多人在做复杂AI系统时会用到的模式——黑板模型。这个话题和分层很相关因为黑板的本质是一种无序协同的分层替代方案。传统分层是上层依赖下层流程是线性或树状的。但有些场景尤其是多模型协作的复杂推理——比如一个医学影像诊断系统需要同时调用分割模型、病灶检测模型、报告生成模型而且这三个模型的结果需要互相修正——这种场景下严格的分层反而很别扭。黑板模型的思路是所有模型共享一个黑板一个共享数据空间各自从黑板读写信息、在需要时更新自己的判断最终黑板汇聚出综合结果。这相当于把流程编排变成了数据驱动系统里的各个模块不再有严格的上下层关系而是通过共享数据空间协作。这个模式我在实际项目里用过一次效果不错。但我要给你的建议是黑板模型在系统复杂度还没大到需要它的时候绝对不要用。因为它牺牲了明确的数据流依赖调试和追踪会很痛苦。我那次用的场景是三个模型之间的迭代确实存在循环依赖纯分层流程根本推不进才被迫上了黑板。大多数AI系统分层和Workflow已经足够了。4. 选型实战Workflow引擎和Inference Server到底怎么挑4.1 Workflow引擎Airflow、Argo Workflows、Temporal怎么选这是我觉得很多人最纠结的地方。选Workflow引擎我的判断标准可以归纳成三个问题你的任务主要调度什么东西任务的持久化要求有多强你的容器化程度有多高工具核心定位最适合的场景踩过的坑Airflow定时DAG调度生态最成熟离线数据管道、定时特征计算、ETL它本质是按计划跑任务实时性差不适合在线业务编排Argo WorkflowsK8s原生工作流容器化任务编排、ML训练流水线、K8s集群上的批处理依赖K8s非K8s环境不合适参数传递稍显繁琐Temporal持久化工作流状态机长时运行、需要人工审批/补偿/可靠恢复的业务流程上手门槛比前两者高需要理解Activity与Workflow的模型我做一个简单的取舍建议如果任务是明确时间周期的表格/特征型任务比如每天凌晨两点算特征直接上Airflow它最成熟相关资料最多。如果团队已经整体跑在K8s上任务又大多是容器化的一次性任务比如跑一个模型训练Job、批量推理Argo Workflows最顺手因为可以复用K8s的调度和弹性能力。如果是一个面向C端的业务流程比如用户提交审核、中间要人工介入、可能耗时数小时甚至数天一定要上Temporal或者Cadence这类带持久化执行状态的引擎Airflow和Argo都不适合。我见过最典型的错配用Airflow去编排C端业务流。Airflow调度的最小粒度是分钟的Schedule而C端业务流是事件驱动的——用户提交了任务才触发一次流程而不是每隔一分钟跑一遍。结果工程师为了模拟事件触发用Airflow频繁轮询数据库把调度器跑成了轮询器既浪费资源又延迟高。这是工具选型时对任务驱动模型理解不到位导致的。4.2 Inference ServervLLM、Triton、TensorRT-LLM 的选型对比Inference层选型相对Workflow简单一些因为核心指标就两个吞吐量和延迟。我按当前主流场景做了一个对比工具第一优势适用模型类型备注vLLM用PagedAttention优化显存吞吐量高大语言模型LLM最近进化很快已经支持多模态社区活跃度极高NVIDIA Triton多框架统一推理TensorFlow/PyTorch/ONNX自带并发模型调度任意类型的模型架构成熟稳定适合多模型混合部署但配置偏复杂TensorRT-LLM针对NVIDIA GPU做了底层极致优化LLM且明确绑定NVIDIA GPU推理速度极致但工程改造量较大适合对时延要求极端的场景ONNX Runtime轻量、跨平台、CPU/GPU都支持传统模型分类、检测等适合快速部署小模型Python/C#/C都友好我的实际选型经验是如果你的AI系统主打LLM能力优先考虑vLLM。它的吞吐量优势在并发请求多的时候特别明显而且现在OpenAI兼容API做得很好业务代码几乎不用改。如果你的系统里各种模型都有——一个OCR、一个图像分类、一个小BERT——而且不想为每个模型单独写一套服务用Triton统一部署。Triton的并发调度会把多个模型的GPU显存复用得很好。如果是纯CPU场景或者是边缘设备ONNX Runtime最省心不需要GPU也能跑得不错。这里有个选型常被忽略的点是模型预热Warm-up。模型部署到Inference Server之后框架默认是懒加载——第一个请求进来才初始化CUDA上下文、加载权重。这意味着线上第一个请求的延迟可能会是正常值的5到10倍。我只在Triton和vLLM的配置里都设置了启动预热请求用一张占位图跑一遍推理再对外提供服务。很多线上偶发超时其实是这个问题。4.3 层与层之间的通信机制同步、异步还是流式分层架构搭起来之后层与层的通信方式也要认真设计。我见过很多团队分层图画得很漂亮但层间通信全是同步HTTP,结果一压测就崩。我的通信选型原则是Inference层内部或紧邻的上游用gRPC或HTTP/2。单次推理是低延迟高并发的场景gRPC的二进制协议和连接复用能明显降低开销。vLLM和Triton都原生支持gRPC。Workflow引擎的触发事件走消息队列。用户提交一个任务API网关只把任务信息写入Kafka或者RabbitMQWorkflow引擎消费事件、创建流程实例。这样最终用户的请求耗时就和服务端实际处理耗时解耦了用户不会傻等。LLM的流式输出场景用SSEServer-Sent Events或WebSocket。现在大模型相关的产品基本都是打字机效果HTTP短连接同步等待完整输出会把整个链路的响应时间拖到不可接受。我自己的一个习惯是同层内部的调用用函数签名直接约定跨层的调用才用显式的网络接口。因为同层内部改接口的成本低跨层改接口的成本高。把这个边界定清楚接口变更的爆炸半径就能控制住。5. 实操中反复踩的四个坑附完整排查链路5.1 坑一把多级推理流程做成了同步调用链前面提过这个案例这里展开讲一遍完整排查过程因为这个坑太典型了。现象系统上线后平时延迟正常但一到流量高峰就会出现大量502。客户投诉明显变多。排查链路我拿到问题后先看了API网关的监控发现错误集中在某一台网关实例上但它本身的CPU、内存都不高不合理。再看服务依赖图发现用户请求链路是网关 → 服务A预处理 → 服务B模型1 → 服务C模型2。三层都是同步gRPC调用。用Jaeger分布式追踪抽样看了看延迟分布发现服务B到服务C的调用p99延迟直接从200ms飙升到5秒。看服务C的监控GPU利用率只有40%左右但线程数打满了——线程池饱和大量请求在排队。最后定论同步调用链让服务C的线程池成为整个链路的瓶颈。服务A、B各自持有HTTP/gRPC连接池每个请求都要占用一个线程等待下游响应流量一上来连接池和线程池双双耗尽请求积压超时雪崩。修复方案把同步调用链改为编排层驱动。API网关收到请求后直接把任务塞进KafkaWorkflow引擎用的Temporal消费事件按步骤调用服务A、服务B、服务C。每一步完成之后Workflow把中间结果持久化到任务状态里再触发下一步。用户侧通过轮询或WebSocket拿最终结果。这样服务A、B、C的并发模型从线程等待变成了短请求处理各自的线程池不会再被下游拖死流量再大也只是消息队列堆积量变大不会雪崩。这次排查给我的教训很深刻凡是超过两步的AI处理链路就不要用同步HTTP直连了。同步是Inference的模式不是Workflow的模式。5.2 坑二无限重试把GPU打到满载现象某天突然收到告警GPU集群利用率100%但业务量并没有明显上升——查询流量监控QPS反而跌了一半。排查链路先看GPU侧发现每个GPU卡上的进程都在跑同一个模型而且请求量非常大。看调用来源发现大量是重试流量——上游服务在收到超时错误后启动了一个指数退避重试逻辑但退了三次还失败就直接无限重试。再看业务日志发现最早一批请求是因为一个参数校验bug导致模型输出异常返回了500。当时还在灰度并没有全量。但由于重试逻辑设置不当只需要少量错误请求就能产生大量重试把集群打满。修复方案分两个层面。第一推理服务层面规定幂等明确的错误码——对于参数类错误返回4xx不允许重试对于超时类错误返回503允许有限重试最多3次。第二Workflow层面引入死信队列超过重试次数的请求进入人工处理队列而不是无限循环。经验之谈推理服务必须做重试保护。因为Inference Server是资源密集型的重试风暴对它的伤害比对普通Web服务大得多——GPU是稀缺资源一旦被打满恢复时间很长。如果你控制不了上游的重试行为就在推理服务前面加一层限流器直接丢弃超出阈值的请求。5.3 坑三分层分得太碎“微服务”变成了“微地狱”有些团队矫枉过正把分层理解成拆微服务。我有一次接手一个AI推荐系统同事说我们架构很规范每个环节都是独立微服务我一看光一个推荐链路就拆了8个服务鉴权、用户画像查询、候选召回、粗排模型、精排模型、规则过滤、物品信息补充、结果埋点。每个服务之间都是网络调用。这个架构的后果是显而易见的端到端延迟从单机版的150ms涨到700ms网络开销是主要元凶。排查问题要翻8套日志开发一次联调要启动8个服务。任何一个服务挂了整条链就断了可用性约等于0.8的8次方——约等于16.8%这数学期望非常可怕。修复方案按照变更频率和资源特性重新聚合边界。我的做法是把8个服务重新聚合成3个网关层鉴权参数校验、推荐引擎召回粗排精排规则过滤合并进同一个进程因为它们的QPS和部署节奏高度一致、模型服务层rank模型单独拆出来因为GPU资源要独立扩缩容。用户画像和物品信息这类低频元数据直接在推荐引擎进程内查询缓存不走网络。这个案例说明分层不等于拆服务拆服务只是实现分层的一种手段。在同一部署单元里做模块化分层往往比强行拆成网络服务明智得多。5.4 坑四观测性架构没有一次做到位这条可能不算踩坑更像事后补救。我有一次接手别人的AI系统排查一个评论审核偶尔漏放的问题。这个系统的Workflow有四步文本模型判断 → 图片模型判断 → 规则引擎断词 → 人工抽检。线上出了漏放案例但我发现根本没法查日志散落在四个服务的本地文件里没有trace_id串联也没有集中日志平台。最后怎么查的靠人工下单复现配合把四个服务的日志手工拼在一起逐个对时间戳。花了整整两天才定位到是规则引擎的断词逻辑更新时Workflow的版本和生产版本不一致——灰度没切干净。这次事后我做了两件事全链路接入OpenTelemetry统一trace_id透传——从API网关进去就生成trace_id粘在每个日志、每个MQRabbitMQ消息头里。每个服务都按trace_id查询集中到同一个日志平台用的ELK。做完之后查一次问题的时间从两天缩短到十分钟。我一直认为AI系统比传统业务系统更需要可观测性因为AI行为本身有随机性不靠trace很难区分模型判断错了和系统链路错了。6. 用行业成熟标准给自己做一个分层健康度体检6.1 ISA-95的层级模型工业界对分层的成熟回答如果你所在的行业涉及制造业、工业互联网你会经常听到ISA-95——这是国际自动化学会制定的企业-控制系统集成标准。ISA-95把工厂的IT/OT系统分成了Level 0到Level 4五个层级Level 0物理过程传感器、执行器Level 1基本控制PLC、DCSLevel 2监控SCADA、HMILevel 3制造执行MES生产调度、质量追踪Level 4业务规划ERP订单管理、供应链这套分层模型的核心思想是层与层之间通过标准接口交换数据每层内部可以做独立优化上层不关心下层的具体实现。我每次给AI系统做架构评审的时候都会把ISA-95拿出来做类比你的数据分析/处理系统处于什么层级你的模型服务是否对应Level 1/2的实时控制你的Workflow编排是否对应Level 3的生产调度这种类比不是纸上谈兵。我看过不少工业AI项目把模型推理直接接到传感器数据上没有中间的数据治理层、没有调度层模型一更新整套流程都要停。如果早点用ISA-95的视角审视就该知道Level 1和Level 2之间隔着一层数据处理与报警的职责绝不能让上层模型直接和底层设备深度耦合。6.2 数据仓库的四层模型给AI系统的数据层一个参考数据仓库分层的概念对AI系统同样有启发。经典数仓分为四层ODS操作数据存储原始数据落地层保留最细粒度数据DWD数据明细层清洗、标准化之后的明细数据DWS数据汇总层按主题聚合的宽表ADS应用数据层面向业务应用的数据映射到AI系统中ODS对应样本原始日志——模型请求日志、特征原始值、结果回传日志都该有原始归档不能只删不存。DWD对应清洗后的样本集——去重、过滤异常、标注修正之后的可用于训练的数据。DWS对应特征宽表/特征层——在线推理直接读取的特征存储要和离线特征计算的逻辑保持一致。ADS对应业务风控/运营使用的报表和监控指标——模型的线上表现、延迟、命中率等。很多AI团队的架构里数据层是缺失的。模型训练用一份临时跑的数线上线下特征不一致出了问题都找不到历史数据回溯。如果你在做AI系统我强烈建议至少把ODS和DWD两层建立起来这是无数行业经验沉淀下来的血泪教训没有原始数据归档的AI系统出问题了连追溯的资格都没有。6.3 一张自检清单快速判断你的分层是否合理说了这么多总得给一个可以落地执行的东西。我每次做架构评审都会拿这几个问题过一遍你可以直接抄去用某一层内部修改其他层是否完全不需要知道如果不能边界画错了。某一层能否独立扩容如果不能说明它耦合了资源特性不同的逻辑。某一层宕机影响范围是否可控如果全链路不可用说明层间隔离没做好。修改模型代码需要同步改业务代码吗如果需要模型层和编排层的接口设计有问题。端到端延迟里业务代码之外的网络开销占比是否超过20%如果超过考虑物理聚合。出问题时能否通过一个trace_id串联所有相关日志如果不能可观测性欠账了。数据层是否有原始日志归档如果没有现在就补别等出事故。这七条我很少看到有团队能一次性全部通过。但没关系架构是演进的每解决一条系统的工程成熟度就上一个台阶。7. 聊聊我个人的一点体会最后不写总结只分享一条经验。做AI系统架构这几年我最深的体会是分层设计的最终目的不是让架构图好看而是让组织里的每一拨人——算法团队、后端团队、平台团队——都能在自己那一层独立地工作、独立地演进、独立地负责。如果你分了层结果算法同学改个模型还要等后端排期发版后端改个接口还要看算法脸色那这个分层是失败的——你只是画了张漂亮的图没有真正划清职责边界。我自己的实践是先定接口再定层。在动手写任何代码之前先把层间的关键接口以文档形式定下来——比如模型服务的输入输出Schema、Workflow触发事件的消息结构、数据层的表结构约定。接口一旦定下来各层就可以并行开工互不干扰。这个做法帮我避开了无数次返工也让我在团队里养成了一个习惯任何架构讨论第一句话永远是这层的接口是什么而不是这层的代码放哪里。如果你现在正要设计一个AI系统或者正在重构一个已经乱成一团的AI系统希望这篇内容能帮你把分层这件事想得更清楚一些。架构没有标准答案但方向对了路就好走了。