今回の論文
今回取り上げるのは、Michael Poli、Stefano Massaroli、Eric Nguyen、Daniel Y. Fu、Tri Dao、Stephen Baccus、Yoshua Bengio、Stefano Ermon、Christopher Ré による論文「Hyena Hierarchy: Towards Larger Convolutional Language Models」です。2023年2月21日に arXiv で公開された研究で、公開元は arXiv、研究分野は長文シーケンスモデリング、言語モデルアーキテクチャ、subquadratic sequence operator です。URL は https://arxiv.org/abs/2302.10866、DOI は https://doi.org/10.48550/arXiv.2302.10866 です。
この論文を選んだ理由は、Transformer をどう高速化するかではなく、そもそも attention 以外で長文を扱える中核演算を作れないか、という視点で設計されているからです。長文LLM、ストリーミング処理、オンデバイス推論、巨大コンテキストの低コスト化を考えるうえで、かなり応用の発想を広げてくれます。
どんな技術か
Hyena Hierarchy は、self-attention を使わずに、長い畳み込みと入力依存のゲーティングを繰り返し組み合わせて長距離依存を扱う技術です。ひとことで言えば、Transformer の attention を別の subquadratic 演算へ置き換えようとするモデル構造です。
通常の attention は、トークン同士の関係を柔軟に表現できる一方で、系列長が伸びると計算量とメモリ使用量が急増します。Hyena はそこに対して、全トークン対の相互作用を直接計算する代わりに、長い範囲を見られる畳み込みと、入力内容に応じて出力を切り替えるゲートを組み合わせます。
重要なのは、単なる軽量近似ではなく、attention に近い表現力を持ちながら、より長い系列を現実的なコストで扱えることを狙っている点です。論文では、長文の recall や language modeling で Transformer に近い性能を出しつつ、長い系列ではより高速に動くことを示しています。
課題
この技術が解決しようとしているのは、長い系列を扱うときに attention の二乗コストが重すぎるという課題です。
何が難しいのかというと、言語モデルでは「遠く離れた位置の情報も見たい」のに、標準的な self-attention は系列長 L に対して概ね O(L^2) の計算が必要になるからです。コンテキストを 2倍、4倍と伸ばしていくと、推論時間だけでなく学習時のメモリ圧迫も急激に大きくなります。
既存の方法にも限界があります。低ランク近似や疎attention、線形attention、state space model など多くの代替案がありますが、論文が指摘するのは、こうした方法の多くが長さは伸ばせても、最終的な表現力や in-context learning の面で dense attention に届きにくいことです。そのため、実際には一部に通常attentionを残した hybrid 構成が必要になりがちでした。
なぜこの課題を解く必要があるのかというと、AIシステムでは長文入力を扱いたい場面が増え続けているからです。たとえば、巨大なコードベース読解、長いログ解析、複数章にまたがるドキュメント要約、長時間会話エージェントなどでは、より広いコンテキストがそのまま性能差になります。もし attention に依存せず長文を扱えるなら、学習コストや推論コストの設計余地が大きく広がります。
用語解説
- Self-Attention
- 各トークンが他のトークンをどれだけ参照するかを動的に決める演算です。Hyena はこれを直接使わずに近い役割を別の演算で実現しようとするので、比較対象として理解しておくと狙いが見えやすくなります。
- Long Convolution
- ごく短い局所畳み込みではなく、系列全体に近い長さまで届く畳み込みです。Hyena の中心要素で、遠い位置の情報を低コストで混ぜる役割を持ちます。
- Gating
- 入力に応じて、どの情報をどれだけ通すかを要素ごとに調整する仕組みです。Hyena では長畳み込みの出力を固定的に使うのではなく、入力依存で制御することで表現力を高めています。
- Implicit Parameterization
- フィルタ係数をそのまま全長分持つのではなく、位置を入力に取る小さな関数でフィルタを生成する考え方です。Hyena が長いフィルタを扱いながら、パラメータ数を系列長に比例させずに済む理由のひとつです。
- Associative Recall
- 長い系列の中から対応する情報を引き当てられるかを見る合成タスクです。Hyena 論文では、この種のタスクを attention 代替演算の設計指針として使っており、単なる perplexity だけでは見えにくい能力差を測っています。
技術の仕組み
Hyena の基本設計は、長い畳み込みで広い文脈を混ぜ、その出力を入力依存のゲートで何段か再帰的に組み合わせる というものです。ポイントは、畳み込みだけでも、ゲートだけでもなく、その両方を反復して使うところにあります。
基本アイデア
論文では attention の強みを、入力依存で振る舞いが変わること、系列長に対してパラメータ数が増えないこと、任意距離の依存を扱えること、の3点として整理しています。Hyena はこの3つをできるだけ保ちながら、より軽い演算で置き換えようとしています。
そのために使うのが、長畳み込みと multiplicative gating です。長畳み込みだけだと入力に対して固定的な線形演算になりやすく、attention のような入力依存性が弱くなります。そこで、入力から作った複数の投影ベクトルで畳み込み結果を掛け合わせ、演算自体をデータ依存にしています。
Hyena 演算子の形
Hyena では、入力系列から v, x1, ..., xN のような複数の射影を作り、初期状態 z1 = v から始めます。その後、各段階で zn に長畳み込みをかけ、その結果に xn を要素積で掛けて次の状態 z(n+1) を作ります。これを数段繰り返した最後の出力が Hyena ブロックの出力になります。
式だけ見ると単純ですが、意味としてはかなり重要です。畳み込みが「遠い場所から情報を持ってくる」役割を持ち、ゲートが「その情報をこの入力ではどう使うか」を制御しています。論文ではこの再帰の深さを order と呼んでおり、Hyena-2 や Hyena-3 のように段数で表現力を調整します。
フィルタの作り方
長い系列に対して通常の畳み込みフィルタをそのまま持つと、フィルタ長に比例してパラメータが増えます。Hyena はここを implicit parameterization で解決します。具体的には、位置情報を入力にした小さな MLP から長畳み込みフィルタを生成します。
この設計により、系列長が長くなってもパラメータ数はほぼ増えません。しかも、単なる固定係数ではなく、連続的な関数としてフィルタを表せるため、長距離のパターンを比較的柔軟に表現できます。論文では、FFN ベースの implicit filter が、S4 系や周波数領域の明示フィルタより長い系列で強かったことも示しています。
計算方法
長畳み込みはそのまま実装すると重いですが、Hyena は FFT ベースの畳み込みで効率化しています。論文では、Hyena の計算量を order N、系列長 L、幅 D に対して O(NDL(log L + D)) と整理しています。attention の O(L^2) より系列長への伸び方が緩やかなので、長文になるほど有利になりやすい設計です。
ここで重要なのは、理論計算量が低いだけでなく、長い系列で実際に速度差が出ることです。論文でも、短い系列では optimized attention の実装効率に勝てない場合がある一方、系列長が伸びると Hyena の優位が大きくなると報告しています。
なぜ attention っぽい表現力を持てるのか
Hyena は attention 行列そのものを作りませんが、論文ではデータ依存の対角行列と Toeplitz 行列の積として見られることを示しています。直感的には、固定の長畳み込みだけではなく、入力で変わるゲートを挟むことで、入力ごとに異なる情報伝搬パターンを作れるわけです。
このため、単なる畳み込みモデルより in-context learning 的な振る舞いに近づけます。実際、論文では associative recall や induction 系タスクで、従来の attention-free 系より大きく強い結果を出しています。
モデル全体での使い方
論文では Hyena を attention の drop-in replacement として扱っています。つまり、Transformer ブロックの attention 部分を Hyena 演算子に置き換え、残りの埋め込み、FFN、残差接続などは比較的標準的な構成を維持します。
これは実務上も重要です。完全に新しいモデルファミリというより、既存の Transformer 的な設計資産を残しつつ、中核演算だけを差し替える発想だからです。長文性能や計算コストが課題のとき、アーキテクチャ探索の現実的な選択肢として考えやすくなります。
実験と結果
論文では、Hyena を単なる理論提案で終わらせず、合成タスク、言語モデリング、長系列速度比較、画像分類まで広く検証しています。特に重要なのは、長文での能力差を先に synthetic task で見てから、大規模言語モデリングへつなげている点です。
何を検証したのか
主に検証しているのは次の4点です。1つ目は、長い系列で in-context 的な対応関係を本当に扱えるかです。2つ目は、WikiText103 や The Pile のような実データで Transformer に近い perplexity を出せるかです。3つ目は、系列長が伸びたときに attention より高速になるかです。4つ目は、言語以外でも使える一般的な演算かです。
どんなデータセットや評価指標を使ったのか
言語モデリングでは WikiText103 と The Pile を使い、主に perplexity で比較しています。長文能力の設計確認には associative recall などの synthetic task を使い、正答率で比較しています。速度面では attention と FlashAttention との runtime 比較を行っています。さらに Vision Transformer の attention を Hyena に差し替えた ImageNet-1k の top-1 accuracy も報告しています。
長文の associative recall では大差が出た
長系列の associative recall では、Hyena はかなり印象的です。語彙サイズ 30、系列長 30k では Hyena が 100.0%、FlashTransformer が 32.4%、GSS が 5.3%、H3 が 8.4% でした。64k でも Hyena は 100.0% を維持し、131k でも 97.2% を出しています。
この結果から言えるのは、Hyena が単に軽いだけではなく、長距離の対応付けを実際に保てていることです。論文では、ここでの順位が後の language modeling の順位と相関しているとも述べており、長文能力を先に小さな実験で見極める設計姿勢自体も参考になります。
言語モデリングでは Transformer 級に近づいた
WikiText103 の 125M パラメータ帯では、Transformer が perplexity 18.6、Hyena-3 が 18.6、Hyena-3-slim が 18.5 でした。少なくともこの規模では、attention なしでも同等水準に届いています。
The Pile でも、355M パラメータ帯で GPT が 11.4 / 9.8 / 9.1、Hyena-2 が 11.3 / 9.8 / 9.2 とかなり近い値でした。しかも、15B token 時点の FLOPs は GPT が 4.77e19、Hyena-2 が 3.93e19 で、論文では同等 perplexity をより小さい学習計算量で達成したと整理しています。
ここで重要なのは、「少し悪いけれど軽い」ではなく、「かなり近い性能で、長い系列では有利」という位置まで来ている点です。attention-free モデルを実用品質へ近づけた一歩として見る価値があります。
速度は長い系列ほど効く
速度比較では、Hyena は系列長 8K で高最適化 attention の約2倍、64K で約100倍高速だったと報告されています。交差点としては、通常attentionとの比較では長さ 2048 あたり、FlashAttention との比較では 4096 から 8192 の間で Hyena が有利になり始めるとされています。
これは実務的にかなり大事です。短いプロンプト中心のチャット用途では、理論的に良くても実装効率で勝てない場合があります。一方、コード解析、長報告書処理、長会話履歴など、最初から長い系列を前提にするプロダクトでは、Hyena 的な演算の価値が上がります。
画像分類でも drop-in で成立した
ImageNet-1k では、ViT の attention を Hyena に差し替えた Hyena-ViT が、16x16 パッチで 78.5%、8x8 パッチで 79.8% を出し、ViT の 78.5% と 80.0% にかなり近い精度でした。
この結果から、Hyena は言語専用のトリックではなく、系列演算としてある程度汎用性があると分かります。特に、画像でもパッチ数が増えるほど系列長が伸びるので、長い系列に強い演算としての価値があります。
何に使える？
Hyena の使い道は、単に「Transformer の代替候補」だけではありません。長文や長系列を扱うAIアプリで、計算量のボトルネックを構造から崩したい場面に向いています。
長文LLMやコード読解
巨大なコードベース、長い仕様書、ログ、監査記録のように、最初から入力が長いタスクでは Hyena の発想が役立ちます。全文を dense attention で見るより、長距離依存を保ちつつコストを抑えやすいからです。特にコード検索やリポジトリ要約のような用途では、長文性能が直接UXにつながります。
ストリーミング処理やリアルタイム解析
音声、センサーログ、イベント列のような連続入力でも応用余地があります。Hyena は長い系列を扱う演算子として設計されているため、リアルタイムに伸び続けるデータを効率よく処理したいケースと相性があります。論文は言語中心ですが、系列処理という意味では汎用です。
長いコンテキストを前提にしたエージェント
長時間タスクを走らせるエージェントでは、行動履歴、ツール出力、制約条件が積み上がっていきます。現時点の商用実装ではそのまま Hyena に置き換えるのは難しいですが、長い履歴前提の内部モデルや専用サブモデルを設計する発想としては有力です。ここは将来的な応用の推測を含みますが、attention だけに依存しない長期記憶処理の候補として見ておく価値があります。
画像やマルチモーダルの長系列化
画像を細かいパッチで処理したり、動画フレーム列を長く扱ったりすると、系列長はすぐ大きくなります。Hyena は長い系列でも比較的扱いやすいので、マルチモーダル基盤モデルの一部演算としても検討余地があります。論文でも ViT 置換が成立しているため、応用の方向性として自然です。
開発や事業へのヒント
この論文から得られるヒントは、長文AIの改善を「もっと大きいGPUを使う」だけで考えないことです。中核演算を見直すと、プロダクト設計の選択肢そのものが広がります。
長文前提サービスではアーキテクチャ差が効く
短文チャット中心の製品ではモデル差が見えにくくても、長文要約、社内検索、コード理解、調査自動化では演算子の違いがコストと速度に直結します。長い系列が前提のサービスを作るなら、attention 最適化だけでなく attention-free 系も評価候補に入れる価値があります。
小規模プロダクトでも発想は取り込める
論文の完全再現は簡単ではありませんが、考え方は小規模でも使えます。たとえば、遠距離依存は圧縮的に混ぜ、局所の細部だけ別処理する、入力依存のゲーティングで固定演算の弱点を補う、といった設計原則です。これは独自モデルだけでなく、前処理や軽量サブモデル設計にも応用できます。
推論コストだけでなく学習コストも差別化要素になる
Hyena は推論高速化の話に見えますが、論文では学習 FLOPs でも利点を示しています。今後、独自基盤モデルやドメイン特化モデルを作る事業では、運用コストより先に学習コストがボトルネックになることも多いです。そこを architecture choice で削れるなら、事業上の優位にもつながります。
今後見るべき方向性
今後注目したいのは、attention を完全に捨てるかどうかではなく、どの層・どのモダリティ・どの系列長帯で別演算が有利になるかです。Hyena はその代表例で、長系列専用ブロック、ハイブリッド構成、ストリーミング特化設計などへの広がりを考える起点になります。
限界
Hyena にも注意点があります。
まず、短い系列では必ずしも有利ではありません。論文でも、実際の高速化が効いてくるのは長い系列からで、短文では FlashAttention のような高度に最適化された attention 実装が強い場面があります。つまり、どの用途でも置き換えれば速くなるわけではありません。
次に、実装難易度があります。FFT ベースの長畳み込み、implicit filter、ゲーティングの再帰、GPU 上の最適化まで含めると、単純な Transformer より扱いは難しいです。論文でも専用の fused CUDA kernel を使っており、素朴実装では性能が出にくい可能性があります。
また、論文時点では sub-billion 規模が中心で、超大規模LLMでの支配的アーキテクチャになるかまでは断言できません。性能差がさらに大規模化でどう出るか、instruction tuning や tool use、RAG、コード生成でどう効くかは追加検証が必要です。
さらに、attention の強みは単なる長距離依存だけではなく、柔軟なトークン間選択そのものにもあります。Hyena はそこへかなり迫っていますが、すべてのタスクで完全代替になるとは限りません。特に、細かい参照パターンを明示的に切り替える必要が強いタスクでは、hybrid 構成のほうが実務上は扱いやすい可能性があります。
よくある質問
Q. Hyena Hierarchy は Transformer を完全に置き換える技術ですか？
A. 論文の主張は、attention の完全否定ではなく、長い系列では attention なしでもかなり近い性能まで行ける、というものです。用途によっては置き換え候補になりますが、短い系列や既存最適化が強い場面では Transformer 系が依然有利です。
Q. なぜ畳み込みだけで attention に近いことができるのですか？
A. 畳み込みだけでは不十分ですが、Hyena は入力依存ゲーティングを何段か重ねています。これにより、固定の長畳み込みを入力ごとに使い分けるような振る舞いができ、単純な線形畳み込みより表現力が大きく上がります。
Q. 実務で今すぐ使うなら、どんな場面が向いていますか？
A. 長文要約、コードベース解析、長会話履歴処理、長大ログ解析のように、入力長が最初から大きい用途です。短文中心の一般チャットでは、Hyena の優位が見えにくい可能性があります。
Q. Hyena は推論最適化の技術ですか、それともモデル構造の技術ですか？
A. 本質はモデル構造の技術です。推論高速化にもつながりますが、既存モデルの外付け最適化ではなく、attention の代わりに何を中核演算として置くかというアーキテクチャ設計の提案です。
Q. この論文から実装者が一番学ぶべき点は何ですか？
A. 長文性能を改善したいとき、attention をどう近似するかだけでなく、どんな演算の組み合わせなら attention の重要な性質を保てるか、という観点で設計することです。性能と計算量の両方を変えるには、この視点が重要です。
今日の学び
この論文は、長い系列を扱うときに self-attention の計算量が重すぎるという課題を扱いました。そこに対して、長畳み込みと入力依存ゲーティングを再帰的に組み合わせる Hyena という演算子で、attention に近い表現力と subquadratic な計算特性を両立しようとしました。
ここから得られるヒントは、長文AIの改善はコンテキスト長の拡張だけではなく、中核演算の再設計でも進められるということです。長い入力が価値になるプロダクトほど、こうした architecture-level の発想が効いてきます。