Ollaya：把决策模型搬回本地的开源运行时，兼容 TypeSafe API、敏感数据不再上云

【摘要】

第一，Ollaya 把“决策模型”这件事本地化了。它不像聊天模型那样生成文字，而是读一段状态（邮件、工单、任意 JSON）加上几个带类型的问题，一次前向计算就返回校准过的概率——分类、路由、是否违规，毫秒级给出。它的自我定位是“像 Ollama 跑大模型一样，在本地跑开放决策模型”。

第二，它开源、本地优先。Apache-2.0 许可，Rust 写的运行时，权重从模型作者自己的 Hugging Face 仓库拉取并做 sha256 校验，Ollaya 本身永不重新托管权重；服务只监听 127.0.0.1:11435，不依赖任何外部在线服务。敏感数据从一开始就没离开你的机器。

第三，它“兼容 TypeSafe API”是实打实的兼容：实现了 /v1/systemone、/v1/decisions、/v1/models 三个端点，线格式与 TypeSafe 一致。你原来接 TypeSafe AI 的 Jev 云模型，只要把 TYPESAFE_BASE_URL 指到本机、模型名换成 laya，客户端代码基本不动。这等于给闭源云决策模型做了一个开源本地替身。

第四，模型生态是开放的：laya（ModernBERT，RTX 4090 上 5 个问题约 8–10 毫秒）、decider、kev、qwen3guard（安全守卫）、nli / gliclass（零样本分类）等都能跑，各自带自己的许可证。底座是 ONNX Runtime，CPU 上 fp32 与 PyTorch 参考实现在 2,383 道题上 100% 一致，GPU 走 CUDA fp16。

第五，它戳中的是 2026 年很现实的一道口子：越来越多系统需要“结构化判断”组件（路由、审核、分类、风控），过去这类活要么调云端大模型（数据出网、按 token 计费、有延迟），要么自己搓规则。Ollaya 把判断做成可本地部署、可校准、可替换的小模型，正好卡在“要智能、但不要云”的位置。

一、事件描述

下面按 Ollaya 官方仓库 README、官方文档 ollaya.dev 与开源聚合站快照梳理可验证事实，官方未点明处单独标注。

二、Ollaya 是什么：决策模型的“本地运行时”

Ollaya 的 README 把自己一句话讲清楚了——它要做的是“决策模型界的 Ollama”。区别只在于，Ollama 拉的是会聊天的语言模型，Ollaya 拉的是“做判断”的模型。

所谓决策模型，干的不是写文章，而是回答结构化问题。你给它一段 state（可以是一封邮件、一张工单、一段聊天记录，或者任意 JSON），再给它几个带类型的问题：choice（选项带概率）、score（评分层级）、noul（某陈述成立的概率）。它在一次前向传播里就把这些概率算出来，单位通常是毫秒，而且明确“从不生成文本”。这恰好补上了大语言模型最不稳的一块：做确定性的、可校准的分类与判断。聊天模型擅长“写”，决策模型擅长“判”，两者不是一回事。

这也是为什么 Ollaya 把使用体验做得和 Ollama 几乎一样：一条 ollaya run laya --preset triage "..." 就能跑，首次自动拉模型；ollaya pull、list、ps、show、create 等子命令一一对应。它甚至提供了 Modelfile，把你固化好的一套问题写成模型，下次直接 ollaya run inbox "..."。对已经习惯 Ollama 工作流的人来说，上手成本几乎为零。

三、兼容 TypeSafe API：给 Jev 一个开源本地替身

“兼容 TypeSafe API”是这条消息里最容易看走眼的一点，值得拆开。

TypeSafe AI 推出的 Jev 是一款云端“系统一”决策模型——它不开源、没有公开权重、也没有离线构建。开发者过去要用它，就得把状态和问题发到 api.typesafe.ai，按 token 付费。Ollaya 做的事，是把同一套 API 线格式在本地复刻了一遍：它实现了 /v1/systemone、/v1/decisions、/v1/models 三个端点，请求和响应格式与 TypeSafe 一致。官方文档里写的替换方式极简——把 TYPESAFE_BASE_URL 指到 http://localhost:11435、TYPESAFE_DEFAULT_MODEL 设成 laya，原本调用 Jev 的官方 Python SDK 几乎不用改代码就能转到本地。

这就带来一个很实用的含义：Ollaya 不是另起炉灶造一套新协议，而是直接兼容现有生态。对已经把 Jev 接进后端、又想把数据留在内网的团队，替换成本主要在改几个环境变量，而不是重写调用层。README 里也提到 ollaya mcp，可以把这些决策模型通过 MCP 接到 Claude Code / Desktop / Cursor 之类的客户端本地使用——判断能力留在自己机器上，不再过第三方。

需要说清的边界是：这种“兼容”是线格式一致，不代表 Ollaya 和 TypeSafe AI 有任何官方合作，也不代表 laya 和 Jev 的判断质量相等。它提供的是“可替换的本地形态”，质量要靠具体模型各自的基准说话。

四、模型与底座：ONNX Runtime 上的开放生态

Ollaya 本身不生产模型，它只是把一堆开放的决策模型组织成一个能本地服务的运行时。README 列出的名单相当务实：

• laya：路由模型，英语版基于 ModernBERT-large（421M），多语版基于 mmBERT-base（322M）；文档给出 RTX 4090 上 5 个问题 8–10 毫秒的参考延迟。
• decider / decider:0.8b：Mapika 基于 Qwen3.5 的解码器，有 2B 与 0.8B 两档，文档称在 typed-decisions 基准上最准。
• kev：Jared Palmer 的 Kev-0.8B，在 Qwen3.5-0.8B 上加 LoRA 与指针头，已校准。
• qwen3guard：Qwen 团队的安全守卫模型，内置安全/争议/不安全等类目，可用来做内容审核。
• nli / gliclass：零样本分类器（Moritz Laurer 的 NLI、Knowledgator 的 GLiClass），适合没有标注数据也要分类的场景。
• von：Victor Hugo Panisa 的 Von 1.1，ModernBERT-large 底座，每选项独立打分的 8k 上下文模型。

这些模型各自带许可证（README 中 laya、decider、kev、qwen3guard、gliclass、von、nli:modernbert-large 为 Apache-2.0，nli:deberta-v3-large 为 MIT），Ollaya 只发布约 3 MB 的小型 ONNX 图，真正的权重从作者自己的 Hugging Face 仓库读，固定提交并做 sha256 校验。这点很关键：它把“模型来自谁、是否被篡改”的信任链交还给原始作者和校验值，而不是由 Ollaya 统一托管。

推理底座是 ONNX Runtime。CPU 上跑 fp32，NVIDIA GPU 上跑 CUDA fp16；README 强调 fp32 导出在每检查点 2,383 个问题上与 PyTorch 参考实现 100% 一致。对“判断”这种要稳定、要可复现的活，能把数值一致性钉死，比单纯快更有意义。

五、隐私与本地优先到底做到了哪一步

“隐私优先”这四个字，在 Ollaya 这里不是口号，是可以逐条核到的设计：

• 服务只监听 127.0.0.1:11435，也就是本机回环地址，不对外暴露；Linux 下若检测到 systemd 且有 root，会建一个本地服务，但端口仍绑定回环。
• 推理完全在本地 daemon 完成，不调用任何外部在线接口；你的邮件、工单、聊天记录作为 state 传进去，不会出网。
• 权重从模型作者自己的 HF 仓库拉，Ollaya 不重新托管，且每次固定提交、sha256 校验，降低“被掉包”的风险。

能确认的是“数据不出本机 + 权重来源可校验”这两层。需要冷静看待的是：本地优先解决的是“传输与托管”的隐私，不等于“模型本身无偏见、判断永远对”。决策模型的输出是否适合你的业务，仍取决于模型和你的提问设计。另外，“不重新托管权重”也意味着你要信任上游作者仓库的长期可用性——这是把托管责任从 Ollaya 转移到社区，本身也是一种取舍。

六、决策模型三种落地方式的隐私与可控性

下面按公开信息，对“结构化判断”这类能力常见的三种落地方式做定性对照。条越长代表数据越留在自己手里、可控性越高，非精确测速。

决策模型三种落地方式的隐私与可控性（定性，越长越自主）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  自写规则 / 传统 ML       ████████████        高（数据不出内网，但是否够聪明受规则上限约束）
  Ollaya 本地运行时        ██████████          中高（本地推理，权重来自 HF，可换模型、可校准）
  云端决策模型（如 Jev）    ██                  低（状态与问题发往第三方，按 token 计费、有延迟）

图：三种“结构化判断”落地方式的隐私与可控性对照（依据 Ollaya 本地优先设计与 TypeSafe/Jev 的云端形态对比；隐私/可控性为定性，Ollaya 卡在“要智能、但要本地”那一档）

从图上看，Ollaya 想拿的不是“最聪明”或“最便宜”，而是中间那块长期被忽略的地带：比手写规则聪明，比云端模型可控。它的价值不取决于单次判断多惊艳，而取决于它把“判断”变成了一个可以本地部署、可替换、可审计的标准件。

七、结语

Ollaya 是一个 Apache-2.0 的 Rust 运行时，把“决策模型”做成能像 Ollama 跑大模型那样在本地跑的东西：读状态、答带类型的问题、毫秒级返回校准概率、不生成文本。它兼容 TypeSafe 的 /v1/systemone 等端点，让原本接 Jev 云模型的代码改几个环境变量就能转到本地；底座是 ONNX Runtime，laya、decider、kev、qwen3guard、nli、gliclass 等开放模型都能服务，权重从作者 HF 仓库拉并 sha256 校验，Ollaya 不重新托管。

能确认的是形态与边界：本地 daemon、回环端口、无外部在线服务，数据不出本机；兼容为线格式一致、非官方合作；模型质量以各自基准为准。需要放平预期的有两点：仓库创建于 2026-09-24、星标尚少（约 200），长期维护还要看社区；本地优先解决了传输与托管的隐私，不等于判断永远正确。

对“系统里需要一处结构化判断”这件事，Ollaya 给出的是一条清晰的路：别把每段工单、每封邮件都发给云端大模型，也别退回手写规则——把判断做成可本地部署、可校准的小模型，数据留在自己机器上，调用层照旧。它不一定取代 Jev，但它让“本地做决策”第一次变得像拉一个 Ollama 模型那样简单。