AI算力资源入门：芯片、显存、网络、存储和集群
先讲一个很多团队都真实遇到过的场景。
公司想做一个内部AI助手，工程师在自己的机器上把模型接好，输入一个问题，几秒钟就返回了答案。演示很顺利，看起来只差把它正式部署上线。于是下一个问题很自然地冒了出来：真要上线，得配什么样的GPU？
可等服务真的开放给几十个同事一起用，麻烦却不全出在显卡上：
每天早上第一次调用，要等很久才有反应；
文档一长，就弹出"显存不足"；
大家扎堆提问时，快的时候一秒出结果，慢的时候要干等好几秒；
后来加了几张GPU，可监控里还是能看到它们隔一会儿就停下来，像在等什么。
这些看似零散的现象，其实都在说同一件事：算力从来不是某一张卡的单项能力，而是模型和数据从存储出发，途经内存、显存、计算单元和网络，再把结果送回来的一整条工作链。 这条链上只要有一环跟不上，整件事就会卡在那里——哪怕GPU本身还闲着。
所以这篇文章不打算比较具体的显卡型号，而是想先带你把这条链上的每个角色认全。把角色认清楚了，你之后再去学算力，才知道自己究竟在学什么、每个概念又落在链条的哪个位置。
灶台再好，也撑不起一整家餐厅
要看清这些角色之间的关系，把AI系统想象成一家忙碌的餐厅会很好用：
真正掌勺、负责烹饪的灶台，是GPU或其他加速芯片；
灶台旁边那张操作台，是显存——这一刻要下锅的食材，必须先摆到台面上；
后厨的仓库是存储，完整的数据集和模型都存放在这里；
而在仓库、灶台和各个工位之间来回跑动的通道，就是网络。
只接几桌客人的时候，最抢眼的当然是灶台火力。可一到午市高峰，问题立刻换了模样：食材没及时端上来，厨师只能空等；操作台太小，一道大菜根本铺不开；几个厨师挤在一条窄通道里，谁也过不去。等订单再多，还得有人统一安排——哪个工位接哪一桌、谁先谁后——这就对应集群里的资源调度。
这个类比想说的，不是"某个硬件到底像什么"，而是一个更要紧的整体观念：计算、存放和搬运，必须彼此配合。 GPU决定了菜能炒多快，但数据能不能按时到位、多张GPU能不能拧成一股绳，是其他资源说了算。
一次prompt请求背后做了什么
用户点开AI助手的时候，模型并不是一直"待"在GPU里等着他。它的权重平时安静地躺在本地磁盘、共享文件系统或者对象存储里。服务启动的那一刻，系统得先把这些权重读出来，解析、初始化，再把计算真正用得上的部分搬进GPU显存——你看，问题还没开始回答，存储、CPU内存和数据传输就已经先忙起来了。
请求进来之后，接力棒交到CPU手上：它接住这段文字，完成分词、排队和批次组织，把人写的句子翻译成模型能算的数字，再送去GPU做矩阵运算。生成回答的过程中，模型会顺手把已经算过的上下文缓存下来，也就是KV Cache，这样每吐出一个新词，就不必把前面所有内容从头再算一遍——当然，这份缓存同样要占显存。
如果模型不大、一张卡就装得下，这条路走得还算顺畅。可一旦模型大到必须拆给好几张GPU，权重和中间结果就得在卡与卡之间来回搬。同一台机器里的GPU，可以走PCIe、NVLink这类内部高速通道；一旦跨到另一台服务器，数据还得经过网卡和交换机——网络，就是在这一步正式挤进了计算的关键路径。
到这里，一次推理才算基本走完。如果换成训练，还要在同一条路上再添几个动作：源源不断地读数据、让多张GPU反复对齐梯度、每隔一段时间把模型的当前状态存成检查点。顺着这一次请求从头走到尾，你会发现，芯片、显存、网络、存储和集群不再是五个各说各话的名词，而是同一个AI任务里前后咬合的几道工序。
芯片负责算得快，显存决定运行时数据存储
在刚才那次请求里，CPU、GPU和NPU干的其实是不同的活：
CPU擅长应付控制复杂、分支又多的任务，所以数据预处理、请求调度、系统管理这类杂事，通常都归它管；
GPU手里攥着成千上万个并行计算单元，最适合同时处理一大批长得差不多的矩阵运算，是AI计算真正的主力；
NPU则是专门冲着神经网络设计的一类加速器，它到底强不强，还得看它支持哪些算子、支持什么精度格式、配套的软件工具链顺不顺手。
所以学计算芯片，光盯着"峰值算力"那个最大数字，意义并不大。一个模型跑得快不快，还要看它常用的那些算子有没有被优化过、软件能不能把硬件的本事真正调动起来、数据有没有及时喂到计算单元嘴边。往后你再读芯片相关的资料，不妨顺着计算精度、算子支持、软件生态、实际利用率这几条线慢慢建立判断，而不是只比一个标称的最大值。
显存和芯片贴得最近，回答的却是另一个问题：眼前这一刻，到底摆得下多少东西。模型权重、输入、中间激活、KV Cache，全都得挤在显存里。容量决定它们能不能同时放下，带宽则决定GPU能多快地把这些数据反复读进、写回。这里有个容易被忽略的差别：模型"能启动"不等于"跑得快"——一旦显存不够、被迫频繁把数据倒腾到CPU内存，等待就跟着来了。
所以显存也不能只记一个"多少GB"。模型大小、训练时的激活、推理并发数、上下文长度、KV Cache，再加上显存带宽，这些都是你之后要一点点串起来的概念。
网络、存储和集群，负责让计算别停下来
当一张GPU装不下模型，或者训练慢得让人等不起，团队自然会加卡。但新的算力也带来了新的成本：每张卡算完自己那一份，往往还得跟别人交换梯度或者中间结果。网络的意义，就在于让这些被拆开的计算，能够及时重新汇到一起。
顺着这个思路往下学网络，先别急着背缩写。先把"为什么并行就会产生通信"想透，再去认识带宽、延迟、拥塞和拓扑。至于PCIe、NVLink、Ethernet、RoCE、InfiniBand、RDMA、AllReduce这一长串名字，都可以先挂到这张关系图上——它们说到底，都在回答同一组问题：数据从哪儿走、要走多少、多久能到。
存储管的是另外两件事：让任务始终有数据可读，也让训练的进度能存得下来。容量只说明"能放多少"，真正决定数据供得上供不上的，是吞吐、IOPS、延迟和元数据能力。训练数据、模型权重、日志、检查点、推理缓存，读写方式各不相同，所以本地NVMe、共享文件系统和对象存储往往各管一段，谁也替代不了谁。
等服务器和用户越来越多，集群就该登场了。它要接住一个个作业，替它们找到合适的GPU和节点，把进程拉起来，盯着运行状态，出了故障还得能重试或恢复。学集群的时候，节点、作业、进程、rank、调度、队列、配额、检查点、可观测性这些词，会慢慢连成一套完整的流程，而不再是一堆孤立的名词。
同一套硬件，训练和推理盯着的地方不一样
同一套算力系统，既能拿来训练模型，也能用来跑推理服务。只是这两类任务，看系统的角度很不一样。训练常常一跑就是几小时、几天甚至几周，多张GPU反反复复地同步，团队最在意的是整件事总共要跑多久、加卡之后扩展效率高不高、中途断了还能不能接着来。
在线推理面对的则是一波接一波的用户请求，它更关心：第一个字多久蹦出来、后面的生成稳不稳、同一时刻能扛住多少人。模型权重和KV Cache会长期赖在显存里；把请求攒成一批一起处理能提高整体吞吐，却也可能让某个用户多等一会儿。
正因如此，学任何一项算力技术时，都值得多问一句：它服务的到底是训练，还是推理？同样的GPU、网络和存储，摆进不同的负载里，可能站在完全不同的关键位置上。
一张算力学习地图
读到这儿，你不需要记住所有硬件的名字，但应该已经能把接下来要学的东西，安放进五个彼此相连的位置：
计算芯片：从CPU、GPU、NPU的分工入手，再往下学计算精度、算子、峰值性能和实际利用率。
显存与内存：先搞清模型权重、激活和KV Cache是怎么占空间的，再学容量、带宽、换入换出和内存层级。
网络互联：先想明白多卡为什么要通信，再学集合通信、带宽、延迟、拓扑、RDMA以及不同的网络体系。
数据存储：顺着数据读取和检查点写回，去认识吞吐、IOPS、小文件、缓存、共享文件系统和对象存储。
集群管理：跟着一个作业的生命周期，学节点、进程、rank、并行、调度、监控和故障恢复。
这五块并不是五门互不相干的课。模型越大，显存越吃紧；一张卡装不下，网络就开始要紧；任务跑得越久，检查点越是救命；用的人越多，调度和隔离就越不能缺席。往后所有的深入阅读，其实都只是在这条工作链的某个位置上，继续往下挖而已。
接下来可以读什么
如果你想先把某一个部件吃透，可以从《什么是AI计算》和GPU基础读起；如果你已经在操心多卡或者企业部署，那就顺着高速网络、GPU虚拟化、高速存储、集群导读，一篇篇往下看。这四篇读完，再去碰NCCL、RDMA、MIG、分布式检查点、调度器这些专题，你会更清楚它们各自到底在解决什么问题。
站内关联阅读
参考资料
NVIDIA CUDA Programming Guide, GPU Memory：https://docs.nvidia.com/cuda/cuda-programming-guide/01-introduction/programming-model.html
PyTorch Distributed：https://docs.pytorch.org/docs/stable/distributed
NVIDIA NCCL User Guide：https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/overview.html
Kubernetes, Schedule GPUs：https://kubernetes.io/docs/tasks/manage-gpus/scheduling-gpus/
PyTorch Distributed Checkpoint：https://docs.pytorch.org/docs/main/distributed.checkpoint.html
NVIDIA GPUDirect Storage Design Guide：https://docs.nvidia.com/gpudirect-storage/design-guide/index.html