企业官网建设流程全解析

简介：这份PDF文档面向具备Linux系统管理与深度学习框架经验的IT技术人员和运维人员，聚焦海光DCU平台上DeepSeek-R1/V3推理环境的完整搭建流程。内容覆盖DCU驱动与Docker基础依赖安装、模型下载渠道（SCNet超算互联网、Huggingface、Modelscope）、K100AI与Z100/K100系列不同型号的推理部署，以及vllm、ollama、Pytorch三种框架的具体配置方法，并延伸至Anythingllm与DCU智能助手的Webui+server可视化交互环节。资源包为1个PDF文件，约1.05MB，结构按章节组织，从环境依赖、模型获取到推理部署与可视化交互层层递进，附有命令行示例、环境变量设置说明及参考链接，便于对照实操与排错。目前已有1543人学习，适合需要快速完成海光DCU上DeepSeek模型部署与调优的技术人员参考。

1. 海光 DCU 上跑 DeepSeek-R1/V3：为什么值得折腾，以及谁该看

如果你手里有一台搭载海光 DCU 的服务器，又恰好想把 DeepSeek-R1 或 V3 这类大参数量的自然语言处理模型跑起来做推理服务，那你大概率已经发现：网上关于 CUDA 生态的部署教程铺天盖地，但一到国产加速卡这条线，能直接抄作业的完整流程少得可怜。这篇笔记就是冲着这个缺口来的——从驱动检查、容器环境准备、模型权重转换，到推理服务启动和并发调优，我会把每个环节的命令、参数和踩过的坑都摊开讲。

海光 DCU 的软件栈走的是类 ROCm 路线，工具链叫 DTK（DCU 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 -5

hy-smi输出里重点看三列：型号（比如 Z100 或 K100）、显存总量、当前利用率。如果hy-smi报错或者显示不出卡，先检查/dev/kfd和/dev/dri设备节点是否存在。DTK 版本决定了你能用哪个版本的 PyTorch 适配包，常见对应关系是 DTK 23.10 配 PyTorch 2.1，DTK 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-size=64g \ -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-dcu==0.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_config=quant_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 Cache

vLLM 的核心优势是 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看卡间连接矩阵，确认所有卡之间都有链路。如果是容器环境，检查有没有加--network=host，HCCL 默认走主机网络，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 上的性能表现和驱动版本、容器配置、甚至机房温度都有关系，不记数据光凭感觉调，很容易在某个版本升级后一夜回到解放前。希望帮到你。

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