在4070 Ti + 32GB RAM上测试极限MoE模型的性能：Kimi K3、DeepSeek V4 Flash和Qwen3.5-122B的结果及研究论文🔧

Reddit r/LocalLLaMA 论文
mixture-of-experts model-inference consumer-hardware research-paper benchmarking runtime-research hardware-experiments

摘要

本文详细介绍了使用自定义运行时CRANE V2在消费级硬件上进行的极限混合专家模型实验，并展示了包含Kimi K3、DeepSeek V4 Flash和Qwen3.5-122B模型结果的研究论文。

我一直在进行一个名为CRANE V2的自定义推理/运行时研究项目，主要是因为我想回答一个愚蠢的问题：在普通消费级Windows机器上，你能把荒谬巨大的MoE模型推到多远，直到物理极限真正获胜？硬件并不特殊：Ryzen 7 7800X3D、RTX 4070 Ti 12GB、32GB DDR5、Lexar NQ700 2TB NVMe + Samsung 970 EVO Plus 1TB NVMe、Windows 11。到目前为止，我测试了三个主要目标：Kimi K3（2.779T参数 / 711GB检查点）、DeepSeek V4 Flash Q4 + Q3，以及Qwen3.5-122B-A10B Q4。这篇论文是一份26页的证据锁定报告，包含成功运行、失败分支、质量门控、硬件测量、缓存实验、运行时变更和声明边界。 在展示有趣数字之前的重要免责声明：最高吞吐量结果并不等同于以完整能力运行原始模型。CRANE有意将速度墙实验与质量保留实验分开。一些最快的配置文件改变了专家路由、精度或共享专家行为，导致输出完全垃圾。我特别不声称“2.8T Kimi以9 tok/s正常运行”或“122B Qwen以57 tok/s正常运行”。论文将这些数字分开放在不同的账本中，正是出于这个原因。 到目前为止的主要结果：Kimi K3：规范的首令牌控制为0.014459 tok/s。一个故意修改的速度墙配置文件最终在64个令牌上达到9.314978 tok/s，但有用的文本被破坏，质量恢复甚至未能通过故意简单的“巴黎”门控。DeepSeek V4 Flash Q4：修改的静态路由最终在128个令牌上达到42.26 tok/s，同样产生了无法使用的文本。DeepSeek V4 Flash Q3：这变得更加有趣。使用每个选定专家的原始源张量，零回退，动态前二路由，相同的选定路由质量边界从1.14提升到8.08 tok/s，同时正确回答“巴黎”。它仍然不是规范的前六DeepSeek，我也不将其呈现为如此。Qwen3.5-122B：速度墙测试在128个令牌上达到57.38 tok/s，但这使用了静态捕获路由、融合门/上处理并跳过了共享专家。输出是多语言垃圾。实际的规范前八控制以1.89 tok/s产生了“巴黎”，这是有意义的质量数字，而不是57.38。 我个人认为比巨大标题数字更有趣的部分是实验教会了运行时什么。CRANE最终将两个物理SSD上的权重视为一个逻辑存储，按需加载确切的专家切片，在两个驱动器上条带化专家库读取，使用固定主机暂存，重叠存储和GPU传输，构建有界GPU专家缓存，测量路由局部性，实验LFU/LRU替换，测试CPU近权重执行，并保留详细的每次运行证据，而不是信任碰巧看起来最酷的数字。 特别是对于DeepSeek Q3，双SSD并行读取将确切配置文件从1.14提升到3.69 tok/s，固定暂存达到7.08，流水线达到7.50，九槽缓存达到7.91，衰减LFU最终将结果固定在8.08 tok/s，专家回退为0。也有很多失败。更大的缓存变得更慢。DSpark推测解码使确切的DeepSeek目标退化。主机L2缓存输给了直接固定读取。路由器评分驱逐输给了衰减LFU。Qwen暴露了一个实际的聊天模板参数传递错误，必须与模型质量失败分开。一些运行只是达到了显式的RAM安全地板并被终止，而不是允许将Windows变成弹坑。 当前结论实际上相当保守：Kimi K3、DeepSeek V4或Qwen3.5-122B都没有被批准作为此运行时最终服务应用程序的实际本地模型。大型模型实验很有用，因为它们暴露了架构和硬件边界。下一个目标是一个实质上更小的MoE，其中CRANE可以保留真实能力，而不是用智能交换基准速度。 CRANE V2尚未公开发布。这仍然是一个活跃的研究/运行时项目，我不想因为一些数字有趣就将未完成的二进制文件/源代码树放到网上。当前的运行时合约存在，实验有详细日志，但我想在将其视为其他人应该实际使用的东西之前，确定架构和质量保留目标。附带的论文目前也是一份本地技术报告，未经同行评审，随着新模型实验的添加，研究仍在增长。我现在分享主要是因为结果变得足够有趣，我非常希望从实际使用llama.cpp、MoE路由、外部核心推理、缓存、Windows内存行为等的人那里获得反馈。如果您发现错误假设、误导性解释、缺失控制或其他值得测试的方法，请指出来。将速度和能力证据分开的全部意义在于，我宁愿正确记录丑陋的结果，也不愿赢得一个想象的基准。是的，让一个711GB / 2.779T参数的Kimi检查点在这台机器上产生哪怕一个真实令牌，最初就是整个愚蠢的实验。它稍微升级了。😭 https://docs.google.com/document/d/1pENke9QLMAJuxwhsUkEjDzXtag\_q20fp/edit?usp=drivesdk&ouid=115131734398029449735&rtpof=true&sd=true
查看原文

相似文章

Qwen3.8-Max 媲美 Kimi K3 和 DeepSeek V4 Flash

Reddit r/LocalLLaMA

Qwen3.8-Max 是一款 2.4T 参数的开源权重模型，在基准测试中与 Kimi K3 和 DeepSeek V4 Flash 表现持平，在编码和软件任务上尤为出色。权重将于下周发布，定价为输入 $2/百万 tokens、输出 $6/百万 tokens。