著者 | Feng Nie
原文リンク：https://zhuanlan.zhihu.com/p/1932578428181279850
本稿は学術共有のみを目的としており、もし著作権侵害があれば、削除を要請するためにご連絡ください。
原文リンク：
Robin's Home Page：jianzhnie.github.io/llmtech/#/rlhf/infra/RL-Infra_overview
1. SFTから強化学習へ：モデル訓練パラダイムの転換
2024年にOpenAIがO1シリーズモデルを発表するまで、主流の機械学習訓練方法は主に教師ありファインチューニング（Supervised Fine-Tuning, SFT）に依存していました。この方法は、モデルに「正解」を学習させ、予測と実際のラベル間の損失（loss）に基づいてモデルパラメータを更新します。訓練プロセスは比較的単純で、PyTorchやTensorFlowなどの深層学習フレームワークもこのパラダイムを中心に豊富な訓練加速ツールを構築してきました。
しかし、O1シリーズモデルの発表に伴い、モデル訓練の重点はSFTから強化学習（Reinforcement Learning, RL）へと徐々に移行しています。SFTは訓練プロセスにおける「ウォーミングアップ」段階と見なされ、その役割はパラメータの初期化やポリシーの誘導に弱められています。代わりに、RLはモデルの能力向上においてますます重要な役割を担っています。
1.1. RLアルゴリズムの進化と多様化
RLアルゴリズム自体も絶えずイテレーションと最適化を繰り返しています。初期のDPO（Direct Preference Optimization）から、古典的なPPO（Proximal Policy Optimization）、さらに近年登場したGRPO、RLOO、Reinforce++、DAPOなどの新しい手法まで、RLアルゴリズムはポリシー更新方法、安定性、サンプル効率などの面で最適化を続けています。
DPOはその簡潔さから一時期流行しましたが、タスクの複雑さやモデル規模の増大に伴い、その限界が徐々に明らかになり、現在では実際のエンジニアリングではあまり採用されていません。それでも、主流のRLフレームワークの全体構造は比較的安定しており、コアプロセスは主に以下の段階で構成されています：
1.2. RL訓練プロセスの三大モジュール
モジュール1：ポリシー生成（ロールアウト）
「生徒が自分で答えを探す」プロセスに対応します。これはRL訓練におけるロールアウト段階であり、モデルは現在のポリシーに基づいて応答（action）を生成し、環境とのインタラクションをシミュレートします。この段階はモデル推論プロセスの拡張であり、通常、多様な行動軌跡を得るために大量のサンプリングが必要です。
モジュール2：報酬評価（Reward Evaluation）
「生徒の答えを採点する」プロセスに対応します。伝統的に、この段階は報酬モデル（Reward Model）に依存し、生成結果の品質を評価するために使用されます。現在の段階では、タスクの複雑さの向上に伴い、報酬評価の実装方法も多様化しています：
ルールベースの評価（Rule-based）：数学、物理、コードなどの分野で、結果とルールの合致度に基づいて採点を行います。
軽量報酬モデル：小さなモデル（例：7Bパラメータ）を訓練して採点を行い、コストは制御可能で、良好な結果が得られます。
多くの研究プロジェクトでは、このモジュールはロールアウトの一部として簡略化され、個別に重視されていませんでした。しかし、エージェント行動シミュレーションの台頭、特にEコマースやカスタマーサービスなどの商業アプリケーションシナリオでは、報酬評価の複雑性が著しく上昇しており、将来的にはこのモジュールの重要性が高まるでしょう。
モジュール3：ポリシー更新（Policy Update）
「生徒が採点に基づいて学習する」プロセスに対応します。これはRL訓練のコア段階であり、従来の訓練フレームワーク（例：PyTorch、DeepSpeedなど）に基づいて損失関数を変更することでポリシー更新を実現します。PPO、DPO、RLOOなどの異なるアルゴリズムは、この段階での実装ロジックが異なりますが、全体構造は一貫しています。
1.3 まとめ
SFT主導の訓練パラダイムからRL駆動の能力向上へと、大規模モデルの訓練プロセスは深い変革を経験しています。RLフレームワークの構造は安定していますが、その各モジュールの機能、実装方法、重要性は絶えず進化しています。
ロールアウトモジュール：長いコンテキストや異種タスクによるパフォーマンスの課題に直面しています。
報酬評価モジュール：単純なルールから複雑な評価へと進化しており、将来的にRL訓練における重要なボトルネックとなる可能性があります。
ポリシー更新モジュール：基盤となる訓練フレームワークのパフォーマンス最適化とアルゴリズムのイテレーションに依存しています。
エージェント行動シミュレーション、複雑なタスクモデリング、マルチモーダルインタラクションなどの方向性の発展に伴い、RLフレームワークの設計はモジュール間の協調、リソーススケジューリングの効率性、アルゴリズムとエンジニアリング実装の統一性により一層注力されるでしょう。
2. RL訓練フレームワークの設計とパフォーマンス最適化の課題
現在、主流の強化学習（Reinforcement Learning, RL）訓練フレームワークは、通常、訓練（Training）とロールアウト（推論）の二つのコアモジュールに分けられます。
効率的なRL訓練システムを設計する際、開発者は一連の重要な課題に直面します。以下は、技術選定とフレームワーク設計プロセスでまとめた三大核心問題です。
2.1 課題1：ロールアウトと訓練モジュールの連携とリソース管理
現在、RL訓練は一般的にオンポリシー（On-policy）戦略を採用しており、これはロールアウトと訓練プロセスが順次実行されなければならないことを意味します。しかし、モデル規模の継続的な増大に伴い、分散型マルチGPU訓練は避けられないトレンドとなっています。
ロールアウト段階：主にメモリ集約型タスクであり、特に長いコンテキスト（例：Chain-of-Thought）を処理する際には、大量のKVキャッシュ（Key-Value Cache）を維持する必要があります。
訓練段階：計算集約型タスクであり、大規模なパラメータ更新と勾配計算を伴います。
これら二つの段階はそれぞれ多くの最適化手法（例：メモリ再利用、パイプライン並列化など）を持っていますが、これら二種類の異種リソースを統一されたフレームワーク内でいかに効率的に管理するか？両者間のパラメータ同期メカニズムをいかに最適化するか？これらは効率的なRLシステムを構築する上での重要な課題です。
2.2 課題2：基盤となる訓練および推論フレームワークの多様性
現在、以下のような複数の主流の訓練フレームワークが存在します：
Megatron-LM
DeepSpeed（FSDP）
PyTorch FSDP
同時に、推論エンジンも多様化の傾向を示しています：
vLLM
SGLang
異なる訓練フレームワークと推論エンジンのアーキテクチャは顕著な差があり、パラメータ同期や推論スケジューリングなどの側面で実装ロジックに大きな違いが生じます。例えば、パラメータ更新の部分だけでも、異なる組み合わせでは全く異なる実装ロジックが必要となる可能性があり、これはシステムの保守性と拡張性に対して高い要求を課します。
2.3 課題3：異種バッチ実行による不確実性
ロールアウトタスクは通常バッチ形式で実行されますが、バッチ内のタスクの複雑さは大きく異なる場合があります。特にエージェント行動シミュレーションを導入するシナリオでは、この異種性がより顕著になり、全体的なスケジューリング効率の低下やリソース利用率の不均衡といった問題を引き起こす可能性があります。
3. パフォーマンス最適化分析
3.1 初期実装とパフォーマンスボトルネック
RL訓練の初期の実装では、ワークフロー全体は通常、以下の3つの段階に分けられました：
1. 推論段階（ロールアウト）：モデルが現在のポリシーに基づいて応答を生成します。
2. 評価段階：報酬モデルまたはその他のメカニズムを通じて生成結果の品質を採点します。
3. 訓練段階：採点結果に基づいてポリシーモデルを更新します。
このワークフローは本質的にSFT（教師ありファインチューニング）フレームワークに基づいて実装できますが、ポリシーモデル、報酬モデルなどの複数のモデルインスタンスを初期化する必要がある点が異なります。しかし、この実装方法は実際の運用において顕著なパフォーマンスボトルネックを抱えることがよくあります。
3.2 メモリ最適化戦略
大規模モデル訓練において、GPUメモリの占有は主に以下の部分を含みます：
モデルパラメータ（Parameters）
勾配（Gradients）
オプティマイザの状態（Optimizer States）
アクティベーション（Activations）
7Bパラメータのモデルを例にとると、FP32精度では、モデルパラメータと勾配だけで約28GBのGPUメモリが必要となり、オプティマイザの状態はさらに28GB×3=84GBを占める可能性があり、合計で112GBに達します。明らかに、単一のGPUではこれほど膨大なメモリ要件をまかなうことはできません。
このため、業界では多様な分散訓練戦略が提案されています：
データ並列化（Data Parallelism, DP）：DeepSpeed ZeRO-1/2/3のように、All-Gather操作を通じて完全なパラメータを動的に再構築します。
テンソル並列化（Tensor Parallelism, TP）とパイプライン並列化（Pipeline Parallelism, PP）：Megatron-LMのように、パラメータ分割戦略を採用し、大規模モデルに適しています。
NVIDIAの関連論文の研究結果によると、1000枚以下のGPU規模では、DPとTP/PPのパフォーマンスは同等ですが、より大規模な場合では、TP/PPがAll-Gather操作の通信オーバーヘッドを回避できるため、パフォーマンス上の優位性がより顕著になります。
この表は、データ並列化（DP）、テンソル並列化（TP）、パイプライン並列化（PP）の3種類の並列化戦略を異なる特性で比較したものです。
3.3 推論速度最適化とエンジン選定
現在の主要な推論エンジン（vLLMやSGLangなど）は、KVキャッシュの再利用や基盤となる演算子の最適化において、顕著なパフォーマンス向上を実現しています。それにもかかわらず、訓練と推論エンジン間のパラメータ同期には依然として課題が存在します：
推論エンジンが生成する出力と訓練エンジンの精度に違いがある；
現在の主流のアプローチは、ロールアウト段階で推論エンジンを使用して生成を高速化し、訓練段階では訓練エンジンがlogitsを再計算する（prefill段階のみで十分であり、計算効率が高い）というものです。
したがって、高性能推論エンジンを訓練フレームワークと統合することは、RL訓練全体の効率を高めるための有効な道筋です。しかし、訓練と推論モジュールの結合と協調をいかに効率的に実現するかは、引き続き深く研究されるべき問題です。
4. 訓練フレームワークと推論エンジンの統合
4.1 SPMDとMPMDの概念解説
訓練フレームワークと推論エンジンをどのように組み合わせるかを議論する前に、SPMD（Single Program, Multiple Data）とMPMD（Multiple Programs, Multiple Data）の概念を理解しておく必要があります。簡単に言えば、SPMDは複数の処理ユニットが同じプログラムを実行し、異なるデータセットを操作することを指し、MPMDは複数の処理ユニットが異なるプログラムを実行し、異なるデータセットを処理することを指します。前者は通常、ワークフローを調整するための集中コントローラを必要としませんが、後者は混乱を避けるために必要となる場合があります。
訓練フレームワークと推論エンジンの統合を議論する際、まず理解すべきは2つの並列処理モードです：SPMD（Single Program, Multiple Data）とMPMD（Multiple Programs, Multiple Data）。これらの2つのモードは、単一コントローラアーキテクチャとマルチコントローラアーキテクチャとしても説明できます。
単一コントローラ（SPMD）：すべてのワーカーノードが同じプログラムロジックを実行し、データ量が大きくモデル規模が小さいシナリオに適しています。
マルチコントローラ（MPMD）：各ワーカーノードが異なるプログラムを実行でき、実装の複雑さは増しますが、集中制御が不要で、特定のアプリケーションシナリオに適しています。
DeepSpeedやMegatronなどの主流の深層学習訓練フレームワークはSPMDモードを採用しており、すべてのプロセスが同じコードロジックに従って演算を行うことを保証しています。しかし、推論エンジン（SGLangやvLLMなど）の場合、状況は異なります。推論エンジン（SGLangやvLLMなど）は計算プロセスにおいてSPMD原則に従いますが、次のトークンのソースを決定したり、KVキャッシュをどのように処理するかといった点では、SPMD/MPMD分類が完全に適用されるわけではありません。これらの状況では、Google Pathwayなどのシステムがより柔軟なソリューションを提供しています。
上記の背景を考慮すると、我々は単一コントローラまたはマルチコントローラアーキテクチャの採用に限定するのではなく、訓練フレームワークと推論エンジン間の訓練データおよびモデルパラメータに関する通信メカニズムにより一層注力すべきです。
4.2 SLIMEの具体的な実装方法
訓練フレームワークと推論エンジン間の核心的な課題は、訓練データとモデルパラメータの通信メカニズムにあります。これをよりよく理解するために、SLIMEとROLLプロジェクトを分析し、具体的な実装方法を探ることができます。
SLIMEは、強化学習の拡張に特化した後処理フレームワークであり、RayTrainGroupを訓練フレームワーク用、RolloutGroupを推論エンジン用として2つの主要なコンポーネントを定義しています。
4.2.1 データ転送メカニズム
SLIMEは、ミドルウェアクラスであるBufferを定義することで、推論エンジンと訓練モジュール間のデータ転送を実現しています。すべてのデータはこのBufferに格納され（ディスクへの書き込みも可能）、ロールアウトIDを介して指定アクセスが行われます。さらに、Bufferクラス内のデータ処理関数およびロールアウト/評価関数は、コマンドライン引数を通じて柔軟に設定可能であり、システムの適応性を大幅に向上させています。
この設計により、ビジネス要件への対応がより柔軟かつ効率的になり、特に様々な特殊な要件やデータ形式に直面する際に重要です。
ロールアウトのgenerate関数はBufferを介しています。
訓練フレームワークが必要とするデータの取得も、このBufferに依存しています：
ロールアウトのバッファをアクターに同期するプロセスは以下の通りです：
4.2.2 モデルパラメータ同期メカニズム
ロールアウトエンジンが適切なタイミングで正しくパラメータを同期できるよう、SLIMEはアクターの構成情報をロールアウトに渡します。これには、各訓練段階後に重みを更新するためのプロセスグループの初期化が含まれます。
上記のプロセスは、データバッファの同期だけでなく、アクター間の並列構成の調整も網羅しており、パラメータ更新の一貫性と正確性を保証します。
4.3 ROLLの具体的な実装方法
ROLLは、クラスター（Cluster）方式を通じて複数の役割を定義しており、各役割が異なるタスクを担当します。この設計方法はアルゴリズムレベルの認識と比較的合致しており、アルゴリズムの観点から見ると、訓練フレームワークと推論エンジン間の差異は顕著ではなく、クラスターによるカプセル化はこれらの複雑さをうまく隠蔽しています。
4.3.1 データ転送メカニズム
Megatronと同様に、ROLLはドメイン（domain）ごとにサンプリングを分離し、pipeline.pyファイルで設定することを可能にしています。これにより、ユーザーがデータジェネレータを作成したくない場合でも、ROLLはより便利なソリューションを提供します。特に報酬（reward）モデルについては、統一されたモデルが理想的ですが、訓練の難易度が高いため、現在は異なるドメインに対して異なる報酬モデルを使用し、最終的に集約処理を行う傾向にあります。ROLLは、多様なアプリケーションシナリオに適応するために、異なるドメイン、バッチ、およびクエリに対するカスタム設定をサポートしています。
4.3.2 モデルパラメータ同期メカニズム
ROLLにおけるモデル更新ロジックは、ポイントツーポイント通信と集合通信の2つの方法を組み合わせています：
ポイントツーポイント通信：同一デバイス上のパラメータ更新に使用され、workerのnode_rankとgpu_rankを直接介して同一デバイス上にあるかどうかを判断し、効率的なデータ交換を行います。
集合通信：ターゲットクラスターにパラメータをブロードキャストすることで実現され、メインプロセス（rank 0）のみがブロードキャスト操作を実行します。これはデバイス間のパラメータ同期に適しています。
これら2つの通信戦略は、コロケーションおよび非コロケーションのシナリオにそれぞれ対応し、パラメータ同期の柔軟性と効率を保証します。
4.3.4 複数マシン展開時の考慮事項
すべてのコンポーネントが同一マシン上にある場合、パラメータ同期のハードコード実装は比較的単純ですが、複数マシン展開になると状況はより複雑になります。この場合、ネットワーク通信による遅延と帯域幅の制限をいかに効果的に管理するかだけでなく、分散環境下でのリソース割り当てとロードバランシングを最適化することも考慮する必要があります。さらに、シングルコントローラモードでは、クラスター規模の拡大に伴いコントローラへの負担が増大し、特にマルチメディアデータを処理する際には、パフォーマンスボトルネックに特別な注意を払う必要があるかもしれません。したがって、複数マシン展開の場合、適切な通信戦略の選択とコントローラのワークロード最適化が特に重要になります。ただし、SLIMEとROLLの設計から見ると、パラメータ同期の核心はGPUに同期操作を通知することにあり、中間の通信プロセスはコントローラに依存しないため、複数マシン展開にある程度の利便性と柔軟性を提供します。
4.4 コロケーションとRayの応用
アクター、リファレンス、報酬、クリティックなどのモデルを同一GPUカード上に配置することをコロケーションと呼びます。しかし、前述の通り、モデル規模の増大（例えば、7Bモデルはすでに単一カードでの訓練が困難）に伴い、今年後半には1000Bパラメータを超えるモデルが複数登場すると予想されます。これにより、並列計算によるオーバーヘッドが非常に顕著になります。現在、報酬モデルは一般的に小さく、7-30Bの規模で十分なため、個別に展開する方が費用対効果が高いことがよくあります。
この複雑さに対処するため、プロジェクトでは分散計算をサポートする強力なフレームワークであるRayが導入され、開発者が基盤ロジック管理の負担を軽減するのに役立ちます。Rayベースの分散訓練ワークフローとRay分散計算フレームワークの詳細は、以下の記事を参照してください： - OpenRLHFにおけるRayベースの分散訓練ワークフローの図解 - Ray分散計算フレームワークの詳細解説
次に、SLIME、Verl、ROLL、OpenRLHFの4つのフレームワークにおけるコロケーションと非コロケーションの実装の違いを比較します。
4.4.1 SLIME
SLIMEは、RayTrainGroupを訓練用、RolloutGroupを推論用として、2つの主要なワーカーのみを定義しています。コロケーションの場合、訓練と推論は個別に展開できます。一方、非コロケーションの場合には、パラメータを同期するために分散通信を処理する必要があります。この設計は抽象度が高く、理解しやすく、訓練と推論の異なるニーズにうまく適応できます。構成でコロケーションを指定するだけで、すべての重要な段階で関連する操作が自動的に実行されます。
4.4.2 ROLL
非コロケーションシナリオでは、ROLLは異なるワーカー（例：アクター、クリティック、報酬など）を異なるGPUに、さらにはイテレーションごとに配置するきめ細やかな指定を可能にします。手動で指定しない場合、Rayが自動的に展開を完了します。RLタスクはリソース消費が大きいことを考慮すると、きめ細やかなGPUリソース構成はリソース利用効率の向上に役立ちますが、同時にアルゴリズム側のリソーススケジューリング能力にも高い要求を課します。明らかに、これらの複雑さを管理するにはRayを使用する方が適切です。
4.4.3 Verl
VERLは、コロケーションと非コロケーションの展開を実現するために独自のアプローチを採用しています。非コロケーションモードでは、各ワーカー（例：アクター、クリティック、報酬など）は独立したプロセスとして実行され、スケジューリングはRayに依存します。一方、コロケーションモードでは、複数の役割が同じRayアクターインスタンスを共有し、同じプロセス内で複数のワーカークラスをインスタンス化します。create_colocated_worker_clsまたはcreate_colocated_worker_cls_fusedメソッドを介して、複数の役割を持つクラス（WorkerDict/FusedWorkerなど）が動的に生成され、その内部には複数のワーカーインスタンスが保持されます。外部からは統一されたインターフェースを介して異なる役割のワーカーメソッドを呼び出すことができ、内部では対応するワーカーインスタンスに自動的にディスパッチされます。この方法は、同じプロセス内で複数の役割が共存することを可能にし、プロセス間通信による遅延やメモリ断片化の問題を軽減するなど、特定のシナリオでパフォーマンスを大幅に向上させることができます。
4.4.4 OpenRLHF
OpenRLHFは柔軟なハイブリッド展開オプションを提供しており、vLLMエンジン、アクター、リファレンス、報酬、クリティックモデルノードの共配置展開だけでなく、非同期訓練のニーズに合わせて部分的なハイブリッド展開や完全な分離展開もサポートしています。この柔軟性により、多様なアプリケーションシナリオに対応できますが、同時に管理と最適化の複雑さも増します。
4.4.5 結論
まとめると、非コロケーションの場合、特に複雑なエージェントや複数ターンインタラクションのシナリオを扱う際に、Rayはリソース管理をより簡単にするのに役立ちます。しかし、運用チームからのフィードバックによると、Rayの設計思想は既存のKubernetesクラウドネイティブ生産環境と一部競合しており、実際の生産環境でのデプロイ時に管理コストが高くなるという問題があります。それでも、Rayチームはこれらの問題に対処するため、例えばRayがNCCLを通じて直接テンソルデータを転送できるようにすることで、オブジェクトストレージを迂回して効率を高めるなどの最適化に取り組んでいます。将来的には、Rayからのさらなる更新と改善が期待されます。
4.5 異なる訓練フレームワークと推論エンジンの統合
異なる訓練フレームワークと推論エンジンを統合する際、パラメータ変換の問題が発生する可能性があります。例えば、vLLMが4次元テンソル並列化（TP）を使用し、DeepSpeedが8つのGPUに分散している場合、データ転送の一貫性を確保するために適切なパラメータ変換が必要です。Megatron-LMも同様の要件を持っています。複数の訓練フレームワークと推論エンジンが存在する場合、適合のための作業量は指数関数的に増加し、設定エラーやパフォーマンス問題を引き起こす可能性があります。
4.6 コードの疎結合設計
SLIMEを例にとると、そのアーキテクチャは3層に分かれています：最上位層のRolloutGroupが推論エンジンの全体フローを管理し、中間層のRolloutRayActorが具体的な推論リクエストを処理し、最下層のSglangEngineが具体的な推論ロジックを実装します。この階層設計により、バックエンドの推論エンジンの置き換えが容易になり、上位の制御ロジックを変更することなく、下層の実装を変更するだけで済みます。同様に、訓練フレームワークも同様の階層構造を採用しており、システムの柔軟性と保守性を保証しています。
5. エージェント強化学習について
現在、ROLL、Verl、OpenRLHFなどのフレームワークは、エージェント強化学習に対して良好なサポートを提供しています。これによりコードの複雑さが増す可能性はありますが、技術が成熟するにつれて、より明確な設計が登場すると予想されます。将来的には、エージェント強化学習が主流となり、既存のRL手法はその一部となるでしょう。
6. フレームワーク選択の推奨事項
6.1 フレームワークの難点分析
技術環境の急速な発展は、古いフレームワークがすぐに時代遅れになることを意味します。そのため、フレームワークを簡潔に保ち、高い保守性を維持することが鍵となります。新しいフレームワークは過去の負債がないため、新しい技術トレンドに容易に適応できます。
6.2 推奨フレームワーク
OpenRLHF：Ray、vLLM、ZeRO-3、HuggingFace Transformersを統合した高性能なオープンソースRLHFフレームワーク。
slime：新しくローンチされたフレームワークで、コードが簡潔であり、大胆なフレームワーク変更を試したい研究者に適しています。
ROLL：データ処理と非同期操作のサポートを強調しており、特にエージェント強化学習を深く探求するチームに適しています。
verl：安定していて最適化が良好で、大規模クラスター展開に適しており、特にリソースが豊富なチームに推奨されます。
チームの具体的なニーズと技術的背景に基づいて、最適なフレームワークを選択して作業を進めることができます。特定の要件があるチームや迅速な拡張を希望するチームにとっては、複数の大手企業によって検証されているverlが良い選択肢かもしれません。一方、技術革新とアジャイル開発を追求するチームには、slimeまたはROLLがより魅力的かもしれません。
まとめ
過去半年間、我々はRL訓練フレームワーク、エージェントフレームワーク、そして推論エンジンフレームワークについて深く掘り下げてきました。全体として、コード量ではエージェントフレームワークが最も膨大で、次いで推論エンジン、RL訓練フレームワークの順です。コードの難易度では、推論エンジンがトップで、次にRL訓練フレームワーク、エージェントフレームワークが続きます。特筆すべきは、推論エンジンの基盤となる演算子の複雑さを除けば、RL訓練フレームワークの課題は主に様々なシステムと技術の統合にあり、これはフレームワーク開発者が多様な技術とビジネスロジックについて深い理解を持つことを要求します。
verl、slime、ROLL、OpenRLHFといったオープンソースフレームワークはそれぞれ特色を持ち、著者たちの追求と堅持を示しており、コミュニティの活動も活発です。オープンソースRLフレームワークの分野において、中国は技術力と認知深度の面で世界をリードしていると言えるでしょう。アルゴリズム人材間の差異は大きくありませんが、ハードウェアリソース（GPUなど）の面ではまだ一定の差があります。