2026 年 4 月，阿里 Qwen 团队连发数款 Qwen3.6 模型：开源的 Qwen3.6-35B-A3B（MoE，4/16）与 Qwen3.6-27B（dense，4/22），加上闭源的 Qwen3.6-Plus 与 Qwen3.6-Max-Preview。开源两款都拿到了 Apache 2.0，并且围绕 agentic coding、工具调用、视觉这几块做了重写——配合 256K 上下文，它们成为继 Qwen3-235B 之后、本地推理玩家最关心的一批模型。
与此同时，Apple 在 5 月初被确认停产 M3 Ultra Mac Studio，新的 M5 Ultra 预计要到 2026 年末才会登场。这让仍在二手市场流通的 M3 Ultra Mac Studio 多了一层窗口期意味：跑 Qwen3.6 这一代模型，它仍然是消费级里最舒服的统一内存平台。本文按机型 + 量化 + 跑法三个维度，把这条路径整理清楚。
一、Qwen3.6 系列速览
| 变体 | 参数 | 类型 | 许可证 | 发布日期 | 主要用途 |
|---|---|---|---|---|---|
| Qwen3.6-27B | 27B | Dense | Apache 2.0 | 2026-04-22 | 通用 + 编码 |
| Qwen3.6-35B-A3B | 35B 总 / 3B active | MoE 稀疏 | Apache 2.0 | 2026-04-16 | 编码 / Agent / 视觉 |
| Qwen3.6-Plus | 未公开 | Dense | 闭源 | 2026-04-02 | 编码、Agent，仅云端 |
| Qwen3.6-Max-Preview | 未公开 | 未公开 | 闭源 | 2026-04-20 | 旗舰，仅云端，260K context |
对本地推理来说，重点是前两款。A3B 这个后缀是 Qwen 这一代沿用的「总参数 / 激活参数」标记——35B-A3B 意味着模型总参数 35B，但每个 token 在 256 个 expert 中只激活其中一部分（路由 8 + shared 1），实际算力消耗按 ~3B 计算。这是 MoE 在 Apple Silicon 上的「用内存换吞吐」核心策略：模型放得下、激活算得起。
两款开源模型都标了 256K context、201 种语言支持，并且引入了一个叫 preserve_thinking 的选项，允许把 thinking-mode 的中间产物在多轮对话里保留——这对 agent 类工作流很重要。
二、机型与统一内存：Mac Studio 三档对照
Apple Silicon 的「统一内存」直接当作 GPU 显存使用，是它在本地 LLM 上的最大优势。Qwen3.6 在 Mac Studio 上的对照如下（以官方 + Unsloth 给出的 4-bit 量化为基准）：
| 机型 | 统一内存 | 适合的 Qwen3.6 | 实测推理速度 |
|---|---|---|---|
| Mac Mini M4 16GB | 16 GB | 35B-A3B（4-bit，mmap） | ~17 tok/s |
| Mac Studio M3 Ultra 96GB | 96 GB | 27B / 35B-A3B（最佳点） | 35B-A3B ~71 tok/s |
| Mac Studio M3 Ultra 192GB | 192 GB | 上述 + Qwen3-235B-A22B（中等量化） | 235B Q4 ~16–24 tok/s |
| Mac Studio M3 Ultra 512GB | 512 GB | 几乎全系开源 LLM | 235B BF16 段位可用 |
几个观察：
- 96GB 是 35B-A3B 的「最佳性价比」点：4-bit 量化加 KV cache 留出空间，仍能在 200K context 量级下持续输出，且 71 tok/s 已经超过大多数云端 API 的人类阅读速度。
- 192GB / 512GB 主要为 235B 与超长 context 服务：跑 27B/35B 反而是浪费，差异更多体现在「可以同时挂多个模型」与「能塞下未量化的 BF16」。
- Mac Mini M4 16GB 也能跑 35B-A3B：通过 llama.cpp 的
--mmap+ MoE 稀疏激活，只把激活那部分搬进物理内存，实测 17 tok/s、零 swap。这是 35B-A3B 相对于 27B dense 模型的杀手锏。
下面这张引自 Creative Strategies 的对照图直接给出了「内存档位 × 模型规格」的视觉版本：
量化档位的实际占用
Unsloth 官方对 Qwen3.6 开源两款给出的「模型重量 + KV cache + 上下文留白」估算如下：
| 模型 | 3-bit | 4-bit | 6-bit | 8-bit | BF16 |
|---|---|---|---|---|---|
| Qwen3.6-27B | 15 GB | 18 GB | 24 GB | 30 GB | 55 GB |
| Qwen3.6-35B-A3B | 17 GB | 23 GB | 30 GB | 38 GB | 70 GB |
96GB 机型的「舒适区」是 4-bit / 6-bit 全系，外加大 context 余量；192GB 以上可以直接挂 BF16。
三、三种主流跑法对比
Mac 上能跑 Qwen3.6 的栈不止一家，差别集中在「速度 / tool-calling / 用户体验」三个维度：
| 工具 | 后端 | 速度（Mac Mini M4） | 工具调用 | 安装难度 |
|---|---|---|---|---|
| llama.cpp + Metal | GGUF | ~17 tok/s | ✅ | 中（自己 build） |
| Ollama | GGUF | ~17 tok/s | ✅ | 低（一行装好） |
| LM Studio（MLX） | MLX | ~25–35 tok/s | ✅ | 低（GUI） |
Raw MLX (mlx_lm) |
MLX | ~25–35 tok/s | ❌ | 低 |
需要提一点：Qwen3.6 在 Ollama 上的 GGUF 当前并不完美——因为多模态部分的 mmproj 视觉权重是分离文件，Ollama 的打包机制目前还没把它们整合好。如果你打算用视觉能力，直接选 llama.cpp 或 MLX 路径会更稳。
跑法 1：llama.cpp（最经典，Metal 加速）
适合「想看看每个开关怎么影响速度」的开发者：
# 编译（关掉 CUDA，启用默认 Metal）
cmake llama.cpp -B llama.cpp/build -DGGML_CUDA=OFF
cmake --build llama.cpp/build --config Release -j --target llama-cli
# 直接从 Hugging Face 拉 Unsloth 量化版
./llama.cpp/build/bin/llama-cli \
-hf unsloth/Qwen3.6-27B-GGUF:UD-Q4_K_XL \
--mmap \
-c 32768 \
--temp 0.7
--mmap 是关键——它让 macOS 把模型文件按需 paging 进物理内存。如果是 35B-A3B 这种 MoE，效果尤其明显：99% 的 expert 在长会话里几乎不会被访问，于是物理内存占用远低于模型实际大小。
跑法 2：MLX（Apple 原生，最快）
MLX 是 Apple 自家针对统一内存做的 ML 框架，对 Qwen3.6 这种 MoE 在 token 生成上的速度优势最明显（参考 MacStories 在 M3 Ultra 512GB 上的 Qwen3-235B 测试，MLX 比 GGUF 快 50%，内存占用还少）：
# Unsloth 提供的一键安装脚本
curl -fsSL https://raw.githubusercontent.com/unslothai/unsloth/refs/heads/main/scripts/install_qwen3_6_mlx.sh | sh
source ~/.unsloth/unsloth_qwen3_6_mlx/bin/activate
python -m mlx_vlm.chat --model unsloth/Qwen3.6-27B-UD-MLX-4bit
要拿到工具调用，可以走 mlx-lm-server 把 OpenAI 兼容 API 暴露出来，前端接 Continue、Cline、Aider 都没问题。
跑法 3：Ollama（最省心）
ollama run qwen3.6:35b-a3b
适合不想折腾命令行的场景，自动处理量化、缓存、并发；缺点是当前 Qwen3.6 GGUF 的 vision 部分尚未完整，并且更新到最新模型的速度比 Hugging Face 慢一拍。
加速：Multi-Token Prediction (MTP)
Qwen3.6 这一代在权重里附带了 MTP 头，允许一次预测多个 token、再用主模型校验。Unsloth 给的数据：
- Qwen3.6-27B + MTP：~140 tok/s
- Qwen3.6-35B-A3B + MTP：~220 tok/s
- 在大多数任务下没有可观察的准确率损失。
如果是 llama.cpp 用户，需要 build 时启用 LLAMA_MTP=1（社区分支提供）；MLX 这边集成更早，自动生效。
四、典型工作流：从安装到跑通
以一台 M3 Ultra 96GB 的 Mac Studio 为例，给出一条最常见的「写代码 + 调 agent」工作流：
# 1. 装 Ollama 或 LM Studio 之一（这里以 Ollama 为例）
brew install ollama
ollama serve &
# 2. 拉 35B-A3B
ollama pull qwen3.6:35b-a3b-q4_K_M
# 3. 用 OpenAI 兼容地址接进自己常用的编码工具
export OPENAI_API_BASE=http://localhost:11434/v1
export OPENAI_API_KEY=ollama
# 4. 用 aider / continue / opencode 等任意一个客户端连过来
aider --model openai/qwen3.6:35b-a3b-q4_K_M --architect
跑起来后，几个值得监控的指标：
Activity Monitor → Memory → Swap Used：理想是恒为 0。一旦出现 swap，就说明模型 + KV cache 已经溢出物理内存，速度会断崖式掉。powermetrics --samplers gpu_power：看 GPU 使用率与功耗。Apple Silicon 的 LLM 推理是 GPU bound，吃不满 GPU 通常意味着 prompt 阶段在 CPU 侧瓶颈。- 首 token 延迟 (TTFT)：长 context 下尤为重要。Qwen3.6 27B 在 M3 Ultra 96GB 上的典型 TTFT 是 32K context 内 < 2 秒；超过 128K 后会显著拉长。
五、M3 Ultra 停产之后：本地推理的选项
5 月 11 日报道确认 Apple 停产了 M3 Ultra Mac Studio，市场反应主要分两派：
- 囤现货：M3 Ultra 96GB / 192GB 在二手与渠道商手里仍流通，跑 Qwen3.6 27B / 35B-A3B 仍然是消费级最佳——这是窗口期。
- 等 M5 Ultra：2026 年底预计登场，传闻在 Neural Engine 之外会针对 transformer 推理增加专用单元；但具体规格未官方发布。
如果不打算等：
- 个人开发者 → Mac Mini M4 16/32GB 跑 27B 量化 / 35B-A3B（mmap），是 $599–$799 档最划算的 LLM 工作站。
- 小团队 / 研究 → 二手 M3 Ultra 96GB（市场价回落明显），跑 35B-A3B BF16 也吃得下。
- 大模型推理 / 长 context → 转向 Strix Halo 或者双 RTX 5090，64GB VRAM 也能拿下 70B Q4，但功耗与噪音都高于 Mac Studio。
- 企业级 → H200 (141GB) / B200 (192GB) 是另一个量级的预算，本文不做覆盖。
总结
Qwen3.6 这一代在 Apple Silicon 上的「最佳搭档」可以归纳为一句话：Mac Studio M3 Ultra 96GB + 35B-A3B 4-bit + MLX。这个组合提供：
- 4-bit 量化 ≈ 23 GB 模型权重 + 大量上下文余量；
- 35B 总参数、3B 激活的 MoE 让推理速度接近云端 API（71 tok/s 起步，MTP 后翻倍）；
- MLX 路径下原生支持工具调用，能直接挂上 Aider / Continue / opencode 等编码 agent；
- 全部本地运行，离线、零订阅、数据不出机。
如果预算更紧，Mac Mini M4 16GB 加上 llama.cpp --mmap，也能拿到 17 tok/s 的可用速度。如果预算更松，512GB 让你直接跑 Qwen3-235B 也不发愁。剩下的，就是看 M5 Ultra 在 2026 年底能不能把这条赛道的天花板再往上抬一档。
评论