Qwen2.5-32BをVRAM24GBで常用するUnsloth Dynamic GGUF導入ガイド

所要時間: 約30分 | 難易度: ★★★☆☆

この記事で作るもの

• RTX 3090/4090のVRAM 24GBに収まり、かつGPT-4oに匹敵する日本語回答精度を持つローカルLLM環境
• LM Studioやllama.cppで「Unsloth Dynamic V3.1」量子化モデルを動作させるPython推論スクリプト
• CursorやDifyのバックエンドとして活用できるAPIサーバー構築

前提知識：

• Pythonの基本的な実行環境（venvやconda）が構築できる
• Hugging Faceからファイルをダウンロードした経験がある

必要なもの：

• NVIDIA GPU（VRAM 16GB以上推奨、24GBあれば最高品質で動作）
• 30GB以上の空きストレージ
• Python 3.10以降の環境

先に確認するスペック・料金

ローカルLLM、特に30B（300億パラメータ）クラスを動かす際、最大の障壁は「VRAM（ビデオメモリ）容量」です。 今回扱うQwen2.5ベースの32Bモデルは、標準的な4bit量子化（GGUF）で約18〜20GBのVRAMを消費します。 RTX 4060 Ti (16GB) ではモデルの一部をメインメモリ（RAM）に逃がす必要があり、推論速度が劇的に低下します。

一方で、RTX 3090や4090の24GB環境であれば、モデル全体をGPU上に載せきることが可能です。 もしMacユーザーであれば、メモリ32GB以上のM2/M3 Max/Ultraが最低ラインとなります。 「自分のGPUで動くか不安」という方は、まずはこのDynamic GGUF版のIQ4_XS（約17GB）から試すのが最も賢い選択です。 クラウドGPU（RunPodなど）を使う場合は、RTX 3090/4090インスタンスが1時間あたり$0.4前後で利用できます。

なぜこの方法を選ぶのか

これまでローカルLLMの標準だった「GGUF」形式は、モデル全体を一律の精度で削る手法が一般的でした。 しかし、Unslothが提唱する「Dynamic V3.1」量子化は、モデル内の「重要な層」には高い精度を残し、そうでない層を深く削るというインテリジェントなアプローチを取っています。 これにより、従来のQ4_K_M（4bit相当）と同じファイルサイズでありながら、推論精度（Perplexity）が明らかに向上しています。

特にQwen2.5-32Bというモデルは、日本語能力においてLlama 3.1 70Bに迫る実力を持っています。 70Bモデルを動かすにはGPUが2枚必要ですが、32Bなら1枚で済みます。 「1枚のGPUで動かせる最強の日本語環境」を構築するなら、Unsloth Dynamic GGUF一択と言っても過言ではありません。

Step 1: 環境を整える

まずは、GGUF形式を最も安定して動かせる「llama-cpp-python」の環境を作ります。 公式のビルド済みバイナリを使うのではなく、自身のGPU環境に最適化してコンパイルするのがパフォーマンスを引き出すコツです。

# 仮想環境の作成
python -m venv qwen-env
source qwen-env/bin/activate  # Windowsの場合は qwen-env\Scripts\activate

# CUDA環境があることを前提としたインストール
# CMAKE_ARGSを指定することで、GPU（cuBLAS）を有効にします
export CMAKE_ARGS="-DGGML_CUDA=on"
pip install llama-cpp-python huggingface-hub

「llama-cpp-python」は、内部でC++のライブラリをビルドします。 もしエラーが出る場合は、PCに「Visual Studio Build Tools」や「CUDA Toolkit」が正しくインストールされているか確認してください。 ここをケチってCPU版をインストールしてしまうと、レスポンスに数分待たされることになります。

⚠️ 落とし穴: Windows環境で CMAKE_ARGS が無視されるケースが多発します。その場合は set CMAKE_ARGS=-DGGML_CUDA=on を実行してから pip install するか、すでにインストール済みの場合は pip uninstall llama-cpp-python -y で消してから再試行してください。

Step 2: モデルの選定とロード

次に、Hugging FaceからUnslothが公開している最新のDynamic GGUFをダウンロードします。 「どのファイルを選べばいいか」が最初の難関ですが、24GBのVRAMがあるなら「Q4_K_M」か「IQ4_XS」がベストバランスです。

import os
from huggingface_hub import hf_hub_download
from llama_cpp import Llama

# モデル情報の定義
# 今回のトピックであるUnslothのDynamic GGUFリポジトリを指定
model_repo = "unsloth/Qwen2.5-32B-Instruct-GGUF"
model_file = "Qwen2.5-32B-Instruct-IQ4_XS.gguf" # VRAM 24GBに最適

# モデルのダウンロード（初回のみ）
model_path = hf_hub_download(repo_id=model_repo, filename=model_file)

# Llamaクラスの初期化
# n_gpu_layers=-1 は「すべての層をGPUにオフロードする」設定です
# これにより、CPUを一切介さずに高速な推論が可能になります
llm = Llama(
    model_path=model_path,
    n_gpu_layers=-1,
    n_ctx=8192,      # コンテキストサイズ。用途に合わせて調整
    n_threads=8      # CPUを使用する場合のスレッド数
)

「n_gpu_layers=-1」の設定は、必ず指定してください。 これを忘れると、たとえRTX 4090を使っていても、推論の一部がCPUに割り振られてしまい、秒間100トークン出るはずの速度が秒間数トークンまで落ち込みます。 また、n_ctx（コンテキスト長）を大きくしすぎると、KVキャッシュがVRAMを圧迫し、Out of Memory (OOM) でクラッシュします。 24GB環境で32Bモデルを動かすなら、まずは8192（8k）程度で様子を見るのが無難です。

Step 3: 動かしてみる

準備が整ったので、実際に日本語でプロンプトを投げてみます。 Qwen2.5はシステムプロンプトの理解力が非常に高いので、役割を与えると精度が跳ね上がります。

# 推論の実行
response = llm.create_chat_completion(
    messages=[
        {"role": "system", "content": "あなたは優秀なエンジニアです。簡潔かつ技術的に正確な回答をしてください。"},
        {"role": "user", "content": "Pythonで高速な非同期処理を書く際の注意点を3つ教えてください。"}
    ],
    temperature=0.7, # 創造性と正確性のバランス
    max_tokens=1024  # 回答の最大長
)

# 結果の出力
print(response["choices"][0]["message"]["content"])

期待される出力

1. イベントループのブロック回避: time.sleep()などの同期関数を避け、必ずawait可能な非同期ライブラリを使用してください。
2. セマフォによる流量制限: 大量の非同期タスクを一度に投げるとリソースを食いつぶすため、asyncio.Semaphoreで同時実行数を制御すべきです。
3. エラーハンドリング: TaskGroup（Python 3.11以降）などを活用し、例外が発生した際に他のタスクが宙に浮かないよう適切に管理してください。

出力結果を見て、日本語が不自然でないか、論理が通っているかを確認してください。 UnslothのDynamic GGUFは、従来の量子化で見られた「文章の後半で支離滅裂になる」現象が劇的に改善されています。 レスポンス速度も、RTX 4090なら毎秒40〜60トークン程度は出ているはずです。

Step 4: 実用レベルにする（APIサーバー化）

単発のスクリプトで終わらせず、ローカルでAPIサーバーを立てて、普段使いのツールと連携させます。 llama-cpp-pythonにはOpenAI互換のAPIサーバー機能が備わっているため、これを利用するのが最も簡単です。

# OpenAI互換サーバーを起動
python -m llama_cpp.server --model $MODEL_PATH --host 0.0.0.0 --port 8000 --n_gpu_layers -1

このコマンドを叩くだけで、あなたのPCが「自前GPT-4oサーバー」になります。 あとは、CursorやDify、あるいは自作のWebアプリから http://localhost:8000/v1 をベースURLとして指定するだけです。 私はこの方法で、外部にデータを送りたくない機密性の高いソースコードのレビューをローカルで完結させています。

さらに実務で使い倒すなら、以下のエラーハンドリングとリトライ処理を組み込んだラッパー関数を作っておくと重宝します。

import time

def generate_with_retry(prompt, retries=3):
    for i in range(retries):
        try:
            # サーバーが起動している前提でリクエスト
            # ここでは内部ライブラリを直接叩く例
            return llm.create_chat_completion(
                messages=[{"role": "user", "content": prompt}]
            )
        except Exception as e:
            print(f"エラー発生。{i+1}回目リトライ中...: {e}")
            time.sleep(2)
    return None

よくあるトラブルと解決法

次のステップ

この記事で、Qwen2.5-32Bを最高効率で動かす環境が手に入りました。 ここから先は、この強力な「脳」をどう活用するかが鍵です。 まずは、Difyをローカルにインストールし、今回立てたAPIサーバーを接続して「自社ドキュメント特化型RAG」を構築してみてください。

また、Unslothが公開しているノートブックを使えば、今回使ったモデルを自分のデータで追加学習（Fine-tuning）することも可能です。 VRAM 24GBあれば、LoRAを用いた学習も十分に可能です。 「モデルを動かす」段階から「モデルを育てる」段階へ。 ローカルLLMの世界は、ここからが本当の面白さです。

よくある質問

Q1: RTX 3060 (12GB) しか持っていないのですが、動かせますか？

32Bモデルを12GBで動かすのは、Dynamic GGUFを使っても「IQ2_M」などの極端な量子化が必要になります。回答精度が著しく低下するため、正直おすすめしません。Qwen2.5-7Bや14Bを高い精度（Q8_0）で動かす方が、実用的な結果が得られます。

Q2: Dynamic V3.1と普通のGGUF、体感で違いはありますか？

あります。特に長文の要約や、複雑なコード生成において差が出ます。従来のGGUFでは論理が破綻しがちだった境界線上のタスクでも、Dynamic V3.1は粘り強く一貫性を保ってくれます。Perplexityの数値以上に、出力の「納得感」が違います。

Q3: llama.cpp以外の実行環境（Ollamaなど）でも使えますか？

はい、OllamaでもModelfileを自作すれば利用可能です。ただし、UnslothのDynamic GGUFの真価を発揮させるには、最新のllama.cppバックエンドが必要です。Ollamaが内蔵しているライブラリが古い場合、新形式を認識しないことがあるので、最新版へのアップデートを忘れずに。

あわせて読みたい

• RTX3090・4090でQwen2.5-27Bを動かす方法
• ローカルLLM用GPU・Mac選び方比較：Qwen2.5/Gemma2を快適に動かすVRAMの壁
• llama.cppとGGUF量子化の使い方入門：自作PCやMacでLLMを動かす全手順