大模型推理加速全链路：内存管理、编译优化、量化与并行策略

大模型推理成本已成为AI产业落地的核心瓶颈。随着模型参数规模向万亿级迈进、多模态智能体应用场景爆发，推理引擎需要应对算子实现、内存管理、量化压缩、异构调度与并行策略等多维度的技术挑战。本文整理自清华大学助理研究员金煜阳博士在 QCon 全球软件开发大会 2026 北京站的分享《大模型推理加速全链路：内存管理、编译优化、量化与并行策略》。 金煜阳系统介绍了其所在实验室在大模型推理加速全链路方面的探索，覆盖从底层算子优化到上层并行策略的完整技术栈。本文将逐一展开算子级性能调优中的细粒度图层优化方法、面向异构模型结构的KV Cache内存管理、编译与运行时协同的混合精度量化、基于负载特性的CPU-GPU异构调度，以及面向动态请求场景的自适应并行策略，最后介绍开源推理引擎赤兔在国产芯片生态中的实践成果。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 背景与挑战 人工智能的市场规模正在以超出预期的速度扩张。去年来自Precedence Research和艾瑞咨询的数据预测，到2030年全球AI市场规模将达到11万亿。但今年年初OpenAI的持续爆发，以及智能体应用的集中涌现，让这个预测数字显得保守了许多，我相信它一定会再往上调整不少。与此同时，中国AI产业也处于快速发展期。从企业数量、人才培养、论文专利等维度与美国对比，我们在产业界和顶尖人才方面仍有差距，但追赶速度极快，可以说正在从跟跑进入并跑的阶段。 智能体的兴起正在改变大模型的应用范式。基座大模型提供基础能力，智能体将其与人类已有的所有软件工具连接起来，从而赋能各行各业。但在这一片繁荣背后，推理成本构成了整个产业链中最重的开销。能够训练基座大模型的厂家屈指可数，但几乎每一个AI应用背后都在调用推理API。推理，以及推理所需的算力，就是这个产业背后的主要成本。 我们团队做的其中一件事情，就是构建一个大模型推理引擎，让它接在各类AI芯片之上、支撑各种模型、最终服务于上层的AI应用。底层芯片方面，除了英伟达的GPU，国内也有华为昇腾、摩尔线程、燧原、沐曦、天数智芯等厂商在奋力建设国产芯片生态。上层，则有VLM和SGLang等优秀的开源推理引擎。我们清华大学实验室也开源了一个推理引擎，名为赤兔——这个在后面会详细展开。 理解推理引擎的优化，需要先理解大模型推理的两个基本阶段：Prefill和Decode。当用户输入“今天中饭吃什么”这句话时，系统会把整句话一次性处理，这个阶段叫做Prefill，是计算密集型操作。之后，模型开始一个字一个字地输出回复，就像我现在说话一样，一个字接一个字地往外吐，这就是Decode阶段，也叫自回归生成。Decode阶段每一次生成新token，都需要访问之前所有的上下文数据，计算量不大，但访存量极大，因此是访存密集型操作。这两个阶段的特性截然不同，对底层资源的需求也完全不同，这为后续的异构调度和并行策略设计埋下了重要伏笔。 在这个基础之上，大模型的发展趋势给推理引擎带来了四个维度的挑战。首先是模型规模越来越大，DeepSeek宣称的V4参数已达万亿级别，实际规模可能更大。其次是模型架构日益复杂。智能体场景下，用户与模型长期对话，上下文越来越长，还会从工具调用中产生视频、图片等多模态信息。架构层面，除了主流的MoE（混合专家）结构，千问Next等模型还采用了混合注意力模式：一部分是传统的Full Attention，另一部分是Mamba这样的线性注意力。这些异构架构对算力的需求分布完全不同，推理引擎必须具备足够的灵活性来应对。 算子优化 从高性能计算的基本原理出发，推理系统的性能取决于五个关键维度：算子优化、内存管理、模型量化、异构调度和并行优化。算子优化是最底层的能力，就像一个公司里每个人的单兵作战能力。如果每个算子的执行效率都不高，再好的系统调度也无济于事。 去年DeepSeek的开源周活动很好地印证了这一点。他们陆续发布的FlashMLA和DeepGEMM等子模块中，有两个直接与算子实现相关，另外两个与并行通信相关。这说明，底层算子的性能是整个系统的基石。问题在于，现代AI硬件的算力增长迅速，但新功能的复杂性也在急剧上升。以Tensor Core为例，GPU原本只有通用的CUDA Core做简单运算，但为了加速深度学习中的张量计算，英伟达专门加入了Tensor Core。如何将Tensor Core与CUDA Core协同调度，如何利用Distributed Shared Memory等新硬件特性来缓解访存瓶颈，就成了算子实现中的关键难题。硬件为大模型负载而设计新特性，软件必须跟上才能把硬件性能榨干——这是一个相辅相成、持续迭代的过程。 手写算子可以针对特定形状达到极致性能，但问题在于，模型在并发度变化时会产生不同形状的算子切分，而每种形状的最佳实现都不同。FlashMLA是一个典型例子——如果针对特定形状手工优化，性能远优于自动编译器Triton生成的代码。但为每一种形状都手写算子，开发成本极其高昂。而用Triton自动编译虽然省力，性能又大打折扣。这中间的根本原因，就是编译器难以自动适配不同硬件架构的底层特性。 编译过程包含了多个重要环节，我在这里做一个高度简化的说明。深度学习代码首先被抽象为计算图（这个概念由TensorFlow首倡），然后在图层进行优化：算子融合、计算等价或不等价变换等。融合后的算子再调用算子库或进行自动代码生成，最终才能在芯片上运行。在图层面，不同芯片架构需要不同的算子聚合或拆分策略；在算子层面，又涉及计算与访存的掩盖、异步流水线调度等细节，每种芯片设计各不相同。即使是英伟达自家的H系列，H20和H100的计算访存能力不同、显存大小不同，所需的调度策略也不同。把这一切全部交给编译器自动完成，难度极大。 我们团队在图层变换和算子代码生成这两个方向都做了工作，这里重点介绍其中一项成果——FlashTensor，这项基于张量属性的细粒度图层优化工作发表在去年的领域顶会上。这个工作的出发点是一个观察：模型参数量和上下文长度都在增长，但增长速度不同。更大参数量带来更高精度，这是Scaling Law的核心结论；更长上下文带来更好的记忆能力，这一点在代码智能体中体现得尤为明显。如果模型只能处理200K上下文，当对话内容超出时，它只能将200K压缩成10K作为背景知识，再进行下一轮处理。而如果上下文窗口达到百万token级别，模型就能持续保留最无损的信息，记忆能力显著增强。但问题是，上下文长度的增长速度快于参数规模的增长，这导致计算过程中中间结果的变化幅度不一致。举个例子：第一个算子算出的中间结果写入显存，第二个算子再读取。如果上下文的维度增长更快，通过不同维度的乘法运算，中间结果会爆炸式增大——将中间结果写入显存的过程反而成为瓶颈，前后计算本身可能并不大。 现有的粗粒度融合处理方式有两种。第一种是把第一个和第二个算子合并，消除了中间结果的写入读出开销。但合并后的计算图依赖关系复杂，并行度受限，无法让GPU上几千个线程同时工作，硬件效率难以发挥。第二种情况是，如果编译器识别出算子无法合并，就拆分成很多小算子。这时中间结果的访存开销极大——虽然每个小算子计算时间短，但不间断地写入读出中间张量会