高效推理技术的价值，需要通过实际部署才能进入业务。
DeepSeek 开源 DeepInfer，为开发者提供了探索其推理技术的入口。对于希望在自有基础设施上运行模型的团队，接下来还需要解决一系列工程问题：如何提供 API 、如何配置运行环境 、如何管理 GPU ，以及如何评估它在实际工作负载中的表现。
这次，我们通过一个轻量服务项目 DeepInfer-server ，将 DeepInfer 接入 GPUStack 的自定义推理后端，在单机八张 NVIDIA B200 上跑通了 DeepSeek-V4.1-Flash 的文本推理服务。
本文介绍这套集成的组成、部署流程，以及与 vLLM 在相同硬件上进行对比的方法。
一、DeepInfer 带来了什么？
DeepInfer 是 DeepSeek 开源的高性能推理框架。当前公开版本提供离线推理及面向规模化服务的核心引擎能力 ，支持 DeepSeek-V4.1-Flash，并集成了 FlashMLA、DeepGEMM、DeepEP、DeepSelect 等计算与通信组件。它还提供多种并行策略、推测解码和异步调度等能力。DeepInfer 官方仓库
这些组件共同作用于模型推理的不同环节：计算执行得更快，GPU 之间的数据交换更高效，调度能够更充分地利用硬件。对使用者而言，最终关注的是相同资源下可以服务多少请求，以及用户需要等待多久。
不过，将引擎接入业务 ，还需要完成请求处理 、协议转换 、HTTP 服务 和部署管理。
此次集成中，各组件的分工如下：
| 组件 | 在本次集成中的作用 |
|---|---|
| DeepInfer | 执行模型推理，管理底层计算、通信与并行运行 |
| deepseek-recipe | 将聊天请求转换为模型输入，并解析模型输出中的文本、思考内容和工具调用 |
| DeepInfer-server | 连接上述组件，提供 HTTP API、流式响应及服务生命周期管理 |
| GPUStack | 管理模型部署、GPU 分配、运行配置，并提供模型访问与测试入口 |
其中，deepseek-recipe 是 DeepSeek 提供的协议转换与编解码组件。它负责在 API 请求、对话格式、模型 token 序列和响应之间转换；模型推理与 HTTP 传输由调用方提供。deepseek-recipe 官方仓库
为什么还需要编写 DeepInfer-server？
DeepInfer 当前公开版本的入口主要面向离线推理。要像运行 vllm serve 一样启动一个可供应用调用的服务，还需要把引擎接入 HTTP 请求处理流程。deepseek-recipe 提供了协议转换与输出解析能力，但实际模型推理和 HTTP 传输仍需由调用方接入。仅将两个组件安装到同一个容器中，还不会自动得到完整的在线推理服务。
GPUStack 的自定义后端定义负责告诉平台"用哪个镜像、以什么命令启动、传入哪些参数"，并不会自动为离线引擎生成 API。因此，本次集成需要一层连接代码，将组件组织成可启动、可检查状态、可接收请求的服务。
DeepInfer-server 承担的就是这层服务封装：
- 连接请求与推理。接收 Chat Completions 请求，交给 deepseek-recipe 转换为模型输入，再调用 DeepInfer 执行生成。
- 将输出交给应用。把生成的 token 转换为文本、思考内容或工具调用，返回普通 JSON 或 SSE 流式响应，并报告 token 用量。
- 管理服务运行。初始化推理进程，处理请求分发、取消、超时和异常，提供模型列表与健康检查接口。
- 接入部署平台。提供容器镜像和常用启动参数，让 GPUStack 能够传入模型路径、端口及 GPU 配置，启动并管理服务。
这样，应用可以通过熟悉的 OpenAI Chat Completions 兼容接口调用模型，GPUStack 则可以沿用自定义后端的部署流程。底层推理仍由 DeepInfer 完成，协议转换与解析复用 deepseek-recipe。
当前封装聚焦单机多 GPU 的文本推理。它是用于验证集成的独立演示项目，并未补齐 DeepSeek 生产系统的完整 KV cache 管理、Prefill/Decode 分离和负载均衡架构，也不能直接等同于 DeepSeek 官方线上服务。
二、通过 GPUStack 自定义后端，部署 DeepInfer
GPUStack 的自定义推理后端机制允许用户声明容器镜像、启动命令、默认参数和环境变量，将新的推理服务纳入部署流程。模型路径、端口等信息可以通过模板变量在部署时传入。GPUStack 自定义后端文档
这意味着，团队可以在同一个平台中尝试新的推理引擎，复用已有的模型管理和部署操作。
本次集成提供了配套定义文件：
text
gpustack-deepinfer-server-backend.yaml第一步 ：准备运行环境
本次演示使用同一台八卡 NVIDIA B200 服务器，模型为：
text
deepseek-ai/DeepSeek-V4.1-Flash-1017
部署前，需要准备完整模型权重、DeepInfer-server 镜像，以及满足要求的 GPU 驱动、容器运行环境和主机内存。
这套配置还需要正确暴露 RDMA 设备并配置通信环境。配套 YAML 中的网卡与网络参数来自本次验证环境，其他服务器应根据实际配置调整。
第二步 ：导入自定义后端
在 GPUStack 的推理后端管理页面，新建自定义后端并导入 DeepInfer 推理后端的 YAML 声明。
定义文件包含服务启动方式、常用参数、健康检查路径，以及 JIT 缓存目录等配置。GPUStack 会在部署时传入模型路径、服务端口、模型名称和分配到的 GPU 数量。
第三步 ：创建模型部署
创建模型部署时，选择对应的模型权重，将推理后端设为前述步骤添加的 DeepInfer-server。
为与后文的性能对比保持一致，本文部署示例使用以下配置。在模型的后端参数中显式设置 --expert-parallel-size=8、--data-parallel-size=8、--context-parallel-size=1，覆盖配套 YAML 中的 DP=1 默认值，并检查最终启动配置。
| 配置项 | 示例值 |
|---|---|
| GPU 数量 | 单机 8 卡 |
| 并行配置 | EP=8、DP=8、CP=1 |
| 最大上下文长度 | 32,768 tokens |
| 最大同时运行序列数 | 每个 DP rank 为 16 |
| 每个 DP rank 的批处理 token 预算 | 32,768 |
| GPU 内存利用率参数 | 默认 0.85 |
| 启动超时 | 3,600 秒 |
EP、DP、CP 分别表示专家并行、数据并行和上下文并行。当前封装要求 DP × CP = EP；这里设置 CP=1，不进行跨卡上下文切分。max-num-seqs=16 是每个 DP rank 的上限，DP8 下服务总接纳上限为 128。
首次启动需要加载权重 ，并可能进行内核编译与预热。GPUStack 中可以查看启动日志，待模型初始化完成后再进行推理测试。持久化 JIT 缓存有助于复用编译产物。
第四步 ：验证推理
模型就绪后，可以在 GPUStack 的 Playground 中发送文本请求，检查流式输出，也可以通过 API 接入现有应用。
至此，从模型权重、推理引擎到 API 调用的链路已经打通。团队可以继续在这一基础上测试业务提示词、观察资源使用，并评估进一步优化的收益。
三、同样八张 B200，与 vLLM 如何比较？
在看数据之前 ，先说明本次比较的范围。
本次测试是服务集成与初步性能验证。两边的部署配置均未针对当前硬件完成最优调优，也与 DeepSeek 实际生产推理系统的部署架构存在差别。由于当前公开的 DeepInfer 没有提供与 vLLM 对应的 TP（张量并行）路径，我们选择让 DeepInfer 使用 CP1、DP8、EP8，让 vLLM 使用 TP1、DP8、EP8，以便在更接近的并行策略下比较。该选择用于减少部署策略差异，不代表任何一方的最佳配置。
DeepInfer 官方介绍的并行能力是 Attention DP / balanced CP，以及 MoE EP + EPLB。本次采用单机合并运行的服务，没有复现其生产系统的 Prefill/Decode 分离、完整 KV cache 管理和负载均衡架构。DeepInfer 官方说明
即使都采用 DP8+EP8，两边的内核、通信、Engram 访问和调度实现仍然不同。DeepInfer-server 还包含本次演示编写的请求协调与协议处理逻辑，其开销计入服务端到端表现。本文结果不能代表 DeepSeek 官方服务性能，也不能用来判断两个引擎的性能上限。
先看日常聊天体验
完成部署后，我们先通过 GPUStack Playground 体验单请求聊天。下图中，vLLM 的界面显示输出速度约为 91.4 tokens/s ，展示了当前配置下的一次交互表现；相比之下，DeepInfer 的输出速度约为 106.2 tokens/s，略胜一筹。
单次聊天的速度会受到提示词、上下文、回答长度及界面统计口径影响。这张截图用于展示交互体验，不作为两种引擎的单请求性能排名，也不能直接与下文的并发输出吞吐混用。下面将并行策略调整为两边均采用 DP8+EP8，再通过 8K 输入、1K 输出、16 并发的 Benchmark 观察批量请求表现。
测试环境与配置
本轮测试使用同一台八卡 B200 服务器和同一版本模型权重，通过 GPUStack 提供的 Benchmark 功能，以并发 16 发起 100 个请求。
| 项目 | DeepInfer-server | vLLM |
|---|---|---|
| 硬件 | 8 × NVIDIA B200，同一 Worker | 8 × NVIDIA B200，同一 Worker |
| 模型 | DeepSeek-V4.1-Flash-1017 | DeepSeek-V4.1-Flash-1017 |
| 版本 | DeepInfer 固定提交 9bd9cf2，服务镜像标签 latest |
0.32.0 |
| 并行策略 | DP8、CP1、EP8 | DP8、TP1、EP8 |
| 最大上下文长度 | 32,768 tokens | 32,768 tokens |
max-num-seqs |
16 / DP rank | 16 / DP rank |
max-num-batched-tokens |
32,768 / DP rank | 32,768 / DP rank |
| GPU 内存利用率参数 | 0.85 | 0.85 |
| 推测解码 | 关闭 | 关闭 |
| 数据集 | Random | Random |
| 目标输入 / 输出长度 | 8,192 / 1,024 tokens | 8,192 / 1,024 tokens |
| 客户端目标并发 | 16 | 16 |
| 请求数量 | 100 | 100 |
先看 GPUStack 中的原始结果
将两份报告的主要指标放在一起：
| 指标 | DeepInfer-server：DP8+EP8 | vLLM：DP8+EP8 |
|---|---|---|
| 成功请求数 / 总请求数 | 100 / 100 | 100 / 100 |
| 平均输出吞吐量（tokens/s） | 1,392.44 | 1,112.20 |
| 平均首 token 延迟 TTFT（秒） | 4.28 | 2.04 |
| P95 首 token 延迟 TTFT（秒） | 16.33 | 8.27 |
| 平均 token 间隔 ITL（毫秒） | 8.74 | 11.98 |
| P95 token 间隔 ITL（毫秒） | 8.93 | 13.70 |
| 平均请求端到端延迟（秒） | 13.23 | 14.30 |
| P95 请求端到端延迟（秒） | 25.46 | 20.03 |
| 实际平均并发 | 14.72 | 14.58 |
输出吞吐、TTFT、ITL 和请求延迟分别取自导出报告的 output_tokens_per_second_mean、time_to_first_token_*、inter_token_latency_* 与 request_latency_* 字段。表中将 TTFT 从毫秒转换为秒。输出吞吐沿用报告的平均统计口径，不将其直接换算为整轮测试耗时；ITL 也不与报告中的 time_per_output_token 或逐 SSE chunk 间隔混用。
四、这组数据说明了什么？
在本轮 DP8+EP8 的两次运行中，DeepInfer-server 的报告平均输出吞吐更高 ，生成阶段的平均 token 间隔更短 ；vLLM 的首 token 等待和请求尾部延迟更低。
具体来看，DeepInfer-server 的报告平均输出吞吐比对应 vLLM 运行高约 25.2% ，平均 ITL 低约 27.0% ，平均请求端到端延迟低约 7.5%。这些是本次实测值之间的差异，尚不构成稳定性能提升的证明。
同时，DeepInfer-server 的平均 TTFT 为 4.28 秒，约为 vLLM 2.04 秒的 2.09 倍 ；P95 请求延迟为 25.46 秒，比 vLLM 的 20.03 秒高约 27.1%。用户等待第一段回答的体验，以及少部分较慢请求的表现，仍有改进空间。
这种差异提示我们，评估推理服务需要同时看吞吐 、首 token 延迟 、持续生成速度 和尾部延迟。对于交互应用，更快开始回答很重要；对于批量生成任务，单位时间完成的输出量也很重要。只选取其中一个数字，无法完整描述服务体验。
两套 DP8+EP8 配置都完成了 100 个请求，验证了本轮负载下的服务可用性。100 次成功请求并不等同于生产稳定性认证，本轮 Random 数据测试也不承担模型回答质量评测。
对 GPUStack 而言，这次实践展示了一个可复用的过程：通过自定义后端接入新引擎 ，在统一平台完成部署与测试 ，再根据实际数据选择适合业务的运行方式。后续我们会在固定提示词与测试条件的基础上，继续验证不同并发下的表现，并定位服务封装与引擎执行各自的开销。
五、持续跟进，让高效推理更容易被使用
DeepInfer 的开源，为推理优化提供了更多可研究、可验证的实现。
与此同时，DeepSeek 在官方部署问答中明确说明，KV cache 管理与负载均衡组件与内部基础设施耦合较深，目前尚未完整开源。官方也表示，后续 DeepSeek 模型的推理代码及性能优化 将继续在 DeepInfer 中开源。DeepSeek 官方部署问答
这为后续集成留下了值得关注的空间。未完整开源组件的具体发布时间与范围，仍应以官方后续公告为准。
GPUStack 将持续关注 DeepInfer 及相关计算、通信、编解码组件的进展，在组件可获取、可验证的基础上推进集成，并通过实际部署和测试评估其价值。
我们希望，新的推理技术能够更快进入开发者和企业的实际环境：降低尝试门槛，让性能收益可以复现，让资源成本可以衡量，让更多团队用得起、用得好大模型。
让低成本推理普惠 ，需要持续的技术优化，也需要让这些优化更容易部署和使用。
GPUStack 项目入口：github.com/gpustack/gpustack
DeepInfer-server 仓库：github.com/gpustack/DeepInfer-server
GPUStack 使用文档：docs.gpustack.ai
附录：参考截图
环境信息
等待模型部署启动就绪
DeepInfer 单并发推理实测数据
测试配置：16 并发、100 请求、8K ISL、1K OSL。
相同硬件资源下的 vLLM 单并发推理实测数据
加入 GPUStack 社区
GPUStack 社区聚焦 AI 基础设施与大模型实践。
社区中持续分享真实环境下的部署经验、问题排查案例，以及推理引擎、算力管理和系统架构相关讨论。
欢迎扫码加入 GPUStack 社区，与更多关注 AI Infra 与大模型推理实践的伙伴一起交流 、学习 与分享。
若群聊已满或二维码失效，请访问 GPUStack 社区二维码 查看最新信息。
About GPUStack
GPUStack 是由 GPUStack.ai 推出的开源项目。GPUStack.ai 成立于 2022 年，是 AI Infra 解决方案提供商，目前已完成两轮、共计 1.03 亿元融资，包括 5,300 万元种子轮融资及 5,000 万元 Pre-A 轮融资。创始团队成员均来自业界应用广泛的 Kubernetes 管理平台 Rancher 核心团队。其中，联合创始人兼 CTO 梁胜博士曾任 SUSE 全球工程及创新总裁；加入 SUSE 之前，他于 2014 年 9 月创立 Rancher Labs 并担任 CEO。
我们的愿景是赋能企业在任意环境中使用人工智能，实现业务的卓越运营。GPUStack 是实现这一目标的重要一步。
使用 GPUStack，迅速搭建你的专属 MaaS 平台！从本地快速构建 GPU 集群开始，运行和使用各类 AI 模型，为 AI 应用提供支持。
【开源地址】：github.com/gpustack/gpustack