3行でいうと

  • 公式の配布場所は、GitHubの QwenLM/Qwen3.8 と、Hugging Faceの Qwen 組織です。Hugging Faceの Qwen 組織には、読んだ時点で Qwen3.8 の 27B、27B-FP8、2.4T-A95B、2.4T-A95B-FP8、Flash-Next、Flash-Next-FP8 が並んでいました。GGUF、AWQ、GPTQ、MLX の形式の公式リポジトリは、その一覧には見えませんでした。
  • ライセンスは3種類です。27B系は Apache-2.0、2.4T-A95B系は「Qwen3.8-Max License」、Flash-Next は「Qwen Community License 1.0」。独自の2つは、個人の利用は広く許していますが、他人にモデルの推論を使わせる事業やコーディング・事務のAIアシスタント事業に当たると別のライセンスが要る、という条件があります（2.4T-A95Bでは、その事業の収益が連続12か月で5,000万米ドルを超える場合。Flash-Nextは金額の基準を読み取れませんでした）。
  • 必要なGPUやメモリの大きさは、Qwen3.8の公式のREADMEとモデルカードのどれにも書かれていませんでした。数字が読めたのは、Ollamaのライブラリのファイルの大きさ（27Bで18GB〜56GB）と、vLLMプロジェクトのレシピ集（Qwenの公式ではない）のGPUの例だけです。
  • 量子化は、Qwen公式が出しているのはFP8版（ブロック128の細かいFP8）です。手元のパソコン向けのGGUFなどは、コミュニティやOllamaの配布になります。Qwen公式の量子化の品質の比較表は、読めた範囲では Qwen2 の古いもので、Qwen3.8 の数字は見つかりませんでした。

この記事は、公式の資料を2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はQwenを入れていますが、使い心地はこの記事には書いていません。コマンドと設定の値は、公式のページに書かれていたものを写しており、動作確認はしていません。公式ページは要約の形で取得したため、長い引用はせず言い換えています。ライセンスの原文は、要約で読んだだけです。商用利用や配布の判断は、原文を自分で読み、必要なら専門家に確認してください。

先に結論

前提：用語をそろえる

1. 公式の配布場所の地図

場所 何があるか 公式に書かれていること 確かさ
GitHub QwenLM/Qwen3.8 モデルの一覧、公開日、動かし方、ライセンスの案内 リポジトリの表示はApache-2.0。ただし重みのライセンスは、HuggingFaceかModelScopeで重みと一緒に公開されたファイルを見る、と書かれている 文書に書かれている
Hugging Face の Qwen 組織 重み、モデルカード、LICENSEファイル Qwen3.8 の6リポジトリ（27B、27B-FP8、2.4T-A95B、2.4T-A95B-FP8、Flash-Next、Flash-Next-FP8）が一覧に並ぶ 文書に書かれている
ModelScope READMEが「重みを公開している場所」として挙げる 中身は今回読んでいない 確認できず
qwen.readthedocs.io Quickstart、手元実行（llama.cpp、Ollama、LM Studio、MLX LM）、デプロイ（SGLang、vLLMなど）、量子化（AWQ、GPTQ、llama.cpp） 読んだ範囲では、Qwen3 と Qwen2.5 の書き方。Ollama と MLX LM のページには「Qwen3向けに更新予定」の旨の注意書きがある 文書に書かれている
Ollama のライブラリ（ollama.com/library/qwen3.8） Ollama用に配られているQwen3.8 Ollamaのページ。Qwenの公式ではない。qwen3.8のタグが12種類ある 文書に書かれている

GitHubのREADMEが載せているQwen3.8系の公開日は、2.4T-A95Bが2026年8月12日、27Bが8月14日です。そのほか、Qwen3.6（4月）、Qwen3.5（2月〜3月、9B、4B、2B、0.8Bの小さい版もある）、Qwen3-Next-80B-A3B（2025年9月11日）が載っています。小さいモデルほど手元のパソコンには向きますが、ライセンスはモデルごとに違うので、1つずつ確かめる必要があります（次の節）。

Hugging Faceの組織ページには、Qwen3.8のほかに、画像生成のQwen-Image-2.1系、安全性用のQwen3Guard-Stream、Qwen-Drive-1.0-4Bなども並んでいました。この記事では扱っていません。

2. ライセンス：モデルごとに違う、手元で動かすときに何が効くか

前のガイド（02）に、3種類の概略を書きました。今回、LICENSEファイルを読み直して、手元で動かす人の立場から整理します。条文は原文で確かめてください。

モデル カードの license 欄 中身（要約） 確かさ
Qwen3.8-27B、27B-FP8 apache-2.0 Apache License 2.0（著作権表記は2026年のAlibaba Cloud）。ライセンスの写しの添付、変更したファイルへの変更の明示、特許訴訟を起こすと特許許諾が終わる条項、商標は使えない、無保証 文書に書かれている
Qwen3.8-2.4T-A95B、2.4T-A95B-FP8 qwen3.8-max 「Qwen3.8-Max License」。広い許諾と、2つの条件（下） 文書に書かれている
Qwen3.8-Flash-Next other（qwen-community-1.0） 「Qwen Community License 1.0」。広い許諾と、2つの条件（下） 文書に書かれている
Qwen3.8-Flash-Next-FP8 ― 読んでいない 確認できず

独自の2つのライセンスに共通する広い許諾。 重み、パラメーター、設定ファイル、推論コード、文書を、無償で、使用・複製・改変・統合・公開・配布・サブライセンス・販売・デプロイ・ホスティング・ファインチューニング・派生物の作成まで許す、という書き方です。

条件1：モデル名の表示。 月間利用者が1億人を超える、または月の収入が2,000万米ドル（相当額）を超える商用の製品・サービスでは、利用者向けの画面にモデル名を目立つように出す必要があります（原文は「prominently displayed on the user interface」）。個人が手元で使うだけなら、この条件に触れる場面は普通ないはずです（これは僕らの見立てです）。

条件2：別のライセンスが要る事業。 次のどちらかの事業を営む場合、商用に使う前にQwenから別のライセンスを得る、という条件です（Max Licenseでは、収益が連続12か月で5,000万米ドルを超える場合。下の「2つのライセンスの違い」を参照）。 - 「Model as a Service」：第三者に、言語モデルの推論やファインチューニングを、入力、パラメーター、学習データをある程度自分で制御できる形で使わせる事業。他社のモデルへ要求を中継するだけのものは含まれません。 - 「AI Work Assistant」：主にAIによるコーディングやオフィス業務の支援のために作られた、独立したAI製品。例としてQoderとQwenWorkが書かれています。翻訳のような単機能の道具、買い物や地図のような別の分野のアシスタント、主目的が別の製品の一機能は含まれません。

例外：社内利用。 社内で使うだけで、モデル、その出力、モデルの能力を第三者に提供しないなら、条件2の別ライセンスは要りません。

2つのライセンスの違い。 2.4T-A95Bの「Max License」には、この事業の収益が連続12か月で5,000万米ドルを超える場合に別のライセンスが必要、という金額の基準がありました。Flash-Nextの「Community License 1.0」は、取得した要約には金額の基準が出てきませんでした。02でも同じ読み方を書きましたが、要約で読んだだけなので、金額の基準があるかどうかは原文で確認してください。どちらも、取得した要約では、終了（解除）の条項と準拠法の条項は見つかりませんでした。問い合わせ先として、model-business@notice.qwencloud.com が書かれています。

Apache-2.0の27B系について。 取得した要約には、第三者にサービスとして提供する場合の扱いを個別に定めた記述はありませんでした。Apache-2.0の一般的な条件（上の表）だけです。

自分で量子化して配るとき、コミュニティの量子化版を使うとき。 Apache-2.0の変更の明示や、独自ライセンスのモデル名の表示と別ライセンスの条件が、派生物にどう及ぶかは、僕らは条文の全体を読めていません。27Bのモデルカードの表示では、量子化版が1,541個ある、と出ていましたが、これはQwenが出したものとは限りません。使う前に、そのリポジトリのライセンスの欄を見るのが安全です（僕らの見立てです）。

3. モデルの大きさと、必要なハードの公式の記載

ここが、読んで一番はっきりした点です。Qwen3.8のREADMEと、27B、27B-FP8、2.4T-A95B、2.4T-A95B-FP8、Flash-Nextのモデルカードは、必要なGPU、VRAM、メモリを書いていませんでした。 サーバーの起動例には --tensor-parallel-size 4 のような複数GPU向けの指定がありますが、必要条件として書かれているわけではありません。

モデル 公式が書く大きさ 文脈の長さ 配布の形式 必要なハードの公式の記載
Qwen3.8-27B 27B（言語モデル）。画像の入力にも対応。層64。Hugging Face表示は28B、BF16 262,144トークン（標準）。最大1,000,000まで伸ばせる BF16。FP8版あり 読んだ範囲では書かれていない
Qwen3.8-27B-FP8 同上 同上 BF16とF8_E4M3。ブロック128のFP8 書かれていない。ファイルの大きさもページには出ていない
Qwen3.8-2.4T-A95B 全体2.4T、1回に約95Bが動くMoE。層92。エキスパート512、1回に10＋共有1 262,144トークン（標準）。最大1,010,000 BF16。FP8版あり。文字のみ（画像は非対応）、思考モードは止められない 書かれていない
Qwen3.8-Flash-Next カードは全体125B、1回に6B。ほかにn-gram埋め込み51B、MTP 4B。組織ページの表示は180B 262,144トークン（標準）。最大1,000,000 カードの本文はFP8に触れていない。組織ページにFP8版の名前がある 書かれていない。メモリの制約が厳しい環境に向く設計だとカードが説明し、オフロード（メモリの外に逃がす）もしやすい、と書く

Flash-Nextは、カードが「実験的なプレビュー」と書き、Qwen4の土台になる設計の最初の公開、と説明しています。読んだ要約では、実運用向けの保証は書かれていません。カードの内訳（125B＋51B＋4B）を足すと、組織ページの180Bと合います（僕らの計算です）。

数字が読めた2か所（どちらもQwenの公式ではない）

Ollamaのライブラリ（Ollamaの公式サイト、取得時の表示）。 qwen3.8 の27bには、12個のタグがあり、どれも文脈256K、入力は文字と画像です。

タグ 表示されたファイルの大きさ 形式
qwen3.8:latest、qwen3.8:27b 18GB 名前に量子化名なし（latestは27bと同じ）
qwen3.8:27b-q4_K_M、27b-mtp-q4_K_M 18GB Q4_K_M
qwen3.8:27b-nvfp4 18GB NVFP4
qwen3.8:27b-q8_0、27b-mtp-q8_0 30GB Q8_0
qwen3.8:27b-mxfp8 32GB MXFP8
qwen3.8:27b-bf16、27b-mtp-bf16 56GB BF16
qwen3.8:27b-mlx 18GB MLX
qwen3.8:27b-mlx-bf16 56GB MLX、BF16

ページには、Ollamaの版やメモリの必要量は書かれていませんでした。ファイルの大きさは、載せるのに最低限必要な量の目安にはなりますが、実際には文脈の長さに応じてKVキャッシュなどが増えます（僕らの見立てです）。28BのBF16が56GBというのは、1つの数が2バイトで、28B×2という読み方と合います（僕らの計算です）。

vLLMプロジェクトのレシピ集（recipes.vllm.ai、Qwenの公式ではない）。 27Bのページには、GPUごとの検証例が載っていました。ただし、このページにはQwen以外（Inferact、unsloth、RedHatAI、NVIDIAなど）が作った量子化版も含まれています。このページの内容は、この記事では動かして確かめていません。

家庭のパソコンで動くか。 Qwenの公式の資料からは判断できません。Ollamaのライブラリの18GBは、見かけの目安です。動くかどうかは、載せたあとの速さと、文脈の長さで決まります。

4. 量子化：何があって、公式は何を書いているか

形式 誰が出しているか 公式の記載 確かさ
BF16（元の重み） Qwen 27Bで28B、BF16。Ollamaの表示では56GB 文書に書かれている
FP8（ブロック128） Qwen 27B、2.4T-A95B、（Flash-Nextは名前のみ）。「元の性能とほぼ同じ」とカードが書くが、数字なし 文書に書かれている
GGUF（Q4_K_M、Q8_0など） コミュニティ、Ollama Qwen3.8のREADMEは、HuggingFaceでGGUFを探すよう書き、Qwen3.5系にllama.cppが対応と書く。Qwenの組織ページに、GGUFのリポジトリは見えなかった 文書に書かれている
MLX コミュニティ、Ollama READMEは mlx-lm（文字）と mlx-vlm（画像と文字）を挙げ、Qwen3.5に対応と書く 文書に書かれている
AWQ、GPTQ 読んだ範囲では、Qwen3.8については確認できず QwenのドキュメントにAWQ、GPTQのページがあり、vLLMのページには Qwen/Qwen3-8B-AWQ という名前が出てくる（Qwen3の例）。Qwen3.8の公式リポジトリは、組織ページの一覧に見えなかった 確認できず
NVFP4、MXFP4 Inferact、unsloth、RedHatAI、NVIDIAなど（Qwen以外） vLLMのレシピ集に載る 文書に書かれている（Qwenの公式ではない）

品質はどれくらい落ちるのか：公式の数字は古い

QwenのドキュメントのQuantized Modelsのページは、Qwen2シリーズの比較表で、「Qwen3向けに更新予定」の注意書きがあります。BF16、GPTQ-Int8、GPTQ-Int4、AWQを、MMLU、C-Eval、IFEvalの平均で比べていて、FP8とGGUFは載っていません。Qwen2-72B-Instructは、BF16が平均81.3、GPTQ-Int4が81.2でほぼ同じ。一方、Qwen2-0.5B-Instructは、BF16が34.4、GPTQ-Int4が29.7で、小さいモデルほど落ちています。これは、表の数字から僕らが読み取ったことで、ページが結論として書いているわけではありません。Qwen3.8や、GGUFのQ4_K_Mが、どれだけ落ちるかは、読んだ範囲に数字がありません。

速度とメモリの公式の数字も、Qwen3の時代のもの

QwenのドキュメントのSpeed Benchmarkのページは、Qwen3シリーズ（0.6Bから235B-A22B）を、NVIDIA H20 96GBで、Transformers と SGLang で測っています。たとえばQwen3-14Bは、Transformersで入力長1のとき、BF16が28,402MB、AWQ-INT4が9,962MB（メモリは、このページではMB表記）。Qwen3-32Bの入力長30,720では、BF16が70,728MB、AWQ-INT4が27,718MBです。FP8は、Transformersでの速度が「まだ最適ではなく、さらなる最適化が必要」と書かれています（表ではTransformersのFP8がBF16より遅く、SGLangの表ではFP8のほうが速くなっています）。条件（H20、バッチサイズ1、2048トークン生成、PyTorch 2.6.0、Transformers 4.51.3など）が今とは違うので、27B以上のQwen3.8にそのまま当てはめることはできません。

自分で量子化する場合（Qwenのドキュメントの手順）

Qwenのドキュメントのllama.cpp量子化のページは、Qwen3-8Bを例に、次の流れを書いています。

python convert-hf-to-gguf.py Qwen/Qwen3-8B --outfile Qwen3-8B-F16.gguf
./llama-quantize Qwen3-8B-F16.gguf Qwen3-8B-Q8_0.gguf Q8_0

BF16で変換するなら --outtype bf16 を付けます。8Bの例として、Q8_0、Q5_K_M、Q4_K_Mが一般的、と書かれています。質を保ちたいときは、重要度行列（imatrix）を使います。

./llama-imatrix -m Qwen3-8B-F16.gguf -f calibration-text.txt --chunk 512 -o Qwen3-8B-imatrix.dat -ngl 80
./llama-quantize --imatrix Qwen3-8B-imatrix.dat Qwen3-8B-F16.gguf Qwen3-8B-Q4_K_M.gguf Q4_K_M

補正用の文章は、使う分野に近いものがよい、とされています。品質の確認には llama-perplexity を使う例があります（wikitext-2、ただし指示用のモデルには最適でない、と注意書きあり）。ページに、perplexityの結果の数字はありません。これはQwen3-8Bの手順で、Qwen3.8にそのまま使えるかは、読めていません。

5. 道具ごとの手順（公式に書かれているとおりに）

5-1. Ollama（いちばん短い）

Qwenのドキュメントのollamaのページは、Qwen2.5の例で、「Qwen3向けに更新予定」の注意書きがあります。Qwen3.8の手順は、Ollamaのライブラリのページに、次のとおり書かれていました。

ollama run qwen3.8

APIの例は、http://localhost:11434/api/chat に、モデル名 qwen3.8 で送る形です。Pythonの ollama パッケージでは chat(model='qwen3.8', ...) です。27bに加えて、特定の量子化を選ぶなら、前の節のタグ（qwen3.8:27b-q4_K_M など）を指定します。ページによると、思考モードは既定でオンで、リクエストごとに止められます。

Ollamaの公式ドキュメントが書いていること（動かす前に効く設定）。

項目 公式の記載 確かさ
既定の文脈の長さ VRAMが24GiB未満なら4k、24〜48GiBなら32k、48GiB以上なら256k 文書に書かれている
変える方法 アプリの設定のスライダー。またはサーバーを OLLAMA_CONTEXT_LENGTH=64000 ollama serve のように起動 文書に書かれている
確かめる方法 ollama ps の PROCESSOR 欄（100% GPU、100% CPU、または割合）と CONTEXT 欄 文書に書かれている
警告 文脈を長くするとメモリが増える。CPUへのオフロードは避けるのが最良（遅くなる）。検索、エージェント、コーディング用途は64,000トークン以上が目安 文書に書かれている
モデルの保持 既定で5分。OLLAMA_KEEP_ALIVE で変える（負の値で無期限、0で応答後すぐ解放） 文書に書かれている
並列の影響 必要なメモリは OLLAMA_NUM_PARALLEL と OLLAMA_CONTEXT_LENGTH の積で増える 文書に書かれている
KVキャッシュの量子化 OLLAMA_KV_CACHE_TYPE。既定は f16。q8_0 で約半分、q4_0 で約4分の1のメモリ。Flash Attentionが有効なとき。設定は全モデルに効く 文書に書かれている
待ち受け 既定では127.0.0.1のポート11434。OLLAMA_HOST で変える。FAQには、公開時の安全上の警告は書かれていなかった 文書に書かれている

GGUFを自分でOllamaに取り込む（Qwenのドキュメントの手順、Qwen2.5の例）。 コミュニティのGGUFを使うときの、読んだ範囲で唯一の公式の手順です。ページには「Qwen3向けに更新予定」の注意書きがあり、Qwen3.8の例ではありません。まず Modelfile というファイルを作ります。

FROM qwen2.5-7b-instruct-q5_0.gguf
PARAMETER temperature 0.7
PARAMETER top_p 0.8
PARAMETER repeat_penalty 1.05
PARAMETER top_k 20
SYSTEM """You are Qwen, created by Alibaba Cloud. You are a helpful assistant."""

公式の例には、この間にQwenの区切りの記号（<|im_start|> と <|im_end|>）でチャットの形を定める長い TEMPLATE の記述があります。長いので、ここには写していません。ページからそのまま写してください。そのあと、次の2行で作って動かします。

ollama create qwen2.5_7b -f Modelfile
ollama run qwen2.5_7b

サンプリングの値（0.7、0.8など）は、このQwen2.5の例のものです。Qwen3.8には、後の「6. 動かしたあとの設定」の値を使います。

OpenAI互換のAPIとして呼ぶ（Ollamaの公式ドキュメント）。 ローカルのアドレスは http://localhost:11434/v1/ です。公式の例はクラウド用（https://ollama.com/v1 と環境変数 OLLAMA_API_KEY）で、ローカル向けではありません。ローカルについて、公式は「クライアントはAPIキーの値を要求するが、Ollamaは無視する」と書いています。次のローカル向けの書き方は、公式の例をこの記事で置き換えたものです（動作は確かめていません）。

from openai import OpenAI

client = OpenAI(base_url="http://localhost:11434/v1/", api_key="ollama")
response = client.chat.completions.create(
    model="qwen3.8",
    messages=[{"role": "user", "content": "Say hello in one sentence."}],
)
print(response.choices[0].message.content)

落とし穴。 既定の文脈は、VRAMが24GiB未満だと4kです。長い文章や、エージェントの用途では、足りません。文脈を増やすとメモリが増え、GPUに載りきらずにCPUへ逃げて遅くなることがあるので、変えたら ollama ps で確かめます。

5-2. llama.cpp（細かく調整したい人向け）

llama.cppは、GitHubの公式ページ（ggml-org/llama.cpp、MIT license）が、CUDA（NVIDIA）、HIP（AMD）、Metal（Apple Silicon）、SYCL（Intel）、Vulkan、CANN（Ascend NPU）、MUSA、OpenCLなどに対応し、1.5ビットから8ビットの整数量子化に対応している、と書いています。メモリの目安は、このページには書かれていませんでした。CPUとGPUをまたいで動かし、VRAMより大きいモデルを一部だけ高速化できる、という説明はあります。

Qwenのドキュメントの手順は、次のとおりです（Qwen3-8Bの例）。

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j 8

Homebrewなら brew install llama.cpp ですが、ページは、最適化されていない、Linuxではそれだと GPU に対応しない、と注意しています。モデルは、-hf で直接取れます。

./llama-cli -hf Qwen/Qwen3-8B-GGUF:Q8_0 --jinja --color -ngl 99 -fa -sm row --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0 -c 40960 -n 32768 --no-context-shift
./llama-server -hf Qwen/Qwen3-8B-GGUF:Q8_0 --jinja --reasoning-format deepseek -ngl 99 -fa -sm row --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0 -c 40960 -n 32768 --no-context-shift
オプション 意味（Qwenのドキュメントの説明）
-hf / -m / -mu Hugging Faceから取る／ローカルのファイル／URL
-ngl GPUに載せる層の数。99は、全部載せる指定の例
-c 文脈の長さ。既定は4096、0でモデルの値
-n 1回に生成する最大の長さ。既定は無制限
--no-context-shift 文脈がいっぱいになったら、ずらさずに止める
--jinja モデルに入っているチャットのテンプレートを使う
-fa Flash Attention。生成が速くなることがある

llama-serverは、既定で http://localhost:8080、WebのUIとOpenAI互換のAPI（/v1/）が出ます。ページには、サーバーの認証やキーの設定は書かれていませんでした。

Qwenのドキュメントが書いている注意（Qwen3の時代のページ）。 llama.cppは、Qwen3とQwen3MoEを b5092 以降のバージョンで対応する、と書かれています。また、思考と非思考を切り替える「ハードスイッチ」はチャットのテンプレートの中にあり、llama.cppでは外に出ていません（「ソフトスイッチ」は使える）。思考を完全に止めたいときの案として、常に enable_thinking=False と同じ動きをする自前のテンプレートを --chat-template-file で渡す方法が挙がっています。Qwen3.8にそのまま当てはまるかは、読めていません。

落とし穴。 上のコマンドの -c 40960 などは、Qwen3の値です。Qwen3.8は標準の文脈が262,144トークンです。そのまま写すと、短い文脈で動きます。また、Qwen3.8のREADMEが「llama.cppが対応」と書くのは、Qwen3.5シリーズです。27Bのカードのタグが qwen3_5 なので、動く見込みはありますが、Qwen3.8の27Bがllama.cppで動くかを、公式の資料で確かめられた箇所は、読んだ範囲にありませんでした。

5-3. LM Studio

Qwenのドキュメントでは、LM Studioのアプリを入れ（macOS、Windows、Linux）、アプリ内の検索（Cmd/Ctrl＋Shift＋M）でQwenを探して、変種をダウンロードする、とあります。LM Studioは、手元のハードに合う変種を勧める、と書かれています。Hugging Faceのカードの「Use this model」から選ぶ方法もあります。これは、先にHugging Faceのアカウントの「Local Apps Settings」でLM Studioを有効にしておく必要があります。自分のGGUFは lms import <path/to/model.gguf> で入れます（「My Models」に出なければ、LM Studioの手動の取り込みの手順に従う、とあります）。ローカルのAPIは lms server start ですが、lms のコマンドは、LM Studioのアプリを一度起動してからでないと動きません。特定のQwenの世代や量子化の推奨は、書かれていません。

5-4. MLX（Apple Silicon）

READMEは、mlx-lm（文字のみ）と mlx-vlm（画像と文字）を挙げ、Hugging Faceで MLX 形式を探すよう書いています。Qwenのドキュメントのページは、pip install mlx-lm、mlx_lm.convert --hf-path ... --mlx-path ... -q（-q が量子化）という、Qwen2.5の例です。必要なMacの条件は、書かれていません。Ollamaには 27b-mlx のタグもあります。

5-5. vLLM、SGLang、Transformers（複数GPUのサーバー向け）

Qwen3.8のREADMEの起動例は、次のとおりです。27Bで、テンソル並列4、文脈262,144トークンの設定です。

# Transformers
transformers serve Qwen/Qwen3.8-27B --port 8000 --continuous-batching

# vLLM
vllm serve Qwen/Qwen3.8-27B --port 8000 --tensor-parallel-size 4 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder

# SGLang
sglang serve --model-path Qwen/Qwen3.8-27B --port 8000 --tp-size 4 --context-length 262144 --reasoning-parser qwen3 --tool-call-parser qwen3_coder

READMEは、ほかにTokenSpeedの同様の例も載せています。OpenAI互換の入口として http://localhost:8000/v1 に出る、というのは僕らの整理で、READMEにこのアドレスの記載は読めていません。一方、27Bのモデルカードは、もっと素朴な形です。

pip install vllm
vllm serve "Qwen/Qwen3.8-27B"

pip install sglang
python3 -m sglang.launch_server --model-path "Qwen/Qwen3.8-27B" --host 0.0.0.0 --port 30000

docker model run hf.co/Qwen/Qwen3.8-27B

FP8版は、モデル名を Qwen/Qwen3.8-27B-FP8（2.4Tなら Qwen/Qwen3.8-2.4T-A95B-FP8）に変えるだけ、と同じ書き方で載っています。

vLLMのQwen3時代のページ（参考）に書かれていた注意。 --gpu-memory-utilization の既定は0.9（GPUのメモリをあらかじめ確保）。メモリ不足の逃げ道として --enforce-eager（遅くなるかもしれない）が挙がっています。FP8のブロック量子化は、計算能力が8.9を超えるNVIDIAのGPU（Ada、Hopper以降）で動き、vLLM 0.9.0以降はFP8 Marlinで、Ampereのカードも使える、とあります。FP8でテンソル並列のサイズが合わないエラーは、並列数を下げるか --enable-expert-parallel で対処する、とあります。Qwen3.8にも当てはまるかは、読めていません。また、ツール呼び出しのパーサーは、Qwen3のページでは hermes、Qwen3.8のREADMEでは qwen3_coder で、書き方が違います。新しいほう（README）を使うのが筋です。

落とし穴：待ち受けの範囲。 モデルカードの SGLang の例は --host 0.0.0.0（すべてのネットワークの入口で待ち受ける）です。vLLMとllama-serverのページには、APIの認証やキーの設定は、読んだ範囲に書かれていませんでした。僕らの見立てとして、同じネットワークの他の人からも呼べる状態になるので、必要がなければ 127.0.0.1 にとどめるほうが安全です。

5-6. 長い文脈（YaRN）

標準の262,144トークンを超えて1,000,000トークンまで伸ばすには、設定を上書きします。27Bのカードの内容は、rope_type が yarn、factor が 4.0、original_max_position_embeddings が 262144 などで、vLLMなら VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 と --hf-overrides、--max-model-len 1000000 を使います。カードは、YaRNは静的で、短い文章で性能が落ちることがあるため、必要なときだけ有効にし、典型的な長さに合わせて factor を調整するよう、書いています（524,288トークンなら2.0）。

6. 動かしたあとの設定：公式の推奨値

27Bのカードの推奨値は次のとおりです。

モード temperature top_p top_k min_p presence_penalty repetition_penalty
思考（既定） 1.0 0.95 20 0.0 0.0 1.0
指示（非思考） 0.7 0.80 20 0.0 1.5 1.0

7. 選び方の表（ここは僕らの整理です）

やりたいこと 候補 公式の記載から言えること 注意
まず手元で試したい Ollama（ollama run qwen3.8） Ollamaのライブラリに27bのタグがある。ファイルは18GBから Ollamaの配布で、Qwen公式ではない。文脈の既定がVRAMで変わる
アプリで選びたい LM Studio アプリが、手元のハードに合う変種を勧める Qwen3.8の記載はドキュメントにない
量子化やオプションを細かく決めたい llama.cpp 対応するバックエンドが多い。変換と量子化の手順がある Qwen3.8への対応は、READMEではQwen3.5まで
Apple Siliconで MLX（mlx-lm、mlx-vlm）、Ollamaの27b-mlx READMEはQwen3.5まで対応と書く Mac側の必要条件は書かれていない
複数GPUのサーバーで公開する vLLM、SGLang READMEに、27B、TP4、262,144の例がある 必要GPUの数字は書かれていない。待ち受けと認証に注意
一番大きい2.4T-A95B vLLM、SGLang 公式のFP8版がある 必要な環境の数字は、どこにもなかった。個人の機械では現実的でない可能性が高い（僕らの見立て）

8. 最初の10分でやること（僕らの整理）

  1. 使うモデルのHugging Faceのカードで、右上の license の欄を見る（27Bなら apache-2.0、2.4T-A95Bなら qwen3.8-max）。LICENSEのファイルも開く。
  2. 機械の空きを確かめる（GPUのVRAM、メモリ、ストレージ）。公式は必要量を書いていないので、Ollamaのタグのファイルの大きさ（18GB、30GB、56GB）を、最低限の目安にする。
  3. 試すだけなら、Ollamaを入れて ollama run qwen3.8 を実行する。動いたら、ollama ps で、GPUに載っているか、文脈はいくつかを見る。
  4. 僕らの見立てとして、載るかの大まかな確認は「ファイルの大きさ＋文脈の長さの分のメモリ」で考える。公式はこの式も数字も書いていないので、実際に動かして ollama ps の SIZE と PROCESSOR を見るのが確かです。
  5. 文脈が足りないと感じたら、OLLAMA_CONTEXT_LENGTH を上げ、ollama ps で再確認する。メモリが足りなければ、OLLAMA_KV_CACHE_TYPE を q8_0 にする選択肢がある（Flash Attention有効のとき）。
  6. サーバーとして他のアプリから呼ぶなら、OpenAI互換のアドレス（Ollamaなら http://localhost:11434/v1/、vLLMなら http://localhost:8000/v1）を、自分のマシンの中だけに限る。
  7. 商用で使うなら、モデル名の表示の条件（1億人、月2,000万米ドル）と、別ライセンスの条件（MaaSとAI Work Assistant）に当てはまるかを確かめる。迷ったら、問い合わせ先か専門家に。

気をつけること

出典