メインコンテンツへスキップ
見出し画像

Qwen3.8-Flash-Next 最新アーキテクチャをどう動かすか

    he-be

    16GB VRAMで実用的に動く177Bの次世代LLMモデル

    Qwen3.8-Flash-Nextは、次世代Qwen4アーキテクチャのプレビュー版だ。名前は3.8だが中身は全く別物で、Qwen4としての本格的なリリースがこの後に控えている。

    これまでのローカルLLMは、賢さを買うとVRAMも一緒に買わされた。パラメータを増やせば賢くなり、増やしたぶんVRAMが要る。
    我々ローカルLLM勢にとって賢さの値段はVRAMの値段だった。

    このアーキテクチャはそこを設計で突破しようとしている。毎トークン計算する部分だけをVRAMに置き、知識は表にしてRAMに置き、文脈は固定サイズの状態に畳む。
    賢さと家で回せる効率を同時に取りに来た作りで、Maker Faireの会場で七味唐辛子一味分類工場の司令塔をやっていたのも、このモデルだった。

    だから今のうちに特徴を押さえておく価値がある。Qwen4が出たとき、MTPをどう使うか、知識の表をどこに置くか、コンテキストをどこまで取るか、という運用の型はそのまま持ち越せるはずだ。

    この記事は、手元の2台(DDR5のゲーミングPCと、DDR4に中古GPUを2枚積んだサーバー)でこのモデルを動かした運用の型を書く。

    先に結論

    • Qwen3.8-Flash-Nextは、VRAMに置くものを毎トークン計算する6Bぶんに絞り、51Bの知識はRAMに置いた表で足す作りになっている。長コンテキストでもVRAM消費が増えない。いまローカルで回すなら一番のおすすめだ

    • 運用の型は2つ。DDR5のPCなら16GBのGPU1枚でexpertをRAMに置く。DDR4なら中古GPUを複数積んでexpertをVRAMに載せ切る

    • Q4より下の量子化でも、実タスクで成果物の差がわからなかった。だから構成は速さとコンテキスト長で選んでいい


    前編


    賢さをVRAMの外に置く

    モデルを賢くする素直な方法はパラメータを増やすことで、増やしたぶんVRAMが要る。このモデルはVRAMを使わずにパラメータを増やす方法を2つ備えている。

    ひとつ目はお馴染みのMoEだ。総パラメータ125B(48層)のうち、1トークンを作るのに読むのは6Bで、呼ばれなかったexpertはVRAMに置かなくてよくRAM(CPU)でいい。
    ただし、どの6Bが呼ばれるかはその時にならないと分からないので、RAMからGPUへ運ぶ往復が毎トークン起きる。
    この往復の速さがDDR5かDDR4かで決まり、後で書く型Aと型Bの分かれ目になる。

    ふたつ目がこのモデルの新しい部分で、n-gram埋め込みという51Bの表だ。
    2000万項目の表を、直前の2語か3語の並びで検索しLLMの計算に注入する。
    考えなくても知っていればいいことを、6Bの本体が毎回考え直すかわりに、表の検索で済ませる。
    常識問題をカンニングする索引だ。

    この表は、直前の単語で検索するので、探して事前準備することができる。これが呼ぶまで分からないexpertとの違いだ。時間の余裕が大きく、RAMだけでなくSSDにすら置いておくことができる。
    表のサイズは26.8GiB。177Bのうち3割弱の知識がVRAMの外に置いておける。RAMに置いておく場合生成27 t/sだった。

    長コンテキストで効くのは、履歴を固定サイズの状態に畳みVRAM消費を抑える仕組みだ。実測で、文脈1kトークンあたりに増えるVRAMはV100側19MiB、3090側13.7MiBしかなく、わずかなサイズに抑えられている。
    16GBのGPUに240kの長コンテキストが載るのはこの性質による。

    最後にMTP。次の1トークンを先読みして、当たれば1回の計算で2トークン進む。効く構成と効かない構成があり、分かれ目は型Bの所で書く。

    まとめると、VRAMよりRAMの方が安く量を増やせるという事情を考慮した、コスパの高い設計ということだ。
    VRAMとRAM、RAMの種類によって適した構成が変わるので、二つ紹介する。


    型A。DDR5なら16GBのGPU1枚で動く

    ゲーミングPCはRyzen 7 9700X、DDR5-5600 128GB、RTX 5080 16GB。ここにQ4_K_XLの111GBを載せる。
    VRAMに入るわけがないので、expert 48層のうち47層(つまりほとんど全部)をRAMに置く。
    GPUに残るのはattentionとdense、expert 1層、KV cache、MTPヘッドだ。

    高速なDDR5だから成り立つ構成で、ほとんどのウェイトをRAMに置いて47層を転送しても25ms弱で済む。
    GPU側13.4msなので1トークン40ms前後、24 t/sになる。
    これがDDR4だと20 t/sを切ってしまう。

    文脈はMTPを付けたまま載る最長の240kにした。
    文脈が埋まるほど生成が遅くなり、MTPの相対的な得が大きくなる。
    実際、240kにMTPを付けたら18.1 t/s、256kにMTP無しが16.8 t/sで、MTPの効果があった。

    トラップとして、サイズの小さいUD-IQ4_XS (93.7GB)は量子化の影響で計算効率が悪く、RAM消費がわずかに減るが速度は改善しない。素直により賢いQ4_K_XL (111GB)を使えば良い。

    型B。DDR4なら中古GPUで載せ切る

    うちのLLMサーバーはRyzen 7 5700X、DDR4-3200 96GB、Tesla V100 32GBとRTX 3090 24GBの計56GB VRAM。
    ここにQ4_K_XLを載せてexpert 20層をCPUに置くと28.5 t/sで、なんとVRAM 16GBのPCとほとんど変わらない。
    最初は2割速いが、128kコンテキストだとPCの方が速いことすらある。
    VRAMを3.5倍積んだのに、DDR4の遅さと古いGPUの計算時間でちょうど相殺してしまい、速度が出ない。

    原因は上記したようにDDR4が遅いことに尽きる。RAMとVRAMの往復を毎トークン待つため、MTPも効果が出ない。以前MTPを引き分けと判断したのは、この構成での話だった。

    それならば、量子化を1段下げて載せ切ってしまえば良い。
    Q4_K_XLが111GBで、IQ4_XSが94GB、IQ3_XXSが82GB。
    IQ3_XXSならGPUに載せる分が49.5GiBで、n-gram埋め込み26.8GiBをRAMに出せば、56GBに96kコンテキスト込みで入る。
    16GBの方は当然最初から載せ切る選択肢はない。

    載せ切ると2倍速い。
    MTP無しが50.2 t/s、MTPを付けて短文脈60前後、コード生成では72 t/sまで出た。
    63kコンテキスト段階で43.7、96kで36.1t/s出ている。
    Q4_K_XLと比較すると、短文脈28.2、63kで19.8、97kで17.1なので、全体的に2倍速だ。

    同じ56GBが、Q4のままだと16GBと同着で、IQ3_XXSにすると2倍速い。


    量子化を下げても、差が出なかった

    IQ3_XXSはIQ2_Sの2.5bit 量子化を多用する。個人的には3bitもやりすぎな量子化だと考えているので、以前は3bitのIQ4_XSを避けて、遅いQ4_K_XLを選んだ。
    今回、速度を出すために3bitに下げているので、性能面の対価があるかもしれない。当然KLDを測定したら劣化はしている。

    ただ知りたいのは実際に成果物が変わるかどうかなので、同じエージェントコーディングタスクをpi coding agentから2台に投げて比べた。
    PCのQ4_K_XLとサーバーのIQ3_XXS対決として、段取りとタスクの用意はClaudeに丸投げ。

    テストは6組すべて同じ結果だった。たとえば矛盾のあるタスクでは、両方とも関数を壊してテストを通した上で「ドキュメントと矛盾している」と指摘し、確認を求めてきた。判断の分かれる所で同じ判断をしている。

    結局二つの量子化で差が出るタスクを作れなかった。思いつく限りのコーディングタスクで差が出ないなら、自分の用途では差がないのと同じことだ。
    遅い方を選んだ以前の判断も体感ベースだし、今回も結局雰囲気ベースだ。
    おそらく、177Bもパラメータがあり、元が賢いぶん量子化の誤りが出にくいのだと見当を付けている。
    小さいモデルで2.5bit量子化したら壊れるのは当然だ。

    実タスク中の生成速度はIQ3_XXSが69 t/s、Q4_K_XLが30 t/sで、先ほどの2倍強がそのまま出た。


    このモデルの強み

    なぜこのモデルがおすすめかを書いておく。エージェントタスクでの差は、パラメータ数やベンチマークの点差より、最初の一手の判断に出る。文脈を読んで、どこで考えるのをやめ、何から手を付けるかを決める力だ。
    要するにエンジニアとしての勘、経験のようなものだ。

    Laguna-S-2.1 118Bはthinkingが止まらず、実際に手を動かすことができなかった。
    Qwen3.8-27Bは検討に検討を重ねなかなか成果物を出してこない。
    Ornith-1.5-35B-A3Bはブラウザ動作確認で古いオプションを付け自滅する。

    Flash-Nextは考え終わると1トークン目から手が動く。
    ブラウザで動く3Dレースゲームを書かせ、ブラウザで自己検証させる課題を完走したのはFlash-Nextだけで、公開ベンチマーク(SWE-bench Pro)が3つとも60点前後で横並びなのに結果は釣り合っていない。
    ログを読むと、頼まれていない検証ツールを先に書き、その場限りのエラー対処はバグを隠すと判断して入れず、ツールを呼ぶ前のthinkingは数十字から数百字で速やかに正しい手を打っていた。
    そして今回、2.5bpwに落としても、同じ判断をしている。

    この差は複利で効く。
    最初の一手が合っていればやり直しが無く、thinkingが短く済み、コンテキストに迷う情報が入らず、次の判断も正確になる。一手目を外すモデルは逆の流れで崩壊していく。
    ベンチの点差に対して差が不連続に見えるのはこのためだと思っている。

    一応、比較相手はLaguna-S-2.1やQwen3.8-27Bなど家で回せるモデル同士で、クラウドのモデルと同じくらい賢いという話はしていない。といっても確実にClaude Sonnetよりは賢いが、当然Fableの方が賢いに決まっている。


    まとめ

    Qwen3.8-Flash-Nextは、VRAMに置くものを毎トークン計算する部分に絞り、知識はRAMに置いた51Bの表で足し、文脈は固定サイズの状態に畳む。だから16GBのGPU1枚で240kが載り、56GBに載せ切れば60 t/s出る。

    運用の型は2つで、DDR5なら16GBのGPU1枚でexpertをRAMに置き、DDR4なら中古GPUを複数積んで載せ切る。載せ切れるならQ4に固執する理由は無かった。IQ3_XXSまで下げても、実タスクで成果物の差を作れなかった。

    Qwen4が出ても、この型はそのまま使えるはずだ。安いVRAMを狙いつつ、首を長ーくして待っていよう。

     
     
     

    he-be

     
     
    LLMマニア

    あなたへのおすすめ