Qwen 27B——牺牲上下文以运行更好的量化版本，利弊分析

我之前一直在用 Unsloth IQ4_XS，虽然它在 20GB 显存上为我提供了健康的 96K 上下文，但我确实注意到了它在草稿阶段的所有问题，以及为修复这些问题所浪费的时间和本地 token。我决定看看如果使用更少的上下文和更高的量化会发生什么，天哪，我真是大吃一惊。最终结果比我预想的还要好。拥有更高的上下文很棒，因为它允许你运行更复杂的东西而无需压缩，中断也更少，这理应节省时间。当你拥有足够的显存来运行像 Q8 这样的高量化版本并搭配大上下文时，这百分之百是真的。然而，对于我们这些 GPU 贫民来说情况并非如此，因为你是在用模型质量换取上下文。这意味着什么呢？意味着虽然你获得了上下文，但你牺牲了代码质量，进而导致草稿中出现错误，造成延迟和返工来修复这些问题。除了代码质量更低之外，这还在耗费时间。使用 XS 一段时间后，我决定改用 KS 来看看对比如何。我想让我试试反其道而行之，牺牲上下文来使用更好的量化。我可以告诉你，我真是大吃了一惊。你看，使用更高的量化确实牺牲了上下文，我从 96K 降到了 75K，从使用 IQ4XS 96K KV-F16 变成了 UDQ4KS 75K KV-Q8。最终结果是，虽然我在更低的 KV 量化（从 F16 到 Q8）下拥有更少的 KV，但模型质量的提升远远抵消了降低 KV 量化所带来的任何问题。你看，模型质量的提升导致草稿中的问题大大减少，这转化为更少的调试和修复问题的时间。是的，我确实在 KV 方面有了更多的压缩，但还没有到损害质量的程度，虽然压缩 KV 需要几秒钟，但修复草稿中的问题所需的时间要长得多。最终结果是，在相同的测试中，运行 XS 花了 8 小时，而运行 KS 搭配更少上下文花了不到 6 小时。原因是这个……