Layaをローカルで動かす：WebGPUで実現する低遅延推論と実務への応用

• LayaはJevと同様の選択肢スコアリング特化型LLMで、322M〜421Mパラメータの軽量モデル。
• MLXとWebGPUを活用することで、ローカル環境で1桁msの推論速度を実現し、ブラウザ上でも20fpsでの動作が可能。
• Embedding層の肥大化がボトルネックであり、実務ではモデルの軽量化と推論パイプラインの最適化が導入の鍵となる。

我々エンジニアがLLMを実務に組み込む際、最も頭を悩ませるのが「生成の非決定性」と「レイテンシ」の壁だ。特にAPI経由で自然言語を生成させる場合、ネットワーク遅延とトークン生成の不確実性は、リアルタイム性が求められるアプリケーションにおいて致命的なデッドロックを引き起こす。ここで注目すべきが、Convai Innovationsが公開したオープンウェイトモデル「Laya」である。Layaは、自然言語を生成するのではなく、あらかじめ用意された選択肢に対してスコアを付与することに特化したモデルだ。これは、Jevのコンセプトを継承しており、まさに「LLMを推論エンジンではなく、意思決定のための分類器として使う」という、極めてエンジニアリング的なアプローチである。

Layaのアーキテクチャは、ModernBERT（英語421M）またはmmBERT（多言語322M）のエンコーダーに、2層のDecision Headを乗せたシンプルな構成だ。質問ごとに「[CLS] choice question: … [SEP] [MASK] 選択肢1 [MASK] 選択肢2 … [SEP] 状態 [SEP]」という系列を構築し、[MASK]位置の隠れ状態をスコア化する。双方向エンコーダーであるため、1回のフォワードパスで全選択肢のスコアが算出される。この仕組みは、従来の「生成してパースする」というスパゲッティコードのような実装から我々を解放してくれる。特に、ガードレール用途や、複雑な条件分岐の判定において、この「確率分布を直接叩く」手法は、システムの堅牢性を劇的に向上させるはずだ。

実際にMLXを用いてM5チップ上で動作させたところ、初回ロードを除けば3問の推論が21msで完了するという驚異的な数値を叩き出した。JevのAPI利用時に感じていた「地理的遅延による2fpsの壁」は、ローカル推論によって完全に過去のものとなった。これは、単なるベンチマークの向上ではない。これまで「LLMには重すぎて無理」と諦めていたリアルタイムゲームのAI制御や、ブラウザ上での即時バリデーションが、現実的な選択肢として浮上したことを意味している。

ブラウザ上でLLMを動かすという試みは、これまでWASMの遅さに阻まれ、実用には程遠い「おもちゃ」の域を出なかった。しかし、onnxruntime-webとWebGPUの組み合わせは、その状況を一変させた。LayaをONNXにエクスポートし、ブラウザ上で実行した結果、3問の推論で約50msという結果を得た。これは20fps弱のパフォーマンスであり、ゲームの描画やユーザーインターフェースの即時フィードバックには十分な速度だ。WASM環境での900msという数値と比較すれば、WebGPUがいかにゲームチェンジャーであるかは明白である。

ただし、ここでエンジニアが直面する現実的な課題は「モデルサイズ」と「メモリ消費」だ。fp16量子化モデルでも647MBというサイズは、モバイル環境のブラウザにおいては無視できない。詳細なプロファイリングを行うと、モデルのパラメータのうち約61%がEmbedding層に占められていることが判明した。Transformer本体は251MB程度であるにもかかわらず、語彙数256kのEmbeddingテーブルがメモリを圧迫しているのだ。この構造的なボトルネックを解消しない限り、モバイル端末での快適な動作は難しい。

以下の表は、ブラウザ環境における推論速度の比較である。WebGPUの優位性は明らかだが、fp16における精度の微細なズレ（1.2e-2）をどう許容するかは、アプリケーションの要件次第となる。

我々が明日から取るべき対策は明確だ。Embedding層をグラフから切り離し、JS側でint8のテーブルとして管理するような最適化を検討すべきである。また、Layaの性能は「選択肢の説明文の質」に完全に依存する。これは、モデルを賢くするのではなく、プロンプト（説明文）をエンジニアリングすることで出力を制御するという、LLM時代の新しい開発パラダイムを示唆している。チェスやSnakeゲームのデモが示す通り、ルールベースのプランナーとLLMを組み合わせるハイブリッドな設計こそが、現在のLLMの限界を突破する唯一の道ではないだろうか。

LayaやJevのようなモデルを触っていると、ふと「我々は本当に巨大なLLMを必要としているのか？」という根源的な問いに突き当たる。確かにGPT-4のような巨大モデルは汎用的な知性を持つが、特定のタスク、例えば「この入力が安全か否か」「どの選択肢が最適か」を判定するだけであれば、322MパラメータのBERTベースモデルで十分すぎるほどの精度が出る。むしろ、巨大モデルをAPI経由で叩くコストとレイテンシを考えれば、ローカルで動く軽量モデルを「使い捨てる」ように大量投入するアーキテクチャの方が、ビジネスの現場では遥かに合理的だ。

しかし、ここで注意が必要なのは、モデルの「賢さ」に対する過信だ。チェスのデモにおいて、Layaは合法手を選択する能力はあるが、それはあくまでプランナーが提示した選択肢を読んでいるに過ぎない。Laya自身がチェスの盤面を理解し、戦略を練っているわけではないのだ。この「理解しているフリ」を見抜く力こそが、シニアエンジニアに求められる洞察力である。我々は、LLMを魔法の杖として扱うのではなく、あくまで「確率的な分類器」として、その出力の信頼区間をどう設計し、システム全体でどうハンドリングするかという、泥臭いシステム設計に立ち返る必要がある。

今後、Layaのようなオープンウェイトモデルはさらに増殖するだろう。その時、我々が選ぶべきは「どのモデルが最も賢いか」ではなく、「どのモデルが自分のアプリケーションの制約（メモリ、レイテンシ、精度）に最もフィットするか」という最適化の視点だ。あなたは、自分のプロダクトに組み込まれたLLMが、ブラックボックスとして振る舞うことを許容し続けるのか？それとも、ローカルで制御可能な軽量モデルを徹底的にチューニングし、システムの挙動を完全に掌握する道を選ぶのか？技術の進化は待ってくれない。今すぐ手元のリポジトリをクローンし、自身のユースケースで推論を走らせ、その「確率の揺らぎ」を肌で感じることから始めてほしい。