Summary

  • OpenAIのBatch APIは同期APIより50％低い料金と24時間の処理枠を掲げる。期限切れのバッチでも、完了したリクエストが消費したトークンには料金がかかる。
  • 未完了のリクエストは取り消され、batch_expiredとしてエラーファイルに記録される。入力と出力を行番号で合わせず、custom_idで突き合わせて不足分を確定する。

値引き率は一つの数字で示せる。納品率は、一行ずつ数えなければ分からない。

OpenAIのBatch APIは、複数のリクエストをJSONLファイルにまとめ、非同期で実行する仕組みだ。公式ガイドは同期APIに対する50％の割引、別枠のレート制限、24時間の処理時間を示す。大量の評価や文書分類、埋め込み生成には魅力的な条件である。安い計算時間を買える。しかし発注者が欲しいのは多くの場合、計算時間そのものではなく、入力全件に対応した完成物だ。

期限に収まらなかったバッチはexpiredになる。OpenAIは、処理済みの応答を出力ファイルに残し、未完了のリクエストを取り消すと説明している。取り消された行はエラーファイルに入り、batch_expiredというコードが付く。処理済みの行で使われたトークンは請求対象だ。ここで「バッチが終わった」と「発注した仕事が終わった」は別の意味になる。

たとえば分類対象の一部に結果がなければ、担当者は全件を分類済みとして次の工程へ渡せない。評価に欠けたケースがあれば、その欠落を知らずに平均だけを出すことも危うい。OpenAIの料金規則は完成した処理に対応している。一方、買い手の損益は必要な全件が使える状態になったかで決まる。半額という見出しだけを稟議に貼れば、この差は消えてしまう。

差を測るための道具は公開されている。入力の各リクエストには一意のcustom_idが必要だ。OpenAIは出力の行順が入力と一致しない場合があると明記する。最初の行同士を合わせる管理表では、結果を別の案件に貼り付けかねない。入力IDの集合を保存し、成功した出力のID、エラーファイルのIDと照合する。これで処理済みと未処理が、件数ではなく名前を持つ。

バッチを取得するAPIには、状態、expires_at、expired_at、出力とエラーのファイルID、総数・完了数・失敗数を示すrequest_countsがある。対象となるバッチではトークン利用量も確認できる。件数は異常の大きさを示すが、どの顧客記録が空白かは示さない。そこはcustom_idで埋めるしかない。

期限切れの後に元の入力を丸ごと再送すれば、すでに答えのある行も再び実行対象になる。不足したIDだけを次のバッチに入れれば、二度目の支出を残作業に絞れる。公開資料には特定の顧客の期限切れファイルや請求書はない。実額を示すには、その顧客の出力・エラー両ファイルとモデル料金が要る。

50％の値引きは確かな価格条件だ。納期に必要な成果物を全部得られるかは、別の管理条件である。安いキューに仕事を入れる前に、期限切れになった場合の残作業を誰が数え、誰が追加支出を決めるのかを決めておくべきだ。

Sources