在树莓派上运行 DeepSeek-V4-Flash

我通过从 PCIe 连接的 NVMe SSD 流式加载模型权重，在树莓派 5（8GB 版）上运行了 DeepSeek-V4-Flash。Codex（GPT-5.5 xhigh）和 Claude Code（Opus 4.8 max）驱动了代码编写和测试，而我负责方向把控、架构设计和项目管理。整个项目耗时仅一周多一点，期间 Codex 和 Claude Code 大部分时间以目标驱动模式运行，经历了 160 多次实验并在实际设备上进行了主动测试。

项目初期，Codex 在目标模式下无人值守运行了超过三天，让模型在树莓派上跑起来

项目初期，Codex 在目标模式下无人值守运行了超过三天，让模型在树莓派上跑起来

最终结果是 DeepSeek-V4-Flash 以每秒 1.3 个生成 token 的速度运行，平均功耗仅为 8 瓦。显然，这并不像人们期望的聊天机器人或编码代理那样快，但这从来就不是重点。重点在于，看看是否能让一个接近前沿水平的开源权重模型，在完全离线、廉价拼凑的计算设备上运行，而且这个设备还能用电池组供电。

DS4 CLI 演示以及树莓派的能耗实时显示

DS4 CLI 演示以及树莓派的能耗实时显示

该项目的 GitHub 仓库地址：danveloper/flash-pi-dsv4

几天前我在推特上提到过这件事，但现在我想对整个项目做一个完整的记录，因为这绝对是我做过的最雄心勃勃、最不可思议的技术冒险之一。之前在我的 M3 MacBook 上运行 Qwen 3.5 397B 也算相当大胆，但 Apple Silicon 的统一内存架构（CPU 和 GPU 共享内存）本身就是一个强大的平台。树莓派虽然也有统一内存和 GPU，但性能严重不足，只有一颗 ARM Cortex-A76 CPU（移动设备级别的处理器），而且我这款只有 8GB 低功耗 DDR4 内存。它的 VideoCore GPU 基本上只适合视频输出，在本项目中并未使用。

做这个项目的原因有很多，但最主要的是：开源权重模型已经达到接近前沿水平的能力，却仍然需要庞大的计算平台，普通爱好者基本无法触及。我想看看，用最小、最便宜、现成的计算设备，搭配目前最好的开源权重模型之一，到底能走多远——用速度换取更低的成本和更低的功耗。

庞大的 GPU 集群价格高昂且耗电巨大。超大规模云服务商（谷歌、亚马逊、微软等）和大型实验室（Anthropic、OpenAI、谷歌、xAI 等）正在疯狂抢购尽可能多的电力、GPU 和内存芯片，以满足迅速增长的 AI token 经济。这使得 AI 和技术的未来集中在少数几家公司手中——只有它们拥有资金、采购渠道、能源合同和数据中心资源，能够获取尽可能多的算力和电力。而来自世界另一端实验室的开源权重模型，永远无法在 AI 前沿上与每年投入数千亿美元的美国实验室竞争，但对于爱好者的家庭实验室来说，可能已经足够好了。

本项目最重要的目标是，在尽可能低的功耗下演示 AI 推理，这使得树莓派成为一个有吸引力的目标平台。对于需要这种智能水平的应用，比如机器人或高级自动化，必须考虑持续功耗。我的假设是：无人值守的自动化不需要聊天界面或编码代理那样的实时吞吐量，但肯定能从更高智能的模型中受益。如果你不是坐在那里盯着 token 流式输出，那么一个能以每秒 1-2 个 token 进行推理、并在几分钟或几小时内采取行动的平台，可能是可以接受的。

粗略比较一下功耗范围：一个 50 美元的电池组可提供高达 74Wh 的电量，在全力推理（约 1 个 token/秒）且不充电的情况下，大约可使用 9 小时，大约可生成 32,000 个 token。显然，这永远无法与调用在线 AI 提供商的 API 相提并论，但拥有一个完全离线、高度定制、高度智能的代理在“拼凑计算”上运行，希望能激发一些关于可能性的想法。

它是如何工作的？

简而言之，这个项目的诀窍在于：在任何时间点，只有模型中真正需要计算的部分被加载到内存中，其余部分留在 SSD 上，并恰好及时激活。这使得一个通常需要数据中心级内存的巨型模型，能够在仅有 8GB RAM 的小型平台上运行。底下有上千个微优化，但核心思想很简单：让 CPU 保持忙碌，让 SSD 持续读取，避免加载任何即将用不到的字节。

该项目使用了 Antirez 的“DwarfStar4”GGUF 模型，这是一个对共享模型权重进行 4bit 量化，并对路由专家进行巧妙的 iMatrix 2bit 量化的模型。这一点很重要，因为 DeepSeek-V4-Flash 是一个混合专家（MoE）模型。在 MoE 变压器中，token 仍然经过模型的层堆栈，但某些前馈块包含多个专家 MLP。路由器决定每个 token 在该层应该由哪些专家处理。在 Antirez 的模型中，这些路由专家被量化到 2bit，这大大减少了每个活跃专家需要加载的数据量。

默认配置下，每次前向传播会将每个 token 路由到一定数量的专家。对于 DeepSeek-V4-Flash，这个数量是 6 个。你可以通过牺牲质量来减少活跃专家数量，我发现 4 个专家在成本与质量之间是一个合理的权衡，不过差异并非完全不可察觉。进一步减少的最大风险是模型会变得“平滑大脑”，开始重复自己或输出垃圾结果。对于 Qwen 的情况，我采用二分搜索来确定模型能正常输出 JSON 字符串时的专家数。对于 DeepSeek，我将其减少到 2 个，发现对话和代码质量仍然可以接受，因此本项目的最终配置每次前向传播只使用 2 个专家。你的体验可能会有所不同。

权重按需从磁盘流式传输到 RAM，这之所以可行，主要是因为 NVMe SSD 的吞吐量已经变得异常出色。一般情况下，它不能替代 RAM，我也不想假装 SSD 就是 DDR4，但对于精心排序的顺序读取，现代 NVMe 存储的速度已经足够快，成为一种有趣的流式传输载体。树莓派 5 的 PCIe 3.0 通道理论最高速度约为 985 MB/s。实际上，在 ext4 文件系统上使用 64kb 预读大小时，引擎可以持续拉取约 600MB/s 的数据。最终的考量并非抽象地“让磁盘变快”，而是“让磁盘足够快，并加载正确的字节，使 CPU 保持饱和”。

最后这一点非常重要。模型做出专家路由决策后，引擎需要寻找到权重载荷中该专家的位置，抓取该专家的字节，加载到内存，并保持推理管线持续运行。最大的敌人是空闲时间。你既不想让 CPU 空闲等待磁盘，也不想让磁盘急切地加载一堆 CPU 永远不会用到的无关权重。

按照设计，GGUF 中的专家按张量类型打包，例如“gate”、“up”和“down”。就我们的目的而言，这意味着单个专家的张量散布在数百兆字节无关的权重中，这些权重与当前计算无关。在原生按张量排列的格式中，读取一个专家需要进行多次较小的顺序读取，从该专家的 gate 张量跳到 up 张量再到 down 张量，中间夹杂大量无关字节。

这对于高吞吐量的流式推理非常不利，因此我们将专家重新打包为按专家排列的格式。不再将所有 gate、所有 up、所有 down 分别存储，而是将每个专家的活跃字节在磁盘上连续存储。当路由器选择一个专家时，引擎可以发起一次大的读取，读取它实际需要的字节。将这些数据块对齐到 2MB 的步幅，即可获得高读取吞吐量，同时避免意外地将无关权重拖入 RAM。简而言之，我们“对权重进行了碎片整理”。

模型完全在树莓派的 CPU 上运行，对于这类任务来说，这通常是一个性能严重不足的设备。尽管如此，我仍然对 Cortex-A76 的实际能力感到惊讶。它是一个四核 ARM 芯片，支持 NEON SIMD，这为低精度矩阵乘法提供了路径。一个自定义的 NEON 内核将相关的矩阵数学操作融合在一起，使 CPU 每次调用能完成更多有用的工作，开销更小，缓存行为也更好。

对齐的权重和融合的内核使 CPU 和 SSD 能够同时保持忙碌。当 CPU 正在计算当前专家时，引擎可以准备下一次读取。实际上，CPU 和磁盘都还有一点余量。我测量的平均持续 CPU 使用率约为 87%，磁盘吞吐量约为 600MB/s，而理论 PCIe 上限为 985MB/s。可能还有进一步的优化可以更接近理论极限，但我没能找到。

快速回到 CPU 的 SIMD 支持：Transformer 层的前馈部分是一系列顺序计算，包括前面提到的 gate、up 和 down 投影。每个计算都使用暂存空间，中间激活值会短暂存储在此，为下一个计算做准备。通常，这些激活值以 16 位或 32 位精度存储。在本项目中，我们将暂存空间保持在 8 位精度，以提高 SIMD 效率并保持较低的内存占用。当你看到类似“W8A16”的模型配置时，意味着权重以 8 位精度存储或加载，而激活值在暂存空间中以 16 位精度保留。这里的目标是让流式权重和临时激活值都尽可能节省树莓派 CPU 和内存系统的资源。

这种方法最吃亏的地方……

每个人（包括我本人）都刻意关注的一个指标是每秒生成 token 数（tokens per second），也就是生成速度的吞吐量：你在屏幕上看到的“Good”、“morning”和“!”。但推理实际上分为两个主要阶段：提示词处理（prompt processing）和生成阶段，通常称为预填充（prefill）和解码（decoding）。

预填充之前，用户的输入会被分词（tokenized），即输入字符串被拆分为预定义的块，每个块被分配一个数字。预填充阶段则将所有提示词 token 通过 Transformer 层进行处理，使每个注意力层能够计算并存储这些提示词 token 的键值状态到 KV 缓存中。在生成阶段，每个新 token 计算自己的查询，并利用这些缓存的键值进行注意力计算。

通常，预填充可以在提示词上并行化，因为完整的输入序列是预先知道的。注意力掩码保证了因果顺序，结果是为生成阶段填充了一个 KV 缓存。这种并行性使得大型 GPU 可以在第一个生成 token 出现之前快速处理长提示词。

在本项目中，预填充受到的打击最大。由于树莓派从磁盘流式加载权重，并且所有计算都在 CPU 上进行，提示词处理无法获得人们期望的常规推理硬件那种大幅并行加速。长提示词需要很长时间才能计算出第一个生成 token。这使得这种设置不适合冷启动、长文本、动态上下文处理，因此也不适合聊天机器人风格的交互。

但这不是所有用例的死穴。对于固定的指令，长 KV 缓存可以在更快的机器上预先计算，然后在推理时加载，从而基本消除了预填充成本。这对聊天机器人来说并不理想，但对于每次调用都遵循相同指令的模型来说可能是合理的，例如检查传感器或指标并决定是否采取行动。

这是更重要的一点：无人值守的自动化不一定需要与聊天窗口相同的延迟特性。如果没有人逐 token 监视代理，一个缓慢但功能强大的离线模型仍然可能有用，尤其是当任务在几分钟或几小时内展开，而不是毫秒级完成。

接下来呢？

有趣的是，这个项目最终走向了这里，因为我最初的目标是使用树莓派 + Hailo 10H HAT 构建一个预填充加速器。Hailo 芯片让我兴奋，因为它可以将模型编译到加速器的物理执行布局中，并以几瓦的功耗运行推理。我花了数十个小时将 DeepSeek 权重转换为 Hailo 所需的 HEF 格式，并且成功验证了 2 层完整运行。我本应该更早意识到这一点：Hailo 无法像这个模型所需的那样进行动态路由，因此 MoE 路由在该设备上完全不可行。

这次失败反而让我更清晰了……这个项目证明了在廉价硬件上进行低成本推理的可行路径，但也展示了当前 MoE 架构对流式推理的敌意。MoE 模型在训练时很棒，当权重已经驻留在内存中时效率很高，但对于这个项目，无法在当前层完成路由工作之前知道下一个专家，是非常残酷的限制。当所有模型层都在内存中时，这只是一个路由决策；但当模型权重从磁盘流式加载时，这个路由决策决定了接下来哪些字节需要存在于 RAM 中。

对于流式加载模型权重，如果专家层能够在下游线性对齐，那就好多了。也就是说，如果引擎能提前知道第 N+1、N+2……N+n 层需要哪些专家，它就可以在第 N 层计算时急切地准备这些读取，这样 CPU 和磁盘都能更接近其最大潜力工作。如果模型架构围绕这一约束设计，树莓派上的每秒 token 数可能再增加 2-3 个。

重要的是，线性对齐的 MoE 还会重新打开像 Hailo 这样的加速器的大门。动态决策可以留在 CPU 上，而推理中可预测的部分则可以转移到加速器。不同芯片之间的 TOPS 比较很混乱，因为厂商引用的精度模式和加速器不同，但关键点是功率密度。Hailo 旨在以仅几瓦的功耗提供大量低精度推理吞吐量。如果模型执行路径的更多部分是静态可知的，那么在这种设备上进行预填充加速将变得更加现实。

除此之外，我认为小模型有更大的机会展示更高的能力。似乎随着时间推移，研究人员正在将更多智能塞进更小的架构中。OpenAI 的参数高尔夫竞赛最近挑战模型制作者，要求在一个小于 16MB 权重文件的模型架构中达到 GPT-2（1.24 亿参数）的质量，并且训练时间不超过 10 分钟。排行榜上基本是递归模型，即层被循环、权重紧密打包。如今一个几百万参数的模型，与几年前大得多的模型相比，表现惊人地出色。这是令人难以置信的进步，我确信小型递归模型是高吞吐量本地推理的未来路径之一。

让树莓派与 GPU 服务器竞争从来不是这个项目的重点。重点在于，通过量化、流式加载、布局感知的权重，以及愿意用延迟换取低成本低功耗的意愿……