主题
K8s 开发工程师(ML 平台方向)- 面试手册
基于 JD:MiniMax 机器学习平台设计开发、大模型训练任务调度、K8s 控制器与调度器研发、PyTorch/Ray/Megatron 等框架适配、GPU/NPU/ARM 异构计算、RDMA 高性能网络、训练指标观测。
一、岗位核心能力画像
| 维度 | 重点 |
|---|---|
| 开发能力 | 精通 Go/Python,扎实编程基础,良好代码风格与工程习惯 |
| K8s 深度 | 控制器、调度器研发,大规模训练任务编排、在离线混部 |
| AI/ML 平台 | 模型数据处理、预训练、SFT、RL 各阶段任务调度与稳定运行 |
| 训练框架 | PyTorch、Ray、Megatron 等分布式训练框架支持与适配 |
| 基础设施 | GPU/NPU/ARM 异构计算、RDMA 高性能网络、资源效率与成本优化 |
| 可观测性 | 训练指标上报、存储、观测 |
二、高频面试问题与回答思路
2.1 编程基础与工程能力
Q1:你最擅长 Go 还是 Python?各自在大模型平台中的应用场景?
- Go:K8s 控制器、调度器、Operator、平台服务端、API Gateway
- Python:训练脚本、数据处理、与 ML 框架(PyTorch/TensorFlow)集成、实验管理
- 平台底层基础设施多用 Go,算法与训练逻辑多用 Python
Q2:如何保证大规模系统的代码质量?
- 单元测试、集成测试、端到端测试
- Code Review、Lint、CI 流水线
- 日志规范、错误处理、可观测性
- 模块化设计、接口抽象、避免硬编码
Q3:Go 的内存模型与 GC 调优经验?
- 避免内存泄漏:注意 Goroutine、Channel、循环引用
- 减少 GC 压力:对象复用、sync.Pool、减少小对象分配
- pprof 分析内存与 CPU 瓶颈
Q4:Python 在训练任务中的性能优化?
- 多进程替代多线程绕过 GIL
- 使用 NumPy/Pandas/Arrow 做向量化计算
- 数据预取与流水线(PyTorch DataLoader num_workers/pin_memory)
- 使用 Cython/Numba 加速热点代码
2.2 Kubernetes 控制器与调度器
Q5:K8s 控制器的工作原理?
- 基于 List-Watch 机制监听资源变化
- Informer 维护本地缓存,WorkQueue 处理事件
- Reconcile 调谐:比较期望状态与实际状态,执行差异动作
- 幂等性、错误重试、优雅关闭
Q6:如何开发一个自定义 K8s 调度器?
- 方案一:扩展默认调度器(Scheduler Framework 插件)
- Filter、Score、Reserve、Permit、Bind 等扩展点
- 方案二:独立调度器
- 监听 Pod,实现调度逻辑,调用 Bind API
- 指定 Pod 的
schedulerName
- 考虑 Gang Scheduling、Topology Aware、资源预留等场景
Q7:Gang Scheduling 在大模型训练中为什么重要?如何实现?
- 训练任务通常需要多个 Pod 同时启动(All-Reduce 同步)
- 避免部分 Pod 调度成功导致任务死锁或资源浪费
- 实现方式:
- Volcano 的 PodGroup
- Kube-scheduler-scheduler-plugins 的 Coscheduling
- 自研调度器维护 PodGroup 状态
Q8:如何优化 K8s 调度器性能?
- 减少无效调度循环
- 节点预选缓存优化
- 并行打分
- 调度热点 Pod 分类
- 调度决策缓存与批处理
Q9:K8s Operator 在大模型平台中的作用?
- 抽象训练任务:TrainingJob、FineTuneJob、RLJob
- 管理任务生命周期:创建、监控、弹性扩缩容、失败重试、清理
- 集成存储、网络、监控、日志
- 实现故障自愈与资源回收
2.3 大模型训练任务编排
Q10:大模型训练(预训练/SFT/RL)的任务特点?
- 长周期运行(数小时到数周)
- 高资源需求(多机多卡 GPU)
- 强同步依赖(All-Reduce/All-to-All)
- 对网络、存储、 checkpoint 有高要求
- 容错与断点续训重要
Q11:PyTorch Distributed 常见通信后端?
- NCCL:NVIDIA GPU 最优选择,支持多机多卡
- Gloo:CPU 训练或没有 NCCL 的环境
- MPI:超大规模集群
Q12:Megatron、DeepSpeed、FSDP 的区别?
| 框架 | 特点 |
|---|---|
| Megatron | NVIDIA 出品,支持 Tensor Parallel、Pipeline Parallel、Sequence Parallel |
| DeepSpeed | 微软出品,ZeRO 系列优化、Offload、3D Parallelism |
| FSDP | PyTorch 原生,易用,数据并行 + 参数分片 |
Q13:Ray 在大模型训练中的作用?
- 分布式计算框架,支持训练、推理、数据处理、超参搜索
- Ray Train 封装多种分布式训练后端
- Ray Cluster Autoscaler 动态扩缩容
- 与 K8s 集成:KubeRay Operator
Q14:训练任务失败如何自动恢复?
- Checkpoint 机制:定期保存模型状态
- 失败后根据 checkpoint 重启
- 使用 RestartPolicy、BackoffLimit
- 监控异常指标(loss 突增、梯度爆炸、NCCL 超时)
- 节点/卡故障自动迁移
2.4 资源效率与成本优化
Q15:什么是在离线混部?如何落地?
- 在线服务(低延迟敏感)与离线训练(高吞吐)共享集群资源
- 利用潮汐资源,提高整体利用率
- 关键能力:
- 资源隔离(CPU/Memory/IO/网络 QoS)
- 优先级抢占与驱逐
- 动态资源调度
- 干扰检测与规避
Q16:GPU 利用率低的原因及优化手段?
- 原因:数据加载瓶颈、通信等待、小 batch、任务间隙
- 优化:
- 数据流水线优化
- 增大 batch size / 梯度累积
- 通信优化(NCCL 调参、拓扑感知)
- 多任务共享 GPU(MIG/MPS)
- 自动扩缩容与任务合并
Q17:如何降低大模型训练成本?
- 在离线混部提升资源利用率
- 使用抢占式/Spot 实例
- 自动弹性扩缩容
- 混合精度训练(FP16/BF16)
- 模型并行策略优化
- Checkpoint 与故障恢复减少重复计算
- 调度策略减少资源碎片
2.5 异构计算与高性能网络
Q18:GPU/NPU/ARM 在大模型场景中的差异?
- GPU:NVIDIA 生态成熟,CUDA/NCCL 主流
- NPU:华为昇腾等,需适配 CANN 生态,适合国产化场景
- ARM:能效比高,适合推理与边缘,软件生态逐步完善
- 平台需抽象异构资源调度与框架适配
Q19:RDMA 为什么对大模型训练重要?
- 低延迟、高带宽、CPU offload
- 常用于多机 GPU 训练
- 方案:RoCEv2、InfiniBand
- 需配合 GPUDirect RDMA 进一步降低延迟
Q20:K8s 中如何暴露和管理 GPU/RDMA 资源?
- GPU:NVIDIA Device Plugin + GPU Feature Discovery
- RDMA:RDMA Shared Device Plugin / SR-IOV Device Plugin
- 网络拓扑感知调度:将通信密集的 Pod 调度到同一交换机/机架
- 使用 Extended Resources 或 Device Plugin 机制
2.6 可观测性与训练指标
Q21:大模型训练需要关注哪些指标?
- 资源指标:GPU 利用率、显存占用、SM 占用、温度、功耗
- 训练指标:loss、learning rate、throughput (samples/sec)、step time
- 分布式指标:NCCL 通信时间、All-Reduce 等待时间
- 健康指标:checkpoint 时间、失败重试次数、任务排队时间
Q22:如何设计训练指标上报与存储?
- 指标采集:Prometheus Exporter、NVIDIA DCGM、训练框架 Hook
- 指标上报:Pushgateway、OpenTelemetry、自定义 Agent
- 存储:Prometheus + Thanos/VictoriaMetrics、时序数据库
- 展示:Grafana Dashboard、实验对比视图
- 长期存储与成本:采样聚合、冷热分层
Q23:如何检测训练异常?
- loss 长时间不下降或异常跳变
- throughput 持续下降
- GPU 利用率骤降
- NCCL 超时或通信错误
- 显存 OOM
- 梯度爆炸/NaN
2.7 系统性能分析与故障排查
Q24:训练任务卡慢如何分析?
- 分层定位:数据加载 → 前向/反向计算 → 通信同步 → IO/Checkpoint
- 工具:PyTorch Profiler、Nsight Systems、NCCL Tests、perf、ebpf
- 查看各阶段耗时占比,定位瓶颈
Q25:NCCL 超时/通信错误排查?
- 检查网络连通性与带宽
- 检查 RDMA/GPUDirect 配置
- 确认 NCCL_IB_DISABLE、NCCL_SOCKET_IFNAME 等环境变量
- 使用
nccl-tests验证基础性能 - 检查防火墙、MTU、交换机配置
三、项目经验准备建议
项目一:机器学习平台任务调度系统
- 背景:大模型训练任务多、资源需求大、调度复杂
- 目标:构建支持预训练/SFT/RL 的任务调度平台
- 方案:
- 设计 TrainingJob CRD 描述训练任务
- 开发 Operator 管理任务生命周期
- 自研/扩展调度器支持 Gang Scheduling、拓扑感知、优先级队列
- 集成 PyTorch/Ray/Megatron 启动器
- 成果:训练任务排队时间下降 X%,资源利用率提升 Y%
项目二:GPU 集群在离线混部
- 背景:GPU 集群白天推理多、夜间训练多,资源浪费
- 目标:提升 GPU 集群整体利用率
- 方案:
- 划分在线推理与离线训练资源池
- 实现优先级调度与抢占
- 监控任务干扰,自动迁移受影响任务
- 动态配额与弹性伸缩
- 成果:集群利用率从 X% 提升到 Y%,成本下降 Z%
项目三:训练可观测性平台
- 背景:训练任务失败定位慢,指标分散
- 目标:统一训练指标、日志、事件观测
- 方案:
- 采集 GPU、NCCL、框架、应用多层指标
- 构建训练任务级 Dashboard
- 异常检测与自动告警
- 训练失败根因分析
- 成果:MTTR 降低 X%,训练失败率下降 Y%
四、面试准备清单
4.1 技术复习
- [ ] Go/Python 编程、并发、性能优化
- [ ] K8s 控制器/Operator/调度器开发
- [ ] 分布式训练原理:DP、DDP、TP、PP、ZeRO
- [ ] PyTorch、Ray、Megatron、DeepSpeed 框架
- [ ] GPU/NPU/ARM 异构计算基础
- [ ] RDMA/RoCE/InfiniBand 网络基础
- [ ] 在离线混部与资源调度
- [ ] 可观测性:Prometheus、Grafana、DCGM、训练指标
4.2 项目复盘
- [ ] 准备一个 ML 平台或训练调度系统项目
- [ ] 准备一个 K8s 调度器/控制器开发项目
- [ ] 准备一个 GPU 资源优化或在离线混部项目
- [ ] 用 STAR 法则梳理成果与数据
4.3 行为面试
- 如何平衡训练任务的资源公平性与效率?
- 遇到训练任务大规模失败,如何快速定位与恢复?
- 在资源紧张时,如何与多个业务方协调 GPU 使用?
- 描述一次优化训练效率或降低成本的完整经历。
五、推荐学习资源
| 类型 | 资源 |
|---|---|
| K8s 调度 | scheduler-plugins、Volcano、Kube-scheduler 源码 |
| 训练框架 | PyTorch Distributed、Megatron-LM、DeepSpeed、Ray 官方文档 |
| GPU 性能 | NVIDIA DCGM、Nsight Systems、CUDA/NCCL 最佳实践 |
| 网络 | RDMA/RoCE/InfiniBand 原理、GPUDirect RDMA |
| 平台实践 | Kubeflow、KubeRay、NVIDIA GPU Operator、 volcano-sh/volcano |
六、简历亮点建议
- 量化训练规模:支撑 X 张 GPU、Y 个训练任务、Z 个模型版本
- 突出调度能力:Gang Scheduling、拓扑感知、在离线混部
- 强调框架适配:PyTorch/Ray/Megatron/DeepSpeed 集成经验
- 展示成本优化:资源利用率提升、成本下降、训练效率提升
- 提及异构与网络:GPU/NPU、RDMA、RoCE 经验
- 展示平台化成果:自研 ML 平台、CRD/Operator、可观测体系
祝你面试顺利,拿下大模型平台开发 Offer!