LLM 基础设施入门：一次看懂 GPU 显存、推理服务与成本

是什么、为什么需要：训练和推理是两回事

“运行”LLM 这个说法里混杂着两件事。训练是在大量数据上不断修正参数（模型学到的数值），推理则是用已经做好的模型生成回答。训练时，除了前向计算，还要把误差反向传回去修正数值（反向传播）。因此，除了权重，还必须把梯度、优化器状态和中间计算值一起放进显存，同一个模型训练所需的 GPU 也远多于推理。Megatron-LM（paper）也指出，巨型 Transformer 由于显存限制难以训练，并用 512 张 GPU 训练了 83 亿参数的模型。

推理不是一次就结束的。每当用户请求到来，它都会持续产生运营成本。vLLM 论文（paper）引用了一项估算：处理一条 LLM 请求的成本可能比传统关键词搜索高 10 倍，并指出提高吞吐量、降低单次请求成本变得十分重要。大多数公司并不自己训练模型，而是对现有模型提供服务（serving，即向用户返回响应的运营工作）。因此本文也以推理为中心。

LLM 推理有一个特点：它根据前面已有的 Token 逐个生成下一个 Token（自回归模型）。vLLM 论文解释说，由于这种按顺序生成的方式，任务速度受制于显存，无法充分利用 GPU 的计算能力。FlashAttention（paper）也指出，最新 GPU 的计算速度已超过显存速度，Transformer 的大部分运算都卡在显存访问上。LLM 基础设施的讨论有相当一部分都围绕“如何节省显存”，原因就在这里。

组成部分：GPU 显存用在哪里

GPU 显存（VRAM）中主要存放三类东西。第一是权重。它就是模型本身，在提供服务期间始终固定不变。第二是 KV 缓存。它是保存已处理 Token 的注意力键和值的记录，使生成下一个 Token 时无需重复相同的计算。它按请求单独生成，文本越长越大，请求结束后即释放。第三是激活值，即计算过程中临时产生的中间值。

vLLM 论文（paper）给出了实际比例的例子。在 40GB 的 A100 GPU 上为 13B（130 亿参数）模型提供服务时，权重约占显存的 65%，KV 缓存接近 30%，其余约 5% 由激活值等使用。权重不变，激活值又很小。因此，KV 缓存的管理方式决定了一次能批量处理多少请求（批大小）。据 vLLM 博客（w2），在 LLaMA-13B 上，仅一个序列的 KV 缓存就可高达 1.7GB。

权重大小可以简单估算。Hugging Face 指南（w1）的经验法则如下：若参数量为 X billion（以十亿为单位），FP32 下约需 4X GB，BF16·FP16 下约需 2X GB。例如，Llama-2-70b 需要 140GB，Falcon-40b 需要 80GB。指南解释说，对于少于 1,024 个 Token 的短输入，所需显存几乎由权重决定。实际上，按 BF16 预估为 31GB 的 bigcode/octocoder，加载后实测约为 29GB。还要记住，输入越长或并发请求越多，KV 缓存所占的部分就越大。

精度与量化：数字要记得多精细

参数是小数，用多少字节记录一个小数就是精度。FP32 用 4 字节，FP16 和 BF16 用 2 字节，FP8 用 1 字节。BF16 与 FP16 大小相同，但可表示的数值范围更广，因此训练时数值更不容易不稳定。Hugging Face 指南（w1）说明，如今几乎所有模型都以 BF16 训练。指南还指出，前面的 octocoder 如果用 FP32 运行，将需要 64GB。

量化是把权重压缩成 8 位或 4 位等更少比特来存储的方法。Hugging Face 指南（w1）介绍了相关研究：将精度降到 8 位·4 位，性能不会大幅下降，同时还能获得计算上的优势。按字节数计算，权重在 8 位下每 X billion 参数约需 X GB，在 4 位下约需 X/2 GB。对于 70B 模型，可估算出 4 位下仅权重就约为 35GB。据 vLLM 文档（w4），该引擎支持 FP8、INT8、INT4、GPTQ·AWQ、GGUF 等量化格式。GPTQ·AWQ 是权重量化方法，GGUF 是本地运行中常用的文件格式。

有两点需要注意。第一，量化对质量的影响因模型和任务而异，因此一定要用自己业务的评测集来验证。第二，即使压缩了权重，KV 缓存依然单独存在。对于处理长文档或并发请求较多的服务，即便压缩了权重，显存仍可能不足。

推理引擎与连续批处理：延迟与吞吐量的平衡

推理引擎是一种服务器软件，它把模型加载到内存中，接收多个用户的请求并高效处理。一个请求要经过两个阶段。首先在预填充阶段一次性处理整个提示词，此时生成第一个 token。到这一步所用的时间就是 TTFT（首 token 时间）。接下来的解码阶段逐个生成 token。用户感受到的是 TTFT 以及之后文字输出的速度。运维方关注的是 GPU 每秒输出的 token 数，即吞吐量（token/秒）。吞吐量直接关系到成本。

延迟与吞吐量是此消彼长的关系。把多个请求打包成一批处理时，从内存中读取一次权重就能处理多个请求，因此吞吐量会提高。但批次变大后，每个请求可能需要等待，或者单个步骤变慢，延迟可能增加。在过去的方式中，必须等整个批次完成，新请求才能进入。连续批处理在每个解码步骤都会移出已完成的请求，并立即插入正在等待的请求，从而减少 GPU 的空闲时间。vLLM 文档（w4）将连续批处理与 chunked prefill（把长提示词的预填充切分处理）、prefix caching（复用相同的前缀部分）以及预填充与解码分离执行一起列为支持的功能。

vLLM 的核心技术是分页注意力（PagedAttention）。根据 vLLM 论文（paper），以往的系统会为每个请求预先分配与最大长度（例如 2,048 个 token）相当的连续内存。结果，KV 缓存内存中实际存放 token 信息的部分只有 20.4~38.2%。分页注意力像操作系统的虚拟内存一样，把 KV 缓存划分为固定大小的块，并在需要时按块分配。vLLM 博客（w2）称，这样可以把浪费降到 4% 以下，在从一个提示词生成多个回答的情况下，最多可节省 55% 的内存。论文报告称，在同等延迟水平下，其吞吐量比 FasterTransformer、Orca 高 2~4 倍；博客则称，其吞吐量比 HF Transformers 最高高 24 倍，比 TGI 最高高 3.5 倍。不过，这些倍数是在特定模型、GPU 和数据上得出的实验结果。

也有加快注意力计算本身的技术。FlashAttention（paper）把注意力切分成小块（tile），在 GPU 芯片内部高速的 SRAM 中计算。因此，对相对较慢的 HBM（GPU 的高带宽内存）的读写次数减少了。它计算的是精确注意力而非近似，同时在 GPT-2 上将注意力计算最多加快了 7.6 倍，内存占用也降到与序列长度成正比的水平。vLLM 文档（w4）表示其使用了包括 FlashAttention 在内的优化注意力内核。

一张 GPU 装不下时：张量并行与流水线并行

Hugging Face 指南（w1）写道，在撰写当时最大的 GPU A100、H100 的显存为 80GB。指南还解释说，它所举例的大多数模型仅加载就会超过 80GB，因此需要张量并行或流水线并行。在实践中，增加 GPU 之前，先考虑能否通过量化放进一张卡，会更简单。

张量并行是把每一层内部的大矩阵切分给多张 GPU 分别计算，再合并结果的方式。Megatron-LM（paper）只在 PyTorch 中加入了几个通信操作，就实现了这种层内模型并行。这种方式可以与流水线并行一起使用。该研究在 512 张 GPU 上维持了 15.1 PetaFLOPs，与单张 GPU 相比达到了 76% 的扩展效率。张量并行在每一层都需要 GPU 之间交换结果，因此 GPU 之间的连接（互连）必须足够快。所以通常把同一台服务器内的 GPU 组合在一起。

流水线并行是按顺序切分各层，把前面的层放在 GPU A 上、后面的层放在 GPU B 上的方式。需要交换的通信较少。但 Hugging Face 指南（w1）指出，简单的流水线并行无法解决前一张 GPU 工作时后一张 GPU 空闲的问题，因此需要更先进的方法。根据 vLLM 文档（w4），该引擎为分布式推理支持张量、流水线、数据、专家和上下文并行。其中数据并行是启动多个模型副本的方式，用于提高能放进单张卡的模型的吞吐量。

分步应用：选择部署方式与估算成本

如果是第一次上手，建议按以下顺序进行。第一，写下需求：确定每天的请求数、每个请求的平均输入和输出 token 数、可接受的 TTFT，以及数据能否发送到外部。第二，估算内存：用“参数 × 字节”计算权重，并为 KV 缓存留出余量。第三，选择部署方式。第四，计算成本。第五，通过负载测试实际测量 TTFT 和吞吐量，并调整批大小和 GPU 数量。

部署方式大致有四种。云 API 是按使用的 token 量付费、调用模型公司 API 的方式。运维负担最小，但数据会发送到外部。GPU 云是按小时租用 GPU、自行启动推理引擎的方式。可以自由选择开放权重模型，但需要自己运维。自建服务器需要购置设备、承担电力和运维人员成本。作为交换，数据留在内部，在使用量持续较大时更有优势。本地运行（本地 LLM）是在 PC 或笔记本上运行小模型或量化模型的方式，适合个人试用。vLLM 可以启动与 OpenAI API 兼容的服务器（w2、w4）。因此，从使用 API 转向自行运维时，应用代码需要改动的地方更少。

成本估算方法如下。如果使用 API，则“月成本 ≈ 月请求数 × （平均输入 token × 输入单价 + 平均输出 token × 输出单价）”。输入和输出往往分开定价，所以要分开计算。例如，每天 1,000 次请求、每次输入 2,000 个 token、输出 500 个 token，则每天输入 200 万个 token、输出 50 万个 token。30 天就是输入 6,000 万个 token、输出 1,500 万个 token，再分别乘以各自的单价。

如果自行运维，则按“每 token 成本 ≈ GPU 每小时成本 ÷ 每小时处理的 token 数”来看。吞吐量翻倍，每 token 成本就减半。根据 vLLM 博客（w2），LMSYS 引入 vLLM 后，处理同样流量所需的 GPU 数量减少了 50%。反过来，即使请求少、GPU 闲置，每小时成本也照样支出。因此，使用量少或波动大时 API 往往更有利，使用量持续较大时自行运维往往更有利。

检查清单与常见错误

部署前检查三组事项。内存方面，看是否按精度对应的字节数计算了权重，是否为 KV 缓存留出了余量，量化后是否评估了质量。性能方面，看是否设定了 TTFT 目标，是否用真实负载测量了吞吐量（token/秒），是否使用支持连续批处理的推理引擎。成本与运维方面，看是否分开计算了输入和输出 token，是否在监控 GPU 利用率，是否确认了向外部发送数据时的公司内部规定。

常见错误如下：只计算权重而忘了 KV 缓存，导致长请求时内存不足；期望“最高 24 倍”这类基准测试倍数在自己的环境中同样成立；一味提高吞吐量，导致 TTFT 变长、用户体验变差；用简单的流水线并行使用多张 GPU，却让它们大部分时间闲置；请求不多却购置自建服务器，导致 GPU 利用率一直偏低。

还需要了解局限。本文中的数值来自特定时间点的资料。例如“最大的 GPU 为 80GB”是以 Hugging Face 指南（w1）撰写时为准。硬件和引擎变化很快，实际决策时应以最新文档和自己实测的数值重新确认。

延伸学习

建议先阅读 Hugging Face 指南（w1）。它配合代码示例，依次介绍权重内存的计算方法、精度、FlashAttention，以及 MQA、GQA 等结构改进。接着，最好在 vLLM 博客（w2）中通过图示了解分页注意力如何以块的形式管理 KV 缓存。

若想深入了解原理，可阅读 vLLM 论文（paper）。其中详细介绍了内存浪费从何而来以及调度设计。FlashAttention（paper）有助于理解 GPU 内部 HBM 与 SRAM 这一内存层级。如果想了解模型并行的起点，可以看看 Megatron-LM（paper）是如何实现张量并行的。

若想亲自动手，可在 vLLM 文档（w4）的功能列表中查看连续批处理、量化和并行选项，并按照 Quickstart 指南从小模型开始启动。启动之后，亲自测量 TTFT 和吞吐量是最好的学习方式。