3
我一直在尝试在扩展的上下文中使用米斯特拉尔。SWA 据称允许最多 32k 上下文，但实际上我得到的是垃圾。然而，Reddit 上有人提到，使用 45,000 根 ROPE 可以使 24k 连贯。因此，我将 24k 与 KoboldCPP 中的默认 ROPE 进行了比较，然后与自定义 ROPE 进行了比较。后者有效，前者是胡言乱语。
我的猜测是当前的 GGUF 并不是在考虑 SWA 的情况下构建的。
Q
[ggerganov/llama.cpp]米斯特拉尔和滑动窗注意 - GGUF 绳索住宿。
A
回答
0
PyTorch 模型可以处理长提示吗？它的输出与 llama.cpp 和 KoboldCPP 的输出相比如何？我尝试测试它，但系统内存不足。
7
我最近也在想同样的事情
Mistraln_ctx_train在转换期间获得 32k，但它们实际上是 4k 上下文模型（4k 窗口超过 32k 总上下文）
因此，将它们作为经过训练的 32k 上下文进行处理是没有意义的，因为从当前实现的角度来看，该模型应该作为具有 4k训练过的上下文进行处理。
有什么想法吗？
0
对 pytorch 一无所知，因为我只是 KoboldCPP 用户。无论如何，建议 24k 使用 ROPE 的人认为这可能是模型配置有问题，但这需要聪明的人才能弄清楚。这是他们的猜测。
0
也许看看#2268 - YaRN/NTK 类型缩放。它可能比平面缩放效果更好。
1
我认为 llama.cpp 还不支持滑动窗口注意力......:(
3
它实际上可能已经支持它 - 请参阅讨论 #3581 主要问题是我不是 100% 确定 SWA 是如何工作的（请参阅我的评论），因此我们没有将其作为选项添加到示例中
2
使用 Mistral 模型，我设置了 --rope-freq-base，并且在 8k 上下文之后我不再获得垃圾输出从我的测试： --rope-freq-base 10000 （默认）8K 上下文 --rope-freq-base 20000 （有效，较低的困惑度）16k 上下文 --rope-freq-base 40000 （有效，较低的困惑度）32k 上下文
我可能完全错误地使用了它，但我仍在学习这个存储库的所有细节。