万亿参数大模型推理成本高企，清华团队开源赤兔引擎全链路加速

推理成本成为产业落地的核心瓶颈

大模型推理成本已经成为 AI 产业落地的核心瓶颈。随着模型参数规模向万亿级迈进、多模态智能体应用场景爆发，推理引擎需要应对算子实现、内存管理、量化压缩、异构调度与并行策略等多维度的技术挑战。清华大学助理研究员金煜阳博士在 QCon 全球软件开发大会 2026 北京站分享了大模型推理加速全链路的探索成果。

金煜阳系统介绍了其所在实验室从底层算子优化到上层并行策略的完整技术栈，覆盖细粒度图层优化方法、面向异构模型结构的 KV Cache 内存管理、编译与运行时协同的混合精度量化、基于负载特性的 CPU-GPU 异构调度，以及面向动态请求场景的自适应并行策略，最后还介绍了开源推理引擎赤兔在国产芯片生态中的实践成果。

智能体兴起改变应用范式

人工智能市场规模正在以超出预期的速度扩张。去年来自 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 上几千个计算核心充分发挥。第二种方式则是在图层进行更细粒度的变换，FlashTensor 正是基于张量属性的细粒度优化方法，通过分析张量的形状、内存布局和访问模式，在不牺牲并行度的前提下减少中间结果的显存读写。

KV Cache 内存管理应对异构结构

内存管理方面，KV Cache 是大模型推理中占用显存最大的部分之一。随着上下文长度增长，KV Cache 的显存占用线性增加，成为限制并发请求数量的关键因素。金煜阳团队针对异构模型结构设计了专门的 KV Cache 内存管理方案。传统模型结构相对统一，KV Cache 的分配和释放策略可以简单固定。但面对混合注意力模式、多模态输入等异构结构，不同层的 KV Cache 大小、生命周期和访问频率差异巨大，需要更灵活的内存管理策略。

具体来说，异构模型结构中，Full Attention 层和线性注意力层的 KV Cache 需求完全不同。线性注意力层的状态可以压缩为固定大小的状态向量，不需要像 Full Attention 那样保存完整的键值对。如果统一按照 Full Attention 的方式分配内存，会造成大量浪费。金煜阳团队的方法是根据不同层的结构特性，动态调整 KV Cache 的分配策略，在保证推理精度的前提下最大化显存利用率。

混合精度量化协同编译与运行时

量化压缩是降低推理成本的另一条重要路径。金煜阳团队提出了编译与运行时协同的混合精度量化方案。传统量化方法通常在模型训练完成后统一进行，所有层使用相同的量化精度。但不同层对量化的敏感度不同，统一量化会导致某些层精度损失过大。混合精度量化的思路是根据每层的敏感度分配不同的量化精度，敏感层保留较高精度，不敏感层使用较低精度。

编译与运行时协同的关键在于，编译器在编译阶段可以获取模型的完整结构信息，分析每层的计算特性和数据分布，制定量化的精度分配方案。运行时则根据实际的输入数据和硬件特性，动态调整量化参数。这种协同方式比单纯的静态量化或动态量化更加灵活，能够在精度和性能之间取得更好的平衡。

CPU-GPU 异构调度基于负载特性

异构调度方面，金煜阳团队关注的是 CPU-GPU 的协同工作。大模型推理中，Prefill 阶段是计算密集型，适合 GPU 处理；Decode 阶段是访存密集型，计算量不大但需要频繁访问内存。不同阶段的负载特性不同，对硬件资源的需求也不同。金煜阳团队提出的基于负载特性的 CPU-GPU 异构调度方案，根据请求所处的阶段和负载特征，动态决定将任务分配给 CPU 还是 GPU。

这种调度策略的核心是识别每个请求的实时负载特性。对于计算密集型的 Prefill 请求，优先分配给 GPU；对于访存密集型的 Decode 请求，如果 GPU 的计算资源已经饱和，可以将部分请求调度到 CPU 上执行，充分利用 CPU 的内存带宽和缓存资源。通过这种方式，可以在不增加硬件成本的前提下提升整体吞吐量。

自适应并行策略应对动态请求

并行策略方面，大模型推理面临的一个核心问题是请求的动态性。不同时间段的请求数量、请求的上下文长度、请求的生成长度都在不断变化。固定的并行策略无法适应这种动态变化，要么在请求高峰时资源不足，要么在请求低谷时资源浪费。金煜阳团队提出了面向动态请求场景的自适应并行策略，根据实时的请求负载动态调整并行度。

自适应并行策略需要解决两个关键问题：一是如何准确预测未来的请求负载，二是如何在不中断服务的前提下调整并行配置。金煜阳团队的方法结合了历史请求数据和实时监控信息，通过在线学习的方式预测短期内的负载变化趋势，并提前调整并行策略。这种自适应机制能够在保证服务质量的同时，最大化硬件资源的利用率。

赤兔引擎在国产芯片生态中的实践

最后，金煜阳介绍了开源推理引擎赤兔在国产芯片生态中的实践成果。赤兔是清华大学实验室开源的推理引擎，目标是接在各类 AI 芯片之上，支撑各种模型，最终服务于上层的 AI 应用。在国产芯片方面，赤兔已经适配了华为昇腾、摩尔线程、燧原、沐曦、天数智芯等多家厂商的硬件平台。

国产芯片生态的建设面临诸多挑战，包括硬件架构差异大、软件工具链不完善、算子库覆盖不全等。赤兔引擎通过统一的抽象层屏蔽底层硬件差异，向上提供一致的接口，使得模型开发者无需针对每种芯片单独优化。同时，赤兔引擎集成了金煜阳团队在算子优化、内存管理、量化压缩、异构调度和并行策略等方面的研究成果，为国产芯片上的大模型推理提供了全链路的加速能力。

全链路优化是必然方向

从底层算子优化到上层并行策略，大模型推理加速需要全链路的协同优化。单一层面的优化往往难以取得显著效果，因为推理系统的性能瓶颈可能出现在任何一个环节。金煜阳团队的探索表明，只有将算子实现、内存管理、量化压缩、异构调度和并行策略作为一个整体来考虑，才能充分发挥硬件的性能潜力。

随着模型参数规模继续增长、智能体应用场景不断扩展，推理成本的压力只会越来越大。开源推理引擎赤兔的实践为国产芯片生态中的大模型推理提供了一个可行的技术路径。未来，随着更多硬件特性的引入和软件技术的进步，推理引擎的优化空间仍然巨大，全链路优化将成为大模型推理加速的必然方向。