步骤 1：分词
在模型处理任何内容之前，您的提示会被拆分为 令牌 —— 小的文本块，每个块大约包含几个字符或一个词素。分词是确定性的且几乎瞬间完成；它只是针对模型词汇表的一次查找。模型永远不会看到原始文本，只会看到令牌 ID 序列。步骤 2：预填充（计算密集型）
预填充 是模型读取您整个提示的过程 —— 一次性处理您发送的所有令牌 —— 然后才开始生成回复。这一步是 计算密集型 的：GPU 正在对整个提示进行大量的矩阵运算，因此其性能取决于您的处理能力。 预填充有两个值得注意的影响：- 当回复开始缓慢时，您等待的就是这一步。发送提示与看到第一个令牌之间的延迟称为 首令牌时间 (TTFT)，这几乎完全是预填充时间。
- 它会构建 KV 缓存 —— 提示的运行记录，这样模型就不必在生成后续每个令牌时重新处理提示。有关该缓存在内存中的成本，请参阅 KV 缓存与上下文。
步骤 3：解码（内存带宽密集型）
预填充完成后，模型开始 解码：逐令牌生成回复。每个新令牌都被追加到序列中，下一个令牌基于迄今为止的所有内容进行预测。 解码的行为与预填充截然不同。在每一步中，模型都必须从内存中读取其权重（对于混合专家模型，则是仅读取活跃的专家）以及整个 KV 缓存。由于相对于需要移动的数据量，每个令牌产生的新计算量很少，因此解码是 内存带宽密集型 的 —— 它受限于数据从内存传输到计算单元的速度，而非您拥有的原始算力。 这就是 每秒令牌数 所衡量的指标，也是为什么：- 算力较低但内存更快的 GPU 可以在解码速度上超越拥有较慢内存的“更快”芯片。
- 更长的上下文会减慢解码速度，因为每一步都需要读取更多的 KV 缓存，此外还会占用更多内存（请参阅 KV 缓存与上下文）。
步骤 4：令牌流式返回
随着模型生成每个令牌，它会立即被解码回文本并流式传输到客户端 —— 这就是为什么您会看到回复逐字出现，而不是一次性全部显示。如果您使用 Tokios，此数据流将从您的本地后端通过连接器和网关传回发送请求的应用程序或智能体；有关这段传输路径，请参阅 Tokios 如何路由请求。内存中各部分的分布
上述所有内容都发生在驻留在 VRAM（或统一内存）中的三个部分上：
权重是基础 —— 如果没有完全加载权重（或部分卸载；请参阅 内存与卸载），您无法运行模型。KV 缓存是随着对话或文档变长而增长的部分，这就是为什么“短提示有效但长提示导致内存不足”是一种常见的故障模式。
本页介绍工作机制。有关内存用量计算 —— 给定模型和上下文实际需要多少 GB —— 请参阅 内存与卸载 和 GPU 模型适配指南。
深入了解更多
KV 缓存与上下文
为什么更长的上下文会占用更多内存并减慢解码速度。
内存与卸载
内存用量公式以及模型无法完全装入内存时发生的情况。
量化
缩小权重精度如何改变内存和速度。
阅读模型卡片
在运行模型之前，在哪里查找模型的架构和上下文长度。
理解其运行方式后
上述所有内容都在您的机器上发生，针对运行在localhost 上的模型。一旦您对此感到满意，下一个问题是如何从您自己的机器以外的地方访问它。
为您的本地模型提供稳定的端点
Tokios 不选择、托管或微调您的模型 —— 一旦它在本地运行，Tokios 将其转换为一个稳定的、经过身份验证的端点，您可以从任何地方调用它。