xLSTM 採用判断: 再帰型アーキテクチャと xLSTM Large 7B の実装事情

xLSTM が埋めようとしている溝

元の LSTM には、長い系列を扱うときにゲートの飽和で情報が失われやすいという制約があった。README は、指数ゲーティングと適切な正規化・安定化手法、そして新しい行列メモリによって「元の LSTM の限界を克服する」と説明している。対象読者は 2 種類に分かれる。Transformer や状態空間モデルと比較したときに、言語モデリングで競争力のある再帰型の選択肢を試したい研究者と、xLSTM Large 7B という学習済みの重みを推論で使いたい実務者である。この 2 つは同じリポジトリにいながら、必要な依存もコードパスも別物なので、最初にどちらなのかを決めておかないと後で構成を組み直すことになる。

NeurIPS 版と xLSTM Large で分かれる 2 つのコードパス

リポジトリの構成は素直ではない。README によれば、NeurIPS 論文のモデルは xLSTMBlockStack と xLSTMLMModel という形で提供され、非言語用途や他アーキテクチャへの組み込みには前者、言語モデリングやトークン列を扱う用途には後者を使う。一方で 7B モデル向けに最適化されたアーキテクチャは xlstm/xlstm_large に置かれ、xlstm/xlstm_large/model.py という単一ファイル実装になっている。README はこの実装について、mlstm_kernels 以外に NeurIPS 版の実装への依存がないと明記している。つまり 7B を使うだけなら、古いブロック実装の設計を理解する必要はない。逆に、xLSTM のブロックを自分のモデルに差し込みたいだけなら、xlstm_large 側の設定項目を追う必要はない。同じパッケージ名で配布されているため、どちらの API を触っているのか意識しないと混乱しやすい。

指数ゲーティングと行列メモリ、そしてカーネル選択という実装上の分岐

アーキテクチャの中心は指数ゲーティングと行列メモリだが、利用者にとってより実務的なのはカーネルの選択である。xLSTMLargeConfig には chunkwise_kernel、sequence_kernel、step_kernel の 3 つがあり、README のサンプルではそれぞれ chunkwise--triton_xl_chunk、native_sequence__triton、triton を指定している。コメントには xl_chunk が TFLA カーネルに相当すると書かれている。この 3 つは独立して切り替えられ、Triton を外す場合は chunkwise--native_autograd、native_sequence__native、native の組み合わせになる。つまり同じモデル定義のまま、実行環境に応じて計算経路だけを差し替える設計になっている。推論向けには mode="inference" と return_last_states=True を設定し、入力は torch.randint(0, 2048, (3, 256)) のような形状で渡す例が示されている。

導入手順と、環境変数でしか解決できない部分

最小構成は conda 環境を environment_pt240cu124.yaml から作り、pip install xlstm で入れる流れである。リポジトリから入れる場合は git clone の後に pip install -e . を実行する。xLSTM Large 7B を使う場合はこれに加えて pip install mlstm_kernels が必要で、README はこのパッケージを別リポジトリとして参照している。sLSTM の CUDA カーネルを使う場合は Compute Capability 8.0 以上が条件で、コンパイルが通らない場合の回避策として export TORCH_CUDA_ARCH_LIST="8.0;8.6;9.0" が示されている。CUDA ライブラリの探索パスを変えたい場合は XLSTM_EXTRA_INCLUDE_PATHS を設定する。シェルでも Python 内でも指定できる点は、ビルドを CI に組み込むときに効いてくる。

Triton 前提が崩れる環境と、ネイティブ経路の代償

README は、主に NVIDIA GPU で検証しており Triton カーネルは AMD GPU でも動くはずだと述べている。ただし「はずだ」であり、動作確認の範囲は明示されていない。Apple Metal のような他のプラットフォームでは、当面はネイティブ PyTorch 実装を使うことが推奨されている。この場合 chunkwise_kernel を chunkwise--native_autograd に、sequence_kernel を native_sequence__native に、step_kernel を native に変える。ここで注意すべきは、ネイティブ経路が単なる互換モードではなく、Triton カーネルによる高速化を放棄する選択だという点である。README はネイティブ実装の速度について何も数値を出していないため、Triton 版と比べてどの程度落ちるかはこの資料からは判断できない。導入検討時には、対象ハードウェアでどちらの経路になるかを先に確定させたほうがよい。

Apache-2.0 のコードと、そうではない重み

リポジトリ本体は Apache-2.0 で、これはコードの利用条件である。しかし xLSTM 7B の重みは Hugging Face の NX-AI/xLSTM-7b で配布されており、README のバッジが示すライセンスは nxai_community であって Apache-2.0 ではない。コードを自前のパイプラインに組み込む場合と、学習済み重みをプロダクトで使う場合とで、確認すべき条件が別になる。ここでは法的な解釈は示さないが、少なくとも同一ライセンスだと仮定して進めるのは避けたい。sLSTM のカーネルについては、より高速な代替として FlashRNN ライブラリが別途案内されている。

Transformer や状態空間モデルと何が違うのか

README は xLSTM を Transformer や状態空間モデルと比較し、言語モデリングで有望な性能を示すと述べるにとどまり、具体的な比較数値を本文中には置いていない。判断材料として使えるのはむしろアーキテクチャの性質のほうである。Transformer が系列長に対して注意機構の計算量を持つ のに対し、xLSTM は再帰型であり、7B モデルの論文タイトルも「Fast and Efficient Inference」を掲げている。一方で再帰型であることは、学習時の並列性や既存の Transformer 向けツールチェーンとの相性という面で制約になる。既存の推論基盤やファインチューニング手法をそのまま流用したいなら、Transformer 系のモデルを選ぶ理由は依然として強い。xLSTM を選ぶ動機は、推論効率を優先したい場合か、再帰型アーキテクチャ自体を研究対象にしている場合に限られる。

メンテナンス状況と、次に確認すべきこと

リポジトリはアーカイブされておらず、v2.0.6 が 2026-09-07 に、v2.0.4 が 2025-05-28 に公開されている。約 1 年 3 か月空いての更新であり、活発とは言い切れないが停止もしていない。依存関係の面では、PyTorch は 1.8 以上で検証済みとされ、環境ファイル environment_pt240cu124.yaml が実質的な推奨構成になっている。CUDA と PyTorch のバージョン一致が前提とされているため、既存環境に後から足すより、専用の conda 環境を切るほうが衝突は少ない。導入前に見るべきは、sLSTM カーネルを使うなら GPU の Compute Capability、xLSTM Large を使うなら mlstm_kernels の導入可否、そして 7B の重みを使うなら nxai_community ライセンスの条件である。

編集部の結論

xLSTM Large 7B を推論で動かしたい、あるいは再帰型アーキテクチャを自前の系列モデルに組み込みたいチームに向く。NVIDIA GPU を持たず Apple Silicon で動かしたい場合は、公式実装ではなくネイティブ PyTorch 経路かコミュニティ製の xLSTM-metal を検討する段階であり、このリポジトリの Triton カーネル前提の構成をそのまま持ち込むべきではない。導入前に確認すべきは 3 点で、第一に sLSTM の CUDA カーネルを使うなら Compute Capability が 8.0 以上か、第二に xLSTM Large を使うなら mlstm_kernels が別パッケージとして必要になる点、第三に 7B の重みが Apache-2.0 ではなく nxai_community ライセンスで配布されている点である。

公式情報源

1. License: Apache-2.0
2. NX-AI/xlstm on GitHub
3. Project website
4. README
5. Releases