DeepSeek 性能优化指南

为什么需要性能优化？

DeepSeek 模型性能强大，但推理成本同样不可忽视。无论是本地部署的单卡用户，还是云端 API 的海量调用，合理的性能优化可以带来 2-10 倍的推理加速，同时大幅降低硬件和 API 成本。本指南覆盖从量化、KV Cache、批处理到分布式推理的完整优化链路。

性能指标体系

在开始优化之前，必须先建立正确的性能评估体系。没有衡量标准，优化就是盲人摸象。以下是你需要关注的六个核心指标。

六大核心性能指标

指标	英文	说明	优化目标
吞吐量	TPS / TGS	每秒生成的 token 数（Tokens Per Second / Tokens Generated per Second）	越高越好
首 Token 延迟	TTFT	Time To First Token，从请求发出到第一个 token 生成的时间	越低越好
每 Token 延迟	TPOT	Time Per Output Token，每个输出 token 的平均生成时间	越低越好
GPU 利用率	GPU Util	GPU 计算核心的使用率，反映计算资源是否被充分利用	越高越好
显存占用	VRAM	模型推理时占用的 GPU 显存（GB），决定能跑多大的模型	越低越好
吞吐延迟比	QPS/P99	在满足 P99 延迟要求下的最大吞吐量，SLA 核心指标	越高越好

吞吐量 vs 延迟：鱼与熊掌

性能优化的核心矛盾在于吞吐量和延迟之间的权衡。增大 batch size 可以提高吞吐量，但会增加 TTFT；降低精度可以加速推理，但可能影响回答质量。优秀的优化方案需要在两者之间找到最佳平衡点。

离线批处理场景（如评测、数据标注）：优先追求吞吐量，延迟可以容忍
在线服务场景（如聊天机器人、API）：优先控制延迟，TTFT 通常需要 < 500ms
实时交互场景（如语音助手）：极度关注延迟，TTFT 需要 < 200ms

性能监控工具

# GPU 实时监控
nvidia-smi dmon -s pucvmet -d 1

# vLLM 自带性能指标（Prometheus 格式）
# 启动时添加 --disable-log-requests 减少日志开销
vllm serve deepseek-ai/DeepSeek-V3 \
  --host 0.0.0.0 --port 8000 \
  --disable-log-requests

# 使用 benchmark_serving.py 压测
python benchmarks/benchmark_serving.py \
  --backend vllm \
  --model deepseek-ai/DeepSeek-V3 \
  --dataset-name sharegpt \
  --num-prompts 1000 \
  --request-rate 10

量化技术详解

量化是将模型参数从高精度（FP16/BF16）压缩到低精度（INT8/INT4）的技术。合理的量化可以在几乎不损失精度的情况下，将显存占用降低 50%-75%，推理速度提升 2-4 倍。

主流量化方法对比

量化方法	精度	显存节省	速度提升	精度损失	推荐场景
GPTQ	INT4/INT8	~60%	2-3x	极小	GPU 推理，追求精度
AWQ	INT4	~60%	2-3x	极小	GPU 推理，速度优先
GGUF	Q2-Q8	40%-75%	1.5-4x	取决于级别	CPU/混合推理，灵活部署
FP8	FP8	~50%	1.5-2x	几乎无	H100/H200，原生支持

GGUF 量化级别详解

GGUF 提供了从 Q2 到 Q8 的多种量化级别，数字越大精度越高，模型越大。以下是 DeepSeek-R1-8B 在不同量化级别下的表现：

量化级别	模型大小	推理速度	MMLU 得分	推荐度
Q2_K	3.2 GB	极快	~58.2	不推荐
Q3_K_M	4.0 GB	快	~62.5	低配设备
Q4_K_M	5.2 GB	较快	~65.8	强烈推荐
Q5_K_M	6.4 GB	适中	~66.8	推荐
Q6_K	7.4 GB	正常	~67.5	高质量需求
Q8_0	8.5 GB	正常	~67.9	最高精度

使用 GPTQ/AWQ 量化 DeepSeek

# 使用 AutoGPTQ 加载量化模型
from transformers import AutoTokenizer
from auto_gptq import AutoGPTQForCausalLM

model = AutoGPTQForCausalLM.from_quantized(
    "deepseek-ai/DeepSeek-V3-GPTQ-Int4",
    device="cuda:0",
    use_triton=True,  # 使用 Triton 加速推理
)
tokenizer = AutoTokenizer.from_pretrained("deepseek-ai/DeepSeek-V3-GPTQ-Int4")

# 使用 vLLM 加载 AWQ 量化模型
# vllm serve deepseek-ai/DeepSeek-V3-AWQ --quantization awq

量化方法选择决策树

使用 Ollama 本地运行：选择 GGUF Q4_K_M，速度与精度的最佳平衡点
使用 vLLM 部署服务：优先使用 AWQ INT4，vLLM 原生支持，性能最佳
H100/H200 显卡：使用 FP8 量化，原生 Transformer Engine 加速
CPU 推理：使用 GGUF Q4_K_M 或 Q5_K_M，搭配 llama.cpp 获得最佳性能
极致精度需求：使用 GPTQ INT8 或不量化，保留 BF16 精度

KV Cache 优化

KV Cache 是 Transformer 推理的核心机制，也是显存占用的主要来源。理解和优化 KV Cache，是提升推理性能的关键一步。

KV Cache 工作原理

在自回归生成过程中，每个新 token 都需要与所有历史 token 计算注意力。KV Cache 将已计算的 Key 和 Value 矩阵缓存起来，避免重复计算。对于上下文长度为 N、隐藏维度为 d 的模型，KV Cache 的内存占用约为：

KV Cache 大小 = 2 * num_layers * N * d * num_heads * 2_bytes
    

以 DeepSeek-V3（671B 参数，MoE 架构）为例，在 128K 上下文下，KV Cache 可能占用数十 GB 显存，远超模型权重本身。

KV Cache 量化（FP8 KV Cache）

将 KV Cache 从 FP16 量化为 FP8 或 INT8，可以在几乎不损失精度的情况下，将 KV Cache 显存占用减半。这是目前最成熟、效果最显著的 KV Cache 优化手段。

# vLLM 启用 FP8 KV Cache
vllm serve deepseek-ai/DeepSeek-V3 \
  --kv-cache-dtype fp8 \
  --max-model-len 131072 \
  --gpu-memory-utilization 0.95

# SGLang 启用 FP8 KV Cache
python -m sglang.launch_server \
  --model deepseek-ai/DeepSeek-V3 \
  --kv-cache-dtype fp8_e5m2 \
  --context-length 131072

Prefix Caching（前缀缓存）

在多轮对话中，每轮对话的 system prompt 和历史对话内容完全相同。Prefix Caching 将已计算的 KV Cache 复用，避免为相同的前缀重复计算。这在以下场景中效果显著：

多轮对话：system prompt + 历史消息完全复用，TTFT 可降低 50%-80%
批量评测：多个样本共享相同的 instruction 前缀
Few-shot 推理：多个请求共享相同的 few-shot 示例前缀
RAG 场景：多个问题共享相同的检索上下文前缀

# vLLM 启用 Automatic Prefix Caching（默认启用）
vllm serve deepseek-ai/DeepSeek-V3 \
  --enable-prefix-caching

# SGLang 的 RadixAttention 自动启用前缀缓存
# 无需额外配置，默认开启

多轮对话优化实践

# 优化前：每次请求都重新计算整个对话历史
messages = [
    {"role": "system", "content": system_prompt},
    {"role": "user", "content": "问题1"},
    {"role": "assistant", "content": "回答1"},
    {"role": "user", "content": "问题2"},  # system + 历史每次都重新计算
]

# 优化后：启用 Prefix Caching，system prompt 和历史消息的 KV Cache 被复用
# 第二轮的 TTFT 从 500ms 降至 50ms

批处理优化

批处理（Batching）是提升 GPU 利用率最直接的手段。但传统的静态批处理在 LLM 推理中面临严重挑战：不同请求的输出长度差异巨大，导致 GPU 空转。Continuous Batching 解决了这个问题。

Static Batching vs Continuous Batching

对比维度	Static Batching	Continuous Batching
工作机制	等待 batch 中所有请求完成后才处理下一批	请求完成后立即替换为新请求，动态调整
GPU 利用率	低，短请求等待长请求	高，GPU 几乎无空闲
吞吐量	低	高，可达 10x 提升
实现框架	HuggingFace Transformers	vLLM, SGLang, TGI

最佳 Batch Size 选择

Batch size 并非越大越好。过大的 batch size 会增加延迟，过小则无法充分利用 GPU。最佳 batch size 取决于以下因素：

GPU 显存大小：batch size 受限于 KV Cache 可用显存。24GB 显存（RTX 4090）建议 max_num_seqs=32-64
请求负载：高并发场景适当增大 batch size，低负载场景保持较小 batch size 以降低延迟
序列长度：长上下文场景 batch size 需要调小，因为 KV Cache 占用更大
模型大小：大模型（如 DeepSeek-V3）的 batch size 通常小于小模型（如 DeepSeek-R1-8B）

vLLM Continuous Batching 配置

# vLLM 批处理相关参数
vllm serve deepseek-ai/DeepSeek-V3 \
  --max-num-seqs 64 \             # 最大并发序列数（batch size 上限）
  --max-num-batched-tokens 8192 \ # 每次迭代最多处理的 token 数
  --max-model-len 32768 \          # 最大上下文长度
  --gpu-memory-utilization 0.95    # GPU 显存使用率

动态批处理策略

Chunked Prefill：将长 prompt 的 prefill 阶段分块处理，与 decode 阶段交替执行，避免 prefill 阻塞 decode
Priority Scheduling：为不同请求设置优先级，高优先级请求优先进入 batch
Length-aware Batching：将相似长度的请求放入同一 batch，减少 padding 浪费
Iteration-level Scheduling：每次迭代重新评估 batch 组成，动态加入新请求

推测解码（Speculative Decoding）

推测解码是近年来最受关注的推理加速技术之一。它利用一个小型"草稿模型"快速生成候选 token，再由大型"目标模型"并行验证，在不损失精度的前提下实现 2-3 倍的推理加速。

推测解码原理

大模型推理的瓶颈在于自回归生成：每次只能生成一个 token，无法并行化。推测解码通过"小模型猜测 + 大模型验证"的方式，将串行生成变为并行验证：

草稿阶段：小模型（Draft Model）快速生成 K 个候选 token（如 K=5）
验证阶段：大模型（Target Model）一次前向传播验证所有 K 个 token
接受/拒绝：根据概率分布接受正确的 token，拒绝不匹配的 token
重复：从第一个被拒绝的位置开始，继续上述过程

加速比分析

推测解码的加速比取决于草稿模型的"接受率"（Acceptance Rate）。接受率越高，加速效果越好。典型场景下：

目标模型	草稿模型	接受率	加速比
DeepSeek-V3 (671B)	DeepSeek-V3-Lite (16B)	~85%	2.5x
DeepSeek-R1 (671B)	DeepSeek-R1-Distill-Llama-8B	~80%	2.2x
DeepSeek-Coder-V2	DeepSeek-Coder-1.3B	~90%	3.0x

DeepSeek 推测解码实现

# 使用 vLLM 的推测解码
vllm serve deepseek-ai/DeepSeek-V3 \
  --speculative-model deepseek-ai/DeepSeek-V3-Lite \
  --num-speculative-tokens 5 \
  --speculative-draft-tensor-parallel-size 1

# 使用 HuggingFace 的推测解码
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

target_model = AutoModelForCausalLM.from_pretrained(
    "deepseek-ai/DeepSeek-V3", torch_dtype=torch.bfloat16
).to("cuda")

draft_model = AutoModelForCausalLM.from_pretrained(
    "deepseek-ai/DeepSeek-V3-Lite", torch_dtype=torch.bfloat16
).to("cuda")

# 使用 assisted_decoding 或 prompt_lookup_decoding
output = target_model.generate(
    input_ids,
    assistant_model=draft_model,
    max_new_tokens=256,
    do_sample=True,
    temperature=0.7,
)

草稿模型选择建议

草稿模型应满足三个条件：1) 与目标模型同系列或同架构，确保高接受率；2) 参数量为目标模型的 1/10 到 1/50；3) 推理速度明显快于目标模型。对于 DeepSeek-V3，推荐使用 DeepSeek-V3-Lite 或 DeepSeek-R1-Distill-Qwen-1.5B 作为草稿模型。

显存优化

显存是 LLM 推理的最大瓶颈。一个 671B 参数的 DeepSeek-V3 模型，即使使用 FP16 也需要 ~1.3TB 显存。通过下面这些技术，你可以在有限的显存上运行更大的模型。

Gradient Checkpointing（梯度检查点）

虽然主要用于训练，但梯度检查点的思想也影响推理。在推理中，通过不保存中间激活值，用计算换空间，可以显著降低显存占用。这在长上下文推理中尤为关键。

CPU Offloading（CPU 卸载）

将部分模型层或 KV Cache 卸载到 CPU 内存中，虽然会牺牲一些速度，但可以让原本无法运行的模型跑起来：

# llama.cpp 的 GPU 层数控制（Ollama 底层）
# 将部分层卸载到 CPU，减少 GPU 显存占用
ollama run deepseek-r1:8b

# 在 Ollama 对话中设置 GPU 层数
# /set parameter num_gpu 20  # 仅 20 层在 GPU 上，其余在 CPU

# HuggingFace Accelerate 的 CPU Offloading
from accelerate import infer_auto_device_map, dispatch_model
device_map = infer_auto_device_map(
    model,
    max_memory={0: "16GiB", "cpu": "64GiB"},
)
model = dispatch_model(model, device_map=device_map)

FlashAttention

FlashAttention 是一种 IO-aware 的精确注意力算法，通过分块计算和重计算策略，将注意力计算的时间和显存复杂度从 O(N^2) 降低到接近 O(N)。vLLM 和 SGLang 均已默认集成 FlashAttention。

版本	核心改进	速度提升	显存节省
FlashAttention-1	IO-aware 分块计算，避免 O(N^2) 显存	2-3x	10-20x
FlashAttention-2	优化并行策略，减少非矩阵乘法操作	2x (vs FA1)	与 FA1 相当
FlashAttention-3	针对 H100 优化，异步计算，FP8 支持	1.5-2x (vs FA2)	与 FA2 相当

PagedAttention

PagedAttention 是 vLLM 的核心创新，将 KV Cache 像操作系统的虚拟内存分页一样管理。它将 KV Cache 分割为固定大小的"页面"（Block），按需分配和释放，解决了 KV Cache 碎片化和浪费的问题：

显存利用率提升：从传统方案的 20%-40% 提升到接近 100%
支持更大 Batch Size：同样的显存可以处理更多并发请求
内存共享：并行采样（beam search）时，多个序列共享相同的 KV Cache 页面
无需预留：不再需要为每个请求预留最大长度的 KV Cache 空间

# vLLM 的 PagedAttention 配置
vllm serve deepseek-ai/DeepSeek-V3 \
  --block-size 16 \              # KV Cache 页面大小（token 数）
  --gpu-memory-utilization 0.95 \ # 用满 95% 显存
  --max-num-seqs 128              # 最大并发序列数

张量并行与流水线并行

当单个 GPU 无法容纳整个模型时，需要使用分布式推理技术。张量并行（TP）和流水线并行（PP）是两种最常用的分布式策略，理解它们的区别和适用场景至关重要。

TP vs PP 对比

对比维度	张量并行（TP）	流水线并行（PP）
切分方式	将单层权重矩阵切分到多张 GPU	将不同层分配到不同 GPU
通信量	高，每层都需要 AllReduce	低，仅层间传输激活值
GPU 利用率	高，所有 GPU 同时工作	有气泡（Bubble），部分 GPU 空闲
跨节点通信	不推荐，通信瓶颈严重	适合，通信量小
推荐 GPU 数	2-8，单节点内	4-32，可跨节点

不同模型规模的最优配置

模型	参数量	推荐 GPU	TP	PP	总 GPU
DeepSeek-R1-8B	8B	RTX 4090	1	1	1
DeepSeek-R1-70B	70B	A100 80GB	4	1	4
DeepSeek-V3	671B (37B active)	H100 80GB	8	1	8
DeepSeek-V3 (Full)	671B	A100 80GB	8	2	16

vLLM 分布式推理配置

# 单节点 8 GPU，张量并行
vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.95

# 多节点：2 节点各 8 GPU，TP=8 PP=2
# 节点 0
vllm serve deepseek-ai/DeepSeek-V3 \
  --tensor-parallel-size 8 \
  --pipeline-parallel-size 2

# 通信优化：使用 NCCL 环境变量
# export NCCL_SOCKET_IFNAME=eth0
# export NCCL_IB_DISABLE=0  # 启用 InfiniBand
# export NCCL_NET_GDR_LEVEL=5  # GPUDirect RDMA

通信成本优化

分布式推理的通信开销是性能杀手。以下手段可以显著降低通信成本：

NVLink/NVSwitch：单节点内使用 NVLink 连接 GPU，带宽 900GB/s，远超 PCIe
InfiniBand：跨节点使用 InfiniBand（200-400GB/s），避免使用以太网
GPUDirect RDMA：GPU 直接通过 RDMA 通信，绕过 CPU，减少延迟
通信-计算重叠：将 AllReduce 通信与下一层的计算重叠执行

硬件选型与成本优化

选择合适的硬件，是在性能与成本之间找到最佳平衡点的关键。不同 GPU 的性能差异巨大，同一模型在不同硬件上的推理成本可能相差数十倍。

GPU 性能对比

GPU	显存	FP16 算力	带宽	云租用价格	适合模型
T4	16 GB	65 TFLOPS	320 GB/s	~$0.35/h	7B 以下模型
A10	24 GB	125 TFLOPS	600 GB/s	~$0.75/h	8B-13B 模型
A100 80GB	80 GB	312 TFLOPS	2,039 GB/s	~$1.50/h	70B 模型，MoE 模型
H100 80GB	80 GB	989 TFLOPS	3,352 GB/s	~$2.80/h	DeepSeek-V3，FP8 推理

每 Token 成本估算

以 DeepSeek-R1-8B（Q4_K_M 量化）为例，在不同 GPU 上的推理成本：

GPU	TPS	每小时 Token 数	每百万 Token 成本
T4	~40	144K	$2.43
A10	~80	288K	$2.60
A100	~200	720K	$2.08
DeepSeek API	-	-	$0.14 (V3)

注意：DeepSeek 官方 API 的价格远低于自建 GPU 推理成本，对于大多数场景，使用 API 比自建服务更经济。只有每日调用量超过千万 token 时，自建 GPU 集群才可能具有成本优势。

云端 vs 自建

对比维度	云端 GPU	自建机房
初始投入	零	高（H100 ~$30K/张）
弹性	高，随时扩缩	低，硬件固定
数据安全	需评估合规性	完全可控
日均成本	按需付费	固定（电费+运维）

Spot Instance 策略

使用云厂商的 Spot/Preemptible 实例可以节省 60%-90% 的 GPU 成本。但 Spot 实例可能随时被回收，需要做好容错设计：

多区域部署：在不同可用区启动 Spot 实例，降低同时被回收的概率
Checkpoint 机制：定期保存推理服务的状态，被回收后快速恢复
混合策略：核心服务用按需实例，弹性负载用 Spot 实例
预热池：保持一定数量的空闲实例作为缓冲，Spot 回收时无缝切换

性能 Benchmark 实测

以下是基于真实环境的性能测试数据，对比不同推理框架在不同硬件上的表现。所有测试使用 DeepSeek-R1-8B（Q4_K_M 量化），输入 512 tokens，输出 256 tokens。

推理框架性能对比（RTX 4090 24GB）

框架	TPS	TTFT	并发 8	并发 32	显存占用
Ollama	~65	~280ms	-	-	~5.5 GB
vLLM	~120	~150ms	~850 TPS	~2,400 TPS	~6.8 GB
SGLang	~135	~120ms	~920 TPS	~2,600 TPS	~6.5 GB
TGI	~110	~160ms	~800 TPS	~2,200 TPS	~7.0 GB

SGLang 在 DeepSeek 模型上表现最优，得益于其 RadixAttention 和高效的 MoE 调度。vLLM 紧随其后，生态更成熟。Ollama 适合个人使用，不适合高并发服务。

不同模型规模性能对比（vLLM + A100 80GB）

模型	量化	单卡 TPS	4 卡 TP TPS	显存/卡
DeepSeek-R1-8B	AWQ INT4	~180	-	~6 GB
DeepSeek-R1-32B	AWQ INT4	~70	-	~22 GB
DeepSeek-R1-70B	AWQ INT4	-	~180	~40 GB
DeepSeek-V3	FP8	-	~120	~65 GB

不同硬件下 DeepSeek-R1-8B 性能

硬件	显存	Ollama TPS	vLLM TPS	适合场景
Apple M2 16GB	统一内存	~15	-	个人体验
RTX 4060 8GB	8 GB	~30	~50	入门开发
RTX 4090 24GB	24 GB	~65	~120	小团队服务
A100 80GB	80 GB	~90	~180	生产服务
H100 80GB	80 GB	~130	~280	大规模生产

优化 Checklist

从基线到生产，按照以下步骤逐步优化你的 DeepSeek 推理服务。每一步都能带来可量化的性能提升。

第一阶段：基础优化（立竿见影）

选择正确的推理框架：从 Ollama 切换到 vLLM 或 SGLang，获得 Continuous Batching 和 PagedAttention，吞吐量提升 2-5x
启用模型量化：使用 AWQ INT4 或 GGUF Q4_K_M，显存降低 60%，速度提升 2-3x
启用 FlashAttention：vLLM/SGLang 默认已启用，无需额外配置
设置合理的 max_model_len：不要超过实际需要的上下文长度，避免 KV Cache 浪费
调整 gpu_memory_utilization：从默认 0.90 提升到 0.95，充分利用显存

第二阶段：进阶优化（显著提升）

启用 FP8 KV Cache：KV Cache 显存减半，支持更大 batch size 和更长上下文
启用 Prefix Caching：多轮对话场景 TTFT 降低 50%-80%
配置 Chunked Prefill：避免长 prompt 阻塞其他请求的 decode
调优 max_num_seqs：根据 GPU 显存和并发量，找到最优并发数
启用推测解码：选择合适的小模型作为草稿模型，获得 2-3x 加速

第三阶段：生产级优化（极致性能）

张量并行部署：大模型（70B+）使用 TP 拆分到多卡，突破单卡显存限制
使用 NVLink/InfiniBand：分布式推理使用高速互联，降低通信开销
启用 NCCL 优化：配置 GPUDirect RDMA、NCCL_NET_GDR_LEVEL 等参数
混合精度推理：H100 使用 FP8，其他 GPU 使用 BF16，平衡精度和速度
压测和监控：使用 benchmark_serving.py 定期压测，Prometheus + Grafana 监控性能指标

性能优化决策速查表

你的问题	优先尝试	预期提升
显存不够跑模型	AWQ/GPTQ INT4 量化 + CPU Offloading	显存降低 60%+
推理速度太慢	切换到 vLLM/SGLang + 量化	速度提升 3-5x
并发处理能力不足	Continuous Batching + FP8 KV Cache	并发提升 3-8x
多轮对话首 token 慢	Prefix Caching	TTFT 降低 50%-80%
长上下文推理 OOM	FP8 KV Cache + 降低 max_num_seqs	上下文长度翻倍
GPU 成本太高	Spot Instance + 量化 + 小模型	成本降低 60%-90%

DeepSeek 性能优化常见问题

Ollama 和 vLLM 的性能差距有多大？ +

在单请求场景下，vLLM 比 Ollama 快约 1.5-2 倍。但在高并发场景下，vLLM 的 Continuous Batching 和 PagedAttention 优势明显，吞吐量可达 Ollama 的 5-10 倍。如果你需要构建生产级 API 服务，强烈建议使用 vLLM 或 SGLang。个人使用场景下，Ollama 的简洁性和易用性更有优势。详见 DeepSeek 部署教程。

AWQ 和 GPTQ 量化选哪个？ +

推荐 AWQ。AWQ 在推理速度上通常优于 GPTQ（约 10%-20%），且 vLLM 对 AWQ 有原生支持，集成更简单。GPTQ 在精度保持上略优于 AWQ（差距极小，通常小于 0.5%），如果你对精度要求极高，可以选择 GPTQ INT8。大多数场景下，AWQ INT4 是速度与精度的最佳平衡。更多模型量化信息请查看 DeepSeek 开源模型。

显存不够跑 DeepSeek-V3，怎么办？ +

DeepSeek-V3 是 671B 参数的 MoE 模型，即使量化后也需要 8 张 A100/H100。如果你的硬件不足，有以下方案：1) 使用 DeepSeek 官方 API，成本极低（输入 1 元/百万 tokens）；2) 使用 DeepSeek-R1 蒸馏版（1.5B-70B），性能接近但需求低得多；3) 使用云端 GPU 按需租用。详见 DeepSeek 模型架构详解。

推测解码在所有场景下都有效吗？ +

并非所有场景。推测解码在以下场景效果最好：1) 输出内容确定性高（如代码生成、翻译）；2) 草稿模型与目标模型同架构同训练数据；3) 显存足够同时加载两个模型。在创意写作等随机性高的场景中，接受率可能低于 60%，加速效果有限。建议先在小规模测试中验证接受率，再决定是否启用。

如何选择 Ollama 的 GGUF 量化级别？ +

Q4_K_M 是绝大多数场景的最佳选择，速度与精度的平衡点。如果你显存紧张（8GB 以下），选 Q3_K_M；如果追求最高质量（16GB+ 显存），选 Q5_K_M 或 Q6_K。Q2 级别精度损失明显，不推荐。使用 ollama run deepseek-r1:8b 默认下载 Q4_K_M 版本。更多下载指南请查看 DeepSeek 模型下载。

Continuous Batching 需要特殊配置吗？ +

vLLM 和 SGLang 默认启用 Continuous Batching，无需额外配置。你只需要关注两个关键参数：max_num_seqs（最大并发序列数）和 max_num_batched_tokens（每次迭代最大 token 数）。建议从默认值开始，根据实际负载和显存使用情况逐步调整。如果 GPU 利用率低，增大 max_num_seqs；如果出现 OOM，减小 max_num_seqs 或降低 max_model_len。

DeepSeek 相关教程

深入学习 DeepSeek 模型的部署、使用和开发。

部署教程

DeepSeek 部署教程

Ollama、Docker、vLLM、K8s 部署方案，从单机到集群。

模型详解

DeepSeek 模型架构

技术架构、Benchmark、MoE 详解、选型对比。

模型列表

DeepSeek 开源模型

6 大系列、20+ 模型完整目录与对比。

下载指南

DeepSeek 模型下载

Ollama、Hugging Face、GitHub 下载指南。

入门教程

DeepSeek 模型怎么用

四种使用方式，零基础入门教程。

模型微调

DeepSeek 微调教程

LoRA、QLoRA、全量微调完整指南。