原贴链接

我正在考虑构建一个廉价的ARMv9单板计算机集群来运行Deepseek v3。据我研究，有效处理该模型大约需要664GB的内存。经过快速计算，我设想一个大约有11个节点的设置可能可行，每个节点的配置如下：CPU为ARMv9.2，约30万亿次运算每秒（如果能利用板载GPU或许能再增加10万亿次运算每秒）；内存为64GB，速度为100GB/秒；网络为双5GbE（绑定可能是一种选择）；存储为NVMe，或许每个节点1TB，如果使用Ceph的话小一点也可能够用。我对几件事感到好奇：1. 软件：你会推荐什么框架/工具来在集群中高效地分配模型？llama.cpp、exo、vLLM、带有MPI的Kubernetes、Ray或者其他完全不同的东西？2. 性能：这种设置可能实现的每秒标记数（toks/s）大概能有多少？3. 成本优化：对于ARMv9板是否有更好/更便宜的替代方案，或者在保持所需性能的同时优化成本的策略？如果您尝试过类似的事情，很想听听您的想法！

讨论总结

原帖计划构建ARMv9 SBC集群来运行Deepseek v3，并就软件框架、性能预期和成本优化提出问题。评论者观点多样，有反对构建该集群的，理由是性能可能低于快速服务器；也有给出具体构建建议的，如推荐使用RADXA Orion O6时要检查NPU支持情况，推荐llama.cpp等软件框架，还对原帖设想的TOPS需求、集群所需RAM等提出质疑并展开技术讨论，同时也涉及到成本效益的分析以及不同硬件方案的比较等，整个讨论围绕构建ARMv9 SBC集群运行Deepseek v3这一主题展开，氛围较为理性客观。

主要观点

  1. 👍 不建议构建ARMv9 SBC集群来运行Deepseek v3
    • 支持理由：这种集群每秒生成的标记（t/s）会低于一台快速服务器，如在4k语境下，会低于3 t/s。
    • 反对声音：无（未在评论中有明确反对该观点的表述）
  2. 🔥 构建集群时若使用RADXA Orion O6需检查工具对其NPU的支持
    • 正方观点：可帮助构建集群时更好利用该硬件，避免不兼容等问题。
    • 反方观点：无（未在评论中有明确反对该观点的表述）
  3. 💡 对原帖提出的TOPS需求表示怀疑
    • 解释：通过对Q8量化下的RAM数据读取速率等进行分析，认为所需的计算量可能没那么多。
  4. 💡 不要使用ARM SOC中的GPU运行llama.cpp
    • 解释：在llama.cpp中其通常比CPU慢，使用GPU会降低性能。
  5. 💡 原帖应给出预算相关信息
    • 解释：原帖提到要构建廉价的集群，但没有提及何为“廉价”，预算信息有助于更好地讨论构建方案。

金句与有趣评论

  1. “😂 Don’t do it.”
    • 亮点：直接简洁地表达不建议构建ARMv9 SBC集群来运行Deepseek v3的态度。
  2. “🤔 Maybe have a look at llama.cpp, which just got support for Deepseek - v3 and supports more quantization types.”
    • 亮点：推荐了适合运行Deepseek - v3的软件框架llama.cpp及其优势。
  3. “👀 100 GB/s如果使用Q8量化意味着最多100B权重/秒从RAM读取（每个约8位，Q8下为1字节），所以每个权重的平均计算次数并不多，我记得，所以即使1TOPS也将达到10OP/权重/秒，所以不需要比这高很多就能跟上限于100GB/s的RAM数据速率。”
    • 亮点：通过数据和计算来支撑对原帖TOPS需求的怀疑。

情感分析

总体情感倾向较为理性客观。主要分歧点在于是否应该构建ARMv9 SBC集群来运行Deepseek v3，以及原帖中关于性能需求和成本优化方面内容是否合理。产生分歧的可能原因是不同评论者的技术背景、经验以及对相关硬件和软件的了解程度不同。

趋势与预测

  • 新兴话题：不同硬件方案（如ARMv9 SBC集群与ddr5 epyc/xeon服务器）性价比对比可能会引发后续讨论。
  • 潜在影响：如果有更多关于构建廉价且高效运行Deepseek v3的方案讨论，可能会对相关人工智能领域的硬件选择和模型运行策略产生影响。

详细内容：

标题：构建廉价 ARMv9 SBC 集群以运行 Deepseek v3 的热议

最近，Reddit 上有一个关于构建廉价 ARMv9 SBC 集群来运行 Deepseek v3 的讨论引起了广泛关注。原帖中，作者表示经过研究，要有效处理该模型大概需要 664GB 的 RAM，并设想了一个由约 11 个节点组成的设置，还提出了一些相关疑问，此帖获得了众多评论和大量点赞。

讨论的焦点主要集中在以下几个方面： 有人直接表示不建议这么做，认为其每秒生成的令牌（t/s）会低于快速服务器。但也有人认为可以尝试，比如检查某些工具对所包含 NPU 的支持，或者考虑使用 CPU 或 GPU 进行推理。 对于性能方面，有人指出 Deepseek-v3 是一个 MoE，每次激活约 37B，所以推理性能更像是一个 37B 模型。理论上，如果能在 8 个节点间实现良好的并行，每秒可能达到 42 个令牌，但实际中难以接近这个数值。 在成本优化方面，有观点认为 SBC 的内存定价随容量呈对数增长，大规模的节点设置成本可能很高，需要探索捐赠支持。也有人认为可以使用大量相对性能一般的板子来降低成本。

有人分享道：“作为一名在相关领域有一定经验的研究者，我发现 GPU 的内存带宽通常更具优势，在处理大型模型时表现更出色。比如，DDR5 8000 MT/s 的内存速度明显高于普通的 SBC 所采用的规格。”

关于模型的量化和内存需求，也有详细的分析。有人提到，如果使用 Q8 量化，100 GB/s 意味着每秒最多读取 100B 权重。

讨论中存在一些共识，比如大家都认为在考虑这种集群设置时，需要综合权衡性能、成本和可扩展性。特别有见地的观点是，要充分评估不同方案的性价比，不能仅仅追求低成本而忽略了性能。

总的来说，这个关于构建廉价 ARMv9 SBC 集群的讨论充满了各种观点和思考，为有类似想法的人提供了丰富的参考和启示。但最终是否可行以及如何优化，还需要进一步的实践和探索。