ハクソク

世界を動かす技術を、日本語で。

DeepSeek 4 FlashのMetal用ローカル推論エンジン

1日前原文(github.com)

概要

ds4.c は DeepSeek V4 Flash 専用の軽量ネイティブ推論エンジン。 llama.cpp と GGML の知見を活かしつつ、Metal専用グラフ実行・KVキャッシュ圧縮・長大なコンテキスト対応を実現。 2bit量子化 や 1Mトークンウィンドウ など独自最適化を実装。 OpenAI/Anthropic互換API を備え、エージェント連携やローカル推論検証も重視。 MacBook/Mac Studioなど 128GB以上RAM 搭載機向け設計。

ds4.c：DeepSeek V4 Flash専用推論エンジンの特徴

  • DeepSeek V4 Flash 専用設計のMetalグラフ実行エンジン

    • GGUFファイル の独自読み込み・プロンプト描画・KVステート管理・サーバAPI連携
    • 他ランタイムやフレームワークのラッパーではなく、単独動作を重視

  • llama.cpp と GGML への多大な謝意

    • GGMLのカーネル・量子化形式・GGUFエコシステムの知見を活用
    • 一部コード・設計をMITライセンス下で流用・改変

  • DeepSeek V4 Flash モデルの優位性

    • アクティブパラメータが少なく高速動作
    • 思考セクション長が問題の複雑さに比例し、他モデルの1/5程度
    • 1Mトークンの巨大コンテキストウィンドウ に対応
    • 英語・イタリア語の文章生成能力が非常に高い準フロンティアモデル
    • KVキャッシュの高圧縮 でローカル長文推論やディスク永続化が可能
    • 特殊な2bit量子化 による高効率動作（MacBook 128GB RAMで動作可能）

  • プロジェクト方針

    • 一度に一つのモデルのみ対応、 公式実装のlogits検証 ・長文テスト・エージェント連携重視
    • 高性能パーソナルマシン（128GB RAM以上） で信頼できるローカル推論を目指す
    • コードは GPT 5.5 の支援と人間の設計・検証による共同開発
    • Metal専用 （将来的にCUDA対応の可能性あり）、CPU経路は動作保証外（macOSカーネルバグによるクラッシュ注意）

モデル・量子化・ダウンロード

  • 対応モデルはDeepSeek V4 Flash専用GGUFのみ
    • 他のDeepSeek/GGUFファイルは非対応（テンソルレイアウト・量子化・メタ情報が異なるため）
  • 2bit量子化（q2） と 4bit量子化（q4） モデルを提供
    • q2：128GB RAMマシン向け
    • q4：256GB以上RAMマシン向け
  • ダウンロード方法
    • ./download_model.sh q2 または ./download_model.sh q4 でモデル取得
    • モデルは./gguf/以下に保存、curl -C -で途中再開対応
    • MTP（推測デコード）GGUF もオプションで取得可能（./download_model.sh mtp）

ビルド・実行・CLI操作

  • ビルド
    • makeでビルド
    • デフォルトモデルパスは./ds4flash.gguf
  • CLI操作例
    • ワンショットプロンプト：./ds4 -p "Explain Redis streams in one paragraph."
    • インタラクティブチャット：./ds4（複数ターン、KVチェックポイント引継ぎ）
    • コマンド例：/help、/think、/nothink、/ctx N、/quit など
    • Ctrl+C で生成中断可能

サーバ機能・API互換

  • OpenAI/Anthropic互換APIサーバ
    • ./ds4-server --ctx 100000 --kv-disk-dir /tmp/ds4-kv --kv-disk-space-mb 8192
    • Metal専用、1セッションのみ同時保持（バッチ未対応）
    • エンドポイント例
      • GET /v1/models
      • POST /v1/chat/completions（OpenAI互換）
      • POST /v1/messages（Anthropic/Claude互換）
    • SSEストリーミング対応
    • ツール呼び出し はDSML形式からOpenAI/Anthropic形式に自動変換

パフォーマンス・推論速度

  • 推論速度例（q2, --ctx 32768, Metal, -n 256）
    • MacBook Pro M3 Max (128GB)：短文 58.52 t/s（プリフィル）、26.68 t/s（生成）
    • Mac Studio M3 Ultra (512GB)：短文 84.43 t/s（プリフィル）、36.86 t/s（生成）
    • 11709トークン長文入力時も高速（プリフィル最大468 t/s）

エージェントクライアント連携

  • OpenAI互換エージェント（opencode, Pi等）で利用可能

    • サーバ起動後、クライアント設定ファイルでbaseURLやcontext等を指定

    • 1Mトークンウィンドウ使用時は26GB以上メモリ消費 （q2量子化で81GBモデル＋22GBインデックス等）

    • 128GB RAM環境では100k～300kトークン程度が現実的

    • 出力上限384kトークン で極長文生成も可能（ただしウィンドウ制限あり）

    • opencode用設定例

      • ~/.config/opencode/opencode.jsonにds4プロバイダー・エージェントを追加

    • Pi用設定例

      • ~/.pi/agent/models.jsonにds4プロバイダー・モデルを追加

ライセンス・謝辞

  • GGML, llama.cpp の著作権表示をLICENSEに明記
  • MITライセンス 下で一部コード・カーネル・量子化ロジック等を活用
  • llama.cpp, GGML, Georgi Gerganov氏および全コントリビューターに深謝

注意事項・今後の展望

  • 現状はアルファ品質コード、今後の改善・新バージョン対応に期待
  • Metal専用、CPU経路はmacOSバグによりクラッシュするため非推奨
  • 今後CUDA対応の可能性 あり
  • AI生成コードに抵抗がある場合は非推奨

ds4.c は DeepSeek V4 Flash の性能を最大限に引き出すために設計された、ローカル推論エンジンの決定版。 大規模コンテキスト・高速性・圧縮キャッシュ・API互換性を備え、 128GB以上RAM搭載Mac での利用に最適。 llama.cpp ・ GGML の知見を活かしつつ、現代的なローカルAI体験を提供。

Hackerたちの意見

これ、めっちゃすごいね。オープンソースのモデルを最適化するために集中して取り組んだら、数ヶ月後にどうなるのかすごく気になる。推論サービングだけじゃなくて、ハーネスの最適化や、フロンティアモデルが推論できることとオープンソースモデルがサイズやトレーニングのせいで欠けている部分を埋めるためのカスタムワークフローを作ることについてもね。

└

フロンティアモデルとオープンソースモデルの間には、常に大きなギャップがあるよね（よっぽど金持ちじゃない限り）。この業界、全然意味がわからない。みんなユニットエコノミクスを無視してる。Kimi 2.6を decent tok/ps で運用するのに月20kかかるけど、そのトークンを利益を出して売るには、ハードウェアコストが月1k以下じゃないと無理だよ。億万長者がコストの1/10～1/20でトークンを売ってくれることに賭けてる人たちや、消費者向けハードウェアに収まる能力のあるオープンソースモデルの妄想的な未来を信じてる人たちは、実際に詰んでる。

最大モード以外でトークンが少なくなるのが気になるな。DeepSeek V4 Flashが大好きで、めっちゃ使ってるんだけど、安いから一日中使っても10ドルのOpenCode Goサブスクリプションを使い切ることがないんだ。だからいつも最大モードで使ってるけど、今はハイモードの方がいいのか考えちゃう。

└

何に使ってるの？私はSOTA（Claude 4.7 Maxの思考）にこだわって、遅いリクエスト/レスポンスには我慢してる。あまり考えないモデルにどんな仕事を任せるかはわからないな。私の直感はClaude vSOTA Maxが扱えることに基づいてるから。でも最終的には自宅システムを作りたいと思ってる。小さめのローカルモデルがメタデータの割り当てをうまく処理できるんじゃないかな。編集：でも、Mac Studioはもう512GBを提供してないんだって… DRAM不足、笑。厳しいね。

└

オープンコードの使い心地はどう？Claude Proから乗り換える価値あるかな？

└

最大設定だと、ArtificialAnalysisのベンチマークスイートを実行する時に、高設定の2倍以上のトークンを使うんだ。今のトップモデルの中では、確かにトークン使用量が一番多いモデルだよ。「インテリジェンス vs. トークン使用」のチャートはここで見られるよ: https://artificialanalysis.ai/models?models=gpt-5-5%2Cgpt-5-...

ランダムで面白いデータポイント：DS4がフルスピードでトークンを生成しているとき、私のMacBook M3 Maxはエネルギー使用量が最大で50Wに達するんだ…

└

人間の脳2、3個分の電力使用量だね。すごい仕事だ！

└

「LLM用のデータセンターは、スケールメリットのおかげで、自己ホスティングのLLMモデルよりもユーザーあたりのエネルギー効率が高い」というデータポイントは、インターネットが受け入れる準備ができていない。

└

MacBook ProやMac Studioでローカルモデルを使ったとき、だいたい60Wのトータルシステムを見たことがある。Mac Studioのベースラインは約10W、MacBook Proは約6Wだね。

└

みんなが気づいてるわけじゃないかもしれないけど、これは本当に素晴らしい結果だよ。俺のM4 Maxでは、ほとんどのモデルが150Wで動いてる。

└

これらの機械が「考える」のにどれだけの電力が必要かを考えるのは面白いよね。俺は「かなりの量」って漠然と思ってたけど、具体的な数字を出すのはいいことだね。DS4 Flashが50Wで280Bパラメータだとしたら、DS4 Proは1.6Tパラメータでおそらく300Wくらいになるってこと？最新のGPT 5やOpusも、たぶん500Wくらいで似たような感じ？Claude Codeを使ってる時に「オートフェレート」してるとき、どこかのデータセンターで500W消費してるって言ってもいいのかな？

└

それってマジで大きい数字なの？ところで、ハードウェアに詳しくない俺みたいなのが、どうやってこれを測るんだろう？

DS4って見ると、いつも頭の中で「ダークソウル4」（悲しい顔）とか、デュアルショック4、ディープシーク4って解釈しちゃうんだよね。

すごいプロジェクトだね！これは目的を持ったバイブコードプロジェクトのいい例だよね、君が認めてる通り。

へへ、実はQwen3モデルのために似たようなものを作ったことがあるんだ。これ、Qwen3だけ動いて、いくつかの量子化にしか対応してなくて、GGUFから読み込むし、Claudeで最適化された推論をループで実行するんだ。全体がコンパクト（ファイルは数個だけ）で、考えやすいんだよね。学生たちがいじって学べるように作ったんだ（異なるデコーディング戦略を追加したり、アブレーションを追加したり）。人気のフレームワークは大きくて複雑で、ハックしにくいけど、教育プロジェクトはたいてい古いもの（GPT-2とか）に焦点を当てがち。教育目的のプロジェクトだったけど、頭から離れないアイデアが浮かんだんだ。もし、特定のGPU+モデルの組み合わせに合わせた超最適化された推論エンジンを作り始めたらどうなるんだろう？GPUは高くて、日々入手しにくくなってるし。抽象化を減らして、正確なハードウェア/モデルに直接コードを書けば、かなり最適化できるかも（願望）。推論をループで最適化しようとするエージェントを動かして、速度や品質を実験的にテストするのもいいかも。ただ、モデルが古くなると、またゼロからやり直さなきゃいけないのが難点だね。

└

ローカル推論の最適化に関する別の提案だけど、HermesチームがXで、各モデルのニュアンスに合わせたカスタムパーサーを使うと結果がどれだけ良くなるかをたくさん話してるんだ。一部のモデルはJSON出力で末尾に,を使うのが好きだったり、そうじゃなかったりするから、パーサーが特定のモデルの特性を扱えるなら、より高性能な機能が得られるよ。

└

俺も似たようなものを作ったことがあるんだけど、一つの問題はLLMがいいシェーダーを書くのが本当に苦手だってこと。あいつらをもうちょっとマシにするのに、時間をかけすぎちゃったよ。

└

これで有名なFizzBuzzのハイパフォーマンスコードゴルフの答えに繋がるね。[1] もし推論のためにああいう最適化を実装できたら、速度を10倍以上にできるかもしれない。[1] https://codegolf.stackexchange.com/questions/215216/high-thr...

└

PyTorchがプラグイン可能なコンパイラを持つようになったらどうなる？M種類のGPUとNモデルがあって、バックエンドが許せば、専門のコンパイラを実行できるのかな？

MacBookで大規模なLLMを使うと、トークンは許容できる速度で生成されるけど、問題はコンテキストの読み取りなんだ。チャットセッションの時みたいにインクリメンタルに読むんじゃなくて、大きなファイルをペーストした時みたいな大きなサイズの読み取りになるから、数分かかることもあるよ。

└

もし間違ってなければ、そのリポジトリは2ビット量子化で動かすことについてのものだね。これはクラウドプロバイダーが提供する生のインテリジェンスからはかなり遠いと思う。でも、エージェントワークフローにおけるローカルLLMの重要性をより明らかにしているよ。

└

DS4は1秒間に460トークンを処理できるんだ。特別速いわけじゃないけど、遅すぎるわけでもない。M3 Maxでの話ね。ベンチマークはreadmeを見てみて。

└

なんでそうなるの？チャットに全履歴をフィードバックすることに依存しないアーキテクチャってあるのかな？再帰的なLLMとか？

これってoMLXと比べてどうなの？

ワクワクしてたけど、DSフラッシュがまだでかいって気づいちゃった。まあ、存在してるだけでも嬉しいし、antirezがまだ面白いことやってるのを見るのはいいね。