摘要：Deepseek-r1模型的迅速走红，显著提升了本地部署大型语言模型的需求。本文旨在深入探讨如何优化本地部署大型模型的性能，并结合我们的实际操作经验进行评测与分析。在文章的结尾部分，我们将详细分享如何在本地高效部署功能完备的Deepseek-r1大型模型。

一、背景概述

Deepseek-r1模型的迅速走红，显著提升了本地部署大型语言模型的需求。本文旨在深入探讨如何优化本地部署大型模型的性能，并结合我们的实际操作经验进行评测与分析。在文章的结尾部分，我们将详细分享如何在本地高效部署功能完备的Deepseek-r1大型模型。

在生产环境中，我们已经成功部署了专用的大型模型推理集群，并对其性能进行了全方位优化。对于大型模型的推理而言，性能优化主要聚焦于两个核心指标：吞吐量和响应时间（RT）。吞吐量方面，我们传统上使用每秒请求数（QPS）来衡量，即系统每秒能够处理的请求数量。然而，对于大型模型来说，每秒Token数（Token/s）同样是一个重要的性能指标，它反映了系统每秒能够处理的输入或输出Token的数量。响应时间（RT）则是指系统处理每个请求所需的时间。对于支持流式输出的大型模型，我们还需要额外关注一个关键指标——首个Token到达时间（TTFT），即从系统开始处理请求到输出第一个Token所需的时间。

接下来，本文将详细介绍部署高性能大型模型推理服务的方法与思路，这些方法和思路主要围绕提升吞吐量和响应时间这两个核心指标而展开。

二、构建高性能、易扩展的大模型推理框架的核心理念

尽管业界已涌现出众多成熟的大模型推理框架，但在深入探索这些框架之前，我们首先需要思考的是，如何打造一款既具备卓越性能又易于扩展的大模型推理框架。以下是大模型推理框架设计需满足的核心条件：

高性能的基石——CPU与GPU的分离设计

对于以python为主的大模型GPU推理引擎而言，实现高性能的关键在于CPU与GPU的分离设计。这一设计通常要求将系统划分为两个独立的进程：CPU进程与GPU进程。CPU进程专注于处理与CPU相关的任务，如序列化、调度、分发及Resize等；而GPU进程则专注于GPU推理逻辑，其底层通过直接调用CUDA等高性能计算库来完成GPU运算。

目前，主流的大模型推理框架，如vllm与sglang，已广泛采用或正在逐步实施CPU与GPU的分离架构。这一设计究竟带来了哪些优势呢？

Python的运行时机制中，全局解释器锁（GIL）限制了同一时间内只有一个线程能够执行Python字节码。这意味着，在多线程Python程序中，线程间的并行执行受到GIL的限制。这一设计虽简化了内存管理和对象引用计数，确保了线程安全，但在以GPU计算为主导的推理服务中，却成为了性能提升的障碍。

在单一的Python进程中，若同时存在多个CPU密集型任务（如网络请求处理、数据预处理及请求验证等）与GPU任务，它们将共享GIL。这导致CPU密集型任务与GPU任务相互竞争GIL，造成GPU kernel启动调度不足，进而形成性能瓶颈。具体表现为GPU利用率低下，在高并发场景下，GIL的竞争显著影响系统的响应速度和吞吐量。

我们通过专项对比测试发现，采用CPU与GPU分离设计后，GPU利用率大幅提升，QPS提高了7倍，响应时间（RT）缩短了50%。以VLLM为例，在其0.6版本中，通过实施CPU与GPU进程分离设计，性能得到显著提升，吞吐量提高了2.7倍，具体可参见相关文章。

易扩展的保障——模块的高内聚与低耦合

为实现高效且易于扩展的设计，我们应将系统按功能划分为多个模块，确保每个模块仅负责其特定功能，实现模块内部的高内聚和模块间的低耦合。一个完善的大模型推理框架至少应包含以下四个核心模块：

综合上述内容，我们可以设计出一个高性能、可扩展的大模型推理框架。该框架将系统划分为多个进程（包括多个CPU进程与GPU进程），进程间通过管道等高效通信方式进行数据交换。同时，系统在逻辑上被划分为多个模块，其中接入层、调度器、模型推理层和显存管理模块是不可或缺的组成部分。这一架构也是当前vllm 1.0与sglang等经典推理框架所采用的基础架构。感兴趣的朋友可以查阅相关代码，深入了解其设计思路。例如，sglang推理引擎的代码就提供了很好的参考。

三、显存碎片问题的革新解决方案：Paged Attention技术

在Linux等操作系统环境中，应用程序通常无需担忧内存碎片问题，这得益于Linux内核所提供的强大内存管理机制。然而，这一优势并不适用于GPU显存。在GPU上频繁申请和释放大小不规则的显存空间，极易导致显存碎片的产生。

在大模型推理场景中，显存碎片问题变得尤为棘手。推理过程中广泛涉及的注意力计算（Attention）机制，需要频繁申请和使用名为kvcache的缓存。随着请求数量的不断增加，kvcache的大小和数量会随之攀升，通常占据总显存的三分之一左右，并且会经历频繁的申请和释放过程。若缺乏有效的显存管理策略，显存碎片将不断累积，最终可能引发系统性能的显著下降甚至崩溃。

为了应对这一挑战，vllm创新性地提出了Paged Attention技术。该技术的设计灵感源自于操作系统的内存管理机制，旨在实现对kvcache显存的统一高效管理。

Paged Attention技术借鉴了操作系统虚拟内存和分页机制的核心原理。它将大型语言模型中的KV Cache缓存划分为一系列固定大小的块，这些块在内存中可以非连续存储。通过引入类似Linux页表的Block table结构，Paged Attention能够将每个请求的逻辑KV块映射到物理KV块中。这种映射机制不仅有效避免了显存碎片的产生，还显著提升了系统的吞吐量。

在评测效果方面，Paged Attention技术展现出了卓越的性能。通过高效的内存管理策略，它显著减少了内存浪费，提高了GPU的利用率，使得模型的推理吞吐量相较于传统方法实现了数倍的提升。具体而言，与HuggingFace Transformers相比，吞吐量可提升至24倍；与HuggingFace TGI相比，提升幅度也可达到3.5倍。此外，Paged Attention技术还降低了内存开销，支持更复杂的采样方法，使得LLM服务变得更加快速、经济高效。

目前，VLLM与SGLang等主流推理引擎已经默认支持Paged Attention技术的开启。因此，当你使用这些推理引擎部署大模型时，系统将自动享受Paged Attention技术所带来的性能提升和显存管理优化。

四、优化重复计算：Radix Attention技术引领大模型推理新风尚

尽管Paged Attention技术已经成功解决了显存碎片问题，并显著提升了系统吞吐量，但在大模型推理的实践中，我们仍然发现存在大量的性能优化空间，特别是在处理包含重复Prompt内容的请求时。

在实际应用中，我们经常会遇到需要多次向大模型发送请求的场景，而这些请求中的Prompt往往包含大量相同的内容。例如，在系统提示、用户消息或聊天历史等部分，都可能存在可共享的前缀或重复片段。这些重复的计算不仅浪费了计算资源，还降低了系统的整体性能。

为了有效解决这一问题，SGLang团队提出了一种创新的算法——Radix Attention。该技术旨在通过优化KV缓存的重用，来减少大模型推理过程中的重复计算和内存占用。

Radix Attention技术的核心在于利用基数树（Radix Tree）这一数据结构，来高效管理和重用不同请求之间共享的前缀。当多个请求包含相同的前缀时，Radix Attention可以智能地重用该前缀对应的KV缓存，从而避免不必要的重复计算。

在Radix Attention的工作流程中，基数树扮演着至关重要的角色。随着聊天会话的进行，基数树会动态地演变和扩展，以容纳新的请求和消息。通过智能地分割和重用节点，Radix Attention能够确保在内存限制下，最大化地重用KV缓存，并减少冗余计算。

那么，Radix Attention技术的性能表现如何呢？为了验证其效果，我们进行了对比评测。结果显示，与VLLM (v0.5.0)相比，Radix Attention充分利用了不同请求之间的共享前缀，其耗时减少了30%，吞吐量则提升了1.5倍。这一显著的性能提升，充分证明了Radix Attention技术在大模型推理中的优势和潜力。

此外，SGLang团队还给出了Radix Attention与当前系统的性能对比效果。结果显示，与现有系统相比，SGLang的吞吐量提升了5倍以上。这一惊人的提升幅度，再次彰显了Radix Attention技术的卓越性能和实际应用价值。

如果你也想体验Radix Attention技术的魅力，不妨尝试使用SGLang的推理引擎来启动大模型进行推理。相信你会被其出色的性能和高效的计算效率所折服。

五、优化请求处理：Chunked Prefill策略降低卡顿风险

在大模型的实际应用中，我们可能会遇到一种令人困惑的现象：尽管系统的平均响应时间保持在正常水平，但偶尔会有某个请求的响应时间异常延长，甚至出现卡顿。这种现象的根源何在？又该如何有效应对呢？

大模型的推理流程通常涵盖两个阶段：prefill阶段和decode阶段。以输入1000个token的prompt并要求模型生成100个token的响应为例进行说明。在prefill阶段，系统会对这1000个token进行并行处理，充分利用GPU的并行计算能力来提升效率。而在decode阶段，则需要按顺序逐个生成后续的100个token，因为每个新生成的token都依赖于之前的输出结果。

然而，在实际应用中，多个请求往往会同时进行推理，这就可能导致不同请求的阶段发生交叉运行。特别是当某个请求的prefill阶段处理了一个特别长的prompt时，它会大量占用GPU资源。如果此时其他请求的decode阶段与该请求并行运行，就可能会因为资源争抢而导致decode阶段的响应速度变慢，甚至引发卡顿现象。

为了解决这一问题，我们可以采取一种名为chunked prefill的策略。具体而言，就是将整个prompt按照固定长度（例如512个token）进行分割，每次在prefill阶段只处理一块内容。这样做的好处在于，每次并行处理的内容更短，能够减轻单个请求对GPU资源的占用，从而降低对其他同时运行的decode请求的影响。

通过启用chunked prefill功能，我们可以显著优化系统的性能表现。一方面，它能够有效降低系统的最大响应时间（max RT），提升用户体验的流畅度。另一方面，在高并发场景下，chunked prefill还能帮助提升平均响应时间（average RT），使系统能够更好地应对高负荷的请求压力。

值得一提的是，在vllm的最新版本中，chunked prefill功能已经默认开启。这一改进不仅简化了用户的使用流程，还进一步提升了系统的稳定性和性能表现。因此，对于正在使用vllm进行大模型推理的用户来说，这无疑是一个值得庆祝的好消息。

六、优化输出长度，加速大模型推理性能

在大模型的推理流程中，prefill阶段和decode阶段扮演着至关重要的角色。Prefill阶段主要负责对输入的prompt进行注意力计算，这一过程可以并行处理，从而提升效率。而decode阶段则专注于按顺序生成新的token，由于每个新token的生成都依赖于之前的输出，因此这一阶段无法并行进行。

为了提升整体的响应时间（RT），我们可以考虑在decode阶段尽量减少生成的token总长度。事实上，每生成一个token都需要一定的时间，如果能够减少输出的token数量，那么整体的响应时间也将相应缩短。例如，如果每生成一个token耗时5毫秒，那么减少5个token的输出就意味着可以节省25毫秒的总响应时间。对于非流式调用的大模型来说，这种优化策略尤为有效。特别是在执行简单的分类或识别任务时，我们往往只需要输出结果，而无需生成其他无关的信息。

那么，如何有效地缩短大模型的输出长度呢？以下是一些实用的方法：

a. 设置最大输出长度限制

首先，我们可以通过调整系统参数来设定大模型的最大输出长度。如果你使用的是OpenAI接口来调用大模型，那么在输入参数中会有一个名为“max tokens”的设置项。通过调整这个参数，你可以有效地限制大模型的输出长度，从而避免产生过长的输出或陷入无限循环的困境。

b. 利用Prompt引导简短输出

另外，我们还可以通过优化prompt来引导大模型产生更短的输出。例如，在prompt中加入“请直接给出结果”或“请尽量简短回答”等提示语，可以有效地减少无关内容的输出，使大模型的回答更加精炼。

c. 微调大模型以缩短输出

如果条件允许的话，对大模型进行微调也是一种非常有效的方法。通过微调，我们可以让大模型在满足需求的前提下尽量缩短输出长度。在微调过程中，我们可以先通过调整prompt来生成大量不同长度的输出数据，然后利用这些数据对大模型进行训练。这样一来，大模型不仅能够更好地处理输入内容，还能够在输出长度上得到有效的优化，从而达到更好的效果。

七、多卡推理：加速大模型推理的利器

在某些特定场景下，由于模型效果的需求，我们无法对大模型进行量化处理，但同时又对响应时间（RT）有着极高的要求。此时，采用多卡推理便成为了一个立竿见影的解决方案，通常能够将RT缩短至原来的1/3或1/2，甚至更多。

从上述数据可以看出，推理过程中从单卡切换到双卡可以显著提升大模型的推理速度与QPS。

那么，多卡为何能够提升大模型的推理速度呢？这主要得益于张量并行（tensor parallelism）的优化。

假设我们将张量并行设置为2，即使用两张GPU来加速推理。在模型加载阶段，推理引擎会将大模型的注意力参数（attention parameters）数量均分为两组，并分别加载到每张GPU上。随后，在推理过程中，两张GPU会并行计算注意力，最后将计算结果进行聚合合并，从而得到最终的输出。

这个过程可以类比于复印一本非常厚的书。如果我们想一次性复印整本书，但复印机一次只能复印几页，那么效率将会非常低。此时，我们可以将书分成几个部分，每个部分分别复印，最后再将所有复印好的部分按顺序拼接起来，这样就完成了整本书的复印。

在张量并行中，我们要处理的大模型就像是那本厚书，而GPU则像是复印机。由于单个GPU无法一次性处理整个大模型，我们就需要将模型（特别是权重张量）分成几个部分，并让不同的GPU分别处理。在处理输入数据时，就像是书的每一页被分别复印，然后再将复印好的各个部分拼接起来，形成完整的输出结果。

那么，如何配置张量并行呢？以下我们分别给出vllm与sglang两款大模型的配置方式：

通过合理配置多卡推理，我们可以显著提升大模型的推理速度，从而更好地满足实际应用中的高要求。

八、预测解码：小模型与大模型的协同加速策略

近期，预测解码作为一种创新的加速技术，在提升大型模型（例如72B大模型）推理速度方面展现出了显著优势。

预测解码的工作原理相当直观。以加速一个70B大模型为例，你可以先训练一个同类型但规模较小（7B）的模型。在推理阶段，同时加载这两个模型。首先，利用7B小模型进行初步预测，输出例如5个token。随后，将这些token传递给70B大模型进行验证，并保留验证正确的前N个token作为最终输出。这一过程可以持续进行，以实现连续的预测与验证。

由于验证步骤可以批量处理，且小模型的推理速度相对较快，因此这种方法能够大幅提升70B大模型的推理速度，同时确保其输出质量。以下是我们针对70B模型进行的实验数据：

实验结果显示，预测解码在特定场景下能够显著提升大模型的推理速度。

此外，还有一种更为简便的方法。如果你的输出内容大部分与输入prompt相似（例如，仅需要大模型修改文章中的错别字），且你不想训练7B的小模型，那么你可以直接使用n-gram匹配prompt的方法替代小模型。这种方法直接从输入prompt中选取预测的token，然后交由大模型进行验证。这种方法不仅速度更快，而且实现更为简单。

对于希望深入了解预测解码技术的读者，我们推荐参考vllm的相关文档。

接下来，我们将介绍如何在vllm中配置预测解码：

a. 使用大模型+小模型的方式：
（具体配置步骤需根据vllm的官方文档及实际需求进行调整。通常，这涉及到设置模型路径、指定推理策略以及配置相关参数等步骤。）

b. 使用n-gram匹配的方式：
（这种方法相对简单，通常只需要在输入阶段对prompt进行n-gram分析，选取可能的token，并传递给大模型进行验证。具体实现方式可能因vllm版本及实际需求而有所不同。）

请注意，以上介绍仅供参考，具体配置和实现方式可能因vllm的版本、模型类型及推理需求而有所不同。因此，在实际应用中，建议参考vllm的官方文档及社区资源，以获得更详细和准确的指导。

九、高效部署Deepseek-R1满血版大模型的方法

在前面的内容中，我们已经探讨了多种业界大模型性能优化的方法。接下来，我们将借助SGLang这一推理引擎，详细介绍如何部署近期备受瞩目的Deepseek-R1满血版大模型。以下是详细的部署步骤：

a. Deepseek-R1模型的下载

Deepseek团队发布了一系列模型，其中包括原始模型Deepseek-r1-zero和经过多阶段训练并官方推荐的Deepseek-r1最优模型。然而，Deepseek-r1模型拥有高达671B的参数，部署时需要至少2张8H20 GPU，资源消耗相对较大。为此，Deepseek团队基于Deepseek-r1蒸馏出了一系列小型模型，其中DeepSeek-R1-Distill-Qwen-32B等模型在单张H20 GPU上即可运行。但在此，我们将专注于介绍满血版Deepseek-r1的部署方法。

b. 部署环境的准备

为了使用SGLang推理引擎部署Deepseek-r1，我们需要准备以下软硬件环境：

GPU：至少2张8H20 GPU

IP地址：为两台部署机器分别配置IP地址，例如10.0.0.1和10.0.0.2

推理引擎SGLang：安装方法可参考官方文档：https://docs.sglang.ai/start/install.html

Deepseek-r1满血版模型：下载地址：https://modelscope.cn/models/deepseek-ai/DeepSeek-R1/

c. Deepseek-R1的部署

在准备好SGLang镜像、Deepseek-r1模型以及GPU资源后，我们可以按照以下命令启动Deepseek-r1：

节点1（Node 1）：

bash复制代码

python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-R1 --tp 16 --dist-init-addr 10.0.0.1:5000 --nNodes 2 --node-rank 0 --trust-remote-code

节点2（Node 2）：

bash复制代码

python -m sglang.launch_server --model-path deepseek-ai/DeepSeek-R1 --tp 16 --dist-init-addr 10.0.0.1:5000 --nnodes 2 --node-rank 1 --trust-remote-code

来源：华远系统