我最近在给Gemma-3-270m做指令微调（SFT）时，碰到了和你完全一样的糟心事——微调后的模型会不断重复正确的NER结果，还夹杂着莫名其妙的“model”字样，一直生成到接近max_new_tokens的上限才停止，但直接用官方的gemma-3-270m-it版本就完全正常。折腾了好一阵后，我总结了几个可能的原因和对应的解决办法，你可以挨个试试：

1. 核心遗漏：SFTTrainer未指定对话字段 #

这是我踩过的最大坑！你的数据集用的是messages格式的对话数据，但SFTTrainer默认会去寻找text字段来处理训练数据。如果不明确指定dataset_text_field="messages"，模型根本没学会正确的对话结构，自然不知道什么时候该停止生成。

解决办法：
重新初始化SFTTrainer时加上这个关键参数：

trainer = SFTTrainer(
    model=model,
    args=args,
    train_dataset=dataset['train'],
    eval_dataset=dataset['test'],
    processing_class=tokenizer,
    dataset_text_field="messages"  # 必须指定这个，否则模型无法正确解析对话数据
)

2. 聊天模板与基础模型的适配问题 #

你把gemma-3-270m-it的chat_template套到了base模型的tokenizer上，但base模型本身没经过指令微调的对齐训练，对对话格式的结束信号（EOS token）不敏感。而官方的it版本是专门优化过对话逻辑的，知道在assistant回复结束后停止生成。

解决办法：

• 训练阶段强化EOS信号：在训练数据的每条assistant回复结尾手动添加tokenizer.eos_token，或者确认SFTConfig的dataset_kwargs中append_concat_token设置正确，让模型在训练时就学会识别结束位置。
• 生成阶段强制停止：调用生成管道时，明确指定EOS token的ID，同时把pad token也映射到EOS（避免无意义的填充）：

  outputs = pipe(prompt, max_new_tokens=256, disable_compile=True, 
                 eos_token_id=tokenizer.eos_token_id, 
                 pad_token_id=tokenizer.eos_token_id,
                 do_sample=False)  # 确定性生成也能减少重复
  

3. 换用指令微调版模型作为微调基座 #

base模型是纯预训练语言模型，只学过预测下一个token，没有对话回合的概念。与其硬套it版本的模板，不如直接用gemma-3-270m-it作为SFT的基础模型，它本身已经有对话格式的先验知识，微调后的对齐效果会好得多，重复问题大概率会直接消失。

解决办法：
把代码中的base_model替换为it_model，去掉手动复制chat_template的步骤，直接用it版本的模型和tokenizer初始化：

base_model = "google/gemma-3-270m-it"  # 直接用指令版作为基座

# 加载模型和tokenizer时统一用base_model
model = AutoModelForCausalLM.from_pretrained(
    base_model,
    torch_dtype="auto",
    device_map="auto",
    attn_implementation="eager"
)
tokenizer = AutoTokenizer.from_pretrained(base_model)

4. 检查训练数据与过拟合情况 #

如果以上方法都没用，可以看看你的验证集loss是不是在训练后期开始上升——如果是，说明模型过拟合了，会开始重复训练数据中的内容。

解决办法：

• 减少训练epoch数（比如从5降到3）
• 增加per_device_train_batch_size或者加入正则化（比如在SFTConfig中设置weight_decay=0.01）
• 检查训练数据的格式是否统一，有没有混入异常的"model"字样（毕竟生成结果里重复了这个词，大概率训练数据里有相关的噪声）

我当时是先补了dataset_text_field参数，重复问题就缓解了一大半，后来换成it版本基座微调后就完全正常了。你可以按优先级先试前两个办法，应该能很快解决问题！