原贴链接

不久前,Phi 3.5 发布,同时还有 Phi-3.5-MoE(16x3.8B)。我个人认为这个 MoE 模型听起来非常有趣,因为它有 66 亿活跃参数,速度会非常快,而且总共有 600 亿参数,我认为它的知识水平几乎与 700 亿参数的模型相当。

为什么 llama.cpp 还不支持这个模型呢?是因为模型在测试中的表现不佳,因此不值得添加支持吗?还是因为缺乏时间和/或难以找到具备正确技能的人来添加支持?

似乎在 llama.cpp 的 GitHub 上支持 Phi-3.5-MoE 的问题已经逐渐减少。

讨论总结

本次讨论主要围绕微软未为Phi-3.5-MoE模型提供支持的问题展开。讨论中涉及了微软对开源项目的贡献态度、公司内部的官僚主义问题,以及微软对开放权重的实际兴趣等话题。评论者们对微软在训练模型后未能提供必要的支持表示不解,认为这可能导致用户失去兴趣。同时,讨论中也涉及了llama.cpp社区的志愿者性质,以及新模型架构的复杂性导致支持困难的问题。总体而言,讨论情感倾向复杂,既有对微软的不满,也有对社区和技术挑战的理解。

主要观点

  1. 👍 微软应分配员工为Phi-3.5-MoE模型提供支持。

    • 支持理由:模型具有高性能和庞大的参数规模,值得官方支持。
    • 反对声音:微软可能更关注内部测试和实验,而非开放模型。
  2. 🔥 llama.cpp主要由志愿者组成,新架构的实现依赖于对特定模型感兴趣的开发者。

    • 正方观点:志愿者根据兴趣和需求实现功能,符合开源精神。
    • 反方观点:新模型架构复杂,导致支持困难,社区兴趣不足。
  3. 💡 Phi-3.5-MoE模型在减少幻觉方面表现良好。

    • 解释:尽管社区兴趣不高,但模型性能得到部分用户认可。
  4. 💡 微软可能因内部官僚主义问题而未能提供支持。

    • 解释:公司策略和内部流程可能阻碍了模型的支持工作。
  5. 💡 Phi-3.5-MoE模型在实际应用中不如其他模型。

    • 解释:训练数据主要是合成数据,提示方式特定,硬件需求高。

金句与有趣评论

  1. “😂 Microsoft should spare a guy to do it.”

    • 亮点:幽默地指出微软应分配员工支持模型。
  2. “🤔 The answer to the question: ‘Why does llama.cpp not support X’ is more often than not pretty simple. No volunteer cared enough about the model to implement it.”

    • 亮点:简洁解释了llama.cpp不支持某些模型的原因。
  3. “👀 Please notice number of voices ‘AI is taking job from programmers!!!!!!111oneoneone’ then ‘why this is not coded yet’ :)”

    • 亮点:讽刺地表达了人们对AI技术的矛盾心态。
  4. “😂 I think that you overestimate the existence of llama.cpp as an entity or organization that is capable of deciding whether to implement support for a given model or not.”

    • 亮点:幽默地指出llama.cpp并非有组织的实体。
  5. “🤔 I’ve been running it for a few days and it is a fantastic model.”

    • 亮点:直接表达了对Phi-3.5-MoE模型的高度评价。

情感分析

讨论的总体情感倾向复杂,既有对微软未能提供支持的不满,也有对社区和技术挑战的理解。主要分歧点在于微软是否应为模型提供官方支持,以及llama.cpp社区的志愿者性质。可能的原因包括微软的内部策略、官僚主义问题,以及新模型架构的复杂性。

趋势与预测

  • 新兴话题:Phi-3.5-MoE模型的实际应用性能和社区支持问题可能引发后续讨论。
  • 潜在影响:微软对开源项目的支持态度可能影响未来模型的发展和社区的参与度。

详细内容:

标题:关于 Phi-3.5-MoE 支持的热门讨论

不久前,Phi 3.5 发布,其中包括 Phi-3.5-MoE (16x3.8B)。这一模型听起来相当有趣,拥有 6.6b 活跃参数,速度极快,总计 60b 参数,想必具备与 70b 模型几乎相同的知识水平。但 llama.cpp 目前却不支持这一模型。此帖引发了众多讨论,获得了大量的关注和众多评论。

讨论的焦点主要集中在 llama.cpp 不支持 Phi-3.5-MoE 模型的原因。有人认为微软应该派人来做这件事。也有人指出,一些公司投入大量精力训练模型,却不安排员工为热门库/应用写支持,导致很多人失去兴趣。还有用户表示,大公司通常只对有企业关系或由类似企业运作的非营利组织管理的开源项目做贡献,而 llama.cpp 是个社区项目,所以它们不参与。

有人提出疑问,为什么微软没有创建自己的引擎/软件,让消费者硬件能运行量化的 Phi 模型以方便大家使用。有人认为是因为钱都在数据中心。也有人觉得微软想卖 Co-Pilot,不想让用户运行其他随机模型。还有人猜测这可能源于微软这样的大公司内部的官僚作风,众多经理和中层经理需要批准人员任命,还要与法律团队事先协调,获得批准很困难。

有用户指出,大多数公司在公共模型上几乎不投入精力,只是交出一些内部测试的剩余成果。还有人说,对于“llama.cpp 为什么不支持 X”的问题,通常答案很简单,就是没有志愿者足够关心这个模型去实现它。

有人认为,如果 GitHub 或 llama.cpp 能实现赏金和某种支付系统会很棒,很多人愿意捐赠。也有人提到,该模型性能与 Gemma-2-9b 相当,但需要能运行 Gemma-2-27b 的硬件,还存在“phi”综合征,需要特定方式提示,所以不如运行更大的 Gemma。有人测试后认为这个模型并不出色,可能大家对它不够感兴趣所以没人实现支持。

总之,关于 llama.cpp 不支持 Phi-3.5-MoE 模型的原因众说纷纭,尚无定论。是因为模型本身不够出色,还是因为缺乏志愿者的兴趣和支持,或者是其他复杂的原因,仍有待进一步探讨。