株式会社バンコム

125BのQwen3.8-Flash-Nextを2bitに落としてRTX 3060で動かす：VRAM 12GB・メモリ32GB・SSDで毎秒16トークン

125BをRTX 3060で。Qwen3.8-Flash-Next 2bit、VRAM 12GB＋SSDで毎秒16トークン。花ロボが光るブロックを1つずつPCに運び、横に積まれたブロックの山と速度メーターを花イヌが見ているイラスト
Information

この記事は、AIが行った検証の記録をもとにAIが執筆し、人間が確認しています。

社内の検証マシン「DQN」（GeForce RTX 3060 12GB、メモリ32GB）で、Qwenの大型モデル「Qwen3.8-Flash-Next」を動かしてみました。パラメータ数は125B（1,250億）で、ふつうに考えればVRAM 12GBのPCで動かす大きさではありません。2bit相当（Q2_0）まで量子化し、そのうえで必要な部分だけをSSDから読み込む「Strata」というエンジンを使って、無理やり載せています。

文章を書く速さ（生成）は毎秒約16.7トークン（中央値）、長いプロンプトを読み込む速さは毎秒約200トークンでした。短い質問なら2秒ほどで答え始めます。ただ、2万トークン級のプロンプトだと読み込むだけで1分半から2分かかります。コーディングエージェント（pi、OpenCode）にツールを使わせる簡単なテストは、どちらも通りました。

構築日：2026年10月11日（日本時間）。速度は、同日から10月12日までにDQNが処理した51件のリクエストの記録から集計しました。公式情報の確認日は2026年10月13日です。

Qwen3.8-Flash-Nextとは

Qwen3.8-Flash-Nextは、Qwenチームが次の世代（Qwen4）に向けた構造の試作として公開した、オープンウェイトのモデルです。出典：公式モデルカード。

項目公式モデルカードの情報
規模125B。1トークンの計算で動くのはそのうち6B。ほかにn-gram埋め込み51B、MTP（先読み用の層）4B
構造MoE（Mixture of Experts）。48層、各層に512個のエキスパートがあり、1トークンごとに10個（＋共有の1個）だけを使う
注意機構Gated DeltaNetとQwen Sparse Attention（QSA）の組み合わせ
コンテキスト長262,144トークン（最大100万トークンまで拡張可）
入力文章と画像（今回は文章だけを試した）
ライセンス表記qwen-community-1.0

元の精度（BF16）のままだと、ファイルは354GBあります。

2bit版（GSQ-RCO Q2_0）

使ったのは、オーストリア科学技術研究所の研究室（ISTA DASLab）が公開している量子化版です。GSQとRCOという手法で、重みのテンソルごとに精度を割り振っています。大きさは4種類あり、いちばん小さいQ2_0は平均2.40bit、ファイルは合計66.4GBです。

版平均bit合計サイズAIME25GPQA-DiamondLiveCodeBench v63つの平均
BF16（元の精度）16354GB100.0091.9287.4393.12
IQ3_S3.5083.6GB100.0092.9386.8693.26
IQ3_XXS3.0075.8GB100.0091.4186.2992.57
Q2_0（今回）2.4066.4GB96.6789.3981.1489.07

上の値はISTAのモデルカードの報告で、本稿では再現していません。Q2_0は3bit版より平均で3.5ポイントほど低いかわりに、読み込みと生成が速くなる形式だと説明されています。

ファイルは2つに分かれていて、2つ目（28.8GB）はn-gram埋め込みの表です。1トークンにつき1行しか読まないので、SSDに置いたままでよいとされています。

実際に入れたのは「abliterated」版

手本にした構築手順（後述）がこの版を使っていたため、DQNに入れたのは、ISTAの量子化版をもとにしたSC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUFのQ2_0です。これは、依頼を断る働きを取り除いた（abliterated）版です。モデルカード自身も「組み込みの安全策がほぼ働かないので、利用者の前に出すなら自前の安全対策を用意すること」と注意しています。

DQNでは、社内VPNの中からだけ使える形にしています。手本の説明によると、同じ手順はISTAの通常版でもそのまま使えます。ふつうの用途なら、通常版を選ぶほうが無難です。

検証環境

項目DQN
GPUGeForce RTX 3060（VRAM 12GB）、ドライバー 580.178.04
CPUCore i5-12400（6コア12スレッド。AVX-512なし）
メモリ32GB（OSから見て30GiB）＋スワップ7GiB
SSDNVMe 1TB（Phison E27T、DRAMなし）
OS・CUDAUbuntu 24.04.4 LTS、CUDA 12.9
エンジンStrata（bodhi37/strataのorca-portブランチ、コミット b90510c）
モデルSC117 abliterated Q2_0（リビジョン eec4e10）＋MTP用ファイル mtp-q2_0.gguf

手本の構成は、Ryzen 9 9900X、RTX 4070 SUPER 12GB、メモリ30GiB（＋zram 30GiB）です。Q2_0の生成速度は、短い文脈で毎秒39〜44トークンと報告されています。DQNはGPUが1世代前で、CPUのコア数も半分、メモリに置ける量も少なめです。

なぜVRAM 12GBで動くのか

Q2_0でも、エキスパートの部分だけで31.6GiBあります。VRAM 12GBにはもちろん、ほかのサービスも動くメモリ32GBにも収まりません。Strataは、MoEが1トークンで使うエキスパートが少ないことを利用して、次のように置き場所を分けています。

以前の記事「12GB VRAM で Qwen3.6-35B-A3B を高速に動かす」では、モデル全体をVRAMとメモリに収めていました。今回は、メモリにも入りきらない分をSSDから読むところが違います。

セットアップの手順

手本にしたのは、bodhi37さんが公開している構築手順「Qwen3.8-Flash-12GBRAM-32GBVRAM-SSD-Recipe」です。DQNでは次の順に進めました。モデルのダウンロード開始からAPIが最初に答えるまで、約16分でした。

1. モデルをダウンロードする

from huggingface_hub import snapshot_download
snapshot_download(
    repo_id="SC117/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-GGUF",
    revision="eec4e10a2c29b440a2ae85591fa11569ce752963",
    allow_patterns=["Q2_0/*", "mtp-q2_0.gguf"],
    local_dir="/home/kiyo/models/qwen38-sc117",
    max_workers=2)

Q2_0の2ファイル（38.0GB＋28.8GB）とMTP用のファイル（0.89GB）で、約10分かかりました。

2. Strataをビルドする

手本はCUDA 13.3とRTX 4070 SUPER（sm_89）向けです。DQNでは、入っているCUDA 12.9と、RTX 3060のsm_86に変えてビルドしました。Strataが使うggmlは、llama.cppの決まったコミット（3cf0325）のソースを third_party/llama.cpp に展開しています。

cmake -G Ninja -S . -B build-dqn -DCMAKE_BUILD_TYPE=Release \
  -DSTRATA_ENABLE_CUDA=ON -DSTRATA_BUILD_TESTS=OFF -DSTRATA_WERROR=OFF \
  -DCMAKE_CUDA_ARCHITECTURES=86 \
  -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.9/bin/nvcc \
  -DSTRATA_GGML_DIR=$PWD/third_party/llama.cpp \
  -DSTRATA_NATIVE_EXPERTS=ON
cmake --build build-dqn --target strata -j 4

3. Strata用にファイルを詰め直す

StrataはエキスパートをGGUFから直接読まないので、1回だけ専用の形式に変換します。

Q2=/home/kiyo/models/qwen38-sc117
.venv/bin/python tools/iq_pack.py \
  --gguf $Q2/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-abliterated-Q2_0-00001-of-00002.gguf \
  --out  $Q2/pack-q2
.venv/bin/python tools/make_native_head.py \
  --arch-shard   $Q2/Q2_0/...-00001-of-00002.gguf \
  --tensor-shard $Q2/Q2_0/...-00001-of-00002.gguf \
  --out $Q2/head-q2.gguf
.venv/bin/python tools/mtp_rt.py --gguf $Q2/mtp-q2_0.gguf --out $Q2/mtp-runtime
.venv/bin/python tools/make_profile_from_counts.py \
  data/counts-sc117-r1.strc dqn/profile-sc117-r1.bin --blob-bytes 1382400

ここでエキスパート以外の重み（1.5GB）と、エキスパートの目録ができます。エキスパート本体のファイル（34GB）は、初めて起動したときに組み立てられます。手本が使っている新しいプロファイル（r2）は、指定のコミットに入っていませんでした。そこで、同梱されている利用回数の記録（r1）からDQN用のプロファイルを作りました。r1の記録では、使われた回数の多い2,000個（2.6GB）で全体の利用の54%、8,000個（10.3GB）で94%をまかなえます。

4. 設定をDQNに合わせて縮める

設定手本（Q2_0）DQN
--hot-ram-gib（メモリに置くエキスパート）21.08.0
--expert-cache（VRAMに置くエキスパートの数）30003000
--pool-workers（CPUの作業スレッド）126
--prefill（読み込みの区切り）163841024
--spec（先読みの最大数）64
--max-context13107232768（最初は8192）
--prompt-cache（保存する会話の数）61

メモリに置く量を8GiBまで減らしたのは、DQNのメモリが32GBで、ほかのサービスも動いているからです。CPUの作業スレッドは、コア数に合わせて6にしました。

StrataにはOpenAI互換のAPIサーバーが付いています。これをsystemdのサービスにして、それまでDQNで動かしていたローカルLLM（ik_llama.cpp）と入れ替えました。2つを同時に動かすとVRAMが足りないので、サービスの設定に Conflicts=ik-llama.service を書いて同時に起動しないようにしています。メモリも MemoryHigh=18G、MemoryMax=20G で上限を決めました。

結果

起動とメモリ

初めての起動では、GGUFからエキスパートのファイル（31.64GiB）を組み立てるため、APIが使えるようになるまで約4分かかりました。2回目からはできたファイルをそのまま使うので、約20秒で立ち上がります。起動後のVRAMの使用量は約9.9GB（空き約2.9GB）、メモリは約17〜18GBでした。

速さ

場面結果
短い日本語の質問（入力35トークン、出力28トークン）答え始めまで1.96秒、全体で3.7秒
Pythonのコードを書かせる（入力56トークン、出力357トークン）全体で22.8秒、生成は毎秒17.3トークン
生成の速さ（出力50トークン以上の45件）中央値 毎秒16.7トークン（最小14.1、最大20.3）
長いプロンプトの読み込み（1,000〜27,000トークン）毎秒約120〜210トークン。27,180トークンで約2分15秒
同じ会話の続き前の内容を覚えていれば、新しく足した部分だけを読む

生成の速さは、手本の報告（毎秒39〜44トークン）の半分以下です。ログを見ると、使ったエキスパートの13〜22%ほどが、メモリにもVRAMにもなくSSDから読まれていました。コードを書かせた357トークンの例では、SSDから43.1GB（毎秒約2.1GB）を読んでいて、1トークンあたり約120MBになります。メモリに置ける量（8GiB）が手本（21GiB）よりかなり少ないことが効いていると考えられますが、設定を変えての比較はしていません。

先読み（MTP）は効いていて、コードの例では1回の計算で平均2.2トークン進みました。

回答の中身

「あなたは何ができますか？箇条書きで3つ挙げてください」と聞いた答えは、次のとおりです。

- 質問への回答や情報整理
- 文章の作成、翻訳、要約
- 論理的思考や計算

リストから重複を取り除く関数を書かせると、元の順序を保ったまま重複を除く正しいコードと、計算量の説明を返しました。ただ、説明文に「長数」（正しくは「長さ」）、「保われる」（正しくは「保たれる」）という日本語の誤りが2か所ありました。2bitにした影響かどうかは、ほかの版と比べていないのでわかりません。

コーディングエージェントから使う

piとOpenCodeに「probe.txt を読んで、中に書いてある値だけを答えて」と頼みました。どちらもファイルを読むツールを使い、正しい値を返しました。

OpenCodeは最初に渡す指示文が約1万トークンあり、最初の応答まで約85秒かかりました（うち読み込みが約75秒）。2回目は前の内容を覚えていたので、約5秒で返っています。piは指示文が約1,700トークンと短く、待ち時間は少なめでした。

つまずいた点

この検証でわかること・わからないこと

まとめ

125Bのモデルでも、MoEで1トークンに使う部分が小さければ、VRAM 12GB・メモリ32GBのPCで「動く」ところまでは持っていけました。毎秒16トークン前後なら、チャットとしては十分に読める速さです。

一方で、長いプロンプトの読み込みは毎秒200トークンほどです。大きなファイルを何度も読ませるエージェントの用途では、待ち時間が長くなります。同じDQNで動かしていたOrnith 1.5（35B、生成は毎秒約57トークン）と比べると、速さは3分の1以下です。大きなモデルの賢さを取るか、小さなモデルの速さを取るかで、使い分けることになりそうです。

参照資料

Qwen3.8-Flash-Next 公式モデルカード ／ ISTA DASLab GSQ-RCO GGUF ／ SC117 abliterated GGUF ／ 構築手順（bodhi37） ／ Strata（bodhi37のフォーク） ／ GSQの論文 ／ RCOの論文。情報は2026年10月13日に確認。