前回のMacゲームの回で、統合メモリ——CPUとGPUが同じメモリを共有する仕組み——の話を書きました。そのとき読者の方から鋭い指摘をいただきました。

WindowsのPCでも、グラフィックボードを積まなければCPU内蔵のGPUがメモリを共有します。構成としてはApple Siliconと同じはずですが、パフォーマンスも同じになるのでしょうか？

これを確かめるのに、これ以上ない環境が手元にありました。1台のミニPCに、内蔵GPUと外付けのグラフィックボードが両方載っているのです。同じマシン・同じOS・同じソフトのまま、構成だけを切り替えて比べられます😊

同じ1台で、両方の構成を試せる環境

今回の主役はこのマシンです。

• ミニPC（Ryzen 7 7840HS / RAM 32GB / Windows 11 Pro）
• 内蔵GPU：Radeon 780M — CPUに内蔵。システムのメモリを共有する＝統合メモリ構成
• 外付けGPU：RTX 3060（12GB） — OCuLinkという規格でケーブル接続＝専用GPU構成

普通は「統合メモリのマシン」と「グラボ搭載のマシン」を2台用意して比べることになり、CPUもメモリもOSも違うので何が効いているのか分からなくなります。今回は1台で切り替えるので、差はGPUの構成だけです。

用語集

用語	意味
統合メモリ	CPUとGPUが同じメモリを分け合う作り。内蔵GPU（iGPU）はこの形。専用のVRAMを持ちません
VRAM	グラフィックボードが持つ専用の高速メモリ。速い代わりに容量は製品ごとに固定で、後から増やせません
eGPU	外付けのグラフィックボード。ノートPCやミニPCにケーブルで足すもの
OCuLink	eGPUの接続規格のひとつ。PCIe 4.0 x4相当（約64Gbps）で、Thunderbolt 4／USB4（40Gbps）より速い。より新しいThunderbolt 5は80Gbps
メモリ帯域	メモリとの間で1秒あたり何GB運べるか。AIの文章生成はここで速度が決まります
Dense / MoE	AIモデルの作り方。Denseは全部の部品を毎回使う。MoEは専門家を多数持ち毎回そのうち一部だけ動かすので、大きいわりに動作が軽い
量子化 （Q4・Q3）	モデルの数値を粗くして容量を減らすこと。数字が小さいほど軽いが精度は落ちます
pp / tg	pp＝プロンプト処理（読ませた文章を理解する段階・演算が主役）、tg＝生成（返事を書く段階・メモリ帯域が主役）。今回この2つを分けて測ります
-ngl	AIモデルの何層をGPUに載せるかの指定。-ngl 99で「全部載せろ」の意味になります
1% Low	fpsの悪かった下位1%の平均。平均fpsが同じでもここが低いと「カクつく」と感じます

検証環境と、条件の揃え方

比較でいちばん大事なのは条件を揃えることです。今回はここに気を配りました。

• 推論エンジンを統一：llama.cpp の Vulkan版を使用。CUDA（NVIDIA専用）やROCm（AMD専用）を使うとエンジンの違いが混ざってしまうため、両方のGPUで動く同じバイナリで測りました
• 測定条件を統一：プロンプト512トークン／生成128トークン／3回平均。さらにウォームアップを1回捨てる（Vulkanは初回にシェーダの準備が入り、実測でppが217→1218と5.6倍変わったため）
• ゲームの画質設定を固定：設定ファイルのSHA256（内容が同じかを確かめる指紋のようなもの）が両方の測定で完全一致することを確認済み

使ったGPUはこの2つです。Vulkanから見ると、両方とも同じように「デバイス」として見えます。

RTX 3060は12329MiB、Radeon 780Mは16282MiB。この780M側の数字が、後で効いてきます

つまずき①：公式バイナリが起動すらしない

測定を始める前に、いきなり壁にぶつかりました。

llama.cppの公式サイトからWindows版をダウンロードして実行しても、何のメッセージも出ないまま終了してしまいます。--helpすら表示されません。

原因は Smart App Control（SAC）でした。Windows 11の保護機能で、署名のないプログラムを実行させないもの。llama.cppの公式配布物は署名されていないため、プログラムの起動自体は通るのに、部品（DLL）の読み込み段階で止められる——だから「何も出ずに落ちる」という分かりにくい症状になっていました。

解決策は「署名されている配布物を使う」ことでした。LM Studioというアプリに同梱されているllama.cppは、中身は同じVulkan版なのに開発元の署名があるためSACを通ります。

これは以前のローカルAIエージェントの回でも同じ壁に当たっていて、Windowsでローカルツールを動かすとき繰り返し出てくる問題のようです。「署名済みの配布物を選ぶ」が現実解でした。

立てた予想（3つ）

測る前に、3つの予想を立てました。先に言うと、このうち2つが外れます😅

予想	根拠
① 小さいモデルはRTX 3060が圧勝	両方に載るので、純粋にメモリ帯域の差（GDDR6 vs DDR5）が出るはず
② 大きいモデルを載せるにはBIOS設定の変更が要る	780MのVRAM割当は現在512MB。BIOSで16GBに増やさないと大きいモデルは載らないはず
③ MoEなら統合メモリが逆転できる	MoEは容量を食うが動く部分は小さい。容量に余裕のある780Mが有利になるはず

AI推論の実測結果

3種類のモデルで測りました。tg（生成）が体感速度に直結する数字です。

モデル	GPU	pp t/s	tg t/s	確保VRAM
7B Dense (4.36GB)	RTX 3060	1215.3	55.94	4380 MB
	780M	112.9	13.37	4408 MB
14B Dense (8.37GB)	RTX 3060	509.5	29.34	8503 MB
	780M	52.4	6.72	8560 MB
MoE 30B-A3B Q3 (13.7GB)	RTX 3060	491.7	44.20	10476 MB （一部CPU）
	780M	226.4	26.47	14198 MB （全部GPU）

MoEの実測。LOAD FAILEDの行が2つあるのが、この記事の後半につながります

予想①は的中でした。7Bで4.18倍、14Bで4.37倍。統合メモリ側は速度では明確に負けます。

ですが、他の2つが外れました。順に見ていきます。

予想外れ①：BIOSの割当は、制限になっていなかった

ここが今回いちばんの発見です。

上の表をもう一度見てください。780Mが14198MB＝約14.2GBを確保しているのが分かります。ところが——

BIOSのVRAM割当は512MBのままです。それなのに14.2GBのモデルが丸ごと載りました。

タスクマネージャーを見ると答えが書いてあります。

• 専用GPUメモリ：512MB ← BIOSで設定した分
• 共有GPUメモリ：15.7GB ← システムのRAMから必要に応じて借りる分
• 合計：16.2GB

つまり現代のWindowsとドライバは、内蔵GPUが使えるメモリをBIOS設定に縛られず、実行時に自動で確保します。BIOSの数字は「最初から予約しておく分」に過ぎませんでした。

この検証、当初は「BIOSで512MBと16GBに変えて2条件で測る」つもりでした。その前提自体が不要だったわけです😳

ちなみに専用を16GBに増やしても合計は増えません。専用が増えた分だけシステムRAMが減り、共有できる分も同じだけ減るためです。

予想外れ②：MoEでも逆転しなかった

もうひとつの予想も外れました。

MoEは「大きいけれど毎回動くのは一部だけ」なので、容量に余裕のある統合メモリが有利になるはずと考えていました。実際どうなったかというと——

モデル	RTX 3060	780M	差
7B Dense	55.94	13.37	4.18倍
14B Dense	29.34	6.72	4.37倍
MoE Q3	44.20	26.47	1.67倍

差は4.2倍から1.67倍まで縮みました。方向性としては予想どおりです。ですが逆転はしませんでした。

面白いのは、780Mは13.7GBを全部GPUに載せているのに対し、RTX 3060は12GBに収まりきらず一部をCPUに回しているという点です。条件としては780Mのほうが有利なのに、それでも負けた。

理由はこうです。MoEは1回の生成で3B相当しか動きません。だから「全部が高速メモリに載っていること」よりも、「動く部分が高速メモリに載っていること」のほうが効く。RTX 3060は12GBのうち大部分に主要な層を載せられていて、それで十分だったわけです。

つまずき②：-ngl 99 を付けると遅くなる

そして、この予想外れにはもう一つの原因がありました。実用上いちばん役立つ知見かもしれません。

llama.cppには-nglという指定があります。「モデルの何層をGPUに載せるか」で、-ngl 99と書けば「全部載せろ」の意味になります。速くしたいなら全部載せる——と考えるのが自然です。

ところがMoE（13.7GB）をRTX 3060（12GB）に-ngl 99で載せようとすると、起動すらしませんでした。

failed to fit params to free device memory:
  n_gpu_layers already set by user to 99, abort
ggml_vulkan: Device memory allocation of size 1073516544 failed.
vk::Device::allocateMemory: ErrorOutOfDeviceMemory

ユーザーが-nglを明示すると、llama.cppは自動調整をやめます。「全部載せろと言われたので、載らないなら諦める」という動きです。

そこで-nglを指定せずに実行したところ——

指定	結果
-ngl 99（全部載せろ）	起動失敗
指定なし（自動）	44.2 t/s で快走（載る分だけ載せ、残りはCPU）

「動かない」が「一番速い」に変わりました。llama.cppが空きメモリを見て、載る分だけ載せてくれたわけです。

なお内蔵GPU側では同じ問題が起きにくくなっています。780Mはメモリがシステムと地続きなので、足りなければそのまま溢れられるのに対し、専用GPUは物理的に別のメモリなので逃げ場がない——という構造の違いでした。

ppとtgで、差の出方がまるで違う

もう一つ、測ってみて気づいたことがあります。ppとtgで差の大きさがまるで違うのです。

モデル	tg（生成）の差	pp（読解）の差
7B	4.18倍	10.8倍
14B	4.37倍	9.7倍
MoE Q3	1.67倍	2.2倍

生成では4倍差なのに、プロンプト処理では約10倍差。これは教科書どおりの結果で、理由もはっきりしています。

• pp（プロンプト処理）は、読ませた文章をまとめて計算する段階＝演算性能が主役。GPUの純粋な計算力の差がそのまま出ます
• tg（生成）は、1文字ずつ順番に作る段階＝メモリ帯域が主役。計算量は少ないが、モデル全体を何度も読み返すので帯域で決まります

実用的に言うと、「長い資料を読ませる用途ほど、専用GPUが効く」ということになります。短い質問に答えさせるだけなら差は4倍で済みますが、長文を渡すと10倍の差が出る。用途によって体感が大きく変わりそうです。

ゲームでの実測

次はゲームです。Warframe（基本無料）を、同じ場面・同じ画質設定で60秒間計測しました。

計測した場面。キャラクターを静止させ、前後のスクリーンショットで動いていないことを確認しています

指標	RTX 3060	780M	差
平均 fps	134.8	38.8	3.47倍
1% Low fps	82.0	23.6	3.47倍
0.1% Low fps	80.3	22.2	3.62倍
GPU実働時間/フレーム	7.42 ms	25.62 ms	3.45倍

注目したいのは全部の指標が約3.5倍で綺麗に揃っていることです。平均だけでなく1% Low（カクつきの指標）も同じ比率なので、「たまに引っかかる」類の差ではなく、素の性能差だと分かります。

そして780Mでも38.8fps出ている点も見逃せません。1080pで快適とは言えませんが、「ミニPC単体でも遊べなくはない」水準ではあります。

なお計測にあたっては、VSync（画面の更新に同期させる機能）を切っています。切らないと両方とも60fps張り付きになり、差がまったく見えなくなるためです。

ゲームとAIで「差の出方」が違う

同じ2つのGPUを、同じマシンで、用途だけ変えて比べた結果を並べます。ここが今回いちばん面白い部分でした。

• ゲームは素直に3.5倍。平均も1% Lowも同じ比率で、統合メモリ機に有利な要素が特にない＝GPUの生の力がそのまま出ます
• AIは1.67倍〜10.8倍まで振れる。MoEのように「動く部分が小さい」設計だと差が縮み、読解のように演算量が支配的だと差が開く

つまり「グラボを足す価値」は、ゲームでは一定だがAIでは何を動かすかで3〜6倍変わるということです。統合メモリ機で戦えるのは「MoEを生成中心で使う」ケース、という具体的な線引きができました。

eGPUという選択肢について

最後に、eGPUそのものの話をしておきます。ノートPCやミニPCを持っていて、ゲームもしたいという方には現実的な選択肢だと思います。

今回の構成（OCuLink接続）で、不安定さや引っかかりは一切ありませんでした。RTX 3060は普通のグラフィックボードとして認識され、モデルの読み込みも7Bで3.86秒と速い。接続の帯域がボトルネックになる場面は見当たりませんでした。

接続方式	帯域	備考
Thunderbolt 5	80Gbps	数字の上では最速。ただし高価で製品数もまだ少ない（Razer Core X V2が349.99ドル、Sonnet Breakaway Box 850 T5が697.99ドルなど）
OCuLink	約64Gbps (PCIe 4.0 x4相当)	今回の構成。ミニPCで採用例が増えており、比較的安価
Thunderbolt 4 / USB4	40Gbps	対応機器がいちばん多い。ただし実効はさらに低い
デスクトップ直挿し	PCIe x16	最速。eGPUはこれには一歩劣る

Thunderbolt 5（80Gbps）の製品も出てきています。数字だけ見るとOCuLinkを上回りますが、本体側がThunderbolt 5に対応している必要があり、ケースも高価で選択肢が限られます。一方OCuLinkは規格としては地味ですが、安価で、対応するミニPCが増えているのが実情です。

なおThunderbolt系は接続そのものにプロトコルの処理が挟まるため、実効の帯域は表示の数字より低くなります。OCuLinkはPCIeをほぼそのまま引き出す方式なので、公称値の差ほど実性能の差は開かないとみてよさそうです。

一点だけ、eGPU構成ならではの注意があります。ディスプレイをeGPU側に繋いでいる場合、内蔵GPUで描画させるとフレームがeGPUへコピーされます。今回の780Mの38.8fpsには、この転送コストが含まれています。ミニPC本体の映像出力に繋げば、内蔵GPU側の数字はもう少し伸びる可能性があります。

まとめ

• ★BIOSのVRAM割当は制限になっていなかった。512MB設定のまま780Mが14.2GBを確保し、13.7GBのモデルを全部載せた。統合メモリの容量調整は、OSとドライバが実行時に自動でやっている
• ★MoEでも統合メモリは逆転しなかった（RTX 3060: 44.2 t/s vs 780M: 26.5 t/s）。ただし差は4.2倍→1.67倍まで縮むので、方向性としては正しい
• 理由は「全部載る」より「動く部分が速いメモリにある」ほうが効くから。容量が足りない＝負け、ではなかった
• ★-ngl 99を機械的に付けると、起動すらしなくなることがある。指定しないほうが自動で調整され、むしろ速い
• ppとtgで差がまるで違う（生成4倍 vs 読解10.8倍）。長文を読ませる用途ほど専用GPUが効く
• ゲームは全指標きっちり3.47倍。AIと違って振れ幅がなく、GPUの生の力がそのまま出る
• ★公式のllama.cppはSmart App Controlに丸ごとブロックされる。LM Studio同梱の署名済みランタイムで回避できた
• OCuLink接続のeGPUは、不安定さも帯域のボトルネックも感じなかった

今回いちばんの収穫は、立てた予想が2つも外れたことでした😅 特に「BIOSを変えないと大きいモデルは載らない」は、前回の記事を書いた時点で完全に思い込んでいた部分です。実際に測ってみないと分からない——というのを、いい形で突きつけられました。

そして「容量が正義 vs 帯域が正義」の答えは、少なくともこの規模では帯域（と演算）が正義でした。統合メモリが本当に活きるのは、専用GPUでは部分的にすら載せられないほど巨大なモデルを動かすときなのだと思います。その線引きが数字で見えたのが、今回いちばんの成果でした😊

それでは、今回はここまで。最後までありがとうございました😊

【実測環境】Windows 11 Pro 25H2 / Ryzen 7 7840HS / RAM 32GB / Radeon 780M（iGPU）/ GeForce RTX 3060 12GB（OCuLink接続のeGPU）／llama.cpp Vulkan（LM Studio 0.4.20 同梱版）／計測は prompt 512トークン・生成128トークン・3回平均（ウォームアップ1回を破棄）。ゲームは PresentMon 2.5.1 で60秒キャプチャ、1920x1080・VSyncオフ・同一シーンで静止。画質設定は両測定でファイルのSHA256一致を確認済み。数値は2026年7月時点の実測値で、ドライバやソフトの版により変わる可能性があります。【eGPUケースの参考】eGPU.io「Best eGPU Enclosures」（2026年7月）／Thunderbolt 5対応eGPUケース一覧。価格は2026年7月時点のもので変動します。