Ornith 1.5 35B实测：Q4与Q8量化对比，哪个更值得跑？

近期开源社区迎来了 Ornith 1.5 模型家族的发布，这一系列模型基于 Qwen 3.5/3.6 进行二次训练，声称在能力上实现了显著跃升。科技博主 Bijan Bowen 对其中的旗舰级消费级模型——Ornith 1.5 35B-A3B（350亿参数、30亿激活参数的混合专家模型）进行了深度实测，重点对比了 Q4KM 与 Q8 两种量化版本在本地运行时的真实表现。

模型背景与测试环境

Ornith 1.5 系列建立在 Qwen 3.5 的基础之上，通过额外训练带来了可观的能力提升。除了本次测试的 35B MoE 模型外，官方还发布了一款 1.5 397B 的大型模型，据称在 DeepSWE 基准上取得了 56 分的成绩，官方宣称可以对标 Claude Opus 4。DeepSWE 是一个评估大语言模型软件工程能力的基准测试，源自 SWE-bench 系列，它通过向模型提供真实 GitHub 仓库中的 bug 报告或功能需求，要求模型生成能通过对应测试用例的代码修改。56分意味着模型能成功解决56%的测试案例，这一成绩确实亮眼。不过测评者也提醒，所有基准测试都应保持谨慎态度——基准成绩可能因数据泄露、过度优化特定测试格式等原因而不完全反映真实能力，最好还是亲自运行验证。

对于消费级用户而言，35B-A3B 这样的规模更具现实意义。这里的「A3B」指的是混合专家模型（Mixture of Experts, MoE）架构中的"激活参数"概念。在传统的稠密模型中，每次推理都会激活模型的全部参数；而 MoE 架构则将模型拆分为多个"专家"子网络，通过"路由器"组件根据输入内容决定激活哪些专家。以本模型为例，虽然总参数量为350亿，但每次推理仅激活约30亿参数，这意味着它能以接近3B模型的计算成本获得接近35B模型的能力。这种设计大幅降低了推理时的显存和算力需求，使得大参数模型能在消费级硬件上运行。由于目前 Qwen 尚未推出对应的 3.8 版本 35B-A3B 模型，Ornith 1.5 有望成为一个不错的临时替代方案。

测评者的测试方案颇具巧思：他在单张 RTX 6000 Pro 显卡上同时运行两个量化版本——左侧是 Q4KM，右侧是 Q8，两者均使用 Ornith 官方在 Hugging Face 上传的 GGUF 文件，并严格遵循官方推荐的采样参数与推理配置，以排除后端设置错误的干扰。

GGUF（GPT-Generated Unified Format）是由 llama.cpp 项目所使用的模型文件格式，是当前本地部署大语言模型最流行的格式之一。llama.cpp 是一个纯 C/C++ 实现的 LLM 推理框架，支持 CPU、CUDA、Metal 等多种后端，使得用户无需依赖 Python 或大型框架即可高效运行模型。RTX 6000 Pro 配备48GB GDDR7显存，是专业级消费显卡，能够同时承载两个量化版本的关键原因在于 MoE 架构的低激活特性——虽然模型文件较大，但运行时的实际计算需求可控。

量化技术简述

本次测试的核心对比在于两种量化级别的差异。量化是将模型权重从高精度浮点数（如FP16/BF16的16位）压缩为低精度整数表示的技术。Q4KM 表示将权重量化为4位精度并使用 K-Quant Mixed 策略（由 llama.cpp 项目提出），Q8 则为8位量化。K-Quant 是一种分组量化方案，它将权重分成小块，每块使用独立的缩放因子来减少量化误差。Q4KM 相比纯 Q4 会对模型中更关键的层（如注意力层）使用稍高的精度，从而在压缩率和精度之间取得更好的平衡。Q8 量化后的模型文件大约是 FP16 的一半大小，而 Q4 约为四分之一。量化的代价是精度损失——模型的"思考"能力会因权重信息的丢失而有所下降，这正是本文测试两种量化级别差异的核心动机。

浏览器操作系统测试：Q8明显胜出

第一项测试是「Browser OS v2.7」，要求模型生成一个带有程序化动态壁纸和邮件应用的浏览器操作系统。

结果显示，Q4 版本率先完成任务，其间遇到过无法一次性大规模修改代码的问题，于是自主拆解成小块逐步处理。Q8 版本则一度卡住——它错误地用「关闭标签页」而非「关闭浏览器」来结束测试，导致完成信号无法触发，需要手动介入继续。

浏览器操作系统测试效果对比

从上下文占用来看，Q8 用掉了 262K 上下文窗口的 41%，而 Q4 仅使用了 19.5%。上下文窗口是指模型单次推理时能处理的最大 token 数量，262K 意味着约26万个 token（大约相当于一本中等长度的小说）。在代理式编码场景中，模型需要反复阅读代码、生成修改、接收反馈，这些都会快速消耗上下文空间。Q8 消耗更多上下文的原因在于它进行了更加细致的 QA 检查，反复审视和迭代修改自己的输出。

在最终结果对比中，差异非常明显：Q8 版本的视觉呈现更加精致、功能更完整。其 GTA 克隆游戏画面质感突出（测评者形容为「果冻般」的效果），设置面板中的壁纸动态速度、任务栏透明度、24小时时钟格式等细节都实现得相当到位，甚至内置了一个会「超时退出」的 Matrix 特效彩蛋。

结论很清晰：在这一测试中，如果条件允许，Q8 无疑是更优选择。作为 MoE 模型，即使 GPU 显存不足以完全承载，也可以将部分负载卸载到 CPU 内存（即"部分卸载"策略），牺牲推理速度换取输出质量。这一策略对 MoE 模型特别友好，因为每次推理只激活少量专家，实际需要 GPU 加速的计算量远小于模型总参数量所暗示的规模。

地铁模拟器与FPS测试：细节见真章

第二项测试是地铁模拟器结合 FPS 玩法。两个版本再次呈现出鲜明差距。

Q4 版本的核心问题在于：鼠标无法控制视角移动，射击功能也失效，视角始终固定朝前，即便给它开发者控制台让其自行修复，问题依旧存在。

弹道会冻结留在场景中

Q8 版本命名为「Meatball Station」，完成度更高。虽然按 W 键会导致场景冻结、无法真正移动，但在经过修复迭代后，它成功解决了弹道残留、枪口火焰不消失等问题，还实现了指针锁定退出/进入、跳跃等功能。测评者认为，对于这个规模的模型来说，Q8 的表现已经相当出色。

复杂任务实测：Q4的惊喜与Q8的深度

在自包含的 C++ 滑板游戏测试中，出现了意外的惊喜。Q4KM 运行了很长时间几乎耗尽上下文，测评者原本已不抱期望，但最终产出的结果远超预期——一个半成型的滑板骑手模型，尽管存在诸多问题，但对于 Q4 量化的 MoE 模型而言令人印象深刻。

Q8 版本则运行了整整一夜，经过大量上下文压缩（即对早期对话内容进行摘要或裁剪，保留最关键的信息以腾出空间继续工作），最终生成了带有行走 NPC、动感喷泉特效以及可用滑板技巧和多视角切换的场景。虽然同样缺乏移动功能，但作为「原地花式模拟器」已相当可玩。

3D引擎建模：Q4反而更实用

在使用 OpenSCAD 建模直列六缸引擎的测试中，出现了有趣的反转。OpenSCAD 是一款基于脚本的3D建模软件，与传统的图形化 CAD 工具不同，它通过代码来定义几何形状——用户编写类似编程语言的脚本来描述物体的形状、尺寸和组合方式。这使得它特别适合作为 LLM 生成3D模型的输出格式，因为模型只需生成文本代码即可创建三维物体。

Q4KM 生成的引擎块尺寸更接近可 3D 打印的合理规格（消费级打印机的打印面积通常在20-30厘米范围内），正确体现了六个气缸的结构。

3D引擎建模对比

而 Q8 虽然细节更丰富——正确识别出双涡轮增压、气门室盖上的六个点火线圈盖等，但缩放严重失控，生成了远超打印平台尺寸的全尺寸引擎。测评者指出，从实用角度看，Q4 的结果反而可能更好——在3D打印场景中，模型尺寸的合理性往往比细节的丰富性更重要，因为超出打印范围的模型需要额外的手动缩放和调整工作。

网站前端与StreetEat游戏：各有侧重

在腕表网站前端测试中（需包含带电影级镜头环绕的 3D 手表模型），两个版本的差距反而不明显。测评者坦言，如果不告诉他哪个是 Q8，他很难分辨。Q8 的手表带比例更真实，但整体偏暗；Q4 的核心组件（表冠、表盘、皮革表带）也都到位。由于这是一个存在已久的测试，不排除已进入训练数据的可能——这也是 AI 评测中一个普遍存在的"数据污染"问题，当测试题目出现在训练语料中时，模型的表现会被人为抬高。

最后的「StreetEat」游戏测试要求用 Blender 制作素材、用 Godot 构建游戏。Blender 是一款开源的3D建模和动画软件，Godot 则是一个开源游戏引擎，两者结合代表了完整的独立游戏开发工作流。这是一个从未在此前视频中展示过的全新测试，可有效排除训练数据污染的可能。Q4 版本产出了有各种错误、无法移动但能开启并展示基本游戏框架的成果。Q8 则表现惊艳——完整制作了素材并整合，「yeeting」抛掷动作、音效、镜头晃动都得以实现，测评者对其在多次上下文压缩后仍能完成整合表示高度赞赏。

总结：消费级本地部署的实用选择

经过为期两天的多项测试，测评者对 Ornith 1.5 35B-A3B 给出了积极评价。核心结论包括：

整体能力相较基础 Qwen 3.5/3.6 版本有明显提升，尤其是在全新的、未出现在训练数据中的复杂任务上表现亮眼；
Q8 在大多数场景下优于 Q4KM，特别是在浏览器 OS、C++ 滑板游戏、StreetEat 游戏等需要深度迭代的任务中差距显著；
但并非所有场景 Q8 都占优，在腕表网站和 3D 引擎建模中，Q4KM 的结果甚至可能优于或持平 Q8；
Q8 会消耗更多上下文进行细致的 QA 检查，而 Q4 更节省资源、更适合普通消费级硬件运行。

测评者特别强调，之所以进行 Q4 与 Q8 的对比，正是因为大量用户出于硬件限制会选择 Q4KM。对于大多数消费级用户而言，16-24GB 显存的显卡是主流配置，运行 Q8 版本可能需要大量依赖 CPU 卸载从而严重影响速度，而 Q4KM 则能在合理的推理速度下提供可用的输出质量。对于希望在消费级设备上运行本地大模型的用户来说，Ornith 1.5 35B-A3B 确实是一个值得尝试的选项——它代表了 MoE 架构在本地部署场景中「以小博大」理念的最新实践。