大模型公司云原生工程师：从K8s到GPU调度的实战指南

1. 大模型公司搞云原生，真不只是"运维容器"那么简单

这两年大模型赛道火得一塌糊涂，但有个现象挺有意思——各家基模公司在疯狂招算法人才的同时,云原生研发工程师的岗位需求也在悄悄暴涨。我身边不少朋友看到"基础模型公司招聘云原生研发工程师"这种JD时，第一反应都是："大模型公司不是应该招算法大佬吗？云原生这种偏底层基建的角色，去大模型公司能干什么？"

有这种疑问很正常，毕竟大多数人印象里的云原生还停留在"把应用塞进容器、用Kubernetes编排一下、搞搞CI/CD流水线"这个层面。但如果你真的接触过一个大模型训练集群，就会明白——在基模公司里，云原生工程师压根不是传统意义上的"运维"或者"平台开发"，他们更像是整个算力体系的总调度师。

拿阶跃星辰这种国内前沿的基模公司来举例，这类公司核心工作是训练和迭代基础大模型。大模型训练是什么概念？不是一台服务器跑个脚本，而是上千张GPU卡组成的超级集群，动辄连续运行几周甚至几个月，中间任何一个节点故障、网络抖动、显存泄露，都可能导致整个训练任务中断，前功尽弃。这种场景下，底层基础设施的稳定性、资源调度的效率、故障自愈的能力，直接决定了一个模型能不能按时训练出来。

所以你看，云原生在大模型公司里的定位早就变了：它不再只是支撑业务系统的"水电煤"，而是直接参与到模型训练和推理的每一个环节里，成为算力交付的核心载体。这也解释了为什么现在基模公司愿意花大价钱招云原生研发工程师——因为算法团队负责"想得出来"，云原生团队负责"跑得起来"，缺一个都不行。

这篇文章我想从这份招聘信息切入，聊聊我这些年在云原生和AI基础设施交叉领域的实际观察，包括大模型公司里云原生工程师到底做什么、需要什么硬技能、以及如果你对这类岗位感兴趣，应该朝哪个方向准备。内容不涉及具体公司的内部信息，更多是从行业通识和个人经验出发，希望能给正在观望这个方向的人一些参考。

2. 大模型训练和推理，到底给云原生出了哪些难题

2.1 GPU资源不是"越多越好"，而是"调度得越好越值钱"

很多人以为大模型公司买几千张GPU卡就能开始训练了，实际上最大的瓶颈往往不在卡的数量，而在卡的利用率。以我的经验来看，训练集群的GPU平均利用率能稳定跑到60%以上就算很不错的水平了，很多团队的利用率其实长期在40%以下徘徊。

为什么利用率这么低？因为大模型训练任务对资源的需求是动态变化的。一个训练任务在数据加载阶段，GPU可能闲得发慌，但在反向传播阶段，显存又可能瞬间爆掉。传统的资源管理方式是一台机器固定跑一个任务，GPU空闲就空着，别人想用也用不了。而在云原生架构下，你可以在Kubernetes之上做精细化的GPU资源共享，把不同优先级的任务动态调度到同一个集群里，用空闲时段跑数据预处理、跑小模型调参、跑推理压测，把GPU的时间片榨得干干净净。

还有一个容易被忽略的问题是异构GPU的混部。现在的训练集群里，A100、H100、4090、国产加速卡可能同时存在，它们的算力、显存、互联带宽都不一样。云原生调度器需要能感知这些差异，把碎片化的GPU资源合理分配给不同任务。算法工程师不会关心你用的是哪张卡，他们只关心"我的任务什么时候能排上、跑起来稳不稳"。这中间的复杂性，全部压给了云原生工程师。

2.2 分布式训练：把"一台超级电脑"拆成"一群普通电脑"

大模型训练本质上是一种极度消耗资源的高性能计算，它的底层依赖的是分布式并行计算，一种把大规模计算任务拆分成多个小任务、分配给不同计算节点并行执行的技术。一个几千亿参数的大模型，单卡根本放不下，必须切分成多个分片，放到几十甚至上百台机器上协同训练。这种训练方式涉及大规模集群的资源管理、任务编排和网络通信，对底层基础设施提出了极为苛刻的要求。

从云原生的视角来看，分布式训练给Kubernetes带来了几个非常棘手的挑战。

第一个是任务编排的复杂性。一个训练任务可能包含多个角色：Parameter Server、Worker、Evaluator，每种角色需要的资源类型和数量都不一样。Kubernetes原生的Deployment、StatefulSet根本没法直接描述这种复杂的任务拓扑，所以业界出现了各种自定义控制器，比如KubeFlow、Volcano、Kueue这些项目，本质都是在扩展Kubernetes的调度能力，让它"听得懂"分布式训练的语言。

第二个是网络性能问题。分布式训练极度依赖节点间的通信带宽，特别是在模型并行和流水线并行的场景下，每个训练步都要做一次全集群的梯度同步。如果网络延迟高、带宽不够，整个集群的算力就会被通信拖死。所以在训练集群里，你经常能看到RoCE、InfiniBand、RDMA这些专属名词。云原生工程师需要把网络虚拟化层做得很"轻"，不能因为叠加了容器网络就额外增加通信开销，否则模型训练速度直接缩水三分之一都是有可能的。

第三个是容错问题。训练任务跑半个月，中间挂掉一个节点怎么办？传统做法是停掉整个任务重新拉起，但大模型训练的Checkpoint动辄几百GB甚至上TB，保存一次就要好几分钟，频繁重启的话训练进度就全耗在存储IO上了。好的云原生方案需要做故障预判、快速迁移、增量Checkpoint等能力，让训练任务在节点故障时尽量"无感"地恢复到最近的状态。

2.3 推理服务：流量洪峰面前的"秒级弹性"

如果说训练场景是"慢工出细活"，那推理场景就是"兵贵神速"。大模型应用上线之后，用户请求是不可预测的，可能白天闲得发慌，晚上突然来一波流量洪峰。而且大模型推理和传统Web服务完全不一样，它不是无状态的，每个请求可能都要占用几十GB的显存资源，一个实例的加载时间动辄几十秒。如果流量突增时再临时扩容，光是拉起新实例的等待时间就够用户体验"跌穿地板"了。

这里就需要云原生体系里的自动扩缩容机制，但绝对不只是CPU和内存指标那么简单的HPA。大模型推理的扩缩容要组合看QPS、排队长度、显存余量、GPU利用率等多个指标。我们做过一个方案，用Kubernetes的Event-driven Autoscaling（KEDA）对接推理框架的指标接口，当排队请求数超过阈值时自动扩容，低峰期再缩容到最小副本数。这样既保证了用户体验，又不会让GPU在闲时白白空转。

还有个麻烦是推理引擎本身并不总是无状态的，像vLLM、TensorRT-LLM这类推理框架，本身是无状态的（模型只读），但如果你开启了前缀缓存等功能，不同副本之间的状态同步就变得复杂。云原生工程师要去设计合适的亲和性调度策略，避免流量频繁在不同副本间漂移导致缓存命中率下降。这种细节问题，只有踩过一次坑的人才懂它有多烦人。

3. 一份基模公司云原生岗位JD的技术栈拆解

3.1 硬技能：从Kubernetes到GPU调度的完整链路

把这类岗位的JD关键词拆开看，基本上可以整理出这样一张技能地图：

需要注意的是，仅仅"会用Kubernetes"在基模公司的招聘里几乎不构成任何优势，因为你会用别人也会用。这里真正有价值的是"能扩展Kubernetes"的能力：当原生组件满足不了你的需求时，你能不能写一个自定义CRD（Custom Resource Definition，自定义资源定义），能不能实现一个Scheduler Plugin扩展调度逻辑，这些问题才是区分普通用户和研发工程师的分水岭。

3.2 加分项：懂一点机器学习，比纯云原生工程师更吃香

在基模公司做云原生，有个很微妙的地方——你服务的对象是算法工程师和模型训练任务，如果你完全不懂机器学习的训练流程，很多需求你根本听不懂。

举个例子，算法团队说"我这次跑的任务数据格式是Safetensors，需要把数据集挂载进来，但跨节点的数据缓存没打到，每轮迭代数据读取太慢了，能不能帮我看看？"如果不懂Safetensors是什么、不懂数据加载在训练循环中的位置，你可能连从哪儿排查都不知道。所以我一直觉得，想在基模公司的云原生岗位上真正站住脚，最好懂一些机器学习的基础概念：训练是什么、推理是什么、显存和算力分别影响什么、Checkpoint为什么这么大、为什么数据加载会成为瓶颈。

这种"懂AI的云原生工程师"在当前市场上是稀缺的。因为纯算法背景的人搞不定基础设施，纯云原生背景的人又和算法团队对话困难，而中间这个交叉地带，恰恰是基模公司最需要人的地方。

3.3 软技能：大模型公司里最重要的工作方式

除了技术本身，这类岗位对软技能的要求其实也很明确，只是不会写在JD里。我在大模型公司工作的感受是，算法团队的工作节奏非常快——今天的实验明天就要看结果，如果基础设施出了问题，他们没耐心看你写排查报告，只会直接问你"什么时候能恢复"。所以云原生工程师在这里必须具备极强的问题定界能力和沟通表达能力。

还有一点很考验人的是需求优先级的管理。算法团队的需求往往又急又多：这边要扩容，那边要新功能，后面还有一堆优化需求排队。如果你来者不拒，最后大概率是什么都做不好。成熟的云原生工程师会主动和算法团队对齐优先级，把基础设施稳定性放在最高优先级，然后再按投入产出比去排需求。这种"拒绝的艺术"，在大模型公司比在传统公司更重要，因为资源竞争真的太激烈了。

4. 从开源CMDB到云原生适配，一条值得参考的实战路径

4.1 为什么传统的CMDB思维在云原生时代开始失效

搜索词里有个"开源CMDB适配云原生"，这其实是一个非常典型的演进话题，也是很多正在向云原生转型的团队的真实现状。CMDB（Configuration Management Database）在传统IT运维里是核心资产，记录着每台服务器、每个应用、每条网络链路的配置关系。但到了云原生环境，很多东西发生了根本变化。

传统CMDB里的对象是相对静态的——一台物理服务器放在机房里，它的IP、位置、配置基本一年半载不会变。但云原生环境里，Pod的IP可能是几分钟一变，实例数量可能随流量动态伸缩，服务之间的依赖关系由Service Mesh动态管理。你如果用传统CMDB的思路去维护这些动态对象，很快就会陷入一个困境：配置数据永远跟不上实际状态，CMDB里的"真相"和线上的"现实"严重脱节。

再往深一层说，云原生环境里的"配置"已经不再是一张表能描述清楚的了。一个应用可能有几十个环境变量、多个配置挂载、复杂的网络策略、精细的RBAC权限。这些配置散落在Kubernetes的各个资源对象里，用传统CMDB的模型去建模，根本不现实。

4.2 把CMDB改造成云原生的"实时资源图谱"

我自己经历过一个从传统CMDB向云原生适配的项目，说实话，这不是把数据迁个库那么简单，而是整个建模思路的转变。

我们的做法是，不再试图把"期望状态"存到数据库里，而是让CMDB变成"实时汇聚层"——通过Kubernetes API Server的事件监听机制，把所有资源对象的变更实时同步到CMDB里，再结合实际的状态数据（比如Pod是否Running、是否需要重建），构建出一张实时的资源图谱。这样做的好处是，CMDB从"人工维护的管理台账"变成了"自动同步的观测平台"，数据可信度大幅提升。

这里有个技术细节值得展开说。Kubernetes的Informer机制可以监听资源变更事件，但它默认的行为是把事件传给上层处理器，不做持久化。我们在做CMDB同步时，用了一套数据库容器化部署的方案，配合Binlog增量同步，把Kubernetes资源变更事件流式地同步到CMDB数据库，形成一张可以回溯的历史变更表。这张表非常有用——当线上出现故障时，你可以通过它快速确认"这个服务是不是刚发布过""这个命名空间是不是有人改过配置"，排查效率翻倍。

4.3 开源选型的取舍经验

我当时调研了市面上几个开源CMDB项目，包括一些国内团队维护的配置管理平台和一些社区活跃的云资源管理工具。在这个过程中最深的体会是：不要为了开源而开源，更不要迷信某个项目的Star数就能解决你所有问题。

选型的核心逻辑应该是：你的团队有没有能力维护这个项目的二次开发？如果你的场景不需要深度定制，直接选一个功能完整、社区活跃、部署简单的项目就好；但如果你要把它作为基础设施的底座，深度对接自研平台，那就必须评估它的代码结构、扩展点设计、和云原生生态的兼容性。

我们最终选型时有一个测试方法：把这个开源项目部署到我们的测试集群里，用一个真实的场景去验证——比如模拟一个Pod被驱逐、重建、漂移到另一台节点的完整生命周期，看CMDB里的数据能否准确跟踪这个变化。很多项目在这个简单测试上就暴露了问题，要么数据更新有延迟，要么根本不知道Pod重建了。这个测试方法我认为值得推荐给所有正在做类似选型的人，比看一堆功能对比表格靠谱得多。

5. 给想入行的人泼三盆冷水

最后聊聊我观察到的、很多想往这个方向转的人容易忽略的现实问题，也可以说是三盆冷水。

第一盆冷水是，这个岗位的门槛真的不低。很多人以为会点Kubernetes、背几个CKA题目就能去基模公司应聘云原生工程师，实际上完全不够。基模公司要的是能解决极端场景问题的工程师——集群规模几千台机器、单任务占用几百张GPU、故障恢复要求分钟级，这些场景需要的系统设计能力和问题排查能力，远远超出日常业务云原生开发的范畴。

第二盆冷水是，这个岗位的压力比想象中大。大模型公司里的基础设施团队往往是"背锅侠"角色。算法跑不出来怪基础设施慢，推理延迟高了怪基础设施不行，资源不够了也第一个找你。你需要有很强的抗压能力，还要学会在混乱中快速定界问题。有时候凌晨三点被叫起来处理训练任务中断的问题，真的不是段子。

第三盆冷水是，这个领域的技术栈迭代速度极快。今天的Kubernetes生态还算是相对稳定的，但GPU调度、异构计算、大模型推理优化这些方向几乎每个月都有新方案冒出来。你今天掌握的东西，可能一年后就过时了一半。如果你不是一个喜欢持续学习的人，这个岗位会让你非常累。

那什么样的人适合呢？我个人觉得，真正适合做这一行的人是那种天生喜欢折腾基础设施、对性能指标敏感、出了问题能不问出"为什么"不睡觉的人，对性能指标敏感、出了问题能盯到底的人。云原生研发工程师不是单纯的"运维升级版"，而是一个需要深入理解算力分配、资源切分、任务编排的底层系统工程师角色。在这个位置上，你面对的不是某一个业务模块，而是驱动整个大模型运转的"发动机"本身——这种感觉，说实话挺上头的。

如果你现在正在考虑这个方向，我的建议是：先把Kubernetes的原理吃透，再把GPU调度、高性能网络、分布式存储这些硬骨头啃下来，然后找一个真实的训练集群环境去实战——光靠在本地搭个单机K8s练练手，离基模公司的要求还差得太远。路不近，但值得走。