GitHub上的开源项目AirLLM最近又更新了一轮宣称：一张4GB显存的消费级显卡，也能跑动70B参数的大语言模型，不靠量化、不靠蒸馏、不靠剪枝。项目页面顺着往下报数字，8GB显存能跑405B的Llama 3.1，约12GB能跑671B的DeepSeek-V3，2026年7月的更新里更进一步，说不到4GB就能跑动号称"全球最大开源模型"的2.8万亿参数Kimi K3。数字确实抓眼球，但翻开这个项目的GitHub issue会发现，官方自己也答不出一个更基础的问题——这套方案跑起来到底多快。
逐层加载省的是显存，不是搬运量
70B模型的FP16权重体积约140GB，远超消费级显卡的显存上限。AirLLM的思路是逐层加载：每次只把当前要计算的那一层transformer权重从磁盘或内存搬进显存，算完立刻释放，再搬下一层。这不是新算法，量化（GGUF/llama.cpp）、CPU-GPU混合卸载（DeepSpeed ZeRO-Inference）、批处理优化（FlexGen）这些路线早就存在，AirLLM的卖点更多在于把整套流程封装成一行AutoModel调用，用起来足够简单。
官方给不出的那个数字
README里能找到的性能信息只有两条：预取加载提速约10%，4/8bit压缩最高带来3倍加速。没有任何一条关于70B模型推理速度的基准数据。一个公开的GitHub issue（#295）直接质疑这一点：官方连固定的模型版本、完整硬件规格、实测延迟、峰值显存、磁盘占用这些最基础的信息都没给出，更别说可复现的测试脚本。
按工程测算，4bit压缩后的70B模型体积约35GB，走PCIe约20GB/s的带宽算下来，理论速度上限也就每秒0.57个token；如果用的是未压缩的FP16权重，理论速度可能连每秒0.15个token都到不了。
显存数字好看，token吐出来的速度才是能不能用的真相
跟llama.cpp比，差距在哪
这组理论下限不是空穴来风。工程测算显示，在4GB GPU加上够用系统内存的场景下，llama.cpp跑量化70B模型的实际生成速度大约在0.5到2.5 tokens/s区间；而AirLLM的估算区间大约在0.05到0.3 tokens/s，慢了一个数量级。这些都是工程估算而非受控实测，但方向一致：社区反复吐槽的点也在这里——AirLLM解决的是"显存装不下模型"，没解决"权重要来回搬"，瓶颈只是从显存挪到了磁盘和PCIe带宽上，逐token的自回归生成还得反复访问全部权重，延迟只会更糟。
4GB之外还要付的账
4GB显存只是宣传里最好看的那个数字。要真正跑起来，还得预留约300GB级别的磁盘空间做权重拆分转换，加上够用的系统内存和一块跑得动的NVMe硬盘——这些成本都不在"4GB"这三个字里。
- 风险.README本身也有可疑之处，2026年7月的更新时间戳和页面里嵌着几条与推理框架毫无关系的广告链接（游戏素材生成器、表情编辑器），这份说明文档的可信度也该打个问号。
对完全没有大显存GPU、只做离线批处理或研究验证的人，AirLLM"能跑起来"仍有兜底价值。但想要交互式对话或多用户服务，目前看不到任何能撑起这个场景的速度证据。接下来该盯的，是有没有第三方给出可复现的tokens/s实测，issue #295提的基准测试提案会不会真的落地。
- 结论.判断一个本地部署方案能不能用，先看tokens/s，再看显存那个数字。