5 分钟跑起来：Ornith-1.5 量化版在 Mac 上的 MLX 与 Metal 部署实测

2026 年 8 月 19 日，DeepReinforce 正式发布 Ornith-1.5 系列开源模型，IT 之家等媒体在次日跟进报道：最大的 397B MoE 模型部分性能超过 Claude Opus 4.8，9B-Mobile 量化版甚至能跑进 iPhone 17；而在社区里，抖音、CSDN 上"Ornith-1.5-35B-A3B 完整实测""小显存部署大模型的新答案"等内容迅速铺开。真正让本地玩家兴奋的，是这代家族的"中间尺寸"成员——35B-A3B：总参数 35B，但每次推理只激活约 3B 参数，量化后最小权重仅 21.7GB，意味着 24~32GB 统一内存的 Mac 就能把一个大模型完整装进内存。

本文基于 Ornith-1.5-35B-A3B-GGUF 仓库（内含五个量化档位与多模态投影文件），把 Mac 上的两条部署路径讲透：GGUF 走 Metal 加速的 Ollama / llama.cpp 系运行时，一行命令即可拉起；同时给出 MLX 社区版（mlx-lm / mlx-vlm）的环境搭建边界、采样参数配置，以及按内存档位选型的完整实测指南。

一、35B-A3B 为什么值得在 Mac 上跑

先看模型卡（README.md）给出的关键事实：Ornith-1.5-35B-A3B 是 Ornith-1.5 家族中的 MoE 成员，bf16 全精度权重约 70GB，但每个 token 只激活约 3B 参数。正是这种稀疏激活设计，让 35B 级的模型拥有了"端侧可及"的权重体积。

它的基准表现（README 基准表，五轮运行取平均）与同尺寸竞品对比相当醒目：

三处值得注意：其一，在所有编码与 Agentic 基准上全面压制同尺寸的 Qwen3.6-35B-A3B；其二，DeepSWE 一项直接给出 22 分对 0 分（对比模型全部挂零）；其三，相比稠密的 Gemma-4-31B 与 Muse-Glimmer-30B，Agentic 编码优势是"wide margins"级别。

另外两个部署前必须知道的特性（README 明确标注）：

• 它是推理模型：助手回复默认以<think>…</think>思维链块开头，OpenAI 兼容服务端通过 reasoning parser 把思维链单独放进reasoning_content字段；
• 推荐采样参数：通用任务temperature=0.6, top_p=0.95, top_k=20；复现官方基准则用temperature=1.0。

二、仓库拆解：五档 GGUF 与多模态投影

仓库根目录下是五个量化档位 + 一个多模态投影文件（Git LFS 指针中标明的真实体积）：

这里要先厘清一个容易踩坑的生态边界：GGUF 是 llama.cpp 生态的格式，它在 Mac 上由 Ollama、llama.cpp（llama-server）、LM Studio、LLMFarm 等运行时直接加载，这些运行时全部走 Apple Silicon 的 Metal 加速；而MLX 生态（mlx-lm / mlx-vlm）原生吃的是 safetensors 格式权重，社区里已有多篇 Ornith 部署手册验证过 mlx-vlm 路径（依赖安装、config.json / generation_config.json 参数解析、Metal 加速、内存优化），但那是针对 Ornith-1.0-9B 的 MLX 格式权重。因此本文的部署主线是 GGUF 仓库对应的 Metal 系运行时，MLX 社区版作为并行路径单列一节。

三、MLX 社区版环境搭建

如果你手头是 MLX 格式的 Ornith 权重（或打算自行转换），环境搭建非常轻量——MLX 社区版就是两个 pip 包：mlx-lm（纯文本 LLM）与mlx-vlm（多模态）：

# 建议独立虚拟环境，避免污染系统 Python python3 -m venv .venv && source .venv/bin/activate # MLX 社区版：文本 + 多模态 pip install -U mlx-lm mlx-vlm # 验证安装 python -c "import mlx, mlx_lm; print(mlx.__version__)"

搭建要点（来自社区 MLX 部署手册的共性经验）：

1. 运行环境：Apple Silicon Mac（M 系列芯片）是 MLX 的主战场，Linux 下 MLX 也能跑但会退化为 CPU 路径，Metal 加速红利消失；
2. 模型获取：MLX 权重需从mlx-community空间拉取（safetensors 格式），拉取后务必做完整性校验，社区手册明确建议核对文件 hash；
3. 参数文件：MLX 加载依赖config.json与generation_config.json，其中max_position_embeddings、rope_scaling、eos_token_id等字段直接决定上下文上限与停止生成行为，改参数前先读这两个文件；
4. 内存优化：mlx-vlm 支持分块加载与低精度推理，16GB 统一内存的 Mac Mini 已被社区验证可跑 Ornith-1.0-9B 级模型。

需要说明的边界：Ornith-1.5-35B-A3B 是 MoE 新架构（GQA + 稀疏专家路由），MLX 运行时对它的支持程度以官方发布为准；对 35B-A3B-GGUF 仓库而言，Ollama / llama.cpp 是当前风险最低、速度最快的路径。

四、模型仓库拉取与参数配置（5 分钟清单）

GGUF 仓库最大的便利是免手动下载：README 的 Agentic Usage 一节给出了开箱即用的拉取命令，Ollama 与 llama.cpp 都会自动从 Hugging Face 拉取对应文件。

路径 A：Ollama（最快，一条命令）

ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF

首次执行会自动下载模型（选 Q4_K_M 档约 21.7GB，取决于网速），之后即进入交互式聊天。装 Ollama 只需brew install ollama一行。

路径 B：llama.cpp（OpenAI 兼容 API + 工具调用）

# 提供 OpenAI 兼容接口，端口 8000 llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

这是 README 给出的标准命令。随后任何 OpenAI 兼容客户端（Python SDK、curl、OpenCode、Hermes Agent、OpenClaw）都能直接对接——README 里给出了 Hermes / OpenClaw 的环境变量模板（OPENAI_BASE_URL=http://localhost:8000/v1、OPENAI_API_KEY=EMPTY），以及注册 OpenCode provider 的完整 JSON 配置。这意味着你可以把本地 Ornith 直接挂进终端编码工作流，而不只是聊天。

路径 C：LM Studio（图形界面）

不想碰命令行的话，LM Studio 导入 GGUF 文件即可，界面里可直接调整 GPU offload 层数与上下文长度。

必须改的两个参数

• 上下文长度-c：llama.cpp 会在启动时按-c值预分配 KV cache，262144 token 的全量分配在 35B 级模型上会让 KV cache 膨胀到几十 GB 量级，24/32GB 的 Mac 会直接启动失败。日常编码与问答建议先降到-c 8192或-c 16384，需要长文档再按需上调；
• 采样参数：按 README 推荐设置temperature=0.6 / top_p=0.95 / top_k=20，追求 benchmark 复现则把温度拉到 1.0。

进阶玩法是长上下文扩展：README 给出了 YaRN 方案——在config.json中注入rope_scaling（rope_type: yarn, factor: 4.0, original_max_position_embeddings: 262144），即可把窗口扩到约 100 万 token。但官方特别提示：开源运行时对 YaRN 是静态缩放，会轻微损害普通长度输入的生成质量，只有真实需要超长窗口时才开启，且factor应匹配实际需求（目标窗口 ≈ factor × 262144）。

五、Metal 加速下的速度与内存实测

内存：权重 + KV cache 两层账

内存占用 = 模型权重 + KV cache + 计算缓冲。权重账已在上表列出，KV cache 随上下文线性增长，粗略公式为2 × 层数 × KV 头数 × 头维度 × 序列长度 × 2 字节——这正是上面反复强调"先降-c"的原因。按目标 Mac 选档的经验结论：

• 24GB 统一内存：Q4_K_M，上下文控制在 8~16K，日常 agentic 编码够用；
• 32GB：Q5_K_M / Q6_K 都能舒服跑，16~32K 上下文有富余；
• 48GB：Q8_0 档，接近 BF16 质量且保留长上下文余量；
• 96GB 以上：直接上 BF16，复现官方全部基准。

速度：MoE 稀疏激活是 Mac 上最大的红利

速度的判断依据是架构而非营销话术：decode 阶段每 token 只激活约 3B 参数，单 token 的前向计算量约等于一个 3B 级稠密模型，瓶颈从"算力"转移到了"统一内存带宽"——这正是 Apple Silicon 的强项（M 系列统一内存带宽 100~400GB/s 量级，远高于同价位独立显存）。

社区在 NVIDIA 平台的公开对照数据可作为量级参照：RTX 4080 16G 显存、Q4 量化下，Ornith 35B 实测约 18.2 token/s，同环境 Qwen 35B 为 16.8 token/s（CSDN 社区实测摘要）。Mac 上由于 3B 激活 + Metal 的高带宽利用，Q4_K_M 档位在 M 系列上的吞吐通常落在每秒数十 token区间——但请以本机实测为准，不要盲信任何"跑分截图"。

自测方法很简单，三条路任选：

# 方式一：llama.cpp 自带基准工具 llama-bench -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF -m 0 -ngl 999 # 方式二：服务端实测，向 /v1/chat/completions 发流式请求并计时 curl http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"Ornith-1.5-35B-A3B","messages":[{"role":"user","content":"count from 1 to 100"}],"stream":true,"temperature":0.6}'

两点辩证提醒：

1. MoE 在低并发下不吃亏也不占便宜：专家路由本身有调度开销，35B-A3B 的优势是"权重体积小、可装进 24GB 内存"，而非单 token 绝对延迟碾压稠密 3B 模型；
2. 速度数字随-c和量化档位漂移：KV cache 越大、上下文越长，Memory-bound 特征越明显，Q4 与 Q8 的吞吐差距往往小于体积差距——这也是"先上 Q4 跑起来，再按需升级"的策略依据。

多模态：别忘了那个 0.9GB 的 mmproj

仓库里的mmproj-Ornith-1.5-35B-BF16.gguf是视觉投影权重（约 0.9GB），配合主模型可做图像理解。用 llama.cpp 加载时通过--mmproj指定该文件即可，文本与视觉共用同一套服务端口。对多模态有需求的读者，这是 GGUF 路径上成本最低的加分项。

结语

把 35B 模型装进 24GB 内存的 Mac、5 分钟跑起来，这在两年前还是"性能妥协"的代名词；而 35B-A3B 用 MoE 稀疏激活 + GGUF 量化把这道选择题变成了纯粹的内存预算题：Q4_K_M 起步，32GB 内存上 Q5/Q6，追求满血再上 Q8 与 BF16。对终端编码 Agent 而言，一条ollama run或llama-server命令拉起本地 Ornith，再通过 OpenAI 兼容接口接进 OpenCode / Hermes / OpenClaw，就已经拥有了一个不依赖云端的 35B 级"自改进"编码搭档——隐私留在本机，性能对标云端，这是 2026 年本地大模型最值得做的事之一。