DwarfStar(ds4)と「過適合」推論エンジンの台頭
- 「過適合(overfit)」推論エンジンとは何か、なぜ狭いランタイムが同一ハードウェア上で汎用ランタイムの約 2 倍の速度を出せるのか、そしてなぜ 2026 年にそれが高価な賭けではなくなったのかを理解する
- 汎用 GGUF ランナーでは得られない、ds4 の 3 つの仕組みを学ぶ:非対称なルーテッドエキスパート量子化、SSD からストリーミングする上限付きエキスパートキャッシュ、再起動後も残る KV スナップショット
- ds4 が公表している数字を正しく読む:どれが Mac 1 台の値で、どれが 16 セッションを共有する 8 GPU の値で、どれが 128 GB のマシンで動く 178 GB のモデルなのか
- この賭けの実コストを見積もる:撤回されることを前提に設計されたモデルサポート、日付を確認すべき main ブランチ、そして C を読めることを前提としたセキュリティ姿勢
- 自分の用途で narrow(特化型)が llama.cpp に勝つ場面を見極める。そして、明らかに勝てない 3 つのケースも把握する
2026 年 10 月 2 日、「From the creator of Redis; run LLM locally
with ds4」 というタイトルのリンクが Hacker News のトップページに載り、362 ポイント・
104 コメントに落ち着きました。意外なのはプロジェクトそのものではありません。このプロジェクトは
すでに 5 か月前から存在していた点です。antirez/ds4 は 2026 年 5 月 6 日に作成され、
広く知られる前に、静かに 23,582 スター、2,268 フォーク、761 件の未解決 issue を
集めていました。
注目された理由は、エンジンそのものよりも重要です。ds4 は、1 年前にはほとんど存在せず、いまや 少なくとも 6 つのエントリを持つカテゴリ、つまり 過適合推論エンジン(overfit inference engine) の中で 最もスターの多いメンバーです。1 つのモデルを 1 種類のハードウェア向けに作られたランタイムで、 他のモデルは動かさず、作者自身も使い捨てにするつもりでいます。
ここで Colibrì や Strata を読んだことがあれば、この地図上の 2 点はすでに見ています。このページでは 3 点目と、その地図全体を扱います。
一文で言うと
ds4 は、少数の Mixture-of-Experts モデルを選び、それらの特定アーキテクチャ向けに Metal、CUDA、 ROCm のカーネルを書き、ルーテッドエキスパート だけを約 2 ビットまで圧縮しつつトークンごとの 経路は高い精度のまま保ち、さらに独自の CLI、コーディングエージェント、HTTP サーバーを周囲に 備えています。6 つのモデルで速度と完成度を得る代わりに、それ以外は何も動かせません。
「過適合」とは、正確には何か
カテゴリ名は、モデルの過学習(overfitting)からの意図的な類推です。ランタイムが 1 つのターゲットに きつく合わせ込まれていて、意図的に汎化しない、ということです。2026 年 10 月初旬時点で公開されている ラインナップは次のとおりです。
| エンジン | 対象ハードウェア | 対象モデル |
|---|---|---|
| DwarfStar (ds4) | Metal 96 GB 以上、CUDA(DGX Spark、Ada/L40S)、ROCm(Strix Halo) | DeepSeek V4 / V4.1 Flash、V4 PRO、GLM 5.2/5.3、Qwen3.8-Flash-Next |
| Strata | コンシューマー向け NVIDIA、12 GB 以上 | Qwen3.8-Flash-Next |
| ninfer | RTX 5090 | Qwen チェックポイント |
| Splash | Apple Silicon M3 以降 | Qwen ファミリー |
| llamAmpere | RTX 3090 / 3090 Ti | Qwen3.8-27B |
| gufo | AMD Strix Halo | 厳選されたセット |
特化型エンジンとチューニング済みの汎用エンジンを同じマシンで比較した公開計測は、ひとつだけあります。 ある開発者の RTX 4070(12 GB、64 GB DDR5)で Qwen3.8-Flash-Next を動かした結果で、60K コンテキストにおいて 最良にチューニングした llama.cpp が 27 tok/s、Strata が 53 tok/s でした。およそ 2 倍です。
ただし、この数字には作者自身が付けた但し書きがあります。量子化と設定が異なっていたため、統制された 実験ではない、ということです。これは実環境での差であって、ベンチマークではありません。この違いこそ、 このカテゴリ全体が表示するのを苦手としているものであり、どのエンジンの README を読む前にも 肝に銘じておく価値があります。AI ベンチマークの読み方が求める 規律と同じものです。
なぜ 2026 年に安く作れるようになったのか
論点は 3 つあり、3 つ目が自明でないものです。
- 汎用性はスループットを犠牲にします。 多数のモデルとバックエンドをサポートすると、防御的な分岐や 共有アロケータが必要になり、個々の経路をどこまで攻めてスケジューリングできるかが制約されます。
- コーディングエージェントがカーネル作成のコストを激減させました。 有能なシステムプログラマが 1 人いてエージェントを使えば、かつてはチームが必要だったペースで GPU カーネルを書き、計測し、 修正できます。ds4 の作者自身、このプロジェクトはモデルの強い支援を受けて作られ、アイデア、 テスト、デバッグは人間が主導したと説明しています。
- 推論の最適化は、目的関数が異例なほど明確です。 入力は固定、一致させるべき参照出力があり、 最大化する数字は 1 つだけ。エージェントに向けて放っておけるループであり、だからこそ論点 2 が ほかの領域ではなくここで効くのです。
汎用ランタイムでは得られない 3 つの仕組み
1. 非対称な量子化:エキスパートは潰し、経路は保つ
284B パラメータのモデルをノート PC で動かすという、不可能に聞こえる見出しは、一様な圧縮の話では ありません。MoE モデルはトークンごとに重みのごく一部しか触れず、その部分も壊れやすさは均一では ありません。ds4 はこの非対称性をテンソルの種類ごとに利用しています。
リポジトリが正確な数字で文書化しているのは Qwen3.8-Flash-Next の構成で、じっくり読む価値があります。
| コンポーネント | 処理 | サイズ |
|---|---|---|
| Main + MTP の重み | imatrix IQ2_XXS の gate/up エキスパート、パディング付き Q2_K の down 射影 | 41.73 GiB |
| 元の BF16 n-gram | ディスクから直接読み込み、メモリには常駐しない | 95.37 GiB |
この表から読み取るべき点は 2 つです。1 つ目に、量子化は テンソルの役割ごとに 選ばれています。 gate 射影と up 射影には down 射影とは異なる方式が使われます。受ける劣化への耐性が違うからです。 2 つ目に、ディスク上で最大の成果物は、トークンごとの乗算にはまったく使われません。n-gram 埋め込みは ルックアップなので SSD に置かれ、RAM と競合しません。Strata も同じモデルで同じ性質を利用しています。 ファイルサイズとメモリ要件は、単に同じ数字ではないのです。
リポジトリは、この処理に耐えるモデルを明記しています。DeepSeek V4 Flash と PRO、そして GLM 5.2 は 「積極的なルーテッドエキスパート量子化に耐える」 とされています。これはアーキテクチャごとの 経験的な主張であって一般法則ではなく、だからこそエンジンのモデル一覧は短いのです。
2. すべてではなく、エキスパートだけをストリーミングする SSD ストリーミング
フラグは --ssd-streaming ですが、実際にやっていることは、この言葉から連想されるよりも狭い範囲です。
プロジェクト自身の SSD_STREAMING.md から引用します。
SSD streaming keeps a bounded cache of routed experts and reads missing experts from the GGUF.
つまり、ルーテッドでない重みは RAM に残ります。上限付きキャッシュに出入りするのはルーテッド エキスパートだけです。ドキュメントは、これによって他の重み、アクティベーション、スクラッチ、コンテキスト に必要なメモリが不要になるわけでは ない と明記しています。「ストリーミング」という言葉からは RAM が問題でなくなるように読みがちなので、注意が必要な点です。
ここでの目玉の結果は、このページで最も意外な数字です。GLM 5.3 Flash Q4 を M5 Max で動かした場合、 つまり 128 GB のマシンで 177.77 GiB のモデル です。
| フェーズ | 計測値 |
|---|---|
| プリフィル(初回 / 継続) | 121 t/s / 104 t/s |
| 生成 | 11.9〜14.9 t/s |
ドキュメントが添えている警告とあわせて読んでください。「Generation is usually more sensitive to cache misses than prefill. A large model that starts successfully can still be too slow for interactive work.」 毎秒 12 トークンは、バッチ要約の処理なら十分ですが、 横で眺めているコーディングエージェントにはつらい速度です。
直感に反するチューニングの落とし穴もあります。エキスパートキャッシュを 大きく すると、 デコードが 遅くなる ことがあります。大きすぎるキャッシュが、毎トークン触れられる非ルーテッドの 重みを押し出してしまうためです。キャッシュは大きいほど良い、というわけではありません。
アーキテクチャとしてのエキスパートストリーミングをさらに深く扱った内容(本当の上限としての NVMe
帯域、SSD の摩耗、O_DIRECT)は、まさにその考え方を軸に作られた
Colibrì を参照してください。
3. KV スナップショット:エージェントループを安くする細部
あなたの日々の体験を最も変えそうな仕組みですが、ほとんど誰も書いていません。ds4 はセッションの
KV 状態と会話履歴を ~/.ds4/kvcache に保存し、文書化された約束は
「compatible local KV snapshots avoid rebuilding the prompt.」 です。
セッション操作のコマンド:
| コマンド | 効果 |
|---|---|
/save | 現在のセッションを保存する |
/list | 保存済みセッションを一覧表示する |
/switch <sha> | 指定したセッションを KV 状態ごと再開する |
/strip <sha> | KV ペイロードを破棄し、テキストは残す |
/del <sha> | セッションを削除する |
重要な理由:長時間動くエージェントは、毎ターン、増え続けるプレフィックスを再送します。エンジンが そのたびにプレフィックスを一から再構築すると、まさに重要な作業負荷でプリフィルが実時間の大半を 占めてしまいます。HN のスレッドのコメント投稿者たちは、KV の再利用性を保つ追記専用のメッセージ履歴を、 汎用ランタイムなら通常は呼び出し側に任せてしまう類の細部として挙げていました。これは、 プロバイダ横断のプロンプトキャッシュのローカル エンジン版です。経済性は同じで、層が違います。
文書化されている制限が 1 つあります。画像を含むセッションはまだ保存できません。
ランタイムだけでなく、スタックである
4 つのバイナリが付属し、その役割分担が肝心です。
| バイナリ | 用途 |
|---|---|
ds4 | 会話履歴を持つ対話型マルチターン CLI |
ds4-agent | 推論を直接呼び出すネイティブのコーディングエージェント(HTTP を介さない) |
ds4-server | http://127.0.0.1:8000 で待ち受ける、外部クライアント向け HTTP サーバー |
ds4-eval | 実際の GGUF に対する、組み込みの能力回帰テスト |
ds4-server が統合の接点であり、リポジトリは想定クライアントを名指ししています。Pi、OpenCode、
Codex CLI、そして Claude Code です。そのため ds4 は、
Claude とローカルモデルの併用や
ローカルコーディングエージェントで説明しているハイブリッド構成の
ローカルバックエンドとして有力な候補になります。
ds4-eval についてリポジトリが述べていることは、異例なほど正直なので注目してください。
これらは 「DwarfStar integration checks, not official leaderboard scores」 です。
答えられるのは「このビルドは退行したか?」であって、「このモデルは優れているか?」ではありません。
クローンから最初のトークンまで
- Apple Silicon 上の Metal が主要な経路でデフォルトです。CUDA には 2 つのターゲットがあります。DGX Spark 向けにチューニングされたものと、Ada/L40S クラスのカード向けの汎用のものです。ROCm は Framework Desktop などの Strix Halo システムが対象です。選ぶのは実行時フラグではなく、コンパイル時のターゲットです。
- Metal 経路では Flash クラスのモデルに 96 GB 以上が必要で、PRO 版は 256 GB 以上のマシンが前提です。SSD ストリーミングは下限を下げますが、上の数字が示すとおり、最大級のモデルでは生成速度が 1 桁から十数 t/s にとどまります。「対話的」の線のどちら側にいたいのかを、先に決めてください。
- Metal なら素の make、それ以外なら make cuda-spark、make cuda-generic、make strix-halo。プラットフォーム別カーネル付きの純 C で、リポジトリは C が約 8.7 MB、CUDA が約 4.5 MB、Objective-C が約 2.3 MB、Metal が約 1.4 MB。他の推論ライブラリへの実行時依存はありません。
- ヘルパースクリプトは ds4f-q2、qwen38-q2、qwen38-q4k、qwen38-vision といった短いタグを受け取ります。これらはプロジェクト固有の GGUF ビルドで、「汎用 GGUF ランナーではない」という点が具体的になる手順です。Ollama や llama.cpp 用にすでにディスク上にあるチェックポイントは、動作しない前提です。
- 何かを接続する前に、ds4 で品質と速度を対話的に確認します。そのうえで ds4-server を起動し、クライアントをポート 8000 に向けます。現在の API の形は docs/ にあるサーバーとクライアントのガイドで確認してください。README は詳細をそちらに委ねていて、このページが書かれて以降に最も変わっている可能性が高い部分です。
- /save を実行し、続けて /list を実行します。この手順が、遅いプリフィルを一度きりのコストに変えます。このエンジンで最もレバレッジの高い習慣です。
ビルド、取得、実行(Apple Silicon)
git clone https://github.com/antirez/ds4.git cd ds4 make ./download_model.sh ds4f-q2 ./ds4
残り 3 つのビルドターゲット
make cuda-spark # DGX Spark make cuda-generic # Ada Lovelace / L40S-class, multi-GPU make strix-halo # ROCm on Strix Halo (e.g. Framework Desktop)
Claude Code、Codex CLI、OpenCode、Pi 向けに配信する
./ds4-server # listens on http://127.0.0.1:8000 by default # see docs/SERVER.md for the API surface and multi-session handling, # and docs/CLIENTS.md for per-client setup
初日に知っておきたいフラグ
--ctx 32768 # context window size --prefill-chunk 1024 # prefill batch size --ssd-streaming # bounded routed-expert cache, rest read from GGUF --mtp # speculative decoding (GLM, Qwen) --nothink / --think # reasoning off/on; V4.1 uses --think-level 1-100 --temp 0 # greedy --vision FILE # load a vision encoder --prefix-file FILE # preload conversation pairs --power 100 # throughput/GPU-load trade (V4.1 and GLM require 100)
見出しの数字が伝えない 6 つのこと
1. 126 t/s という数字はあなたの Mac の値ではない
リポジトリは、8 基の L40S によるデプロイで 「about 126 t/s aggregate generation with 16 sessions」 と報告しています。これは 8 基のデータセンター GPU 上の 16 同時セッションにわたる合計スループット であり、割り算すればセッションあたり約 8 t/s です。サービング容量の数字です。手元のノート PC で 1 つの応答がどれだけ速くストリームされるかについては何も語っておらず、文脈抜きで引用されやすい 数字でもあります。この罠の一般的な説明は 高速推論とトークン速度にあります。
2. モデルサポートは撤回されることを前提に設計されている
リポジトリが掲げる方針は 「Model support is intentionally opportunistic.」 です。モデルは、 128 GB のノート PC や 256/512 GB のワークステーションへの関連性に基づいて追加され、削除 されます。 プロジェクトは自らを、普遍的な対応範囲ではなく 「a working template for the biggest use cases」 と位置づけ、ユーザー自身のハードウェア向けにコーディングエージェントで コードベースを改変することを奨励しています。
これは依存関係への警告として読んでください。ds4 と DeepSeek V4 Flash の組み合わせでワークフローを 組んだとしても、サポートされている組み合わせは明示的に約束ではありません。コミットを固定(pin) しましょう。
3. コミット日は自分で確認する。そしてこのカテゴリの予測を知っておく
2026 年 10 月 6 日時点で、main の最新コミットは 2026 年 9 月 20 日 付、約 2 週間前で、
761 件の未解決 issue があります。コミット自体は放棄されたものではなく、ROCm と Metal のテストスイート
ガードや QA プリフライトのドキュメントなど、丁寧なエンジニアリングに見えます。しかし、このカテゴリの
年代記作者は、2027 年 4 月までに、上に挙げた 6 つのエンジンのうち少なくとも 4 つが 60 日間コミット
なしになる と予測しています。モデルアーキテクチャが足元で動いていくためです。
これは予測であって事実ではありません。このページに載せる理由は、それが 確認可能 だからです。 このクラスのエンジンを採用する前に、確認には 10 秒しかかかりません。コミット日は、どの README にも 載っていない「メンテナンス」の列です。
4. ROCm に関する、知っておくべき矛盾
Hacker News のスレッドのあるコメント投稿者は、ROCm ビルドは「absolutely untested」だと報告しました。 一方、リポジトリ自身の 2026 年 9 月 19 日のコミットログは、具体的な表現で逆のことを述べています。 Strix Halo 上で警告なしの ROCm アプリケーションおよびテストビルドを検証し、配置、メモリ、セッション、 サーバー、エージェントのテストが通ったと、コミットメッセージが記述しているのです。
両方とも、時点や Strix Halo の構成が異なれば真である可能性があるため、ここでは解消せず両方を 報告します。AMD を使う場合、ROCm は 3 つのバックエンドのうち最も踏み固められていないものと 考え、採用を決める前に自分のマシンで検証してください。
5. 独自の GGUF と、スレッドで不評だったウェブサイト
ds4 は 「deliberately narrow, not a general GGUF runner」 であり、独自の GGUF ビルドが必要です。
別の話として、dwarfstar.sh のプロジェクトサイトは HN のスレッドで、マーケティング色が強いと
批判されました。あるコメント投稿者は「pure slop」と呼んでいます。技術的な中身は、代わりにリポジトリの
docs/ ディレクトリにあります。ランディングページではなく、リポジトリを読んでください。
6. セキュリティ姿勢は、あなたが C を読めることを前提としている
これらは若く、ほぼ単独のメンテナによるプロジェクトで、ネイティブ GPU アクセスを持ち、外部の レビュアーは少なく、カテゴリ全体がこの形を共有しています。これを追っている人々からの定番の助言は、 ソースからビルドし、コミットを固定し、失っても構わないハードウェアで動かすことです。ツールアクセスを 持つエージェントの背後にローカルエンジンを置くなら、 ローカルおよびハイブリッドエージェントの保護の 脅威モデルは、モデルだけでなくランタイムにも当てはまります。
特化型が本当に汎用に勝つとき
過適合エンジンを選ぶのは、 使うモデルがその一覧にあり、プロジェクトの期間中そこに残り続けるとき。 ハードウェアも一覧にあるとき。作業負荷が、再利用できるプレフィックスを持つ長時間のもので、KV スナップ ショットが元を取れるとき。そして、ソースからビルドして diff を読めるときです。
llama.cpp や Ollama にとどまるのは、 モデルを頻繁に切り替えるとき。管理できない複数のマシンで 1 つのランタイムを使いたいとき。まだ誰も過適合させていないモデルが必要なとき。あるいは最適化したい ものが毎秒のトークン数ではなく自分の時間であるときです。汎用ランタイムは、参照のベースラインでも あります。先にそれを計測しなければ、特化型エンジンが実際に何をもたらしたのかを知ることはできません。 そのベースラインをまだ取っていないなら、 Ollama でモデルをローカル実行するが出発点として適切です。
ホスト型 API を使うのは、 仕事がローカル性ではなくフロンティアの能力を必要とするとき。これは HN のスレッドでも直接話題になりました。あるコメント投稿者は、実際のコーディング作業では フロンティアのクラウドモデルのほうが依然として速いと指摘しています。ローカル推論が買えるのは プライバシー、コスト管理、オフライン動作であり、同等性ではありません。 ローカル or Claude エージェント?が、その判断を丁寧にたどります。
ローカル AI コミュニティで形になりつつある合意は、勝者を決めることではなく 二層のエコシステム です。幅広さと可搬性のための汎用ランタイムと、いま四半期に実際に動かしているモデルで最大の性能を出す ための使い捨ての過適合ランタイム。両方をインストールしておくことが期待されています。
Check yourself
0/6出典と参考文献
- antirez/ds4 — リポジトリ、README、対応モデル表、ビルドターゲット、バイナリ、フラグ: https://github.com/antirez/ds4
- ds4
docs/SSD_STREAMING.md— 実際に何がストリーミングされるか、GLM 5.3 Flash Q4 の計測値、エキスパートキャッシュのサイズに関する警告: https://github.com/antirez/ds4/blob/main/docs/SSD_STREAMING.md - ds4
docs/SERVER.md— HTTP サーバーの API の形とマルチセッションの扱い: https://github.com/antirez/ds4/blob/main/docs/SERVER.md - ds4
docs/CLIENTS.md— Pi、OpenCode、Codex CLI、Claude Code ごとのセットアップ: https://github.com/antirez/ds4/blob/main/docs/CLIENTS.md - "From the creator of Redis; run LLM locally with ds4" — ハードウェアの幅広さ、フォークのエコシステム、批判を含む Hacker News のスレッド: https://news.ycombinator.com/item?id=49936575
- "The Rise of Overfit Inference Engines" — カテゴリの枠組み、6 つのエンジンのラインナップ、RTX 4070 での llama.cpp 対 Strata の計測、放棄の予測: https://carteakey.dev/blog/local-inference/the-rise-of-overfit-inference-engines/
- DwarfStar プロジェクトサイト — HN のスレッドで批判されたランディングページ。中身はリポジトリの
docs/にある: https://dwarfstar.sh/ - ggml-org/llama.cpp — このカテゴリの何かを採用する前に、比較基準として計測しておくべき汎用ランタイム: https://github.com/ggml-org/llama.cpp
次のステップ
- Strata: 12 GB カードで 94 tok/s の 125B MoE — コンシューマー GPU 上の同じカテゴリで、品質面の代償も全面的に見積もっています
- Colibrì: 744B MoE を SSD から動かす — エキスパートストリーミングを限界まで突き詰め、tok/s で何を支払うかを示します
- プライベートなローカル AI スタック — 動かしているほかのすべてのものと並べて、狭くて速いエンジンをどこに置くか