AREX Feed Article
两名开发者实测 Kolibri-1：单台 DGX Spark 上官方权重约 20 tok/s，自制 NVFP4 量化版最高 80 tok/s
图：Kolibri 的品牌视觉素材（Trending Topics 报道配图，版权标注为 Aleph Alpha）。
10 月 4 日，NVIDIA 开发者论坛用户 与 X 用户 先后公布了各自在单台 DGX Spark（GB10）上运行 Kolibri-1 的实测数据。用官方 FP8 权重的那份测出解码约 20 tok/s（每秒生成的 token 数），工具调用短测 15 个场景全部通过；用自制 NVFP4 量化版的那份在 1k 上下文解码 80 tok/s、32k 时 65 tok/s，但作者称其编码输出质量差、训练的草稿模型也未达标，决定不再合并这条分支。两份记录都来自个人测试，作者也各自注明了样本与调优上的限制。
Kolibri-1 是 Aleph Alpha 在 10 月 3 日开放的英德双语 MoE（混合专家）模型，78B 总参数、3B 激活，最高支持 1M token 上下文，完整权重按 Apache 2.0 许可在 Hugging Face 提供下载（）。发布公告给的是厂商口径的性能数字；这两份记录回答的是更基本的问题：一台 128 GB 统一内存的机器能不能把它跑起来、跑多快。
图：论坛帖中出现的 Kolibri-1 Hugging Face 模型页预览。
官方 FP8 权重：绕过 amd64 容器限制，冷启动 18～25 分钟
martinB78 的帖子记录了他把 Kolibri-1 在 Spark 上跑通的完整过程：从镜像、启动参数，到实测数字和注意事项。Kolibri-1 需要 Aleph Alpha 的 vLLM 插件 aleph-alpha-inference，而插件锁定 vLLM 0.29；据他核对，上游只发布了 amd64 版本的插件容器，不能直接用在 arm64 的 GB10 上。他的解法是把纯 Python 的插件装进多架构的 vllm/vllm-openai:v0.29.0 镜像，再在镜像里 pip install aleph-alpha-inference==1.0.0。按他的说法，整个 Dockerfile 就这一步。
在单台 Spark、vLLM 0.29.0、CUDA 13.0 的环境下，他用 llama-benchy 测试（2,048 token 提示、生成 128 token、并发 1、两轮）：上下文深度 0、16k、32k 时，解码速度为 20.4、19.9、19.6 tok/s，prefill（预填充）为 1,402、1,331、1,131 tok/s，首 token 时间 1.5、12.3、27.3 秒。权重单独占 73.5 GiB，冷启动 18～25 分钟（其中加载权重约 1,087 秒），他建议把就绪超时放宽到 30 分钟；GPU 内存利用率定在 0.78，因为在他的机器上，CUDA 实际可用内存比系统显示的可用量少约 11 GiB。
工具调用方面，tool-eval-bench 短测 15 个场景得到 100/100，五个类别各 6/6；但响应性分项只有 15/100，原因是模型默认开启思考，单轮中位耗时 9.6 秒。作者自己列了这些数字的边界：单台硬件、小样本、未调参、非官方基准，测试时并行运行两个场景可能带来计时噪声，llama-benchy 因未取到官方 tokenizer 而用 gpt2 近似；他还注明帖文由 AI 生成。配套 里，compose 文件只做过配置校验、没有端到端运行，Dockerfile 也没有为发布重新构建。
自制 NVFP4 量化版：量化验收门槛与三次迭代
@0xBakeer 的路线是另一条：他为 Kolibri-1 自制了 NVFP4 量化版，并围绕它调整自己的 TandemLLM 推理引擎。在单台 DGX Spark 上，1k 上下文解码 80.4、8k 时 76.4、32k 时 65.1 tok/s，prefill 约 2,170 tok/s；在文档编辑与引文类文本上，配合推测解码（speculative decoding）与 StairCut 路由，速度还能提升 3 倍以上（约 80 到 260 tok/s），输出与不开推测解码时一致。
记录了更多细节：量化只把 40 个滑窗层的路由专家与 q/o 投影放进 NVFP4，k/v、10 个全注意力层的注意力和共享专家保留 FP8，权重 44.9 GB；量化验收门槛是各领域平均 NLL（负对数似然，越小越好）相对 FP8 版本至多 +0.05 nat，最终版本落在 +0.005～+0.035；在约 2,000 个高置信度位置上，与普通解码逐步取最大概率 token 的结果一致率为 99.35%～99.75%。三个迭代版本把 1k 解码从 39.4 提升到 80.4 tok/s；在 1k 上下文，最终版本达到按内存带宽算出的理论上限（109～112 tok/s）的 72%～74%，一个解码步要读出约 2.44 GB 权重。
他停下来的原因也写在同一页：一次编码测试里，他让模型在 opencode 里「用浏览器做一个马里奥游戏」，模型给出的极简平台游戏带逻辑 bug，每轮思考约 200～315 token；他为给新文本提速而训练的 5 层、4.52 亿参数草稿模型，3,900 步后每轮平均只通过 1.47 个 token，未达到每轮 2.0 的要求。分支被标记为归档，不再维护，也不会合并进主干。他同时写明，官方报告中的编码分数（LiveCodeBench v6 85.9、HumanEval+ 92.7、effort high 下 SWE-bench Verified 66.4）他没有复现，也没有调查差距从何而来。帖子最后一句是：「暂时回到 Qwen 了。」
同一个模型，三种结果：差别出在运行时与量化方案
在 martinB78 帖子的回复里，用户 cosinus 报告了第三种组合：基于为 GB10 原生构建（SM121 优化）的 vLLM 0.30.1rc1 加官方插件，服务上下文设为 262k 时，解码约 48 tok/s，tool-eval-bench 86/100，启动约 10 分钟。
约 20、约 48、65～80 tok/s，三个数字都来自同一个模型，差别出在运行时构建、量化方案与推测解码。两人的解释也指向同一个约束：解码速度受限于每一步要读出的权重字节数。martinB78 说，20 tok/s 左右正是流式读取 73 GiB 权重时该有的水平，「不会像我们习惯的小 MoE 那么轻快」；@0xBakeer 给出的账更细：1k 上下文每解码一个 token 要读 2.44 GB 权重，理论上限 109～112 tok/s，他的最终版本把这个上限用到了七成多。这些数字来自不同的运行时与配置，彼此之间不是一次对照实验，不能直接横向比较。
厂商基准分数、超长上下文与工具链：还没闭合的部分
两份记录测的是吞吐、一次工具调用基准和一次编码尝试；Aleph Alpha 公布的基准分数，不在它们的覆盖范围内。里指出，当时还没有独立排名可查：Kolibri 尚未进入 Artificial Analysis 榜单。
图：同一论坛帖里另一位用户贴出的基准对比截图，Kolibri 一列的英语综合分 75.5、德语综合分 70.8。
其他留白同样具体：冷启动为什么慢，martinB78 只给了一个未经验证的猜测：FP8 MoE 权重处理可能受 CPU 与统一内存带宽限制；这些能跑通的路线都出自社区之手，更快的那条路（NVFP4 加推测解码）停在了一个已归档的分支上；而 NVFP4 版给过一次 185k token 文档上的 prefill 测量（1,510 tok/s），离官方宣称的 1M token 上限还有距离。