最近介紹過的 Ollaya 和 Jev，它的口號是「決策模型版的 Ollama」。一行 ollaya run 就能在本機跑判斷模型/型別化決策模型，模型不生成文字，只回傳「是否」、「選哪個」、「幾分」的機率。該專案的官方網站說 NVIDIA RTX 4090 卡片上跑跑的話，每個請求 8 到 10 毫秒，非常快，API 也與 TypeSafe 的 Jev 相容。
讀完我的第一個念頭是，這種小模型最適合放在 NAS 上吧 ? NAS 全年開機，資料本來就在那裡，內部文件也不必送出去給雲端判斷。所以這篇的重點是 Ollaya 能不能跑在 NAS 上？ 順便把我在其他設備上測試的速度、準確度與實作問題一併做個說明。
測試版本是 Ollaya 0.6.1（2026-09-26 發佈），檢測 AI 用的測試題是 CyberQ 團隊開發的 881 題判斷題組，其中 105 題經過人工複核。
測試結果初探
| 機器 | 處理器／顯示卡 | 能跑嗎 | laya 每請求 |
|---|---|---|---|
| QNAP TS-x64 系列 NAS | Celeron N5095 | 不能，一啟動就 SIGILL | 無 |
| 另一台 Intel 低功耗 NAS（有 NVIDIA 卡） | 同樣沒有 AVX | 不能，裝了顯示卡也沒用 | 無 |
| QNAP TS-x73A 系列 NAS | Ryzen Embedded V1500B，8 GB | 可以，但只放得下 laya | 4.1 秒 |
| 桌機 A，CPU | Intel | 可以 | 1.08 秒 |
| 桌機 A，GPU | RTX 5060 Ti 16 GB | 官方版不行，換掉一個函式庫就可以 | 17.5 毫秒 |
| 桌機 B，CPU | Ryzen | 可以 | 0.79 秒 |
| 桌機 B，GPU | RTX 3060 12 GB | 官方版直接可用 | 31 毫秒 |
| NVIDIA DGX Spark | GB10，只能用 CPU | 可以 | 0.63 秒 |
每請求平均 2.5 題，數字取 p50。
測試結果主要是這樣的：
NAS 能不能跑，先看 CPU 有沒有 AVX，沒有的話直接跳過，這是目前 NAS 和工業用電腦、伺服器採購的新標準了，沒有 AVX 要跑很多新世代的小服務、型別判斷模型會比較麻煩或沒辦法跑。
有 AVX 的 NAS 跑得起來，但只放得下最小的 laya。
真正好用的是 decider 決策模型，準確率 82.9%，但它要 GPU 顯示卡，且需要有 16 GB 的 VRAM（12 GB 的 RTX 3060 跑不動），u 一般 NAS 則需要具備能跑 16GB 如 RTX A4000 以上 NVIDIA 的顯示卡就能夠用。而 QNAP 推出的 AI NAS，如 QAI 系列新機型都能跑。
問題一：沒有 AVX，連 `–version` 都跑不動
第一台 NAS 的容器一啟動就結束，沒有任何日誌，結束碼 132。132 等於 128 加 4，也就是 SIGILL（非法指令）。我本來以為是推論引擎的問題，結果發現更前面：
docker run --rm --entrypoint /usr/bin/ollaya ghcr.io/ollaya-dev/ollaya:0.6.1 --version
# 結束碼 132連印版本號都不行，代表 Ollaya 的主程式本身就是以 AVX 為前提編譯的。換到 Celeron N5095 的 TS-x64 系列也一樣。這兩顆 CPU 的指令集都只到 SSE4.2。
要注意的是，NAS 上裝了 NVIDIA 顯示卡也救不了。去比對 CPU 版與 CUDA 版映像裡的主程式是同一支檔案，雜湊完全相同，GPU 能力只是多放一包 CUDA 函式庫。如果跑的時候主程式先掛點，當然就輪不到顯示卡的份。
動手之前先下指令查：
grep -o -w -m1 avx /proc/cpuinfo || echo "沒有 AVX，Ollaya 起不來"很多入門與中階的 x86 NAS 用的都是 Celeron、Pentium Silver 這一類處理器。它們跑 Docker 完全沒問題，偏偏就是沒有 AVX，因此這類新的型別決策模型就沒辦法跑。
有 AVX 的 NAS 跑得起來，但只放得下 laya
另一款測試用的是 TS-x73A 系列 NAS ，具備 AMD Ryzen Embedded V1500B 處理器，它有支援 AVX2，Ollaya 可以正常啟動。不過因為這台只有 8 GB 記憶體，開機後可用約 2 到 3 GB。我把容器上限設在 3 GB，只載入 laya 的多語版：
| 項目 | 數字 |
|---|---|
| 每請求（平均 2.5 題） | p50 4.1 秒，p95 7.6 秒 |
| 單題 | p50 1.37 秒 |
| 同時送 4 個請求 | 吞吐沒有增加，每秒 0.22 個情境 |
輸出倒是很可靠，和在 DGX Spark（ARM）上跑出的結果逐題比對，153 題 100% 相同，機率最大只差 0.0001。
問題二：記憶體大哉問
Ollaya 的模型在磁碟上是 F16，用 CPU 跑時居然一律以 F32 載入，所以實際吃掉的記憶體遠大於檔案大小：
| 模型 | 參數量 | CPU 模式記憶體峰值 |
|---|---|---|
| laya:multilingual | 322M | 2.3 GB |
| laya:en | 421M | 3.5 GB |
| gliclass | 439M | 3.9 GB |
| von | 395M | 4.3 GB |
| kev | 0.76B | 6.0 GB |
| nli | 435M | 6.4 GB |
| decider:0.8b | 0.75B | 6.8 GB |
| decider | 1.9B | 15.7 GB |
8 GB 記憶體的 NAS 只放得下 laya。
16 GB記憶體 的 NAS 理論上放得下 decider:0.8b，但在 CPU 上每個請求要 2.5 到 16 秒（這是 Intel i5 處理器的數字，NAS 只會更慢）。
問題三則是 GPU
Ollaya 官網寫支援 NVIDIA GPU，但有三個前提：
主機必須是 x86_64
CUDA 版只有 amd64。在 DGX Spark 這類 ARM 平台上設定 OLLAYA_DEVICE=cuda，會回 this build of ollaya has no CUDA support。官網寫的「Linux ARM64 native CUDA 13」，和實際發佈的檔案對不上。
驅動要 R580 以上（CUDA 13）
NAS 上的 NVIDIA 驅動套件還停在 575。
顯示卡不能是 Blackwell
官方附的 CUDA 元件缺 RTX 50 系列的核心（GitHub issue #10，尚未解）。我在 RTX 5060 Ti 上實測時，預設設定下它會直接改用 CPU，伺服器日誌裡一個字都沒寫，你只會覺得天啊，怎麼這麼慢。
如果強制指定 GPU 去跑，該程式則會回 cudaErrorNoKernelImageForDevice。
要確認有沒有真的用到 GPU，請看 ollaya ps 或 /api/ps 的 device 欄位。
RTX 50 系列的繞法
反過來說，三個條件都符合就很順。另一台桌機是 Ryzen 5 7500F 加 RTX 3060 12 GB，官方版解開就能用，預設設定會自動用 GPU，laya 每個請求 31 毫秒。
第三點也可以自己解決。我的另一台桌機是 RTX 5060 Ti，拆開 Ollaya 之後發現兩件事：
ONNX Runtime 的核心（1.28.0）是靜態連結在主程式裡的。
CUDA provider 卻是另外載入的共享函式庫，放在 lib/ollaya/cuda_v13/。
而 PyPI 上的 onnxruntime-gpu==1.28.0 剛剛好是同一版，它的 CUDA provider 有 sm_120 核心、依賴的也是 CUDA 13。所以做法就很簡單啦，改一改就可以跑得起來了：
# 以 x86_64 Linux／WSL2 為例
pip download --no-deps --only-binary=:all: --python-version 3.12 \
--platform manylinux_2_28_x86_64 --platform manylinux_2_27_x86_64 \
--platform manylinux_2_17_x86_64 --platform manylinux2014_x86_64 \
onnxruntime-gpu==1.28.0 "nvidia-cuda-runtime~=13.0" "nvidia-cublas~=13.0" \
"nvidia-curand~=10.0" "nvidia-cudnn-cu13~=9.0" "nvidia-cufft~=12.0" \
"nvidia-cuda-nvrtc~=13.0" "nvidia-nvjitlink~=13.0" -d wheels
# 把所有 wheel 裡的 .so 攤平放進 <ollaya>/lib/ollaya/cuda_v13/換完之後，伺服器日誌寫著 device=cuda:0 precision=fp16：
| 項目 | CPU（同一台 i5） | GPU（RTX 5060 Ti） |
|---|---|---|
| laya 每請求 | 1082 毫秒 | 17.5 毫秒 |
| laya 單題 | 366 毫秒 | 12.9 毫秒 |
哇，這樣測試下來，直接快了 60 倍。fp16 與 fp32 的答案一致率是 99.35%。但因為這是我自己的繞法，不是官方支援的組態，藥石做的話，請自行評估。
準確度方面顯示 laya 不行，但 decider 可以
先講 API的成績，Ollaya 對 TypeSafe API 的相容做得很仔細，不論是回應形狀、confidence 公式、評分題從 0 起算、422 錯誤格式，全都對得上。連 Jev 的一個陷阱都照抄了 XD，是非題的 criteria 如果用 yes/no 當鍵，會被默默忽略，要寫 true/false 才有作用。
模型之間的差距就很大了。以下是對人工複核 105 題的準確率（這份題組亂猜約 30%）：
| 模型 | 準確率 | 信心 ≥0.9 時的準確率 | 涵蓋率 |
|---|---|---|---|
| laya | 35.2% | 46% | 26% |
| gliclass | 33.3% | 68% | 17% |
| von | 39.0% | 從不超過 0.9 | 0% |
| nli | 47.6% | 64% | 25% |
| kev | 75.2% | 100% | 24% |
| decider:0.8b | 76.2% | 99% | 44% |
| decider（1.9B） | 82.9% | 98% | 57% |
| 對照：我自己蒸餾的 4B 模型 | 87.6% | 98.5% | 65% |
「涵蓋率」是指有多少題的信心高過門檻。它的意義是，decider 對一半以上的題目很有把握，而這些題幾乎全對，其餘的再交給大模型處理。這正是串接架構要的東西，而且 decider 完全不用自己訓練。
它的弱點在英文與評分題。繁中對教師模型的一致率 87.6%，英文只有 74.0%，評分題 69.0%。
官網首頁的範例是讓模型審查 AI 代理人要執行的指令，使用者只要求「修正 README 的錯字」，代理人卻要執行 git push --force origin main。
| 模型 | 危險的 git push --force | 正確的 sed 修錯字 |
|---|---|---|
| laya | run 0.85 | run 0.89 |
| decider | block 0.53（ask 0.40、run 0.06） | run 0.90 |
laya 幾乎分不出兩者，decider 則能正確處理。
使用 Ollaya 的代價，decider 很吃資源
| 模型 | 顯存（16 GB 卡） | RTX 5060 Ti 每請求 | RTX 3060 每請求 | 單題（5060 Ti） |
|---|---|---|---|---|
| laya | 約 1 GB | 18 毫秒 | 31 毫秒 | 14 毫秒 |
| kev | 約 5.6 GB | 313 毫秒 | 435 毫秒 | 131 毫秒 |
| decider:0.8b | 約 4.5 GB | 773 毫秒 | 1020 毫秒 | 133 毫秒 |
| decider | 約 12.7 GB | 1.17 秒 | 跑不動 | 192 毫秒 |
decider 的單題 192 毫秒和官網寫的 190 毫秒吻合，官網上寫的 8 到 10 毫秒，則指的是 laya。
為什麼 decider 這麼吃 VRAM 顯示記憶體呢？我們看一下伺服器日誌的 precision= 就知道，有 laya 以 fp16 放上 GPU，decider、kev、nli 都是 fp32，因此會吃較多記憶體。
在 12 GB 的 RTX 3060 上，decider 1.9B 的情況是：
權重載得進去，使用量約 7.75 GB。
但每次推論都要再配置一塊 2 GB 的緩衝（看大小是把整張詞嵌入表轉成 fp32）。
結果每個請求都回 500，連 20 個字的輸入也一樣。
所以它需要 16 GB 級的顯示卡。12 GB 的卡只有兩條路：
改用 decider:0.8b 模型（76.2%，每請求約 1 秒）或 kev（75.2%）。
把 decider 1.9B 模型放在 CPU 上跑。要 16 GB 以上的記憶體，在 Ryzen 5 7500F 上每請求 4 到 24 秒。
順帶一提，同一個 decider:0.8b 在 RTX 3060（官方元件）與 RTX 5060 Ti（我換過的元件）上跑 881 題，答案 100% 相同，也就是說換元件的繞法可行，且不會影響結果，這是好事。
部署 Ollaya 時要注意的四件事
它預設綁在 0.0.0.0
官方映像的 OLLAYA_HOST 是 0.0.0.0:11435，日誌也會警告「任何連得到的人都能執行、下載、刪除模型」。在 NAS 上請用 -p 127.0.0.1:11435:11435，或設定 OLLAYA_API_KEY（實測會正確回 401）。
記憶體不足時，錯誤訊息不會告訴你
模型被 OOM 砍掉時，API 回的 MODEL_LOAD_FAILED 內容是一行不相干的日誌（「GPU runtime not installed, using CPU」）。要去看伺服器日誌裡的 signal: 9 (SIGKILL) 才知道是 OOM。
模型掛掉之後不會自動恢復
之後同一個模型的每個請求都回 500，要手動送 {"model":"...","keep_alive":0} 卸載才會好。
自動選路會看錯語言
繁中說明夾著 JSON 或錯誤堆疊時，laya 的 router 會判成「English Latin text」，送去只懂英文、context 只有 512 的版本。
另外，同一段內容問幾題，就會被重新處理幾次，問 1、2、4 題，輸入 token 分別是 65、130、260，Ollaya 只要碰到題目一多，就會自動線性變慢。
給 NAS 使用者的建議
請先查處理器有沒有支援 AVX，沒有 AVX 就不用試了，裝了顯示卡也一樣。
有 AVX、8 GB 記憶體的 NAS只放得下 laya。可以拿來體驗 API，但每個請求要數秒。
想要能用的判斷品質請用 decider，放在一台有 16 GB 顯示卡的 x86 機器上，讓 NAS 透過區網呼叫它。RTX 50 系列照上面的方式換函式庫即可，12 GB 的卡就退一步用 decider:0.8b，雖然小，但效果仍舊還可以。
拿它當 Jev 的本機替身也很合適，相容的 API 可以讓程式在開發與測試時不必呼叫雲端。
這次測試最大的收穫，是能不能跑與值不值得跑需要分開看。Ollaya 在 NAS 上大多跑不起來，跑得起來的又只有最弱的模型。但在一張 16 GB 的遊戲顯示卡上，它的 decider 小模型的成績，已經接近我花了一天蒸餾出來的模型，而且一下載馬上就能用。這對想在辦公室、區域網路環境中做判斷自動化的人來說，是非常值得關注的起點， Jev 相關衍生專案也越來越多，值得大家去實作看看。
