4GB显卡跑2.8T模型：AirLLM如何把大模型塞进你的桌面

当业界还在为7B模型需要多大显存争论时，AirLLM已经让2.8T参数的Kimi K3在单张RTX 6000 Ada上以3.72GB显存运行。这不是魔法，也不是量化蒸馏，而是将推理的显存需求从“整模型常驻”改写为“逐层流式加载”。过去30天，这个项目狂揽8172颗Star，今天依然以每日800+的速度增长——因为它正在重新定义大模型推理的硬件门槛，让拥有低端显卡的个人开发者第一次摸到了前沿模型的边界。

这个项目在做什么

大模型推理的显存难题，本质是“模型权重必须全部驻留显存”的惯性思维。70B模型仅权重就需要约140GB，远超单张消费级显卡的容量。传统方案要么多卡并行，要么用量化把精度砍掉，要么把部分层卸载到CPU——但这些都有明显代价。

AirLLM提出了一个更激进的思路：按层加载，逐层计算。它把模型按层切分，每一层单独从磁盘读入GPU，前向传播完毕立刻释放，再加载下一层。这样峰值显存只依赖单层大小，而非整个模型。更妙的是，对于MoE架构的模型（如Mixtral、DeepSeek-V3、Kimi K3），它进一步将粒度细到“专家”——每个token只路由到少数专家，AirLLM就只流式加载这些专家，一层都不用加载完整。

用这个逻辑，70B模型在4GB GPU上跑成了现实；2.8T参数的Kimi K3——目前开源最大的模型——只需3.72GB显存。这不是特调，而是通用机制。

为何此刻被关注

本期项目新增819颗Star，看似平平，但拉长到30天，这是一个爆发窗口：6月30日单日峰值3621颗，整个区间增长8172颗。转折点正是2026年7月Kimi K3支持的上线。2.8T参数是什么概念？是此前最大开源模型DeepSeek-V3的4倍多。在此之前，这类模型被视为“国家级算力”的专属，而AirLLM让它运行在单张消费级GPU上，甚至是在4GB显存的边缘卡上。

这是“不可能”的瓦解。社交媒体上，开发者晒出自己运行Kimi K3的截图——没有A100集群，只有一块中古显卡。这种认知冲击直接引爆了传播。此外，v3.0版本带来的FP8支持也让DeepSeek-V3（671B）被压缩到约12GB显存，Qwen3-235B只需约3GB，正好卡在主流显卡的甜点区。

技术上有何不同

AirLLM最核心的设计是层流（layer streaming）和专家流（expert streaming）。与常见的offload（如DeepSpeed ZeRO-Offload）相比，它的粒度更细，卸载策略更激进；与量化（如GPTQ、GGUF）相比，它不损失精度，并且可以堆叠在量化之上——项目提供的块状量化压缩还能再提速3倍。

一个容易被忽略的细节是：它依然依赖transformers的AutoModel接口，使用者几乎无缝切换。在初始化时传入compression='4bit'就能启动压缩。这种“降低门槛”的工程化意识，是它获得广泛采用的关键。

但代价也很明显：推理速度远不如全量驻留。因为要频繁读取磁盘并做小步计算，吞吐量受限。不过对于单用户、离线、长上下文场景（比如分析一篇论文、写代码），这个速度可接受。它和vLLM、TensorRT-LLM不是替代关系——后者追求吞吐，前者追求可达性。

谁应该用它

个人开发者：手里只有一块GTX 1650（4GB）或RTX 3060，却想尝试最新开源的Qwen3、Llama 4或Kimi K3。AirLLM是唯一能让你触达这些模型的选择。
高校研究者：没有预算申请集群，但需要验证某个模型在某些任务上的效果。可以用AirLLM在实验室机器上跑通基线，再上云做大实验。
创业团队做PoC：需要快速验证产品里“大模型推断”的可行性，而不想在初期就投入云GPU费用。

注意，它不适合高并发生产环境，也不适合需要低延迟（如实时对话）的场景。

局限与开放问题

AirLLM的代价是速度。在K3的3.72GB显存背后，是磁盘I/O和PCIe带宽构成了瓶颈，实测token生成速度远低于原生驻留方案。另外，模型按层拆分需要大量磁盘空间（405B模型需要约400GB），且每次加载都需要反复读取，对SSD寿命也不友好。更实际的问题是，它目前不支持动态批处理，多用户并发会直接崩溃。这些限制决定了它更多是“能跑”，而不是“跑得好”。但作为一项打破常规认知的技术，AirLLM的价值恰恰在于：它证明了显存不是推理的天花板，带宽才是。