4GB 显存跑 70B 模型：极客的浪漫，和工程师的现实

你手头有张 4GB 的老显卡，网上有人说这卡能跑 70B。第一反应是标题党吧？我也这么想。然后翻了 AirLLM 的实测数据，越看越坐不住：405B 的 Llama 3.1，8GB；671B 的 DeepSeek-V3，12GB；最新的 Kimi K3——2.8 万亿参数，开源模型里最大的那个——在 RTX 6000 Ada 上只占 3.72GB 显存。

同一周 Cloudflare 也发了篇博客，讲他们怎么在全球边缘节点上跑 Kimi K2.6 和 GLM 5.2。做法是量化 KV cache 加压缩权重，结果单卡能扛的并发请求翻倍，每 token 成本降了约 30%。

一边在榨干最烂的卡，一边在榨干最贵的卡。说的其实是同一件事：把模型用起来，比把模型堆大更值钱。

先搞清楚 AirLLM 是怎么"骗"过显存的

它没做量化、没做蒸馏、没做剪枝。原理一句话：分层加载，按需计算。

传统推理把整个模型塞进显存。70B 光权重就要 140GB，4GB 卡直接原地去世。AirLLM 换了个思路：把模型切成一层一层，算到哪层就从内存加载哪层，算完就丢。

对 MoE 模型这招更狠。Kimi K3 有 2.8 万亿参数，但每次推理只激活一小撮 expert，AirLLM 就只流式加载用到的那些，所以能压到 3.72GB。

打个比方：你不是把整个图书馆搬进自习室，而是每次只借当下要读的那一页。书在书架上，随取随还。

代价呢？速度。每生成一个 token 都要反复做磁盘/内存 IO，吞吐量比满血部署低一个数量级不止。AirLLM 自己也没藏着，文档里写得明白：这方案适合离线、低并发、不赶时间的场景。

Cloudflare 走的是另一条路：让模型在边缘"住下来"

AirLLM 是省内存，Cloudflare 是省算力、拼并发。

Kimi K2.6 这种长上下文 MoE 模型，最吃显存的不是权重，是 KV cache。模型每生成一个 token，都得把前面所有 token 的注意力键值存下来。上下文越长 cache 越大，最后是 cache 把 GPU 撑爆，模型反倒进不来。

Cloudflare 的招数是把 cache 从 BF16 压到 FP8。有意思的是，单并发下速度还慢了 9%（137 → 125 tok/s）——光看这个数你会觉得亏了。但 BF16 在 32 并发就 OOM，FP8 一路扛到 64 并发，峰值 2,192 tok/s，比 BF16 的峰值高 41%，每 token 成本省约 30%。

而且质量没掉：GSM8K 94.24 → 94.09，MMLU 89.11 → 89.04，误差在噪声范围内。

两条路的共同点：都在跟"成本"较劲

AirLLM 服务的是个人开发者：本地调个大模型，不想每次都去租 A100，手头那张老卡能把 demo 跑通就行。Cloudflare 那头是另一个世界——边缘节点上成千上万的请求，省 30% 成本就是账单上少一位数。

两边看着背道而驰，其实较的是同一个劲：算力永远不够，所以推理效率才是护城河。 2026 年的开源生态早就不缺模型了，缺的是把模型跑起来的便宜方案。谁能在同样的卡上服务更多请求、在更差的卡上跑更大的模型，谁就赢了。

泼盆冷水：别被演示视频带偏

"4GB 跑 70B"这句话很热血，但你真拿它上生产，会被速度教做人。它拿延迟和吞吐换显存，只适合实验和离线任务。

Cloudflare 那套也搬不走。FP8 KV cache 量化、prefill/decode 分离、SGLang 优化，全是分布式生产环境的工程活，个人项目根本用不上。

我更在意的是第三层：这两篇都是工程技巧，不是算法突破。工程技巧的进步是一格一格挪的，不会突然跳。所以别指望明天你的手机能跑 70B。

你今天可以做的事

1. 手头有老显卡？花 20 分钟跑一下 AirLLM 的 demo（pip install airllm 就能跑），拿真实速度判断它值不值得进你的工作流，别看 README
2. 在做边缘/Serverless 推理？认真读 Cloudflare 那篇，重点看 KV cache 量化和 prefill/decode 分离，这两招对吞吐的提升是实打实的
3. 都不相关？至少记住风向变了：模型推理正在从"堆卡"转向"抠效率"。下次选型，把推理成本当一等公民来比，别等账单来了才算

参考来源：

• AirLLM: 70B inference with single 4GB GPU
• Cloudflare: Smaller, faster, safer — running Kimi and GLM at scale

✨ 本文由 DeepSeek 生成初稿，Claude 审核润色。