原贴链接

为了从大型语言模型（LLM）获取下一个标记，我们通过将最后一个隐藏状态与输出嵌入矩阵相乘来计算LLM词汇表中每个单独标记的概率。这个矩阵非常庞大，在小型多语言LLM中占总参数的20%。当使用top - k采样来采样下一个标记时，我们从128,256个（对于Llama 3.2模型）中仅采样40个最可能的标记。通过使用HNSW向量索引，我们可以通过对输出嵌入进行近似最近邻搜索直接检索这40个最可能的标记，避免与输出嵌入进行完整的矩阵乘法。这减少了内存访问和计算，从而使中端笔记本电脑上的Llama 2.1 1B的基于CPU的推理速度提高了28%。更多细节，请阅读[martinloretz.com/blog/vector - index - cpu/]上的完整博客文章。## 基准测试 针对Llama 1B F16的llama - bench（Ubuntu = Intel® Core™ i7 - 10750H x 12，2 x 16GiB DDR4 2933 MHz，MacBook = MacBook Pro 16" M4 Pro，vec = 向量索引，MM = 矩阵乘法（参考））：|模型|线程|测试|Vec t/s|MM t/s|加速比| |:——|:——:|:—-:|:——–:|:——–:|:——:| |Ubuntu|1|tg256|5.99 ± 0.05|4.73 ± 0.04|1.27| |Ubuntu|6|tg256|12.51 ± 0.30|9.72 ± 0.13|1.29| |MacBook|1|tg256|23.56 ± 0.24|20.11 ± 0.44|1.17| |MacBook|10|tg256|12.52 ± 0.31|11.80 ± 0.18|1.06| 选择Llama 3.2 1B进行这些基准测试是因为其相对较大的嵌入矩阵（占所有参数的21%）。较大模型的完整模型加速比较低，因为计算输出嵌入花费的时间较少。要复现这些基准测试，请查看fork of llama.cpp的代码。安装说明在自述文件中。

讨论总结

原帖作者介绍了一种利用HNSW索引加速CPU端LLM推理的方法并给出了相关的基准测试结果。评论者们反应多样，多数人对原帖成果表示肯定，有人对加速的工作原理存在疑惑并通过参考ChatGPT等方式来理解，还有人关注该方法对较新模型的加速效果和价值，也有人探讨该方法对特定构建模型（如Gemma 2 2b、Lumina 2.0）的影响，并且有评论者表示要尝试这种方法并得到原帖作者的积极回应。

主要观点

  1. 👍 对原帖成果表示肯定
    • 支持理由：原帖提出新的加速方法并展示一定成果，评论者认可这一成果，如“Nice job!”
    • 反对声音：无
  2. 🤔 希望看到不同设置下结果质量的标准基准测试
    • 正方观点：为了更好地评估该方法的有效性，不同设置下的基准测试很有必要
    • 反方观点：原帖作者无法提供标准基准测试，但分享了一些实验观察
  3. 🔥 对原帖提到的加速推理的工作原理存在疑惑
    • 正方观点：原帖没有把工作原理阐述得非常清晰，例如如何避免某些计算过程不清楚
    • 反方观点：原帖作者及其他评论者通过举例（将输出嵌入看作点等）来解释原理，以回应疑惑
  4. 💡 对加速方法应用于较新模型（如llama3）的加速效果表示好奇并质疑价值
    • 正方观点：多数人倾向新模型，所以想知道该方法对新模型的效果及价值
    • 反方观点：无明确反对，原帖作者未对价值质疑做出直接反驳
  5. 👍 该方法对基于Gemma 2 2b构建的事物有一定帮助
    • 支持理由：Gemma 2 2b有巨大词汇量，该方法有助于其相关的推理构建
    • 反对声音：无

金句与有趣评论

  1. “😂 Nice job!”
    • 亮点：简洁地表达对原帖成果的认可态度。
  2. “🤔 I can’t provide you with any standardized benchmarks, from my experiments I can share the following observations: For ef_const I used 5000 to get the maximum out of it as it’s only done once for a model and the index can be distributed with the model.”
    • 亮点：原帖作者在不能提供标准基准测试的情况下分享自己的实验观察。
  3. “👀 如何避免h*v，你做了什么?”
    • 亮点：直接提出对工作原理中避免计算的疑惑。
  4. “🤔 Nice. But regarding your last paragraph since most people are probably prefering more recent models, how much speedup does this apply to say llama3?”
    • 亮点：提出了多数人关注的新模型的加速效果问题。
  5. “👍 这应该对基于Gemma 2 2b构建的东西有一点帮助。”
    • 亮点：探讨该方法对特定模型构建的影响。

情感分析

总体情感倾向是积极的，多数评论者对原帖成果表示肯定。主要分歧点在于对该方法在新模型中的价值探讨以及对工作原理的疑惑理解。积极的原因是原帖提出了新的加速方法且有一定的成果展示，大家在肯定的基础上进行深入的技术交流；疑惑和价值探讨也是正常的技术讨论范围内的不同观点交流。

趋势与预测

  • 新兴话题：该方法在新模型中的实际应用效果以及如何进一步优化以适用于更多场景。
  • 潜在影响：如果这种加速方法被证明在更多模型尤其是新模型中有较好效果，可能会对LLM在CPU端的推理效率提升产生积极推动作用，也可能会影响相关技术在设备端的部署策略。

详细内容：

标题：一种加速基于 CPU 的 LLM 推理的新方法在 Reddit 引发热议

最近，Reddit 上有一个帖子引起了广泛关注，该帖子介绍了一种使用 HNSW 索引加速基于 CPU 的 LLM 推理的方法。帖子称，在从 LLM 中获取下一个标记时，通过在输出嵌入上使用 HNSW 向量索引，可以避免与输出嵌入矩阵的完整乘法运算，从而减少内存访问和计算，使 Llama 2.1 1B 在中端笔记本电脑上的 CPU 推理速度提高了多达 28%。该帖获得了大量的点赞和众多评论。主要的讨论方向集中在这一方法的效果、适用范围以及与其他技术的对比等方面。

在讨论中，主要观点和争议点如下： 有人认为应该提供关于各种 ef_const 和 ef 设置与 top-k 采样在结果质量上的标准基准测试。 有人好奇这种方法对像 mass moe 这样的技术会有多大影响。 还有人对这一方法的原理提出疑问，通过解释，了解到可以将输出嵌入视为高维空间中的点，使用 HNSW 这种基于图的搜索算法来高效找到最可能的候选标记，从而减少计算量和内存访问。 有人询问这一方法对更新的模型如 llama3 的加速效果如何，是否值得在新模型中应用。

有人分享道：“对于 ef_const 我使用 5000 来获得最大效果，因为它对于一个模型只做一次，并且索引可以与模型一起分布。M 值为 32 效果不错，可能是连接数的正确权衡。我主要尝试了 ef 值，对于 llama 3.2 1B，ef 值为 100 或更低时，会注意到每隔几个单词就会有一些‘异常’或无意义的标记生成。对于 ef 值为 200 时效果很好，当固定采样生成器的种子时，前 10 个左右的单词生成完全相同，之后会有不同但在上下文中合理的单词。”

有人提供了一个相关的解释链接：https://www.pinecone.io/learn/series/faiss/hnsw/

总的来说，大家对这一加速方法表现出了浓厚的兴趣，同时也在探讨其在不同场景和模型中的应用效果及潜力。这一讨论不仅有助于深入理解这一技术创新，也为相关领域的发展提供了更多的思考和方向。