Qwen3.8-27Bの設定：MacのoMLXとRTXのllama.cpp

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

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

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

モデルファイルと実行アプリの対応を、まず確認する

デバイス選択機で現在のデバイスを選択すると、使用するパスと命令を確認できます。デスクトップでは、対応するQ4 GGUFまたはMLX変換版に基づいて確認します。約17GBほどのファイルサイズの通知は出発点に過ぎず、実際のダウンロードおよび実行時のメモリ使用量を確認する必要があります。

公式BF16モデルIDをサーバーに送るためのパスは、同じQ4ファイルを開くものではありません。27B重みだけを単純に計算しても約54GBの規模となり、より多くのワークスペースが必要になります。以下に示した公式サーバーの例を、24GBGPU用のQ4命令のようにコピーしないでください。

テキストの質問から正常に実行した後、画像入力と追加のアクセラレーションを確認します。最初のロードでモデルファイルとビジョン・MTPのサポートを同時に変更すると、どこで失敗したかを特定するのが難しいです。

一つの良好な設定を残します

Mac用oMLXおよびRTX用llama.cppの命令は、装置選択に応じて使用します。要求は1つに絞り、表示されたコンテキストから始めます。より大きなコンテキストまたは攻撃的なメモリ設定に直ちに移行するのではなく、まず正常な回答を残すことが重要です。

プリフィル、最初のトークンまでの時間、デコードおよびピークメモリを記録します。準備実行後に1回実行した結果、同じ入力に対して3回の中央値をもとに記録します。その後、プリフィルチャンクまたはキャッシュの精度を変更する際には、この記録をもとに実際の効果を判断します。

以下のvLLMコマンドは、別途NVIDIAサーバー経路に公式重みを格納できるものです。選択機のデスクトップコマンドと混同しないでください。サーバーは最初は127.0.0.1にのみ制限し、他のデバイスからのアクセスを想定する場合は、認証およびアクセス制限を別途準備します。

vllm serve Qwen/Qwen3.8-27B   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90

サーバーが起動されたことと、回答が生成されたことは異なります

モデルリストを確認し、実際にロードされた識別子をリクエストに含めます。oMLXはこのガイドの8000、llama.cppは8080のように選択した命令のアドレスを使用しなければなりません。以下の例アドレスと異なる場合はその部分を修正した上で短い質問を送信してください。

回答がチャンクで到着するかどうか、また思考プロセスと最終回答がアプリ内で区別されるかどうかを確認します。思考トークンを長期間生成する場合、画面に最終文が遅れて表示される可能性があります。その時間を純粋なプリフィルとして誤って記録しないよう、サーバーログも確認してください。

基本質問が完了したら、通常のドキュメントを送ってください。短い挨拶から得られた最高tok/sよりも、そのドキュメントの最初の回答と完了時間は実際の使用により近いです。

# 1. 로드된 모델 목록 확인
curl -N http://127.0.0.1:8000/v1/models

# 2. OpenAI 호환 챗 완성 API 호출
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "<local-model-identifier>",
    "messages": [
      {"role": "user", "content": "로컬 LLM 서빙의 장점을 세 가지로 요약해줘."}
    ],
    "temperature": 0.6,
    "max_tokens": 1024,
    "stream": true
  }'

遅いと感じたら、どの処理に時間がかかるかを見る

入力を受けた後、長時間待つ場合、プリフィルチャンクと入力長、キャッシュ状態を確認します。回答が開始された後で遅い場合は、CPUに移された重みがあるか、メモリの圧迫またはスワップが発生したかを確認します。この2つの問題をMTPステップの1つで解決しようとすると、原因を誤認してしまう可能性があります。

サポートされるファイルおよびランタイムでMTPを有効にした後は、同じ質問に対してデフォルト値と比較します。平均承認長が短い場合や検証コストが大きい場合、MTPを有効にしても利益を得られない可能性があります。キャッシュの精度とMTPを同時に変更しないでください。

必要な長文の文脈でメモリが不足する場合、まず要求数と長さを減らして戻りの基準を確保します。続けて、継続的に必要な処理においてのみ限界が繰り返されるかを確認の上、上位のメモリ構成を検討します。

良い記録よりも継続的に使う設定を残します

コードの修正とドキュメントの要約を行う場合、2種類の質問を残してください。一方だけが速くなる設定も存在します。速度だけでなく、実際の結果の誤差および実行失敗の有無も併せて確認しなければなりません。

最後に、モデルファイル・アプリバージョン・文脈・アクセラレーションオプションを保存します。更新後に問題が生じても、正常な構成に戻ることができます。最初から最も高速な数値を求めるのではなく、作業が完了するまでに必要な設定をまず作成した上で、その後で速度を上げるほうが、維持がしやすくなります。