在内存丰富但GPU性能有限的设备上运行Qwen 3.8 Flash Next的体验
原文：Experience report - Qwen 3.8 Flash Next on memory rich, GPU poor setup
（非Claude撰写，所有错误和糟糕的文本都是由于周日早上咖啡喝得太少造成的 ;) 我们的家庭服务器是2018年的Thinkstation P520，2023年以约600欧元的价格购入。它已经升级为2TB的三星980 Pro NVMe硬盘、一个Xeon W-2145处理器和一张12GB的3060显卡 - 总成本大约1000欧元。虽不是小数目，但考虑到它提供的所有功能，这笔钱也不算疯狂。256GB的ECC DDR4内存，频率为2666MHz，四通道，内存带宽约为80GB/s。Qwen 3.6 35b a3b Q4_K_M是日常使用的模型，在编译时使用intel MKL扩展的llama.cpp构建。它不是最智能的模型，但足以完成基本任务。量化确实会降低其智能，但在这种配置下，更大的量化会严重影响吞吐量。Qwen 3.6 35b a3b Q4_K_M 常驻内存：~20GB 预填充：~400tps 生成：30-50tps 上下文：128k 显存：~10.5GB。Flash next是一个完全不同的野兽，尽管它是一个更大的模型，但吞吐量和预填充表现相当不错。在这个配置中，模型的大小是决定性能的因素，这并不奇怪。Qwen 3.8 Flash Next UD-Q4_K_XL 常驻内存：~110GB 预填充：~200tps 生成：12-15tps 上下文：65k 显存：~10.5GB。它速度慢，上下文低，但输出比35b模型要好得多。一些有趣的事情出现了：- 35b的速度对盒子忙于其他任务非常宽容，性能损失很小。这在意料之中，因为更多的模型适合在GPU上运行 - 如果在盒子上进行其他操作（即使运行opencode），Flash next的性能会崩溃，速度降至3-5 tps。内存被完全占用，并且对争用非常敏感。只有当我从另一台机器运行opencode时，它才真正可用。- 合成的、随机内容的基准测试在性能上给出了完全错误的答案。确保您使用现实的上下文来衡量MoE模型。这在我调整服务器时绊倒了我，只有在转向opencode真正尝试时才出现。以下是信息...