[Deep Research-3]：讨论一下大模型推理性能吧，再让o3做个“事实核查”

[Deep Research-3]：讨论一下大模型推理性能吧，再让o3做个“事实核查”

中文 (Chinese) English

对于绝大多数企业和人而言，本地部署应该是一个为期一周的“从开始到放弃”的过程，性能优化和本地数据是最重要的两个核心。

今天这篇研究报告交给OpenAI写：大模型推理性能。

我本来是让GPT-4o直接翻译成中文的，但是那个输出惨不忍睹，只能交给Gemini 2.0-Flash了（怎能不爱上任劳任怨勤勤恳恳的Gemini，但是公众号不支持Markdown，我也不准备一行行调整了，找时间自动化一下输出吧）。

实际输出格式是下面这样的。

LLM 推理基准测试概述 (2024)

大型语言模型 (LLM) 推理性能差异很大，具体取决于模型大小以及使用的硬件和软件优化。下面，我们将比较模型和硬件类别，讨论并发扩展，并检查特定用例。我们重点介绍了最近（2024 年）的基准测试结果，包括 MLPerf 提交和行业报告，并提供了对不同方法的成本效益的见解。所有数据和声明均由可靠来源（学术研究、MLPerf 结果和供应商报告）支持。

1. 模型范围：各种 LLM 和大小

模型范围： 推理基准测试现在涵盖了专有模型（如 OpenAI 的 GPT-4）和开源模型（Meta 的 Llama 2、TII 的 Falcon、Mistral AI 的 Mistral-7B 等）。这些模型的范围从相对较小的 70 亿参数 LLM 到巨大的 700 亿+ 甚至 1000 亿+ 参数模型：

  • 开放与封闭模型： 开源 LLM（Llama 2、Falcon、Mistral 等）通常用于公共基准测试，因为它们的权重可用于测试。例如，MLCommons 在其 2024 年推理基准测试套件中添加了 Llama 2-70B 作为代表性的“大型”LLM。相比之下，像 GPT-4 这样的专有模型没有公开进行基准测试，但由于它们的规模（据传 GPT-4 超过 1000 亿参数或使用 MoE 技术），它们的推理可能需要高端 GPU 集群。
  • 不同系列： 基准测试包括通用聊天模型（例如 GPT 系列、Llama 2-Chat）、代码专业模型（OpenAI Codex、StarCoder）以及其他模型，如 Qwen（阿里巴巴的模型）。每个模型可能都有独特的架构（例如，某些模型中的 Mixture-of-Experts），这会影响推理效率。

模型大小与性能： 较大的模型通常以较慢的推理和更大的内存使用为代价提供更高的准确性：

  • 小型 (7B-13B)： 这些模型通常可以在单个 GPU 上运行并实现更高的令牌生成吞吐量。例如，一个 7-8B 的模型通常可以容纳在 ~16-24 GB 的内存中，并且每个令牌的延迟比 70B 模型低得多。
  • 中型 (13B-30B)： 中型模型平衡了质量和速度。像 Llama 2-13B 这样的 13B 模型可能需要大约 26 GB 的 FP16（或使用 8 位量化时更少），并且在同一 GPU 上生成文本的速度大约是 70B 模型的两倍。
  • 大型 (65B-70B+)： 70B+ 范围内的模型推动了内存和计算的极限。Llama 2-70B 在 FP16 中消耗 ~140 GB 的内存，这意味着如果不跨多个 GPU 分片或使用较低的精度，它甚至无法在单个 40 GB GPU 上运行。

2. 硬件范围：GPU 与 TPU 与加速器与 CPU

推理性能高度依赖于硬件功能。

  • NVIDIA GPU (A100, H100)： H100 (80 GB) 是目前的旗舰产品，由于架构改进和 FP8 支持，它提供了更高的吞吐量。在一项基准测试中，与 A100 相比，H100 在 7B 模型上实现了 ~2 倍更高的每秒令牌数。
  • AMD GPU (MI300X)： MI300X 是 AMD 对 H100 的回应，具有 192 GB 的 HBM3 内存，非常有利于在不分割的情况下托管 70B+ 模型。
  • Google TPU (v4, v5e)： TPU v5e 是面向训练和推理的成本优化版本，与 TPU v4 相比，它提供高达 2.5 倍的每美元推理性能。
  • AI 加速器 (AWS Inferentia2, Habana Gaudi2)： 这些专用芯片侧重于性价比。Inferentia2 的每个令牌成本比 GPU 实例好约 44.7%。
  • 高性能 CPU： 虽然速度较慢，但现代 CPU（如 Intel Xeon）可以通过 4 位量化运行较小的模型。

3. 并发和扩展性能

LLM 推理不仅关系到单流吞吐量；并发、批处理和分布式扩展是关键。增加批量大小通常会提高总吞吐量，但也会增加每个请求的延迟。使用 vLLM 等引擎通过“连续批处理”算法显著提高了多用户吞吐量。

4. 用例性能注意事项

  • 聊天机器人： 优先考虑低延迟和流式输出（到达第一个令牌的时间）。
  • 代码生成： 涉及长上下文（提示长度），受益于 FlashAttention。
  • RAG (检索增强生成)： 将检索延迟与 LLM 生成延迟相结合，通常允许使用较小的模型。

5. 最新基准和趋势 (2024)

  • 量化： 转向 FP8 和 INT8/INT4 已成为加速推理的标准。
  • 更长的上下文： 处理 32k+ 令牌对内存带宽提出了更高要求。
  • 专家混合 (MoE)： 如 Mixtral-8x7B，在推理期间仅激活部分参数，比同等规模的密集模型更快。

来源： MLPerf v4.0/4.1, NVIDIA, AMD, AWS, Google Cloud, Argonne National Lab (2024).

有兴趣还是应该看英文原版。

读完这些，我觉得意犹未尽，让 o3-mini-high 动用它的搜索功能，做了一次“事实核查”，结果如下：

以下是对文章“LLM 推理基准测试：综合分析”的详细分析，包括对其关键声明的事实核查和对所引用参考文献的评估。

技术声明核查：

  1. 硬件性能差异：文章关于小型模型在 CPU 上运行而大型模型需要加速器的说法是准确的。
  2. 吞吐量与延迟指标：文中提到的 TTFT 和令牌/秒的数据在行业标准范围内（如 RTX 4090 的 95 tok/s）。
  3. 框架比较：对 vLLM 与 TensorRT-LLM 性能优势的看法与 FriendliAI 和各开源项目的测试结果一致。

参考文献评估： 引用的 23 篇文献涵盖了 arXiv 学术论文、顶级行业博客（Oracle, NVIDIA, Dell）和开发者社区（GitHub, Reddit），信息来源可靠且多元化。

我不贪心，这样的报告，每天产出一篇即可。

← Back to Blog