企业官网建设流程全解析

简介：《DeepSeek本地部署的硬件要求与环境配置》是一份面向大模型开发者、运维人员及企业技术团队的PDF文档，围绕私有化部署DeepSeek时的硬件选型与软件环境搭建展开，覆盖个人学习测试到企业级生产部署等不同场景。文档共1个PDF文件，资源包约274KB，篇幅精炼，便于快速查阅与归档。内容从基础开发测试环境与生产级集群配置的分级建议切入，对处理器、显卡显存、内存容量、存储介质与网络带宽等资源规划给出最低与推荐配置对照，并延伸至操作系统准备、计算加速工具链、深度学习框架安装、分布式训练参数、模型量化加载、显存分级卸载及资源监控与性能分析等关键环节，帮助读者建立从选型到调优的完整部署知识框架。已有2219人学习，适合需要评估本地部署可行性、制定硬件预算或梳理环境配置要点的技术人员参考。

1. 从一张 24GB 显卡的翻车说起：这份配置单解决什么问题

有位做私活的读者发来截图：RTX 3090 24GB，加载一个 32B 的 4-bit 量化模型，进度条走到九成，CUDA out of memory 直接糊脸，而他手里那张配置单上明明白白写着「24GB 可用」。这种翻车我见得太多了——显存够不够，从来不是拿参数量除以一个系数就能算出来的，权重、KV cache、激活值、框架预留这四块加起来才是真实占用。这份《DeepSeek 本地部署的硬件要求与环境配置.pdf》的价值，就在于把这条链路拆得足够细：从 7B 到 32B 以上的三档硬件配置，到 CUDA 12.1 与 cuDNN 的安装验证，再到 4-bit 量化、分级卸载、DCGM 监控，一路排布到生产集群。它适合的是已经决定把 DeepSeek 放到自己机器上、需要一份能逐项核对参数的从业者；纯新手拿它当第一份教程会有点吃力，因为它默认你分得清「装好了」和「跑得动」。

2. 硬件分级怎么定：显存系数、内存倍率与三档配置

采购单是最容易出事的地方。多买一张卡预算翻倍，少买一张卡上线延期，中间没有太多试错空间。这一章把配置单背后的计算逻辑摊开，让每个人都能拿自己的模型尺寸算出需要的机器。

2.1 每 10 亿参数 1.2GB 这条经验线，边界在哪

原文给的关键说明是「GPU 显存需至少容纳模型参数：每 10 亿参数约需 1.2GB 显存（FP16 精度）」。这条线我一直在用，但必须说清楚它的适用边界，否则就是给自己挖坑。

FP16 精度下，1 个参数占 2 字节，10 亿参数的理论权重就是 2GB。为什么经验值是 1.2GB？因为这条线来自实践中的混合口径：一部分场景是权重以 FP16 存放但部分层做了量化，一部分场景是统计时把共享权重和非活跃参数排除掉了。它更像一个「下界估计」，不是「够用估计」。我自己的习惯是：拿 1.2GB 当作权重占用基准，然后单独把 KV cache 和框架预留加上去，最后再乘一个 1.1～1.2 的碎片系数。直接拿「参数量 × 1.2GB」去对显存，是我见过最常见的翻车起点。

真正容易被忽略的是 KV cache。它的量级经常追平甚至超过权重。以 7B 模型为例，32 层、hidden 4096、32 个注意力头、head_dim 128，FP16 推理，batch 4、上下文 4096：

# KV cache 显存估算 # 2 表示 K 和 V 两份；2 表示 FP16 每元素 2 字节 n_layers = 32 n_heads = 32 head_dim = 128 seq_len = 4096 batch = 4 bytes_per_elem = 2 kv_bytes = 2 * n_layers * n_heads * head_dim * seq_len * batch * bytes_per_elem print(f"KV cache: {kv_bytes / 1024**3:.2f} GB") # 约 8.00 GB

这段代码里每个因子都有实际含义：n_layers是每个 token 在每一层都要存一份 KV，2是 K 和 V 各一份，batch与seq_len是线性放大项。算完你会发现，权重 14GB 的 7B 模型，光 KV cache 就吃掉 8GB，两者相加已经贴着 24GB 的边了，还没算激活值和框架自身的预留。如果模型用了 GQA（分组查询注意力），KV 头数远小于注意力头数，这一项会显著下降，把n_heads换成实际的 KV 头数即可。

提示：估算时用你打算上线的最大 batch 和最大上下文长度，而不是测试时的 batch=1、seq=512。很多线上事故都是压测时按短上下文算显存，实际请求一到长文本就炸。

2.2 三档配置单与它们各自的能力边界

原文把场景分成基础开发测试（7B 以下）和生产级部署（32B 以上）两档，中间其实还有一档被很多人跳过——单卡 24GB 到 48GB 的「验证档」，用来跑通全流程再决定要不要上集群。我把三档整理成一张对照表，方便直接对着自己的需求选：

表里有两个点值得单独说。第一是内存与显存的比例关系，原文建议「内存容量建议为显存的 2 倍以上，用于缓存中间计算数据」。这个 2 倍在分级卸载（把部分参数或优化器状态放到 CPU 内存）场景下会显得不够，因为卸载到内存的东西是实打实驻留的，我一般会把比例抬到 2.5～3 倍，宁可内存买便宜点的大容量，也别在显存吃紧时没地方卸。第二是存储，NVMe 不是可选项——模型权重加载速度直接决定你的服务冷启动时间，32B 模型 FP16 权重几十 GB，SATA 盘的加载时间能让灰度发布变成事故。

至于原文给出的生产环境性能指标——输入长度 512 tokens 时推理延迟 <200ms、吞吐 >1000 requests/sec——这两个数字要在批量处理优化的前提下才有意义。单条请求低延迟和高吞吐在很多实现上是互相拉扯的，先把 batch 策略定下来，再去看指标是否达标，不要拿单条串行测试的结果去对标吞吐指标。

2.3 用一段脚本把配置单算成自己的

光看表格不够，实际选型时要把自己的模型参数、上下文长度、batch 一起代进去。下面这段脚本把权重、KV cache、激活预留三块拼在一起，给出一个保守的显存需求：

def estimate_vram(params_b, n_layers, n_kv_heads, head_dim, seq_len=4096, batch=1, dtype_bytes=2, quant_bits=None): """ params_b : 参数量，单位十亿，如 7 / 32 n_layers : 模型层数 n_kv_heads : KV 头数（GQA 时远小于注意力头数） head_dim : 每个头的维度 quant_bits : None 表示不量化；4 表示 4-bit 量化 """ if quant_bits is None: weight_gb = params_b * 1.2 # 经验系数，FP16 口径的下界 else: weight_gb = params_b * (quant_bits / 8) * 1.1 # 量化权重 + 反量化开销 kv_gb = (2 * n_layers * n_kv_heads * head_dim * seq_len * batch * dtype_bytes) / 1024**3 reserve_gb = max(2.0, weight_gb * 0.15) # 激活值与框架预留 total = (weight_gb + kv_gb + reserve_gb) * 1.1 # 碎片系数 print(f"权重 {weight_gb:.1f}G | KV {kv_gb:.1f}G | 预留 {reserve_gb:.1f}G " f"=> 建议显存 ≥ {total:.1f}G") estimate_vram(7, 32, 32, 128, seq_len=4096, batch=4) estimate_vram(32, 64, 8, 128, seq_len=8192, batch=1, quant_bits=4)

参数说明几句：1.2这个系数是原文给的 FP16 经验值，量化分支里用quant_bits / 8换算字节数并乘 1.1 补偿反量化时的临时张量；reserve_gb取权重占用 15% 与 2GB 的较大值，是为了覆盖小模型也躲不掉的固定开销；最后的1.1是显存碎片系数，跑长稳服务时建议抬到 1.15。用这段脚本算出来的数字，再对照 2.2 的表格去选卡，比拍脑袋靠谱得多。

3. 系统与加速环境：内核模块、CUDA 12.1 与 cuDNN 验证

硬件到位之后，翻车概率最高的环节其实是软件。驱动、CUDA 运行时、cuDNN、PyTorch 编译版本这四者的版本咬合关系，一度让我怀疑是玄学。这一章把配置顺序和验证方法固定下来，减少反复重装的次数。

3.1 Linux 侧的四项必改配置

原文给的 Ubuntu 方案里有四行命令，看着简单，但每一行对应的都是一类真实故障：

# 1. 补齐内核额外模块，确保 CUDA 内核模块能被正常加载 sudo apt install -y linux-modules-extra-$(uname -r) # 2. 降低交换倾向，避免推理过程中被换出导致延迟抖动 echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 3. 建立专用部署目录 sudo mkdir -p /opt/deepseek sudo chmod 777 /opt/deepseek # 4. 提高文件句柄与锁内存上限（模型加载会打开大量文件） echo "* soft nofile 65535" | sudo tee -a /etc/security/limits.conf echo "* hard nofile 65535" | sudo tee -a /etc/security/limits.conf

第一条对应的是驱动装完、nvidia-smi能出表，但 PyTorch 里torch.cuda.is_available()返回 False 的情况——内核模块没跟上当前内核版本，重启后模块加载失败。第二条的swappiness=10值得多说一句：大模型推理时进程常驻内存很大，如果系统把一部分页换到磁盘，第一次请求会突然慢几百毫秒，表现为「跑一段就卡一下」的抖动，排查时很容易误判成 GPU 降频。第三条的目录权限看似无关紧要，实际是多用户环境下模型缓存路径写不进去的常见原因。第四条是我自己加的，模型权重加载时并发打开的文件数很容易顶到默认 1024 的上限。

另外原文提到的vm.swappiness写法和额外模块安装，建议在装机脚本里固化下来，而不是每次重装都手敲。我一般的做法是把这几行放进一个bootstrap.sh，新机器一条命令跑完，避免漏项。

3.2 CUDA 12.1 与 cuDNN 的安装顺序和验证脚本

原文给的安装方式是静默安装，这条路适合批量部署，但有几个参数要改：

# 下载并静默安装 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装示例代码，别嫌它占地方，后面验证 GPU 通信是否正常时用得上。--silent表示无交互，适合脚本化。

装完之后别急着装框架，先把环境变量和验证走一遍：

# 写入环境变量（注意路径里的 cuda-12.1 与实际安装目录一致） 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 # 验证驱动与运行时 nvidia-smi # 右上角显示的 CUDA Version 是驱动支持的最高版本 nvcc -V # 显示的是实际安装的工具链版本

这里有个高频误解：nvidia-smi右上角的 CUDA Version 不是「已安装的 CUDA 版本」，而是驱动能支持的最高运行时版本。很多人看到它显示 12.4 就以为自己装的是 12.4，结果nvcc -V显示 12.1，两边的版本在编译扩展时对不上。判断标准永远以nvcc -V为准。

cuDNN 的验证用原文那段 Python 就够，但我会补一行版本对比：

import torch print(torch.__version__) # 框架版本 print(torch.version.cuda) # 框架编译时链接的 CUDA 版本 print(torch.cuda.is_available()) # 应为 True print(torch.backends.cudnn.version()) # 应 >= 8902 print(torch.cuda.get_device_capability()) # 返回 (major, minor)，如 (8, 0)

torch.version.cuda和nvcc -V显示的版本不一致是正常的，前者是预编译轮子链接的运行时版本，只要主版本号对得上（都是 12.x）通常不影响。torch.cuda.get_device_capability()的输出要记下来，下一章编译 FlashAttention 时直接用它决定架构参数，写错了就是编译几十分钟然后运行时报错。

3.3 WSL2 方案的适用边界

原文给的 Windows 兼容方案是 Windows 11 Pro 22H2 以上 + WSL2 + 显卡驱动 535.54.03 以上。这条路能走通，但要清楚它的边界在哪。

第一，WSL2 的显存是动态分配的，不会独占。宿主机上开着浏览器、开着一堆窗口，WSL 里能拿到的显存就会被挤压，表现为「同样的配置，昨天能跑今天 OOM」。我一般会在.wslconfig里显式限制内存上限，避免 WSL 把宿主内存吃干净导致整机卡死。

第二，文件 I/O 跨文件系统时性能断崖。把模型权重放在 Windows 盘符下、从 WSL 里访问/mnt/c/...，加载速度可能只有原生 ext4 的几分之一。正确做法是把权重放在 WSL 的 Linux 文件系统内，或者干脆用一块独立盘挂进去。

第三，多卡和 NVLink 在 WSL2 下基本没有意义，分布式训练也别在这上面折腾。它的定位很明确：个人开发机上跑通代码逻辑、验证量化效果，跑通了再迁到 Linux 服务器。指望它做生产部署，是从一开始就选错了路。

注意：WSL2 下nvidia-smi显示的是宿主驱动的能力，但 CUDA 工具链是装在 WSL 发行版内的，两套东西要分别确认，别混着排查。

4. 框架与模型配置：PyTorch 轮子、4-bit 量化与分级卸载

环境通了之后，重头戏是把模型真正跑起来。这一章的核心是把「能加载」和「能稳定推理」之间的差距填上，重点在三个地方：框架轮子的选择、量化配置的四个参数、卸载策略的开关组合。

4.1 PyTorch 轮子与 FlashAttention-2 的编译参数

原文给的安装命令是针对 80GB 卡优化的版本：

# 安装与 CUDA 12.1 匹配的 PyTorch 轮子 pip install torch==2.1.0+cu121 --extra-index-url https://download.pytorch.org/whl/cu121 # 编译安装 FlashAttention-2 MAX_JOBS=4 TORCH_CUDA_ARCH_LIST="8.0" pip install flash-attn==2.3.3

--extra-index-url指向官方的预编译轮子仓库，版本号里的+cu121后缀必须和你的 CUDA 主版本对齐，装成+cu118会出现「导入成功但一调用就报符号找不到」的诡异现象，排查起来很费时间。

重点说TORCH_CUDA_ARCH_LIST="8.0"。这个值是计算架构代号，8.0 对应 80GB 那一代数据中心卡。如果你的卡是消费级的 30 系或 40 系，架构分别是 8.6 和 8.9，照抄 8.0 会得到一份「能编译、能安装、一运行就 illegal memory access」的扩展。正确做法是先用上一章的get_device_capability()查出来，再填进去。多卡型号混插时可以用分号分隔，比如"8.0;8.6"，代价是编译时间翻倍。

MAX_JOBS=4控制并行编译的进程数。这个参数不是越大越好，编译 FlashAttention 时每个进程都吃大量内存，MAX_JOBS开太大容易在编译阶段被 OOM killer 干掉，症状是编译卡住然后进程无声消失。内存 32GB 的机器上 4 是稳妥值，64GB 以上可以开到 8。

编译完成后必须验证，不能装完就当成功：

import torch from flash_attn import flash_attn_func q = torch.randn(2, 128, 8, 64, dtype=torch.float16, device="cuda") out = flash_attn_func(q, q, q) print(out.shape) # 期望 (2, 128, 8, 64)

跑通这五行，才算 FlashAttention 真的可用。跑不通但没报错的情况极少，通常是版本不匹配被静默回退了。

4.2 4-bit 量化配置：四个参数逐个拆

原文给的 4-bit 量化加载配置很短，但每个参数都会实质影响效果和显存：

import torch from transformers import AutoModelForCausalLM, BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, # 总开关：权重以 4-bit 存放 bnb_4bit_use_double_quant=True, # 二次量化：对量化常数再量化 bnb_4bit_quant_type="nf4", # 量化数据类型：正态分布友好的 4-bit bnb_4bit_compute_dtype=torch.bfloat16 # 计算时的数据类型 ) model = AutoModelForCausalLM.from_pretrained( "deepseek-ai/deepseek-32b", quantization_config=bnb_config, device_map="auto" )

load_in_4bit打开后，权重占用大约降到 FP16 的四分之一，但要注意它只压权重，KV cache 和激活值不受影响——这就是为什么 2.1 里那个估算脚本要把 KV 单独算。

bnb_4bit_use_double_quant是对量化过程中产生的常数（scale、zero-point）再做一次量化，能再省下每个参数约 0.37 bit 的开销。在 32B 这个量级上大概能省出 1.5GB 左右，属于白捡的收益，一般没有理由关掉。

bnb_4bit_quant_type="nf4"用的是正态分布分位数量化，对权重近似正态分布的模型更友好，精度损失比朴素的 fp4 小。这个参数基本没有调整空间，默认就是它。

bnb_4bit_compute_dtype是最容易翻车的一个。设成float16时，反量化后的中间结果在数值范围大的层上会溢出成 inf，表现出来就是「模型能加载、能推理，但输出全是重复的胡话或者直接空字符串」。改成bfloat16之后，同样的数值范围能容纳得下。如果你的卡架构不支持 bf16（计算能力 8.0 以下的部分型号），只能用 fp16，那就得配合梯度检查点或者调小 batch 来规避。

提示：量化后一定要跑一组固定 prompt 做效果基线对比，别只看困惑度数字。我见过量化后困惑度只涨了 2%，但指令跟随能力明显下降的情况，这种只能靠人工看输出发现。

device_map="auto"会自动把层分配到可用设备上。这个参数很方便，也是很多诡异问题的来源：它会把放不下的层甩到 CPU 上，于是模型「加载成功」但推理速度慢十倍，而日志里一句警告都没有。判断方法是加载完打印一下设备分布：

from collections import Counter devices = Counter(p.device.type for p in model.parameters()) print(devices) # 期望 {'cuda': N}，出现 'cpu' 就说明被卸载了

出现cpu说明显存确实不够，要么降 batch、要么缩短上下文、要么换更小的模型，不要指望靠device_map硬撑。

4.3 分级卸载的参数组合与代价

显存实在不够时，原文给的分级卸载是最后一张牌：

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对应四张卡，--mixed_precision bf16让计算走 bf16 而不是 fp32，--gradient_accumulation_steps 8用累积梯度换取更小的等效 batch。真正的卸载发生在后两行：参数卸载到 NVMe、优化器状态卸载到 CPU 内存。

这套组合的代价必须说清楚。参数卸载到 NVMe 意味着每次前向都要从盘上读权重，PCIe 带宽再高也拼不过显存，实测吞吐会掉一个数量级。它适合的是「显存不够但又必须跑起来」的场景，比如在单机上验证一个 32B 模型的效果，不适合线上服务。优化器状态卸载到 CPU 只对训练有意义，纯推理时这一项没作用，别照抄。

配套的accelerate_config.yaml也要对得上：

compute_environment: LOCAL_MACHINE distributed_type: MULTI_GPU num_processes: 4 mixed_precision: bf16 gpu_ids: all

distributed_type在多卡时必须显式写MULTI_GPU，写成NO会导致只有一张卡被用上而其余闲置。gpu_ids: all比列举具体编号更省事，但机器上有其他任务占卡时要改成显式列表，避免抢卡。

5. 避坑与排查：五条用重装换来的记录

前面四章讲的是「应该怎么配」，这一章讲「配完为什么还是不对」。下面五条都是我自己或者身边人真实撞过的，按现象、原因、解决三段写，遇到同类问题可以直接对照。

5.1 装完 FlashAttention 报 illegal memory access

现象：pip install flash-attn一路绿灯，import也正常，第一次前向就抛 CUDA illegal memory access，换回普通注意力就没事。

原因：TORCH_CUDA_ARCH_LIST写死成"8.0"，而实际卡是 8.6 或 8.9 架构。编译出来的 PTX/cubin 与硬件指令集不匹配，在特定 kernel 上才暴露，所以表现为「有时能跑有时炸」。这个坑最气人的地方在于它不报编译错误。

解决：先用torch.cuda.get_device_capability()查到真实架构，重新编译时把TORCH_CUDA_ARCH_LIST设成对应值，多机型混插用分号分隔。改完记得先pip uninstall flash-attn清干净，再重装，否则缓存的旧轮子会被复用。

5.2 显存明明够，还是 CUDA out of memory

现象：nvidia-smi看显存还剩 6GB，推理一跑就 OOM，报错信息里的申请量大得离谱。

原因：三种可能。一是device_map="auto"已经把部分层甩到 CPU，GPU 侧的层反而因为要接收跨设备传输的张量而产生额外峰值；二是 KV cache 按服务端配置的最大上下文预分配，而不是按当前请求长度；三是显存碎片，长时间跑之后没有足够大的连续块。

解决：先打印设备分布确认没有 CPU 卸载；再把max_position_embeddings或服务框架里的上下文上限调到真实业务需要的长度；最后在服务启动时加PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True缓解碎片。三步按顺序排，别一上来就怀疑显存不够。

5.3 量化后输出重复、乱码或空字符串

现象：4-bit 加载成功，推理不报错，但输出质量断崖式下降，短 prompt 正常、长 prompt 崩。

原因：bnb_4bit_compute_dtype设成了float16，反量化后的中间激活在数值范围大的层上溢出成 inf，softmax 之后概率分布被破坏。序列越长，累积的激活值越大，所以表现为「短的好、长的坏」。

解决：改成torch.bfloat16。硬件不支持 bf16 时，回退方案是降低 batch、缩短上下文、或者换用 8-bit 量化。改完拿同一组 prompt 做前后对比，不要只看困惑度。

5.4 多机多卡训练卡在初始化，日志无输出

现象：accelerate launch之后进程全部挂起，nccl相关日志刷屏或者干脆没有，几十分钟后超时退出。

原因：init_method里的地址写成了127.0.0.1，或者端口被别的任务占用。原文示例里的tcp://192.168.1.100:23456是主节点真实 IP，多机场景下必须用这个而不是回环地址。另外防火墙拦掉 NCCL 使用的端口段也会造成同样的静默挂起。

解决：确认主节点 IP 从各节点都能 ping 通、端口未被占用、防火墙放行对应端口段。调试时设置NCCL_DEBUG=INFO打开日志，能看到它卡在建立连接还是卡在传输。

5.5 推理延迟忽高忽低，隔一阵就抖一下

现象：压测时 P50 延迟很稳，P99 突然飙到几倍，且没有规律。

原因：vm.swappiness没调，系统在内存压力下把部分页换到磁盘，第一次访问触发缺页中断；或者别的进程在周期性占用 GPU（比如监控采集）；又或者是温度墙导致降频。

解决：按 3.1 把swappiness降到 10 并写进sysctl.conf持久化；用nvidia-smi -q -d PERFORMANCE看是否有降频原因；把监控采集频率从秒级降到十秒级。三个方向逐一排除，通常前两个就能定位。

注意：这五条里有三条的表现是「不报错但不对」，这类问题最耗时间。养成装完就跑一组固定输入做基线对比的习惯，比出问题再回头查要省得多。

6. 监控与验收：上线前那套固定动作

配置跑通不等于可以上线，中间还差一套可观测性。DCGM 是采集 GPU 指标的标准做法，起一个容器就能把温度、功耗、显存、SM 利用率、ECC 错误全部暴露成 Prometheus 指标：

docker run -d --gpus all --rm -p 9400:9400 \ nvcr.io/nvidia/cloud-native/dcgm:3.3.1-1-ubuntu22.04

容器起来后，Prometheus 侧按原文的 job 配置抓取即可：

scrape_configs: - job_name: 'dcgm' static_configs: - targets: ['localhost:9400']

这一步的价值不在于「有监控」，而在于把几个关键指标和故障对应起来。显存利用率长期贴顶说明 batch 或上下文配置过激；SM 利用率长期低于 40% 而请求排队，说明瓶颈在 CPU 预处理或网络而非 GPU；温度接近阈值时开始降频，表现为吞吐阶梯式下滑；ECC 错误计数非零要立刻安排换卡。我在验收时一般看这四个，比看平均延迟有用得多。

单请求级别的性能剖析用 Profiler，原文那段 schedule 参数值得解释一下：

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是跳过第一个 step 不采样，warmup=1是第二个 step 只跑不记录，active=3是记录接下来的三个 step。为什么要 wait 和 warmup？因为第一次前向包含内核自动调优、内存池分配、cuDNN 算法选择，这些一次性开销会污染数据，不排掉的话你会看到一堆莫名其妙的耗时峰值。record_shapes=True会记录张量形状，代价是 trace 文件变大，排查显存问题时这个信息很关键。

上线前的验收清单我固定成这几项：固定 prompt 集的输出质量与量化前对比；最大上下文加最大 batch 的显存水位是否留够 15% 余量；连续压测两小时的 P99 延迟是否平稳；DCGM 四项关键指标是否在合理区间；Profiler trace 里是否存在异常长的单算子。这套动作走完，我心里才有底。

说个自己的教训。早期部署时我图省事，装完环境跑通一次 demo 就交付了，结果对方在真实流量下跑了三天，延迟一路劣化到不可用，回头排查发现是显存碎片加上swappiness没调，两个问题叠在一起。从那以后我每次部署完都强制走一遍这套验收动作，尤其是长时间压测那一步——短跑能过不代表长跑能过。希望帮到你。

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