不会手算GRPO显存，根本拿不到offer

---

去年年底，我一个朋友，拿了 PhD offer，没去。直接春招上岸了。

大包。

我盯着自己还在改的论文，脑子里就一个念头：要不我也不登校了，早点套现？

然后就开始疯狂刷面经。上 RL 方向的面经散得跟打翻的芝麻似的——有的藏在字节面经汇总里，有的埋在 Agent 面试攻略的评论区，还有几篇标题写着"AI面试经验"，点进去发现是卖课的。花了两周，我把它们全蒸馏了一遍，加上自己跟几个面试官聊完后的理解，整理出 35 道题。

这事儿比我想象的累多了。说实话。

先聊几个你在别处看不到的观察。

现在的 RL 面试，根本不区分你是做算法还是做 Infra。

我面某家公司的时候，前面还在聊 PPO 的 advantage 怎么算，面试官突然问：不考虑 CPU offload，GRPO 训练时显存里有几个模型？

我当时愣了一下。

后来算明白了。GRPO 显存里塞着三个模型：Actor、Reference Model、Reward Model。跟 PPO 比，它把 Critic 砍掉了——GRPO 用组内相对优势替代了价值网络。以 7B 模型为例，BF16 精度下单模型参数占 14GB，三个就是 42GB。再加上 Actor 的优化器状态 28GB、梯度 14GB，总共大概 84GB 左右。

绝了。

如果你做 CPU offload，把 Ref 和 Reward 扔到 CPU 上，能省到 56GB。再把优化器也 offload 掉，能压到 28GB——只留 Actor 在 GPU 上。但延迟会炸，通信瓶颈严重。最实用的方案是 Ref+Reward+Optimizer 全部 offload，大概能省 64% 显存，代价是通过 layer-wise offload 和通信-计算 overlap 来缓解延迟。

这事儿让我意识到一个残酷的事实：你不会算显存，就别想拿到 RL 岗的 offer。讲真，我面完那天晚上回去就开始手算各种模型配置的显存占用，算到凌晨两点。

算法题本身反而更有意思。

有个问题我特别喜欢：为什么要用 Actor-Critic 而不是纯 Critic？纯 Critic 方法——比如 DQN——在连续动作空间里基本是个灾难。你想想，每个时间步都要对 Q 函数做全局优化，动作空间连续的时候这根本不可解。Actor-Critic 把策略单独参数化成一个网络，梯度直接流过策略参数，连续空间里自然就解决了。

还有方差的问题。REINFORCE 的梯度估计方差极高，因为用的是完整回报。引入 Critic 做 baseline 之后，减去一个跟动作近似不相关的函数，方差大幅降低，期望还不受影响。这事儿数学上可以严格证明，但面试的时候你只需要说清楚直觉就行。

翻车了。

我第一次面的时候，被追问 LLM 场景下 Actor-Critic 有什么特殊考量。我没准备到这一层。后来查资料才发现，LLM 的 action space 是 token 级别的，极其巨大，Critic 要对每个 token 序列估计价值，这个值函数的方差比传统 RL 场景大得多。所以 GRPO 这类方法干脆不要 Critic，用组内相对比较来算 advantage。你品，细品——这玩意儿的设计逻辑其实特别直给，但没踩过坑的人就是想不到。

MoE RL 是个深坑。

DeepSeek 的技术报告我看了一遍又一遍。R1 系列最明确的是 GRPO、多阶段 RL、cold start 和 rejection sampling。V3 的重点是 MoE 架构、aux-loss-free load balancing、MLA 和 MTP，RL 细节没有完全展开。V3.2 的主要公开创新是 DeepSeek Sparse Attention，长上下文训练和推理效率。至于 V4——截至 2026 年 6 月，我没找到任何可靠的官方技术报告。

不能编。

但 MoE RL 的难点是可以说的。token-level logprob ratio 在 MoE 下方差更高，因为每个 token 的 expert routing 可能变化。expert 负载不均会影响训练稳定。训练和 rollout engine 的并行策略不同，会导致 logprob 和路由一致性问题。GSPO 这类 sequence-level objective 被 Qwen 报告能稳定 MoE RL，原因是 sequence-level ratio 对 token 局部波动不那么敏感。

这个方案——不对，应该叫策略——挺聪明的。把 ratio 的计算粒度从 token 级提升到 sequence 级，MoE 的路由波动自然就被平滑掉了。说白了，就是换个角度看问题，不跟 token 级别的噪声死磕。

RL Infra 的本质是什么？

不是训练。

是把推理系统和训练系统拼成一条不漏水的流水线。

字节的 verl 框架就是在做这件事。它不强行把训练和推理揉成同一种并行形态，而是承认二者天然不同：训练侧重重重反传加重通信，推理侧重高吞吐加长尾调度。verl 在两套系统之间搭桥，把数据流和参数流接起来。同步训练会浪费吞吐——同一批 prompt 里，有的样本很快结束，有的因为长推理链路拖很久，训练端经常空转等最慢的那几个 rollout。改成异步，又会引入策略陈旧、队列拥塞、失败重试这些新问题。

真的。

RL infra 的难点全在这些工程细节里，而不是什么高深的算法创新。我有个周末试着搭了个最小原型，光是把 rollout 结果正确喂回训练 pipeline 就搞了两天，各种 shape mismatch、device 不对齐、gradient 断流——debug 到怀疑人生。

关于 Data 相关的面试题，我一句都没整理。

因为根本没法背。

你做过什么样的 reward 设计、处理过什么样的数据分布偏移、踩过什么样的 reward hacking 坑——这些全靠实际经历。面试官聊两句就知道你是真做过还是背八股。我面某厂的时候，面试官问我 reward hacking 怎么检测，我说了一堆理论，他直接打断："你实际遇到过吗？怎么修的？"我当时就卡壳了。

没用。

这大概是我刷完所有面经后最深的感受：背题没用。打铁还需自身硬。

但话说回来，如果你连这 35 道题都说不清楚，面试官大概率不会给你机会证明自己有多硬。所以我还是建议你把这 35 道题过一遍，每道题都打开联网搜索，用 LLM 反复交互追问。别指望有标准答案。这些问题的延伸空间太大了，面试官随便往深了问都能问到你不会的地方。

这也是 RL 这个方向有意思的地方——它还没卷成八股文。

挺好的这东西。