Ornith-1 压力测试：35B 本地模型终于能胜任智能体任务了吗？

01Ornith-1从哪里来？

Ornith-1.0由DeepReinforce团队于2026年6月发布。这不是一个简单地标记为“编码”的通用会话模型。该系列使用Gemma 4和Qwen 3.5系列的模型专门针对智能体编程任务进行了后训练。

它的特殊性来自于它的训练方法。 DeepReinforce谈论self-scaffolding：在强化学习期间，模型不仅学习产生解决方案。它还学习改进指导该解决方案的结构：搜索策略、工作记忆、错误管理和工具编排。

简单来说，Ornith 不仅接受过回答问题的训练。它接受过训练，可以更好地组织解决问题的方法。这正是对代理的期望：观察、行动、验证、纠正和重复，直到实现结果。

02为什么该模型如此受欢迎？

首先引起我注意的是计数器Ollama。模型发布大约一个月后，官方页面显示下载量超过 303,000 个账户。截至撰写本文时，在 Hugging Face 上，七个官方存储库上显示的计数器总数超过 1100 万个。

必须谨慎解释这些数字。下载并不一定代表不同的人。单个用户可以检索多个变体，自动化系统还可以增加计数器。

尽管如此，他们还是表现出了真正的兴趣。 Ornith 来得正是时候：许多用户正在寻找一种模型，该模型不仅要编写独立的函数，而且实际上知道如何在项目中工作。

• 代理编码的明确专业化；
• 可在GGUF中访问本地变体；
• 上下文窗口宣布为 256K 代币；
• 易于理解的 MIT 许可证；
• 直接集成到Ollama；
• 9B 和 35B 尺寸的公布结果非常高。

03Ornith-1的不同变体

Ollama显示的大小是分布式量化文件的大小，而不是所需的总内存。上下文、KV 缓存、缓冲区和代理工具会增加大量消耗。

04模型发布方公布的结果

以下结果是DeepReinforce发表的结果。它们对于了解家庭情况很有用，但不能替代独立评估。基准测试还使用大型上下文和特定代理环境。

35B 特别有趣。根据出版商的数据，它在 Terminal-Bench 2.1 上获得 64.2，而 Qwen 3.6-35B 则为 52.5。在 SWE-bench Verified 上，差距更小：75.6 比 73.4。这证实了一个重要的想法：Ornith 似乎特别优化用于执行完整的智能体任务，而不仅仅是生成代码。

05我的测试环境

我的编程测试使用至少 64,000 个令牌的上下文。这一点是决定性的：Ollama本身建议代码代理最小为64K。增加上下文直接增加了内存消耗。

Ollama 分发的 Ornith 35B 模型重量已约为 21 GB。因此，在我的两个 RTX 3060 上，没有足够的 VRAM 来轻松容纳上下文、KV 缓存和缓冲区。部分工作通过 PCIe 总线传输溢出到 RAM 和 CPU。

ollama run ornith:35b

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

ollama ps

ollama launch codex

06测试 1：创建 Flappy Bird

我的第一个测试成为经典：要求模型创建一只 Flappy Bird。游戏简单易懂。一只小鸟会自动向前移动，玩家让它上升并必须避开管道。

这种类型的项目在公共数据、教程和 GitHub 示例中极为常见。最重要的是，它允许您快速检查代理是否知道如何创建多个文件、选择技术、启动程序并纠正可能的错误。

07测试 2：在两张 RTX 3060 上开发 C 语言计算器

对于第二次测试，我故意选择了一些不那么传统的东西：一个用 C 语言开发的计算器，具有受 Windows 3.1 启发的真正图形界面。

我不想用现代库用几行代码制作一个 Python 计算器。我想将模型推向更严格的环境：窗口管理、按钮、事件、本机编译和适应 macOS。

正是在这个时候，我的物质限制才显现出来。量化模型、64K 上下文和代理数据不再适合 24 GB 累积 VRAM。 Ollama 和 llama.cpp 在两个 GPU 和系统内存之间分配负载。

对于非专业读者来说，问题很简单：模型花费部分时间移动数据而不是计算。显卡不再在最佳条件下工作，并且生成率崩溃。

08对MacBook Pro M4进行相同的测试

我在配备 32 GB 统一内存的MacBook Pro M4 上再次进行了相同的练习。我关闭了所有应用程序，以便在Ollama留下尽可能多的内存。

Mac 炸了大约 35 分钟，GPU 使用率为 100%。第一个结果确实显示了类似计算器的界面，但按钮无法正常工作。

我向模型解释了问题。大约十分钟后，他编辑了项目，重新编译了应用程序，并在 macOS 上得到了一个可用的 C 语言计算器。

增益不仅仅来自额外的 8 GB。苹果的统一内存可以让CPU和GPU工作在同一个内存空间。这避免了系统 RAM 和多个专用显卡之间的某些传输。

09Codex、Ollama及智能体模式

我使用了两种方法来检查编排工具是否确实改变了结果。

第一个是推出 Codex，并以 Ollama 作为本地提供商。 Ollama 现在提供 ollama launch codex 命令，该命令将 Codex 配置为使用本地或远程模型。

第二个是通过从Ollama启动的命令行体验，具有真正的代理工具，能够读取文件、修改文件、发出命令并继续任务。所以我不是在谈论用ollama run获得的简单猫。

在我的设置中，第二种方法产生了最佳结果。它似乎更好地尊重模型的本机设置并更好地处理长时间会话。 Codex 连接到 Ollama API 有效，但在我的测试中利用可用上下文的效率较低。

10与GPT-5.6 SOL比较

然后，我要求 Codex（使用我的 Pro 订阅）和 GPT-5.6 SOL 用 C 创建相同的计算器。

不出所料，第一个结果来得更快，而且看起来更成功。有趣的是，该模型遇到了完全相同的问题：界面显示了，但无法正确点击按钮。

然而，云模型的诊断更为明确。它发现了 Mac 视网膜显示屏上比例和坐标处理的问题。第二次通过完成了申请。

这种比较从科学意义上来说是不公平的：模型、基础设施、量化和编排工具是不同的。最重要的是，它衡量用户通过可用的手段实际获得的内容。

11此测试实际显示了什么

这是一个愚蠢的测试，但这正是它有趣的原因。如果我要一个带有流行图形库的 Python 计算器，Ornith 可能会在大约十分钟内完成。

我的目标是摆脱最明显的路径，将模型置于边缘：C 语言、复古 GUI、原生 macOS 编译、事件处理和 Retina 缩放问题。

• 35B模型现在可以执行真正的本地智能体任务；
• 可用内存通常比理论参数数量更具决定性；
• 64K 上下文完全改变了硬件要求；
• 代理工具及其集成几乎与模型一样重要；
• 本地仍然比领先的云模型慢得多；
• 本地模型的进展速度足够快，足以涵盖新的用途。

即使在六个月前，我也无法想象使用这种尺寸的本地模型能够如此轻松地获得这种类型的结果。模型的权重仍然是决定性的，但培训、编排和专业化现在使得用更少的材料做更多的事情成为可能。

12对企业有何影响？

问题不再只是哪个是市场上最好的型号。真正的问题是每次使用需要什么级别的功率、隐私和成本。

DGX Spark 或同等机器具有 128 GB 统一系统内存。它不是传统意义上的 128 GB 专用 VRAM，但该架构提供了足够的空间来本地利用 24 GB 卡上不可能轻松容纳的模型和上下文。

还有中间选项。公司可以求助于像 Mistral 这样的法国公司（其 Le Chat 现已更名为 Vibe）、使用欧洲产品或在自己的基础设施上部署某些模型。它可以保留最强大的美国或中国模型来执行实际上证明曝光和成本合理的任务。

因此，我们必须停止将人工智能视为所有员工的统一许可证购买。公司必须试验、衡量和定义自己的服务水平。

为此，无需在 LinkedIn 上搜索带有虚构头衔的个人资料，该个人资料将自己描述为我们只使用了几年的技术的绝对专家。你必须从修补、测试、破坏、测量和重新开始开始。这仍然是了解真正可能的事情的最佳方式。

S来源和详细信息

• DeepReinforce — Ornith-1 的官方 GitHub 存储库
• DeepReinforce — self-scaffolding方法和基准的介绍
• 拥抱脸 — DeepReinforce 的官方模型和变体
• Ollama — Ornith 官方库，显示大小和下载
• Ollama — 有关上下文大小和内存消耗的文档
• Ollama — 与 Codex 正式集成
• Ollama — ollama 启动概述 命令
• NVIDIA — DGX Spark 官方规格
• Mistral — 公司介绍及其部署可能性

下载计数、变体可用性和运行时性能可能会快速变化。所显示的值对应于撰写本文时可见的信息。