DeepSeek 和北京大学最近开源了一个叫 DSpark 的推理框架，核心特点是重新设计了显存和计算之间的协同调度，让 LLM 推理效率提升非常明显。
这个框架跟已有的 vLLM / SGLang 有什么不同？
现有的推理框架主要在算子融合、KV cache 管理、continuous batching 这些层面做文章。DSpark 的思路不太一样：它更关注显存访问模式——把计算和显存移动尽量重叠，减少 GPU 核心等待数据的空闲时间。
几个我看到的技术点：
- 流水线化的显存预取：在计算当前 batch 的同时，预先把下一个 batch 需要的权重和 KV cache 搬进 SRAM，降低 memory-bound 的影响。
- 自适应分块策略：根据序列长度和 batch 大小动态调整分块参数，不是固定算子尺寸。
- 算子级计算-显存重叠：在算子内部就把访存和计算指令交替排列，不是只靠全局调度。
从披露的测试数据看，在 H800 上对 DeepSeek V2 系列的推理场景，端到端 decode throughput提升了约 60-85%，首 token 延迟也有明显改善。
对部署的影响
如果数据属实，这类协同调度优化可能比单纯换更大的显存带宽更划算。对部署来说：
- 同等硬件能支撑更多并发：特别是高并发短序列场景（搜索推荐类、代码补全、客服对话），效果比长序列场景更突出。
- 功耗方面有附带好处：计算和访存重叠意味着同样时间内 GPU 利用率更高，完成同样数量的请求更快，从而整体能耗更低。
- 现有的量化策略不冲突：DSpark 在 FP8/INT4 量化模型上同样适用，可以配合使用。
另外 DeepSeek 同一时期还开源了 DeepSpec——一套专门训练和评估 speculative decoding 草稿模型的完整工具链。两者相互补充：DeepSpec 负责训练更好的草稿模型，DSpark 负责在推理时把协同调度做到极致。两者的结合思路其实指向同一个方向：推理优化不再只是 serving 层的事，也需要从模型训练侧和硬件调度侧同时下手。
值得探讨的问题
- 这种显存-计算协同调度能否做成通用 runtime 层，还是需要针对每代硬件重新适配？
- 在推理芯片百花齐放的今天（NVIDIA / AMD / 昇腾 / GraphCore），这类框架相比纯 CUDA 优化的方案有多大可移植性？
- DSpark 和 DeepSpec 的组合已经接近生产级了，还是更适合实验室场景？
内容来源：
- VentureBeat: DeepSeek open sources DSpark framework
- Open Source For You: Peking University, DeepSeek Open-Source DSpark
- GitHub DeepSpec: speculative decoding training framework