Laya：開源 AI 決策模型實戰教學，比 Jev 快六倍的自架方案

我最近在研究什麼

前幾週我在看 Alex Hitt 的一段影片，講的是兩個「決策模型」（decision model）的比較：Laya 和 Jev。這兩個東西都不是你平常會拿來聊天的 AI，它們專門做一件事：把一堆文字或資料丟進去，然後直接回傳一個有結構化的答案跟信心分數。

我看完之後覺得這個方向很值得寫一篇完整的研究出來，因為它代表了一種跟大型語言模型（LLM，也就是我們常說的 ChatGPT、Claude 那種會一直生成文字的 AI）完全不同的思路。不生成文字、不一步步預測下一個文字單位（一個字可能拆成好幾個），而是用一次前向傳遞直接給出分類結果。

在過去的幾年裡，我們幾乎把所有AI的問題都丟給大型語言模型去解決。不管是要分類一封郵件、判斷一張圖片的內容，還是決定要不要回覆某個客服訊息，大家的第一反應都是「讓 AI 寫一段文字來回答」。但這種做法有個根本性的問題：當你的問題其實只需要一個簡單的答案時，讓模型產生成百上千個字元，不僅浪費時間也浪費資源。

想像一下：你去餐廳點餐，只需要知道「今天推薦什麼菜」，但廚師卻花了二十分鐘做一道三道菜的套餐，最後你只吃了一口。決策模型就像是一個經驗豐富的領班，他看一眼你的需求就能直接告訴你該選什麼，不用做一整個套餐。

為什麼要比較 Laya 和 Jev？

這兩種模型雖然都叫「決策模型」，但它們的設計哲學完全不同。Laya 是開源的、可以自架的；Jev 則使用雲端 API（Application Programming Interface，也就是應用程式介面，讓你的程式跟遠端服務溝通的橋樑），不需要自己處理硬體。這篇文章會帶你實際看 Laya 的程式碼、安裝流程、怎麼設計問題格式，最後再跟 Jev 做個完整的比較。

什麼是「決策模型」？為什麼需要它？

一般的大型語言模型像是 Claude、GPT，它們回答問題的方式是一步一步生成文字，先預測第一個文字單位，然後根據結果預測第二個，依此類推。這個過程叫自回歸生成（autoregressive generation），也就是每一步都要等上一步完成才能繼續。

自回歸這個詞聽起來很複雜，其實就是「一個接一個」的意思。就像你玩接龍遊戲，下一個人必須等上一個人說完才能開始。大型語言模型做文字生成的時候就是這樣：它先產生第一個字，然後根據已經產生的文字來決定第二個字，接著是第三個、第四個，一直繼續下去。

想像一下：你讓別人抄一段文章，他必須從第一個字開始，一個字一個字念完，再念下一個。這就是你熟悉的 AI 聊天方式。這種方式很強大，因為它可以寫出各種長短不一的文字。但問題是，很多時候我們根本不需要一段文字，我們只需要一個簡單的答案。

這種方式很適合寫文章、做摘要、回答開放式問題，但有一個致命缺點：速度。

這裡的速度不只是指「等得久不久」的問題，還包括「花多少錢」。因為大型語言模型每次回答都要生成很多文字，這意味著伺服器要運算很多次，耗電量也跟著增加。對於只需要簡單答案的任務來說，這樣做不僅浪費時間，也浪費錢。

假設你的應用程式需要對一封客服信件做分類：是「帳單爭議」還是「訂單狀態查詢」？用 LLM 的話，你必須等它生成完整文字，然後再從回傳的文字中解析出你要的答案。這可能花上幾百毫秒甚至更多。

決策模型怎麼解決這個問題？

決策模型解決這個問題的方式很直接：它根本不做文字生成。

你輸入一段文字和一個結構化的問題格式，它直接回傳你定義好的選項中的一個，以及每個選項的機率。因為跳過了文字生成的步驟，延遲可以壓到三十多毫秒。比 LLM 快上數十倍。

Laya 是什麼？

Laya 是一個開源的「快速直覺」決策模型，由 NandhaKishorM（Convai Innovations）開發，以 Apache 2.0 授權釋出。它不是聊天機器人，你不能問它「今天天氣如何」。它的設計目標很明確：接受一段狀態資料和結構化的問題，然後在一個前向傳遞中直接回傳分類結果。

這個「快速直覺」的名稱取自心理學家丹尼爾·康納曼提出的概念。他在書中把人類思考方式分成兩種：快速直覺的反應（像是看到危險會立刻跳開），以及緩慢、需要努力的思考（像是做一道數學題）。Laya 屬於第一種類型，它不是慢慢推理，而是直接給出答案。

你可以把 Laya 想成是一個訓練有素的郵政分揀員。當信件進來時，他不需要讀完整封信的內容，只需要掃描幾個關鍵字，比如地址的區域、信件的類型，就能立刻決定這封信該送到哪個分區。這個過程只需幾百毫秒，而且幾乎不會出錯。Laya 做類似的事情，只是它處理的是文字資料而不是實體信件。

GitHub 倉庫在 github.com/NandhaKishorM/laya，模型權重在 Hugging Face 的 convaiinnovations/laya。

底層架構

Laya 的英文模型權重檔案基於 ModernBERT-large（395M 參數），是一個完全微調過的雙向編碼器。在這之上，開發者額外訓練了一個決策頭：在基礎模型之上多加的一層網路，專門負責根據選項計算偏好分數。這個決策頭包含兩層神經網路結構、一個選項標記評分器，以及一個行動升級頭。總參數量是 421M。

簡單來說，Laya 的核心流程是這樣的：

1. 你把狀態資料和問題格式打包成一個資料包（payload）
2. 每個候選選項都被分配到獨立的 [MASK] 文字單位上
3. 整個資料包一次送進神經網路編碼器（Transformer，一種能理解文字順序的架構）
4. 決策頭對每個選項計算一個標量偏好分數（logits，也就是神經網路輸出的原始數值）
5. 機率轉換函數（softmax）把所有選項的分數轉成機率，讓總和剛好是百分之百

因為沒有文字生成循環，所以不存在「解析錯誤」或「幻覺輸出」的問題：答案一定在你預先定義的選項之中。整個過程就像把一份考卷一次過腦，而不是逐題思考。

三種問題類型

Laya 支援三種問題類型：

類別決策：例如部門轉接、意圖分類。它會回傳選中的選項、每個選項的機率，以及校準後的信心分數。

序數量表評分：例如將一封信件的緊急程度放在 0 到 2 的量表上。不過開發者自己在影片中也承認，這是目前架構中最弱的部分：在嚴格數學刻度任務上的表現較差。

布林值校準機率：回傳一個介於 0.0 到 1.0 之間的精確機率值，而不是文字。例如「這封郵件是釣魚攻擊的機率是 0.92」。

校準機率：為什麼這很重要？

一般用二元強化學習訓練的模型，傾向把最高機率推到接近 1.0，因為這樣能最大化獎勵訊號。但這會毀掉模型的校準（calibration）：它看起來很有信心，但實際上可能是錯的。

什麼是校準？

想像一下：一個學生每次考試都說「我有百分之百把握」，結果每次都考不及格。這種過度自信比完全不知道還糟糕，因為你會根據他的信心做出錯誤的決策。Laya 就是要避免這種情況。

Laya 使用一種叫 RLCD（Reinforcement Learning for Calibrated Decisions）的訓練方式：探索階段在 logits（神經網路輸出的一個中間數值，代表模型對每個選項的偏好程度）上加零均值高斯雜訊，獎勵訊號來自嚴格適切評分規則（strictly proper scoring rules）。簡單來說，只有誠實報告真實機率才能最大化獎勵。

RLCD 的全稱是「校準決策強化學習」，這是開發者自己命名的訓練方法。傳統的做法是讓模型學會「猜對就給獎勵」，但這樣會導致模型過度自信，它總是想把機率推得越高越好，不管自己到底有沒有把握。RLCD 改變了這個規則：如果模型說它有百分之八十的把握，而結果確實是對的，它就得到高分；但如果它說有百分之八十卻錯了，就會受到較大的懲罰。這樣的設計讓模型學會誠實地報告自己的信心程度。

經過溫度擬合（用你自己的資料微調模型的信心刻度）後，英文模型的期望校準誤差（ECE）降到 0.081：當模型說它有 85% 信心時，實際準確率確實約在 85% 左右。這對需要設定信心門檻的自動化系統來說非常關鍵。

安裝與實戰教學

第一步：安裝

Laya 透過 pip 安裝，非常簡單：

pip 是 Python 的套件管理工具，就像手機上的 App Store 一樣，可以幫你快速安裝和管理各種程式庫。如果你還沒有安裝 Python，可以先去官網下載最新版本。

pip install laya

需要 Python 3.10 以上版本。還有幾個可選的額外套件：laya[serve]（HTTP 伺服器）、laya[mcp]（MCP server）、laya[onnx]（ONNX Runtime）。

第二步：載入模型

import laya

agent = laya.load("convaiinnovations/laya")

第一次執行時會自動從 Hugging Face Hub 下載模型權重檔案。英文版本約 1.5 GB。

第三步：定義問題格式

Laya 不接受對話歷史。你需要明確區分兩部分：狀態資料和問題格式。

狀態資料是你要分析的未結構化內容：一封客服信件、一筆訂單紀錄、一段使用者輸入。問題格式則是用 Python 字典定義的結構化查詢。讓我們一步步來看。

先準備狀態資料，也就是你要讓模型分析的內容：

state = {
    "project": "AI Architecture",
    "components": [
        {"type": "NeuralNet", "id": "NN01"},
        {"type": "DataPipeline", "id": "DP01"}
    ],
    "status": "Active"
}

接下來定義問題格式。這裡我們同時問了三個不同類型的問題：部門分類（choice）、緊急程度評分（score），以及是否需要人工介入（noul）：

questions = {
    "department": {
        "type": "choice",
        "options": ["engineering", "billing", "support"],
        "instructions": "Which department should handle this?"
    },
    "urgency": {
        "type": "score",
        "instructions": "Rate the urgency from 0 to 2",
        "scale": ["low", "medium", "high"]
    },
    "is_critical": {
        "type": "noul",
        "instructions": "Is this a critical issue requiring immediate attention?"
    }
}

第四步：執行預測

所有問題都在一次前向傳遞中完成：

result = agent.predict(state, questions)
answers = result["answers"]

print("Department:", answers["department"]["choice"])
# -> engineering (confidence: 0.94)
print("Urgency:", answers["urgency"]["score"])
# -> 1.84 / 2.0
print("Churn Risk:", answers["is_critical"]["noul"])
# -> 0.892 (89.2% probability)

自動信心門檻控制

因為 Laya 的機率是經過嚴格校準的，你可以安全地設定信心門檻來決定是否自動化執行：

dept = answers["department"]["choice"]
conf = answers["department"]["confidence"]

if conf >= 0.85:
    route_automatically(dept)
else:
    escalate_to_human_agent(dept, reason=f"Low confidence ({conf:.2f})")

這是 Laya 相比一般 LLM 的一個核心優勢：你可以根據校準後的信心分數寫出可靠的自動化邏輯，而不必擔心模型在錯誤時依然表現出過度信心。

效能數據：Laya vs Jev

這部分是大家最關心的。影片中的比較數據如下（均在 Tesla T4 GPU 上測量）：

Tesla T4 是 NVIDIA 推出的一款雲端伺服器專用的顯示卡，常被用於 AI 推理任務。選擇這款硬體來測量，是為了確保數據的公平性：兩款模型都在同樣的環境下進行測試。不過要注意，實際的延遲會因為硬體不同而有所差異。

指標	Laya（英文）	Laya（多語種）	Jev（公開數據）
單題延遲	38.4 ms	32.8 ms	175–276 ms
10 題批次延遲	156 ms	72.3 ms	未公開
單題平均延遲（批次處理）	15 ms	7.2 ms	—
參數量	421M	322M	未公開
上下文長度	512 文字單位	1024 文字單位（可至 8192）	64k 文字單位
準確率（任務內測試）	83.8%	—	94.0%（簡單選項分類）
ECE（校準誤差）	0.081（擬合後）	—	0.246

Laya 在延遲上確實有顯著優勢：約六到八倍。這是因為 Laya 完全跳過自回歸循環，所有選項在同一個前向傳遞中評估。Jev 雖然也是非生成模型，但它的實際部署延遲（包含網路時間）明顯較高。

從另一個角度看，這兩種模型代表了不同的設計哲學。Laya 追求的是極致的速度與成本效益，適合那些需要每秒處理成千上萬次決策的場景。Jev 則更強調準確率與上下文的理解深度，適合那些需要更細緻判斷的任務。選擇哪一個，取決於你的使用情境更看重速度還是精度。

不過要注意幾點：

1. Jev 的延遲數據來自第三方公開資料，不是受控的直接比較。另外一個獨立測量專案 jev-measured 報告從美國東部伺服器測得的 p50（中位數）延遲為 184 ms（不含網路地板時間），跟影片的 236–276 ms 有差距。
2. Jev 在 Banking77 的簡單選項分類準確率達到 94.0%，比 Laya 的任務內測試高出一段距離。但在選項數量超過 50 個時，Jev 準確率下降到 79.0%。
3. Laya 的多語種模型權重檔案支援超過一百種語言，延遲還更低（32.8 ms），這是 Jev 做不到的。

Laya 的結構限制與注意事項

選項預算限制

Laya 有一個重要的結構限制：總文字單位上下文被嚴格分成兩個區塊：狀態資料區和選項提示區。英文版本的選項預算由一個參數（GitHub README 標註為 head_max_len = 192）決定。

如果你嘗試傳入一個包含 77 個標籤的大型分類表，模型必須把這 192 個文字單位的預算平均分配到每個選項上。每個選項只分到約四個文字單位的語義空間。在這種密度下，選項之間的區別特徵會消失，準確率會掉到 0.425 的天花板。

解決方式有兩種：

• 手動覆蓋該參數值（利用 rope embeddings，也就是讓模型理解文字位置順序的一種編碼技術）
• 採用由粗到細的分層路由策略：把大型選項集拆成兩步決策樹，確保問題結構定義不超過 20 個選項

非拉丁語系的準確率問題

Laya 的英文主幹編碼器在處理非拉丁字元（例如高棉文）時，準確率會直接歸零。但有趣的是，模型在這種情況下依然維持超過 0.95 的信心分數。這意味著信心門檻機制在這裡完全失效。

解決方式是使用內建的 Router 模式：一個純 Python 腳本能在半毫秒內評估資料包的語言類型，並自動將非英文文字轉發到多語種模型權重檔案。不過要注意，預設的惰性載入策略在切換模型權重檔案時會產生超過 10 秒的冷啟動延遲，這會完全破壞 Laya 的 sub-40 ms 優勢。

解決方案是將兩個模型權重檔案鎖定在記憶體中：設定 preload=True 鎖定約 1.5 GB 記憶體，讓兩個模型都能即時存取。

序數量表評分的弱點

影片和原始碼都提到，序數量表是目前 Laya 架構中最薄弱的環節。在需要嚴格數學刻度的任務上，它的表現不如類別決策和布林值校準機率。如果你需要精確的量表評分，建議先用你自己的資料做微調。

Laya 的優缺點

Laya vs Jev：完整比較

Jev 提供的是雲端 API 服務，你不需要自己架設任何硬體，只要透過網路呼叫就能得到分類結果。Laya 則是開源模型，你可以自己安裝在自己的伺服器或電腦上。

維度	Laya	Jev
授權	Apache 2.0（開源）	閉源 API
部署方式	pip install + 本地 GPU	雲端 API（OpenRouter、TypeSafe）
單題延遲	38.4 ms（T4）	175–276 ms（公開數據）
價格	免費（自架成本 = 電費+硬體）	$0.042 每百萬文字單位輸入，輸出免費
單次決策實際成本	≈0（自有硬體）	$0.000015–0.000030
參數量	421M / 322M	未公開
顯示卡記憶體需求	~1.5 GB（預載入）	不需要
多語言	支援 100+ 語言	僅英文
可微調	是	否
最大選項數	建議不超過 20	最多 255
上下文長度	512 / 1024 文字單位	64k 文字單位
校準 ECE	0.081（擬合後）	0.246

Jev 提供的是雲端 API 服務，你不需要自己架設任何硬體，只要透過網路呼叫就能得到分類結果。Laya 則是開源模型，你可以自己安裝在自己的伺服器或電腦上。

什麼時候該選 Laya？

• 你需要極低延遲（sub-40 ms），且有自己的 GPU 硬體
• 你的資料涉及多語言，或需要處理非拉丁字元
• 你希望完全控制資料流，不想把敏感資料傳到第三方雲端
• 你需要的選項數量較少（不超過 20 個）

如果你的工作場景是每天需要處理數以萬計的簡單分類任務，而且對延遲有嚴格要求，Laya 會是你最好的選擇。它的開源性質也意味著你可以根據自己的需求客製化模型，而不必受制於任何第三方的定價策略。

什麼時候該選 Jev？

• 你不想管理硬體，只想呼叫雲端 API
• 你的 payload 很長（需要 64k 上下文），Laya 的 512–1024 文字單位可能不夠
• 你需要處理大量選項（最多 255 個），Laya 在超過 20 個選項時準確率會明顯下降
• 你已經在使用 OpenRouter，Jev 可以無縫整合

如果你的需求更偏向於需要深度理解的任務，而且你有足夠的預算來支付雲端服務的費用，Jev 的雲端方案會讓你省掉很多設定和維護的麻煩。特別適合那些不需要超低延遲、但需要處理大量選項的場景。

實際應用場景

在實際的企業環境中，決策模型最常見的使用方式是作為大型系統的第一層過濾器。想像你是一家電商公司的技術負責人，每天收到成千上萬封客戶來信。如果每封信都送去讓 LLM 分析，光是等待時間就可能超過十分鐘。但如果你先用 Laya 做初步分類，把明顯的問題快速分流，剩下的才交給更強大的模型處理，整個流程可以縮短到幾秒鐘以內。

這裡說的 LLM 就是大型語言模型，也就是我們平常會拿來聊天、寫文章的 AI，像是 ChatGPT 或 Claude。而決策模型完全不同，它不會跟你聊天，只會給你一個明確的答案和信心分數。這兩者的差別，就像是一個什麼都能聊的萬能助手跟一個專門做分類決定的專家之間的差異。

客服工單分流

這是一個非常典型的 Laya 使用案例。把工單內容作為 state，定義部門選項（engineering、billing、support）和緊急程度分數：

state = {"ticket": "我的帳單被重複扣款，請盡快處理"}
questions = {
    "department": {
        "type": "choice",
        "options": ["billing", "engineering", "general_inquiry"],
    }
}

接著再用 noul 原語判斷是否需要人工介入：

questions["escalate"] = {
    "type": "noul",
    "instructions": "Does this require human escalation?"
}

內容審核與安全檢查

在社群平台或部落格系統中，自動化的內容審核是不可或缺的功能。與其讓 LLM 逐一閱讀每篇文章然後寫出審核報告，不如先用 Laya 快速判斷內容是否有害、屬於哪個分類。這種做法不僅速度快，而且成本幾乎可以忽略不計。對於每天產生大量使用者內容的平台來說，這能節省大量的運算資源和費用。

questions = {
    "is_harmful": {
        "type": "noul",
        "instructions": "Does this content violate safety guidelines?"
    },
    "category": {
        "type": "choice",
        "options": ["spam", "abuse", "safe", "needs_review"],
        "instructions": "Classify this content"
    }
}

工具選擇（Agent routing）

在現在流行的 multi-agent 架構中，每個 AI 代理都需要根據任務類型選擇最適合的工具。multi-agent 這個詞聽起來很複雜，簡單說就是「多個 AI 協作」的概念，就像一間公司裡有不同部門的員工，每個人都負責不同的工作。如果每次選擇都送去讓 LLM 思考，成本會非常高。用 Laya 做工具選擇的守門員，可以把不必要的 LLM 呼叫降到最低，同時保持快速的反應時間。

在 multi-agent 系統中，每個步驟可能需要選擇不同的工具。用 Laya 可以在 sub-40 ms 內完成工具選擇，不需要呼叫昂貴的 LLM：

questions = {
    "tool": {
        "type": "choice",
        "options": ["search_web", "run_code", "read_file", "call_api"],
        "instructions": "Which tool should the agent use next?"
    }
}

總結

Laya 提供了一種跟傳統 LLM（大型語言模型，也就是我們常說的 ChatGPT、Claude 那種會一直生成文字的 AI）完全不同的 AI 決策方式：用一次前向傳遞取代文字生成循環，用校準機率取代不可靠的信心估計。對於需要低延遲、高吞吐量、可預測輸出的系統來說，這是一個值得考慮的方案。

你可以把 LLM 和決策模型的分類方式想成是兩種不同的工作風格。LLM 像是個喜歡深思熟慮的作家，他會一步步構思、寫下每個字，適合需要創造力和靈活性的任務。決策模型則像是個經驗豐富的快篩人員，他看過足夠多的案例後，能瞬間判斷出最可能的答案，適合那些只需要「對或錯」的決定。

它不是萬能的。選項數量受限、序數量表評分（score）表現較弱、非英文資料需要額外模型權重檔案。這些限制都意味著你需要根據自己的使用情境做出判斷。

如果你正在用 LLM 做簡單的分類或路由任務，而且對延遲或成本有要求，Laya 的開源方案值得花時間試試看。畢竟，不是每個 AI 問題都需要一個會聊天的模型來解決。有些時候，你只需要一個能快、準、狠地給出答案的夥伴。

接下來看什麼

• Jev AI：比 LLM 快 40–200 倍的決策模型：深入了解 Jev 的背景與原理
• Jev 模型：搭配 Claude Code 提速的三種用法：實際操作 Jev 的應用方式

常見問題

• Q：Laya 可以用在中文嗎？

可以。Laya 的多語種模型權重檔案支援超過一百種語言，包括繁體中文。不過非拉丁字元（例如高棉文）需要先用 Router 模式偵測語言，再轉發到對應的模型權重檔案。另外要注意，預設的惰性載入策略在切換模型權重檔案時會產生超過十秒的冷啟動延遲，這會破壞 Laya 的超低延遲優勢。如果要跑多語種，建議將兩個模型權重檔案都鎖定在記憶體中。

• Q：Laya 和 Jev 哪個比較適合新手？

如果你只是想測試一下，Jev 的雲端方案比較方便，不需要自己架設硬體。只要透過網路呼叫就能得到分類結果。但如果你想完全掌控自己的資料、而且有自己的 GPU，Laya 的開源方案會更划算。

• Q：為什麼 Laya 的選項數建議不超過二十個？

因為 Laya 的選項提示區只有固定大小的文字單位空間（英文約一百九十二個文字單位）。選項越多，每個選項分到的語義空間就越小，模型就無法區分細微差別。如果真的有大量分類需求，可以改用由粗到細的分層路由策略，把大問題拆成幾個小決策。

• Q：Laya 的機率校準真的可靠嗎？

Laya 使用 RLCD（Reinforcement Learning for Calibrated Decisions）訓練方式，讓模型在誠實報告機率時獲得最大獎勵。經過溫度擬合後，期望校準誤差（ECE）降到 0.081，代表當模型說它有百分之八十五信心時，實際準確率確實約在百分之八十五左右。這比 Jev 的 0.246 低了不少，對需要信心門檻的自動化系統來說很關鍵。