本地跑 Qwen 3.8 27B：17GB 说的是总内存，不是显存

传得最广的那个数字是 17GB，出处就是 Unsloth 自己的硬件表。但把表头读完，它说的比这个数字精确得多：单位是总内存，内存加显存，或者 Apple 芯片上的统一内存。这个区别决定了模型是跑在你的显卡上，还是有一半跑在主板上。

你的机器能跑什么，不能跑什么

24GB 能跑 Qwen 想让你跑的那档量化，16GB 只能跑妥协方案，再往下就别折腾了。 Qwen 把 Qwen3.8-27B 以 Apache 2.0 协议发在 Hugging Face 上，27B 稠密视觉语言模型，原生 262,144 token 上下文。它小到让问题从”该用哪个数据中心”变成了”我桌上这台装得下吗”。这和 GLM 5.2 那种 2-bit 都要 256GB Mac Studio 的局面完全不同。先看结论。

权重协议：              Apache 2.0，允许商用
参数量：                27B 稠密（llama.cpp 数出 27.32B）
原生上下文：            262,144 token（YaRN 可扩到 1M）
最小可用 GGUF：         9.01 GB（Unsloth UD-IQ2_XXS）
4-bit GGUF：            16.81-18.97 GB，看谁打包的
厂商内存指引：          2-bit 11-13 GB，4-bit 17-19 GB，指内存+显存总和
视觉能力：              需单独下 mmproj 文件，+0.63-0.93 GB，按发布方不同
M2 Pro 16GB 实测：      2-bit 生成 7.11 tok/s，提示处理 74.59 tok/s
同一台机器 4-bit：      提示处理慢 4 倍，生成直接失败
配置耗时：              约 20 分钟，大部分时间在下载

配好之后你能做的：离线跑一个够强的编程和 agent 模型，没有按 token 计费，也没有数据离开这台机器。你做不到的：追上托管服务的延迟、在消费级机器上跑满 256K 上下文，或者用上 Max 那一档——它根本没有开放权重。

老实说：24GB 显卡才是 Qwen 真正希望你用的那档量化的入门线，32GB 才谈得上宽裕。16GB 以下要问的已经不是选哪档量化，而是本地推理这条路对不对。

Qwen 3.8 27B 到底要多少显存？

11GB 到 19GB 的总内存，这句话的重点全在”总”字上。 Unsloth 的硬件表把单位写得很清楚：总内存，也就是内存加显存，或者 Apple 芯片上的统一内存。这是给整台机器的预算，不是显卡的规格要求。

指引比文件体积高出两三个 GB，是因为内存里装的不只有文件。你还要为 KV 缓存、计算缓冲区，以及操作系统本来就占着的那部分买单。

容易被读错的地方在这里：同一个 Unsloth 页面的正文写着 4-bit”能在大多数 17-19GB 显存的设备上跑，比如 RTX 5080、4090，或者 24GB 内存的 Mac”。而按 NVIDIA 官方对比页，RTX 5080 配的是 16GB GDDR7，5070 Ti 也是 16GB。4090 是 24GB，5090 是 32GB。所以在 5080 上，4-bit 走的是显卡加系统内存凑出来的总内存预算，正如表头写的那样，而不是 17GB 塞进显存。它照样能跑，只是有些层落在了 PCIe 总线的另一侧，生成速度也跟着落过去了。

如果只想记一条规则，用 Unsloth 那条：内存加显存至少要等于量化文件的大小，否则能跑，但会从磁盘换页，慢得很难受。

该下载哪个 GGUF 量化版本？

挑还能给你留出 2-3GB 余量的最大那个文件，而且比字节数，别比量化名。 名字不等于体积。三家给这个模型都发了叫 Q4_K_M 的文件，彼此差了 2.2GB，因为每家在同一个标签下选的逐张量精度都不一样。

在 16GB 显卡上，这个差值就是全部的决策依据。LM Studio 那版比 Unsloth 小 300MB，比 ggml-org 小 2.2GB，而这些从量化名上一点也看不出来。

按内存预算的实用选择：

• 32GB 以上：UD-Q4_K_XL 17.92 GB，或者 Q6_K 22.88 GB——如果你愿意把余量花在精度而不是上下文上。
• 24GB：lmstudio-community 的 Q4_K_M 16.81 GB，给 KV 缓存留的空间最多。
• 16GB：UD-Q3_K_XL 13.44 GB，装得下还有干活的余量。4-bit 那几个文件不卸载就装不下。
• 16GB 统一内存 Mac：UD-IQ2_XXS 9.01 GB。这是地板，而且你会明显感觉到。

Unsloth 的 UD 前缀表示他们的动态量化，会把敏感层保留在更高精度，而不是一刀切。在 2-bit 和 3-bit 这一端，这件事比标称位数更重要。

什么时候值得本地跑 Qwen 3.8 27B，什么时候不值得？

数据不能出门的时候，或者用量大到显卡能摊平成本的时候。 其余情况下托管服务更便宜，也快得多。

这些情况适合本地部署：

1. 你处理的代码或文档受合同约束，不允许走第三方推理。
2. 你已经有 24GB 或 32GB 的显卡，想让日常重构和代码审查不再按 token 付费。
3. 你需要离线可用——飞机上、隔离网络的实验室里，或者在你控制不了的网络后面。

这些情况别本地部署：

1. 你的显卡只有 12GB 或更少。装得下的量化档位好不到值得你折腾的程度。
2. 你想要这一家里最强的。Qwen3.8-Max 只有 API、没有开放权重，而 2.4T-A95B 那个兄弟型号 1-bit 都要 397GB。
3. 你要跑长时间的 agent 任务。按下文实测的真实场景 2.91 tok/s，托管模型四分钟做完的任务，你这里要跑将近一个小时。

停手规则： 如果你走完下面第 4 步，在你实际使用的上下文长度下生成速度还不到 5 tok/s，就别再调了。这台机器不适合托管这个模型，没有哪个参数能把它拉高一个数量级。

什么硬件跑得动 Qwen 3.8 27B？

24GB 显卡或 32GB Mac 是舒服的入门线，16GB 能跑但要妥协。 显卡型号没有总内存池和它的带宽重要。

软件这边，llama.cpp 比大家想的省事。config.json 里的架构字符串是 qwen3_5，而 llama.cpp 从 2026 年 2 月 PR #19435 合入稠密和 MoE 支持起就认这一族了。这里实测过：b10375 这个构建发布于 2026-08-12 12:18 UTC，比权重本身第二天 08:23 UTC 落到 Hugging Face 还早，加载运行毫无怨言。所以”升级 llama.cpp”很少是真正的解法，只要你的构建新到跑过任何 Qwen 3.5 或 3.6 模型，它就跑得动这个。macOS 上 brew install llama.cpp 就够新；Linux 和 Windows 拿发行版二进制或者自己编译。

有一个 Apple 芯片的细节，任何厂商的表里都没写。macOS 不会把整个内存池交给 GPU。在写这篇文章用的 16GB M2 Pro 上，llama.cpp 启动时直接把 Metal 上限打了出来：

ggml_metal_device_init: has unified memory    = true
ggml_metal_device_init: recommendedMaxWorkingSetSize  = 12713.12 MB

12.71GB，不是 16GB。这一行决定了任何一台 Mac 上哪些量化档位是候选项，值得在你下载 17GB 权重之前先读一眼。

怎么在 llama.cpp 里跑 Qwen 3.8 27B？

五步，慢的那步是下载。 下面每一步都在上面那台 M2 Pro 上跑过。

第 1 步：安装 llama.cpp

brew install llama.cpp
llama-cli --version

预期结果：一个构建版本号。我这里是 b10450-ece963f41。如上文所说，2026 年的构建基本都行。

第 2 步：挑一个量化档，拿它和你的上限比一比

curl -s "https://huggingface.co/api/models/unsloth/Qwen3.8-27B-GGUF/tree/main" \
  | python3 -c "import json,sys;[print(f\"{f['path']:32s}{f['size']/1e9:6.2f} GB\") for f in json.load(sys.stdin) if f['path'].endswith('.gguf')]"

预期结果：完整文件列表，带精确到字节的体积。拿它比你的总内存，不是比你的显卡。

第 3 步：下载权重

curl -L -o qwen38-27b.gguf \
  "https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/resolve/main/Qwen3.8-27B-UD-Q3_K_XL.gguf"

预期结果：一个文件，这个体积不分片。把文件名换成你在第 2 步挑好的那个。

第 4 步：跑起来

llama-server -m qwen38-27b.gguf -c 16384 \
  --temp 1.0 --top-p 0.95 --top-k 20 --port 8080

预期结果：localhost:8080 上一个 OpenAI 兼容端点。那几个采样值是 Qwen 为思考模式公布的设定。非思考模式用 --temp 0.7 --top-p 0.80 --top-k 20 --presence-penalty 1.5。

第 5 步：想要视觉能力就再加这一步

基础 GGUF 是纯文本的。单独加载它，llama.cpp 会明说，打印 modalities : text。视觉那一半在一个单独的投影器文件里：

curl -L -o mmproj.gguf \
  "https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/resolve/main/mmproj-F16.gguf"
llama-server -m qwen38-27b.gguf --mmproj mmproj.gguf -c 16384 --port 8080

预期结果：接受图片输入。给这个 F16 投影器留 0.93GB，加在权重之上，不在你原本规划的那个数字里面。如果你想要更小的 0.63GB Q8_0 投影器，三家发布方里只有 ggml-org 发它，所以那个文件要去和你的权重不同的仓库拿。

Qwen 3.8 27B 在 16GB Mac 上有多快？

2-bit 每秒 7.11 个 token，而 4-bit 文件根本生成不了。 用 llama-bench 在那台 M2 Pro 上测，llama.cpp b10450，两档量化同一台机器：

值得多看两眼的是 4-bit 那一行。文件加载成功。模型参数量报得也对。提示处理跑得起来，比 2-bit 慢四倍，因为权重已经装不进 12.71GB 的 Metal 工作集，机器在换页。然后生成阶段死在 failed to decode generation batch, res = -3。llama.cpp 的头文件里写明任何小于 -1 的返回值都是致命错误，区别于返回码 1——后者是批次过大时那个普通的”找不到 KV 槽位”。在这个硬件上，跌破厂商给的内存数字不会优雅降级，只会给你一份跑到一半的基准测试。

上面那些是零上下文下的合成数字。真实场景更差。同一个 2-bit 模型用 llama-server 以 -c 16384 提供服务，发一个 7,072 token 的提示，llama.cpp 自己的计时报告是这样：

prompt eval time = 208988.11 ms /  7072 tokens ( 33.84 tokens per second)
       eval time =  27129.34 ms /    80 tokens (  2.91 tokens per second)
      total time = 236117.45 ms /  7152 tokens

一轮四分钟，生成是 2.91 tok/s，而不是基准测试承诺的 7.11。提示处理随着上下文填满而变慢，llama.cpp 每个进度节点打印的累计均值，在第 2,090 个 token 时是 43.58 tok/s，到第 6,186 个 token 降到 37.82。任何在零上下文下报出的 tok/s 数字，包括上面那张表里的，都是你这辈子能看到的最好情况。

那个请求也顺带演示了思考模式的默认行为。它被限制在 80 个补全 token，回来的是一个片段而不是答案，因为 reasoning_effort 默认是 xhigh，推理在答案出现之前就把预算吃光了。这个特征很好验证：问一个需要几步推理的问题，把 max_tokens 卡在 80，响应回来会带 finish_reason: length、content 为空，80 个 token 全在 reasoning_content 里。换成问 84 * 3，同样的上限就没事，三轮分别只用了 29 到 51 个 token，因为短推理装得下。问题不在上限本身，而在上限撞上了一个模型想仔细想想的问题。在这么慢的机器上，日常活儿把 reasoning_effort 设成 low 或者直接关掉思考，并且给一个像样的 max_tokens。

加载日志里还有一个不起眼的细节：llama.cpp 打印 model has unused tensor blk.64.nextn.* 然后跳过它。那是多 token 预测头，Qwen 训它是为了加速推理，而这条 GGUF 路径不用它。ggml-org 把 MTP 权重作为单独文件发布。想要这份加速，你得自己去找。

2-bit 的质量代价很快就会露出来。让它写一个合并两个有序链表的函数，模型的思考轨迹里把方案写成了畸形的 Python：def __init__(self, val): self.val; self.next——这是两个什么也不做的表达式，不是赋值。思考轨迹本来就是草稿，最终答案很可能没问题，但这类失误会随着量化档位往上走而越来越少。这是”想办法凑到 24GB”比”把 16GB 用出来”更值的最强论据。

还有两个标签别被绕进去。llama.cpp 把架构报成 qwen35，因为 Qwen3.8-27B 建立在 Qwen3.5 架构上，config.json 里写的是 model_type: qwen3_5。它还把 Unsloth 的动态 2-bit 文件报成 ftype Q4_K - Small，那是个头部字段，不是实际的精度混合。信字节数。

为什么 27B 模型的 KV 缓存这么小？

因为 64 层里只有 16 层用完整注意力。 Qwen 在模型卡里公布了层结构：16 次重复，每次是三个 Gated DeltaNet 块接一个 Gated Attention 块。Gated DeltaNet 是线性注意力层，它的状态对每个序列是固定大小，不会随着对话变长而增长。只有那 16 层完整注意力才按 token 存缓存。

按 config.json 算，这些层用 4 个 KV 头、头维度 256。f16 下每层每 token 是 4KiB，16 层加起来每 token 64KiB：

一个同样头配置的常规 64 层模型，缓存要四倍，跑满上下文是 64GiB。正是这套混合结构，才让一个带 256K 窗口的 27B 模型成为桌面上可以谈的事。

它也给出了上下文这个问题的老实答案。权重原生支持 262,144 token，用 YaRN 能拉到一百万，但跑满原生上下文光缓存就要 16GiB。在那台 16GB 测试机上，llama-server 用 2-bit 量化以 -c 16384 启动并正常服务请求，8K 到 16K 是那里的实用区间。32GB 的机器可以在 4-bit 模型旁边从容地放下 32K。把 -c 设成你实际用得到的长度，需要更长就用 --cache-type-k q8_0 --cache-type-v q8_0 量化缓存，占用大约减半，质量代价很小。完整窗口留给托管服务——这和上下文窗口本身的道理是一样的。

本地部署常见报错与修法

这里的本地故障大多是内存问题换了一件报错的外衣。 下面每一行都在测试机上复现过，除了最后一行——那条来自 Qwen 自己的最佳实践说明。

一台本地 Qwen 3.8 27B 机器能给团队共用吗？

一台机器能服务一到两个开发者，服务不了一个团队。 llama-server 暴露的是 OpenAI 兼容端点，任何同事都能把客户端指过来，这部分确实简单：

llama-server -m qwen38-27b.gguf -c 16384 --host 0.0.0.0 --port 8080 --parallel 2

卡住的是算术。一块消费级显卡跑 4-bit 的 27B 只产出一条 token 流，而 --parallel 是把你的上下文预算分给各个槽位，不是把吞吐乘上去。两个开发者共用一块 4090 会互相感觉到。四个就得排队了。

想要共享本地端点的团队应该去看数据中心卡上的 vLLM 或 SGLang，那是另一个预算级别的另一个工程。那条路在 GLM 5.2 自建部署硬件与成本指南里写过，模型不同但容量测算的逻辑是通用的。4-bit 的 27B 大约只占一块 48GB 显卡三分之一的内存，剩下的空间足够放并发 KV 缓存，所以对团队来说买一块这样的卡，比买四块各自存一份权重的 4090 合理得多。

本地机器在任务中途顶不住了怎么办？

把客户端指向一个说同样协议的托管端点，接着干活。 每套本地部署都有同样两个缺口，而且不是 llama.cpp 的错。

第一个是容量。你的机器以内存带宽允许的速度跑一个模型，而当任务需要 2.4T 那个兄弟型号、需要 Max 那一档，或者仅仅是需要快一点的答案时，本地端点拿不出东西来。第二个是覆盖面。Qwen3.8-27B 有开放权重，Qwen3.8-Max 没有；模型卡指向 Qwen Cloud 上一个默认 1M 上下文的托管版 27B，标注为即将上线，而截至写稿时那个概览页链接仍然返回 404。这一家里有些型号，你花多少硬件预算都托管不了。

因为 llama-server 说的是 OpenAI Chat Completions 那套格式，托管网关也是，所以两边的修法一样：换掉 base_url 和密钥，代码不动。像 ofox.ai 这样的网关同时有 bailian/qwen3.8-max 和上一代的 bailian/qwen3.6-27b、bailian/qwen3.5-27b，同一个客户端可以从你的显卡回落到托管档位，不用再开第二个账号。开放权重的 27B 本身截至写稿时不在这个目录里；OpenRouter 上有两家供应商提供它，都给满 262,144 token 上下文：Chutes 每百万输入 0.40 美元、输出 3.00 美元，跑的是 fp8；AkashML 是 0.45 和 3.20 美元，跑的是 bf16。GGUF 那张表的道理在这里又演了一遍——便宜的那个端点是量化过的，价差就是精度差。

买硬件之前先算账。按这个价格，一个每月推 1,000 万输入 token 和 200 万输出 token 的开发者，花 10 到 11 美元，取决于请求落在哪家。4090 靠这笔账是回不了本的；买它的理由是隐私和离线可用，不是算术。

27B 到底值不值得跑？

跟自己的上一代比，明显值。 Qwen 公布的数字里，Qwen3.8-27B 在 Terminal Bench 2.1 上是 73.0，Qwen3.6 27B 是 63.4；SWE-bench Pro 上 61.7 对 53.5；他们自研的 QwenSWEBench 上 79.0 对 49.3。计算机操作方面，OSWorld-Verified 从 63.9 升到 84.3。这些是厂商自测数字，跑在 Claude Code harness 上，部分任务集做过修正，所以当方向看而不是当排行榜看。但同样参数量、只隔一代，这个方向确实很陡。想看 27B 这个尺寸级别对上前沿托管模型的独立评测，Qwen 3.6 27B 对比 Claude Opus 4.6 编程实测是我们手上最接近的基线。

对本地机器来说更要紧的比较，是跟你实际跑得起的那档量化比。24GB 显卡上的 4-bit 27B 接近 Qwen 拿去跑分的那个模型。16GB 笔记本上的 2-bit 27B 不是，而且这两者之间的差距比两代之间的差距还大。

多出来的内存买到了什么，有一个独立数据点。上一代发布时，Simon Willison 在本地跑了它，并在 2026-04-22 报了他自己的数字：“I tried it out with the 16.8GB Unsloth Qwen3.6-27B-GGUF:Q4_K_M quantized version”，记录到生成 25.57 tok/s，并称之为 “an outstanding result for a 16.8GB local model”。那是同一个尺寸级别、上一代、4-bit，在一台放得下它的机器上。而本文这台 16GB Mac 在 2-bit 下，合成基准 7.11 tok/s、真实提示 2.91 tok/s。慢三到九倍，量化还更差，为的是大约 8GB 的差距。买内存优先于买任何别的东西。

References

• Qwen/Qwen3.8-27B model card
• Qwen3.8-27B config.json
• Unsloth: Qwen3.8 how to run locally
• unsloth/Qwen3.8-27B-GGUF file listing
• ggml-org/Qwen3.8-27B-GGUF file listing
• lmstudio-community/Qwen3.8-27B-GGUF file listing
• NVIDIA GeForce graphics card comparison
• OpenRouter: qwen/qwen3.8-27b
• llama.cpp
• Simon Willison: Qwen3.6-27B