原贴链接

大家好，我想我们大多数人都对DeepSeek V3感到兴奋。然而，我们大多数人没有足够的内存（RAM）或显存（VRAM）来托管这个庞然大物（671B）。不过，这个模型使用的是混合专家模型（MOE），它有很多专家，使得实际有效参数达到37B。是否有可能削减一些专家呢？（比如说使用50%的专家，性能损失20%）如果这不可行，是不是意味着大量专家的混合专家模型（MOE）是必然的发展方向呢？

讨论总结

这个讨论主要围绕DeepSeek V3展开，原帖提出是否可以对其MOE中的专家进行修剪或者减少数量，因为很多人没有足够资源来托管这个大模型。评论者们从不同角度进行了讨论，包括技术上如何处理专家（如合并等操作的可行性）、模型自身专家的特性不能随意削减、如果资源不足可以租用云服务器或使用API、在其他模型上的尝试经验、希望模型能缩小规模或量化发展以及相关的商业应用等方面的问题。整体氛围是积极探索和交流的。

主要观点

  1. 👍 存在用于合并相同架构不同模型的技术，但LLMs还未实现。
    • 支持理由：评论者指出一些技术用于合并相同架构的不同模型，但LLMs目前还没有类似基础模型的实现。
    • 反对声音：无
  2. 🔥 MOE模型中的专家工作方式特殊，不能随意削减。
    • 正方观点：就像RAID阵列中的硬盘，去掉一个会使相关文件损坏，专家工作方式并非想象那样可简单操作。
    • 反方观点：无
  3. 💡 可以用常见提示来剖析模型。
    • 解释：通过剖析模型来处理专家相关操作，比如找到调用频率低的专家进行合并等操作。
  4. 💡 希望看到DeepSeek V3缩小规模或量化的发展。
    • 解释：因为大多数人受资源限制无法托管该模型，这样能让模型更好地被应用。
  5. 💡 已有针对MoE的类似想法，可以向有类似想法的人寻求对DeepSeek的支持。
    • 解释：向有经验的人寻求支持可能有助于DeepSeek V3相关问题的解决。

金句与有趣评论

  1. “😂 我整晚都在思考如何“合并”专家。”
    • 亮点：表明评论者积极投入到关于模型专家处理的思考中。
  2. “🤔 Experts in MoE models don’t work like you think they do.”
    • 亮点：强调MOE模型专家工作方式的特殊性，改变人们可能存在的错误认知。
  3. “👀 我也希望看到任何能缩小或量化DeepSeek V3的发展。”
    • 亮点：表达了大众对于DeepSeek V3能够更广泛应用的期望。
  4. “🤔 如果可行的话，你甚至可以使用megekit的进化合并来尝试获得更好的结果。”
    • 亮点：提出了一种优化模型操作的可能方式。
  5. “👀 看到这么好的模型在大多数商业应用中被浪费，这很令人难过。”
    • 亮点：指出了模型目前面临的在商业应用方面的困境。

情感分析

总体情感倾向是积极探索的。主要分歧点在于MOE模型中专家能否削减，一方认为可以尝试技术手段对专家进行处理，另一方认为MOE模型专家工作方式特殊不能随意削减。可能的原因是对MOE模型的理解程度和技术操作可行性的不同判断。

趋势与预测

  • 新兴话题：对DeepSeek V3进行缩小规模或量化发展的探索。
  • 潜在影响：如果能够实现缩小规模或量化，将使更多资源受限的用户可以使用该模型，可能会对自然语言处理领域的应用范围和发展速度产生积极影响。

详细内容：

标题：关于 DeepSeek V3 自托管的热门讨论

在 Reddit 上，一篇关于“MOE pruning? DeepSeek v3 self hosted idea ”的帖子引发了热烈关注。此帖指出，尽管大家对 DeepSeek V3 满怀期待，但大多数人因缺乏足够的内存（RAM 或 VRAM）难以托管这个规模达 671B 的模型。鉴于其使用 MOE 且拥有众多专家，实际活跃参数为 37B，于是提出能否修剪部分专家（比如使用 50%的专家并承受 20%的性能损失）的疑问。如果不可行，是否意味着大量专家的 MOE 模式是未来的趋势？这一帖子获得了众多的点赞和评论。

讨论焦点与观点分析： 有人整夜思考尝试“合并”专家。还有人认为如果不需要的专家可以不加载到内存中，需要时再通过 LRU 缓存或类似方式调入。但也有人指出每个句子的每个词可能由不同专家生成，并非一个专家负责一个消息。有人觉得从数据局部性角度看，如果不是所有专家都用于每个句子，那么特定主题可能更多地使用某些专家。未来或许能在潜在空间隔离知识，实现更有效的修剪方法，但这需要更多创新。 还有人提到存在一些用于合并相同架构不同模型的技术，但目前尚未在 LLMs 中实现。有人认为可以对模型进行常见提示的“剖析”，合并调用频率低的专家，并重新配置门控器。 有人认为专家在 MOE 模型中的工作方式并非想象中那样简单，不能随意删除或合并。有人因为想在自己的 llama.cpp 分叉中运行实验以及隐私考虑不想使用 API。还有人就租用服务器进行了讨论，并提供了相关建议和资源链接。 有人尝试在 Mixtral 和 Grok - 1 上进行相关操作，并分享了链接。有人希望看到能缩小或量化 DeepSeek V3 的发展，也有人指出由于数据收集和许可问题，该模型在很多商业应用中受限。

在这场讨论中，大家对于 DeepSeek V3 模型的自托管和优化问题各抒己见，观点多样。未来如何在技术和应用层面实现更好的平衡与突破，值得我们持续关注和探讨。