Google ColabでQwen3.6-27Bを動かす｜T4 16GB・GGUF・MTP比較手順

30秒で分かる結論

この記事で扱うのは、ColabのGPU VMでQwen3.6-27BのGGUFをllama.cppから試し、MTP off/onを同じ条件で比較する手順です。実際の速度やOOMの有無は読者のruntimeへ依存します。

• 実行用Colab notebookをダウンロード - 保存してColabのFile > Upload notebookから開く
• MTPの仕組みと設定 - draft token、受理率、n-maxを先に理解する
• T4でOOMになった時 - VRAM、KV cache、contextを症状別に切り分ける

Colabはローカルではなくクラウド実験環境

Google Colabのコードはアカウントごとの仮想マシンで実行されます。Colab公式FAQは、VMがアイドル後に削除され、最大寿命があること、無料枠ではGPU種類や利用上限が変動し保証されないことを説明しています。

そのため、ここでGGUFを動かしても、手元のWindows PCで推論しているわけではありません。モデルやpromptをクラウドへ置くこと、notebookを共有すること、runtime resetでファイルが失われることを別々に考えてください。

• 無料GPUの割り当てを前提にしない
• 無料枠の利用時間を毎日何時間と断定しない
• 機密文書、個人情報、業務データをアップロードしない
• 公開トンネルや常設serverを作らない
• 実行ログとnotebookの保存先・共有範囲を確認する

Qwen3.6-27Bの公式仕様を先に確認する

Qwen公式モデルカードでは、Qwen3.6-27Bは27B parametersのCausal Language Model with Vision Encoderとして説明され、MTPはmulti-stepsで訓練されています。native contextは262,144 tokensで、これはT4で確保できる実用contextを意味しません。

この記事ではQwen3.6-27Bを別のQwen3.6-35B-A3Bなどのモデルと混同せず、27BのGGUFを対象にします。27Bの公式ベンチマークや、Qwen3.5 9B・Gemmaなど別モデルの速度をColab T4へ転用しません。

• Qwen3.6-27B model card - 27B、MTP、context、model typeの一次情報
• Qwen3.6公式ブログ - 発表内容をモデルカードと照合する

T4 16GBで何が難しいのか

NVIDIA公式のT4仕様は16GB GDDR6です。ただし、16GBすべてをmodel weightsだけに使えるわけではありません。CUDA/runtime buffer、KV cache、context、batch、MTP関連の余白が必要です。

この表は2026-07-15に配布ページで確認した参考サイズです。ファイルサイズと実際のVRAM使用量は同じではなく、更新やruntimeの差で変わるため、最終判断はnvidia-smiと起動ログで行います。

• Q4/Q5/Q8の一般論 - 量子化の役割をQwen固有のサイズと分ける
• T4でOOMになる原因 - model weights以外の負荷を切り分ける

必要なものと実行前の確認

必要なのは、Googleアカウント、Colab notebook、GPU runtimeを試せる状態、モデルを置く空きdisk、同じ条件を記録するメモです。GPU割り当てがない場合は、後続セルを盲目的に実行しません。

1. Runtime > Change runtime typeでGPUを選ぶ。ただしGPUの種類や割り当ては保証されない。
2. preflightを実行し、GPU名、VRAM、RAM、disk、Python versionを記録する。
3. GPUがなければ停止し、別の時間や有料/専用GPUを検討する。
4. T4ならQ3_K_S・context 4096・MTP offから始める。

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

llama.cppをCUDA対応でビルドする

Unslothの配布ページは、llama.cppをcloneし、GGML_CUDA=ONでビルドし、draft-mtpを指定する例を示しています。ここではRAMを使い切らないように並列数を2へ抑え、ビルド終了後にcommitとversionを保存します。

if [ ! -d llama.cpp ]; then git clone https://github.com/ggml-org/llama.cpp; fi
cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j 2 --target llama-cli
git -C llama.cpp rev-parse HEAD
llama.cpp/build/bin/llama-cli --version

このセルはllama.cppのmasterを取得するため、実行時のcommitは固定ではありません。記事や共有ログへ結果を書く場合は、出力されたcommit、llama-cli --version、GPU名を必ず残してください。

GGUFを取得する量子化を選ぶ

llama-cliの--hf-repo user/model:quantは、Hugging FaceのGGUF repoと量子化名を指定する方法です。ノートブックの初期値はQ3_K_Sにし、Q3_K_Mや別候補へ変える場合は、ファイルサイズ、空きdisk、空きVRAMを確認します。

この手順はQwen3.6-27B-MTP-GGUFの配布者ページを使います。Qwen公式のTransformersモデルと、Unslothが変換・量子化したGGUFの配布元は同じものとして扱いません。license、revision、Files欄、モデルカードを確認してください。

MODEL_REF="unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S"
# Q3_K_Mなどへ変更する場合は、同じprompt・contextで別の測定行にする
echo "$MODEL_REF"

• GGUFの形式とmetadata - GGUFはモデル名ではなく実行用ファイル形式として読む
• Hugging FaceでGGUFを探す - 配布者、Files、licenseを確認する

baseline：まずMTPなしで動かす

baselineではMTPを使わず、同じ量子化・context・GPU layers・sampling・prompt・出力上限を固定します。まずロードできること、短い応答が返ること、ログにCUDA backendとgenerationの情報が出ることを確認します。

MODEL_REF="unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S"; PROMPT="次の文章を、条件を落とさず日本語で3点に要約してください。無料のGoogle Colab GPUは割り当てや利用時間が保証されず、実行結果はGPU・量子化・context・ビルドに依存します。"; llama.cpp/build/bin/llama-cli --hf-repo "$MODEL_REF" --no-mmproj --ngl 99 --ctx-size 4096 --n-predict 128 --batch-size 256 --ubatch-size 128 --flash-attn on --seed 42 --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 --spec-type none --single-turn --prompt "$PROMPT" --log-file /content/qwen-baseline.log

一度の結果だけで「T4なら何tokens/s」と一般化しません。prompt processing、TTFT、generation tokens/s、peak VRAM、終了コードを別々に記録し、GPU実測ができなかった場合は未実測と書きます。

MTP：同じ条件でdraft-mtpを追加する

MTPはbaselineのコマンドへspec-type draft-mtpとspec-draft-n-max 2を追加するだけに留め、他の条件を変えません。Unslothの現行例でも、MTP用にdraft-mtpとspec-draft-n-max 2を示しています。

MODEL_REF="unsloth/Qwen3.6-27B-MTP-GGUF:Q3_K_S"; PROMPT="次の文章を、条件を落とさず日本語で3点に要約してください。無料のGoogle Colab GPUは割り当てや利用時間が保証されず、実行結果はGPU・量子化・context・ビルドに依存します。"; llama.cpp/build/bin/llama-cli --hf-repo "$MODEL_REF" --no-mmproj --ngl 99 --ctx-size 4096 --n-predict 128 --batch-size 256 --ubatch-size 128 --flash-attn on --seed 42 --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.0 --spec-type draft-mtp --spec-draft-n-max 2 --single-turn --prompt "$PROMPT" --log-file /content/qwen-mtp.log

MTPは必ず速くなる機能ではありません。draft tokenがtargetに受理される割合、draftとverificationのコスト、sampling、VRAM余白が結果を左右します。-np > 1や--mmprojは配布者ページでMTP未対応と記載されているため、この実践では使いません。

• MTPの仕組みを読む - accepted/rejected、n-max、VRAM、samplingを分けて理解する

baselineとMTPの比較条件を固定する

最低でもbaseline、MTP n-max=1、MTP n-max=2を別行にし、同じpromptで比較します。可能なら3回以上の中央値と、cold/warm、失敗条件を残してください。

結果を記録するテンプレート

• Colab runtimeのGPU名と空きVRAMを記録する
• 実行時のmodel revisionとllama.cpp commitを記録する
• 実測値がない欄は推測で埋めず未確認とする
• SNSのQwen3.5 9BやGemmaの数値をQwen3.6-27Bへ転用しない

OOMになったときの順番

推論時のCUDA OOM、llama.cppのbuild中にRAMが尽きる、GGUFのdownload中にdiskが尽きる、GPUが割り当てられない、は別の症状です。最初に段階を特定します。

1. nvidia-smiでGPU名と空きVRAMを確認する。
2. MTPをoffにしてbaselineを起動し、MTP固有の余白不足か分ける。
3. contextを4096から下げる、batch/ubatchを下げる。
4. Q3_K_Sなど軽いquantへ下げ、model weightsの負荷を減らす。
5. GPU layersを調整し、一部CPU offloadならRAMと速度を別に記録する。
6. free -hとdf -hでRAM/diskを確認し、必要ならruntimeを再起動する。

• Colab T4のGGUF OOM対策 - 症状別の分岐とdecision treeを見る
• VRAMの使われ方 - weights、buffer、KV cacheを分けて理解する

セッション切断・再開・データの扱い

ColabのVMは永続的なローカルPCではありません。モデル、build artifact、ログをVM内だけに置くと、runtimeの切断・削除で消える可能性があります。notebook自体はGoogle Driveまたは手元へ保存し、実測ログは個人情報や機密promptを含めない形で保存します。

Google Driveへmountする場合も、共有範囲、容量、組織ルールを確認します。最初からDriveへ巨大GGUFを置く前提にせず、/contentへ取得して必要な結果だけ保存するほうが切り分けしやすい場合があります。

• Colabの制限とVM寿命 - 無料枠、idle timeout、共有、resetを公式FAQで確認する
• ローカルLLMのプライバシー - ローカル実行とクラウド実行の境界を整理する

手元PC・Colab・有料GPUの使い分け

無料で大規模モデルを無制限に動かす場所ではなく、条件を記録した短い実験環境としてColabを使うと、速度と再現性の話を混同しにくくなります。

この手順で確認できること・できないこと

このリポジトリではColab GPUを確保できないため、2026-07-15時点では手順とnotebookの静的検証までを行い、GPU実測値は掲載していません。読者が実行した結果を記録して初めて、そのruntimeの観測になります。

FAQと次の一手

まずnotebookを保存し、GPU確認、llama.cpp build、Q3_K_S baseline、MTP n-max=2の順に実行します。OOMなら設定を一つずつ戻し、速度を比較する前に同じ条件が保たれているか確認してください。

• MTPの用語と設定を読む - speculative decodingとMTPを分ける
• 一般的な速度測定方法 - TTFT、tokens/s、RAM/VRAMを記録する
• GGUFの選び方へ戻る - 形式、量子化、配布元、licenseを確認する