このトピックでは、QwQ-32B モデルの特徴、主要なメトリック、エッジクラウドデプロイメントのベストプラクティス、およびテスト環境のセットアップについて説明します。このトピックでは、QwQ-32B モデルの包括的なガイドを提供し、モデルの特徴、デプロイメント要件、およびパフォーマンス最適化手法を迅速に理解できるようにします。これにより、エッジクラウド環境にモデルを効率的にデプロイおよび使用して、推論効率を向上させ、コストを削減できます。
QwQ-32B について
説明
QwQ-32B は、Qwen2.5-32B モデルに基づいてトレーニングされたオープンソースの推論モデルです。このモデルは、強化学習を通じてモデルの推論機能を大幅に向上させます。モデル数学コード(AIME 2024 および 2025、LiveCodeBench)やいくつかの一般的なメトリック(IFEval、LiveBench)などの主要なメトリックは、フルバージョンの DeepSeek-R1 のレベルに達しており、推論タスクにおいてパラメーター数が少ない高性能のパラダイムのブレークスルーを実現し、高コストな大規模モデルデプロイメントにより費用対効果の高い選択肢を提供します。
シナリオ
QwQ-32B モデルは、数学的論理推論、大規模ドキュメント処理、コード生成などのシナリオに適しています。また、中国語での知識ベースの会話検索や複数ラウンドの会話などのシナリオでも優れたパフォーマンスを発揮します。次の表に、一般的な推論シナリオを示します。
シナリオ | 平均入力長(トークン) | 平均出力長(トークン) | 典型的なアプリケーションケース |
数学的論理推論 | 0.5K~1.5K | 0.8K~3.6K | MATH 問題解決、LSAT 論理問題分析 |
知識ベースの会話検索 | 1K~4K | 0.2K~1K | MMLU 知識評価、医療相談 |
複数ラウンドの会話システム | 2K~8K | 0.5K~2K | カスタマーサービス会話、心理相談 |
大規模ドキュメント処理 | 8K~16K | 1K~4K | 論文要約、法的文書分析 |
コード生成とデバッグ | 0.3K~2K | 1K~5K | 関数の実装、デバッグ |
モデル推論の主要なメトリック
メトリック | 説明 |
モデル精度 | モデルの重みと計算で使用される数値精度。低精度のモデルは、メモリ使用量が少なく、リソースコストも低くなりますが、複雑なタスクでの精度は低下します。 |
同時実行性 | 同時に処理されるユーザーリクエストの数。同時実行性が高いほど、ビジネスキャパシティが大きくなります。ただし、同時実行性を高めると、GPU メモリと GPU メモリ帯域幅の使用量も増加します。 |
入力長 | ユーザーが提供するプロンプトのトークン数。GPU メモリ使用量に影響します。入力長が長いと、最初のトークンまでの時間(TTFT)に影響します。 |
出力長 | モデルによって生成される応答テキストのトークン数。GPU メモリ使用量に影響します。出力長が長いと、切り捨てまたはメモリ不足(OOM)エラーが発生します。 |
TTFT | ユーザーリクエストが開始されてから最初の出力トークンが受信されるまでの時間。ユーザーエクスペリエンスに影響します。TTFT は 1 秒未満、2 秒を超えないようにすることをお勧めします。 |
出力トークンあたりの時間(TPOT) | 各出力トークン(最初のトークンを除く)を生成するために必要な平均時間。生成速度と読書体験との一致を反映します。TPOT は 50 ミリ秒未満、100 ミリ秒を超えないようにすることをお勧めします。 |
シングルチャネルスループット | チャネルあたりのトークン出力レート(トークン/秒)。シングルチャネルスループットが低いと、カスタマーエクスペリエンスが低下します。10 トークン/秒~30 トークン/秒の値にすることをお勧めします。 |
GPU メモリ使用量 | 実行時の GPU メモリ使用量の割合。GPU メモリ使用量は、モデルパラメーター、KV キャッシュ、および中間活性化値で構成されます。GPU メモリ使用量が高い(95% 超など)と、OOM エラーが発生し、サービスの可用性に影響を与える可能性があります。 |
エッジクラウドに QwQ-32B をデプロイするためのベストプラクティス
エッジクラウドは、グローバルに分散されたエッジノード上で複数仕様の異種計算リソースを提供し、さまざまなシナリオにおける異種計算要件に対応します。単一の GPU カードの GPU メモリは 12 GB~48 GB です。次の表に、エッジクラウドにさまざまな QwQ-32B モデル精度で推論サービスをデプロイする場合の推奨構成と推論パフォーマンスを示します。
QwQ-32B FP16 精度向けの推奨 48 GB GPU メモリ搭載デュアルカードインスタンス
48 GB GPU メモリ搭載デュアルカードインスタンスは VM です。次の表に、構成を示します。
環境パラメーター
CPU
96 コア
メモリ
384 GB
GPU
NVIDIA 48 GB × 2
オペレーティングシステム
Ubuntu 22.04
Docker バージョン
26.1.3
GPU ドライバー
ドライバーバージョン: 570.124.06
CUDA バージョン: 12.4
推論フレームワーク
vllm 0.7.2
さまざまなシナリオでのパフォーマンス
シナリオ
入力長
出力長
同時実行性
シングルチャネルスループット(トークン)
TTFT(秒)
TPOT(ミリ秒)
GPU メモリ使用量
数学的論理推論とコード生成
1K
4K
4
14.5
0.6
67.4
95%
1K
4K
8
13.3
1.6
71.3
95%
知識ベースの会話検索
4K
1K
2
14.2
1.8
68.6
95%
4K
1K
4
13
2.7
72.7
95%
複数ラウンドの会話と長文ドキュメント処理
4K
4K
2
14.64
1.7
71.5
95%
4K
4K
4
13.6
2.9
82.3
95%
数学的論理推論とコード生成:
このシナリオは、短い入力と長い出力が特徴です。入力長は 0.3 KB~2 KB、出力長は 0.8 KB~5 KB です。
同時実行性が 4 の場合、シングルチャネルスループットは 15 トークン/秒に近く、TTFT は 1 秒未満です。これは、ユーザーエクスペリエンスと費用対効果のバランスが取れています。同時実行性が 8 の場合、TTFT が大きくなるとユーザーエクスペリエンスにわずかな影響がありますが、許容範囲内です。コストを削減したい場合は、同時実行性を高めることができます。
知識ベースの会話検索:
このシナリオは、長い入力と短い出力が特徴です。入力長は 1 KB~4 KB、出力長は 0.2 KB~1 KB です。
インスタンスの最適な同時実行性は 2 です。同時実行性が 4 に増加すると、TTFT は 2 秒を超えます。ネットワークレイテンシを考慮すると、ユーザーエクスペリエンスへの影響は許容範囲内です。
複数ラウンドの会話と長文ドキュメント処理:
このシナリオは、長い入力と長い出力が特徴です。入力長は 2 KB~16 KB、出力長は 1 KB~4 KB です。
入力長が長くなると、メモリ消費量が増加するだけでなく、TTFT にも大きな影響があります。インスタンスの最適な同時実行性は 2 です。ビジネス状況に応じて、入力長と同時実行性を調整できます。
QwQ-32B INT4 精度向けの推奨 12 GB GPU メモリ搭載 5 カードインスタンス
12 GB GPU メモリ搭載 5 カードインスタンスはベアメタルインスタンスです。次の表に、構成を示します。
環境パラメーター
CPU
24 コア × 2、3.0 GHz~4.0 GHz
メモリ
256 GB
GPU
NVIDIA 12 GB × 5
オペレーティングシステム
Ubuntu 20.04
Docker バージョン
28.0.1
GPU ドライバー
ドライバーバージョン: 570.124.06
CUDA バージョン: 12.4
推論フレームワーク
vllm 0.7.2
さまざまなシナリオでのパフォーマンス
12 GB GPU メモリ搭載 5 カードインスタンスのシングルチャネルスループットは、シングルチャネルとマルチチャネルの両方の同時実行性のパフォーマンス要件を満たすことができます。ただし、シングルカード GPU メモリのサイズが原因で、TTFT パフォーマンスは満足のいくものではありません。この構成を使用して、数学的論理推論とコード生成サービスをデプロイすることをお勧めします。入力長が長い知識ベースの会話検索、複数ラウンドの会話、長文ドキュメント処理などのシナリオでは、48 GB GPU メモリ搭載デュアルカードインスタンスを使用することをお勧めします。
シナリオ
入力長
出力長
同時実行性
シングルチャネルスループット(トークン)
TTFT(秒)
TPOT(ミリ秒)
GPU メモリ使用量
数学的論理推論とコード生成
1K
4K
2
37
1.3
26.4
96.5%
1K
4K
4
32.5
1.7
28.7
96.5%
1K
4K
8
24.6
3.5
61.5
96.5%
知識ベースの会話検索
4K
1K
1
33.5
4.7
25.1
96.5%
複数ラウンドの会話と長文ドキュメント処理
4K
4K
1
35.8
4.7
26.6
96.5%
8K
4K
1
21.9
9.3
43.3
96.5%
数学的論理推論とコード生成
同時実行性が 2 の場合、シングルチャネルスループットは 37 トークン/秒に達し、TTFT は 1.3 秒です。これは、ユーザーエクスペリエンスと費用対効果のバランスが取れています。同時実行性を 8 に増やすと、ユーザーエクスペリエンスへの影響が大きくなります。費用対効果を向上させたい場合は、同時実行性を 4 に増やすことができます。
知識ベースの会話検索、数学的論理推論、およびコード生成
入力長が長いため、GPU メモリ使用量が高く、同時実行性が 1 の場合、TTFT は 5 秒近くになり、アプリケーションの本番環境には適していません。ただし、この構成を使用して POC 環境を構築できます。
テスト環境を構築する
48 GB GPU メモリ搭載デュアルカードインスタンスを作成して初期化する
ENS コンソールでインスタンスを作成する
ENS コンソールにログインします。
左側のナビゲーションウィンドウで、 を選択します。
[インスタンス] ページで、[インスタンスの作成] をクリックします。 ENS インスタンスパラメーターの構成方法については、「インスタンスを作成する」をご参照ください。
ビジネス要件に基づいてパラメーターを構成できます。次の表に、推奨構成を示します。
ステップ
パラメーター
推奨値
基本構成
課金方法
サブスクリプション
インスタンスタイプ
x86 コンピューティング
インスタンス仕様
NVIDIA 48 GB × 2
詳細な仕様については、カスタマーマネージャーにお問い合わせください。
イメージ
Ubuntu
ubuntu_22_04_x64_20G_alibase_20240926
ネットワークとストレージ
ネットワーク
セルフビルドネットワーク
システムディスク
ウルトラディスク、80 GB 以上
データディスク
ウルトラディスク、1 TB 以上
システム設定
パスワードの設定
カスタムキーまたはキーペア
注文を確認します。
システム設定が完了したら、右下隅にある [注文の確認] をクリックします。システムは構成に基づいてインスタンスを構成し、価格を表示します。支払いが完了すると、ページは ENS コンソールにジャンプします。
作成されたインスタンスは、ENS コンソールで確認できます。インスタンスが 実行中 の状態であれば、インスタンスは使用可能です。
オペレーションを呼び出してインスタンスを作成する
OpenAPI ポータル でオペレーションを呼び出してインスタンスを作成することもできます。
次のセクションでは、オペレーションパラメーターのリファレンスコードについて説明します。以下を構成できます。
{
"InstanceType": "ens.gnxxxx", <インスタンスタイプ>
"InstanceChargeType": "PrePaid",
"ImageId": "ubuntu_22_04_x64_20G_alibase_20240926",
"ScheduleAreaLevel": "Region",
"EnsRegionId": "cn-your—ens-region", <エッジノード>
"Password": <YOURPASSWORD>, <パスワード>
"InternetChargeType": "95BandwidthByMonth",
"SystemDisk": {
"Size": 80,
"Category": "cloud_efficiency"
},
"DataDisk": [
{
"Category": "cloud_efficiency",
"Size": 1024
}
],
"InternetMaxBandwidthOut": 5000,
"Amount": 1,
"NetWorkId": "n-xxxxxxxxxxxxxxx",
"VSwitchId": "vsw-xxxxxxxxxxxxxxx",
"InstanceName": "test",
"HostName": "test",
"PublicIpIdentification": true,
"InstanceChargeStrategy": "instance", <インスタンスに基づく課金>
}インスタンスにログインしてディスクを初期化する
インスタンスにログインする
インスタンスへのログイン方法については、「インスタンスに接続する」をご参照ください。
ディスクを初期化する
ルートディレクトリを展開します。
インスタンスを作成またはサイズ変更した後、インスタンスを再起動せずにルートパーティションをオンラインで展開する必要があります。
# クラウド環境ツールキットをインストールします。 sudo apt-get update sudo apt-get install -y cloud-guest-utils # GPT パーティショニングツール sgdisk が存在することを確認します。 type sgdisk || sudo apt-get install -y gdisk # 物理パーティションを展開します。 sudo LC_ALL=en_US.UTF-8 growpart /dev/vda 3 # ファイルシステムのサイズを変更します。 sudo resize2fs /dev/vda3 # サイズ変更の結果を確認します。 df -h
データディスクをマウントします。
データディスクをフォーマットしてマウントする必要があります。次のセクションでは、サンプルコマンドを示します。ビジネス要件に基づいてコマンドを実行してください。
# 新しいディスクを識別します。 lsblk # ディスクをパーティション分割せずにフォーマットします。 sudo mkfs -t ext4 /dev/vdb # マウントを構成します。 sudo mkdir /data echo "UUID=$(sudo blkid -s UUID -o value /dev/vdb) /data ext4 defaults,nofail 0 0" | sudo tee -a /etc/fstab # マウントを確認します。 sudo mount -a df -hT /data # 権限を変更します。 sudo chown $USER:$USER $MOUNT_DIR
説明インスタンスに基づいてイメージを作成する場合は、
/etc/fstabファイルからext4 defaults 0 0行を削除する必要があります。そうしないと、イメージに基づいて作成されたインスタンスを起動できません。
vLLM 推論環境をインストールする
CUDA をインストールする
CUDA のインストール方法については、「CUDA Toolkit 12.4 ダウンロード」をご参照ください。
# CUDA Toolkit をインストールします。
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_570.124.06_linux.run
chmod +x cuda_12.4.0_570.124.06_linux.run
# この手順には時間がかかり、GUI との対話が必要です。
sudo sh cuda_12.4.0_570.124.06_linux.run
# 環境変数を追加します。
vim ~/.bashrc
export PATH="$PATH:/usr/local/cuda-12.8/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda-12.8/lib64"
source ~/.bashrc
# インストールが成功したかどうかを確認します。
nvcc -V
nvidia-smi補助ソフトウェアをインストールする(オプション)
uv は、Python 仮想環境と依存関係を管理するための優れたツールであり、複数のモデルを実行する必要があるクラスターに適しています。uv のインストール方法については、「uv のインストール」をご参照ください。
# uv をインストールします。デフォルトでは、uv は ~/.local/bin/ にインストールされます。
curl -LsSf https://astral.sh/uv/install.sh | sh
# ~/.bashrc を編集します。
export PATH="$PATH:~/.local/bin"
source ~/.bashrc
# クリーンな venv 環境を作成します
uv venv myenv --python 3.12 --seed
source myenv/bin/activateuv をインストールした後に構成した CUDA 環境変数が無効になり、nvcc\nvidia-smi が見つからない場合は、次の操作を実行します。
vim myenv/bin/activate
追加
export PATH="$PATH:/usr/local/cuda-12.8/bin"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda-12.8/lib64"
export PATH の後# vLLM と ModelScope をインストールします。
uv pip install vllm==0.7.2
uv pip install modelscope
# GPU 監視ツール。NVIDIA が提供するデフォルトツール System Management Interface(SMI)を使用することもできます。
uv pip install nvitopQwQ-32B モデルと vLLM ベンチマークスクリプトをダウンロードする
# 容量不足によるエラーを回避するために、モデルをデータディスク /data にダウンロードします。
mkdir -p /data/Qwen/QwQ-32B
cd /data/Qwen/QwQ-32B
modelscope download --model Qwen/QwQ-32B --local_dir .
# オプション。データセットをダウンロードします。
wget https://www.modelscope.cn/datasets/gliang1001/ShareGPT_V3_unfiltered_cleaned_split/resolve/master/ShareGPT_V3_unfiltered_cleaned_split.json
# 必要に応じて git をインストールします。
apt update
apt install git -y
# テストスクリプトを含む vllm.git をダウンロードします。
git clone https://github.com/vllm-project/vllm.gitモデルをオンラインでテストする
vLLM サーバーを起動する
vllm serve /data/Qwen/QwQ-32B/ \
--host 127.0.0.1 \
--port 8080 \
--tensor-parallel-size 2 \
--trust-remote-code \
--served-model-name qw \
--gpu-memory-utilization 0.95 \
--enforce-eage \
--max-num-batched-Tokens 8192 \
--max-model-len 8192 \
--enable-prefix-caching テストを開始する
python3 ./vllm/benchmarks/benchmark_serving.py --backend vllm --served-model-name qw --model /data/Qwen/QwQ-32B --dataset-name random --random-input 1024 --random-output 4096 --random-range-ratio 1 --max-concurrency 4 --num-prompts 10 --host 127.0.0.1 --port 8080 --save-result --result-dir /data/logs/ --result-filename QwQ-32B-4-1-4.logテストを完了する
次の表に、テスト結果を示します。
