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

2026 年 8 月 27 日

本页内容

过去 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。下面的内存表列出了每种量化对应的数值。

那么 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 芯片上实际表现如何。

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

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

	qwen3.6:27b	qwen3.8:27b
生成速度（5 次运行平均）	28.6 tok/s	14.0 tok/s
提示词处理	95.0 tok/s	93.1 tok/s
逐次运行波动	28.5-28.8（极其稳定）	13.2-15.4
每个答案使用的 token 数	1,950-3,340	890-1,090

先说最核心的数字：新模型的生成速度是前代的一半。参数量相同、量化大小相同、机器相同。混合注意力架构是新的，而 Ollama 里的 Metal 内核显然还没跟上。我预计随着运行时逐渐成熟，这个差距会缩小；其他新架构也经历过同样的事情。

不过，它实际上并没有让我多花时间。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 芯片上推理是通过 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 下长任务的准确性会崩溃，而通用知识则得以保留。他们给出的工具调用最低要求是 Q2_K_XL 量化版，大小为 9.8GB。

根据我的经验：1-bit 量化版是一个能教会你真正一课的小把戏。量化并不会均匀地降低模型性能。事实性知识存活下来，决断力却死掉了。如果你的用例是“在低配设备上快速回答冷知识”，它确实管用。但如果是任何智能体类工作，多花 3GB 上 Q2 吧。

每种量化需要多少内存

Unsloth 发布了完整的 GGUF 阶梯表，这里给出实用版本。预算时请考虑文件大小，再加上几 GB 用于上下文和视觉投影器。

量化版本	文件大小	实际最低内存	可运行的设备
UD-IQ1_M（1-bit）	6.7GB	16GB	任何现代迷你主机
UD-Q2_K_XL	9.8GB	16GB	任何现代迷你主机
UD-Q4_K_XL / Q4_K_M	16-17.6GB	32GB	中端迷你主机
UD-Q6_K	22GB	32GB（紧张）/ 48GB	高内存配置
Q8_0	29GB	48-64GB	Strix Halo、Mac 统一内存
BF16	54.7GB	96GB+	128GB Strix Halo、Mac Studio

对于 32GB 这一档，像 GEEKOM A6（搭载 Ryzen 7 6800H 和 32GB 内存）或 GMKtec M6 Ultra（DDR5）这样的设备，运行 Q4 量化版的效果和我上面基准测试的结果一样，只是更慢：CPU 推理时每秒只有个位数的 token，而不是 14。这种速度适合像我这样的后台任务；在交互式聊天中，它会考验你的耐心。

如果你不想买 Apple 设备、又想以真实速度跑这个模型，社区共识的目标是 AMD 的 Strix Halo 平台。strix-halo-guide 项目在 Ryzen AI Max+ 395 上实测官方 Q4_K_M 达到 20.4 tok/s 生成速度和 292 tok/s 提示词处理速度，并有原始 CSV 数据作为支撑。GMKtec EVO-X2 64GB 版本是该平台的性价比入门选择，售价 1,999 美元；而 BOSGAME M5 等 128GB 配置则能解锁表格中的 Q8 和 BF16 档位，还能跑更大的模型。我在“本地 LLM 最佳迷你主机”一文中完整覆盖了这个平台的选择决策。

当前市场有一个提醒：内存价格仍然虚高。一套 64GB DDR5 SODIMM 内存条目前售价 750-870 美元。如果你要买迷你主机跑本地 LLM，直接买预装好内存的整机目前比日后自行升级更便宜——这和我二十多年买电脑积累下来的所有直觉完全相反。

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-供应商-内容”命名规范重命名。视觉能力让它能处理 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 构建版本内置了视觉投影器（约 4.6 亿参数），图像输入开箱即用。本地运行时对视频理解的支持仍然不太完善。

那 Qwen3.8-Flash-Next 呢？就在我写这篇文章的时候，它的权重已经发布了：一个 180B 的 MoE 模型，Q4 量化后大约 110GB。这完全是另一个级别的硬件需求：你需要 128GB 级别的统一内存，目前这意味着要一台 3500 美元以上的 Strix Halo 主机，或者一台大内存 Mac。如果“出奇地适合本地部署”的架构说法经得起验证，那这就是未来的一篇文章。

资源

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

测量愉快！📊

最后更新：2026 年 8 月