Perplexity、Apple Silicon向け推論エンジン「Lily」をオープンソース化

Perplexity は、自社の「Hybrid Compute」の基盤となるローカル推論エンジン「Lily」をオープンソース化しました。これは単一プロセスで動作するランタイムです。Rust レイヤーがチェックポイントを読み込み生成ループを駆動し、OpenAI 互換のチャット完了 API を通じてトークンをストリーミング出力します。実際のモデル演算は手書きされた Metal カーネルによって実行されます。推論パスには PyTorch も MLX も含まれていません。

Lily はあえて特定の用途に特化しています。対象となるのは、Apple Silicon 上で動作する Qwen3.6-35B-A3B という単一のモデルのみです。この「狭さ」こそが、高いパフォーマンスを実現する理由となっています。

実用性は担保されていますか？はい、可能です。pplx-garden リポジトリにはスタンドアロンのデモが公開されており、最小限の OpenAI 互換 HTTP API を介して貪欲なテキスト生成を行う Rust と Metal による推論サーバーとして動作します。4 ビット量子化されたチェックポイントのサイズは 19.4 GB です。したがって、実用的に動かすには統一メモリが 32 GB 以上の Apple Silicon Mac が最低限必要となります。Perplexity が提供する製品「Hybrid Compute」では、macOS 15 以上を要件とし、推奨環境として 32 GB のメモリを挙げています（24 GB でも動作しますが、ベストな結果を得るには 32 GB を推奨します）。

なぜここまで特化しているのでしょうか？

Mac デフォルトのスタックは MLX と MLX-LM です。これらはすでに Qwen の実装を搭載しており、グループ化されたエキスパート処理や融合された再帰 Metal カーネル、GQA（Grouped Query Attention）に対応したアテンション機構を備えています。しかし、これらの操作は異なるアーキテクチャ間でも再利用可能であることが最優先されます。

一方、Lily はその制約を捨て去り、モデル構造、実行計画、カーネル選択のすべてを単一のランタイム内に統合しました。

主なワークロード形状は以下の 3 つです

Qwen3.6-35B-A3B は 350 億のパラメータを保持し、トークンごとに約 30 億が活性化します。ルーターは 256 のエキスパートを評価して 8 つを選択し、すべてのトークンを処理する共有エキスパートも併用されます。また、グループ化クエリアテンション（16 クエリヘッド、2 KV ヘッド）を用いた 10 層のフルアテンション層と、30 層の Gated DeltaNet を組み合わせることで、3 つのパターンが生まれます。それは「不均等なエキスパートグループ」「成長する KV キャッシュに対するアテンション」「固定サイズの再帰処理」です。

Prefill: 重みのパック状態を維持し、ルーティングは GPU で実行

チェックポイントでは、グループ単位のアフィン量子化（4 ビット）が採用されています。64 個の重みごとに bfloat16 のスケールとバイアスが共有され、約 70 GB の bfloat16 重みが 19.4 GB に圧縮されます。Metal 4 のテンソル演算は bfloat16 を消費するため、まず重みを再構築する必要があります。Lily はこれをグループ化 GEMM（行列積）の内部でタイル単位で行い、結果をスレッドグループメモリに保持して FP32 で累積します。これにより、展開された配列がユニファイドメモリに到達することはありません。Perplexity のアブレーション実験では、この融合処理によって 512 トークンのプロンプトにおけるエンドツーエンドの Prefill 性能が 77.4% 向上しました。

ルーティングヒストグラム、プレフィックススキャン、散乱（scatter）、ブロックマップを単一の GPU コマンドバッファ内に保持することで、各 MoE レイヤー内の CPU 同期を排除し、512 トークンで 89% の性能向上を実現しました。16 行タイルから 32 行タイルへ変更し、4 つの simdgroup を使用したことで、2K トークンで 13.2% の向上が得られました。また、レジスタに保持された Gated DeltaNet スキャンにより 5.6% の向上がありました。エキスパート GEMM は Prefill 時間の約 90% を占めます。長いプロンプトはバウンド付きのチャンクで実行されるため、一時的な活性化が重みやキャッシュとメモリを競合させることはありません。

Decode: トークンあたりの転送バイト数を最小化

バッチサイズ 1 のデコード処理では重みの再利用がほぼないため、帯域幅が性能の上限を決定します。ある記録されたステップでは 795 個のカーネルが実行され、555 段階の逐次処理が行われていましたが、Lily は並列的な Metal パスで実際の依存関係を記録し、独立したカーネル同士をオーバーラップさせることで効率化を図っています。選択されたトークンは、次のステップの GPU 内に常駐する入力スロットに直接書き込まれるため、トークンごとの CPU との往復通信が不要になります。また、4 つのカーネルチェーンを融合させることで中間データをレジスタ内に保持し続けています。

共集約キャッシュ読み込みにより、キーの帯域幅は 33.8 GB/s から 47.9 GB/s に、バリューの帯域幅は 42.0 GB/s から 61.8 GB/s に向上しました。GQA（グループ化クエリアテンション）のパッキングでは、4 つのクエリヘッドを 1 つのスレッドグループで共有し、各 KV ロウを一度だけ読み込むことで、32K のコンテキスト長においてデコード性能が 23.8% 向上しました。また、32K 以上で固定ブロックのアテンションレイアウトを採用した結果、32K で 7.7%、64K で 27.4%、128K で 40.2% のデコード性能の改善が実現されています。

結果

40 コア、メモリ 128 GB の M5 Max システム上でバッチサイズ 1 の条件下で、MLX-LM の最速ダイレクト生成パスと比較して、Lily は 256 トークンから 128K トークンまでの 10 種類の長さにおいて、同一の 4 ビットチェックポイントを読み込みました。その結果、プリフィル処理では平均 4,156 トークン/秒を達成し、MLX-LM の 3,388 トークン/秒（1.23 倍）を上回りました。デコード処理でも 170.0 トークン/秒を記録し、同様の比較対象である 126.4 トークン/秒に対して 1.35 倍の性能を示しました。

さらに、プロンプト長とコンテキスト長の両方を 4K に設定したテストでは、Lily はそれぞれ 5,749.9 トークン/秒と 186.6 トークン/秒を達成し、比較対象である 4,737.5 トークン/秒と 140.9 トークン/秒を大きく上回りました。記録されたすべてのポイントで Lily の方が高速であり、プリフィルでは 1.12〜1.42 倍、デコードでは 1.31〜1.37 倍の性能差となりました。

教師ありチェック（teacher-forced check）を 192 位置で行った結果、Lily のパープレキシティは 0.04% 高いものの、上位ランクのトークンが一致する割合は 96.35% で、精度面でも十分な性能を保証しています。

主なポイント

Lily は、Apple Silicon 上で Qwen3.6-35B-A3B を推論するための Rust + Metal エンジンであり、処理パスに PyTorch や MLX を一切使用していません。

M5 Max（40 コア、128 GB）において、MLX-LM のプリフィル処理で平均 1.23 倍、デコード処理で平均 1.35 倍の性能向上を達成しました。

プリフィル処理での最大の改善点は、GPU に残存する専門家ルーティングによる 89% の高速化と、グループ化された GEMM（行列積演算）に量子化解除を統合したことで得られた 77.4% の高速化です。

デコード処理での最大の改善点は、32K コンテキスト長における GQA パッキングによる 23.8% の向上と、128K コンテキスト長における固定ブロックアテンションによる 40.2% の向上です。

技術的な詳細はこちら、GitHub リポジトリはこちらでご確認ください。Twitter や 15 万人以上のメンバーが参加する ML サブレディット、ニュースレターへの登録もぜひご検討ください。Telegram ユーザーの方にも、今なら Telegram でコミュニティに参加していただけるようになりました。