284Bの大規模モデル「DeepSeek-V4-Flash」を64GBのMac miniで高速動作、ABEJAが検証成果とモデルを公開

要点

• ABEJAのエンジニアが、総パラメータ284Bのオープンウェイトモデル「DeepSeek-V4-Flash-0731」をメモリ64GBのMac miniで実用的に動作させる検証結果を公開した。

• 通常102GB以上のRAMを要するモデルに対し、重みの削減などを行うことでメモリ使用量を58.5GBまで抑え、全データをメモリ上に収めることに成功した。

• これにより推論速度が大幅に向上し、プロンプト処理（prefill）は最大126トークン/秒、生成（decode）は最大20トークン/秒を達成した。

• 検証に用いられた最適化済みモデルの重みファイルは、Hugging Face上で一般公開されている。

• 株式会社ABEJAのエンジニアである石川氏は2026年9月28日、総パラメータ数284BのオープンウェイトAIモデル「DeepSeek-V4-Flash-0731」を、メモリ64GBのMac mini（M4 Pro搭載、2024年モデル）環境で高速動作させるための検証プロセスと性能データを同社公式テックブログで公開した。同モデルは高いコーディング性能を持つ一方で、推奨される量子化版でも100GB以上のメモリが必要となるため、64GBメモリ環境では動作速度が大幅に低下する課題があった。石川氏はメモリ不足による性能低下の要因を特定した上で、モデルのメモリフットプリントを58.5GBまで削減し、大幅な推論速度の向上を達成したと報告している。

「DeepSeek-V4-Flash」の性能とローカル実行におけるメモリの壁

DeepSeekが7月31日に公開した「DeepSeek-V4-Flash-0731」は、総パラメータ数284B、推論時に動作するアクティブパラメータ数13BのMoE（Mixture of Experts：入力に応じて複数の専門ネットワークから必要な部分を選択して処理する仕組み）アーキテクチャを採用したオープンウェイトモデルである。ベンチマークテストではTerminal Bench 2.1で82.7%、DeepSWEで54.4%、NL2Repoで54.2%を記録しており、コーディングエージェント用途で高い注目を集めている。

同モデルを手元で動かす手段として、AIモデル高速化フレームワークを提供するUnslothによる量子化GGUF版が公開されている。提供形式は最小の「UD-IQ1_S」（83GB）から「UD-Q8_K_XL」（162GB）まで揃っており、Unsloth公式ガイドでは最良の結果を得るために「UD-IQ3_XXS」の利用が推奨されている。

しかし、推奨されるUD-IQ3_XXSはファイルサイズ単体で97GiBあり、推論時にコンテキスト情報を保持するKVキャッシュを含めると102GiB以上のRAM（メインメモリ）が必要となる。最小構成のUD-IQ1_Sでも77GiB前後のメモリを要するため、64GiBのユニファイドメモリ（CPUとGPUで共有される単一のメモリ領域）を備えたMac miniでは、そのままではメモリ容量が不足するという課題が存在していた。

mmapを用いた初期検証とCPU推論の性能限界

石川氏はまず、オープンソースの推論ソフトウェア「llama.cpp」を用い、メモリ容量を超えるモデルの動作検証を実施した。llama.cppはストレージ上のファイルを仮想メモリ空間に直接対応付けて読み込む「mmap(2)」を利用するため、物理メモリに収まらないモデルであっても起動自体は可能である。

この検証では、GPUへのレイヤー配置を無効化する -ngl 0 と、DeepSeek-V4の実行時に指定しないとエラー停止や出力破損の原因となる --no-repack の2つのオプションを設定して実行された。その結果、動作はしたもののテキスト生成を行うdecode速度は4〜7トークン/秒にとどまり、入力プロンプトを処理するprefill速度も初期設定（バッチサイズ -ub 512）で4.88トークン/秒と低速であった。この速度では1万トークンのプロンプトを読み込むのに30分以上を要し、バッチサイズを -ub 8192 に広げても約19トークン/秒（所要時間8分以上）と、実用には厳しい状態であったという。

モデルサイズを小さくすることで改善するかを確かめるため、97GiBのUD-IQ3_XXS、90GiBのUD-Q2_K_XL、85GiBのUD-IQ2_Mの3種類の量子化形式で比較が行われた。しかし、ファイルサイズを12GiB縮小してもdecode速度は3.3〜4.1トークン/秒の間で推移し、明確な速度改善は見られなかった。メモリに収まらない限り、トークンを生成するたびにストレージから重みを読み直す構造が変わらないためである。

さらにキャッシュ状態を変えた複数回のテストデータを分析した結果、生成時間のばらつきはメモリ不足時に発生するページフォールト（メモリ上にないデータをストレージから読み出す割り込み処理）の量に比例していることが明らかになった。計算上、仮に全データをページキャッシュ上に保持できたとしても、CPUで処理する限りdecode速度は7.6トークン/秒が上限になると結論づけられている。

GPUオフロード時の速度低下とボトルネックの特定

続いて、llama.cppの -ngl オプションを用いて一部のレイヤーをGPUにオフロードする構成が検証された。しかし、GPUに配置するレイヤー数を0、4、16と増やしていくにつれて、decode速度は4.5トークン/秒、3.7トークン/秒、3.3トークン/秒へと低下し、24レイヤーではメモリ不足により起動できない結果となった。

この現象について石川氏は、Macのユニファイドメモリの特性が影響していると説明している。GPUに割り当てられたモデルの重みはメモリ上に固定されて解放されなくなるため、CPU側で利用可能なページキャッシュ領域が削られ、結果としてストレージからの読み直し頻度が増加してしまったためである。この検証から、GPUによる高速化を図るにはモデルの全データを物理メモリ内に完全に収める必要があることが判明した。

モデル重みの削減による高速化の達成

最小の1ビット量子化でも77.3GiBを要し、量子化による圧縮だけでは64GiBの制限をクリアできないことから、石川氏はモデルの重み自体を削減（プルーニング）する手法を導入した。

このアプローチにより、メモリ使用量を58.5GiBまで縮小することに成功し、Mac miniの64GiBメモリ内にモデル全体を収めてGPUで一括処理できるようになった。その結果、スタート時点と比較して推論性能は飛躍的に向上した。prefill速度は初期の4.88トークン/秒から111〜126トークン/秒へと大幅に加速し、decode速度も4〜7トークン/秒から14〜20トークン/秒に達したという。

本検証で作成されたプルーニング済みのモデルデータ（DeepSeek-V4-Flash-0731-Pruned-155B-A13B-GGUF）は、Hugging Faceのリポジトリにて公開されている。