最近和几个做后端的朋友聊天发现一个很有意思的变化去年大家还在讨论怎么把微服务拆得更细、怎么把高并发压测做漂亮今年好几个人已经把简历方向改成了“AI Infra”“云原生工程师”这类关键词。大模型公司也正好在抢这批人。我注意到国内一家做基础模型基模的前沿公司——阶跃星辰最近放出了云原生研发工程师的招聘需求。这个岗位放在五年前可能只是常规运维开发但在基础模型公司里它直接关系到万亿参数模型能不能稳定训练、能不能低成本对外提供服务。这篇文章就顺着这个招聘信息把云原生研发工程师在基模公司里的价值、日常、技术栈和面试重点全部拆开讲一遍。我尽量说人话不堆概念适合三类人看正在考虑要不要投这类岗位的后端/运维同学已经在大模型公司但搞不清基础设施团队在做什么的人以及单纯好奇“云原生到底怎么跟大模型产生关系”的技术爱好者。1. 基模公司为什么要养云原生研发工程师1.1 从“炼一次模型”到“运营一套模型系统”过去大家理解大模型公司第一反应是“一堆算法大牛在调模型”。但真正走到对外提供API服务、把模型能力卖给企业和开发者的时候事情就完全变了。训练一个千亿甚至万亿参数的基础模型不是在一台机器上跑个Python脚本的事而是几百张GPU卡同时工作、连续跑几周甚至几个月的系统工程。这段时间里任意一张卡出故障、任意一条网络链路抖动、任意一次存储读写超时都可能导致整个训练任务中断。哪怕有checkpoint机制一次失败恢复也要浪费少则几十分钟、多则几个小时的计算时间。更别提训练完成后还要把模型高效地部署成在线服务扛住随时波动的用户请求。这些事没有扎实的云原生底座根本撑不起来。所以基模公司养云原生研发工程师核心目标就一句话让整个AI系统像一台稳定的超级计算机一样运转。算法工程师只负责提需求和看结果中间所有的资源分配、任务调度、故障恢复、性能优化全是云原生工程师的活。换个更好懂的比喻算法团队是厨师负责研究菜谱和味道云原生工程师是厨房里的水电煤气系统设计者。厨师水平再高灶台总憋火、水管老爆裂这餐厅也开不下去。1.2 这个岗位和传统云原生工程师有什么区别传统互联网公司的云原生工程师面对的核心对象是大量无状态服务。用户请求进来多个副本平均分摊任何一个Pod挂了自动拉起一个新的业务无感。整个系统天然适合Kubernetes那套“声明式状态、控制器调谐”的模型。但大模型场景下的训练任务完全不同它是典型的长时高吞吐单体任务。一个训练任务可能占着64张卡跑半个月中途不能随便重启不能像Web服务那样随意扩缩容。这和云原生理论课上教的“小步快跑、弹性伸缩”几乎是反着来的。这就导致一个认知冲突很多传统云原生工程师刚接触AI集群时非常不适应拿Web服务的思路去套训练任务结果处处碰壁。真正能干好的人既要懂Kubernetes也要理解深度学习框架的原理还要知道GPU硬件层面的显存、NVLink拓扑、RDMA通信这些底层细节。在我看来传统云原生工程师和AI场景下的云原生研发工程师最大的区别在于“管的东西多了两层”多了GPU这种异构计算资源多了分布式训练/推理这套AI专用工作负载。这也正是这个岗位虽然门槛高但价值也高的原因。1.3 从招聘JD看这类岗位的真实定位虽然我没有看到阶跃星辰这份招聘的完整JD但根据这类岗位的行业惯例要求通常集中在几个方向扎实的Kubernetes功底熟悉调度器、控制器、CRD开发大规模GPU集群的运维和调优经验熟悉主流的分布式训练框架比如Megatron-LM、DeepSpeed对推理服务有了解用vLLM、SGLang、TensorRT-LLM这类东西部署过模型熟悉GPU、RDMA、高性能存储等底层硬件从这些要求就能看出来这个岗位不是普通运维也不是纯业务后端而是介于两者之间的平台研发。它更像是一个“面向AI的计算操作系统工程师”自己不一定训练模型但要为训练和推理搭建最好的运行环境。这类岗位在组织架构里通常属于基础架构部或者AI平台部级别和薪资对标后端高级研发工程师但在稀缺性上更高。因为传统后端人才很多同时精通Kubernetes、GPU、分布式训练的人才市场上是真没几个。2. 大模型场景下云原生工程师要掌握什么一张技术栈地图2.1 基础设施层GPU、RDMA网络与高性能存储往最底层看第一件事是把GPU集群管起来。GPU在这里不光是“一块能算数的卡”而是有显存、有SM核心、有NVLink高速互联的复杂设备。训练大模型时数据并行、张量并行、流水线并行会把计算任务切开分布在多张卡上每张卡之间需要频繁同步梯度这时候卡间的通信带宽直接决定训练效率。所以你会看到大模型集群标配InfiniBand或者RoCE网络带宽跑到400Gbps甚至更高。云原生研发工程师得理解这些网络的基本原理至少要知道为什么两个节点之间的通信延迟会飘为什么网卡降速会导致整个训练任务变慢。存储也一样。训练过程中产生的checkpoint文件动辄几十GB甚至上TB读写频率并不高但一旦写失败就是大事故。高性能并行文件系统比如Lustre、GPFS在这里比普通对象存储更有用。云原生工程师要把这些存储挂给Kubernetes里的Pod使用同时做好容量规划、IO隔离和备份策略。说真的这一层最考验经验也最出事故。很多训练任务跑崩不是代码问题而是底层网络闪断、存储写入超时这类基础设施问题。2.2 资源调度层Kubernetes在AI场景下的二次开发Kubernetes本身是个优秀的平台但直接用原版K8s跑AI训练任务会踩到一堆坑。原因很直接K8s默认是为无状态Web服务设计的对GPU这种稀缺资源支持得并不够精细。这就要做二次开发了。常见工作包括自定义调度器当用户提交流程要求“我要64张卡”系统要考虑这些卡是不是在同一个交换机下能不能组成一个高性能通信域而不是随便挑64张空闲卡。优先级和抢占几百个算法工程师同时提任务谁的训练任务更紧急低优先级的任务能不能被高优先级任务抢走资源这些都需要策略支持。资源隔离一张A100显卡默认只能整体分配但实际很多推理场景用不满。这时就要做GPU虚拟化或者时间片共享把一张卡切成多个逻辑资源提高利用率。这些能力光靠K8s原生配置是搞不定的还需要写CRD、开发Controller、扩展调度器插件。这恰恰是这个岗位“研发含量”最高的地方。用一个不严谨但好懂的说法别人用Kubernetes是点鼠标配置你在这个岗位上是给Kubernetes“打补丁”让它能适配大模型场景。2.3 训练平台层让分布式训练稳定可恢复训练任务一旦跑起来云原生工程师要考虑的事情就变成怎么让它别挂挂了怎么快速恢复。分布式训练框架Megatron-LM和DeepSpeed都有自己的容错机制但在集群层面还需要一套完整的任务管理平台。算法工程师提交一个训练任务平台要负责创建Pod、分配资源、监控状态如果任务异常退出要判断是代码问题还是环境问题是否自动重跑是否从最近一个checkpoint断点续训。这一块我见过太多血泪教训。有人写了个训练任务没有设置checkpoint保存间隔跑了三天一声OOM全部归零。有人设置了checkpoint但保存到了本地磁盘Pod一重建权重全没了。云原生工程师要做的就是把这些失误变成不可能checkpoint强制走共享存储任务失败自动检测并重新排队恢复时自动加载最新版本。还有一个容易被忽略的点训练任务的日志和指标。几十张卡同时跑任何一张卡有异常都要能快速定位。日志收集、指标监控、链路追踪这些可观测性设施在这里不是锦上添花是必需品。2.4 推理服务层把大模型变成高可用在线服务训练只是前半段模型最终要对外提供服务。推理服务跟训练任务又不一样它对延迟非常敏感用户发一句话系统必须在一两秒内返回结果。推理场景的一个主流方案是vLLM它通过PagedAttention和连续批处理技术大幅提升GPU利用率。对云原生工程师来说要把这类推理引擎容器化、部署到Kubernetes上配置好自动扩缩容策略让服务在请求高峰时快速增加副本在低谷时缩容节省资源。这里有一个容易被外行忽视的细节推理服务不是“实例多了就一定更快”。大模型推理非常依赖GPU显存每个请求都要占用显存空间存储KV Cache。实例多了单个请求的排队延迟可能下降但显存碎片和通信开销也会上升。所以扩容策略不是简单看CPU使用率而要综合看显存占用率、请求队列长度、P99延迟等多维指标。还有模型版本的灰度发布。新模型上线前得先让一部分流量跑新版本对比效果和延迟确认没问题再全量切过去。这套流程和互联网公司发布微服务很像但背后的技术复杂度高很多因为模型加载要占大显存一个实例起停一次都是几分钟级别的操作。2.5 可观测性没有监控AI集群就是一坨黑盒一个几百卡的AI集群跑着几十个训练任务和上百个推理服务如果没有完善的监控系统出问题时就像在漆黑的房间里找一根掉在地上的针。GPU监控要用DCGM这类工具采集利用率、显存占用、温度、功耗。网络监控要看RDMA的丢包率、重传率、带宽。训练任务监控要看吞吐量、loss是否收敛、梯度是否出现异常。再往上业务侧的请求量、延迟、成功率也要全链路打通。云原生工程师在这里的核心能力是“建立监控体系”和“看懂监控数据”。不是装个Prometheus、配个Grafana面板就完事了而是要能通过指标定位问题链路。我遇到过一次训练效率突然下降的情况查了一圈发现是某台机器的GPU因为温度过高主动降频导致整个训练任务被拖慢。没有温度监控这个问题可能要看几天日志才能找到原因。3. 岗位日常解密云原生研发工程师在大模型公司实际做什么3.1 训练任务的生命周期管理从提交流程到故障恢复如果你加入这样的团队会发现日常工作和“写业务接口”完全两样。核心任务是管理训练任务的生命周期我用一个实际场景说明。算法同事提交了一个需求“我要训练一个千亿参数模型预计需要64张A100跑两周。”你的工作从接到这个需求就开始了。先看集群当前资源确认是否有64张卡连在同一个高性能网络域内。如果没有就得调度碎片资源或者等前面的任务释放。任务开始后要监控运行状态。第一个冒出来的问题往往是OOM。除了显存溢出还有可能是CPU内存不够。这时需要快速判断并调整Pod的资源配额或者指导算法同事优化数据加载。假设跑到第三天一台机器突然宕机。调度系统检测到后自动触发重启策略新Pod起来后从最近的checkpoint恢复训练。你要做的是确认恢复动作正常执行同时把故障节点的业务流量摘掉避免再次中断。这个流程里没有“写代码”的环节但每一个动作背后都是代码和平台在支撑。这就是研发工程师和运维的区别运维盯的是单次故障研发做的是让故障自动恢复的机制。3.2 推理服务上线容量预估、压测与自动扩缩容模型训练完成要部署上线做推理服务这是另一个高频场景。工程师先要根据模型大小做容量预估。随便算一笔账一个70亿参数的模型以FP16精度加载光权重就要占约14GB显存。如果输入长度比较长每个请求还要额外占用KV Cache假设平均每个请求占2GB显存一张80GB显存的A100能同时处理的并发请求大概就是二十几个。这个数字直接决定服务的副本数和扩容策略。接下来是压测。用压测工具模拟线上流量观察P99延迟和GPU利用率。如果延迟超标先看是不是显存不够导致排队还是模型算子没优化好甚至网络带宽成为瓶颈。压测通过后要配上自动扩缩容策略。我见过一个比较合理的配置以GPU利用率为主要扩缩容指标同时参考请求队列深度。繁忙时5分钟拉起来4到5个新副本闲时自动缩回去把GPU资源释放给训练任务。实际部署到Kubernetes时发布配置大概是这个思路apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference namespace: ai-service spec: replicas: 4 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: containers: - name: vllm-server image: registry.example.com/llm/vllm:latest resources: limits: nvidia.com/gpu: 1 memory: 128Gi requests: nvidia.com/gpu: 1 memory: 96Gi ports: - containerPort: 8000这份配置看着简单实际生产中还有一堆细节探针怎么设、优雅退出怎么处理、缓存目录挂载到哪、模型权重从哪里加载、是否要开启GPU虚拟化共享。每一点都踩过坑。3.3 成本治理GPU那么贵钱到底花在哪大模型公司的成本大头就是GPU。一张高端的训练卡报价几万甚至几十万集群里几百张卡一天的折旧加电费就是天文数字。云原生研发工程师要背的一个关键指标是GPU利用率。我见过不少公司GPU平均利用率只有30%到50%大量算力都浪费在等待和碎片上。提高利用率的常见手段有这么几种优先级抢占让紧急的在线推理任务优先于离线批量任务GPU共享把推理场景用不满的卡切分成多份分给多个小模型使用弹性混部训练任务和推理任务错峰使用同一批GPU碎片整理定期把稀疏的小任务合并腾出完整的节点给大任务使用做这方面工作光凭直觉不行得有数据支撑。每个GPU卡每个小时的利用率、显存占用、处在哪个任务、空闲了多久都要监控得清清楚楚。我曾经写过一个报告工具每天自动汇总各项目的GPU消耗和利用率推送给各个团队负责人。效果立竿见影过去那种“任务挂了三天没人发现GPU白白烧着”的情况几乎绝迹。3.4 和算法团队的分工边界你不是调参的你管厨房还有个新同学容易困惑的问题我是研发工程师要不要也去看看模型的loss、改改超参数我的建议是不要。一个优秀的云原生研发工程师边界感要清楚。算法同事负责模型效果好你负责他们跑得稳、跑得快。你的KPI不是模型指标涨了而是任务调度成功率、GPU利用率、故障恢复时间、推理服务的SLA这几个数字。但这并不意味着你可以不懂模型训练。恰恰相反你越理解算法团队在做什么越能提前预判他们的需求。比如你知道吴系列模型在做多模态实验数据加载量特别大就提前把数据缓存、IO带宽准备好。你知道推理服务要支持流式输出就提前验证负载均衡器是否能hold住长连接。这就像厨师和厨具工程师的关系厨师不用会修灶台但灶台设计师得知道厨师做菜的火候习惯。4. 面试重点与研发岗辨析这到底算不算“研发”4.1 面试到底面什么一份可以照着准备的清单如果你正在考虑投递面试准备方向可以按这个优先级来。第一层Kubernetes基础。源码级理解不要求但调度器工作原理、控制器模式、CRD机制这些必须熟。面试官会问创建一个Pod到运行起来中间经历了什么自定义调度器要如何接入PV和PVC的绑定流程是什么这些问题答不好后面基本没戏。第二层GPU和AI训练的基础知识。Diffusion模型训练和LLM训练对资源的需求有什么不同什么是数据并行、张量并行、流水线并行为什么要用NVLink和RDMA这些不要求你会调模型但要知道大体原理。第三层推理服务架构。vLLM的核心优势是什么为什么大模型推理需要连续批处理KV Cache对显存的影响有多大部署一个推理服务怎么压测、怎么扩缩容第四层系统设计场景题。给你一个几十人的算法团队要在一个500卡GPU集群上跑训练任务平台架构怎么设计这类题目没有标准答案考的是你的全局观和落地能力。回答时从资源池化、调度策略、容错恢复、成本监控几个维度展开就能体现出经验。4.2 顺带聊聊热搜芯片验证工程师算研发岗吗最近有个热搜词是“芯片验证工程师是研发岗吗”我从职业角度多说两句。芯片验证工程师当然是研发岗它和云原生研发工程师一样都是研发体系的组成部分。只是因为验证工作不像“写业务代码”那么直观容易被误解“是不是做测试的”。实际上芯片验证工程师要写SystemVerilog、搭UVM验证平台、做覆盖率分析工作量和技术含量一点不比设计工程师低只是做的事情是“证明设计是对的”。这类讨论背后有个共同点研发岗的类型正在变得越来越多样。过去一说研发大家默认是写Java/Python做业务。现在AI、芯片、基础设施都成为研发岗的重要分支。云原生研发工程师同样面临这样的误解——有人觉得就是运维其实它是写代码、设计系统、做架构的纯正研发岗。一个岗位是不是研发不看它有没有在“写业务”而看它是否在“创造和改造复杂的系统”。4.3 想转这个方向三条切实可行的路径如果你想从传统后端或者运维转过来我建议走这三条路。第一条路是“先玩转Kubernetes”。别只停留在看文档和考CKA证书的层面自己搭一个包含GPU节点的集群试着调度一个需要GPU的Pod再用kubectl排查故障。把K8s用熟了后面的路就好走了。第二条路是“把一个大模型跑起来”。找一台消费级显卡用vLLM部署一个开源模型做一次压测看看吞吐量和延迟是多少。再试着手写一个自动扩缩容策略模拟流量波动。这个过程会把推理服务的所有关键概念都过一遍。第三条路是“研究一个真实的调度问题”。比如去读Kubernetes调度器的源码看看它是如何给Pod选节点的。然后思考一个问题如果一个训练任务要求4张卡必须在同一个节点上该怎么实现思路比答案重要能体现你的工程嗅觉。5. 一些个人观察和经验5.1 我在这个方向看到的机会从大环境看基础模型公司的竞争已经从前两年的“拼算法拼效果”慢慢进入“拼工程拼成本”的阶段。模型能力大家都在追赶谁能把训练成本降得更低、把推理服务做得更稳定谁就能在商业上占优势。而这一切恰好都需要云原生研发工程师去实现。我认识几个从传统后端转到AI Infra方向的工程师普遍反馈是做的事更有挑战性了接触的技术栈更深了在组织里的话语权也明显提高。毕竟你管的是公司最贵的资产GPU集群的每一分利用率和成本都看得见摸得着。当然这个方向的坑也不少。技术迭代太快今天的主流框架明天可能就被替代知识体系庞杂硬件、网络、分布式、AI要全沾压力也大训练集群一出问题全公司都在等你恢复。但正因为有门槛这个岗位才不太容易被替代含金量也更扎实。5.2 最后几个简历和面试的小建议最后给大家一些比较实在的建议。简历上不要只写“熟悉Kubernetes”要写你具体做了什么比如“自研了基于拓扑感知的GPU调度插件使训练任务平均排队时间降低40%”这类有数据支撑的成果。面试时不要背概念面试官更愿意听到你解决真实问题的过程当时遇到了什么现象怎么定位的最后做了什么变更效果如何。还有一个很加分的动作自己写一个开源小项目比如一个简单的Operator或者调度器插件放到GitHub上。哪怕功能很简单也能证明你有动手能力。这个行业不缺会纸上谈兵的人缺的是真正能把事情落地的人。如果你正好在看机会或者刚开始转入这个方向欢迎在评论区聊聊你遇到的问题。我踩过的坑大概率也能帮你少走一点弯路。