Laya 在 Apple Silicon 上：MLX 移植帶來什麼，以及沒帶來什麼

Laya 是一種從不寫出任何句子的決策模型。Convai Innovations 於 2026-09-18 把權重放上 Hugging Face，隔天一位名叫 mizorewww 的開發者發表了Laya-MLX——一個獨立移植版本，透過 MLX 在 Apple Silicon 上原生執行全部三個 Laya 檢查點，不需 PyTorch、不需 Transformers 執行環境，也不呼叫雲端。該移植版在 M3 Max 上回報：421M 檢查點回答一個簡短英文問題的中位數為 13.42 毫秒，322M 多語言版本為 7.39 毫秒，輸出 token 數為零。與此同時，Kev，另一個追求相同型別化決策理念的開放家族，則建構在 Qwen3.5-4B-Base 之上，而且在 Mac 上可用之前還需要一整套第二後端，因為 PyTorch 在 Apple 的 GPU 上沒有針對其 DeltaNet 層的運算核心。兩個專案、同一週、同一個目標，而只有其中一個乾淨俐落地完成移植。這個差異就是整件事的重點，而且這是執行環境的故事，不是模型的故事。

這件事今天值得寫成一篇文，原因不在於 Laya 很新，而是在 2026-09-19 之前，想在 Mac 上執行具型別決策模型，就別無他法地得連整套 PyTorch 堆疊一起拖進來；而讀者真正想問的問題——我能在自己的筆電上跑這個嗎？我得放棄什麼？——終於有了可衡量的答案。所以這篇文章談的是服務路徑、它背後的數字，以及那些數字不再代表它們表面上看起來的意思的地方。

首先，Laya 不是什麼

Laya 不是 LLM。它是非自迴歸的：對狀態與你的問題進行一次雙向前向傳遞，然後輸出的是具型別的答案。沒有逐 token 解碼，沒有思維鏈，沒有生成的 JSON 需要解析，也沒有輸出 token 可供計費。三個答案原語是選擇（從 N 個具名選項中選一個）、分數（一個有序的評分規準等級）以及 noul（某件事為真的校準機率）。

這對你如何解讀本文中的每一個數字至關重要。當這個移植版回報 13.42 ms 時，它並不是像生成基準測試那樣，回報產生數百個 token 所需的 13.42 ms。它回報的是整個操作。把決策模型的延遲拿來和 LLM 的每秒 token 數相比，是在比較兩種不同的工作；任何這樣做的文章——包括發布後流傳、爆紅的「比 Jev 快 50 倍」貼文——都在提出一項其背後工作無法支撐的主張。

這個埠實際測量了什麼

這些數據是移植作者自己的，是在明確指定的機器上取得的，閱讀時應一併參照隨附的機器與方法。Laya-MLX 是在 M3 Max 上測得這些數據，配備 40 個 GPU 核心與 128 GiB 統一記憶體，採 FP16 精度，且不計入模型載入時間。

• 一個簡短問題，P50 — 在 421M 英文檢查點上為 13.42 ms，在 322M 多語言檢查點上為 7.39 ms。

• 一個簡短問題，P95 — 分別為 13.92 毫秒與 7.79 毫秒。

• 50 題吞吐量 — 每秒 146.8 題及每秒 395.0 題。

• MLX 峰值分配 — 943.6 MiB 與 687.6 MiB。

計時邊界是值得再讀一次的部分。它包含提示準備、分詞、張量建構、同步推論、校準與結果格式化。它不包含模型載入。50 題的吞吐量測試使用了 batch_size=64，而 API 預設為 16，所以這兩個數字描述的是刻意批次化的工作負載，而不是單次互動呼叫的成本。不同的輸入長度、不同的問題數量，以及不同的執行環境條件，都會改變結果。這些注意事項正是「一個數字」與「一項基準測試」之間的差別，而該移植版本本身也說明了這些。

記憶體下限是大多數讀者會據以行動的數字，也是這組數據中最不含糊的一項：針對單一簡短問題，在兩個檢查點上，MLX 峰值配置都不到 1 GB。這並不是在宣稱你 Mac 的整體佔用量——OS、你的終端機和 Python 行程都與它並存——但它是名副其實的下限，而且大約比在本機執行中型生成式模型所需低三個數量級。

保真度檢查是更有趣的結果

一個快速移植版若其回答與它所移植的模型不同，便毫無價值，而這正是該專案完成關鍵工作之處。三個檢查點在所有 63 題驗證問題中，都與上游所選答案相符——無論是 FP32 還是 FP16，共 378 次比較中 378 次全數吻合。每個組態也執行了 100 次重複且具確定性的呼叫，並未測得作用中記憶體成長，且所有 36 個已發布的權重檔案都通過嚴格的遠端總和檢查碼驗證。

誠實地解讀這個範圍：那衡量的是在那些測試樣本上的保真度，而不是對所有可能問題的準確度。它告訴你這個移植版忠實於 Laya。它完全沒有告訴你 Laya 本身是否正確。

獨立、由社群維護，卻仍不在名單上

這個移植版兩度如此自述：它是獨立的 MLX 移植版，不是 Convai Innovations 的官方發行版。RLCD 訓練與微調留在上游。權重歸功於 Convai Innovations。雙方皆採用 Apache-2.0。

上游如何對待它，比任何免責聲明都更能說明問題。Laya README 帶有一份 Community Tools 清單，而截至 2026-09-23，其中包含四個條目：omp-laya-judge、laya-adk-toolkit、laya-Ascend（用於 Huawei Ascend NPU），以及 laya-apple——一個使用 MLX GPU 與 Neural Engine 的 Apple Silicon 執行環境。第四個條目是透過 2026-09-23 合併的 pull request #260 加入的。本文所談的移植並不在這四個之中。上游的清單現在把 Apple Silicon 讀者指向另一個社群專案，而不是最早推出且擁有基準測試的那個專案。

上游自家的問題追蹤器交代了其餘部分。第 50 號問題「Apple silicon ports」於 2026-09-21 開啟，至今仍未結案；維護者當天即回覆表示 Apple Silicon 支援正在追蹤中，而像 Laya-MLX 這類社群移植專案正探索原生 Metal 推論，接著又於 2026-09-23 回覆，其中一句值得逐字引用：「The MLX port remains community-maintained.」PyTorch 端的修正——MPS 自動轉型與 transformers 4.x 的 RoPE 校正——以 pull request #273 的形式提交，於 2026-09-23 合併，該討論串中有位審查者指出，這項修正仍需與 #109 中另一項獨立的自動轉型重構合併，而後者仍未結案。此外，2026-09-21 開啟的第 52 號問題回報，一個 Laya-MLX sidecar 在運作數小時後，Metal 記憶體成長到約 21.7 GB，其中 vmmap 將約 21.4 GB 歸因於繪圖子系統，而非 Python 堆積；該問題提議為配置器快取設定上限，並在每次推論後予以清除，而它仍未結案。

把這些放在一起看，實際的答案是：這個執行環境並未獲得上游背書，依維護者自己的說法，它是由社群維護的；而對長時間執行的 sidecar 來說，唯一真正重要的記憶體問題，目前是在公開場合處理，而不是已在某個發行版中修正。

我可以在我的筆電上執行它嗎？又得犧牲掉什麼？

安裝只需要一個 pip 指令，而且這個移植版本會發佈已預先轉換好的 FP16 權重，因此你不必自行轉換任何東西：

pip install laya-mlx

然後import laya_mlx as laya、agent = laya.load("aac6fef/laya-mlx")，並呼叫agent.predict(state, questions)。需求為 Apple Silicon、Python 3.11+ 與 macOS 14+。實測環境為 macOS 27.2、Python 3.12.13 與 MLX 0.32.2——而該移植版本指出，其使用的 MLX 版本提供了 macOS 14、15 與 26 的 wheel，但安裝程式選了 26 那一個，且該機器並未測試較舊的受支援 macOS 版本。

你在每個維度上放棄了什麼：

• FP16 與 FP32 — FP16 是預設值，也是上述每一個重點數字的來源。FP32 與上游的數值一致性更高；即使所選標籤一致，不同精度下的機率仍可能略有差異。BF16 可以要求使用，但不屬於已發布的驗證矩陣，因此請將其視為未經測試。

• 記憶體下限與餘裕——對於簡短問題，峰值 MLX 配置低於 1 GiB 在任何 M 系列 Mac 上都算舒適。這並不代表持續的伺服器負載，而如果你打算把它當作長期執行的 sidecar 而非函式庫呼叫來運行，issue #52 正是你該謹慎以對的原因。

• 多語言與英語的比較 — 322M 多語言檢查點是兩者中較快的那個，也是涵蓋 100 多種語言的那個，但這個移植版本刻意沿用了上游的警告：英語檢查點不能取代多語言檢查點。在兩者之間進行路由是預期的模式，而非可有可無的講究。

• 上游認可 對比 社群維護——是後者。上游發行說明中沒有任何內容承諾這個移植版在上游變更後仍能繼續運作。

• 速度與校準——快速移植版無法修正一個出貨時就過度自信的校準分桶。上游會將擬合後的溫度限制在 [0.5, 5.0]，而出貨的 choice:11+ 分桶是 0.1006，這會把 logits 銳化約十倍，並把五五波的結果回報成近乎確定。擬合校準溫度存在有其道理；在依據機率做分支之前，先用你自己的留出資料擬合它們。

還有兩項限制值得記住，兩者都來自上游自己的追蹤器。 action.act_probability 目前不帶任何可用訊號——幾乎每個輸入都讀為 1.0，而其原始 logits 在 396 個已標註決策上對照正確性的 AUROC 為 0.30（issue #185）。改用 confidence 來把關，它在相同項目上達到 0.77。而且 noul 問題可能會跟隨其選項標籤，而非狀態（issue #156）——上游自己的卡片在明確正向輸入上回報了自信的「no」，在英文檢查點上最為明顯。它建議的變通方法不是改用不同模型，而是重塑問題：以兩個選項的 choice 來提問，使用中性鍵（A/B），並把你的 yes/no 措辭作為選項描述。

為什麼其中一個決策模型能乾淨地移植，另一個卻不能

這裡的差異是架構層面的，而對任何必須在這兩個系列之間做選擇的人來說，這是本文中最有用的一點。

Laya 的骨幹是 ModernBERT-large，一個完全由注意力構成的雙向編碼器。注意力正是 Apple GPU 堆疊最擅長的事，也是 MLX 投入心力之處。因此這次移植是對原本就已有快速路徑的層進行重新實作：編碼器、決策頭的 Transformer 層、評分頭與動作頭全都在 MLX 中執行，而分詞仍透過 Hugging Face 的 Rust 分詞器處理。

Kev 的主幹是 Qwen3.5 基礎模型，而 Qwen3.5 將注意力層與 Gated DeltaNet 層混合在一起。DeltaNet 是遞迴式的，會忽略注意力遮罩。這帶來兩個後果。首先，每個問題都必須以自己的列執行，而無法共用同一個遮罩序列；Kev 專案對此的處理方式是只計算一次狀態，並讓每一列重複使用其快取。其次——而這正是會在 Mac 上造成痛點的部分——Apple 的 GPU 上並沒有針對這些層的 PyTorch 核心，因此 PyTorch 退回到了參考實作程式碼。jaredpalmer/kev-4b 模型卡仍以淺白文字記載了由此產生的限制：一個五題請求在 Kev-4B 的 Qwen3 版本上只需 0.17 秒，在 M5 上以 bf16 執行則需 0.78 秒。

引用之前請先確認目前的措辭，因為它已經變了。Kev 儲存庫的 README 現在表示，伺服器改為在 Apple Silicon 上透過 MLX 執行 Qwen3.5 模型，並公布自家的 M5 數據：在約 270 個 token 的狀態下，針對一個五題、每題三個選項的請求，Kev-4B 在新狀態下為 721 毫秒，透過前綴快取在重複狀態下為 136 毫秒，對比 PyTorch bf16 MPS 路徑上的 3,302 毫秒與 847 毫秒。Kev-0.8B 則為 149 毫秒與 28 毫秒。上一代的 Qwen3 模型仍然在純 PyTorch MPS 上執行，該專案稱它們在 Mac 上是個不錯的選擇。

請小心，別把這變成比賽結果。這些不是正面對決的測量。Laya-MLX 的 13.42 毫秒，是 M3 Max 上的一道簡短問題；Kev 的 721 毫秒，則是 M5 上約 270 個 token 狀態下的五道題，每題三個選項。題數不同、選項數不同、狀態長度不同、機器不同、執行環境也不同。真正可驗證且值得比較的是問題的樣貌，而不是贏家：純注意力編碼器移植到 Apple Silicon 毫不費力，而混合線性注意力模型則需要一整套第二後端，才能在那裡使用。

決策模型的真正用途

撇開基準測試不談，誠實的適用場景其實很狹窄，而專案本身也這麼說：Laya 是能快速進行特化的基礎，而非零樣本決策引擎。在 Convai 自家的 typed-decisions 基準測試中，兩個基礎檢查點零樣本得分分別為 0.362 和 0.342，相較之下，多數類別基線為 0.461，隨機基線為 0.318。它們低於你總是回答最常見標籤時所得到的界線。最受矚目的 0.766 屬於 laya-typed-decisions，這個檢查點是在該基準測試自己的訓練分割上微調而成，而且絕不應被引用為通用能力。

Convai 針對 TypeSafe Jev 1.13.0 所發布的比較報告，正因如此值得一讀，而且在他們那邊標示得很謹慎：每一個 Laya 數字都是路由器實際回傳的結果，而 Jev 的數字則是第三方公布的數據，Convai 從未測量過，因為它沒有 TypeSafe API 存取權限。在該比較中，經過路由的 Laya 在型別化決策上得分為 0.766，Jev 為 0.727；溫度後 ECE 為 0.081 對 0.246；在 Tesla T4 上的 p50 延遲為 32.8 毫秒對 236–276 毫秒——在一個問題上有 7.8 倍的差異。那才是應該引用的數字。在社群媒體上流傳的「比 Jev 快 50 倍」這個數字，並未出現在該專案的文件或其基準測試中，而且該專案自己發布的比較也不支持這個說法。Jev 在它領先的地方也確實領先：在 Banking77 上，Jev 得分為 0.870，而 Laya 為 0.425，因為 Laya 的選項共享固定的 token 預算，而 77 個標籤每個大約只剩三到四個 token。

所以，真正部署的形貌是一個決策頭部：便宜、地端、專一——分派工單、為急迫性評分、回答是／否的閘門——背後再由生成式模型負責需要撰寫的部分。決策模型在毫秒內做出具型別的判定，然後升級處理。生成的那一半是不同執行環境上的不同模型，而這正是路由器發揮價值之處：200 多個模型透過單一金鑰取用，依供應商定價、不加價，因此供應商價格一有變動，當天就能生效，而且當供應商在執行途中效能下降時自動容錯移轉。OrcaRouter 不提供 Laya，也不提供 Kev 或 Jev——Qwen3.5 系列列在我們的模型清單上，決策模型本身則不在。我們涵蓋的是那個技術堆疊中生成的一半，也就是決策頭部每次升級請求時，你所呼叫的那一半。

還有一個理由要讓這兩個半部保持分開，而不是訴諸單一模型來同時完成兩者。一個成本為零個輸出 token、且從不觸及網路的本機決策頭，是與 API 呼叫不同種類的依賴：當網路不通時，它仍能運作，而且它的成本不會隨著它讀取多少文字而增加。那就是值得付出代價換取的特性。本文其餘部分談的則是，你為了它在保真度、記憶體和維護方面付出了多少代價。

誰應該執行，誰應該等待

執行 Laya-MLX，前提是你使用 M 系列 Mac、你的決策是受約束的——從具名選項中擇一、評分表分數、是／否閘門——而且你要嘛有標籤可供微調，要嘛已準備好自行擬合校準溫度。安裝只需一行指令，記憶體需求下限不到 1 GB，而且保真度相關的工作已經完成並公開發表。

等一下，如果你需要上游支援保證，如果你執行的是長期運行的 sidecar，並且希望記憶體成長的問題能在某個發行版本中獲得解決，而不是留在一個未結案的 issue，或者你的問題本來就是開放式的。非自迴歸編碼器在回答「我下一步該做什麼」時，並不是在做同一件事的 LLM 的縮小版。它是一種不同的工具，而且唯有當問題已經被形塑成適合它的樣子時，它才能讀得順。