🔧 推理引擎 · 技术深潜

单机跑起 617B 模型、吞吐最高提升 7 倍：清华开源推理引擎「赤兔」的全链路加速法

大模型推理成本，正在成为 AI 产业落地最重的开销。清华大学助理研究员金煜阳博士在 QCon 2026 北京站系统拆解推理加速全链路——从细粒度算子优化、KV Cache 内存管理，到混合精度量化、CPU-GPU 异构调度与自适应并行策略。其团队开源的推理引擎「赤兔」，已在国产芯片上跑出与主流引擎持平的性能。

综合公开信息整理• 2026-07• 全文约 5 分钟读完
#大模型推理 #推理引擎 #模型量化 #异构计算
7x 异构调度吞吐极限提升
4.92x 异构 KV Cache 吞吐提升
617B 单机装下完整模型参数

⚡ 30 秒速览

  • 五个维度都有硬数据：算子优化端到端提速 1.5–1.86 倍 · KV Cache 管理吞吐提升 4.92 倍 · 混合精度量化比 AWQ 快 6 倍 · 异构调度吞吐提升 7 倍。
  • 为什么还有优化空间：Prefill 计算密集、Decode 访存密集，负载特征完全不同——统一放在 GPU 上，本身就是一种浪费。
  • 开源引擎「赤兔」：A800 集群上快于 vLLM；华为昇腾、沐曦等国产芯片已适配；FP8 软件等效加速，精度持平。
  • 最激进的一次实验：单台 CPU+GPU 机器跑起 617B 参数完整模型，吞吐约为 vLLM 8×H20 配置的一半。
  • 诚实注脚：这是资源悬殊下的「够用」，不是全面超越——但 617B 被装进单机的方向，已被证明可行。

01推理成本：AI 产业最重的开销

能训练基座大模型的厂家屈指可数，但几乎每一个 AI 应用背后都在调用推理 API。推理，以及推理所需的算力，就是这个产业背后最主要的成本。

智能体正在让这个成本结构发生位移。基座模型提供基础能力，智能体把模型与人类已有的软件工具连接起来——多轮对话、工具调用、长上下文，每一次交互都在消耗更多算力。模型参数向万亿级迈进，上下文窗口从 200K 向百万 token 攀升，推理引擎面对的不再是单点性能问题，而是一个多维度的系统挑战。

万亿级模型参数规模
（DeepSeek V4）
200K→1M+上下文窗口
目标长度
4 维度规模 / 架构 /
上下文 / 多模态
2 阶段Prefill /
Decode

注：四维挑战中，「架构」指 MoE 之外还出现了 Full Attention 与 Mamba 线性注意力混合的异构结构，不同部分对算力的需求分布完全不同。

02一切优化的起点：两个阶段，两种脾气

理解推理引擎的优化，需要先回到两个基本阶段。当用户输入「今天中饭吃什么」，系统一次性处理整句话——这是 Prefill。之后模型逐字生成回复，每产生一个新 token 都要访问之前全部上下文——这是 Decode。

⚡ Prefill 阶段

计算密集型。一次性读完整个输入，重在吞吐。整句话被编码成模型能理解的形态，一次算完。

📖 Decode 阶段

访存密集型。逐字生成回复，每次生成都要翻一遍全部历史上下文。计算量不大，访存量极大。

一个吃算力，一个吃带宽。

两者对底层资源的需求完全不同——正是这种差异，为后面的异构调度与并行策略设计埋下了伏笔。

03算子优化：把 3.45% 的效率拉回 80%

算子优化是最底层的能力，就像一个公司里每个人的单兵作战能力。若每个算子都跑不高效，再好的系统调度也无济于事。

但难点在于形状的动态变化。手写算子针对特定形状性能极优，可并发度一变，算子形状就变，每种形状的最佳实现都不同。编译器自动生成省力，性能却大打折扣——在 A100 上，一个 Sparse Attention 算子的实测计算效率仅有 3.45%。

Sparse Attention
优化前实测
3.45%
正常预期
计算效率参考线
80–90%

注：柱形宽度按计算效率百分比绘制。3.45% 为 A100 实测数据，差距接近一个数量级。

团队提出的方案名为 FlashTensor——一项基于张量属性的细粒度图层优化工作。它不再粗粒度地合并或拆分算子，而是更细致地审视算子间的依赖结构，定义细粒度属性，在最大化并行度的条件下重组计算。

端到端推理时间提升 1.5–1.86 倍 多模型测试于 A100 / H100，对比 TensorRT、PyTorch 原生、TVM、CUTLASS 等基线

注：衡量的是端到端推理时间，而非单个算子加速比——整体快，才是真的快。

04内存管理：异构模型的 KV Cache 怎么管

KV Cache 是模型对上下文的「记忆」。对话越长，记忆越大，显存很快不够用。业界已有两条路：压缩记忆——只保留最有价值的 token；或借鉴操作系统页表机制，做动态内存分配。

团队关注的是一个更前沿的场景：异构大模型。

未来的主流模型，可能同时长着两种记忆系统。

Full Attention 做压缩滑动窗口筛选信息，Mamba 做线性注意力——不同的注意力层需要不同的内存分配机制。用统一的大页表管理所有层，仍然存在大量浪费。

🧠 多粒度 KV Cache 内存管理

  • 将大页与定制化小页结合，按注意力类型分配粒度，尽可能消除碎片。
  • 面向 Full Attention + Mamba 异构模型架构设计，适配未来主流形态。
  • 在 H100 平台上针对新型异构模型完成测试。
结果：与当前最优 vLLM 方案相比，整体吞吐量提升 4.92 倍。

05量化：混合精度如何让模型「说人话」

参数规模与显存增长之间存在巨大的剪刀差。全量低精度量化后，模型开始「不说人话」，输出质量严重下降。混合精度是当前主流解法：参数和计算中只有极少数「离群值」需要保持高精度，剩余 99% 用低精度处理。

但直接落地，效率只剩 30%。

为什么？

单独调度离群值的开销极大——就像给团队里每个人单独发私信。团队从编译与运行时两个层面对离群值数据的重构和调度流程做了系统性改进，大幅降低了专门调度的开销。

1.5–1.6xNVIDIA 算子性能
对比当前最优方案
6x对比
AWQ 量化方案
2x+燧原 S60
性能提升
≈持平模型精度
对比 FP16

注：燧原 S60 为国产加速卡，端到端精度验证表明混合精度量化后模型精度与原始 FP16 基本持平。

06异构调度：把活分给 CPU 和 GPU

智能体工作模式下，用户不只关注逐字输出速度，还关注多轮对话效率——每一轮对话都会形成新的上下文，需要重新 Prefill。于是两个阶段都可能成为瓶颈。

既然 Prefill 吃算力、Decode 吃带宽，为什么不让不同的硬件各干各的？

进一步拆解 Decode：Attention 层随 Batch Size 增大可扩展性强，MLP 层扩展性弱。CPU 内存大、算力弱——适合承接访存密集、计算需求小的部分；GPU 继续专注计算密集的 MLP。这个思路被命名为 FastDecode。

CPU 承接访存密集→GPU 专注计算密集→Batch Size 拉大→吞吐提升 7 倍

注：链路展示 FastDecode 的核心逻辑。「7 倍」为特定场景（Batch Size 可拉至很大的负载）下的吞吐收益。

在此基础之上，团队又推出了进一步优化的 FastDecode Max。

07并行策略与「赤兔」：不存在一劳永逸的方案

全量参数需要 9 张 H100 才能放下。DeepSeek 的部署配置很有代表性：Prefill 阶段用 32 张 GPU，Decode 阶段用 144 张 GPU；Attention 用张量并行加数据并行的 4×8 模式，MoE 直接 32 个专家并行。

不同子结构需要不同策略。更复杂的是，负载本身还在潮汐波动——用户白天集中请求、晚上几乎停歇。推理引擎必须能根据负载切换策略：压力大时吞吐优先，压力小时降低时延。

这就是赤兔在做的事。

开源推理引擎「赤兔」 · 关键落地数据

  • A800 集群：FP8 软件等效加速，速度优于 vLLM，精度持平。
  • 华为昇腾：FP4 量化能力，更少资源提供较高性能。
  • 沐曦芯片：已完成适配。
  • 单机 CPU+GPU：成功装载并运行 617B 参数完整模型。

需要诚实指出：那套 617B 单机方案的吞吐量，大约只有 vLLM 8×H20 配置的一半。但一边是 1 张 GPU 加 CPU，一边是 8 张 H20——资源相差一个数量级。

这个「一半」，恰恰说明资源利用率还有巨大的挖潜空间。

编辑核心判断

大模型推理优化没有单点银弹。当参数向万亿级迈进，把算子、内存、量化、调度与并行当作一个整体来设计的「全链路工程能力」，将比任何单一算法创新都更难复制——这也正是自研推理引擎真正的壁垒。

▶现在就能用

赤兔推理引擎已开源，当前版本 0.5.4，0.6 版本将聚焦智能体推理。GitHub 搜索 「Chitu」 推理引擎即可找到开源仓库。

GitHub 搜索 Chitu 推理引擎