16G 显存实测:Ornith 35B vs Qwen 35B,代码能打但中文呢?
【免费下载链接】Ornith-1.5-35B-A3B-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-35B-A3B-GGUF
2026 年 8 月,DeepReinforce 发布 Ornith-1.5 系列开源模型,其中 Ornith-1.5-35B-A3B 以"35B 总参数、每 token 仅激活约 3B 参数"的 MoE 架构切入中端市场,官方模型卡给出的编码与 Agentic 基准全面压制同级 Qwen 3.6-35B-A3B。然而,当模型真正落到社区手里、跑进一块 16G 显存的 RTX 4080 时,结论开始变得微妙:代码任务它确实能打,但中文理解与文化任务却被 Qwen 反超。本文基于仓库模型卡、GGUF 量化文件与多篇社区实测,拆解这"一半领先、一半落后"背后的架构逻辑与部署取舍。
一、"35B 激活 3B":MoE 架构决定了它的能力半径
理解 Ornith-1.5-35B-A3B 之前,先看它的出身。模型卡(README.md)明确说明:Ornith-1.5 是在 Ornith-1.0(基于 Qwen3.5 与 Gemma4 继续预训练、中期训练与后训练而来)之上,把自我改进循环从 scaffold 与 rollout 优化,扩展到任务生成、scaffold 构建与解决方案 rollouts 的联合优化——不再依赖人工固定任务集,而是让模型持续生成更难的新任务、发现解法并经由强化学习改进策略。
这一训练目标直接塑造了模型的能力分布:模型卡列出的一组编码基准数据可以说明问题(下表为官方 5 次独立运行平均值):
| 基准 | Ornith-1.5-35B-A3B | Qwen3.6-35B-A3B | Ornith-1.0-35B-A3B |
|---|---|---|---|
| Terminal-Bench 2.1 (Terminus-2) | 67.8 | 52.5 | 64.2 |
| SWE-bench Verified | 79.0 | 73.4 | 75.6 |
| SWE-bench Pro | 59.6 | 49.5 | 50.4 |
| SWE-bench Multilingual | 71.4 | 67.2 | 69.3 |
| DeepSWE | 22.0 | 0.0 | 0.0 |
| Frontier-Bench v0.1 | 5.1 | 1.4 | 1.4 |
从 Ornith-1.0 到 1.5,自我改进循环的升级带来了肉眼可见的代际提升(SWE-bench Verified 75.6→79.0、DeepSWE 0→22、Frontier-Bench 1.4→5.1),同时与 Qwen3.6-35B-A3B 的差距几乎在每个编码基准上拉大到 5~15 分。官方发布的基准总览图如下:
值得注意的是推理侧的表现:GPQA Diamond 达到 89.2(高于 Qwen 3.6 的 86),HLE(无工具)25.6 也优于 Qwen 的 21.4。这说明它的强化学习训练并未完全牺牲推理能力。但"代码强、推理不弱"与"中文强"是两回事,后者恰恰是本文要追问的重点。
二、HumanEval 与代码生成:领先优势从哪里来
官方基准偏重 Agentic 场景,而社区更关心传统 HumanEval 这类"单题作答"。综合多篇 16G 显存实测文章(RTX 4080、4-bit 量化、Text Generation WebUI / vLLM 环境),可以得到一组一致的结论:
- HumanEval 分数:Ornith 35B 约78.5%,Qwen 35B 约76.2%,Ornith 领先约 2~3 个百分点;
- 推理速度:Ornith 约18.2 tokens/s,Qwen 约16.8 tokens/s,MoE 稀疏激活的优势在吞吐上兑现;
- 代码质量观感:社区实测对"算法正确率"打分时 Ornith 胜出(如 4/5 题正确),但多位作者同时指出:Qwen 生成的代码更贴近工程实践(补全、异常处理、命名习惯),Ornith 更"标准教科书化"——这是一条值得玩味的观察:benchmark 分数高不代表代码可直接落地,工程化习惯与生态调性仍是隐性成本。
分数领先的结构性原因并不难解释:Ornith 的训练数据与强化学习奖励几乎全部围绕"把任务做对"(终端操作、仓库级修复、工具调用)设计,HumanEval 这类"输入输出可验证"的题目正是其奖励函数最适配的形态;而 Qwen 作为通用底座,代码能力是"附带技能"而非"主修科目"。用 Agentic 基准(Terminal-Bench、SWE-bench Pro、NL2Repo 46.2 vs 29.4)衡量,Ornith 的领先优势更是被放大到接近一倍,这正是它被社区称作"单卡 Agent 编码之王"的底气。
三、中文理解与文化任务:Qwen 的主场反超
如果只看编码分数,结论似乎一边倒。但把测试范围扩大到中文任务,风向立刻变了:
- C-Eval(中文理解):社区实测中Qwen 明显领先,Ornith 在中文知识、成语/俗语理解类题目上失分明显;
- MMLU 综合知识:两者接近,但 Qwen 在人文社科子项上更稳;
- 多轮中文对话与混合任务:Qwen "更均衡",Ornith 在非编码类中文请求上偶有"任务理解偏差"——即模型倾向把问题往代码/工具调用方向带。
多篇独立实测文章给出了几乎一致的定性结论:"Ornith 强于代码任务,Qwen 优在中文与对话"。这并非玄学,而是训练分布的直接投射:Ornith-1.5 的自我改进循环生成的训练任务几乎全部落在软件工程领域,中文通用语料在持续预训练与 RL 阶段被持续压缩;而 Qwen 的底座本身在中文语料与对齐上投入极重。一个模型不可能在所有方向同时被强化,Ornith 把"能力预算"几乎全部花在了代码与 Agent 上——这是它代码能打的代价,也是中文落后的原因。
对国内开发者而言,这意味着一个现实困境:想让 Ornith 帮你读中文技术文档、写注释、做中文需求分析,它的表现大概率不如 Qwen;而一旦任务切换到"修 issue、改仓库、跑命令行",Qwen 又明显吃力。选模型前,先想清楚你的工作流是"中文语境下的工程"还是"纯代码任务"。
四、16G 显存下的部署性价比:Q4_K_M 几乎是唯一答案
抛开基准不谈,16G 显存这个约束条件本身才是大多数个人开发者真正面对的问题。看仓库里实际提供的 GGUF 文件(模型文件清单),量化档位从 4-bit 到全精度一应俱全,实际文件大小如下:
| 文件 | 实际大小 | 能否整载入 16G 显存 |
|---|---|---|
| Ornith-1.5-35B-BF16.gguf(全精度) | 71.07 GB | ✗ 需要约 2×80GB 双卡 |
| Ornith-1.5-35B-Q8_0.gguf | 37.80 GB | ✗ |
| Ornith-1.5-35B-Q6_K.gguf | 29.21 GB | ✗ |
| Ornith-1.5-35B-Q5_K_M.gguf | 25.35 GB | ✗ 勉强但无 KV 余量 |
| Ornith-1.5-35B-Q4_K_M.gguf | 21.71 GB | △ 需显存/内存混载或 KV Cache offload |
| mmproj-Ornith-1.5-35B-BF16.gguf(多模态投影) | 0.90 GB | 可选加载 |
这里有一个容易误解的点:Q4_K_M 的 21.71GB 依然超过 16G 显存。社区实测给出的显存占用数据(Ornith 13.2G / Qwen 12.8G)是在 vLLM/llama.cpp 的显存与内存混合 offload、以及 KV Cache 压缩策略下取得的结果——即"显存占用"与"模型文件大小"是两个概念,前者还包含 KV Cache 与 offload 调度。这也解释了为什么多篇实测文章一致推荐Q4_K_M 是 16GB 下的最佳平衡点:5-bit 以上无法给上下文留出余量,4-bit 以下(如 3-bit)精度损失开始侵蚀代码正确率。
部署层面,仓库模型卡给出的路径非常直接——GGUF 版本天生为 llama.cpp 系生态准备:
# llama.cpp / Atomic.chat:一条命令起 OpenAI 兼容服务 llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144 # Ollama:直接拉取 ollama run hf.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF值得注意两点:其一,Ornith-1.5-35B-A3B 是推理模型,默认输出带<think>推理块,llama.cpp/vLLM 均需启用 reasoning parser(vLLM 侧为--reasoning-parser qwen3),否则思维链会混入正文;其二,模型原生支持 262,144 tokens 上下文,配合模型卡提供的 YaRN 配置可扩展至约 1M tokens,但社区实测提醒:16G 显存下长上下文与量化精度是此消彼长的关系,4K 上下文场景 Qwen 的显存余量更足(12.8G vs 13.2G),256K 全开则需要 2×80GB 双卡级别的硬件——小显存用户请自觉把上下文压到 8K 以内。
五、结论:把"能打"和"能用"分开看
把官方数据与社区实测拼在一起,Ornith-1.5-35B-A3B 与 Qwen 35B 的画像其实非常清晰:
- 代码与 Agent 任务:Ornith 全面占优——HumanEval 领先约 2~3 分,SWE-bench 系列领先 5~10 分,推理速度还快约 10%。如果你的工作流是"喂仓库、改代码、跑命令",16G 显存下 Q4_K_M 档的 Ornith 是当前性价比最高的开源选择之一;
- 中文理解、文化任务与混合对话:Qwen 明显更稳——C-Eval 领先、多轮中文对话更自然、代码风格更贴近工程实践。对国内团队而言,中文需求分析、注释生成、文档解读这些高频场景,Qwen 反而是更务实的选择;
- 16G 显存是硬约束:无论选谁,Q4_K_M 几乎是唯一合理档位,且都需要显存/内存混载调度;若预算允许升到 24G 以上,Q5_K_M 或 Q6_K 的精度收益才开始显现。
一句话总结社区实测的共识:Ornith 是把"代码能力预算"花到极致的偏科生,Qwen 是语料与对齐均衡发展的优等生。在 16G 显存的消费级显卡上,没有"全都要"的选项——先确认你的主战场是写代码还是写中文,再决定让哪只鸟进笼子。若两者都要兼顾,最现实的方案是:Ornith 跑代码 Agent,Qwen 负责对话与文案,两块 16G 显卡各司其职,这或许是当前硬件约束下最合理的分工。
【免费下载链接】Ornith-1.5-35B-A3B-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-35B-A3B-GGUF
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考