「27B・24GBで動く」「100万トークン対応」を実測する：RTX 3060 12GB×2枚でQwythos-27Bの限界を探る
12GB×2枚(合計24GB)は24GBカード1枚と同じか。公称100万トークンは実用的か。Qwythos-27B-v1(Q4_K_M)でコンテキスト長を4096〜131072まで6段階に変えて実測し、CPUオフロードが始まる境界と速度低下を記録。おまけで派生タグがblobを生かし続ける罠も実機再現。
「27BモデルもQ4量子化なら24GBで動く」という説明を見て、RTX 3060 12GB×2枚（合計24GB）なら同じはず、と思ったことはないでしょうか。今回はhf.co/empero-ai/Qwythos-27B-v1-GGUF:Q4_K_Mという実在の26.9Bモデルを使い、「12GB×2枚は24GBカード1枚と同じか」「公称100万トークンのコンテキスト長は実際どこまで使えるか」を、このPCで実測しました。
結論：12GB×2枚は「24GBカード1枚」ではない
まず対照実験として、健全性を確認しました。最小プロンプト「1+1は何ですか？数字だけ答えてください」を投げたところ、既定設定（コンテキスト長32768）で11%/89% CPU/GPUという結果になりました。文字化けもなく、モデル自体は健全です。
ここから本題です。コンテキスト長を4096から131072まで6段階で変え、毎回モデルを完全に再ロードしてollama psの実測値を取りました。
| num_ctx | VRAM使用量 | CPU比率 | GPU比率 | 生成速度(目安) |
|---|---|---|---|---|
| 4,096 | 17GB | 0% | 100% | 約18 tok/s |
| 8,192 | 17GB | 0% | 100% | 約18 tok/s |
| 16,384 | 19GB | 6% | 94% | 約14 tok/s |
| 32,768 | 20GB | 11% | 89% | 約9 tok/s |
| 65,536 | 22GB | 21% | 79% | 約5.7 tok/s |
| 131,072 | 27GB | 34% | 66% | 約3.5 tok/s |
崖のようにある地点で急に壊れるのではなく、コンテキストを上げるほど滑らかにCPU側の比率が増え、速度が落ちていく、という結果でした。全段階で出力の文字化けは一切なく、モデルの重み自体（Q4量子化で約17GB）は健全です。
ただし注目してほしいのは16,384を超えた時点で早くもCPUオフロードが始まっている点です。理由は単純で、モデルの重みが17GBを占め、24GB(合計)のうち残りはわずか7GB程度。そこにKVキャッシュ（コンテキストを保持するための一時領域）を積んでいくため、コンテキストを伸ばすほど残りの余白を食いつぶしていきます。
「公称24GBで動く」という説明は、多くの場合コンテキスト長4kのような短い条件での計測です。今回の実測でも4k・8kまでは完全に100%GPUでした。しかしこれは単体24GBのGPUカード1枚の場合の話であり、12GB×2枚のような分割構成では、カードごとの12GB上限・PCIe越しの分割・CUDAの予備領域の分だけ、同じ「合計24GB」でも早く天井に当たります。
「公称100万トークン」はこのPCでは非現実的
このモデルのコンテキスト長は公称1,048,576トークン（約100万）です。しかし今回の実測では、131,072トークン（公称の約8分の1）の時点で既にCPU比率が34%まで上昇し、生成速度は4k時点の約5分の1(3.5 tok/s)まで落ちていました。これ以上コンテキストを伸ばしても実用速度にならないと判断し、検証を打ち切りました。
非エンジニアの読者への実用的な結論は次の通りです。
- 12GB×2枚（合計24GB）でこのクラスの27Bモデルを使うなら、実用的なコンテキスト長の上限は8,192〜16,384あたり。長いログや複数ファイルを一度に読ませたい用途には、公称値をそのまま信じず、まず小さいコンテキストで動かしてから伸ばして確認するべきです。
- 「100万トークン対応」という宣伝文句は、対応可能な上限であって、手元のVRAMで実用的に使える保証ではありません。
おまけの発見：派生タグが生きていると「再ダウンロード」が名目だけになる
今回の検証中、以前の記事で扱った「ollama rmしてもファイルが本当には消えない」という罠を、このモデルでも意図的に再現しました。
# コンテキスト長違いの派生タグを6個作成した状態で
ollama rm hf.co/empero-ai/Qwythos-27B-v1-GGUF:Q4_K_M
# → 派生タグがblob(約17GB)を参照し続けているため、実ファイルは消えない
# → 改めて pull すると、927MBの副次ファイルだけ再取得され「success」と
# 表示されるが、17GB本体は再ダウンロードされないこれは今回のモデル固有の不具合ではなく、Ollamaの仕組みそのものの挙動です。「コンテキスト長を変えたカスタムタグを作って試す」という今回のような使い方をした後、元のタグだけ消して作り直したつもりでも、実は中身が変わっていない、という事故が起きやすいことを、改めて実機で確認できました。
まとめ
Qwythos-27B-v1（Q4量子化）は、少なくとも今回の6段階のテストでは文字化け等の破損は一切なく、健全なモデルでした。その上で分かったのは、「27B・24GBで動く」「100万トークン対応」という数字は、手元のVRAM構成（特に12GB×2枚のような分割構成）でそのまま再現される保証にはならない、という当たり前だけれど見落としがちな事実です。買う前・試す前に、まず短いコンテキストで自分のVRAM構成での挙動を確認する。それだけで「動くはずなのに遅い・詰まる」という失望を避けられます。