榨干64GB内存：Qwen3.5 122B A10B（UD-Q2_K_XL，启用MTP）已完全取代我原本的Qwen3 Next 80B（UD-Q4_K_XL）

我有64GB常规内存，之前运行的是 Qwen3 Next 80B（UD-Q4_K_XL 量化），性能不错，内部知识也比 Qwen3.5 35B A3B 好很多——而 Qwen3.5 35B A3B 本身就比 Qwen3.6 35B A3B 强。在 DDR4 上，我平均获得 8.5 tok/s 的速度。不过，Qwen3.5 122B A10B 配合 UD-Q2_K_XL 量化，使得同一个 64GB 内存也能容纳一个约 120B 的模型。与普遍看法相反，UD-Q2_K_XL 权重尽管核心是 Q2，但即使启用 MTP 也仍然相当不错。我在内部知识方面得到了质量高得多的回复，尽管生成速度大幅下降至仅约 2.9 tok/s，更具体地说，是在 CPU 上运行时提示处理速度大幅下降（没错，我两个模型都只能在 CPU 上运行）。假如我的笔记本换成 DDR5-5600 内存，生成速度本可以提升到高达 6 tok/s，这已经相当可用了。我觉得等待高质量回复是值得的——这些回复似乎是 Qwen3.5 122B 的常规 MoE 架构（10B 激活参数）强行得出的，而相比之下，基本已经过时的 Qwen3 Next 80B 采用稀疏 MoE 架构，虽然总参数量高达 80B，但激活参数仅约 3.5B，这导致它在解释小众主题时可能会遗漏一些重要事实，甚至完全胡编乱造。不过，这样做也有缺点。提示处理速度的大幅下降使得它几乎无法有意义地集成到需要查阅维基百科档案等信息的智能体工作负载中。如果没有一个约 60B 的模型来覆盖 32-48GB 内存范围，并在 Qwen3.6 35B A3B 的速度和 Qwen3.5 122B A10B 的“不差劲”之间找到平衡点，我认为我们无法在仅约 100GB 的存储空间内拥有一部数字百科全书。我们只能将就使用 Qwen3.5/3.6 35B A3B，前提是内存足够容纳——否则就得用 Gemma 4 26B A4B 或密集模型，尤其是在使用独立 GPU 而非统一内存运行 LLM 时。不过，如果你有像 AMD Strix Halo 迷你 PC 那样拥有 64GB 或 96GB 内存的设备，我想你就不会遇到这些问题了。附：我已经尝试过 Qwen3.5 122B A10B 的 REAP 变体，它们完全不行，不知为何变得更笨了，而且提示处理速度极慢的核心问题仍未解决。