1 台の H100 で OSS LLM をよりスマートに、低コストで、高速に実行

セッションノート

P5.4xlarge インスタンスの概要：

• AWS は P5.4xlarge を導入し、強力なオープンソース LLM（Qwen-32B、Mistral、LLaMA 2 など）を 1 台の NVIDIA H100 GPU でホストできるようにしました。
• これまで必要だった、大規模で高価なマルチ GPU クラスターの過剰プロビジョニングを解消します。対象者：
• 高コストやパフォーマンスの妥協なしに OSS LLM をホストしたいエンジニア、スタートアップ、個人の技術愛好家。
• 大規模なクラスターでスケールアップするのではなく、スマートにスケールしたいチーム。主なメリット：
• コスト効率：複雑なマルチ GPU クラスターの過剰プロビジョニングと管理の必要性を低減します。
• パフォーマンス：1 台の H100 GPU で、メモリや計算能力を妥協することなく提供します。
• 利用しやすさ：強力な GenAI 機能をより多くの開発者が利用できるようにします。セッションのハイライト：
• P5.4xlarge 上の OSS モデルについて、実環境のベンチマークを検証します。
• エージェント型 GenAI ワークフローとコスト削減戦略について説明します。
• Hugging Face transformers などのモデルや低レイテンシーのチャットボットに関する実践的なデプロイのヒント。実践的な成果：
• どの OSS モデルが 1 台の H100 で効率的に動作するかを理解します。
• P5.4xlarge で期待できるパフォーマンス。
• 過剰プロビジョニングをせず、特定のニーズに合ったインフラストラクチャを設計する戦略。結論：
• 「有用なチャットボットや GenAI アプリを提供するのに、ほとんどの人は 8 GPU のモンスターを必要としません。それでも結局、その費用を支払っています。」
• 小規模チームや個人のエンジニアが AWS P5.4xlarge を使用して、OSS LLM を効果的かつ費用効率よくデプロイできるようにします。– ニーズの紹介：
• 「1 台の H100 を利用するためだけに 8 台の GPU の料金を支払って管理する代わりに、ようやくワークロードに合ったインスタンスサイズを選べると想像してください。」
• 問題：
• 大規模 GPU クラスターの過剰プロビジョニングによる非効率性とコスト。画期的な進展の発表：
• 新しいサービス：
• 「AWS は最近、新しいシングル GPU の P5 インスタンスサイズを導入しました。p5.4xlarge では最新の NVIDIA H100 を利用でき、余分な購入も無駄もありません。」
• 解決策：
• 不要な費用と複雑さの排除を強調します。仕様とシンプルさの強調：
• インスタンスの仕様：
• 「p5.4xlarge には必要なものがすべて揃っています。1×H100 GPU、16 vCPUs、256 GiB RAM、約 4 TB NVMe SSD、100 Gbps ネットワークです。」
• メリット：
• 「フラッグシップ GPU のすべての能力を、シンプルなデプロイと低い料金で利用できます。」価格差の明確化：
• コスト比較：
• 「一部のリージョンでは、これを 1 時間あたり約 $3.90 で利用できます。より大きな P5 で 8 台すべての GPU に料金を支払う場合と比較してください。」
• 効果：
• 「これにより、小規模チームにとって、実験、デモ、さらには本番環境へのハードルが大幅に下がります。」導入前と導入後：
• 以前の状況：
• 「以前、H100 は『エンタープライズ規模』と莫大な初期コストを意味していました。」
• 現在の状況：
• 「今では、ワンクリックでプロ仕様の機能を利用できます。シングルテナント API、エージェント型 RAG、社内ツール、迅速に動くスタートアップに最適です。」
• 変革：
• 高性能 GPU の機能を利用しやすく、手頃な価格にすることに重点を置きます。視聴者に持ち帰ってほしいこと：
• 利用しやすさ：
• 「p5.4xlarge によって、NVIDIA H100 の能力が『一般的な』ユースケースでも手の届くものになります。大規模なクラスターは不要です。」
• 効率：
• 「よりシンプルで、より安価であり、ほとんどのオープンソース LLM のサービングと実験に最適なサイズです。」
• 最適なソリューション：
• 「GenAI に最適な GPU が必要なら、今では 1 台だけ入手できます。クラスターは不要です。」– 1 台の H100 には実際に何が収まるのか？一般的なチャットと高度な推論に対応する Qwen3‑32B：
• 「Qwen3‑32B は 32.8B パラメータの密モデルで、最大 32k トークンのコンテキストを備えているため、実際のドキュメントチャット、コーディング、さらにはエージェント型のユースケースにも優れた性能を発揮します。」
• パフォーマンス：
• 「1 台の H100 で約 1,500 tokens/sec を難なく達成し、余裕を持って複数の同時チャットに対応します。」効率性に優れた Mistral/Mixtral：
• 「Mistral 7B と Mixtral‑7x8B は推論向けに最適化されており、トークンごとに有効化するパラメータがはるかに少ないにもかかわらず、一部のベンチマークでは 70B の密モデルを上回ります。」
• パフォーマンス：
• 「H1100 上の TensorRT‑LLM は A100 の約 3 倍のスループットを実現します。つまり、わずかなハードウェアで 70B に近いパフォーマンスを得られます。」Llama 2‑13B / 70B：位置付けと 1 台では不十分な場合：
• 「Llama 2‑13B は 1 台の H100 で高速に動作します（5,000+ tokens/sec）。70B も動作しますが、本格的な大規模運用では複数の GPU が必要になる場合があります。」
• ユースケース：
• 「ほとんどのチャット製品と RAG 製品では、13–32B が収まり、高速に動作します。70B が必須なのは、最高品質または最大規模のモデルの場合だけです。」
• 「≤32B の密モデル（またはアクティブパラメータが 13B の MoE）が必要なら、リアルタイムのチャットボットと GenAI API には 1 台の H100 で十分です。」– 価値の位置付け：
• 「分散インフラストラクチャやクラスター管理の悩みなしに、1 台の H100 で見事に動作する 3 つの一般的な GenAI アーキテクチャを見てみましょう。」パターン 1 – 低レイテンシーのチャット／推論 API：
• 「実用的なチャットボットと推論 API をわずか 1 台のサーバーで提供できます。Hugging Face Transformers でモデルをロードし、vLLM または TensorRT‑LLM でサービングし、シンプルな API ゲートウェイを前段に配置します。」
• メリット：
• 「H100 の処理能力により、同時実行性が高まり、コードの複雑さが軽減されます。シャーディングや並列化の工夫は不要です。」パターン 2 – 検索拡張生成（RAG）：
• 「RAG では、ベクトル DB とドキュメントを GPU の外部に置き、負荷の高い LLM 生成を H100 に任せます。」
• メリット：
• 「これによりコストを抑え、パフォーマンスを高く保てます。最新の MoE モデルは、適切な量子化によって 1 台の H100 にも収まり、特殊なハードウェアの工夫は不要です。」パターン 3 – エージェント型ワークフロー：
• 「アクションを連鎖させてエージェントを作成したいですか？1 台の H100 で 32B のプランナーモデルを実行し、そのモデルがツール（HTTP、Lambda、コンテナなどを経由）を呼び出します。」
• メリット：
• 「GPU が処理するのは『思考』だけなので、インスタンスごとに複数のエージェントフローとユーザーを同時に処理できます。」まとめ：
• ほとんどの GenAI 製品（チャット、API、RAG、エージェント）を、わずか 1 台の H100 インスタンスで構築できます。」– 比較の位置付け：
• 「ここまでの内容を、シンプルな判断基準に置き換えてみましょう。1 台の H100 が適しているのはいつで、クラスターが本当に必要なのはいつでしょうか？」効率：
• 「調査によると、マルチ GPU クラスターで完全に線形なスケーリングが得られることはほとんどありません。8 台の GPU でも、得られる速度は期待値の 75–85% にとどまることが多く、特にリアルタイム推論では GPU 間通信が速度を低下させます。」コストと俊敏性の優位性：
• 「p5.4xlarge の料金は約 $3.90/hr なので、小規模チームは数ドルで本番グレードの GenAI を実行でき、大規模なクラスターに長期的に投資する必要はありません。」シングル H100 のユースケース：
• 「モデルが 13–32B、またはアクティブパラメータが ~13B の MoE であれば、1 台の H100 で開発、社内ツール、初期の本番環境、中程度のトラフィックに対応でき、クラスター管理の悩みもありません。」マルチ GPU のユースケース：
• 「本格的な 70B+ 規模が必要な場合、または膨大なトラフィックをサポートする必要がある場合にのみ、マルチ GPU を選択してください。」今後の参考：
• 「1 台の H100 の能力を超えることがあれば、より高いスループットを備えた H200 が登場を控えています。」
• 「しかし現在、ほぼすべての人にとって H100 が最適な選択肢です。」– 主なポイントのまとめ：
• 「ほとんどのオープンソース LLM ワークロードに巨大なクラスターは必要ありません。ニーズに合わせて調整した 1 台の H100 p5.4xlarge だけで十分です。」収まるモデル：
• 「収まるモデルを見てきました。Qwen3‑32B、Mistral、Llama2‑13B、Mixtral はすべて 1 台の H100 でスムーズに動作します。」最新のアーキテクチャ：
• 「チャット API、RAG、エージェント型ワークフローという 3 つの最新アーキテクチャを検討しました。いずれも 1 台の H100 で簡素化され、スケーラブルになります。」コストと複雑さの削減：
• 「さらに、コストと複雑さを削減し、超高同時実行性や最大規模のモデルが必要な場合にのみクラスターへ移行します。」

26

Adit Modi

1 台の H100 で OSS LLM をよりスマートに、低コストで、高速に実行

このセッションの目的と対象者

• GenAI の実行に本当に 8 台の GPU が必要でしょうか？
• LLM インフラストラクチャへの過剰な支払いと過剰設計をやめましょう。このセッションの対象者は？
• 大規模なマルチ GPU クラスターの過剰プロビジョニングと管理に疲れた、小規模チーム、スタートアップ、個人のエンジニア。
• 専任のクラスター管理者になることなく、独自の条件でオープンソース LLM を実行したい開発者。
• 巨額の料金を支払わずに、チャットボット、API、RAG で大規模モデルのパフォーマンスを得る方法を知りたい方。このセッションの対象外となるのは？
• Bedrock、SageMaker JumpStart などのマネージド型ホスト LLM プラットフォームを使用するチーム、またはインフラストラクチャを制御しない「LLM-as-a-service」を希望するチーム。
• モデルをセルフホストする予定がなく、独自仕様のクラウド API（例：OpenAl、Anthropic）のみを使用して構築する方。
• 高 QPS で 70B+ パラメータのモデルを必要とし、大規模な分散クラスターの利用に抵抗がない方。OSS LLM の「過剰なクラスター」問題 ほとんどの GenAI ユースケースでは、これほどの規模は必要ありません！では、より良い方法はあるのでしょうか？
• チームは念のため、オープンソース LLM に大規模なマルチ GPU クラウド構成をデフォルトで採用します。
• その結果、実際には軽いことが多いワークロードに対して、複雑な分散推論、速度低下、多額のコストが発生します。
• 実際には、最新製品のほとんどのユースケースは、1 台の強力な GPU と小規模な 7B/13B/32B モデルを使用した方が高速かつ安価に動作します。
• ハードウェアを適正なサイズにすることで、レイテンシーが低下し、手間が減り、大幅な節約につながります。LLM の実行に複雑なマルチ GPU クラスターは必須ではありません。
• 過剰プロビジョニングはコストと複雑さを増大させますが、多くのチームでデフォルトになっています。
• ほとんどの最新 OSS モデルと一般的な製品ワークロードでは、速度、シンプルさ、コスト削減のために必要なのは、十分な性能を備えた 1 台の GPU だけです。p5.4xlarge の紹介：実際のワークロードに対応する 1 台の H100 優れた GPU がついに手の届くものに
• Amazon Web Services は最近、新しいシングル GPU の P5 インスタンスサイズを導入しました：
• p5.4xlarge では最新の NVIDIA H100 を利用でき、余分な購入も無駄もありません p5.4xlarge：仕様とシンプルさ
• p5.4xlarge には必要なものがすべて揃っています：
• 1xH100 GPU、16 vCPUs、256 GiB RAM、約 4 TB NVMe SSD、100 Gbps ネットワーク。フラッグシップ GPU のすべての能力を、シンプルなデプロイと低い料金で利用できます。
• 一部のリージョンでは、これを 1 時間あたり約 $3.90 で利用できます。より大きな P5 で 8 台すべての GPU に料金を支払う場合と比較してください。

1 台の H100 には何が収まるのか？（Qwen-32B、Mistral、Llama-2 など）

Qwen3-32B — 高度な推論、シングル GPU

• Qwen3-32B：32.8B の密なパラメータ、32k コンテキスト、優れたチャット／コーディング性能
• 1 台の H100 で ~1,500–1,800 tokens/sec で動作
• エージェント型チャットボットと API ワークロードに最適（リクエストのバッチ処理が可能）Mistral/Mixtral — 効率的な処理能力
• Mistral 7B：H100 上で高速に動作し、TensorRT-LLM の使用により A100 と比べて 3x のスループット
• Mixtral-7x8B（MoE）：70B に近いパフォーマンス、VRAM 使用量は大幅に低減
• 効率的なモデルで、コストと速度に優れ、本番環境に最適 Llama 2（13B/70B）— 現実的な検証
• Llama 2-13B：1 台の H100 で 5,000–6,000 tokens/sec（最適化あり）
• Llama 2-70B：実行可能だがレイテンシーが高く、本格的な 70B+ のニーズにのみ最適
• ほとんどの製品は、1 台の GPU 上の 13B– 32B で優れた結果を得られます 経験則—1 台の H100 で何ができるのか？
• LLM が <32B の密モデル、またはアクティブパラメータが ~13B の MoE であれば、応答性の高いマルチユーザーチャットと RAG API には 1 台の H100 で十分です H100：OSS GenAI サービングの新たな最適解
• 1 台の GPU 上の設計パターン：API、RAG、エージェント チャットと API のサービングパターン
• 1 台の H100 で LLM API を実行：Hugging Face + vLLM/TensorRT-LLM
• 複数のユーザーに低レイテンシーで提供—クラスター運用やシャーディングは不要
• シンプルで高速な、本番環境対応のデプロイ 検索拡張生成（RAG）
• ベクトル DB／ドキュメントを GPU の外部に保存し、LLM 生成には H100 を使用
• 1 台の H100 で RAG API に高スループットかつ高速な GenAI を提供
• Mixtral/MoE モデル：量子化により 1 台の GPU に収容 エージェント型ワークフロー
• H100 上の「プランナー」LLM（Qwen/Mistral）がタスクを外部ツールに振り分け
• GPU は思考に使用し、ツールは別の場所で実行（HTTP、Lambda、コンテナ）
• 1 つのインスタンスでマルチエージェント、マルチユーザーのフローをサポート まとめ—1 台の H100、多数のパターン
• ほとんどの GenAI 製品（チャット、API、RAG、エージェント）を、わずか 1 台の H100 インスタンスで構築できます。
• コストと適正なサイジング：1 台の H100 で十分な場合

1 台の H100 とマルチ GPU クラスターの比較

• マルチ GPU クラスター：効率は 75–85%、8x の高速化はまれ
• GPU 間通信がスケーリングを遅らせる—ハードウェアが増え、複雑さも増大
• 1 台の H100 でほとんどの OSS モデルに高いパフォーマンスを提供 コスト：p5.4xlarge は手頃な価格
• わずか $3.90/hour（Capacity Blocks、一部のリージョン）
• 実験、開発、本番環境を実行—8 台の GPU に料金を支払う必要なし
• 小規模チーム、スタートアップ、社内ツールに最適 H100 とマルチ GPU の選択基準
• シングル H100：7B– 32B の密モデル、またはアクティブパラメータが ~13B の MoE LLM、中程度の QPS に最適
• マルチ GPU：本格的な 70B+ モデルまたは大規模なファインチューニングに必要
• H200：超高スループットに向けた次のステップ（将来に対応）まとめと主なポイント
• ほとんどの OSS LLM ワークロード：シングル H100 の p5.4xlarge が賢明な選択
• クラスターの複雑さも無駄な出費もなく、実行、チューニング、デプロイするだけ 覚えておくべき 3 つの要点
• どのモデルが収まるか？Qwen3-32B、Llama 2-13B、Mistral、Mixtral—最大 32B
• どのパターンか？チャット API、RAG、エージェント型ワークフロー—すべて 1 台の GPU 上で実行
• 使用する場面：開発、社内ツール、初期段階の製品、中程度の同時実行数 自分で試す + リファレンスアーキテクチャ
• Amazon EC2 p5.4xlarge を起動し、vLLM/TensorRT-LLM でデプロイ
• 独自のレイテンシー、スループット、コスト削減効果を測定