DeepSeekが大規模では安価なのにローカルでは高コストな理由

• DeepSeek-V3 のような一部のAIモデルは、大規模提供時には安価で高速だが、ローカル実行では遅く高コストになる
• その理由は、GPU活用効率に関わる throughput（スループット）と latency（レイテンシ） の根本的なトレードオフにある
• バッチサイズを大きくするとGPUは効率的に動作するが、ユーザーはトークンが集まるまで待つ必要があり、レイテンシ増加が発生する
• Mixture-of-Experts構造 と ディープパイプライン を持つモデルは、高いバッチと長いレイテンシを必要とする
• ローカルの単一ユーザー環境では、十分に大きなバッチ形成が難しく、性能低下とコスト増加の問題が生じる
• OpenAI、Anthropic などは、アーキテクチャ自体の効率化、高度なバッチ戦略、あるいは大量のGPU投入によって高速応答を実現している

---

バッチ推論とGPU効率

• GPUは 大規模行列積（GEMM） に最適化されたハードウェアである
• 複数ユーザーのトークンを一度にまとめて大きな行列としてバッチ実行すると、低い往復オーバーヘッドとメモリ効率 によりスループットが大幅に向上する
• 推論サーバーは複数リクエストのトークンをキューに積み、適切なサイズのバッチを選んで大規模なGEMM演算を行う
• この過程でサーバーは、バッチサイズ（throughput増加） と 待ち時間（latency増加） のトレードオフを選択することになる

なぜ一部のモデルは大規模バッチに最適化されているのか

Mixture of Experts（MoE）とバッチ

• MoE構造（DeepSeek-V3、GPT-4と推定）がGPU効率の低い主要因である
• 数百の「専門家」ブロックがそれぞれ独立した行列積を必要とするため、小規模バッチでは各エキスパートの仕事量が少なく効率が落ちる
• すべてのエキスパートを十分に活用するには多くの同時リクエストが必要であり、サービスレベルでは大規模バッチが必須となる
• 短い待機（ウィンドウ5ms） ではエキスパートが頻繁にアイドル状態になり、長い待機（ウィンドウ200ms） では高効率を最大化できる

ディープパイプラインモデルのバッチ問題

• 数百層の大規模トランスフォーマー は、複数GPUにレイヤー単位で分割（パイプライニング）して実行する
• 1つのバッチ内のトークン数がパイプラインステップ数より少ない場合、「パイプラインバブル」が発生し、スループット低下につながる
• これを防ぐには大きなバッチ（長い待機）が必須であり、その結果 モデルの応答時間が長くなる

なぜ常にキューを満たせないのか

• 理論上は、多数の同時トラフィックで常にキューを埋めればバブルを回避できるように見える
• しかし、トランスフォーマーのAttention段階では行列サイズ（長さ）がすべて同じでなければバッチ化できないため、実運用で単一キューを完全に機能させるのは難しい
• また、FFNとattention段階を分離すると、メモリオーバーヘッド の急増とデータ移動の非効率という問題も生じる

要約と結論

• 大規模バッチ処理 はGPUコスト削減とスループット向上に不可欠だが、ユーザーの待ち時間は長くなる
• Mixture-of-Experts、大規模パイプライン構造 のモデルは、本質的に待機ベースの高効率バッチ環境に最適化されている
• ローカルのようにトラフィックが少ない環境 では、最適化された大規模バッチ構成が不可能なため、GPU効率が急低下し実行コストが上昇する
• OpenAI、Anthropic などが高速な応答性を示す理由 は次の可能性がある
  • (1) MoEではない、より効率的な構造である可能性
  • (2) バッチ／パイプライン最適化や高度な推論テクニックを適用している可能性
  • (3) 必要以上に多くのGPUを投入して、速度を買っている構造である可能性

追加: プリフィルバッチと本文バッチの違い

• トランスフォーマーは、1ユーザーのプロンプトにおける プリフィル（長い入力）もバッチ実行でき、初期推論を高速化できる
• ただし本文で論じたバッチは、複数ユーザーのリクエストにおける 本格的なトークン生成段階 で発生する、スループットとレイテンシのトレードオフに関するバッチである
• プリフィルバッチは、本文で述べた同時大規模バッチと直接的な関係はない

参考事項

• 実際の推論システムでは、継続的バッチ処理（continuous batching） を併用し、バッチが埋まると即座に実行する
• しかし、根本的な throughput-latency トレードオフ の構造は同じように適用される

[GN⁺]

Hacker Newsの意見

• 自分はDeepseek V3を自宅で直接動かしているが、価格負担は小さく、速度と性能にも満足している。多くの人はGPUなしでは大規模モデルを動かせないと思っているが、自分の経験ではむしろCPUサーバーのほうが消費電力も少なく実用的だと感じる。自宅サーバーはミドルレンジのEPYC 9004シリーズをベースにした、384GB RAM搭載のSupermicroボードを使用しており、総費用は約4000ドル。GPUがなくてもRAMを十分に積めば、消費電力がゲーミングデスクトップより低いことも多い。Unsloth Dynamic GGUFモデルを活用してRAMを270GBほど使用し、実際には元モデルとほぼ同等の品質でさまざまな作業をこなせる。普段は16kコンテキストで動かし、必要なら24kまで拡張して使う。トークン生成速度は毎秒9〜10、コンテキストを大きくすると7程度。2CPUを使う環境では、これよりさらに高速なトークン速度でフルモデルを回している例もある
  • Unsloth Dynamic GGUFが実際に元モデルにどれほど近い性能を示すのか気になる。自分の経験では簡単な作業では差は大きくないが、複雑な課題や長いコンテキストでは差がはっきり出ることがある。Unslothが素晴らしい仕事をしているのは事実だが、元の非量子化モデルとの直接比較評価が不足しているのは残念。多くの個人や企業にとって元モデルを直接動かす余力がないのも現実的な制約だ
  • Ollamaのようなツールで、Deepseekをコード生成用途として40コアCPUと256GB RAMで動かせるのか気になる。モデルには約200GBのメモリ割り当てを想定している
  • 個人サイトにアクセスできないという言及。自分はDigitalOcean共同創業者のJeff Carrだと名乗り、連絡がつくことを願っている
  • 高速メモリを備えたGPUが必須だと思っていたが、本当にGPUなしで大容量メモリだけで推論できるのか質問。統合メモリではない構成でどう実現しているのか気になる
  • Deepseek V3がオープンウェイトモデルの中で実用性が非常に高い点には同意する。多くの作業では、思ったほど高レベルのreasoningトークンは必要なく、待たなくてよいのが利点だ。必要ならいつでもより高いreasoningオプションを選べるのも魅力。自前で動かさない場合でも、完全なコンテキスト（16k）と80tpsを提供し、データを利用しないと約束するサービスを提供する事業者もいる。9004ホームサーバーの活用例として、素晴らしい構成だという感想
• このブログ記事の内容は印象的だという評価。結論（「バッチングが必要」）には同意するが、MoEモデル推論に関する議論はもう少し多面的であるべきだという意見。大きなバッチが重要な理由は、LLM推論では計算量不足ではなく、すべてのウェイトをVRAMからロードすることがボトルネックだからだ。H100のTFLOPSとメモリ帯域幅を比べると、実際には1バイトあたり300 FLOPを処理できる余地があるという計算になる。バッチが大きいほど、ロードした各パラメータあたりでより多くの計算ができるため、バッチサイズの最大化が必要になる。そのため「roofline model」という用語が使われる。モデルが大きくなるにつれてVRAMに全体が収まらなくなり、複数のGPUやノードに分散する必要が出てくる。NVLinkやInfiniBandでもVRAMからの直接ロードほど速くはなく、そこがボトルネックになる。MoEの強みはexpert parallelism、つまり異なるノードに異なるexpertをメモリ上に配置し、ノード間通信を最小化できる点にある。ただし、すべてのexpertがVRAMに収まり、KVキャッシュなどのオーバーヘッドも吸収できるだけのノード数がある場合に限る。結局、バッチサイズは自然と大きくならざるを得ず、そうして初めて各GPUが効率的に動作できる
  • 異なる「expert」を1つのノードにラウンドロビンで割り当て、複数のリクエストが同じexpertを使うときだけ機会的にバッチ化する方式を提案。バッチの代わりにキューを置くようなもので、レイテンシは増えるが、深い研究ワークフローのような環境なら十分許容できる水準
  • モデルが1台のGPUに収まらないとき、レイヤーごとに分割し、次のレイヤーを担当するGPUに小さなベクトルを送って計算する方式で推論できるという実運用例。Cerebrasではこの方式でLlama 4 Maverickにおいて毎秒2500兆トークンを生成。fabric上でのベクトル転送は非常に速く、アイドル時間はほとんどない
  • すべてのノードとウェイトがアナログ回路に配置されれば、はるかに高速に動作できるのではないかという可能性を想像
  • AMDに投資する論理の1つとして、モデル全体が単一シャーシに収まり、マップ/リデュース方式の利点とネットワーク機器コスト削減があるという点を挙げる。反対意見があれば知見がほしい
• 時間を節約したい人向けの一行要約：答えはバッチ推論。複数人のプロンプトをモデルインスタンスに同時投入する方式で、細かく時分割するだけより実質的にはるかに効率的だ。これによりtemperatureやseedを固定してもサービス応答が毎回異なることがあり、その理由は各プロンプトが何と一緒にバッチされるかを制御できないからだ。この現象がデータ窃取の攻撃ベクトルになり得る可能性も想像できる
  • バッチの利点の1つは、同じ内容の評価を繰り返して実際に「hallucination」があるか確認したいとき、batch-size分だけまとめて投げられて便利なことだ。実はバッチという概念はLLMに最初からあったが、時間がたってからその真価を実感しがちだ
  • 自分はサービス提供者がすべてのモデルで常にバッチ処理をしていると単純に推測していたが、特定のモデルファミリーでのみ適用されるのか気になる
  • 他のプロンプトと一緒にバッチされると、なぜモデル応答に変動が生じるのか気になる
  • プロンプトが他人のものと一緒に束ねられるなら、非常に有効な攻撃ベクトルになり得るという懸念
• 簡潔にまとめると:<br>- 高いsparsityを持つモデルでは、1回の行列積を十分に計算集約的にするために大規模バッチ（同時リクエスト数）が必要<br>- その規模の大きいバッチをさばくには、モデルウェイトとMLA/KVキャッシュをHBMに収めるために8〜16基程度のGPUが必要。だが8〜16基のGPUでは総スループットが低く、個々のユーザーの応答速度は本当に遅くなる。改善するには256基程度のGPUが必要で、そこでようやく快適な利用体験が期待できる
  • 自分は16基のH100（2ノード）環境でDeepseekをサービス提供している。リクエストあたり毎秒50〜80トークンで、全体として数千トークン規模まで安定したスループットを確認している。最初のトークン生成時間も安定しており、我々が使えるどのクラウドサービスよりも速い体験だ
  • sparsityが高い = 大規模バッチが必要、というつながりがよく理解できないという意見。疎行列積は結局0が多い行列積にすぎないだろう、という皮肉
• LLMの観点から素晴らしい解説だという感想。ハイパースケールLLM企業は実際の計算トレースを綿密に分析してボトルネック区間を洗い出し、ロードバランサー、パイプラインアーキテクチャ、スケジューラなどでワークロード最適化に本気で取り組んでいるだろうという予測。効率確保のための「バッチ前提条件」は、高い安全性が求められるアプリケーションでは不利になり得て、クエリ分離が極めて高コストになる構造だ。NVIDIAのvGPU仮想化はGPUメモリを時分割するが、コンテキストスイッチのたびにアンロード/リロードが必要で、重複排除もないのではと疑っている。MIGもメモリをユーザーごとに固定分割するが、再調整にはGPUの再起動が必要で、96GB GPUを4x24GBに分割したくない気持ちはよく分かる。GPUボードに第2のメモリ（DRAM）を追加すれば、PCIeより速くさまざまな行列データを載せられるのではないかと想像する（HBMをキャッシュとして）。<br>Software Engineering生存型実戦ガイドブック の率直な記述も高く評価されている
• Deepseek向けソフトウェアの最適化余地はまだ大きいという意見。実際、小型GPU＋大容量RAMシステム（ktransformers）か、非常に大きなVRAMを持つシステムか、この2種類に対するアクセシビリティ重視の最適化しか進んでいない。192GB VRAM＋残り通常メモリという構成（DGX station、2xRTX Pro 6000など）では、MoEの力でDeepseek 4bitもかなり高速に動くはず。Deepseekでは中国語プロンプトでなければ、ほとんどのexpertは活性化されない。プルーニングもしやすい環境だ。今後のenthusiast向けシステムは、こうしたソフトウェア最適化に合った方向へ進むだろう。Redditには16x3090（Pcie 3.0 x4）システムでllama.cpp上毎秒7トークン程度を実現した例もあり、3090単体でもVRAM全体を毎秒39回スキャンできるのだから、別の性能ボトルネックがあるはずだ
  • 16x3090システムの消費電力は実に5KW。このレベルなら電気代を考えるとAPIを使ったほうが安い。Deepseekでは中国語プロンプトを使わないと活性化されないexpertが多いという点から、モデル軽量化やトークンをより近いexpertへルーティングする方式を想像する
  • MI300x 1基で192GB VRAMを提供できる
• 自分はML研究者でもエンジニアでもないので、その点を踏まえて聞いてほしいという前置き。Deepseek V3/R1は従来のローカルモデルよりはるかに大きく、ローカルで動かすこと自体が高価なのは事実だ。アクティブなパラメータ数は全体サイズより少ないが、それは計算要件を減らすだけで、メモリ要件はそのままなので、巨大なGPUがなければ実用はほぼ不可能だ。主要なフロンティアのproprietaryモデルとは直接比較もできず、サイズなどの情報が公開されていない。それらのモデルがローカルでより安く動くと期待する根拠もない。むしろMoEはローカル/シングルユーザー環境ではバッチ非効率の問題が小さいため、より適したトレードオフを提供する。バッチを大きくすると各トークンの待ち時間は200msまで増えるが、その代わりfeed-forward演算（GEMM）が大きくなり、より効率よく計算できる。バッチが大きくなると行列自体が大きくなるのか気になる。自分の頭の中のモデルでは、バッチは「入力行列サイズを増やす」のが目的というより、「メモリ帯域制約を計算ボトルネックへ移す」ことが目的のように思える。すでにウェイトはレイヤーごとに分割されてHBM → SRAMへ読み込まれ、分割ごとに行列積を計算し最後に結果を足し合わせる構造だ。バッチングの利点は、同じウェイトで複数の演算を同時処理できることで、FLOPSを効率的に最大化できる点にある。OpenAIやAnthropicなどの大規模モデルが実際に高速応答しているのか、ブログ記事にはtime to first tokenごとの数値がなく根拠が弱いと思う
  • 自分は元記事の著者だ。ML研究者ではなく、関心の強いエンジニアという立場だ。MoEのローカル単一ユーザーシナリオとは、マルチユーザーのバッチ利点がないため、GPUあたりのスループットが劇的に落ちるという意味だ。大量の並列推論リクエストがない限りそうなる。バッチによって入力行列サイズを大きくすると、バッチ1では1xdim行列だった計算が、バッチが増えるとbatch-size x dimになり、GPU利用率が急上昇して計算ボトルネックへ転換できる。最後に、Deepseekが他モデルより遅いのも、たくさん使えば実感できる
• mixture of expertsは大きなバッチが必要だが、Appleシリコンを使うならバッチサイズ1でも実用になることを想定している。unified memoryのおかげで大きなモデルもローカル実行できるが、帯域幅とFLOPSが低いため動作は比較的遅い。MoEは毎回処理すべきパラメータ数が少ないため計算負荷が低いという特性がある。実際、DeepseekをMacでシングルバッチ推論として十分実用的な速度で動かした人の経験は多い。もちろん十分なメモリを積むには購入コストが高い点は変わらない。Macや似た構造のマシンが今後さらに増えれば、MoEモデルとの相性は抜群だという評価。大容量RAMにアップグレードしたMacでdenseモデルを回すのは、比較にならないほどつらいという対比
• 同僚と話していて、プログラミング支援向けにLLMを使う場合、モデルはむしろ本質的な最適化から外れた方向に進化しているという結論になった。自分は社内規定上、ほぼすべての作業でローカル4〜30Bモデルと複数のGPTシリーズを比較しているが、特にGPT-4oは平均的には優秀な結果を出す一方で、「応答の一部を捏造する」傾向もあり、検証と反復にかなり時間を取られる。結果として「低パラメータのローカルモデルとの努力対効果の差は思ったほど大きくない」という判断になった。問題はどちらも本当に遅く、高速な反復ができないことだ。自分は品質が多少低くても、応答が稲妻のように即時に返る大コンテキストモデルのほうがずっと使いやすいと感じる。実際の品質評価指標の改善以上に、「体感上の反復速度」が重要だという願い
• 「遅くて高い」という主張には反対だ。DDR4メモリベースの旧型ワークステーションでも、llama.cppを使えば1000ドル前後のシステムで毎秒3トークン出せるという事例がある
  • 君は実際のDeepseekモデルではなく、distill版を混同して使っているのかもしれないという指摘。192GB RAM以上がなければ本物のモデルは動かせない