LLM の API 費用を下げる7つの手 — 効く順に試す

効く順に7つ

同じ前置き（システムプロンプト、参照文書）を繰り返し送る構成では、キャッシュ対応のモデルを使うと入力分が大幅に安くなる。提供元によってはキャッシュ済み入力が通常の10分の1程度になる。

条件は、キャッシュする部分がリクエストの先頭にあり、完全に一致することである。ユーザーの入力を前のほうに置く実装だとキャッシュが効かないので、順序を見直す。

2. 入力を短くする

RAG で上位20件を渡しているなら、5件に減らして品質が落ちるか試す。多くの場合、落ちない。検索の精度が十分なら、件数を増やしても雑音が増えるだけである。

会話履歴も同じで、全部を毎回送る実装になっていることが多い。直近数ターン＋要約に変えると、長い会話での費用が頭打ちになる。

3. 用途ごとにモデルを分ける

分類、抽出、ルーティングのような単純な判断に最上位モデルは要らない。安いモデルや小さいモデルで十分な精度が出る。最終的な文章生成だけ賢いモデルに回す。

どこを下げられるかは、実際に両方で出力を比べて決める。勘で下げると品質が落ちた理由が分からなくなる。

4〜6

アプリ側のキャッシュは、同じ質問が繰り返されるFAQ的な用途で効く。Helicone のようなゲートウェイを使うと実装せずに済む。バッチAPIは即時性が要らない処理で半額程度になる提供元がある。出力の上限トークン数は、長文が不要な処理で設定しておくと暴走を防げる。

7. モデルを替える前に測る

全面的に安いモデルへ替えるのは最後である。替える前に、自分のタスクでの品質差を測る評価セットを作る。20〜30件の代表的な入力と期待される出力を用意して、両方のモデルで比べる。

この評価セットは一度作れば資産になる。モデルが更新されるたびに回せば、乗り換えの判断が勘ではなくなる。

よくある質問

Q. どこから手を付けるべきですか。

A. まず何にいくらかかっているかを測ってください。観測ツールで用途別のトークン数を出すと、たいてい1つの処理が費用の大半を占めています。そこだけ直せば済むことが多いです。

Q. 安いモデルで品質は落ちませんか。

A. タスクによります。分類や抽出では差が出ないことが多く、長文の生成では差が出ます。評価セットを作って測ってください。