ColabのT4でGGUFがOOMになる原因｜16GB VRAM・量子化・contextの直し方

先に症状を分類する

OOMはファイルが大きいからだけではありません。ロード、context拡張、MTP追加、build、downloadの段階を先に特定します。

まずnvidia-smiでGPUを確認する

nvidia-smi || true
free -h
df -h

T4の16GB GDDR6はNVIDIA公式仕様です。しかしColab無料枠でT4が必ず割り当てられるわけではありません。GPU名がL4やA100ならT4の結果を使わず、そのGPUのVRAMと条件を別に記録します。GPUなしなら後続のCUDA推論セルを実行しないでください。

• NVIDIA T4の仕様 - 16GB GDDR6と公式仕様を確認する
• ColabのGPU提供条件 - GPU種類と利用制限は変動する

ファイルサイズとVRAM使用量は違う

Qwen3.6-27B-MTP-GGUFの配布ページでは、Q3_K_S 12.2GB、Q3_K_M 12.6GB、IQ4_XS 15.7GB、Q4_K_M 17.5GBなどの参考サイズが表示されます。T4 16GBと数字を比べるだけでは、ロード可否やcontextの余白は判断できません。

解決順1：MTPを一度offにする

MTPだけOOMなら、量子化やモデルをすぐ変える前に、同じquant・context・GPU layersでMTPをoffにしてbaselineを起動します。baselineもOOMならMTPが主因ではなく、weights、buffer、context、offloadの問題です。

--spec-type none
# baselineが動いた後だけ、次の測定でMTPを追加
--spec-type draft-mtp --spec-draft-n-max 1

n-maxは1→2の順で比較し、4は余白が確認できる場合の追加実験にします。MTP on/offで別のquantやpromptを使うと、OOMの原因を特定できません。

解決順2：contextとKV cacheを下げる

Qwen公式のnative context 262,144はモデルの最大仕様であり、T4 16GBで同じ長さを確保できる値ではありません。短文が動いて長文でOOMになるなら、contextと会話履歴、入力長、検索で渡す文書量を下げます。

1. ctx-sizeを4096など安全側へ設定する。
2. 短い固定prompt、新規セッション、少ない出力上限で起動する。
3. 動いた後に8192などへ少しずつ増やす。
4. 各変更でpeak VRAMとtokens/sを別の記録行にする。

• context長の一般ガイド - 公式最大値とruntimeの実用値を分ける

解決順3：quant・batch・GPU layersを調整する

llama.cpp/build/bin/llama-cli --hf-repo "unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S" --no-mmproj --ngl 60 --ctx-size 4096 --batch-size 128 --ubatch-size 64 --spec-type none --single-turn --prompt "$PROMPT"

build時OOMと推論時OOMを分ける

CUDA out of memoryと書かれていても、何をしている時に出たかが重要です。buildのRAM不足をquant変更だけで直そうとせず、download失敗をOOMと呼ばないようにします。

一部CPU offloadで動いた場合の読み方

GPU layersを下げてモデルの一部をRAMへ置くと、ロードできる場合があります。ただし、T4の全部VRAMで動いた結果ではありません。RAM使用量、CPU使用率、generation tokens/s、peak VRAMを記録し、安定性を優先した別条件として扱います。

CPU offloadで動いたからT4に収まったとは書きません。読者が同じ条件を再現できるよう、-ngl、context、quant、GPU名、RAMを公開します。

disk・RAM不足とruntime再起動

1. ログを保存し、どのセル・どの段階で失敗したかを書く。
2. df -hでGGUFとbuild artifactの空き容量を見る。
3. free -hでRAMとswapの状態を見る。
4. 不要なモデル・build artifactを整理し、必要ならColab runtimeを再起動する。
5. 再起動後はGPU、commit、quant、contextを再確認してから再実行する。

再起動だけでモデルが小さくなったり、ColabのGPUが保証されたりするわけではありません。環境が初期化され、同じ条件を再構成できるかを確認する操作です。

やってはいけない近道

• Q4_K_Mを16GB T4へ必ず載せられると断定する
• 無料ColabのGPUや利用時間を固定値として案内する
• MTPの2倍速度や精度完全一致を保証する
• 別モデル・別quant・別contextの結果を比較する
• GPUなしruntimeでCUDA推論セルを盲目的に実行する
• Colabへ機密文書をアップロードする
• ngrokやcloudflaredで外部公開serverを作る

• Colab実践ガイド - 安全側の初期値と実行順へ戻る
• ローカルAIトラブルシュート - 手元PCの症状とColabの症状を分ける

FAQと再実行の判断

OOMを直す目的なら、一度にquant・context・batch・GPU layers・MTPを全部変えないでください。変更を1つずつ行い、baselineが動く状態を作ってからMTPへ進むと、読者もログを読み返せます。

• MTPの追加負荷を読む - draftとverificationのVRAM・受理率を確認する
• VRAMの使われ方を読む - 16GB表記と空きVRAMを分ける
• 速度を条件付きで測る - TTFTとgenerationを分離する