AMD设备迎来史诗级突破，llama.cpp实测数据惊掉下巴

谁也没想到，llama.cpp的一次更新，直接让AMD设备的本地大模型运行效率迎来质的飞跃。有开发者实测发现，在AMD Strix Halo设备上，搭载MTP技术的Qwen 3.6 35B-A3B模型，短时解码速度冲到71t/s，即便是62K长上下文，也能稳定在48t/s，速度直接暴涨60%-90%。

更让人意外的是，KV体积直接缩小15倍，原本困扰开发者的长上下文卡顿、内存不足问题，似乎一夜之间得到了缓解。但这份惊喜背后，却藏着一个反转——所有人都以为是MTP技术立了大功，实测后才发现，真正的核心功臣另有其主。

这份实测数据到底有多能打？为什么大家都猜错了核心功臣？普通开发者能不能轻松复刻这份惊喜？今天就带大家一次性搞懂，这波llama.cpp的更新，到底给AMD用户带来了多少实际福利。

关键技术补充：llama.cpp、MTP与DeltaNet，到底是什么来头

在深入拆解实测细节前，先跟大家说清楚几个关键技术，避免看不懂专业术语——毕竟对普通开发者来说，能落地、能复用的技术，才是好技术。

首先是llama.cpp，这是ggml-org开源的免费大模型推理工具集，目前在GitHub上已经收获了109089个星标，堪称本地大模型运行的“神器”。它支持多种硬件后端，包括AMD的Vulkan RADV，还能通过量化技术降低内存占用，让普通设备也能跑起来大模型，无需复杂配置，新手也能快速上手。

然后是MTP技术，全称多标记预测，简单说就是让大模型从“一次生成一个token”的“挤牙膏”模式，变成“一次生成多个token”的“冲刺模式”，核心是通过单次前向传播预测多个后续词元，减少推理迭代次数，从而提升速度。这次llama.cpp合并PR #22673后，正式加入了MTP支持，这也是大家最初以为的“速度密码”。

最后是DeltaNet，这是一种线性注意力机制，今年被Qwen系列模型采用，核心是通过门控形式（Gated DeltaNet），将传统注意力机制的平方级计算复杂度，降到线性级别，既能大幅缩小KV缓存体积，还能保证长上下文的性能稳定，这也是这次实测中，被大家忽略的“隐藏功臣”。

核心拆解：实测细节全曝光，一步到位复刻高效体验

硬件配置说明

本次实测全程使用相同硬件，避免硬件差异影响数据准确性，具体配置如下：AMD Ryzen AI Max+ 395处理器，128 GB UMA内存，Radeon 8060S gfx1151显卡，采用Vulkan RADV后端，设备为AMD Strix Halo盒子（已更换视觉端点）。

新旧模型实测数据对比

为了凸显这次更新的提升，开发者专门对比了之前使用的Gemma 4 26B-A4B Q8模型，与现在的Qwen 3.6 35B-A3B Q6_K + MTP-2模型，两组数据差异十分明显，具体如下：

1. 旧模型（Gemma 4 26B-A4B Q8）表现：

• 短上下文解码速度：41 t/s
• 22K上下文解码速度：36 t/s
• KV缓存占用：每1K个代币（SWA）对应66 MiB
• 实用上下文上限：96K，超过后性能会明显下滑

2. 新模型（Qwen 3.6 35B-A3B Q6_K + MTP-2）表现：

• 短上下文解码速度：71 t/s，较旧模型提升73%
• 62K上下文解码速度：48 t/s，一次解码可超过2200个令牌，较旧模型22K场景提升33%
• KV缓存占用：每1K个代币仅需2 MiB，较旧模型缩小15倍（核心得益于门控DeltaNet线性注意力机制）
• 上下文上限：原生支持256K，实测中远未达到内存瓶颈
• MTP接受率：平均86%，最高可达96.7%，意味着模型“猜”出的多token准确率极高，几乎不用回退重算

具体操作步骤（无需手动构建，新手可直接复刻）

很多开发者担心操作复杂，其实这次的优化最贴心的地方，就是无需手动构建，只需使用指定镜像，就能轻松启用MTP和DeltaNet的优势，具体步骤如下：

1. 无需手动编译llama.cpp，直接使用带有llama.cpp master分支的镜像：
kyuz0/amd-strix-halo-toolboxes:vulkan-radv

2. 下载unsloth发布的Qwen 3.6 35B-A3B-MTP-GGUF模型（llama.cpp合并PR #22673三天后，unsloth已正式发布该模型，可直接获取）

3. 启动模型时，无需额外添加复杂参数，镜像会自动适配MTP和DeltaNet，直接运行即可获得实测中的高效性能

补充说明：该模型的多模态模式仍然有效（可使用同一仓库中的mmproj-F16），工具调用和思考模式也能正常工作，不会因为性能提升而牺牲功能完整性。

实测中的小插曲

值得注意的是，并非所有设备都能顺利运行，有另一位开发者反馈，自己昨晚下载了MTP模型，在9070xt显卡上运行时遇到了问题，但标准的35B MoE型号运行正常，使用Hermes作为网关时，平均吞吐量能达到42tk/s，甚至在39分钟内就完成了应用程序的全部功能更新，仅出现一个小UI错误，且在第二次提示中就成功修复，足以看出优化后的模型实用性极强。

辩证分析：MTP是锦上添花，DeltaNet才是真正的核心密码

这次实测最让人意外的反转，就是大家一开始都误以为MTP技术是速度暴涨、KV缩小的核心原因，但深入分析后才发现，DeltaNet才是真正的“幕后功臣”。不可否认，MTP技术确实立下了汗马功劳，它让模型的解码速度实现了短期的大幅提升，平均86%的接受率，也保证了速度提升的同时，不牺牲生成质量，这对需要快速输出内容的开发者来说，无疑是极大的福利。

但从长期使用和长上下文场景来看，DeltaNet的价值远大于MTP。传统的注意力机制，计算开销会随文本长度呈平方级暴增，这也是为什么Gemma 4模型在3万上下文后，性能会断崖式下跌；而Qwen 3.6采用的门控DeltaNet，通过线性注意力机制，将计算复杂度降到线性级别，不仅大幅缩小了KV缓存体积，还让模型在长上下文场景中保持稳定。

实测数据也印证了这一点：Gemma 4模型在3万上下文后性能暴跌，而Qwen 3.6在6.2万上下文时，性能仅损失约三分之一，远优于Gemma 4的“损失一半”。这意味着，MTP解决的是“速度快慢”的问题，而DeltaNet解决的是“能不能稳定跑长上下文”的核心痛点——对本地大模型来说，后者的实用价值，其实比前者更重要。

当然，我们也不能否定MTP和DeltaNet的协同作用：如果没有MTP的短期提速，DeltaNet的稳定优势难以快速被感知；如果没有DeltaNet的长上下文支撑，MTP的提速也只能局限在短文本场景，无法发挥更大价值。两者相辅相成，才造就了这次的实测奇迹。但这也引发了一个值得思考的问题：未来本地大模型的优化，应该优先提升速度，还是优先保证长上下文的稳定性？

现实意义：AMD用户的春天来了，本地大模型落地门槛再降低

这次llama.cpp的更新+Qwen 3.6模型的优化，对AMD用户来说，无疑是一次史诗级的福利，其现实意义远超“速度提升”本身。首先，它打破了“AMD设备跑本地大模型不如其他设备”的固有认知，通过Vulkan RADV后端的优化，让AMD设备的硬件优势得到充分发挥，普通AMD用户也能轻松跑起35B级别的大模型，且能获得流畅的体验。

其次，KV体积缩小15倍、长上下文稳定支持256K，彻底解决了本地大模型“内存不够用、长文本卡顿”的核心痛点——这也是很多开发者放弃本地大模型，转而使用云端模型的关键原因。现在，只需普通配置的AMD设备，就能轻松处理长文档、多轮对话、工具调用等场景，无需担心内存瓶颈，大大降低了本地大模型的落地门槛。

再者，无需手动构建、直接使用镜像的操作方式，让新手开发者也能快速复刻这份高效体验，不用再花费大量时间编译、调试代码，真正实现了“技术普惠”。同时，模型的多模态、工具调用功能正常，也意味着开发者可以基于这个优化方案，快速搭建实用的AI应用，提升工作效率——就像那位39分钟完成应用功能更新的开发者，这样的效率提升，在实际工作中能节省大量时间。

但我们也要清醒地认识到，目前这项优化还存在一定的局限性：部分显卡（如9070xt）运行时会遇到兼容性问题，多并发部署还未完全支持，这些都是未来需要完善的地方。但不可否认，这次的突破，已经为本地大模型的优化指明了方向——速度与稳定性兼顾，才是本地大模型落地的核心需求。

互动话题：你的AMD设备，能跑起来这个优化模型吗？

看完这次实测，相信很多AMD用户已经按捺不住想要尝试的心情了。其实本地大模型的优化，从来都是“实测出真知”，每个人的设备配置、使用场景不同，体验也会有所差异。

你目前使用的是AMD什么设备？有没有尝试过llama.cpp的最新版本和Qwen 3.6 MTP模型？运行时遇到了哪些问题？是像实测中那样速度暴涨，还是遇到了兼容性难题？

另外，你觉得未来本地大模型的优化，应该优先发力MTP这类提速技术，还是DeltaNet这类稳定性技术？欢迎在评论区留言分享你的体验和观点，和大家一起交流探讨，互相避坑、互相学习，让我们一起解锁本地大模型的更多可能！