Cactus Gemma 4 E2B Hybrid 增加置信度评分，但路由才是真正的考验

Cactus 发布了 Gemma 4 E2B Hybrid，直接挑战端侧 AI 通常面临的取舍。如今，每个回答都会附带一个介于零和一之间的置信度评分。应用程序可以将高置信度回答保留在本地，同时把不确定的请求发送给更大的云端模型。

这听起来只是输出上的一个小变化。实际上，它代表了小型 AI 系统的一种全新部署模式。

大多数本地模型要么回答所有请求，要么依赖单独的路由器来决定哪些请求应交给云端。Cactus 将决策信号直接放入模型检查点。该公司表示，这一信号来自内部隐藏状态，而不是添加到回答中的置信度表述。

这一区别很重要，因为小型模型不需要在每个请求上都击败云端模型。它只需要识别出自己能够可靠处理的请求。良好的路由信号可以让这种能力有限的模型成为更大型系统的第一阶段。

Cactus 声称，其最小的 Gemma 混合模型在仅升级部分工作负载的情况下，可以在大多数受测基准上媲美 Gemini 3.1 Flash-Lite。根据基准测试和数值精度的不同，报告的转交率从 15% 到约 90% 不等。

较低的数字为本地推理提供了颇具吸引力的理由。较高的数字则暴露了核心不确定性。该模型的实用性取决于任务、硬件格式、置信度阈值，以及本地错误回答所造成的成本。

因此，这次发布提出了一个比 Gemma 4 能否在手机上运行更重要的问题。一个嵌入式探针能否让文本、视觉和音频任务中的本地到云端路由都变得可靠？

Cactus Gemma 4 E2B Hybrid 将置信度转化为 API 输出

核心变化并非又一个小型模型，而是一个会随每个完整回答返回路由信号的模型检查点。

Cactus 在开放的混合模型代码库中介绍了其方法。首轮发布以 Gemma 4 E2B 为核心，这是 Google 新推出的 Gemma 4 系列中最小的模型。

根据官方 Gemma 4 模型卡，Google 将 E2B 和 E4B 模型定位于移动和边缘部署，而更大的 Gemma 4 变体则面向消费级 GPU 和工作站。

Cactus 对较小的模型进行后训练，加入一个读取其隐藏表征的探针。探针是一种轻量级学习组件，可将模型内部激活映射为有用的预测。

在这里，预测的内容是完整响应是否可能正确。应用程序会在接收回答的同时，以结构化数据的形式获得这一结果。

这种设计避免让模型写出“我的置信度为 85%”之类的短语。语言形式的置信度可能反映写作风格、指令微调或用户提示，并不一定与正确性相符。

结构化输出还避免了从生成文本中解析分数。这一选择降低了格式变化、提示注入或异常响应破坏路由逻辑的可能性。

Cactus 在其文档中展示了一种简单的阈值策略。当置信度低于 0.85 时，应用程序可以丢弃本地结果，转而询问更大的模型。

这一阈值只是示例，并非通用的安全界限。每位开发者都必须根据错误容忍度、流量、延迟和升级处理的后果自行选择。

笔记应用程序在总结非正式材料时，可能会接受更多本地回答。医疗或金融工作流则需要更严格的测试和额外的保障措施。

该模型可通过多种常见推理路径使用。Cactus 为其自有运行时、Hugging Face Transformers、Apple 的 MLX 框架以及经过修补的 llama.cpp 服务器提供了示例。

在每种情况下，目标都保持一致。回答和置信度评分应通过独立的输出字段返回。

该代码库采用 MIT 许可证，不过 Gemma 模型的使用仍须遵守 Google 的条款。相关检查点收录在公开的模型集合中。

这种开放性为开发者提供了比概念演示更实用的东西。他们可以测试检查点、检查集成代码、调整阈值，并衡量模型在自身工作负载上的表现。

不过，llama.cpp 路径需要编译补丁。Transformers 的说明还记录了特定的版本和设备加载限制。

这些细节揭示了一个重要的实际限制。嵌入式探针改变了模型接口，因此现有推理引擎无法自动理解它。

Cactus 减轻了集成负担，但并未将其完全消除。生产团队仍然需要兼容的运行时、部署测试，以及围绕置信度字段建立监控机制。

为什么置信度探针比原始模型规模更重要

当小型模型能够有选择地放弃作答，而不是假装可以同样出色地处理每个请求时，它才会变得更有价值。

其背后的理念称为选择性预测。当预估风险处于可接受范围内时，模型作答；当风险过高时，模型放弃作答。

早在 Cactus 发布之前，研究人员就已对这一框架展开研究。Selective-LAMA 研究发现，置信度感知评估能够揭示普通准确率分数所掩盖的弱点。

该研究还警告，不应假定 token 概率就是最佳置信度函数。一个表达流畅的模型可能为某个回答赋予很高的概率，但该回答在事实层面仍然错误。

Google 通过 ASPIRE 探索了另一种方法。ASPIRE 是一种选择性预测方法，它会修改模型并对其进行训练，以生成更好的选择分数。其选择性预测研究报告称，相比多种基线方法，它取得了更高的 AUROC 结果。

AUROC 衡量所有可能阈值下的排序质量。0.5 分表示随机区分，1.0 分则表示能够完美区分正确和错误的输出。

AUROC 并不意味着置信度为 0.85 的回答有 85% 的概率是正确的。要得出这种结论，还需要进行校准分析。

相反，AUROC 考察的是正确回答是否通常比错误回答获得更高的分数。良好的排序能力使系统能够保留更安全的请求，同时升级处理风险更高的请求。

Cactus 报告称，在 12 项文本、视觉和音频评估中，其平均 AUROC 为 0.814。token 熵基线的平均值为 0.549。

token 熵用于衡量预测 token 之间的不确定性。它颇具吸引力，因为许多推理系统无需训练其他组件即可计算该指标。

报告中的差距表明，与单纯的 token 级不确定性相比，内部探针能够捕捉到更有用的正确性信号。在独立评估重现这些测试之前，这一结论仍只是该公司的说法。

不同基准测试的结果各不相同。Cactus 报告称，MMLU 上的得分为 0.770，MMLU-Pro 上为 0.771；ARC-Easy 上为 0.888，ARC-Challenge 上为 0.834。

视觉测试结果包括 MMBench 上的 0.840、ChartQA 上的 0.779，以及 DocVQA 上的 0.781。相应的 token 熵得分介于 0.435 到 0.615 之间。

音频测试产生了此次发布中最有意思的结果。Cactus 表示，该探针没有使用任何音频训练数据，但在四项音频基准测试中取得了 0.789 到 0.876 的 AUROC 分数。

这些基准测试包括 MMAU、GigaSpeech、Earnings-22 和 LibriSpeech。在相同任务中，token 熵得分介于 0.323 到 0.517 之间。

Cactus 将这种迁移解释为探针能够读取与模态无关的正确性信号的证据。这种解释具有合理性，但现有证据尚不足以完全证实其机制。

探针可以利用基准测试之间持续存在的相关性，而不一定是在普遍意义上表征正确性。数据集中的隐藏模式、回答长度、解码行为和评估规则都可能影响性能。

零音频训练的结果仍然值得关注。如果独立测试能够证实这一点，开发者或许不再需要为每种输入模态单独建立置信度系统。

这对于处理文档、图像、会议录音和语音问题的助手尤其有用。一个路由接口就可以覆盖多种媒体类型。

构建这些应用程序的团队还需要上下文，而不仅仅是模型置信度。在路由开始之前，本地访问以往的决策、笔记和文档可以改善输入。

可搜索的个人知识库可以提供这些上下文。随后，置信度探针会处理另一个独立问题：是否应信任本地生成的回答。

真正的竞争在于本地优先还是默认使用云端

Cactus 主张应由不确定性而非模型规模决定每个请求在哪里运行，以此向云端优先推理施压。

云端优先系统会将每个提示发送到远程服务。这种设计可以稳定地使用更大的模型，但每个请求都依赖网络连接和外部基础设施。

本地优先系统将处理保留在设备上。它可以减少网络暴露、支持离线工作，并且无需经过云端往返即可响应。

两种路径都无法在所有场景中胜出。小型本地模型受到更严格的内存和计算限制，而云端模型可以提供更广泛的能力和更频繁的更新。

混合路由试图将每个请求分配给成本更低或隐私性更高、同时仍能提供可接受回答的路径。路由器成为系统的控制点。

Cactus 报告了 Gemma 4 E2B Hybrid 在部分基准测试上达到 Gemini 3.1 Flash-Lite 水平所需的转交率。这些数据来自该公司，并非独立审计结果。

在完整 FP16 精度下，ChartQA 的云端处理占比据称为 15% 到 20%。在 MMBench、GigaSpeech 和 MMAU 上，这一比例达到 30% 到 35%。

LibriSpeech 据称需要 25% 到 30% 的转交率。MMLU-Pro 的表现则逊色得多，需要将 45% 到 55% 的请求发送至云端。

量化改变了整体局面。量化会降低数值精度，使模型占用更少的内存，并能在资源受限的硬件上更高效地运行。

在四位精度下，ChartQA 据称所需的转交率上升至 25% 到 30%。MMBench 和 GigaSpeech 则上升至 40% 到 45%。

在四位精度下，MMLU-Pro 需要将约 90% 的请求转交给云端。Cactus 没有报告该基准测试的三位精度结果。

如此大的差异使人无法简单地声称本地模型能够处理大多数请求。它只有在特定任务、模型格式和质量目标下才能处理大多数请求。

图表读取应用程序或许可以将大部分工作负载保留在本地。类似 MMLU-Pro 的高难度知识任务在量化后可能几乎无法从中受益。

比较对象同样重要。达到 Gemini 3.1 Flash-Lite 的水平，并不等同于达到现有最大型云端模型的水平。

生产团队可能会选择更强的备用模型，因为需要升级处理的请求本来就是困难案例。这种变化可以提高质量，但也可能增加延迟或运营成本。

路由还会带来两种用户体验。本地回答可以快速返回，而升级处理的回答则必须等待网络传输和云端推理。

开发者必须决定在这段延迟期间显示什么。他们可以展示进度状态、以流式方式输出云端替代回答，或明确告知用户更强大的模型正在检查回答。

应用还必须控制哪些内容会离开设备。置信度分数并不能确保敏感内容可以安全上传。

如果请求包含私人会议记录、客户资料或专有代码，应用就需要制定单独的数据策略。低置信度不应自动覆盖隐私限制。

一种可行的策略可以综合多项信号。系统可以先检查敏感度，再检查连接状况、置信度、延迟预算和可用的云端模型。

根据这项策略，部分不确定的请求仍会保留在本地处理，但会显示明确警告。其他请求则可以路由到私有企业端点，而非公共服务。

因此，主要竞争发生在架构层面。Cactus 并非只是在比较某个 Gemma 检查点与某个 Gemini 端点。

它真正探讨的是：云端调用是否应当成为由测得的不确定性触发的例外。如果这一模式有效，应用便可以将本地推理作为默认执行层。

基准测试仍未证明什么

报告的 AUROC 结果展现了可喜的排序能力，但尚未证明置信度经过校准，也未证明其具备生产环境可靠性。

第一个尚未解决的问题是校准。零到一之间的分数看起来像概率，但其数值形式并不会使它自动成为概率。

经过校准的 0.80 分数应当意味着，在可比预测中，正确率约为 80%。但 Cactus 主要报告的是衡量排序表现的 AUROC。

路由器可能在排序方面表现良好，同时仍给出具有误导性的绝对分数。因此，开发者应当在具有代表性的验证集上选择阈值。

第二个问题是分布偏移。基准测试提示词比实际部署的助手所收到的请求更干净、更稳定。

真实用户会混合使用不完整的问题、私有术语、不断变化的事实、附件、转录错误和相互冲突的指令。这些输入既可能改变回答质量，也可能改变置信度表现。

音频迁移结果涉及一种分布偏移，但并未覆盖所有生产环境条件。新的口音、背景噪声、专业词汇和长录音仍是需要测试的相关场景。

第三个问题是选择性准确率。开发者需要知道，在每种云端预算下保留的回答中，错误率是多少。

AUROC 汇总了所有阈值下的表现，但不能直接揭示某个特定阈值是否满足产品要求的准确率。

生产环境评估应绘制覆盖率与风险之间的关系。覆盖率是由本地回答的请求占比，而风险是这些保留请求中的错误率。

团队还应将混合系统与更简单的替代方案进行比较。token 熵是一种基线方案，但并非唯一可用的路由器。

其他选择包括重复采样、语义一致性、独立验证器、检索置信度、提示词分类，以及基于任务类型的规则。

有些方法需要更多计算资源。另一些方法则可以在生成前运行，从而避免把本地计算资源浪费在无论如何都会转到云端的请求上。

Cactus 对已经完成的生成结果进行评分。这样的时序意味着设备会先承担生成回答的成本，之后可能丢弃该回答，并在远端重复处理请求。

这种方式仍能减少云端调用，但无法最大限度降低总计算量。对于明显困难的提示词，生成前路由器可能更快。

一种组合设计可以在生成前对请求分类，并在生成后应用探针。简单请求保留在本地，明显需要升级的请求跳过本地生成，而模棱两可的情况则同时使用这两个阶段。

第四个问题是基准测试的归属。Cactus 发布了检查点、代码、声称的结果和实现说明，这有助于外部审查。

然而，该代码库并未提供相当于经同行评审且得到独立复现的评估。因此，报告的数字仍应明确归因于 Cactus。

第五个问题是回退质量。更强大的云端模型并不能保证替代回答正确。

如果两个模型存在相同的训练盲区，或以相似方式理解提示词，升级处理可能会重复最初的错误。应用仍然需要来源依据和针对特定领域的验证。

对于文档问题，检索质量可能比模型大小更重要。更大的模型无法根据缺失的合同条款或过时的项目记录给出正确回答。

这使工作流上下文成为路由的重要补充。将当前文档与既往工作相结合的系统，可以在任一模型回答之前降低不确定性。

知识融合工作流可以为此整合相关的本地信息。随后，路由分数可以帮助判断生成的回答是否需要更强大的推理能力。

高风险应用还需要额外一层保障。医疗、法律、安全和金融类输出即使模型置信度很高，也可能需要人工审核。

置信度分数应当为风险策略提供支持，而不是取代风险策略。当自信地犯错所造成的代价高于升级处理的代价时，这一区别至关重要。

为什么这次发布正逢其时

Gemma 4 提供了一个小型多模态模型，而设备硬件和云端成本使选择性执行变得越来越重要。

如今，小型模型能够处理的不再只是短文本补全。Gemma 4 E2B 面向文本、视觉和音频工作负载，同时定位为适合边缘级部署的模型。

输入范围的扩大改变了本地 AI 的经济性。一个助手可以解读拍摄的图表、转录语音、总结文本并回答后续问题。

然而，多模态能力也带来了难度不均的问题。读取清晰图表与理解嘈杂音频或解答专业知识问题截然不同。

仅依据模态制定的固定路由策略会忽略这些差异。基于置信度的路由试图在单个回答层面作出决策。

这种方法也适用于正在兴起的 AI 智能体。智能体通常会执行许多小型操作，而不是只处理一个孤立的请求。

会议工作流可能包括转录音频、识别决策、创建任务、起草摘要，以及回答有关讨论内容的问题。将每个步骤都发送给大型模型可能过于浪费。

混合系统可以在本地完成常规提取和格式化，并将模棱两可的决策、相互冲突的陈述或困难的跨文档问题升级处理。

然而，置信度传播成为了一项新挑战。即使后续每个回答看起来都很有把握，早期错误仍可能污染之后的步骤。

因此，智能体开发者应当将置信度与中间输出一同存储。如果前面的关键步骤获得低分，他们还应重新评估下游工作。

同样的原则也适用于离线使用。在旅行、现场工作或网络故障期间，设备可能无法连接任何云端回退服务。

在这种情况下，即使无法路由，置信度仍然有用。应用可以拒绝回答、警告用户、保存请求，或在恢复连接后重试。

因此，Cactus 为开发者提供了两种相互关联的能力：在云端可用时支持自动移交，在云端不可用时直观呈现不确定性。

这比模型使用谨慎措辞更为具体。结构化分数可以驱动应用行为、监控和策略执行。

不过，如果没有经过校准，开发者应避免直接向用户展示该数字。“置信度 0.82”听起来非常精确，即使其实际含义会因任务而异。

更好的界面可以将经过验证的分数区间转化为操作。应用可以正常回答、请求澄清、核查来源，或将任务发送审核。

这种设计让不确定性信号具有可操作性，而无需用户在日常工作中解读机器学习指标。

这一时机也反映了模型提供商面临的压力。如果小型模型能够安全地保留更多请求，云端供应商处理常规任务的推理量就会下降。

与此同时，混合系统可能会增加最困难请求对云端模型的需求。供应商可能会推出专门的回退端点，或自己的设备—云端路由层作为回应。

硬件公司同样有动力支持这一模式。更完善的运行时集成可以在无需自定义补丁的情况下公开探针输出，并减少 Cactus 当前文档中提到的阻力。

因此，这次发布是更大趋势转变的早期实现。模型选择正在从产品级决策转变为针对每个请求的决策。

三项信号将决定 Cactus Hybrid 能否经受住考验

独立复现、真实设备上的覆盖率曲线，以及原生运行时支持，将决定它会成为一种架构，还是仅仅停留在一个前景可期的检查点。

第一项信号是独立复现基准测试。研究人员和开发者需要使用已发布的检查点复现报告的 AUROC 结果。

在测试替代方案前，复现工作应保留 Cactus 的评估设置。这样才能区分实现差异与模型行为。

最需要验证的结果是跨模态迁移。在没有使用音频训练探针的情况下获得相近的音频表现，将进一步支持存在共享正确性信号这一观点。

如果性能大幅下降，则会削弱这种解释。这可能表明结果容易受到解码设置、数据集准备方式或未记录的评估选择影响。

独立测试还应检验校准效果。可靠性图和预期校准误差可以说明零到一之间的输出是否能像可用的概率一样发挥作用。

第二项信号是真实设备上的风险—覆盖率曲线。开发者需要在现实内存限制下，对手机、笔记本电脑和边缘硬件进行测量。

这些测试应包括延迟、能耗、模型加载时间、本地错误率和云端移交频率。量化模型尤其值得关注。

Cactus 自己的数据已经表明，精度会改变路由的经济性。四比特构建版本可能更适合设备，但也可能将更多请求发送到云端。

正确的问题不应是孤立情况下的本地生成是否更快，而应是完整的混合路径能否同时改善质量、隐私、延迟和资源使用。

测试还应涵盖不断变化的网络状况。在办公室 Wi-Fi 上运行良好的路由器，在蜂窝网络或间歇性连接下可能带来截然不同的体验。

第三项信号是推理运行时的原生支持。当前示例证明了集成是可行的，但补丁和版本限制会阻碍采用。

llama.cpp、Transformers、MLX 或移动端运行时提供更广泛的支持，将减少自定义工程工作，也会促进置信度输出形成通用规范。

标准接口可以让开发者在无需重建应用逻辑的情况下替换模型，还可以支持用于比较分数、结果和移交率的监控工具。

如果没有这些规范，每个支持置信度的检查点都有可能成为一次性集成。这会减缓实验速度，并加大比较难度。

Cactus Gemma 4 E2B Hybrid 已经将一个有用的理念变成了现实。本地模型无需回答所有问题，也能成为默认选择。

发布之后，更困难的工作才刚刚开始。团队必须验证阈值、保护敏感输入、衡量保留请求的错误率，并决定在不存在云端路由时如何处理。

开发者应从结果可验证且范围明确的工作流开始。与开放式对话相比，文档提取、图表问答或会议录音转录能提供更清晰的评估。

然后，他们可以比较三种路径：始终在本地运行、始终在云端运行，以及基于置信度路由的混合模式。有用的结果并不是最高的表面分数。

真正有价值的是一种在满足既定错误率上限的同时，仍能让足够多的请求保留在本地处理，从而证明增加系统复杂度是合理的策略。

请密切关注接下来的独立评测。如果该探针能在不同设备和私有工作负载中保持其排序质量，置信度就能成为一种实用的路由依据。

如果性能因分布偏移而大幅下降，此次发布仍将带来宝贵的经验。结构化的不确定性字段是否可信，取决于其阈值背后的证据是否可靠。