@sudoingX: 我之前在 llama.cpp 上用 Q4 量化运行了 Ornith 新型 35B MoE 模型，4 bit，体积小，速度快，达到了约 78 tok/s。然后我更换了引擎……

X AI KOLs Timeline 模型
open-source mixture-of-experts code-generation local-ai llm-inference vllm performance

摘要

一款名为 Ornith 的 35B MoE 智能编码模型，在单台 DGX Spark 上以 FP8 精度近乎无损运行，支持 300 万 token 上下文，速度约 36 tok/s，预计通过投机解码可进一步提升性能。

我之前在 llama.cpp 上用 Q4 量化运行了 Ornith 新型 35B MoE 模型，4 bit，体积小，速度快，达到了约 78 tok/s。然后我更换了引擎。 现在我在 vLLM 中运行同一 MoE 模型，采用 FP8 精度，近乎无损，基本保持完整质量，仅用一台 DGX Spark。而且这台机器还能轻松支撑超过 300 万 token 的上下文。想象一下：一个 35B 的智能编码模型，近乎全精度，拥有 300 万 token 的窗口，就放在桌面上。 在此精度下，速度约为 36 tok/s，完全可用，而这还是未优化的基线水平，尚未启用投机解码。 这正是大家忽略的关键点。本地 AI 悄悄迎来了一款真正好用的智能编码模型，近乎无损，超大上下文，单机运行，却几乎无人察觉。 接下来是投机解码，届时 Spark 将利用闲置算力换取速度，这个数字还会上升。如果实现，你就能在桌面上以真实速度运行近乎全质量的 35B 编码模型。这才是真正的考验。
查看原文
查看缓存全文

缓存时间: 2026/06/28 14:09

我原本在 llama.cpp 上跑 Ornith 新的 35B MoE，用的 Q4 量化、4 位，小巧又快速。跑到了大约 78 tok/s。然后我换了个推理引擎。

现在我在单台 DGX Spark 上，用 vLLM 跑同一个 MoE，精度是 FP8，近乎无损，基本是完整质量。而且这台机器还有余力支撑超过 300 万个 token 的上下文窗口。想想看：一个 35B 的智能编码模型，接近全精度，带着 300 万 token 的窗口，就放在桌面上。

在这个精度下，它稳定在约 36 tok/s，完全可用，而且这还只是未经优化的基线版本，还没有用上推测解码。

这就是人们还没注意到的重磅消息。本地 AI 已经悄然拥有了一款真正优秀的智能编码模型——近乎无损、超长上下文、单台机器就能跑，而且几乎没人留意到它。

下一步是推测解码，DGX Spark 会用它的闲置算力换取速度，token 数还会往上提。如果成功，你就在桌面上拥有一个接近全精度的 35B 编码模型，跑得飞快。这才是真正的考验。

Sudo su (@sudoingX): 在 DGX Spark 上跑 Ornith，看看它到底怎么样。

这是来自 @ornith_ / deepreinforce-ai 的新版智能编码模型，35B MoE（A3B，每个 token 约 3B 参数活跃）。我下载了 Q4_K_M gguf（约 20GB），接入了 Hermes Agent，单台 Spark 上预填充很快，约 78 tok/s，所以它

相似文章