跑通ChatGLM3微调后又试了Llama3，发现两套代码风格差异好大，正常吗？

太正常了，我当初从ChatGLM切到Llama也懵了好一阵。这俩不光tokenizer细节，连数据预处理和损失计算的位置都不一样，本质上是模型架构和训练策略差异导致的，不是你基础的问题。我现在基本是保留一套peft调参的核心逻辑，但数据collator和标签处理那段永远单独写，别指望一套代码通吃。建议你直接去读transformers里对应模型的源码，把attention_mask和padding的差异吃透，比硬套模板省心得多。

正常，GLM和Llama的tokenizer细节本来就不一样，硬套模板必炸。建议把attention mask和label shift单独封装成函数，换模型只改配置不改逻辑。

正常，不同模型细节差异本来就大，尤其分词和mask。我一般把核心训练循环抽出来，再针对模型改个preprocess函数。

正常，GLM和Llama在tokenizer细节上差异就是大，别怀疑自己。我一般留个基座模板再按模型调几个关键参数，硬套代码必炸。

这太正常了，不同模型的tokenizer和训练目标本来就不一样，ChatGLM3的标签移位和Llama3就不是一个套路，照着抄肯定翻车。我一般会拿一个自己维护的微调模板，把数据预处理和模型相关的部分拆开，换模型只改tokenizer和loss那块。建议你直接看官方finetune脚本或者LLaMA-Factory这类框架，能省不少事。

这太正常了，我一开始也踩过一模一样的坑。ChatGLM3的tokenizer和Llama3在padding策略上确实不一样，ChatGLM系列习惯用left padding配合它自己的attention实现，而Llama3那边一般用right padding，直接照搬肯定报错。标签移位那块也是，不同模型对loss计算时shift logits和shift labels的处理顺序有差异，有些教程还会自己包一层，看起来就更乱了。我现在的做法是别追求一套模板通吃，而是把数据预处理和模型前向这两块解耦，针对每个模型写薄薄一层adapter代码。社区里像LLaMA-Factory、Swift这些框架其实就是在帮你抹平这些差异，可以先去读它们的源码，看它们怎么按模型类型分支处理。想减少切换成本的话，建议把tokenizer、attention_mask、labels这三件事单独抽出来做单元测试，换模型时先跑这几个小测试，比直接上全量微调省心很多。基础没打牢这个担心没必要，这本来就是模型生态碎片化带来的工程问题，不是你的锅。