原贴链接

嘿，r/LocalLLaMA！如果你正在运行Qwen 2.5模型，我发现了一些漏洞和问题：1. 原始模型只有32K的上下文长度。Qwen使用YaRN将其从32B扩展到128K。我将原生128K GGUFs上传到了huggingface.co/unsloth，32B编码器128K上下文在[https://huggingface.co/unsloth/Qwen2.5 - Coder - 32B - Instruct - 128K - GGUF](https://huggingface.co/unsloth/Qwen2.5 - Coder - 32B - Instruct - 128K - GGUF)；2. 填充令牌（Pad_token）不应为<|endoftext|>，微调时会产生无限生成，我已将修复内容上传到huggingface.co/unsloth；3. 基础模型的<|im_start|> <|im_end|>标记未经过训练，如果对基础模型进行微调或推理，不要将它们用于聊天模板。如果对基础（左）和指令（右）版本之间的嵌入进行主成分分析（PCA），首先会看到字节对编码（BPE）层次结构，还能看到基础模型中的<|im_start|>和<|im_end|>标记未经过训练，但在指令模型中分开了。https://llminfo.image.fangd123.cn/images/h9x9r8v3lj0e1.png!/format/webp。1. 此外，Unsloth可以在48GB的卡上微调72B，更多详情见https://github.com/unslothai/unsloth；2. 微调Qwen 2.5 14B编码器也适用于免费的Colab（16GB卡）！对话笔记本：[https://colab.research.google.com/drive/18sN803sU23XuJV9Q8On2xgqHSer6 - UZF?usp = sharing](https://colab.research.google.com/drive/18sN803sU23XuJV9Q8On2xgqHSer6 - UZF?usp = sharing)；3. Kaggle笔记本每周也提供30小时的免费GPU：[https://www.kaggle.com/code/danielhanchen/kaggle - qwen - 2 - 5 - coder - 14b - conversational](https://www.kaggle.com/code/danielhanchen/kaggle - qwen - 2 - 5 - coder - 14b - conversational)。我上传了Qwen 2.5的所有修复版本、GGUFs和4位预量化的bitsandbytes：GGUFs包含原生128K上下文窗口。上传了2、3、4、5、6和8位GGUFs。（此处为表格内容，略）我确认128K上下文窗口扩展GGUFs至少运行良好。尽量不要使用小模型（0.5到1.5B且2 - 3位量化），4位量化运行良好，32B编码器2位量化也相当不错！完整的带有128K和32K GGUFs的修复Qwen 2.5模型集合：[https://huggingface.co/collections/unsloth/qwen - 25 - coder - all - versions - 6732bc833ed65dd1964994d4](https://huggingface.co/collections/unsloth/qwen - 25 - coder - all - versions - 6732bc833ed65dd1964994d4)。最后，微调Qwen 2.5 14B编码器也适用于免费的Colab（16GB卡）！对话笔记本：[https://colab.research.google.com/drive/18sN803sU23XuJV9Q8On2xgqHSer6 - UZF?usp = sharing](https://colab.research.google.com/drive/18sN803sU23XuJV9Q8On2xgqHSer6 - UZF?usp = sharing)

讨论总结

原帖主要是关于Qwen 2.5模型相关的Bug修复、不同版本模型改进、上下文窗口扩展以及微调等内容。评论者们积极参与技术讨论，如模型中工具调用标记是否训练、原生128k模型中Yarn启用情况、Exl2版本与YaRN的关系等，同时也对原帖作者的工作表达了感谢、认可等积极态度，也有人提出在实际使用Qwen 2.5模型时遇到的问题并寻求解答。

主要观点

  1. 👍 Qwen 2.5模型的coder基础版和指令版未进行工具调用训练
    • 支持理由：原帖作者回复评论者的疑问时表明coder基础版和指令版未进行工具调用训练。
    • 反对声音：无。
  2. 🔥 在32K上下文需求下不用YARN可能更好
    • 正方观点：评论者认为如果仅需要32K的上下文，可能不用YARN会更好。
    • 反方观点：原帖作者未直接反对，但解释了128K部分表述可能有误以及提供原生128K版本的目的。
  3. 💡 微调时不使用YaRN而后使用可能提高微调性能
    • 解释：有评论者提出微调时不使用YaRN而后使用的疑问，认为这样可能提高微调性能，原帖作者表示在较小上下文窗口微调后扩展可能可行，但需要深入研究YaRN论文确定。

金句与有趣评论

  1. “😂 bbsss: Could you do that embeddings visualization for the tool_call tokens as well? It seems even the instruct version is not trained on tool calling.”
    • 亮点：首先提出对tool_call tokens进行嵌入可视化的疑问，引发后续关于工具调用相关的讨论。
  2. “🤔 noneabove1182：I don’t think I fully understand, the native 128k models should have yarn enabled to allow for that context, right?”
    • 亮点：对原生128k模型中Yarn启用情况提出疑惑，是关于模型技术方面的典型疑问。
  3. “👀 mwmercury：Thank you so much for doing this. We really appreciate your work!”
    • 亮点：直接表达对原帖作者工作的感谢，反映出原帖内容的价值。

情感分析

总体情感倾向是积极的。主要分歧点在于对Qwen 2.5模型中一些情况的认定，例如部分人认为是Bug，而有人觉得是特性。可能的原因是大家对模型的理解深度和使用场景不同。

趋势与预测

  • 新兴话题：Unsloth对视觉功能的支持，可能会引发关于视觉模型微调等相关的后续讨论。
  • 潜在影响：对Qwen 2.5模型相关技术的讨论可能促使更多人关注和研究模型的优化、修复以及应用场景的拓展，推动自然语言处理技术在相关领域的发展。

详细内容：

标题：关于 Qwen 2.5 模型的 Bug 修复及扩展讨论在 Reddit 上引热议

在 Reddit 的 r/LocalLLaMA 版块，一则关于 Qwen 2.5 模型的帖子引起了众多关注。该帖子指出了 Qwen 2.5 模型存在的一些问题，并提供了相应的修复和扩展方案，获得了大量的点赞和众多评论。

帖子中提到的主要内容包括：

  1. 指出原始模型的上下文长度仅为 32K，使用 YaRN 将其扩展到 128K，并上传了原生 128K GGUFs 到指定链接。
  2. 提到了Pad_token的错误设置以及基础模型中某些未训练的令牌。
  3. 还分享了关于模型在不同显卡和平台上的微调适配情况，如在 48GB 卡上可微调 72B，在免费 Colab 的 16GB 卡上可微调 Qwen 2.5 14B Coder 等，并提供了相关链接。

讨论的焦点主要集中在以下几个方面： 有人提出能否对工具调用令牌进行嵌入可视化。有人认为基础模型和指令模型在 Coder 模型中都未对<tool_call>和</tool_call>进行训练。有人对这些复杂的设置和修复表示不太理解。也有人分享了自己在使用模型时遇到的问题，比如模型在处理较长上下文或特定任务时的表现不佳。

例如，有人提到在 LMStudio 中使用 7B 模型时存在的问题，以及不同版本的 Qwen 在处理工具调用等任务时的情况。还有人讨论了关于设置上下文长度、使用 Yarn 以及模型微调等方面的问题。

对于模型的这些问题和改进方案，大家的观点各不相同。有人对作者的工作表示感谢和赞赏，有人则对一些设置和效果提出疑问。但总体来说，大家都在积极探讨如何更好地优化和使用 Qwen 2.5 模型。

总之，这次关于 Qwen 2.5 模型的讨论为模型的优化和应用提供了丰富的思路和经验，也让更多人对模型的特性和使用有了更深入的了解。