JP2022187116A - 多重制御プログラム、情報処理装置および多重制御方法 - Google Patents

Abstract

【課題】１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制する。
【解決手段】推論処理にＧＰＵを用いるサーバ１は、推論処理を実行するＡＩフレームワーク１３から出力されるメッセージを監視する。サーバ１は、監視によって取得されるメッセージのパターンから、推論処理の中核を担うコア処理であってＧＰＵを用いるコア処理の開始および終了のタイミングを判定する。サーバ１は、コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければ、コア処理を開始し、他のコア処理を実行しているプロセスがあれば、コア処理のプロセスを識別するプロセス識別子をコア開始通知キュー２１８に蓄積する。
【選択図】図３

Description

本発明は、多重制御プログラムなどに関する。

近年、ＧＰＵ（Graphical Processing Unit）を使ってＡＩ（Artificial Intelligence）処理を実行するシステムが増加している。例えば、映像のＡＩ処理により物体検知等を行うシステムがある。

このようなシステムでは、１台のＧＰＵが１台のカメラから転送される映像を処理していたが、映像は一定周期で送られるため、処理の隙間でＧＰＵが空く時間が生じる。そこで、１台のＧＰＵが複数台のカメラから転送される映像を収容して処理することで、相互に隙間を埋めて効率よく利用することが期待される。

特開平１０－３０１７９３号公報 特開２０１９－１２１１８５号公報

しかしながら、１台のＧＰＵが複数の処理を多重で実行すると、処理同士の干渉により処理時間が増加する場合がある。

ここで、処理同士の干渉により処理時間が増加する場合について、図１３を参照して説明する。図１３は、処理同士の干渉による処理時間の増加を説明する図である。図１３に示すように、１台のＧＰＵは、複数のタスクを多重で処理することが可能である。ここでは、タスクの処理は、映像の推論処理であり、４個の処理が並列で実行されている。

ＧＰＵは、単体で映像の推論処理を実行する場合には、予め定められた一定周期で推論処理を実行する。ところが、ＧＰＵが、４並列で映像の推論処理を実行する場合には、推論処理同士が干渉してしまい、処理時間が増加する場合がある。処理時間の増加の程度は、推論処理の内容や重なり方によって異なる。例えば、推論処理間の重なりが大きく、推論処理の重なる数が多い方が、処理時間の増加の程度は大きくなる。推論処理の開始タイミングは別々であるため、偶々開始が近い推論処理が多いと、推論処理の重なる数が多くなり、処理時間の増加の程度が大きくなり、推論処理の処理時間が一定周期を超過してしまう。すなわち、処理同士の干渉により処理時間が増加してしまう。

本発明は、１つの側面では、１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制することを目的とする。

１つの態様では、情報処理装置は、推論処理にＧＰＵ（Graphical Processing Unit）を用いる情報処理装置であって、前記推論処理を実行するアプリケーションから出力されるメッセージを監視する監視部と、前記監視部による監視によって取得されるメッセージのパターンから、前記推論処理の中核を担うコア処理であって前記ＧＰＵを用いるコア処理の開始および終了のタイミングを判定する判定部と、前記コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければ、前記コア処理を開始し、前記他のコア処理を実行しているプロセスがあれば、前記コア処理のプロセスを識別するプロセス識別子をキューに蓄積する制御部と、を有する。

１実施態様によれば、１台のＧＰＵが複数の処理を多重で実行しても、処理の重複実行による処理時間の増加を抑制することが可能となる。

図１は、多重制御を実行するサーバの参考例を示す図である。 図２は、実施例に係る多重制御を実行するサーバの一例を示す図である。 図３は、実施例に係るサーバの機能構成の一例を示す図である。 図４は、パス－モデル対応表の一例を示す図である。 図５は、推論回数ＤＢの一例を示す図である。 図６は、コア開始通知キューの一例を示す図である。 図７は、遷移パターンＤＢの一例を示す図である。 図８Ａは、ＧＰＵでの実行完了の監視を説明する図（１）である。 図８Ｂは、ＧＰＵでの実行完了の監視を説明する図（２）である。 図９は、実施例に係る状態管理部のフローチャートの一例を示す図である。 図１０は、サーバのハードウェア構成の一例を示す図である。 図１１は、実施例に係るサーバの各モジュール単位のシーケンスの一例を示す図である。 図１２Ａは、複数プロセスの推論のシーケンスの一例を示す図（１）である。 図１２Ｂは、複数プロセスの推論のシーケンスの一例を示す図（２）である。 図１３は、処理同士の干渉による処理時間の増加を説明する図である。

以下に、本願の開示する多重制御プログラム、情報処理装置および多重制御方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。

［多重制御を実行するサーバ］
まず、１台のＧＰＵが複数の推論処理を多重で実行する場合における多重制御を実行するサーバの参考例を、図１を参照して説明する。図１は、多重制御を実行するサーバの参考例を示す図である。サーバ８は、例えば動画像（映像）に関し、推論処理するプロセス８０をＧＰＵ（Graphics Processing Unit）８７を用いて実行する。サーバ８は、１台のＧＰＵ８７上で複数のプロセス８０を実行することを想定する。ここでいう推論処理するプロセス８０とは、例えば、映像から不審者を推定したり、交通量を推定したりするアプリケーションのことをいう。プロセス８０は、ＣＵＤＡ（Compute Unified Device Architecture）８５の所定のライブラリを組み込み、推論モデルを用いて推論処理を実行する。

推論処理は、３つのフェーズを含む。３つのフェーズは、前処理、畳込み処理および後処理であり、各処理の特性は異なる。前処理は、例えば、データソース等の処理データを用意するＣＰＵ処理と、ＣＰＵからＧＰＵ８７へデータを転送するデータ転送処理とを含む。畳込み処理は、例えば、ディープラーニングの中核部分である、ＧＰＵ８７を利用したデータ処理であり、畳込みニューラルネットワーク（Convolutional neural network）を用いて実行される。後処理は、例えば、ＧＰＵ８７からＣＰＵへ処理結果を転送するデータ転送処理と処理結果を取り出して加工するＣＰＵ処理とを含む。なお、畳込み処理のことを、以降、コア処理またはＧＰＵ処理というものとする。

サーバ８は、複数の推論処理を同時に行う際に、コア処理が重複して実行されないように実行タイミングを制御する。例えば、サーバ８は、直前に実行された推論処理の開始時刻から閾値以上遅らせて後続の他のアプリケーションの推論処理を開始させる。

ここでいう推論処理するプロセス（推論プロセス）８０は、アプリケーション８１、Ｗｒａｐｐｅｒ部８２、ＡＩフレームワーク８３およびＣＵＤＡ（Compute Unified Device Architecture）８５を含む。サーバ８は、アプリケーション８１とＡＩフレームワーク８３との間のＷｒａｐｐｅｒ部８２と別のプロセス９０で実行するスケジューラ部９１とのインターフェースを利用して、ＧＰＵ８７を利用したコア処理の実行タイミングを制御する。

ＡＩフレームワーク８３は、推論を実行するためのライブラリであり、ＣＵＤＡ８５のライブラリを使うためのＧＰＵ処理（コア処理）を呼び出す。ＣＵＤＡ８５は、ＧＰＵ８７を使うためのライブラリである。ＧＰＵドライバ８６は、ＧＰＵ８７を動かすためのソフトウェアである。

アプリケーション８１は、推論モデルのモデルロードの開始をＷｒａｐｐｅｒ部８２に要求したり、各フレームの推論をＷｒａｐｐｅｒ部８２に要求したりする。

Ｗｒａｐｐｅｒ部８２は、アプリケーション８１からの推論要求を受け付けると、スケジューラ部９１からの指示に基づいて、推論処理を実行すべく、ＡＩフレームワーク８３に推論処理を実行させる。

スケジューラ部９１は、複数の推論プロセス８０を多重で実行させる場合には、所定の閾値だけ後続の推論プロセスの開始タイミングを遅延させるべく、後続の推論プロセス８０のＷｒａｐｐｅｒ部８２に推論開始を指示する。所定の閾値は、一例では、推論プロセス８０で使用される推論モデルが同じである場合には、畳込み処理（コア処理）のフェーズの処理時間の値を示す。推論モデルが同じであれば、畳込み処理の処理時間は略同じとなるからである。別の例では、所定の閾値は、推論プロセス８０で使用される推論モデルが異なる場合には、前処理と畳込み処理（コア処理）とを加算した処理時間の値を示す。

所定の閾値は、事前に、計測されたり、ベンチマークなどで調査されたりして、プロファイル情報９２に記憶される。そして、スケジューラ部９１が、２つの推論プロセス８０が近いタイミングで実行される場合には、プロファイル情報９２を参照して推論モデルに対応する所定の閾値を取得する。そして、スケジューラ部９１は、先行の推論プロセス８０の開始タイミングから所定の閾値だけ後続の推論プロセス８０の開始タイミングを遅延させて開始指示することで、干渉による処理時間の増加を抑制することができる。

ところが、参考例で説明したサーバ８は、コア処理の干渉による処理時間の増加を抑制することができるが、所定の閾値を求めるための事前調査にかかるコストが大きいという問題がある。そこで、以降で説明する実施例では、事前調査にかかるコストを不要とし、コア処理の干渉による処理時間の増加を抑制する場合を説明する。

図２は、実施例に係る多重制御を実行するサーバの一例を示す図である。実施例に係るサーバ１は、コア処理を呼び出すメッセージ（命令）を監視し、メッセージパターンから推論処理のコア処理の開始、終了のタイミングを判別する。そして、サーバ１は、コア処理を実行しているプロセスがなければ推論処理を開始し、実行中のプロセスがあれば開始通知を待機させる。

ここでいう推論処理するプロセス（推論プロセス）１０は、アプリケーション１１、第１のＷｒａｐｐｅｒ部１２、ＡＩフレームワーク１３、第２のＷｒａｐｐｅｒ部１４およびＣＵＤＡ１５ａを含む。サーバ１は、ＡＩフレームワーク１３とＣＵＤＡ１５ａとの間の第２のＷｒａｐｐｅｒ部１４を利用して、コア処理を呼び出すメッセージ（命令）を監視し、メッセージパターンから推論処理のコア処理の開始、終了のタイミングを判別する。

ＡＩフレームワーク１３は、推論を実行するためのライブラリであり、第２のＷｒａｐｐｅｒ部１４に対して、ＣＵＤＡ１５ａのライブラリを使うためのＧＰＵ処理（コア処理）を呼び出す。ＣＵＤＡ１５ａは、ＧＰＵ１７を使うためのライブラリである。ＧＰＵドライバ１６は、ＧＰＵ１７を動かすためのソフトウェアである。

アプリケーション１１は、推論モデルのモデルロードの開始を第１のＷｒａｐｐｅｒ部１２に要求したり、各フレームの推論を第１のＷｒａｐｐｅｒ部１２に要求したりする。

第１のＷｒａｐｐｅｒ部１２は、アプリケーション１１からのモデルロードの開始要求に応じて、別のプロセス２０で実行するスケジューラ部２１にモデルロードの開始を通知するとともに、推論モデルを生成する。また、第１のＷｒａｐｐｅｒ部１２は、アプリケーション１１からの推論要求に応じて、推論開始通知とモデル名をスケジューラ部２１に通知する。そして、第１のＷｒａｐｐｅｒ部１２は、スケジューラ部２１からの推論開始指示に基づいて、推論処理を開始する。

第２のＷｒａｐｐｅｒ部１４は、ＡＩフレームワーク１３からのＧＰＵ処理の呼び出しメッセージ（命令）をフックし、遷移パターンを用いて呼び出しメッセージのパターンから推論の状態を管理する。推論の状態には、前処理の状態、コア処理の状態、後処理の状態が挙げられる。第２のＷｒａｐｐｅｒ部１４は、推論の状態が前処理のときにコア処理の開始の遷移パターンを判定し、推論の状態がコア処理のときにコア処理の終了の遷移パターンを判定し、推論の状態が後処理のときにはいずれも判定しない。第２のＷｒａｐｐｅｒ部１４は、コア処理の開始を検知したとき、スケジューラ部２１にコア処理の開始を通知し、スケジューラ部２１からのコア処理の開始の指示を待機する。そして、第２のＷｒａｐｐｅｒ部１４は、スケジューラ部２１からコア処理の開始指示を受信したとき、コア処理のＧＰＵ利用を開始する。また、第２のＷｒａｐｐｅｒ部１４は、コア処理の終了を検知したとき、スケジューラ部２１にコア処理の終了を通知し、後続の後処理を続行する。

スケジューラ部２１は、第１のＷｒａｐｐｅｒ部１２から初回の推論開始通知を受信すると、第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する。スケジューラ部２１は、第１のＷｒａｐｐｅｒ部１２から二回目以降の推論開始通知を受信すると、第２のＷｒａｐｐｅｒ部１４に状態管理を初期化させ、第２のＷｒａｐｐｅｒ部１４から状態管理初期化通知を受信すると、第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する。

また、スケジューラ部２１は、第２のＷｒａｐｐｅｒ部１４からコア処理の開始通知を受信すると、他にコア処理を実行している推論プロセス１０がなければ、第２のＷｒａｐｐｅｒ部１４にコア処理の開始を指示する。スケジューラ部２１は、他にコア処理を実行している推論プロセス１０があれば、当該推論プロセス１０のプロセスＩＤを蓄積する。そして、スケジューラ部２１は、第２のＷｒａｐｐｅｒ部１４からコア処理の終了通知を受信すると、プロセスＩＤが蓄積されていれば、蓄積されたプロセスＩＤのうち一つのプロセスＩＤが示す推論プロセス１０の第２のＷｒａｐｐｅｒ部１４にコア処理の開始を指示する。

［サーバの機能構成の一例］
このような多重制御を実行するサーバ１の機能構成の一例を、図３を参照して説明する。図３は、実施例に係るサーバの機能構成の一例を示す図である。図３に示すように、サーバ１は、推論処理を行うプロセス１０と、プロセス１０と異なるプロセス２０とを有する。推論処理を行うプロセス１０は、複数存在する。また、サーバ１は、ＧＰＵドライバ１６と、ＧＰＵ１７とを有する。

プロセス１０は、アプリケーション１１、第１のＷｒａｐｐｅｒ部１２、ＡＩフレームワーク１３、第２のＷｒａｐｐｅｒ部１４およびＣＵＤＡライブラリ１５を有する。プロセス２０は、スケジューラ部２１を有する。なお、ＣＵＤＡライブラリ１５は、図２で示したＣＵＤＡ１５ａと同義である。

第１のＷｒａｐｐｅｒ部１２は、モデルロードフック部１２１、モデル識別部１２２、フック用モデル生成部１２３、プロセス間通信部１２４、パス－モデル対応表１２５およびフック用モデル１２６を有する。

モデルロードフック部１２１は、アプリケーション１１からのモデルロード命令をフックし、モデル識別部１２２にモデルロード命令およびロード対象のモデルのパスを返す。

モデル識別部１２２は、後述するパス－モデル対応表１２５とロード対象のモデルのパスから、ロード対象のモデル名を取得する。そして、モデル識別部１２２は、スケジューラ部２１に対して、モデルロード開始通知、自身のプロセス１０のプロセスＩＤ、取得したモデル名を送信する。そして、モデル識別部１２２は、フック用モデル生成部１２３にロード対象のモデルのパスを渡す。

パス－モデル対応表１２５は、モデルオブジェクトが配置されているパスと、モデル名を対応付けたリスト（ＤＢ：DataBase）であり、例えば管理者によって登録される。ここで、パス－モデル対応表１２５の一例を、図４を参照して説明する。図４は、パス－モデル対応表の一例を示す図である。図４に示すように、パス－モデル対応表１２５は、パスと、モデル名とを対応付けた表である。図４の例では、パス－モデル対応表１２５は、ｃｓｖ形式であるが、これに限定されるものではない。パスは、モデルが存在するパスを示す。モデル名は、モデルの名称である。一例として、“ｙｏｌｏ”というモデル名のモデルは、“／ｈｏｍｅ／ｕｓｒ／ｍｏｄｅｌｓ／ｓａｖｅｄ＿ｍｏｄｅｌ／Ｙｏｌｏ”のパス配下に記憶されている。

図３に戻って、フック用モデル生成部１２３は、ＡＩフレームワーク１３のモデルロードＡＰＩ（APplication Interface）を利用し、ロード対象のモデルのモデルオブジェクトをロードする。そして、フック用モデル生成部１２３は、モデルオブジェクトにフック用モデルＡＰＩ（１１１）とモデル名の情報を追加して、フック用モデル１２６を生成する。そして、フック用モデル生成部１２３は、フック用モデルＡＰＩ（１１１）を、モデル識別部１２２およびモデルロードフック部１２１を経由してアプリケーション１１に返す。

フック用モデル１２６は、アプリケーション１１からフック用モデルＡＰＩ（１１１）を用いて推論が実行されたとき、推論開始命令をフックする。そして、フック用モデル１２６は、推論開始通知、プロセスＩＤおよびモデル名をスケジューラ部２１に送信して、スケジューラ部２１からの指示を待機する。フック用モデル１２６は、スケジューラ部２１からの推論開始指示を受信したとき、モデルオブジェクトを用いて推論を実行する。そして、フック用モデル１２６は、実行結果をアプリケーション１１に返す。

プロセス間通信部１２４は、自身のプロセス１０における第１のＷｒａｐｐｅｒ部１２とプロセス２０におけるスケジューラ部２１とのプロセス間の通信を行う。

ＡＩフレームワーク１３は、モデルロード部１３１、推論実行部１３２およびモデルオブジェクト１３３を有する。

モデルロード部１３１は、第１のＷｒａｐｐｅｒ部１２の要求に応じて、ロード対象のモデルのモデルオブジェクト１３３を取得する。推論実行部１３２は、第１のＷｒａｐｐｅｒ部１２の要求に応じて、推論を実行する。例えば、推論実行部１３２は、推論を実行するために、ＣＵＤＡライブラリ１５に対するＡＰＩを示すＣＵＤＡ ＡＰＩを第２のＷｒａｐｐｅｒ部１４に送信する。

第２のＷｒａｐｐｅｒ部１４は、ＣＵＤＡＡＰＩフック部１４１、状態管理部１４２、ＡＰＩ呼び出し制御部１４３、プロセス間通信部１４４および遷移パターンＤＢ１４５を有する。なお、ＣＵＤＡＡＰＩフック部１４１は、監視部の一例である。状態管理部１４２は、判定部の一例である。

ＣＵＤＡＡＰＩフック部１４１は、ＣＵＤＡ ＡＰＩをフックする。例えば、ＣＵＤＡＡＰＩフック部１４１は、ＡＩフレームワーク１３からのＣＵＤＡ ＡＰＩをフックすると、状態管理部１４２にＣＵＤＡ ＡＰＩおよび引数を渡す。

状態管理部１４２は、推論状態を管理する。

例えば、状態管理部１４２は、スケジューラ部２１からモデル名を含む状態管理初期化指示を受信したとき、後述する遷移パターンＤＢ１４５からモデル名に対応する遷移パターンをロードし、状態管理用の内部変数を初期化する。そして、状態管理部１４２は、状態管理初期化完了通知をスケジューラ部２１に送信する。ここでいう遷移パターンＤＢ１４５は、遷移パターンを保持するＤＢであり、例えば管理者によって登録される。遷移パターンには、モデル名、コア開始パターン、コア終了パターンの情報が含まれる。なお、遷移パターンＤＢ１４５の説明は、後述する。

また、状態管理部１４２は、ロードした遷移パターンに基づき、ＣＵＤＡ ＡＰＩがフックされた際に渡されるＣＵＤＡ ＡＰＩおよび引数から状態等の内部変数を更新する。ここでいう状態は、現在の状態のことをいい、前処理の状態、コア処理の状態、後処理の状態が含まれる。一例として、遷移パターンに示される遷移条件にＣＵＤＡ ＡＰＩを実行した時の返り値が含まれる場合には、状態管理部１４２は、ＣＵＤＡライブラリ１５にＣＵＤＡ ＡＰＩ実行命令を送信して、実行命令に対する返り値に基づいて状態等の内部変数を更新する。例えば、状態管理部１４２は、実行命令に対する返り値を受信すると、状態を、前処理からコア処理に更新する。

また、状態管理部１４２は、ロードした遷移パターンに基づき、コア開始パターンを検知した場合には、スケジューラ部２１にコア開始通知および自身のプロセス１０のプロセスＩＤを送信する。この後、状態管理部１４２は、内部変数の更新時に、ＣＵＤＡ ＡＰＩが実行されていない場合には、ＡＰＩ呼び出し制御部１４３にＣＵＤＡ ＡＰＩおよび引数を渡す。状態管理部１４２は、内部変数の更新時に、既にＣＵＤＡ ＡＰＩが実行されている場合には、ＡＰＩ呼び出し制御部１４３にＣＵＤＡ ＡＰＩの実行に対応する返り値を渡す。

また、状態管理部１４２は、ロードした遷移パターンに基づき、コア終了パターンを検知した場合には、スケジューラ部２１にコア終了通知および自身のプロセス１０のプロセスＩＤを送信する。この後、状態管理部１４２は、内部変数の更新時に、ＣＵＤＡ ＡＰＩが実行されていない場合には、ＣＵＤＡ ＡＰＩを実行し、実行に対応する返り値を、ＣＵＤＡＡＰＩフック部１４１を経由してＡＩフレームワーク１３に返す。状態管理部１４２は、内部変数の更新時に、既にＣＵＤＡ ＡＰＩが実行されている場合には、実行に対応する返り値を、ＣＵＤＡＡＰＩフック部１４１を経由してＡＩフレームワーク１３に返す。

また、状態管理部１４２は、コア開始、コア終了のいずれも検知しない場合には、以下の処理を行う。状態管理部１４２は、内部変数の更新時に、ＣＵＤＡ ＡＰＩが実行されていない場合には、ＣＵＤＡ ＡＰＩを実行し、実行に対応する返り値を、ＣＵＤＡＡＰＩフック部１４１を経由してＡＩフレームワーク１３に返す。状態管理部１４２は、内部変数の更新時に、既にＣＵＤＡ ＡＰＩが実行されている場合には、実行に対応する返り値を、ＣＵＤＡＡＰＩフック部１４１を経由してＡＩフレームワーク１３に返す。

ＡＰＩ呼び出し制御部１４３は、ＣＵＤＡ ＡＰＩの呼び出しを制御する。例えば、ＡＰＩ呼び出し制御部１４３は、状態管理部１４２からＣＵＤＡ ＡＰＩおよび引数、または、返り値を受信すると、スケジューラ部２１からのコア開始指示を待機する。ＡＰＩ呼び出し制御部１４３は、スケジューラ部２１からコア開始指示を受信したとき、ＣＵＤＡ ＡＰＩおよび引数を受信している場合には、当該ＣＵＤＡ ＡＰＩを実行する。そして、ＡＰＩ呼び出し制御部１４３は、実行に対応する返り値を、状態管理部１４２に返す。また、ＡＰＩ呼び出し制御部１４３は、スケジューラ部２１からコア開始指示を受信したとき、返り値を受信している場合には、状態管理部１４２に当該返り値を返す。

プロセス間通信部１４４は、自身のプロセス１０における第２のＷｒａｐｐｅｒ部１４とプロセス２０におけるスケジューラ部２１とのプロセス間の通信を行う。

スケジューラ部２１は、推論回数カウント部２１１、処理判定部２１２、推論開始制御部２１３、状態管理初期化指示部２１４、コア実行スケジュール部２１５およびプロセス間通信部２１６を有する。また、スケジューラ部２１は、推論回数ＤＢ２１７およびコア開始通知キュー２１８を有する。なお、コア実行スケジュール部２１５は、制御部の一例である。コア開始通知キュー２１８は、記憶部の一例である。

推論回数カウント部２１１は、推論回数をカウントする。例えば、推論回数カウント部２１１は、第１のＷｒａｐｐｅｒ部１２からモデルロード開始通知、プロセスＩＤおよびモデル名を受信すると、プロセスＩＤおよびモデル名の組み合わせに対し、推論回数を０回として、後述する推論回数ＤＢ２１７に登録する。また、推論回数カウント部２１１は、第１のＷｒａｐｐｅｒ部１２から推論開始通知、プロセスＩＤおよびモデル名を受信すると、推論回数ＤＢ２１７からプロセスＩＤおよびモデル名の組み合わせに対応する推論回数を取得し、取得した推論回数に１加えて、推論回数ＤＢ２１７を更新する。そして、推論回数カウント部２１１は、プロセスＩＤ，モデル名、登録または更新した推論回数を処理判定部２１２に渡す。ここでいう推論回数ＤＢ２１７は、プロセスＩＤおよびモデル名の組み合わせごとに推論回数を保持するＤＢである。

ここで、推論回数ＤＢ２１７の一例を、図５を参照して説明する。図５は、推論回数ＤＢの一例を示す図である。図５に示すように、推論回数ＤＢ２１７は、プロセスＩＤ，モデル名および回数を対応付けて記憶する。図５の例では、推論回数ＤＢ２１７は、ｃｓｖ形式であるが、これに限定されるものではない。プロセスＩＤは、プロセス１０を識別するＩＤである。モデル名は、モデルの名称である。回数は、推論回数を示す。一例として、プロセスＩＤが“ｐｉｄ１”であり、モデル名が“ｙｏｌｏ”である場合に、推論回数として「３」と記憶している。

図３に戻って、処理判定部２１２は、推論回数カウント部２１１からプロセスＩＤ、モデル名、推論回数を受信すると、以下の処理を行う。処理判定部２１２は、推論回数が「１」である場合には、推論開始指示を送信させるべく、推論開始制御部２１３にプロセスＩＤを送信する。また、処理判定部２１２は、推論回数が２以上である場合には、状態管理初期化指示を送信させるべく、状態管理初期化指示部２１４にプロセスＩＤおよびモデル名を送信する。そして、処理判定部２１２は、状態管理初期化指示部２１４から状態管理初期化完了通知を受信すると、推論開始指示を送信させるべく、推論開始制御部２１３にプロセスＩＤを送信する。

状態管理初期化指示部２１４は、処理判定部２１２からプロセスＩＤおよびモデル名を受信すると、プロセスＩＤが示すプロセス１０の第２のＷｒａｐｐｅｒ部１４にモデル名を含む状態管理初期化指示を送信する。そして、状態管理初期化指示部２１４は、第２のＷｒａｐｐｅｒ部１４からの応答を待機する。そして、状態管理初期化指示部２１４は、第２のＷｒａｐｐｅｒ部１４から状態管理初期化完了通知を受信すると、状態管理初期化完了通知を処理判定部２１２に返す。

推論開始制御部２１３は、処理判定部２１２からプロセスＩＤを受信すると、プロセスＩＤが示すプロセス１０の第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する。

コア実行スケジュール部２１５は、コア処理の実行をスケジュールする。例えば、コア実行スケジュール部２１５は、第２のＷｒａｐｐｅｒ部１４からコア開始通知およびプロセスＩＤを受信すると、以下の処理を行う。コア実行スケジュール部２１５は、後述するコア開始通知キュー２１８が空である場合には、コア処理を実行しているプロセス１０がないので、プロセスＩＤが示すプロセス１０の第２のＷｒａｐｐｅｒ部１４にコア開始通知を送信する。そして、コア実行スケジュール部２１５は、コア開始通知キュー２１８にプロセスＩＤを追加する。コア実行スケジュール部２１５は、コア開始通知キュー２１８が空でない場合には、コア処理を実行中のプロセス１０があるので、コア開始通知キュー２１８にプロセスＩＤを追加する。コア実行スケジュール部２１５は、第２のＷｒａｐｐｅｒ部１４からコア終了通知およびプロセスＩＤを受信すると、コア開始通知キュー２１８から当該プロセスＩＤを削除する。そして、コア実行スケジュール部２１５は、コア開始通知キュー２１８からいずれかのプロセスＩＤを選択し、選択したプロセスＩＤが示すプロセス１０の第２のＷｒａｐｐｅｒ部１４にコア開始指示を送信する。

ここでいうコア開始通知キュー２１８は、コア開始を検知したプロセス１０のプロセスＩＤを蓄積するキューである。コア開始通知キュー２１８に蓄積されたプロセスＩＤの一つが現にコア処理を実行中のプロセス１０のプロセスＩＤであり、それ以外に蓄積されたプロセスＩＤがコア処理の実行を待機しているプロセス１０のプロセスＩＤである。ここで、コア開始通知キュー２１８の一例を、図６を参照して説明する。図６は、コア開始通知キューの一例を示す図である。図６に示すように、コア開始通知キュー２１８には、コア処理を実行中または実行を待機しているプロセスのプロセスＩＤが蓄積される。一例として、プロセスＩＤとして“ｐｉｄ１”、“ｐｉｄ２”、“ｐｉｄ４”および“ｐｉｄ３”が蓄積されている。

プロセス間通信部２１６は、自身のプロセス２０におけるスケジューラ部２１とプロセス１０とのプロセス間の通信を行う。

ここで、遷移パターンＤＢ１４５の一例を、図７を参照して説明する。図７は、遷移パターンＤＢの一例を示す図である。図７に示すように、遷移パターンＤＢ１４５は、モデル名、コア開始パターンおよびコア終了パターンを対応付けて記憶する。図７の例では、遷移パターンＤＢ１４５は、ｊｓｏｎ形式であるが、これに限定されるものではない。

符号ａ１、ｂ１で示される“ｍｏｄｅｌｓ”フィールドが、遷移パターンが対応するモデル名のリストである。符号ａ２、ｂ２が示される“ｃｏｒｅ＿ｓｔａｒｔ”フィールドが、コア開始と判定するＣＵＤＡ ＡＰＩのコア開始パターンである。符号ａ３、ｂ３が示される“ｃｏｒｅ＿ｅｎｄ”フィールドが、コア終了と判定するＣＵＤＡ ＡＰＩのコア終了パターンである。

また、“ｉｆ”フィールドは、コア開始またはコア終了と判定される判定条件である。「“ｉｆ”：［［Ａ，Ｂ］，［Ｃ］，［Ｄ］］」である場合には、「（Ａ ａｎｄ Ｂ） ｏｒＣ ｏｒＤ」であることを示す。また、「“○○＿ｈｏｏｋ”」は、フックするＣＵＤＡ ＡＰＩが〇○であることが条件であることを示す。また、「“ｓｔｒｅａｍ＝ｍａｉｎ＿ｓｔｒｅａｍ”」は、フックするＣＵＤＡ ＡＰＩの引数のストリームがメインストレームと一致することが条件であることを示す。また、「“ｒｅｔｕｒｎ＝０”」は、ＣＵＤＡ ＡＰＩを実行した返り値が「０」であることが条件であることを示す。また、“ｓｙｎｃｈｒｏｎｉｚｅｄ”は、フックしたＣＵＤＡ ＡＰＩのＧＰＵ１７での実行が完了することが条件であることを示す。このように、遷移パターンＤＢ１４５では、コア開始またはコア終了と判定される判定条件として、特定のＣＵＤＡ＿ＡＰＩをフックしたとき、特定のＣＵＤＡ＿ＡＰＩを実行して返り値を取得したとき、特定のＣＵＤＡ＿ＡＰＩのＧＰＵ１７での実行が完了したときの３パターンを定義することができる。

また、“ａｃｔｉｏｎ”フィールドは、ａｃｔｉｏｎを起こすために用いられるフィールドである。例えば、「“ｍａｉｎ＿ｓｔｒｅａｍ＝ｓｔｒｅａｍ”」は、内部変数に含まれるメインストリーム変数に、フックしたＣＵＤＡ＿ＡＰＩの引数のストリームの番号をセットすることを意味する。

一例として、“ｍｏｄｅｌｓ”フィールドが“ｒｅｓｎｅｔ”または“ｙｏｌｏ”である場合に、“ｃｏｒｅ＿ｓｔａｒｔ”フィールドとして“ｉｆ”フィールドが“ｃｕＬａｕｎｃｈＫｅｒｎｅｌ＿ｈｏｏｋ”と記載されている。“ｃｕＬａｕｎｃｈＫｅｒｎｅｌ＿ｈｏｏｋ”は、フックするＣＵＤＡ ＡＰＩがｃｕＬａｕｎｃｈＫｅｒｎｅｌであることが条件であることを示す。加えて、“ａｃｔｉｏｎ”フィールドが“ｍａｉｎ＿ｓｔｒｅａｍ＝ｓｔｒｅａｍ”と記載されている。また、“ｃｏｒｅ＿ｅｎｄ”フィールドとして“ｉｆ”フィールドが［“ｃｕＭｅｍｃｐｙＤｔｏＨＡｓｙｎｃ＿ｈｏｏｋ”，“ｓｔｒｅａｍ＝ｍａｉｎ＿ｓｔｒｅａｍ”，“ｓｙｎｃｈｒｏｎｉｚｅｄ”］と記載されている。

別の例として、“ｍｏｄｅｌｓ”フィールドが“ｃｐｎ”である場合に、“ｃｏｒｅ＿ｓｔａｒｔ”フィールドとして“ｉｆ”フィールドが“ｃｕＬａｕｎｃｈＫｅｒｎｅｌ＿ｈｏｏｋ”と記載されている。“ｃｕＬａｕｎｃｈＫｅｒｎｅｌ＿ｈｏｏｋ”は、フックするＣＵＤＡ ＡＰＩがｃｕＬａｕｎｃｈＫｅｒｎｅｌであることが条件であることを示す。また、“ｃｏｒｅ＿ｅｎｄ”フィールドとして“ｉｆ”フィールドが［“ｃｕＣｔｘＳｙｎｃｈｒｏｎｉｚｅ＿ｈｏｏｋ”，“ｒｅｔｕｒｎ＝０”］と記載されている。「“ｒｅｔｕｒｎ＝０”」が記載されているので、ＣＵＤＡ ＡＰＩを実行した返り値が「０」であることが条件であることを示す。

ここで、遷移パターンに基づく状態管理部１４２の処理の一例を説明する。例えば、状態管理部１４２は、スケジューラ部２１からモデル名を含む状態管理初期化指示を受信したとき、遷移パターンＤＢ１４５からモデル名に対応する遷移パターンをロードする。遷移パターンＤＢ１４５に記憶された“ｍｏｄｅｌｓ”フィールドの中のモデル名と受信モデル名とが一致する遷移パターンがロードされる。そして、状態管理部１４２は、状態管理用の内部変数を初期化する。内部変数には、状態、メインストリーム変数、監視対象ストリーム変数、監視対象イベント変数が含まれる。状態には、前処理、コア処理、後処理の三状態が含まれ、初期化時には前処理がセットされる。そして、状態管理部１４２は、状態管理初期化完了通知をスケジューラ部２１に送信する。

そして、状態管理部１４２は、ロードした遷移パターンに基づき状態管理を開始する。現在の状態が前処理である場合には、状態管理部１４２は、ＣＵＤＡＡＰＩフック部１４１からＣＵＤＡ ＡＰＩと引数が渡されるたびに、コア開始パターンを識別する。具体的には、状態管理部１４２は、遷移パターンの“ｃｏｒｅ＿ｓｔａｒｔ”フィールドの条件を判定する。一例として、“ｉｆ”フィールドに“ｓｙｎｃｈｒｏｎｉｚｅｄ”が含まれる場合には、“ｉｆ”フィールド内のそれ以外の条件を満たすＣＵＤＡ ＡＰＩがフックされた時に、状態管理部１４２は、当該ＣＵＤＡ ＡＰＩのＧＰＵ１７での実行完了までを監視する。状態管理部１４２は、ＧＰＵ１７での実行完了を検知したとき、条件を満たしたと判定する。なお、ＧＰＵ１７での実行完了の監視については、後述する。また、条件に“ａｃｔｉｏｎ”フィールドが含まれる場合には、“ｉｆ”フィールドの条件を満たした時に、状態管理部１４２は、内部変数を更新する。

そして、状態管理部１４２は、コア開始パターンを検知したとき、現在の状態を前処理からコア処理に更新する。そして、状態管理部１４２は、ＡＰＩ呼び出し制御部１４３にＣＵＤＡ ＡＰＩと引数を送信する。この後、状態管理部１４２は、スケジューラ部２１にコア開始を通知する。そして、状態管理部１４２は、ＡＰＩ呼び出し制御部１４３から返り値を受信したとき、ＣＵＤＡＡＰＩフック部１４１に返り値を返す。

現在の状態がコア処理である場合には、状態管理部１４２は、ＣＵＤＡＡＰＩフック部１４１からＣＵＤＡ ＡＰＩと引数が渡されるたびに、コア終了パターンを識別する。具体的には、状態管理部１４２は、遷移パターンの“ｃｏｒｅ＿ｅｎｄ”フィールドの条件を判定する。一例として、“ｉｆ”フィールドに“ｓｙｎｃｈｒｏｎｉｚｅｄ”が含まれる場合には、“ｉｆ”フィールド内のそれ以外の条件を満たすＣＵＤＡ ＡＰＩがフックされた時に、状態管理部１４２は、当該ＣＵＤＡ ＡＰＩのＧＰＵ１７での実行完了までを監視する。状態管理部１４２は、ＧＰＵ１７での実行完了を検知したとき、条件を満たしたと判定する。なお、ＧＰＵ１７での実行完了の監視については、後述する。

そして、状態管理部１４２は、コア終了パターンを検知したとき、現在の状態をコア処理から後処理に更新する。この後、状態管理部１４２は、スケジューラ部２１にコア終了を通知する。

なお、状態管理部１４２は、上記以外のとき、ＣＵＤＡＡＰＩフック部１４１から渡されたＣＵＤＡ ＡＰＩを実行し、返り値をＣＵＤＡＡＰＩフック部１４１に返す。

ここで、ＧＰＵ１７での実行完了の監視について、図８Ａおよび図８Ｂを参照して説明する。図８Ａおよび図８Ｂは、ＧＰＵでの実行完了の監視を説明する図である。なお、図８Ａでは、監視の中で“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”がフックされない場合を説明し、図８Ｂでは、監視の中で“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”がフックされた場合を説明する。

図８Ａに示すように、監視の中で“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”がフックされない場合が表わされている。まず、“ｉｆ”フィールドに“ｓｙｎｃｈｒｏｎｉｚｅｄ”が含まれる場合には、“ｉｆ”フィールド内のそれ以外の条件を満たすＣＵＤＡ ＡＰＩがフックされた時に、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象ストリーム変数に当該ＣＵＤＡ ＡＰＩの引数のストリーム番号をセットする。ここでは、監視対象のＣＵＤＡ ＡＰＩは“ｃｕＭｅｍｃｐｙＤｔｏＨＡｓｙｎｃ”、引数は“Ｓｔｒｅａｍ １”である。かかる場合には、内部変数としての監視対象ストリーム変数に引数“Ｓｔｒｅａｍ”の“１”がセットされる。

次に、“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”のＣＵＤＡ ＡＰＩがフックされた時、引数のストリーム番号が監視対象ストリーム変数と同じであれば、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象イベントに当該ＣＵＤＡ ＡＰＩの引数のイベント番号をセットする。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”、引数は“Ｓｔｒｅａｍ １”および“Ｅｖｅｎｔ １”である。かかる場合には、引数のストリーム番号が監視対象ストリーム変数と同じであるので、内部変数としての監視対象イベント変数に引数“Ｅｖｅｎｔ”の“１”がセットされる。

次に、“ｃｕＥｖｅｎｔＱｕｅｒｙ”のＣＵＤＡ ＡＰＩがフックされた時、引数のイベント番号が監視対象イベント変数と同じであり、当該ＣＵＤＡ ＡＰＩの実行の返り値が「０」であれば、状態管理部１４２は、監視対象のＣＵＤＡ ＡＰＩのＧＰＵ１７での実行が完了したと判定する。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＥｖｅｎｔＱｕｅｒｙ”、引数は“Ｅｖｅｎｔ １”である。かかる場合には、引数のイベント番号が監視対象イベント変数と同じであるので、実行の返り値が「０」であれば、監視対象のＣＵＤＡ ＡＰＩのＧＰＵ１７での実行が完了したと判定される。

図８Ｂに示すように、監視の中で“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”がフックされる場合が表わされている。まず、“ｉｆ”フィールドに“ｓｙｎｃｈｒｏｎｉｚｅｄ”が含まれる場合には、“ｉｆ”フィールド内のそれ以外の条件を満たすＣＵＤＡ ＡＰＩがフックされた時に、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象ストリーム変数に当該ＣＵＤＡ ＡＰＩの引数のストリーム番号をセットする。ここでは、監視対象のＣＵＤＡ ＡＰＩは“ｃｕＭｅｍｃｐｙＤｔｏＨＡｓｙｎｃ”、引数は“Ｓｔｒｅａｍ １”である。かかる場合には、内部変数としての監視対象ストレーム変数に引数“Ｓｔｒｅａｍ”の“１”がセットされる。

次に、“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”のＣＵＤＡ ＡＰＩがフックされた時、引数のストリーム番号が監視対象ストリーム変数と同じであれば、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象イベント変数に当該ＣＵＤＡ ＡＰＩの引数のイベント番号をセットする。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”、引数は“Ｓｔｒｅａｍ １”および“Ｅｖｅｎｔ １”である。かかる場合には、引数のストリーム番号が監視対象ストリーム変数と同じであるので、内部変数としての監視対象イベント変数に引数“Ｅｖｅｎｔ”の“１”がセットされる。

次に、“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”のＣＵＤＡ ＡＰＩがフックされた時、引数のイベント番号が監視対象イベント変数と同じであれば、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象ストリーム変数に引数のストリーム番号をセットする。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”、引数は“Ｅｖｅｎｔ １”および“Ｓｔｒｅａｍ ２”である。かかる場合には、引数のイベント番号が監視対象イベント変数と同じであるので、内部変数としての監視対象ストリーム変数に引数“Ｓｔｒｅａｍ”の“２”がセットされる。

次に、“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”のＣＵＤＡ ＡＰＩがフックされた時、引数のストリーム番号が監視対象ストリーム変数と同じであれば、状態管理部１４２は、以下の処理を行う。状態管理部１４２は、状態管理用の内部変数としての監視対象イベント変数に当該ＣＵＤＡ ＡＰＩの引数のイベント番号をセットする。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＥｖｅｎｔＲｅｃｏｒｄ”、引数は“Ｓｔｒｅａｍ ２”および“Ｅｖｅｎｔ ２”である。かかる場合には、引数のストリーム番号が監視対象ストリーム変数と同じであるので、内部変数としての監視対象イベント変数に引数“Ｅｖｅｎｔ”の“２”がセットされる。

この後、引数のイベント番号が監視対象イベント変数と同じである“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”がフックされた時、状態管理部１４２は、前述した“ｃｕＳｔｒｅａｍＷａｉｔＥｖｅｎｔ”のＣＵＤＡ ＡＰＩがフックされた時の処理に戻る。

そして、“ｃｕＥｖｅｎｔＱｕｅｒｙ”のＣＵＤＡ ＡＰＩがフックされた時、引数のイベント番号が監視対象イベント変数と同じであり、当該ＣＵＤＡ ＡＰＩの実行の返り値が「０」であれば、状態管理部１４２は、監視対象のＣＵＤＡ ＡＰＩのＧＰＵ１７での実行が完了したと判定する。ここでは、フックされるＣＵＤＡ ＡＰＩは“ｃｕＥｖｅｎｔＱｕｅｒｙ”、引数は“Ｅｖｅｎｔ ２”である。かかる場合には、引数のイベント番号が監視対象イベント変数と同じであるので、実行の返り値が「０」であれば、監視対象のＣＵＤＡ ＡＰＩのＧＰＵ１７での実行が完了したと判定される。

［状態管理部のフローチャート］
次に、実施例に係る状態管理部のフローチャートの一例を、図９を参照して説明する。図９は、実施例に係る状態管理部のフローチャートの一例を示す図である。

状態管理部１４２は、スケジューラ部２１から状態管理初期化指示とモデル名とを受信する（ステップＳ５１）。状態管理部１４２は、遷移パターンＤＢ１４５からモデル名に対応する遷移パターンを取得する。状態管理部１４２は、状態を前処理にセットする（ステップＳ５２）。取得した遷移パターンには、コア開始パターンおよびコア終了パターンが含まれる。コア開始パターンには、コア開始判定条件が含まれる。コア終了パターンには、コア終了判定条件が含まれる。

状態管理部１４２は、スケジューラ部２１に状態管理初期化完了通知を送信する（ステップＳ５３）。状態管理部１４２は、ＡＩフレームワーク１３からＣＵＤＡ ＡＰＩをフックする（ステップＳ５４）。

状態管理部１４２は、状態が前処理であるか否かを判定する（ステップＳ５５）。状態が前処理であると判定した場合には（ステップＳ５５；Ｙｅｓ）、状態管理部１４２は、コア開始判定条件に返り値が必要であるか否かを判定する（ステップＳ５６）。例えば、コア開始判定条件に“ｒｅｔｕｒｎ＝０”が設定されている場合である。コア開始判定条件に返り値が必要であると判定した場合には（ステップＳ５６；Ｙｅｓ）、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩを実行する（ステップＳ５７）。

状態管理部１４２は、実行した結果、コア開始判定条件を満たすか否かを判定する（ステップＳ５８）。コア開始判定条件を満たさないと判定した場合には（ステップＳ５８；Ｎｏ）、状態管理部１４２は、ステップＳ６５に移行する。

一方、コア開始判定条件を満たすと判定した場合には（ステップＳ５８；Ｙｅｓ）、状態管理部１４２は、スケジューラ部２１にコア開始を通知する。そして、状態管理部１４２は、返り値をＡＰＩ呼び出し制御部１４３に送信する（ステップＳ５９）。そして、状態管理部１４２は、ＡＰＩ呼び出し制御部１４３から返り値を受信して、状態をコア処理にセットする（ステップＳ６０）。そして、状態管理部１４２は、ステップＳ６５に移行する。

一方、コア開始判定条件に返り値が必要でないと判定した場合には（ステップＳ５６；Ｎｏ）、状態管理部１４２は、コア開始判定条件を満たすか否かを判定する（ステップＳ６１）。コア開始判定条件を満たすと判定した場合には（ステップＳ６１；Ｙｅｓ）、状態管理部１４２は、スケジューラ部２１にコア開始を通知する。そして、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩと引数をＡＰＩ呼び出し制御部１４３に送信する（ステップＳ６２）。そして、状態管理部１４２は、ＡＰＩ呼び出し制御部１４３から返り値を受信して、状態をコア処理にセットする（ステップＳ６３）。そして、状態管理部１４２は、ステップＳ６５に移行する。

一方、コア開始判定条件を満たさないと判定した場合には（ステップＳ６１；Ｎｏ）、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩを実行する（ステップＳ６４）。そして、状態管理部１４２は、ステップＳ６５に移行する。

ステップＳ６５において、状態管理部１４２は、返り値をＡＩフレームワーク１３に返す（ステップＳ６５）。そして、状態管理部１４２は、次のＣＵＤＡ ＡＰＩをフックすべく、ステップＳ５４に移行する。

ステップＳ５５において、状態が前処理でないと判定した場合には（ステップＳ５５；Ｎｏ）、状態管理部１４２は、状態がコア処理であるか否かを判定する（ステップＳ６６）。状態がコア処理であると判定した場合には（ステップＳ６６；Ｙｅｓ）、状態管理部１４２は、コア終了判定条件に返り値が必要であるか否かを判定する（ステップＳ６７）。例えば、コア終了判定条件に“ｒｅｔｕｒｎ＝０”が設定されている場合である。コア終了判定条件に返り値が必要であると判定した場合には（ステップＳ６７；Ｙｅｓ）、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩを実行する（ステップＳ６８）。

そして、状態管理部１４２は、実行した結果、コア終了判定条件を満たすか否かを判定する（ステップＳ６９）。コア終了判定条件を満たさないと判定した場合には（ステップＳ６９；Ｎｏ）、状態管理部１４２は、ステップＳ７４に移行する。

一方、コア終了判定条件を満たすと判定した場合には（ステップＳ６９；Ｙｅｓ）、状態管理部１４２は、スケジューラ部２１にコア終了を通知して、状態を後処理にセットする（ステップＳ７０）。そして、状態管理部１４２は、ステップＳ７４に移行する。

一方、コア終了判定条件に返り値が必要でないと判定した場合には（ステップＳ６７；Ｎｏ）、状態管理部１４２は、コア終了判定条件を満たすか否かを判定する（ステップＳ７１）。コア終了判定条件を満たすと判定した場合には（ステップＳ７１；Ｙｅｓ）、状態管理部１４２は、スケジューラ部２１にコア終了を通知して、状態を後処理にセットする（ステップＳ７２）。そして、状態管理部１４２は、ステップＳ７３に移行する。

一方、コア終了判定条件を満たさないと判定した場合には（ステップＳ７１；Ｎｏ）、状態管理部１４２は、ステップＳ７３に移行する。ステップＳ７３において、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩを実行する（ステップＳ７３）。そして、状態管理部１４２は、ステップＳ７４に移行する。

ステップＳ７４において、状態管理部１４２は、返り値をＡＩフレームワーク１３に返す（ステップＳ７４）。そして、状態管理部１４２は、次のＣＵＤＡ ＡＰＩをフックすべく、ステップＳ５４に移行する。

一方、状態がコア処理でないと判定した場合には（ステップＳ６６；Ｎｏ）、状態管理部１４２は、フックしたＣＵＤＡ ＡＰＩを実行して、返り値をＡＩフレームワーク１３に返す（ステップＳ７５）。そして、状態管理部１４２は、次のＣＵＤＡ ＡＰＩをフックすべく、ステップＳ５４に移行する。

［サーバのハードウェア構成］
図１０は、サーバのハードウェア構成の一例を示す図である。図１０に示すように、サーバ１は、ＣＰＵ３１に加えてＧＰＵ３２を有する。そして、サーバ１は、メモリ３３、ハードディスク３４およびネットワークインターフェイス３５を有する。図１０に示した各部は、例えばバス３６で相互に接続される。

ネットワークインターフェイス３５は、ネットワークインターフェイスカード等であり、ストレージサーバ（図示しない）等の他の装置との通信を行う。ハードディスク３４は、図３に示した機能を動作させるプログラムや遷移パターンＤＢ１４５等を記憶する。

ＣＰＵ３１は、図３に示した各処理部と同様の処理を実行するプログラムをハードディスク３４等から読み出してメモリ３３に展開することで、図３等で説明した各機能を実行するプロセスを動作させる。例えば、このプロセスは、サーバ１が有する各処理部と同様の機能を実行する。具体的には、ＣＰＵ３１は、プロセス１０、プロセス２０およびＧＰＵドライバ１６等と同様の機能を有するプログラムをハードディスク３４等から読み出す。そして、ＣＰＵ３１は、プロセス１０、プロセス２０およびＧＰＵドライバ１６等と同様の処理を実行するプロセスを実行する。

ＧＰＵ３２は、推論処理の中のＧＰＵ処理を実行するプログラムをハードディスク３４等から読み出してメモリ３３に展開することで、当該プログラムを実行するプロセスを動作させる。ＧＰＵ３２は、複数のプロセス１０を多重で動作させる。

［サーバの各モジュール単位のシーケンス］
次に、実施例に係るサーバの各モジュール単位のシーケンスの一例を、図１１を参照して説明する。図１１は、実施例に係るサーバの各モジュール単位のシーケンスの一例を示す図である。

まず、アプリケーション１１は、モデルロード命令およびロード対象のモデルのパスを第１のＷｒａｐｐｅｒ部１２に送信する（Ｓ１１）。すると、第１のＷｒａｐｐｅｒ部１２は、アプリケーション１１からのモデルロード命令をフックする。そして、第１のＷｒａｐｐｅｒ部１２は、パス－モデル対応表１２５とロード対象のモデルのパスから、ロード対象のモデル名を取得し、スケジューラ部２１にモデルロード開始通知、プロセスＩＤおよびモデル名を送信する（Ｓ１２）。

モデルロード開始通知、プロセスＩＤおよびモデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対し、推論回数のカウントを初期化する（Ｓ１３）。

第１のＷｒａｐｐｅｒ部１２は、ＡＩフレームワーク１３のモデルロードＡＰＩを利用し、ロード対象のモデル名のモデルオブジェクトをロードする（Ｓ１４～Ｓ１６）。この後、第１のＷｒａｐｐｅｒ部１２は、ロードしたモデルオブジェクトにフック用ＡＰＩとモデル名の情報を追加し、フック用モデルを生成する（Ｓ１７）。そして、第１のＷｒａｐｐｅｒ部１２は、フック用モデルＡＰＩ（１１１）をアプリケーション１１に返す（Ｓ１８）。

アプリケーション１１が、フック用モデルＡＰＩ（１１１）を用いて初回の推論を実行する（Ｓ１９）。すると、第１のＷｒａｐｐｅｒ部１２は、フック用モデルが推論開始命令をフックし、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ２０）。この後、第１のＷｒａｐｐｅｒ部１２は、スケジューラ部２１からの指示を待機する。

推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを１加えた値「１」に更新する（Ｓ２１）。そして、スケジューラ部２１は、推論回数が「１」（初回）であるので、プロセスＩＤが示すプロセス１０の第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ２２）。

推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、推論を実行する（Ｓ２３）。ＡＩフレームワーク１３は、推論処理を、ＧＰＵ１７を利用して実行する（Ｓ２３Ａ，Ｓ２４）。そして、第１のＷｒａｐｐｅｒ部１２は、推論結果を受信すると、アプリケーション１１に返す（Ｓ２５，Ｓ２６）。

次に、アプリケーション１１が、フック用モデルＡＰＩ（１１１）を用いて二回目以降の推論を実行する（Ｓ２７）。すると、第１のＷｒａｐｐｅｒ部１２は、フック用モデルが推論開始命令をフックし、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ２８）。この後、第１のＷｒａｐｐｅｒ部１２は、スケジューラ部２１からの指示を待機する。

推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを１加えた値に更新する（Ｓ２９）。そして、スケジューラ部２１は、推論回数が「２」以上であるので、プロセスＩＤが示すプロセスの第２のＷｒａｐｐｅｒ部１４に状態管理初期化指示とモデル名を送信する（Ｓ３０）。そして、スケジューラ部２１は、第２のＷｒａｐｐｅｒ部１４からの応答を待機する。

状態管理初期化指示とモデル名を受信した第２のＷｒａｐｐｅｒ部１４は、遷移パターンＤＢからモデル名に対応する遷移パターンをロードし、内部変数を初期化する（Ｓ３１）。この後、第２のＷｒａｐｐｅｒ部１４は、状態管理初期化完了通知をスケジューラ部２１に送信する（Ｓ３２）。

状態管理初期化完了通知を受信したスケジューラ部２１は、送信元のプロセスＩＤが示すプロセスの第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ３３）。

推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、推論を実行する（Ｓ３４）。ＡＩフレームワーク１３は、推論処理を、ＧＰＵ１７を利用すべく、第２のＷｒａｐｐｅｒ部１４を経由してＣＵＤＡライブラリ１５を実行する（Ｓ３４Ａ，Ｓ３５）。

そして、第２のＷｒａｐｐｅｒ部１４は、ＡＩフレームワーク１３からＣＵＤＡ ＡＰＩをフックしたとき（Ｓ３６）、ロードした遷移パターンに基づき、ＣＵＤＡ ＡＰＩ、引数から状態等の内部変数を更新する。そして、第２のＷｒａｐｐｅｒ部１４は、コア開始のパターンを検知すると（Ｓ３７）、スケジューラ部２１にコア開始通知とプロセスＩＤを送信する（Ｓ３８）。

スケジューラ部２１は、コア開始通知キュー２１８が空であれば、コア開始指示をプロセスＩＤが示すプロセス１０の第２のＷｒａｐｐｅｒ部１４に送信する（Ｓ３９）。なお、スケジューラ部２１は、コア開始通知キュー２１８が空でなければ、コア開始通知キュー２１８にプロセスＩＤを追加する。

コア開始指示を受信した第２のＷｒａｐｐｅｒ部１４は、ＧＰＵ１７を利用すべく、ＣＵＤＡライブラリ１５を実行する（Ｓ４０）。

そして、第２のＷｒａｐｐｅｒ部１４は、コア終了のパターンを検知すると（Ｓ４２）、スケジューラ部２１にコア終了通知とプロセスＩＤを送信する（Ｓ４３）。なお、コア終了通知とプロセスＩＤを受信したスケジューラ部２１は、コア開始通知キュー２１８の当該プロセスＩＤを削除する。この後、スケジューラ部２１は、コア開始通知キュー２１８内のプロセスＩＤの一つを選択し、選択したプロセスＩＤが示すプロセス１０の第２のＷｒａｐｐｅｒ部１４にコア開始指示を送信する。

この後、第２のＷｒａｐｐｅｒ部１４は、内部変数の更新時に、ＣＵＤＡ ＡＰＩを実行していない場合には、ＧＰＵ１７を利用すべく、ＣＵＤＡライブラリ１５を実行する（Ｓ４４～Ｓ４６）。そして、第２のＷｒａｐｐｅｒ部１４は、ＣＵＤＡ ＡＰＩを実行して返り値をＡＩフレームワーク１３に返す。推論実行したＡＩフレームワーク１３は、推論結果を第１のＷｒａｐｐｅｒ部１２を経由してアプリケーション１１に返す（Ｓ４７，Ｓ４８）。

ここで、二回目以降の推論の場合には、第２のＷｒａｐｐｅｒ部１４は、ＡＩフレームワーク１３からＣＵＤＡ ＡＰＩをフックしたとき、モデル名に対応する遷移パターンに基づいて、コア開始およびコア終了を検知する。そして、第２のＷｒａｐｐｅｒ部１４およびスケジューラ部２１は、コア処理が他のコア処理と重ならないようにコア処理の実行を制御する。ところが、初回推論の場合には、第２のＷｒａｐｐｅｒ部１４は、ＡＩフレームワーク１３からＣＵＤＡ ＡＰＩをフックしても、そのままコア処理を実行する。これは、以下の理由による。ＡＩフレームワーク１３が推論を実行する場合、初回推論のとき推論処理を実行しながらＧＰＵ１７を利用する際の無駄をなくすためにＧＰＵ利用パターンを最適化する。このため、初回推論では、秒オーダーで処理されるのに対して、二回目以降の推論では、数十～数百ミリ秒のオーダーで処理される。すなわち、初回推論が二回目以降の推論より長い処理となる。したがって、初回推論では、他のコア処理を秒オーダーでブロックしないようにするために、他の推論処理との並列実行を許可すべく、第２のＷｒａｐｐｅｒ部１４は、そのままコア処理を実行するようにする。

［複数プロセスの推論のシーケンス］
ここで、複数のプロセス１０の推論のシーケンスの一例を、図１２Ａおよび図１２Ｂを参照して説明する。図１２Ａおよび図１２Ｂは、複数プロセスの推論のシーケンスの一例を示す図である。推論を実行するプロセスは、プロセスａ（１０ａ）およびプロセスｂ（１０ｂ）であるとする。スケジューラ部２１は、プロセスｃ（２０）であるとする。

図１２Ａに示すように、まず、プロセスａは、モデルロード開始通知、プロセスＩＤおよびモデル名をスケジューラ部２１に送信する（Ｓ１０１）。例えば、プロセスａにおいて、アプリケーション１１は、モデルロード命令およびロード対象のモデルのパスを第１のＷｒａｐｐｅｒ部１２に送信する。すると、第１のＷｒａｐｐｅｒ部１２は、アプリケーション１１からのモデルロード命令をフックする。そして、第１のＷｒａｐｐｅｒ部１２は、パス－モデル対応表１２５とロード対象のモデルのパスから、ロード対象のモデル名を取得し、スケジューラ部２１にモデルロード開始通知、プロセスＩＤおよびモデル名を送信する。

モデルロード開始通知、プロセスＩＤおよびモデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対し、推論回数のカウントを初期化する（Ｓ１０２）。そして、スケジューラ部２１は、プロセスＩＤおよびモデル名の組み合わせに対し、推論回数を０回として、推論回数ＤＢ２１７に登録する。

また、プロセスｂは、モデルロード開始通知、プロセスＩＤおよびモデル名をスケジューラ部２１に送信する（Ｓ１０３）。なお、Ｓ１０３を実施する際のプロセスｂ内での実施内容は、プロセスａのＳ１０１の場合と同様であるので、その説明を省略する。プロセスａのモデルロード開始通知、プロセスＩＤおよびモデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対し、推論回数のカウントを初期化する（Ｓ１０４）。そして、スケジューラ部２１は、プロセスＩＤおよびモデル名の組み合わせに対し、推論回数を０回として、推論回数ＤＢ２１７に登録する。

続いて、プロセスａは、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ１０５）。例えば、第１のＷｒａｐｐｅｒ部１２は、ＡＩフレームワーク１３のモデルロードＡＰＩを利用し、ロード対象のモデル名のモデルオブジェクトをロードする。この後、第１のＷｒａｐｐｅｒ部１２は、ロードしたモデルオブジェクトにフック用ＡＰＩとモデル名の情報を追加し、フック用モデルを生成する。そして、第１のＷｒａｐｐｅｒ部１２は、フック用モデルＡＰＩ（１１１）をアプリケーション１１に返す。アプリケーション１１がフック用モデルＡＰＩ（１１１）を用いて初回の推論を実行すると、第１のＷｒａｐｐｅｒ部１２では、フック用モデルが推論開始命令をフックし、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する。この後、第１のＷｒａｐｐｅｒ部１２は、スケジューラ部２１からの指示を待機する。

推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、推論回数ＤＢ２１７から、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを取得する。そして、スケジューラ部２１は、推論回数のカウントを１加えた値「１」に更新し（Ｓ１０６）、推論回数ＤＢ２１７に登録する。そして、スケジューラ部２１は、推論回数が「１」（初回）であるので、プロセスＩＤが示すプロセス１０ａの第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ１０７）。

推論開始指示を受信したプロセスａは、初回推論を実行する（Ｓ１０７Ａ）。例えば、推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、推論を実行する。ＡＩフレームワーク１３は、推論処理を、ＧＰＵ１７を利用して実行する。そして、第１のＷｒａｐｐｅｒ部１２は、推論結果を受信すると、アプリケーション１１に返す。

また、プロセスｂは、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ１０８）。なお、Ｓ１０８を実施する際のプロセスｂ内での実施内容は、プロセスａのＳ１０５の場合と同様であるので、その説明を省略する。推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、推論回数ＤＢ２１７から、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを取得する。そして、スケジューラ部２１は、推論回数のカウントを１加えた値「１」に更新し（Ｓ１０９）、推論回数ＤＢ２１７に登録する。そして、スケジューラ部２１は、推論回数が「１」（初回）であるので、プロセスＩＤが示すプロセスｂの第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ１１０）。

推論開始指示を受信したプロセスｂは、初回推論を実行する（Ｓ１１０Ａ）。例えば、推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、推論を実行する。ＡＩフレームワーク１３は、推論処理を、ＧＰＵ１７を利用して実行する。そして、第１のＷｒａｐｐｅｒ部１２は、推論結果を受信すると、アプリケーション１１に返す。

初回推論を終了したプロセスａは、二回目以降の推論を実行すべく、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ１１１）。例えば、アプリケーション１１が、フック用モデルＡＰＩ（１１１）を用いて二回目以降の推論を実行する。すると、第１のＷｒａｐｐｅｒ部１２は、フック用モデルが推論開始命令をフックし、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する。この後、第１のＷｒａｐｐｅｒ部１２は、スケジューラ部２１からの指示を待機する。

推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを１加えた値に更新して（Ｓ１１２）、推論回数ＤＢ２１７に登録する。そして、スケジューラ部２１は、推論回数が「２」以上であるので、プロセスＩＤが示すプロセスａの第２のＷｒａｐｐｅｒ部１４に状態管理初期化指示とモデル名を送信する（Ｓ１１３）。そして、スケジューラ部２１は、第２のＷｒａｐｐｅｒ部１４からの応答を待機する。

プロセスａでは、状態管理初期化指示とモデル名を受信した第２のＷｒａｐｐｅｒ部１４は、遷移パターンＤＢからモデル名に対応する遷移パターンをロードし、内部変数を初期化し、状態管理初期化完了通知をスケジューラ部２１に送信する（Ｓ１１４）。

状態管理初期化完了通知を受信したスケジューラ部２１は、送信元のプロセスＩＤが示すプロセスａの第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ１１５）。

プロセスａでは、推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、前処理を実行する（Ｓ１１５Ａ）。

初回推論を終了したプロセスｂは、二回目以降の推論を実行すべく、推論開始通知、プロセスＩＤ、モデル名をスケジューラ部２１に送信する（Ｓ１１６）。なお、Ｓ１１６を実施する際のプロセスｂ内での実施内容は、プロセスａのＳ１１１の場合と同様であるので、その説明を省略する。

推論開始通知、プロセスＩＤ、モデル名を受信したスケジューラ部２１は、プロセスＩＤとモデル名の組み合わせに対する推論回数のカウントを１加えた値に更新して（Ｓ１１７）、推論回数ＤＢ２１７に登録する。そして、スケジューラ部２１は、推論回数が「２」以上であるので、プロセスＩＤが示すプロセスｂの第２のＷｒａｐｐｅｒ部１４に状態管理初期化指示とモデル名を送信する（Ｓ１１８）。そして、スケジューラ部２１は、第２のＷｒａｐｐｅｒ部１４からの応答を待機する。

プロセスｂでは、状態管理初期化指示とモデル名を受信した第２のＷｒａｐｐｅｒ部１４は、遷移パターンＤＢからモデル名に対応する遷移パターンをロードし、内部変数を初期化し、状態管理初期化完了通知をスケジューラ部２１に送信する（Ｓ１１９）。

状態管理初期化完了通知を受信したスケジューラ部２１は、送信元のプロセスＩＤが示すプロセスｂの第１のＷｒａｐｐｅｒ部１２に推論開始指示を送信する（Ｓ１２０）。

プロセスｂでは、推論開始指示を受信した第１のＷｒａｐｐｅｒ部１２は、モデルオブジェクトを用いて、前処理を実行する（Ｓ１２０Ａ）。

図１２Ｂに示すように、前処理を実行中のプロセスａでは、第２のＷｒａｐｐｅｒ部１４が、コア開始のパターンを検知すると、スケジューラ部２１にコア開始通知とプロセスＩＤを送信する（Ｓ１３１）。

プロセスａからコア開始通知とプロセスＩＤを受信したスケジューラ部２１は、コア開始通知キュー２１８からキュー長を取得する（Ｓ１３２）。ここでは、キュー長が０であるとする。すると、スケジューラ部２１は、コア開始通知キュー２１８が空であるので、コア開始指示をプロセスＩＤが示すプロセスａの第２のＷｒａｐｐｅｒ部１４に送信する（Ｓ１３３）。加えて、スケジューラ部２１は、コア開始通知キュー２１８にプロセスａのプロセスＩＤを追加する（Ｓ１３４）。そして、コア開始指示を受信したプロセスａの第２のＷｒａｐｐｅｒ部１４は、コア処理を実行する（Ｓ１３３Ａ）。

また、前処理を実行中のプロセスｂでは、第２のＷｒａｐｐｅｒ部１４が、コア開始のパターンを検知すると、スケジューラ部２１にコア開始通知とプロセスＩＤを送信する（Ｓ１３５）。

プロセスｂからコア開始通知とプロセスＩＤを受信したスケジューラ部２１は、コア開始通知キュー２１８からキュー長を取得する（Ｓ１３６）。ここでは、キュー長が１である。すると、スケジューラ部２１は、コア開始通知キュー２１８が空でないので、コア開始通知キュー２１８にプロセスｂのプロセスＩＤを追加する（Ｓ１３７）。

コア処理を実行中のプロセスａでは、第２のＷｒａｐｐｅｒ部１４が、コア終了のパターンを検知すると、スケジューラ部２１にコア終了通知とプロセスＩＤを送信する（Ｓ１３８）。そして、第２のＷｒａｐｐｅｒ部１４は、引き続き、後処理を実行する（Ｓ１３８Ａ）。

プロセスａからコア終了通知とプロセスＩＤを受信したスケジューラ部２１は、コア開始通知キュー２１８の当該プロセスＩＤを削除する（Ｓ１３９）。そして、スケジューラ部２１は、コア開始通知キュー２１８の先頭のプロセスＩＤを取得する（Ｓ１４０）。ここでは、取得されたプロセスＩＤは、プロセスｂのプロセスＩＤである。すると、スケジューラ部２１は、コア開始指示をプロセスＩＤが示すプロセスｂの第２のＷｒａｐｐｅｒ部１４に送信する（Ｓ１４１）。そして、コア開始指示を受信したプロセスｂの第２のＷｒａｐｐｅｒ部１４は、コア処理を実行する（Ｓ１４１Ａ）。

コア処理を実行中のプロセスｂでは、第２のＷｒａｐｐｅｒ部１４が、コア終了のパターンを検知すると、スケジューラ部２１にコア終了通知とプロセスＩＤを送信する（Ｓ１４２）。そして、第２のＷｒａｐｐｅｒ部１４は、引き続き、後処理を実行する（Ｓ１４２Ａ）。

プロセスｂからコア終了通知とプロセスＩＤを受信したスケジューラ部２１は、コア開始通知キュー２１８の当該プロセスＩＤを削除する（Ｓ１４３）。そして、スケジューラ部２１は、引き続き、コア開始通知キュー２１８の先頭のプロセスＩＤを取得する（Ｓ１４４）。そして、スケジューラ部２１は、プロセスＩＤを取得できれば、次のコア開始指示を該当するプロセスＩＤが示すプロセス１０に指示することになる。

［実施例の効果］
このようにして、上記実施例では、サーバ１は、ＧＰＵ１７を用いる推論処理の中核を担うコア処理であって前記ＧＰＵ１７を用いるコア処理の開始および終了の判定に用いるメッセージパターンを遷移パターンＤＢ１４５に記憶する。サーバ１は、推論処理を実行するアプリケーションから出力されるメッセージを監視する。サーバ１は、遷移パターンＤＢ１４５に記憶されたメッセージパターンを用いて、監視して得られたメッセージのパターンから、コア処理の開始および終了のタイミングを判定する。サーバ１は、コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければコア処理を開始し、他のコア処理を実行しているプロセスがあれば、コア処理のプロセスを識別するプロセス識別子をコア開始通知キュー２１８に蓄積する。かかる構成によれば、サーバ１は、１台のＧＰＵ１７が複数の推論処理を多重で実行しても、推論処理の重複実行による処理時間の増加を抑制することが可能となる。特に、サーバ１は、遷移パターンＤＢ１４５を用いてコア処理の開始および終了のタイミングを判定することで、コア処理の時間を事前に調査する事前調査にかかるコストを不要とし、コア処理の干渉による処理時間の増加を抑制できる。

また、上記実施例では、サーバ１は、コア処理の終了のタイミングを判定した場合には、終了のタイミングを判定したコア処理を実行していたプロセスのプロセス識別子をコア開始通知キュー２１８から削除する。かかる構成によれば、サーバ１は、コア処理の終了のタイミングをリアルタイムに得ることができ、直ぐに次のコア処理を開始することができ、推論処理の重複実行による処理時間の増加を確実に抑制できる。

また、上記実施例では、コア処理の開始および終了の判定に用いるメッセージパターンは、ＧＰＵ１７を利用する特定のメッセージを取得する場合、ＧＰＵ１７を利用する特定のメッセージを実行して返り値を取得する場合、ＧＰＵ１７を利用する特定のメッセージのＧＰＵ１７での実行が完了した場合を含む。かかる構成によれば、サーバ１は、各種におけるコア処理の開始パターン、終了パターンを用いることで、多様な推論処理の重複実行による処理時間の増加を確実に抑制できる。

［その他］
なお、図示したサーバ１に含まれる第１のＷｒａｐｐｅｒ部１２、第２のＷｒａｐｐｅｒ部１４およびスケジューラ部２１の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、状態管理部１４２を、状態管理を初期化する初期化部と、コア開始パターンを検知した際の処理部と、コア終了パターンを検知した際の処理部と、コア開始、コア終了のいずれも検知しない場合の処理部とに分散しても良い。また、モデル識別部１２２とフック用モデル生成部１２３とを１つの部として統合しても良い。また、遷移パターンＤＢ１４５などを記憶する記憶部（図示しない）をサーバ１の外部装置としてネットワーク経由で接続するようにしても良い。

１ サーバ
１０，２０ プロセス
１１ アプリケーション
１２ 第１のＷｒａｐｐｅｒ部
１３ ＡＩフレームワーク
１４ 第２のＷｒａｐｐｅｒ部
１５ ＣＵＤＡライブラリ
１６ ＧＰＵドライバ
１７ ＧＰＵ
２１ スケジューラ部
１１１ フック用モデルＡＰＩ
１２１ モデルロードフック部
１２２ モデル識別部
１２３ フック用モデル生成部
１２４，１４４，２１６ プロセス間通信部
１２５ パス－モデル対応表
１２６ フック用モデル
１３１ モデルロード部
１３２ 推論実行部
１３３ モデルオブジェクト
１４１ ＣＵＤＡＡＰＩフック部
１４２ 状態管理部
１４３ ＡＰＩ呼び出し制御部
１４５ 遷移パターンＤＢ
２１１ 推論回数カウント部
２１２ 処理判定部
２１３ 推論開始制御部
２１４ 状態管理初期化指示部
２１５ コア実行スケジュール部
２１７ 推論回数ＤＢ
２１８ コア開始通知キュー

Claims (6)

1. 推論処理にＧＰＵ（Graphical Processing Unit）を用いる情報処理装置であって、
   前記推論処理を実行するアプリケーションから出力されるメッセージを監視する監視部と、
   前記監視部による監視によって取得されるメッセージのパターンから、前記推論処理の中核を担うコア処理であって前記ＧＰＵを用いるコア処理の開始および終了のタイミングを判定する判定部と、
   前記コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければ、前記コア処理を開始し、前記他のコア処理を実行しているプロセスがあれば、前記コア処理のプロセスを識別するプロセス識別子をキューに蓄積する制御部と、
   を有することを特徴とする情報処理装置。
2. 前記制御部は、前記コア処理の終了のタイミングを判定した場合には、終了のタイミングを判定した前記コア処理を実行していたプロセスのプロセス識別子を前記キューから削除する
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記コア処理の開始および終了の判定に用いるメッセージパターンを記憶する記憶部をさらに有し、
   前記判定部は、前記記憶部に記憶されたメッセージパターンに基づいて、前記取得されるメッセージのパターンから前記コア処理の開始および終了のタイミングを判定する
   ことを特徴とする請求項１または２に記載の情報処理装置。
4. 前記メッセージパターンは、前記ＧＰＵを利用する特定のメッセージを取得する場合、前記ＧＰＵを利用する特定のメッセージを実行して返り値を取得する場合、前記ＧＰＵを利用する特定のメッセージの前記ＧＰＵでの実行が完了した場合を含む
   ことを特徴とする請求項１に記載の情報処理装置。
5. ＧＰＵ（Graphical Processing Unit）を用いて推論処理を実行する多重制御プログラムであって、
   前記推論処理を実行するアプリケーションから出力されるメッセージを監視し、
   監視によって取得されるメッセージのパターンから、前記推論処理の中核を担うコア処理であって前記ＧＰＵを用いるコア処理の開始および終了のタイミングを判定し、
   前記コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければ、前記コア処理を開始し、前記他のコア処理を実行しているプロセスがあれば、前記コア処理のプロセスを識別するプロセス識別子をキューに蓄積する、
   処理をコンピュータに実行させる多重制御プログラム。
6. ＧＰＵ（Graphical Processing Unit）を用いて推論処理を実行する多重制御方法であって、
   前記推論処理を実行するアプリケーションから出力されるメッセージを監視し、
   監視によって取得されるメッセージのパターンから、前記推論処理の中核を担うコア処理であって前記ＧＰＵを用いるコア処理の開始および終了のタイミングを判定し、
   前記コア処理の開始のタイミングを判定した場合には、他のコア処理を実行しているプロセスがなければ、前記コア処理を開始し、前記他のコア処理を実行しているプロセスがあれば、前記コア処理のプロセスを識別するプロセス識別子をキューに蓄積する
   処理をコンピュータが実行する多重制御方法。

Images