/tags/mlx/ Recent content in mlx on Hugo -- gohugo.io en Sun, 19 Apr 2026 02:00:00 +0800 /posts/omlx-gemma4-m5-optimization/ Sun, 19 Apr 2026 02:00:00 +0800 /posts/omlx-gemma4-m5-optimization/ 实验结果 (M5 / 32GB RAM) 测试模型：Gemma4-26B-A4B-it-nvfp4（4-bit 量化，激活权重 ~3.85GB）。 场景 基线 调优后 提升 瓶颈分析 短文本生成 (256 tok) 38.18 tok/s 39.75 tok/s +4.1% 带宽瓶颈：已达硬件理论极限 长文本重复查询 (11k tok) 14.59s 2.27s +540% IO 瓶颈：Hot Cache 消除磁盘加载 瓶颈逻辑：为什么我把 39.7 tok/s 当作接近上限的参考值？ Decode 阶段性能由内存带宽决定：每生成一个 token，都要把激活权重从内存完整读一遍。 MoE 激活：Gemma4-26B-A4B 单步仅激活 4B 专家参数，约 3.85 GB（nvfp4 量化后）。 硬件带宽：M5 标准版 153 GB/s。 理论上限：153 GB/s ÷ 3.85 GB ≈ 39.7 tok/s 这次实测到 39.75 tok/s，已经很接近按带宽估出来的上限。至少在这组测试条件下，软件层面的调参看起来不太容易明显越过这条线。 优化策略 (针对 32GB 机型) 1. 内存硬锁定 sudo sysctl iogpu. /posts/mlx-vs-ollama-benchmark-on-m2-mbp/ Sat, 14 Mar 2026 15:00:00 +0800 /posts/mlx-vs-ollama-benchmark-on-m2-mbp/ Apple Silicon 的统一内存架构让本地运行大模型成为可能，而在 macOS 上，目前主要有两条路：通用方案 Ollama（基于 llama.cpp），以及 Apple 官方为 Apple Silicon 定制的 MLX 框架。 这篇文章记录我在 M2 MacBook Pro (32GB) 上的实测过程，重点回答一个问题：在日常使用中，MLX 到底比 Ollama 快多少？值不值得切换？ 测试环境与方法 硬件: M2 MacBook Pro，32GB 统一内存 系统: macOS（后台无其他 GPU 密集型任务） 测试 Prompt: 固定同一段中文提问，限制输出 128 tokens 重复次数: 每组跑 3 次取平均，排除冷启动影响 引擎 模型 量化格式 Ollama qwen3.5:latest GGUF Q4_K_M MLX mlx-community/Qwen3.5-9B-MLX-4bit MLX 4-bit 两者均使用 Qwen3.5 9B，量化精度对齐为 4-bit，尽量排除模型本身的变量。 MLX 与 GGUF：两种格式的本质差异 理解这两种格式的区别，有助于解释为什么它们的性能表现不同。 GGUF（llama.cpp 使用的格式）是一种跨平台的模型格式，设计目标是兼容性：同一个文件可以在 CPU、NVIDIA GPU、AMD GPU、Apple Silicon 上运行。Ollama 底层就是 llama.cpp，通过 Apple 的 Metal API 调用 GPU，但这层抽象有额外的调度开销。