零Token决策：EmbeddingGemma 2 + WebGPU 浏览器端多模态分类

当决策不该是"生成"时

大多数人用大模型做分类决策时，习惯让它"说一句话"：这颗蛋受精了吗？这个场景可以继续吗？我们现在处于四种状态中的哪一种？但用聊天模型来回答这类问题，本质上是用错了工具。生成过程缓慢、不确定，而且每生成一个 token 都是一次偏离的机会。

一个决策本身是有类型的——一个类别、一个是非、一个分数。既然如此，为什么不直接拿到这个类型？

一个名为 Decide Live 的静态网页正是围绕这个思路构建的。它把摄像头画面、麦克风窗口、图片或一行文本，直接转化为一个带类型的决策，整个过程完全在浏览器中完成。它运行微调后的 EmbeddingGemma 2（Apache-2.0 协议），通过 transformers.js 在 WebGPU 上执行，生成零个 token，且不上传任何数据。

作者将这种本地化形态称为 ZTC（Zero-Token Confidence，零 Token 置信度）。没有服务器、没有按次调用的 API 费用，模型权重只需缓存一次。

一个决策是如何算出来的

Decide Live 的决策路径完全公开在页面和模型卡中，可以复现。整个流程不涉及任何解码循环，核心是四步：

查询嵌入与选项嵌入

首先是查询嵌入。媒体占位符排在最前，接着是 task: classification | query: {question}，当提供上下文时再加上 \nContext: {context}。模型在一次前向传播中同时嵌入媒体和文本。

选项嵌入则把每个选项写成 title: none | text: {description} 的格式，嵌入一次后缓存起来。

嵌入模型（Embedding Model） 与生成模型的根本区别在于：它不产生新的文本序列，而是将输入（文本、图像、音频）映射为高维向量空间中的一个点。语义上相近的输入，其向量在空间中也更接近。EmbeddingGemma 2 是在 Gemma 2 基础上经过对比学习微调的变体，目标是让"查询"与"正确选项"的向量距离尽可能近，而与"错误选项"尽可能远。这与 CLIP、sentence-transformers 等模型遵循同一范式。关键优势是：嵌入只需一次编码器前向传播（encoder forward pass），不存在自回归解码循环，计算量是确定且有界的，这正是它能在浏览器端实时运行的根本原因。

池化与打分

在注意力掩码上做平均池化（mean pooling），再做 L2 归一化，得到一个 768 维的单位向量。最后的打分公式为：

P(option_i) = softmax_i( 19.96 * cos(e_query, e_option_i) )

这里的缩放系数 19.96 是学习得到的（对应约 0.05 的温度），随 decision.json 一起发布。整条路径只有每张卡片一次编码器前向传播，再加一个点积——没有逐 token 的生成。

这正是"零 Token"的意义所在：决策由查询嵌入与选项嵌入之间的余弦相似度做 softmax 得出，没有文本生成，因此结果确定性强且成本极低。

平均池化（mean pooling） 是将序列中所有 token 的隐藏状态按注意力掩码加权平均，压缩成单一向量的标准做法。相比只取 [CLS] token，平均池化通常能更均匀地利用序列的全局语义信息。L2 归一化则将向量缩放到单位球面上，使余弦相似度等价于点积，计算更高效。

公式中缩放系数 19.96（约等于温度参数 τ = 1/19.96 ≈ 0.05）的作用是控制 softmax 的"尖锐程度"：温度越低，概率分布越集中于最高分选项，决策越果断；温度越高，分布越平坦，不确定性越大。该系数通过训练学习得到，而非手动调参，体现了模型对自身置信度的自校准。

浏览器端的技术栈

Decide Live 的工程实现同样值得关注，它展示了当下端侧 AI 的完整可行方案：

• transformers.js 4.3.1 在 Web Worker 中加载模型并返回嵌入向量，避免阻塞主线程。
• WebGPU 负责运行 ONNX 计算图；当浏览器不支持 WebGPU 时，自动回退到 WASM（CPU） 运行。
• ONNX 文件提供 q4f16 版本和一个可移植的 q4 构建（4-bit 权重配普通 8-bit gather，使同一批文件也能在缺少 GatherBlockQuantized 支持的 WASM 运行时上运行），外加一个 4-bit 音频编码器。为了塞进 Hugging Face Space 的 1GB 限制，fp16 和 fp32 版本被省略。
• 权重只下载一次，之后由浏览器缓存。此后所有决策都在本地完成。

这种设计意味着：首次访问需要下载模型，但之后便可脱离网络、脱离服务器独立运行。

WebGPU 是 W3C 于 2023 年正式落地的新一代浏览器图形与计算 API，相比 WebGL 提供了更接近原生 GPU 的通用计算能力（Compute Shader），使矩阵乘法等张量运算可以直接在浏览器中高效执行。transformers.js 是 Hugging Face 推出的 JavaScript 推理库，复用了 Hugging Face Hub 上的模型权重（ONNX 格式），并封装了分词、特征提取等预处理流程。两者结合使得原本只能在 Python/PyTorch 环境运行的 Transformer 模型，无需任何服务器即可在普通浏览器标签页中完整执行。q4f16 表示权重以 4-bit 量化存储、计算时反量化为 fp16，是当前端侧推理的主流精度折衷方案，可在模型体积与推理精度之间取得较好平衡。

它实际能做什么

Decide Live 提供了几种可直接上手的模式：

• 实时模式（Live）：嵌入摄像头画面，对最多四张决策卡片打分，每张卡片带独立问题，采用训练时的"每卡一次前向传播"格式。每张卡片显示概率条、当前决策和一个置信门控（confidence gate）。
• 麦克风/音频文件：同样的卡片机制，作用于 16kHz 单声道、2 秒窗口；低于 -55 dBFS 的安静窗口会被跳过。
• 单一输入：一张图片、一段文本、一段音频或短视频，配一个问题和 2 到 8 个以 key: description 形式写的选项，或者一个是非问题。
• 样例测试：18 个带标准答案的图片测试，可在浏览器内运行，输出准确率报告，并比较不同 prompt 格式的表现。

为什么这对边缘 AI 很重要

一个运行在设备上的决策，天然具备三重优势：隐私性（摄像头画面和音频永不离开本机，隐私是"构造性"保证的，而非承诺的）、零边际成本（每次调用免费）、以及离线可用（首次加载后即可脱网工作）。

把这些特性与零 Token 形态结合，你就能对每一帧画面或每一个音频窗口打分，而不必承担云端账单或网络往返的延迟。这正是实用级边缘智能应有的样子。

传统的"每次决策调用一次云端 API"模式，在高频场景下既昂贵又存在延迟瓶颈。而当分类决策被还原为"一次编码 + 一次点积"的轻量操作，并下沉到端侧，整个成本与延迟结构就被彻底改写了。

小结

Decide Live 由 VIDRAFT / FINAL-Bench 构建，采用 Apache-2.0 协议开源。它的价值不仅在于一个可玩的演示，更在于清晰地示范了一种思路：分类决策不必走生成的路径。

用嵌入 + 校准相似度替代逐 token 生成，既保证了确定性，又把计算成本压到最低，再借助 WebGPU 与 transformers.js 落地到浏览器端——这为需要高频、低延迟、强隐私的边缘 AI 应用提供了一条值得借鉴的工程范式。感兴趣的开发者可以直接访问其 Hugging Face Space 体验，并查看页面源码了解完整的决策路径。