硬核面经丨蚂蚁 AI Infra 实习从一面到三面实录- 大数跨境

首页

硬核面经丨蚂蚁 AI Infra 实习从一面到三面实录

知乎AI先行者

2026-07-10

做 AI Infra、大模型推理优化的同学，面试时最容易陷入一个误区：拼命背量化算法、CUDA 优化技巧、图优化 Pass 清单，以为把知识点记牢就能过关。

面试里实际会被问什么？

知友@草原小可汗如实记录了他在华为、百度、阿里云、蚂蚁等大厂每一场面试 AI Infra 岗位的完整过程，还把所有复盘内容系统整理成了专栏。

今天这篇，就是一份蚂蚁 AI Infra 岗的一、二、三轮面试复盘。他的专栏里还收录了更多大厂的面试复盘，感兴趣的可以点击文末「阅读全文」查看专栏。

@草原小可汗

发布于 2026 年 4 月 18 日

蚂蚁的 AI Infra 一面

算子优化、量化、图优化都问到了。

最近面了蚂蚁的 AI Infra 一面，整体感受是，这一轮比较偏工程理解，不是只问八股，更想看你是不是真的做过优化，能不能把问题、分析过程和思路讲清楚。

一开始是自我介绍，后面主要围绕我现在实习里做过的事情展开。面试官先让我讲了实习中解决过的一些问题，重点问到一个算子要不要优化，该怎么判断，以及如果决定优化，具体会怎么做。我这里主要是从热点分析、瓶颈判断和优化路径选择几个角度来回答。

比如先看它是不是耗时热点，再看问题到底是算力瓶颈、访存瓶颈，还是调度和启动开销，然后再决定是做 kernel 优化、算子融合、图优化，还是数据布局调整。

后面问得比较多的是量化。先考察了我对量化工作的理解，然后又给了一个开放题：如果给我一个还没有量化的模型，要怎么推进量化。我当时主要按自己的理解回答，大概是先分析模型结构和部署目标，再去选量化粒度、量化方案和校准方式，最后结合精度和性能去反复迭代。这一块我能答出思路，但说实话还不算特别系统，因为我现在接触更多还是偏推理侧和算子层优化，对完整模型量化流程的工程经验还不够多。

接着他追问了一个我觉得挺典型的问题，就是像 AWQ 这种量化方式，看起来其实给模型增加了很多步骤，

比如把 BF16 压成更低比特，计算的时候又要做一些反量化，那为什么最后整体还是会有加速。我当时给了两个理解。一个是量化之后权重更小了，带宽压力会下降，模型读取和访存效率会提升，很多推理场景本来就是 memory bound，所以即使多了一些量化和反量化步骤，总体吞吐还是可能更高。

另一个是量化往往不只是改数据类型，很多时候会和算子融合、数据排布优化一起做，这样虽然表面上步骤变多了，但中间 tensor 的搬运、读写和 kernel 切换次数减少了，所以总时间反而下降。

然后他又问了我在实习里写的一个 timing 插件，为什么要写，它底层是怎么实现的，解决了什么问题，以及为什么不用 Nsight、NCU 这种 profiling 工具直接做。我这里主要讲的是，这个插件更适合日常开发过程里的快速定位和粗粒度统计，接入成本低，迭代快，不需要每次都起完整 profiler，比较适合高频排查问题。

另外还问到了不同模型在本地部署和量化时会不会有明显差异，也问了图优化具体是怎么选的，开发流程是什么。还有静态图和动态图相关的问题，比如为什么很多时候要先把动态图转成静态图再去做融合优化，以及动态图和静态图转换本身的开销怎么处理。这部分我答得一般，因为我目前的经验还是零散的，没能把这块讲得特别体系化。

中间也问到了 vLLM。我这里其实有点可惜，因为源码我下过，但还没系统看完，所以只能回答一些比较浅的理解，比如它在推理调度、KV Cache 管理上的一些核心思路，以及我最近看过的一些 KV Cache 量化相关论文。这个地方也能明显感觉到，如果面的是 AI Infra，光知道概念还是不够，最好还是要往源码和实现细节里走。

后面还问了我在实习过程中有没有解决过比较困难的问题。我提到的是一个 OOM 和随机崩溃的问题，出现在长轮次推理或者训练中，会有显存异常增长以及随机退出的情况。我就讲了当时大概是怎么排查链路、定位原因，再一点点修复的。

最后还做了一道 LeetCode 题，是复制带随机指针的链表。这个题本身不算特别陌生，我给的思路就是先处理普通 next 链，再去处理 random 指针，整体思路还算顺下来了。

反问环节我主要问了两件事。一个是后续流程，面试官说大概还有三轮，应该是两轮技术面加一轮 HR 面。另一个是进去之后主要做什么，他说整体偏推理优化方向，他们团队本身是做强化学习相关的，但具体工作不只是单点算子，也会涉及上层框架、推理引擎、训练引擎、传输引擎和后面的算子优化。

整体下来，我觉得这一面不是那种很纯算法的面试，更像是在看你有没有真实做过 AI Infra 相关的事情，能不能把性能问题、定位过程和优化思路讲清楚。对我自己来说，这一面也暴露了几个短板，一个是模型量化流程理解还不够系统，一个是动态图、静态图和图优化这块还不够扎实，还有一个就是像 vLLM 这种推理系统，后面确实要继续补源码。

蚂蚁的 AI Infra 二面

项目深挖更细，还聊了一道 CUDA 脑暴题

这场蚂蚁二面的感觉和一面不太一样。一面更像是先确认你做过什么、懂到什么程度，二面则明显更深，基本是顺着项目细节一路往下追，尤其会反复确认你到底是不是亲手做过优化、怎么判断优化价值、怎么分析性能边界，以及你对更上层系统有没有兴趣。开场还是先让我用一个比较高层的方式讲实习经历、项目经历和职业规划，我这边还是重点放在了算子优化、图优化、量化推理 runtime 这些内容上。

项目部分一开始还是围绕我现在做的方向展开。我先讲了三个相对核心的点：一个是单算子优化，一个是稳定性问题修复，一个是算子融合。单算子优化这块，我举的是把旧的手写实现替换成高性能库实现，再做单测和整网测试的例子；稳定性问题这块，我讲的是一个多轮推理过程中随机崩溃和 OOM 的问题，最后定位到某个切片相关算子在 int32 场景下错误进入了 device path，导致维度信息异常，修完之后长轮数稳定性明显改善；算子融合这块，我讲的是先看整张静态图，再挑那些链条长、出现频次高、值得专门写融合算子的部分下手。整体上，这一轮比一面更在意「你怎么判断该不该做」，而不只是「你做没做过」。

面试官中间有一段问得挺细，他追着问我：如果目标是把一条推理链路的性能往上拉，最有效的方式到底是什么。我这里给的回答比较明确，主要还是两类。第一类是先看出现频次高的基础算子，对这些高频算子做单算子层面的性能优化，因为它们在整网里出现次数多，单点收益会被放大。第二类是看那些既重、又成链、而且在图里反复出现的算子组合，对它们做融合来减少中间张量搬运、kernel 启动和不必要的数据流转。这个回答后面又被继续追问，问到如果最后还是和目标性能有 gap，这部分差距主要来自哪。我这里的理解是两块：一块来自软件生态，很多实现如果还是早期手写版本，调度、内存管理、算子实现本身都会比较粗糙；另一块来自硬件上限，软件可以尽量逼近，但上限还是会被硬件制程和理论算力约束。

融合这一块也被专门展开聊了。面试官不是只问「你会不会融合」，而是问「你怎么判断哪一串适合融合」。我这里回答的逻辑是，先看一串算子的长度和出现次数，但这两个只是第一层筛选，更关键的是它们之间的依赖关系。最理想的情况是一个输入进来，中间是一串连续算子，最后汇成一个输出，中间这些节点不再被图中其他部分额外依赖，这样融合就相对直接。如果中间节点的输出还要流向别的分支，或者输入本身就依赖别的支路，那融合复杂度会明显上升，因为你不仅要算逻辑，还要处理好多余的输入输出接口。这个问题我觉得问得挺像真正做图优化的人会问的，因为它考的不是「知道 fusion 这个词」，而是你有没有真的看过图。

后面又聊到了 profiling 和性能分析的方法。面试官问我平时看性能数据会重点看什么，我这边回答得比较工程化：第一看总执行时间的拆分，先分清楚到底是启动开销、数据搬运还是计算本身占大头；第二看 warp 相关等待和分歧，因为 warp divergence 往往会直接影响实际执行效率；第三在有多流的场景下，会去看是不是形成了比较合理的流水。这个部分其实也和我平时做优化的习惯比较一致，就是先判断瓶颈属于哪一类，再决定是改 kernel、本地存储、数据布局，还是考虑融合和调度层面的事。

项目之外，这一轮还专门追问了量化。这里不只是问「你做过 W4A16 吗」，而是继续往为什么这么做、代价是什么、不同量化策略的取舍是什么这些问题上走。

比如面试官会让我解释 W8A8、W4A16 分别代表什么，也会继续追问，为什么权重量化到 4 bit 的时候，激活值很多场景下仍然要保留更高精度。我这边的思路还是从信息敏感度出发：权重相对更适合压缩，而激活值在不同输入下波动更大、极端值更多，如果对激活也做过激进的量化，最终推理正确性更容易受影响。后面还聊到了均匀量化、非均匀量化，以及非均匀量化在计算复杂度、额外 scale/zero point 存储和硬件加速适配上的代价。能感觉到，二面比一面更希望你把这些概念讲成「有工程取舍的东西」，而不是停留在定义上。

最后一段是一个比较典型的开放式 CUDA 脑暴题。题目本质上是做一个 histogram 类算子：输入是一组只会落在 0 到 9 这十个桶里的数，输出是每个桶里出现了多少次。面试官先让我讲最朴素的实现，我给的是线程读数据然后对对应桶做原子加；接着他引导我去分析这里面的性能问题，比如大量线程同时更新很少几个桶，会带来非常明显的写冲突。后面讨论的思路主要是把更新先收敛到 block 内的 shared memory 局部直方图，再在 block 结束时写回全局结果；中间会涉及 shared memory 使用时的同步，以及是否能让一个线程处理多个元素、通过更合理的数据分区方式改善访问模式。这个题我自己的感觉是，考的不是你能不能一次把最优代码写出来，而是你能不能顺着提示把问题往「冲突、局部归约、同步、访存模式」这些方向想下去。

整体下来，我觉得这场二面比一面更像一次真正的技术交流。它不只是继续确认你简历上的内容，更在看你有没有形成自己的分析框架。哪些算子值得做，哪些链路适合 fusion，性能 gap 应该怎么拆，量化为什么这样取舍，一道简单 CUDA 题里真正的瓶颈在哪，这些都不是靠背答案就能糊弄过去的。对我自己来说，这场里答得相对顺的是算子优化、图融合判断、量化取舍和性能分析方法；相对一般的地方，是现场写 CUDA 脑暴题时对一些更细的并发/层级关系表述还不够稳，有些地方思路到了，但表达没有完全收拢住。

蚂蚁的 AI Infra 三面

这一轮更偏大模型、量化和推理基础理解。

这场蚂蚁 AI Infra 三面，整体感觉和前两轮又不太一样。前两轮更多是在深挖我已经做过的项目，这一轮虽然也会问项目，但明显更关注我对大模型推理、量化、KV Cache、attention 这些基础问题到底理解到什么程度。开头还是先做自我介绍，我主要讲了自己现在在做的几个方向：一段偏工程化的软件开发经历，一段偏算子和图优化的实习经历，以及自己在做的一个基于 Python extension 的量化推理 runtime 小项目。

这一轮项目部分问得相对直接。面试官先让我展开讲了自己做的那个量化推理 runtime。我这边讲的是，基于一个开源 runtime 做了一些修改，把一个 8B 量级的模型做了 W4A16 量化，也就是权重量化成 Int4，激活保持 FP16，然后让它能够在一张显存比较小的消费级显卡上跑通前向。这里他继续追问的重点不是「有没有跑起来」，而是你到底做了哪些改动、量化到底落在了哪一部分、精度掉了多少、用什么数据集测的。这个地方能感觉出来，对方其实是在确认你是不是只会复现，还是对整个量化链路真的有理解。

后面又回到了我在实习里做的事情，问得还是比较聚焦。我讲了三个比较核心的点，一个是完善了一条融合链路和相关高性能库接入，一个是定位并修复了整网长跑中的稳定性问题，一个是设计并合入了一个轻量级的 timing 工具，用来快速分析 kernel 时间开销、判断瓶颈方向。这里我自己的感觉是，三面不会像前两面那样特别展开去抠某一个 bug 的链路细节，而是更想知道你做这些事情背后的方法论是什么。比如你这个 timing 工具为什么有用，它解决的不是「能不能测时间」这么简单，而是让你在 profiling 工具没那么成熟的时候，先快速判断一个算子更偏 latency bound、memory bound 还是 compute bound，再决定后面往哪里优化。

然后问题开始明显往大模型基础理解上走。

比如他会接着问，除了自己做过的 W4A16，你对 INT8、FP8 这些业界更常见的量化方案了解多少。这里我回答得相对中规中矩，主要是讲了 FP8 的两种常见格式、它在训练和推理里的不同适用性，以及为什么很多量化方案最后还是会在速度和精度之间做折中。接着又追问到了更细一点的点，比如 KV Cache 怎么算、为什么大模型推理里需要 KV Cache、attention 本身怎么理解、为什么 attention 往往比权重更难量化。这里能感觉出，对方其实是在看你是不是真的把 Transformer 推理过程想明白了，而不只是停留在几个术语上。

KV Cache 这一段我自己的感觉是，问得其实挺基础，但也挺容易暴露理解深度。比如怎么算 KV Cache 大小，背后其实就是 batch size、序列长度、head 数、head dim、层数、数据类型这些量一起决定的；

再比如为什么需要 KV Cache，本质上是为了避免每次生成新 token 时都重复计算历史 token 的 key/value，把前面已经算过的部分缓存下来，减少重复开销。

这种问题不一定难，但如果平时只是「知道有这个东西」，没真正往推理路径里去想，就会答得比较虚。

另外他还单独问到了 attention 怎么理解，以及为什么 attention 相关的量化更难做。我当时的回答还是比较偏直觉：attention 对数值分布更敏感，里面又有 softmax 这种对精度很敏感的步骤，所以很多时候大家更愿意先从权重或者 KV Cache 下手，而不是直接把 attention 这部分压得太激进。现在回头看，这个方向本身没错，但如果能把数值稳定性、动态范围、误差放大这些点说得更清楚，应该会更好。

整体下来，我觉得这场三面不像前两轮那样特别强调「你做了哪些优化」，而更像是在确认：你做过这些事情之后，对大模型推理这条链路本身到底理解到了什么程度。项目经历还是重要，但更重要的是你能不能从项目里抽出来，去回答更泛化的问题。对我自己来说，这一轮答得比较顺的是自己做过的量化项目、工具开发、以及一些工程实践上的东西；相对一般的是大模型推理这部分基础虽然知道一些，但还不够扎实，尤其是 KV Cache、attention、量化策略这些地方，如果后面继续面更深一点的 infra 岗，还是得系统补。整体氛围上，我感觉这一轮结束之后大概率已经接近流程尾声了，面试官也提到如果通过，可能就不再需要 HR 面。