How AI inference works, clearly explained

清晰解释 AI 推理的工作原理

Component | Article_teaser

2026年8月26日

7分钟阅读

AI 推理

Cedric Clyburn

开发者倡导者

Subpattern | social_share_set

Component | social_share

分享

Subpattern | subscribe

Component | social_icon

订阅 RSS

Component | Icon

© Red Hat, Inc. CC-BY-4.0 授权

Subpattern | results_nav

组布局

Component | Nav_links

• 返回所有文章

Component | Generic

如果您正在使用或构建大型语言模型（LLMs），那么最重要的概念可能是理解推理和键值（KV）缓存的工作原理。这是因为无论您是在使用编码代理、检索增强生成（RAG）还是微调，推理都是每次向模型发出请求并获得响应时发生的过程（也是所有成本产生的地方）。

训练只发生一次，而推理会在每次用户发送提示时发生。因此，让我们逐步了解其工作原理、KV 缓存的作用，以及大多数团队用于节省基础设施成本和减少延迟的优化方法。

推理是一个堆栈，而非模型文件

图1：提供模型需要三个组件协同工作：权重、推理服务器和底层硬件。

您计算机（或 HuggingFace）上的模型目前还无法为任何人提供服务。要实现推理，需要以下三个组件协同工作：

• 模型权重：包含数十亿个学习参数的文件（如 Kimi、GLM、Qwen 或您选择的其他模型）。

• 推理服务器：如 vLLM 这样的软件，负责加载模型、管理传入请求并处理即将介绍的优化。

• 硬件加速器：通常是执行繁重数值计算的 GPU。

您可以跳过中间层，直接使用 PyTorch 在 GPU 上运行模型。这对于笔记本或单个用户来说运行良好。但一旦需要同时为大量用户提供服务，推理服务器才能使 GPU 在生产规模上实现可用性（就像您本地打开 HTML 文件与通过 Apache HTTP 服务器提供服务的区别）。

模型每次生成一个标记

图2：每次前向传递仅生成一个新标记，然后将其反馈以生成下一个。

大型语言模型不会一次性生成长响应，而是每次生成一个标记，且每个新生成的标记都依赖于之前的所有标记（包括模型刚刚生成的标记）。

例如，以提示“快速的棕色”开始：

• 模型预测“狐狸”→ 添加到结果中

• “快速的棕色狐狸”→ 预测“跳跃”→ 添加到结果中

• 依此类推，直到模型生成特殊结束序列标记。

这就是自回归生成，人们低估的是，响应中的每个标记都需要完整地通过模型一次。500个标记的回答意味着模型需要运行500次，这里您可以看到计算需求如何开始增长。

为什么存在 KV 缓存

图3：每个标记都会通过每层的注意力模块，将其查询与之前所有内容的键和值进行比较。

在每次传递过程中，标记会转换为嵌入（数值表示），通过堆叠的变压器层进行处理，而每一层都有一个自注意力模块，让标记相互查看。这就是内存问题的起点。

注意力机制为每个标记计算三个向量：

• Q（查询）：该标记想从上下文中了解的内容

• K（键）：该标记所持有的信息类型

• V，即值：其实际内容

要生成下一个标记，需要将它的查询与迄今为止所有标记的键进行比较，并对值进行加权求和。

但！真正重要的是：查询仅用于当前标记。键和值需要用于整个历史记录，但它们不会改变。第4个标记的键和值在第5步时与第4步时完全相同。

图4：由于早期标记的键和值永远不会改变，因此它们只需保存一次并重复使用，而不是在每一步都重新计算。

因此，我们不再在每一步重新计算它们，而是将它们保存在GPU内存中，仅计算新标记的K和V。这就是KV缓存，它会在模型的每一个N层中发生，因此节省的内存空间会乘以N。

KV缓存究竟会占用多大空间？

每个标记在每一层都需要存储其键和值，且每层有多个并行的键值头（KV heads）。计算公式为：

2 × num_layers × num_kv_heads × head_dim × dtype_bytes

以gpt-oss-120b为例：36层，8个KV头，头维度为64，每个值占2字节。每个标记大约需要72 KB空间，但gpt-oss只在一半的层上保存完整历史记录，因此实际增长空间约为每个标记36 KB。

• 2k（典型对话轮次）：约75 MB
• 8k（标准生产级）：约300 MB
• 32k（长文档或代码库）：约1.2 GB
• 128k（gpt-oss最大值）：约4.8 GB

这还是一个专为高效服务而设计的模型。一个密集型70B模型（如Llama 3.3 70B），拥有80层和128个头维度，每个标记需要约320 KB空间，相同对话的内存消耗是前者的9倍。这就是为什么模型架构选择对控制AI成本至关重要。

你的GPU预算都花在哪里？

像gpt-oss-120b这样的模型可以装入一块NVIDIA H100 80 GB GPU。这在模型发布时是个重大突破，但加载完权重后，卡上只剩下约15-20 GB内存用于KV缓存和推理开销。现在为真实用户提供服务变得棘手，例如：

• 如果服务器按请求保留内存，按请求可能达到的最大上下文长度分配内存（这是旧方法的做法），那么每个请求都会消耗4.8 GB内存，不管是否实际使用。这在H100上只能同时支持3个用户。糟糕。

• 如果按每个请求实际使用的内存进行分配，一个典型的8k请求仅消耗300 MB。同样显卡、同样模型，可以支持50或60个用户。虽然使用的是相同硬件，但差异完全在于GPU内存的管理方式，这也说明这个话题的重要性。

图5：为最坏情况下的上下文长度保留内存会导致大部分KV缓存空间空闲。

生产级推理服务器（如vLLM）如何解决这个问题？

主要通过以下三种方式：

1. PagedAttention

PagedAttention将KV缓存拆分为多个固定大小的小块，这些块可以分散在内存任意位置，通过一张表记录每个请求的块所在位置。不会为可能永远用不到的上下文保留内存。如果你在操作系统中使用过虚拟内存，这个概念会很熟悉，这个想法正是来源于此。

图6：PagedAttention将缓存分散到多个固定大小的小块中，并通过查找表跟踪这些块，无需提前预留任何内存。

2. 连续批处理

通过连续批处理，不需要等待整个批次完成。已完成的请求会离开，新请求在槽位释放时加入。这样GPU可以持续获得新的计算任务。

Figure 7: 静态批处理使每个请求都等待最慢的那个，而连续批处理会立即填充每个释放的插槽。

3. 前缀缓存

当请求共享前缀（系统提示、检索到的文档、编码代理上下文中相同的仓库文件）时，会复用已缓存的K和V，而不是重新计算。

Figure 8: 当请求共享相同的开头文本时，会复用该前缀已执行的工作，而不是重新计算。

这些方法不会改变模型本身，但会改变运行模型的效率。

然后是模型本身的压缩

量化是一种通过降低精度存储权重（或激活值）的方法，从而减少占用空间并加快计算速度。大多数模型默认使用BF16（每参数16位）格式。当降至FP8（8位浮点数）或INT8（8位整数）时，内存使用量可减少一半而不影响基础精度。若进一步降至4位，内存占用仅为原来的四分之一。例如，Red Hat AI Hugging Face仓库中所有量化模型的精度均可恢复至其基础精度的99%以上。

gpt-oss-120b模型是一个典型案例，因为相关工作已由他人完成。在BF16格式下，该模型包含117B参数，权重体积约为234GB，需要3块80GB显卡才能加载。OpenAI使用MXFP4量化方法对MoE（专家混合）权重进行微调后，模型体积降至80GB以下，可运行在单张显卡上。

• BF16（假设）：约234GB → 3块显卡

• MXFP4（原生版本）：可适配一块80GB显卡

Figure 9: 低精度数值格式通过牺牲范围和细节换取更小的内存占用。

大多数模型并非以这种方式提供，这时就需要自行实施量化，或前往HuggingFace查看我们的压缩模型。最终，量化带来两大优势：量化权重可减少每次前向传播过程中从高带宽内存（HBM）向静态随机存取内存（SRAM）传输的数据量，这是延迟优化；量化激活值可使张量核心以更低精度执行计算，提升每秒操作数，这是吞吐量优化。仅量化权重的方案（如W8A16，权重8位、激活值16位）可实现前者，而同时量化权重和激活值的方案（如W8A8，权重和激活值均为8位整数）可实现两者。

Figure 10: 更小的权重能更快进入GPU的高速内存，低精度计算在张量核心上的吞吐量显著提升。

实际上，FP8可将内存需求减少一半，同时在精度影响最小的情况下提升最高达1.6倍的吞吐量。而且，你并不会因此降低模型性能。通用后训练量化（GPTQ）、激活感知权重量化（AWQ）和SmoothQuant等校准技术会使用小规模代表性数据集，确定哪些权重最为关键并加以保护，因此精度下降通常不超过百分之一。

训练是一次性成本；推理是持续发生的成本，且占据了大部分费用。每个token都需要一次完整的前向传播。KV缓存会随着上下文长度和并发用户数的增加而增长，其管理是推理服务器的主要职责。在我们的示例中，相同GPU上朴素部署与优化后的部署在并发用户数上差距约为3人 vs 50人。正确实现推理，可最大限度发挥现有硬件的性能。

附言：如果你喜欢这个内容！

如果你想亲自实践，我们与DeepLearning.AI和Red Hat共同打造了一门免费课程，提供动手操作环节：使用LLM Compressor对Qwen模型进行量化并测量精度权衡，使用vLLM进行服务部署，使用GuideLLM进行基准测试，使用lm-eval进行评估：使用vLLM实现快速且高效的LLM推理。

Block | Dynamic pattern deluxe promo

Component | Band_header

Resource

开始AI推理之旅

了解如何构建更智能、更高效的AI推理系统。学习量化、稀疏性以及vLLM等高级技术（由Red Hat AI支持）。

Component | spacer

Component | Cta_multi_basic

Subpattern | simple_cta

Component | CTA

获取资源

Deluxe mbox

Component | Card_header

关于作者

Subpattern | speaker

Card layout

Component | Image_embed

Component | Person

Cedric Clyburn

Subpattern | social_links

Cedric Clyburn (@cedricclyburn) 是Red Hat的高级开发者倡导者，是一位热衷于软件技术的专家，拥有Kubernetes、DevOps和容器工具背景。他有在DevNexus、WeAreDevelopers、The Linux Foundation、KCD NYC等会议演讲和组织会议的经验。Cedric热爱开源，致力于让开发者的日常工作更轻松！目前常驻纽约。

阅读该作者的更多文章

类似文章推荐

Dynamic pattern

Blog post

为什么AI基础设施必须开源构建

扩展智能体AI：llm-d如何实现基础设施主权

Subpattern | card_flex

Subpattern | text_basic

继续探索

• 什么是智能体AI？ 文章

• 预测性AI与生成性AI 文章

• 构建生产级AI/ML环境的关键考量 电子书

• 以Ansible方式实现生成性AI 视频

• 通过现代应用平台实现创新与转型 电子书

Keep Exploring mbox

Subpattern | simple_text

按频道浏览

探索所有频道

Pattern | raw_html

自动化

关于IT自动化在技术、团队和环境中的最新动态

人工智能

关于使客户能够随时随地运行AI工作负载的平台的最新消息

混合云

探索我们如何通过混合云构建更灵活的未来

安全

关于我们在不同环境和技术中降低风险的最新动态

边缘计算

关于简化边缘平台操作的最新动态

基础设施

关于全球领先的企业的Linux平台的最新动态

应用程序

关于我们解决最复杂应用程序挑战的解决方案

虚拟化

企业虚拟化的未来，适用于本地或跨云的工作负载