### 基准测试结果：在macOS上运行Qwen3.8-27B的最佳且最快的引擎是什么？ 目前尚未有官方或广泛认可的基准测试明确指出运行 **Qwen3.8-27B**（假设为27B参数模型）在macOS上性能最优的引擎。实际性能高度依赖于以下因素： 1. **硬件配置**：特别是Mac芯片型号（M1/M2/M3/M4 Pro/Max/Ultra）、统一内存容量和速度。 2. **模型量化格式**：使用的GGUF/GGML量化级别（如Q4_K_M, Q8_0等）显著影响速度和内存占用。 3. **引擎版本与优化**：引擎的编译优化、对Apple Silicon的Metal/Vulkan后端支持程度。 **不过，基于社区普遍反馈和当前技术栈，以下引擎通常被认为在macOS上运行大型语言模型表现出色：** #### 1. **llama.cpp（及其衍生版本）** - **优势**：高度优化，原生支持Apple Silicon的**Metal**加速，性能卓越。是macOS上运行量化模型（GGUF格式）的**事实标准**。 - **推荐**：使用最新版本的 `llama.cpp`，并在编译时启用Metal后端。其子项目 `llama-ggml-metal` 性能强劲。 - **运行方式**：通常通过命令行工具（如 `llama-cli`, `llama-server`）运行。 #### 2. **MLX** - **优势**：由Apple团队开发的**专为Apple Silicon优化的机器学习框架**。能原生利用芯片的统一内存和GPU，理论上能实现最佳性能和内存效率。 - **现状**：对部分模型有良好支持，但生态和模型兼容性（尤其是GGUF格式）相比llama.cpp可能稍逊。需确认Qwen3.8-27B是否有适配MLX的版本。 - **推荐**：如果MLX版本可用且性能良好，它很可能是**“最快”** 的选择。 #### 3. **LM Studio** - **优势**：提供开箱即用的图形界面，底层集成了`llama.cpp`等引擎，并进行了优化配置。对用户友好，性能也十分优秀。 - **推荐**：适合希望便捷管理模型和参数，并快速获得良好性能的用户。 **如何自行寻找“最佳”答案？** 由于缺乏统一基准，最可靠的方法是**自己测试**： 1. **下载引擎**：获取最新版本的 `llama.cpp`（带Metal）、 `MLX` 相关推理工具，或 `LM Studio`。 2. **准备模型**：下载适用于你目标引擎的 `Qwen3.8-27B` 量化文件（例如GGUF格式）。 3. **进行基准测试**： - **速度**：测量生成速度（tokens/秒）。 - **内存**：观察内存占用峰值。 - **稳定性**：确保运行稳定。 4. **调整参数**：在每种引擎中调整上下文长度（`-c`）等参数，找到平衡点。 **结论建议：** - **追求极致性能与兼容性**：首选 **llama.cpp**（确保启用Metal）。 - **追求Apple生态原生与潜在最优效率**：尝试 **MLX**，但需先确认模型支持。 - **追求便捷性与高性能的平衡**：选择 **LM Studio**。 请记住，27B参数的模型即使量化后，也需要 **32GB 或更多统一内存** 的Mac才能流畅运行。请根据你的具体硬件进行选择和测试。

全新的 Qwen 3.8 27B 模型非常适合本地智能体使用。问题在于，使其表现出色的特性（作为稠密模型）也导致了它的运行缓慢。许多引擎和模型变体都声称能实现各种速度提升。这些说法究竟有多真实？而且，在短时合成测试中得到验证的巨大提升宣称，在实际的智能体工作负载中还能保持吗？我花了五天时间和超过100个GPU小时，进行了严谨、可重复的智能体编码测试，收集并比较了数据。下载了200GB的模型文件。最终，我的磁盘上产生了20个《泡泡龙》克隆游戏，包括那些测试失败的版本。没有一个能玩，但这不是重点。我的推荐是：MTPLX 或 llama.cpp+MTP。 我在8位量化模型（GGUF或MLX格式）上进行测试，KV缓存未经量化。最大响应长度100k，完整262k上下文，使用Qwen官方编码采样器和Qwen Jinja聊天模板。 我首先用一个简短的合成基准测试每个引擎，以验证安装、使用、结果收集，并验证速度声称。然后是真正的测试，使用一个由4个阶段/提示组成的智能体编码基准；每个引擎测试两次，分别在中等和极高推理强度下进行： 1. 捕获需求并编写规范计划 2. 编写实现计划 3. 实现核心功能 4. 完成高级功能的实现 最后一项测试是预填充速度测试，使用冷启动128k token提示，关闭推理并进行确定性采样，重复两次。 测试硬件：Apple Mac Studio，M2 Max，96GB统一内存。 | 引擎 | 强度 | 解码速度 | 预填充速度 | 运行时间 | Token数 | 评分 | |----------------------|--------|----------------|------------|----------|---------|------| | MTPLX | 极高 | 20–22 tok/s | 109 t/s | 2小时05分 | 152K | 93 | | MTPLX | 中等 | 21–24 tok/s | 109 t/s | 1小时35分 | 117K | 91 | | llama.cpp + MTP | 极高 | 17–19 tok/s | 103 t/s | 2小时52分 | 179K | 86 | | llama.cpp + MTP | 中等 | 18–20 tok/s | 103 t/s | 1小时04分 | 70K | 84 | | mlx-dspark DFlash2 | 中等 | ~16–18 tok/s | 145 t/s | 2小时09分 | 125K | 82 | | mlx-dspark DSpark | 中等 | ~12–17 tok/s | 145 t/s | 2小时05分 | 96K | 77 | | llama.cpp + DFlash2 | 中等 | 14–15 tok/s | ~103 t/s | 2小时09分 | 111K | 74 | | llama.cpp + DFlash2 | 极高 | 13–14 tok/s | ~103 t/s | 3小时31分 | 174K | 72 | | oMLX | 极高 | 10–11 tok/s | 85 t/s | 3小时57分 | 146K | 67 | | llama.cpp 基线版 | 极高 | 10–11 tok/s | 103 t/s | 3小时43分 | 140K | 66 | | llama.cpp 基线版 | 中等 | 10–12 tok/s | 103 t/s | 1小时44分 | 66K | 66 | | oMLX | 中等 | 10–12 tok/s | 85 t/s | 1小时44分 | 64K | 65 | | vllm-mlx | 中等 | 9–11 tok/s | 134 t/s | 3小时30分 | 115K | 51 | | vllm-mlx | 极高 | 9–12 tok/s | 134 t/s | 4小时08分 | 136K | 50 | | mlx-dspark DFlash2 | 极高 | ~9–15 tok/s | 145 t/s | 3小时58分 | 226K | 47 | * vllm-mlx：完成了任务，但没有将思考过程与输出分开，导致原始的思考链泄漏到了最终输出中。 * mlx-dspark DFlash2 极高强度：思考了22.6万个token，却什么也没交付。 **关于极高与中等推理强度？** MTPLX 极高强度仅比中等多花半小时（2小时05分 vs 1小时35分），但在我评分卡上的游戏质量显著提升。值得。 llama.cpp + MTP 极高强度多花了1小时48分，质量同样有显著提升。如果你有时间，值得。 oMLX 极高强度耗时是中等的两倍多。较慢的token生成速度对两种模式的时间差产生了巨大影响。不值得。不如换一个更快的引擎。 dspark DFlash2 极高强度是表格底部的警示案例。请参阅上方的异常说明。 当引擎足够快且没有限制时，极高强度才值得。模型会思考更长时间（增长30%至100%），速度相同，结果更好。在慢速引擎上，你会明显感受到较慢的性能与额外思考时间叠加的负面影响；这时不如使用中等强度，由你自己花时间规划更好的流程和工作流。 **命令和配置说明** 我为每个引擎使用的确切命令： ```bash # llama.cpp 基线版 (homebrew, b10470) llama-server -m Qwen3.8-27B-Q8_0.gguf --mmproj mmproj-F16.gguf \ --jinja -c 262144 --parallel 1 -ngl 99 --port 8030 # llama.cpp + MTP，推荐的GGUF设置 llama-server -m Qwen3.8-27B-Q8_0.gguf --mmproj mmproj-F16.gguf \ -md mtp-Qwen3.8-27B-Q8_0.gguf --spec-type draft-mtp --spec-draft-n-max 3 \ --jinja -c 262144 --parallel 1 -ngl 99 -ngld 99 # llama.cpp + DFlash2 (目前需要 PR #27342 版本) llama-server -m Qwen3.8-27B-Q8_0.gguf \ -md Qwen3.8-27B-DFlash2-Q8_0.gguf --spec-type draft-dflash --spec-draft-n-max 7 \ --jinja -c 262144 --parallel 1 -ngl 99 -ngld 99 # MTPLX (pip install mtplx)。注意 --max-tokens mtplx start web --model Qwen3.8-27B-MTPLX-Optimized-Quality --max-tokens 100000 # oMLX (brew install jundot/omlx/omlx)，模型目录包含检查点 omlx serve --model-dir /path/to/models # mlx-dspark (pip install mlx-dspark)。注意 --max-tokens-cap mlx-dspark serve --model Qwen3.8-27B-MLX-8bit --mode dflash \ --context-window 262144 --max-tokens-cap 262144 --default-max-tokens 100000 # vllm-mlx (pip install vllm-mlx)。注意 --timeout vllm-mlx serve Qwen3.8-27B-MLX-8bit --max-request-tokens 262144 --timeout 7200 ``` 所有MLX引擎都使用普通的 mlx-community 8位权重，MTPLX除外，它需要其专有的检查点格式（包含MTP张量）。我使用的是 Youssofal/Qwen3.8-27B-MTPLX-Optimized-Quality。 对于llama.cpp GGUF，我使用了来自 ggml-org 的官方MTP草稿模型。 **MTPLX** 默认响应上限较低，请使用 `--max-tokens 100000`。 **dspark** 也有一个较低的默认生成上限32k。 **vllm-mlx** 会终止任何预填充时间超过300秒的请求。请使用 `--timeout` 提高它。 **给任何复现此测试的人的一个测量警告：** 引擎并非都以每事件一个token的方式流式传输。有些会将多个token打包在一个块中，MTPLX约1.7个，oMLX约3个。