hunch：在 CPU 上跑毫秒级语义决策，把大模型高频任务接过去

hunch 是一个基于 Google EmbeddingGemma 2 构建的本地语义决策系统，专门用来在普通 CPU 上做毫秒级的快速判断。

在很多 Agent 系统里，大量的开销其实都花在微小但重复的判断上，比如判断某个工具调用有没有失败、输出里有没有提示词注入、用户输入该路由给哪个智能体，或者日志是否存在异常。过去为了这些判断，每次都得调用一次大模型或昂贵的判定模型，不仅延迟高，Token 费用也飞速上涨。hunch 的目标就是接管这类高频任务。

它是怎么边用边学的

hunch 采用的是快反应架构，核心由 EmbeddingGemma 2、轻量级分类器以及教师模型蒸馏机制组成。

它的工作流分为「学生」和「老师」两个角色。你平时调用的主力大模型充当老师，hunch 内部的轻量分类器则是学生。学生会直接读取 EmbeddingGemma 2 吐出的语义向量。

起初，所有问题依然交给老师回答，hunch 在一旁默默记录并进行训练。当交叉验证显示学生的判定与老师的吻合度达到标准后，系统就会判定它「毕业」，正式由学生在本地接管该任务。

毕业后系统也不会彻底放任不管。hunch 依然会抽样一部分请求送回老师做审计检查。如果遇到超出学习范围的生疏输入，它会自动退回给大模型处理，防止模型在能力之外盲目猜测。

运行规格与性能表现

hunch 完全不需要 GPU。它底层依赖一个用 Rust 编写的高性能引擎 eg2cpu，在普通 CPU 上就能高效运行。

在苹果 M5 Pro 芯片上，对一个约 190 token 的工具执行结果进行文本语义判断，中位数延迟仅为 22 毫秒。处理图片分类时，耗时约在 100 毫秒左右。换算下来，每百万 token 的运行成本不到 3 美分。

在并发压力测试下，32 个并发调用方可跑出每秒 86 次请求，p99 延迟为 466 毫秒。如果是在配备 AMX 的 24 核 Sapphire Rapids 服务器上批量处理，将 32 token 的文本编码到第 8 层，每个文本仅需约 0.6 毫秒。

除了后端服务，项目还附带了 hunch.live 库，支持 Python 和 TypeScript，可以用来实时构建基于文本或图像的动态选择型问题。

怎么跑起来与去哪试

hunch 的核心代码、eg2cpu 引擎和测试样例均已开源，采用 MIT 或 Apache-2.0 双许可证，代码存放在 GitHub 的 undrgrnd-labs/hunch 仓库中。

本地部署需要准备 Rust 1.88 或更高版本，以及 Python 的 uv 包管理器，通过 maturin 编译 Python 扩展。项目仓库提供了 download.py 脚本，可一键下载 Apache-2.0 协议的 EmbeddingGemma 2 权重。

需要说明的是，hunch 专为结构化决策设计，即判定是否、单选或打分。如果你的任务需要复杂的间接推理，比如分析故障的严重程度以及该指派谁来修复，它并不适合替代大模型。

为什么重要

我们认为 hunch 代表了一种非常务实的 Agent 架构演进方向。现在的很多 AI 系统把所有问题不加区分地全扔给前沿大模型，既浪费算力又拖慢整体吞吐，说白了就是在拿大炮打蚊子。

对于正在构建生产级 Agent 的团队来说，hunch 提供了一种低成本的分级推理手段。它不需要昂贵的显卡，直接在现有的 CPU 服务器上挂一个本地进程，就能把工具调用检查和日志审计等脏活累活扛下来，值得当下在测试流里引入试试。