同じモデルでも、入力・出力・キャッシュで単価が分かれています。
見積もりが外れるのは、たいてい出力側です。読み方と、費用を下げる順番を見ます。
3つの単価
| 種別 | 何に対する料金か |
|---|---|
| 入力 | こちらが送った指示や資料 |
| 出力 | 返ってきた文章 |
| キャッシュ読み出し | 前と同じ入力を再利用したぶん |
出力が高いのは、1語ずつ順に生成する処理だからです。入力はまとめて読み込めますが、出力は前の語を見てから次を決める。並列にできないぶん、計算が重くなります。
この差が、見積もりのずれを生みます。長い資料を渡す作業は、入力が大きくても意外と安い。逆に、短い指示から長文を書かせる作業は高くつきます。
キャッシュが効く場面
同じ前置きを何度も送るなら、ここが効きます。
社内規程や商品一覧を毎回添える処理では、その部分が固定です。一度読み込んだ内容を再利用できれば、2回目以降の入力費用が大きく下がる。
条件があります。固定部分を先頭に置き、変わる部分を後ろに回すこと。途中が変わると、そこから先は再利用できません。
有効な時間にも限りがある。数分から数十分で消える設定が多いので、まとめて処理するほうが効きます。
思考の分が上乗せされる
手順を追って考えるモデルでは、注意が要ります。
画面に出ない検討部分も、出力として課金されます。最終的な回答が3行でも、その手前で長く考えていれば、そのぶんが乗る。
見積もりが2倍3倍とずれる原因の多くがこれです。考える深さを指定できるモデルなら、簡単な作業では浅い設定にしておきたい。
画像と音声は換算される
文章以外を渡すときも、単位は同じです。
画像は解像度に応じてトークン数に換算されます。高解像度のまま渡すと、数千トークン分になることがある。読ませたいのが文字だけなら、縮小してから渡すほうが安い。
音声も秒数に応じて換算されます。長い録音をそのまま投げる処理は、想定より高くつきやすい領域です。
料金表には換算の目安が書かれています。見積もりの前に、そこだけは読んでおきたい。
見積もりの立て方
1件あたりの実費を測るのが先です。
本番と同じ形の処理を1回だけ流し、請求の明細を見る。ここで出た数に件数を掛ければ、見積もりになります。
料金表から計算した数は当てになりません。実際のトークン数は、指示文の書き方や資料の中身で変わるからです。
一括処理をかける前には、必ず数件で試す。この一手間で、桁違いの事故は防げます。
下げる順番
効く順に並べると、こうなります。
まず出力を短くする。字数を指定するより、「結論だけ」「表で」と形を決めるほうが確実に減ります。
次に、モデルを下げる。作業によっては小さいモデルで十分です。分類や形式変換なら、差が出ないことが多い。
最後に入力を削る。資料を全部渡さず、必要な章だけ抜く。手間の割に効果が小さいので、最後で構いません。
バッチ処理という選択
急がない処理なら、単価を半分にできる方式があります。
まとめて投げて、結果を待つ形です。数時間かかりますが、その代わり割引が効く。夜間に流して朝に受け取る運用なら、待ち時間は問題になりません。
対話の裏側で動く処理には使えない。定期的な集計や、大量の分類に向いた方式です。
上限を先にかける
事故を金額で止める仕組みが用意されています。
月の上限額、通知のしきい値、鍵ごとの制限。提供元の管理画面で設定できます。繰り返し処理を組むなら、書き始める前に入れておきたい。
無限ループに入った処理が一晩回り続ける、という事故は起こります。上限がかかっていれば、被害はそこで止まる。
通知だけでは間に合いません。気づいたときには終わっているので、止まる設定にしておく必要があります。
統合サービス経由は別物
複数のモデルをまとめて使える仲介サービスでは、料金表の読み方が変わります。
独自のクレジット単位に換算されているため、元の単価から素直に計算できません。同じモデルでも、経由するサービスによって支払額が何倍も違うことがある。
こちらも、実際に少量流して請求を見るしかありません。資料に書かれた単価を信じない運用が要ります。単価が予告なく変わることもあるので、月に一度は明細を確認しておきたい。
出典
出力側の処理が重くなる理由は、下記の生成方式に由来します。
