フードデリバリー広告向け大規模ディープラーニングモデルのエンジニアリング実践

著者: Yajie Yingliang、Chen Long 他

導入

美団のフードデリバリー事業が成長を続ける中、フードデリバリー広告エンジンチームは複数の分野でエンジニアリングの探求と実践を行い、一定の成果を上げています。連載形式でお伝えします。内容は主に、①ビジネスプラットフォーム化の実践、②大規模ディープラーニングモデルエンジニアリングの実践、③ニアラインコンピューティングの探究と実践、④大規模インデックス構築とオンライン検索サービスの実践、⑤メカニズムエンジニアリングプラットフォーム化の実践などです。先日、当社はビジネスプラットフォーム化の実践を公開しました（詳細は記事「美団テイクアウト広告プラットフォーム化の探求と実践」をご参照ください）。この記事は、連載記事の2番目です。オンラインレイテンシとオフライン効率という2つの側面から始めて、フルリンクレベルでの大規模ディープモデルがもたらす課題に焦点を当て、大規模ディープモデルでの広告のエンジニアリング実践について説明します。皆様に何らかの助けやインスピレーションをお届けできれば幸いです。

1 背景

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

2 分析

通常の小規模モデルと比較して、大規模モデルの中心的な問題は、データ量とモデル規模が数十倍、さらには数百倍に増加すると、全体的なリンクにおけるストレージ、通信、コンピューティングが新たな課題に直面し、それがアルゴリズムのオフライン反復効率に影響を与えることです。オンラインレイテンシ制約などの一連の問題をどのように克服するのでしょうか?まず、以下に示すように、完全なリンク分析から始めましょう。

期間の増加は主に以下の側面に反映されます。

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

この記事では、オンラインレイテンシ（モデル推論、特徴提供）とオフライン効率（サンプル構築、データ準備）という2つの側面に焦点を当て、大規模なディープモデルでの広告のエンジニアリング実践を段階的に説明します。以降の章では、「期間」を最適化する方法やその他の関連する問題について説明しますので、お楽しみに。

3 モデル推論

モデル推論レベルでは、フードデリバリー広告は、ニッチ規模の DNN モデルのサポートを代表とする 1.0 時代から、高効率とローコードによるマルチビジネス反復をサポートする 2.0 時代、そして徐々にディープラーニング DNN コンピューティング パワーと大規模ストレージのニーズに向けられた今日の 3.0 時代まで、3 つのバージョンを経てきました。主な進化の傾向は以下の図に示されています。

大規模モデル推論シナリオの場合、3.0 アーキテクチャが解決する 2 つの主要な問題は、「ストレージの問題」と「パフォーマンスの問題」です。もちろん、100GBを超えるサイズのN個のモデルをどのように反復するか、計算量が数十倍に増加したときにオンラインの安定性をどのように確保するか、パイプラインをどのように強化するかなども、プロジェクトが直面する課題です。以下では、Model Reasoning 3.0 アーキテクチャが「分散」を通じて大規模モデル ストレージの問題をどのように解決するか、また CPU/GPU アクセラレーションを通じてパフォーマンスとスループットの問題をどのように解決するかに焦点を当てます。

3.1 分散型

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

• スパース パラメータ: パラメータの規模は大きく、通常は数十億、場合によっては数十億、数百億になります。これにより、ストレージ スペースの使用量が大きくなり、通常は数百 GB、場合によっては T レベルになります。その特徴は、①単一マシンへのロードが困難：スタンドアロンモードでは、すべてのスパースパラメータをマシンメモリにロードする必要があり、深刻なメモリ不足が発生し、安定性と反復効率に影響します。 ②スパース読み取り：推論計算ごとに、パラメータの一部のみを読み取る必要があります。たとえば、ユーザーパラメータの総数は2億レベルですが、推論要求ごとに1つのユーザーパラメータのみを読み取る必要があります。
• 密なパラメータ：パラメータの規模は大きくありません。全結合モデルは一般的に 2 ～ 3 層で、パラメータの大きさは数百万から数千万です。特徴：①単一マシンロード可能：密なパラメータは約数十メガバイトを占め、単一マシンメモリは正常にロードできます。たとえば、入力層は2000、全結合層は[1024、512、256]で、合計パラメータは2000 * 1024 + 1024 * 512 + 512 * 256 + 256 = 2703616で、合計270万パラメータで、メモリ占有量は100メガバイト以内です。 ②全読み取り：推論計算ごとにすべてのパラメータを読み取る必要があります。

したがって、モデルパラメータ規模の拡大を解決する鍵は、スパースパラメータを単一マシンストレージから分散ストレージに変換することです。変換方法は、①モデルネットワーク構造の変換、②スパースパラメータのエクスポートの 2 つの部分で構成されます。

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

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

通常、TF モデルはネイティブ演算子を使用してスパース パラメータを読み取ります。コア演算子は GatherV2 演算子です。演算子入力は主に 2 つの部分で構成されます。① クエリする ID リスト。② スパース パラメータを格納する埋め込みテーブル。

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

TF 演算子の変換の本質は、モデル ネットワーク構造を変換することです。変換の中核となるポイントは、主に 2 つの部分です。① ネットワーク グラフの再構築、② カスタム分散演算子。

1. ネットワーク図の再構築：モデルネットワーク構造を変換し、ネイティブ TF 演算子をカスタム分散演算子に置き換え、ネイティブの埋め込みテーブルを固定します。

• 分散オペレータの置き換え: モデル ネットワークを走査し、置き換える必要がある GatherV2 オペレータをカスタム分散オペレータ MtGatherV2 に置き換え、上流ノードと下流ノードの入力/出力を変更します。
• ネイティブ埋め込みテーブルの固定化: ネイティブ埋め込みテーブルはプレースホルダーとして固定化されており、モデル ネットワーク構造をそのまま維持できるだけでなく、スパース パラメーターが単一のマシン メモリを占有するのを防ぐこともできます。

2.カスタム分散演算子: ID リストに基づいて、埋め込みクエリ プロセスを、ローカルの埋め込みテーブルからのクエリから分散 KV からのクエリに変換します。

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

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

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

全体のプロセスを下の図に示します。オフライン分散モデル構造変換、ニアラインデータ一貫性保証、オンラインホットデータキャッシュなどの手段を通じて、数百 GB の大規模モデルの正常な反復ニーズを保証します。

ご覧のとおり、分散システムで使用されるストレージは外部 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 はモデル オプティマイザーを使用して、モデル ネットワーク内の複数層の演算子の統合線形融合を実行し、演算子のスケジューリング オーバーヘッドと演算子間のデータ アクセス オーバーヘッドを削減します。たとえば、3 つの演算子 Conv+BN+Relu は CBR 構造演算子に統合されます。
2. データ精度の調整: モデルをオフラインでトレーニングした後、推論プロセス中にバックプロパゲーションは不要になるため、データ精度を FP16 または INT8 精度などに適切に下げることができ、メモリ使用量が削減され、推論のレイテンシが短縮されます。

CPU アクセラレーションは通常、固定バッチ内の候補キューの推論を高速化しますが、検索およびプロモーションのシナリオでは、候補キューは動的になることがよくあります。つまり、モデル推論の前にバッチ マッチング操作を追加する必要があります。つまり、要求された動的バッチ候補キューをそれに最も近いバッチ モデルにマッピングする必要がありますが、そのためには N 個のマッチング モデルを構築する必要があり、メモリ使用量が N 倍になります。しかし、現在のモデルサイズは数百GBに達しており、メモリが深刻に不足しています。したがって、加速のために適切なネットワーク構造を選択することは、検討する必要がある重要な問題です。次の図は、全体的なオペレーティング アーキテクチャを示しています。

1. ネットワーク分散: CTR モデルの全体的なネットワーク構造は、埋め込み層、注意層、MLP 層の 3 つの部分に抽象化されます。埋め込み層はデータ取得に使用され、注意層にはより多くの論理演算と軽量のネットワーク計算が含まれ、MLP 層は集中的なネットワーク計算に使用されます。
2. 高速ネットワーク選択: OpenVINO は純粋なネットワーク コンピューティングに優れた高速化効果があり、MLP レイヤーに適切に適用できます。さらに、モデル データのほとんどは埋め込みレイヤーに保存され、MLP レイヤーは数十メガバイトのメモリしか占有しません。 MLP層ネットワークに複数のバッチを分割した場合、最適化前のモデルメモリ使用量（ Embedding+Attention+MLP ）≈最適化後（ Embedding+Attention+MLP×バッチ数）となり、メモリ使用量にほとんど影響しません。したがって、最終的に、MLP レイヤー ネットワークをモデル加速ネットワークとして選択しました。

現在、OpenVINO ベースの CPU アクセラレーション ソリューションは、実稼働環境で良好な結果を達成しています。CPU がベースラインと等しい場合、サービス スループットは 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 は他のエンジンよりも演算子の最適化が詳細で、カスタム プラグインを通じて任意の演算子を実装できるため、スケーラビリティが優れています。また、TensorRTは一般的な学習プラットフォーム（ Caffe、PyTorch、TensorFlowなど）のモデルをサポートしており、周辺機器も充実しつつある（モデル変換ツールonnx-tensorrt、パフォーマンス分析ツールnsysなど）ため、GPU側のアクセラレーションエンジンとしてTensorRTが利用されています。
• モデル分析：CTRモデルの全体的なネットワーク構造は、埋め込み層、注意層、MLP層の3つの部分に抽象化されています。埋め込み層はデータ取得に使用され、CPUに適しています。注意層にはより多くの論理演算と軽量のネットワーク計算が含まれ、MLP層はネットワーク計算に重点を置いています。これらの計算は並列で実行でき、GPUに適しています。GPUコア（ Cudaコア、Tensorコア）を最大限に活用して並列性を向上させることができます。

3.3.2 最適化の目的

ディープラーニングの推論段階では、計算能力とレイテンシに対する要件が非常に高く、トレーニング済みのニューラル ネットワークを推論の末端に直接展開すると、計算能力が不足して実行できない、または推論時間が長くなるなどの問題が発生する可能性が高くなります。したがって、トレーニングされたニューラル ネットワークを最適化する必要があります。業界におけるニューラル ネットワーク モデルの最適化の一般的な考え方は、モデルの圧縮、異なるネットワーク レイヤーのマージ、スパース化、低精度のデータ型の使用、さらにはハードウェア特性に基づいたターゲットを絞った最適化など、さまざまな側面から最適化できます。この目的のために、私たちは主に次の 2 つの目標を中心に最適化を行います。

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

上記 2 つの目標に焦点を当て、以下では、モデル最適化、融合最適化、エンジン最適化で行った作業の一部を具体的に紹介します。

3.3.3 モデルの最適化

1. 計算と転送の重複排除: 推論中、同じバッチには 1 人のユーザー情報のみが含まれます。したがって、推論前にユーザー情報をバッチ サイズから 1 に減らし、推論が実際に必要なときに拡張することで、データの転送コピーと繰り返し計算のオーバーヘッドを削減できます。下の図に示すように、推論前に User クラスの特徴情報を 1 回だけ照会し、その後はユーザーに関連するサブネットワークで切り取って、関連性を計算する必要があるときに展開することができます。

• 自動化プロセス: 繰り返し計算されるノード (赤いノード) を検索します。ノードのすべてのリーフ ノードが繰り返し計算されるノードである場合、そのノードも繰り返し計算されるノードです。すべてのノードがトラバースされて検索されるまで、リーフ ノードからレイヤーごとにすべての繰り返しノードを検索します。すべての赤と白のノードの接続線を見つけ、ユーザー機能拡張ノードを挿入して、ユーザー機能を展開します。

2. データ精度の最適化：モデルトレーニング時には勾配を更新するためにバックプロパゲーションが必要となるため、高いデータ精度が求められます。しかし、モデル推論時には前向き推論のみが行われ、勾配更新は必要ありません。そのため、効果を確保しながら、FP16または混合精度を使用して最適化することで、メモリスペースを節約し、転送オーバーヘッドを削減し、推論パフォーマンスとスループットを向上させます。

3. 計算のプッシュダウン：CTRモデル構造は、主にEmbedding、Attention、MLPの3つの層で構成されています。Embedding層はデータ取得に偏っており、Attentionは部分的にロジックに偏っており、部分的に計算に偏っています。GPUの潜在能力を最大限に活用するために、CTRモデル構造におけるAttentionとMLPの計算ロジックの大部分はCPUからGPUにプッシュダウンされて計算され、全体的なスループットが大幅に向上します。

3.3.4 融合最適化

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

• レイヤー フュージョン: TensorRT は、レイヤーを水平または垂直にマージすることで、ネットワーク レイヤーの数を大幅に削減します。簡単に言えば、一部のコンピューティング オペレーションを融合したり、一部の冗長なオペレーションを削除したりすることで、データ循環回数、ビデオ メモリの頻繁な使用、およびスケジューリングのオーバーヘッドを削減します。たとえば、一般的なネットワーク構造には、畳み込みと要素ごとの演算の融合と CBR 融合があります。次の図は、融合前後のネットワーク構造全体における一部のサブグラフの構造を示しています。FusedNewOP は、融合プロセス中に CudnnMLPFC、CudnnMLPMM、CudaMLP などの複数の戦術を伴う場合があります。最後に、期間に基づいて最適な戦術が融合構造として選択されます。融合操作により、ネットワーク層の数が削減され、データ チャネルが短縮されます。同じ構造がマージされてデータ チャネルが広くなり、GPU リソースをより効率的に使用するという目的が達成されます。

• カーネル自動チューニング: ネットワーク モデルが推論しているときに、計算のために GPU の CUDA カーネルを呼び出します。 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 ファイルを取得します。 Profing ファイルを通じて、推論プロセスを明確に確認できます。次の図に示すように、推論全体における一部の演算子のカーネル起動制限現象が深刻であり、一部の演算子間のギャップが大きく、最適化の余地があることがわかりました。

そのために、パフォーマンス分析ツールと変換モデルに基づいてネットワーク全体を分析して、TensorRT が最適化した部分を見つけ出し、ネットワーク内で最適化できる他のサブ構造に対してネットワーク融合を実行します。同時に、そのようなサブ構造がネットワーク全体で一定の割合を占め、融合後にコンピューティング密度をある程度まで高めることができることを確認する必要があります。使用するネットワーク統合方法の種類については、特定のシナリオに従って柔軟に使用できます。

3.3.5エンジン最適化

1. 複数のモデル：フード配信広告のスケールは不確実であり、広告の数が異なるため、各モデルは異なる入力スケールに対応し、複数の固定バッチにマッピングされます。
2. マルチコンテキストとマルチストリーム：各バッチモデルには、複数のコンテキストと複数のストリームを使用します。これは、同じコンテキストを待っているモデルのオーバーヘッドを回避できます。次の図に示すように、単一のストリームは複数のストリームになります。

3. 動的な形状：不確実な入力バッチを備えたシナリオで不必要なデータパディングに対処し、モデルの数を減らし、ビデオメモリなどのリソースの無駄を減らすために、モデルは実際の入力データに基づいて導入され、コンピューティングリソースの不要な無駄を削減します。
4. CUDAグラフ：最新のGPUでの各操作（カーネル実行など）は少なくともマイクロ秒かかり、各操作をGPUに送信することには、いくつかのオーバーヘッド（マイクロ秒）が発生します。実際の推論では、多くのカーネル操作を実行する必要があります。 CUDAグラフは、個々の操作のリストではなくグラフとして計算プロセス全体を定義することでこれを達成し、1つのCPU操作でグラフ上の複数のGPU操作を起動する方法を提供することにより、カーネルの提出と起動のオーバーヘッドを削減することでこれを達成できます。 CUDAグラフの中心的なアイデアは、推論の前後にグラフをキャプチャし、推論の必要に応じてグラフをキャプチャすることにより、1つずつグラフを起動する必要があり、最終的にはカーネルの発射数を減らすという目標を達成する必要があります。以下の図に示すように、1つの推論は4つのカーネル関連操作を実行します。

5. マルチレベルPS ：GPUアクセラレーションエンジンのパフォーマンスをさらに調査するために、埋め込みデータのクエリ操作は、マルチレベルPS：GPUビデオメモリキャッシュ - > CPUメモリキャッシュ - >ローカルSSD/分布KVを介して実行できます。その中で、ホットデータはGPUビデオメモリでキャッシュでき、キャッシュされたデータは、データホットスポットの移行、プロモーション、排除などのメカニズムを通じて動的に更新でき、GPUの並列コンピューティングパワーとメモリアクセス機能を効率的なクエリの完全なタッピングにします。オフラインテストの後、GPUキャッシュのクエリパフォーマンスは、CPUキャッシュを見逃すと比較して、CPUキャッシュにアクセスすることでクエリをすることができます。特定の構造は次のとおりです。

3.3.6パイプライン

モデルの最終的なオンラインロードまでのプロセス全体は、面倒であり、モデルは異なるGPUカード、異なるTensort、Cudaバージョンと互換性がありません。したがって、モデル反復の全体的な効率を改善するために、次の図に示すように、パイプラインに関連する機能を構築しました。

パイプライン構造は、2つの部分で構成されています。オフラインモデルの分割と変換プロセスと、オンラインモデルの展開プロセス：

1. オフライン側：モデル分割ノードを提供する必要があります。プラットフォームは、元のTFモデルを埋め込みサブモデルと埋め込みサブモデルに自動的に分割します。最後に、2つのサブモデルの変換結果は、後続のモデル展開のためにS3に保存されます。プロセス全体がプラットフォームによって自動的に完了し、ユーザーが実行の詳細を認識する必要はありません。
2. オンラインテスト：モデルの展開のためにハードウェア環境を選択するだけです（モデル変換の環境と一致します）。環境構成に基づいてモデルを適応してロードし、モデルの展開を完了し、ワンクリックで起動します。

パイプラインは、構成可能な機能とワンクリック機能を構築することにより、モデル反復の効率を大幅に改善し、アルゴリズムとエンジニアリングの同僚が自分の仕事にもっと集中できるようにします。次の図は、純粋なCPU推論と比較してGPUの実践で達成された全体的な利点を示しています。

4機能サービスコードゲン最適化

特徴抽出は、従来のLRモデルと、ますます人気のある深い学習モデルの両方をモデル化する前駆体です。 Meituan Takeaway機能プラットフォームの以前のブログの構築と実践では、モデル機能の自己記述MFDLに基づいて機能計算プロセスを構成する方法を説明し、オンラインの推定およびオフライントレーニング中にサンプルの一貫性を確保しようとしました。ビジネスの急速な反復により、特にモデル機能の数は増加し続けています。この目的のために、私たちは機能抽出層にいくつかの最適化を行い、スループットと時間消費の両方で大幅な利益を達成しました。

4.1フルプロセスコードゲン最適化

DSLは、機能処理ロジックの説明です。初期の機能計算の実装では、各モデル構成のDSLが解釈されました。解釈された実行の利点は、実装が簡単であり、一般的に使用されるイテレーターパターンなど、優れた設計を通じて優れた実装を達成できることです。実際、モデル構成の固定バージョンの場合、すべてのモデル機能変換ルールが固定されており、リクエストでは変更されません。極端な場合、この既知の情報に基づいて、各モデル機能をハードコード化して最高のパフォーマンスを実現できます。明らかに、モデル機能の構成は大きく異なり、各モデルに対して手動でエンコードすることは不可能です。そのため、CodeGenのアイデアが生まれ、コンパイル中に各構成の独自のコードのセットが自動的に生成されます。 CodeGenは特定のテクノロジーやフレームワークではなく、抽象的な説明言語から特定の実行言語への変換プロセスを完了するアイデアです。実際、業界では、CodeGenを使用してコンピューティング集約型シナリオでコンピューティングを加速することが一般的な慣行です。たとえば、Apache SparkはCodeGenを使用して、1.xのExpressionCodegenから2.xで導入されたwholestageCodegenまでのexpresscodegenの実行パフォーマンスを最適化し、非常に明白なパフォーマンスの利点を達成しました。機械学習の分野では、Tensorflow XLAやTVMなどのTFモデルの加速フレームワークも、コードゲンの概念に基づいており、IRとローカル環境に基づいてスケジューリング最適化を実行します。

SparkのWholestageCodegenを利用して、私たちの目標は、機能計算DSL全体を実行可能な方法にコンパイルして、コードランタイム中のパフォーマンスの損失を減らすことです。コンピレーションプロセス全体を、フロントエンド（フロントエンド）、オプティマイザー（オプティマイザー）、バックエンド（バックエンド）に分割できます。フロントエンドは、主にターゲットDSLを解析し、ソースコードをASTまたはIRに変換します。具体的な実装は以下のとおりです。

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

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

1. オペレーターの読み取り：ストレージシステムから機能を取得するプロセスは、IOタイプのタスクです。たとえば、リモートKVシステムをクエリします。
2. コンバージョンオペレーター：機能がローカルで取得された後、機能が変換されます。これは計算集中タスクです。たとえば、固有値をハッシュします。

したがって、実際の実装では、さまざまな種類のタスクのスケジューリングを検討し、機械リソースの使用率を可能な限り改善し、全体的な時間のかかるプロセスを最適化する必要があります。業界の調査と独自の実践と組み合わせて、次の3つの実装が実行されました。

1. タスクの種類に基づくステージの分類：2つのタイプのステージを取得して計算すると、次のステージが実行されます。これは、初期に使用したソリューションです。しかし、欠点も明らかであり、各段階の長い尾の長い尾が時間のかかるプロセスに影響を与えます。
2. パイプラインベースのステージ部門：異なる段階の長期尾の重ね合わせを減らすために、最初にデータをスライスし、IOタスクが完了した後、タスクが計算されるため、プロセス全体がパイプラインと同じくらいスムーズになります。シェルディングスケジューリングにより、前のステージを事前に次のステージに入る準備ができているため、待機時間を短縮し、全体的な要求時間と長い尾を削減できます。しかし、不利な点は、統一されたシャードサイズが各段階の使用率を完全に改善できないことです。
3. SEDA（段階的なイベント駆動型アーキテクチャ）メソッド：段階的なイベント駆動型メソッドは、キューを使用して段階を分離および取得し、各段階を計算します。これにより、各段階で個別のシャードサイズを選択できるだけでなく、イベント駆動型モデルがプロセスをスムーズに保つこともできます。これが私たちが現在探求している方法です。

コードゲンソリューションも完全ではありません。コードジェンと非同期の非ブロッキングの実装に基づいて、適切なリターンがオンラインで取得されており、時間のかかる機能計算を減らし、CPU負荷を大幅に削減し、システムスループットを改善します。将来的には、ハードウェア命令（ SIMDなど）や不均一なコンピューティング（ GPUなど）の組み合わせを調査して最適化を行うなど、バックエンドのコンピレーションプロセス中にターゲットを絞った最適化を実行し、ターゲットを絞った最適化を実行し続けます。

4.2送信の最適化

オンライン推定サービスは、全体としての2層アーキテクチャです。元のシステムプロセスは、特徴計算の結果をm（予測されたバッチサイズ）×n（サンプル幅）のマトリックスにスプライスし、それをシリアル化して計算層に転送することです。これを行う理由は、歴史的な理由で、多くの初期の非DNNモデルの入力形式がルーティングレイヤーを介してスプライスされた後、コンピューティングレイヤーが変換なしで直接使用できるためです。ただし、モデルの反復開発により、DNNモデルは徐々に主流になり、マトリックス伝送の欠点も非常に明白です。

1. スケーラビリティが低い：データ形式は統一されており、非数字タイプの固有値と互換性がありません。
2. 送信パフォーマンスの損失：マトリックス形式に基づいて、たとえば機能を調整する必要があります。クエリ/ユーザーディメンションを各アイテムに整列させる必要があります。

上記の問題を解決するために、最適化されたプロセスは、輸送層に変換層を追加して、テンソル、マトリックス、オフラインCSV形式など、MDFLの構成に従って計算モデル機能を必要な形式に変換します。実際、ほとんどのモデルはTFモデルです。伝送消費をさらに節約するために、プラットフォームは各テンソルマトリックスを保存するためのテンソルシーケンス形式を設計しました。ここで、R_FLAGはアイテム機能の長さを表すために使用されます。コンパクトなテンソルシーケンス形式に基づいて、データ構造はよりコンパクトであり、ネットワークに送信されるデータの量を減らします。また、最適化された伝送形式は、コンピューティングレイヤーを呼び出すルーティングレイヤーのリクエストサイズも50％以上低下し、ネットワーク伝送時間が大幅に低下しました。

4.3高次元ID機能エンコーディング

ディスクリート機能とシーケンス機能は、機能処理段階を変更して、ハッシュ処理を介して元の機能を変更します。 1,000億レベルの次元の特性に直面している場合、弦のスプライシングとハッシュのプロセスは、表現空間とパフォーマンスの点で要件を満たすことができません。業界調査に基づいて、スロットエンコードに基づいて機能エンコード形式を設計および適用しました。

ここで、feature_hashは、ハッシュ後の元の機能値の値です。整数機能は直接入力できます。非整数機能またはクロス機能を最初に入力した後、44ビットを超えると切り捨てられます。スロットベースのエンコードソリューションが起動した後、オンライン機能計算のパフォーマンスを改善するだけでなく、モデル効果に大幅な改善をもたらしました。

5サンプル構造

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

オンラインおよびオフラインの一貫性の問題を解決するために、業界は一般に、単純なオフラインラベルのスプライシングと機能のバックフィルを介してサンプルを構築する代わりに、オンラインダンプのリアルタイムスコアリングで使用される機能データを使用します。元のアーキテクチャを下の図に示します。

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

1. 準備に長い間：既存のリソースの制限の下では、サンプルデータの準備が整う前にビッグデータはほぼt+2でなければならず、アルゴリズムモデルの反復に影響します。
2. リソースの消費：既存のサンプル収集方法は、すべての要求された機能をスプライスし、露出とクリックでそれらをスプライスすることです。

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

上記の問題を解決するために、業界には2つの一般的なソリューションがあります。特定のプロセスを以下の図に示します。

1. ストリーミングステッチスキーム：ストリーミング処理フレームワーク（フリンク、ストームなど）の低遅延ストリーム処理機能により、エクスポージャー/クリックリアルタイムストリームは、メモリ内の機能スナップショットストリームデータ（結合）に関連付けられ、モデルオフライントレーニングサンプルに変換されます。その中で、ストリーミングサンプルとオフラインサンプルはそれぞれ異なるストレージエンジンに保存され、さまざまな種類のモデルトレーニング方法をサポートしています。このソリューションの問題：データフロープロセスの量は、多くのメッセージフローリソース（ Kafkaなど）を占有します。
2. KVキャッシュスキーム：機能によって抽出されたすべての機能（ Redisなど）は、候補者のキューをリアルタイムコンピューティング（フリンクまたは消費者アプリケーション）に渡します。ストリーミングトレーニングのサポート。この方法は、特性またはトラフィックが増加するにつれて、外部メモリを使用します。しかし、顕著な問題には、大規模なデータをキャッシュするために大きなメモリが必要です。

5.1.2最適化の改善

無効な計算を減らすという観点から、要求されたデータは公開されません。この戦略には、露出したデータに対してより強い需要があるため、処理をストリーミングするために天レベルの処理を事前に配置することで、データの準備時間を大幅に改善できます。第二に、データのコンテンツから、リクエストレベルの変更データとリンクが柔軟に分離および処理され、次の図が大幅に改善されます。

1。データの分割：大規模なデータ送信ボリューム（大きな機能スナップショットフローの大きな問題）、予測されたラベルとリアルタイムデータの問題を1つずつ解決し、リフロー中にオフラインデータに二次アクセスでき、リンクデータフローのサイズを大幅に削減できます。

• サンプルストリームにはコンテキスト +リアルタイム機能のみがあります。これにより、読み取りデータストリームの安定性が向上します。

2。遅延消費結合方法：大きなメモリ占有率の問題を解決します。

• 主流のように、露出ストリームはHBaseに同時に書き込まれます。
• サンプルストリームが遅延すると、バックグラウンドサービスのサンプルストリームは、露出ストリームよりも最初に到着します。

3.機能サンプル：ラベルの結合を通じて、ここでの再入国のリクエストの数はオンラインの20％未満です。露出がスプライシングされた後、露出モデルサービス要求（コンテキスト+リアルタイム機能）がフィルタリングされ、すべてのオフライン機能が補充され、完全なサンプルデータを形成します。

5.2構造化されたストレージ

ビジネスの反復により、機能スナップショットの数が大きくなり、単一のビジネスシナリオで全体的な機能スナップショットが1日あたり数十レベルに達しています。コンピューティングエンジン（Spark）（シャッフルを使用すると、データはシャッフル書き込み段階のディスクに分類されます。割り当てられたメモリが不十分な場合は、複数のドロップと外部ソートが発生します） 、独自のデータのメモリと多数のコンピューティングCUが計算を効果的に完了し、メモリが高いメモリを占有します。サンプル構造プロセスのコアプロセスを以下の図に示します。

機能を補うと、次の問題が存在します。

1. データの冗長性：補足機能のオフラインテーブルは、一般的に完全なデータであり、サンプル構造に使用されるピースの数は、その日、つまり数千万のデータがあります。
2. 結合順序：補完的な機能の計算プロセスは、複数の結合計算があります。したがって、上記の図に示すように、結合計算のパフォーマンスは密接に関連しています。

サンプルの構造効率が遅いという問題を解決するために、短期的にはデータ構造ガバナンスから始めます。

1. 構造化された分割。データは、ハイブリッドストレージの代わりに、コンテキストデータと寸法データの構造化されたストレージに分割されます。新しいラベルサンプルスプライシングプロセス中に大量の冗長データを運ぶ問題を解決します。
2. 効率的なフィルタリングプリマウント。データフィルタリングは参加する前に参加するように進められ、機能計算に参加するデータの量を減らすと、ネットワークIOを効果的に削減できます。スプライシングプロセス中、補足機能のハイブテーブルは一般にフルスケールのテーブルであり、データストリップの数は一般に毎月のアクティブ量であり、実際のスプライシングプロセスで使用されるデータストリップの数は毎日のアクティブな量であるため、データ冗長性が大きくなり、無効なデータが追加のIOと計算をもたらします。最適化方法は、使用されるディメンションキーを事前に計算し、対応するブルームフィルターを生成することです。ブルームフィルターを使用してフィルタリングを使用します。
3. 高性能結合。効率的な戦略を使用して、結合順序を手配して、機能リンクの効率とリソース利用を改善します。機能スプライシングプロセス中に、複数のテーブルの共同操作が行われ、結合の順序もスプライシングパフォーマンスに大きな影響を与えます。上の図に示すように、スプライスされた左のテーブルのデータの量が大きい場合、全体的なパフォーマンスは低下します。 Huffmanアルゴリズムのアイデアを使用して、各テーブルをノードと見なすことができます。したがって、この問題はハフマンツリーを構築するために抽象化することができ、ハフマンツリーの構築プロセスが最適な結合順序です。

データのオフラインストレージリソースは80％+まで保存され、サンプルの構造効率は現在200％+で増加しています。

6データ準備

このプラットフォームは、機能、サンプル、モデルなどの多数の貴重なコンテンツを蓄積しています。機能最適化は、アルゴリズム担当者がモデル効果を改善するためのすべての方法の40％を占めていますが、フィーチャマイニングの従来の作業方法には、長い時間、マイニング効率の低さ、機能マイニングの繰り返しなどの問題があるため、プラットフォームは機能ディメンションでビジネスを強化することを望んでいます。機能の効果を検証し、ユーザーに最終効果インジケーターを推奨する自動化された実験プロセスがある場合、それは間違いなく戦略の学生が多くの時間を節約するのに役立ちます。リンク全体が構築されている場合、将来、異なる機能候補セットを入力して、対応する効果インジケーターを出力する必要があります。この目的のために、このプラットフォームは、機能とサンプルの「追加」、「減算」、「乗算」、「分割」のためのインテリジェントなメカニズムを構築しました。

6.1「追加」を行う

機能の推奨は、モデルテスト方法に基づいており、新しいモデルとベースモデルのオフライン効果を比較するために、他のビジネスラインの既存のモデルへの多重化に基づいています。特定の機能の推奨プロセスを以下の図に示します。

1. 機能認識：機能の推奨は、オンラインの壁またはビジネス間在庫を通じてトリガーされています。
2. サンプルの生成：サンプルの生成中に、構成ファイルを介して機能が抽出されます。新機能を取得した後、これらの機能に依存する元の機能、寸法、およびUDF演算子は解析され、新機能構成と依存した元のデータは、ベースラインモデルの元の構成ファイルに融合して、新しい機能構成ファイルを構築します。新しいサンプル構造を自動的に実行すると、関連する機能が機能名を介して抽出されます。
3. モデルトレーニング：モデル構造とサンプル形式の構成を自動的に変換し、モデルトレーニングを実行し、Tensorflowをモデルトレーニングフレームワークとして使用し、Trecord形式をサンプル入力として使用し、それぞれ数値クラスとIDクラスに従って新機能を入れ、IDクラス機能のテーブル操作を検索し、モデルトレーニングを受信するための新しいサンプルを受信することができます。
4. トレーニング日、サンプルパス、モデルハイパーパラメーターなどを含む新しいモデルトレーニングパラメーターを自動的に構成し、トレーニングセットとテストセットを分割し、新しいモデルを自動的にトレーニングします。
5. モデルの評価：評価インターフェイスを呼び出して、オフラインインジケーターを取得し、新しいモデルと古いモデルの評価結果を比較し、単一の機能を分割した後、単一の機能の貢献度が示されています。評価結果を統一された方法でユーザーに送信します。

6.2「減算」を行う

機能の推奨が広告内に実装され、特定の利点が達成された後、機能エンパワーメントレベルでいくつかの新しい調査を行います。モデルの継続的な最適化により、機能の拡張は非常に高速であり、モデルサービスのリソースの消費は急激に増加しています。したがって、プラットフォームはエンドツーエンド機能スクリーニングツールを構築しました。

1. 機能スコアリング：モデルのすべての機能スコアリングは、WOE（証拠の重み）およびその他の評価アルゴリズムを介して与えられます。
2. 効果検証：モデルをトレーニングした後、バッチ内の機能をスコアリングして排除してソートします。具体的には、特徴破壊方法を使用することにより、元のモデルと壊れたモデルの評価結果が比較され、差が大きくなり、しきい値がしきい値よりも低く、排除できる機能が与えられた後に評価が完了します。
3. 端到端方案：用户配置好实验参数和指标阈值后，无需人为干涉，即可给出可删除的特征以及删除特征后模型的离线评估结果。

最终，在内部模型下线40%的特征后，业务指标下降仍然控制在合理的阈值内。

6.3 做“乘法”

为了得到更好的模型效果，广告内部已经开始做一些新的探索，包括大模型、实时化、特征库等。这些探索背后都有一个关键目标：需要更多、更好的数据让模型更智能、更高效。从广告现状出发，提出样本库（ Data Bank ）建设，实现把外部更多种类、更大规模的数据拿进来，应用于现有业务。詳細は、次の図に示されています。

我们建立了一套通用的样本共享平台，在这个平台上，可以借用其他业务线来产生增量样本。并且也搭建通用的Embedding共享架构，实现业务的以大带小。下面以广告业务线复用非广告样本为例，具体做法如下：

1. 扩样本：基于Flink流式处理框架，建设了高扩展样本库DataBank，业务A很方便复用业务B、业务C的曝光、点击等Label数据去做实验。尤其是为小业务线，扩充了大量的价值数据，这种做法相比离线补录Join，一致性会更强，特征平台提供了在线、离线一致性保障。
2. 做共享：在样本就绪后，一个很典型的应用场景就是迁移学习。另外，也搭建Embedding共享的数据通路（不强依赖“扩样本”流程），所有业务线可以基于大的Embedding训练，每个业务方也可以update这个Embedding，在线通过建立Embedding版本机制，供多个业务线使用。

举例来说，通过将非广告样本复用到广告内一个业务，使样本数量增加了几倍，结合迁移学习算法，离线AUC提升千分之四，上线后CPM提升百分之一。此外，我们也在建设广告样本主题库，将各业务生成的样本数据进行统一管理（统一元数据），面向用户透出统一样本主题分类，快速注册、查找、复用，面向底层统一存储，节约存储、计算资源，减少数据Join，提高时效性。

6.4 做“除法”

通过特征“减法”可以剔除一些无正向作用的特征，但通过观察发现模型中还存在很多价值很小的特征。所以更进一步我们可以通过价值、成本两方面综合考虑，在全链路基于成本的约束下价值最大，筛选出那些投入产出比较低特征，降低资源消耗。这个在成本约束下去求解的过程定义为做“除法”，整体流程如下图所示。

在离线维度，我们建立了一套特征价值评估系统，给出特征的成本和价值，在线推理时可以通过特征价值信息进行流量降级、特征弹性计算等操作，做“除法”关键步骤如下：

1. 问题抽象：如果我们能得到每个特征的价值得分，又可以拿到特征的成本（存储、通信、计算加工），那么问题就转换成了在已知模型结构、固定资源成本下，如何让特征的价值最大化。
2. 成本约束下的价值评估：基于模型的特征集，平台首先进行成本和价值的统计汇总；成本包括了离线成本和在线成本，基于训练好的评判模型，得出特征的综合排序。
3. 分场景建模：可以根据不同的资源情况，选择不同的特征集，进行建模。在有限的资源下，选择价值最大的模型在线Work。另外，可以针对比较大的特征集建模，在流量低峰启用，提升资源利用率的同时给业务带来更大收益。还有一种应用场景是流量降级，推理服务监控在线资源的消耗，一旦资源计算达到瓶颈，切换到降级模型。

7 总结与展望

以上是我们在大规模深度学习工程上的反“增”实践，去助力业务降本提效。未来我们还会持续在以下方面进行探索、实践：

1. 全链路GPU化：在推理层面，通过GPU的切换，支撑更复杂业务迭代的同时，整体成本也极大的降低，后面会在样本构建、特征服务上进行GPU化改造，并协同推进离线训练层面的升级。
2. 样本数据湖：通过数据湖的Schema Evolution、Patch Update等特性构建更大规模的样本仓库，对业务方进行低成本、高价值的数据透出。
3. Pipeline ：算法全生命周期迭代过程中，很多环节的调试，链路信息都不够“串联”，以及离线、在线、效果指标的视角都比较割裂，基于全链路的标准化、可观测大势所趋，并且这是后续链路智能化弹性调配的基础。现在业界比较火的MLOps、云原生都有较多的借鉴思路。
4. 数据、模型智能匹配：上文提到在模型结构固定前提下，自动为模型加、减特征，同理在模型层面，固定一定特征输入前提下，去自动嵌入一些新的模型结构。以及在未来，我们也将基于业务领域，通过平台的特征、模型体系，自动化地完成数据、模型的匹配。

8 本文作者

亚劼、英亮、陈龙、成杰、登峰、东奎、仝晔、思敏、乐彬等，均来自美团外卖技术团队。