VRAM 16GB の RTX5070Ti で動かせた Ollama ローカル LLM 紹介
前置き・なんで LLM には VRAM が大量に必要なのか
普段は ChatGPT (Plus に課金中) → Gemini (無料枠) → Claude (無料枠) を使っていて、ローカル LLM は別に出番がないのだが、新しいモデルが出たと聞いたらとりあえず動かしてみたい欲はある。
しかしイマドキの LLM 界隈では、自分が持っている RTX5070Ti という 16GB の VRAM なんていうのはハナクソみたいなモンで、128GB だの 192GB だのという VRAM を用意しないことには「それなりの賢さを備えた LLM」を動かすのは難しい状態。とはいえ100万円を普通に超えるような Mac Studio は買えませんでして…。
何でこんなに VRAM を食うのかというと、コレはモデル自体のパラメータ量が多いこともあるが、それとは別に「コンテキストウィンドウ」を確保することも絡んでくる。要するにチャットの会話履歴をどれくらい覚えておくかという容量のことで、コレを KV キャッシュとして VRAM の中に持つことになる。
コンテキストウィンドウの容量ってどれくらいかかるの、というのも試算してみた。例えば2万行ほどのコードベースがあったとして、それ全体を読み込んだ上で作業させたいとする。コレはトークンに直すと20～30万トークン程度になり、コンテキストウィンドウとしては 256～512K ほどが見込まれる。KV キャッシュ容量に換算するとコレが 32～64GB ほどになるため、LLM のモデル全体を GPU に載せた上で、それとは別に 32GB とか 64GB とかいう単位で VRAM に空きがないと、AI が事前に知っておくべき情報を覚えさせておけないということになる。
当然ながら GPU の VRAM から溢れたデータが CPU・RAM にオフロードされると、実行速度が大幅に低下してしまう。だから VRAM に全部載せる方法を模索し、結果的に Mac なんかの「ユニファイドメモリ」という仕組みが重宝されているワケである。
前置き・メインメモリを VRAM に割り当てる・共用する方式で VRAM 容量を稼いでいる
ちなみに、RTX5070Ti のように専用 VRAM を持つ「グラボ」の方が、メモリ帯域自体は大きいので、VRAM 容量さえ足りれば、実行速度 (tok/s = Tokens Per Second) は速い傾向にある。
ユニファイドメモリ相当の考え方は Mac に限らず存在し、Intel Arc B390 などの GPU では、LPDDR5X という高速な帯域を持つメインメモリを VRAM として一部割り当てて使うことで、速度そのものは GDDR7 メモリに届かなくとも、実用的な賢さと速さで利用できるというワケ。
Mac のユニファイドメモリはコレよりもメモリの速度が速く、Intel Arc 構成だと 10～15 tok/s 程度のところを 15～25 tok/s 程度出せたりするようだ。
自分のマシン環境はこんな感じ
さて、自分の現在のメインマシン GalleriaXA については過去記事でも書いているので詳細は省くが、GPU は RTX5070Ti (VRAM 16GB) を搭載。CPU は Intel Core Ultra 7 265 に、メインメモリは 32GB。Ollama を動かす WSL に対しては 16GB 分のメモリを割り当ててある状態。
.wslconfig
[wsl2]
memory=16GB
swap=0
networkingMode=Mirrored
[experimental]
hostAddressLoopback=true
今回は、このような環境で $ ollama run を動かして軽くチャットしてみた結果を載せる。CPU オフロードが発生しないよう調整を入れたモノもあるので、VRAM 16GB だとこんな感じでとりあえず動きはした、というところまでの話である。長い会話や AI エージェント的な振る舞いをさせた時にどうなるかは検証していない。
# 以降、WSL にて実行した結果
$ nvidia-smi
Sun Aug 30 17:27:16 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 610.57.01 KMD Version: 610.88 CUDA UMD Version: 13.3 |
+-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce RTX 5070 Ti On | 00000000:02:00.0 Off | N/A |
| 0% 46C P8 11W / 300W | 0MiB / 16303MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
+-----------------------------------------------------------------------------------------+
# Ollama は本稿執筆時点の最新バージョンを使用
$ ollama --version
ollama version is 0.33.2
# 動作を試す LLM は以下のとおり
$ ollama ls
NAME ID SIZE MODIFIED
qwen3.5-9b-q8_0-uncensored:latest 88dd8cb43035 9.5 GB 46 minutes ago
qwen3.6-35b-a3b-iq3-8k:latest cf59408a6f9a 13 GB 9 minutes ago
qwen3.8-27b-q3km-8k:latest d7c0bfc8f4f6 13 GB 4 days ago
gpt-oss:20b 17052f91a42e 13 GB 5 months ago
gemma4:12b-it-qat 38044be4f923 7.2 GB 2 months ago
Qwen 3.5 9B Q8_0 (検閲なしバージョン)
- 過去記事 : 2026-04-27 Qwen3.5 の検閲なしバージョンを Ollama で動かしてみる
コチラの過去記事で取り扱ったモデルそのままである。Qwen 3.5 9B をベースに検閲を回避したモデルというのが出回っていたので、コレを動かしている。
- 元の GGUF ファイル
Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q8_0.ggufは以下からダウンロードした
GGUF ファイルを元に、Ollama で動くモデルを作る。
Modelfile
FROM ./Qwen3.5-9B-Uncensored-HauhauCS-Aggressive-Q8_0.gguf
TEMPLATE {{ .Prompt }}
RENDERER qwen3.5
PARSER qwen3.5
PARAMETER temperature 0.6
PARAMETER top_p 0.95
PARAMETER top_k 20
PARAMETER num_ctx 131072
PARAMETER presence_penalty 1.
以下のようにモデルを生成したら実行するだけ。
$ ollama create qwen3.5-9b-q8_0-uncensored -f Modelfile
# 「こんにちは、あなたはどんなことができるモデルですか？」といった簡単な質問を投げた結果部分
$ ollama run qwen3.5-9b-q8_0-uncensored:latest --verbose
total duration: 36.518831267s
load duration: 1.482436ms
prompt eval count: 14 token(s)
prompt eval duration: 12.378364s
prompt eval rate: 1.13 tokens/s
eval count: 1582 token(s)
eval duration: 24.134974s
eval rate: 65.55 tokens/s # ← コレが応答スピード
# 実行中の GPU 使用量は以下のとおり。CPU オフロードが発生していないことが確認できる
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5-9b-q8_0-uncensored:latest 88dd8cb43035 13 GB 100% GPU 131072 4 minutes from now
$ ollama run --verbose で表示される eval rate が、いわゆる tok/s (Tokens Per Second)、応答のスピードといえる。
Qwen 3.5 は Dense モデルと呼ばれるモノで、LLM が持つ全パラメータを毎回全て使うという従来型のモデル。テキスト出力専用ではなくマルチモーダルに対応したモデルもあるので、画像認識などにも使える。
Q8_0 というのはモデルのデータ精度を通常の 16Bit から 8Bit に落とした「8ビット量子化」を示すモノ。8ビットくらいだと、精度の劣化はそこそこに、元のフル精度 (FP16・16Bit) と比べるとファイルサイズを半分に落とせる。
Qwen 3.6 35B-A3B IQ3
次は Qwen 3.6。コチラはモデル名の「A3B」が示しているとおり、総パラメータは 35B (350億) あるが、推論時にアクティブに使われるパラメータは 3B まで抑えられた MoE (Mixture-of-Experts) というモデル。
IQ3 というのは Importance Quantization (重要度量子化) の略で、「賢さのために大事なところは高精度で残しつつ、どうでもいいところはガッツリ削る」というやり方で 3Bit にまで削っている。コレにより、従来の「一律で 4Bit に削ったモデル」相当の賢さを保ちつつサイズを軽量化している。その代わり、「重要度」を確認しながら処理をするため計算負荷は高まり、出力スピードは落ちる傾向にある。
# 素のままダウンロード・実行できる Qwen 3.6 モデルを選択してみた
$ ollama run batiai/qwen3.6-35b:iq3 --verbose
total duration: 14.470484419s
load duration: 1.453214ms
prompt eval count: 26 token(s)
prompt eval duration: 269.98ms
prompt eval rate: 96.30 tokens/s
eval count: 1244 token(s)
eval duration: 14.075278s
eval rate: 88.38 tokens/s
# CPU オフロードが発生している
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
batiai/qwen3.6-35b:iq3 0bfe0939fc2c 16 GB 13%/87% CPU/GPU 131072 4 minutes from now
MoE モデルの場合、CPU オフロードが発生しても、使用頻度の低い部分が CPU オフロードされていることが多いため、出力スピードはあまり落ちていない (それどころか、Qwen 3.5 と比べるとちょっと速いくらい)。
試しに、CPU オフロードが発生しないようにコンテキストウィンドウのサイズを小さくしてみる。
Modelfile
FROM batiai/qwen3.6-35b:iq3
PARAMETER num_ctx 8192
モデルを作成して実行する。コレで CPU オフロードは発生しなくなった。
$ ollama create qwen3.6-35b-a3b-iq3-8k -f Modelfile
$ ollama run qwen3.6-35b-a3b-iq3-8k --verbose
total duration: 5.95833594s
load duration: 2.158099ms
prompt eval count: 26 token(s) # ← プロンプトのトークン数
prompt eval duration: 241.639ms
prompt eval rate: 107.60 tokens/s
eval count: 907 token(s) # ← 思考トークンと出力のトークン数
eval duration: 5.575805s
eval rate: 162.67 tokens/s # ← CPU オフロードがなくなったためかより高速化した
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.6-35b-a3b-iq3-8k:latest cf59408a6f9a 13 GB 100% GPU 8192 4 minutes from now
ちなみに今回設定した 8192 というコンテキストサイズ num_ctx の決め方だが、単発の会話においては「プロンプト + 思考トークン + 出力」の合計が収まるかどうか、から計算できる。
$ ollama run --verbose の表示でいけば、prompt eval count と eval count の合計値が 8192 以内に収まっていれば問題なし、というワケだ。
Qwen 3.8 27B Q3_K_M
次は Qwen 3.8。Qwen 3.6-27B の事後学習で性能を上げた Dense モデルとされているようだ。
Q3_K_XL という量子化モデルではコンテキストサイズを 8192 まで小さくしても CPU オフロードが発生してしまったので Q3_K_M を選択した。
Modelfile
FROM smtek/Qwen3.8-27B:Q3_K_M
PARAMETER num_ctx 8192
カスタムモデルを作成して実行する。
$ ollama create qwen3.8-27b-q3km-8k -f Modelfile
$ ollama run qwen3.8-27b-q3km-8k:latest --verbose
total duration: 8.93621303s
load duration: 3.116289ms
prompt eval count: 56 token(s)
prompt eval duration: 850.202ms
prompt eval rate: 65.87 tokens/s
eval count: 340 token(s)
eval duration: 8.077878s
eval rate: 42.09 tokens/s
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.8-27b-q3km-8k:latest d7c0bfc8f4f6 13 GB 100% GPU 8192 4 minutes from now
Qwen 3.5 9B Q8_0 が 65.55 tok/s だったのと比べると、Qwen 3.8 27B Q3_K_M が 42.09 tok/s と、出力スピードは落ちているのだが、total duration などの所要時間を見ると Qwen 3.8 の方が速く答えてくれているようだ。
なお、コンテキストサイズ 8192 というのはかなりタイトなので、会話が長くなったり、長めのコードを貼ったりすると古いやり取りを忘れてしまい、文脈が飛ぶことがある。簡単にいえば「おバカになっちゃう」アレである。
また、Q3 系のように量子化で軽量化しすぎると、Tool Calling (外部ツールの呼び出し) だったり、「正確に JSON 形式で出力して」といった構造化出力の場面で崩れることが多くなりやすい気がした。やはり、AI エージェントとして使う時は量子化が粗すぎるとダメ、コンテキストウィンドウが小さいとダメ、ということで、VRAM が潤沢に必要なワケである。
GPT-OSS 20B
Alibaba Cloud が開発した Qwen の 3.5・3.6・3.8 を使ってきたが、次は OpenAI 提供の GPT-OSS。
コチラも MoE モデルであり、16GB という VRAM にも 20B 相当が乗ってサクサク動く。eval rate を見れば分かるが出力スピードはなかなか速いのでストレスが少ない。
賢さとしては o3-mini 相当とのことなので、2025年1月頃 (発表当時) のコスパ向け AI だと思って使うつもりなら十分だろうか。2026年の AI エージェント分野の発展を見てからの使用感だと、もう少し賢さが欲しくなるかもしれない。
$ ollama run gpt-oss:20b --verbose
total duration: 7.735915536s
load duration: 1.099226ms
prompt eval count: 76 token(s)
prompt eval duration: 474.117ms
prompt eval rate: 160.30 tokens/s
eval count: 970 token(s)
eval duration: 7.252008s
eval rate: 133.76 tokens/s
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gpt-oss:20b 17052f91a42e 12 GB 100% GPU 4096 4 minutes from now
Gemma4 12B IT-QAT
Google 開発の Gemma4。IT-QAT というのはそれぞれ、「IT : 対話向け調整済」「QAT : 量子化前提学習」という意味合い。
IT = Instruction-Tuned ということで、対話向けの指示調整が入っているのでチャットアシスタントとしての用途に向いている。
また、モデル軽量化のために事後に量子化するのではなく、学習段階から量子化する QAT = Quantization-Aware Training という手法が取られている。コレにより、4Bit 量子化ながら精度劣化が少なく、サイズも抑えられているというワケ。
$ ollama run gemma4:12b-it-qat --verbose
total duration: 26.336682265s
load duration: 2.860593ms
prompt eval count: 20 token(s)
prompt eval duration: 6.971352s
prompt eval rate: 2.87 tokens/s
eval count: 1143 token(s)
eval duration: 19.359056s
eval rate: 59.04 tokens/s
$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
gemma4:12b-it-qat 38044be4f923 7.7 GB 100% GPU 4096 4 minutes from now
VRAM 使用量 7.7GB と、今回検証した中では一番小さく済んでいる。
以上
ホント、コレ以降は用途次第というか。有償の Claude Code や Codex のようなエージェント的な動作を期待してしまうと、主に賢さの面で厳しいモノがあり、その理由は前述のとおり、単なるパラメータ数の違いに留まらず「コンテキストウィンドウのサイズ」という問題がつきまとう。
VRAM 16GB でローカル LLM 時代を戦うのはもう相当厳しいが、一応動きはしました、ということで。