Qwen3.6ローカル導入のVRAM：27Bと35B-A3Bの量子化を実測する

ローカル展開用の Qwen3.6 の 2 つの一般的なオープン ウェイト バージョンは、Qwen3.6-27B と Qwen3.6-35B-A3B です。前者は 27B の高密度モデルで、後者は合計パラメータが約 35B で、各トークンが約 3B のパラメータをアクティブにする MoE モデルです。

MoE にはアクティベーション パラメータが少ないため、通常はトークンあたりの計算量を減らすことができますが、3B にロードする必要がある重みは減りません。グラフィックス カードを選択するときは、まず総重量と量子化ファイルを確認し、次に KV キャッシュとランニング マージンを計算する必要があります。

3種類のメモリ値を混同しない

• 理論上の重量体積: パラメータ量とビット幅を使用して計算され、予備スクリーニングにのみ使用されます。
• GGUF ファイル サイズ: 定量的なメタデータを含む、ディスク上の特定の変換ファイルのサイズ。
• ランタイム メモリ: 重み、KV キャッシュ、計算バッファ、マルチモーダル プロジェクション、バックエンド オーバーヘッドの合計。

モデル ファイル、コンテキスト、バックエンドの説明なしに「Q4 には 18GB のビデオ メモリが必要」とオンラインで書くことは、実測からの結論とみなされません。

理論上の重みサイズ

式:

1

权重 GiB ≈ 参数量 × 位宽 ÷ 8 ÷ 1024³

実際の G​​GUF は通常、対応する裸重量の推定値よりも大きくなります。有効な平均ビット幅は第 4 四半期と第 5 四半期のプラン間で異なるため、この表はダウンロード ページの実際のファイル サイズを表すものではありません。

利用可能なVRAMから候補を絞る

以下は展開の開始点であり、保証値ではありません。デフォルトは単一同時実行、約 4K コンテキストで、必要な CPU オフロードを許可します。

ビジョン mmproj を同時にロードしたり、コンテキストを数十万のトークンに増やしたり、同時実行性を高めたりすると、メモリ要件が大幅に増加します。モデル カードの最大コンテキストをデフォルトの起動値として扱わないでください。

GGUF が選択されている場合は完全なファイル名を記録します

少なくとも次のことを文書化します。

1
2
3
4
5
6

基础模型：Qwen/Qwen3.6-27B 或 Qwen/Qwen3.6-35B-A3B
转换仓库与 commit：
GGUF 文件名：
量化：Q4_K_M / Q5_K_M / 其他
SHA256：
llama.cpp 版本：

サードパーティの GGUF は、公式の基本重量まで追跡可能であり、変換ツールとライセンスを説明する必要があります。倉庫名が似ているだけであり、文書が正式な情報源からのものであることを証明することはできません。

llama.cppの実測手順

4K コンテキスト、単一同時実行から開始:

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen-model-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8080

別の端末レコードを開きます。

1

nvidia-smi --query-gpu=name,memory.total,memory.used,driver_version --format=csv

起動ログには、モデル バッファー、KV キャッシュ、オフロード層番号、およびバックエンド情報も保存されます。次に、同じプロンプト ワードをそれぞれ 4K および 8K コンテキストで実行し、ピーク メモリ、最初のトークン遅延、および生成されたトークン/秒を記録します。

Ollamaで測定する

1

ollama run qwen3.6:27b

の特定のラベルは、Ollama モデル ライブラリの現在のページの影響を受けます。実行後に実行します。

1
2

ollama ps
nvidia-smi

ollama ps の PROCESSOR は、CPU/GPU の割り当てを示します。モデル ラベルで定量化タイプが指定されていない場合、結果を GGUF の Q4_K_M と直接比較することはできません。

高密度モデルと MoE の間のデプロイメントの違い

27B 密モデルの各層が計算に参加し、その構造は比較的単純です。 35B-A3B は、トークンに基づいて一部の専門家にルーティングされます。 MoE を展開するときは、耐荷重に加えて、バックエンドがエキスパート ルーティングを正しく実装しているかどうかにも注意する必要があります。

考えられる違いは次のとおりです。

• 同じ重量ボリュームの下で、各トークンの計算量は異なります。
• MoE はメモリ アクセスとエキスパート スケジューリングに対してより敏感です。
• バックエンドが異なれば、エキスパート向けの GPU/CPU 割り当て戦略も異なります。
• 一部の古いバージョンのバックエンドは構成を読み取ることができますが、構成を正しく生成できません。
• 複数のカードが割り当てられている場合、エキスパートのクロスデバイス転送がボトルネックになる可能性があります。

したがって、35B-A3B は、速度に関しては 3B モデルのみと比較することはできず、ビデオ メモリに関しては 35B 高密度モデルのみと比較することはできません。

ダウンロード前にディスクとRAMを見積もる

ローカル導入ではダウンロードキャッシュ、GGUF、実行時メモリマップが必要です。複数の量子化を試すと、先にディスクが不足する場合があります。

Windows では以下を確認できます。

1
2
3
4
5

Get-PSDrive -PSProvider FileSystem |
  Select-Object Name, Used, Free

Get-CimInstance Win32_ComputerSystem |
  Select-Object TotalPhysicalMemory

システム メモリは、オフロードされていない重みと等しいだけではありません。モデル パーツが CPU 上に配置されている場合は、オペレーティング システム、ファイル キャッシュ、KV キャッシュ、およびバックエンド バッファー用のスペースも予約する必要があります。システムが頻繁にページを変更し始めると、生成速度が大幅に低下します。

2 つのモデルに対して独立したスタートアップ コンフィギュレーションを作成する

同じ長いコマンドを繰り返し変更しないでください。個別のスクリプトを作成すると、27B をテストするときに 35B コンテキストまたはファイルの誤用を回避できます。

27B 開始コマンド

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen3.6-27b-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8081

35B-A3B 開始コマンド

1
2
3
4
5
6
7

.\llama-server.exe `
  -m .\qwen3.6-35b-a3b-q4_k_m.gguf `
  -ngl 999 `
  -c 4096 `
  -np 1 `
  --host 127.0.0.1 `
  --port 8082

ポートを分離した後、ポートを 1 つずつ起動して比較できます。ビデオ メモリが不足している場合は、2 つのサービスを同時に実行しないでください。

チャット テンプレートを確認し、出力を検討する

Qwen のバージョンが異なると、チャット テンプレート、思考モード、特別なトークンが異なる場合があります。以下の現象が発生した場合は、まずモデルカードとバックエンドのサポートを確認してください。

• system、userなどの文字ラベルをそのまま出力、印刷します。
• 答えは繰り返されます。 ・思考内容と最終的な答えとの境界が異常である。
• JSON 出力の前に追加のタグを混ぜます。
• ツール呼び出しパラメータが有効な JSON ではありません。

ランダムな特殊トークンを削除して「修正」しないでください。テンプレートのエラーにより、ベンチマーク テストと実際のアプリケーションの間でまったく異なる結果が生じる可能性があります。

API 接続とモデル ID チェック

両方のサービスを開始した後、モデル リストを個別に確認します。

1
2

curl.exe http://127.0.0.1:8081/v1/models
curl.exe http://127.0.0.1:8082/v1/models

は、同じリクエストを再度使用して比較します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

$payload = @{
  model = 'local-qwen'
  messages = @(
    @{ role = 'user'; content = '用 JSON 返回三个 Linux 日志排查步骤。' }
  )
  temperature = 0
} | ConvertTo-Json -Depth 5

Invoke-RestMethod `
  -Uri 'http://127.0.0.1:8081/v1/chat/completions' `
  -Method Post `
  -ContentType 'application/json' `
  -Body $payload

ポートを 8082 に変更してテストを繰り返します。サービス ログ内の実際のモデル ファイルを確認して、クライアントから渡された model フィールドがバックエンドによってロードされたファイルをマスクしないようにします。

KV キャッシュは個別に測定する必要があります

測定シーケンスは次のとおりです。

1. サービスは開始されたばかりで、リクエストされていません。
2. 1K トークンを入力します。
3. 4K トークンを入力します。
4. 8K トークンを入力します。
5. 8K を維持し、2 番目の同時リクエストを追加します。

各ステップでのメモリのピークと応答時間を記録します。起動後にビデオ メモリのみを記録すると、長いコンテキストと同時キャッシュが失われます。

毎回異なるトークン番号を避けるために、テスト テキストはローカルの固定ファイルから取得する必要があります。まずクライアント トークナイザー統計を使用するか、API usage フィールドから実際の入力トークンを確認することができます。

マルチカード展開では、まず割り当て結果を確認します

24GB グラフィックス カードを 2 枚使用しても、自動的に理想的な 48GB のスペースが得られるとは限りません。異なるバックエンドはレイヤー、テンソル、またはエキスパートごとに分割でき、カードは追加の出力レイヤーとキャッシュをホストすることもできます。

各カードを観察してください。

1

nvidia-smi --query-gpu=index,name,memory.total,memory.used,utilization.gpu --format=csv -l 1

一方のカードが OOM に近く、もう一方のカードにはまだ多くのアイドル時間が残っている場合は、現在の llama.cpp のテンソル分割とデバイス選択パラメーターを確認する必要があります。パラメータはバージョンによって変わります。使用する前に、対応するリリースのヘルプ出力を参照してください。

1

.\llama-server.exe --help

古いバージョンのマルチカード パラメータをコピーして、本番環境に直接使用しないでください。

ビジュアル入力には 3 つの一致が必要です

マルチモーダル展開では、次の両方を満たす必要があります。

• Qwen モデルはネイティブに視覚入力をサポートします。
• mmproj は特定の基本モデルに一致します。
• 現在の llama.cpp ビルドは、このマルチモーダル アーキテクチャをサポートしています。

ビジュアル投影ファイルを 27B と 35B-A3B の間で混在させることはできません。テストするときは、最初に小さな画像と明確な質問を使用し、次にログが実際にビジュアル エンコーダーをロードするかどうかを確認します。テキストによる回答を受け取っただけでは、画像が処理されたことにはなりません。

また、ビジュアルトークンはコンテキストとキャッシュも拡張するため、画像のサイズと数量も追跡します。

独自のタスクのベースラインを確立する

少なくとも 5 種類のタスクを含めることをお勧めします。

各タスクは、温度、シード、最大出力長を固定して少なくとも 3 回実行されます。 MoE と高密度モデルの変動、速度、精度を一緒に記録する必要があります。

速度は 2 つの指標に分割する必要があります

• プロンプト処理: 入力、長いテキスト、RAG の読み取り速度がより重視されます。
• トークン生成: 回答を生成する速度。チャット エクスペリエンスはそれにさらに注意を払います。トークンを 1 つだけ発行すると混乱を招く可能性があります。 35B-A3B の生成は速いが、長い入力の処理が遅い場合は、ドキュメントのワークフローには適していない可能性があります。

最初のトークン遅延も個別にリストする必要があります。ユーザーは多くの場合、最終的なスループットよりも最初の単語を待つ時間のほうに敏感です。

高精度量子化へ上げる判断基準

Q4_K_M から Q5_K_M に進む前に、次のように答えてください。

• 重要なタスクのエラー率が大幅に減少したかどうか。
• 構造化された出力がより安定しているかどうか。
• ビデオ メモリに KV キャッシュ用の余地がまだ残っているかどうか。
• 生成速度の低下は許容されますか?
• フル GPU から部分的な CPU オフロードに変更するかどうか。

量子化をアップグレードした結果、大量のオフロードが発生する場合、品質のわずかな向上は速度の低下に見合わない可能性があります。

よくある質問

35B-A3B が 27B より大きいのに、潜在的に高速である理由

より多くの合計重みを保存する必要がありますが、各トークンは一部のエキスパートのみをアクティブにします。実際の速度は、専門家のルーティング、メモリ帯域幅、バックエンドの最適化によって決まり、アクティベーション パラメータだけから推定することはできません。

どの 24GB グラフィックス カードを選択すればよいですか?

最初に 27B Q4/Q5 をテストし、次に 35B-A3B Q4 をテストします。コンテキストとタスクを修正し、完全な GPU 常駐、速度、精度を比較し、MoE が確実な勝利であるとは直接考えません。

低い量子化に変更しても OOM が発生するのはなぜですか?

コンテキスト、同時実行性、視覚的投影、またはその他のプログラムの占有に変更がない可能性があります。 GGUF ファイル サイズを比較するだけでなく、ブート ログと nvidia-smi を確認してください。

モデルカードの最大コンテキストを直接使用することは可能ですか?

理論上のサポートは、ネイティブ構成がそれに耐えられることを意味するものではありません。まずは 4K/8K から始めて、実際のニーズに応じて KV キャッシュを増やして記録します。

OOM 後の回復シーケンス

1. 同時実行をオフにし、-np 1 を維持します。
2. コンテキストを 8192 から 4096 または 2048 に減らします。
3. より小さな量子化に変更します。
4. GPU オフロードを削減し、システム メモリを使用して重量の一部を引き継ぎます。
5. ビデオメモリを占有している他のプロセスを停止します。
6. サービスを再起動し、起動ログから構成が有効になっていることを確認します。

CPU オフロードは「実行」を「ゆっくり実行」に変えるため、速度も同時に記録する必要があります。

27B または 35B-A3B

• シンプルな展開と安定したバックエンド互換性が必要です。優先度の比較は 27B です。
• MoE の推論効率に焦点を当てる: 同じハードウェアで 35B-A3B を測定。
• ビデオ メモリは 12 GB のみ: 小型モデルを優先し、モデルに大量のオフロードを強制しません。
• マルチモダリティの実行: 最初に公式モデル カードとバックエンドのビジュアル サポートを確認し、次に mmproj オーバーヘッドを含めます。

Qwenモデルカードとバックエンド資料

• Qwen3.6-27B オフィシャルモデルカード
• Qwen3.6-35B-A3B オフィシャルモデルカード
• llama.cpp公式倉庫