RWKV の紹介: リニアトランスフォーマーの台頭と代替手段の模索

RWKV ポッドキャストに関する私の考えの一部を要約します: https://www. php.cn/link/9bde76f262285bb1eaeb7b40c758b53e

理由代替手段の重要性はそれほど重要ですか？

2023 年の人工知能革命に伴い、Transformer アーキテクチャは現在最高潮に達しています。ただし、成功した Transformer アーキテクチャの採用を急ぐあまり、そこから学べる代替案を見落としがちです。

#エンジニアとして、私たちは画一的なアプローチを採用し、すべての問題に対して同じソリューションを使用すべきではありません。私たちはあらゆる状況でメリットとデメリットを比較検討する必要があります。そうしないと、代替手段があることを知らずに「満足」を感じながら特定のプラットフォームの制限内に閉じ込められてしまうと、一夜にして開発が解放前に戻ってしまう可能性があります

この問題は人工知能の分野に特有のものではなく、古代から現在まで繰り返されてきた歴史的なパターンです。

# 。この物語では、Oracle、MySQL、SQL Server などのさまざまなデータベース管理システムが市場シェアと技術的優位性を求めて激しく競争します。これらの競争は、パフォーマンスや機能に反映されるだけでなく、ビジネス戦略、マーケティング、ユーザー満足度などの多くの側面も関係します。これらのデータベース管理システムは、より多くのユーザーや企業が製品を選択するよう、新しい機能や改善を継続的に導入しています。 SQL 戦争の歴史の 1 ページ。データベース管理システム業界の発展と変革を目撃し、私たちに貴重な経験と教訓を提供してくれました。 #最近のソフトウェア開発における注目すべき例は、SQL サーバーが物理的に制約され始めたときに現れた NoSQL トレンドです。世界中のスタートアップ企業が、その規模には遠く及ばないにもかかわらず、「規模」を理由に NoSQL に注目しています

#SQL と NoSQL は 2 つの異なるデータベース テクノロジです。 SQLはStructured Query Languageの略で、主に構造化データを処理するために使用されます。 NoSQL は、非構造化データまたは半構造化データの処理に適した非リレーショナル データベースを指します。 SQL が NoSQL よりも優れている、またはその逆であると考える人もいますが、実際には、それぞれのテクノロジーに独自の長所、短所、およびユースケースがあることを意味しているだけです。場合によっては、複雑なリレーショナル データの処理には SQL の方が適している一方、大規模な非構造化データの処理には NoSQL の方が適している場合があります。 ただし、これは 1 つのテクノロジーのみを選択できるという意味ではありません。実際、多くのアプリケーションやシステムは実際に SQL と NoSQL のハイブリッド ソリューションを使用しています。特定のニーズとデータの種類に応じて、問題を解決するために最も適切なテクノロジーを選択できます。 したがって、各テクノロジーの特性と適用可能なシナリオを理解し、特定の状況に基づいて情報に基づいた選択を行うことが重要です。 SQL と NoSQL には、どちらも独自の学習ポイントと推奨される使用例があり、同様のテクノロジーから学び、相互影響を受けることができます

現在トランスフォーマー

アーキテクチャの最大の問題点は何ですか?
• 通常、これには計算、コンテキスト サイズ、データセット、アライメントが含まれます。この説明では、計算とコンテキストの長さに焦点を当てます。
• O(使用/生成されたトークンごとに N^ 2) であるため、二次計算コスト増加によって引き起こされます。これにより、コンテキスト サイズが 100,000 を超えると非常に高価になり、推論とトレーニングに影響します。

#現在の GPU 不足がこの問題をさらに悪化させています。

コンテキスト サイズによりアテンション メカニズムが制限され、「インテリジェント エージェント」の使用例 (smol-dev など) が大幅に制限され、問題の解決が強制されます。コンテキストが大きくなると、必要な回避策は少なくなります。

それでは、この問題をどのように解決すればよいでしょうか?

RWKV の紹介: 線形 Tトランスフォーマー

• コンテキスト サイズに依存しない線形の計算コスト。
• # CPU (特に ARM) では、要件が低い RNN モードで妥当なトークン/秒出力を許可します。
• #RNN には、コンテキスト サイズの厳密な制限はありません。ドキュメント内の制限はガイドラインであり、微調整することができます。

AI モデルを 100k コンテキスト以上のサイズに拡張し続けると、二次関数の計算コストは​​指数関数的に増加し始めます。

ただし、線形トランスフォーマーはリカレント ニューラル ネットワーク アーキテクチャを放棄せず、そのボトルネックを解決せず、置き換えを余儀なくされました。

#ただし、再設計された RNN は Transformer のスケーラブルな教訓を学び、RNN が Transformer と同様に動作できるようにし、これらのボトルネックを解消します。

トレーニング速度の点では、トランスフォーマーを使用するとトランスフォーマーが再び使用可能になり、トレーニングを 1 つ以上にスケールしながら、O(N) コストで効率的に実行できるようになります。同様のパフォーマンス レベルを維持しながら、10 億のパラメータを実現します。

#グラフ: トークンあたりの線形トランスフォーマーの計算コストとトランスフォーマーの指数関数的増加の関係

二乗比を線形スケーリングに適用すると、トークン数 2,000 で 10 倍以上の増加が得られ、トークン長 100,000 で 100 倍以上の増加が得られます。

RWKV は 14B パラメータで、GPT NeoX や他の同様のデータセット (Pile など) に匹敵する最大のオープンソース線形 Transformer です。

RWKV モデルのパフォーマンスは、類似の既存の変圧器モデルと同等です。サイズ、さまざまなベンチマークは

# を示しますが、より簡単に言うと、これは何を意味するのでしょうか? ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃アドバンテージ＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃＃ ##コンテキスト サイズが大きい場合、推論/トレーニングは Transformer よりも 10 倍以上安価です。

RNN モードでは、限られたハードウェアでは実行速度が非常に遅くなる可能性があります。

# 同じデータセット上の Transformer と同様のパフォーマンス

• RNN には技術的なコンテキスト サイズの制限はありません(コンテキストは無制限!)
• #欠点
• スライディング ウィンドウの問題、特定の点を超えると損失のあるメモリ

トランスの最適化と導入ほど優れていない

• つまりRWKV はまだ LLaMA2 の 60B パラメータ スケールに達していませんが、適切なサポートとリソースがあれば、特にモデルが小型で効率的な傾向にあるため、より低コストで幅広い環境で実現できる可能性があります
• ユースケースが効率性にとって重要である場合は、これを検討してください。ただし、これは最終的な解決策ではありません。鍵は健康的な代替案にあります
• #他の方法を学ぶことを検討する必要があります。代替案とその利点

拡散モデル: テキストでのトレーニングには時間がかかりますが、マルチエポックトレーニングに対しては非常に回復力があります。その理由を解明することは、トークン危機を緩和するのに役立つ可能性があります。

敵対的生成ネットワーク/エージェント: テキストに基づいている場合でも、データセットなしで目的のトレーニング セットを特定のターゲットにトレーニングする手法を使用できます。モデル。

##元のタイトル: RWKV の紹介: リニアトランスの台頭と代替手段の探索

picocreator

##//m.sbmmt.com/link/b433da1b32b5ca96c0ba7fcb9edba97d

以上がRWKV の紹介: リニアトランスフォーマーの台頭と代替手段の模索の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。