端侧 AI 缺的从来不是参数，是一句我没把握

两行伪代码，今天挂在了 Hacker News 首页。

if confidence < 0.85:
    answer = ask_a_bigger_model(prompt)

置信度低于 0.85，就把问题转给更大的模型。逻辑简单到小学生都能看懂，难的从来是那个 confidence 到底从哪来。

这是一家叫 Cactus 的公司发的开源项目 cactus-hybrid，他们对 Gemma 4 E2B 做了一次后训练（post-train，就是在训练好的模型上再补一轮特定方向的训练），把一个「探针」直接打包进了模型文件里。这个探针干一件事，给模型的每一个回答打一个 0 到 1 之间的分数，告诉你这个答案有多大概率是对的。分数是结构化返回的，不是让模型在回答末尾自己喊一句「我有 85% 的把握」然后你拿正则去抠。

先交代一下主角。Gemma 4 E2B 是 Gemma 家族里最小的那个，2B 级别，专门为手机、笔记本这类设备端准备的。端侧模型的老三样优点大家都背得出来，快、免费、隐私不出门。缺点也就一个，笨。不是全方位的笨，是那种你永远不知道它这次会不会笨的笨。十个问题答对八个，听着不错，可你不知道错的是哪两个，于是十个答案你一个都不敢直接用。

这才是端侧 AI 真正卡壳的地方。不是能力不够，是能力不可预期。

Cactus 这次给出的答案有点子牛逼。带上置信度之后，Gemma 4 E2B Hybrid 只需要把 15% 到 35% 的问题转交给 Gemini 3.1 Flash-Lite，剩下的全部自己在设备上消化，最后在大多数基准上的总成绩，和全程用 Flash-Lite 打平。

你品一下这笔账。三分之二以上的请求根本不用出设备，不花钱、不排队、数据不上传，整体质量却和纯云端一个水平。对做产品的人来说，这不是跑分提升 3% 那种新闻，这是成本结构和隐私故事直接换了一套写法。

当然，打平的前提是那个分数得靠谱。分数不靠谱，整套架构就是空中楼阁，该转的没转出去，用户拿到一堆自信的错误答案，不该转的全转了，那你混合个啥，直接用云端得了。

所以这个项目里最值得看的不是跑分表，是衡量「分数靠不靠谱」的那张表。指标叫 AUROC，翻译成人话，就是这个分数把「答对的」和「答错的」分开的能力，0.5 等于瞎猜，1.0 是完美分开。Cactus 的探针在 12 个测试集上平均 0.814。

对照组选得也很诚实，token 熵。这是行业里最常用的土办法，模型生成每个词的时候都有一个概率分布，分布越平摊说明模型越犹豫，拿这个犹豫程度当置信度用。做过模型接入的朋友大概都试过这招，文本任务上凑合能用，token 熵在 MMLU 上也有 0.697，跟探针的 0.770 差距不算羞辱。

拉开差距的地方在多模态。视觉问答 MMBench 上，token 熵 0.435，比瞎猜还低。音频转写 GigaSpeech 上，0.343。这个数你敢信，意思是模型生成得越流畅，答案反而越可能是错的。想想也对，转写一段没听清的音频，模型不会结巴，它会流畅地编。犹豫程度衡量的是「说得顺不顺」，不是「说得对不对」，两件事在生成模型身上经常没关系。

而探针在这些任务上全部稳在 0.78 到 0.88。

然后是整个 README 里最让我心里咯噔一下的一句。这个探针的训练数据里，一条音频都没有。零。但它在四个音频基准上照样拿到 0.79 到 0.88 的 AUROC。

怎么说呢，这一下就把「探针是不是背下了题库」这种解释给排除了。它读的是模型隐藏状态里某个跟模态无关的信号。作者在 HN 的讨论里补了一句背景，他们先对 Gemma 4 做了机制可解释性研究，发现不同层的隐藏状态里携带着有意义的「自我察觉」信号，探针就是学会了从隐藏状态预测答错的概率。有人问这跟 Goodfire 的 RLFR 是不是一个路子，作者说思路上松散相似。

模型内部本来就存着一个「我对这个答案有没有底」的信号，只是从来没人把它接出来做成产品接口。好家伙，可解释性研究这个常年被吐槽只能发论文的方向，这次直接落成了一个 API 字段。

我平时的工作就是给模型搭外围工程的，让它接工具、跑任务、出了错兜得住的那一层。这个方向的人看到「原生置信度」四个字，感受会比一般用户强烈得多。因为我们天天在做的事情，就是在模型外面猜它有没有把握。超时了猜一次，输出格式不对猜一次，跑个校验脚本再猜一次，全是又贵又粗的间接证据。模型自己揣着答案却不吭声，我们在外面拿听诊器隔着三层棉袄听。现在有人把听诊器直接焊进了模型胸口，这个方向我是真的觉得对。

顺着这个再多聊一层。前两天 Cursor 刚发了 Cursor Router，在云端替你决定每个请求该去哪个模型。今天 Cactus 在设备端做了同一件事，置信度够就本地答，不够就上云。一周之内，云上和端上各落了一子，指向同一个判断，单个模型的能力不再是故事的全部，「知道该派谁上」正在变成一层独立的基础设施。而路由要做得好，前提永远是同一个，得有一个可信的信号告诉你现在这手牌有多大。

好了，夸完了，说坑。这个项目的坑不但有，还挺硬。

最大的一个是量化。量化就是把模型权重从 16 位浮点压到 4 位甚至 3 位整数，牺牲一点精度换体积和速度，端侧部署几乎人人都得做。而量化对这套混合架构是双倍伤害，模型变笨了，需要转出去的题变多，探针也变钝了，识别错误的能力跟着掉。FP16 下 15% 到 35% 的转交率，到 4 bit 普遍涨到 40% 上下，到 3 bit 部分任务要转 55% 到 65%。最惨的是 MMLU-Pro 这种知识密集型任务，4 bit 下要转出去差不多 90%。

九成的题都得请云端出马，那这个「端侧模型」存在的意义就比较行为艺术了。而现实里的端侧部署，恰恰大部分都跑在 4 bit 附近。所以宣传语里那个漂亮的 15% 到 35%，你默认要打个折扣来读。

工程成熟度也还在早期。Transformers 接入要求版本必须钉在 5.5.x，新版直接段错误。加载模型必须显式指定设备，用 device_map 自动分配会让置信度读取直接崩掉，因为探针的打分逻辑在常规前向传播路径之外。llama.cpp 那边更是要自己编译一个打过补丁的引擎。都不是过不去的坎，但每一条都在提醒你，这是个上线第一天的东西。HN 上还有两个我很关心的问题没得到回答，一个是补了探针之后模型本身的生成质量有没有退化，一个是代码任务上表现怎么样。

还有一条评论我想单独说，因为它是全场最尖锐的一条。有人不满这个项目的措辞，原话大意是，你不可能「知道自己错了」，你只能知道自己没把握。一个人可以斩钉截铁然后错得离谱，也可以慌得一批结果全对。

嘴上有点损，但他其实说到了正经处。这个探针输出的不是「对错」，是一个和对错高度相关的统计信号，0.814 的 AUROC 很好，可它照样会放过一些说得斩钉截铁的错误。你的路由代码兜得住它看走眼的那部分吗，阈值切在 0.85 还是 0.7，转出去的成本和答错的代价怎么权衡，这些还是你的活，一个字段替不了你做架构判断。

说真的，我倒觉得「没把握」这个词比「知道自己错了」诚实，也更接近这个东西真正的价值。老水手最值钱的本事从来不是划得快，是看一眼天色就知道今天不能出海。模型也一样，能力涨到今天这个地步，稀缺的早就不是多答对三道题，是它开口之前先告诉你，这道我没底，你找别人问问。

项目是 MIT 协议，模型都在 Hugging Face 的合集里，Cactus 自家框架、MLX、Transformers、llama.cpp 四条路的接入代码都是复制粘贴就能跑的程度。发布当天就有社区开发者把它接进了自己的麦克风转写工具，速度厉害了。你要是手上正好有端侧或者混合部署的场景，值得花一晚上试试，顺便帮 HN 上那两个没人答的问题探探底。

至于那两行伪代码，我估计它们会活得比这个项目久。以后再看到什么端侧模型发布，我大概只会先问一句，它知不知道自己几斤几两。参数多少，反倒是后面的事了。