原贴链接

我分享这个是以防你想知道在这样一台机器上可能会得到什么样的吞吐量。例如，如果你正在考虑是否值得购买（对我来说，我不后悔，我很喜欢这台机器）。相同的单一查询，将上下文设置为8K，下面是由LMStudio测量的每秒令牌数：LLaMA 3.2 3B 4位–181；LLaMA 3 8B 8位–55；LLaMA 3.3 70B 4位–11.8；Mistral Large 123B 4位–6.6；Mistral Nemo 12B 4位–63；Mistral Nemo 12B 8位–36；Mistral Small 22B 4位–34.5；Mistral Small 22B 8位–19.6；Qwen2.5 32B 4位–24；Qwen2.5 32B 8位–13.5；Qwen2.5 72B 4位–10.9；Qwen2.5 72B 8位–6.2；WizardLM - 2 8x22B 4位–19.4！！。为了比较，这里是在我的另一台MacBook（M1 Pro，32GB）相同设置下获得的一些数字：Mistral Nemo 12B 4位–22.8；Mistral Small 22B 4位–12.9；Qwen2.5 32B 4位–8.8。希望这是有趣/有用的。

讨论总结

原帖作者分享了MacBook M4 Max在不同本地大型语言模型下的每秒令牌吞吐量测试结果，同时给出了与MacBook M1 Pro的对比数据。评论者们提出了各种各样的问题，包括测试的具体情况（如token发送情况、测试所用MacBook型号、测试时的功率模式等）、MacBook在运行这些任务时的性能表现（如是否存在过热、降频、风扇噪音等问题，长上下文下的性能变化）、模型相关问题（如建议测试其他模型版本、不同模型在不同条件下的性能差异等），还有关于MLX使用方面的疑问以及对原帖格式的看法等，整体氛围比较和谐，大家在交流中分享信息和观点。

主要观点

  1. 👍 原帖测试输入长度约为1K个token，随着上下文增大首次出token的时间会增加，但吞吐量不会恶化
    • 支持理由：原帖作者进行了相关测试，以学术论文摘要测试为例，给出不同模型在长上下文下的数据对比。
    • 反对声音：无
  2. 🔥 Mac适合小查询，长上下文会大大降低提示处理速度
    • 正方观点：多个评论者根据原帖测试数据及自身经验，认为长上下文时Mac首次出token时间可能较长，如在长上下文时可能要几分钟或更久。
    • 反方观点：无
  3. 💡 GPU在长上下文时会耗尽显存，而Mac在非常长时虽然仍有问题但至少可用
    • 解释：评论者对比Mac和GPU在长上下文时的表现，指出Mac相对有一定优势。
  4. 💡 建议原帖作者测试Mistral Large 2411 123b的4b、6b或8bit版本
    • 解释：评论者认为这是可在消费设备上运行的优秀且较大的模型。
  5. 💡 原帖格式存在问题，需要改进
    • 解释：评论者认为原帖的格式令人困惑，希望每个模型能单独成行。

金句与有趣评论

  1. “😂 linh1987：Do you actually send 8k token in context or you only use a small prompt? I think the problem with these CPUs are mainly prompt processing performance”
    • 亮点：率先对原帖测试中的token发送情况及CPU主要问题进行提问，引发后续讨论。
  2. “🤔 linh1987：Then I guess we’re on the same page. Mac is good for smaller queries but longer context will hurt prompt processing speed by a lot. Time to first token can take minutes or more in those cases”
    • 亮点：总结双方达成一致的观点，明确指出Mac在不同查询规模下的性能差异。
  3. “👀 AppearanceHeavy6724: no surprises here, almost perfect linear scaling.”
    • 亮点：简洁地表达对原帖测试结果的看法，认为吞吐量呈现几乎完美的线性缩放。
  4. “😎 You should also test mistral large 2411 123b 4b and 6b or 8bit.”
    • 亮点：提出对新模型版本进行测试的建议，拓展原帖测试内容。
  5. “🤓 The formatting is confusing.”
    • 亮点：指出原帖格式问题，从不同角度对原帖进行评价。

情感分析

总体情感倾向为中性，主要是对原帖内容进行理性探讨。分歧点较少，主要分歧在于原帖测试中的一些未明确情况（如测试条件等），以及对MacBook性能在不同场景下的看法。可能的原因是大家都是基于对技术内容的关注，以交流信息和观点为主，没有太多主观情绪的介入。

趋势与预测

  • 新兴话题：可能会有更多关于不同模型在特定条件下（如不同上下文长度、不同功率模式等）性能比较的讨论，以及对MacBook在运行大型语言模型时如何优化性能的探讨。
  • 潜在影响：如果更多的性能优化方案被提出，可能会影响到MacBook用户在选择运行大型语言模型时的决策，也可能会促使软件开发者针对MacBook的特点进行相关软件的优化。

详细内容：

标题：MacBook M4 Max 128 GB 在本地 LLMs 中的性能测试引发Reddit热议

最近，Reddit上一篇关于MacBook M4 Max 128 GB在多个流行本地LLMs（以MLX格式）中每秒令牌吞吐量的测试引起了广泛关注。该帖子获得了众多点赞和大量评论。

原帖分享了在16英寸MacBook M4 Max（自动电源模式）上，对多个模型如LLaMA 3.2 3B 4bit等的测试结果，并与M1 Pro 32GB的相关数据进行了对比。同时，还提到了在较长上下文情况下的性能变化。

这一帖子引发了多个方向的讨论，包括MacBook在不同任务中的实际表现、与其他设备的比较、散热和电池消耗等问题。

文章将要探讨的核心问题是：MacBook在处理本地LLMs任务时的优势和局限性，以及是否值得购买用于此类工作。

在讨论中，主要观点有： 有人认为Mac对于较小的查询表现不错，但较长上下文会严重影响提示处理速度。比如，有用户分享道：“Mac是好用于较小的查询但较长上下文将极大地损害提示处理速度。在这些情况下，首次令牌的时间可能需要几分钟甚至更多。” 也有人提到Mac在处理这类任务时会发热严重，电池消耗极快。例如：“我有M3 Pro 16英寸版，运行这类推理模型时，它变得非常热，电池消耗超快。” 还有用户认为MacBook在处理较大模型时，吞吐量表现不错。如：“对于123b的Mistral Large，每秒6或7个令牌的速度非常舒适，特别是考虑到这对于Windows用户几乎无法达到。”

讨论中的共识在于，MacBook在处理较长上下文和高负载任务时存在一些挑战，但在某些特定情况下，其性能也有一定优势。

特别有见地的观点如，有用户指出MacBook在散热和电池方面的问题可能导致设备折旧成本增加，因此不建议在MacBook上运行LLMs。

总的来说，这次关于MacBook在本地LLMs中的性能测试讨论，充分展现了大家对于其性能的关注和思考。但最终是否值得购买用于此类工作，还需根据个人具体需求和使用场景来判断。