strata-mlx 更新：・被其他请求打断的长对话不再重复读取。对于 10,000 token 的对话，下一轮输出首个字符的时间从 19.7 秒降至 0.26 秒（M4 Max，需要添加 --conversation-cache-mib）・基于用户在 32 GB Mac 上的真实测试，默认为 macOS 保留更多内存，不再触发交换（paging）・M5 上的 float32 恢复为精确计算我仍需要更多不同配置的 Mac 设备进行测试。欢迎下载试用，并向我提交 Issues。http://github.com/yibie/strata-mlx

yibie/strata-mlx

来源：https://github.com/yibie/strata-mlx

strata-mlx

Qwen3.8-Flash-Next on Apple Silicon：一个 MLX 引擎，读取 Strata（https://github.com/Niko1221/Strata）使用的 GGUF 文件，并使用 Strata 的行协议（line protocol）通信，因此 Strata 的服务器和网页可以驱动它。

这是一个独立的、非官方项目。它与 Strata 及其作者无关，后者已表示 macOS 不在 Strata 本身的范围内。这是实验性的，仅在一台机器上运行过。

它是什么

Strata 通过将大部分专家权重保留在主机内存中，在一块 12 GB 显卡上运行一个 125B 参数的混合专家模型。而具有统一内存的 Mac 不需要那一半的技巧。本引擎承接另一半：

• 文件原封不动。 GSQ-RCO GGUF 文件加载时不改变任何一个权重。专家保留在文件自身的块中，共九种块类型，Metal 内核直接从这些块进行矩阵乘法。28.8 GB 的 n-gram 表保留在磁盘上。
• 草稿与验证。 模型自带的草稿头（draft head）猜测下一个 token，模型本体进行一遍验证。最终写入的每个 token 都由模型决定。
• 提示词（Prompt）。 分块读取，专家在 Apple 的着色器矩阵乘积中一块一块地处理。一次对话只读取一遍：后续追问只读取新增部分，新对话从与上一次共享的系统提示词之后开始，并且对话可以保存和恢复。加上 --conversation-cache-mib 后，被其他请求打断的对话会被暂存到内存中再取回，而不需要重新读取。
• 长对话，实测上下文达 128K token。
• 内存占用小于模型体积。 装不下的专家权重在 token 需要时从 SSD 读取，而 MLX 通常会以两倍大小持有的密集张量仍以文件块形式保留，为专家权重留出更多空间。
• Strata 的行协议，通过 stdin 和 stdout 通信（strata_mlx/serve.py）。

实测数据

M4 Max，128 GB，macOS 27，MLX 0.32.3。贪心解码。所有数字均来自这一台机器，该机器在持续负载下会变慢，请将其视为范围值。两个模型文件分别为 Q2_0（66.4 GB）和 IQ3_S（83.6 GB）。回答的生成速度比 llama.cpp 或 LM Studio 快 1.6 至 2.9 倍，长提示词的读取速度快 4% 至 36%。

生成回答，在四个 256 token 的提示词上的 token/秒（越高越好）：

读取提示词，1,180 token，token/秒（越高越好）：

关闭草稿头后，引擎仍会在答案重复对话中较早出现的内容时复制之前的猜测；完全不做猜测、每次只处理一个 token 的速度为 46-48 tok/s（Q2_0）和 41-43（IQ3_S）。

这两张表未能体现的两件事，均记录在 ISSUES.md 中：几十个 token 的短提示词读取速度比 llama.cpp 慢（首个 token 约 0.6 秒对 0.3 秒）；此外本引擎的读取速度数据取自比其他引擎更晚的会话。Ollama 0.35.1 无法加载任何一个文件。

在默认的 16 位浮点精度下，大约每 250 个 token 中有一个不是精确模型会选出的，出现在两个候选几乎持平的位置；开启和关闭草稿头时都是如此。--dtype float32 输出精确模型选择的 token（已在八个回答上验证），但速度更慢。

在 M5 上，MLX 默认情况下 float32 矩阵乘法的精度仅与 float16 相当，因此 --dtype float32 和测试会关闭该优化（MLX_ENABLE_TF32=0）；开启该设置后测试在 M5 上通过，且模型尚未在该模式下运行过 float32（issue 5（https://github.com/yibie/strata-mlx/issues/5））。

在部分专家保留在内存、其余存于 SSD 的情况下（在同一台机器上限制内存以模拟较小内存的机器），仅 Q2_0：内存中保留 3.3 GB 专家权重时，回答速度为 11-12 tok/s；保留 11.9 GB 时为 18-27；保留 20.5 GB 时为 23-38。1,180 token 的提示词读取速度为 107-145 tok/s，因为提示词的一个分块需要从磁盘读取 26 至 30 GB 的专家权重（issue 4（https://github.com/yibie/strata-mlx/issues/4））。

以上数据是引擎为 macOS 保留 4.2 GB 内存时，16 GB、24 GB 和 32 GB 机器分别能保留的专家权重量。一台真实的 32 GB Mac（MacBook Air M5）在保留 20.5 GB 时发生交换，回答速度为 6-19 tok/s；保留 16 GB 时为 23-29（issue 6（https://github.com/yibie/strata-mlx/issues/6））。

因此引擎现在为 macOS 保留 7.9 GB 内存，这样 32 GB 机器可以保留 16 GB 专家权重，上述三个数字尚未在此设置下重新测量。

完整记录（包括尝试过但无效的方案）见 ROADMAP.md（英文，按时间顺序）和 docs/OPTIMIZATION_RECORD.md（中文，按主题组织）。

哪种 Mac

--check 不加载任何内容，只显示一台 Mac 在每个文件上的运行情况。在下载任何文件之前即可使用，也可用于非运行设备的 Mac：

./strata-mlx --check # 本机 Mac
./strata-mlx --check --machine-memory 48 # 48 GB 内存的 Mac
./strata-mlx --check --native # 磁盘上的文件，根据其自身头部信息

与引擎启动时使用的相同算法：

“全部”（Whole）对应实测数据中的速度路径，测试设备为 M4 Max；其他芯片尚未测试。当只有部分专家权重在内存中时，其余部分在 token 需要时从 SSD 读取，即上文提到的慢速路径。IQ3_S 完全未以这种方式运行过。

这张表是算法推算，不是测试结果：作者运行过本引擎的唯一一台 Mac 内存为 128 GB。引擎为 macOS 及其他程序保留 7.9 GB，且不计算对话本身的内存，约 36,000 token 约需 1 GB。该数字来自目前唯一有报告的小内存 Mac——32 GB 的 MacBook Air M5：当为 macOS 保留 4.2 GB 时发生交换；按现在表格中的设置，几乎未发生交换，速度约为两倍（issue 6（https://github.com/yibie/strata-mlx/issues/6））。

其他内存大小尚不清楚：16 GB 的 Mac 可能需要比这里更少的保留量，可以用 --expert-memory GB 手动设置专家权重的份额。

运行

需要一台 Apple Silicon Mac、Python 3.12 或 3.13 以及 uv。仅在 macOS 27 上测试过；提示词内核使用 Metal 4 的 Metal Performance Primitives。

git clone https://github.com/yibie/strata-mlx && cd strata-mlx
uv sync
uv run pytest # 256 个测试，无需模型文件

模型文件，Q2_0 约 66 GB：从 ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF（https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF）下载同一大小的两个分片，放在同一文件夹中。Q2_0 和 IQ3_S 已测试过；其他大小在加载器中有路径但未测试。

草稿头不在这些文件中。其 31 个张量、4.9 GB，通过范围请求（range request）从原始检查点中获取，无需下载完整的 360 GB，每个张量都经过 SHA-256 校验。该脚本是 Strata 自带的，在此处未做修改，位于 tools 目录中（与 Strata 中相同）：

python tools/mtp_fetch.py fetch --out ~/.cache/strata-mlx/mtp # 可断点续传

没有草稿头引擎也能运行，速度即上文“关闭草稿头“的数值。

./strata-mlx --serve --native --mtp ~/.cache/strata-mlx/mtp

之后进程使用 Strata 的行协议通信：打印 INFO ... 和 READY，接收 GEN ,,... 并以 T 行和 DONE 行作为回答。提示词是 token id；分词、聊天模板和 HTTP API 由 Strata 的服务器负责。Strata 的 serve/server.py（0.1.40）在未做修改的情况下驱动了本引擎，将配置中的 exe 设为 strata-mlx 脚本，将上述选项放入 args；Strata 的 setup.py 无法在 macOS 上运行，因此该配置是手动编写的。

选项：--spec 1（关闭草稿头），--dtype float32，--max-context N，--expert-memory GB（在内存中保留多少专家权重；默认情况下若机器能装下模型则全部保留），--machine-memory GiB（按该大小的机器运行），--guess-rows off，--expert-profile off，--conversation-cache-mib MiB（将被其他请求打断的对话暂存在该大小的内存中；默认关闭，在无法完整装下模型的 Mac 上该内存从专家权重份额中扣除）。

bench/ 中的基准测试使用 llama.cpp 的 llama-tokenize 进行分词，bench/compare_servers.py 会在安装了 llama-server 和 LM Studio 的 lms 时自动启动它们。

尚未支持

图片输入、多对话并行解码，以及 Q2_0 和 IQ3_S 以外的文件格式。对话缓存使用 16 位浮点（128K token 时为 3.9 GB）。本项目尚未在内存小于 128 GB 的 Mac 上运行过。

许可证

MIT，详见 LICENSE。下文提到的项目各有自己的许可证；从 Strata 取用的唯一文件 tools/mtp_fetch.py 属于 Strata，保留 Strata 的 MIT 许可证，位于该文件旁边。

致谢

• Strata（MIT）：本项目遵循的设计、行协议、采样器顺序、查找式草稿器（lookup drafter）的思路、对话中保留哪些检查点以及如何暂存对话——所有这些在此处为 MLX 全部重写；以及其获取草稿头的脚本，原样包含。
• llama.cpp 和 ggml（MIT）：GGUF 格式和块类型，此处的内核按照其解包逻辑实现；码本（codebook）表在运行时来自其 gguf 包。
• MLX 和 mlx-lm（MIT），以及 mlx-lm 中移植本模型的 pull request 1788，本引擎在此基础上构建并固定依赖。
• ISTA-DASLab 提供 GSQ-RCO 文件，Qwen 提供模型。模型权重有自己的许可证，不属于本仓库。

yibie（@yibie）： 公开我最近的项目：strata-mlx

Strata 非常棒：它能在一块 12 GB 的显卡上跑 125B 参数的混合专家模型 Qwen3.8-Flash-Next。但它的作者说过，macOS 不在支持范围内。

我还是想让它跑在 Mac 上。

所以我花了一天半，写了 strata-mlx。它是一个非官方的 MLX 引擎，借鉴 strata 的设计，直接读 Strata