业务场景
我们用LoRA微调一个7B的中文对话模型。跑了12个小时，loss从3.2降到1.8，看起来很正常对吧？但我第二天一看验证集BLEU和ROUGE，和没训之前几乎一模一样。这不对劲。
业务目标是让模型在特定领域（比如客服对话）上表现更好。我们有个大概3000条人工标注的对话数据，都是真实用户query和标准回复。训练环境是一台8卡A100机器，显存绰绰有余，所以排除了资源瓶颈。
我第一反应是数据质量问题，检查了两遍对话数据的格式和长度分布，没发现异常。然后怀疑是epoch不够，又跑了6小时，loss继续降到1.2，验证指标还是纹丝不动。
这时候我才反应过来，问题可能不在数据，而在训练过程本身。
问题定位
先说结论：最后定位到是梯度消失问题。
当时我没有在训练循环里加梯度统计，只是看loss下降就以为一切正常。回过头补上梯度监控之后，发现问题了——
import torch
from torch.utils.data import DataLoader
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model, TaskType
# 训练循环里加这个回调
def gradient_stats_hook(module, grad_input, grad_output):
"""每层梯度范数统计"""
if grad_output[0] is not None:
grad_norm = grad_output[0].norm().item()
module._grad_norm = grad_norm
# 注册hook到所有LoRA层
model = AutoModelForCausalLM.from_pretrained(
"meta-llama/Llama-2-7b-hf",
device_map="auto",
torch_dtype=torch.float16
)
lora_config = LoraConfig(
task_type=TaskType.CAUSAL_LM,
r=16,
lora_alpha=32,
lora_dropout=0.05,
target_modules=["q_proj", "v_proj", "k_proj", "o_proj"]
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 给所有可训练参数挂hook
for name, param in model.named_parameters():
if param.requires_grad:
param.register_hook(lambda grad, n=name:
print(f"[{n}] grad_norm={grad.norm().item():.6f}")
)跑了一个step，输出把我吓到了：
[lora_B.weight] grad_norm=0.0234
[lora_A.weight] grad_norm=0.0001
[model.layers.0.self_attn.q_proj.lora_B.weight] grad_norm=0.0218
[model.layers.0.self_attn.q_proj.lora_A.weight] grad_norm=0.00008
...
[model.layers.30.self_attn.q_proj.lora_B.weight] grad_norm=0.0192
[model.layers.30.self_attn.q_proj.lora_A.weight] grad_norm=0.00002看到了吗？所有层的lora_B.weight梯度范数在0.02左右，但lora_A.weight梯度只有0.0001左右，差了200倍。
数据说明
训练数据来源
我们的训练数据是内部积累的客服对话，用transformers的对话模板处理过。大概长这样：
{
"conversations": [
{"role": "user", "content": "我的订单号是20240115，什么时候发货？"},
{"role": "assistant", "content": "您好！查询到您的订单，预计48小时内发货。"}
]
}数据量3000条，平均每条对话长度约512 tokens。用的是ChatML模板，在user和assistant消息前后加了特殊标记。
数据预处理
数据加载时做了这几件事：
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf", trust_remote_code=True)
def preprocess_function(examples):
# 拼接对话历史，加上特殊token
texts = []
for conv in examples["conversations"]:
text = ""<|im_start|>user\n" + conv[0]["content"]
text += "<|im_end|><|im_start|>assistant\n" + conv[1]["content"]
text += "<|im_end|>"
texts.append(text)
# tokenize，labels拷贝input_ids
model_inputs = tokenizer(texts, max_length=512, truncation=True, padding="max_length")
model_inputs["labels"] = model_inputs["input_ids"].copy()
return model_inputs预处理这块我没发现问题，后来定位到问题在模型本身的训练逻辑。
数据分布检查（容易踩的坑）
我后来又遇到过一次类似问题，这次不是初始化问题，而是数据问题。
数据集里某个特殊token占比超过40%，导致模型只要预测这个token就能把loss拉低，但实际上什么都没学到。这种情况下梯度消失是表象，真正的问题是数据不平衡。
排查方法：
from collections import Counter
import torch
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-hf")
# 统计token分布
all_token_ids = []
for sample in dataset:
tokens = tokenizer.encode(sample['text'])
all_token_ids.extend(tokens)
token_counts = Counter(all_token_ids)
total = sum(token_counts.values())
# 打印最常见的20个token
print("Top 20 tokens:")
for token_id, count in token_counts.most_common(20):
token_str = tokenizer.decode([token_id])
pct = count / total * 100
print(f" [{token_id:5d}] '{token_str}' -> {pct:.2f}%")
# 检查特殊token比例
special_tokens = tokenizer.all_special_ids
special_ratio = sum(token_counts[t] for t in special_tokens) / total
print(f"\nSpecial tokens ratio: {special_ratio:.2%}")
# 如果超过5%，说明有问题
if special_ratio > 0.05:
print("⚠️ WARNING: Special token ratio too high, may cause gradient issues")根因分析
LoRA梯度消失的原理
这里得解释下LoRA的结构，不然说不清楚为什么会出现这个问题。
LoRA的核心是低秩分解。对于一个原始权重 $W \in \mathbb{R}^{d \times k}$，LoRA引入两个矩阵：
- $A \in \mathbb{R}^{r \times k}$，用随机初始化
- $B \in \mathbb{R}^{d \times r}$，初始化为零
前向计算变成：
$$h = W \cdot x + B \cdot A \cdot x$$
问题出在初始化上。$B$初始化为零，意味着训练开始时 $B \cdot A = 0$，新增的路径对输出没有任何贡献。然后梯度从 $h$ 回传到 $B$ 和 $A$，但 $A$ 的梯度要经过 $B$ 才能影响输出——这形成一个链式依赖。
具体来说，$B$ 的梯度是：
$$\frac{\partial L}{\partial B} = \frac{\partial L}{\partial h} \cdot (A \cdot x)^T$$
而 $A$ 的梯度是：
$$\frac{\partial L}{\partial A} = B^T \cdot \frac{\partial L}{\partial h} \cdot x^T$$
训练刚开始时 $B = 0$，所以 $\frac{\partial L}{\partial A} \approx 0$，$A$ 几乎收不到梯度。而 $B$ 的梯度虽然有，但量级很小，因为 $A \cdot x$ 的初始输出也在零点附近。
这就是所谓的”梯度消失”——不是真的消失，而是初始化导致 $A$ 被锁死了，只有 $B$ 在微弱地更新。
用optimizer状态验证
梯度监控确认了问题，但我还想看看optimizer实际在做什么。
# 训练几个step后检查optimizer状态
optimizer = torch.optim.AdamW(
model.parameters(),
lr=2e-4,
betas=(0.9, 0.999),
weight_decay=0.01
)
# 模拟几步训练
for batch in dataloader:
outputs = model(**batch)
loss = outputs.loss
loss.backward()
optimizer.step()
optimizer.zero_grad()
break # 看第一步之后的状态
# 检查exp_avg和exp_avg_sq
print("=== Optimizer State Analysis ===")
for name, param in model.named_parameters():
if not param.requires_grad:
continue
state = optimizer.state.get(param)
if state is None:
continue
exp_avg = state['exp_avg']
exp_avg_sq = state['exp_avg_sq']
print(f"\n{name}:")
print(f" param mean: {param.data.mean():.6f}, std: {param.data.std():.6f}")
print(f" exp_avg mean: {exp_avg.mean():.8f}, std: {exp_avg.std():.8f}")
print(f" exp_avg_sq mean: {exp_avg_sq.mean():.8f}")
print(f" update/param ratio: {(exp_avg / (exp_avg_sq.sqrt() + 1e-8)).mean():.8f}")输出大概是这样：
=== Optimizer State Analysis ===
lora_B.weight:
param mean: 0.002341, std: 0.015623
exp_avg mean: 0.000023, std: 0.000156
exp_avg_sq mean: 0.000061
update/param ratio: 0.029412
lora_A.weight:
param mean: 0.031256, std: 0.100523
exp_avg mean: 0.000001, std: 0.000005
exp_avg_sq mean: 0.000000
update/param ratio: 0.000823lora_A的exp_avg_sq几乎是零，说明它几乎没收到过有效的梯度。而lora_B虽然状态也不活跃，但比A好太多了。
参数说明
rank和alpha的取值依据
我用的是r=16, lora_alpha=32，这两个数是怎么定的？
rank的选择：
rank决定了低秩矩阵的秩，也即LoRA层能表达的线性空间维度。我当时考虑的是：
-
rank=8：太保守了。7B模型有4096的hidden_size，rank=8意味着每个LoRA层只有64维的表示能力。对于客服对话这种需要捕捉语义细微差别的任务，8可能不够。
-
rank=32：理论上表示能力更强，但显存占用也会翻倍。3000条数据的小任务，用32有点 overkill。
-
rank=16：折中方案。实测下来，rank=16在大多数垂域微调场景够用了。除非你的任务需要非常细粒度的指令遵循（比如复杂的数学推理），那时候再考虑32或64。
alpha的选择：
alpha是缩放因子，最终scale = alpha / rank。alpha=32意味着scale=2，也就是LoRA分支的输出权重是2倍。
公式上，最终输出是 h = Wx + (BAx) * (alpha/r)。如果alpha太小，LoRA的贡献被压得很低；如果alpha太大，可能破坏预训练学到的知识。
我一般alpha设为rank的2倍，也就是固定scale=2。如果训练不稳定（loss爆炸），会降低alpha到1.5倍或1倍。
target_modules的选择
target_modules=["q_proj", "v_proj", "k_proj", "o_proj"]q是query，k是key，v是value，o是attention输出。我当时全选了。
其实如果显存紧张，可以只打q和v。o一般影响不大，因为它是输出投影，已经被下游层处理过了。
还有个选择是加上ffn层的gate和up_proj，但我没加，怕引入太多参数导致过拟合。
解决方案
找到根因就好办了。我试了四种方案，最后选了方案4。
方案1：改A的初始化
标准LoRA用随机初始化A、高斯初始化B为零。更合理的做法是让A的初始化方差小一些，这样 $A \cdot x$ 的输出不会一开始就把B的贡献淹没。
from peft.tuners.lora import LoraLayer
# 自定义LoRA层初始化
class CustomLoraLayer(LoraLayer):
def reset_lora_parameters(self):
# B保持为零初始化
if hasattr(self, 'lora_B') and self.lora_B is not None:
self.lora_B.zero_()
# A改用更小的方差
if hasattr(self, 'lora_A') and self.lora_A is not None:
torch.nn.init.normal_(self.lora_A.weight, std=0.01)但实测下来这个改动效果有限。问题在于，只改A的方差并不能解决链式依赖——A的梯度还是要经过B才能传导回去，方差小只是让梯度量级小一点，并没有打破死锁。
方案2：增大alpha/r比例
LoRA有个scale参数 $\alpha / r$。如果当前 r=16, alpha=32，scale=2。我试过把alpha调到64：
lora_config = LoraConfig(
r=16,
lora_alpha=64, # 原来是32
...
)这让最终输出里 $B \cdot A \cdot x$ 的权重变大了，但治标不治本——梯度依然只流向B，A还是半死不活。而且alpha太大还有个问题：可能破坏预训练权重已经学好的表示。
方案3：归一化梯度
最终方案是把所有LoRA参数的梯度做归一化，让A和B收到相对均衡的梯度：
class GradientNormalizedLoRA(torch.nn.Module):
def __init__(self, base_layer, rank=16, alpha=32):
super().__init__()
self.base_layer = base_layer
self.rank = rank
self.scale = alpha / rank
# A和B分别存，方便单独处理
self.lora_A = torch.nn.Parameter(torch.randn(rank, base_layer.in_features) * 0.01)
self.lora_B = torch.nn.Parameter(torch.zeros(base_layer.out_features, rank))
self.base_layer.weight.requires_grad = False
def forward(self, x):
# 原始前向
base_out = self.base_layer(x)
# LoRA路径
lora_out = (self.lora_B @ (self.lora_A @ x.T)).T
return base_out + lora_out * self.scale
def gradient_balance_hook(model):
"""把所有LoRA对的梯度做均衡"""
# 按层遍历，找到lora_A和lora_B配对
for name, module in model.named_modules():
if isinstance(module, GradientNormalizedLoRA):
# 梯度裁剪和均衡
grad_A = module.lora_A.grad
grad_B = module.lora_B.grad
if grad_A is not None and grad_B is not None:
# 计算梯度范数比
norm_A = grad_A.norm()
norm_B = grad_B.norm()
if norm_A > 1e-8 and norm_B > 1e-8:
# 把B的梯度按比例放大，让它俩量级接近
ratio = norm_B / norm_A
if ratio < 0.1: # A远大于B
module.lora_B.grad = grad_B * (norm_A / norm_B) * 0.5
elif ratio > 10: # B远大于A
module.lora_A.grad = grad_A * (norm_B / norm_A) * 0.5但这个方案有个问题——在训练循环里手动改梯度会增加约15%的计算开销，而且逻辑比较hacky，不适合生产环境。
方案4：正交初始化（我的选择）
综合考虑实现成本和效果，我最后选了方案4，原因是它不需要改训练循环，纯靠改初始化就能解决问题，代码干净利落。
后来我发现peft库在较新版本里已经支持自定义初始化了：
from peft import LoraConfig, get_peft_model
from peft.tuners.lora import LoraConfig as PEFTLoraConfig
lora_config = LoraConfig(
r=16,
lora_alpha=32,
lora_dropout=0.05,
target_modules=["q_proj", "v_proj"],
init_lora_weights="gaussian" # 新版支持
)如果你用的peft版本不支持，也可以直接改源码。我个人更倾向直接fork一份peft按需改：
# 在 peft/tuners/lora.py 里的 LoraLayer.reset_lora_parameters
# 原来是这样：
def reset_lora_parameters(self):
if self.lora_A is not None:
# 随机初始化
self.lora_A.weight.normal_(mean=0, std=0.02)
if self.lora_B is not None:
# 零初始化
self.lora_B.weight.zero_()
# 改成这样（用正交初始化，而不是全零）：
def reset_lora_parameters(self):
if self.lora_A is not None:
self.lora_A.weight.normal_(mean=0, std=0.005)
if self.lora_B is not None:
# 改成小幅度的正交初始化，而不是全零
torch.nn.init.orthogonal_(self.lora_B.weight, gain=0.01)为什么正交初始化比方案1（改A方差）和方案3（梯度均衡）更好？
-
相比方案1（改A方差）：只改A的方差没有打破梯度链式依赖，只是让梯度量级小一点。正交初始化是同时改A和B，让B不再是零矩阵，这样前向时 $BA$ 一开始就有非零输出，反向时A和B的梯度都能正常传导。
-
相比方案3（梯度均衡）：梯度均衡需要每次backward后手动修改梯度，增加了约15%的计算开销，而且代码侵入性强。正交初始化是一次性改初始化，训练过程完全不变。
-
正交初始化的核心优势：$B$ 用正交初始化意味着 $B$ 的列向量是两两正交的，这保证了 $BA$ 的表示空间更丰富，不会出现某些方向被压缩的情况。
正交初始化的反例和边界条件：
但正交初始化不是万能的。有个场景我踩过坑：
如果你的任务需要模型彻底摆脱预训练知识（比如做风格迁移，让模型完全忘掉原来的写作风格），正交初始化可能不如零初始化好。因为正交初始化让 $BA$ 一开始就有非零输出，模型会更容易保留预训练知识。
另外，对于极小的rank（比如r=2或r=4），正交初始化的意义也不大——空间太小，正交约束和普通初始化差别不大。这种情况下我建议直接用方案2（调大alpha），或者干脆换别的微调方法。
调用方式
完整训练脚本
这是最终用的训练脚本，基于DeepSpeed ZeRO-2：
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
LoRA微调脚本 - 支持梯度监控
"""
import os
import torch
from transformers import (
AutoModelForCausalLM,
AutoTokenizer,
TrainingArguments,
Trainer,
DataCollatorForLanguageModeling
)
from peft import LoraConfig, get_peft_model, TaskType
from datasets import load_dataset
# ============== 配置区 ==============
MODEL_NAME = "meta-llama/Llama-2-7b-hf"
DATA_PATH = "./data/chat_data.json"
OUTPUT_DIR = "./output/lora_finetuned"
# LoRA配置
LORA_R = 16
LORA_ALPHA = 32
LORA_DROPOUT = 0.05
LORA_TARGET_MODULES = ["q_proj", "v_proj"]
# 训练配置
LEARNING_RATE = 2e-4
NUM_EPOCHS = 3
BATCH_SIZE = 4
GRADIENT_ACCUMULATION_STEPS = 4
MAX_GRAD_NORM = 1.0
# ============== 配置区结束 ==============
def main():
# 1. 加载模型和tokenizer
print("Loading model...")
model = AutoModelForCausalLM.from_pretrained(
MODEL_NAME,
device_map="auto",
torch_dtype=torch.float16,
load_in_8bit=False,
trust_remote_code=True
)
tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME, trust_remote_code=True)
tokenizer.pad_token = tokenizer.eos_token
tokenizer.padding_side = "right"
# 2. 配置LoRA
print(f"Configuring LoRA: r={LORA_R}, alpha={LORA_ALPHA}")
lora_config = LoraConfig(
task_type=TaskType.CAUSAL_LM,
r=LORA_R,
lora_alpha=LORA_ALPHA,
lora_dropout=LORA_DROPOUT,
target_modules=LORA_TARGET_MODULES,
bias="none",
init_lora_weights="gaussian" # 用新版支持的初始化
)
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 3. 加载数据
print(f"Loading data from {DATA_PATH}")
dataset = load_dataset("json", data_files=DATA_PATH, split="train")
def tokenize_function(examples):
texts = []
for conv in examples["conversations"]:
text = ""<|im_start|>user\n" + conv[0]["content"]
text += "<|im_end|><|im_start|>assistant\n" + conv[1]["content"]
text += "<|im_end|>"
texts.append(text)
result = tokenizer(texts, truncation=True, max_length=512)
result["labels"] = result["input_ids"].copy()
return result
tokenized_dataset = dataset.map(
tokenize_function,
batched=True,
remove_columns=["conversations"]
)
# 4. 训练参数
training_args = TrainingArguments(
output_dir=OUTPUT_DIR,
learning_rate=LEARNING_RATE,
num_train_epochs=NUM_EPOCHS,
per_device_train_batch_size=BATCH_SIZE,
gradient_accumulation_steps=GRADIENT_ACCUMULATION_STEPS,
max_grad_norm=MAX_GRAD_NORM,
warmup_ratio=0.03,
lr_scheduler_type="cosine",
logging_steps=10,
save_steps=100,
save_total_limit=2,
fp16=True,
dataloader_num_workers=4,
remove_unused_columns=False,
report_to=["tensorboard"]
)
# 5. 自定义Trainer，记录梯度
class GradientLoggingTrainer(Trainer):
def training_step(self, model, inputs):
# 正常训练
loss = super().training_step(model, inputs)
# 每50步打印梯度统计
if self.state.global_step % 50 == 0:
grad_norms = {}
for name, param in model.named_parameters():
if param.requires_grad and param.grad is not None:
grad_norms[name] = param.grad.norm().item()
# 打印A和B的梯度比
lora_A_norms = [v for k, v in grad_norms.items() if "lora_A" in k]
lora_B_norms = [v for k, v in grad_norms.items() if "lora_B" in k]
if lora_A_norms and lora_B_norms:
avg_A = sum(lora_A_norms) / len(lora_A_norms)
avg_B = sum(lora_B_norms) / len(lora_B_norms)
ratio = avg_B / (avg_A + 1e-8)
self.log({
"grad_norm_A": avg_A,
"grad_norm_B": avg_B,
"grad_ratio_B_A": ratio
})
return loss
# 6. 开始训练
trainer = GradientLoggingTrainer(
model=model,
args=training_args,
train_dataset=tokenized_dataset,
data_collator=DataCollatorForLanguageModeling(tokenizer, mlm=False)
)
trainer.train()
# 7. 保存
trainer.save_model(f"{OUTPUT_DIR}/final")
tokenizer.save_pretrained(f"{OUTPUT_DIR}/final")
print("Training complete!")
if __name__ == "__main__":
main()使用DeepSpeed启动
deepspeed --num_gpus=8 train_lora.py \
--deepspeed ds_config.jsonds_config.json内容：
{
"train_batch_size": "auto",
"train_micro_batch_size_per_gpu": "auto",
"gradient_accumulation_steps": "auto",
"gradient_clipping": 1.0,
"zero_optimization": {
"stage": 2,
"offload_optimizer": {
"device": "cpu",
"pin_memory": true
},
"allgather_partitions": true,
"allgather_bucket_size": 2e8,
"reduce_scatter": true,
"reduce_bucket_size": 2e8,
"overlap_comm": true,
"contiguous_gradients": true
},
"fp16": {
"enabled": true,
"loss_scale": 0,
"loss_scale_window": 1000,
"initial_scale_power": 16
}
}上线后评估
验证结果
改完初始化之后，同一个数据集重新训练：
| 阶段 | 原来(r=16,a=32,零初始化) | 改后(r=16,a=32,正交初始化) |
|---|---|---|
| Step 100, loss | 2.1 | 1.95 |
| Step 500, loss | 1.4 | 1.12 |
| Step 1000, loss | 1.1 | 0.78 |
| 验证集BLEU | 12.3 | 18.7 |
| 验证集ROUGE-L | 0.241 | 0.358 |
BLEU从12.3跳到18.7，这才对嘛。loss降不代表模型在学，只有验证指标提升才是真的学到东西。
资源消耗对比
改动后对显存的影响：
| 配置 | GPU显存占用 | 训练速度 |
|---|---|---|
| 原始LoRA (r=16) | ~42GB (8卡) | 120 tokens/sec/GPU |
| 正交初始化LoRA | ~42GB (8卡) | 118 tokens/sec/GPU |
几乎没区别，初始化只影响参数值，不影响计算图。正交初始化和零初始化在显存占用和速度上是一样的。
硬件环境：8卡A100 80GB，Ubuntu 22.04，CUDA 12.1，PyTorch 2.1.0，transformers 4.36.0，peft 0.7.1。
梯度监控结果
改完后同一批数据再看梯度分布：
[lora_B.weight] grad_norm=0.0218
[lora_A.weight] grad_norm=0.0195 # 从0.0001升到0.0195！A和B的梯度比从200:1变成了约1:1，这才是健康的训练状态。
常见坑
如果这样改还不行怎么办
改了初始化之后验证指标还是不动，这时候别慌，问题可能在别的地方。
1. 学习率不对
我遇到过学习率太大导致训练震荡的情况。2e-4对7B模型来说算比较大的，如果用了正交初始化，梯度更大了，建议把学习率降到1e-4试试。
training_args = TrainingArguments(
learning_rate=1e-4, # 从2e-4降下来
...
)2. 数据质量问题
前面说的token分布问题再强调下。如果数据里某个token占比超过30%，模型会”偷懒”，只学预测这个token。检查下special token比例，超过5%就有问题。
3. 数据量太少
3000条数据其实偏少，训3个epoch可能不够。我后来把epoch提到5，验证指标又涨了一点。
4. 模型本来就不适合这个任务
说实话，有时候问题不是训练的问题，是模型本身的能力边界。比如你用中文模型做英文任务，或者7B模型做复杂推理，效果差是正常的，不是LoRA的锅。这种情况换个大模型或者专用模型更实在。
5. target_modules选错了
如果你只选了q_proj和v_proj，但任务需要理解语义关系，可能加上k_proj和o_proj效果更好。如果任务偏生成，加上ffn层的gate_proj和up_proj可能有奇效。
另一个容易踩的坑：数据token分布
我后来又遇到过一次类似问题，这次不是初始化问题，而是数据问题。
数据集里某个特殊token占比超过40%，导致模型只要预测这个token就能把loss拉低，但实际上什么都没学到。这种情况下梯度消失是表象，真正的问题是数据不平衡。
总结
回过头看这个问题，其实不复杂：
-
LoRA的B零初始化+A随机初始化 = A被锁死。这不是bug，是设计选择，但在某些场景下会导致训练无效。
-
loss下降不等于模型在学。得看验证指标、梯度分布、optimizer状态，综合判断。
-
rank和alpha不是越大越好，但太小会导致表示能力不足。我现在一般r=16起步，如果任务复杂或者数据量大才往32、64调。
-
数据分布问题也得排查，特别是用chat模板的数据集，system prompt、user/assistant标记的分布会直接影响某些层的激活。
-
正交初始化是正统解法，比改方差和梯度均衡都干净利落。除非你有特殊需求（彻底忘掉预训练知识），否则别用零初始化。
最后提醒一句：如果你现在用的peft版本比较老，升级到0.7+会好很多，那个版本对初始化做了优化，而且多了gradient checkpointing的兼容处理。