モデル別実行レシピ

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

Qwen3.8-27Bを動かしてみると、ほかの人が公開した記録より遅い。そんなときは、まず設定の違いを確認してみてください。同じモデル名でも、ファイル、コンテキスト長、実行アプリが違えば条件は変わります。ここではMacのoMLXとRTXのllama.cppを分け、どの段階で待っているかを確認しながら一つずつ調整します。

実行レシピ

機器別の設定

1人で使う場合

使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。

使う機器を選ぶ

使用可能メモリ： 56GB / 帯域幅： 307GB/s

プロファイル

Apple MacBook Pro M5 Pro (64GB)

メモリに収まる

推奨ランタイム： oMLX (MLX 4ビット（GGUF Q4_K_Mとは別形式）) · ドキュメントに基づくランタイム設定

インストール後の初回実行や、毎日安定して使いたいときに

プロファイルのコンテキスト長

16,384 トークン

ランタイムの文書に基づく設定MBP M5 Pro 64GB · Q4 · 要求 1個

ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。

デコード速度の推定値

13.9 ~ 15.4 tok/s

1人で使う場合の推定値

最初のトークンまでの推定時間

36.0 ~ 41.9秒

プリフィル: 392 ~ 456 tok/s

推定メモリ使用量

約 21.21GB / 56GB

残余の余裕：少ない 34.8GB

サーバーアドレス

http://127.0.0.1:8000

ローカルのみ · 127.0.0.1

推定値は、計算ツールが推奨する量子化・高速化設定と 16,384トークンを基準にしています。上記の実行設定を測定した値ではありません。

このプロファイルの設定

設定値	この設定にする理由
モデルの重みMLX 4ビット（GGUF Q4_K_Mとは別形式）	MLXモデルのディレクトリを使います。Q4_K_MのGGUFとはファイル形式が異なります。
入力長の確認16,384	リクエスト前にモデル設定の入力上限を確認してください。この起動コマンドではコンテキスト長を指定していません。
KVキャッシュモデル設定で確認	この起動コマンドではKVキャッシュの精度を指定していません。
プリフィルのバッチサイズランタイム設定で確認	llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。
同時リクエスト数1	1件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。
メモリの余裕2GB以上	モデルの読み込み後に、実際のメモリ使用量とスワップの有無を確認します。

MBP M5 Pro 64GB 実行コマンド（oMLX)

Apple Silicon · MLX モデル · メモリガード

MODEL_DIR="$HOME/.omlx/models"
omlx serve \
  --model-dir "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --max-concurrent-requests 1 \
  --memory-guard balanced

まずこの設定で基準速度を記録し、その後は下の手順に沿って一項目ずつ変更します。

起動後の確認

01起動ログで、モデルの読み込み完了と実際のコンテキスト長を確認します。
02ウォームアップ後はリクエストを1件ずつ送ります。同じ長さの異なる入力を3つ使い、キャッシュを再利用しない初回の処理時間を記録します。
03同じ入力を繰り返した結果は、キャッシュ再利用の記録として分けます。初回入力の結果と混ぜないでください。
04プリフィルtok/s、デコードtok/s、ピークメモリをまとめて記録し、その後は一項目ずつ変更します。

変わる点と注意点

コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。

推奨設定での速度を見る MBP M5 Pro 64GB 価格・電力・販売構成の確認

1つずつ調整

高速化の手順

複数の値を一括で変更すると原因を特定するのが難しいです。

STEP 1
基準値を保存
初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。
とき：エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。
STEP 2
プリフィルのチャンクサイズを調整
1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。
とき： TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。
STEP 3
KVキャッシュ調整
コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。
とき：出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。
STEP 4
MTP・投機的デコーディング
対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。
とき： 3回の中央値が基準値より良くならなければ、無効に戻します。
STEP 5
コンテキスト拡張
実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。
とき：情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。

自分の機器の測定記録を送る

同じ条件で3回以上測定したJSONを読み込んでください。送信ボタンを押すまでは、このブラウザ内でのみ確認します。

受け付けるのは機器・モデル・実行条件と測定値だけです。プロンプト・回答・元のログ・ファイルパスは含めないでください。

記録ファイルがなければ、起動中のローカルサーバーと測定ツールで作成できます。Node.js 20以上が必要です。結果の自動送信は行いません。

測定方法を読む測定ツールをダウンロード機器・設定のテンプレートをダウンロード

測定JSONを読み込む（最大32KB）

内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。

設定の問題を報告

この設定でどこにつまずいたかを教えてください。報告を読めるのは管理者だけです。

報告する設定 · MBP M5 Pro 64GB · Qwen3.8 27B · バランス

Qwen3.8 27B · 4K

Qwen3.8 27B・入力4,096トークン・1人で使う場合の推定結果です。実測記録ではなく、速度体験と同じ計算値です。

最初のトークンまでの時間は、回答が始まるまでの待ち時間です。トークン生成速度は、その後の文章が出る速さです。長い文書を入力するなら両方を確認してください。

Mac mini M4 32GB · Qwen3.8 27B

量子化: Q4_K_M · 高速化: none · トークン生成: 5.1 ~ 5.7 tok/s · 最初のトークン: 16.4 ~ 35.5秒

入力処理: 116 ~ 252 tok/s · 必要メモリ: 17.6GB · 利用可能メモリ: 27GB

Mac mini M4 Pro 48GB · Qwen3.8 27B

量子化: Q4_K_M · 高速化: none · トークン生成: 12.3 ~ 13.7 tok/s · 最初のトークン: 7.8 ~ 14.3秒

入力処理: 289 ~ 530 tok/s · 必要メモリ: 17.6GB · 利用可能メモリ: 41GB

RTX 4090 24GB · Qwen3.8 27B

量子化: Q4_K_M · 高速化: none · トークン生成: 38.3 ~ 51.9 tok/s · 最初のトークン: 2.6 ~ 3.6秒

入力処理: 1,141 ~ 1,591 tok/s · 必要メモリ: 17.6GB · 利用可能メモリ: 22.5GB

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

上の選択欄で機器を選ぶと、対応する実行方法とコマンドが表示されます。デスクトップでは、互換性のある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サーバーの起動（BF16の重み）

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

公式BF16の重みとランタイム用の余裕を確保したNVIDIAサーバーで、127.0.0.1にバインドして実行します。

サーバーの起動と回答の確認は別です

モデル一覧を確認し、実際に読み込まれたモデルの識別子をリクエストに指定します。アドレスは実行したコマンドに合わせてください。このガイドではoMLXは8000、llama.cppは8080ポートを使います。下の例と違う場合は、アドレスを直してから短い質問を送ります。

回答が少しずつ届くか、アプリが思考過程と最終回答を区別できるかを確認します。思考トークンの生成が長く続くと、最終的な文章が画面に出るまで時間がかかることがあります。その時間をすべてプリフィルと誤って記録しないよう、サーバーログも見てください。

基本的な質問への回答が完了したら、普段使う文書を送ってみてください。短い挨拶で出た最高tok/sより、その文書で回答が始まるまでの時間と完了までの時間のほうが、実際の使い心地に近い指標になります。

APIの状態確認とチャットリクエストのテスト

# 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
  }'

この例ではoMLXは8000、llama.cppは8080ポートを使います。起動したランタイムに合わせてアドレスを変更してください。

どの段階で待っているかを確認する

回答が始まるまで長く待つ場合は、プリフィルのチャンクサイズ、入力長、キャッシュの状態を確認します。回答が始まってから遅い場合は、CPUへ移された重みや、メモリ不足・スワップがないかを見ます。どちらもMTPの段階数だけで解決しようとすると、原因を見落としかねません。

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

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

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

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

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

NVFP4で実行するには

対応するNVFP4カーネルが必要です。Sparkの実測値とRTXの推定値は区別しています。

vLLM / SGLang · Inferact/Qwen3.8-27B-NVFP4

変更履歴

サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。

2026-09-06
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
2026-09-06
Qwen 27BのSpark設定から別エンジンのオプションを削除
Spark 1台・2台のSGLang設定に、llama.cpp専用の投機的デコーディングオプションが付かないよう修正しました。DFlash2・DSpark構成は、それぞれの専用モデルと実行経路を維持します。
2026-09-06
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
2026-09-06
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
2026-09-06
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。