一次性讲清楚 Qwen3.8 27B 的本地部署

从零开始 · Mac 和 N 卡两条路线 · 附 4090 实测数据

先说一个我自己都没想到的实测结果：

一个 9.83GB 的压缩版模型，在我那 72 道短题上，跟 30GB 的版本打成了平手。

结论先甩出来：一张 12GB 的普通游戏卡（3060 12G、4070 这种）就能跑，干短任务没问题。 断网能用，不花一分钱 token 费，资料不用上传给任何人。

（先说清楚两件事：同分不等于同一个东西——两者的量化方式、显存占用、长文表现都不一样，第四章会详细对比。短题平手也不等于长任务平手——社区在 41 个 agent 长任务上的实测显示 2-bit 会明显掉队（Q2_K_XL 27/41 对 Q4_K_M 35/41），我自己第三轮也测到 Q2 思考要多花 2.14 倍。）

先花半分钟，说说这是什么

Qwen3.8 27B 是阿里 8 月 14 日刚开源的模型，Apache 2.0 协议，随便商用。 27B 稠密参数、原生能看图看视频，但主业是干活：写代码、调工具、读长文——官方定位就是端侧 Agent 模型，256K 上下文，还能扩到 1M。开源两天 Hugging Face 下载破百万，N 卡、Mac、AMD 全是第一时间支持，不少人的评价是“目前最有性价比的端侧 Agent 模型”。官方跑分 SWE-bench Pro 61.7，号称超 Claude Opus 4.6 Max——这是官方口径，第三方复现还在路上；我自己测的在第四章。

它有两个设计跟你的钱包直接相关，后面章节会反复用到：

• 混合注意力：64 层里只有 16 层是全注意力，KV Cache 比传统模型省约 75%——这就是 24GB 游戏卡敢谈十几万字长文的原因（第五章会细算这笔账）

• MTP 官方内置：推测解码头直接做进了模型文件，不用另外下载，开个参数生成速度就翻倍（第七章会拧这个开关）

这篇就讲一件事：怎么把它装上你的机器、调出全力。

这篇我从“你的电脑能不能跑、跑起来卡不卡”开始讲，一路讲到装好、调好、知道它快在哪慢在哪。所有专业名词第一次出现都用大白话解释。你不需要有任何本地部署经验。

写给谁：

• 想装个大模型在自己电脑上，但不知道从哪下手的

• 手上有台不错的 Mac 或 N 卡，不确定配置够不够的

• 已经装过、但不知道怎么调才最快的（直接看第五章和第七章）

我写这篇的直接原因，是踩了个认知坑：我一直以为“窗口开大 = 模型变慢”，不敢把窗口调高。测完才发现窗口大小、内容长度、显存占用是三笔完全不同的账——这三件事没分清，后面所有配置都是瞎调。第五章专门讲这个。

这篇很长，先挑你要看的

全文约 2 万字，你大概率不用全读。这篇按四个问题组织，挑你的那条点链接直达（如果点了没跳，按章节号搜索也能到）：

① 它是什么、值不值得装 → 开头那节 + 第二章

② 你的机器能不能跑、选哪个版本

• 能不能跑、什么体感 → 第一章，5 分钟

• 一堆版本不知道下哪个 → 下面那张选型表就够了；想看依据再翻第四章

• 用的是 Mac → 6.9 节，单独写的

③ 怎么装

• 已经决定装了，只要命令 → 第六章 6.1，照抄就行（在全文一半的位置，直接搜“6.1”也能到）

• 装的时候报错了 → 第八章“五个坑” + 6.8 节

④ 怎么调快

• 装好了但嫌慢 → 第五章 + 第七章

想看完整过程和数据 → 从头读，约 40 分钟。四轮质量测试、DFlash 2 横评、5090 对比这些实测细节单独写了一篇：《想证明量化版更差，我测了四轮都没证成》

不想读完的，看这一段就够

先把结论全甩出来，想知道怎么来的再往下读。

你的显卡该下哪个：

版本多大什么卡用原版 BF1655.56GB80GB 专业卡、或 128GB 以上的 MacQ8_0 / Q623–30GB32GB 以上Q8attn（4-bit 主体）19.1GB32GB 以上Q4_K_M 16.5GB20GB 以上，我推荐这个Q2_K_XL9.83GB12–16GB 卡IQ2_S / IQ1_M6.7–8.4GB别用，明显变笨

名字看着乱，规律就一条：数字越小、文件越小、越省显存，但压过头会变笨。 原版最准，但要 80GB 级的机器；这篇讲的是一张消费级显卡怎么跑，所以从压缩版讲起，Q4_K_M 是我测下来的平衡点。

12–16GB 档的一个坦白：这档我只测了 Q2_K_XL。Unsloth 还有 Q3_K_XL（12.24 GiB）和 IQ4_XS（13.27 GiB），正好卡在这个显存区间，我没测过。社区在 41 个 agent 长任务上的数据是：Q2_K_XL 27/41、Q3_K_XL 33/41、Q4_K_M 35/41——2-bit 少完成两成任务。所以：只干短任务，Q2_K_XL 没问题；要跑 agent 长任务，16GB 卡建议优先试 Q3_K_XL，别直接抄我的 Q2 配置。

这张表只管“下哪个文件、要什么卡”。每档能开多大窗口、多快、吃多少显存，第一章那张总表逐行列了——全文只有那一张是完整对照，别处都以它为准。Mac 用户看第一章那张 Mac 专表：16GB 只能条件苛刻地凑合，24GB 才是起步线。

几个最该知道的结论：

• 窗口开大只占显存，不影响速度 —— 真把内容塞满才会慢。这是全文最重要的一条

• 装机全程约 14 分钟（下载 12 分半是大头），国内一定走 hf-mirror 镜像

• 别看文件名猜位数 —— Q8attn 是 4-bit 主体，不是 8-bit

• 量化的代价：答对了，但想得更久 —— 小量化版 tok/s 更高，但可能多想两三倍，总时间反而不省

• 速度配置用 MTP3 就够，新出的 DFlash 2 日常场景还更慢（这是 N 卡结论，Mac 上正好相反，见 6.9）

• 模型跑起来了不代表能用 —— 一定要发个真实请求验证，日志说 model loaded 会骗人

想知道每个结论怎么测出来的、我踩了哪些坑，就往下读。光质量我就测了四轮，前两轮全是白测的——正文只留了影响你选型的结果，完整的测试过程单独写成了另一篇。（不知道从哪看起的，回开头“这篇很长，先挑你要看的”那份路线图。）

下面第零章是术语表——可以先跳过。每个词第一次出现时正文都会当场解释一遍，遇到不懂的再回来查就行。

第零章：几个词先说清楚

这章是术语表，可以先跳过直接看第一章——每个词第一次出现时正文都会当场解释，这里只是方便你回头查。已经熟悉 KV Cache、MTP、量化这些词的更不用停留。

（token、上下文这些大家都懂的就不啰嗦了，只说后面反复出现、容易懵的。）

tok/s（每秒多少字）

模型每秒吐多少字，后面所有速度都用它。参照：人正常阅读约每秒 5–10 字，所以 47 tok/s 就是“你根本读不过它”。

显存 / 统一内存

N 卡用户看显存（显卡上的专用内存），Mac 用户看统一内存（内存显存是同一块，共用）。模型得整个装进这里面才跑得快，这是全篇最重要的硬指标。

量化（Q4、Q6、Q8 这些）

把模型“压缩着存”，压得越狠越省显存，也可能损点精度。数字越小压得越狠：Q2 最省、Q8 最保真。第三章讲原理。

GB 和 GiB（这两个不是一个东西）

GB 按 1000 进位，GiB 按 1024 进位，同一个文件用两种单位写出来数字不一样——比如 Q2_K_XL 写成 9.83GB 和 9.15GiB 是同一个文件，别以为是两个版本。本文正文统一用 GB；只有下载命令附近标注 GiB，因为 HuggingFace 页面和 wget 进度条显示的是 GiB，照着核对文件大小时别对不上号。

窗口

模型一次最多能记住多少内容，像桌子多大。启动时可以设成 32K（小桌）或 256K（大长桌）。记住：桌子大 ≠ 干活慢，第五章细讲。

预处理（Prefill）

你把内容发过去，模型不会立刻开口——它得先把你发的内容从头处理一遍（建立 KV Cache）才开始答。这段等待就是预处理。发两句话 0.2 秒；发 25 万 token，三分半钟。

KV Cache

模型处理输入时缓存下来的中间结果。有了它，生成每个新 token 时不用把前面的内容重算一遍。上下文越长，KV Cache 越大，占的显存越多——这是显存消耗的大头之一。

MTP（多 token 预测）

一种加速技术：让模型提前预测接下来的几个 token，验证通过就一次输出多个，省下逐字生成的时间。预测命中的比例叫“接受率”——接受率高就快，低了反而更慢（白算一遍）。

KV Cache 也能量化（q8 / q4）

KV Cache 本身也可以压缩存储。q8 精度高、占显存多；q4 省一半显存、精度低一些。KV Cache 分 K 和 V 两部分，可以分开设置（比如 K 用 q8、V 用 q4），这是常见做法。

空载 / 满载

我后面对比速度时会用这两个词：空载指窗口开着但只发了一两句话；满载指真把窗口塞满了内容。这两种情况速度差很多，第五章会专门讲。

offload（分层放）

大模型分很多层。层放显卡上跑得快但吃显存，挪到内存省显存但慢。显存不够时靠它续命。

ubatch（一次读几页）

模型读你发的内容时，一次处理多少。像看书一次翻几页——翻多几页可能读得更快，但不是越多越好，第七章有实测。

冷启动 / 热启动

冷启动是刚开机、模型还没进显存，第一次加载要多等一会儿；热启动是已经跑过一轮，再启动就快得多。

第一章：先花两分钟，看你的电脑能不能跑、跑多快

模型压缩完从 7GB 到 30GB 不等，下错了白等一小时。所以先花两分钟对号入座。

第一步：查你的机器有多少

Mac（M 系列）： 左上角 → 关于本机 → 看“内存”。这个数就是全部预算，模型和系统共用。

Windows / Linux + N 卡：

• Windows：Ctrl+Shift+Esc → 性能 → GPU → 看“专用 GPU 内存”

• 或命令行 nvidia-smi，看右上角总量

• 顺便看下内存（建议 32GB 起），显存不够时靠它兜底

一张总表：先找到你自己那一行

后面的章节会把每个数字的来龙去脉讲清楚。如果你只想知道“我该下哪个、能开多大窗口”，看这一张就够了。

先记住一条硬线：Q4_K_M 最省的配法（q4 KV、32K）也要 16,338 MiB。 装不下它的卡，没有第二选择；装得下的，模型质量都一样，只是想要长窗口还是想要快之间的取舍。

① 装不下 Q4_K_M 的（≤16GB）：没得选，不是取舍

显卡容量只能用窗口显存代价≤8GB没有能全塞进显卡的方案—最小的 IQ1_M 也要 8.17GB有人靠 offload 分层放跑起来过（ 外部报告），速度掉一个量级，见 6.712GBQ2_K_XL32K10.92GB72 题 41 分（Q4 是 47）；每题多想 2.14 倍；显存太紧，开不了 MTP16GBQ2_K_XL128K14.66GB同上

② 装得下 Q4_K_M 的（18GB 起）：质量固定，只选窗口和速度

下面全部是同一个模型 Q4_K_M，答题质量一样（72 题 47 分，全文最高），不存在“用质量换窗口”。 每格的速度都标了是“长文”还是“短任务”。

显卡容量配置一：优先长窗口配置二：优先速度18GBq4 KV、64K，17,090 MiB，长文 40.36 tok/s同左（MTP 贴线：18,148 MiB 只剩 284MiB，不建议开）20GBq4 KV、128K，18,548 MiB，长文 33.56 tok/sq4 KV + MTP3、32K，18,148 MiB，短任务 105.70 tok/s（全文最快）24GBq4 KV 不开 MTP、256K，21,492 MiB，长文 25.25 tok/s，25 万字 17/17q4 KV + MTP3、192K，22,637 MiB，长文 59.52 tok/s32GB 及以上q4 KV + MTP3、256K，24,422 MiB，长文 53.15 tok/s同左，已经是这张卡的最优解

补充参考（其他路线，数字来源和测法都不同）：

• RTX 5090 32G（⚠️ 外部报告）：LOW + MTP2、256K 仅声明贴线存疑，短测 105.5 tok/s、约 30.2GB——只能当短上下文参考

• AMD 7900 XTX 24GB（⚠️ 外部报告）：约 62 tok/s（第三方客户端输出，量化版本和窗口未声明）——AMD 对这个模型是 Day-0 支持，A 卡是能跑的；我手里没有 A 卡，只当量级参考

• Mac 16GB（本机实测）：Q2_K_XL、最多 32K，4–6 tok/s（条件苛刻，见 6.9），9.83GB + swap

• Mac 24GB+（⚠️ 外部报告/估算）：24GB 起 MLX 4-bit + MTP 约 10 tok/s；32GB 以上约 10–40，开投机解码还能翻倍——具体看下面“Mac 用户”那张表

表里的速度不能横着比。 “短任务”是 32K 小窗口，“长文”是塞满 25 万字——同一张卡，内容越多越慢，不是卡不快。

第二步：对号入座——能不能跑，跑起来什么体感

先说清楚速度意味着什么。参照物是人的阅读速度，每秒 5–10 字：

• 30 tok/s 以上：刷刷地出，非常的爽，完全没等待感

• 15–30：跟得上，很舒服，日常干活够用

• 8–15：能用，但看得出它在一个字一个字蹦

• 5 以下：干等，不如用云端

⚠️ 三个容易搞混的“大小”，先分清：

• 卡容量：你显卡有多少显存

• 文件大小：模型文件占硬盘多少（比如 Q2_K_XL 是 9.83GB）

• 实际占用：跑起来吃多少显存——永远比文件大，因为还要加 KV Cache 和运行开销

比如 Q4_K_M 文件约 16GB，但 32K 窗口最省的配法（q4 KV）跑起来要 16,338 MiB，所以 16GB 卡装不下（只剩 46MiB），得 18GB 起。按文件大小买卡，一定会翻车。

Mac 用户看这张：

芯片 + 内存能跑吗下哪个版本不开投机解码开投机解码后数据来源基础款 16GB 条件苛刻才凑合Q2_K_XL 能装下4–6 tok/s（关思考、8K 窗口、清后台）帮不上（见 6.9） 本机实测，见 6.9M4 mini 24GB 可以MLX 4-bit + MTP34.12 tok/s9.94 tok/s 外部报告M4 基础款 32GB 可以Q4_K_M + MTP约 10–15约 23–35 按 2.3× 折算的估算M2/M3 Pro 32–36GB 可以Q4_K_M + MTP约 10–14约 23–32 估算M2 Max 舒服4-bit + DFlash2—22 tok/s 外部报告M4 Pro 48–64GB 舒服UD-Q4_K_XL + MTP约 15–22约 35–50 估算M3/M4 Max 64–128GB 很舒服Q5/Q6 甚至 Q8约 25–4072.1（代码）/ 53.3（散文） 外部报告（M4 Max）M2/M3 Ultra 128GB+ 随便造Q8 甚至原版34 tok/sMTP 79 / DFlash2 88 外部报告（M3 Ultra）M5 Max 128GB 随便造4-bit26 tok/s70–87.9 tok/s 外部报告

Mac 上一定要开投机解码。 M3 Ultra 开与不开是 88 对 34，差 2.6 倍；用 MTP 还是 DFlash2、怎么开，见 6.9。

表里只有 16GB 那行是本机实测，其余是外部报告或按带宽折算的估算——任务、窗口、量化各不相同（同一台机器换个任务能差 30%），只当量级参考。

速度看内存带宽，不看 CPU 核心数：带宽翻倍，速度基本翻倍。买二手注意——M3 Pro 带宽（150GB/s）比上一代 M2 Pro（200GB/s）还低，为跑模型别买它。

⚠️ 上面所有数字都只是“模型本身”占的地方，还没算 KV Cache。

你窗口开多大，就要多留几个 G 给 KV Cache。以我这张 48G 卡为例，同一个模型：窗口 32K 占 20.4GB，开到 256K 涨到 30.3GB——光换个窗口大小，多吃 10 个 G。

所以留 20% 余量，别卡着上限选。12GB 卡跑 9.83GB 的模型，窗口就别想开太大。

第三步：跑不动怎么办

三条退路，别硬撑：

• 换小一号的模型——8B 级别 8GB 显存就能跑，日常问答够用

• 接受更狠的压缩——但看上表，1-bit 那档真的只是演示，别抱幻想

• 直接用云端 API——一个月用不了几次的，就别折腾了。为了偶尔用一次去买张显卡，这账算不过来

第二章：动手前，先花 10 分钟确认它值不值得装

这章讲怎么少走弯路。已经决定要装的，可以跳过。

这步很多教程不写，但最省时间。

模型下载动辄十几到三十 GB，网速一般要一小时起步。下完发现“这模型不是我要的”，那一小时就白等了。

所以先去网页版摸一摸。 随便问几个你真实会用到的问题——不是“你好你是谁”，是你工作里真会丢给它的活：读一段你的代码、总结一份你的资料、按你的要求写点东西。

重点看两件事：

• 指令遵循度——你提三个要求，它办了几个

• 你最常干的那类活它干得怎么样——写代码的看代码，写文案的看文案

这两样满意了再往下走。不满意就到此为止，省下一小时下载和半天折腾。

先说明一点：网页版和本地版不完全等价。 网页版跑的通常是没压缩的完整版，本地是压缩版，质量有差距（第四章有实测）。所以网页版体验到的是这模型的上限——上限你都不满意，本地版只会更不满意。

第三章：为什么必须“压缩”这个模型

这章讲原理：为什么非压不可、压了为什么还能用。只想动手的直接搜“6.1”跳到装机命令。

显存现状

Qwen3.8 27B 的官方原版——没经过任何压缩的完整版——18 个权重文件加起来 55.56GB。

先看看市面上的卡都有多少显存：官方版 4090 是 24GB，5090 是 32GB，绝大多数人手里的卡在 8–24GB 之间。没有一张消费级显卡装得下 55.56GB。

连我这张特例都不行：4090 魔改的 48G 版，显存已经翻了官方一倍，实际可用约 49GB——55.56 > 49，还是装不下。 而且这还没算运行时的 KV Cache 和临时开销，真跑起来还得多十几个 G。连魔改卡都装不下，普通卡更没戏。

所以在消费级显卡上必须压缩，没得选——这不是省钱的取舍，是所有人的必经之路。很多人一上来纠结“量化会不会变笨”——装都装不下，纠结这个没意义。

压缩了为什么还能用？

用照片打比方。

一张单反原图 50MB，发微信被压成 2MB，你看还是那张照片，脸还是那张脸。因为照片里大量信息是冗余的——天空那一大片蓝，不需要每个像素都存精确数值。

模型也一样。模型里存着几百亿个数字（权重），原版每个数字用 16 位存，精确得要命。但很多数字并不需要那么高精度——把 3.14159265 存成 3.14，模型的判断基本不变。

量化干的就是这件事：用更少的位数存每个数字。

• 原版（BF16）：每个数字 16 位，最精确，最占地方（55.56GB）

• Q8：压到 8 位，体积减半，精度损失很小（约 30GB）

• Q4：压到 4 位，再减半（约 16GB）

• Q2：压到 2 位，极限压缩（约 10GB）——按常理该崩了，但实测出乎意料，第四章说

为什么同样是 4 位，压法不一样

同样压到 4 位，不同格式的压法差别很大：有的按固定块粗切，有的（比如英伟达的 NVFP4）分块更细、每块单独缩放。英伟达官方说这样精度损失的风险更低——我一度信了，主力用了它好几个月，测了四轮也没验证出来。到底怎么回事，第四章用数据说。

第四章：该选哪个版本

这章讲选型。你要是已经决定用 Q4_K_M（我的推荐），直接搜“6.1”跳到装机命令——这章都是选型依据，不看不影响动手。

上一章讲清楚了为什么必须压缩。这一章回答下一个问题：压缩版本有一堆，到底该下哪个？

我为这一章测了四轮，还发现自己犯了两个错，而且是同一种错——看着文件名和官方文档做推断，没去测。 先把错认了，再上数据。

错误一：我把 4-bit 当成了 8-bit。 我一直把 Q8attn 当成“8-bit 版本”。它的全名 Qwen3.8-27B-NVFP4-MTP-Q8attn 其实已经说清楚了：主体是 NVFP4，也就是 4-bit，只是 attention 部分用了更高精度（这就是 Q8attn 的来历）。传统的 8-bit 是 Q8_0，那是另一个文件。光看文件名猜位数，很容易搞反。

错误二：我以为 NVFP4 更聪明。 NVFP4 是英伟达自己的 4 位格式，压法确实更细，官方说精度损失的风险更低。我信了这个说法，主力用了它好几个月。然后测了四轮，一轮也没测出它比普通 4 位的 Q4_K_M 聪明：

测试Q8attnQ4_K_M结果固定 72 题41/7247/72Q4 高 6 分25 题核心正确率25/2525/25平同题 24 道·思考 token1.20×0.97×Q4 少想 19%同题 24 道·每题耗时18.52 秒13.81 秒Q4 快 25%15 题严格同题（q8 KV）12/1513/15Q4 高 1 题，p=1.000015 题严格同题（q4 KV）13/1512/15Q8attn 高 1 题，p=1.000025 万字长文精确召回3/33/3平

分差最大的那组 72 题是 Q4 高 6 分——但那组不是同轮配对测试，不算干净对照；唯一一组严格同题配对是打平，p=1.0000。所以准确的说法是：我没测出 NVFP4 更聪明，也没证明它更差。 英伟达大概率没说错，他们测的是自己的基准，和我跑的代码题、数学题、25 万字长文召回对不上。

这四轮怎么设计、前两轮为什么白测、哪两篇论文把我点醒、每一轮的原始数据——完整过程单独写成了一篇：《想证明量化版更差，我测了四轮都没证成》。这一章下面只留直接影响“你该下哪个”的数据。

那 NVFP4 到底还值不值得用

值。它输的是“更聪明”这个说法，速度和显存上还是有位置的——下面这张表按窗口和 KV 设置分开列，每一格的速度只对应它自己那档配置。

关于下面所有速度数字：来自我第二轮测试（任务更严、条件统一）。同一个配置在不同任务下会有 10% 上下的浮动——我自己就测出过两组对不上的数，原因在实测记录那篇里讲了。

主力档实测（48G 卡，装满 25 万 token 真实内容）

版本读完 25 万 token生成速度显存旧 Q8196.8 秒19.88 tok/s36.9GBQ6205.2 秒22.75 tok/s31.0GBQ8attn q8（我选的）214.0 秒47.67 tok/s30.3GBQ8attn q8K/q4V212.9 秒49.09 tok/s28.2GBQ8attn q4/q4212.3 秒59.01 tok/s26.3GBLOW q8219.8 秒39.07 tok/s26.8GB

核心结论：在这次真实 250K 结构化任务里，新版（Q8attn）的生成速度是旧 Q8 的 2.4 倍（47.67 对 19.88），同时少占 6.6GB 显存。

拿 Q4_K_M 跟表里的 Q8attn 比：同样跑满 256K，Q8attn q4/q4 是 59.01 tok/s、26.3GB，Q4_K_M q4/q4 加 MTP3 是 53.15 tok/s、24.4GB——Q8attn 快 11%，Q4_K_M 省 1.9GB。

我最后推荐 Q4_K_M，是因为质量测不出差距的前提下，它更省显存、也更容易在 24GB 卡上跑起来。你要是有 32GB 以上、又想榨满 256K 的速度，Q8attn q4/q4 是更快的那个。

一个细节：新版“读”反而略慢（214 对 196.8 秒），但“写”快了一倍多。读只发生一次、写是持续的，所以这个取舍完全划算。

极限压缩三档：一张表说完

我把压缩推到极限，看小显存到底能不能干活：

版本体积总分相比旧 Q8一句话判决IQ1_M6.73GB24/72-45.5%像缩略图，出现过思考不闭合、HTTP 500。技术演示，不能干活IQ2_S8.37GB35/72-20.5%短任务凑合，250K 长文直接返回空答案（0/17），别跑长任务Q2_K_XL9.83GB41/72-6.8%和我现用的 30GB 版本同分；250K 长文 17/17 全对，31.34 tok/s

所以 9.83GB 的 Q2_K_XL 是可用下限，再往下要付真代价——Unsloth 官方文档也警告：从 Q2_K_XL 降到 IQ2_S，32-token 预测准确率从 25% 断崖跌到 8–10%，大量循环、空响应、工具调用失败，和我的实测对得上。

Q2_K_XL 的“同分”有边界：跑满 250K 要 19.65GB。所以 12GB 卡用它干短任务（32K 占 10.92GB）没问题，想跑满 250K 长文得有 24GB。

还有个反直觉的发现：压得越狠跑得越快，但也笨得越明显。 IQ1_M 短生成速度最快（89.53 tok/s）却最笨（24 分），Q2_K_XL 最慢（72.03）却最聪明（41 分）。别只看 tok/s 挑版本。

量化的代价：答对了，但想得更久

四轮测试里测出来的代价是这个。只比较“传统 8-bit 的 Q8_0 也答对的那 24 道同题”：

版本思考 token相对 Q8_0单题总耗时Q8_0481.581.00×22.16 秒Q8attn576.621.20×18.52 秒Q4_K_M467.210.97×13.81 秒Q2_K_XL1,032.252.14×17.98 秒IQ2_S1,495.583.11×22.16 秒

看 IQ2_S 那行：它的单 token 速度是全场最快的（32.38 tok/s），但完成一个任务要 22.16 秒——和最慢的 Q8_0 一模一样。因为它要多想 3.11 倍的 token，省下的每 token 时间，全被“想得更久”吃回去了。

量化模型 tok/s 更高，不代表任务更快。如果它为了答对多想两三倍，速度收益会被吃光。

第四轮我照着别人验证过的暴露点（AIME 级数学、长文精确召回、300 行代码）又打了一轮，Q8attn 和 Q4_K_M 之间只有一道题的翻转，配对检验 p = 1.0000，还是分不出高下。

那到底谁更强？我的诚实回答：我没能证明高位版本更聪明，四轮都没有。 最接近“同源对比”的 Q8_0 vs Q4_K_M 300 对盲测，是 81.67% 对 79.33%，差异不显著。但这句话有边界：不等于“Q4 和 Q8 一样好”（没测出不是证明相同），也不等于“量化没有代价”（Q2 思考膨胀 2.14 倍、IQ2 代码 8 道只对 4 道，都是实打实的）。

我推荐 Q4_K_M，靠的是三条：显存更低、单任务耗时最短（13.81 秒 vs Q8_0 的 22.16 秒）、四轮没观察到可靠的质量劣势。跟“它更聪明”没关系。

低位为什么没输？因为这几个版本用的不是同一种压缩工艺。Q8_0 是传统量化，均匀地砍每一层精度；Q4_K_M 和 Q2_K_XL 是 Unsloth 的动态量化——先用校准数据跑一遍模型，重要的层少砍、不重要的层多砍。还是照片那个比方：懂行的人用好算法压到 2MB，可以比外行随手压到 5MB 更清楚。位数不是唯一变量，怎么压才是。

（每一轮的题目设计、原始数据、样本量的局限，都在那篇实测记录里，这里不占篇幅了。）

中间档：Q4_K_M，以及压缩 KV Cache 能省多少

12GB 太挤、32GB 又买不起的人，中间还有一档 Q4_K_M（32K 窗口最省配法 q4 KV 实测 16,338 MiB，16GB 卡装不下，所以得 18GB 起步）。它在我那 72 道短题里拿了 47/72，是本次小样本中最高的。

但更值得说的是压缩 KV Cache 能省多少。同样是 Q4_K_M，KV Cache 从 q8 压到 q4：

窗口q8 KV 显存q8 速度q4 KV 显存q4 速度32K16,850 MiB45.1416,338 MiB44.8764K18,100 MiB41.0417,090 MiB40.36128K20,596 MiB34.4118,548 MiB33.56192K23,092 MiB29.7520,020 MiB28.96256K25,588 MiB26.3421,492 MiB25.25

256K 时，压缩 KV Cache 省下 4GB 显存，速度只掉 4.1%。

我之前担心“压缩 KV Cache 会让长文变笨”。实测下来 q8 KV 和 q4 KV 都是 17/17 全对，整轮只多等 1.87 秒——但这 17 道题所有版本都满分，说明题目太简单、测不出差距，所以这里只能说“没测出问题”，不能说“没有影响”。

24GB 卡必须压缩 KV Cache 才装得下——不压的话 256K 要 25.6GB，24GB 卡根本装不下。

测试边界

这些数字的局限得交代：Q8_0 不是原版 BF16，只是传统 8-bit 量化，当部署基准用；五个版本来自不同的量化配方，差异不能全归因于“位宽”；第四轮每组只有 15 题，样本量只够发现巨大差距。完整的边界说明（包括一道被我作废的题）在实测记录那篇里。

最终选择

按显卡对号入座：

• 默认推荐 Q4_K_M（任何显卡，只要装得下）——16.5GB、思考最省、单任务最快，四轮测试没观察到质量劣势

• 32GB 及以上要跑满 256K 长文：Q4_K_M + q4 KV + MTP3（24,422 MiB，长文 53.15 tok/s）——质量（47 vs 41）和显存都更省，是我推荐的首选；Q8attn（30.3GB，长文 47.70）是我个人常驻配置

• 24GB：Q4_K_M + q4 KV + MTP3，开到 192K（22.6GB，59.52 tok/s）。别硬开 256K，只剩 154MiB

• 18–20GB：Q4_K_M + q4 KV。18GB 能开 64K（17,090 MiB，长文 40.36 tok/s），20GB 能开 128K（18,548 MiB，长文 33.56 tok/s）；MTP 在 32K 只多吃 1.81GB，20GB 卡开得起（18,148 MiB，短任务 105.70 tok/s），18GB 开了就贴线（不建议）

• 12–16GB：Q2_K_XL，12GB 跑 32K（10.92GB），16GB 能到 128K（14.66GB）。限定：这是短任务的结论——agent 长任务社区数据显示 2-bit 会掉两成完成率，16GB 卡可以优先试我没测过的 Q3_K_XL（12.24 GiB）或 IQ4_XS（13.27 GiB）

• 8GB 及以下：我没测出可用的全 GPU 方案。混合卸载能启动，但速度太差，不推荐

第五章：全文最重要的一件事——窗口、内容、显存是三笔账

这章别跳。 全文只有这一章讲的是认知，不是操作——搞清楚这三笔账，你调任何模型都不会瞎调。

这章是我写这篇的初衷，我自己就在这儿绕了半天。

我原本的误解

“256K 窗口听起来很爽，但开这么大，模型肯定变慢吧？平时聊两句也被拖累吧？”

完全不是。

一张书桌，讲清三件事

窗口 = 桌子有多大。

你可以买张小书桌（32K），也可以买会议室那么长的桌（256K）。买大桌子唯一的代价是占地方——这里就是占显存。桌子大小跟干活快慢没关系。

内容 = 你在桌上摊了多少纸。

你可以在大长桌上只摊一张纸，也可以摊满 25 万 token。摊多少纸，才决定干活快慢。

为什么纸越多越慢？这个机制得讲透。

模型每写下一个新字之前，都要回头把桌上所有的纸扫一遍——这就是“注意力机制”：它要确保新写的字跟前面所有内容都对得上。

桌上一张纸，扫一眼就完事，唰唰唰地写。桌上摊了 25 万 token，它每写一个字都得把这 25 万 token 扫一遍；写第二个字，再扫一遍；第三个字，再扫一遍……

所以内容越长，每个字的成本越高，吐字速度就掉下来。这不是模型偷懒，是它的工作方式决定的。

还有一步：动笔前得先通读。 模型开写前要把桌上的纸读一遍、记好笔记（预处理）。25 万 token，光通读就三分半钟。

显存只跟窗口有关

我实测的显存占用，全程只跟窗口大小有关，跟你实际发多少内容没关系：

• 32K 窗口：20.4GB

• 64K 窗口：21.8GB

• 128K 窗口：24.6GB

• 256K 窗口：30.3GB

为什么？因为模型启动时就把桌子的地方占了——先把那张 256K 的大桌摆好、KV Cache 分配好，管你今天用不用得上。这是预留，不是实际用量。

最硬的一组证据：同一个配置，空载 vs 满载

上面那张表是“不同窗口”之间比。为了把话说死，我做了一组完全相同配置下的对照——同样开着 256K 窗口、同样的 KV Cache 精度、同样的 MTP 设置，只有“实际塞了多少内容”不同：

同一配置（256K 窗口 / q8 KV / MTP3）下：

• 空载（只发一句短话）：78.80 tok/s，峰值显存 30,272 MiB

• 填满 250K token：47.70 tok/s，峰值显存 30,280 MiB

看这两行：

• 显存几乎完全一样（差 8 MiB，等于没差）——因为 256K 那张大桌子的位置，启动时就预留好了，你今天用不用得上，它都占着

• 速度掉了 39.5%（空载是满载的 1.65 倍）——掉速的原因就是你真的把纸摊满了

一句话记住

开大窗口主要增加显存；把内容填满，才会明显拖慢生成。

把书桌换大，和真的读完一摞书，是两件事。

所以显存够就把窗口开大，别省。 平时聊两句不吃亏，需要时能一次塞进一整本书。

一个体感数字：这个配置下，从你按回车到蹦出第一个字，中位数 90.8 毫秒（第一次冷启动 226 毫秒）。不到 0.1 秒就开始出字，日常对话完全没有等待感。

第六章：手把手部署

这章分两条路线，按你的机器直接跳：

• N 卡（Windows / Linux） → 6.1 到 6.7，我的实机验证过

• Mac（M 系列） → 直接看 6.9，有图形界面和命令行两种走法

先给个心理预期：比你想的快

新手最怕“开始了不知道什么时候是头”。我从零跑了一遍完整流程，实测计时：

• 下载模型（走国内镜像）：12 分 33 秒（17.81 GiB，平均 24.3 MB/s）

• 编译 llama.cpp：约 1 分 40 秒，比想象中快得多

• 冷启动到收到完整回复：6.85 秒（模型加载进显存）

• 总计：约 14 分 20 秒，从开始下载到聊上第一句

十四分钟就能跑起来——大头是下载，编译反而只要一分多钟。当然你的网速决定下载时间，慢的话可能要一两小时。

硬盘至少留 40GB（模型 18GB + 编译产物 + 余量）。

6.1 装推理框架（llama.cpp）

用的是官方上游的 llama.cpp，不是任何第三方魔改版。

• llama.cpp build: b10441（commit 0177dcc7）

• 系统：Ubuntu 24.04.3 LTS

• CUDA:12.0.140

• 显卡驱动：595.71.05

• GPU 架构：Ada（sm_89）

为什么要固定版本？ 这个模型依赖 Qwen3.8、NVFP4 和 MTP 支持，旧版 llama.cpp 跑不起来。

第一步，确认显卡和 CUDA 能用：

plaintextnvidia-smi nvcc –version

nvidia-smi 要能看到你的显卡和显存总量；nvcc –version 要能输出 CUDA 版本。这两条有任何一条报“命令找不到”，先去装显卡驱动和 CUDA Toolkit，别往下走。

第二步，装编译依赖：

（网上很多教程会让你装 libcurl4-openssl-dev，这个版本用不上，CMake 会直接提示忽略。容易缺的是 Ninja。）

plaintextsudo apt-get update sudo apt-get install -y git wget openssl build-essential python3-venv ninja-build

第三步，下载源码并固定到验证过的版本：

plaintextpython3 -m venv ~/apps/llama-cuda-build-venv ~/apps/llama-cuda-build-venv/bin/pip install cmake==4.4.2

git clone https://github.com/ggml-org/llama.cpp.git ~/apps/llama.cpp-b10441-cuda-src git -C ~/apps/llama.cpp-b10441-cuda-src checkout 0177dcc7300bad8914bb838baabce87899812491

第四步，编译（这步最久，10–20 分钟）：

plaintext~/apps/llama-cuda-build-venv/bin/cmake -S ~/apps/llama.cpp-b10441-cuda-src -B ~/apps/llama.cpp-b10441-cuda-src/build-cuda
-DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON -DGGML_CUDA_FA=ON -DCMAKE_CUDA_ARCHITECTURES=89

~/apps/llama-cuda-build-venv/bin/cmake –build ~/apps/llama.cpp-b10441-cuda-src/build-cuda –config Release -j 16

⚠️ 一个不会报错、但你应该改对的参数：-DCMAKE_CUDA_ARCHITECTURES

这个数字是你的显卡架构代号：

• 30 系（3060/3080/3090）→ 86

• 40 系（4060/4070/4080/4090）→ 89

• 50 系（5070/5080/5090）→ 120

上面命令里写的是 89（我是 4090）。你不是 40 系的，改成对应的值。

我特意试了写错会怎样：在 4090 上故意写成 86（30 系的值），结果既不报错、也没有明显变慢（短测只慢 0.60%）。所以这个参数写错了你根本发现不了——不会有任何提示告诉你抄错了，编译产物也能跑，只是没有为你的卡做最优化。养成对着上面这张表核一眼的习惯。

另外 -j 16 是用 16 个核心编译，改成你 CPU 的核心数（不确定就写 -j 4，慢点但稳）。

验证装好了：

plaintext~/apps/llama.cpp-b10441-cuda-src/build-cuda/bin/llama-server –version

看到 version: 0.1.0-dev (build 1, commit 0177dcc) 就对了。

6.2 下载模型（国内用镜像，快很多）

只需要一个文件，17.81 GiB。

国内用户先设这个镜像，直连 HuggingFace 大概率下不动：

plaintextexport HF_ENDPOINT=https://hf-mirror.com

然后下载：

plaintextmkdir -p ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF

wget -c -O ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/Qwen3.8-27B-NVFP4-MTP-Q8attn.gguf
‘https://hf-mirror.com/utautako/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/resolve/main/Qwen3.8-27B-NVFP4-MTP-Q8attn.gguf?download=true’

wget -c 的 -c 是“断点续传”——下载断了（这么大的文件很常见），再运行一遍同样的命令就会接着下，不用从头来。

下完一定要核对大小，这是最常见的坑：

plaintextstat -c ‘%n %s bytes’ ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/Qwen3.8-27B-NVFP4-MTP-Q8attn.gguf

必须显示 19128349888 bytes。 数字比这个小，就是没下完（哪怕只差一点），继续跑 wget -c。

关于 MTP：不用另外下草稿模型。 这个文件里已经内嵌了 MTP 层，命令里的 draft f16 说的是运行时缓存精度，不是另一个文件。

可选：要给模型传图片的话，再多下一个 888 MiB 的：

plaintextwget -c -O ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/mmproj-Qwen3.8-27B-NVFP4-BF16.gguf
‘https://hf-mirror.com/utautako/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/resolve/main/mmproj-Qwen3.8-27B-NVFP4-BF16.gguf?download=true’

纯文字用不上，下面的命令都不带它。

6.3 建一个本地 API Key

只做一次：

plaintextumask 077 openssl rand -hex 32 > ~/qwen38-api-key

服务只监听 127.0.0.1（本机），不会暴露到公网。这个 key 是防止本机其他程序误调用。

6.4 三档启动命令，照抄就行

一次只能有一档占用 8080 端口。 初次部署建议直接在前台跑，日志显示在终端，Ctrl+C 停止。

A 档：日常 32K（新手从这档开始）

plaintext~/apps/llama.cpp-b10441-cuda-src/build-cuda/bin/llama-server
-m ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/Qwen3.8-27B-NVFP4-MTP-Q8attn.gguf
–alias Qwen3.8-27B-NVFP4-MTP-Q8attn
–host 127.0.0.1 –port 8080
–ctx-size 32768
–n-gpu-layers 99 –fit off
–threads 16 –threads-batch 16 –parallel 1
–batch-size 2048 –ubatch-size 512
–cache-type-k q8_0 –cache-type-v q8_0
–flash-attn on –jinja
–spec-type draft-mtp –spec-draft-n-max 3
–spec-draft-type-k f16 –spec-draft-type-v f16
–spec-draft-backend-sampling
–cache-reuse 0
–api-key-file ~/qwen38-api-key

这堆参数在说什么：

• –ctx-size 32768 = 桌子多大，这里是 32K

• –cache-type-k/v q8_0 = KV Cache 用什么精度，q8 是清楚详细那档

• –batch-size 2048 –ubatch-size 512 = 一次读多少页，512 是实测最优

• –parallel 1 = 只开一条并发槽位。这个参数值得单独说一句：llama.cpp 会把窗口按并发数平分，默认值不是 1 的版本里，你以为开了 256K，实际每条请求可能只分到一半。自己一个人用就锁 1，等于把整个窗口都留给自己——同样的显存能多出一大截可用窗口

• –spec-draft-n-max 3 = MTP 设成 3，我这台机器实测最优

• –n-gpu-layers 99 = 把所有层都塞进显卡（写个大数就是“全部”）

• –fit off = 禁止它偷偷缩窗口来“勉强启动”，显存不够就直接报错，免得你以为开了 32K、实际只开了 8K

• –flash-attn on = 开启那个省显存的底层算法

• –jinja = 用模型自带的对话模板，OpenAI 接口需要

• –threads 16 = 用 16 个 CPU 线程，改成你的核心数

还有一个我该早点提的参数：–reasoning-effort（思考档位）。 这个模型默认是 xhigh——想得最久、最容易把输出预算吃光。我们钉的这个 llama.cpp 版本里就带这个参数，可以在上面任何一条命令里加一行：

plaintext –reasoning-effort medium \

• 可选 xhigh（默认）/ high / medium / low，也可以设 none 整个关掉思考

• 什么时候调低：日常问答、写作这类不需要深度推理的活，medium 足够，响应明显变快

• 什么时候关掉：小显存 / 16GB Mac 这种性能紧张的机器，思考本身也占输出预算和时间，关掉能省一大截（6.9 节 Mac 的“打字机水平”就是以关思考为前提的）

• 它和第八章的坑一是同一件事的两面：想太久 → 吃光输出预算 → 答案被截断 → 看起来像“变笨”。发现模型突然变笨，除了检查输出上限，也检查一下思考档位是不是没必要地开在 xhigh

这档实测占约 20.4GB。

B 档：256K 稳妥（32GB 卡跑长文用）

跟 A 档只差两处：窗口 262144（256K）,V cache 压到 q4_0。

plaintext~/apps/llama.cpp-b10441-cuda-src/build-cuda/bin/llama-server
-m ~/models/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF/Qwen3.8-27B-NVFP4-MTP-Q8attn.gguf
–alias Qwen3.8-27B-NVFP4-MTP-Q8attn
–host 127.0.0.1 –port 8080
–ctx-size 262144
–n-gpu-layers 99 –fit off
–threads 16 –threads-batch 16 –parallel 1
–batch-size 2048 –ubatch-size 512
–cache-type-k q8_0 –cache-type-v q4_0
–flash-attn on –jinja
–spec-type draft-mtp –spec-draft-n-max 3
–spec-draft-type-k f16 –spec-draft-type-v f16
–spec-draft-backend-sampling
–cache-reuse 0
–api-key-file ~/qwen38-api-key

实测约 28.2GB。

C 档：24GB 卡的安全配置（192K）

这是 24GB 显卡的推荐档——用 Q4_K_M 模型，K/V 都压到 q4 q4，窗口开到 192K 而不是 256K。

先下载模型（Unsloth 的动态量化版 UD-Q4_K_M）：

plaintextmkdir -p ~/models/Qwen3.8-27B-GGUF

wget -c -O ~/models/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf
‘https://hf-mirror.com/unsloth/Qwen3.8-27B-GGUF/resolve/main/Qwen3.8-27B-UD-Q4_K_M.gguf?download=true’

下载完先校验大小，必须是 16464440224 bytes，小了就是没下完，wget -c 续传：

plaintextstat -c ‘%s’ ~/models/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf

然后启动：

plaintext~/apps/llama.cpp-b10441-cuda-src/build-cuda/bin/llama-server
-m ~/models/Qwen3.8-27B-GGUF/Qwen3.8-27B-UD-Q4_K_M.gguf
–alias Qwen3.8-27B-Q4
–host 127.0.0.1 –port 8080
–ctx-size 196608
–n-gpu-layers 99 –fit off
–threads 16 –threads-batch 16 –parallel 1
–batch-size 2048 –ubatch-size 512
–cache-type-k q4_0 –cache-type-v q4_0
–flash-attn on –jinja
–spec-type draft-mtp –spec-draft-n-max 3
–spec-draft-type-k f16 –spec-draft-type-v f16
–spec-draft-backend-sampling
–cache-reuse 0
–api-key-file ~/qwen38-api-key

实测 22.6GB、59.52 tok/s。别贪心开 256K——实测虽然能装下（24,422 MiB），但只剩 154MiB 余量，一点波动就崩。

6.5 验证装好没

启动日志里应该能看到显卡设备、模型加载、然后是 HTTP 服务在监听 127.0.0.1:8080。

另开一个终端，先看健康检查：

plaintextexport QWEN_API_KEY=“$(head -n 1 ~/qwen38-api-key)” curl -sS -H “Authorization: Bearer ${QWEN_API_KEY}” http://127.0.0.1:8080/health

返回 {“status”:“ok”} 就是活着。

再发第一句话：

plaintextcurl -sS http://127.0.0.1:8080/v1/chat/completions
-H “Authorization: Bearer ${QWEN_API_KEY}”
-H ‘Content-Type: application/json’
-d ‘{“model”:“Qwen3.8-27B-NVFP4-MTP-Q8attn”,“messages”:[{“role”:“user”,“content”:“只回复：QWEN_OK”}],“temperature”:0,“max_tokens”:128,“stream”:false}’

返回的 JSON 里能看到 QWEN_OK，就成了。

这是个 API 服务，不是网页。 用浏览器打开 127.0.0.1:8080 看到空白或报错是正常的，别以为装失败了。

6.6 装好了，然后怎么用？

跑起来只是第一步，得接到你日常用的工具里才有意义。这个服务是 OpenAI 兼容接口，所以凡是支持“自定义 API 地址”的客户端都能接：

• 想要聊天窗口 → 装个 Chatbox、LobeChat 这类客户端，在设置里把 API 地址填 http://127.0.0.1:8080/v1，API Key 填你刚生成的那个

• 写代码用 → Cursor、Continue 这类插件都支持自定义模型，填法同上

• 接 Claude Code → 设两个环境变量就行：ANTHROPIC_BASE_URL=http://127.0.0.1:8080 加 ANTHROPIC_AUTH_TOKEN=你的key（llama.cpp 这个版本自带 Anthropic 兼容端点）。agent 长任务对模型质量敏感，建议配 Q4_K_M 以上用，别拿 2-bit 版本跑（原因见开头 12–16GB 档那条坦白）

• 自己写程序调用 → 直接用 OpenAI 的 SDK，把 base_url 指到 http://127.0.0.1:8080/v1 就行，代码跟调 OpenAI 一模一样

模型名填 Qwen3.8-27B-NVFP4-MTP-Q8attn（就是启动命令里 –alias 那个值）。

6.7 显存不够时，“分一半给内存”值不值？

前面说过 –n-gpu-layers 能把一部分层挪到内存里跑（offload），显存不够时靠它续命。但代价有多大？我实测了一遍：

有多少层在显卡上生成速度显存占用全部（正常情况）73.61 tok/s26,176 MiB56 层24.36 tok/s23,258 MiB48 层15.67 tok/s20,682 MiB40 层11.08 tok/s17,964 MiB36 层10.05 tok/s16,620 MiB32 层9.04 tok/s15,262 MiB

看第一行到第二行：只挪出去几层，速度就从 73.6 掉到 24.4，剩三分之一。 再往下挪，速度掉到 10 上下就基本不动了——但显存也只省下 10GB 左右。

对照第一章那个体感表：10 tok/s 是“能用，但看得出它一个字一个字往外蹦”的水平。

所以结论很明确：

• 16GB / 18GB 的卡想硬开 256K 窗口，不值得。 靠 offload 是能跑起来，但只剩 9–10 tok/s，日常用会很难受

• 我的建议：换更小的量化版本（Q2_K_XL），或者把窗口调小。第一章那张总表就是按这个思路给的

• offload 只适合应急——比如临时需要处理一个超长文档，忍一次慢，别当常驻方案

这组数是在 48GB 的卡上通过限制 GPU 层数模拟出来的小显存场景。 真实的 16GB / 18GB 显卡，CPU 和 PCIe 带宽通常更弱，实际速度只会更低，不会更高。

6.8 四种最常见的启动失败

① 启动就 OOM（显存不足）

日志里有 CUDA error: out of memory 或 failed to allocate buffer for kv cache。

按这个顺序处理：

• nvidia-smi 看谁在占显存，确认没有重复启动了两个

• 先降窗口：–ctx-size 从 262144 降到 196608、131072、32768

• 再压 KV Cache：–cache-type-k/v 从 q8_0 改成 q4_0（实测省 4GB，速度只掉 4%）

• 关掉 MTP：去掉 –spec-type draft-mtp 那几行，能省 1.8–2.9GB（窗口越小省得越少：32K 省 1.81GB，256K 省 2.93GB），代价是速度掉一半

先别动 –n-gpu-layers 去 CPU 混跑——那是最后一招，速度会掉一个量级。

② 能加载，但第一个请求就炸

日志里有 failed to allocate compute pp buffers 之类。这是启动时只差一点余量。

先把 –ubatch-size 512 降成 256，还不行把 –batch-size 2048 降成 1024。

③ 模型路径或文件不对

日志里有 failed to load model。跑一下 stat -c ‘%s’ 你的模型路径，大小必须是 19128349888 bytes。小了就是没下完，wget -c 续传。

④ 端口被占了

日志说 Address already in use。

plaintextss -ltnp | grep ’:8080 ’

看是谁占着。如果已经是你自己的 llama-server，别再启第二个。如果是别的服务，把 –port 8080 改成 8081（curl 地址也跟着改）。别随手杀不认识的进程。

6.9 Mac 用户看这里

⚠️ 说明数据来源：16GB 那档我实机测过了（结果见下面“16GB Mac 实测”），32GB 以上是估算——按同类模型的公开数据和内存带宽折算。有 Mac 的朋友实测了欢迎打脸。

先说 16GB Mac：我测了，条件苛刻才凑合

我手上有台 M4 MacBook Air（16GB），拿它完整跑了一遍。先说修正后的结论：能跑，但条件苛刻。我第一轮测出的 0.75 tok/s，现在看是 swap 爆掉时的异常值，不是这台机器的正常水平。

先看花了多少时间准备：编译 llama.cpp 9 分钟、下载模型 24 分半、冷启动 14 秒。半小时准备工作。

然后是速度（Q2_K_XL，9.83GB，8K 窗口，三次取中位数）：

• 短问答（88 字）：0.75 tok/s，实际要等 2 分钟

• 写代码（600 字）：0.74 tok/s，实际要等 13 分半

• 长输出（1000 字）：1.48 tok/s，实际要等 11 分钟

对照第一章那张体感表：5 tok/s 以下就是“干等，不如用云端”。0.75 是这条线的七分之一。

更糟的是，写代码和长输出那 6 次请求全部撞到了输出上限被截断——它连话都没说完。

为什么这么慢？ 内存不够，系统在拿硬盘当内存用：swap 从启动前的 584MB 涨到了 3.9GB，内存压力全程黄色。数据在内存和硬盘之间来回倒腾，M4 的算力根本发挥不出来。

但这组数需要一个重要修正。 测试结束、机器空闲一段时间后，我又跑了一次短探针，速度到了 6.25 tok/s——是首测的 8 倍多。我当时把它当“受缓存预热影响的异常值”排除了，现在看排除反了：0.75 才是异常值。首测时 swap 已经爆了、内存压力全程黄色，测出来的是“swap 爆掉状态下的速度”，不是这台机器的正常水平。旁证也对得上：社区有人在带宽只有我这台一半左右的 M1 16GB 上、同一个 Q2_K_XL，跑出了约 4 tok/s、内存稳定——比我首测快 5 倍。硬件更弱反而更快，只能说明我那轮的环境坏了。

修正后的结论：16GB Mac 能跑到 4–6 tok/s 的“打字机水平”，但前提苛刻——关掉思考（见 6.4 的 –reasoning-effort 说明）、窗口只开 8K、关掉其他吃内存的程序，别让 swap 涨起来。一旦 swap 爆了，就会掉到我首测那种 0.75 的水平。

窗口上限：32K，但 64K 会骗你

• 8K / 16K / 32K：能启动，能完成短请求

• 64K：假成功——日志打印 model loaded、端口也在监听，但一发请求立刻 HTTP 500

64K 这个坑要特别注意：它初始化时 Metal 已经 OOM 了，但进程照样打印“模型已加载”、照样监听端口。 你以为装好了，实际是坏的，直到发第一个请求才报 Compute error。

整机可用性：还算能用，切换应用没卡死（程序化激活应用 0.09–0.35 秒）。但那是在内存压力黄色、swap 快 4GB 的状态下——别指望一边跑 27B 一边正常干活。

所以 16GB Mac 我的建议：能跑，但别当主力。 4–6 tok/s 是“看得出它一个字一个字蹦”的水平，而且条件苛刻——偶尔离线应急可以，日常干活还是换 8B 级小模型或用云端 API 更实在。

32GB 以上的 Mac：下面是步骤，但我没实测过

Mac 不用编译 CUDA，有两条路：

方法一：图形界面（推荐，不用碰命令行）

• 下载安装 LM Studio（或 Unsloth Desktop），都是免费的

• 打开后在模型库里搜 Qwen3.8

• 按你的内存选版本（对照第一章总表）：

• 32GB 内存 → UD-Q4_K_XL（约 18GB）

• 48GB → Q5_K_XL 或 Q6_K（20–23GB）

• 64GB 以上 → Q8_0

• 点下载，等它下完

• 加载模型，在设置里把上下文长度（Context Length）调到你想要的——注意第五章说的：开大只占内存，不影响短对话速度

• 开始聊

不想碰终端、只要一个能聊天的窗口，走这条。

方法二：命令行（要 API 接口的话）

Mac 上用 Metal 而不是 CUDA：

plaintextbrew install cmake git curl

git clone https://github.com/ggml-org/llama.cpp cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_METAL=ON cmake –build llama.cpp/build –config Release -j –target llama-cli llama-server

Mac 上不要开 CUDA，Metal 是默认的。Linux 的 apt 命令也别抄，用 brew。

下载模型（Unsloth 的动态量化版对 Mac 比较友好）：

plaintextexport HF_ENDPOINT=https://hf-mirror.com pip install -U “huggingface_hub[cli]”

hf download unsloth/Qwen3.8-27B-GGUF –local-dir ./Qwen3.8-27B-GGUF –include “UD-Q4_K_XL”

启动（参数比 N 卡少，不用 CUDA 相关的）：

plaintext./llama.cpp/build/bin/llama-server
-m ./Qwen3.8-27B-GGUF/你下载的文件名.gguf
–host 127.0.0.1 –port 8080
–ctx-size 32768
–n-gpu-layers 99
–flash-attn on –jinja

验证方法和上面 N 卡的一样（6.5 节）。

Mac 上把速度提到 2 倍以上：开投机解码

前面装完跑的是“不开投机解码”的速度。开了之后，同一台机器能快 2 到 2.6 倍——M3 Ultra 上有人测出开与不开是 88 对 34 tok/s（⚠️ 外部报告，我没有 Mac 高配机型验证，下同）。这一步别省。两条路线：

• 路线一：oMLX（不用编译，推荐）——Inco AI 给 macOS 出了带 DFlash 2 的预编译版，下载就能用。M3 Ultra 上外部实测 88 tok/s。

• 路线二：自己编 llama.cpp——上面的编译命令已经带了 -DGGML_METAL=ON，MTP 直接可用；但 DFlash 2 的支持还在 PR #27342 里没合并进主线，要用得手动切分支：

plaintextgit fetch origin pull/27342/head:pr-27342 && git switch pr-27342 cmake -B build -DCMAKE_BUILD_TYPE=Release -DGGML_METAL=ON && cmake –build build -j

选 MTP 还是 DFlash2，看内存：

• 内存 32GB 以下的，用 MTP 别用 DFlash2。 MTP 的草稿只有约 256MB，DFlash2 的要 1.06GB——内存紧的时候这 800MB 就是能不能跑的差别。24GB 的 M4 mini 有人用 MLX 4-bit + MTP 从 4.12 提到 9.94 tok/s，峰值内存 18.17GB（⚠️ 外部报告）

• 内存富余的两个都试。 Mac 和 N 卡的最优解不一样：我 4090 上 MTP3 比 DFlash2 快 9.4%，M3 Ultra 上反过来 DFlash2（88）比 MTP（79）快——别照搬本文第七章的 N 卡调优结论

• 16GB 的机器别试——模型本身已经把内存吃到靠 swap，草稿模型再小也塞不进

Mac 上有一条得记住：统一内存是和系统共用的，模型占太多会导致整机卡顿甚至开始用硬盘交换（swap），那时候速度会断崖下跌。别把内存吃到 90% 以上，给系统留至少 8GB。

Mac 上还有一选：MLX。 除了 llama.cpp，苹果自家的 MLX 框架（配 LM Studio 或 mlx-lm 都能跑），社区普遍反馈同等量化下生成速度比 llama.cpp 快一到两成。我这轮没测，本文 Mac 路线的数字都是按 llama.cpp/GGUF 测的——追求极致速度的 Mac 用户值得自己试试 MLX 版本。

第七章：时间都花在哪——按显卡分档，没有万能配置

这章讲怎么调最快。装好了、能用了，想再榨点性能出来的看这里。

测完最实在的结论：不存在一套配置能同时兼顾“和别的模型共存”、“256K 大窗口”和“最高速度”。 想要哪个就得放弃点别的。所以最优解是分三档，按需切换。（这张表管的是“装好之后怎么调”；还没决定下哪个版本的，先回第一章那张总表。）

先把两个我会反复用的词定义清楚：

• q8K/q4V 配置 = 只压 V cache（K 保持清晰、V 压缩）。慢一点，但保险。

• q4/q4 配置 = K/V 都压到 q4（K 和 V 都压缩），MTP 设成 4。更快更省显存，代价是 KV 精度更低，复杂推理时可能受影响。

场景配置实测32GB+ 日常常驻Q8attn、32K、q8 KV、MTP382.9 tok/s，约 20GB32GB+ 长文Q8attn、256K、q8 KV、MTP3满载 47.70 / 空载 78.80 tok/s，30.3GB24GB 硬开 256K（反面教材）Q4_K_M、256K、q4 KV、MTP353.15 tok/s，24.4GB——只剩 154MiB，不推荐12–16GBQ2_K_XL32K：62.96 / 128K：43.75 tok/s独占显卡的极速方案vLLM + W4A1668.0 tok/s，占 45.5GB，无法与别的服务共存

（Q4_K_M 各档——18 / 20 / 24GB——的配置和速度都在第一章那张总表里，这里不重复。）

你该选哪档？照这个走

• 显卡只跑这一个模型，追求极致速度 → vLLM + W4A16，68 tok/s 是这张卡能跑到的最高速度

• 显卡还要跑别的东西（我这台还挂着视频模型和图像模型）→ 常驻 32K 那档，82.9 tok/s 已经很快，只吃 20GB，留足空间给别人

• 突然来个超长任务（塞一整本书、一个完整代码库）→ 临时切 256K（q8 K / q4 V），用完切回来

• 256K 和 vLLM 都别长期常驻——为了偶尔用一次的能力天天多占十几个 G，不值

下面展开讲两件事：MTP 开不开、缓存怎么复用。

MTP 开不开：生成快一倍，多占 2.9GB 显存

以 Q4_K_M + q4 KV 跑 250K 长文为例：

• 不开 MTP：25.30 tok/s，整轮 279.41 秒，峰值显存 21,492 MiB

• 开 MTP3：53.15 tok/s，整轮 242.76 秒，峰值显存 24,422 MiB

生成速度翻倍（+110%），整轮省 36.6 秒，代价是多吃 2.9GB 显存。 猜中率高达 98.3%，质量还是 17/17。

有个反直觉的细节：开了 MTP 之后，“读输入”这一步反而慢了 11.7 秒（198.81 对 187.11 秒）。但因为生成那头快得多，整轮算下来还是净省 36 秒。

这 2.9GB 决定了 24GB 卡能开多大窗口。 192K 能开，还剩点余量；256K 也能装下（24,422 MiB），但只剩 154MiB——这种配置我不推荐，一点波动就崩。

还有一条：别把 MTP 往大调。 MTP3 是 82.93 tok/s，MTP5 掉到 78.46，MTP8 只剩 65.48。猜 3 个字容易全中，猜 8 个字很可能第 4 个就错——一错后面全作废，白猜。网上不少教程让你调大，我这台机器上 MTP3 就是最优解。

连续对话：第二轮几乎不用重读

这条对做 Agent 的人最重要。同样一份 250K 的历史：

模型第一次读完同样前缀第二轮在后面追加 1024 字把开头删掉再追加Q2_K_XL196.25 秒4.24 秒5.45 秒195.28 秒Q4_K_M（q4 KV）192.05 秒5.20 秒6.39 秒192.04 秒

只要历史的开头不动、只往后面加内容，第二轮几乎不花时间——190 多秒变 4–5 秒。

但看最后一列：一旦你为了控制长度把开头的旧对话删掉（很多 Agent 框架的默认做法），缓存立刻全部失效，要从头重读 190 多秒。

做 Agent 的注意：宁可让历史长一点，也别随便截断开头。 这一刀下去，190 多秒就白等了。

最后一条提醒：慢在“读”，不在“写”

25 万 token 光读进去就要 214 秒。但读完之后生成有 47.67 tok/s，一点不慢。长上下文的痛点就是开口前那段等待。 塞本书进去，泡杯茶回来它才开始答；但一旦开始答，速度是正常的。

除此之外我还测了一批周边问题——ubatch 调多大、要不要开并发、新出的 DFlash 2 值不值得换、跟 RTX 5090 差多少——结论都不需要你改配置，过程和数据单独写成了一篇：《想证明量化版更差，我测了四轮都没证成》。

第八章：五个坑，我替你踩了

前面七章讲的是“怎么做对”。这一章讲我做错过什么——五个坑，每个都真实浪费过我几小时。有两个特别隐蔽：模型看起来变笨了、结果是配置问题；服务看起来启动成功了、结果是坏的。

坑一：输出预算给小了，模型会“想对了但没答完”

这个我踩得最狠。测 250K 长文本时，我一开始把输出上限设成 2048 字。结果旧 Q8 和 Q6 两个版本，表面成绩 0/17，全错。

我以为是长文本把模型搞崩了。后来把输出上限调到 4096，同样的题、同样的模型，变成 17/17 全对。

翻日志才明白：它在思考过程里明明已经找对答案，只是还没来得及输出最终结论就被截断了。 从外面看就是“什么都没答对”。

所以：发现模型突然“变笨”，先检查是不是输出预算不够。 尤其带思考过程的模型，思考本身也占输出预算，很容易不知不觉被截断。同一件事的另一面是思考档位：这个模型默认 xhigh，想得最久、最容易吃光预算——6.4 节讲了怎么用 –reasoning-effort 调低或关掉，两个开关要一起检查。

坑二：换推理框架，配错了会让你误以为模型变笨

vLLM + W4A16 那套方案必须正确配置两样：chat template（对话模板）和 reasoning parser（思考内容解析器）。

配错时表现很迷惑：思考内容和最终答案会错位——你看到的可能是它的思考过程，最终答案没正常交付。看着像模型质量出问题，是配置问题。 换框架时先把这两项对齐，再评价模型好坏。

坑三：网上说好的方案，未必适合你的机器

我认真试了两个流传的“更优方案”：

LOW GGUF：一开始我判它出局，后来发现是我搞错了场景。

我最早测它：短测只快 3.4%，到 250K 长文反而更慢（生成 39.07 对 47.67），于是直接否决了。

但后来做对照测试时发现：同样的参数下，LOW 在短对话里比 Q8attn 快 12.8%，还少占 3.38GB。

所以准确的结论应该是：LOW 适合短对话，Q8attn 适合长文。 我之前那句“否决”下得太急——同一个模型在不同场景下的排名是会反过来的，这也是我强调“看跑分要连着任务一起看”的原因。

vLLM + W4A16：真快，250K 下 68.0 tok/s，比我的方案快 40%。但要占 45.5GB——我这卡还得留给别的服务，装不下。

这两个方案本身没问题，只是场景跟我不一样。 显卡专门伺候一个模型的，W4A16 就是最优解；一卡多用的，别想。

另外：llama.cpp 还有几个性能补丁在审查中，尚未合并，现在还不适合上生产。

坑四：你跑出来的数，和我这篇对不上，多半是任务不一样

同一个配置，我自己前后测过两轮，速度差了 10%（44.73 对 49.09 tok/s）。模型没变、语料没变，变的是任务本身——第二轮的输出格式更规整，MTP 猜得更准，速度就上去了。

所以你照着这篇装好之后，跑出来的数和我的对不上，别急着怀疑装错了。任何跑分数字，都得连着“测的是什么任务”一起看——我这篇写的是“在这次真实 250K 结构化任务中”的速度，不代表你干任何活都能到。两轮怎么对不上的、原始数据长什么样，在实测记录那篇里。

坑五：日志说“模型已加载”，不代表真的能用

这个坑是我在 16GB Mac 上撞到的，但谁都可能撞上。

我把窗口开到 64K 启动，日志一切正常：

plaintextsrv llama_server: model loaded srv llama_server: listening on http://127.0.0.1:8080

看起来完全成功了。 端口在监听，健康检查也能过。

但发第一个请求，立刻 HTTP 500：

plaintexterror: Insufficient Memory (kIOGPUCommandBufferCallbackErrorOutOfMemory) srv send_error: task id = 0, error: Compute error.

翻回启动日志才发现，**初始化阶段已经 OOM 了，**只是进程没有退出，继续往下走完了启动流程。

所以：装完别只看“model loaded”就以为成了，一定要发一个真实请求验证。 第六章 6.5 节那两条 curl 命令就是干这个用的——健康检查过了不算数，要看到模型真的回你话。

结论：一页纸带走

关于上手

• 从下载到聊上第一句，实测约 14 分钟（下载 12 分半是大头，编译才 1 分 40 秒）

• 硬盘留 40GB；国内一定要走 hf-mirror 镜像

关于能不能跑

• 12GB 就能跑，干短任务够用（Q2_K_XL，32K 占 10.92GB）。不用为这个模型专门买大卡

• 24GB 就开到 192K（Q4 + q4 KV + MTP3，22.6GB，59.52 tok/s）。硬开 256K 只剩 154MiB，别碰

• 32GB 就能开满 256K（30.3GB）。48GB 买的是余量和多服务共存，不是“非它不可”

• 8GB 及以下没有已验证的全 GPU 方案

• 显存不够别指望 offload：只挪出去几层，速度就从 73.6 掉到 24.4；挪到能省 10GB 时只剩 9 tok/s。换小模型或缩窗口，都比这个强

• Mac 16GB 条件苛刻才凑合：关思考、8K 窗口、清后台能到 4–6 tok/s 的打字机水平；我首测的 0.75 tok/s 是 swap 爆掉的异常值。别当主力

• Mac 看统一内存，24GB 是能干活的起步线（M4 mini 有外部实测 MTP 下 9.94 tok/s），32GB 起才从容；速度由内存带宽决定，开投机解码能再快 2 倍以上（见 6.9）

• 上面的数字都没算 KV Cache，留 20% 余量。照着模型文件大小买卡，必翻车

关于窗口

• 开大窗口主要增加显存；把内容填满，才会明显拖慢生成

• 铁证：同一个 256K 配置，空载 78.80 tok/s、满载 250K 只剩 47.70，但显存只差 8 MiB

• 显存够就放心开大窗口，平时聊短的一点不亏

关于配置

• KV Cache 压到 q4 很值：256K 下省 4GB 显存，速度只掉 4.1%。质量上我只测过长文检索题（q8/q4 都是满分，测不出差距），没测过它对数学、代码这类精度敏感任务的影响

• MTP3 让生成快一倍，多占 2.9GB——小显存卡开不起，这就是为什么要分档

• 新出的 DFlash 2 不用急着换：日常对话 MTP3 还快 9.4%；DFlash 只在“250K 已读入、还要生成上千 token”时划算，而且依赖未合并的 PR。但这是 N 卡的结论——M3 Ultra 上有人测出 DFlash2 反超 MTP（88 对 79），Mac 用户别照搬

• MTP 不是越大越好：我这台 4090 上 MTP3 最优，5090 上有人测出 MTP2 最优，官方推荐的 6 在两边都是差档

• 做 Agent 一定要利用“历史开头不变可复用”：190 多秒变 4–5 秒。截断开头，缓存全废

关于跑分怎么看

• 同一个配置，我在不同任务上测出过 44.73 和 49.09。看任何跑分，都得连着“测的什么任务”一起看

• 同一个模型在不同场景下排名会反过来：LOW 版短对话比 Q8attn 快 12.8%，长文却更慢

测试边界

• 每类只有 24 题、LongBench 只有 8 题，样本很小，只够看方向，不能做排行榜

• Q4 的 47/72 是不开 MTP 测的；开了 MTP3 只验过 250K 长文 17/17 和工具调用 10/10，没重跑 72 题

• Agent 工具测试 10/10 只能证明基础工具调用可用，不代表复杂 Agent 场景无差别

• 所有速度都是单张 4090 48G 单流实测，换个显卡数字会不一样

最后

换显卡、换模型，具体数字肯定不一样。但三笔账的道理是通用的：窗口占显存、内容占时间、压缩换空间。这三件事搞清楚，你调任何模型都不会瞎调。

模型地址👇

https://huggingface.co/utautako/Qwen3.8-27B-NVFP4-MTP-Q8attn-GGUF

附录：那四轮质量测试去哪了

正文只给了结论。四轮测试的完整过程——前两轮为什么全白测、哪两篇论文把方向纠正过来、第四轮的三个靶子怎么选的、每一轮的原始数据和边界——单独写成了一篇：

👉 《想证明量化版更差，我测了四轮都没证成》

如果你也想测自己的模型，看那篇能少走几段弯路。一句话预告：用常规题目测量化差距，只会得到一堆满分——要么换维度测思考 token，要么照着已知的暴露点打。