最近我的互联网几次崩溃，让我在没有编码代理的情况下陷入困境，因此当我看到 "Gemma 4 现在通过 MTP 运行速度提升 2 倍" 的多标记预测更新时，我决定尝试让它运行。我想要一个本地编码代理的设置：足够快以便可以在我的 Mac 上实际使用，通过兼容 OpenAI 的 API 运行（这样我可以在其他工具中使用），并且最好能在需要时处理截图/图像，这样我就能把它生成的内容的截图喂给它。结果我成功了！这个视频是实时的，展示了代理以完全可用的速度响应。经过一些测试，我最终的设置是：在 macOS 上使用 Metal 构建的 llama.cpp Gemma 4 26B-A4B 以 GGUF 格式 A Q8 MTP 草稿模型 用作终端编码代理的 Gemma 4 多模态投影器 这是在运行 macOS 15.7.7 的 Apple M1 Max 上测试的，配备 64 GB 统一内存。 模型 主要模型是：gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf 在 Hugging Face 上的链接：models/unsloth-gemma-4-26B-A4B-it-GGUF/gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf 该文件约 16 GB。与 MTP 草稿头和多模态投影器一起，模型文件夹约为 17 GB。基准提示是：编写一个紧凑的 Python 函数，解析统一 diff 并返回更改的文件路径。然后解释两个边缘情况。每个基准生成约 128 个标记。 基线：llama.cpp + Metal 我首先通过 llama.cpp 直接运行主模型，并启用 Metal 加速：repos/llama.cpp/build/bin/llama-cli -m models/unsloth-gemma-4-26B-A4B-it-GGUF/gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf -ngl 999 -fa on -c 4096 -n 128 结果：设置提示 tok/s 生成 tok/s Gemma 4 26B-A4B Q4，llama.cpp Metal 298.0 58.2 58 tokens/second 虽然速度不是很快，但可以用，但对于编码代理工作，你希望速度尽可能快，特别是在代理进行许多工具调用时。 添加 MTP 草稿模型 Gemma 4 现在可以使用 MTP 草稿模型：MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf 这可以通过 llama.cpp 作为推测草稿模型加载：repos/llama.cpp/build/bin/llama-cli -m models/unsloth-gemma-4-26B-A4B-it-GGUF/gemma-4-26B-A4B-it-UD-Q4_K_XL.gguf --model-draft models/unsloth-gemma-4-26B-A4B-it-GGUF/MTP/gemma-4-26B-A4B-it-Q8_0-MTP.gguf --spec-type draft-mtp --spec-draft-n-max 3 -ngl 999 -fa on -c 4096 -n 128 第一次运行 MTP 的结果是使用 4 个草稿标记达到 69.2 tokens/second。然而，Unsloth 关于如何运行 MTP 模型的指南包括这条注释：“我们发现 --spec-draft-n-max 2 是最佳起点，但不要假设 2 是最优的，因为性能取决于硬件。尝试从 1 到 6 的任何值，并使用适合您系统中最快的那个。”经过对 --spec-draft-n-max 的测试，最佳结果是 72.2 tokens/second，使用了 3 个草稿标记。 设置提示 tok/s 生成 tok/s 提速 仅主模型 298.0 58.2 1.00x 主模型 + Q8 MTP 草稿 295.6 72.2 1.24x 有用的是提示处理基本保持不变，而生成速度改善约 24%。 调整 MTP 我测试了 --spec-draft-n-max 的值从 1 到 6。 --spec-draft-n-max 提示 tok/s 生成 tok/s 1 295.5 68.4 2 299.1 72.0 3 295.6 72.2 4 297.3 70.7 5 297.9 63.7 6 296.3 61.2 在我的 M1 Max 机器上，3 是最快的，2 的速度接近，任一值都可以。 值高于该范围的速度都较慢。 MLX 比较 我还通过 mlx-lm 测试了 MLX 模型，以找出在 Mac 上运行模型的更快方法，是 llama.cpp 还是 mlx。 运行时 模型 生成 tok/s llama.cpp Metal + MTP Unsloth GGUF Q4 + Q8 MTP 72.2 llama.cpp Metal Unsloth GGUF Q4 58.2 MLX-LM Unsloth UD MLX 4-bit 45.8 MLX-LM mlx-community 4-bit 43.9 MLX-LM mlx-community OptiQ 4-bit 38.1 我以为 MLX（针对 Mac 进行优化）会是最快的。然而，在这个特定的设置下，llama.cpp 比 MLX 更快，而 llama.cpp 加上 MTP 显然是最佳选择。我想所有为 llama.cpp 付出的努力和调整使得它在 macOS 上的优化表现得相当好，即使它是跨平台的。我还尝试通过 gemma-4-swift-mlx 运行 Gemma 4 MTP，但测试的 26B 4-bit MLX 检查点与加载器预期的权重键不匹配，我已经有了之前的 MLX 测试，所以不想重新下载新的模型并尝试调整以匹配。 添加图像支持 对于 Pi，我还想能够附加截图。我最初为它设置的本地模型条目声明模型为仅文本：“input” : [ “text” ] 这就意味着 Pi 没有正确地将图像工具输出发送给模型。llama.cpp 服务器还需要 Gemma 4 多模态投影器，以便多模态部分工作（只有 12B 是原生多模态的）：mmproj-BF16.gguf 使用 --mmproj 加载后，llama.cpp 显示多模态支持，Pi 可以发送图像。我重新运行了加载了投影器的文本基准，只是为了检查它没有改变速度：设置投影器 提示 tok/s 生成 tok/s llama.cpp Metal + MTP 无 120.3 71.4