6月26日，X上一位叫 Berry Xia 的用户发了一条推文。没有发布会直播，没有CEO站台，没有精心剪辑的宣传片。推文里就一个名字：Ornith-1.0。四个模型，从小到大排列整齐，全部MIT协议开源。
这条推文在开发者圈子里炸开了锅——因为评测数据实在太过扎眼：35B参数的混合专家模型，在编程基准测试中越级击败了参数量十倍于它的Qwen 3.5-397B；而最大的397B MoE版本，Terminal-bench得分78.2，直接超过了Claude Opus 4.7（69.7分）。
一个没有大厂背书的开源模型家族，凭什么能把Anthropic的旗舰模型和阿里云的巨型参数模型按在桌上？这篇文章拆解Ornith-1.0的技术底牌，并给出一份不废话的部署和使用指南。
四个模型，从笔记本到服务器全覆盖
Ornith-1.0不是一个模型，是一个家族。DeepReinforce团队（由李纪为领衔）一口气放出四个版本：
| 版本 | 架构 | 参数量 | 推荐硬件 |
|---|---|---|---|
| Ornith-1.0-9B | Dense | 9B | MacBook Pro / 单GPU |
| Ornith-1.0-31B | Dense | 31B | 单GPU（24GB显存） |
| Ornith-1.0-35B | MoE | 35B（活跃参数约9B） | 单GPU（16GB显存） |
| Ornith-1.0-397B | MoE | 397B（活跃参数约70B） | 多GPU集群 |
9B Dense适合个人开发者本地跑，31B Dense是性价比甜点，35B MoE是单GPU部署的杀手锏——后面会详细说这个版本为什么值得关注，397B MoE则是打榜用的旗舰。
所有模型基于Gemma 4和Qwen 3.5预训练基座，通过强化学习后训练，训练框架叫”自改进”（Self-Improvement）——模型不仅学习生成代码解决方案，还学习驱动这些解决方案的脚手架框架。联合优化框架和方案，让模型找到更优的搜索路径，生成更高质量的代码。
MIT协议意味着你可以商用、修改、分发，没有任何附加限制。这在编程模型领域并不常见——很多”开源”模型用的是Apache 2.0或自定义协议，商用条款各有各的限制。
评测数据：35B打穿397B，397B超过Claude旗舰
Ornith-1.0的评测数据是它最大的卖点。先看Terminal-bench 2.1（终端编程能力基准测试）：
| 模型 | Terminal-bench 2.1 分数 |
|---|---|
| Ornith-1.0-397B MoE | 78.2 |
| Claude Opus 4.7 | 69.7 |
| Ornith-1.0-35B MoE | 62.8 |
| Qwen 3.6-35B | 49.2 |
| Qwen 3.5-397B | 48.6 |
397B版本78.2分，比Claude Opus 4.7高了8.5分。35B版本62.8分，超过了参数量11倍于它的Qwen 3.5-397B（48.6分）和同档的Qwen 3.6-35B（49.2分）。
再看SWE-bench（软件工程基准测试，衡量模型修复真实GitHubBug的能力）：
| 模型 | SWE-bench 分数 |
|---|---|
| Ornith-1.0-9B Dense | 69.4 |
| Gemma 4-31B | 52.0 |
9B的Dense模型在SWE-bench上拿到69.4分，比参数量3倍于它的Gemma 4-31B（52分）高出17.4分。
这些数字背后的含义很清楚：Ornith-1.0的训练方法（联合优化框架与方案的自改进强化学习）确实在编程任务上找到了更有效的路径，不是靠堆参数取胜。
35B MoE：单GPU上的编程杀手
如果你只有一块GPU，35B MoE版本是最值得关注的选择。
MoE（Mixture of Experts）架构的核心思路是：模型虽然有35B总参数，但每次推理只激活约9B参数——不同的输入会路由到不同的”专家子网络”。这意味着推理时需要的显存和计算量远小于一个35B的Dense模型。
实际部署中，35B MoE在16GB显存的单GPU上就能跑起来，推理速度接近9B Dense模型，但编程能力远超同参数量的Dense架构。62.8分的Terminal-bench成绩，意味着它处理终端编程任务的能力已经接近很多闭源模型的中档水平。
对于没有大算力集群的个人开发者和小团队，这个版本的性价比几乎是无敌的——一块中档GPU，就能跑出一个能处理真实编程任务的模型，而不是只能写Hello World的玩具。
怎么部署：三种方式从简到繁
方式一：Ollama 本地部署（最简单）
如果你已经装了Ollama，部署Ornith-1.0只需要两步：
# 1. 拉取模型（以35B MoE为例）
ollama pull ornith-1.0-35b
# 2. 启动对话
ollama run ornith-1.0-35b9B版本同理，ollama pull ornith-1.0-9b即可。Ollama会自动处理量化、显存分配和推理优化，Mac用户还能享受MLX加速。
不过注意，Ollama上的模型是量化版本（4-bit Q4_K_M），性能会比原始权重略有下降。如果你的GPU显存够大，建议用方式二的原始权重部署。
方式二：vLLM 原始权重部署（性能最优）
如果你有一块24GB显存以上的GPU（比如RTX 4090或A100），可以直接用vLLM跑原始权重：
# 1. 从HuggingFace下载模型
pip install huggingface_hub
huggingface-cli download deepreinforce-ai/Ornith-1.0-35B --local-dir ./ornith-35b
# 2. 安装vLLM
pip install vllm
# 3. 启动推理服务
python -m vllm.entrypoints.openai.api_server \
--model ./ornith-35b \
--tensor-parallel-size 1 \
--max-model-len 8192 \
--port 8000启动后你就能得到一个兼容OpenAI API格式的本地推理服务，任何支持OpenAI API的客户端（包括AI编程助手）都能直接对接。
方式三：HuggingFace Transformers 直接加载（适合调试和定制）
如果你需要深度定制模型行为（比如修改推理参数、加入自定义工具调用）：
from transformers import AutoModelForCausalLM, AutoTokenizer
model_name = "deepreinforce-ai/Ornith-1.0-9B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
model_name,
torch_dtype="auto",
device_map="auto"
)
prompt = "Write a Python function to find the longest increasing subsequence in a list."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=512)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))
9B版本在MacBook Pro上就能跑，不需要GPU。
实操：把Ornith接入你的编程工作流
光部署模型还不够，关键是怎么用它干活。以下是三个实际场景的用法：
场景一：搭配Continue.dev做本地编程助手
Continue.dev是一个开源的IDE编程助手插件，支持VS Code和JetBrains。它可以连接任何兼容OpenAI API的推理服务——正好接上你用vLLM部署的Ornith-1.0。
# 1. 安装Continue插件（VS Code扩展商店搜索"Continue"）
# 2. 在~/.continue/config.json中配置配置文件中设置模型提供商为OpenAI兼容格式，baseURL指向你vLLM服务的地址（比如http://localhost:8000/v1），模型名称设为Ornith-1.0-35B。
配置完成后，VS Code里的Tab补全、Cmd+K内联编辑、Chat对话，全部走本地Ornith推理，不花一分钱token费。
场景二：用Ornith做代码审查和Bug修复
Ornith-1.0在SWE-bench上表现优秀，说明它擅长处理真实代码仓库中的Bug修复场景。实际用法：
# 把Ornith作为OpenAI兼容API启动后
# 用任何AI编程工具（如aider、Codex CLI等）对接
# aider示例
aider --model openai/ornith-1.0-35b \
--openai-api-base http://localhost:8000/v1 \
--openai-api-key dummy
# 然后在aider中：
# "Read the bug report in issues/42.md and fix the code"Ornith的SWE-bench能力意味着它不只是写代码——它能读懂Bug报告、定位问题代码、生成修复方案。配合工程化编程工具，你就有了一个本地化的代码修复助手。
场景三：批量代码生成和重构
对于需要批量处理代码的场景（比如统一代码风格、批量添加类型注解、重构遗留代码），可以用Ornith配合脚本：
import openai
client = openai.OpenAI(
base_url="http://localhost:8000/v1",
api_key="dummy"
)
# 批量给Python文件添加类型注解
files = ["src/api.py", "src/models.py", "src/utils.py"]
for file_path in files:
with open(file_path) as f:
code = f.read()
response = client.chat.completions.create(
model="Ornith-1.0-35B",
messages=[
{"role": "system", "content": "Add type annotations to Python code. Preserve all existing logic."},
{"role": "user", "content": f"Add type annotations:\n\n{code}"}
]
)
with open(file_path, 'w') as f:
f.write(response.choices[0].message.content)全程本地推理，不需要担心代码泄露到云端。
和闭源模型比，Ornith缺什么？
公平地说，Ornith-1.0不是万能的。它和Claude Code、Codex这类闭源编程助手相比，有几个明显的短板：
没有内置工具调用链：Claude Code能自动调用Git、文件系统、Shell命令，Ornitch本身只是个语言模型，工具调用能力需要你自己搭。
没有长上下文：Ornith的上下文窗口和基座模型一致（Gemma 4是128K，Qwen 3.5系列支持更长），但实际编程任务中处理大型代码库时，你可能需要自己做上下文管理——比如用Claude Code的/fork策略那样的分治思路。
生态刚起步：模型刚发布一天，社区工具、插件、微调脚本都还没有。比起成熟的开源编程模型（如DeepSeek Coder、Qwen Coder），Ornith的生态配套需要时间积累。
但它的优势也很明确：MIT协议、参数覆盖全、35B单GPU杀手版本、评测成绩硬核。如果你在寻找一个能在本地跑、能商用、编程能力足够硬的开源模型，Ornith-1.0是目前最值得试的选择。
下一步：去试一下
Ornith-1.0全系列模型权重在HuggingFace上可直接下载（搜索deepreinforce-ai/Ornith-1.0-*），MIT协议，零门槛。
最推荐的起步路径：先用Ollama拉9B版本，在你的笔记本上跑一轮对话，感受它的编程输出质量；如果满意，再考虑在GPU服务器上部署35B MoE版本做正式使用。
一条推文扔出来的模型，评测数据扎眼，MIT协议敞开，部署路径清晰。开发者的世界里，有时候最好的东西就是这么来的——没有发布会，没有大厂背书，代码和数字说话。
发表回复