在本地运行 Qwen3.8 27B：来自我的 Mac Studio 的实际数据

在本地运行 Qwen3.8 27B：来自我 Mac Studio 的真实数据

过去 10 天里，Qwen3.8 27B 一直静静地在我 Mac Studio 上作为后台助手运行。它把我的 RSS 订阅源汇总成一份晨间摘要，把我扫描的 PDF 重命名并归档成可搜索的形式，还能处理我随手丢给它的任何汇总杂活。都是些琐碎的事。而这正是它的吸引力所在：这是我第一个信任到足以让它独自处理琐碎事务的本地模型。

然后上周，这个模型突然在 r/LocalLLaMA 上到处都是，我的信息流里塞满了基准测试图表，我这才意识到，我一直握着的正是那些帖子大多缺失的东西：一台能真正把它跑起来的机器，以及测量它的时间。

于是我给它做了基准测试。每个模型五次计时运行，相同的提示词，相同的机器，外加一个让我两次惊讶的 1-bit 实验。以下是我测量到的全部内容，以及它对你自行运行这个东西所需的硬件意味着什么。

太长不看

• Qwen3.8 27B（Q4_K_M，17GB）在我的 Mac Studio M3 Ultra 上通过 Ollama 生成速度约为 ~14 tokens/s。它的前代 qwen3.6:27b 在同一台机器上的速度约为 ~28.6 tokens/s。
• 它回答同样的提示词所用的 token 数大约只有三分之一，因此每个完整答案的实际耗时几乎打平。
• 1-bit 量化版本（6.7GB）在 llama.cpp 中以 27 tokens/s 的速度运行，事实性回答正确，但无法给出确定的答案。
• 你需要最近几周的 llama.cpp。更早的构建版本会以 unknown model architecture: 'qwen35' 报错失败。我自己就遇到了这个问题。
• 32GB 内存可以轻松运行 Q4。16GB 可以运行 Q2。下方的 RAM 对照表列出了每种量化版本的具体数字。

那么 Qwen3.8 27B 到底是什么？

Qwen3.8-27B 是一个 27.3B 参数的稠密模型，采用混合注意力设计（GGUF 中的架构标签为 qwen35，这一点后面很重要）。它是多模态的，内置图像和视频理解能力，拥有 262,144 token 的原生上下文窗口，并以 Apache 2.0 许可发布。官方模型卡声称在 SWE-bench Pro 上达到 61.7，在 GPQA Diamond 上达到 89.2——这些数字在一年前属于前沿实验室的水平。

社区的反应直接跳过了那张基准测试表。真正引爆讨论的是人们在这款模型发布第一周用它做了什么：一个团队将其接入他们的编程流水线，作为付费 API 模型的直接替代品，并反馈说表现经得起考验；OCR 测试者声称其质量超过某些商业云服务层级。最热门帖子中让我印象深刻的一句话是：“这是第一个让人感觉不只是一个玩具的本地模型。”

我的贡献是那些图表大多缺失的一项测量：这款模型在你能买到的 Apple silicon 上实际表现如何。

我的数据：同一台机器上 3.8 对 3.6

我的日常用机是一台 Mac Studio M3 Ultra，配备 256GB 统一内存，就是我在DeepSeek V4 Flash 指南里用的同一台机器。我通过 ollama run --verbose 对每个模型各跑了五次计时生成，提示词为多样化的技术类问题，回答约 200-500 词，然后对统计数据取平均。两个模型都是 Ollama 默认的 Q4_K_M 量化版本，磁盘占用都几乎正好是 17GB。

先说标题数字：新模型的生成速度只有前代的一半。相同的参数量、相同的量化尺寸、相同的机器。混合注意力架构是新的，而 Ollama 中的 Metal kernel 显然还没跟上。我预计随着运行时逐渐成熟，这一差距会缩小；其他新颖架构也经历过同样的情况。

不过它实际上并没有浪费我的时间。Qwen3.8 用大约 1,000 个 token 就回答了相同的提示词，而 3.6 则啰嗦地用了 2,000-3,300 个。算一下：2,058 个 token 按 28.6 tok/s 是 72 秒，955 个 token 按 14.2 tok/s 是 67 秒。每个 token 更慢，但每个回答更快。

在它生成时，CPU 几乎毫无察觉，因为在 Apple silicon 上推理通过 Metal 在 GPU 上运行。这篇文章的封面图正是那一刻，用 macmon 在生成过程中捕获：GPU 满载 100%，功耗 63.95W，CPU 仅消耗 6W，回答全程持续流式输出。

Stats 菜单栏应用从 GUI 一侧讲述了同样的故事：全部 60 个 GPU 核心 100% 运行，系统功耗达到 291W：

1-bit 实验：脑损伤，实测

本周得票最高的 Qwen3.8 帖子庆祝了 Unsloth 的 1-bit 量化，一个 6.7GB 的文件，发帖人亲切地称之为“脑损伤量化”。一个 27B 模型装进了 7B 的内存占用。我必须试一试。

它跑起来了，而且很快：

提示词处理 309 tok/s，生成 27.2 tok/s。速度几乎是我 Q4 的两倍，而内存占用不到 8GB。

然后我问了它一些问题。事实性回忆确实不错：它知道堪培拉是澳大利亚的首都，并正确地解释了背后悉尼与墨尔本的妥协。但当我让它写一个简单的 bash 单行命令时，它给出了一个可用的命令，然后却不停地自我怀疑，烧掉了 400 个 token 在多个备选方案之间来回打转，始终没有敲定最终答案。

这与 Unsloth 自己的说法一致：他们的量化文档直言不讳地指出，1-bit 不应用于智能体或工具调用类工作，而他们的发散测试显示，在 1-bit 下长任务的准确率会崩塌，而通用知识则能存活下来。他们给出的工具调用最低要求是 9.8GB 的 Q2_K_XL 量化版本。

从我的经验来看：1-bit 量化是个花架子，但教会了一个真实的道理。量化对模型的损害并不均匀。事实存活下来，决断力却死掉了。如果你的用例是"在土豆机上快速回答冷知识"，它确实能用。但如果涉及任何智能体类的工作，还是多花 3GB 上 Q2 吧。

每种量化需要多少 RAM

Unsloth 发布了完整的 GGUF 阶梯，所以这里是实用版本。预算按文件大小加上几 GB 用于上下文和视觉投影器。

对于 32GB 这一档，像 搭载 Ryzen 7 6800H 和 32GB 内存的 GEEKOM A6，或者 采用 DDR5 的 GMKtec M6 Ultra 这样的机器，运行 Q4 量化版本的方式与我上面的基准测试相同，只是更慢：CPU 推理时大约只有个位数 tokens 每秒，而不是 14。这个速度适合像我这样的后台任务；但放在交互式聊天里，会考验你的耐心。

如果你想在不买 Apple 的情况下让模型以真正的速度运行，社区公认的目标平台是 AMD 的 Strix Halo。strix-halo-guide 项目在 Ryzen AI Max+ 395 上测得官方 Q4_K_M 的生成速度为 20.4 tok/s，提示词处理速度为 292 tok/s，并有原始 CSV 数据作为支撑。配备 64GB 的 GMKtec EVO-X2 是该平台的高性价比入门选择，售价 $1,999，而像 BOSGAME M5 这样的 128GB 配置则解锁了表格中的 Q8 和 BF16 行，还能运行大得多的模型。我在 最适合本地 LLM 的迷你主机 中详细讨论了整个平台的选择。

当前市场有一个警告：RAM 价格仍然虚高。一套 64GB DDR5 SODIMM 套装目前售价 750-870 美元。如果你要买一台迷你主机来做本地 LLM 工作，目前直接买已经装好 RAM 的整机比之后自己升级更便宜，这和我二十年来买电脑积累的每一个直觉都完全相反。

GPU 用户的扩展方式则不同：社区报告显示，双 RTX 3090 配置大约能跑到 60 tok/s，而 RTX 5090 根据运行时的不同能跑到 75-140 tok/s，16GB 显卡则运行 IQ4 量化版本并配合量化 KV cache。

如何运行它（以及那个让我花了 20 分钟的坑）

Ollama 是最短的路径。模型页面是 ollama.com/library/qwen3.8：

# pulls the default Q4_K_M, 17GB
ollama pull qwen3.8:27b

# --verbose prints the tokens/s stats you've seen in my screenshots
# --think=false skips the reasoning preamble for quick answers
ollama run qwen3.8:27b --verbose --think=false "your prompt"

用 --verbose 运行它，每个回答末尾都会附带一个像这样的统计信息块：

你需要 Ollama 0.32.12 或更新版本；模型元数据将其声明为最低要求。

对于 llama.cpp，坑在这里。我的 Homebrew 版 llama.cpp 已经装了好几周，它直接拒绝加载这个文件：

llama_model_load: error loading model: unknown model architecture: 'qwen35'

这种混合架构需要最新的内核。brew update && brew upgrade llama.cpp 解决了这个问题，同样的版本要求也适用于任何基于 llama.cpp 的前端（LM Studio、Jan、koboldcpp）：如果 Qwen3.8 加载失败，先更新运行时，再去排查其他任何东西。

# grab a quant from the Unsloth GGUF repo, then:
llama-bench -m Qwen3.8-27B-UD-IQ1_M.gguf     # speed check
llama-cli -m Qwen3.8-27B-UD-IQ1_M.gguf -p "your prompt" -st

它实际上整天都在为我做什么

对我来说，基准测试的数字不如这个模型自从我拉取它以来一直在做的事情重要：那些不起眼的后台工作，过去要么根本不会发生，要么就泄露到云端 API 上。

晨间信息流摘要：一个 launchd 任务在夜间收集我未读的 RSS 条目，让 qwen3.8 把它们压缩成一份摘要，我边喝咖啡边读。262k 的上下文窗口意味着一周的订阅源能塞进单个提示词里。

扫描件归档：纸质邮件被扫描后，模型读取每个 PDF 的文本，并按我的 YYYY-MM-vendor-what-it-is 命名规范重命名。视觉能力意味着它能处理那些被 OCR 搞得一团糟的扫描件。

当某个论坛帖子累积到 400 条评论时，它会被粘贴进去并生成摘要，且标注各方立场归属。这篇文章的研究就催生了几份这样的摘要，感觉有种愉快的循环感。

这一切都不在乎每秒多少 token。要求是一个足够聪明、不会把保险信函归档成外卖菜单的模型，我自己已经拥有的硬件，以及什么都不离开这栋房子。这才是 2026 年本地模型的真正卖点，也是我在 自托管革命中提出的同一个论点：即便是那些小小的云端依赖也值得替换掉。

常见问题

我能在 16GB 内存上运行 Qwen3.8 27B 吗？可以，用 1-bit 或 2-bit 量化（6.7-9.8GB 文件）。2-bit 是 Unsloth 认为可用于工具调用的最小量化。Q4 质量需要 32GB。

它比 Gemma 4 更好吗？ 形态不同。Gemma 4 的 26B-A4B 是稀疏 MoE，在相同硬件上生成速度快得多（我的 Gemma 4 指南里有那些数字）。Qwen3.8 27B 是稠密模型，每个 token 更慢，而社区目前认为它在编程和智能体任务上明显领先。作为后台助手我会选 Qwen3.8；在中等硬件上做交互式聊天，Gemma 4 仍然合理。

为什么在我的机器上它也比 qwen3.6 慢？ 混合注意力架构是新的，运行时内核（Ollama Metal、llama.cpp Vulkan/CUDA）还没有针对它充分优化。预计随着更新差距会缩小。部分安慰是：它每次回答使用的 token 少得多，所以完成回答的延迟比 tok/s 差距所显示的更接近。

视觉在本地能用吗？ 能。Ollama 构建版自带视觉投影器（约 460M 参数），图像输入开箱即用。本地运行时的视频理解支持仍然不完善。

那 Qwen3.8-Flash-Next 呢？ 它在我写这篇文章时发布了权重：一个 180B MoE，Q4 下大约 110GB。完全是另一个硬件级别：你需要 128GB 级别的统一内存，如今这意味着 3,500 美元以上的 Strix Halo 机器或一台大 Mac。如果其“出人意料地本地友好”的架构说法站得住脚，那会是以后的一篇文章。

资源

• Unsloth GGUF 量化：从 6.2GB 到 54.7GB 的各种大小（模型卡和 strix-halo-guide 已在上文它们应得的位置链接）
• Unsloth 量化文档：为什么 1-bit 会破坏工具调用
• 开启我这一周的 r/LocalLLaMA 帖子：社区的第一手实测报告
• 相关内容：最适合本地 LLM 的迷你主机 · 在家运行 DeepSeek V4 Flash · 无需 GPU 运行 Gemma 4

祝测量愉快！📊