Qwen 3.8 vs Ornith 1.5:两款35B本地模型真实对比评测

Qwen 3.8与Ornith 1.5五天内相继发布,各有擅场:前者自主编程更强、显存更省,后者超长上下文速度占优。
阿里Qwen 3.8(27B稠密模型)与Deep Green Force Ornith 1.5(35B MoE模型)在五天内相继开源,共同瞄准消费级GPU用户。架构上两者走向相反:Ornith用MoE降低每Token计算量但全量显存常驻,Qwen用混合注意力(DeltaNet)压低KV缓存增长但每Token全量激活。实测中,Qwen在30道One-Shot编程题中以24/30远胜Ornith的15/30,在零引导生成GTA式3D游戏时一次通过,而Ornith需六轮迭代;但超长上下文下速度攻守逆转,Ornith越过16万Token仍维持45 Token/秒,Qwen则跌至约5 Token/秒。显存方面,Q4量化下Qwen仅需16-19G,Ornith需27G以上。当前Qwen拥有第三方独立验证(Artificial Analysis评分52),Ornith评测数据几乎全来自厂商自测,信任基础尚需积累。
五天两连发:本地模型圈的两强相撞
本地大模型圈五天内接连炸了两次。8月14日,阿里发布了稠密模型 Qwen 3.8(27B);仅隔五天,8月19日 Deep Green Force 跟上开源的 Ornith 1.5(35B)。两者都是开放权重,都瞄准了消费级显卡用户——换句话说,都冲着你机箱里的那块 GPU 而来。
到底谁更强,目前谁都说不清。在直接的编程评测里,Qwen 赢得干脆:30个任务过24个;Ornith 只过15个,看起来一边倒。可当让两个模型从零做一个完整的3D游戏时,剧本立刻反转——Qwen 一次提示零引导直接交卷,Ornith 却被推着走了六轮才勉强追上。而一旦上下文拉长,速度上的攻守又再度易位。
本文改编自 YouTube 频道 PandaMakingMoney 的35分钟完整对比原片,不含任何赞助,两家模型背后都没有金主,全部依据公开评测、独立测试以及真实在自己机器上跑过模型的用户反馈。结论先行:谁赢,完全取决于你在优化什么。

架构对比:MoE省计算 vs 稠密模型省显存
Ornith 1.5:混合专家模型的计算优势与显存代价
Ornith 1.5(35B)出自 Deep Green Force,采用 MIT 协议,可随意修改、商用。家族里还有面向轻量硬件的9B精简版,以及一个397B的旗舰版本(家用机器根本跑不动),因此35B才是真正能落到消费级显卡上的主力。
它是混合专家(MoE)模型:内部有256个专家,每来一个 Token,路由器只挑8个上场,其余248个坐板凳。总参数35B,每个 Token 实际只激活约3B——这正是它推理速度快的根源。
但坑也在这里:路由是逐 Token 动态选择,你无法预测下一步会用哪些专家,因此全部35B参数必须同时常驻显存。计算便宜,显存不省。
Qwen 3.8:稠密架构配合混合注意力机制
Qwen 3.8(27B)走的是另一条路,采用 Apache 2.0 协议的稠密模型,来自阿里 Qwen 团队。27.7B参数全量激活,没有路由,没有专家挑选,整个模型每次都在干活。
但它把"省"字用在了注意力机制上——混合注意力。全模型64层中,只有16层用传统全注意力(需要记住越来越长的对话历史),另外48层用固定状态大小的线性注意力(DeltaNet)。效果是 KV 缓存几乎不随上下文膨胀:8K 上下文只多约0.5G,拉到32K也只多约2G,跑长编程、长对话时特别占便宜。显存省,但每个 Token 全家出动。
两家套路一致:云上放旗舰(Ornith 的397B、Qwen 的2.4万亿参数 Max 版走 API),开放给你本地托管的都是"小弟"。两种完全不同的工程赌注就此摆开。
跑分验证:厂商自报数据与独立第三方评测
大多数对比视频翻车的地方,就是把厂商自报数字直接贴一张表就完事。这里我们坚持打对折看。
Ornith 方面,Deep Green Force 自报 Terminal Bench 2.1 拿到60多分,自家编程榜重进70多。对35B级别确实好看,但每个数字都出自厂商测自己的模型、用自己的评测环境、跑在自己的硬件上,全程无第三方参与——不代表造假,但要按"车厂夸自己车最快"的标准来听。
Qwen 3.8 自家榜跳得更猛:Terminal Bench 2.1 从上代63.4涨到73.0,Deep SWA 从13.3近乎翻三倍到42.2,OS World 验证分从63.9冲到84.3。同样是自测自报。
全片唯一的独立证据来自 Artificial Analysis——这家第三方与阿里无利益关系。他们给 Qwen 打出52的智能指数,恰好追平满推理档的 GPT-5.6,智能体分51,甚至压过发布不到三个月的 Claude Opus 4.8。代价是啰嗦:同轮评测里 Qwen 生成约1.6亿 Token,而同级开放模型中位数才4300万,多了近4倍。而 Ornith 至今缺乏独立验证。

真人实测:编程能力与自主性深度检验
第一场:30道One-Shot编程题实测
社区有人用 Three.js 设计了30道一次性(One-Shot)编程题——每题只许一次作答,不给返工,不给额外引导。这砍掉了迭代的安全网,更接近真实的自动化编程流程。全部统一跑在 Q6 量化上以保证公平。
结果 Qwen 3.8 拿下24/30,全场最高。Ornith 那15个通过里,有好几个交的是纯白屏或碰巧满足判分条件的坏输出——技术上算过,实际上没法用。但公道话也要说:在它真正做出来的题上,产出质量明显好于上代。整场下来 Ornith 比 Qwen 多烧两到四成 Token,其中一部分还烧在了最终交废件的迭代上——你为没落地的结果付了算力。
第二场:从零生成GTA式3D游戏
第二场是纯真实工作流。测试者在 Apple M3 Ultra、512G 统一内存的机器上跑编程智能体,显存余量大到不成变量,专门看模型本身。任务很野:一句自然语言提示,要求做出致敬《GTA:圣安地列斯》的可玩3D游戏,大地图能自由探索、能偷车抢车、画面还要像样,全部从零生成。
Qwen 3.8 一次尝试、零额外引导直接完成——这对无人执手的编程智能体场景是极强信号。Ornith 则足足迭代了六轮,测试者形容"不停地推、不停地揪",直言它"和 Qwen 不在同一个自主性等级上"。

长上下文性能:速度攻守逆转
但同一场测试里,速度立刻翻盘。对话拉近超长上下文后,Ornith 从每秒75 Token 缓降到45,跨过16万 Token 大关之后依然顺畅可用;而 Qwen 跨过同一道线,生成速度直接崩到每秒约5 Token,基本等于卡死。这不是小差距,而是长对话里一个还能用、一个已经废的区别。
显存成本对比与选购建议
不同显存档位的适配情况
Ornith 推荐 Q4_K_M 量化,模型加运行开销整包约23G才算舒服,官方和社区建议按27G以上准备。MoE 在这里变成包袱:256个专家必须同时进显存,就算每 Token 只用8个也一样。小卡的后路是用 CPU Offload 把部分专家卸到系统内存,12G的卡也能伺候,代价是速度肉眼可见地掉。

Qwen 同档 Q4_K_M 只要16到19G,24G卡装下后还能留出5.6万到6.4万 Token 的上下文——归功于那48层线性注意力。按显卡分档:
- 24G显存:Qwen 更从容,Ornith 贴着上限
- 16G显存:Qwen 明显更舒服
- 12G显存:Ornith 靠 CPU 卸载硬跑或激进量化
- 32G以上:两家都能放开手脚上 Q6/Q8
最终选择建议
选 Qwen 3.8 的场景:接近编程智能体、需要模型少人执手地干活——它一次过的表现遥遥领先,是唯一有独立第三方(Artificial Analysis)验证背书的选择,16-24G 显存装得更从容,工具链(Unsloth 动态量化)也最成熟。
选 Ornith 1.5 的场景:商业场景明确要 MIT 而非 Apache 2.0 协议,长期打超长上下文对话、显存又给得起。
关于独立验证的提醒
Ornith 1.5 发布才一周,跑分几乎全部由厂商自曝,35B 这一档的独立验证还很稀薄,Hacker News 上甚至有人质疑"自我改进"在这个规模是否成立。这不是说它差——工程扎实、速度优势打实——而是说信任要靠独立验证慢慢挣,不是靠发布周的一波热搜。此刻,Qwen 在"证据"这条路上走得更远。这是证据的差距,不是实力的判决。
相关推荐

@ai-sdk/zai@3.0.10 发布:依赖更新的补丁版本解析
Vercel AI SDK 发布 @ai-sdk/zai@3.0.10 补丁版本,同步更新 provider、provider-utils 与 openai-compatible 等底层依赖。本文解析该版本变更内容及 AI SDK provider 体系的设计意义。

Vercel AI SDK 更新:@ai-sdk/workflow 2.0.29 修复工具结果保留问题
Vercel AI SDK 发布 @ai-sdk/workflow 2.0.29 补丁版本,核心修复工作流在终止、延迟、暂停三种响应状态下 provider 工具执行结果的保留问题,并同步升级 ai@7.0.98 等核心依赖。

Vercel AI SDK 更新:@ai-sdk/xai 4.0.58 批处理与图像生成改进
Vercel AI SDK 发布 @ai-sdk/xai 4.0.58 版本更新,新增批处理图像生成支持,修复批处理请求类型校验及 DeepSeek 推理流问题,并同步升级 provider 相关依赖。