ローカルAIガイド

購入前に、速度と費用を確かめる

モデル別実行レシピ

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

機器を選ぶと、バランス・生成速度・長いコンテキスト向けのプロファイルと確認手順が表示されます。

Qwen3.8-27Bを最初に起動した日は問題なかったのに、長いコードの質問では待たされるとします。モデル名だけでは、他の人の速度記録と比較できません。まずMacのoMLXまたはRTXのllama.cppで使ったファイルとコンテキストを合わせ、ロード・最初の回答・生成のどこが遅いか確認し、設定を1つずつ変えてみます。

目次
実行条件と要点
  • oMLX 0.7.0は、対応するQwen3.8-27BチェックポイントでLightning MTPとDFlash2をサポートします。二つの生成高速化経路は一つずつ比較してください。
  • 重みの量子化とKVキャッシュの精度は別々に扱います。長いコンテキストでは、Q8のKVキャッシュと小さめのプリフィルバッチを検討します。
  • バランス設定で基準値を保存し、一項目ずつ調整します。3回の中央値を比べて、変更を残すか判断します。
機器別の実行設定へ移動

Qwen3.8 27B · 4K

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

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

Qwen3.8 27B · 4K
Qwen3.8 27B · 4K

Mac mini M4 32GB · Qwen3.8 27B

量子化2: 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

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

まず実際に使うコンピュータを機材セレクターで選びます。このガイドではMacのoMLXとRTXのllama.cppを別の経路として扱い、デスクトップでは互換性のあるQ4 GGUF3またはMLX4変換版を出発点にします。同じモデル名でもファイル形式とアプリが違えば、セレクターが示すコマンドも異なります。他の人の設定をコピーする前に、自分の機材と形式を合わせる理由はここにあります。

約17GBという案内はQ4ファイルを探すときの大まかな目安であり、実行中に必要なメモリ総量ではありません。ダウンロード後に正確なサイズを確認し、実行時にOS、アプリ、キャッシュのための領域が残るかも見ます。モデルファイルがディスクにあることと、モデルがメモリにロードされて回答できる状態であることは別です。

公式BF165のモデルIDをサーバーに渡す経路も別です。27Bの重みだけでも単純計算で約54GBになり、さらにランタイム6の作業領域が必要です。そのため、以下のvLLM例は公式サーバー用重みを実行できるNVIDIA環境を前提としており、24GB GPU7向けのQ4コマンドとして流用できません。同じモデル名でも配布ファイルと精度が変われば必要な環境も変わります。

最初にテキスト質問の基準を作っておけば、後で画像やMTP8を追加したときに比較しやすくなります。最初の試行でQ4ファイル、画像入力、MTPを一度に変えると、どれが失敗の原因か分かりにくくなります。ここではまずテキスト回答が完了する状態を作り、その後で選択したランタイムが対応する機能だけを加えます。

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

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

MacのoMLXまたはRTXのllama.cpp向けにセレクターが示したコマンドを適用し、一度に1件だけリクエストします。表示されたコンテキストで短いコード質問を最後まで回答させます。ここで確認するのは高いスコアではなく、モデルのロードから回答まで基本経路が動くことです。最初からコンテキストを大きくするとキャッシュ使用量が変わり、基準状態を作りにくくなります。

通常の回答が得られたら、その設定を記録します。準備実行の後、プリフィル9、最初のトークンまでの時間、デコード10、ピークメモリを3回分記録すれば、たまたま速かった1回だけで判断しにくくなります。同じ入力の再送は初回リクエストと分けて記録します。2回目には入力キャッシュが残る可能性があるため、その差をモデルや機材の固定的な速度差と解釈しないでください。

たとえば空入力を処理できない関数とその呼び出し元を一緒に入力したなら、依頼に含めたファイル範囲と回答が指摘した条件も記録します。この記録は速度の数値を作る前に、2つの設定へ同じ作業を依頼したか確認するためのものです。他の人がより短い質問やすでに開いていたファイルで比較していたなら、そのtok/sを自分の作業の完了時間にそのまま当てはめることはできません。

以下のvLLMコマンドはデスクトップセレクターとは別の構成です。公式BF16重みを保持できるNVIDIAサーバー向けの例なので、Macや24GB RTX向けQ4コマンドと混同しないでください。クライアントが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にバインドして実行します。

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

API11テストではモデル一覧に実際に表示された識別子をリクエストに指定します。ポートも起動したランタイムに合わせます。このガイドのコマンドはoMLXが8000、llama.cppが8080なので、8000番でサーバーが動いていないのにcurl例を繰り返しても回答は返りません。まずアドレスから応答があるか確認し、その後短いチャットリクエストが完了するか確かめます。

応答がストリーミングの断片として届くかを確認し、アプリが思考過程と最終回答を分ける設定なら両方の表示を見ます。長い思考トークンを出す設定では、入力処理が遅くなくても最終文が画面に出るまで時間がかかる場合があります。最初のトークンから最終回答までの画面表示とサーバーログを合わせて見ると、どの段階に時間がかかったか区別しやすくなります。

モデル一覧に名前が表示されるのは、サーバーがその識別子を認識している確認であり、アプリが意図したモデルを要求したことやコンテキスト設定が適用されたことの検証ではありません。名前が誤っていればリクエストが拒否されたり、別の経路から回答が返ったりすることがあります。文書入力に進む前に短い応答で実際のモデル識別子とサーバーログを確認すれば、後で遅い回答がモデルロードによるものか、別のモデルを指定したことによるものか混同しにくくなります。

テキスト質問が完了したら、実際に任せる予定のコードや文書を送ります。たとえば修正対象の関数と周辺の呼び出し元を一緒に含め、回答が依頼したファイル範囲を扱っているか確認します。短い挨拶で高いtok/sが出ても、長いコード入力後の最初の回答や完了時刻の代わりにはならないため、自分の質問を比較の基準にします。

APIの状態確認とチャットリクエストのテスト
# 1. List loaded models
curl -N http://127.0.0.1:8000/v1/models

# 2. Call the OpenAI-compatible chat completions 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": "Summarize three advantages of local LLM serving."}
    ],
    "temperature": 0.6,
    "max_tokens": 1024,
    "stream": true
  }'
この例ではoMLXは8000、llama.cppは8080ポートを使います。起動したランタイムに合わせてアドレスを変更してください。

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

コードや文書を送った後の最初の回答が遅いなら、入力トークン数、プリフィルチャンク、キャッシュ状態を確認します。回答が始まってから遅いなら、メモリ使用量、スワップ、重みの一部がCPU12へ移っていないか調べます。前者は入力処理、後者はトークン生成のボトルネックかもしれません。両方をMTPのステップ数だけ増やして解決しようとすると原因を見落とします。

oMLX 0.7.0には、Qwen3.8-27B向けのLightning MTPとDFlash2経路が含まれています。異なるspeculative decoding13方式なので、UIでは両方を同時に有効にせず、一度に一つを選び、チェックポイント14とドラフトモデルが選んだ経路に合っているか確認してください。同じ質問で通常のデコードと選択した高速化経路を比較すると、実際に何が変わったか分かります。

PR #3958のQwen3.8-27B oQ4e比較では、80コアGPUと512GBユニファイドメモリ15ーを搭載したM3 Ultraで、長いcode_pythonプロンプトから512トークンを生成しました。temperature 1、top_p 0.95、top_k 20では、Lightning MTPは8K・16K・64Kコンテキストで74.1・64.9・49.6 tok/s、DFlash2は79.4・84.7・59.9 tok/sでした。ANEプリフィルはオフで、各行はPRブランチとmainの比較です。これはPRの検証結果であり、安定版oMLX 0.7.0を同じ条件で新たに反復測定した結果ではありません。適用する前に、同じモデル・入力・コンテキストで手元のMacを測定してください。

PR #3958の結果表には、メモリーガードの段階もKVキャッシュ16の精度も記載されていません。oMLX 0.7.0では、balancedは他のアプリ用にメモリーの約8%（3～8GB）を空け、aggressiveは約2%（1.5～4GB）だけを残します。普段はbalancedから始め、aggressiveは他のアプリを閉じた状態で安定性を確認してから検討してください。どの設定が結果を変えたか分かるよう、KVキャッシュの精度とMTPも別々の条件として記録します。

速度だけでなくコードの結果も検証します。たとえば同じ関数変更の依頼を既定設定とMTP設定で送り、関数名が要求どおり変わったか、空入力処理の分岐が残ったか、既存の戻り値形式が保たれたか確認します。テストに失敗したら差を記録し、早く終わった回答が作業を正しく完了したか見ます。これはコード要件の確認であり、候補トークンの検証動作を確かめる試験とは異なります。

コンテキストを増やした場合だけメモリ不足になるなら、まずリクエスト数と入力長を下げ、安定して回答できる範囲を見つけます。毎日使う文書の長さでも限界が繰り返すか確認し、必要な場合にだけ大容量メモリ構成を検討します。長い質問が一度失敗しただけで機材不足と決めるより、テキストの基準状態と実作業の違いを調べるほうが正確です。

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

コード修正と文書要約の両方を任せるなら、それぞれ代表的な質問を1つ残します。ある作業に役立つプリフィルバッチやキャッシュ設定でも、別の入力長ではメモリ負荷や待ち時間が変わる場合があります。回答速度だけでなく、コードが実行可能か、文書の重要条件が要約に残っているかも基準回答と比べます。

最終記録にはモデルファイル名、アプリのバージョン、コンテキスト長、リクエスト数、使用した高速化オプションを記載します。更新後に実行が変わった場合、この状態に戻ってどの設定が変化したか確認できます。まず普段の作業が最後まで完了し、必要な情報が正確に得られる設定を作ります。その基準が安定してから項目を1つ調整し、実際に待ち時間が減ったか比べます。

たとえば普段の質問はQ4ファイルで安定して完了するのに長い入力だけ失敗するなら、新しい機材を買う前にコンテキストとプリフィル設定がセレクターでどう設定されたか確認します。逆に短い入力でもモデルをロードできないなら、キャッシュ精度やMTPのステップよりファイルとランタイムの組み合わせ、使用可能メモリを先に調べます。問題の位置が分かれば、何を変えるべきか選びやすくなります。

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

NVFP4で実行するには

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

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

用語の注釈

  1. トークン — モデルが入力や出力を分けて処理する単位です。1トークンが1文字や一定の時間に相当するわけではありません。

    本文に戻る

  2. 量子化 — モデルの数値を少ないビット数で表す方法です。メモリ使用量のほか、精度や実行速度も変わることがあり、影響は形式と実装によります。

    本文に戻る

  3. GGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。形式だけで特定ハードウェアへの対応や速度が保証されるわけではありません。

    本文に戻る

  4. MLX — Appleが開発する機械学習フレームワークです。Apple siliconでは統合メモリとMetalを活用し、別途Linux向けの実行経路も提供します。対応モデルや機能はMLXを使うツールごとに異なります。

    本文に戻る

  5. BF16 — モデルの数値を保存・計算する16ビット浮動小数点形式です。利用可否はハードウェアと実行環境によります。

    本文に戻る

  6. ランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあり、GPUランタイムライブラリと完成したサービングアプリは別の構成要素です。

    本文に戻る

  7. GPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。

    本文に戻る

  8. MTP — 複数の将来トークンを予測する学習方式またはモデル構成です。生成速度への効果は実装や実行条件によります。

    本文に戻る

  9. プリフィル — LLMが入力プロンプトを読み、各トークンの内部表現を計算する段階です。プロンプトが長いほど処理するトークンが増えます。

    本文に戻る

  10. デコード — LLMでは入力処理後に出力トークンを生成する段階です。VAEやオーディオコーデックでは、圧縮表現や符号化データから元の形式を復元する処理を指すことがあります。

    本文に戻る

  11. API — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。APIという言葉だけで外部サーバーへの送信を意味するわけではありません。

    本文に戻る

  12. CPU — コンピューターで汎用のプログラム命令を実行する中央処理装置です。AI処理ではGPUなど他のプロセッサーと役割を分けることがあります。

    本文に戻る

  13. 投機的デコーディング — 出力候補を先に提案し、メインモデルが検証する生成手法です。候補は別のドラフトモデル、MTPヘッド、文脈内の反復箇所の検索などで作れます。速度への効果は実装や条件によって異なります。

    本文に戻る

  14. チェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。

    本文に戻る

  15. ユニファイドメモリ — CPUとGPUが同じ物理メモリ領域を共有する構造です。メモリ総量が増えるわけではなく、利用可能量はシステムによります。

    本文に戻る

  16. KVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。

    本文に戻る

  17. NVFP4 — NVIDIAが定義した4ビット浮動小数点データ形式です。対応状況はGPU世代、モデル、ソフトウェア実装によって異なります。

    本文に戻る

実行レシピ

機器別の設定

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の設定値としてそのまま使わないでください。
同時リクエスト数11件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。
メモリの余裕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
まずこの設定で基準速度を記録し、その後は下の手順に沿って一項目ずつ変更します。

起動後の確認

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

変わる点と注意点

  • コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。
推奨設定での速度を見る MBP M5 Pro 64GB 価格・電力・販売構成の確認

1つずつ調整

高速化の手順

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

  1. STEP 1

    基準値を保存

    初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。

    とき： エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。

  2. STEP 2

    プリフィルのチャンクサイズを調整

    1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。

    とき： TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。

  3. STEP 3

    KVキャッシュ調整

    コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。

    とき： 出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。

  4. STEP 4

    MTP・投機的デコーディング

    対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。

    とき： 3回の中央値が基準値より良くならなければ、無効に戻します。

  5. STEP 5

    コンテキスト拡張

    実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。

    とき： 情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。

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

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

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

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

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

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

設定の問題を報告

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

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

変更履歴

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

  1. Macのモデル形式と実行設定を訂正

    MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。

    コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。

  2. Qwen 27BのSpark設定から別エンジンのオプションを削除

    Spark 1台・2台のSGLang設定に、llama.cpp専用の投機的デコーディングオプションが付かないよう修正しました。DFlash2・DSpark構成は、それぞれの専用モデルと実行経路を維持します。

  3. 初回入力とキャッシュ再利用の記録を分離

    検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。

  4. 機器・プロファイルの保存と再表示を追加

    実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。

  5. 実行エンジンの説明へのリンクを追加

    設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。