【暑期实习】 百度 AI Infra 一面复盘

更偏推理基础、工程细节和 CUDA 手写题

这场百度 AI Infra 一面，整体感受是节奏很快，前半段主要围绕简历里的项目和实习经历往下问，后半段会明显转到一些更偏推理基础和工程理解的问题，最后还加了一道 CUDA 的手写题。面试官一开始先介绍了团队，说他们在百度智能云下面，训练、推理、强化学习、Agent 这些 AI Infra 相关方向基本都覆盖到了，所以一上来的感觉就是，这不是只盯某一个小点的岗位，而是一个工作面比较宽的 Infra 团队。

正式开始之后，前面还是从我现在做的事情切进来，重点还是摩尔线程这段实习。面试官先问我怎么理解自己在做的这个 TensorFlow MUSA Extension，到底是框架层的改动，还是 runtime 层的一些支持和优化。我这边的回答大意是，它更像是在 runtime 和插件这一层做适配、算子支持、图优化和融合，而不是直接去改 TensorFlow 框架本身。接着他又顺着我简历里的 PR 问到了那个 timing 宏，问得还挺细，比如它的计时原理是什么、CPU 侧和 GPU 侧各怎么计、为什么要做成插件里的补丁，而不是直接做进更底层的 profiling 工具里。我这里的回答主要还是围绕两层：一层是 CPU 侧通过开始和结束时刻去做总时间观测，另一层是 GPU 侧通过 event 去测 kernel 执行阶段；之所以做成这种轻量补丁，是因为当时更正式的工具不够成熟、也不够好用，所以先用一个侵入性更低、上手更快的方法去做粗粒度判断。

这个 timing 宏后面还被继续追问了一个挺好的问题，就是“观测者效应”。也就是说，你既然往代码里插桩，那这个插桩本身会不会影响原来的执行流、会不会让结果产生偏差。我这里也承认了确实会有这方面的问题，比如 event 和同步本身会带来额外开销，特别是在多流场景里，时间观测还可能被 mask 掉一部分真实情况。所以这个工具更适合做第一轮粗筛，判断一个算子更偏 compute bound、memory bound 还是 latency bound，真正想看更细的东西，还是要回到更正式的 profiling 工具上去。这个问题我觉得挺好，因为它不只是问你“会不会用工具”，而是在问你对工具边界有没有认识。

后面还聊到了图优化和单算子优化。图优化这块，面试官其实不太满意那种“我们开了个脚本，它就自动优化了”的说法，他更想听的是：你具体看到了什么、你做了什么、你怎么判断哪些算子值得优化。这里我后来举了一个更具体的例子，就是一个逻辑类算子在某个模型里出现很多次，而且其中某些 shape 是高频出现的，于是就针对这些高频 shape 做 fast path，比如标量和矩阵做逻辑运算时，不再先扩成完整矩阵再算，而是直接用广播的方式去做，这样就能省掉额外的内存申请和拷贝开销。整网里这种热点算子虽然只占一部分，但如果高频出现，整体吞吐还是能看到明显提升。这个地方能感觉到，百度这一面还是挺看重你能不能从“脚本”和“流程”里抽出一个足够具体的优化例子。

再往后，问题开始转到更偏大模型推理基础。比如他会直接问你：如果把一个 FP16 的权重量化成 INT8+FP32 scaling，这个量化过程怎么理解；scaling factor 怎么算；为什么要按绝对值最大值去决定范围；PagedAttention 提高的“利用率”到底是什么利用率；如果不用 PagedAttention，原来的问题在哪；大模型推理里常见的资源瓶颈有哪些。这里能感觉到，面试官是在有意识地把问题从“你做过什么项目”拉到“你对推理引擎和推理基础理解到什么程度”。我这边有些地方能答上来，比如 scaling factor 可以按绝对值最大值去对齐到 int8 范围，PagedAttention 本质上是在提高 KV Cache 这类资源的使用效率，避免固定大块分配造成浪费；但有些地方一继续往下问，就会暴露出自己更多还是偏项目经验，还没有完全形成系统化的推理引擎理解。比如他后来继续追问 vLLM 启动服务时到底会传哪些常见参数，我这里就比较虚，因为平时更多是跑脚本，没太系统地关注这些启动参数本身。

最后还有一道 CUDA 手写题，形式上是让你共享屏幕，用纯文本编辑器写一个 kernel 的核心内容。题目本身不复杂，就是最基础的 vector add。这部分面试官没有故意抬很高的难度，而是会盯着你写的东西继续问，比如为什么要加 if (id < n) 这种边界判断、为什么这里没有用 shared memory、block=256 和 warp 的关系是什么。这个题更像是在确认你对 CUDA 最基础的线程组织、block/warp 概念和简单 kernel 写法是不是熟，而不是想靠一道很难的题卡人。整体上，这一轮给我的感觉就是：前面看项目真实性，中间看推理和量化基础，最后用一个最基础的 CUDA 题确认下限。

整体下来，我觉得百度这一面和前面几家相比，一个很明显的特点是它既问工程，也问基础，但问法比较偏“从一个具体问题往背后的原理走”。比如 timing 宏不是问你怎么写的，而是问它会不会影响观测结果；PagedAttention 不是问你知不知道，而是问你具体提升了什么；量化不是问几个名词，而是问 scaling factor 怎么算。这种面法其实挺考验平时是不是把项目里的概念真正想明白了。对我自己来说，这一面相对顺的是前半段的实习项目和一些具体优化案例；相对一般的是大模型推理引擎这部分，还需要继续补得更系统一些。