世界を動かす技術を、日本語で。

96台のH100 GPUにDeepSeekを展開する

概要

  • DeepSeek は高性能なオープンソース大規模言語モデル(LLM)であり、独自のアーキテクチャを持つ
  • SGLang による最適化実装で、公式DeepSeekブログに近いスループットを達成
  • Prefill-Decode分離 と大規模Expert Parallelism(EP)を活用し、コスト効率も大幅向上
  • すべてのコンポーネントと実験コードは 完全オープンソース で公開
  • 本記事では並列化設計、最適化手法、評価結果を解説

DeepSeek推論システムの大規模並列化と最適化

  • DeepSeek はMulti-head Latent Attention(MLA)とMixture of Experts(MoE)を採用した独自構造
  • モデル規模が大きく、効率的な大規模サービングには高度な並列化設計が必要
  • SGLangを用いた実装はAtlas Cloud上の 12ノード・各8台のH100 GPU で稼働
  • Prefill-Decode分離および大規模Expert Parallelism(EP)により
    • 1ノードあたり 52.3k input tokens/sec22.3k output tokens/sec (2000トークン入力時)を達成
  • 公式DeepSeek報告にほぼ匹敵するスループットをオープンソースで初めて実現

コスト・効率比較

  • この構成をローカルで展開した場合、 $0.20/100万output tokens のコスト
  • 公式DeepSeek Chat APIの約1/5のコスト効率
  • 同じリソースでのバニラTensor Parallelismと比較し、 最大5倍の出力スループット向上

主な技術ハイライト

  • Prefill-Decode分離(PD Disaggregation) と大規模EP(DeepEP, DeepGEMM, EPLB)をSGLangでサポート
  • 12ノード・各8 H100 GPUでDeepSeek推論システムを再現
  • 効率化・メモリピーク削減・ワークロードバランスに重点を置いた最適化
  • 実験結果・コードは全て オープンソース で公開

並列化設計

  • 計算複雑性メモリ要求 を満たすため、各コンポーネントごとに最適な並列化戦略を採用
    • Attention Layer:DP Attention(KVキャッシュ重複排除によるメモリ削減)
    • Dense FFN:Data Parallelism(DP)によるスケーラビリティ・メモリ効率・通信コスト最小化
    • Sparse FFN(MoE):Expert Parallelism(EP)で大規模専門家重みの分散
    • LM Head:DP適用によるメモリ・通信効率化

Attention Layer最適化

  • DeepSeekのMLAに対し、 DP Attention でKVキャッシュ重複を排除し、メモリオーバーヘッドを大幅削減
  • SGLang v0.4からハイブリッドDP/TPをサポートし、小バッチサイズでも効率的処理

Dense FFN最適化

  • 中間次元18,432など高次元FFNがメモリピークの主因
  • Tensor Parallelism(TP)では分割単位が小さくなりすぎ、GPUアラインメント効率低下
  • DPは分割ロスを回避し、バランス良いワークロード分配が可能
  • メモリ効率:
    • TPはDP Attention下での優位性が減少
    • DP=TP時、最適なTPサイズはPrefill3以下・Decode6程度
    • 低TP度の方がメモリ効率良好
  • 通信効率:
    • TPはFFNごとにAll-Reduce2回必要
    • DPはReduce-ScatterとAll-Gather1回ずつで通信コスト半減
    • AttentionもDPなら通信完全排除が可能

Sparse FFN(MoE)最適化

  • 大規模専門家重みの分散が必要
  • Expert Parallelism(EP) で各デバイスに専門家重みを分配し、メモリボトルネックを解消
  • 不規則なAll-to-All通信やワークロード不均衡の課題もEP設計で最適化

LM Head最適化

  • 大語彙出力のため、従来はVocabulary Parallelismを採用
  • 本実装では DP を適用し、通信・メモリ効率を向上

Prefill-Decode分離(PD Disaggregation)

  • LLM推論は Prefill(全入力処理)Decode(トークン生成) の2フェーズ
  • 従来は一体型エンジンでスケジューリングされ非効率
    • PrefillバッチがDecodeバッチを頻繁に中断、トークン生成遅延
    • DP AttentionでPrefill/Decode混在時に遅延増大
    • DeepEPのPrefill/Decode異なるディスパッチモードに非対応
  • PD分離 で各フェーズを独立最適化、GPU利用率最大化

実装詳細

  • Prefill ServerとDecode Serverがペアとなり、ローカルで送受信を確立
  • Decode ServerがKVキャッシュを事前割当→Prefill Serverが前処理・KV計算→Decode Serverへ転送→トークン生成
  • ノンブロッキング転送 :バックグラウンドスレッドで送受信し、イベントループを妨げない
  • RDMA利用 :非連続メモリチャンクも効率的に転送
  • 高性能RDMAライブラリ(Mooncake, NIXL等)とAPI統合

大規模Expert Parallelism

DeepEPによるExpert Parallelism

  • DeepSeek開発の通信ライブラリ DeepEP でMoEモデルの大規模EPを実現
  • トークンを専門家に効率的にルーティングし、通信遅延を最小化
  • Prefill/Decodeで異なるディスパッチモードを提供
    • Normal Dispatch :Prefill向け、最大スループット重視(CUDA Graph非対応)
    • Low-Latency Dispatch :Decode向け、低遅延重視(CUDA Graph対応・事前メモリ割当必須)
  • SGLangでは Autoモード でワークロードに応じて自動切替
  • PD分離によりPrefill/Decodeで最適なモードを同時活用可能

DeepGEMM統合

  • DeepSeek開発の高効率ライブラリ DeepGEMM でMoE関連行列積の高速化
  • 専用関数でPrefill/Decode双方の計算を最適化

評価・今後の展望

  • 本実装は公式DeepSeek報告にほぼ匹敵するスループットをオープンソースで実現
  • コスト効率・拡張性・再現性に優れる
  • 全コード・実験手順を公開し、コミュニティによる発展が期待

まとめ

  • DeepSeekの大規模推論を SGLang で最適化・オープンソース化
  • Prefill-Decode分離・大規模EP等の最先端技術を実装
  • コミュニティによるさらなる発展・応用に向けた基盤提供

Hackerたちの意見

「この実装をローカルで展開すると、1M出力トークンあたり0.20ドルのコストになります。」これは電気代だけの話?それともGPUの予想寿命に基づいたコストも含まれてるの?

「上の図に示した私たちの実装は、Atlas Cloudの12ノードで動作していて、それぞれに8つのH100 GPUが搭載されています。」レンタル費用も含まれてるのかな?

これにはすべてのコストが含まれてるよ。1ノードあたり22kトークン/秒、つまり8台のH100で。12ノードだと264kトークン/秒、つまり1時間で950百万だね。これでH100の$2/時間で約$0.2021百万になる。これはrunpod.ioみたいなサービスでの価格だよ。(スポット価格を払わず、ボリュームディスカウントを受ければもっと安くなる。)

私も気になる。記事には書かれてないけど、減価償却やGPUの故障率も考慮しないといけないよね。

わお、タイトルにオープンソースって入れてほしい!

なんで?オリジナルのタイトルにはオープンソースって入ってないじゃん。

これらのオープンモデルは、商業用のバイナリ配布をゼロコストで提供して、Western LLMプロバイダーが投資を活かす機会を潰す意図があるんだ。これってFOSSというより、むしろ素晴らしい企業のノベルティみたいなもんだね。

この投稿には関連する話がちょっとあったね: https://news.ycombinator.com/item?id=45050415。でもこのコスト分析はたくさんの疑問に答えてくれるし、これらのプロバイダーが推測しているインファレンスのマージンがどれだけ大きいかを教えてくれる。あと、GoogleやOpenAIは一般の人よりもデータセンターの料金が有利だと思う。8つのH100が載ったノードはAWSで1時間31.40ドルかかるから、96ノードだと1時間376.80ドルになるね。188百万の入力トークン/時、80百万の出力トークン/時だと、入力トークンは約2ドル/百万、出力トークンは4.70ドル/百万になる。これは実際、Deepseek r1の料金(入力が0.10〜0.60ドル/百万、出力が2ドル/百万)よりもかなり高いけど、主要なプロバイダーはAWSのp5オンデマンド価格を払ってないと思う。追記:これらの数字はノードごとのもので、実際の入力と出力の価格は12で割ることになる。入力トークンは0.17ドル/百万、出力トークンは0.39ドル/百万だね。

188Mの入力トークン / 80Mの出力トークンはノードごとの話だったと思うんだけど?この数字を逆算すると、彼らは約$2/H100/時間(8xH100ノードだと$16/時間)を支払っていることがわかる。ちなみに、私のサイトの一つでは、8xH100ノードの1ヶ月契約が$12.91/時間だって書いてある。サーバーを買ってCOLOに置く場合のレートは大体$10/時間だから、もっと良い条件で購入すればコストを約30%削減できる余地があるね。

なるほど、著者たちはどうやらアトラスクラウドホスティングを使っていて、H100あたり$1.80/時間を請求しているみたい。これだと全体のコストが入力あたり約$0.08百万、出力あたり$0.18百万になるから、大手プロバイダーの大規模な推論マージンにもっと合ってる感じだね。

投稿によると、彼らのコストはクラウドGPUで出力トークンあたり$0.20/1Mだったから、君の数字はどこかおかしいよ。

AWSは全然安くないし、今まで安かったこともないよ。GPUの世界でヘッツナーみたいなところ、例えばrunpod.ioを探した方がいい。そこは$2/時間だから、8台で$16/時間、AWSの半分だよ。96台を探しているなら、ボリュームディスカウントもあるかも。H100は約$32kで、3-5年で償却すると$1.21から$0.7/時間になるから、電気代やCPU/RAMなどを加えると、runpod.ioはAWSに比べて実際のコストにかなり近い。

AWSで8台のH100を使うノードは1時間あたり$31.40かかるから、96台だと1時間あたり$376.80になるんだよね。しかも、こんな感じのDell/HPEサーバーをオンラインで作ることもできないのが残念。『AIサーバー』の見積もりをリクエストしないといけないんだ。SuperMicroを通すと、サーバー自体が約$60,000で、8つのGPUがそれぞれ$25,000だから、8 GPUノードで約$300,000になる。これにはネットワークやストレージ、ラック、電気、冷却、設置してくれる人、$1,000のDACケーブル、NVIDIAのミドルウェア、H100の不安定さによるダウンタイムも含まれてないから、定期的に交換が必要になるし…。この場合、96台のH100クラスター(12台のH100)をセットアップするには、$4-5百万かかると思う。でも、1年半後にはAWSより安くなるはずだよ。

Sglangを使ったプレフィルとデコーディングレイヤーの分離はかなり面白い!普通、8xH100じゃKVキャッシュも考慮せずにモデルの4bit量子化を保持するのは難しいのに。一つのプレフィルノードで3つのデコーディングノードを支えるのも魅力的だし、いいまとめだね。

面白いことに、これはOpenRouterで最も安いプロバイダーの10倍安いよ: https://openrouter.ai/deepseek/deepseek-r1?sort=price インファレンスは思ってたよりも利益が出るね。

トークンあたりのコストについてコメントしてる人へ:このスループットは100%の稼働率を前提にしてるよ。スケールでコストが上がる要因はいくつかある: - この規模ではオンデマンドGPUはないから、数年契約でレンタルしなきゃいけない。だから、最大スループット(または十分に高いパーセンタイル)のために、ある数のGPUをロックインする必要があるんだ。ピーク時のスループットは西海岸のビジネスアワーで2-3倍高いだろうし、 - GPUはデータ処理やレイテンシの問題で地域制限がかかることが多い。だから、アジアはデータをアメリカに送るのを嫌がるし、アメリカもアジアにデータを送るのを嫌がるから、夜間にこれらのGPUを利用するのは難しい。これらの要因で、GPUの稼働率は10-20%になるんだ。もし君が新しいモデルのトレーニングにお金をたくさん使う大企業なら、オフピーク時間にRL推論やモデルのトレーニングを入れて稼働率を最大化することもできるかもしれない。でも、純粋に推論に特化している企業には、この90%のマージンが本物だとは思わない方がいいよ。たとえ「10倍安い」と見えても、実際のマージンは50%くらいだと思う。

夜間の件だけど、だからこそいくつかのプロバイダーは、非対話型のユースケース向けに12時間または24時間で返却されるバッチティアの仕事を50%オフで提供してるんだよ。

もしいくつかの地域にワークロードを分散させることができれば、そんなに多くのGPUをオンデマンドで手に入れるのも可能かも。GCPのコンピュートクラスみたいなもので、在庫切れの時に別のマシンタイプにフォールバックできるし。これで在庫切れから完全に免れるわけじゃないけど、かなり耐性がつくよ。デューティサイクルメトリクスを使って、GPUワークロードをスケールダウンして無駄を減らすこともできるしね。

それに、分野がすごく早く進化してるから、1年後や2年後に同じマージンを維持できるとは限らないってことも考えないといけないよ。

この規模でのオンデマンドGPUは存在しない。 > この2つの要因により、GPUの利用率は10-20%にとどまる。どうしてこの2つの要因が相殺されないの? 自社用のプライベートGPUクラスターを構築する企業が、ワークロードスケジューラー(例えばSlurm)を前に置いて、クレジット会計や使用ベースの請求を有効にして、検証済みの顧客パートナーがバッチジョブをクラスターに送信できるようにしないのはなぜ? そうすれば、各ジョブはクラスターの低稼働ポイントでの大きなスポットリソース割り当てを受けて、できるだけ早く完了できるのに。いくつかの企業や大学が余剰の推論能力を地元の中小企業に貸し出すことを決めれば、「この規模でのオンデマンドGPU」が実現することになる。アクセスを得るためにいくつかの会議を経る必要があるけど、家のローンを組むのと同じくらいの手間で済むはずだし、VC投資を受けるほど面倒なことはないよね。これが商業市場でのHPCコンピュートの仕組みなんだ。HPCクラスターの検証済み顧客が独立した「広いけど短い」ジョブのフライトを送り出して、リソースを詰め込んで他のクライアントのジョブと公平にスケジュールして、夜間に実行されるんだ。じゃあ、どうして同じような商業的な「GPU HPC」市場が見られないの? そういうクラスターを作ってる企業は、投資家から資金を受けていて、GPUのTCOを最小化する方法を考える努力をすることに関心がないか、あるいは、非常に大きな企業で、1つの大きな「顧客」と契約していて、その顧客が100%の余剰GPU時間を吸収できる状態にあるのかもしれない。…それとも、そうでなければ、これらのクラスターがオーナー自身によって100%利用されていることが判明するのかもしれない。どちらにしても、これらのステートメントが真実でないなら、ここにはまさに$20札が落ちていることになるよ。(しかも、企業の視点から見ると最高の$20札だよ:賃貸収入。)

「バッチ処理」市場がどれくらい大きいか知ってる? 主要なプロバイダーはオフピーク処理で50%以上の割引を提供してるって聞いたけど。これはこの問題を少し修正するためだと思ってたし、表面的にはビッグデータの場所では十分な処理ができるから、比較的大きな市場かもしれないね。実際どうなの?

SGLangチームがGB200 NVL72でのDeepSeek推論性能についてのフォローアップブログを出してるよ:https://lmsys.org/blog/2025-06-16-gb200-part-1/ もし高品質な推論のために$3-4M余ってるなら、チェックしてみてね。:) SGLangはH100に比べて2.5-3.4倍のスピードアップを引用してる。さらに最適化が進む予定だけど、まだブログのパート2は公開されてないみたい。

実際の例を見られるのはすごく助かる。生産推論ワークロードをデプロイするのが(ざっくり)どうなるか、最新の最適化努力も含めてね。私はこの分野でコンサルしてるけど、クライアントは「自分のLLMを動かす」ことがどれだけ複雑になり得るか、まだ完全には理解してないんだよね。