※当ページはアフィリエイト広告（プロモーション）を含みます。
自宅のPCでLLMを動かすとき、性能を決めるのはほぼVRAMの容量です。そして16GBというのは、ミドルレンジのGPUとしては上限に近いのに、大きめのモデルを載せようとすると途端に足りなくなる、いちばん判断に迷うサイズでもあります。
手元のRTX 5060 Ti 16GBで、27Bクラスのモデルが実用速度で動くのかを確かめました。あわせて、それまで使っていたOllamaをやめてllama.cppに移しています。結果と、途中で分かった「載る／載らない」の境界線を記録しておきます。
・27B（3bit量子化）は載る。生成速度は毎秒30〜46トークンで、読みながら待てる速さ
・ただし4bit量子化は物理的に載らない。16GBで27Bを動かすなら3bitが事実上の上限
・VRAMは16.31GB中15.65GBを使い切る。画像生成との同時起動は不可能
・Ollamaを撤去してディスクが9.4GB空いた
構成
| 項目 | 内容 |
|---|---|
| GPU | NVIDIA GeForce RTX 5060 Ti 16GB |
| モデル | Qwen3.6-27B-MTP（unsloth配布のGGUF） |
| 量子化 | Q3_K_M / ファイルサイズ 12.87GB |
| ランタイム | llama.cpp b9993（CUDA 13.3ビルド） |
| コンテキスト | 16,384トークン（KVキャッシュはq8_0で圧縮） |
| API | llama-server の OpenAI互換エンドポイント |
GPUは16GBモデルを選んでいます。同じRTX 5060 Tiには8GB版もありますが、8GBでは27Bクラスは載りません。ローカルLLMを目的に買うなら、この差は決定的です。
Ollamaをやめた理由
それまではOllamaで12Bクラスのモデルを動かしていました。導入が一行で終わるのは本当に楽で、始めるだけならいまでも第一候補だと思います。
移行した理由は速度です。今回使ったモデルはMTP（Multi-Token Prediction）という、次のトークンをまとめて先読みして、当たっていれば一気に確定させる仕組みに対応しています。これを有効にするにはランタイム側で専用のフラグを指定する必要があり、Ollamaのように設定を抽象化してくれるツールだと、こうした新しい高速化オプションに手が届きません。llama.cppのサーバーを直接起動する形にすると、フラグを全部自分で指定できます。
結果として、同じGPUで12B→27Bとモデルサイズを倍以上にしながら、体感速度は落ちませんでした。移行後にOllama本体とモデルを削除して、ディスクが9.4GB戻っています。
起動コマンド
llama-server.exe ^ -m "C:\AI\models\Qwen3.6-27B-MTP-Q3_K_M.gguf" ^ --host 127.0.0.1 --port 8080 ^ -ngl 99 -c 16384 -fa on -np 1 --jinja ^ --alias qwen3.6-27b-mtp ^ --spec-type draft-mtp --spec-draft-n-max 4 --spec-draft-p-min 0.75 ^ -ctk q8_0 -ctv q8_0
効いているのは後半3行です。--spec-type draft-mtp がMTPの有効化、-ctk q8_0 -ctv q8_0 がKVキャッシュの8bit圧縮。このKVキャッシュ圧縮を入れないと、16kのコンテキストを確保した時点でVRAMが足りなくなります。-ngl 99 は全レイヤーをGPUに載せる指定で、1レイヤーでもCPU側に落ちると速度が桁で落ちるので、ここは妥協できません。
実測
llama-serverが返すtimings情報をそのまま拾っています。プロンプトキャッシュは無効にして、毎回ゼロから処理させました。
| 測定項目 | 結果 |
|---|---|
| 生成速度（短い質問・3回平均） | 34.6 tok/s（30.6〜37.6の幅） |
| 生成速度（長文の要約タスク） | 46.3 tok/s |
| プロンプト処理速度 | 719 tok/s（2,533トークンを3.5秒） |
| VRAM使用量 | 15,650 MiB / 16,311 MiB |
| 消費電力（生成中） | 171 W |
日本語の生成で毎秒30トークンを超えていれば、読む速度より出力のほうが速いので、待たされている感覚はほとんどありません。2,500トークンの文章を投げても、読み込みが3.5秒で終わるので、長い資料を貼って質問する使い方も成立します。
速度がぶれる理由がMTPの受理率だった
気になったのは、生成速度が30〜46 tok/sと1.5倍もぶれることです。サーバーのログにMTPの統計が出ていたので確認しました。
draft acceptance = 0.95154 (216 accepted / 227 generated), mean len = 3.04 draft acceptance = 0.91700 (232 accepted / 253 generated), mean len = 3.07 draft acceptance = 0.88325 (174 accepted / 197 generated), mean len = 2.51 draft acceptance = 0.89677 (139 accepted / 155 generated), mean len = 3.57
先読みしたトークンが採用された割合が88〜95%、一度にまとめて確定できた長さが平均2.5〜3.6トークン。つまり、通常なら1個ずつしか出せないところを、当たっているときは3個まとめて出しているわけです。
そして受理率は生成する内容によって変わります。要約のように後続の単語が予測しやすい文章では受理率が上がって46 tok/sまで伸び、自由な発想を求める質問では下がって30 tok/s台に落ちる。速度のぶれはGPUの調子ではなく、タスクの性質そのものでした。これは事前には読めない部分なので、「だいたい30 tok/s出る、内容がよければ45まで伸びる」と考えておくのが実態に合っています。
16GBの壁は、思っていたより低い位置にあった
いちばん判断が必要だったのが量子化の選択です。一般に4bit（Q4_K_M）が品質と容量のバランスが良いとされていて、最初はそこを狙いました。載りませんでした。
| 量子化 | ファイルサイズ | 16GBに載るか |
|---|---|---|
| Q4_K_M | 約17GB〜 | 載らない。ファイル単体でVRAMを超える |
| UD-Q3_K_XL | 13.77GB | ぎりぎり載る。実質これが上限 |
| Q3_K_M（採用） | 12.87GB | 載る。KVキャッシュ込みで15.65GB |
ここで見落としやすいのが、VRAMに載るのはモデルファイルだけではないという点です。Q3_K_Mは12.87GBですが、実際の使用量は15.65GB。差の約2.8GBはKVキャッシュ（会話の文脈を保持する領域）とワークスペースです。しかもこれは、KVキャッシュを8bitに圧縮した上での数字です。圧縮なしなら倍近く必要になります。
つまり「16GBのGPUだから16GBまでのモデルが載る」ではなく、実際に選べるのはVRAMの8割程度までと見ておく必要があります。
画像生成とは同時に動かせない
VRAMを15.65GB使い切るということは、他のGPUアプリと共存できないということです。同じPCでComfyUIによる画像生成環境も動かしているので、ここは運用でしのいでいます。
具体的には、LLMの起動スクリプトの冒頭でComfyUIにVRAM解放のリクエストを投げるようにしました。
try {
Invoke-RestMethod -Method Post -Uri "http://127.0.0.1:8188/free" `
-Body '{"unload_models":true,"free_memory":true}' `
-ContentType "application/json" -TimeoutSec 5 | Out-Null
Write-Host "[ok] ComfyUI VRAM freed"
} catch {
Write-Host "[--] ComfyUI not running, skip"
}
ComfyUIが起動していなければそのまま素通りするので、どちらの状態から始めても同じスクリプトで済みます。逆に画像生成をしたいときは、LLMサーバーを停止するスクリプトを先に叩く。この一往復を自動化しておかないと、必ずどこかで「VRAMが足りない」と怒られて手が止まります。
使ってみて分かったこと
- 「常に手元にある」ことの価値が思ったより大きい。APIの残量やレート制限を気にせず、雑な質問を何度でも投げられる。試行回数が増えるので、結果的に使う頻度が上がった
- 27Bと12Bの差は、日本語の自然さにいちばん出る。12Bでも意味は通るが、27Bのほうが言い回しが素直で、直しが少ない
- 電力は171W。1時間動かして約4〜5円の電気代なので、常時使わないなら気にする水準ではない
- 逆に、最新の情報が必要な調べ物には全く向かない。学習時点で知識が止まっているので、そこはクラウド側のAIを使い分けています
- コード生成も、短いスクリプトなら十分だが、複数ファイルにまたがる作業だとクラウドの大きいモデルに明確に負ける
これから組む人へ
16GBのGPUで27Bを狙うなら、選べるのは3bit量子化だけで、VRAMはほぼ使い切ります。余裕を持って複数のモデルを切り替えたり、画像生成と併用したいなら、正直なところ16GBでは足りません。
一方で、「27Bが3bitで載って、毎秒30〜46トークン出る」というのは、実用ラインは超えています。ミドルレンジのGPUでどこまでやれるかの一つの基準として、この数字が参考になれば幸いです。
予算を上げられるなら、次の段は24GB以上です。ここまで来ると4bit量子化の27Bが余裕で載り、画像生成との併用でVRAMを取り合う必要もなくなります。ただし価格は数倍になるので、「3bitで妥協できるかどうか」がそのまま予算の分岐点だと考えると選びやすいと思います。
【仕事の依頼】ローカルAI環境の構築を承っています
当ラボでは、こうした自宅・社内PCでのAI環境構築を有償で承っています。
- ローカルLLMの導入：GPU選定から量子化の選択、API化まで
- 画像生成環境の構築：ComfyUIを含むワークフロー設計
- 定型レポートの自動生成：文書処理・分析の自動化（決算短信を毎日AIに読ませた記事はこちら）
下のフォームから、内容・規模に応じてお見積りします。
関連記事
※本記事は個人環境での測定記録です。速度・VRAM使用量はGPU・ドライバ・モデルのバージョンによって変動します。数値は2026年7月31日時点、llama.cpp b9993での実測値です。
コメント