最近在技术社群刷到一条招聘信息一下子让人停住了目光阶跃星辰国内前沿基模公司正在招聘云原生研发工程师。单独看这条信息似乎只是一次普通的岗位发布但结合行业背景去读里面透露出的信号非常明确——大模型公司在卷完算法和算力之后工程底座已经成为决定上限的关键变量。现在各家基模公司的差距已经不只是模型架构和训练数据更多体现在同样的GPU资源谁能稳定跑出更高的训练效率同样的推理请求洪峰谁能用更少的卡扛住更大的并发。而这一切的背后都和一个角色血肉相连——云原生研发工程师。换句话说在AGI时代的基模公司里云原生已经从曾经的支撑角色变成了核心战斗力。这篇文章我想从这条招聘信息出发拆一拆基模公司的云原生岗位背后的核心技术点、能力要求以及如果你对这个方向感兴趣应该按照什么路径去积累。既送给正在观望这个赛道的朋友也送给想从传统云原生转向AI基础设施方向的工程师。1. 一条招聘启事背后的行业信号从运维支撑到核心底座1.1 基模公司凭什么离不开云原生先明确一下基模的含义。所谓基模公司做的是基础大模型的研发也就是从零训练千亿甚至万亿参数级别的模型然后通过API或开源方式对外输出能力。这类公司的特点非常鲜明第一算力消耗巨大训练任务动辄占用上千张加速卡第二研发迭代快几乎每周都有新的实验要跑第三复杂的分布式体系贯穿全流程数据处理、训练、微调、推理每一步都跑在分布式环境上。传统意义上的运维模式面对这种规模早就失效了。人工登录服务器一台一台配环境、逐个进程守护、手动升级依赖这种操作在单机时代或许还能凑合但在千卡集群面前完全是灾难。云原生带来的是一整套面向大规模分布式系统的设计范式不可变基础设施、声明式API、自动化编排、弹性伸缩、服务发现、可观测性等等。基模公司需要云原生不是因为别人都有K8s所以我也要有而是因为它本质上就是在云原生这套方法论之上才能管理好成千上万台机器组成的超级计算机。1.2 基模公司云原生研发工程师到底在做什么顺着JD往下看这类岗位最核心的职责和解惑可以这样概括建设和管理大规模的Kubernetes集群作为所有训练和推理任务运行的底座设计GPU资源调度方案让算力分配效率最大化减少任务排队和碎片浪费承接分布式训练框架和云原生基础设施之间的衔接比如任务编排、故障恢复、数据缓存加速打造模型推理服务平台支持在线高并发请求下的弹性伸缩与稳定输出构建可观测体系覆盖日志、指标、链路追踪让系统的每一个故障都能被快速定位。你会发现这个岗位干的活远比用K8s部署几个服务要深得多。它要求工程师既懂Kubernetes、容器、网络、存储这些云原生技术又要理解GPU、RDMA、分布式训练框架这些AI基础设施。这也是为什么越来越多基模公司宁愿花高薪招人也不愿意从普通互联网公司随便拉一支云原生团队过来——门槛确实不在K8s本身而在于你是否理解大模型训练和推理场景下如何用好云原生。2. 拆解基模公司云原生岗位的能力地图不只是K8s熟手2.1 GPU调度与算力池化K8s之外的硬门槛绝大多数云原生工程师对容器CPU和内存的调度很熟但到了GPU场景很多人会直接卡住。原因在于GPU这类资源比CPU复杂得多它有显存、有算力、有驱动和CUDA版本依赖还需要考虑通信拓扑。基模公司里的GPU调度第一优先级是最大化利用率。一张A100或者H20级别的卡动辄数十万元如果平均利用率只有三成那浪费的就是真金白银。但利用率又分两个层面一是任务运行期间GPU的实际算力能否跑满二是集群全局视角下任务之间的空隙能不能尽量填满。这就要靠调度策略来实现。调度器常用的策略有两种Binpack和Spread。Binpack倾向于把任务尽量堆叠到少数节点上优点是能空出更多整节点方便承接大的训练任务同时减少节点的碎片化Spread则是把任务铺开优点是能降低单点故障对多个任务的影响缺点是会制造大量碎片。基模公司通常会混合使用针对不同优先级和不同类型的任务走不同的调度策略。此外还有算力池化的话题。GPU共享、MIG切分、显存与算力隔离都是在底层芯片能力基础上做精细化切蛋糕的手段。一个推理服务可能只需要半张卡的算力如果整卡分配另一半就白白闲置。这里的核心技术包括时间片调度、显存隔离、算力限额等每一层都需要云原生研发工程师深入到底层去调优。再往下还有拓扑感知。分布式训练非常在意GPU之间的通信延迟数据并行时每个Step都要做梯度同步如果梯度聚合发生跨机通信走的是PCIe或网络延迟会比NVLink高出很多倍。调度器如果能把一个训练任务的多卡尽量分配到同一台机器上并选择拓扑最优的那几块卡训练吞吐的差距可能体现在百分之几十的量级上。很多公司甚至为了这个诉求会自己开发调度器插件或者直接改造Kubernetes的调度逻辑。2.2 分布式训练的容错与编排从单机思维切换到集群思维如果说GPU调度是地基那分布式训练的容错和编排就是主体框架。单机训练任务跑挂了大不了重来千卡集群上跑着一个周期数周的预训练任务如果中间某个节点坏了导致整个任务回滚到几轮之前那就是灾难级的资源浪费。这里的关键技术之一是弹性容错。业界的主流做法是周期性地保存checkpoint把模型权重、优化器状态、训练步数等信息固化到持久化存储中。训练过程中一旦有节点故障调度系统自动摘除故障节点、重新拉起新节点然后从最近一次checkpoint恢复训练。听起来简单实际上非常考验系统设计能力checkpoint怎么高效地写几百GB甚至上TB的权重数据如何在几分钟内完成落盘并避免影响训练性能怎么处理部分完成、部分失败的checkpoint写入这些都是在K8s之上做Operator时需要花大量心思解决的问题。任务编排层面也一样。在大模型训练中一个任务往往不是简单的一个Pod而是一个包含worker和ps的分布式拓扑。Kubernetes原生调度对这类作业的支持并不完善于是就有了各种自定义Controller和Operator。它们负责管理和维护训练作业的全生命周期创建时按照拓扑要求调度资源运行中持续监控健康状态与通信情况异常时自动做故障转移。这套编排逻辑是否合理直接决定了训练团队能否把精力集中在模型本身而不是天天折腾基础设施。另外训练任务往往会用上高性能网络比如RDMA和InfiniBand。这类网络和普通以太网最大的不同是它走的是RDMA协议数据从一台机器的GPU显存直接到达另一台机器的GPU显存跳过内核协议栈延迟和CPU开销都能大幅降低。但在K8s环境里接入RDMA就会涉及网卡直通、网络命名空间配置、路由规则等一系列复杂问题。这些都不是开箱即用的标准K8s能力需要云原生研发工程师做大量的定制化开发。2.3 推理系统的弹性伸缩在线场景对云原生的新考验训练场景是离线任务对延迟不敏感突发重来最多是浪费算力但推理场景是完全不一样的性质它的延迟直接决定用户体验。基模公司一旦对外开放模型API线上就会有无穷无尽的请求压过来而且请求模式很不均匀高峰和低谷之间的流量差距可能非常大。传统的HPA弹性伸缩在这种场景下往往不够用原因在于模型加载一次需要较长的时间几十GB的权重加载到显存可能要几十秒甚至分钟级。如果等到CPU指标上来再扩容用户的请求已经从网关层开始超时了。这就逼着云原生平台做出更多预判式、资源预留式的推理架构。常见的做法包括常驻一个基础规模的实例池保证最小的服务能力同时在流量预见上涨时提前扩容再配合请求级的路由策略和队列背压机制保证已有的伸缩实例不至于被冲垮。推理服务的另一大特点是GPU显存是稀缺资源。在线推理场景下动态Batching、PagedAttention这类技术可以从算法和应用层面提升显存利用效率但底层依然需要云原生平台提供精细的资源调度。不同模型、不同版本的推理副本之间怎么做混部一个实例故障后流量怎么平滑切换GPU实例的热升级如何做到不中断在线服务每一件事都需要云原生研发工程师去设计、开发、压测和调优。3. 云原生核心技术栈自学路线看懂需求更要看懂为什么3.1 第一阶段容器和Kubernetes别只停留在会用如果你连Docker和Kubernetes的基本操作都还不熟那第一步就是把它们从会启动一个容器推进到理解设计思想的层面。可以这样分层去学容器化基本功镜像构建、数据卷、网络模式、资源限制。重点理解容器如何与宿主机共享内核、隔离资源K8s核心对象Pod、Deployment、Service、ConfigMap、Secret、StatefulSet、DaemonSet、Job/CronJob。每个对象都要问一句它解决了什么问题Pod的完整生命周期从调度、拉镜像、创建容器、健康检查到终止每个阶段在什么条件下触发故障时K8s会做什么、不会做什么。在这个阶段建议多做几轮实验。比如故意把健康检查的探针配错看看Pod是怎么被重启的把多个副本的Deployment部署到不同节点观察滚动更新的过程手动把节点置为不可调度看看上面的Pod会怎么处理。这些实验能帮你建立起对K8s行为的直觉而不是停留在背概念。对于有志于走向大模型方向的人来说这个阶段还有个额外任务装一次GPU驱动的环境在K8s里运行一次nvidia-smi。这不是复杂操作但它会逼你理解设备插件、GPU驱动、容器运行时之间的关系。3.2 第二阶段深入调度器和Operator模式这里才是分水岭普通人用K8s是使用者思维云原生研发工程师要的是平台建设者思维。到了这个阶段重点应该放在两块调度器的扩展机制以及Controller/Operator的开发模式。Kubernetes调度器支持通过扩展点来注入自定义逻辑比如Filter、Score、PreFilter、PostFilter这些阶段。基模公司常常会在这些阶段实现GPU拓扑感知、多级排队、优先级抢占、Backfill等能力。建议找一些开源项目比如Volcano、Kueue这类面向批处理和AI负载的调度器读源码理解它们是如何扩展K8s调度器的。Operator模式也值得花大力气学习。你不需要从零造轮子但应该透彻理解client-go、Informer、WorkQueue、Controller这些核心组件的工作机制搞清楚Watch、List、DeltaFIFO、Indexer之间是怎么配合的。为了练手可以尝试用Operator模式编写一个简单的控制器比如自定义一个App CRD控制器监控App的状态并把相应的Deployment和Service创建出来当App被删除时自动清理关联资源。这一套下来你对K8s的掌控感会有质的飞跃。3.3 第三阶段可观测性与分布式链路云原生世界的眼睛集群规模一大可观测性就变得和调度同样重要。没有完善的监控、日志和链路追踪体系整个集群就是一个黑盒遇到线上问题只能靠猜。技术栈方面常见的组合是Prometheus做指标采集、Grafana做可视化、Loki或ELK做日志聚合、OpenTelemetry做链路追踪。但你需要的不是会部署这些组件而是能回答以下问题当用户反馈API变慢了你如何从监控面板上一层层下钻定位到是网络、容器、应用还是GPU导致的当GPU利用率出现周期性抖动时你要怎么设计告警规则才能在不吵人和不漏报之间找到平衡对于一个训练任务如何从集群层、Pod层、容器层、GPU设备层收集指标并在作业Fail时快速判断是哪个环节出了状况可观测性做得好的平台能让工程师在面对千卡集群时仍然保持冷静。它的本质是把不可见的分布式系统的内部状态变成清晰可见的信号流。这一点基模公司的云原生研发团队非常看重。3.4 别忘了CICD和基础设施即代码工程效率的放大器在基模公司模型迭代速度快基础设施变更频率也非常高。这时候如果没有一套可靠的CICD流程和基础设施即代码实践整个平台的稳定性就会崩溃。GitOps是当前很受青睐的实践Git仓库作为基础设施的唯一事实来源任何变更先提交MR通过自动化的流水线做审核和校验再由控制器自动同步到集群。好处有两个一是变更可追溯、可回滚谁在什么时候改了什么一目了然二是环境一致性有保障测试环境和生产环境通过同一套代码生成显著降低环境不一致导致的问题。工具层面上Terraform、Pulumi负责云资源的声明式管理ArgoCD负责K8s资源的持续同步GitHub Actions或GitLab CI负责自动化测试和构建。这些工具组合起来能让你从手动敲命令运维的泥潭里解放出来专注于更底层的平台能力建设。4. 实战视角如果准备投递这类岗位我会怎么做4.1 简历上真正值钱的项目经验怎么沉淀很多人写简历时会写熟悉Kubernetes掌握云原生技术栈但在基模公司的招聘官眼里这种描述过于泛泛。真正有区分度的表述是你在具体场景中解决过什么问题做出了什么可衡量的结果。比如与其写熟悉K8s调度不如写设计并实现基于拓扑感知的GPU调度器将多机训练任务的平均通信开销降低25%。与其写熟悉CI/CD流程不如写搭建基于GitOps的多环境发布流水线将服务部署时间从40分钟缩短到8分钟。项目经验不一定要来自公司生产环境参与开源项目、自己搭一套模拟集群跑实验同样能沉淀出好的素材。我个人非常推荐的一个练手项目是基于Volcano或Kueue搭建一个支持多租户和GPU资源共享的训练平台。不需要真的有大集群在几台有GPU的工作站上甚至是在云上的几台实例上就能完成。关键是把任务提交、资源队列、抢占调度、失败重试这几个核心链路跑通并记录下来过程中的取舍与踩坑。4.2 面试中大概率会出现的几个考察角度结合我见过的AI基础设施团队面试风格这个岗位的面试大概率会从四个角度考察候选人。第一K8s的原理。常见问题包括Pod调度过程是怎样的StatefulSet和Deployment的区别在哪里描述一下Service的负载均衡机制。这些问题的目的不是考记忆而是看你有没有真正理解K8s的工作模式。第二GPU与AI负载的独特问题。比如假设你有一个8卡节点怎么分配才能让训练性能最优如何解决GPU显存碎片化问题如果训练任务频繁OOM怎么排查。这一部分核心考察你对算力资源的敏感度。第三分布式系统设计。比如设计一个大模型推理服务架构要求支持弹性伸缩和故障恢复怎么设计checkpoint存储才能让训练中断后快速恢复。这些问题没有标准答案面试官想看到的是你能不能在系统层面权衡利弊。第四故障排查实战。对方会给出一个现象的线索链比如线上某服务P99延迟上升排查思路是什么或者是训练任务运行3小时后失败你如何定位原因。这类问题要求你有清晰的排查框架先看全局再缩小范围先看基础设施再怀疑应用。如果你之前没有AI基础设施相关经验也不用慌。面试官更看重的是基础能力和解决问题的思路。云原生本身就是一套工程方法论调度也好、编排也好、容错也好很多经验是可以从通用分布式系统迁移过来的。4.3 为什么AI基础设施 云原生值得作为长期方向最后聊聊方向选择的问题。我在这个行业里见过不少工程师技术能力很强但选择方向时容易陷入短期思维只盯着当前公司用什么、当前趋势在哪。而放到一个更长的周期来看AI基础设施一定是未来五到十年持续投入的领域。原因也很实在大模型的能力迭代不会停止对算力的渴求也不会停止同时算力价格注定要求我们不断提高利用效率。这里面既有硬核的系统问题也有长期的优化空间。云原生恰好是整个AI工程化链条里最标准化的底座你在K8s上沉淀的经验不会因为某个模型的爆火或者某个框架的迭代而被淘汰。反过来看这一波基模公司的云原生岗位对工程师来说也是一个非常难得的机会。在一个算力密度极高、挑战极大的环境里工作两三年你在集群调度、分布式训练、推理优化、故障处理这几个方向的成长速度是在普通业务线公司很难想象的。这也是为什么我跟身边做云原生方向的朋友交流时都会建议他们认真考虑这类机会。如果你已经有了K8s的底子往AI基础设施方向再迈出一步并没有想象中那么难关键是读懂场景理解GPU和分布式训练带来的新问题然后把通用的云原生方法论迁移过去。方向对了能力积累只是一个时间问题。
大模型时代云原生工程师：从K8s到GPU调度的能力跃迁
最近在技术社群刷到一条招聘信息一下子让人停住了目光阶跃星辰国内前沿基模公司正在招聘云原生研发工程师。单独看这条信息似乎只是一次普通的岗位发布但结合行业背景去读里面透露出的信号非常明确——大模型公司在卷完算法和算力之后工程底座已经成为决定上限的关键变量。现在各家基模公司的差距已经不只是模型架构和训练数据更多体现在同样的GPU资源谁能稳定跑出更高的训练效率同样的推理请求洪峰谁能用更少的卡扛住更大的并发。而这一切的背后都和一个角色血肉相连——云原生研发工程师。换句话说在AGI时代的基模公司里云原生已经从曾经的支撑角色变成了核心战斗力。这篇文章我想从这条招聘信息出发拆一拆基模公司的云原生岗位背后的核心技术点、能力要求以及如果你对这个方向感兴趣应该按照什么路径去积累。既送给正在观望这个赛道的朋友也送给想从传统云原生转向AI基础设施方向的工程师。1. 一条招聘启事背后的行业信号从运维支撑到核心底座1.1 基模公司凭什么离不开云原生先明确一下基模的含义。所谓基模公司做的是基础大模型的研发也就是从零训练千亿甚至万亿参数级别的模型然后通过API或开源方式对外输出能力。这类公司的特点非常鲜明第一算力消耗巨大训练任务动辄占用上千张加速卡第二研发迭代快几乎每周都有新的实验要跑第三复杂的分布式体系贯穿全流程数据处理、训练、微调、推理每一步都跑在分布式环境上。传统意义上的运维模式面对这种规模早就失效了。人工登录服务器一台一台配环境、逐个进程守护、手动升级依赖这种操作在单机时代或许还能凑合但在千卡集群面前完全是灾难。云原生带来的是一整套面向大规模分布式系统的设计范式不可变基础设施、声明式API、自动化编排、弹性伸缩、服务发现、可观测性等等。基模公司需要云原生不是因为别人都有K8s所以我也要有而是因为它本质上就是在云原生这套方法论之上才能管理好成千上万台机器组成的超级计算机。1.2 基模公司云原生研发工程师到底在做什么顺着JD往下看这类岗位最核心的职责和解惑可以这样概括建设和管理大规模的Kubernetes集群作为所有训练和推理任务运行的底座设计GPU资源调度方案让算力分配效率最大化减少任务排队和碎片浪费承接分布式训练框架和云原生基础设施之间的衔接比如任务编排、故障恢复、数据缓存加速打造模型推理服务平台支持在线高并发请求下的弹性伸缩与稳定输出构建可观测体系覆盖日志、指标、链路追踪让系统的每一个故障都能被快速定位。你会发现这个岗位干的活远比用K8s部署几个服务要深得多。它要求工程师既懂Kubernetes、容器、网络、存储这些云原生技术又要理解GPU、RDMA、分布式训练框架这些AI基础设施。这也是为什么越来越多基模公司宁愿花高薪招人也不愿意从普通互联网公司随便拉一支云原生团队过来——门槛确实不在K8s本身而在于你是否理解大模型训练和推理场景下如何用好云原生。2. 拆解基模公司云原生岗位的能力地图不只是K8s熟手2.1 GPU调度与算力池化K8s之外的硬门槛绝大多数云原生工程师对容器CPU和内存的调度很熟但到了GPU场景很多人会直接卡住。原因在于GPU这类资源比CPU复杂得多它有显存、有算力、有驱动和CUDA版本依赖还需要考虑通信拓扑。基模公司里的GPU调度第一优先级是最大化利用率。一张A100或者H20级别的卡动辄数十万元如果平均利用率只有三成那浪费的就是真金白银。但利用率又分两个层面一是任务运行期间GPU的实际算力能否跑满二是集群全局视角下任务之间的空隙能不能尽量填满。这就要靠调度策略来实现。调度器常用的策略有两种Binpack和Spread。Binpack倾向于把任务尽量堆叠到少数节点上优点是能空出更多整节点方便承接大的训练任务同时减少节点的碎片化Spread则是把任务铺开优点是能降低单点故障对多个任务的影响缺点是会制造大量碎片。基模公司通常会混合使用针对不同优先级和不同类型的任务走不同的调度策略。此外还有算力池化的话题。GPU共享、MIG切分、显存与算力隔离都是在底层芯片能力基础上做精细化切蛋糕的手段。一个推理服务可能只需要半张卡的算力如果整卡分配另一半就白白闲置。这里的核心技术包括时间片调度、显存隔离、算力限额等每一层都需要云原生研发工程师深入到底层去调优。再往下还有拓扑感知。分布式训练非常在意GPU之间的通信延迟数据并行时每个Step都要做梯度同步如果梯度聚合发生跨机通信走的是PCIe或网络延迟会比NVLink高出很多倍。调度器如果能把一个训练任务的多卡尽量分配到同一台机器上并选择拓扑最优的那几块卡训练吞吐的差距可能体现在百分之几十的量级上。很多公司甚至为了这个诉求会自己开发调度器插件或者直接改造Kubernetes的调度逻辑。2.2 分布式训练的容错与编排从单机思维切换到集群思维如果说GPU调度是地基那分布式训练的容错和编排就是主体框架。单机训练任务跑挂了大不了重来千卡集群上跑着一个周期数周的预训练任务如果中间某个节点坏了导致整个任务回滚到几轮之前那就是灾难级的资源浪费。这里的关键技术之一是弹性容错。业界的主流做法是周期性地保存checkpoint把模型权重、优化器状态、训练步数等信息固化到持久化存储中。训练过程中一旦有节点故障调度系统自动摘除故障节点、重新拉起新节点然后从最近一次checkpoint恢复训练。听起来简单实际上非常考验系统设计能力checkpoint怎么高效地写几百GB甚至上TB的权重数据如何在几分钟内完成落盘并避免影响训练性能怎么处理部分完成、部分失败的checkpoint写入这些都是在K8s之上做Operator时需要花大量心思解决的问题。任务编排层面也一样。在大模型训练中一个任务往往不是简单的一个Pod而是一个包含worker和ps的分布式拓扑。Kubernetes原生调度对这类作业的支持并不完善于是就有了各种自定义Controller和Operator。它们负责管理和维护训练作业的全生命周期创建时按照拓扑要求调度资源运行中持续监控健康状态与通信情况异常时自动做故障转移。这套编排逻辑是否合理直接决定了训练团队能否把精力集中在模型本身而不是天天折腾基础设施。另外训练任务往往会用上高性能网络比如RDMA和InfiniBand。这类网络和普通以太网最大的不同是它走的是RDMA协议数据从一台机器的GPU显存直接到达另一台机器的GPU显存跳过内核协议栈延迟和CPU开销都能大幅降低。但在K8s环境里接入RDMA就会涉及网卡直通、网络命名空间配置、路由规则等一系列复杂问题。这些都不是开箱即用的标准K8s能力需要云原生研发工程师做大量的定制化开发。2.3 推理系统的弹性伸缩在线场景对云原生的新考验训练场景是离线任务对延迟不敏感突发重来最多是浪费算力但推理场景是完全不一样的性质它的延迟直接决定用户体验。基模公司一旦对外开放模型API线上就会有无穷无尽的请求压过来而且请求模式很不均匀高峰和低谷之间的流量差距可能非常大。传统的HPA弹性伸缩在这种场景下往往不够用原因在于模型加载一次需要较长的时间几十GB的权重加载到显存可能要几十秒甚至分钟级。如果等到CPU指标上来再扩容用户的请求已经从网关层开始超时了。这就逼着云原生平台做出更多预判式、资源预留式的推理架构。常见的做法包括常驻一个基础规模的实例池保证最小的服务能力同时在流量预见上涨时提前扩容再配合请求级的路由策略和队列背压机制保证已有的伸缩实例不至于被冲垮。推理服务的另一大特点是GPU显存是稀缺资源。在线推理场景下动态Batching、PagedAttention这类技术可以从算法和应用层面提升显存利用效率但底层依然需要云原生平台提供精细的资源调度。不同模型、不同版本的推理副本之间怎么做混部一个实例故障后流量怎么平滑切换GPU实例的热升级如何做到不中断在线服务每一件事都需要云原生研发工程师去设计、开发、压测和调优。3. 云原生核心技术栈自学路线看懂需求更要看懂为什么3.1 第一阶段容器和Kubernetes别只停留在会用如果你连Docker和Kubernetes的基本操作都还不熟那第一步就是把它们从会启动一个容器推进到理解设计思想的层面。可以这样分层去学容器化基本功镜像构建、数据卷、网络模式、资源限制。重点理解容器如何与宿主机共享内核、隔离资源K8s核心对象Pod、Deployment、Service、ConfigMap、Secret、StatefulSet、DaemonSet、Job/CronJob。每个对象都要问一句它解决了什么问题Pod的完整生命周期从调度、拉镜像、创建容器、健康检查到终止每个阶段在什么条件下触发故障时K8s会做什么、不会做什么。在这个阶段建议多做几轮实验。比如故意把健康检查的探针配错看看Pod是怎么被重启的把多个副本的Deployment部署到不同节点观察滚动更新的过程手动把节点置为不可调度看看上面的Pod会怎么处理。这些实验能帮你建立起对K8s行为的直觉而不是停留在背概念。对于有志于走向大模型方向的人来说这个阶段还有个额外任务装一次GPU驱动的环境在K8s里运行一次nvidia-smi。这不是复杂操作但它会逼你理解设备插件、GPU驱动、容器运行时之间的关系。3.2 第二阶段深入调度器和Operator模式这里才是分水岭普通人用K8s是使用者思维云原生研发工程师要的是平台建设者思维。到了这个阶段重点应该放在两块调度器的扩展机制以及Controller/Operator的开发模式。Kubernetes调度器支持通过扩展点来注入自定义逻辑比如Filter、Score、PreFilter、PostFilter这些阶段。基模公司常常会在这些阶段实现GPU拓扑感知、多级排队、优先级抢占、Backfill等能力。建议找一些开源项目比如Volcano、Kueue这类面向批处理和AI负载的调度器读源码理解它们是如何扩展K8s调度器的。Operator模式也值得花大力气学习。你不需要从零造轮子但应该透彻理解client-go、Informer、WorkQueue、Controller这些核心组件的工作机制搞清楚Watch、List、DeltaFIFO、Indexer之间是怎么配合的。为了练手可以尝试用Operator模式编写一个简单的控制器比如自定义一个App CRD控制器监控App的状态并把相应的Deployment和Service创建出来当App被删除时自动清理关联资源。这一套下来你对K8s的掌控感会有质的飞跃。3.3 第三阶段可观测性与分布式链路云原生世界的眼睛集群规模一大可观测性就变得和调度同样重要。没有完善的监控、日志和链路追踪体系整个集群就是一个黑盒遇到线上问题只能靠猜。技术栈方面常见的组合是Prometheus做指标采集、Grafana做可视化、Loki或ELK做日志聚合、OpenTelemetry做链路追踪。但你需要的不是会部署这些组件而是能回答以下问题当用户反馈API变慢了你如何从监控面板上一层层下钻定位到是网络、容器、应用还是GPU导致的当GPU利用率出现周期性抖动时你要怎么设计告警规则才能在不吵人和不漏报之间找到平衡对于一个训练任务如何从集群层、Pod层、容器层、GPU设备层收集指标并在作业Fail时快速判断是哪个环节出了状况可观测性做得好的平台能让工程师在面对千卡集群时仍然保持冷静。它的本质是把不可见的分布式系统的内部状态变成清晰可见的信号流。这一点基模公司的云原生研发团队非常看重。3.4 别忘了CICD和基础设施即代码工程效率的放大器在基模公司模型迭代速度快基础设施变更频率也非常高。这时候如果没有一套可靠的CICD流程和基础设施即代码实践整个平台的稳定性就会崩溃。GitOps是当前很受青睐的实践Git仓库作为基础设施的唯一事实来源任何变更先提交MR通过自动化的流水线做审核和校验再由控制器自动同步到集群。好处有两个一是变更可追溯、可回滚谁在什么时候改了什么一目了然二是环境一致性有保障测试环境和生产环境通过同一套代码生成显著降低环境不一致导致的问题。工具层面上Terraform、Pulumi负责云资源的声明式管理ArgoCD负责K8s资源的持续同步GitHub Actions或GitLab CI负责自动化测试和构建。这些工具组合起来能让你从手动敲命令运维的泥潭里解放出来专注于更底层的平台能力建设。4. 实战视角如果准备投递这类岗位我会怎么做4.1 简历上真正值钱的项目经验怎么沉淀很多人写简历时会写熟悉Kubernetes掌握云原生技术栈但在基模公司的招聘官眼里这种描述过于泛泛。真正有区分度的表述是你在具体场景中解决过什么问题做出了什么可衡量的结果。比如与其写熟悉K8s调度不如写设计并实现基于拓扑感知的GPU调度器将多机训练任务的平均通信开销降低25%。与其写熟悉CI/CD流程不如写搭建基于GitOps的多环境发布流水线将服务部署时间从40分钟缩短到8分钟。项目经验不一定要来自公司生产环境参与开源项目、自己搭一套模拟集群跑实验同样能沉淀出好的素材。我个人非常推荐的一个练手项目是基于Volcano或Kueue搭建一个支持多租户和GPU资源共享的训练平台。不需要真的有大集群在几台有GPU的工作站上甚至是在云上的几台实例上就能完成。关键是把任务提交、资源队列、抢占调度、失败重试这几个核心链路跑通并记录下来过程中的取舍与踩坑。4.2 面试中大概率会出现的几个考察角度结合我见过的AI基础设施团队面试风格这个岗位的面试大概率会从四个角度考察候选人。第一K8s的原理。常见问题包括Pod调度过程是怎样的StatefulSet和Deployment的区别在哪里描述一下Service的负载均衡机制。这些问题的目的不是考记忆而是看你有没有真正理解K8s的工作模式。第二GPU与AI负载的独特问题。比如假设你有一个8卡节点怎么分配才能让训练性能最优如何解决GPU显存碎片化问题如果训练任务频繁OOM怎么排查。这一部分核心考察你对算力资源的敏感度。第三分布式系统设计。比如设计一个大模型推理服务架构要求支持弹性伸缩和故障恢复怎么设计checkpoint存储才能让训练中断后快速恢复。这些问题没有标准答案面试官想看到的是你能不能在系统层面权衡利弊。第四故障排查实战。对方会给出一个现象的线索链比如线上某服务P99延迟上升排查思路是什么或者是训练任务运行3小时后失败你如何定位原因。这类问题要求你有清晰的排查框架先看全局再缩小范围先看基础设施再怀疑应用。如果你之前没有AI基础设施相关经验也不用慌。面试官更看重的是基础能力和解决问题的思路。云原生本身就是一套工程方法论调度也好、编排也好、容错也好很多经验是可以从通用分布式系统迁移过来的。4.3 为什么AI基础设施 云原生值得作为长期方向最后聊聊方向选择的问题。我在这个行业里见过不少工程师技术能力很强但选择方向时容易陷入短期思维只盯着当前公司用什么、当前趋势在哪。而放到一个更长的周期来看AI基础设施一定是未来五到十年持续投入的领域。原因也很实在大模型的能力迭代不会停止对算力的渴求也不会停止同时算力价格注定要求我们不断提高利用效率。这里面既有硬核的系统问题也有长期的优化空间。云原生恰好是整个AI工程化链条里最标准化的底座你在K8s上沉淀的经验不会因为某个模型的爆火或者某个框架的迭代而被淘汰。反过来看这一波基模公司的云原生岗位对工程师来说也是一个非常难得的机会。在一个算力密度极高、挑战极大的环境里工作两三年你在集群调度、分布式训练、推理优化、故障处理这几个方向的成长速度是在普通业务线公司很难想象的。这也是为什么我跟身边做云原生方向的朋友交流时都会建议他们认真考虑这类机会。如果你已经有了K8s的底子往AI基础设施方向再迈出一步并没有想象中那么难关键是读懂场景理解GPU和分布式训练带来的新问题然后把通用的云原生方法论迁移过去。方向对了能力积累只是一个时间问题。
