Laya 本機 System One 模型：安裝、用法與 Jev 比較

Laya 提供哪三個模型#

Laya 目前列出三個 checkpoint：

權重大小約 647 到 843 MB，實際執行還要加上 PyTorch、模型結構、中間張量與批次資料的記憶體。它不是一個幾十 MB 的分類器；若正式服務需要高併發，仍要估算 GPU、常駐記憶體與冷啟動。

Laya 的輸出介面模仿 System One 常見的三種 primitive：choice、score 與 noul。它也是非自回歸模型，一次 forward pass 可以處理同一 state 上的多個問題。

安裝與第一個本機判斷#

先建立獨立 Python 環境，再安裝 PyPI 套件：

1
python3 -m venv .venv
2
source .venv/bin/activate
3
pip install laya

README 建議從 Router 開始。它會依文字語言與 script 選擇英文或多語 checkpoint：

1
from laya import Router
2

3
router = Router(preload=True)
4

5
state = {
6
    "subject": "帳單重複扣款",
7
    "body": "信用卡被扣了兩次，請協助退款。",
8
}
9

10
questions = {
11
    "department": {
12
        "type": "choice",
13
        "instructions": "哪個部門應處理這則訊息？",
14
        "criteria": {
15
            "billing": "帳單、付款與退款",
16
            "technical": "系統錯誤與串接問題",
17
            "sales": "價格與新合約",
18
            "other": "其他",
19
        },
20
    },
21
    "refund_requested": {
22
        "type": "noul",
23
        "instructions": "使用者是否明確要求退款？",
24
    },
25
}
26

27
result = router.predict(state, questions)
28

29
print(result["routing"])
30
print(result["answers"]["department"])
31
print(result["answers"]["refund_requested"])

preload=True 會預先載入 checkpoint，以換取之後較低的呼叫延遲，但也會增加啟動時間與記憶體使用量。第一次執行還需要從 Hugging Face 下載權重；正式部署應先完成下載並固定模型 revision，避免啟動時受到外部網路或權重更新影響。

如果已確定只處理單一語言，也能直接載入指定模型：

1
import laya
2

3
agent = laya.load(
4
    "convaiinnovations/laya",
5
    subfolder="multilingual",
6
    device="cuda",
7
)
8

9
result = agent.predict(state, questions)

以上介面依 Laya 0.3.4 repository 與模型卡整理。本機檢查確認 PyPI metadata、套件原始碼與模型檔案存在；本文沒有下載完整權重跑 GPU 推論，因此延遲與範例輸出仍以專案公布資料為準。

33 ms 很快，但條件要寫完整#

Laya 公布的 Tesla T4 測量中，多語模型單一問題約 32.8 ms；一次處理 10 個問題為 72.3 ms，平均每題 7.2 ms。這是 GPU forward pass 的測量，不包含首次下載、模型載入、應用程式排隊、網路 API 包裝或 CPU 環境差異。

更重要的是準確率。專案自己的 benchmark 明確揭露：

• 基礎 laya 與 laya-multilingual 在 typed-decisions zero-shot 測試只得到 0.362 與 0.342，接近 0.318 的隨機基準，也低於 0.461 的多數類別基準。
• 專門微調的 laya-typed-decisions 在相同 2,000 個 decision 上得到 0.766。
• 高分能力主要來自針對該 workflow 的微調，不能當成任意領域的 zero-shot 表現。
• 模型原始輸出過度自信，專案建議以自己的資料重新做 temperature fitting。
• score 是目前較弱的 primitive，大量選項也會受到 Token 分配影響。

這些限制反而說明比較合理的定位：Laya 是可自行微調的快速判斷底座，不是下載後就能理解所有公司分類規則的萬用模型。

Laya 和 Jev 怎麼選#

少量或不固定的請求，Jev API 通常比較容易估算；資料敏感、請求量大、能維護模型服務，或需要針對內部標籤微調時，Laya 才比較有評估價值。

不要只拿單次推論價格比較。自架模型還有 GPU 閒置、容器映像、權重更新、監控、校正與事故處理成本；雲端 API 則要考慮資料傳輸、供應商限制與服務可用性。

上線前要做的四個檢查#

第一，先建立自己的 holdout dataset，不要使用微調資料衡量正式準確率。第二，分語言看準確率與 ECE，尤其繁體中文不要和英文平均。第三，測試選項順序、other 案例及對抗性文字。第四，將高影響操作放在程式規則與人工審核後面。

「沒有文字生成」不等於「沒有 hallucination」。Laya 不會寫出 schema 外的答案，但仍會自信地分錯類；它的 README 也直接記錄英文 checkpoint 對非拉丁文字可能高信心答錯。格式安全與語意正確必須分開驗證。

想先理解這類模型的共同介面，可讀 Jev 是什麼？；若決定採用託管 API，可接著看 Jev TypeScript API 教學。如果需求來自 Codex 額度問題，則先確認 Skill、MCP 與 Router 的差異，不要把安裝套件當成成本優化完成。

常見問題#