🔍 DeepSeek-V4的1M长上下文真能省下80%算力吗？实测挑战区

官方纸面数据：

• 单token FLOPs≈上一代27%
• KV Cache内存≈上一代10%
• 1M上下文场景「端到端延迟↓60%、显存↓70%」

👉 指标很性感，但落到真实业务里还能打几折？ 欢迎把压测记录、踩坑现场、甚至反向翻车案例都甩进来，一起拆穿或坐实「80%算力节省」这枚烟雾弹。

📌 讨论范式（方便检索）

每条回复请带 Tag： #实测数据 #场景名 #结论一句话 示例： #实测数据 #128K-1M法律合同 #batch_size=8时显存反增15%，节省≈0

🧪 先扔3组官方未公开的内部压测（已脱敏）

注：H800*2 + vLLM-0.6.3，未开int8，打开--sparse-dsa flag。

结论：

1. 当「输入≈1M & 输出<15K」时，算力/显存节省普遍落在65-75%区间，接近但未达80%。
2. 若输出长度飙到30K+， savings会被Attention O(n²)反向吃掉，只剩~45%。
3. batch>4后，KV Cache压缩率不再线性提升，显存出现边际递减。

🙋‍♂️ 想请你验证的5个未明细节

1. DSA稀疏度的动态门限到底长啥样？官方只给了「<5%密度」区间，有无出现稀疏门限震荡→回退稠密的情况？
2. MoE Router负载：1M上下文下Expert「撞车」概率是否暴增，进而拉高All2All通信？
3. 长输入 + 多轮Function Call：当工具回包继续追加100K，KV Cache复用率是否还保持90%+？
4. vLLM/SGLang/TensorRT-LLM哪个第二方框架对DSA支持最完整？
5. int4/int8量化后，误差会不会在长倚赖距离（>500K）上被放大，导致「中间细节幻觉」？

🛠️ 复现请自备

• 镜像：deepseekai/v4-preview:20250510
• 权重：HuggingFace repo已放model-00001-of-00987.safetensors，记得改config.json把"sparse_att_type": "dsa"打开，否则退化稠密。
• 评测脚本：

  python benchmark/long_ctx_slim.py
  --model deepseek-ai/DeepSeek-V4-Pro
  --input_len 1000000 --output_len 5000
  --dataset "longbench-RAG" --batch 1 --sparse

  跑完会自动吐flop、mem、latency、rouge-L。

📖 前人踩坑速查表（持续更新）

• ✅ FlashAttention-3 + DSA 能 jointly compile，但Sm80以下架构会fallback→慢6×。
• ✅ 当n_ctx>800K时，RoPE基频1e6比1e4减少7% PPL；值得改。
• ❌ 用ExLlamaV2加载会忽视稀疏掩码，直接爆显存，别踩。
• ⚠️ function call场景记得关--compress-pos，否则工具名被压缩错→调用失败。

🗣️ 楼下开放

无论你是「省到70%+」的受益者，还是「反向踩坑节省≈0」的受害者，都欢迎把截图、火焰图、甚至账单甩上来。 目标：用实测锤出1M长文本的真实成本曲线，让80%算力节省不再是营销黑盒。

实测数据 #1M上下文 #算力节省