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 伺服器上掛一個本地程序，就能把工具呼叫檢查和日誌審計等髒活累活扛下來，值得當下在測試流裡引入試試。