原贴链接

嘿 r/LocalLLaMA！花了点时间，但我一直在尝试在 Unsloth 中支持 Qwen 2.5，以实现 2 倍更快的微调和 70% 更少的 VRAM 使用，但我发现了一些 Qwen 2.5 模型中的问题 / 错误 - 如果你已经下载了这些模型，请更新所有 Qwen 模型：

EOS 令牌问题

Qwen 2.5 基础模型（从 0.5b 到 72b）- EOS 令牌应该是 <|endoftext|> 而不是 <|im_end|>。基础模型中的 <|im_end|> 实际上是未经训练的，因此如果你使用它，会导致 NaN 梯度。你应该从源代码重新拉取分词器，或者你可以从 https://huggingface.co/unsloth 下载修复后的基础模型，如果这有帮助的话。

聊天模板问题

• Qwen 2.5 基础模型不应该有聊天模板，这实际上会导致错误，特别是在 Unsloth 的微调笔记本中，因为我检查聊天模板中是否存在未经训练的令牌以对抗 NaN 梯度。
• 不要为 Qwen 2.5 的基础模型使用聊天模板。这会导致 NaN 梯度！

我仍在寻找更多问题，但一般来说，这些问题是最主要的！我还设法上传了 4bit bitsandbytes 量化模型到 https://huggingface.co/unsloth，以实现 4 倍更快的下载（并包含所有错误修复）。还包括完整的 float16 权重。

我还上传了数学和编码器版本到 https://huggingface.co/unsloth。

我还制作了免费的 Kaggle 笔记本（每周 30 小时的 GPU 时间）和 Colab 笔记本，用于微调 Qwen 2.5（所有版本），适用于基础和对话风格的微调：

• Kaggle 基础模型微调笔记本：https://www.kaggle.com/code/danielhanchen/kaggle-qwen-2-5-unsloth-notebook/notebook
• Kaggle 指令模型微调笔记本：https://www.kaggle.com/code/danielhanchen/kaggle-qwen-2-5-conversational-unsloth
• Colab 微调笔记本：https://colab.research.google.com/drive/1Kose-ucXO1IBaZq5BvbwWieuubP7hxvQ?usp=sharing
• Colab 对话笔记本：https://colab.research.google.com/drive/1qN1CEalC70EO1wGKhNxs1go1W9So61R5?usp=sharing

讨论总结

本次讨论主要围绕Qwen 2.5模型的修复、微调及其在Unsloth平台上的应用展开。帖子作者Danielhanchen详细列出了Qwen 2.5模型中存在的EOS token和chat template问题，并提供了修复方案和相关资源链接。评论中，用户们对Daniel的工作表示感谢，并讨论了模型微调、版本兼容性、多GPU支持等技术问题。整体讨论氛围积极，用户对Daniel的贡献表示高度认可，并提出了一些建设性的建议和请求。

主要观点

1. 👍 Qwen 2.5模型的修复
   • 支持理由：Danielhanchen详细列出了模型中的问题，并提供了修复方案和资源链接。
   • 反对声音：无明显反对声音，多数用户对修复方案表示认可。
2. 🔥 微调支持
   • 正方观点：用户对Unsloth平台的微调功能表示兴趣，并提出了具体的使用需求。
   • 反方观点：有用户担心仅使用特定任务数据会导致模型过拟合。
3. 💡 多GPU支持
   • 用户希望Unsloth平台能支持多GPU训练，并表示愿意为此付费。
4. 💡 版本兼容性
   • 用户建议在pip install命令中包含版本号，以避免新版本发布时的兼容性问题。
5. 💡 模型审查
   • 用户建议Hugging Face应有一个“Daniel检查过”的标签，以确保用户下载的模型是安全的。

金句与有趣评论

1. “😂 un_passant：You are amazing !”
   • 亮点：简洁直接地表达了对Daniel工作的赞赏。
2. “🤔 mwmercury：Small request: next time could you please include the version in pip install command, such as unsloth==x.x.x to avoid any compatibility issue when a new version released?”
   • 亮点：提出了一个实际且有建设性的建议。
3. “👀 Inevitable-Start-653：Dude omg! Companies should be paying you to review their hf uploads, all the major players always need to fix something post upload.”
   • 亮点：强调了模型审查的重要性，并建议Hugging Face应为此付费。
4. “👀 thesillystudent：Hey Daniel, would we be getting multi gpu support on the free tier ? Unsloth is amazing, that’s the only thing holding it back.”
   • 亮点：指出了Unsloth平台的唯一不足，并提出了具体的技术需求。
5. “👀 Inevitable-Start-653：I’d be willing to even pay for it”
   • 亮点：表达了用户对多GPU支持的强烈需求和付费意愿。

情感分析

讨论的总体情感倾向积极，多数用户对Danielhanchen的工作表示感谢和赞赏。主要分歧点在于模型微调的具体方法和多GPU支持的需求。用户们对模型的修复和优化表示高度认可，并提出了一些建设性的建议和请求。

趋势与预测

• 新兴话题：多GPU支持、模型审查和版本兼容性可能会引发后续讨论。
• 潜在影响：Danielhanchen的工作可能会促使Hugging Face等平台加强模型审查机制，并推动Unsloth平台增加多GPU支持功能。

详细内容：

标题：Qwen2.5 的问题、修复及相关讨论在 Reddit 上引发关注

在 Reddit 的 r/LocalLLaMA 版块，有一篇关于 Qwen2.5 的帖子引起了众多用户的热烈讨论。该帖子指出了在支持 Qwen 2.5 于 Unsloth 中进行更快且更节省 VRAM 微调时发现的一些问题和提供的修复方法。截至目前，帖子获得了众多点赞和丰富的评论。

主要讨论方向包括 EOS 令牌问题、聊天模板问题，以及分享了各种模型的下载链接和相关的微调笔记本。比如，Qwen 2.5 基础模型的 EOS 令牌应该是 <|endoftext|> 而非 <|im\_end|>，基础模型中使用 <|im\_end|> 会导致 NaN 梯度。同时，基础模型不应有聊天模板，否则会引发错误。

有人称赞道：“你太厉害了！”还有人表示：“感谢你的付出。”也有人提出：“从未使用过 Unsloth，这次真的想尝试一下。不过，下次能否在‘pip install’命令中注明版本，比如‘unsloth==x.x.x’，避免新版本发布时的兼容性问题？”

有人询问：“免费开源版的 unsloth 支持完整微调还是仅支持 LoRA 和 QLoRA？”得到回复：“目前支持 LoRA 和 QLoRA，完整微调在未来规划中！”还有人表示在使用 Qwen 模型时遇到了一些特殊情况，如 VRAM 使用量的异常等。

有人请教：“如果想让 Qwen 针对特定的 json 格式输出进行微调，应该选择基础模型还是指导模型？”回复是：“理论上两者都可行，但可以先尝试指导版本。”

有人问道：“unsloth（开源）是否支持使用多个 GPU 的 vRAM 进行训练？”还有人提到 llama.cpp 中由于 EOS 令牌存在的 bug 已被修复。

总体而言，这篇关于 Qwen2.5 的帖子引发了广泛且深入的讨论，为用户在使用和微调该模型时提供了有价值的参考和交流。