GTX 1650(VRAM 4GB)搭載の古いゲーミングノートPCでローカルLLMは動くのか？

前回まで、EVO-X2（ユニファイドメモリ128GB）でQwen3.8-Flash-Nextを動かして遊んでいたのだけど、その時にEVO-X2へリモートデスクトップ接続するのに使っていたVRAM 4GBの古いゲーミングノートPCでもモデルを動かせないかな、と考えてちょっと試してみた。

そういえばこのマシンを買ったときはフォトグラメトリにハマっていて、Metashapeが快適に動くようにGPU搭載マシンにした記憶があるけど、最近そっちは全然触ってないな〜。

結論

GTX 1650 Max-QのVRAM 4GBでも、Gemma 4 E4Bは意外と使えた。
起動は＆短文プロンプトはコンテキスト長128kまで、長文要約タスクで実際に文章を読み込ませるのは96kまで確認できた。

検証環境

主な環境だけ先に書く。詳細は末尾。

項目	内容
CPU	Intel Core i7-10750H / 6C12T
RAM	64GB DDR4
GPU	NVIDIA GeForce GTX 1650 with Max-Q Design
Dedicated VRAM	4GB
OS	Windows 11 Home 25H2
NVIDIA Driver	591.74
llama.cpp	b10679 (50f068fff) / Windows CUDA 12 build
Model	Gemma 4 E4B IT QAT UD-Q4_K_XL
Model size	3.91GiB / 7.46B

まずは、モデルを選んで動かしてみる

Qwen3.8-Flash-Nextは大きすぎるし、普段使っているGemma 4 31Bも、Gemma 4 26B A4Bでもまだ大きすぎる気がしたので、Gemma 4 E4BとQwen3.8 4Bを候補にした。

この時点で想定していた使い方は、

• システムプロンプトでキャラクター設定をして、チャットで雑談する
• Open WebUIやOpenCodeに登録して、tool call専用機にする

の2パターン。
雑談ならGemma 4、tool callならQwen3.8というつもりだったが、Gemma 4 E4Bだけで意外と長くなったので、今回はGemma 4 E4Bの話だけで終わる。

動くかどうかも分からないので、まずはモデルをダウンロードして、llama.cppのzipを展開してから llama-cli で起動してみる。

最初はcontext 2048、-ngl 0（CPUのみ）から。

.\llama-cli.exe `
  -m "(gemma-4-E4B-it-qat-UD-Q4_K_XL.gguf のパス)" `
  -c 2048 `
  -ngl 0 `
  -t 6 `
  -n 128 `
  --reasoning off `
  --jinja `
  --single-turn `
  -lv 4 `
  -p "日本語で二文だけ自己紹介してください。"

これは問題なく動いたので、次は -ngl を少しずつ増やしてモデルのlayerをGPUへoffloadしてみる。

最終的に -ngl 50 で43/43 layersがGPUへoffloadされ、これも問題なく動いた。
全部載って動くなら最初から -ngl 99 にしておいてもよかったのだけど、それは結果論。

llama.cppのログではこんな感じ。

load_tensors: offloading output layer to GPU
load_tensors: offloading 41 repeating layers to GPU
load_tensors: offloaded 43/43 layers to GPU
load_tensors:   CPU_Mapped model buffer size =  1872.00 MiB
load_tensors:        CUDA0 model buffer size =  2493.32 MiB

「3.91GiBのモデルなのに4GB VRAMへ全部入った」と単純に言うと少し語弊がある。llama.cppのログではCUDA側のmodel bufferは約2.49GiBで、CPU_Mapped側にも約1.87GiBある。

短文生成のTGをざっくり比べると、

条件	TG
CPUのみ (-ngl 0)	約8.05 tok/s
43/43 GPU offload	約32.24 tok/s
で、およそ4倍になった。
しばらくEvo-X2に大きめのモデルを載せて長文を読ませて負荷をかけていたので、CPUのみの8tok/sぐらいでも「遅いけど耐えられないほどではないな～」という感じだったが、全層GPUに載せると体感速度も全然違う。

コンテキストサイズを増やしてみる

context 2048 で動いたので、4096、8192と徐々に増やして、短めのプロンプトでまともに回答できるかをチェックしていたのだけど、気づいたら 262144 まで行っていた。

このテストでは各contextに合わせた長文は入れていない。すべて同じ短いプロンプトを使い、contextの「設定値だけ」を変えている。

llama-serverで短いプロンプトを2回投げ、2回目のTGとリソースログをまとめてみた。

context設定	実際のslot上限	VRAM使用 最大	Shared / Non-local 最大	llama GPU committed 最大	TG
4k	4k	2835 MiB	0.117 GiB	2.885 GiB	31.95 tok/s
8k	8k	2903 MiB	0.121 GiB	2.956 GiB	31.41 tok/s
16k	16k	3039 MiB	0.129 GiB	3.096 GiB	31.24 tok/s
32k	32k	3311 MiB	0.145 GiB	3.378 GiB	30.93 tok/s
64k	64k	3855 MiB	0.176 GiB	3.940 GiB	30.91 tok/s
96k	96k	3889 MiB	0.705 GiB	4.504 GiB	27.63 tok/s
128k	128k	3907 MiB	1.250 GiB	5.067 GiB	26.50 tok/s
256k	128kにcap	3889 MiB	3.525 GiB	7.322 GiB	26.35 tok/s

4k～64kまではVRAM使用量は増えるものの、Shared / Non-localは0.12～0.18GiB程度で、TGも31～32 tok/sからほとんど変わらなかった。

ところが96kではDedicated VRAMがほぼ上限に達し、Shared / Non-localが0.705GiBへ増える。同じ短い入力なのにTGも30.91 → 27.63 tok/sへ低下した。

128kではShared / Non-localが1.25GiB、TGは26.50 tok/s。

このあたりから、物理VRAM 4GBの外側にあるsystem RAMをShared / Non-local GPU memoryとして使う影響が見え始めたように見える。

256kはもっと妙なことになった。
モデル自体の n_ctx_train は131072なのに、-c 262144 で起動するとKV cache自体は256k分確保される。

llama_context: n_ctx = 262144
llama_context: n_ctx_seq = 262144
llama_context: n_ctx_seq (262144) > n_ctx_train (131072) -- possible training context overflow

その後、llama-server側では、

the slot context (262144) exceeds the training context of the model (131072) - capping
initializing, n_slots = 4, n_ctx_slot = 131072

となり、実際のrequest slotは128kにcapされた。

つまりこの条件では、

256k分のKV cache用メモリを確保したのに、1 requestで使えるcontextは128k
という、ほぼメモリの無駄遣い状態。
よく見たらモデルの最大context長は最初から131072だった。先に確認しよう。

※この短文contextテストはllama-serverで実施しており、後述するllama-cliの実長文テストとはslot数やbuffer確保条件が異なる。表内でcontext設定による相対変化を見るためのデータとして扱っている。

長文要約テストも試してみる

思ったより長contextまで起動できたので、今度は長文をちゃんと読み込んで処理できるかを試してみる。

EVO-X2 x Qwen3.8-Flash-Nextのテストで使ったのと同じ、日本語論文を切り出して繰り返したテスト文書を使い、llama-cli で64kと96k近くまで実際に埋めて、さいごに要約を出力してもらった。

context	実入力	PP	PP時間	TG	生成	総時間	VRAM使用	llama Shared / Non-local
64k	61,395 tokens	71.81 tok/s	14分15秒	17.06 tok/s	1024 tokens	15分15秒	3799 MiB	0.174 GiB
96k	93,415 tokens	42.60 tok/s	36分33秒	5.77 tok/s	1006 tokens	39分27秒	3893 MiB	0.645 GiB

どちらも truncated = 0 で入力を最後まで処理した。
64kは61,395 tokensを読むだけで約14分。96kは93,415 tokensで約36分半。
だいぶ待たされる感じ。

入力token数は64k→96kで約1.52倍なのに、PP時間は約2.56倍。TGも17.06 → 5.77 tok/sまで落ちた。

96kではVRAMが3893MiBまで埋まり、llamaプロセスのShared / Non-localも0.645GiBまで増えているので、

• contextが長くなってattention/KV参照コストそのものが増えた
• 物理VRAMからShared / Non-local側へ跨ぐ量も増えた

の両方が効いていそう。

64kではShared / Non-localは0.174GiB程度で、contextを61k tokensまで実際に埋めても大きく増えなかった。このあたりまでなら、そこそこ快適に使えそう？

出力については、目視した範囲では日本語や要約内容に大きな破綻はなかった。

96kは約39分かかったけど最後まで完走した。
「VRAM 4GBだから長文は無理だろう」と思って始めたテストなので、96kまで行けた時点でだいぶ想定外。

EVO-X2と比較してみる

前回はEVO-X2のBIOSでUMA Frame Buffer Sizeを2 / 32 / 64 / 96GBに変えるテストをしていた。

そのときは4GB設定を試していなかったので、今回あらためてEVO-X2をVRAM割り当て4GBにして、

• 同じGemma 4 E4B
• 同じllama.cpp b10679
• 同じ64k / 96k
• 同じ61,395 / 93,415 tokenの入力
• 同じsampling条件

で実行してみた。llama.cppのバックエンドは、GTX 1650側はCUDA、EVO-X2側はVulkan。

結果はこちら。

PC / backend	context	実入力	PP	TG	llama Dedicated	llama Shared	Non-local	GPU Total Committed
GTX 1650 4GB / CUDA	64k	61,395	71.8	17.1	3.710 GiB	0.174 GiB	0.174 GiB	3.884 GiB
EVO-X2 UMA 4GB / Vulkan	64k	61,395	184.5	29.7	2.84 GiB	2.96 GiB	0 GiB	5.80 GiB
GTX 1650 4GB / CUDA	96k	93,415	42.6	5.8	3.803 GiB	0.645 GiB	0.645 GiB	4.447 GiB
EVO-X2 UMA 4GB / Vulkan	96k	93,415	126.8	23.5	3.22 GiB	3.15 GiB	0 GiB	6.37 GiB

　

64kではEVO-X2のVulkanがGTX 1650に対してPP約2.6倍、TG約1.7倍。
96kではPP約3.0倍、TGは約4.1倍まで差が広がった。

ただし、これはGPU世代もメモリ帯域もbackendも全然違う2台なので、単純な「GPU性能比較」として見るつもりはない。
今回見たかったのは4GBを超えたGPU memoryがWindows/WDDM上でどう扱われるかというところ。

GTX 1650の「4GB」とEVO-X2の「4GB」は同じではない

GTX 1650は4GBのDedicated VRAMと64GBのsystem RAMが物理的に別れている。

96kではDedicatedが3.803GiBまで埋まり、0.645GiBがShared / Non-localとしてsystem RAM側へ出ていた。

一方、EVO-X2はCPUとGPUが同じ128GB LPDDR5を共有するUMA。

BIOSを4GB設定にしても、64k時点でllamaプロセスは、

• Dedicated: 2.84GiB
• Shared: 2.96GiB
• Total: 5.80GiB

をGPU用途としてcommitしている。

96kでは、

• Dedicated: 3.22GiB
• Shared: 3.15GiB
• Total: 6.37GiB

になった。

そしてGTX 1650ではSharedとほぼ同量が Non-local に計上されたのに対し、EVO-X2では今回のVulkan runで Non-local = 0 だった。

Windowsのタスクマネージャでも差が分かりやすい。左ががGTX 1650で右がEVO-X2。

　

※GTX 1650側のタスクマネージャは3D/Copy/Video系engineを表示しているため、LLM推論中でもグラフ上は0%に見える。リソースログで取得した nvidia-smi のGPU使用率は推論中ほぼ100%だった。

どちらも画面上は「Dedicated + Shared」という似た表示になるが、物理構成はまったく違う。

前回の記事では、EVO-X2をVRAM 2GB設定にしても90GiB級のGPU memory commitをShared中心で使って巨大モデルを動かせた。

これは「物理VRAM 2～4GBの一般的なdGPUでも同じことができる」という意味ではない。

同じWDDMのShared GPU memoryという名前でも、UMAとdGPUでは性能上の意味がかなり違う。

今回GTX 1650で96kへ伸ばした時に急に遅くなった結果と並べると、この違いがかなり分かりやすかった。

※EVO-X2ではb10679のROCm版も同条件で試した。64k PP 910.6 tok/s、96k PP 743.0 tok/sという異常に高い値が出たが、64kでは後半に不自然な反復が増え、96kでは出力が明確に破綻したため、性能比較からは除外した。今回の正式比較には正常な出力を確認したVulkan版だけを使っている。以前から、異常なぐらいの高速値が出るときは出力が怪しいことがあるので要注意。

長文品質評価も試してみる

ここまで来たら、EVO-X2 x Qwen3.8-Flash-Nextの第5回でやった日本語長文品質評価もできそう、ということでやってみた。

テスト内容と採点基準は第5回と同じ。

第5回ではcontext 128kで実施したが、今回のテスト文書はGemma tokenizerで約19.6k tokensなので、GTX 1650側はcontext 32kにした。本文＋質問＋回答を十分収められる条件。

llama-serverの起動オプションのサンプリング値も第5回と合わせて、

temp = 0.2
top-k = 20
top-p = 0.8
min-p = 0.05

とした。

llama.cppのWeb UIから質問ごとに新チャットを開き、毎回同じ本文を添付した。

採点結果

Model	Q1(20)	Q2(15)	Q3(15)	Q4(15)	Q5(20)	共通(15)	合計
Gemma 4 E4B QAT（今回）	20	15	13	14	20	11	93
Qwen3.8-Flash-Next UD-IQ3_XXS（第5回）	19	15	13	15	20	12	94
Gemma 4 31B IT QAT（第5回）	20	15	13	15	20	14	97
Gemma 4 26B A4B QAT（第5回）	20	15	13	15	20	15	98
Qwen3.8 27B UD-Q5_K_XL（第5回）	18	15	15	15	20	13	96

点数だけ見ると、第5回の4モデルにかなり近い。
7.46BのE4Bが93点なので「意外とすごい」と言いたくなるのだけど、実際に回答を読んだ体感は点数ほど近くなかった。

今回の主な減点項目。

項目	内容
Q3	本文中の例を正しく使っているが、固定採点基準で指定していた別の例を使わなかったため13/15。これは第5回でも複数モデルが同じ理由で減点
Q4	3種類の「中立」は拾えているが、「極性発現」を2番目のケースの例として扱った部分が不正確で14/15
Q5	採点項目そのものは全部拾って20/20。ただし「潜在的意見テキストでは評価表現辞書のエントリとして現れないケースが多い」など、本文より一歩強い因果関係をかなり追加
共通	本文にない補完、話の広げすぎ、Q5の字数超過などを減点

採点対象外の部分では、こんな出力があった。
分かるようでよく分からない文章になっている。
他モデルの回答を読んでから読み直すと、間違ってないような気もするが…

第5回のgemma4 31bの出力

第5回のgemma4 26b a4bの出力

第5回のqwen3.8 flash nextの出力

第5回で試したGemma 4 26B A4Bは、内容は正しいのだけど「もう少し詳しく、分かりやすく説明してほしい」という不満だった。
今回のGemma 4 E4Bはそれとは違って、ところどころ「あれ？」となる感じだった。

速度は最初だけかなり待つけど、キャッシュが効けばは意外と快適

Q1の入力は19,735 tokens。
初回はキャッシュがないので全部PPする必要があり、

• PP: 103.96 tok/s
• PP時間: 約189.8秒（約3分10秒）
• TG: 24.56 tok/s
• Q1全体: 約221秒

だった。最初のファイル添付時はかなり遅い。

ところがQ2以降はprompt cache / context checkpointが効いた。

問題	総入力token	新規にPPしたtoken	PP時間
Q1	19,735	19,735	189.84秒
Q2	19,695	477	5.99秒
Q3	19,703	79	1.27秒
Q4	19,693	70	1.25秒
Q5	19,716	94	1.38秒

Q3～Q5では約19.6k tokensの本文のほぼ全部を再利用できており、新規PPは100 tokens未満。

TGもだいたい25 tok/s前後だったので、一度本文を読み込ませた後の質疑応答はかなり普通のチャットに近い体感だった。

「長文を読む最初の1回は待つけど、その文書について何度も質問する」用途なら、古い4GBノートでも思ったより現実的かもしれない。

添付ファイルを忘れたQ4

第5回では、テスト中にファイル添付を忘れたケースが面白かったので、採点外でモデルごとの差も見ていた。今回もQ4で同じことをやってみた。

Gemma 4 E4Bは資料がないことを指摘せず、

• 事実の記述における中立性
• 価値判断からの離脱
• 立場や視点の公平性

という、いかにもありそうな「中立」の3分類を作って答えた。
もちろん今回の本文の第6.1節にそんな分類はない。

第5回の比較コメントではと並べると

Model	添付忘れ時
Gemma 4 31B	資料なしに気づかず、それらしい誤答
Gemma 4 26B A4B	資料不足は指摘するが一般論を追加
Qwen3.8 27B	資料不足は指摘するが一般論を追加
Qwen3.8-Flash-Next	資料不足を指摘したあと一般論を追加
Gemma 4 E4B	資料なしに気づかず、本文とは無関係の「中立」3分類を生成

という感じ。

この点はGemma 4 31Bに近い動作だけど、今回のE4Bはかなり具体的に「もっともらしい別の話」を作っている。

採点基準を作るのはやっぱり難しい

今回も、第5回と同じく「点数と実際に使った印象が完全には一致しない」という結果になった。
今ここで採点基準を変えると第5回との比較が訳の分からないことになるので、今回も同じ基準をそのまま使った。
次に新しい評価基準を作るなら、「本文に書いてないことを推測で断定する」は減点対象にして、内容の間違い、日本語の間違いの減点幅はもう少し大きくしたい。

一般的に使われているベンチマークはもっとちゃんと考えて作られたものだろうけど、それでも「ベンチマークの数字と実際に使った感覚が合わない」という話をよく聞くのも、何となく分かる気がする。

まとめ

「VRAM 4GBの古いGTX 1650ノートでローカルLLMを動かしてみる」という軽いネタのつもりだったのだけど、予想外に色々できた。

今回分かったことをまとめると、

• Gemma 4 E4B Q4_K_XLはGTX 1650 Max-Q 4GBで43/43 layers GPU offloadできた
• 短いpromptならTGは30 tok/s前後
• context 32kなら約2万tokenの日本語文書を使った品質評価まで普通にできた
• 64kでは61,395 tokens、96kでは93,415 tokensの実入力を最後まで処理できた
• ただし96kではShared / Non-local memoryが増え、PP/TGともかなり遅くなった
• 32k品質テストは初回PPこそ約3分かかるが、その後はprompt cacheが効いてかなり快適
• 品質スコアは93/100だったが、第5回の大型モデルより本文外の補完や話の広げすぎが目立った
• EVO-X2の「VRAM 4GB設定」は、物理VRAM 4GBのGTX 1650とは全く同じ意味ではない

次回は、最初に候補のひとつとして挙げていたQwen3.8 4Bを試すか、Evo-X2でコンテキスト長全振り実験に使おうと思っているQwen3.5-2Bをこちらのマシンでも試すか、どちらにしても、同じ環境でもう少し遊んでみたい気がする。

詳細な検証環境

PC

項目	内容
CPU	Intel Core i7-10750H @ 2.60GHz
コア / スレッド	6C / 12T
RAM	64.0GB DDR4（63.8GB使用可能）
dGPU	NVIDIA GeForce GTX 1650 with Max-Q Design
Dedicated VRAM	4096MiB
iGPU	Intel UHD Graphics
ストレージ	NVMe SSD + HDD
OS	Windows 11 Home 25H2
OS Build	26200.9168

nvidia-smi:

NVIDIA-SMI 591.74
Driver Version: 591.74
CUDA Version: 13.1

GPU: NVIDIA GeForce GTX 1650 with Max-Q Design
Memory: 4096 MiB
Power Limit: 35 W
Driver Model: WDDM

llama.cpp

公式releaseのWindows CUDA 12 buildを使用。

PS C:\llama-b10679-cuda12> .\llama-cli.exe --version
version: 0.3.0-dev (build 10679, commit 50f068fff)
built with Clang 20.1.8 for Windows x86_64

PS C:\llama-b10679-cuda12> .\llama-server.exe --version
version: 0.3.0-dev (build 10679, commit 50f068fff)
built with Clang 20.1.8 for Windows x86_64

device:

CUDA0: NVIDIA GeForce GTX 1650 with Max-Q Design (4095 MiB, 3294 MiB free)

使用したモデル

今回使用:

gemma-4-E4B-it-qat-UD-Q4_K_XL.gguf

llama.cppログ上:

model type   = E4B
model params = 7.46 B
file size    = 3.91 GiB
n_ctx_train  = 131072

長contextテストデータの作り方

元データは、

乾孝司・奥村学「テキストを対象とした評価情報の分析に関する研究動向」
（『自然言語処理』Vol.13, No.3, 2006年、pp.201–241）

この論文の言語処理学会論文誌LaTeXコーパス、

に収録されているLaTeXソースから、第3章の一部を9,406字と14,874字で切り出した。

その後、9,406字のブロックと14,874字のブロックを繰り返して、必要な長さの日本語文書を作成し、最後に以下の指示を追加した。

以上が入力文書です。
複数回繰り返されている部分は無視して、入力文書のユニークな部分について要約してください。

次の項目を含め、800字程度の日本語でまとめてください。

1. 文書が扱う問題
2. 主な手法の分類
3. 評価表現辞書の構築方法
4. 共起情報・PMI・文脈情報の役割
5. 文書分類との関係
6. 注意点または限界

文書に書かれていない内容は推測しないでください。
数式・専門用語は、意味を変えずに必要に応じて残してください。