这两年做企业AI落地模型托管这个词大家已经不陌生了。把模型丢到平台上、通过API调用看起来什么都搞定了。但真正做过生产环境的人都知道平台背后那一层算力调度才是决定成本、延迟和稳定性的命门——尤其是当你手里的卡混着不同品牌、不同型号性能天差地别的时候能不能把这堆“五花八门”的算力有效组织起来直接决定业务能不能跑得动。OpenCSG和密瓜智能这次的战略合作恰好切在这个点上从“模型托管”升级到“算力原生”共建企业级异构算力调度底座。我看了这个消息之后第一时间想到的是这些年我在异构调度项目里踩过的坑和总结出来的经验正好借这个机会梳理一遍给正在做类似架构选型或者准备改造算力平台的团队一个参考。这篇文章不会只停留在新闻层面讲合作本身而是会重点拆解几个实际问题模型托管和算力原生到底差在哪、异构算力调度底座的核心模块是什么、落地的关键步骤有哪些、以及在真实环境中最容易踩的坑。如果你是搞AI基础设施的工程师、技术负责人或者正在为团队的GPU利用率发愁这篇文章应该能给你一些可以直接拿走的思路。1. 从模型托管到算力原生这次合作到底在解决什么问题1.1 模型托管的旧模式模型住进“酒店”算力只是“公共客厅”传统模型托管平台的核心逻辑本质上是一个“模型即服务”的封装平台负责把模型部署成API、做鉴权计费、简单做个负载均衡。听起来很方便但问题是底层算力管理往往非常粗糙。很多平台的做法是每个模型固定绑定一组实例或者把所有GPU放在一个大池子里按请求量做粗暴分配。这种模式的问题在业务稍微复杂一点之后就全暴露了。我见过不少团队的GPU集群名义上几十张卡从监控面板上看利用率长期只有20%到30%。原因就是静态绑定A模型流量高峰时实例打满B模型长期闲置但你不能把B模型的那张卡临时拆给A用。更麻烦的是大模型和小模型的显存需求天差地别静态实例里经常出现“这张卡还剩20GB放不下一个新模型、放三个又不够”的尴尬局面。所以模型托管做了这么多年大家慢慢意识到一件事模型托管本身不是核心问题核心问题是托管的底座能不能把算力像水龙头一样按需分配。你托管的模型再多、功能再全如果底层的GPU利用率上不去、响应延迟稳不住那这套平台就只能算个演示系统。1.2 算力原生的三个关键词协同、感知、编排这次合作里提到“算力原生”这个词乍一听有点唬人但拆开来看并不复杂。它借鉴的是“云原生”的思路——云原生应用从设计第一天就考虑容器、微服务和弹性伸缩而不是事后硬塞进去。算力原生就是模型从发布那一刻起就和算力资源深度绑定调度系统从一开始就知道每个模型要什么卡、要多少显存、适合什么并行策略。具体来说有三个关键词。第一是协同模型调度不再只看“哪台机器有空闲”而是要看模型的架构特性、卡的拓扑关系、显存碎片情况、甚至数据加载位置。第二是感知调度器能实时感知每个节点的算力状态包括GPU利用率、显存余量、卡间通信带宽而不是靠静态资源清单拍脑袋。第三是编排模型的部署、扩缩容、版本切换、切流都能通过统一的编排层完成不需要人工介入改配置。说的直接一点模型托管是“住酒店”你在前台办个入住就行但房间不能改、面积不能换、朝向不能挑算力原生是“精装公寓的智能家居系统”空调、灯光、窗帘全部联动你坐在那说出需求系统自己就把环境调好了。这次合作要做的显然不是多接几个模型而是把整个“智能家居系统”的底座建起来。1.3 为什么必须异构不是“图新鲜”是被现实逼的很多没做过生产环境的人会问为什么不统一用同一型号的GPU这样调度不就简单了吗答案是现实不允许。企业的GPU采购周期长、批次杂今天买到A100明天可能是H20后天因为项目紧急又买了一批国产加速卡甚至研发团队自己手里还攥着几块4090在跑实验。几年的时间下来一个稍微有点规模的团队手里的硬件就一定是五花八门的。异构带来的挑战是系统性的。不同型号的单卡算力可能差好几倍显存大小不一样分配粒度也不同卡间通信有的走NVLink有的走PCIe有的用厂商自研互联协议更别提软件栈的差异CUDA生态之外的卡在算子兼容、通信库、量化支持上各自为政。调度系统如果对这些差异一无所知那就只能把异构资源当作统一资源来用结果就是“一卡有难全体围观”——某个慢速卡可能把整个推理链路拖成这样那样的性能瓶颈。所以这次合作强调“异构算力调度底座”本质上是顺着企业的真实硬件环境在做文章。不是去假设一个理想化的同构集群而是把“混着用”这件事变成一种能被妥善管理的能力。从模型托管时代的“平台帮我管模型”进化到算力原生时代的“平台帮我管好每一张卡”。这一步跳过去企业的AI基础设施才真正算得上完备。2. 异构算力调度的核心链路从一次请求到一张卡片的完整旅程2.1 一次推理请求的完整路径理解异构算力调度最直观的方式是跟着一次推理请求看它在系统里走完一条完整的路。我把这条路径拆成六个环节每一个环节出问题都会让用户体验到“变慢”或者“报错”。第一步API网关收到请求先做鉴权和租户识别确认这是谁在调用、调用的什么模型。第二步模型路由模块介入它要根据请求内容判断应该命中哪个模型的哪个版本这里还可能涉及多模型之间的流量切换和A/B测试逻辑。第三步调度器开始工作它需要查询当前所有候选节点的资源状态包括有哪些空闲卡、显存够不够、卡间的通信拓扑如何然后做一次决策。第四步决策完成之后把请求分发到选定的推理实例上同时下发必要的资源配置。第五步推理实例真正开始执行。第六步结果返回给网关同时写入日志、指标和计费数据。在传统的模型托管平台里第一、二、六步是齐的但中间那三步往往很简单——要么随机选节点要么轮询要么干脆绑死。在异构调度底座里中间三步才是真正见功力的地方。调度的决策质量直接决定这次请求是10毫秒返回还是200毫秒超时决定这张卡是跑在60%利用率还是90%利用率。2.2 调度底座里的四个关键模块做异构算力调度本质上是在搭建一套属于AI场景的“操作系统”。我从实际项目经验出发认为底座里至少有四个模块是绕不开的。第一个是资源注册与拓扑感知模块。每个GPU节点启动时向调度器注册自己的硬件信息GPU型号、显存大小、卡间互联类型、所在物理机的位置。调度器通过这些信息构建一张“算力拓扑图”知道哪张卡在哪个节点、和哪张卡相邻、通信代价是多少。这一步是异构调度的地基如果拓扑信息不准后面所有调度策略都是空中楼阁。第二个是模型路由与版本管理模块。CRUD模型和用户之间不是简单一对一关系。同一个模型可能同时在跑两三个版本有做灰度验证的有服务正式业务的。路由模块要维护模型版本与后端实例的映射关系并且支持按权重、按用户、按标签做流量切分。这块做不好发布新模型就跟“盲飞”差不多出了问题连回滚都不知道回滚到哪。第三个是资源切分与隔离模块。它负责把一张物理GPU“切”成适合多个模型共享的样子。常见的技术手段包括显存隔离、时间片切分、MIG、MPS等。每种方案都有代价。比如时间片切分适合吞吐型任务但对时延不友好MIG隔离性好但切分粒度固定MPS能提高利用率但可能出现排队。调度器要能根据模型特性选择最合适的切分方式。切分方案隔离强度粒度适用场景主要局限显存隔离中可按需分配显存多模型共享GPU算力争抢无法完全避免时间片切分低固定/动态时间片吞吐型批处理任务对在线推理延迟不稳定MIG高固定切分规格对隔离要求高的生产环境切分粒度选择少MPS中并发上下文小模型混合部署排队等待不可控第四个是可观测性模块。你调度器做得再好如果没有指标系统支撑出了问题连原因都找不到。这个模块要记录每次调度的决策依据、节点状态变化、推理延迟分布、GPU利用率曲线。做得好的团队还会在网关层打全链路trace id一次请求从进来到返回每一步耗了多少时间都能回溯。这四个模块的关系可以这样理解拓扑感知是“地图”模型路由是“导航”资源切分是“车道划分”可观测性是“行车记录仪”。缺了任何一个这套底座都跑不长久。2.3 调度策略选型经验不能只盯一个目标调度策略是整个底座里最考验经验的部分。常见的策略无非这么几种最少负载优先、亲和性优先、成本优先、SLA优先。但实际生产环境里单一策略几乎没有能直接用的。最少负载优先看起来公平但它不考虑卡型差异和显存碎片可能把一个需要40GB显存的模型调度到一张只有32GB空闲的A100上虽然那张A100负载最低。成本优先策略会把任务尽量往便宜的卡上塞但如果在线推理请求突然上来热点卡会先被打爆。SLA优先策略倒是保住了延迟但往往会让一大批非关键任务长期饿死整体资源利用率拉胯。我比较推崇的做法是“两级调度”。第一级在资源池之间调度把异构资源先分成几个逻辑池比如“高性能在线池”“低成本批处理池”“国产加速卡池”。第二级在池内的实例之间调度再做亲和性、碎片、负载的微调。这样做的优势是策略可以被分层定义——池级策略关注业务优先级和成本实例级策略关注延迟和利用率两层互相解耦。之前我们做过一个项目把在线推理和离线批处理任务分开到两个池子在线池用最少负载优先SLA保护离线池用成本优先可抢占。原本经常出现的“离线任务把在线延迟拖垮”现象马上就消失了整个集群的利用率也从33%提到了60%左右。调度策略没有银弹分层治理是目前来说最省心也最可维护的方案。3. 企业落地的关键技术点能直接拿走的实施经验3.1 模型迁移从“影子模式”到“回收资源”三步走从模型托管平台迁移到算力原生底座最容易犯的错误就是“大爆炸式切换”一天之内把所有模型全部迁过去出了一堆问题然后整个团队焦头烂额。我建议按三步走每一步都有明确的可验证目标。第一步是影子模式。新底座和旧平台并行运行生产流量仍然走旧平台但把真实请求同时复制一份打到新底座上。对比两侧的推理结果和延迟确认一致性。这一步的核心产出是一份“回归报告”要覆盖所有模型的所有典型输入类型尤其是那种输入文本特别长、特别容易触发分词的边界case。模型文件的一致性经常在这里暴露问题比如tokenizer版本不一致导致分词结果不同或者预处理逻辑有肉眼看不见的偏差。第二步是灰度切换。流量按5%、20%、50%的比例逐步切到新底座。每跑一周左右看一次稳定性数据主要看P99延迟有没有恶化、有没有新增的错误码、调度器有没有出现资源不足的误判。这个阶段的关键是要给新底座“预热”的机会不能刚切完流量就指望所有模型都达到最佳性能。第三步是回收资源。确认新底座稳定之后把旧平台的固定实例缩容把释放出来的GPU资源纳入新的算力池。很多人会忽略这一步导致新旧两套资源同时跑着成本翻倍。在实操中我建议在切换完成后的两周内务必完成资源回收否则财务看到账单会非常头疼。3.2 算力池化管理把异构资源当成一个“算力银行”异构调度的核心抽象是把物理GPU资源虚拟成一个可伸缩的“算力银行”。每个项目组在系统里开一个账户账户里有配额比如“最多占用200个算力单元”。模型部署时申请算力调度器从池子里划拨用完之后释放。这种抽象让资源管理变得像财务管理一样清晰。但这里有一个很容易被忽视的点算力单元怎么定义。你不能简单地把“一张卡”当作一个单元因为A100和国产加速卡的算力天差地别。常见的做法是选一个基准型号作为1.0其他型号按实测性能折算成系数。比如把A100定成1.0某款性能约为其七成的卡折算成0.7。这个系数不能拍脑袋要通过在真实模型上跑benchmark来定而且每半年要复测一次因为驱动和软件栈更新之后性能系数可能会变。池化管理带来的另一个好处是配额控制可以落到组织维度。以前是“谁申请到卡就是谁的”现在是“每个团队有自己的算力额度超额了需要申请”。这能有效避免“囤卡不用”的资源浪费。我见过有的团队一口气占了20张卡实际利用率只有10%但别人想用又不敢动。配额机制能倒逼团队去优化自己的推理效率而不是无脑占资源。3.3 控制面与数据面分离调度器挂了推理不能跟着挂这是一个老生常谈但特别容易被忽略的架构原则。调度器属于控制面推理实例属于数据面两者必须解耦。最直接的原因是控制面一旦出问题不应该影响到已经在跑的推理服务。如果调度器和推理进程耦合在一起调度器过载或panic所有在线推理请求都会被波及那就等于一个管理工具的故障拖垮了整个业务。实现方式上调度的决策结果应该以“期望状态”的方式下发到工作节点节点上运行的agent负责维持这个状态。控制面和数据面之间通过心跳来同步状态控制面短暂不可用的时候数据面仍然按照最后一次下发的配置继续运行。这一点和Kubernetes的控制器模式非常像复用成熟思路总比自己重新造轮子稳妥。另外要注意的是控制面本身要做高可用部署至少三个副本数据要持久化。调度决策记录、资源状态、模型路由表这些元数据如果丢了恢复起来会非常痛苦。我们在实际项目中就吃过这个亏控制面单点部署一次机房断电之后所有模型路由信息全没了花了整整半天手动恢复配置。3.4 与现有K8s体系的融合别推倒重来大部分企业已经有Kubernetes集群很多AI服务也已经是容器化部署。异构算力调度底座不需要做成一个完全独立的系统更合理的做法是把它做成K8s体系的扩展能力。具体来说底层依然用K8s管节点和Pod生命周期但在设备插件层做扩展让K8s能感知GPU的型号、显存、切分状态。在此基础上把模型路由、调度策略、算力配额这些AI特有的逻辑做成自定义资源。这样做的最大好处是企业已有的CI/CD流程、监控告警、日志采集体系基本可以复用团队不需要学一套全新的平台。但要注意一个技术细节K8s默认调度器对GPU做的是整卡调度它不知道一个模型需要多少显存、适合什么并行方式。所以必须在device plugin层做“眼睛”把物理GPU上报成可切分的虚拟资源才能让调度器看到“这张卡还剩32GB可用”这样的信息。这一层是最容易出bug的地方也是异构调度底座和通用K8s平台拉开差距的关键位置。4. 实操避坑指南我在异构调度项目里踩过的坑4.1 显存碎片模型多、卡少时最容易被忽视的问题显存碎片是异构调度里最容易遇到、也最难排查的问题。现象很典型集群里每张卡都显示“还有空闲显存”但新模型就是部署不上去。原因在于模型占用的显存大小各不相同A模型占32GBB模型占24GB能放下三个B模型的节点可能只够放两个剩下的空间变成碎片。碎片问题不能靠人工盯必须让调度器感知碎片率。我建议在资源指标里加一个“碎片度量”公式大概是可以分配的连续显存块总数除以理论可用显存。当碎片率超过一定阈值调度器要主动做“整理”把某些模型迁移到其他节点把碎片空间合并。这听起来很重但对利用率提升的帮助非常明显。在调度算法层面也要尽量避免“低效装箱”。比如优先放置显存需求相近的模型避免一个大模型把一张卡的剩余空间卡死。这个思路和操作系统的内存分配是相似的但AI场景下模型不能随意迁移所以装箱策略要更谨慎。实际操作中我们一般会做“预检查”在新模型发布前模拟一次调度决策看它会不会在集群里造成高碎片率如果会就手动调整放置位置。4.2 冷启动与预热别让用户替你的懒买单模型首次加载是异构调度里一个非常容易被低估的性能杀手。一个十几GB的模型从磁盘读权重到初始化完成耗时可能从几十秒到几分钟不等。如果用户一个冷门模型第一次调用就赶上了冷启动那体验直接崩了。更麻烦的是冷启动不只是慢它还会占用调度资源导致其他正常请求也被拖累。解决思路是分“热”和“冷”两条路径。热的模型可以配置常驻实例保证最低数量的副本一直在跑。冷的模型允许冷启动但要提前把权重文件预热到节点本地避免从对象存储远程拉取。另外调度器可以根据历史调用记录做预加载top10的模型贡献了95%的流量把它们全部做成常驻剩余的长尾模型按热度动态决策。还有一个经验是版本更新时不要整体重建实例尽量做“热加载”。让老版本实例继续服务新版本实例在后台加载完毕后再切换流量。这个和滚动更新的逻辑是对齐的但是在模型场景下容易被人忽略。我们最早做的时候直接重建导致每次发版都有几十秒的请求失败后来改成后台预加载再切流那部分错误率就归零了。4.3 混部场景下的算力抢占大模型拖垮小模型异构集群里大模型和小模型混跑在同一批卡上是常态。大模型推理通常持续打满算力小模型反而可能有空闲期。如果没有优先级控制一次大模型的批量请求就能把所有GPU算力吃光小模型的在线延迟瞬间飙到几秒。我在实践中学到的一个可靠做法是给延迟敏感的模型预留“算力保险”。比如集群总量100张卡先划出20%作为SLA保障池只允许低延迟模型使用剩下的80%才让所有模型自由竞争。自由竞争的池子里再做优先级调度低优先级任务可以被抢占但高优先级任务不允许被低优先级拖累。这套机制在操作系统领域已经相当成熟直接迁移到GPU调度场景也说得通。混部环境下还要特别注意故障隔离。有可能出现的情况是一个模型的显存泄漏慢慢吃光整张卡的显存导致同卡上的其他模型全部oom。所以在资源切分模块里显存隔离不能只是“软限制”必须要有“硬隔离”的手段。能上MIG或者等价硬隔离方案的尽量上否则排查问题时你会非常痛苦。4.4 可观测性缺失等于“盲飞”调度中心必须留痕我见过不止一个团队调度器上线了但只监控了CPU和内存调度决策的过程完全是个黑盒。后来出了故障只能靠猜是策略算错了还是节点状态不准还是模型路由表更新出错了没有日志没有trace排查一个晚上都找不到根因。这个问题必须在一开始就解决。我的建议是调度器每做一次决策都要写审计日志内容包括模型名、版本、请求ID、候选节点列表、最终选中的节点、决策原因、决策耗时、当时各节点的资源状态。这些日志可以不用实时查询但一定要持久化。出了服务质量问题先回放日志看调度决策是否合理再往下排查执行环节。网关层还要打全链路trace id一次请求从网关进来经过路由、调度、推理、返回每一步都带同样的id这样就能很快定位到瓶颈是在调度层还是在推理层。这套东西搭建成本不算高但回报率极高强烈建议在项目早期就做好不要等故障发生了再补。4.5 兼容性问题异构平台里没有“银弹指令”异构调度的难点不只是硬件差异软件栈差异更磨人。模型推理依赖的算子库、通信库、量化方案在不同品牌卡之间往往不具备可比性。你可能在英伟达GPU上跑得好好的一个模型迁移到国产加速卡上一个算子不支持就报错或者FP8量化根本不生效跑出来的精度完全不对。我的经验是在项目启动阶段就要做一个“算子兼容性审计”把你计划部署的所有模型的算子列表梳理出来和目标硬件逐个核对。如果发现不支持的算子尽早考虑替换方案比如用ONNX导出、算子替换、或者干脆选择其他模型结构。这个审计做得越早后期返工越少。通信库也是一个雷。NCCL只覆盖英伟达生态混入其他加速卡后集合通信就必须依赖厂商自研的通信库性能特性完全不同。调度器在选择多卡并行方案时要感知硬件类型不能假设所有卡之间的通信带宽是一样的。如果调度器默认两张卡走PCIe也能有NVLink的带宽那这个模型的多卡推理性能就会非常难看。常见现象可能原因排查方式推荐解法模型部署后一直pending调度器认为显存不足查看调度日志和节点空闲显存启用显存碎片整理或调整模型放置首次调用延迟特别高模型冷启动检查是否为首次加载配置常驻实例和预热小模型时延突然飙升大模型任务抢占算力查看节点GPU利用率和时间片分布启用优先级调度和SLA保障池国产加速卡上推理报错算子不兼容跑算子兼容性审计ONNX导出或算子替换控制面重启后路由错乱元数据未持久化检查状态存储启用高可用和持久化存储5. 这套方案适合谁以及怎么评估效果5.1 目标场景不是什么团队都需要马上上异构调度异构算力调度底座听上去很强大但它有明确的适用边界。如果你的团队只有三五张卡跑着一两个模型业务量也不大那就完全没必要上这套系统。自己做几张表的资源分配手工管理反而更简单高效。复杂系统的维护成本在那里摆着没有规模效应的情况下硬上只会让团队被运维拖垮。但如果你的团队模型数量超过20个、GPU数量超过50张、业务有明显的波峰波谷并且手里确实混着多种型号的卡那异构调度底座几乎就是刚需。还有一个明显的信号是你发现团队里开始有人专门花时间处理“哪张卡跑哪个模型”这种资源协调问题这往往就意味着调度需求已经超出人肉管理的范围了。跨厂商采购也是重要的判断依据。如果企业明确知道自己未来的采购会涉及多个品牌那异构调度就不是“要不要做”的问题而是“什么时候做”的问题。越早把资源抽象层建设好后续新硬件接入的时候就越省事。临时抱佛脚的迁移成本往往是一开始就规划好的几十倍。5.2 落地效果评估不要只看“GPU利用率涨了多少”很多团队做这类项目汇报的时候喜欢拿“GPU利用率从30%涨到70%”当亮点但利用率只是其中一个指标而且不是唯一重要的指标。我建议从五个维度做综合评估。第一是调度决策延迟。P95的调度耗时应该控制在50毫秒以内如果调度决策本身就要几百毫秒那对在线推理的影响就已经不可接受了。第二是推理服务质量。看P99延迟的变化异构调度不能以牺牲稳定性为代价换利用率如果P99抖动了超过20%这个方案就需要重新审视。第三是资源利用率。看整体GPU平均利用率同时也看碎片率。利用率涨不上去调度的意义就打折扣了。第四是发布效率。从“新建一个模型到完成部署”的时长异构调度底座应该做到分钟级复用已有资源而不是每个新模型都要从零开始找卡。第五是故障恢复时间。调度器或者某个节点出故障之后受影响的服务在多久内能自愈这个指标决定了系统的可信度。这些指标维度各有侧重但实际评测时我会建议至少连续观察一个月再下结论。三天两天的数据太容易被业务波动干扰只有跨过一个完整的业务周期各项指标才真正有说服力。一个月的数据出来之后再回头对照改造前的基线你会发现这个项目的真实价值比任何PPT上的数字都直观。5.3 我的一点个人体会先把“看得见的指标”做出来根据我个人参与这类项目的经验异构算力调度的项目最后能不能成往往不取决于技术方案多惊艳。我见过不少项目技术上规划得很完整框架选得很高大上但落地的过程中各种扯皮运维说调度策略看不懂算法团队说迁移后的结果对不上管理层说要看到成本节省。最后项目烂尾的不少。真正能落地的团队通常有个共同特点先把“看得见的指标”做出来。也就是先选定一两个核心模型、一小部分算力快速搭一个最小可用的调度闭环从“请求进来”到“结果返回”全链路跑通让所有人看到调度决策、节点状态、资源利用率这些数据。项目的信任感建立起来之后后面的推广才顺理成章。回过头来看OpenCSG和密瓜智能这次合作我觉得最有价值的不是它们要做什么宏大平台而是它们把“模型托管”和“算力原生”这两个阶段明确拆开了。对企业来说这意味着一个更清晰的演进路径托管解决的是“能用”原生调度解决的是“用好”。如果产品真正落地给行业带来的可能是很多企业一直想要、但自己又很难一把手搭建的那一层能力。至少对于长期做着零散资源整合工作的人来说这算是一件值得持续关注进展的事情。
