Edge0、MoEエキスパートをSSDからストリーミング――35Bモデルの短いコンテキストで必要なアクティブメモリはわずか2.9 GiB

Edge0は、大規模な疎MoEのデプロイ問題をストレージ階層の管理として捉え直した。すべてのエキスパート重みをint4形式でSSDに保持し、実行時にはmemory mappingを通じて現在のtokenに必要なエキスパートだけを読み込む。このため、アクティブメモリはモデルの総パラメータ数ではなくworking setによって決まる。Apache 2.0で公開された最初のプレビュー版には、Qwen3.5-MoEをベースとする35B-A3Bと、Ling 3.0をベースとする8B-A1Bが含まれる。モデル、LoRA、ルーティング予測器は同じディレクトリで配布され、OpenAI互換の`/v1/chat/completions`エンドポイントを通じてサービスを提供できる。

ルーティング結果が確定してからSSDから重みを読み込む方式では、通常、各layerでI/O待ちが発生する。そこでEdge0は追加のprerouter headを学習させ、選択されるエキスパートを1ステップ先に予測することで、読み込み処理を現在のforward passとオーバーラップさせる。プロジェクトは、この設計によってデコードのthroughputが最大59％向上するとしている。ただし、効果はSSDのレイテンシ、モデルサイズ、ルーティング幅、予測のヒット率によって変わり、誤ったprefetchが帯域幅を浪費する可能性もある。backend interfaceはすでにMLX実装から分離されているが、CUDAは現時点では将来対応の項目にとどまる。

もう一つの技術であるRecover-LoRAは、FP16教師モデルを使って凍結されたint4モデルを蒸留し、量子化誤差の回復を試みる。adapterは基礎重みにmergeされない。公式が5つのbenchmarkで比較したところ、35B版の平均スコアはFP16ベースモデルを3.9ポイント、8B版は2.8ポイント下回った。ただし、これは依然としてチーム自身が実施したOpenCompassの結果であり、各モデルで使用しているベースモデルも同一ではない。

24GB Mac mini M4 Proで、約3,300-tokenのpromptと計測対象となる200個のデコードtokenを用いたテストでは、35B版は毎秒14.9～17.7 token、短いコンテキストでのアクティブメモリのピークは2.9 GiBだった。一方、完全な量子化済みファイルは依然として約23GBあり、ディスク上に保存される。長いコンテキストではKV cacheも別途増加するため、「3GBで35Bを動かせる」という表現を、総ストレージ容量やシステムメモリの要件と解釈することはできない。エンジニアリング面では今後、スマートフォンでの実測、cold startと複数リクエスト時のjitter、SSDの書き込み寿命、そしてCUDA backendでも同等のworking setとthroughputの優位性を維持できるかに注目すべきだ。