r/LocalLLaMA検証: <code>Krasis</code>が単一RTX 5080で80B MoEの3,324 tok/s prefillを報告

投稿が示したアプローチ

r/LocalLLaMAで共有された Krasis 投稿は、収集時点でスコア180、コメント53だった。投稿者の説明は一貫している。長い入力を読む prefill はGPUで処理し、生成段階の decode はCPUで処理する。system RAM を積極活用し、VRAM不足でも大きなMoEモデルを実用速度に近づけるという設計だ。

公開された主要ベンチマーク

投稿の代表値は、Qwen3-Coder-Next (80B, Q4) を単一RTX 5080 16GBで動かしたケースで、prefill 3,324 tok/s、35K contextでTTFT 9.7s、decode 14.9 tok/s。さらにEPYC 7742 + RTX 2000 Ada 16GB構成でもQ4/Q8比較が示され、Qwen3.5-35B-A3B、Qwen3-235B-A22B、DeepSeek V2-Liteなど複数モデルの結果が併記されている。

測定条件として、prefillは10K-50K token prompt、decodeは64-token生成平均という記述がある。つまり、短いベンチではなく、実際に長いcontextを扱う場面を意識した評価になっている。

実務で注目される理由

• IDEやagent運用では入力contextが肥大化し、prefill待ちがUXのボトルネックになりやすい。
• 従来offloadではCPU側の読み込み経路が長く、最初の応答まで時間がかかることが多い。
• GPU prefillを優先する設計は、同じVRAMでも体感応答を改善できる可能性がある。

制約と今後の検証項目

投稿とREADMEは制約も明示している。大きなRAM容量、NVIDIA依存、初回前処理時間、ディスクキャッシュ容量などのコストがある。またMoE向け最適化が中心で、dense model全般に同じ効果が出るとは限らない。

それでも、consumerクラスのハードウェアで長文入力の待ち時間を具体的数値で改善しようとする試みとして価値がある。次に必要なのは第三者再現、同時リクエスト時の挙動、より大規模モデル帯での安定性評価である。

出典: Reddit投稿、Krasis GitHub