动态KV缓存量化与按需加载mmproj/MTP：我的llama.cpp愿望清单

我们都知道优化VRAM使用的挣扎：量化模型、量化kvcache、关闭mmproj。我经常对这些方面必须做出的权衡感到沮丧。在我的RTX 5090上，我可以容纳： - Qwen3.5-27B @ Q6_K - 开启mmproj，关闭MTP - q8_0 kvcache - 150k上下文 这达到了29/32 GB。我可能还能进一步优化以充分利用剩余空间，但找到合适的参数平衡点令人沮丧。大多数时候，我不需要mmproj，也不希望量化我的kvcache。没有mmproj且不量化kvcache的情况下，我大概可以获得120k+ token的上下文。没有mmproj，我可以开启MTP。80%的情况下，这种配置会更好： - Qwen3.5-27B @ Q6_K - 关闭mmproj，开启MTP - f16 kvcache - ~120k上下文 但有时我需要mmproj，有时我处理大上下文需要量化kvcache。更改这些任何一项都需要几秒钟来完全卸载并重新加载整个模型。如果我在会话中途这样做，因为需要重新处理整个上下文，时间会更长。我的推理框架内置了交换系统，我已经尽可能降低了延迟，但仍然太慢。在会话中等十几秒来交换配置实在不行，因为我没耐心。我想要鱼与熊掌兼得。 我不确定这一切是否由于技术限制，所以上周我花时间学习了llama.cpp的kvcache，现在我可以报告：动态/按需的kvcache量化是完全可能的！我已经在这里实现了一个概念验证：https://github.com/ggml-org/llama.cpp/pull/24134 它的作用是：添加一个HTTP端点 `POST /requantize_kvcache`，接受两个参数（ctk, ctv）。调用时，它会： - 读取并删除当前的kvcache - 以所需的量化方式创建一个新的空kvcache - 量化之前的kvcache并加载到新的kvcache中。 实际上，如果你的推理框架支持这一点，你可以在会话的大部分时间里使用全精度的kvcache，并在接近内存限制时选择性地量化它。重新量化比卸载并重新加载整个模型花费的时间少得多，而且额外的好处是不需要重新处理整个提示。你可以从离开的地方继续，现在有了更多可用的内存。目前，这只支持某些模型架构的kvcache（例如，我一直在用Qwen3测试）。在其他方面也不完整（详见PR），但完成实现的工作量不大。我希望在一两周内完成，假设llama.cpp的维护者想要这个功能😅 其他相关的愿望清单项目： - 一个用于仅加载/卸载mmproj（或在mmproj和MTP之间切换）的端点 - 一个类似--fit的CLI标志，允许动态kvcache量化，无需从推理框架调用API端点。这将为你提供设备所能容纳的最大上下文，但当接近设备极限时，它会自动量化你的kvcache。 - 一个用于按需进行提示处理的端点（虽然，我认为这只需用n_predict: 0调用completions？我需要研究一下）。