1. 为什么要自己造轮子业务需求倒逼的技术决策得物App的商品内容、交易链路里大模型能落地的场景远比外界想象的要多。商品标题生成、卖点提炼、客服问答、穿搭推荐理由、图片素材生产、搜索词改写、评论舆情分析每个业务方都在提需求每个团队也都在尝试自己调API、自己租卡、自己搭环境。我是在2023年下半年开始接手这个事情的。当时最直观的感受是资源是散的能力是重复造的。A团队用某家的API做文本分类B团队自己租了几张卡微调LLaMA做商品摘要C团队让外包标了一万多条数据准备训一个对话模型结果连训练脚本都是从GitHub上东拼西凑来的。这种模式下有几个肉眼可见的问题。第一GPU利用率极低。各团队各自为政有人租了8卡A100训练一个7B模型实际上只用了3天剩下27天卡在闲置有人需要推理服务图省事直接用训练卡扛QPS单卡一次只能并发几个请求响应时间动不动十几秒。第二重复造轮子且质量参差。指令微调、RLHF、量化部署这些环节每家都在做但大多没有沉淀成平台能力换个场景又要重来一遍。最典型的例子是数据清洗每个团队都在写正则、写去重脚本代码风格五花八门跑出来的数据集质量也完全不可控。第三业务方根本不知道用哪个模型。开源社区模型更新极快Llama、Qwen、Baichuan、ChatGLM各自有不同尺寸和版本。业务方来问“我应该用哪个模型”没人能给出靠谱建议——因为没有人做过系统的评测和准入机制。于是我们内部立项做了一件事从0到1搭一套通用的大模型训练和推理平台统一管理底层GPU资源统一提供数据、训练、评测、部署、监控的全链路能力让业务方只需要关心“我的数据和我的场景”其余交给平台。这里说的“通用”不是指模型通用而是指平台能力通用。不管你是微调一个7B模型做文本分类还是全参训练一个13B模型做多轮对话或者是只调用推理API做批量预测平台都能覆盖。2. 训练平台的地基算力编排、数据管道与分布式框架的选型训练平台是整个体系里最重的一块。它的核心职责不是“把训练跑起来”而是“让训练高效、稳定、可控地跑起来”。我把它拆成三个子系统算力编排、数据管道、训练框架。2.1 算力池化把GPU变成可以被调度的资源我们初期GPU资源大概有几十张后续扩展到几百张。如果让每个团队直接使用裸金属服务器资源碎片化问题会立刻暴露出来。所以我们做算力池化的思路是Kubernetes 自定义调度器 队列管理。具体做法是使用K8s作为资源调度的底座GPU节点通过Device Plugin上报资源按业务优先级划分多个队列比如“核心交易链”和“算法预研”分开排队队列之间支持抢占高优先级作业可以抢占低优先级作业的GPU单作业支持申请任意数量的GPU跨节点训练通过高速网络通信。这里有个很容易忽略的细节GPU资源的“可调度”不只是看显存容量还要看卡间通信拓扑。同样是申请8卡如果8张卡分布在4台机器上每台2张训练性能会远差于8张卡在同一台机器上通过NVLink互联。所以我们的调度器在分配GPU时会优先尝试“紧凑放置”把同一份作业尽量调度到同一台物理机的卡上。如果单机放不下再考虑多机组合。2.2 数据管道样本质量比模型规模更重要很多人一上来就想训个大模型但实际做下来会发现数据工程占了整个项目周期的80%工作量。我们平台上建设了一套标准的数据接入、清洗、去重、配比、打包的流程。对于指令微调场景数据管道的核心步骤包括格式统一所有业务方的数据统一成instruction input output的格式兼容多轮对话的messages结构清洗过滤按长度、特殊字符、语言类型、重复度进行过滤规则引擎加模型打分双重过滤低质量样本去重用MinHash LSH做大规模去重避免相似样本在训练中反复出现导致过拟合配比采样不同业务的数据量差异很大如果直接混合训练数据量大的领域会主导模型行为。所以平台支持按领域设定采样权重比如客服数据权重0.3、商品摘要权重0.2、通用对话数据权重0.5每次训练时按权重有放回地采样Tokenization与打包在离线阶段把文本转成token序列并提前打包好训练时直接加载避免在线处理拖慢训练速度。这块踩过一个实打实的坑数据配比没做好的时候模型在某个业务场景上表现极好但其他场景全面退化。后来我们加了配比采样和少量通用数据混合才解决了灾难性遗忘的问题。2.3 训练框架选型Megatron-LLM DeepSpeed的组合路线训练框架是我们选型讨论最久的部分。大模型训练的主流方案无非三种HuggingFace Transformers DeepSpeed、Megatron-LM、以及原生的PyTorch FSDP。我们的选型决策逻辑是方案优势劣势适用场景HF Trainer DeepSpeed上手快文档全分布式策略灵活性不足单机多卡、快速实验Megatron-LM含Legate等变体张量并行/流水线并行成熟学习曲线陡峭模型适配成本高超大模型、多机多卡PyTorch FSDP与PyTorch生态无缝大规模跨机训练性能一般中等规模微调最后我们采用的是一条混合路线基础能力封装在HF生态上支持DeepSpeed ZeRO阶段2/3对于需要训练13B以上模型的场景支持切换到Megatron风格的张量并行流水线并行。虽然Megatron的上手成本高但13B模型在多机多卡场景下的吞吐确实高出不少值得为它维护一套单独的入口。训练入口的抽象非常关键。我们把“训练脚本”做成了平台的“内置方案”用户只需要配置模型名、数据路径、超参数、GPU数量平台自动生成训练脚本。刚开始内部也有人质疑“哪有训练是填个表单就能跑的”但后来证明降低使用门槛是平台能推广开的核心原因。3. 推理平台的工程化从单卡硬扛到弹性服务训练平台解决的是“模型怎么来”的问题推理平台解决的是“模型怎么用”的问题。我们当时的情况是训练平台已经跑通但业务方问“微调好的模型怎么部署”“QPS能到多少”“延迟多高”我们没有统一的答案。3.1 推理框架的选型vLLM为什么是首选我们先跑通了几个方案直接用HuggingFace的generate接口做推理最慢、用FastAPI自己写一套调度太糙、用Triton Inference Server强但配置复杂、用vLLM快且生态好。最终我们把vLLM作为统一推理引擎。vLLM的核心优势在于它的PagedAttention机制显存利用率比传统方案高了好几倍。传统推理服务在生成时会给每条请求预分配最大长度的KV Cache导致显存浪费严重。PagedAttention像操作系统管理内存一样管理KV Cache按页分配用多少分配多少所以可以用更少的GPU承载更多的并发。实际效果我们测试过同样是基于Qwen-7B的模型在单张A10040GB上HF原生方式并发能力大概是4路左右vLLM开到16路还很稳且token生成延迟基本没增加。3.2 模型优化三板斧量化、投机采样、前缀缓存部署层面的优化我们主要做了三件事。第一量化。我们验证了INT8和INT4两种量化方案。对于7B模型的文本生成场景INT8量化几乎没有精度损失吞吐提升约40%INT4用GPTQ或AWQ能把显存占用降一半但部分场景会出现明显质量下降。所以我们的策略是追求质量的业务用FP16或INT8追求成本和吞吐的用INT4平台暴露开关让用户自己选。第二投机采样Speculative Decoding。这个优化在长文本生成场景非常香用一个小模型如1B先草拟若干token再由大模型一次性验证。实测在14B模型上投机采样能把生成速度提升2~3倍而输出分布基本一致。第三前缀缓存Prefix Caching。电商场景有个特点客服对话、商品文案生成这类任务system prompt和用户指令经常是固定的只有中间变量在变。vLLM的Prefix Caching能直接复用相同前缀的KV Cache首token延迟从秒级降到几十毫秒。我们在客服机器人场景上了这个能力之后接口P99延迟下降了约60%。3.3 弹性扩缩容与稳定性保障推理服务上线之后流量波动是常态。大促期间客服请求量翻三五倍如果按峰值固定资源平时就白白浪费显卡如果按平时配置大促直接扛不住。所以我们在推理平台之上做了一套弹性机制指标采集采集每个推理实例的QPS、GPU利用率、KV Cache使用率、排队请求数扩缩容策略基于排队请求数做HPA排队超过阈值就扩容低于阈值持续一段时间就缩容优雅下线缩容时不直接杀Pod而是先把实例标记为“停止接收新请求”等存量请求跑完再回收避免用户请求中断服务网格通过服务名发现实例配合负载均衡策略保证流量均匀分布。这里要提醒一个大家容易忽略的点大模型推理服务冷启动非常慢。一个7B模型加载权重需要十几秒如果HPA指标设置得太敏感扩容后流量已经回来了服务还没就绪等于白扩。我们后来加了预热机制新实例启动完成后先去请求健康检查接口通过后才接收流量。4. 训练稳定性断点续训、故障自愈与可观测性大模型训练动辄几天几周中途失败的代价极大。我们内部有过一次惨痛教训某次13B模型训练跑了6天因网络抖动导致训练进程崩溃而checkpoint每24小时才保存一次白白丢了5天算力。从那以后“稳定性”成了训练平台的第一优先级。4.1 断点续训checkpoint频率和恢复机制的权衡断点续训的核心是checkpoint。但checkpoint不是存得越频繁越好——13B模型在FP16下权重就有26GB加上优化器状态AdamW一般要2~3倍权重大小一个完整checkpoint可能超过100GB保存一次耗时好几分钟。保存期间训练是暂停的频率过高反而拖慢整体进度。我们最终的策略是双层checkpoint机制快速checkpoint只保存模型权重不保存优化器状态每隔2小时自动保存一次用于快速恢复推理或轻量任务完整checkpoint权重 优化器状态 学习率调度器状态 数据迭代器位置每24小时保存一次用于断点续训。实际崩溃恢复时优先用最近的完整checkpoint最多丢24小时如果没有完整checkpoint则用最近的快速checkpoint配合重新预热优化器。虽然丢一小段进度但比从头再来节省了几个数量级的成本。4.2 故障自愈慢节点检测与自动屏蔽训练集群最常见的故障不是“崩溃”而是“变慢”。网络抖动、散热问题、其他任务抢占带宽都会让某个节点的训练速度拖慢整体。AllReduce的同步特性决定了整个训练集群的速度取决于最慢的那个节点。我们的做法是每个训练作业定期上报各节点的step耗时如果某个节点的step耗时持续超过均值2倍判定为“慢节点”自动将该节点上的任务迁移到空闲节点重启并续训同时隔离该节点触发硬件巡检。这个机制上线后我们长时训练的失败率降低了大概70%。但它的难点在于判定阈值需要调参给得太紧会把正常波动当故障给得太松又起不到作用。我们根据实际训练日志统计最终把阈值定在“连续5个step超过均值2倍”才触发。4.3 训练可观测性一定要看Loss曲线之外的指标训练看Loss曲线是基本功但在大模型分布式训练中只看Loss完全不够。我们给训练作业标配了以下几类观测指标吞吐指标每秒处理的token数、每GPU的MFU模型浮点运算利用率通信指标梯度同步耗时占比如果超过20%就说明通信瓶颈严重资源指标GPU利用率、显存占用、温度、功耗数据管道指标数据加载器是否成为瓶颈、prefetch队列是否经常为空。最有用的一个调试案例是某次训练吞吐只有预期的60%排查一圈发现是数据加载器的num_workers设置太小GPU每次要等数据利用率像心电图一样忽高忽低。把num_workers从4调到16之后吞吐立刻回到正常水平。这种问题在单机小模型训练中不太明显但在多机大模型训练里会被放大到肉眼可见。5. 评测治理让业务方放心上线的最后一公里平台有了训练能力、推理能力还不够。业务方最怕的问题是“你怎么保证你这个模型比我现在的方案好”如果回答不上来平台的采用率就上不去。所以我们在平台里加了评测中心把模型评估从“玄学”变成“工程”。5.1 评测集建设公开基准 业务场景评测评测集分两层第一层是公开基准测试比如MMLU、C-Eval、BBH等用来衡量模型综合能力。这一层的主要作用是“体检”确保模型没有明显的通用能力退化。第二层是业务评测集这部分才是决定模型能否上线的关键。每个业务方在平台上按自己的场景提交一批典型问题形成各自的评测集。评测维度包括准确性答案是否与标注一致格式合规性输出是否符合业务方要求的JSON结构安全性是否输出违规内容指令跟随能力是否严格按用户指令执行而非自由发挥。评测可以自动跑模型微调完成后自动触发评测生成报告推送给业务方。5.2 线上效果的A/B验证与灰度发布评测集是离线指标但真正能说明问题的是线上业务指标。我们做了一整套灰度发布机制新模型先部署到影子环境流量复制线上请求但返回结果不直接生效离线对比新旧模型输出差异影子环境跑通后放量到5%真实流量观察业务指标如客服解决率、点击率、用户满意度指标正向或持平继续放量到20%、50%、100%反向就直接回滚保留旧模型服务。这个流程走下来业务方对平台的信任感提升了很多。说白了大模型平台要想被业务方接受光把模型训出来是不够的还得有一整套“证明它好”的方法论。6. 踩过的坑与经验沉淀最后分享几个实际踩过的坑这些教训比任何架构设计文档都值钱。6.1 通信库导致的多机训练卡死某次多机训练跑着跑着就hang住日志里没有任何报错进程不退出也不继续。排查了大半天最终定位是通信库的问题不同机器上的NCCL版本不一致导致AllReduce操作在某个节点上永远等不到另一个节点的消息。解决方式是平台在每次训练作业启动前强制校验所有节点的CUDA、NCCL版本和驱动版本一致版本不一致的直接拒绝调度。后来我们把环境镜像化问题彻底根治。6.2 显存碎片的隐形杀手推理服务上线初期我们遇到过服务运行几天后GPU显存被占满的情况。一开始以为是内存泄漏用nvidia-smi逐卡排查发现已分配的缓存块并不大但显存碎片严重总容量被大量“不可用的小碎片”吃掉。这是因为vLLM的PagedAttention虽然高效但在长时间运行、大量不同长度的请求进进出出后页表管理会产生碎片。我们升级到支持--enable-chunked-prefill的版本并定期重启服务后问题得到缓解。线上推理服务要建立定期重启机制我们后来做了“优雅重启流量泳道”的方案每3天自动滚动重启一轮。6.3 关于“从0到1”的一些个人体会做这类平台最大的挑战不是技术而是组织协调。技术选型、环境搭建、脚本封装这些事团队里有经验的人一周就能拉通但要让大家真正用它让业务方信任它是一个漫长的过程。我的体会是平台建设要分阶段交付不要憋大招第一阶段能跑通一个完整的训练推理流程哪怕只支持1个模型、1个业务方第二阶段加上数据管道和评测能力让第二个、第三个业务方接入第三阶段完善弹性伸缩、故障自愈、可观测性提升自动化水平第四阶段开放更多能力比如LoRA低成本微调、模型仓库、Prompt调试工具让业务方能自助服务。每个阶段都有实际业务方在使用才能持续获得反馈和资源投入。这也是我们后来平台能顺利推广到全公司多个业务线的核心经验。最后再分享一个小技巧训练和推理平台的监控面板一定不要分开看。GPU资源是共享池训练作业和推理服务相互影响非常直接。我们上线了统一的资源大盘能一眼看到“当前有多少卡被训练占用、多少卡被推理占用、每张卡的热度如何”这对资源规划和故障排查都有很大帮助。到今天为止这个大盘仍是我每天打开频率最高的页面。 从0到1搭建大模型训练推理平台：算力编排、数据管道与稳定性实践
1. 为什么要自己造轮子业务需求倒逼的技术决策得物App的商品内容、交易链路里大模型能落地的场景远比外界想象的要多。商品标题生成、卖点提炼、客服问答、穿搭推荐理由、图片素材生产、搜索词改写、评论舆情分析每个业务方都在提需求每个团队也都在尝试自己调API、自己租卡、自己搭环境。我是在2023年下半年开始接手这个事情的。当时最直观的感受是资源是散的能力是重复造的。A团队用某家的API做文本分类B团队自己租了几张卡微调LLaMA做商品摘要C团队让外包标了一万多条数据准备训一个对话模型结果连训练脚本都是从GitHub上东拼西凑来的。这种模式下有几个肉眼可见的问题。第一GPU利用率极低。各团队各自为政有人租了8卡A100训练一个7B模型实际上只用了3天剩下27天卡在闲置有人需要推理服务图省事直接用训练卡扛QPS单卡一次只能并发几个请求响应时间动不动十几秒。第二重复造轮子且质量参差。指令微调、RLHF、量化部署这些环节每家都在做但大多没有沉淀成平台能力换个场景又要重来一遍。最典型的例子是数据清洗每个团队都在写正则、写去重脚本代码风格五花八门跑出来的数据集质量也完全不可控。第三业务方根本不知道用哪个模型。开源社区模型更新极快Llama、Qwen、Baichuan、ChatGLM各自有不同尺寸和版本。业务方来问“我应该用哪个模型”没人能给出靠谱建议——因为没有人做过系统的评测和准入机制。于是我们内部立项做了一件事从0到1搭一套通用的大模型训练和推理平台统一管理底层GPU资源统一提供数据、训练、评测、部署、监控的全链路能力让业务方只需要关心“我的数据和我的场景”其余交给平台。这里说的“通用”不是指模型通用而是指平台能力通用。不管你是微调一个7B模型做文本分类还是全参训练一个13B模型做多轮对话或者是只调用推理API做批量预测平台都能覆盖。2. 训练平台的地基算力编排、数据管道与分布式框架的选型训练平台是整个体系里最重的一块。它的核心职责不是“把训练跑起来”而是“让训练高效、稳定、可控地跑起来”。我把它拆成三个子系统算力编排、数据管道、训练框架。2.1 算力池化把GPU变成可以被调度的资源我们初期GPU资源大概有几十张后续扩展到几百张。如果让每个团队直接使用裸金属服务器资源碎片化问题会立刻暴露出来。所以我们做算力池化的思路是Kubernetes 自定义调度器 队列管理。具体做法是使用K8s作为资源调度的底座GPU节点通过Device Plugin上报资源按业务优先级划分多个队列比如“核心交易链”和“算法预研”分开排队队列之间支持抢占高优先级作业可以抢占低优先级作业的GPU单作业支持申请任意数量的GPU跨节点训练通过高速网络通信。这里有个很容易忽略的细节GPU资源的“可调度”不只是看显存容量还要看卡间通信拓扑。同样是申请8卡如果8张卡分布在4台机器上每台2张训练性能会远差于8张卡在同一台机器上通过NVLink互联。所以我们的调度器在分配GPU时会优先尝试“紧凑放置”把同一份作业尽量调度到同一台物理机的卡上。如果单机放不下再考虑多机组合。2.2 数据管道样本质量比模型规模更重要很多人一上来就想训个大模型但实际做下来会发现数据工程占了整个项目周期的80%工作量。我们平台上建设了一套标准的数据接入、清洗、去重、配比、打包的流程。对于指令微调场景数据管道的核心步骤包括格式统一所有业务方的数据统一成instruction input output的格式兼容多轮对话的messages结构清洗过滤按长度、特殊字符、语言类型、重复度进行过滤规则引擎加模型打分双重过滤低质量样本去重用MinHash LSH做大规模去重避免相似样本在训练中反复出现导致过拟合配比采样不同业务的数据量差异很大如果直接混合训练数据量大的领域会主导模型行为。所以平台支持按领域设定采样权重比如客服数据权重0.3、商品摘要权重0.2、通用对话数据权重0.5每次训练时按权重有放回地采样Tokenization与打包在离线阶段把文本转成token序列并提前打包好训练时直接加载避免在线处理拖慢训练速度。这块踩过一个实打实的坑数据配比没做好的时候模型在某个业务场景上表现极好但其他场景全面退化。后来我们加了配比采样和少量通用数据混合才解决了灾难性遗忘的问题。2.3 训练框架选型Megatron-LLM DeepSpeed的组合路线训练框架是我们选型讨论最久的部分。大模型训练的主流方案无非三种HuggingFace Transformers DeepSpeed、Megatron-LM、以及原生的PyTorch FSDP。我们的选型决策逻辑是方案优势劣势适用场景HF Trainer DeepSpeed上手快文档全分布式策略灵活性不足单机多卡、快速实验Megatron-LM含Legate等变体张量并行/流水线并行成熟学习曲线陡峭模型适配成本高超大模型、多机多卡PyTorch FSDP与PyTorch生态无缝大规模跨机训练性能一般中等规模微调最后我们采用的是一条混合路线基础能力封装在HF生态上支持DeepSpeed ZeRO阶段2/3对于需要训练13B以上模型的场景支持切换到Megatron风格的张量并行流水线并行。虽然Megatron的上手成本高但13B模型在多机多卡场景下的吞吐确实高出不少值得为它维护一套单独的入口。训练入口的抽象非常关键。我们把“训练脚本”做成了平台的“内置方案”用户只需要配置模型名、数据路径、超参数、GPU数量平台自动生成训练脚本。刚开始内部也有人质疑“哪有训练是填个表单就能跑的”但后来证明降低使用门槛是平台能推广开的核心原因。3. 推理平台的工程化从单卡硬扛到弹性服务训练平台解决的是“模型怎么来”的问题推理平台解决的是“模型怎么用”的问题。我们当时的情况是训练平台已经跑通但业务方问“微调好的模型怎么部署”“QPS能到多少”“延迟多高”我们没有统一的答案。3.1 推理框架的选型vLLM为什么是首选我们先跑通了几个方案直接用HuggingFace的generate接口做推理最慢、用FastAPI自己写一套调度太糙、用Triton Inference Server强但配置复杂、用vLLM快且生态好。最终我们把vLLM作为统一推理引擎。vLLM的核心优势在于它的PagedAttention机制显存利用率比传统方案高了好几倍。传统推理服务在生成时会给每条请求预分配最大长度的KV Cache导致显存浪费严重。PagedAttention像操作系统管理内存一样管理KV Cache按页分配用多少分配多少所以可以用更少的GPU承载更多的并发。实际效果我们测试过同样是基于Qwen-7B的模型在单张A10040GB上HF原生方式并发能力大概是4路左右vLLM开到16路还很稳且token生成延迟基本没增加。3.2 模型优化三板斧量化、投机采样、前缀缓存部署层面的优化我们主要做了三件事。第一量化。我们验证了INT8和INT4两种量化方案。对于7B模型的文本生成场景INT8量化几乎没有精度损失吞吐提升约40%INT4用GPTQ或AWQ能把显存占用降一半但部分场景会出现明显质量下降。所以我们的策略是追求质量的业务用FP16或INT8追求成本和吞吐的用INT4平台暴露开关让用户自己选。第二投机采样Speculative Decoding。这个优化在长文本生成场景非常香用一个小模型如1B先草拟若干token再由大模型一次性验证。实测在14B模型上投机采样能把生成速度提升2~3倍而输出分布基本一致。第三前缀缓存Prefix Caching。电商场景有个特点客服对话、商品文案生成这类任务system prompt和用户指令经常是固定的只有中间变量在变。vLLM的Prefix Caching能直接复用相同前缀的KV Cache首token延迟从秒级降到几十毫秒。我们在客服机器人场景上了这个能力之后接口P99延迟下降了约60%。3.3 弹性扩缩容与稳定性保障推理服务上线之后流量波动是常态。大促期间客服请求量翻三五倍如果按峰值固定资源平时就白白浪费显卡如果按平时配置大促直接扛不住。所以我们在推理平台之上做了一套弹性机制指标采集采集每个推理实例的QPS、GPU利用率、KV Cache使用率、排队请求数扩缩容策略基于排队请求数做HPA排队超过阈值就扩容低于阈值持续一段时间就缩容优雅下线缩容时不直接杀Pod而是先把实例标记为“停止接收新请求”等存量请求跑完再回收避免用户请求中断服务网格通过服务名发现实例配合负载均衡策略保证流量均匀分布。这里要提醒一个大家容易忽略的点大模型推理服务冷启动非常慢。一个7B模型加载权重需要十几秒如果HPA指标设置得太敏感扩容后流量已经回来了服务还没就绪等于白扩。我们后来加了预热机制新实例启动完成后先去请求健康检查接口通过后才接收流量。4. 训练稳定性断点续训、故障自愈与可观测性大模型训练动辄几天几周中途失败的代价极大。我们内部有过一次惨痛教训某次13B模型训练跑了6天因网络抖动导致训练进程崩溃而checkpoint每24小时才保存一次白白丢了5天算力。从那以后“稳定性”成了训练平台的第一优先级。4.1 断点续训checkpoint频率和恢复机制的权衡断点续训的核心是checkpoint。但checkpoint不是存得越频繁越好——13B模型在FP16下权重就有26GB加上优化器状态AdamW一般要2~3倍权重大小一个完整checkpoint可能超过100GB保存一次耗时好几分钟。保存期间训练是暂停的频率过高反而拖慢整体进度。我们最终的策略是双层checkpoint机制快速checkpoint只保存模型权重不保存优化器状态每隔2小时自动保存一次用于快速恢复推理或轻量任务完整checkpoint权重 优化器状态 学习率调度器状态 数据迭代器位置每24小时保存一次用于断点续训。实际崩溃恢复时优先用最近的完整checkpoint最多丢24小时如果没有完整checkpoint则用最近的快速checkpoint配合重新预热优化器。虽然丢一小段进度但比从头再来节省了几个数量级的成本。4.2 故障自愈慢节点检测与自动屏蔽训练集群最常见的故障不是“崩溃”而是“变慢”。网络抖动、散热问题、其他任务抢占带宽都会让某个节点的训练速度拖慢整体。AllReduce的同步特性决定了整个训练集群的速度取决于最慢的那个节点。我们的做法是每个训练作业定期上报各节点的step耗时如果某个节点的step耗时持续超过均值2倍判定为“慢节点”自动将该节点上的任务迁移到空闲节点重启并续训同时隔离该节点触发硬件巡检。这个机制上线后我们长时训练的失败率降低了大概70%。但它的难点在于判定阈值需要调参给得太紧会把正常波动当故障给得太松又起不到作用。我们根据实际训练日志统计最终把阈值定在“连续5个step超过均值2倍”才触发。4.3 训练可观测性一定要看Loss曲线之外的指标训练看Loss曲线是基本功但在大模型分布式训练中只看Loss完全不够。我们给训练作业标配了以下几类观测指标吞吐指标每秒处理的token数、每GPU的MFU模型浮点运算利用率通信指标梯度同步耗时占比如果超过20%就说明通信瓶颈严重资源指标GPU利用率、显存占用、温度、功耗数据管道指标数据加载器是否成为瓶颈、prefetch队列是否经常为空。最有用的一个调试案例是某次训练吞吐只有预期的60%排查一圈发现是数据加载器的num_workers设置太小GPU每次要等数据利用率像心电图一样忽高忽低。把num_workers从4调到16之后吞吐立刻回到正常水平。这种问题在单机小模型训练中不太明显但在多机大模型训练里会被放大到肉眼可见。5. 评测治理让业务方放心上线的最后一公里平台有了训练能力、推理能力还不够。业务方最怕的问题是“你怎么保证你这个模型比我现在的方案好”如果回答不上来平台的采用率就上不去。所以我们在平台里加了评测中心把模型评估从“玄学”变成“工程”。5.1 评测集建设公开基准 业务场景评测评测集分两层第一层是公开基准测试比如MMLU、C-Eval、BBH等用来衡量模型综合能力。这一层的主要作用是“体检”确保模型没有明显的通用能力退化。第二层是业务评测集这部分才是决定模型能否上线的关键。每个业务方在平台上按自己的场景提交一批典型问题形成各自的评测集。评测维度包括准确性答案是否与标注一致格式合规性输出是否符合业务方要求的JSON结构安全性是否输出违规内容指令跟随能力是否严格按用户指令执行而非自由发挥。评测可以自动跑模型微调完成后自动触发评测生成报告推送给业务方。5.2 线上效果的A/B验证与灰度发布评测集是离线指标但真正能说明问题的是线上业务指标。我们做了一整套灰度发布机制新模型先部署到影子环境流量复制线上请求但返回结果不直接生效离线对比新旧模型输出差异影子环境跑通后放量到5%真实流量观察业务指标如客服解决率、点击率、用户满意度指标正向或持平继续放量到20%、50%、100%反向就直接回滚保留旧模型服务。这个流程走下来业务方对平台的信任感提升了很多。说白了大模型平台要想被业务方接受光把模型训出来是不够的还得有一整套“证明它好”的方法论。6. 踩过的坑与经验沉淀最后分享几个实际踩过的坑这些教训比任何架构设计文档都值钱。6.1 通信库导致的多机训练卡死某次多机训练跑着跑着就hang住日志里没有任何报错进程不退出也不继续。排查了大半天最终定位是通信库的问题不同机器上的NCCL版本不一致导致AllReduce操作在某个节点上永远等不到另一个节点的消息。解决方式是平台在每次训练作业启动前强制校验所有节点的CUDA、NCCL版本和驱动版本一致版本不一致的直接拒绝调度。后来我们把环境镜像化问题彻底根治。6.2 显存碎片的隐形杀手推理服务上线初期我们遇到过服务运行几天后GPU显存被占满的情况。一开始以为是内存泄漏用nvidia-smi逐卡排查发现已分配的缓存块并不大但显存碎片严重总容量被大量“不可用的小碎片”吃掉。这是因为vLLM的PagedAttention虽然高效但在长时间运行、大量不同长度的请求进进出出后页表管理会产生碎片。我们升级到支持--enable-chunked-prefill的版本并定期重启服务后问题得到缓解。线上推理服务要建立定期重启机制我们后来做了“优雅重启流量泳道”的方案每3天自动滚动重启一轮。6.3 关于“从0到1”的一些个人体会做这类平台最大的挑战不是技术而是组织协调。技术选型、环境搭建、脚本封装这些事团队里有经验的人一周就能拉通但要让大家真正用它让业务方信任它是一个漫长的过程。我的体会是平台建设要分阶段交付不要憋大招第一阶段能跑通一个完整的训练推理流程哪怕只支持1个模型、1个业务方第二阶段加上数据管道和评测能力让第二个、第三个业务方接入第三阶段完善弹性伸缩、故障自愈、可观测性提升自动化水平第四阶段开放更多能力比如LoRA低成本微调、模型仓库、Prompt调试工具让业务方能自助服务。每个阶段都有实际业务方在使用才能持续获得反馈和资源投入。这也是我们后来平台能顺利推广到全公司多个业务线的核心经验。最后再分享一个小技巧训练和推理平台的监控面板一定不要分开看。GPU资源是共享池训练作业和推理服务相互影响非常直接。我们上线了统一的资源大盘能一眼看到“当前有多少卡被训练占用、多少卡被推理占用、每张卡的热度如何”这对资源规划和故障排查都有很大帮助。到今天为止这个大盘仍是我每天打开频率最高的页面。