blog

Qwen ローカル使い方 完全ガイド:Ollama・LM Studio・vLLM対応

Qwen ローカル使い方 完全ガイド:Ollama・LM Studio・vLLM対応

Qwen ローカル使い方の前提:二層構造を正確に把握する

Qwenをローカル環境で動かす需要は、2025年後半以降に急速に高まっている。背景には、AlibabaのQwenチームがQwen3シリーズのオープンウェイト版をApache 2.0ライセンスで公開し、商用利用可能な状態で無償配布したことがある(Qwen3公式ブログ, 2026-06-08)。

ただし、実装を始める前に提供形態の二層構造を正確に理解しておく必要がある。この区別を誤ると、環境構築の前提が根本から崩れる。

  • クローズドAPI専用モデル(qwen3-max, qwen3.5-plus, qwen3.5-flash等):重み非公開。Alibaba Cloud Model Studio経由でのみ利用可能。HuggingFaceからのダウンロードは不可。
  • オープンウェイトモデル(Qwen3-235B-A22B, Qwen3-32B, Qwen3-14B, Qwen3-8B, Qwen3-4B, Qwen3-1.7B, Qwen3-0.6B等):Apache 2.0、無償ダウンロード・商用利用可。ローカル実行の対象はこちらのみ(HuggingFace Qwen3コレクション, 2026-06-08)。

旗艦モデルのqwen3-maxは1Tパラメータ超のMoE構成だが、重みは非公開であり、「Qwen3-MaxをHuggingFaceから無料DLしてローカル実行する」という構成は存在しない(Alibaba Cloud Model Studio — Supported Models, 2026-06-08)。

Qwen提供形態の二層構造:クローズドAPIとオープンウェイトの分類図 クローズド(API専用) qwen3-max / qwen3.5-plus qwen3.5-flash / qwen-max 等 重み非公開 Alibaba Cloud Model Studio / Qwen Chat から利用 ローカル実行:不可 オープンウェイト Qwen3-235B-A22B / 32B / 14B 8B / 4B / 1.7B / 0.6B 等 Apache 2.0 HuggingFace 等で無償 DL 商用利用可(ライセンス要確認) ローカル実行:可能
図1. Qwenの提供形態二層構造。ローカル実行の対象はオープンウェイト版のみ(出典:Alibaba Cloud Model Studio, 2026-06-08)

ローカル実行を選ぶ技術的な根拠は主に三点だ。第一にデータ主権:機密情報を外部APIに送信できないユースケース(医療・金融・製造ライン品質検査など)では、オンプレミス実行が要件になる。第二にレイテンシ:閉域網や工場ラインでは外部APIへのルートが存在しないか、RTTが実用に耐えない。第三に大量推論コスト:月数億トークンを超えるバッチ処理では従量課金が累積し、ハードウェア固定費を上回るケースがある。

逆に言えば、これら三点が当てはまらない用途では、クラウドAPIの方がトータルコストが低くなりやすい。この判断軸は後述する。

Qwen3シリーズの詳細なモデル仕様についてはQwen3の解説記事を、世代間の違いの整理はQwenシリーズの違いを整理した記事を参照されたい。

Qwen ローカル使い方:モデル選定と推奨スペック

ローカル実行における最初の意思決定は「どのモデルサイズを選ぶか」だ。モデルサイズと量子化の組み合わせで必要VRAMが大きく変動するため、保有ハードウェアから逆算して選定する。

モデルサイズ・VRAM・用途の対応表

以下は、GGUF Q4_K_M量子化を基準とした目安値だ。実際の消費VRAMはコンテキスト長・バッチサイズ・推論エンジンによって前後する。数値はHuggingFace Qwen3コレクションおよびDevelopersIO(2026)を参考にした目安であり、環境差があることを前提として扱うこと。

モデル 総パラメータ 活性パラメータ Q4量子化VRAM目安 想定用途
Qwen3-0.6B 0.6B 約1〜2 GB エッジ・組み込み
Qwen3-1.7B 1.7B 約2〜3 GB 軽量タスク・動作確認
Qwen3-4B 4B 約3〜4 GB 省メモリ実運用
Qwen3-8B 8B 約5〜6 GB 日常業務・コーディング支援
Qwen3-14B 14B 約9〜11 GB 高品質テキスト生成・翻訳
Qwen3-32B 32B 約20〜24 GB 複雑な推論・エージェント
Qwen3-30B-A3B(MoE) 30B 3B 約4〜6 GB(推論時) 軽量MoE・高速推論
Qwen3-235B-A22B(MoE) 235B 22B 約130 GB以上(フル) 研究・高性能サーバー

MoEモデルは推論時の活性パラメータが少ない設計であり(例:Qwen3-30B-A3Bは活性3B相当)、推論速度とVRAM効率の観点で優れている。ただしモデルファイル全体のロードには総パラメータ分のディスクI/Oが発生するため、ストレージ帯域幅も考慮が必要だ。

量子化レベルの選択基準

GGUF形式ではQ4_K_Mが汎用的な出発点となる。品質とVRAMのトレードオフとして、Q8_0はほぼ損失なしだがファイルサイズが約2倍になる。Q2_K以下は小型デバイスへの詰め込み用であり、出力品質の劣化が顕著になりやすい。まずQ4_K_MまたはQ5_K_Mで試し、品質が要件を満たさない場合にQ8へ上げるという手順が効率的だ。数学証明やコード生成といった精度要求が高いタスクでは、Q4でのエラー率がQ8と比較して増える傾向があることは事前に把握しておくべきだ。

MoEとdenseの使い分けや各モデルの特性についてはQwenモデル比較記事で詳しく整理している。

ローカルLLMの導入やRAG構築をご検討の方は、AI開発会社クリスタルメソッドの無料相談をご利用ください。

Qwen ローカル使い方:Ollama・LM Studio・vLLMの具体的手順

ローカル実行のツールは用途とスキルセットで使い分ける。2026年現在の主流は以下の三系統だ。

1. Ollama(CLI・最速セットアップ)

Ollamaはモデルのダウンロード・起動・OpenAI互換APIサーバーの立ち上げをコマンド一本で完結させる。エンジニアがプロトタイプを即席で立てる場合の第一選択肢になりやすい(DevelopersIO, 2026)。

# Ollamaのインストール(macOS/Linux)
curl -fsSL https://ollama.com/install.sh | sh

# Qwen3-8Bを取得して対話開始(Q4量子化版が自動選択)
ollama run qwen3:8b

# MoEモデルを使う場合
ollama run qwen3:30b-a3b

# thinkingモードを無効化したい場合はプロンプト冒頭に /no_think を付ける
# 例: /no_think このコードをレビューしてください。

Ollama起動後、デフォルトでlocalhost:11434にOpenAI互換のREST APIが立ち上がる。既存のOpenAI SDK実装を最小変更で流用できるため、社内ツールへの組み込みが容易だ。

# Pythonからの呼び出し例(openaiライブラリ使用)
import openai

client = openai.OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama"  # Ollamaはキー不要だが引数として必要
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
        {"role": "user", "content": "Pythonでバイナリサーチを実装してください。"}
    ]
)
print(response.choices[0].message.content)

Qwen3のthinkingモード切替については、Ollamaの場合はプロンプトに/no_thinkを前置する方法が確認されている(Zenn, 2026-05)。ストリーミングレスポンスの<think>タグ内がthinking過程であり、アプリ側でパースして表示・非表示を制御する実装が一般的だ。

2. LM Studio(GUI・ノーコード運用)

LM StudioはHuggingFaceからのモデル検索・ダウンロード・実行をGUIで完結させる。CLIに不慣れなチームメンバーへの展開や、複数モデルを手軽に比較したい場面に向いている。OpenAI互換のローカルサーバー機能を内蔵しており、localhost:1234でAPIを公開できる(DevelopersIO, 2026)。

  1. 公式サイト(lmstudio.ai)からプラットフォーム別インストーラを取得してインストールする。
  2. 「Discover」タブで「qwen3」を検索し、対象サイズ・量子化を選択してダウンロードする。
  3. 「Chat」タブでモデルをロードし、対話を開始する。
  4. 「Local Server」タブでサーバーを起動し、APIエンドポイントを外部アプリに渡す。

注意点として、大型モデルのロード時間はストレージのI/Oスループットに大きく依存する。NVMe SSD上にモデルファイルを配置することで体感速度が改善しやすい。また、LM StudioはGPU推論(CUDA/Metal)に対応しているが、ドライバとcudaバージョンの組み合わせによっては手動設定が必要になるケースがある。

3. vLLM(本番グレードのスループット重視)

vLLMはページドアテンションとバッチ処理の最適化により、高いスループットを実現するオープンソースの推論エンジンだ。GPU複数枚のtensor parallelism対応、本番APIサーバーとしての運用を想定する場合の標準候補となる。

# vLLMのインストール
pip install vllm

# Qwen3-14BをOpenAI互換APIサーバーとして起動
python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen3-14B \
  --tensor-parallel-size 2 \
  --dtype bfloat16 \
  --port 8000

vLLMはHuggingFaceのモデルIDを直接指定できる。--tensor-parallel-sizeでGPU分散枚数を指定する。BF16実行にはAmpere世代以降(A100・H100・RTX 3090/4090等)を推奨する。大規模バッチ推論や同時接続数が多いAPIサーバー用途ではOllamaより明確にスループットで優位に立つ。ただし、セットアップの複雑度もOllamaより高く、CUDAドライバ・PyTorchバージョンの依存関係管理が運用コストとして乗ってくる点も現実として把握しておくべきだ。

コーディング特化モデルのローカル活用についてはQwen-Coderの解説記事を、マルチモーダル推論にはQwen-VLの実装ガイドを参照されたい。

Qwen3のthinking/非thinkingモード制御と実装上の落とし穴

Qwen3の設計上の特徴として、thinkingモード(Chain-of-Thought)と非thinkingモードの切替が実装の核心になる。Qwen3公式ブログ(qwenlm.github.io, 2026-06-08)によれば、Qwen3は119言語に対応し、この二モードの切替を設計の中核に据えている。

Transformersライブラリでの制御

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen3-8B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(
    model_name, torch_dtype="auto", device_map="auto"
)

messages = [{"role": "user", "content": "再帰的なバイナリサーチをPythonで実装してください。"}]

# thinkingモードを無効化する場合(enable_thinking=False)
tokenized = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    enable_thinking=False   # Trueにすると <think>タグ内に推論過程が展開される
)

inputs = tokenizer(tokenized, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=512)
print(tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True))

thinkingモードを有効にすると<think>...</think>ブロックに推論過程が展開され、数学・論理推論・複雑なコード生成といったタスクで最終回答の品質が向上するケースがある。一方でトークン消費量と応答レイテンシが増加するため、単純な分類・要約・抽出タスクには非thinkingモードが適している。

実装の判断基準は「タスクの複雑度」と「許容レイテンシ」のバランスによる。応答時間がSLAとして定義されているAPIサービスでは、thinkingモードの有効化が要件を満たさない可能性があるため、ベンチマークを取った上で判断すること。

システムプロンプト設計の注意点

thinkingモード有効時にシステムプロンプト内で/no_think相当の指示を混在させると、挙動が不安定になる報告がある(Zenn, 2026-05)。thinking/非thinkingの切替はモデルのチャットテンプレート引数またはプロンプトプレフィックスで一元管理し、システムプロンプトと混在させないことを強く推奨する。特にOllamaでの実装では、/no_thinkはユーザーターンの先頭に付与する形が現時点での確認されている動作だ。

メモリ管理とCPUオフロードの落とし穴

Transformersでの実行時、device_map="auto"は利用可能なGPUとCPUメモリを自動割り当てする。しかしCPUオフロードが発生すると推論速度がGPU実行と比較して桁違いに低下する。nvidia-smiまたはtorch.cuda.memory_summary()で常時モニタリングし、モデル全体がGPUメモリに収まる量子化・バッチサイズの組み合わせを選定することが安定稼働の要件となる。コンテキスト長を長くするほどKVキャッシュのVRAM消費が増えることも忘れずに設計に組み込むべきだ。

画像入力を含む用途にはQwen画像編集機能の実装例が参考になる。音声系の拡張についてはQwen TTSの解説記事を参照されたい。

ローカル運用の実践的トレードオフ:API vs. ローカルの意思決定基準

ローカル実行を本番環境に持ち込む前に、以下の観点で設計を検証しておく必要がある。

コスト構造の比較

機密データを扱わず、推論頻度が低い用途では、Alibaba Cloud Model StudioのAPIを使う方がトータルコストは低くなりやすい。2026-06-08時点の公式価格(Alibaba Cloud Model Studio — Model Pricing)によれば、qwen3.5-flashは入力約$0.05〜$0.25/100万トークン、出力約$0.40〜$2.00/100万トークンで段階課金される。GPUサーバーを24時間稼働させる電力・減価償却・運用工数と比較して判断すべきだ。

ローカル実行の優位性が出てくる条件は以下の通りだ。

  • データが外部送信不可(個人情報保護・営業秘密・規制対象データ)
  • 推論リクエスト量が月数億トークンを超える規模
  • ネットワーク遮断環境(工場ライン・研究機関の閉域網)
  • レスポンスタイムがミリ秒単位のSLAとして定義されている

なお、弊社が開発するDeepAIは、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン/AIアバターソリューションであり、対話AIやRAGを活用した閉域網・オンプレミス環境への展開も想定した設計が可能だ。LLMのローカル運用と同様に「データを外に出さない」設計原則が求められる接客・研修・広報用途でのAI活用についてもご相談いただきたい。

モデル更新追従のコスト

オープンウェイト版は新スナップショット(例:Qwen3-235B-A22B-2507のような日付付き更新版)がHuggingFaceに追加されていく。クラウドAPIでは最新版への切り替えがAPI側で行われるケースが多いが、ローカル運用では更新タイミングを運用者が管理する必要がある。モデルファイルのストレージ確保・再テスト・デプロイパイプラインのメンテナンスは、見えにくいランニングコストとして事前に計上しておくべきだ。

セキュリティ上の留意点

OllamaやvLLMのAPIサーバーはデフォルトでアクセス制御が最小限だ。社内ネットワーク内での運用であっても、認証レイヤー(APIキー・JWT等)を前段に設けることを推奨する。また、Alibaba CloudがオープンウェイトとしてQwen3Guard(安全用途特化モデル)を提供しており、入出力フィルタとして組み合わせる構成も検討に値する。ただし、Qwen3Guardの具体的な仕様・ライセンスについてはHuggingFace Qwen3コレクションで最新情報を確認すること。

旗艦クラスが必要な場面のハイブリッド構成

ローカルで対応しきれない旗艦クラスの性能が必要な場面では、オープンウェイトをローカルで動かしつつ、複雑なタスクをqwen3-max等のクローズドAPIにルーティングするハイブリッド構成も現実的な選択肢だ。APIコストとローカル運用コストの最適化についてはQwen料金の詳細解説が参考になる。

セットアップの詳細手順についてはQwen環境構築ガイドも合わせて参照されたい。Qwen ローカル使い方の全体像は「モデル選定→ツール選定→thinkingモード制御→本番化設計」の四段階で整理できる。手軽に試すならOllama、GUIで管理するならLM Studio、本番スループットを追うならvLLMという棲み分けが現時点での実用解だ。Qwen関連の最新情報は弊社ブログのQwen関連記事一覧も継続的に参照されたい。


弊社が開発するDeepAIは、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン/AIアバターソリューションだ。リップシンク・表情生成・音声合成・対話AIなどを組み合わせ、接客・研修・面接練習・広報等の用途に活用できる。LLMのローカル運用と同様に「データを外に出さない」設計原則が必要な場面での導入についても、ぜひご相談いただきたい。


参考文献

関連記事

監修

河合 継(クリスタルメソッド株式会社 代表取締役)

AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について編集方針

LLM・ローカルLLMの業務導入をご検討の方へ

クリスタルメソッドは、オープンモデル・ローカルLLMの選定からRAG構築・PoC・本番導入までのAI開発を支援しています。「機密データを外部に出さずにLLMを使いたい」「自社の業務に合うモデルを選びたい」といったご相談を承っています。

AIブログ購読

 
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • 教育 AI 活用 事例から学ぶ企業研修のDXとAnthropic無償提供が示すプロンプトの重要性

    教育 AI 活用 事例から学ぶ企業研修のDXとAnthropic無償提供が示すプロンプトの重要性

    ## 1. Anthropicによる教育者向けClaude無償提供ニュースの要点 2026年1月、AIスタートアップのAnthropicは、国際NGO「Teac...

  • AI人事評価のリスクと違法性の境界線とは?Meta社リストラ訴訟から学ぶ防衛策

    AI人事評価のリスクと違法性の境界線とは?Meta社リストラ訴訟から学ぶ防衛策

    近年、企業の意思決定プロセスにおいてAI(人工知能)の活用が急速に進んでいます。特に人事評価や採用、人員整理といった領域でのAI導入は、業務効率化や客観性の担保...

  • AIエージェントの相互運用性と規制がもたらす経営インパクト—米上院法案から紐解く日本企業の針路

    AIエージェントの相互運用性と規制がもたらす経営インパクト—米上院法案から紐解く日本企業の針路

    自律的にタスクを遂行するAIエージェントの台頭に伴い、異なるシステムやプラットフォーム間でこれらを安全に連携させる「相互運用性」と、それを支える「規制」のあり方...

View more