原贴链接

你能分享一下你的硬件、模型以及性能数据，如TPS和TTFT吗？

讨论总结

本次讨论主要围绕CPU在推理任务中的性能表现展开，重点关注内存带宽、量化技术和模型大小对推理速度的影响。讨论中，参与者分享了各自的硬件配置、模型类型和性能数据，比较了CPU和GPU在推理速度上的差异。主要观点包括内存带宽是CPU推理的主要瓶颈，量化技术对推理速度的影响，以及不同模型大小在CPU上的推理速度。此外，讨论还涉及了CPU推理的实用性，特别是在低功耗硬件和服务器上的应用。总体而言，讨论氛围较为技术性，参与者提供了丰富的实际案例和数据支持。

主要观点

  1. 👍 内存带宽是CPU推理的主要瓶颈，而不是计算能力。

    • 支持理由：多个评论者指出，内存带宽限制了CPU在推理任务中的性能表现，尤其是在处理大模型时。
    • 反对声音：有评论提到，计算能力在某些情况下也对推理速度有帮助。

  2. 🔥 量化技术在某些情况下可能会降低推理速度，但在其他情况下可以提高速度。

    • 正方观点：一些评论者认为，适当的量化技术可以提高推理速度，尤其是在GPU上。
    • 反方观点：另一些评论者指出，某些量化方法可能会降低推理速度，特别是在CPU上。

  3. 💡 CPU推理的实用性取决于用户的需求和期望。

    • 解释：讨论中提到，CPU推理在处理适量请求时是可行的，但在请求过多时可能会变得不切实际。

  4. 🚀 使用GPU进行上下文处理（预填充）可以显著增加上下文大小。

    • 解释：有评论者提到，通过GPU加速上下文处理，可以显著提高推理速度和上下文大小。

  5. 🌟 在主流双通道DDR5平台上，CPU推理性能受限于较小的7-8-9B模型。

    • 解释：讨论中提到，为了在CPU上获得合理的性能，只能使用较小的模型，而在GPU上则可以处理更大的模型。

金句与有趣评论

  1. “😂 M34L：内存带宽是CPU推理的主要瓶颈，而不是计算能力。”

    • 亮点：这一观点被多次提及，成为讨论的核心。

  2. “🤔 Theio666：在某些情况下，量化技术反而会降低推理速度。”

    • 亮点：这一观点引发了关于量化技术对推理速度影响的深入讨论。

  3. “👀 Downtown-Case-1755：LLMs不完全受限于内存带宽，计算能力在某些情况下也有帮助。”

    • 亮点：这一观点提供了对CPU推理性能的另一种解释。

  4. “🚀 henfiber：Adding a GPU only for context processing (prefill) which is compute-bound, allows you to increase the context size 10x or so.”

    • 亮点：这一观点展示了GPU在提高推理速度和上下文大小方面的优势。

  5. “🌟 tmvr：A good case for CPU inference is probably something like Mixtral8x7B where the full model needs about 50GB RAM at Q8, but the active inference is only using the 7B portions so you get decent speed.”

    • 亮点：这一观点提供了一个实际案例，展示了CPU在特定模型上的推理性能。

情感分析

讨论的总体情感倾向较为中性，主要集中在技术层面的讨论和数据分享。主要分歧点在于内存带宽和计算能力在CPU推理中的相对重要性，以及量化技术对推理速度的影响。这些分歧可能源于不同的硬件配置和模型类型，导致参与者对CPU推理的性能有不同的体验和看法。

趋势与预测

  • 新兴话题：量化技术在CPU推理中的应用和优化可能会引发后续讨论。
  • 潜在影响：随着硬件技术的进步，CPU和GPU在推理任务中的性能对比可能会发生变化，特别是在低功耗硬件和服务器上的应用。

详细内容：

标题：关于 CPU 和 GPU 推理性能的热门讨论

在 Reddit 上，一则题为“Compared to GPUs, What kind of TPS performance have you seen on CPUs? Is CPU inference practical?”的帖子引发了广泛关注，获得了众多点赞和大量评论。原帖主要探讨了 CPU 推理的性能表现，还希望大家能分享硬件、模型以及诸如每秒处理事务数（TPS）和首次令牌时间（TTFT）等性能数据。

这一话题引发了多方面的讨论。有人指出，对于大型语言模型（LLM）推理，瓶颈普遍由内存带宽而非计算能力主导，吞吐量与内存带宽大致成正比，与模型的活动参数大小也成正比。7 - 13b 模型在配备典型 DDR5 双通道内存的 CPU 上速度大致接近人类写作速度，而 70b 模型则可能需要等待数秒才能处理每个令牌。还有用户提到，在某些情况下量化会使速度变慢，比如在 PyTorch 中使用 bnb 8 位量化时推理速度比全 fp16 慢了 3 倍多。也有人表示，计算能力在去量化等部分有一定帮助，随着上下文变长效果会更显著。有人分享了一些关于 CPU 优化量化的链接，如 https://github.com/ggerganov/llama.cpp/blob/d39e26741f9f02340651dbc640c9776e1a1128ef/examples/quantize/README.md?plain=1#L57 等。

有人在 GPU 上进行推理，所以对 CPU 相关的优化不感兴趣。还有人在树莓派 4 8GB 上运行 6B IQ4_XS 模型，能达到 0.75 TPS。有人认为，与强调 GPU 的 AI 训练服务器相比，CPU 推理是实用的，但处理过多请求时可能不实用。有人通过自己的研究给出了大致的估计：对于高端 16 核/DDR5 主流 CPU，7b 模型在约 300 字的上下文中是实用的；对于 96 核 12 通道 DDR5 EPYCs，30b 模型在约 300 字的上下文中是实用的。

讨论中的共识在于，CPU 推理在一定程度上是可行的，但性能会受到诸多因素的限制。特别有见地的观点是，将 GPU 用于计算密集型的上下文处理，可以提高性能。但关于 CPU 推理是否真正实用，仍存在争议，取决于具体的应用场景和需求。