原贴链接

GGerganov表示，增加多模态支持是具有良好软件架构技能的新人参与项目的绝佳机会。代码库中已经包含了从模型转换、数据加载、后端使用到推理的通用低到中级模式及细节。要实现视觉模型支持并正确扩展API，需要一些对项目高级架构的理解。我们非常需要具备这类技能的人才，因此目前我认为最好等待看是否有人出现并长期帮助项目。否则，恐怕我们无法维持项目质量。有人能推荐从低中级模式到高级的学习资源吗？谢谢。

讨论总结

讨论主要聚焦于如何学习和贡献高阶架构到 GGUF 项目。帖子作者和多位评论者表达了技术上的困惑和资源需求，尤其是初学者在面对复杂项目结构时的无助感。部分资深开发者提供了支持和建议，但也有人指出项目结构过于臃肿，难以维护。此外，讨论中还涉及了学习动力不足和代码不适感等心理层面的议题。

主要观点

  1. 👍 技术困惑与资源需求
    • 支持理由：多位用户表示对高阶架构的学习感到困惑，缺乏相关资源。
    • 反对声音：部分用户认为应更多自学，利用现有文档和社区支持。
  2. 🔥 项目结构问题
    • 正方观点：if47认为项目结构臃肿，建议拆分为多个小项目。
    • 反方观点：compilade认为单一仓库更便于快速发展的项目管理。
  3. 💡 学习动力不足
    • Admirable-Star7088承认缺乏学习新项目的动力，尤其在无导师的情况下。
  4. 🛠️ 开发支持
    • Remove_Ayys表示愿意帮助新开发者，已在个人Github页面上表达此意愿。
  5. 😣 代码不适感
    • LinkSea8324表示看到llama.cpp代码会引发PTSD，反映了对代码风格的不满。

金句与有趣评论

  1. “😂 ClumsiestSwordLesbo：This confused me greatly too”
    • 亮点：反映了普遍的技术困惑。
  2. “🤔 Remove_Ayys：As I have written on my Github page, I will happily talk to potential devs and help them get started.”
    • 亮点：展示了社区支持的重要性。
  3. “👀 if47：llama.cpp is already bloated, the current project structure is difficult to maintain.”
    • 亮点：直接指出了项目结构问题。
  4. “😓 Admirable-Star7088：学习一个架构/独立进入一个项目，没有老师或监督，需要大量的血、汗和泪。”
    • 亮点：生动描述了独立学习的困难。
  5. “🙀 LinkSea8324：Seeing llama.cpp code triggers my PTSD of LuaJIT code”
    • 亮点：极端的代码不适感表达。

情感分析

讨论总体情感倾向为中性偏负面。主要分歧点在于技术理解的难度和项目结构的合理性。负面情绪主要源于技术困惑、学习动力不足和代码不适感，而正面情绪则来自社区支持和开发者的帮助意愿。

趋势与预测

  • 新兴话题：项目结构优化和社区支持机制的改进。
  • 潜在影响：可能促进GGUF项目更加关注初学者友好性和代码可维护性，吸引更多新开发者参与。

详细内容：

《关于学习高级架构以助力 GGUF 的热门讨论》

在 Reddit 上，有一个关于学习高级架构以助力 GGUF 的帖子引发了众多关注。该帖由 GGerganov 发布，链接为 https://github.com/ggerganov/llama.cpp/issues/8010#issuecomment-2376339571 。GGerganov 表示：“我的观点是，为项目添加多模式支持对于具有良好软件架构技能的新人来说是一个很好的参与机会。从模型转换到数据加载、后端使用和推理，实现所需的一般低到中级模式和细节已经在代码库中可用。要为视觉模型实现支持并以正确的方式扩展 API，需要对项目架构有一些高级的理解。我们真的需要更多具有这种技能的人，所以在这一点上，我觉得最好等待看看是否有人会出现并抓住这个机会长期帮助这个项目。否则，我担心我们无法维持项目的质量。” 此帖获得了大量的关注，引发了热烈的讨论。

有人提出不知道从何处开始学习 GGerganov 所说的从低到中级模式到高级的内容。有人分享道：“这也让我感到非常困惑。” 还有用户表示：“作为在 llama.cpp 项目中提交次数仅次于 Georgi 和 slaren 的开发者（主要是 CUDA 方面的内容），正如我在我的 Github 页面所写的，我很乐意与潜在的开发者交流并帮助他们入门。” 并有人回复“谢谢！很快会联系您。”

关于项目的结构，有人认为“llama.cpp 已经很臃肿了，当前的项目结构难以维护。维护者应该首先使用语义版本控制将其拆分为几个小项目，以分离核心、cli 和服务器。在他们正式这样做之前，很难做出贡献。”但也有人觉得“实际上，对于一个快速发展的项目，我认为作为一个‘单体仓库’更简单，因为它可以更轻松地在单个 PR 中进行更广泛的 API 更改，而无需分别同步多个子项目的不必要开销。”

有开发者表示“作为一名开发者/程序员，我有时会想也许我应该熟悉 llama.cpp 项目并对其进行改进和添加我想要的功能。问题是我甚至不知道在这个项目中从哪里开始以及首先需要学习哪些部分，而且我一直懒得开始这些首先繁琐且耗时的步骤。从我的经验来看，在没有老师或主管的情况下独自学习架构/进入一个项目需要付出很多心血和汗水。不幸的是，到目前为止我还没有动力在 llama.cpp 上这样做。我已经在我已经有深入了解的环境和项目中变得太舒适了。” 还有人提出“如果有人编写一个脚本将整个代码库复制到一个单个的顺序 word 文档或 PDF 中，然后可以将其上传到 gemini，我们可以要求 gemini 读取它并吐出一个学习计划。” 但也有人回应“把所有代码放在一个文件不是问题，但我怀疑 Gemini 或任何其他现有的 LLM 能够正确理解如此巨大和复杂的代码库。” 有人称“虽然您说得对，但它应该能够了解代码库正在使用哪些库，并据此列出主题列表。” 还有人说“看到 llama.cpp 代码会引发我对 LuaJIT 代码的创伤后应激障碍。”

在这场讨论中，大家对于如何学习相关架构以及项目的结构和改进方向存在不同的看法。一方面，有人认为项目结构需要优化以便于贡献；另一方面，也有人认为当前的单体仓库模式有其优势。同时，对于如何入门学习以及利用现有资源也存在争议。而大家的共识在于都希望能够更好地推进项目的发展。一些独特的观点，如将代码库整理为文档并借助 gemini 制定学习计划，丰富了讨论的内容。但究竟如何有效地学习和改进 llama.cpp 项目的架构，仍然是一个有待深入探讨和解决的问题。