Foresight Ventures: 理性的に分散型計算ネットワークを考える

著者 ：Ian Xu、Foresight Research

TL;DR

• 現在AI + Cryptoの結合点は主に2つの大きな方向性がある：分散型コンピューティングとZKML；ZKMLについては私の以前の記事を参照してください。この記事では、分散型の分散コンピューティングネットワークについて分析と考察を行います。
• AIの大規模モデルの発展傾向の下で、コンピューティングリソースは次の10年間の戦場であり、未来の人類社会にとって最も重要なものである。これは商業競争にとどまらず、大国間の戦略資源にもなるでしょう。将来的には高性能計算インフラやコンピューティングリソースへの投資が指数関数的に増加するでしょう。
• 分散型の分散コンピューティングネットワークはAIの大規模モデルのトレーニングにおいて最大の需要がありますが、同時に最大の課題と技術的ボトルネックにも直面しています。複雑なデータ同期やネットワーク最適化の問題が含まれます。また、データのプライバシーとセキュリティも重要な制約要因です。既存の技術の中には初歩的な解決策を提供できるものもありますが、大規模な分散トレーニングタスクでは、計算と通信のオーバーヘッドが非常に大きいため、これらの技術は依然として適用できません。
• 分散型の分散コンピューティングネットワークはモデル推論においてより実現可能性があります。未来の増分空間も十分に大きいと予測されます。しかし、通信遅延、データプライバシー、モデルセキュリティなどの課題にも直面しています。モデルのトレーニングと比較して、推論時の計算の複雑性とデータの相互作用は低く、分散環境での実行に適しています。
• TogetherとGensyn.aiという2つのスタートアップの事例を通じて、技術の最適化とインセンティブ層の設計の観点から、分散型の分散コンピューティングネットワーク全体の研究方向と具体的な考え方を説明します。

1. 分散型コンピューティング---大規模モデルのトレーニング

私たちが分散型コンピューティングのトレーニング時の応用について議論する際、一般的には大規模言語モデルのトレーニングに焦点を当てます。主な理由は、小規模モデルのトレーニングはコンピューティングリソースの需要がそれほど大きくないため、データプライバシーや一連のエンジニアリング問題を解決するために分散型で行うのは不合理であり、むしろ中央集権的に解決する方が良いからです。一方、大規模言語モデルはコンピューティングリソースの需要が非常に大きく、現在は爆発的な初期段階にあります。2012年から2018年の間に、AIの計算需要は約4ヶ月ごとに倍増しており、今後5〜8年も引き続き大きな増加が予測されます。

大きな機会がある一方で、問題を明確に認識する必要があります。皆がシーンは大きいと知っていますが、具体的な課題はどこにあるのでしょうか？これらの問題をターゲットにできるのは誰か、盲目的に参入するのではなく、これがこの分野の優れたプロジェクトを判断する核心です。

(NVIDIA NeMo Megatron Framework）

1. 全体のトレーニングプロセス

1750億パラメータを持つ大規模モデルのトレーニングを例にとります。モデルの規模が非常に大きいため、多くのGPUデバイスで並行トレーニングを行う必要があります。中央集権的なデータセンターがあり、100個のGPUがあり、各デバイスは32GBのメモリを持っていると仮定します。

• データ準備：まず、インターネット情報、ニュース、書籍などのさまざまなデータを含む巨大なデータセットが必要です。トレーニング前にこれらのデータを前処理する必要があります。これには、テキストのクリーンアップ、トークン化、語彙の構築などが含まれます。
• データ分割：処理されたデータは、複数のバッチに分割され、複数のGPUで並行処理されます。選択したバッチサイズが512の場合、各バッチには512のテキストシーケンスが含まれます。次に、全データセットを複数のバッチに分割し、バッチキューを形成します。
• デバイス間データ転送：各トレーニングステップが始まると、CPUはバッチキューから1つのバッチを取り出し、そのバッチのデータをPCIeバスを介してGPUに送信します。各テキストシーケンスの平均長さが1024トークンであると仮定すると、各バッチのデータサイズは約512 * 1024 * 4B = 2MB（各トークンが4バイトの単精度浮動小数点数で表されると仮定）です。このデータ転送プロセスは通常数ミリ秒しかかかりません。
• 並行トレーニング：各GPUデバイスがデータを受信すると、前向き伝播（forward pass）と逆向き伝播（backward pass）の計算を開始し、各パラメータの勾配を計算します。モデルの規模が非常に大きいため、単一のGPUのメモリではすべてのパラメータを保存できないため、モデル並行技術を使用して、モデルパラメータを複数のGPUに分散させます。
• 勾配集約とパラメータ更新：逆向き伝播計算が完了すると、各GPUは一部のパラメータの勾配を取得します。次に、これらの勾配はすべてのGPUデバイス間で集約され、グローバル勾配を計算する必要があります。これにはネットワークを介してデータ転送が必要です。25Gbpsのネットワークを使用していると仮定すると、700GBのデータ（各パラメータが単精度浮動小数点数を使用していると仮定すると、1750億パラメータは約700GB）を転送するのに約224秒かかります。その後、各GPUはグローバル勾配に基づいて保存しているパラメータを更新します。
• 同期：パラメータの更新後、すべてのGPUデバイスは同期を行い、次のトレーニングステップで一貫したモデルパラメータを使用することを確認します。これもネットワークを介してデータ転送が必要です。
• トレーニングステップの繰り返し：すべてのバッチのトレーニングが完了するか、設定されたトレーニングエポック数に達するまで、上記のステップを繰り返します。

このプロセスは大量のデータ転送と同期を含み、トレーニング効率のボトルネックになる可能性があります。したがって、ネットワークの帯域幅と遅延を最適化し、高効率の並行および同期戦略を使用することは、大規模モデルのトレーニングにとって非常に重要です。

2. 通信オーバーヘッドのボトルネック：

通信のボトルネックは、現在の分散型コンピューティングネットワークが大規模言語モデルのトレーニングを行えない理由でもあります。

各ノードは協調して作業するために頻繁に情報を交換する必要があり、これが通信オーバーヘッドを生じさせます。大規模言語モデルの場合、モデルのパラメータ数が非常に多いため、この問題は特に深刻です。通信オーバーヘッドは以下のいくつかの側面に分かれます：

• データ転送：トレーニング中、ノードはモデルパラメータや勾配情報を頻繁に交換する必要があります。これには、大量のデータをネットワークで転送する必要があり、膨大なネットワーク帯域幅を消費します。ネットワーク条件が悪い場合や計算ノード間の距離が大きい場合、データ転送の遅延が非常に高くなり、通信オーバーヘッドがさらに増加します。
• 同期問題：トレーニング中、ノードはトレーニングが正しく行われるように協調して作業する必要があります。これには、各ノード間で頻繁に同期操作を行う必要があります。たとえば、モデルパラメータの更新やグローバル勾配の計算などです。これらの同期操作には、大量のデータをネットワークで転送する必要があり、すべてのノードが操作を完了するのを待つ必要があるため、大量の通信オーバーヘッドと待機時間が発生します。
• 勾配の累積と更新：トレーニング中、各ノードは自分の勾配を計算し、それを他のノードに送信して累積および更新する必要があります。これには、大量の勾配データをネットワークで転送する必要があり、すべてのノードが勾配の計算と転送を完了するのを待つ必要があるため、これも大量の通信オーバーヘッドの原因となります。
• データの一貫性：各ノードのモデルパラメータが一貫していることを保証する必要があります。これには、各ノード間で頻繁にデータの検証と同期操作を行う必要があり、これが大量の通信オーバーヘッドを引き起こします。

通信オーバーヘッドを削減するためのいくつかの方法がありますが、たとえばパラメータや勾配の圧縮、高効率の並行戦略などがありますが、これらの方法は追加の計算負担を引き起こす可能性があるか、モデルのトレーニング効果に悪影響を与える可能性があります。また、これらの方法は通信オーバーヘッドの問題を完全に解決することはできません。特にネットワーク条件が悪い場合や計算ノード間の距離が大きい場合にはなおさらです。

例を挙げると：

分散型コンピューティングネットワーク

GPT-3モデルには1750億のパラメータがあります。単精度浮動小数点数（各パラメータ4バイト）を使用してこれらのパラメータを表現する場合、これらのパラメータを保存するには約700GBのメモリが必要です。分散トレーニングでは、これらのパラメータを計算ノード間で頻繁に転送および更新する必要があります。

100個の計算ノードがあると仮定し、各ノードが各ステップで全てのパラメータを更新する必要がある場合、各ステップで約70TB（700GB*100）のデータを転送する必要があります。1ステップが1秒かかる（非常に楽観的な仮定）と仮定すると、毎秒70TBのデータを転送する必要があります。この帯域幅の需要は、ほとんどのネットワークを大きく超えており、実現可能性の問題です。

実際の状況では、通信遅延やネットワークの混雑により、データ転送にかかる時間は1秒を大幅に超える可能性があります。これは、計算ノードがデータ転送を待つために多くの時間を費やすことを意味し、実際の計算を行うことができません。これによりトレーニングの効率が大幅に低下し、この効率の低下は待つだけでは解決できず、実現可能性の違いを生じさせ、トレーニングプロセス全体を不可能にします。

中央集権的データセンター

中央集権的なデータセンター環境でも、大規模モデルのトレーニングには通信の最適化が必要です。

中央集権的なデータセンター環境では、高性能計算デバイスがクラスターとして接続され、高速ネットワークを介して計算タスクを共有します。しかし、このような高速ネットワーク環境であっても、パラメータ数が極めて多いモデルのトレーニングでは、通信オーバーヘッドがボトルネックとなります。なぜなら、モデルのパラメータや勾配は各計算デバイス間で頻繁に転送および更新される必要があるからです。

最初に述べたように、100個の計算ノードがあり、各サーバーは25Gbpsのネットワーク帯域幅を持っていると仮定します。各サーバーが各トレーニングステップで全てのパラメータを更新する必要がある場合、各トレーニングステップで約700GBのデータを転送するのに約224秒かかります。中央集権的なデータセンターの利点を活かし、開発者はデータセンター内部でネットワークトポロジーを最適化し、モデル並行などの技術を使用してこの時間を大幅に短縮できます。

対照的に、同じトレーニングを分散環境で行う場合、100個の計算ノードが世界中に分散していると仮定し、各ノードのネットワーク帯域幅が平均1Gbpsしかない場合、同じ700GBのデータを転送するのに約5600秒かかります。これは中央集権的なデータセンターで必要な時間よりもはるかに長いです。また、ネットワークの遅延や混雑により、実際に必要な時間はさらに長くなる可能性があります。

ただし、分散型コンピューティングネットワークの状況と比較すると、中央集権的なデータセンター環境での通信オーバーヘッドの最適化は比較的容易です。なぜなら、中央集権的なデータセンター環境では、計算デバイスが通常同じ高速ネットワークに接続されており、ネットワークの帯域幅と遅延が相対的に良好だからです。一方、分散型コンピューティングネットワークでは、計算ノードが世界中に分散している可能性があり、ネットワーク条件が相対的に悪くなるため、通信オーバーヘッドの問題がより深刻になります。

OpenAIがGPT-3をトレーニングする過程で、通信オーバーヘッドの問題を解決するためにMegatronというモデル並行フレームワークを採用しました。Megatronはモデルのパラメータを分割し、複数のGPU間で並行処理を行うことで、各デバイスが処理する必要のあるパラメータの量を減らし、通信オーバーヘッドを低減します。同時に、トレーニング時には高速な相互接続ネットワークを使用し、ネットワークトポロジーを最適化することで通信経路の長さを減少させます。

（LLMモデルのトレーニングに使用されるデータ）

3. なぜ分散型コンピューティングネットワークはこれらの最適化を行えないのか

行うことは可能ですが、中央集権的なデータセンターと比較すると、これらの最適化の効果は非常に制限されています。

1. ネットワークトポロジーの最適化：中央集権的なデータセンターでは、ネットワークハードウェアとレイアウトを直接制御できるため、必要に応じてネットワークトポロジーを設計および最適化できます。しかし、分散環境では、計算ノードが異なる地理的位置に分散しており、たとえば中国に1つ、アメリカに1つある場合、それらの間のネットワーク接続を直接制御することはできません。ソフトウェアを介してデータ転送経路を最適化することはできますが、ハードウェアネットワークを直接最適化するほど効果的ではありません。また、地理的位置の違いにより、ネットワークの遅延や帯域幅にも大きな変動があり、ネットワークトポロジーの最適化の効果をさらに制限します。
2. モデル並行：モデル並行は、モデルのパラメータを複数の計算ノードに分割し、並行処理を行うことでトレーニング速度を向上させる技術です。しかし、この方法は通常、ノード間でデータを頻繁に転送する必要があるため、ネットワークの帯域幅と遅延に高い要求があります。中央集権的なデータセンターでは、ネットワークの帯域幅が高く、遅延が低いため、モデル並行は非常に効果的です。しかし、分散環境では、ネットワーク条件が悪いため、モデル並行は大きな制約を受けます。

4. データセキュリティとプライバシーの課題

データ処理と転送に関与するほぼすべての段階がデータのセキュリティとプライバシーに影響を与える可能性があります：

1. データ配分：トレーニングデータは、計算に参加する各ノードに配分される必要があります。この段階で、データが分散ノードで悪用されたり漏洩したりする可能性があります。
2. モデルのトレーニング：トレーニング中、各ノードは割り当てられたデータを使用して計算を行い、モデルパラメータの更新や勾配を出力します。この過程で、ノードの計算プロセスが盗まれたり、結果が悪意を持って解析されたりすると、データが漏洩する可能性があります。
3. パラメータと勾配の集約：各ノードの出力は、グローバルモデルを更新するために集約される必要があります。集約プロセス中の通信も、トレーニングデータに関する情報を漏洩する可能性があります。

データプライバシーの問題に対する解決策は何ですか？

• 安全なマルチパーティ計算：SMCは特定の小規模な計算タスクで成功裏に適用されています。しかし、大規模な分散トレーニングタスクでは、計算と通信のオーバーヘッドが大きいため、現在は広く適用されていません。
• 差分プライバシー：Chromeのユーザー統計など、特定のデータ収集および分析タスクに適用されています。しかし、大規模な深層学習タスクでは、DPがモデルの精度に影響を与える可能性があります。また、適切なノイズ生成と追加メカニズムを設計することも課題です。
• フェデレーテッドラーニング：Androidキーボードの語彙予測など、一部のエッジデバイスのモデルのトレーニングタスクに適用されています。しかし、より大規模な分散トレーニングタスクでは、FLは通信オーバーヘッドが大きく、調整が複雑などの問題に直面しています。
• 同態暗号：計算の複雑性が比較的小さいタスクで成功裏に適用されています。しかし、大規模な分散トレーニングタスクでは、計算オーバーヘッドが大きいため、現在は広く適用されていません。

まとめ

上記の各方法には適応するシーンと限界があり、分散型コンピューティングネットワークの大規模モデルのトレーニングにおいてデータプライバシーの問題を完全に解決できる方法はありません。

期待されるZKは大規模モデルのトレーニング時のデータプライバシーの問題を解決できるのか？

理論的にはZKPは、分散計算におけるデータプライバシーを確保するために使用でき、あるノードが規定に従って計算を行ったことを証明することができますが、実際の入力や出力データを開示する必要はありません。

しかし、ZKPを大規模分散コンピューティングネットワークの大規模モデルのトレーニングシーンに適用するには、以下のボトルネックに直面します：

• 計算と通信のオーバーヘッドの増加：ゼロ知識証明の構築と検証には大量の計算リソースが必要です。また、ZKPの通信オーバーヘッドも大きく、証明自体を転送する必要があります。大規模モデルのトレーニングの場合、これらのオーバーヘッドは特に顕著になる可能性があります。たとえば、各小バッチの計算で証明を生成する必要がある場合、トレーニング全体の時間とコストが大幅に増加します。
• ZKプロトコルの複雑性：大規模モデルのトレーニングに適したZKPプロトコルを設計および実装することは非常に複雑です。このプロトコルは、大規模なデータと複雑な計算を処理できる必要があり、発生する可能性のある異常エラーを処理できる必要があります。
• ハードウェアとソフトウェアの互換性：ZKPを使用するには特定のハードウェアとソフトウェアのサポートが必要であり、これはすべての分散計算デバイスで利用できない可能性があります。

まとめ

ZKPを大規模分散コンピューティングネットワークの大規模モデルのトレーニングに適用するには、数年の研究と開発が必要であり、学術界がこの方向にもっと多くのエネルギーとリソースを投入する必要があります。

二、分散型コンピューティング---モデル推論

分散型コンピューティングのもう一つの大きなシーンはモデル推論にあります。大規模モデルの発展経路に基づくと、モデルのトレーニングの需要は高まりのピークを過ぎて成熟に伴い徐々に減少しますが、モデルの推論の需要は大規模モデルとAIGCの成熟に伴い指数関数的に増加します。

推論タスクは、トレーニングタスクに比べて通常計算の複雑性が低く、データの相互作用が弱く、分散環境での実行に適しています。

(NVIDIA TritonによるLLM推論の強化)

1. 課題

通信遅延：

分散環境では、ノード間の通信は不可欠です。分散型の分散コンピューティングネットワークでは、ノードが世界中に分散している可能性があるため、ネットワーク遅延が問題になることがあります。特にリアルタイム応答が必要な推論タスクでは顕著です。

モデルのデプロイと更新：

モデルは各ノードにデプロイする必要があります。モデルが更新された場合、各ノードはそのモデルを更新する必要があり、大量のネットワーク帯域幅と時間を消費します。

データプライバシー：

推論タスクは通常、入力データとモデルのみを必要とし、大量の中間データやパラメータを返す必要はありませんが、入力データにはユーザーの個人情報などの機密情報が含まれる可能性があります。

モデルセキュリティ：

分散型ネットワークでは、モデルが信頼できないノードにデプロイされるため、モデルの漏洩が発生し、モデルの権利や悪用の問題が生じる可能性があります。これはセキュリティとプライバシーの問題を引き起こす可能性があり、モデルが機密データを処理するために使用される場合、ノードはモデルの動作を分析することで機密情報を推測することができます。

品質管理：

分散型の分散コンピューティングネットワーク内の各ノードは異なる計算能力とリソースを持っている可能性があり、これが推論タスクの性能と品質を保証するのが難しくなる可能性があります。

2. 実現可能性

計算の複雑性：

トレーニング段階では、モデルは反復的にトレーニングされ、各層で前向き伝播と逆向き伝播の計算を行う必要があります。これには、活性化関数の計算、損失関数の計算、勾配の計算、重みの更新が含まれます。したがって、モデルのトレーニングの計算の複雑性は高いです。

推論段階では、1回の前向き伝播計算で予測結果を得るだけです。たとえば、GPT-3では、入力されたテキストをベクトルに変換し、モデルの各層（通常はTransformer層）を通じて前向き伝播を行い、最終的に出力の確率分布を得て、その分布に基づいて次の単語を生成します。GANの場合、モデルは入力されたノイズベクトルに基づいて画像を生成する必要があります。これらの操作はすべてモデルの前向き伝播に関与し、勾配を計算したりパラメータを更新したりする必要はなく、計算の複雑性は低いです。

データの相互作用性：

推論段階では、モデルは通常、単一の入力を処理し、トレーニング時の大量のデータを処理することはありません。各推論の結果は、現在の入力のみに依存し、他の入力や出力には依存しないため、大量のデータの相互作用を行う必要がなく、通信の負担も軽減されます。

生成画像モデルの例を挙げると、GANを使用して画像を生成する場合、モデルにノイズベクトルを入力するだけで、モデルは対応する画像を生成します。この過程では、各入力が1つの出力を生成するだけで、出力間に依存関係がないため、データの相互作用を行う必要はありません。

GPT-3の例を挙げると、次の単語を生成するためには、現在のテキスト入力とモデルの状態のみが必要であり、他の入力や出力と相互作用する必要はないため、データの相互作用性の要求も低いです。

まとめ

大規模言語モデルでも生成画像モデルでも、推論タスクの計算の複雑性とデータの相互作用性は相対的に低く、分散型の分散コンピューティングネットワークでの実行に適しています。これは、現在私たちが見るほとんどのプロジェクトが力を入れている方向でもあります。

3. プロジェクト

分散型の分散コンピューティングネットワークの技術的なハードルと技術の幅は非常に高く、ハードウェアリソースの支援も必要です。そのため、現在私たちはあまり多くの試みを見ていません。TogetherとGensyn.aiを例に挙げます：

1. Together

（TogetherのRedPajama）

Togetherは大規模モデルのオープンソースに特化し、分散型AIコンピューティングソリューションを目指す企業であり、誰もがどこでもAIにアクセスし使用できることを望んでいます。TogetherはLux Capitalがリードした2000万ドルのシードラウンドの資金調達を完了しました。

TogetherはChris、Percy、Ceによって共同設立され、大規模モデルのトレーニングには大量の高性能GPUクラスターと高額な支出が必要であり、これらのリソースとモデルのトレーニング能力が少数の大企業に集中していることが背景にあります。

私の観点から見ると、分散型コンピューティングのスタートアップ計画として比較的合理的なものは以下の通りです：

ステップ1. オープンソースモデル

分散型の分散コンピューティングネットワークでモデル推論を実現するための前提条件は、ノードが低コストでモデルを取得できる必要があるということです。つまり、分散型コンピューティングネットワークのモデルはオープンソースである必要があります（モデルが特定のライセンスの下で使用される必要がある場合、実現の複雑性とコストが増加します）。たとえば、chatgptのような非オープンソースのモデルは、分散型コンピューティングネットワークで実行するのには適していません。

したがって、分散型コンピューティングネットワークを提供する企業の隠れた障壁は、強力な大規模モデルの開発と維持能力を持つ必要があるということです。自社開発の強力なベースモデルをオープンソース化することで、第三者モデルのオープンソースへの依存をある程度解消し、分散型コンピューティングネットワークの最も基本的な問題を解決できます。また、コンピューティングネットワークが大規模モデルのトレーニングと推論を効果的に行えることを証明するのにも有利です。

Togetherもこのように行っています。最近発表されたLLaMAに基づくRedPajamaは、Together、Ontocord.ai、ETH DS3Lab、Stanford CRFM、Hazy Researchなどのチームによって共同で立ち上げられたもので、完全にオープンソースの大規模言語モデルのシリーズを開発することを目指しています。

ステップ2. モデル推論における分散型コンピューティングの実現

上記の2つのセクションで述べたように、モデル推論はモデルトレーニングに比べて計算の複雑性とデータの相互作用性が低く、分散型の分散環境での実行に適しています。

オープンソースモデルを基に、Togetherの開発チームはRedPajama-INCITE-3Bモデルに対して一連の更新を行いました。たとえば、LoRAを利用して低コストの微調整を実現し、モデルがCPU（特にM2 Proプロセッサを使用したMacBook Pro）上でよりスムーズに動作するようにしました。また、このモデルの規模は小さいですが、同じ規模の他のモデルを超える能力を持ち、法律や社会などのシーンで実際に応用されています。

ステップ3. モデルトレーニングにおける分散型コンピューティングの実現

（分散型トレーニングの通信ボトルネックを克服するためのコンピューティングネットワークの概念図）

中長期的に見て、AIの大規模モデルのトレーニングにおけるコンピューティング需要を受け入れることは、非常に魅力的であることは間違いありません。Togetherは設立当初から、分散型トレーニングにおける通信ボトルネックを克服する方法を模索してきました。彼らはNeurIPS 2022で関連する論文を発表しました：Overcoming Communication Bottlenecks for Decentralized Training。以下の方向性を主にまとめることができます：

スケジューリングの最適化

分散環境でトレーニングを行う際、各ノード間の接続には異なる遅延と帯域幅があるため、通信が重いタスクを速い接続を持つデバイスに割り当てることが重要です。Togetherは特定のスケジューリング戦略のコストを記述するモデルを構築し、通信コストを最小化し、トレーニングのスループットを最大化するためにスケジューリング戦略を最適化しています。Togetherチームは、ネットワークが100倍遅くても、エンドツーエンドのトレーニングスループットはわずか1.7〜2.3倍遅くなることを発見しました。したがって、スケジューリングの最適化を通じて分散型ネットワークと中央集権的クラスター間のギャップを埋めることは非常に可能性があります。

通信圧縮の最適化

Togetherは前向きの活性化と逆向きの勾配に対する通信圧縮を提案し、AQ-SGDアルゴリズムを導入しました。このアルゴリズムは、確率的勾配降下法の収束に対する厳格な保証を提供します。AQ-SGDは、遅いネットワーク（たとえば500 Mbps）上で大規模な基盤モデルを微調整することができ、中央集権的なコンピューティングネットワーク（たとえば10 Gbps）で圧縮なしのエンドツーエンドのトレーニング性能と比較して、わずか31％遅くなります。さらに、AQ-SGDは最先端の勾配圧縮技術（たとえばQuantizedAdam）と組み合わせて使用することができ、エンドツーエンドの速度を10％向上させることができます。

プロジェクトのまとめ

Togetherチームは非常に包括的な構成を持ち、メンバーは大規模モデルの開発、クラウドコンピューティング、ハードウェア最適化などの業界の専門家によって支えられています。また、Togetherは道筋の計画において、確かに長期的な忍耐を示しています。オープンソースの大規模モデルの開発から、分散型コンピューティングネットワークにおけるモデル推論のための余剰コンピューティングリソースのテスト、そして大規模モデルのトレーニングにおける分散型コンピューティングの配置まで、--- まさに厚積薄発の感があります:)

しかし、現在のところTogetherがインセンティブ層に関する研究成果をあまり見ていないことは、技術開発と同様に重要であり、分散型コンピューティングネットワークの発展を確保するための鍵となる要素だと考えています。

2. Gensyn.ai

(Gensyn.ai)

Togetherの技術的な道筋から、分散型コンピューティングネットワークがモデルのトレーニングと推論においてどのように実現されるか、そしてそれに伴う研究の重点を大まかに理解することができます。

もう一つ無視できない重点は、コンピューティングネットワークのインセンティブ層/コンセンサスアルゴリズムの設計です。優れたネットワークには以下の要素が必要です：

1. 収益が十分に魅力的であることを保証する；
2. 各マイナーが適切な収益を得られることを保証する（不正防止と多労多得を含む）；
3. タスクが異なるノード間で合理的にスケジュールおよび配分され、大量のアイドルノードや一部のノードが過度に混雑しないようにする；
4. インセンティブアルゴリズムがシンプルで効率的であり、過剰なシステム負担や遅延を引き起こさないこと；

……

Gensyn.aiがどのように行っているか見てみましょう：

• ノードになる

まず、コンピューティングネットワーク内のソルバーは、入札の方法でユーザーが提出したタスクを処理する権利を競い、タスクの規模や不正が発覚するリスクに応じて、一定の金額を担保する必要があります。

• 検証

ソルバーはパラメータを更新する際に複数のチェックポイントを生成し（作業の透明性と追跡可能性を保証）、定期的にタスクに関する暗号化された推論証明（作業の進捗の証明）を生成します。

ソルバーが作業を完了し、一部の計算結果を生成した場合、プロトコルは検証者を選択し、検証者も一定の金額を担保し（検証者が誠実に検証を実行することを保証）、上記の証明に基づいてどの部分の計算結果を検証するかを決定します。

• ソルバーと検証者の間に意見の不一致が生じた場合

Merkleツリーのデータ構造に基づいて、計算結果に不一致がある正確な位置を特定します。検証の操作全体はブロックチェーンに記録され、不正者は担保金を差し引かれます。

プロジェクトのまとめ

インセンティブと検証アルゴリズムの設計により、Gensyn.aiは検証プロセスで全ての計算タスクの結果を再生する必要がなく、提供された証明に基づいて一部の結果を複製および検証するだけで済むため、検証の効率が大幅に向上します。また、ノードは部分的な計算結果のみを保存する必要があるため、ストレージスペースと計算リソースの消費も削減されます。さらに、潜在的な不正ノードはどの部分が選ばれて検証されるかを予測できないため、不正のリスクも低下します。

このような検証の不一致と不正者の発見の方法は、全ての計算結果を比較する必要がなく（Merkleツリーの根ノードから始めて、徐々に下に移動する）、計算プロセス中のエラーが発生した場所を迅速に特定できるため、大規模な計算タスクを処理する際に非常に効果的です。

要するに、Gensyn.aiのインセンティブ/検証層の設計目標は：シンプルで効率的です。しかし、現在は理論的なレベルに限られており、具体的な実現には以下の課題があるかもしれません：

• 経済モデルにおいて、適切なパラメータを設定し、不正を効果的に防止しつつ、参加者に過度なハードルを課さないようにすること。
• 技術的実現において、効果的な周期的な暗号推論証明を策定することは、高度な暗号学の知識を必要とする複雑な問題です。
• タスク配分において、コンピューティングネットワークが異なるソルバーにタスクを選択し配分する方法も合理的なスケジューリングアルゴリズムの支援が必要です。単に入札メカニズムに基づいてタスクを配分することは、効率と実現可能性の観点から明らかに議論の余地があります。たとえば、計算能力の強いノードはより大規模なタスクを処理できますが、入札に参加していない可能性があります（ここではノードの可用性に対するインセンティブの問題が関わります）。計算能力の低いノードは最高の入札を行うかもしれませんが、複雑な大規模計算タスクを処理するのには適していないかもしれません。

4. 未来への考察

分散型コンピューティングネットワークが誰に必要かという問題は、実際にはまだ検証されていません。アイドルコンピューティングリソースを、コンピューティングリソースの需要が非常に大きい大規模モデルのトレーニングに適用することは明らかに最も理にかなっており、想像の余地も大きいです。しかし、実際には通信やプライバシーなどのボトルネックが私たちに再考を促します：

分散型で大規模モデルをトレーニングすることに本当に希望が見えるのでしょうか？

このような共通の認識から抜け出し、「最も合理的な落地シーン」を超えて、分散型コンピューティングを小型AIモデルのトレーニングに適用することも大きなシーンであるかもしれません。技術的な観点から見ると、現在の制限要因はモデルの規模とアーキテクチャによって解決されており、市場の観点から見ると、私たちは常に大規模モデルのトレーニングが現在から未来にかけて巨大であると考えていますが、小型AIモデルの市場には魅力がないのでしょうか？

私はそうは思いません。大規模モデルに比べて小型AIモデルは展開と管理が容易であり、処理速度とメモリ使用においても効率的です。多くのアプリケーションシーンでは、ユーザーや企業は大規模言語モデルのより一般的な推論能力を必要とするのではなく、非常に細分化された予測目標にのみ関心を持っています。したがって、ほとんどのシーンでは、小型AIモデルが依然としてより実行可能な選択肢であり、大規模モデルの潮流の中で早期に無視されるべきではありません。