现在把大模型训练和推理真正跑进生产环境的人应该都有一种很直观的感受数据的活好干算力的活难干。AllData 这类数据中台把元数据、数据同步、数据质量、数据服务都管得井井有条但到了 GPU/CPU/内存/磁盘这些异构算力资源这一层绝大多数团队还在靠问一圈、盯一下、抢一抢的方式过日子。我做了一次集成尝试在 AllData 数据中台里接入了开源项目 Crater目的就一个把训练和推理场景下的算力资源当作一套统一资产来调度少做点人肉运维多留点时间做正事。这篇文章不打算讲太多概念重点是把为什么这样设计、实际怎么集成、踩了哪些坑、最后效果如何讲透。适合正在做 AI 平台建设、或者准备在数据中台里接入算力管理能力的团队参考。1. 数据中台与算力平台之间的那堵墙为什么AllData需要Crater先说背景。AllData 本身是一套开源的一站式数据中台覆盖数据集成、数据开发、数据治理、数据服务这些能力。我们内部用了一段时间之后发现一个很尴尬的断层数据链路已经自动化了但模型训练和推理依赖的算力资源仍然是纯手工管理。数据开发在中台上提数、调度、监控都顺滑算法工程师却在另一个世界里抢机器、抢显存、抢磁盘空间。1.1 数据侧很成熟算力侧却在各玩各的最典型的状态就是数据开发用中台界面跑数算法工程师用 SSH 登到 GPU 服务器上敲命令两边各有一套信息体系。中台上能看到数据血缘、任务依赖、质量报告却看不到任何一台 GPU 服务器的实时状态算力侧只有少数几个消息灵通的同事知道哪台机器还剩多少显存、哪个节点磁盘又要满了。资源信息完全靠口口相传分配情况没有任何记录更谈不上审计和复盘。这种割裂带来的问题在故障时尤其明显。比如某个推理服务突然 F 了第一反应不是看调度日志而是到处问谁在用那台卡。人找人、找机器、找责任人十分钟能定位的问题可能要折腾半小时。数据中台本身有非常成熟的元数据管理思路完全可以借用同一套方法论去管理算力资源只是缺少一个能纳管异构设备的执行层。crater 的定位正好补齐这一层。它负责把分散在不同物理节点上的 GPU、CPU、内存、磁盘统一上报、统一分配、统一回收让资源信息像数据资产一样看得见、管得住。上层业务不需要知道具体跑在哪台机器上只要提交资源申请由调度器负责安排。这也符合数据中台一贯的抽象思路底层细节屏蔽掉把能力以服务的方式暴露出来。1.2 训练用一台、推理用一台的资源割裂浪费在没有统一调度之前很多团队为了防止训练任务影响线上推理会选择物理隔离训练任务用一组机器推理服务用另一组机器。这种做法看起来安全实际上资源利用率非常糟糕。训练任务的特点是重负载、长时间、夜间为主白天大部分时候模型在等待数据、等待调参推理服务则相反白天的业务高峰才是它的主战场夜间请求量大幅下降。两边各占一摊就意味着夜晚训练靠那组机器硬扛白天空闲也没法借给推理白天推理那组机器高负荷夜间又全部闲着。资源池被人为切成了两半任何一侧出现瞬时的流量高峰另一侧的闲置资源也帮不上忙。更别说不同团队的 GPU 型号还不同有的机器显存大、有的机器 CPU 强没有统一调度时很难按需匹配。我称这个问题为算力孤岛。AllData 已经把数据资产统一了起来算力资产没有理由继续隔离。Crater 的引入彻底改变了这个局面训练和推理任务提交到同一个资源池由调度器根据任务类型、优先级、资源需求动态分配。高峰期可以把资源倾斜给推理低峰期再把卡让给训练跑 batch 任务一套池子两套场景这才是我理解的训推一体化。2. Crater为异构算力管理带来了什么一套资源底座Crater 不是一个单一模块而是一套完整的异构算力资源管理框架。它做的事情可以从两个层面理解一个是资源抽象层解决有多少资源、怎么描述资源的问题另一个是调度执行层解决任务来了放哪里、怎么放最合理的问题。这两层配合起来平台才有能力对上提供算力服务。2.1 异构资源统一抽象Crater 在每个物理节点上部署一个轻量代理代理负责采集节点上的 GPU 型号、显存总量与已用量、GPU 利用率、CPU 核数、内存容量、磁盘容量和 IO 指标然后统一上报给中心调度服务。所有节点的资源信息经过标准化之后形成一套统一的资源描述符。上层应用看到的不是一张机器清单而是一个可动态分割的算力资源池你只需要声明我要多少 G 显存、多少个 CPU 核、多少内存调度器会从池子里挑出最合适的分片。这个抽象思路非常重要。举一个不一定很恰当但很好理解的例子以前申请机器就像租一套整租的房子不管一个人住还是五个人住整套都归你Crater 的资源抽象则把这套房拆成房间、工位、公共区域按实际占用分配。对数据中台侧来说资源不再绑定到某一台物理机而是变成一种可以动态发放和回收的配额。这也让后续做多租户管理、成本核算、任务隔离有了唯一的数据来源。2.2 GPU/CPU/内存/磁盘的细粒度调度早期很多内部平台调度粒度很粗要么按整卡分配要么按整机分配。大模型场景下这种粗粒度非常浪费尤其是推理场景一个 7B 参数的模型量化之后可能只需要十几 G 显存按整卡分就白白浪费了剩余部分。Crater 支持细粒度的多维资源匹配显存可以按 GB 申请CPU 按核数申请内存和磁盘按容量申请调度器在多维约束下做组合匹配。实际的调度匹配逻辑不复杂核心是这么几步任务提交时会带一份资源需求描述包括显存大小、CPU 核数、内存、磁盘、是否必须使用某种 GPU 型号、是否独占节点等等调度器先筛选出所有满足硬性条件的节点再通过打分函数给每个候选节点排序打分时会考虑节点剩余资源的碎片程度、是否已经有同样的模型权重缓存、当前节点的负载热点、网络拓扑位置等因素最终选出得分最高的放置方案。我对比过两种落地方式一种是所有 GPU 机器都纳入自建的资源调度系统另一种是用 Kubernetes 做底层编排上层再封装一层调度。最终选了基于类似 Crater 思路独立出来的调度服务原因是它把配额、调度、资源上报、分配记录都做完整了团队不需要从零维护一套复杂的调度器只需要把业务层和它对接起来即可。这个决策在后续开发中确实省了大量工时因为我们没有陷入调度算法本身的深坑而是把精力花在了业务适配和数据打通上。3. 在AllData中落地Crater我实际完成的集成路径接入这件事听起来简单实际做起来要拆成好几步。我按项目推进的时间线把关键环节和决策点交代一下。3.1 从资源接入到统一门户第一步是把所有可用的异构算力节点纳入 Crater 的纳管范围。这一步没有太多技术难度主要工作是给每台机器安装代理组件、配置上报地址、确认采集指标能够被中心服务识别。真正花时间的反而是资源信息梳理团队里很多 GPU 服务器是过去半年陆续采购的型号杂、驱动版本不同、显存大小参差不齐。如果这些信息不整理清楚后续调度非常容易因为资源标签不完整导致任务无法匹配。资源接入之后我在 AllData 数据中台的服务层封装了一个算力资源门户。这个门户做了三件事一是展示全集群的资源总量和实时使用率GPU/CPU/内存/磁盘分维度看二是提供资源申请入口使用者提交规格需求系统自动生成工单并提交给调度器三是展示历史分配记录和任务资源拓扑方便追溯这个任务到底用了哪些资源。这套门户的价值不在于多炫而在于所有操作都有记录不再是口头化的借一下卡。实际开发时门户和后端服务的交互协议上我做了两个决定。第一任务规格使用统一的资源描述 JSON结构类似{ task_id: train_20240716_001, task_type: training, priority: high, resources: { gpu: {count: 4, memory_gb: 80, model: A100}, cpu: {cores: 32}, memory: {size_gb: 256}, disk: {size_gb: 200} }, duration: 01:00:00, image: registry.internal/deeplearning/pytorch:2.1-cu12.1 }字段含义很直白tack_type 用来区分训练还是推理priority 决定是否参与排队和抢占resources 声明硬性需求。第二个决定是调度器只认这套声明式描述不关心任务的具体内容。这让 Crater 侧保持完全通用后续扩展任何新框架都不需要改动调度逻辑。3.2 调度器的核心工作流程调度器的工作流程是典型的校验-匹配-绑定-发放四步。任务提交后先做配额校验检查这个租户当前已分配的资源加上本次申请是否超出配额上限如果超了就直接排队并给出预计可调度时间。配额校验通过后进入节点匹配这个过程会读取所有在线节点的最新状态筛选出满足资源条件且标签匹配的节点列表。节点筛选完成以后调度器按打分策略对候选节点排序。我这边打分的权重主要看三点节点剩余资源与申请资源的拟合度拟合度越高分越高避免大材小用节点是否已有相同模型权重缓存有缓存的任务优先调度过去能省掉大量加载时间节点的实时负载避开 CPU 已经跑满或磁盘 IO 接近瓶颈的机器。最终得分最高的节点被选中调度器生成一条资源分配记录并通知节点代理执行环境准备。环境准备这一步很多人会忽略但实际很容易出问题。节点代理需要在分配好的资源分片上完成环境隔离比如用容器或虚拟化方式把 GPU 显存、CPU 核、内存隔离出来同时挂载训练数据和模型权重目录。我最初踩的坑就是环境准备没有做超时控制模型镜像下载慢的时候任务一直处于准备中状态调度器无法区分是正常下载还是卡死。后来在分配记录里加了一个状态机把Preparing、Ready、Running、Finished、Failed几个状态在数据库里全部落地配合超时阈值才算真正搞清楚每个任务卡在哪个环节。3.3 适配层与接口设计集成过程中我花时间最多的地方其实是 AllData 数据中台与 Crater 之间的适配层。当时有两个方案可以选择一个是在中台里直接调用 Crater 的调度接口逻辑上最直接但中台业务代码会和调度器强耦合另一个是在中间加一个适配层中台只依赖适配层提供的接口由适配层负责翻译和转换。我选了后者。理由很简单数据中台的迭代频率远高于算力调度平台如果两边直接耦合任何一方的接口变更都可能引发连锁故障。适配层做成独立服务之后中台侧只需要关心任务提交和状态查询其他事情全部由适配层兜住。适配层的主要接口我设计成五个资源申请、资源释放、任务状态查询、资源使用率查询、配额变更。所有接口返回统一格式业务侧不用感知调度器的内部状态流转。实际运行下来这个设计的好处很快体现出来。有一次 Crater 升级调度接口我们只需要在适配层做兼容AllData 本身的业务代码一行没动。如果当时直接硬编码调用估计又要经历一次半夜紧急修复。4. 训推一体化的关键机制一套池子两套场景训推一体化这个词很多文章都在提但落到实际平台里核心问题无非是两个训练任务和推理服务怎么共享同一套资源而不互相干扰模型版本更新时算力资源怎么平滑切换4.1 训练任务与推理服务的调度冲突与解耦共享资源池必然遇到一个矛盾训练任务对资源的需求是大而稳定推理服务对资源的需求是小而频繁。如果一视同仁地调度训练任务很可能长时间占住大量 GPU推理服务只能在一旁饿肚子。Crater 的解决思路不是物理隔离而是通过优先级和可抢占机制来协调。实际配置里我把推理服务设为高优先级、低超卖倍率保障在线请求不受影响训练任务设置为中低优先级允许在资源不足时排队。同时训练任务本身做了 checkpoint 机制每次调度重新开始时可以从最近一个检查点继续而不是从头跑。这样即便训练任务被推理高峰期挤掉代价也只是回退几十分钟而不是浪费一整天的训练进度。除了优先级我还限制了推理服务的单任务资源上限。比如一个在线推理服务最多申请一张卡的一半显存一旦超过这个阈值就必须横向扩容而不是纵向加资源。这样设计是为了避免某个推理服务异常时把整个节点的显存吃满拖垮同节点的其他任务。细粒度配额优先级抢占这两条规则加在一起才真正实现了池子共用、场景解耦。4.2 模型版本切换与资源热迁移集成前我们上线新模型版本的方式比较原始新模型起一套新服务流量切过来之后老服务再删。这个流程在主机数量少的时候还能忍受模型多了以后非常浪费。训练 side 每两天出一个更好精度的版本每次都要重新申请资源、拉起服务、切流量、释放旧资源一套流程走下来至少半小时期间还容易出错。接入 Crater 之后模型版本切换变得非常轻量。新版本模型的权重文件先同步到共享存储调度器只需要在已分配的资源分片上更新容器镜像和权重加载路径业务服务通过内部探针感知到新版本就绪后自动做平滑切换。整个过程不需要额外申请新资源也不需要释放旧资源资源和模型之间彻底解耦。这套机制在推理服务频繁更新的场景下尤其好用。配合共享存储上的多版本权重管理我们可以实现一天发布五个版本而资源零额外消耗。发布动作变成了更新资源分片上的模型版本标签重启推理进程而不是重新分配一台新机器。这个体验上的差异日常维护过推理集群的工程师一定懂。5. 实操中的难点排查与避坑经验集成过程中踩了不少坑挑三个最有代表性的写出来给后来者省点时间。5.1 显存分配不均匀导致的利用率黑洞刚上线时遇到一个非常反直觉的现象集群显存总量看起来还有富余但新任务一直调度不上去。排查发现问题出在显存碎片。早期版本的调度策略是优先填满节点——第一个任务申请 40G第二个任务申请 40G第三个任务申请 10G看起来每台机器都分配得很满但剩余的都是碎片化的小段显存无法满足一个需要大显存的新任务。定位问题的过程很有意思。一开始我盯着调度器日志看没发现任何异常所有节点状态都正常任务就是匹配不到合适节点。后来把每个节点的剩余显存分布拉出来看才发现大量剩余 2G、4G这类零头。这个坑教会我一件事调度不能只看总量一定要看连续可用量。后来我在打分策略里加入了一个碎片惩罚因子优先把新任务调度到剩余显存最连续、与申请值最匹配的节点这个现象才基本消失。5.2 大数据量模型的磁盘带宽瓶颈第二个坑更隐蔽。某个推理任务在调度完成后从节点进入到模型可响应之间花了将近十分钟远超预期。刚开始以为是网络传输慢排查网络后发现带宽根本没打满。后来查到节点代理的日志发现时间全部耗在从共享存储读取模型权重文件上。现在很多大模型的权重文件动辄几十 GB多个节点同时加载同一个模型时共享存储的带宽会成为瓶颈。如果调度器不加干预模型更新后所有节点一窝蜂地去拉新权重磁盘 IO 直接被打满任务互相拖慢。我的解决办法是两层第一在共享存储前加一层本地磁盘缓存节点首次加载后将权重文件缓存到本地第二调度器对同模型、同时间点的加载请求做错峰处理在任务状态机里增加一个依赖资源预热阶段模型文件在后台预热完成后再正式拉起推理进程。5.3 多租户配额与资源抢占的边界第三个问题是多租户场景下最常见的——有人申请了资源却不用。某个团队为了确保训练任务能随时跑一次性申请了大量 GPU 配额并长期持有但实际使用率不到三成。其他团队的任务因为配额不足只能排队资源就这么白白浪费了。这个问题的本质是配额管理和实际使用率脱节。Crater 的调度器负责分配的合理性但分配了到底用没用需要平台侧自己监测。我在 AllData 中台做了个定时巡检任务定期比对每个租户的已分配资源和实际使用率超过一定阈值就自动回收空闲资源同时发通知给资源持有者。另外还设计了一个空闲资源临时借用机制任务可以在配额不足时借用空闲资源池但被借用资源一旦有更高优先级任务申请立即释放。这套机制上线后集群整体利用率提高了大概三成而且没有引发任何跨团队冲突。关键在于规则要提前透明化所有租户在同一个使用规范下申请、使用、释放资源遇到抢占时有明确的优先级界定而不是等冲突发生了再互相扯皮。6. 我的经验与几个可复用的小技巧接入 Crater 这几个月我最大的体会是算力调度平台不是做不出来而是很多团队低估了资源管理这件事本身的工作量。GPU 纳管、调度算法、配额控制都只是底座真正让平台跑起来、让业务愿意用的是那些细节资源信息可视、分配记录可查、配额规则透明、失败状态可追踪。如果你也在做类似的集成有几个小技巧可以直接拿去用。第一调度器落实声明式资源描述任务只告诉平台要什么不告诉平台怎么跑这会让上层业务保持最大的灵活性。第二资源分配记录一定要落库哪怕只是一个简单的任务资源映射表排查故障时能节省大量时间。第三模型权重缓存和存储带宽规划要提前做不要等到几十 G 的权重并发加载时才想起来。第四多租户配额一定要配上使用率巡检否则资源会被占而不用的团队囤积迟早引发矛盾。我个人的习惯是每两周复盘一次资源利用率曲线把高峰、低峰和调度器决策记录对照着看。很多问题在曲线上早就有苗头只是当时没注意。这套 AllData Crater 的架构上线之后我这边接到的问题从谁能帮我看看机器变成了这个任务怎么调度更合理方向对了。后续还可以做的是把算力资源成本分账数据也接入中台让每个团队能看到自己用了多少算力、产生了多少成本这一步走完平台的闭环就真正完整了。
