原贴链接

这可能是在消费级硬件上运行DeepSeek - V3的最佳且最用户友好的方式，或许也是最经济实惠的方式。听起来终于可以在家用本地设备运行一个类似GPT - 4o水平的模型了，甚至可能质量更好。https://venturebeat.com/ai/deepseek - v3 - now - runs - at - 20 - tokens - per - second - on - mac - studio - and - thats - a - nightmare - for - openai/更新：我不确定v3和r1之间是否有区别，但这里有来自用户/u/poli - cya使用DeepSeek R1 671B 4位量化的一个13k上下文的结果。 - 提示：13140个词元，每秒59.562个词元 - 生成：720个词元，每秒6.385个词元https://www.reddit.com/r/LocalLLaMA/comments/1j9vjf1/deepseek_r1_671b_q4_m3_ultra_512gb_with_mlx/这取决于你的使用场景和对速度的容忍度，但在我看来每秒6.385个词元还不算太差。你可以按月购买，先支付1531.10美元，试用14天，如果不满意可以退款。哈哈。在2020年，如果有人说在5年后，一台1万美元的电脑可以根据一个简单的文本指令在家里仅用10分钟就能生成一个基本游戏的完全可运行代码，没人会相信。

讨论总结

这个讨论围绕DeepSeek - V3在消费级硬件上运行展开。包括模型的速度、性能、所需的上下文窗口、硬件的功率等技术问题，也涉及到价格与性价比，不同用户对不同配置和性能的需求等方面，存在各种观点和争议。

主要观点

  1. 👍 仅用少量上下文和简单提示就公布吞吐量不实用
    • 支持理由：在实际应用场景中需要更多的上下文和合理提示处理速度，否则难以满足需求。
    • 反对声音：无明显反对声音。
  2. 🔥 真正的项目需要至少32k上下文窗口
    • 正方观点：如代码库这样的项目，较少的上下文窗口无法满足需求。
    • 反方观点：无明确反方观点，但有人关注到不同任务下的需求差异。
  3. 💡 认为宣传20 t/s的速度是不好的建议
    • 支持理由：存在之前用户的基准测试，不同上下文下速度差异大。
    • 反对声音：无明显反对声音。
  4. 🤔 在实际场景中DeepSeek - V3速度可能为5个token/秒
    • 支持理由：有用户通过自己的使用情况和经验做出此推测。
    • 反对声音：无明显反对声音。
  5. 😕 特定MLX版本的PP速度尚可但不算好
    • 支持理由：从处理文件的时间等方面来看，速度不够理想。
    • 反对声音：无明显反对声音。

金句与有趣评论

  1. “😂 To be useful today, you need something with 32k context length (bare minimum) and reasonable prompt processing speeds.”
    • 亮点：直接指出当下对模型有用的最低要求，是很多讨论的基础观点。
  2. “🤔 nah, for any real project (like a code base) you need at least 32k context window. the performance of M3 Ultra drops significantly in those situations.”
    • 亮点：强调特定项目下对上下文窗口的需求以及M3 Ultra在这种情况下的性能下降问题。
  3. “👀 It’s smoke and mirrors. They cherry - picked 20 t/s for tiny context to make it look good. At 16k of context the speed is 5 t/s.”
    • 亮点：揭露可能存在的数据挑选问题，对原帖中的速度数据提出质疑。
  4. “😏 I’m using QwQ to process code at 300 tok/s and I’m thinking I need 1000 tok/s.”
    • 亮点：通过自身使用情况表明对速度的更高需求。
  5. “🙄 Dammit man you are so cocky, Dunning - Kruger is streaming out of you.”
    • 亮点：在讨论中带有一定情绪的表达，反映出讨论者之间的态度碰撞。

情感分析

总体情感倾向比较复杂。一方面，部分人认可DeepSeek - V3在消费级硬件上运行这一成果所代表的技术发展方向，表现出正面情感；另一方面，很多人对其性能（如速度、处理能力等）提出质疑和担忧，存在负面情感。主要分歧点在于模型的性能是否能满足不同需求，可能的原因是不同用户的使用场景、对硬件和模型的期望以及技术能力不同。

趋势与预测

  • 新兴话题：是否4bit可行以及可能影响基准测试数量展示的技术问题等可能会引发后续讨论。
  • 潜在影响：如果DeepSeek - V3这种模型能在消费级硬件上成功运行并优化性能，可能会改变人们对AI模型硬件需求的看法，也可能影响消费级硬件在AI领域的市场布局。

详细内容：

《Reddit 热讨：Mac Studio 运行 DeepSeek-V3 的性能与价值争议》

近日，Reddit 上一则关于在 Mac Studio 上运行 DeepSeek-V3 的帖子引发了热烈讨论。该帖称这可能是在消费硬件上运行 DeepSeek-V3 的最佳且最友好的方式，甚至可能是最实惠的。帖子还提供了相关链接：https://venturebeat.com/ai/deepseek-v3-now-runs-at-20-tokens-per-second-on-mac-studio-and-thats-a-nightmare-for-openai/ 以及 https://www.reddit.com/r/LocalLLaMA/comments/1j9vjf1/deepseek_r1_671b_q4_m3_ultra_512gb_with_mlx/ 。此帖获得了众多关注，评论数众多，主要讨论了其性能、适用场景以及与其他硬件配置的比较。

讨论焦点主要集中在以下几个方面： 有人认为，对于当下实用的情况，需要至少 32k 的上下文长度和合理的提示处理速度。像苹果硅基解决方案在这方面存在限制，若要等待很久才有第一个令牌出现，或者在填充大量上下文时速度骤降，这样的模型和硬件组合是没有价值的。比如，有人表示自己在 1.5TB 内存的系统上运行 R1，Q8 与 128k 上下文占用 1.25TB，生成速度非常糟糕。 但也有人认为，16k 是目前本地模型的理想上下文长度，不同人的观点有所差异。还有人觉得，这取决于具体的使用和模型，自己用 100k 进行总结效果不错。 在个人经历和案例分享方面，有人分享自己在特定系统上运行的糟糕体验。 有趣的观点如“那家伙看到‘苹果’这个词就被触发了”。

有人指出，对于像代码库这样的真实项目，至少需要 32k 的上下文窗口，M3 Ultra 在这种情况下性能会显著下降。也有人思考需要多少更快的速度和更多的内存才能获得较好的上下文窗口。有人认为，对于常规模型，当前速度可用，但对于推理模型，思考时间可能过长。 有人提到，对于复杂任务，已经有允许 32k 思考令牌的基准测试。还有人比较了 Mac 与 Nvidia 在推理方面的价格和性能。 有人表示，在实际场景中，速度可能只有 5 tok/s，也有人认为当前的 MLX 版本的提示处理速度虽然可达 45 - 50 t/s，但仍不够好。

总体而言，关于 Mac Studio 运行 DeepSeek-V3 的性能和价值存在较大争议，有人认为在处理敏感数据等特定场景下具有优势，也有人对其速度和价格不太满意。究竟其是否值得投入，还需根据具体需求和使用场景来判断。