Qwen 3.8 27B 本地运行指南（2026）：总量 17 GB，而非 17 GB VRAM

Qwen3.8-27B 流传的数值是 17 GB，这个数字直接来自 Unsloth 自己的硬件表。仔细看表头会发现，它的表述比这个数字本身更精确：单位是总内存，即 RAM 加 VRAM，或者统一内存。这个区别决定了模型是跑在你的显卡上，还是部分跑在主板上。

本地能跑什么（不能跑什么）

有 24 GB 你可以跑 Qwen 原计划的量化版本；16 GB 是妥协版；低于这个就别折腾了。Qwen 在 Hugging Face 上以 Apache 2.0 协议发布了 Qwen3.8-27B，这是一款 27B 稠密视觉语言模型，原生上下文长度为 262,144 token。它足够小，问题的答案不再是"该选哪个数据中心"，而是"能不能塞进我桌上的机器"。这和 GLM 5.2 的情况完全不同——后者即便用 2-bit 量化也还需要 256 GB 的 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，总 RAM+VRAM
视觉能力：        单独的 mmproj 文件，各发布商加 0.63-0.93 GB
M2 Pro 16GB 实测：2-bit 生成 7.11 tok/s，提示词处理 74.59 tok/s
同设备 4-bit：   提示词慢 4 倍，生成直接失败
配置时间：        约 20 分钟，大部分在下载

完成配置后你能做的事：在本地跑一个强大的编程和 AI 智能体模型，没有按 token 计费，数据也不会离开你的机器。你做不到的事：匹配托管服务的延迟、在消费级设备上跑满 256K 上下文、或者用 Max 级别（它根本没有开放权重）。

实话实说：24 GB 显卡才是 Qwen 希望你用的量化版本的入门门槛，32 GB 才不算紧巴巴。低于 16 GB 的情况下，真正的问题不是选哪个量化版本，而是本地推理本身是不是正确的选择。

Qwen 3.8 27B 实际需要多少 VRAM？

总内存 11 GB 到 19 GB 之间，而"总"这个字在这句话里至关重要。Unsloth 的硬件表明确标注了单位：总内存，即 RAM 加 VRAM，或者 Apple 芯片上的统一内存。这是一个针对整台机器的预算，而不是针对显卡的规格。

实际建议比每个文件大小高出几 GB，因为内存里不止有文件本身。KV 缓存、计算缓冲区，以及你的操作系统已经在占用的内存都需要付费。

这里容易产生误解：同一个 Unsloth 页面说 4-bit"可以在大多数设备 17-19 GB VRAM 上运行，如 RTX 5080、4090 或 24 GB RAM 的 Mac"。根据 NVIDIA 自己的对比页面，RTX 5080 配备了 16 GB GDDR7，5070 Ti 也是。4090 有 24 GB，5090 有 32 GB。所以在 5080 上，4-bit 路径是一个由显卡加系统 RAM 共同满足的总内存预算——正如表格标题所示——而不是真的有 17 GB 待在 VRAM 里。它能跑，只是部分层落在了 PCIe 总线的错误一侧，生成速度也会跟着降下来。

如果你想要一条简单的规则，用 Unsloth 的说法：RAM 加 VRAM 应该至少达到量化文件的大小，否则能跑但会频繁换页到磁盘上，速度严重下降。

该下载哪个 GGUF 量化版本？

选那个让你留有 2-3 GB 余量的最大文件，而且要比对字节数而不是量化名称。名称不是大小。三家发布商为这个模型都发布了一个叫 Q4_K_M 的文件，它们之间相差 2.2 GB，因为每家在相同标签下选择了不同的逐张量精度。

在 16 GB 显卡上，这个差距就是整个决策的关键。LM Studio 的构建比 Unsloth 的少 300 MB，比 ggml-org 的少 2.2 GB，而这些从量化名称上都看不出来。

按内存预算的实际选择：

32 GB 及以上：UD-Q4_K_XL，17.92 GB；或者 Q6_K，22.88 GB，如果你想把余量花在精度而不是上下文上。

24 GB：lmstudio-community 的 Q4_K_M，16.81 GB，为 KV 缓存留出最多空间。

16 GB：UD-Q3_K_XL，13.44 GB，够用且有工作空间。4-bit 文件放不下，除非用卸载。

16 GB 统一内存 Mac：UD-IQ2_XXS，9.01 GB。这是下限，你会感受到它的局限。

Unsloth 的 UD 前缀表示他们的动态量化，把敏感层保持在更高精度而不是均匀量化。在 2-bit 和 3-bit 级别，这比标称比特数更重要。

什么时候本地运行 Qwen 3.8 27B 值得（什么时候不值得）？

当数据不能离开大楼，或者你的用量大到足以摊平 GPU 成本时。其他情况下，托管服务更便宜，速度也快得多。

本地运行的适用场景：

你在处理代码或文档，合同禁止第三方推理。

你已经有一张 24 GB 或 32 GB 的 GPU，想停止为日常的重构和审查按 token 付费。

你需要离线运行——在飞机上、在物理隔离的实验室里、或者在你无法控制的网络后面。

不要选择本地运行的场景：

你的显卡只有 12 GB 或更少。能放进去的量化版本不够好，不值得折腾。

你想用这个系列的顶级版本。Qwen3.8-Max 只提供 API，根本没有开放权重；2.4T-A95B 兄弟版在 1-bit 下需要 397 GB。

你在做长流程的 AI 智能体运行。以实测的 2.91 tok/s 来看，托管模型 4 分钟完成的任务在这里要跑将近一个小时。

停止规则：如果你完成下面的第 4 步后，在你实际使用的上下文长度下生成速度低于 5 tok/s，就别调了。那台机器不是这个模型的合适宿主，没有什么参数能把它改变一个数量级。

什么硬件能跑 Qwen 3.8 27B？

24 GB GPU 或 32 GB Mac 是舒适的入门门槛；16 GB 能用但有妥协。显卡本身不如总内存池及其带宽重要。

软件方面，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。在本文使用的 16 GB M2 Pro 上，llama.cpp 在启动时直接报告了 Metal 的限制：

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

12.71 GB，不是 16 GB。这一行决定了在任何 Mac 上哪些量化版本是候选，值得在下载 17 GB 权重之前先看一眼。

如何在 llama.cpp 中运行 Qwen 3.8 27B？

五个步骤，下载是最慢的环节。以下全部在上述 M2 Pro 上运行。

第一步：安装 llama.cpp

brew install llama.cpp
llama-cli --version

预期结果：一条构建字符串。我的版本是 b10450-ece963f41。如上所述，几乎任何 2026 年的构建都可以。

第二步：选一个量化版本并检查它是否符合你的上限

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')]"

预期结果：完整文件列表，包含精确字节数。对比你的总内存，而不是你的显卡。

第三步：下载权重

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

预期结果：一个文件，这个大小不需要分片。把文件名换成第二步里你选的量化版本。

第四步：启动服务器

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。

第五步：如果你想要视觉能力，加载它

基础 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.93 GB 预算。如果想要更小的 0.63 GB Q8_0 投影器，ggml-org 是三家发行方中唯一提供它的，所以这个文件来自与权重不同的仓库。

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

2-bit 下 7.11 tokens/秒，4-bit 文件根本无法生成。以上数据在 M2 Pro 上用 llama-bench 测量，llama.cpp b10450，两个量化版本在同一台机器上测试：

4-bit 这一行才是值得关注的。文件能加载，模型正确报告了参数量。提示词处理运行正常，但因为权重不再适应 12.71 GB 的 Metal 工作集，机器开始换页，速度比 2-bit 慢了四倍。然后生成中止，报错 failed to decode generation batch, res = -3。llama.cpp 的头文件将任何小于 -1 的返回值都标记为致命错误，与返回码 1 不同——返回码 1 是常规的"找不到 KV 槽位"，通常来自过大的批次。在这个硬件上低于厂商给出的内存数字并不会优雅降级，而是会让基准测试半途而废。

这些是零上下文下的合成数字。实际数字更差。通过 llama-server 以 -c 16384 提供同一个 2-bit 模型，发送一个 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 打印的运行平均值，在 token 2,090 时为 43.58 tok/s，到 token 6,186 时降至 37.82。任何在零上下文下引用的 tokens-per-second 数字，包括上表中的那些，都是你所能看到的最佳情况。

这个请求也展示了 thinking 的默认行为。它被限制在 80 个 completion token，结果返回了一个片段而非完整答案，因为 reasoning_effort 默认为 xhigh，推理消耗完预算时答案还不存在。验证这个特征很简单：问一个需要几步推理的问题，将 max_tokens 限制在 80，响应会以 finish_reason: length 到达，内容为空，80 个 token 全部在 reasoning_content 里。换一个问题问 84 × 3，相同的限制就没问题，三次运行中跨 29 到 51 token，因为短推理可以装下。问题不在于限制本身，而在于限制遇上了一个模型想要深入思考的问题。在这么慢的机器上，日常任务把 reasoning_effort 设为 low 或关闭 thinking，给它一个真正的 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，这是两个空操作表达式而非赋值。思维追踪是草稿，最终答案很可能没问题，但这种失误会随着量化级别上升而减少。这是为 27B 寻找 24 GB 而非在 16 GB 上凑合的最有力论据。

两个值得理清的标签。llama.cpp 报告架构为 qwen35，因为 Qwen3.8-27B 建立在 Qwen3.5 架构之上，config.json 声明了 model_type: qwen3_5。它还报告 Unsloth 的动态 2-bit 文件为 ftype Q4_K - Small，这是头文件中的一个字段，不是实际混合方案。相信字节数。

为什么 27B 模型只需要这么少的 KV Cache？

因为 64 层中只有 16 层使用完整注意力。Qwen 在模型卡中公布了层拓扑：16 个重复的 Gated DeltaNet 块，每个块后接一个 Gated Attention 块。Gated DeltaNet 是一个线性注意力层，其状态大小相对于序列是固定的，不会随对话增长。只有 16 个全注意力层保留每个 token 的缓存。

根据 config.json 计算，这些层使用 4 个 KV 头，头维度为 256。在 f16 下，这是每 token 每层 4 KiB，跨 16 层合计每 token 64 KiB：

一个使用相同头配置的常规 64 层模型需要四倍的缓存，在完整上下文下需要 64 GiB。这种混合布局是 27B 模型搭配 256K 窗口能够运行在桌面级硬件上的原因。

这也给出了关于上下文的诚实答案。权重原生支持 262,144 个 token，用 YaRN 可以扩展到一百万，但仅完整原生上下文本身就消耗 16 GiB 缓存。在 16 GB 测试机上，llama-server 用 2-bit 量化启动了 2-bit 模型并提供了服务，-c 16384 可以正常运行，8K 到 16K 是那里的实际可用区间。在 32 GB 上你可以舒适地持有 32K 上下文，同时加载一个 4-bit 模型。把 -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

限制来自算术。一块消费级 GPU 以 4-bit 运行 27B 模型产生一个 token 流，--parallel 在各个槽位之间分配你的上下文预算，而不是倍增吞吐量。两个开发者在 4090 上会注意到彼此的存在。四个人就得排队了。

想要共享本地端点的团队应该去看数据中心显卡上的 vLLM 或 SGLang，那是另一个项目，预算完全不同。那条路在 GLM 5.2 自托管 vLLM 硬件和成本指南中有详细说明；虽然模型不同但规模逻辑可以照搬。27B 以 4-bit 运行大约需要 48 GB 显卡三分之一的空间，这就为并发 KV cache 留下了真正的余量，所以一块这样的显卡对团队来说比四张各持有一份私有权重的 4090 更合理。

本地机器在任务中途耗尽怎么办？

把客户端指向一个使用相同协议的托管端点，继续工作。每个本地设置都有相同的两个缺口，而且这不是 llama.cpp 的错。

第一个是容量。你的机器以内存带宽允许的速度运行一个模型，当任务需要 2.4T 兄弟模型、Max 级别、或者 simply 一个更快的答案时，本地端点无能为力。第二个是覆盖范围。Qwen3.8-27B 有开放权重；Qwen3.8-Max 没有，模型卡指向一个 Qwen Cloud 托管的 27B，默认上下文 1M，据描述即将推出，但关联的概述页面在撰写本文时仍返回 404。这个模型家族有些是你在任何硬件预算下都无法托管的。

因为 llama-server 使用 OpenAI Chat Completions 格式，托管网关也一样，修复方案在两端相同：改 base_url 和 key，代码不动。像 ofox.ai 这样的网关提供 bailian/qwen3.8-max 以及上一代的 bailian/qwen3.6-27b 和 bailian/qwen3.5-27b，所以同一个客户端可以从你的 GPU 回退到托管层而无需第二个账户。开放权重 27B 目前不在那个目录中；在 OpenRouter 上有两家提供商提供它，都是完整的 262,144-token 上下文：Chutes 以 $0.40/百万输入 token 和 $3.00/百万输出 token 提供 fp8 服务，AkashML 以 $0.45 和 $3.20 提供 bf16 服务。和 GGUF 表格相同的经验又上升了一层。更便宜的端点就是量化过的，价格差异就是精度差异。

买硬件之前先算账。按这个价格，一个开发者每月输入 1000 万、输出 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 测试框架、已对部分任务集应用修正后跑出的数字，所以应将其视为一个方向而非排行榜，但同一参数规模下仅一代之隔的方向变化是陡峭的。若要获得一个独立的参照，看看 27B 这个规模级与前沿托管模型的差距，Qwen 3.6 27B 与 Claude Opus 4.6 的编码对比是最接近的基准。

对于本地机器来说，更有意义的比较是你实际能跑得起的量化版本。24 GB 显存的卡上跑 4-bit 27B 接近 Qwen 基准测试时的模型。16 GB 笔记本上跑 2-bit 27B 则不是，两者之间的差距比代际之间的差距更大。

有一个独立的数据点可以说明额外内存带来了什么。上一代发布时，Simon Willison 在本地运行并于 2026-04-22 报告了他自己的数字："我试用了 16.8GB 的 Unsloth Qwen3.6-27B-GGUF:Q4_K_M 量化版本"，记录生成速度为每秒 25.57 个 token，并称其为"16.8GB 本地模型的一个出色结果"。那是一代之前、同等规模、4-bit、在有足够空间的机器上跑的结果。本文中的 16 GB Mac 在 2-bit 下合成基准测试得到 7.11 tok/s，真正提示词得到 2.91 tok/s。慢了 3 到 9 倍，用的还是更差的量化，代价是大约 8 GB 的内存。先买内存，其他都可以往后排。

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

Simon Willison: Qwen3.6-27B

常见问题

我能在 16 GB 显卡上运行 Qwen 3.8 27B 吗？

4-bit 不行，而且无法完全放在 GPU 上。4-bit GGUF 根据打包方不同为 16.8-19.0 GB，这已经超过 16 GB 显卡的容量了，还不算 KV 缓存。在 16 GB 显卡上你要么降到 3-bit 量化（12.6-13.8 GB），要么保持 4-bit 让 llama.cpp 将溢出的层卸载到系统内存——可以工作，但生成速度会落到 DDR 带宽上。

Qwen 3.8 27B 在本地运行时有视觉多模态能力吗？

只有单独下载 projector 文件才有。基础 GGUF 仅含文本；llama.cpp 单独加载时报告 'modalities: text'。视觉需要伴随 --mmproj 传入的配套 mmproj 文件，它位于权重预算之上而非之内。Unsloth 和 lmstudio-community 发行的版本为 0.93 GB；只有 ggml-org 发布了 0.63 GB 的 Q8_0 projector，所以你可能需要从不同于权重的另一个仓库拉取。

Unsloth、ggml-org 和 LM Studio 的 Q4_K_M 文件有什么区别？

大小差异可达 2.2 GB。同样的 Q4_K_M 名称，lmstudio-community 出品为 16.81 GB，Unsloth 为 17.11 GB，ggml-org 为 18.97 GB，因为每个发布者在相同名称下选择了不同的每张量精度。在内存受限的机器上，这个差异决定了模型是否能装下，所以比较 Hugging Face 文件列表中的字节数，而不是信任量化名称。

Qwen 3.8 27B 在本地机器上支持完整的 256K 上下文吗？

权重支持，你的内存通常不支持。KV 缓存每个 token 在 f16 下大约需要 64 KiB，所以完整的 262,144-token 上下文需要在权重之上额外约 16 GiB。在 64 GB 或更大的机器上没问题，在 16 GB 上不可能。将 -c 设置为你实际使用的大小，通常是 8K 到 32K，如果需要更多就量化缓存。

Qwen 3.8 27B 在苹果硅上每秒生成多少 token？

在配备 16 GB 统一内存的 M2 Pro 上，使用 llama.cpp b10450 运行 2-bit Unsloth 量化版本，合成基准测试在零上下文下得到 7.11 tok/s 的生成速度和 74.59 tok/s 的提示词处理速度。一个包含 7,072-token 提示词的真实请求实测生成速度为 2.91 tok/s，提示词处理为 33.84 tok/s，单轮耗时四分钟。引用第二组数字，而非第一组。

Qwen 3.8 27B 是开源的吗？

是的，权重在 Hugging Face 上以 Apache 2.0 发布，允许商业使用。这特指 Qwen3.8-27B。Qwen3.8-Max 仅有 API，Qwen Cloud 列出的 1M 默认上下文的托管 27B 即将上线，所以开源权重路线和托管路线不是同一个产品。

为什么 llama.cpp 报告 Qwen 3.8 模型的架构为 qwen35？

因为 Qwen3.8-27B 构建于 Qwen3.5 架构之上，配置声明了 model_type qwen3_5。产品名称中的版本号移动了，但层级拓扑没有动。你的下载没有问题。

我应该在本地运行 27B 还是通过 API 调用 Qwen 3.8？

本地在隐私、离线使用和固定硬件成本上胜出。API 在速度上胜出，而且在 2.4T 和 Max 层级上你根本无法托管。Qwen3.8-27B 在 OpenRouter 上运行，每百万输入 token 0.40 到 0.45 美元，每百万输出 token 3.00 到 3.20 美元，跨两个提供商，所以轻度用户需要很长时间才能与购买 GPU 达到盈亏平衡点。

Originally published on ofox.ai/blog.