Ornith-1.5 对位 DeepSeek V4：‘叫板‘的底气到底有几分

Ornith-1.5 对位 DeepSeek V4：'叫板'的底气到底有几分

【免费下载链接】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 叫板 DeepSeek V4"。这句话不是空穴来风——翻开官方基准表，DeepSeek-V4-Flash-0731 (284B)赫然出现在对比栏里，而且 Ornith 全线领先。但"叫板"二字，在自媒体标题里是一句爽话，在工程语境里却是一笔需要逐项核算的账：对位的是 V4 全系还是 V4 Flash？35B-A3B 这张"小卡"凭什么参与这场对局？量化部署的成本账怎么算？本文基于官方 benchmark 数据、社区一手实测与本仓库（Ornith-1.5-35B-A3B-GGUF）的实际文件，把这场"叫板"拆开来看。

一、"叫板"的出处：官方表格里的正面交锋

先看结论：Ornith 确实主动把 DeepSeek V4 写进了自己的对比名单。在官方技术博客的完整评测表中，Ornith-1.5-397B 与 DeepSeek-V4-Flash-0731（总参数 284B）在全部十六项编码、推理、智能体基准上逐项对位且无一落后，核心数据如下：

但这句"叫板"需要两个括号。其一，对手是V4 Flash——DeepSeek 体系里的轻量档（284B MoE），并非 V4 全系最重的那档；其二，官方同时拉上了 Claude Opus 4.8 作为参照系：Terminal-Bench 2.1 为 86.1 vs 85.0、SWE-bench Verified 为 86 vs 85.8，Ornith 占优，但在 DeepSWE 上 56 vs 59、Frontier-Bench 上 13.5 vs 21.1，Ornith 仍落后于闭源旗舰。所以更严谨的表述是：Ornith-1.5-397B 在开源阵营里把"对位 DeepSeek V4 Flash"这件事做实了，但对闭源天花板还差半步。

二、35B-A3B：社区真正拿来"对位"的是谁

自媒体标题把"叫板"的流量引到了 35B-A3B 上，但翻开源仓库 README.md 的基准表会发现，35B 规格的官方对照组里根本没有 DeepSeek V4——它的对手是 Qwen3.6-35B-A3B、Gemma-4-31B（稠密）、Muse-Glimmer-30B（稠密），以及作为"跨级参照"的 Qwen3.5-397B：

这张图说明了一个更戏剧性的事实：每 token 只激活约 3B 参数的模型，打穿了同体量的稠密模型，甚至逼近并反超了 397B 级旗舰。看几个关键点：

• 编码全面压制同规格对手：Terminal-Bench 2.1 (Terminus-2) 67.8，而 Qwen3.6-35B-A3B 只有 52.5、Gemma-4-31B 只有 42.1；SWE-bench Verified 79.0，高于 Qwen3.6-35B-A3B 的 73.4，也高于 Qwen3.5-397B 的 76.4。
• DeepSWE 上直接清零式碾压：22 分对 Ornith-1.0 的 0、Qwen3.6 的 0、Qwen3.5-397B 的 1——这是官方表里最悬殊的一栏，也最能体现"自我改进循环"在真实软件工程任务上的积累（评估基于 Claude Code harness 与 256K 上下文窗口）。
• 但并非全胜：HLE（无工具）25.6，低于 Qwen3.5-397B 的 28.7；BrowseComp 67.6 对 78.6、WideSearch 67.8 对 74，说明在长程检索与纯推理上，"3B 大脑"与 397B 仍有代差；MCP-Atlas 上还落后于稠密的 Muse-Glimmer-30B（75.5）。

所以，社区那句"叫板 DeepSeek V4，但仔细看分数，事情没那么简单"并非标题党——35B 规格真正对位的不是 DeepSeek V4，而是"小显存能否扛起 agentic 工作负载"这个命题，这才是它引发实测热潮的根本原因。

三、架构与部署成本：12G 显存对服务器集群

"35B 总参数、每 token 仅激活约 3B"是 Ornith-1.5-35B-A3B 的立身之本，型号里的 A3B 即指激活量。社区博主给出的比喻很贴切：35B 是"编制"，3B 是"现役上岗"——专家网络平日闲置，推理时按需路由，这让它的部署成本断崖式低于同参数量的稠密模型，更远低于 284B 的 DeepSeek V4 Flash。

官方对 35B 规格的定位是明确的：bf16 全精度约 70GB 权重，README 给出的标准部署方案是2×80GB GPU起，为 256K 上下文留出余量：

vllm serve ornith-ai/Ornith-1.5-35B-A3B \ --served-model-name Ornith-1.5-35B-A3B \ --tensor-parallel-size 2 \ --max-model-len 262144 \ --enable-auto-tool-choice --tool-call-parser qwen3_xml \ --reasoning-parser qwen3

而本仓库提供的 GGUF 量化阶梯，把这条门槛进一步拉到了消费级硬件：Ornith-1.5-35B-Q4_K_M.gguf 约 21.7GB、Ornith-1.5-35B-Q8_0.gguf、Ornith-1.5-35B-Q6_K.gguf、Ornith-1.5-35B-Q5_K_M.gguf 直到 Ornith-1.5-35B-BF16.gguf（约 71GB）的全谱系，另附 mmproj-Ornith-1.5-35B-BF16.gguf 视觉投影权重，为多模态输入留好通道。README 给出一条一行式启动命令：

llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144

社区实测验证了这条路径的可行性：一张4070Ti（12G 显存）+ 32G 内存，用 llama.cpp 的 llama-server 加载 Q4_K_M，核心三招——--n-cpu-moe 24把 24 个专家offload到内存、KV cache 量化到 q8_0（--cache-type-k q8_0 --cache-type-v q8_0）、照抄官方采样参数（--temp 0.6 --top-p 0.95 --top-k 20）——即可在170K 上下文下稳定跑到约 60 token/s，日常改 bug、读代码、跑草稿完全够用。博主还提醒两个坑：必须开--jinja（否则 think 块会裸奔出模板）和--reasoning on（让思维链与正文分离返回）。若需求超越 256K，README 提供了 YaRN 静态扩展方案，把rope_scaling（rope_type: "yarn"、factor: 4.0）写进 config.json 后窗口可拉至约 1M——但官方明确提示静态缩放会轻微损伤短输入质量，属于"不到万不得已别开"的选项。

对比之下，DeepSeek V4 Flash 是 284B 量级的 MoE，其部署面是服务器集群与云 API；Ornith-1.5-35B-A3B 的差异化叙事则非常清晰：把 agentic 编码能力装进一张游戏卡。这也是抖音、CSDN 上"小显存部署大模型的新答案"这类标题批量出现的原因。

四、开源生态话语权：站上 Qwen 肩膀，还是自成一体

"叫板"最深的看点在训练范式。Ornith-1.0 本身就是基于 Qwen3.5 与 Gemma 4 做持续预训练（CPT）、中期训练与后训练而来——它选择了站在开源底座上再进化，而非从零自研架构；到了 Ornith-1.5，自我改进循环被升级为完整闭环：模型自己出题（task generation）、自己搭评测脚手架（scaffold construction）、自己生成解（solution rollouts），再用 GRPO 联合优化三阶段，任务奖励被分解为有效性与可验证性 × 前沿难度 × 新颖度的乘积形式（R_task = V × D × N），其中前沿难度以模型自身 rollout 的成功率逼近目标值 p*=0.2 来衡量——模型越强，旧任务自动贬值，出题器被迫转向更难的新题。

这与 DeepSeek 的自研路线（独立架构 + 弹性算力基建）构成了开源生态里两种截然相反的哲学：一边是用海量真实代码库"投喂"静态分布，一边是让模型在动态自生成的课程里持续推高自己的能力前沿。后者在 DeepSWE（22 vs 0/1）这类需要真实工程操作的基准上立竿见影，也解释了为什么 Ornith 的每次发布都能引发一波"自己给自己出题"的讨论热。

生态层面的实证同样密集：发布当日，知乎出现"开源即王炸"的实测长文，CSDN 迅速跟进部署教程与 16G 显存横向测评，抖音博主用"跑起来像 3B、脑子接近 27B 稠密模型"来定性；而 GGUF 镜像仓库（即本仓库）第一时间铺开五档量化权重——量化链路的完善速度，本身就是开源话语权的硬指标。与此同时，README 中 Ollama、llama.cpp、Atomic.chat、Hermes、OpenClaw、OpenCode 等 agent 框架的开箱即用适配，意味着它已经悄然进入本地 agent 工作流的标准候选名单。

结语：底气有几分，账要分开算

把三层证据叠起来，"叫板"的成色可以这样结算：

• 分数账：397B 对 DeepSeek V4 Flash 全项占优，有官方数据背书；但对标闭源 Opus 4.8 仍有 DeepSWE、Frontier-Bench 的短板，且对手只是 Flash 档，谈不上"掀翻 V4"。
• 成本账：35B-A3B 真正的底气是"3B 激活 + 量化后 12G 显存可跑"，在 170K 上下文下维持 60 token/s——这是 284B 的 V4 Flash 给不了的消费级体验。
• 范式账：最值得关注的不是某一栏分数，而是"模型自我进化"这条新路线正式从论文走入开源生态。当模型开始给自己出题、自己搭考场，"模型 vs 模型"的对比终将升级为"训练范式 vs 训练范式"的对比——那时，"叫板 DeepSeek V4"的叙事会显得相当次要。

对开发者而言，结论反而简单：想在本地、在消费级显卡上跑一个能进终端干活、能拆任务、能调工具的 agentic 模型，Ornith-1.5-35B-A3B 的 GGUF 量化版本是目前性价比最高的选项之一；至于"叫板"谁，让分数表去说话，让 benchmark 条件去较真。

【免费下载链接】Ornith-1.5-35B-A3B-GGUF项目地址: https://ai.gitcode.com/hf_mirrors/ornith-ai/Ornith-1.5-35B-A3B-GGUF