Granite Switch 4.1 8B 对比 LFM2.5 2.6B Base：这里真的有得选吗？

这是这组对比里最不像公平较量的一个，所以我们干脆立刻把这一点说清楚，而不是假装它是公平的。Granite Switch 4.1 8B是 IBM 于 2026 年 10 月 14 日发布的复合检查点，由 87.8 亿参数构成：一个冻结的 Granite 4.1 8B，外加两个可切换适配器和一个语音编码器，可在同一个端点上完成对话、决策打分和转写。LFM2.5 2.6B Base则是 Liquid AI 于 2026 年 8 月 1 日发布的 26.9 亿参数预训练文本模型，专为端侧部署而打造——而且重要的是，它自己的模型卡就说明这是基础检查点，“仅推荐用于需要大量微调的任务”。把两者拿来比较，仿佛其中一个能替代另一个，这是范畴错误。比较它们反而能告诉你更有用的东西：各自的边界究竟落在哪里，以及为什么几乎没有人会在这两者之间做选择。

所以这并不是一场模型比拼。它是一张你实际会做出的决策地图——当你有边缘端目标和一个服务器端目标，并试图弄清楚哪个模型该部署到哪里时，所面对的就是这个决策。

每一个是干什么用的

LFM2.5 2.6B Base 是一种混合架构，而混合正是其关键所在。它共有三十层，其中 22 层是双门控短卷积块，8 层是分组查询注意力——因此整个堆栈以卷积为主而非注意力，这正是它能在小型硬件上压低内存占用和每 token 成本的原因。隐藏维度为 2,048，32 个查询头对应 8 个 KV 头，上下文长度为 131,072 token，词表规模为 128,000 token，预训练预算为 34 万亿 token。它列出了十六种语言：英语、阿拉伯语、中文、法语、德语、意大利语、日语、韩语、葡萄牙语、西班牙语、越南语、泰语、印尼语、印地语、俄语和波兰语。Liquid 将该系列描述为专为端侧部署而打造，并与原生检查点一同提供同系列的 instruct 模型，格式包括 GGUF、ONNX 和 MLX。

Granite Switch 4.1 8B 则把相反的本能用在相反的问题上。它没有缩小模型，而是保留了规模偏大的文本主干，并以横向方式增加能力。基础模型是 Granite 4.1 8B：40 层、隐藏维度 4,096、32 个查询头对 8 个 KV 头、131,072 token 上下文窗口、100,352 token 词表。在此之上是 guardian-core，一个作用于注意力投影的 rank-16 activated-LoRA 适配器，用于检测有害内容、越狱、粗俗语言、暴力、性内容、社会偏见和不道德行为；decision，一个作用于全部七个投影的 rank-64 适配器，可在单次前向传播中返回对带标签选项 token 的校准 softmax；以及 Granite Speech 5.0 TurboCTC，一个用于转录的 470M 参数非自回归 conformer 编码器。组合后的总参数量为 8,776,400,896，而基础模型为 8,380,551,168——增长了 4.72%。

起决定作用的维度：指令模型与基础模型

这两个检查点之间最大的区别不在于规模或架构，而在于一个是成品模型，另一个是原材料。

Granite Switch 4.1 8B 开箱即可调用。适配器已组合在内，控制 token 已通过聊天模板接通，决策适配器的调用方法配有可运行的代码文档，模型卡中列出了它所需的确切 Transformers 和 vLLM 版本。你下载它、运行它，它就能完成这三项任务。

LFM2.5 2.6B Base 从设计上就不会做这些。Liquid 自己的指南指出，这个检查点适用于“特定语言（例如日语）或特定领域（例如医疗）的助手、在专有数据上训练，或试验新颖的后训练方法”——而如果你想要的是一个开箱即用就能回答问题的模型，模型卡则会指向经过后训练的同系列模型。基础检查点没有可供比较的指令遵循行为，没有对齐，也没有聊天模板规范。把两者放在同一个评估中，Granite 模型会显得明显更好，而原因与哪个模型更好毫无关系：一个经过了后训练，另一个没有。

• 参数 — 8.78B 组合 vs 2.69B。

• 层 — 40 个稠密 Transformer 块，对比 30 个混合块（22 个双门控短卷积 + 8 个 GQA）。

• 上下文 — 131,072 tokens 对 131,072 tokens。完全打平，这很不寻常，值得注意。

• 词汇表 — 100,355（为适配器预留的三个 id）对 128,000。

• 模态 — 输入文本和音频、输出文本，对比仅文本。

• 检查点类型 — 已组合、经过后训练、可直接调用，对比用于微调的预训练基座。

• 许可证——Apache-2.0 与 LFM 1.0 许可证，而后者并非 Apache。这一区别在商业上至关重要，而且很容易被忽略。

• 已发布的证据——一项由供应商自行开展的 Decision Index，总体得分 42.9，且没有独立评估；相比之下，基础检查点没有可比较的公开基准。

2.69B 能为你带来哪些 8.78B 做不到的东西

可移植性，而且它不是一种软优势。一个 2.69B 模型，其 30 层中有 22 层由短卷积构成，就是为运行在设备上而设计的——笔记本电脑、手机级 SoC、嵌入式盒子——而 Liquid 正是为此提供了量化的 GGUF、ONNX 和 MLX 变体。一个 8.78B 的组合式检查点，外加一个 470M 的语音编码器，则是服务器端产物。它运行在 GPU 上，置身容器之中，藏在端点之后。

这意味着部署形态并不重叠：一种针对请求无法离开设备的情况，另一种针对请求可以离开设备的情况。如果约束是“无网络”，那么比较还没开始就已经结束，再多的组合也改变不了这一点。再加上许可证这一点——是 LFM 1.0 而非 Apache-2.0——那么，当你打算用自己的数据微调自己的模型并将其作为产品发布时，2.6B 检查点就是你会选择的那个；而当你希望在宽松许可证下今天就获得三种能力时，你会选择的则是 Granite Switch。

组合能给你带来什么 2.69B 给不了的东西？

一个端点，三项任务；得到的不是答案，而是一个概率。

决策适配器是在另一侧没有对应物的部分。给定一个状态和一个带有标注选项的问题，它会在一次前向传播中返回这些标签上的校准 softmax——文档记载的调用会向 vLLM 请求恰好是标签 token id 的 logprobs，通过 logprob_token_ids，并对它们取指数，得到形如 A: 0.982、B: 0.0035、C: 0.014 的输出。提示词给你一个 token；这个给你一个可以设阈值、求平均并取对数的数字。还有一个文档中记载的、在你基于它构建之前值得了解的小问题：vLLM 会将 logprob_token_ids 限制为每个请求 128 个 id，因此选项超过 128 个的问题需要将其标签 id 分块为每组 128 个，每个分块发一个提示词完全相同的请求，将结果拼接起来，并对完整的标签集合应用一次 softmax。因为返回的 logprobs 覆盖整个词表，所以每个标签的值与是哪个分块请求了它无关，因此分块后的结果与未设上限的调用在数学上完全相同。

同一端点上的语音是第二个。在普通聊天补全请求中发送一个 input_audio 内容部分，470M 编码器会先将其转写，再把转写结果拼接进上下文。IBM 的注意事项很具体，值得重复：仅支持英语、输出为小写且无标点，而且编码器与语言模型并非联合训练——两者之间没有经过训练的投影来耦合，因此误转写可能会悄无声息地改变模型所回应的内容。一个完全没有音频通路的边缘模型，面临的是另一个问题，而不是没有问题。

而第三个是安全适配器：一个有害内容与越狱分类器，搭载在同一个检查点上，当你传入 adapter_name 时，由聊天模板插入的控制 token 将其激活，而无需再部署并为之付费的第二个模型。

当答案是"两者都"时，路由器适合放在哪里

这个对比的现实版本最终会让两个模型落在同一个产品里。LFM2.5 2.6B Base，经过微调，运行在设备端，处理那些不能离开设备的数据；Granite Switch 4.1 8B，自托管，在服务端处理决策与转写。这就是一种两层架构，而它带来的运维问题是：接缝处会发生什么——设备端模型失败、服务器被打满、某个请求需要落到别的什么上面去。这两个检查点目前都不在 OrcaRouter 的目录中，所以我们并不是获取其中任何一个的途径；我们真正变得相关的节点，是它们背后的回退链。一个 API 密钥即可覆盖 200 多个托管模型，并具备自动故障转移，路由 DSL 让你能把多个模型组合进一次调用，而不必手动拼装扇出逻辑，而且供应商目录价按 0% 加价直通，因此厂商一降价，当天就能生效。img src="4.png" alt="OrcaRouter 模型目录的截图，标题为“210 个模型、16 家提供商、一个 API 密钥、一张账单”，模态分面显示 173 个文本、12 个图像、5 个嵌入、10 个视频和 10 个 TTS 模型，侧边筛选栏包含输入模态、上下文长度、输入价格、状态、访问层级、系列和支持的参数，还有一个按最新优先排序的模型卡片列表，开头是 OrcaCyber Zero 1.5、OpenAI GPT-6.1 Sol 和 Anthropic Claude Sonnet 5.5，并列出了它们每百万 token 的输入和输出价格。" /> 正是这一层让两层设计能够存活下去，而不是变得脆弱，也值得在边缘层开始在现场出故障之前就先部署到位。

判决，姑且如此

如果你打算进行微调，如果推理必须在设备端进行，或者如果 2.69B 的资源占用是硬性约束，就选择 LFM2.5 2.6B Base。如果你需要一个经过校准的决策分布、一个内联的安全分类器，或者从与聊天相同的端点进行转录，并且可以接受由 GPU 支持的容器，就选择 Granite Switch 4.1 8B。这两个用例之间的重叠几乎为零，这就是为什么对“哪个胜出”的诚实回答是：这个问题本身就不成立——也是为什么更值得带走的结论是：一个 2.69B 的基础检查点和一个 8.78B 的组合式指令模型并不是同一条质量线上的两个点。它们是两个不同的产品，只是参数数量恰好相邻。