大模型推理中的 Token 计算到底消耗哪些硬件资源，从输入请求到结果生成逐步分析

很多人谈论大模型推理成本时，会直接把Token数量乘以一个价格，然后得出每百万Token多少钱。但在服务器硬件层面，一个Token并不是一个简单的“计算单位”。它会消耗GPU计算资源、显存容量、显存带宽、GPU内部缓存、CPU资源、系统内存、PCIe或高速GPU互连、网络带宽以及一定的存储资源，而且输入Token和输出Token对硬件的压力并不完全相同。

如果从硬件工程角度观察，一次大模型推理至少应该拆成请求接收、Tokenization、Prefill、Decode、结果采样与传输几个阶段。真正决定GPU成本的核心，也不是“Token越多GPU占用越高”这么简单，而是模型参数量、上下文长度、批量大小、KV Cache、数据类型、并发请求数以及GPU之间的通信方式共同决定了每个Token需要消耗多少计算和内存资源。

一个Token首先消耗的是CPU和系统内存

用户输入的并不是GPU可以直接理解的Token编号。HTTP请求首先进入服务器，经过TLS终止、请求解析、认证、限流、路由等处理，然后由Tokenization程序把文本转换成Token ID。

这一阶段通常由CPU执行。对于单个请求，Tokenization的计算量相对于大型Transformer模型本身通常很小，但当推理服务达到很高的请求速率以后，CPU仍然可能成为瓶颈。尤其是大量短请求同时进入系统时，网络协议栈、TLS、JSON解析、Tokenization、请求队列和调度线程都会消耗CPU。

因此，出现“GPU利用率只有50%，但是服务器吞吐量上不去”的情况，并不一定应该立即升级GPU。CPU核数、单核性能、线程调度、Tokenization实现、请求队列以及Python或其他运行时的开销，都可能成为限制因素。

Token ID、输入张量以及推理框架的数据结构通常首先位于CPU内存，然后才根据执行计划传递给GPU。这里的系统内存容量和内存带宽会影响数据准备和调度效率，但不能简单认为“Token越多就会按某个固定字节数消耗RAM”。不同框架的张量布局、批处理方式、输入缓存和异步流水线都会改变实际内存占用。

Prefill阶段主要考验GPU计算能力

当输入Token进入Transformer以后，首先经历Prefill阶段。

例如用户一次提交5000个Token，模型需要利用这5000个Token完成上下文计算，并建立后续生成所需要的KV Cache。这个阶段通常具有很高的并行度，因此矩阵乘法和Attention计算会大量使用GPU的Tensor Core以及其他计算资源。

这也是为什么“GPU有多少TFLOPS”在Prefill阶段具有一定参考价值。

但TFLOPS依然不能直接等价于实际推理速度。GPU执行大模型时，还要不断读取模型权重、激活值和其他张量。如果计算单元很强，而显存带宽或者数据复用效率跟不上，Tensor Core可能无法保持满负载。

以FP16模型为例，一个70亿参数模型的权重理论上大约需要14GB存储空间。实际推理时还需要考虑KV Cache、临时激活、CUDA运行时、算子workspace、显存碎片以及框架自身开销，所以不能简单地说“70亿参数模型一定需要40GB GPU”。如果上下文很短、批量很小，可能远低于这个数字；如果上下文很长、并发很高，KV Cache反而可能成为主要的显存消费者。

这里必须把“模型权重”和“KV Cache”区分开。模型权重通常在加载以后长期驻留GPU显存，而KV Cache会随着请求上下文和已经生成的Token不断变化。

Decode阶段的瓶颈与Prefill完全不同

Prefill完成以后，模型进入Decode阶段，也就是一次生成一个或者少量Token的过程。

这时候计算模式发生了明显变化。生成下一个Token时，模型需要使用已经存在的上下文信息，而这些历史信息主要通过KV Cache保存。随着上下文长度增加，每生成一个新Token，都需要处理越来越长的历史上下文。

因此，Decode阶段通常更加容易受到显存容量和显存带宽影响。

对于Transformer的典型Multi-Head Attention结构，KV Cache每个Token占用的内存可以近似理解为：

2 × 层数 × KV头数 × 每个头的维度 × 每个元素的字节数

这里的2来自Key和Value两组数据。

假设一个模型拥有80层、8个KV Head、每个Head维度128，并使用FP16保存KV Cache，那么每个Token大约需要320KiB的KV Cache空间。100K Token对应的KV Cache理论量级就可能达到约31GiB。

这只是用于说明机制的计算，并不是所有模型都会得到这个数字。GQA、MQA、MLA、不同Attention结构、KV Cache量化以及部分层使用不同Attention机制，都会改变实际占用。

这也是长上下文模型越来越依赖KV Cache管理技术的原因。模型可能只有几十GB权重，但随着并发请求和上下文长度增长，KV Cache可能迅速成为显存压力最大的部分。

显存容量和显存带宽解决的是两个不同问题

GPU显存容量决定的是“能不能装下这些数据”，显存带宽更多决定的是“这些数据能多快被搬进计算路径”。

例如A100 80GB使用HBM2e，显存带宽约为2TB/s量级；H100的HBM3版本显存带宽约为3TB/s量级。具体数字还要区分产品型号，因此不能简单把某一型号的带宽写成整个GPU系列的固定参数。

更重要的是，显存带宽并不等于模型推理速度。

假设一个Decode步骤需要频繁读取大量模型权重和KV Cache，那么GPU可能主要受内存访问限制。此时增加Tensor Core数量并不一定能够同比提升Token/s，因为计算单元已经在等待数据。

反过来，如果模型执行中的矩阵乘法占主导，GPU可能更接近计算受限状态，此时Tensor Core吞吐能力才更加关键。

专业性能分析因此不能只看GPU Utilization。应该同时观察SM利用率、Tensor Core利用率、显存读写吞吐、显存容量、功耗、频率、温度以及不同Kernel的执行时间。

KV Cache是长上下文推理最容易被低估的资源

长上下文真正改变推理服务器经济模型的地方，并不是模型权重突然变大，而是KV Cache随着请求长度增加而增长。

假设模型本身可以加载进一张80GB GPU，那么并不代表这张80GB GPU可以同时服务大量100K上下文请求。每个请求都会占用自己的KV Cache，多个并发请求叠加以后，很快就会把剩余显存吃掉。

一旦显存不足，系统可能需要降低并发、限制上下文长度、采用KV Cache量化、进行CPU Offload，或者把请求分散到更多GPU。每一种方案都会付出代价。

CPU Offload可以缓解GPU显存容量压力，但CPU内存与GPU之间的PCIe或其他互连带宽远低于GPU内部HBM带宽，因此不能把它理解成“显存不够就把数据放到RAM，性能基本不变”。

这也是现代推理框架越来越重视Paged KV Cache、Prefix Cache以及Cache Block管理的原因。显存管理效率本身已经成为推理系统性能的一部分。

PCIe和GPU之间的高速互连决定多GPU系统的通信成本

单GPU推理时，GPU内部数据路径通常是主要性能来源。

当模型无法装进一张GPU，或者为了提升吞吐量需要使用多GPU以后，情况就复杂很多。

模型可能采用Tensor Parallel、Pipeline Parallel或者其他并行方式。不同GPU之间需要交换激活值、部分结果或者其他中间数据。此时GPU之间的互连速度和拓扑结构就会影响整体性能。

PCIe 4.0 x16的理论单向带宽约为16GB/s，PCIe 5.0 x16约为32GB/s；实际有效吞吐会受到协议开销、平台拓扑和设备限制影响。

NVLink和NVSwitch则提供了更高带宽的GPU间互连，但它们解决的是GPU之间的数据交换问题，并不是简单替代SSD到GPU或者CPU到GPU的数据路径。

因此，多GPU服务器不能只看“有几张GPU”。还要看GPU之间如何连接、是否经过PCIe Switch、NUMA拓扑如何、CPU Root Complex在哪里，以及应用采用什么并行策略。

CPU内存带宽通常不是生成Token的第一瓶颈

原稿把DDR4内存带宽和GPU HBM带宽直接进行比较，这容易产生误解。

一台服务器的DDR4或DDR5内存带宽确实可能影响Tokenization、数据预处理、CPU Offload、模型加载以及部分推理路径，但在典型GPU推理中，模型主体计算主要发生在GPU，不能简单认为“DDR4只有几十GB/s，所以Token生成一定受到系统内存带宽限制”。

对于GPU驻留模型，权重和KV Cache主要位于GPU显存，Decode阶段的关键数据访问通常也是GPU HBM或GDDR路径。

只有当系统频繁发生CPU与GPU之间的数据交换，或者采用CPU Offload、异构推理等策略时，系统内存带宽和PCIe带宽才会明显进入主要瓶颈区域。

因此，诊断服务器性能时应该先确认数据到底在哪里，而不是看到“RAM带宽低于HBM”就判断系统内存是瓶颈。

网络带宽影响的是服务层吞吐和延迟

网络资源在大规模推理服务中当然重要，但它和GPU计算之间不是简单的替代关系。

如果用户发送1000个Token的请求，而服务器返回100个Token，网络需要传输的是请求文本或Token数据、协议开销以及最终生成结果。Token本身通常非常小，因此单个请求并不会因为“1000个Token”就消耗大量网络带宽。

当服务规模达到每秒数千甚至数万请求以后，情况才会发生变化。大量并发连接、TLS、HTTP协议、流式输出以及多个GPU节点之间的内部通信，都会形成网络压力。

对于分布式推理系统，前端请求网络和GPU集群内部网络需要分开考虑。前者主要负责用户请求和响应，后者可能承担Tensor Parallel、专家并行、KV Cache传输或者节点间调度。

RDMA、RoCE等技术可以降低特定高性能集群中的CPU参与和通信延迟，但它们不是“结果返回客户端的万能加速器”。客户端仍然需要经过正常的网络协议和服务端架构。

模型加载和Token生成不是同一个性能问题

原稿把NVMe随机读取延迟直接放到Token计算过程中，也需要进一步区分。

正常的推理服务器通常会在服务启动或模型切换阶段，从NVMe、网络存储或对象存储加载模型权重，然后把模型放入CPU内存并进一步传输到GPU显存。

这个阶段确实可能受到SSD吞吐、CPU内存带宽、PCIe带宽和GPU初始化速度影响。

但是模型已经加载到GPU以后，持续生成Token通常不会每生成一个Token就从NVMe读取完整模型权重。

因此，“SSD随机读取延迟10微秒还是1微秒”通常不是稳态Decode Token/s的第一决定因素。它更可能影响冷启动、模型切换、节点恢复以及缓存未命中的时间。

这一区分对于GPU服务器维护非常重要。服务器启动慢和Token生成慢，可能完全是两个不同的故障域。

GPU利用率低并不代表GPU性能差

AI推理服务器出现低GPU利用率时，很多人第一反应是GPU没有吃满。

但GPU利用率只是结果，不是原因。

如果请求数量不足，GPU自然无法保持高利用率。如果CPU Tokenization、调度器、网络、数据预处理或者同步操作成为瓶颈，GPU也会等待。

如果模型使用多个GPU，而某张GPU因为通信、负载不平衡或者并行策略问题处于等待状态，整体GPU利用率也可能下降。

甚至在单个Kernel内部，GPU也可能受到显存访问、Kernel Launch、同步和数据依赖影响。

专业诊断需要结合时间线观察CPU、GPU、HBM带宽、PCIe吞吐、网络流量和请求延迟，而不是单独看任务管理器里的GPU百分比。

从硬件维修角度如何定位Token性能异常

如果一台AI服务器的Token生成速度突然下降，第一步不是更换GPU，而是确定性能下降发生在哪个阶段。

如果模型加载速度下降，重点检查NVMe吞吐、文件系统、CPU内存、PCIe链路以及模型加载流程。

如果Prefill明显变慢，则重点观察GPU计算利用率、Tensor Core利用率、显存吞吐、输入长度以及批处理策略。

如果Prefill正常而Decode变慢，则应该重点检查KV Cache、显存容量、显存带宽、并发数量以及GPU频率和功耗状态。

如果单GPU正常，多GPU明显下降，则需要进一步检查GPU间互连、PCIe拓扑、NUMA、通信Kernel以及并行策略。

如果GPU利用率不高但CPU已经接近饱和，则应该检查Tokenization、请求调度、线程池、网络协议栈和应用运行时。

如果GPU温度、功耗和频率出现异常下降，则应该进一步排查散热、功耗限制、VRM、GPU电源供应以及系统级Power Limit，而不是单纯把问题归咎于模型。

如果显存已经接近满载，则要进一步区分模型权重、KV Cache、workspace和框架缓存分别占用了多少空间。单纯增加显存容量可能解决容量问题，但并不一定解决带宽或者计算问题。

AI推理服务器真正需要监控的是一组指标

对于专业AI基础设施，单独监控“Token/s”是不够的。

比较有价值的指标至少包括Time To First Token，也就是TTFT；Inter-Token Latency，也就是生成阶段相邻Token之间的时间；Prefill吞吐；Decode吞吐；请求并发量；每秒生成Token数；GPU显存使用量；HBM读写带宽；GPU计算利用率；功耗；温度；GPU频率；CPU利用率；系统内存；PCIe吞吐；GPU间通信吞吐以及网络延迟。

这些指标组合起来以后，才能判断一台服务器到底是计算受限、显存带宽受限、显存容量受限、CPU受限、通信受限还是调度受限。

对于AI服务器维修人员，这比简单观察“GPU有没有跑到99%”有价值很多。

大模型中的Token并不是某个GPU硬件单元专门处理的“小颗粒计算单位”。一个Token从进入系统到最终生成，需要经过网络协议栈、CPU、Tokenization、系统内存、GPU计算单元、显存、KV Cache以及最终的网络输出；在多GPU环境中，还可能涉及PCIe、NVLink、NVSwitch甚至节点间高速网络。

而且输入Token和输出Token的资源特征并不相同。输入较长时，Prefill会带来较强的并行计算压力；生成阶段则随着上下文增长而越来越依赖KV Cache和显存访问效率。长上下文、高并发和多用户场景下，显存容量很容易从“装模型的问题”变成“决定能同时服务多少请求的问题”。

所以，分析大模型推理硬件成本时，最有效的方法不是问“一个Token需要多少GPU”，而是把Token放回整个执行链路中观察：它在哪里生成，数据在哪里存放，哪一个硬件在搬运数据，哪一个计算单元在执行算子，以及哪个环节首先达到饱和。只有把这些问题拆开，才能知道一张GPU为什么能达到某个Token/s，也才能判断下一次升级应该买更大的显存、更高的HBM带宽、更强的计算单元、更快的GPU互连，还是增加CPU、内存和网络资源。