第9章 — パフォーマンス、スケール、コスト

LLM Primer I: How Generative AI Works を章ごとに紹介するシリーズ、第9回です。前回はアプリケーションパターンを巡りました。今日は、それを「実際に動かす」コストの話 — LLM 機能が世に出るか、それともパイロットで静かに息絶えるかを決める、運用の現実 — を扱います。

「大きいほど良い」は、おおむね正しく、おおむね誤解を招く

「モデルが大きいほど能力も高い」という直感は、おおむね正しいし、おおむね危ない。大きいモデルは、平均すれば、ほとんどのベンチマークでより良い結果を出します。ただし、モデルが大きくなるほどリターンは細っていく。パラメータが倍のモデルが、倍良くなることはまずありません。たいていは「気持ち良い」程度の差で、運用コストはその何倍にも膨れあがります。

多くの実アプリケーションでは、しっかりしたプロンプティング、しっかりした検索、しっかりした評価を備えた「小さめのモデル」が、雑なパイプラインに放り込まれた「大きめのモデル」を上回ります。これが第9章のいちばん大事な実務的洞察で、各フロンティア社のマーケティングのトーンに逆らうぶん、本書は意識して時間をかけて擁護します。

レイテンシとスループットは、互いに引っ張り合う

LLM 運用では、2つの指標がほぼ全てです。レイテンシはリクエストから最初の応答までの時間、スループットはシステムが1秒あたりに処理できるリクエスト数。

この2つは、構造的にトレードオフの関係にあります。スループットを上げたいなら、リクエストをまとめて GPU に並列に流すバッチ化が効きますが、当然レイテンシは犠牲になる。レイテンシを下げたいなら、到着したリクエストをすぐに処理する方向に倒すしかなく、その分スループットが落ちる。片方を取れば、もう片方を譲ることになります。

実プロダクトの多くは、「継続バッチング」と呼ばれる手法 — 飛行中のバッチに新規リクエストを継ぎ足していくやり方 — でその中間に着地します。ストリーミング生成(出力全体を待たず、生成された端から返す)も体感レイテンシには効きますが、実際の生成時間はそこまで変わりません。本書では、どんな製品にどんな設計判断がふさわしいか、ひとつずつ整理してまいります。

本当のコスト方程式

LLM の運用は、ふつうのソフトウェア運用とは別物です。そして、その違いを高い授業料で学ぶのが、AI 導入プロジェクトでよくある光景でもあります。従来のソフトウェアでは、いったん作ってしまえば、ユーザーが増えてもほぼ無料。サーバーは1人で回ろうと1,000人で回ろうと動いてくれます。ところがLLMは、リクエストの一つひとつが、現実の計算コストを発生させる。コストは利用量に対して、ほぼ線形に上がっていきます。

主要なコストドライバは、列挙が簡単です。入力が長いほど高くなる(Attention の計算が入力長で増える)。出力が長いほど高くなる(出力トークンごとに forward pass が増える)。モデルが大きいほど高くなる(パラメータが多いほどトークンあたりの FLOPs が増える)。推論モデルはさらに高くなる(最終答えに至るまでに、膨大な中間トークンを生成する)。そしてこれらは、足し算ではなく掛け算で効いてきます。

本書では、現実的なシナリオ — 小規模チャットボット、中位の RAG、推論モデル付きのエージェント型 — を例にとって、月額の請求額がどう動くかを表でお示しします。具体的な数字は時間とともに動きますが、曲線の形そのものは、長く生き残る情報かと思います。

量子化、やさしく

コスト削減のための工学的トリックの中でも、特に効くのが量子化です。モデルのパラメータは通常、16 bit や 32 bit の浮動小数で持ちますが、それを 8 bit、ときには 4 bit にまで落とし、スケール係数を慎重に選ぶことで情報の損失を抑えるのが量子化の発想です。

効果は劇的です。メモリ使用量は大きく減り、より小さなハードウェアに収まり、走るのも速くなる(ボトルネックが計算速度よりもメモリ帯域にあるケースが多いので、ここがダイレクトに効きます)。品質の低下も、丁寧に設計すれば小さく、ベンチマーク上で数ポイント、実用上は気づかない程度のことも珍しくありません。

関連手法 — Pruning、Distillation、Sparsity — も同じ方向に効きます。とくに Distillation は、大きなモデルの振る舞いを模倣する小さなモデルを得るための定番。本書は各手法を、適した場面と組み合わせて整理してまいります。

エッジ展開・オンデバイス展開

本番のLLMの多くはクラウドのデータセンターで走っていますが、それが許されないアプリケーションもあります。リアルタイム音声アシスタント、厳しいプライバシー要件を抱えたアプリケーション、ネットワーク接続なしでも動かないと困るデバイス — こういった場面では、モデルをユーザーのハード上で直接動かすことに大きな利点が出てきます。

エッジ展開は独立した工学分野です。メモリは限られ、電力は貴重で、利用できる計算量もデータセンターとは桁違いに少ない。本書は、強い圧縮、慎重なモデル選択、ハイブリッドな設計(日常タスクは小さなローカルモデル、難しいケースはクラウドへエスカレーション)を組み合わせて、ここをどう成立させるかを扱ってまいります。

第9章を通して、得られるもの

第9章を読み終えるころには、提案されているLLMアプリケーションのコストとパフォーマンスを、構築前の段階でモデル化できるようになっているはずです。どの設計判断がコストに効き、どれがレイテンシに効くか、どのトレードオフが交渉可能で、どれが本質的に動かせないか。ベンダーの料金ページを開いて、いま自分が何にいくら払っているのかも分かるようになるかと思います。

そして、ここから自然と次の問いが立ち上がります。スケールで動かせるようになったとき、本当にそれを動かすべきか — どう判断すればいいのか。

次回 — 第10章: 安全性、倫理、信頼。 ハルシネーション、バイアス、プロンプトの安全性、説明可能性、そしてLLMアプリケーションを「責任ある製品」へと押し上げるためのガバナンスフレームワーク。本番でリスクを取りに行く現場が、実際に使っているコントロール群を扱ってまいります。