注記: 本記事の調査（DwarfStar / ds4 の設計、選択的量子化のレシピ、DeepSeek V4 Flash のモデル構成、各 Mac / DGX Spark でのローカル推論ベンチの突き合わせ）には、Claude と、そのリサーチ機能を利用しています。ローカル推論は情報の更新が非常に速く、かつ M5 Max 実機ベンチのように「コミュニティ報告例」の域を出ない数値も多い領域です。参考にされる場合は、必ず一次情報（GitHub の README、antirez.com のブログ、Hugging Face の配布ページ）で確認してください。本記事は2026年7月時点の情報をもとにしています。数値は「公式実測」「コミュニティ報告例」「未確認」を区別して書いています。
はじめに
前回、M5 Max（128GB）を注文して届くのを待っている間に、なぜ2ダイ構成で Unified Memory を保てるのかを調べる記事を書きました。今回はその続きというか、同じ「M5 Max が来るまでにいろいろ調べておく」シリーズです。
ハードの中身が一段落したので、今度は「では実際に何を載せて回すのか」を調べています。128GB という容量を選んだ最大の理由が、ローカルで大きめのモデルを動かしたいからなので、ここは避けて通れません。
そこで最近ずっと話題になっているのが、Redis 作者の antirez（Salvatore Sanfilippo）氏 が作った DwarfStar（リポジトリ名は ds4）です。これは DeepSeek V4 Flash という 284B の MoE モデルを、128GB の MacBook Pro で動かすために作られた専用推論エンジンで、その肝が「Dwarf Star 量子化」と呼ばれる選択的量子化です。
最初にひとつ整理しておくと、「DeepSeek V4 Flash の Dwarf Star 版」という固有のモデル名があるわけではありません。ここは混同しやすいので、記事の冒頭で三層に切り分けておきます。
- エンジン: DwarfStar（ds4）。C 中心（Metal / CUDA を含む）の推論エンジン、MIT ライセンス。
- 量子化手法: Dwarf Star の選択的（非対称）量子化。層ごとというより、テンソルの種別・部位ごとに精度を変えるレシピ。
- 重み: その量子化を適用した GGUF ファイル（
ds4flash.gguf）。Hugging Face のantirez/deepseek-v4-ggufで配布。
「DwarfStar 版のモデル」と一言で呼びたくなりますが、正確にはこの三層の合わせ技です。以降もこの区別を保って書きます。
この記事では、動機（なぜ128GBでこれが動くのか）→ 仕組み（選択的量子化）→ 性能（各 Mac / DGX Spark の実測）→ 自分の使い方・検証計画、の順で見ていきます。半導体ロジック検証（SystemVerilog / UVM）の視点も最後に少し混ぜます。
DwarfStar（ds4）とは何か
DwarfStar は、DeepSeek V4 Flash を主眼に置いたネイティブ推論エンジンです（現在は PRO も対応）。汎用の GGUF ランナーでも、llama.cpp のラッパーでもなく、完全に自己完結しています。README の言葉を借りると「意図的に狭い（intentionally narrow）」設計で、単一モデル系列 × 少数プラットフォームに賭ける、というスタンスです。
作者の antirez 氏 は Redis を作った人で、2026年4月24日に DeepSeek が V4 シリーズをオープンリリースした直後、5月初旬に ds4 を公開しました。公開1週目は平均14時間/日で作業したそうで、GitHub スターは1か月で13,000超（本記事の執筆時点では18,000超、fork も1.5k）に達し、llama.cpp 作者の Georgi Gerganov らの注目も集めました。
名前の由来がそのまま設計思想になっています。白色矮星（dwarf star）が自身に崩壊してより小さな空間に高密度な天体を作るように、DwarfStar は大きなモデルを約81GB に凝縮して家庭用 Mac に載せます。プロジェクトは当初 ds4、次に DwarfStar4、最終的に末尾の "4" を落として DwarfStar に改名されました（特定の DeepSeek バージョンから独立したエンジンのアイデンティティを示すため）。リポジトリの URL は今も github.com/antirez/ds4 のままです。
エンジンが提供するのは、単に推論を速く回すだけではありません。DeepSeek 特化のモデルロード、プロンプトレンダリング、tool calling、KV ステート管理（RAM とディスク両方）、サーバ API、統合コーディングエージェントまで、端から端まで内包しています。
汎用ランナーが「モデルを読んで推論する」だけなのに対し、ds4 は上のブロックを全部自前で持っているのが特徴です。この「フルスタックで1モデルに賭ける」姿勢が、後述するディスク KV キャッシュのような実用機能につながっています。
プロジェクト名の変遷も、この「エンジンとしての独立」を示しています。
対応バックエンドは、Metal が主要ターゲット（macOS / Apple Silicon）、次いで CUDA（DGX Spark を特に意識）、ROCm（Strix Halo / Framework Desktop）です。リポジトリの説明文も "DeepSeek 4 Flash and PRO local inference engine for Metal, CUDA and ROCm" となっており、サーバも CUDA で動きます。ここは進化が速いので、最新の README を見るのが確実です。
| バックエンド | 対応状況 | 備考 |
|---|---|---|
| Metal | 主要ターゲット | macOS / Apple Silicon、M5 Max はここ |
| CUDA | 対応 | DGX Spark を特に意識、サーバも動作 |
| ROCm | 対応 | Strix Halo / Framework Desktop |
| CPU | 正しさ確認用のみ | production 非推奨、macOS ではカーネルクラッシュ報告。Linux 向け make cpu はあるが参照/デバッグ用途 |
CPU パスは「正しさ確認用」で production 非推奨です。ここは以前 WSL2 の CPU で動くか調べたとき、実用にならないと分かった点でもあります。逆に言うと、サーバ（ds4-server）は Metal だけでなく CUDA でも動くので、Apple Silicon 以外でも実用的に立てられます。
一点、antirez 氏 自身が「AI が書いたコードが気に入らないなら、このソフトはあなた向きではない」と README に書いているくらい、開発に強力に AI を使っています。ブログの締めの一文が "AI is too critical to be just a provided service."（AI は、ただ提供されるサービスであるには重要すぎる）で、クラウド API の停止やポリシー変更リスクに対する自衛としてローカルを重視する、という思想がプロジェクト全体に通底しています。
選択的量子化 ─ なぜ 128GB Mac に載るのか
ここが本記事のいちばんの本題です。DeepSeek V4 Flash は、DeepSeek 公式のネイティブ配布形式（FP4+FP8 混合）で約158〜165GB あります。ここで注意したいのは、この約165GB が「何も手を加えていない素の状態」だという点です。つまり素の時点で既に FP4（MoE expert）+ FP8（その他）というかなり低精度の混合になっていて、それでも 165GB あるので、128GB の M5 Max にはそのままでは載りません。総パラメータ 284B を全部 FP4（0.5バイト）にしても約142GB で、これでも 128GB を超えます。だから、素のネイティブ形式のままでは載らず、もう一段の圧縮が要る、というのが出発点です。
そこで Dwarf Star の選択的量子化が約81GB まで縮小します。名前は q2（2bit 系）ですが、単純に全パラメータを2bit へ潰しているわけではありません。
肝は「不均一（非対称）な量子化」です。q2 と呼ばれていても、全パラメータを一律に2bit へ潰すのではなく、また層ごとに感度を測って配分するのでもなく、テンソルの種別・部位ごとに手で設計された精度を割り当てます。antirez 氏 自身は X で、要点をこう表現しています。routed expert だけを激しく潰し（up/gate を IQ2_XXS、down を Q2_K）、それ以外の shared expert・attention projection は温存して品質を保つ、と。実際の GGUF を見ると（ファイル名がそのままスペックになっています）、Q8_0 で残るのは shared expert・attention projection・output head で、router や embedding、compressor、indexer、HC 系の補助ブロックは F16、norm や sinks は F32、という振り分けです。つまり「2bit に潰す部分」と「Q8/F16/F32 で残す部分」が混在していて、その平均としてネイティブ約165GB が約81GB に収まる、という構造です。
なぜこれで成立するのか。ここは前回の記事で MoE の話をしたところと地続きです。MoE では、routed expert がモデル空間の大半を占めますが、各 expert は一部のトークンしか処理しません。つまり「大きいが、1トークンあたりでは一部しか動かない」。そこで、モデルの意思決定に効く部分（router、projection、shared expert）は高精度で温存し、量の多い routed expert を大胆に潰す、という配分が効いてきます。
考え方を図にすると、こういう「感度で仕分けして bit を配る」構図です。
一律に2bit へ潰すのではなく、量は多いが1トークンあたり一部しか通らない routed expert だけを大胆に潰し、少量だが常に効く部分を高精度で残す。これが「非対称」の意味です。
メモリ内訳を面積で見ると、この非対称性が直感的に分かります。ネイティブ約165GB のうち大半を占める routed expert が 2bit に潰れて大きく縮む一方、意思決定系はほぼそのまま残り、合計が約81GB に収まります。
整理すると次のようになります。
| 部分 | 役割 | 精度 |
|---|---|---|
| routed MoE expert（up/gate） | 大多数を占める、一部トークンのみ活性 | IQ2_XXS（約2bit） |
| routed MoE expert（down） | 同上 | Q2_K（2bit） |
| shared expert / attention projection / output head | 意思決定に効く主要部位 | Q8_0（高精度で温存） |
| router / embedding / compressor / indexer / HC 系 | 補助・制御系 | F16 |
| norm / sinks | 補助 | F32 |
この「2bit 量子化はジョークではない」というのが antirez 氏 の主張で、README では「コーディングエージェント下でちゃんと動き、tool を確実に呼ぶ」と述べています。
もう一段の工夫が imatrix（importance matrix、重要度行列）です。これは量子化誤差をどう重み付けしてスケールを選ぶかを、合成的なフォールバックではなく実際の活性化統計に基づいて決める仕組みです。対象は routed MoE パス。128GB 機では、この imatrix 版（q2-imatrix）が推奨ビルドになっています。
imatrix が効くのかどうか、公式リポジトリに定量比較があります。DeepSeek 公式 API の継続100件に対して、target-token の NLL（負の対数尤度、小さいほど良い）で旧版と比べたものです。
| 指標 | 旧 Q4 | Q4 imatrix | 差 |
|---|---|---|---|
| 平均 NLL | 0.177357819 | 0.173895148 | -1.95%（改善） |
| ケース勝率 | 46 | 54 | imatrix 優勢 |
| first-token 一致 | 81 | 83 | imatrix 優勢 |
| 平均 greedy LCP | 11.94 | 12.21 | imatrix 優勢 |
ここで注意しておきたいのが、この数字は q4 で測ったものだという点です。q2 での同種の数値（q2 vs q2-imatrix）は公表されていません。imatrix の仕組み上、Q4 では実行時のテンソル型は変えず（routed expert は Q4_K のまま）誤差の重み付けだけを変えるのに対し、Q2 では IQ2_XXS の gate/up expert に使っていた合成的なフォールバックを実際の活性化統計に置き換えます。つまり q2 のほうが imatrix の効き方は構造的に大きいはずですが、その定量値は一次情報では確認できませんでした。
もうひとつ、「単純に一律で2bit に潰した場合」との比較についても触れておきます。結論から言うと、公式にはそういう配布物も比較ベンチも存在しません。ダウンロードスクリプトが提供するのは q2-imatrix や q2-q4-imatrix（末尾6層だけ q4）などで、いずれも非対称量子化（routed expert だけ2bit、他は Q8）が前提です。「全パラメータを一律2bit にした版 vs 非対称版」という直接比較の数字は無く、antirez 氏 の主張は定性的なもの（一律に潰すと構造化出力が壊れがちだが、非対称なら tool calling まで実用的に動く）に留まります。ここは実機が来たら、自分で一律版を作って比べてみたい部分です。
KV キャッシュ側も工夫されています。DeepSeek V4 自体が Hybrid Attention（圧縮 KV キャッシュ）を持っていて、ds4 はさらに実装レベルで、KV キャッシュを RAM だけでなくディスクに永続化します。ここは後述しますが、Claude Code のような巨大な初期プロンプトを毎回 prefill し直さずに済む、という実用上おいしい設計です。
品質劣化の程度については、正直に書いておきます。antirez 氏 は「DeepSeek v4 Flash も PRO も 2bit 量子化に非常によく耐える」と述べていますが、「MMLU/HumanEval で full Q4 の 95-98% を維持」「perplexity 劣化 3-5%」といった具体数値は、私が確認できた範囲では一次情報で裏が取れませんでした（主に二次情報の主張）。参考として、別ルート（Unsloth）では「expert を IQ2_XXS に再量子化すると 30% 超の RMSE 誤差」との指摘もあり、2bit expert 化には相応の誤差が伴います。なので「品質は保たれる」はタスク依存と理解すべきで、特に SV/UVM のような厳密性が要る用途では自前ベンチが必須、というのが今のところの結論です。
DeepSeek V4 Flash モデル自体
エンジンと量子化の話が続いたので、載せるモデル自体も整理しておきます。
- リリース: 2026年4月24日。オープンウェイト（DeepSeek 独自ライセンス）。開発元は中国の DeepSeek。
- 構成: 総 284B パラメータ / 活性 13B の MoE。router は top-6 / 256 routed expert + 1 shared expert。43層。1M トークンのコンテキスト（ただしこれはモデルの理論上限で、128GB 機で実際に回せるのは後述のとおり 100〜300k 程度）。
- ネイティブ形式: FP4（MoE expert）+ FP8（その他）の混合。
Flash と PRO の違いを並べておきます。
| 項目 | V4 Flash | V4 PRO |
|---|---|---|
| 総パラメータ | 284B | 1.6T |
| 活性パラメータ | 13B | 49B |
| 層数 | 43 | 61 |
| routed expert | 256 / 層 | 384 / 層 |
| ローカルの現実味 | 128GB Mac で q2 が載る | 256GB〜512GB 級が必要 |
| 位置づけ | 小さいフットプリントで PRO に迫る（Think Max） | 知識・最難関タスクで上 |
128GB という手持ちの制約から見ると、Flash が「載せられる上限」で、PRO はもう一段上のマシンの話、という切り分けになります。
ここで重要なのが、前回の記事でも書いた「メモリ フットプリントは総パラメータ数（284B → 量子化後 81GB）で決まり、decode 速度は活性パラメータ数（13B）で決まる」という非対称性です。「大きくて容量は食うが、1トークンで動くのは一部だから速い」という MoE の性質が、Apple Silicon の「容量は大きいが帯域は中位」という特性と噛み合う。DwarfStar が 128GB Mac をターゲットにできるのは、この噛み合わせがあるからです。
容量と速度を別々のパラメータ数が決める、という点が MoE の勘所です。dense モデルだと「容量 = 計算量」で両方が同じ数字に縛られますが、MoE は容量を大きくしても計算量（＝ decode の重さ）は活性分しか増えない。だから 284B という総量を 128GB に押し込みつつ、13B 相当の速度で回せるわけです。
ベンチマーク性能（DeepSeek の自己申告値なので、独立検証とは区別すべきですが）としては、V4-Flash の Max モードで SWE-bench Verified 79.0%、MMLU-Pro 86.2% あたりが挙げられています。ただし Flash は Non-Think / High / Max の3モードで数値がかなり変わり、たとえば Non-Think では SWE-bench Verified 73.7%、MMLU-Pro 83.0% です。API 価格も入力 $0.14 / 出力 $0.28（100万トークン）と非常に安く、「128GB 以下で走らせられる準フロンティア級」という位置づけでコミュニティに受け止められています。
性能とハードウェア要件
ここからは実際の速度と要件です。まず容量から。
- q2（約81GB）: 128GB 機が公式の基準。コミュニティでは 96GB 機で q2-imatrix を動かした報告もあり。
- q4: 256GB 以上が必要。128GB 機で q4 を最初に選んではいけない（ランタイムオーバーヘッド込みで大きすぎる）。
- フルコンテキスト 1M: モデルの理論上限は 1M だが、フルに使うには追加で約26GB（圧縮 indexer だけで約22GB）必要。q2 本体81GB に積むと 128GB はほぼ埋まるので、128GB 機では 100〜300k が現実的な上限。しかも後述のとおり decode 速度は 1M で約8 t/s まで落ちるため、容量・速度の両面で 1M は「設定はできるが実運用は挑戦的」という位置づけ（antirez 氏自身も当初 1M は合成テスト段階と述べている）。
- SSD streaming: 96GB 未満でも動かせる Metal 専用の容量モード。非 routed 重みは常駐、routed expert はキャッシュ + ミス時に GGUF からロード。
128GB の枠に対して、この収支を積み上げで見ると余裕がどれだけあるか分かります。q2 本体が約81GB、そこにランタイムと作業用 KV、コンテキストが乗ります。q4（約153GB）だと本体だけで枠を超えるのが、q2 を選ぶ理由です。
速度については、公式 README の Speed テーブルを見ます。M3 Max 128GB、M5 Max 128GB、M3 Ultra 512GB、さらに PRO 行や DGX Spark 行が載っています（--ctx 32768 --nothink、greedy、単発 CLI）。
| マシン | Quant | プロンプト | Prefill | Generation |
|---|---|---|---|---|
| MacBook Pro M3 Max 128GB | q2 | short | 58.52 t/s | 26.68 t/s |
| MacBook Pro M3 Max 128GB | q2 | 11709 tokens | 250.11 t/s | 21.47 t/s |
| MacBook Pro M5 Max 128GB | q2 | short | 87.25 t/s | 34.27 t/s |
| MacBook Pro M5 Max 128GB | q2 | 11707 tokens | 463.44 t/s | 25.90 t/s |
| Mac Studio M3 Ultra 512GB | q2 | short | 84.43 t/s | 36.86 t/s |
| Mac Studio M3 Ultra 512GB | q2 | 11709 tokens | 468.03 t/s | 27.39 t/s |
| Mac Studio M3 Ultra 512GB | q4 | 12018 tokens | 448.82 t/s | 26.62 t/s |
棒グラフにすると、prefill と decode で各マシンの傾向がはっきり分かれます。
注目したいのが M5 Max 128GB の行で、短文で prefill 87.25 / generation 34.27、11.7k トークンで prefill 463.44 / generation 25.90 と、M3 Max 128GB を prefill・generation とも明確に上回っています。特に prefill が M3 Max の 250 → 463 とほぼ倍近いのが目を引きます（後述の Neural Accelerator）。
補足として、antirez 氏 はブログで「M5 Max 128GB は 2bit 量子化で ~500 t/s prefill、~35-40 t/s decode。6-7k ドルという価格を考えると現状もっともお得な選択肢の一つ」とも述べています。README の実測値（463 / 25.90）よりブログの概括値（~500 / 35-40）の方が高めですが、これは測定方法の違い（チャンク prefill のスイープ vs 単発 CLI、短文か長文か）で説明できる範囲です。コミュニティ実測（note の sweep、q2-imatrix）では、短文で generation 約31 t/s、200K で約22.6 t/s、1M で約8 t/s と、長文で減衰する曲線が報告されています。
この減衰を折れ線で見ると、コンテキストを伸ばすほど generation が落ちていく様子が分かります。検証で長文を投入する場合、decode 速度がどのあたりまで許容できるかの目安になります。
参考として他プラットフォームも並べておきます（いずれも現 README のテーブルに含まれています）。
| マシン | Quant | Prefill | Generation | メモ |
|---|---|---|---|---|
| M3 Ultra 512GB で V4 PRO | q2 | 138.82 t/s | 9.56 t/s | 32k コンテキスト |
| DGX Spark（GB10） | q2 | 343.81 t/s | 13.75 t/s | 7047 トークン |
ここは前回の記事の「prefill vs decode」の話がそのまま効いてきます。decode（トークン生成）はメモリ帯域律速で、M5 Max の帯域は M4 Max 比 +約12%（546→614 GB/s）なので、実測でも decode は概ね +12〜28% 程度の伸び。一方 prefill（プロンプト処理）は演算律速で、M5 世代は各 GPU コアに Neural Accelerator を内蔵しています。Apple の「最大4倍」はあくまで AI 向けピーク GPU compute の主張であって、ds4 の prefill 速度が常に4倍になるという意味ではありません。ただ ds4 の実測でも、M5 Max は decode より prefill 側で大きく伸びており（上の表で prefill が M3 Max 比ほぼ倍、decode の伸びは穏やか）、長文投入タスクでは恩恵が出やすいと考えられます。
検証タスクは「大きな入力を読ませて、比較的短い答えを書かせる」ものが多いので、prefill 支配になりがちです。そこに M5 Max の強みが乗る、というのがこの図の含意です。
つまり、大きな RTL コードベースや仕様書、UVM テストベンチをコンテキストに投入する検証タスクのように prefill が支配的なワークロードでは、M5 Max の恩恵が体感で最も大きい。しかも一度 prefill したコンテキストは、ds4 のディスク KV キャッシュで再利用できるので、以降のセッションのコールドスタートコストがほぼゼロになります。この2つが組み合わさるのが、DwarfStar × M5 Max の一番おいしいところだと思っています。
ただし、この再利用には条件があります。KV キャッシュの復帰はハッシュの完全一致ではなく、プレフィックス（先頭からの共通部分）の一致で効きます。各トークンの KV 値はそれ以前のトークンだけに依存する（causal attention）ため、「先頭から同じところまで」は使い回せて、初めて食い違ったトークン以降だけ再計算になる、という仕組みです。
つまり、既存のコンテキストの末尾に質問を継ぎ足す分には、プレフィックスが変わらないので再利用が効きます。一方、システムプロンプトの一部を書き換える、履歴の途中に何か挿入する、古い履歴を削って詰める（コンテキスト圧縮）といった「先頭側を触る」操作をすると、変更点以降のプレフィックスが全部ずれて、そこから先の KV は無効化され再 prefill が走ります。ハッシュが変わって全滅する、というのはこのケースです。
これはエージェント運用で現実的に効いてきます。ツールの実行結果を会話の途中に差し込む構成だと、差し込むたびに以降の KV が無効になり再計算が走る。逆に、大きな仕様書や RTL を最初に一度入れて以降は末尾に問答を足すだけ、という構成なら、初回の prefill コストを1回払えば以降はほぼ再利用で済みます。ちなみに ds4 の README には、履歴を再構築する際にトークン列がバイト単位で一致するようにして KV プレフィックスのミスマッチを防ぐ「exact DSML replay」という仕組みへの言及があります。裏を返せば、プレフィックスの一致はそれだけ壊れやすく、明示的に守る必要があるものだ、ということです。
サーバ API とエージェント連携
自分の普段の使い方（OpenCode を OpenAI 互換エンドポイントで叩く）に直結するのがここです。ds4-server は次のエンドポイントを提供します。
-
GET /v1/models（deepseek-v4-flash/deepseek-v4-proのモデル名を返す） -
POST /v1/chat/completions（OpenAI 形式） -
POST /v1/completions（legacy） -
POST /v1/responses（OpenAI Responses 形式、Codex CLI 向け） -
POST /v1/messages（Anthropic 形式、tool_use ブロック対応、Claude Code 系クライアント向け）
OpenAI 系（chat/completions・responses）と Anthropic 系（messages）の両方を備えています。なお deepseek-v4-flash / deepseek-v4-pro というモデル名は互換用の alias で、エンドポイントやモデル名を指定して Flash / PRO が切り替わるわけではありません。実際にどちらが使われるかは、起動時に -m でロードした GGUF で決まります。
両 API とも SSE ストリーミングに対応し、thinking モードは推論部分が別チャンネルで配信されて最終テキストに混ざりません。tool スキーマは DeepSeek の DSML tool 形式にレンダリングされ、生成された tool call は OpenAI tool call に逆マップされます。README には opencode、Pi、Claude Code、Codex CLI それぞれの具体的な設定例まで載っています。
自分の OpenCode 構成はそのまま左の OpenAI 互換の口に挿さる想定です。注意点は図中でオレンジにした推論ワーカーで、ここが単一かつ直列という制約です。
一点だけ注意があって、リクエストは単一ワーカーで直列化されます。並列 tool call を多用するエージェントだと、順番待ちがボトルネックになりうる。ここは実際に自分のエージェント構成で流してみて確かめる必要がありそうです。
エンジン内蔵の ds4-agent という統合コーディングエージェントもあり、こちらはソケット境界なしで内部から直接推論を制御します。セッション = オンディスク KV キャッシュそのもので、/save /list /switch でセッション管理ができ、フル KV セッションは prefill なしで復帰します。
データ主権とライセンス
これは以前から気にしている論点なので、切り分けて書いておきます。
エンジン（ds4）は MIT、モデル（DeepSeek V4 Flash）も MIT のオープンウェイトですが、開発元は中国の DeepSeek です。私はセンシティブなコードには西側ライセンス（Apache-2.0、MIT）のモデルを好む方針ですが、ここは (1) エンジンと (2) モデルの出自を分けて評価するのが妥当だと思っています。
完全ローカル実行なので、プロンプト・生成物・KV キャッシュはすべて自分のマシンに留まり、外部 API へのデータ送信もログ保持もレート制限もありません。機密性の高い設計データ・検証データ（RTL、テストベンチ、社内仕様）を扱うロジック検証ワークフローでは、これが本質的な利点です。「実行時に外部通信が発生しない」という意味でのデータ主権は確保される。
ただし、オープンウェイトであっても学習データや RLHF パイプラインは非公開で、DeepSeek 系モデルには中国関連の話題での検閲的な振る舞いが学術的に報告されている点は、モデルのバイアスとして別途留意しておくべきです（ただしこれらの研究の多くは V3 / R1 を対象にしたもので、V4 Flash 固有の検証はまだ限定的です。V4 でも同様の傾向があるかは、自分で確かめる余地があります）。「ローカルだからデータは安全」と「モデル自体のバイアス」は別問題、という整理になります。
M5 Max が来たらやること
備忘を兼ねて、到着後の手順を書いておきます。
まずセットアップ。ビルド要件は Xcode Command Line Tools、curl、約80GB 以上の空き容量です。
git clone https://github.com/antirez/ds4
cd ds4
./download_model.sh q2-imatrix # 128GB 機の推奨ビルド（約81GB）
make
ダウンロードモードは imatrix 版が推奨で、いくつか種類があります（q2-imatrix、末尾6層だけ q4 化する q2-q4-imatrix、q4-imatrix、PRO 用の pro-q2-imatrix や層分割の pro-q4-layers00-30 / pro-q4-layers31-output など）。128GB 機なら素の q2 ではなく q2-imatrix を選びます。モード名は変わりうるので最新のモード名は README で確認してください。
起動は、まずスモークテストしてから、サーバをディスク KV キャッシュ有効で立てる流れを想定しています。
# CLI ワンショット
./ds4 -p "Explain UVM factory override in one paragraph."
# サーバ（OpenAI/Anthropic 互換、ディスク KV キャッシュ有効）
./ds4-server --ctx 100000 --kv-disk-dir ~/.ds4/kv --kv-disk-space-mb 65536
128GB 機での方針は、q2-imatrix を使い、コンテキストは 100〜300k に抑え（1M フルは約26GB 食うので過大）、ディスク KV キャッシュを大きめ（64GB 程度）に取って長いセッションでプレフィックスが毎回 evict されないようにする、--ctx はエージェント側の上限と揃える、q4 は選ばない、というところです。
その上で、検証エンジニアとしての実測計画は次のとおりです。
- 自分の実 RTL / UVM コードで「コード生成」「バグ説明」「テストベンチ雛形生成」を流す。
- (a) tool-call の信頼性、(b) SV コードの構文 / プロトコル正確性、(c) 62k〜100k 級コンテキストでの decode 速度、を自前で計測する。
- 公式 README の M5 Max 行（短文で generation 約34 t/s、11.7k トークンで約26 t/s）やコミュニティ報告（長文で減衰）と、自分の数値が整合するか確認する。
判断の分岐点も決めておきます。
以前の検証で感じた「protocol の正確さは活性の少ない MoE より dense が有利」という傾向どおりなら、コード正確性が足りない場面では素直に dense 側へ寄せます。128GB あれば「MoE で速く回す」と「dense で正確に書かせる」を用途で使い分けられるので、DwarfStar はその「速く広く」側の主力候補、という位置づけで検証するつもりです。
わかっていること・わかっていないこと
この記事も推定と未確認を含むので、層別しておきます。
| 信頼度 | 内容 |
|---|---|
| 公式確認済み | ds4 は MIT、DeepSeek V4 Flash 優先＋PRO 対応、Metal / CUDA / ROCm 対応、選択的量子化のレシピ（routed expert を IQ2_XXS/Q2_K、shared expert・attention projection・output head を Q8_0、router や補助は F16/F32）、q2 約81GB、サーバの各エンドポイント（chat/completions・responses・messages） |
| 公式（README）実測 | M3 Max / M5 Max / M3 Ultra の Speed テーブル、Q4 imatrix の NLL -1.95% 改善 |
| 作者評価・コミュニティ報告 | antirez 氏 ブログの ~500 prefill / 35-40 decode（README 実測は 463 / 25.90）、長文での減衰曲線 |
| 未確認・裏取れず | full Q4 比 95-98% 維持、perplexity 3-5% 劣化、SV/UVM タスクでの実用精度、V4 Flash 固有の検閲挙動 |
正直に言っておくべき点を挙げます。
- M5 Max は README の Speed テーブルに載りましたが、これは単発 CLI の値です。自分の検証タスク（長文 prefill + ディスク KV キャッシュ + tool-call）での体感は、届いたら自分で測ります。
- 2bit 量子化の品質はタスク依存です。「保たれる」という主張と、「IQ2_XXS で 30% 超 RMSE」という指摘が両方あり、SV/UVM のような厳密性が要る用途ほど自前検証が要ります。
- ds4 は自前配布の GGUF 専用で、他所の DeepSeek/GGUF は動きません。V4 Flash / PRO 以外（antirez 氏は DwarfStar 内で別モデルの実装にも言及）や DeepSeek V5 等が出ても、対応が入るまで走らない。「特化」の裏返しです。
- サーバは単一ワーカー直列化。並列 tool-call を多用するエージェントでは、この直列化がボトルネックになりうる。
- antirez 氏 自身が「alpha/beta 品質」と明言しています。distributed inference など新機能は特に発展途上です。
- この分野は README が日々更新されます。数値・フラグ・モード名は、読む時点ではさらに進んでいる可能性があるので、最新の README を正とみなしてください。
- DwarfStar の q2 は「層ごとの自動感度最適化」ではなく、現時点ではテンソル種別ごとに手で設計された非対称量子化レシピに、routed expert 向けの imatrix を組み合わせたもの、と理解するのが安全です。
まとめ
- DwarfStar（ds4）は、antirez 氏 が作った DeepSeek V4 Flash 優先＋PRO 対応のネイティブ推論エンジン（C 中心、MIT、Metal / CUDA / ROCm）。「意図的に狭い」設計で、モデルロードからサーバ API、コーディングエージェントまで内包する。
- 「DeepSeek V4 Flash の Dwarf Star 版」という固有モデル名は無く、エンジン（DwarfStar）・量子化手法（選択的量子化）・重み（GGUF）の三層で理解するのが正確。
- 選択的量子化の肝は非対称配分。量の多い routed expert を IQ2_XXS/Q2_K に潰し、shared expert / attention projection / output head を Q8_0、router や補助ブロックを F16/F32 で残すことで、大きなモデルを約81GB に凝縮して 128GB Mac に載せる。層ごとではなくテンソル種別ごとの手設計レシピ。128GB 機の推奨は q2-imatrix。
- フットプリントは総パラメータ（284B）、decode 速度は活性パラメータ（13B）で決まる MoE の非対称性が、Apple Silicon の「大容量・中帯域」と噛み合う。
- 速度は M3 Max 128GB q2 で短文 decode 26.68 t/s、M5 Max 128GB q2 で短文 decode 34.27 t/s / prefill 87.25 t/s（いずれも README 実測）。prefill が速い M5 Max は、大きなコンテキストを投入する検証用途で体感差が出る。ディスク KV キャッシュとの合わせ技が効く。
- サーバは OpenAI/Anthropic/Responses 互換で、OpenCode や Claude Code、Codex CLI にそのまま繋がる。ただし単一ワーカー直列化に注意。
- データ主権はローカル実行で確保されるが、モデルの出自（中国製）とバイアスは別問題として切り分ける。
- 品質・精度はタスク依存。SV/UVM のような厳密性が要る用途は、届いたら自分の RTL/UVM コードで tool-call 信頼性とコード正確性を実測して判断する。ここは実機が来たら更新します。
Appendix A: 一般的な GGUF 量子化とのサイズ比較
ここまでは antirez の Dwarf Star q2（約81GB、ds4 専用 GGUF）を見てきましたが、DeepSeek V4 Flash には Unsloth の UD（Unsloth Dynamic）量子化のような、汎用の llama.cpp 系 GGUF も存在します。同じモデルを別ルートで量子化したものが、128GB Mac にどう載るかを比較しておきます。
先に前提を整理しておきます。GGUF 量子化に「Mac 専用サイズ」というものは存在しません。Dwarf Star が「Mac 向け」と銘打たれていたのは配布側の売り文句で、Unsloth の UD 量子化は同じファイルが Mac でも Windows でも動きます。Mac では Metal で全層を GPU に載せる（-ngl 99）だけで、ファイル自体は共通です。なので実際の判断は「M5 Max 128GB のユニファイドメモリにどのサイズが収まるか」になります。
unsloth/DeepSeek-V4-Flash-GGUF の UD 量子化のサイズを、128GB Mac に載るかで並べると次のとおりです（WIP なので今後増減あり）。
| 量子化 | サイズ | 128GB Mac |
|---|---|---|
| Dwarf Star q2（ds4 専用・参考） | 約81 GB | 余裕あり |
| UD-IQ1_S | 82.5 GB | 余裕あり |
| UD-IQ1_M | 86.9 GB | 余裕あり |
| UD-IQ2_XXS | 90.9 GB | 収まる |
| UD-IQ2_M | 90.9 GB | 収まる |
| UD-Q2_K_XL | 96.8 GB | 収まる |
| UD-IQ3_XXS | 103 GB | タイト（KV 余地少） |
| UD-IQ3_S | 117 GB | ほぼ限界（短文脈のみ） |
| UD-Q3_K_M / XL | 129 GB | 不可 |
| UD-IQ4_XS / NL | 138 GB | 不可 |
| UD-Q4_K_XL | 155 GB | 不可 |
| UD-Q8_K_XL | 162 GB | 不可（ロスレス版） |
Dwarf Star q2 だけは ds4 専用 GGUF で他は汎用の UD 量子化なので列の性質が違いますが、サイズ感の比較用に先頭に置きました。非対称レシピの Dwarf Star q2（約81GB）が、UD 系のどの 2bit 版（90GB 台）よりも小さく収まっているのが分かります。
Mac のユニファイドメモリは既定だと GPU が使える分が全体の7割前後に制限されるので、128GB でもそのままだと 90GB 台後半が実質の壁です。sudo sysctl iogpu.wired_limit_mb=<値> で上限を上げれば 115〜120GB あたりまで押し込めますが、OS 用に 8〜10GB は残す前提です。それを踏まえると、快適に使えて KV/コンテキストの余地も残るのは 2bit まで。UD-Q2_K_XL（96.8GB）が品質と余裕のバランスで実質の上限、もう少し文脈長が欲しければ UD-IQ2_M（90.9GB）、という並びになります。IQ3_XXS（103GB）以上は載っても KV がほぼ取れず、Q3_K_M（129GB）からは不可です。
ここは Dwarf Star q2（約81GB）と見比べると示唆的です。Dwarf Star は routed expert だけを 2bit に潰す非対称レシピで 81GB に収めているので、UD 系の 2bit 帯（90〜97GB）より一段小さく、その分 KV/コンテキストの余地を稼げます。一方 UD 系は汎用 llama.cpp で動く（ds4 に縛られない）という自由度があります。どちらを取るかは、ds4 の速度・エージェント統合を取るか、ランタイムの自由度を取るか、という選択になります。
正直に押さえておきたい点が2つあります。
ひとつ、メモリの天井は Windows 機とほぼ同じ 128GB クラスなので、Mac に替えても選べる量子化帯は変わりません。サブ Q4 しか載らない状況は同じで、FP4 ネイティブなこのモデルでサブ Q4 の品質が読めない問題も、Mac では解決しません。Mac の利点は容量ではなく速度です。
もうひとつ、その速度の利点も、このモデルに関しては割り引いて考えた方がよいです。ユニファイドメモリの帯域（500GB/s 級）は本来 DDR5 デュアルチャネル（80GB/s 級）を圧倒しますが、V4 のデコードは帯域ではなく indexer / sinkhorn 等のカスタムカーネルで計算律速になるため、帯域差がそのまま速度差に化けるわけではありません。とはいえ Metal 版のカスタムカーネルは実装済みで、Apple Silicon の GPU 計算は強いので、CPU 律速だった Windows 機よりは体感でかなり速くなるはずです。
ちなみに 162GB のロスレス Q8 に手を出したいなら、128GB では無理で、192GB 以上の Mac が要ります。いまの構成だと 2bit 帯で運用する、が結論になります。
Appendix B: Redis とは
本文で ds4 の作者 antirez を「Redis 作者」と紹介しましたが、Redis を知らない読者向けに補足しておきます。
Redis（レディス）は、データをディスクではなくメモリ上に置いて超高速に読み書きする、オープンソースのデータストアです。一言でいうと「非常に高速なキーバリューストア」で、key を指定して value を出し入れする辞書のような仕組みを、ネットワーク越しに提供します。名前は REmote DIctionary Server の略です。
普通のデータベース（MySQL や PostgreSQL など）がデータをディスクに保存するのに対し、Redis は基本的にメモリ上でデータを扱うため、読み書きが桁違いに速い（マイクロ秒〜ミリ秒オーダー）のが最大の特徴です。単純な文字列だけでなく、リスト、集合、ハッシュ、ソート済み集合といった多様なデータ構造を扱えるのも特徴です。
代表的な用途はキャッシュです。Web サービスで DB への問い合わせ結果を Redis に一時的に置き、次回は Redis から即座に返すことで負荷を下げ応答を速くします。ほかにセッション管理、リアルタイムのランキング、メッセージキュー、レート制限のカウンタなど、「速さが要る一時的なデータ」を扱う場面で広く使われています。
作者の Salvatore Sanfilippo（antirez）が2009年に Redis を作り、以後11年ほど中心的に開発しました。Redis は世界中の Web サービスの裏側で動いている定番ソフトで、antirez は堅実で高速なソフトウェアを書くプログラマとしてエンジニアの間で広く知られています。
なぜこの補足を入れたかというと、ds4 の設計思想が Redis 譲りだからです。本文で ds4 を「C 言語で書かれた、狭く一つのことに集中した設計」と評しましたが、これは Redis 以来の「小さく、単一目的で、C で高速に書く」というスタンスがそのまま AI ツールに持ち込まれたものです。「Redis を作った人が、今度は DeepSeek をローカルで動かすエンジンを作った」という文脈を押さえると、ds4 の「意図的に狭い」設計がなぜそうなっているのかが腑に落ちると思います。
なお半導体・EDA の文脈でも、シミュレータやツールチェーンのバックエンドでキャッシュ層に Redis が使われることがあり、名前だけは見たことがある方もいるかもしれません。
Appendix C: なぜ今どき C 言語で書くのか
ds4 が C（＋Metal/CUDA）で書かれていると聞くと、「なぜ今どき C なのか、Rust や Zig ではないのか」と思うかもしれません。ここも触れておきます。
理由は大きく2つに分けられます。ひとつは antirez 個人の事情と技術的合理性、もうひとつは推論エンジンというソフトの性質です。
antirez 側の理由は、おそらく次の3点です。antirez は長年 C を書いてきて（Redis も C）非常に慣れていること、C は性能が予測可能なこと、Metal/CUDA バインディングのための ABI が素直なことです。分解すると次のようになります。
- 慣れ: 最も速く確実に書ける言語が C。新しい言語への学習コストを払う動機がない。ds4 は GPT-5.5 の支援を受けつつ短期間で書き上げられており、この速度には「手に馴染んだ言語」であることが効いている。
- 予測可能な性能: C は抽象化レイヤーが薄く、メモリレイアウトや実行挙動が透明。ランタイムや GC（ガベージコレクタ）が挟まらないので、メモリ帯域とキャッシュ効率が性能を直接決める推論エンジンでは、この予測可能性が武器になる。
- GPU バインディング: ds4 の実体は Metal / CUDA の GPU カーネルを叩くこと。Metal（Objective-C 経由）や CUDA（C/C++ API）は C から直接呼ぶのが最も素直。実際、執筆時点のリポジトリも C / Objective-C / Metal が中心で、GPU 層と地続きに C が使われている。
より本質的な答えは、推論エンジンというソフトの性質にあります。LLM 推論の性能は、ほぼ全てがメモリ帯域と GPU カーネルの効率で決まります。抽象度の高い言語で書ける「ロジックの複雑さ」ではなく、「ハードウェアをどれだけ無駄なく叩くか」が勝負なので、この領域ではハードに近い低レベル言語が今でも王道です。対抗馬の llama.cpp も C/C++ ですし、CUDA 自体が C/C++ の世界です。むしろ「今どき」だからこそ、AI の重い数値計算は低レベル言語に回帰している、とも言えます。
ds4 の「意図的に狭い（1モデル特化）」設計とも噛み合います。汎用フレームワーク（Python の PyTorch 等）は多数のモデルに対応するため抽象化の層を厚く持ちますが、その層自体がオーバーヘッドになります。1モデルだけを最速で回すと割り切れば、抽象化を捨てて C で直書きするのが最も速い、という判断です。
半導体の検証をやっていると、この感覚は馴染みやすいと思います。SPICE シミュレータや高速化した RTL シミュレータのコアが今も C/C++ で書かれ、性能クリティカルな部分ではメモリレイアウトやキャッシュを意識して手で最適化するのと、まったく同じ発想です。流行りの言語で新しさを見せるより、枯れて確実な道具で目的を果たす、という選択ですね。
Appendix D: ディスクリート GPU + DDR5 機との比較（RTX 4060 8GB / RTX 5060 Ti 16GB）
Appendix A で「Windows 機とメモリ天井は同じ 128GB クラスで、Mac の利点は容量ではなく速度」と書きました。ここをもう少し具体的に、自分の現用機（Ryzen 9 7950X / RTX 4060 8GB / 128GB DDR5）と、その素直なアップグレード先である RTX 5060 Ti 16GB を、M5 Max 128GB と同じ土俵で並べてみます。
先に前提の区別をひとつ。ディスクリート GPU 機では、本文で扱った ds4 の Dwarf Star q2 は実質使えません。ds4 の CUDA バックエンドは DGX Spark（GB10）のような大容量コヒーレントメモリを想定しており、96GB 未満向けの SSD streaming モードは Metal 専用だからです。8GB / 16GB の VRAM に約81GB は載らないので、dGPU 機での現実的な経路は llama.cpp + Unsloth の UD-IQ2_M（約91GB、Appendix A のサイズ表を参照）を --n-cpu-moe で回す構成になります。つまり以下の表は、dGPU 側が「llama.cpp + UD-IQ2_M」、M5 Max 側が「ds4 + Dwarf Star q2」で、列の性質が違う点に注意してください。
スペック比較
| 項目 | RTX 4060 8GB（現用） | RTX 5060 Ti 16GB | M5 Max 128GB |
|---|---|---|---|
| アーキテクチャ | Ada Lovelace (AD107) | Blackwell (GB206) | Apple M5 Max（Fusion / 2ダイ, N3P） |
| 演算ユニット | 3,072 CUDA コア | 4,608 CUDA コア | 40 コア GPU（各コアに Neural Accelerator）+ 16 コア Neural Engine |
| メモリ | 8GB GDDR6（専用 VRAM） | 16GB GDDR7（専用 VRAM） | 128GB ユニファイド LPDDR5X |
| メモリ帯域 | 約 272 GB/s | 約 448 GB/s | 約 614 GB/s |
| Matmul アクセラレータ | 第4世代 Tensor（FP8 ネイティブ） | 第5世代 Tensor（FP4 ネイティブ） | GPU コア内蔵 Neural Accelerator（Metal 4 Tensor API） |
| 消費電力 | 115W（GPU 単体） | 180W（GPU 単体） | ノート SoC 全体で数十 W 級 |
| V4 Flash（約81〜91GB）が載るか | 不可（8GB） | 不可（16GB） | 可（ユニファイドに丸ごと常駐） |
速度比較
| マシン / 実行系 | モデル・量子化 | Decode | Prefill | 出典 |
|---|---|---|---|---|
| Ryzen 9 7950X + RTX 4060 8GB + 128GB DDR5 / llama.cpp | UD-IQ2_M（約91GB） | 約 4〜8 t/s | 遅い | 推定（未実測） |
| 同上 + RTX 5060 Ti 16GB / llama.cpp | UD-IQ2_M（約91GB） | 約 6〜11 t/s | やや改善 | 推定（未実測） |
| MacBook Pro M5 Max 128GB / ds4 | Dwarf Star q2（約81GB） | 34.27 t/s（短文）/ 25.90 t/s（11.7k） | 87.25 / 463.44 t/s | README 実測 |
dGPU 側の decode は、DDR5-6000 デュアルチャネルの実効帯域を 60〜70 GB/s 程度と仮定した推定値です。DDR5 のクロックや枚数で上下します。
なぜディスクリート GPU では速くならないのか
理由は、約91GB のモデルが 8GB / 16GB の VRAM に載りきらないからです。大半が DDR5 側に常駐し、--n-cpu-moe（または -ot）で routed expert を CPU offload する構成になります。1トークンあたり読むのは活性 13B 分（UD-IQ2_M で約 4〜4.5GB）ですが、その大半が遅い DDR5 経由になるため、律速は DDR5 帯域です。GPU をいくら速くしても、この壁は動きません。
16GB に増やしても効きが薄い理由
「エキスパートが VRAM に入れば速くなるのでは」と思いがちですが、ここは MoE の性質で直感に反します。DeepSeek のルーターは 256 の routed expert を均等利用するよう学習されており、生成中は事実上ほぼ全部が満遍なく引かれます。熱い少数エキスパートという偏りがありません。
16GB に載るのは約91GB のうち 12% 程度なので、1トークンで引く 6 エキスパートのうち VRAM 由来は平均 0.7 個ほど、残り 5.3 個は DDR5 由来です。4060 → 5060 Ti で遅い経路の割合が約 96% → 約 88% に減るだけで、体感は +2〜4 割にとどまります。
優先して VRAM に置くべきは、毎トークン確実に触る部分（attention 層・shared expert・router・KV キャッシュ）であって、均等アクセスの routed expert ではありません。--n-cpu-moe が routed expert を CPU 側へ追い出す設計になっているのは、このためです。
M5 Max だけ土俵が違う理由
M5 Max では 81〜91GB を丸ごと 614 GB/s のユニファイドメモリに常駐させられるので、ルーターがどのエキスパートを引いても遅い経路（DDR5）を踏みません。dGPU 側の「GPU が速くても RAM が壁」という構図そのものが消えます。5060 Ti への換装（4060 比 +2〜4 割）とは、比較の土俵が違うわけです。
ただし本文で触れたとおり、V4 の decode は indexer / sinkhorn 等のカスタムカーネルで計算律速になる面があり、帯域差がそのまま速度差に化けるわけではありません。それでも Metal 版カーネルは実装済みで、CPU 律速だった Windows 機よりは体感でかなり速くなるはずです。
どのマシンでどの組み合わせを選ぶか
| マシン | V4 Flash（284B MoE）を回すなら | 16GB VRAM が本当に生きる用途 |
|---|---|---|
| RTX 4060 8GB + DDR5 | llama.cpp + UD-IQ2_M（RAM 律速、数 t/s） | — |
| RTX 5060 Ti 16GB + DDR5 | 同上（4060 比 +2〜4 割、壁は同じ） | 24〜32B 級 dense を Q4 で全量 VRAM 常駐（40〜70 t/s 級） |
| M5 Max 128GB | ds4 + Dwarf Star q2（本命、25〜35 t/s） | 大容量 MoE をユニファイドに常駐 |
要するに、RTX 5060 Ti への換装は「V4 Flash 単体では投資対効果が薄い」という結論になります。16GB が本当に生きるのは、全部 VRAM に載る中規模 dense モデル（24〜32B を Q4）を回すときで、それは別の話です。V4 Flash を速く回す目的に限れば、答えはユニファイドメモリ側にあります。
なお dGPU 機の数値は、DDR5 帯域からの推定で自分ではまだ実測していません。実機（M5 Max）が来たら、現用の 4060 機でも UD-IQ2_M を --n-cpu-moe で実測し、この推定と突き合わせて更新するつもりです。
参考にしたリンク
- antirez/ds4（GitHub、README・ビルド・起動オプション）: https://github.com/antirez/ds4
- ds4 imatrix ツールの README（imatrix の対象・NLL 改善）: https://github.com/antirez/ds4/blob/main/gguf-tools/imatrix/README.md
- antirez「A few words on DS4」（開発経緯・非対称量子化レシピ・思想）: https://antirez.com/news/165
- antirez「Distributing LLM inference in DwarfStar」（M5 Max 評価・分散推論）: https://antirez.com/news/167
- antirez（X、2bit 選択的量子化のレシピ）: https://x.com/antirez/status/2048885632869523869
- antirez/deepseek-v4-gguf（Hugging Face、GGUF 配布・ダウンロードモード）: https://huggingface.co/antirez/deepseek-v4-gguf
- deepseek-ai/DeepSeek-V4-Flash（Hugging Face、モデル構成・ライセンス）: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash
- DeepWiki: Getting Started（ビルド・要件の整理）: https://deepwiki.com/antirez/ds4/1.1-getting-started
- Entrpi/ds4-on-spark（DGX Spark でのベンチ・ルーフライン解析）: https://github.com/Entrpi/ds4-on-spark
- MindStudio「How to Run DeepSeek V4 Flash Locally ... with Dwarf Star」（選択的量子化の解説・二次情報）: https://www.mindstudio.ai/blog/run-deepseek-v4-flash-locally-dwarf-star-macbook
- Techstrong.ai「Redis Creator Brings DeepSeek to the Mac」（背景・二次情報）: https://techstrong.ai/articles/redis-creator-brings-deepseek-to-the-mac/
本記事のうち、M5 Max の ds4 実測、2bit 量子化の具体的な品質数値、SV/UVM タスクでの実用精度など、一次情報で裏が取れていない部分は「作者評価」「コミュニティ報告例」「未確認」として明示しました。実機が届いたら、自分の検証タスクで測り直して更新する前提で読んでいただければと思います。