【検証】Tesla V100 32GBでQwen3.8-27Bは動くか？128kコンテキストが1枚に載った実測ベンチマーク

こんにちは、七宮さん(@shichinomiya_s)です。

2026年8月14日に Qwen3.8-27B が Apache 2.0 で公開されました。27Bのdenseモデルでありながらvisionエンコーダを内蔵し、ネイティブ262,144トークン（最大100万トークンまで拡張可）という、いま「1枚のGPUで動かせる中で最も強いモデル」候補です。

これを NVIDIA Tesla V100 32GB で動かしました。2017年のVolta世代、compute capability は sm_70。bfloat16もFP8もハードウェアで持たず、FlashAttention 2も動きません。2026年の推論スタックが次々と切り捨てているアーキテクチャです。

結論から言うと、動きました。しかも131,072トークンのコンテキストが1枚に載りました。ただし記事を書くために回した実測の中で、「V100で使ってはいけない設定」と「これを知らないと実用にならない設定」がはっきり出たので、そこまで含めて全部出します。

数値はすべて自分で回した実測ログ由来です。うまくいかなかったところも、そのまま書きます。

まず結論 — 実測サマリー

一番大事な一行：--reasoning-budget 1024 を付けてください。付けないと同じ問題に134秒かけて答えを出しません。付けると39秒で正解します。

検証環境

mmprojはBF16版ではなくF16版を選びます。VoltaはBF16をハードウェアで持たないためです。この後も何度も出てきますが、V100の話は「bf16が無い」から始まって「bf16が無い」に帰ってきます。

いきなり詰まった話 — CUDA 13 は Volta を切った

本題の前に。今回いちばん最初に手が止まったのがここでした。

2026年現在、GPUを選ぶ画面の既定フィルタは compute_cap>=800（Ampere以降）かつ cuda_max_good>=13 になっていることが多く、この条件だとV100は候補として1件も出てきません。CUDA 13がVoltaのサポートを打ち切ったことが、そのまま「選択肢の一覧から消える」という形で表に出ています。

compute_cap=700 に落とし、コンテナイメージもCUDA 12系のdevelに変えて、ようやく候補が出ました。V100を使うなら CUDA 12.x + sm_70 明示ビルドが事実上の前提です。llama.cppのビルドは24スレッドで約16分かかりました。

cmake -S llama.cpp -B llama.cpp/build \
  -DCMAKE_BUILD_TYPE=Release -DGGML_CUDA=ON \
  -DCMAKE_CUDA_ARCHITECTURES=70 -DLLAMA_CURL=ON
cmake --build llama.cpp/build -j$(nproc) \
  --target llama-bench llama-cli llama-mtmd-cli

検証結果① まず動くのか — sm_70でハイブリッドアテンションは通るか

Qwen3.8-27Bは64層のうち48層がGatedDeltaNetの線形アテンション、16層だけが通常のfull attentionというハイブリッド構成です。線形アテンション層は従来型のKVキャッシュを持ちません。

これが今回いちばん不安だった点でした。CUDAカーネルとしては比較的新しい部類で、2017年のVoltaで動く保証はどこにもありません。動かなければ「V100に2026年のモデルは載らなかった」という記事になるところでした。

結果は一発で通りました。

> 日本語で「動作確認OK」とだけ出力してください。

[Start thinking]
The user is asking me to output only "動作確認OK" in Japanese.
This is a simple request - just output that exact text.
[End thinking]

動作確認OK

[ Prompt: 119.4 t/s | Generation: 31.8 t/s ]

このときのピークVRAMは16,626 MiB、ピーク電力205.7W、ピーク温度41℃。32GBに対して半分しか使っていません。27Bをこの余裕で載せられるなら、残りをコンテキストに回せるはずです。

検証結果② コンテキスト長 — 131,072トークンが1枚に載る

32,768トークンを積んだ状態でも生成が27.95 tok/s。深度0比で -16% しか落ちていません。VRAMも19GB弱です。

そして131,072トークン。25,264 MiB で通りました。7GB以上余っています。64層中48層がKVキャッシュを持たない構成なので、コンテキストを伸ばしてもVRAMがほとんど増えないわけです。生成速度は15.84 tok/sまで落ちますが、10万トークン超の資料を丸ごと読ませて回答させる用途なら十分実用圏です。

実際に約20,000トークンの日本語文書に1文だけ紛れ込ませた情報を答えさせるテスト（いわゆるneedle-in-a-haystack）では、シリアル番号と日付の両方を正確に抜き出しました。prefillは708.5 tok/s、生成29.2 tok/sでした。

質問: 第7倉庫の予備電源装置のシリアル番号と、次回点検日をそれぞれ答えてください。

- シリアル番号: V100-KX-4827
- 次回点検日: 2027年3月14日

検証結果③ 量子化 — Q6_Kまで載る。128kと両立すると残り436MiB

面白いのはprefillが量子化を上げてもまったく落ちない（むしろ微増する）点です。prefillは演算律速なので、モデルが重くなっても速度に効きません。一方で生成はメモリ帯域律速なので、Q4→Q6で -25% ときれいに落ちます。V100のHBM2帯域がそのまま出ている形です。

そしてVRAM。Q6_K_XL で 131,072トークンも通りました。ただしピーク 32,332 MiB / 32,768 MiB。空きは 436 MiB しかありません。

これは「載る」と書いていい数字ですが、実運用で狙う設定ではありません。V100は映像出力を持たないので画面には使われませんが、他のプロセスがVRAMを少しでも掴んでいれば落ちます。日常的に使うなら Q4_K_XL + 128k（25.3GB）か、Q6_K_XL + 64k（28.2GB）が現実的な線です。

検証結果④ sm_70の壁 — KVキャッシュ量子化は使ってはいけない

ここが今回いちばん「V100らしい」結果でした。

-ctk q8_0 -ctv q8_0 でKVキャッシュを8bit量子化して回したところ、こうなりました。

sm_70にq8_0 KVのCUDAカーネルが無く、エラーを出さずにCPUへフォールバックしていました。GPUが遊んでいるのに終わらない、という一番たちの悪い壊れ方です。10分待って打ち切りました。

救いは、線形アテンションのおかげでそもそもKVキャッシュが小さいこと。V100ではKV量子化を使わないと決めても、実害はほとんどありません。

ついでに -fa（FlashAttention）フラグも見ておきました。

差は誤差範囲です。VoltaはFA2に対応していないので当然ですが、指定してもエラーにならず素通りするので「効いているつもり」になりがちです。付けても付けなくても同じ、と覚えておけば十分です。

検証結果⑤ 最大の実用問題 — thinkingが終わらない

ここからが、V100でQwen3.8を使うなら絶対に読んでほしいところです。

Qwen3.8はthinkingがデフォルトで有効です。llama.cppは --reasoning-effort を一級のフラグとして持っています。ところが。

まず none は使えません。チャットテンプレートが例外を投げます。

Error: Jinja Exception: Unexpected reasoning effort none.
Supported types are xhigh (default), medium, and low.

そして残る3段階を、ある論理パズル（答えは6時間42分13秒。手計算で検算済み）で試したところ、こうなりました。

3段階すべてで、4,096トークンの上限まで考え続けて答えに到達しませんでした。しかも low にしても時間が短くなっていません。effortを下げれば速くなる、という期待は裏切られます。

日本語要約でも同じことが起きました。「300字程度に要約してください」と頼んだところ、モデルは文字数を数える作業に思考枠を使い切り、要約本体を一度も出力しないまま終了しました。出力の末尾はこうです。

Total: 15+9+21+28+25+28+27+25+38+14+28 = 258

Hmm, that's about 258. I need to get closer to 300. Let me expand a bit.

Actually, I realize I'm overcomp

生成速度は32 tok/s出ています。速度は問題ないのに、思考トークンの浪費がそのまま体感待ち時間になる。これが33 tok/sのハードで27Bを動かすときの、本当のボトルネックです。

解決策 — --reasoning-budget 1024 を付ける

そこで --reasoning-budget で思考トークンに上限をかけ、同じ問題を回し直しました。

1024が最適点です。39秒で、無制限と同じ正解に到達します。無制限は134秒かけて答えを出さないので、実質3.4倍以上の改善であり、しかも無制限では得られなかった答えが得られます。

一方で256や512まで絞ると15〜23秒と速いものの、答えを間違えます。速度と正答率のトレードオフは実在していて、この問題では1024が境界でした。

なお --reasoning-budget 0 はドキュメント上「即座に思考終了」ですが、実際には無制限と同じ挙動になりました（134秒・思考が閉じない）。0は使わないほうがよさそうです。

また意外だったのが -rea off で思考自体を切っても78秒かかり、budget 1024（39秒）より遅い点。思考を切ると本文が長くなるためで、「思考オフ＝速い」ではありませんでした。

検証結果⑥ vision — mmprojはsm_70でも動く

Qwen3.8-27Bはvisionエンコーダを内蔵しており、UnslothのGGUFにも mmproj-F16.gguf（0.93GB）が同梱されています。

800×600の写真を llama-mtmd-cli に渡したところ、正常に処理されました。出力の一部です。

背景には、大きくぼかされた木々（樹木）が見えます。これは「ボケ」と呼ばれる写真の技法で、前景の草を際立たせるために使われています。（中略）低い視点（地面レベル）から撮影されており、観覧者は草の真上にいるかのように感じさせます。この視点により、普段見慣れた草が、まるで高層ビルや森のような存在感を持つように描かれています。

前景・背景・ボケ・光・構図まで、かなり細かく読んでいます。sm_70でもvisionは問題なく動くと言っていいです。

ただし1点。出力の末尾に中国語が混ざりました。「总而言之」「宏大的」、さらに「少しハazy（霞んだ）雰囲気」という壊れ方もしています。Q4_K_XL量子化での言語ドリフトと思われます。日本語で使うなら、量子化を上げるか出力チェックを挟むかの判断が要ります。

検証結果⑦ 品質 — 通ればちゃんと強い

コード生成は「llama-benchのMarkdown出力をパースして辞書のリストを返す関数」を書かせました。生成されたコードを、実際にこの記事で使ったベンチ結果に対して走らせて動作確認しています。

from __future__ import annotations
import re

def parse_llama_bench(md: str) -> list[dict[str, object]]:
    keys = ("model", "size", "params", "backend", "ngl", "test", "t_s")
    rows: list[dict[str, object]] = []
    for line in md.splitlines():
        line = line.strip()
        if not line.startswith("|") or re.fullmatch(r"\|[\s\-:|]+\|", line):
            continue
        cells = [c.strip() for c in line.strip("|").split("|")]
        if len(cells) < 7 or cells[0].lower() == "model":
            continue
        t_s = float(re.split(r"\s*±", cells[6])[0])
        rows.append(dict(zip(keys, (*cells[:6], t_s))))
    return rows

ヘッダ行と区切り行を無視、±以降の標準偏差を捨てる、t_sはfloat、表が無ければ空リスト — 指定した仕様を全部満たしたうえで、6行を正しく抽出しました。一発で動くコードです。

要約タスクの失敗については補足があります。同じタスクを Qwen3.6-27B（Q4_K_M）にも投げてみたところ、まったく同じ壊れ方をしました（Total: 366. Still over. Let's trim more aggressively. と数え続けて終了）。これはQwen3.8固有の欠陥ではなく、このモデル系列に日本語で文字数を指定したときの弱点です。文字数指定は避けて「短く」「3〜4文で」のように頼むほうが安全です。

消費電力と温度

最高269.2W / 65℃。PCIe版のTDPは250Wなので瞬間的には超えますが、温度は65℃止まりでサーマルスロットリングの気配はありませんでした。ロード時間も6.85 / 6.87 / 6.89秒とばらつき0.6%で、非常に安定しています。

V100でQwen3.8-27Bを動かすときの設定まとめ

実測から導いた、そのまま使える設定です。

# ビルド（sm_70 を明示。CUDA 12.x 必須）
cmake -S llama.cpp -B build -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=70 -DLLAMA_CURL=ON
cmake --build build -j$(nproc)

# 日常使い（Q4_K_XL・32k・thinking を1024で打ち切る）
./build/bin/llama-cli \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 99 -c 32768 \
  --reasoning-budget 1024 \
  --temp 1.0 --top-p 0.95 --top-k 20

# 長文を丸ごと読ませる（128k）
./build/bin/llama-cli \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 99 -c 131072 \
  --reasoning-budget 1024

# 画像を読ませる（mmproj は F16 を選ぶ）
./build/bin/llama-mtmd-cli \
  -m Qwen3.8-27B-UD-Q4_K_XL.gguf --mmproj mmproj-F16.gguf \
  -ngl 99 -c 16384 --image photo.jpg -p "この画像を説明してください。"

やってはいけない設定も明確です。

• -ctk q8_0 -ctv q8_0（KV量子化） — CPUフォールバックで実質停止する
• --reasoning-effort none — チャットテンプレートが例外を投げる
• --reasoning-budget 0 — 無制限と同じ挙動になる
• mmproj-BF16.gguf — VoltaはBF16非対応。F16版を使う
• CUDA 13系のイメージ — Voltaが切られている

向いている人・注意点

向いている

• 10万トークン級の資料を丸ごと読ませたい人。128kが1枚に載って15.84 tok/sは、この用途では十分実用的です
• 32GBのVRAMを安く確保したい人。27Bクラスをprefill 800 tok/s超で回せます
• 手を動かして自前ビルドできる人。プリビルドのバイナリや最新のコンテナはVoltaを切っています

注意点

• bf16もFP8もFA2も無く、周辺エコシステムから外れていく一方です。vLLMやTensorRT-LLMを使いたいなら候補になりません
• KV量子化のような「動くけどCPUに落ちる」壊れ方をします。GPU利用率を必ず見てください
• 映像出力がありません。別途表示用のGPUが要ります
• thinkingの制御を知らないまま使うと「遅いモデル」という誤った印象になります

まとめ

2017年のTesla V100で、2026年のQwen3.8-27Bは動きます。

• Q4_K_XLで 33.41 tok/s、32kでも27.95 tok/s
• 131,072トークンが25,264 MiBで載る。Q6_Kでも載るが残り436 MiBで余裕はゼロ
• visionも動く。ただしQ4では中国語の混入が起きる
• KV量子化はCPUに落ちるので使わない
• --reasoning-budget 1024 が実用性を決める。39秒で正解、無制限は134秒で答えなし

「sm_70はもう終わり」という話は半分本当で、推論スタックの選択肢は確かに狭まっています。ただllama.cppとGGUFという一本道が残っている限り、32GBのHBM2はまだ十分に戦えます。特に長コンテキストでは、線形アテンション系のモデルとV100の32GBの組み合わせは想像以上に相性が良い、というのが今回いちばんの収穫でした。

検証ノート（再現用）

本文の数値はすべて以下のコマンドの出力から取っています。

# モデル取得（ファイル名は正確に指定する。--include はワイルドカードを取りこぼす）
hf download unsloth/Qwen3.8-27B-GGUF \
  Qwen3.8-27B-UD-Q4_K_XL.gguf mmproj-F16.gguf --local-dir models

# 深度スイープ
llama-bench -m models/Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 99 \
  -p 512 -n 128 -d 0,4096,32768 -r 3 -o md

# 128k（1回計測）
llama-bench -m models/Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 99 \
  -p 512 -n 128 -d 131072 -r 1 -o md

# FlashAttention フラグの効き
llama-bench -m models/Qwen3.8-27B-UD-Q4_K_XL.gguf -ngl 99 \
  -p 512 -n 128 -fa 0,1 -r 3 -o md

# VRAM・電力・温度は1秒粒度でログしてピークを取る
nvidia-smi --query-gpu=timestamp,memory.used,power.draw,temperature.gpu \
  --format=csv,noheader,nounits -l 1 > gpu.csv

計測はすべて同一マシン・同一ビルドで実施し、llama-bench は3回計測（深度131,072のみ1回）、VRAM・電力・温度は1秒粒度ログのピーク値を採用しています。llama.cppは d230ddd と f9f09f0（どちらも2026-09-03）を使用しました。

それでは、また。