做平台架构的同学这几年应该都有同一种感觉云原生这套东西跑Web服务、跑微服务、跑大数据作业都挺顺手但一旦把大模型推理和训练任务放进来很多原本笃定的设计原则开始失灵。我所在团队接手大模型平台重构时工单系统里最刺眼的一条告警就是GPU配额冻结通知——5分钟预冻结折合1.33核时听起来数字不大背后却暴露了一个本质问题在大模型时代云原生架构设计如果还停留在容器调度层面GPU资源管理、推理服务弹性、训练任务编排这些环节迟早会把你拖垮。这篇文章我想把大模型时代的云原生架构设计这件事掰开揉碎讲清楚。核心围绕三个问题为什么传统云原生架构撑不住大模型负载、GPU资源调度和推理服务应该怎么重新设计、训练微调和多模型共存的平台底座又该怎么搭。适合正在做AI平台、GPU集群管理、或者准备把大模型接入生产环境的架构师和研发同学也适合想搞明白vLLM、Ollama这些工具背后部署逻辑的初学者。1. 传统云原生架构在大模型负载面前的三处断裂点1.1 无状态设计假设失效显存成了新的资源边界传统云原生架构的基石是无状态。Kubernetes里一个Pod可以被随时销毁、重建、滚动升级实例之间完全等价因为真正的状态都在外部数据库或者对象存储里。这套模型支撑了互联网业务这么多年没人觉得有问题。但大模型推理服务把这个根基直接掀翻了。一个70B参数规模的开源模型光是FP16精度的权重就要占掉约140GB显存再加上KV Cache和中间激活值单张A10080GB根本放不下。生产上通常的做法是做张量并行或流水线并行把模型切到4张甚至8张卡上。这个切分方案一旦确定卡与卡之间的通信模式就固定了实例不再是独立的、可等价替换的单元。你杀掉一个推理Pod再重建意味着整套权重重新加载就算走本地NVMe缓存也要几十秒到几分钟冷启动直接看对象存储的加载速度半小时也不奇怪。所以第一个断裂点很清楚你熟悉的任意实例等价替换模型失效了推理实例变成了有重量的、不可随意挪动的单元。凡是基于无状态假设设计的滚动发布、自动扩缩容、故障自愈策略在大模型场景下全部需要重新审视。我自己踩过的坑就是当初把推理服务当成普通微服务接进已有的发布平台结果每次灰度发布都要经历一次模型重载服务可用性直接被打到99%以下后来才改成多副本交替预热的方式。1.2 网络拓扑被忽视跨机通信的延迟代价第二个断裂点藏在网络里。传统微服务对网络的要求是能用就行几百微秒的延迟波动不会要命。但大模型的张量并行和流水线并行对网络拓扑极其敏感AllReduce、AllGather这类集合通信操作是在每个Transformer层都会发生的通信延迟直接叠加到单次推理延迟上。举个例子一个8卡张量并行的推理实例跑在跨机跨交换机的卡上和跑在同一台8卡机器上单次请求延迟可能差出30%到50%。更麻烦的是如果你的调度器不感知GPU的物理拓扑把本该在同一台机器上协同的8张卡拆到了不同节点CPU和GPU之间的PCIe/NVLink带宽也会成为瓶颈训练时的通信效率甚至会掉到原来的三分之一。这意味着调度器不能只看哪台机器有空闲卡还得看这些卡是否在同一个拓扑域内。Kubernetes默认的调度策略完全不知道NVLink、不知道交换机层级它只会做最粗粒度的资源匹配。这正是很多团队在GPU集群规模上来之后不得不自研调度器的直接原因。1.3 弹性伸缩的粒度错位副本数不再是万能解药传统弹性伸缩的逻辑是流量涨了加副本流量掉了减副本。HPAHorizontal Pod Autoscaler看CPU指标就能工作得很好。但大模型推理服务的弹性问题复杂得多。首先显存是硬约束。一个推理实例占了几百GB显存加的副本必须真的有卡可放而GPU是整卡分配的不像CPU那样可以超卖。其次模型加载成本高你不可能频繁地扩缩容——每启动一个副本都在做一次大文件传输和权重装载这跟启动一个Java进程的成本完全不在一个数量级。第三推理服务本身还有动态批处理、KV Cache复用这些机制请求的并发形态、前缀相似度都会影响实例的真实吞吐能力只看QPS做弹性很容易误判。所以在大模型场景下弹性的思路要反过来不是流量到了再加副本而是提前把资源池备好副本常驻通过请求调度层做流量分配。这也解释了为什么大家开始关注请求级的路由、预热池、以及instance层面的优雅缩容。2. GPU资源调度从按核时记账到显存感知分配的切换2.1 Kubernetes默认GPU调度为什么不够用很多团队最初接触GPU调度用的是Kubernetes原生的nvidia.com/gpu资源。它的逻辑很简单每个GPU是一份整数资源Pod声明几份调度器就给你找几台有足够空闲卡的节点。这套机制对付单卡推理够用但在大模型时代暴露出一堆问题。第一它不区分GPU型号和显存大小。同样是一份GPUA100 80GB和T4 16GB是完全不同的资源但资源声明里看不出差别。第二它不支持显存级的共享和切分。一个只跑Qwen 7B的推理服务实际只需要16GB显存却要占用一整张A100剩下60多GB白白浪费。第三它不感知卡的拓扑关系前面说的跨机并行问题就是这么来的。第四它不处理显存碎片——A卡剩70GB、B卡剩50GB一个需要80GB的任务谁也没法放但两张卡都不是全空整体利用率却上不去。这也是为什么很多公司的GPU集群利用率长期只有20%到40%——不是没有需求而是调度层的粒度太粗把资源全浪费在碎片和错配上。2.2 显存感知调度与碎片治理的实践路径要解决上面的问题核心思路是把卡这个粗粒度资源细化成显存 算力 拓扑关系的组合来看待。我见过比较务实的做法分为三层第一层是至少做到型号感知。给GPU节点打上标签标注型号、显存总量、NVLink拓扑调度器按照Pod声明的显存需求去匹配而不是只看有没有GPU。第二层是做显存切分和共享。NVIDIA官方有MIGMulti-Instance GPU方案可以把A100/H100切出多个实例隔离性好但切分档位固定、不够灵活。开源社区还有HAMi原Volcano GPU方案这类项目支持更细粒度的显存分配和显存共享、超卖适合把多张小模型任务塞进一张卡。第三层是面向大模型并行的拓扑感知调度。对于需要多卡并行的大任务调度器要把同一交换域、同一NVLink域作为调度约束尽量把实例的卡分配在物理上相邻的位置。这一层做得好不好直接决定训练性能和推理时延。这里要特别提醒显存超卖是把双刃剑。超卖能提高利用率但一旦超卖比例过高多个任务同时吃满显存就会出现OOM而GPU的OOM会把整个进程直接干掉不像CPU那样只是变慢。我建议在混合负载场景下超卖比例先控制在1.2到1.5倍并且给重要推理服务保留独占卡不让超卖任务和在线服务混部。2.3 常见GPU调度方案的选型对比不同阶段的团队适合的方案完全不同这里我按实际使用经验给一个对比。方案粒度拓扑感知显存共享适用场景成本Kubernetes原生GPU整卡无无单卡推理、起步阶段低NVIDIA MIG物理切分部分固定档位A100/H100机型的多路复用中HAMi / 自研调度器显存级可扩展支持多模型混部、利用率敏感高厂商商业化方案如NGC等平台级支持支持云上托管、企业级视预算注意上表里的成本不只是钱还包括维护成本。自研调度器能把利用率从30%拉到70%但背后的开发、测试、故障排查成本都很高。我见过不少团队在20台GPU机器以内的时候老老实实用Kubernetes原生调度加节点标签完全没有问题真正需要动调度器的是当你有几十台以上GPU机器、同时跑训练和推理、而且显存碎片开始成为日常痛点的时候。别为了架构先进提前造轮子。3. 推理服务架构重塑vLLM、Ollama背后的部署模式差异3.1 连续批处理为什么vLLM能把吞吐拉高数倍聊大模型推理服务绕不开vLLM。它最核心的贡献是PagedAttention和Continuous Batching连续批处理。传统推理服务的批处理逻辑是攒一批请求一起做前向计算全部算完再统一返回——批内所有请求必须等最慢的那个走完而且如果请求长短不一GPU算力浪费非常严重。连续批处理则把批拆成了细粒度的调度单元每个请求的生成步长不一致一个请求的某个token算完马上可以让下一个请求插进来GPU几乎每个时刻都在满负荷计算。这个机制对架构设计的影响比很多人以为的要大。它意味着推理服务内部的负载模型不再是并发连接数决定吞吐而是当前激活的生成序列数决定算力消耗。你在做容量评估的时候不能用传统Web服务的QPS公式得按并行序列数 × 每序列生成速度来估算而且还要考虑前缀缓存命中率。另外vLLM这类框架天生就是为多模型实例 请求路由设计的。你可以在同一个GPU节点上跑多个不同模型的实例通过请求里的模型名路由到对应的实例这就是后面要说的模型网关的由来。3.2 推理实例的有状态本质KV Cache与优雅扩缩容前面我说推理实例是有重量的主要体现在两个地方模型权重和KV Cache。权重是静态的加载完就固定了KV Cache是动态的随请求的生成过程不断增长并且会让显存占用在实例运行期间波动。这意味着你做资源预留的时候不能只按权重大小算还要把KV Cache的峰值考虑进去。vLLM里可以通过gpu_memory_utilization参数设置显存利用率上限一般建议预留10%到20%的余量给运行时波动和碎片。扩缩容也要讲策略。冷扩容要加载模型耗时长所以生产上常见做法是常驻最小副本数 缓启动扩容。当流量突增时先让已有实例通过连续批处理硬扛同时新副本开始加载模型等它Ready后再切流量。缩容就更要小心直接删Pod会导致正在处理的请求断连必须走优雅停机先摘流量等已生成的序列全部结束后再销毁实例。3.3 本地部署Ollama与云端推理平台的差异Ollama在个人电脑和开发环境里很流行主打一条命令本地跑大模型很多同学用它做模型体验和原型验证。我要提醒的是Ollama的易用性背后牺牲了不少生产级能力它的并发控制、显存管理、批量推理优化都比vLLM弱不少适合个人机器和低并发场景。如果你的服务要面对真实生产流量架构上还是应该以vLLM、TensorRT-LLM这类高性能推理引擎为底座Ollama更适合当开发调试工具或者边缘离线场景的轻量部署方案。还有一个架构层面的问题值得注意应用怎么接大模型现在很多Java团队用Spring AI这类框架把大模型调用封装得像Spring Data一样底层可以切换不同的模型提供商。这类框架在架构上的价值是屏蔽了模型差异让你可以随时从闭源模型切到私有化部署的开源模型。但业务上真正的演进方向是多模型路由和智能体框架——在网关层根据任务类型把请求分给不同的模型比如代码生成走一个模型、通用对话走另一个模型再叠加Agent框架做工具调用和长流程编排。这个变化会让平台的架构从单模型服务走向模型编排与治理。4. 训练与微调任务的云原生编排Job容错、数据管线与配额治理4.1 分布式训练Job的编排与容错训练和微调是另一类完全不同的工作负载。它的特点是长时长、资源密集、且单点故障会导致整个任务失败。以PyTorch为例多卡训练通常通过torchrun拉起一组进程进程间通过NCCL通信。在Kubernetes上跑这类任务裸用Pod是很痛苦的——你需要的是能感知一组进程必须同时调度、同时存活的Job编排。Kubeflow的PyTorchJob就是干这个的它把一组Worker和一个可能的Chief组织成一个逻辑单元支持失败重试和gang scheduling组调度。组调度的意思是要么这组任务的所有资源一次性满足要么就不调度防止死锁——想象一下两个各需要4卡的任务A先占了4张卡B也占了4张卡但A的第5张卡等B释放B的第5张卡等A释放两边都卡死。实际生产中还有一个容易被忽视的点检查点Checkpoint。大模型训练动不动跑几天甚至几周任何一次节点故障都可能导致几小时的算力白费。架构上一定要把周期性Checkpoint做成标配并且把checkpoint存在高性能的共享存储上而不是本地盘——否则节点挂了checkpoint也跟着没了。我自己见过最惨烈的一次事故就是某个训练任务把checkpoint写在本地节点磁盘故障后团队不得不从36小时前的备份重跑。4.2 数据管线和存储选型喂饱GPU比调度GPU更关键训练任务的另一个瓶颈经常在数据侧。GPU算力再强如果数据加载不及时GPU也在空转。我见过不少团队的训练效率只有理论值的一半查到最后是DataLoader的瓶颈数据从远端对象存储拉取太慢、预处理tokenize、图像解码没有流水线化、或者存储的IOPS不够支撑多节点并发读取。架构上大模型平台至少要有一个独立的数据缓存层。常见做法是原始数据放对象存储预处理后的样本缓存到分布式文件系统比如JuiceFS、Alluxio或者干脆用SSD本地盘做缓存让DataLoader每次都读最近、最快的那份数据。另外Embedding、tokenize这类结构化计算应该做成可复用的预处理流水线避免每个训练任务都重复做一遍。在这个环节上数据格式的统一也很重要建议团队提前定好一套统一的样本格式规范避免每个模型微调时都重写一套数据转换脚本。4.3 配额治理从核时记账到多团队协同的预算模型回到开头那条GPU配额冻结通知。核时或者卡时是在多团队共享GPU集群时最通用的计量单位一个任务占用多少卡、跑了多少小时折算成核时从团队的预算里扣。预冻结是资源管理平台的一种常见策略——任务启动前先冻结预计消耗防止任务跑完发现团队预算超了冻结时间内的实际消耗会在任务结束或后续结算中多退少补。这个机制的工程挑战在于配额怎么定价、怎么防止浪费、怎么处理超卖导致的优先级冲突。我的建议有三点第一在线推理服务的配额要跟训练任务分离训练允许排队推理不允许不然一个训练任务把卡占满线上模型服务直接被饿死第二给配额加利用率标签定期识别低利用率的占用任务超卖或优先级抢占机制要提前设计好第三配额冻结的粒度不要只按累计核时最好同时限制最大并发卡数防住那种一口气申请几百张卡、实际只用几十张的浪费行为。5. 大模型平台整体参考架构网关、存储与可观测性的特殊设计5.1 分层架构接入层、推理层、训练层、数据层、管控层综合前面几节一个相对成熟的大模型云原生平台我建议按五层来搭。接入层负责统一API入口兼容OpenAI风格的接口协议让业务方不用关心底层是自建模型还是第三方模型。推理层是多个推理实例池通过vLLM等引擎跑不同模型按模型ID做路由支持多副本和切流。训练层负责微调和预训练任务跑在Kubernetes的Job体系上配合队列和优先级调度。数据层统一管理语料、预处理流水线和检查点存储做到一份数据多处复用。管控层则是大脑负责配额、权限、监控告警和模型版本管理。这五层不一定要一次性全建完但边界一定要清晰。我见过很多团队一开始图省事把网关逻辑塞进推理服务里把数据管道写在训练脚本里最后平台规模一上去改哪里都牵一发动全身。5.2 网关层的特殊性流式输出、长连接与模型路由模型网关和普通API网关最大的差别在于流式输出。大模型接口基本都是SSEServer-Sent Events流式返回一个请求可能维持几十秒的长连接传统网关的短连接、小超时、缓冲整个响应的做法全部不适用。网关必须支持流式透传、流式限流、以及半开连接时的优雅断开。模型路由也是网关的核心职责。多模型共存时路由策略不只是简单的model名映射还包括按需分发的优先级服务级别目标不同、降级策略主模型过载或不可用时切换到备用模型、以及成本控制贵模型只在特定请求级别启用。这些逻辑放在网关层业务方就完全不用感知背后的模型切换。另外提一句大模型的输入输出有长度限制网关层要做token级的校验和统计不能等请求全进来了才发现超长。tokenizer的计算放在网关上虽然有点开销但能避免无效请求打到推理实例上浪费算力这笔账是划算的。5.3 可观测性从毛坯指标到全链路追踪大模型平台的可观测性比普通微服务复杂一个维度。除了常规的QPS、延迟、错误率你还需要看模型加载状态、显存利用率和KV Cache占用、批处理大小、队列深度、前缀缓存命中率、GPU的算力利用率SM利用率、以及每个请求的prefill和decode阶段分别耗时多少。全链路追踪也很关键。一个业务请求可能经过业务服务 - 模型网关 - 推理实例 - 如果是Agent框架多次工具调用和多次模型调用。要把整条链路串起来需要在网关层给每个请求注入traceId并且在每次模型调用时记录模型名、prompt长度、生成token数、成本估算等信息。没有这套东西你排查一个为什么回答变慢了的问题会非常痛苦。我自己的经验是先把GPU维度的指标采集做起来用DCGM导出再逐层补全业务指标最后再上分布式追踪。顺序不要反因为GPU维度的数据是最难在事后补齐的而业务日志反而是随时可以加的。6. 真实项目中的踩坑记录与经验沉淀6.1 GPU配额不足时的处置链路回到开头那条告警。GPU配额冻结这件事在架构上意味着你不仅要管资源用得好不好还要管资源分得公不公平。我处置这类工单的标准流程是先确认是实时冻结还是预冻结预冻结说明任务还没启动只是资源预留动作然后查团队的配额池余量、当前在跑任务的真实占用率判断是额度本身不够还是被低效任务占着茅坑不拉屎。大部分情况下最后查出来的都是后者——某个训练任务用16卡跑了一个小模型的微调实际利用率不到30%把配额全部吃掉了。最终方案是把低效任务做卡数降配、插队队列里排到后面把配额释放给紧急任务。这个case说明了一件事资源调度做得再好没有一个合理的配额治理机制集群依然会被浪费时间。调度是让资源放得下配额治理是让资源用得值。6.2 显存OOM的排查链路大模型平台最常见的线上事故之一就是OOM。排查思路要分层先看是节点级OOM还是容器级OOM节点级往往是混部问题容器级则分两种情况——要么是显存预留不足权重KV Cache峰值超过设定值要么是并发请求太多导致KV Cache暴涨。针对第一种情况调整vLLM的gpu_memory_utilization和max_num_batched_tokens就能缓解针对第二种情况要控制网关层的并发放行数或者在推理引擎层设置max_num_seqs限制同时处理的序列数。还要特别注意多模态模型的显存峰值图像输入的前向计算峰值远高于文本如果平台同时接多模态模型容量规划一定要按峰值而不是平均值。这里最怕的是看起来余量充足一跑多模态就挂。6.3 模型版本管理与灰度发布大模型平台上线最后一个绕不开的环节是模型版本管理。模型的更新不能像代码那样简单发布因为新模型可能在行为上说错话、在格式输出上变化、在延迟上有明显差异。灰度发布的标准做法是新老模型实例同时部署网关先把5%流量切到新模型对比回答质量、拒绝率、延迟分布人工review一小批典型case之后再逐步放量。有条件的话模型上线前应该跑一遍自动化评估集覆盖推理能力、指令遵循、格式正确性、安全内容过滤等维度。在这个基础上还要保留快速回滚能力——回滚难不难取决于你的网关是否支持一键切回旧模型以及旧模型的实例是否还保活。我建议生产环境至少保留一个旧版本实例常驻直到新版本稳定运行一周以上。另外大模型本身的更新还涉及prompt和系统提示词的管理。很多Agent框架和知识抽取工具都会把prompt模板写死在代码里这个在架构上非常不推荐。prompt应该跟模型版本一样作为配置管理的独立对象支持按模型、按场景、按灰度比例动态下发生效。这些细节不处理你后面会发现模型没动效果却变了这类最难排查的问题。回到我个人的体会大模型时代的云原生架构设计本质上是在通用容器调度和专用AI负载之间找一个平衡点。纯粹的通用调度解决不了显存、拓扑、流式推理这些硬约束纯粹的专用平台又容易变成点状方案失去弹性和可复用性。真正落地走得稳的团队往往是从小规模开始先把一个模型的服务端到端跑通再把资源调度、配额治理、版本管理一层层加厚。架构不是设计出来的是压测、故障和复盘里逼出来的。最后分享一个小技巧每次大模型平台做架构评审时多问一句如果这张GPU卡现在突然坏了几分钟内能恢复——所有架构设计的价值都可以用这问题来检验。
