如何在 MacBook Pro 上运行 GLM-5.3-Flash：2bit-Lite MLX 实战指南

运行 GLM-5.3-Flash 于 MacBook Pro 上，意味着只有一台机器：一台128 GB M4/M5 Max MacBook Pro，它运行的是2bit-lite 构建，属于我们的 MLX 转换，并提高了 macOS 的有线内存限制。如果你的 MacBook Pro 内存低于 128 GB——比如 36 GB M4 Pro 或 48 GB M4 Max——这份操作指南不适合你；请跳到最后一节，改用托管的 z-ai/glm-5.3-flash API。GLM-5.3-Flash（权重位于 zai-org/GLM-5.3-Flash）是 Z.ai 的 3200 亿参数混合专家模型，每个 token 激活 180 亿参数——发布于 2026 年 8 月 26 日，是首个原生多模态的 GLM-​5——即使我们的 MLX 移植版的最小构建也需要约 102 GB 的权重和约 112 GB 的内存。这就是整个市场，我们不会回避这一点。

这是第一方文档，不是发布稿：以下权重是 OrcaRouter 自己的构建（orcarouter/GLM-5.3-Flash-MLX，MIT），采用我们免校准的 OrcaSAQ 量化方法生成。我们于 8 月 26 日发布，次日公开纠正了方向，因为原始量化范围并未让 MacBook Pro 的实用性对大多数人成为可能——常规 2-bit 构建仍需约 160 GB，而没有任何笔记本电脑具备这一容量。8 月 27 日，我们将最小变体重建为 2bit-lite 专门适配 128 GB MacBook Pro，本文如实说明其带来的好处与代价。每个标记为 实地记录 的数字均在我们单次 H200 验证运行中测得；这里没有任何厂商基准。凡是我们沿用社区做法之处——如 wired-memory 命令、mlx-vlm 版本控制——我们都会如实标注。

哪款版本适用于哪款 Mac（下载任何内容前请先阅读此信息）

仓库中的五个构建各自对应一个最低内存数值。在 MacBook Pro 上，“该选哪个构建”只有一个答案——一切高于 2bit-lite 的都是 Mac Studio 的话题：

• 6-bit — 约296 GB权重 / 约320 GB内存 / 近无损。仅适用于512 GB的Mac Studio。

• 4-bit — 约 204 GB / 约 224 GB / 我们推荐的默认值。Mac Studio 为 256 GB。这就是仓库根目录所镜像的内容。

• 3位——约184 GB / 约200 GB。Mac Studio 256 GB。

• 2-bit — 约145 GB / 约160 GB。Mac Studio 192 GB。这是我们在发布日提供的最小版本，而它是一个失误。

• 2bit-lite — 约 102 GB / 约 112 GB。唯一能装进 128 GB 机器的版本——128 GB M4/M5 Max MacBook Pro，或 128 GB Mac Studio 或 Mac mini。任何 128 GB Apple Silicon 笔记本电脑（M3 Max 或更新型号）也是如此，只是速度较慢。

那个阶梯中隐藏的陷阱：README 的默认下载命令会拉取 4-bit 版本（约 204 GB），这在 256 GB 的机器上是正确的默认选择，但在笔记本电脑上毫无用处。如果你在 MacBook Pro 上按默认命令操作，最终会得到一个无法分配的模型。2bit-lite 路径需要显式指定--include，详见下文。

在以上计算甚至还未生效之前，你还会遇到一个硬性上限。macOS 不允许一个进程占用 128 GB Mac 的全部统一内存；默认的 GPU 可用上限约为 91–96 GB（这是社区逆向工程得出的数字，并在多篇大模型 MLX 配置的文章中得到佐证）。这低于仅权重就约 102 GB 的需求，因此 即使 2bit-lite 也无法加载，除非你提高有线内存上限。这一步是强制性的，详见第 4 节。

安装 mlx-vlm — 并且只安装 mlx-vlm

GLM-5.3-Flash是一个视觉语言模型，因此它运行于mlx-vlm，而不是mlx-lm。这是人们最容易卡住的地方，所以提前说明：mlx-lm仅适用于纯文本模型；通过它运行多模态模型会产生令人困惑的加载错误。请安装0.6.17或更高版本的VLM包：

pip install -U "mlx-vlm>=0.6.17"

版本固定并非装饰。glm5_next —— 支撑 GLM-5.3-Flash 的混合稀疏加线性注意力架构 —— 直到模型发布当天（2026年8月26日）才进入 mlx-vlm，任何更旧的版本都无法识别该配置。该架构之所以重要还有第二个原因：这是一种全新的拓扑结构，第一波移植存在真实的正确性缺陷，而这些缺陷不会从流畅的输出中暴露出来。社区对早期 glm5_next MLX 路径的运行时审计发现并修复了其中四个问题：每个 FFN 块上未应用的 SwiGLU 截断、流形约束的超连接张量被转换为错误的 dtype（这会在静默中破坏注意力混合矩阵）、注意力归一化中的两处 epsilon 不匹配，以及参考实现使用 float32 而实际使用 bf16 的路由器 logits。修复之后，数值与参考实现匹配到约 1e-7。给你的启示：保持 mlx-vlm 更新，并对任何新架构移植的首个版本保持警惕。

下载权重：排除标志，以及你实际需要的包含标志

仓库根目录镜像了 4 位构建，所有五个变体都作为子文件夹提供。默认命令会下载根目录并使用 --exclude，这样五个变体文件夹（合计约 800 GB）就不会被一并下载：

hf download orcarouter/GLM-5.3-Flash-MLX --local-dir ./GLM-5.3-Flash-MLX --exclude "2bit-lite/*" "2-bit/*" "3-bit/*" "4-bit/*" "6-bit/*"

在 MacBook Pro 上，那条命令对你不适用——它给出的是 4-bit 根目录。对于 128 GB 的笔记本电脑，只需获取 2bit-lite 子文件夹：

使用 hf 下载 orcarouter/GLM-5.3-Flash-MLX，包含 "2bit-lite/*" 文件，并保存到本地目录 ./GLM-5.3-Flash-MLX

这是约 102 GB 的下载，而且是自包含的——2bit-lite/ 文件夹自带 config.json，所以你直接让生成器指向它即可。如果 hf 不在你的 PATH 中，请安装它：pip install -U huggingface_hub。开始之前，请确认你有约 110 GB 的可用磁盘空间，并且你的 Mac 存储不是只剩最后那 100 GB——MLX 会内存映射权重，而几乎满的 SSD 正是这些配置在下载中途挂掉的原因。

提高有线内存限制——这个人人都会忘记的步骤

这是在 128 GB MacBook Pro 上决定成败的一步，而 README 卡片默认你已经知道，而没有明确写出该命令。128 GB Mac 的默认 Metal 工作集上限约为 91–96 GB，低于 2bit-lite 权重所需的约 102 GB——因此不执行这一步，模型将无法分配内存，加载过程会失败。社区标准的解决方案是使用 sysctl 命令，以兆字节为单位提高 GPU 有线内存上限：

使用 sudo sysctl 命令，将 iogpu.wired_limit_mb 设置为 114688

这会设置约 112 GB 的上限，为系统预留约 14 GB。在 128 GB 的机器上，社区里实际用的数值从约 114688（112 GB）到约 122880（120 GB）不等；不要设到最大——macOS 需要留有余量，否则内存压力大时会出现 WindowServer 卡顿和系统停滞。设置后，加载模型并观察活动监视器：如果内存压力变黄，就调低数值。

两条实用注意事项，均来自社区实践而非我们的现场记录。首先，sysctl 会在重启后重置，并且只在你设置它的那个终端会话中生效，所以要记得重新运行它（或通过 LaunchAgent 编写脚本）——重启后忘记这回事，就是经典的“昨天还能用”的失败。其次，MLX 还暴露了一个进程内开关，mlx.core.metal.set_wired_limit(bytes)，在 macOS 15.0 及更高版本上可用；它必须保持在 sysctl 上限之下，并且如果你是在笔记本中编写脚本，它是更可移植的选择。无论你使用哪一种，效果都是一样的：没有它，这里的一切都无法运行。

运行它：文本、图像和 Python API

权重就位、限制提高后，生成只需一条命令。文本：

python -m mlx_vlm.generate --model ./GLM-5.3-Flash-MLX/2bit-lite --prompt "用一句话解释量子纠缠。" --max-tokens 256

图像输入的工作方式相同，使用--image标志——这正是多模态模型在笔记本电脑上大显身手的地方，因为视觉塔在 OrcaSAQ 布局中保持更高的精度：

python -m mlx_vlm.generate --model ./GLM-5.3-Flash-MLX/2bit-lite --image photo.jpg --prompt "描述这张图片。" --max-tokens 256

对于脚本而言，Python API 与 mlx-vlm 用户所熟悉的形态相同：

from mlx_vlm import load, generate from mlx_vlm.prompt_utils import apply_chat_template model, processor = load("./GLM-5.3-Flash-MLX/2bit-lite") prompt = apply_chat_template(processor, model.config, "描述这张图片。", num_images=1) print(generate(model, processor, prompt, ["photo.jpg"], max_tokens=256, verbose=True))

保持 --max-tokens 适中。在我们的 H200 实测中，2bit-lite 大约能维持 10 tok/s，因此一份 1,024 token 的答案就已经需要等待两分钟——而当输出较长时，KV 预算和质量崩塌问题就会开始发力（见下文）。在笔记本电脑上，在有实测数据之前，你应该预期它会更慢，而不是更快。

你实际获得的质量（测量阶梯）

这里是这本手册中诚实的部分，我们不会粉饰它。OrcaSAQ 可以优雅地退化至 3-bit，之后成本迅速上升。与 FP8 参考（困惑度 2.7797）相比：

• 6-bit——困惑度 2.7864（+0.24%），top-1 词元一致率 97.76%。近乎无损，名副其实。

• 4-bit：困惑度 2.8620（+2.96%），top-1 准确率 96.13%。推荐的默认值。

• 3-bit — 困惑度 3.0566（+9.96%），top-1 92.06%。激进但可用。

• 2-bit — 困惑度 4.3622（+56.9%），top-1 86.56%。真正的代价。

• 2bit-lite——困惑度 6.7018（+141%），top-1 77.19%。这是最小的构建，也是 MacBook Pro 唯一能容纳的版本。

这些数字来自我们自己的转换流水线。2bit-lite 的困惑度回归达到 141%，top-1 token 一致性低于 78%——你正在运行一个明显降质的模型，下面的故障模式正是这种降质在实际中的体现。它是一个出色的演示，也是一个尚可的短格式助手；但它不能替代全精度模型。

关于速度，我们同样要对您坦诚。已发布的实测说明为 H200：约 10 tok/s，多轮对话稳定，日常问答和短文本处理没有问题。我们目前还没有 2bit-lite 在 MacBook Pro 上的实测数据，也不会去编造一个——Apple Silicon 在此处的吞吐量取决于内存带宽、散热条件以及混合注意力机制所对应的 MLX 内核覆盖情况，而针对此版本在这台笔记本上的表现，上述因素我们均未实测。我们能为您提供的最近似的已发布 Apple Silicon 数据点，是在不同 MLX 运行时下，512 GB Mac 上 4-bit GLM-5.3-Flash 构建的独立测试结果，约为 450 tok/s——但这是不同的构建、不同的精度，而且是台式机，所以也不要把它当作您会得到的数字。请按较慢的速度做预期；如果实际并非如此，那就算是意外之喜了。

KV缓存与长上下文：留意余量

GLM-5.3-Flash宣称支持 1M token 的上下文窗口。这个数字在这套硬件上并无实际意义，如果教程装作不是这样，那反而会误导你。现场备注只有一句话：为运行时配置足够的 KV 预算，以满足你的目标长度。在单块 H200 上，2bit-lite 在权重加载后大约留下 39 GB 的余量用于 KV 缓存。在 128 GB 的 MacBook Pro 上，算起来就更为紧张：约 102 GB 的权重对比约 112 GB 的上限，在计入 macOS 自身的工作集之前，只剩下大约 26 GB——而混合线性注意力层使得该模型的 KV 占用相对于同等规模的稠密模型要小，但其仍然会随上下文长度线性增长。

服务端来自更广泛社区的指导也印证了这一点：一个在8K上下文下能正常加载的配置，在128K下可能会内存耗尽。在笔记本电脑上，请保持上下文较短——几千个token的问答或一张图片——不要试图让它读一本书。当某个工作负载确实需要长上下文时，你就进入了本文最后一部分的讨论范围。

长代码生成在 2bit-lite 下不可靠（请读两遍）

任何隐瞒其失败模式的指南，如果没有这一节都会变得毫无价值，因此它拥有自己的标题。H200 的现场记录清晰明确：日常问答和短文本输出正常，而长代码生成在此精度下并不可靠。我们的验证运行复现了三种失败模式：

• 重复循环——模型开始重复相同的行或文本块，而不是继续推进，通常发生在生成几百个token之后。

• 缺少胶水代码——导入、连接和错误处理被静默丢弃。生成的函数单独看是正确的，但无法运行，因为周围的脚手架完全缺失。

• 频繁重写——而不是进行最小改动，模型会重写文件的大块内容，并且连续轮次的输出互不一致。

这些在2bit-lite上是可以复现的，而这正是77% top-1一致率所预测的情况。那些坚持使用笔记本电脑构建的从业者实际所做的是：

• 将其用于 解释、摘要、问答和图像理解——这是它真正擅长的短形式工作。

• 如果你必须索要代码，请一次只索要一个小函数，并附带明确的签名，且在继续之前逐一验证。不要将整个文件交给它，然后要求实现某个功能。

• 对于任何长时间的任务——完整的模块、重构、长时间的代理会话——都路由到全精度API。这不是变通方案；这是正确的架构，也是最后一部分。

完全不这样做时：改为调用 z-ai/glm-5.3-flash

诚实的决策规则：只有当您确实想要一个 320B 多模态模型在可随身携带的笔记本电脑上运行时，才在 128 GB M4/M5 Max MacBook Pro 上运行 2bit-lite——离线问答、私有文档、图像理解，没有任何数据会离开机器。其他一切请选择 API：

• 任何低于 128 GB 的 MacBook Pro — 没有适合您的构建版本。请勿尝试加载它；请使用 API。

• 长代码生成或长上下文推理——2bit-lite 恰恰在这一点上稳定地失败。请使用 API。

• 质量敏感型工作 — 77.19% 的 top-1 一致性和 +141% 的困惑度是真正的下降，而不是四舍五入误差。使用 API。

• 有保障的吞吐量或可预测的延迟 — 尚无可用的实测笔记本数据，现场记录为 10 tok/s。请使用 API。

托管模型是z-ai/glm-5.3-flash，在 OrcaRouter 上以全精度提供服务，按 Z.ai 当前定价计费——截至撰写本文时，每百万输入 token 为 $0.07，每百万输出 token 为 $0.25（发布期定价；Z.ai 公布的价目表为 $0.15 / $0.50）。这是供应商报告的价格，我们以 0% 加价原样转售，因此 Z.ai 的降价当天就会反映在我们这边。您只需一个 API 密钥，即可访问我们路由的其他 200 多个模型；自动故障转移意味着，用这个新模型做实验不会把您的生产路径押在单一供应商身上。在下载 102 GB 并等待首次冷生成完成的同样时间内，API 已经回答了一周的问题量——而且还是以全精度回答的。

本地推理只有在理由是本地时才值得——隐私保护、离线工作、无速率限制、可依靠电池运行的演示。出于其他任何原因，从成本或质量角度衡量，它都不值得；在内存不足128 GB的机器上，则完全不值得。

常见问题

64 GB 或 96 GB 的 Mac 能否在本地运行 GLM-5.3-Flash？不能。最小的 2bit-lite 构建在扣除 macOS 开销后大约需要 112 GB 最低内存，即使是 128 GB 的机器也必须提高有线内存上限才能加载。如果你的 Mac 低于 128 GB，本地运行这条路走不通；请改用 API 调用 z-ai/glm-5.3-flash。

我安装了 mlx-vlm，但模型加载失败——出了什么问题？常见原因有两个，按顺序排列：一是版本低于 0.6.17，该版本早于 glm5_next 支持，无法识别该架构；二是未提高有线内存限制，因为在 128 GB Mac 上，默认约 91–96 GB 的 Metal 上限下，约 102 GB 的构建无法分配内存。修复这两点（升级软件包、运行 sysctl），即可正常加载。

本地的2bit-lite构建与z-ai/glm-5.3-flash API是同一个模型吗？底层权重同为GLM-5.3-Flash，但质量并不相同。2bit-lite是一种2-bit量化，与FP8参考相比，top-1 token一致性为77.19%，长代码生成不太可靠。API提供全精度。它们只在短文本、对质量要求不高的任务中可互换使用。

30秒版本

一台机器，一次构建，一个必需的 sysctl。如果你有一台 128 GB 的 M4/M5 Max MacBook Pro：安装 mlx-vlm>=0.6.17，只需下载 2bit-lite/（约 102 GB），用以下命令提高有线内存上限 sudo sysctl iogpu.wired_limit_mb=114688，然后运行 mlx_vlm.generate——适用于问答、短文本和图像。需要接受的是：在此精度下，长代码生成不可靠；目前还没有测得的笔记本吞吐量；128 GB Mac 是下限而非标准配置。如果上述任何一点让你无法接受——或者你的 Mac 低于 128 GB——同一模型的全精度版本只需在 z-ai/glm-5.3-flash 上调用一次 API 即可获得。

没有 128 GB 的 Mac？z-ai/glm-5.3-flash在 OrcaRouter 上以全精度提供相同的模型 —— 一个 API 密钥，提供商定价以 0% 加价直接传递，无需 102 GB 下载。