64 GBのRAMだけで、GPUなしにDeepSeek V4 Flash 284Bを本当に動かせるのか？

コミュニティのプロジェクトが、64 GBのLinuxマシンでCPUのみを使ってDeepSeek V4 Flash 284Bを実行したと報告しています。報告された構成では、llama-modchip、重みあたり約1.71ビットのカスタムチェックポイント、メモリ帯域幅の大きいデスクトップCPUを使用しています。公式チェックポイントの一般的な容量の目安ではなく、特定のビルドを使った記録済みの実験として捉えてください。

この結果が有用なのは、通常は混同されがちな3つの疑問を測定可能にするためです。重みファイルを格納できるか、生成中にプロセスが十分なメモリを維持できるか、そしてその圧縮レベルでも出力が実用的か、という疑問です。このプロジェクトは、11月8日のコミュニティでの議論で取り上げられました。以下の測定値は、独立したテストによるものではなく、llama-modchipメンテナーのリポジトリからのものです。

どのDeepSeekモデルとランタイムが使われているのか？

このプロジェクトの対象はDeepSeek V4 Flashです。ドキュメントによると、総パラメーター数は約284Bで、トークンごとのアクティブなパラメーター数は約13Bです。Mixture-of-Expertsモデルでは、ルーターがトークンごとにエキスパートを選択します。これによりトークンごとの計算量は抑えられますが、すべてのエキスパートを保存し、アクセス可能な状態にしておく必要があります。通常のデプロイ環境については、開発元のモデルカードとハードウェア要件の概要をご覧ください。

この実験では、専用のトランスコードとggml/llama.cppエコシステムへのパッチを使用しています。同じモデルファミリーをうたう別のファイルでも、テンソルのレイアウトや精度が異なる場合があります。標準的なllama.cppバイナリと一般的なGGUFは、別の選択肢として考える必要があります。上流リリースの手順については、既存のllama.cppアップデートガイドをご覧ください。

2840億個のパラメーターを64 GBのRAMにどう収めるのですか？

1重みあたり平均1.71ビットで、2840億個の重みは、10進単位で約61 GBのパック済みデータに相当します。プロジェクトの報告によると、256K構成でファイルサイズは56.56 GiB、プロセスの常駐メモリのピークは57.61 GiBです。GiBとGBは異なる単位です。余裕を把握するには、テスト時にホストで実際に利用できるメモリを確認してください。ファームウェアの予約領域、内蔵グラフィックス、その他のプロセスが、わずかな空き容量の多くを消費することがあります。

常駐メモリと重みファイルのサイズは関連する指標ですが、どちらもシステムのすべての割り当てを捉えるものではありません。読み込み中に、カーネルがファイルシステムキャッシュを回収したり、一時バッファーを保持したりすることがあります。ランナーのメモリ使用量とシステムの利用可能メモリの両方を確認してください。また、あるテストで記録された常駐メモリのピークだけでは、すべてのコンテキスト長や入力タイプを評価できません。

プロンプト速度と生成速度に差が出るのはなぜですか？

プロンプト処理では既知の入力を扱うため、ランタイムは複数のトークンにわたって処理をまとめて実行できます。生成は逐次的です。次のトークンは、それまでに生成されたトークンに依存します。MoEモデルのCPU生成では、選択されたエキスパートの重みと状態をメモリからどれだけ速く取得できるかが重要です。クロック速度、チャネル数、メモリータイミング、スレッドの配置は、いずれも結果に影響します。

短いプロンプトのテストと、長いリポジトリのプロンプトを分けます。最初のトークンが出るまでの時間と、その後の生成時間を別々に測定してください。ストリーム開始後の応答が速く見えても、長いプレフィックスが全体のレイテンシの大部分を占めることがあります。ランタイムがキャッシュ済みの状態を再利用したかどうかを記録してください。プレフィックスをウォームアップした状態と、コールド実行では、異なる問いへの答えが得られます。上流ベンチマークツールのドキュメントでは、プロンプトと生成の測定方法について説明しています。

この精度設定では、どの程度品質が低下しますか？

重みあたりのビット数が示すのは保存容量であり、モデルの品質ではありません。テンソルごとに異なる精度を適用でき、サイズが近い2つの変換でも動作が異なる場合があります。長い推論、厳密な構文、ツールの引数、珍しい語彙は、確認するのに適した項目です。1つの質問に対して読みやすい回答が得られれば、生成が機能していることは示せます。しかし、同じビルドがコーディングのワークフローでも信頼できることの証明にはなりません。

テスト前に小規模な参照セットを選んでください。厳密な形式での出力タスク、既知のテストに失敗する関数、長いコンテキスト内からの情報検索、モデルが慎重に対応すべき依頼を含めてください。同じプロンプトを使い、より高精度のベースライン、または対応するより小型のベースラインと比較してください。テスト入力を固定し、不完全な出力、不正なツール呼び出し、タイムアウトを記録してください。後の改善の原因を特定できるよう、モデルとランタイムのリビジョンを固定してください。

結果を責任を持って再現するには、どうすればよいでしょうか？

十分なSSD容量がある隔離されたLinuxテストマシンで、メンテナー指定の正確なチェックポイントとリビジョンを使用して始めてください。プロジェクトのビルドおよびクイックスタート手順を読み、実行前にスクリプトを確認し、CPU、メモリ構成、カーネルを記録してください。シェルツールを有効にせず短いプロンプトを使うのが、最初のテストとして有効です。ホストが応答性を保てると確認してから、コンテキストを増やしてください。

1. 読み込み前に、空きメモリとスワップの動作を測定してください。同じマシン上で実行中の他の負荷の高い実験は停止してください。
2. チェックポイントの正確なファイルサイズとハッシュ、ランナーのバージョン、特別なトランスコード設定やエキスパート配置設定を記録してください。
3. ピークRSS、最初のトークンが出るまでの時間、1秒あたりの出力トークン数、スワップが使用されたかどうかを記録してください。キャッシュの影響と初回実行時の挙動を分けるため、テストを2回実行してください。
4. 長い作業でモデルを使う前に、出力の正確さを比較してください。後でエージェントを接続する場合は、データの露出とファイルシステムへのアクセスを確認してください。

リポジトリの作業には分離されたGitワークツリーを使ってください。ホストが家庭内のストレージやバックアップサービスも提供している場合は、別のコンピューティングマシンで最初の実験を行いましょう。RAMを使い切る推論プロセスは、メモリ不足で停止するより前に、これらのサービスに支障をきたすおそれがあります。

より小さなモデルを選ぶべきなのはどんな場合ですか？

安定した対話速度、簡単なアップデート、または複数のセッションを実行できるだけの余裕が必要なら、より小さなチェックポイントを選びましょう。コミュニティによるこの実験が特に興味深いのは、カスタムコード、低精度、慎重な再現を許容できる場合です。サポート対象のランタイムで動く日常用モデルのほうが保守しやすく、1時間あたりにより多くの有用な作業を終えられる可能性もあります。本番環境の設定を変える前に、同じタスクで両方を比較してください。

よくある質問

ディスクリートGPUは必要ですか？

メンテナーは、指定の284BチェックポイントをCPUのみで実行した結果を報告しています。リポジトリにはGPU支援型の構成も含まれているため、テストプロファイルは分けてください。

64 GBのPCなら、どれでも報告された速度が出ますか？

搭載メモリだけを根拠に、一般的な速度を断言することはできません。CPUでの生成速度はメモリ帯域幅、カーネル、スレッドの配置に左右され、システムには十分な空きRAMが必要です。

チャットのストリーミングで44 tok/sの速度が出ますか？

約44 tok/sという数値は、引用された構成でのプロンプト処理速度を指します。リポジトリでは、自動回帰生成については別途、より低い速度の範囲が報告されています。

最初に試す設定は256Kコンテキストですか？

短い設定から始めて測定してください。メンテナーが示すメモリ使用量は、特定のランナーとチェックポイントの構成に基づいています。

これは公開済みのハードウェアガイドに取って代わるものですか？

標準的なデプロイには公式のモデルガイドを利用してください。llama-modchipは、独自の精度、互換性、パフォーマンス上の制約があるコミュニティ発の方法として扱いましょう。

結論

興味深いのは、特定のCPUランタイムとカスタムの低ビットチェックポイントを使えば、予想外に大きなMoEモデルを限られたメモリ内に収められることです。正確なビルドを再現し、プロンプト処理とデコードを区別して、信頼して使う前に出力品質をテストしてください。日常的なレイテンシを評価する際には、小型モデルも比較対象として役立ちます。