首页 / 文章 / 超越GPU：Inferentia2、TPU、Groq LPU和Tenstorrent在LLM服务中的实际差异

IT技术

超越GPU：Inferentia2、TPU、Groq LPU和Tenstorrent在LLM服务中的实际差异

✍️ zhirenhun 📅 2026/8/10 👁 201 阅读 ⏱ 57 分钟

如果您在生产环境中运行LLM推理，您现在拥有的硬件选择比以往更多。NVIDIA和AMD GPU仍然是默认选择，但它们并非唯一选择。AWS销售Inferentia2。Google出租TPU。Groq制造了一款专用于推理的芯片。Tenstorrent正在研发另一款。每款专用芯片在某一方面都比GPU更好。

大多数文章把这当作速度竞赛：谁每秒生成的token最多。如果您真正运行一个服务栈，这就没有抓住重点。基准测试中最快的芯片，如果您的p99延迟剧烈波动，或者您每周发布一个新模型，或者您的流量与芯片的设计目标不匹配，那么它仍然可能是错误的选择。

本文为选择专用推理硬件的团队描绘了格局。对于每款芯片，它都涵盖了其擅长的方面、为此需要放弃的东西，以及专用芯片何时真正胜过GPU。简短答案先放在前面：对大多数团队而言，GPU服务胜出是因为其灵活性。DigitalOcean在GPU Droplets上使用NVIDIA H100和H200以及AMD MI300X和MI325X运行推理，因此这一观点来自运行这些工作负载的经验，而不仅仅是阅读规格表。

摘要

四大芯片家族，四种权衡。GPU以峰值效率换取灵活性。固定功能加速器（Inferentia2、TPU）以灵活性换取单个固定模型上更低的每token成本。Groq的LPU以容量换取可预测的延迟。Tenstorrent是较早阶段的数据流选项。
大多数团队需要GPU的灵活性。无需重新编译即可更换模型、更改精度和调整批处理。专用芯片会让您为这些更改中的每一项再次付出代价。
Groq在可预测延迟方面胜出。其固定调度使p50和p99保持接近，这对于实时、单请求工作负载非常重要。
Inferentia2和TPU在高负载下针对单一固定模型赢得每token成本优势。问题是：每次更改模型、精度或形状时都必须重新编译。
决定服务上限的是内存，而不是FLOPS。容量限制模型大小，带宽限制速度。下面纠正了两个常被引用的错误数字。

本文使用的术语表

如果您不熟悉推理硬件，可以先参考下面的表格。它定义了文章中使用的术语。

核心推理概念

术语	含义
LLM推理	运行训练好的语言模型来回答实时用户请求。训练更新模型；推理只使用它。示例：聊天机器人回复客户消息。
专用推理	您为自己的应用单独租用或拥有私有芯片（GPU或专用加速器）。您为GPU时间或硬件付费，而不是按共享API上的token付费。
服务栈	用户提示词与流式答案之间的所有环节：负载均衡器、模型服务器（如vLLM）、GPU/芯片、网络和监控。
Token	模型读取或写入的一段文本，通常是一个单词、单词的一部分或标点符号。计费和速度报价（token/秒）基于token。
吞吐量	每秒产生的总输出。如果您的服务器在所有用户中每秒生成500个token，这就是您的吞吐量。更高的吞吐量意味着在相同硬件成本下每秒能提供更多答案。
每token成本	花费的美元 ÷ 生成的token数。每token成本更低的芯片在高负载下更便宜，但前提是您的模型和流量与芯片的设计目标匹配。
批次大小	服务器在一次GPU处理中同时处理的请求数量。批次大小为8意味着一次有8个提示词通过芯片运行。更大的批次能更高效地利用芯片，但可能让单个用户在队列中等待更长时间。
单流服务	一次只服务一个请求并设定严格的速率目标。示例：语音助手必须在300毫秒内响应，且不允许有批处理延迟。
批量推理	离线运行大量提示词，没有实时用户等待。示例：一夜之间总结10万张支持工单；您优化的是总成本，而不是每个请求的速度。

延迟与可靠性

术语	含义
延迟	从发送提示词到收到完整（或首个）答案的挂钟时间。如果用户等待800毫秒，这就是他们感受到的延迟。
p50（中位延迟）	按速度对所有请求排序；p50是中间值。如果p50 = 200毫秒，则一半请求快于200毫秒，一半慢于200毫秒。它描述的是典型请求，而不是最差请求。
p99延迟	按速度对所有请求排序；p99是只有最慢的1%才会超过的时间。如果p99 = 2秒而p50 = 200毫秒，大多数用户没有问题，但百分之一的用户会得到明显缓慢的响应，这就是破坏聊天体验和SLA的原因。
p999延迟	与p99类似，但针对最慢的0.1%（千分之一）。用于即使是罕见的缓慢响应也不可接受的情况（例如交易或安全关键系统）。
尾部延迟	分布中较慢的一端，即异常请求，而不是平均值。GPU的p50可能为150毫秒，p99为1.5秒；尾部就是这一差距。
SLA（服务等级协议）	关于性能或正常运行时间的合同或内部目标。例如：“p99延迟必须保持在500毫秒以下”或“99.9%正常运行时间”。未达到SLA，您就违反了客户承诺或触发内部警报。
确定性延迟	相同的输入形状 → 每次的延迟几乎相同，因为芯片的调度在运行前就已固定。Groq的目标就是如此：p50和p99非常接近。
统计性延迟	延迟因请求而异，因为芯片在运行时决定调度并在并发用户之间共享资源。GPU在混合负载下很典型：p50看起来不错，p99可能飙升。

芯片家族和产品

术语	含义
GPU（图形处理单元）	一种灵活的加速器，可运行多种模型类型和设置。您可以在不重新编译的情况下更改模型、精度（FP16、INT8）和批处理大小。本文中指的是：NVIDIA H100/H200 和 AMD MI300X/MI325X。可以把它想象成一个通用厨房，无需重建灶台就能烹饪许多菜肴。
通用 GPU	与本文中的 GPU 相同，是所有其他对比的基线。
Inferentia2	AWS 专为推理而构建的芯片。当单个模型以巨大规模不变运行时效果最佳：每个 token 成本低。提供推理服务前，必须使用 AWS Neuron 编译模型；当模型或输入大小发生变化时，需重新编译。
TPU（张量处理单元）	Google 的自定义 AI 芯片，可在 Google Cloud 上租用。处于服务模式的 TPU v5e 与 Inferentia2 类似：每个模型/形状只需编译一次，以大规模低成本提供服务，但灵活性不如 GPU。
Groq LPU（语言处理单元）	Groq 的纯推理芯片。权重存放在极快的片上内存中；每个操作都预先调度。结果是：延迟非常可预测，但每颗芯片的内存很小，因此大型模型需要多颗芯片。
Tenstorrent	一家构建数据流式 AI 芯片的厂商。此处仅作简要介绍，因为其生产级服务规格和软件不如 GPU、Inferentia2、TPU 或 Groq 成熟。
固定功能加速器	针对单一狭窄任务优化的硬件，通常是在特定输入大小下编译好的一个模型。就像一个单一用途的家电：对该任务非常高效，但需求变化时就很笨拙。Inferentia2 和 TPU v5e 就是例子。
数据流芯片	数据通过一条固定的专用单元链流动（不像 GPU 上运行的通用程序）。Tenstorrent 采用这种方法。
H100 / H200	NVIDIA 数据中心 GPU，常用于 LLM 推理服务。H200 与 H100 拥有相同的计算能力，但内存更大、速度更快（141 GB 对 80 GB），仅这一点就让它在大型模型推理中更快。
MI300X / MI325X	AMD 的数据中心 GPU，在本对比中是 NVIDIA 的 GPU 替代方案。MI325X 比 MI300X（192 GB）增加了更多内存（256 GB HBM3E）。
Hopper	NVIDIA 针对 H100 和 H200 的架构代次。“Hopper GPU” = H100/H200 级别。
Blackwell	NVIDIA 在 Hopper 之后的下一代架构（后续引用的 MLPerf 结果中较新的 GPU）。
张量流处理器（TSP）	Groq 对 LPU 内部芯片设计的内部名称，也就是 Groq 的 ISCA 论文中所描述的硬件。

编译、软件和灵活性

术语	含义
编译步骤 / 编译	将你的模型（PyTorch/ONNX 等）转换为芯片能够原生运行的程序。在 Inferentia2 上使用 Neuron；在 TPU 上使用 XLA。根据模型大小，需要几分钟到几小时。当模型、精度或输入尺寸发生变化时，你需要重新编译，这不是一次性设置。
Neuron / AWS Neuron SDK	AWS 用于在 Inferentia 芯片上编译和运行模型的工具链。如果 Neuron 不支持你模型中的某个操作，编译将失败或运行一个缓慢的备用方案。
XLA	Google 的编译器，将模型转换为可供 TPU 运行的程序（属于 OpenXLA 项目的一部分）。与 Neuron 一样，具有每个形状只能编译一次的限制。
热切换	无需重新编译即可加载新的模型权重并开始提供服务。在 GPU 上：将服务器指向新的检查点并重启，或在几秒钟内完成切换。在 Inferentia2/TPU 上：通常需要完全重新编译。
连续批处理	当新请求到达时，服务器将它们添加到当前 GPU 批次中，并移除已完成的请求，批处理大小每毫秒都在变化。在流量多变的情况下保持 GPU 忙碌。vLLM 和类似服务器在 GPU 上实现这一点。
静态调度	Groq 的编译器在任何请求到达之前精确决定每个操作的运行时间，包括芯片之间的通信流量。时序可预测，但在批处理大小从 1 变化到 64 时，调度难以轻松适应。
算子	模型图中的一个步骤，例如“多头注意力”、“矩阵乘法”、“SiLU 激活”。编译器必须全速实现你模型所使用的每个算子。
算子覆盖率	编译器/芯片原生支持的算子列表。缺少算子 = 编译失败，或一个缓慢的 CPU 备用方案，这会抵消芯片的速度优势。务必根据你自己的模型检查覆盖率，而不是厂商的演示模型。

内存、数学，以及为什么生成感觉“慢”

术语	含义
FLOPS / FLOPs	芯片在峰值状态下每秒能执行的浮点数学运算次数（规格表数字）。高 FLOPS 听起来很厉害，但词元生成往往等待的是内存读取而非数学运算，因此仅看 FLOPS 会产生误导。
内存带宽	芯片从内存读取数据的速度，单位为 GB/s 或 TB/s。例如：H100 约 3.35 TB/s。词元生成会对每个新词元重新读取全部模型权重，因此带宽往往比 FLOPS 更早成为速度上限。
内存容量	芯片一次能容纳多少数据（例如 H100 80 GB，Groq 每芯片 220 MiB）。如果权重放不下，就需要将模型拆分到多块芯片上，或量化到更低的精度。
HBM（高带宽内存）	堆叠在 GPU 封装上的大容量内存（H100：80 GB；H200：141 GB）。容量远大于 Groq 的片上 SRAM，但访问速度仍比 SRAM 慢。
SRAM	位于芯片裸片上的小型极速内存。Groq 将权重存储在 SRAM 中（每芯片 220 MiB），读取速度非常快，但 70B 模型无法容纳在单块芯片上。
KV 缓存	在生成过程中，模型会存储过往的注意力键和值，这样每个词元就不必重新计算整个提示词。它随对话长度增长。上下文越多 = KV 缓存内存读取越多 = 每个词元生成越慢、成本越高。
预填充 / 提示词处理	阶段 1：模型在一次（或少数几次）并行扫描中读取完整的用户提示词。计算密集，芯片的计算单元保持忙碌。每个请求在输出任何词元之前执行一次。
解码 / 词元生成	阶段 2：模型一次输出一个词元。每一步都从内存重新读取所有模型权重。内存密集，这通常是生成比“思考”提示词感觉更慢的原因。
自回归生成	模型先生成词元 1，然后使用词元 1 生成词元 2，再用 1+2 生成词元 3，依此类推。无法跳过；每个词元都依赖于所有之前的词元。
算术强度	比值：完成的数学运算 ÷ 从内存读取的字节数。低（词元解码）：芯片等待内存 → 内存受限。高（预填充）：芯片保持计算忙碌 → 计算受限。同一块芯片，两个阶段，两种瓶颈。
Roofline 模型	工程师用来回答“这一步受限于数学速度还是内存速度？”的简单图表。解释了为什么预填充和解码在同一硬件上表现不同。
内存受限	芯片空闲等待来自内存的数据。LLM 的词元解码通常是内存受限的，在增加带宽或缩小模型之前，增加 FLOPS 无济于事。
计算受限	芯片的数学单元完全忙碌；内存跟得上。长提示词的预填充通常是计算受限的。
MiB / GB / TB/s	MiB/GB = 能容纳多少（模型大小）。TB/s = 数据移动多快（服务速度）。示例：70B 模型 FP16 精度下权重约 140 GB；在 3.35 TB/s 带宽下，读取一次权重约需 42 毫秒，这就是每个词元的理论下限。

模型大小、精度与量化

术语	含义
参数 / 70B 模型	每个参数都是一个学习到的数字（权重）。70B = 700 亿个这样的数字。参数量越大 = 模型越大 = 需要更多内存，通常回答也更聪明，但服务速度更慢、成本更高。
权重	模型在训练期间学到的所有数字，也就是你加载到内存中用于服务的“大脑”。70B 模型的权重必须能放入你的芯片中，或者拆分到多块芯片上。
FP16 / BF16	16 位数字格式（每个权重约 2 字节）。许多 LLM 部署的默认格式。70B 模型在 FP16 下约为 140 GB。
FP8	8 位浮点数（每个权重约 1 字节）。内存占用为 FP16 的一半，精度略有折衷。H100/H200 及部分加速器支持。
INT8 / INT4	整数格式（每个权重 1 字节或约 0.5 字节）。量化后使用。70B 模型在 INT8 下约为 70 GB，INT4 下约为 35 GB，可放入较小的 GPU。
量化	将权重从 FP16 缩小到 INT8/INT4（或 FP8），使模型占用更少内存、运行更快。权衡：某些任务上可能有质量损失，务必在你的数据上评估。
GPTQ / AWQ	两种流行的开源方法，用于在 GPU 上将模型压缩到 INT4。让你可以在 80 GB GPU 上运行 FP16 下装不下的 70B 模型。
TruePoint（Groq）	Groq 在 LPU 上的混合精度数学格式，即 Groq 在其芯片上表示权重和激活的方式。
cFP8（Inferentia2）	AWS 在 Inferentia2 上的可配置 FP8 格式，介于 FP16 体积和 INT8 压缩之间的中间方案。
TOPS	每秒万亿次整数运算，厂商提供的 INT8 吞吐量规格（类似 FLOPS，但针对整数运算）。用于比较加速器在量化模型上的表现。
输入形状	编译后模型期望的确切序列长度和批量大小，例如“batch 1, sequence 2048”。将 512 词元的提示词发送给为 2048 编译的模型，编译器会用零填充其余部分。
填充	将短请求填充到最近的编译大小。填充的词元同样消耗计算资源，这会体现为浪费的工作量以及 Inferentia2/TPU 上的 p99 延迟尖峰。

跨芯片扩展

术语	含义
张量并行	将一个模型的层拆分到多个GPU上，使每个芯片持有一部分并并行计算。示例：一半层在GPU 0上，一半在GPU 1上，两者同时处理同一个请求。
分片	将模型权重拆分成多个部分，分布到许多芯片上。当单个芯片无法容纳整个模型时需要这样做，Groq需要数百个芯片来运行70B模型，因为每个芯片只有220 MiB。
NVLink / NVSwitch	NVIDIA的高速线缆/芯片，用于连接服务器内的GPU（H100上为900 GB/s）。使张量并行的GPU能够快速交换数据，而无需经过慢速的PCIe。
NeuronLink	AWS在Inf2实例中连接Inferentia2芯片的链路（192 GB/s）。当模型跨越多个Inferentia芯片时使用。
二维环形拓扑	TPU pod中的网格布线模式，每个芯片连接到网格中的相邻芯片。Google用这种方式将TPU扩展到每个pod 256个芯片。
互连	任何将芯片连接在一起的网络。慢速互连意味着GPU相互等待，也意味着增加芯片时无法获得线性加速。
Pod (TPU)	一个大型有线连接的TPU集群（v5e中最多256个芯片）。你可以根据模型大小租用切片（例如8个芯片）或整个pod。

基准测试与优化技术

术语	含义
MLPerf推理	一种行业基准测试套件，具有固定规则和第三方审计。供应商提交硬件配置和分数，适用于在相同基准测试上比较GPU/TPU，而不是跨不同基准测试。
Artificial Analysis	一家独立公司，测量各云提供商的实时LLM API速度和价格。本文使用其数据来获取Groq在Llama模型上的吞吐量数字。
推测解码	一个小型的“草稿”模型快速猜测多个token；大型模型一次性验证它们。如果猜测正确，每个大型模型步骤可以输出多个token，通常生成速度快2-3倍。
A/B测试	将模型版本A用于50%的流量，版本B用于50%的流量，以比较质量或成本。在GPU上容易（热交换权重）；在编译芯片上麻烦（需要重新编译两个版本）。

文章范围与方法论

本文使用已发布的供应商规格和公开架构论文来比较芯片架构。每个硬件数字都链接到其来源。这些不是DigitalOcean的基准测试结果。当某个论断涉及设计原理而非我们在生产中实际测量的内容时，文中会明确说明。

最近有一件事值得注意。2025年12月24日，NVIDIA许可了Groq的推理技术（据报道约200亿美元），聘用了Groq的创始人及几位高级员工，并保持该协议为非排他性。Groq仍在新领导下自行运营GroqCloud。来源：Groq新闻室。这笔交易表明，即使是最大的GPU制造商，可预测的片上内存推理也至关重要。但它并未改变下文中的权衡取舍。

推理芯片分类法

首先介绍四种芯片类别。每一类都针对不同的方面进行了优化。

推理芯片的四个家族：通用GPU、专用功能加速器、确定性LPU和数据流，每一个都有其押注的方向和付出的代价。 四种芯片家族，四种不同的权衡。GPU是灵活的基线，其他一切都以它为衡量标准。

通用GPU。 NVIDIA H100和H200、AMD MI300X和MI325X。加载模型即可提供服务，无需编译步骤。可以随着流量变化更换模型、更改精度、调整批处理。这就是灵活的基线。其他所有选项都牺牲部分这种灵活性以换取特定的收益。

专用功能加速器。 服务模式下的AWS Inferentia2和Google Cloud TPU v5e。它们旨在以低成本大规模运行一个固定模型。两者都需要一个编译步骤，将你的模型转换为芯片特定的代码。Inferentia2使用AWS Neuron SDK，TPU使用XLA。性能在很大程度上取决于你为编译准备的输入形状。

确定性低延迟芯片。 Groq LPU（语言处理单元）。它将模型权重存储在快速的片上内存中，并提前安排每个操作，因此每个请求占用相同的时钟周期数。你放弃容量和灵活性，以获得可预测的速度。Groq在ISCA的两篇同行评审论文中记录了该设计：2020年的原始Tensor Streaming Processor，以及2022年的多芯片扩展。来源：快速思考：一种用于加速深度学习工作负载的张量流处理器，ISCA 2020。

数据流芯片。 Tenstorrent。其服务软件不如其他三种成熟，可靠的生产规格也更难找到。本文仅在类别层面进行介绍。

延迟特征：确定性对比统计性

这里需要格外注意。p99 延迟是日常运维问题，而大多数文章都跳过了其背后的硬件原因。

对于面向用户的应用，中位延迟说明不了多少问题。真正破坏 SLA 的是慢尾，即 p99 和 p999。在 GPU 上，这种尾部延迟来自两个设计选择。首先，GPU 在运行时决定执行什么，因此调度具有可变性。其次，并发请求共享相同的内存通道。这些特性内置于架构之中，并不是部署不当的迹象。

两种延迟分布。GPU 面板是宽分布，p50 与 p99 相距甚远，且存在长尾。Groq 面板是紧密的尖峰，p50 与 p99 几乎重合。 在 GPU 上，慢请求与中位数相距甚远。在 Groq LPU 上，延迟通过设计保持紧凑。

Groq 通过提前决定一切来减少这种变化。其编译器将完整模型映射到硬件，精确到时钟周期，包括芯片间的通信。相同输入形状的相同请求每次都会消耗相同的周期数，因此 p50 和 p99 非常接近。Groq 的 ISCA 2020 论文将此描述为核心设计目标：移除仲裁器和缓存等响应式硬件，使时序保持可预测。来源：Groq ISCA 2020 论文。这是 Groq 来自同行评审论文的设计主张，而非 DigitalOcean 进行的生产测试。

代价是刚性。GPU 使用连续批处理：服务器将不断变化的实时请求分组为一次传递。固定调度无法如此自由地适应。Groq 在单流、实时服务方面表现出色。当批量大小大幅波动时，其优势会缩小。

Inferentia2 和 TPU v5e 因编译而表现不同。两者都针对特定输入形状进行编译。不匹配的请求会被填充到最近的已编译形状。即使典型请求看起来正常，这种填充也会表现为 p99 延迟尖峰。Neuron 和 XLA 允许你选择要编译的形状，因此可以对此进行调优，但这确实是 GPU 可以避免的真实尾部延迟来源。

编译要求与操作灵活性

GPU 在操作灵活性方面更胜一筹。这是真正的工程优势，而非营销话术。

Inferentia2 需要通过 Neuron SDK 将模型编译为 AWS Neuron 格式。TPU v5e 需要 XLA 编译。编译并非一次性步骤。当模型改变、精度改变或输入大小、批量大小改变时，都需要重新编译。如果你每周发布一个新模型，或同时运行多个版本，这项成本永远不会消失。

模型变更的两条路径。GPU 路径加载新权重并直接服务，具有热交换循环，无需重新编译。固定功能路径先编译为 Neuron 或 XLA，再加载并服务，每次模型、精度或形状变化时都需要重新编译循环。 同样的模型变更，两条路径。GPU 热交换权重，固定功能加速器则在每次变化时重新编译。

我们没有经过验证的代表性模型规模的编译时间数据，也不会凭空编造。对于已发表版本，请从 AWS Neuron 文档和 Google 的 XLA 与 TPU 文档中获取当前数据，在真实模型上运行编译，并报告你测量到的结果，同时注明软件版本。在此之前，核心观点依然成立：编译是一项经常性成本，它随你配置变更的频率而增长。

第二个限制是算子覆盖范围。在固定功能硬件上，你只能运行编译器支持的算子。如果你的模型使用了编译器未实现的注意力变体或激活函数，要么编译失败，要么在慢速回退路径上运行，从而失去你花钱买来的速度。在投入之前，请对照 AWS Neuron 支持的算子列表和 OpenXLA 算子列表检查你的模型。这就是供应商“支持的模型”列表与你实际全速服务的模型之间的差距。

第三个限制是精度。精度选项很重要，因为量化是团队将更大模型装入更少内存的方法。

精度	NVIDIA H100 / H200	AWS Inferentia2	Google TPU v5e	Groq LPU
FP16	支持	支持	通过 BF16 路径	通过 TruePoint 实现高精度数学运算
BF16	支持	支持	支持，原生	TruePoint 累加
FP8	支持	可配置 FP8 (cFP8)	v5e 不支持，后续 TPU 新增	TruePoint 混合精度
INT8	支持	支持	支持，393 INT8 TOPS	支持
INT4、GPTQ、AWQ	支持，软件支持	有限	有限	由编译器路径决定

来源：cFP8、FP16、BF16 和 INT8 列表来自 AWS Inferentia。TPU v5e 的 BF16 和 INT8 数据来自 SemiAnalysis。TruePoint 来自 Groq。发布前请针对当前 SDK 文档核对 INT4 和量化行，因为框架支持会随版本变化。

选择 GPU 是一种深思熟虑的权衡。你放弃了 Groq 紧凑的 p99 延迟和 Inferentia2 在单一固定模型满载时每 token 的最低成本。作为回报，你可以在不重新编译的情况下更换模型，使用服务引擎支持的任何量化方式，并运行连续批处理以在不断变化的负载下保持硬件忙碌。

吞吐上限与模型规模限制

当LLM逐个生成token时，速度受限于芯片从内存读取模型权重的速度，而非其数学运算速度。芯片每生成一个token都要读取整个模型。因此，决定服务上限的是内存带宽，而非峰值FLOPS。每个token还会从内存中读取每请求状态（KV缓存），这增加了更多流量。Google研究人员在一篇同行评审论文中将此形式化：生成阶段以从内存加载权重和缓存为主，而提示处理阶段是计算密集型。这两个阶段在同一芯片上遇到不同的瓶颈。来源：Pope等人，《高效扩展Transformer推理》，MLSys 2023。

计算机架构师将计算量与内存流量的比值称为算术强度。它源自屋顶线（roofline）性能模型：

算术强度 = 执行的总FLOPs ÷ 从内存移动的总字节数

低的算术强度意味着内存受限：芯片等待数据。高的算术强度意味着计算受限：计算单元保持忙碌。提示处理是计算密集型的。token生成是内存密集型的。这就是为什么同一芯片上两个阶段的感觉如此不同。来源：Williams、Waterman和Patterson，《屋顶线：多核架构的一种深刻可视化性能模型》，《ACM通讯》，2009年。

对比计算密集的提示处理步骤与内存密集的token生成步骤的示意图，说明为什么生成受限于内存读取而非数学运算。 处理提示时让计算单元保持忙碌。生成每个新token时主要等待内存。这就是为什么内存带宽而非FLOPS决定芯片的服务速度。

H200是最清晰的证明。它使用与H100相同的计算die（每片晶圆上的die）。唯一的变化是内存更多更快，仅此一点就让推理速度快得多。来源：NVIDIA H200。

每颗芯片内存容量的条形对比：H200为141 GB，H100为80 GB，Inferentia2为32 GB，TPU v5e为16 GB，Groq LPU为220 MiB片上SRAM，并标注了各自的带宽。 容量决定能容纳的最大模型。带宽决定服务速度。Groq的小条形显示了SRAM的取舍。

该图表中有两个数字经常被误引。

Inferentia2带宽。AWS列出其最大的Inf2服务器为9.8 TB/s。这是所有12颗芯片的总和，而不是单颗芯片。每颗芯片约为820 GB/s。将9.8 TB/s引用为单芯片数字会高估带宽十倍以上。来源：Amazon EC2 Inf2实例。

Groq片上内存。Groq的ISCA 2022论文指出，每颗芯片向共享片上内存池贡献220 MiB。市场宣传将其四舍五入为“约230 MB”，但论文才是精确来源。芯片上没有HBM。这一设计选择解释了Groq的大部分行为。来源：《面向大规模机器学习的软件定义张量流多处理器》，ISCA 2022。

将内存带宽转化为实际毫秒数

带宽这个指标作为可对照工作负载校验的数字更有用：

每token时间下限 = 模型权重大小（字节）÷ 内存带宽（字节/秒）

这是一个理论下限，而非实测结果。它假设芯片在整步中只读取权重，没有竞争、没有KV缓存读取、没有批处理重叠，因此实际生产延迟会更高。它仍然告诉你芯片可能达到的最快速度。用它作为供应商延迟声明的合理性检查。

条形图显示在H100、H200、Inferentia2和TPU v5e上生成一个token的理论下限时间，每个均按模型权重大小除以内存带宽计算，公式显示在顶部。每个条形将模型权重大小除以该芯片的带宽。H200与H100相比唯一的变化是内存，而计算直接展示了效果：对于同一个70B模型（FP16），H100上每token约41.8毫秒，而H200上约29.2毫秒。

具体计算：70B模型在FP16下需要140 GB权重。在H100上（约3.35 TB/s），140 ÷ 3,350 ≈ 0.0418秒，即每token下限约41.8毫秒。在H200上（约4.8 TB/s），同样的140 GB需要140 ÷ 4,800 ≈ 0.0292秒，约29.2毫秒。计算die完全相同，只有内存变了，仅此一点就解释了差距。只要模型能装进该芯片的内存，这个公式适用于任何芯片和模型大小。

一颗芯片能装下多大的模型

你可以根据内存大小估算单颗芯片能容纳的最大模型。该方法适用于任何芯片：

权重大小（字节） = 参数数量 × 每参数字节数

FP16或BF16：每参数2字节
INT8：每参数1字节
INT4：每参数约0.5字节

所以70B模型在FP16下约需140 GB，INT8下约70 GB，INT4下约35 GB。

在考虑每个请求所需的工作内存之前，先应用这个（仅权重）：

H200，141 GB：在FP16下勉强装下70B模型，几乎没有余量。
H100，80 GB：可装下FP16的30B至40B模型，或量化后的70B模型。
Inferentia2，每芯片32 GB：约16B模型（FP16）。
TPU v5e，每芯片16 GB：约8B模型（FP16）。
Groq，每芯片220 MiB：仅模型的一小部分。一个70B模型需要分布在数百颗芯片上。

这些只是权重的上限。每个请求还需要随批大小和上下文长度增长的工作内存，所以实际限制更低。将这些视为上界，而非保证。没有权威的公开来源准确说明某个模型在生产中需要多少颗Groq芯片。Groq描述的是机架级芯片协同工作，并不总是给出每模型的芯片数，因此任何其他地方出现的“每模型N颗芯片”数字都应视为估算值。

你可以自己估算一个下限：

所需芯片数下限 ≈ (参数数量 × 每参数字节数) ÷ 每芯片220 MiB

70B模型在INT8下约需70 GB权重。除以每芯片220 MiB，得到约303颗芯片，仅用于容纳权重。在FP16下（约140 GB），则升至约607颗。两个数字都忽略了KV缓存、激活内存和网络开销，因此请将其视为下限，而非订单规格。

架构示意图，展示了70B参数模型完整存放在一两块GPU上，与同一模型被切分成数百个切片分布在多块Groq芯片上（每块仅220 MiB）的对比，并包含芯片数量公式和计算结果。 GPU可将大模型完整存放在一两块芯片上。Groq的每芯片内存很小，因此同一模型会分散到一整机架的芯片上，每块仅保存一个薄切片。所示芯片数只是根据公式算出的容量下限，并非已发布的部署规格。

Groq的取舍用一句话概括：片上内存非常快，但容量非常小，因此大模型需要很多芯片和大量机架空间。

跨芯片扩展

当单块芯片无法容纳模型时，你需要将其分布到多块芯片上。此时，芯片之间的连接就成了瓶颈。

三种互连拓扑并列对比：NVLink和NVSwitch为GPU构成全互联网格，TPU v5e使用二维环形网络，Groq则采用编译器调度的芯片间网络。 每种架构连接芯片的方式都不同。GPU使用全速网格，TPU通过环形网络路由，Groq在编译时调度芯片间流量。

NVIDIA GPU使用基于NVLink的张量并行。H100和H200上的第四代NVLink通过18条链路为每块GPU提供900 GB/s的总带宽。NVSwitch让服务器内的每块GPU都能以全速访问其他所有GPU。来源：NVIDIA Hopper架构深入解析。
Inferentia2通过NeuronLink在Inf2实例内部的芯片之间以192 GB/s的速度扩展。来源：Amazon EC2 Inf2实例。
TPU v5e通过二维环形互连扩展，每个pod最多256块芯片。来源：SemiAnalysis。
Groq使用编译时调度的芯片间网络，这与单片内部采用的方法相同，因此跨芯片通信保持确定性。Groq在ISCA 2022论文中描述了这一设计，但我们未能找到以GB/s为单位的公开带宽数据。在Groq发布官方数据之前，请谨慎对待你在其他地方看到的任何Groq互连带宽数字。

关键问题在于：随着芯片的增加，吞吐量是否大致线性扩展？通信开销又有多大？在供应商已披露互连带宽的地方请使用公开数据，并在未披露处注明。

独立基准测试实际展现的结果

以上所有内容均来自厂商规格表。规格表展示的是理论极限，而非芯片在实际流量下的表现。本节汇集了我们能够验证的独立测量数据。需要注意：这些数据来自不同模型上的不同测试，因此你无法仅凭这些数据对四款芯片进行排名。请将它们视为独立的数据点，而不是排行榜。

图表显示了根据Artificial Analysis的数据，Groq在Llama模型上的独立测量吞吐量随时间攀升，同时并列出MLPerf报告的NVIDIA GPU代际提升和TPU v5e的每美元性能结果，并提醒这些数据使用了不同的模型和方法。这些芯片中的一些确实有真实且独立测量的数据，但这些数据是在不同模型上采用不同方法测得的。请将其视为多个独立的数据点，而非一张统一的图表。

Groq在Meta开源Llama模型上的表现（由独立测试公司Artificial Analysis测试）：2024年2月在Llama 2 70B上达到每秒241个token，几个月后在Llama 3 70B上达到每秒284个token，到2024年12月在Llama 3.3 70B上达到每秒276个token；另一个独立的推测解码端点在相同模型上达到每秒1,665个token。Artificial Analysis的实时跟踪页面后来显示，在17家供应商中，Groq在Llama 3.3 70B上的输出速度并列最快，为每秒296.7个token。来源：Groq新闻室，引述Artificial Analysis和Artificial Analysis，Llama 3.3 70B供应商对比。这些是真实的独立测量结果，虽然历史数据来源于Groq自己的新闻室，因此请将这一趋势视为方向性可靠，并在引用前直接在Artificial Analysis上核实当前数字。

NVIDIA GPU在MLPerf推理基准测试上的表现。该基准测试由非营利行业联盟MLCommons运行和审计：在Llama 2 70B基准上，根据NVIDIA自己提交的MLPerf推理v4.1结果，H200的吞吐量最高达H100的1.5倍，而更新的Blackwell架构最高达H100的4倍。来源：NVIDIA Blackwell平台在MLPerf推理v4.1中创下新的LLM推理记录。在后续一轮中，CoreWeave自己提交给MLPerf推理v5.0的H200结果显示，在Llama 2 70B基准上每秒超过33,000个token，这是一个系统级数字，在很大程度上取决于该配置中包含的GPU数量。来源：HPCwire对MLPerf v5.0的报道。

Google TPU v5e有一个可直接比较且经审计的结果：在其MLPerf推理3.1提交中，四块TPU v5e芯片运行GPT-J 6B基准测试，其每美元性能是Google上一代TPU v4的2.7倍。来源：Google Cloud，使用Cloud TPU v5e实现经济高效的AI推理。这是一个小模型基准测试，并非70B级别的对比；而且我未能找到TPU v5e在大型Llama模型上的MLPerf提交结果，无法与上面的GPU数字直接比较。

AWS Inferentia2 是本节的空白点。我们搜索了使用 Inferentia2 的公开 MLPerf Inference 提交，但没有找到。AWS 发布了自己的声明，例如比同类 EC2 实例性价比高 40%，但我们无法像 Artificial Analysis 和 MLPerf 为其他三款芯片提供的那样，验证独立审计的 LLM 吞吐量数据。请直接查看当前的 MLCommons 结果页面；每轮提交都会变化。

决策框架：哪种芯片适合哪种工作负载

收藏本部分。这是一份决策指南，不是推销话术。

决策树。如果严格的 p99 SLA 是主要约束条件，选择 Groq。如果模型经常变化或您服务多个模型，选择 GPU。如果您有大量流量且成本最关键的单一固定模型，选择 Inferentia2 或 TPU。否则，灵活默认选项是 GPU。 从顶部开始。大多数路径通向 GPU，因为大多数工作负载的变化频率高于其冻结频率。

您的工作负载	最佳选择	原因
单一固定模型、高流量、成本最重要	Inferentia2 或 TPU v5e	编译成本可分摊。大规模下每个 token 成本最低。
严格的 p99 SLA、实时、单流	Groq LPU	每次运行的延迟相同，这是设计使然。
模型经常变化或进行 A/B 测试	GPU	无需重新编译。可自由更换模型。
大型或非标准模型、不常见算子	GPU	避免编译器支持缺口。
从一个端点服务多个模型	GPU	无需逐模型编译步骤。

简而言之：高流量且无严格延迟 SLA 的单一冻结模型 → Inferentia2 或 TPU 可能每个 token 成本更低。严格延迟 SLA → Groq 可能最合适。经常变化的模型、多个模型或非标准架构 → GPU。

专用芯片何时胜过 GPU

GPU 是灵活的默认选择，但并非总是正确。专用芯片在以下情况下胜出：

严格的实时 p99 SLA。语音代理和其他互动工具需要在单个请求上实现亚秒级响应，这正是 Groq 可预测延迟发挥优势的场景。没有通用的毫秒阈值，请根据用户实际容忍度进行测试。GPU 的延迟尾部在负载下可能以固定调度不会的方式破坏严格的 SLA。
单一模型、长时间冻结、高流量。当模型很少变化时，您只需支付一次编译成本，并将其分摊到数十亿个 token 上。每个 token 的成本可能低于 GPU。
与芯片编译形状匹配的模型。当输入大小与您为编译目标匹配时，固定功能芯片效果最好，因此填充保持较小。
对成本敏感且无延迟压力的批量推理。离线或排队作业关心每个 token 的成本，而非尾部延迟，固定功能芯片非常适合。

如果这些情况符合您的工作负载，专用芯片是理性的选择。如果您的设置经常变化，GPU 的灵活性比在狭窄基准上的峰值效率更有价值。