JP6539236B2 - 効果的なニューラルネットワークの配置に用いるシステム及び方法 - Google Patents

Description

本出願はネットワーク管理に関し、より具体的には、例えばニューラルネットワーク配置のような計算集約的な問題に用いるシステム及び方法に関する。

[優先権主張]
本出願は２０１５年９月４日に出願された第６２／２１４，８１６号米国特許出願の優先権と、本出願は２０１６年７月１３日に出願された第１５／２０９，４９９号米国特許出願の優先権とを主張し、前記特許文献がその全部内容及びすべての目的のために援用するように本願に組み込んだ。

図１はディープニューラルネットワークを配置するための従来の典型的なアーキテクチャを示す。リクエストがインターネットを介してデータセンターにストリーミングされる。これらのリクエストはロードバランサ１０２でデータセンター１１０にある複数のサーバー１０４の中の１つにルーティングされる。各リクエスト１０６はこれらのサーバー１０４の中の１つに実行されている単一のワーカースレッドで処理され、その後、サーバー１０４が結果１０８を戻す。

１つのスレッドのみで各ニューラルネットワークの中の１つを実行するためのコードを実行する必要があるので、コードが容易に書き込まれて、このため、アーキテクチャ１００を理解しやすい。ワーカースレッドは直ちに各リクエスト１０６を処理するため、更に遅延を容易に推論し、且つ遅延は一般的に最小化されたものである。最後、各リクエスト１０６は単独に処理されるので、当該アーキテクチャによりフェイルオーバーをより容易に推論する。

システム１００を実施しやすいが、非常に効果的なものではない。このため、より効果的なニューラルネットワーク配置を提供するとともに処理要求を満たすシステム及び方法が必要である。

一つの様態において、本出願は、データ処理リクエストのスループットを向上させるバッチ方法を提供し、この方法は、少なくとも部分的に未知のタイミングで、ニューラルネットワークモデルを使用することにより処理しようとする、１つ又は複数の制約で制限されるリクエストに関連するデータを受信するステップと、前記１つ又は複数の制約における少なくとも１つを利用して、前記データにおける少なくとも一部をバッチに動的集合するステップと、複数のスレッドを統合する単一スレッドにより前記バッチを処理し、メモリから前記ニューラルネットワークモデルにロードされた負荷をシェアリングし、データスループットを向上させるステップと、を含む。

もつ一つの様態において、本出願は、ニューラルネットワークモデルに関連するリクエストを処理するためのバッチ処理システムを提供し、このシステムは、１つ又は複数の計算設備を含み、各計算設備は、少なくとも１つのプロセッサ及び記憶設備と、異なるリクエストに関連するデータを受信し、更に１つ又は複数の制約により少なくとも２つ異なるリクエストからのデータブロックをバッチに動的集合するバッチビルダーアセンブリと、前記バッチビルダーと通信可能に連結されて、複数のスレッドを統合する単一スレッドにおいて前記バッチを処理し、メモリから前記ニューラルネットワークモデルにロードされた負荷をシェアリングし、データスループットを向上させる計算エンジンアセンブリと、を含む。

さらに、もつ一つの様態において、本出願は、バッチビルダーを提供し、このバッチビルダーは、１つ又は複数の指令シーケンスを含む非一時的コンピュータ可読媒体を含み、前記１つ又は複数の指令シーケンスが少なくとも１つのプロセッサで実行される場合に、少なくとも部分的に未知のタイミングで、ニューラルネットワークモデルを使用することにより処理しようとする、１つ又は複数の制約で制限されるリクエストに関連するデータを受信するステップと、前記１つ又は複数の制約における少なくとも１つを利用して、前記データにおける少なくとも一部をバッチに動的集合するステップと、複数のスレッドを統合する単一スレッドにより前記バッチを処理し、メモリから前記ニューラルネットワークモデルにロードされた負荷をシェアリングし、データスループットを向上させるステップと、が実行される。

本出願の実施形態を参照して、これらの実施形態の例示が図面に示されてもよい。図面は説明するためのものだけであり、限定するためのものではない。本出願はこれらの実施形態のコンテキストにおいて総体に説明したが、これらの説明が本出願の範囲をこれらの具体的な実施形態に限定するためのものではないことを理解すべきである。図面におけるアイテムは一定の縮尺で描かれていない。

ディープニューラルネットワークを配置するための典型的なアーキテクチャ構成を示す。 本出願の実施形態に係るニューラルネットワークを配置するためのアーキテクチャ構成を示す。 本出願の実施形態に係るニューラルネットワークの配置に利用可能な例示的なサーバーアーキテクチャを示す。 本出願の実施形態に係るニューラルネットワークの配置に用いられてデータ処理リクエストのスループットを増加する例示的なバッチ方法を示す。 本出願の実施形態に係る前処理を利用する例示的なバッチ方法を示す。 従来の設定において８０ ｍｓ内において４つのストリームからのデータブロックを処理する場合のグラフを示す。 本出願の実施形態に係る、バッチ設定において８０ ｍｓ内に２０個のストリームからのデータブロックを処理する場合の例示的なグラフを示す。 本出願の実施形態に係る計算設備／情報処理システムの簡略化したブロック図を示す。

以下の明細書において、解釈するために、具体的な細部を説明することにより本出願に対する理解を提供する。しかし、当業者にとって、明らかに本出願はこれらの細部がない場合にも実現されることができる。なお、当業者は、以下のように、本出願の実施形態が多種の様態、例えば有形のコンピュータ可読媒体での過程、装置、システム、設備又は方法で実現されることができると認識すべきである。

図面に示すアセンブリ又はモジュールは本出願の例示的な実施形態の説明であり、本出願の混乱を避けるためものである。理解すべきであることは、明細書全体において、アセンブリがサブユニットを含むことができる単独な機能ユニットと記述されてもよいが、当業者は、各アセンブリ又はその部材が単独なアセンブリに区分されることができ、又は統合される（単一のシステム又はアセンブリの内部に集積されることを含む）ことができることを認識すべきである。本文に議論された機能又は操作がアセンブリとして実現されることができることを注意すべきである。アセンブリはソフトウェア、ハードウェア又はその組み合わせとして実現されることができる。

なお、図面内のアセンブリ又はシステムの間の接続は直接接続に限定されない。より具体的には、これらのアセンブリの間のデータは中間アセンブリで変更され、フォーマット再プログラミングされ、又は他の方式で改変されることができる。また、付加的接続又はより少ない接続を利用することができる。また、注意すべきであることは、用語「連結」、「接続」又は「通信連結」が直接接続、１つ又は複数の中間設備で実現される非直接接続及び無線接続を含むことを理解すべきである。

明細書において、「１つの実施形態」、「好ましい実施形態」、「実施形態」又は「各実施形態」とは、実施形態を合わせて説明した具体的な特徴、構造、特性又は機能が本出願の少なくとも１つの実施形態に含まれ、且つ１つの以上の実施形態に存在することができることを意味する。また、本明細書における各箇所には、上記語句の出現は必ずしもすべて同じ実施形態を参照しない。

明細書における各箇所において、一部の用語の使用は例示するためであり、限定と解釈されるべきではない。サービス、機能又はリソースは単一のサービス、機能又はリソースに限定されず、これらの用語の使用は分散式又は集合式の１組の関連サービス、機能又はリソースであってよいことを示すことができる。

用語「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｃｏｍｐｒｉｓｅ）」及び「有している（ｃｏｍｐｒｉｓｉｎｇ）」はオープンエンドの用語と理解すべきであり、以下の任意のリストは例示だけであり、リストされる項目に限定されることを意味しない。本文に使用される任意のタイトルは組織するためのものであり、本明細書又は請求項の範囲を限定すべきではない。

なお、当業者は、（１）あるステップを選択的に実行してもよい。（２）ステップは本文に述べた具体的な順序に限定されない。（３）あるステップを異なる順序で実行してもよい。（４）あるステップを同時に実行してもよいことを理解すべきである。

現在の特許開示には例示としてニューラルネットワーク配置及び分類リクエストが利用されるが、本出願がこれに限定されず、本出願の様々な様態は他の目的のために応用又は実施されることができ、他の計算集約的な問題を含むが、これらに限定されないことを注意すべきである。

Ａ. 概要
広告プレースメント、画像及びビデオ認識、音声認識、言語処理、ウェブページ捜索などを含む様々な分野において、ディープニューラルネットワークは日々重要なものになる。多くの重要タスクに対して、ディープニューラルネットワークは比較的良好な精度を提供するが、大規模なディープニューラルネットワークの配置は高価なものである可能性がある。これは主に大量の数学演算を必要とする可能性がある大型ニューラルネットワークを使用する分類データ点の計算負荷に起因する。

典型的なデータセンターのアーキテクチャは大型ニューラルネットワークの配置を複雑にする。リクエストがインターネットを介して進入することに従って、データセンターは複数のサーバーでこれらのリクエストに対してロードバランシングを行う。信頼できるサービスを提供するために、サーバー又はネットワークが故障した場合に、データセンターは更に、リクエストが改めてルーティングされる可能なフェイルオーバー能力を提供すべきである。なお、インターネットサービスは低遅延応答を要求することによりサービスのインタラクティブを保持する傾向がある。これらの要求はニューラルネットワークを配置するための従来システムの生成をもたらし、従来システムにおいて、各リクエストはロードバランサで計算を実行するワークサーバーに送信される。各リクエストは、サービスが単一スレッドで提供されて、遅延及び弾性要求を制御する。

計算から考えれば、プロセッサを使用して複数の独立スレッドからの複数のリクエストにサービスを提供することは最も好ましいものではない。これは、各スレッドがメモリから同じニューラルネットワークモデルを繰り返してロードするからである。単一スレッドにおいて複数のリクエストにサービスを提供することはより効果的であり、スレッドプールを組織化（orchestrate）してメモリからニューラルネットワークモデルをロードする負荷をシェアリングすることによって、負荷の再利用を促進する。換言すれば、スレッドとユーザ（ユーザがそれぞれ単独にニューラルネットワークモデルをロードする複数のスレッドに割り当てられる）との一対一の関係を除去して、代わりに、１つのスレッドを使用してすべてのリクエストを総合的に処理することにより、複数のスレッドはニューラルネットワークのロード及び（マトリックスからマトリックスへの乗算）計算の実行の際に協力し合うことができる。

本文にはバッチシステム及び方法の実施形態を提供し、当該システム及び方法は公共ニューラルネットワークモデルの単一スレッドをシェアして複数のリクエストを総合的処理することを可能にさせ、これにより、各リクエストの計算がより効果的になる。実施形態において、バッチシステムを構築することによりリクエストを分類する効率を明らかに向上させ、同時に厳しい遅延制約を満たすとともにインタラクティブを保持する。バッチシステムの実施形態は分類リクエストを完全に形成された環境で使用されることができるだけでなく、データストリームに対して分類を実行する際に使用されることができる。

以上のように、典型的なアーキテクチャを容易に推論することができるが、その計算効率が低い。これは、主に実際に多くの場合に同じモデルを使用したが、各ワーカースレッドがニューラルネットワークモデルを独立にロードするからである。このため、ニューラルネットワークを配置する従来方式はメモリから同じニューラルネットワークモデルをロード及びリロードする必要があるので、大量のメモリ帯域幅を浪費した。したがって、ニューラルネットワークの構成をより効果に配置するシステム及び方法を実現することを期待とする。

Ｂ. 例示的な実施形態の実現
図２は本出願の実施形態に係るニューラルネットワークを配置するためのアーキテクチャ構成を示す。アーキテクチャ２００は、データセンター２１０を含み、データセンター２１０はロードバランサ２０２及び１つ又は複数のサーバー２０４を含んでもよく、１つ又は複数のサーバー２０４はそれぞれバッチビルダー２１４及び計算エンジン２１６を含む。

実施形態において、図１に示すように、ロードバランサ２０２はデータセンター２１０におけるサーバー２０４にリクエスト２０６を送信する。実施形態において、ロードバランサ２０２はデータセンター２１０のサーバー２０４でリクエストをバランシングすることによりサーバーの使用効率を保持する。実施形態において、既に具体的なサーバー２０４に送信されたリクエストのために到達したデータは同一のサーバー２０４にルーティングされる。図２におけるサーバー２０４は、バッチビルダー２１４を含み、実施形態において、バッチビルダー２１４はリクエスト２０６を、計算エンジン２１６に入力されたデータ処理リクエストのバッチに動的集合する。実施形態において、バッチビルダー２１４はアプリケーションレベル制約（例えば、分類に必要な端末ユーザの計算遅延を実行する）又は計算エンジン２１６の性能又はこの両者に基づいてバッチを生成する。

実施形態において、バッチビルダー２１４で生成されたリクエストバッチはデータブロックを含む。データブロックの長さがロードバランサ２０２で送信されてデータセンター２１０に到達するデータパック２１２の長さと同じである必要がないことを理解すべきである。

図３は本出願の実施形態に係るニューラルネットワークの配置に利用可能な例示的なサーバーアーキテクチャを示す。当該アーキテクチャの実施形態は任意の計算エンジンを効果的に使用することを可能にさせ、ニューラルネットワークの分類を実行する。例えば、中央処理装置（ＣＰＵ）３１２、加速器３１４（例えばフィールドプログラマブルゲートアレイ（ＦＰＧＡ）、グラフ処理ユニット（ＧＰＵ））又は任意の他の処理／情報処理設備でマルチスレッドの実現方式を使用することができる。実施形態において、図３に示すように、計算エンジンはメインサーバーＣＰＵ ３０８とメモリ３０６をシェアするプロセッサ３０５で実現することができ、又は既にその自身のメモリ３２０を有するプロセッサ３１０で実現することができる。

実施形態において、バッチビルダーはリクエストデータ及び結果（例えば、加速器３１４にデータを伝達するか、又は加速器３１４からのデータを伝達する）を伝達する際に関連する遅延を隠すことに用いることができる。例えば、バッチビルダーはリクエストを受信することができるとともに計算エンジンにバッチを送信することができる。次のバッチからのデータを受信する同時に前のバッチからのデータを伝達するので、バッチビルダーは遅延を効果的に隠すか又は低減することができる。

ニューラルネットワークを推定する際に本出願の実施形態が従来の方法に比べて効果的であり、バッチビルダーで生成されたバッチは複数のユーザからのデータを含むとともにシェアされるニューラルネットワークモデルで処理されるからであることを注意すべきである。かなり長い時間において、既に多種のタイプのプロセッサの演算強度が向上された。これは、メモリ帯域幅が相対的により重要になり、数学演算が相対的にコストが低くなることを意味とする。これによりメモリ帯域幅を節約し、したがって、プロセッサの演算強度がより高くなる場合に特に有利である。本出願の実施形態は更にスループット指向のプロセッサ、例えば大量の作業を必要とし効率を飽和させるＧＰＵに良く適用される。

以下、一般的且つ挑戦的な場合に対して例示的な実現方式を提供し、一定の長さ又は可変長さを有する、順序があるパケットシーケンスを含むストリーム入力を分類するとともに、遅延制約を満たすことに関する。実施形態において、各パケットを（無意味な）ストリームを有する最後のパケットに指定することにより、ほぼ同じ方式で非ストリーム入力を処理する。

本文に使用されるように、用語「リクエスト」、「ユーザリクエスト」、「データ処理リクエスト」、「ストリーム」、「ストリーム入力」及び「データストリーム」は互換的に使用されてもよい。用語「ユーザ」と「ストリーム」との関連は、各ストリームが単一のユーザに関連することである。用語「ブロック」はニューラルネットワークの入力大きさに関連するデータの大きさを示す。用語「パケット」はネットワークで伝送することができる１組のデータを示すと理解されるべきである。用語「パケット」は本出願の実施形態をイーサネット（登録商標）又は三層構造ネットワークに制限すると解釈されるべきではない。用語「パケット」、「フレーム」、「データ」、「データグラム」、「セル」又は「データトラフィック」は互換的に使用されてもよく、且つ１組のデータを示す他の用語で代替されてもよい。

ニューラルネットワークモデルでデータを処理することを仮定したが、当業者は、本出願の実施形態によれば、他の技術、モデル又はネットワークを利用してデータを処理することができることを理解すべきである。

「データ」とは、複数のタイプの入力データにおける任意の入力データである。例えば、音声設定において音声を転写する場合、各パケットは複数のミリ秒（例えば、８０ｍｓ）の音声周波数を示すことができる。ビデオ環境において、各パケットは現在の画像と前の画像との間の差別を示すことができる。画像認識において、各パケットは画像全体のタイルを示すことができる。

実施形態において、遅延制約はストリームにおける最後のパケットが到達した後に一定の時間量においてストリーム全体を処理することを表明することができる。これは、
Ｔストリーム全体処理＜Ｔ最後のパケット到達＋Δ許容可能な遅延と示されることができる。

Ｔストリーム全体処理はストリーム全体の処理を完成すべきである時間を示し、Ｔ最後のパケット到達は最後のパケットの到達時間を示し、及びΔ許容可能な遅延はアプリケーション依存の許容可能な遅延を示す。遅延が一般的に非常に厳しいオンライン設定において、Δ許容可能な遅延は１秒間より小さいことが好ましい。

実施形態において、１つの目標は同時にできるだけ多いストリームを処理し、且つ遅延制約（例えば、高いスループットを保持する）を満たしてよい。対照的に、従来方法はそれぞれ独立に各ストリームを処理することにより、低遅延を確保するとともに柔軟性を保持する。

本出願の実施形態において、複数のリクエストは同時にニューラルネットワークを実現する計算エンジンに伝送されるようなモデル／アーキテクチャを応用した。実施形態において、バッチ方法を使用することによりニューラルネットワークは単一ユーザのためにデータを処理する方式と類似する方式で同時に存在する複数のユーザのためにデータを処理する。図４は本出願の実施形態に係るニューラルネットワークを配置することによりデータがリクエストを処理するスループットを向上させる例示的なバッチ方法を示す。ステップ４０２において、バッチビルダーが例えば非同期方式でユーザに関連する複数のパケットを含むデータ処理リクエストを受信する場合、バッチ方法を起動する。パケットはそれぞれのユーザに関連するストリームに到達することができる。パケットは例えば複数のユーザからのデータストリームをロードバランシングするロードバランサによって到達されることができる。実施形態において、パケットの到達時間は未知のものであってよく、アプリケーションレベル制約で制限され、例えば遅延制約、計算エンジンの性能特性等である。

ステップ４０４において、バッチビルダーはアプリケーションレベル制約内でリクエストからのデータをバッチに動的集合し、当該バッチは１つ又は複数のリクエスト（例えば状態リクエスト）からのデータを含む。

ステップ４０６において、メモリに一回のみロードする及び／又はメモリからロードされた公共ニューラルネットワークを利用して当該バッチを処理（例えば、音声周波数ストリームに分類を実行する）し、それにより計算遅延要求を低減し、これによりデータストリームのスループットを増加する。

ステップ４０８において、結果を出力し、例えば分類結果を出力する。このため、メモリ帯域幅を節約するとともに計算効率を向上させる。

実施形態において、バッチビルダーは単一スレッドで実行し、且つ以下のタスクを有する。
ａ）データを前処理する。
ｂ）前処理されたデータを、複数のユーザでシェアされるバッチマトリックスにパッケージする。
ｃ）計算エンジンに当該バッチマトリックスを転送する。

実施形態において、バッチビルダーは３種のタイプのデータ構造を維持する。
１）各ユーザに用いる入力バッファ。
２）各ユーザに用いる前処理バッファ。
３）バッチのリンクリスト（即ち、ニューラルネットワークに入力されたマトリックス）、バッチリストと示されてもよい。例えば音声又はビデオ処理のアプリケーションにおいて、ニューラルネットワークは計算エンジンが正確的な出力を生成するように、所定の順序に従ってバッチを処理することができる。実施形態において、２つ又はより多いユーザの間でバッチをシェアすることができる。実施形態において、前処理を実行しなくてもよい。

図５は本出願の実施形態に係る前処理を使用する例示的なバッチ方法を示す。ステップ５０２において、具体的なユーザに用いるパケットがバッチビルダーに到達する際にバッチ方法を起動する。

ステップ５０４において、データを当該ユーザに用いる入力バッファにコピーし、その後パケットを廃棄してもよい。

ステップ５０６において、入力バッファを前処理する。前処理の例示は音声周波数信号をスペクトログラム及び他の処理に変換することである。実施形態において、前処理を実行しなくてもよい。

前処理が完成した場合に、ステップ５０８において、結果を当該ユーザに用いる前処理バッファに置く。一部のアプリケーションにおいて、前処理がデータブロックに発生してもよい。例えば、音声システムは、大きさが一定であることが必要とされる音声入力ウィンドウのスペクトログラムを頻繁に使用する。その結果、実施形態において、次のパケットからのデータがない場合に、ユーザのパケットを前処理することを確保できない可能性がある。

実施形態において、ステップ５１０において、前処理バッファの大きさが少なくともニューラルネットワークに必要な入力と同じである場合に、前処理バッファからバッチリストにおける次の合格のバッチにブロック（その大きさがニューラルネットワーク入力の大きさによって確定されることができる）を伝達する。実施形態において、合格のバッチに対して、現在のユーザのために処理される任意のデータを含むべきではない。実施形態において、バッチの大きさが制限されて、バッチ全体も不合格になる。画像又はビデオ認識アプリケーションにおいて、ブロックは画像全体を示してもよく、音声認識アプリケーションにおいて、ブロックは一定長さの入力スペクトログラムを示してもよい。

実施形態において、ステップ５１２には、バッチビルダーはすべてのアクティブユーザで循環することができ、それにより当該バッチを充填する。

ステップ５１４において、バッチビルダーはその後に計算エンジンに１つ又は複数のバッチを送信するかどうかを判定することができる。実施形態において、判定を行うための複数の方式が存在する。

１）１つの簡単な方法は、計算エンジンが忙しくない場合のみにバッチを送信する。
２）他のより構造化の方法は、以下の条件の中の１つを満たす場合にバッチを送信する。
ａ）バッチは次のパケットが既に到達したユーザのデータを含み、計算エンジンの処理時間にバッチビルダーにより追加の繰り返しを行うことに必要な時間を加えると遅延制約を超える。
ｂ）バッチリストは十分に充填されて、それにより任意のアクティブユーザに対しての最後のパケットが現在に到達すると、遅延制約を満たすことが不可能性である。

実施形態において、後の方法を実施するために、システムの異なる部分に対して、合理的で高精度に処理時間を定義することは必要なものである。より有効であるために、実施形態において、バッチビルダーは遅延に対して敏感なバッチと、大きいがより効果的な、スループット指向のバッチ統合することができ、ここで、遅延に対して敏感なバッチは、高い優先度であるが低い計算効率で実行することにより遅延制約を満たすことができ、スループット指向のバッが大部分の計算作業を処理する。実施形態において、バッチビルダーは処理が終了するまで継続的に繰り返される。

遅延制約が８０ ｍｓである案を考えて、１つのユーザに対して、計算エンジンは２０ ｍｓがかかってデータブロックを処理し、１０個のユーザからなるバッチに対して、計算エンジンは４０ ｍｓがかかってデータブロックを処理する。従来例示において、遅延制約を満たすために、同時に４つのストリームのみからのデータを処理してもよい。図６は従来設定において１つのユーザが毎回に８０ ｍｓにおいて４つのストリームからのデータブロックを処理する場合のグラフを示す。

対照的に、本出願の各実施形態に係るバッチ方法を利用して、毎回に１０個のユーザからなるバッチにおいて同時に２０個のストリームからのデータブロックを処理することができる。図７は、本出願の実施形態に係る、バッチ設定において８０ ｍｓ内に２０個のストリームからのデータブロックを出力する場合の例示的なグラフを示す。「＋」で表すブロックとは、当該ストリームからのデータブロックが処理されていることであり、「−」で表すブロックとは、ストリームが遮断されることである。

当業者は、計算エンジンの計算時間と遅延要求との間の差異が大きいことが、バッチングのチャンスをより大きくすることを理解すべきである。

実施形態において、本特許文献の様々様態は情報処理システム／計算設備に関してもよい。本出願の目的として、情報処理システムは、商業、科学、制御又は他の目的に基づいて解答、計算、確定、分類、処理、輸送、受信、検索、開始、ルーティング、切替、記憶、表示、伝送、出現、検出、記録、コピー、操作又は任意の様態として操作された情報、インテリジェンス又はデータの任意の装置又は装置セットを含んでもよい。例えば、情報処理システムはパーソナルコンピュータ（例えば、ラップトップコンピュータ）、タブレットコンピュータ、タブレット電話、パーソナルディジタルアシスタント（ＰＤＡ）、スマートフォン、スマート腕時計、スマートパッケージング、サーバー（例えば、ブレードサーバー又はラックマウント型サーバー）、ネットワーク記憶設備又は任意の他の適切な設備であってよく、更に大きさ、形状、性能、機能及び価格が変化してもよい。情報処理システムはランダムアクセスメモリ（ＲＡＭ）、１つ又は複数の処理リソース（例えば、中央処理装置（ＣＰＵ）又はハードウェア又はソフトウェア制御ロジック）、ＲＯＭ及び／又は他のタイプのメモリを含んでもよい。情報処理システムの他のアセンブリは１つ又は複数のディスクドライブ、外部設備と通信するための１つ又は複数のネットワークポート、及び例えばキーボード、マウス、タッチスクリーン及び／又はビデオディスプレーの各種の入力及び出力（Ｉ／Ｏ）設備を含んでもよい。情報処理システムは更に各ハードウェアアセンブリの間で通信できるように操作される可能な１つ又は複数のバスを含んでもよい。

図８は、本出願の実施形態に係る計算設備／情報処理システム（又は計算システム）の簡略化したブロック図を示す。情報処理システムが異なって配置されてもよく、異なるアセンブリを含んでもよいことを理解することができるが、システム８００に示す機能に対して情報処理システムをサポートする各実施形態に操作されてもよいことを理解すべきである。

図８に示すように、システム８００は、計算リソースを提供するとともにコンピュータを制御する１つ又は複数の中央処理装置（ＣＰＵ）８０１を含む。ＣＰＵ ８０１はマイクロプロセッサ等を利用して実現されてもよく、且つ１つ又は複数のグラフ処理ユニット（ＧＰＵ）８１７及び／又は数学計算に用いられる浮動小数点コプロセッサを更に含んでもよい。システム８００はシステムメモリ８０２を更に含んでもよく、システムメモリ８０２はランダムアクセスメモリ（ＲＡＭ）又は読み取り専用メモリ（ＲＯＭ）の様態であってもよく、又はＲＡＭとＲＯＭの様態であってもよい。

図８に示すように、複数のコントローラ及び周辺設備をさらに提供してもよい。入力コントローラ８０３は例えばキーボード、マウス又はライトペンへの各種の入力設備８０４のインターフェースを示す。スキャナー８０６と通信するスキャナーコントローラ８０５を更に有してもよい。システム８００は、１つ又は複数の記憶設備８０８とインタラクションするためのメモリコントローラ８０７を更に含んでもよく、１つ又は複数の記憶設備８０８の中のそれぞれはいずれも例えば磁気テープ又はＣＤの記憶媒体を含み、又は記録操作システム、ユーティリティプログラム及びアプリケーションに用いることができる指令プログラムを含む光学媒体を更に含んでもよく、ここで、アプリケーションは本出願の各様態のプログラムを実現する実施形態を含んでもよい。本出願によれば、記憶設備８０８は更に既に処理されたデータ又は処理しようとするデータを記憶することに用いられてもよい。システム８００は表示設備８１１にインターフェースを提供するためのディスプレーコントローラ８０９を更に含んでもよく、表示設備８１１は陰極線管（ＣＲＴ）、薄膜トランジスタ（ＴＦＴ）ディスプレー又は他のタイプのディスプレーであってよい。計算システム８００は更にプリンタ８１３と通信するためのプリンタコントローラ８１２を含んでもよい。通信コントローラ８１４は１つ又は複数の通信設備８１５にインタラクションすることができ、通信設備８１５によりシステム８００はインターネット、クラウドリソース（例えば、イーサネットクラウド、イーサネット上のファイバチャネル（ＦＣｏＥ）／データセンターブリッジング（ＤＣＢ）クラウド等）、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、記憶領域ネットワーク（ＳＡＮ）の多種のネットワークにおける任意のネットワークを含むか又は赤外線信号の任意の適切な電磁キャリア信号を含むことによりリモート設備に接続される。

示されるシステムにおいて、すべての主なシステムアセンブリはバス８１６に接続されてもよく、バス８１６は１つ以上の物理バスを示すことができる。しかし、各種のシステムアセンブリは互いに物理的に隣接してもよく、又は互いに物理的に隣接する必要がない。例えば、入力データ及び／又は出力データは１つの物理位置から他の物理位置にリモート伝送されることができる。なお、本出願の各様態を実現するプログラムはネットワークでリモート位置（例えば、サーバー）からアクセスすることができる。当該データ及び／又はプログラムは多種の機械読み取り可能な媒体における任意の媒体により伝送されてもよく、機械読み取り可能な媒体は、例えばハードディスク、フロッピーディスク及び磁気テープのような磁気媒体、例えばＣＤ-ＲＯＭ及びホログラフィー設備のような光学媒体、光磁気媒体、及び例えば特定用途向け集積回路（ＡＳＩＣ）、プログラム可能なロジック設備（ＰＬＤ）、フラッシュメモリデバイス及びＲＯＭとＲＡＭ設備のような特別にプログラムコードを記憶又は記憶して実行するように構成されるハードウェア設備を含むが、これらに限定されない。

１つ又は複数のプロセッサ又は処理ユニットに対して、本出願の実施形態は指令を利用して１つ又は複数の非一時的コンピュータ可読媒体でコーディングすることにより、各ステップを実行することができる。１つ又は複数の非一時的コンピュータ可読媒体は揮発性および不揮発性メモリを含むべきであることを注意すべきである。代替の実施例でもよく、ハードウェア実現方式又はソフトウェア／ハードウェア実現方式を含むことを注意すべきである。ハードウェア実現の機能はＡＳＩＣ、プログラマブルアレイ、デジタル信号処理回路等を利用して実現することができる。このため、任意の請求項において、用語「装置」はソフトウェア実現方式をカバーするだけではなく、ハードウェア実現方式もカバーする。類似するように、本文に使用された用語「コンピュータ可読媒体」はその上で実行される指令プログラムを有するソフトウェア及び／又はハードウェア、又はソフトウェア及びハードウェアの組み合せを含む。これらの実現態様の代替態様を考えて、図面及び付いている説明が機能情報を提供し、当業者はプログラムコード（即ち、ソフトウェア）をプログラミングすること及び／又は回路（即ち、ハードウェア）を製造することで必要な処理を実行する必要があることを理解すべきである。

本出願の実施形態は更に非一時的有形のコンピュータ可読媒体を有するコンピュータ製品に関してもよく、当該コンピュータ可読媒体には各種のコンピュータで実現される操作を実行するためのコンピュータコードを有することを注意すべきである。媒体及びコンピュータコードは本出願の目的に基づいて専門に設計して構造する媒体及びコンピュータコードであってもよく、又は関連分野の当業者が公知するか又は取得するできるタイプであってもよい。有形のコンピュータ可読媒体の例示は、例えばハードディスク、フロッピーディスク及び磁気テープのような磁気媒体、例えばＣＤ-ＲＯＭ及びホログラフィー設備のような光学媒体、光磁気媒体、及びプログラムコードを記憶又は記憶して実行するように専門に配置されたハードウェア設備、例えば特定用途向け集積回路（ＡＳＩＣ）、プログラム可能なロジック設備（ＰＬＤ）、フラッシュメモリデバイス及びＲＯＭとＲＡＭ設備を含むが、これらに限定されない。コンピュータコードの例示は、例えばコンパイラで生成されたマシンコード、及びコンピュータがインタプリタを利用して実行する上級コード（higher level code）のファイルを含む。本出願の実施形態は処理設備で実行されるプログラムモジュールに位置してもよいマシン実行可能な指令として全体的又は部分的に実施されることができる。プログラムモジュールの例示は、ベース、プログラム、ルーチン、オブジェクト、アセンブリ及びデータ構造を含む。分散式計算環境において、プログラムモジュールは物理的にローカル、リモート又は両者の環境に設置されてもよい。

当業者は、計算システム又はプログラミング言語が本出願の実施に対して非常に重要なものではないことを理解すべきである。当業者は、多くの上記素子が物理的及び／又は機能的にサブモジュールに分けられるか又は統合されることを認識すべきである。

請求の範囲における素子が異なって配布されてもよく、複数の付属物、構成及び組み合せを有することを含むことを注意すべきである。例えば、実施形態において、各請求項の主旨は他の請求項と組み合せられてもよい。

当業者は、上記の例示及び実施形態が例示的なものであり、本出願の範囲を制限するためのものではないことを理解すべきである。その趣旨は、明細書を読んで図面を研究した後に当業者に対して明らかなすべての置換、増強、等価、組み合せ及びその改善は本出願の実際な精神及び範囲内に含まれる。

Claims (18)

1. 少なくとも部分的に未知のタイミングで、ニューラルネットワークモデルを使用することにより処理しようとする、１つ又は複数の制約で制限されるリクエストに関連するデータを受信するステップと、
   前記１つ又は複数の制約における少なくとも１つを利用して、前記データにおける少なくとも一部をバッチに動的集合するステップと、
   メモリから前記ニューラルネットワークモデルをロードする負荷をシェアリングし、データスループットを向上させるように、複数のスレッドを統合する単一スレッドにより前記バッチを処理するステップと、を含んでおり、
   ここで、バッチビルダーが、
   単一スレッドで実行することで、
   パケットを含む前記データを前処理し、
   前処理されたデータを複数のユーザのうちの少なくとも２つのユーザでシェアされたバッチマトリックスに集合し、
   計算エンジンに前記バッチマトリックスを提供する、ステップと、を更に含んでおり、
   ここで、前記バッチビルダーは、
   各ユーザに用いる入力バッファ、
   各ユーザに用いる前処理バッファ、
   バッチリストと示されるバッチマトリックス、
   という３種のタイプのデータ構造を維持することを特徴とする
   データ処理リクエストのスループットを向上させるバッチ方法。
2. 前記１つ又は複数の制約は遅延要求を含むことを特徴とする
   請求項１に記載の方法。
3. 前記遅延要求は、前記リクエストにおける最後のパケットが到達した後の予定時間量内にリクエストを処理する要求、及び既に前記リクエストからのデータを含むバッチにデータを添加しない要求の中の少なくとも１つを含むことを特徴とする
   請求項２に記載の方法。
4. 所定の遅延に対して処理の実行に影響を受ける２つ又はより多いリクエストからのデータを遅延に対して敏感なバッチに集合するステップと、
   所定の遅延に対して処理の実行に影響を受けない２つ又はより多いリクエストからのデータを処理するためのスループット指向のバッチに集合するステップを更に含んでおり、
   ここで、前記所定の遅延に対して処理の実行に影響を受けるバッチの処理優先度は前記スループット指向のバッチの処理優先度よりも高いことを特徴とする
   請求項２に記載の方法。
5. 前記バッチは少なくとも１つのステートフルリクエストを含むことを特徴とする
   請求項１に記載の方法。
6. 前記パケットからのデータを前記複数のユーザのうちの１つのユーザに関連する入力バッファにコピーするステップと、
   前記パケットを廃棄するステップと、
   前記入力バッファを前処理することにより第１組の結果を取得するステップと、
   前記第１組の結果を前記複数のユーザのうちの前記１つのユーザに関連する前処理バッファに置くステップと、を更に含むことを特徴とする
   請求項１に記載の方法。
7. 前記入力バッファを前処理するステップにおいては、
   前記複数のユーザのうちの前記１つのユーザに関連する前処理バッファからの１つの画像及び一部のスペクトログラムを示す予め決められた量のデータを前記バッチリストにおける適格バッチに伝送するステップであって、前記適格バッチは、現在のユーザのために処理される任意のデータを含まないバッチを示す、ステップ、を含むことを特徴とする
   請求項６に記載の方法。
8. すべての動作中のユーザに関連するデータについて請求項６の各ステップを繰り返すことにより前記バッチリストを充填することに応答して、前記計算エンジンの状態に基づいて前記計算エンジンに１つ又は複数のバッチを提供するかどうかを判定するステップを更に含むことを特徴とする
   請求項６に記載の方法。
9. 前記計算エンジンに１つ又は複数のバッチを提供かどうかを判定するステップは、
   遅延制約を超える追加の繰り返しに必要な時間と、遅延制約に対するバッチリストの状態の効果の中の少なくとも１つに基づいて実行されることを特徴とする
   請求項８に記載の方法。
10. ニューラルネットワークモデルに関連するリクエストを処理するためのバッチ処理システムであって、
    １つ又は複数の計算設備を含んでおり、
    各計算設備が、
    少なくとも１つのプロセッサ及び記憶設備と、
    異なるリクエストに関連するデータを受信し、更に１つ又は複数の制約により少なくとも２つ異なるリクエストからのデータブロックをバッチに動的集合するバッチビルダーアセンブリと、
    メモリから前記ニューラルネットワークモデルをロードする負荷をシェアリングし、データスループットを向上させるように、前記バッチビルダーアセンブリと通信可能に連結されて、複数のスレッドを統合する単一スレッドにおいて前記バッチを処理する計算エンジンアセンブリと、を含んでおり、
    ここで、前記バッチビルダーアセンブリは、
    パケットを含む前記データを前処理し、
    前処理されたデータを複数のユーザのうちの少なくとも２つのユーザでシェアされたバッチマトリックスに集合し、
    計算エンジンに前記バッチマトリックスを提供し、
    ここで、前記バッチビルダーアセンブリは、
    各ユーザに用いる入力バッファ、
    各ユーザに用いる前処理バッファ、
    バッチリストと示されるバッチマトリックス、
    という３種のタイプのデータ構造を維持することを特徴とする
    ニューラルネットワークモデルに関連するリクエストを処理するためのバッチ処理システム。
11. データブロックの大きさがニューラルネットワークモデルの入力の大きさにより確定されることを特徴とする
    請求項１０に記載のバッチ処理システム。
12. ロードバランサを更に含み、前記ロードバランサは未知のタイミングで複数のリクエストを受信し、前記１つ又は複数の計算設備において前記複数のリクエストをロードバランシングすることにより、同一のリクエストに関連するデータが同一の計算設備に送信されることを特徴とする
    請求項１０に記載のバッチ処理システム。
13. 前記計算エンジンは処理されたバッチをそれぞれ１つのユーザに関連する複数の応答に分けることを特徴とする
    請求項１０に記載のバッチ処理システム。
14. １つ又は複数の指令シーケンスを含む非一時的コンピュータ可読媒体を含み、前記１つ又は複数の指令シーケンスが少なくとも１つのプロセッサで実行される場合に、
    少なくとも部分的に未知のタイミングで、ニューラルネットワークモデルを使用することにより処理しようとする、１つ又は複数の制約で制限されるリクエストに関連するデータを受信するステップと、
    前記１つ又は複数の制約における少なくとも１つを利用して、前記データにおける少なくとも一部をバッチに動的集合するステップと、
    メモリから前記ニューラルネットワークモデルをロードする負荷をシェアリングし、データスループットを向上させるように、複数のスレッドを統合する単一スレッドにより前記バッチを処理するステップと、が実行されており、
    ここで、バッチビルダーが、
    単一スレッドで実行することで、
    パケットを含む前記データを前処理し、
    前処理されたデータを複数のユーザのうちの少なくとも２つのユーザでシェアされたバッチマトリックスに集合し、
    計算エンジンに前記バッチマトリックスを提供する、ステップと、を更に実行されており、
    ここで、前記バッチビルダーは、
    各ユーザに用いる入力バッファ、
    各ユーザに用いる前処理バッファ、
    バッチリストと示されるバッチマトリックス、
    という３種のタイプのデータ構造を維持することを特徴とする
    バッチビルダー。
15. 前記バッチビルダーは、複数のユーザのうちの各ユーザに対する入力バッファ及び前処理バッファを含んでおり、各ユーザが処理しようとするリクエストに関連することを特徴とする
    請求項１４に記載のバッチビルダー。
16. 前記バッチビルダーは前記リクエストを非同期的に受信することを特徴とする
    請求項１４に記載のバッチビルダー。
17. 前記１つ又は複数の制約は、前記リクエストにおける最後のパケットが到達した後の予定時間量内にリクエストを処理する要求、及び既に前記リクエストからのデータを含むバッチにデータを添加しない要求の中の少なくとも１つを含むことを特徴とする
    請求項１４に記載のバッチビルダー。
18. 実行するステップは、更に
    遅延に対して敏感な２つ又はより多いリクエストからのデータを遅延に対して敏感なバッチに集合するステップと、
    遅延に対して敏感ではない２つ又はより多いリクエストからのデータを処理るためのスループット指向のバッチに集合するステップを更に含んでおり、
    ここで、前記遅延に対して敏感なバッチの処理優先度は前記スループット指向のバッチの処理優先度よりも高いことを特徴とする
    請求項１４に記載のバッチビルダー。

Images