AI 加速器选型：GPU、TPU 与自研芯片如何评测

核心摘要

AI 加速器应被当作服务某个明确负载的完整系统来选，而不是按芯片峰值数字排榜。先固定模型、精度、流量形态、质量门禁、延迟目标、软件栈和成本边界，再让合格的 GPU、TPU 与自研芯片接受同口径评测。最终比较满足 SLO 的 Goodput、已验收结果成本、可靠性和迁移风险。不同模型规模、序列长度、Batch、并发或推理阶段下，最优平台可能完全不同。

目录

• 什么是 AI 加速器？
• 先定义工作负载契约
• 让负载与硬件约束匹配
• 把软件栈纳入加速器边界
• 建立可复现的基准测试
• 同时衡量 Goodput、质量与成本
• 正确读取厂商数据与 MLPerf
• 计算完整 TCO
• 验证迁移与回滚
• 选型决策框架
• 常见问题

核心要点

• 不存在统一赢家：模型、精度、序列长度、并发、延迟目标和软件变化都会改变最优硬件。
• 内存是一等约束：权重、激活、工作区和 KV Cache 可能在峰值算力发挥作用前就淘汰候选平台。
• Prefill 与 Decode 是不同负载：Prefill 更可能暴露计算上限，低并发 Decode 往往更受数据搬运限制。
• 芯片不等于部署系统：Runtime、编译器、Kernel、拓扑、Host、网络和可观测性都属于被测对象。
• Goodput 比原始吞吐更有决策价值：只统计满足延迟、质量、安全和格式要求的输出。
• TCO 必须包含变化成本：迁移工程、闲置容量、故障恢复和可移植性可能抵消较低的小时价格。

什么是 AI 加速器？

AI 加速器 是为机器学习工作负载提供高效执行能力的专用硬件及其配套软件栈。它包括 GPU、云 TPU 与 ASIC、推理专用处理器、晶圆级系统和端侧 NPU。

真正有意义的比较单位通常是可部署的完整系统，而不是裸芯片：

这个边界能避免一种常见错误：拿某厂商的单芯片稠密 FLOPS，与另一厂商的稀疏系统级结果或托管服务吞吐直接比较。它们描述的并不是同一个对象。

不同架构家族解决不同问题

这些是待验证的倾向，不是排名。专用架构可以在一个明确负载上优于 GPU，也可能在模型、Batch、序列长度或软件版本变化后失去优势。

先定义工作负载契约

工作负载契约确保每个候选平台解决同一个问题。缺少契约时，测试往往会被调整成最有利于某个平台的形态。

在索取结果前固定以下身份：

对于自回归 LLM，应使用生产 Trace 或版本化合成器。只给平均 Prompt 长度不够，长尾上下文和输出长度可能主导内存与延迟。

先做硬门禁，再做性能优化

候选平台出现以下任一情况时，应在性能排名前淘汰：

1. 无法加载精确模型与精度，或必须执行未经批准的转换；
2. 必需算子没有原生实现、可验证编译路径或可接受 Fallback；
3. 无法达到最低质量和安全门禁；
4. 暴露的指标不足以定位延迟与故障；
5. 无法在运维目标内恢复；
6. 所需区域与容量等级不可获得。

只有通过资格门禁的平台才进入成本与性能比较。

让负载与硬件约束匹配

硬件适配取决于负载的算术强度、内存占用、通信模式与延迟目标。Tensor 峰值吞吐只描述其中一个上限。

Prefill 与 Decode 压力不同

自回归推理包含两个阶段：

• Prefill 并行处理 Prompt Token。大矩阵运算能使用较多计算资源，长上下文还会增加 Attention 计算和临时状态。
• Decode 逐步生成 Token。低并发下，反复读取权重和 Cache State 可能让数据搬运比峰值算力更重要。

Batching 可以提高算术强度，但也会改变排队和单请求延迟。正确问题不是「这颗芯片每秒能生成多少 Token」，而是「这个系统在满足延迟分布时能完成多少已验收工作」。

跨平台研究 The xPU-athalon 显示，实测最优平台会随 Batch、序列长度和模型规模变化。该研究还说明闲置功耗、通信能耗、编译时间与软件成熟度都应进入选型。论文中的数值仅适用于被测平台与软件版本；可迁移的结论是必须保留工作负载身份。

容量、带宽与拓扑是三个约束

团队经常把三类问题统称为「显存」：

1. 容量决定权重、激活、工作区和在线 Cache 是否装得下。
2. 带宽决定数据能以多快速度抵达计算单元。
3. 拓扑决定模型跨设备或节点后需要付出多少通信成本。

张量并行 能让模型装入多设备，但集合通信可能抵消分布式计算节省的延迟。系统级结果必须同时报告精确链路拓扑和加速器数量，不能归因到单颗芯片。

把软件栈纳入加速器边界

软件兼容性是一份发布契约，而不是一个勾选项。只有精确模型图、数值格式、Kernel、Framework、Driver、Firmware 与服务能力能够协同工作，平台才算合格。

几个官方资料能说明这种边界：

• NVIDIA Blackwell 文档描述了双 Die、Transformer Engine、NVLink、RAS 与机密计算能力。这些架构事实本身不能证明业务性能。
• Google Cloud 把 TPU v6e 描述为具有特定 Slice Shape 和 Runtime 配置的 256 芯片二维 Torus Pod。单芯片规格无法代表每种 Slice 或服务行为。
• AWS 通过 NeuronCore-v3、设备内存、NeuronLink、Logical NeuronCore 与 Neuron 软件栈描述 Trainium2。适用性取决于编译和受支持执行路径。
• AMD ROCm 兼容矩阵把硬件与特定 OS、Firmware、Driver、Python、Framework 和 Serving Engine 绑定。因此「支持 ROCm」不足以证明可复现。

用真实 Compile-and-run 测试建立算子与功能矩阵：

建立可复现的基准测试

公平的加速器基准是可以重建输入、环境和验收策略的版本化实验。先记录身份，再采集结果。

{
  "benchmarkId": "support-llm-serving/17",
  "model": {
    "artifactSha256": "sha256:...",
    "tokenizerSha256": "sha256:...",
    "precision": {
      "weights": "int8",
      "activations": "bf16",
      "kvCache": "fp8"
    }
  },
  "workload": {
    "datasetRevision": "traffic-sample/42",
    "arrivalProcess": "replayed-timestamps",
    "concurrency": [1, 8, 32, 128],
    "warmupRequests": 200
  },
  "objectives": {
    "p95TtftMs": 800,
    "p95InterTokenMs": 80,
    "minimumTaskAcceptance": 0.97
  },
  "system": {
    "accelerator": "candidate-system",
    "count": 8,
    "topology": "declared-by-provider",
    "runtimeRevision": "sha256:...",
    "driverRevision": "pinned"
  },
  "measurement": {
    "powerBoundary": "whole-system-wall-ac",
    "costBoundary": "compute-network-storage-operations",
    "runnerRevision": "sha256:..."
  }
}

重复次数应足以支持当前决策所需的变异与置信区间，不存在通用次数。共享基础设施或时间趋势可能造成偏差时，应随机化候选运行顺序。保留请求级原始观测，确保分位数与失败可以重新计算。

建立证据等级

同时衡量 Goodput、质量与成本

已验收输出 Goodput 只统计通过发布策略的完成工作。原始吞吐可以上升，而用户体验同时下降。

对于请求级服务：

accepted(request) =
  completed
  AND quality_pass
  AND safety_pass
  AND schema_valid
  AND TTFT <= objective
  AND inter_token_latency <= objective
  AND end_to_end_latency <= objective

accepted_goodput = sum(accepted requests) / measured_seconds

还应报告：

• TTFT、Token 间延迟以及端到端 p50/p95/p99；
• 请求、输入 Token、输出 Token 与已验收任务吞吐；
• Queue Time、Cancel、Timeout 与 Error Rate；
• 权重、激活、Workspace 与 KV Cache 内存；
• Accelerator、Host、Network 与 Storage Utilization；
• 按风险切片拆分的质量与安全结果；
• 带明确边界的实测能耗；
• 每个已验收请求、输出 Token 或业务结果的成本。

不要用一个加权总分隐藏权衡。硬约束应保持可见，并展示成本、延迟、质量和可移植性的 Pareto Frontier。

正确读取厂商数据与 MLPerf

基准身份决定结果能否比较，产品名称本身不能。

MLPerf Inference: Datacenter 提供标准场景、负载生成、质量目标和提交元数据。使用时必须遵守以下边界：

• 比较同一 Benchmark、Scenario、Quality Target 与 Rules Version；
• Closed 与 Open Division 分开；
• 区分 Available、Preview 和 Research/Development/Internal 系统；
• 保留加速器数量、Host System、Software Stack 和提交代码；
• MLPerf Power 表示对应基准的整机墙上功耗；
• 不能用 TDP 或电源额定值冒充基准实测能耗。

厂商数据仍适合发现候选平台和理解架构。应明确标为厂商证据，保留模型和系统条件，并在自己的负载上复现影响决策的关键结论。

计算完整 TCO

完整 TCO 是在明确周期内交付已验收工作的总成本，而不是采购价除以峰值 FLOPS。

complete_cost =
  compute_rental_or_amortization
  + power_and_cooling
  + network_and_storage
  + software_and_support
  + migration_engineering
  + operations_and_incidents
  + idle_and_reserved_capacity
  + egress_and_exit_cost
  + rollback_capacity

cost_per_accepted_unit =
  complete_cost / accepted_requests_or_tokens

使用实测利用率，不要假设所有加速器始终满载。计入编译预热、维护、失败请求、容量碎片、预留承诺和多区域 Standby。测量功耗时，说明边界是 Accelerator、Node、Rack 还是 Facility，以及是否包含冷却开销。

对于云服务，把价格和供给放在可替换的 Worksheet 中，不要固化到长期正文。对于自建系统，明确折旧周期、融资、利用率、残值和数据中心假设。更低的芯片或实例价格不能直接证明已验收结果成本更低。

验证迁移与回滚

迁移是一项带退出条件的工程实验，成功加载模型文件只是第一步。

迁移证明

1. 编译并执行代表性模型、自定义算子和 Dynamic Shape。
2. 复现基线输出，调查所有质量差异。
3. 覆盖 Streaming、Cancel、Batching、Cache Pressure 与 Overload。
4. Profiling 通信、内存和 Fallback Path。
5. 注入 Worker、Link、Host 和依赖故障。
6. 测量 Cold Start、Scale-up、Repair 与 Restore Time。
7. 先运行 Shadow Traffic，再进行受门禁保护的 Canary。
8. 保留足以满足回滚目标的旧平台容量。

锁定不只来自硬件，还来自模型格式、自定义 Kernel、编译器行为、云 API、编排、可观测性、预留合同和数据出口。应记录每层依赖的 Owner。

选型决策框架

AI 加速器选型应先通过门禁，再做优化。

使用保留证据的决策表：

当模型、流量分布、Runtime、价格合同、区域或质量策略发生实质变化时，旧决策就会失效。应按版本化契约重跑受影响门禁，而不是把过去赢家永久化。

常见问题

GPU 一定是 AI 工作负载最稳妥的默认选择吗？

GPU 往往拥有更广的 Framework 和 Kernel 支持，但「最稳妥」取决于负载和组织。对于稳定且已受支持的工作负载，托管 TPU 或自研加速器可能降低成本或改善供给；而模型变化快、自定义算子多、要求多云和重视调试时，GPU 的可移植性可能更有价值。两者都需要证据，不能固化成统一结论。

Tokens per Second 能直接比较不同 AI 加速器吗？

只有模型制品、Tokenizer、输入输出分布、精度、Serving Engine、并发、采样、硬件数量、质量门禁和延迟目标一致时才可以。单用户 Decode 速率与重度 Batch 的聚合速率回答不同问题，应同时报告分阶段延迟和满足 SLO 的聚合 Goodput。

初筛时应该看峰值 FLOPS 还是显存带宽？

两者都能帮助淘汰明显不可能或发现值得测试的平台，但都不能独立完成选型。峰值 FLOPS 必须声明精度、稀疏性和聚合层级；显存带宽必须结合容量、访问模式、Cache、Kernel 与算术强度解释。规格只能形成假设，完整负载测试才提供决策证据。

如何公平比较 AI 加速器能效？

对同一已验收负载测量能耗，并明确边界。整机墙上能耗包含 Accelerator TDP 未覆盖的影响；流量波动时 Idle Behavior 也很重要。MLPerf Power 结果只适用于对应 Benchmark、System 与 Scenario，不能转换成通用芯片能效排名。

多久应该重新评估一次加速器选型？

模型、精度、上下文分布、并发、SLO、Runtime、Driver、价格、供给或业务质量策略发生实质变化时都应重评。使用版本化契约后，团队可以只重跑受影响的门禁，同时保留历史证据。

总结

AI 加速器选型本质上是工作负载资格审查和系统工程问题。先定义行为与流量契约，淘汰不兼容平台，再可复现地评测合格系统，并只统计通过产品门禁的工作。比较完整系统与完整成本，最后证明迁移、故障恢复和回滚。即使具体 GPU、TPU 与自研芯片持续变化，这套方法仍然成立。

资料来源与延伸阅读

• The xPU-athalon: Quantifying the Competition of AI Acceleration
• MLPerf Inference: Datacenter
• Google Cloud TPU v6e 架构与配置
• NVIDIA Blackwell 架构
• AWS Trainium2 架构
• AMD ROCm 兼容矩阵

相关资源

• LLM 推理：指标、架构与生产门禁
• AI 推理成本经济学
• KV Cache：内存、延迟与容量规划
• 模型量化：制品、运行时适配与质量门禁
• 模型推理
• 吞吐量