DSV4論文の図1は、DSV3.2が1mコンテキストで約50GBを使用し、DSV4は
約5GB：
https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro/blob/main/DeepSeek_V4.pdf
ということを示唆しているように見えます。
私自身の計算では、1mコンテキストにおける正しいFP16のKVキャッシュは次のはずです：
| モデル | パラメータ | 128k | 160k | 1m | KV% |
|---|---|---|---|---|---|
| V3.x | 671B | 8.58GiB | 10.72GiB | 68.63GiB | 5.11% |
| V4 Flash | 284B | 0.76GiB | 0.95GiB | 6.08GiB | 1.07% |
| V4 Pro | 1600B | 1.09GiB | 1.36GiB | 8.71GiB | 0.272% |
つまり、KVキャッシュの削減は9.5倍ではなく7.879倍です。それでも非常に印象的です。KV%メトリクスを見ると、約20倍の向上が見えてきます。これは基本的に、現在のあらゆるTransformer-SSMハイブリッドモデルのKVキャッシュ使用量を完全に打ちのめします。ですが、Transformer-SSM陣営は、Transformer層にDSV4のCSAとHCAを使うだけで追いつけます。
このKVキャッシュ使用量なら、llama.cppでDSV4がサポートされたとき、DSV4 Flashなら256GB RAMと3090で1mコンテキストを簡単に実行でき、DSV4 Proなら1.5TB RAMとRTX 6000 Blackwellで実行できるはずです。論文中に言及されているさまざまな速度向上によって、それが現実的になるのだと思います。
DSV4 Proは人工的な解析（Artificial analysis）ではあまり良くないようです。ですが、KimiやZhipuがそこから派生させて、KVキャッシュが非常に少ない“怪物”を作ることを期待できます。
総じて、DSは中国のAIシーンにおける研究の中核（バックボーン）として、依然としてとても好調です。
PS 興味のある人向けに、もう少し詳しい計算です。計算で何か間違いがあれば教えてください：
llama.cppで実際にV3.2を動かして見えているものに基づくと、DSV3.2の実際のFP16 KVキャッシュ使用量は、160kコンテキストで10.72GiB、仮想的な1mコンテキストで68.625GiBです。
この数値は、トークンごと・層ごとのMLA KVキャッシュの式で検証できます：（kv_lora_rank + qk_rope_head_dim） * precision = (512 + 64) * 2 = 1152バイト。したがって、61層で1mトークンなら 1152*61*1024*1024 = 68.625GiBとなり、これは50GBではありません。
一方で、DSV4 Proの場合は、30のCSA層と31のHCA層が交互に入っています。私の理解では、CSAはMLAのKVキャッシュの1/4だけを保存するので、1トークンあたり・層あたりは288バイト、HCAはMLAのKVキャッシュの1/128だけを保存するので、1トークンあたり・層あたりは9バイトです。したがって、KVキャッシュは (288*30+9*31)*1024*1024 ≒ 8.70996GiB になります。よって、KVキャッシュの削減は9.5倍ではなく7.879倍です。
DSV4 Flashでは、最初の2層はウィンドウサイズ128トークンのSliding Window Attentionです。通常、この2層における、任意の長さが128を超える場合の層ごとのKVキャッシュは 2*n_head_kv*head_dim*precision*window = 2*1*128*2*128 = 65536バイトになります。現在のllama.cppの実装では、より良いバッチ処理のためにウィンドウに256バイトを追加しており、2*1*128*2*(128+256) = 196608バイトになります。
DSV4 Flashには21のCSA層と20のHCA層があるため、1mコンテキストでのKVキャッシュは (288*21+9*20)*1024*1024+2*196608 = 6.0824GiBです。これはDSV3.2に比べて11.3倍の削減であり、主張されている13.7倍ではありません。
[link] [comments]
