Laya 模型是什麼？開源的決策模型可以整包跑在自己機器上：三個 checkpoint、RLCD 訓練法，以及開箱即用只有 0.362 的那個大坑

Laya 模型是 Convai Innovations 在 2026 年 9 月 18 日開源的決策模型：你給它一段文字或一包 JSON 當作狀態，附上幾個答案範圍固定的問題，它回你選項、分數或是非，每個答案都帶機率。它不生成任何文字，官方定位跟 TypeSafe 的 Jev 同一類，叫 System One 模型。最大的差別在授權與部署：權重採 Apache 2.0 全部公開，可以整包跑在自己的機器上，沒有 API、沒有帳單。

我們是在寫完Jev 模型技術解析的隔幾天遇到它的。當時留了一個問號：官方明講英文最準、中日韓文字要自己測。Laya 出現後這個問號變成兩個，因為它宣稱支援 100 多種語言、而且比 Jev 快 7 倍、還免費。我們花了一個晚上把它裝進一台 M1 Mac mini 實際跑過，這篇先把它是什麼講清楚：架構怎麼運作、三個 checkpoint 差在哪、官方數字哪些可信、以及開箱即用會踩到的那個大坑。

先講為什麼值得花時間看。官方 GitHub 專案開源四天就累積 14,736 顆星、1,206 個 fork，生態系裡已經長出 Apple Silicon 的 MLX runtime、Rust 版推論引擎、瀏覽器版本。這種速度在模型圈很少見，代表「把判斷從生成裡拆出來」這件事不只是一家公司的行銷語言，而是一整批工程師都在等的東西。

Laya 模型是什麼：一個可以整包搬回家的判斷引擎

一句話定位：Laya 是給程式用的判斷引擎，跑在你自己的硬體上。下面這張表先把整篇結論擺出來，後面每節再展開。

要理解它，先看它跟一般語言模型在做分類時的差別。你請 GPT 或 Claude 把一封客服信歸類，模型做的事是一個一個預測下一個 token：先吐左大括號、再吐欄位名、再吐冒號、再吐答案，一路到 JSON 收尾。你要的其實只是「technical」這一個詞，卻付了整份 JSON 的生成成本。

Laya 把這件事反過來。它讀一次狀態，對每個問題直接輸出「答案空間裡每個選項的機率」，全程沒有生成任何文字。用棒球主審來比喻：一般語言模型像個會把整場比賽寫成賽後報導的記者，Laya 像那個只喊好球壞球的主審，從頭到尾沒寫過一個字，但每一球都要當場判。

這個設計帶來一個實際好處：沒有東西需要解析，也沒有格式可以壞掉。用語言模型做分類最惱人的其實是格式：它偶爾漏一個逗號就害 JSON 解析失敗，你得多寫一套重試邏輯。Laya 的輸出本來就是結構化的數值，程式拿到就能用。

講到「AI 讀完內容做判斷、程式接著動」這種形狀的任務，這件事我們自己已經有現成的在跑。SalesKing是我們每天在用的 CRM，AI 讀完 LINE 對話後判斷客戶處在哪個銷售階段、生成追蹤計畫，那一層「判斷銷售階段」就是標準的選擇題：選項固定、答案要能讓後面的自動化直接用。這類判斷點該用付費 API 還是自架開源模型，正是這篇要幫你想清楚的事。如果你手上的系統也有這種節點，可以直接跟我們聊，我們會先幫你看哪幾題適合怎麼拆。

它是誰做的

作者是 Nandakishor M，Convai Innovations 的執行長，過去在印度理工學院帕拉卡德分校的技術創新中心擔任主持人。發布節奏可以從三個地方交叉核對：PyPI 套件 0.1.0 版的上傳時間是 9 月 18 日 04:38，GitHub 專案建立於同日 04:46，Hugging Face 模型頁 建立於 05:05，27 分鐘內一條龍發布。官方網站 也把這三個連結掛在一起。

有兩個容易混淆的地方要先講清楚。第一，Convai Innovations 這家印度公司跟做遊戲角色對話的 convai.com 完全無關，兩者只是名字接近。第二，Laya 這個字在中文圈會撞到 LayaAir 這套 HTML5 遊戲引擎，搜尋時要加上「模型」或「決策模型」才找得到對的東西。

三個 checkpoint 與那個會自動選型的 Router

先給答案：中文一律用 multilingual，英文版遇到非拉丁文字會壞掉，而且是自信地壞掉。

三個 checkpoint 前面掛了一個 Router，它會在半毫秒內用純 Python 偵測文字的書寫系統，再決定送給哪個模型。官方給的理由很嚇人：英文版處理高棉文時是0.000 的準確率配上 0.952 的信心。模型錯得很篤定，信心門檻完全擋不住，所以偵測必須發生在推論之前。

Router 有個效能陷阱要先知道。預設只保留一個 checkpoint 在記憶體裡，所以流量在語言之間跳動時，每次切換都要重建模型，官方實測中位數是 CPU 7.4 秒、T4 10.3 秒。正式環境一定要用 `Router(preload=True)` 把要用的都常駐，這也決定了它天生是「常駐服務」的形狀，不能寫成每次請求才載入的無伺服器函式。

import laya
from laya import Router

# 正式環境務必 preload，否則語言切換要重建模型（CPU 中位數 7.4 秒）
router = Router(preload=True)

state = {
    "from": "[email protected]",
    "subject": "報價單第 3 項金額怪怪的",
    "body": "剛收到報價單，第三項單價好像多算了一個零，可以幫忙確認嗎？",
}

questions = {
    "department": {
        "type": "choice",
        "instructions": "這則訊息應該由哪個團隊處理",
        "criteria": {
            "billing": "帳款、發票、退費",
            "technical": "系統錯誤、串接問題",
            "sales": "報價、合約、方案內容",
        },
    },
    "urgency": {
        "type": "score",
        "instructions": "這件事需要多快處理",
        "criteria": ["這週內回覆即可", "今天內要有人回", "現在就要處理"],
    },
    "churn_risk": {
        "type": "noul",
        "instructions": "客戶有沒有表達想終止合作",
    },
}

res = router.predict(state, questions)
print(res["answers"]["department"]["choice"])      # sales
print(res["answers"]["urgency"]["score"])          # 0.87
print(res["answers"]["churn_risk"]["noul"])        # 0.04
print(res["routing"]["model"])                     # multilingual

回應除了答案本身，還會附一段 routing 說明它為什麼選這個 checkpoint。另外每個答案都有一個 Jev 沒有的欄位叫 `action`，裡面是 `act_probability`，可以當作「這題要不要直接讓程式動作」的第二道訊號。

裝起來要多少空間

我們在一台 16GB 記憶體的 M1 Mac mini 上實際裝過，數字給你參考：虛擬環境連同 PyTorch 與 Transformers 是 922MB，多語言版權重 647MB，載入模型後常駐記憶體約 1.5 到 2GB。整包裝完約 1.6GB，跟一般人想像的「跑模型要很多空間」差很遠，因為它的參數量只有能實用的最小語言模型的十七分之一。

速度我們也量了：M1 的 CPU 上單題中位數 86 毫秒、九成在 91 毫秒以內。這個數字比官方自己給的 CPU 區間（193 到 464 毫秒）還快一倍多，也比我們量到的 Jev 從台北呼叫的 611 毫秒快 7 倍。模型第一次載入要 35 秒，之後常駐就穩定在 86 毫秒。

三種問題型態與 RLCD 訓練法

問題型態跟 Jev 完全對得上，這是刻意的相容設計，也是它被稱為開源替代品的原因。

訓練方法官方叫 RLCD，全名是針對校準決策的強化學習。機制講白話是這樣：模型輸出一個機率分佈，訓練時在它的輸出上加零平均的雜訊做探索，然後用一種數學上「只有誠實報告機率才能拿到最高分」的評分規則來給獎勵。所以模型學到的不只是「答對」，還包括「該有幾成把握就報幾成」。

這個「校準」概念值得多解釋一句，因為它是這類模型最重要的賣點。校準的意思是：一群被模型標成 0.8 信心的答案，長期看大約八成是對的。它是群體性質，不保證單一答案正確。有了校準，你才能在程式裡寫「信心低於某個值就交給人」這種規則，整套自動化才敢上線。

這套方法跟 Jev 用的名字一樣也叫 RLCD，兩家的實作細節沒有公開到能逐項比對的程度。Laya 這邊有把訓練腳本與微調 notebook 一起開源，所以至少看得到損失函數怎麼寫、超參數設多少，這是閉源 API 給不了的東西。

官方公布的校準指標 ECE 是 0.081，比 Jev 公布的 0.246 好三倍。但要注意這個數字有個前提，下一節會講。

官方數字怎麼讀：哪些可信、哪些有前提

先給答案：速度的數字是真的，準確率的數字有前提，而且那個前提在中文圈的報導裡幾乎都被漏掉了。

最重要的那個前提：開箱即用接近亂猜

官方模型卡在「誠實的限制」那節寫得很白：基礎 checkpoint 在 typed-decisions 上的零樣本準確率是 0.362，多語言版 0.342，而隨機猜是 0.318、「永遠選最大類」是 0.461。換句話說，開箱即用的 Laya 比亂猜好一點點，比最笨的基準線還差。那個亮眼的 0.766 屬於另一個 checkpoint，它在該 benchmark 自己的訓練集上微調過。

官方自己的結論是一句很誠實的話：Laya 是一個可以快速特化的底座，不是零樣本決策引擎。這句話跟中文圈流傳的「開源模型直接秒殺閉源 API」是兩件完全不同的事，而差別就在你有沒有準備好標註資料與微調的力氣。

我們拿 221 筆台灣客服訊息實測過這件事，數字比官方講的更難看，完整的混淆矩陣與錯誤分析寫在Laya 繁體中文實測那篇。這裡先講結論：繁中零樣本的分類正確率是 44.8%，而且 221 筆裡有 140 筆被判成同一個類別。

第三方的獨立比較也指向同一個結論。Artifilog 的 Laya 與 Jev 對照整理出的建議是：延遲要壓在 50 毫秒內、選項在 2 到 50 個之間、需要跨語言、而且願意投入時間在自己的資料上微調，這四個條件同時成立時才選 Laya；反過來，選項超過 50 個、或者不想管 GPU 與微調的團隊，付費 API 仍然是比較省事的選擇。

那個 0.362 對台灣團隊的意思

把這個數字翻成白話：你 pip 安裝完、照文件寫好問題、把客戶訊息丟進去，得到的答案品質大概跟丟骰子差不多。這跟「模型不好」是兩回事，它只是還沒學過你的任務長什麼樣子。官方把微調 notebook 一起開源，就是因為他們知道大家一定得走這一步。

好消息是這一步比想像中便宜。官方 notebook 在雙 T4 上訓練那格標的是四到六分鐘，我們改成單機版在 M1 Mac mini 的 CPU 上跑 150 筆資料，四個 epoch 花了 609 秒。錢是零，要的是標註資料。

它沒有 API，這件事的實際後果

先給答案：Laya 只有 pip 套件跟權重，要 HTTP 端點得自己包，而且必須是常駐服務。

官方提供的入口只有三個：`pip install laya`、Hugging Face 上的線上體驗空間、以及一本微調用的 notebook。體驗空間可以拿來試感覺，它終究只是展示頁，沒辦法當production 端點用。完整清單是 Hugging Face 模型庫、PyPI 套件頁、以及 線上體驗空間。

所以評估時真正要比的從來就不是「0.042 美元對上 0 元」。自架要算的是常駐機器的月費、包 API 的工時、監控與換版的維運，以及最重要的那一項：準備標註資料的人力。我們在AI 導入成本拆解那篇列過三個預算級距各能做什麼，自架模型這條路的成本結構比較接近「養一個小系統」，跟「買一個服務」差很多。

三個中文圈常見的誤讀

• 把 0.766 當成開箱即用的成績：那是微調後的專用 checkpoint，基礎版零樣本只有 0.362
• 把「快 7 倍」當成「準 7 倍」：速度差來自本機推論與跨海 API 的架構差異，跟判斷品質是兩件事
• 把「免費」當成「零成本」：省的是 API 帳單，付的是常駐機器、包服務的工時、還有標註資料的人力

誰適合用 Laya，誰應該直接用 API

先給答案：資料不能出境、或者延遲必須壓在 100 毫秒內，這兩種情況值得自架；其他情況先用 API 把價值驗證出來。

適合自架的三種情況

• 資料不能離開自己的機房：政府標案、醫療、金融，或客戶合約裡直接寫明的情況。這是自架最無法被取代的價值
• 延遲必須壓在 100 毫秒內：使用者打字時就要即時判斷、串流內容過濾、遊戲或即時控制。遠端 API 光是跨太平洋來回就吃掉幾百毫秒
• 呼叫量大到 API 帳單有感：這個門檻比想像中高很多，我們實測 221 筆訊息的 API 成本是 0.0054 美元，換算一個月十萬封信不到新台幣 80 元

應該先用 API 的三種情況

• 手上還沒有標註資料：沒有資料就沒辦法微調，而沒微調的 Laya 在中文上不堪用
• 選項數量很多：官方建議控制在 20 個以內，超過要自己改 head_max_len 或做兩層分類
• 團隊沒有人養得動一台常駐推論機器：這不只是開機而已，還有監控、換版、記憶體與擴容

選項數量那條限制值得單獨記住，因為它是架構決定的、不是調參數能繞過的。所有選項共用一個固定的 token 預算（英文版 192、多語言版 256），選項越多每個分到的字數越少，多到一定程度時選項之間就變得難以區分。官方在 77 個選項的 Banking77 上只拿到 0.425，同一份測驗 Jev 是 0.870。如果你的分類表有幾十個類別，要嘛提高預算參數，要嘛拆成兩層。

我們自己的客服分流流程同時符合「即時性不高」與「已經有標註資料」兩個條件，所以現階段的取捨是繼續用 API 跑正式流程，同時在本機養一個自架版本測試資料不出境的可行性。如果你的進件來自 LINE 官方帳號，前面的接法照LINE 官方帳號接 AI 的三種整合路徑，換模型只是換掉中間那個判斷節點。

從「跑得起來」到「公司每天在用」之間，差的是一層客製：問題怎麼寫成它讀得懂的形式、訊息怎麼清成乾淨的狀態、門檻怎麼從你的資料畫出來、人工複審那條路怎麼接回現有系統。少了這一層，它就是一個很快的函式；有了這一層，它才是流程裡的一個節點。

不用一次到位，從你最頭痛的那一條流程開始就好。先聊一下你現在的情況，我們會直接告訴你「這個值得做嗎、大概怎麼做」，這個階段我們陪你一起想，後面真的要動手再談範圍跟費用。可以把你公司現在的流程丟過來，我們很樂意聽你聊聊現況，一起看看哪幾個判斷點適合先拆出來。

我們怎麼看：開源把成本從帳單搬到了工程

生態系的反應也值得看一眼。這個專案開源四天累積了 14,736 顆星，但也同時開了 101 個 issue，其中第 102 號就是使用者回報高基數選項的解法：先做一輪粗篩把選項縮到 20 個以內，準確率從 54.3% 拉到 60.8%。官方在說明文件裡誠實註明「那是回報者的數字，本專案沒有重測」。這種透明度在模型圈少見，也是我們願意認真評估它的原因之一。

想從頭理解企業導入 AI 該怎麼排優先序，企業 AI 導入指南有整套框架；如果你考慮的是更大的自架題目，企業自建大型語言模型的技術路徑那篇談的是大上好幾倍的工程。

我們公司內部最省時間的三個 AI 流程，八成中小企業都用得上，而且它們的核心全部是選擇題。你公司現在最頭痛的是哪一塊？可以把現況丟過來，我們陪你一起看看適合的解法。

讀到這裡，你手上應該已經有一份判斷標準了：資料能不能出境、延遲要不要壓在 100 毫秒內、手上有沒有標註資料。想知道這三題對你的系統各自是什麼答案，跟我們聊聊你的 AI 導入需求，我們會先幫你看哪一題最值得先動、大概怎麼做最划算，再談要不要真的動手。