128GB M5 Max MacBook Pro で「ds4」を試したら、Claude Codeがローカルで動いた話

発端

2026年5月10日、テクノエッジに掲載された松尾公也氏の記事「128GB超メモリMac専用の巨大LLMエンジン「ds4」はローカル推論の常識をどう書き換えるのか」を読んで、これは試さずにいられないと思った。

手元には先日入手した M5 Max 搭載の MacBook Pro 16インチ、ユニファイドメモリは記事と同じ 128GB。動作条件はクリアしている。元記事は M4 Max での検証だったので、世代をひとつ進めた環境で同じことができれば、それなりに意味のあるデータが取れるはず。

ということで、その日の夕方からクローンしてビルドして、気がつけば「ローカルで Claude Code が動いている」ところまで行ってしまった。本記事はその一連の検証レポートである。

ds4 とは何か（おさらい）

詳しい解説は元記事に譲るが、要点だけ書くと：

• 作者: Salvatore Sanfilippo（antirez）。Redis の作者として知られる

• 対象モデル: DeepSeek V4 Flash（284Bパラメータ、アクティブ13Bの MoE）専用

• 動作条件: 128GB 以上のメモリを積んだ Apple Silicon Mac

• 設計思想: 汎用エンジンではなく「1モデル × Apple Silicon × エージェント運用」に全振り

新規性のある工夫は3つある。

ひとつめは 非対称な2-bit量子化。全層を均等に圧縮するのではなく、MoE のルーティングエキスパートだけを 2-bit にし、それ以外（共有エキスパート、projection、ルータ、出力層）は Q8 で残す。これで 284B が 81GB に収まる。

ふたつめは KVキャッシュのディスク永続化。プロンプトを SHA1 でキー化して <sha1>.kv として保存。同一プロンプトの2回目以降は ms 単位でロード可能になる。

みっつめは エージェントAPI同梱。OpenAI互換 /v1/chat/completions だけでなく Anthropic互換 /v1/messages まで実装している。

特に2番目のディスクKVキャッシュが本記事の主役になる。

検証環境

検証に使ったマシンは MacBook Pro 16インチ（Mac17,6）、Apple M5 Max 搭載モデル。コア構成は18コアで、内訳は Super 6コア + Performance 12コア。M5 世代から「Super」と「Performance」という新しい階層名になっており、従来の「Performance + Efficiency」二層から切り替わっている点が地味に興味深い。

メモリは 128GB Unified Memory、OS は macOS 26.4.1（build 25E253）。

ds4 のコミットハッシュは 8e7575b。これは元記事の検証環境と同一なので、直接比較が可能な条件になっている。

GGUF は DeepSeek-V4-Flash-IQ2XXS-w2Q2K-AProjQ8-SExpQ8-OutQ8-chat-v2.gguf、サイズは約 80.77 GiB。MTP（Speculative Decoding）用の補助 GGUF も落としたが今回は使用していない。

ビルドとモデルのダウンロード

ビルドは拍子抜けするほど簡単だった。

mkdir -p ~/src ~/models/ds4
cd ~/src
git clone https://github.com/antirez/ds4.git
cd ds4
make

ビルド時間は10秒に満たない。ds4 と ds4-server の2バイナリが生成される。

モデル置き場はコードと分離した。./gguf/ ディレクトリを ~/models/ds4/ へのシンボリックリンクにして、後で llama.cpp フォークと共有できるようにする。

ln -s ~/models/ds4 gguf
./download_model.sh q2

GGUF は約 81GB。手元は 10G 回線で、約 200 MB/s 出てダウンロードは7〜8分で完了。

ベンチマーク：純粋な推論性能

サーバを起動する前に、まず CLI で純粋な推論性能を測る。記事の M4 Max 値と直接比較できる形で、3パターン揃えた。条件は --nothink（中問題は thinking）、--temp 0（greedy）、出力 256〜512 トークン。

結果は以下の通り。

短プロンプト（"Hello, who are you?"、約10トークン）: prefill 65.14 t/s、generation 39.65 t/s

コード生成（"Write Python code to compute fibonacci(20)"）: prefill 71.79 t/s、generation 39.38 t/s

thinking付き中問題（日本語の文章題）: prefill 109.84 t/s、generation 39.06 t/s

generation は3条件とも 39 t/s 台で安定している。これはモデル全体のメモリ帯域律速なのでプロンプト長に依存しないのが正常な挙動だ。

元記事との比較

元記事の M4 Max 128GB で取得された値と並べてみる。

短プロンプトは
M4 Max が prefill 22.69 t/s（ただしcold start を含む値）/ gen 23.42 t/s に対し、
M5 Max では prefill 65.14 t/s / gen 39.65 t/s。

コード生成は
M4 Max が prefill 49.36 t/s / gen 31.14 t/s に対し、
M5 Max が prefill 71.79 t/s / gen 39.38 t/s。

thinking 付き中問題では
M4 Max が prefill 80.34 t/s / gen 31.80 t/s だったところ、
M5 Max では prefill 109.84 t/s / gen 39.06 t/s。

generation は条件によらず約 1.2〜1.7倍。これは M5 世代の Unified Memory 帯域の改善が直接効いている部分だろう。MoE モデルは生成時にアクティブパラメータ全部を舐めるため、メモリ帯域がそのまま速度になる。

派手な観察：長文prefill

実は短プロンプトでは ds4 の真価は半分も見えない。1500 トークン級の長プロンプトを投げると prefill は 324 t/s まで伸びた。

さらに後述する Claude Code 経由の 22,618 トークン処理では、チャンクごとに 375 → 301 t/s で推移しながら、合計71秒で完走している。22kトークン規模で speed が 20% 程度しか落ちないのは、DeepSeek V4 Flash の Hybrid Attention（CSA + HCA）が長文脈で本領を発揮している証拠だ。

Metal 初期化の劇的改善

地味に驚いたのが Metal residency request の所要時間。元記事では「30秒ほどかかる」と書かれていたが、手元の M5 Max + macOS 26.4.1 環境では：

residency requested in 269.376 ms

269ミリ秒。100倍以上速い。OS 側か GPU ドライバ側の改善が効いていると思われる。これだけで起動体験が別物になる。

ディスクKVキャッシュの威力

ds4 の本命機能はこちら。サーバを起動して同一プロンプトを2回投げる、というシンプルな実験で確認した。

サーバ起動

./ds4-server \
  --ctx 100000 \
  --kv-disk-dir /tmp/ds4-kv \
  --kv-disk-space-mb 8192 \
  --trace /tmp/ds4-trace.log

--kv-disk-dir を指定しないとディスクキャッシュは無効。デフォルトは無効になっているのは初見だと罠なので注意。

計測

995トークンのプロンプト（ds4 の前提情報を詰め込んだ日本語の文章題）を、同一内容で2回投げた。

1回目は cold 状態で、サーバ側の prefill 時間が 3.404秒、サーバ側の全体応答が 4.733秒、curl で測った往復時間が 4.758秒。

2回目はディスクキャッシュ hit で、サーバ側の prefill 時間が 0.000秒（KVロードに 4.3ms）、サーバ側の全体応答が 1.314秒、curl 往復が 1.342秒。

サーバ側のログには cold 時に保存、hit 時に読み込みの記録が残る：

18:50:44 kv cache stored tokens=995 reason=cold size=35.88 MiB save=13.2 ms
18:50:46 kv cache hit tokens=995 quant=2 load=4.3 ms file=/tmp/ds4-kv/df3aa351655ebf3a9495e98fec753ea52d1f8fa4.kv

995 トークンの KV キャッシュは 35.88 MiB。ディスクへの保存に 13.2 ms、復元に 4.3 ms。プリフィル処理そのものが完全にスキップされた。

curl の実測ベースで 4.758s → 1.342s と約 3.5 倍の高速化。これは生成時間（50 トークン分の generation 時間）が支配的になるためで、prefill 部分だけで見れば 3,400 ms → 0 ms と実質無限倍速になっている。プロンプトが長くなるほど効果は劇的になる、というのが次のセクションで明らかになる。

真打ち：Claude Code が ds4 で動いた

ここまでは順当な検証だった。次が本記事のクライマックスである。

Claude Code を ds4 に向ける

Anthropic 公式の Claude Code（v2.1.138）は、環境変数 ANTHROPIC_BASE_URL で API の向き先を変更できる。ds4-server は Anthropic 互換の /v1/messages を実装しているので、理屈上はそのまま接続できるはず。

export ANTHROPIC_BASE_URL=http://127.0.0.1:8000
export ANTHROPIC_API_KEY=dummy
export ANTHROPIC_MODEL=deepseek-v4-flash
claude

testproj という空ディレクトリで claude コマンドを起動。

起動の瞬間

Claude Code のヘッダに表示されたモデル名：

deepseek-v4-flash · API Usage Billing
~/work/testproj

「API Usage Billing」と出ているが、実際の課金はゼロ。手元の ds4-server に繋いでいるだけだ。Claude Code 側は Anthropic の正規 API に繋がっていると認識したまま、応答しているのは紛れもなくローカルの DeepSeek V4 Flash。

自己認識テスト

> 今動いてる推論モデル、自認は何か回答お願いします

返ってきたのは：

現在稼働中の推論モデルは DeepSeek V4 Flash です。
Claude Code の環境上で動作しています。

ちゃんとモデル自身が「私は DeepSeek V4 Flash」と認識している。API 互換レイヤーが完璧に機能していて、Claude Code のシステムプロンプトに侵食されずにモデル本来の自己認識が保たれている。

22,618 トークンのシステムプロンプト

サーバ側ログを見ると、Claude Code が初手で送ってくるシステムプロンプトの正体が見えた。

chat ctx=0..22618:22618 TOOLS prompt start

22,618 トークン。元記事で松尾氏が「Claude Code が初手で送ってくる25,000トークンのシステムプロンプト」と書いていたあれが、実測値として記録された。ツール定義、システム指示、過去のチャット履歴などがすべてここに乗っている。

これを cold で処理するのに 71.227 秒かかった。長い。クライアントの「Cooked for 1m 21s」表示と合致する。

2回目以降の魔法

その後、別の質問を投げた瞬間にディスクKVキャッシュが効いた：

18:22:09 kv cache hit tokens=22691 quant=2 load=30.8 ms
        file=/tmp/ds4-kv/59ebb5e16e5317facd24f3fa4c1c43de3f12c2d2.kv
chat ctx=22691..22714:23 TOOLS prompt start
chat ctx=22691..22714:23 TOOLS prompt done 0.769s

22,691トークンが30.8msで復元。あとは新しい質問の差分（23トークン）だけを 769 ms で処理し、応答生成へ。

1問目（システムプロンプト初回、cold）は prefill 71.227 秒、全体 73.734 秒。2問目（22,691トークン分復元、disk hit）は prefill が 0.030 秒のロード + 0.769 秒の差分処理、全体で 4.650 秒。

prefill だけで見れば 71 秒 → 0.8 秒、約 89 倍の高速化。元記事は 1364 トークンで 18 倍だったが、Claude Code のような巨大システムプロンプトでは 89 倍まで効果が拡大する。プロンプトが長いほど劇的になる、という仮説の見事な実証になった。

コード生成までやらせてみた

ここまで動けば実用検証もしたくなる。

Claude Code に対して「カレントディレクトリのファイル一覧を表示してください」と頼むと Bash ツールで ls を実行、
「hello.py を作って "Hello from DeepSeek V4 Flash on M5 Max!" と表示する内容にしてください」で Write ツールでファイル作成、
「引数で名前を受け取って "Hello, <名前>!" と表示するように修正して」で Edit ツールで修正、
最後に「fibonacci.py を作ってください。コマンドライン引数 n を受け取って、フィボナッチ数列の n 番目までを表示する効率的な実装」で Write で生成。

すべてのツール呼び出しが正しくチェーンした。コード品質も悪くない。fibonacci のメモ化実装はデフォルト引数による辞書共有という、定番だが綺麗な書き方を採用していた。

off-by-one を発見、修正させてみる

ところが fibonacci.py 20 の実行結果を見ると最後が 4181 で、fib(20) = 6765 が含まれていない。range(n) で 0〜n-1 を回す解釈になっており、人間の自然な「n番目を含めて」とは食い違っている。

そこで指摘してみた：

> fibonacci.py 20 を実行すると最後が 4181 になりますが、
  数学的には fib(20) = 6765 のはずです。
  「n番目まで」の解釈で off-by-one エラーが発生しているようです。
  fib(n) も含むように修正してください。

返ってきた挙動が美しかった。まず Bash で実行してユーザの主張が事実か確認、次に Edit で range(n) → range(n + 1) という最小限の修正、もう一度 Bash で実行して ...4181, 6765 が出ることを確認、最後に「fib(0) から fib(20) までの 21項 が表示され、最後が正しく 6765 になりました」と説明。

ユーザの指摘を盲信せず、確認 → 最小修正 → 再検証という、エージェントとして理想的な動作。2-bit 量子化された 81GB のモデルが、ローカルでこの挙動を見せている。

何が証明されたか

ここまでの検証で、ds4 + DeepSeek V4 Flash + Claude Code の組み合わせが 実用域に達している ことが確認できた。元記事の主張を実機で確認してみた結果、
Apple Silicon Mac でほぼゼロ依存・make一発・10秒未満でビルドできること、
M3 Max 128GB の README 公称値より速いこと（M5 Max では generation で M4 Max 比 +25%）、
同一プロンプト2回目で大幅高速化すること（短文で3.5倍、22kトークンで89倍）、
OpenAI互換 / Anthropic互換 API 両方が動作すること、Claude Code 公式バイナリがそのまま動くこと、
Read / Write / Edit / Bash すべてのツールがチェーンすること、ユーザフィードバックループが回ること（off-by-one 指摘 → 確認 → 修正 → 再テスト）、
すべて確認できた。

M5 Max 128GB という環境の評価

M5 Max は「ローカルAIマシン」として現状ほぼ完成形だと思う。81GB のモデルが余裕で乗り、generation 39 t/s 台、KV キャッシュやアプリ用に 40GB の余裕、Metal の初期化も激速。MacBook Pro 一台で完結する自律 AI エージェント環境が、本当に手元で動いてしまっている。

特に Claude Code を回している間も、Activity Monitor のメモリプレッシャーは緑のまま、動作中に他の作業も普通にできるレベル。これは「ギリギリ動く」というより「実用余裕」のレンジに入ってきている。

残るトレードオフ

公平に書いておく。対応モデルは DeepSeek V4 Flash のみで、次のモデルが出ても antirez の対応待ちになる。Metal 専用で、CUDA は未定。CPU バックエンドは macOS の VM バグでカーネルクラッシュする、と README に警告がある。2bit 量子化版のため、フルプレシジョンほどの正確性は期待できない（とはいえ今回のコード生成では問題を感じなかったが）。Claude Code 連携は ANTHROPIC_BASE_URL を勝手に書き換える形なので、本来の Anthropic アカウントとの併用は注意が必要。

まとめ

「Redis の作者がローカル推論エンジンを書いた」というだけで界隈はざわつくが、中身を見るとさらに驚く。「KV キャッシュをディスクに置く」「非対称 2-bit 量子化」「1モデル特化」という、汎用フレームワークの常識を真っ向から否定する設計。それを実装してしまうところに antirez らしさがある。

そしてその結果、「Claude Code が完全にローカルで動く」という光景が、M5 Max MacBook Pro 一台で再現できてしまった。元記事の松尾氏が「1年前なら冗談だった光景」と書いていたのは、まさにこのことだ。

検証コストは ds4 のクローンとビルドが約30秒、GGUF ダウンロードが約8分（10G 回線）、全工程の実時間は起動から Claude Code 動作確認まで2時間弱。これだけのコストで、この体験が手に入る時代になった、というのが個人的には今日一番の驚きだった。

次にやってみたいこと

しばらくは Claude Code を ds4 経由で実運用に投入してみるつもり。普段使いで雑にコード書かせたり、エラー解析してもらったり、ドキュメント書かせたり。短時間の検証ではわからない癖や限界が見えるはずなので、しばらく運用してから続報を書こうと思う。

参考リンク

• ds4 GitHub: https://github.com/antirez/ds4

• DeepSeek V4 Flash GGUF: https://huggingface.co/antirez/deepseek-v4-gguf

• DeepSeek V4 Flash 公式: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash

• 元記事（テクノエッジ）: https://www.techno-edge.net/article/2026/05/10/5049.html