10万 GPU卡的运营听起来像个夸张的数字游戏但对真正干过这事儿的人来说这是实打实的压力测试。你可能管过几十台、几百台GPU服务器觉得日子还行但一旦规模上到十万张卡这个量级你会发现所有之前靠人肉、靠经验、靠“跟兄弟们打个招呼”能解决的问题全部变成了系统性难题。这不是技术栈的简单放大而是整个运营逻辑的重构。这篇文章我想和你聊聊站在技术运营的角度把十万张卡当成一个“活着的有机体”来管理到底要面对什么。我不打算给你一套从天而降的完美方案而是分享这些年我在一线踩坑后沉淀下来的思考框架。这里面没有炫技只有如何把“能用”变成“好用”再变成“稳定、高效、可预期”的硬功夫。无论你是刚接手大规模集群还是正在为扩容做准备这篇内容大概能帮你少走至少半年的弯路。1. 先想清楚10万规模到底在运营什么很多刚接触大规模集群的同学第一反应是“我要把驱动装好、把监控配上、把故障处理掉”。这些当然对但只对了一小部分。10万张卡的运营本质上是把一个物理资源池转变成一个“随时可取、按需分配、质量可控”的计算服务。你的用户不再是几个熟悉的研究员而是成百上千个业务团队他们不关心底层是A100还是H800他们只关心三件事能不能拿到卡、拿到卡好不好用、跑了稳不稳定。1.1 从“管机器”到“管平台”的认知切换我以前也当过“救火队员”哪台机器报警了就去修哪台哪个用户说卡了就去查哪个任务。但在十万卡规模下这种模式完全失效。因为故障是常态而不是异常。每天都会有卡掉线、驱动崩溃、节点温度过高、网络抖动如果你还是靠人去逐个响应团队规模得爆炸。所以第一层认知切换是你运营的不是一张张卡而是一套系统一套能够自我发现、自我隔离、甚至自我修复的系统。你的KPI不是“修好了多少故障”而是“故障对用户的影响有多小”。这时候你考虑的核心变成了“平台能力”比如任务调度能不能自动绕开故障节点比如新节点上线能不能做到零人工干预比如用户申请资源到真正能用上时间能不能从“天”压缩到“分钟”“管平台”还有一个含义是你得从“成本中心”变成“价值中心”。技术运营如果只会花钱扩容、买卡、修卡那老板眼里你就是个“运维成本”。但你如果能拿出数据说明通过你的调度优化、故障预测、利用率提升为公司在同等算力下多支撑了多少业务省下了多少采购预算那你的话语权完全不同。这就是为什么我一直强调技术运营一定要懂业务指标而不只是技术指标。1.2 四个运营维度资源、环境、故障、成本把“运营平台”这个抽象概念拆开落到日常工作上其实就是四个维度资源维度有多少卡可用、多少卡被占用、多少卡在维修、多少卡在“养老”。要做到实时的资源可视化和精细化的配额管理。环境维度从驱动、CUDA、容器runtime到Python包、网络配置任何一层不一致都会成为用户眼中的“环境坑”。你要提供标准化的环境交付能力而不是让每个用户自己折腾。故障维度故障发现速度、定位准确度、隔离及时性、修复效率。这背后是监控覆盖率、日志完整度、自动化操作脚本的成熟度。成本维度每一张卡是不是都在干正事还是被闲置、被低效占用用户申请了100张卡实际用了多少算力怎么把碎片化的资源重新拼接起来这四个维度每一个单拎出来都可以写一篇万字长文。这篇文章我重点拆解其中最关键、也最容易被忽略的部分。2. 集群怎么搭卡才“好用”十万张卡不是一堆裸卡堆在那就能跑的。硬件层面、驱动层面、资源管理层三层都得打通才能把一个“卡”变成“服务”。2.1 硬件层多卡拓扑与互联选型先说一个很多人容易忽略的点一张AI服务器里插了8张卡和8张卡分布在8台机器里性能表现天差地别。原因就是互联拓扑。在大规模训练场景比如千卡以上的大模型训练通信量极大。如果卡间走的是PCIe Switch多卡通信会抢带宽延迟也高如果走NVLinkNVSwitch卡间带宽能到几百GB/s效果会好很多。所以在选型时训练集群和推理集群的硬件策略应该不一样。训练集群优先选择8卡NVLink全互联的整机比如英伟达DGX系列或者浪潮、宁畅这些厂商的8卡服务器而推理集群如果对延迟不敏感4卡机、双卡机甚至单卡机都够用这样反而能减少故障爆炸半径。单服务器多GPU卡的互联怎么连也是个实操问题。我见过不少现场卡插上了但拓扑不对。比如8张卡分在了两个CPU的PCIe域上跨CPU通信要绕QPI/UPI总线性能掉得很厉害。用nvidia-smi topo -m一看NVLink和PCIe的连线图一眼就能看出来。GPU卡之间的直接互联如果是NVLink那是好事如果走PCIe就要保证同一个训练任务的卡尽量落在同一个PCIe Switch下。还有网络层。大规模训练要同步梯度参数服务器模式对网络带宽要求稍低但基于AllReduce的同步训练网卡速度直接决定扩展效率。我们内部一般要求跨节点通信至少用RoCE或InfiniBand100Gbps起步400Gbps是常态。如果网络是短板你哪怕GPU再多训练效率也上不去这就是“水桶效应”。2.2 驱动层用GPU Operator做标准化交付驱动安装听上去是个简单活但你在十万卡规模下会发现节点下线重装、新卡扩容、内核升级、驱动适配任何一次手动操作都会留下“配置漂移”。今天这台机器装的是535.104.05明天那台机器还是470.182.03用户一跑行为完全不一样这种问题能把人折磨疯。所以这里必须给NVIDIA GPU Operator一个位置。它是NVIDIA官方提供的Kubernetes扩展能通过云原生的方式管理GPU节点的驱动、运行时和监控组件。你不用再SSH到每台机器去手动装驱动而是通过K8s的DaemonSet机制自动给节点打上驱动和运行时。GPU Operator打包了这几样东西NVIDIA Driver容器化部署的驱动按节点自动匹配和安装。NVIDIA Container Toolkit让Docker/containerd里的容器能访问GPU之前叫nvidia-docker2。DCGM-Exporter暴露GPU健康指标给Prometheus监控用的。Node Feature Discovery自动给节点打上GPU型号、驱动版本的标签方便调度器识别。使用GPU Operator之后新节点上线流程从“人工装驱动、装容器工具、配监控”变成了“节点加电、注册到集群、Operator自动完成一切”。注意GPU Operator对集群版本有要求K8s版本过旧会有很多兼容性问题而且每个版本适配的驱动版本范围也不一样一定要参考官方文档的兼容矩阵。这里有个经验GPU Operator要想稳定运行节点的内核版本和驱动版本必须提前规划好。不要频繁升级内核因为Operator里的内核模块是编译好的内核一变驱动模块就要重新适配非常容易出问题。我们内部的策略是选择一个稳定的内核长版本在一个大版本周期内保持不动除非有严重安全漏洞否则不升级。2.3 资源层池化与调度的基础设置卡装好了驱动没问题了接下来才是重头戏——怎么让用户“拿到卡”。物理上一张卡就是一张卡但不同用户对资源的需求不一样。有人要整卡跑大模型有人只需要几GB显存跑个小脚本。如果全部整卡分配那显存就白白浪费了。这时候就要做“池化”把物理GPU切分成逻辑资源。常见的切分方式有三种MIG、时间切片、vGPU。MIG是硬件层面的切分只能用在A100/A800/H800这些较新的卡上能把一张卡切成多个独立的GPU实例显存和算力都是硬隔离的适合多用户共用一张卡也能保证SLA。时间切片是软件层面的多任务轮流使用一张卡隔离性弱但胜在灵活。vGPU通常需要虚拟化平台比如NVIDIA vGPU搭配vSphere。我推荐的做法是分池管理训练集群尽量整卡分配不做切分因为训练任务占满显存和算力切分了反而影响性能推理集群可以用MIG或时间切片提高利用率开发测试集群则可以考虑弹性调度允许超分反正开发机卡了也无所谓重启就行。分池管理还有一个隐藏的好处故障排查时爆炸半径能被限制。比如开发测试集群的节点再乱也不会影响到生产训练集群的稳定性。3. 可观测性10万张卡的“体检报告”资源交付出去只是开始更大的挑战是“运营”本身。我始终觉得可观测性建设是大规模GPU运营最核心的“地基工程”。没有数据你所有的决策都是拍脑袋有了数据你才能做预测、做优化、做自动化的闭环。3.1 硬指标DCGM与Xid错误先来说说监控数据的采集。NVIDIA官方提供了DCGMData Center GPU Manager通过DCGM-Exporter可以采集到非常丰富的GPU指标。哪些指标值得重点关注我建议至少盯住这几类利用率类SM利用率也就是计算核心占用率、显存利用率、显存带宽利用率、NVLink收发速率、PCIe收发速率。状态类GPU温度、显存温度、功耗、风扇转速、电源电压。错误类Xid错误计数、ECC错误计数分单比特、双比特、NVLink错误计数、PCIe错误计数。运行时长类GPU运行时间、处于空闲状态的时长。采集频率上Prometheus默认15秒抓一次其实有点稀疏。有些指标比如NVLink带宽、SM利用率波动非常快你如果15秒采样一次平均值会掩盖很多瞬时问题。我们内部对核心指标做到5秒采集一次虽然不是最精确但基本能覆盖大部分场景。说到Xid错误这是NVIDIA驱动上报的一种硬件错误机制。Xid错误是GPU运维里最需要重视的信号它几乎是硬件故障或者驱动跟硬件不匹配的先兆。Xid错误码很多常见的有Xid 63/64ECC错误或GPU显存错误通常是显存颗粒问题大概率要换卡。Xid 79GPU在重放错误可能显存有坏块也可能是驱动不稳定。Xid 13/31一般和显存越界有关多数是程序bug但也可能是硬件问题。Xid 45/68/69严重错误驱动崩溃或GPU掉卡通常需要重置或换卡。我见过很多团队Xid错误出了但是因为“看起来任务还在跑”就没管。结果没几天就变成系统崩溃所有依赖这张卡的训练任务全部中断损失几十万GPU小时的算力。所以我们的自动化规则很简单只要DCGM上报Xid错误立刻标记该卡为“亚健康”隔离出调度池不允许新任务调度上去同时通知用户做任务迁移。这个自动化动作是我们从无数次惨痛教训里学来的。3.2 业务指标利用率不能只看显存监控GPU状态只是第一步要想让运营做得好还得关注业务指标。很多业务方的同学看着nvidia-smi里显存用了90%就说“我卡用满了”。但实际上显存占用率高和算力利用率高完全是两回事。你显存占满了可能只是在加载模型参数实际计算并没有密集发生。典型的是推理服务模型常驻显存但GPU计算单元的利用率可能只有5%到10%。所以我们在做资源报表的时候一定要区分“显存利用率”和“算力利用率SM利用率”。如果一张卡显存利用率很高但SM利用率长期低于20%那大概率说明这个任务模型大、计算稀疏或者存在显存溢配的情况。这时候运营要做两件事一是跟业务方沟通看能不能优化模型结构或者推理引擎减少显存占用二是在调度层面对这类任务做更合理的打包比如把多个推理实例塞到一张卡上共用显存。还有一个容易被忽略的指标是“排队时间”。用户申请资源后从提交申请到任务真正在GPU上跑起来隔了多久如果这个时间太长用户就会觉得算力不够用然后进一步申请更多资源造成“假性资源紧张”。所以我们内部对调度器有要求高优先级任务的排队时间必须控制在分钟级超时就自动告警运营人员就要介入要么抢节点要么扩容。4. 故障排查实战一线踩坑记录按理说有了监控和告警故障处理应该轻松了。但实际情况是告警只是告诉你“出事了”具体什么问题、怎么解决、怎么防止再犯这才是真正考验运营团队的地方。这一章我分享几个高频故障的实际排查过程。4.1 GPU Crash Dump / Xid错误怎么响应先说说“GPU Crash Dump triggered”这种情况。这个词最近在社群里面出现得特别频繁很多人在跑深度学习训练时突然看到这个报错然后驱动就崩了任务也就断了。这个报错的意思是GPU驱动检测到了硬件或软件层面的严重异常正在导出崩溃转储信息crash dump本质是驱动层的自我保护机制。我在实际运维中遇到的“GPU Crash Dump”触发原因大致有三类第一类是硬件不稳定比如电源供电不足、显存过热、显卡被过度超频。这类问题一般发生在高功耗持续运行的训练集群。所以我们要求所有高负载节点的机房制冷和供电必须冗余同时通过DCGM做温度监控超过85度就预警超过92度直接强制降频或隔离。第二类是驱动bug。NVIDIA驱动版本如果不稳定在某些操作比如CUDA上下文切换频繁、显存分配释放反复时会触发崩溃转储。这类问题通常是通过升级或回滚驱动解决。我们内部维护了一个驱动版本基线每个新驱动先在测试集群跑一周通过“业务验证稳定性测试”才允许推送到生产环境。第三类是应用越界访问比如CUDA代码里访问了非法显存地址、显存越界写、未释放的资源过多等。这种情况驱动会直接触发Xid错误或crash dump。很难靠运维单方面解决必须让业务方提供core dump和日志定位到具体的非法地址和调用栈。我们一般会配合业务方在容器里挂上CUDA的compute-sanitizer内存检查工具抓更精细的报错信息。响应流程上我总结了一套SOP收到告警 - 查看DCGM指标重点看Xid错误码、温度、功耗 - 检查驱动日志dmesg /var/log/syslog - 拉取业务日志和core dump - 判断是硬件还是软件问题 - 硬件问题隔离节点触发维修流程软件问题通知业务方定位必要时回滚驱动或修改代码。另外诊断完之后故障卡不要立刻回到生产池。我的习惯是先让它跑一个10分钟的压力测试比如用NVIDIA自带的DCGM diagnostic或者gpu-burn确认无错误后再放回资源池。否则你侥幸放回去第二天又出问题用户信任感就会崩塌。4.2 用户侧常见的卡死和性能问题除了硬件层面的故障用户侧的问题也占了运营工作量的很大一部分。我挑几个高频的来说。场景一环境不一致导致“换台机器就报错”。这是最典型的。用户在开发机上程序跑得好好的提交到集群上就报错原因多半是开发机和集群节点的CUDA版本、Python版本、依赖库版本不一致。你说这是用户的锅吗不全是。如果平台能提供标准化的镜像和容器环境这个问题完全可以避免。我们的解决方案是推广“镜像即环境”的理念。所有基础环境打成Docker镜像按GPU驱动版本、CUDA版本、深度学习框架版本分类管理。用户提交任务时必须指定镜像不允许在裸机直接跑。这样既保证了环境一致性也方便运营团队统一做安全扫描和环境升级。场景二装环境时卡在“找不到CUDA”。很多用户在pip install torch的时候装了CPU版而不是GPU版。这是最容易踩的坑。PyTorch的官方源里默认的pip install torch装的是CPU版本你要装GPU版得指定--index-url https://download.pytorch.org/whl/cu118这样的链接。对于国内用户很多人会用清华源但清华源的PyTorch可能默认也是CPU版你必须找到带cu后缀的版本。我在团队内部写了一份《GPU环境安装避坑手册》核心就几条一是安装GPU版PyTorch必须指定CUDA版本标签二是nvidia-smi显示的CUDA Version是驱动支持的“最高版本”不代表你能直接用那个版本的CUDA三是容器内不一定需要单独装驱动但必须有nvidia-container-toolkit才能让容器访问GPU。把这几个逻辑讲清楚能帮用户挡掉50%的“装环境”问题。场景三Windows/虚拟机下GPU性能差。搜索热词里也有“windows 虚拟机如何共用gpu”、“vmware workstation pro gpu”这类词。Windows宿主机上跑Linux虚拟机再用GPU性能和稳定性都很不理想。因为VMware Workstation这类桌面虚拟化产品对GPU直通的效率远低于物理机环境。如果只是开发调试勉强可用如果是跑训练或推理妥妥的坑。我的建议很简单GPU算力型任务一律跑在物理机或者K8s容器上。Windows上实在要用可以试试WSL2的GPU加速微软和NVIDIA做了CUDA在WSL2的适配开发调试性能基本接近物理机。但生产任务不要考虑虚拟化这条路。4.3 故障自愈与预防机制故障处理完复盘是必须的但如果每次都靠复盘来补坑永远慢一步。我们花了很大精力做“故障自愈”和“预防机制”。自愈方面所有K8s工作负载都要配置重启策略和健康检查只要GPU异常导致Pod失败调度器就能自动把Pod重新调度到健康节点。数据面也做了自动备份和断点续训训练任务跑挂了能从最近的一个检查点checkpoint继续跑不用重头再来。预防方面我们建立了一套“健康巡检”机制。每周对全集群所有GPU做一次轻量级诊断跑一遍DCGM diagnostic的短测试检查温度、压力、ECC错误的情况。一旦发现ECC错误计数持续增长就自动触发换卡流程。ECC错误是显存老化的前兆等到它真的坏了再换影响的就不只是那张卡了。5. 用了多少、用得好不好效率与成本运营做到最后老板最关心的问题一定是“我买了这么多卡到底用了多少产出怎么样”5.1 利用率数据怎么算才真实先定义清楚几个指标分配率被用户申请占用的GPU数量 / 总GPU数量。真实利用率所有GPU的实际算力消耗 / 总算力能力。排队时长用户申请到任务启动的平均等待时间。无效占用GPU被申请了但业务根本没在跑或者跑得非常低效。我之前遇到过一个团队报上来的利用率“达到90%”结果一查很多卡被用户申请了之后只在上面跑了个sleep脚本或者训练任务卡在I/O等待GPU根本没有实际计算。所以“分配率”高不代表“利用率”高这个数据一定要拆开看。要拿到真实的利用率光靠nvidia-smi dmon这种单机命令不行必须从全集群的监控系统里捞数据。我们通常在DCGM采集的SM利用率、显存利用率基础上按“任务的申请时间段”和“任务的持续运行时间段”分别聚合。如果一张卡的平均SM利用率低于30%我们就认为这个任务在“浪费算力”会主动联系业务方确认需求。5.2 降本增效的几条实用路径聊完数据再说点实在的。降本增效不是一刀切地关资源而是要通过精细化管理挖掘出冗余算力。第一招碎片整理。大规模集群运行久了会形成大量“碎片”——比如一台8卡机器上5张卡被任务A占用剩下3张卡因为凑不满一个完整的8卡任务就被闲置了。这样的碎片资源单看每张卡利用率不高但汇总起来可能占到集群总量的10%到15%。我们的调度器里加了“节点聚合”策略优先将小任务调度到剩余卡数多的节点尽量把若干台机器腾空把“碎片”变成“整卡”让大任务有地方能跑。第二招队列与优先级分级。不同业务的重要性和紧急程度不一样。我们会把资源池分成高优级生产、在线推理、中优先级训练任务、低优先级开发调试、跑实验。低优先级任务在资源紧张的时候可以被抢占但代码里必须做检查点保护的机制被抢了也不会有太大损失。这样在同样的GPU总量下能支撑的“有效业务”更多。第三招空闲关停与弹性调度。对于异步推理或者批处理任务高峰期和低峰期的资源需求差异很大。我们的调度器支持基于Predicted负载的弹性伸缩低峰期自动把冗余节点设成“休眠”状态高峰期再自动唤醒。休眠的节点不参与调度、功耗大幅下降同时也能腾出电力容量给别的资源。这个做法的直接收益是电费和省下来的故障率一直满载的卡容易老化。第四招针对性采购与异构混部。各种模型对GPU的需求差异很大。大语言模型训练需要大显存、高带宽的卡而很多CV推理任务用相对低端的卡就绰绰有余。采购的时候别只盯着最高端的型号建一个“高低搭配”的资源池高端卡跑大模型中低端卡跑推理性价比会高很多。6. 环境治理与LLM时代的运营挑战走到这一步你已经有了一套能稳定支撑10万卡的平台体系但开篇我就说过GPU集群的运营是动态的。现在这个阶段最大的变量来自大模型LLM带来的应用形态变化以及相关的技术生态演进。6.1 镜像与依赖治理先说个老生常谈但又绕不开的问题——依赖治理。大模型时代人人都要跑PyTorch、TensorFlow、PaddleOCR、OpenVINO、Ollama这些东西每个框架背后还有一堆CUDA、cuDNN、Python包版本依赖。如果不加以治理整个集群的环境会乱成一锅粥。我们的做法是“镜像超市”模式。运营团队预先构建好几种基础镜像覆盖最常见的场景training-pytorch:latestPyTorch CUDA 12.x cuDNN 8.x适合大多训练任务。inference-trt:latestTensorRT Triton Inference Server适合推理。llm-ollama:latestOllama集成镜像适合本地快速部署大模型推理。cpu-only:latest适用于不需要GPU的轻量任务。用户提交任务时只能从镜像超市里选不允许自建镜像直接跑除非提交审核。看似限制了自由实际上是在帮用户省心。镜像统一之后环境类工单骤降大家不用再花一整天去排查“为什么我这里报错、你那里不报错”。同时网络源也要管起来。很多用户习惯用默认pip源回国或者内外网环境一变下载慢或者装上坏的包。我们在平台里统一配置了清华源、阿里源等镜像并对PyPI上的深度学习相关包做了一次“白名单”化处理确保下载的一定是兼容CUDA的版本。6.2 LLM训练/推理带来的新压力大模型的到来给GPU运营带来了两个明显的新挑战。第一个是训练稳定性。千卡、万卡级的大模型训练一跑就是几周甚至几个月。任何一张卡出问题哪怕只是几分钟的参数同步超时都可能导致整个训练任务失败或需要回滚。所以我们现在对训练集群的GPU做更高频的健康检查同时配合框架层的检查点机制把RTO恢复时间目标控制在“分钟级”。说白了就是在训练主循环里嵌入周期性的“心跳”和“快照”让机器知道“如果这张卡挂了我可以从哪继续”。第二个是推理密集化。大模型推理和传统CV推理完全不同。传统推理请求短平快单张卡能支撑大量请求但LLM推理请求长显存占用量大而且有“先到先得”和“共享KV Cache”等机制导致单张卡能承载的并发请求量大幅下降。这就对调度提出了新要求传统按照“显存大小”来做资源分配的方式不再够用还要考虑“请求的上下文长度”、“Batch Size”这些动态因素。我们正在研究基于“序列长度感知”的调度策略让推理集群在同一批卡上支撑更多的并发请求本质上是对显存和时间片做更细粒度的复用。6.3 昇腾等其他加速卡的兼容性技术圈不可能只有NVIDIA一家。现在很多机构也在尝试国产卡比如昇腾。从运营角度看多一种硬件架构就多一套管理复杂度。昇腾的驱动不是NVIDIA Driver监控指标不是DCGM容器工具也不是nvidia-container-toolkit整个链路都得单独适配。我的建议是在平台层做“异构资源抽象”把底层的不同加速卡包装成统一的“可调度资源”。上层用户只认资源规格多少T算力、多少GB显存不关心具体是NVIDIA、昇腾还是其他芯片。这个抽象层建设虽然前期成本高但长期来看能避免被单一供应商绑定。我们在内部做过一次昇腾迁移试点难点主要在上层框架的适配和算子库是否丰富纯物理层部署反而没那么复杂。7. 运营团队自身的能力建设平台技术再强最终还是要靠人去驱动。十万人团队这里指组织规模的运营方式跟十人小团队的“兄弟文化”是两码事。我这里说的“能力建设”更多是指团队工作方式的方法论升级。我们团队内部推行了几件事我觉得效果不错。一是“文档即代码”所有运维操作、SOP、故障复盘都沉淀为文档并且版本化管理。二是“自动化优先”任何操作如果一个月内手工执行超过三次就必须脚本化或平台化。三是“轮值运维深度复盘”每周有一个值班同学负责响应告警和工单周会上所有故障都要做“根因分析”和“改进项跟踪”避免同一个坑踩两次。很多人觉得做技术运营就是“体力活”我觉得恰恰相反。一个优秀的GPU技术运营应该具备系统思维和产品思维。你得理解上层业务为什么需要那么大的算力也得理解底层硬件为什么会出现这样那样的故障。当你站在整个“计算服务”的视角去看问题时你就是那个让十万张卡真正“活起来”的人。我自己带团队这几年最深的体会是10万张卡的平台听起来是个庞大的技术目标但你只要把“资源、环境、故障、成本”这四个轮子都装好让它们形成一个不停转动的飞轮每一次故障处理、每一次效率优化都会让这个飞轮转得更顺滑。量变到质变往往是在某个不经意的时刻发生的。等哪天你看到用户说“平台真稳跑了一个月都没出问题”那种成就感比写成百上千行代码要爽得多。