【Part 4】DeepSeek（ディープシーク）の価格比較：競合の OpenAIやAnthropic等と比較すると価格は魅力的？

※「【Part 3】DeepSeek（ディープシーク）とChatGPTの違いとは？DeepSeekの強み＆競争優位性を徹底解説！」の続き

前章では、「DeepSeek（ディープシーク）とChatGPTの違いとは？」という疑問に答えるべく、DeepSeekの強みと競争優位性を詳しく解説しております。

本稿の内容への理解をより深めるために、是非、インベストリンゴのプラットフォーム上にて、前章も併せてご覧ください。

DeepSeek（ディープシーク）の推論（Inference）に関して

私たちは、DeepSeek（ディープシーク）の中で最も過小評価されている革新の一つが、その推論クラスター設計であると考えています。モデル開発に関する研究には大きな注目が集まっていますが、DeepSeekはモデルの提供方法にも変革をもたらしています。同社の推論クラスターアーキテクチャは、AIチップにおける制約がメモリ依存から計算依存へと移行する可能性を示唆しており、CUDAだけでは対応できない、より洗練された調整レイヤーの必要性を浮き彫りにしています。

現在の推論インフラは主にシングルカードまたはシングルノードのパラダイムに基づいており、推論用データセンターと学習用データセンターでは、根本的に異なる制約のもとで運用されています。現時点では、AIチップの性能は主に計算能力ではなく、メモリ容量によって制限されています。例えば、Llama 3 70BモデルをH100 GPUにロードすると、モデル本体とKVキャッシュ（チャット履歴）が利用可能なメモリをすべて使い切ってしまいますが、それでも計算ユニットの使用率はおよそ50％にとどまります。学習作業においては、複数のGPU間でデータを移動させる必要があり、それがサーバー間やラック間にまたがる場合はさらに顕著で、利用率が約30％まで低下することもあります。これにより、レイテンシが増加し、効率が低下します。

モデルの推論を行う際には、基本的にモデル全体を一つのGPU、あるいは高速なNVLinkで接続された8つのGPUを備えた一つのサーバーノードにロードして動作させるのが一般的です。通常、それ以上のGPUを別のサーバーにまたがって拡張することは望ましくありません。というのも、サーバー間でのGPU間通信は、レイテンシが高く、帯域幅も低いため、通信がより複雑になるからです。

サーバーノード内では、複数のGPUがNVlink（H100では900GB/s）によって接続されていますが、ノード間通信（RDMA）では、各GPUがCX7（InfiniBand）またはBlueField 3（Ethernet RoCE）のネットワークインターフェースカードに、400Gb/sで接続されています。エヌビディアのマーケティングに惑わされてはいけません。NVlinkの帯域幅の数値は、業界標準である「単方向帯域幅」ではなく、「双方向帯域幅」として示されています。つまり、数字を大きく見せるために、エヌビディアはHopperで採用されているNVlink 4.0の帯域幅を900GB/s（双方向）として宣伝しています。ですが、同じ基準で比較する場合、実際の単方向帯域幅は450GB/sです。

一方で、RDMAやノード間通信の帯域幅については、表示されている数値は単方向のものですが、単位は「400Gb/s」であって「400GB/s」ではありません。ビット（bit）とバイト（byte）の換算により、RDMAの実効帯域幅はわずか50GB/sに過ぎません（1バイト＝8ビットのため）。これはNVlinkの単方向帯域幅の9分の1に相当します。このため、複数のサーバーノードをまたいで推論処理を行うには、NVlinkとRDMA間の帯域幅の差に対処しなければなりません。最適化がなされていない場合（現時点でそのような即時に使えるソリューションは存在しません）、例えば2台のサーバーにそれぞれ8枚のH200 GPUを搭載しても、単一ノードに8枚のH200を搭載した場合と比べて、スループットはおよそ9分の1にまで低下してしまいます。

OpenAIは当初、GPT-4のような大規模モデルをホストするために、1サーバーあたり16枚のGPUを使用する実験を行っていました。しかし、GPT-4 TurboやGPT-4oでは、パラメータ数やモデルサイズを削減し、8ビット量子化を進めることで、1サーバーあたりのGPU必要数を減らし、ネットワークの負荷も軽減しました。さらに、エヌビディア（NVDA）はBlackwell世代において、1サーバーあたりのGPU上限を72枚に引き上げ、NVSwitchを活用して1つのラック内で72枚のB200 GPUを相互接続することで、スケーラビリティに関する制約に対応しています。

現在、GPUはメモリによって制約を受けており、これはつまり、最先端のモデルをホスティングする際に、GPUの計算能力が足りなくなる前にメモリが先に不足してしまうということです。推論がユーザーごとに専用のモデルやGPUを割り当てる方式ではなく、サービスとして提供される場合、バッチ処理を活用することでGPUの利用率を高めることができます。

バッチ処理とは、複数のユーザーからのリクエストを一つにまとめて処理する手法で、すでにメモリ上に読み込まれている同一のモデルの重みを使ってGPUがそれらを同時に処理できるようにするものです。理論的には、バッチ処理を適切に行えば、計算資源の利用率を100％まで引き上げることが可能です。

しかし、最先端モデルの場合、制約となるのは計算能力ではなくメモリです。というのも、モデルの重みがGPUメモリの大半を占めてしまうため、バッチサイズを思うように拡大できないのです。このメモリによるボトルネックは、最先端モデルの推論において深刻な問題となっています。

✅ メモリ容量の制限により、使用可能なKVキャッシュが限られます

✅ KVキャッシュが限られることで、同時に対応できるユーザー数、もしくは入力＋出力トークンの長さを制限せざるを得ません

✅ KVキャッシュの制約により、文脈ウィンドウ（コンテキストウィンドウ）の長さも制限されます

たとえばLlama 3 8Bのような小型モデルであれば、スループットを向上させるために必ずしもバッチ処理は必要ありません。しかし、Llama 3 70Bや405Bのような大規模モデルでは、同時実行ユーザー数を増やすことでスループットを線形に向上させることができます。

例えば、H100（80GB）は、Llama 3 70BをFP8で動かす場合、入力・出力トークンをそれぞれ128に設定したうえで、1ユーザーであれば毎秒4,020トークンを処理できます。これを同時に8ユーザーに増やせば、スループットは毎秒15,355トークンとなり、ほぼ8倍に達します。

Llama 3 405Bのような最先端モデルでは、スループットを向上させるためにバッチ処理が不可欠ですが、同時にKVキャッシュの管理も非常に慎重に行う必要があります。最先端モデルは、その重みを格納するためだけでも複数のGPUを必要とします。例えば、H100（80GB）1枚では70Bを超えるモデルのホスティングは不可能であり、モデルを8枚のH100（合計640GBのメモリ）または8枚のH200（合計1,128GBのメモリ）に分散させる必要があります。

Llama 3 405B FP8を例に挙げて説明します。

✅ モデルの重み：405GB（固定で、ほとんどのGPUメモリを占有します）

✅ 残りのメモリ容量：640GB - 405GB = 235GB

✅ 1トークンあたりのKVキャッシュ：FP16で約2MB

この条件下では、入力＋出力トークンの合計が117,500トークンを超えることはできません。つまり、総ユーザー数 × 各ユーザーのトークン数の合計が117,500トークンを上回ってはならないということです。

たとえば、入力だけで128,000トークンある場合、出力トークンが生成される前に、KVキャッシュのメモリが枯渇してしまいます。DeepSeekの観測によると、平均的な出力トークンの長さは4,989トークンです。仮にシーケンス長を4,224トークン（入力128トークン／出力4,096トークン）とすると、ノードが対応できる最大のバッチサイズは23.5、つまり同時に処理可能なユーザー数は約23人となります。この場合、KVキャッシュの使用量は200GBをわずかに超える程度です。

一般的に、計算資源の利用率を高めるには、8人以上の同時ユーザーが必要です。しかし、KVキャッシュの制約があるため、たとえば2人のユーザーがそれぞれ55,000トークンを消費する場合、KVキャッシュが不足し、それ以上スループットを向上させることができず、計算資源の利用率も向上しません。

このため、多くのAPIプロバイダーは8,000トークンのコンテキストウィンドウしかサポートしておらず、128,000トークンのような長いコンテキストウィンドウに対応するには、専用GPUを少数または1ユーザーのみに割り当てる必要があるため、価格は数倍に跳ね上がります。

8枚のH100 GPUを搭載したノードには合計640GBのメモリがあります。このうち、バッチサイズ23.5で使用されるKVキャッシュのメモリは約210GBです（23.5 × 4,224 × 2 × 10⁶ = 約210GB）。つまり、残りの約25GBは活性化処理やその他の補助的な処理に使用されることになります。この構成により、利用可能なメモリはほぼ最大限活用されますが、これ以上スケーリングを行うと、計算資源を使い切る前にメモリが限界に達してしまうリスクがあります。

実際にエヌビディアの公式ドキュメントを確認すると、Llama 3 405Bにおける推論ベンチマークの速度については、8枚のH200を使用した場合のみが掲載されており、スループットも8人の同時ユーザーでの結果しか記載されていません。これは、1人の同時ユーザーだけで動作させるのはコスト効率が悪いためです。Llama 3 405B FP8を8枚のH200で推論する場合、入力トークンと出力トークンの数によってスループットは大きく変動します。

下記の表に見られるように、エヌビディアはLlama 3 8Bに関しては単一ユーザーでのスループット、Llama 3 405Bについては8人の同時ユーザーでのスループットのみを提供しています。405Bでは、入力トークン数が1,000を超えるとスループットが急激に低下します。これは非常に低い閾値であり、エージェントやCoT（Chain of Thought）のようなユースケースでは、システムプロンプトや思考トークンだけでも簡単に4,000トークン以上に達してしまいます。

また、8Bのような小規模モデルでも、入力トークンを5,000まで増やすとスループットは急激に劣化します。したがって、高いスループットと長いコンテキストウィンドウを両立させるためには、1つのGPUに読み込む重みの量を減らし、バッチ処理を活用して十分に使い切れていない計算資源のスループットを向上させる必要があります。

（出所：TensorRT-LLM/docs/source/performance/perf-overview.md at main · NVIDIA/TensorRT-LLM）

DeepSeek V3は推論時にアクティブなパラメータ数を370億（MTP分としてさらに140億）に削減しているものの、モデル全体のサイズは671GBに達します。これは、80GBのH100を8枚使用した構成の容量を超えており、効率的に運用するには96GBのH100やH200のような大容量メモリを搭載したGPUが必要です。そうでない場合は、推論スケーリングのために追加の80GB H100を借りる必要があり、メモリ制約のために余剰な計算資源が遊休状態になってしまいます。

こうした非効率を解消するため、DeepSeekは「4+40ノード構成」による新しい推論アーキテクチャを導入しました。この構成では、入力トークンは最初に「プレフィル」ステージへ送られ、初期計算が行われたのち、「デコード」ステージに進み、出力生成が行われます。「4+40ノード構成」とは、この役割分担を反映したものです。4つのプレフィルノードは、ニューラルネットワークの初期レイヤーを担当し、入力トークンを高速に並列処理します。その後、モデルが問い合わせに最適な専門的「エキスパート」を判断し、そのリクエストを40のデコードノードのいずれかにルーティングして、トークン単位で応答を生成します。

このプレフィル／デコード（P/D）アーキテクチャは、推論の効率性にとって非常に重要です。プレフィル段階では入力を解析・文脈化する処理が行われ、これらは高度に並列化が可能なため、GPUコアの利用率を最大化できます。一方、デコード段階ではトークンを逐次生成する必要があり、各トークンは前のトークンに依存するため、GPUの演算コアとHBMメモリ間で頻繁に読み書きが発生し、GPUの計算能力を完全に活用するのが難しくなります。

この本質的な違いから、OpenAIやAnthropicのような先進的なAPIプロバイダーは、多くの場合、入力トークンよりも出力トークンの方に高い料金を設定しています。プレフィル処理は並列化によってコストを抑えることができますが、デコード処理は構造的に逐次かつメモリ負荷が大きいため、コストが高くなるからです。したがって、DeepSeekのように効率的な推論クラスター設計を持つプロバイダーは、性能を損なうことなく、より低価格で推論サービスを提供することが可能です。

さらに、プレフィルとデコードを分離することで、KVキャッシュの制約を受けにくくなり、より多くの入力トークンを処理できます。これは、出力トークンのKVキャッシュがデコード専用GPUに分離されて保存されるためです。

（出所：Zomi）

（補足ですが、DeepSeekが最近オープンソース化した「DeepEP」およびその後に公開された自社推論クラスターの統計情報によると、P/Dクラスタ構成は「Prefill EP32」と「Decode EP144」に変更されています。これは、おそらく1つのGPUに2つのエキスパートが割り当てられており、128枚のGPUで合計256のエキスパート、さらにロードバランス用として別の16枚のGPUに32の冗長エキスパートを配置している構成と考えられます）

以下に、このプロセスの簡単な説明を示します：

プレフィル（Prefilling）ステージ

プレフィルステージでは、初期の入力シーケンス（例：ユーザーからのクエリ）を処理し、デコード処理のための初期隠れ状態（hidden states）を生成します。このステージには、以下のステップが含まれます。

a. 入力埋め込みとアテンションの全結合層（Attention Dense Layer）

• テンソル並列処理（TP4）：入力シーケンスを複数のチャンクに分割し、それぞれを4つのGPUで4分割テンソル並列（TP4）によって処理します。これにより、各GPUへの計算負荷が軽減されます。

• シーケンス並列処理（SP）：シーケンスはさらに小さなセグメントに分割され、それぞれが独立して処理されることで、計算の並列化が実現されます。

• アテンション機構：アテンション層では、トークン間の依存関係を計算します。Multi-Head Latent Attention（MLA）アーキテクチャでは、キーとバリューを低ランクの潜在ベクトルに圧縮することで、メモリ使用量を削減し、計算速度を向上させています。

b. Mixture-of-Experts（MoE）レイヤー

• エキスパート並列処理（EP32）：各MoEレイヤーには256のエキスパートが存在し、そのうち32は冗長エキスパートとして32枚のGPUに分散配置されています。各GPUには8つの本来のエキスパートと1つの冗長エキスパートが搭載され、負荷分散が図られています。

• 冗長エキスパート：高負荷となるエキスパートは複製され、他のGPUにも冗長配置されます。これにより、計算負荷がGPU間で均等に分散されます。高負荷のエキスパートは、オンライン運用中に収集された統計データに基づいて検出され、一定の間隔（例：10分ごと）で調整が行われます。

• オール・トゥー・オール通信（All-to-All Communication）：トークンはノード間ではInfiniBand（IB）、ノード内ではNVLinkを使用してエキスパートへと分配されます。これにより、高速なデータ転送が実現されつつ、通信のオーバーヘッドは最小限に抑えられます。

c. マイクロバッチの並列処理

• マイクロバッチの重複実行（Micro-Batch Overlapping）：計算負荷が類似している2つのマイクロバッチを同時に処理します。一方のバッチがアテンションとMoEの計算を行っている間に、もう一方のバッチではトークンの分配および統合処理（dispatchおよびcombine）が行われるため、通信のオーバーヘッドを隠蔽できます。

デコード（Decoding）ステージ

デコードステージでは、出力シーケンス（例：モデルの応答）をトークンごとに順次生成します。このステージには以下の要素が含まれます。

a. トークンのルーティングとエキスパートの選定

• 共有エキスパート：共有エキスパートは「ルーティング対象のエキスパート」として扱われ、トークンルーティングの際には常に選択されるようになっています。各トークンは、共有エキスパートを含む9つのエキスパートを選択します。

• エキスパート並列処理（EP320）：合計256のエキスパートに加え、64の冗長エキスパートが320枚のGPUに分散配置されています。各GPUには1つのエキスパートのみが搭載されており、64枚のGPUは冗長エキスパートおよび共有エキスパートを担当します。このような細粒度の並列処理により、計算効率が向上します。

• 冗長エキスパート：計算負荷の高いエキスパートは複製されて冗長に配置され、GPU間で計算負荷が均等になるように調整されます。高負荷のエキスパートは、オンライン運用中に収集された統計データを基に検出され、一定間隔（例：10分ごと）で再配置が行われます。

DeepSeekのP/D（プレフィル／デコード）アーキテクチャは、推論処理をプレフィルとデコードに分割することで、GPUのアイドル時間を最小化し、計算資源の利用率を最大化しています。入力トークンを複数のGPUで並列に処理するプレフィルステージが計算負荷の大部分を担い、この段階で適切なエキスパートが特定され、最適なデコードノードにリクエストがルーティングされます。

この構造によって、デコード用の各GPUはモデル全体ではなく、1つのエキスパート（約26億パラメータ）のみを読み込めばよいため、重要な効率向上が実現されています。デコード処理は構造的に逐次的で並列化が難しいため、GPUごとのモデル重みを軽量化することで、メモリのボトルネックを防ぎつつ、計算資源の高効率な活用が可能になります。

さらに、MLAやMTPといったメモリ効率に優れた技術と組み合わせることで、トークンスループットは2倍に向上し、KVキャッシュの使用量も約6分の1に削減されます。これにより、DeepSeekは長文コンテキスト処理に必要なメモリを確保したまま、H800による推論速度を大幅に加速させることができます。その結果、DeepSeekでは128kのコンテキストウィンドウを追加料金なしで標準提供できる一方で、他のホスティング型APIではP/Dアーキテクチャを採用しておらず、入力＋出力トークンを1台のGPUノードのKVキャッシュ内に保存する必要があるため、8kのコンテキストウィンドウしか対応していません。

P/DとMoEはDeepSeek独自の技術というわけではありませんが、他社との違いは、これら2つのアーキテクチャを高度に組み合わせ、大規模ノード間での推論を最適化している点にあります。他社がスケールアップ型のネットワーク構成に依存している中、DeepSeekはプレフィルに基づくエキスパート選定と、デコードステージでのMoEスパース性を緊密に統合することで、メモリのオーバーヘッドを削減しつつ、計算効率を最大化しています。

このアプローチにより、DeepSeekはより高速なトークン生成、優れたGPU利用率、そしてコスト効率の高い推論を実現しており、他社の標準的なP/DやMoEの実装とは一線を画しています。

DeepSeek（ディープシーク）を含む推論価格の比較

以下の図は、DeepSeek V3を含む複数のモデルに対するAPI価格を示しています。DeepSeek V3は、複数のサードパーティプロバイダーを通じて提供されていますが、これらのプロバイダーの粗利益（GM）構成は公開されていません。DeepSeekによると、同社のAPI価格はプラスの粗利益を維持するように設定されていますが、OpenAIほど高い水準ではないとしています。一方、小規模なAPIプロバイダーの中には、ユーザー獲得を目的として、売上原価（COGS）を下回る価格設定を行い、実質的に使用料を補助する形で市場シェアを拡大しようとしているところもあります。

その中でも、TogetherAIの価格設定は、より高い粗利益を維持しながら長期的に安定した価格水準を示す指標となる可能性があります。TogetherAIは、最も安価な提供者として競争するのではなく、品質とブランドの確立を重視しており、それがCOGSと比べて明らかに高い価格設定に反映されています。

2025年2月8日以前、DeepSeekは入力トークンの価格を半額に、出力トークンの価格を4分の1に引き下げました。もし創業者が示唆するように粗利益率が50～75％の範囲にあるのであれば、DeepSeekはCOGSを下回る価格設定をしておらず、資本的支出（CAPEX）や営業費用（OPEX）を加味したうえで、適度な利益率を維持していることになります。一方で、Hyperbolicやネビウス・グループ（NBIS）のような小規模な新規参入企業は、ホスティング型モデル市場でのシェア拡大を目指して、赤字覚悟で運営している可能性があります。

さらに、エヌビディア（NVDA）、マイクロソフト（MSFT）、アマゾン（AMZN）、テンセント、ファーウェイといった企業も、自社のモデルガーデン内でDeepSeekのAPIを提供しています。ただし、これらの企業は価格を公表しておらず、ほとんどがAPIを無償で提供している状況です。これは、おそらく開発者を取り込み、インフラの最適化前に利用データを収集・調整することを目的とした戦略であると考えられます。

（出所：筆者作成）

DeepSeekは、入力プロンプトのキャッシュ機能を導入しており、これは2024年第4四半期時点でAnthropicのみが同様に実装しているコスト削減機能です。しかし、価格面ではDeepSeekの方がAnthropicよりも大幅に安価です。たとえば、Claude 3.5 Sonnetではキャッシュヒットした入力トークンが100万トークンあたり0.30ドルであるのに対し、DeepSeek-V3では同条件でわずか0.07ドル、オフピーク時には0.035ドルまで下がります（画像参照）。

DeepSeekとAnthropicのキャッシュ機構はいずれも、プレフィルステージで処理済みの入力トークンの繰り返し部分 ― いわゆる「プレフィックス」 ― を保存する仕組みです。これらのプレフィックスが次回以降のクエリでも出現した場合、既に処理済みの結果を再利用することで、冗長な計算を省略することができます。特に、毎回同じようなプレフィックス（例：「あなたはチャットボットとして振る舞う必要があります。」）が繰り返されるエージェント系のユースケースでは、大きな効果を発揮します。

ただし、DeepSeekのキャッシュ機能は、Anthropicに比べてより自動化されています。Anthropicではユーザーがキャッシュを手動で有効化し、保存するプレフィックスを自ら選ぶ必要がありますが、DeepSeekでは頻繁に使用されるプレフィックスをシステムが自動的に特定・キャッシュするため、ユーザー側の操作なしにさらなるコスト削減が可能です。

オフピーク割引：毎日協定世界時（UTC）16:30〜翌0:30の時間帯に適用

（出所：DeepSeek）

このキャッシュ機構は、すでに低価格で提供されているDeepSeekのAPIにおいて、さらに大きなコスト削減の可能性を示しています。高度に調整されたAIエージェントでは、システムプロンプトが5,000トークンを超えることが一般的であり、対してユーザーの入力は1回あたり100トークン程度であることも珍しくありません。キャッシュがなければ、毎回のクエリで5,000トークン以上が消費されることになり、コストが不必要に膨らんでしまいます。

今後、コンテキストウィンドウが拡大し、ファインチューニングの代わりにRAG（Retrieval-Augmented Generation）ベースのアーキテクチャが主流になるにつれ、このプレフィックスキャッシュのコスト削減効果はさらに重要になると考えられます。DeepSeekによれば、入力トークンの約53％がキャッシュヒットしており、これによって実質的に入力トークンのコストは半分に削減されています。

推論効率の向上にとどまらず、DeepSeekのアーキテクチャ上の革新は、より広範なAIインフラの在り方にも影響を与える可能性があります。これは、モデルのホスティング戦略だけでなく、将来のAIチップの設計にまで波及する可能性を秘めています。DeepSeekの技術論文では、推論効率をさらに高めるための具体的なハードウェア最適化案が提示されており、これにチップメーカー（たとえばエヌビディアなど）が対応していくことを期待しています。

また、DeepSeekの創業者は、中国が既存の技術を追随するのではなく、独自にイノベーションを牽引する先進的なAIラボを確立する必要性を強調しています。これは、DeepSeekのアーキテクチャ的な洞察を取り入れられるAIチップメーカーが、エヌビディアに対して競争優位を築く可能性があることを示唆しています。このような戦略的重要性を踏まえれば、2025年1月下旬に、米国企業として最初にエヌビディアがDeepSeekのサポートを表明したことも不思議ではありません。

---

🚀お気に入りのアナリストをフォローして最新レポートをリアルタイムでGET🚀

コンヴェクィティ社はテクノロジー銘柄に関するレポートを執筆しており、プロフィール上にてフォローをしていただくと、最新のレポートがリリースされる度にリアルタイムでメール経由でお知らせを受け取ることができます。

さらに、その他のアナリストも詳細な分析レポートを日々執筆しており、インベストリンゴのプラットフォーム上では「毎月約100件、年間で1000件以上」のレポートを提供しております。

そのため、コンヴェクィティ社のテクノロジー銘柄に関する最新レポートに関心がございましたら、是非、フォローしていただければと思います！

---

アナリスト紹介：コンヴェクィティ

📍テクノロジー担当

コンヴェクィティのその他のテクノロジー銘柄のレポートに関心がございましたら、こちらのリンクより、コンヴェクィティのプロフィールページにてご覧いただければと思います。

---