大家好，欢迎来到本期节目。今天我们要做点有趣的事情：在一台五年前的旧款 M1 Max 笔记本电脑上，运行完整版、未量化的 DeepSeek V4.1 Flash 模型。这台电脑仅有 64GB 内存，而该模型体积超过 500GB。我们将展示其性能表现，并对比 M5 Max（128GB 内存）和 Mac Studio 的表现。目前它正在以每秒 1.6 token 的速度运行，利用 Engram 流式和专家流式技术。虽然速度看似缓慢，但相比之前每秒仅处理两个 token 的层流式方法已有巨大提升。

这是目前排名第一的开源权重模型，直到 Kimmy K 3.1 发布之前都位居榜首。我们在五年前的系统上运行了最高智能水平的模型，稍后我会切换到大屏幕进行详细演示。目前我们仅使用了 40GB 内存，因为系统限制了预算分配；增加这个设置可以略微提升速度。除了 DeepSeek V4.1 Flash，我们还能运行 Qwen 3.8 Flash Next。取消 DeepSeek 生成后，我用它玩 HTML 俄罗斯方块游戏。虽然尚未启用 NTP（可加速并多用内存），但在我的 128GB 系统上运行更快。

Qwen 3.8 Flash Next SE 版本的速度在每秒四到五个 token 之间波动。当首次遇到新专家时运行较慢，直到用完预算；目前因耗尽 40GB 预算而降至每秒两个 token。在低内存环境下，从 SSD 流式读取是安全的，因为读操作不会磨损硬盘。接下来测试 M5 Max：模型即将在 Hugging Face 上线，后缀“se”代表流式专家。我在 MacBook Pro M5 Max（128GB 内存）上处理约 500 token 的提示，初始速度为每秒五到七个 token。

随着专家加载填满内存，处理 500 token 提示的速度稳定在每秒七到八个 token。活动监视器显示仅使用 88GB RAM，平均速度在每秒五到七个 token 间波动：当专家序列重复时无需重新加载，复杂任务则降至每秒五个左右。最终完成文档生成，平均速度达 6.5 token/秒。此前在相同系统上测试 Qwen 3.8 Flash Next 的量化版本时，Q9 表现最佳，Q6 次之。现在测试 Qwen SE 版的九比特版本：禁用 MTP 时初始速度达每秒二十 token，随后因代码生成需切换专家而降至十二至十五 token/秒。

使用更多比特位会降低速度，因为需要更多内存并加剧专家交换频率。尽管 Q6 版本可达每秒三十 token，但九比特版在智能度与速度间取得了更好平衡。这种流式专家技术让旧硬件也能运行前沿大模型，证明了内存优化策略的有效性。通过动态加载和卸载专家模块，系统在有限资源下实现了可行的推理性能，为本地部署大模型提供了新路径。

关于GPU性能，如果Q6量化版本能达到每秒30个令牌的速度，那么切换到Q9时理论上应降至25或20左右。然而我们实际测得仅为每秒15.5个令牌。接下来，我计划启用MTP（多Token预测）功能进行测试。删除当前进程并重启后，数据显示在禁用NTP时速度为每秒15.5个令牌；而一旦启用MTP，性能瞬间飙升至接近30个令牌/秒。

实测中我们观察到了每秒25至26个令牌的惊人速度，这确实快得难以置信。从我的经验来看，系统正在流式传输专家模块并构建RAM池。幸运的是这台机器配备了128GB内存，目前使用了92GB，最终平均速度稳定在每秒22.9个令牌。相比之下，Q9版本在未启用MTP时约为30令牌/秒，启用后则达到50左右。这意味着速度减半的原因在于约40%的时间都在等待SSD流式加载层数据，未来我们将探索预取机制以进一步优化性能。

目前我们已获得了可用的生成速度。接下来我想尝试运行Kimi K3.1，看看能否在这台旧设备上跑起来并测试其速度。作为最终测试环节，我将展示它在Mac Studio上的表现。首先启动标准的DeepSeek V4.1非流式版本，输入“Tetris HTML”指令。加载模型需要一点时间，内存占用迅速攀升至280GB左右。这是因为未启用嵌入流式传输，所有数据都驻留在内存中。

当前标准版DeepSeek V4.1 Flash的生成速度约为每秒12个令牌，通常能稳定在15左右。我发现之前运行的是调试模式导致速度受限，切换至发布版后，完整版本的DeepSeek达到了每秒15.5到16个令牌。这个速度对于生成俄罗斯方块代码非常实用，具体体验取决于思考深度：若要求10万令牌的长思维链可能需要一小时；但若只需简短回答或夜间挂机运行，每秒2个令牌也足够完成任务。

尽管模型总大小超过500GB，但由于启用了嵌入流式传输，实际常驻内存仅需280GB。现在我们将测试专家流式版本（SE版），执行相同的“Tetris HTML”任务。由于基础模型极小，仅占用约20-30GB内存，加载过程明显加快。目前系统正在流式引入专家模块，初始速度仅为每秒2个令牌，这是因为我将流式预算限制在1%，即约15GB内存上限。

这种低内存策略适合需要同时运行多个模型或后台应用的用户，虽然速度较慢但能确保系统稳定。解除限制后，Mac Studio凭借512GB内存优势开始快速加载专家模块，内存占用从18GB迅速攀升至130多GB。随着更多专家被加载进流式池，推理速度显著提升。重启推理事件后，初始速度达到每秒7.5个令牌，峰值超过11个。相比之下，非流式版本稳定在每秒15个左右；而受内存约束的流式模式最高约11个。

接下来测试Qwen SE版本（9S量化）。该模型需完整加载后方可开始推理，耗时约10秒。在当今优化大模型性能的世界里，这种等待令人联想到三十年前数据库优化的艰辛历程。Qwen 9S版本在禁用MTP时达到了惊人的每秒30个令牌，启用后更是飙升至50左右。这一9位量化版本的表现令人印象深刻，我们还需进一步观察其在流式传输模式下的具体速度表现。

这就是流式版本，当我们不受专家数量限制时。因此加载应该超级快，因为模型的基础部分非常小。所以它加载得非常迅速。但现在它将开始流式传输专家模块，起初加载会有点慢。你可以看到我们一开始是每秒六个 token，然后七个 token，而且随着它能够复用要使用的专家模块数量，速度会变得越来越快。

目前我们达到了每秒九个 token 左右，而且我们在内存中只使用了模型中的 80 GB。但如果我重启推理过程，希望那些专家模块已经被缓存了，应该会更快一些。所以我们这里从每秒 15 个 token 开始。不过目前确实存在性能损失，无论如何，如果你试图使用模型的流式版本并且你有足够的内存。

如果你有足够多的内存，那就直接使用模型的标准 9S 版吧。但如果你想在 RAM 更小的系统上运行它，那么你可以使用流式版本，该版本允许你将专家模块流入流出以使其能够运行。我们成功让它跑起来了。来看看这边，我们设法运行了这些模型：DeepSeek 是目前人工智能分析领域排名第一的开放权重模型。

我们让它在五年前的这台笔记本上以每秒两个 token 的速度运行，并且我们还得到了这个：这是 Qwen（通义千问）的 9-bit 版本，速度达到了每秒 22 个 token。所以请告诉我你们对“流式内格拉姆”（streaming engrams）和“流式专家模块”的看法，你们是否期待在我们的五年老笔记本上运行 Kimmy K 3.1？

要知道，我之前只能达到每分钟一个 token。所以如果能提升到每秒一个 token 就会处于前沿水平；对于一个拥有三万亿 RAM 的模型来说，那将非常棒。实际上请告诉我你们的预测，我想要关于速度的预测：在 M1 Max 64 GB、以及 128 GB 系统上，还有配备 512 GB（原文误写为 gips）的 Mac Studio 上分别会是多少 token？

我希望你们觉得这个视频有用并享受了节目。顺便记录一下，这里是 DeepSeek V4.1 Flash 流式版本以及内存使用情况：86 GB 的内存。这是一次完整的生成过程，也就是那个三维立方体图。为了好玩起见，我们还尝试了 GLM 5.3 Flash 版。那个运行得很慢，每秒两个 token（原文误写为2,000），所以我需要优化一下。

不过我们也做了一个三维立方体图，它运行在 128 GB 的系统上。这个模型超过 300 GB，我们得到了 GLM Flash 的这个精彩三维立方体图。看啊，生成了四千个 token（原文误写为two 4,000）。它在系统上运行了，速度是每秒两个 token。现在，就 DeepSeek 而言，平均大约是每秒 5.7 个 token（原文误写为I think）。

我们也在这里得到了一个三维立方体图。所以我还需要在 M1 上完成那个测试。但你看，两个生成过程都在运行，而且它彻底搞定了（smashed it）。