Qwen3.8-Flash-Nextのローカル実行で最初に見るべき数字は、GPU名ではなく推論中に本当に空いている総メモリです。Unslothは最小1-bit quantの下限を75GBとし、96GB RAMまたはユニファイドメモリの端末を推奨しています。4-bitの必要量は約112GBなので、128GB Macでも「余裕で262K context」ではなく、Q3/Q4を現実的に試せる出発点です。
「1 tokenあたり6B parametersをactivateする」という説明も、6Bモデルという意味ではありません。Qwen公式model cardでは、main modelが125B、N-gram embeddingが51B、MTPが4Bです。計算時に選ばれるmain-model parameterが6Bでも、必要なweight自体は保存・配置しなければなりません。
96GBと128GBでできることは違う
Apple Siliconではmodel、macOS、アプリ、KV cacheが同じunified memoryを共有します。128GB表記でも、ブラウザ、IDE、Docker、build processが30GBを使えば、推論用は98GBです。GPUマシンでもVRAMだけでなくsystem RAMとoffloadの速度を合わせて判断します。
Unslothの現行quant analysisは次のサイズを示しています。
| quant | 公開サイズ | 判断 |
|---|---|---|
UD-IQ1_S | 72.5GB | 最小route。fit最優先で品質リスクが大きい |
UD-IQ1_M | 74.5GB | 96GB級で試せる1-bit候補 |
UD-Q2_K_XL | 78.9GB | 低メモリ実験の現実的な候補 |
UD-IQ3_XXS | 82GB | 96GB級でも短いcontextから始める |
UD-Q3_K_XL | 90GB | 128GB級の方が安全なheadroomを取りやすい |
UD-IQ4_XS | 93.7GB | 小さめの4-bit系だがKV cacheは別 |
UD-Q4_K_XL | 111.3GB | 128GBでも他processとcontextを厳しく管理する |
Unslothのguideでは、1/2/3/4-bitの総メモリ目安を75/79/90/112GB、5-bitを200GB、8-bitを270GB、BF16を355GBとしています。これはpublisherのrouting guidanceです。OS、runtime buffer、KV cache、vision projectorを正確に予約するcalculatorではありません。
したがって、64GB以下はfull Flash-Next GGUFを前提にしない方がよく、96GBは1–3-bit・text-only・短いcontextでの検証向けです。128GBならQ3と一部Q4が候補になります。192/256GB以上でも、長いcontextが無料になるわけではありません。
24–48GB級でlocal coding agentを使うことが目的なら、別modelであるQwen3.8-27Bのローカルagentic codingガイドの方がhardwareに合います。
同じように見える3つの名前
Qwen/Qwen3.8-Flash-Nextはopen-weightのmultimodal MoEで、Qwen4 architectureのearly previewです。Gated DeltaNetとQwen Sparse Attentionを組み合わせ、N-gram embeddingでcapacityを増やしています。
Qwen3.8-FlashはQwenのmanaged serviceです。公式説明ではdefault 1M contextやbuilt-in toolsなどのproduction featureがありますが、local GGUFに自動で付く機能ではありません。
Qwen3.8-27Bは27B dense modelです。Flash-Nextの軽量quantではありません。memory estimate、runtime flag、benchmarkを混ぜないでください。
Qwenが公開したcoding、agent、tool-use scoreは試す理由になりますが、vendor指定harnessの結果です。Unsloth 1-bit quantのtool argumentsが自分のruntimeで保たれるか、128GB Macのfirst-token latencyが許容範囲かは別に測定します。
shard名を推測せずaliasで起動する
新architectureに対応した最新llama.cppを使います。Unsloth GGUF repositoryのquant aliasを利用すれば、手動で4分割file名を組み立てる必要がありません。
bashllama serve -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL
96GB machineでQ4をそのまま選ばないでください。公開memory budgetに収まる低bit aliasへ置き換えます。Unsloth側の入口は次です。
bashunsloth run --model unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL
現時点のUnsloth manual download例には、local directoryのGGFF表記と、その後のUD-IQ1_S directory / UD-Q4_K_XL filenameの不一致があります。修正される可能性は高いものの、手動downloadでは実際に保存されたdirectoryと最初のshardを確認してからpathを渡すべきです。
contextは8Kまたは16Kから開始します。公式のnative 262,144 tokens、最大1,000,000 tokensはcapabilityであり、local defaultではありません。段階的に増やし、prompt processing、KV cache、swapの変化を同じ入力で比べます。
初回起動の合格条件
画面に文字が出るだけでは不十分です。
/v1/modelsでserverが返すmodel IDを確認する。- 短いtext requestでFlash-Nextと選択したquantがロードされていることを確認する。
- load後の空きmemory、time to first token、連続generation、swapを記録する。
- 8K、16K、それ以上で同じtaskを実行し、context増加のcostを見る。
- agent用途なら、単純なtool schemaでname、typed arguments、tool result、次turnまで確認する。
その後、正解を判断できる5–10個のrepository taskを複数quantに与えます。完了数、手修正、tool failure、wall-clock timeを比較してください。UnslothのKLDやtop-1 recoveryはquant選択の参考にはなりますが、あなたのtask acceptance rateではありません。
OOM、継続的swap、長いprompt後の壊れたtool JSON、許容できない初回待ち時間はNo-Goです。contextを下げ、quantを変え、それでも駄目なら小型modelへ移ります。「ロードできた」を成功条件にすると、調整時間だけが増えます。
Flash-Nextを選ぶ条件
96GB以上の実メモリがあり、低bit quantの品質リスクを受け入れ、large-capacity sparse modelをagentic/long-context taskで試したいなら価値があります。Q3/Q4の比較には、他アプリを閉じて使える128GB級がより適しています。
一方、64GBが上限、常駐assistantが目的、または低latencyが最優先ならsmall dense modelの方が合理的です。Flash-Nextはtokenあたりの計算を減らしますが、weightとN-gram embeddingの保存を消しません。
download前にQwen公式repositoryでidentity/runtime supportを確認し、Unslothの最新guideでquant情報を更新してください。weight pageの現在のlicense tagはqwen-community-1.0です。商用利用や再配布はtagではなく実際のlicense本文で判断します。
