Qwen Infra Research 面经

这里记录一下我面试 Qwen 研究实习生的经历，项目方向是前沿的 Infra Research。同期，我也尝试过 Dots Infra 与 DeepSeek 两个机会：或是 Mentor 直接联系，或是 HR 主动找上门，对我而言都很幸运。以当时尚未本科毕业的背景，若是自己投递，大概率也是石沉大海。

• Dots：推进到 HR 面后，我与负责跟进的 HR 沟通，主动终止了流程。

• DeepSeek：最终因种种原因未能成行。机考当天，恰逢我为博士零年级唯一一篇独立一作论文赶投稿，精力几乎耗尽；而 DeepSeek 的机考又极其漫长，对我这种没怎么刷过算法题的实战派来说，确实有些吃力。于是，我在考试界面里待了大约 30 分钟便退出了，几乎没怎么作答。后来，一位好心的猎头把我推荐给了某位 DeepSeek 内部人士。这位大佬做过一个在推理优化领域极具影响力的 Tutorial 类项目，我也从中受益颇多。按他的说法，我的简历很有竞争力，问题就出在机考太差。

• Qwen：在当时能够推进的机会里，它一开始就是我为自己圈定的最优解。一方面，面试流程没有难度过分的机考；另一方面，团队的知名度、影响力和实力都足够强。联系我的 Mentor（Huiqiang）在 MSRA 时期的论文，我早已拜读；Qwen 这边的团队又延续了 MSRA 的原班人马，因此选择他们，对我而言没什么可犹豫的。

对我而言，DeepSeek 大概仍是最向往的选择。但有些事由不得你：错过了就是错过了，未来是否还有机会，也不得而知。哪怕现在进入 Qwen 的团队已经是很顶尖的去处，但心中或许还是会有点遗憾吧，不过哪怕是在 Qwen，我周围的大家也都比我强很多，各个方面都有很值得蒸馏的人，好生蒸馏大家，才是我应该做的。

一面 — Mentor 面

这一面由我的直属 Mentor 面试，主要围绕我过去一年在 DLM 与 DLM Infra 上的一系列工作展开。

工作脉络大致是：D2F → LoPA → LightningRL → MBD-LMs。

其中重点聊了两块。其一是以 D2F 为基础提出的多块流水线化推理；其二是 MBD-LMs 在这一推理之上做的训推对齐训练方案——它能在稳定不掉点、甚至小幅提点的前提下，大幅提升各类 BD-LM 的 TPF。

此外，我还完整实现过一个 DLM 推理引擎，这也是我这一面最想展开的部分。它的核心后端正是基于 MBD 的思路搭建的：MBD 后端的 Block Buffer 机制让多块流水线得以跑通 CUDA Graph，并真正鲁棒地耦合进以 Paged Attention 为核心的状态机调度中；同时这套 Block Buffer 还能把 BD-LMs、MBD-LMs、Dual Cache 的块级推理等机制轻松糅合到同一个后端状态机下，再在 Sampler 等模块做特殊处理，从而顺带支持 T2T 推理；甚至只需稍作修改，也能很方便地支持 Diffusion Gemma 的推理——整体设计相当全面。

这个引擎从核心设计到搭建，都是在没有 CC 辅助的情况下独立完成的，算得上我能力上的“核心预训练”：它第一次把我此前散碎的知识与能力串成了一个整体。再加上从头做 MBD-LMs 时经历的洗数据、筛数据、多机多卡分布式训练、训练算子优化和训练算法设计，可以说，完整的训推流程我都亲手跑过一遍了，哈哈。

聊完这些，我们又大致探讨了 DFlash 一类工作与上述成果结合的可能方向。

最后，因为简历里提到我写过不少 Triton kernel，mentor 让我当场搓了一个 softmax kernel 出来（事后回想，当时有点紧张，没有用 online softmax）。

二面 — Infra Research Leader 面

这一面由我们小组的 Leader 面试，个人项目部分聊了和上一面差不多长的时间。可能因为我这一年的研究与工程脉络比较清晰、完整，能展开的话题也比较多。

在研究与项目之外，主要问了我几个问题。其中一个关于投机解码：同样生成 n 个 token，AR 逐 token 解码与 spec 的 draft–verify 流程，开销如何对比，后者在时间上又能省下多少？这个问题要说清楚其实并不容易——在单请求或小 batch 下，AR 的线性层计算通常接近 GEMV，生成 n 个 token 需要串行执行 n 次 forward；而 spec 可以把多个 draft token 放进一次 target forward 中并行验证，通过复用权重加载、提高计算利用率，摊薄每个 token 的推理成本。但最终能加速多少，还取决于每轮实际接受并推进的 token 数、verification 本身的耗时，以及 drafting 和其他额外开销，不能简单按 draft length 推算。我当时分析得不算好，毕竟我并非做 spec 出身，只能说大致知道它的执行路径。

另一个问题是：FA 为什么能做到 one pass？关键是 online softmax，以及它与两次 tiled GEMM 的融合。普通 attention 中，softmax 依赖整行分数的最大值和指数和，当前 tile 的最终归一化权重无法独立确定。FA 则在扫描 KV tiles 的过程中，持续维护逐行最大值、指数和与未归一化的输出累积量；最大值变化时，通过重缩放修正此前的贡献，再累加当前 tile 的结果，最后统一归一化。这样，对一个固定的 query tile，只需遍历其所需的 KV tiles 一遍，就能完成 QK、softmax 和 PV 的计算，无需将完整的 attention 矩阵写回显存后再读取。

三面 — RL Infra Leader 面

这一面由团队更上一级的 Leader 面试，依旧是经典起手：把前面几个项目和 paper 讲清楚。这部分已经聊过不少遍，我也比较熟悉了。

项目聊完，已经过去约一个小时，没再问多少其他问题，就直接进入了写代码环节。先来了一道 hard，因为不刷题，我依旧没能做出来（

于是，改让我写 FA2 的 Triton kernel。这个我还算熟练，搓了 40 分钟做出来，但已经没时间写测试了。Leader 大致检查后，认为没什么问题，便直接提交了。

四面 — HR 面

这一面是 HR 面，没聊太多，但结束后又给我安排了一轮面试，让我有些意外。

说实话，我当时以为要寄了。整个流程的面试轮数和实际强度，已经超出我对项目实习的预期；至少当时，我很少见到要求现场写 FA2 的面试。我一度怀疑是本科学校的原因，需要接受更高标准的考核。后来了解到，阿里云对 23 所高校有硬性要求；不在范围内，就需要凭足够强的实力取得信任，再由推荐人强推才能通过。

五面 — RL Leader 面

五面又是一位大 Leader，要求我极其简短地介绍自己的 paper：不展示 paper 或 blog，只靠口头表达，把自己在做什么讲清楚，并说服他。这一面倒是比较轻松地结束了。

面完后又等了两周，才收到 offer。整个流程走了差不多两个月——等到入职时，我投的 paper 都已经出分，开始 rebuttal 了（