「Qwen3.5-9B は Q4量子化・6GB弱のVRAMで、日本語性能がGPT-4を超える」——ローカルLLM界隈でよく見かける類の触れ込みだ。M1 Max 64GBの実機に手持ちのqwen3.5:latest（6.6GB）があったので、実際にどうなのか確かめてみた。
先に結論を書く。**「GPT-4超えか」は測れなかった。**これを検証するには大量の日本語プロンプトに対する人間評価が要るし、そもそも比較対象のGPT-4に同条件でアクセスできない。この記事で測れたのは別のことだ——M1 Maxで実際にこのモデルを動かすと、何が起きるかという実測値である。
実機のモデル仕様
ollama show qwen3.5:latest で確認した実機のマニフェストは以下の通り。
architecture qwen35
parameters 9.7B
context length 262144
quantization Q4_K_M
Capabilities: completion / vision / tools / thinking
ollama list 上のディスク占有は6.6GB。ネタの前提「Q4/6GB VRAM」は実機で裏が取れた。context lengthは262144（26万トークン超）と、9.7Bクラスとしてはかなり広い文脈窓を確保している。ただし文脈窓の広さと生成の"軽さ"は別物だ。ここで見落としてはいけないのがCapabilities行のthinking——このモデルは応答を返す前に、内部で思考トークンを吐く挙動を持つ。これが後述する実測結果の核心につながる。
実測ベンチマーク — 答えは131字、出力は3936トークン
GPU信号機で他の生成ジョブと衝突しないことを確認してから、以下を1回実行した。
ollama run qwen3.5:latest --verbose '日本語で、あなた自身について150字程度で自己紹介してください。'
--verboseが出す実測値をそのまま引用する。
total duration: 1m44.06638s
load duration: 5.393837s
prompt eval count: 26 token(s)
prompt eval duration: 154.744ms
prompt eval rate: 168.02 tokens/s
eval count: 3936 token(s)
eval duration: 1m38.514761s
eval rate: 39.95 tokens/s
最終的に画面に出た日本語の回答文はこうだ。
私はAIアシスタントです。文章作成や要約、翻訳など幅広くサポートします。正確で丁寧な回答を提供し、礼儀正しくお話しいたします。ご質問やお困りのことがあれば遠慮なくご相談ください。皆様のお役に立ちたいと思い、業務効率化やアイデア出しなどのお手伝いを心掛けています。
文字数を数えると131字。依頼した「150字程度」にほぼ収まっている。だがeval countが示す総出力トークンは3936個。この差の大半は、画面には出ない<thinking>ブロックの中身——「文字数の数え方は全角/半角で変わるか」「安全性チェックはクリアしているか」といった、英語での長い自問自答だった。体感の生成時間（1分44秒）のほとんどは、131字の回答のためではなく、この見えない思考の時間だったということになる。
大まかな内訳を出すとこうなる。可視の回答131字は日本語なら200トークン未満で収まる（1文字≒1〜2トークン換算）。残る3736トークン超——出力全体の95%以上——が画面に出ない<thinking>側だったことになる。※あくまで概算で、思考ブロックのトークン数を個別に計測したものではない（--verboseが返すのはeval countの合計のみ）。
ここでeval rate: 39.95 tokens/sという数字の意味も変わってくる。これは3936個の出力トークン全体を平均した速度であって、「131字の答えが39.95 tok/sで出てきた」わけではない。ユーザーから見た体感は「1分44秒待って131字が返ってきた」であり、これは実効で見ると1.26字/秒相当（131字÷104秒）にすぎない。eval rateという1つの数字を鵜呑みにすると、この体感とのギャップを見落とす。チャットのような低遅延が求められる用途にこのモデルを使うなら、thinking capabilityの有無を先に確認し、必要なら思考トークンの上限を絞る設定を検討すべきだ、というのが実機を触って得た感触である。
正直な限界 — 中央値は取れなかった
1回だけの数字を鵜呑みにしないよう、同じプロンプトで2回目の実測を試みた。だが2回目はタイムアウトし、GPU信号機のロックが解放されないままOllamaが凍結状態で止まった。gpu-signal.sh runは「ロック取得→コマンド実行→ロック解放」を内部タイムアウト無しで同期実行するだけの作りで、ロック解放はコマンドの実行完了を待ってから呼ばれる。今回はコマンド呼び出し元のセッション側が先にタイムアウトして制御を返さなかったため、解放処理の行まで到達せず、ロックファイルが残ったと見られる（gpu-signal.sh本体のコードで確認）。
# 復旧に使った実際のコマンド
bash gpu-signal.sh release
# → [thaw] llama-server 復活 / [thaw] ollama serve 復活
# → ✅ Ollamaにフル復帰。会話・Claude Code接続が戻ります。
手動でロックを解放し、Ollama自体は正常復帰したことをstatusで確認した。実害は残さなかったが、**この記事のtok/s実測値は1回きりであり、複数回の中央値やばらつきは検証していない。**盛って書かない、が今回は「測れた回数そのものが少ない」という形で出た。
M4/M5の公表値とM1 Maxの位置
事前調査で確認したwillitrunai.com のQwen3.5 MLXガイドの要約によれば、Qwen3.5の9BクラスはM4/M5系で25〜35 tokens/sという数字が報告されている（このURLは出典として引用するのみで、この記事の執筆にあたって本文は開いていない）。今回のM1 Max実測のeval rateは39.95 tokens/sだった。
環境eval rate（生成速度）出典
M4/M5系（9Bクラス・公表値）25〜35 tokens/s外部記事の要約引用
M1 Max 64GB（今回・実測）39.95 tokens/s本記事の実測（1回のみ）
※M1 Max実測は1回のみの単発値。他環境での再現値・複数回の中央値ではない。
数字だけ見るとM1 Maxが上回っているが、プロンプト内容・文脈長・同時実行プロセスの有無が揃っていない単純比較であり、優劣を断定する材料にはならない。あくまで「4年落ちのM1 Maxでも同クラスの数字域には入っている」という参考値として書く。
まとめ — 再現できる学び
軽量なローカルLLMの速度を語るとき、eval rateという1つの数字だけを見ると体感を見誤る。**thinking系のモデルは、可視の回答とは別に大量の内部思考トークンを消費する。**今回のケースでは、131字の回答のために3936トークンを生成しており、体感の待ち時間の大半はユーザーが読むことのないテキストのために使われていた。
「日本語でGPT-4を超えるか」という問いに答えは出せなかった。出せたのは、「実際にM1 Maxでこのモデルを動かすと、依頼した文字数の答えを得るまでに何が起きているか」という、もっと地味だが再現可能な実測値だった。再現する場合はollama run <model> --verboseとollama show <model>の2つだけで、同じ切り口の比較を別モデル・別環境でもすぐに追試できる。