Qwen3-27B macOS 推理横评：MTPLX 综合最快，llama.cpp+MTP 紧随其后

针对 Qwen3 系列 27B 模型在本地 Mac 上的运行效率问题，一位用户在 r/LocalLLaMA 发起了一项耗时 5 天、累计超过 100 GPU 小时的实测。测试在 Apple Mac Studio（M2 Max，96GB 统一内存）上完成，覆盖 MTPLX、llama.cpp（含 MTP/DFlash2 草案模型）、mlx-dspark、oMLX、vllm-mlx 共 6 个推理引擎。本文整理其方法、结论与可复现命令。

实测设置

模型与量化：统一使用 8-bit 量化（GGUF 或 MLX），KV cache 不量化，最大上下文 262k，最大响应长度 100k，采用 Qwen 官方 coding sampler 与 Jinja 聊天模板。
测试流程：先跑一段合成短基准验证安装与速度宣称，再进入 agentic 编程实测——分 4 个阶段（需求与规约、实现规划、核心功能、进阶功能），每个引擎分别在 medium 与 xhigh 两种推理强度下各跑一次；最后用 128k 冷启动 prompt 测 prefill 速度。
评分维度：decode（tok/s）、prefill（t/s）、wall time、总生成 tokens，以及作者自评的质量分。

核心结论：MTPLX 综合领先

按质量分排序，前三名为 MTPLX xhigh（93）、MTPLX medium（91）、llama.cpp+MTP xhigh（86）。

MTPLX：解码 20–24 tok/s，prefill 109 t/s，xhigh 总耗时 2h05，质量分 93，是综合最优解。
llama.cpp+MTP：解码 17–20 tok/s，prefill 103 t/s，medium 总耗时仅 1h04，是最快完成任务的方案。
mlx-dspark DFlash2：prefill 速度最快，达 145 t/s，但解码较慢且质量不稳定；其 xhigh 配置甚至思考了 22.6 万 tokens 却未交付有效输出。
oMLX / llama.cpp 基线 / vllm-mlx：整体偏慢。vllm-mlx 存在思维链未与最终输出分离的问题，会泄漏原始推理内容。

xhigh 与 medium 推理强度的权衡

在快速引擎上 xhigh 收益明显：MTPLX xhigh 比 medium 仅多花约 30 分钟，质量显著提升。
在慢速引擎上 xhigh 性价比低：oMLX xhigh 耗时是 medium 的两倍多，主要瓶颈在于解码速度被叠加放大。
总体规律：xhigh 模式下模型思考时间增加 30%–100%，输出质量更好，但仅当引擎解码不被拖慢时才划算；否则建议保持 medium，把省下的时间投入到流程规划上。

复现命令与踩坑提示

MTPLX：mtplx start web --model Qwen3.8-27B-MTPLX-Optimized-Quality --max-tokens 100000，默认响应上限偏低，需手动提到 100k。
llama.cpp+MTP：llama-server -m Qwen3.8-27B-Q8_0.gguf -md mtp-...gguf --spec-type draft-mtp --spec-draft-n-max 3 -c 262144 -ngl 99 -ngld 99，MTP 草案模型使用 ggml-org 官方版本。
llama.cpp+DFlash2：暂需自行编译 PR #27342。
mlx-dspark：--max-tokens-cap 与 --default-max-tokens 都需调整，默认 32k 会截断长任务。
vllm-mlx：默认 300 秒 prefill 超时过短，需用 --timeout 7200 拉长。
测量注意：各引擎流式输出的 token 打包粒度不同，MTPLX 约 1.7、oMLX 约 3，直接对比原始事件数会失真。

对希望在 Mac 上本地跑 Qwen3-27B 做 agentic 编程任务的用户，作者给出的明确建议是：优先选 MTPLX，退而求其次选 llama.cpp+MTP；并尽量使用 xhigh 推理强度以获得更好的输出质量。