Qwen3.8-27B 262K上下文提速16倍，超越双3090

我花了不少时间把层放置、KV格式和llama.cpp本身当作实验变量来调整。记录了159次实验。先给数字，再说注意事项。

硬件：AMD Ryzen AI MAX+ 395（Strix Halo，128 GB统一内存）+ 通过eGPU链接的RTX 3090 Ti。单个llama.cpp进程，AMD侧用Vulkan，NVIDIA侧用CUDA，一个27B模型跨两者切分。

基线：9.474 tok/s。仅目标模型，无投机解码，仅AMD侧。

现在，代码类生成：
- 32K上下文：153.32 tok/s
- 200K上下文：87.74 tok/s

HumanEval，164个问题，由真实的编码代理（pi-agent）驱动，并通过执行官方测试来评分：
- 本地：159/164，29.7分钟
- 远程：2x RTX 3090运行vLLM TP2：157/164，42.4分钟

长上下文检索测试集：15/15，本地352秒 vs 远程551秒。

真正起作用的因素，按意外程度大致排序：
1. 聊天模板。换用更简洁的模板（Qwen-Sharp）后，墙钟时间减少44%，输出token减少51%，精度无变化。比几周的GPU调优效果还大。它只是让模型不再自言自语。
2. KV缓存格式作为放置杠杆。在K和V上都从q8_0改为q4_0，恰好释放了2,176 MiB，这足以在完整262K下把每个全注意力层都移到快速显卡上。预填充+28%，生成+20%。Qwen3.8的Gated DeltaNet与全注意力比例为3:1，所以64层中只有16层有KV，且只有这些层的成本随上下文扩展。哪一层放在哪张GPU上至关重要。
3. --spec-type draft-mtp,ngram-mod。这个标志可叠加。在MTP之上再用n-gram，对代码类输出有+72%到+140%的提升，对散文类约-1%，且不占用VRAM。如果你生成代码，这就是免费收益。
4. 一行llama.cpp补丁：--spec-draft-ubatch。投机上下文继承了目标模型的512微批处理，并保留了2.2 GiB计算缓冲区来起草4个token。将其设为64后，释放了1,039 MiB，代价是1.78%的预填充开销，这换来了另一层的放置空间。
5. MTMD_BACKEND_DEVICE=Vulkan1 将视觉编码器放到空闲的iGPU上。据我所知这是未文档化的。默认情况下会把它放到第一个GPU类型设备上，即已经满载的3090 Ti，然后它在分配884 MiB时崩溃。

没用的尝试，省得你去试：
- 外部草稿模型（0.8B、4B）：5.06-5.77 tok/s，比不用投机还差。跨PCIe的顺序起草延迟占主导。
- 多通道并行起草：降到1.62 tok/s。27B的验证过程是瓶颈；任何扩大验证图的做法都会输。
- Q6_K：墙钟时间2.3倍，精度反而略低（因为两次撞上64K输出限制墙）。20.5 GiB中只有15.6 GiB能放进显卡，所以4个注意力层被推到了iGPU上，而不是1个。

注意事项，因为这里是r/LocalLLaMA，反正你们也会找出来：
- 153 tok/s是32K下代码类生成，其中n-gram承担了主要工作。同样配置在200K散文下是35.8。不同负载，有意识地区分开。
- 远程对比是部署栈对部署栈，不是硬件隔离：远程运行AWQ-MTP微调版，本地运行基础版的Q4_K_M。
- 我要求的是独立函数而不是标准的prompt+completion格式，所以5个HumanEval失败中有3个是辅助函数上的NameError，官方测试工具本会把这些保持在同一作用域内。159/164可能略微低估。同样的低估适用于所有分支。
- q4_0键确实是质量上的变化。通过了我的15/15门槛；在信任它之前，请在自己的工作负载上验证。

完整文档包含所有标志、补丁和失败分支：[https://definedrr.medium.com/qwen3-8-27b-9-tokens-per-second-to-153-ee3781f4a3f5?sharedUserId=definedrr3

—— 高票评论（帖子共26条讨论）——

[+17] u/Sadge404：我闻到了Claude的味道。

[+9] u/Significant_Bar_460：q4 KV真的有用吗？在200k上下文下肯定退化得很厉害。

[+5] u/Kaljuuntuva_Teppo：q4 KV缓存……为什么要牺牲长上下文质量？

[+2] u/Otherwise-Variety674：确认一下，你用的是Qwen3.8-27B Q4_K_M？我跟你硬件一样（现在有时候还用我的5090或7900xtx），准备试一下，先谢了。😄

[+2] u/cviperr33：有意思，谢谢

[+1] u/Gloomy_Letterhead395：太疯狂了

[+1] u/S0299S：我本来打算在48GB内存的Mac mini上搭这个

[+1] u/Queasy_Asparagus69：不错，但你应该用deepseek flash 0731做类似的事；比起Qwen3.8我更喜欢它

[+1] u/Prudent-Ad4509：KV量化通常是一票否决的问题，但如果工作负载允许，那么在特定负载下这是个不错的结果。

[+1] u/TokyoPav：我想做同样的，但用oculink连接的amd 9700 32GB显卡。它是否有120W的APU功耗限制？很难找到详细资料。Linux是否不受此问题影响？