模型算法篇难度 3⏱ 11 分钟概念
01按场景选型（模型选择指南）
根据任务场景在性能、成本、延迟三角中找到最优模型组合
模型选型场景分析Model Routing多模型策略成本优化
更新于 2026-03-25model-selection-by-scenario
AI 计算硬件的类型、核心指标与选型逻辑，帮助开发者理解"用什么跑模型"。
内容摘要
AI 硬件是指专门为深度学习训练和推理优化的计算芯片及其配套系统。最常见的是 GPU（Graphics Processing Unit，图形处理单元），此外还有 TPU（Tensor Processing Unit，张量处理单元）、ASIC（Application-Specific Integrated Circuit，专用集成电路）等。
AI 硬件是指专门为深度学习训练和推理优化的计算芯片及其配套系统。最常见的是 GPU（Graphics Processing Unit，图形处理单元），此外还有 TPU（Tensor Processing Unit，张量处理单元）、ASIC（Application-Specific Integrated Circuit，专用集成电路）等。
为什么需要专用硬件？因为大语言模型的核心运算是海量的矩阵乘法。通用 CPU 虽然什么都能算，但它的核心少（几十个）、每次只能串行处理少量数据，就像一个全能但只有两只手的厨师。而 GPU 拥有数千个并行计算核心，可以同时处理大量矩阵运算，相当于几千个助手同时切菜——速度快了几个数量级。
在 Agent 应用中，硬件决定了模型推理的速度和成本。选错硬件可能导致：推理延迟太高（用户等不了）、显存不够（模型装不下）、或者花了冤枉钱（杀鸡用牛刀）。理解 AI 硬件的基本类型和关键指标，是做好模型部署的前提。
AI 硬件生态可以从两个维度理解：芯片类型（用什么）和核心指标（看什么）。
| 类型 | 代表产品 | 核心优势 | 典型用途 |
|---|---|---|---|
| GPU | NVIDIA H100 / B200、AMD MI300X | 通用并行计算，生态最成熟 | 训练 + 推理，最主流选择 |
| TPU | Google TPU v5p / v6 (Trillium) | 张量运算优化，与 Google Cloud 深度集成 | 大规模训练和推理（Google 生态） |
| ASIC | AWS Trainium / Inferentia、华为昇腾 | 特定任务极致优化，能效比高 | 大规模推理、边缘计算 |
| CPU | Intel Xeon、AMD EPYC | 通用计算，灵活性最高 | 数据预处理、调度编排、小模型推理 |
| 指标 | 含义（大白话） | 为什么重要 |
|---|---|---|
| 算力（FLOPS） | 每秒能做多少次浮点运算 | 决定训练和推理的计算速度 |
| 显存容量（GB） | 芯片上能装多少数据 | 决定能跑多大的模型 |
| 显存带宽（TB/s） | 数据从显存搬到计算核心的速度 | LLM 推理的真正瓶颈，比算力更关键 |
| 互联带宽（GB/s） | 多块芯片之间传数据的速度 | 多卡并行时，通信慢会拖垮性能 |
| 功耗（W） | 芯片运行时消耗的电力 | 影响电费和散热成本 |
AI 硬件加速的核心逻辑可以归结为一句话：把矩阵乘法从通用处理器搬到专用并行处理器上。
大语言模型推理时，绝大部分计算是矩阵乘法：$Y = W \times X$（$W$ 是模型权重，$X$ 是输入）。CPU 处理这种运算时是"一个一个算"，而 GPU 可以"几千个同时算"。
但光有计算能力还不够。模型权重和中间结果都存在显存（通常是 HBM，High Bandwidth Memory，高带宽存储器）里。计算核心要不停地从显存读数据、算完再写回去。如果显存带宽不够，计算核心就会"饿着肚子等数据"——这就是为什么 LLM 推理是显存带宽受限（memory-bandwidth bound）而不是计算受限。
多块 GPU 协同工作时，还需要高速互联（如 NVIDIA NVLink）在卡间传输数据。互联带宽不足会导致多卡扩展效率大打折扣。
图解要点：
# 检查 GPU 硬件信息（基于 PyTorch 2.1+，截至 2026-03）
import torch
if torch.cuda.is_available():
props = torch.cuda.get_device_properties(0)
print(f"GPU 型号: {props.name}")
print(f"显存容量: {props.total_mem / (1024**3):.1f} GB") # total_mem 单位为字节
print(f"SM 数量: {props.multi_processor_count}") # SM = 流多处理器
else:
print("未检测到 CUDA GPU")
torch.cuda.get_device_properties() 返回 GPU 的硬件属性。SM（Streaming Multiprocessor，流多处理器）数量反映并行计算能力——SM 越多，同时处理的矩阵分块越多。
NVIDIA 凭借 CUDA 生态的先发优势，是目前 AI 硬件的事实标准。
| 型号 | 架构 | 显存 | 显存带宽 | FP16 算力 | 功耗 | 定位 |
|---|---|---|---|---|---|---|
| A100 | Ampere | 80 GB HBM2e | 2.0 TB/s | ~312 TFLOPS | 400W | 上一代主力，仍广泛使用 |
| H100 | Hopper | 80 GB HBM3 | 3.35 TB/s | ~990 TFLOPS | 700W | 当前生产主力 |
| H200 | Hopper 升级 | 141 GB HBM3e | 4.8 TB/s | ~990 TFLOPS | 700W | H100 的大显存版本 |
| B200 | Blackwell | 192 GB HBM3e | 8 TB/s | ~2.5 PFLOPS (FP8) | 1000W | 最新旗舰，性能最强 |
关键信息：
AMD 是 NVIDIA 在 AI GPU 领域的主要竞争对手，核心优势是大显存和性价比。
| 型号 | 架构 | 显存 | 显存带宽 | FP16 算力 | 定位 |
|---|---|---|---|---|---|
| MI300X | CDNA 3 | 192 GB HBM3 | 5.3 TB/s | ~1.3 PFLOPS | 大显存推理，单卡可装 70B 模型 |
| MI325X | CDNA 3+ | 256 GB HBM3e | 6 TB/s | ~1.3 PFLOPS | MI300X 的显存升级版 |
| MI350X/MI355X | CDNA 4 | 288 GB HBM3e | 8 TB/s | ~5 PFLOPS | 新一代旗舰，支持 FP4/FP6 |
关键信息：
TPU 是 Google 自研的 AI 专用芯片，深度集成于 Google Cloud。
| 型号 | 单芯片 BF16 算力 | 显存 | 显存带宽 | 特点 |
|---|---|---|---|---|
| TPU v5p | ~459 TFLOPS | 95 GB HBM2e | 2.76 TB/s | 单 Pod 最多 8960 芯片 |
| TPU v6e (Trillium) | ~918 TFLOPS | 32 GB | 1.6 TB/s | 能效比 v5e 提升 67% |
关键信息：
| 概念 | 与 AI 硬件概述的区别 | 更适合关注的重点 |
|---|---|---|
| 模型部署架构 | 硬件是"用什么跑"，部署架构是"怎么组织起来跑" | 关注推理服务的系统设计（负载均衡、弹性伸缩） |
| 模型量化 | 硬件提供算力，量化是降低模型对算力和显存的需求 | 关注精度与效率的权衡（FP16→INT8→FP4） |
| 分布式训练 | 硬件是基础设施，分布式训练是利用多卡/多机的并行策略 | 关注数据并行、张量并行、流水线并行等策略 |
| 云服务 | 硬件是物理层面，云服务是把硬件打包成按需付费的服务 | 关注 GPU 实例选型、定价模式、弹性调度 |
核心区别：
| 常见误区 | 正确理解 |
|---|---|
| "算力越高推理越快" | LLM 推理主要受显存带宽限制，不是算力。一块带宽 8 TB/s 的卡，推理速度可能远超一块算力更高但带宽只有 2 TB/s 的卡。 |
| "显存越大越好" | 显存大小应匹配模型大小。7B 模型 FP16 约占 14 GB，用 192 GB 显存的卡跑它纯属浪费。按需选择，把钱花在刀刃上。 |
| "NVIDIA 是唯一选择" | AMD MI300X 在大显存推理场景有独特优势；Google TPU 在大规模训练上性价比出色；华为昇腾在国产化合规场景不可替代。没有"唯一最好"的硬件。 |
| "多卡一定比单卡快" | 多卡并行有通信开销。如果模型能装进单卡，单卡推理延迟通常更低。只有模型太大装不下时，才需要多卡切分。 |
| "FP8 / FP4 量化会严重损失精度" | 现代芯片（H100、B200、MI350）原生支持低精度计算。FP8 推理在大多数任务上精度损失不到 1%，但速度可提升 2–4 倍。 |
参考答案：
通常是显存带宽。LLM 推理时，每生成一个 token 都需要从显存读取全部模型权重，但每次读取只做少量计算（一次矩阵-向量乘法）。计算量相对于数据搬运量来说很小，所以计算核心大部分时间在等数据，显存带宽成为瓶颈。这就是为什么 H200（4.8 TB/s）比 H100（3.35 TB/s）在推理上更快，尽管两者算力相同。
参考答案：
70B 参数 × 2 字节（FP16）= 140 GB，这还不算推理时的 KV Cache 和激活值，实际需要约 150–160 GB。80 GB 显存的单卡装不下。解决办法有三种：(1) 量化到 INT8（约 70 GB）或 INT4（约 35 GB），可以装进单卡；(2) 使用多卡张量并行，把模型切分到 2–3 张 80 GB 卡上；(3) 选择大显存卡如 AMD MI300X（192 GB），单卡可装下 FP16 的 70B 模型。
参考答案：
7B 模型 FP16 约占 14 GB 显存，单张中端 GPU 即可装下。推荐方案：(1) 使用 INT8 量化将模型压缩到约 7 GB，进一步降低显存和计算需求；(2) 选择 1–2 张 NVIDIA A100 或同等级 GPU（无需 H100，因为 7B 模型不需要那么大的带宽和算力）；(3) 使用 vLLM 等高效推理框架，利用 PagedAttention 和连续批处理提升吞吐量。10 万次/天 ≈ 1.2 QPS 平均，峰值约 5–10 QPS，单卡 + vLLM 足够支撑。选择依据：模型小，不需要顶配硬件；预算有限，A100 性价比优于 H100；使用成熟推理框架可以最大化硬件利用率。
优先展示同分类且标签更接近的内容，方便继续串联学习。
根据任务场景在性能、成本、延迟三角中找到最优模型组合
根据参数规模选择合适的 LLM，平衡性能、成本和硬件需求
在个人电脑或私有服务器上运行大语言模型的核心概念与工具选择。