近期開源 AI 圈迎來了一項引人注目的發布——由 DeepReinforce 推出的 Ornith-1.0 模型系列。這組專為 Agentic Coding（智慧體編碼）設計的開源模型，在發布後迅速成為社群討論的焦點。本文將從模型架構、基準測試表現、核心技術創新與部署可行性等面向，客觀分析 Ornith-1.0 的亮點與潛在價值。

模型背景與版本架構

Ornith-1.0 系列建立在 Gemma 4 與 Qwen 3.5 的預訓練模型之上，共推出四個參數量版本：

模型版本架構類型適用場景
Ornith-1.0-9BDense（稠密）邊緣裝置、IDE 整合
Ornith-1.0-31BDense（稠密）均衡效能與資源
Ornith-1.0-35B MoEMoE（混合專家）本地部署首選
Ornith-1.0-397B MoEMoE（混合專家）旗艦級雲端部署

其中，397B MoE 是本次發布的旗艦模型，僅有 17B 的活躍參數（active parameters）。而 35B MoE 版本則被視為「甜蜜點」——參數量遠低於旗艦版，但在多項編碼基準測試中卻能逼近甚至超越 397B 大模型的表現。

所有模型均採用 MIT 授權協議，允許商業與研究用途，無任何額外限制。

基準測試表現

根據官方公布的數據，Ornith-1.0 在多個主流編碼智慧體基準測試中取得了亮眼的成績。以下整理主要結果：

旗艦版（397B MoE）

測試項目Ornith-1.0-397BClaude Opus 4.7Claude Opus 4.8
Terminal-Bench 2.177.570.385.0
SWE-Bench Verified82.480.887.6
SWE-Bench Pro62.2—69.2
SWE-Bench Multilingual78.9——
NL2Repo48.2——
ClawEval77.1——

在 Terminal-Bench 2.1 與 SWE-Bench Verified 兩項測試中，397B 版本超越了 Claude Opus 4.7，展現了開源模型在編碼智慧體任務上的競爭力。

小尺寸版本

模型Terminal-Bench 2.1SWE-Bench Verified
Ornith-1.0-9B43.169.4
Ornith-1.0-35B MoE64.4—
Qwen 3.5-397B53.5—

值得注意的是，35B MoE 版本在 Terminal-Bench 2.1 上以 64.4 分的成績超越了 Qwen 3.5-397B 的 53.5 分。這意味著僅有 35B 參數的模型，在編碼智慧體任務上的表現，超越了參數量接近其 11 倍的 Qwen 3.5-397B。

核心技術創新：自我支撐架構（Self-Scaffolding）

Ornith-1.0 最引人注目的技術突破，在於其 「Self-Scaffolding」 架構。

傳統編碼智慧體依賴人類手動設計的固定「 harness」（即模型調用工具、管理記憶體、組織執行流程的邏輯框架）。Ornith-1.0 則將這個 harness 本身視為一個可學習的物件，讓模型在強化學習過程中，同時優化「架構生成」與「解決方案生成」。

具體而言，訓練過程分為兩個階段：

  1. 階段一：模型根據任務提出一個優化後的 scaffold（執行架構）。
  2. 階段二：模型基於該 scaffold 生成解決方案。

兩個階段的獎勵會同時回傳，使模型能協同優化自身的組織邏輯與編碼能力。

這種「讓模型學會如何規劃自己的執行流程」的做法，被開發者稱為自動化智慧體策略（Automation of Agentic Strategy）。它跳過了傳統手動提示工程（Prompt Engineering）與框架設計的瓶頸，讓模型自主發現比人類設計的更高效的搜索路徑。

防作弊機制

為防止模型在基準測試中「作弊」（例如直接讀取測試答案），DeepReinforce 實施了三層防護：

  • 固定信任邊界：環境、工具表面與測試隔離層對模型策略不可變。
  • 確定性監控器：自動標記並懲罰模型讀取隱藏路徑等違規操作。
  • 凍結 LLM 法官：在驗證器之上增加一層最終否決機制，捕捉意圖級的作弊行為。

部署與使用方式

Ornith-1.0 提供了多種部署選項，涵蓋從雲端到本地消費級硬體：

雲端部署

模型支援 vLLM、SGLang 與 Transformers 三大框架，並提供 OpenAI 相容的 API 端點，方便與現有智慧體框架整合。

vllm serve deepreinforce-ai/Ornith-1.0-9B \
  --served-model-name Ornith-1.0-9B \
  --max-model-len 262144 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

本地部署

官方提供了 GGUF 量化格式（透過 Hugging Face 上的 Ornith-1.0-35B-GGUF 與 Ornith-1.0-9B-GGUF 集合），支援 Ollama 與 Unsloth 等本地推理工具。根據社群測試，35B MoE 的 Q4 量化版本約需 21GB 顯存，意味著擁有 24GB 或 48GB 顯存的消費級 GPU（如 RTX 3090/4090）即可流暢運行。

程式碼範例

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
resp = client.chat.completions.create(
    model="Ornith-1.0-9B",
    messages=[{"role": "user", "content": "Write a Python is_prime(n)."}],
    temperature=0.6,
    top_p=0.95,
)
msg = resp.choices[0].message
print(getattr(msg, "reasoning_content", None))  # 推理追蹤
print(msg.content)  # 最終答案

社群觀點與實測反饋

模型發布後，在 r/LocalLLaMA 等社群引發了熱烈討論。以下是從社群中提取的幾個主要觀點：

正面評價：

  • 多數開發者對 35B MoE 版本的「性價比」表示認可，認為它在本地部署可行性與編碼能力之間取得了良好的平衡。
  • 有開發者分享本地實測結果，表示在實際 Vibe Coding 工作流中，35B 版本的表現與 Qwen 3.6-35B 相當，但在某些特定編碼任務上展現出優勢。
  • GGUF 格式的提供被視為一大亮點，降低了本地部署的門檻。

謹慎觀點：

  • 部分社群成員指出，基準測試的表現不等於實際開發體驗。在真實的私有程式碼倉庫中，面對雜亂的依賴關係與未文件化的 API，模型的表現仍有待驗證。
  • 有開發者提到，目前仍需確認 chat template 是否正確配置，才能確保推理結果與訓練條件一致。
  • 針對 397B 旗艦版，社群認為其適合需要最高準確率的倉庫級任務，但對一般開發者而言，記憶體與運算成本偏高。

總結與展望

Ornith-1.0 的發布，標誌著開源編碼模型從「純參數量競爭」轉向「工作流優化」的新階段。其核心的 Self-Scaffolding 架構，讓模型不再只是被動地回答編碼問題，而是學會自主規劃執行流程、從失敗中恢復、並動態調整策略。

從實際應用角度來看：

  • 小型專案或邊緣部署：9B Dense 版本提供了在單張 GPU 上運行編碼智慧體的可行方案。
  • 本地開發者首選：35B MoE 版本在效能與硬體需求之間取得了最佳平衡，適合擁有 24GB+ 顯存的開發者本地部署。
  • 企業級任務：397B MoE 版本在 SWE-Bench 等基準上超越了 Claude Opus 4.7，適合需要處理大型程式碼倉庫的場景。

當然，作為一個剛發布的模型系列，Ornith-1.0 仍面臨一些挑戰：真實環境中的泛化能力、推理延遲與吞吐量的平衡、以及長期穩定性，都需要時間來驗證。但無論如何，這確實是開源編碼智慧體領域一個值得關注的進展。

- 廣告 -

參考資源