LLM

LLM API をどう選ぶか

大規模言語モデルの API は、単体の性能比較で選ぶと後悔しやすい。ベンチマークの数値は日々塗り替わるうえ、実際のプロダクトでは応答品質以外の要因——レート制限、コンテキスト長、料金構造、モデルの提供終了サイクル——が運用の成否を決めるからだ。

最初に決めるべきは「何をさせるか」

同じ LLM でも、得意な領域は分かれる。長文の資料を読ませて要約させたいのか、コードを書かせたいのか、大量の短いテキストを分類させたいのか。この用途が決まらないまま比較表を眺めても、判断軸が定まらない。

• 長文処理が中心 — 扱えるコンテキスト長と、長い入力を送り続けたときのコスト構造（キャッシュの仕組みがあるか）を見る
• コード生成が中心 — 実際に自分のコードベースで試すのが唯一確実な評価方法になる
• 大量の定型処理 — 単価と応答速度が効く。高性能モデルより軽量モデルのほうが総合的に有利なことが多い
• マルチモーダル — 画像・音声・動画を扱えるかで候補が一気に絞られる

料金は「入力と出力で別レート」が基本

多くのサービスで入力トークンと出力トークンの単価は異なり、出力側が数倍高い。長い回答を大量に生成する用途ではコストが跳ねやすく、逆に長い資料を読ませて短く答えさせる用途なら見た目の入力量ほどコストは膨らまない。単価の数字だけでなく、自分のワークロードがどちらに寄るかで試算する必要がある。

単一ベンダー依存のリスク

LLM を機能の中核に据えるほど、その提供元の障害がサービス停止に直結する。応答が得られなかったときに何を返すかを設計に入れておくかどうかで、障害時の被害が変わる。複数ベンダーを同じインターフェースで扱えるゲートウェイを挟む構成も、この観点では検討に値する。