海光DCU部署DeepSeek-R1/V3大模型推理实战指南

简介这份PDF文档面向具备Linux系统管理与深度学习框架经验的IT技术人员和运维人员聚焦海光DCU平台上DeepSeek-R1/V3推理环境的完整搭建流程。内容覆盖DCU驱动与Docker基础依赖安装、模型下载渠道SCNet超算互联网、Huggingface、Modelscope、K100AI与Z100/K100系列不同型号的推理部署以及vllm、ollama、Pytorch三种框架的具体配置方法并延伸至Anythingllm与DCU智能助手的Webuiserver可视化交互环节。资源包为1个PDF文件约1.05MB结构按章节组织从环境依赖、模型获取到推理部署与可视化交互层层递进附有命令行示例、环境变量设置说明及参考链接便于对照实操与排错。目前已有1543人学习适合需要快速完成海光DCU上DeepSeek模型部署与调优的技术人员参考。1. 海光 DCU 上跑 DeepSeek-R1/V3为什么值得折腾以及谁该看如果你手里有一台搭载海光 DCU 的服务器又恰好想把 DeepSeek-R1 或 V3 这类大参数量的自然语言处理模型跑起来做推理服务那你大概率已经发现网上关于 CUDA 生态的部署教程铺天盖地但一到国产加速卡这条线能直接抄作业的完整流程少得可怜。这篇笔记就是冲着这个缺口来的——从驱动检查、容器环境准备、模型权重转换到推理服务启动和并发调优我会把每个环节的命令、参数和踩过的坑都摊开讲。海光 DCU 的软件栈走的是类 ROCm 路线工具链叫 DTKDCU Toolkit底层用 HIP 做异构计算抽象。这意味着你不能直接把 PyTorch 官方 CUDA 版的 wheel 装上去就完事得用适配过的推理框架和算子库。DeepSeek-R1 是推理增强型模型V3 是通用对话底座两者在部署上的核心差异在于R1 对 KV Cache 和长上下文更敏感V3 则更看重吞吐。适合谁看一是有国产化硬件环境、需要私有化部署大模型的团队二是想评估 DCU 到底能不能扛住 70B 级别模型推理的工程师。下面从环境搭建开始一步步来。2. 环境搭建从驱动检查到推理容器就绪2.1 先确认你的 DCU 和 DTK 版本能不能对上很多人翻车就翻在第一步——驱动和 DTK 版本不匹配后面所有操作都是白费。登录服务器后先用hy-smi看卡的状态这个命令类似 NVIDIA 的nvidia-smi能列出 DCU 型号、显存占用、温度和工作状态。# 查看 DCU 硬件状态确认卡被系统识别 hy-smi # 查看 DTK 版本注意输出中的 DTK 版本号 cat /opt/hyhal/version.txt # 查看内核驱动版本 modinfo hydcu | head -5hy-smi输出里重点看三列型号比如 Z100 或 K100、显存总量、当前利用率。如果hy-smi报错或者显示不出卡先检查/dev/kfd和/dev/dri设备节点是否存在。DTK 版本决定了你能用哪个版本的 PyTorch 适配包常见对应关系是 DTK 23.10 配 PyTorch 2.1DTK 24.04 配 PyTorch 2.2 以上。版本对不上时推理框架加载算子库会直接 segfault而且报错信息往往指向一个完全不相关的地方排查起来很折磨。提示hy-smi的显存显示和实际可用显存有差异DCU 会预留一部分做 ECC 和系统管理实际可用大约是标称值的 92% 到 95%。2.2 拉取适配 DCU 的推理镜像并验证 PyTorch 可用最省事的做法是用官方或社区维护的 DCU 适配容器镜像里面已经装好了 DTK 运行时、HIP 库和适配版 PyTorch。如果你所在环境不能拉公网镜像那就得在本地用 Dockerfile 自己构建核心是把 DTK 的 apt 源配好然后装pytorch-dcu和torchaudio-dcu这类专用包。# 拉取适配 DCU 的 PyTorch 基础镜像以实际可用的镜像名为准 docker pull registry.example.com/dcu/pytorch:2.2-dtk24.04 # 启动容器挂载 DCU 设备节点和模型目录 docker run -it --rm \ --device/dev/kfd \ --device/dev/dri \ --group-add video \ --shm-size64g \ -v /data/models:/models \ -v /data/workspace:/workspace \ registry.example.com/dcu/pytorch:2.2-dtk24.04 \ /bin/bash--device两个参数是把 DCU 的计算和渲染节点透传给容器--group-add video确保容器内用户有权限访问设备。--shm-size设大是因为大模型推理时进程间通信和共享内存用量很高默认 64MB 会在加载 70B 模型时直接爆掉。进容器后跑一段 Python 验证import torch # 检查 DCU 是否被 PyTorch 识别 print(可用设备数:, torch.cuda.device_count()) print(设备名称:, torch.cuda.get_device_name(0)) # 做一次简单的张量计算确认算子能跑通 x torch.randn(1024, 1024).cuda() y torch.mm(x, x) print(矩阵乘法结果形状:, y.shape)如果device_count()返回 0八成是设备节点没挂进去或者容器内用户不在 video 组。如果矩阵乘法报 HIP 相关错误那就是 DTK 运行时和 PyTorch 适配包版本不匹配得回去对版本号。2.3 装推理框架vLLM 的 DCU 适配版怎么选DeepSeek-R1/V3 这种量级的模型用 HuggingFace Transformers 直接generate推理吞吐太低生产环境基本都上 vLLM 或类似的高吞吐推理引擎。DCU 上有适配过的 vLLM 分支核心改动在注意力算子和 KV Cache 管理这两块把原本调 CUDA 的地方换成了 HIP 调用。# 安装 DCU 适配版 vLLM注意不要直接 pip install vllm pip install vllm-dcu0.4.2 --extra-index-url https://pypi.example.com/dcu # 验证 vLLM 能否正确加载 DCU 后端 python -c from vllm import LLM; print(vLLM import OK)这里的关键参数是版本号。vllm-dcu的版本和上游 vLLM 不是一一对应的0.4.2 可能对应上游 0.4.0 的 API。装错版本会出现AttributeError: module vllm has no attribute LLM这种让人摸不着头脑的报错。我一般会先pip show vllm-dcu看它依赖的torch版本确认和容器里的 PyTorch 一致再往下走。3. 模型准备权重下载、格式转换与显存估算3.1 DeepSeek-R1 和 V3 的权重结构差异DeepSeek-R1 和 V3 都是 MoE混合专家架构但 R1 在推理时会激活更多的专家层导致单次前向计算的显存峰值更高。V3 的专家路由相对稀疏吞吐更好但单次推理的延迟略高。下载权重时要注意官方仓库里通常有 FP8 和 BF16 两个版本DCU 对 BF16 的支持更成熟FP8 需要额外的量化算子支持不是所有 DTK 版本都覆盖。# 用 huggingface-cli 下载权重需提前配置好镜像源或本地缓存 huggingface-cli download deepseek-ai/DeepSeek-R1 \ --local-dir /models/DeepSeek-R1 \ --local-dir-use-symlinks False # 查看权重文件总大小估算显存需求 du -sh /models/DeepSeek-R1下载完后检查目录里有没有config.json、tokenizer.json和一堆.safetensors文件。如果只有.bin格式的 PyTorch 权重vLLM 也能加载但加载速度会慢不少。MoE 模型的显存估算不能只看参数量得把激活的专家数乘进去。以 671B 总参数的 V3 为例BF16 下全量加载需要约 1.3TB 显存显然单卡放不下必须做张量并行或者量化。3.2 用张量并行把大模型切到多张 DCU 上张量并行TP是把模型的权重矩阵按维度切分到多张卡上每张卡只存一部分计算时通过集合通信把结果拼起来。DCU 之间用 HCCL 做通信类似 NVIDIA 的 NCCL。启动 vLLM 时用--tensor-parallel-size指定卡数。# 用 4 张 DCU 做张量并行启动 R1 的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /models/DeepSeek-R1 \ --tensor-parallel-size 4 \ --dtype bfloat16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --port 8000--tensor-parallel-size 4表示用 4 张卡这个数必须是注意力头数的约数否则切分时会报维度不匹配。--max-model-len控制最大上下文长度R1 支持到 64K 甚至更长但设得越大 KV Cache 占用越高。--gpu-memory-utilization 0.90是让 vLLM 最多用 90% 的显存留一点给系统和其他进程。如果启动时报 HCCL 通信超时先检查hy-smi里卡之间的拓扑连接再确认容器有没有挂载/dev/hccl相关设备。3.3 显存不够时的量化方案怎么选单机 8 卡 DCU 跑 V3 全量 BF16 仍然吃力这时候得上量化。常见做法是 GPTQ 或 AWQ 的 4bit 量化能把显存占用压到 BF16 的四分之一左右。DCU 上 AWQ 的算子适配比 GPTQ 更完整我一般优先选 AWQ。from awq import AutoAWQForCausalLM from transformers import AutoTokenizer # 加载原始模型并做 AWQ 量化需要足够的 CPU 内存 model_path /models/DeepSeek-V3 quant_path /models/DeepSeek-V3-AWQ model AutoAWQForCausalLM.from_pretrained(model_path) tokenizer AutoTokenizer.from_pretrained(model_path) # 量化配置4bit分组大小 128 quant_config {zero_point: True, q_group_size: 128, w_bit: 4, version: GEMM} model.quantize(tokenizer, quant_configquant_config) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)w_bit: 4是权重量化位数q_group_size: 128是分组量化的大小组越小精度越高但元数据开销越大。量化过程本身很吃 CPU 内存V3 这个量级至少准备 512GB 以上的内存否则会在量化中途 OOM。量化完的模型用 vLLM 加载时把--dtype改成float16并加上--quantization awq参数。4. 推理服务调优并发、KV Cache 与长上下文处理4.1 并发请求下怎么调 batch size 和 KV CachevLLM 的核心优势是 PagedAttention把 KV Cache 按页管理避免显存碎片。但页大小和最大并发数需要根据实际请求模式调。默认的--max-num-seqs是 256在 DCU 上这个值偏大容易导致显存不够触发抢占。# 调整并发相关参数适配 DCU 显存 python -m vllm.entrypoints.openai.api_server \ --model /models/DeepSeek-R1-AWQ \ --tensor-parallel-size 4 \ --quantization awq \ --max-model-len 16384 \ --max-num-seqs 64 \ --block-size 32 \ --gpu-memory-utilization 0.88 \ --port 8000--max-num-seqs 64把同时处理的请求数压到 64减少 KV Cache 峰值。--block-size 32是 PagedAttention 的页大小32 在 DCU 上比默认的 16 更省元数据开销但内部碎片会多一点。实际调的时候我会先用--max-num-seqs 32跑一轮压测看hy-smi的显存曲线如果峰值离上限还有余量再往上加。4.2 长上下文场景下 R1 的 KV Cache 优化R1 做推理链任务时上下文经常拉到 32K 以上KV Cache 会线性增长。除了调--max-model-len还可以开--enable-prefix-caching让相同前缀的请求复用 KV Cache。# 开启前缀缓存适合系统提示词固定的场景 python -m vllm.entrypoints.openai.api_server \ --model /models/DeepSeek-R1-AWQ \ --tensor-parallel-size 4 \ --quantization awq \ --max-model-len 32768 \ --enable-prefix-caching \ --max-num-seqs 32 \ --port 8000--enable-prefix-caching对多轮对话和固定 system prompt 的场景提升明显但如果每个请求的 prompt 都不一样反而会增加哈希计算的开销。判断标准是看请求之间有没有公共前缀有就开没有就别开。另外--max-model-len设到 32768 时KV Cache 单请求占用会到 GB 级别--max-num-seqs必须相应往下压否则显存直接爆。4.3 用 benchmark 脚本测出真实吞吐和延迟调完参数得用数据说话。vLLM 自带 benchmark 脚本可以模拟并发请求测吞吐和 TTFT首 token 延迟。# 跑 benchmark模拟 50 个并发请求 python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --host 127.0.0.1 \ --port 8000 \ --model /models/DeepSeek-R1-AWQ \ --dataset-name sharegpt \ --num-prompts 200 \ --request-rate 10--request-rate 10表示每秒发 10 个请求--num-prompts 200是总请求数。输出里重点看Throughput每秒输出 token 数和TTFT。DCU 上如果 TTFT 超过 2 秒通常是 KV Cache 不够导致请求排队得降--max-num-seqs或者加卡。如果吞吐上不去但 TTFT 正常那瓶颈可能在 HCCL 通信检查卡间带宽是不是跑满了。5. 避坑与排查DCU 部署 DeepSeek 的五个血泪教训5.1 坑一hy-smi 正常但 PyTorch 认不到卡现象是hy-smi能列出 DCU但 Python 里torch.cuda.device_count()返回 0。原因通常是容器启动时没挂/dev/kfd或者容器内用户不在video组。解决方法是重新启动容器确认--device/dev/kfd --device/dev/dri --group-add video三个参数都带上进容器后用ls -l /dev/kfd确认设备节点存在且权限正确。5.2 坑二加载模型时 HCCL 通信超时多卡启动时卡在Initializing HCCL然后超时退出。原因是卡间拓扑没被正确识别或者防火墙挡了 HCCL 用的端口。先跑hy-smi topo -m看卡间连接矩阵确认所有卡之间都有链路。如果是容器环境检查有没有加--networkhostHCCL 默认走主机网络bridge 模式下会通不了。5.3 坑三AWQ 量化后推理结果乱码量化完的模型输出重复或乱码大概率是量化时的校准数据不对。AWQ 需要一批校准数据来统计激活分布如果校准集和实际任务差异太大量化误差会累积。解决方法是换用和业务场景接近的校准数据或者把q_group_size从 128 降到 64牺牲一点压缩率换精度。5.4 坑四长上下文请求把显存打爆--max-model-len设了 32768但实际请求到 20K 左右就 OOM。原因是 vLLM 的显存预分配是按max-model-len算的但 PagedAttention 的页管理有额外开销。解决方法是把--gpu-memory-utilization从 0.90 降到 0.85给 KV Cache 留更多余量同时把--max-num-seqs再压一档。5.5 坑五升级 DTK 后推理框架全挂手贱升级了 DTK 版本结果 vLLM 加载算子库时报符号未定义。原因是 vLLM 的 DCU 适配版是针对特定 DTK 版本编译的DTK 升级后 ABI 不兼容。解决方法是回退 DTK 到适配版本或者等 vLLM 发布对应新 DTK 的适配包。升级前一定先看推理框架的 release note 里写的 DTK 版本要求。6. 进阶技巧用投机采样把 R1 的推理速度再提一档R1 这类推理增强模型有个特点输出里大量 token 是「确定性」的推理步骤比如数学符号和逻辑连接词。这种场景特别适合投机采样Speculative Decoding——用一个小模型先草拟多个 token大模型再并行验证验证通过就一次性接受多个 token相当于把串行生成变成半并行。在 DCU 上配投机采样需要一个小模型做 draft model。选型上 draft model 要和目标模型同 tokenizer否则 token 对不齐。常见做法是用同系列的 1.5B 或 7B 小模型做 draft。# 启动带投机采样的推理服务 python -m vllm.entrypoints.openai.api_server \ --model /models/DeepSeek-R1-AWQ \ --tensor-parallel-size 4 \ --quantization awq \ --speculative-model /models/DeepSeek-R1-Distill-1.5B \ --num-speculative-tokens 5 \ --max-model-len 16384 \ --port 8000--speculative-model指定 draft model 路径--num-speculative-tokens 5是每次草拟的 token 数。这个数不是越大越好设太大 draft model 的命中率会下降反而浪费算力。我一般从 5 开始试看 benchmark 里的acceptance rate低于 0.6 就往下调高于 0.8 可以试着加到 7 或 8。验证投机采样有没有生效看 vLLM 的日志里有没有Speculative decoding enabled和每轮的接受率统计。如果接受率一直很低检查 draft model 和目标模型的 tokenizer 是不是完全一致——哪怕词表差一个 token接受率都会崩。另外 DCU 上跑投机采样时draft model 和目标模型会争抢显存--gpu-memory-utilization要相应下调我一般设 0.82 左右。最后一个习惯每次调完参数我都会把hy-smi的显存曲线和 benchmark 的吞吐数据记到同一个表格里跑上五六轮再决定最终配置。DCU 上的性能表现和驱动版本、容器配置、甚至机房温度都有关系不记数据光凭感觉调很容易在某个版本升级后一夜回到解放前。希望帮到你。本文还有配套的精品资源点击获取