NVIDIA 的加速计算堆栈：GPU、CUDA 与 AI 基础设施

什么是“加速计算”

加速计算的想法很简单：与其让通用 CPU 做所有任务，不如把繁重且重复的部分卸载给专门的处理器（通常是 GPU），这样这些工作可以更快、更高效地完成。

CPU 擅长处理各种各样的小任务——运行操作系统、协调应用、做决策。GPU 则为同时完成大量相似计算而设计。当一个工作负载可以被切分为成千上万（甚至百万）个并行操作——例如大矩阵相乘或对大量数据批次应用相同的数学变换——GPU 就像一个“加速器”，能显著提升吞吐量。

为什么这不仅仅关乎游戏

游戏让 GPU 出名，但相同的并行数学在现代计算中随处可见：

• 训练和运行 AI 模型（尤其是深度学习）
• 视频处理与计算机视觉
• 科学模拟（天气、物理、化学）
• 数据分析与检索

这就是加速计算从消费级 PC 走进数据中心的原因。它不仅仅是“更快的芯片”——而是让此前在成本、时间和能耗上不可行的工作负载变为可行。

堆栈：硬件 + 软件 + 基础设施

当人们说“英伟达的加速计算堆栈”时，通常指三层协同工作：

1. 硬件： 为服务器和大规模工作负载设计的 GPU。
2. 软件： CUDA 以及一系列库/工具，让开发者不用从零手写所有内容就能使用 GPU。
3. 基础设施： 网络、存储和调度，保证 GPU 有足够的数据并在多机间协调工作。

读完本指南你会明白什么

读完后，你会对 GPU 与 CPU 的对比、为什么 AI 很适合 GPU、CUDA 实际做了什么，以及构建可扩展 AI 系统时除 GPU 外还需要哪些要素有一个清晰的心智模型。

GPU 与 CPU：简单的心智模型

把 CPU 想成一小队训练有素的专家。人数不多，但每个人都擅长决策、快速切换任务并处理复杂的“如果这样，则那样”的逻辑。

GPU 则像有数百甚至数千名能干的助理。每个助理可能不如专家复杂，但他们可以同时处理大量相似的工作。

CPU 擅长什么

CPU 在控制与协调方面表现出色：运行操作系统、管理文件、处理网络请求以及执行带大量分支的代码路径。它们为顺序逻辑而生——步骤 1 然后 2，然后 3，尤其是每一步都依赖上一步时。

GPU 擅长什么

当相同的操作需要并行应用到许多数据上时，GPU 发光发热。不再是一个核心重复做同一件事，而是许多核心同时完成它。

常见的 GPU 友好型工作负载包括：

• 矩阵运算（深度学习的核心）
• 图像与视频处理（滤镜、编码、识别）
• 物理仿真与科学计算
• 3D 渲染与图形学
• 大规模数据并行分析

误区：“GPU 会替代 CPU”

在大多数真实系统中，GPU 并不替代 CPU——它们互补。

CPU 通常运行应用、准备数据并协调工作。GPU 处理并行的重计算。这就是为什么现代 AI 服务器仍然配备强大的 CPU：没有良好的“专家”协调，这些“助理”可能会闲着而不是工作。

NVIDIA 如何推动 GPU 成为通用计算平台

从图形芯片到“也能做其它数学运算”

GPU 最初是为绘制像素和 3D 场景而设计的。在 1990 年代末和 2000 年代初，NVIDIA 等厂商不断增加并行单元以加速着色与几何处理。研究者注意到，许多非图形问题也归结为对大量数据点重复相同操作——这正是图形流水线擅长的。

简要时间线：

• 2000 年代初： 学术界通过把计算表达为图形操作尝试“GPGPU”。
• 2006–2007： NVIDIA 推出 CUDA，这是一种编程模型，让开发者在 GPU 上编写通用代码，而不用再假装是图形操作。
• 2010 年代： GPU 加速的库日趋成熟；深度学习框架标准化对 GPU 的支持。
• 2010s 后期–2020s： 数据中心 GPU 成为训练和部署大型 AI 模型的默认选项。

为什么图形数学与科学/机器学习工作负载匹配

图形工作负载大量依赖线性代数：向量、矩阵、点积、卷积和巨量的乘加运算。科学计算使用相同的构件（例如仿真、信号处理），而现代机器学习更是如此——尤其是密集矩阵乘法和卷积。

关键的匹配点是并行性：许多 ML 任务对大批量数据（像素、token、特征）应用相同操作。GPU 被设计为高效运行数千个相似线程，因此在这些模式下每秒能做的算术远超 CPU。

采用的良性循环：工具、库与人才

NVIDIA 的影响不仅是更快的芯片；更重要的是让 GPU 为普通开发者可用。CUDA 让 GPU 编程更容易上手，越来越多的库（线性代数、神经网络、数据处理）减少了编写自定义内核的需要。

随着越来越多团队发布基于 GPU 的产品，生态系统自我强化：更多教程、更好的工具、更有经验的工程师和更强的框架支持——让下一支团队更容易成功采用 GPU。

CUDA：解锁硬件的软件层

再强大的 GPU 也只有在开发者能可靠指挥它时才有用。CUDA（Compute Unified Device Architecture）是 NVIDIA 的编程平台，让 GPU 感觉像一个真正的计算目标，而不仅仅是图形的附加品。

为什么软件平台很重要

CUDA 同时完成两件大事：

• 为程序员提供清晰的方式来表达“以并行方式运行这段工作”。
• 提供编译器、驱动和库，把这一意图转化为快速的 GPU 执行。

没有这一层，每个团队都得为每代芯片重做底层 GPU 编程、性能调优和内存管理。

内核、线程与并行性——通俗说法

在 CUDA 中，你会写一个 kernel（内核），它就是一个被设计成同时运行多次的函数。你不是调用它一次，而是在成千上万甚至百万个轻量线程上启动它。每个线程处理整体工作的一小块——比如一个像素、一行矩阵或神经网络计算的一个小片段。

关键思想：如果你的问题可以切成许多相似且独立的任务，CUDA 就能把这些任务高效地调度到 GPU 的众多核心上。

CUDA 在实际中的出现形式

大多数人不会为 AI 手动写原始 CUDA。它通常运行在他们已经使用的工具之下：

• 深度学习框架（PyTorch、TensorFlow）
• NVIDIA 的库，如 cuDNN（深度学习）、cuBLAS（线性代数）、NCCL（多 GPU 通信）

这就是为什么“支持 CUDA”常常是 AI 基础设施规划中的一个核对项：它决定了你的堆栈能使用哪些优化构件。

可移植性的权衡

CUDA 与 NVIDIA GPU 紧密绑定。这种紧密集成是其快速且成熟的主要原因——但也意味着把相同代码迁移到非 NVIDIA 硬件上可能需要改动、替代后端或不同的框架。

为什么 AI 工作负载非常适配 GPU

AI 模型看起来很复杂，但大量繁重工作归结为在巨大规模上重复相同的数学运算。

张量与“矩阵乘法”的现实

“张量”只是多维的数组：向量（1D）、矩阵（2D）或更高维（3D/4D+）。在神经网络中，张量表示输入、权重、中间激活和输出。

核心操作是对这些张量进行乘加，尤其是 矩阵乘法（以及相关的“卷积”）。训练与推理重复执行这种模式数百万到数万亿次。这就是为什么 AI 性能常用系统做密集乘加运算的速度来衡量。

为什么 GPU 与此模式匹配

GPU 被构建为并行运行大量相似计算。与通常设计中几个很快的核心不同，GPU 有很多较小的核心，能一次处理庞大的运算网格——这正适合张量工作负载中的重复数学。

现代 GPU 还包含面向该用例的专用单元。概念上，这些“面向张量的加速器”比通用核心更高效地完成乘加模式，从而在每瓦上提供更高吞吐量。

训练与推理：不同的瓶颈

训练是优化模型权重，通常受总体算力和多次在内存间移动大型张量限制。

推理则提供预测，常受延迟目标、吞吐量以及如何快速喂给 GPU 数据而不浪费周期的限制。

为什么批量大小、显存与吞吐量重要

AI 团队关心：

• 批量大小（batch size）： 更大的批量能提升 GPU 效率，但需要更多显存。\n- 内存容量/带宽： 如果张量放不下或读写速度不够快，GPU 就会等待。\n-吞吐量： 每秒能处理多少训练样本或查询——常直接映射到成本和用户体验。

AI 服务器内部：是什么让 GPU 机箱不同

现代“GPU 服务器”外观看起来像普通服务器，但内部围绕尽可能高效地为一张或多张高功率加速卡供给数据来设计。

核心部件：GPU、CPU、RAM、存储

• GPU（主角）： 一台服务器可能装 1、4、8 或更多数据中心 GPU。这些负责训练与推理的并行计算。\n- CPU（协调者）： CPU 仍然重要：准备数据、运行操作系统、管理网络并保持 GPU 忙碌。但通常不是 AI 的主要计算引擎。\n- 系统 RAM： CPU 的工作内存，用于缓存数据集、预处理并在把批次送到 GPU 之前做中间准备。\n- 存储： 快速 SSD（常为 NVMe）在加载大型数据集和检查点时减少等待。慢速存储会让昂贵的 GPU 空闲。

显存：为什么 GPU 内存常成为瓶颈

每个 GPU 都有自己的高速内存称为 显存（VRAM）。很多 AI 任务并不是因为 GPU “太慢”而失败，而是因为模型、激活与批量无法放入显存。

这就是为什么人们会讨论“80GB GPU”或“能放多少 tokens”。如果显存不足，你可能需要更小的 batch、降低精度、模型分片或更多/更大显存的 GPU。

多 GPU：更多卡片不一定自动更快

在一台机器里放多张 GPU 有好处，但扩展性能取决于 GPU 之间需要通信多少。有些工作负载几乎线性扩展；另一些则因同步开销、显存复制或数据加载瓶颈而受限。

功耗与散热：实际考量

高端 GPU 每张可能消耗数百瓦。一个 8 卡服务器在行为上更像一个取暖器而不是“普通”机架服务器。这意味着：

• 更大的电源和精心规划的机柜供电\n- 更响、更大风量的冷却方案\n- 更高的热输出，影响数据中心的放置密度

一个 GPU 机箱并非只是“带 GPU 的服务器”——它是为保持加速器满负荷供给、散热和通信而设计的系统。

超越 GPU 的 AI 基础设施：网络、存储、调度

GPU 的速度取决于周边系统。当你从“一台强力服务器”扩展到“很多 GPU 协同工作”时，限制因素往往不再是原始算力，而是你能多快移动数据、共享结果并保持每个 GPU 忙碌。

为什么在大规模时网络成为瓶颈

单 GPU 任务多数从本地存储拉数据并运行。多 GPU 训练（以及许多推理部署）则频繁交换数据：梯度、激活、模型参数和中间结果。如果交换很慢，GPU 就会等待——而空闲的 GPU 时间是最昂贵的。

网络瓶颈的两个常见症状是：

• 增加 GPU 后训练速度几乎没有提升\n- 利用率波动剧烈，GPU 在 100% 与接近 0% 之间交替

高速互连与网络结构（概念视角）

在服务器内部，GPU 可能通过非常快速、低延迟的连接链接，以便无需绕行慢路径即可协调。跨服务器则使用为高负载下可预测性能设计的高带宽网络结构。

概念上，可分为两层：

• 节点内互连： 帮助同一机箱内的 GPU 协同工作\n- 节点间网络： 让多台机箱表现得像一个更大的系统

这就是为什么“GPU 数量”本身并不足够——你还要问这些 GPU 是如何互相通信的。

存储与数据流水线：有效地喂给 GPU

GPU 不直接在“文件”上训练，它们在批次的流上训练。如果数据加载慢，计算就会停滞。高效的流水线通常结合：

• 快速存储（常为分布式）和接近计算的缓存\n- 在 CPU 或加速器上并行预处理（解码、增强、分词）\n- 智能批处理和预取，确保下一个批次在需要之前已准备就绪

一个构建良好的流水线能让相同的 GPU 感觉快很多。

调度与利用率：保持昂贵硬件的高利用

在真实环境中，许多团队共享同一个集群。调度决定哪个作业获得 GPU、时长以及分配哪些资源（CPU、内存、网络）。良好的调度能减少“GPU 饥饿”（作业排队）与“GPU 浪费”（分配但空闲）。它还能启用优先队列、抢占和资源右尺寸化——当 GPU 小时是预算项而非可有可无时，这点至关重要。

NVIDIA 的软件生态：库、工具和驱动

硬件只是故事的一半。NVIDIA 的真正优势在于把 GPU 从快速芯片变成团队可以构建、部署和维护的平台的软件堆栈。

库与 SDK：作为“构件”

大多数团队不会写原始 GPU 代码。他们用构件来组装应用：经过优化的库和 SDK 处理常见、昂贵的操作。把它们想象成加速的“乐高积木”——矩阵运算、卷积、视频处理、数据移动——让你能专注于产品逻辑，而不是重写底层内核。

框架如何获得 GPU 加速

流行的 ML 框架（用于训练和推理）与 NVIDIA 堆栈集成：当你在 GPU 上运行模型时，框架会把关键操作路由到这些加速库的底层。从用户角度看，这可能只是一个简单的设备切换（“使用 GPU”），但在这个开关背后是一串组件：框架、CUDA 运行时和性能库共同工作。

必须安装和维护的内容

至少，你需要管理：

• GPU 驱动（与硬件对话）\n- CUDA 运行时（让应用能在 GPU 上启动工作）\n- 编译器和工具包（如果你构建自定义 CUDA 扩展）\n- 框架构建与容器镜像（团队实际运行的内容）

运营现实：兼容性与更新

这是许多项目容易出错的地方。驱动、CUDA 版本和框架发布之间有兼容性约束，版本不匹配可能导致性能下降甚至部署失败。许多团队在容器中固定“已验证的组合”，并使用分阶段更新（dev → staging → production）。把 GPU 软件堆栈当作产品依赖来管理，而不是一次性安装完就算了。

向上扩展与向外扩展：从单个 GPU 到集群

当你的模型在单卡上跑通后，下一个问题是如何更快（或如何容纳更大的模型）。两条主要路径：向上扩展（在一台机器里放更多/更强的 GPU）和 向外扩展（让多台机器协同工作）。

从单 GPU 到多 GPU：有什么变化

单卡时，一切都在本地：模型、数据和显存都在一处。多卡时，你开始在设备间协调工作。

向上扩展通常指迁移到一台装有 2–8 张 GPU 的服务器，这能带来显著升级，因为 GPU 可以快速共享结果并访问同一主机的 CPU 与存储。

向外扩展则是增加更多服务器，并用快速网络连接它们。这是训练能扩展到数十或数千张 GPU 的方式——但协调成为首要问题。

数据并行 vs 模型并行（通俗说法）

数据并行： 每张 GPU 保持一份完整模型拷贝，但每张卡训练不同的数据切片。每步结束后，GPU 通过交换梯度来达成权重一致。这是最常见的起点，因为易于理解。

模型并行： 因为模型太大或太慢而无法放在一张卡上，模型本身被切分到多张 GPU。在前向和反向传播中，GPU 需要互相通信，而不只是步骤结束时同步。这能解锁更大的模型，但通常增加通信开销。

许多实际系统在服务器内部使用模型并行，在服务器间使用数据并行的混合策略。

通信开销：为什么更多 GPU 不总是更快

更多的 GPU 意味着“谈话时间”更多。如果工作负载很小或网络很慢，GPU 可能因等待更新而空闲。当出现以下情况时，会看到回报递减：

• 模型每步计算时间很短（计算量少）但同步频繁。\n- 无法在不损害质量的情况下增大 batch。\n- 互连或网络带宽成为瓶颈。

你已超出单机能力的实际信号

当出现以下情况，你可能需要多 GPU 或集群：

• 即便调优后仍频繁触及 GPU 内存上限。\n- 训练时间不可接受且单卡利用率已很高。\n- 需要更高的可用性或同时运行许多作业（多个团队、产品、试验）。

到那时，堆栈不再只是 GPU，还要包括高速互连、网络和调度——因为扩展是关于协调的，而不仅仅是原始算力。

加速计算在真实产品中的应用

加速计算并非研究室的幕后技巧，而是很多日常产品变得即时、流畅且越来越智能的原因：因为某些工作负载在成千上万次小运算并行执行时运行得更好。

AI 模型训练与服务

大多数人注意到的是 服务端：聊天助手、图像生成器、实时翻译和应用内的“智能”功能。底层，GPU 支持两个阶段：

• 训练： 对大量数据进行计算以学习模型参数。\n- 推理（服务）： 使用已训练模型给出回答、摘要、推荐或检测异常——常常有严格的延迟要求。

在生产环境中，这体现在更快的响应、更高的吞吐（每台服务器支持更多用户）以及在给定数据中心预算内运行更大或更强模型的能力。

视频处理、渲染与创意工作流

流媒体平台和视频应用在编码、解码、放大、抠图和特效等任务上依赖加速。创意工具在时间线回放、调色、3D 渲染和 AI 功能（降噪、生成填充、风格迁移）中也用到它。结果是更少等待、编辑时更实时的反馈。

科学计算与工程仿真

加速计算被广泛应用于在巨大网格或大量粒子上重复相同数学的仿真：天气与气候模型、计算流体力学、分子动力学与工程设计验证。更短的仿真周期意味着更快的研发、更频繁的设计迭代与更高的结果质量。

实时分析与推荐系统

推荐、搜索排序、广告优化与欺诈检测常需快速处理大规模事件流。GPU 能加速部分特征处理与模型执行，使决策在用户仍在页面时就能完成。

选择合适工具

并非所有工作都适合放在 GPU 上。如果你的工作负载较小、分支逻辑多或以顺序逻辑为主，CPU 可能更简单也更便宜。加速计算在你能一次执行大量相似数学或当延迟与吞吐直接影响产品体验时最有价值。

一个实用产品提示：随着团队越来越多地构建 AI 功能，瓶颈往往不再是“我们能写 CUDA 吗？”，而是“我们能否安全地发布并快速迭代应用？”。像 Koder.ai 这样的 平台在这方面很有用：你可以通过对话驱动的工作流快速原型并发布 web/后端/移动应用，然后在需要加速时在后台接入基于 GPU 的推理服务——而无需重建整个交付管道。

选择 GPU 与平台：实用采购清单

为 AI 购买“一块 GPU”实际上是在购买一个小平台：算力、内存、网络、存储、供电、散热和软件支持。事先做些结构化评估能避免模型变大或使用量上升时的痛苦惊喜。

1) 根据工作负载匹配 GPU

从你最常运行的任务开始——训练、微调还是推理——以及未来 12–18 个月预期的模型大小。

• 显存（容量）： 最快遇到的瓶颈通常是显存不足。如果进行大批量训练或服务较大模型，应优先考虑容量（和内存带宽），而不是仅看“峰值 TOPS”。\n- 计算吞吐： TFLOPS/TOPS 等规格重要，但只有在工作负载能持续喂满 GPU 时才有意义。查看贴近你用例的基准（例如 transformer 训练、扩散模型推理）。\n- 互连： 如果会使用多张 GPU，卡间的连接（例如某些系统里的 NVLink）可能决定“能否良好扩展”。多节点集群则需要关注网络（通常是 InfiniBand 或高端以太网）。\n- 功耗与热设计： 数据中心 GPU 每张消耗数百瓦。购买前确认机柜供电、PDU 与散热余量。

2) 为完整系统预算，而非仅 GPU

一张强 GPU 在错配机箱里仍会表现不佳。常见的隐藏成本包括：

• CPU 与 RAM，用于数据准备与保持流水线流畅\n- 存储（本地快速 NVMe 用于数据集/检查点；共享存储供团队使用）\n- 网络（网卡、交换机、线缆）当你计划向外扩展时\n- 软件与支持（驱动、CUDA 兼容性、企业支持合同）

3) 云端 vs 本地：按波动性与约束选择

• 云端 适合负载波动大、需要迅速启动或想在短时间内试多种 GPU 类型的场景。\n- 本地 通常在利用率稳定、数据驻留要求严格或希望长期成本可预测时更划算——前提是你能可靠运营硬件。

混合策略很常见：本地做基础容量，高峰训练突发到云端。

4) 购买前要问的问题

向供应商（或内部平台团队）询问：

1. 可用的具体 GPU SKU 是哪些，交付周期如何？\n2. 支持的 CUDA/驱动栈 是什么，更新频率如何？\n3. 多 GPU 和多节点扩展如何处理（拓扑、网卡、交换机）？\n4. 满载时的预计功耗与散热要求？\n5. 有哪些故障处理机制（备件、保修条款、RMA 周转）？\n6. 能否提供类似工作负载的参考构建与实际性能？

把这些答案当作产品的一部分：纸面上最好的 GPU 若无法供电、散热或保证数据供给，也不是最佳平台。

权衡、风险与加速计算的下一步

加速计算有明显好处，但不是“免费性能”。围绕 GPU、软件与运维所做的选择可能会形成长期约束——尤其当团队标准化在某个堆栈上时。

厂商锁定与可移植性

CUDA 与 NVIDIA 的库生态能让团队迅速高产，但同样的便利也会降低可移植性。依赖 CUDA 专有内核、内存管理模式或闭源库的代码，迁移到其它加速器可能需要大量改造。

实用做法是把“业务逻辑”与“加速器逻辑”分离：保持模型代码、数据预处理与编排尽可能可移植，把自定义 GPU 内核隔离在干净的接口后面。如果可移植性重要，应及早在至少一种替代路径上验证关键工作负载（即便较慢），以评估真实的切换成本。

供应、成本与能源限制

GPU 供应可能波动，价格随需求变化。总体成本不仅是硬件：电力、散热、机架空间与人员成本也可能占主导。

能源是第一类约束。更快的训练很棒，但如果它让功耗翻倍而不改善结果时间，你可能会付出更高代价。跟踪单位训练成本、每焦耳的 tokens 数和利用率——而不仅仅是“GPU 小时”。

共享 GPU 环境中的安全与隔离

当多个团队共享 GPU 时，基本的安全卫生很重要：强隔离边界、审计访问、打好补丁的驱动以及对模型权重和数据集的谨慎处理。优先使用平台支持的隔离原语（容器/虚拟机、按作业的凭证、网络分段），并把 GPU 节点当作高价值资产来管理。

未来关注点

预计会在三方面持续进步：更高的能效（每瓦性能）、更快的 GPU 与节点间网络，以及更成熟的软件层以减少运维摩擦（剖析、调度、可复现性和更安全的多租户共享）。

总结与下一步

如果你要采用加速计算，从一到两个具有代表性的工作负载开始，测量端到端成本与延迟，并记录可移植性假设。然后构建小而标准的“金色路径”（标准镜像、驱动、监控与访问控制），再逐步向更多团队扩展。

有关规划的更多内容，请参见 /blog/choosing-gpus-and-platforms 与 /blog/scaling-up-and-scaling-out。