記事公開日
【小ネタ】NVIDIAテンソル並列処理機能でAIは速くなるのか？
LM Studioの高速化 後編
はじめに
今年（2026年）の6月1日に、NVIDIAがWindows向けの新SoCを発表しました。RTX Sparkという名前だそうで、CPUはMediaTek設計のARMベース、128GBのユニファイドメモリを搭載し、GPUは同社Blackwellアーキテクチャ1ペタFLOPS、CPUとGPU間のバスをNVLink C2Cでつなぐ・・・ とまあとにかく一般向けとしてはかなり高性能なWindows PCとなりそうなわけです。もちろん、値段もそれなりにするでしょうけど。
で、私が触れたいのはそこではありません。私が触れたいのは、上記発表の一日前にNVIDIAから発表された、Windows PC向けのある技術についてです。それは「テンソル並列処理機能（Tensor Parallelism）」です。これは、一台のPCに二台（枚）以上のグラフィックボードを搭載したときに、複数のグラフィックボードを効率良く使うための技術のことを指します。一般の方だと「それがなにか？」と聞こえるかもしれませんが、オンデバイスAI（ローカルLLM）界隈では結構インパクトの大きい技術なんです。ついに2枚挿しのグラフィックボードが活用できるわけですから。
というわけで、今回はそのインパクトが大きいかもしれない「テンソル並列処理機能」が、本当に効果があり、我々に恩恵を与えるものなのか？ということを検証していきたいと思います。後編の今回は検証結果を中心に紹介します。
テンソル並列処理機能の検証
検証の方法
テンソル並列処理機能の検証ですが、3種類のプロンプトを推論させて、その速度を測定するという方法にします。その3種類のプロンプトとは、
- プロンプト1. 英語の日本語翻訳
- 弊社（三技協）の英語ホームページの"Message From the Representative(代表挨拶)"から引用した文章を日本語訳させます
- 580単語（約4200文字）程度の英語の文章です
- インプットとアウトプットが同程度になります
- プロンプト2. 日本語文章の要約
- 今年6/30から連載していたブログ記事（30,000文字程度）を400字程度にまとめて貰います
- インプットが大きく、アウトプットが小さくなります
- 必要なコンテキストサイズも大きくなります
- プロンプト3. プログラミングコードの作成
- F#のコードを生成して貰います
- インプットが小さく、アウトプットが大きくなります
このインプットとアウトプットの大きさが異なる3種類のプロンプトによって速度を測定します。尚、同じモデル間での比較となるため、今回はアウトプットのクオリティは考慮しません。評価項目は以下の通りです。
評価は、次の3設定において行います。
- 評価1. シングルGPU
- GPU0だけを有効化
- モデルサイズによってはVRAMからあふれるため検証不可
- 評価2. パイプライン並列
- 2GPUで、GPU間でメモリ割り当てに「均等に分割」を選択
- 評価3. テンソル並列
- 2GPUで、GPU間でメモリ割り当てに「Tensor Parallelism」を選択
使用するハードウエアは以下の通りです。全く同じグラボRTX 5060Tiを2枚積んでいます。RTX 5060TiはVRAMの量に比べて価格が安いため、ゲーマーよりもオンデバイスAI勢に選ばれているグラボです。
- CPU: AMD Ryzen 7 7700X 8-Core
- メインメモリ: 32GB DDR5
- グラフィックボード: NVIDIA GeForce RTX 5060Ti × 2
- GPU: Blackwell
- VRAM: 16GB GDDR7
- 演算能力: 759 TOPS※2
グラボ2枚挿し
グラボステーが1つしかなくて、下段に仮支えが入っているのはご愛嬌
その他設定は以下の通りです。
- LM Studio 0.4.20 (Build1)
- CUDA 12 llama.cpp(Windows) v2.26.0
- コンテキストサイズ：24567 (評価2がなんとか入るサイズ)
- オフロード：VRAM限定
- KVキャッシュ：全てVRAM
LM Studioハードウエア設定画面
画面ではテンソル並列（Tensor parallelism）が選択されている
検証に使用したAIモデル
検証に使用したAIモデルと、それを選んだ意図を説明します。普段から使っているためラインナップがGoogle寄りですが、その辺はご容赦ください。
- LLaMa3.1 8B （Meta）
- 多くの方がベンチマーク的に使用しているLLaMa3系統のモデル
- Gemma4 E4B （Google）
- E4BはEffective 4Bの略で、7.6Bのパラメータを持つが4Bのサイズで動く
- 小型軽量モデルの検証用
- Qwen3.5 9B MTP （Alibaba）
- こちらもベンチマークによく使用されるため使用
- MTP対応もポイント
- Gemma3 12B （Google）
- 同じGemmaでもやや古いGemmaと差があるかの検証用
- Gemma4 26B A4B QAT （Google）
- MoEに対応しており、全体サイズ26Bでも実際に動くのは4Bというモデル
- 個人的に一番使っている
- MoEだけでなくQATにも対応という最新技術モデルでもある
- Gemma4 31B QAT （Google）
- 実験PCでギリギリVRAMに収まらない（オフロードする）サイズ
MTP/MoE/QATなどのAI技術については、以前書いたこちらのブログを読んで下さい。
各モデルの細かい情報は以下の通りです。
| モデル名 | アーキテクチャ | パラメータ | 開発 | 量子化 | サイズ | 備考 |
|---|---|---|---|---|---|---|
| meta-llama-3.1-8b-instruct | LLaMa3 | 8B | Meta | Q4 K S | 4.7GB | |
| gemma-4-e4b | Gemma4 | 7.6B | Q4 K S | 6.3GB | ||
| qwen3.5-9b-mtp | Qwen3.5 | 9B | Alibaba | Q4 K S | 7.4GB | MTP |
| gemma-3-12b | Gemma3 | 12B | Q4 K M | 8,2GB | ||
| gemma-4-26b-a4b-qat | Gemma4 | 26B-A4B | Q4 0 | 15.6GB | MoE、QAT | |
| gemma-4-31b-qat | Gemma | 31B | Q4 0 | 18.9GB | QAT |
これらのAIモデルを使って、テンソル並列処理機能がどれだけの効果を出すのか検証していきます。
検証結果
先に注釈を入れさせていただきます。
- Gemma4 26B A4B QATとGemma4 31Bの"Single CUP"の測定は、1つのVRAM(16GB)だとモデルがVRAMへ入りきりません。
- Gemma4 26Bはメインメモリにスワップさせることで動作しましたが、非常に遅いため出力速度は参考程度にご覧下さい
- Gemma4 31BはSingle CPUでは動作しませんでしたので、計測しておりません。
さて、検証結果ですが、ここは説明も無しに単純に貼っていますので、具体的数値に興味のない方は、次の章に飛んでください。
検証結果である計算速度は、AIでは一般的な評価指針である「トークン毎秒 [tokens/sec]」を使っています。もちろん、数字が大きい方が早いということになります。また、グラフは各モデルの評価2のパイプライン並列を100%とした場合、並列の違いによりどれぐらい高速化（低速化）したかを表しています。
プロンプト1（日本語訳）における出力速度
| Single GPU | パイプライン並列 | テンソル並列 | |
|---|---|---|---|
| Llama3.1 8B | 78.82 | 78.75 | 115.29 |
| Gemma4 E4B | 87.23 | 82.85 | 99.23 |
| Qwen3.5 9B MTP | 70.99 | 70.70 | 85.11 |
| Gemma3 12B | 45.62 | 45.40 | 63.18 |
| Gemma4 26B A4B QAT | 41.82 | 98.84 | 106.84 |
| Gemma4 31B QAT | NA | 19.90 | 32.17 |
単位:tokens/sec
プロンプト1（日本語訳）における出力速度
パイプライン並列を100%とした場合の割合
プロンプト2（長文要約）における出力速度
| シングルGPU | パイプライン並列 | テンソル並列 | |
|---|---|---|---|
| Llama3.1 8B | 56.02 | 55.22 | 86.93 |
| Gemma4 E4B | 80.42 | 75.82 | 93.87 |
| Qwen3.5 9B MTP | 74.85 | 75.08 | 96.34 |
| Gemma3 12B | 37.72 | 37.30 | 54.82 |
| Gemma4 26B A4B QAT | 24.40 | 84.39 | 96.94 |
| Gemma4 31B QAT | NA | 17.48 | 28.79 |
単位:tokens/sec
プロンプト2（長文要約）における出力速度
パイプライン並列を100%とした場合の割合
プロンプト3（コード生成）における出力速度
| シングルGPU | パイプライン並列 | テンソル並列 | |
|---|---|---|---|
| Llama3.1 8B | 81.95 | 80.94 | 116.89 |
| Gemma4 E4B | 89.72 | 82.44 | 100.29 |
| Qwen3.5 9B MTP | 66.82 | 63.86 | 77.11 |
| Gemma3 12B | 46.65 | 46.16 | 64.58 |
| Gemma4 26B A4B QAT | 44.95 | 106.88 | 110.45 |
| Gemma4 31B QAT | NA | 20.75 | 33.74 |
単位:tokens/sec
プロンプト3（コード生成）における出力速度
パイプライン並列を100%とした場合の割合
考察
どの結果からも、2つのことが分かります。
- （VRAMが足りている場合）パイプライン並列はシングルGPUよりもすこし遅くなる
- テンソル並列はパイプライン並列よりも確実に速くなる
1の方は僅かの差であることが多いですが、それでも確実にシングルGPUよりもパイプライン並列が遅くなるため、ハイエンドゲーム勢がマルチGPUを嫌がるのはよく分かります。 2の方も、すべての条件でテンソル並列の方が速くなったわけですが、上の結果だけだとどれぐらい速くなったのかが分かりにくいため、3つの結果の平均を出してみました。
| テンソル並列の 平均速度上昇率[%] |
計算上の パラメータ数 |
|
|---|---|---|
| Llama3.1 8B | 148.5 | 8B |
| Gemma4 E4B | 121.7 | 4B |
| Qwen3.5 9B MTP | 123.3 | 9B |
| Gemma3 12B | 141.7 | 12B |
| Gemma4 26B A4B QAT | 108.5 | 4B |
| Gemma4 31B QAT | 162.9 | 31B |
まず2の結果から言えることは、おおよそパラメータ数が多いほどテンソル並列の効果が高いということです。それを言うと、一番効果の低かったGemma4 26Bはどうなのか？と思われる方もいるかと思いますが、Gemma4 26BはMoE（Mixture of Experts）という技術を使っています。簡単に言えば「総パラメータ数は大きいが、各計算は必要な部分だけ取り出して行うため小さくて済む」というものです。つまり、計算自体は小パラメータ（4B）で行うので、おそらくテンソル並列の効果が低かったのでしょう。
結果的に、いずれのモデルにおいても計算は速くなったのですが、個人的に言えば思ったより速くないという印象です。NVIDIAによる最大1.8倍という触れ込みと比べてということもあるのですが、それだけではなくGPU利用率の上昇幅よりも実測値が速くなっていないという印象があるからです。
今回の検証試験は画面にはタスクマネージャーを表示させながら行っていました。パイプライン並列では常にGPUの使用率は40%台でした。理論上2つのGPUが同時に動かないわけですから、2つのGPUの使用率がそれぞれ50%以下になるのは当然です。一方、テンソル並列ではどの試験でもGPU利用率は2つとも80%台中盤から後半を示していました。となれば、テンソル並列はGPU利用率が倍になるわけですから、速度も倍とは言いませんが、1.8倍に近くなるのでは？とも思っていたのですが、実際に値を計算してみるとそれほどでもない。例えば、Gemma4 26Bを見れば、GPUの利用率は倍近くになっているにもかかわらず、計算速度は8%程しか上昇していない！
テンソル並列時のGPU利用率
2つのGPUとも80％以上ある事が分かる（Gemma4 26B A4B QAT）
なぜこのような結果になるのかを解明できるほどの知識を持ち合わせていないため、残念ながらここまで。とりあえず、テンソル並列は必ず速度向上の効果があり、パラメータ数が多いモデルほど効果が高いという結論にさせて頂きます。
まとめ
いかがだったでしょうか？オンデバイスAIの最新技術である「テンソル並列」の検証をしてみました。AIサーバーとかでは当たり前であったテンソル並列技術が、ついにllama.cppに実装され、家庭用のコンピューターでもテンソル並列が使用できるようになりました。一部、テンソル並列を利用しようとするとエラーになるモデルもあるのですが、メジャーなモデルであればllama.cppやLM Studioのバージョンアップでそのうち改善されるでしょう。
かなり控えめに言っても、オンデバイスAI界隈は盛り上がっています。Mac Studioをはじめ、最初に話題にしたNVIDIA RTX Sparkや、AMDのRyzen AI Haloなど、明確にオンデバイスAIをターゲットにしたGPU用メモリ（ユニファイドメモリ）を巨大にしたハードウエアが次々に登場しています。さらに、中国のKimi K3のように「個人PCで動かすのは難しい」サイズであるものの、その代わりにクラウドAI並みの性能を持つ巨大LLMも一般公開されています。つまり、企業レベルのGPUサーバーを用意すれば、クラウドAIに匹敵するオンデバイスAIが動かせることを意味します。言い換えれば、高性能AIがハイパースケーラー※3以外でも動かせる時代が来つつあるのです。
みなさんも、是非オンデバイスAIに触れてみてはいかがでしょうか？とりあえず、VRAMかメインメモリ32GB以上のコンピュータとLM Stuidoさえ準備できれば、いろいろと試すことができます。まずは動かしてみて、オンデバイスAIならではの機能を試してみてください。
※2; Tera-Operations Per Secondの略。AIの演算能力を表す数値。グラフィック時代は1秒間の浮動小数点演算回数を表すFLOPS（FLoating-point Operations Per Second）で評価されていたが、AIでは整数計算が多いため、整数（int8）計算の回数で評価するようになった。MicrosoftがCopilot+PCを販売する際に作り出した指標と言われている。
※3; 世界規模で巨大なデータセンターを保有・運営し、膨大な計算資源やクラウドサービスを自社および外部向けに提供する巨大IT企業のこと。Amazon AWSや、Google Cloud、Microsoft Azure等のクラウドサーバー保有企業を指す。