【暑期实习】蚂蚁 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 脑暴题时对一些更细的并发/层级关系表述还不够稳，有些地方思路到了，但表达没有完全收拢住。