DeepSeek本地部署：显存估算、环境配置与量化调优指南

简介：《DeepSeek本地部署的硬件要求与环境配置》是一份面向企业开发者与个人研究者的技术文档，聚焦私有化部署大模型时的硬件选型与环境搭建难题。内容按场景分级展开：7B以下模型的基础测试配置与32B以上参数的生产级集群方案，逐项列出CPU、GPU、内存、存储与网络要求，并给出显存与参数量的换算关系；同时覆盖Ubuntu与Windows双平台准备、CUDA与cuDNN安装验证、PyTorch及FlashAttention定制安装、分布式训练参数配置，以及4-bit量化加载、分级卸载等显存优化策略和DCGM实时监控的落地做法。资源包为1个PDF文件，约274KB，便于离线查阅与团队传阅。已有2219人学习，适合正在评估本地部署可行性、或需要对照配置清单排查环境问题、做量化与显存调优的读者。

1. DeepSeek 本地部署这件事，先算显存再谈下载

很多人把 DeepSeek 本地部署想成“下载权重、装个环境、敲一行启动命令”，真上手才发现卡住的点在别处：一张 6GB 的显卡刚把模型加载到一半就报 CUDA out of memory，一台 32GB 内存的机器在 4-bit 量化下勉强跑通却每秒钟吐不出三个字。硬件要求与环境配置这两件事，本质上是一道预算题——参数规模决定显存下限，显存决定你能不能用更大的 batch，batch 又反过来决定吞吐。这份《DeepSeek 本地部署的硬件要求与环境配置》把个人测试机到企业级集群的分级配置、驱动与 CUDA 工具链、量化加载、分布式卸载、监控排错串成一条线。它适合三类人：想在自己机器上跑通推理的开发者、要给团队搭一套私有推理服务的运维、以及正在评估“到底该买什么卡”的技术负责人。

2. 硬件分级选型：显存公式与三档配置的边界在哪

买卡这件事最容易翻车的地方，是拿“模型参数量”直接对标“显存容量”。7B 模型不是 7GB 显存就够，32B 模型也不是 32GB 就能塞下。中间隔着一个 KV Cache，还有激活值和临时缓冲区。原料里给出的经验值是 FP16 精度下每 10 亿参数约 1.2GB 显存，这个数字对应的是权重本身，属于下限而非上限。真正决定你能不能开长上下文、能不能并发多路的，是后面那两笔账。

2.1 显存三笔账：权重、KV Cache 与激活余量

权重账好算，精度换一下系数就变：FP16/BF16 按 1.2GB/1B 估，INT8 大约减半，NF4 4-bit 因为要存量化常数和分组缩放因子，实测落在 0.55～0.7GB/1B 之间，我一般按 0.7 估，宁可留点余量。KV Cache 这笔账最容易被忽略，它跟上下文长度、并发数、层数、KV 头数全部线性相关，公式是 2（K 和 V）× 层数 × KV 头数 × head_dim × 序列长度 × batch × 单元素字节数。

# 显存粗估：权重 + KV Cache + 激活余量，单位 GB def estimate_vram(params_b, layers, kv_heads, head_dim, seq_len, batch, weight_gb_per_b=1.2, # FP16 权重系数；NF4 量化可改 0.7 bytes_per_elem=2, # FP16 为 2，BF16 也是 2 act_ratio=0.15): # 激活与临时缓冲，按权重比例留余量 weight = params_b * weight_gb_per_b # 2 表示 K/V 各一份；kv_heads 是 GQA 分组后的头数，不是注意力总头数 kv = 2 * layers * kv_heads * head_dim * seq_len * batch * bytes_per_elem / (1024 ** 3) act = weight * act_ratio return {"weight": round(weight, 1), "kv_cache": round(kv, 1), "activation": round(act, 1), "total": round(weight + kv + act, 1)} # 以 GQA 结构示例取值：64 层、8 个 KV 头、head_dim 128 print(estimate_vram(32, 64, 8, 128, seq_len=4096, batch=1)) print(estimate_vram(32, 64, 8, 128, seq_len=4096, batch=8))

这段代码的价值在于把“我感觉够”变成可对照的数字。params_b填模型参数量（单位十亿），layers和kv_heads从模型配置文件里查num_hidden_layers和num_key_value_heads，注意后者在 GQA 模型里远小于num_attention_heads，填错会让 KV Cache 高估好几倍。seq_len是你实际业务里的输入加输出总长度，不是模型声称的最大上下文。batch就是并发路数，它是最灵敏的旋钮——batch 从 1 加到 8，权重一项不变，KV Cache 直接乘 8。跑一遍你会发现，32B 模型在 4096 长度下单路只需要十几个 GB，八路并发就要多出上百 GB，这就是为什么企业级场景要堆卡而不是堆单卡显存。

2.2 三档配置：从测试机到集群的边界感

原料里的分级思路是对的，但边界比表格更值得记。基础测试档对应 7B 以下模型，6GB 显存的卡能加载 4-bit 量化版本，但上下文只能压到 2K 左右，且不能开并发；16GB 内存是底线，因为模型加载时会先在内存里做一次反序列化再搬到显存，内存不足会直接触发 OOM Killer 而不是报显存错误。中间档是我认为性价比最高的区间：单张 24GB 卡配 64GB 内存，跑 14B～32B 的 4-bit 量化，能支撑小团队内部的知识问答和文档摘要。

生产档的几个数字要单独解释。4 张 80GB 卡不是简单的 320GB 可用显存，张量并行会把权重切分到每张卡上，同时每张卡还要留出通信缓冲区；NVLink 在这里的作用是让卡间带宽不成为瓶颈，走 PCIe 的话张量并行的效率会掉一大截。512GB 内存对应的是参数卸载场景——把部分层或优化器状态放到 CPU 内存里，靠 PCIe 搬运换取显存放得下更大模型，代价是吞吐下降。至于原料里给出的 200ms 以内延迟、1000 请求每秒吞吐这类指标，需要说清楚前提：那是在固定输入长度、批量预处理、且模型已经预热的情况下测出来的，冷启动第一次请求的耗时通常是稳态的十倍以上。

2.3 存储与网络：最容易被砍预算的两项

很多人配机器时把预算全砸在显卡上，存储随便给个 SATA 固态，结果每次重启服务加载 32B 权重都要等上好几分钟。模型加载是纯顺序读，NVMe 的顺序带宽优势能直接体现出来：一张 3.5GB/s 的盘加载 20GB 权重理论 6 秒，SATA 盘 500MB/s 就要 40 秒，而推理服务重启、扩缩容、灰度发布这些动作都会反复触发加载。原料里写 512GB NVMe 起步、1TB 加机械盘做冷备，这个组合合理，机械盘放模型归档和日志，NVMe 放热加载的权重和缓存。

# 把模型缓存和临时目录挪到大容量盘，避免根分区被权重撑爆 export HF_HOME=/data/hf_cache export TRANSFORMERS_CACHE=/data/hf_cache export TMPDIR=/data/tmp mkdir -p /data/hf_cache /data/tmp df -h /data # 确认目标盘剩余空间大于模型体积的 2 倍

HF_HOME决定权重下载后落在哪，TRANSFORMERS_CACHE在旧版本里单独生效，两个都设上比较稳妥。TMPDIR指向大盘是因为部分加载逻辑会先写临时文件再读回，根分区只有几十 GB 的机器经常在这里翻车。网络部分，千兆环境适合单机拉取权重和内部调用，万兆以上才谈得上多节点共享 NAS 上的模型仓库；InfiniBand 属于多机张量并行的必需品，单机多卡用不上，别被销售话术带着走。

3. 系统环境落地：Ubuntu 内核模块、CUDA 12.1 与 cuDNN 的安装顺序

环境配置最大的误区是“先把 CUDA 装上再说”。正确的顺序是操作系统与内核头文件、显卡驱动、CUDA 工具链、cuDNN、最后才是深度学习框架。顺序颠倒的典型后果是驱动被 CUDA 安装包自带的旧版本覆盖，或者内核升级后 DKMS 没重新编译模块，机器重启直接进不了图形界面。原料里给的 Ubuntu 22.04 LTS 路线是稳的，下面把它拆成可复现的步骤。

3.1 Ubuntu 22.04 的四个前置动作

全新系统装完，先别急着下载模型。内核模块、交换策略、部署目录、驱动检查这四件事做完，后面能省掉大量排错时间。

# 1. 补齐内核头文件与额外模块，DKMS 编译显卡驱动依赖这两项 sudo apt update sudo apt install -y build-essential dkms linux-headers-$(uname -r) linux-modules-extra-$(uname -r) # 2. 降低交换倾向，避免大内存分配被换出到磁盘导致推理卡顿 echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 3. 建专用部署目录并交还当前用户，避免后续所有操作都要 sudo sudo mkdir -p /opt/deepseek && sudo chown -R $USER:$USER /opt/deepseek # 4. 确认驱动与显卡识别正常 nvidia-smi

linux-modules-extra这一项在原料里被标为“启用 CUDA 内核模块”，实际作用是补齐nvidia-uvm等模块的依赖，缺了它nvidia-smi可能正常但 CUDA 程序报找不到设备。vm.swappiness=10不是禁用交换，而是让内核尽量不把推理进程的内存页换出去——大模型推理的常驻内存一旦被换到磁盘，延迟会从毫秒级跳到秒级，这种抖动很难通过日志定位。部署目录单独建并chown是为了后面用非 root 用户跑服务和容器，权限问题在容器挂载卷的时候会集中爆发。nvidia-smi右上角显示的 CUDA Version 是驱动支持的最高运行时版本，不是你已安装的版本，这两个概念混淆会导致后面选错 PyTorch 的 cu 后缀。

3.2 CUDA 12.1 静默安装与 cuDNN 验证

CUDA 安装包有 runfile 和 deb 两种，runfile 的好处是可以精确控制装哪些组件、不碰已有驱动。原料里用的就是 runfile 加--silent参数，适合批量部署。

# 只装工具链和样例，不安装驱动，避免覆盖系统中已就绪的显卡驱动 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 # 写入环境变量，PATH 在前保证 nvcc 用新版本 echo 'export PATH=/usr/local/cuda-12.1/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc nvcc -V # 确认输出 12.1

四个参数的含义要记牢：--override跳过安装器的兼容性检查，在较新内核上不加会直接退出；--toolkit只装编译器、库和头文件，这是不加驱动覆盖的关键；--samples装示例程序，用来做最小化验证；--silent无交互。装完必须做一次真实调用验证，不能只看nvcc -V。

import torch print(torch.cuda.is_available()) # 应为 True print(torch.version.cuda) # 应为 12.1 print(torch.backends.cudnn.version()) # 应 >= 8902 print(torch.cuda.get_device_capability(0)) # 例如 (8, 0) 对应 A100

torch.cuda.is_available()返回 False 时，九成是驱动版本低于 CUDA 运行时要求，或者LD_LIBRARY_PATH指向了错误的 lib64。cudnn.version()低于 8902 说明 cuDNN 没装或装的是旧包，很多算子会退回慢速实现且不报错，表现为“能跑但莫名其妙慢”。get_device_capability返回的计算能力值后面编译 FlashAttention 时要用，先记下来。

3.3 Windows + WSL2 的兼容路径与硬限制

不是所有人都有条件装一台 Linux 机器，Windows 11 加 WSL2 是可行的退路，但要知道它牺牲了什么。原料给的版本要求是 Windows 11 Pro 22H2 及以上、WSL2 内的 Ubuntu 20.04、DirectX 12 Ultimate 运行时、NVIDIA 535.54.03 以上驱动，这套组合能跑通 CUDA 推理。

第一行是很多人踩的坑：WSL2 里的显存不是独占的，Windows 桌面、浏览器、图形加速都会吃掉一部分，标称 24GB 的卡在 WSL2 里可能只剩 22GB 出头，按 24GB 卡的显存边界设计的加载参数会直接 OOM。第二行意味着 WSL2 只适合单卡开发和验证，别指望在上面搭张量并行。第三行的实操建议是把模型权重放在 WSL2 自己的文件系统里（\\wsl$下的路径），而不是放在 Windows 的 NTFS 盘上再跨系统访问，后者在加载大文件时能慢出好几倍。第四行如果要用容器跑推理服务，WSL2 里需要单独装 nvidia-container-toolkit，并且 Docker Desktop 的 GPU 支持开关要打开，否则容器里nvidia-smi直接不认卡。

4. 框架与量化：PyTorch 2.1 匹配、FlashAttention-2 编译与 4-bit 加载

框架层的选择没有太多自由度，基本被显卡型号和 CUDA 版本锁死。真正有操作空间的是三件事：PyTorch 轮子选哪个 cu 后缀、FlashAttention-2 怎么编译不白等、量化配置怎么调才能既省显存又不把精度拉垮。这三件事串起来，决定了你的单卡能不能跑起 32B。

4.1 PyTorch 版本对齐：cu121 后缀不是随便填的

pip 安装 PyTorch 时下载的轮子自带 CUDA 运行时，所以系统里装的 CUDA 版本和轮子后缀不需要严格相等，但必须满足“驱动支持的最高版本 ≥ 轮子要求的运行时版本”。原料里给的是torch==2.1.0+cu121，对应 CUDA 12.1 运行时。

# 先卸干净旧版本，避免多份 torch 在 site-packages 里打架 pip uninstall -y torch torchvision torchaudio # 安装匹配 CUDA 12.1 的轮子，torchvision 版本号必须与 torch 对应 pip install torch==2.1.0 torchvision==0.16.0 \ --extra-index-url https://download.pytorch.org/whl/cu121

--extra-index-url指向 PyTorch 自己的轮子仓库，不加会从默认源装到 CPU 版本，症状是torch.cuda.is_available()一直 False 但驱动明明正常。torchvision的版本必须和torch严格配对，2.1.0 对应 0.16.0，乱配会在导入时报符号未定义。装完再跑一次 3.2 节那段验证脚本，确认torch.version.cuda输出 12.1。如果机器上有多套 Python 环境，务必确认pip -V指向的是你要用的那个解释器，虚拟环境没激活就 pip 安装是最常见的“装了但没生效”原因。

4.2 FlashAttention-2 编译：架构列表填错就是白等

FlashAttention-2 是源码编译安装，编译时会把当前架构对应的 CUDA 内核全部生成一遍，这一步动辄二三十分钟。TORCH_CUDA_ARCH_LIST填错的话，编译能过，运行时却报“no kernel image is available for execution on the device”。

# 限制并行编译任务数，防止小内存机器编译时被 OOM Killer 干掉 export MAX_JOBS=4 # 只编译目标显卡的架构，多填会显著拉长编译时间 export TORCH_CUDA_ARCH_LIST="8.0" pip install flash-attn==2.3.3 --no-build-isolation

MAX_JOBS=4的取值逻辑是看机器内存：每个编译进程大约吃 2～3GB，32GB 内存的机器开 4 个比较稳，开 8 个很容易在链接阶段被系统杀进程，报错信息还看不出是内存问题。TORCH_CUDA_ARCH_LIST的对应关系必须查准：A100 是 8.0，3090 是 8.6，4090 是 8.9，H100 是 9.0，多卡异构才需要写多个值。--no-build-isolation让编译过程复用当前环境里已装的 torch，否则 pip 会新建隔离环境重新拉一份，编译时间翻倍还可能版本对不上。

装完之后用python -c "import flash_attn; print(flash_attn.__version__)"验证版本，再在真实模型上跑一次前向确认不报内核缺失，只 import 成功不算通过。

4.3 4-bit 量化加载：nf4、双重量化与 device_map 的顺序

显存不够时，量化是最直接的后悔药。原料里给的 BitsAndBytesConfig 配置是标准组合，四个参数各管一件事，改错任何一个都会让效果或显存不符合预期。

import torch from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, # 权重按 4bit 存储 bnb_4bit_use_double_quant=True, # 对量化常数再量化一次，约再省 0.4bit/参数 bnb_4bit_quant_type="nf4", # 正态分布友好的 4bit 数据类型 bnb_4bit_compute_dtype=torch.bfloat16 # 计算时升到 bf16，兼顾精度与速度 ) model = AutoModelForCausalLM.from_pretrained( "deepseek-ai/deepseek-32b", quantization_config=bnb_config, device_map="auto", # 按显存余量自动切分到多卡或 CPU trust_remote_code=True, torch_dtype=torch.bfloat16 ) tokenizer = AutoTokenizer.from_pretrained("deepseek-ai/deepseek-32b", trust_remote_code=True)

quant_type="nf4"比fp4更适合大模型权重，因为权重近似正态分布，nf4 的量化格点按分位数排布，同等比特数下误差更小；换成 fp4 通常能看到困惑度上升。use_double_quant=True省的是量化常数那点开销，7B 模型上大约省 0.4GB，32B 上能省 1～2GB，属于白拿的收益，代价是加载时多一点点解压计算。compute_dtype必须显式指定，不写的话默认走 fp16，在 A100/H100 上 bf16 的数值稳定性更好且速度持平。device_map="auto"是按显存自动切分，多卡时会用 accelerate 的分片策略，但要注意它优先填满靠前的卡，做压测时不能假设负载均匀。

4.4 分布式与分级卸载：world_size、rank 与 offload 的取舍

单卡放不下又不想降精度，就走参数卸载。原料里给了 accelerate 的启动参数，核心是把优化器状态放 CPU、参数放 NVMe，用 PCIe 带宽换显存空间。

# accelerate_config.yaml distributed_type: MULTI_GPU num_processes: 4 # 等于 world_size，总进程数 mixed_precision: bf16 # 与量化配置里的 compute_dtype 保持一致 gpu_ids: all

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" \ train_or_infer.py

num_processes必须等于distributed_type下实际参与的 GPU 数，写多了会在 NCCL 初始化阶段挂起，报错信息通常是超时而不是明确的“进程数不匹配”。gradient_accumulation_steps=8是用时间换显存：等效 batch 放大 8 倍，但显存峰值只按单批算，代价是训练时长线性增加。两个 offload 参数的物理含义不同——offload_param_device="nvme"把模型参数扔到固态盘，换入换出走 NVMe 带宽，适合参数多但访问频次相对可控的场景；offload_optimizer_device="cpu"把优化器状态放内存，走 PCIe。两者同时开会让端到端速度掉到纯 GPU 的几分之一，只在显存实在不够时用。另外init_method用tcp://IP:PORT的写法时，这个 IP 必须是所有节点都能访问到的地址，多网卡的机器要显式指定绑定的网卡，否则会选到不通的那张。

5. 避坑排查：显存溢出、首包延迟与吞吐塌方的四类翻车

上面几章是按正确路径写的，实际现场更多是从报错往回倒推。这一章把四类高频翻车按“现象、原因、解决”记下来，都是能直接对上号的。

5.1 显存账不对：CUDA out of memory 的三种真面目

现象一：模型加载到 90% 左右报CUDA out of memory，nvidia-smi显示显存其实还有不少余量。原因：加载过程先在内存里反序列化权重再逐层搬到显存，峰值出现在搬运阶段，且 PyTorch 的缓存分配器会预留碎片，nvidia-smi看到的是物理占用，跟分配器视角不一致。解决：把device_map从auto改成显式的{"": 0}先单卡验证，或者加low_cpu_mem_usage=True让加载走分片路径，内存也要留出模型体积 2 倍以上的余量。

现象二：单条请求正常，并发到 8 路就 OOM，间隔性的。原因：KV Cache 随 batch 线性增长，而显存估算时按 batch=1 算的，并发上来直接把预留的激活余量吃掉。解决：回 2.1 节的脚本按实际 batch 重算一遍，用max_batch_size或推理框架的调度参数把并发卡在显存能兜住的值，别指望靠重试解决。

现象三：跑了一段时间才开始 OOM，重启就恢复。原因：请求长度不固定，长输入把 KV Cache 撑到峰值后，分配器持有的缓存块没有及时释放，后面短请求进来也复用不了。解决：开model.gradient_checkpointing_enable()降激活峰值（推理场景主要对长输入有帮助），或者设置PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True减少碎片；根治办法是在服务层做输入长度截断和请求队列限流。

5.2 延迟不达标：首 token 慢与长输入抖动的两个来源

现象：单条请求首 token 要好几秒，之后就快了。原因：冷启动没预热，第一次前向要触发内核编译、显存分配、权重从内存到显存的搬运，这些开销在稳态下不存在。解决：服务启动后先跑几条固定长度的假请求做预热，把torch.cuda.synchronize()前后的耗时打出来，确认预热生效再挂负载均衡。

现象：输入从 512 token 涨到 4096 token 后，延迟不是线性增长而是跳变。原因：注意力计算在长序列下从访存受限变成计算受限，且 KV Cache 大了之后缓存命中率下降。解决：上 FlashAttention-2（4.2 节），确认它真的被用上了——在 Profiler 里看 attention 算子的名字，没出现 flash 前缀说明走的还是慢速实现；同时检查attn_implementation参数有没有显式指定。另一个容易忽略的点是分页显存没开，长序列下 KV Cache 的碎片会额外拖慢。

5.3 多卡跑不动：NCCL 卡住与吞吐上不去的排查顺序

现象：多卡启动后日志停在 NCCL 初始化，几分钟后超时退出。原因：节点间网络不通、init_method的 IP 不可达、或者容器里没放开 IPC 和共享内存。解决：先用nc -zv IP PORT确认端口通，容器启动加--ipc=host --shm-size=8g，多网卡机器设NCCL_SOCKET_IFNAME指定网卡，再用NCCL_DEBUG=INFO打出详细日志看卡在哪一步握手。

现象：多卡能跑，但吞吐只有单卡的 1.3 倍左右。原因：张量并行的通信开销吃掉了收益，卡间走 PCIe 而非 NVLink 时尤其明显；也可能是数据并行下每张卡都在跑完整前向，显存没省、通信还多了。解决：先用nvidia-smi topo -m看卡间互联是 NVLink 还是 PCIe，走 PCIe 的话优先用流水线并行而不是张量并行；同时确认输入数据的分发不是单线程喂给所有卡，dataloader 的num_workers要跟上卡数。

5.4 环境被升级搞坏：驱动、内核、CUDA 的三角关系

现象：某次apt upgrade之后机器重启，nvidia-smi报“Failed to initialize NVML”。原因：内核版本升级了，但 DKMS 没有自动为新内核重新编译显卡驱动模块，模块版本与运行内核不匹配。解决：装linux-headers时确保 DKMS 已启用，升级后手动跑sudo dkms status确认模块对新内核有构建记录；生产机器建议锁定内核版本，别让自动升级乱动。

现象：代码没改，某天开始报CUDA driver version is insufficient for CUDA runtime version。原因：有人装了新版本的 PyTorch，轮子要求的 CUDA 运行时高于驱动支持的上限；或者反过来，驱动被 CUDA 安装包的默认选项覆盖成了旧版本。解决：用nvidia-smi右上角的版本号和torch.version.cuda对比，前者必须大于等于后者；重装 CUDA 时务必带--toolkit不带驱动覆盖，这两个动作记牢能省掉一次重装系统。

6. 监控与验收：DCGM 指标加 Profiler 采样，把黑匣子打开

部署完能跑通只是及格线，能说清楚“为什么慢、慢在哪、还有多少余量”才算交付。DCGM 负责看硬件面，Profiler 负责看算子面，两者配合能把推理服务从黑匣子变成可观测系统。

6.1 DCGM 采集与三个必须看的指标

# 用容器方式跑 DCGM exporter，把 GPU 指标暴露成 Prometheus 格式 docker run -d --gpus all --rm -p 9400:9400 \ nvcr.io/nvidia/cloud-native/dcgm:3.3.1-1-ubuntu22.04 curl -s localhost:9400/metrics | grep -E "DCGM_FI_DEV_(GPU_UTIL|FB_USED|SM_CLOCK)"

--gpus all让容器能看到所有卡，-p 9400:9400暴露指标端口。拉取指标后重点看三个：DCGM_FI_DEV_FB_USED（显存实际占用，用来校验 2.1 节的估算准不准）、DCGM_FI_DEV_GPU_UTIL（利用率，长期低于 50% 说明瓶颈在 CPU 预处理或网络 IO）、DCGM_FI_DEV_SM_CLOCK（降频意味着功耗或温度撞墙，性能问题不在代码）。

6.2 Profiler 采样与验收清单

import torch from torch.profiler import profile, ProfilerActivity with profile(activities=[ProfilerActivity.CPU, 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.generate(**inputs, max_new_tokens=64) prof.step() # 必须调用，否则采样窗口不会推进

wait=1跳过首次冷启动，warmup=1让缓存稳定，active=3采三个窗口，这三个参数不改的话采到的全是冷启动数据，结论会完全跑偏。prof.step()漏写是最常见的错误，表现是 trace 文件为空。导出的结果用 TensorBoard 打开，重点看 attention 和 matmul 两类算子的耗时占比，以及有没有意料之外的cudaMemcpy。

从那以后我每次上线前都强制走一遍这套验收：先在单卡上把 2.1 节的显存估算和实测对一遍，差得超过 15% 就回头查配置；再跑 24 小时长稳压测看显存曲线有没有缓慢爬升，这条曲线比任何日志都诚实。上面这些参数和排查项我对着这份文档核过一次，硬件分级表和踩坑清单可以直接当部署前的对照表用，需要的话可以拿去。希望帮到你。

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