Ornith 9B实测：16GB Mac Mini能否胜任本地AI编码？

开源AI编程模型的新成员：Deep Reinforce Ornith 1.0

开源AI编程模型的赛道又添新成员。位于旧金山的Deep Reinforce公司发布了专为**智能体编码（agentic coding）**打造的开源模型家族——Ornith 1.0。

什么是智能体编码？ 传统AI编码助手（如早期Copilot）以「补全」为主，被动响应用户输入；而智能体编码模型则主动规划任务、调用工具（文件读写、终端命令、代码执行）、根据执行反馈自我修正，形成「思考→行动→观察」的循环。这要求模型具备更强的长程一致性、工具调用准确性与错误恢复能力，而非单纯的代码生成质量。代表性框架包括Claude Code、Cursor Agent、Devin等，本文所用的Pi Agent亦属此类。

本文基于一位B站UP主在16GB M4 Mac Mini上的亲测，深入探讨这一模型家族中最小的9B稠密模型，在本地环境下能否真正胜任日常编码任务。

Ornith 1.0：专为智能体编码设计的模型家族

Ornith 1.0并非单一模型，而是涵盖四种规格的完整家族：

• 9B稠密模型（本次测试主角）
• 31B稠密模型（暂未开放下载）
• 35B MoE模型
• 397B MoE模型

其中9B、35B和397B均为开放权重（open weight），可直接下载并在本地设备上运行。

稠密模型 vs MoE模型：稠密（Dense）模型的每个参数在每次前向传播时均参与计算，参数量即计算量；MoE（Mixture of Experts，混合专家）模型则将参数分组为多个「专家」网络，每次仅激活其中少数几个。这解释了为何397B MoE在本地硬件上仍可运行——其实际推理时激活参数量可能仅与较小稠密模型相当，算力需求远低于总参数量的直觉预期。MoE架构的代表还有Mixtral、DeepSeek-V3等。

在技术底座上，Ornith 1.0基于Gemma 4与Qwen 3.5构建。Gemma 4被认为是当前智能体任务完成能力最强的模型之一，Qwen系列则是本地AI编码领域的佼佼者。以两者为起点，理论上兼顾了任务执行与代码生成两方面的优势。

Benchmark数据怎么看？

官方给出了针对Terminal Bench 2.1、SWE Bench Verified/Pro以及CLAW Eval等多个基准的评测数据。从图表看，9B模型（橙色）与体量更大的31B、35B模型相比，差距似乎并不悬殊。

但这里有一个关键洞察值得注意：这些基准测试考察的能力维度并不相同。

• SWE Bench（由普林斯顿大学于2023年提出，从GitHub真实Issue中采样）考察模型能否读懂陌生代码库、定位bug并生成可通过测试的补丁——是衡量「修复存量代码」能力的黄金标准；
• Terminal Bench 考察模型能否在harness中运行、执行工具调用、在终端里完成任务；
• 而上述两者都不测试从零构建完整应用的能力。

这正是benchmark分布与真实开发者需求之间的显著错位。对普通开发者而言，「帮我从头做一个完整项目」才是最真实的需求。因此，最有价值的评测永远是用自己的硬件、跑自己的真实用例。

硬件与环境：16GB Mac Mini的部署实况

测试设备为搭载M4芯片的16GB Mac Mini。内存分配策略上，预留约4GB给操作系统与后台应用，其余约12GB留给模型。

运行工具选用免费桌面应用LM Studio。模型搜索中，Ornith 9B提供MLX和GGUF两种格式：

• MLX：Apple专为Apple Silicon设计的机器学习框架，充分利用M系列芯片统一内存架构（CPU与GPU共享同一内存池），避免了传统GPU推理中的数据搬运瓶颈，体积更小，在Apple Silicon上速度更快，尤其是prefill阶段；
• GGUF：llama.cpp项目主导的通用量化格式，跨平台兼容性更好，支持Windows/Linux/macOS多端部署，本次测试的选择。

加载完成后，6.2GB用于模型权重，最大上下文长度可达26万tokens。将上下文设为约18.5万tokens时，内存占用约12GB——对本地小模型而言相当出色。

进阶技巧：若希望压榨更长上下文，可开启Flash Attention并将KV cache量化到Q8。

Flash Attention与KV Cache量化：Flash Attention由Tri Dao等人于2022年提出，通过分块（tiling）技术将注意力矩阵的计算从高带宽内存移至更快的SRAM中完成，在长上下文场景下速度提升显著。KV Cache是Transformer推理的标准优化——缓存已计算的Key/Value矩阵，避免逐token重复计算，代价是随上下文增长占用大量内存。对KV Cache进行Q8量化（8-bit量化），可在精度损失极小的前提下将内存占用压缩约50%，使26万token的完整上下文窗口在16GB设备上成为可能。

在约10.29GB内存占用下即可跑满完整上下文窗口。最终，活动监视器显示内存占用刚过15GB，逼近16GB上限。简单请求下，GGUF版本的生成速度约为16 tokens/秒。

实战测试：9B vs 35B，从零构建塔防游戏

为验证「专为智能体编码优化」的宣称，测试设计了一个真实任务：用Pi Agent作为harness、VS Code作为编辑器，给出简单prompt——在单个HTML文件中构建一个塔防游戏。

选择Pi Agent而非Claude Code的原因很实际：小模型在小硬件上运行Claude Code等待时间过长，首个请求可能需要三四分钟，Pi Agent响应更快，实用性更强。

为形成对照，还通过LM Link功能从另一台Mac Studio调用Ornith 35B（4bit MLX）跑同一任务。速度差距立竿见影：

• 9B（16GB Mac Mini）：约16 tokens/秒
• 35B（Mac Studio）：约100 tokens/秒，快近5倍

结果对比：精度差异一目了然

35B模型生成了约750行代码，游戏基本可玩：弓箭手能射击敌人，有金币经济系统，运行流畅，能力上限清晰可见。

9B模型的表现则令人失望。生成近900行代码，但游戏几乎无法运行——单位不射击、逻辑混乱。更糟的是，用9B模型自我调试时，它陷入反复循环，越改越糟。

最终不得不采取妥协方案：以35B生成的可用代码为基础，喂给9B模型，经过四五轮迭代，才勉强「抢救」出一个能玩、但远不如35B原版精致的版本。

核心结论：小模型的精度天花板

这一问题并非Ornith独有，Qwen等其他开源小模型同样如此：

9B级别的模型精度不足——它们会创建函数却不声明、写出空函数，有时工具调用损坏导致Agent无法理解模型意图。

这一现象有其深层的架构根源：完整应用的构建需要模型在数千token的生成过程中同时维护数据结构的全局一致性、函数签名与调用点的精确对应、跨模块的状态管理逻辑。研究表明，模型处理长程依赖的能力与参数规模呈非线性关系——从9B到35B的参数增长，带来的「有效工作记忆」提升远超线性比例。这也是业界普遍观察到的现象：Qwen2.5-Coder-7B、DeepSeek-Coder-7B等同量级模型在类似任务中均表现出相似的「碎片化」问题，拼写错误、函数定义了却从不调用、代码结构无法自洽——这些细小缺陷累积起来，使得「在单次任务中维持一个应用的完整性」在9B参数下几乎不可能实现。

对于想在16GB Mac Mini上跑本地编码模型的开发者，这里有两条务实建议：

1. 降低预期——不要指望9B模型一次性构建完整应用；
2. 缩小任务粒度——将需求拆解成更小、更明确的单元再交给模型处理。

35B模型证明了Ornith架构本身具备产出优质代码的能力，问题纯粹在于9B参数带来的精度损耗。对于追求本地隐私与低成本推理的开发者来说，Ornith家族值得关注——但根据实际硬件理性选择参数规格，远比盲目相信benchmark数字更重要。