「Qwen3.8-27Bが公開されたけど、自分のPCでも動かせるのだろうか？」
今回のQwen3.8-27Bで気になったのは、ベンチマークの順位よりも、むしろこちらでした。
27Bクラスのモデルを、普通の開発者が自分のPCに置いて実際に使えるのか。
結論から言えば、かなり現実的になっています。
Qwen3.8-27Bは27BのDense（密）モデルで、テキストだけでなく画像・動画も扱えるマルチモーダルモデルです。ネイティブのコンテキスト長は262,144 tokensとされており、公式ウェイトに加えて、すでにGGUFなどのコミュニティ量子化版も登場しています。2026年8月15日前後には、Qwen公式ウェイトやUnslothなどの量子化版を使ったローカル推論の検証も急速に増えています。
ただし、「27BだからVRAMが27GB必要」という単純な話ではありません。
実際には、
- BF16 / FP8 / 4bitなどの重み精度
- GPU VRAM
- システムメモリ
- コンテキスト長
- KV Cache
- 同時実行数
- 推論フレームワーク
まで考える必要があります。
この記事では、24GB前後のGPUやApple Siliconで試したい人向けのGGUF + llama.cppと、48GB以上のNVIDIA GPUでAPIサーバーとして運用したい人向けのFP8 + vLLMという2つの方向から、実際の導入方法を整理します。
※この記事は2026年8月15日前後の環境を前提にしています。Qwen3.8-27Bやllama.cpp、vLLMはリリース直後のため、バージョンによってコマンドや対応状況が変わる可能性があります。
- この記事はこんな人におすすめ
- Qwen3.8-27Bはなぜローカル向きなのか
- まず自分のPCでどこまで動くか確認する
- このモデルが役立つシーン
- 方法A：GGUF + llama.cppで動かす
- llama.cppをインストールする
- モデルを直接起動してみる
- ローカルAPIとして起動する
- 方法B：公式FP8 + vLLMでAPIサーバーを作る
- Python環境を作る
- vLLMでQwen3.8-27Bを起動する
- 複数GPUならTensor Parallelも使える
- OpenAI互換APIとして呼び出す
- Thinking Modeはどう使う？
- GGUFとFP8、どちらを選ぶべき？
- 実際にどんな用途で使える？
- Qwen3.8-27Bのメリット
- デメリットもある
- 初心者がよくハマる5つのポイント
- 他のローカルLLM環境と比較すると？
- 本当に完全オフラインで使える？
- まとめ｜27Bモデルをローカルで動かすなら、まずQ4から
この記事はこんな人におすすめ
今回の内容は、単純に「Qwen3.8-27Bとは何か」を知りたい人向けではありません。
実際に自分のPCでモデルを動かしたい人を対象にしています。
たとえば、
- 24GB VRAMのGPUを持っている
- RTX 3090 / 4090などでローカルAIを試したい
- Apple Silicon Macで大きめのLLMを動かしたい
- API料金を気にせずコード生成を試したい
- 自分専用のAIコーディング環境を作りたい
- ローカルLLMをWebアプリやAgentから呼び出したい
- 社内ネットワークだけでAIを利用したい
- vLLMでOpenAI互換APIを立てたい
という人です。
逆に、8GB程度のGPUしかない場合は、いきなり27Bに挑戦するより、小型モデルから始めたほうが快適です。
Qwen3.8-27Bはなぜローカル向きなのか
Qwen3.8-27Bの面白いところは、27Bという比較的大きなモデルでありながら、量子化によってコンシューマー向けGPUでも現実的に扱える点です。
公開後には公式のQwen3.8-27BおよびFP8版が公開され、さらにUnsloth、LM Studio系などからGGUFや各種量子化モデルが出てきています。
特にローカル利用では、モデルの「パラメータ数」だけを見ると判断を誤ります。
たとえば27Bモデルでも、
BF16 → 約54GB級
なのに対して、
4bit → 約16～18GB級
まで小さくできます。
もちろん、ファイルサイズが小さくなったからといって、そのままVRAMだけで余裕を持って動くわけではありません。
推論中にはKV Cacheなどにもメモリが必要になるからです。
ここがローカルLLMで最初につまずきやすいところです。
まず自分のPCでどこまで動くか確認する
最初からインストールを始める前に、手元のハードウェアを確認しておきましょう。
| 環境 | 現実的な選択 | コメント |
|---|---|---|
| 16GB GPU | 3bit前後 | 動作確認向け。速度・品質は妥協が必要 |
| 24GB GPU | 4bit GGUF | 一番試しやすい構成 |
| 32GB Apple Silicon | Q4前後 | メモリ容量次第でかなり実用的 |
| 48GB以上 NVIDIA | FP8 | vLLMによるAPI運用に向く |
| 64GB以上 RAMのCPU | 4bit | 動く可能性はあるが速度は期待しすぎない |
| 80GB級GPU | FP8 + 長文 | 本格的なサーバー用途に向く |
ここで重要なのが、「262Kコンテキストに対応している＝262Kで動かすべき」ではないということです。
むしろ最初は8K、16K、32K程度から始めたほうがいいでしょう。
コンテキストを増やすとKV Cacheの使用量も増えます。コミュニティではQwen3.8-27Bについて、262Kコンテキスト時のKV Cacheだけでかなり大きなメモリを消費するという試算も出ています。
つまり、
「モデルファイルがVRAMに入った」
と
「262Kで余裕を持って推論できる」
はまったく別の話です。
このモデルが役立つシーン
Qwen3.8-27Bをローカルで動かすメリットは、単に「無料でAIチャットができる」ということではありません。
開発者の場合、むしろAPIとして使えることが大きなポイントになります。
たとえば、自分で作ったWebアプリから、
Webアプリ ↓OpenAI互換API ↓Qwen3.8-27B ↓回答
という構成を作れます。
これなら、
- コードレビュー
- ログ解析
- ドキュメント要約
- SQL生成
- JSON変換
- ローカルファイル解析
- Agent
- プログラムのデバッグ
などに利用できます。
特にvLLMを使えばOpenAI互換APIとして提供できるため、既存のOpenAI API対応プログラムから接続先を変更するだけで利用できるケースもあります。
ここは「ローカルLLMを動かして遊ぶ」段階から「自分の開発環境に組み込む」段階へ進むうえで重要なポイントです。
方法A：GGUF + llama.cppで動かす
まずおすすめしたいのが、
GGUF + llama.cpp
です。
24GB GPUやApple Silicon、CPU + GPU混合環境など、幅広い環境で試しやすいのが特徴です。
今回はコミュニティで公開されているUnslothのQwen3.8-27B GGUFを例にします。
量子化モデルにはQ3、Q4、Q5など複数の選択肢があります。
最初に試すなら、24GBクラスではQ4系がバランスを取りやすいでしょう。
llama.cppをインストールする
macOSやLinuxでは、環境によってインストール方法が異なります。
たとえば公式のインストールスクリプトを利用する方法があります。
curl-LsSf https://llama.app/install.sh | sh
Windowsでは環境によって、
wingetinstallllama.cpp
のように導入できます。
ただし、GPUを利用する場合は「llama.cppがインストールできた」だけでは十分ではありません。
CUDAやGPUバックエンドが正しく有効になっているか確認してください。
ここを確認せずに実行すると、
GPUを持っているのにCPUで推論している
という、かなりもったいない状態になることがあります。
モデルを直接起動してみる
llama.cppの環境が準備できたら、まずはCLIから試します。
llama cli -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL
初回はモデルのダウンロードが発生します。
17GB前後のモデルをダウンロードする場合、ネットワーク環境によってはかなり時間がかかります。
ここで焦って何度もCtrl+Cを押すのはおすすめしません。
まずディスク容量とターミナルのログを確認しましょう。
Q4が厳しい場合は、さらに小さい量子化版を試します。
llama cli -hf unsloth/Qwen3.8-27B-GGUF:Q3_K_M
逆にメモリに余裕があるなら、Q5系を選ぶという考え方もあります。
ローカルAPIとして起動する
CLIで動作確認できたら、次はサーバーとして起動します。
llama serve -hf unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL
起動すると、環境によってはローカルの8080番ポートでアクセスできます。
ここで重要なのは、単なるWeb画面だけではないことです。
OpenAI互換APIとして、
のようなエンドポイントを利用できます。
たとえば、
curl http://127.0.0.1:8080/v1/chat/completions \-H"Content-Type: application/json" \-d'{ "model": "unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL", "messages": [ { "role": "user", "content": "Pythonで指数バックオフ付きHTTPリクエストを書いてください" } ], "temperature": 0.7, "max_tokens": 1024, "stream": false }'
これで、自分のPC上にAI APIを用意できます。
個人的には、ローカルLLMを試すならここまでやっておくことをおすすめします。
ブラウザでチャットするだけなら、モデルをローカルに置くメリットを十分に活かせないからです。
方法B：公式FP8 + vLLMでAPIサーバーを作る
もう一つの方法が、
公式FP8モデル + vLLM
です。
こちらは24GB GPUで気軽に試すというより、48GB以上のNVIDIA GPUや複数GPUを使って、開発環境や社内APIとして運用したい人向けです。
vLLMはOpenAI互換APIを提供できるため、アプリケーションとの接続がしやすいのが大きな利点です。
Python環境を作る
Linux環境なら、まず仮想環境を作っておくと安全です。
python3 -m venv .venvsource .venv/bin/activate
その後、
pip install -U pip
として、必要なパッケージをインストールします。
pip install "vllm>=0.17.0""transformers>=5.8.0" openai
ただし、Qwen3.8-27Bはリリース直後のモデルなので、記事を読む時点で公式Model Cardが指定するバージョンを優先してください。
AIモデルは、昨日まで動いていたコマンドが今日のアップデートで動かなくなることも珍しくありません。
vLLMでQwen3.8-27Bを起動する
基本構成は次のようになります。
vllm serve Qwen/Qwen3.8-27B-FP8 \--host127.0.0.1 \--port8000 \--max-model-len32768 \--gpu-memory-utilization0.90 \--kv-cache-dtype fp8 \--reasoning-parser qwen3 \--enable-auto-tool-choice \--tool-call-parser qwen3_coder
ここではあえて、
--max-model-len 32768
としています。
Qwen3.8-27Bが長いコンテキストに対応していても、最初から262Kに設定する必要はありません。
まず32Kで正常動作を確認する。
その後、
32K↓64K↓128K↓262K
というように段階的に増やしていくほうがトラブルを切り分けやすくなります。
複数GPUならTensor Parallelも使える
GPUを2枚以上搭載している場合は、Tensor Parallelを利用できます。
たとえば2枚なら、
--tensor-parallel-size2
とします。
ただし、「GPUを2枚にしたら単純に速度が2倍」というわけではありません。
PCIe帯域、GPU間通信、モデルの分割方法などによって結果は変わります。
ローカルAIではGPUの枚数だけを見るより、
VRAM容量 + GPU間通信 + 推論フレームワーク
をセットで考えたほうが現実的です。
OpenAI互換APIとして呼び出す
vLLMが起動したら、
curl http://127.0.0.1:8000/v1/chat/completions \-H"Content-Type: application/json" \-d'{ "model": "Qwen/Qwen3.8-27B-FP8", "messages": [ { "role": "user", "content": "このプロジェクトの技術的な問題点を3つ挙げてください" } ], "temperature": 1.0, "top_p": 0.95, "max_tokens": 2048 }'
という形で呼び出せます。
また、モデル名が分からない場合は、
curl http://127.0.0.1:8000/v1/models
で確認できます。
これは地味ですが、非常に重要です。
APIクライアントで、
model not found
というエラーが出たとき、モデルそのものが壊れているとは限りません。
単純にAPIに登録されているモデルIDと、クライアント側で指定した名前が違っているケースがあります。
Thinking Modeはどう使う？
Qwen3.8-27BではThinking Modeを使うことができます。
複雑なコード解析や問題解決では便利ですが、常にONにすればいいわけではありません。
たとえば、
- 複雑なコードレビュー
- バグの原因分析
- 設計判断
- 数学的な問題
- 複数ステップの作業
などではThinkingを使う価値があります。
一方、
- 短い文章の修正
- 単純な要約
- JSON変換
- 簡単な質問
なら、思考を無効にしたほうがレスポンスが速くなることがあります。
非Thinkingの場合は、たとえば次のような指定を使います。
{ "temperature": 0.7, "top_p": 0.8, "presence_penalty": 1.5, "chat_template_kwargs": { "enable_thinking": false }}
ただし、ここも重要なのですが、モデルや推論フレームワークのバージョンに合わせて公式推奨値を確認するようにしてください。
「別のQwenモデルで使っていた設定をそのままコピーする」のは、ローカルLLMでは意外と危険です。
GGUFとFP8、どちらを選ぶべき？
ここまで読んで、
結局どっちを使えばいいの？
と思った人も多いでしょう。
かなり単純化すると、次のように考えて大丈夫です。
| 項目 | GGUF + llama.cpp | FP8 + vLLM |
|---|---|---|
| 導入難易度 | 低め | 高め |
| 主な環境 | GPU / Mac / CPU | NVIDIA GPU |
| 24GB GPU | ◎ | △ |
| 48GB以上 | ○ | ◎ |
| APIサーバー | ○ | ◎ |
| 個人利用 | ◎ | ○ |
| 複数ユーザー | △ | ◎ |
| 量子化 | ◎ | ○ |
| Agent用途 | ○ | ◎ |
| 初心者 | おすすめ | 慣れてから |
最初の一台なら、私はGGUF + llama.cppをすすめます。
理由は単純です。
失敗したときに原因を切り分けやすいからです。
「まずモデルを動かす」という目的なら、複雑なサーバー構成を最初から組む必要はありません。
一方で、AIアプリを開発していて、
自分のプログラムからAPIとして呼びたい
という段階まで来ているなら、vLLMを試す価値が高くなります。
実際にどんな用途で使える？
Qwen3.8-27BをローカルAPIにすると、かなり応用範囲が広がります。
たとえば自分の開発環境に、
VS Code ↓自作AIクライアント ↓http://127.0.0.1:8000/v1 ↓Qwen3.8-27B
という構成を作ることができます。
さらに、
ユーザー ↓Webアプリ ↓FastAPI ↓Qwen3.8-27B ↓回答
とすれば、独自のAIサービスも作れます。
たとえば、
ログ解析ツール
なら、
ログファイル ↓FastAPI ↓Qwen3.8-27B ↓エラー原因を分析 ↓日本語で説明
という流れにできます。
コードレビューなら、
Git差分 ↓LLM ↓問題点 ↓修正案
という仕組みも作れます。
ここまで来ると、ローカルLLMは「ChatGPTの代用品」というより、自分のソフトウェアに組み込める推論エンジンとして考えたほうが分かりやすくなります。
Qwen3.8-27Bのメリット
データを外部APIへ送らなくていい
ローカル運用の大きなメリットです。
自分のPCや社内サーバーで処理するなら、設計次第でソースコードやログなどを外部APIに送らずに済みます。
もちろん、ローカルだから自動的に安全という意味ではありません。
APIを外部公開したり、ログを別サーバーへ送ったりすれば、当然データは外へ出ます。
API料金を気にせず試せる
クラウドAPIでは、
入力トークン+出力トークン=料金
という形になります。
ローカルでは、モデルそのものを取得した後は、主に電気代とハードウェアコストが中心です。
大量のテストやAgent開発では、この差が意外と大きくなります。
モデルを自分で管理できる
APIサービスではモデルが更新されると、挙動が変わることがあります。
ローカルなら、
モデルA↓モデルAの量子化版↓設定を固定
というように、自分で環境を管理できます。
再現性を重視する開発では、この点が便利です。
デメリットもある
もちろん良いことばかりではありません。
一番大きいのは、ハードウェアコストです。
27Bモデルを快適に動かそうと思えば、それなりのGPUやメモリが必要になります。
さらに、GPUを長時間動かせば電気代もかかります。
クラウドAPIなら数分で使えるところを、ローカルでは、
GPU購入↓ドライバ設定↓CUDA↓Python↓推論フレームワーク↓モデル↓API
と準備する必要があります。
つまり、ローカルLLMは「無料」というより、
自分でインフラを持つ代わりにAPI料金を減らす方法
と考えたほうが実態に近いでしょう。
初心者がよくハマる5つのポイント
1．モデルがVRAMに入れば動くと思ってしまう
これが一番多いです。
重みだけではありません。
KV Cacheや推論処理にもメモリが必要です。
特に長いコンテキストを設定すると、必要なメモリが急激に増えます。
最初は8K～32K程度から始めるのがおすすめです。
2．GPUを持っているのにCPUで動いている
GPU対応版を入れたつもりでも、実際にはCPU推論になっていることがあります。
推論速度が極端に遅い場合は、
- GPUが認識されているか
- CUDAが利用できるか
- GPUオフロードが有効か
- CPUへ大量にレイヤーが落ちていないか
を確認してください。
3．起動したまま何分も待ってしまう
初回起動では数十GBのモデルをダウンロードしたり、必要なKernelを準備したりする場合があります。
「固まった」と判断する前に、ターミナルのログとディスク使用量を確認しましょう。
4．いきなり262Kコンテキストにする
これはおすすめしません。
長文対応はQwen3.8-27Bの魅力ですが、実用上は必要な長さだけ設定したほうが軽くなります。
まず、
8192
次に、
16384
さらに、
32768
と増やしていけば十分です。
5．ローカルAPIをそのままインターネットへ公開する
これは特に注意してください。
今回の例では、
127.0.0.1
を使っています。
これは基本的に自分のPCからのアクセスを想定した設定です。
もし、
0.0.0.0
で公開するなら、
- APIキー
- 認証
- HTTPS
- Firewall
- Reverse Proxy
- Rate Limit
- アクセスログ
などを考える必要があります。
「ローカルで動くAI」と「インターネットに公開されたAI API」は、まったく別のセキュリティ問題を持っています。
他のローカルLLM環境と比較すると？
Qwen3.8-27Bを使う方法は、llama.cppとvLLMだけではありません。
| 方法 | 初心者向け | API | GPU自由度 | サーバー用途 |
|---|---|---|---|---|
| llama.cpp | ◎ | ◎ | ◎ | ○ |
| vLLM | △ | ◎ | ○ | ◎ |
| Ollama | ◎ | ◎ | ○ | ○ |
| LM Studio | ◎ | ○ | ○ | △ |
| SGLang | △ | ◎ | ○ | ◎ |
ただし、Qwen3.8-27Bについては、モデル公開直後ということもあり、各ツールの対応状況が変化しています。
たとえば2026年8月上旬時点ではOllama側にQwen3.8の公式エントリーがないという情報もあり、最新モデルをすぐ試したい場合は、対応状況を個別に確認したほうが安全です。
そのため今回のような「公開直後のモデルをすぐ試したい」というケースでは、モデルカードと推論フレームワーク側の対応状況を確認してから環境を作ることをおすすめします。
本当に完全オフラインで使える？
ここも誤解されやすいところです。
モデルをローカルにダウンロードしても、それだけで完全オフラインになるわけではありません。
たとえば、プロンプトに、
https://example.com/image.jpg
のような画像URLを渡せば、その画像を取得するためにネットワークアクセスが発生する可能性があります。
完全にオフラインで利用したいなら、
モデル＋必要なファイル＋画像＋アプリケーション
をあらかじめローカルに用意しておく必要があります。
このあたりは「ローカルLLM」と「完全オフラインLLM」を分けて考えると分かりやすいでしょう。
まとめ｜27Bモデルをローカルで動かすなら、まずQ4から
Qwen3.8-27Bは、27Bという数字だけを見ると「一般的なPCでは無理そう」と感じます。
しかし量子化技術を使えば、24GBクラスのGPUでも現実的に試せる領域まで下げられます。
一方、FP8版を使って本格的なAPIサーバーとして運用するなら、48GB以上のNVIDIA GPUを用意したほうが余裕があります。
今回紹介した方法を整理すると、
24GB GPU / Apple Silicon
なら、
GGUF + llama.cpp + Q4
から始めるのが分かりやすいでしょう。
一方、
48GB以上のNVIDIA GPU
なら、
公式FP8 + vLLM
を選ぶことで、OpenAI互換APIとして自分のアプリやAgentへ接続しやすくなります。
そして、どちらを選ぶ場合でも、最初から262Kコンテキストを目指す必要はありません。
まず8K～32K程度でモデルを安定して動かし、その後にコンテキスト長、量子化、KV Cache、同時実行数を調整していくほうが、結果的に早く目的へたどり着けます。
Qwen3.8-27Bの面白さは、「27Bモデルが動いた」というところだけではありません。
ローカルでモデルを動かし、OpenAI互換APIとして公開し、自分のWebアプリやIDE、Agentから呼び出すところまで進めると、AIモデルを使う側から、AIを組み込んだソフトウェアを作る側へ一歩進めます。
今回のようなローカルLLMでは、モデルを起動できた時点はゴールではありません。
そこから、
「自分のPCで動くAIを、何の仕事に使えるか」
を考え始めると、ローカル推論の面白さが一気に増してきます。
なお、Qwen3.8-27Bは公開直後のモデルであり、コミュニティ側でもvLLM、GGUF、量子化版などの対応が急速に進んでいます。実際、公開直後から複数のGGUFやNVFP4、各種量子化版、長文コンテキストの検証結果が公開されています。
そのため、この記事のコマンドをそのままコピーするだけではなく、実際に使う時点のQwen公式Model Cardと推論フレームワークのリリース情報を確認することをおすすめします。
评论