外币兑换说到大模型，近两年大家聊得最多的就是“卡”——买了多少张GPU、训练一个模型要烧多少电、推理一个请求要花多少钱。但真正在一线做过AI基础设施的人都知道，卡买回来只是第一步，怎么把卡用好，才是真正让人头秃的事情。我见过不少团队，GPU总量看着不少，实际利用率不到三成，有的任务排队等到凌晨，有的卡却在“睡大觉”。所以当我看到佳杰云星的“东莞大模型算力调度平台”入选“新质100”企业创新集群标杆案例时，第一反应不是恭喜，而是想说一句：“这事儿，终于有人在认真做了。”
这个平台解决的，恰恰就是算力从“买得到”到“用得好”的核心问题。它不是一个简单的资源管理系统，而是把分散的GPU集群、异构算力、存储网络和大模型训练推理任务串起来的一整套调度体系。不管你是要做大模型微调、本地私有化部署，还是跑多模态推理服务，它都能在合适的时间把合适的算力分给合适的任务。这篇文章我打算从实际落地和技术拆解的角度，聊聊这种算力调度平台到底是怎么设计的，里面有哪些我在实操中踩过的坑，以及它对大模型工程化的真正价值。
1. 项目解读：东莞大模型算力调度平台到底在解决什么
1.1 不是缺算力，是算力“用不动”
先讲一个我在多个客户现场反复见到的场景。某个企业采购了一批GPU服务器，准备做大模型本地部署和微调。硬件到了，驱动装了，框架跑起来了，然后问题就来了：算法团队说训练任务排队太久，运维团队说GPU利用率太低，老板说投入这么大怎么看不到产出。三拨人谁也说不服谁，本质上就是算力资源缺乏统一调度。
打个比方，这就像一个办公楼里有很多会议室，有大有小，有能投屏的有不能投屏的。如果没有一个前台统一登记和分配，就会出现“大会议室被两个人占了开小会，二十个人的项目组挤在小房间里”的荒诞场面。东莞大模型算力调度平台做的就是“会议室前台”的活，但它管的不止是会议室，而是几千张GPU卡、几百台服务器、各种训练任务和推理服务之间的动态匹配。
在建设思路上，这个平台最大的特点是把“算力”当作一种可调度、可计量、可运营的资源来对待，而不是一堆孤立的裸金属服务器。通过容器化和虚拟化技术把物理GPU切分成虚拟算力单元，再根据任务的优先级、资源需求、数据位置等条件动态分配。说白了，就是让每一张卡都尽量在干活，每一分算力都尽量花在刀刃上。
1.2 为什么是东莞，为什么是“新质100”
“新质100”这个评选，关注的是那些在技术创新、产业升级和新质生产力培育方面有标杆意义的企业案例。东莞作为制造业重镇，近年来在数字化转型和智能化升级上的需求非常迫切，大量制造企业开始尝试用大模型做质检、供应链优化、工艺参数推荐等场景。真正跑起来之后，大家发现大模型落地不是简单接个API就行，而是需要一套能够支撑训练、微调、推理、迭代全生命周期的算力底座。
佳杰云星这个案例能入选，我个人理解有几个原因。第一，它不是停留在PPT层面的概念平台，而是把真实业务的算力需求落了地；第二，它兼顾了训练和推理两类完全不同的负载，技术上确实有难度；第三，它的模式对同类企业有很强的可复制性——哪怕你不是东莞的企业，只要你有GPU集群、有大模型应用需求，这套平台的设计思路都是可以直接借鉴的。
从更大的视角看，这标志着大模型行业正在从“卷模型参数”向“卷工程效率”转变。以前大家比拼的是谁家的模型排名更高，现在比拼的更多是谁能用更少的卡、更低成本地跑出同样的效果。算力调度平台，就是这场效率竞赛的基础设施。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 整体设计思路：算力调度平台的架构与核心机制
2.1 技术栈选型：Kubernetes是底座，但不能只靠Kubernetes
我在做这类平台时，底座通常都会选Kubernetes，原因很简单：生态成熟、资源抽象能力强、社区活跃。但真正上手之后你会发现，Kubernetes自带的调度器默认是面向在线业务设计的，对GPU这种特殊资源和分布式训练这类特殊负载的支持非常有限。
佳杰云星在这套平台上做的事情，可以理解成在Kubernetes之上加了一层“懂大模型业务”的调度大脑。原生的Kubernetes调度器能告诉你这个Pod放到哪台机器上，但它不会告诉你：这个训练任务用的是AllReduce还是Parameter Server架构，多卡之间需不需要高速互联，推理服务的显存峰值可能出现在哪个环节，不同租户之间怎么做到互不干扰。这些恰恰是算力调度平台需要解决的核心问题。
所以平台的整体架构大致分为三层。最底层是资源层，负责纳管GPU服务器、存储和网络设备；中间层是调度层，负责资源池化、任务排队、调度策略和动态伸缩；最上层是应用层，面向算法工程师和数据科学家提供训练任务提交、模型仓库、推理服务部署等功能。用户看到的是一个清爽的界面，背后则是调度引擎在毫秒级地做资源分配决策。
2.2 资源池化的三种粒度：整卡、分片和共享
GPU资源的池化方式，直接决定了调度平台的灵活性和利用率。目前主流的有三种粒度，我在实际项目里会根据业务场景混合使用。
整卡分配是最简单也是性能最好的方式，一个任务独占一张物理GPU，不存在资源争抢，适合大型训练任务。这种方式的问题也很明显，如果任务的显存需求只有10GB，而卡是80GB的H100，那剩下70GB基本就浪费了。
分片分配是通过GPU虚拟化技术，把一张物理卡切成多个虚拟卡，每个虚拟卡拥有独立的显存和计算资源份额，适合推理服务和小规模微调任务。这种方式能显著提升资源利用率，但会引入一定的性能损耗，对时延敏感的业务要谨慎使用。
共享分配更加激进，多个任务可以同时使用一张物理卡，通过显存隔离和计算优先级来控制资源使用。这种方式通常配合显存回收和算力超卖策略一起用，适合对性能要求不高、但数量众多的推理请求。实际项目中，这三种方式会通过标签和模板预置到平台里，用户提交任务时按需选择，不需要关心底层实现细节。
2.3 调度策略：为什么不能只用“先来先服务”
很多初做算力平台的人会默认用FIFO（先来先服务）策略处理任务排队，只写，卡被占着也没办法。但在大模型业务场景里，这种策略会让运维团队痛不欲生。
举个例子，A团队提交了一个需要64卡的大模型训练任务，因为资源不够排在队列里。B团队随后提交了一个只需要2卡的模型评测任务，按理说应该很快就能跑起来，但在FIFO策略下，它就只能等着A任务先完成。结果就是2张空闲的卡闲在那里，评测任务等了三小时还没跑上，这是典型的资源利用率和任务响应时间的矛盾。
佳杰云星这个平台的做法是引入多级优先级调度和基于预估等待时间的排队机制。高优任务可以抢占低优任务的资源（通过挂起和恢复的方式），短任务可以“插队”到长任务前面，系统还会根据当前集群负载情况预估每个任务的等待时间，并反馈给用户建议。比如你提交任务时，平台会提示你“如果使用预置的A100集群，预计等待7分钟；如果使用H100集群，预计立即执行但单价更高”，这让用户在业务刚性和成本之间有了自主选择的余地。
3. 核心细节拆解：从任务提交到模型服务的完整路径
3.1 训练任务调度：让多卡训练跑得更稳更高效
大模型训练和传统分布式计算最大的不同，在于它对网络通信的要求极其苛刻。以目前最常见的AllReduce训练模式为例，每迭代一步，所有GPU之间都要做一次梯度同步，通信量动辄上GB。如果调度器把4张卡分到4台物理机上，哪怕走的是InfiniBand网络，通信效率也远不如同一台物理机上的4张卡通过NVLink内部互联。
所以在调度训练任务时，平台需要做拓扑感知。简单说，调度器会优先把同一个训练任务的GPU分配在同一台物理机上，实现卡间NVLink全互联；如果一台机器放不下，再考虑跨机分配，但要尽量让跨机通信的路径最短。这个逻辑听起来不复杂，但在真实的Kubernetes环境里，需要开发自定义的调度插件去读取GPU的拓扑信息，并且和节点选择逻辑联动。
训练任务还有一个容易被忽视但又极其关键的环节是容错恢复。大模型训练经常一跑就是几天甚至几周，网络抖动、硬件故障、驱动异常都可能导致任务中断。如果没有自动恢复机制，训练中断24小时后才发现，浪费的时间和算力都让人肉疼。这一点上，平台普遍的做法是周期性保存模型检查点，同时跟踪任务的Heartbeat状态。一旦检测到任务异常，调度器会尝试在空闲资源上自动拉起一个新的任务实例，并从最近一次检查点恢复训练，而不是从头开始。
3.2 推理服务调度：弹性伸缩和缓存命中率
训练任务对调度器的要求是“算得准”，推理服务的要求则是“扛得住”和“省得下”。
推理服务的流量通常是波动的，白天用户的请求量大，晚上基本没人访问。给每个模型固定分配两张卡跑24小时，既浪费算力，也增加成本。所以平台的调度系统需要支持基于QPS和时延指标的自动伸缩。流量上来时，自动调度新的副本；流量下去后，回收多余副本，把GPU让给其他任务。
这里面有一个细节处理得好不好，直接影响推理成本和响应速度，就是KVCache的管理和复用。大模型生成式推理有一个特点，用户请求中的历史对话内容会被缓存成KVCache，如果下一次请求命中了缓存，就不需要重新计算前面的部分，能大幅减少计算量和时延。优质的调度系统会感知到这一点，在调度推理副本时尽量把同一类请求路由到缓存命中率较高的节点上。说白了，这也是一种“数据局部性”调度策略，跟CPU场景下L1/L2缓存的道理是一样的，只是被搬到了分布式推理的场景里。
3.3 多租户隔离：算力的“小区物业”
算力调度平台在企业和园区里，几乎必然要面对多租户场景。不同部门、不同团队共用一套集群，如何保证他们互不干扰、配额分明、费用清晰，直接决定平台能不能长期运营下去。
首先是最基础的GPU资源和数据隔离。平台一般通过Kubernetes的Namespace和自定义的资源配额体系来实现，每个租户能看到多少卡、能用多少显存，都有明确的额度限制。其次是在算力层面上，不同的训练和推理任务会被调度到不同的物理卡或虚拟卡上，避免出现邻居“吵”到我的情况。我再强调一次，在有多租户环境的场景下，这个隔离一定要做好，否则一个团队的内存泄漏或显存OOM，就可能拖垮同一台物理机上其他团队的任务。
计费体系也是一个隐性但极其重要的环节。平台需要对每个租户的GPU使用时长、显存占用、存储使用量做精细计量，然后按照预设的价格模型生成账单。没有这套计费系统，资源分配就会变成“会哭的孩子有奶吃”，谁吵得凶谁就拿到更多卡，到最后谁都觉得自己吃亏，平台就离散伙不远了。
4. 实操过程与踩坑实录：真刀真枪搭一套算力平台的教训
4.1 GPU显存泄漏：节点“亚健康”的元凶
有一个问题，几乎每个做大模型推理平台的人都会遇到——GPU显存泄漏。刚开始跑推理服务时，服务的显存占用会缓慢增长，一段时间后就把整张卡打满，最后触发OOM，导致该卡上的所有推理请求集体超时。
排查思路是这样的：先用nvidia-smi和dcgm-exporter把显存、GPU利用率等指标拉出来，按时间和Pod维度做聚合，找出泄漏的规律。然后观察是哪个服务在持续分配显存，逐步缩小范围。最后定位到大模型的显存分配器和请求处理逻辑，通常在长连接场景下，历史KVCache没有及时释放，导致显存被一点点蚕食。解决方案是在推理框架层面设置显存上限和自动清理机制，同时在平台运维侧配置显存使用率告警，超过阈值就自动重启对应容器，防止故障扩大。
我特别建议所有做推理平台的朋友，在平台能力建设初期就把细粒度的GPU指标监控做起来，别等到出了问题再补。nvidia-smi dmon这种命令行工具适合排查单机问题，但平台层面的大规模监控，一定要依赖Prometheus加上DCGM这套组合，一次性把指标采集、告警、看板全部打通。
4.2 多卡训练任务被调度到“天南海北”
我们在自建平台上跑一个需要16卡微调的任务，结果任务启动后通信频繁超时，训练速度慢得离谱。排查了半天才发现，调度器压根没感知到“这16张卡应该在尽量近的位置上”。
原因说起来很尴尬，默认调度器是按照“节点剩余资源最多”的策略来分配Pod的，结果同一个训练任务的16张卡被分散到了8台物理机上。每轮迭代都要走跨机通信，性能被网络延迟拖垮。解决方案是在调度器中加入“拓扑亲和”逻辑，优先尝试把训练任务的卡调度到同一台机器，其次是同一个机架的相邻机器，最后才是跨机架。这需要在资源预留层面做好配合，否则调度器有“偏好”但没“预留”，最后还是会退化成跨机分布。
如果你也遇到类似问题，先看一下NCCL的环境变量，特别是NCCL_DEBUG和NCCL_IB_DISABLE，能帮你快速确认走的是RDMA还是TCP。凡是训练性能异常的问题，第一步永远是确认通信链路，99%的性能问题都出在这里。
4.3 国产化GPU适配：兼容性比想象中更磨人
在东莞这类制造业聚集的地区做算力平台，还有一个现实问题：国产化GPU的适配。不少园区和企业会采购国产GPU芯片来做大模型训练和推理，一是供应稳定，二是成本可控。但坦白说，国产GPU在生态成熟度上和主流高端卡还有差距，适配过程中会遇到大量“意料之外”的麻烦。
最大的问题通常是软件生态的碎片化。不同芯片厂商的驱动、运行时、算子库各成体系，有的支持CUDA兼容模式，有的不支持；有的对PyTorch的支持比较完善，有的则只适配了自家的深度学习框架。算力调度平台如果要对这些异构的GPU做统一管理，就必须在底层做一层抽象，把不同芯片的资源量化和健康监测逻辑统一起来，否则调度器连“这个节点还剩多少显存”这种基本信息都没法获取。
我的建议是在平台投入面向国产化GPU的支持时，做好两个准备。一是和芯片厂商共建兼容性测试矩阵，把常见的深度学习框架、模型结构、分布式通信库都过一遍，形成一份明确的兼容性报告；二是在平台层面留好“异构芯片调度”的扩展接口，不要把所有逻辑都写死为某一种芯片的实现。别的行业可以靠“一把梭”走天下，但在这个领域，必须承认中国市场的芯片生态就是多元并存的。
4.4 监控告警缺失：“玄学”失败变成日常
算力平台上线初期，最让人头疼的是任务“莫名其妙”地失败。用户提交一个训练任务，跑了一个小时，avai 突然报错退出，没有任何告警，也没有日志留存。用户来质问，运维团队一头雾水，最后只能让用户重跑一遍。这种事情多来几次，平台的信任度就彻底凉了。
这里面的核心问题是：平台把大量的运行信息散落在各个容器的日志中，没有做统一的采集和关联分析。真正好用的算力平台，必须做到“一次失败，处处留痕”。任务的调度记录、资源分配情况、启动命令、容器日志、GPU指标、退出码，所有这些都要能在一个页面上串联起来查看。用户不再需要去命令行里翻Kubernetes事件，也不需要SSH到某个节点上看dmesg，点一下“历史任务”，所有信息一目了然。
我的建议是平台上线前，先把任务生命周期追踪做扎实。每个任务从提交到结束的每一个状态变化，都要写入审计日志；每个任务对应的所有运行指标和日志，都要按任务ID建立索引。这样无论是用户排查问题，还是平台团队做性能分析，都能像查户口一样查到一个任务的完整“病历”。
5. 大模型工程化浪潮下，算力调度的四个发展趋势
5.1 从“单集群调度”走向“全域协同调度”
现在很多平台的调度范围还局限在一个集群内部。但真正上了规模之后会发现，一个企业往往有多个集群，分布在多个机房，甚至混搭了私有云和公有云的资源。训练任务希望在私有云的闲置资源上跑，突发流量又希望临时调用公有云的GPU，这两个诉求放在一个平台上，就需要“全域调度”能力。
在我看来，这是东莞大模型算力调度平台入选标杆案例后最值得继续演进的方向。它本质上不是个技术问题，而是个信任问题——企业愿不愿意把核心数据放到更大的调度范围里，平台又如何保证数据不出域、合规可控。算力调度的下一站，拼的其实是安全和信任。
5.2 从“资源调度”走向“联合优化”
早期的调度系统只盯资源利用率，后来开始关注任务的完成时间，再往后发现单纯追求这些指标可能会让服务质量变差。所以我看到的新一代调度算法，普遍在把“资源效率”“任务耗时”“服务质量”三个维度放在一起做联合优化。
举个AI领域最常见的例子，同一个集群上跑大模型微调任务和跑在线推理服务，天然存在资源竞争。微调任务越多，推理服务的排队时间就越长，用户体感就越差。调度器不能只满足于把任务分配出去，还得实时调整不同业务的资源水位，既要保证训练任务不被饿死，也要守住推理服务SLA的底线。这套复杂度和自动驾驶有点相似——感知、预测、决策、执行，一个环节都不能断。
5.3 从“手动运维”走向“智能运维”
大模型的训练和推理链路越来越复杂，靠人肉运维盯告警已经完全不现实了。算力平台的下一个能力高地，是用AI的方式来运维AI。比如，通过分析历史监控数据，提前预测哪个节点的GPU可能要故障；通过分析任务日志，自动告诉你这个任务失败的原因大概率是数据加载慢还是模型OOM。
我个人的体会是，智能运维不需要一上来就做得特别重。可以先从异常检测做起，把Kubernetes事件、GPU指标、任务日志这三类数据全部接入，训练一个简单的分类模型，去识别“即将失败的任务”的早期信号。跑通这个闭环之后，再逐步扩展到自动诊断、自动恢复。别一开始就追求“全自动无人值守”，那只是一个美好的愿景。
6. 对AI从业者的三个建议：从“会用算力”到“用好算力”
第一，别低估算力规划的复杂度。以往我们做IT基础设施，先画架构图再买设备基本就完事了。但在大模型时代，算力规划是一个持续迭代的过程。业务模型在变、框架版本在变、GPU型号在变，调度平台必须是一套有生命力的系统，而不是一套上线就不动的“铁疙瘩”。建设之初就要想清楚扩展接口、兼容性边界和可观测性，不然越往后越难改。
第二，真正难的不是技术，而是组织协同。我在不少企业看到过相似的局面：算法团队只管提交任务，运维团队只管资源分配，两边连话都说不上。算力调度平台想跑得好，得有一个能把算法、平台、业务的诉求拉通的角色。这不一定是一个岗位，但一定是一个意识——技术是为业务服务的，调度策略最终要平衡的是业务收益和算力成本。
第三，多关注开源生态和社区的最新进展。现在大模型技术迭代飞快，新的推理引擎、新的调度框架、新的显存优化方法层出不穷。与其闭门造车去重新发明轮子，不如先看看社区里有没有成熟的方案。我一直在关注的就是两个方向，一个是推理引擎层面的优化，比如vLLM的缓存机制如何更智能地配合调度器；另一个是GPU池化方向，如何让显存这种硬资源真正实现“按需分配、随时回收”。
回到佳杰云星这个入选的案例本身。它最大的价值，不是给行业提供了一个“模范生”的答案，而是证明了一个朴素的道理：算力调度平台不是什么高不可攀的实验室产物，它是可以被真实落地、被业务验证、被规模化复用的工程系统。从东莞出发，未来一定会有更多城市、更多园区、更多企业，把这套思路用在自己的算力底座上。
最后分享一个我自己的小经验：选型采购GPU之前，先想清楚你未来三个月的任务画像——训练多还是推理多？任务大小差距悬殊吗？业务峰值出现在什么时段？这些问题不需要很精确，但能让你在搭建算力平台时少走很多弯路。算力调度这件事，最怕的不是技术复杂，而是你根本不知道自己的业务要什么。把这些想明白了，再回头去看那些花里胡哨的调度算法和平台架构，你会觉得，事情一下子清爽了很多。