原贴链接

我们都知道较长的提示会导致处理速度变慢。为了确定影响程度,我使用llama.cpp和Llama-3.1-8B - Instruct - q4_K_M测量了不同提示大小下的速度。我将每个测试作为一次性生成(不是通过多轮聊天风格累积提示)。对于rtx - 4090,速度从153.45tk/s降到73.31tk/s;对于M3 Max,速度从62.43tk/s降到33.29tk/s。更新:正如其他人指出的,启用提示缓存会有很大帮助,因为不必处理之前的提示。但是我发布这个是为了让其他人意识到,人们(包括我自己)经常分享像‘我使用8B模型得到60.5个令牌/秒’这样的数字,但如果不知道上下文长度,这些数字毫无意义。后面分别列出了RTX 4090 24GB和MacBook Pro M3 Max 64GB在不同令牌数量下的提示处理和令牌生成速度数据。

讨论总结

原帖通过在不同设备上测试不同提示大小对速度的影响,引出了一系列讨论。评论主要聚焦在prompt caching对处理长提示速度的作用、不同设备(Mac和RTX - 4090)在处理提示尺寸时的性能比较、测试中的设置(如 -fa功能)、对原帖数据关系的疑问以及涉及的技术原理(如自注意力机制下输入令牌与计算复杂度的关系)等方面,整体讨论氛围偏向技术交流,较为理性。

主要观点

  1. 👍 prompt caching有助于处理长提示带来的速度问题
    • 支持理由:缓存可以避免重新处理之前的提示内容,如只重新处理新标记。
    • 反对声音:无
  2. 🔥 Mac在处理大提示尺寸时速度表现差
    • 正方观点:有评论指出Mac在处理大提示尺寸时速度数据差,并且是苹果系统的主要弱点,不利于长时间LLM会话。
    • 反方观点:也有提到在常规聊天场景下Mac的表现还可以接受。
  3. 💡 RTX - 4090在处理提示速度上比M3 - Max快很多,但随着提示尺寸增长其速度也会下降
    • 支持理由:原帖数据表明不同提示尺寸下RTX - 4090和M3 - Max的速度对比,且随着提示尺寸增加,RTX - 4090速度也有下降趋势。
    • 反对声音:无
  4. 💡 人们分享模型速度数据时应明确上下文长度
    • 解释:单独的速度数据如果没有上下文长度是无意义的。
  5. 💡 使用llama - bench能得到标准化的硬件比较结果
    • 解释:有评论认为这是比较硬件的更好方式。

金句与有趣评论

  1. “😂 pyr0kid: jesus christ. and then theres me running a frankenstein computer where im happy with a mere 200/5”
    • 亮点:通过对比自己低性能电脑的满意速度与原帖高性能设备速度,产生一种诙谐效果。
  2. “🤔 chibop1: If your primary use is to query long documents, then you have to wait for a while for the first response. However, it’s not that bad for regular chat especially with context shift.”
    • 亮点:全面地分析了Mac在不同使用场景下(查询长文档和常规聊天)的表现。
  3. “👀 stevelon_mobs: There’s a quadratic relationship between input tokens and computational complexity due to self attention”
    • 亮点:从技术原理角度解释了提示大小影响速度背后可能的原因。
  4. “😉 chibop1: No doubt, NVidia has the speed!”
    • 亮点:简洁地强调了RTX - 4090在速度方面的优势。
  5. “🤓 a_beautiful_rhind: Caching server will help you here.”
    • 亮点:直接指出prompt caching的作用。

情感分析

总体情感倾向较为中性,主要是技术层面的讨论交流。存在一定分歧点,如对于Mac性能在不同使用场景下的评价不同,一方认为Mac处理大提示尺寸速度差是主要弱点,另一方认为在常规聊天场景下可以接受。原因在于不同用户对设备性能的需求和评判标准因使用场景而异。

趋势与预测

  • 新兴话题:随着提示尺寸增加,输入令牌与计算复杂度的二次关系可能会引发更多关于自注意力机制在速度影响方面的深入探讨。
  • 潜在影响:对于模型性能优化方面,可能会促使更多人关注prompt caching的应用,以及在分享模型速度数据时重视上下文长度的说明,从而影响相关领域在性能评估方面的标准和实践。

详细内容:

标题:《探讨提示词大小对处理速度的显著影响》

在 Reddit 上,一则题为“如何提示词大小显著影响速度”的帖子引发了热烈讨论。该帖详细介绍了使用 llama.cpp 与 Llama-3.1-8B-Instruct-q4_K_M 模型,在不同提示词大小的情况下,分别在 RTX-4090 和 M3 Max 上进行测试的结果,获得了众多关注和大量评论。

讨论焦点主要集中在提示词大小与处理速度的关系、不同硬件设备的性能差异以及优化方案等方面。有人指出,缓存服务器会对此有所帮助。比如有人说:“缓存服务器会在这方面帮到你。” 还有人提到,在分享诸如“我用 8B 模型每秒能得到 60.5 个令牌”这样的数据时,如果不明确上下文长度,这些数字是没有意义的。就像有人说:“没错,提示缓存能有所帮助,但我发这个就是想让大家知道,包括我自己在内,人们常常分享这样的数字,但不说明具体的上下文长度,这些数字是没意义的。”

有人认为,对于较大的模型,提示词大小的影响更显著。例如:“当然。它对较大的模型有更大的影响。人们声称在 70b 的 100ctx 上能达到 20t/s,但从不说明在聊天进一步深入时会发生什么。”

关于硬件设备的比较,有人提到使用 llama-bench 能获得更标准化的结果。并提供了相关链接:https://github.com/ggerganov/llama.cpp/blob/master/examples/llama-bench/README.md 。

有用户分享了个人经历,如“我每天都在我的 Mac 上使用 70b - q5_K_M 模型。对我来说,7tk/s 是非常可用的。我甚至能容忍 5tk/s!”

对于苹果系统在处理大提示词尺寸时的表现,看法不一。有人认为“Mac 在处理大提示词尺寸时非常糟糕”,也有人认为“如果你的主要用途是查询长文档,那么你得等一会儿才能得到第一个响应。但对于常规聊天,尤其是有上下文转换的情况,还不算太糟。”

在讨论中,关于不同硬件设备的性价比和适用场景也存在争议。有人觉得如果主要用于 AI ,Mac 不是最佳选择,而有人则认为根据个人需求和容忍度,Mac 也有其可用之处。

总之,这场讨论让我们更深入地了解了提示词大小与硬件性能之间的复杂关系,也让我们看到了不同用户在实际应用中的多样需求和体验。