MiniMax AI Infra 三轮技术面实录

分层讲述结构：

• Layer 1 - 业务背景：为什么做这个项目？不做会怎样？（如：模型迭代周期太长，研究员排队等卡）
• Layer 2 - 架构设计：整体架构图（调度器 + 队列 + 监控 + 存储），关键组件选型理由
• Layer 3 - 核心难点：遇到过什么技术挑战？（如：显存碎片、NCCL 通信瓶颈、Checkpoint 写放大）
• Layer 4 - 解决方案：怎么解决的？用了什么技术？（如：引入 PagedAttention、梯度累积策略调整、异步 Checkpoint）
• Layer 5 - 量化结果：GPU 利用率提升 XX%、训练时间缩短 XX%、成本下降 XX%

1. 延迟优化（Latency）

• 算子层：FlashAttention / FlashDecoding 减少 KV Cache 访问；算子融合（fuse kernel）减少 launch overhead
• 模型层：Speculative Decoding（草稿模型）、量化（INT8/FP8/AWQ/GPTQ）、KV Cache 压缩（MLA / GQA）
• 服务层：Continuous Batching、Prefix Caching、Radix Tree 前缀复用

2. 吞吐优化（Throughput）

• Dynamic Batching + Request Scheduling（最短作业优先 / 最大吞吐优先）
• PD 分离（Prefill-Decode Disaggregation）：Prefill 需要大算力，Decode 需要低延迟，分离后各自优化
• Pipeline Parallelism for serving：多卡流水处理不同请求阶段

3. 成本控制（Cost）

• 异构部署：热请求用 A100/H100，冷请求用 A10/L4
• Spot / 抢占式实例用于离线推理
• 自动扩缩容：基于 QPS 和队列深度的 HPA
• 模型蒸馏 + 小模型路由：简单请求走 7B，复杂请求走 70B

1. 模型版本管理

• 模型仓库：MLflow / Model Registry / 自研，记录 checkpoint → model artifact → 性能指标的完整血缘
• 版本命名：semantic versioning（v1.2.3），标签体系（stable / canary / rollback）
• AB 测试能力：同一流量按 header / user_id 分流到不同版本，收集业务指标

2. 灰度发布策略

• 影子流量（Shadow）：新模型接收线上流量但不返回结果，只对比输出差异和延迟
• 金丝雀（Canary）：1% → 5% → 20% → 100% 渐进放量，监控 P99 延迟、错误率、业务指标
• 蓝绿部署（Blue-Green）：两套完整环境瞬时切换，适合大版本升级

3. 回滚机制

• 自动熔断：错误率 > X% 或延迟 > Yms 时自动切回旧版本
• 一键回滚：模型镜像 + 配置 + 权重全部版本化，回滚时间 < 30s
• Checkpoint 热加载：vLLM / Triton 支持运行时切换模型权重

案例 1：训练 OOM（Out of Memory）

• 现象：某 70B 模型训练在特定 step 稳定 OOM，不是初始就爆
• 根因：sequence length 不固定，某个 batch 遇到超长序列，activation 显存暴增
• 解决：① gradient checkpointing 换空间换时间；② 引入 activation checkpoint 策略选择（全量 vs 选择性）；③ 动态 batch size（按序列长度分组 bucketing）
• 结果：峰值显存下降 40%，训练速度损失仅 15%

案例 2：推理显存碎片

• 现象：推理服务运行一段时间后，明明总显存够用，但新请求分配失败
• 根因：PyTorch CUDA Memory Allocator 的缓存池碎片化 + 变长序列导致的不规则分配
• 解决：① 引入 PagedAttention（block-based 分配，避免碎片）；② 定期清空 CUDA cache（权衡性能）；③ 请求按长度分组，减少显存块大小差异

案例 3：CPU 内存泄漏

• 现象：DataLoader 进程内存持续增长，最终被 OOM Killer 杀掉
• 根因：多进程 DataLoader 中，自定义 collate_fn 持有张量引用未释放
• 解决：① 显式 del + torch.cuda.empty_cache()；② 限制 worker 数量；③ 换用 Streaming Dataset 减少内存占用

1. 调度策略优化

• Gang-Scheduling → 弹性调度：不要求所有 GPU 同时就绪，支持部分分配 + 后续补全
• 队列优先级 + 抢占：高优先级任务（如在线实验）可抢占低优先级任务（如离线评估），被抢占任务自动 Checkpoint 恢复
• Bin-Packing：将多个小任务打包到同一台机器的多个 GPU 上，减少资源碎片
• Topology-aware：考虑 NVLink / InfiniBand 拓扑，将通信频繁的任务分配到同节点 / 同交换机

2. 训练利用率提升

• 减少数据加载瓶颈： prefetch + 异步数据 pipeline、高速存储（SSD / 本地 NVMe）
• 通信优化：NCCL 调优（tree vs ring）、通信计算重叠（overlap）、梯度压缩
• 长稳训练：自动故障检测 + 快速恢复（ Checkpoint 间隔优化、热迁移）

3. 推理利用率提升

• Continuous Batching 提升 GPU 算力占用率（从 30% → 80%+）
• 自动扩缩容：低峰期缩容释放资源给训练任务
• 混部：推理和训练任务错峰共享集群

4. 碎片整理与资源回收

• 定时巡检：发现僵尸进程、挂掉的容器、未释放的显存
• 自动清理：空闲超时（如 30 分钟无活跃任务）自动释放资源
• 显存碎片整理：定期 consolidate 或重启服务

挑战 1：超长上下文（1M+ tokens）带来的显存和计算爆炸

• 问题本质：Attention 的 O(N²) 复杂度，1M context 下 KV Cache 占用数百 GB，推理延迟不可接受
• 应对策略：
  • 引入 Linear Attention / Lightning Attention 降低复杂度到 O(N)
  • KV Cache 量化 + 压缩（如 MLA 将 KV 投影到低维 latent space）
  • PagedAttention + Prefix Caching 减少重复计算
  • Context Parallelism：将长序列切分到多卡并行处理

挑战 2：Scaling Law 下的万卡训练稳定性

• 问题本质：随着集群规模扩大，单点故障概率指数上升；网络拥塞、梯度同步延迟、loss spike 频发
• 应对策略：
  • 异步 Checkpoint：每 10 分钟异步写 Checkpoint，不阻塞训练
  • 故障自愈：自动检测 hung / OOM / NCCL 超时节点，隔离后重新调度
  • 3D Parallelism 自动调优：根据模型结构和集群拓扑自动选择 TP/PP/DP 组合
  • DiT（Data-independent Training）技术：减少数据加载对训练稳定性的影响

挑战 3：推理成本随模型规模线性增长

• 问题本质：模型越大，推理成本越高，但业务收入未必同步增长
• 应对策略：MoE 架构（稀疏激活）、投机解码（Draft Model）、蒸馏小模型做路由、异构硬件部署

1. 数据并行（Data Parallelism, DP）

• 原理：每个 GPU 持有完整模型副本，处理不同数据子集，反向传播后 All-Reduce 同步梯度
• 适用：模型能放进单卡显存（< 40B @ A100 80G），需要加速训练的场景
• 优点：实现简单、扩展性好、通信量小（只传梯度）
• 缺点：模型太大时无法使用；显存冗余（每张卡都存完整模型）
• 代表：PyTorch DDP、DeepSpeed ZeRO（本质是显存优化的 DP）

2. 模型并行 / 张量并行（Tensor Parallelism, TP）

• 原理：将模型层的参数按维度切分（如 Attention 的 head 维度、FFN 的 hidden 维度），每卡只存部分参数，前向/反向时通过 All-Gather / Reduce-Scatter 通信
• 适用：单卡放不下的模型（> 40B），通信带宽高的场景（NVLink 节点内）
• 优点：突破单卡显存限制
• 缺点：通信密集（每层至少 2 次 All-Reduce），跨节点性能差
• 代表：Megatron-LM TP、Colossal-AI

3. 流水线并行（Pipeline Parallelism, PP）

• 原理：将模型按层切分成多个 stage，每个 GPU 负责一部分层，数据像流水线一样依次流过
• 适用：超大规模模型（> 100B），层数多、需要跨节点部署的场景
• 优点：通信量小（只传激活值）、可跨节点扩展
• 缺点：流水线气泡（Bubble）导致 GPU 空闲；负载均衡难
• 优化：GPipe（macro-batch）、PipeDream（1F1B 交错）、Interleaved PP

4. 组合策略（3D Parallelism）

• TP 在节点内（NVLink 带宽高），PP 跨节点，DP 在最外层扩规模
• MiniMax-01 千亿模型典型配置：TP=8（节点内）× PP=4 × DP=16 = 512 卡

1. 系统架构（四层）

• API 层：REST/gRPC 接口，接收训练任务提交（镜像、资源需求、优先级、约束）
• 调度层：Scheduler 核心，负责任务排队、资源匹配、抢占决策
• 执行层：Agent / Worker，在每个节点上拉起容器、监控任务状态、上报指标
• 资源层：GPU 池、存储池、网络池的抽象和管理

2. 核心调度流程

• 提交：用户提交 Job → 校验资源需求 → 进入优先级队列
• 调度：Scheduler 周期性扫描队列 → 按优先级 + 资源匹配度排序 → 选择最优节点
• 绑定：Gang-Scheduling（确保所有需要的 GPU 同时可用）→ 预分配资源 → 下发任务
• 执行：Agent 拉取镜像 → 启动容器 → 挂载分布式存储 → 启动训练进程
• 监控：实时采集 GPU 利用率、显存、网络、loss → 异常自动处理

3. 高可用机制

• Scheduler HA：主备模式，状态持久化到 etcd，故障秒级切换
• 任务容错：节点故障 → 自动迁移到备用节点 + 从最新 Checkpoint 恢复
• 资源超售：训练任务通常不会 100% 占满显存，允许适度超售提升利用率（需严格风险评估）

4. 可扩展设计

• Scheduler 支持多实例分片（按队列或按资源池分片）
• 插件化：资源约束、亲和性、拓扑感知都做成插件
• 与 Kubernetes 集成：用 Custom Controller + CRD 实现，复用 K8s 生态

1. 监控指标体系（分层）

• 硬件层：GPU 利用率、显存占用、温度、功耗、NVLink / IB 带宽、PCIe 带宽
• 通信层：NCCL All-Reduce 耗时、通信量、等待时间（wait time）
• 框架层：PyTorch Profiler 采集：forward/backward 耗时、数据加载耗时、optimizer 耗时
• 业务层：loss curve、learning rate、throughput (samples/s, tokens/s)、MFU（Model FLOPs Utilization）

2. 瓶颈定位方法

• 计算瓶颈：GPU 利用率低但显存高 → 可能是数据加载慢或通信阻塞
• 通信瓶颈：NCCL 耗时占比 > 30% → 检查拓扑（是否跨交换机）、检查通信算法（ring vs tree）
• 内存瓶颈：频繁 page fault / CPU 内存占用高 → DataLoader 太慢或数据预处理太重
• 存储瓶颈：Checkpoint 写操作耗时 > 5min → 使用分布式存储或异步写入

3. 故障自动处理

• 检测：心跳机制（Agent 每 30s 上报）+ 异常指标自动触发（如 loss NaN、NCCL timeout）
• 诊断：自动采集日志、生成故障快照（GPU 状态、网络状态、进程状态）
• 恢复：节点级故障 → 隔离节点 + 重新调度任务；任务级故障 → 自动重启 + 从 Checkpoint 恢复

1. 可靠性保障

• 多副本：Checkpoint 写入分布式存储（如 Ceph、JuiceFS、HDFS），自动 3 副本
• 校验机制：写入时计算 CRC / MD5，读取时校验，防止静默损坏
• 版本保留：保留最近 N 个 Checkpoint（如最近 5 个 + 每 1 小时 1 个），支持任意时间点回滚
• 异地备份：关键 Checkpoint 异步复制到异地存储，防止机房级故障

2. 写入性能优化

• 异步写入：训练进程不等待 Checkpoint 写完，后台线程负责上传，减少训练中断时间（从 5min → 30s）
• 增量 Checkpoint：只保存变化的部分（如 optimizer state 变化小，可增量更新）
• 分片并行写：每个 rank 写自己的分片，最后汇总元数据，避免单点瓶颈
• 压缩：使用 zstd / lz4 压缩，减少 I/O 量（通常可压缩 3-5x）

3. 读取性能优化

• 预加载：任务调度时提前将 Checkpoint 从冷存储预热到计算节点本地 SSD
• 分层存储：热 Checkpoint 在 NVMe SSD（延迟 < 1ms），冷 Checkpoint 在对象存储（成本低）
• 懒加载：大模型参数按需加载，不阻塞训练启动

4. 成本优化

• 生命周期管理：自动将 7 天前的 Checkpoint 转存到冷存储（如 S3 Glacier）
• 去重：相同模型的 Checkpoint 之间有大量重复，可用内容寻址存储（CAS）去重

K8s 在 AI Infra 中的价值

• 统一调度：训练、推理、数据处理任务统一管理，资源池化
• 弹性伸缩：HPA / VPA 根据负载自动扩缩容，推理高峰期自动扩容
• 服务发现：分布式训练 worker 自动注册发现，无需手动配置 IP
• 可观测性：复用 Prometheus / Grafana 生态，统一监控告警

K8s 在 AI 场景的特殊挑战

• GPU 调度弱：原生 K8s 不支持 GPU 拓扑感知、不支持 Gang-Scheduling
  • 解决：GPU Operator + Device Plugin + 自研 Scheduler Extender / Volcano / Yunikorn
• 显存管理缺失：K8s 只管理 GPU 卡数，不管理显存细粒度分配
  • 解决：自研显存调度器（按显存配额调度）、MIG / MPS 分区
• 训练任务容错差：Pod 失败默认重启，但训练需要 Checkpoint 恢复
  • 解决：自定义 Controller（Training Operator / MPI Operator），失败时自动从 Checkpoint 恢复而非冷启动
• 存储性能：训练需要高吞吐并行存储，K8s 默认存储性能不足
  • 解决：JuiceFS / Lustre / GPFS 作为底层存储，通过 CSI 接入

我的实践

• 基于 K8s + Volcano 构建了训练调度平台，支持 Gang-Scheduling、优先级抢占、拓扑感知
• 开发了 TrainingJob CRD，封装了 PyTorchJob / MPIJob 的通用逻辑，用户只需填资源需求和镜像
• 与 Kubeflow 集成，支持实验追踪和模型版本管理

1. 传统架构痛点

• GPU 节点自带大容量 NVMe SSD，但利用率低（很多节点存储空闲）
• Checkpoint 写到本地盘，节点故障时数据丢失风险高
• 数据预处理节点和训练节点紧耦合，扩缩容不灵活

2. 存算分离设计

• 计算层：GPU 节点专注计算，只保留少量本地缓存（热数据），不存持久数据
• 存储层：独立的高性能存储集群（如基于 RDMA 的并行文件系统、对象存储），通过高速网络（200Gbps+ RDMA / InfiniBand）接入
• 缓存层：计算节点本地 SSD 作为缓存，常用数据（如模型代码、频繁读取的 dataset shard）本地命中

3. 核心收益

• 资源弹性：计算和存储独立扩缩容，训练高峰期加 GPU 节点，不需要加存储
• 数据共享：多任务共享同一份数据集，避免重复存储
• 可靠性提升：Checkpoint 写入高可靠存储，节点故障数据不丢
• 成本优化：存储用廉价 HDD / 对象存储，计算用 GPU，各自选最优配置

4. 关键挑战与应对

• 挑战 1：网络带宽瓶颈 → 训练时频繁读数据，网络延迟影响吞吐
  • 应对：RDMA 网络（延迟 < 2μs）、数据预加载到本地缓存、数据集切分后本地缓存
• 挑战 2：元数据性能 → 海量小文件（如图像数据集）导致元数据操作瓶颈
  • 应对：将小文件打包成 TFRecord / WebDataset / Arrow 格式；使用元数据缓存
• 挑战 3：缓存一致性 → 多节点缓存可能导致数据版本不一致
  • 应对：只读数据集（训练数据不变）；写操作（Checkpoint）直写存储层

1. 分层 SLA 定义

• 数据层：数据可用性 > 99.9%、ETL 延迟 < 1h、数据质量校验通过率 > 99%
• 训练层：训练任务成功率 > 95%、资源就绪时间 < 10min、Checkpoint 恢复时间 < 5min
• 推理层：可用性 > 99.99%、P99 延迟 < 200ms、错误率 < 0.1%
• 平台层：API 可用性 > 99.95%、调度响应时间 < 5s

2. 监控体系

• 基础设施监控：GPU/CPU/内存/网络/存储的利用率、温度、故障率
• 业务监控：训练吞吐、推理 QPS/延迟、模型精度漂移、数据新鲜度
• 用户感知监控：端到端请求耗时（从用户发请求到收到响应）、排队时间

3. 保障机制

• 冗余设计：推理服务多副本 + 负载均衡；存储多副本；关键路径去单点
• 自动降级：推理高峰期自动切换到轻量级模型或缓存结果
• 容量规划：基于历史数据预测资源需求，提前扩容避免峰值击穿
• 混沌工程：定期模拟节点故障、网络分区，验证系统恢复能力

4. 应急流程

• 分级告警：P0（立即响应，如推理服务宕机）、P1（1h 内响应，如训练任务大量失败）、P2（24h 内处理）
• On-Call 轮值 + 自动工单派发 + 故障复盘模板（5 Whys）

决策框架（四象限）

• 差异化竞争力 + 业务核心：必须自研（如调度策略、推理引擎核心路径）
• 差异化竞争力 + 非核心：自研 wrapper / 适配层，底层用开源
• 非差异化 + 业务核心：深度定制开源方案（如 K8s + 大量 CRD）
• 非差异化 + 非核心：直接采用成熟开源方案（如监控用 Prometheus、日志用 Loki）

案例 1：自研推理调度器（选择自研）

• 背景：开源方案（如 Seldon、KFServing）不支持 Continuous Batching 和 Prefix Caching 的细粒度调度
• 决策：自研推理调度器，支持请求级别的 GPU 显存管理和动态批处理
• 结果：推理吞吐提升 3x，成为核心竞争力

案例 2：训练存储系统（选择开源 + 深度定制）

• 背景：需要高并发 Checkpoint 写入，自研存储系统成本高
• 决策：基于 JuiceFS 深度定制，优化 RDMA 路径和缓存策略，不改核心存储引擎
• 结果：3 个月上线，Checkpoint 写入速度提升 5x

关键原则：

• 自研必须有清晰的 ROI：投入 3 个人月，预期带来 XX% 性能提升或成本下降
• 先验证开源方案的天花板，再决定是否自研（避免重复造轮子）
• 自研组件必须有完善的文档和交接机制，防止人员流失后成为技术债

1. 评估维度

• 算力：FP16/FP8/INT8 峰值算力、Tensor Core 利用率、实际 MFU
• 显存：容量、带宽（HBM3 vs HBM2e）、ECC 支持
• 互联：NVLink / NVSwitch 带宽、RDMA 网卡兼容性、多卡 scaling efficiency
• 软件生态：CUDA 兼容性、驱动稳定性、PyTorch/TensorFlow 支持程度
• 成本：TCO（Total Cost of Ownership）= 采购成本 + 功耗成本 + 运维成本

2. 测试流程

• Phase 1 - 基准测试：跑标准 benchmark（MLPerf、Hugging Face benchmark），对比现有硬件
• Phase 2 - 业务测试：跑真实业务模型（如公司内部的大模型），测试训练吞吐、推理延迟、稳定性
• Phase 3 - 压力测试：7×24 小时 burn-in 测试，检测硬件故障率、温度稳定性
• Phase 4 - 兼容性测试：与现有网络、存储、调度系统的兼容性

3. 引入策略

• 灰度引入：先给非核心任务（如离线评估、小规模实验）使用，验证稳定后逐步扩到核心训练
• 混部部署：新硬件和老硬件共存，通过调度器自动路由不同任务到合适的硬件
• 软件适配：必要时写自定义 CUDA kernel 或对接新硬件的 SDK

4. 风险管控

• 签订 SLA：硬件故障率 < X%、性能衰减 < Y%
• 保留回退方案：如果新硬件不达标，能快速切回老硬件
• 长期支持：确保厂商能提供 3-5 年的驱动和固件更新

1. 训练侧变革

• 变革：模型从百亿到千亿再到万亿，训练集群从百卡到万卡，稳定性、成本、调度复杂度指数级上升
• 应对：
  • MoE 架构：稀疏激活降低训练成本（如 MiniMax-01 的 32 专家）
  • 3D Parallelism 自动调优：根据模型结构动态选择 TP/PP/DP 组合
  • 异步 Checkpoint + 故障自愈：万卡集群单点故障不可避免，必须自动恢复

2. 推理侧变革

• 变革：推理成本成为业务盈亏关键，长上下文（1M+）和 Agent 场景对延迟极度敏感
• 应对：
  • PD 分离（Prefill-Decode Disaggregation）：Prefill 并行化，Decode 低延迟流水化
  • 投机解码（Speculative Decoding）：用小模型草稿 + 大模型验证，延迟降低 2-3x
  • 模型蒸馏 + 路由：简单请求走小模型，复杂请求走大模型

3. 数据侧变革

• 变革：大模型需要海量高质量数据（15T+ tokens），数据 pipeline 成为瓶颈
• 应对：
  • 流式数据处理：不全部加载到内存，边处理边训练
  • 数据质量自动筛选：用规则 + 小模型过滤低质量数据
  • 多模态数据统一处理：文本、图像、音频的预处理 pipeline 统一抽象

4. 工程化变革

• 变革：从「研究员手动跑实验」到「工程化大规模生产」，MLOps 成为标配
• 应对：
  • 统一实验平台：代码、数据、超参、模型版本全链路追踪
  • 自动扩缩容：训练任务自动申请资源，推理服务按流量自动伸缩
  • 成本可观测：每个实验、每个模型的训练/推理成本精确核算

示例：推理服务化平台架构设计

1. 背景与需求

• 公司从 0 到 1 搭建大模型推理服务，需要支持多模型、多版本、高并发、低延迟
• 关键需求：P99 < 200ms、QPS > 10k、支持 A/B 测试、成本可控

2. 方案对比与决策

3. 关键架构决策详解

• 为什么用 gRPC 而不是 HTTP/REST？ → 二进制协议减少序列化开销，支持 streaming（对于大模型生成式输出很重要）
• 为什么用 Redis 做模型元数据缓存？ → 模型配置读取频繁但数据量小，Redis 延迟 < 1ms；但 Checkpoint 权重大文件不缓存
• 为什么做 PD 分离（Prefill-Decode）？ → Prefill 需要并行计算，Decode 需要低延迟流水，分离后各自优化，整体吞吐提升 40%

4. 实施与结果

• 架构图（略，面试时可画）：API Gateway → Router → Prefill Pool / Decode Pool → Model Store
• 结果：P99 延迟从 500ms → 180ms，QPS 从 3k → 12k，成本下降 55%

1. 并行策略设计（3D Parallelism）

• Tensor Parallelism（TP）：在节点内（8×A100/H100）切分 attention head 和 FFN，利用 NVLink 高带宽
• Pipeline Parallelism（PP）：跨节点切分层数，每 4-8 层一个 stage，减少跨节点通信
• Data Parallelism（DP）：最外层，复制模型到多个节点组，加速训练
• 组合示例：千亿模型 → TP=8 × PP=8 × DP=16 = 1024 卡

2. 通信优化

• 网络拓扑：InfiniBand / RoCE，3 层 CLOS 网络，确保任意两卡带宽 > 200Gbps
• 通信算法：All-Reduce 用 Ring 还是 Tree？大 message 用 Tree（带宽优化），小 message 用 Ring（延迟优化）
• 重叠：通信和计算重叠（如 backward 时同时 All-Reduce 上一层的梯度）
• 梯度压缩：1-bit Adam、Error-feedback 压缩，减少通信量 10x

3. 存储设计

• Checkpoint：每 100-1000 step 异步写一次，使用分布式并行文件系统（Lustre / GPFS）
• 数据集：WebDataset / TFRecord 格式，顺序读取，预加载到本地 NVMe
• 中间结果：梯度、激活值量大但生命周期短，用节点内 NVMe 暂存

4. 容错与稳定性

• 故障检测：心跳 + NCCL timeout 监控，30s 内发现 hung 节点
• 自动恢复：隔离故障节点 → 从最新 Checkpoint 恢复 → 其他节点继续训练
• Checkpoint 策略：增量 Checkpoint + 多副本 + 异地备份

5. 调度与资源管理

• Gang-Scheduling：确保所有 1024 卡同时就绪才启动
• Topology-aware：将通信频繁的 rank 放到同一交换机下
• 优先级与抢占：在线实验可抢占离线评估，被抢占任务自动 Checkpoint

1. 资源隔离机制

• 硬件隔离（最强）：MIG（Multi-Instance GPU）将 A100 物理切分成最多 7 个独立实例，完全隔离
• 软件隔离：MPS（Multi-Process Service）允许多进程共享 GPU，但隔离性弱于 MIG
• 容器隔离：NVIDIA Docker + Device Plugin，按 GPU 卡粒度分配，简单粗暴但有效
• 显存隔离（细粒度）：自研显存调度器，按显存配额（如 20GB / 40GB）分配，支持超售

2. 调度策略

• 配额预留：每个租户有保底配额（guaranteed quota），确保高峰期也有资源可用
• 弹性配额：租户可超出配额使用空闲资源，但可被其他租户抢占
• 时间片轮转：短任务（< 1h）优先调度，减少队列等待
• gang-scheduling：多卡任务必须所有卡同时可用才调度，避免资源死锁

3. 配额管理

• 层级配额：公司级 → 部门级 → 团队级 → 项目级，层层分解
• 动态调整：根据历史使用率自动调整配额（使用率低的部门配额减少）
• 借用机制：部门 A 的闲置配额可临时借给部门 B，B 完成后归还

4. 公平性保障

• 等待时间公平：FIFO 基础上加权，等待久的任务优先级提升
• 资源使用公平：统计每个租户的实际使用时长，使用率低的租户后续调度优先级提高
• 抢占策略：高优先级任务可抢占低优先级，但被抢占任务自动 Checkpoint 恢复，不丢进度

1. 抽象层设计（核心）

• 任务抽象：定义统一的 Job Spec（镜像、资源需求、启动命令、环境变量、数据挂载点）
• 分布式抽象：统一描述分布式配置（world_size、rank、master_addr、backend），底层自动映射到各框架
• 存储抽象：统一数据集、Checkpoint、日志的访问路径，屏蔽底层存储差异

2. 统一接口

• CLI：train submit --framework pytorch --config train.yaml
• Python SDK：from aiplatform import TrainingJob; job = TrainingJob(framework="jax", ...)
• Web UI：可视化提交任务、监控进度、查看日志

3. 框架适配层

• PyTorch：原生支持，直接用 torchrun / torch.distributed.launch
• TensorFlow：适配 TF_CONFIG 环境变量，支持 Parameter Server 和 MirroredStrategy
• JAX：适配 JAX_COORDINATOR_ADDRESS 和进程网格配置，支持 pjit / pmap
• 通用 Launcher：写一个框架无关的 launcher，根据 framework 字段生成对应的启动命令和环境

4. 用户体验优化

• 模板库：提供各框架的常用训练模板（单卡、DDP、FSDP、TPU）
• 自动转换：部分简单模型支持 PyTorch ↔ TensorFlow 自动转换（如 ONNX 中间表示）
• 统一监控：不管底层什么框架，监控面板统一展示 loss、acc、throughput、GPU 利用率

1. 原理

• 传统 Static Batching：等 batch 满或超时后才执行，导致长尾延迟高
• Dynamic Batching：请求到达后动态组 batch，支持请求随时加入正在执行的 batch（Continuous Batching / Inflight Batching）
• 核心收益：GPU 算力利用率从 30-40% → 80%+，吞吐提升 3-5x

2. 策略设计

• Batch Size 上限：受显存限制，根据模型和序列长度动态计算 max_batch_size
• 等待超时：max_wait_time（如 5ms），超时后即使 batch 不满也执行，避免单个请求等待过久
• 序列长度分组：将相似长度的请求分到同一 batch，减少 padding 浪费（vLLM 的 PagedAttention 解决此问题）
• 优先级队列：实时请求（如对话）走快速通道，离线请求（如批量生成）走批量通道

3. 实现机制

• 调度器（Scheduler）：维护请求队列，按策略组 batch，下发到 GPU
• KV Cache 管理：每个请求的 KV Cache 独立管理，新请求随时加入，完成的请求随时释放（vLLM 的 Block Manager）
• Attention Mask：动态构造 causal mask，确保新加入的请求只看到自己的前缀

4. 权衡

• 吞吐 vs 延迟：batch 越大吞吐越高，但单个请求等待时间越长。需要按业务场景调整参数
• 公平性：长序列请求可能阻塞短序列请求。解决方案：长度分组 + 超时保护
• 显存碎片：Dynamic Batching 导致 KV Cache 分配不连续。解决方案：PagedAttention（块式分配）

1. 流水线阶段设计

• 阶段 1 - 模型导入：从 PyTorch / ONNX / TensorFlow 导入计算图
• 阶段 2 - 图优化：常量折叠、算子融合、死代码消除、布局转换（NCHW → NHWC）
• 阶段 3 - 量化：FP32 → FP16 / INT8 / FP8，配合校准（calibration）和精度回退（fallback）
• 阶段 4 - Kernel 生成：针对目标硬件（A100 / H100 / T4）生成最优 CUDA kernel
• 阶段 5 - 运行时优化：内存池管理、异步执行、流式处理

2. 每层优化手段

• 算子融合（Kernel Fusion）：将多个小算子合并成一个 kernel，减少 kernel launch overhead
  • 典型融合：Layernorm + Residual + Activation、QKV Projection + Attention
• 内存优化：算子间内存复用（in-place operation）、激活值检查点（activation checkpointing）
• 量化：
  • PTQ（Post-Training Quantization）：快速但精度损失稍大
  • QAT（Quantization-Aware Training）：精度好但需重新训练
  • SmoothQuant / AWQ / GPTQ：针对 LLM 的先进量化方法

3. 工具链

• TensorRT：NVIDIA 生态，推理性能极致优化，但支持算子有限
• TVM / Apache TVM：跨硬件编译，自动搜索最优 schedule
• ONNX Runtime：通用性强，支持多种后端（CUDA / DirectML / OpenVINO）
• XLA / JAX jit：Google 生态，JIT 编译 + 自动并行

4. 效果评估

• 精度：Perplexity 变化 < 1%、下游任务准确率变化 < 0.5%
• 性能：延迟下降 2-5x、吞吐提升 3-10x
• 稳定性：编译后模型在标准测试集上跑 10k 次，结果一致性 > 99.9%

示例：推理服务雪崩事故

1. 背景（Situation）

• 某大模型推理服务上线后，在晚高峰时段突发雪崩：P99 延迟从 200ms 飙升到 10s+，大量请求超时，客服投诉激增

2. 任务（Task）

• 30 分钟内止血，2 小时内定位根因，1 周内彻底修复并防止复发

3. 行动（Action）- 分层处理

• 止血（0-30min）：立即扩容 2 倍实例 + 开启降级策略（短请求走缓存，长请求限流）+ 通知业务方
• 定位（30min-2h）：
  • 监控发现 GPU 利用率 100%，但 QPS 并没有明显增长
  • 日志发现大量请求的 sequence length 突然变长（从平均 500 → 3000+）
  • 根因：某业务方上线了新功能，prompt 模板引入了长上下文，导致 KV Cache 爆炸

4. 5 Whys 深挖

• Why 1：为什么延迟飙升？→ GPU 算力被长序列占满，短序列排队
• Why 2：为什么长序列会占满 GPU？→ KV Cache 没有长度限制，单请求占 20GB+
• Why 3：为什么没有长度限制？→ 配置里 max_seq_len 设为 unlimited
• Why 4：为什么设为 unlimited？→ 上线时为了兼容所有场景，没有按业务分级
• Why 5：为什么没有分级？→ 缺乏 SRE review 流程，上线 checklist 不完善

5. 改进措施

• 技术层：按业务分级设置 max_seq_len（普通 2k、高级 8k、企业 32k）；引入请求长度预估 + 动态路由
• 流程层：上线前必须过 SRE review（资源需求、容量评估、回滚方案）；建立混沌工程定期演练
• 监控层：增加 sequence length 分布监控、KV Cache 使用率告警、自动限流

6. 结果（Result）

• 同类事故 0 复发；平均故障恢复时间从 30min → 5min；团队建立了完整的 On-Call + 复盘机制

1. 信息输入层（每天 30min）

• 论文：arXiv 每日更新筛选（关注 ML Systems / OSDI / SOSP / MLSys），用 ReadPaper / PapersWithCode 跟踪
• 开源：GitHub Trending + 核心项目 release note（vLLM、DeepSpeed、Triton、Megatron）
• 社区：Twitter/X 技术圈、Reddit r/MachineLearning、中文社区（知乎、InfoQ）

2. 消化理解层（每周 4-6h）

• 论文精读：每周精读 1-2 篇核心论文，做笔记（问题 → 方法 → 实验 → 我的思考）
• 源码阅读：每月深入读一个核心组件的源码（如 vLLM 的 scheduler、DeepSpeed 的 ZeRO）
• 动手实验：本地或云 GPU 复现关键实验（如 Lightning Attention 小规模验证）

3. 实践验证层（每季度）

• POC 项目：选 1-2 个新技术做内部 POC，验证在业务场景下的可行性
• 技术分享：在团队内部分享学习成果，教学相长
• 参与开源：给 vLLM / DeepSpeed 提 PR，从 consumer 变成 contributor

4. 决策过滤层（关键）

• 不是所有新技术都要追。决策标准：业务价值 × 技术成熟度 × 团队能力
• 早鸟奖励 vs 踩坑风险：技术雷达（Adopt / Trial / Assess / Hold）管理技术栈

方向 1：推理成本优化（最关注）

• 为什么：模型越大推理成本越高，成本直接决定商业模式可行性。MiniMax 的 MoE 架构已经走在前面，但推理侧还有大量优化空间
• 关键技术：
  • PD 分离（Prefill-Decode Disaggregation）：分离后各自优化，已看到 40%+ 吞吐提升
  • 投机解码（Speculative Decoding）：Draft Model 验证模式，延迟降低 2-3x
  • 异构硬件调度：热请求 H100、温请求 A10、冷请求 CPU，动态路由
• 我的实践：在上一家公司实现了 Draft Model + 动态批处理，推理成本下降 60%

方向 2：超长上下文支持（1M+ tokens）

• 为什么：Agent、代码生成、法律文档分析都需要超长上下文，但 KV Cache 是瓶颈
• 关键技术：
  • Linear Attention / Lightning Attention：O(N) 复杂度，MiniMax 已经在大规模应用
  • Context Parallelism：将长序列切分到多卡，每卡处理一部分
  • KV Cache 压缩：H2O、StreamingLLM、MLA 等 eviction 策略

方向 3：AI 编译器与自动优化

• 为什么：手工优化 CUDA kernel 效率低，自动编译 + 自动调优是大趋势
• 关键技术：TVM、MLIR、Triton、auto-tuning（自动搜索最优 block size、fusion 策略）

1. 现状分析

• 当前处于什么阶段？（如：从「人肉运维」到「平台化」的转型期）
• 核心痛点：训练效率低、推理成本高、团队协作摩擦大、技术债累积

2. 愿景定义（3 年）

• 构建「自助式 AI 平台」：算法工程师 5 分钟内启动训练任务，自动扩缩容，成本透明
• 关键指标：资源利用率 > 80%、任务启动时间 < 5min、推理 P99 < 100ms

3. 演进路线图

• Phase 1（0-6 月）：夯实基础
  • 统一调度平台、统一监控告警、自动化故障恢复
• Phase 2（6-12 月）：效率提升
  • 推理优化（Dynamic Batching、量化、PD 分离）、训练 MFU 提升（FlashAttention、通信优化）
• Phase 3（1-2 年）：智能化
  • AutoML for Infra：自动选择并行策略、自动调优超参、自动容量规划
• Phase 4（2-3 年）：生态化
  • 内外部资源共享、多云调度、成本精细化运营

4. 关键里程碑

• 每个阶段设定 2-3 个可量化的里程碑，与业务目标强绑定

1. 愿景定义

• 与业务方深度沟通，理解业务目标（如：Q3 要上线 XX 模型，需要训练吞吐提升 2x）
• 将业务目标翻译为技术愿景（如：「构建支持千亿模型万卡训练的稳定平台」）
• 愿景必须可感知：团队成员能说出「我们在做什么，为什么重要」

2. 优先级框架

• ICE 评分：Impact（业务影响）× Confidence（技术信心）× Ease（实现难度）
• 四象限法：
  • P0：高影响 + 低难度（立即做，如监控告警完善）
  • P1：高影响 + 高难度（重点攻坚，如推理性能优化）
  • P2：低影响 + 低难度（有空做，如工具链改进）
  • P3：低影响 + 高难度（不做或推迟，如自研存储引擎）

3. 落地机制

• 双周迭代：固定节奏，每两周交付可演示的增量
• 技术 Review：关键设计必须过技术委员会，确保方向正确
• Demo 文化：每季度全员 Demo Day，展示成果，增强成就感
• Owner 制：每个项目/模块明确 Owner，有权有责

4. 风险管控

• 关键路径识别：哪些任务是阻塞性的？提前安排缓冲时间
• 技术债管理：每迭代预留 20% 时间还技术债
• 向上管理：定期向老板汇报进展、风险、需要的支持

1. 分歧识别与收集

• 不回避分歧，主动召开技术讨论会，让各方充分表达
• 要求各方用数据和案例支撑观点，而不是「我觉得」
• 明确分歧点：是目标不同？还是手段不同？

2. 决策流程（RFC 模式）

• Step 1 - 方案文档化：各方写 RFC（Request for Comments），包含：背景、方案、优缺点、风险、回滚计划
• Step 2 - 公开讨论：全员 Review RFC，收集反馈，迭代 1-2 轮
• Step 3 - 小范围验证：如果分歧大，做 A/B 测试或 POC，用数据说话
• Step 4 - 决策：技术负责人（我）综合各方意见，做出最终决策

3. 决策原则

• 数据优先：能 POC 验证的，不拍脑袋
• 可逆性原则：如果决策可逆（如技术选型），快速决策；如果不可逆（如架构大改），谨慎决策
• 团队共识：即使有人不同意，也要确保所有人理解决策理由，「不同意但执行」

4. 决策后

• 明确执行计划、负责人、时间节点
• 设定回顾点（如 1 个月后 review），如果决策错了，勇于承认并调整

1. 团队结构

• 核心层（30%）：资深工程师，负责架构设计和技术决策
• 骨干层（50%）：有经验的中级工程师，负责模块开发和落地
• 成长层（20%）：校招/初级工程师，负责具体任务，快速学习成长
• 角色互补：训练优化、推理优化、调度系统、存储、网络，每个方向至少 2 人

2. 招聘标准（我看重的特质）

• 技术深度 + 广度：不只懂一个框架，能理解系统全链路（从 CUDA kernel 到 K8s 调度）
• Owner 意识：不是「做完任务」，而是「对结果负责」
• 学习能力：AI Infra 变化快，必须能快速跟进新技术
• 沟通协作：能跟算法团队、硬件团队、业务方有效沟通
• 抗压能力：线上故障时冷静处理，不推诿

3. 培养机制

• Mentor 制：每位新人配一位资深导师，前 3 个月手把手带
• 技术分享：每周内部技术分享（论文、源码、项目复盘）
• 轮岗机制：每半年可轮换方向（如从训练组换到推理组），拓宽视野
• 外部交流：参加 OSDI / SOSP / MLSys 等顶会，了解行业前沿

4. 文化塑造

• 数据驱动：所有优化必须有量化结果，不拍脑袋
• 开放透明：技术决策公开讨论，文档全员可见
• 容错文化：鼓励试错，但要求复盘；一次故障的价值 > 10 次成功
• 客户第一：算法工程师和终端用户是我们的客户，他们的体验是最高优先级

1. 分层解耦（最重要）

• 存储层、计算层、调度层、服务层严格解耦，每层通过稳定接口交互
• 举例：推理引擎可以从容器的 Triton 换成自研的，只要满足统一的服务接口，上层无感知
• 避免「大泥球」架构，每个组件职责单一、边界清晰

2. 接口稳定性

• 核心接口（如任务提交 API、模型服务 API）一旦定义，保持向后兼容
• 版本管理：v1 / v2 / v3，老版本至少支持 6 个月 deprecation 期
• 契约测试：接口变更必须通过自动化契约测试

3. 技术雷达（Technology Radar）

• 定期（每季度）评估技术栈：Adopt（主推）、Trial（试点）、Assess（观察）、Hold（淘汰）
• 避免技术债累积：明确标记 legacy 组件，制定替换计划
• 引入新技术必须有 POC + 评审，不追新、不保守

4. 持续重构

• 每迭代预留 20% 时间做重构和还技术债
• 重构原则：小步快跑，每次只改一个模块，确保测试覆盖
• 建立代码健康度指标：测试覆盖率、圈复杂度、依赖耦合度

5. 文档与知识沉淀

• 架构决策记录（ADR）：每个重大技术决策都有文档，记录背景、方案、决策理由
• 新人 onboarding 文档：2 周内能独立上手
• 故障案例库：每次故障都写成案例，供团队学习

ROI 计算框架

ROI = (收益 - 成本) / 成本 × 100%

1. 成本核算（全面）

• 直接成本：人力成本（工程师时间）、硬件采购、云服务费用、软件许可
• 间接成本：维护成本（每年 15-20% 的初始成本）、培训成本、机会成本（做 A 就不能做 B）
• 隐性成本：技术债、人员流失风险、供应商锁定

2. 收益评估（量化）

• 效率收益：训练时间缩短 XX% → 模型迭代加快 → 业务收益 XX
• 成本收益：推理成本下降 XX% → 每月节省 XX 万
• 质量收益：故障率下降 XX% → 客户满意度提升 → 留存率提升 XX%
• 战略收益：自研系统成为技术壁垒，支持未来 3 年业务扩展（难以量化但重要）

3. 示例：自研推理调度器

• 成本：3 个工程师 × 6 个月 = 18 人月 ≈ 90 万
• 收益：推理吞吐提升 3x → 同样流量只需 1/3 GPU → 每月节省 50 万 → 年化 600 万
• ROI：(600 - 90) / 90 = 567%（极高）
• 回收期：2 个月

4. 决策原则

• ROI > 300% 且回收期 < 6 个月：立即做
• ROI 100-300%：评估资源是否允许
• ROI < 100%：除非有战略价值，否则不做
• 不确定性高的投资：分阶段投入，每阶段设 go/no-go 决策点

1. 受众分析

• 业务方（产品经理/运营）：关心用户价值、成本、上市时间
• 研究院（算法科学家）：关心实验效率、模型效果、研究自由度
• 管理层（CTO/CEO）：关心投入产出、竞争优势、战略方向

2. 价值翻译（不说技术术语）

• ❌ 错误："我们优化了 All-Reduce 通信，提升了 NCCL 带宽利用率"
• ✅ 正确："模型训练时间从 2 周缩短到 5 天，你们可以更快验证新想法"
• ❌ 错误："我们实现了 Continuous Batching 和 PagedAttention"
• ✅ 正确："同样成本下，我们的服务能多支撑 3 倍用户，或者成本降低 60%"

3. 案例驱动

• 用具体的业务场景讲故事："上次大促期间，推理延迟飙升导致用户流失。我们通过 XX 优化，把延迟稳定在了 XX，保障了活动顺利进行"
• 可视化：用图表展示利用率提升、成本下降、故障减少

4. 双向沟通

• 不是单向宣讲，而是倾听需求："你们目前最大的痛点是什么？我们可以怎么帮你们？"
• 建立定期沟通机制：每双周与研究院 sync，了解实验需求；每月向业务方汇报平台能力升级
• 让业务方参与决策：资源分配优先级由业务方和技术方共同决定

5. 挑战的表达方式

• 不抱怨，而是提出方案："当前推理成本是我们最大的挑战，我们计划通过 XX 优化在 3 个月内降低成本 50%，需要业务方配合做 XX"

能力 1：技术判断力（Technical Judgment）

• 为什么最重要：AI Infra 技术栈复杂（训练、推理、存储、网络、硬件），方向选错了代价巨大
• 具体体现：能在信息不完整时做出合理的技术决策；知道什么该自研、什么该用开源；预判技术趋势
• 我的实践：在 XX 项目中，我判断推理引擎必须自研核心调度器（而非用开源），虽然前期投入大，但 6 个月后带来 3x 性能提升，成为团队核心竞争力

能力 2：团队领导力（Team Leadership）

• 为什么重要：AI Infra 是系统工程，单枪匹马做不成，必须带领团队协同作战
• 具体体现：招人、培养人、激励人；建立高效协作机制；在压力下保持团队士气
• 我的实践：我建立了 Mentor 制 + 技术分享文化，团队新人 3 个月就能独立负责模块；团队离职率连续 2 年 < 5%

能力 3：业务翻译能力（Business Translation）

• 为什么重要：技术再牛，如果不能转化为业务价值，就是自嗨
• 具体体现：能把业务目标翻译成技术目标；能用非技术语言向老板和业务方解释技术价值；做决策时考虑 ROI
• 我的实践：每季度我会做「技术投入业务回报」分析报告，用数据展示平台升级带来的成本节省和效率提升，争取到了持续的资源投入

补充能力（ honorable mention）：

• 抗压与韧性：线上故障、项目延期、资源不足是常态，能在压力下保持冷静和执行力
• 学习能力：AI Infra 技术迭代快，必须持续学习才能不被淘汰