Kolibri vs Intern-Decision 4B：一个撰写文档，另一个则完全拒绝写作

关于 Kolibri 和 Intern-Decision-4B，最值得注意的一点是，它们并非同一类对象，若把这当成模型与模型之间的比较，就会犯下范畴错误。Kolibri 是 Aleph Alpha 于 2026 年 10 月 3 日发布的 781 亿参数混合专家语言模型，每个 token 激活 34.6 亿参数，可撰写德语和英语文本。Intern-Decision-4B 是来自 InternLM 团队的 45.4 亿参数多模态结构化决策模型，于 2026 年 9 月 26 日上传至 Hugging Face；其模型卡明确写道，它“完全不调用 generate()，也不采样自由形式文本”。一个生成散文。另一个在单次前向传播中，针对你提供的选项输出概率分布，并且没有能力写出一个句子。它们只会在一种狭窄的情形下才成为同类可比对象，而准确知道那究竟是哪种情形，恰恰是这两次发布中最有用的信息。

两次发布，两种截然不同的简短说法

Kolibri 的模型卡是一份大型稀疏语言模型的规格说明：50 层，每一层都是专家混合，每层 384 个专家，其中有 1 个共享专家和 6 个路由专家，原生上下文为 262,144 个 token，已验证可支持到 1,048,576，四档推理强度级别，带有随附 vLLM 解析器的 Hermes 风格工具调用，以 128×128 块存储的 FP8 权重，以及 Apache 2.0 条款。其训练在 768 块 NVIDIA B200 上历时 21 天，使用了 20 万亿个 token——392,000 GPU 小时，报告算力为 6.4×10²³ FLOPs，估计耗电 9.5×10² MWh，包含数据中心开销，不包含监督微调和强化学习。模型卡给出的最低服务配置是两张 A100 80 GB 卡、两张 H100 SXM5、一张 H200、一张 B200 或一张 B300，FP8 占用空间约为 78 GB。它是一套严肃的基础设施，而它通过生成文本来回答问题。

Intern-Decision-4B 是另一种截然相反的对象，而它的卡片对此直言不讳，令人耳目一新。它是在 Qwen3.5-4B 上微调得到的模型，其中视觉塔和投影器被冻结，只有语言主干参与训练。你给它一个状态、一个由命名问题组成的模式，以及可选的至多八张图像，它就会一次性返回每个问题在候选答案上的分布。其机制很不寻常，值得精确说明：选项被映射到覆盖 A 到 Z、a 到 z 以及 0 到 9 的单 token 符号——共 62 个候选，因此每个问题最多可有 62 个选项——提示中每个字段用一个占位符渲染，模型读取每个占位符紧前位置的 logits。Softmax 只在属于该字段的允许符号 logits 上运行，特定检查点的温度会校准结果，而这些符号会按所输入的 JSON 映射回你原来的选项值。没有解码循环，没有采样，也没有自然语言文本。

• 输出 — Kolibri：自由生成的德语或英语文本、工具调用、推理轨迹。Intern-Decision-4B：带有每个选项概率的类型化 JSON 答案。

• 参数 — Kolibri：总计 78,103,074,560，激活 3,457,573,120。Intern-Decision-4B：45.4 亿，分布在四个 bfloat16 格式的 safetensors 分片中，并带有冻结的视觉塔。

• 输入 — Kolibri：仅文本。Intern-Decision-4B：文本加最多八张图像。

• 问题容量 — Intern-Decision-4B：每个字段最多 62 个选项，一次前向传播即可处理，支持 'choice'、'score' 和 'noul'（是/否）问题类型。Kolibri：原则上无上限，实践中一次一个 token。

• 语言 — Kolibri：从构建上即为德语和英语。Intern-Decision-4B：Qwen3.5-4B 所带的任何语言，所有已发布的评测套件均为英语。

• 延迟 — Intern-Decision-4B：根据其自身测量，在单块 RTX 4090 上，每次查询平均为 44.16 毫秒、中位数为 44.03 毫秒、P95 为 44.60 毫秒。Kolibri：完全没有公布任何每次查询的数据。

• 许可证——{{1}}两者均为 Apache 2.0{{/1}}；Intern-Decision-4B 随附时保留了 Qwen 许可证文件。

为什么竟然会存在一个 4B 评分器

为Intern-Decision-4B辩护的理由不在于它小，而在于向大型生成模型询问一个概率，并不等同于测量一个概率，而这一差异是可测量的。

模型卡自己的基准测试表以一种不同寻常的自我披露程度提出了这一论点。在七个准确率测试套件上，Intern-Decision-4B 平均为 90.02——而它拿来对比的最强基线模型 Jev 为 88.74。但准确率是无趣的那一半。表中还报告了 Brier 分数和期望校准误差，而那里的情况更为严苛。4B 的 Brier 为 0.347，ECE 为 0.065，而 Jev 为 0.358 和 0.095。校准问题的故事真正变得有信息量，是在较小的同门模型那里。Intern-Decision-2B 平均得分为 84.68，远高于 0.8B 的 79.38——然而其 ECE 为 0.100，比 0.8B 的 0.066 更差，也比 4B 的 0.065 更差，同时 Brier 为 0.437，而 0.8B 为 0.530。两个小模型中更准确的那个，对自己的置信度最不诚实。如果你曾假设校准会随着准确率提高而改善，或随着参数量增加而改善，那么这张表在这两点上都是反例。

第二个独立的诊断覆盖 96 个案例，这些案例使用精确的参考分布而非采样的硬标签构建——随机抽取、复合事件、条件历史、概率谜题。在该试点中，4B 模型在所报告的指标上的误差从 0.628 降至 0.550，而对比模型为 0.595。模型卡明确指出，该试点并未用于拟合或选择所发布的温度；4B 的温度 1.992418 是在校准集上单独拟合得到的。InternLM 团队还将基准本身发布到了 GitHub 仓库中——包括确定性生成器、参考答案和离线评分器——这意味着该校准声明属于第三方真正可以复现、而非只能凭信接受的那一类。

Kolibri 的发布内容中没有提供任何等价物。它的对比表报告了十四个模型在同一个供应商测试框架上的任务准确率，而准确率正是生成模型所能被衡量的指标。材料中没有任何校准数值，也没有 Brier 或 ECE，而且没有办法在不涉及一句话并阅读它的情况下，向它询问“该合同条款可执行的概率”。

它们真正相遇的那道缝隙

把两者放在同一条真实的工作流里并排比较，各自的形态就一目了然了。德语文档工作流两半都需要，而任何一款工具都无法覆盖另一半。

Kolibri 是负责读取和写入的那一半。对于持有德语合同或技术文档的团队，它拥有 262,144 个 token 的原生窗口、FP8 KV 缓存、一个双语分词器（Aleph Alpha 报告其在德语网页文本上的平均值为每 token 4.90 字节），以及 Hermes 工具调用——也就是说，这个模型能够总结一份申报文件、起草一封回复，并驱动一个工具循环。它做不到的是，以你可以审计的方式告诉你它自身的置信度，因为它输出的一切都是采样得到的字符串。

Intern-Decision-4B 是负责决策的那一半。给定一页德语文本和一组固定选项，它能在一块消费级 GPU 上于 44 毫秒内返回一个经过校准的分布，无需生成步骤，因此完全不存在采样方差。它做不到的是首先生成德语文本，而且其已发布的评估套件都是英语的——它的德语行为继承自 Qwen3.5-4B 基座，而非经过专门训练，这对于德语部署而言是一个真实存在的局限，并且没有人对此进行过评估。

因此，对于受监管的德语工作流，诚实的工程答案是：它们是同一条流水线的两个阶段，而不是同一个位置的两种候选方案。实际的问题是各自在哪里运行。Kolibri 需要两块 H100 或一块 B200，以及约 78 GB。Intern-Decision-4B 需要一块 RTX 4090，运行一次查询不到 45 毫秒。硬件上的成本不对称约为两个数量级，这指向一种设计：小型评分器对每个案例持续运行，而大型生成器只在案例确实需要成文表述时才被调用。相比把每个案例都送进 78B 模型以得到一个随后还得由你解读的答案，这是一种更便宜、也更便于审计的形态。

两者的托管现实，以及该层的用途

两个模型都没有以托管 API 的形式提供，而我们是核实过才这么说的，而不是想当然。Intern-Decision-4B 没有厂商端点；其发布形式是权重、一个 GitHub 仓库和一个 Hugging Face Space。自本周中以来，它的下载量和点赞数都有变化，这说明人们正在采用它，但在任何我们愿意点名的渠道中，仍然没有可付费调用的路径。

Kolibri 同样没有 Aleph Alpha API 的 SKU——其发布物是权重、一份技术报告，以及位于 ghcr.io/aleph-alpha/aleph-alpha-inference 的容器镜像。而且它不在 OrcaRouter 上：我们以供应商前缀和模型名称的每一种拼写检索了目录，结果都返回“未找到”；这一点我们宁愿直说，也不愿暗示并非如此。

路由层在这里改变的不是对这两个模型的访问，而是决定是否为其中任何一个买单的经济账。一个 OpenAI 密钥 按提供商的标价，不加任何附加项，看看德语文档工作负载是否真的需要 800 亿参数，然后再去订购 GPU。决策那一半没有这样的捷径，因为校准分布行为正是这个模型存在的全部意义，而没有任何路由层级能做到这一点。但这本身就是发现：它告诉你，4B 评分器才是你真正会自行托管的部分，而生成器则是值得用你今天下午就能拿到的东西重新测试的部分。

什么能了结它

两项测量，而这两者都尚不存在。

第一个是 Intern-Decision-4B 在德语输入上的表现。所有已发布的评测套件都是英语的，而该模型又是对一个多语言基座模型的微调，因此它在德语上的校准情况是未知的——而校准恰恰是那种不会跨语言免费迁移的特性。一个 96 案例分布试点的德语版本，将会是任何人都能发布的、关于这个模型的最有信息量的单一产物。

第二个是 Kolibri 的每次决策成本。其服务经济学主张是一条帕累托前沿：质量与每 GPU 每秒解码 token 数之间的权衡，而 Kolibri 没有 Artificial Analysis 页面，也没有第三方对测试框架的复现。在有人实际运行它之前，“780 亿参数”只是一项规格说明，而非一项成本；而要在其前面保留一个 44 毫秒评分器的理由，也仍停留在设计论证层面，而非经过实测的结论。

在那之前，看待这一组合的正确方式不是把它当成一场竞赛。两者之中，Intern-Decision-4B 是技术上更有趣的那个发布，因为校准感知的结构化输出是几乎没有生成模型提供的能力，而它的模型卡让你可以自行核实这一说法。Kolibri 则是影响更深远的那个发布，因为一家欧洲实验室以 Apache 2.0 许可发布 780 亿参数的模型、并同时公开数据流水线，这更像是一次供应链事件，而非单纯的模型事件。两者无法互相取代。同时需要两者的团队应当为两者都做规划，并据此确定硬件规模，而真正的工程投入其实落在它们周边的框架上。