200GBの問い：モデルの重みのうち、本当にGPUに置くべきものはどれか

大規模言語モデルのサーバー見積もりは、荒っぽい一つの規則に従ってきた。パラメータ数を数え、精度を掛け、その分のGPUメモリを買う。DeepSeekのV4.1 Flashはこの規則を崩す。重みは合計7630億で、FP8ならアクセラレータメモリの下限は763GBになるはずだ。ところが実際には約567GBで動かせる。そのうち1960億が、はじめから通常のシステムRAM上で動くよう設計されているからである。

要点

• あるモデルの重みのうち約196GB分をアクセラレータの外へ完全に逃がせる。必要なサーバー構成そのものが変わる。
• 移せる重みは一度に数十エントリしか読まないルックアップテーブルで、トークン生成を律速するメモリ帯域を奪い合わない。
• この節約はGPUの一段下の階層が十分速い場合にだけ成立する。設計の重心はGPU予算からシステムメモリとストレージI/Oの計画へ移る。

上限を決めるのは容量ではなく帯域だ

トークンを一つ生成するには、モデルのアクティブな重みをメモリから読み出す必要がある。トークンごとに繰り返されるこの読み出しがあるからこそ、スループットの天井を決めるのは演算量ではなくメモリ帯域であり、アクセラレータメモリがあの価格を保っている。容量も重要だが、重みをGPUに載せる本当の理由は、それをどれだけ速く流し込まねばならないかにある。

この理屈が当てはまるのは、実際に流される重みだけだ。そうでない重みもある。DeepSeekの条件付きメモリモジュールは1960億のパラメータをN-gramのルックアップテーブルとして保持する。短いトークン列について学習された連想であり、参照コストはブロック全体を走査する代わりにトークンあたり数十回のテーブル読み出しで済む。これほど疎にしか触られない重みが、システムで最も速いメモリを占める理由はない。

結果として在庫は二つに分かれる。トークンごとに有効化される約80億パラメータは速くなければならない。一方のルックアップ用の塊はシステムRAMに置いてもよいし、詰まらずに応答できる程度に速いストレージアレイでも構わない。技術報告書を読み解いたThe Registerは、この狙いをモデルが知っていることと計算すべきことの分離だと説明している。

調達交渉はどう変わるか

およそ200GBは端数ではない。ノードの等級を一段またぐ差になることが多く、つまり設備投資計画そのものを分ける。パラメータ数だけで見積もる買い手は過剰投資になり、下の階層を確かめずにオフロード後の数字だけで見積もる買い手は過少投資となり、レイテンシで代償を払う。

いまはどちらの誤りも避けにくい。モデルカードがメモリの数字を二つではなく一つしか載せていないからだ。有用な開示は分割された二つの値である。アクセラレータに常駐させねばならない量と、一段下に置いてよい量だ。この問いは、ドキュメントに現れるより先にベンダー評価の項目として入ってくるだろう。

要求すべき数字がもう一つある。GPUを埋めるのは重みだけではない。キーバリューキャッシュはコンテキスト長と同時利用者数に応じて膨らみ、スループットの高いチャットやエージェント用途ではむしろこちらが支配的になる。同じDeepSeekのリリースはこれを別途攻めた。アテンションを作り替え、新しい因果エンコーダ・デコーダを導入して、キャッシュ使用量を従来のFlashモデルの13〜25%まで下げている。容量に直せばメモリあたりの同時セッション数が4倍から8倍になるということで、多くの運用者にとってはパラメータの算術より身近な数字だ。

この手法はどこまで持ち出せるか

独自技術ではない。GoogleのGemmaチームは、階層のどこもが窮屈なスマートフォンに実用的なモデルを収めるため、近い仕組みのPer-Layer Embeddingを作った。DeepSeekは1月にN-gram版を公開し、Alibabaもその後、実験的なQwenモデルに510億パラメータのルックアップ用の塊を組み込んでいる。アクセラレータの値段とDRAM一枚の値段を比べたことがある者なら誰でも読み取れる経済性が、この設計を広げている。

決着していないのは、階層をどこまで下れるかだ。システムRAMは実証済みの置き場である。ストレージはまだ主張の段階で、アレイの性能に大きく左右される。検討する側は見出しの数字を信じるより、自社の推論基盤でベンチマークを取るべきだ。節約は本物だが条件付きであり、その条件とはすでに持っているか持っていないかというインフラそのものだからである。

変更管理にも変数が一つ増える。エンドポイントの背後で何を動かすかを変える事業者は、同時にメモリプロファイルまで変えてしまう。今週、固定したはずのモデル名が拒否する手段もなく別の重みを返し始めた件で、このリスクが表面化した。

FAQ

どんなモデルでも重みをシステムRAMへ逃がせますか?

できない。大量ストリーミングを避けられるほど疎にしか触られない重みだけが、レイテンシの代償なしに移せる。実際にはトークンごとに使うアクティブな重みではなく、ルックアップ型のパラメータがこれに当たる。通常の密な重みを逃がせば、GPUが解決するはずだった帯域のボトルネックがそのまま戻ってくる。

DeepSeek V4.1 Flashに実際どれだけのGPUメモリが要りますか?

7630億パラメータをFP8ですべてアクセラレータに載せるなら最低763GBが要る。1960億パラメータのルックアップ用の塊を逃がすと、その下限は約567GBまで下がる。本番運用ではキーバリューキャッシュ用の余裕が別途必要で、これはコンテキスト長と同時利用者数に比例して増える。

重みをオフロードするとモデルは遅くなりますか?

受け側の階層次第で完全に決まる。システムRAMから返るルックアップは構造が保つ程度には速い。一方で遅いストレージアレイは参照のたびに待たせ、この設計が削るはずだったレイテンシをそのまま返してくる。自社のハードウェアで実測することだけが確かな答えになる。