作者： Matt Connor
Kolibri-1 自行托管需要什么硬件和成本？
Kolibri-1 采用 Apache 2.0，但约需 78 GB FP8 权重、1 块 H200 或 2 块 80 GB H100。了解硬件成本，以及何时小模型更合适。
自托管 Kolibri-1：简要回答
自托管 Kolibri-1 是可行的，但无法在普通 VPS 上运行。位于海德堡的 Aleph Alpha 以 Apache 2.0 协议发布了该模型。FP8 格式的权重文件大小约为 78 GB。官方推荐的运行方式是使用 vLLM，且至少需要一块 H200 或两块显存各为 80 GB 的显卡。目前没有针对 CPU、GGUF、llama.cpp 或 Ollama 的官方支持方案。
对于德国的许多读者来说，最关心的问题是：数据是否能保留在本地？Kolibri-1 可以做到这一点，且许可协议对此没有限制。主要的障碍在于硬件。
数据说明：本文所有信息均基于 Aleph-Alpha/Kolibri-1 的模型卡（Model Card）修订版 e52eb4627d11516b0c01de49210ab5a4e4061444（Hugging Face，2026 年 10 月 3 日）以及 aleph-alpha-inference 1.0.0 版本软件包。最后核查日期为 2026 年 10 月 13 日。后续修订版可能会有不同的数据。在租赁或购买硬件前，请务必核实最新信息。
Model Card 对 Kolibri-1 的规定
- 架构：MoE（Mixture of Experts，混合专家）。模型由许多子网络组成，这些子网络称为专家。每个 Token 只会执行其中少数专家。
- 规模：总计 78 billion 个参数，每个 Token 激活其中 3.46 billion 个参数。模型有 50 层，每层包含 384 个专家，每个 Token 会选择其中 6 个。
- 上下文：原生支持 262.144 个 Token。根据 Model Card，已验证长度达到 1.048.576 个 Token 时的质量。
- 权重：采用 FP8（8 位浮点数）格式
float8_e4m3fn，分块大小为 128×128。Embedding 和 LM-Head 使用 bfloat16。根据 Model Card，权重总计约 78 GB。Repository 本身大小为 78,9 GB。 - 训练数据：62,5% 为英语，23,9% 为德语，13,6% 为代码；预训练规模为 20 trillion 个 Token。此外还使用了一个根据 Model Card 针对德语词结构优化的 Tokenizer。
- 许可证：Apache 2.0。Repository 未设置访问门槛。因此无需提交访问申请。
最重要的信息在前两行。每个 Token 激活 3.46 billion 个参数，意味着每个 Token 所需的计算量较小。但内存需求取决于全部 78 billion 个参数。Router 会为每个 Token 选择不同的专家。因此，所有专家都必须始终驻留在 GPU 显存中。MoE 模型的计算量类似小模型，但显存占用类似大模型。
Tokenizer 也会产生实际影响。Tokenizer 会将文本拆分为 Token。如果它不适合目标语言，一个较长的德语单词可能会被拆分成许多小片段。这会消耗更多上下文和计算时间。针对德语优化的 Tokenizer 处理相同文本时需要更少的 Token。
Model Card 的基准测试数据
Aleph Alpha 为训练后的模型给出了两个总体分数。这些数据来自厂商自己的评估，而不是独立测试。
此图表背后的数据
[
{
"label": "Deutsch (Overall DE)",
"overall": 70.8
},
{
"label": "Englisch (Overall EN)",
"overall": 75.5
}
]根据 Model Card，Kolibri-1 的德语得分为 70.8，英语得分为 75.5。因此，该模型在英语上的表现也略强。它是否适合你的任务，只能通过使用你自己的文档进行测试来判断。
与 Pharia 相比的变化
Aleph Alpha 之前的模型系列名为 Pharia。Pharia-1-LLM-7B-control 的 Model Card 使用 Open Aleph License。该许可证允许非商业研究和教学。商业使用需要直接联系 Aleph Alpha。相比之下，Kolibri-1 使用 Apache 2.0。你可以在企业中使用该模型，也可以修改后再分发，但必须同时提供许可证文本和相关声明。
Kolibri-1 需要哪种 GPU？
该卡片列出了两个级别。最低要求：2× A100 80 GB、2× H100 SXM5、1× H200、1× B200 或 1× B300。推荐配置：2× H100 SXM5、2× H200、1× B200 或 1× B300。
为什么单张 H100 不够？计算很简单。从显存（VRAM，video random access memory）中减去模型权重占用的空间。剩余空间主要需要由 vLLM 用于 KV 缓存。KV 缓存为上下文中的每个 Token 保存 Attention 层的键和值（keys 和 values）。没有 KV 缓存，模型就无法保留上下文。
此图表背后的数据
[
{
"config": "1\u00d7 H100 80 GB",
"vram_gb": 80,
"gewichte_gb": 79,
"rest_gb": 1
},
{
"config": "1\u00d7 H200",
"vram_gb": 141,
"gewichte_gb": 79,
"rest_gb": 62
},
{
"config": "2\u00d7 A100 80 GB",
"vram_gb": 160,
"gewichte_gb": 79,
"rest_gb": 81
},
{
"config": "2\u00d7 H100 SXM5",
"vram_gb": 160,
"gewichte_gb": 79,
"rest_gb": 81
},
{
"config": "2\u00d7 H200",
"vram_gb": 282,
"gewichte_gb": 79,
"rest_gb": 203
}
]一张 H100 有 80 GB 显存，权重占用 79 GB。按计算结果，剩余 1 GB。这不足以支持有意义的上下文。一张 H200 可释放 62 GB，两张 H200 可释放 203 GB。实际可用余量更小。vLLM 默认只使用 92% 的显存（--gpu-memory-utilization，vLLM 0.29.0 中的默认值为 0.92），激活值也需要占用空间。这些数值是四舍五入后的粗略计算，不是实测结果。
该架构的两个特性可以降低 KV 缓存的压力。第一，根据该卡片，Kolibri-1 按 4:1 的比例组合使用 Sliding-Window-Attention 层和完整 Attention 层。Sliding-Window 层只保存固定窗口中的 Token。因此，其缓存不会随完整上下文长度增长。第二，该卡片建议使用 --kv-cache-dtype fp8。这样，每个缓存条目占用的显存只有 16 位精度下的一半。不过，完整 Attention 层仍会随每个 Token 增长。在 262.144 个 Token 的上下文下，单张 H200 的显存仍然很紧张。
为什么普通 VPS 无法运行 Kolibri-1
Aleph Alpha 仅发布了基于 GPU 的 vLLM 运行路径。模型卡中未提及 CPU 运行、GGUF、llama.cpp 或 Ollama。普通的 CPU VPS 没有显存，因此不具备运行该模型的基础。
尽管如此，Hugging Face 上仍有社区提供的 GGUF 转换版本。搜索 “kolibri-1 gguf” 的结果显示，2026 年 10 月 6 日有 8 个 Kolibri-1 存储库，到 2026 年 10 月 13 日已增加至 11 个。Q4_K_M 文件大小约为 47.5 GB，理论上可以放入 64 GB RAM 的服务器中。然而，我们在 2026 年 10 月 6 日核查的存储库明确指出：标准的 llama.cpp 无法识别 kolibri1 架构。你需要使用特定提交（commit）的补丁版本。截至 2026 年 10 月 13 日，情况未变：llama.cpp 仅有一个关于 Kolibri-1 的开放功能请求。一些作者确实测试了长上下文。Prompt48 报告称，在 A100 上使用 Q4_K_M 版本，在 195,935 token 处能准确找回测试信息（Needle），扩展上下文后在 718,803 token 处也能找回。Hob-forge 在使用 -c 262144 的运行中，在高达 253,646 token 的范围内找回了三个隐藏事实。这些仅是检索测试，而非基准测试。Prompt48 和 Hob-forge 明确表示，目前缺乏与 FP8 原版模型的基准测试对比。对于企业数据而言，这尚不足以作为生产基础，目前仍处于实验阶段。
关于模型在不同量化下所需的 RAM 大小，请参考 LLM 所需 RAM 大小指南 中的逐步计算方法。关于为何此处使用 vLLM 作为工具，请参阅 Ollama 与 vLLM 的对比：vLLM 专为 GPU 上的高并发请求而构建，而 Ollama 则适用于快速启动量化模型。
安装 Kolibri-1 与 vLLM
你需要一台配备合适 NVIDIA GPU 并已安装驱动的 Linux 服务器。租用服务器时需要注意的事项，请参阅GPU VPS 概览。先检查机器实际配置：
nvidia-smi --query-gpu=name,memory.total --format=csv输出会列出每张卡的名称和 MiB 单位的显存。H100 应报告约 81.000 MiB，H200 应报告约 143.000 MiB。如果命令没有报告驱动，说明尚未安装 NVIDIA 驱动。此时 vLLM 也无法找到 GPU。
然后创建独立的 Python 环境。该软件包会在固定版本范围内安装 vLLM 和 PyTorch。在独立环境中，这不会影响服务器上的其他程序。
sudo apt update && sudo apt install -y python3-venv
python3 -m venv ~/kolibri
source ~/kolibri/bin/activate
pip install 'aleph-alpha-inference==1.0.0'
pip show vllm aleph-alpha-inference该 Card 会写入 pip install 'aleph-alpha-inference>=1'。这里将版本固定为 1.0.0。这样，后续版本就不会在你不知情的情况下更改当前配置。版本 1.0.0 要求 Python 3.10 或更高版本，以及 vLLM 0.29.0 或更高但低于 0.30.0 的版本。因此，pip show 应显示 vLLM 0.29.x 版本。该软件包是 vLLM 的插件。它会为推理和工具调用注册解析器 kolibri1。没有该插件，vLLM 不认识这些名称。
Aleph Alpha 还提供容器镜像：ghcr.io/aleph-alpha/aleph-alpha-inference。如果你使用容器运行 GPU 服务器，也可以采用这种方式。
禁用 vLLM 遥测
vLLM 默认会发送匿名使用统计信息。如果要求任何内容都不能离开服务器，请在启动前将其禁用：
export VLLM_NO_USAGE_STATS=1
export DO_NOT_TRACK=1启动服务器
该命令遵循 Card 中的命令，并增加固定修订版本和 localhost 绑定：
vllm serve Aleph-Alpha/Kolibri-1 \
--revision e52eb4627d11516b0c01de49210ab5a4e4061444 \
--host 127.0.0.1 --port 8000 \
--kv-cache-dtype fp8 \
--reasoning-parser kolibri1 \
--tool-call-parser kolibri1 \
--enable-auto-tool-choice--revision 确定要加载的权重版本。不使用此选项时，vLLM 会从 main 加载当前版本。如果 Aleph Alpha 修改了该存储库，模型会在下次下载时发生变化。--host 127.0.0.1 使 API 只能在本地访问。不使用此选项时，vLLM 会监听所有网络接口。只要防火墙允许，端口 8000 就会开放。
使用 2 个 GPU 时，添加 --tensor-parallel-size 2。此选项会将每一层分配到两张卡上。不使用此选项时，vLLM 只使用一张 GPU，而权重无法放入单张 80-GB 显卡。
首次启动时，vLLM 会从 Hugging Face 下载约 79 GB 到 ~/.cache/huggingface。请为此下载和 Python 环境预留足够的磁盘空间。首次成功下载后，可以使用 export HF_HUB_OFFLINE=1 阻止后续与 Hugging Face 的所有连接。之后权重只会从本地缓存加载。
如果显存不足以支持完整的 262.144 Token 上下文，vLLM 将无法启动。错误消息会指出，用于最大序列长度的 KV 缓存过小。此时请设置更小的上限，例如 --max-model-len 65536。Card 使用 --max-model-len 1048576 和 --hf-overrides '{"max_position_embeddings": 1048576}' 启动扩展上下文，最多支持 1.048.576 Token。这需要明显更多的显存，应仅用于推荐配置。
检查模型是否响应
日志报告服务器已在端口 8000 上运行后，测试兼容 OpenAI 的 API：
curl http://127.0.0.1:8000/v1/models
curl http://127.0.0.1:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model": "Aleph-Alpha/Kolibri-1", "messages": [{"role": "user", "content": "Was ist die Hauptstadt von Frankreich?"}], "chat_template_kwargs": {"enable_thinking": false}}'第一个请求应将 Aleph-Alpha/Kolibri-1 列为模型。第二个请求应返回 JSON，其中 choices[0].message.content 指出巴黎。enable_thinking: false 会为本次请求关闭推理模式。默认情况下，该模式处于启用状态。根据 Card，reasoning_effort 也会使用值 none 生效。Card 建议的采样参数为 temperature=1.0、top_p=0.97 和 top_k=128。
从你的计算机访问时，不需要开放端口。SSH 隧道即可满足需求：
ssh -L 8000:127.0.0.1:8000 user@dein-server之后，你可以在计算机上通过 http://127.0.0.1:8000 访问 API。如果需要让网络中的其他服务访问，请同时设置 --api-key，并在前面配置带 TLS（transport layer security）的反向代理。
Kolibri-1 每小时的成本是多少（欧元）？
GPU 租赁价格会因提供商和地区而大幅波动。以下计算基于截至 2026 年 10 月的两个假设：H200 按需租赁价格为每小时 3.50 欧元，H100 SXM5 按需租赁价格为每小时 2.50 欧元，均不含增值税。专业 GPU 提供商的价格有时更低，欧盟地区的 hyperscaler 通常明显更高。请替换为你自己的报价。计算方法不变。
此图表背后的数据
[
{
"plan": "1\u00d7 H200, rund um die Uhr",
"eur_pro_stunde": 3.5,
"stunden_pro_monat": 730,
"eur_pro_monat": 2555
},
{
"plan": "2\u00d7 H100 SXM5, rund um die Uhr",
"eur_pro_stunde": 5,
"stunden_pro_monat": 730,
"eur_pro_monat": 3650
},
{
"plan": "1\u00d7 H200, nur B\u00fcrozeit",
"eur_pro_stunde": 3.5,
"stunden_pro_monat": 176,
"eur_pro_monat": 616
}
]一个月平均有 730 小时。H200 全天运行时，每月成本为 2555 欧元。推荐的双 H100 方案每月成本为 3650 欧元。如果只在办公时间运行，即每个工作日运行 8 小时、每月 22 个工作日，共 176 小时，则需支付 616 欧元。但每次启动都需要重新将权重加载到显存中，这需要几分钟。
什么时候相比 API Token 更划算？
截至 2026 年 10 月，Card 没有列出 Kolibri-1 的托管 API。因此，与 Token 价格进行比较，实际是将自有 GPU 上运行的 Kolibri-1 与通过 API 使用的其他模型进行比较。计算采用每 1 million Token 的两个假设价格，并将输入和输出混合计算：低价模型为 0.50 欧元，高价模型为 2 欧元。
此图表背后的数据
[
{
"plan": "1\u00d7 H200, rund um die Uhr",
"mio_token_bei_0_50_eur": 5110,
"mio_token_bei_2_eur": 1277.5,
"token_pro_sekunde_bei_0_50_eur": 1944
},
{
"plan": "2\u00d7 H100 SXM5, rund um die Uhr",
"mio_token_bei_0_50_eur": 7300,
"mio_token_bei_2_eur": 1825,
"token_pro_sekunde_bei_0_50_eur": 2778
},
{
"plan": "1\u00d7 H200, nur B\u00fcrozeit",
"mio_token_bei_0_50_eur": 1232,
"mio_token_bei_2_eur": 308,
"token_pro_sekunde_bei_0_50_eur": 1944
}
]按每 1 million Token 0.50 欧元计算，H200 全天运行只有在每月达到 5110 million Token 后才能覆盖成本。也就是说，平均每秒需要处理 1944 Token，并且昼夜不停运行。按每 1 million Token 2 欧元计算，办公时间方案的盈亏平衡点降至 308 million Token。单张卡能否根据你的 Prompt 长度和回答长度组合达到这一吞吐量，需要实际测量。该计算只能说明从哪个处理量开始值得讨论这个问题。
有关利用率和空闲时间的详细计算方法，请参阅GPU 服务器与 API Token 的盈亏平衡计算。对于 Kolibri-1，还需要考虑表格无法体现的一点。因数据原因希望自行托管 Kolibri-1 的用户，通常根本不会将其与 API 比较。如果文档不能离开本地环境，API 就不在选项之内。此时真正需要比较的是：在签订数据处理协议（AVV）的欧盟数据中心租用 GPU，还是购买自有硬件。租用的 GPU 同样位于第三方环境中。根据 GDPR（《通用数据保护条例》），这属于委托处理，而不是在自有场所运行。
何时诚实地选择更小的本地模型
如果你需要 Kolibri-1 的优势，使用它才有意义。根据模型卡，这些优势包括工具调用和长上下文文档处理。262.144 个 token 足以在一次请求中容纳整个合同文件夹。如果任务较短，成本计算就会不同。
整理电子邮件或生成简短摘要时，通常使用参数量为 7 到 14 billion 的模型就足够。经过 4 bit 量化后，它可以通过 Ollama 运行在配备 16 到 32 GB RAM 的 CPU VPS 上。它的速度比 GPU 慢，但每天处理几百个请求通常足够。这篇指南介绍了如何自行在 VPS 上托管 Ollama。这样只需支付普通服务器的月租，而不是按 GPU 使用小时计费。
同一厂商推出的一个显而易见的小型模型是 Pharia-1-LLM-7B-control。但根据许可证文本，其许可证 Open Aleph License 仅允许用于非商业和非管理目的。因此，它不适合企业使用。
只有通过测试才能做出可靠判断。从日常工作中选取 50 个真实任务。让 Kolibri-1 在按小时租用的 GPU 上处理这些任务，再让一个小型模型在 CPU VPS 上处理。然后比较两者的回答。租用几小时进行测试的成本，相比错误购买硬件的成本很低。
另一个开放模型对同一问题会给出怎样的结果，这篇指南介绍了自行托管 Kimi K3 所需的条件。这个对比有助于判断其规模：Kolibri-1 的权重约为 78 GB，属于仍可装入单张显卡的模型。
FAQ
我可以商业使用 Kolibri-1 吗？
可以。根据模型卡，Kolibri-1 使用 Apache 2.0 协议。你可以在企业内部使用它，也可以在附带许可文本和声明的前提下分发修改后的版本。这与之前的 Pharia 系列不同：Pharia-1-LLM-7B-control 的模型卡使用的是 Open Aleph License，该协议仅允许非商业和非行政用途。
Kolibri-1 能在 Ollama 或 CPU 上运行吗？
官方不支持。Aleph Alpha 仅发布了通过 vLLM 在 NVIDIA GPU 上运行的路径，并配合 aleph-alpha-inference 插件。虽然社区存储库提供了多个 GGUF 文件（如 Q4_K_M 版本，约 47.5 GB），但它们需要打过补丁的 llama.cpp，因为标准 llama.cpp 无法识别 kolibri1 架构。一些作者报告称在超过 700,000 token 的长上下文中通过了检索测试，但据他们自己所述，目前尚无与 FP8 原版模型的基准测试对比。
单张 80 GB 的 H100 足以运行 Kolibri-1 吗？
不足。FP8 权重本身就占用了约 78 GB。对于存储上下文的 KV Cache 而言，几乎没有剩余空间。模型卡建议的最低配置包括两张 H100 SXM5 或一张 H200。在使用两张显卡时，你需要通过 --tensor-parallel-size 2 启动 vLLM。
如何关闭 Kolibri-1 的思考模式？
思考模式默认开启。你可以在 JSON 请求体中通过 "chat_template_kwargs": {"enable_thinking": false} 关闭该模式。根据模型卡说明，使用 reasoning_effort 并将其值设为 none 同样有效。当模式开启时，--reasoning-parser kolibri1 会将思考内容与实际回答进行分隔。