得物这类电商平台做大模型平台难点从来不是能不能跑起来而是怎么让一堆没有统一标准的模型训练任务、推理服务在同一个底座上稳定跑起来还能让算法工程师不骂人。我从项目立项到落地把搭通用大模型训练和推理平台这件事完整复盘一遍从硬件规划讲到调度设计再到推理优化和那些让人掉头发的线上问题全部摊开聊。这个平台解决的核心问题很简单以前算法团队每个人自己找卡、自己配环境、自己折腾部署一个模型一个样资源利用率惨不忍睹。平台要做的就是统一资源、统一流程、统一服务让训练和推理变成提交作业和发布服务这么简单。这篇文章适合想自建模型平台的技术负责人、负责AI基础设施的工程师以及准备从单机实验走向集群化训练的算法同学。1. 平台建设背景与需求拆解1.1 为什么不能继续各自为战先说个真实场景。当时团队里做商品文案生成的同事在本地工作站上跑微调一张卡一次只能跑一个实验想并行跑两组 LoRA 就得排队做搜推的同事自己有套推理脚本但接口格式和鉴权方式全是自己定义的业务方接入一个模型就要改一次代码还有个同事为了部署一个对话模型手动装了一下午依赖结果 CUDA 版本和另一个项目冲突。这种状态最大的问题不是慢而是不可复制、不可运维、不可度量。模型训练和推理一旦变成个人行为就谈不上资源配额、任务优先级、服务SLA这些工程化指标。所以做这个平台第一步不是选技术栈而是统一共识训练任务必须走平台提交推理服务必须走平台发布环境由平台托管资源由平台统一调度。1.2 平台的目标用户和核心诉求我在设计平台的第一版PRD时把用户分成了三类每类诉求完全不一样。算法工程师希望提交训练任务像在本地跑脚本一样简单能看到日志、指标、GPU利用率不用自己维护环境微调流程最好是填个表单就完事。业务研发希望调用模型服务像调用普通HTTP接口一样简单有标准化的鉴权、限流和文档不需要懂模型细节。平台/运维团队希望资源水位清晰、成本可归因、故障可排查。某个模型服务吃掉了多少卡、哪个业务线的训练任务最多、GPU集群还剩多少余量这些都要有数据支撑。三类诉求汇总下来平台的核心能力就收敛成四块资源池化管理、训练任务编排、推理服务托管、统一的观测运维体系。后面所有的技术选型都围绕这四块展开。1.3 设计原则先定规则再写代码平台建设最怕一上来就写代码。我定下三条原则后面所有技术决策都拿这三条来检验。第一资源与业务解耦。算法工程师不再关心GPU卡具体长在哪台机器上只关心我需要几卡、什么型号、跑多久平台负责在集群里找满足条件的资源腾挪出来。第二训练与推理隔离。训练任务短则几分钟长则几天抖动影响小在线推理服务对延迟极其敏感必须保证资源稳定。所以底层要把训练池和推理池物理或逻辑上隔离开。第三默认安全合规。所有镜像都要经过扫描所有代码沙箱运行模型文件的读写必须经过平台审计这些在电商场景里是红线不能省。2. 基础设施选型与硬件规划揭秘2.1 GPU选型训练和推理各用各的卡GPU是整个平台成本的大头选错型号后面全得返工。训练和推理对GPU的需求其实是有明显差别的。训练重算力、重伤函数吃显存推理重吞吐、重延迟控制而且对显存带宽的要求比算力更敏感。咱们分场景来看。训练侧主力我选择的是大显存、高算力的卡比如A100 80G或H800主要跑7B到70B级别的稠密模型预训练和全量微调这类卡支持张量并行和流水线并行多卡通信效率高。推理侧主力选的则是L20 48G或A10 24G主要跑7B以下模型的在线服务单卡能塞下量化后的模型性价比高。GPU型号显存适用场景单卡承载典型模型A100 80G80GB7B-70B模型训练/微调大Batch实验13B全参微调ZeRO-3H800 80G80GB大模型预训练、长序列训练70B训练多卡并行L20 48G48GB7B以下在线推理LoRA微调7B INT4量化后并发推理A10 24G24GB轻量推理、开发调试3B量化模型多实例部署这里的核心思路是物尽其用。A100跑推理性价比太低L20跑大模型训练显存又不够。把不同型号的卡划分到不同资源池训练池和推理池之间通过资源配额动态调整比如大促前推理流量高峰可以临时把一部分空闲训练卡划拨到推理池但这个操作必须由平台管理员审批执行不能自动混部。2.2 存储选型数据湖和并行文件系统两手抓训练平台和普通应用平台一个很大的不同在于数据访问模式。训练任务要高频读取海量样本如果存储的吞吐跟不上GPU就会饿肚子等数据训练效率大打折扣。我把存储分成两层。第一层是对象存储存放原始数据集、模型Checkpoint备份、日志归档选的是兼容S3协议的对象存储服务容量弹性成本低。第二层是并行文件系统挂载到训练容器里存放当前训练任务需要频繁读取的数据集子集和实时写入的Checkpoint用的是Lustre或GPFS这类并行文件系统读写带宽能到GB/s级别。这里面有个非常关键的细节训练容器里如果直接读对象存储每个epoch都要从远端拉数据光等网络IO就能吃掉30%的训练时间。我的做法是做一个数据缓存层首次读取时把热数据灌到并行文件系统里后续epoch直接从本地缓存读。实测下来数据读取时间从分钟级降到秒级GPU利用率直接拉升了20多个百分点。2.3 网络规划训练集群要组高速内网大模型分布式训练最怕网络瓶颈。数据并行时AllReduce通信张量并行时每层都要全量通信这些操作对网络带宽和延迟都极其敏感。如果用普通的万兆以太网跑千亿级模型时通信时间甚至超过计算时间。我们的训练集群全部走RDMA网络交换机支持无损网络GPU节点间通信走RoCEv2或者Infiniband。规划上注意两点一是训练节点尽量放在同一个可用区避免跨机房通信二是大模型训练任务的节点组要尽量在物理拓扑上相邻减少跨交换机跳数。这部分没法做虚拟化隔离必须在硬件规划阶段就把拓扑定好后面迁移成本极高。3. 训练平台架构与核心功能落地3.1 平台整体模块划分整个训练平台的架构可以概括为一入口、两平面、三服务。一入口是统一的训练平台入口支持Web界面和命令行工具两种方式算法工程师喜欢各有不同全都要支持。两平面是控制面和数据面控制面负责任务调度、配额管理、镜像管理数据面负责实际执行训练容器。三服务分别是资源管理服务负责GPU资源的分配和回收、任务编排服务负责训练任务的生命周期管理、观测服务负责日志、指标、事件的采集和展示。这里有个容易踩的坑控制面组件如果和训练任务混跑在同一批GPU机器上一个训练任务的网络风暴可能会拖垮整个控制面。我的做法是控制面组件单独部署在CPU节点上GPU节点只做训练执行这样即使训练集群全挂平台入口和调度逻辑依然可用。3.2 镜像与环境的标准化封装环境统一是平台能落地的前提。算法工程师以前自己conda装环境现在全部改成平台提供的镜像构建服务。具体做法是平台内置几个基础镜像按框架版本和CUDA版本区分比如pytorch-2.1-cuda-12.1、tensorflow-2.13-cuda-11.8这类的作为构建其他镜像的底座。算法工程师可以在基础镜像之上通过Dockerfile或者平台提供的交互式构建工具加入自己的依赖构建好推到平台的镜像仓库训练时直接指定镜像名即可。这个流程看起来简单但统一之后收益巨大。以前在我机器上是好的这句话在平台上是行不通了所有人的训练环境都基于同样的镜像基线环境问题导致的训练失败率大幅下降。我在镜像管理里还做了一个安全扫描的环节镜像推送到私有仓库之前必须经过漏洞扫描和敏感信息扫描防止有人把密钥或者数据集地址直接打进镜像里。3.3 任务调度和资源分配策略调度器是训练平台技术含量最高的模块。开源方案里Volcano和Kueue比较成熟我们最终选了Volcano因为在GPU资源调度、Gang Scheduling成组调度和队列管理方面更贴合训练场景。Gang Scheduling是训练任务必须支持的特性。一个分布式训练任务通常占用8张卡如果调度器只调度到6张卡就启动训练整个任务会一直阻塞等待剩下的卡又占着不用造成资源死锁。Volcano的Gang Scheduling会保证一个任务的所有资源都齐了才启动要么全给要么不给。我在实践中还配置了队列权重比如训练A队占50%的配额训练B队占30%剩下的作为抢占池。紧急任务可以抢占低优任务的资源但被抢占的任务会自动保存Checkpoint等资源释放后续跑不会从头再来。资源配额这块我还要多说一句。配额不能只看总量要看可同时运行的作业数和单作业最大卡数两个维度否则会出现一个人提交了一个需要64卡的任务把整队资源全部占完其他同事全部排队的情况。3.4 分布式训练框架的接入与封装平台本身不生产训练能力它要做的是把各种各样的训练框架统一接进来。我们在平台里预置了PyTorch的DDP、FSDP、DeepSpeed和Megatron-LM的启动脚本模板工程师提交任务时只填几个必要参数比如模型架构、数据集路径、GPU卡数、训练epoch数平台会自动生成启动命令并注入环境变量。这里有个很重要的细节分布式训练的启动其实是有固定套路的。以PyTorch为例多机多卡训练需要设置MASTER_ADDR、MASTER_PORT、WORLD_SIZE、RANK这些环境变量然后通过torchrun启动。平台把这些细节全部包装掉了工程师甚至不需要知道自己的任务跑在哪台机器上也不用管节点间的网络配置。这对算法工程师的体验提升是非常明显的。还有Lora这类参数高效微调平台也要能支持。我们把Lora训练做成了流程化模板工程师提交任务时选择基础模型版本和Lora配置平台自动从模型仓库拉取基座模型训练完成后再把Lora权重单独存一份方便后续合并或者直接用于向量化服务。3.5 训练过程的可观测性和稳定性训练跑起来只是开始能观测、能止损才是平台真正值钱的地方。我们在每个训练容器里都注入了监控采集组件采集GPU利用率、显存使用、训练loss、吞吐量这些指标汇总到监控系统里实时绘制曲线。一旦发现loss发散或者GPU利用率掉到低谷告警系统会立刻推送消息到对应的工程师。训练中断后的自动恢复也是一开始就要做的功能。大模型训练动不动跑几天中途一台机器故障导致整个任务崩溃如果没有容错机制前面的算力全白费了。我们做了两件事第一周期性保存Checkpoint默认每30分钟一次保存到并行文件系统第二任务级健康检查发现训练进程退出后自动重启容器并从最近的Checkpoint接续训练。这个机制一次性能帮助团队避免好几天的无效等待。4. 推理平台的关键技术与优化实战4.1 推理引擎选型对比之后只留了一个推理引擎的选择直接影响服务的性能和成本。开源生态里最常用的几个推理框架我全都测过一轮包括vLLM、SGLang、TGI和TensorRT-LLM。推理框架优势劣势适合场景vLLMPagedAttention显存管理优秀吞吐高社区活跃新模型算子适配有滞后绝大多数在线对话、生成服务SGLang多模态和结构化输出支持好RadixAttention缓存命中率高与vLLM相比生态稍弱复杂Prompt、大并发场景TGIHuggingFace生态紧密部署简单性能上限比vLLM略低快速试点、小规模服务TensorRT-LLM单卡性能极致延迟最低编译复杂模型适配成本高高并发、超低延迟的限定场景实测下来vLLM的综合性价比最高我们主力推理服务都跑在它上面。SGLang在部分场景下的前缀缓存命中率表现更好所以对一些Prompt高度模板化的服务比如商品摘要生成我们会单独用SGLang起服务。TensorRT-LLM虽然性能最好但新模型接入成本太高每次升级模型都要重新编译优化不适合快速迭代的平台场景。4.2 显存估算与KV Cache调优推理服务部署最常遇到的问题就是显存不够。很多同学不看模型显存需求直接部署结果服务一启动就OOM。我教大家一套简单的估算逻辑。以7B模型为例。FP16精度下模型权重占用的显存大约是参数量 × 2字节也就是14GB。这里还只是权重真正吃显存的大户是KV Cache。KV Cache的大小可以用这个公式估算KV Cache显存 2 × 层数 × 注意力头数 × 每个头的维度 × 序列长度 × 并发数 × 字节数。以7B模型为例假设32层、32个注意力头、每个头128维、序列长度2048、并发数16、FP16精度算下来KV Cache大约要占用2 × 32 × 32 × 128 × 2048 × 16 × 2字节约等于16GB。所以你看7B模型部署在线服务时光权重加KV Cache就要30GB显存单张A10 24G是塞不下的必须量化。我们通常的做法是7B以下模型用INT4量化后部署在L20或A10上7B到13B模型用INT8量化后部署在L20上13B以上用多卡张量并行部署。量化后效果会有轻微损失但换来的是成倍的吞吐提升实际业务场景里这点损失基本都是可接受的。4.3 弹性伸缩和优雅缩容策略在线推理服务最麻烦的特性是流量波动。白天高峰期几十个并发凌晨可能只有几个并发。如果服务只部署固定实例要么高峰期牺牲延迟要么低峰期白白烧钱。我们的推理服务全部接入了弹性伸缩。核心指标用两类GPU利用率和平均排队请求数。当GPU利用率超过80%且平均排队请求数持续增长时平台自动扩容服务实例当GPU利用率低于30%持续10分钟自动缩容一部分实例。这里要特别注意缩容不能太激进模型服务加载很慢一旦流量突增但已经缩容了来不及扩容就会大量超时。我的经验是保留一个最小安全水位比如服务承载峰值流量的30%。模型预热也是推理服务的隐藏坑。冷启动一个新实例后模型权重会从磁盘加载到显存首次请求的延迟会特别高。我们在容器启动脚本里加了一个预热逻辑模型加载到显存后先发几条哑请求跑一遍确认推理路径正常后才把实例挂到负载均衡后面确保用户请求不会打到未就绪的实例上。4.4 推理服务的网关与兼容层业务方调用模型服务不应该关心模型后端是什么引擎、跑在哪个实例上他们只需要一个统一的接口。所以我们做了一个推理网关对外暴露兼容OpenAI格式的HTTP接口模型列表、对话补全、向量化这些接口全部标准化。业务方接入新模型时只需要在平台上申请一个API Key拿到网关地址就能直接调用无需关心后端的模型推理细节。网关这层还承担了限流、鉴权、计量的职责。每个业务方有独立的配额流量超出会自动限流而不是直接打爆后端服务。每次推理调用都会记录Token数量、响应时间方便月底核算成本和反推业务量。这个设计给平台带来的直接好处是业务方接入模型的时间从按天计算降到按小时计算。5. 平台落地过程中的常见问题与排查实录5.1 训练任务显存OOM的排查流程训练中OOM是我见过最频繁的问题。刚上平台的时候同学提交了个13B模型的微调任务单卡24G显存Batch Size设置成8结果训练跑了几千步之后突然OOM。原因很简单Batch Size太大激活值在反向传播时峰值显存超了。排查OOM不能光看报错说CUDA out of memory就完事。我建议按这个顺序排查先用nvidia-smi看显存占用时间线确认是模型权重占的多还是激活值占的多再把Batch Size减半试跑如果显存占用明显下降说明是激活值问题如果是权重就爆了说明该上DeepSpeed ZeRO或者FSDP了不能硬扛。为了避免这个坑反复出现平台在提交任务时做了个前置检查根据模型参数量、训练精度、单卡显存大小自动估算最大安全Batch Size如果工程师填的参数超了系统直接提示调整而不是等到训练跑了一半才崩。5.2 推理服务延迟抖动的原因和解法有个线上推理服务测试的时候P99延迟只有200毫秒上线后压一压就到2秒了。排查下来发现两个问题叠加第一推理服务并发参数设置过高导致GPU显存里KV Cache被大量请求抢占单个请求的可用显存变小大请求排队时间变长第二同一个GPU上部署了多个推理实例内存带宽被争抢。推理服务并发参数不是越大越好它和Batch Size、模型大小、显存容量强相关需要实测调参。我一般先用goroutine模拟并发请求逐步调高并发数观测P99延迟和GPU利用率曲线找到GPU利用率和延迟均衡的临界点。至于多实例混部我的建议是线上服务尽量不要在同一个GPU上部署多个独立实例除非用的是MIG切分或者显存量化后确实够用。5.3 分布式训练通信慢的棘手问题有一次8卡训练任务理论算力利用率应该到90%实际只有50%。看监控发现GPU利用率像心电图一样上去一下掉下来典型的等待通信特征。排查发现两个节点之间走的是普通的TCP网络RDMA根本没生效。后来验证了一下光改网络协议没用torchrun启动参数里的NCCL_IB_DISABLE没有设为0nccl默认禁用了Infiniband。这个问题其实很隐蔽训练脚本能正常跑但通信方式走的是回退路径。设置环境变量NCCL_DEBUGINFO后train loog里明确显示用的是TCP Socket而不是IB问题立刻暴露。这类问题在平台建设初期经常出现我建议训练任务的默认环境变量统一由平台注入工程师不要手动覆盖否则每个人配置不一样出了通信问题很难排查。5.4 平台自身的高可用和故障演练训练平台本身也是系统它也会挂。我们经历过一次控制面数据库锁死导致所有训练任务无法提交在线推理服务倒是没受影响因为推理服务是独立的数据面只要容器还活着就能继续跑。这次事故让我意识到平台的关键服务必须做高可用同时要定期做故障演练。我梳理了平台的高可用清单数据库主备切换要能自动完成调度器和API Server必须至少两个副本对象存储要跨区域冗余。每个季度做一次演练模拟一个GPU节点宕机、一个机房网络抖动、一个控制面服务被kill掉确认整个平台在这些故障下依然能保证已运行的训练任务不丢、在线推理服务不中断。这个流程看起来麻烦但真出大事的时候能救整个团队。6. 个人经验与后续演进思考整个平台从需求梳理到上线最深的体会是要坚持小步快跑、只做闭环。第一版只做了三件事GPU资源池化、训练任务提交与日志查看、一个简单的镜像服务。就这三件事让算法团队从自己折腾环境变成了提交任务跑起来体验的改善是立竿见影的。后来才逐步加上分布式训练支持、推理服务托管、弹性伸缩、成本报表这些进阶功能。如果让我从头再来我会把推理网关和模型仓库放在更早的优先级。训练平台是给算法用的推理平台是给业务用的两者之间必须有模型仓库这个桥梁来传递标准化的模型产物。平台初期如果只顾训练不顾推理模型上线时又要手忙脚乱前期的效率优势会被抵消。还有成本治理这方面平台上线后很容易出现资源滥用比如有人提交了任务但一直挂在队列里不跑占着配额不释放有人把批量推理任务写成了长时间运行的常驻服务。我们后来加了空闲资源回收机制容器内连续一段时间没有GPU计算操作自动冻结资源把GPU释放回资源池重新分配。这套机制让集群整体利用率提高了将近三成。这套平台方案目前支撑的业务包括商品文案生成、智能客服辅助、个性化推荐解释等多种模型后续还在推进推理服务和训练任务的混部调度目标是进一步把GPU资源池的利用率推高。平台的演进没有终点每一波模型升级都会带来新的工程挑战这也是做基础设施最有意思的地方。 大模型训练推理平台建设实战：GPU资源池化与弹性伸缩
得物这类电商平台做大模型平台难点从来不是能不能跑起来而是怎么让一堆没有统一标准的模型训练任务、推理服务在同一个底座上稳定跑起来还能让算法工程师不骂人。我从项目立项到落地把搭通用大模型训练和推理平台这件事完整复盘一遍从硬件规划讲到调度设计再到推理优化和那些让人掉头发的线上问题全部摊开聊。这个平台解决的核心问题很简单以前算法团队每个人自己找卡、自己配环境、自己折腾部署一个模型一个样资源利用率惨不忍睹。平台要做的就是统一资源、统一流程、统一服务让训练和推理变成提交作业和发布服务这么简单。这篇文章适合想自建模型平台的技术负责人、负责AI基础设施的工程师以及准备从单机实验走向集群化训练的算法同学。1. 平台建设背景与需求拆解1.1 为什么不能继续各自为战先说个真实场景。当时团队里做商品文案生成的同事在本地工作站上跑微调一张卡一次只能跑一个实验想并行跑两组 LoRA 就得排队做搜推的同事自己有套推理脚本但接口格式和鉴权方式全是自己定义的业务方接入一个模型就要改一次代码还有个同事为了部署一个对话模型手动装了一下午依赖结果 CUDA 版本和另一个项目冲突。这种状态最大的问题不是慢而是不可复制、不可运维、不可度量。模型训练和推理一旦变成个人行为就谈不上资源配额、任务优先级、服务SLA这些工程化指标。所以做这个平台第一步不是选技术栈而是统一共识训练任务必须走平台提交推理服务必须走平台发布环境由平台托管资源由平台统一调度。1.2 平台的目标用户和核心诉求我在设计平台的第一版PRD时把用户分成了三类每类诉求完全不一样。算法工程师希望提交训练任务像在本地跑脚本一样简单能看到日志、指标、GPU利用率不用自己维护环境微调流程最好是填个表单就完事。业务研发希望调用模型服务像调用普通HTTP接口一样简单有标准化的鉴权、限流和文档不需要懂模型细节。平台/运维团队希望资源水位清晰、成本可归因、故障可排查。某个模型服务吃掉了多少卡、哪个业务线的训练任务最多、GPU集群还剩多少余量这些都要有数据支撑。三类诉求汇总下来平台的核心能力就收敛成四块资源池化管理、训练任务编排、推理服务托管、统一的观测运维体系。后面所有的技术选型都围绕这四块展开。1.3 设计原则先定规则再写代码平台建设最怕一上来就写代码。我定下三条原则后面所有技术决策都拿这三条来检验。第一资源与业务解耦。算法工程师不再关心GPU卡具体长在哪台机器上只关心我需要几卡、什么型号、跑多久平台负责在集群里找满足条件的资源腾挪出来。第二训练与推理隔离。训练任务短则几分钟长则几天抖动影响小在线推理服务对延迟极其敏感必须保证资源稳定。所以底层要把训练池和推理池物理或逻辑上隔离开。第三默认安全合规。所有镜像都要经过扫描所有代码沙箱运行模型文件的读写必须经过平台审计这些在电商场景里是红线不能省。2. 基础设施选型与硬件规划揭秘2.1 GPU选型训练和推理各用各的卡GPU是整个平台成本的大头选错型号后面全得返工。训练和推理对GPU的需求其实是有明显差别的。训练重算力、重伤函数吃显存推理重吞吐、重延迟控制而且对显存带宽的要求比算力更敏感。咱们分场景来看。训练侧主力我选择的是大显存、高算力的卡比如A100 80G或H800主要跑7B到70B级别的稠密模型预训练和全量微调这类卡支持张量并行和流水线并行多卡通信效率高。推理侧主力选的则是L20 48G或A10 24G主要跑7B以下模型的在线服务单卡能塞下量化后的模型性价比高。GPU型号显存适用场景单卡承载典型模型A100 80G80GB7B-70B模型训练/微调大Batch实验13B全参微调ZeRO-3H800 80G80GB大模型预训练、长序列训练70B训练多卡并行L20 48G48GB7B以下在线推理LoRA微调7B INT4量化后并发推理A10 24G24GB轻量推理、开发调试3B量化模型多实例部署这里的核心思路是物尽其用。A100跑推理性价比太低L20跑大模型训练显存又不够。把不同型号的卡划分到不同资源池训练池和推理池之间通过资源配额动态调整比如大促前推理流量高峰可以临时把一部分空闲训练卡划拨到推理池但这个操作必须由平台管理员审批执行不能自动混部。2.2 存储选型数据湖和并行文件系统两手抓训练平台和普通应用平台一个很大的不同在于数据访问模式。训练任务要高频读取海量样本如果存储的吞吐跟不上GPU就会饿肚子等数据训练效率大打折扣。我把存储分成两层。第一层是对象存储存放原始数据集、模型Checkpoint备份、日志归档选的是兼容S3协议的对象存储服务容量弹性成本低。第二层是并行文件系统挂载到训练容器里存放当前训练任务需要频繁读取的数据集子集和实时写入的Checkpoint用的是Lustre或GPFS这类并行文件系统读写带宽能到GB/s级别。这里面有个非常关键的细节训练容器里如果直接读对象存储每个epoch都要从远端拉数据光等网络IO就能吃掉30%的训练时间。我的做法是做一个数据缓存层首次读取时把热数据灌到并行文件系统里后续epoch直接从本地缓存读。实测下来数据读取时间从分钟级降到秒级GPU利用率直接拉升了20多个百分点。2.3 网络规划训练集群要组高速内网大模型分布式训练最怕网络瓶颈。数据并行时AllReduce通信张量并行时每层都要全量通信这些操作对网络带宽和延迟都极其敏感。如果用普通的万兆以太网跑千亿级模型时通信时间甚至超过计算时间。我们的训练集群全部走RDMA网络交换机支持无损网络GPU节点间通信走RoCEv2或者Infiniband。规划上注意两点一是训练节点尽量放在同一个可用区避免跨机房通信二是大模型训练任务的节点组要尽量在物理拓扑上相邻减少跨交换机跳数。这部分没法做虚拟化隔离必须在硬件规划阶段就把拓扑定好后面迁移成本极高。3. 训练平台架构与核心功能落地3.1 平台整体模块划分整个训练平台的架构可以概括为一入口、两平面、三服务。一入口是统一的训练平台入口支持Web界面和命令行工具两种方式算法工程师喜欢各有不同全都要支持。两平面是控制面和数据面控制面负责任务调度、配额管理、镜像管理数据面负责实际执行训练容器。三服务分别是资源管理服务负责GPU资源的分配和回收、任务编排服务负责训练任务的生命周期管理、观测服务负责日志、指标、事件的采集和展示。这里有个容易踩的坑控制面组件如果和训练任务混跑在同一批GPU机器上一个训练任务的网络风暴可能会拖垮整个控制面。我的做法是控制面组件单独部署在CPU节点上GPU节点只做训练执行这样即使训练集群全挂平台入口和调度逻辑依然可用。3.2 镜像与环境的标准化封装环境统一是平台能落地的前提。算法工程师以前自己conda装环境现在全部改成平台提供的镜像构建服务。具体做法是平台内置几个基础镜像按框架版本和CUDA版本区分比如pytorch-2.1-cuda-12.1、tensorflow-2.13-cuda-11.8这类的作为构建其他镜像的底座。算法工程师可以在基础镜像之上通过Dockerfile或者平台提供的交互式构建工具加入自己的依赖构建好推到平台的镜像仓库训练时直接指定镜像名即可。这个流程看起来简单但统一之后收益巨大。以前在我机器上是好的这句话在平台上是行不通了所有人的训练环境都基于同样的镜像基线环境问题导致的训练失败率大幅下降。我在镜像管理里还做了一个安全扫描的环节镜像推送到私有仓库之前必须经过漏洞扫描和敏感信息扫描防止有人把密钥或者数据集地址直接打进镜像里。3.3 任务调度和资源分配策略调度器是训练平台技术含量最高的模块。开源方案里Volcano和Kueue比较成熟我们最终选了Volcano因为在GPU资源调度、Gang Scheduling成组调度和队列管理方面更贴合训练场景。Gang Scheduling是训练任务必须支持的特性。一个分布式训练任务通常占用8张卡如果调度器只调度到6张卡就启动训练整个任务会一直阻塞等待剩下的卡又占着不用造成资源死锁。Volcano的Gang Scheduling会保证一个任务的所有资源都齐了才启动要么全给要么不给。我在实践中还配置了队列权重比如训练A队占50%的配额训练B队占30%剩下的作为抢占池。紧急任务可以抢占低优任务的资源但被抢占的任务会自动保存Checkpoint等资源释放后续跑不会从头再来。资源配额这块我还要多说一句。配额不能只看总量要看可同时运行的作业数和单作业最大卡数两个维度否则会出现一个人提交了一个需要64卡的任务把整队资源全部占完其他同事全部排队的情况。3.4 分布式训练框架的接入与封装平台本身不生产训练能力它要做的是把各种各样的训练框架统一接进来。我们在平台里预置了PyTorch的DDP、FSDP、DeepSpeed和Megatron-LM的启动脚本模板工程师提交任务时只填几个必要参数比如模型架构、数据集路径、GPU卡数、训练epoch数平台会自动生成启动命令并注入环境变量。这里有个很重要的细节分布式训练的启动其实是有固定套路的。以PyTorch为例多机多卡训练需要设置MASTER_ADDR、MASTER_PORT、WORLD_SIZE、RANK这些环境变量然后通过torchrun启动。平台把这些细节全部包装掉了工程师甚至不需要知道自己的任务跑在哪台机器上也不用管节点间的网络配置。这对算法工程师的体验提升是非常明显的。还有Lora这类参数高效微调平台也要能支持。我们把Lora训练做成了流程化模板工程师提交任务时选择基础模型版本和Lora配置平台自动从模型仓库拉取基座模型训练完成后再把Lora权重单独存一份方便后续合并或者直接用于向量化服务。3.5 训练过程的可观测性和稳定性训练跑起来只是开始能观测、能止损才是平台真正值钱的地方。我们在每个训练容器里都注入了监控采集组件采集GPU利用率、显存使用、训练loss、吞吐量这些指标汇总到监控系统里实时绘制曲线。一旦发现loss发散或者GPU利用率掉到低谷告警系统会立刻推送消息到对应的工程师。训练中断后的自动恢复也是一开始就要做的功能。大模型训练动不动跑几天中途一台机器故障导致整个任务崩溃如果没有容错机制前面的算力全白费了。我们做了两件事第一周期性保存Checkpoint默认每30分钟一次保存到并行文件系统第二任务级健康检查发现训练进程退出后自动重启容器并从最近的Checkpoint接续训练。这个机制一次性能帮助团队避免好几天的无效等待。4. 推理平台的关键技术与优化实战4.1 推理引擎选型对比之后只留了一个推理引擎的选择直接影响服务的性能和成本。开源生态里最常用的几个推理框架我全都测过一轮包括vLLM、SGLang、TGI和TensorRT-LLM。推理框架优势劣势适合场景vLLMPagedAttention显存管理优秀吞吐高社区活跃新模型算子适配有滞后绝大多数在线对话、生成服务SGLang多模态和结构化输出支持好RadixAttention缓存命中率高与vLLM相比生态稍弱复杂Prompt、大并发场景TGIHuggingFace生态紧密部署简单性能上限比vLLM略低快速试点、小规模服务TensorRT-LLM单卡性能极致延迟最低编译复杂模型适配成本高高并发、超低延迟的限定场景实测下来vLLM的综合性价比最高我们主力推理服务都跑在它上面。SGLang在部分场景下的前缀缓存命中率表现更好所以对一些Prompt高度模板化的服务比如商品摘要生成我们会单独用SGLang起服务。TensorRT-LLM虽然性能最好但新模型接入成本太高每次升级模型都要重新编译优化不适合快速迭代的平台场景。4.2 显存估算与KV Cache调优推理服务部署最常遇到的问题就是显存不够。很多同学不看模型显存需求直接部署结果服务一启动就OOM。我教大家一套简单的估算逻辑。以7B模型为例。FP16精度下模型权重占用的显存大约是参数量 × 2字节也就是14GB。这里还只是权重真正吃显存的大户是KV Cache。KV Cache的大小可以用这个公式估算KV Cache显存 2 × 层数 × 注意力头数 × 每个头的维度 × 序列长度 × 并发数 × 字节数。以7B模型为例假设32层、32个注意力头、每个头128维、序列长度2048、并发数16、FP16精度算下来KV Cache大约要占用2 × 32 × 32 × 128 × 2048 × 16 × 2字节约等于16GB。所以你看7B模型部署在线服务时光权重加KV Cache就要30GB显存单张A10 24G是塞不下的必须量化。我们通常的做法是7B以下模型用INT4量化后部署在L20或A10上7B到13B模型用INT8量化后部署在L20上13B以上用多卡张量并行部署。量化后效果会有轻微损失但换来的是成倍的吞吐提升实际业务场景里这点损失基本都是可接受的。4.3 弹性伸缩和优雅缩容策略在线推理服务最麻烦的特性是流量波动。白天高峰期几十个并发凌晨可能只有几个并发。如果服务只部署固定实例要么高峰期牺牲延迟要么低峰期白白烧钱。我们的推理服务全部接入了弹性伸缩。核心指标用两类GPU利用率和平均排队请求数。当GPU利用率超过80%且平均排队请求数持续增长时平台自动扩容服务实例当GPU利用率低于30%持续10分钟自动缩容一部分实例。这里要特别注意缩容不能太激进模型服务加载很慢一旦流量突增但已经缩容了来不及扩容就会大量超时。我的经验是保留一个最小安全水位比如服务承载峰值流量的30%。模型预热也是推理服务的隐藏坑。冷启动一个新实例后模型权重会从磁盘加载到显存首次请求的延迟会特别高。我们在容器启动脚本里加了一个预热逻辑模型加载到显存后先发几条哑请求跑一遍确认推理路径正常后才把实例挂到负载均衡后面确保用户请求不会打到未就绪的实例上。4.4 推理服务的网关与兼容层业务方调用模型服务不应该关心模型后端是什么引擎、跑在哪个实例上他们只需要一个统一的接口。所以我们做了一个推理网关对外暴露兼容OpenAI格式的HTTP接口模型列表、对话补全、向量化这些接口全部标准化。业务方接入新模型时只需要在平台上申请一个API Key拿到网关地址就能直接调用无需关心后端的模型推理细节。网关这层还承担了限流、鉴权、计量的职责。每个业务方有独立的配额流量超出会自动限流而不是直接打爆后端服务。每次推理调用都会记录Token数量、响应时间方便月底核算成本和反推业务量。这个设计给平台带来的直接好处是业务方接入模型的时间从按天计算降到按小时计算。5. 平台落地过程中的常见问题与排查实录5.1 训练任务显存OOM的排查流程训练中OOM是我见过最频繁的问题。刚上平台的时候同学提交了个13B模型的微调任务单卡24G显存Batch Size设置成8结果训练跑了几千步之后突然OOM。原因很简单Batch Size太大激活值在反向传播时峰值显存超了。排查OOM不能光看报错说CUDA out of memory就完事。我建议按这个顺序排查先用nvidia-smi看显存占用时间线确认是模型权重占的多还是激活值占的多再把Batch Size减半试跑如果显存占用明显下降说明是激活值问题如果是权重就爆了说明该上DeepSpeed ZeRO或者FSDP了不能硬扛。为了避免这个坑反复出现平台在提交任务时做了个前置检查根据模型参数量、训练精度、单卡显存大小自动估算最大安全Batch Size如果工程师填的参数超了系统直接提示调整而不是等到训练跑了一半才崩。5.2 推理服务延迟抖动的原因和解法有个线上推理服务测试的时候P99延迟只有200毫秒上线后压一压就到2秒了。排查下来发现两个问题叠加第一推理服务并发参数设置过高导致GPU显存里KV Cache被大量请求抢占单个请求的可用显存变小大请求排队时间变长第二同一个GPU上部署了多个推理实例内存带宽被争抢。推理服务并发参数不是越大越好它和Batch Size、模型大小、显存容量强相关需要实测调参。我一般先用goroutine模拟并发请求逐步调高并发数观测P99延迟和GPU利用率曲线找到GPU利用率和延迟均衡的临界点。至于多实例混部我的建议是线上服务尽量不要在同一个GPU上部署多个独立实例除非用的是MIG切分或者显存量化后确实够用。5.3 分布式训练通信慢的棘手问题有一次8卡训练任务理论算力利用率应该到90%实际只有50%。看监控发现GPU利用率像心电图一样上去一下掉下来典型的等待通信特征。排查发现两个节点之间走的是普通的TCP网络RDMA根本没生效。后来验证了一下光改网络协议没用torchrun启动参数里的NCCL_IB_DISABLE没有设为0nccl默认禁用了Infiniband。这个问题其实很隐蔽训练脚本能正常跑但通信方式走的是回退路径。设置环境变量NCCL_DEBUGINFO后train loog里明确显示用的是TCP Socket而不是IB问题立刻暴露。这类问题在平台建设初期经常出现我建议训练任务的默认环境变量统一由平台注入工程师不要手动覆盖否则每个人配置不一样出了通信问题很难排查。5.4 平台自身的高可用和故障演练训练平台本身也是系统它也会挂。我们经历过一次控制面数据库锁死导致所有训练任务无法提交在线推理服务倒是没受影响因为推理服务是独立的数据面只要容器还活着就能继续跑。这次事故让我意识到平台的关键服务必须做高可用同时要定期做故障演练。我梳理了平台的高可用清单数据库主备切换要能自动完成调度器和API Server必须至少两个副本对象存储要跨区域冗余。每个季度做一次演练模拟一个GPU节点宕机、一个机房网络抖动、一个控制面服务被kill掉确认整个平台在这些故障下依然能保证已运行的训练任务不丢、在线推理服务不中断。这个流程看起来麻烦但真出大事的时候能救整个团队。6. 个人经验与后续演进思考整个平台从需求梳理到上线最深的体会是要坚持小步快跑、只做闭环。第一版只做了三件事GPU资源池化、训练任务提交与日志查看、一个简单的镜像服务。就这三件事让算法团队从自己折腾环境变成了提交任务跑起来体验的改善是立竿见影的。后来才逐步加上分布式训练支持、推理服务托管、弹性伸缩、成本报表这些进阶功能。如果让我从头再来我会把推理网关和模型仓库放在更早的优先级。训练平台是给算法用的推理平台是给业务用的两者之间必须有模型仓库这个桥梁来传递标准化的模型产物。平台初期如果只顾训练不顾推理模型上线时又要手忙脚乱前期的效率优势会被抵消。还有成本治理这方面平台上线后很容易出现资源滥用比如有人提交了任务但一直挂在队列里不跑占着配额不释放有人把批量推理任务写成了长时间运行的常驻服务。我们后来加了空闲资源回收机制容器内连续一段时间没有GPU计算操作自动冻结资源把GPU释放回资源池重新分配。这套机制让集群整体利用率提高了将近三成。这套平台方案目前支撑的业务包括商品文案生成、智能客服辅助、个性化推荐解释等多种模型后续还在推进推理服务和训练任务的混部调度目标是进一步把GPU资源池的利用率推高。平台的演进没有终点每一波模型升级都会带来新的工程挑战这也是做基础设施最有意思的地方。