Qwen3.6 35B-A3B：vLLMとqwen3パーサーの設定

ハードウェア別速度チューニングおよびサーバーリシピ要約

重み、KVキャッシュ、プリフィルバッチ、同時リクエストと加速機能を分離し、バランス・速度・長い文脈プロファイルで提供します。

詳細ページから、プロフィール別に実行コマンド、適用値、停止すべき条件、および測定順序を確認できます。実行コマンドは、モデルファイルと実行プログラムが確認された組み合わせにのみ表示されます。

24GBでは、モデルをメモリに載せた後の余裕が重要

Q4変換版の対応は、約20GB程度の推定を出発点としていますが、実際のファイルを確認します。モデルの重みおよび4K〜8K文脈のキャッシュ、実行空間が含まれている必要があります。GPUにロードされたというメッセージだけでは、長い対話までを保証することはできません。

32GB以上でも他のアプリやキャッシュ用の余裕を確認する必要があります。公式チェックポイントはQ4変換版と容量が異なります。以下に示したマルチGPUの例とデスクトップファイルを開くコマンドは異なるパスです。

対応するモデルと実行アプリのサポートをまず確認してください。正常に動作していたファイルがあれば保存し、新しいパスを試行することで、問題が発生した際には比較の基準が残ります。

GPUの数に関するサーバーの例は推奨購入とは限りません

公式vLLMサンプルの並列数は、搭載された設備およびメモリ・サポート条件に合わせて決定すべきです。コメントに記載された8を「GPUを8台使用する」と解釈しないでください。デスクトップQ4を実行する目的であれば、LM Studioまたはその設備選択ツールのパスを使用してください。

vLLMでは、そのモデルをサポートするバージョンおよびQwen3推論パーサーを確認します。この例ではvLLM 0.19.0以上を出発点としていますが、実際に実行される条件は、現在インストールされているバージョンがサポートしているかどうかです。サーバーはまずローカルアドレスのみに設定します。

MTPは、基準回答が正常に生成された後に、サポートされる組み合わせに追加します。複数のオプションを一度にコピーした最高記録よりも、デフォルト値と変更された項目が残った記録の方が、私の環境で原因を特定しやすいです。

GPU_COUNT=8 # 공식 예시는 8 GPU, 실제 구성에 맞춰 수정
vllm serve Qwen/Qwen3.6-35B-A3B   --host 127.0.0.1   --port 8000   --tensor-parallel-size "$GPU_COUNT"   --max-model-len 8192   --reasoning-parser qwen3   --gpu-memory-utilization 0.92

lms ls
lms load <qwen-3.6-35b-identifier> --gpu=max --context-length=8192
lms server start --port 1234

思考時間と回答生成時間は区別します

推論パーサーは、思考プロセスと最終結果をアプリが区別できるように助けます。画面に最終文が遅れて表示されるとき、その時点で思考トークンが生成されているか確認してください。これらをすべてプリフィルで記録してしまうと、入力処理性能を誤って読み取ることになります。

同じ質問の入力長と最大出力、思考設定を揃えて比較します。準備実行後、3回の中央値と実際の出力トークン数を残します。回答長が大きく異なる2つの実行の完了時間だけを比較しても、生成速度を分離するのは難しいです。

以下のテストはvLLMの8000アドレスです。LM Studioを使用した場合は1234とロードされたモデル識別子で対応します。アドレスが異なる場合、モデルが遅い問題ではなく別のサーバーに質問された可能性があります。

curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "Qwen/Qwen3.6-35B-A3B",
    "messages": [
      {"role": "user", "content": "파이썬으로 이진 탐색 함수를 작성하고 시간 복잡도를 설명해줘."}
    ],
    "max_tokens": 1024,
    "stream": true
  }'

コンテキスト長と高速化の設定は、一つずつ変える

24GBの余裕がなければ、リクエストを1つに固定し、短いコンテキストを維持してみます。その後、必要な入力長に拡張する際にはキャッシュとピークメモリを確認します。速度が急に低下した場合は、スワップやCPUに移された重みがあるかをまず確認します。

MTPを有効にすると、平均承認長と実際のデコードが改善されたかどうかを確認します。一つのコードの出力された拡大率を、一般的な文章生成にも適用しないでください。キャッシュの精度とプリフィルチャンクも個別に比較しなければなりません。

長い入力の待ち時間だけが問題であれば、デコードの加速よりも入力処理とキャッシュを確認する価値があります。どのセグメントが遅いのかを記録しておくことで、設定を追加せずに次の実験を絞ることができます。

起動できたら、普段の作業を最後まで試す

ビット探索コードだけでは十分に検証されたとは言いません。実際に修正したいコードやドキュメントを投入し、結果を確認してください。正しい答えが得られ、かつ待ち時間も妥当であることが両方確認されなければ、使用可能な設定とは言えません。

その状態のモデルファイルとランタイム、文脈およびアクセラレーションを保存してください。より大きな設備を検討する際も、この条件が比較基準になります。すでに十分であれば、新しいGPUに代えて現在の構成を継続するのも、このレシピが提供できる結果の一つです。