8 月 14 日晚上 11 点，千问团队正式开源 Qwen3.8-27B，这一周 Mac 圈基本被各种实测刷屏微博。官方给它的定位很明确：27B 参数、原生多模态，262K 原生上下文，用 YaRN 还能扩展到 1M哔哩哔哩。我把 B站、知乎、微博上这一周的实测收了一圈，交叉对比 6 组数据之后，发现两件反直觉的事，准备下载模型之前建议先看完。
更大的模型反而更快？同一台 Mac，35B 跑出 80 tok/s，27B 只有 54
先看一组扎心的对比。在 M4 Max 实测视频的评论区，一位 M2 Max 96GB 用户晒出了自己的成绩单：Qwen3.8-27B-MLX 只跑出 54.0 tok/s，而尺寸更大的 Qwen3.6-35B-A3B（q6k 量化）反而跑出 80.4 tok/s哔哩哔哩。模型更大反而更快，第一眼像 bug，其实是稠密和 MoE 两种架构的区别。Qwen3.8-27B 是稠密（Dense）模型，官方介绍里写得很明白微博。稠密模型每生成一个 token，都要把全部 27B 参数的权重从内存完整读一遍，一点都省不了；而 Qwen3.6-35B-A3B 是 MoE，35B 只是总参数，每个 token 只激活其中一小部分。DeepSeek-V4-Flash 更极端：86 个专家，每个 token 只激活 2 个知乎。
解码速度大致等于「内存带宽 ÷ 每个 token 要读的字节数」。稠密模型每 token 读全部权重，MoE 只读被激活的专家，这就是 Mac 统一内存「偏心」MoE 的根本原因：容量再大，带宽就那么多。M3 Ultra 统一内存带宽约 800GB/s，而 RTX 5090 是 1792GB/s 级别，Mac 想跑快稠密大模型，天然吃亏。
同一只 27B，从 5 tok/s 到 63 tok/s：机器决定一切
同一只模型在不同机器上的差距，比想象中更夸张。最扎眼的是两个极端：Mac mini M4 32G 上，独立开发者 Easy 实测 Qwen3.8 27b 的 MLX 4bit 版本只有 5～6 tok/s，让模型写个计算器，思考了 51 分钟微博。另一头，M3 Ultra 512G 跑 Q4 版 27B，两次独立实测都稳定在 30 tok/s 上下哔哩哔哩哔哩哔哩。其中纯跑分那次还发现 FP8 反而只有 20 左右，而换到 RTX 5090 能稳定 60、最高冲到 100+。
接 OpenCode 跑 Agent 编程的复测里，单请求稳定在 30～35 Token/s，两个并发时整体约 63 Token/s哔哩哔哩。
机型 | 模型与量化 | 解码速度 |
|---|---|---|
Mac mini M4 32G | Qwen3.8-27B MLX 4bit | 5～6 tok/s |
M2 Max 96G | Qwen3.8-27B MLX | 54.0 tok/s |
M2 Max 96G | Qwen3.6-35B-A3B q6k | 80.4 tok/s |
M4 Max 128G | Qwen3.8-27B NVFP4 + MTP | 63.1 tok/s，16K 内约 42 |
M3 Ultra 512G | Qwen3.8-27B Q4 | 30+ tok/s，FP8 约 20 |
M3 Ultra 512G | DeepSeek-V4-Flash 2.4bit | 27.9 tok/s @1K，20.8 @约 200K |
注意表格最后一行：284B 的 DeepSeek-V4-Flash 在 M3 Ultra 上 1K 上下文的生成速度和 27B 稠密模型几乎打平——下一节细说。
284B 的「怪兽」，反而是 Mac 上最从容的
DeepSeek-V4-Flash 总参数 284B，每 token 只激活 13B，支持 1M 长度上下文知乎。按「参数即正义」的直觉，这种模型跟个人设备完全无缘；但 M3 Ultra 512G 实测，1K 上下文生成 27.9 tok/s，接近 200K 上下文还能保持 20.8 tok/s，模型实际内存占用约 79GB哔哩哔哩。为什么 284B 反而跑得从容？因为 MoE 每 token 只读 13B 激活参数，内存压力接近一个 13B 稠密模型，却装着 284B 的知识容量。作为对照：RTX 4090 的 24G 显存想跑它，得靠把专家权重放在系统内存里、按需钉页拷贝的开源调度器，才做到 10.1 t/s知乎。显卡路线要靠黑科技绕显存，而 Mac 的大统一内存天然装得下。斌叔的判断很直白：Apple Silicon 是为 MoE 模型设计的，巨大的统一内存、适中的带宽；稠密模型则相反，受带宽限制微博。
按内存档位选模型，别硬上
16～24G：4～8B 小模型加 Q4/NVFP4 量化是现实选择。NVFP4 相比常见的 q4_K_M，困惑度测试显示质量损失大约减少一半知乎。
32G：Q4 的 27B 能装下，但要有个位数速度的心理预期，51 分钟的计算器就是前车之鉴。
48～64G：性价比甜点位。已经有知乎作者给出 48GB 统一内存的完整部署方案：MLX 跑 4-bit 量化的 27B 生成服务，独立 FastAPI 服务提供 Embedding 和 Rerank知乎。
比慢更该警惕的，是长上下文断崖
M4 Max 128G 的深度扫描数据值得反复看：解码在 4K～16K 稳定在 42 tok/s 上下，31K 直接断崖掉到 11.3 tok/s哔哩哔哩。上下文越长越慢不奇怪，但断崖式下跌背后是 Qwen3.8-27B 的混合注意力结构：层类型按「3 层 linear attention + 1 层 full attention」重复，64 层里只有 16 层是 full attention，传统 KV Cache 估算公式不能直接套用知乎。也就是说，标称 262K 上下文不等于你的内存真能撑住 262K，长文本场景务必先小步实测再上量。
本周噪音避一个：「2GB 内存跑 26B」
「2GB 内存跑 Gemma 4 26B」的说法这周传得很广，但有人较真实测：完整文本模型安装是 37 个文件、14,291,915,755 bytes，约 14.3 GB哔哩哔哩。所谓 2GB，指的是特定配置下进程的物理内存占用，不是模型大小，更不是最低配置门槛。以后看到「小内存跑大模型」的标题，先分清说的是权重体积、进程 footprint，还是营销口径。
值得继续盯的三个信号
第一，投机解码正在成为 Mac 提速的主战场。斌叔发起的优化挑战，不到 16 小时就有人把成绩做到比基线提升 +153%，比开箱即用的 MTP 解码快 2.5 倍微博。
第二，数据中心的推理优化正在低成本下沉到个人电脑：mlx-dspark 把 DeepSeek DSpark 的投机解码路线，用 Apple MLX 重写到了 Apple Silicon 上知乎。
提速是有条件的：M4 Pro 上的基准，Gemma-4 12B 从 18.4 tok/s 提到约 30 tok/s，Qwen3-4B 从 52.9 提到约 73 tok/s，约 1.4～1.6 倍知乎。它解决的是解码瓶颈场景，不是所有任务无脑翻倍。
第三，MLX 的生态在快速变宽。Ollama 的 MLX 引擎经过优化后速度提升了 20%知乎。WWDC26 上 Apple 把 Core AI 和 MLX 一起端上台面，官方亲自带练哔哩哔哩。更值得注意的是 MLX 已完整支持 CUDA 后端，同一套代码既能跑在 Apple Silicon，也能跑在英伟达 GPU 上知乎。
最后一句
这一波实测潮其实说明白了一件事：Mac 本地跑模型，内存决定「能不能装下」，带宽和模型结构决定「跑多快」。稠密模型吃带宽，MoE 吃容量，27B 的刷屏不等于 27B 适合每一台 Mac。你的 Mac 是哪一档内存，正在跑什么模型、什么速度？评论区报个数，给后面想入坑的当个参照。
