Simon Willison の記事を朝の通勤中に読んで、思わずスマホを二度見した。
Gemini 3.5 Flash が GA になった。-preview が取れたのはいいとして、価格が前世代の 3 Flash Preview の 3 倍、3.1 Flash-Lite に至っては 6 倍。input $1.50/million、output $9/million というのは、もはや「安い Flash」というポジションではない。Gemini 3.1 Pro の $2/$12 と並べると、かなり近い水準まで上がってきてる。
いま自分のサービスでは gemini-3.1-flash-lite をメインに使っていて、ユーザーの入力をリライトしてからベクトル検索に投げる処理を 1 日数万回走らせてる。コスト感覚がゼロ起点で作った設計だったから、Artificial Analysis のベンチマーク実測値を見たときに少し息が止まった。3.5 Flash (high) のベンチ実行コストが $1,551.60 で、3.1 Flash-Lite Preview の $93.60 の約 16 倍。これはさすがにえぐい。
正直、3.5 Flash に今すぐ全部移行する理由はない。自分のユースケース — 短いリライトと分類タスク — は推論精度よりスループットとコストが命だから。ただ、モデル ID を定数で埋め込んでる箇所が複数あって、これは今すぐ直したい。
とりあえず環境変数に切り出して、モデル切り替えを設定ファイル 1 行で完結させる構成にする。これをやっておかないと、次に価格が動いたとき (そして絶対また動く) に対応コストがかかりすぎる。
fallback を 3.5 Flash にしておいて、flash-lite がコケたときだけ切り替わる設計にしようとしてる。精度が必要なタスクだけ model を明示的に上書きする。こういう柔軟性を最初から持たせておくべきだった、という反省。
もうひとつ気になったのが、Interactions API (現在 beta) の話。記事では「OpenAI の Responses API が導入したパターン、とくにサーバーサイドの履歴管理」と評されてた。自分のチームでは今、会話履歴を Redis に突っ込んで自前でコンテキスト管理してるんだけど、これが地味に辛い。ユーザーセッションをまたぐと履歴の整合性がずれるバグを先月も踏んだばかりで、彼女に愚痴ったら「それ毎月聞いてる」と言われた。
サーバーサイドで履歴を持ってもらえるなら、そのロジックをごっそり消せる可能性がある。beta が外れたらすぐ検証したいやつ。
あと地味に笑ったのが、ペリカンの SVG を API に生成させたら 14,403 output tokens 使って約 13 セント飛んだという話。output コストは input の 6 倍なので、長い出力を大量に投げるタスクは本当に注意が必要で、これは自分のリライト処理でも意識してる部分。出力が長くなりがちなプロンプトは early stop の instruction を明示的に入れるようにしてから、output token が 3 割くらい減った。
knowledge cutoff が January 2025 というのも頭に入れておきたい。最新情報を前提にした処理を書くときはそこを前提にしたプロンプト設計が必要になる。このへんのモデルスペックを一覧管理する社内ドキュメントを作ろうとして放置してたので、週末にでも Notion に叩き込む。
LLM のコスト設計は「今のモデルで固定」じゃなくて「変動前提で逃げ道を作っておく」のが正解だと、今回改めて思った。次のリリースサイクルで自分のリポジトリのモデル設定を全部 env に逃がす PR を出す。
Gemini 3.5 Flash が GA になった。-preview が取れたのはいいとして、価格が前世代の 3 Flash Preview の 3 倍、3.1 Flash-Lite に至っては 6 倍。input $1.50/million、output $9/million というのは、もはや「安い Flash」というポジションではない。Gemini 3.1 Pro の $2/$12 と並べると、かなり近い水準まで上がってきてる。
いま自分のサービスでは gemini-3.1-flash-lite をメインに使っていて、ユーザーの入力をリライトしてからベクトル検索に投げる処理を 1 日数万回走らせてる。コスト感覚がゼロ起点で作った設計だったから、Artificial Analysis のベンチマーク実測値を見たときに少し息が止まった。3.5 Flash (high) のベンチ実行コストが $1,551.60 で、3.1 Flash-Lite Preview の $93.60 の約 16 倍。これはさすがにえぐい。
じゃあ自分のコードはどこを直すのか
正直、3.5 Flash に今すぐ全部移行する理由はない。自分のユースケース — 短いリライトと分類タスク — は推論精度よりスループットとコストが命だから。ただ、モデル ID を定数で埋め込んでる箇所が複数あって、これは今すぐ直したい。
# 今の悲しいコード
MODEL_ID="gemini-1.5-flash"
# ↑ ハードコードで 3 箇所くらい散らばってるとりあえず環境変数に切り出して、モデル切り替えを設定ファイル 1 行で完結させる構成にする。これをやっておかないと、次に価格が動いたとき (そして絶対また動く) に対応コストがかかりすぎる。
# .env.production
GEMINI_MODEL=gemini-3.1-flash-lite
GEMINI_MODEL_FALLBACK=gemini-3.5-flashfallback を 3.5 Flash にしておいて、flash-lite がコケたときだけ切り替わる設計にしようとしてる。精度が必要なタスクだけ model を明示的に上書きする。こういう柔軟性を最初から持たせておくべきだった、という反省。
Interactions API は触っておきたい
もうひとつ気になったのが、Interactions API (現在 beta) の話。記事では「OpenAI の Responses API が導入したパターン、とくにサーバーサイドの履歴管理」と評されてた。自分のチームでは今、会話履歴を Redis に突っ込んで自前でコンテキスト管理してるんだけど、これが地味に辛い。ユーザーセッションをまたぐと履歴の整合性がずれるバグを先月も踏んだばかりで、彼女に愚痴ったら「それ毎月聞いてる」と言われた。
サーバーサイドで履歴を持ってもらえるなら、そのロジックをごっそり消せる可能性がある。beta が外れたらすぐ検証したいやつ。
あと地味に笑ったのが、ペリカンの SVG を API に生成させたら 14,403 output tokens 使って約 13 セント飛んだという話。output コストは input の 6 倍なので、長い出力を大量に投げるタスクは本当に注意が必要で、これは自分のリライト処理でも意識してる部分。出力が長くなりがちなプロンプトは early stop の instruction を明示的に入れるようにしてから、output token が 3 割くらい減った。
knowledge cutoff が January 2025 というのも頭に入れておきたい。最新情報を前提にした処理を書くときはそこを前提にしたプロンプト設計が必要になる。このへんのモデルスペックを一覧管理する社内ドキュメントを作ろうとして放置してたので、週末にでも Notion に叩き込む。
LLM のコスト設計は「今のモデルで固定」じゃなくて「変動前提で逃げ道を作っておく」のが正解だと、今回改めて思った。次のリリースサイクルで自分のリポジトリのモデル設定を全部 env に逃がす PR を出す。