隔空叫板 DeepSeek V4：榜首分数背后，Ornith-1.5 的差评比好评先到

8 月 19 日，DeepReinforce 一口气放出 Ornith-1.5 系列三档开源模型（9B、35B-A3B、397B），次日即被 DoNews、网易等媒体集体刷屏："自我改进循环""397B 性能对标 Claude Opus 4.8""9B 量化版能塞进 iPhone 17"几个关键词直冲热搜。而在社区传播中，最抓眼球的一句话是——Ornith-1.5 叫板 DeepSeek V4。与此同时，本地部署圈却传来另一批声音：MLX 版乱码、长代码推理死循环、128GB DDR4 跑 35B 烧内存条……好评与差评几乎同一天抵达。本文基于官方模型卡（本仓库即其 GGUF 镜像）与社区一手实测，把"榜首分数"和"真实差距"拆开来看。

叫板 DeepSeek V4 的分数依据

先看官方口径。仓库内的 README.md 模型卡给出了 35B-A3B 在 17 项编码 / 推理 / Agentic 基准上的完整结果，所有分数均为 5 次独立运行取平均：

• Terminal-Bench 2.1（Terminus-2）：67.8，直接压过同尺寸 Qwen3.6-35B-A3B 的 52.5，也高于 Qwen3.5-397B 的 53.5；
• SWE-bench Verified：79.0——不仅碾压 Qwen3.6-35B-A3B 的 73.4，还反超总参数 397B 的 Qwen3.5-397B（76.4），这正是"小身板干翻大块头"叙事的来源；
• SWE-bench Pro：59.6（同尺寸竞品仅 49.5 / 51.6），Multilingual：71.4（vs 67.2 / 69.3）；
• DeepSWE：22，而对比组 Qwen3.6-35B-A3B 与 Qwen3.5-397B 均为 0——这是拉开差距最夸张的一项；
• Frontier-Bench v0.1：5.1，对比组普遍只有 1.4；
• GPQA Diamond：89.2，超过 397B 的 88.4。

更值得注意的是训练方法。README 开篇即点明：Ornith-1.5 把 1.0 时代的"脚手架优化 + rollout 优化"，扩展为联合优化任务生成、脚手架构建与解法 rollout——模型不再依赖人工筛好的固定题目，而是持续生成新任务、自己搭验证环境、再用强化学习改策略。36Kr 对此的概括是"AI 自己出题自己练，两个月狂涨 11%"。宣传口径里"叫板 DeepSeek V4"的底气，正是建立在这些数字与"端到端自我改进"的范式叙事之上。

社区争议点逐条盘点

但仔细看分数，事情确实没那么简单——社区争议恰恰都集中在"这些分数怎么来的、能不能复现"上。

争议一：榜单分数依赖"定制化评估流程"。README 脚注写得很直白：复现 Terminal-Bench 2.1 需要修改 Qwen chat template保证训练与推理一致性，还要修改 Harbor 框架以对齐 vLLM 的reasoning_contentkey；SWE-bench 系列则用 OpenHands harness 并施加"防作弊"（移除 git 历史、禁用网络）。并非说流程不严谨，而是这些分数是"在特定 harness + 特定模板改造"下测得的厂商口径。模型发布不到一天，第三方独立复现尚未跟上，社区横评文章标题直接发问："9B 打 35B，是实力还是数据游戏？"

争议二：MLX 量化版实测翻车。有博主在 M 系 Mac（64GB 统一内存）上先走 MLX 路线，加载后输出"中英韩文混排的多语言碎片乱码"：换 /v1/completions 绕过模板依旧、9B 与 35B 双双中招、升到最新 mlx-lm 0.31.3 仍复现，最终判定疑似 4-bit scales 转换问题。这是本地部署圈传播最广的差评之一。而同一台机器切到 Ollama 加载 GGUF（llama.cpp Metal 后端）后立刻恢复正常，还能带视觉投影看图。

争议三：量化档位与榜单分数不是一回事。那篇 Mac 实测里漂亮的 57.6 tok/s，来自Q4_K_M 量化版，而官方榜单全部是 BF16 结果。README 明确建议以temperature=1.0复现跑分，通用任务则推荐 0.6——也就是说本地 Q4 档位的真实体感，不应直接对标模型卡数字。另有 9B 实测暴露长代码场景短板：超过 80 行的长代码生成频繁陷入推理死循环，32K 以上上下文速度暴跌至 22 tok/s。

争议四："自我进化"被普遍误读。不少读者以为"部署后模型会越用越强"。实际上官方定义的自我改进发生在训练阶段，发布后权重即固定，本地部署并不会继续进化。这一误读几乎出现在每篇快评的评论区，官方文档也需专门澄清。

争议五：硬件门槛与内存风险。35B-A3B bf16 约 70GB，跑满 256K 上下文官方推荐 2×80GB 显卡；而社区里有人用 128GB DDR4 纯内存跑 35B，90 分钟烧坏一根内存条、9 天后第二根告急——MoE 虽只激活约 3B 参数，但整权重的搬运压力全落在硬件上。本仓库提供 BF16 与 Q4_K_M / Q5_K_M / Q6_K / Q8_0 五档 GGUF 及 mmproj-Ornith-1.5-35B-BF16.gguf 视觉投影，正是为缓解这一矛盾而配。

榜单之外，真实场景的差距在哪

回到最实用的层面：榜单之外，Ornith-1.5 与主流模型的真实差距，集中体现在"通用能力 vs 编码专精"与"量化折损"两条线上。

社区在 16GB 显存环境下对 Ornith 35B 与 Qwen 35B 做过多轮实测，结论高度一致：Ornith 强在代码生成与推理速度（HumanEval 78.5% vs 76.2%，推理 18.2 t/s vs 16.8 t/s），Qwen 在中文理解、文化任务与工程实践贴合度上更优；有评测者甚至指出 Ornith 生成的代码"算法更标准，但 Qwen 更贴近工程实践"。这与模型定位相符——Ornith-1.5 是终端型 agentic 编码模型，中文通用对话并非其主战场，把"叫板 DeepSeek V4"理解为全能力对标并不成立。

量化折损同样不可回避。Mac 实测中 57.6 tok/s 的速度来自 Q4_K_M，而官方跑分基于 BF16；README 也提示开源运行时（vLLM / SGLang）的 YaRN 是静态缩放——普通长度输入开着会轻微掉质量，长窗口才值得开启。对开发者而言，合理姿势是：先用 Ollama / llama-server 加载本仓库 Q4_K_M 验证体感（llama-server -hf ornith-ai/Ornith-1.5-35B-A3B-GGUF --port 8000 -c 262144），确需长上下文或生产并发再上 vLLM / SGLang 与 BF16。

结论：Ornith-1.5-35B-A3B 的榜首分数货真价实地存在于模型卡中，SWE-bench Verified 79.0 与 DeepSWE 22 的领先尤其具有含金量；但"叫板 DeepSeek V4"的宣传热度，明显跑在了第三方复现与本地实机验证之前。MLX 乱码、长代码死循环、量化折损、模板改造式评估——这些差评并非抹黑，而是把"榜单"与"体感"之间那段真实距离摊开给你看。对于自托管与 agentic 编码场景，它值得一试；至于"全面超越"的叙事，不妨等第三方独立评测与更多长链路实测落地后再下结论。