mzCache、CPU／GPU並列復元でモバイルLLMのメモリを回復、最初のtokenまでの遅延を2.1～5.5倍短縮

ソウル大学校とカリフォルニア大学バークレー校の研究者らは、ユーザーがカメラ、ゲーム、動画Appに切り替えた後、Androidのメモリ回収機構によって重みとKV cacheが退避される、オンデバイスLLMの問題に対処するmzCacheを提案した。論文によると、3B未満のパラメータを持つモデルでも、長いコンテキストと合わせると5～7 GBを占有し得る。Qwen3-0.6Bを例にすると、32KコンテキストのKV cacheは約3.5 GBに達する。一般的なzRAMはLZ4またはZstdを使用するが、テスト対象のKV cacheでは約0.2～9.3%しか容量を削減できず、メモリ圧迫が続くとLow-Memory Killerがモデルプロセスを直接終了する可能性がある。[mzCacheの論文](https://arxiv.org/abs/2609.01338)では、重みを層単位、KV cacheを固定tokenブロック単位でOpenCL Shared Virtual Memoryバッファに分割し、従来の連続した大容量ブロックでは全体を保持または解放するしかないという制約を回避する。

システムの中核は単純なswapではなく、「最速で復元するにはどうするか」に基づいて退避順序を決定する点にある。mzCacheは後段のTransformer層を優先的に退避し、推論で最初に使用される前段の層を保持する。新しいリクエストが届くと、GPUはメモリに残っている層から直ちにprefillを開始し、CPUはforward passの順序に従ってフラッシュストレージから重みを読み戻し、圧縮領域からKVブロックを展開する。カスタムOpenCL attention kernelは、非連続なKVポインタを直接ストリーミングできるため、事前に完全なバッファへ統合する必要がない。約6,000行のC／C++による実装はllama.cppを基盤とし、KV圧縮にはARM NEONを使用している。

研究では、市販スマートフォン上でQwen3-0.6BおよびEXAONE-4.0-1.2Bを使用し、ストレージベースの部分offloadと比較した結果、TTFTが2.1～5.5倍短縮されたと報告している。Galaxy S25+のマルチタスクテストでは、標準OSの経路では各ラウンドでモデルプロセスが終了した一方、mzCacheはセッション状態を保持した。[研究チームの出版物ページ](https://sites.google.com/view/kyunghanlee/publications)には、この論文がMobiCom 2026に採択されたと記載されている。ただし、現時点では公開コードは確認されておらず、評価対象もQualcomm Adreno、2つの小規模モデル、少数のスマートフォンに集中している。NPU、Metal、より大規模なモデルへ移植できるかどうかに加え、追加のピーク消費電力やフラッシュ書き込みコストについても、導入前に検証する必要がある。