DeepSeek-R1技术解读及推理部署

1. DeepSeek-R1模型介绍

1.1 DeepSeek简介

1.1.1 DeepSeek公司背景介绍

DeepSeek是幻方量化旗下的一家大模型企业。幻方量化是中国知名的私募巨头，根据此前的信息，幻方量化有1万多张A100显卡，在美国显卡禁令之前用于量化投资。DeepSeek成立与2023年7月份，致力于探索人工智能本质。

1.1.2 DeepSeek-R1系列模型介绍

DeepSeek-R1在多个高难度基准测试中表现与OpenAI O1-1217相当，但训练成本更低。与传统的SFT+RL方法不同的是，他们发现即使不使用SFT，也可以通过大规模RL显著提高推理能力。此外，通过包含少量冷启动数据进行SFT就可以进一步提高性能。

• DeepSeek-R1-Zero ：不用SFT直接进行RL，也能取得不错的效果。
• DeepSeek-R1 ：加入少量CoT数据进行SFT作为冷启动，然后再进行RL，可以取得更优的性能，同时回答更符合人类偏好。
• 用DeepSeek-R1的样例去蒸馏小模型，能取得惊人的效果。

项目地址：https://github.com/deepseek-ai/DeepSeek-R1 (opens new window)

1.1.3 DeepSeek-R1与V3的关系

DeepSeek-R1是基于DeepSeek-V3的进一步优化，通过强化学习和蒸馏技术提升其推理能力。

1.1.4 DeepSeek-R1的训练流程

DeepSeek-R1的训练过程分为4个阶段，包括使用数千高质量CoT示例进行SFT的冷启动，面向推理的强化学习，通过拒绝抽样的SFT，面向全场景任务的强化学习与对齐。两个SFT阶段进行推理和非推理能力的能力植入，两个强化学习阶段旨在泛化学习推理模式并与人类偏好保持一致。

1.1.5 突破创新带来大模型新范式

DeepSeek-R1/V3模型的主要创新如下：

R1/V3的优化	R1/V3的创新与价值（实现了与 OpenAI-o1-1217 相当的性能）	其他开源大模型（相当于Llama3.3的性能）
软硬件结合，提高模型计算效率降低成本	提出MLA，通过将键值 (KV) 缓存显著压缩为潜在向量来保证高效推理	采用GQA或MHA，占用KV缓存比MLA大一个数量级
减少冗余，提高模型计算效率降低成本	提出DeepSeekMoE，采用细粒度专家分割和共享专家隔离，减少冗余的专家参数	采用粗粒度专家，模型参数冗余大
改进算法，提高训练效率	提出无辅助损失策略 ，改善MoE模型训练	采用常规辅助损失策略，容易训练失败
简化算法，提高训练效率	采用GRPO进一步使模型与人类偏好对齐，提高训练效率	采用PPO，训练效率不高
软硬件结合，提高训练效率	基于开源代码开发自有的FP8混合精度训练框架，提升训练效率	传统开源训练框架，以BF16或FP32为主，显存占用超过FP8，训练速度较慢
软硬件结合，提高训练效率	DualPipe算法来实现高效的流水线并行	默认流水线并行算法，气泡较多
软硬件结合，提高训练效率	跨节点All-to-All通信内核，使用PTX编程以充分利用InfiniBand（IB）和NVLink带宽	默认通信内核
改进数据，提高模型性能	使用长思维链(CoT)数据进行模型训练，提升模型能力	几乎无长思维链训练

DeepSeek-R1通过从模型结构到训推全流程的极致工程优化，带来大模型新范式。

1.2 模型关键特性

1.2.1 MLA(KV压缩)

在 DeepSeek 模型中，多头潜在注意力（Multi-Head Latent Attention，MLA） 是一种关键技术，旨在通过低秩压缩方法优化注意力机制的计算效率和内存使用。MLA 通过对键（Key）和值（Value）进行低秩联合压缩，显著减少了推理过程中的键值缓存（KV Cache），在保持模型性能的同时降低了内存占用。

1.2.2 MOE结构创新

多专家负载不均影响端到端性能10%以上，热点专家达到容量上限丢 弃Token影响模型效果。DeepSeek采用专家数量多 + 每个专家的shape 小 + 共享专家的策略，大幅减少了资源消耗。

1.2.3 MTP(多token预测)优化

传统预测推理速度慢，需要逐个生成token，加上单个token的预测倾向于局部捕捉最优，整体可能效果不好，所以引入多Token预测。

核心思路：让模型一次性通过多个顺序模块预测多个未来的token，并让大LLM来判断小LLM生成token是正确token的概率，概率高的保留，概率低的通过大LLM生成答案。基于MTP，实现从“一字一句”进化为“整句”理解生成，模型训练收敛和推理速度。

1.2.4 使用FP8混合精度

大规模训练上首次使用FP8混合精度，结合Dualpipe通信优化。

1.2.5 创新性应用GRPO

创新性应用GRPO，将强化学习流程的两个模型训练简化为一个模型的训练。

DeepSeek R1训练流程，大大简化了强化学习的训练复杂度，使强化学习在模型效果提升上更加“平民化”。

1.3 技术报告解读

DeepSeek-R1-Zero证明了，完全不进行SFT，仅依靠RL即可显著提升LLM的推理能力。尽管如此，输出的可读性和混合语言问题依然存在。SFT的目的是让LLM遵循指令，模仿人类语言表达。因此，DeepSeek-R1在训练过程中适度加入了SFT，通过四个阶段的训练进一步提升了推理能力，同时改进了输出的可读性和质量。

技术报告原文：https://arxiv.org/abs/2501.12948 (opens new window)

1.3.1 少量数据冷启动

采用一定的手段收集少量高质量数据：比如对于长CoT数据，使用few-shot，直接提示DeepSeek-R1-Zero通过反思和验证生成详细答案，然后通过人工注释者的后处理来细化结果。

总共收集了数千个样本，相比完全不用SFT，收集的样本进行SFT，可以显著增强可读性；同时后续的实验也证明了通过少量数据冷启动也能进一步提升推理能力。

1.3.2 对推理场景进行RL

在数学、代码等推理场景中，DeepSeek-R1延续了DeepSeek-R1-Zero的做法，依旧通过RL进行推理能力的提升，这里没有变化。

针对DeepSeek-R1-Zero输出中的语言混合问题，DeepSeek-R1引入了额外的奖励机制——语言一致性奖励。该奖励通过统计输出中目标语言的占比，作为奖励信号与原始准确性奖励结合，最终通过过程反馈进一步优化模型的语言输出，提升其语言一致性。

1.3.3 拒绝采样和SFT

这一阶段通过构建推理数据和非推理数据两部分，利用SFT进一步提升模型的通用能力。

• 推理数据：采用拒绝采样从前一阶段的模型中生成推理过程，并引入无法用规则奖励的数据，通过DeepSeek-V3的LLM-as-judge方式进行奖励，过滤掉混合语言、长段落和代码块的CoT数据，共计60万样本。
• 非推理数据：使用DeepSeek-V3生成的推理无关的SFT数据，共计20万样本。

总计生成了80万样本，使用DeepSeek-V3-Base进行了2个epoch的SFT训练。

1.3.4 适配所有场景的RL阶段

为了平衡推理能力和通用能力，DeepSeek-R1进行了最后一次RL训练，针对不同数据类型采用了不同的Prompt和奖励机制。

• 对于推理数据，使用DeepSeek-R1-Zero的方法，基于规则的奖励指导数学、编程和逻辑推理领域的学习过程。
• 对于通用数据，使用DeepSeek-V3的RM进行奖励。
• 对于有用性，聚焦评估最终的总结内容，确保其对用户的实用性和相关性，同时减少对推理过程的干扰。
• 对于无害性，评估整个响应过程，包括推理和总结，识别并减少潜在风险、偏见或有害内容。

通过整合奖励信号和多样化数据分布，最终模型既保持了强大的推理能力，又在有用性和无害性上取得了良好平衡，有较好的用户体验。

1.3.5 蒸馏出小参数模型

[1] 蒸馏模型可取得较好效果

DeepSeek-R1在阶段三“拒绝采样和SFT”时的数据对小模型进行SFT，未经过RL阶段，已经能够取得较好的效果。

[2] 蒸馏模型比直接训练更好

从实验结果来看，与通过小模型进行SFT+RL训练相比，蒸馏较好性能模型的输出去做SFT会有更好效果，且成本也会低很多。

经验：要实现效果好的小模型，要具备把模型做大的能力。训练出一个效果好的大参数模型，然后再对其蒸馏，效果要远优于直接训小模型。OpenAI的mini系列模型就是在训练了大基座之后再进行蒸馏，在保持模型能力的条件下，大幅降低参数量，减少推理成本。

2. DeepSeek-R1推理部署

此处分别使用vLLM、llama.cpp、ktransformers等框架部署了32B蒸馏模型、1.58精度动态量化的671B模型、4精度量化的671B模型。

2.1 模型权重与效果评估

2.1.1 模型下载地址

[1] DeepSeek-R1 Models：

Model	Total Params	Activated Params	Context Length	下载
DeepSeek-R1-Zero	671B	37B	128K	HuggingFace (opens new window)
DeepSeek-R1	671B	37B	128K	HuggingFace (opens new window)

[2] DeepSeek-R1-Distill Models：

Model	Base Model	下载
DeepSeek-R1-Distill-Qwen-1.5B	Qwen2.5-Math-1.5B (opens new window)	HuggingFace (opens new window)
DeepSeek-R1-Distill-Qwen-7B	Qwen2.5-Math-7B (opens new window)	HuggingFace (opens new window)
DeepSeek-R1-Distill-Llama-8B	Llama-3.1-8B (opens new window)	HuggingFace (opens new window)
DeepSeek-R1-Distill-Qwen-14B	Qwen2.5-14B (opens new window)	HuggingFace (opens new window)
DeepSeek-R1-Distill-Qwen-32B	Qwen2.5-32B (opens new window)	HuggingFace (opens new window)
DeepSeek-R1-Distill-Llama-70B	Llama-3.3-70B-Instruct (opens new window)	HuggingFace (opens new window)

注：有且仅有671B版本的模型才是DeepSeek-R1，其余的蒸馏模型都不是R1，本质上只是用R1输出的高质量数据做了微调训练，得到了推理效果上的提高。

[3] Unsloth的动态量化版本：https://huggingface.co/unsloth/DeepSeek-R1-GGUF (opens new window)

2.1.2 模型效果评估

对于下列所有模型，最大生成长度设置为32768个token。对于需要采样的基准测试，使用temperature为0.6，top-p为0.95，并且每个查询生成64个响应，以估算pass@1。

DeepSeek-R1-Evaluation：

Category	Benchmark (Metric)	Claude-3.5-Sonnet-1022	GPT-4o 0513	DeepSeek V3	OpenAI o1-mini	OpenAI o1-1217	DeepSeek R1
	Architecture	-	-	MoE	-	-	MoE
	# Activated Params	-	-	37B	-	-	37B
	# Total Params	-	-	671B	-	-	671B
英文	MMLU (Pass@1)	88.3	87.2	88.5	85.2	91.8	90.8
	MMLU-Redux (EM)	88.9	88.0	89.1	86.7	-	92.9
	MMLU-Pro (EM)	78.0	72.6	75.9	80.3	-	84.0
	DROP (3-shot F1)	88.3	83.7	91.6	83.9	90.2	92.2
	IF-Eval (Prompt Strict)	86.5	84.3	86.1	84.8	-	83.3
	GPQA-Diamond (Pass@1)	65.0	49.9	59.1	60.0	75.7	71.5
	SimpleQA (Correct)	28.4	38.2	24.9	7.0	47.0	30.1
	FRAMES (Acc.)	72.5	80.5	73.3	76.9	-	82.5
	AlpacaEval2.0 (LC-winrate)	52.0	51.1	70.0	57.8	-	87.6
	ArenaHard (GPT-4-1106)	85.2	80.4	85.5	92.0	-	92.3
代码	LiveCodeBench (Pass@1-COT)	33.8	34.2	-	53.8	63.4	65.9
	Codeforces (Percentile)	20.3	23.6	58.7	93.4	96.6	96.3
	Codeforces (Rating)	717	759	1134	1820	2061	2029
	SWE Verified (Resolved)	50.8	38.8	42.0	41.6	48.9	49.2
	Aider-Polyglot (Acc.)	45.3	16.0	49.6	32.9	61.7	53.3
Math	AIME 2024 (Pass@1)	16.0	9.3	39.2	63.6	79.2	79.8
	MATH-500 (Pass@1)	78.3	74.6	90.2	90.0	96.4	97.3
	CNMO 2024 (Pass@1)	13.1	10.8	43.2	67.6	-	78.8
中文	CLUEWSC (EM)	85.4	87.9	90.9	89.9	-	92.8
	C-Eval (EM)	76.7	76.0	86.5	68.9	-	91.8
	C-SimpleQA (Correct)	55.4	58.7	68.0	40.3	-	63.7

Distilled Model Evaluation：

Model	AIME 2024 pass@1	AIME 2024 cons@64	MATH-500 pass@1	GPQA Diamond pass@1	LiveCodeBench pass@1	CodeForces rating
GPT-4o-0513	9.3	13.4	74.6	49.9	32.9	759
Claude-3.5-Sonnet-1022	16.0	26.7	78.3	65.0	38.9	717
o1-mini	63.6	80.0	90.0	60.0	53.8	1820
QwQ-32B-Preview	44.0	60.0	90.6	54.5	41.9	1316
DeepSeek-R1-Distill-Qwen-1.5B	28.9	52.7	83.9	33.8	16.9	954
DeepSeek-R1-Distill-Qwen-7B	55.5	83.3	92.8	49.1	37.6	1189
DeepSeek-R1-Distill-Qwen-14B	69.7	80.0	93.9	59.1	53.1	1481
DeepSeek-R1-Distill-Qwen-32B	72.6	83.3	94.3	62.1	57.2	1691
DeepSeek-R1-Distill-Llama-8B	50.4	80.0	89.1	49.0	39.6	1205
DeepSeek-R1-Distill-Llama-70B	70.0	86.7	94.5	65.2	57.5	1633

Unsloth的动态量化版并未使用标准的基准测试，而是使用它创建了Flappy Bird游戏，并根据10个标准对其进行评分。

详见：https://docs.unsloth.ai/basics/tutorial-how-to-run-deepseek-r1-on-your-own-local-device/deepseek-r1-dynamic-1.58-bit (opens new window)

2.2 部署全精度的32B蒸馏模型

70B的蒸馏模型是基于LLaMA的，它的效果还不如基于32B的Qwen蒸馏模型，因此这里没有选最大参数的蒸馏模型。DeepSeek-R1-Distill-Qwen-32B模型的部署与Qwen2.5-32B是一致的，我这里使用LLaMA-Factory项目对其进行部署，开启了vLLM推理加速，遵循OpenAI风格的API格式。推理服务的部署及压力测试详见我的另一篇博客：基于vLLM加速大模型推理并评估性能 (opens new window)

2.2.1 容器化部署推理服务

实验环境：实体GPU服务器，NVIDIA A100 / 40GB * 8，Debian 12，256GB内存，1TB存储，CUDA 12.4

Step1：准备代码并修改Dockerfile

$ git clone https://github.com/hiyouga/LLaMA-Factory.git
$ cd LLaMA-Factory
$ cp ./docker/docker-cuda/Dockerfile .
$ vim Dockerfile

这里我只需要部署推理服务，因此对这个原始的Dockerfile做了一些改动，并删去了一些不需要的步骤。

• 需要安装vLLM，所以需要把Dockerfile里的INSTALL_VLLM设置成true。
• 为了加速下载，可以把PIP_INDEX设置成https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple。

# Default use the NVIDIA official image with PyTorch 2.3.0
# https://docs.nvidia.com/deeplearning/frameworks/pytorch-release-notes/index.html
ARG BASE_IMAGE=nvcr.io/nvidia/pytorch:24.02-py3
FROM ${BASE_IMAGE}

# Define environments
ENV MAX_JOBS=4
ENV FLASH_ATTENTION_FORCE_BUILD=False
ENV VLLM_WORKER_MULTIPROC_METHOD=spawn

# Define installation arguments
ARG INSTALL_BNB=false
ARG INSTALL_VLLM=true
ARG INSTALL_DEEPSPEED=false
ARG INSTALL_FLASHATTN=false
ARG INSTALL_LIGER_KERNEL=false
ARG INSTALL_HQQ=false
ARG INSTALL_EETQ=false
ARG PIP_INDEX=https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple

# Set the working directory
WORKDIR /app

# Install the requirements
COPY requirements.txt /app
RUN pip config set global.index-url "$PIP_INDEX" && \
    pip config set global.extra-index-url "$PIP_INDEX" && \
    python -m pip install --upgrade pip && \
    python -m pip install -r requirements.txt

# Copy the rest of the application into the image
COPY . /app

# Install the LLaMA Factory
RUN EXTRA_PACKAGES="metrics"; \
    if [ "$INSTALL_BNB" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},bitsandbytes"; \
    fi; \
    if [ "$INSTALL_VLLM" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},vllm"; \
    fi; \
    if [ "$INSTALL_DEEPSPEED" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},deepspeed"; \
    fi; \
    if [ "$INSTALL_LIGER_KERNEL" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},liger-kernel"; \
    fi; \
    if [ "$INSTALL_HQQ" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},hqq"; \
    fi; \
    if [ "$INSTALL_EETQ" == "true" ]; then \
        EXTRA_PACKAGES="${EXTRA_PACKAGES},eetq"; \
    fi; \
    pip install -e ".[$EXTRA_PACKAGES]"

# Rebuild flash attention
RUN pip uninstall -y transformer-engine flash-attn && \
    if [ "$INSTALL_FLASHATTN" == "true" ]; then \
        pip uninstall -y ninja && pip install ninja && \
        pip install --no-cache-dir flash-attn --no-build-isolation; \
    fi
# Rebuild vllm
RUN pip uninstall -y vllm
RUN pip install vllm==0.6.2

Step2：构建镜像并运行容器

$ docker build -t llamafactory_image .
$ docker run -itd \
  --gpus=all \
  --shm-size 32G \
  -p 8000:8000 \
  -v /home/DeepSeek-R1-Distill-Qwen-32B/:/app/models/model \
  -e CUDA_VISIBLE_DEVICES=1,2 \
  -e API_PORT=8000 \
  -e NCCL_P2P_DISABLE=1 \
  -e NCCL_IB_DISABLE=1 \
  --name deepseek_qwen32b \
  llamafactory_image:latest \
  python src/api.py \
  --model_name_or_path /app/models/model \
  --template deepseek3 \
  --infer_backend vllm \
  --vllm_enforce_eager True \
  --vllm_gpu_util 0.95 \
  --vllm_maxlen 16384 \
  --max_new_tokens 2048
$ docker logs -f deepseek_qwen32b

参数的含义解释：

docker run -itd
--gpus=all # 容器可见的显卡
--shm-size 32G # 容器共享内存设置
-p 8000:8000 # 把服务器端口和容器内端口映射，这里是服务器上的8000端口和容器内8000对应
-v /home/DeepSeek-R1-Distill-Qwen-32B/:/app/models/model # 把服务器上的模型挂载到容器里
-e CUDA_VISIBLE_DEVICES=1,2 # 使用的显卡
-e API_PORT=8000 # 容器内API端口设置
-e NCCL_P2P_DISABLE=1 # 有些显卡需要这么设置避免报错
-e NCCL_IB_DISABLE=1 # 有些显卡需要这么设置避免报错
--name deepseek_qwen32b # 容器名
llamafactory_image:latest 

python src/api.py 
--model_name_or_path /app/models/model \ # 容器内挂载的模型，需要把模型挂载到这里
--template deepseek3 \ # chat模型的对话模板，需根据模型类型不同更改
--infer_backend vllm \ # 推理后端，选vllm或是huggingface
--vllm_enforce_eager True \ # vllm的一个选项，可以省显存
--vllm_gpu_util 0.95 \ # vllm显存占用设置
--vllm_maxlen 16384 \ # 模型输入加输出最大长度
--max_new_tokens 2048 # 控制生成文本的最大长度

在实际应用中，vllm_maxlen与max_new_tokens这两个参数之间的关系可以被视为一种包含关系：

• --max_new_tokens 指定了生成阶段可以新增的最大token数。
• --vllm_maxlen 设定了整个输入加输出的token数量的上限。

因此，优先级实际上是关于限制范围的大小：

• 首先考虑的是--vllm_maxlen：因为它是关于输入加输出总长度的硬性限制。这意味着无论你设置的--max_new_tokens是多少，最终生成的文本加上输入文本的长度都不能超过--vllm_maxlen的值。
• 其次是--max_new_tokens：在不超过--vllm_maxlen的前提下，--max_new_tokens决定了单次请求中最多能生成多少新的tokens。

用其中的1和2号卡进行部署，共使用了72GB的显存空间（与vllm_gpu_util、vllm_maxlen、max_new_tokens等参数有关），占用情况如下图所示：

以下是实际落地部署时使用的配置，用了4张卡来部署的，把最大Token数的限制放大了。

$ docker run -itd \
  --gpus=all \
  --shm-size 32G \
  -p 8000:8000 \
  -v /home/DeepSeek-R1-Distill-Qwen-32B/:/app/models/model \
  -e CUDA_VISIBLE_DEVICES=0,1,2,3 \
  -e API_PORT=8000 \
  -e NCCL_P2P_DISABLE=1 \
  -e NCCL_IB_DISABLE=1 \
  --name deepseek_qwen32b \
  llamafactory_image:latest \
  python src/api.py \
  --model_name_or_path /app/models/model \
  --template deepseek3 \
  --infer_backend vllm \
  --vllm_enforce_eager True \
  --vllm_gpu_util 0.8 \
  --vllm_maxlen 60000 \
  --max_new_tokens 32768

特别说明：如果只设置了vllm_maxlen，而没有设置max_new_tokens，就会使用后者的缺省值，输出不了多点儿内容就被截断了。

Step3：调用推理服务测试

curl --location 'http://127.0.0.1:8000/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
  "model": "DeepSeek-R1-Distill-Qwen-32B",
  "messages": [
    {
      "role": "user",
      "content": "树上有四只鸟，开枪打死一只，还剩几只？"
    }
  ],
  "temperature": 0.6,
  "stream": true
}'

需要注意的是，R1的蒸馏模型也是有思考过程的，部署对接时要做一下这里的处理。

2.2.2 不完整think标签问题

问题描述： 使用LLaMA-Factory运行DeepSeek-R1-Distill-Qwen-32B推理服务时发现，有的回复它并不以<think>\n开头，但还是会输出<\think>。由于接入应用采用的是流式输出，这种情况会导致无法判定输出内容是思维过程还是答案回复，对界面渲染造成麻烦。

官方说明： DeepSeek-R1系列模型在响应某些查询时倾向于绕过思维模式（即输出<think>\n\n</think>），这可能会对模型的性能产生不利影响。为了确保模型进行彻底的推理，建议强制模型在每次输出开始时以<think>\n作为响应。

解决方案： 尝试过DeepSeek官方所说的强制<think>开头的方案，但发现有些会缺失结束的</think>标签，还是会导致问题。最新版LLaMA-Factory已经支持了DeepSeek-R1-Distill-Qwen-32B模板，但不支持强制思考。即每次一定会输出<think>和<\think>，但里面内容有可能是空的，也就是其实没思考，不过这样的输出是不会导致任何问题的。

2.2.3 推理服务的压力测试

使用Eval-Scope工具对使用vLLM部署的API服务进行了压力测试，可以看到其推理速度还是挺快的。并发量大了之后，速度会变慢。

注：Qwen2.5-32B原版模型的推理测试见：https://qwen.readthedocs.io/zh-cn/latest/benchmark/speed_benchmark.html (opens new window)

[1] 短数据集情况

1并发：

"Number of concurrency": 1,
"Total requests": 10,
"Succeed requests": 10,
"Failed requests": 0,
"Throughput(average tokens/s)": 20.983,
"Average QPS": 0.066,
"Average latency (s)": 15.079,
"Average time to first token (s)": 15.079,
"Average time per output token (s)": 0.04766,
"Average input tokens per request": 54.9,
"Average output tokens per request": 316.4,
"Average package latency (s)": 15.079,
"Average package per request": 1.0

5并发：

"Number of concurrency": 5,
"Total requests": 20,
"Succeed requests": 20,
"Failed requests": 0,
"Throughput(average tokens/s)": 73.602,
"Average QPS": 0.236,
"Average latency (s)": 15.52,
"Average time to first token (s)": 15.52,
"Average time per output token (s)": 0.01359,
"Average input tokens per request": 55.45,
"Average output tokens per request": 312.0,
"Average package latency (s)": 15.52,
"Average package per request": 1.0

10并发：

"Number of concurrency": 10,
"Total requests": 40,
"Succeed requests": 40,
"Failed requests": 0,
"Throughput(average tokens/s)": 137.523,
"Average QPS": 0.572,
"Average latency (s)": 12.543,
"Average time to first token (s)": 12.543,
"Average time per output token (s)": 0.00727,
"Average input tokens per request": 56.475,
"Average output tokens per request": 240.6,
"Average package latency (s)": 12.543,
"Average package per request": 1.0

20并发：

"Number of concurrency": 20,
"Total requests": 40,
"Succeed requests": 40,
"Failed requests": 0,
"Throughput(average tokens/s)": 215.718,
"Average QPS": 0.908,
"Average latency (s)": 13.268,
"Average time to first token (s)": 13.268,
"Average time per output token (s)": 0.00464,
"Average input tokens per request": 56.325,
"Average output tokens per request": 237.675,
"Average package latency (s)": 13.268,
"Average package per request": 1.0

50并发：

"Number of concurrency": 50,
"Total requests": 100,
"Succeed requests": 100,
"Failed requests": 0,
"Throughput(average tokens/s)": 335.048,
"Average QPS": 0.798,
"Average latency (s)": 26.961,
"Average time to first token (s)": 26.961,
"Average time per output token (s)": 0.00298,
"Average input tokens per request": 54.89,
"Average output tokens per request": 419.62,
"Average package latency (s)": 26.961,
"Average package per request": 1.0

100并发：

"Number of concurrency": 100,
"Total requests": 200,
"Succeed requests": 200,
"Failed requests": 0,
"Throughput(average tokens/s)": 498.405,
"Average QPS": 1.329,
"Average latency (s)": 42.931,
"Average time to first token (s)": 42.931,
"Average time per output token (s)": 0.00201,
"Average input tokens per request": 55.345,
"Average output tokens per request": 375.065,
"Average package latency (s)": 42.931,
"Average package per request": 1.0

200并发：

"Number of concurrency": 200,
"Total requests": 400,
"Succeed requests": 400,
"Failed requests": 0,
"Throughput(average tokens/s)": 747.06,
"Average QPS": 3.018,
"Average latency (s)": 45.805,
"Average time to first token (s)": 45.805,
"Average time per output token (s)": 0.00134,
"Average input tokens per request": 55.17,
"Average output tokens per request": 247.55,
"Average package latency (s)": 45.805,
"Average package per request": 1.0

400并发：

"Number of concurrency": 400,
"Total requests": 400,
"Succeed requests": 400,
"Failed requests": 0,
"Throughput(average tokens/s)": 667.435,
"Average QPS": 2.787,
"Average latency (s)": 72.396,
"Average time to first token (s)": 72.396,
"Average time per output token (s)": 0.0015,
"Average input tokens per request": 55.055,
"Average output tokens per request": 239.482,
"Average package latency (s)": 72.396,
"Average package per request": 1.0

[2] 长数据集情况

1并发：

"Number of concurrency": 1,
"Total requests": 10,
"Succeed requests": 10,
"Failed requests": 0,
"Throughput(average tokens/s)": 19.523,
"Average QPS": 0.022,
"Average latency (s)": 45.941,
"Average time to first token (s)": 45.941,
"Average time per output token (s)": 0.05122,
"Average input tokens per request": 7837.9,
"Average output tokens per request": 896.9,
"Average package latency (s)": 45.941,
"Average package per request": 1.0

5并发：

"Number of concurrency": 5,
"Total requests": 5,
"Succeed requests": 5,
"Failed requests": 0,
"Throughput(average tokens/s)": 47.821,
"Average QPS": 0.056,
"Average latency (s)": 63.475,
"Average time to first token (s)": 63.475,
"Average time per output token (s)": 0.02091,
"Average input tokens per request": 7651.6,
"Average output tokens per request": 855.2,
"Average package latency (s)": 63.475,
"Average package per request": 1.0

10并发：

"Number of concurrency": 10,
"Total requests": 20,
"Succeed requests": 20,
"Failed requests": 0,
"Throughput(average tokens/s)": 52.166,
"Average QPS": 0.075,
"Average latency (s)": 112.828,
"Average time to first token (s)": 112.828,
"Average time per output token (s)": 0.01917,
"Average input tokens per request": 7572.5,
"Average output tokens per request": 700.0,
"Average package latency (s)": 112.828,
"Average package per request": 1.0

2.3 部署动态量化的671B模型

如果服务器集群配置不足以运行原版的671B DeepSeek R1模型，可以使用Unsloth AI动态量化版，它的效果比蒸馏模型要好。这里是用的推理框架是官方博客提到的llama.cpp，采用的是CPU+GPU的混合推理，推理速度与加载到GPU的层数有关，但速度不是很快。

2.3.1 Unsloth的动态量化版

动态量化” 的核心思路：对模型的少数关键层进行高质量的 4-6bit 量化，而对大部分相对没那么关键的混合专家层（MoE）进行大刀阔斧的 1-2bit 量化。通过这种方法，DeepSeek R1 全量模型可压缩至最小 131GB（1.58-bit 量化），极大降低了本地部署门槛，甚至能在单台 Mac Studio 上运行。

动态量化模型的原理介绍这里就不赘述了，详见：https://unsloth.ai/blog/deepseekr1-dynamic (opens new window)

2.3.2 推理服务部署及测试

实验环境：实体GPU服务器，NVIDIA A100 / 40GB * 8，Debian 12，256GB内存，1TB存储，CUDA 12.4

Step1：安装llama.cpp环境

$ apt-get update
$ apt-get install build-essential cmake curl libcurl4-openssl-dev -y
$ git clone https://github.com/ggerganov/llama.cpp
$ cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON -DLLAMA_CURL=ON
$ cmake --build llama.cpp/build --config Release -j --clean-first --target llama-quantize llama-cli llama-gguf-split llama-server
$ cp llama.cpp/build/bin/llama-* llama.cpp

Step2：下载模型权重

这里选用的是1.58bit动态量化的模型，需要占用131GB的存储空间。

$ export HF_ENDPOINT=https://hf-mirror.com

由于文件较大，因此使用huggingface_hub库来下载，支持断点续传。

# pip install huggingface_hub hf_transfer
# import os # Optional for faster downloading
# os.environ["HF_HUB_ENABLE_HF_TRANSFER"] = "1"

from huggingface_hub import snapshot_download
snapshot_download(
  repo_id = "unsloth/DeepSeek-R1-GGUF",
  local_dir = "DeepSeek-R1-GGUF",
  allow_patterns = ["*UD-IQ1_S*"],
)

下载好的模型权重如下：

Step3：运行推理测试

$ ./llama.cpp/llama-cli \
    --model DeepSeek-R1-GGUF/DeepSeek-R1-UD-IQ1_S/DeepSeek-R1-UD-IQ1_S-00001-of-00003.gguf \
    --cache-type-k q4_0 \
    --threads 16 \
    --prio 2 \
    --temp 0.6 \
    --ctx-size 8192 \
    --seed 3407 \
    --n-gpu-layers 7 \
    -no-cnv \
    --prompt "<｜User｜>Create a Flappy Bird game in Python.<｜Assistant｜>"

可以正常输出，但生成速度比较慢，只有2-3token/s。

资源没有被充分利用，因此又对--threads和--n-gpu-layers参数进行了调整，优化参数后推理速度有5-6token/s。

我们服务器的cpu是48核心的，因此可以把threads设置高一点，比如32。

$ cat /proc/cpuinfo| grep "processor"| wc -l
48

我利用了NVIDIA A100 / 40GB * 5的GPU资源，因此将--n-gpu-layers设置为61，载到GPU的层数建议如下：

Step4：部署推理服务

调整为合适参数之后，部署推理服务：

$ ./llama.cpp/llama-server \
    --model DeepSeek-R1-GGUF/DeepSeek-R1-UD-IQ1_S/DeepSeek-R1-UD-IQ1_S-00001-of-00003.gguf \
    --cache-type-k q4_0 \
    --threads 32 \
    --prio 2 \
    --temp 0.6 \
    --ctx-size 4096 \
    --n-gpu-layers 61 \ 
    --port 8080 \  
    --host 0.0.0.0

注：--port用来指定端口，--host 0.0.0.0是需要加的，不然只能在本机去访问。

我使用了3-7号卡（共5张），消耗了约150GB显存，部署起来的显存占用如下：

Step4：使用推理服务

$ curl --location 'http://127.0.0.1:8080/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data '{
  "model": "DeepSeek-R1-671B-1.58Bit",
  "messages": [
    {
      "role": "user",
      "content": "介绍一下MoE模型的原理"
    }
  ],
  "temperature": 0.6,
  "stream": true
}'

DeepSeek-R1模型在生成回答时，可能会在回答中包含其思考过程，可以在<think>和</think>标记里将其提取出来。

2.4 部署半精度的671B模型

2.4.1 KTransformers简介

KTransformers 是一个基于模板规则的注入框架，专为资源受限环境中的本地部署优化而设计，重点支持异构计算架构，尤其在 GPU/CPU 卸载方面进行性能优化，其主要特点包括：

• MoE架构的稀疏激活：通过卸载稀疏的专家参数到 CPU 内存，显著减少 GPU 显存需求。
• 异构计算加速：通过多线程、NUMA 感知和 Intel AMX 指令集，优化 CPU 加速，提升性能。
• 内存与显存动态平衡：允许调整量化策略，进一步降低 GPU 需求，支持千亿级模型在较低显存的环境中运行。

KTransformers 在运行 MoE 架构的 DeepSeek-R1 模型推理中表现优异，显著提升了推理效率并解决了 GPU 算力瓶颈。

项目地址：https://github.com/kvcache-ai/ktransformers (opens new window)

2.4.2 部署条件及部署实践

实验环境：实体GPU服务器，NVIDIA A800 / 80GB * 8，Debian 12，1TB内存，256TB存储，CUDA 12.6

[1] 查看实验环境详细配置

查看CPU型号并检查是否支持AMX加速，这里用的是Intel Xeon Platinum 8358 CPU，不支持AMX加速。

$ lscpu   // 在输出中查看是否有AMX或相关的特性。若支持AMX，可能会看到类似AMX或AMX-512的标识。

查询内存的DDR代数，我这里用的是DDR4，赶不上官方用的DDR5内存，因此后面我们实际跑出来的推理速度很慢。

$ sudo apt-get install dmidecode
$ sudo dmidecode -t memory

[2] 对比官方V0.2的实验环境

由于CPU不支持AMX加速，因此无法使用V0.3版本，所以我们选择了V0.2版本去做实验，如下是官方的实验环境：

[3] 部署模型推理与性能测试

按照官方教程的V0.2版本去部署推理服务，部署的是4精度量化的DeepSeek-R1-671B模型（只支持加载GGUF格式的模型，1.58精度的尝试过跑不出来结果），内存和显存占用符合预期，但测出来的推理速度仅有1.3tokens/s（可能是因为我们的内存带宽不行）。

推理效果基本符合预期，但该框架可能还存在bug，我们实际测试时遇到了模型胡乱回答的情况（第一次是乱的，第二次是对的），在Github issues里也看到有人反馈模型推理效果变差了的情况，开发者回复可能是因为MLA的矩阵吸收与量化一起导致的问题。

注：我们测试时是早期版本，且测试服务器是DDR4内存，不支持英特尔AMX加速，因此测试出来的速度比较慢，并不是说这个框架不行，在其他人做的实测中，看到过他们在符合要求的服务器上，跑出了十几Tokens/s的生成速度。

2.4.3 实际应用场景与限制

随着对于低成本部署DeepSeek-R1模型的需求越来越高涨，KTransformers由于低成本部署的特性也随之被带火。因此出现了很多标题党的文章和视频，都是类似于诸如“仅需单张4090显卡流畅运行满血DeepSeek-R1-671B”的标题。乍一看只要这个配置，普通个人用户都蠢蠢欲动了，实际尝试后发现根本不是想的那么回事儿。

官方明明白白写了“671B DeepSeek-Coder-V3/R1 仅使用 14GB VRAM 和 382GB DRAM 运行其 Q4_K_M 版本”，并且给出了详细的部署配置环境，标题党们避重就轻，只提其中有优势和有噱头的部分，不提劣势和难达到的要求。KTransformers的确是个好框架，但其技术目前还不成熟，处于快速迭代中，我相信它未来可期。

主要槽点：

• 仅需单张4090显卡即可：所谓的低显存是拿内存去换的，需几百GB的内存，虽然它比显卡便宜很多，也不是普通机器能有的。
• 满血DeepSeek-R1-671B：这个模型是FP8混合精度去训练的，真正的满血模型是8精度，但这里能够支持运行的实际是4精度。
• 最高多少的推理速度：对硬件配置也是有要求的，推理速度非常受限于内存带宽。官方宣称的速度，是CPU利用了英特尔AMX加速，还使用了DDR5的内存，如果达不到要求，部署起来的实测速度会与这个相差很大。
• 缺少推理的并发支持：只支持单对话单队列排队模式，无法支持并发，个人或小团队自用还行，不适合作为服务端对外提供服务。

2.5 部署全精度的671B模型

实验环境：实体GPU服务器*2，NVIDIA A800 / 80GB * 8 * 2，Debian 12，1TB内存，256TB存储，CUDA 12.6（A100不支持FP8推理，16张卡跑不起来，换成80GB显存的H100显卡就可以）

由于我们实验环境单台机器的显存无法完全加载这么大参数的全精度模型，因此选择了采用 vLLM + Ray 的分布式推理方案。如果考虑高可用，可以再额外结合着 Docker + Kubernetes 去部署。

• 采用 vLLM + Ray 方案的部署过程，可参考我的另一篇博客：基于vLLM加速大模型推理并评估性能 (opens new window)

2.5.1 预估部署的显存占用

“满血”的含义：在8位精度下运行6710亿参数量的DeepSeek-R1大模型，通过FP8的方式进行推理。

有一个最保守的公式来计算显存用量：M = (P x 4) / (32 / Q) x 1.2

• M是所需显存（GB），P是模型参数量（1B计量），Q是精度位数。
• 算上模型副本、上下文等额外开销，再粗略地乘1.2考虑进去。

按照上述方式计算，在Q8精度下需要805.2GB显存，实际上可以紧着点儿用，后面乘的1.2可以小点儿。

2.5.2 不支持FP8推理而踩坑

满足这个显存要求只是第一步，还有两个非常重要的坑点，尤其需要注意！！血泪教训，不然几个小时加载模型白等！！

• 检查显卡是否支持FP8推理（比如A100、A800就不行）
• 使用显卡张数要是2的指数（比如12张卡就不行）

即便是英伟达A100、A800这样的专业计算卡，也是不支持FP8推理的，而H100、H800系列是支持的。

华为昇腾显卡也是不支持FP8推理的。

我们这里使用16张A100显卡部署满血DeepSeek-R1-671B所遇到的报错，就是因为不支持FP8推理导致的。

如果硬要用不支持FP8推理的显卡来跑，那就需要将其转换成BF16精度，显存占用需要多一倍。

BF16模型可以自己转换，也可以直接下载，这是BF16精度模型的下载地址：https://huggingface.co/arcee-ai/DeepSeek-R1-bf16 (opens new window)

2.5.3 推荐的服务器集群配置

[1] H800集群

FlashMLA，直接突破H800计算上限。它是为Hopper GPU开发的高效MLA解码内核，专门针对可变长度序列进行了优化，目前已经投入生产。按照官方介绍来说，FlashMLA使用之后，H800可以达到3000GB/s内存，实现580TFLOPS计算性能。

下表是H系列不同显卡的规格参数：

	H800（80GB SXM）	H100（80GB SXM）	H20
显存容量	80GB	80GB	96GB
显存带宽	3.35TB/s	3.35TB/s	4.0TB/s
NVLink 带宽	400GB/s	900GB/s	900GB/s
FP32（TFLOPS）	67	67	44
TF32 Tensor Core（TFLOPS）	989	989	74
FP16 Tensor Core（TFLOPS）	1979	1979	148
FP8 Tensor Core（TFLOPS）	3958	3958	296

[2] H20集群

H20显卡是目前国内合规渠道可采购的英伟达高端显卡，具备高显存配置、900GB/s的卡间互联带宽，支持PCIe Gen5，适合构建大规模GPU集群并保持高线性加速比。

• 拥有非常好的显存带宽和容量，支持FP8算力，很适合大模型推理，每张定价在1.2万~1.5万美元区间，是性价比较高的选择。
• 1台8卡141GB的H20服务器拥有1128GB显存，并且支持FP8算力，它是能够将全精度的DeepSeek-R1-671B模型部署起来的。

GPU	FP16算力（稠密，TFLOPS）	FP8算力 （稠密，TFLOPS）	L2 Cache （MB）	显存容量（GB）	显存带宽（TB/s）	卡间互联带宽（GB/s）	PCIe连接
H200	989.5	1979	50	141	4.8	900	Gen5
H20	148	296	60	96/141	4.0	900	Gen5

注：H20 96GB目前已经全面停产，H20 141GB是96GB的继任机型，是英伟达官方中国特供版，目前浪潮、华三、超聚变已大量铺货，出厂价格110~120w之间，销售价格125~150w均为合理价格区间。

2.6 推理模型服务的使用建议

2.6.1 官方推荐的参数配置

在使用 DeepSeek-R1 系列模型（包括基准测试）时遵循以下配置，以实现预期性能。

• 将temperature设置在 0.5-0.7 范围内（建议为 0.6），以防止无休止的重复或不连贯的输出。
• 避免添加system prompt；所有instructions都应包含在user prompt中。
• 对于数学问题，建议在提示中包含一个指令，例如：“请逐步推理，并将您的最终答案放在 \boxed{} 内。”
• 在评估模型性能时，建议进行多次测试并取平均结果。

2.6.2 官方提供的Prompt

[1] 文件上传功能

包含 {file_name}、{file_content} 和 {question} 这些参数。

file_template = \
"""[file name]: {file_name}
[file content begin]
{file_content}
[file content end]
{question}"""

[2] 网络搜索功能

包含 {search_results}、{cur_data} 和 {question} 这些参数。

对于中文查询，使用如下提示：

search_answer_zh_template = \
'''# 以下内容是基于用户发送的消息的搜索结果:
{search_results}
在我给你的搜索结果中，每个结果都是[webpage X begin]...[webpage X end]格式的，X代表每篇文章的数字索引。请在适当的情况下在句子末尾引用上下文。请按照引用编号[citation:X]的格式在答案中对应部分引用上下文。如果一句话源自多个上下文，请列出所有相关的引用编号，例如[citation:3][citation:5]，切记不要将引用集中在最后返回引用编号，而是在答案对应部分列出。
在回答时，请注意以下几点：
- 今天是{cur_date}。
- 并非搜索结果的所有内容都与用户的问题密切相关，你需要结合问题，对搜索结果进行甄别、筛选。
- 对于列举类的问题（如列举所有航班信息），尽量将答案控制在10个要点以内，并告诉用户可以查看搜索来源、获得完整信息。优先提供信息完整、最相关的列举项；如非必要，不要主动告诉用户搜索结果未提供的内容。
- 对于创作类的问题（如写论文），请务必在正文的段落中引用对应的参考编号，例如[citation:3][citation:5]，不能只在文章末尾引用。你需要解读并概括用户的题目要求，选择合适的格式，充分利用搜索结果并抽取重要信息，生成符合用户要求、极具思想深度、富有创造力与专业性的答案。你的创作篇幅需要尽可能延长，对于每一个要点的论述要推测用户的意图，给出尽可能多角度的回答要点，且务必信息量大、论述详尽。
- 如果回答很长，请尽量结构化、分段落总结。如果需要分点作答，尽量控制在5个点以内，并合并相关的内容。
- 对于客观类的问答，如果问题的答案非常简短，可以适当补充一到两句相关信息，以丰富内容。
- 你需要根据用户要求和回答内容选择合适、美观的回答格式，确保可读性强。
- 你的回答应该综合多个相关网页来回答，不能重复引用一个网页。
- 除非用户要求，否则你回答的语言需要和用户提问的语言保持一致。
# 用户消息为：
{question}'''

对于英文查询，使用如下提示：

search_answer_en_template = \
'''# The following contents are the search results related to the user's message:
{search_results}
In the search results I provide to you, each result is formatted as [webpage X begin]...[webpage X end], where X represents the numerical index of each article. Please cite the context at the end of the relevant sentence when appropriate. Use the citation format [citation:X] in the corresponding part of your answer. If a sentence is derived from multiple contexts, list all relevant citation numbers, such as [citation:3][citation:5]. Be sure not to cluster all citations at the end; instead, include them in the corresponding parts of the answer.
When responding, please keep the following points in mind:
- Today is {cur_date}.
- Not all content in the search results is closely related to the user's question. You need to evaluate and filter the search results based on the question.
- For listing-type questions (e.g., listing all flight information), try to limit the answer to 10 key points and inform the user that they can refer to the search sources for complete information. Prioritize providing the most complete and relevant items in the list. Avoid mentioning content not provided in the search results unless necessary.
- For creative tasks (e.g., writing an essay), ensure that references are cited within the body of the text, such as [citation:3][citation:5], rather than only at the end of the text. You need to interpret and summarize the user's requirements, choose an appropriate format, fully utilize the search results, extract key information, and generate an answer that is insightful, creative, and professional. Extend the length of your response as much as possible, addressing each point in detail and from multiple perspectives, ensuring the content is rich and thorough.
- If the response is lengthy, structure it well and summarize it in paragraphs. If a point-by-point format is needed, try to limit it to 5 points and merge related content.
- For objective Q&A, if the answer is very brief, you may add one or two related sentences to enrich the content.
- Choose an appropriate and visually appealing format for your response based on the user's requirements and the content of the answer, ensuring strong readability.
- Your answer should synthesize information from multiple relevant webpages and avoid repeatedly citing the same webpage.
- Unless the user requests otherwise, your response should be in the same language as the user's question.
# The user's message is:
{question}'''

3. DeepSeek开源周发布会

DeepSeek在2025.2.24至2.28期间推出的 “开源周”，通过连续五天开源五大核心代码库及相关技术文档，引发了全球 AI 开发者的高度关注。这些开源项目覆盖 AI 开发的全链路——从底层硬件性能优化到模型训练、推理加速，再到数据存储与通信效率提升，标志着 AI 技术普惠化和开源生态建设的重要里程碑。

• 项目地址：https://github.com/deepseek-ai/open-infra-index (opens new window)

3.1 FlashMLA

3.1.1 FlashMLA简介

FlashMLA是专门面向Hopper GPU的一款高效解码内核，针对大模型中可变长度序列的处理进行了优化。可变长度序列在大模型中，尤其是长文档或长对话的处理过程中，会导致计算开销急剧增加。它通过优化Attention机制，显著提高了长短不一序列的处理速度，优化后的内存带宽达到了3000 GB/s，计算性能达到了580 TFLOPS。

• 项目地址：https://github.com/deepseek-ai/FlashMLA (opens new window)

FlashMLA借鉴FlashAttention分块Tiling 和显存优化的思想，通过“以算代存”的方式减少对显存带宽的依赖，从而显著提升计算性能。它的实现基于 NVIDIA 的 Cutlass 和 CUDA 框架，并专门针对最新一代 Hopper 架构（H800 SXM5 配置）做了深度优化。

3.1.2 FlashMLA核心技术

Flash MLA 的核心是高效的 MLA 解码内核，关键技术包括：

• 低秩矩阵压缩：MLA 使用低秩矩阵，将KV缓存压缩为潜向量，减少内存占用。通过解压潜向量生成独特的KV Head。
• 针对GPU 优化：FlashMLA针对Hopper GPU的Tensor Core进行优化，使用了SM90的关键特性，大幅提高显卡的利用率。
• Row-wise/Block-wise优化：细粒度划分，在shared memory中原位处理计算，减少了额外的中间计算过程的显存占用，减少显存访问次数。
• Split-KV 分块处理：将KV拆分给多个SM（Stream Multiprocessor）处理，然后在局部把partial计算结果合并。
• 变长序列支持：通过 tile_scheduler_metadata 和 num_splits 参数，FlashMLA 支持变长序列的并行处理，以缓解负载不均衡问题。

3.2 DeepEP

3.2.1 DeepEP简介

DeepEP 是一个专门针对 Mixture-of-Experts (MoE) 训练方法设计的通信工具，其核心目标是通过优化 GPU 之间的数据传输来加速 AI 的训练和推理过程。

• 项目地址：https://github.com/deepseek-ai/DeepEP (opens new window)

具体来说，DeepEP 能够：

• 提升 GPU 间的数据传输速度，无论是 NVLink（同一机器内的 GPU）还是 RDMA（跨机器的 GPU）。
• 减少推理解码阶段的延迟，这对于实时应用如 ChatGPT 至关重要。
• 实现计算和数据传输的并行执行，避免因等待数据传输而导致的计算停滞。

3.2.2 DeepEP性能测试

根据测试，在 NVIDIA H800 GPU 加上 400Gb/s RDMA 的服务器环境下，DeepEP 展现出了优异的性能指标，这表明它能够显著提高大规模 MoE 模型的训练和推理效率。

• 普通模式：NVLink 速度可达 158GB/s，RDMA 速度在 43-47GB/s 之间。
• 低延迟模式：延迟可低至 163 微秒，RDMA 速度维持在 39-46GB/s。

3.2.3 DeepEP原理架构

DeepEP的优化思路如下：

• 通信缓冲区管理的优化：通过Buffer类封装了跨节点/节点内的通信缓冲区，支持NVLink（节点内）和RDMA（跨节点）通信。预分配对齐的内存池（num_nvl_bytes和num_rdma_bytes），减少动态内存分配开销。使用CUDA IPC和NVSHMEM实现高效的进程间内存共享。
• 动态调度：get_dispatch_layout和intranode_dispatch根据输入令牌动态分配专家任务，生成分发布局。使用任务队列（FIFO）和原子计数器管理多节点间的任务同步，避免数据竞争。
• 异步通信与流管理：通过独立的comm_stream分离计算与通信操作，利用CUDA事件（EventHandle）实现跨流同步。支持异步执行模式（async参数），隐藏通信延迟。
• 低延迟优化：low_latency_mode采用双缓冲技术，交替使用两个缓冲区减少等待时间。通过TMA（Tensor Memory Access）和预取策略优化FP8等数据类型的传输效率。

3.3 DeepGEMM

3.3.1 DeepGEMM简介

DeepGEMM是一个专为实现清晰高效的FP8通用矩阵乘法（GEMMs）而设计的库，采用了DeepSeek-V3提出的细粒度缩放技术。该库同时支持常规矩阵乘法和混合专家分组矩阵乘法。它使用CUDA编写，通过轻量级即时编译（JIT）模块在运行时编译所有内核，无需在安装过程中进行编译。

• 项目地址：https://github.com/deepseek-ai/DeepGEMM (opens new window)

3.3.2 DeepGEMM技术细节

DeepGEMM 使用 CUDA 编写，无需安装时编译，依赖一个轻量级 JIT 模块，运行时生成内核。目前仅支持 NVIDIA Hopper 张量核心，采用 CUDA 核心两级累积解决 FP8 张量核心累积的不精确问题。它借鉴了 CUTLASS 和 CuTe 的一些概念，但避免了繁重模板依赖，该库的设计非常简单，只有一个核心内核函数，包含大约300行代码，性能优于专家调优内核。

其优化包括：

• 持久化 warp 特化，提升线程调度效率。
• Hopper TMA 特性，如加载/存储/多播/预取。
• stmatrix PTX 和寄存器计数控制。
• 完全 JIT 设计，无需预编译，运行时根据形状/块大小/流水线阶段生成内核。

细粒度缩放是其关键特性，可能是通过为矩阵的不同部分应用多个缩放因子来管理 FP8 的精度问题，尤其在 MoE 模型中，可能按专家或组进行缩放。

3.4 DualPipe及EPLB

3.4.1 DualPipe及EPLB简介

[1] DualPipe双向流水线并行

DualPipe是一个双向流水线并行算法，旨在优化DeepSeek-V3和R1模型训练中的计算与通信重叠时间，减少流水线上的等待时间。该算法通过在等待时间内分配其他任务，充分利用显卡的空闲时间，从而提高计算资源的利用率和训练速度。该算法目前仅支持NVIDIA的H系列显卡。

• 项目地址：https://github.com/deepseek-ai/DualPipe (opens new window)

[2] EPLB专家并行负载均衡器

EPLB专家并行负载均衡器是一个冗余专家策略，旨在优化硬件利用率，减少推理阶段的资源浪费。它主要通过均衡多个专家之间的工作负载，避免某个专家过载或空闲，提高推理效率。与DualPipe不同，EPLB不仅限于DeepSeek模型，它具有较强的通用性，能够在各种MOE模型中使用。EPLB目前同样也仅支持NVIDIA的H系列显卡。

• 项目地址：https://github.com/deepseek-ai/eplb (opens new window)

3.4.2 DualPipe及EPLB核心特点

[1] DualPipe核心特点

• 计算与通信重叠：DualPipe 的设计目标是最大化集群设备的计算性能，通过在前向传播（Forward）和后向传播（Backward）阶段实现计算与通信的完全重叠，显著减少传统流水线并行中的“气泡”（Pipeline Bubble，即空闲等待时间）。这对于需要跨节点协作的专家并行（Expert Parallelism）场景尤为重要。
• 双向调度：与传统的单向流水线并行不同，DualPipe 采用双向调度策略，从流水线的两端同时输入微批次（Micro-batches），充分利用硬件资源。这种方法在保持计算通信比例恒定的情况下，即使模型规模进一步扩大，也能维持接近零的通信开销。
• 高效扩展性：DualPipe 针对跨节点的混合专家模型（MoE）进行了优化，通过减少通信瓶颈，使得大规模分布式训练能够在相对有限的硬件资源（如 H800 GPU）上高效运行。
• 显存优化：DualPipe 将模型的最浅层（包括嵌入层）和最深层（包括输出层）部署在同一流水线级别（PP Rank），实现参数和梯度的物理共享，进一步提升内存效率。这种设计减少了高代价的张量并行（Tensor Parallelism）需求。

[2] EPLB核心特点

• 负载均衡优化：EPLB 通过复制高负载专家（Redundant Experts Strategy）并对专家分配进行启发式调整，确保不同 GPU 之间的负载均衡。这种方法解决了专家并行中因专家负载不均导致的计算资源浪费问题。分层负载平衡策略也可用于预填充阶段，具有较小的专家并行规模。
• 跨节点通信优化：在 DeepSeek-V3 的技术报告中提到，EPLB 尝试将同一组的专家尽量分配到同一节点，减少跨节点的数据传输开销。这种分组限制路由（Group-Limited Expert Routing）策略显著提升了分布式训练的效率。
• 高效可扩展性：EPLB 支持灵活的专家复制和分配，能够适配不同规模的模型和硬件配置。例如，在一个包含 2 个节点、每个节点 4 个 GPU 的集群上，EPLB 可以动态规划16个个专家副本的分配。

3.4.3 两项技术的通俗理解及意义

DualPipe和EPLB解决了大规模并行训练中的关键问题：计算资源利用率低和负载不均衡。

• DualPipe通过重新编排计算任务，打破传统的流水线并行模式；
• EPLB则为MOE模型提供了智能资源调度策略。

通俗理解：DualPipe类似于生产线上的多条流水线，优化等待时间，以填充显卡的空闲期，从而提升效率；而EPLB像是对多位专家的工作负载进行智能调度，确保各专家高效运行，不会出现过载或空闲现象，进一步提升推理速度。

3.5 3FS及Smallpond

3.5.1 3FS及Smallpond简介

[1] 3FS分布式文件系统

3FS（Fire-Flyer File System）是DeepSeek开发的一款高性能分布式文件系统，旨在为AI训练和推理工作负载提供高效的共享存储层。它充分利用现代SSD和RDMA（远程直接内存访问）网络技术，简化分布式应用程序的开发，解决大规模数据密集型任务中的存储瓶颈。

• 项目地址：https://github.com/deepseek-ai/3FS (opens new window)

下图展示了一个大型3FS集群的读压测吞吐情况。该集群由180个存储节点组成，每个存储节点配备2×200Gbps InfiniBand网卡和16个14 TB NVMe SSD。大约500+个客户端节点用于读压测，每个客户端节点配置1x200Gbps InfiniBand网卡。在训练作业的背景流量下，最终聚合读吞吐量达到约6.6TB/s。

[2] Smallpond分析工具

Smallpond是基于3FS的一个分析工具，适用于处理海量数据。它的设计主要是为了优化硬盘与GPU之间的传输效率，尤其适合大规模计算任务。Smallpond具有广泛的通用性，可以用于不同类型模型的文件传输和GPU通信，尤其在量化和大模型训练中表现突出。

• 项目地址：https://github.com/deepseek-ai/smallpond (opens new window)

DeepSeek利用GraySort基准对Smallpond进行了评估，该基准可衡量大规模数据集的排序性能。测试集群由25个存储节点（2个NUMA域/节点、1个存储服务/NUMA、2×400Gbps NIC/节点）和50个计算节点（2个NUMA域、192个物理核心、2.2 TB RAM和1×200 Gbps NIC/节点）组成。对8192个分区中的110.5 TB数据进行排序耗时30分14秒，平均吞吐量为3.66 TB/分钟。

3.5.2 3FS及Smallpond优势

[1] 3FS技术优势

• 针对硬件的软件适配：通过 NVMe SSD 和 RDMA 协同优化 I/O 和网络传输，相比传统文件系统（如 HDFS）在高并发场景下延迟更低、吞吐量更高。
• 去中心化架构：无单点故障，节点间对等设计提升了可扩展性和可靠性。
• 高效缓存：KVCache 查找性能达 40 GiB/s，显著降低推理延迟，优于现有开源方案（如 Alluxio）。
• 成本效益：在普通硬件上实现高性能，避免对专用存储设备的依赖，符合 DeepSeek 一贯高性价比策略。
• 流量隔离：与 HFReduce 协同设计，避免存储与计算流量冲突，提升系统稳定性。

[2] Smallpond技术优势

• 高性能查询：基于 DuckDB 的列式存储和向量化执行引擎，查询速度远超传统工具（如 Spark 在小规模任务中的开销）。
• 低开销：无需分布式集群支持，单机即可处理大规模数据，部署简单。
• 与 3FS 协同：直接利用 3FS 的存储能力，避免数据迁移成本，实现高效数据流水线。
• 扩展性好：支持插件式扩展，可集成更多数据源和处理逻辑。

3.5.3 3FS及Smallpond意义

3FS和Smallpond的组合极大提升了数据处理效率，并颠覆了传统的数据准备模式，从“先处理后训练”转变为“边处理边训练”。不仅优化了训练过程中的加速算法，还在数据处理环节实现了加速，进一步推动了整个训练流程的高效化。

3.6 DeepSeek-V3/R1推理系统概览

3.6.1 DeepSeek推理系统的优化

[1] 推理系统的优化目标

DeepSeek-V3 / R1推理系统的优化目标是：更大的吞吐，更低的延迟。

为了实现这两个目标，官方采用的方案是使用大规模跨节点专家并行（Expert Parallelism / EP）。首先 EP 使得 batch size 大大增加，从而提高 GPU 矩阵乘法的效率，提高吞吐。其次 EP 使得专家分散在不同的 GPU 上，每个 GPU 只需要计算很少的专家（因此更少的访存需求），从而降低延迟。

但 EP 同时也增加了系统的复杂性，复杂性主要体现在两个方面：

• EP 引入跨节点的传输。为了优化吞吐，需要设计合适的计算流程使得传输和计算可以同步进行。
• EP 涉及多个节点，因此天然需要 Data Parallelism（DP），不同的 DP 之间需要进行负载均衡。

因此下面将通过“大规模跨节点专家并行”、“计算通信重叠”、“尽可能地负载均衡”等方式应对这些挑战。

[2] 大规模跨节点专家并行

由于 DeepSeek-V3 / R1 的专家数量众多，并且每层 256 个专家中仅激活其中 8 个。模型的高度稀疏性决定了必须采用很大的 overall batch size，才能给每个专家提供足够的 expert batch size，从而实现更大的吞吐、更低的延时。需要大规模跨节点专家并行（Expert Parallelism / EP）。

这里采用多机多卡间的专家并行策略来达到以下目的：

• Prefill：路由专家 EP32、MLA 和共享专家 DP32，一个部署单元是 4 节点，32 个冗余路由专家，每张卡 9 个路由专家和 1 个共享专家
• Decode：路由专家 EP144、MLA 和共享专家 DP144，一个部署单元是 18 节点，32 个冗余路由专家，每张卡 2 个路由专家和 1 个共享专家

[3] 计算通信重叠

多机多卡的专家并行会引入比较大的通信开销，所以这里使用了双 batch 重叠来掩盖通信开销，提高整体吞吐。

1）对于 prefill 阶段，两个 batch 的计算和通信交错进行，一个 batch 在进行计算的时候可以去掩盖另一个 batch 的通信开销。

2）对于 decode 阶段，不同阶段的执行时间有所差别，所以我们把 attention 部分拆成了两个 stage，共计 5 个 stage 的流水线来实现计算和通信的重叠。

[4] 尽可能地负载均衡

由于采用了很大规模的并行（包括数据并行和专家并行），如果某个 GPU 的计算或通信负载过重，将成为性能瓶颈，拖慢整个系统；同时其他 GPU 因为等待而空转，造成整体利用率下降。因此我们需要尽可能地为每个 GPU 分配均衡的计算负载、通信负载。

1）Prefill Load Balancer

• 核心问题：不同数据并行（DP）实例上的请求个数、长度不同，导致 core-attention 计算量、dispatch 发送量也不同。
• 优化目标：各 GPU 的计算量尽量相同（core-attention 计算负载均衡）、输入的 token 数量也尽量相同（dispatch 发送量负载均衡），避免部分 GPU 处理时间过长。

2）Decode Load Balancer

• 核心问题：不同数据并行（DP）实例上的请求数量、长度不同，导致 core-attention 计算量（与 KVCache 占用量相关）、dispatch 发送量不同。
• 优化目标：各GPU的 KVCache 占用量尽量相同（core-attention 计算负载均衡）、请求数量尽量相同（dispatch发送量负载均衡）。

3）Expert-Parallel Load Balancer

• 核心问题：对于给定 MoE 模型，存在一些天然的高负载专家（expert），导致不同 GPU 的专家计算负载不均衡。
• 优化目标：每个 GPU 上的专家计算量均衡（即最小化所有 GPU 的 dispatch 接收量的最大值）。

3.6.2 DeepSeek线上的数据统计

[1] 推理所使用的显卡与精度

DeepSeek V3 和 R1 的所有服务均使用 H800 GPU，使用和训练一致的精度，即矩阵计算和 dispatch 传输采用和训练一致的 FP8 格式，core-attention 计算和 combine 传输采用和训练一致的 BF16，最大程度保证了服务效果。

[2] 动态调整推理节点数量

由于白天的服务负荷高，晚上的服务负荷低，因此官方实现了一套机制，在白天负荷高的时候，用所有节点部署推理服务。晚上负荷低的时候，减少推理节点，以用来做研究和训练。在最近的 24 小时里，DeepSeek V3 和 R1 推理服务占用节点总和，峰值占用为 278 个节点，平均占用 226.75 个节点（每个节点为 8 卡 H800 GPU）。假定 GPU 租赁成本为 2 美金/小时，总成本为 87072美金/天。

[3] 推理服务的成本及利润估计

在 24 小时统计时段内，DeepSeek V3 和 R1：

• 输入 token 总数为 608B，其中 342B tokens（56.3%）命中 KVCache 硬盘缓存。
• 输出 token 总数为 168B。平均输出速率为 20~22 tps，平均每输出一个 token 的 KVCache 长度是 4989。
• 平均每台 H800 的吞吐量为：对于 prefill 任务，输入吞吐约 73.7k tokens/s（含缓存命中）；对于 decode 任务，输出吞吐约 14.8k tokens/s。

以上统计包括了网页、APP 和 API 的所有负载。如果所有 tokens 全部按照 DeepSeek R1 的定价计算，理论上一天的总收入为 562027美金，成本利润率 545%。（注：实际没有这么多收入，因为 V3 的定价更低，同时收费服务只占了一部分，另外夜间还会有折扣）

4. 其他推理模型及相关应用

4.1 QWQ-32B推理模型

4.1.1 QWQ-32B的基准测试

从基准测试上来看，32B的QwQ-32B效果明显优于DeepSeek-R1和DeepSeek-R1-Distilled-Llama-70B，可以接近DeepSeek-R1和o1-mini的水平。这里的基准测试包括数学推理，编程竞赛，通用能力，指令遵循以及函数调用等各个方面。特别地，QwQ-32B也整合了Agent能力，使其能够在使用工具和根据环境反馈调整推理的过程中进行批判性思考。

4.1.2 QWQ-32B的效果对比

同为主打推理的大模型，DeepSeek-R1的架构为MoE结构，QwQ-32B则属于典型的密集模型。

通常来说，MoE模型更加适合知识密集型场景，例如知识问答系统、信息检索等，以及大规模数据处理，例如在处理大规模文本数据、图像数据时，MoE模型可以通过不同专家处理不同的数据子集，提高处理效率。但MoE庞大的参数量决定了，部署满血大模型需要在云端或者自有服务器资源上运行。

而密集模型体积小，计算成本高，更适合需要深度连贯推理的场景，例如复杂的逻辑推理任务、深度阅读理解等，以及复杂算法设计等对实时性要求不高的场景。最大的优点在于非常适合本地部署，但有时候，也会出现废话过多的情况。

对比维度	密集模型（QwQ-32B)	MoE模型（DeepSeek-R1）
优点	训练难度相对低，过程简单直接推理连贯性好，所有神经元都参与计算和推理，能整体把握上下文信息	计算效率高，推理时只需激活部分专家模型容量大，可通过增加专家数量扩展
缺点	计算成本高，训练和推理需大量计算资源和内存模型容量扩展受限，易过拟合，存储部署成本高	训练复杂，需训练门控网络，考虑专家负载平衡存在路由开销，门控网络路由选择有额外计算和时间消耗

密集模型和 MoE 模型各有其独特的优势和局限性，不存在绝对的优劣之分。在实际应用中，我们需要根据具体的任务需求、数据特点、计算资源和预算等因素来选择合适的模型架构。

以下是QWQ-32B与DeepSeek-R1-Distill-Qwen-32B的效果对比：

• 系统提示词：我要你扮演诗人。你将创作出能唤起情感并具有触动人心的力量的诗歌。写任何主题或主题，但要确保您的文字以优美而有意义的方式传达您试图表达的感觉。您还可以想出一些短小的诗句，这些诗句仍然足够强大，可以在读者的脑海中留下印记。
• 用户提示词：请写一首关于山东大学的藏头诗。

对于这个例子而言，DeepSeek-R1-Distill-Qwen-32B的思考是不充分的，得到的结果也不符合要求，而QWQ-32B不但符合要求，还在继续检查写的是否更合适，得到的结果还不错。

结论：在没有足够算力部署满血671B模型的情况下，建议优先选用QWQ-32B去做落地，它比R1的蒸馏模型能力更强。

4.2 o3-mini推理模型

4.2.1 o3-mini模型发布

2025.1.31，OpenAI发布了o3-mini模型。和前一代o1-mini类似，它也针对STEM（Science、Technology、Engineering、Mathematics）进行了优化，延续了mini系列小而美的风格。ChatGPT Pro、ChatGPT Plus用户从发布日起可以访问OpenAI o3-mini（middle推理）和 OpenAI o3-mini-high模型，免费用户也可以通过选择“Search+Reason”来使用o3-mini来体验搜索。

4.2.2 o3-mini推理性能

技术报告原文：https://cdn.openai.com/o3-mini-system-card.pdf (opens new window)、官方博客原文：https://openai.com/index/openai-o3-mini (opens new window)

人类专家测评显示，大多数情况下o3-mini比o1-mini产生更准确、更清晰的答案，获得了56%的偏好度，同时在处理复杂现实问题时的重大错误率更是降低了39%。

[1] 数学能力上，低推理强度下的o3-mini（low）达到了与o1-mini相当的水平；中等推理强度下能力媲美满血版o1；而一旦推理强度拉满（high），其表现直接超越o1系列一众模型。

在由60多位顶尖数学家准备的FrontierMath难题测试中，高推理强度下的o3-mini相较o1系列也有了大幅提升。官方甚至特意注明，如果搭配Python工具使用，o3-mini（high）在第一次尝试时就解决了超过32%的问题，其中包括28%以上的T3级问题。

[2] 科学能力方面，在PhD水平的物化生问题上，低推理强度下的o3-mini就已经和o1-mini拉开了层级。

[3] 在编码这项重要能力上，o3-mini更是在各层级上领先o1系列。

o3-mini在取得上述领先的同时，响应更快了，其平均响应时间为7.7秒，较o1-mini的10.16秒提升了24%。

4.3 Deep-Research深度研究

4.3.1 Deep-Research基本介绍

Deep Research是一个利用推理能力综合大量联网信息并为你完成多步骤研究任务的Agent，它能在几十分钟内完成人类需要数小时才能完成的工作。它的背后是一个定制化的o3模型，该模型针对网页浏览和Python数据分析进行了优化，能够利用推理能力搜索、解读和分析互联网上的大量文本、图像和 PDF 文件来生成研究报告。

• 在一系列针对现实问题的公开评估测试中，Deep Research达到了SOTA，其中在Humanity's Last Exam上准确率为26.6%，超过了DeepSeek-R1（9.4%）和o3-mini high（13.0%），在GAIA上达到了72.57，超过之前最好的方法（63.64）。
• 目前的Deep Research也有局限性，比如会在回答中生成虚假信息或做出错误推断，而且可能难以区分权威信息与谣言，而且任务启动时间较长。它的推理成本很高，目前只对ChatGPT Pro用户开放，且每月最多支持100次查询，后续会逐步开放。

官方介绍：https://openai.com/index/introducing-deep-research (opens new window)

4.3.2 Deep-Research使用示例

Deep Research vs GPT-4o：

功能	GPT-4o	Deep Research
任务类型	通用对话	深度研究
信息获取	主要为训练数据	实时联网搜索
报告级别	快速总结	专业级研究报告
引用来源	仅搜索任务有	清晰引用、可验证

Deep Research使用示例如下：

4.4 推理模型使用的最佳实践

4.4.1 如何编写推理模型的Prompt

推理模型在处理简明直接的提示词时表现最佳。某些提示工程（如要求模型「一步一步思考」）可能并不会提升性能，有时反而会降低效果。简单来说，可以这样理解：

• 推理模型就像一位经验丰富的高级同事——你只需告诉他们最终目标，就能相信他们自主完成所有细节工作。
• 非推理模型则更像一位新手同事——你需要提供明确详细的指示，才能让他们准确完成特定的输出任务。

构建Prompt的具体建议如下：

• 用开发者消息取代系统消息：自o1-2024-12-17版本起，推理模型开始支持开发者消息（developer message）而非系统消息（system message）。
• 保持提示词简洁明确：推理模型最擅长理解和响应简短、清晰的指令。
• 避免使用CoT提示：由于模型内置推理能力，因此无需特别提示它们「一步一步思考」或「解释推理过程」。
• 善用分隔符增强清晰度：使用Markdown、XML标签和章节标题等分隔符来明确区分输入的不同部分，这有助于模型准确理解各个章节的内容。
• 优先尝试零样本学习：推理模型通常无需少样本示例即可产出优质结果，因此建议先尝试不含示例的提示词。如果对输出结果有更复杂的要求，再考虑在提示词中添加输入和期望输出的示例。请注意确保示例与提示词指令严格匹配，因为不一致可能导致性能下降。
• 提供明确约束条件：如果需要对模型的响应施加具体限制（例如「提供预算控制在500美元以内的解决方案」），请在提示词中明确列出这些约束条件。
• 明确定义目标：在指令中，请详细说明判定响应成功的具体参数，并引导模型持续优化推理过程，直到达成设定的成功标准。
• Markdown格式说明：从o1-2024-12-17版本开始，API中的推理模型默认不会生成带有Markdown格式的响应。如果确实需要在响应中包含Markdown格式，请在开发者消息的首行添加「Formatting re-enabled」字符串。

4.4.2 如何选择推理模型与非推理模型

这两类模型没有优劣之分，它们各有所长。o系列模型更像是一个「规划者」，能深入思考复杂任务；相比之下，GPT模型则是一个「执行者」，能直接执行任务，延迟低、性价比更高。

在不同情况下，具体选择哪个模型，推荐如下：

• 速度和成本：选择非推理模型，因为它们处理速度更快，成本更低。
• 执行明确任务：选择非推理模型，它们在处理界定清晰的任务时表现出色。
• 准确性和可靠性：选择推理模型，它们是可靠的决策专家。
• 复杂问题解决：选择推理模型，它们善于处理模糊和复杂的问题。

大多数AI工作流，可以使用二者的结合。

4.5 简洁答案的准确率更高

4.5.1 欠思考问题及统计学现象

DeepSeek-R1和o1/o3这类推理大模型带来震撼之际，有人发现了它存在的弱点。来自腾讯AI实验室、苏州大学和上海交通大学的一项最新研究揭示：在遇到高难度问题时，推理大模型可能像“三心二意的学生”一样频繁切换解题思路，却因缺乏深入探索而失败——这种现象被研究者称为Underthinking（欠思考）。

通过分析AI的错误答案，他们发现当前的推理大模型经常在思考早期就走上了正确的路线，但倾向于“浅尝辄止”，很快开始探索别的思路，导致后续生成的数千个tokens对解题毫无贡献。这种“无效努力”不仅浪费计算资源，还显著降低了答案的正确率。

论文地址：https://arxiv.org/abs/2501.18585 (opens new window)

为了系统分析，团队在3个具有挑战性的测试集MATH500、GPQA Diamond和AIME2024上，对类o1模型QwQ-32B-Preview、DeepSeek-R1-671B等进行了实验。下图比较了正确和错误回答中的token使用量和思维切换次数。平均来看，类o1模型在错误回答中比正确回答多消耗了225%的token，原因是思维切换频率增加了418%。

4.5.2 许多被放弃的推理路径存在正确思路

为了深入分析这一现象，研究团队开发了一套评估框架，用于判断被放弃的推理路径是否实际上足以推导出正确答案。结果观察到，许多模型在回答开头阶段的思路是正确的，但并未继续深入完成推理。

超过70%的错误回答中至少包含一个正确的思路。此外，在超过50%的错误回答中，有10%以上的思路是正确的。

4.5.3 思维不足问题在不同数据集表现各异

实验结果表明，所有测试的类o1模型都存在显著的思维不足问题。模型的准确率与思维不足之间的关系在不同数据集上表现各异。在MATH500-Hard和GPQA Diamond数据集上，性能更优的DeepSeek-R1-671B模型在取得更高准确率的同时，其UT得分也更高，表明错误回答中存在更多思维不足。

这意味着，尽管模型整体能力更强，但在不确定时可能生成更长但效率较低的推理过程，可能是因为模型探索了多个错误的推理路径，却未能有效收敛到正确解答。相反，在AIME2024测试集中，DeepSeek-R1-671B模型不仅取得了更高的准确率，还表现出较低的UT得分，反映出较少的思维不足和更高的token效率。

这表明模型在该任务中，即使未得出正确答案，其推理过程依然保持专注和高效，团队表示这可能是因为模型与AIME2024所要求的问题类型和推理过程更好地对齐。理解思维不足现象对于开发能够提供正确答案并具备有效推理过程的模型至关重要。

4.5.4 用思路切换惩罚机制提高思考专注度

研究者借鉴了人类考试策略，提出了一种“思路切换惩罚机制” （Thought Switching Penalty，TIP）。其原理类似于考试时给自己定规矩：“先专注当前方法，至少尝试10分钟再换思路”。技术细节上，TIP会对触发思路切换的关键词施加惩罚，降低这些词在解码过程中的生成概率，迫使模型在当前路径上探索更久。例如，当模型开始写“Alternatively, we can consider…”时，TIP会通过调整参数（惩罚强度α和持续时间β），抑制这种过早的切换倾向。

实验结果显示，加入TIP能让模型在数学测试上的准确率上升，同时UT Score下降，说明既减少了无效切换，又提高了答案质量。例如在AIME2024数学竞赛测试上，加入TIP的QwQ-32B-Preview模型准确率从41.7%提升至45.8%，同时UT Score从72.4降至68.2。这种方式无需重新训练模型，仅需调整解码策略即可。

4.5.5 用简洁解码策略提高回复质量

UC Berkeley的教授Alex Dimakis几乎同时分享了类似的观察：“对于DeepSeek-R1和所有推理模型，错误的答案更长，而正确的答案要短得多”。基于此，他提出一个简单的解决办法，称为简洁解码：“并行运行5次模型，从答案中选择tokens最少的”。初步实验结果表示，简洁解码在AIME2024测试上能提高6%-7%的准确率，比Consensus Decoding更好也更快。

5. 参考资料

[1] DeepSeek-R1论文速读 from 吃果冻不吐果冻皮 (opens new window)

[2] DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning from Arxiv (opens new window)

[3] 新研究揭示DeepSeek/o3弱点：频繁切换思路放弃正确方向，最短答案往往就是对的 from 微信公众号 (opens new window)

[4] DeepSeek独立发现o1核心思路，OpenAI首席研究官亲自证实 from 微信公众号 (opens new window)

[5] OpenAl o3-mini System Card from OpenAI官网 (opens new window)

[6] OpenAI推o3-mini新模型，被DeepSeek逼急？定价仍打不过 from 微信公众号 (opens new window)

[7] o3-mini上线，性能未能全面超越DeepSeek R1 from PConline要闻 (opens new window)

[8] OpenAI o3-mini 系统说明书（中文）from 首席AI分享圈 (opens new window)

[9] OpenAI o3-mini from OpenAI官网 (opens new window)

[10] 首个OpenAI免费推理模型o3-mini发布 from 量子位 (opens new window)

[11] 仅需一万块钱！清华团队靠强化学习让 7B模型数学打败GPT-4o from 微信公众号 (opens new window)

[12] DeepSeek R1 671B 完整版本地部署教程来了 from 微信公众号 (opens new window)

[13] OpenAI紧急直播，ChatGPT疯狂开挂「深度研究」！10分钟爆肝万字现AGI雏形，刷榜人类最后考试 from 微信公众号 (opens new window)

[14] Introducing deep research from OpenAI官网 (opens new window)

[15] Thoughts Are All Over the Place: On the Underthinking of o1-Like LLMs from Arxiv (opens new window)

[16] 聊聊DeepSeek-R1的技术路径 from 吃果冻不吐果冻皮 (opens new window)

[17] Run DeepSeek R1Dynamic 1.58-bit from Unsloth AI (opens new window)

[18] 如何评价DeepSeek等大模型在中科院物理所理论竞赛中的表现 from 知乎 (opens new window)

[19] 部署满血DeepSeek R1的避坑指南-vLLM 0.7.1 from 微信公众号 (opens new window)

[20] DeepSeek R1 671B 完整版本地部署教程来了 from 微信公众号 (opens new window)

[21] 昇腾 910B 部署满血 DeepSeek-R1 from 吃果冻不吐果冻皮 (opens new window)

[22] Ollama vs. llama.cpp实测对比 from Software 2.0 (opens new window)

[23] 4090单卡跑满血版DeepSeek-R1，清华团队开源项目再破大模型推理门槛 from 微信公众号 (opens new window)

[24] 什么配置能本地部署并运行满血617B的DeepSeek-R1？from 知乎 (opens new window)

[25] DeepSeek-R1模型推理 from 昇腾社区 (opens new window)

[26] DeepSeek-R1满血蒸馏全适配：国产 GPU 、全平台 & 多机分布式 from 吃果冻不吐果冻皮 (opens new window)

[27] 清华开源KTransformers-让24GB显卡流畅运行满血DeepSeek-R1 from 吃果冻不吐果冻皮 (opens new window)

[28] deepseek技术解读：从V3到R1的MoE架构创新 from 知乎 (opens new window)

[29] DeepSeek揭秘R1官方同款部署设置，温度=0.6！OpenAI推理指南同时上线 from 微信公众号 (opens new window)

[30] 部署DeepSeek-R1最佳体验而推荐的设置 from Twitter (opens new window)

[31] Reasoning best practices from OpenAI官方文档 (opens new window)

[32] GPT-4/o1-level Local VSCode Copilot on a Desktop with only 24GB VRAM from Github (opens new window)

[33] 配这种CPU，GPU单卡就能跑满血DeepSeek-R1，至强+AMX让预填充速度起飞 from 量子位 (opens new window)

[34] 什么配置能本地部署并运行满血671B的DeepSeek-R1？from 知乎 (opens new window)

[35] 全新混合架构，显卡需求超低！教你轻松部署DeepSeek-R1全参数Q4量化，这就是Ktransformers from Bilibili (opens new window)

[36] vLLM 部署DeepSeek-R1 from MKY-技术驿站 (opens new window)

[37] 本地部署DeepSeek-R1-Distill-Qwen-32B，输出仅有</think>，没有<think> from Github issues (opens new window)

[38] deepseek r1满血版本部署 from 微信公众号 (opens new window)

[39] 如何在本地部署DeepSeek-R1模型？from 知乎 (opens new window)

[40] r1满血版部署后推理很慢 from Github issues (opens new window)

[41] 英伟达系列显卡大解析，应当如何选择，含架构技术和性能对比带你解决疑惑 from 博客园 (opens new window)

[42] 算力平台：Nvidia H20 的实用价值 from CSDN (opens new window)

[43] 分布式推理和服务 from vLLM官方文档 (opens new window)

[44] Eval-Scope大模型压力测试 from 知乎 (opens new window)

[45] DeepSeek发新成果。梁文锋亲自参与，实习生挑大梁，显著加速AI训练推理 from 微信公众号 (opens new window)

[46] 实测告诉你：DeepSeek-R1 7B、32B、671B差距有多大？from 微信公众号 (opens new window)

[47] DeepSeek突破H800性能上限，FlashMLA重磅开源，算力成本还能降 from 微信公众号 (opens new window)

[48] 美团开源首发INT8无损满血版DeepSeek R1 from 吃果冻不吐果冻皮 (opens new window)

[49] Qwen开源QwQ-32B，“小”模型性能比肩DeepSeek-R1 from 微信公众号 (opens new window)

[50] 阿里发布开源推理模型 QwQ-32B，支持消费级显卡本地部署，有哪些技术亮点？from 知乎 (opens new window)

[51] QwQ-32B: Embracing the Power of Reinforcement Learning from Qwen官方文档 (opens new window)

[52] 通义QwQ-32B+Milvus，消费级显卡布满血大模型与RAG的时代来了 from 微信公众号 (opens new window)

[53] DeepSeek推理成本需要的相关概念：Throughput、TPOT、TTFT from 吃果冻不吐果冻皮 (opens new window)

[54] H20 141GB DeepSeek实测数据，性价比最高的原生满血版一体机 from 微信公众号 (opens new window)

[55] 实测单卡5090D部署满血DeepSeek-R1过程 from 知乎 (opens new window)

[56] DeepSeek R1私有部署GPU选择指南（英伟达A100、H100、A800、H800、H20系列）from 微信公众号 (opens new window)

[57] 满血DeepSeek-R1 671B 英伟达H20单机/双机FP8精度并发压力测试 from 微信公众号 (opens new window)

[58] 吞吐量破10000tokens/s，VLLM 0.8.1版本驱动下的Deepseek-r1 671B from 微信公众号 (opens new window)

[59] DeepSeek昨夜上新！新旧版V3对比实测，代码能力飙升，震惊海外用户 from 微信公众号 (opens new window)

[60] AMD跑DeepSeek性能超H200！128并发Token间延迟不超50ms，吞吐量达H200五倍 from 微信公众号 (opens new window)

[61] 深入QwQ，工具调用、压测和调优 from 微信公众号 (opens new window)

[62] 一文了解DeepSeek及应用场景 from 吃果冻不吐果冻皮 (opens new window)

[63] 企业级模型推理部署工具vllm使用指南 - 部署最新deepseek-v3-0324模型 from 微信公众号 (opens new window)

[64] DS推理：原生FP8、4算力，B200是h200的5倍 from 微信公众号 (opens new window)

[65] K8s + vLLM & Ray：DeepSeek-r1 671B 分布式推理部署实践 from 微信公众号 (opens new window)

[66] H200部署DeepSeek R1，SGLang调优性能提升2倍，每秒狂飙4000+ Tokens from 知乎 (opens new window)

[67] Understanding Reasoning LLMs from magazine (opens new window)

[68] 图解推理大模型 from 知乎 (opens new window)

[69] 大模型慢思考技术探讨 from 微信公众号 (opens new window)

[70] DeepSeek开源周技术全景 from 博客园 (opens new window)

[71] DeepSeek开源周总结和感悟 from 知乎 (opens new window)

[72] Deepseek开源周解读 from 芯语 (opens new window)

[73] DeepSeek: FlashMLA代码解析 from 知乎 (opens new window)

[74] DeepSeek 开源 DeepGEMM——极致高效的 FP8 矩阵计算库 from 知乎 (opens new window)

[75] DeepSeek-V3 / R1 推理系统概览 from 知乎 (opens new window)

[76] 陈巍：DeepSeek 开源Day（1）-FlashMLA 深入分析 from 知乎 (opens new window)

[77] 陈巍：DeepSeek 开源Day（2）DeepEP深入分析 from 知乎 (opens new window)

[78] 陈巍：DeepSeek 开源Day（3）DeepGEMM深入分析 from 知乎 (opens new window)

[79] 陈巍：DeepSeek 开源Day（4）DualPipe&EPLB深入分析 from 知乎 (opens new window)

[80] 陈巍：DeepSeek 开源Day（5）3FS&smallpond深入分析 from 知乎 (opens new window)

[81] 陈巍：DeepSeek 开源Day（6）推理系统概览解读 from 知乎 (opens new window)

[82] DeepSeek突破H800性能上限，FlashMLA重磅开源，算力成本还能降 from 微信公众号 (opens new window)

[83] DeepSeek 开源周，简单解读第二篇开源工作：DeepEP from 知乎 (opens new window)