Kolibri-1
关于 Kolibri-1 的完整介绍（点开看；上面就是结论表）
Aleph Alpha（德国）2026-10-03 开源的 MoE 推理模型（HF: Aleph-Alpha/Kolibri-1，许可 **Apache 2.0**，FP8 e4m3 权重）。78.1B 总 / 3.46B 激活，50 层全 MoE（384 路由专家激活 6 + 1 共享）、滑窗 512 + 每 5 层全注意力 GQA（48 查询头 / 4 KV 头），主打长上下文与推理效率，德英双语，显式推理模式 + 工具调用。**原生上下文 config 一手核到 = 262,144**（max_position_embeddings）；官方卡另标 1,048,576 上限并**明确建议 ≤262,144 token 以保证服务效率与复杂任务质量**——按站内『卡面/外推口径不算原生』纪律，native_ctx 记 config 权威的 262K，1M 视为扩展口径如实标注。KV 已按 config 一手核到并建 arch_detail：50 层 = 5 全注意力 + 45 滑窗 513 / GQA 4KV / head_dim 128，复算 0.083G/4K（原保守近似 0.4G，config 抓到后转正）。权重 FP8 ~78G：单卡 24G 装不下，**最低 2×A100 80G 或 1×H200**——这是本批里唯一「门槛偏可跑」的一条（不是纯集群）。收录理由：国外线窗口内新的 Apache-2.0 开放权重 MoE，读者会搜，给诚实答案页。他测（2026-11-09 B-066 补，DGX Spark 128G 双独立来源，C 级、方向一致可升 B 级待裁定）：vLLM 0.29.0 + FP8 KV 单流 **20.4 tok/s**（mARTin-B78，prefill 1402，16K/32K ctx 仅 19.9/19.6 几乎不掉）/ vLLM main + BF16 KV 单流 **50.1**（pulseandthread，158K ctx 29.2，4 并发聚合 111.6）——同硬件两引擎 **20.4 vs 50.1 两说并存不抹平**（引擎版本 + KV dtype 双变量，引用按各自来源标）。端侧 M5 Max 128G MLX 91–116 t/s（modemguides 10-04 汇总，端侧留底本不入 benchmarks）。
实测速度：什么卡、什么量化、多少 token
| 显卡 | 卡数 | 量化 | 上下文 | 框架 / 版本 | decode tok/s | prefill tok/s | 单流/并发 | 投机 | 口径 | 来源 |
|---|---|---|---|---|---|---|---|---|---|---|
| NVIDIA DGX Spark 128G | 1 卡 | FP8（官方 shipped 权重） | 未报 | vLLM（llama-benchy pp2048/tg128 口径） · 0.29.0（CUDA 13.0，--kv-cache-dtype fp8 --gpu-memory-utilization 0.78 --max-model-len 131072） | 20.4 | 1402 | 单流 | 无 | 口径不全·不进对比 缺 2 项 | mARTin-B78/aleph-alpha-inference-kolibri-1-dgx-spark（README 实测表 + 原始数据 benchmarks/ 目录） mARTin-B78（GitHub 社区） · 2026-10-04 |
| NVIDIA DGX Spark 128G | 1 卡 | FP8（官方 shipped 权重，KV cache BF16） | 0K | vLLM（作者自写 bench.ts 客户端，256-token 回复） · 0.1.dev20073+g8e685d198（torch 2.13.0+cu130，CUDA 13.0，--kv-cache-dtype auto --max-model-len 262144 --gpu-memory-utilization 0.90） | 50.1 | 未报 | 单流 | 无 | 他测·本站未复现 | pulseandthread/kolibri-1-dgx-spark（README 实测表，0/4.9K/19.8K/79K/158K prompt 全序列） pulseandthread（GitHub 社区） · 2026-10-03 |
每行是一次真实测量的完整口径：哪张卡、几张卡、什么量化、多大上下文、哪个框架哪个版本、单流还是并发、开没开投机—— 缺一项就会标出来，缺项的行不参与对比与偏差计算。本站实测行没有外链，但日志路径就是原始数据所在。 想看同一张卡跑别的模型，从这个表的显卡名点进那张卡的页面。
速查：什么卡、跑多少 token
推算值按 Q4_K_M、8K 上下文、单流；真实测量看下面的实测速度表。没有实测的模型这里只有推算，本站不把推算写成实测。
架构常数（已核实）
来源：Aleph-Alpha/Kolibri-1 / config.json（抓取于 2026-11-09）。KV 公式：2 × 层数 × KV头数 × 头维 × 精度字节 × token（滑窗层按 513 封顶）。
上下文档位（按 Q4_K_M）
| 上下文 | KV | 总需显存 | 16G 水位内 |
|---|---|---|---|
| 4K | 0.08 G | 47.9 G | 超 |
| 8K | 0.12 G | 48 G | 超 |
| 32K | 0.36 G | 48.2 G | 超 |
| 128K | 1.29 G | 49.2 G | 超 |
* 含 1G 框架开销；可用水位按 Windows 口径 88% = 14.1G。
各显存档位能开多大
| 显存 | 推荐量化 | 8K 总需 | 最多可开 |
|---|---|---|---|
| 4G | 装不下 | — | — |
| 6G | 装不下 | — | — |
| 8G | 装不下 | — | — |
| 10G | 装不下 | — | — |
| 11G | 装不下 | — | — |
| 12G | 装不下 | — | — |
| 16G | 装不下 | — | — |
| 20G | 装不下 | — | — |
| 22G | 装不下 | — | — |
| 24G | 装不下 | — | — |
| 32G | 装不下 | — | — |
| 48G | 装不下 | — | — |
| 64G | Q5_K_M（估算） | 55.8G | 61440（约 60K） |
| 96G | Q8_0（估算） | 84.1G | 49664（约 49K） |
| 128G | Q8_0（估算） | 84.1G | 262144（约 256K） |
| 256G | Q8_0（估算） | 84.1G | 262144（约 256K） |
| 512G | Q8_0（估算） | 84.1G | 262144（约 256K） |
「最多可开」已扣掉权重与 1G 开销；标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 250 token（估算值，未逐项核实）。量化档后带「（估算）」= 官方仓库没核到这档、按公式算的权重体积（方向保守偏高）；不带 = 核过官方仓库真实文件体积。
估算速度（Q4_K_M · 8K）
推算 本站暂无这一模型的实测记录。
| 显卡 | 状态 | 估算 tok/s |
|---|---|---|
| NVIDIA RTX 5090 32G | 装不下 | 需 offload ≈12–19 |
| NVIDIA RTX 5090 D 32G | 装不下 | 需 offload ≈12–19 |
| NVIDIA CMP 170HX 64G（矿卡魔改） | 能跑但紧 | 200 |
| NVIDIA RTX PRO 5000 Blackwell 48G（工作站） | 装不下 | 需 offload ≈12–19 |
| AMD Instinct MI100 32G（老数据中心卡） | 装不下 | 需 offload ≈12–19 |
| AMD Instinct MI50 32G（数据卡） | 装不下 | 需 offload ≈12–19 |
| AMD Radeon VII 16G | 装不下 | 需 offload ≈12–19 |
| NVIDIA RTX 4090 24G | 装不下 | 需 offload ≈12–19 |
| NVIDIA RTX 3090 Ti 24G | 装不下 | 需 offload ≈12–19 |
同一套公式也用于显卡页，两页数字必然一致。带宽按 60–85% 效率折算（offload 场景更低），并对单流解码设经验上限，因此这里的数字比纯带宽公式保守。 总需显存 = 48G，对比各卡可用水位。
实测数据区
上传实测数据
推理框架命令
llama.cpp
# 1) 取 GGUF 权重（本站核实过的仓库名）
huggingface-cli download Aleph-Alpha/Kolibri-1 config.json
# GGUF 量化版通常在第三方转换仓库，搜「Aleph-Alpha/Kolibri-1 GGUF」
# 2) 起服务（Linux/macOS 用 ./llama-server，Windows 用 llama-server.exe）
llama-server -m KOLIBRI-1-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080
# 该模型带滑窗层，长上下文比同级便宜，值得把 -c 拉高试试
# MoE：想让专家留在内存以塞更大模型，加 --n-cpu-moe（参数名随版本变，用 --help 确认）Ollama
# 本站没核实到 Ollama 仓库里有 Kolibri-1 的可用标签，所以不给命令
# 自己去查一眼：https://ollama.com/search?q=Kolibri-1宁可不给命令，也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。
vLLM
vLLM 直接吃 Hugging Face 仓库名，这条最可靠：
vllm serve Aleph-Alpha/Kolibri-1 --max-model-len 8192 --gpu-memory-utilization 0.90LM Studio
模型页搜「Aleph-Alpha/Kolibri-1」→ 选 Q4_K_M 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大仓库名 Aleph-Alpha/Kolibri-1 是本站核实过的（架构常数就取自它）。Ollama 标签与 GGUF 文件名会随发布方变动，本站不保证一定存在，拉取失败请搜同名前缀。
优化要点
- Q4_K_M 权重 46.9G（估算）、Q6_K 64G（估算）、Q8_0 83G（估算）：带「估算」的是公式值（官方仓库没核到这档），不带的核过真实文件；先在容量表里确认 8K 上下文还剩多少，再决定档位
- 上下文从 8K 提到 32K，KV 增加约 0.2G（本模型 50 层 / 4 KV头 / 头维 128）
- 模型原生上下文上限是 256K，把 -c 设得更高属于超纲使用，质量不保证
- 想要更长上下文：-ctk q8_0 -ctv q8_0 让 KV 减半，几乎不掉质量
- MoE 速度按激活参数（本站用 3.46B）算，显存却必须装下全部 78.1B 专家；两者混用会得出完全错误的结论
- 本站对单流解码设了经验上限 200–200 tok/s（依带宽分档），超出上限的数字是公式失真而不是你的卡快