电子产品世界

为了展示基于 Arm 平台的服务器 CPU 在 LLM 推理方面的能力，Arm 软件团队和我们的合作伙伴对 llama.cpp 中实现的 int4 和 int8 内核进行了优化，以利用这些较新的指令 ^[3] 。我们在 AWS Graviton3 平台上进行了多次实验，以测量不同场景下对性能的影响，并将影响因素隔离开。

所有实验均在 AWS r7g.16xlarge 实例上进行，该实例带有 64 个虚拟 CPU (vCPU) 和 512 GB 的内存。所用的模型是经过 int4 量化的 Llama3-8B。

提示词词元 (Token) 通常是并行处理的，即使对于单次操作 (batch=1)，也会使用所有可用核心。在这方面，经过 Arm 优化，每秒处理的词元数提升了 2.5 倍；在处理更大的批次大小时，性能小幅提升。

词元生成以自回归的方式进行，对于所需生成的输出长度高度敏感。在这方面，经过 Arm 优化，吞吐量最多可提高两倍，有助于处理更大的批次大小。

词元生成的延迟对 LLM 的交互式部署非常重要。对于下个词元响应时间 (time-to-next-token)，100ms 的延迟是关键的目标指标，这是基于人们每秒 5-10 个单词的典型阅读速度计算得出的。在下方图表中，我们看到在单次操作和批量处理的场景下，AWS Graviton3 都能满足 100ms 的延迟要求，因此适合于作为 LLM 的部署目标。

我们使用了两组不同的模型 Llama3-8B 和 Phi-3-mini (3.8B)，以展示不同规模的 LLM 的延迟情况。

即使是在 2019 年推出的 AWS Graviton2 这样的上一代 Arm 服务器平台上，也能运行多达 80 亿参数的新 LLM，并且在单次操作和批量处理的场景下，均能满足 100ms 的延迟要求。

此外，我们使用经过 int4 量化的 Llama3-8B 模型，比较了它在 AWS Graviton3 与在 AWS 上其他新一代服务器 CPU 的性能。

我们发现，相较于其他两款 CPU，在提示词处理和词元生成方面，AWS Graviton3 的性能高出三倍。

同样值得注意的是，AWS Graviton3 CPU 比第四代 x86 CPU 更具成本效益，这在 Graviton3 实例相对较低的定价中就有所体现。鉴于 LLM 对算力的要求已经非常高，以单位价格词元数量来计算总体拥有成本 (TCO)，是推动 LLM 在数据中心内广泛采用的关键。

在这一点上，AWS Graviton3 拥有显著优势，每美元词元数量最高多了三倍，不仅在 CPU 中处于领先，也为希望在采用 LLM 的过程中逐步扩大规模的用户提供了令人信服的优势。

当开发者想要在其应用中部署专用 LLM 时，服务器 CPU 为开发者提供了灵活、经济和简化的起点。Arm 新增了几项关键特性，有助于显著提升 LLM 的性能。得益于此，基于 Arm Neoverse 的服务器处理器（如 AWS Graviton3）不仅能提供优于其他服务器 CPU 的 LLM 性能，还能为更多应用开发者降低采用 LLM 的门槛。