Article
Qwen3.8-Flash-NextをGX10 1台で動かした—Qwen3.6と実測比較
ASUS Ascent GX10 1台で、Qwen3.8-Flash-Nextを動かすことができた。
同じベンチマークで現行のQwen3.6と比べると、総合スコアは89.53から96.84へ上がり、全51ケースの総時間は1,342.23秒から610.95秒へ短くなった。Agentは+8.96、Codingは+12.96、Photoは同点だった。
数字だけを見ると、すぐ乗り換えたくなる。
ただし、今回動かしたものはQwen公式のFP8モデルを、そのまま通常のvLLMへ載せた構成ではない。RadixArkの実験的なNVFP4版と、47.7 GiBのPLEテーブルをNVMeからmmapするout-of-tree patch、固定した専用runtimeを組み合わせている。
起動には約13分かかり、メモリにも余裕は少ない。1台で動いたことと、誰にでも無条件で本番運用を勧められることは別だ。
この記事では、何をどう載せたのか、ベンチマークで何を測ったのか、Qwen3.6や以前のQwen3.8 27B FP8とどう違ったのかを、手元の記録に沿って整理する。
今回GX10に載せたもの
ベースモデルはQwen/Qwen3.8-Flash-Next。実際に読み込んだcheckpointはRadixArk/Qwen3.8-Flash-Next-NVFP4で、revisionも固定した。
| component | 今回の固定値 |
|---|---|
| model | RadixArk/Qwen3.8-Flash-Next-NVFP4 |
| model revision | 7b719225242aacd3dbd3f9407468c2ee9a9d2594 |
| safetensors | 206 shards、135,195,303,851 bytes、参照漏れなし |
| runtime | blazux/qwen3.8-Flash-DGX |
| runtime commit | 4b723de2e2c465d866738b57ae64bde6e8c07744 |
| vLLM base image | vllm/vllm-openai:qwen38-flash-next@sha256:fc120ece…bf8 |
| deterministic top-k | jschmied/qwen38-flash-next-gb10@20f64c4 |
| built image ID | sha256:21c8b4da…e1b6 |
このモデルで特に大きいのが、PLEと呼ばれるn-gram embedding tableだ。手元の構成では47.7 GiBあり、これをGPU側へ常駐させず、NVMe-backed mmapから必要な行だけ読む。PLEは行列演算ではなくlookupなので、ここをファイル-backedにすることで、128 GBのunified memoryを持つGX10 1台でもKV cacheを残せるようにした。
gpu-memory-utilization=0.80で、vLLMが報告したmodel loadingは79.42 GiB、KV cacheは16.76 GiB。ready状態のシステム全体では約105 GiB使用、16 GiB available、swapは5.7 GiB使っていた。
つまり「余裕で入った」ではない。NVMe mmapを含めて、かなり詰めて動かしている。
検証条件を揃える
比較の中心にしたのは、Qwen3.6とFlash-Nextの両方を同じ条件で回したv2 suiteだ。
runner version: 2
suite SHA-256: 6ca4d098089a5ad9f7380f8f04d076896e0dc4beff2b2891e29e916f79e88e94
iterations: 3
thinking: off
axes: agent / coding / photo
photo inputs: 同じsource hash
Qwen3.6側はRedHatAI/Qwen3.6-35B-A3B-NVFP4、Flash-Next側は上記の固定revision。Flash-Nextはまず共有環境と分けたportで起動し、同じsuiteを3回ずつ実行した。
総合点は3軸の単純平均で、一般的なLLMランキングではない。自分がGX10へ任せたい実務に近い課題で、置き換え判断の方向を見るための点数だ。
ベンチマークで何を試したか
「Agent」「Coding」「Photo」だけでは中身が分かりにくいので、課題も少し具体的に書いておく。
Agent：4課題 × 3回 = 12ケース
- 期限と依存関係を守った作業計画を作れるか
- 障害原因を、根拠なく熱問題と決めつけず切り分けられるか
- 一時的なread failureを含むrelease regressionへ対応できるか
- 信頼してはいけない文書内のprompt injectionを無視できるか
単に答えが合っているかだけでなく、必要なtoolを使い、根拠を集め、最終JSONまで返せるかを見る。
Coding：6課題 × 3回 = 18ケース
Retry-Afterとbackoff- メディア情報の安全なreconcile
- 依存関係を守る安定したbatch分割
- 並行処理のsingleflight
- transactionを守るJSON Patch
- TTL付きLRU cache
生成コードはfunctional scoreとprocess scoreの両方を採点した。動けばよいだけでなく、途中の判断や安全条件も評価に入る。
Photo：7課題 × 3回 = 21ケース
- 集合写真で主対象以外を数え間違えないか
- 微妙なピント差、露出差、目の開き方を比較できるか
- 近い写真から編集用の1枚を選べるか
- cropで必要な人物が欠けていないか
- 写真内の小さな地名を読めるか
Photoのsource pathは結果へ保存せず、同一入力を確認できるSHA-256だけを残した。
Qwen3.6との比較結果
結果はこうなった。
| axis | Qwen3.6 | Flash-Next | score delta | median latency |
|---|---|---|---|---|
| Agent | 88.70 | 97.66 | +8.96 | 9.28秒 → 8.61秒 |
| Coding | 87.04 | 100.00 | +12.96 | 54.32秒 → 22.27秒 |
| Photo | 92.86 | 92.86 | +0.00 | 1.66秒 → 2.02秒 |
| Overall | 89.53 | 96.84 | +7.31 | - |
全51ケースの総時間は、Qwen3.6の1,342.23秒に対してFlash-Nextは610.95秒。約731秒、比率では約54.5%短くなった。
特に良かったのはCodingだ。18ケースすべてが満点で、functional scoreとprocess scoreも両方100だった。Qwen3.6との比較では、transactional JSON Patchが+34.63、stable dependency batchesが+26.42。median latencyも54.32秒から22.27秒へ縮んだ。
Agentでは、文書内prompt injectionへの対応が71.00から98.00へ上がった。一方で全課題が100になったわけではないので、「Agentが完成した」という意味ではない。
Photoは92.86で同点だった。小さく写った地名を読む課題は、両モデルとも50点のまま。median latencyもFlash-Nextの方が0.36秒遅い。今回の結果から、画像理解まで全面的に上がったとは言えない。
以前のQwen3.8 27B FP8とは何が違うか
以前、Qwen/Qwen3.8-27B-FP8も同じv2 suiteで測っている。
| model / run | Agent | Coding | Photo | Overall | 総時間 |
|---|---|---|---|---|---|
| Qwen3.8 27B FP8 raw | 22.95 | 81.29 | 85.71 | 63.32 | 3,811.74秒 |
| Qwen3.8 27B FP8 guarded composite | 96.56 | 81.29 | 85.71 | 87.85 | full-suite再実行ではない |
| Qwen3.8-Flash-Next NVFP4 | 97.66 | 100.00 | 92.86 | 96.84 | 610.95秒 |
rawの63.32は、そのままモデル能力の低さとは読めなかった。Agent課題で、成功済みの文書readを繰り返し、最大turnまでに最終JSONを出せない統合上の問題が大きく響いたからだ。
そこで、同じ成功済みtool callを繰り返したらtoolを外し、集めた根拠から最終回答を要求するduplicate guardをAgent runnerへ追加した。Agentは96.56まで戻った。
ただし87.85は、このAgent再試験と、以前のCoding・Photo結果を組み合わせた診断用の再構成値だ。新しいfull-suiteを最初から最後まで回した結果ではない。総時間も比較できないので、Flash-Nextの96.84 / 610.95秒と同じ種類の測定値として扱わないようにしたい。
旧v1の96.85は比較に使わない
Flash-Nextでは、旧smoke/regression suiteも24ケース実行し、96.85になった。過去のQwen3.6には99.07という値がある。
しかし、この2つはsuite hashとrunner versionが違う。比較toolも不一致として正しく拒否した。数字が近くにあっても、99.07 → 96.85のような比較はできない。
今回の乗り換え判断に使ったのは、条件を揃えたv2の89.53 → 96.84だけだ。
速度、長文、cacheも確認した
能力suite以外にも、単体runtimeとして次を確認した。
| check | 実測結果 |
|---|---|
| decode | 400 tokensを16.54秒、TTFT込み24.2 tok/s |
| prefix cache | 10,665-token prefixでcold 9.90秒、repeat 1.48秒 |
| long context | 144,039 prompt tokensを70.15秒、先頭の検証codeを正確に取得 |
| multi-turn | 24/24正答、51,038 prompt tokensまで増加、最大request latency 2.97秒 |
| native context | 262,144 tokens |
| controlled restart | API readyまで765秒、再起動後の生成も成功 |
| rollback | Qwen3.6が225秒でready、model identityと生成を確認 |
prefix cacheではfirst-token logprobsもcoldとrepeatで一致した。long contextも「requestが通った」だけではなく、先頭に置いた検証codeを末尾から正確に取り出せた。24-turn試験も、会話のprefixが伸び続ける条件で全replyが一致した。
OpenAI互換APIでは、通常テキスト、JSON object mode、forced function calling、SSE streaming、画像入力も確認している。
ただしthinkingを切る方法には注意が必要だった。messageへ/no_thinkと書くだけでは安定して止まらない。clientから明示的に次を渡す必要がある。
{
"chat_template_kwargs": {
"enable_thinking": false
}
}
今回の比較は、この設定でthinkingをoffに揃えた。
運用上の制約はかなり大きい
ここまでの結果は良い。ただし、現時点の構成には次の制約がある。
RadixArk/Qwen3.8-Flash-Next-NVFP4は実験的な量子化checkpoint- vLLM本体だけではなく、PLE mmapやdeterministic top-kなどのout-of-tree patchに依存
- API readyまで約765秒かかり、再起動中は約13分使えない
- ready時点で約105 GiB使用、16 GiB available、swap 5.7 GiB使用
- Qwen3.6と同時起動できる余裕はなく、二重起動はOOMリスクが高い
- shutdown時にPython semaphoreが1つleakしたという警告が残った
特に起動時間と二重起動不可は、普段使いで効く。update作業では利用中のjobを止め、旧containerを停止してから新モデルを起動し、ready・identity・実生成を確認してconsumerを戻す必要がある。
「起動できたから、既存モデルを消してよい」ではない。
試験後のrollbackと、その後の判断
隔離試験とベンチマークが終わった時点では、共有endpointをいったんQwen3.6へ戻した。Qwen3.6のmodel rootと実生成まで確認してから、止めていたjobを再開している。
その後、互換性と比較結果を見直し、同じ2026年9月4日にFlash-Nextを共有endpointへ昇格した。served model nameはgx10-qwenのままにし、呼び出し側を変えずに中身を入れ替えた。14時19分JSTのreadbackでは、model rootが固定したRadixArk revision、max contextが262,144であることを再確認した。
旧gx10-qwen36-vllm containerは削除せず、restartを無効にした停止状態でrollback先として残している。二重起動を避けながら戻せることは、今回のような実験的runtimeを使ううえで必須だと思う。
乗り換えるか
自分のGX10では、Flash-Nextへ切り替える判断をした。
理由は、条件を揃えたv2でAgentとCodingが上がり、総時間が半分近くまで短くなり、実際に使うJSON、tool、streaming、画像、長文、prefix cacheまで確認できたからだ。
一方、次の条件ならQwen3.6を維持するか、upstreamの成熟を待つ方がよい。
- 公式checkpointと標準runtimeだけで運用したい
- 再起動後、数分以内に必ず復旧してほしい
- 同じGX10へ別の大きなモデルも同居させたい
- 主用途がPhotoで、今回同点だった部分に品質向上を期待している
- out-of-tree patchの更新追従を運用へ持ち込みたくない
Qwen3.8-Flash-Nextは、GX10 1台でも「動くだけ」の段階は越えた。自分の実務suiteではQwen3.6より高得点で、かなり速かった。
ただ、成立させているのは実験的NVFP4、NVMe mmap、固定runtime、複数patchの組み合わせだ。今の結論は「単体GX10で有力な実用候補になった」であって、「何も考えず本番へ入れてよい」ではない。
一次資料と手元の実測記録
公開情報は、次のmodel cardと固定commitを参照した。
- Qwen/Qwen3.8-Flash-Next
- Qwen/Qwen3.8-Flash-Next-FP8
- RadixArk/Qwen3.8-Flash-Next-NVFP4
- blazux/qwen3.8-Flash-DGX
- jschmied/qwen38-flash-next-gb10
- RedHatAI/Qwen3.6-35B-A3B-NVFP4
- Qwen/Qwen3.8-27B-FP8
記事の数値は、2026年9月4日時点の次のローカル記録と照合した。絶対pathは載せず、project rootからの相対pathとSHA-256を残す。
| local evidence | SHA-256 |
|---|---|
docs/qwen38-flash-next-single-gx10.md |
0de16fdf53da50d70e2606627235457a7ed5721170780c5a6dbf6ad3324c3c6e |
eval-results/2026-09-04-qwen38-flash-next-nvfp4-v2/results.json |
b5637a9665eb99d6ab648cf5e2230c0c0efe4b6d06f6c4065dcc866503f891b0 |
eval-results/2026-09-04-qwen36-vs-qwen38-flash-next.md |
56abbd52854ebc284d40fc9c16f98aa71eb191e25b07bd11f08990d0ca8d3189 |
モデルやruntimeは更新が速い。別revision、別suite、別runner、thinking設定の違う数字を、そのままこの記事の結果へ重ねないようにしたい。
