推奨マシンスペック

InfiniCloud AI ハードウェア選定ガイド

InfiniCloud AIは、小規模なコンピュータから複数の高性能GPUを搭載したサーバーまで、さまざまな規模のハードウェアで運用できるAIプラットフォームです。

特定のGPUや巨大なサーバーを必須とするのではなく、利用するAIモデル、利用者数、応答速度、データの取り扱い方針に合わせて、適切なコンピュータを選択できます。

例えば、小規模な部門で社内文書を検索・要約する用途であれば、24GBクラスのGPUと小型言語モデルから始められます。一方、高度な推論や多数の同時利用者を必要とする場合には、96GBクラスのGPUを複数搭載した構成や、H100、B200、B300などのデータセンター向けGPUを利用することで、より大規模なAI基盤を構築できます。

また、外部の大規模言語モデル（LLM）を利用し、社内のコンピュータでは文書検索、音声処理、補助モデルなどを実行する構成も選択できます。

InfiniCloud AIのハードウェア選定では、「どれほど大きなモデルを動かすか」と「何人が同時に利用するか」を分けて考えることが重要です。

InfiniCloud AI ハードウェア選定ガイド

図1：InfiniCloud AIのGPU構成と利用モデルの参考例。図中のモデルは構成例であり、GPU枚数の必須条件を示すものではありません。

1. ハードウェア選定の基本的な考え方

InfiniCloud AIの性能は、単純にCPUのコア数やGPUの演算性能だけで決まるものではありません。

主に、次の5つの条件によって決まります。

AIモデルの規模と種類
GPUメモリ（VRAM）の容量と帯域幅
同時に処理するAIリクエストの数
入力する文書や出力する回答の長さ
求められる応答速度と回答品質

例えば、パラメータ数が大きいモデルは、高度な推論や複雑な質問への対応で有利になることがあります。しかし、その分だけ多くのメモリと演算資源を消費し、1件の回答にかかる時間が長くなる場合があります。

逆に、小型モデルは必要なメモリが少なく、比較的短時間で回答できるため、同じハードウェアで多くの利用者に対応しやすくなります。

したがって、AIモデルは大きければよいというものではありません。

業務に必要な回答品質を満たす範囲で、できるだけ効率のよいモデルを選択することが、導入費用と運用性能の両面で重要です。

1.1 モデルの規模と同時利用者数は別の問題

AIシステムの性能は、次の2つに分けて考えます。

モデルの搭載能力: どれほど大きなモデルをGPUメモリ上に配置できるか。
リクエスト処理能力: 単位時間に何件のAIリクエストを処理でき、どれほどの応答時間を維持できるか。

GPUメモリが大きければ、大規模なモデルを搭載しやすくなります。しかし、大規模モデルを搭載できることと、多数の利用者に高速に回答できることは同じではありません。大きなモデルを1つ動かす構成と、小型モデルを複数動かす構成では、後者の方が多数の利用者を快適に処理できる場合があります。

2. ハードウェア構成の選び方

InfiniCloud AIでは、次のような構成が考えられます。

構成	GPU・メモリ容量の例	主な用途
外部LLM中心	GPUなし、またはL4 24GB	外部LLM連携、RAG、補助処理
小規模ローカルAI	L4 24GB ×1〜L40S 48GB x 1	24GBでは9B級などの小型モデル。 48GBでは30B前後のMoE量子化モデル。
標準ローカルAI	RTX PRO 6000 Blackwell 96GB ×1	30B前後のdenseモデルと30B前後のMoE量子化モデル。
複数モデル運用	RTX PRO 6000 Blackwell 96GB ×2	用途別モデル、負荷分散
大規模ローカルAI	RTX PRO 6000 Blackwell 96GB ×4	大規模量子化モデル、複数モデル
高性能推論サーバー	H100 80GB ×1～複数	高帯域HBM、FP8推論、高負荷運用
フロンティア級AI	B200 180GB ×8、B300 288GB ×8	超大規模MoE、超大規模推論基盤

上記は構成を選択するための参考例です。対応するモデルの種類、量子化形式、コンテキスト長、推論エンジンによって必要なGPU容量は変わります。

RTX PRO 6000 Blackwell 96GB ×2が100V電源の概ねの限界点です。RTX PRO 6000 Blackwell 96GB ×4になると、2x2系統の電源から供給する必要があります。

大規模ローカルAIモデルよりも上になると、フロンティアモデルに肉薄する性能が出始めます。一般に、4ヶ月でフロンティアモデルにオープンモデルが肉薄すると言われています。

また複数GPUのメモリ容量は、GPUを取り付けただけで単一の大きなメモリとして利用できるわけではありません。大規模モデルを分散配置する場合には、対応する推論エンジンとGPU間通信の設計が必要です。

3. GPUを搭載しない構成・小型GPUによる構成

3.1 外部LLMを中心に利用する場合

外部のLLM APIを利用する構成では、必ずしも高性能なGPUは必要ありません。

例えば、外部LLMに高度な推論や文章生成を任せ、InfiniCloud AIのコンピュータでは次の処理を担当させることができます。

社内文書の収集と検索
RAG（Retrieval-Augmented Generation：検索拡張生成）
AIエージェントの処理制御
利用者認証、アクセス制御
文書解析、音声認識
小型モデルによる文章分類や再順位付け

この構成では、外部モデルの処理能力を利用しながら、社内のAIシステムを比較的小さなハードウェアで運用できます。

ただし、外部LLMに送信する情報については、機密性、データ保存条件、APIの利用規約、通信障害時の対応などを確認する必要があります。

特にデータの法的扱いに気をつける必要があり、機密情報や個人情報を取り扱う場合には、外部モデルへ送信してよい情報の範囲を事前に定めてください。良く分からない場合は、国内のLMaaSを使うべきです。

3.2 NVIDIA L4（24GB）クラスでのローカルLLM利用

NVIDIA L4は、24GBのGPUメモリを備えた比較的小型・低消費電力のGPUです。RTX5090などの民生用GPUもこのぐらいのクラスになります。

24GBという容量は大規模モデルには不足することがありますが、小型モデルを適切に選択すれば、InfiniCloud AIのローカルLLMとして利用できます。

例えば、Qwen3.5-9Bのような9B級モデルは、FP8まで量子化することで24GBクラスのGPUにも搭載しやすくなります。

9Bモデルの重みだけを考えた場合、理論上の必要容量は次のようになります。

形式	モデル重みの概算容量
BF16 / FP16	約18GB
FP8 / INT8	約9GB
4bit量子化	約4.5GB

実際には、量子化の付加情報、推論エンジン、KVキャッシュ、入力コンテキストなどのために追加のメモリが必要になります。

そのため、24GBのGPUで9Bモデルを利用する場合、4bitまたは8bit量子化を選択し、コンテキスト長や同時リクエスト数を調整する運用が現実的です。

この構成は、少人数の部門利用、社内文書の検索、定型的な質問応答、PoC（概念実証）などに適しています。

一方、9B級モデルと大規模モデルでは、複雑な推論や難度の高い質問に対する回答品質に差が生じる可能性があります。導入前に実際の業務データで評価してください。

3.3 L4 GPUを補助モデル専用にする選択

L4クラスのGPUを、主たるLLMの実行に使用する必要はありません。主LLMには外部APIを使用し、L4では小型の判断モデル、Embedding、再順位付け、音声認識などを処理する構成も有効です。

例えば、次のように役割分担できます。

外部LLM: 高度な推論、長文生成、複雑な質問への回答
L4 GPU: 小型LLM、文書分類、Embedding、音声認識、再順位付け
CPU: 検索処理、API制御、文書管理、Tokenizer、AIエージェントの制御

このように役割を分担すると、比較的小さなコンピュータでも、高度なAI機能を提供できます。ただし、補助モデルも同時実行が増えればGPUメモリと演算資源を消費します。負荷に応じて一部をCPUに配置するか、GPUを追加してください。

4. RTX PRO 6000 Blackwellによる本格的なローカルAI

NVIDIA RTX PRO 6000 Blackwellシリーズは、96GBのGDDR7メモリを搭載した高性能GPUです。

96GBという大きなGPUメモリにより、27B～35B級のモデルを高精度な形式で運用したり、さらに大きなモデルを量子化して搭載したりすることが可能になります。

また、GPUメモリ帯域幅は約1.79TB/秒に達し、大規模言語モデルの推論に必要な大量の重みデータを高速に読み出せます。

4.1 GPU 1枚の構成

RTX PRO 6000 Blackwellを1枚搭載した構成は、社内でローカルAIを本格運用するための有力な選択肢です。

用途に応じ、次のようなモデルを検討できます。

Qwen3.5-27Bなどの27B級モデル
Qwen3.6-35B-A3BなどのMoEモデル
Gemma4などの中規模モデル
gpt-oss-20bなどの比較的小型なモデル
量子化した、より大規模なモデル

モデルの形式や実装によって、実際に必要なGPUメモリは異なります。

例えば27B級のDenseモデルであれば、BF16のモデル重みは約54GB、FP8なら約27GB、4bitでは約13.5GBとなります。96GBのGPUを利用すれば、モデルの実行に加え、KVキャッシュや複数リクエストの処理に使用するメモリも確保しやすくなります。ただし、96GBすべてをモデル重みに割り当ててしまうと、長文入力や複数利用者の処理に必要な余裕がなくなります。

傾向として、コーディングに使う場合は量子化をFP8程度に留める方が良いでしょう。InfiniCloud AIはユーザ毎にAPIキーの発行ができますが、これを利用してプロファイルを書くことで、codexやclaude codeのバックエンドとして利用できます。

また、InfiniCloud AIのEDTMモードのとき、writerとverifierは異なるトレーニングをしたモデルのほうが、より良い結果が出てくる傾向があります。傾向としてはPlannerは層が厚いdenseモデルの方が、問題の分解能力に優れている傾向もあります。

4.2 GPU 2枚の構成

RTX PRO 6000 Blackwellを2枚搭載すると、合計192GBのGPUメモリを利用できる構成になります。この場合、大きく2種類の運用方法があります。

方法A：異なるモデルをGPUごとに配置する

例えば、片方のGPUに高度な推論を担当するモデルを配置し、もう片方に高速な回答生成や文書処理を担当するモデルを配置します。

AIエージェントの役割ごとにモデルを使い分ける場合に適した構成です。

方法B：同じモデルをそれぞれのGPUに配置する

同じモデルを2つのGPUで独立して動かし、利用者からのリクエストを振り分ける方法です。

この場合は、モデルの規模を大きくするよりも、同時処理能力の増加を重視します。

ただし、GPU 2枚分の処理能力が常に完全に2倍になるわけではありません。リクエストの配分、CPUやネットワークの処理能力などによって変化します。

4.3 GPU 4枚の構成

96GBのGPUを4枚搭載すると、物理的なGPUメモリ容量は合計384GBとなります。

この規模では、複数のAIモデルを用途別に配置するほか、大規模な量子化モデルを複数GPUへ分散して搭載することも検討できます。

例えば、GLM-5.3-FlashやDeepSeek-V4.1-Flash-1017のような大型モデルを候補として評価する場合、4bit量子化、モデル分割、必要に応じたRAM退避などを組み合わせた構成で動作させることができます。

ただし、これらのモデルを実際に搭載できるかは、モデルの総パラメータ数、量子化形式、推論エンジンの実装、およびGPU間通信方式によって決まります。

RTX PRO 6000を4枚搭載した構成は、単にGPUメモリを増やすだけでなく、複数モデルの運用や負荷分散を柔軟に設計できる点に価値があります。

5. H100・B200・B300による高性能AIサーバー

より高速な推論や大規模モデルを必要とする場合には、HBM（High Bandwidth Memory）を搭載したデータセンター向けGPUが選択肢になります。

HBMは、GPUの演算装置に対して非常に高いメモリ帯域幅を提供する技術です。LLMでは、多数のパラメータを繰り返し参照するため、メモリ帯域幅が推論速度を左右する重要な要素になります。

GPU	GPUメモリ	メモリ帯域幅の目安
NVIDIA L4	24GB	300GB/秒
RTX PRO 6000 Blackwell	96GB	約1.79TB/秒
H100 SXM	80GB	約3.35TB/秒
B200 SXM	180GB	最大約8TB/秒
B300 SXM	288GB	最大約8TB/秒

これらは公称仕様値です。実際のLLM推論速度がメモリ帯域幅に比例するわけではありません。

5.1 NVIDIA H100

H100は、高速なHBMを搭載するデータセンター向けGPUです。

H100 SXMは80GBのGPUメモリと約3.35TB/秒のメモリ帯域幅を備え、FP8などを利用した高性能推論に適しています。GPUメモリ容量だけを見るとRTX PRO 6000 Blackwellの96GBより小さいものの、H100 SXMはメモリ帯域幅が大きく、適切に最適化されたモデルでは高い推論性能を発揮できます。

特に、同じモデルを多数のリクエストに対して実行する場合や、応答遅延を抑えた運用を求める場合に有力です。ただし、H100にはSXMやPCIeなどの構成があり、メモリ帯域幅やGPU間接続の仕様が異なります。導入する製品の仕様を確認してください。

5.2 NVIDIA B200

B200は、180GBのHBM3eを搭載し、最大約8TB/秒のメモリ帯域幅を備えています。

GPU単体でも大きなモデルを配置しやすく、複数GPUを高帯域のNVLink／NVSwitchで接続することで、より大規模なモデルの分散推論が可能になります。8基のB200を搭載したHGX構成では、合計1.44TBのGPUメモリが提供されます。

この規模になると、大型MoEモデルや複数の高性能モデルを組み合わせた推論基盤が現実的な検討対象になります。

5.3 NVIDIA B300とTrillion級モデル

B300は、GPU当たり288GBのHBM3eを搭載する、さらに大容量のGPUです。8基のB300を搭載した構成では、合計約2.3TBのGPUメモリを利用できます。

例えば、総パラメータ数2.4T（2兆4,000億）のモデルを単純に4bitで表現した場合、モデル重みだけで約1.2TBが必要になります。実際には量子化情報、KVキャッシュ、推論エンジンなどの追加メモリを必要としますが、約2.3TBのHBMを持つ構成では、こうしたTrillion級モデルのGPU常駐運用も検討できるようになります。

MoE（Mixture of Experts）モデルでは、すべてのパラメータを毎回の演算に使用するわけではありません。例えば、総パラメータ数2.4T、活性化パラメータ数95Bのモデルでは、1トークンの推論で使用される主な計算量は活性化される部分に大きく依存します。

ただし、利用される可能性のあるExpertの重みをGPUに常駐させるには、総パラメータ数に対応する容量が必要です。

大容量HBMと高速なGPU間通信の組み合わせにより、これまで外部APIでしか利用できなかった規模のモデルを、自社管理の計算基盤で運用するという選択肢が生まれます。

これは、機密情報の取り扱い、モデル選択の自由度、独自モデルの運用などの面でも、新たな可能性をもたらします。ただし、Trillion級モデルの実運用には、推論エンジンによるモデル対応、量子化品質、GPU間通信、消費電力、冷却などを含めた検証が必要です。

6. GPUメモリ容量と推論速度の関係

GPUを選定する際には、モデルを搭載できる容量だけでなく、推論時の性能にも注意してください。LLMの推論処理は、大きく次の2つに分けられます。

Prefill: 入力された文章や文書を処理し、回答生成を始めるまでの計算
Decode: 回答を1トークンずつ順番に生成する処理

Prefillでは、入力トークン数や計算性能が重要になります。

一方、Decodeでは、モデル重みの読み出しやメモリ帯域幅が性能を制約することがあります。

例えば、27BのDenseモデルをFP8で利用する場合、モデル重みは概算で27GBです。単一ストリームのDecode処理で、重みの読み出しだけが性能を制約すると仮定すると、メモリ帯域幅をモデル重み容量で割ることで、おおまかな処理能力の尺度を計算できます。

GPU	単純な帯域計算の例
RTX PRO 6000 Blackwell	1,792÷27 ≒ 66トークン/秒
H100 SXM	3,350÷27 ≒ 124トークン/秒
B200 SXM	8,000÷27 ≒ 296トークン/秒

この数値は単純計算であり、保証性能ではありません。

モデル重みの読み出しだけを仮定した概算であり、演算時間、キャッシュ、量子化方式、推論エンジン、バッチ処理などを考慮していません。実際には、この値を下回ることも、バッチ処理などでモデル重みを効率的に再利用して集計スループットが上回ることもあります。

大切なのは、同じメモリ容量でもGPUの帯域幅や演算特性によって応答速度が変わるという点です。

7. 同時利用者数と応答速度のトレードオフ

AIシステムでは、1人の利用者に対する応答速度が十分であっても、利用者が増えるにつれて応答待ち時間が長くなることがあります。これは、AIからの回答を生成する処理に一定の時間が必要であり、リクエストの到着頻度が処理能力に近づくと待ち行列が形成されるためです。

7.1 M/M/c待ち行列モデルによる考え方

同時利用者数とGPU処理能力の関係を理解するために、待ち行列理論のM/M/cモデルを利用できます。

M/M/cモデルでは、リクエストの到着をポアソン過程、処理時間を指数分布、処理設備をc個と仮定します。

次の記号を使用します。

λ（ラムダ）: 単位時間当たりに到着するリクエスト数
μ（ミュー）: 1つの処理設備が単位時間当たりに処理できる平均リクエスト数
c: 並列にリクエストを処理できる設備数
ρ（ロー）: 設備全体の平均利用率

設備全体の平均利用率は、次の式で表せます。

ρ = λ / (c × μ)

安定して処理を続けるためには、基本的に次の条件が必要です。

ρ < 1

ただし、ρが1未満であれば応答速度が十分というわけではありません。

ρが1に近づくと、待ち行列が急激に増大し、利用者の待ち時間が長くなる可能性があります。LLMでは、長い文章の生成や高度な推論に時間がかかるため、1つの処理系が単位時間に処理できるリクエスト数μが小さくなりがちです。また、実際のLLMの処理時間は、入力文章の長さ、出力トークン数、推論の複雑さによって大きく変動します。

したがって、実環境では処理時間を指数分布と仮定したM/M/cモデルだけでは十分に表現できず、M/G/cやG/G/c、あるいは実測に基づくシミュレーションが必要になる場合があります。

M/M/cは、性能設計の基本的な傾向を理解するための近似モデルとして利用してください。

7.2 利用者が増えると何が起こるか

例えば、1つの独立した推論処理系が、平均20秒で1件のリクエストを処理できるとします。この場合、1分間の平均処理能力は3件です。

ここに毎分4件のリクエストが到着すると、処理能力を超えるため、1つの処理系では待ち行列が増加し続けます。同じ処理系を2つ用意すると、合計処理能力は毎分6件となり、理論上は安定した処理が可能になります。

しかし、M/M/cモデルで計算すると、平均待ち時間は約16秒、処理時間を含む平均応答時間は約36秒になります。処理系を3つに増やした場合、平均待ち時間は約2.2秒、平均応答時間は約22.2秒まで短縮します。

構成	平均設備利用率	平均応答時間の理論例
1処理系	133%	処理能力不足・不安定
2処理系	約67%	約36秒
3処理系	約44%	約22秒

この例では、1つの独立した処理系が同時に1件を扱うと仮定しています。

実際のLLM推論エンジンでは、Continuous Batchingによって1つのGPU上でも複数リクエストを同時に進行させることができます。そのため、GPU枚数がそのままcに一致するわけではありません。

推論エンジンのバッチ効率と、負荷が増えた際の実測処理能力に基づいて判断してください。

7.3 多人数で利用するための3つの方法

同じハードウェアでより多くの利用者に対応するには、主に次の方法があります。

方法1：モデルを小さくする

27Bモデルを9Bモデルに変更すると、モデル重みの読み出し量や演算量を減らせるため、応答時間と同時処理性能が改善する可能性があります。ただし、モデルを小さくすると回答品質が低下する場合があります。業務に必要な品質を満たすことが前提です。

方法2：量子化によってモデルを軽量化する

BF16、FP8、INT8、4bitなどから適切な形式を選択することで、GPUメモリの使用量を削減できます。推論エンジンとGPUが適切な量子化演算に対応していれば、推論速度の改善も期待できます。ただし、量子化によって必ず高速になるわけではなく、品質への影響もモデルごとに評価する必要があります。また、9Bなどでは4bitにすることで、function callingのためのjsonが崩れたりすることもあります。

方法3：GPUを増やす

複数GPUに同じモデルを配置し、リクエストを分散することで、システム全体の処理能力を増やします。この場合、モデルを小さくせずに回答品質を維持しながら、対応可能な同時リクエスト数を増やせる可能性があります。一方、GPUの追加には導入費用、電力、冷却、保守などのコストが発生します。

モデルを小さくして処理速度を高めるか、GPUを増やして回答品質と処理能力を両立させるかが、システム設計上の重要な判断になります。

7.4 同時利用者数と同時リクエスト数は異なる

例えば100人の社員がInfiniCloud AIを利用していても、100人全員が常時AIに回答を生成させているわけではありません。

利用者は、質問を入力したり、AIの回答を読んだり、ほかの業務を行ったりしています。そのため、必要なGPU処理能力は、登録利用者数だけでなく、実際に到着するリクエスト数によって決まります。

一方、始業直後、会議中、社内システムからの一括処理などでは、短時間に多数のリクエストが集中する場合があります。また、Agentic AIでは1件の利用者からの質問に対し、複数の内部LLM呼び出しが発生することがあります。

したがって、システム管理者は利用者数に加え、ピーク時のリクエスト数、内部モデル呼び出し回数、平均処理時間を把握する必要があります。

8. GPUを増やす場合の構成方法

複数のGPUを搭載する場合、どのようにGPUを利用するかによって性能特性が異なります。

8.1 モデルを分割する（Tensor Parallelismなど）

1つの大きなモデルを複数GPUへ分散配置する方法です。例えば、1枚のGPUには搭載できないモデルを、2枚または4枚のGPUへ分散することで実行可能にします。

InfiniCloud AIでは1枚のGPUに入らないサイズのモデルを選択したとき、自動的にこの機能が使われます。

この方法では、GPU間で演算結果を交換するため、通信性能が重要になります。PCI Expressで接続したGPU間の通信性能は、同一GPU内のメモリ帯域幅より低くなります。そのため、GPU枚数を増やしても、単一リクエストの処理速度が比例して向上するとは限りません。

特に、大規模なモデルを高速に分散実行する場合には、NVLinkやNVSwitchを備えた構成が有利になることがあります。

8.2 同じモデルを複製する（Data Parallelism）

GPUごとに同じモデルを配置し、異なるリクエストを独立して処理する方法です。例えば、27Bモデルを4枚のGPUにそれぞれ配置し、ロードバランサーで利用者のリクエストを振り分けることができます。

InfiniCloud AIでは同じモデルのInstance数をふやすことで、自動的にこの機能が使われます。

この方法は、大規模モデルを1つ動かすよりも、同じモデルへの多数のリクエストを処理したい場合に適しています。利用者数の増加に応じてGPUやサーバーを追加しやすく、段階的な拡張にも向いています。

8.3 用途別にモデルを配置する

複数GPUを使用して、それぞれ異なるモデルを担当させる方法です。例えば、次のように分担できます。

GPU 1：高度な推論や検証
GPU 2：文章生成、一般的な質問応答
GPU 3：プログラム生成、専門業務モデル
GPU 4：追加モデル、予備能力、負荷集中時の処理

AIエージェントが質問の種類を判断し、適切なモデルへ処理を振り分けることで、GPUを効率的に利用できるようになります。ただし、役割の異なるモデルを多数配置すると、特定のGPUだけが混雑する場合があります。リクエストの分布を観測しながら配置を調整してください。

9. CPU・メモリ・ストレージの選定

GPUを中心に考えがちなAIシステムですが、CPU、ホストメモリ、ストレージの選定も重要です。InfiniCloud AIでは、ローカルLLM以外にも、文書解析、検索、認証、API処理、音声処理などの機能が動作します。

9.1 標準構成の目安

CE／ESでローカルLLMを本格利用する場合の参考構成は次のとおりです。

項目	標準的な参考構成
CPU	16コア以上
ホストメモリ	256GB以上
ストレージ	1TB以上のSSD、用途に応じて増設※
GPU	利用するモデルに応じて選択
ネットワーク	利用者数、外部API、GPUサーバー間通信に応じて設計

これはすべての構成で必須となる最小要件ではありません。外部LLM中心の構成や、小型モデルを使用する構成では、CPUやホストメモリを削減できる場合があります。

一方、複数の大型モデル、長文の文書解析、多人数での利用などを想定する場合は、より多くのCPUコアやホストメモリが必要になることがあります。

※ストレージに関しては、インストールするモデルサイズによって大きく異なります。たとえば220Bモデルは500GBぐらいのデータがあるため、インストールするだけで一気にストレージ容量が減ります。また、InfiniCloud AIは、ユーザ毎にストレージ領域を持ちます。ストレージは80％を超えるとアップロードはできなくなりますが、AIをなるべく賢く利用する手段として、ゴミの残るNASを直接繋げず、選別したデータをきちんと知能ドメインのストレージ領域にアップロードしておくことで、結果の品質がかなり変わります。元となるデータファイルのサイズが大きいほど、ストレージは容量は必要になります。

9.2 CPUはAIの周辺処理を担当する

CPUは、主に次のような処理を担当します。

API、Webサービス、認証処理
AIエージェントのワークフロー制御
文書の解析、分割、検索
Tokenizerなどの前処理
GPUに投入するデータの準備
GPUからの処理結果の管理

GPUが高速でも、CPUによる前処理が遅いとシステム全体の性能が低下します。音声認識、文書の大量取り込み、再順位付けなどをCPUで処理する場合には、特に注意してください。(幾つかの処理はGPUにオフローディングできます。GPUメモリにあまりがある場合は設定することも可能です。config.default.iniを参照し、config.iniを書き替えてください)

9.3 ホストメモリの重要性

ホストメモリは、GPUに搭載できないモデル重みの退避先や、文書処理、検索インデックス、キャッシュなどに利用されます。モデルの一部をホストメモリに置くRAM Offloadingを利用すると、GPUメモリ容量を超えるモデルを実行できる場合があります。

ただし、ホストメモリとGPU間の転送速度は、GPU内のメモリ帯域幅に比べて大幅に低くなります。そのため、RAM Offloadingを利用すると、モデルの搭載可能容量は増えても、推論速度が大きく低下する可能性があります。

RAM Offloadingは、大きなモデルを動かすための選択肢ですが、多人数への高速な応答を目的とする場合には、GPUメモリへ常駐させる構成を優先してください。

9.4 ストレージ

AIモデルの保存には、モデルサイズに応じて数GBから数百GB、あるいはそれ以上のストレージが必要になります。また、同じモデルでも複数の量子化形式を保持すると、その分だけ容量を消費します。

標準構成では1TB以上を参考としていますが、複数モデルや大量の文書を扱う場合には2TB～4TB以上のNVMe SSDも検討してください。大規模モデルを複数保存する場合や、モデルの一時展開、更新前のバックアップを行う場合には、さらに容量が必要になることがあります。

10. 用途別の構成例

10.1 少人数の部門でAIを導入したい

推奨例：L4 24GB ×1、小型量子化モデル

社内文書の検索、FAQ、簡単な文章作成などであれば、9B級の量子化モデルから始める方法があります。導入費用と消費電力を抑えやすい一方、大型モデルと比べて回答品質や長文推論に制約が生じる場合があります。

高度な推論だけ外部LLMへ振り分ける構成も検討できます。

10.2 社内文書を外部へ送信せずにAIを利用したい

推奨例：RTX PRO 6000 Blackwell 96GB ×1

27B～35B級を中心としたモデルをローカルに配置し、RAGと組み合わせる構成です。社内データを外部LLMへ送信しない運用を実現しやすくなります。

ただし、システムのログ、更新、監視、外部サービス連携なども含めて、情報の送信経路を確認する必要があります。

10.3 高度な推論と高速な応答を使い分けたい

推奨例：RTX PRO 6000 Blackwell 96GB ×2

高度な推論を担当するモデルと、高速な応答生成を担当するモデルを分離します。すべての質問を大型モデルで処理するのではなく、問題の難度や業務内容に応じてモデルを選択します。

これにより、回答品質を確保しながら、全体の処理時間を抑えられる場合があります。

10.4 多数の社員が同じAIモデルを利用する

推奨例：RTX PRO 6000 Blackwellを複数枚、またはH100などの高性能GPU

同じモデルを複数GPU上で独立して動かし、リクエストを分散する方法を検討してください。同時利用者数の増加に対応する際には、単にモデルを大きくするよりも、GPUの処理系を増やす方が有効な場合があります。

応答時間、リクエスト到着頻度、GPU利用率、待ち行列長を観測し、必要な設備数を決定してください。

10.5 数百B以上の大規模モデルを検討したい

推奨例：RTX PRO 6000 Blackwell ×4以上、またはHBM搭載GPU

量子化を利用し、複数GPUにモデルを分散配置する方法を検討します。大規模モデルでは、総パラメータ数だけでなく、活性化パラメータ数や推論時の通信量も重要です。

特にGPU間通信が頻繁に必要な場合は、PCIe接続とNVLink／NVSwitch接続で性能差が生じる可能性があります。

10.6 Trillion級モデルを自社管理のAI基盤で運用したい

推奨例：HGX B300 ×8などの大容量HBM構成

超大規模MoEモデルを量子化し、高帯域なGPU間接続を利用して推論する構成です。社内専用の高度なAI環境や、さまざまな専門モデルを組み合わせたAI基盤への発展が期待できます。

一方で、ハードウェア費用、電力、冷却、推論エンジンの対応状況などが重要になります。

導入前には、実際に運用するモデルを用いた性能検証が必要です。

11. システム管理者が確認すべき性能指標

InfiniCloud AIの構成を決定する際には、モデルが正常に起動することだけでなく、実際の業務を想定した負荷試験を行ってください。

主な確認項目は次のとおりです。

TTFT（Time To First Token）: リクエストから最初の回答トークンが生成されるまでの時間
ITL（Inter-Token Latency）: 回答生成中、隣り合うトークン間の生成間隔
総応答時間: リクエスト開始から回答完了までの時間
Throughput: システム全体で単位時間当たりに生成できるトークン数や完了リクエスト数
GPUメモリ使用量: モデル、KVキャッシュ、推論エンジンが使用するメモリ容量
待ち行列長: 処理開始を待っているリクエスト数
同時実行数: 実際に処理中のリクエスト数

特に平均応答時間だけでなく、95パーセンタイル（P95）や99パーセンタイル（P99）の応答時間を確認することが重要です。

平均応答時間が良好でも、一部の利用者が長時間待たされる構成では、業務上の使い勝手が悪くなることがあります。

11.1 負荷試験の進め方

実際の業務に使用するAIモデルを決定する。
入力文章の長さと出力トークン数を想定する。
1件のリクエストに対する応答時間を測定する。
同時リクエスト数を段階的に増やす。
応答時間、スループット、GPUメモリ使用量を測定する。
長文入力や複雑な推論を含む負荷試験を行う。
目標とする応答時間を維持できるリクエスト数を確認する。
必要に応じてモデル、量子化形式、GPU枚数を再検討する。

試験では、利用者の質問を模した単純なリクエストだけでなく、RAGによる文書検索や、Agentic AIの複数回のモデル呼び出しを含めてください。

また、推論エンジンが備えるContinuous Batching、KVキャッシュ管理、Prefix Cachingなどの最適化機能も、モデルと環境に応じて評価してください。

12. よくある質問

Q. GPUメモリが大きいほどAIは速くなりますか？

必ずしもそうではありません。GPUメモリ容量は、主に搭載できるモデルの規模やKVキャッシュ容量に影響します。推論速度には、メモリ帯域幅、GPUの演算性能、モデル構造、量子化形式、推論エンジンなども関係します。

Q. 24GBのGPUでもInfiniCloud AIは利用できますか？

はい。利用するモデルや構成によります。例えば、9B級の小型モデルを4bitなどに量子化することで、24GBクラスのGPUでローカルLLMを利用する構成が考えられます。また、主LLMを外部APIで実行し、GPUを補助モデル専用にする方法もあります。

Q. GPUを2枚にすれば、応答速度も2倍になりますか？

必ずしも2倍にはなりません。1つのモデルを2枚に分割して動かす場合は、GPU間通信が必要です。一方、同じモデルを2枚のGPUに独立して配置する場合は、システム全体の同時処理能力を高めやすくなります。

Q. 96GBのGPUを4枚搭載すると、384GBのモデルを動かせますか？

4枚のGPUの物理メモリ合計は384GBですが、その容量を1つのモデルで自動的に利用できるわけではありません。モデル分割に対応する推論エンジンが必要です。また、モデル重み以外にもメモリが必要になるため、384GBのモデル重みをそのまま搭載できるわけではありません。

Q. 利用者が増えたら、モデルを小さくするべきですか？

回答品質を維持できる場合には、有力な方法です。モデルを小さくすると処理時間が短縮し、同じGPUでより多くのリクエストを処理できる可能性があります。ただし、回答品質の低下が許容できない場合は、GPUを追加してモデルを複製する構成を検討してください。

Q. ホストメモリを増やせばGPUを減らせますか？

モデルの一部をRAMに退避することで、GPUメモリが不足する場合でも実行できることがあります。ただし、GPUとRAM間の通信がボトルネックとなるため、推論速度は低下する可能性があります。利用者が多く、応答速度が重要な場合は、GPUメモリへモデルを常駐させることを優先してください。

Q. コンテキスト長を長くすると、なぜ性能が低下するのですか？

入力トークンが増えるとPrefill処理の計算量が増加します。また、同時に処理するリクエストのコンテキストが長くなると、KVキャッシュのメモリ使用量が増え、同時処理能力を圧迫する場合があります。したがって、モデルが非常に長いコンテキストに対応していても、すべてのリクエストで最大長を使用することは推奨されません。RAGを利用する場合は、検索精度を高め、必要な文書だけをモデルへ渡すことも重要です。

13. まとめ：小さく始め、必要に応じて拡張する

InfiniCloud AIは、特定のGPU構成を前提とせず、用途に応じて段階的に拡張できるAIプラットフォームです。

小型GPUと小型言語モデルによるスモールスタートから、96GBクラスのGPUを用いた本格的なローカルAI、複数GPUによる高並列処理、HBMを搭載したフロンティアクラスのTrillion級モデルの運用まで、幅広い構成を検討できます。

ハードウェアを選定する際には、次の3つの判断が基本となります。

必要な回答品質を満たすAIモデルを選ぶ。
そのモデルを適切な速度で動かせるGPUを選ぶ。
利用者数とリクエスト量に応じて、並列処理能力を設計する。

最初から最大のハードウェアを導入する必要はありません。

一方で、モデルの高度化や利用者数の増加に応じて、より大きなGPUメモリ、高いメモリ帯域幅、複数GPU構成が必要になることがあります。

InfiniCloud AIでは、モデルの高度化と利用者数の増加を別々の拡張軸として捉え、回答品質・応答速度・導入費用のバランスを取りながら、AI基盤を成長させていくことを推奨します。