自己部署大模型，显存不够、速度慢一半？DeepSeek 把生产级推理框架开源了（2.6 万星）
github监控器 · 2026-11-10 · 约 3414 字 · deepseek-ai/DeepInfer
你想在自己机器上跑一个大模型，结果两张卡都不够，速度还只有官方的三分之一。问题多半不在模型，在推理框架。
DeepInfer 是 DeepSeek 线上服务用的那套推理框架，现在把离线推理部分开源了。2.6 万星，每天涨 993 星，Apache-2.0。
它不教你"怎么部署"，它给的是一套已经在上亿次请求里跑过的默认配置：哪些 kernel 该开、并行怎么切、采样怎么保证确定性。下面按"能不能编过、编过怎么跑"讲。
一、先说结论：它解决的是「同样的卡，跑得更快」
大模型推理的性能瓶颈有三个层次，很多人只盯着第一个：
这三层都优化过，才有"同样的卡跑得更快"。只换一个更快的算子，收益是个位数；三层一起调，才是数量级的差别。
二、它开源了什么，没开源什么
README 的第一句很关键：
"DeepInfer is the high-performance inference framework that powers DeepSeek's large-scale production services. This open-source release provides offline inference..."
两个信息：
- 它是生产框架，不是实验项目——这意味着它的默认配置是被真实流量打磨过的；
- 开源的是 offline inference，即离线批量推理，不是在线服务那一套调度。
这个边界很重要。你要做的是"批量跑数据"，它正合适；你要做的是"对外提供 API 服务"，还得自己补一层。
三、支持什么模型，支持哪些能力
目前明确支持的是 DeepSeek-V4.1-Flash。能力清单我按"对性能的影响"重排：
第四行和第五行是"能不能塞进你的卡"的关键；第六、七行是"能不能用在生产"的关键——结果不可复现的推理框架，没法做 A/B。
四、编译：三个前置，一个坑
从源码编译。pyproject.toml 里的构建依赖写得很清楚：
[build-system]
requires = ["ninja", "setuptools >= 77.0.3", "torch >= 2.7"]
build-backend = "setuptools.build_meta"所以前置是三样：ninja、setuptools ≥ 77、torch ≥ 2.7。
坑在 torch 版本上。你的 CUDA 版本决定了能装哪个 torch，torch 版本又决定了它能不能编过。顺序是：先定 CUDA，再选 torch，最后编。
反过来的顺序（先 pip install torch，再看 CUDA）是最常见的失败路径。
编译前建议先跑一遍环境自检：
python -c "import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())"
ninja --version三个都正常再开始编。少一个都会在编译中途报错，而且报错信息往往指向 C++ 而不是环境。
五、跑起来：模型从哪来
默认 checkpoint 是 deepseek-ai/DeepSeek-V4.1-Flash-1017，第一次运行会自动下载到 Hugging Face 缓存。
如果你已经把模型下到本地，用环境变量指过去：
export DEEPINFER_HF_MODEL_DIR=/path/to/your/model这条很重要。自动下载在国内网络下经常卡住，而且几十 GB 的模型重下一次很痛。先手动下好、再指过去，省一小时。
另外一个控制解码加速的开关：
export DEEPINFER_ENABLE_MTP_VARLEN=1MTP 是 multi-token prediction，varlen 是变长。开了它会用草稿 token 加速解码，但不是所有场景都更快——短输出场景下开销可能盖过收益。自己测。
六、并行怎么切：一张决策表
这是最实际的配置问题。按你的机器形态选：
第二行和第四行是配套的。MoE 模型的通病是"热门专家挤爆、冷门专家空转"，EPLB 就是治这个的。
先用默认配置跑通一次，再改并行。一上手就调并行参数，出错了你分不清是配置问题还是环境问题。
七、显存怎么估：别信"最低配置"
README 给了性能基准，但没给"你需要多少显存"。这个要自己算，公式是：
显存 ≈ 权重（参数量 × 每参数字节）+ KV cache（并发 × 上下文 × 层数 × 头数 × 2）两个容易算错的地方：
- 权重的"每参数字节"取决于量化——FP16 是 2 字节，FP8 是 1，Q4 是 0.5；
- KV cache 才是真正的变量——它跟并发数线性相关，跟上下文长度线性相关。你要跑 32K 上下文 × 8 并发，KV cache 可能比权重还大。
所以"我 24G 显存能跑 70B 吗"这种问题没有统一答案，取决于你的上下文长度和并发数。先定这两个，再算显存。
八、七个坑
- torch 版本和 CUDA 不匹配。 先定 CUDA 再选 torch，别反过来；
- 没装 ninja。 它要编译自定义 kernel，没有 ninja 会退化成慢速路径；
- 模型自动下载卡住。 先手动下好，用
DEEPINFER_HF_MODEL_DIR指过去； - 单卡也去调并行。 通信开销大于收益；
- 无脑开 MTP。 短输出场景可能更慢，要测；
- 信"最低显存"。 官方基准是特定上下文和并发下的数，不是你的场景；
- 拿离线框架做在线服务。 它开源的是 offline inference，服务化要自己补。
九、和其它推理框架怎么选
这一节是我自己的判断，不是 README 的内容：
关键判断点：它的优化是围绕 DeepSeek 模型结构做的（MLA、MoE、MTP），换个模型架构，很多 kernel 用不上。
十、谁该用
十一、版本与地址
examples/ 目录 |
包名: deepinfer
版本: 0.1.0
许可: Apache-2.0
模型: DeepSeek-V4.1-Flash
关键环境变量: DEEPINFER_HF_MODEL_DIR / DEEPINFER_ENABLE_MTP_VARLEN最后一句：这个项目的价值不在"又一个推理框架"，而在于它把 生产环境的默认值 摊开了——哪些 kernel 值得开、并行该怎么切、什么时候该牺牲吞吐换一致性。这些经验平时写在内部文档里，不会公开。
AI 实战导师 / 企业 AI 落地顾问 / 智能体工程师，17 年跨界、15,000+ 小时 AI 实操、20+ 套已交付工作流。
发表评论: