你是否遇到过这样的情况：给大模型发了一段长文档，它要“思考”很久才开始回答；而回答一旦开始，又是一个字一个字往外蹦，速度慢得令人着急。这背后并不是模型“偷懒”，而是受到了硬件的物理限制。
本文将从工程师的视角，拆解大模型推理的两个关键阶段，并给出最硬核也最简单的速度估算公式，帮你一眼看懂大模型的快与慢。
一、你需要知道的两个前提
在深入分析之前，先建立两个核心概念：
- Token：大模型眼中的最小语义单元，一个中文字、一个英文单词或标点都可能是一个 Token。你的输入和模型的输出，都会被切分成一串 Token。
- 模型参数：大模型本质上是一堆巨大的矩阵，存放着海量参数。这些参数全部存放在显存（VRAM） 中，等待 GPU 计算核心调遣。
二、输出 Token 的生成：一场显存带宽的极限赛
当大模型开始输出回复时，它是一个一个 Token 依次生成的，这个过程叫自回归解码。每生成一个 Token，都必须做一次完整的前向传播，这意味着：
GPU 计算核心必须把整个模型的所有参数从显存里搬出来，完整地读一遍。
假设一个模型大小是 40 GB（显存里占了 40 GB 空间），你显卡的显存带宽是 256 GB/s，那么理论上每秒钟最多能完成多少次这样的“全量搬运”呢？
这就是模型“一字一字往外蹦”的物理天花板。输出 Token 的生成速度，瓶颈是显存带宽，而不是计算能力。 因为对于单个序列的生成，计算量并不大，绝大多数时间都在等数据从显存运到计算核心。模型越大，带宽越低，这个上限就越低。
现实情况还会更慢一些，因为显存还要同时读写 KV 缓存（用于记录上下文）等中间数据，进一步挤占了带宽。但这个简单的除法，已经能让你快速评估一台设备跑某个模型的“理论极限速度”。
三、输入 Token 的处理：计算核心的并行压力测试
模型在输出第一个字之前，必须先“读懂”你给它的所有输入，这个阶段被称为预填充。你提交的提示词（Prompt）会被切分成成百上千个输入 Token，模型要一次性对它们全部进行处理。
这时的物理瓶颈完全变了。因为所有输入 Token 是一起进入模型、并行计算的，权重只需要从显存里读出一次，就能同时服务于所有输入 Token。这样一来，数据搬运的时间被海量计算分摊掉了，显存带宽不再是主要矛盾。
取而代之的，是纯粹的计算能力。模型需要瞬间完成几千个 Token 对应的矩阵乘法，这对硬件核心的 FLOPS（每秒浮点运算次数）是巨大考验。算力越强，每秒能处理的输入 Token 就越多；算力孱弱的设备，就会表现出“提交文档后要等很久才响应”。
例如，一台 AMD 迷你电脑运行 700 亿参数模型时，测算出的提示词处理速度只有 95 tokens/s。如果你丢给它一份 4000 Token 的文档，首 Token 延迟将高达：
这 42 秒里，用户只能盯着空白屏幕干等。输入 Token 的处理速度，瓶颈是硬件算力，也就是 GPU 核心的数量和频率。
四、一张表看清这两个阶段的差异
| 阶段 | 核心任务 | 物理瓶颈 | 直观感受 |
|---|---|---|---|
| 预填充（处理输入） | 并行吞下全部输入 Token | 计算能力（FLOPS） | 提交文档后，等待首字响应的时间 |
| 自回归解码（生成输出） | 逐 Token 生成回复 | 显存带宽 | 开始回复后，吐字的快慢 |
一句话总结：输入看核心算力，输出看显存带宽。
五、如何让大模型跑得更快？
理解了瓶颈所在，优化方向就非常明确了：
- 减小模型体积：通过量化技术将模型从 16-bit 压缩到 4-bit，相当于把“模型大小”这项分母直接缩小几倍，生成速度同比例提升。这是最直接有效的方法。
- 提高显存带宽：选择带宽更高的显卡（如从 256 GB/s 提升到 1 TB/s 以上），可以线性提升生成速度。
- 增强计算能力：使用拥有更多 Tensor 核心的高端 GPU，可以加速输入 Token 的并行处理，减少“等待首字”的时间。
- 增加批处理：在服务端同时处理多个用户的请求，可以让权重复用，提高总吞吐量，但单个用户的生成延迟依然受带宽限制。
了解这些现实的物理约束，下次你再遇到大模型“思考”很久或“打字”慢的时候，就能立刻判断：是设备算力不够，还是显存带宽顶到了天花板。
