Ornith 1.0 九B模型本地实测：塔防游戏暴露小模型编程瓶颈

一款专为智能体编程而生的开源模型

近期，旧金山公司 Deep Reinforce 发布了 Ornith 1.0 开源模型系列，主打「智能体编程」（agentic coding）能力。所谓「智能体编程」，是指AI模型不仅能生成代码片段，还能像人类开发者一样自主规划多步骤任务、调用工具、读取文件系统、执行终端命令，并根据反馈迭代修正——与传统「代码补全」的本质区别在于自主性和闭环能力，模型需要在没有人类逐步介入的情况下，完成从理解需求到交付可运行产物的完整链路。

智能体编程脱胎于「AI Agent」框架的兴起。传统大语言模型以单轮问答为主，而 Agent 模式引入了「ReAct」（Reasoning + Acting）范式——模型在推理链中穿插工具调用，形成「思考→动作→观察→再思考」的循环。这一范式由谷歌和普林斯顿研究者于 2022 年正式提出，此后迅速成为代码 Agent 的标准架构。在工程实现层面，ReAct循环将模型输出结构化为「Thought/Action/Observation」三段式格式，工具调用结果（Observation）会被拼接回提示词，形成不断增长的上下文——一个典型的代码Agent任务可能需要在单次会话中处理数十次工具调用，上下文累积量轻松突破数万tokens。这也意味着工具调用的格式稳定性（即模型能否始终输出可解析的JSON/函数调用格式）成为工程落地的核心挑战，是后文9B模型暴露出「tool call格式损坏」问题的深层根源。当前主流智能体编程工具（如 Claude Code、Cursor、GitHub Copilot Workspace）均基于此循环，差异在于工具集的丰富程度与上下文管理策略。

系列包含四种规模：9B 稠密模型、31B 稠密模型、35B MoE 模型，以及 397B MoE 模型。这里有必要说明两类架构的区别：「稠密模型」（Dense Model）在每次推理时会激活全部参数，计算量与参数量成正比；「MoE」（Mixture of Experts，混合专家模型）则通过门控机制每次只激活一部分「专家」子网络，使模型在拥有极大总参数量的同时，实际推理开销远小于同规模稠密模型——397B MoE 的实际计算成本，可能仅相当于数十B规模的稠密模型。

混合专家架构并非新概念，最早可追溯至 1991 年 Jacobs 等人的论文，但真正在 LLM 领域引发关注是 Mistral 于 2023 年底发布的 Mixtral 8x7B。MoE 的核心挑战在于「专家负载均衡」——若门控网络反复激活同几位专家而冷落其他专家，训练会退化。实践中通常引入辅助损失函数（auxiliary loss）强制均衡。此外，MoE 在批量推理时的效率优势显著，但单请求延迟并不总优于稠密模型，因为专家分布在不同内存位置，存在内存访问碎片化问题。

其中 9B、35B 和 397B 三个版本均为开放权重（open weight），用户可直接下载在本地设备上运行；31B 版本目前尚未发布。值得注意的是，「开放权重」与「开源」在业界是两个不同概念——开放权重仅指模型参数文件可公开下载，但训练数据、训练代码乃至商业使用条款可能受限。用户在商业部署前，需仔细核查对应许可证条款。

根据发布论文，Ornith 1.0 构建在预训练的 Gemma 4 和 Qwen 3.5 之上——前者被认为是当前智能体任务完成能力最强的模型之一，后者是本地 AI 编程模型中的代表性选手。这种「站在巨人肩膀上」的技术路线，让 Ornith 1.0 一经发布便备受关注。

本文聚焦于最小的 9B 稠密模型，在一台仅有 16GB 内存的 M4 Mac mini 上测试其真实编程能力。

基准测试的可信度与局限

论文中给出了三张性能评测图表，分别对应 397B、35B MoE 和 9B 模型。厂商宣称 35B MoE 模型能够超越 Qwen 3.6 35B——这是相当大胆的声明。

但任何理性的开发者都明白：最可靠的评测，永远是用自己的硬件跑自己的真实用例。 官方数字很难直接映射到日常开发体验。

这里有一个值得所有人注意的关键区分。Terminal Bench 2.1、SWE Bench Verified/Pro 等主流基准测试，考察的并非「从零构建完整应用」的能力。SWE-Bench 由普林斯顿 NLP 团队于 2023 年提出，从 GitHub 上抓取了 2294 个真实 Issue-PR 对，覆盖 Django、Flask、Scikit-learn 等 12 个主流 Python 项目；核心任务是给定真实开源项目的 Issue 描述，让模型在完整代码库上定位并修复 Bug，通过单元测试验证结果。Terminal Bench 则侧重评估模型在终端环境下完成多步骤任务的能力。值得注意的是，批评者指出 SWE-Bench 存在数据污染风险（测试项目均为公开代码库，可能出现在训练集中），以及「通过测试≠正确修复」的评估偏差——这也是 SWE-Bench Verified 和 Pro 版本相继引入人工筛选与更严格沙箱隔离的原因。两者测试的是「修复」而非「创造」，具体场景包括：

• 在既有框架（harness）中运行：能否正确执行工具调用，在终端完成各类任务；
• 在陌生代码库中修复 Bug：给定从未见过的代码库和一个 Bug，能否读懂代码、定位并修复问题。

这两类能力都有价值，但与「从头写一个完整程序」本质不同。而「从零构建」，恰恰是大多数独立开发者最渴望的能力，也是本次实测的核心目标。

16GB Mac mini 上的本地部署实测

测试设备：M4 Mac mini，16GB 内存。预留约 4GB 给操作系统和录屏，模型实际可用约 12GB。运行工具选用免费桌面应用 LM Studio。

LM Studio 中的 Ornith 9B 提供 MLX 和 GGUF 两种格式。MLX 是 Apple 专为 Apple Silicon（M 系列芯片）设计的机器学习框架，其性能优势根植于 Apple Silicon 的统一内存架构（Unified Memory Architecture，UMA）——M系列芯片将CPU、GPU、神经网络引擎（ANE）共享同一内存池，带宽可达200-400 GB/s以上，远超传统x86架构中CPU内存与GPU显存之间约16-64 GB/s的PCIe总线带宽。MLX针对这一架构设计了懒惰求值和统一内存操作原语，使模型权重无需在CPU与加速器之间复制，在预填充（prefill）阶段表现尤为出色；GGUF（GPT-Generated Unified Format）则是 llama.cpp 生态的通用量化格式，跨平台兼容性更强，适合 Windows、Linux 等异构环境。本次测试选用了通用性更强的 GGUF 格式。

上下文长度表现相当亮眼：模型权重约占 6.2GB，12GB 内存预算内可支持约 186,000 tokens 的上下文——相比之下，此前测试 Gemma 4 12B 时，同等内存限制下仅能达到约 70,000 tokens。这一差距主要源于 KV 缓存的内存占用差异。KV 缓存（Key-Value Cache）是 Transformer 推理的核心优化机制——在自回归生成中将已计算的注意力矩阵缓存复用，但代价是随上下文增长而线性膨胀的内存消耗。从工程角度量化这一差异：KV 缓存的内存占用公式为「2 × 层数 × 头数 × 头维度 × 序列长度 × 精度字节数」，典型 9B 模型每 1000 个 token 约消耗约 32MB KV 缓存，186K 上下文意味着约 6GB 专用于缓存。

Ornith 9B 能以较小参数量支持如此长的上下文，暗示其在架构层面做了针对性优化——最关键的技术是分组查询注意力（Grouped Query Attention，GQA）。标准多头注意力中每个注意力头都拥有独立的KV投影矩阵；GQA将Query头分成若干组，同组共享一对KV头，在大幅压缩KV缓存（通常降低4-8倍）的同时保持接近标准注意力的模型质量——这正是Ornith 9B能以12GB内存支持186K tokens的底层原因。若启用 Flash Attention（一种通过分块计算将内存从 O(n²) 降至 O(n) 的算法优化）并将 KV 缓存量化至 Q8，甚至可以在仅 10.29GB 占用下开满全部上下文窗口。

实测生成速度约为 16 tokens/秒（前一天基准测试可达约 18 tokens/秒，差异可能源于其他应用占用内存导致降频）。短消息场景下 MLX 与 GGUF 速度相近，但随着上下文增大，MLX 的优势会逐渐凸显——这正是UMA高带宽在长序列KV缓存读取时的优势所在。

塔防游戏对决：9B vs 35B

为验证「智能体编程」的实际表现，本次设计了一个真实任务：用单个 HTML 文件从零构建一个塔防游戏（Tower Defense）。同样的任务此前用 Qwen 3.6 35B 测试时，曾在四分钟内一次成型。

开发环境：VS Code 编辑器 + PyAgent 智能体框架。作者坦言更偏爱 Claude Code，但在小模型 + 低内存设备的组合下，Claude Code 等待时间过长，PyAgent 响应更快、更实用。

为形成对照，作者通过 LM Studio 的 LM Link 功能，从另一台 Mac Studio 上远程调用了 Ornith 35B（4-bit MLX）。两台设备速度差距悬殊：9B 约 16 tokens/秒，35B 高达约 100 tokens/秒，快出整整五倍。当然，这并非严格的同配置对比。

9B 的结果：能跑，但无法游玩

9B 模型生成了约 900 行 HTML，代码量与 35B 的 750 行相当。但打开浏览器后，结果令人失望——游戏界面几乎无法交互：防御塔不会射击，敌人也不正常行进。随后尝试让 9B 自行调试这份代码，模型陷入反复循环，越改越糟。

35B 的结果：迭代后产出可玩游戏

35B 模型的表现明显更好。本次录制时遇到一点小问题（前一天用同样提示词曾一次成型），但在补充说明「防御塔不射击」后，经过几轮迭代，最终产出了真正可玩的塔防游戏：弓箭手、加农炮、冰霜法师、狙击手四种防御单位均可正常射击、消耗金币、推进波次。画面虽然朴素，但逻辑完整、玩法成立。

核心结论：小模型的「精度」瓶颈

这次对比测试清晰揭示了小参数模型在代码生成场景下的本质短板。作者的总结一针见血：

使用 9B 模型做编程任务时，要么降低预期，要么缩小工作范围。

35B 模型具备完成高质量工作的容量（capacity），而 9B 模型的问题并非「不够聪明」——它的推理过程读起来其实相当有条理——而是精度不足，具体表现为：

• 创建了函数却忘记声明；
• 生成空函数体；
• 工具调用（tool call）格式损坏，导致 PyAgent 无法解析模型意图；
• 变量拼写错误、定义后从不调用的函数。

这一现象在 Scaling Law 研究中有深刻的理论根源。Kaplan 等人于 2020 年在 OpenAI 提出的神经缩放定律（Neural Scaling Laws）描述了模型损失与参数量、数据量、计算量之间的幂律关系，此后 DeepMind 的 Chinchilla 研究（2022年）进一步修正，指出在计算量固定的前提下增大数据量比单纯堆参数更高效。在代码生成领域，研究者发现存在明显的能力「相变」（phase transition）现象——某些推理密集型任务（如多文件依赖追踪、跨函数状态一致性验证）在模型参数突破特定规模前几乎无法完成，超过阈值后能力突然跃升，而非平滑提升。研究表明代码的「语法正确率」与「语义正确率」随参数增长的提升速率截然不同——语法错误在数十亿参数时已基本消除，但语义级别的「局部正确、全局不一致」错误需要更大模型才能显著改善。

这背后的直觉是：全局一致性要求模型在生成第 N 行代码时，仍能精确「记住」前 N-1 行引入的所有约束——变量名、函数签名、调用关系构成一张动态增长的依赖图，而追踪这张依赖图的能力与模型的有效记忆容量（即参数量）直接相关，9B到35B之间恰好跨越了「局部代码生成」与「全局一致性维护」之间的关键能力阈值。代码生成任务中「把应用各部分缝合在一起」的收尾工作，9B 级别本地模型难以胜任的根本原因正在于此。你可能没注意到，这并非 Ornith 独有的问题，Qwen 等其他同规模模型同样存在类似困境——这是参数规模带来的普遍性限制。

写在最后

Ornith 1.0 是一次有诚意的开源模型发布：186K tokens 超长上下文、对 Apple 芯片友好的 MLX 支持，以及基于 Gemma 4 与 Qwen 3.5 的技术路线，都值得肯定。

但对于想在轻量本地硬件上「一句话生成完整应用」的用户，9B 模型目前仍难以胜任从零构建的需求。它更适合的场景，是在既有框架中执行边界清晰的小任务，或配合精细的提示工程处理有限范围的工作。想要获得真正可用产出的开发者，仍需要 31B 及以上规模的模型。

本地大模型的边界正在快速扩展，但「参数换精度」的规律，短期内依然成立。