Qwen3.8-27Bの機器別設定：MacはoMLX、RTXはllama.cpp

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

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

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

モデルファイルと実行アプリを合わせる

上の選択欄で機器を選ぶと、対応する実行方法とコマンドが表示されます。デスクトップでは、互換性のあるQ4 GGUFまたはMLX変換版を基準に確認します。約17GBというファイルサイズは目安にすぎません。実際のダウンロード容量と実行時のメモリ使用量を確かめてください。

公式のBF16モデルIDをサーバーに指定しても、同じQ4ファイルが読み込まれるわけではありません。27Bの重みだけでも単純計算で約54GBあり、さらに作業用メモリが必要です。下の公式サーバー例を、24GB GPUでQ4を動かすコマンドとしてコピーしないでください。

まずテキストの質問に正常に答えることを確認し、その後で画像入力や追加の高速化を試します。初回からモデルファイル、画像対応、MTPを同時に変えると、失敗の原因を切り分けにくくなります。

正常に動く設定を基準として残す

選んだ機器に合わせ、MacではoMLX、RTXではllama.cppのコマンドを使います。リクエストは一度に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へ移された重みや、メモリ不足・スワップがないかを見ます。どちらもMTPの段階数だけで解決しようとすると、原因を見落としかねません。

対応するファイルとランタイムでMTPを有効にしたら、同じ質問で基準値と比べます。平均採用トークン長が短かったり、検証の負荷が大きかったりすると、速くならない場合があります。キャッシュの精度とMTPを同時に変えないでください。

必要な長さのコンテキストでメモリが足りなければ、まずリクエスト数と長さを減らし、正常に動く基準へ戻します。普段必要な作業で繰り返し限界に当たるかを確かめてから、メモリの多い構成を検討してください。

一度の好記録より、毎日使える設定を残す

コードの修正と文書の要約を両方行うなら、それぞれのテスト用の質問を残してください。片方だけ速くなる設定もあります。速度と合わせて、出力の誤りや実行の失敗も確認します。

最後に、モデルファイル、アプリのバージョン、コンテキスト長、高速化オプションを保存します。更新後に問題が起きても、正常な構成へ戻せます。最初から最高速度を狙うより、必要な作業を最後までこなせる設定を作ってから速くするほうが、維持しやすくなります。