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

著者: 亚廼英梁陈龙 他

はじめに

美団のフードデリバリー事業が発展し続ける中、フードデリバリー 広告エンジンチームは複数の分野でエンジニアリングの探索と実践を実施し、一定の成果を上げてきました。連載形式で共有していきますが、その内容は主に、①ビジネスプラットフォーム化の実践、②大規模ディープラーニングモデルエンジニアリングの実践、③ニアラインコンピューティングの探索と実践、④大規模なディープラーニングモデルエンジニアリングの実践です。 -スケールインデックスの構築とオンライン検索サービス; ⑤ 機構エンジニアリングプラットフォームの実践。少し前に、当社はビジネス プラットフォーム化の実践を公開しました (詳細については、「##美団テイクアウト広告プラットフォーム化の検討と実践 ##」を参照してください) #>> 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）を使用します。

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

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

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

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

1. ネットワーク分散: CTR モデルの全体的なネットワーク構造は、エンベディング層、アテンション層、MLP 層の 3 つの部分に抽象化されます。埋め込み層はデータ取得に使用され、アテンション層にはより多くの論理演算と軽量のネットワーク計算が含まれ、MLP 層には高密度のネットワーク計算が含まれます。
2. アクセラレーション ネットワークの選択: 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 つの目標を中心に最適化します:

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

モデル最適化

、融合最適化、 について詳しく紹介します。エンジンの最適化 いくつかの作業が完了しました。 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 エンジンの最適化

複数のモデル

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

Dynamic Shape

: 入力バッチが不確実なシナリオでの不必要なデータ パディングに対処し、同時にモデルの数を減らし、ビデオ メモリなどのリソースの無駄を削減するために、Dynamic Shape が導入されました。実際の入力データに基づいて推論を実行し、データ パディングと不要なコンピューティング リソースの無駄を削減し、最終的にパフォーマンスの最適化とスループットの向上という目的を達成します。
3. CUDA グラフ: 最新の GPU の各操作 (カーネルの実行など) にかかる時間は少なくともマイクロ秒レベルであり、 GPU に送信される各操作も、ある程度のオーバーヘッド (
マイクロ秒レベル
4. ) を生成します。実際の推論では、多くのカーネル操作を実行する必要があることがよくあります。これらの操作はそれぞれ個別に 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 を渡す必要があります。具体的な構造は次のとおりです。

5. ##3.3.6 パイプライン
オフライン トレーニングから最終的なオンライン読み込みまでのプロセス全体モデルの変換は面倒で、エラーが発生しやすく、モデルは異なる GPU カード、異なる TensorRT および CUDA バージョンで汎用的に使用できないため、モデル変換でエラーが発生する可能性が高くなります。したがって、モデル反復の全体的な効率を向上させるために、次の図に示すように、パイプラインで関連する能力構築を実行しました。



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

1. ##オフライン側: モデル分割ノードを提供するだけで、プラットフォームは元の TF モデルを埋め込みサブモデルと計算グラフ サブモデルに自動的に分割します。埋め込みサブモデルは、分散コンバーターを通じて分散コンピューティングを実行します。サブ置換と埋め込みインポート作業。計算グラフ サブモデルは、選択したハードウェア環境 (GPU モデル、TensorRT バージョン、CUDA バージョン ) に従って TensorRT モデルの変換とコンパイルの最適化を実行し、最終的に変換します。 2 つのサブモデル 結果は、後続のモデル展開およびオンラインのために S3 に保存されます。プロセス全体は、ユーザーが実行の詳細を意識することなく、プラットフォームによって自動的に完了します。
2. オンライン テスト: モデル デプロイメント ハードウェア環境を選択するだけで (モデル変換の環境と一致するようにしてください)、プラットフォームが構成されます環境に応じて、モデルのアダプティブ プッシュ ロードを実行し、ワンクリックでモデルの展開とオンライン展開を完了します。
#Pipeline は、構成とワンクリック機能の構築を通じてモデルの反復効率を大幅に向上させ、アルゴリズムとエンジニアリングの学生が自分の仕事により集中できるようにしました。次の図は、純粋な CPU 推論と比較して、GPU の実践で得られる全体的な利点を示しています。

4 機能サービス CodeGen の最適化

機能抽出はモデル計算の前段階であり、従来の LR モデルであっても、ますます人気が高まっている深層学習モデルであっても、特徴抽出を通じて入力を取得する必要があります。前回のブログ

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

DSL は機能処理ロジックの説明です。初期の特徴量計算の実装では、各モデルに設定された DSL が解釈されて実行されました。解釈実行の利点は、実装が簡単で、一般的に使用される反復子パターンなどの適切な設計によって適切な実装を実現できることですが、欠点は、実行パフォーマンスが低く、多くの分岐ジャンプや型を使用できないことです。変換などの汎用性を確保するために、実装レベルでは避けてください。実際、モデル構成の固定バージョンの場合、そのモデル機能の変換ルールはすべて固定されており、リクエストによって変更されることはありません。極端な場合には、この既知の情報に基づいて、各モデルの機能をハードコーディングして、究極のパフォーマンスを達成することができます。明らかに、モデルの機能構成は常に変化しており、各モデルを手動でコーディングすることは不可能です。そこで、コンパイル中に構成ごとに独自のコードのセットを自動的に生成する CodeGen のアイデアが生まれました。 CodeGen は特定のテクノロジやフレームワークではなく、抽象的な記述言語から特定の実行言語への変換プロセスを完了するアイデアです。実際、業界では、コンピューティング集約型のシナリオで計算を高速化するために CodeGen を使用することが一般的です。たとえば、Apache Spark は CodeGen を使用して SparkSql の実行パフォーマンスを最適化します。式操作を高速化する 1.x の ExpressionCodeGen から、フルステージ アクセラレーションのために 2.x で導入された WholeStageCodeGen まで、非常に明白なパフォーマンスの向上が達成されています。機械学習の分野では、TensorFlow XLA や TVM などの一部の TF モデル アクセラレーション フレームワークも CodeGen のアイデアに基づいており、Tensor ノードを統合中間層 IR にコンパイルし、ローカル環境と組み合わせた IR に基づいてスケジューリングの最適化を実行します。ランタイムモデル計算の高速化を実現します。

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

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



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

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

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



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

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

4.2 伝送の最適化

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

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

上記の問題を解決するために、最適化されたプロセスでは、伝送層の上に変換層を追加し、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 ストリーミング サンプル

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



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

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

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

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






#
1. ストリーミング スプライシング ソリューション : ストリーミング処理フレームワーク (Flink、Storm など ) の低遅延ストリーム処理機能を使用して、エクスポージャを直接読み取ります。クリック数 リアルタイム ストリームは、メモリ内のフィーチャ スナップショット ストリーム データに関連付けられます (Join)。ストリーミング トレーニング サンプルが最初に生成され、次にモデルのオフライン トレーニング サンプルに転送されます。ストリーミング サンプルとオフライン サンプルはそれぞれ異なるストレージ エンジンに保存され、さまざまな種類のモデル トレーニング方法をサポートします。このソリューションの問題点: データ フロー リンク内のデータ量がまだ非常に多く、より多くのメッセージ フロー リソース (Kafka など) を占有している; Flink リソースの消費が大きすぎる。データ量が数百の場合1 秒あたり G、Windows 参加には 30 分 × 60 × 100G のメモリ リソースが必要です。
2. 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 が必要です。 大量のメモリを占有します。サンプル構築プロセスの中心となるプロセスを次の図に示します。

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

1. データの冗長性 : オフラインの補足機能テーブルは一般的にデータ量が多く、エントリ数は数億、サンプル構築に使用するエントリ数はその日のDAU数程度となります。したがって、補足特徴テーブル データが計算に参加しており、冗長なデータが存在します。
2. 結合順序: 補足フィーチャーの計算プロセスは次元フィーチャーの補完です。複数の結合計算があるため、結合計算のパフォーマンスと結合テーブルの順序は異なります。これには大きな関係があり、上図のように、左のテーブルが数十TBレベルの大きなテーブルの場合、その後のシャッフル計算処理で大量のネットワークIOとディスクIOが発生します。

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

1. 構造化された分割。 データは、ハイブリッド ストレージではなく、コンテキスト データと構造化ストレージの次元データに分割されます。これにより、ラベル サンプルの新しいフィーチャを結合するプロセスで大量の冗長データを運ぶという問題が解決され、構造化ストレージの後、オフライン フィーチャに対して大幅なストレージ圧縮が実現されます。
2. 高効率フィルタリング プレフィックス。結合前にデータ フィルタリングが高度に行われるため、特徴量の計算に含まれるデータ量が削減され、ネットワーク IO が効果的に削減されます。スプライシング プロセス中、フィーチャを補足的に記録するための Hive テーブルは通常フル テーブルであり、データ項目の数は通常月次のアクティビティとなりますが、実際のスプライシング プロセスで使用されるデータ アイテムの数はほぼ 1 日のアクティビティです。そのため、大量のデータの冗長性があり、無効なデータにより追加の IO と計算が発生します。最適化方法は、使用されるディメンション キーを事前計算し、対応するブルーム フィルターを生成することです。データの読み取り時にブルーム フィルターを使用してフィルター処理を行うことで、冗長なデータ送信と補足記録プロセス中の冗長な計算を大幅に削減できます。
3. 高パフォーマンスの結合。効率的な戦略を使用して結合シーケンスを調整し、機能再登録プロセスの効率とリソース使用率を向上させます。フィーチャのスプライシング プロセス中に、複数のテーブルで結合操作が行われ、結合の順序もスプライシングのパフォーマンスに大きく影響します。上図に示すように、結合される左側のテーブルのデータ量が多い場合、全体のパフォーマンスが低下します。ハフマン アルゴリズムの考え方を利用して、各テーブルをノード、対応するデータ量をその重みとみなすことができ、テーブル間の結合計算量は、単純に 2 つのテーブルの重みの合計に類推できます。ノード。したがって、この問題はハフマン木の構築に抽象化でき、ハフマン木の構築プロセスが最適な結合順序になります。

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

6 データ準備

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

6.1 「追加」を行う

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

1. 機能の認識: 機能の推奨は、オンライン ウォールまたは企業間のストック方式を通じて行われます。これらの機能はある程度検証されており、機能の推奨の成功率を保証できます。
2. サンプル制作: サンプル制作中に構成ファイルから機能が抽出され、プロセスによって新しい機能が構成ファイルに自動的に追加されます。 、新しいサンプルデータの作成。新しいフィーチャーを取得した後、これらのフィーチャーが依存する元のフィーチャー、ディメンション、および UDF 演算子を分析し、新しいフィーチャー構成と依存する元のデータをベースライン モデルの元の構成ファイルに統合して、新しいフィーチャー構成ファイルを構築します。新しいサンプルを自動的に構築します。サンプルの構築中に、関連する特徴が特徴名を通じて特徴ウェアハウスから抽出され、構成された UDF が特徴計算のために呼び出されます。サンプル構築の期間は構成可能です。
3. モデル トレーニング: モデルの構造とサンプル形式の構成を自動的に変換し、モデル トレーニング フレームワークとして TensorFlow を使用してモデル トレーニングを実行します。 , サン​​プル入力として tfrecord 形式を使用し、新しいフィーチャを数値クラスと ID クラスに従って 2 つのグループ A と B にそれぞれ配置します。ID クラスのフィーチャはテーブル検索操作を実行し、モデル構造を変更せずに既存のフィーチャに均一に追加します。新規モデルのトレーニング用にサンプルを受け取ることができます。
4. 新しいモデル トレーニング パラメーターを自動的に構成します: トレーニング セットとテストに分割されたトレーニング日、サンプル パス、モデルのハイパーパラメーターなどが含まれます。を設定すると、新しいモデルが自動的にトレーニングされます。
5. モデル評価: 評価インターフェイスを呼び出してオフライン インジケーターを取得し、新旧モデルの評価結果を比較し、単一の機能の評価結果を予約します。 features、単一の機能の貢献を示します。評価結果は一律にユーザーに通知されます。

6.2 「引き算」を行う

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

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

6.3 「乗算」を行う

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

データバンク

）の構築を提案します。具体的には、以下の図に示すとおりです。

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

1. サンプルの拡張: Flink ストリーミング処理フレームワークに基づいて、拡張性の高いサンプル ライブラリ DataBank が構築されており、ビジネス A はビジネス B とビジネスを簡単に再利用できますC. 露出、クリック、その他のラベル データを使用して実験を行います。特に中小企業向けに大量の価値データが拡充されており、オフライン補完登録に比べて整合性が強化されており、機能プラットフォームによりオンラインとオフラインの整合性が保証されています。
2. 共有: サンプルの準備ができたら、非常に典型的なアプリケーション シナリオは転移学習です。さらに、Embedding によって共有されるデータ パスも構築されます ( は「サンプル拡張」プロセスに大きく依存しません )。すべてのビジネス ラインは大規模な Embedding に基づいてトレーニングできます。各ビジネス パーティはこれを更新することもできますオンラインで埋め込みを行い、複数の事業部門で使用するためのバージョン メカニズムをオンラインで作成します。

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

6.4 「除算」を行う

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

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

1. 問題の要約: 各機能の価値スコアを取得でき、機能のコストも取得できる場合 (#ストレージ、通信、コンピューティング、処理) ) の場合、問題は、既知のモデル構造と固定リソース コストを考慮して、機能の価値を最大化する方法に変換されます。
2. コスト制約下での価値評価: モデルの機能セットに基づいて、プラットフォームはまずコストと価値の統計的要約を実行します。 ; コストに含まれるもの オフライン コストとオンライン コストは、機能の包括的なランキングを取得するためにトレーニングされた評価モデルに基づいています。
3. シナリオベースのモデリング: さまざまなリソース条件に基づいて、モデリング用にさまざまな機能セットを選択できます。リソースが限られているため、オンラインでの作業に最も価値のあるモデルを選択してください。さらに、比較的大規模な機能セット用にモデル化し、低トラフィックのピーク時に有効にすることで、リソースの使用率が向上し、ビジネスに大きなメリットをもたらすことができます。もう 1 つのアプリケーション シナリオはトラフィックの低下です。推論サービスはオンライン リソースの消費を監視し、リソース計算がボトルネックに達すると、低下モデルに切り替えます。

7 概要と展望

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

1. フルリンク GPU 化: 推論レベルでは、GPU スイッチングを通じて、より複雑なビジネス反復をサポートする一方で、全体的なコストも非常に高くなります。その後、サンプル構築と機能サービスにおいて GPU ベースの変革を実行し、オフライン トレーニング レベルのアップグレードを共同で推進します。
2. サンプル データ レイク: スキーマ エボリューション、パッチ更新、およびデータ レイクのその他の機能を通じて大規模なサンプル ウェアハウスを構築し、ビジネスサイド 低コストで価値の高いデータ開示を実現します。
3. パイプライン: アルゴリズムのライフサイクル全体の反復プロセス、デバッグの多くの側面、リンク情報では十分ではありません「シリーズ」、オフライン 、オンライン、効果指標の観点は比較的細分化されており、リンク全体に基づく標準化と可観測性が一般的な傾向であり、これが後続のリンクのインテリジェントかつ柔軟な展開の基礎となります。現在業界で流行している MLOps とクラウド ネイティブには、参考になるアイデアがたくさんあります。
4. データとモデルのインテリジェントなマッチング: 前述したように、モデル構造が固定されているという前提の下で、モデルに対して特徴量が自動的に追加および削除されます。 、モデルレベルで固定、特定の特徴入力の前提の下で、いくつかの新しいモデル構造を自動的に埋め込むことができます。そして将来的には、ビジネス分野に基づいて、プラットフォームの機能とモデルシステムを通じて、データとモデルのマッチングも自動的に完了する予定です。

8 この記事の著者

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

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