跳到主要内容

硬件总览

这篇文章用一条主线把大模型硬件知识串起来。
它的目标不是讲完每个硬件细节，而是先建立判断框架：当我们说“这个模型能不能跑”“需要几张卡”“为什么吞吐上不去”“为什么显存爆了”时，应该看哪些硬件因素。

一句话来总结：

LLM 硬件 = 放得下模型 + 跑得动计算 + 传得动数据 + 扛得住并发。

展开就是：

  • 显存容量和带宽
  • CPU / 内存 / 存储
  • GPU 算力
  • GPU 互联和网络
  • 推理框架调度
  • 监控和排障

1. 先看 GPU / 加速卡​

大模型训练和推理最核心的硬件通常是 GPU 或 AI 加速卡。

看 GPU 时不要只看“型号贵不贵”，至少要看：

  • 显存容量。
  • 显存带宽。
  • 支持的计算精度，例如 FP16、BF16、FP8、INT8。
  • Tensor Core / Matrix Core 能力。
  • 多卡互联能力。
  • 驱动、CUDA、推理框架支持情况。

对于 LLM 推理，显存容量和显存带宽经常比理论算力更直接影响体验。

对应阅读：

2. CPU 和系统内存不是不重要​

虽然模型主体计算在 GPU 上，但 CPU 和系统内存仍然影响服务稳定性。

CPU 常参与：

  • 请求解析。
  • tokenizer。
  • prompt 组装。
  • 调度。
  • 后处理。
  • 日志和监控。
  • RAG 检索链路。

系统内存常用于：

  • 模型加载过程。
  • CPU offload。
  • 文件缓存。
  • 多进程服务开销。
  • 数据预处理。

如果 CPU 太弱、内存太小，即使 GPU 很强，也可能出现加载慢、请求排队、tokenizer 成为瓶颈等问题。

对应阅读：

3. 显存决定模型能不能放下​

LLM 推理时，显存通常由几部分组成：

总显存 ≈ 权重显存 + KV Cache 显存 + 运行时开销 + 冗余空间

其中：

  • 权重显存取决于模型参数量和精度。
  • KV Cache 取决于上下文长度、并发数、层数和 KV heads。
  • 运行时开销来自 CUDA、推理框架、临时 buffer 等。

一个常见误区是只看权重大小。例如 7B FP16 权重约 14GB，但真实服务还要留 KV Cache 和运行时空间，不代表 16GB 显卡一定能稳定承载高并发长上下文。

对应阅读：

4. 算力和精度决定跑得多快​

GPU 厂商通常会标注 FP16、BF16、FP8、INT8 等不同精度下的理论算力。

但理论算力不等于实际吞吐。实际推理性能还受这些因素影响：

  • 显存带宽。
  • batch 大小。
  • 输入输出 token 长度。
  • kernel 优化。
  • 推理框架调度。
  • KV Cache 管理。
  • 是否使用量化。

LLM 推理常常不是单纯“算力越高越快”。在小 batch、低并发、访存压力大的场景里，显存带宽和 kernel 效率可能更关键。

对应阅读：

5. 多卡不是简单相加​

当单卡显存放不下模型，或者吞吐不够时，就会进入多卡部署。

多卡常见并行方式：

  • Tensor Parallel。
  • Pipeline Parallel。
  • Data Parallel。
  • Expert Parallel。

多卡带来更多资源，也带来通信成本。模型并不是自动因为有 4 张卡就快 4 倍。

需要关注：

  • GPU 之间是 PCIe 还是 NVLink。
  • 是否有 NVSwitch。
  • GPU 拓扑是否均衡。
  • 推理框架是否支持对应并行方式。
  • 跨卡通信是否成为瓶颈。

对应阅读：

6. 存储影响模型启动和分发​

模型权重很大。几十 GB 到数百 GB 的模型并不罕见。

存储会影响：

  • 模型下载速度。
  • 服务冷启动时间。
  • 多副本模型分发。
  • 容器镜像大小。
  • 缓存目录管理。

本地 NVMe SSD、网络盘、对象存储、容器镜像打包模型，这些方案的启动速度和维护方式都不同。

对应阅读：

7. 多机集群看网络​

单机多卡不够时，就需要多机 GPU 集群。

这时网络成为核心因素：

  • Ethernet。
  • InfiniBand。
  • RDMA。
  • RoCE。
  • 跨节点带宽和延迟。

训练、MoE、跨节点 tensor parallel 对网络特别敏感。在线推理集群虽然不一定每个请求都跨节点切分模型，但负载均衡、模型分发、日志和监控也依赖网络稳定性。

对应阅读：

8. 硬件选型要从任务反推​

不要先问“买哪张卡”，先问任务是什么。

不同场景关注点不同：

场景优先关注
本地实验成本、显存、生态兼容
单卡微调显存容量、BF16/FP16 支持、内存
在线推理显存、带宽、吞吐、稳定性、成本
长上下文服务KV Cache 容量、显存、调度能力
多模态模型显存、图像预处理、视觉 encoder 开销
多机训练GPU 互联、网络、存储、可靠性

硬件选型的正确方式是：

模型规模 + 精度 + 上下文长度 + 并发 + 延迟目标 + 成本预算
  -> 反推 GPU / 内存 / 存储 / 网络

对应阅读：

9. 监控和排障决定能不能长期稳定​

模型能启动只是第一步。线上还要持续关注：

  • GPU 利用率。
  • 显存占用。
  • 显存碎片。
  • 温度。
  • 功耗。
  • ECC / Xid 错误。
  • GPU 掉卡。
  • OOM。
  • PCIe / NVLink 异常。

硬件问题常常表现为模型服务问题，例如延迟抖动、请求超时、服务重启、吞吐下降。

对应阅读：

10. 推荐学习路径​

建议按这个顺序学习硬件部分：

  1. GPU/加速卡：先知道核心计算硬件是什么。
  2. CPU 与内存：理解主机资源对服务的影响。
  3. 显存：理解模型为什么会 OOM。
  4. 模型尺寸与显存估算：学会粗算能不能放下。
  5. GPU 互联：理解多卡为什么需要高速互联。
  6. 存储与模型加载：理解模型启动和分发。
  7. 网络与集群：理解多机训练和推理集群。
  8. 单机多卡：理解常见多 GPU 部署方式。
  9. 硬件精度与算力：理解 FLOPS、FP8、INT8 等指标。
  10. 硬件选型：把前面的知识用于决策。
  11. 硬件监控与排障：让服务长期稳定运行。

11. 总结​

LLM 硬件知识可以串成一条链：

模型大小
  -> 权重显存
  -> KV Cache
  -> GPU 显存和带宽
  -> 多卡互联
  -> 存储和网络
  -> 监控和排障

实际工程中，硬件不是孤立选择。模型结构、量化方式、上下文长度、并发、推理框架和业务延迟目标，都会共同决定硬件需求。

最实用的判断方式是：先用模型参数和精度估算权重，再用上下文和并发估算 KV Cache，最后结合推理框架压测结果确定硬件方案。