面壁智能大模型应用开发一面

1. 自我介绍

2. 项目拷打，重点说训练目标、数据构造和效果闭环

3. SFT 的损失函数怎么计算，如果样本长度差异很大要注意什么

SFT 本质上还是标准的 next-token prediction，常见就是对目标输出 token 做交叉熵损失。对于指令微调来说，通常不会对整个输入输出序列都算 loss，而是只对 assistant 部分或者需要学习的 target 部分做 mask。这样模型重点学习回答分布，而不是把用户输入再复述一遍。

样本长度差异很大时，最需要注意的是 loss 的归一化方式。如果直接对 batch 求和，长样本会天然占更大权重，训练会向长回答风格偏移。更稳的做法通常是按有效 token 数做平均，或者在 batch 构造时控制长度分布。

import torch
import torch.nn.functional as F

def sft_loss(logits, labels, ignore_index=-100):
    vocab_size = logits.size(-1)
    return F.cross_entropy(
        logits.view(-1, vocab_size),
        labels.view(-1),
        ignore_index=ignore_index
    )

4. GRPO 相对 PPO 的核心改进是什么，为什么很多人会关注它

GRPO 的重要改动在于，它弱化了对独立 value model 的依赖，更强调组内样本的相对比较。PPO 里一般要估计 value，再算 advantage，链路更长；GRPO 可以在同一个 prompt 下采多个候选，通过相对奖励或归一化收益来更新策略。这样做减少了一部分训练不稳定来源，也降低了工程复杂度。

它受关注的原因很现实：大模型后训练里，value model 本身就不一定好训，而且额外引入一套 value 链路会增加显存和调参负担。GRPO 不是把 RL 彻底简化掉，而是在大模型场景下做了更贴近工程成本的折中。

5. GRPO 的缺点是什么，如果让你改，你会往哪改

GRPO 最大的问题是它对组内采样质量非常敏感。如果同一组候选都很差，或者差异很小，那相对排序带来的训练信号其实很弱。第二个问题是它天然更偏相对优化，容易学到“比这组样本稍好”而不是“绝对意义上足够好”，这在高要求任务里可能不够。还有一个常见问题是奖励噪声会在组内放大，尤其裁判模型本身不稳定时更明显。

如果让我改，我会优先在三个地方动手：一是提高组内候选多样性，减少一堆近似答案互相比；二是引入更稳定的长度约束和格式约束，避免模型钻奖励空子；三是混入少量监督信号或者 reference regularization，防止训练后期行为塌陷。

6. 介绍几种并行训练方式，TP、PP、DP 分别适合什么场景

数据并行最直观，就是每张卡上放一份完整模型，切不同 batch 来算，最后同步梯度，适合模型还能放得下但想提高吞吐的场景。张量并行是把同一层里的矩阵切开到不同设备上一起算，适合单卡放不下单层参数或者算子特别大时使用。流水并行是把不同层放到不同设备上，micro-batch 像流水线一样流过各个 stage，更适合超深模型。

实际训练里通常不是三选一，而是混合并行。比如大模型最常见的是 DP + TP + PP 一起上。选型关键在于你卡间带宽、模型层结构、显存瓶颈和吞吐目标分别是什么。不是所有场景都值得上 PP，因为流水调度和 bubble 也会带来额外损失。