「显存差一半就跑不动」——这句抱怨大概是 2026 年本地跑大模型最普遍的日常。24G 卡量化后勉强塞下一个 70B，16G 卡加载都开始报警，8G 卡除了 7B 之外几乎没得挑。于是问题来了：显存不够，除了「上个量化」还有别的活法吗？
有，而且不止一种。把这些年社区真跑通的路径摊开看，能清楚地分成五条性质完全不同的路线：分层流式、GGUF 量化、CPU offload 混合、蒸馏小模型、远程 API。这五条路没有谁最强，只有它们各自解决的根本不是同一个问题。所以这篇横评不排座次，它要做的是把你缺的东西和该走的路线对上号。
先说清楚：比什么，不比什么
三条边界先立好。
第一，这篇比的是内存策略路线，不是部署工具。 Ollama、LM Studio、vLLM、llama.cpp、GPT4All 这五款工具的横向评测本站已写过一篇：本地部署工具横评。那篇解决的是「用哪个工具」，比的是界面形态、上手难度、并发能力、同一台机器上的实测吞吐。这篇解决的是「卡不够时该走哪条路」，比的是策略。两篇是分工不是重复：工具是路线的执行者，量化那条路可以由 Ollama、LM Studio 或裸 llama.cpp 执行，分层流式那条路甚至不用你熟悉的工具栈。
第二，速度不做跨路线跑分。 五条路线跑在不同硬件、不同模型、不同精度组合下，tokens/s 没有同口径可比性，这里只做定性描述：哪条路线在结构上必然慢、哪条必然快。想看同工具、同硬件、同模型的实测数字，去看上面那篇部署工具横评。
第三，显存数字逐个标来源。 凡是出现具体 GB 数字的地方都写清出处和硬件前提。其中 airllm 的所有数字都是 README 口径（官方仓库 README 实测表格的自报数据），本文没有在同硬件上复现，也不把它当作跨路线比较的分母——那是官方宣传位数字，横着比不公平。
灵魂观点可以摆上桌：真正的选择不是「哪种方法最强」，而是「你缺的是显存、是内存、还是速度」。
五轴对比表
<table> <thead> <tr><th>轴</th><th>分层流式</th><th>GGUF 量化</th><th>CPU offload 混合</th><th>蒸馏 / 小模型</th><th>远程 API</th></tr> </thead> <tbody> <tr><td>显存占用</td><td>最低：可压到个位数 GB，README 口径称 4GB 以下可跑 2.8T 的 Kimi K3</td><td>中低：随量化位宽近似线性下降，Q4 档是当前生态甜点</td><td>低：卡上只留放得下的层，其余常驻内存</td><td>低：直接换用小参数量模型</td><td>本机为零：计算在服务商侧</td></tr> <tr><td>速度</td><td>结构上最慢：逐层从磁盘或内存搬运，慢是设计使然而非故障</td><td>可观：全模型常驻显存或内存映射，属于「能正常用」的速度</td><td>强依赖 PCIe 与内存带宽，卡越小跨总线次数越多</td><td>最快：模型本身就小，延迟最低</td><td>由网络往返与服务商负载决定，本机不可控</td></tr> <tr><td>质量损失</td><td>无：README 口径明确不量化、不蒸馏、不剪枝</td><td>有损：低位宽档位损失可感知，需按任务敏感度选档</td><td>权重不改动，理论无损，实际表现取决于实现成熟度</td><td>最大：换模型等于换能力上限</td><td>取决于选型：可直达旗舰，本机不承担这份损失</td></tr> <tr><td>部署复杂度</td><td>最高：版本矩阵三重锁，磁盘与主机内存都是 TB 级门槛</td><td>最低到中等：生态最成熟，一条命令到图形界面都能拉</td><td>中等：要理解层分配规则与总线瓶颈</td><td>最低：多数时候就是换一个模型名</td><td>最低：注册、取 key、按量计费</td></tr> <tr><td>适用人群</td><td>偶发跑一次超大模型，或想在本地摸一摸 2.8T 的人</td><td>绝大多数日常本地部署用户，默认选项</td><td>显卡很小但内存充裕、愿意接受延迟的人</td><td>追求工程省心、能接受能力降档的人</td><td>数据不涉敏、只关心效果与总成本的人</td></tr> </tbody> </table>表格之外补一句方法论：横着看是五条路线，竖着看是五个代价。任何一条都在某个维度上明确付费——分层流式付速度，量化付质量，offload 付延迟，蒸馏付上限，API 付数据边界与账单。没有一列「全赢」，这就是排不出座次的原因。
仓库地址链接与明文各一遍：github.com/lyogavin/airllm（明文 github.com/lyogavin/airllm）、github.com/ggerganov/llama.cpp（明文 github.com/ggerganov/llama.cpp）、github.com/ollama/ollama（明文 github.com/ollama/ollama）。
路线一：分层流式：用速度换显存的天花板
这是 airllm 的路线，也是五条里最反直觉的一条。README 原文口径写得很清楚：不量化、不蒸馏、不剪枝，靠逐层流式加载（layer-wise streaming）把 70B 塞进单张 4GB 卡里。
原理不难懂：模型推理是一层层往下算的，某一层算完就不再需要常驻显存。airllm 按顺序把每一层从磁盘或内存搬进显存，算完就换下一层，显存占用因此只与「单层大小 + 常驻部分」有关，与总参数几乎无关。这也是它敢把 2.8T 的 Kimi K3 塞进 4GB 以内的原因。
README 口径的实测数字（全部为官方自报，附硬件前提，本文未复现）：
- 70B 在单张 4GB 卡可跑，这是它的宣传头牌数字。
- Qwen3.8-27B（稠密 VL，Gated DeltaNet + Gated Attention，原生视觉）3.33GB 显存，RTX 3090 端到端实测。
- Qwen3.8-Flash-Next（125B，含约 51B 的 n-gram 嵌入）5.95GB 显存，RTX 4090 端到端实测。
- Kimi K3（2.8T 总参数、激活 1040 亿，896 专家每 token 激活 16 个）3.72GB 显存，RTX 6000 Ada 端到端实测，按 token 路由逐专家流式。
- DeepSeek-V3（671B）约 12GB。
Kimi K3 这个数字值得停一下：2.8T 参数跑在 3.72GB 显存里，听着像绕过了物理定律，其实没有——代价被转移到了磁盘与时间上。2.8T 模型的完整权重是 TB 级磁盘占用，官方博客与上证报口径都提到单节点跑它是巨大的磁盘代价；它的开源许可也是修改版 MIT 许可（非标准 MIT，2026-07-27 开放完整权重），商用前请读 LICENSE。
三条必须一起写的事实边界：
第一，慢是结构性的，不是坏了。逐层从磁盘或内存搬运，每个 token 生成都要反复走这套流程，官方没给 tokens/s 数字，本文也不给。凡是期待它跟常驻显存方案同速的期待，都需要修正。
第二，版本矩阵是三重锁。CUDA 12 的 torch 构建（flash-attn 没有 CUDA 13 预编译轮子）、flash-attn、对应模型的 transformers 分支，三者错一个就跑不起来，而且不同模型要求还不一样：Qwen3.8-27B 要 transformers 5.8+，Qwen3.8-Flash-Next 需要 transformers 的 in-tree qwen4_exp，Kimi K3 要 transformers 4.56.x 并额外装 compressed-tensors。
第三，生态坑不少。GitHub API 2026-10-12 实证：36,747 星、3,829 fork、Apache-2.0、160 个 open issues。星数说明关注度，open issues 说明关注度里有多少是来问问题的。
谁该走这条路：想偶发跑一次卡上根本放不下的模型、在本地摸一摸 2.8T 是什么体验、不介意等很久的人。若日常是逐 token 对话，这条路会让你难受。
路线二：GGUF 量化：生态最成熟的那条默认路
把权重压小，是最不需要发明的思路。GGUF 是 llama.cpp 生态推动的量化格式，从 Q8 到 Q6、Q5、Q4 一直到更低档位，Ollama、LM Studio、llama.cpp 乃至一批第三方前端都吃这套格式，入门成本低到几乎不需要学习曲线。踩坑与档位选择，本站 Ollama 本地部署 SOP 已铺得很细，这里不重复。
这条路线的价值在于它是唯一一条「日常可用」和「生态成熟」同时成立的路线：不需要理解层加载、不需要调总线参数、不需要担心版本三重锁。代价同样明确——量化有损，低比特档位在长链推理、精确计算、代码生成上的损失是可感知的。省下来的空间不是白捡的，压权重换显存，省下的是用输出质量付的账。站内那篇部署工具横评的避坑第一条就说这件事：7B Q4 留 8G 余量最舒服，非要把 70B 塞进 16G，量化到极致也卡成 PPT。
谁该走这条路：绝大多数日常本地部署用户。诉求是「装上就用、质量可接受」，量化就是答案。
路线三：CPU offload 混合：卡小但内存多的解法
这条路既不压权重也不慢速搬运，而是分摊：能放进显存的层留显存，放不下的层扔内存，运行时在两边来回搬。
它的表现高度依赖 PCIe 通道带宽和系统内存带宽：卡小意味着跨总线搬运的层更多，速度损失跟着上去；内存容量则必须真的够——这是最容易被忽略的前提，很多人是插上去才发现内存不够，被迫在 OOM 与换页间折腾。
它的独特价值在于保住了权重的原精度，理论上无损，跟量化是本质区别。所以当任务对精度敏感、量化档位已不能再降时，offload 是一条常被忽略的中间选项。缺点也明显：你得自己算层分配，并接受由此带来的延迟。
谁该走这条路：显卡规格已定死买不了、内存充裕、任务对精度敏感、且能接受延迟的人。
路线四：蒸馏与小模型：最省心，也最诚实的一种放弃
这条路干脆不谈显存——直接换一个参数量小得多的模型，或者用一个蒸馏版本。它是工程上最省心的一条：换个模型名就完事，延迟最低，笔记本上跑得动。
代价最大，也最不可协商：换模型等于换能力上限。它不是「同模型更省电」，而是「另一个模型在回答」。复杂推理、长链任务、专业问答上，小模型和旗舰模型的差距不会因为部署省心而消失。
这条路线也最容易被误读成「参数小就弱」或「参数大就一定好」两个极端。实际上小模型在窄任务上（固定格式抽取、分类、简单改写）常常更稳定，成本也低一个数量级。问题只在于你要不要那个能力上限。
想看怎么挑小模型，本站 本地编程模型横评 按任务类型拆过一轮；轻量模型落地过程见 Mellum 2.1 本地部署 SOP。
谁该走这条路：把工程省心排在能力上限前面、任务窄而稳定、能接受明确降档的人。
路线五：远程 API：把显存问题从桌上拿走
这条路思路最简单：让算力发生在别人的机器上。显存问题在这条路上根本不存在——不是被解决了，是不存在了。本地显卡多小都不影响调用效果，因为模型根本没有加载进你的显存。
代价转移到两个地方。数据边界：请求要出本机，走公网到服务商，前面四条路线里「数据不出域」这个本地部署的核心动机被直接抵消。成本结构：从一次性硬件投入变成按量计费，用得少反而便宜，用得猛账单会失控，价格与下线也不由你决定。托管服务的分层选型，本站 Qwen3.8-Flash-Next 三层部署 SOP 里的托管 API 一层有展开。
还有一条容易被忽略的理由：当你要的是旗舰能力时，本地路线根本不在候选集里。一张 8G 卡无论怎么折腾都拿不到旗舰模型的水平，此时把问题从「怎么塞进显存」改成「找谁付显存的钱」，才算解决。
谁该这条路：数据不涉敏、不需要离线、只关心效果与总成本的人。
各归其位：五行决策速查
把五轴表翻译成五行决策。选之前提醒一句：所有路线都只负责把模型跑起来，值不值得信、能力够不够用，仍要自己判断。
- 缺显存、缺到离谱（连 70B 都放不下），且能等：分层流式。仓库 github.com/lyogavin/airllm，Apache-2.0，36,747 星（GitHub API 2026-10-12 实证）；怎么搭、坑在哪见 airllm 4GB 推理资源篇。
- 缺显存但只是差一点，日常要能对话：GGUF 量化。这是默认答案，生态最成熟，档位按任务敏感度选。
- 显存小但内存充裕，任务对精度敏感：CPU offload。保住权重原精度，代价是延迟与调参。
- 显存根本不够且不想折腾，追求省心：蒸馏 / 小模型。放弃能力上限换速度与稳定。
- 要的是旗舰能力，或者数据不涉敏：远程 API。显存问题不存在，成本与数据边界转移到服务商。
常见问题
Q1: 五条路线里到底哪条最强？ 没有「最强」这个概念，因为它们优化的不是同一个目标。分层流式把显存压到最低，代价是速度；量化把显存和速度一起解决，代价是质量；offload 保住质量，代价是延迟；小模型把速度拉满，代价是能力上限；API 把显存问题消灭，代价是数据边界和账单。该问的是「缺的是显存、内存，还是速度」。
Q2: airllm 真的能在 4GB 卡上跑 70B 吗？ 按官方 README 口径是可以的，它靠逐层流式加载实现，不量化、不蒸馏、不剪枝。但读懂这个数字有两个前提：官方给的是显存占用数字，不是速度数字；本文引用的 airllm 显存数据全是 README 自报口径（Qwen3.8-27B 的 3.33GB 标 RTX 3090，Qwen3.8-Flash-Next 的 5.95GB 标 RTX 4090，Kimi K3 的 3.72GB 标 RTX 6000 Ada），我们没有同硬件复现，也不做跨路线比较。速度上官方没给 tokens/s，本文不编。
Q3: 量化会掉多少质量？ 分档位和任务。低比特档位在长链推理、精确计算、代码生成上的损失可感知，短问答、抽取、分类这类窄任务影响小得多。所以没有统一答案，只有「这个任务对精度有多敏感」的判断。要重申的是：量化省下来的空间是用输出质量付账的。档位怎么选见 Ollama 本地部署 SOP。
Q4: CPU offload 和量化该选哪个？ 看你缺什么。量化压的是显存和磁盘，速度通常更好，是日常首选；offload 只压显存但保留权重原精度，代价是速度高度依赖 PCIe 与内存带宽。任务对精度敏感、量化档位已不能再降时，offload 才是更对的选择。
Q5: 远程 API 是不是「作弊」？ 不是作弊，是把问题换了个位置。显存问题在这条路上确实不存在，但那是因为计算根本没发生在你机器上，代价转移到了数据出本机和按量计费上。如果核心诉求之一是数据不出域，这条路从一开始就不该进候选集。
收尾
五条路线看下来，结论还是那句朴素话：不是选最强的方法，是先认清自己缺的是什么。缺显存到离谱、能等，换分层流式；差一点、要日常能用，换量化；卡小内存足，换 offload；懒得折腾，换小模型；要旗舰效果且数据不涉敏，换 API。
你的卡是多大？卡在哪条路线上？评论区聊聊。