海光DCU接入Kubernetes与DeepSeek推理部署实践

在算力集群这件事上，大家通常默认“加速卡 = NVIDIA”。但这两年国产 DCU 上得很快，尤其海光 DCU，性价比和生态都在往实用靠，不少团队已经开始把 DCU 节点放进生产 Kubernetes 集群，跑训练、跑推理。我这边最近刚完成一批海光 DCU 节点的接入，还和 CubeStudio AI 平台做了资源对接，最后在 DCU 上把 DeepSeek 推理服务部署了起来。整个过程涉及整卡、共享、两种 vDCU 虚拟化，坑不少，但也真能跑通。这篇文章就把适配路径完整记录下来，给准备接 DCU 的同学当参考。

1. 接入前必须搞清楚的三个问题：DCU 在 K8s 里是怎么被“看到”的

1.1 DCU 不是 GPU，但调度模型可以“模仿” GPU

海光 DCU 本质上是类 GPGPU 加速器，软件栈叫 DTK（DCU Toolkit），底层接口风格接近 ROCm/HIP，所以在 Kubernetes 里的接入方式，和 NVIDIA 的“Device Plugin + 容器运行时 + 资源上报”一模一样的思路。你可以把 DCU 想象成一个讲方言的 GPU：它有自己的一套管理工具、驱动、运行时，但表达给 Kubernetes 的方式，还是通过 device plugin 上报一种自定义资源，比如hygon.com/dcu。

Kubernetes 本身不认识什么 GPU、DCU、NPU，它只认resources.limits里的数值。你上报hygon.com/dcu: 2，调度器就知道这个节点还有两张卡可以分配。真正让容器里看到卡的，是 device plugin 把/dev/dri、/dev/kfd等设备映射进容器，同时注入环境变量DCU_VISIBLE_DEVICES，告诉你的程序“用哪几张卡”。

这个逻辑搞明白后，后面所有适配都不会迷糊。你不是在给 Kubernetes 装驱动，而是让 Kubernetes 把 DCU 当成一种“可计数的资源”，再配合容器运行时把设备安全地交进去。

1.2 需要一个平台来管理加速卡资源池

如果只是手动调度几张卡，直接写 Pod 的 limits 就行。但生产环境通常有几十张卡、几十个用户、多个团队，谁申请了多少资源、有没有超卖、某张卡坏了怎么替换，这些不能靠人工记录。所以我们接入了 CubeStudio 这样的 AI 平台，它在 Kubernetes 之上做了一层资源抽象，把整卡、共享、vDCU 这些调度能力封装成“资源池”，用户不感知底层是 DCU 还是 GPU，只在界面上选“资源类型 = 海光 DCU”，就能跑 Notebook、训练任务或推理服务。

这里有个关键点：平台可以帮你屏蔽底层差异，但平台自己也得知道怎么跟 device plugin 配合。所以我们在做 CubeStudio 适配时，主要工作是三件事：配置资源池、绑定节点标签、设置 DCU 资源类型。平台最终生成的还是标准的 Kubernetes Pod YAML，只不过里面带了hygon.com/dcu的 limits。

1.3 一张表看清各组件的作用

在动手之前，我们先理了一遍整个链路里各组件的关系，这里用表格列出来，方便你对照：

这个链路没有哪一环是能跳过的。之前有同事想图省事，不装容器运行时，直接靠 device plugin 硬塞设备进容器，结果容器内权限不对，驱动映射不完整，程序起来就报错。所以我建议还是老老实实按完整链路配。

2. 环境准备：驱动、DTK、容器运行时，一步都不能错

2.1 确认 DCU 型号和驱动版本

先把节点上的硬件摸清楚。海光 DCU 常见型号有 Z100、Z100L、K100、K100L 等，显存大小从 16GB 到 64GB 不等。登录到节点，用lspci查看设备信息：

lspci | grep -i "hygon\|datacenter accelerator"

你能看到类似Processing accelerators: Hygon Information Technology Co., Ltd. Device的字样。记下设备的 PCI ID，后续安装驱动时需要用它来核对固件是否匹配。

驱动版本也很关键，海光 DCU 的驱动跟 DTK 工具链是配套发布的。我们当时采用的是 DTK 24.04 版本，配套的驱动版本是 6.2.x。版本不匹配最常见的现象是dcu-smi工具执行失败，或者驱动加载报module version doesn't match. 建议先在海光官方支持库里确认当前要用的 DTK 版本对应的驱动版本，再统一安装，不要各拿各的。

2.2 安装驱动，并验证 dcu-smi 是否可用

驱动安装比较简单，拿到驱动包后解压，直接执行安装脚本：

tar -xf hygon_dcu_driver_*.tar.gz cd hygon_dcu_driver_*/ sudo ./install.sh

安装完成后，重启或者重新加载模块：

sudo modprobe amdgpu sudo modprobe kfd

然后验证设备是否被正确识别，海光 DCU 的命令行管理工具是dcu-smi，类似nvidia-smi：

dcu-smi info -t

如果输出里能看到每张 DCU 卡的型号、显存、温度、利用率，就说明驱动 OK。我最开始安装完没执行 modprobe，直接跑dcu-smi一片空白，浪费了不少时间。

还有一点值得说：有些节点是海光 CPU + 海光 DCU 的组合，这种情况下 BIOS 里可能要对 IOMMU 做配置。生产环境建议在 BIOS 里打开 IOMMU，并把iommu=pt写进内核参数，否则设备直通到容器时可能出现 DMA 错误。

2.3 安装 DTK，并把工具链带进容器镜像

DTK 是 DCU 上的 CUDA 等价物。你可以在/opt/hygon/DTK下看到一批工具，比如 HIP 编译器、hipcc、hipblas、MIOpen 这些。在宿主机上装好 DTK 后，重点是把它“打”进容器镜像里，否则你在容器里跑 PyTorch，没找到 HIP 后端，照样识别不了 DCU。

我们的做法是写一个基础镜像 Dockerfile，把 DTK 依赖复制进去：

FROM ubuntu:22.04 # 复制海光 DTK 运行时到镜像 COPY --from=hygon/dtk:24.04 /opt/hygon/DTK /opt/hygon/DTK ENV PATH=/opt/hygon/DTK/bin:$PATH \ LD_LIBRARY_PATH=/opt/hygon/DTK/lib:/opt/hygon/DTK/lib64:$LD_LIBRARY_PATH \ HIP_VISIBLE_DEVICES=0 # 安装 Python 和 PyTorch 适配版本 RUN pip install torch==2.1.0+dcu

这个镜像后续会作为 CubeStudio 里 Notebook 和训练任务的底座镜像。注意 PyTorch 要用 DCU 适配版，不能用官方 CUDA 版，否则 HIP 后端找不到。

2.4 配置容器运行时：让 Docker/containerd 认识 DCU

这一步很多人容易漏。光有 device plugin 不够，容器运行时还要知道怎么把 DCU 设备挂载进容器，以及怎么根据DCU_VISIBLE_DEVICES环境变量做设备隔离。

海光官方提供类似nvidia-container-toolkit的dcu-container-runtime，安装完成后需要配置 Docker 或 containerd。以 Docker 为例，在/etc/docker/daemon.json里加上 runtime 配置：

{ "runtimes": { "dcu": { "path": "/usr/bin/dcu-container-runtime", "runtimeArgs": [] } } }

用 containerd 的话，要改/etc/containerd/config.toml，在run_containerd配置里注册 runtime，比较繁琐。我们生产环境用的是 containerd，当时因为没配好，Pod 起来后容器内/dev/dri根本不存在，查了半天才发现是 containerd 配置里没加这个 runtime。如果是新环境，建议先用 Docker 跑通，再迁 containerd，排查起来更容易。

配置完成后，推荐用一个简单的容器验证：

docker run --rm --runtime=dcu -e DCU_VISIBLE_DEVICES=0 your-dcu-image dcu-smi info -t

能显示 DCU 信息，说明容器运行时 OK。

3. Kubernetes 设备插件接入：从整卡调度开始

3.1 部署 hygon-device-plugin

设备插件是 DCU 资源进入 Kubernetes 的关键组件。海光官方提供的 device plugin 一般叫hygon-device-plugin，它主要做两件事：把节点上所有 DCU 上报给 kubelet；在 Pod 申请资源时，把指定 DCU 的设备文件和DCU_VISIBLE_DEVICES注入进去。

部署方式很简单，就是一个 DaemonSet。以下是我们的部署 YAML 核心片段：

apiVersion: apps/v1 kind: DaemonSet metadata: name: hygon-device-plugin namespace: kube-system spec: selector: matchLabels: app: hygon-device-plugin template: metadata: labels: app: hygon-device-plugin spec: hostNetwork: true containers: - name: hygon-device-plugin image: hygon/hygon-k8s-device-plugin:latest imagePullPolicy: IfNotPresent args: - --mode=default env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName volumeMounts: - name: device-plugin mountPath: /var/lib/kubelet/device-plugins - name: sys mountPath: /sys - name: dev mountPath: /dev volumes: - name: device-plugin hostPath: path: /var/lib/kubelet/device-plugins - name: sys hostPath: path: /sys - name: dev hostPath: path: /dev

部署后，确认 Pod 正常运行：

kubectl -n kube-system get pods | grep hygon-device-plugin

3.2 验证节点资源是否上报成功

设备插件起来后，查看节点状态，正常情况下你应该能在Capacity里看到这个资源：

kubectl describe node dcu-node-01 | grep -A5 "Capacity"

输出类似：

hygon.com/dcu: 8

如果没看到这个资源，先看 device plugin 日志：

kubectl -n kube-system logs <hygon-device-plugin-pod-name>

常见问题包括：驱动没装好、/var/lib/kubelet/device-plugins目录权限不对、kubelet 的--feature-gates=DevicePlugins=true没开启。新版本 Kubernetes 默认会开启，老版本可能还要手动加进来。

3.3 整卡调度：跑第一个“吃卡”任务

资源上报成功后，就可以用整卡模式调度了。所谓整卡，就是一张 DCU 卡整个分给一个 Pod，不拆、不共享。YAML 里声明：

apiVersion: v1 kind: Pod metadata: name: dcu-test-pod spec: containers: - name: dcu-test image: your-dcu-base-image:latest resources: limits: hygon.com/dcu: 1 command: ["/bin/bash", "-c", "dcu-smi info -t && sleep 3600"]

调度到 DCU 节点后，进入容器验证：

kubectl exec -it dcu-test-pod -- dcu-smi info -t kubectl exec -it dcu-test-pod -- env | grep DCU

如果能看到 DCU 卡信息且DCU_VISIBLE_DEVICES指向正确编号，就说明整卡链路通了。

整卡模式的好处是简单、隔离性最强、性能无损，缺点也明显——资源浪费。一张 32GB 显存的卡，如果跑一个只需要 8GB 的小模型，剩下的 24GB 就白白空着。这就是我们接下来聊共享和 vDCU 的原因。

4. 共享调度与两种 vDCU 虚拟化的区别

4.1 为什么需要共享：业务碎片化下的必然选择

整卡模式在测试阶段够用，但生产环境资源很快就紧张。我们有几十个模型并行推理，大部分模型都是 7B、14B 这种小模型，显存需求 8GB 到 16GB，用整卡跑一个大材小用，用 CPU 跑又慢得没法看。这种场景下，共享一张 DCU 卡就成了刚需。

海光 DCU 的共享方案，按隔离粒度分，大致有三种：纯软件层显存隔离（共享模式）、硬切分区的 vDCU 模式、软切并发的 vDCU 模式。这里很多人会混淆，我重点把后面两种 vDCU 讲清楚。

4.2 共享模式：纯软件层的显存隔离

共享模式通常由 device plugin 加启动参数实现。比如通过参数指定把一张物理卡划分为多个逻辑卡，每个逻辑卡分配一定显存配额，多个 Pod 可以调度到同一张物理卡上。这种模式实现简单，但隔离性较弱，尤其是算力方面，多个任务抢同一张卡的算力，某个任务计算量大时，其他任务延迟会明显上升。

配置上，我们在 device plugin 的 DaemonSet 里加参数，比如：

args: - --mode=share - --memory-limit=16

这里的--memory-limit表示单张卡按显存大小切分，比如 32GB 的卡，每个 slice 最大 16GB，那就能切出 2 个逻辑卡。具体参数名不同版本可能不同，以官方文档为准。

共享模式的典型场景是 Notebook 或者短时任务，用户跑几行 Python 代码，对延迟不敏感，只想要一个能跑模型的交互环境。

4.3 vDCU 模式一：硬切分区，类似 MIG 的“物理级”虚拟化

第一种 vDCU，本质上是把一张物理 DCU，通过底层固件和驱动在硬件层面切分成多个独立的虚拟 DCU。每个虚拟 DCU 拥有独立的显存、独立的计算单元片段、独立的内存带宽，任务之间基本互不干扰，隔离性跟整卡差不了多少。

这种模式特别适合“多模型稳定并行”的场景。比如一张 64GB 的卡，切成 4 个 16GB vDCU，四个模型各自独占一份资源，互不抢算力，延迟波动很小。

在 K8s 里的配置方式，通常是 device plugin 加--mode=vdcu参数，然后在 Pod 里按虚拟 DCU 的规格申请：

resources: limits: hygon.com/dcu: 1 hygon.com/vdcu-type: "K100L-16G"

实际参数名和语义可能因插件版本有差异，但思路一致：平台或用户在创建资源池时选择“vDCU 硬切模式”，每个 vDCU 会带一个显存规格，调度时 device plugin 根据当前物理卡剩余可切分空间决定分配哪张卡。

这个模式踩过的坑是：不是所有型号的 DCU 都支持硬切，老型号可能只在特定驱动版本下支持。配置前一定要对照官方支持矩阵确认。

4.4 vDCU 模式二：软切并发，时间片和并发调度的取舍

第二种 vDCU，走的是另一个方向：不做显存硬隔离，而是让多个虚拟 DCU 共享同一张物理卡的算力，通过驱动层面的调度器给任务分配时间片或并发量子。这种模式下，显存是共享的，但每个 vDCU 仍然有逻辑上的资源边界。

它的好处是资源利用率极高。比如一个推理服务和一个数据预处理任务混跑在同一张卡上，推理任务大部分时间在等请求，算力空窗正好让预处理任务利用。坏处是：一旦多个任务同时进入计算密集状态，就互相抢算力，延迟抖动明显；显存共享也可能导致一个任务把显存吃满，把别的任务挤掉。

我们当时做过的压测显示，在混跑场景下，推理服务的 P99 延迟会从 40ms 飙到 200ms 以上。所以这种模式适合层别：不同业务的服务质量要求不同，把对延迟不敏感的批处理任务和对延迟敏感的服务任务混跑，需要谨慎设计。

配置方式也是 device plugin 加参数，相对硬切模式会多一些调度选项，比如 GPU 时间片比例、并发队列数量等。产品文档里这套一般叫 vDCU 并发调度或时间片调度。

4.5 两种 vDCU 怎么选，经验总结

这里给一个比较直接的选用逻辑：

没有哪一种是普适最优的，一定要按业务特性来。我们在 CubeStudio 上同时配置了整卡池和 vDCU 硬切池，两种池对应不同的资源规格，让用户在创建任务时可以按需选择。

5. CubeStudio 平台适配：让 AI 平台“看得见” DCU

5.1 CubeStudio 跟 Kubernetes 是什么关系

CubeStudio 属于典型的“Kubernetes 之上的 AI 平台”，它对外是 Web 控制台，用户可以在上面创建 Notebook、提交训练任务、部署推理服务，但对内它只是把请求翻译成 Kubernetes 资源，交给 API Server 处理。平台本身不直接管理硬件，而是通过识别设备插件上报的资源类型来调度作业。

因此，平台适配 DCU 的核心，就是让平台认识hygon.com/dcu这种资源，并知道每个资源池下的节点有多少 DCU 可用。

5.2 在 CubeStudio 中创建 DCU 资源池

登录 CubeStudio 管理端后，一般是在“资源管理”或“集群管理”模块操作。我们这边的配置流程大体如下：

• 在集群管理里添加海光 DCU 节点，给节点打上gpu-type=hygon-dcu的标签，同时写清楚每节点的 DCU 卡数和型号。
• 创建新的资源池，类型选择“海光 DCU”，并把这个资源池绑定到刚才添加的节点上。
• 在资源池配置里，可以设置共享粒度。如果你要同时支持整卡和 vDCU，需要分别建不同的资源池，因为一个池通常绑定一种调度模式。
• 把资源池授权给对应的项目组或用户。

这里有个细节：Node 上的标签和 device plugin 的--node-selector参数要对上，不然平台把任务调度到节点上，device plugin 却因为节点标签不匹配拒绝分配卡，任务就一直 Pending。

5.3 验证 CubeStudio 里的 DCU 任务

配置完成后，我们在 CubeStudio 里创建了一个测试 Notebook，资源类型选“海光 DCU vDCU 16G”，进入终端后执行：

python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())"

如果一切正常，输出会是True和虚拟 DCU 数量。这一步能通过，说明平台、调度器、设备插件、容器运行时整条链路已经打通。

值得提醒的是，PyTorch 在 DCU 上识别设备的逻辑，虽然也走 HIP，但torch.cuda.device_count()一般能通过兼容层返回正确结果。这里不影响使用，只是确认方式。如果平台界面显示卡占用异常，建议回到底层 K8s 看 Pod 的事件，不要只盯平台侧日志，平台日志和 K8s 事件经常不同步。

6. DeepSeek 部署实操：从 vLLM-DCU 到推理调用

6.1 选模型：要跑完整版还是蒸馏版

海光 DCU 上跑 DeepSeek，核心是选对推理框架和模型版本。DeepSeek 官方开源了完整版 DeepSeek-R1（671B MoE）和一系列蒸馏版（DeepSeek-R1-Distill-Qwen-7B/14B/32B）。完整版效果好，但对显存要求极高，671B 参数即使做量化也得几百 GB 显存，单卡跑不了，得做多卡张量并行。蒸馏版就友好得多，7B、14B、32B 都可以在单卡或双卡上跑通。

我们生产环境一开始用的是 DeepSeek-R1-Distill-Qwen-14B，单张 32GB 的 DCU 就能跑，配合 INT8 量化，显存占用大概 22GB，能稳定服务。如果想要更好的效果，可以换 32B 版本，但至少需要 2 张 32GB 卡并行，或者用单张 64GB 的卡。

6.2 推理框架：为什么用 vLLM-DCU

社区里跑 DeepSeek 的推理框架，最常用的是 vLLM 和 SGLang。海光团队提供了适配 DCU 的 vLLM 分支，一般叫vLLM-DCU，它把 vLLM 里的 CUDA 算子替换成 HIP 实现，并且针对 DCU 的硬件特性做过优化。直接用官方 vLLM 大概率起不来，因为它默认 CUDA 后端，在 DCU 上找不到 GPU。

我们采用的镜像大致长这样：

FROM hygon/vllm-dcu:latest ENV VLLM_USE_DCU=1 \ HIP_VISIBLE_DEVICES=0 WORKDIR /workspace

实际生产镜像里还会装模型下载工具和监控脚本，这里精简展示核心配置。

6.3 编写 DeepSeek 推理服务的 K8s 部署文件

下面是我们在 CubeStudio 上最终生成的推理服务 Deployment YAML 的核心片段：

apiVersion: apps/v1 kind: Deployment metadata: name: deepseek-r1-distill-qwen-14b namespace: ai-inference spec: replicas: 1 selector: matchLabels: app: deepseek-r1 template: metadata: labels: app: deepseek-r1 spec: containers: - name: vllm-dcu image: hygon/vllm-dcu:latest command: - python - -m - vllm.entrypoints.openai.api_server args: - --model=/models/deepseek-r1-distill-qwen-14b - --tensor-parallel-size=1 - --max-model-len=8192 - --gpu-memory-utilization=0.85 - --trust-remote-code resources: limits: hygon.com/dcu: 1 volumeMounts: - name: model-storage mountPath: /models env: - name: HIP_VISIBLE_DEVICES valueFrom: fieldRef: fieldPath: "metadata.annotations['vdcu.hygon.com/device-id']" volumes: - name: model-storage persistentVolumeClaim: claimName: dcu-model-pvc

几个关键参数说明一下：

• --tensor-parallel-size：张量并行度。单卡跑 14B 就用 1；如果跑 32B 且显存不够，要扩到 2，同时hygon.com/dcu申请 2，device plugin 会分配两张卡，vLLM 会用 NCCL 风格的集合通信在两张卡之间做分布式推理。
• --max-model-len：最大上下文长度。DCU 显存有限，不要盲目设大。14B 模型设 8192 比较稳，设成 32768 显存可能直接爆掉。
• --gpu-memory-utilization：显存利用率上限。设 0.85 比较稳妥，不要设 0.95，容易把 KV Cache 和模型加载挤在一起触发 OOM。

看到HIP_VISIBLE_DEVICES的取值来自vdcu.hygon.com/device-id注解，这在生产实践里比较关键。因为整卡模式下设备号一般从 0 开始，但在 vDCU 虚拟化模式下，一个容器可能拿到的是物理卡上的某个切分切片，设备号不一定是 0。我们用注解方式把实际设备号传给环境变量，保证 vLLM 能识别对设备。

6.4 部署后的推理验证

部署完成后，确认 Pod 状态是 Running：

kubectl -n ai-inference get pods | grep deepseek

然后跑一个推理请求测试接口。vLLM 的 OpenAI 兼容接口默认监听 8000 端口：

curl http://<cluster-ip>:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1-distill-qwen-14b", "messages": [ {"role": "user", "content": "用一句话介绍 Kubernetes"} ], "max_tokens": 200, "temperature": 0.7 }'

返回结果里有正常的choices内容，说明整个链路已经通了。如果返回 500 或者卡住不动，先看 vLLM 日志里有没有算子编译失败或显存不足的错误。

6.5 性能表现和资源调优建议

我们现在这个 14B 蒸馏版模型，单张 DCU 上，批大小 1 的情况下首 token 延迟约 300ms，生成速度约 25 tokens/s。如果做并发优化，开启 vLLM 的 continuous batching，吞吐能提升到 80 tokens/s 左右，代价是单请求延迟略有上升。

对于想把 DeepSeek 完整版 671B 跑起来的情况，至少要 8 张 64GB 的 DCU，并且--tensor-parallel-size=8。这种规模下，显存规划要特别仔细，模型权重 + KV Cache + 激活值都要预留。我们目前只在实验环境用 4 卡跑过量化版的 V3/R1 系列，生产环境还是以蒸馏版为主，先把服务稳定性稳住，再往大模型迁移。

7. 常见问题与排查实录：一张速查表看清故障点

这几个月搞下来，我们把遇到的高频问题整理成了一张表，基本上覆盖了 DCU 接入 K8s 的常见故障点：

有几条我再展开说下，因为它们是实操中最容易“卡死”人的。

第一条是关于gpu-memory-utilization。你设 0.95，看剩余显存可能还有几个 GB，但 vLLM 在计算 KV Cache 时会把整块显存一次性预留，如果预留失败会直接报“No available memory for the cache”. 这个参数不是越高越好，0.85 是我们在多型号 DCU 上比较稳的经验值。

第二条是在 vDCU 硬切模式下，某些 PyTorch 算子会尝试访问不属于当前 vDCU 的显存地址，导致 coredump。这个问题的根源是算子库对虚拟设备支持不完整。最简单的应对是先把任务切到整卡池跑通流程，再回到 vDCU 池做性能测试。如果必须用 vDCU，建议升级到最新版 DTK，算子兼容性问题通常在新版修复。

第三条是监控问题。DCU 的利用率指标不能直接用 Prometheus 的DCU_FI_DEV_GPU_UTIL（那是给 NVIDIA 或其他卡的）。海光有自己的 exporter，能把dcu-smi的数据转成 Prometheus 指标。如果没接监控，共享模式和 vDCU 软切模式下你根本看不出是哪张卡在打满，排查性能问题全靠猜。

8. 个人观察：国产加速卡接入，难的不是技术而是对接口

最后说点实操之外的话。这次适配海光 DCU 给我的整体感受是：技术链路本身并不复杂，K8s 的设备抽象模型已经把底层的差异消化得差不多了，真正费时间的反而是对接口——设备插件参数变了要查文档，DTK 版本变了要重新验证算子兼容性，vDCU 模式的限制条件藏在犄角旮旯的表格里。

对我们这种既要跑训练又要跑推理的团队来说，最有效的策略是把资源池化，并且分得很细。整卡池给核心训练，vDCU 硬切池给多模型推理，共享池给开发和临时任务，通过 CubeStudio 把这些池子暴露给不同团队，用户按需选择，底层调度完全透明。这样既保证了关键任务的资源隔离，又不会浪费卡片资源。

如果你也正在做类似的国产算力接入，建议先在一个小集群里把整条链路跑通，再逐步放量。开始不要急着上 vDCU，先把整卡模式摸熟，再把共享和虚拟化加进来。这样每一步出问题都能定位到具体的组件，不会一上来就是一团乱麻。

另外，DeepSeek 这类大模型在 DCU 上跑推理，多花点时间在模型量化和显存参数调优上，收益非常明显。同样一张卡，参数调好和没调好，吞吐能差 2 到 3 倍。