GPU与算力基础：显存、带宽、Tensor Core、NVLink、MIG和云GPU
摘要
GPU 选型常被简化成显卡型号和峰值算力比较，但生产系统真正遇到的约束来自容量、带宽、计算吞吐、互联、调度和价格的耦合。本文把 GPU 看成一个受多重上界限制的计算系统：显存决定任务能否启动，带宽决定数据能否喂饱计算单元，Tensor Core 决定低精度矩阵计算能否进入高效路径，NVLink 与 NCCL 决定多卡扩展是否有效，MIG 与云实例形态决定资源能否被稳定共享。文章不以硬件参数罗列为中心，而以瓶颈诊断和成本决策为中心，讨论如何把训练、微调、推理和评测放进同一套算力判断框架。
关键词
GPU 计算；显存容量；显存带宽；Tensor Core；NVLink；MIG；云 GPU；算力评测；推理部署
研究问题与方法
本文关心三个问题：同样是“GPU 不够”，怎样区分容量瓶颈、带宽瓶颈、计算瓶颈和通信瓶颈；同样是更换硬件，何时应该升级单卡，何时应该优化内核、量化模型、改并发策略或重构多卡通信；同样是云 GPU，怎样从规格表回到目标模型、目标上下文和目标 SLA。方法上，本文采用系统分解和工程验收结合的路径：先把一次 AI 任务拆成计算、存储和通信三条主约束，再用容量估算、roofline 思维、端到端 profiling 和业务压测校验假设。
下图不是硬件拓扑装饰，而是本文的判断框架：任何 GPU 方案都要同时通过容量、吞吐、通信和调度四道门，才算真正适合生产负载。
一个实用的性能上界可以写成：
其中 是有效计算量， 是实际可用计算吞吐， 是显存读写量， 是有效显存带宽， 是跨设备通信量， 是有效互联带宽， 是排队、调度、数据准备和服务链路开销。这个公式的意义不是精确预测每一次运行时间，而是提醒团队：峰值 TFLOPS 只覆盖其中一项，不能代替完整工程判断。
大模型、图像生成、视频生成、推荐系统、科学计算和高性能数据分析，经常被统称为“吃算力”的工作。但真正落到工程实践时，只说“需要更多 GPU”远远不够。一个任务跑得慢，可能不是芯片不够快，而是显存装不下、显存带宽不够、CPU 到 GPU 传输太频繁、Tensor Core 没有被用上、多卡通信拖后腿、云 GPU 规格选错，或者多个任务互相抢资源。理解 GPU 与算力基础，不是为了背参数，而是为了能判断瓶颈在哪里，钱应该花在哪里，系统应该怎样设计。
GPU 的核心价值来自大规模并行计算。CPU 更擅长复杂控制流、低延迟响应和通用任务，GPU 更擅长把大量相似计算同时展开。深度学习训练和推理里的矩阵乘法、卷积、注意力计算、归一化、采样和图像处理，都有大量可并行部分，所以能被 GPU 加速。但 GPU 不是魔法盒子，它受显存容量、访存模式、带宽、计算单元、互联、驱动、框架和调度共同影响。只看“有多少 TFLOPS”会误判很多场景。
这篇文章面向中文学习者和工程实践者，系统讲清 GPU 计算中的几个关键概念：显存是什么，为什么带宽很重要，Tensor Core 如何改变矩阵计算，NVLink 为什么能影响多卡训练，MIG 如何把一张数据中心 GPU 切成多个隔离实例，云 GPU 该如何选型。读完后，你不一定能记住每一代芯片参数，但应该能看懂云厂商实例说明、NVIDIA 文档、训练框架日志和推理部署方案，也能更准确地和算法、后端、运维、采购团队讨论算力问题。
引言：GPU 不是更快的 CPU，而是另一种计算组织方式
CPU 和 GPU 的差异，首先不是频率高低，而是设计目标不同。CPU 核心数量较少，但每个核心功能复杂，缓存层次精细，分支预测、乱序执行、系统调用和通用控制能力强，适合处理操作系统、数据库、业务服务、编译、网络请求和复杂逻辑。GPU 核心数量多，单个核心控制能力较弱，但能让成千上万个线程执行相似操作，适合大规模数据并行。
深度学习里的核心计算通常能写成矩阵和张量操作。例如全连接层是矩阵乘法，卷积可以转换或实现为高度并行的乘加，Transformer 里的注意力、前馈网络和投影层也离不开大矩阵计算。GPU 把这些计算拆成很多小块，让大量线程同时处理不同元素。只要数据足够大、计算结构足够规则，GPU 就能把并行性释放出来。
但 GPU 加速有前提。第一，任务必须有足够并行度。如果只是小批量、短序列、零散请求，GPU 可能还没吃满，CPU 调度和数据传输已经占了不少时间。第二，数据要能高效进入 GPU。如果每一步都从 CPU 内存拷贝小块数据到显存，再把结果拷回 CPU，传输开销会抵消计算收益。第三，计算要匹配硬件路径。如果模型使用的数据类型、算子布局或框架配置无法触发高效内核，标称算力再高也用不上。
GPU 编程里经常提到 kernel。它不是操作系统内核，而是在 GPU 上执行的一段并行函数。深度学习框架会把矩阵乘法、归一化、激活函数、采样等操作变成一个个 GPU kernel。一次训练或推理任务，通常是 CPU 负责调度和准备，GPU 负责执行大量 kernel。性能优化的一大部分，就是减少不必要的 kernel 启动、让每个 kernel 更高效、把多个小操作融合成更少的操作。
理解 GPU 时，可以把一次任务拆成三层。第一层是计算：有多少乘法、加法、矩阵乘法、卷积和注意力。第二层是存储：这些计算需要从显存读多少数据，写多少结果，中间状态能不能放得下。第三层是通信：数据是否要在 CPU、单卡、多卡、多机之间移动。很多工程问题不是计算层单独决定的，而是计算、存储和通信共同决定的。
显存容量：能不能跑起来，先看装不装得下
显存是 GPU 自己使用的高速内存。模型参数、输入数据、中间激活、梯度、优化器状态、KV cache、临时工作区和框架缓存，很多都会占用显存。显存容量决定一个任务能不能直接跑起来，也影响 batch size、上下文长度、并发量和模型切分方式。很多人第一次遇到 GPU 问题，看到的就是显存不足。
以深度学习训练为例，显存通常被几类对象占用。第一是模型参数，也就是神经网络权重。第二是前向传播产生的激活，反向传播需要用它们计算梯度。第三是梯度本身。第四是优化器状态，例如 Adam 常见的一阶、二阶动量。第五是数据 batch、临时张量、通信缓冲区和框架保留空间。训练同一个模型时，显存占用往往远大于模型文件本身。
推理显存结构又不同。推理一般不需要保存梯度和优化器状态，但大语言模型会大量使用 KV cache。KV cache 保存历史 token 的注意力键值，能避免每生成一个新 token 都重新计算全部历史内容。上下文越长，并发请求越多，KV cache 越大。一个模型参数装得下，不代表长上下文高并发推理也装得下。很多推理服务的瓶颈不是参数，而是 KV cache。
数据类型会显著影响显存。FP32 每个数 4 字节，FP16 和 BF16 每个数 2 字节，INT8 每个数 1 字节，INT4 约半字节。训练常用混合精度，把部分计算放在 FP16 或 BF16 上，同时保留必要的高精度累积。推理可以用 FP16、BF16、INT8、INT4 等量化方案降低显存占用。量化节省显存和带宽，但可能带来精度损失、算子支持差异和额外校准工作。
显存容量还决定模型部署方式。小模型可以单卡部署；中等模型可能需要张量并行或流水并行；大模型需要多卡甚至多机，把参数、激活或 KV cache 分布到多个 GPU 上。分布式部署不是免费午餐，显存压力下降后，通信压力会上升。如果多卡互联很弱，模型虽然能装下，吞吐和延迟可能仍然不理想。
工程上估算显存时，不要只看模型参数大小。训练要考虑参数、梯度、优化器、激活和临时空间；推理要考虑参数、KV cache、batch、上下文长度、并发、采样和框架缓存。很多部署事故来自“模型文件只有几十 GB，所以一张 80GB 卡应该够”，但实际运行时中间状态和并发缓存把显存打满。
显存不足有几类常见解决方式。训练可以降低 batch size、使用梯度累积、开启混合精度、激活检查点、ZeRO、参数分片、优化器状态分片和序列并行。推理可以降低并发、缩短上下文、使用量化、分页 KV cache、张量并行、专家并行或模型卸载。每种方法都有代价：降低 batch 可能影响吞吐，量化可能影响质量，分片会增加通信，卸载会增加延迟。
显存带宽：装得下不等于喂得饱
显存容量回答“能不能装下”，显存带宽回答“能不能快速读写”。GPU 的计算单元再强，也需要不断从显存读取输入、权重和中间数据，再把结果写回显存。如果数据供应跟不上，计算单元会等待，算力利用率下降。很多任务看起来在用高端 GPU，实际被带宽卡住。
带宽可以理解为单位时间内能搬运多少数据。现代数据中心 GPU 使用 HBM 这类高带宽显存，带宽远高于普通服务器内存。H100、A100 等卡的显存带宽，是它们适合大模型和高性能计算的重要原因之一。对许多深度学习算子来说，性能上限由计算吞吐和内存带宽共同决定，哪边先达到瓶颈，哪边就限制整体速度。
一个常用判断方法是算术强度，也就是每读取一字节数据能做多少计算。如果一个算子读写很多数据，但计算很少，例如逐元素加法、某些归一化和简单变换，它更可能受带宽限制。如果一个算子对同一批数据做大量乘加，例如大矩阵乘法，它更可能受计算吞吐限制。实际模型中两类算子都有，所以优化不能只盯着矩阵乘法。
访存模式也很重要。GPU 喜欢连续、合并、对齐的数据访问。如果线程访问分散地址，显存事务变多，缓存命中变差，实际带宽会低于标称值。深度学习框架和高性能库会为常见布局做优化，例如 NHWC、NCHW、行主序、列主序、对齐到特定边界。模型代码里频繁 transpose、view 后非连续、切片拷贝和小张量拼接，都可能破坏访存效率。
显存层次不止全局显存。CUDA 编程模型里还有寄存器、共享内存、常量内存、本地内存、L2 缓存等层次。寄存器最快但数量有限，共享内存在一个线程块内共享，适合把重复使用的数据暂存起来。高性能矩阵乘法通常会把数据分块加载到更近的存储层，尽量让每个数据元素被多次使用，减少对全局显存的压力。
带宽还影响推理服务。大语言模型推理里，生成阶段常常是逐 token 进行。每生成一个 token，都要读取大量权重和 KV cache。batch 很小时，计算单元可能吃不满，反而由内存带宽和调度开销主导。提高并发、连续批处理、KV cache 管理和高效 attention kernel，都是为了让 GPU 在带宽和计算之间取得更好平衡。
判断带宽瓶颈不能只看 GPU 利用率。监控里 GPU utilization 高，不一定代表 Tensor Core 高效工作；显存占用高，也不代表带宽饱和。更可靠的方式是结合框架 profiler、NVIDIA 工具、算子耗时、显存带宽利用、SM 利用率、Tensor Core 利用率和 batch 变化实验。把 batch 翻倍后吞吐几乎不变，可能是计算或带宽已满；把上下文加长后延迟陡增，可能是 KV cache 和 attention 成本上升。
CUDA：GPU 软件栈的基础入口
CUDA 是 NVIDIA GPU 上最重要的软件平台之一。它提供编程模型、运行时、驱动接口、编译工具、数学库和性能工具。即使很多工程师不直接写 CUDA C++，只使用 PyTorch、TensorFlow、JAX、vLLM、TensorRT 或 RAPIDS，底层仍然大量依赖 CUDA、cuBLAS、cuDNN、NCCL 等库。
CUDA 的基本执行模型包括 grid、block 和 thread。一个 kernel 会启动一个 grid，grid 里有很多 block，每个 block 里有很多 thread。block 是调度和共享内存使用的重要单位，同一个 block 内线程可以通过共享内存协作。thread 负责处理具体数据元素。深度学习框架会把张量操作映射到这种并行结构上。
CUDA 程序的性能来自三个方向。第一是足够并行度，让 GPU 上有足够多的线程和任务可执行。第二是高效访存，让全局显存访问合并、减少不必要拷贝、提高缓存和共享内存复用。第三是使用高性能库和硬件特性，例如 cuBLAS 的 GEMM、cuDNN 的卷积、Tensor Core 的矩阵乘加、NCCL 的多卡通信。
对应用开发者来说，理解 CUDA 不一定意味着自己写 kernel，但要知道框架并不是永远自动最优。一个看似简单的模型结构，可能因为张量形状不友好、batch 太小、算子不融合、动态形状太多、数据类型不匹配，导致无法调用最优库。生产推理里经常会把模型导出到 TensorRT 或使用专门推理引擎，就是为了让计算图更贴近 GPU 高效执行路径。
CUDA 版本、驱动版本和框架版本也会影响可用能力。新 GPU 往往需要较新的驱动和 CUDA 支持；新数据类型、新 Tensor Core 路径、新通信特性也需要软件栈配合。云 GPU 环境里，选择镜像时要确认驱动、CUDA、cuDNN、NCCL、PyTorch 或 TensorFlow 版本是否匹配，否则硬件买对了，软件路径却跑不起来。
Tensor Core：为什么矩阵计算速度突然变得很高
Tensor Core 是 NVIDIA 从 Volta 架构开始引入并持续演进的专用矩阵计算单元。它不是普通 CUDA core 的简单堆叠，而是面向矩阵乘加设计的硬件路径。深度学习最核心的操作之一是矩阵乘法，Tensor Core 能在较低精度输入和较高精度累积之间高效完成矩阵乘加，从而显著提升训练和推理吞吐。
传统 FP32 计算精度高，但吞吐和显存压力更大。深度学习很多场景不需要每一步都用 FP32 输入。混合精度训练会用 FP16、BF16、TF32、FP8 等格式参与矩阵计算，并在合适位置使用 FP32 累积或维护主权重。Tensor Core 正是为这类工作负载设计的。它让模型训练和推理可以在质量可控的前提下获得更高吞吐。
不同 GPU 架构支持的数据类型不同。Volta 重点支持 FP16 Tensor Core，Ampere 引入和强化 TF32、BF16、稀疏性等能力，Hopper 进一步支持 FP8 Transformer Engine 等路径。工程实践里，不能只说“打开 Tensor Core”，还要看模型、框架、数据类型、张量尺寸和算子是否满足条件。某些形状不对齐，某些算子不支持，某些层仍然会走普通路径。
TF32 是很多人容易忽略的格式。它在 Ampere 之后常用于加速 FP32 风格的矩阵乘法，保留 FP32 的指数范围，同时使用较短尾数参与 Tensor Core 计算。对很多深度学习训练来说，TF32 能在较少代码改动下提升矩阵乘法性能。是否启用、是否允许精度差异，需要根据训练稳定性和结果要求决定。
BF16 在大模型训练中很常见。它和 FP16 一样占 2 字节，但指数范围接近 FP32，数值稳定性通常更好。很多大模型训练优先使用 BF16，是因为它能减少溢出和 loss scaling 的复杂度。硬件是否高效支持 BF16，是选择 GPU 时的重要指标。
FP8 是新一代大模型训练和推理里的重要方向。FP8 可以进一步降低显存占用和带宽压力，提高 Tensor Core 吞吐，但它对缩放、校准和框架支持要求更高。Hopper 架构里的 Transformer Engine 就是为了让 Transformer 模型更好地使用 FP8 和混合精度路径。是否采用 FP8，不应只看速度，还要看模型质量、训练稳定性、工具链成熟度和团队经验。
Tensor Core 的价值不是所有算子都变快，而是把核心矩阵乘法大幅加速。模型整体速度还取决于非矩阵算子、数据加载、显存带宽、通信、调度和后处理。很多推理场景里，GEMM 很快，但 attention、KV cache、采样、tokenizer、请求调度和网络返回也会影响端到端延迟。
想让 Tensor Core 发挥作用，常见做法包括使用自动混合精度、选择支持 Tensor Core 的数据类型、让矩阵尺寸对齐、使用成熟库、避免不必要的类型转换、关注框架日志和 profiler。对普通应用团队来说，优先使用 PyTorch AMP、TensorRT、cuBLASLt、Transformer Engine、vLLM 等成熟路径，通常比自己手写底层 kernel 更稳。
算力指标：TFLOPS 重要，但不能单独解释性能
云厂商和硬件厂商常用 TFLOPS、TOPS、显存容量、显存带宽、TDP、NVLink 带宽等参数描述 GPU。TFLOPS 表示每秒万亿次浮点运算，通常按 FP32、TF32、FP16、BF16、FP8 等不同精度分别给出。TOPS 常用于整数或低精度计算。数字越大，理论计算吞吐越高，但实际应用不一定线性变快。
首先，标称算力通常是理想条件下的峰值。模型必须使用对应数据类型、对应算子和足够大的矩阵，才可能接近峰值。如果任务是小 batch、动态形状、频繁控制流、访存不连续、算子碎片化，实际吞吐会远低于标称值。很多线上推理服务追求的是低延迟和稳定并发，不是单次大矩阵峰值。
其次，不同精度的峰值不能直接比较质量。FP8 峰值很高，但不是所有模型都能无损使用 FP8。INT4 推理显存省，但量化质量和算子支持要验证。企业选型时不能只看“某精度峰值最高”，还要看自己的模型是否支持这种精度，结果是否可接受，框架是否成熟，监控和回滚是否完备。
再次，显存容量和带宽可能比峰值更重要。一个模型如果需要 80GB 显存，40GB 卡的 FP16 算力再高也装不下；一个任务如果受带宽限制，计算峰值翻倍也可能提升有限。多卡训练还要看卡间互联和集群网络。单卡很强，但卡间通信弱，扩展到八卡时效率可能不高。
最后，端到端性能还包含 CPU、存储、网络和服务框架。训练时数据加载慢，会让 GPU 等数据；推理时 tokenizer、队列调度、HTTP 框架、后处理和流式返回都会影响用户感知。GPU 是核心，但不是唯一组件。生产系统要看完整链路的吞吐、延迟、稳定性和成本。
因此阅读规格表时，可以按顺序看六件事：显存容量是否够，目标精度下 Tensor Core 是否支持，显存带宽是否适合任务，多卡互联是否满足扩展，云实例 CPU 和网络是否匹配，软件栈是否支持目标框架。TFLOPS 是重要指标，但只是其中之一。
NVLink：多卡之间为什么需要高速互联
单张 GPU 有容量和算力上限。训练更大模型、提高 batch、服务更高并发时，经常需要多张 GPU 协同工作。多卡协同的难点不只是把任务分出去，还要在 GPU 之间移动参数、梯度、激活或 KV cache。卡间通信慢，训练和推理都会被拖住。
PCIe 是常见通用互联，CPU、网卡、存储和 GPU 都可以通过 PCIe 连接。它通用性强，但相对 GPU 间专用互联，带宽和拓扑可能成为瓶颈。NVLink 是 NVIDIA 面向 GPU 高速互联设计的技术，能让 GPU 之间以更高带宽通信。NVSwitch 则进一步支持多 GPU 之间形成更高带宽、更灵活的互联结构，常见于 DGX 和高端云 GPU 实例。
多卡训练里，数据并行需要在每一步同步梯度。模型越大，梯度同步越重；卡越多，通信拓扑越关键。NCCL 会根据硬件拓扑选择 ring、tree 等通信算法，但底层链路仍然决定上限。NVLink 和 NVSwitch 能降低多卡同步成本，提高扩展效率。没有高效互联时，增加 GPU 数量可能出现“卡数翻倍，速度只提升一点”的情况。
模型并行更依赖卡间通信。张量并行把一个矩阵运算切到多张卡上，中间结果需要频繁交换；流水并行把模型层分到不同卡上，激活在阶段之间传递；专家并行会根据 token 路由到不同专家，也需要跨卡通信。互联越快，多卡切分的代价越低。互联越弱，工程上越要减少跨卡边界和通信频率。
推理也会受到 NVLink 影响。大模型如果必须跨多张卡部署，每个 token 的生成可能涉及多卡同步。低延迟服务尤其怕通信抖动。对小模型或单卡能装下的模型，NVLink 影响没那么大；对必须跨卡的模型，NVLink、NVSwitch 和实例拓扑会直接影响吞吐和延迟。
云 GPU 选型时，要看“几张卡”之外的拓扑。两台实例都写着 8 张 GPU，但一台可能有 NVSwitch，另一台可能只是 PCIe 拓扑；一台网络适合多机训练，另一台更适合单机推理。训练大模型时，多机之间还要看 InfiniBand、RoCE、EFA 或云厂商专用网络。卡间、机间、存储三类带宽都要看。
工程上可以通过拓扑工具、NCCL 测试和框架日志确认互联。不要只相信实例名称。实际环境里，驱动、容器、虚拟化、拓扑映射和云平台配置都可能影响可见链路。上线前做一次 all-reduce 带宽测试，往往比纸面参数更有说服力。
MIG：把一张大 GPU 切给多个任务
MIG 是 Multi-Instance GPU 的缩写，是 NVIDIA 在部分数据中心 GPU 上提供的硬件级分区能力。它可以把一张支持 MIG 的 GPU 切分成多个 GPU 实例，每个实例拥有独立的一部分计算资源、显存、缓存和带宽资源。这样多个用户或任务可以在同一张物理 GPU 上运行，同时获得比普通共享更强的隔离。
MIG 适合几类场景。第一是推理服务。多个小模型或多个低到中等负载服务，不一定需要整张 A100 或 H100，用 MIG 可以提高资源利用率。第二是开发和测试。多个工程师需要稳定 GPU 环境时，MIG 可以减少互相抢资源。第三是多租户平台。不同租户使用独立 GPU 实例，比进程级共享更容易解释资源边界。第四是批处理任务。许多小任务可以并行占用不同 MIG 实例。
MIG 的核心价值是隔离和确定性。普通多进程共享同一张 GPU 时，一个任务占满显存或计算资源，可能影响其他任务。MIG 把资源切成固定形状，每个实例有自己的显存容量和计算份额。这样一个实例里的任务不容易把另一个实例挤掉。对企业平台来说，这种确定性有助于做配额、计费和服务等级。
但 MIG 不是万能方案。第一，它只在支持的 GPU 和驱动环境中可用，不同型号支持的切分形状不同。第二，MIG 实例之间不能像完整 GPU 那样自由共享整卡资源，单个任务如果需要更大显存或更多计算，就必须分配更大实例或整卡。第三，某些多卡通信、图形能力或特定软件路径在 MIG 下有额外限制。第四，MIG 的资源形状是离散的，不能按任意百分比切分。
MIG 和 Kubernetes 经常一起使用。NVIDIA GPU Operator 和 device plugin 可以把 MIG 实例暴露给容器调度系统，让 Pod 请求特定大小的 GPU 资源。这样平台可以把整张 GPU、MIG 实例、时间片共享等方式结合起来。生产环境要提前设计资源命名、调度策略、监控指标和租户配额，避免用户不知道自己拿到的是整卡还是 MIG 分区。
MIG 和 MPS、时间片共享不同。MPS 更偏向让多个 CUDA 进程共享 GPU 执行资源，提高并发利用；时间片共享是调度层把多个任务轮流放到 GPU 上；MIG 是硬件级分区。它们解决的问题不同。需要强隔离和确定资源时，MIG 更合适；需要弹性共享和提高吞吐时，MPS 或推理服务的连续批处理可能更合适。
选择 MIG 时，要先看任务画像。一个 7B 量化模型低并发推理，可能适合小实例；一个 70B 模型或长上下文服务，往往需要整卡或多卡；训练任务通常更需要完整 GPU 和高速互联。不要为了提高利用率，把需要整卡性能的任务硬塞进 MIG，也不要让轻量任务长期独占整卡。
云 GPU：不是买卡，而是买完整运行环境
云 GPU 给团队带来弹性。无需先采购服务器、上架、布线、维护机房，就能按需获得 A10、L4、A100、H100、H200、B 系列等不同级别 GPU。对训练试验、短期高峰、推理扩容和多地区部署，云 GPU 非常有价值。但云 GPU 不是简单“租一张卡”，它包含实例规格、CPU、内存、本地盘、网络、镜像、配额、价格和可用区供应。
选云 GPU 第一看任务类型。训练大模型需要显存、Tensor Core、卡间互联和机间网络；微调和实验可能更看显存与成本平衡；推理服务看单请求延迟、并发吞吐、KV cache、冷启动、弹性扩缩和稳定性；图像视频生成看显存、算子支持和批处理；传统机器学习和数据分析可能看 CPU、内存、GPU 数量和数据读取。
第二看实例整体配置。很多人只看 GPU 型号，忽略 CPU 和内存。数据预处理、tokenizer、请求调度、压缩解压、特征工程和存储读取都需要 CPU。CPU 太弱会让 GPU 等待。内存太小会导致数据加载、缓存和多进程服务受限。本地 NVMe 对训练数据缓存和模型加载很重要。网络带宽影响分布式训练、对象存储读取和服务流量。
第三看 GPU 拓扑。单卡推理可以选择性价比更高的 L4、A10、L40S 等，具体看模型和量化方案。多卡训练要关注 NVLink、NVSwitch、实例内拓扑和跨机网络。AWS P5、Google Cloud A3、Azure ND 系列等高端实例，都围绕多卡高带宽互联和高速网络设计。它们适合大规模训练，但价格也高，不应拿来跑轻量任务。
第四看供应和配额。高端 GPU 经常需要申请配额，热门区域可能短缺。生产服务不能只依赖一个区域和一种实例。训练任务可以排队，线上推理需要容量规划和降级策略。云 GPU 的真实成本还包括空闲时间、镜像存储、数据传输、对象存储请求、负载均衡和日志监控。
第五看软件镜像。云厂商通常提供深度学习镜像、NVIDIA 驱动、CUDA、cuDNN、NCCL 和框架预装环境。自定义镜像要维护版本兼容。容器化可以减少环境漂移，但宿主机驱动和容器 CUDA 运行时仍要匹配。使用 Kubernetes 时，还要处理 GPU Operator、device plugin、节点池、污点容忍、资源请求和监控。
云 GPU 的成本管理要细到任务。训练实验应有自动关机和预算提醒；推理服务应有自动扩缩、批处理和模型分层；临时开发环境应有过期回收；大规模训练应提前做小规模吞吐测试，确认扩展效率后再放大。最浪费的不是昂贵 GPU 本身，而是昂贵 GPU 在等待数据、等待人、等待错误重试。
训练、微调和推理对 GPU 的要求不同
训练从零开始优化模型参数，通常最吃显存、计算和通信。大模型训练需要保存参数、梯度、优化器状态和大量激活，还要进行多卡多机同步。训练关注吞吐、稳定性、扩展效率和恢复能力。高端 GPU、NVLink、NVSwitch、高速网络和并行训练框架在这里最重要。
微调介于训练和推理之间。全量微调仍然需要较大显存和优化器状态；LoRA、QLoRA 等参数高效微调可以大幅降低显存压力，让中小团队用更少 GPU 完成适配。微调要关注基础模型大小、序列长度、batch、优化器、量化、检查点保存和评测流程。很多业务微调不需要最大集群，但需要稳定可复现。
推理目标是把模型能力稳定服务给用户。它关注延迟、吞吐、并发、上下文长度、冷启动、成本和服务等级。推理通常不需要梯度，但需要高效 KV cache、批处理、请求调度、量化和模型路由。小模型可以单卡高并发，大模型可能多卡部署。长上下文服务会显著增加显存和带宽压力。
在线推理和离线批处理也不同。在线推理更看首 token 延迟、每 token 延迟、排队时间和流式体验；离线批处理更看总吞吐和单位成本。在线服务不能无限等 batch 凑齐，离线任务可以更充分利用 GPU。一个配置在线表现好，不代表离线成本最低。
RAG 和智能体类应用还有额外开销。向量检索、重排、工具调用、代码执行、网页抓取、文档解析和权限过滤，可能发生在模型调用前后。GPU 只负责其中一部分。优化这类应用时，不要把所有延迟归咎于模型推理。很多时候，检索、权限、网络和外部工具才是用户等待的主要来源。
因此选 GPU 前，要先写清工作负载：模型规模、参数精度、上下文长度、batch、并发、训练还是推理、是否多卡、是否多机、可接受延迟、可接受成本、数据来源、上线区域。没有工作负载画像，GPU 选型只能靠猜。
常见瓶颈如何判断
第一类瓶颈是显存不足。表现是任务直接报显存错误，或 batch 稍微增加就失败，或推理并发上升后频繁驱逐 KV cache。解决方向是降低 batch、缩短上下文、量化、分片、激活检查点、优化缓存管理或换更大显存 GPU。显存不足通常比较直观，但要区分参数占用、激活占用和缓存占用。
第二类瓶颈是计算单元没吃满。表现是 GPU 利用率低、Tensor Core 利用不足、kernel 很碎、batch 小、CPU 调度占比高。解决方向是增加 batch、合并请求、算子融合、使用高效推理引擎、减少动态形状、选择合适数据类型。推理服务中，连续批处理和分页 KV cache 常用于提高利用率。
第三类瓶颈是显存带宽。表现是某些逐元素算子、归一化、拷贝和 attention 相关操作耗时高，计算峰值利用不高但带宽压力大。解决方向是减少不必要读写、使用融合 kernel、改善布局、使用 FlashAttention 等高效实现、降低数据精度、减少中间张量。
第四类瓶颈是卡间通信。表现是单卡很快，多卡扩展效率差，all-reduce 或通信等待时间高。解决方向是检查 NVLink/NVSwitch、NCCL 拓扑、并行策略、梯度累积、通信重叠、网络配置和实例类型。多机训练还要看网卡、交换网络和存储读取。
第五类瓶颈是数据输入。表现是 GPU 周期性等待，数据加载进程 CPU 占用高，存储读取慢，远程对象存储延迟大。解决方向是本地缓存、数据预处理、并行 dataloader、减少小文件、使用高吞吐存储、异步加载和预取。训练集越大，数据管道越重要。
第六类瓶颈是服务链路。表现是模型推理耗时不高，但端到端接口慢。原因可能是 tokenizer、权限检查、检索、重排、网络、排队、后处理、日志、流式输出或客户端。解决方向是做端到端追踪，把延迟拆成阶段，而不是只看 GPU 指标。
从学习到生产的实践路线
学习 GPU 与算力，建议按从低到高的路线。第一步，理解显存、带宽、数据类型和矩阵乘法，能读懂基本规格表。第二步，跑通一个 PyTorch 模型训练和推理，观察显存占用、batch 变化和混合精度影响。第三步，使用 profiler 看算子耗时，理解哪些操作在 GPU 上执行，哪些留在 CPU。第四步，尝试 TensorRT、vLLM 或其他推理引擎，比较端到端吞吐和延迟。第五步，做多卡实验，观察 NVLink、NCCL 和并行策略对扩展效率的影响。
生产环境里，GPU 管理要有明确规范。不同任务使用不同节点池或资源队列；训练、推理、开发、评测不要混在同一池里无规则抢资源；昂贵 GPU 要有自动回收；云 GPU 要有预算、配额和标签；模型服务要有容量测试、限流、降级和监控；多租户平台要考虑 MIG、队列、配额和审计。
团队协作中，算法同学、平台同学和业务同学对“慢”和“贵”的理解可能不同。算法关心模型效果和训练速度，平台关心资源利用和稳定性，业务关心响应时间和成本。统一语言很重要：显存够不够，吞吐是多少，延迟分位是多少，单请求成本是多少，GPU 利用率和 Tensor Core 利用率是多少，多卡扩展效率是多少。指标清楚，讨论才不会变成感觉。
采购和云选型也要基于实测。不同模型、不同框架、不同精度和不同上下文长度，对 GPU 的偏好不一样。真正可靠的做法，是用目标模型和目标请求形态，在候选实例上跑基准测试：单卡吞吐、并发延迟、显存占用、长上下文表现、多卡扩展、冷启动、失败恢复和单位成本。纸面参数用于初筛，真实测试用于决策。
最后要记住，GPU 算力不是越多越好，而是越匹配越好。显存、带宽、Tensor Core、NVLink、MIG 和云 GPU，本质上都是为了让任务在合适成本下稳定完成。理解这些基础概念，能帮助你少买错卡、少租错实例、少做无效优化，也能让 AI 系统从演示走向真正可运行、可扩展、可维护的工程。
一个容量估算的思路
很多团队选 GPU 时，最需要的不是精确到每个字节的公式，而是能快速判断方案是否离谱。容量估算可以先从参数开始。假设一个模型有 70B 参数，使用 FP16 或 BF16 保存权重，参数本身大约需要 140GB 显存。这个数字已经超过单张 80GB GPU，所以不做量化或分片时，单卡推理不现实。若使用 4bit 量化，权重体积会明显下降，但还要额外考虑量化元数据、运行时缓存和算子支持。
推理还要估算 KV cache。KV cache 和层数、隐藏维度、注意力头、上下文长度、并发请求数、数据类型有关。上下文从 4K 增加到 32K，不只是输入变长，缓存也会大幅增加。并发从 1 路增加到 32 路，缓存压力也会跟着上升。很多线上大模型服务在低并发时显存充足，一到业务高峰就被 KV cache 填满，根源就是只估算了参数，没有估算服务状态。
训练容量估算更复杂。全量训练或全量微调中，参数、梯度、优化器状态和激活都会占显存。以 Adam 为例，优化器状态通常会让显存远高于参数本体。再加上反向传播需要保存激活，同一个模型训练显存可能是推理显存的数倍。使用 LoRA 或 QLoRA 时，需要训练的参数少得多，显存压力下降，但基础模型权重、激活、序列长度和 batch 仍然重要。
估算还要给临时空间留余量。深度学习框架会为 cuDNN、cuBLAS、attention kernel、通信缓冲和内存池保留空间。某些算子会根据输入形状选择需要额外 workspace 的算法。生产环境如果把显存预算算到刚好贴边，升级框架、调整 batch、打开更长上下文或增加监控后，都可能触发显存错误。实践中常给显存留出一定安全余量，而不是追求理论满载。
容量估算可以形成一个简单流程。先看模型权重是否装得下，再看训练或推理需要哪些额外状态，再看目标上下文和并发，再看是否需要多卡分片，最后用真实框架跑一次最小可复现实验。这个流程比直接问“某模型要几张卡”更可靠。因为同一个模型，FP16、BF16、INT8、INT4、不同推理引擎、不同上下文和不同并发，答案都可能不同。
GPU 集群不只是多插几张卡
当任务从单卡走向集群，复杂度会上一个台阶。单卡问题主要是显存、带宽和算子效率；多卡问题还要处理通信、调度、故障、存储和作业管理。很多团队第一次搭 GPU 集群时，把注意力放在 GPU 型号上，却忽略网络、供电、散热、驱动一致性和存储吞吐。结果是卡买得很贵，训练却经常等待、掉线或扩展效率很差。
多机训练需要高速网络。单机八卡内部可以靠 NVLink 或 NVSwitch 通信，多机之间则要通过 InfiniBand、RoCE、EFA 或云厂商提供的高性能网络。大模型训练里的梯度同步、参数分片、激活传递和 checkpoint 保存，都可能产生巨大流量。网络抖动、交换机拥塞、网卡配置错误和 NCCL 参数不匹配，都会让训练速度下降甚至中断。
存储也是集群瓶颈。训练数据如果是大量小文件，从对象存储或网络文件系统逐个读取，会让 GPU 等数据。更稳的做法是把数据预处理成适合顺序读取的格式，使用本地 NVMe 缓存，减少小文件随机访问，并让数据加载和训练计算重叠。模型 checkpoint 也要规划好，保存过频会占用网络和存储，保存过少又会增加故障恢复成本。
调度层要区分任务优先级。开发调试、短实验、长训练、在线推理和批量推理，不应无差别抢同一批 GPU。在线推理需要稳定资源和低延迟，长训练需要连续占用和故障恢复，开发任务需要快速启动和自动回收。Kubernetes、Slurm 或云厂商训练平台都可以承载 GPU 调度，但关键是资源队列、配额、优先级和监控要符合组织工作方式。
集群还要重视可观测性。只看 GPU 是否在线不够，要看显存占用、功耗、温度、SM 利用率、Tensor Core 利用率、显存带宽、PCIe 或 NVLink 吞吐、NCCL 错误、网络重传、磁盘吞吐、作业等待时间和失败原因。没有这些指标，团队只能凭感觉判断“是不是卡不够”。有了完整观测，才能知道是算力不足、数据慢、通信慢，还是任务调度不合理。
故障恢复是生产集群必须面对的问题。GPU 训练任务可能运行数小时到数周，期间驱动、网络、节点、存储和代码都可能出错。训练框架要支持 checkpoint 和恢复，平台要能标记坏卡、隔离异常节点、重试失败作业，并保留足够日志用于复盘。云 GPU 也不是永远稳定，抢占式实例、容量回收和底层维护都需要应对策略。
不同团队如何共用 GPU
企业内部 GPU 往往由多个团队共用。算法团队要训练，产品团队要推理，数据团队要跑分析，研发团队要调试，业务团队要试用。没有资源治理时，最常见的结果是轻量任务长期占着大卡，紧急任务排不到资源，实验结束忘记释放，线上推理和离线训练互相影响。
共用 GPU 的第一原则是资源分池。线上推理池、训练池、开发池、评测池可以分开管理。线上推理池更重视稳定和容量水位，训练池更重视吞吐和排队效率，开发池更重视低门槛和自动回收。把所有任务混在一起，短期看简单，长期一定会增加冲突。
第二原则是配额和预算。团队可以按月、按项目或按空间获得 GPU 小时、云费用或模型调用预算。高端 GPU 要有申请和审批，低端或 MIG 资源可以更自由。配额不是为了阻止使用，而是让资源需求显性化，让管理者知道哪些项目真正消耗算力，哪些任务需要优化。
第三原则是资源形态匹配。轻量推理、开发 notebook 和小实验可以使用 MIG、小规格 GPU 或时间片共享；长时间训练和跨卡模型应使用完整 GPU 和稳定互联；高并发推理应使用专门推理引擎和弹性节点。把 7B 小模型低并发服务放在整张 H100 上长期运行，通常不是好成本；把需要多卡通信的大训练拆到弱互联实例上，也不是好效率。
第四原则是自动回收。开发环境、实验任务、临时 notebook、测试推理服务都应有过期时间。无人使用的 GPU 节点自动释放，云实例自动关机，长时间空闲任务提醒负责人。GPU 成本高，手工回收很难长期坚持，平台必须提供默认机制。
第五原则是透明账单。用户如果看不到自己的任务占了多少资源，就很难主动优化。平台应展示任务使用的 GPU 型号、运行时长、显存峰值、平均利用率、费用估算和排队时间。团队负责人看到月度消耗后，才能决定是优化模型、调整实例、购买资源，还是改变使用流程。
参考资料
- NVIDIA CUDA C Programming Guide：https://docs.nvidia.com/cuda/cuda-c-programming-guide/
- NVIDIA CUDA C Best Practices Guide：https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/
- NVIDIA CUDA C Programming Guide，WMMA 与 Tensor Core 相关章节：https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#wmma
- NVIDIA Deep Learning Performance，Mixed Precision Training：https://docs.nvidia.com/deeplearning/performance/mixed-precision-training/
- NVIDIA Multi-Instance GPU User Guide：https://docs.nvidia.com/datacenter/tesla/mig-user-guide/
- NVIDIA GPU Operator 文档，MIG 支持：https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-operator-mig.html
- NVIDIA NVLink and NVSwitch System Documentation：https://docs.nvidia.com/nvlink/
- NVIDIA H100 Tensor Core GPU Architecture Whitepaper：https://resources.nvidia.com/en-us-tensor-core/nvidia-hopper-architecture
- NVIDIA A100 Tensor Core GPU Architecture Whitepaper：https://resources.nvidia.com/en-us-tensor-core/nvidia-ampere-architecture-whitepaper
- AWS EC2 Accelerated Computing Instances：https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/accelerated-computing-instances.html
- Google Cloud GPU platforms：https://cloud.google.com/compute/docs/gpus
- Microsoft Azure GPU optimized virtual machine sizes：https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/gpu-accelerated
- NVIDIA NCCL Documentation：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/
- NVIDIA Transformer Engine Documentation：https://docs.nvidia.com/deeplearning/transformer-engine/user-guide/