DwarfStarで45 TPS？DeepSeek V4 Flashの128GB推論
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
DwarfStarでDeepSeek-V4-Flashを128GB環境・45 TPSで動かし、Huihuiのabliterated版へ差し替えたX投稿を検証。1M文脈、KVキャッシュ、2bit量子化の注意点を解説します。
先に結論
- X投稿では、128GB級のローカル環境でDwarfStarを使い、DeepSeek-V4-FlashのIQ2_XXS系GGUFを約45 tokens/sで動かしたと報告されている
- DwarfStarのKVキャッシュは、同じ会話や長い共通prefixの再処理を省き、継続ターンの待ち時間を大きく減らせる
- ただし、DeepSeek-V4-Flashの最大1M対応と、128GB環境で1Mを実用的に埋められることは別。DwarfStar公式は100K〜300K程度を現実的な目安としている
- Huihuiの「abliterated版」は安全上の拒否を減らした派生モデルであり、精度、事実性、合法性、安全性が上がるわけではない
- 同容量のGGUFへ差し替えられるのは、DS4向けにテンソル構成やメタデータが合わせられているため。同じファイルサイズなら何でも置換できるわけではない
今回の注目点は「無検閲で自由になった」という表現より、80GB前後の284B MoEを128GB級の手元環境へ収め、キャッシュを使いながら対話・エージェント用途へ近づけたことです。
情報監査日: 2026年7月21日
数値の扱い: 45 TPSはTonoKen3氏（@Tono_Ken3）のX投稿による実測報告です。当サイトで再測定した値ではありません。投稿画像からは、ハードウェア型番、DwarfStarのcommit、生成条件、測定区間を確認できません。
表現上の注意: 本記事の「abliterated版」はモデルカード上の名称・手法を指します。出力内容を推奨したり、安全性を保証したりするものではありません。
X投稿が報告した内容
投稿ではまず、DwarfStarでDeepSeek-V4-FlashのIQ2_XXS系モデルを128GBのローカル環境へ載せ、約45 TPSで推論したと説明されています。さらにDwarfStar独自のprompt / KVキャッシュにより、繰り返し使う長い文脈で即座に応答が始まり、1Mコンテキストにも対応するとしています。
その後、元のGGUFをHuihuiが公開した同容量のabliterated版へ差し替え、拒否を減らしたモデルを動かした、という流れです。
| 投稿の主張 | 一次情報で確認できること | 注意点 |
|---|---|---|
| 128GBで動作 | 公式もQ2系を96 / 128GB向けとして案内 | 機種と実際の空きメモリは不明 |
| 45 TPS | DwarfStarは速度表と測定条件を公開 | 投稿と同条件の公式値ではない |
| 即レスポンス | 共通prefixをKVキャッシュから再利用可能 | 初見promptのprefillは省略できない |
| 1Mコンテキスト | 基盤モデルの最大文脈長は1M | 128GBで1Mを確保すると余裕が小さい |
| 同容量モデルへ交換 | Huihui版はDS4向けGGUFとして公開 | 容量一致だけでは互換性を保証しない |
DwarfStarとは
DwarfStar（リポジトリ名はds4）は、Redis作者のSalvatore Sanfilippo氏（antirez）が開発する小型のネイティブ推論エンジンです。汎用GGUFランナーではなく、DeepSeek V4 Flashを中心に、対応モデルの読み込み、chat template、tool calling、KV state、HTTP API、コーディングエージェントを一体で最適化しています。
主なバックエンドはMetal、CUDA、ROCmです。Macでは96GB以上を主対象とし、CUDAではDGX SparkやマルチGPUにも対応します。80GB級のモデルを1台に常駐させる構成だけでなく、SSD streaming、pipeline parallel、tensor parallelも実装されています。
重要なのは、DwarfStarが任意のGGUFを読めるわけではないことです。公式READMEは、テンソル配置、量子化の組み合わせ、メタデータ、MTP stateが合う、掲載済みのDeepSeek V4 / GLM-5.2用GGUFだけを対象としています。
284Bモデルが128GBへ収まる理由
DeepSeek-V4-Flash公式モデルカードによると、モデルは総284B、1トークン当たり13Bを活性化するMoEです。総パラメータを保持する必要はありますが、各トークンで全284Bを計算するdenseモデルではありません。
DwarfStar向けQ2 GGUFは80.8GiBです。routed expertのgate / upをIQ2_XXS、downをQ2_Kへ量子化する一方、shared expert、attention projection、router、embeddingなどはQ8_0、F16、F32を混在させています。
したがって「2bitモデル」という呼び方は便宜的なものです。全テンソルを一律2bitへ落とした80.8GiBではなく、容量の大部分を占めるrouted expertを強く圧縮し、品質に敏感な部分は高い精度を残した混合量子化です。
| 構成要素 | 公開仕様 | 意味 |
|---|---|---|
| 総パラメータ | 284B | 重み全体の規模 |
| 活性パラメータ | 13B / token | 各トークンで使うexpertは一部 |
| Q2系GGUF | 80.8GiB | 96 / 128GB級を対象 |
| Q4系GGUF | 153.3GiB | 256GB以上を推奨 |
| MTP補助GGUF | 3.6GiB | 単体モデルではない |
45 TPSはどこまで速いのか
TPSには少なくとも、入力を読むprefill速度と、回答を1トークンずつ出すgeneration / decode速度があります。投稿の45 TPSは文脈上、後者の生成速度と考えるのが自然ですが、測定コマンドや内訳は画像から確認できません。
DwarfStar公式READMEの単発Metal測定は、32K context、non-thinking、greedy、256トークン生成という条件です。公開表ではM5 Max 128GBの短いpromptが34.27 t/s、約11.7K入力後が25.90 t/sです。DGX Spark 128GBは約7K入力後で13.75 t/sとされています。
ただし公式自身が「最適化に対して表の更新が追いついていない場合がある」と注意しています。ハードウェア、量子化ファイル、MTP / DSpark、thinking、context depth、温まり具合が違えば速度は変わるため、45 TPSはあり得ない数字とはいえませんが、公式表から再現できる数字でもありません。
また、投稿は速度を得た後にHuihui版へファイルを差し替えた流れです。画像内には差し替え後の再ベンチマークがないため、abliterated版でも正確に45 TPSを維持したとまでは確認できません。
「即レスポンス」の正体はKVキャッシュ
LLMのサーバーAPIでは、クライアントが毎回、会話履歴を含むprompt全体を送り直すことがあります。DwarfStar serverは、前回までと同じtoken prefixを検出すると、すでに計算したKV stateを再利用し、新しく追加された部分だけを処理します。
- メモリ内キャッシュ: 現在の会話を継続するときに共通prefixを再利用
- disk KV cache: 会話の切り替えやserver再起動後も保存済みprefixを復元
- 効果: 長いsystem prompt、coding agentの固定説明、既読のコードベースを毎回ゼロからprefillしなくて済む
これは「どんな1M promptでも瞬時に読める」機能ではありません。初めて投入する文書、1文字目から違うprompt、キャッシュにないprefixは通常どおりprefillが必要です。またcache hitは最初の回答が出るまでのTTFTを短くしますが、回答本文を45 TPSで生成するdecode性能そのものとは別です。
1M対応でも、128GBでは100K〜300Kが現実的
DeepSeek-V4-Flash自体の最大context lengthは1Mです。一方、DwarfStar公式は1M contextで約26GBの追加メモリを見積もり、そのうちcompressed indexerだけで約22GBになると説明しています。
80.8GiBのQ2重みに26GBを足すと約107GBです。そこへOS、graph scratch、activation、runtime、表示や他アプリのメモリも必要です。128GBで理論上近づけても余裕は大きくありません。公式READMEが128GBでは100K〜300Kを賢明な設定としているのはこのためです。
したがって、「1M対応」はモデルとエンジンが設定上扱える上限を示します。「128GBで1Mを常に埋めても高速・安定」という意味ではありません。再現テストでは32K、100K、250Kと段階的に上げ、prefill時間、TTFT、生成速度、peak memory、cache file容量を分けて測ります。
Huihui版へ差し替えられた理由
Huihui-DeepSeek-V4-Flash-abliterated-ds4-GGUFは、基盤のDeepSeek-V4-Flashへabliterationを適用し、DS4 / llama.cpp向けに量子化した派生版です。公開ファイルには、元のDwarfStar向けGGUFと同じ80.8GiBのQ2版、74.7GiBのIQ2_XXS版などがあります。
この差し替えが成立する理由は、同じDeepSeek-V4-Flash系で、DS4が期待するテンソル配置と量子化レシピに合わせて作られているからです。ファイル容量が同じことは互換性の結果であって、互換性の条件そのものではありません。別architecture、別tensor layout、別tokenizer、必要metadataの欠落があれば、同じ80.8GiBでも動きません。
「無検閲版」を使うときの注意
Abliterationは、モデル内部の拒否傾向へ介入して、安全上の回答拒否を減らす手法です。研究、創作、security検証などで過剰拒否を抑えたい場面はありますが、「言論の自由」という主観的な評価と、モデルの品質は分けて考える必要があります。
- 正確性は上がらない: 拒否しなくなっても、誤情報や危険な手順を自信満々に出す場合がある
- 完全に拒否しないわけではない: Huihuiのmodel cardもQ2版に一定のrefusal rateがあると記載
- 公開用途のリスク: 不適切、有害、違法な出力をそのまま外部へ返さないguardrailが必要
- tool権限を絞る: shell、メール、クラウド、社内データへ接続するagentではsandboxと承認フローを設ける
- 出力を監査する: 人手確認、ログ、content filter、法務・security reviewを用途に応じて追加する
Huihuiのmodel cardも、研究・管理された環境での利用を推奨し、public-facingなproductionでの直接利用を避けるよう警告しています。ローカル実行は入力データを手元へ留めやすい一方、出力の責任まで消すものではありません。
45 TPSを再現するために必要な記録
- ハードウェア: 機種、GPU、RAM / VRAM、メモリ帯域、電力設定
- ソフトウェア: DwarfStarのcommit、backend、compiler、driver、OS
- モデル: repository、filename、revision、SHA-256、MTP / DSparkの有無
- 生成条件: thinking、temperature、context上限、prompt長、出力長、batch
- 速度指標: prefill t/s、TTFT、decode t/s、cache hit / missを別々に測定
- 長文脈: 32K、100K、250K、必要なら1Mでmemoryと速度をdepth別に記録
- 品質: 元モデルとabliterated版を同じprompt setで比較し、拒否率だけでなく正答率とtool callingも測る
この条件があれば、45 TPSがハードウェアの差なのか、cache hitなのか、投機的decodeなのか、短いpromptだけのピーク値なのかを切り分けられます。
よくある質問
128GBあればDeepSeek-V4-Flashを1Mで使えますか？
設定上は到達できる可能性がありますが、DwarfStar公式はQ2重みが約81GB、1M contextが約26GBを使うため、128GBでは余裕が小さいと説明しています。日常利用は100K〜300Kから始め、実測しながら広げる方が安全です。
45 TPSなら長いコードベースもすぐ読めますか？
45 TPSがdecode速度なら、回答を出す速さです。初めて読む大量のコードはprefill速度とTTFTで決まります。一度処理した共通prefixがKV cacheへ当たれば、2回目以降は大幅に短縮できます。
同じ80.8GiBのGGUFなら差し替えられますか？
いいえ。architecture、tensor名・形状、quantization、metadata、tokenizer、engineのloader対応が一致する必要があります。今回のHuihui版はDS4向けに作られた同系統モデルだから候補になります。
Abliterated版は通常版より高性能ですか？
拒否が減ることと、推論能力・coding能力が上がることは別です。タスクによっては回答率が上がる一方、不正確・不適切な回答も増え得ます。元モデルと同じ評価セットで比較が必要です。
まとめ
DwarfStarでDeepSeek-V4-Flashを128GB級のローカル環境へ収め、約45 TPS、長いprefixのKVキャッシュ再利用、Huihui版への差し替えを実現したという投稿は、ローカルLLMの進歩を示す興味深い実例です。
一方、数字の読み方は分ける必要があります。45 TPSは投稿者の測定であり、公式と同条件ではありません。1Mはモデルの最大contextで、128GBの現実的な常用設定とは限りません。即応答はcache hit時のTTFT短縮で、初見の1M promptが瞬時に処理されるわけではありません。
最も価値のある到達点は「拒否しないモデル」ではなく、モデルファイル、推論エンジン、cache、権限、評価を自分で制御できるローカル基盤が、128GB級でも実用圏へ入ったことです。
参照資料
- TonoKen3（@Tono_Ken3）：元投稿のアカウント（2026年7月21日確認）
- antirez / ds4：DwarfStar公式リポジトリ（2026年7月20日更新版、7月21日確認）
- antirez：DeepSeek V4 Flash — GGUF for ds4（2026年7月16日更新版、7月21日確認）
- DeepSeek-AI：DeepSeek-V4-Flash公式モデルカード（2026年4月22日公開、6月22日更新版、7月21日確認）
- Huihui AI：DeepSeek-V4-Flash abliterated DS4 GGUF（2026年5月26日公開、6月6日更新版、7月21日確認）
