简介：这份PDF文档聚焦DeepSeek大模型本地私有化部署，面向希望保障数据安全、开展定制化开发的企业团队与个人开发者，覆盖从7B以下开发测试到32B以上生产集群的分级场景。内容围绕硬件选型、系统环境搭建、依赖配置与性能优化展开，给出CPU、GPU、内存、存储和网络的最低与推荐配置，并说明显存与参数规模的对应关系，适合需要规划算力预算、验证部署可行性的技术人员参考。资源包仅含1个PDF文件，大小约274KB，轻量便于随查随用，结构按硬件要求、操作系统与CUDA工具链、PyTorch安装、分布式训练、模型量化、显存优化及监控调优等模块组织。文档还提供Linux与Windows兼容方案、CUDA/cuDNN验证命令、4-bit量化加载示例和分级卸载参数片段，可帮助读者快速对照环境清单、少走配置弯路。目前已有2219人学习下载。

1. 显存先算账：DeepSeek 本地部署最先撞上的那道墙

有位开发者把 RTX 3090 24GB 插上主板，按「每 10 亿参数约 1.2GB 显存」这份流传很广的口径一算，7B 模型只要 8.4GB，觉得闭着眼都能跑。结果第一次加载就吃了个 CUDA out of memory，排查半天才发现是默认全精度加载、没指定 device_map，KV cache 还按默认长度全量预留。DeepSeek 本地部署这件事，硬件清单只是入场券，真正决定能不能跑起来的是版本配对与加载参数。这篇安装笔记按「配什么机器 → 装什么系统 → 装什么 CUDA 和框架 → 显存不够怎么救 → 翻车怎么查」的顺序走一遍，适合手上有单卡开发机、也有几台机器想拼小集群的人。

2. 硬件选型对号入座：7B 开发机与 32B 生产集群的两套配置

装环境之前先把机器定下来，后面所有版本选择都是围绕这张卡展开的。同一份安装脚本，在 1660 和 A100 上会得到完全不同的结果，原因不在脚本，而在算力档位和显存容量。硬件先分两档看：7B 以下的开发测试环境，和 32B 以上的生产部署环境。这两档的差别不只是显卡数量，连操作系统、驱动、网络拓扑的选法都不一样。

2.1 每 10 亿参数 1.2GB 是权重下限，不是能跑起来的标准

那份配置文档里给的经验值是「GPU 显存需至少容纳模型参数：每 10 亿参数约需 1.2GB 显存（FP16 精度）」。这句话要拆成两半读：前半句说的是权重本身，后半句说的是 FP16 精度。它算的是「模型能不能被装进去」，不是「服务能不能稳定跑起来」。真正占显存的是三块：权重、KV cache、以及 CUDA context 和框架自身的运行时开销。其中 KV cache 随并发数和上下文长度线性增长，这才是生产环境翻车的主因。

我一般用这个粗算公式估显存，别精确到小数，够判断档位就行：

总显存 ≈ 权重 + KV cache + 运行时开销 权重 = 参数量 × 每参数字节数 # FP16 约 2B/参数，4-bit 约 0.5B/参数 KV cache = 2 × 层数 × 隐藏维度 × 序列长度 × 并发数 × 每元素字节数 运行时开销 = 1.5GB ~ 3GB # CUDA context + 框架 + 碎片余量

按这个口径，7B 模型在 FP16 下权重约 14GB 量级，配 4096 序列长度、8 路并发，KV cache 还要再吃掉几 GB，24GB 卡是能跑但不宽裕的位置；32B 模型单卡根本不要想，必须多卡切分，这就是文档把 32B 以上单独划成生产级的原因。4-bit 量化能把权重压到四分之一左右，7B 在 12GB 卡上就有了活动空间，代价是精度损失和首次加载变慢，后面第 4 章会给出具体配置。

提示：估显存时给运行时留 1.5GB 以上的余量。碎片化在长时间运行后很致命，压线跑的服务往往在几个小时后的某个长请求上崩掉。

2.2 两档配置的对照与取舍

文档给的两档配置我原样搬过来，再补上我实际会怎么看这几列。

开发测试档最容易做错的选择是显卡。1660 6GB 只能跑到量化后的小模型，勉强验证 API 接口通不通；想真正测 7B 的完整流程，3090 24GB 是这条线上的分水岭，再往下压就只能靠 CPU 或者 4-bit 硬撑。CPU 这一列不用太纠结，推理阶段 CPU 只负责调度和 tokenize，258 线程的 EPYC 也不是为了让模型跑得快，而是为了喂得饱 8 张卡。

生产档里 NVLink 是硬要求，不是锦上添花。4 张 A100 走 PCIe 交换时，张量并行的 all-reduce 会把带宽吃满，文档标的「推理延迟 <200ms（输入长度 512 tokens）」和「吞吐 >1000 requests/sec」这两个指标，在 PCIe 拓扑上很难同时拿到。内存那 512GB 也不是摆设，分级卸载到 CPU 内存时，它就是第二级显存池。

2.3 存储与网络：预算表里最先被砍、最先出事的两项

NVMe 这条线我吃过亏。模型权重加载是典型的大块顺序读，SATA SSD 和 NVMe 在冷启动上能差出几十秒；更要紧的是开了offload_param_device="nvme"之后，NVMe 会变成参数换入换出的活动区，这时候盘的速度就直接决定了推理延迟。开发机上一块 1TB NVMe 分两个区，一个装系统一个放模型，是最省事的做法；生产节点用 RAID 0 组 8TB，是为了吞吐不是为了冗余，模型仓库另有备份。

网络这块分两个层面看。节点间通信用万兆起步，多卡多机的梯度同步和请求分发都走这条线，千兆在 32B 场景下会直接成为瓶颈。存储网络单独走 NAS，把模型仓库和日志从计算网络里摘出去，避免大文件读写和推理流量互相踩。至于 InfiniBand HDR 200Gb，那是给 4 节点以上的集群准备的，两三台机器的实验环境用万兆足够，别一上来就堆最贵的方案。

最后提醒一个容易被忽略的点：主板 PCIe 通道数。四张 A100 塞进消费级主板，通道会被拆成 x4 x4 x4 x4，带宽直接腰斩，配置单上看着一样的卡，跑出来的吞吐能差一倍。选服务器平台（EPYC 那套）很大程度就是为了 PCIe 4.0 的通道数。

3. 系统底座与 CUDA 12.1：Ubuntu 22.04、WSL2 和驱动的安装顺序

机器到位之后，接下来的顺序不能乱：操作系统 → 内核模块 → 显卡驱动 → CUDA Toolkit → cuDNN。任何一步跳到前面，后面都会以「明明装了却用不上」的形式还回来。这一章全部围绕 Linux 主线讲，Windows 用 WSL2 的走法单独说清楚。

3.1 操作系统准备与那一行 swappiness

文档推荐 Ubuntu 22.04 LTS，我认同这个选择，原因是它对 CUDA 12.x 的内核模块支持最省心。装完系统第一件事不是装驱动，而是补齐内核扩展模块并调整内存策略：

# 补装与当前内核匹配的额外模块，CUDA 内核模块依赖它 sudo apt install -y linux-modules-extra-$(uname -r) # 降低交换倾向，避免推理进程被换出到磁盘 echo "vm.swappiness=10" >> /etc/sysctl.conf sudo sysctl -p # 建专用部署目录 sudo mkdir -p /opt/deepseek sudo chown -R "$USER":"$USER" /opt/deepseek

第一行里的$(uname -r)是当前运行内核的版本号，必须匹配，不能写死。第二行vm.swappiness=10是把内核换页的倾向从默认 60 压到 10，大模型推理进程常驻内存几十 GB，一旦被换出到 swap，延迟会从毫秒级跳到秒级，而且这种抖动很难从日志里看出来，属于典型的黑匣子问题。最后一行文档里写的是chmod 777，我在自己机器上改成了chown给当前用户，777 意味着任何本地账户都能改模型文件，生产环境不该这么留口子。

Windows 那边走 WSL2 方案，版本要求是 Windows 11 Pro 22H2 及以上，必装组件包括 WSL2 里的 Ubuntu 20.04 LTS、DirectX 12 Ultimate 运行时、以及 535.54.03 以上的 NVIDIA 驱动。这里有个高频翻车点：驱动只装在 Windows 宿主机上，WSL2 内部不要再装一遍 Linux 驱动，装了会把宿主透传进来的驱动顶掉，表现就是nvidia-smi能跑但 CUDA 程序报找不到设备。

3.2 CUDA 12.1 的静默安装与参数取舍

驱动就绪之后装 CUDA Toolkit。文档给的 12.1 版本和后面 PyTorch 的 cu121 wheel 是配套的，不要自作主张升到 12.4 再回头找对应 torch，那是给自己找麻烦：

# 下载 CUDA 12.1 本地安装包 wget https://developer.download.nvidia.com/compute/cuda/12.1.0/local_installers/cuda_12.1.0_530.30.02_linux.run # 静默安装，只装工具链和示例，不覆盖已有驱动 sudo sh cuda_12.1.0_530.30.02_linux.run --override --toolkit --samples --silent

--override是跳过编译器版本和系统版本的兼容性检查，在比较新的发行版上必须加，否则安装器会以「不支持的发行版」退出。--toolkit只装编译器、库和头文件，是最小集合；--samples带上示例，用来做后续的deviceQuery验证。--silent表示无交互，适合写进自动化脚本；代价是装错了不会中途提示，所以装完必须手动验证。注意这里没有传--driver，意思是保留系统里已有的驱动不动，驱动和 Toolkit 分开升级是运维上更稳的做法。

装完把路径写进环境变量，别依赖安装器自动改的 profile：

# 写入 ~/.bashrc，避免每次开新终端都要 source export PATH=/usr/local/cuda-12.1/bin${PATH:+:${PATH}} export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

用带版本号的绝对路径/usr/local/cuda-12.1而不是软链/usr/local/cuda。机器上装多个 CUDA 版本时，软链会跟着最后一次安装漂移，导致「昨天还能跑今天报错」这种玄学现象。

3.3 cuDNN 配置与一次真正的验证

cuDNN 不在这条安装命令里，要单独放进来。文档没给安装步骤，常见做法是从压缩包解压后把库和头文件铺到 CUDA 目录下：

# 解压 cuDNN 并把库文件放到 CUDA 12.1 目录 tar -xvf cudnn-linux-x86_64-8.9.x_cuda12-archive.tar.xz sudo cp cudnn-*-archive/include/cudnn*.h /usr/local/cuda-12.1/include/ sudo cp -P cudnn-*-archive/lib/libcudnn* /usr/local/cuda-12.1/lib64/ sudo chmod a+r /usr/local/cuda-12.1/include/cudnn*.h /usr/local/cuda-12.1/lib64/libcudnn*

-P参数保留符号链接，少了它 cuDNN 的 so 版本链会断，加载时报libcudnn.so.8: cannot open shared object file。chmod a+r是让非 root 用户也能读到这些库，容器里跑推理时经常卡在这一步。

验证分两层，先看驱动层再看框架层：

import torch print(torch.cuda.is_available()) # 应输出 True print(torch.backends.cudnn.version()) # 应 >= 8902 print(torch.version.cuda) # 应显示 12.1

三行输出对应三件事：第一行确认 PyTorch 能拿到设备，第二行确认 cuDNN 版本达到文档要求的 8902 以上，第三行确认 torch 编译时链接的 CUDA 版本与系统里装的一致。三行里任何一行不对，都不要往下走，先解决它。最常见的错误是第三行显示11.8或者None，那说明装的是 CPU 版或者旧版 wheel，第 5 章会讲怎么救。

4. 框架与显存配置：PyTorch 2.1.0+cu121、flash-attn 2.3.3 与 4-bit 量化

到这一层，硬件和系统都定了，剩下全是版本配对的问题。这一章的四个小节按依赖顺序走：先装对 torch，再编译加速库，然后配量化，最后配多卡和卸载。每一步装错了，下一步都会以更难懂的方式报错。

4.1 wheel 后缀必须锁 cu121，别用 extra-index-url 赌运气

文档给的安装命令是这样的：

# 安装与 CUDA 12.1 匹配的 PyTorch 2.1.0 pip install torch==2.1.0+cu121 --extra-index-url https://download.pytorch.org/whl/cu121

版本号里的+cu121是本地版本标识，表示这个 wheel 是针对 CUDA 12.1 编译的。--extra-index-url的意思是「除了默认 PyPI，再去这个源找」，它的问题是 pip 会在两个源之间做版本仲裁，如果 PyPI 上有同名同版本的包，可能会优先拿到 CPU 版。我在自己的机器上会把它换成强制的--index-url，只认这一个源，不给仲裁留空间：

# 强制只从 cu121 源解析，避免回退到 PyPI 的 CPU 版本 pip install torch==2.1.0+cu121 --index-url https://download.pytorch.org/whl/cu121

装完立刻用 3.3 节那三行验证。如果torch.cuda.is_available()返回 False 而nvidia-smi正常，九成是这里装成了 CPU 版，重装即可，不要急着去动驱动。

4.2 flash-attn 编译：MAX_JOBS 和 TORCH_CUDA_ARCH_LIST 怎么填

flash-attn 2.3.3 是源码编译安装，编译期就把 CUDA 架构固定进去了：

# 编译安装 FlashAttention-2，限制并行任务数防止内存打爆 MAX_JOBS=4 TORCH_CUDA_ARCH_LIST="8.0" pip install flash-attn==2.3.3

MAX_JOBS=4控制并行编译的任务数，每个编译进程都要吃内存，核多内存小的机器不限制会直接把系统 OOM 掉，编译到一半被内核杀掉。TORCH_CUDA_ARCH_LIST="8.0"指定只编译算力 8.0 的 kernel，对应 A100。这里是最容易抄错的地方：文档是对着 A100 写的，如果你手上是 3090，算力是 8.6，写 8.0 编出来的库在这张卡上跑不起来或者退回慢路径；4090 是 8.9。混用机器时我一般写成TORCH_CUDA_ARCH_LIST="8.0;8.6;8.9"，编译时间变长，但换机器不用重编。编译时间通常在十几分钟到半小时之间，卡在 5 分钟没动静不一定是挂了，先看 CPU 占用。

注意：编译 flash-attn 需要 nvcc 在 PATH 里，并且版本与 torch 的 cu121 一致。装完 CUDA 后新开的终端才会带上第 3.2 节写的环境变量，旧终端里编译会报找不到 nvcc。

4.3 4-bit 量化：四个参数决定省多少显存、掉多少精度

显存不够时的第一手段是量化。文档给的 4-bit 配置片段值得逐项看：

import torch from transformers import BitsAndBytesConfig, AutoModelForCausalLM bnb_config = BitsAndBytesConfig( load_in_4bit=True, # 权重压到 4bit，显存约为 FP16 的四分之一 bnb_4bit_use_double_quant=True, # 二次量化，再省约 0.4bit/参数 bnb_4bit_quant_type="nf4", # 正态分布量化，比 fp4 更适合权重分布 bnb_4bit_compute_dtype=torch.bfloat16 # 计算时升到 bf16，保证数值稳定 ) model = AutoModelForCausalLM.from_pretrained( "deepseek-ai/deepseek-32b", quantization_config=bnb_config, device_map="auto" # 自动把各层分配到可用设备 )

load_in_4bit是总开关，打开后权重以 4bit 存储，前向计算时按bnb_4bit_compute_dtype临时升精度。bnb_4bit_quant_type="nf4"用正态分布的分位点做量化，对权重这种近似正态分布的张量比均匀量化误差小。bnb_4bit_use_double_quant对量化常数再做一次量化，收益不大但白拿。device_map="auto"是让 accelerate 自己算每层放哪，多卡时会自动切分，单卡时全放在 0 号卡上。这四项里最容易漏的是compute_dtype，不写会退回 fp32 计算，显存省了但速度掉得厉害。

量化之后要接受一个事实：32B 模型即使压到 4bit，权重也在 16GB 上下，加上 KV cache 和运行时，24GB 卡跑起来依然紧。真要在这张卡上跑生产，还得配合下一节的卸载。

4.4 分布式与分级卸载：nccl 配置和 accelerate 启动参数

多卡时先确认通信后端。文档给的配置片段是：

# deepseek.yaml 配置片段 distributed: backend: nccl # NVIDIA GPU 间通信后端 init_method: tcp://192.168.1.100:23456 # 主节点地址与端口，所有进程要能访问 world_size: 4 # 参与训练/推理的总进程数 rank: 0 # 当前进程编号，从 0 开始

backend: nccl是 NVIDIA 卡唯一合理的选择，gloo 在 GPU 上会慢一个数量级。init_method里的地址必须是所有节点都能连上的地址，写127.0.0.1在多机场景下必然卡死。world_size要和实际起的进程数严格相等，多一个少一个都会在同步点上无限等待，而且不报错。rank每个进程不同，从 0 到world_size - 1一一对应，靠脚本按节点和卡号算出来。

显存仍然不够时的最后一招是分级卸载，文档给的是 accelerate 启动方式：

accelerate launch --config_file accelerate_config.yaml \ --num_processes 4 \ --mixed_precision bf16 \ --gradient_accumulation_steps 8 \ --offload_param_device="nvme" \ --offload_optimizer_device="cpu"

--num_processes 4要和 yaml 里的world_size一致。--mixed_precision bf16让前向和后向用 bf16，A100 和 30 系之后的卡都支持，比 fp16 少了梯度溢出的问题。--gradient_accumulation_steps 8是用 8 次小 batch 累积出等效大 batch，显存换吞吐的经典做法。--offload_param_device="nvme"把暂时不用的参数换到 NVMe，--offload_optimizer_device="cpu"把优化器状态放到内存，这两项是推理和微调场景下压显存的最后手段，代价是延迟明显上升，只适合离线任务，不要用在实时服务上。

5. 常见问题排查：五条从 CUDA OOM 到延迟翻倍的踩坑记录

前面四章都是顺利路径，这一章全是翻车现场。下面五条是我自己或身边人真实撞过的，按「现象 → 原因 → 解决」记，顺序大致对应安装的先后。

第一条：加载时报 CUDA out of memory，但nvidia-smi显示显存几乎没占。

现象是模型加载到一半抛 OOM，退出后看显卡显存是空的。原因通常有两个：一是没设device_map，transformers 默认先把整个模型加载到 CPU 再搬 GPU，峰值显存是权重的两倍；二是显存碎片，之前跑过别的进程留下碎片，空闲显存看着够但拼不出连续块。解决是先加device_map="auto"，让框架按层分配、边加载边搬运；碎片问题则重启进程，或者设置PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True缓解。如果两者都做了还 OOM，那就是 2.1 节算账时漏了 KV cache，去调小max_length或并发数。

第二条：torch.cuda.is_available()返回 False，但nvidia-smi一切正常。

这是最高频的一条。原因八成是装 torch 时被 PyPI 上的 CPU 版覆盖了，用 4.1 节的强制--index-url重装即可。剩下两成是驱动版本低于 CUDA 12.1 的要求，或者 WSL2 里又装了一遍 Linux 驱动把透传的顶掉了。判断方法很直接：python -c "import torch; print(torch.version.cuda)"，输出None就是 CPU 版，输出11.8之类就是装错了 wheel 版本。

第三条：flash-attn 编译几十分钟后失败，报Killed或者编译出的库加载时报 undefined symbol。

Killed是编译并行度太高把内存吃爆，把MAX_JOBS从 4 降到 2 甚至 1 就行。undefined symbol基本是TORCH_CUDA_ARCH_LIST与实际显卡算力不匹配，编出来的 kernel 里没有这张卡的代码，按 4.2 节改成对应的算力值重编。还有一种情况是 torch 版本变了但 flash-attn 没重装，两者的 ABI 对不上，重装 flash-attn 即可。

第四条：多卡启动后卡住不动，日志停在init_process_group没有任何输出。

原因是通信没建立起来，先查三处：init_method里的地址所有节点能否 ping 通，端口是否被防火墙拦了；world_size和--num_processes是否相等；rank是否有重复或者跳号。这三点里任何一点不对，进程都会在同步点上静默等待，不会超时报错，看起来就像卡死。我一般会先用两台机器跑一个最小 demo 打通 nccl，再上模型，省得在一堆变量里猜。

第五条：单条请求延迟从 200ms 涨到 1 秒以上，GPU 利用率却不高。

这时候 GPU 不是瓶颈，去看三个地方：一是 swap 有没有被用起来，free -h看 si/so 是否非零，是的话就是 swappiness 没调或者内存不够，回到 3.1 节；二是 KV cache 有没有无限增长，服务化时没设max_length上限，长对话会把 cache 撑爆并触发反复换页；三是模型是不是被卸载到了 CPU 或 NVMe，4.4 节的卸载参数在实时服务上是毒药，确认启动命令里没有带--offload_param_device。延迟类问题不要靠猜，第 6 章的 Profiler 就是干这个用的。

6. 验收怎么跑：从 CPU 兜底到四卡集群的三级验证

装完之后别急着上业务，按三级递进验证，每级通过再进下一级，出问题时能立刻定位到是哪一层。这是那份文档结语里提到的「渐进式验证」，我在每台新机器上都强制走一遍。

第一级，CPU 模式验证功能链路。不碰 GPU，把模型权重加载到内存，跑一条短输入看输出是否正常。这一步验证的是模型文件完整性和 tokenizer 配置，跟显卡无关。如果这一步就失败，问题在权重下载和依赖版本，别去查 CUDA。

第二级，单卡完整流程。device_map指向单张卡，跑一次带量化的推理，同时盯显存水位：

# 另开一个终端，每 0.5 秒采样一次显存占用 nvidia-smi --query-gpu=memory.used,memory.total,utilization.gpu \ --format=csv -l 0.5

看两个数：加载完成后的稳定占用，和单次请求的峰值占用。两者之差就是 KV cache 加激活值的开销，这个值决定了你能开多少并发。稳定占用逼近总量时，别急着上服务，先回到第 4 章做量化或缩短上下文。

第三级，多卡与服务化。起 4 进程跑一次批量推理，用 DCGM 把指标接出来看，比nvidia-smi直观得多：

# 启动 DCGM 导出器，暴露 Prometheus 格式指标 docker run -d --gpus all --rm -p 9400:9400 \ nvcr.io/nvidia/cloud-native/dcgm:3.3.1-1-ubuntu22.04

--gpus all让容器能看到所有卡，-p 9400:9400把指标端口映射出来，Prometheus 那边加一条job_name: 'dcgm'、targets: ['localhost:9400']就能采集。重点看DCGM_FI_DEV_FB_USED的曲线，四卡是否均衡、有没有某张卡先满，一眼就能看出来。

单次请求耗时拆解用 PyTorch Profiler，别用秒表掐：

import torch with torch.profiler.profile( activities=[torch.profiler.ProfilerActivity.CUDA], schedule=torch.profiler.schedule(wait=1, warmup=1, active=3), on_trace_ready=torch.profiler.tensorboard_trace_handler("./log"), record_shapes=True ) as prof: for step in range(10): model(input_ids) prof.step()

wait=1先跳过 1 步让 CUDA 预热，warmup=1再空跑 1 步避开首次编译，active=3采 3 步的真实数据，这套 schedule 是为了不被冷启动的假数据带偏。产物丢到./log，用 TensorBoard 打开就能看到每个 kernel 的耗时占比，是卡在 attention 还是卡在数据搬运，一目了然。

三级都过之后，把这一整套命令固化成脚本，新机器上直接跑。从那以后我每次装新环境，都会先跑一遍 CPU 兜底再碰显卡，因为最贵的时间不是装驱动，是在一个装错的 wheel 上排查半天。希望这套顺序能帮你少走一遍弯路。

本文还有配套的精品资源，点击获取