常见问题

什么是决策模型？

一种模型，它读入一个状态（文本、一封邮件、一张工单、一个 JSON 对象）加上类型化的问题，在一次前向传播中返回一个类型化的答案，并给出每个问题经过校准的概率。它从不生成文本。这使它很快，输出也容易据以行动：路由工单、拦截消息、在概率高于阈值时升级处理。

怎么安装？

macOS、Windows 和 Linux 上的桌面应用；Linux 和 macOS 上命令行的 curl -fsSL https://ollaya.dev/install.sh | sh，Windows 上的 irm https://ollaya.dev/install.ps1 | iex；或 Docker 镜像 ghcr.io/ollaya-dev/ollaya。见下载。

Ollaya 与 Ollama 是什么关系？

Ollaya 借鉴了 Ollama 的体验（单一二进制、pull、run、serve、Modelfile、约定相同的本地 REST API），并把它用在决策模型上，而不是生成式语言模型上。它是一个独立项目，与 Ollama 没有关联。

Ollama 现在也能跑决策模型了。Ollaya 有何不同？

Ollama 0.35（2026 年 9 月）为两个解码器模型加入了 /v1/systemone：Bespoke Labs 的 Nimble 和 Together AI 的 Tev1。两个项目都遵循 TypeSafe 的线上格式，而对解码器模型，两者都读取答案标签的下一 token 得分。Ollaya 从 0.8.0 起也能跑 Nimble。以下比较针对 Ollama 0.35：

并排实测。 在一块 RTX 5090 上，用 Bespoke Labs 的公开基准（来自 13 个数据集的 3,880 个人工标注问题，用 Bespoke 自己的代码评分）：Ollaya 上的 winnow:12b 每题 60 ms 得 0.773，而 Ollama 上表现最好的 Nimble 是 210 ms 得 0.749。在同一份 Nimble 权重上准确率相同（0.748 和 0.749），Ollaya 的校准误差低 5.5 倍（0.022 对 0.122，因为 Ollaya 应用了作者的温度），而 Ollama 更快（210 对 310 ms：它跑的是 Q8_0 GGUF，而 Ollaya 用 fp32 计算）。主页上有这张图。

Ollama 的优势也是实打实的。Tev1 它有而这里还没有（Together AI 尚未为其权重发布许可证）；如果你已经用 Ollama 跑语言模型，一个守护进程就能兼顾两边。两者可以并排运行：Ollama 在 11434 端口，Ollaya 在 11435。

它与 TypeSafe 是什么关系？

TypeSafe 闭源的 Jev 模型开创了决策模型这一门类。Ollaya 在 TypeSafe 兼容 API 后面提供开源模型：官方的 TypeSafe Python SDK 0.7.1 无需改动即可配合 TYPESAFE_BASE_URL=http://localhost:11435 和任意 API key 使用。Ollaya 与 TypeSafe 没有关联。见 TypeSafe 兼容性。

我能跑哪些模型？

来自以下家族的开放决策模型。见 Models，它比较它们的准确率和速度。

• winnow 来自 EldanRing：Winnow-E4B（winnow:e4b，推荐的模型）和 Winnow-12B（winnow），以 GGUF 文件发布的 Gemma 4 微调。Ollaya 在 llama.cpp 上跑作者的文件，可以用 NVIDIA GPU、Apple 芯片的 GPU 或 CPU。winnow:e4b 在类型化决策上得 0.722，接近 Jev 的 0.738，在 RTX 4090 上约 90 ms。
• laya 来自 Convai Innovations：laya（一个 router）、laya:en、laya:multilingual 和 laya:typed-decisions，每一个也都有 -fp16 和 -fp32 版本。laya 把英文文本发给 laya:en，把其他语言（比如土耳其语）发给 laya:multilingual。它是最快的。
• decider 来自 Mapika：decider:4b、decider:2b 和 decider:0.8b，构建在 Qwen3.5 上。decider:4b 在类型化决策上得 0.680。decider:2b-vision 还能随状态一起读入一张图片。
• nli 来自 Moritz Laurer：基于 DeBERTa-v3-large 和 ModernBERT-large 的零样本 NLI 分类器。它是最准的编码器。
• gliclass 来自 Knowledgator：一个遵循指令的零样本分类器，一次就为每个选项打分。
• kev 来自 Jared Palmer：kev:4b（即 kev）、kev:0.8b 和 kev:9b，是在 Qwen3.5 上的一个 LoRA 和一个指针头，在各自的 span 处为每个选项打分，经过校准。kev:9b 在类型化决策上得 0.722，与 winnow:e4b 一样高，但需要 24 GB 的 GPU，耗时约 500 ms。
• decision 来自 vLLM Semantic Router 贡献者：decision:eos，即 Decision 1.0 Eos，一个完全微调的 Qwen3.5-0.8B，带一个端点头，在最后一个 token 处为每个选项打分，经过校准，行最长可达 16,384 个 token。
• qwen3guard 来自 Qwen 团队：一个覆盖 119 种语言的安全防护栏。它回答自己内置的问题（安全、有争议或不安全，以及不安全类别），所以你只需发送文本。
• von 来自 Victor Hugo Panisa：基于 ModernBERT-large 的 Von 1.1，一次为每个选项在它自己的标记处打分，可读入最多 8,192 个 token 的状态。
• clm 来自 Contrastive-LM：CLM-v0.1-8B，用 Qwen3-8B 嵌入状态和每个选项，并通过两个训练过的头挑出最接近状态的选项。问题和选项会被缓存，所以重复的几乎不花成本。它在类型化决策上得 0.357；作者是为 agent、游戏和工具调用的状态而做的。
• jevk5 来自 alibiserikbay：JevK5 v0.3，以 GGUF 文件发布的 Qwen3.5-4B 微调。Ollaya 在 llama.cpp 上跑作者的 4B Q8_0 文件，每个问题最多 16 个选项。

权重从哪来？

来自模型作者自己的 Hugging Face 仓库，固定到一个 commit。每个文件在被拉取时都会用它的 sha256 校验。Ollaya 从不重新托管权重：它的 registry 只提供小的清单和派生文件，例如 ONNX 计算图，这些文件通过 URL 引用权重。同样的派生文件也发布在 Hugging Face 上的 ollaya-dev 下。

答案和原模型一样吗？

Ollaya 以 ONNX 运行 Laya。每个 checkpoint（en、multilingual 和 typed-decisions）的 2,383 个问题上，ONNX 导出选择与 PyTorch fp32 参考相同的答案，比例是 100%，最大概率差为 1.1 × 10⁻⁴。在 CUDA GPU 上默认运行 fp16 图；在接近平手时它可能与 fp32 不同。固定一个 -fp32 tag 即可与参考一致。

这些模型和 Jev 比怎么样？

看具体模型。在类型化决策上（2,000 个问题），winnow:e4b 和 kev:9b 最接近，0.722 对 Jev 的 0.738，而 winnow:e4b 在 RTX 4090 上约 90 ms 回答五个问题，比 Jev 的托管 API 还快。小的编码器，比如 laya，最快，但在更难的问题上远低于 Jev。主页列出了每个模型的准确率和速度。关于开放决策模型与 Jev 在准确率和校准上的独立比较，见 Decision Index。如果你有某个固定任务的标注数据，在它上面微调过的模型通常胜过任何通用模型。

它有多快？

一次决策就是一次前向传播。在 RTX 4090 上通过 HTTP API 端到端测量，五个问题的中位请求：laya:multilingual 8 ms，laya:en（fp16）10 ms，gliclass 15 ms，nli 20 ms，winnow:e4b 89 ms。单个问题在编码器上花 8–11 ms。更大的解码器花得更久：kev:4b 354 ms，decider:4b 520 ms。

我需要 GPU 吗？

不需要。Ollaya 在 CPU 上运行；在 x86-64 Linux 和 Windows 上，当存在 NVIDIA GPU 且驱动为 R525 或更新时会使用它（R580 起用 CUDA 13 库，之前用 CUDA 12）。安装脚本只在发现 GPU 时才下载 CUDA 库。Windows 和 Linux 桌面应用不捆绑 CUDA 库：它们单独运行时在 CPU 上跑模型；当命令行也装上并带上它的 GPU 库（且与应用同样新）时，应用会从那套安装启动服务器，从而用上 GPU。像 winnow 这样的 GGUF 模型在 llama.cpp 上运行，它也会用 Apple 芯片 Mac 的 GPU（Metal）；它们的一致性已在 CUDA 和 x86-64 CPU 上验证过，尚未在 Metal 上验证。它们是大语言模型，所以 GPU 对它们的影响比编码器模型大得多：测得的速度见各模型页面。在 RTX 30、40 或 50 系列卡上，GGUF 模型无需其他东西。在较老或数据中心的卡上（GTX 10 系列、V100、T4、A100、H100），llama.cpp 的 CUDA 库带有一些由驱动在首次使用时编译的代码，这需要更新的驱动：配合 CUDA 12 库需要 R570 或更新，配合 CUDA 13 库需要支持 CUDA 13.4 或更新的驱动。驱动较老时，Ollaya 在 CPU 上运行 GGUF 模型并记录原因；ollaya llama-devices 显示每块 GPU 的计算能力以及内核是否在其上运行。

支持哪些平台？

• Linux x86-64 和 ARM64，glibc 2.38 或更新：Ubuntu 24.04、Debian 13、Fedora 39、RHEL 10 或更新。
• macOS 14 或更新，Apple 芯片。laya 和 nli:modernbert-large 通过 MLX 在 Apple GPU 上运行，比在 CPU 上快 2 到 3 倍；其他模型在 CPU 上运行。
• Docker： linux/amd64 和 linux/arm64 用 ghcr.io/ollaya-dev/ollaya，NVIDIA GPU 用 :cuda（宿主驱动比 R580 老时用 :cuda12）。在较老的 Linux 发行版上也用它。
• Windows 10 和 11，64 位 x86 PC：桌面应用，命令行用 irm https://ollaya.dev/install.ps1 | iex，它也会用 NVIDIA GPU（两者都装，应用的服务器也会用它）。用 Linux 安装程序的 WSL 2 也行。
• 桌面应用三个平台都跑：见下载。

我的数据会离开我的机器吗？

不会。服务器默认监听 127.0.0.1:11435，并在本地运行模型。网络只用于拉取模型。状态和问题永远不会被记录。

为什么是 11435 端口？

它紧挨着 Ollama 的默认端口 11434，这样两者可以并排运行。

概率是怎么校准的？

按问题类型和选项数量分别做温度缩放，随每个模型一起发布。对于你依赖的阈值，在你自己的标注数据上重新拟合温度，并用 Modelfile 把它们烤进去。

有 MCP 服务器或 agent skill 吗？

两个都有。ollaya mcp 把本地模型提供给 Claude Code、Claude Desktop、Cursor 和其他 MCP 客户端（claude mcp add ollaya -- ollaya mcp），而 ollaya-decisions skill 教 agent 何时以及如何使用它们。见 Agents。

怎么更新？

运行 ollaya update。它会检查最新版本，若有更新的，就把安装脚本再跑一遍装到同一个位置，从而保留你的模型和服务设置。ollaya update --check 只告诉你是否有更新。桌面应用整体更新：从下载安装新版本。在 Docker 里，拉取新镜像。

怎么卸载？

在 Linux 上，安装程序设置好服务之后：

sudo systemctl disable --now ollaya && sudo rm /etc/systemd/system/ollaya.service
sudo rm -rf /usr/local/bin/ollaya /usr/local/lib/ollaya /usr/local/share/doc/ollaya /usr/local/share/ollaya
sudo userdel -r ollaya    # also deletes /usr/share/ollaya, including the models

对于不带 root 的安装（在 ~/.local 里），删除 ~/.local/bin/ollaya、~/.local/lib/ollaya、~/.local/share/doc/ollaya 和 ~/.local/share/ollaya，以及 ~/.ollaya 里的模型。

许可证是什么？

Ollaya 是 Apache-2.0。模型各自带有自己的许可证：laya、decider、kev、decision、qwen3guard、gliclass、von、winnow、jevk5、clm 和 nli:modernbert-large 是 Apache-2.0，而 nli:deberta-v3-large 是 MIT。