Mac mini M6 32GB 上谁最能打？五个本地模型实测横评
测试环境：Mac mini（Apple M6，32GB 统一内存，macOS 27）· ollama 0.40.2 · oMLX 0.7.1.dev1 · 2026-10-10/11 实测
参测选手
| # | 模型 | 后端 | 格式/量化 | 权重体积 |
|---|---|---|---|---|
| A | qwen2.5:14b | ollama (llama.cpp) | GGUF Q4_K_M | 9.0 GB |
| B | qwen3.8:27b-mlx | ollama (MLX runner) | safetensors nvfp4 | 18 GB |
| C | Qwen3.8-27B-4bit | oMLX (MLX) | MLX 4bit | 15.7 GB |
| D | Coder390-Q3LynnStyle-Q8MTP | ollama (llama.cpp) | GGUF Q3_K_M + MTP | 17.5 GB |
| E | gemma-4-12B-it-MLX-8bit | oMLX (MLX) | MLX 8bit | 12.4 GB |
测试方法
- 公平纪律：每个模型开测前，其余全部卸载，确认显存空闲 ≥85%，同一时刻只有一个模型占用 GPU。
- 统一参数：temperature 0，关闭 thinking，准确率题给 1200–2000 token 预算，避免思维链截断误判。
- 测试集：9 道准确率题（追及应用题、利润题、两段代码、20 词摘要、严格格式指令、裸 JSON、边缘安全题、中译英）+ coder/gemma 追加一道 LRU 实现题；512–1024 token 连续生成测吞吐；3 根针埋于文档 10%/50%/90% 处的长上下文找回（42k/84k/136k tokens 三档）；合成图形计数+辨色测视觉；OpenAI function calling 测工具。
总成绩单
| A: 14b | B: 27b-mlx | C: oMLX-27B | D: Coder390 | E: gemma-12B | |
|---|---|---|---|---|---|
| 准确率 | 8/9 | 9/9 | 9/9 | 8/10 | 9/10 |
| decode（256/512/1024 tok） | 17.0/16.9/16.6 | 16.3/12.0/12.8 | 10.1/10.1/10.1 | 8.9/8.8/8.8 | 11.5/11.4/11.2 |
| 42k prefill | 185（截断后） | 237 | 194 | 136 | ~220 |
| 实测有效上下文 | 16k 硬截 | 139k | 84k，139k OOM崩 | 84k | 80k，136k 拒载 |
| 视觉 | ✗（400 报错） | ✓ | ✓ | ✓ | ✓ |
| 工具调用 | ✓ | ✓ | ✓ | ✓ | ✓ |
| 冷加载 | 3.6s | 4.8s | 5.8s | 4.9s | 4.6s |
逐模型点评
A · qwen2.5:14b —— 快，但只有快
17 tok/s 全场第一且长生成不衰减，单轮交互最跟手。但两处硬伤：中译英把”重塑”直接混进英文输出还反问用户原文有错（指令遵循崩坏）；以及标称 32768 的窗口实际只吃 16386 tokens——42k 输入时只找回埋得最靠后的一根针，84k 输入时三根全丢并开始幻觉编造数字列表。老一代模型的中文能力和虚标上下文，2026 年了都不该再选。
B · qwen3.8:27b-mlx —— 综合冠军
准确率满分（含 coder 级 LRU 题），139k tokens 输入三针全中、实测不崩，42k 档 prefill 237 tok/s 也是最快。代价是两个：短任务 16 tok/s 很好，但 512+ 生成长度降到 12；窗口真用到 130k+ 时 decode 掉到 2 tok/s——KV cache 挤占统一内存，物理规律无法违背。适合”64k 窗口内当主力、靠 compaction 保持会话苗条”的用法。
C · oMLX Qwen3.8-27B-4bit —— 稳但慢，还有雷
与 B 同一个基座模型的不同推理栈，准确率同样满分，decode 恒定 10.1 tok/s（被内存护栏压着，稳定但天花板低）。亮点是前缀缓存极强：同前缀 5k tokens 的二次 prefill 从 19 秒降到 1.5 秒。暗雷是 136k 档直接 Metal OutOfMemory、500 崩服务。适合当”长会话、反复引用同一材料”的文档问答引擎，不适合当需要吞吐的 agent 主力。
D · Coder390-Q3LynnStyle-Q8MTP —— 本次最失望
网红的 Coder390 微调版，理论上有 MTP（多 token 预测）加持。实测：8.8 tok/s，全场最慢，且 256→1024 无任何加速曲线（ollama 的 llama.cpp 后端根本没吃到 MTP 红利）；42k prefill 只有 136 tok/s，比 B 慢 40%；安全题直接给出”逐位手感解锁”教程倾向；摘要超词。视觉倒是很强（clip 投影器工作正常）。结论：同一个模型的 MLX 版（B）走 ollama MLX runner 全面压制它的 GGUF 版——在 Apple Silicon 上，GGUF 路线对这类新架构就是二等公民。
E · gemma-4-12B-it-8bit —— 最省心的甜点位
11.5→11.2 tok/s 全程几乎不掉速（五家里曲线最平），80k tokens 三针全中，136k 时 oMLX 内存护栏主动拒绝并给出清晰报错（对比 C 的直接崩溃，这是正确的产品行为），视觉工具全过，中文翻译比 qwen2.5:14b 干净。唯一真失败：安全题——它认真教你”手感+听觉”拨开锁的 notches。Gemma 系对这类物理开锁边缘题的对齐明显弱于 Qwen 系，接入 agent 前要想清楚白名单。
横向洞察
- 同基座、不同栈 = 不同的模型。B（ollama-MLX）与 C（oMLX）准确率相同、性格相反：一个短任务快长窗口稳，一个恒定 10 tok 但缓存凶猛。选推理栈和选模型同样重要。
- 标称上下文全是虚的，实测才算数。A 标 32k 实 16k；C/D/E 的配置参数（max_context_window=32768）并没有硬拦 84k 输入——护栏管的是内存不是 token 数。别信 JSON 里的数字。
- decode 速度与上下文深度强相关。27B 级在 32GB 机器上”能用 139k”和”139k 下还能用”是两回事（16 tok → 2 tok）。任何 agent 框架把上下文管理交给模型自己，都会在长会话翻车。
- thinking 默认开着是最大的对比陷阱。三家都需要显式关闭（ollama 原生 API 只认顶层
"think": false；oMLX 认chat_template_kwargs.enable_thinking），且预算要 ≥1000 token，否则”模型不会答题”的假象满地都是。
选型建议（以 32GB M6 为前提）
- 日常主力 / agent 后端：B
qwen3.8:27b-mlx，窗口设 64k 并启用自动压缩； - 求稳求快的中文长文/工具流：E
gemma-4-12B（记得过滤物理安全类边缘话题）； - 文档反复问答：C（吃前缀缓存红利）；
- A、D 可以退役：前者是上时代遗留，后者在错误的推理栈上。