Ollaya：给 Jev 决策模型做一个「Ollama」，开源权重本地跑

Jev 类决策模型的热度正在从云端 API 蔓延到本地硬件。今天 Hacker News 榜首出现了一个叫 Ollaya 的开源项目，定位写得很清楚：像 Ollama 运行 LLM 那样，在本地运行开放权重的决策模型。一条命令 ollaya run laya，就能在自己的 CPU 或 GPU 上跑起毫秒级的类型化判断服务。这篇文章拆解它的架构、模型矩阵和部署方式，看看「决策模型本地化」这条工具链现在走到了哪一步。

Ollaya 官方站点：Run decision models locally

决策模型不是小号 LLM

先把概念摆正。Jev 是 TypeSafe AI 在 9 月 15 日发布的 System One 模型，它与常规 LLM 的区别不在规模，而在输出方式：LLM 用自回归方式逐个 token 生成文本，决策模型则把一段状态（state）和一组类型化问题（choice、score、yes/no）一次性送入模型，单个前向传播里并行输出所有答案，每个答案附带校准过的概率。它不生成字符串，因此不存在类型错误，也没有传统意义上的幻觉空间。

TypeSafe 官方博客给出的参照数字：Jev 托管 API 的端到端响应在 70ms 到 500ms 之间，输入 token 定价 $0.042/百万，输出 token 不计费；作为对比，主流前沿 LLM 的输入 token 价格在 $0.20 到 $10/百万，端到端响应 3 到 329 秒。官方工作流评测中自称「最快快 193.6 倍、最便宜便宜 444.6 倍」，并注明这是工作流评测里的上限值。

但 Jev 本体没有公开权重，也没有离线版本。想要这类能力又不想把工单、邮件、用户消息送到第三方 API 的团队，此前没有别的选择。这就是 Ollaya 切入的位置：官方 Jev 的开源替代生态已经出现，缺的是一个统一的本地运行时。

Ollaya 是什么：决策模型的模型管理器

Ollaya 用 Rust 写成，Apache-2.0 协议，整个项目是一个二进制文件加一个本地守护进程。命令面完全对照 Ollama 的心智模型：ollaya serve 起服务，run、pull、list、ps、show、rm、cp、stop、create 各司其职，守护进程没启动时 CLI 会自动拉起。

它的 API 设计是全文最关键的工程决策：Ollaya 直接实现了 TypeSafe 的线上协议。POST /v1/systemone 和 GET /v1/models 与 TypeSafe 的请求、响应结构逐字段一致，官方 TypeSafe Python SDK 0.7.1 不改一行代码，只把 TYPESAFE_BASE_URL 指到 http://localhost:11435 就能切到本地模型。对已经围绕 Jev API 写好业务代码的团队，迁移成本被压到一个环境变量。

看一个实际请求。用 curl 直接调本地端点：

bash

curl http://localhost:11435/v1/systemone -d '{
  "model": "laya",
  "state": "Can I get an invoice for last month?",
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does the customer want?",
      "criteria": {
        "invoice": "Needs an invoice or receipt",
        "refund": "Wants money back",
        "other": "Anything else"
      }
    }
  }
}'

返回结构里，intent 是一个 choice 型答案：模型选定 invoice，置信度 0.9547，并给出完整的概率分布（invoice 0.9698 / refund 0.0172 / other 0.013）。usage 字段显示这次请求消耗 43 个输入 token，输出 token 为 0。同一份输入换成 Ollama 式的命令行跑，效果更直观：

text

$ ollaya run laya --preset triage "I was charged twice for my subscription this month and want a refund."

intent            refund       ████████████████ 1.00
is_urgent         no           ██████████████░░ 0.88
frustration       1.76 / 3     ██████░░░░░░░░░░ 0.36
refund_requested  yes          ██████████████░░ 0.90
churn_risk        no           ██████████░░░░░░ 0.61

五个问题、五个概率分布，一次前向传播全部返回。客服工单分类、意图路由、风险打分这类原本要靠 LLM 链式调用的场景，变成了对本地进程的一次 HTTP 调用。

模型矩阵：编码器模型挑大梁

Ollaya 目前收录 9 个开放权重模型，全部来自第三方作者的 Hugging Face 仓库，Ollaya 自己只发布约 3MB 的 ONNX 计算图，权重文件按 commit 固定版本并用 sha256 校验，不做转存。这个设计让模型许可和更新始终归属原作者。

模型	底子	规模	定位
`laya:en`	ModernBERT-large	421M	英文决策模型，最快
`laya:multilingual`	mmBERT-base	322M	100+ 语言
`laya`	路由器	—	按语种自动分发到上面两个
`laya:typed-decisions`	微调版	—	用类型化决策工作流微调
`decider`	Qwen3.5 解码器	0.8B / 2B	官方称 Ollaya 内最准，typed-decisions 基准 0.591
`kev`	Qwen3.5 + LoRA + pointer head	0.76B	Jared Palmer 训练，自带温度校准
`nli`	DeBERTa-v3-large / ModernBERT-large	396M / 435M	零样本 NLI 分类器
`gliclass`	DeBERTa-v3-large	439M	指令跟随零样本分类
`von`	ModernBERT-large	395M	8k token 上下文，选项内嵌标记打分
`qwen3guard`	Qwen3Guard-Gen	0.6B	内容安全分类，119 种语言

这张表里藏着一个结构性事实：跑得最快的 laya:en 底层是 ModernBERT 编码器，解码器模型 decider 反而排在延迟表的末尾。原因回到决策模型的计算本质——不需要逐 token 生成，编码器的单次前向传播反而成了优势。官方给出的延迟数据：RTX 4090 上 laya 路由器单次请求（五个问题）中位数 8.1ms（multilingual）到 9.6ms（en），nli 20.4ms，gliclass 14.7ms，2B 的 decider 190ms；对照 TypeSafe 托管 API 的中位数 236 到 276ms（含网络往返）。本地推理在延迟项上反超了云 API，这在 LLM 场景里很少见。

精度方面，Ollaya 的 convert/ 管线在导出 ONNX 时做逐检查点校验：fp32 导出与 PyTorch 参考实现在 2383 个问题上做到 100% 决策一致。GPU 上跑 fp16，CPU 上跑 fp32，加载模型时自动选择。

部署：从笔记本到 Docker

Ollaya 的安装是标准的一行脚本，macOS（Apple silicon）、Linux（x86_64/arm64）、Windows（CPU 版 PowerShell，GPU 走 WSL 2）都覆盖，Docker 镜像发布在 GHCR，CUDA 版一行命令起服务：

bash

docker run -d --gpus=all -p 11435:11435 ghcr.io/ollaya-dev/ollaya:cuda

硬件要求方面，NVIDIA GPU 需要驱动 R580 以上，安装脚本检测到 GPU 才拉取 CUDA 运行库；Apple、AMD、Intel 的 GPU 上模型回退到 CPU 运行。所有模型的 CPU 路径都是可用的，这对 300M 到 500M 量级的编码器模型来说不算苛刻，普通笔记本就能跑。

配置走环境变量：OLLAYA_HOST（默认监听 127.0.0.1）、OLLAYA_MODELS、OLLAYA_KEEP_ALIVE、OLLAYA_DEVICE、OLLAYA_API_KEY 等。数据面完全本地：工单、邮件、用户消息在原有环境内完成打分，没有任何外发请求。

Modelfile 是另一个从 Ollama 借来的概念，可以把问题集、校准和精度烘焙成一个命名的模型：

text

FROM laya
QUESTIONS ./triage.json
PARAMETER precision fp32

ollaya create triage -f Modelfile 之后，团队里任何人 ollaya run triage "..." 就能用同一套问题定义。

给 Agent 用：MCP 接入

Ollaya 内置了 MCP 服务器，把决策模型暴露给 Claude Code、Claude Desktop、Cursor 等 MCP 客户端：

bash

claude mcp add ollaya -- ollaya mcp

对编码 Agent 的实际意义在计划执行环节。Agent 在执行破坏性操作前需要判断风险等级、意图匹配这类离散决策，现在可以在本地以毫秒级延迟拿到带概率的答案，而不是为一次 10ms 的判断发起一次数秒级的 LLM 调用。仓库还附带一个 ollaya-decisions 技能文件，教 Agent 在什么场景调用、怎么设置问题 schema。

局限与边界

Ollaya 的能力边界值得写清楚。首先，开放决策模型与 Jev 之间存在能力差距，TypeSafe 用 RLCD（Reinforcement Learning for Calibrated Decisions）训练的 Jev 在自家工作流评测里对标的是 GPT-6 Astra 和 Fable 5.1 的平均输出，开放阵营的 decider 在 typed-decisions 基准上是 0.591，没有可比的同台数据。其次，决策模型的输入是文本或 JSON 状态，多模态（图像、音频）不在当前支持范围。第三，选项基数（cardinality）上限与 Jev 一致为 255，超过需要两段式评分。最后，这批开放模型以英文和主要语种的分类任务为主，laya:multilingual 覆盖 100+ 语言但中文场景的校准质量仍需自行验证。

另一个现实问题是生态成熟度：项目刚上榜时 star 数还在三位数，贡献者 2 人，issues 只有 5 个，离 Ollama 那种社区规模还有很长的路。把它放进生产环境前，校准数据的自建验证（Modelfile 支持在自有标注数据上重新拟合校准）是必要步骤。

对开发者意味着什么

把 Ollaya 放进 Ollama 所代表的开源本地化谱系里看，它补上的位置很明确：LLM 有 Ollama、llama.cpp、LM Studio，嵌入和重排模型有一整套 sentence-transformers 生态，而决策模型这个刚刚成型的品类，第一次有了统一的本地运行时。对两类人这是直接可用的东西：一是数据敏感场景的后端工程师，工单路由、内容审核、意图分类可以在内网闭环；二是搭建 Agent 工作流的开发者，高频、低延迟、带置信度的离散判断从此多了一条不依赖云 API 的路径。

Jev 把「判断」从「生成」里剥离出来做成了独立品类，Ollaya 把这个品类的开源部分装进了每个人自己的机器。接下来值得观察的是开放阵营的校准质量能否追上 RLCD 训练的闭源原版，以及 TypeSafe 生态和开源生态谁先把决策模型的开发范式沉淀成标准。

来源：

Ollaya 官方站点：https://ollaya.dev/
Ollaya GitHub 仓库（Apache-2.0）：https://github.com/ollaya-dev/ollaya
TypeSafe 官方博客《Introducing System One Models & Jev》：https://typesafe.ai/blog/introducing-system-one-models-and-jev