本地部署提速总纲：从换引擎到改权重，四层手段一次讲清

摘要：本文系统梳理本地大模型部署提速的完整方法论，将各种提速手段按「动手的深度」划分为四层：换引擎（工具层）、改摆法（调度层）、换模型（架构层）、改权重（磨刀）。文章先讲清本地推理慢的本质——显存带宽墙，再逐层拆解每层的核心手段与适用场景，包括显存卸载、KV cache 优化、MoE 稀疏激活、量化、剪枝等，最后给出四层叠加的顺序建议与常见误区，帮助读者快速定位适合自己的提速方案。

本地部署提速总纲：从换引擎到改权重，四层手段一次讲清

我每天都在折腾本地部署，测试各种"速度"和"质量"怎么平衡。前边我在《一文讲透 15 个大模型部署工具》里，把 15 个主流推理工具挨个过了一遍。但真上手测下来才发现：推理工具只是最底层——在它之上，还叠着一大片优化空间。

所以这篇文章试图从多个维度说清楚：本地部署到底分哪几个层级，每一层又分别该怎么提速。下面讲的是通用原理和框架，数据都来自公开资料；我自己的逐层实测会另开文章——后续我会针对每个层级，挑有代表性的方案做深度测试。

判据只有一条：你动的是程序、是摆法、是文件，还是文件里的数。 网上的提速说法各自都对，混在一起却容易得出离谱结论——比如以为剪枝能提速。这篇只做一件事：把这些手段按"动手的深度"分成四层。

零、先讲清一件事：本地推理到底慢在哪

这一节是所有提速手段的总钥匙。跳过它，后面每一条都只能死记。

大模型是一个字一个字往外蹦的。生成第 N 个字之前，模型要把自己从头到尾跑一遍。而"跑一遍"这件事，本质上不是在算，是在读——把几十亿个参数从显存里读出来，乘一遍，写回去，再读下一个字。

问题就出在这儿。以 H100 为例：它的算力高达 990 TFLOPS，但显存带宽只有 3.35 TB/s。一个字一个字生成时，GPU 绝大部分时间在等数据搬过来，算力是闲着的。

所以有个非常粗糙但极好用的近似：

生成速度 ≈ 显存带宽 ÷ 模型体积

模型小一半，速度就快差不多一倍。这解释了本地部署里绝大部分现象，也解释了为什么下面所有手段，归根到底只有三条路：

记住这三条路，再看网上那些"提速 N 倍"的说法，你就能立刻判断它在哪条路上、对你有没有用。

一、四层手段，先给结论

两条最容易搞混的，先说死：

第三层和第四层的分界，是"文件换没换"。 换一个 MoE 版本、换一个原生小模型，那是换模型，第三层。把手里这个做量化、做剪枝，文件还是那个文件，那是第四层。

FreeToken 和 AirLLM 看着像新引擎，其实不算。 它们的核心手艺全是调度——带宽自适应混合调度、双缓冲预取、专家缓存运行时热改。所以它们归第二层，不是第一层的新引擎。同理 KTransformers 也是。

术语大白话（写给你也写给我自己）

二、第一层：换引擎（工具层）

模型一个字节没动，只是换了个程序来跑它。零风险，但收益完全取决于你的场景。

这一层就是《一文讲透 15 个大模型部署工具》讲的内容——那篇把 15 个主流引擎挨个拆解过，本文只取它和上面三层的相对位置，不重复展开了。

2.1 五个主流引擎，各自解决什么

几个补充：

• MLX 是 Apple Silicon 的亲儿子，M 系列 Mac 上比通用引擎更贴硬件。
• TensorRT-LLM 是 NVIDIA 官方的性能天花板，代价是只认 N 卡、配置复杂。
• ExLlamaV3 是 N 卡单机玩家的速度怪，用自家的 EXL2/EXL3 格式。

2.2 一个反直觉的结论

同一张卡、同一个模型，装得下和装不下，最优引擎不是同一个：

装不下就用聪明的，装得下就用笨的。

道理不复杂。装得下的时候权重全在显存里，调度越简单越快，聪明调度那点额外开销是白付的。装不下的时候必须往内存卸，怎么卸、什么时候搬就成了胜负手。

⚠️ 这组数字是第三方实测（RTX 5090 32G + Ultra 9 285K + 64G DDR5，模型 Qwen3.6-35B），不是我跑的。

2.3 装不下时怎么办

这是消费级显卡最常撞的墙。路子有三条，都属第二层，但通常靠专门的引擎实现：

• KTransformers：异构计算，CPU + GPU 分工，主打在消费级显卡上跑超大模型。
• AirLLM：极端形态，逐层流式加载，有人拿它在 4G 显存上跑过 2.8T 参数。代价是慢，拿时间换空间。
• FreeToken：带宽自适应混合调度 + 双缓冲预取 + 专家缓存热改，2026 年 8 月开源。

一句话：它们不是"更快的引擎"，是"装不下时才需要的引擎"。

三、第二层：改摆法（调度层）

这层最值钱，因为它一分钱不花、不伤模型，还最容易被忽略。

它有两半：一半是往哪放，一半是怎么排。

3.1 往哪放：显存、内存、硬盘

权重可以待在三个地方，速度差着数量级：

关键知识点来了——"往内存卸"有两种卸法，差别巨大：

-ngl（整层卸载）：把前 N 层整个搬到显卡，剩下的整个留 CPU。问题是 Transformer 的一层里塞了两样东西——注意力（小、带宽敏感、每个字都要用）和前馈网络（大、MoE 模型里大部分时间闲着）。整层卸载会把注意力一起搬走，而注意力恰恰是你最搬不起的那部分。

–n-cpu-moe（只卸专家）：只把 MoE 的前馈专家张量搬到 CPU，把注意力、路由、嵌入层、共享专家全留在显卡。

同样的模型、同样的卡、搬走同样多的字节，只卸专家能快得多。 很多人试了一次 -ngl 觉得"卸载太慢"就去买显卡，其实是参数用错了。

两个实操提醒：

3.2 KV cache：显存里那本被忽略的账

很多人算显存只算权重，结果一开长对话就爆。因为还有 KV cache。

它是干什么的：模型每生成一个字，都要回头看前面所有字。如果每次都重算，复杂度是平方级的，长对话直接卡死。所以干脆把算好的 K、V 存下来，用显存换时间。

代价是它随对话长度线性膨胀。 公式：

每 token 的 KV 占用 = 2 × 层数 × KV头数 × 头维度 × 每元素字节数

拿 Llama-3 70B 举例（80 层、8 个 KV 头、头维度 128、FP16 两字节）：

2 × 80 × 8 × 128 × 2 = 327,680 字节 ≈ 320 KB / token

• 4K 上下文 → 约 1.3 GB
• 32K 上下文 → 约 10.5 GB
• 128K 上下文 → 约 40 GB

而且这是"每条对话"。 8 条 32K 的对话同时挂着，光 KV cache 就奔着 32 GB 去了。

这就是为什么"模型能跑 128K 上下文"和"能同时跑很多条 128K"完全是两件事。

3.3 怎么排：一次多算几个

这一半一个字节都不改，只改干活的次序。

（1）连续批处理（Continuous Batching）
老式批处理是凑齐一批一起跑，跑完才能进下一批——快的人要等慢的人。连续批处理改成每轮迭代都能进人出人，GPU 几乎不空转。vLLM 靠它在并发负载下把显卡利用率顶到 85-92%。

这是多人共用场景收益最大的一项，也是 Ollama 的短板。

（2）PagedAttention：解决"装得紧不紧"
老办法给每条对话预留一整块连续显存，按最大长度预留。结果短对话浪费一大半，长对话进来又找不到连续空间。

vLLM 借鉴操作系统分页：把 KV cache 切成固定大小的块（通常 16 token 一块），按需分配，用块表把逻辑位置映射到物理块。显存利用率从大约 40% 提到 95%，吞吐提升 2-4 倍。

⚠️ 别搞错它的边界：PagedAttention 不会压缩每个 token 的 KV 数据，它优化的是分配、回收、共享和寻址。想让每个 token 变小，得靠量化、GQA 或 MLA。

（3）前缀复用（Prefix Caching）：解决"哪些能不重算"
大量应用的每条请求都带着同一段长系统提示词、同一份 RAG 文档。没优化时，这段前缀会被反复算一百遍。前缀复用把算好的 KV 块留下，新请求命中就直接用。

• vLLM 叫 Automatic Prefix Caching
• SGLang 用 RadixAttention（基数树），能匹配"最长共用前缀"而不只是完全相同的前缀，官方报告在 prefix-heavy 负载下吞吐最高 6.4 倍
• llama.cpp 也有，日志里那个 f_keep 说的就是保留了百分之多少的前缀

⚠️ 边界同样明确：必须 token 序列完全一致（语义相近不算命中）；它省的是 prefill（降 TTFT），对之后每个字的生成速度没有帮助；不要把动态时间戳、随机 ID 放在提示词开头，那会让后面整段都失去命中。

（4）投机解码（Speculative Decoding）
这一条最聪明，也是个人单机最容易被忽略的。

思路：让一个小模型先打 K 个字的草稿，大模型一次前向传播把 K 个字全验完，对了的留下，错的从错的那个位置重来。

关键在于：验证是并行的，生成是串行的。 验 K 个字和生成 1 个字的开销差不多。

而且它有个严格的数学保证：输出分布跟大模型自己一个字一个字生成完全一致，不是近似，是等价。 所以它没有质量损失。

真实加速全看接受率：

（Llama-3 70B 单卡 H100，SSD 论文实测；吞吐 125 → 250 t/s，显存多花约 4.7%）

代码最快，因为语法和样板套路可预测；创意写作最慢，因为大模型自己都不确定。

⚠️ 几条不能踩的线：草稿模型要和目标模型同家族（Llama-3 8B 配 Llama-3 70B 才行，Mistral 配 Llama 接受率撑不住）；温度越高接受率越低；输出很短的任务（<50 字）摊不薄初始化开销；显存已经满了就别加。

四、第三层：换模型（架构层）

这是收益最大的一层，也是最反直觉的一层。

4.1 MoE：参数多的，可能比参数少的快得多

MoE（混合专家）把前馈网络拆成很多个专家，每个字只挑几个上工。名字里的 A3B 说的是"激活 3B"。

关键在于区分两个数字：

举个极端例子：一个 35B-A3B 的 MoE 模型，每字只激活 3B；一个 27B 的稠密模型，一个字一个字都得全体过一遍。前者参数多三成，速度能快将近十倍。

所以看模型先看激活量，别看总参数。 这一条能帮你省下最多时间。

代价是：总参数一个没少，35B 的权重该占的显存一点没省。 MoE 省的是算力不是显存——它把"能不能算得快"和"装不装得下"这两件事彻底分开了。

4.2 压缩 KV cache：GQA、MLA

对话一长，显存大头就从权重切换到 KV cache 了。三种主流做法：

MLA 值得多说一句。它不是"让几个头共用"，而是压缩存储格式本身。DeepSeek 的做法是：存的时候存一个压缩潜向量，算注意力的时候用学到的投影矩阵现场还原 K 和 V。

公开口径：KV cache 降到标准多头注意力的约 5-7%，也就是省下九成以上。而且 DeepSeek 的消融实验显示，在同等压缩比例下，MLA 的质量保持能力明显优于 GQA，调好了甚至能反超 MHA。

⚠️ 这个数字来自 DeepSeek 公开论文，不是我实测。

（顺带一个小坑：位置编码不能直接加在压缩后的向量上，否则压缩空间就废了。MLA 的解法是"解耦 RoPE"，把语义内容和位置感知拆成两条独立路径。）

4.3 线性注意力与混合架构

这是 2026 年最热闹的方向。

标准注意力的复杂度是 O(N²)——上下文翻倍，计算量翻四倍。线性注意力把复杂度降到近似 O(N)，代价是"记性"差一点。

业界的解法是混着用：大部分层用线性/卷积层干脏活累活，少数层留标准注意力保精度。

LFM2 这个路子尤其适合本地：卷积块的状态大小是固定的，不随上下文长胖。只有那 10 层注意力会长 KV cache，等于把 KV 膨胀砍掉了四分之三。

⚠️ 以上都是厂商公开口径，不是我跑的。LFM2 我已经下到本地，跑完会单独出实测。

4.4 蒸馏

教师模型带学生模型，把大模型的本事塞进小模型。DeepSeek-R1 把 671B 的推理能力蒸馏到 1.5B-70B 的稠密模型上，R1-Distill-Qwen-32B 在 MATH-500 上拿到 94.3%。

对本地党的意义很直接：蒸馏出来的小模型不需要 MoE 路由，单卡就能跑，还带着大模型的推理能力。

五、第四层：改权重（磨刀）

终于到了动模型本身的一层。这里每一刀都是拿智商换体积或速度，区别只在划不划算。

5.1 量化：先分清几种格式

量化的意思是：每个参数本来用 16 位浮点数存，现在用 4 位整数存。体积小四倍，读起来快四倍，代价是精度损失。

GGUF（llama.cpp / Ollama 用，唯一能跑 CPU 和混合推理的格式）：K-quants 混合精度，不同层给不同位宽。

GPTQ：用 Hessian 矩阵（二阶信息）逐层最小化重建误差，老牌 GPU 4-bit 标准，存量生态最大。

AWQ：不看二阶信息，改看激活值分布，把最重要的那 1% 权重保护起来。2026 年 GPU 生产推理的默认选择，加载也最快。

EXL2 / EXL3：位宽能按小数设（比如 4.65 bit），精确卡死内存预算，ExLlama 专用。

FP8：Hopper / Ada 及更新的卡有硬件加速，接近无损。

一条最实用的经验法则：

同样显存下，大模型的低精度版，几乎总是打赢小模型的高精度版。
Q4 的 70B（约 40 GB）在几乎所有测试上都胜过 FP16 的 13B（约 26 GB）。

推论：先挑你显存装得下的最大参数量，再把剩下的显存花在更好的量化档或更长的上下文上，而不是换更高精度的小模型。

位宽的黄金点：

⚠️ 两个细节：

• imatrix（重要性矩阵）在低位宽下特别值钱。 它先跑一遍校准文本，看清楚哪些参数重要，量化时优先保它们。Q4 档可有可无，Q3 及以下基本是必需品；IQ 系列（IQ3_M、IQ4_XS）更是几乎必须配 imatrix。
• 训练越充分的模型越难量化。 参数里塞的信息越密，压起来损失越大。所以前沿模型越大，无脑上低位宽的风险越高。

5.2 剪枝：摘掉不干活的

剪枝分两大类，区别比大多数人想的重要：

MoE 的专家剪枝是结构化剪枝，所以它对普通用户是可用的——剪完就是个正常的小模型，llama.cpp 照跑。

剪枝最关键的一件事：校准集决定砍谁。

主流的判据是"路由权重 × 专家激活范数"，在一份校准文本上统计出来。这意味着：你喂什么文本，就决定砍掉谁。

喂英文代码，中文专家的得分就低，整块被清除——这不是误伤，这是算法按你说的在做。所以同一份模型，换一份校准集，剪出来就是两个物种。

⚠️ 必须纠正一个常见误解：剪枝不等于提速。

MoE 剪掉一半专家，每个字要激活的参数量一个没少——还是那套 top-k 路由，说好激活 3B 还是 3B。砍掉的是本来就不干活的那批。

省的是仓库面积，不是每次出工的人数。

所以剪枝买的是"装得下"，不是"跑得快"。想提速，剪枝得配合"少卸几层到 CPU"才能间接兑现。

📌 我实测过一版剪掉一半专家的 Qwen3.6-35B-A3B：体积小了三成三、卸载层数少了 11 层、量化档还更高——三样便宜占尽，速度反而慢了约一成，代码跑分还反超了原版。这个矛盾很值得单写一篇，这里先按下不表。

5.3 低比特：2 bit 是道悬崖

2 bit 往下，普通的训练后量化基本崩了，只有量化感知训练（QAT）能保住可用模型。

QAT 是在训练过程中就模拟量化噪声，让模型学会适应。QLoRA 是更常见的折中——基础模型量化到 4 bit，只训练高精度的 LoRA 适配器。

BitNet 是另一条路：1.58 bit 三值量化，权重只取 -1/0/+1。它"不在那条曲线上"——因为它从一开始就只有这些位，没有精度可丢。代价是你不能把现有模型转成它，只能从头训。

5.4 稀疏化：给权重定硬规矩

剪枝是"整块拿走"，稀疏化是"零敲"，而且敲的位置要符合硬件能识别的图案。

最主流的是 N:M 半结构化稀疏，其中 2:4 是 NVIDIA Sparse Tensor Core 的门槛——每连续 4 个权重里最多留 2 个非零，这样才能触发硬件加速。

难点在于：全精度模型的权重分布是单峰的（都挤在零附近），硬要砍掉一半，砍到的往往是有信号的权重，性能断崖式下跌。

有意思的是低比特和稀疏化能互相成全。微软的 Sparse-BitNet 发现：1.58 bit 的 BitNet 权重天然分成三峰，约 42% 已经是零，砍的时候阈值落在噪声区而不是有效权重上。结果在 2:4 稀疏度下，BitNet 性能只掉 5.7%，而 BF16 基线崩了 18.8%。

六、四层怎么叠加：我的顺序建议

先榨干上两层，再考虑动下面。

理由很实在：头两层不要钱、不伤模型，改完不满意撤回来就是了，模型一个字节没动。后两层改的是模型本身，改坏了就是改坏了，只能重下——重下一个 20G 的模型，在普通家宽下是大半天。

四层内部也有优先级：

七、五个常见误区

八、接下来我会逐层实测

这篇讲的是通用原理。接下来我会在自己的机器上（RTX 3070、8G 显存、R9-7900、64G DDR5 5200）按层往下测，每层单独出一篇：

补一项我回来更新一次这篇。

来源与口径

本文是科普整理，数据与结论来自公开资料：

• 引擎选型：vLLM / SGLang / Ollama / llama.cpp 官方文档与 2026 年多篇第三方横评。
• Ollama vs FreeToken 速度对照：第三方实测（RTX 5090 32G + Ultra 9 285K + 64G DDR5，Qwen3.6-35B），非本人机器。
• 带宽墙：H100 算力 990 TFLOPS、显存带宽 3.35 TB/s，公开硬件规格。
• 投机解码接受率与加速：SSD 论文实测（Llama-3 70B，单卡 H100）。
• KV cache 容量公式与算例：多篇工程博客一致口径，以 Llama-3 70B（80 层 / 8 KV 头 / 128 头维度 / FP16）为算例。
• PagedAttention / 前缀复用：vLLM 与 SGLang 官方文档及 PagedAttention 论文（arXiv:2309.06180）。
• MLA 压缩比：DeepSeek 公开论文口径。
• Qwen3-Next / LFM2 / MiniMax / Kimi Linear 的混合比例与收益：各厂商官方发布口径，非实测。
• 量化格式与位宽黄金点：llama.cpp 社区与 2026 年量化综述口径。
• 剪枝判据、结构化与非结构化区别：MoE 推理优化综述（arXiv:2412.14219）及多篇专家剪枝论文。
• 稀疏化与 Sparse-BitNet：微软研究院（arXiv:2603.05168，CVPR 2026）。
• 📌 唯一一处本人实测（剪枝那句）：llama.cpp build 10166，模型 qwen36-reap50-Q5_K_M-imat.gguf，完整数据另文。

⚠️ 硬件、驱动、llama.cpp 版本不同，结果会有出入。抄参数之前先在自己机器上跑一遍。

更多AI相关，如免费API资讯、实测、教程，请关注同名GZH。