テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践-AI-php.cn

著者: 亚廼英梁陈龙他

はじめに

美団のフードデリバリー事業が発展し続ける中、フードデリバリー広告エンジンチームは複数の分野でエンジニアリングの探索と実践を実施し、一定の成果を上げてきました。連載形式で共有していきますが、その内容は主に、①ビジネスプラットフォーム化の実践、②大規模ディープラーニングモデルエンジニアリングの実践、③ニアラインコンピューティングの探索と実践、④大規模なディープラーニングモデルエンジニアリングの実践です。 -スケールインデックスの構築とオンライン検索サービス; ⑤ 機構エンジニアリングプラットフォームの実践。少し前に、当社はビジネスプラットフォーム化の実践を公開しました (詳細については、「##美団テイクアウト広告プラットフォーム化の検討と実践 ##」を参照してください) #>> 1つ)。この記事は、一連の記事の 2 番目であり、フルリンクレベルでの大規模ディープモデルによってもたらされる課題に焦点を当て、オンラインレイテンシとオフライン効率の 2 つの側面から始めて、大規模な広告エンジニアリングについて説明します。スケールディープモデル. 練習して、皆さんに何らかの助けやインスピレーションをもたらすことを願っています。 1 背景

検索、レコメンデーション、広告などのインターネットの中核的なビジネスシナリオ (

以下、検索プロモーション ) 、データマイニングと関心が行われますモデリングとユーザーに高品質のサービスを提供することは、ユーザーエクスペリエンスを向上させるための重要な要素となっています。近年、検索およびプロモーションビジネスでは、データの配当とハードウェアテクノロジーの恩恵を受けてディープラーニングモデルが業界で広く導入されており、同時に CTR シナリオでは、業界は単純な DNN 小規模から徐々に移行しています。モデルから大規模なモデルまで、数兆のパラメータを持つ埋め込みモデル、または超大規模なモデルまで。テイクアウト広告ビジネスラインは主に「LR浅いモデル（ツリーモデル）」→「深層学習モデル」→「大規模深層学習モデル」という進化過程を経験してきました。進化全体の傾向は、人工的な特徴に基づく単純なモデルから、データを中心とした複雑な深層学習モデルへと徐々に移行しています。大型モデルの採用により、モデルの表現力が大幅に向上し、需要側と供給側のマッチングがより正確になり、その後のビジネス展開の可能性が広がりました。しかし、モデルとデータの規模が増加し続けると、効率と次のような関係があることがわかります。上の図に示すように、データの規模とモデルの規模が増加すると、対応する「期間」はどんどん長くなっていきます。この「期間」は、効率に反映されるオフラインレベルに対応し、レイテンシに反映されるオンラインレベルに対応します。そして私たちの仕事は、この「期間」の最適化を中心に行われます。テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

2 分析

通常の小規模モデルと比較して、大規模モデルの中核的な問題は次のとおりです。データ量とモデルの規模が数十倍に増加するためです。たとえ 100 回であっても、リンク全体のストレージ、通信、コンピューティングなどは新たな課題に直面し、アルゴリズムのオフライン反復効率に影響を及ぼします。オンライン遅延の制約など一連の問題をどうやって突破するのか？以下に示すように、まずリンク全体を分析してみましょう:

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

「期間」が長くなり、これは主に次の側面に反映されます:

オンライン遅延: 機能レベルでは、オンラインリクエストが変更されていない場合、機能の数が増加すると IO と機能の計算時間が発生します。増加などの問題は特に顕著であり、特徴演算子の分析とコンパイル、特徴抽出の内部タスクのスケジューリング、ネットワーク I/O 送信などの側面での再構築が必要です。モデルレベルでは、モデルは数百 M/G から数百 G に変更され、ストレージが 2 桁増加しました。さらに、単一モデルの計算量も桁違いに増加しました (FLOP は数百万から今では数千万に増加しました)。 CPU だけではこの大きな問題を解決することはできず、コンピューティング能力の需要により、大規模な深層学習推論をサポートする CPU GPU 階層キャッシュ推論アーキテクチャを構築することが不可欠です。
: サンプルと特徴の数が数倍に増加すると、サンプルの構築とモデルのトレーニングにかかる時間が大幅に長くなります。 . 受け入れられなくなる可能性もあります。限られたリソースで大規模なサンプルの構築とモデルのトレーニングをどのように解決するかが、システムの主な問題です。データレベルでは、業界は一般に 2 つのレベルで問題を解決します。一方では、バッチ処理プロセスの制約を継続的に最適化します。他方では、集中型から分散型までデータの「バッチをストリームに変換」します。、データの効率が大幅に向上します。準備完了です。トレーニングレベルでは、アーキテクチャレベルの最適化と組み合わせたハードウェア GPU によって高速化が実現されます。第 2 に、アルゴリズムの革新は多くの場合、人によって推進されます。新しいデータをどのようにしてモデルにすばやく一致させることができますか? 新しいモデルを他のビジネスで迅速に適用するにはどうすればよいでしょうか? 同じ最適化を独立して実行するために N 人の事業ラインに N 人が配置されれば、アルゴリズムは進化します1 つの事業ラインを最適化し、同時に N 事業ラインにブロードキャストすることで、N-1 人員が新たなイノベーションを行うために解放され、特にモデル全体の規模が変化した場合に、イノベーションサイクルが大幅に短縮されます。必然的に手動の反復コストが増加し、「人が機能/モデルを見つける」から「機能/モデルが人を見つける」への大幅な変革が達成され、「反復的なイノベーション」が削減され、モデルとデータのインテリジェントなマッチングが実現されます。
: 機械学習パイプラインは大規模な深層学習モデルのリンクに固有のものではありませんが、大規模なモデルのロールアウトでは、次のような問題が発生します。 ① システムプロセスが完全および増分オンライン展開をどのようにサポートするか、② モデルのロールバック時間、物事を正しく行うための時間、間違ったことを行った後の回復時間などの新たな課題。つまり、開発、テスト、展開、監視、ロールバックなどで新たな需要が発生します。

モデル推論、機能サービス)、オフライン効率 () に焦点を当てています。サンプル構築とデータ準備の 2 つの側面から実施されます。)、大規模なディープモデルでの広告のエンジニアリング実践を段階的に説明します。「期間」を最適化する方法とその他の関連する問題については、後続の章で説明しますので、お楽しみに。 3 モデル推論

モデル推論レベルでは、テイクアウト広告は、ニッチスケールをサポートする DNN モデルに代表される 1.0 時代から、 2.0 時代では、高効率かつ低コードでマルチサービスの反復をサポートしていましたが、3.0 時代では、ディープラーニング DNN のコンピューティング能力と大規模ストレージのニーズに徐々に直面しています。主な進化の傾向を次の図に示します。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践大規模なモデル推論シナリオに直面すると、3.0 アーキテクチャによって解決される 2 つの中心的な問題は、「ストレージの問題」と「パフォーマンス」です。問題"。もちろん、N数百Gのモデルをどのように反復するか、計算負荷が数十倍に増加した場合にオンラインの安定性をどのように確保するか、パイプラインをどのように強化するかなどもプロジェクトが直面する課題です。以下では、Model Inference 3.0 アーキテクチャが「分散」を通じて大規模なモデルストレージの問題をどのように解決するか、また CPU/GPU アクセラレーションを通じてパフォーマンスとスループットの問題を解決する方法に焦点を当てます。

3.1 分散

大規模モデルのパラメータは主に、疎パラメータと密パラメータの 2 つの部分に分かれています。

スパースパラメータ: パラメータの大きさは非常に大きく、通常は10億レベル、さらには10億/数百億レベルに達します。大規模なストレージスペースの使用量。通常は 100G レベル、さらには T レベルに達します。その特徴: ① スタンドアロンロードの難しさ: スタンドアロンモードでは、すべての Sparse パラメータをマシンのメモリにロードする必要があるため、深刻なメモリ不足が発生し、安定性と反復効率に影響します; ② Sparse の読み取り: Sparse の一部のみパラメータは、推論計算ごとに読み取る必要があります。たとえば、ユーザーパラメーターの全量は 2 億レベルですが、各推論リクエストで読み取る必要があるユーザーパラメーターは 1 つだけです。
高密度パラメータ: パラメータのスケールは大きくなく、モデルは通常 2 ～ 3 層で完全に接続されており、パラメータの大きさは 100 万分の 1 です。ミリオンレベル。特徴: ① 単体マシンロード可能: 高密度パラメータは数十メガバイト程度を占有しますが、単体マシンメモリは通常ロード可能例: 入力層は 2000、全結合層は [1024, 512, 256]、合計パラメータは: 2000 * 1024 1024 * 512 512 * 256 256 = 2703616、合計 270 万パラメータ、占有メモリは 100 メガバイト以内; ② 完全読み取り: 各推論計算について、完全なパラメータを読み取る必要があります。。

したがって、モデルパラメーターのスケールが大きくなるという問題を解決する鍵は、スパースパラメーターを単一コンピューターのストレージから分散ストレージに変換することです。変換方法には 2 つの部分が含まれます。 ① モデルネットワーク構造変換;② スパースパラメータをエクスポートします。

3.1.1 モデルネットワーク構造の変換

業界では、分散パラメータを取得するには大きく 2 つの方法があります。外部サービスが事前にパラメータを取得し、それを外部サービスに渡すことです。推定サービス ; 推定サービスは、TF (TensorFlow) 演算子を変換することにより、分散ストレージからパラメータを内部的に取得します。アーキテクチャ変更のコストを削減し、既存のモデル構造への侵入を減らすために、TF オペレーターを変更して分散パラメーターを取得することを選択しました。

通常の状況では、TF モデルはネイティブオペレーターを使用してスパースパラメーターを読み取ります。コアオペレーターは GatherV2 オペレーターです。オペレーターの入力は主に 2 つの部分で構成されます: ① 必要なクエリ ID list; ② Sparseパラメータを格納する埋め込みテーブル。

演算子の機能は、ID リストのインデックスに対応する Embedding データを Embedding テーブルから読み取って返すことであり、本質的にはハッシュクエリの処理です。このうち、Embedding テーブルに格納される Sparse パラメータは、単機モデルではすべて単機メモリに格納されます。

TF オペレーターの変換は本質的にモデルネットワーク構造の変換であり、変換の核心は主に 2 つの部分で構成されます: ① ネットワークグラフの再構築、② カスタム分散オペレーター。

1. ネットワークダイアグラムの再構築: モデルネットワーク構造を変換し、ネイティブ TF オペレーターをカスタム分散オペレーターに置き換え、ネイティブエンベディングテーブルの変更を実行します。同時に固まります。

分散オペレータの置換: モデルネットワークを横断し、置換する必要がある GatherV2 オペレータをカスタムの分散オペレータに置き換えます。オペレーター MtGatherV2 は、上流ノードと下流ノードの入出力を同時に変更します。
ネイティブエンベディングテーブルの固定化: ネイティブエンベディングテーブルはプレースホルダーとして固定化され、モデルネットワーク構造の整合性を維持できるだけでなく、占有も回避できます。スパースパラメータによる単一マシンメモリの。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践 2. カスタム分散演算子: ID リストに基づいてクエリを変換するプロセスは、ローカルの Embedding テーブルからのクエリから分散 KV からのクエリに変更されます。

リクエストクエリ: 入力 ID を重複排除してクエリ量を削減し、シャーディングを通じて 2 次キャッシュを同時にクエリします ( ローカルキャッシュリモート KV) 埋め込みベクトルを取得します。
モデル管理: モデルの埋め込みメタの登録とアンインストールのプロセス、およびキャッシュ関数の作成と破棄を維持します。
モデルのデプロイメント: モデルのリソース情報のロードと、埋め込みデータを KV に並行インポートするプロセスをトリガーします。

3.1.2 スパースパラメーターエクスポート

シャード並列エクスポート: 解析モデルチェックポイントファイル、Embedding テーブルに対応するパーツ情報を取得し、パーツごとに分割し、複数のワーカーノードを介して各パーツファイルを並行して HDFS にエクスポートします。
KV のインポート: 事前に複数のバケットを事前に割り当てます。バケットには、オンラインルーティングクエリを容易にするために、モデルのバージョンなどの情報が保存されます。同時に、モデルの埋め込みデータもバケットに保存され、シャーディングに基づいて並行して KV にインポートされます。

全体的なプロセスは次の図に示されており、オフラインの分散モデル構造変換、ニアラインデータの一貫性保証、オンラインホットスポットデータを通じて数百ギガバイトのデータを保証します。キャッシュ: モデルの通常の反復要件。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

#分散ストレージによって使用されるストレージは外部 KV 機能であり、より効率的で柔軟な機能に置き換えられることがわかります。将来的には管理が容易な埋め込みサービス。

3.2 CPU アクセラレーション

モデル自体の最適化方法に加えて、主に一般的な CPU アクセラレーション方法が 2 つあります。 ① AVX2 を使用した命令セットの最適化。 , AVX512命令セット; ②アクセラレーションライブラリ（TVM、OpenVINO）を使用します。

命令セットの最適化: TensorFlow モデルを使用する場合は、TensorFlow フレームワークコードをコンパイルするときに、命令を直接コンパイルオプション最適化項目を設定するだけです。 AVX2 および AVX512 命令セットの導入には明らかな最適化効果があり、オンライン推論サービスのスループットが 30% 向上したことが実際に証明されています。
アクセラレーションライブラリの最適化: アクセラレーションライブラリは、ネットワークモデル構造を最適化および統合して、推論高速化効果を実現します。業界で一般的に使用されている高速化ライブラリには TVM や OpenVINO などがあり、その中でも TVM はクロスプラットフォームをサポートしており、汎用性に優れています。 OpenVINOはIntelメーカーのハードウェアに特化して最適化されており、汎用性がありながら高速化効果が優れています。

以下では、CPU アクセラレーションに OpenVINO を使用した実際の経験の一部に焦点を当てます。 OpenVINO は、Intel が発表した深層学習ベースのコンピューティングアクセラレーション最適化フレームワークのセットで、圧縮の最適化、アクセラレーションコンピューティング、および機械学習モデルのその他の機能をサポートします。 OpenVINO の高速化原理は、線形演算子融合とデータ精度校正の 2 つの部分に簡単に要約されます。

線形演算子の融合: OpenVINO は、モデルオプティマイザーを使用して、モデルネットワーク内の多層演算子を線形 Fusion に統合します。 3 つの Conv BN Relu 演算子を CBR 構造演算子にマージするなど、演算子のスケジューリングオーバーヘッドと演算子間のデータメモリアクセスのオーバーヘッドを削減します。
データ精度の調整: モデルがオフラインでトレーニングされた後は、推論プロセス中にバックプロパゲーションが必要ないため、データ精度を適切に下げることができます。 FP16 または INT8 精度に関しては、メモリフットプリントが小さくなり、推論レイテンシが低くなります。

#CPU アクセラレーションにより、通常、固定バッチ候補キューの推論が高速化されますが、検索プロモーションシナリオでは、候補キューは動的であることがよくあります。これは、モデル推論の前に、バッチマッチング操作を追加する必要があることを意味します。つまり、要求された動的バッチ候補キューは、それに最も近いバッチモデルにマップされますが、これには N 個のマッチングモデルを構築する必要があり、結果としてメモリ使用量が N 倍になります。。現在のモデルの容量は数百ギガバイトに達しており、メモリが非常に不足しています。したがって、高速化のために合理的なネットワーク構造を選択することは、考慮する必要がある重要な問題です。次の図は、全体的な動作アーキテクチャです: テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

ネットワーク分散: CTR モデルの全体的なネットワーク構造は、エンベディング層、アテンション層、MLP 層の 3 つの部分に抽象化されます。埋め込み層はデータ取得に使用され、アテンション層にはより多くの論理演算と軽量のネットワーク計算が含まれ、MLP 層には高密度のネットワーク計算が含まれます。
アクセラレーションネットワークの選択: OpenVINO は、純粋なネットワークコンピューティングに対して優れたアクセラレーション効果を備えており、MLP レイヤーに適切に適用できます。さらに、モデルデータのほとんどは埋め込み層に保存され、MLP 層が占有するメモリは数十メガバイトのみです。 MLP層ネットワークを複数のバッチに分割した場合、モデルのメモリ占有量は最適化前(Embedding Attendance MLP)≒最適化後(Embedding Attendance MLP×バッチ番号)となります。影響は小さくなります。したがって、最終的にモデル加速ネットワークとして MLP 層ネットワークを選択しました。

現在、OpenVINO に基づく CPU アクセラレーションソリューションは実稼働環境で良好な結果を達成しています。CPU がベースラインと同じ場合、サービススループットは 1 倍向上します。 40%、平均遅延は 15% 減少します。 CPU レベルで高速化を行いたい場合は、OpenVINO が良い選択です。

3.3 GPU アクセラレーション

ビジネスの発展に伴い、ビジネス形態はますます豊富になり、トラフィックはますます増大し、モデルはますます増加しています。消費電力が急激に増加する一方で、広告シーンでは主に DNN モデルが使用され、多数のスパースな特徴の埋め込みとニューラルネットワークの浮動小数点演算が含まれます。メモリアクセスとコンピューティング集約型のオンラインサービスとして、可用性を確保しながら低遅延と高スループットの要件を満たす必要がありますが、これは単一マシンのコンピューティング能力に対する課題でもあります。コンピューティングリソース要件とスペースの間の矛盾がうまく解決されないと、ビジネス開発が大幅に制限されてしまいます。モデルが拡張され深化される前は、純粋な CPU 推論サービスでかなりのスループットを提供できますが、モデルが拡張され深化されると、計算は次のようになります。高可用性を確保するには、大量のマシンリソースを消費する必要があるため、大規模なモデルをオンラインで大規模に適用できなくなります。現在、業界で一般的な解決策は GPU を使用してこの問題を解決することであり、GPU 自体はコンピューティング集約型のタスクにより適しています。 GPU を使用するには、可用性と低遅延を確保しながら、使いやすさと汎用性も考慮しながら、可能な限り高いスループットを達成する方法という課題を解決する必要があります。この目的を達成するために、TensorFlow-GPU、TensorFlow-TensorRT、TensorRT などの GPU についても多くの実践的な作業を行ってきました。TF の柔軟性と TensorRT の加速効果を考慮するために、 TensorFlow と TensorRT の独立した 2 段階のアーキテクチャ設計。

3.3.1 加速分析

ヘテロジニアスコンピューティング: 私たちのアイデアは、CPU アクセラレーション、200G ディープラーニング CTR と一致しています。このモデルでは、 GPU に直接配置されます。メモリを大量に消費する演算子が適しています (埋め込み関連の操作など )。CPU および計算を大量に消費する演算子 (#) ##たとえば、MLP#) は GPU に適しています。
GPU を使用する際に注意すべきいくつかの点 #: ① メモリとビデオメモリ間の頻繁な相互作用; ② レイテンシとスループット; ③ パフォーマンスの最適化とのスケーラビリティのトレードオフ; ④ GPU の使用率。
推論エンジンの選択: 業界で一般的に使用されている推論高速化エンジンには、TensorRT、TVM、XLA、ONNXRuntime などが含まれます。オペレータの最適化が得意です。他のエンジンよりも詳細で、カスタマイズされたプラグインを通じて任意のオペレータを実装でき、拡張性が高くなります。さらに、TensorRT は一般的な学習プラットフォーム (Caffe、PyTorch、TensorFlow など) のモデルをサポートしており、その周辺環境はますます充実しています (##) #モデル変換ツール onnx-tensorrt、性能解析ツール nsys など #) のため、GPU 側の高速化エンジンは TensorRT を使用します。モデル分析: CTR モデルのネットワーク構造の全体的な抽象化は、エンベディング層、アテンション層、MLP 層の 3 つの部分に分かれています。エンベディング層が使用されます。データ取得に適しており、CPU に適しています。アテンション層にはより多くの論理演算と軽量のネットワーク計算が含まれていますが、MLP 層はネットワーク計算に焦点を当てており、これらの計算は並列実行でき、GPU に適しており、GPU を最大限に活用できます。コア (Cuda Core、Tensor Core)、並列度を向上させます。
3.3.2 最適化の目標ディープラーニングの推論フェーズでは、コンピューティング能力とレイテンシに関して高い要件が求められます。推論側では、計算能力の不足や推論時間が長いなどの問題が発生する可能性があります。したがって、トレーニングされたニューラルネットワークに対して特定の最適化を実行する必要があります。業界におけるニューラルネットワークモデルの最適化に関する一般的な考え方は、モデルの圧縮、異なるネットワーク層の結合、スパース化、低精度データ型の使用など、さまざまな側面から最適化できます。ハードウェアの特性。この目的を達成するために、主に次の 2 つの目標を中心に最適化します:

遅延とリソースの制約下でのスループット: レジスタやキャッシュなどの共有リソースが競合する必要がない場合、同時実行性を高めることでリソース使用率 (CPU、GPU) を効果的に改善できます。およびその他の使用法)、ただし、これによりリクエストのレイテンシが増加する可能性があります。オンラインシステムの遅延制限は非常に厳しいため、オンラインシステムのスループット上限はリソース使用率指標で単純に換算することはできず、遅延制約のもとで総合的に評価し、リソース上限と組み合わせる必要があります。システムの遅延が短く、リソース (メモリ/CPU/GPU など) の使用率が制約となる場合、モデルの最適化によってリソースの使用率を削減できます。システムリソースの使用率が低く、レイテンシが制約となっている場合、フュージョンの最適化とエンジンの最適化によってレイテンシを短縮できます。上記のさまざまな最適化方法を組み合わせることで、システムサービスの総合的な機能を効果的に向上させることができ、システムのスループットを向上させるという目的を達成できます。計算制約下での計算密度: CPU/GPU 異種システムでは、モデル推論のパフォーマンスは主にデータコピーの効率と計算の効率に影響され、それぞれメモリアクセスを集中させるオペレーターによって制御されます。データコピーの効率は、計算量の多いオペレータによって決定され、PCIe データ転送、CPU/GPU メモリの読み書きなどの効率に影響されます。計算効率は、CPU コア、CUDA などのさまざまな計算ユニットの計算効率に影響されます。コア、および Tensor コア。 GPUなどのハードウェアの急速な発展に伴い、コンピューティング集約型オペレータの処理能力が急速に向上し、その結果、メモリ集約型オペレータがシステムサービス能力の向上を妨げる現象がますます顕著になってきています。また、システムサービス機能にとって、コンピューティング密度の重要性もますます高まっています。つまり、モデルの計算量があまり変わらない場合のデータコピーとカーネル起動の削減です。たとえば、モデルの最適化と融合の最適化は演算子変換 (
) の使用を減らすために使用され、CUDA グラフはカーネルの起動などを減らすために使用されます。

モデル最適化

、融合最適化、について詳しく紹介します。エンジンの最適化 いくつかの作業が完了しました。 3.3.3 モデルの最適化

1. 計算と送信の重複排除: 推論中、同じバッチには 1 つのユーザー情報のみが含まれます。したがって、推論前にユーザー情報をバッチサイズから 1 に削減し、実際に推論が必要なときに拡張して、データ送信のコピーと反復計算のコストを削減できます。次の図に示すように、推論前にユーザークラスの機能情報を 1 回だけクエリし、ユーザー関連のサブネットワークのみでその情報をプルーニングし、関連付けを計算する必要があるときに展開することができます。

#自動プロセス: 繰り返し計算されたノード (

#赤いノード) を見つけます。 )、ノードのすべてのリーフノードが繰り返し計算ノードである場合、そのノードも繰り返し計算ノードであり、すべての繰り返しノードは、ノードのトラバーサル後までリーフノードからレイヤーごとに上向きに検索され、検索して、すべての赤と白のノードの接続線を見つけ、ユーザー機能拡張ノードを挿入して、ユーザー機能を展開します。

#2. データ精度の最適化テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

: 原因学習時は勾配更新のためバックプロパゲーションが必要となり高いデータ精度が要求されますが、モデル推論時は勾配更新を行わずに順推論のみを行うため、効果を確保することを前提にFP16や混合精度を使用します。メモリ領域を節約するための最適化に使用され、送信オーバーヘッドが削減され、推論パフォーマンスとスループットが向上します。 #3. 計算プッシュダウン

: CTR モデルの構造は主に、Embedding、Attention、MLP の 3 つの層で構成されます。部分データです。アテンションは部分的に論理的であり、部分的に計算的です。GPU の可能性を最大限に活用するために、CTR モデル構造におけるアテンションと MLP の計算ロジックの大部分は、計算のために CPU から GPU に移動され、全体的なスループットが大幅に向上します。

3.3.4 Fusion Optimization

オンラインモデル推論中、各層の計算操作は GPU によって完了します。実際には、CPU は異なる CUDA カーネルを起動することによって計算を完了します。CUDA カーネルテンソルの計算は非常に高速ですが、CUDA カーネルの起動と各層の入出力テンソルの読み取りと書き込みに多くの時間が浪費されることが多く、メモリ帯域幅のボトルネックと GPU リソースの無駄が発生します。ここでは主に TensorRT の 自動最適化 と 手動最適化 の部分を紹介します。 1. 自動最適化: TensorRT は、ディープラーニングアプリケーションに低レイテンシー、高スループットの推論展開を提供できる、高性能のディープラーニング推論オプティマイザーです。 TensorRT を使用すると、非常に大規模なモデル、組み込みプラットフォーム、自動運転プラットフォームの推論を高速化できます。 TensorRT は、TensorFlow、Caffe、MXNet、PyTorch などのほぼすべての深層学習フレームワークをサポートできるようになり、TensorRT と NVIDIA GPU を組み合わせることで、ほぼすべてのフレームワークでの高速かつ効率的なデプロイと推論が可能になります。また、一部のレイヤー融合やカーネル自動チューニングなど、一部の最適化ではユーザーの参加をあまり必要としません。

レイヤー融合: TensorRT は、レイヤー間を水平または垂直にマージすることで、ネットワーク層の数を大幅に削減します。データ循環の数、ビデオメモリの頻繁な使用、およびスケジューリングのオーバーヘッドを削減するために、計算処理を実行するか、いくつかの冗長な処理を削除します。たとえば、一般的なネットワーク構造には、Convolution And ElementWise Operation 融合、CBR 融合などが含まれます。次の図は、融合前後のネットワーク構造全体の一部のサブグラフの構造図です。FusedNewOP には、融合プロセス中にさまざまな戦術が含まれる場合があります。 CudnnMLPFC、CudnnMLPMM、CudaMLP など。最終的に、持続時間に基づいて最適な戦術が融合構造として選択されます。融合操作により、ネットワーク層の数が減り、データチャネルが短くなり、同じ構造をマージしてデータチャネルを広くし、GPU リソースをより効率的に使用するという目的を達成します。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

カーネル自動チューニング: ネットワークモデルが推論中に、CUDA カーネルを呼び出します。 GPUの計算。 TensorRT は、さまざまなネットワークモデル、グラフィックスカードの構造、SM の数、コア周波数などに合わせて CUDA カーネルを調整し、さまざまな最適化戦略と計算方法を選択し、現在の状況に適した最適な計算方法を見つけて、現在のモデルが確実に特定のプラットフォームで最良の結果が得られ、優れたパフォーマンスが得られます。上の図は最適化の主なアイデアです。各演算には複数のカーネル最適化戦略 (cuDNN、cuBLAS など。) があります。現在のアーキテクチャによれば、非効率なカーネルはすべての最適化戦略からフィルタリングされ、同時に最適なカーネルを選択し、最後に新しいネットワークを形成します。

2. 手動最適化: ご存知のとおり、GPU は計算集約型の用途に適しています。他のタイプの演算子 (軽量計算演算子、論理演算演算子など ) はあまり使いやすいものではありません。 GPU 計算を使用する場合、各操作は通常、CPU が GPU にビデオメモリを割り当てる -> CPU が GPU にデータを送信する -> CPU が CUDA カーネルを開始する -> CPU がデータを取得する -> CPU が GPU ビデオメモリを解放するという複数のプロセスを経ます。スケジューリング、カーネルの起動、メモリアクセスなどのオーバーヘッドを削減するには、ネットワークの統合が必要です。 CTR大規模モデルは柔軟で変更可能な構造のため、ネットワーク融合手法を統一することが難しく、特定の問題のみを詳細に分析できます。例えば、垂直方向には Cast、Unsqueeze、Less が融合され、TensorRT 内部の Conv、BN、Relu が融合され、水平方向には同じ次元の入力演算子が融合されます。この目的を達成するために、NVIDIA 関連のパフォーマンス分析ツール (NVIDIA Nsight Systems、NVIDIA Nsight Compute など ) を使用して、実際のオンラインビジネスシナリオに基づいて特定の問題を分析します。これらのパフォーマンス分析ツールをオンライン推論環境に統合して、推論プロセス中に GPU プロフィングファイルを取得します。 Profing ファイルを通じて、推論プロセスを明確に確認できます。図に示すように、推論全体における一部の演算子のカーネル起動限界現象が深刻で、一部の演算子間のギャップが大きく、最適化の余地があることがわかりました。次の図:

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

そのためには、パフォーマンス分析ツールと変換されたモデルに基づいてネットワーク全体を分析し、TensorRT が最適化した部分を見つけて、最適化できるネットワーク内の他の部分構造に対してネットワーク統合を実行します。また、この下部構造がネットワーク全体で一定の割合を占めることを保証し、融合後にコンピューティング密度がある程度まで増加することを保証します。どのようなネットワーク統合手法を使用するかについては、シナリオに応じて柔軟に利用できますが、統合前と統合後の部分構造図の比較は次の図のようになります。 #3.3 .5 エンジンの最適化

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

複数のモデル

: テイクアウト広告におけるユーザーリクエストの規模が不確実であるため、広告場合によっては多い場合と少ない場合があるため、より多くロードします各モデルは異なる入力のバッチに対応します入力スケールはバケットに分割され、複数の固定バッチにパディングされます同時に、推論のために対応するモデルにマッピングされます。マルチコンテキストとマルチストリーム: 各バッチモデルで、マルチコンテキストとマルチストリームを使用すると、待機中のモデルのオーバーヘッドを回避できるだけでなく、同じコンテキストだけでなく、複数のストリームの同時実行性を最大限に活用してストリーム間のオーバーラップを実現すると同時に、リソース競合の問題をより適切に解決するために CAS が導入されています。次の図に示すように、単一のストリームが複数のストリームになります。

Dynamic Shape テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

CUDA グラフ: 最新の GPU の各操作 (カーネルの実行など) にかかる時間は少なくともマイクロ秒レベルであり、 GPU に送信される各操作も、ある程度のオーバーヘッド (
) を生成します。実際の推論では、多くのカーネル操作を実行する必要があることがよくあります。これらの操作はそれぞれ個別に GPU に送信され、独立して計算されます。すべての送信起動のオーバーヘッドをまとめて集計できれば、全体的な改善がもたらされるはずです。パフォーマンスで。 CUDA Graph は、コンピューティングプロセス全体を個々の操作のリストではなくグラフとして定義し、単一の CPU 操作がグラフ上で複数の GPU 操作を起動するメソッドを提供することで、カーネル送信起動のオーバーヘッドを削減することでこれを実現します。 CUDA Graph の中心となるアイデアは、カーネルの起動回数を減らすことです。推論の前後でグラフをキャプチャし、推論のニーズに応じてグラフを更新することで、以降の推論では次々にカーネルを起動する必要がなくなり、グラフのみが作成されます。カーネルの起動が必要になり、最終的にはカーネルの起動数が減ります。以下の図に示すように、1 つの推論で 4 つのカーネル関連の操作が実行されますが、最適化の効果は CUDA グラフを使用することで明確に確認できます。

マルチレベル PS

: GPU アクセラレーションエンジンのパフォーマンスをさらに調査するため、埋め込みデータをクエリします。この操作は、マルチレベル PS: GPU メモリキャッシュ -> CPU メモリキャッシュ -> ローカル SSD/分散 KV を通じて実行できます。その中で、ホットスポットデータは GPU メモリにキャッシュでき、キャッシュされたデータはデータホットスポットの移行、昇格、削除などのメカニズムを通じて動的に更新され、GPU の並列計算能力とメモリアクセス機能を最大限に活用して効率的なクエリを実行できます。。オフラインテスト後、GPU キャッシュのクエリパフォーマンスは CPU キャッシュの 10 倍です。GPU キャッシュのミスデータについては、CPU キャッシュにアクセスしてクエリできます。2 レベルのキャッシュはデータアクセスの 90% を満たすことができます。ロングテールリクエストの場合、データ取得のために Access 分散 KV を渡す必要があります。具体的な構造は次のとおりです。テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

##3.3.6 パイプライン

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

#パイプラインの構築には、オフラインモデルの分割と変換プロセス、およびオンラインモデルデプロイメントプロセスの 2 つの部分が含まれます。

##オフライン側: モデル分割ノードを提供するだけで、プラットフォームは元の TF モデルを埋め込みサブモデルと計算グラフサブモデルに自動的に分割します。埋め込みサブモデルは、分散コンバーターを通じて分散コンピューティングを実行します。サブ置換と埋め込みインポート作業。計算グラフサブモデルは、選択したハードウェア環境 (GPU モデル、TensorRT バージョン、CUDA バージョン ) に従って TensorRT モデルの変換とコンパイルの最適化を実行し、最終的に変換します。 2 つのサブモデル結果は、後続のモデル展開およびオンラインのために S3 に保存されます。プロセス全体は、ユーザーが実行の詳細を意識することなく、プラットフォームによって自動的に完了します。
オンラインテスト: モデルデプロイメントハードウェア環境を選択するだけで (モデル変換の環境と一致するようにしてください)、プラットフォームが構成されます環境に応じて、モデルのアダプティブプッシュロードを実行し、ワンクリックでモデルの展開とオンライン展開を完了します。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践 4 機能サービス CodeGen の最適化

美団テイクアウト特徴プラットフォームの構築と実践では、モデル特徴自己記述MFDLに基づく特徴計算について説明しました。このプロセスは、オンライン推定およびオフライントレーニング中にサンプルの一貫性を確保するように構成されています。ビジネスの反復が急速に進むにつれて、モデルの特徴の数は増加し続けており、特に多数の個別の特徴を導入する大規模なモデルでは、計算量が 2 倍になります。この目的を達成するために、特徴抽出レイヤーにいくつかの最適化を行い、スループットと消費時間の大幅な向上を達成しました。 4.1 フルプロセス CodeGen の最適化

Spark の WholeStageCodeGen を利用する私たちの目標は、特徴計算 DSL 全体を実行可能なメソッドにコンパイルし、それによってコード実行時のパフォーマンスの損失を軽減することです。コンパイルプロセス全体は、フロントエンド (FrontEnd)、オプティマイザー (Optimizer)、およびバックエンド (BackEnd) に分けることができます。フロントエンドは主に、ターゲット DSL の解析とソースコードの AST または IR への変換を担当します。オプティマイザは、フロントエンドに基づいて取得した中間コードを最適化し、コードをより効率的にします。バックエンドは、最適化された中間コードを変換します。コードをそれぞれのプラットフォームのネイティブコードに変換します。具体的な実装は次のとおりです。

フロントエンド : 各モデルはノード DAG グラフに対応し、各特徴を 1 つずつ解析し、DSL を計算します。、AST を生成し、AST ノードがグラフに追加されます。
Optimizer: パブリック演算子の抽出、定数の折りたたみなど、DAG ノードを最適化します。
バックエンド: 最適化されたグラフをバイトコードにコンパイルします。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

最適化後のノード DAG グラフの変換、つまりバックエンドコードの実装によって、最終的なパフォーマンスが決まります。困難の 1 つは、既存のオープンソース式エンジンを直接使用できない理由でもあります。特徴計算 DSL は純粋な計算式ではありません。読み取り演算子と変換演算子の組み合わせにより、特徴の取得と処理のプロセスを記述することができます。

読み取り演算子: ストレージからシステムのプロセス機能の取得は IO タイプのタスクです。たとえば、リモート KV システムにクエリを実行します。
変換演算子: ローカルで取得した特徴量の変換は、大量の計算を必要とするタスクです。たとえば、特徴値をハッシュします。

したがって、実際の実装では、さまざまな種類のタスクのスケジュールを考慮し、マシンリソースの使用率を最大化し、時間のかかるプロセス全体を最適化する必要があります。業界調査と独自の実践を組み合わせて、次の 3 つの実装が実行されました:

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

タスクタイプに基づいてステージを分割する: プロセス全体を取得と計算の 2 つのステージに分割し、ステージの内部シャーディングは並列処理されます。 , 前のステージが完了したら、次のステージを実行します。これは私たちが初期に使用したソリューションです。実装は簡単で、さまざまなタスクタイプに基づいてさまざまなシャードサイズを選択できます。たとえば、IO タイプのタスクではより大きなシャードを使用できます。しかし、さまざまな段階のロングテールが重なり、各段階のロングテールがプロセス全体の時間に影響を与えるという欠点も明らかです。
パイプラインに基づいてステージを分割する: さまざまなステージのロングテールの重ね合わせを減らすために、まずデータを断片化し、機能ごとに読み取ります。シャードを取得し、IO タスクの完了後にコンピューティングタスクをコールバックするコールバックを追加することで、プロセス全体が組み立てラインのようにスムーズになります。シャードのスケジューリングにより、前のステージの準備が早く完了したシャードが事前に次のステージに入ることができるため、待ち時間が短縮され、全体のリクエスト時間のロングテールが短縮されます。ただし、シャードサイズを統一しても各ステージの使用率を完全には改善できないという欠点があり、シャードが小さいと IO タスクのネットワーク消費量が増加し、シャードが大きいとコンピューティングタスクの時間消費が増加します。
SEDA (段階的イベント駆動型アーキテクチャ) アプローチに基づく: 段階的イベント駆動型アプローチでは、キューを使用してステージの取得と計算ステージを分離し、各ステージは独立したスレッドプールとバッチ処理キューは、毎回 N (バッチ係数) 要素を消費します。これにより、各ステージが個別にシャードサイズを選択できるようになり、イベント駆動型モデルによりプロセスをスムーズに保つこともできます。これが私たちが現在模索していることです。

CodeGen ソリューションは完璧ではありません。動的に生成されたコードはコードの可読性を低下させ、デバッグのコストを増加させます。ただし、CodeGen をアダプテーションレイヤーとして使用すると、より詳細なソリューションも提供されます。最適化によりスペースが広がります。 CodeGen と非同期ノンブロッキング実装に基づいて、時間のかかる特徴量計算を削減する一方で、CPU 負荷を大幅に軽減し、システムスループットを向上させるなど、オンラインでの優れたメリットが得られています。今後も CodeGen を活用し、ハードウェア命令 (SIMD など) やヘテロジニアスコンピューティング (## など) の組み合わせを検討するなど、バックエンドのコンパイルプロセスで的を絞った最適化を実行していきます。 #GPU など) を使用して、より詳細な最適化を行います。

オンライン予測サービスは全体として 2 層のアーキテクチャを持ち、特徴抽出層はモデルのルーティングと特徴の計算を担当し、モデル計算層はモデルの計算を担当します。本来のシステムの処理は、特徴量計算の結果を M (予測バッチサイズ ) × N (サンプル幅 ) の行列に結合し、シリアル化して計算に送信することです。層です。この理由は、一方では歴史的な理由です。多くの初期の非 DNN 単純モデルの入力形式は行列です。ルーティング層が結合された後は、コンピューティング層は変換せずに直接使用できます。他方では、、配列形式は比較的コンパクトで、ネットワーク送信の時間を節約できます。テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践しかし、モデルの反復開発により、DNN モデルが徐々に主流になってきており、行列伝送の欠点も非常に明白です:

スケーラビリティが低い: データ形式が統一されており、数値以外の特性値と互換性がありません。
伝送パフォーマンスの損失: マトリックス形式に基づいて、機能を調整する必要があります。たとえば、クエリ/ユーザーディメンションをコピーして、それぞれに調整する必要があります。増加する項目コンピューティング層にネットワーク送信データ量を要求します。

上記の問題を解決するために、最適化されたプロセスでは、伝送層の上に変換層を追加し、MDFL の構成に従って、計算されたモデルの特徴を必要な特徴に変換します。 . オフラインで使用するための Tensor、行列、CSV 形式などの形式。テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践実際のオンラインモデルのほとんどは TF モデルです。伝送消費をさらに節約するために、プラットフォームは各 Tensor 行列を保存する Tensor Sequence 形式を設計しました。その中で、r_flag は、それがあるかどうかをマークするために使用されます。は項目クラスの特徴です。長さは項目特徴の長さを表します。値は M (項目の数 ) × NF (特徴の長さ ) です。データは、実際の特徴値、アイテム特徴の場合、M 特徴値はフラットに格納され、リクエストタイプの特徴は直接埋められます。コンパクトな Tensor Sequence 形式に基づいて、データ構造がよりコンパクトになり、ネットワーク上で送信されるデータ量が削減されます。最適化された伝送フォーマットにより、オンラインでも良好な結果が得られ、コンピューティング層を呼び出すルーティング層のリクエストサイズが 50% 削減され、ネットワーク伝送時間が大幅に短縮されました。

4.3 高次元 ID 特徴エンコーディング

離散特徴と系列特徴を Sparse 特徴に統合でき、特徴処理段階では元の特徴をハッシュ処理しますID クラスの機能に変わりました。数千億次元の機能に直面すると、文字列の連結とハッシュのプロセスでは、式スペースとパフォーマンスの観点から要件を満たすことができません。業界調査に基づいて、スロットコーディングに基づく特徴エンコード形式を設計して適用しました。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

その中で、feature_hash は、ハッシュ後の元の特徴値です。後の値。整数特徴は直接埋めることができます。非整数特徴または交差特徴は、最初にハッシュされてから埋められます。数値が 44 ビットを超える場合、切り捨てられます。スロットコーディングスキームの導入後、オンライン特徴計算のパフォーマンスが向上しただけでなく、モデル効果も大幅に向上しました。

5 サンプルの構築

5.1 ストリーミングサンプル

オンラインとオフラインの一貫性の問題を解決するために、業界は一般に、オンラインダンプのリアルタイムスコアリングで使用されるフィーチャデータはフィーチャスナップショットと呼ばれます。この方法では、単純なオフラインラベルスプライシングとフィーチャバックフィルによってサンプルを構築するのではなく、大きなデータの不整合が発生します。元のアーキテクチャを次の図に示します。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

機能の規模が大きくなり、反復シナリオがますます複雑になるにつれて、このソリューションは次のようになります。最大の問題は、オンライン特徴抽出サービスが大きなプレッシャーにさらされていること、そして第二に、データストリーム全体を収集するコストが高すぎることです。このサンプル収集スキームには次の問題があります。

長い準備時間 : 現在のリソース制約の下では、このような大きなデータを実行するにはほぼ T 2 かかります。アルゴリズムモデルの反復に影響を与えるサンプルデータを準備します。
リソースの消費量が多い: 既存のサンプル収集方法では、すべてのリクエストの特性を計算し、それらを露出とクリックでつなぎ合わせます。が計算されると、データがテーブルから落ち、その結果、大量のデータが保存され、大量のリソースが消費されます。

5.1.1 一般的なソリューション

上記の問題を解決するために、業界には 2 つの一般的なソリューションがあります。①Flink リアルタイムストリーム処理。 ②KVキャッシュ二次処理。具体的なプロセスを次の図に示します。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

ストリーミングスプライシングソリューション : ストリーミング処理フレームワーク (Flink、Storm など ) の低遅延ストリーム処理機能を使用して、エクスポージャを直接読み取ります。クリック数リアルタイムストリームは、メモリ内のフィーチャスナップショットストリームデータに関連付けられます (Join)。ストリーミングトレーニングサンプルが最初に生成され、次にモデルのオフライントレーニングサンプルに転送されます。ストリーミングサンプルとオフラインサンプルはそれぞれ異なるストレージエンジンに保存され、さまざまな種類のモデルトレーニング方法をサポートします。このソリューションの問題点: データフローリンク内のデータ量がまだ非常に多く、より多くのメッセージフローリソース (Kafka など) を占有している; Flink リソースの消費が大きすぎる。データ量が数百の場合1 秒あたり G、Windows 参加には 30 分 × 60 × 100G のメモリリソースが必要です。
KV キャッシュソリューション : 特徴抽出のすべての特徴スナップショットを KV ストレージ (Redis など) に書き込み、N 分間キャッシュします。ビジネスシステムが通過すると、メッセージメカニズムが候補キュー内のアイテムをリアルタイムコンピューティングシステム (Flink またはコンシューマアプリケーション ) に送信します。この時点のアイテムの量は、以前にリクエストされたアイテムなので、これらのアイテムの特性は次のとおりです。データはフィーチャスナップショットキャッシュから取得され、ストリーミングトレーニングをサポートするためにメッセージフローを通じて出力されます。この方法は外部ストレージに依存するため、機能やトラフィックの増加に関係なく、Flink リソースを制御でき、動作がより安定します。しかし、未解決の問題は依然として大量のデータをキャッシュするためにより大きなメモリを必要とします。

5.1.2 改善と最適化

無効な計算を減らすという観点から、要求されたすべてのデータが公開されるわけではありません。この戦略では公開データに対する需要が高まるため、日レベルの処理をストリーム処理に転送することで、データの準備時間を大幅に短縮できます。次に、データの内容から言えば、リクエストレベルの変更データと日レベルの変更データが特徴的であり、リンクにより両者の処理を柔軟に分離することで、リソースの使用率を大幅に向上させることができます。具体的な計画は次の図の通りです。

テイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践

#1. データ分割: データ転送量が大きい問題を解決します (フィーチャスナップショットフローの問題#) ##)、予測ラベルリアルタイムデータを 1 つずつ照合すると、リフロー中にオフラインデータに 2 回アクセスできるため、リンクデータストリームのサイズを大幅に削減できます。

サンプルストリームにはコンテキストに応じたリアルタイム機能のみが含まれているため、読み取りデータストリームの安定性が向上します。同時に、必要なのはリアルタイム機能のみであるためです。保存すると、Kafka ハードディスクストレージは 10 分の 1 に削減されます。

2. 遅延消費結合方式 : 大量のメモリ使用量の問題を解決します。

公開ストリームはメインストリームとして使用され、HBase に書き込まれます。同時に、後で HBase の結合で他のストリームを公開できるようにするために、 RowKey は Redis に書き込まれ、後続のストリームは RowKey を渡します。HBase に書き込むとき、露出、クリック、および機能の結合は外部ストレージの助けを借りて完了し、データ量が増加してもシステムが安定して実行できるようにします。
サンプルストリームは遅延消費されます。バックグラウンドサービスのサンプルストリームは、多くの場合、露出ストリームよりも前に到着します。露出データの 99% を結合するために、サンプルストリームの待機ウィンドウ統計が必要になります。上記の実装方法は、ウィンドウ期間内のすべてのデータを Kafka のディスクに保存し、ディスクのシーケンシャル読み取りパフォーマンスを使用して、ウィンドウ期間中にキャッシュする必要がある大量のメモリを省略することです。ウィンドウ期間。

#3. 機能の再記録のサンプル : Label's Join を通じて、ここに追加された機能リクエストの数はオンラインの 20% 未満です遅延読み取り、露出とのスプライシング、露出モデルサービスリクエスト (コンテキストリアルタイム機能) のフィルタリング、次にすべてのオフライン機能の記録、完全なサンプルデータの形成、HBase への書き込み。

5.2 構造化ストレージ

ビジネスが繰り返されるにつれて、フィーチャースナップショット内のフィーチャーの数はますます増加し、1 つのビジネスでフィーチャースナップショット全体が数十に達します。シナリオ。TB レベル/日。ストレージの観点から見ると、複数日間にわたる単一ビジネスの特徴的なスナップショットはすでに PB レベルに達しており、広告アルゴリズムのストレージしきい値にほぼ達しており、ストレージの負荷が高いです。コンピューティングの観点からは、コンピューティングエンジン (Spark) のリソース制限により、元の計算プロセスを使用します (shuffle が使用され、シャッフル書き込みフェーズのデータはディスクに書き込まれます)。割り当てられたメモリが不十分な場合、複数のディスク書き込みと外部ソートが発生します )、計算を効果的に完了するには、独自のデータと同じサイズのメモリとより多くのコンピューティング CU が必要です。大量のメモリを占有します。サンプル構築プロセスの中心となるプロセスを次の図に示します。

フィーチャを再記録すると、次の問題が発生します:

データの冗長性 : オフラインの補足機能テーブルは一般的にデータ量が多く、エントリ数は数億、サンプル構築に使用するエントリ数はその日のDAU数程度となります。したがって、補足特徴テーブルデータが計算に参加しており、冗長なデータが存在します。

結合順序: 補足フィーチャーの計算プロセスは次元フィーチャーの補完です。複数の結合計算があるため、結合計算のパフォーマンスと結合テーブルの順序は異なります。これには大きな関係があり、上図のように、左のテーブルが数十TBレベルの大きなテーブルの場合、その後のシャッフル計算処理で大量のネットワークIOとディスクIOが発生します。

#サンプル構築効率が遅いという問題を解決するために、短期的にはデータ構造の管理から開始します。詳細なプロセスは次の図に示すとおりです。

構造化された分割。 データは、ハイブリッドストレージではなく、コンテキストデータと構造化ストレージの次元データに分割されます。これにより、ラベルサンプルの新しいフィーチャを結合するプロセスで大量の冗長データを運ぶという問題が解決され、構造化ストレージの後、オフラインフィーチャに対して大幅なストレージ圧縮が実現されます。

高効率フィルタリングプレフィックス。結合前にデータフィルタリングが高度に行われるため、特徴量の計算に含まれるデータ量が削減され、ネットワーク IO が効果的に削減されます。スプライシングプロセス中、フィーチャを補足的に記録するための Hive テーブルは通常フルテーブルであり、データ項目の数は通常月次のアクティビティとなりますが、実際のスプライシングプロセスで使用されるデータアイテムの数はほぼ 1 日のアクティビティです。そのため、大量のデータの冗長性があり、無効なデータにより追加の IO と計算が発生します。最適化方法は、使用されるディメンションキーを事前計算し、対応するブルームフィルターを生成することです。データの読み取り時にブルームフィルターを使用してフィルター処理を行うことで、冗長なデータ送信と補足記録プロセス中の冗長な計算を大幅に削減できます。

高パフォーマンスの結合。効率的な戦略を使用して結合シーケンスを調整し、機能再登録プロセスの効率とリソース使用率を向上させます。フィーチャのスプライシングプロセス中に、複数のテーブルで結合操作が行われ、結合の順序もスプライシングのパフォーマンスに大きく影響します。上図に示すように、結合される左側のテーブルのデータ量が多い場合、全体のパフォーマンスが低下します。ハフマンアルゴリズムの考え方を利用して、各テーブルをノード、対応するデータ量をその重みとみなすことができ、テーブル間の結合計算量は、単純に 2 つのテーブルの重みの合計に類推できます。ノード。したがって、この問題はハフマン木の構築に抽象化でき、ハフマン木の構築プロセスが最適な結合順序になります。

データのオフラインストレージリソースが 80% 節約され、サンプル構築効率が 200% 向上しました。現在、サンプルデータ全体も、データレイクを利用してデータ効率をさらに向上させます。
6 データ準備

プラットフォームには、機能、サンプル、モデルなどの貴重なコンテンツが大量に蓄積されており、これらのデータ資産を再利用することで戦略担当者を支援したいと考えています。 . ビジネスの繰り返しを改善し、より良いビジネス上の利益を達成します。特徴の最適化は、アルゴリズムスタッフがモデルの効果を向上させるために使用するすべての手法の 40% を占めていますが、従来の特徴マイニング手法には、長時間かかる、マイニング効率が低い、特徴マイニングが繰り返されるなどの問題がありました。機能の次元、ビジネス。機能の効果を検証し、最終的な効果指標をユーザーに推奨するための自動化された実験プロセスがあれば、間違いなく戦略担当者が大幅な時間を節約するのに役立ちます。全体のリンク構築が完了したら、さまざまな特徴候補セットを入力するだけで、対応する効果指標が出力されます。この目的を達成するために、プラットフォームは、特徴とサンプルの「加算」、「減算」、「乗算」、「除算」のためのインテリジェントなメカニズムを構築しました。
6.1 「追加」を行う

機能の推奨はモデルのテスト方法に基づいており、機能を他のビジネスラインの既存のモデルに再利用し、新しいサンプルとモデルを構築します。新しいモデルと基本モデルのオフライン効果を確認し、新機能の利点を活用して、関連するビジネスリーダーに自動的にプッシュします。特定の機能の推奨プロセスを次の図に示します。

機能の認識: 機能の推奨は、オンラインウォールまたは企業間のストック方式を通じて行われます。これらの機能はある程度検証されており、機能の推奨の成功率を保証できます。

サンプル制作: サンプル制作中に構成ファイルから機能が抽出され、プロセスによって新しい機能が構成ファイルに自動的に追加されます。、新しいサンプルデータの作成。新しいフィーチャーを取得した後、これらのフィーチャーが依存する元のフィーチャー、ディメンション、および UDF 演算子を分析し、新しいフィーチャー構成と依存する元のデータをベースラインモデルの元の構成ファイルに統合して、新しいフィーチャー構成ファイルを構築します。新しいサンプルを自動的に構築します。サンプルの構築中に、関連する特徴が特徴名を通じて特徴ウェアハウスから抽出され、構成された UDF が特徴計算のために呼び出されます。サンプル構築の期間は構成可能です。

モデルトレーニング: モデルの構造とサンプル形式の構成を自動的に変換し、モデルトレーニングフレームワークとして TensorFlow を使用してモデルトレーニングを実行します。 , サンプル入力として tfrecord 形式を使用し、新しいフィーチャを数値クラスと ID クラスに従って 2 つのグループ A と B にそれぞれ配置します。ID クラスのフィーチャはテーブル検索操作を実行し、モデル構造を変更せずに既存のフィーチャに均一に追加します。新規モデルのトレーニング用にサンプルを受け取ることができます。

新しいモデルトレーニングパラメーターを自動的に構成します: トレーニングセットとテストに分割されたトレーニング日、サンプルパス、モデルのハイパーパラメーターなどが含まれます。を設定すると、新しいモデルが自動的にトレーニングされます。

モデル評価: 評価インターフェイスを呼び出してオフラインインジケーターを取得し、新旧モデルの評価結果を比較し、単一の機能の評価結果を予約します。 features、単一の機能の貢献を示します。評価結果は一律にユーザーに通知されます。

6.2 「引き算」を行う

広告に機能レコメンデーションが実装され、一定の収益が得られたらが達成されたら、機能強化レベルでいくつかの新しい調査を行います。モデルの継続的な最適化により、機能拡張の速度が非常に速くなり、モデルサービスのリソース消費量が急激に増加するため、冗長な機能を削除してモデルを「スリム化」することが不可欠です。したがって、プラットフォームは一連のエンドツーエンドの機能スクリーニングツールを構築しました。

機能スコアリング##: WOE ( Weight Of Evidence、Weight of Evidence) およびその他の評価アルゴリズムにより、モデルのすべての特徴にスコアが与えられます。スコアが高い特徴ほど、品質が高く、評価精度も高くなります。 #効果の検証

: モデルをトレーニングした後、スコアで並べ替え、バッチで特徴を削除します。具体的には、特徴分割法を用いて元のモデルと壊れたモデルの評価結果を比較し、その差が閾値より大きい場合に評価を終了し、削除できる特徴を与える。エンドツーエンドのソリューション
: ユーザーが実験パラメータと指標のしきい値を設定した後、削除可能な特徴と特徴削除後のモデルを人手を介さずに提供できます。介入、オフライン評価結果。
最終的に、内部モデルで機能の 40% がオフラインになった後でも、ビジネス指標の低下は依然として妥当なしきい値内に制御されました。

6.3 「乗算」を行う
より良いモデル効果を得るために、大規模なモデル、リアルタイム、機能など、広告内でいくつかの新しい検討が開始されました。図書館は待ってください。これらの探索の背後には重要な目標があります。それは、モデルをよりスマートかつ効率的にするために、より多くのより優れたデータが必要であるということです。広告の現状を踏まえ、より多くの種類、より大規模な外部データを取り込み、既存ビジネスに応用するためのサンプルバンク（
データバンク
）の構築を提案します。具体的には、以下の図に示すとおりです。

当社は、他の事業分野を借りて増分サンプルを生成できるユニバーサルサンプル共有プラットフォームを確立しました。。また、大規模および小規模のビジネス統合を実現するための共通の組み込み共有アーキテクチャを構築します。以下は広告以外のサンプルを広告事業で再利用する例で、具体的な方法は以下のとおりです。

サンプルの拡張: Flink ストリーミング処理フレームワークに基づいて、拡張性の高いサンプルライブラリ DataBank が構築されており、ビジネス A はビジネス B とビジネスを簡単に再利用できますC. 露出、クリック、その他のラベルデータを使用して実験を行います。特に中小企業向けに大量の価値データが拡充されており、オフライン補完登録に比べて整合性が強化されており、機能プラットフォームによりオンラインとオフラインの整合性が保証されています。

共有: サンプルの準備ができたら、非常に典型的なアプリケーションシナリオは転移学習です。さらに、Embedding によって共有されるデータパスも構築されます ( は「サンプル拡張」プロセスに大きく依存しません )。すべてのビジネスラインは大規模な Embedding に基づいてトレーニングできます。各ビジネスパーティはこれを更新することもできますオンラインで埋め込みを行い、複数の事業部門で使用するためのバージョンメカニズムをオンラインで作成します。

たとえば、広告以外のサンプルを広告内のビジネスに再利用することで、サンプル数が数倍に増加しました。転移学習アルゴリズムと組み合わせることで、オフライン AUC第 4 に、オンライン化後は CPM が 1% 増加します。また、各事業者が生成したサンプルデータを一元管理し（Unified Metadata）、統一したサンプルテーマ分類をユーザーに公開し、迅速な登録・検索・再利用を可能にする広告サンプルテーマデータベースの構築も進めています。最下層の統合ストレージにより、ストレージとコンピューティングリソースが節約され、データ結合が削減され、適時性が向上します。

6.4 「除算」を行う

特徴量の「減算」により、プラスの効果を持たないいくつかの特徴量を削除できますが、観察すると、いくつかの特徴量が存在することがわかります。モデル特性にはほとんど価値のない機能がまだ多くあります。したがって、価値とコストの両方を総合的に考慮することでさらに一歩進んで、リンク全体のコストベースの制約の下で、入出力の少ない機能を排除し、リソースの消費を削減することができます。このコスト制約のもとで解く過程を「分割」と定義し、その全体過程を下図に示します。

#オフライン次元では、特徴量のコストと価値を与える特徴量評価システムを確立しました。オンライン推論。情報は、トラフィックの劣化、特徴の弾力性の計算、その他の操作を実行するために使用されます。「分割」の主な手順は次のとおりです:

問題の要約: 各機能の価値スコアを取得でき、機能のコストも取得できる場合 (#ストレージ、通信、コンピューティング、処理) ) の場合、問題は、既知のモデル構造と固定リソースコストを考慮して、機能の価値を最大化する方法に変換されます。

コスト制約下での価値評価: モデルの機能セットに基づいて、プラットフォームはまずコストと価値の統計的要約を実行します。 ; コストに含まれるものオフラインコストとオンラインコストは、機能の包括的なランキングを取得するためにトレーニングされた評価モデルに基づいています。

シナリオベースのモデリング: さまざまなリソース条件に基づいて、モデリング用にさまざまな機能セットを選択できます。リソースが限られているため、オンラインでの作業に最も価値のあるモデルを選択してください。さらに、比較的大規模な機能セット用にモデル化し、低トラフィックのピーク時に有効にすることで、リソースの使用率が向上し、ビジネスに大きなメリットをもたらすことができます。もう 1 つのアプリケーションシナリオはトラフィックの低下です。推論サービスはオンラインリソースの消費を監視し、リソース計算がボトルネックに達すると、低下モデルに切り替えます。

7 概要と展望
上記は、大規模な深層学習プロジェクトにおける「増加」防止の実践方法です。ビジネスコストを削減し、効率を向上させます。将来的には、次の側面の探求と実践を続けていきます:

フルリンク GPU 化: 推論レベルでは、GPU スイッチングを通じて、より複雑なビジネス反復をサポートする一方で、全体的なコストも非常に高くなります。その後、サンプル構築と機能サービスにおいて GPU ベースの変革を実行し、オフライントレーニングレベルのアップグレードを共同で推進します。

サンプルデータレイク: スキーマエボリューション、パッチ更新、およびデータレイクのその他の機能を通じて大規模なサンプルウェアハウスを構築し、ビジネスサイド低コストで価値の高いデータ開示を実現します。

パイプライン: アルゴリズムのライフサイクル全体の反復プロセス、デバッグの多くの側面、リンク情報では十分ではありません「シリーズ」、オフライン、オンライン、効果指標の観点は比較的細分化されており、リンク全体に基づく標準化と可観測性が一般的な傾向であり、これが後続のリンクのインテリジェントかつ柔軟な展開の基礎となります。現在業界で流行している MLOps とクラウドネイティブには、参考になるアイデアがたくさんあります。

データとモデルのインテリジェントなマッチング: 前述したように、モデル構造が固定されているという前提の下で、モデルに対して特徴量が自動的に追加および削除されます。、モデルレベルで固定、特定の特徴入力の前提の下で、いくつかの新しいモデル構造を自動的に埋め込むことができます。そして将来的には、ビジネス分野に基づいて、プラットフォームの機能とモデルシステムを通じて、データとモデルのマッチングも自動的に完了する予定です。

8 この記事の著者

Yajie、Yingliang、Chen Long、Chengjie、Dengfeng、Dongkui、Tongye、Simin、Lebin 、など、すべて Meituan の食品配達技術チームから来ています。

以上がテイクアウト広告向けの大規模深層学習モデルのエンジニアリング実践の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。