原贴链接

我测试了Mistral Small用于故事写作，设置如下：

  • 量化：https://huggingface.co/LoneStriker/Mistral-Small-Instruct-2409-6.0bpw-h6-exl2，在24G GPU上

  • UI：exui（带有DRY破解），以及exllama的最新开发分支：https://github.com/turboderp/exui/pulse

  • 采样设置：在每个长度上测试了多种设置，从纯0温度贪婪采样到约1温度，1.05重复惩罚，0.7 DRY倍数，始终使用0.08 MinP，以及中间的多个阶段。

  • 格式化：小说风格，使用Mistral风格的[INST] [/INST]标签在笔记本模式下。

在第一次尝试100K时，它似乎完全崩溃了，所以我只是尝试在不同的上下文长度下继续一个不完整的故事，看看它会如何表现。

Q4 K/V缓存，6bpw权重：

  • 30K：…还可以，连贯。不确定它是如何引用上下文的。

  • 54K：现在它开始进入循环，即使在非常高的温度（或零温度）下，它也会重复相同的短语，如“我不确定。”或“一个人就是一个人。”一遍又一遍。调整采样似乎没有帮助。

  • 64K：更糟糕。

  • 82K：完全不连贯，甚至没有输出真正的英语。

Q6 K/V缓存，6bpw权重：

  • …相同的结果，最多到80K，这是我能适应的最大值。

我的参考模型是Star-Lite（A Command-R合并）35B 4bpw，它在86K时非常连贯（尽管在完整的128K时更值得怀疑），在完全相同的上下文下（只是使用了不同的指令标签）。

我知道这里大多数人都不关心>32K的性能，但这似乎不是一个连贯的“超长上下文”模型，如Megabeam 7B，InternLM 20B或新的Command-R。除非这是exllama、Q缓存或6bpw量化的产物（似乎不太可能），否则它在宣传的128K或甚至64K时完全无法使用。

讨论总结

本次讨论主要围绕Mistral-Small-Instruct-2409 22B模型在长上下文处理中的表现展开。评论者们普遍认为该模型在处理超过32K的上下文时表现不佳，尤其是在处理代码相关内容时。尽管如此，一些评论者指出，该模型在32K上下文长度内仍能保持连贯性，适合休闲使用和角色扮演。讨论中还涉及了不同量化级别对模型性能的影响，以及与其他模型的比较，如Llama 3.1 8B、Gemma 27B和Nemo 12B。总体而言，讨论的情感倾向较为负面，主要集中在对模型性能的失望和对其未来改进的期待。

主要观点

  1. 👍 Mistral-Small-Instruct-2409 22B在32K上下文长度内表现出色
    • 支持理由：能够记住大部分内容，使用多样化的语言，比其他模型更逻辑和聪明。
    • 反对声音：在处理超过32K的上下文时表现不佳。
  2. 🔥 该模型的上下文长度应被限制在18K-22K
    • 正方观点：在18K-22K上下文长度内，模型能够提供准确且连贯的回答。
    • 反方观点：超过24K时，模型的回答能力显著下降。
  3. 💡 量化缓存对模型性能有显著影响
    • Q6量化在大多数情况下与全质量缓存无明显区别，Q8量化在高上下文长度下表现良好。

金句与有趣评论

  1. “😂 Well, what did you expect? Mistral’s history with long context is less than stellar - actually the worst.”
    • 亮点：直接指出了Mistral模型在长上下文处理中的历史表现不佳。
  2. “🤔 如果它能保持在32k的连贯性，那就足够用于休闲使用和角色扮演了。”
    • 亮点：强调了模型在特定上下文长度内的实用性。
  3. “👀 The Mistral Nemo 12B is my favorite, I’m actually looking forward to testing 22B.”
    • 亮点：表达了对Mistral Nemo 12B的喜爱和对22B版本的期待。

情感分析

讨论的总体情感倾向较为负面，主要集中在对Mistral-Small-Instruct-2409 22B模型在长上下文处理中表现不佳的失望。主要分歧点在于模型在不同上下文长度下的表现，以及量化缓存对模型性能的影响。可能的原因包括模型设计上的局限性，以及量化缓存在高上下文长度下的不稳定性。

趋势与预测

  • 新兴话题：量化缓存在高上下文长度下的表现和优化。
  • 潜在影响：对未来模型设计和量化技术的改进提出更高要求，尤其是在处理长上下文任务时。

详细内容：

标题：关于 Mistral-Small-Instruct-2409 长上下文性能的热门讨论

近日，Reddit 上一篇关于 Mistral-Small-Instruct-2409 模型长上下文性能的帖子引发了广泛关注。该帖介绍了对 Mistral Small 进行故事写作测试的详细设置及结果，获得了众多用户的大量点赞和评论。

帖子中提到，在多种设置下，如不同的量化方式、用户界面、采样设置和格式化等，对模型进行了测试。首次尝试 100K 时表现糟糕，后续在不同上下文长度继续测试，发现 30K 时还算可以，54K 开始出现重复短语的问题，82K 则完全语无伦次。

讨论焦点主要集中在模型在不同上下文长度下的表现。有人表示，测试 GGUF 版本到 32K 时很连贯，语言多样，逻辑和推理优于某些模型。也有人指出新 Command R 的采样设置问题，还有人认为其在 32K 以下表现出色，但超过 24K 回答问题的能力就明显下降。

有用户认为，如果模型在 32K 时能保持连贯，对于日常使用和角色扮演来说就足够了，但对于工作中的专业需求，还没有能在 128K 且保持完美连贯的可本地运行模型。不过，也有用户提到 InternLM 20B 在 128K 时表现合理，新 Command R 模型接近 128K。

对于缓存量化，有人推荐使用 Q8，认为其在 24K 或更长的上下文长度下表现较好。还有用户表示 Mistral Nemo 12B 是其最爱，并期待测试 22B。

究竟哪种模型在长上下文处理上更具优势，以及如何优化模型的性能以满足不同需求，成为了本次讨论的核心争议点。