02

1. **オープンソース:** コンピューティングリソースプールを可能な限り拡張します。調達はROIの低さを補う手段となるかもしれませんが、既存リソースの最適化が鍵となります。全社的な視点で見ると、リソースの活用は不十分です。オンラインリソースにはピークと谷があり、在庫にはかなりの量のアイドルリソースが存在します。コンピューティングの大部分はオフラインであるため、リソースの安定性に対する要件は高くありません。これら2つの側面を組み合わせることで、リソースの問題を解決するための柔軟なコンピューティングスケジューリングシステムを構築できます。

2. **コスト削減：** サービスパフォーマンスを可能な限り最適化し、単位計算コストを削減します。モデル推論の計算量は膨大ですが、最適化の余地は大きく残されています。モデル構造とGPUハードウェア特性を最適化することで、モデルサービスのシングルカードスループットを大幅に向上させることができます。さらに、CPU処理の最適化や、Baiduが独自開発したKunlunチップの採用など、様々な手法によって単位コストを削減することも可能です。

1.モデルサービスフレームワークとプラットフォーム：モデルエンジニアリングは、統合されたモデルサービスフレームワークとそれをサポートするモデルサービスプラットフォームによって実現されます。モデルサービスフレームワークとプラットフォームは、構築、テスト、デプロイメントに至るまで、モデルサービスライフサイクルのすべての段階をサポートし、カバーします。

2. 特徴量バッチ計算プラットフォーム：オフライン特徴量計算の効率性問題を解決するため、統合バッチ計算プラットフォームを構築しました。オフラインタスク開発から計算までの各段階における効率性とパフォーマンスのボトルネックを分析し、徹底的に最適化することで、効率性を最大限に向上させました。

3.1 全体的なアーキテクチャ

1.モデルサービスフレームワーク：アルゴリズムチームは、サービスのカプセル化に統一されたモデルサービスフレームワークを使用しています。開発効率を高めるため、フレームワーク言語としてPythonを選択しましたが、Pythonはパフォーマンスの問題も深刻であり、多くのターゲットを絞った最適化が必要です。さらに、サービスユニットあたりの計算コストを最小限に抑えるため、様々な推論最適化手法をフレームワークに継続的に統合しています。

2. モデルサービスプラットフォーム：モデルサービスプラットフォームは、モデルサービスのDevOpsと機能出力をサポートします。このプラットフォームでは、「オペレータ」を管理粒度として用い、「オペレータ」はビデオ分類などの完全な機能を表します。ビデオ分類は通常、複数のモデルサービスの連携を必要とします。アルゴリズムエンジニアは、オペレータをプラットフォームに登録し、サービストポロジなどのメタデータを提供します。また、自動パフォーマンスチューニングと自動負荷テストを通じてパフォーマンスレポートを生成します。サービストポロジとパフォーマンスレポートは、後続のスケジューリングに不可欠な入力情報となります。このプラットフォームは、オペレータの検索と試行機能も提供し、プラットフォームベースの方法でその他のビジネスニーズをサポートします。

3. 計算スケジューリングシステム：計算スケジューリングシステムは、トラフィックとリソースの統合スケジューリングを実行します。モデルサービスへのすべてのリクエストは、計算スケジューリングシステムのゲートウェイを通過し、トラフィック制御とルーティングポリシーを実行します。また、計算スケジューリングシステムは、Baiduの複数のPaaSプラットフォームから、アイドル状態のさまざまな異種リソースをスケジュールし、適切なオペレーターを自動的に展開することで、オフラインコンピューティングのスループットを向上させます。

4. バッチコンピューティングプラットフォーム：バッチコンピューティングプラットフォームは、オフラインジョブタスク生成、タスクスケジューリング、DevOpsなどの機能をサポートします。HTAPベースのストレージソリューションを構築することで、スキャンスループットのボトルネック問題を解決し、コンピューティングスケジューリングシステムと連携することで、大規模なオフラインコンピューティングをサポートします。

3.2 主な技術的ポイント

• ビジネスロジックはDAG（有向非巡回グラフ）として記述され、ノードはOpsと呼ばれます。DAGは複数のOpsで構成され、直列または並列に接続できます。Opsはモデル推論または処理ロジックの一部です。Opsはデータホワイトボードを介して互いにコンテキストを渡します。DAGを使用すると、全体的な処理フローが明確になり、コードの可読性と保守性が向上します。

• モデル推論、ビデオフレーム抽出、ビデオ変換といった共通ロジックを汎用Opライブラリに統合し、ビジネスにおける再利用性を高めます。企業は必要に応じてOpをカスタマイズ・拡張し、フレームワークに登録して利用することも可能です。

• 並行処理スキームは、マルチプロセス + 非同期コルーチン + CPU/GPUコンピューティング分離アプローチを採用しています。このサービスには、RPCプロセス、DAGプロセス、モデルプロセスの3種類のプロセスが含まれており、これらは共有メモリ/GPUメモリを介して相互に連携します。

• PRCプロセスはネットワーク通信を担い、BRPC（オープンソース版：https://github.com/apache/brpc）をベースに開発されています。Pythonマルチプロセスとコルーチンの並列モードをサポートするために、BRPCのPython実装を最適化しました。実際のビジネスシナリオテストでは、最適化後のパフォーマンスが5倍以上向上しました。

• DAGプロセスはDAG実行（CPU処理）を担い、複数のDAGプロセスとオペレーションの非同期コルーチン実行によってCPUマルチコアを最大限に活用します。もう一つの重要なプロセスはModelOpです。これは実際には推論エージェント（RPCに類似）です。実際の推論はローカルのモデルプロセスまたはリモートサービスで実行されます。ModelOpは呼び出しの詳細を隠蔽するため、ユーザーはモデルを簡単に利用できます。

• モデルプロセスは、モデル推論（GPU処理）を担当します。GPUメモリの制限を考慮し、モデルプロセスとDAGプロセスは独立して分離されています。モデルプロセスはPyTorchやPaddleといった複数の推論エンジンをサポートし、多くの推論最適化が行われています。テンソルデータは通常大きいため、DAGとモデルプロセスは共有GPUメモリを直接使用してテンソルを転送することで、不要なメモリコピーを回避しています。

1. 推論スケジューリング：動的バッチ処理とマルチストリーム実行。GPUバッチコンピューティングはより効率的です。サービスはリアルタイムの単一リクエストも受け入れるため、リクエストをバッチ処理することはできません。そのため、リクエストをバッチ処理するためにインサービスキャッシュが使用され、スループットのためにレイテンシが犠牲になります。ストリームはGPUタスクキューと見なすことができます。デフォルトでは単一のグローバルキューであり、タスクはシリアルに実行されます。GPU I/O操作（メモリコピー）中は、コンピューティングユニットはアイドル状態です。複数のストリームを作成することで、異なる推論リクエストは異なるストリームを使用できるため、I/Oと計算を完全に並列化できます。

2. 推論の最適化：業界ではTensorRTを使用するのが主流ですが、実際のアプリケーションでは、動的グラフの静的化の失敗やTensorRT Opsの不完全なカバレッジなどの問題があります。これらの問題を解決するために、チームはPoros（オープンソース版：https://github.com/PaddlePaddle/FastDeploy/tree/develop/poros ）を開発しました。これは、TorchScript、グラフ最適化、TensorRT、vLLMなどの技術を組み合わせ、わずか数行のコードを追加するだけで、複雑なモデル変換なしに推論性能を大幅に向上させます。これにより、効率と性能の双方にメリットをもたらします。同時に、PorosはKunlunなどの異種ハードウェアもサポートしています。

3. モデルの量子化：GPUやKunlunなどのハードウェアは、低精度に対して強力な計算能力を備えています。量子化は効果の損失はわずかですが、スループットを大幅に向上させます。そのため、実稼働環境ではFP16、あるいはINT8/INT4の量子化が用いられます。この部分もPorosでサポートされています。

4. モデル圧縮：これは、モデル蒸留やモデルプルーニングなどの手法を用いてモデルパラメータを簡素化し、計算量を削減することを意味します。ただし、学習が必要であり、有効性もある程度低下します。通常はアルゴリズムエンジニアと共同で実施されます。

1. CRD拡張：Kubernetes CRDを利用してServiceBundle（オペレータデプロイメントパッケージ）などのオブジェクトをカスタマイズし、コントローラーメカニズムを用いてPaaSなどの外部システムへのデプロイメント操作を実行します。ServiceBundleには、オペレータが必要とするすべてのサブサービスのデプロイメント情報とトポロジが含まれています。オペレータサービスのスケジュールと作成時には、最下層から順にサブサービスが作成されます。上位層のサブサービスは、通信ホスティングメカニズムを介して下流のサブサービスのアドレスを取得できます。

2. 通信ホスティング：通信ホスティング機構は、構成センターとモデルサービスフレームワークに基づいて実装されています。サービス起動コマンドは、リモート構成アドレスとAppIDを伝達します。リモート構成をロードすることで、起動時に下流のサービスアドレスを変更できます。理想的な解決策は、ServiceMeshなどの技術を用いて、アーキテクチャ機能とビジネス戦略を分離することです。しかし、複数のPaaSプラットフォームに展開していることを考えると、各PaaSにServiceMesh SideCarコンポーネントを展開するのはコストが高く、フレームワークへの統合も負担が大きすぎます。そのため、まずは構成センターベースのソリューションを構築し、適切な時期が来たら移行を検討します。

1. オペレータスケジューリング：オペレータ（複合サービス）が処理できるトラフィック量は、最も弱いサブサービスの容量に依存します。スケジューリングでは、最も強いサービスにリソースを無駄に費やさないように、総合的な考慮が必要です。

2. トラフィック分布の変化：一部のオペレータのパフォーマンスは、入力データの分布によって影響を受ける可能性があります。例えば、ビデオOCRはビデオの長さや画面上のテキストの割合に影響を受けるため、スケジューリング時に適応的な調整が必要になります。

3. 複数の異種ハードウェア：一部の演算子は複数の異種ハードウェア（Kunlun/GPU/CPUなど）をサポートできますが、他の演算子は1つのタイプにしかバインドできません。グローバルリソースを最も効率的に使用するために、どのようにリソースを割り当てるべきでしょうか？

4. その他の要因：タスクの優先度、リソースの優先度、リソースの変動などもスケジュールに影響します。実際のスケジュール作成では、様々な要因を考慮する必要があります。

1. 2段階スケジューリング：スケジューリングは、トラフィックスケジューリングとリソーススケジューリングという2つの独立した段階に分かれています。トラフィックスケジューリングは、現在のオペレータサービスキャパシティを各ジョブに割り当て、結果をゲートウェイに同期し、トラフィックポリシーを調整する役割を担います。リソーススケジューリングは、リソースの可用性とオペレータキャパシティのギャップに基づいてスケジューリングを行い、最終的にオペレータサービスインスタンスのスケールアップまたはスケールダウンを行います。

2. トラフィックスケジューリング：トラフィックスケジューリングの調整フェーズでは、タスクのパフォーマンス指標に基づいて正規化係数を調整し、各タスクに必要なQpsを正規化Qpsにマッピングします。正規化Qpsは、その後のすべてのスケジューリングの基準となるため、トラフィック配分の変動による影響を軽減します。ソートフェーズでは、ジョブを優先度に基づいてソートし、割り当てフェーズでは、ソート結果と優先度に基づいて、各ジョブに既存のオペレータキャパシティを割り当てます。バインドフェーズでは、結果を実行し、ゲートウェイへのルートを同期します。

3. リソース スケジューリング: リソース スケジューリングの準備フェーズでは、まずジョブの容量ギャップが対応するサービス インスタンス ギャップに変換されます。次に、HardwareFit を実行して、拡張するサービスを適切なハードウェア リソース キューに割り当て、リソースの不足、コンピューティングの費用対効果などに基づいて Sort を実行します。次に、PreAssign を実行して各サブサービスにリソースを事前に割り当てます。最後に、GroupAssign フェーズで複合サービスの各サブサービスのスケジュールの満足度を考慮し、複合サービスの各サブサービスの容量を微調整して、リソースの無駄を回避します。

1.読み取り/書き込みの混在：OLTP（フェッチや更新など）とOLAP（機能のバッチ計算など）の両方の要件がテーブルにアクセスするため、複数の読み取り/書き込み方法が混在することになります。基盤となるストレージはHDDを使用しているため、このような読み取り/書き込みの混在により、ディスクI/Oスループットが大幅に低下します。

2. スキャン増幅：テーブルはストレージにワイドテーブル構造を採用しています。通常、様々なタスクはスキャン時に数列しか必要としませんが、テーブル全体をスキャンする場合は、データ行全体を読み取り、フィルタリングする必要があるため、深刻なIO増幅が発生します。

3. 高い拡張コスト：OLTPとOLAPの読み取りと書き込みが混在するため、スキャン容量を個別に拡張するにはコストがかかります。また、読み取りと書き込みの比率を固定することが難しいため、拡張リソースを予測することが困難です。

1. OLAP/OLTP ストレージの分離: バッチ コンピューティングなどの OLAP シナリオ向けに効率的な OLAP ストレージを構築し、OLAP/OLTP テーブルの混在使用によって発生する読み取り/書き込みの混在問題を軽減します。また、必要に応じて個別に拡張することもできます。

2. 高効率OLAPストレージ設計：当社が独自に開発したOLAPストレージは、RocksDBとAFS（BaiduのようなHDFS）上に構築され、増分同期、行データパーティショニング、および動的列データマージ設計を採用しています。テーブルデータ全体をN個の物理パーティションに分割し、テーブルの増分スナップショットを使用して、OLAPストレージデータを定期的かつ効率的に同期・更新します（基礎テーブルはLSMストレージを使用しているため、増分スナップショットはフルスキャンよりもはるかに効率的です）。列ストレージは、フィールドアクセスホットスポットに基づいて再編成され、頻繁にアクセスされる列を物理層にまとめて保存することで、IO増幅を減らし、動的な調整をサポートします。このソリューションにはデータ同期のレイテンシの問題がある可能性がありますが、当社のシナリオでは、適時性の要件は高くないため、この問題は無視できます。

3. HTAP SDK : テーブルストレージとOLAPストレージの両方へのアクセスをサポートする統合SDKを提供します。ユーザーはSDKに基づいて、独自のOLAPタスクとOLTPタスクを同時に実行できます。

• 構成可能: 一般的で頻繁に使用されるタスク タイプの場合、プラットフォームはこれらのタスクを高度にカプセル化しており、Web インターフェイスで構成するだけで生成できます。

• KQL : KQL は、SQL に似た独自開発の言語で、様々な汎用関数を提供し、ユーザー定義関数（Spark UDF に類似）もサポートしています。ユーザーは KQL を使用してデータのクエリと処理を行うことができます。

• オフライン フレームワーク: フレームワークは、データの読み取りと書き込み、一般的な変換などの機能を提供します。ユーザーはフレームワークの仕様に従ってロジックをカスタマイズし、オフライン タスク展開パッケージを生成してプラットフォームに送信し、プラットフォームがタスクをスケジュールします。