ai-infra git:20260920.a4843f5A

Immutable. This exact content is served forever at /api/v1/blob/abccdce740a24c33.

---
name: ai-infra
description: 大模型推理与训练基础设施怎么面：KV cache、调度、并行、量化算子、服务指标、训练集群。AI Infra 岗读。
keywords: [ai infra, 推理优化, 推理加速, 大模型推理, 推理引擎, vllm, sglang, tensorrt-llm, kv cache, paged attention, continuous batching, 投机解码, speculative decoding, 量化, fp8, cuda, triton, flashattention, 张量并行, moe, pd 分离, ttft, 训练框架, megatron, deepspeed, fsdp, 大模型系统]
layer: domain
---

## 面试官在意什么

AI Infra 工程师（大模型推理优化、推理引擎、大模型系统、训练框架与集群）做的是让模型跑得快、跑得起、跑得稳：推理侧管显存（KV cache）、调度（批处理与抢占）、并行（张量 / 流水 / 专家）、算子（attention、量化内核）、服务（路由、SLO、多租户）；训练侧管千卡集群的并行策略、通信、checkpoint 与故障恢复。它和算法岗的分界是：算法岗问"为什么这个模型好"，Infra 岗问"这个模型在这批卡上每秒能出多少 token、首 token 多少毫秒、显存花在哪、还能怎么省"。真实面试三到四轮：一面考 GPU 体系结构、并发与内存基础加手撕（C++ / CUDA 或 Python 实现一个 attention / softmax / 分块 kernel），二面深挖推理或训练系统里候选人负责的那一段的数字与故障，三面给一个部署场景现场算账（多少卡、多大 batch、能到多少吞吐、瓶颈在哪），主管面看对开源引擎（vLLM、SGLang、TensorRT-LLM）的理解深度与贡献。

面试官最在意四件事：第一，能不能算账——一个 7B / 70B 模型的权重、KV cache 每 token 占多少显存，一张卡能放多少并发，decode 为什么卡在显存带宽而不是算力，用 roofline 判断算子是算力密集还是带宽密集；第二，对推理引擎的机制理解到实现层——PagedAttention 解决了什么碎片问题、continuous batching 在哪一级插入新请求、prefix caching 的命中条件、投机解码的接受率与加速比关系；第三，有没有真实的性能故障与定位过程——TTFT 突增、吞吐上不去、GPU 利用率低、OOM、抢占风暴，从现象到 profiler 到根因；第四，取舍能不能落到 SLO 与成本——延迟、吞吐、显存、精度四者怎么在一个具体业务下排序。

校招侧重：CUDA 编程模型（grid / block / warp、共享内存、合并访存）、GPU 内存层次、attention 的计算与显存复杂度、能读懂 vLLM 一个模块的源码并解释它；社招侧重：生产级服务的调度与 SLO、多模型多租户、PD 分离与 MoE 并行这类大集群问题、算子级优化的实测数字、训练集群的故障率与恢复时间、对开源引擎的贡献或深度定制。

怎么问才像这个方向的面试官：
- 每道题都要算数字：候选人说了任何优化，追优化前后的 TTFT / TPOT / 吞吐 / 显存与测量条件（模型、卡、batch、序列长度）；没有数字的优化不算成果。
- 从现象到机制：不问"PagedAttention 是什么"，问"显存还有 20% 空闲却 OOM 或拒绝新请求，你怎么查"，让候选人自己走到分页与碎片。
- 考取舍不考名词时效：不问"最新引擎版本加了什么"，问"这个特性在你的场景值不值得开、代价是什么"。
- 结合候选人规模出题：单卡跑 7B 的项目不问 PD 分离与专家并行；跑过多机推理或千卡训练的必须追通信、故障与成本账。
- 手撕以 kernel 与系统组件为主（分块 softmax、KV cache 分配器、调度器的一步），不出纯算法题。
- 2026 年推理服务的架构主线是解耦：prefill 与 decode 分到不同 GPU 池（PD 分离）靠 KV 传输库连接，MoE 的注意力与专家层分开并行，长前缀靠基数树共享。面试官会追这些解耦各自换来了什么、代价在哪、什么规模才值得。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现 vLLM / SGLang / TensorRT-LLM 部署 → 追模型与卡型、QPS、TTFT 与 TPOT 的 P50 / P99、并发数、显存占用、开了哪些特性（prefix caching、chunked prefill、投机解码）各带来多少、质量回归怎么做
- 简历出现"推理加速 X 倍" → 追基线是什么（HF transformers 裸跑不算公平基线）、测量条件、batch 与序列长度、加速在 prefill 还是 decode、精度有没有掉
- 简历出现量化 → 追方法（GPTQ / AWQ / FP8 / SmoothQuant）、量化了权重还是激活还是 KV cache、精度回归用什么评测集、kernel 是现成的还是自己写的、实测吞吐变化
- 简历出现 CUDA / Triton 算子 → 追替代了哪个算子、瓶颈是算力还是带宽、用了什么手段（分块、共享内存、融合、访存合并）、profiler 里前后对比、在哪些 shape 下反而变慢
- 简历出现 KV cache 优化 → 追分页粒度、碎片率、prefix 命中率、驱逐策略、长上下文下 offload 到哪、对延迟的影响
- 简历出现投机解码 → 追草稿模型怎么选、接受率多少、什么请求分布下加速消失、和 batch 的冲突怎么处理
- 简历出现多卡 / 多机推理 → 追并行方式与切分维度、通信占比、PD 分离有没有做、负载不均怎么处理、一次掉卡的表现
- 简历出现 MoE 推理 → 追专家并行的路由与 all-to-all 开销、专家负载不均、显存怎么放专家、和稠密模型比吞吐差多少
- 简历出现训练框架 / 千卡训练 → 追并行策略（DP / TP / PP / SP / ZeRO 级别）、MFU 多少、通信占比、checkpoint 间隔与恢复时间、遇到过的慢节点与掉卡怎么定位
- 简历出现推理服务平台 → 追调度策略（FIFO / 优先级 / 公平）、抢占怎么做、多模型怎么共卡、SLO 怎么定与怎么守、成本怎么算到每千 token

## 常见失守与危险信号

- 推理两阶段与性能瓶颈：说不出 prefill 与 decode 各卡在哪；把所有延迟问题归结为"模型太大"；不知道 roofline 是什么
- KV cache 管理：只会说"缓存 K 和 V"；算不出每 token 的 KV 占用；不知道碎片为什么产生、PagedAttention 的块表怎么工作；prefix caching 只答"缓存前缀"说不出命中条件与失效
- 批处理与调度：分不清静态 batch、动态 batch、continuous batching；不知道 chunked prefill 解决 prefill 抢占 decode 的问题；调度只会 FIFO；不知道抢占后 KV 怎么处理（重算 vs 换出）
- 量化与算子：量化只知道"变小变快"；分不清权重量化与激活量化的难点；不做精度回归；写 kernel 不看 profiler；不知道 FlashAttention 省的是显存读写不是计算
- 服务架构与指标：只报平均延迟；分不清 TTFT、TPOT、ITL；没有 SLO；不知道排队时间和推理时间要分开看；多租户靶不到公平性
- 性能剖析与 GPU 体系结构：GPU 利用率低只会"加 batch"；不用 nsys / torch profiler；不知道 SM 占用率与显存带宽利用率的区别；共享内存与 bank conflict 说不清
- 多模型、多租户与成本：不知道每千 token 成本怎么算；不同模型共卡没有隔离；成本优化只想到换小模型
- 训练基础设施与集群：并行策略只会背名字；说不出 ZeRO 三级各分了什么；不知道 MFU；checkpoint 策略拍脑袋；掉卡只会"重跑"
- 开源引擎的源码级理解：只用过 API；说不出 vLLM 的 scheduler、block manager、model runner 各做什么；没有读过或改过任何一处源码

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### 推理两阶段与性能瓶颈
- 阶梯：一次生成请求分哪两段、各做什么 → prefill 为什么算力密集、decode 为什么显存带宽密集，roofline 怎么判断 → 单卡 7B 在 batch 1 与 batch 64 下瓶颈怎么变、TTFT 与 TPOT 各受什么影响 → 面向延迟还是面向吞吐的部署要在调度、并行、量化上各做什么不同的选择
- 答实的标志：能算权重与 KV 的显存、每 token decode 要读多少字节、算力与带宽比；知道 batch 加大先提吞吐后碰算力墙；能用 roofline 解释一次优化为什么有效或无效

### KV cache 管理
- 阶梯：KV cache 存什么、每 token 每层占多少 → 连续分配为什么碎片化、PagedAttention 的块表与按需分配解决了什么 → prefix caching（RadixAttention 之类）的命中条件、驱逐策略、多轮对话与系统提示的共享收益 → 长上下文下 KV 放不下怎么办：换出到 CPU、量化 KV、窗口与压缩的精度代价
- 答实的标志：能算 KV 占用并推出单卡最大并发；知道块大小对碎片与 kernel 效率的取舍；说得出前缀命中率怎么测、什么请求模式命中低；有一次 OOM 或拒绝请求的排查经历

### 批处理与调度
- 阶梯：静态 batch、动态 batch、continuous batching 的差别，新请求在哪一级插入 → chunked prefill 解决 prefill 抢占 decode 的问题；调度器每一步决定什么（谁跑、谁等、谁被抢占）→ 抢占后 KV 怎么处理（重算 vs 换出）、优先级与公平怎么做、排队时间怎么控 → 面向 SLO 的准入控制与降级：超载时拒绝谁、限流放哪一层
- 答实的标志：能画出调度器的一步；知道 max_num_seqs、max_num_batched_tokens 各限制什么；区分排队延迟与推理延迟；有抢占风暴或长尾请求拖垮 batch 的案例

### 服务架构与指标
- 阶梯：一个推理服务由哪几层组成（网关、路由、调度、worker、GPU 实例）→ TTFT、TPOT、ITL、吞吐各衡量什么，为什么只报平均没有意义 → 多模型多租户怎么共卡与隔离、优先级怎么体现、SLO 怎么定与怎么守 → 流式输出、超时、重试、可观测（每请求的排队 / prefill / decode 分段耗时）怎么设计
- 答实的标志：有 P50 / P99 与测量条件；区分排队与推理；每请求有分段打点；能说出 SLO 被打破时先看哪三个面板

### 性能剖析与 GPU 体系结构
- 阶梯：GPU 的执行模型（SM、warp、线程块）与内存层次（寄存器、共享内存、L2、HBM）→ 合并访存、bank conflict、occupancy 对 kernel 性能的影响 → GPU 利用率低怎么定位：数据加载、CPU 侧调度、kernel launch 开销、同步等待，用 nsys / torch profiler 看什么 → CUDA Graph、算子融合、编译（torch.compile / Triton）各消除什么开销
- 答实的标志：能读 profiler 的时间线并指出空洞；知道 SM 占用率高不等于算力用满；有一次从 profiler 找到根因的经历

### 多模型、多租户与成本
- 阶梯：每千 token 成本怎么算（卡时、利用率、吞吐）→ 多模型共卡：显存怎么分、切换代价、LoRA 多适配器服务 → 自建集群 vs 调 API 的成本临界点、峰谷弹性怎么做 → 成本、延迟、质量的取舍怎么落到路由策略（小模型先试、按优先级分池）
- 答实的标志：有成本模型与实际数字；知道利用率是成本的分母；多租户有隔离与公平机制

### 训练基础设施与集群
- 阶梯：数据并行、张量并行、流水并行、序列并行、ZeRO 三级各解决什么瓶颈、通信量怎么估 → MFU 怎么算、为什么千卡训练 MFU 常在 40% 上下、通信与计算怎么重叠 → 慢节点、掉卡、NCCL 超时、loss 尖峰的定位与处理，checkpoint 间隔与恢复时间的取舍 → 混合精度、梯度检查点、激活重计算对显存与速度的影响；训练与推理框架的权重格式转换
- 答实的标志：能给出某规模模型的并行配置与理由；知道 checkpoint 写入对训练的影响与异步写；有一次集群故障的时间线与事后改进

### 开源推理引擎的源码级理解
- 阶梯：vLLM / SGLang 的请求生命周期：从接收到流式返回经过哪些组件 → scheduler、block manager、model runner、worker 各做什么，一步调度怎么决定 batch → 加一个特性（新的采样策略、新的量化格式、新的调度策略）要改哪几处、怎么测 → 引擎之间的设计差异（分页 vs 基数树、Python 调度开销、多进程模型）与各自适合的场景
- 答实的标志：能画出一次请求的组件流转；读过或改过至少一处源码并能讲测法；能说出两个引擎在同一场景下的实测差异与原因