16GB GPUでも35Bモデルは動かせる: LM StudioでMoEモデルのVRAMを圧縮する考え方

Wed, 22 Apr 2026 21:47:34 +0800

16GB VRAM というと、ローカルで大規模モデルを動かす場合はせいぜい 12B〜14B あたりが限界で、それ以上は量子化してもかなり厳しい、というイメージを持つ人が多いと思います。その見方は完全に間違いではありませんが、16GB GPU の本当の上限でもありません。

モデル選定とパラメータ設定がうまく噛み合えば、16GB GPU は必ずしも「小さめのモデル」に留まる必要はありません。その代表的な考え方のひとつが、LM Studio で MoE モデルを使い、適切なアンロード戦略によって 35B 級モデルを実用的な速度で回すというものです。

01 なぜ16GB GPUが12B〜14Bに固定されるわけではないのか

ここでの核心はシンプルです。VRAM 容量は重要ですが、モデルのアーキテクチャも同じくらい重要です。

標準的な dense モデルを 16GB GPU に無理やり押し込もうとすると、すぐに限界に当たります。こうしたモデルは推論時に基本的にすべてのパラメータ計算へ関与するため、VRAM と帯域の負荷が一気に上がるからです。

しかし MoE モデルは違います。総パラメータ数は大きくても、1 回の推論で実際に有効化される専門家パラメータはその一部だけです。35B 級モデルを例にすると、総量は大きくても、1 回の推論で実際に計算に参加するパラメータはずっと少ないため、実際の VRAM 要求は想像ほど極端ではありません。

だからこそ、16GB GPU にもまだ工夫の余地があります。

02 実測上のポイント: 35BのMoEモデルはかなり速く動く

代表的な例として挙げられるのが、Qwen 3.5 35B A3B のような MoE モデルの量子化版です。16GB GPU と LM Studio の組み合わせで設定を調整すると、Q6 量子化で 30 tokens/s を超える水準に届き、Q4 ではさらに高い速度が出ることもあります。

この結果に価値があるのは、単に「動く」からではありません。速度がすでに「明らかに実用的」と言える水準に入っているからです。

比較として、同じくらい大きな規模でも MoE ではないモデルを 16GB GPU で無理に回そうとすると、VRAM あふれや大幅な速度低下が起こりがちです。つまり結果を決めるのは、総パラメータ数だけではなく、推論時にそのパラメータをどう使うかです。

03 LM Studioでは、見るべきパラメータが1つではない

16GB GPU でこうしたモデルを安定して動かすには、運任せではなく、2 つのパラメータを正しく調整する必要があります。

GPU Offload
一部の expert layer を CPU メモリへ強制的に載せるための設定

前者は比較的わかりやすく、GPU Offload は基本的に可能な限り高く設定し、GPU 側での計算を優先させます。

後者こそが重要です。これは「VRAM があふれてからシステムメモリを借りる」という昔ながらのやり方ではなく、あらかじめ一部の expert layer を CPU メモリへ逃がして VRAM 使用量を下げる方法です。MoE モデルはそもそも毎回すべての expert を有効化するわけではないため、専門家層の一部をメモリ側へ回しても、推論速度への影響は多くの人が思うほど大きくありません。

実際には、まず一定の範囲から試し、手元のマシンに合わせて少しずつ調整するのが安全です。

関連値を 20〜35 あたりから始める
VRAM 使用量とメモリ圧力を見ながら微調整する

本質的には、システムメモリを使って VRAM の余裕を買う方法です。

04 128Kコンテキストでも動き、さらに縮めればVRAMをもっと減らせる

もうひとつ面白いのは、コンテキスト長を 128K に引き上げた状態でも、35B 級 MoE モデルが比較的高い速度を保てることです。

ここからわかるのは、16GB GPU の限界は思っているほど固定的ではない、ということです。特に LM Studio のようなローカル推論ツールでは、「動くか動かないか」の二択ではなく、実際には次のようなトレードオフになります。

より多くのシステムメモリを使ってでも VRAM を節約するか
コンテキスト長を短くするか
量子化ごとの能力差を受け入れるか

もしコンテキストを 128K から 64K や 32K に縮めれば、VRAM 圧力はさらに下げられます。つまり、35B 級の MoE モデルの中には、より少ない VRAM の GPU でも何とか動くものが出てくる可能性があります。ただし、その分だけ速度とメモリ負荷のバランスは再調整が必要になります。

05 この方法の代償: RAMと仮想メモリへの要求が高くなる

もちろん、この方法はタダで性能が増えるわけではありません。

注意すべきなのは、VRAM 圧力をさらに圧縮すると、システム RAM の使用量が目立って増え、仮想メモリの負荷も上がることです。つまり、コストが消えるのではなく、GPU から RAM とディスクスワップへ圧力が移るだけです。

そのため、実際に試すなら、先にいくつか確認しておくべきです。

システム RAM が十分あるか
仮想メモリを十分に確保しているか
バックグラウンドで重いソフトがたくさん動いていないか

こうした条件が揃っていないと、「35B が速く動く」どころか、マシン全体が遅くなる可能性があります。

06 量子化は攻めればいいというものでもない

ここにはもうひとつ実務的な判断があります。より低ビットの量子化はたしかに VRAM をさらに節約しやすいですが、それが最善とは限りません。

実際には、Q4 のほうが速度は高くても、元の能力が落ちやすいモデルもあります。その点、Q6 は速度と能力保持のバランスが取りやすいことが多いです。結局は、自分がどちらを優先するかです。

とにかく速く、VRAM に収めたいのか
それともモデル本来の能力をより多く残したいのか

この優先順位によって、選ぶ量子化は変わってきます。

07 試す価値があるモデルの考え方

この観点で見ると、やるべきことは「とにかく大きいモデルを追うこと」ではなく、この戦略に合うモデルを先に探すことです。

MoE アーキテクチャのモデル
LM Studio での対応が良く、量子化版が揃っているモデル
長いコンテキストや instruction following に明確な強みがあるモデル

そして、この考え方は 1 つの 35B MoE モデルだけに限りません。長文脈記憶に強い実験的モデル、命令追従が優秀なモデル、あるいは軽量量子化で速度が出るモデルなどにも自然に広げられます。

つまり重要なのは、まず「メモリで VRAM を補う」戦略に合うアーキテクチャを見つけ、そのうえで調整に入ることです。最初に総パラメータ数だけ見て判断するべきではありません。

08 まとめ

もし手元に 16GB GPU があり、ローカル LLM はせいぜい 12B〜14B までだと思っていたなら、その前提は少し更新してよさそうです。

より正確に言えば、次のようになります。

16GB GPU でも大きめのモデルが完全に無理なわけではない
dense モデルと MoE モデルは分けて考える必要がある
LM Studio の GPU Offload と expert layer の CPU メモリ移動は、VRAM 使用量を大きく変えられる
実際には、より大きいモデル規模とより高い実用速度を得るために、より高いメモリ圧力を受け入れている

この方法がすべてのマシンに向くわけではありませんが、少なくともひとつ確かなことがあります。ローカル LLM 運用では、VRAM 上限だけが唯一の制約ではなく、モデルアーキテクチャと推論設定も同じくらい重要です。

量子化 on KnightLiブログ