模型與本機推論
POCKET、35Bの疎なMoEを8.2 GBに圧縮、標準のllama.cppでスマートフォンおよびCPUのみの環境でも実行可能
VIDRAFTはPOCKETシリーズの重みを公開し、35Bモデルを最小8.2 GBまで量子化しつつ、各tokenで有効化されるパラメータを約3Bに維持した。モデルはアップストリームのllama.cppをそのまま利用できるが、圧縮手法は公開されておらず、性能と品質を示す根拠も現時点では主に開発チームによるものだ。
韓国のチームVIDRAFTは、Darwin-36B-Opusをベースとするオンデバイスモデル群「POCKET」をリリースした。その要点は、スマートフォンがtokenごとに35Bの重みすべてを走査するのではなく、256個のexpertを持ち、毎回8個のみを有効化する疎なMoEアーキテクチャを用いることで、実際に有効化されるパラメータ数を約3Bに抑えることにある。さらに、IQ1_MからQ4_K_MまでのGGUF量子化版を提供し、ファイルサイズは8.2 GBから21 GBとなっている。韓国語版、英語版、Apple MLX向けの個別バージョンも用意されている。
技術面で特に注目すべきなのは互換性だ。POCKETはruntimeの改変を必要とせず、標準のllama.cppで直接実行できるとしている。そのため、既存のLM Studio、Ollama、または独自構築したCPU推論パイプラインで専用forkを保守する必要がない。チームは同一の8-vCPU Hugging Face Space上で約20.5 token/sを計測しており、27BのdenseモデルであるBonsaiの約6.1 token/sを上回った。16スレッドのXeon、M3 Pro、H100でのデコードでも、より高いスループットを記録した。これは、デコードがメモリ帯域幅に制約されるという特性と整合する。疎なモデルは各ステップで転送する有効な重みが少ないため、総パラメータ数が多くても、より小さなdenseモデルより高速になる可能性がある。
ただし、「35BがiPhoneで動く」ことは、実用的なスマートフォン向けアシスタントであることを意味しない。チームは、自ら測定したiPhone上でのtoken/s、Time to First Token、ピークメモリ使用量、持続負荷時の温度、消費電力をまだ公開していない。公開されている品質比較も400問のHellaSwagのみで、61%という結果がBonsaiの60%を上回ったとしても、推論能力、中国語能力、コーディング能力を証明するには不十分だ。重みはApache-2.0で提供されるが、超低ビット版の生成に使われた圧縮レシピは依然としてプロプライエタリ技術である。エンジニアリングチームは今後、実機でprefill、長いコンテキストにおけるメモリ使用量、サーマルスロットリングを再検証し、最低ビット版にドメイン固有の性能劣化が生じていないか確認すべきだ。