在 Apple Silicon 上运行本地大语言模型时，量化策略的选择直接影响推理吞吐、内存占用与输出质量。Ollama 在 macOS 预览版中引入了 MLX 后端，与传统的 GGUF 格式走了两条不同的技术路径。本文聚焦这两种量化方案的工程参数差异，为开发者选择合适的量化级别提供可落地的参考依据。

量化格式的技术差异

Ollama 默认使用 GGUF 格式的 Q4_K_M 量化方案，平均每个权重约 4.5 比特。这是 GGUF 生态中最平衡的档位，在压缩率与精度之间取得了较好的折中。llama.cpp 则提供了更灵活的 Q4_K_XL 模式，会将注意力层和 MoE 路由层等关键组件保持 8 位或 16 位精度，其余层使用 4 位量化，在体积略有增加的情况下提升了计算精度。

Apple 的 MLX 框架则采用了原生 4 位分组量化（group quantization），针对统一内存架构进行了专门优化。这种量化方式与 GGUF 体系有本质区别：它不追求通用的权重压缩，而是结合 Apple GPU 的矩阵运算单元特性，在硬件层面实现更高的计算效率。根据实测数据，MLX 在 Qwen3.5 35B（MoE 架构，17B 活跃参数）上仅需约 20GB 统一内存即可加载，相当于每活跃参数约 1.2GB，这种内存效率使得 24GB 入门级 MacBook Air 也能流畅运行中等规模的模型。

8 位量化在 MLX 生态中同样有对应的模型变体，例如 HuggingFace 上的 mlx-community/GLM-4.5-MLX-8bit。与 4 位相比，8 位量化的模型体积大约增加一倍，但保留了更多的权重信息。对于某些对精度敏感的任务，如复杂推理链的生成，8 位可能带来可感知的质量提升。

推理吞吐与延迟工程参数

在 M4 Max（128GB 统一内存）上针对 Qwen3.5 35B-A3B 的实测数据揭示了量化级别对性能的直接影响。使用 MLX 原生 Python API 时，4 位量化可达到约 130 tokens/s 的生成速度，客户端测得约 115 tokens/s。当通过 HTTP 服务器调用时，由于 TCP 连接、SSE 流式传输和 JSON 解析的开销，速度下降至 90 至 108 tokens/s，但仍远超传统方案。

切换到 8 位量化后，吞吐会出现显著下降。根据 Apple 社区的基准测试，8 位量化通常比 4 位慢约 30% 至 40%，具体数值取决于模型架构和批次大小。对于 7B 规模的模型，4 位配置下常见吞吐约为 80 至 100 tokens/s，8 位则降至 50 至 70 tokens/s。这一差距在长上下文生成场景会更加明显，因为 8 位量化需要更频繁地访问统一内存带宽。

对比 Ollama 的 GGUF 路径，在同一硬件上 Ollama 的生成速度约为 40 至 48 tokens/s，仅为 MLX 4 位的约三分之一。llama.cpp 则位于两者之间，约为 70 tokens/s。这种性能差距主要来源于两个方面：MLX 直接调用 Apple GPU 的 Metal 着色器，无需跨平台兼容层；4 位分组量化与 Apple 芯片的矩阵乘法单元高度契合，减少了数据类型转换的开销。

延迟方面的表现同样值得关注。首 token 延迟（Time to First Token，TTFT）在 4 位量化下通常低于 100ms，得益于更小的模型体积和更低的解压缩开销。8 位量化的首 token 延迟会增加约 20% 至 30%，因为需要处理更多的权重数据。 token 间的延迟（Inter-Token Latency，ITL）在 4 位下稳定在 7 至 10ms 区间，8 位则上升到 12 至 18ms。对于需要实时交互的编码助手或聊天机器人应用，4 位量化在延迟指标上优势明显。

场景化选型建议

选择 4 位还是 8 位量化，需要根据具体业务场景进行权衡。对于日常对话、代码补全和内容摘要等对响应速度敏感的任务，4 位量化是首选。其近无损的压缩特性（尤其是对 MoE 架构）在业界已有广泛验证，Qwen3.5 这类 MoE 模型在 4 位量化下的质量损失几乎可以忽略不计。内存占用仅需 20GB 左右，使得 24GB 内存的 Mac 设备也能胜任。

对于需要更高推理质量的场景，例如复杂数学推理、长文本总结或多轮复杂对话，可以考虑 8 位量化或 llama.cpp 的 Q4_K_XL 模式。这类方案在关键计算层保留了更高精度，输出的连贯性和准确性通常优于纯 4 位方案。代价是内存占用翻倍，推理速度下降约三分之一。如果设备统一内存充足（如 64GB 或 128GB），8 位是合理的升级选择。

混合策略也是一种值得考虑的方案：在模型的不同层使用不同精度。llama.cpp 的 Q4_K_XL 就是这种思路的实现，将注意力机制和路由层保留为高精度，仅对非核心层进行深度量化。这种方式在接近 4 位内存占用的同时，提供了接近 8 位的推理质量。

监控与调优实践

在实际部署中，建议建立一套监控体系来验证量化策略的选择是否合适。核心指标包括：生成速率（tokens/s）、首 token 延迟、内存占用峰值以及输出质量评分。对于生产环境，可以设置如下阈值告警：生成速率低于 50 tokens/s 时触发性能预警；内存占用超过设备可用内存的 80% 时触发资源预警；通过自动评估脚本检测输出质量下降是否超过预设阈值。

Ollama MLX 后端目前仍处于预览阶段，部分高级配置选项尚未完全开放。开发者可以通过环境变量调整 MLX 的行为，例如设置 MLX_NUM_THREADS 控制并行线程数，或通过模型加载参数指定分组大小（group size）。分组大小直接影响量化精度与速度的平衡，较小的分组（如 32 或 64）通常带来更高的精度但略低的吞吐量，较大的分组（如 128 或 256）则相反。

如果需要在不同量化级别之间切换，建议编写自动化脚本实现模型热重载。最简单的方案是维护多个模型目录，分别存放 4 位和 8 位版本，通过 Ollama 的模型管理接口或直接操作文件系统来实现动态切换。这种方式虽然不如单一模型内的动态量化灵活，但实现成本更低，且能兼容当前的 Ollama API。

资料来源：本文量化方案对比基于 Ollama 官方文档与 Apple MLX 社区基准测试，实测性能数据取自 antekapetanovic.com 针对 Qwen3.5 35B 在 M4 Max 上的公开评测。