大規模言語モデルの経済性に関する36万ドルの問い

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
本記事の目的は、大規模言語モデル(LLM)の料金体系がどのように機能するかを読者に伝えることです。これは、LLMを商用利用している複数の企業との会話がきっかけとなっています。これらの会話を通じて、LLMの経済性がしばしば誤解されており、最適化の余地が非常に大きいことに気づきました。
同じタスクを行うのに、 あるモデルでは3,500ドル、別のモデルでは1,260,000ドルかかる可能性があることをご存知ですか?これはパフォーマンスの違いという代償を伴いますが、コストとパフォーマンスのトレードオフについて考える余地が大きく残されています。そのタスクは、より安価なものを使用できるようなものでしょうか?
私たちは、企業が大規模言語モデルへの支出を繰り返し過大評価したり過小評価したりしているのを見てきました。そこで、ここでは人気のある大規模言語モデルの運用コストを理解し、その料金体系がどのように機能するかを把握したいと思います。
ℹ️
このブログの目的は、読者にLLMやその性能について教えることではありません。これは、LLMの料金体系の理解に焦点を当てた、数学的な内容のブログです。簡潔にするため、これらのモデル間の性能比較は行いません。
Wikipediaの要約
料金分析のためのサンプル
LLMの料金体系がどのように機能するかを理解するために、私たちは同じタスク、つまりWikipediaを半分のサイズに要約する際に発生するコストを比較します。
タスクの規模詳細
計算を簡素化し、分かりやすくするために、いくつかの近似値を使用します。
Wikipediaコーパスの規模
- 合計約600万記事
- 1記事あたり約750語
- 記事あたり約1000トークン
❓
トークン は、単語の先頭や末尾に厳密に依存しない単語のサブパーツです。OpenAI APIが入力データを処理する前にトークンに分割する単位です。トークンには、末尾のスペースやサブワードも含まれることがあります。
要約された出力の想定サイズ
このタスクでは、簡略化のため、各記事が元のサイズの半分に圧縮されると仮定します。したがって、期待される出力は以下のようになります。
- 約600万記事
- 要約された記事あたり約375語
- 記事あたり約500トークン

コストの理解
このタスクで異なるモデルを使用した場合のコスト比較
OpenAI/サードパーティAPIにおける料金設定の要因
OpenAIやその他のサードパーティAPIは通常、APIを使用して推論を行う場合、2つの要因に基づいて課金します。
入力コスト
このコストは、APIにコンテキスト/プロンプト/指示として渡されるトークン数(上記で説明)によって異なります。
出力コスト
これは、APIが応答として返すトークン数に基づいたコストです。
要約のようなタスクでは、要約するドキュメント全体または抜粋をモデルに渡す必要があるため、プロンプトの一部となるトークン数が重要になり、それが入力コストにつながります。
自己ホスト型モデルで発生するコストの根拠
セルフホスト型モデルの場合、ユーザーはモデルを実行するために必要なマシンを管理・プロビジョニングする必要があります。これらのリソースの管理コストも含まれるかもしれませんが、料金はマシンの稼働コスト(独自のオンプレミス・クラスターがない限り、通常はクラウドプロバイダーが請求する料金)に基づいているため、比較的理解しやすいです。
マシンのコスト
モデルの実行・ホストに必要なマシンをプロビジョニングするコスト。これらの大規模モデルのほとんどは、ノートパソコンや単一のローカルデバイスで実行できるよりも大きいため、クラウドプロバイダーを利用するのが最も一般的です。
クラウドプロバイダーはこれらのインスタンスを提供しますが、これらのモデルはGPUを必要とするため、ユーザーはGPUの可用性に関する問題に直面する可能性があります。
スポットインスタンス
クラウドプロバイダーは、オンデマンドインスタンスよりも40〜90%安価なコストで余剰キャパシティを提供します。
異なるモデルのコスト比較
GPT-4 - 8Kコンテキスト長
単価
コスト計算式
コスト = トークン数(1000記事あたり) × 記事数(1000単位) × 単価(100万トークンあたり)
入力コスト
1K(トークン/記事) × 6,000K(記事) × $30(/百万トークン) = $180,000
出力コスト
0.5K(トークン/記事) × 6,000K(記事) × $60(/百万トークン) = $180,000
合計コスト
入力コスト + 出力コスト
= $360,000
GPT 4 - 32K コンテキスト長
単位コスト
入力コスト(100万トークンあたり)出力コスト(100万トークンあたり)$60$120
コスト計算式
コスト = トークン数(1000記事あたり) X 記事数(1000単位) X 単位コスト(100万トークンあたり)
入力コスト
1K(トークン/記事) X 6,000K(記事) X $60(100万トークンあたり) = $360,000
出力コスト
0.5 K(トークン/記事) X 6,000K(記事) X $120(100万トークンあたり) = $360,000
合計コスト
入力コスト + 出力コスト
= $720,000
Anthropic Claude V1
単価
費用計算式
費用 = トークン数 (記事1,000件あたり) X 記事数 (1,000件単位) X 単価 (トークン100万件あたり)
入力費用
1K (トークン/記事) X 6,000K (記事) X $11 (トークン100万件あたり) = $66,000
出力費用
0.5K (トークン/記事) X 6,000K (記事) X $60 (トークン100万件あたり) = $96,000
合計費用
入力費用 + 出力費用
= $162,000
InstructGPT - DaVinci
単価
費用計算式
費用 = トークン数 (記事1,000件あたり) X 記事数 (1,000件単位) X 単価 (トークン100万件あたり)
入力費用
1K (トークン/記事) X 6,000K (記事) X $20 (トークン100万件あたり) = $120,000
出力コスト
0.5 K (トークン/記事) X 6,000K (記事) X $20 (/百万トークン) = $60,000
合計コスト
入力コスト + 出力コスト
= $180,000
Curie
単位コスト
コスト計算式
コスト = トークン数 (1000記事あたり) X 記事数 (1000単位) X 単位コスト (100万トークンあたり)
入力コスト
1K (トークン/記事) X 6,000K (記事) X $2 (/百万トークン) = $12,000
出力コスト
0.5 K (トークン/記事) X 6,000K (記事) X $60 (/百万トークン) = $6,000
合計コスト
入力コスト + 出力コスト
= $18,000
セルフホスト型7Bモデル
単価
マシン稼働コスト (スポットA100-80Gbの場合の1時間あたり)$10
コスト計算式
コスト = トークン数 (1000記事あたり) × 記事数 (1000単位) × 単価 (100万トークンあたり)
入力コスト
1K (トークン/記事) × 6,000K (記事) × $30 (100万トークンあたり) = $180,000
出力コスト
0.5K (トークン/記事) × 6,000K (記事) × $60 (100万トークンあたり) = $180,000
合計コスト
入力コスト + 出力コスト
= $360,000
ファインチューニングモデル
企業のほとんどのユースケースでは、自社のデータや特定のタスクに特化したモデルのファインチューニングが求められます。複数の企業が、ファインチューニングされたオープンソースモデルが、特定のタスクにおいてOpenAIのようなサードパーティAPIと同等か、場合によってはそれ以上の性能を発揮すると報告しています。
ファインチューニング済みDaVinci

合計コスト
入力コスト + 出力コスト
= $1,260,000
ファインチューニング済みCurie

合計コスト
入力コスト + 出力コスト
= $126,000
セルフホスト型、ファインチューニング済み、7Bモデル

合計コスト
入力コスト + 出力コスト
= $126,000
全体をまとめると
価格から注目すべき点:
- ユースケースに合わせてファインチューニングする場合、DaVinciモデルとCurieモデルは約7倍高価になります。
- コンテキストウィンドウの増加に伴い、コストは約2倍に増加します。
- モデルのパラメータ数が増加するにつれて、モデルの利用費用も増加します。
ファインチューニングがパフォーマンスに与える影響
モデルのファインチューニングがパフォーマンスに与える影響を分析するため、以下のベンチマークを使用します。興味深いことに、
- パラメータ数の少ないモデルでも、特定のユースケース向けにファインチューニングされた場合、より大規模なモデルよりも優れた性能を発揮することがあります。
- コストと性能の適切なトレードオフが確立されれば、性能を大きく損なうことなく大幅なコスト削減が可能になります。
タスク タイプ最適な6B/7B OOTBモデル Few-shotMoveLM 7B Zero-shotGPT-3.5 Turbo Zero-shotGPT-3.5 Turbo Few-shotGPT-4 Zero-shotGPT-4 Few-shot関連性 - 内部データセット0.330.930.840.840.920.95抽出 - クエリに対する構造化出力0.380.980.220.720.380.73推論 - カスタムトリガー0.620.930.870.880.90.88分類 - ユーザーのクエリのドメイン0.210.790.60.730.70.76抽出 - エンティティタイピングからの構造化出力0.830.870.90.890.890.89
私たちの取り組み
TrueFoundryは、LLMの未来は同じアプリケーション内でのオープンソースLLMと商用LLMの共存にあると信じています!
私たちは、簡単なタスクは軽量なオープンソースLLMが処理し、ウェブ検索やAPI呼び出しなど、クローズドソースの商用LLMのみが提供する独自の機能を必要とする複雑なタスクは、それらに任せられるようなアプリケーションのあり方を信じています。
OpenAIをご利用の場合
OpenAI APIに送信されるトークン数の削減を支援します。この取り組みを始めた理由は以下の通りです。
- コストの半分以上がコンテキスト/プロンプトトークンの処理に費やされていることに気づきました。
- すべての単語が必要なわけではありません。LLMは不完全な文でもうまく処理できます。
そこで TrueFoundry は、圧縮APIを構築しており、 OpenAIのコストを約30%削減します。

オープンソースLLMをご利用の場合
以下のサービスを通じて、お客様自身のインフラストラクチャでこれらのモデルを簡単に実行できるようにします。
- モデルカタログ: 推論とファインチューニングに最適化されたオープンソースLLM。
- ドロップインAPI: これらは、お客様のアプリケーションで既に実行されているHuggingFaceおよびOpenAIのAPIと直接置き換えることができます。
- コスト最適化: クラウドクレジットや予算を活用し、K8s上でクラウドを横断して。

TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)


.png)

.png)














