本地 LLM 结构化推理原语库：给嵌入式工具开发者的分类引擎

在工具和应用中嵌入 LLM 的开发者，经常需要大量'是/否判断、多选归类、相关性打分'这类结构化小判断（如 'is this an ad'、'which folder does this belong in'）。目前的做法是用通用 LLM 硬做，慢且贵；或者在本地用 next-token logits 或 sequence likelihoods 在每个应用里手写一套评分逻辑，重复造轮子。信号 1 的开发者明确说想'把一个普通本地 LLM 用作多个结构化推理原语，而无需引入第二个分类器或切换模型'。

在本地运行 GGUF 模型（llama.cpp 生态）并需要在工具中嵌入分类式判断的开发者和独立构建者；同时受云 API 成本驱动的中小 AI 应用团队。属于开发者工具细分场景，人群明确但单点需求规模有限。

• 单模型多模式：加载一个 GGUF 权重常驻内存，同一模型暴露多种推理模式，避免引入第二个分类器或切换模型
• BOOLEAN 模式：对文本做是/否判断（如广告检测、内容审核）
• CHOICE 模式：基于 teacher-forced sequence log-likelihood 在候选选项中做归类（如'应放进哪个文件夹'）
• SCALE 模式：在给定分值点上输出离散分布，用于相关性打分
• 统一 API：Python/TS 层封装，替代在每个应用里手写 logits 评分逻辑
• AI 的角色：核心是把生成式 LLM 的 logits/likelihood 重新包装为确定性分类原语，模型本身不改变

信号 2 显示 OpenAI Decisions API 刚把'数据归入预定义答案'的推理做到约 10 倍快，证明这类结构化分类原语正成为平台级趋势；信号 3 显示 Jev 这类'为构建者在工具内使用而设计'的分类专用 LLM 已出现；信号 1 则显示本地 GGUF 生态（如 GPT-OSS 20B MXFP4）已足够轻量，让常驻内存的多模式推理在小团队侧可行。云端有了，本地侧还没有顺手的标准答案，是切入窗口。

第一版只做三件事：加载一个 GGUF 模型常驻内存、暴露 BOOLEAN / CHOICE / SCALE 三种推理模式、提供 Python/TS 统一 API。显式不做的：不做云端托管服务，不做模型训练或微调，不做非 GGUF 格式（如 ONNX、safetensors 原生格式）的兼容，不支持流式生成或开放式补全，不做 UI 界面。

平台依赖：深度绑定 GGUF/llama.cpp 生态，上游格式或 API 变动会直接破坏兼容性。巨头风险：OpenAI Decisions API 已把云上方案做到约 10 倍快，Jev 专为构建者而生，若它们的成本持续下降，本地方案的省成本优势会被压缩。开源先行者：llama-modes 已在 Hugging Face 论坛发布同类功能，差异化空间有限。商业化风险：目标用户是习惯免费开源工具的开发者，付费意愿信号为零，很可能演变为纯开源项目。技术风险：不同 GGUF 模型（如 GPT-OSS 20B MXFP4、Qwen3.8 Ridge）的 logits 行为差异可能影响 SCALE 模式的校准一致性。