DeepSeek 推理加速深度教程
全面掌握 DeepSeek 模型推理加速技术。vLLM、SGLang、TensorRT-LLM、llama.cpp 四大引擎深度对比，从部署到调优，从单卡到分布式，完整的推理加速方案。
开始学习DeepSeek 推理加速
为什么需要推理加速？
DeepSeek-V3 拥有 671B 参数，DeepSeek-R1 更是以强化学习驱动推理能力。如此庞大的模型，直接使用原生 PyTorch 推理效率极低。专用推理引擎通过 KV Cache 优化、Continuous Batching、量化压缩、算子融合等技术，可以将推理吞吐量提升 10-50 倍，延迟降低 80% 以上。
核心概念
推理引擎概述
推理引擎是连接训练好的模型权重与生产环境推理请求的中间层。它负责内存管理、批处理调度、计算优化，是决定推理性能和成本的核心组件。
推理性能关键指标
| 吞吐量 (Throughput) | 单位时间内处理的 token 总数（tokens/s）。衡量系统整体处理能力，越高越好。 |
| 首 Token 延迟 (TTFT) | Time To First Token — 从发送请求到收到第一个 token 的时间。影响用户体验的关键指标。 |
| 每 Token 延迟 (TPOT) | Time Per Output Token — 生成每个 token 的平均耗时。影响流式输出的流畅度。 |
| 显存占用 (VRAM) | 模型加载和推理时占用的 GPU 显存（GB）。直接影响可部署的模型规模和批处理大小。 |
主流推理引擎生态
| 引擎 | 开发方 | 核心优势 | 适用场景 |
|---|---|---|---|
| vLLM | UC Berkeley | PagedAttention 显存管理，吞吐量极高 | 生产环境 API 服务 |
| SGLang | Stanford/LMSYS | RadixAttention 前缀缓存，结构化生成 | 多轮对话、Agent 场景 |
| TensorRT-LLM | NVIDIA | 极致 GPU 优化，FP8/INT4 量化 | NVIDIA GPU 极致性能 |
| llama.cpp | ggerganov | CPU/GPU 混合推理，GGUF 量化 | 个人电脑、边缘设备 |
推理加速核心技术栈
- KV Cache 管理：缓存已计算的 Key-Value 矩阵，避免重复计算。PagedAttention 将 KV Cache 分页管理，显存利用率提升 2-4 倍
- Continuous Batching：动态批处理，请求完成后立即替换为新请求，GPU 利用率持续保持高位
- 量化（Quantization）：将 FP16 权重压缩为 INT8/INT4/FP8，显存占用降低 50%-75%，精度损失极小
- 算子融合（Kernel Fusion）：将多个 CUDA 算子合并为一个，减少显存读写，提升计算效率
- 张量并行（Tensor Parallelism）：将单层权重切分到多张 GPU，突破单卡显存限制
- 投机解码（Speculative Decoding）：用小模型快速生成候选 token，大模型验证，加速 2-3 倍
选型建议
生产环境 API 服务首选 vLLM；多轮对话和 Agent 场景推荐 SGLang；追求极致 GPU 性能选 TensorRT-LLM；个人电脑和边缘设备用 llama.cpp。更多模型细节请查看 DeepSeek 模型架构详解。
第 1 步
vLLM 部署 DeepSeek
vLLM 是目前最流行的开源推理引擎，由 UC Berkeley 开发。其核心创新 PagedAttention 将 KV Cache 像操作系统分页一样管理，显存利用率提升 2-4 倍，吞吐量提升 10-30 倍。
PagedAttention 原理
传统推理引擎为每个请求预分配连续显存空间存放 KV Cache，导致严重的显存碎片和浪费（利用率仅 20%-40%）。PagedAttention 将 KV Cache 划分为固定大小的 Block，按需分配、动态映射，显存利用率可达 96% 以上。
- KV Cache 分块：每个 Block 存储固定数量 token 的 Key 和 Value 向量
- 按需分配：请求到达时才分配 Block，不预分配连续空间
- 内存共享：并行采样和 Beam Search 场景下，相同 Prompt 的 KV Cache 可以共享
- Copy-on-Write：写入时才复制 Block，最大化共享
vLLM 安装配置
# 安装 vLLM（推荐使用 pip）
pip install vllm
# 从源码安装（获取最新特性）
git clone https://github.com/vllm-project/vllm.git
cd vllm
pip install -e .
# 验证安装
python -c "import vllm; print(vllm.__version__)"
DeepSeek-V3/R1 部署命令
DeepSeek-V3 和 R1 是 671B 参数的 MoE 模型，需要多卡部署。以下是使用 vLLM 部署的完整命令：
# DeepSeek-V3/R1 671B 多卡部署（8x A100/H100 80GB）
vllm serve deepseek-ai/DeepSeek-V3 \
--tensor-parallel-size 8 \
--max-model-len 8192 \
--gpu-memory-utilization 0.95 \
--max-num-seqs 256 \
--enable-prefix-caching \
--trust-remote-code
# DeepSeek-R1 蒸馏版本部署（单卡 A100 80GB）
vllm serve deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--tensor-parallel-size 1 \
--max-model-len 4096 \
--gpu-memory-utilization 0.90 \
--dtype bfloat16 \
--trust-remote-code
# DeepSeek-R1-Distill-Qwen-32B（单卡 RTX 4090 24GB）
vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
--max-model-len 4096 \
--gpu-memory-utilization 0.85 \
--dtype float16 \
--trust-remote-code
vLLM 性能调优参数
| 参数 | 说明 | 推荐值 |
|---|---|---|
| --max-num-seqs | 最大并发请求数 | 128-256 |
| --max-num-batched-tokens | 单次批处理最大 token 数 | 8192-16384 |
| --gpu-memory-utilization | GPU 显存使用率上限 | 0.90-0.95 |
| --enable-prefix-caching | 启用前缀缓存（共享 Prompt 自动复用 KV Cache） | 开启 |
| --enable-chunked-prefill | 分块预填充，长 Prompt 不阻塞其他请求 | 开启 |
Python API 调用示例
from openai import OpenAI
# vLLM 默认提供 OpenAI 兼容 API
client = OpenAI(
base_url="http://localhost:8000/v1",
api_key="not-needed",
)
response = client.chat.completions.create(
model="deepseek-ai/DeepSeek-V3",
messages=[
{"role": "system", "content": "你是一个专业的编程助手。"},
{"role": "user", "content": "用 Python 实现快速排序算法。"},
],
temperature=0.7,
max_tokens=2048,
stream=True,
)
for chunk in response:
if chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="")
提示
vLLM 的 OpenAI 兼容 API 可以直接替换任何使用 OpenAI SDK 的应用，无需修改代码逻辑。生产环境建议配合 Nginx 做负载均衡和限流。
第 2 步
SGLang 部署 DeepSeek
SGLang 由斯坦福大学和 LMSYS 组织联合开发，是面向 LLM 服务的下一代推理引擎。其核心创新 RadixAttention 和结构化生成语言，在复杂 Prompt 场景下性能显著优于 vLLM。
RadixAttention 原理
RadixAttention 是一种基于前缀树（Radix Tree）的 KV Cache 自动复用技术。传统的 KV Cache 只能按请求复用，而 RadixAttention 可以自动识别不同请求之间的公共前缀并复用缓存，在少样本学习、多轮对话、Agent 等场景中性能提升巨大。
- 前缀树存储：所有请求的 KV Cache 按前缀组织成树结构
- 自动匹配：新请求到达时，自动匹配最长公共前缀并复用 KV Cache
- LRU 驱逐：使用 LRU 策略管理缓存，在显存限制下最大化缓存命中率
- 无需配置：RadixAttention 完全自动工作，无需手动设置前缀
SGLang 安装配置
# 安装 SGLang（推荐 pip）
pip install sglang[all]
# 或从源码安装
git clone https://github.com/sgl-project/sglang.git
cd sglang
pip install -e "python[all]"
# 验证安装
python -c "import sglang; print(sglang.__version__)"
DeepSeek 部署命令
# DeepSeek-V3 多卡部署（8x H100 80GB）
python -m sglang.launch_server \
--model deepseek-ai/DeepSeek-V3 \
--tp 8 \
--context-length 8192 \
--mem-fraction-static 0.85 \
--enable-radix-cache
# DeepSeek-R1 蒸馏版（2x A100 80GB）
python -m sglang.launch_server \
--model deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--tp 2 \
--context-length 4096 \
--mem-fraction-static 0.90
# DeepSeek-Coder-V2 代码推理（单卡 H100）
python -m sglang.launch_server \
--model deepseek-ai/DeepSeek-Coder-V2-Instruct \
--tp 1 \
--context-length 16384 \
--dtype bfloat16 \
--enable-radix-cache
SGLang 前端编程语言
SGLang 提供了一套 DSL（领域特定语言），可以在 Python 中声明式地编写复杂的 LLM 交互逻辑，自动实现前缀缓存、并行调用等优化：
import sglang as sgl
@sgl.function
def multi_turn_chat(s, system_prompt, user_question):
# 系统提示会自动缓存，多轮对话复用
s += sgl.system(system_prompt)
s += sgl.user(user_question)
s += sgl.assistant(sgl.gen("answer", max_tokens=1024))
# 并行调用多个分支
@sgl.function
def parallel_eval(s, question):
s += sgl.system("评估以下方案。")
s += sgl.user(question)
# 并行生成三个维度的评估
s += sgl.fork(3)
s += sgl.gen("score", max_tokens=10, regex=r"\d+\.\d+")
s += sgl.gen("reason", max_tokens=200)
s += sgl.gen("suggestion", max_tokens=200)
s += sgl.join()
# 设置运行时后端
runtime = sgl.Runtime(model_path="deepseek-ai/DeepSeek-V3")
sgl.set_default_backend(runtime)
# 执行
state = multi_turn_chat.run(
system_prompt="你是一个专业的编程助手。",
user_question="解释 PagedAttention 的原理。",
)
print(state["answer"])
前缀缓存优化效果
| 场景 | 无缓存 TTFT | 有缓存 TTFT | 加速比 |
|---|---|---|---|
| 多轮对话（5 轮） | 450ms | 120ms | 3.75x |
| 少样本提示（10-shot） | 820ms | 150ms | 5.46x |
| Agent 工具调用 | 380ms | 90ms | 4.22x |
第 3 步
TensorRT-LLM 部署 DeepSeek
TensorRT-LLM 是 NVIDIA 官方推出的推理引擎，深度集成 CUDA 和 TensorRT 生态。通过图优化、内核自动调优和量化技术，在 NVIDIA GPU 上能实现最高的推理性能。
TensorRT-LLM 核心特性
- 图优化：自动进行层融合、常量折叠、死代码消除等计算图优化
- 内核自动调优：针对具体 GPU 架构（H100/A100/L40S）自动选择最优 CUDA 内核
- FP8 原生支持：H100 的 FP8 Tensor Core 加速，吞吐量提升 2 倍
- INT4/INT8 量化：支持 Weight-Only 和 SmoothQuant 量化方案
- In-flight Batching：NVIDIA 对 Continuous Batching 的实现，延迟更低
安装 TensorRT-LLM
# 从 Docker 开始（推荐，避免环境问题）
docker pull nvcr.io/nvidia/tritonserver:24.06-trtllm-python-py3
# 运行容器
docker run --gpus all -it --rm \
-v /path/to/models:/models \
nvcr.io/nvidia/tritonserver:24.06-trtllm-python-py3
# 或在容器内 pip 安装
pip install tensorrt_llm -U --extra-index-url https://pypi.nvidia.com
模型编译与转换
TensorRT-LLM 需要先将 Hugging Face 模型转换为 TensorRT Engine 格式：
# 第一步：转换为 TensorRT-LLM 检查点格式
python convert_checkpoint.py \
--model_dir deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--output_dir ./trt_checkpoints \
--dtype bfloat16 \
--tp_size 2
# 第二步：构建 TensorRT Engine
trtllm-build \
--checkpoint_dir ./trt_checkpoints \
--output_dir ./trt_engines \
--gemm_plugin bfloat16 \
--max_batch_size 64 \
--max_input_len 4096 \
--max_output_len 2048 \
--max_num_tokens 8192 \
--use_fp8_context_fmha enable
# 第三步：运行推理服务
python run.py \
--engine_dir ./trt_engines \
--tokenizer_dir deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--max_output_len 2048 \
--enable_triton_backend
DeepSeek FP8 量化推理
H100 GPU 支持原生 FP8 计算，配合 TensorRT-LLM 可实现接近无损的量化推理：
# FP8 量化转换（需要校准数据）
python quantize.py \
--model_dir deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--dtype bfloat16 \
--qformat fp8 \
--kv_cache_dtype fp8 \
--output_dir ./trt_checkpoints_fp8 \
--calib_size 512 \
--tp_size 2
# 构建 FP8 Engine
trtllm-build \
--checkpoint_dir ./trt_checkpoints_fp8 \
--output_dir ./trt_engines_fp8 \
--gemm_plugin fp8 \
--max_batch_size 128 \
--max_input_len 4096 \
--max_output_len 2048 \
--use_fp8_context_fmha enable
# FP8 推理：显存减半，吞吐量翻倍
python run.py \
--engine_dir ./trt_engines_fp8 \
--tokenizer_dir deepseek-ai/DeepSeek-R1-Distill-Llama-70B \
--max_output_len 2048
INT4 Weight-Only 量化
对于显存受限的场景，INT4 量化可将模型体积压缩 75%：
# INT4 Weight-Only 量化
python quantize.py \
--model_dir deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \
--dtype float16 \
--qformat int4_awq \
--group_size 128 \
--output_dir ./trt_checkpoints_int4 \
--calib_size 128
# 构建 INT4 Engine
trtllm-build \
--checkpoint_dir ./trt_checkpoints_int4 \
--output_dir ./trt_engines_int4 \
--gemm_plugin int4 \
--max_batch_size 64 \
--max_input_len 4096 \
--max_output_len 2048
# INT4 推理：32B 模型仅需约 16GB 显存，可在 RTX 4090 运行
TensorRT-LLM 适用场景
TensorRT-LLM 最适合纯 NVIDIA GPU 环境、追求极致推理性能的生产场景。缺点是部署流程复杂，需要模型编译步骤，灵活性不如 vLLM 和 SGLang。如果你使用 Triton Inference Server 作为推理平台，TensorRT-LLM 是首选后端。
第 4 步
llama.cpp 本地推理
llama.cpp 是一个纯 C/C++ 实现的推理引擎，专为 CPU 和边缘设备优化。通过 GGUF 量化格式，可以在普通笔记本电脑上运行 DeepSeek 蒸馏模型，无需高端 GPU。
GGUF 量化格式
GGUF（GGML Unified Format）是 llama.cpp 使用的模型文件格式，支持多种量化级别：
| 量化类型 | 位宽 | 文件大小比 | 质量 | 推荐场景 |
|---|---|---|---|---|
| Q4_K_M | ~4.5 bit | ~25% | 优秀 | 最佳性价比，推荐首选 |
| Q5_K_M | ~5.5 bit | ~30% | 极佳 | 追求更高质量 |
| Q8_0 | 8 bit | ~50% | 几乎无损 | 显存充足时使用 |
| IQ3_M | ~3.5 bit | ~20% | 良好 | 显存极度受限 |
安装 llama.cpp
# macOS（使用 Homebrew）
brew install llama.cpp
# Linux / Windows（从源码编译）
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j
# 启用 CUDA 加速
make -j GGML_CUDA=1
# 启用 Apple Metal 加速（macOS）
make -j GGML_METAL=1
# 安装 Python 绑定
pip install llama-cpp-python
# 带 CUDA 的 Python 绑定
CMAKE_ARGS="-DGGML_CUDA=on" pip install llama-cpp-python
DeepSeek 模型 GGUF 下载与部署
# 下载 GGUF 格式的 DeepSeek 蒸馏模型（以 Qwen-32B 为例）
# 从 Hugging Face 下载 Q4_K_M 量化版本
wget https://huggingface.co/unsloth/DeepSeek-R1-Distill-Qwen-32B-GGUF/resolve/main/DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf
# 命令行推理
./llama-cli \
-m DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf \
-p "请解释 MoE 混合专家架构的原理。" \
-n 512 \
-t 8 \
--temp 0.7 \
--top-p 0.9
# 启动 OpenAI 兼容 API 服务器
./llama-server \
-m DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf \
--host 0.0.0.0 \
--port 8080 \
-ngl 99 \
-c 4096 \
-t 8
Python 绑定调用
from llama_cpp import Llama
# 加载模型
llm = Llama(
model_path="./DeepSeek-R1-Distill-Qwen-32B-Q4_K_M.gguf",
n_ctx=4096, # 上下文长度
n_threads=8, # CPU 线程数
n_gpu_layers=99, # GPU 加速层数（-1 = 全部）
verbose=False,
)
# 推理
response = llm.create_chat_completion(
messages=[
{"role": "user", "content": "用 Python 写一个二分查找算法。"},
],
temperature=0.7,
max_tokens=512,
stream=True,
)
for chunk in response:
if "choices" in chunk:
delta = chunk["choices"][0].get("delta", {})
print(delta.get("content", ""), end="")
Apple Silicon (Metal) 优化
llama.cpp 对 Apple Silicon 芯片（M1/M2/M3/M4）有特殊的 Metal 优化，利用统一内存架构实现 GPU 加速：
# macOS 上编译时启用 Metal
make -j GGML_METAL=1
# 运行时指定 GPU 层数
./llama-cli \
-m DeepSeek-R1-Distill-Qwen-14B-Q4_K_M.gguf \
-p "请解释 Transformer 的 Self-Attention 机制。" \
-ngl 99 \
-c 4096 \
-n 512
# M3 Max (36GB) 可运行 Qwen-32B Q4_K_M
# M2 Ultra (64GB) 可运行 Qwen-72B Q4_K_M
个人电脑部署指南
| 硬件配置 | 推荐模型 | 量化 | 预期速度 |
|---|---|---|---|
| 16GB RAM + RTX 4060 | DeepSeek-R1-Distill-Qwen-7B | Q4_K_M | 30-50 tok/s |
| 32GB RAM + RTX 4090 | DeepSeek-R1-Distill-Qwen-32B | Q4_K_M | 20-35 tok/s |
| M3 Max 36GB | DeepSeek-R1-Distill-Qwen-32B | Q4_K_M | 15-25 tok/s |
| M2 Ultra 64GB | DeepSeek-R1-Distill-Llama-70B | Q4_K_M | 8-15 tok/s |
核心概念
推理引擎性能对比
四大推理引擎在不同场景下的性能表现差异显著。以下 Benchmark 数据基于 DeepSeek-R1-Distill-Llama-70B 模型，在 2x A100 80GB 上测试，batch size 为 64。
吞吐量对比（tokens/s）
| 引擎 | 输入 128 tok | 输入 512 tok | 输入 2048 tok | 输出 256 tok |
|---|---|---|---|---|
| vLLM (FP16) | 3,420 | 2,890 | 2,150 | 2,680 |
| SGLang (FP16) | 3,510 | 3,120 | 2,380 | 2,920 |
| TensorRT-LLM (FP8) | 5,820 | 4,950 | 3,680 | 4,580 |
| llama.cpp (Q4) | 580 | 420 | 280 | 380 |
延迟对比（TTFT，ms）
| 引擎 | 空载 TTFT | 16 并发 TTFT | 64 并发 TTFT | TPOT |
|---|---|---|---|---|
| vLLM (FP16) | 85ms | 210ms | 580ms | 32ms |
| SGLang (FP16) | 72ms | 185ms | 510ms | 28ms |
| TensorRT-LLM (FP8) | 80ms | 195ms | 530ms | 30ms |
| llama.cpp (Q4) | 1,250ms | 2,800ms | 8,500ms | 180ms |
显存占用对比（GB）
| 引擎 | 模型权重 | KV Cache | 其他开销 | 总计 |
|---|---|---|---|---|
| vLLM (FP16) | 140GB | 12GB | 4GB | 156GB |
| SGLang (FP16) | 140GB | 10GB | 4GB | 154GB |
| TensorRT-LLM (FP8) | 70GB | 6GB | 3GB | 79GB |
| llama.cpp (Q4) | 38GB | 4GB | 2GB | 44GB |
Benchmark 结论
- TensorRT-LLM FP8 在 NVIDIA GPU 上吞吐量最高，显存占用最低
- SGLang 在长上下文和多轮对话场景下延迟最低（RadixAttention 优势）
- vLLM 生态最成熟，社区最活跃，部署最简便
- llama.cpp 在 GPU 环境性能远不如前三者，但 CPU 和边缘设备体验最佳
核心概念
量化推理深入
量化是推理加速中最重要的技术之一。通过降低模型权重的数值精度，可以将显存占用降低 50%-75%，同时精度损失通常控制在 1% 以内。
量化方法对比
| 量化方法 | 位宽 | 压缩比 | 精度损失 | 支持引擎 |
|---|---|---|---|---|
| AWQ | INT4 | 4x | < 0.5% | vLLM, TensorRT-LLM, SGLang |
| GPTQ | INT4 | 4x | < 1% | vLLM, TensorRT-LLM |
| GGUF | 2-8 bit | 2-8x | < 1% (Q4+) | llama.cpp |
| FP8 | 8 bit | 2x | 几乎无损 | TensorRT-LLM (H100) |
| SmoothQuant | INT8 | 2x | < 0.5% | TensorRT-LLM |
AWQ 量化原理与使用
AWQ（Activation-aware Weight Quantization）通过分析激活值的分布，识别重要权重通道并予以保护，在不校准的情况下实现高精度 INT4 量化：
# 安装 AutoAWQ
pip install autoawq
# AWQ 量化（以 DeepSeek-R1-Distill-Qwen-32B 为例）
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "deepseek-ai/DeepSeek-R1-Distill-Qwen-32B"
quant_path = "DeepSeek-R1-Distill-Qwen-32B-AWQ"
# 加载模型
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
# 量化配置
quant_config = {
"zero_point": True,
"q_group_size": 128,
"w_bit": 4,
"version": "GEMM",
}
# 执行量化
model.quantize(tokenizer, quant_config=quant_config)
# 保存量化模型
model.save_quantized(quant_path)
tokenizer.save_pretrained(quant_path)
# 在 vLLM 中使用 AWQ 量化模型
# vllm serve ./DeepSeek-R1-Distill-Qwen-32B-AWQ --quantization awq
显存节省计算
| 模型 | FP16 显存 | FP8 显存 | INT4 显存 | 节省比 |
|---|---|---|---|---|
| DeepSeek-V3 (671B) | 1,342 GB | 671 GB | 336 GB | 75% |
| R1-Distill-Llama-70B | 140 GB | 70 GB | 35 GB | 75% |
| R1-Distill-Qwen-32B | 64 GB | 32 GB | 16 GB | 75% |
| R1-Distill-Qwen-7B | 14 GB | 7 GB | 3.5 GB | 75% |
量化精度损失分析
- FP8：精度损失几乎为零（< 0.1%），因为 FP8 使用浮点表示，动态范围大。但需要 H100/H200 等支持 FP8 的硬件
- INT8 (SmoothQuant)：精度损失 < 0.5%，通过平滑激活值中的异常值来实现。通用性好，A100/H100 均可使用
- INT4 (AWQ)：精度损失 < 0.5%，通过分析激活值分布保护重要通道。当前最推荐的 INT4 方案
- INT4 (GPTQ)：精度损失 < 1%，需要校准数据，但量化过程更稳定
- Q4_K_M (GGUF)：精度损失 < 1%，在 llama.cpp 生态中广泛使用，性价比最高
量化选型建议
有 H100 优先选 FP8（吞吐量最高）；A100 环境推荐 AWQ INT4（显存节省显著且精度高）；个人电脑用 GGUF Q4_K_M（文件小、兼容好）。减少 75% 的显存意味着可以用少得多的 GPU 部署相同模型，或者在相同硬件上服务更多并发用户。
核心概念
批处理与并发优化
批处理是推理引擎吞吐量的核心决定因素。从静态批处理到 Continuous Batching，再到 Chunked Prefill，每一次批处理技术的演进都带来了显著的性能提升。
三种批处理方式对比
| 批处理方式 | 原理 | GPU 利用率 | 适用引擎 |
|---|---|---|---|
| Static Batching | 等待固定数量请求后一起处理，等最慢的请求完成后才释放 | 低（30-50%） | HuggingFace TGI（旧版） |
| Dynamic Batching | 请求到达即加入批处理，但等所有请求完成后才释放 | 中（50-70%） | ONNX Runtime |
| Continuous Batching | 每个 token 生成后立即检查，完成的请求立即移出，新请求立即加入 | 高（80-95%） | vLLM, SGLang, TensorRT-LLM |
Continuous Batching 工作流程
- 迭代级别调度：每生成一个 token 后都重新评估批处理队列，而非等整个序列完成
- 即时替换：请求生成完成后立即从批处理中移除，GPU 资源立即分配给等待中的新请求
- 抢占式调度：支持优先级队列，高优先级请求可以抢占低优先级请求的计算资源
- 公平调度：防止长序列请求饿死短序列请求，通过轮转或加权调度保证公平性
Chunked Prefill 优化
当用户发送长 Prompt（如 100K token 文档分析）时，Prefill 阶段会占用大量计算资源，导致其他请求等待。Chunked Prefill 将长 Prompt 的 Prefill 拆分为多个小 Chunk，与 Decode 请求交错执行：
# vLLM 中启用 Chunked Prefill
vllm serve deepseek-ai/DeepSeek-V3 \
--enable-chunked-prefill \
--max-num-batched-tokens 8192 \
--tensor-parallel-size 8
# SGLang 中启用 Chunked Prefill
python -m sglang.launch_server \
--model deepseek-ai/DeepSeek-V3 \
--chunked-prefill-size 4096 \
--tp 8
并发用户数优化策略
| 策略 | 说明 | 效果 |
|---|---|---|
| max-num-seqs | 设置最大并发序列数，根据显存容量调整 | 128-256 最佳 |
| 排队策略 | FIFO（先进先出）vs Priority（优先级）vs Shortest-Job-First | SJF 平均延迟最低 |
| 请求限流 | 通过 API 网关限制并发请求数，防止过载 | 稳定性提升 |
| 超时与重试 | 设置合理的超时时间（30-60s），配合指数退避重试 | 用户体验改善 |
请求调度引擎配置
# vLLM 调度器配置示例
vllm serve deepseek-ai/DeepSeek-V3 \
--scheduler-policy priority \ # 优先级调度
--max-num-seqs 256 \ # 最大并发序列
--max-num-batched-tokens 16384 \ # 单轮最大 token 数
--max-paddings 256 \ # 最大 padding 比例
--enable-prefix-caching \ # 前缀缓存
--enable-chunked-prefill \ # 分块预填充
--max-num-on-the-fly 16 # 同时进行预填充的请求数
核心概念
分布式推理
DeepSeek-V3 拥有 671B 参数，即使使用 INT4 量化也需要 336GB 显存，远超单张 GPU 容量。分布式推理通过多卡、多节点协同，让超大模型推理成为可能。
Tensor Parallelism（张量并行）
Tensor Parallelism 将单层 Transformer 的权重矩阵沿列或行切分到多张 GPU 上，每张 GPU 计算一部分，然后通过 AllReduce 通信汇总结果：
- 列切分：将权重矩阵 W 按列切分为 [W1, W2, ..., Wn]，每张 GPU 持有 W_i，各自计算后通过 AllReduce 汇总
- 行切分：将权重矩阵按行切分，每张 GPU 计算部分输出，然后通过 AllGather 拼接
- 通信开销：每层 Transformer 需要 2 次 AllReduce，对 NVLink 带宽要求高。推荐使用 NVLink 互联的 GPU 组
- 最佳 GPU 数：通常 2-8 张 GPU，超过 8 张后通信开销开始超过计算收益
Pipeline Parallelism（流水线并行）
Pipeline Parallelism 将模型按层切分到多张 GPU 上，形成流水线。GPU0 处理前 N 层，GPU1 处理中间 N 层，GPU2 处理后 N 层：
- 按层切分：通信仅发生在流水线阶段的边界，通信量远小于 Tensor Parallelism
- Micro-Batch：将大批次拆分为多个 Micro-Batch，流水线各阶段同时处理不同 Micro-Batch
- 流水线气泡：流水线启动和排空阶段存在 GPU 空闲。通过增加 Micro-Batch 数量可减少气泡占比
- 适用场景：跨节点推理（节点间带宽有限），可与 Tensor Parallelism 组合使用
DeepSeek-V3 671B 分布式部署方案
| 方案 | GPU 配置 | 并行策略 | 预期吞吐量 |
|---|---|---|---|
| 8x H100 80GB (FP8) | 单节点 8 卡 | TP=8 | 3,500 tok/s |
| 16x A100 80GB (FP8) | 2 节点 x 8 卡 | TP=8, PP=2 | 4,800 tok/s |
| 16x A100 80GB (INT4) | 2 节点 x 8 卡 | TP=4, PP=4 | 5,200 tok/s |
| 32x H100 80GB (FP8) | 4 节点 x 8 卡 | TP=8, PP=4 | 8,500 tok/s |
vLLM 多节点部署命令
# 主节点（Node 0）
vllm serve deepseek-ai/DeepSeek-V3 \
--tensor-parallel-size 8 \
--pipeline-parallel-size 2 \
--max-model-len 8192 \
--gpu-memory-utilization 0.95 \
--distributed-executor-backend ray \
--host 0.0.0.0 \
--port 8000
# 工作节点（Node 1）
# 在 Node 1 上启动 Ray worker 并加入集群
ray start --address='NODE0_IP:6379'
# 使用 Ray 自动管理多节点 GPU 资源
# vLLM 通过 Ray 实现多节点调度，无需手动指定 GPU 分配
MoE 模型的特殊考量
DeepSeek-V3 使用 MoE（混合专家）架构，每个 token 只激活部分专家（约 37B 参数），这为推理优化提供了独特机会：
- Expert Parallelism：将不同专家分布到不同 GPU 上，每个 token 只访问部分 GPU，减少通信量
- 专家负载均衡：通过 Auxiliary Loss 或动态路由确保各专家负载均衡，避免某些 GPU 闲置
- 专家缓存：将热门专家的权重缓存到所有 GPU 的显存中，减少跨 GPU 访问
- 稀疏激活：每次推理仅激活 8 个专家（共 256 个），计算量远小于等参数量的 Dense 模型
核心概念
成本优化实践
GPU 推理成本是 AI 应用的最大开销之一。通过合理的 GPU 选型、实例策略和架构设计，可以将推理成本降低 50%-80%。
云 GPU 选型对比
| GPU | 显存 | FP8 支持 | 按需价/时 | 适合模型 |
|---|---|---|---|---|
| H100 80GB | 80 GB | 支持 | $2.50-$3.50 | V3 671B (8x), 70B (2x) |
| A100 80GB | 80 GB | 不支持 | $1.80-$2.50 | V3 671B (16x INT4), 70B (2x) |
| A100 40GB | 40 GB | 不支持 | $1.20-$1.80 | 32B 模型 (单卡), 70B (2x) |
| L40S 48GB | 48 GB | 支持 | $0.80-$1.20 | 32B 模型 (单卡 FP8) |
| RTX 4090 24GB | 24 GB | 不支持 | 自建:~$0.30 | 7B/14B 模型 |
按需 vs 预留实例对比
| 实例类型 | 折扣 | 承诺期限 | 灵活性 | 推荐场景 |
|---|---|---|---|---|
| 按需（On-Demand） | 原价 | 无 | 极高 | 开发测试、不确定负载 |
| 预留（Reserved） | 40-60% | 1-3 年 | 低 | 稳定生产环境 |
| 竞价（Spot/Preemptible） | 60-90% | 无 | 随时被回收 | 离线批处理、容错任务 |
| 混合策略 | 50-70% | 灵活 | 中 | 预留保底 + 竞价弹性 |
推理成本计算
# 推理成本计算公式
# 月成本 = GPU 时价 x 每小时 GPU 数 x 24 x 30 x 利用率
# 示例 1：部署 DeepSeek-R1-Distill-Llama-70B
# 2x A100 80GB 按需实例，日均 18 小时使用
# 月成本 = $2.00 x 2 x 24 x 30 x 0.75 = $2,160/月
# 示例 2：部署 DeepSeek-V3 671B（FP8）
# 8x H100 80GB 预留实例，24/7 运行
# 月成本 = $3.00 x 0.5 (预留折扣) x 8 x 24 x 30 x 0.90 = $7,776/月
# 示例 3：部署 DeepSeek-R1-Distill-Qwen-32B (INT4)
# 1x A100 40GB 竞价实例，24/7 运行
# 月成本 = $1.50 x 0.2 (竞价折扣) x 1 x 24 x 30 x 0.85 = $183/月
# 对比 DeepSeek 官方 API 成本
# DeepSeek API: $0.27/百万输入 token + $1.10/百万输出 token
# 日均 100 万 token 输出: 30 x $1.10 = $33/月
# 对于中低负载场景，使用 API 远比自建推理服务便宜
自建 vs 云服务对比
| 对比维度 | 自建推理服务 | DeepSeek 官方 API | 云推理服务 |
|---|---|---|---|
| 初始成本 | 高（GPU 购置/租赁） | 零 | 中 |
| 运维成本 | 高（需要专人维护） | 零 | 中 |
| 数据隐私 | 完全可控 | 数据经过第三方 | 取决于配置 |
| 高负载成本 | 边际成本低 | 线性增长 | 中等 |
| 弹性扩展 | 受限 | 无限 | 较好 |
成本优化最佳实践
- 负载分级：简单问题用 7B/14B 蒸馏模型，复杂问题路由到 70B/671B 大模型，节省 60% 成本
- 缓存策略：对热门问题缓存答案（语义缓存），命中率可达 30-50%，直接节省推理成本
- 量化降本：FP8 量化降低 50% 显存，INT4 降低 75%，同等硬件可服务更多用户
- 竞价实例：离线批处理和异步任务全部使用竞价实例，成本降低 60-90%
- 自动扩缩容：根据 QPS 自动调整 GPU 实例数，低峰期缩容到 0，节省 40-60% 成本
- 断点续传：竞价实例被回收时保存 KV Cache 状态，恢复后继续推理，避免浪费
成本优化建议
日均 token 量低于 100 万时，直接使用 DeepSeek 官方 API 最经济；日均 100 万-1000 万 token 时，自建 32B/70B 蒸馏模型推理服务性价比最高；日均超过 1000 万 token 时，部署 671B 完整模型并配合量化+竞价实例。更多部署方案请查看 DeepSeek 部署教程。
推理加速 FAQ
DeepSeek 推理加速常见问题
vLLM 和 SGLang 应该选哪个？
通用 API 服务场景选 vLLM（生态更成熟、社区更大、文档更全）；多轮对话和 Agent 场景选 SGLang（RadixAttention 前缀缓存优势明显，TTFT 降低 3-5 倍）。如果业务场景以长系统 Prompt + 多轮对话为主，SGLang 是更优选择。两者都提供 OpenAI 兼容 API，迁移成本极低。
DeepSeek-V3 671B 最少需要多少张 GPU？
FP16 精度至少需要 16 张 A100 80GB（TP=8, PP=2）或 8 张 H100 80GB（TP=8）。FP8 量化（仅 H100 支持）可在 8 张 H100 上运行。INT4 量化可在 8 张 A100 80GB 上运行（TP=8）。如果使用 AWQ INT4 量化 + Tensor Parallelism，可以在 4 张 A100 80GB 上运行，但吞吐量会显著降低。
量化后模型质量会下降多少？
FP8 量化精度损失几乎为零（< 0.1%），因为使用浮点表示动态范围大。INT8 量化（SmoothQuant）精度损失 < 0.5%。INT4 量化（AWQ）精度损失 < 0.5%，在大多数任务中几乎感知不到差异。Q4_K_M（GGUF）精度损失 < 1%。对于 DeepSeek 蒸馏模型，AWQ INT4 是非常安全的选择，推荐在生产环境中使用。
RTX 4090 能运行 DeepSeek 吗？
RTX 4090 24GB 可以运行 DeepSeek-R1 蒸馏模型：7B（Q4 量化，仅需 4GB）、14B（Q4 量化，约 9GB）、32B（Q4 量化，约 16GB + 剩余供 KV Cache）。推荐使用 llama.cpp 或 Ollama 部署，配合 GGUF Q4_K_M 量化格式。无法运行 70B 和 671B 模型。RTX 4090 的推理速度在 7B-32B 模型上表现优秀，可达 30-80 tok/s。
Continuous Batching 能提升多少吞吐量？
相比静态批处理，Continuous Batching 可将 GPU 利用率从 30-50% 提升到 80-95%，吞吐量提升 2-5 倍。在请求长度差异大的场景下（如混合了短问答和长文生成），提升效果尤为显著。vLLM、SGLang、TensorRT-LLM 均默认使用 Continuous Batching，无需额外配置。
自建推理服务还是用 DeepSeek API？
日均 token 低于 100 万时，API 月费约 $33，远低于自建 GPU 成本（至少 $1,500/月起）。日均 100 万-1000 万 token 时，自建 32B/70B 蒸馏模型（配合竞价实例）成本更优。日均超过 1000 万 token 时，自建 671B 完整模型边际成本最低。此外，数据隐私要求严格的场景必须自建。策略上建议先用 API 验证产品，稳定后逐步迁移到自建服务。
了解更多
DeepSeek 相关教程
深入学习 DeepSeek 模型的使用、部署和生态工具。