常見問題

什麼是決策模型？

一種模型，它讀入一個狀態（文本、一封郵件、一張工單、一個 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。