简介这份PDF文档聚焦DeepSeek大模型的本地化部署面向希望私有化运行开源模型的企业开发者、运维人员及具备一定Linux与深度学习基础的个人研究者帮助其在数据安全、定制化需求和算力规划之间建立可落地的配置方案。包内仅含1个PDF文件压缩包约274KB篇幅集中、便于随查随用内容从不同参数规模对应的硬件选型切入延伸至操作系统准备、CUDA与cuDNN加速环境、PyTorch定制安装及分布式训练配置。文档还专门讨论了4-bit量化加载、显存分级卸载、FlashAttention-2启用以及DCGM监控和PyTorch Profiler性能分析等实践要点并给出基础开发测试与生产级集群的分级建议可当作部署前的选型清单和排错参考。已有2219人学习适合需要快速厘清DeepSeek本地部署门槛、对照硬件配置与关键环境参数的读者查阅。1. 硬件先算账一次显存估错的 DeepSeek 本地部署DeepSeek 本地部署最常见的翻车不是模型权重下载不下来而是机器到位、环境配好、from_pretrained一跑屏幕上只有一行CUDA out of memory。我见过最典型的一次是有人按“7B 模型 8GB 显存够用”的直觉买了张 8GB 卡结果 FP16 权重本身就吃掉 8.4GB连加载都过不去。显存账算错后面 CUDA、PyTorch、量化配得再漂亮都是白搭。这篇笔记按“先算硬件 → 再铺系统 → 装计算加速 → 压显存 → 排错 → 验收”的顺序走一遍适合想在自己机器或小集群上跑私有化推理的开发者和运维从 7B 单卡测试到 32B 多卡生产都能对上号。2. 硬件与系统底座7B 单卡和 32B 集群两套配置怎么落地装机之前先别急着下单把参数规模、精度、并发三个数摆在一起配置表自然就出来了。这一章先给显存倒推的算法和两档配置再落到 Ubuntu 22.04 LTS 与 Windows 11 WSL2 两条系统路线的初始化动作。系统装错后面 CUDA 装十遍也白装。2.1 显存倒推公式与两档硬件配置表推理场景下有个粗算口径FP16 精度每 10 亿参数约需 1.2GB 显存这是权重本身的占位。7B 模型约 8.4GB32B 模型约 38.4GB。但权重只是底座真正把显存吃穿的是 KV Cache 和中间激活——上下文长度翻倍KV Cache 线性涨并发路数翻倍它再涨一次。所以我一般会在权重基础上留 1.5 到 2 倍余量再决定买什么卡。内存则按显存的 2 倍以上配用来缓存中间计算数据和做卸载缓冲这一条在开了 CPU 卸载之后尤其关键。组件基础开发测试7B 以下生产级部署32B 以上CPUi7 10 代 / Ryzen 5 5600X2×EPYC 776364 核 128 线程GPUGTX 1660 6GB最低/ RTX 3090 24GB推荐4×A100 80GBNVLink 互联内存16GB DDR4 / 32GB DDR4 ECC512GB DDR4 ECC存储512GB NVMe / 1TB NVMe 4TB HDD8TB NVMe RAID 0 100TB NAS网络千兆以太网 / 万兆光纤网卡InfiniBand HDR 200Gb这张表里有两处容易被忽略。第一处是推荐的 24GB 卡并不是为了跑满 7B 的 FP16而是为了留出上下文空间和跑 4-bit 量化后的 32B 模型做验证第二处是生产档的 NVMe 用了 RAID 0图的是模型加载和 checkpoint 写入的吞吐代价是没有冗余权重文件必须另存一份到 NAS。生产档的验收指标按输入长度 512 tokens 算推理延迟要压到 200ms 以内批量优化后吞吐上到 1000 requests/sec这两个数不是买完机器就自动有的得靠后面几章的配置去逼近。2.2 Ubuntu 22.04 LTS 初始化的三条命令Linux 是主路线版本直接锁 Ubuntu 22.04 LTS内核 5.15 以上对 CUDA 12.1 的兼容最省心。系统装完先做三件事补齐内核额外模块、压低交换分区使用、划出专用部署目录。# 补齐 CUDA 依赖的内核模块缺了会报 nvidia-uvm 加载失败 sudo apt update sudo apt install -y linux-modules-extra-$(uname -r) # 压低交换倾向避免推理时热数据被换出到磁盘 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 专用部署目录用 chown 交给当前用户不要图省事开 777 sudo mkdir -p /opt/deepseek sudo chown -R $USER:$USER /opt/deepseeklinux-modules-extra-$(uname -r)里的$(uname -r)会自动展开成当前内核版本装完不需要重启就能让nvidia-uvm之类模块可用。vm.swappiness10的含义是把换页倾向从默认 60 压到 10只在内存真正吃紧时才动交换分区——大模型推理一旦发生换页延迟会从毫秒级跳到秒级这是玄学延迟的常见来源。目录权限我没有沿用原文里的chmod 777多用户机器上 777 意味着谁都能改模型权重常见做法是用chown把属主给部署账号需要多人协作再加组权限。另外装驱动前建议顺手屏蔽开源的 nouveau 驱动不然安装器会提示需要先禁用。2.3 Windows 11 22H2 WSL2 的必装组件本地验证、单机试跑的场景里Windows 路线完全可行但组件版本要对齐系统 Windows 11 Pro 22H2 及以上WSL2 里装 Ubuntu 20.04 LTS显卡驱动 535.54.03 以上并且确保 DirectX 12 Ultimate 运行时就位。# 在 Windows 侧执行启用 WSL2 并指定发行版 wsl --install -d Ubuntu-20.04 wsl --update # 进入 WSL 后验证 GPU 透传是否生效 nvidia-smiwsl --update别跳过旧版 WSL 内核对新驱动透传支持不完整会出现 WSL 里nvidia-smi提示找不到设备。这里有个反直觉的坑WSL2 里的 GPU 是 Windows 驱动直接透传的不要在 WSL 内再装一遍 Linux 版显卡驱动装了反而会把/usr/lib/wsl/lib下的库覆盖掉导致 CUDA 初始化失败。WSL 路线也有硬限制显存上限受 Windows 侧驱动和 WDDM 管理长上下文跑起来比裸机更容易 OOM真上生产还是回 Ubuntu。2.4 部署目录与存储分层目录规划花十分钟后面能省几小时。我习惯的分法是/opt/deepseek/models放权重/opt/deepseek/env放虚拟环境/opt/deepseek/logs放 profiling 和运行日志/opt/deepseek/cache放 Hugging Face 缓存。权重的读取是随机大块 IO必须落在 NVMe 上日志和数据集可以走 NAS模型仓库和生产镜像放私有 Harbor 这类内网仓库里别每次重拉。# 把下载缓存重定向到大盘避免默认落进根分区 export HF_HOME/opt/deepseek/cache mkdir -p $HF_HOME df -h /opt/deepseek # 确认剩余空间大于权重体积的 2 倍HF_HOME这一条是血泪经验32B 的权重加上分片和临时文件轻松吃掉几十 GB默认路径在~/.cache而很多机器的根分区只给了 50GB下到 90% 就写失败报错还跟权限长得很像。用df -h先确认目标分区余量比事后删缓存省事。3. 计算加速环境CUDA 12.1 cuDNN PyTorch 2.1.0 的版本对齐这一章是整套环境里最容易出玄学的地方问题几乎都能归到一句话版本没对齐。CUDA 12.1、cuDNN 8.9 以上、PyTorch 2.1.0cu121、FlashAttention-2 2.3.3这四个组件的版本是一条链断一环就是undefined symbol或者静默回落到 CPU。3.1 CUDA 12.1 静默安装与工具链验证安装器用 runfile 方式参数决定装了什么、跳过了什么。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跳过编译器版本和系统版本的兼容性检查Ubuntu 22.04 加新内核时基本都要带。--toolkit只装工具链不装随包的驱动。驱动交给系统包管理统一维护否则容易出现内核升级后驱动失配。--samples装示例程序后面验证要用deviceQuery。--silent无交互安装适合脚本化。装完配环境变量写进~/.bashrc而不是只在当前 shell 里 export不然换个终端就找不到nvccexport PATH/usr/local/cuda-12.1/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH nvcc -V # 应输出 release 12.1 /usr/local/cuda-12.1/samples/1_Utilities/deviceQuery/deviceQuery # 末尾应是 Result PASSLD_LIBRARY_PATH里指向lib64的顺序有讲究如果系统里还留着旧版 CUDA一定要让 12.1 排在前面否则运行时加载到旧版libcudart表现为编译通过、运行报错。deviceQuery显示 PASS 只代表驱动和工具链握手成功不代表 PyTorch 能用下一步还得单独验。3.2 PyTorch 2.1.0cu121 与 cuDNN 版本校验PyTorch 必须装 cu121 的轮子不能用默认源。# 指定 cu121 索引避免默认源给到 CPU 版或 cu118 版 pip install torch2.1.0cu121 --extra-index-url https://download.pytorch.org/whl/cu121装完跑一段校验三行输出缺一不可import torch print(torch.cuda.is_available()) # 必须 TrueFalse 说明装成了 CPU 版 print(torch.version.cuda) # 应输出 12.1和系统 CUDA 对齐 print(torch.backends.cudnn.version()) # 应 8902torch.cuda.is_available()返回 False 时先看pip list | grep torch里版本号带不带cu121后缀。不带就是索引没生效常见原因是公司内网镜像覆盖了--extra-index-url或者pip被PIP_INDEX_URL环境变量锁死。torch.version.cuda输出 11.8 则说明装的是 cu118 轮子运行时和系统 CUDA 12.1 混用表现为某些算子报no kernel image is available。cuDNN 版本低于 8902 时FlashAttention 的编译会直接失败这个数要盯住。3.3 FlashAttention-2 的编译参数取舍FlashAttention-2 装的是源码包本地编译两个环境变量决定成败。# 8.0 对应 A1003090 用 8.64090/L40 用 8.9 MAX_JOBS4 TORCH_CUDA_ARCH_LIST8.0 pip install flash-attn2.3.3TORCH_CUDA_ARCH_LIST填的是目标显卡的计算能力代号填错不会报错只会在运行时报“不支持当前设备”或者悄悄走回退实现速度掉一半还查不出原因。MAX_JOBS4控制并行编译的进程数默认会按 CPU 核数拉满64 核机器上一次起 64 个编译器内存瞬间打满然后 OOM——这是我在 512GB 内存的机器上都被打死过一次的场景。编译时间通常半小时到一小时半机器越新越慢别以为卡住了就 CtrlC。顺带说一个取舍如果只用推理、不做训练也可以用预编译轮子省掉编译时间代价是对新卡的支持滞后需要极致吞吐、要开 FlashAttention-2 的还是老老实实本地编译。3.4 多卡 NCCL 配置与 deepseek.yaml 写法单卡跑通之后上多卡通信后端固定用 NCCL。配置文件里几个字段必须和物理机对得上# deepseek.yaml 分布式片段 distributed: backend: nccl # GPU 间通信后端不要用 gloo init_method: tcp://192.168.1.100:23456 # 主节点地址与端口各节点要能互通 world_size: 4 # 总进程数等于所有节点的 GPU 总数 rank: 0 # 当前节点编号从 0 开始且不能重复world_size写大了进程会一直等一个永远不存在的伙伴表现为启动后卡住不报错写小了则有一张卡闲在那里。rank重复的典型现象是init_method端口被占第二个进程起不来。init_method用的 IP 必须是各节点都能访问的内网地址容器里跑还要确认端口没被网络策略挡住。多机场景下再补一个NCCL_SOCKET_IFNAME指定网卡不然 NCCL 可能挑到管理网卡上跨机带宽从 200Gb 掉到千兆训练一轮能等到怀疑人生。4. 显存压下来4-bit 量化与分级卸载的配置写法硬件定了没法改显存就得靠软件挤。这一章的两套手段——4-bit 量化和分级卸载——解决的是不同问题量化是压权重本身的体积卸载是把放不下的部分挪到内存和 NVMe 上。两个一起上24GB 卡跑 32B 模型才有戏。4.1 BitsAndBytesConfig 四个参数的取舍量化配置里四个参数每一个都影响精度或速度不能照抄了事。import torch from transformers import BitsAndBytesConfig, AutoModelForCausalLM bnb_config BitsAndBytesConfig( load_in_4bitTrue, # 权重按 4bit 加载体积约为 FP16 的四分之一 bnb_4bit_use_double_quantTrue, # 二次量化再省约 0.4bit/参数几乎不掉点 bnb_4bit_quant_typenf4, # 正态分布量化比 fp4 更适合权重分布 bnb_4bit_compute_dtypetorch.bfloat16, # 计算时上采样到 bf16兼顾精度和速度 ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-32b, quantization_configbnb_config, device_mapauto, # 自动把层分配到可用设备 )bnb_4bit_quant_type选nf4而不是fp4是因为预训练权重大致服从正态分布nf4 的分位点按正态分布切同等比特下误差更小。bnb_4bit_compute_dtype在 A100 及以上的卡上选bfloat16数值范围比 fp16 大量化反量化过程不容易溢出老卡不支持 bf16 就退回float16。device_mapauto会自动计算每层放哪配多卡时建议换成显式映射避免它把 embedding 层丢到 CPU 上导致首 token 延迟暴涨。量化不是免费的4-bit 相比 FP16 通常有几个点的效果波动客服问答这类任务问题不大要求严格的场景建议做一轮对照评测再上线。4.2 accelerate 分级卸载的参数与启动命令权重压到 4-bit 还放不下就上卸载把参数和优化器状态分别丢到 NVMe 和 CPU 内存计算时再换进来。accelerate launch --config_file accelerate_config.yaml \ --num_processes 4 \ --mixed_precision bf16 \ --gradient_accumulation_steps 8 \ --offload_param_devicenvme \ --offload_optimizer_devicecpu \ run_inference.py--num_processes 4要等于可用 GPU 数不等于world_size时行为不可预期。--mixed_precision bf16让前向反向用 bf16显存再省一截前提是卡支持。--gradient_accumulation_steps 8用累积步数换小 batch推理场景主要用来控制峰值显存。--offload_param_devicenvme把参数卸到 NVMe--offload_optimizer_devicecpu把优化器状态放内存。卸载的代价非常直接每次换入换出都是 PCIe 往返NVMe 的顺序读还好随机读会拖到几毫秒一次。所以我的取舍是推理优先调小 batch 和限制上下文长度实在放不下再开卸载训练场景才考虑把优化器状态卸到 CPU。另外 NVMe 卸载路径要显式指向大盘默认可能写到根分区跑一会儿就把盘写满。4.3 量化前后的显存账本把账算清楚才知道该买卡还是该调参。下表是同一下载环境的实测口径batch1上下文 2048数值会随驱动和算子版本浮动看趋势即可。模型规模FP16 权重4-bit 权重推理峰值4-bit2048 上下文7B约 8.4GB约 2.4GB4GB ~ 6GB32B约 38.4GB约 11GB16GB ~ 20GB32B 卸载约 38.4GB约 11GB显存 12GB余量走内存与 NVMe看到这张表就能理解为什么 24GB 卡是性价比拐点4-bit 的 32B 权重 11GB加 KV Cache 和激活24GB 刚好把上下文拉到 4K 左右。超过这个上下文长度还是得回到多卡。5. 排查记录DeepSeek 本地部署最容易翻车的五处下面五条是这套环境里复现率最高的问题按“现象 → 原因 → 解决”记遇到时按顺序对号入座比从头重装快得多。一、torch.cuda.is_available()返回 False但nvidia-smi正常现象是显卡识别得到PyTorch 死活不用。原因九成是 pip 装成了 CPU 版或者 cu118 版索引源被内网镜像接管了。解决pip uninstall torch torchvision torchaudio -y后显式带--extra-index-url https://download.pytorch.org/whl/cu121重装装完确认版本号带cu121后缀。二、WSL2 里nvidia-smi报通信失败原因是 WSL 内又装了一遍 Linux 显卡驱动把/usr/lib/wsl/lib下的透传库覆盖了。解决在 WSL 内卸掉自装的驱动包sudo apt purge相关 nvidia 包保留 Windows 侧 535.54.03 以上驱动然后wsl --update重启 WSL。这条最容易反复踩重装系统后忘了就再来一遍。三、显存明明够还是报CUDA out of memory现象是nvidia-smi显示只用了 60%进程依然 OOM。原因通常有三个上下文长度超出预估导致 KV Cache 暴涨、device_mapauto把部分层散到了不同设备产生碎片、机器上还挂着别的推理进程。解决先用torch.cuda.memory_summary()看真实分配再调小 batch 和max_new_tokens多卡时改成显式device_map。四、FlashAttention-2 编译到一半进程被杀原因是MAX_JOBS默认吃满 CPU 核数编译器并发太高把内存打穿被内核 OOM killer 干掉日志里连报错都没有。解决固定MAX_JOBS4必要时降到 2同时确认TORCH_CUDA_ARCH_LIST和实卡计算能力一致填错会白编译一遍。五、多卡启动后卡住日志停在 NCCL init现象是没有报错进程一直不前进。原因多为world_size和实际 GPU 数不符、rank重复或者init_method的端口被防火墙拦了。解决逐台ping主节点 IP、telnet端口确认world_size等于总 GPU 数每台机器的rank唯一容器里再加NCCL_SOCKET_IFNAME指定网卡。这一步我一般会在正式跑之前单独用一个最小 all-reduce 脚本验一遍比在大模型里排查省时间。6. 装完怎么验证跑通三层验收和一次 profiling环境装完最怕的是“看起来能跑”。我的验收分三层一层不过不进下一层。第一层看硬件与驱动nvidia-smi里驱动版本、显存、ECC 状态正常nvcc -V输出 12.1deviceQuery末尾是 PASS。第二层看框架3.2 节那三行输出全绿再跑一次最小推理用一句你好测首 token 延迟。第三层才是多卡和压测用world_size对应的进程数跑一次 all-reduce确认带宽没有掉到千兆水平。import torch from torch.profiler import profile, ProfilerActivity with profile( activities[ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3), # 跳过前两步预热 on_trace_readytorch.profiler.tensorboard_trace_handler(./log), record_shapesTrue, ) as prof: for step in range(10): model(input_ids) prof.step()wait1表示第一个 step 不采样warmup1表示第二个 step 只跑不记active3表示连续采三个 step这个节奏是为了避开首次推理的算子编译和显存预分配采到的才是稳态数据。record_shapesTrue会记张量形状排查显存峰值时很有用但会拖慢速度压测时关掉。线上环境再补一套监控DCGM 用容器起Prometheus 从 9400 端口抓docker run -d --gpus all --rm -p 9400:9400 nvcr.io/nvidia/cloud-native/dcgm:3.3.1-1-ubuntu22.04# prometheus 抓取配置 - job_name: dcgm static_configs: - targets: [localhost:9400]DCGM 采的是 GPU 利用率、显存、温度、ECC 错误这些底层指标配合 Grafana 看曲线能提前发现显存缓慢爬升这类泄漏。验收指标我按三个数卡单请求首 token 延迟、输入 512 tokens 时的端到端延迟是否低于 200ms、批量场景吞吐是否接近 1000 requests/sec。达不到不一定是配置问题也可能是上下文长度或 batch 设得太激进先用 profiler 定位到具体算子再调。从那以后我每次装完这套环境都强制走一遍三层验收尤其是第二层的三行校验和最小推理绝不因为nvidia-smi正常就认为装好了——省下的那十分钟往往要用一晚上排查来还。希望帮到你。这套从硬件配置表到命令、参数和排查清单的流程我整理进了《DeepSeek本地部署的硬件要求与环境配置》这份 PDF需要照着装的话按项目名找一下就能取到。本文还有配套的精品资源点击获取
简介这份PDF文档聚焦DeepSeek大模型的本地化部署面向希望私有化运行开源模型的企业开发者、运维人员及具备一定Linux与深度学习基础的个人研究者帮助其在数据安全、定制化需求和算力规划之间建立可落地的配置方案。包内仅含1个PDF文件压缩包约274KB篇幅集中、便于随查随用内容从不同参数规模对应的硬件选型切入延伸至操作系统准备、CUDA与cuDNN加速环境、PyTorch定制安装及分布式训练配置。文档还专门讨论了4-bit量化加载、显存分级卸载、FlashAttention-2启用以及DCGM监控和PyTorch Profiler性能分析等实践要点并给出基础开发测试与生产级集群的分级建议可当作部署前的选型清单和排错参考。已有2219人学习适合需要快速厘清DeepSeek本地部署门槛、对照硬件配置与关键环境参数的读者查阅。1. 硬件先算账一次显存估错的 DeepSeek 本地部署DeepSeek 本地部署最常见的翻车不是模型权重下载不下来而是机器到位、环境配好、from_pretrained一跑屏幕上只有一行CUDA out of memory。我见过最典型的一次是有人按“7B 模型 8GB 显存够用”的直觉买了张 8GB 卡结果 FP16 权重本身就吃掉 8.4GB连加载都过不去。显存账算错后面 CUDA、PyTorch、量化配得再漂亮都是白搭。这篇笔记按“先算硬件 → 再铺系统 → 装计算加速 → 压显存 → 排错 → 验收”的顺序走一遍适合想在自己机器或小集群上跑私有化推理的开发者和运维从 7B 单卡测试到 32B 多卡生产都能对上号。2. 硬件与系统底座7B 单卡和 32B 集群两套配置怎么落地装机之前先别急着下单把参数规模、精度、并发三个数摆在一起配置表自然就出来了。这一章先给显存倒推的算法和两档配置再落到 Ubuntu 22.04 LTS 与 Windows 11 WSL2 两条系统路线的初始化动作。系统装错后面 CUDA 装十遍也白装。2.1 显存倒推公式与两档硬件配置表推理场景下有个粗算口径FP16 精度每 10 亿参数约需 1.2GB 显存这是权重本身的占位。7B 模型约 8.4GB32B 模型约 38.4GB。但权重只是底座真正把显存吃穿的是 KV Cache 和中间激活——上下文长度翻倍KV Cache 线性涨并发路数翻倍它再涨一次。所以我一般会在权重基础上留 1.5 到 2 倍余量再决定买什么卡。内存则按显存的 2 倍以上配用来缓存中间计算数据和做卸载缓冲这一条在开了 CPU 卸载之后尤其关键。组件基础开发测试7B 以下生产级部署32B 以上CPUi7 10 代 / Ryzen 5 5600X2×EPYC 776364 核 128 线程GPUGTX 1660 6GB最低/ RTX 3090 24GB推荐4×A100 80GBNVLink 互联内存16GB DDR4 / 32GB DDR4 ECC512GB DDR4 ECC存储512GB NVMe / 1TB NVMe 4TB HDD8TB NVMe RAID 0 100TB NAS网络千兆以太网 / 万兆光纤网卡InfiniBand HDR 200Gb这张表里有两处容易被忽略。第一处是推荐的 24GB 卡并不是为了跑满 7B 的 FP16而是为了留出上下文空间和跑 4-bit 量化后的 32B 模型做验证第二处是生产档的 NVMe 用了 RAID 0图的是模型加载和 checkpoint 写入的吞吐代价是没有冗余权重文件必须另存一份到 NAS。生产档的验收指标按输入长度 512 tokens 算推理延迟要压到 200ms 以内批量优化后吞吐上到 1000 requests/sec这两个数不是买完机器就自动有的得靠后面几章的配置去逼近。2.2 Ubuntu 22.04 LTS 初始化的三条命令Linux 是主路线版本直接锁 Ubuntu 22.04 LTS内核 5.15 以上对 CUDA 12.1 的兼容最省心。系统装完先做三件事补齐内核额外模块、压低交换分区使用、划出专用部署目录。# 补齐 CUDA 依赖的内核模块缺了会报 nvidia-uvm 加载失败 sudo apt update sudo apt install -y linux-modules-extra-$(uname -r) # 压低交换倾向避免推理时热数据被换出到磁盘 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 专用部署目录用 chown 交给当前用户不要图省事开 777 sudo mkdir -p /opt/deepseek sudo chown -R $USER:$USER /opt/deepseeklinux-modules-extra-$(uname -r)里的$(uname -r)会自动展开成当前内核版本装完不需要重启就能让nvidia-uvm之类模块可用。vm.swappiness10的含义是把换页倾向从默认 60 压到 10只在内存真正吃紧时才动交换分区——大模型推理一旦发生换页延迟会从毫秒级跳到秒级这是玄学延迟的常见来源。目录权限我没有沿用原文里的chmod 777多用户机器上 777 意味着谁都能改模型权重常见做法是用chown把属主给部署账号需要多人协作再加组权限。另外装驱动前建议顺手屏蔽开源的 nouveau 驱动不然安装器会提示需要先禁用。2.3 Windows 11 22H2 WSL2 的必装组件本地验证、单机试跑的场景里Windows 路线完全可行但组件版本要对齐系统 Windows 11 Pro 22H2 及以上WSL2 里装 Ubuntu 20.04 LTS显卡驱动 535.54.03 以上并且确保 DirectX 12 Ultimate 运行时就位。# 在 Windows 侧执行启用 WSL2 并指定发行版 wsl --install -d Ubuntu-20.04 wsl --update # 进入 WSL 后验证 GPU 透传是否生效 nvidia-smiwsl --update别跳过旧版 WSL 内核对新驱动透传支持不完整会出现 WSL 里nvidia-smi提示找不到设备。这里有个反直觉的坑WSL2 里的 GPU 是 Windows 驱动直接透传的不要在 WSL 内再装一遍 Linux 版显卡驱动装了反而会把/usr/lib/wsl/lib下的库覆盖掉导致 CUDA 初始化失败。WSL 路线也有硬限制显存上限受 Windows 侧驱动和 WDDM 管理长上下文跑起来比裸机更容易 OOM真上生产还是回 Ubuntu。2.4 部署目录与存储分层目录规划花十分钟后面能省几小时。我习惯的分法是/opt/deepseek/models放权重/opt/deepseek/env放虚拟环境/opt/deepseek/logs放 profiling 和运行日志/opt/deepseek/cache放 Hugging Face 缓存。权重的读取是随机大块 IO必须落在 NVMe 上日志和数据集可以走 NAS模型仓库和生产镜像放私有 Harbor 这类内网仓库里别每次重拉。# 把下载缓存重定向到大盘避免默认落进根分区 export HF_HOME/opt/deepseek/cache mkdir -p $HF_HOME df -h /opt/deepseek # 确认剩余空间大于权重体积的 2 倍HF_HOME这一条是血泪经验32B 的权重加上分片和临时文件轻松吃掉几十 GB默认路径在~/.cache而很多机器的根分区只给了 50GB下到 90% 就写失败报错还跟权限长得很像。用df -h先确认目标分区余量比事后删缓存省事。3. 计算加速环境CUDA 12.1 cuDNN PyTorch 2.1.0 的版本对齐这一章是整套环境里最容易出玄学的地方问题几乎都能归到一句话版本没对齐。CUDA 12.1、cuDNN 8.9 以上、PyTorch 2.1.0cu121、FlashAttention-2 2.3.3这四个组件的版本是一条链断一环就是undefined symbol或者静默回落到 CPU。3.1 CUDA 12.1 静默安装与工具链验证安装器用 runfile 方式参数决定装了什么、跳过了什么。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跳过编译器版本和系统版本的兼容性检查Ubuntu 22.04 加新内核时基本都要带。--toolkit只装工具链不装随包的驱动。驱动交给系统包管理统一维护否则容易出现内核升级后驱动失配。--samples装示例程序后面验证要用deviceQuery。--silent无交互安装适合脚本化。装完配环境变量写进~/.bashrc而不是只在当前 shell 里 export不然换个终端就找不到nvccexport PATH/usr/local/cuda-12.1/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH nvcc -V # 应输出 release 12.1 /usr/local/cuda-12.1/samples/1_Utilities/deviceQuery/deviceQuery # 末尾应是 Result PASSLD_LIBRARY_PATH里指向lib64的顺序有讲究如果系统里还留着旧版 CUDA一定要让 12.1 排在前面否则运行时加载到旧版libcudart表现为编译通过、运行报错。deviceQuery显示 PASS 只代表驱动和工具链握手成功不代表 PyTorch 能用下一步还得单独验。3.2 PyTorch 2.1.0cu121 与 cuDNN 版本校验PyTorch 必须装 cu121 的轮子不能用默认源。# 指定 cu121 索引避免默认源给到 CPU 版或 cu118 版 pip install torch2.1.0cu121 --extra-index-url https://download.pytorch.org/whl/cu121装完跑一段校验三行输出缺一不可import torch print(torch.cuda.is_available()) # 必须 TrueFalse 说明装成了 CPU 版 print(torch.version.cuda) # 应输出 12.1和系统 CUDA 对齐 print(torch.backends.cudnn.version()) # 应 8902torch.cuda.is_available()返回 False 时先看pip list | grep torch里版本号带不带cu121后缀。不带就是索引没生效常见原因是公司内网镜像覆盖了--extra-index-url或者pip被PIP_INDEX_URL环境变量锁死。torch.version.cuda输出 11.8 则说明装的是 cu118 轮子运行时和系统 CUDA 12.1 混用表现为某些算子报no kernel image is available。cuDNN 版本低于 8902 时FlashAttention 的编译会直接失败这个数要盯住。3.3 FlashAttention-2 的编译参数取舍FlashAttention-2 装的是源码包本地编译两个环境变量决定成败。# 8.0 对应 A1003090 用 8.64090/L40 用 8.9 MAX_JOBS4 TORCH_CUDA_ARCH_LIST8.0 pip install flash-attn2.3.3TORCH_CUDA_ARCH_LIST填的是目标显卡的计算能力代号填错不会报错只会在运行时报“不支持当前设备”或者悄悄走回退实现速度掉一半还查不出原因。MAX_JOBS4控制并行编译的进程数默认会按 CPU 核数拉满64 核机器上一次起 64 个编译器内存瞬间打满然后 OOM——这是我在 512GB 内存的机器上都被打死过一次的场景。编译时间通常半小时到一小时半机器越新越慢别以为卡住了就 CtrlC。顺带说一个取舍如果只用推理、不做训练也可以用预编译轮子省掉编译时间代价是对新卡的支持滞后需要极致吞吐、要开 FlashAttention-2 的还是老老实实本地编译。3.4 多卡 NCCL 配置与 deepseek.yaml 写法单卡跑通之后上多卡通信后端固定用 NCCL。配置文件里几个字段必须和物理机对得上# deepseek.yaml 分布式片段 distributed: backend: nccl # GPU 间通信后端不要用 gloo init_method: tcp://192.168.1.100:23456 # 主节点地址与端口各节点要能互通 world_size: 4 # 总进程数等于所有节点的 GPU 总数 rank: 0 # 当前节点编号从 0 开始且不能重复world_size写大了进程会一直等一个永远不存在的伙伴表现为启动后卡住不报错写小了则有一张卡闲在那里。rank重复的典型现象是init_method端口被占第二个进程起不来。init_method用的 IP 必须是各节点都能访问的内网地址容器里跑还要确认端口没被网络策略挡住。多机场景下再补一个NCCL_SOCKET_IFNAME指定网卡不然 NCCL 可能挑到管理网卡上跨机带宽从 200Gb 掉到千兆训练一轮能等到怀疑人生。4. 显存压下来4-bit 量化与分级卸载的配置写法硬件定了没法改显存就得靠软件挤。这一章的两套手段——4-bit 量化和分级卸载——解决的是不同问题量化是压权重本身的体积卸载是把放不下的部分挪到内存和 NVMe 上。两个一起上24GB 卡跑 32B 模型才有戏。4.1 BitsAndBytesConfig 四个参数的取舍量化配置里四个参数每一个都影响精度或速度不能照抄了事。import torch from transformers import BitsAndBytesConfig, AutoModelForCausalLM bnb_config BitsAndBytesConfig( load_in_4bitTrue, # 权重按 4bit 加载体积约为 FP16 的四分之一 bnb_4bit_use_double_quantTrue, # 二次量化再省约 0.4bit/参数几乎不掉点 bnb_4bit_quant_typenf4, # 正态分布量化比 fp4 更适合权重分布 bnb_4bit_compute_dtypetorch.bfloat16, # 计算时上采样到 bf16兼顾精度和速度 ) model AutoModelForCausalLM.from_pretrained( deepseek-ai/deepseek-32b, quantization_configbnb_config, device_mapauto, # 自动把层分配到可用设备 )bnb_4bit_quant_type选nf4而不是fp4是因为预训练权重大致服从正态分布nf4 的分位点按正态分布切同等比特下误差更小。bnb_4bit_compute_dtype在 A100 及以上的卡上选bfloat16数值范围比 fp16 大量化反量化过程不容易溢出老卡不支持 bf16 就退回float16。device_mapauto会自动计算每层放哪配多卡时建议换成显式映射避免它把 embedding 层丢到 CPU 上导致首 token 延迟暴涨。量化不是免费的4-bit 相比 FP16 通常有几个点的效果波动客服问答这类任务问题不大要求严格的场景建议做一轮对照评测再上线。4.2 accelerate 分级卸载的参数与启动命令权重压到 4-bit 还放不下就上卸载把参数和优化器状态分别丢到 NVMe 和 CPU 内存计算时再换进来。accelerate launch --config_file accelerate_config.yaml \ --num_processes 4 \ --mixed_precision bf16 \ --gradient_accumulation_steps 8 \ --offload_param_devicenvme \ --offload_optimizer_devicecpu \ run_inference.py--num_processes 4要等于可用 GPU 数不等于world_size时行为不可预期。--mixed_precision bf16让前向反向用 bf16显存再省一截前提是卡支持。--gradient_accumulation_steps 8用累积步数换小 batch推理场景主要用来控制峰值显存。--offload_param_devicenvme把参数卸到 NVMe--offload_optimizer_devicecpu把优化器状态放内存。卸载的代价非常直接每次换入换出都是 PCIe 往返NVMe 的顺序读还好随机读会拖到几毫秒一次。所以我的取舍是推理优先调小 batch 和限制上下文长度实在放不下再开卸载训练场景才考虑把优化器状态卸到 CPU。另外 NVMe 卸载路径要显式指向大盘默认可能写到根分区跑一会儿就把盘写满。4.3 量化前后的显存账本把账算清楚才知道该买卡还是该调参。下表是同一下载环境的实测口径batch1上下文 2048数值会随驱动和算子版本浮动看趋势即可。模型规模FP16 权重4-bit 权重推理峰值4-bit2048 上下文7B约 8.4GB约 2.4GB4GB ~ 6GB32B约 38.4GB约 11GB16GB ~ 20GB32B 卸载约 38.4GB约 11GB显存 12GB余量走内存与 NVMe看到这张表就能理解为什么 24GB 卡是性价比拐点4-bit 的 32B 权重 11GB加 KV Cache 和激活24GB 刚好把上下文拉到 4K 左右。超过这个上下文长度还是得回到多卡。5. 排查记录DeepSeek 本地部署最容易翻车的五处下面五条是这套环境里复现率最高的问题按“现象 → 原因 → 解决”记遇到时按顺序对号入座比从头重装快得多。一、torch.cuda.is_available()返回 False但nvidia-smi正常现象是显卡识别得到PyTorch 死活不用。原因九成是 pip 装成了 CPU 版或者 cu118 版索引源被内网镜像接管了。解决pip uninstall torch torchvision torchaudio -y后显式带--extra-index-url https://download.pytorch.org/whl/cu121重装装完确认版本号带cu121后缀。二、WSL2 里nvidia-smi报通信失败原因是 WSL 内又装了一遍 Linux 显卡驱动把/usr/lib/wsl/lib下的透传库覆盖了。解决在 WSL 内卸掉自装的驱动包sudo apt purge相关 nvidia 包保留 Windows 侧 535.54.03 以上驱动然后wsl --update重启 WSL。这条最容易反复踩重装系统后忘了就再来一遍。三、显存明明够还是报CUDA out of memory现象是nvidia-smi显示只用了 60%进程依然 OOM。原因通常有三个上下文长度超出预估导致 KV Cache 暴涨、device_mapauto把部分层散到了不同设备产生碎片、机器上还挂着别的推理进程。解决先用torch.cuda.memory_summary()看真实分配再调小 batch 和max_new_tokens多卡时改成显式device_map。四、FlashAttention-2 编译到一半进程被杀原因是MAX_JOBS默认吃满 CPU 核数编译器并发太高把内存打穿被内核 OOM killer 干掉日志里连报错都没有。解决固定MAX_JOBS4必要时降到 2同时确认TORCH_CUDA_ARCH_LIST和实卡计算能力一致填错会白编译一遍。五、多卡启动后卡住日志停在 NCCL init现象是没有报错进程一直不前进。原因多为world_size和实际 GPU 数不符、rank重复或者init_method的端口被防火墙拦了。解决逐台ping主节点 IP、telnet端口确认world_size等于总 GPU 数每台机器的rank唯一容器里再加NCCL_SOCKET_IFNAME指定网卡。这一步我一般会在正式跑之前单独用一个最小 all-reduce 脚本验一遍比在大模型里排查省时间。6. 装完怎么验证跑通三层验收和一次 profiling环境装完最怕的是“看起来能跑”。我的验收分三层一层不过不进下一层。第一层看硬件与驱动nvidia-smi里驱动版本、显存、ECC 状态正常nvcc -V输出 12.1deviceQuery末尾是 PASS。第二层看框架3.2 节那三行输出全绿再跑一次最小推理用一句你好测首 token 延迟。第三层才是多卡和压测用world_size对应的进程数跑一次 all-reduce确认带宽没有掉到千兆水平。import torch from torch.profiler import profile, ProfilerActivity with profile( activities[ProfilerActivity.CUDA], scheduletorch.profiler.schedule(wait1, warmup1, active3), # 跳过前两步预热 on_trace_readytorch.profiler.tensorboard_trace_handler(./log), record_shapesTrue, ) as prof: for step in range(10): model(input_ids) prof.step()wait1表示第一个 step 不采样warmup1表示第二个 step 只跑不记active3表示连续采三个 step这个节奏是为了避开首次推理的算子编译和显存预分配采到的才是稳态数据。record_shapesTrue会记张量形状排查显存峰值时很有用但会拖慢速度压测时关掉。线上环境再补一套监控DCGM 用容器起Prometheus 从 9400 端口抓docker run -d --gpus all --rm -p 9400:9400 nvcr.io/nvidia/cloud-native/dcgm:3.3.1-1-ubuntu22.04# prometheus 抓取配置 - job_name: dcgm static_configs: - targets: [localhost:9400]DCGM 采的是 GPU 利用率、显存、温度、ECC 错误这些底层指标配合 Grafana 看曲线能提前发现显存缓慢爬升这类泄漏。验收指标我按三个数卡单请求首 token 延迟、输入 512 tokens 时的端到端延迟是否低于 200ms、批量场景吞吐是否接近 1000 requests/sec。达不到不一定是配置问题也可能是上下文长度或 batch 设得太激进先用 profiler 定位到具体算子再调。从那以后我每次装完这套环境都强制走一遍三层验收尤其是第二层的三行校验和最小推理绝不因为nvidia-smi正常就认为装好了——省下的那十分钟往往要用一晚上排查来还。希望帮到你。这套从硬件配置表到命令、参数和排查清单的流程我整理进了《DeepSeek本地部署的硬件要求与环境配置》这份 PDF需要照着装的话按项目名找一下就能取到。本文还有配套的精品资源点击获取
