Qwen3.5:35b-mlx is much slower than Qwen3.5:35b; Qwen3.6:35b-mlx is unrunnable while Qwen3.6:35b can

快速结论：这类问题通常出现在 macOS 的 Ollama 用 MLX runner 加载 Qwen3.5/Qwen3.6 35b-mlx 混合精度 MoE 模型时：一个模型明显变慢，另一个直接加载失败。优先排查 MLX runner 有没有应用 config.json 里的逐张量量化覆盖，以及所用的 Ollama 版本。

适用环境：Issue 中确认的环境为 macOS，Apple Silicon（M3、M3 Ultra、M5 Pro / 64GB 均被提到），Ollama 版本涉及 0.24、0.31.1、0.32.9，以及后续评论提到的 0.34.4；模型为 Qwen3.5:35b / Qwen3.5:35b-mlx 和 Qwen3.6:35b / Qwen3.6:35b-mlx。日志中显示 Metal、iGPU、默认上下文 4096，并设置了 OLLAMA_CONTEXT_LENGTH:32768、OLLAMA_DEBUG:INFO。

最快修复方案：暂无确认的一步修复方案。Issue 中有用户手动应用 PR #15760（config_quant.go / root.go / runner.go）并从本地重新构建 runner 后，qwen3.6:35b-mlx 从立即崩溃变为可正常运行，qwen3.5:35b-mlx 的“变慢”也一并改善；但该 PR 在讨论时仍处于未合并状态，因此官方版本并无已验证的修复。可优先尝试：确认当前 Ollama 版本行为，如果仍在受影响的版本区间，关注并等待包含该修复的版本。

注意事项：手动打补丁并重新构建属于未合并改动的本地实验，存在构建失败或回归风险，不要直接照搬到生产环境；性能对比受上下文长度、量化类型、机型影响，Issue 中有人在 32k 上下文下给出 MLX 与 GGUF 互有胜负的数值，说明“MLX 一定更慢”并不成立。

问题场景

用户在 macOS 的 Apple Silicon 机器上用 Ollama 跑 Qwen3.5/Qwen3.6 的 35b 模型，对比同一 prompt 下 GGUF 与 MLX 两种权重格式的表现。结果出现两种异常：Qwen3.5:35b-mlx 比 Qwen3.5:35b 慢很多，而 Qwen3.6:35b-mlx 直接无法运行，Qwen3.6:35b 却能正常跑。评论中另一位用户在 M5 Pro、64GB、Ollama 0.32.9 上复现了同样的 qwen3.6:35b-mlx 不可运行行为。

报错原文

Qwen3.5:35b-mlx is much slower than Qwen3.5:35b; Qwen3.6:35b-mlx is unrunnable while Qwen3.6:35b can

# 复现用户补充的崩溃信息
the MLX runner crashes immediately with `index out of range [0]` during model load

原因分析

根据 Issue 中复现用户的定位，最可能的原因是 MLX runner 没有应用 config.json 中的逐张量量化覆盖（per-tensor quantization overrides）。Qwen3.5/Qwen3.6 的 MoE 配置使用混合精度量化，例如 router/gate/embed 权重为 8-bit、专家层为 4-bit；当覆盖被忽略时，模型张量布局与加载器预期不匹配，加载阶段 MoE 层就会以 index out of range [0] 失败。

同一根因还会让部分层静默回退到非最优量化，这被认为是 qwen3.5:35b-mlx 明显变慢的原因。需要说明的是，该定位来自社区用户的手动验证，不是官方已合并修复，因此属于强证据下的可能原因判断。

环境排查

确认 macOS 与 Apple Silicon 机型、内存容量（Issue 中为 M3 / M3 Ultra / M5 Pro 64GB）。
确认 Ollama 版本：0.24、0.31.1、0.32.9、0.34.4 在讨论中被提及，其中 0.32.9 可复现崩溃。
确认模型标签与格式：qwen3.5:35b、qwen3.5:35b-mlx、qwen3.6:35b、qwen3.6:35b-mlx。
确认是否使用 MLX runner（日志中的 Metal / iGPU 与 MLX runner 相关）。
对比测试时保持上下文长度一致，例如讨论中的 32k 上下文与日志里的默认 4096。
关注 config.json 的逐张量量化设置是否被 runner 生效。

解决步骤

先记录当前 Ollama 版本，并确认 qwen3.6:35b-mlx 是否在加载阶段直接崩溃、报 index out of range [0]。
用同一个 prompt 分别跑 GGUF 版与 MLX 版，固定上下文长度（例如 32k），记录 decode 速度，排除上下文差异导致的误判。
可优先尝试：检查并关注 PR #15760 的状态，该 PR 为“apply config.json per-tensor quant overrides for mixed-precision MoE”。
如果需要在本地验证，可参考 Issue 中用户的做法：把 PR #15760 的改动应用到 config_quant.go、root.go、runner.go，然后重新构建 runner 并再次测试（属于未合并改动的本地实验）。
修复生效后，重新对比 qwen3.6:35b-mlx 是否可正常加载，以及 qwen3.5:35b-mlx 的速度是否与 GGUF 路径接近。

验证方法

验证分两部分：一是 qwen3.6:35b-mlx 不再在模型加载阶段崩溃，可以正常完成一次推理；二是 qwen3.5:35b-mlx 在同 prompt、同上下文长度下的 decode 速度不再明显落后于 GGUF 版本。Issue 中 M5 Pro 64GB 的实测为约 60 tok/s decode（temperature 0、主权重 4-bit），与 GGUF 路径相当。另需注意，0.34.4 中有用户反馈 qwen3.5:35b-mlx 反而明显快于 qwen3.5:35b，说明版本与量化配置对结果影响很大，应以自己环境中的实测为准。