你在本地让 AI 读一大段代码，显卡明明还有潜力，它却早早说“装不下”。问题可能不在模型，而在 llama.cpp 预先留出了过大的工作区。一位 Reddit 作者称，修正这笔显存预算后，其特定 AMD 双卡配置的可用上下文从 64,256 增至 149,248。以下数据均来自作者个人测试，尚无独立复现或官方确认。
显存被“预留”掉了
llama.cpp 是一套让大模型在消费级硬件上本地运行的开源工具链。它的 auto-fit 会自动估算模型和上下文能否装进显存。
作者认为，auto-fit 高估了 MTP 的计算缓冲区和调度开销。MTP（Multi-Token Prediction，多 Token 预测）会预测更远的多个后续 Token，可用于加速推理，但也需要额外工作空间。计算缓冲区就像临时操作台：如果系统把操作台估得过大，本可用于保存对话和代码的空间便被提前划走。
补丁没有消除 MTP 的真实开销，而是阻止 auto-fit 按膨胀的估算过早裁减上下文。上下文长度指一次请求能容纳的输入与已生成内容总量；它越长，模型越能保留长对话或更多代码，但 KV 缓存等运行数据也会继续占用显存。
提升取决于具体配置
据作者日志，在两张 GPU（16GB＋12GB）、Q6_K_L 量化和 ROCm 后端下，可用上下文由 64,256 增至 149,248；改用 Vulkan，则由 68,864 增至 151,296。单张 16GB GPU、IQ4_XS Pure 下差异很不一样：ROCm 从 19,456 增至 76,032，Vulkan仅从 68,352增至78,592。
这些数字说明，标题里的“64K→149K”不能推广到所有硬件、模型或量化设置。原文也未明确数字单位，因此不宜直接断言为 Token。
为什么值得关注
它展示了本地部署中一个容易忽略的瓶颈：限制长上下文的未必是真实计算需求，也可能是保守但失真的显存估算。作者还称，llama.cpp 可同时编译 ROCm 与 Vulkan；Vulkan较省显存，ROCm在长会话中的 prefill（正式生成前处理整段输入）性能接近前者两倍。不过原文没有给出吞吐量和完整对照数据。
局限与未知
- 测试基于 llama.cpp version 909、master commit 7bd8282 与 ROCm 7.14，模型仅写作“QWEN 27B”，复现信息不完整。
- 材料未说明补丁是否已提交、合并或获得 llama.cpp 官方确认。
- 所有效果均来自同一作者，尚缺独立复现。