BLOG

前回の記事では、NVIDIAの「DGX Spark」について、ハードウェアスペックや公称スペックを整理し、ローカル環境でどの程度の規模のLLMを扱える可能性があるのかを確認しました。

DGX Sparkは、デスクトップサイズながら、大規模AIモデルの推論やfine-tuning、AIアプリケーションのプロトタイピングを手元で行えるAI開発基盤です。クラウドAPIに依存せず、自社環境やローカルネットワーク内でLLMを動かせるため、機密情報を扱う業務や社内向けAIアプリケーションの検証にも活用しやすい構成です。

一方で、スペック表に記載された対応モデルサイズだけでは、実際の使いやすさまでは分かりません。モデルが起動できても、応答が返ってくるまでの時間や生成速度、メモリ使用量によって、業務での使いやすさは大きく変わります。

そこで本記事では、DGX Spark上で複数のLLMを実際に動かし、生成速度、初回応答時間、全文生成時間、メモリ使用量などを確認します。モデルの回答品質や精度を比較するのではなく、ローカルLLMを運用する際に確認すべき実測値を整理することを目的とします。あわせて、クラウドAPI利用時の体感速度との違いを確認するため、Gemini APIの測定結果も参考値として扱います。

💡DGX Sparkを活用して、セキュアなローカルLLM環境を構築したい企業様へ
Athena Technologiesでは、DGX Sparkを活用したローカルLLM環境の導入支援を行っています。
企業ごとのセキュリティ要件や利用目的に合わせて、外部にデータを送らずにLLMを活用できる環境づくりを行います。チャット画面や社内向けAIアプリからLLMを使えるようにする仕組みづくりに加え、LLMを安定して動かすための環境整備や、より大きなモデルを扱うための構成検討まで、実際の業務利用を見据えて対応します。
機密情報を外部サービスに送信せず、自社環境で安全に生成AIを活用したい企業様は、ぜひAthena TechnologiesのDGX Spark導入支援をご検討ください。
⇨Athena TechnologiesのDGX Spark導入支援について詳しくはこちら

この記事でわかること

• DGX Spark上でローカルLLMを動かしたときに実測値を見るべき理由
• LLM運用時に確認すべき主な数値指標
• 検証に使用するモデルの特徴
• モデルサイズやモデル構造による応答速度・メモリ使用量の違い
• クラウドAPI利用時の体感速度との違い
• 「モデルが起動できること」と「快適に使えること」の違い

実測値を見る理由

前回の記事では、DGX Sparkのハードウェアスペックや公称スペックを整理し、単体構成で最大200Bパラメータ級モデル、2台構成で最大405Bパラメータ級モデルに対応するとされていることを確認しました。

ただし、これらの公称値は対応可能なモデルサイズや理論性能の目安であり、実際の使いやすさをそのまま示すものではありません。LLMを業務で利用する場合は、モデルが起動できることと、快適に使えることを分けて考える必要があります。たとえば、モデルを読み込めたとしても、最初の応答が返るまでに時間がかかったり、文章の生成速度が遅かったりすると、チャット用途や社内向けAIアプリケーションでは使いにくく感じられます。また、モデルサイズが大きくなるほどメモリ使用量も増えやすく、入力文が長くなると応答時間にも影響します。

そのため今回はDGX Spark上で実際にLLMを動かし、応答速度やメモリ使用量を確認することで、公称スペックだけでは分かりにくいローカルLLM運用時の使いやすさを見ていきます。

使用モデル

今回の検証では、DGX Spark上で動かすローカルLLMとして、Qwen3.5-2B、Qwen3.6-27B、Qwen3.6-35B-A3Bの3種類を使用します。また、クラウドAPI利用時の体感速度との違いを確認するため、参考比較としてGemini 2.5 Flashも測定します。

Qwen3.5-2B

Qwen3.5-2Bは、今回の検証における小型モデルとして使用します。

DGX SparkのようなローカルLLM環境を評価する際、いきなり大きなモデルだけを見ると、どの程度の負荷がDGX Sparkにとって重いのか判断しにくくなります。そこで、まずは比較的軽量なモデルを動かし、応答速度やメモリ使用量の基準となる値を確認します。

この基準があることで、後述のQwen3.6-27BやQwen3.6-35B-A3Bの結果を見たときに、モデルサイズや構造の違いによって生成速度やメモリ使用量がどのように変化するのかを比較しやすくなります。

Qwen3.6-27B

Qwen3.6-27Bは、27Bパラメータのdenseモデルです。

denseモデルは、推論時にモデル全体を使って計算する一般的な構成です。パラメータ数が大きくなると、計算量やメモリ使用量も増えやすくなります。

このモデルを使うことで、DGX Spark上で実用的な大きめのdenseモデルを動かした場合に、応答速度やメモリ使用量がどの程度になるのかを確認します。

Qwen3.6-35B-A3B

Qwen3.6-35B-A3Bは、総パラメータ数35BのMoEモデルです。

MoEモデルは、推論時にすべてのパラメータを同時に使うのではなく、入力に応じて一部のパラメータを使って計算する構成です。そのため、総パラメータ数だけを見ると大きなモデルに見えても、実際の計算負荷はdenseモデルとは異なる場合があります。

このモデルを使うことで、35Bという総パラメータ数に対して、実際の応答速度やメモリ使用量がどのように出るのかを確認します。

Gemini 2.5 Flash

Gemini 2.5 Flashは、クラウドAPIとの参考比較用に使用します。

今回の主な検証対象はDGX Spark上で動かすローカルLLMですが、クラウドAPIを使った場合の体感速度と比較するため、同じ入力プロンプトをGemini APIにも送信して測定しました。

本記事では、Gemini 2.5 Flashの結果をローカルLLMとのモデル単体の性能比較ではなく、クラウドAPI利用時の参考値として扱います。

3つのローカルLLMを比較する目的

今回、3つのローカルLLMを比較する目的は、モデルサイズだけでなく、モデル構造の違いがDGX Spark上での動作にどのように影響するかを見ることです。

Qwen3.5-2Bでは、比較的軽量なLLMを動かしたときの基準値を確認します。Qwen3.6-27Bでは、大きめのdenseモデルを動かした場合の応答速度やメモリ使用量を確認します。Qwen3.6-35B-A3Bでは、MoEモデルの実行時の特徴を確認します。

これにより、単にパラメータ数が大きいか小さいかだけでなく、denseモデルとMoEモデルの違いが、生成速度やメモリ使用量にどのように表れるのかを確認します。

確認すべき指標

ここでは、DGX Spark上でローカルLLMを動かしたときの実用性を確認するために、どのような指標を見るのかを整理します。

特に確認する指標は、1秒あたりの生成トークン数、最初のトークンが返されるまでの時間、全文生成までにかかる時間、メモリ使用量の4つです。なお、メモリ使用量はDGX Spark上で実行したローカルLLMのみを対象とし、クラウドAPIとの比較では応答速度に関する指標を確認します。

1秒あたりの生成トークン数

1秒あたりの生成トークン数は、LLMが1秒間にどれくらいの速度で文章を生成できるかを示す指標です。一般的には、この値が大きいほど回答生成が速く、ユーザーにとって快適に感じられます。

チャットのようにリアルタイム性が求められる用途では、生成速度が遅いと回答を待つ時間が長くなります。また、要約やレポート作成のように長めの文章を出力する用途でも、生成速度は全体の作業時間に影響します。

そのため、1秒あたりの生成トークン数は、ローカルLLMを実際に使う際の快適さを判断するうえで重要な指標になります。

最初のトークンが返されるまでの時間

最初のトークンが返されるまでの時間は、入力を送ってから最初の応答が表示されるまでの待ち時間です。

この時間が長いと、たとえその後の生成速度が速くても、ユーザーには「反応が遅い」と感じられやすくなります。特にチャット用途では、最初の応答がすぐに返ってくるかどうかが体感速度に大きく関わります。

全文生成までにかかる時間

全文生成までにかかる時間は、入力を送ってから回答がすべて出力されるまでの時間です。

短いチャットでは最初の応答速度が重視されますが、要約、文章作成、レポート生成などでは、最終的な出力が完了するまでの時間も重要になります。同じモデルでも、出力する文章が長くなるほど、全文生成までにかかる時間は増えます。

メモリ使用量

メモリ使用量は、モデルを安定して動かせるかを判断するうえで重要な指標です。

LLMを動かす際には、モデルの重みだけでなく、推論時に利用される*KVキャッシュや、推論エンジンが使用する領域もメモリ上に確保されます。そのため、モデルが起動できたとしても、メモリに余裕が少ない場合は、長い入力や複数リクエストを扱う際に制約が出る可能性があります。

今回の検証では、各モデルを起動した際にモデル本体の読み込みにどれだけメモリを使うか、KVキャッシュにどれだけの領域を確保できるかを確認します。これにより、単にモデルが動くかどうかだけでなく、実運用に向けてどの程度の余裕があるかを判断しやすくなります。

*KVキャッシュ：LLMが文章を生成する際に、過去のトークンの計算結果を保持しておくための領域。長い入力や複数リクエストを扱う際のメモリ使用量に関係する。

実験設定

今回の検証では、推論環境としてvLLMを使用し、3種類のローカルLLMをDGX Spark上で1つずつ起動して測定しました。

vLLMは、LLMを効率よく推論するための推論エンジンです。生成中に利用されるKVキャッシュの管理や、リクエスト処理の効率化を行うことで、ローカル環境やサーバー上でLLMを動かしやすくします。

また、ローカルLLMの結果をクラウドAPI利用時の体感速度と比較するため、参考値としてGemini APIでも同じ入力プロンプトを用いて測定しました。

モデルごとの差を比較しやすくするため、最大入力長、vLLMのメモリ利用設定、最大出力トークン数などは共通にしました。また、本検証ではユーザーに返す最終回答の速度を比較することを目的としているため、**thinkingを無効化し、最終回答のみを出力する条件で測定しています。

**thinking：モデルが最終回答を出す前に推論過程を生成する機能。

ローカルLLMの測定条件

***vLLMのメモリ利用率：vLLMがモデル本体やKVキャッシュなどのために、利用可能なメモリのうちどの程度を確保するかを調整する設定。本記事では、vLLM上で確保されたメモリ量として扱う。

クラウドLLMの測定条件

入力プロンプトは、社内でローカルLLMを活用する場面を想定して作成した検証用の文章です。短めの文章では簡潔な依頼のみを与え、中程度の文章ではクラウドAPI利用時の懸念を含めた背景説明を加え、長めの文章ではローカルLLM活用の背景や運用上の注意点を含めた文章を与えました。

なお、上記の入力トークン数はローカルLLM側の測定で使用した値です。Gemini APIではAPI側のtokenizerに基づいてトークン数が計算されるため、ローカルLLM側のトークン数とは完全には一致しません。

メモリ使用量については、ローカルLLMのみを対象に、vLLM全体のGPUメモリ使用量、モデル本体の読み込みに使われたメモリ、KVキャッシュに使える領域を分けて確認します。クラウドAPIでは利用者側からGPUメモリ使用量を確認できないため、Gemini APIとの比較では、1秒あたりの生成トークン数、最初のトークンが返されるまでの時間、全文生成までにかかる時間を確認します。

実測結果と考察

ここでは、Qwen3.5-2B、Qwen3.6-27B、Qwen3.6-35B-A3Bの3モデルをDGX Spark上で実行した結果を整理します。各モデルに対して、短め・中程度・長めの3種類の入力プロンプトを与え、それぞれ5回ずつ測定しました。

また、クラウドAPI利用時の体感速度と比較するため、参考値としてGemini APIでも同じ入力プロンプトを用いて測定しました。クラウドAPIの応答時間には、モデルの処理時間だけでなく、インターネット経由の通信時間も含まれます。そのため、Gemini APIの結果はモデル単体の性能比較ではなく、クラウドAPI利用時の参考値として扱います。

応答速度の比較

まず、応答速度に関する結果を確認します。以下のグラフは、各プロンプトに対する平均値です。なお、全文生成時間は入力を送信してから回答がすべて出力されるまでの時間を表しており、出力トークン数によっても変化します。

平均生成速度（tokens/sec）

※平均生成速度は、各モデルで出力されたトークン数を、入力を送信してから回答がすべて出力されるまでの時間で割って算出しています。Gemini 2.5 Flashの値には、モデルの処理時間だけでなく、インターネット経由の通信にかかる時間も含まれます。また、出力トークン数はGemini API側の計算に基づくため、ローカルLLMのトークン数と完全に同じ条件ではありません。

平均生成速度を見ると、Gemini 2.5 Flashは約96〜100 tokens/secと非常に高速で、クラウドAPI利用時の生成速度の高さが確認できます。一方で、DGX Spark上のローカルLLMでも、Qwen3.5-2Bは約43 tokens/sec、Qwen3.6-35B-A3Bは約31 tokens/secとなっており、用途によっては十分実用的な速度が出ています。ただし、Qwen3.6-27Bのようなdenseモデルでは約4.4 tokens/secにとどまり、チャット用途では待ち時間が気になりやすい結果となりました。

最初のトークンが返されるまでの時間（TTFT：Time To First Token）

TTFTを見ると、Gemini 2.5 Flashも1秒未満で最初の応答が返っており、クラウドAPI利用時でも十分に短い応答時間です。一方で、DGX Spark上のローカルLLMではQwen3.5-2Bが約0.05秒と非常に短く、Qwen3.6-35B-A3Bも比較的速く最初のトークンを返しています。平均生成速度ではクラウドLLMが優位でしたが、最初のトークンが返されるまでの時間という観点では、ローカルLLMにも強みがあることが分かります。

全文生成にかかった時間

全文生成時間を見ると、Gemini 2.5 Flashはどの入力プロンプトでも約2秒以内に収まっており、クラウドAPI利用時の応答完了までの時間は非常に短い結果となりました。DGX Spark上のローカルLLMでは、Qwen3.5-2Bが約3秒前後、Qwen3.6-35B-A3Bが約6秒前後で生成を完了しており、用途によっては十分実用的な範囲です。一方で、Qwen3.6-27Bは30秒以上かかっており、出力トークン数が極端に多いわけではないことを踏まえると、対話用途では待ち時間が課題になりやすい結果となりました。

メモリ使用量の比較

次に、各モデルを起動した際のメモリ使用量を確認します。

今回の検証では、各モデルを起動した時点でモデル本体がどれだけメモリを使うか、推論時に使うKVキャッシュ用の領域をどれだけ確保できるかを確認しました。

vLLM（LLMを効率よく推論するための推論エンジン）では、モデル本体に加えて、生成中に利用するKVキャッシュや推論を効率化するための実行用領域もメモリ上に確保されます。そのため、vLLM全体のメモリ使用量だけでなく、モデル本体の読み込みに使われたメモリと、KVキャッシュに使える領域を分けて確認します。

※KVキャッシュ容量は、モデル構造によって1トークンあたりに必要なメモリ量が異なるため、KVキャッシュ領域のGiBの大小と単純には一致しません。

このグラフでは、vLLM全体のメモリ使用量を、モデル本体メモリ、KVキャッシュ領域、その他実行用領域に分けて示しています。モデル本体メモリは、モデルの重みを読み込むために使われたメモリ量です。KVキャッシュ領域は、生成中に過去のトークンの計算結果を保持するために使えるメモリ領域です。KVキャッシュ容量は、その領域で保持できるトークン数の目安です。

vLLM全体のメモリ使用量を見ると、3モデルとも約78〜81GiBで近い値になっています。これは、同じvLLMのメモリ利用率設定で起動しているためです。そのため、vLLM全体のメモリ使用量だけを見ると、モデルごとの差は分かりにくくなります。

一方で、内訳を見ると大きな違いがあります。Qwen3.5-2Bでは、モデル本体メモリは4.25GiBにとどまり、KVキャッシュ領域として74.07GiBを確保できています。これに対して、Qwen3.6-27Bではモデル本体メモリが51.1GiB、Qwen3.6-35B-A3Bでは65.53GiBとなっています。同じvLLMのメモリ利用率設定で起動した場合、モデル本体に使われるメモリが大きいほど、KVキャッシュに使える領域は小さくなります。

特にQwen3.6-35B-A3BはMoEモデルですが、モデル全体の重みはメモリ上に配置されるため、モデル本体メモリは3モデルの中で最も大きくなりました。一方で、生成速度はQwen3.6-27Bより大幅に高速です。この結果から、MoEモデルは生成速度の面で有利に働く場合がある一方で、メモリ使用量まで小さくなるとは限らないことが分かります。

実測値から分かること

今回の結果から、DGX Spark上でローカルLLMを運用する際には、モデルが起動できるかだけでなく、実際の応答速度やメモリの内訳を確認することが重要だと分かります。

応答速度を見ると、クラウドAPIとして利用したGemini 2.5 Flashは非常に高速で、全文生成までの時間も短く収まりました。一方で、DGX Spark上のローカルLLMでも、Qwen3.5-2BやQwen3.6-35B-A3Bでは一定の生成速度が出ており、用途によっては十分実用的な範囲で動作することが確認できました。

Qwen3.6-27Bのような大きめのdenseモデルでは、生成速度が大きく低下し、全文生成にも時間がかかりました。モデルを起動できたとしても、チャット用途や対話的な業務利用では、待ち時間が課題になる可能性があります。

また、メモリ使用量を見ると、vLLM全体で確保されるメモリ量は3モデルで近い値になっている一方で、その内訳は大きく異なります。小型モデルではモデル本体のメモリ使用量が小さいため、KVキャッシュ領域を大きく確保できますが、大きなモデルではモデル本体のメモリ使用量が増え、KVキャッシュに使える領域は小さくなります。

特にMoEモデルであるQwen3.6-35B-A3Bは、生成速度の面ではQwen3.6-27Bより大幅に高速でしたが、モデル本体のメモリ使用量は大きくなりました。このことから、MoEモデルは速度面で有利に働く場合がある一方で、メモリ使用量まで小さくなるとは限らないことが分かります。

クラウドAPIは速度や手軽さの面で大きな利点がありますが、入力データを外部サービスに送信する必要があります。そのため、機密情報や社内文書を扱う場合は、応答速度だけでなく、データの取り扱いやセキュリティ要件も含めて判断する必要があります。

まとめ

本記事では、DGX Spark上で3種類のローカルLLMを動かし、応答速度やメモリ使用量を実測しました。また、クラウドAPI利用時の参考比較として、Gemini 2.5 Flashの測定結果も確認しました。

今回の検証では、平均生成速度、最初のトークンが返されるまでの時間、全文生成時間、モデル本体のメモリ使用量、KVキャッシュ領域などを確認しました。その結果、同じDGX Spark上で動かす場合でも、モデルサイズやモデル構造によって、生成速度やメモリの使われ方が大きく変わることが分かりました。

クラウドAPIとして利用したGemini 2.5 Flashは、生成速度や全文生成時間の面で非常に高速でした。一方で、DGX Spark上のローカルLLMでも、Qwen3.5-2BやQwen3.6-35B-A3Bでは一定の速度が出ており、用途によってはローカル環境でも実用的に利用できる可能性があります。

ローカルLLMを業務で利用する際は、モデルが起動できるかだけでなく、実際にどの程度の速度で応答できるか、メモリにどの程度の余裕があるかを確認することが重要です。特に、チャット用途では最初の応答速度や全文生成時間が体感に影響し、長文処理や複数リクエストを扱う場合はKVキャッシュ領域の余裕も重要になります。

クラウドAPIは速度や導入の手軽さに強みがありますが、入力データを外部サービスに送信する必要があります。一方で、DGX Spark上でローカルLLMを動かす場合は、クラウドAPIほど高速ではないケースがあるものの、データを社内環境に閉じたまま扱える点が大きな利点です。

そのため、DGX SparkでローカルLLMを運用する場合は、公称スペックだけで判断するのではなく、実際の利用シーンに合わせてモデルを動かし、速度、メモリ使用量、データ管理の要件を確認しながら、適したモデルや運用方法を選ぶことが重要です。