大模型 AI Infra 方向面试
会有哪些经常提问的问题？
答主@笙囧同学 详细归类总结了六个模块的 AI Infra 面试问题、每个模块的考察逻辑和面试官想要听到的答案。
来看看他的总结：
答主@笙囧同学
中国科学院大学计算机技术硕士在读
主页：https://www.zhihu.com/people/ni-de-huo-ge-72-1
去年秋招的时候，我一个师兄面了六家公司的 AI Infra 岗，拿了四个 offer。有一天晚上我请他吃烤串，让他把每一轮面试被问过的问题尽可能回忆出来，我在旁边拿手机备忘录一条一条记。
那天晚上记了大概七十多个问题。
后来我又陆续找了几个面过这个方向的师兄师姐做了类似的事情，加上我自己面实习时候的经历，手里积累了一百多个真实面试问题。
我花了大概两周时间把这些问题做了归类和去重，发现一个很明显的规律——不管是哪家公司，AI Infra 的面试问题基本都落在六个模块里，而且每个模块的考察逻辑是高度一致的。
这篇回答就是把这六个模块拆开来讲。不只是列题目，更重要的是讲清楚每个模块的考察逻辑和面试官真正想听到的东西。因为 AI Infra 面试有一个特点——同一个问题，答到「知道」和答到「懂了」，面试官的评价差距非常大。
内容会比较长，建议先收藏。
先说一个前提：
AI Infra 面试到底在考什么
在列具体问题之前，有一件事你必须理解，不然准备方向会跑偏。
AI Infra 面试跟传统后端面试不一样，跟算法岗面试也不一样。它考的既不是「你能不能设计一个高并发系统」，也不是「你能不能推导一个 loss 函数」。
它考的是一种特殊的能力：你能不能站在模型和硬件的交界面上思考问题。
具体来说，面试官想看到的是——给你一个大模型推理或训练中的性能问题，你能不能从模型的计算特性出发，分析出瓶颈在硬件的哪个环节，然后给出针对性的优化思路。
这要求你同时理解两端。上面是模型——Transformer 长什么样、每一步在算什么、计算量和数据搬运量分别是多少。下面是硬件——GPU 的计算单元怎么工作、显存带宽是什么量级、数据在不同层次的存储之间怎么流动。
能把这两端连起来的人，就是 AI Infra 岗位要找的人。
理解了这一点，下面的六个模块你就知道该怎么准备了。
模块一：
Transformer 的计算分析
这是 AI Infra 面试的「入场券」，几乎 100%会考，而且通常出现在面试的最前面。答不好这部分，后面的问题面试官可能都不想问了。
但注意——这里考的不是算法岗那种「Attention 机制的设计动机是什么」「为什么要用多头」。AI Infra 面试考的是：你能不能把 Transformer 的每一步操作翻译成具体的计算量和访存量。
最典型的问题是：一次前向传播到底有多少 FLOPs？
这个问题的正确回答方式不是给一个 O(n²d）的复杂度就完了。面试官想听到的是你能把每一层拆开算——QKV 投影多少 FLOPs、QK^T 矩阵乘多少 FLOPs、Softmax 多少、Attention 乘 V 多少、FFN 的两层各多少。
你不需要记住精确的公式，但你得知道一个矩阵乘法 M×N 乘 N×K 的 FLOPs 是 2×M×N×K（一乘一加算两个浮点操作），然后现场推算出每一步的计算量。
面试官接下来大概率会追问两个方向。
第一个追问方向：这些计算在你的 GPU 上需要多久？理论上的最短时间是多少？
这就引出了 Roofline Model——AI Infra 领域分析性能的核心工具。你需要理解：一个计算任务的耗时，要么受限于「算力」（GPU 每秒能做多少次浮点运算），要么受限于「带宽」（GPU 每秒能搬运多少数据）。判断受限于哪一个的指标叫算术强度——就是计算量除以数据搬运量。
面试官经常会给你一个具体的场景——比如「Llama-2-70B 在 A100 上做推理，batch size 为 1，生成一个 token 需要多久」——让你现场估算。你需要知道 A100 的 FP16 算力大概是 312 TFLOPS，HBM 带宽大概是 2TB/s，然后根据模型参数量估算计算量和访存量，判断瓶颈在哪个环节，最终给出一个大致的时间估计。
这种估算不需要精确到小数点后两位，但数量级必须对。能做到这一步的候选人已经不多了。
第二个追问方向：Transformer 中哪些操作是计算瓶颈（compute-bound），哪些是访存瓶颈（memory-bound）？
这个区分非常关键，因为不同类型的瓶颈需要完全不同的优化策略。
大 batch 下的矩阵乘法（QKV 投影、FFN 层）通常是 compute-bound 的，因为计算量随 batch size 增长但数据搬运量增长较慢，算术强度比较高。
逐 token 生成阶段的计算通常是 memory-bound 的——因为此时 batch size 往往很小（甚至为 1），矩阵乘法退化成了矩阵向量乘，算术强度大幅下降，瓶颈变成了从显存读取模型权重的带宽。
Softmax、LayerNorm 这些 element-wise 操作也是 memory-bound 的，因为它们的计算量相对于数据搬运量来说很小。
如果你能流畅地讲清楚这个分类，并且解释清楚为什么 prefill 阶段和 decode 阶段的性能特征完全不同，面试官基本会认为你在这个模块过关了。
模块二：
FlashAttention 与算子优化
这是第二个高频模块。FlashAttention 几乎是必考题，但大部分人的回答都停留在「减少了 HBM 访问」这一句话。面试官真正想考的东西比这深得多。
面试官通常会这样问：FlashAttention 的原理是什么？为什么它能加速 Attention 计算？
回答这个问题你需要先讲清楚标准 Attention 慢在哪。标准实现中，QK^T 的结果是一个 seq_len × seq_len 的矩阵，这个矩阵在长序列下非常大。它会被写到 HBM（显存）里，然后 Softmax 读出来处理完再写回去，再跟 V 做矩阵乘。来来回回反复读写 HBM，而 Attention 这个操作本身的算术强度不高，是一个典型的 memory-bound 操作——瓶颈在数据搬运而不是在计算。
FlashAttention 的核心做法是 tiling 加上 online softmax。把 Q、K、V 分成小块，每次只加载一个小块到 SRAM（GPU 片上缓存，带宽比 HBM 高一到两个数量级），在 SRAM 上做完局部的 Attention 计算。通过一个数学上的技巧——在线更新 Softmax 的分母——让你不需要先算出完整的 QK^T 矩阵再做 Softmax，而是可以一块一块地增量计算。
这样，整个 Attention 过程中那个巨大的中间矩阵永远不需要写到 HBM 里，始终在 SRAM 上被就地消费掉了。
讲到这里面试官大概率会抛出一个追问，而这个追问是区分「背过答案」和「真正理解」的试金石：
「FlashAttention 的实际 FLOPS 比标准 Attention 更高（因为在反向传播时需要重计算），那为什么反而更快？」
如果你能回答「因为 Attention 是 memory-bound 的操作，瓶颈不在计算量而在数据搬运量。FlashAttention 用少量额外的计算换取了大幅减少的 HBM 读写，在 memory-bound 的场景下这笔买卖是划算的」——恭喜你，这个回答说明你真正理解了 Roofline Model 的思维方式，而不只是记住了 FlashAttention 的技术细节。
这也是为什么我把 Roofline Model 放在第一个模块讲——它是理解后面所有优化技术的钥匙。你会发现 AI Infra 领域的绝大部分优化，本质上都是在根据 Roofline 分析的结果做针对性的优化：compute-bound 的操作想办法提高计算效率，memory-bound 的操作想办法减少数据搬运。
面试官还可能追问 FlashAttention 的具体实现细节，比如 tiling 的 block size 怎么选、online softmax 的数值稳定性怎么保证、FlashAttention-2 相比 1 有哪些改进。这些细节建议你去读一遍原论文，不长，而且写得很清楚。
除了 FlashAttention 之外，这个模块还可能涉及到的问题包括：算子融合（kernel fusion）的原理和收益是什么、为什么把多个 element-wise 操作融合成一个 kernel 能显著提速、CUDA 编程的基本概念（grid、block、thread、warp 的关系）。
算子融合这个话题面试官特别喜欢问，因为它的道理很直觉但很多人说不清楚。核心就一句话：多个独立的 kernel 意味着中间结果要反复写回 HBM 再读出来，融合成一个 kernel 之后中间结果可以留在寄存器或 shared memory 里，省掉了大量的 HBM 读写。对于 memory-bound 的操作来说，这个收益是巨大的。
模块三：KV Cache 与推理系统
这个模块考的是大模型推理系统的核心痛点。如果你面的是推理方向的 AI Infra 岗位，这部分的权重会特别高。
KV Cache 是什么、为什么需要它、它带来了什么问题。 这三个问题几乎是一套连环问，面试官会一口气问下来。
为什么需要：自回归生成的时候，每生成一个新 token 都要对之前所有 token 做 Attention。如果每次都重新计算之前所有 token 的 K 和 V，计算量会随序列长度增长而快速膨胀。KV Cache 的做法是把之前算过的 K 和 V 缓存在显存里，每一步只算新 token 的 Q/K/V，然后拼上缓存的 KV 来做 Attention。用空间换时间。
带来的问题：显存占用。这个问题的严重程度很多人低估了。我给你算一笔账——Llama-2-70B，80 层，8 个 KV head，每个 head 维度 128，FP16 精度下一个 token 的 KV Cache 占用 80×8×128×2（K 和 V）×2 字节 = 327,680 字节 ≈ 320KB。听起来不多对吧？但如果序列长度是 4096，那就是 4096×320KB ≈ 1.3GB。如果你同时服务 32 个请求，就是 32×1.3GB ≈ 41.6GB。比模型参数本身占的显存还大。
所以 KV Cache 的管理几乎是推理系统设计的头号挑战。面试官接下来一定会问：怎么优化 KV Cache 的显存占用？
这个问题可以从多个层次回答。
架构层面的优化——GQA 和 MQA。标准的 Multi-Head Attention 每个 head 都有独立的 K 和 V。MQA（Multi-Query Attention）让所有 query head 共享同一组 KV，KV Cache 直接缩小到原来的 1/n_heads。GQA（Grouped Query Attention）是 MQA 的折中方案，每几个 query head 共享一组 KV。Llama-2-70B 用的就是 GQA，8 个 KV head 被 64 个 query head 共享，KV Cache 比标准 MHA 小了 8 倍。
数值层面的优化——对 KV Cache 做量化。把 KV 从 FP16 量化到 INT8 甚至 INT4，显存直接减半或减到四分之一。这个做法的难点在于 Attention 计算对 KV 精度比较敏感，量化太激进可能影响生成质量。
系统层面的优化——这里面试官最想听的是 PagedAttention，也就是 vLLM 的核心技术。传统实现给每个请求预分配一整块连续显存来放 KV Cache，大小按最大序列长度来留。但大部分请求根本用不到最大长度，导致大量显存浪费，而且产生严重的碎片化。
PagedAttention 借鉴了操作系统虚拟内存的分页机制——把 KV Cache 分成固定大小的 block（类似内存页），按需动态分配，不要求连续存储，用一个类似页表的数据结构来管理映射关系。
如果你在回答时能自然地把 PagedAttention 跟操作系统的虚拟内存做类比——「它就像操作系统用分页来解决物理内存碎片化的问题，PagedAttention 用同样的思路解决 KV Cache 的显存碎片化问题」——面试官通常会很满意。因为这说明你不是孤立地记住了一个技术名词，而是理解了它背后的设计思想，并且能跟计算机体系结构的基础知识关联起来。
这个模块还有一组高频问题是关于推理阶段的两个不同 phase 的：prefill 和 decode 的区别是什么？它们的性能特征有什么不同？
这个问题答好了能展现出你对推理系统的整体理解。
prefill 阶段是处理用户输入的 prompt。此时你有一整段文本需要一次性处理，矩阵乘法的维度比较大，通常是 compute-bound 的，GPU 的计算单元可以被充分利用。
decode 阶段是逐 token 生成。每次只生成一个 token，矩阵乘法退化成矩阵向量乘，算术强度大幅下降，变成 memory-bound 的。此时 GPU 大部分时间不是在算，而是在等数据从显存搬过来。
这两个阶段的性能特征完全不同，所以优化策略也不同。一些推理框架（比如 Sarathi、Splitwise）甚至把 prefill 和 decode 拆到不同的 GPU 上分别处理，就是因为两者的资源需求模式差异太大，混在一起会互相干扰。
面试官在这里还可能追问 continuous batching 的原理——传统的 static batching 要等一个 batch 里所有请求都生成完才能开始处理下一个 batch，导致先完成的请求白白等待。continuous batching 允许请求动态地加入和退出 batch，显著提升了吞吐量。vLLM、TGI 这些推理框架都实现了这个机制。
模块四：并行策略与分布式训练
面训练方向的 Infra 岗位时这个模块是重中之重，面推理方向也会涉及但深度要求低一些。
核心问题就一个：大模型太大了一张卡放不下，怎么把它分到多张卡上训练或推理？
围绕这个问题，你需要理解四种并行策略，以及它们各自的适用场景和 trade-off。
数据并行是最直觉的——每张卡上放一份完整的模型，不同卡处理不同的数据，算完梯度之后做 AllReduce 同步。优点是实现简单、通信模式规整。限制是模型必须放得进单张卡的显存。
张量并行是把单个层的权重矩阵切开分到多张卡上。
比如一个矩阵乘法 Y = XW，可以把 W 按列切成两半 W₁和 W₂，两张卡分别算 XW₁和 XW₂，最后拼起来就是完整的 Y。优点是能解决单层参数太大的问题。代价是每一层的计算都需要卡间通信（AllReduce 或 AllGather），对卡间带宽要求非常高，通常需要 NVLink 这种高速互联。
流水线并行是把模型的不同层放到不同卡上。卡 1 放前 20 层，卡 2 放中间 20 层，卡 3 放后面 20 层，数据像流水线一样依次流过。优点是通信量小——只需要在层的边界传递激活值，不需要每一层都通信。缺点是存在「流水线气泡」——当卡 1 在算第二个 micro-batch 的时候，卡 3 在等第一个 micro-batch，中间有空闲。
面试官在这里最喜欢问的追问是：这些并行策略怎么组合使用？ 因为实际的大模型训练中，单用一种策略几乎不可能满足需求，必须混合使用。
比如 Megatron-LM 的经典方案：节点内的多张卡之间用张量并行（因为节点内有 NVLink 高带宽互联），节点之间用流水线并行（节点间带宽较低，流水线并行的通信量小），然后在此基础上再叠加数据并行来扩大 batch size。
如果你能讲清楚为什么要这样组合——「因为张量并行通信频繁但每次通信量不大，适合高带宽低延迟的节点内互联；流水线并行通信不频繁但可能有气泡，适合带宽相对低的节点间互联」——面试官会觉得你是真正理解了，而不是背了个方案。
另一个在这个模块经常出现的问题是 ZeRO（DeepSpeed 提出的）。ZeRO 的核心思路是：数据并行时每张卡都存了一份完整的模型状态（参数、梯度、优化器状态），这非常浪费。ZeRO 把这些状态切分到不同卡上，每张卡只存一部分，需要的时候通过通信获取。ZeRO 分三个 stage，分别切分优化器状态、梯度和参数，切得越多省显存越多但通信越多。
模块五：量化与模型压缩
这个模块在面试中的出现频率很高但深度要求因岗位而异。面推理部署方向的会问得很深，面训练方向的可能只是浅问一下。
最基本的问题：什么是模型量化？为什么能加速推理？
很多人回答「量化就是把 FP16 变成 INT8/INT4，模型变小了所以快了」。这个回答不算错但太粗糙了，面试官一追问就露馅。
更准确的理解是：量化在两个维度上带来收益。
第一个维度是显存占用减少——参数从 2 字节（FP16）变成 1 字节（INT8）或 0.5 字节（INT4），模型直接缩小一半到四分之一。这意味着更大的模型能塞进同一张卡里，或者同样的模型能服务更大的 batch。
第二个维度是访存量减少——前面讲过，decode 阶段是 memory-bound 的，瓶颈在于从显存搬运模型权重的带宽。权重从 FP16 变成 INT4 之后，需要搬运的数据量减少了四分之三，对于 memory-bound 的操作来说，这直接转化为速度的提升。
注意量化不一定能让计算本身变快——因为 GPU 的 INT8/INT4 计算单元不一定比 FP16 快，甚至有时候还需要额外的反量化操作。量化的核心收益在访存端而不在计算端。
这个理解跟 Roofline Model 是一脉相承的。如果面试官追问」为什么量化对 decode 加速明显但对 prefill 加速不明显」，你就能回答：因为 prefill 是 compute-bound 的，瓶颈在计算不在访存，减少访存量对它帮助不大。
量化方法方面，面试官经常问的是 GPTQ、AWQ 和 GGUF 之间的区别。你不需要能手推这些方法的数学细节，但需要理解它们的核心思路差异。
GPTQ 的思路是逐层量化——固定其他层，把当前层的权重量化，通过最小化量化前后输出的差异来选择最优的量化参数。它利用了权重矩阵的 Hessian 信息来决定每个权重的量化精度，让重要的权重保持更高精度。
AWQ 的思路略有不同——它观察到模型中不同的权重通道（channel）对输出的影响程度差异很大，有一小部分通道特别重要。AWQ 通过对输入做等价的缩放变换，让这些重要通道在量化时保持更高的有效精度。
GGUF 主要是 llama. cpp 生态使用的量化格式，支持 CPU 上的高效推理，对各种混合精度方案支持得比较好。
面试官在这里真正想考察的不是你记住了多少技术细节，而是你有没有一个统一的思维框架来理解这些不同的量化方法。如果你能说」这些方法的核心都是一样的——在有限的 bit 预算下，把精度分配给对模型输出影响最大的那些权重，只是识别』重要权重』的方式不同」，这就很好了。
模块六：系统设计与工程能力
前五个模块偏「知识」，这个模块偏「能力」。它考的不是你知道什么，而是你能不能把知道的东西串起来解决一个完整的问题。
最典型的形式是一个开放式的设计题，
比如：「设计一个大模型推理服务系统，要求支持多用户并发、低延迟、高吞吐。你会怎么设计？」
这种题没有标准答案，面试官看的是你的思考过程和分析框架。
一个好的回答通常会从这几个维度展开——
首先要定义清楚问题的约束和目标。延迟要求是什么量级的？吞吐要求是什么量级的？模型多大？硬件资源是什么？这些约束条件决定了后续的设计选择。不问清楚就直接开始设计，面试官会觉得你缺乏工程思维。
然后从请求的生命周期来设计——一个请求进来之后经历了什么。接收请求、排队调度、prefill、decode、返回结果。每个环节有什么瓶颈、可以做什么优化。
调度层面你可以提 continuous batching——请求动态加入和退出，不需要等整个 batch 都完成。内存管理层面你可以提 PagedAttention。计算优化层面你可以提 FlashAttention、量化、投机解码（speculative decoding）。
投机解码是一个面试中加分很多但很多人不知道的话题。核心思路是用一个小模型快速生成多个候选 token，然后用大模型一次性验证。由于验证（prefill）比逐个生成（decode）高效得多，如果小模型猜对的概率足够高，整体速度就能提升。这本质上是一种用「计算换延迟」的策略——你用了额外的小模型计算，但如果能连续猜对几个 token 就省掉了几轮 decode 的等待时间。
如果面试官问到多模型调度、弹性扩缩容这些话题，就更偏系统设计了。这部分的准备方式跟传统后端的系统设计面试比较像——了解负载均衡、服务发现、资源调度的基本概念，然后结合 AI 推理的特殊性来设计。
最后说几句关于准备策略的建议
这篇写下来，内容已经很多了，但我还是想在最后补充几句关于怎么准备的建议。这些是我自己的体会加上几个师兄给我的忠告，我觉得比任何具体的知识点都更有价值。
第一，不要背八股，要建立思维框架。
AI Infra 面试最忌讳的就是背诵式的回答。面试官一听就能听出来，而且他会故意追问一两层来验证你是不是真懂。如果你只是背了一个结论，追问两层就会卡住。
正确的准备方式是理解少数几个核心分析工具——Roofline Model 是最重要的一个——然后用这些工具去分析每一个具体的技术。当你能用同一个框架解释 FlashAttention 为什么快、量化为什么能加速 decode、为什么 prefill 和 decode 的性能特征不同的时候，你就不需要背任何东西了，因为这些结论都是你现场推出来的。
第二，读论文比读博客有用得多。
FlashAttention、PagedAttention（vLLM）、Megatron-LM、DeepSpeed ZeRO——这几篇论文是 AI Infra 方向的「必读文献」。不多，加起来也就五六篇。但每一篇都建议认真读原文，而不是只看别人的解读。因为面试中经常会问到论文里的细节和动机，二手信息的准确度和深度是不够的。
第三，动手跑比光看更重要。
如果你有条件的话（哪怕只有一张消费级显卡），自己跑一跑推理框架——vLLM、TGI、llama. cpp——感受一下不同配置下的性能差异。比如同一个模型，batch size 从 1 调到 32，观察吞吐和延迟怎么变化。或者同一个模型，FP16 和 INT4 量化版本的速度差多少。
这种第一手的体感在面试中非常有用。当面试官问你「某个优化能带来多大的提升」时，如果你能说「我自己测过，在某某配置下大概能提升多少」，可信度和说服力跟「我在论文里看到说能提升多少」完全不一样。
以上就是我整理的 AI Infra 方向面试的核心内容。
这个领域的技术迭代很快，具体的面试题目会随着新技术的出现而更新，但底层的考察逻辑——模型和硬件的交界面上思考问题——这一点不会变。
这篇是我目前为止写过最长的一篇回答了，花了不少时间整理和校对。如果你正好在准备这个方向的面试觉得有用的话帮忙点个赞，后面如果有精力我会再写一篇关于 AI Infra 方向怎么准备项目经历和简历的。
最后附上大厂面经
https://zhuanlan.zhihu.com/p/2011420267147190709
阅读更多
🚀 AI 产品扶持计划：
知乎为 AI 产品提供定制宣发支持，了解/报名请戳：知乎「AI 新品非正式发布现场」扶持计划
🚀 知乎 AI 社群：
如果你是泛 AI 爱好者，对 AI 资讯感兴趣，欢迎扫码加入知乎 AI 社群↓，我们将每周送上 AI 周报，不定时发布 AI 线上线下活动与 AI 产品测试尝鲜。
知乎AI交流群
让一部分开发者先走起来
🚀 知乎科技账号正式登陆 X：
👉 https://x.com/ZhihuFrontier，聚焦「技术 × 观点」的跨语境对话