谈到 AI 硬件，大家最先想到的通常是 GPU 算力。但在实际运行中，GPU 经常遇到另外两个问题：数据装不下，或者数据送得不够快。
以一个 7B 模型为例。7B 表示它大约有 70 亿个参数。在常见配置下，如果让这 70 亿个参数全部参与训练，显存需求通常会超过 100GB；如果一次同时训练的样本更多、输入更长，占用还会继续增加。到了推理阶段，同一个模型在适当配置下可以放进一张 24GB 显存的 GPU。
训练和推理用的是同一个模型，为什么内存需求会差这么多？要回答这个问题，需要先分清三件事：训练时内存里放什么，推理时内存里放什么，以及 HBM、主机内存和 SSD 各自负责什么。
HBM、主机内存和 SSD 有什么区别
大模型系统常用三层存储。它们的区别可以先记成一句话：越靠近 GPU，速度越快，但容量越小、价格也越高。
| 存储层 | 直观理解 | 速度 | 容量 | 主要作用 |
|---|---|---|---|---|
| HBM（显存） | 学生面前的书桌 | 最快 | 最小 | 放正在参与计算的数据 |
| DRAM（主机内存） | 书桌旁的抽屉 | 较慢 | 较大 | 临时存放显存装不下、又可能很快要用的数据 |
| SSD（硬盘） | 教室后面的书柜 | 最慢 | 最大 | 放数据集、训练存档和暂时不用的缓存 |
显存压力大时，权重和优化器状态被卸载到 DRAM / SSD；激活值用完即弃或重计算。
数据块边框颜色 = 目标存储层。方块沿虚线通道流动，点击切换查看训练与推理的流向差异。
可以把 GPU 想成一个正在写作业的学生。正在用的课本和草稿纸要放在书桌上；放进抽屉或教室后面的书柜，可以腾出桌面，但再次使用时要先取回来。真正参与 GPU 计算的数据也一样，最终要进入 HBM。
训练和推理都在使用这三层存储，但两者遇到的问题不同。简单来说，训练通常先被容量卡住，推理则经常被带宽卡住。
这里的带宽，可以理解为单位时间内能搬运多少数据。书桌能放多少本书，对应容量；一分钟能从抽屉里取出多少本书，对应带宽。容量回答"能装多少"，带宽回答"取数据有多快"。
训练为什么需要这么多显存
训练会根据数据不断修改模型。因此，GPU 除了保存模型本身，还要保存修改模型所需的中间信息。
主要有四类：
- 模型权重：模型已经学到的参数。
- 激活值：数据经过每一层计算时产生的中间结果。后面计算如何修改参数时还要用到。
- 梯度：告诉系统每个参数应该往哪个方向调整、调整多少。
- 优化器状态：记录过去几次调整的方向和幅度，帮助训练过程更稳定。
训练有点像学生做完一道题后订正。模型权重是已经学会的解题方法，激活值是草稿纸上的计算步骤，梯度是老师标出的修改方向，优化器状态则像订正记录，记着前几次往哪个方向改、改了多少。要把解题方法改对，这些材料都要留着。
点击下方组件切换显示，查看训练显存是如何从 14 GB 涨到 104 GB 的。
当前显存 104 GB，是纯推理（14 GB）的 7.4 倍。
推理主要是读取权重，训练却要同时保存这四类数据。模型越大、一次处理的样本越多、输入文本越长，显存占用就越高。所以，一个模型能在单张 GPU 上回答问题，却未必能在同一张卡上做全参数训练。
具体需要多少显存，没有一个适用于所有模型的固定数字。数据精度、一次同时处理多少样本（batch size）、输入长度、优化器和训练框架都会影响结果。但量级上的差别很稳定：7B 模型的权重本身只有十几 GB，全参数训练加上梯度、优化器状态和激活值后，通常会上升到 100GB 以上。
更直观的对比来自单 token 视角。以 Llama-3-8B 为例：推理时一个 token 的 KV Cache 约 0.25 MB（FP16）；训练时一个 token 在前向传播中产生的激活值约 8.7 MB（FP16）——是推理单 token 的 35 倍。
同一个模型，训练时一个 token 的激活值是推理时 KV Cache 的数十倍。
Llama-3-8B：训练一个 token 的激活值（8.7 MB）是推理 KV Cache（0.25 MB）的 35 倍。
显存不够时怎么办
训练系统常用三类方法降低显存需求：
| 方法 | 用通俗的话说 | 代价 |
|---|---|---|
| 分片（如 ZeRO） | 一套资料太多，就拆开分给几张书桌，也就是多张 GPU 保存 | GPU 之间需要频繁通信 |
| 卸载（Offload） | 把暂时不用的书放进抽屉（DRAM），甚至送到书柜（SSD） | 需要等待数据搬运 |
| 激活值重计算 | 不保存全部草稿，也就是激活值，需要时再算一遍 | 增加计算量和训练时间 |
这三类方法都没有让数据凭空消失。它们只是用更多通信、搬运或重复计算，换取更少的显存占用。
点击下方策略，看显存压力如何下降，代价如何上升。数据不会凭空消失。
当前显存压力 100%。开启任意策略，用通信、搬运或重复计算来换取显存。
训练过程中还会定期保存 checkpoint，也就是把当前权重和优化器状态写入 SSD。这像学生每做完一部分作业，就把进度保存好；即使电脑突然断电，也不用从第一题重新开始。checkpoint 主要用于容错，不是为了加快当下这一步计算。
推理为什么更关心带宽
推理是用训练好的模型回答问题。它不需要计算梯度，也不需要保存优化器状态，所以内存里的数据种类少了很多。除了模型权重，最重要的一项是 KV Cache。
KV Cache 是什么
大模型生成回答时，是一个 token 接一个 token 往后写。token 可以理解为模型切分文字时使用的小单位，可能是一个字、一个词的一部分，也可能是一个标点。生成下一个 token 时，模型需要参考前面的输入和已经生成的内容。
如果每生成一个 token，都把前文从头计算一遍，会浪费大量算力。KV Cache 会保存前文已经算过的中间结果，让后面的生成直接复用。它保存的是模型处理文字后得到的计算结果，聊天原文仍然是输入的一部分。
KV Cache 可以理解成学生读长文章时做的笔记。没有笔记，每写一句回答都要从第一页重新读；有了笔记，就能直接查看前面已经整理好的重点内容。KV Cache 保存的就是这类供后续计算使用的"笔记"。
这样做能减少重复计算，但会占用显存。上下文越长、同时服务的用户越多，KV Cache 就越大。
具体来说，一个 token 的 KV Cache 有多大？以 FP16 精度为例：
| 模型 | 单 token KV Cache（估算值） |
|---|---|
| Llama-2-7B | 约 1.0 MB |
| Llama-3-8B | 约 0.25 MB |
| Llama-3-70B | 约 0.63 MB |
| DeepSeek-V3 671B (MoE) | 约 0.5–1 MB |
| GPT-3 175B | 约 14.0 MB |
同样是 70 亿到 80 亿参数级别的模型，Llama-3-8B 的单 token KV Cache 只有 Llama-2-7B 的 1/4。原因是 Meta 在 Llama-3 中引入了 GQA（分组查询注意力），把 Key 和 Value 的头数压缩到原来的 1/4。
更极端的例子是 DeepSeek-V3。它虽然参数量巨大（671B），但用了 MLA（多头潜注意力，Multi-head Latent Attention），把 KV 压缩成低秩潜向量再存储，单 token KV 反而被压到主流稠密模型的 1/10 到 1/4。这也是 DeepSeek 官方宣称"KV Cache 成本降到前代 1/10"的架构原因。
与这些架构创新形成对比的是 GPT-3 175B。它发表于 GQA 之前，没有做 KV 头压缩，单 token KV 高达 14 MB——这也是为什么长上下文在老架构上几乎不可行。
切换架构，看 KV 头数和单 token 缓存大小如何被一步步压下来。
亮色格子 = 实际存储的 KV 组。MHA 把 8 个查询头的 KV 压成 8 份。
MHA：每个查询头都有自己的 Key 和 Value，没有压缩。
MHA 是基线：每个头独立存储 KV，长上下文下缓存膨胀最快。
这些数字叠加上下文长度后增长很快：
| 模型 | 8K 上下文 | 32K 上下文 | 128K 上下文 |
|---|---|---|---|
| Llama-3-8B | 约 2 GB | 约 8 GB | 约 32 GB |
| Llama-3-70B | 约 5 GB | 约 20 GB | 约 80 GB |
| GPT-3 175B | 约 112 GB | 约 448 GB | 约 1.8 TB |
一张 80GB 显存的 H100，在 128K 上下文下跑 Llama-3-70B，光 KV Cache 就几乎吃满。这也是为什么 DeepSeek、Mooncake、vLLM 都在拼命做 KV 压缩和分层存储——长上下文场景下，KV Cache 是显存的第一杀手。
拖动滑块改变上下文长度，看 KV Cache 如何线性增长，何时顶破 H100 的 80 GB 显存上限。
当前 32K 上下文：两个模型的 KV Cache 都在 80 GB 以内。
为什么 GPU 会"等数据"
生成回答的阶段通常叫 Decode。模型每生成一个 token，都要读取大量模型权重，以及此前积累的 KV Cache。
如果这些数据不能足够快地送进计算单元，GPU 即使还有空闲算力，也只能等待。这个时候，速度取决于每秒能从显存里读出多少数据。这就是内存带宽瓶颈。
想象一个写字很快的学生，每写一个词都要先翻一遍旁边的笔记。如果递笔记的速度太慢，他大部分时间只能坐着等。学生写字有多快，对应 GPU 的算力；笔记送到手边有多快，对应内存带宽。
推理每生成一个 token 都要把全部权重和 KV Cache 重新读一遍；读得不够快，GPU 就只能干等。
计算很快，但每个 token 都要重读全部权重和 KV Cache；带宽跟不上，GPU 就只能空转。这就是「推理看带宽」。
"训练看容量，推理看带宽"是一条便于理解的经验规律，不是对所有任务都成立的定律。短输入、高并发批处理或不同模型架构，可能让计算、容量和带宽的重要性发生变化。但对于常见的大模型训练和逐 token 生成，它能解释大部分现象。
KV Cache 放不下时，系统怎么处理
推理系统也会把数据分层存放：
| 存储层 | 推理时通常放什么 |
|---|---|
| HBM（显存） | 模型权重和正在生成回答的 KV Cache |
| DRAM（主机内存） | 暂时不活跃、但可能很快继续使用的 KV Cache |
| SSD（硬盘） | 更久没有使用、但仍有复用价值的缓存 |
系统会优先把当前请求需要的数据留在 HBM，把不那么紧急的数据移到主机内存或 SSD。就像学生把正在用的笔记放在桌面，刚用过的收进抽屉，很久不用的放回书柜。请求重新活跃时，系统再把相应缓存取回来。
Mooncake（月之暗面/Kimi）就是一个公开案例。它把 GPU 显存、主机内存和 SSD 组织成更大的 KV Cache 池，目标是在满足延迟要求的前提下，减少重复计算。vLLM、SGLang 等推理框架也在支持类似的分层缓存能力。
SSD 容量大、价格低，但速度远低于 HBM。它适合扩大可复用缓存的范围，却不能直接代替显存。系统需要提前取回数据，并在 GPU 用到之前送进 HBM；如果预测不准或搬运太慢，缓存反而会拖慢生成速度。
点击下方请求切换『当前生成中』的目标。系统会把它提升回 HBM，必要时把最久未用的缓存逐级下沉——就像把书桌腾出位置。
HBM 装不下时，最久未用的缓存被下沉到 DRAM 或 SSD；请求重新活跃时再提升回 HBM。预取必须赶在 GPU 需要之前完成，否则反而拖慢生成。
为什么"缓存命中"的价格更便宜
理解了 KV Cache，厂商定价表里的"缓存命中"和"缓存未命中"就容易理解了。
一次推理可以粗略分成两个阶段：
- Prefill：读取整段输入，并为它计算 KV Cache，相当于第一次读文章并做好笔记。
- Decode：利用前面的计算结果，逐 token 生成回答，相当于看着笔记开始答题。
如果一个新请求的开头和此前处理过的内容完全相同，例如同一个系统提示词或同一份长文档，系统就可以直接复用已经保存的 KV Cache。被复用的部分不需要再次做 Prefill，只需要读取缓存，因此成本更低。
缓存命中就像第二张试卷附上了同一篇阅读材料。文章没有变，之前做的笔记可以继续用；只有新问题需要重新作答。缓存未命中则像换了一篇新文章，学生要重新阅读并做笔记。
截至 2026 年 7 月，DeepSeek 官方定价中，V4-Pro 每百万输入 token 的缓存命中价为 0.003625 美元，未命中价为 0.435 美元，相差 120 倍。价格以后可能调整，但差价背后的机制不会随定价表改变：缓存命中省掉了重复计算。
缓存命中时，系统只需读取已有的 KV Cache；缓存未命中时，系统需要重新计算整段输入的 KV Cache。这 120 倍的价差，本质上是"读缓存"和"重新算一遍"的成本区别——理解了这个，就能判断什么时候该复用系统提示词、什么时候该把长文档放在前面。
切换命中/未命中，拖动滑块改变前缀分界点，看 Prefill/Decode 与价格如何变化。
命中模式下，前 15 个 token 跳过 Prefill，只需读缓存。
命中前缀 15 / 20 个 token——这部分跳过 Prefill，只读缓存。省下的计算 ≈ 75%。
这里有两个容易误解的地方。
第一，缓存只降低输入中命中部分的成本。输出仍然要由模型逐 token 生成，不会因为输入命中缓存就免费。
第二，缓存匹配要求前缀相同。"意思差不多"不能算命中。系统会从输入开头开始比较，前面完全一致的部分可以复用，从出现差异的位置重新计算。
例如两份讲义的前 10 页完全相同，第 11 页开始不同，那么前 10 页的笔记可以继续使用，第 11 页之后要重新整理。
因此，在支持前缀缓存的 API 中，把固定的系统提示词和长文档放在前面，把每次变化的问题放在后面，通常更容易命中缓存。具体命中规则仍要以厂商文档为准。例如 DeepSeek 的硬盘缓存说明明确写明，缓存按前缀单元匹配，并采用尽力而为的方式，不保证每次都能命中。
训练和推理的区别，最后放在一张表里
| 维度 | 训练 | 推理 |
|---|---|---|
| 主要任务 | 修改模型参数 | 用已有参数生成答案 |
| 内存里主要放什么 | 权重、激活值、梯度、优化器状态 | 权重、KV Cache |
| 单 token 内存代价（以 8B 模型为例） | 约 8.7 MB（激活值） | 约 0.25 MB（KV Cache） |
| 常见瓶颈 | 数据太多，显存装不下 | 数据读取不够快；长上下文和高并发下也可能装不下 |
| 主机内存和 SSD 的作用 | 保存数据集、checkpoint，以及卸载的训练数据 | 保存暂时不用、但可能复用的 KV Cache |
| 常见优化思路 | 分片、卸载、重计算 | 缓存复用、分层存储、压缩和预取 |
切换模式，看两个阶段在任务、内存、瓶颈和优化思路上的根本差异。
修改模型参数，让模型学会新东西。
数据需求约是显存容量的 1.5 倍——装不下的那部分就是瓶颈所在。
显存带宽只能填满 GPU 需求的 40%——数据供不上，算力闲着。长上下文和高并发下也可能装不下。
保存数据集、checkpoint、以及被卸载出去的训练数据。
训练侧很多优化，是用更多通信和计算来换取更少的显存占用。
训练侧很多优化的目标，是用更多通信和计算减少显存占用。推理侧很多优化的目标，是用缓存减少重复计算，并及时把数据送到 GPU。
收尾
AI 系统并不是只有"算力"这一项资源。模型能不能运行、回答得快不快、API 为什么这样定价，都和内存容量、内存带宽以及数据在不同存储层之间的搬运有关。
目前 HBM 仍然负责最需要速度的部分，主机内存和 SSD 则负责扩大容量、降低成本。后两者能帮 HBM 分担多少工作，取决于缓存能否命中，以及数据能否在 GPU 需要之前及时取回。
因此，新一代 AI 芯片除了公布算力，也会反复强调 HBM 容量和带宽。GPU 的峰值算力只说明理论上限；如果数据供应不上，实际利用率仍然上不去。