原贴链接

大家好，

我最近在设置 Tabby API，以便利用双 3090 系统进行更快的推理，并认为我会在这里发布一些基准推理速度结果，供其他人参考。

我在推测性解码方面没有太多运气，张量并行对我来说似乎是时好时坏。我看到其他人报告了更好的结果，所以我打算发布一些数据并从其他在多 GPU 设置上运行推理的人那里获得反馈。

随着最近对 DRY 采样器支持的增加，我非常希望将 Tabby API 作为我的后端。然而，我还没有顺利地让推测性解码工作起来，而且我离其他人在这里分享的大约 2 倍的推理速度还差得很远。

以下所有推理数据均使用最新的 tabbyAPI 仓库（今天拉取）和 ExllamaV2 的 v0.2.2 版本。我在基于 Windows 的平台上，所有测试都启用了 fasttensors。双 3090 显卡运行在 PCIe 4.0 x8 上。

我在测试中使用了两种不同的模型和草稿模型组合：

  1. Mistral Large Instruct 2407 123B 2.75BPW 搭配 Mistral 7B Instruct v0.3 3BPW
  2. Qwen 2 72B Instruct 4BPW 搭配 Qwen 2 7B Instruct 3.5BPW

所有上下文缓存都在 Q4 上运行，除了 Qwen 2 7B Instruct 在 Q6 缓存上运行，因为该模型在 Q4 缓存上似乎有显著的退化。

使用 SillyTavern 作为前端，连续进行了五次生成，推理速度是从这五次中平均出来的。提示词在第一次生成时被摄取，并在随后的四次生成中被缓存。

完整的推理日志和 VRAM 使用数据可以在这里找到：https://pastebin.com/aC4fD3j8

模型基础张量并行推测性解码张量并行和推测性解码
Mistral Large 2407 2.75BPW14.38 t/s 平均13.06 t/s 平均10.94 t/s 平均-
Qwen 2 72B Instruct 4BPW13.45 t/s 平均14.98 t/s 平均8.79 t/s 平均15.15 t/s 平均

我无法为 Mistral Large 提供同时使用张量并行和推测性解码的数据，因为不幸的是我耗尽了 VRAM 并抛出了 OOM 错误。即使在 48GB 和 2.75BPW 的主模型下，似乎也有些勉强。

一些杂项一般说明：

  • 我最初在使用较旧版本的 tabbyAPI 时遇到了一些问题，尽管有剩余的 VRAM，但仍然抛出了 OOM 错误，并且偶尔似乎忽略了手动 GPU 分割。GitHub 上提出了类似的问题，启用 fasttensors 并使用 autosplit 似乎解决了这个问题。
  • 当使用张量并行时，我在推理期间看到 GPU_0 和 GPU_1 的 GPU 计算利用率一致为 65%。然而，这在任务管理器中没有准确反映（GPU_1 显示 0% 利用率）。我建议其他使用 Windows 的人通过 GPU-Z 或类似工具监控以查看准确的数据。
  • 运行张量并行似乎确实存在一些 VRAM 开销成本。例如，Mistral Large 2.75BPW 在禁用张量并行时总共加载 42.9GB，启用张量并行时为 43.8GB。

Mistral Large：

Mistral Large 似乎在使用张量并行时显示出一致的推理速度较慢，尽管它是更大的模型。

此外，当使用推测性解码时，速度进一步减慢。据我所知，Mistral 7B Instruct v0.3 与 Mistral Large 2407 共享一个分词器和词汇表（除了一些特殊标记），其他人报告了这种组合的成功。

当看到推测性解码速度减慢时，我会假设问题是接受率较低（即草稿模型经常预测错误的令牌 n，需要在主模型生成令牌 n+1 之前进行另一次前向传递）。据我所知，我无法在 Tabby API 中检查给定生成的接受率，因此我无法确认这确实是推理速度较慢的原因。

在这种情况下，我使用的较小量化可能会在令牌概率分布中产生太多不确定性。我知道较小的模型对量化的退化更敏感，但我看到其他人报告了在这种特定草稿模型下 3BPW 的成功结果。

Qwen 2 72B：

在 Qwen 的情况下，启用张量并行时推理速度有所增加。虽然很小（平均约 11.4%），但确实存在。

然而，推测性解码会导致推理速度大幅减慢。不仅主模型和草稿模型在这种情况下共享一个分词器，而且据我所知，它们的 config.json 显示它们具有相同的词汇量 152064。

这就是为什么我选择使用 Qwen 2 7B 而不是 0.5B，后者似乎有稍有不同的词汇量 151936。

在使用合理大小的量化用于主模型和草稿模型，并且有明显的兼容性时，我不确定是什么导致了如此大幅度的推理速度减慢。任何关于这方面的输入都将非常感谢，因为我在这里有点困惑。

有趣的是，启用张量并行和推测性解码会产生比基础更快的平均速度。仍然远未达到 2 倍的速度，但这是我第一次成功看到启用推测性解码时推理速度有所增加。

其他系统的参考速度、关于张量并行观察到的推理速度增加的讨论，或关于草稿模型选择和兼容性的输入将非常受欢迎。

特别是，使用推测性解码时推理速度的下降似乎不正常，任何关于可能导致这种情况的见解都将非常感谢。

非常感谢。

讨论总结

本次讨论主要围绕Tabby API在多GPU设置下的推理速度基准测试展开，重点关注张量并行（Tensor Parallel）和推测解码（Speculative Decoding）的效果。讨论者分享了在不同模型和配置下的测试数据，并讨论了这些技术在不同使用场景下的表现。特别是，他们发现推测解码在代码生成任务中表现出色，但在创意写作任务中则效果不佳。此外，讨论者还讨论了VRAM使用、GPU利用率和不同模型组合的影响。操作系统（如Windows和Linux）、NVLink的使用以及量化缓存设置也被认为是影响推理速度的关键因素。

主要观点

  1. 👍 张量并行在某些情况下可以提高推理速度，但并非总是有效

    • 支持理由：在某些模型和配置下，张量并行确实提高了推理速度，尤其是在Linux系统下。
    • 反对声音：在Windows系统下，张量并行可能会导致VRAM使用增加，且性能提升不明显。

  2. 🔥 推测解码在代码生成任务中表现优异，但在创意写作任务中效果不佳

    • 正方观点：推测解码在代码生成任务中显著提高了推理速度，尤其是在与张量并行结合时。
    • 反方观点：在创意写作任务中，推测解码反而降低了推理速度，可能与模型的量化缓存设置有关。

  3. 💡 VRAM的使用和分配对推理速度有显著影响

    • 解释：不同模型和配置下的VRAM使用情况不同，过高的VRAM使用可能导致OOM错误，影响推理速度。

  4. 💡 不同GPU之间的传输速率和利用率是影响多GPU设置性能的关键因素

    • 解释：NVLink的使用可以显著提高GPU之间的数据传输速度，从而提升推理速度。

  5. 💡 使用不同的模型组合和量化缓存设置可以显著影响推理速度

    • 解释：不同的模型组合和量化缓存设置会导致推理速度的显著差异，需要根据具体任务进行优化。

金句与有趣评论

  1. “😂 In my case, tensor parallel helps with mistral large. It’s faster than CR+ running regularly.”

    • 亮点：强调了张量并行在特定模型上的有效性。

  2. “🤔 Try switching to Ubuntu 22.4 from Windows, I had similar results.”

    • 亮点：建议切换操作系统以提高性能，反映了操作系统对推理速度的影响。

  3. “👀 nvlink gave me a few extra t/s on bitsnbytes.”

    • 亮点：强调了NVLink在提高推理速度方面的作用。

情感分析

讨论的总体情感倾向较为积极，讨论者们分享了各自的测试结果和经验，并寻求进一步的优化建议。主要分歧点在于不同操作系统、硬件配置和模型组合对推理速度的影响。可能的原因包括操作系统对GPU资源的管理方式、硬件之间的数据传输效率以及模型本身的特性。

趋势与预测

  • 新兴话题：操作系统对推理速度的影响，特别是Linux与Windows的对比。
  • 潜在影响：随着多GPU设置的普及，操作系统优化和硬件配置（如NVLink）将成为推理速度优化的关键因素，可能引发更多关于如何最大化硬件性能的讨论。

详细内容：

标题：关于 Tabby API 中推理速度基准的热门讨论

最近，Reddit 上有一篇关于在 Tabby API 中设置 2 x 3090 系统以实现更快推理，并分享基准推理速度结果的帖子引起了广泛关注。该帖子获得了众多用户的参与，评论数众多。

原帖主要介绍了作者在使用 Tabby API 时对张量并行（Tensor Parallel）和推测解码（Speculative Decoding）的测试结果。作者在 Windows 平台上进行了一系列实验，并提供了详细的数据和分析。然而，作者在某些情况下遇到了问题，如内存不足（OOM）错误，以及在使用推测解码时推理速度不如预期等。

帖子引发的主要讨论方向包括不同用户在各自环境中使用这些技术的经验和效果，以及对推理速度差异原因的探讨。

文章将要探讨的核心问题是：为什么在某些情况下，张量并行和推测解码未能达到预期的推理速度提升效果，以及不同使用场景和硬件配置对其性能的影响。

在讨论中，有人分享道：“在我的情况中，张量并行对 Mistral Large 有帮助。它比常规的 CR+运行速度更快。”还有人表示：“张量并行对我来说没有快太多，但它使用的 VRAM 更少，所以我可以容纳更多的上下文。”

对于 Qwen 2 模型，有用户指出：“在 Qwen 的情况下，启用张量并行时推理速度有所增加。虽然幅度较小，但确实存在。然而，推测解码导致推理速度大幅下降。”

有用户在 3 x 3090 的配置下，使用 Exllama TP 能够将推理速度从 10 - 12t/s 提升到 18 - 20t/s。

关于操作系统的影响，有人提到从 Windows 切换到 Ubuntu 22.4 后，张量并行的效果更好，甚至 Ollama 的速度也有所提升。但也有人提出疑问，为什么在考虑系统开销后，在 Linux 上会天生运行得更快。

在讨论中的共识是，使用场景似乎是决定推理速度提升效果的关键因素，在更具确定性的任务（如编码）中，这些技术的表现往往更好。

特别有见地的观点如：“推测解码在单独使用时似乎只提供了微小的提升，只有与张量并行结合使用时才会产生更高的推理速度。”

总之，通过这次热烈的讨论，我们对 Tabby API 中的推理速度优化有了更深入的了解，但仍有许多问题需要进一步探索和解决。