阿隆自留地

文章摘要

有人在RTX 3090上跑通了Llama 3.1 70B。

RTX 3090有24GB显存，而Llama 70B在Q4量化下约需40GB内存——缺口是真实的，不是数学误差。这个项目（NTransformer）的做法是：把NVMe SSD变成显存的溢出层，用三级缓存体系（VRAM→内存→NVMe）和双缓冲流水线（SLEP streaming）同步NVMe读、PCIe DMA和GPU计算，加上层跳过（layer skipping）技术削减实际计算量。最终结果：Llama 70B的推理速度约0.5 tok/s。

0.5 tok/s不实用——你等一个完整回复要等十几分钟。但开发者自己说得清楚：这是一个概念验证，证明这件事「技术上是可行的」，并系统记录了每一个优化措施带来的加速比（基线mmap方法是0.006 tok/s，NTransformer达到0.5 tok/s，即83倍加速）。

更值得关注的是这个项目的起点：作者从在PlayStation 2（32MB RAM）上跑语言模型的实验入手，被PS2架构里的直接VRAM指令路径启发，最终开发出了绕过CPU内存访问、直接将NVMe数据DMA到GPU显存的技术方案。

背景与问题

NVMe到底有多慢，快到什么程度

理解NTransformer需要先建立几个数量级的直觉。

一张RTX 3090的显存带宽（HBM到GPU核心）约为900 GB/s。PCIe Gen4 x16（CPU到GPU）的理论双向带宽约64 GB/s（单向32 GB/s）。NVMe SSD（PCIe Gen4的顶级型号）的顺序读取速度约7 GB/s。

这三个数字之间有2-3个数量级的差距。把NVMe用作显存溢出层，意味着每次缺显存时，数据传输速度会从900 GB/s降到7 GB/s，下降约128倍。

这是整个项目的基本物理约束，无法绕开，只能通过软件层面的各种手段尽量缩小影响。

消费级GPU跑大模型的需求从哪里来

LLM推理的主流服务路径是云端API（OpenAI、Anthropic、Google）——你发请求，远端数据中心里的H100集群响应。这条路对大多数用户是够用的。

但有一部分用户有明确的本地推理需求：隐私敏感（法律、医疗）；离线使用（无网络连接场景）；成本控制（大量批量推理时API费用可观）；实验性质（研究人员想精确控制推理过程）。

对这些用户来说，消费级显卡能跑多好、能跑多大的模型，是一个有价值的工程问题。RTX 3090（24GB）是目前消费级显卡里显存最大的主流型号（RTX 4090是24GB，RTX 5090是32GB），Llama 70B是当前开源高质量模型的主要档次，两者之间的能力差距精确地定义了"一块消费级显卡的能力上限"这个问题。

核心内容解析

3.1 NTransformer的技术架构

三级缓存体系（Tiered Caching）

NTransformer把Transformer模型权重按访问频率分配到三层存储：

L1 - VRAM Resident（显存常驻）：最频繁访问的层（Embedding层、最后几层Decoder等），常驻在24GB显存里，访问延迟和带宽最优（900 GB/s）
L2 - Pinned RAM H2D（钉固内存，主机到设备）：中等访问频率的层，在系统主内存里分配页锁定（page-locked/pinned）内存，通过PCIe DMA传输到GPU，带宽约32 GB/s
L3 - NVMe/mmap fallback（NVMe回落）：访问频率最低的层，从NVMe直接读取，速度约7 GB/s

Llama 70B在Q4_K_M量化下约40GB，超出24GB显存约16GB，这部分溢出到L2和L3。

SLEP Streaming（双缓冲流水线）

SLEP（Streaming Layer Execution Pipeline，名称是作者自取的）是一个双缓冲技术：在GPU处理第N层的同时，后台异步预取第N+1层的权重。

具体来说：

GPU计算第N层（使用当前在VRAM里的权重）
同时，DMA引擎从NVMe/RAM读取第N+1层的权重到另一个缓冲区
第N层计算完成后，立即开始第N+1层，权重已经到位

这将NVMe读取和GPU计算的时间从"串行叠加"变成了"并行重叠"。理论上，如果DMA速度足够快，GPU不会有等待时间。实际上，NVMe的7 GB/s远慢于GPU的处理速度，所以GPU还是要等待，但等待时间从"完整的NVMe读取时间"压缩到"NVMe读取时间减去GPU能并行的那部分"。

gpu-nvme-direct（用户空间NVMe驱动）

这是技术上最激进的部分：NTransformer实现了一个轻量级的用户空间NVMe驱动，绕过Linux内核的文件系统缓存层，直接将NVMe数据DMA到GPU的pinned memory。

传统路径：NVMe → 内核 → 文件系统缓存 → 用户空间内存 → GPU（通过PCIe DMA）
gpu-nvme-direct路径：NVMe → GPU pinned memory（直接DMA）

这减少了一次内存拷贝，也减少了内核调度的不确定性。代价是配置复杂：需要VFIO绑定NVMe设备（把NVMe从内核驱动移交给用户空间驱动），需要BIOS关闭安全启动、打开4G解码（Above 4G Decoding），AMD平台需要关闭IOMMU。

还有一个红字警告：永远不要把你的系统启动盘当做存储模型的NVMe去做VFIO绑定。VFIO会将设备整个交给用户空间程序控制，任何写操作都可能导致不可恢复的数据丢失。

Linux Kernel 6.12+ 兼容性问题

Linux 6.12内核移除了follow_pfn()这个函数，而NTransformer的GPU内存映射实现依赖它。作者提供了一个DKMS内核模块补丁来修复这个兼容性问题，但这意味着你需要编译和加载自定义内核模块——不适合不熟悉Linux内核构建流程的用户。

层跳过（Layer Skipping）

Transformer模型在推理时，并非每一层的贡献都同等重要。NTransformer的层跳过功能通过余弦相似度（cosine similarity）指标来"校准"每一层的重要性：如果跳过某一层后输出与正常输出的余弦相似度足够高，那么后续推理就默认跳过这一层。

实验结果：在Llama 70B的80层中，跳过约20层（25%）的情况下，质量损失可以接受，同时推理速度提升约25-30%。

这是一种类似于"模型剪枝"（pruning）的运行时优化，不同之处在于它是在推理时动态决策的，而不是在训练后静态剪掉权重。

3.2 基准测试结果

配置	速度（tokens/s）
Llama 8B Q8_0（全VRAM）	48.9
Llama 70B mmap基线	~0.006
Llama 70B L3 only	~0.08
Llama 70B SLEP streaming	~0.3
Llama 70B tiered + layer skip	0.5

83x倍加速的分母（0.006 tok/s）是使用Linux mmap从磁盘直接映射模型权重的原始方法，基本等同于"每次推理从磁盘读全量数据"。

一个有意义的对比：HN评论里有用户用AMD Ryzen 9 7950X + RTX 3090的CPU+GPU混合推理（llama.cpp）跑出了1.5 tok/s的Llama 70B速度——比NTransformer的0.5 tok/s快3倍。这说明对于有大内存（DDR5套装可达192GB）CPU系统的用户，CPU offloading方案目前仍然更实用。

NTransformer的意义不在于当前的绝对速度，而在于它打通了"没有大内存CPU也能跑70B"的路径，瓶颈清晰（PCIe带宽），未来升级路径也清晰（PCIe Gen4 x16的速度是NTransformer3090配置下的约4倍）。

3.3 起源故事：PS2 → 更好的推理

这个项目的起源故事在HN评论里收获了很多关注：作者真的从PS2上跑LLM入手。

PlayStation 2的EE（Emotion Engine）架构有一个独特设计：游戏代码可以通过特定指令路径直接在VU（向量单元）的VRAM里执行操作，而不需要经过主RAM的中转。作者被这个"直接路径"启发，思考现代GPUs是否有类似的机制可以利用——答案是：有，通过gpu-nvme-direct实现的DMA直通实际上在概念上复现了这个思路。

PS2上的实验本身并不实用——PS2的32MB总内存显然跑不了现代LLM。但它作为"概念原型"帮助作者厘清了体系结构思路，这在HN上被称赞为一种很好的工程研究方法：用极端资源约束来暴露第一性原理。

3.4 HN的实际价值讨论

0.5 tok/s适合做什么

这个速度对对话式应用（ChatBot）基本不可用。但有用户指出几个真实可用的场景：

批量离线推理：如果你有1000篇文档需要分类或摘要，0.5 tok/s在时间不紧迫的情况下可以用一夜运行完
实验和基准测试：对研究人员来说，能在单卡上跑70B级别的模型做评估，哪怕慢，也有价值
未来硬件的先行验证：一旦PCIe Gen5 x16的NVMe（理论带宽~16 GB/s）普及，同样的软件栈速度会翻倍以上

MoE模型的潜在适配性

HN上有有趣的讨论：混合专家（Mixture of Experts, MoE）模型天然适合分层存储——每个token推理只激活一小部分"专家"网络（通常16选2），意味着大量参数在推理时根本不需要读取。NTransformer的三级缓存体系如果与MoE模型结合，理论上可以在不牺牲质量的前提下大幅减少NVMe读取量。

深度分析与思考

4.1 这个项目是极客艺术，不是工程产品

NTransformer不是一个你会在生产环境里使用的工具——作者自己在README里也没有任何"用于生产"的承诺。它是一个系统性的技术探索：在一个明确的硬件约束（24GB显存）下，用尽一切软件手段，把可行性边界推到尽可能远的地方。

这类项目的价值在于知识密度，而不是即时实用性。NTransformer的每一个优化手段——SLEP双缓冲、gpu-nvme-direct、层跳过——对于任何在做LLM推理优化的工程师来说，都是值得学习的技术点。这些想法不会因为当前速度是0.5 tok/s而失去价值，当硬件升级之后，同样的软件架构会在更好的硬件上直接受益。

4.2 消费级LLM推理的未来

HN评论有一个很有意思的类比：GPU推理ASIC化，是不是会像比特币挖矿从GPU转向ASIC矿机一样？

历史上，比特币挖矿的路径是：CPU → GPU → FPGA → ASIC。每一步都是"这个任务有稳定的工作负载定义，值得为它定制硬件"的判断。Taalas（另一篇讨论的主角）就是在做这个方向的探索。

LLM推理与比特币挖矿的关键区别是：模型会更新。比特币的SHA-256算法自2009年以来几乎没有变化，但LLM每隔几个月就有新版本。专用硬件的经济账，需要在"更高性能"和"更快过时"之间取得平衡。

NTransformer走的是完全相反的路：用通用软件层打破通用硬件的边界，而不是用专用硬件替换通用硬件。这两条路都在探索中，哪条路走得更远，可能取决于LLM模型更新速度和硬件定制成本曲线哪个更快收敛。

4.3 个人观点：真正有意思的是PCIe直通思路

在NTransformer的所有技术细节中，gpu-nvme-direct是最让我感兴趣的部分，不是因为它当前跑得多快，而是因为它在某种意义上重新定义了"什么是GPU的地址空间"。

传统上，GPU只能直接访问自己的显存（HBM/GDDR）。PCIe作为CPU和GPU之间的数据通道，是一个带宽受限的"搬运工"。但gpu-nvme-direct的思路是：如果我能让NVMe控制器直接把数据放到GPU的pinned memory里，那么在软件层面上，NVMe就变成了"慢一点的显存扩展"。

这个思路与CXL（Compute Express Link）的方向有相似之处——CXL是英特尔主导的新一代互联标准，允许CPU、GPU、内存、存储通过统一的高速接口共享地址空间。如果CXL普及，gpu-nvme-direct探索的这个路径可能会变成标准特性而不是黑客手段。

那时候，在单张消费级显卡上跑100B+参数模型，可能不需要那么多补丁和警告了。

技术栈/工具清单

NTransformer 技术要素

C++17 / CUDA：核心推理引擎实现语言
SLEP Streaming：双缓冲流水线，重叠NVMe/DMA/计算
gpu-nvme-direct：用户空间NVMe驱动，直接DMA到GPU内存
VFIO（Virtual Function I/O）：Linux内核机制，将NVMe设备交给用户空间程序
DKMS（动态内核模块系统）：用于内核6.12+兼容性补丁
三级缓存：VRAM常驻 / 内存H2D / NVMe回落
层跳过（Layer Skipping）：基于余弦相似度的运行时层剪枝

参考工具

llama.cpp：CPU+GPU混合推理的主流工具，L对比基准
exllamaV2：另一个高性能消费级CUDA推理引擎
BLAS / cuBLAS：矩阵运算加速库

硬件配置

测试硬件：RTX 3090 (24GB GDDR6X) + PCIe Gen3 x8插槽
制约点：PCIe Gen3 x8带宽约6.5 GB/s；Gen4 x16可达约28 GB/s（2-4倍提速）