【geek-terminalニュース】NVMeで125B推論?Lean-QwenFlashが16GB VRAMで約20 tok/sを報告

📝 本日のニュース概要

以前お伝えしたQwen3.8 Flash Nextの続報です。Lean-QwenFlashの開発者が、NVMeへの直接オフロードにより、VRAM 16GB・割り当てRAM 8GBで約20 tok/sを報告。量子化、SSD帯域、キャッシュ、生成品質という再現性の条件を掘り下げます。性能は開発者の自己申告で、公式・大手メディアによる裏付けは提示資料にありません。Redditで交わされた低VRAM化への期待と、品質評価への批判も紹介します。

【事象の全貌と背景】
以前お伝えしたQwen3.8 Flash Nextの続報です。今回は「巨大MoEを、少ないメモリでどう動かすか」という実装の話。RedditのMaxDev0氏が、Lean-QwenFlashで125BモデルをNVMeへ直接オフロードし、VRAM 16GB・割り当てRAM 8GBで約20 tok/sを出したと報告しています。公式・大手メディアによる性能の裏付けは提示資料になく、以下の数値は開発者の自己申告です。

投稿者によれば、Strataなどの構成では約2万4000個のエキスパートをRAMに置くため48〜64GBほど必要になり、キャッシュミス時の演算をCPUが担うといいます。ただし、これは投稿者の比較説明であり、各エンジンの全設定を網羅した評価ではありません。今回の狙いは、そのRAM常駐の負担をSSDへの読み出しに振り替えること。大容量メモリが参加条件になるローカルLLMの壁を崩せるかが焦点です。

見出しの数字にも注意が必要です。4090の報告は使用枠を制限した条件で、総RAMが8GBしかないPCでの実証とは区別すべきです。3080 Laptopの別測定はVRAM 16GB・RAM 32GBの機体。「16GB GPUなら同じ速度」と読み替える根拠もありません。(出典:[Reddit投稿](https://www.reddit.com/r/LocalLLaMA/comments/1xev6bo/leanqwenflash_qwen38flashnext_125b_running_at_20/))

【技術的ディープダイブ】
公開READMEの説明では、512個のエキスパートのうち各層・各トークンで10個を活性化し、GPUキャッシュにない重みをNVMeから取り込み、エキスパートの演算はGPUで行う設計だとされています。O_DIRECTと非同期バッファを使うとのことですが、「直接」という語だけでSSDからGPUへホストを経由せず転送する仕組みだと断定はできません。READMEにもホストRAMのキャッシュが登場します。

同資料は、約47GBのエキスパート用ストアと32GBのN-gramテーブルをSSDに置き、Linux、NVIDIA GPU、読み出し約3GB/s以上の高速NVMeを要件に挙げています。これは実装者の説明であり、その帯域さえあれば性能が再現する保証ではありません。(出典:[公開README](https://github.com/MaxDevv/lean-qwenflash))

測定設定は「3.05bpw_h5_ng5、Q4 KV cache」。投稿者の4090測定では、8k文脈で文章生成28〜33 tok/s、コード生成19〜22 tok/s、prefill約1080 tok/s。100kでは生成20.8 tok/s・prefill約1536 tok/s、262kでは生成20.0 tok/s・prefill約1627 tok/sとされています。約20 tok/sという見出しは、この量子化とキャッシュ設定込みの数字です。文章とコードでも開きがあり、用途を省いた速度比較は危うい。

3080 Laptopでは100k文脈で生成約18〜21 tok/s、prefill約650〜700 tok/s、ピークVRAM 15.5GBとの報告です。入力処理のprefillと、続きのトークンを出すdecodeは分けて読む必要があります。長い入力を毎回処理する使い方と、キャッシュを再利用する使い方では、体感も変わるでしょう。

再現性を詰めるなら、SSDの型番、PCIe接続、実際の読み出し量、キャッシュ命中率、初回と反復実行の差、入力と生成長、メモリ制限の方法が欲しいところ。提示された測定だけでは、SSD帯域がどの程度速度を支配するかは算定できません。「125B全体を毎トークンSSDから読む」と仮定するのも、必要帯域を公称シーケンシャル速度だけで判断するのも早計です。

【コミュニティの生々しい熱量と議論】
反応が面白いのは、称賛がすぐ手持ち機材の相談に変わるところです。philmarcracken氏は12GBの3080 Tiと8GBの3070を持つUbuntuサーバーについて、こうした専用エンジンはGPU分割に弱いのでは、と質問。投稿者は「厳密な要件ではない」と応じ、エージェントに改造させて結果を共有してほしいと促しています。30〜40 tok/sも期待できそうだという返信は、測定結果ではなく投稿者の予想です。

一方、Humble_Rabbt氏の「6GB VRAMで、せめて15 tok/sは?」には、投稿者も「試して。ただ、あまり期待はしていない」と慎重。16GBでの報告から、6GBや異種GPUの合算まで成功済みと広げてはいけません。足りないメモリをどう配分するかという、現場そのものの議論です。

cubebash氏はソフトウェア開発のエージェント用途で高く評価し、SSDから大部分を流せるなら将来RAMやVRAMはほとんど要らなくなるのでは、と期待を寄せています。そこへdevilish-lavanya氏が「そのRAM、私のPCに入れてくれない?」と返す。メモリ不足から解放されたい願望と、今すぐ増設したい本音が同居しています。

ただし、速度の熱狂に品質の問いが刺さります。FullstackSensei氏は、流用元のsybil系GLMリポジトリのKL divergence評価について、数千トークン程度の雑学問題では劣化を十分測れない、と批判しています。これはLean-QwenFlashの品質低下を証明した指摘ではありません。それでも、3.05bpwとQ4 KVの構成で、長文の参照、コード修正、ツール呼び出しの信頼性が保たれるかは別途検証が必要、という論点につながります。(反応の出典:前掲Reddit投稿)

【今後の展望とエコシステムへの影響】
もし別のSSDやGPUでも再現されるなら、「全エキスパートをRAMに置く」ことが唯一の入口ではなくなり、既存PCで大型モデルを試す選択肢が広がりそうです。メモリ容量だけでなく、SSDの応答、キャッシュ設計、入力処理まで含めた構成の工夫が、ローカル推論の競争軸になる可能性があります。

ただし、RAMやVRAMの終焉を宣言する段階ではありません。今回の説明にも両方のキャッシュが残り、速度とメモリと品質の交換条件は未確定です。次に欲しいのは、同じ入力と量子化でSSD・キャッシュ容量を変えた比較、そして長文や実際の開発課題での品質評価。約20 tok/sという魅力的な自己申告を、「自分の機材で、必要な品質を保って出せる速度」へ変えることが、このハックの次の勝負でしょう。

🎥 このニュースの動画版&音声版はこちら!

📺 深掘りメイン動画: YouTubeで視聴する

🎧 ポッドキャスト版: ラジオ感覚で聴く

※この記事は、Geek Terminalの自律型AIパイプラインによって自動生成・配信されています。

📺 映像と音声でサクッとチェックしたい方は
Geek Terminal 公式YouTubeチャンネルへ!

タイトルとURLをコピーしました