Apple Silicon上のLaya：MLX移植で得られるもの、得られないもの

Layaは、文を一切書かない意思決定モデルだ。Convai Innovationsは2026年9月18日にその重みをHugging Faceで公開し、翌日、mizorewwwという開発者が公開したのはLaya-MLX——MLXを通じて3つすべてのLayaチェックポイントをApple Silicon上でネイティブに実行する独立した移植版であり、PyTorchもTransformersランタイムもクラウド呼び出しも使わない。この移植版は、M3 Max上で、421Mチェックポイントでの短い英語の質問1件に対して中央値13.42 ms、322Mの多言語版で7.39 ms、出力トークンはゼロだと報告している。一方、Kevは、同じ型付き意思決定のアイデアを追うもう一つのオープンなファミリーだが、Qwen3.5-4B-Base上に構築されており、Macで使えるようになる前にバックエンドをもう一つ丸ごと必要とした。PyTorchにはAppleのGPU上でそのDeltaNet層向けのカーネルがないからだ。2つのプロジェクト、同じ週、同じ目標、そしてクリーンに移植できたのはそのうち1つだけだった。その違いこそが物語であり、それはモデルの物語ではなくランタイムの物語だ。

今日これを記事にする価値がある理由は、Layaが新しいからではない。2026-09-19以前は、PyTorchスタックを一緒に引きずることなくMac上で型付き意思決定モデルを実行する方法が存在しなかったということ、そして読者が実際に抱く疑問――自分のラップトップでこれを実行できるのか、その代わりに何を諦めるのか――についに測定可能な答えが出たということだ。だから本稿は、サービング経路、その背後にある数値、そして数値が見かけ通りの意味をなさなくなる箇所について扱う。

まず、Layaが何ではないかについて

Laya は LLM ではありません。非自己回帰的です。状態とあなたの質問に対して双方向のフォワードパスを 1 回行うと、型付きの回答が出てきます。トークンごとのデコーディングも、思考の連鎖も、解析すべき生成済み JSON も、課金対象の出力トークンもありません。3 つの回答プリミティブは 選択（N 個の名前付き選択肢から 1 つを選ぶ）、スコア（順序尺度のルーブリックレベル）、および noul（何かが真であるという較正済み確率）です。

それは、この記事のすべての数値をどう読むかに関わってくる。そのポートが13.42 msと報告するとき、生成ベンチマークのように数百トークンを生成するための13.42 msを報告しているのではない。操作全体を報告しているのだ。意思決定モデルのレイテンシをLLMのトークン毎秒と比較するのは、二つの異なる仕事を比較しているのであり、それをしている記事は——ローンチ後に広まった「Jevより50倍速い」というあのバイラル投稿を含め——、基盤となる作業が裏付けていない主張をしている。

ポートが実際に測定したもの

これらの数値は移植の作者自身によるもので、明示されたマシン上で取得されたものであり、マシンと手法を添えて読むべきものです。Laya-MLX は M3 Max（GPUコア40基、ユニファイドメモリ128 GiB）上で、FP16、モデルの読み込みを除いた条件で測定しました。

• 短い質問を1つ、P50 — 421M英語チェックポイントでは13.42 ms、322M多言語チェックポイントでは7.39 ms。

• 短い質問1件、P95 — それぞれ13.92 msと7.79 ms。

• 50問のスループット — 1秒あたり146.8問、および1秒あたり395.0問

• ピーク時のMLX割り当て — 943.6 MiB と 687.6 MiB

タイミングの境界は、二度読む価値のある部分だ。そこにはプロンプトの準備、トークン化、テンソル構築、同期推論、キャリブレーション、そして結果のフォーマットが含まれる。モデルの読み込みは含まれない。50問のスループット実行ではbatch_size=64を使用したが、APIのデフォルトは16なので、この2つの数値は単一の対話的な呼び出しにかかるコストではなく、意図的にバッチ処理されたワークロードを表している。入力長の違い、質問数の違い、実行環境の違いは、いずれも結果を変動させる。こうした注意書きこそが、単なる数値とベンチマークの違いであり、ポート自体がそれを明記している。

メモリの下限値は、ほとんどの読者が実際に行動の基準にする数値であり、このセットの中で最も曖昧さの少ないものです。短い質問1回あたり、両方のチェックポイントで、MLXのピーク割り当てが1ギガバイト未満です。これはあなたのMacの総使用量についての主張ではありません——OS、ターミナル、Pythonプロセスもすべてその横に並んでいます——が、これは紛れもない下限であり、中規模の生成モデルをローカルで動かすために要求される量よりおよそ3桁小さいものです。

フィデリティチェックのほうがより興味深い結果だ

移植元のモデルと異なる回答を返す高速な移植版は無価値であり、まさにここでこのプロジェクトは重要な作業を成し遂げた。3 つすべてのチェックポイントは、FP32 と FP16 の両方で、63 件中 63 件の検証質問においてアップストリームの選択回答と一致した — 378 件中 378 件の比較である。各構成はまた、アクティブメモリの増加が測定されることなく、100 回の反復された決定論的呼び出しを実行し、公開された 36 個の重みファイルはすべて厳格なリモートチェックサム検証に合格した。

範囲を正直に読み取ること：それはそれらのフィクスチャに対する忠実度を測っているのであって、あらゆる可能な問いに対する正確さを測っているわけではない。それは、その移植版がLayaに忠実であることを教えてくれる。Layaが正しいかどうかについては何も教えてくれない。

独立系で、コミュニティ運営で、それでもリストには載っていない

この移植版は、自身についてこう二度述べている。つまり、これは独立したMLX移植版であり、Convai Innovationsによる公式リリースではない。RLCDのトレーニングとファインチューニングはアップストリームに留まる。重みはConvai Innovationsに帰属する。双方ともApache-2.0である。

アップストリームがそれをどう扱っているかは、どんな免責事項よりも雄弁に語る。Laya の README にはコミュニティツールのリストがあり、2026-09-23 時点で4つの項目が載っている：omp-laya-judge、laya-adk-toolkit、laya-Ascendは Huawei Ascend NPU 向け、そしてlaya-apple——MLX GPU と Neural Engine を使う Apple Silicon ランタイムだ。この4番目の項目は、2026-09-23 にマージされたプルリクエスト #260 によって加わった。本記事が扱うポ ートは、この4つの中には含まれていない。アップストリームのリストは今や、Apple Silicon の読者を、最初にリリースされベンチマークを備えたものとは別のコミュニティプロジェクトへと導いている。

残りの事情は、上流自身のイシュートラッカーが示している。2026-09-21 に起票された Issue #50「Apple Silicon 移植」は依然としてオープンであり、メンテナーは同日、Apple Silicon サポートは追跡中であり、Laya-MLX のようなコミュニティによる移植版がネイティブ Metal 推論を模索していると返信した。さらに 2026-09-23 には、正確に引用する価値のある一文を添えて再び返信した。「MLX 移植版は引き続きコミュニティによって維持管理されている」。PyTorch 側の修正 — MPS autocast と transformers 4.x の RoPE 補正 — はプルリクエスト #273 として取り込まれ、2026-09-23 にマージされたが、そのスレッドのレビュアーは、#109 にある別個の autocast リファクタリングと組み合わせる必要がまだあると指摘しており、#109 は依然としてオープンである。また、2026-09-21 に起票された Issue #52 は、数時間の動作で約 21.7 GB の Metal メモリにまで増大した Laya-MLX サイドカーを報告しており、vmmapは約 21.4 GB を Python ヒープではなくグラフィックスサブシステムに帰属させている。また、アロケーターキャッシュを制限し、各推論後にそれをクリアすることを提案しているが、依然としてオープンである。

これらをまとめると、実用的な答えはこうだ。このランタイムはアップストリームのお墨付きを得ておらず、メンテナー自身の説明によればコミュニティによって維持されており、長時間稼働するサイドカーにとって重要な唯一のメモリ問題は、リリースで修正されるのではなく、公開の場で取り組まれている。

ノートパソコンで実行できますか、その場合何を諦めることになりますか

インストールは pip コマンド1つだけで、この移植版は変換済みの 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 でも快適です。これは持続的なサーバー負荷についての主張ではなく、ライブラリ呼び出しではなく長期稼働するサイドカーとしてこれを実行する予定なら、注意すべき理由は issue #52 にあります。

• 多言語版と英語版 — 322M の多言語チェックポイントは二者のうちより高速なもので、100 以上の言語をカバーするものだが、この移植版はアップストリームの警告を意図的に引き継いでいる。英語のチェックポイントは多言語版の代替にはならない。両者を使い分けるルーティングこそが想定されたパターンであり、単なる付け足しではない。

• アップストリーム公認かコミュニティ維持か — 後者である。アップストリームのリリースノートには、この移植版がアップストリームの変更を経ても動作し続けることを約束する記述はどこにもない。

• 速度と較正のトレードオフ — 高速な移植は、自信過剰なまま出荷される較正バケットを修正してはくれない。上流はフィット済み温度を[0.5, 5.0]にクランプしており、出荷されるchoice:11+バケットは0.1006で、これはロジットをおよそ10倍に鋭くし、コイントスをほぼ確実なものとして報告してしまう。フィット済みの較正温度にはちゃんとした理由がある。確率で条件分岐する前に、自分のホールドアウトデータでそれらをフィットさせよ。

さらに2つの制約は引き継ぐ価値がある。いずれも上流自身のトラッカーに由来するものである。action.act_probabilityは現在、使えるシグナルを何も持っていない——ほぼすべての入力で1.0を返し、その生のロジットは396件のラベル付き判断にわたって正確さに対するAUROCが0.30だった（issue #185）。代わりにゲートをかけるべきはconfidenceであり、同じ項目では0.77に達する。そしてnoulの質問は、状態ではなく選択肢ラベルに従うことがある（issue #156）——上流自身のカードは、明らかに肯定的な入力に対して自信を持って「いいえ」と報告しており、これは英語チェックポイントで最も顕著である。そこで提案されている回避策は、別のモデルに頼ることではなく、質問の形を変えることだ。つまり、2択のchoiceとして尋ね、中立のキー（A/B）を使い、はい/いいえの文言を選択肢の説明として用いるのである。

なぜ一方の意思決定モデルはきれいに移植でき、もう一方はできないのか

ここでの対比はアーキテクチャに関するものであり、2つのファミリーのどちらかを選ぼうとしている人にとって、この記事の中で最も役立つ情報です。

Laya のバックボーンは ModernBERT-large であり、完全にアテンションのみで構築された双方向エンコーダーだ。アテンションは Apple の GPU スタックが最も得意とする領域であり、MLX が注力してきた領域でもある。したがって、この移植は、すでに高速パスを備えていたレイヤーの再実装である。エンコーダー、決定ヘッドの Transformer 層、スコアリングヘッド、アクションヘッドはすべて MLX 上で動作し、トークン化は依然として Hugging Face の Rust トークナイザーを経由する。

KevのバックボーンはQwen3.5ベースで、Qwen3.5はアテンション層とGated DeltaNet層を組み合わせている。DeltaNetはリカレントであり、アテンションマスクを無視する。これには2つの帰結がある。第一に、各質問は1つのマスクされたシーケンスを共有するのではなく、それぞれ独自の行として実行する必要があり、Kevプロジェクトでは状態を一度計算してそのキャッシュを行ごとに再利用することでこれに対処している。第二に——そしてこれがMacでこたえる部分だが——AppleのGPU上にはこれらの層向けのPyTorchカーネルが存在しなかったため、PyTorchはリファレンスコードへフォールバックした。jaredpalmer/kev-4bのモデルカードには、その結果生じた制限がいまも平易な言葉で記されている。Qwen3ビルドのKev-4Bでは0.17秒で済む5問のリクエストが、M5上のbf16では0.78秒かかる。

それを引用する前に、現在の文言を確認してください。記載が変わっているためです。Kev リポジトリの README では現在、サーバーは Apple Silicon 上で MLX を通じて Qwen3.5 モデルを実行するようになったとされており、約270トークンの状態で各3択の5問からなるリクエストについて、独自の M5 数値を公開しています。Kev-4B は新しい状態で 721 ms、プレフィックスキャッシュを介した繰り返し状態で 136 ms であるのに対し、PyTorch bf16 MPS パスでは 3,302 ms と 847 ms です。Kev-0.8B は 149 ms と 28 ms という結果です。前世代の Qwen3 モデルは依然として通常の PyTorch MPS で動作し、プロジェクトは Mac での優れた選択肢だと述べています。

それを競争結果にしないよう注意してください。これらは直接対決の測定ではありません。Laya-MLX の 13.42 ms は、M3 Max 上での短い質問 1 つです。Kev の 721 ms は、M5 上の約 270 トークンの状態で、それぞれ 3 つの選択肢がある 5 つの質問です。質問数も選択肢の数も状態の長さもマシンもランタイムも異なります。検証可能で比較に値するのは、勝者ではなく問題の形です。純粋なアテンションのエンコーダーは Apple Silicon に苦労なく移植できるのに対し、ハイブリッド線形アテンションモデルはそこで使えるようになるまでに、第 2 のバックエンドをまるごと必要としました。

意思決定モデルは実際に何のためにあるのか

ベンチマークを脇に置けば、正直なところ実用的なユースケースは限定的であり、プロジェクト自身もそう述べている。Layaは特化させるための高速な基盤であって、ゼロショットの意思決定エンジンではない。Convai自身の typed-decisions ベンチマークでは、2つのベースチェックポイントはゼロショットで0.362と0.342を記録し、多数クラスベースラインの0.461、ランダムの0.318と対比される。これらは、常に最も頻出するラベルを答えた場合に得られる水準を下回っている。注目の0.766はlaya-typed-decisions、すなわちそのベンチマーク自身の学習用分割でファインチューニングされたチェックポイントのものであり、一般的な能力として引用してはならない。

Convai が公開した TypeSafe Jev 1.13.0 に対する比較は、まさにこの理由で読む価値があり、Convai 側では慎重に注記されている。Laya の数値はすべてルーターが実際に返す値であり、Jev の数値は第三者が公開した数値で、Convai は TypeSafe API にアクセスできないため測定していない。その比較では、ルーティングされた Laya は typed-decisions で Jev の 0.727 に対して 0.766 を記録し、post-temperature ECE は 0.246 に対して 0.081、Tesla T4 上の p50 レイテンシは 236～276 ms に対して 32.8 ms である — 1つの質問で 7.8 倍の差だ。引用すべきなのはこの数値だ。SNS で広まった「Jev より 50 倍速い」という数値は、プロジェクトのドキュメントにもベンチマークにも登場せず、プロジェクト自身が公開した比較でも裏付けられていない。Jev が優位なところでは優位だ。Banking77 では、Jev は Laya の 0.425 に対して 0.870 を記録する。Laya の選択肢は固定のトークン予算を共有しており、77 個のラベルではそれぞれおよそ 3～4 トークンしか残らないためだ。

つまり、実際のデプロイの形とは、安価でローカルで範囲の狭い判断ヘッド — チケットのルーティング、緊急度のスコアリング、イエス／ノー判定への回答 — であり、その背後に、書き出す必要のある部分を担う生成的な何かが控えている。判断モデルは型付きの呼び出しをミリ秒で下し、エスカレーションする。生成側の半分は別のランタイム上の別のモデルであり、まさにそこがルーターの出番だ：1つのキーの背後に200以上のモデルをプロバイダーの定価で、マークアップなしで、だからベンダーの価格変更はその日のうちに反映され、プロバイダーが実行途中で劣化したときの自動フェイルオーバー。OrcaRouterはLayaを提供しておらず、KevやJevも提供していない — Qwen3.5ファミリーは当社のモデルリストに載っており、判断モデル自体は載っていない。当社がカバーするのはそのスタックの生成側の半分であり、それは判断ヘッドがエスカレーションするすべてのリクエストで呼び出される側の半分だ。

両方とも1つのモデルでこなそうとするのではなく、2つの半分を別々に保つ理由がもう1つある。出力トークンを一切消費せず、ネットワークに決して触れないローカルな決定ヘッドは、API呼び出しとは異なる種類の依存関係だ。ネットワークが使えないときでも動作し続け、そのコストは読み取るテキストの量に比例して増えない。それこそが、対価を払う価値のある性質だ。この記事の残りはすべて、忠実性、メモリ、保守性の面でそれにどれだけの代償を払うかについてである。

誰が実行すべきで、誰が待つべきか

以下の条件に当てはまるなら、Laya-MLXを実行してください。MシリーズのMacを使っていて、意思決定の形式が限定されている——名前付き選択肢からの選択、ルーブリックによるスコア、はい/いいえのゲート——うえで、ファインチューニングに使えるラベルがあるか、自分でキャリブレーション温度を適合させる用意がある場合です。インストールはコマンド1つ、必要なメモリの下限は1ギガバイト未満で、忠実性に関する作業は完了し公開されています。

待ってください。アップストリームのサポート保証が必要な場合、長期間稼働するサイドカーを動かしていて、メモリ増加の問題をオープンな issue ではなくリリースで決着させたい場合、または質問がオープンエンドである場合。「次に何をすべきか」に答える非自己回帰型エンコーダーは、同じことをする LLM の小型版ではない。それは別の道具であり、質問がすでにそれ向けに形作られているときにしか、よく読み取れない。