AirLLM:用流式卸载打破显存铁幕,70B在4GB上无损运行

GitHub今日热榜上，lyogavin/airllm单日暴涨548星，总星数冲至36,476。它抛出一个反直觉的承诺：在单张4GB显卡上，不量化、不剪枝、不蒸馏，直接跑70B大模型推理。更夸张的是，2.8T的Kimi K3能压进3.72GB，671B的DeepSeek-V3只需~12GB。这并非魔法，而是靠一套精巧的流式卸载机制。

💡 核心洞察：AirLLM的“无损”并非指压缩，而是把模型权重放在主机内存或磁盘上，按需逐层或逐专家流式加载到GPU，让显存只容纳当前计算所需的最小单元。

从README的更新日志能拼出它的核心架构。对于密集模型，解码层像流水线一样逐层流式（decoder layers stream）；对于MoE模型如Qwen3.8-Flash-Next（125B），它只流式加载当前token实际路由到的专家，巨大的n-gram表则通过文件映射（file-mapped）留在主机内存。训练时同样适用：Qwen3.8-Flash-Next在RTX 3060 Ti（6GB）上训练，Qwen3.8-27B在~2GB就能跑。

具体数字佐证了这种机制的压榨能力：

• Kimi K3 (2.8T)
  ：RTX 6000 Ada上端到端仅占3.72GB VRAM
• Qwen3.8-Flash-Next (125B)
  ：RTX 4090上仅占5.95GB VRAM
• Qwen3.8-27B
  ：RTX 3090上仅占3.33GB VRAM

💡 核心洞察：流式卸载的本质是用主机带宽换显存容量，把模型权重的存储层级从GPU显存下沉到系统内存甚至磁盘，代价是引入额外的PCIe传输开销。

HackerNews评论区的一条热评直接戳破了泡沫：“Kimi K3 on RTX 6000 Ada (48GB) takes 292 s/token”。生成一个token需要近5分钟，这意味着它完全不适合实时对话或交互场景。此外，主机侧需要大容量存储：Qwen3.8-Flash-Next要求约360GB磁盘空间，且需通过pip install git+https://github.com/huggingface/transformers.git安装特定transformers版本。

💡 核心洞察：AirLLM的适用场景被严格限定在离线批处理、研究实验、模型权重分析等对延迟不敏感的任务，而非生产级聊天服务。

社区对AirLLM也存在质疑。HN开发者@cpfohl指出它本质上似乎是“按需加载层”，仍需将完整模型下载到磁盘，只是RAM需求大幅下降。这确实是事实，但它的工程价值在于将这一机制做到极致，甚至支持MoE的逐专家加载和训练时的适配器常驻。

💡 核心洞察：AirLLM不是银弹，而是显存极度受限下的生存指南。它把“能不能跑”变成了“能不能忍”，适合有大硬盘、不赶时间的极客。

AirLLM的爆火说明了一个事实：大模型军备竞赛之外，还有一群开发者在思考如何让普通硬件也能触碰最前沿的模型。它用近乎行为艺术的方式，把“流式”从流媒体服务器搬到了GPU显存里。或许正如一位 HackerNews 读者所言：“看到一个项目能用这么野的路子让 2.8T 模型跑在 3.7GB 上，本身就是一种工程美学。”

你的显卡是多少GB？你会为了尝鲜忍受 292 秒每 token 的延迟吗？欢迎在评论区分享你的硬核体验。