RTX 5080 16GB VRAMの壁に関するよくある疑問7選｜今回測った27B〜32B（Dense型）は6.2〜10.3 tok/s

RTX 5080は16GB VRAMを搭載している。今回検証したOllama既定タグのDense型27B〜32Bは、モデル全体がこのVRAMに載りきらなかった。ただし起動を拒否されるわけではなく、収まらないレイヤーをCPU側に置いた状態で実行される。当サイトの検証環境（2026-07-29計測）では、そのDense型3本が6.2〜10.3 tok/s。全レイヤーがGPUに載った14Bクラスは75.0〜76.7 tok/s で、大きな差があった（同じモデルで配置だけを変えた比較ではない）。一方でMoE型の Gemma 4 26B A4B は、同じくCPU側への配置が起きながら58.6 tok/s だった。CPU側に回ったときの速度の出方は一律ではなく、今回の結果はDense型とMoE型の構造の違いと整合する（MoE型は1本だけの測定で、同じモデルを全部GPUに載せた場合とは比べていない）。以下は今回検証したモデルの実測であって、27B以上すべてに当てはまる絶対的な線引きではない。

RTX 5080 16GBでQwen3.5 27B・Gemma 4 26B／31B・Qwen3 32Bはどう動く？

4モデルとも起動する。ただし既定タグでのモデル重量が、計測時にOllamaが利用可能と報告した14.2 GiBに収まらないため、載りきらないレイヤーはCPU側に配置された状態で実行される。測った結果が以下。

この14.2 GiBは、モデルをロードする前にOllamaが起動ログへ出力した利用可能VRAM。nvidia-smi 上のカード総容量は16303 MiB（約15.9 GiB）。差分にはデスクトップ表示や既存プロセスの使用分、ドライバ・ランタイム側の予約領域などが含まれる可能性があるが、本記事では内訳までは計測していない。Ollamaの起動ログはGiB表記、タグの配布サイズと ollama ps の表示はGB表記なので、数値を直接引き算しない方がいい。

部分的にCPUへ配置されると、そのレイヤーの計算はCPUが担当し、1トークン生成するたびにそのレイヤーの重みをメインメモリから読み出す。メインメモリの帯域はVRAMよりかなり狭い。GPU側とCPU側の間で受け渡す中間データは、1トークンあたりでは、モデル重みに比べれば小さい。Dense型の Qwen3.5 27B は、GPU内で完結した14Bクラスの約7.3〜7.4分の1の速度だった。パラメータ数の差（約2倍）だけでは説明しにくい差で、CPU側に置かれた重みの読み出しが速度を決めていることと整合する（同じモデルで配置だけを変えた比較や、メモリ帯域の直接の計測はしていない）。gemma4:31b・qwen3:32bはCPU側の割合がさらに増え、6.6〜6.2 tok/s だった。

対照的なのが Gemma 4 26B A4B（gemma4:26b）で、CPU側の割合が27.3%と Qwen3.5 27B（22.1%）より高いのに、58.6 tok/s だった。このモデルは総パラメータ25.2Bに対し、1トークンで有効になるのは約3.8B（128エキスパート中8つ＋共有1つ）。CPU側に置かれたレイヤーでも、Dense型のように全重みを計算するわけではなく、ルーティングで選ばれた一部のエキスパートが主な計算対象になるため、CPU側で1トークンごとに読み出す重み（と演算量）がDense型ほど増えなかった可能性がある。ただし本記事で測ったのはスループットと配分比率だけで、どのレイヤーやエキスパートがCPU側へ回ったかは追跡していない。あくまで仮説として扱いたい。

ここから言えるのは、配布サイズだけでは全レイヤーがGPUに載るかを判断できない、ということ。モデル本体に加えてコンテキストやランタイム用の領域も必要になるため、VRAM容量と同程度の配布サイズでは余裕がほとんど残らない。RTX 5080でDense型の27B級を全部GPUに載せたいなら、配布サイズの小さいタグを選ぶか、より大容量のGPUへ移行するかを検討することになる（どちらも本記事では測っていない）。

RTX 5080で全レイヤーをGPUに載せられた最大モデルサイズは？

今回検証したラインアップの中で、全レイヤーをGPUに載せたまま動いた最大は14Bクラスだった。前掲の表のとおり phi4:14b が ollama ps の SIZE表示10.72GBで75.0 tok/s、qwen3:14b が10.47GBで76.7 tok/s。パラメータ数だけでVRAM使用量が決まるわけではなく、量子化形式・DenseかMoEか・コンテキスト長・KVキャッシュの形式・ランタイムでも変わるため、「14Bまで」という数字は今回のモデル選定に紐づいた結果として読んでほしい。

14Bクラスでは ollama ps 上で100% GPU常駐を確認できた。ただし ollama ps の SIZE表示と、Ollamaが起動時に報告する利用可能VRAMは同じ指標ではないため、残りのVRAMを単純な引き算では出せない。コンテキストを伸ばしたときの余裕は、nvidia-smi の実使用量も併せて確認したい。

9B以下の軽量モデルなら余裕がさらに広がり、qwen3.5:9bで5.88GB、phi4-mini:3.8bでは3.7GB。複数モデル同時起動やマルチタスクを想定するなら、軽量モデル中心の運用が現実的な選択肢になる。

今回の対象を配布サイズで並べると、全部載った14Bクラスが9.05〜9.28GB、CPU配置が始まった27Bクラスが17.42GBで、この間が空いている。これは量子化方式の構造というより、既定タグで揃えたときにこのサイズ帯が手薄になるという選定上の段差。公式タグには gemma4:26b-a4b-it-qat（配布16GB表示）のように既定より小さいバージョンもあるが、今回の14.2 GiBはGB表記に直すと約15.2GBで、配布16GB表示はファイルだけでこれと同程度か上回る。今回の環境では全部は載らない可能性もある。本記事ではこのタグを計測していない。

公称14GB台に見えるGemma 4 26B A4BはRTX 5080でどこまで使える？

Google 公式の Q4_0 目安（約14.4GB）だけ見れば乗りそうに見えますが、Ollama 経由の default 量子化では事情が変わります。計測時の gemma4:26b タグは18GB（17.99GB）と表示され、これだけで利用可能な14.2 GiBを超えていました（現行の同タグは19GB表示）。さらに実行時には KVキャッシュ用のバッファ確保、推論時のアクティベーションメモリ、CUDAコンテキストの予約領域が積み上がります。

Gemma 4ファミリーにはE2B・E4B・12B・26B A4B（MoE）・31B（Dense）があり、Gemma 4 に「27B」というモデルは存在しません（27B は Gemma 3 のサイズ）。本セクションで扱う「14GB台に見えるモデル」は 26B A4B（Ollama: gemma4:26b）を指し、前掲の表で6.6 tok/s だった Gemma 4 31B（gemma4:31b）とは別モデルです。MoE構成は1トークンあたりに使う活性化パラメータこそ少ないものの、ロード時には全エキスパートぶんの重みを確保する必要があり、Dense型に近いメモリ要件になります。

当サイトの実測では、gemma4:26b は ollama ps の SIZE表示18.22GBのうち 72.7%がGPU側、残り27.3%がCPU側という配分になった。計測時にOllamaが利用可能と報告したVRAMは14.2 GiB（nvidia-smi 上のカード総容量は16303 MiB（約15.9 GiB））。18〜20GB級の配布サイズはこれを超えるため、全部をVRAMに置くことはできない。それでもこの計測条件では58.6 tok/s だった。トークンあたりに使う重みが限られるMoEの性質と整合するが、原因を切り分けて測ってはいない（応答品質や用途ごとの使い勝手は本記事では評価していない）。

Q2やQ3量子化に落とせばRTX 5080で27Bは全部VRAMに載る？

まず前提として、量子化を落とせば必ず全部VRAMに載るとは言い切れません。2026-07-29時点のOllama公式ライブラリを確認した範囲では、gemma4:26b・gemma4:31b・qwen3.5:27b のいずれにも q2_K / q3_K_M の公式タグは用意されていません。公式に選べる軽量寄りのタグとしては gemma4:26b-a4b-it-qat（配布16GB表示）があり（qwen3.5:27b-int4 は GGUF ではなく safetensors 形式のため、次の節で扱います）、それ以上落とすなら第三者が公開しているGGUFを取得するか、自分で量子化してOllamaへインポートする必要があります。

Q2・Q3相当のGGUFが実際に何GBになるかは、本記事では実ファイルを確認していないので数値は挙げません。GGUFのサイズは量子化方式や量子化対象外のテンソル（埋め込み・出力層・メタデータ）によって変わり、ロード可否は対象ファイルの実サイズと実行時のメモリ使用量で判断することになります。実行時にはKVキャッシュとランタイム領域も上乗せされます。仮に14GB級まで小さくなっても、利用可能な14.2 GiBに対する余裕は小さく、コンテキスト設定によっては一部がCPU側に残る可能性があります。本記事ではこれらの軽量タグのロード可否・速度・出力品質を測っていません。

一般に低ビット量子化ほど出力品質へ影響する可能性が高まりますが、影響の大きさや現れ方はモデル・量子化方式・タスクによって異なります。本記事で計測したのは生成速度とGPU/CPUの配分だけで、品質は定量評価していません。Q4_K_Mが「品質と速度のバランス点」とされるのも一般的な経験則のため、常用前に実際の用途で確認するのが確実です。

量子化を下げたときの速度差は、モデルとランタイムの実装によって変わるため一概には言えず、本記事では測っていません。今回の実測で言えるのは、部分的にCPU側へ置かれたDense型の27B〜32Bが6.2〜10.3 tok/s だった一方、MoE型の Gemma 4 26B A4B は同じくCPU配置が起きながら58.6 tok/s だった、ということ。全レイヤーがGPUに載るかどうかだけで速度を一律には判断できません。常用の判断では、既定タグで全部載る14Bクラスに留める、MoE型のようにCPU側に回っても速度が残りやすいモデルを試す（今回測ったのは計測時の版の gemma4:26b 1本で、現行版は未測定）、GPUを換装する、の3つを比べることになります。

代替路として、一部のCore Ultra搭載機の Built-in Intel Arc Pro GPU では、システムメモリの最大93%を GPU 側の作業メモリとして動的に割り当てられるドライバ機能が登場している。Intel の Arc Pro 向けドライバでメモリ割当の上限が引き上げられたもので、どのバージョンから使えるかは Intel のドライバ配布ページで確認したい。ただし対象は一部のCore Ultra内蔵の Arc Pro 構成に限られ、通常のIntel Arc iGPU全般に使える話ではない。設定できる上限の割合はシステムRAMの容量で変わる（RAMが多いほど高くできる）とIntelは説明しており、32GB機でどこまで割り当てられるかは対象CPU・ドライバ・設定画面で確かめる必要があります。「VRAMの壁」を別ルートで回避する手段として注目されています。この機能は対象のArc Pro構成でシステムメモリをGPU側の作業領域として使うもので、RTX 5080との同じ条件での推論速度は本記事では比べていません。速度も重視するなら、使うモデルで実際に比べてから判断したいところです。

配布サイズ16GBのint4・QATタグならRTX 5080に全部載る？

断定はできません。公式ライブラリには qwen3.5:27b-int4（配布16GB表示）と gemma4:26b-a4b-it-qat（同16GB表示）があり、いずれも既定タグより小さい構成です。

ただし2つはファイル形式が違います。gemma4:26b-a4b-it-qat は通常の GGUF 形式です。一方 qwen3.5:27b-int4 は、2026-09-29 にOllamaのレジストリで確認した範囲では、通常のGGUFモデルとは異なり、tensor群として格納されたsafetensors系のモデルです。Ollama の開発ドキュメント（ビルド手順）では、safetensors 形式のモデルを動かす MLX エンジンは macOS の Apple Silicon では標準で使われ、ほかのプラットフォームでは任意（Optional）の扱いとされています。Windows 版のドキュメントには、zip 版（Standalone CLI）に加える追加パッケージとして MLX（CUDA）用の ollama-windows-amd64-mlx.zip が挙がっていますが、調べた範囲では、RTX 5080 でこのタグが動くことを示す公式の対応表や動作保証は見つかりませんでした。通常のインストーラー版・追加パッケージ版のどちらでも試していないため、本記事では qwen3.5:27b-int4 を選択肢に入れません。また配布サイズと実行時のVRAM消費量は一致しないため、gemma4:26b-a4b-it-qat もタグの表示サイズだけでは判断できません。

今回Ollamaが利用可能と報告した14.2 GiBは、GB表記に直すと約15.2GB。gemma4:26b-a4b-it-qat の配布16GB表示はファイルだけでこれと同程度か上回り、実行時にはKVキャッシュなども要るため、今回の環境では一部がCPU側に残る可能性がある。全レイヤーをGPUに載せられるかは本記事で計測していないため、ここは断定を避けます。既定タグの gemma4:26b（計測時の版）が58.6 tok/s だった構成から乗り換える価値があるかどうかは、実際にロードして ollama ps のPROCESSOR列を見るのが確実です。

RTX 5060 Ti 16GBや他の16GB GPUでも結果は同じ？

同じモデル・量子化・コンテキスト条件なら、16GB級GPUでは17〜20GB級の既定タグを全GPU常駐させにくいという大枠は共通します。ただし実際にCPU配置が始まる位置や配分率は、OS・表示出力・利用可能VRAM・ドライバ・バックエンドによって変わります。RTX 5060 Ti 16GB・RTX 5070 Ti 16GB・RTX 4070 Ti Super 16GB・RX 9070 XT 16GBのいずれも、今回検証した17〜20GB級の既定タグを全レイヤーGPU常駐させるのは難しいと考えられますが、本記事で実測したのは RTX 5080 のみです。

差が出るのは推論速度（tokens/sec）の方。GPUアーキテクチャ・演算性能・メモリ帯域・量子化カーネルの実装・バックエンド・CPUとRAMの性能など複数の要因で決まり、どこまでVRAMに載るかとは別の軸になります。NVIDIA同士の比較でもCUDAコア数だけで速度は決まりません。RTX 5060 Ti 16GBはCUDAコア4608基・GDDR7メモリで、本記事の計測とは別の当サイト検証でも、14Bクラスのモデルは5080より遅かった。価格は販売店と製品で違いますが、2026年9月29日にツクモの公式通販で確認した在庫品では、ASUS DUAL-RTX5060TI-O16G-WHITEがセール価格で124,999円、RTX 5080のMSI GeForce RTX 5080 16G VENTUS 3X OCが295,799円（いずれも税込）で、半額以下でした（セール価格は期間で変わるので、比べるときは同じ時点の価格で確かめてください）。本記事では両GPUを同じ条件で測っていないので、AI用途での費用対効果は評価していません。

RX 9070 XTは、同じ日にツクモで確認したGIGABYTE Radeon RX 9070 XT GAMING OC 16Gが119,999円（税込）で、上のRTX 5080の半額以下でした（価格差は製品と販売店で変わります）。ただし公式サポートの状況がOSで分かれます。2026-07-29時点のOllama公式GPU一覧では、Linux版のROCm対応GPUとして 9070 XT が掲載されている一方、Windows版の対応一覧には掲載がありません。ただしOllamaはWindowsでもVulkanバックエンドを提供しているため、WindowsではVulkan経路を使える可能性があります。CUDA・ROCm経路とは実装が異なるので、速度や安定性は実環境で確認したいところ（llama.cppを直接使う選択肢もあります）。

5060 Ti 16GBについては、別記事「AI用PCの最低スペックガイド｜RTX 5060 Ti+RAM 32GBで始めるローカルAI環境」で具体的な構成例を解説しています。

RTX 5090（32GB）にアップグレードすべき？それとも5080維持？

中心になる判断軸は「常用したいモデルとタグ」です。そこにコンテキスト長、並列利用、必要な速度、価格を重ねて考えます。常用が14B以下のモデル（今回の実測で ollama ps の SIZE表示10GB台）に収まり、今回測ったロード可否と生成速度を重視するなら、RTX 5080を維持する選択肢があります（応答品質や用途への適合は本記事では評価していません）。コンテキスト拡張の余地はありますが、実際の余裕はKVキャッシュ形式・プロンプト長・並列数・常駐アプリで変わるため、nvidia-smi の実使用量で確認したいところ。逆にDense型の27B〜32BクラスをQ4_K_Mのまま日常的に使いたいなら、24GB級がひとつの目安になります。ただし32B級や長文コンテキストでは24GBでも余裕が小さい可能性があり、容量の面では32GB級（RTX 5090等）が候補になります。本記事では24GB・32GBのGPUでのロード可否や速度は測っていないので、購入前に使うタグと設定で必要なメモリを確かめたいところです。

RTX 5090の発売時の国内価格は39万3,800円（PC Watch）。2026年9月29日にツクモの公式通販で確認した範囲では、RTX 5090の単体カードはすべて在庫なしで、表示価格はいちばん安いGainward GeForce RTX 5090 Phantomでも449,801円（税込）と、発売時の価格を上回っていました。軽い投資ではありません。「27Bが必要かどうか」を冷静に判断するのが先決でしょう。週に1〜2回しか使わないなら、公式の16GB表示タグ（Qwen3.5 27Bとは別系統のMoE型、gemma4:26b-a4b-it-qat）を試すか、カスタムGGUFの品質を実際の用途で確かめたうえで、5080を維持する方が合理的なケースもある。

第三の道としてデュアルGPU構成があります。当サイトの検証環境はRTX 5080 16GB + RTX 5060 Ti 16GBで物理的には合計32GBのVRAMを搭載していますが、これは単一GPUの連続した32GB VRAMとは別物です。モデル分割・KVキャッシュ・転送オーバーヘッドの影響を受けるため、単一GPUの連続した32GBと同じようには扱えません。Ollamaが2GPU間で分散ロードするのは、モデル重量が単一GPUに収まらない場合の回避策としての位置づけになります。

14Bクラスを今回の条件で使うなら5080維持、より大きなモデルを使うなら必要なメモリを確かめたうえで大容量GPUを検討、という分け方がわかりやすい。5080＋5060 Tiのデュアル構成は、本記事では速度と費用対効果を測っていないので、購入候補としての評価は保留します。

RTX 5080の主要仕様と今回CPU配置が起きたモデル

GPU購入検討時に確認しておきたい主要数値をまとめます。

まとめ：自分の常用モデルサイズで判断する

今回検証したOllama既定タグの範囲では、RTX 5080 16GB単体で14BクラスのDenseモデルは全レイヤーがGPUに載り、75.0〜76.7 tok/s で生成できた。一方 Dense型の Qwen3.5 27B（Ollama: qwen3.5:27b）・Gemma 4 31B（Ollama: gemma4:31b）・qwen3:32b は一部がCPU側に配置され、6.2〜10.3 tok/s だった（モデルが違うので、配置だけによる速度差ではない）。同じくCPU側への配置が起きたMoE型の Gemma 4 26B A4B は58.6 tok/s だった。CPU側への配置と速度の関係は、パラメータ数だけで決まる一律の線ではない。量子化形式・モデル構造・コンテキスト長・Ollamaのバージョンで動く数字として読んでほしい。

選択肢は3つ。既定タグで全部載る14Bまでに留めるなら、RTX 5080を維持する選択肢がある（今回測ったのはロード可否と生成速度で、応答品質は評価していない）。Dense型の27B〜32B級を使いたいなら、24GB級のGPUが容量面の検討候補になる（本記事ではそのロード可否・生成速度・出力品質は測っていない）。配布16GB表示の gemma4:26b-a4b-it-qat はDense型ではなくMoE型です。配布サイズだけでも、今回Ollamaが利用可能と報告した14.2 GiB（約15.2GB）と同程度か上回るため、全部載るとは限りません。32B級や長文コンテキストまで見るなら、容量の面ではRTX 5090（VRAM 32GB）が候補（24GB・32GBのGPUでは未測定）。週次の使用頻度と品質要求を冷静に天秤にかけて、自分のワークロードに合った投資判断をしてください。それでも判断に迷う場合は、現状のRTX 5080で14Bクラスを使い込んでから、足りない部分を見極めて追加投資する方が後悔の少ない選択になります。

本記事は AIハードウェア図鑑 が記載時点の情報をもとに執筆。製品アップデートや第三者ベンチマーク・価格・対応ランタイム等の変動で評価が変わる可能性がある。一定期間経過した内容は再検証を推奨する。