LoRA两种实现方案是否存在差异？性能差异原因探究

我们知道LoRA是一种低秩适配方法，公式可表示为：x = W_0 * x + (A @ B) * x。我实现了两种不同的代码版本，现询问二者是否存在差异？

Code 1 #

def forward(self, x):
    x = x @ self.lora_A
    x = x @ self.lora_B
    x = self.scaling * x
    return x

Code 2 #

def forward(self, x):
    x = x @ (self.lora_A @ self.lora_B)
    x = self.scaling * x
    return x

从数学角度看二者似乎等价，但在玩具数据集上测试时，我发现Code 2性能略优。这种细微差异为何出现？是否存在计算或优化层面的深层细节可以解释？

我不确定两种实现是否都正确，GitHub仓库中常见Code 1，但Code 2表现更好，这是为什么？

1. 数值精度差异导致的结果偏差 #

从线性代数理论上，(x @ A) @ B 和 x @ (A @ B) 确实等价，但在浮点数计算（如FP16/FP32）中，舍入误差的累积方式不同：

• Code 1是分步计算，两次矩阵乘法都会引入舍入误差，误差会叠加；
• Code 2先合并A@B得到一个低秩矩阵，再和x相乘，仅产生一次乘法的舍入误差，整体数值稳定性更好，最终结果的精度更高，反映在性能上就会有细微优势。

2. 框架优化与计算效率的隐性影响 #

实际训练中，深度学习框架（如PyTorch/TensorFlow）的自动微分和计算优化策略会带来差异：

• Code 1中A和B是独立可训练参数，反向传播时梯度分开计算更新；Code 2前向先合并矩阵，反向传播时框架可能对梯度计算做特定优化，比如减少中间张量的内存占用，间接提升训练稳定性；
• 合并矩阵后与x相乘的计算逻辑，在部分场景下（如大batch size）计算效率更高：A@B是一次性计算，后续仅需一次大矩阵乘法，缓存命中率更高，训练收敛速度更快，也会体现为性能略优。

3. GitHub常见Code 1的原因 #

• 贴合LoRA设计初衷：LoRA核心是冻结主权重，仅训练低秩分解的A、B矩阵，分开计算的结构更直观体现“低秩适配”的分解逻辑；
• 灵活性更强：后续若需调整A/B的秩、单独替换其中一个矩阵，Code 1的结构更易修改，而Code 2需要重新合并矩阵；
• 显存占用更低：训练时Code 1无需额外存储A@B的合并矩阵，在大规模模型训练中，显存的微小节省也会被优先考虑。

4. 两种实现的正确性 #

两种实现都是正确的，完全符合LoRA的数学公式。性能差异仅来自数值计算精度和框架优化层面的细微区别，而非逻辑错误。

内容的提问来源于stack exchange，提问作者heeee1p