バッチ推論: 複数のプロンプトを 1 回のリクエストで送り、応答を非同期に生成して保存先に出力する。
バッチ推論は、複数のプロンプトを 1 回のリクエストで送り、応答を非同期で生成して保存先に出力する方式です。
この企業は、全件を入力ファイルにまとめて S3 に置いて 1 回の依頼で処理させ、完了後に出力ファイルを取得しているので、バッチ推論に当たります。
ある企業は、顧客レビュー 5 万件の要約を FM で作成します。結果は翌日までに揃えば足りるため、全件を入力ファイルにまとめて Amazon S3 に置き、1 回の依頼で処理させて、完了後に出力ファイルを取得します。 この企業が使っている呼び出し方式はどれですか。
全件を入力ファイルにまとめて 1 回で依頼し、完了後に出力を取得する方式が何に当たるかを選ぶ
バッチ推論: 複数のプロンプトを 1 回のリクエストで送り、応答を非同期に生成して保存先に出力する。
バッチ推論は、複数のプロンプトを 1 回のリクエストで送り、応答を非同期で生成して保存先に出力する方式です。
この企業は、全件を入力ファイルにまとめて S3 に置いて 1 回の依頼で処理させ、完了後に出力ファイルを取得しているので、バッチ推論に当たります。
オンデマンド: リクエストのたびにモデルを呼び出し、その場で応答を受け取って、すぐに結果を利用する。
リクエストのたびに呼び出して応答を受け取るオンデマンドは、顧客との対話のようにその場の応答が要る場面に向きます。
しかし、この企業は全件をまとめて依頼し、完了後に出力ファイルを取得しているので、この方式ではありません。
Provisioned Throughput: モデルに対して購入した処理能力で、処理するトークンの量や速度を高める。
Provisioned Throughput は、モデルに対して購入した処理能力で、処理するトークンの量や速度を高める仕組みです。
しかし、これは処理能力の確保の説明で、この企業が行っている入力ファイルの一括依頼と、完了後の出力ファイルの取得ではありません。
ストリーミング: 応答の生成中から断片を順に受け取り、全体の完了を待たずに利用者の画面へ表示し始める。
ストリーミングは、応答がストリームとして順に返る方式で、生成の途中から画面に表示したい場面に向きます。
しかし、この企業は結果が翌日までに揃えばよく、完了後に出力ファイルを取得しているので、この方式ではありません。
FM の呼び出し方式は、プロンプトの送り方と応答の受け取り方で見分けます。
・リクエストのたびに送り、その場で受け取る → オンデマンド
・複数のプロンプトをまとめて送り、非同期で生成して保存先に出力する → バッチ推論
・購入した処理能力で処理量と速度を高める → Provisioned Throughput
・応答を生成中から順に受け取る → ストリーミング
「入力ファイルを置いて依頼し、完了後に出力ファイルを取得する」場面はバッチ推論を示します。