メインコンテンツへスキップ
When you run ollama run qwen3.6, a lot is hidden from you. The moment you open a model page’s advanced Run it tab and see a line like vllm serve … --tensor-parallel-size 8 --enable-expert-parallel, you meet a new vocabulary. This page explains those words — what each one does and when you’d actually need it.
OllamaやLM Studioを使って一つのGPU（またはMac）上でモデルを実行する場合、この説明の大部分を読み飛ばしても問題ありません。ただし、モデルの規模が一つのGPUでは収まらない場合や、多数のユーザーに同時にサービスを提供する際には並列処理やカーネルの最適化が重要になります。各モデルページの詳細設定タブからここに誘導された際には、ぜひ本内容をご確認ください。

​
推論フレームワーク

An inference framework is the engine that loads the model, runs the math, manages batching and the KV cache, and exposes an API. They trade ease of use for control: 初心者向けの選択肢としては各モデルページに記載されている OllamaやLM Studioが挙げられる。その他のツールではより詳細な設定項目が用意されている。Tokiosはこれらすべてと接続可能で、フレームワークが提供するOpenAI互換の /v1 へとリクエストを転送する。

​
精度

Precision is how many bits the runtime uses to store and compute each number in the model — FP32 (32-bit), FP16/bf16 (16-bit), FP8 (8-bit), or 4-bit formats. Fewer bits means less memory and faster data movement, at some risk to quality. This is the same idea as quantization — precision is the knob, quantization is turning it down. Which low-precision format your hardware can actually run is a separate question, answered in Quantization formats and the hardware they need.

​
カーネル

A kernel is the small, highly optimized GPU (or CPU) routine that performs one hot operation — a matrix multiply, an attention step, dequantizing a 4-bit weight, sampling the next token. You rarely name kernels directly, but they explain two things you do see:
  • なぜ量子化フォーマットには特定のハードウェアが必要なのか あるフォーマットが高速に動作するためには、ランタイム側でそのフォーマットを理解できるカーネルが利用者のチップ上に存在する必要がある。 NVFP4 ではブラックウェルテンサーコア向けのカーネルが必要だが、 GGUF はCPU、Metal、CUDA、ROCm、Vulkan向けのカーネルを llama.cpp が提供しているため幅広く利用可能だ。詳細は 量子化フォーマットと必要なハードウェア を参照されたい。
  • なぜ「FlashAttention」が話題になるのか FlashAttentionは長いコンテキスト処理時にもメモリ消費を抑えつつ高速に動作するアテンションカーネルだ。ランタイム側でこれが有効化されていると記載されている場合、それは利用者のために最適なカーネルが選択されていることを意味する。

​
複数GPUでの実行 — 並列処理

モデルサイズが単一GPUの処理能力を超える場合や、単一GPUでは十分なトラフィックを処理できない場合、ランタイム側が複数のGPUに処理を分散させる。主な戦略は四つあり、それぞれ異なる課題に対応している。
  • テンサー並列処理では各レイヤーの行列を複数のGPU用に分割し、各GPUがそれぞれの部分を処理した後で結果を統合します。これにより各GPUのメモリ使用量が削減されますが、常に通信が必要となるため高速なインターコネクト（NVLinkなど）が不可欠です。
  • パイプライン並列処理では異なるレイヤーを別々のGPUで処理します。これにより多数のデバイスに容易に拡張できますが、前段の処理が終わるまでGPUが待機状態になることもあります。
  • データ並列処理ではモデルのコピーを複数作成して並列実行します。すでにメモリに収まりきらないモデルには効果がありませんが、同時に処理できるリクエスト数を増やす目的に適しています。
  • エキスパート並列処理は MoE モデル専用の手法です。各エキスパートをすべてのGPUにコピーする代わりに、各GPUが一部のエキスパートを保持し、入力トークンは該当エキスパートを所有するGPUへ送信されます。大規模なMoEモデルに有効ですが、ルーティング処理のオーバーヘッドが生じます。
出典：vLLMの並列処理およびスケーリング、vLLMにおけるデータ並列デプロイ、vLLMにおけるエキスパート並列デプロイ、TensorRT-LLMの並列処理戦略。

​
スペキュレーティブデコーディングとMTP

Decode is slow because the model reads its weights from memory for every single token. Speculative decoding speeds it up without changing the output: a fast “draft” proposes several tokens at once, then the full model verifies them in one pass and keeps the ones it agrees with. Because verification is cheaper than generating from scratch, you get more accepted tokens per memory read. Multi-token prediction (MTP) is one way to produce those drafts. The model ships extra heads trained to predict the next few tokens, so it can draft and verify itself. The current DeepSeek-V4-Flash-0731 release bundles a DSpark module in the same checkpoint. Its official model card documents method: dspark for vLLM and DSPARK for SGLang, so you do not configure a separate draft-model path. 出典：DeepSeek-V4-Flash-0731のモデルカード、Qwen3.6-27Bのモデルカード、vLLMにおけるスペキュレーティブデコーディング。
一般向けの単体GPU環境では、ご使用のモデルおよびランタイムのドキュメントで明示されている場合に限り -mtp タグを利用してください。DeepSeek-V4-Flash-0731 の場合は、複数デバイス対応の vLLMまたは SGLang デプロイ環境で同梱されている DSpark パスをご利用ください。

​
本手法の適用範囲

推論処理の仕組み

これらの設定項目が最適化するのはプリフィル処理やデコード処理の基本事項です。

量子化処理とハードウェアの仕様について

ご使用のチップで利用可能な精度フォーマットはどれか。

ご使用のGPUに適したモデルのサイズはどの程度か。

複数のGPUを利用する前に、モデルのサイズを適切に見積もる必要があります。

Tokiosのエンドポイント情報を入力してください。

どのような配信方法を採用しても、Tokiosがローカル環境にある /v1 をどこからでもアクセス可能な、安定した認証済みエンドポイントへと変換してくれます。