17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kenimo49(Imoto Ken)

Qwen 3.5を「ちょっといいPC」で全モデル検証 — 9Bが死んで35Bが動く逆転現象

17
Last updated at Posted at 2026-03-05

はじめに — なぜローカルLLMを検証するのか

2026年に入って、Claude APIやChatGPTが数時間〜半日にわたって使えなくなるインシデントが何度も発生しています。クラウドAIに全依存していると、APIが止まった瞬間に業務が止まります。

実際に筆者の環境でも、AIエージェント（OpenClaw + Claude）を業務の中核に使っているため、Claude障害時に「何もできない時間」が発生しました。フォールバック先としてGLM等の代替APIを設定する方法もありますが、 「そもそもネットワークに依存しないローカルLLMを手元に持っておく」 という選択肢が現実的になりつつあります。

その転機がQwen 3.5です。

2026年2月末〜3月頭にかけて、Alibaba QwenチームがQwen 3.5シリーズを一気にリリースしました。

  • Mediumシリーズ（2/25）: Flash, 27B, 35B-A3B, 122B-A10B
  • Smallシリーズ（3/2）: 0.8B, 2B, 4B, 9B

201言語対応、マルチモーダル、100万トークンコンテキスト — スペックだけ見ると圧倒的です。

ただ、現実問題として聞きたいのは：

「自分のPCで動くの？」

RTX 4090を買えば大体動きます。でもグラボ単体で30万円以上、搭載PCなら50万円超えです。一方、RTX 4070搭載PCなら40万円前後で手に入る（グラボ単体は約9万円〜、2026年3月時点で高騰中）。ゲーミングPCとしても汎用マシンとしても、家庭用で最も現実的な選択肢です。

本記事では、RTX 4070（VRAM 12GB）+ 32GB RAM の実機で、Qwen 3.5の5モデルを実際に動かして検証しました。

検証環境

項目 スペック
GPU NVIDIA GeForce RTX 4070
VRAM 12,282 MiB（12GB GDDR6X）
RAM 32GB DDR4
OS Ubuntu 24.04（WSL2）
CUDA 12.9
Driver 577.00
推論エンジン Ollama 0.17.5
量子化 Ollamaデフォルト

Qwen 3.5 全モデル一覧

まず全体像です。Qwen 3.5は8モデルが存在します。

モデル パラメータ 種別 モデル重み※ RTX 4070
Qwen3.5-0.8B 0.8B Dense ~1GB ✅ 余裕
Qwen3.5-2B 2B Dense ~1.5GB ✅ 余裕
Qwen3.5-4B 4B Dense ~3GB ✅ 余裕
Qwen3.5-9B 9B Dense ~6GB ⚠️ 後述
Qwen3.5-27B 27B Dense ~18GB ❌ 超過
Qwen3.5-35B-A3B 35B (3B active) MoE ~20GB ⚠️ 後述
Qwen3.5-122B-A10B 122B (10B active) MoE ~72GB ❌ 不可
Qwen3.5-Flash - API only - API経由

※ Q4量子化時のモデル重みサイズ。実行時はKVキャッシュ・アクティベーション・CUDAコンテキスト等で実際のVRAM使用量は2〜3倍になります。これが9Bの罠です（後述）。

この中から、RTX 4070で動く可能性がある5モデル（0.8B, 2B, 4B, 9B, 35B-A3B）を検証しました。

MoEモデルの「罠」に注意

「35B-A3Bは実行時3Bしか使わないんだから、軽いんでしょ？」

違います。

MoE（Mixture of Experts）は推論時にアクティブなパラメータが少ないだけで、全パラメータをメモリ上に保持する必要があります。35Bの重みをすべてロードし、その中から3Bを選んで使う。だからVRAM 12GBには収まらず、残りをRAMにoffloadする形になります。

検証タスク

各モデルに同じ4種のタスクを実行させました。

# タスク 内容 意図
1 日本語要約 LLMセキュリティに関する200文字の技術文を3行に要約 日本語理解力
2 英日翻訳 Context Engineeringに関する英文を自然な日本語に翻訳 多言語能力
3 Pythonコード生成 URL→HTMLタイトル抽出関数（エラーハンドリング付き） コーディング実用性
4 日本語推論 「田中さんは電車に間に合うか？」（速度×距離の文章題） 論理的推論

検証結果

サマリー

モデル VRAM使用量 推論速度 要約 翻訳 コード 推論 判定
0.8B 2.5 GB 258 tok/s ✅ △ ✅ ❌ 🟢 爆速
2B 4.2 GB 148 tok/s ✅ △ ✅ ❌ 🟢 快適
4B 5.9→11.8 GB 108→36 tok/s ✅ ❌※ ✅ ✅ 🟡 注意
9B 11.7 GB タイムアウト ❌※ ❌※ ✅ △※ 🔴 非実用
35B-A3B 11.5 GB 10.6 tok/s ❌※ ❌※ ❌※ △※ 🟡 待てるなら

参考: クラウドAPIの出力速度（Artificial Analysis 2026年3月時点）

モデル 出力速度 備考
GPT-4o ~135-175 tok/s OpenAI直接
Claude 4.5 Sonnet ~69-101 tok/s プロバイダにより差大
Claude 3.5 Sonnet ~35-58 tok/s Vertex最速58

ローカルの0.8B（258 tok/s）や2B（148 tok/s）はGPT-4oと同等以上の出力速度。4Bの初回108 tok/sもClaude Sonnetに匹敵します。もちろん品質はクラウドモデルとは比較にならないので、 「速度は出る。問題は品質」 — これがローカルLLMの現在地です。

※ = Thinkingモードの思考過程が長すぎて120秒のタイムアウト内に最終回答まで到達できなかった
△ = 回答は出力されたが品質に問題あり

発見①: 0.8B — 爆速258 tok/s、だが推論に限界

VRAM 2.5GBしか使わず、258 tok/s。人間が読む速度を遥かに超えています。

要約・コード生成は問題なく動きますが、推論と翻訳に弱点が出ました。

実際の出力

日本語要約 ✅

近年、大規模言語モデルの発達によりソフトウェア開発のワークフローが変化しています。AI エージェントはローカル環境でコマンドを実行できますが、プロンプトインジェクション攻撃によって機密ファイルが漏洩する可能性があります。しかし、「Vibe Coding」普及を伴う一方でセキュリティ対策が必要です。

英日翻訳 △

「文脈エンジニアリングの核心は、必要な要素を選ばないことと同様に含めるべきもの同等に重要である。すべての不適切に含まれるトークンはパフォーマンスを低下させる。」

意味は伝わるが「含めるべきもの同等に重要」など助詞が欠落し、日本語として不自然。

Pythonコード生成 ✅

import re
import requests

def get_page_title(url):
    try:
        response = requests.get(url)
        if response.status_code in [400, 401, 404]:
            return None
        match = re.search(r'<title>(.*?)</title>', response.text, re.DOTALL)
        return match.group(1) if match else "Title tag not found"
    except Exception as e:
        print(f"Error retrieving page title: {e}")
        return None

正規表現でtitleタグを抽出。動くが、BeautifulSoup等のパーサーを使わないため不安定。

日本語推論 ❌ 不正解

思考過程が英語で109ステップも暴走し、最終的に「Tominaga cannot catch the train（間に合わない）」と誤った結論。「田中」を「Tominaga」と読み間違えている点も興味深い。計算自体は「7:30到着、7:35出発」と正しいのに、「到着が出発より早い＝間に合わない」と逆の結論を出しています。

向いている用途： エッジデバイス、リアルタイムチャットbot、テキスト分類、簡易要約

発見②: 2B — コスパ最強、日本語も実用レベル

VRAM 4.2GB、148 tok/s。要約・コード生成は安定、翻訳・推論に弱さが残ります。

実際の出力

日本語要約 ✅

LLM と AI ツールの普及により、ソフトウェア開発の効率化が進んでいる。
しかし、AI エージェントがローカルコマンドを実行できるためセキュリティリスクがある。
プルモインジェクション攻撃によって API キーや機密情報が漏洩する可能性がある。

「プロンプトインジェクション」→「プルモインジェクション」と誤変換しているが、内容は正確。

英日翻訳 △

【コンテキストエンジニアリングの要諦】「プロンプトから何を除外するか」と「含める要素」は同等の重要性を持ちます。つまり、含まない要素をどう選択かがパフォーマンスに影響します。

構造は正しいが「どう選択か」の助詞欠落あり。原文の「Every unnecessary token degrades performance」のニュアンスも薄れています。

Pythonコード生成 ✅

def get_html_title(url: str) -> str | None:
    try:
        response = urllib.request.urlopen(url, timeout=10)
        html_content = response.read().decode("utf-8", errors="ignore")
        parser = BeautifulSoup(html_content, "html.parser")
        title_tag = parser.find("title")
        return str(title_tag.get_text()) if title_tag else None
    except urllib.error.HTTPError as e:
        print(f"HTTP エラーが発生しました：{e.code}")
        return None
    except urllib.error.URLError as e:
        print(f"URL リクエストエラーが発生しました：{str(e.reason)}")
        return None
    except Exception as e:
        print(f"不明なエラーが発生しました：{type(e).__name__}: {e}")
        return None

urllib + BeautifulSoup。型ヒント付きで、エラーハンドリングも適切。

日本語推論 ❌ 不正解

英語で思考し、計算は正しい（7:30到着 < 7:35出発）のに、「He is too early — arriving at 7:30 at a station opening at 7:35 would mean he missed the window」と誤った推論。「間に合う」を「ぴったり到着する」と解釈してしまったようです。

向いている用途： チャットbot、日本語テキスト処理、コード補完、軽量AIアシスタント

発見③: 4B — 推論力は本物、ただし「VRAM膨張」の罠

4Bは推論タスクで正答を出した最小モデル。品質は高いですが、VRAM管理に注意が必要です。

VRAM膨張の実測

1タスク目（日本語要約）: VRAM 5,872 MiB → 108 tok/s
2タスク目（英日翻訳）  : VRAM 11,850 MiB → 80 tok/s
3タスク目（コード生成）: VRAM 11,844 MiB → 36 tok/s
4タスク目（推論）      : VRAM 11,840 MiB → 36 tok/s

1タスク目は快適だったのに、2タスク目以降でVRAMが倍増してスピードが1/3に。

これはKVキャッシュの動的拡張が原因です。Qwen 3.5はThinking（思考）モードがデフォルト有効で出力トークンが非常に長くなるため、KVキャッシュが肥大化します。

対策:

  • --num-ctxでコンテキスト長を制限する（例: 4096）
  • /no_thinkプレフィックスでThinkingを無効化する
  • OLLAMA_KV_CACHE_TYPE=q8_0でKVキャッシュを量子化する
# コンテキスト長を制限して起動
ollama run qwen3.5:4b --num-ctx 4096

実際の出力

日本語要約 ✅

近年、LLM と AI ツールが普及し「Vibe コーディング」で開発が変わった。
しかし便利さの裏にプロンプトインジェクションによる機密情報漏洩リスクが潜んでいる。
AI エージェントのローカルコマンド実行可能により API キーやデータへの注意が必要だ。

3モデル中、最も簡潔で読みやすい要約。

英日翻訳 ❌ — Thinkingモード内で翻訳用語の選択（コンテキスト/文脈、トークン/語素 等）を延々と検討し続け、タイムアウト。

Pythonコード生成 ✅

import requests
from bs4 import BeautifulSoup

def extract_title(url: str) -> str | None:
    try:
        response = requests.get(url, timeout=10)
        response.raise_for_status()
        soup = BeautifulSoup(response.text, 'html.parser')
        title_tag = soup.find('title')
        if title_tag and title_tag.string:
            return str(title_tag.string).strip()
    except RequestException as e:
        print(f"Request failed: {e}")
    except Exception as e:
        print(f"Parsing error: {e}")
    return None

requests + BeautifulSoup。raise_for_status()でステータスチェック、.strip()で整形。洗練された実装。

日本語推論 ✅ 正解

はい、田中さんは電車に間に合います。

  1. 歩くにかかる時間 — 2km ÷ 時速4km = 0.5時間 = 30分
  2. 駅への到着時刻 — 7時 + 30分 = 7時30分
  3. 電車の発車時刻との比較 — 到着時刻（7:30） ＜ 発車時刻（7:35）
  4. 結論 — 田中さんは駅に5分早く着き、電車に乗ることが可能です。

計算、日本語、論理構成すべて正確。0.8B・2Bと同じ計算をしながら、正しい結論を導出できるのは4Bから。

向いている用途： コード生成、技術文書作成、品質が必要なタスク全般（コンテキスト長制限必須）

発見④: 9B — VRAMギリギリの罠

9Bはほぼ全タスクでタイムアウト（120秒） しました。

VRAM使用量は11,675〜11,687 MiB。12,282 MiBの上限まで残り600 MiBしかありません。KVキャッシュの確保もままならず、推論速度が極端に低下します。

パラメータ数だけ見れば「6GB程度で収まるはず」ですが、実際にはKVキャッシュ、アクティベーション、CUDA Contextなどで12GBを使い切ります。

唯一の例外: コード生成は成功

import requests
from bs4 import BeautifulSoup
from urllib.parse import urlparse

def get_html_title(url: str, timeout: int = 10) -> str | None:
    try:
        parsed_url = urlparse(url)
        if not all([parsed_url.scheme, parsed_url.netloc]):
            raise ValueError(f"有効なURLではありません: {url}")
        headers = {'User-Agent': 'Mozilla/5.0 ...'}
        response = requests.get(url, headers=headers, timeout=timeout)
        if response.status_code != 200:
            raise Exception(f"HTTP {response.status_code}: {response.reason}")
        soup = BeautifulSoup(response.text, 'html.parser')
        if soup.find('title'):
            return soup.find('title').get_text(strip=True)
        return None
    except requests.exceptions.TooManyRedirects:
        raise Exception("リダイレクト超過：このURLは無効なようです")
    except requests.exceptions.ConnectionError as e:
        raise Exception(f"接続エラーが発生しました: {str(e)}")
    except requests.exceptions.Timeout:
        raise Exception("リクエストがタイムアウトしました")
    except requests.exceptions.RequestException as e:
        raise Exception(f"ネットワークエラー: {str(e)}")

URLバリデーション、User-Agent設定、例外の細分化まで完備。全モデル中最高品質のコードでした。しかし他の3タスクはすべてタイムアウト。

推論タスクは正答（「間に合います」）を出力し始めたものの、Thinkingに時間を使いすぎて途中で120秒超過。

9Bを快適に動かすには最低16GB VRAM（RTX 4070 Ti SUPER等）が必要です。

発見⑤: 35B-A3B（MoE）が9Bより動く逆転現象

最も意外だったのがこれです。

9Bが全滅する一方、35B-A3Bは10.6 tok/sで推論を開始。推論タスクでは正答を出力し始めました。

なぜ9Bが死んで35Bが動くのか

MoEアーキテクチャがカギです。35B-A3Bは推論時に3Bしかアクティブにならない。全35Bの重みはメモリに載せる必要がありますが、実際の計算は3B分で済むため、GPU処理自体は軽い。VRAMに収まらない分はRAM（32GB）にoffloadされます。

35B-A3B の推論フロー:
全35B重み → VRAM 12GB + RAM 20GB にロード
推論時    → 3Bのエキスパートだけ計算 → 10.6 tok/s

一方、9B（Dense）は全9Bを常にGPU上で演算する必要があり、12GB VRAMでは物理的に足りません。

実際の出力

日本語推論 ✅ 正解（タイムアウトで途切れ）

田中さんは電車に間に合います。

  1. 距離は2km、速度は時速4kmなので、$2 \div 4 = 0.5$時間 = 30分
  2. 駅に到着する時刻の計算（ここでタイムアウト）

正答を出力し始めたが、Thinkingモードの思考過程が非常に長く120秒を超過。4タスク中3タスク（要約・翻訳・コード）は最終回答まで到達できずタイムアウトでした。

向いている用途： 高品質な回答が必要だが、レスポンス待ちを許容できる場面（コードレビュー、文章添削など）。Thinking無効化（/no_think）で改善の余地あり。

タスク横断比較

推論タスク: 4B未満は「計算はできるが結論を間違える」

モデル 正答 思考言語 特記事項
0.8B ❌ 英語 計算は正しいが結論が逆
2B ❌ 英語 「間に合う」の意味を誤解
4B ✅ 英語→日本語 完璧な回答
9B ✅ 英語→日本語 正答だが途中でタイムアウト
35B-A3B ✅ 英語→日本語 正答だが途中でタイムアウト

0.8Bと2Bは 2km ÷ 4km/h = 30分 の計算は正しいのに、「7:30 < 7:35 → 間に合う」の最後の論理ステップで失敗。パラメータ数が論理的推論能力に直結する ことを示しています。

コード生成: モデルサイズに比例して品質が上がる

モデル ライブラリ エラーハンドリング 実用度
0.8B requests + 正規表現 最低限 △ 動くが脆い
2B urllib + BeautifulSoup 適切 ○ 実用的
4B requests + BeautifulSoup 適切 ◎ 洗練
9B requests + BeautifulSoup + urlparse 細分化 ◎ プロダクション品質
35B-A3B — — ❌ タイムアウト

RTX 4070ユーザーへの結論

用途別おすすめモデル

用途 おすすめ 理由
リアルタイムチャット 0.8B 258 tok/s、遅延なし
日常のAIアシスタント 2B 148 tok/s × 日本語実用レベル
コード生成・技術文書 4B（ctx制限付き） 品質と速度のバランス
高品質な分析・レビュー 35B-A3B 10 tok/s だが品質は段違い
❌ 避けるべき 9B 12GB VRAMでは実用不可

「実質使える」ラインはどこか？

0.8B ─── 2B ─── 4B ──── 9B ──── 35B-A3B
 快適     快適    注意     NG      待てるなら
258t/s  148t/s  36t/s   死亡     10.6t/s

RTX 4070の「スイートスポット」は2B〜4B です。

  • 速さ重視なら2B（VRAM 4.2GBで余裕あり）
  • 品質重視なら4B（ただしコンテキスト長制限必須）
  • 待てるなら35B-A3B（RAM 32GB以上推奨）
  • 9Bは罠。 スペック上は収まりそうに見えて、実際は12GB VRAMではまともに動きません

RTX 4070で運用するTips

# 1. KVキャッシュを量子化してVRAM節約
OLLAMA_KV_CACHE_TYPE=q8_0 ollama serve

# 2. コンテキスト長を制限（VRAM膨張防止）
ollama run qwen3.5:4b --num-ctx 4096

# 3. Thinkingモードを無効化（出力を短く）
# プロンプトの先頭に /no_think を付ける

# 4. 使い終わったモデルをアンロード
ollama stop qwen3.5:4b

まとめ

RTX 4070（12GB VRAM）はQwen 3.5を動かすのに十分実用的なGPUです。ただし「どのモデルを選ぶか」で体験が大きく変わります。

  1. 0.8B〜2Bは何も考えずに快適に動きます。 日常のチャットやテキスト処理はこれで十分
  2. 4Bはコンテキスト長の管理が必要。 放っておくとVRAMが膨張して速度が落ちます
  3. 9Bは12GB VRAMでは実用不可。 16GB以上のGPUを使ってください
  4. 35B-A3B（MoE）は意外と動く。 RAM 32GB以上あれば10 tok/sで高品質な回答が得られます
  5. 9Bが動かないのに35Bが動く。 MoEの「3Bだけ使う」設計がRTX 4070と相性が良い

ローカルLLMは「動くか動かないか」ではなく、 「どのモデルがどの用途に実用的か」 を知ることが重要です。本記事がRTX 4070ユーザーの参考になれば幸いです。

スライドでおさらい

この検証（5モデル × VRAM・速度・品質）の要点を、12枚のスライドにまとめました。

この記事が参考になったら、いいね👍をお願いします。

📖 本記事を体系化した書籍(発売中)

本記事のような実測ノートを、Ollamaの 12.2 tok/s を -ngl 99 --cpu-moe で 34.6 tok/s(2.8倍)まで引き上げる勝ち構成から、KV キャッシュ量子化、Qwen 3.5 vs 3.6 の世代差、ローカル 35B のエージェント化まで、通しで 1 冊にまとめました。

RTX 4070 で Qwen 35B を 2.8 倍速くする ― 自分の数字を疑え、実測ノート

序章 + 第1章 + 第2章は無料公開中(¥1,200)。

無料の 12 枚スライド版もあります:

17
9
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?