纯CUDA推理引擎：在RTX 3060上跑8.5B参数MoE大模型

一个完全独立的CUDA推理引擎，无需Python和任何深度学习框架，即可在消费级显卡RTX 3060上运行8.5B参数的混合专家模型LFM2.5-8B-A1B，实现每秒超过100个token的推理速度。

• 原作者/维护者： g023 (https://github.com/g023/)
• 来源平台： GitHub
• 原始标题： cuda_inf - LFM2.5-8B-A1B pure C/C++/CUDA inference engine
• 原始链接： https://github.com/g023/cuda_inf
• 发布时间： 2026年6月6日
• 开源协议： MIT License

在大型语言模型推理领域，大多数解决方案都依赖于PyTorch、Transformers等重量级框架，这些框架虽然功能强大，但带来了庞大的依赖链和运行时开销。对于希望在资源受限环境或边缘设备上部署模型的开发者来说，这种"框架依赖"成为了难以逾越的障碍。

cuda_inf项目的诞生源于一个大胆的想法：能否完全抛开Python和深度学习框架，仅依靠纯CUDA C++代码，在消费级显卡上高效运行大型语言模型？这个项目给出了肯定的答案。

该项目针对的是LiquidAI开发的LFM2.5-8B-A1B模型，这是一个极具特色的混合架构模型：

• 总参数量： 85亿参数
• 活跃参数： 仅10亿参数在推理时激活
• 架构特点： 混合卷积+分组查询注意力(GQA)的MoE架构
• 词表大小： 128,000词汇

这种设计使得模型在保持较大参数规模的同时，推理成本显著降低，非常适合在单张消费级显卡上运行。

1. 纯CUDA推理引擎

项目的核心是一个单一的.cu文件，包含了所有必要的CUDA内核和主机端编排代码。这种设计带来了几个显著优势：

• 零依赖运行时： 无需Python解释器、无需PyTorch、无需Transformers库
• 极致精简： 仅包含推理所必需的核心算子实现
• 完全可控： 开发者可以精确控制内存布局、计算流程和优化策略

2. INT4权重量化

为了在12GB显存的RTX 3060上容纳8.5B参数模型，项目采用了激进的INT4分组量化策略：

• 量化粒度： 每128个权重为一组(G=128)
• 权重存储： 所有大型矩阵运算使用INT4存储
• 计算精度： FP16用于嵌入层和语言模型头部，FP32用于累积计算
• 内存占用： 权重仅需约4.76GB显存，为激活值和KV缓存留出充足空间

值得注意的是，项目作者有意识地跳过了2:4结构化稀疏性。虽然这种稀疏性可以进一步减少内存占用，但实验表明，对预训练模型直接进行2:4剪枝会严重破坏模型的连贯性。因此，项目选择了密集INT4量化来保持生成质量。

3. FP8 KV缓存与融合FlashAttention

KV缓存是Transformer推理的内存瓶颈。项目采用了创新的FP8 E4M3量化方案：

• 分组量化： 每64个token为一组共享一个FP16缩放因子
• 混合存储： 正在处理的"尾部"token保持FP16精度，完成后提交到FP8
• 融合内核： 单次在线softmax遍历即可完成注意力计算，同时读取FP8缓存和FP16尾部

这种设计在几乎不损失精度的前提下，将KV缓存内存占用减半。实验表明，与FP16基线相比，贪婪解码输出在60个token中有57个完全匹配，且保持完全连贯。

4. H2O智能缓存驱逐

项目还实现了一个可选的H2O（Heavy Hitter Oracle）缓存驱逐机制：

• 双区域设计： 始终保留最近的W个token（局部窗口）
• 注意力加权： 在较旧的token中保留累积注意力分数最高的N个
• 动态驱逐： 当缓存达到预算上限时，驱逐注意力分数最低的token

这种机制允许在显存极其紧张的情况下（例如预算只有48个槽位而上下文已增长到82个token），仍然保持生成连贯性。

5. Flash-Decoding长上下文优化

针对长上下文场景，项目实现了Flash-Decoding技术：

• 分块计算： 将KV键值范围拆分为16个块并行处理
• 全GPU利用： 相比原始的单warp扫描，充分利用整个GPU计算资源
• 常数时间： 每个token的计算成本不再随上下文长度增长

实验数据显示，在2K token上下文时，朴素单warp解码内核的性能会暴跌至约14 tok/s，而Flash-Decoding可以稳定维持约100 tok/s。

在RTX 3060 (12GB)上的实测性能：

场景	性能
短上下文解码	~105 tok/s
长上下文解码	~100 tok/s
相比朴素实现	约7倍提升

一个典型的推理示例：

$ ./build/engine --prompt "法国的首都是什么？用一句话回答。" --n 400
法国的首都是巴黎。
[engine] 生成83个token，耗时0.75秒 (110.9 tok/s)

项目包含一个头文件-only的字节级BPE分词器实现，完全兼容GPT-2的分词规则。经过验证，该分词器在聊天模板、代码、数字和空白字符的处理上与Hugging Face的encode/decode完全一致。

虽然运行时无需Python，但模型下载和量化仍需离线完成。项目提供了prepare.sh脚本，使用conda环境进行一次性预处理：

• 从Hugging Face下载原始模型
• 执行INT4量化
• 导出分词器配置