海光DCU接入Kubernetes全实践：整卡/共享/vDCU模式与DeepSeek推理部署

搞过 AI 集群的人应该都会有同样的体会：硬件到位不是结束，而是另一个开始。海光 DCU 这种国产加速卡，单卡算力数据看着并不差，但真正决定生产价值的，是它能不能像 NVIDIA GPU 一样被 Kubernetes 调度、被 AI 平台纳管、被不同团队安全地共享。这篇文章记录的是我最近做的一轮完整适配：把一批海光 DCU 接入现有 K8s 集群，在 CubeStudio 平台上打通整卡、共享、两种 vDCU 虚拟化三种资源模式，最后还在这套环境里跑通了 DeepSeek 推理服务。整个过程踩了不少坑，也沉淀出一套可复用的标准动作，下面完整拆给你看。

1. 先把大逻辑捋清楚：DCU 进 K8s 到底靠什么

1.1 一卡一容器不算难，难的是"像 GPU 一样被调度"

很多人第一次接触国产加速卡，以为只要在容器里装上驱动、把设备映射进去就完事了。如果只是单机单卡跑个实验，确实可以这么干，直接挂/dev/dri或者/dev/hygon设备号，容器里就能看到卡。但一旦上了 K8s，问题立刻变复杂：你怎么告诉调度器"这个 Pod 需要一张 DCU"？你怎么限制一个 Pod 只能看到 1 张卡而不会把机器上 8 张卡全部映射进去？你又怎么保证两个 Pod 不会同时抢一张卡导致任务互相打死？

这些问题在 NVIDIA GPU 时代是靠一整套生态解决的：Device Plugin 上报nvidia.com/gpu扩展资源，调度器依据资源数值做分配，容器运行时通过环境变量和钩子把对应卡挂进容器。海光 DCU 要进 K8s，走的其实是同一条路，只是把背后的驱动栈从 CUDA 换成了海光的 DTK 软件栈。明白了这一点，后面所有的操作就都有章可循了。

1.2 标准三步走：驱动 → Device Plugin → 扩展资源

DCU 接入 K8s 的完整链路，我习惯拆成三层来理解：

• 第一层是物理驱动层。海光 DCU 的驱动和 DTK 工具包必须装到集群的每个计算节点上，这是所有上层能力的基础。装完之后，节点上能看到/dev/hygon_dcu这类设备文件，用dcu-smi这类工具能查到卡的型号、显存和算力状态。
• 第二层是 Kubernetes 设备接入层，核心是 Device Plugin。它常驻在每个计算节点上，通过 gRPC 向 kubelet 上报节点上有多少张 DCU，同时负责在 Pod 调度到本节点后，把具体的设备文件和环境变量注入到容器里。这个组件的关键点是它把"物理设备"转换成了"可调度的扩展资源"。
• 第三层是调度消费层。有了扩展资源，Pod 就能在 YAML 里声明要几张卡，比如hygon.com/vdcu: 1。调度器看到这个字段后，会筛选出满足条件的节点，再结合 Device Plugin 做最终的设备绑定。

三层各司其职，哪一层出了问题，表现都不一样。驱动没装好，设备文件都看不到；Device Plugin 挂了，节点上的 DCU 资源会直接消失；调度器配置不对，Pod 可能一直 Pending。排查的时候按这个分层去定位，效率会高很多。

1.3 CubeStudio 在这套架构里的位置

Device Plugin 解决的是"K8s 能调度 DCU"的问题，但生产实践中你还需要一个 AI 平台来处理更高层级的事情：多团队怎么共享有限的卡资源？训练任务和推理任务怎么编排？配额怎么管理？平台怎么让普通算法工程师不用直接写资源 YAML，而是通过界面或 SDK 就能提交任务？

CubeStudio 在这里承担的就是平台层角色。它运行在 K8s 之上，底层天然继承了 Pod、Deployment、Namespace 这些调度语义，但对上层暴露出的是"资源池""训练任务""推理服务""配额"这类更贴近 AI 用户的概念。DCU 接入 K8s 之后，CubeStudio 只要把资源类型注册进去，就能把三种模式统一管理起来。这次适配我最看重的一点，就是整卡、共享、vDCU 三种模式在平台侧是否能无缝切换，毕竟真实业务从来不是单一模式跑到底。

2. 环境准备这一步，把坑提前踩完

2.1 硬件与软件栈清单

先说环境。我这次用的节点配置是双路海光 CPU + 8 张海光 DCU 加速卡，操作系统是麒麟 V10 SP3，内核版本 4.19 以上。Kubernetes 集群版本是 1.28，容器运行时用的 containerd 1.7。这里提前交代清楚，是因为后面所有排查都要基于这套版本组合，版本不匹配是国产加速卡踩坑的头号来源。

软件栈方面，核心是海光 DCU 的 DTK 工具包。它相当于 DCU 生态里的 CUDA Toolkit，里面包含了驱动适配层、编译工具链、运行时库和基础数学库。另外还需要准备对应的 Device Plugin 组件，不同的 DCU 型号和 DTK 版本，对应的 Device Plugin 版本可能不同，这个一定要对着官方兼容性矩阵来选，别想当然用最新版。

有些朋友问我为什么不用 Docker，其实用也能用，但 containerd 在配置 Device Plugin 的钩子时路径更清晰，生产环境也更主流。容器运行时和 Device Plugin 之间通过 Unix Socket 通信，containerd 的配置文件和 Docker 的路径差异是实测中最容易踩的坑之一。

2.2 DTK 安装的第一步验证

DTK 安装过程本身不复杂，解压、执行安装脚本、配置环境变量，但安装完的验证环节值得多说两句。有些时候安装脚本报错不明显，你以为装好了，实际上驱动根本没生效。

我的建议是分三步验证。第一步，先用dcu-smi检查物理卡状态，正常情况下能看到 8 张卡的型号、温度、显存占用；第二步，检查设备文件是否存在，确认/dev/hygon_dcu这类关键设备节点已经创建；第三步，跑一个简单的算子测试，直接在节点上执行一个小矩阵乘法程序，确认计算链路通了。前两步只能证明"卡被识别了"，第三步才能证明"算力真的可用"。

这一轮我在第二个节点上就遇到过驱动装完但/dev设备节点不生成的情况，日志里也没有明显报错。最后翻出来是内核模块和当前内核版本头文件不匹配，重新用dkms编译一遍才解决。所以内核和 DTK 版本的匹配关系一定要提前确认，这是国产卡环境里出现频率最高的隐性问题。

2.3 容器运行时检查和 Device Plugin 部署

驱动就绪后，接下来是在 K8s 里部署 Device Plugin。这里我强烈建议在部署之前先做一个"空跑测试"：直接在节点上手动启动一个容器，用--device把 DCU 设备映射进去，跑一下dcu-smi，确认容器内能正常访问卡。这个测试通过之后，再部署 Device Plugin，否则出了问题你很难定位是运行时的问题还是 Device Plugin 的问题。

Device Plugin 本身在 K8s 里通常以 DaemonSet 方式部署，给每个节点都拉起一个副本。它的核心职责有两个：启动时通过 ListAndWatch 接口向 kubelet 上报资源数量；收到 kubelet 的 Allocate 请求后，把设备文件、环境变量注入到 Pod。部署完成之后，立刻在节点上执行kubectl describe node，如果看到类似hygon.com/vdcu的资源条目，并且数值等于物理卡数，说明设备接入这层已经打通了。

这里有个细节值得留意：Device Plugin 上报的资源名称是可以自定义的，但要和调度消费端保持一致。我正在用的资源名是hygon.com/vdcu，这个命名会贯穿后续所有 Pod YAML 和 CubeStudio 资源池的配置，中途改名会带来一堆不必要的麻烦。

3. 整卡 / 共享 / vDCU 三种接入模式的实现与选型

3.1 整卡模式：隔离性最好，但浪费也最明显

整卡模式最直观，Pod 声明hygon.com/vdcu: 1，调度器就把一整张 DCU 分给这个 Pod，独享显存和算力。这种模式的优势是任务之间完全隔离，互不干扰，性能波动最小，特别适合大模型训练、超大 Batch 推理这类吃满整张卡的场景。

但整卡模式的代价也很现实：如果你的模型推理只需要 6GB 显存，而一张卡有 64GB，那剩余的大几十 GB 就完全浪费了。AI 平台的 GPU 利用率上不去，绝大多数情况都是整卡配额导致的结果。尤其是在多租户场景下，A 团队的推理服务只要半张卡，你非要给他一整张，前面排队的 B 团队就得一直等着。资源明明够，但任务就是起不来，这种体验非常糟糕。

所以在平台侧，我通常建议把整卡模式定位成"高优任务专用通道"，而不是默认模式。训练任务、大模型服务这类需要稳定算力和完整显存的工作负载走整卡，其他场景优先考虑共享或者 vDCU。

3.2 共享模式：提高利用率，但隔离性要靠平台补

共享模式解决的就是利用率问题。多个 Pod 可以打到同一张物理卡上，每个 Pod 按显存和算力配额来使用。这种模式下，平台或者调度器需要在 Pod 调度时做两件事：一是显存配额校验，确保同一卡上的所有 Pod 显存之和不超过物理卡总显存；二是算力控制，防止某个 Pod 抢占过多计算资源导致邻居任务变慢。

这里有个生产环境必须注意的点：共享模式对任务的稳定性要求很高，如果某个任务的显存申请不准确、出现显存泄漏，很容易把同一张卡上其他任务拖垮。所以我会在平台侧做一张"同卡负载表"，任何共享调度都要先查这张表，评估当前卡上已有任务的显存占用和计算压力，再决定是否允许新的 Pod 调度上去。这个机制在 CubeStudio 里可以通过自定义调度策略实现，也是我这次适配重点验证的功能之一。

还有一种更细的做法是把共享和 cgroup 限制结合起来，对 CPU 内存和显存做双重限制。CPU 内存限制走 K8s 原生机制，显存限制则需要 Device Plugin 在分配时做拦截，这个逻辑写起来不难，但要在 Allocate 阶段处理到位，否则 Pod 能被调度上去，却分不到合法的显存区间，运行起来必挂。

3.3 两种 vDCU 虚拟化模式的实际区别

vDCU 是这次适配里最值得深挖的部分，因为它回答了一个关键问题：如何在保持一定隔离性的前提下，把一张大卡拆成多个逻辑卡给不同任务用。据我实际验证，目前比较常见的是两种实现路线，我分别叫它们"算力切分型"和"时间片共享型"。

算力切分型 vDCU 是把一张物理 DCU 的计算单元和显存按比例切分成多个 vDCU 实例，每个实例拥有独立的计算上下文和显存区间，逻辑上就像一张独立的小卡。这种模式的隔离性接近整卡模式，性能可预测性强，缺点是资源粒度比较固定，一旦切出来，哪怕某个 vDCU 上的任务不用，资源也不好临时借给隔壁。比较适合运行时间长的常驻推理服务。

时间片共享型 vDCU 则是在一张物理卡上按时间片轮转，多个任务轮流使用计算单元，显存空间统一管理。这种模式的资源利用率最高、切分最灵活，但缺点是当多个任务同时高负载时，会出现明显的性能争抢，单个任务的吞吐波动较大。比较适合开发调试、短时测试这类对延迟不敏感的工作负载。

这两种模式在 CubeStudio 里被统一建模成不同的 vDCU 规格，管理员创建资源池时可以选择启用哪一种。我在验证时专门跑了对比实验：同样的模型，用算力切分型跑 QPS 非常平稳，用时间片共享型跑整体吞吐更高，但每个请求的延迟毛刺更多。没有绝对的好坏，只有合不合适。

3.4 三种模式怎么选，直接给张对照表

选型建议很简单：有长稳运行需求、对延迟敏感的线上服务，优先 vDCU 算力切分或整卡；集群利用率长期偏低、任务以短时为主，就放开共享和时间片共享模式；训练任务直接走整卡，别折腾。平台侧最好把三种模式同时开放，让用户在提交任务时按需选择，这才是 AI 平台的完整形态。

4. CubeStudio 平台侧适配实操

4.1 注册 DCU 资源池与配额

CubeStudio 接入了 K8s 扩展资源之后，第一步是在平台里创建 DCU 资源池。这一步的输入是资源类型和总量，底层本质上是给不同 Namespace 打上资源配额标签。以我的实践为例，我会先建一个dcu-prod资源池，里面配置整卡和 vDCU 两种规格，再把不同的项目组加到资源池里，分别给配额。

配额管理是平台侧最容易忽略、但实际影响最大的环节。如果不做配额，某个团队一口气把集群所有 DCU 全占了，其他团队的任务直接 Pending 到超时。CubeStudio 的做法是基于 K8s 的 ResourceQuota 做了一层封装，你可以给每个团队设置整卡总数、vDCU 总数、共享模式最大用量等维度的配额。我习惯把配额分成"保障额度"和"弹性额度"两种，核心业务走保障额度，弹性额度按需申请。

这里我特别留意了配额变更对已有任务的影响。K8s 原生配额变化不会影响已经运行的 Pod，只会拦截新提交的任务，这是符合预期的行为。平台侧要做的就是把这个变化及时同步到队列和用户界面上，否则用户提交任务被拒了，但看不到原因，反馈体验会很差。

4.2 训练任务和推理任务的调度策略差异

一个成熟的 AI 平台必须把训练任务和推理任务分开编排，因为两者的资源特征完全不同。训练任务生命周期长、对稳定性要求极高，跑了一半被抢占是最伤的；推理任务生命周期长短不一、对延迟敏感，但单个任务资源需求通常较小。

在 DCU 集群上，我把训练任务默认绑定整卡模式，同时在调度策略里关闭抢占。CubeStudio 的任务调度支持优先级队列，我设置了两个队列：一个训练队列，一个推理队列。训练队列的任务只要申请了整卡，除非节点故障，否则不会被调度器迁走；推理队列的任务则允许在流量高峰时快速扩容，低峰时缩容。

还有一个小细节：推理服务的调度要考虑"同卡亲和性"，也就是让同一套服务的多副本尽量打散到不同物理卡上，避免一张卡挂了导致整个服务雪崩。CubeStudio 的调度器在这里可以配置反亲和规则，我实际验证下来，规则生效后服务的可用性提升明显。

4.3 日常工作负载在平台上的实际效果

适配完成之后，我验证了几个典型场景。第一个场景是提交一个模型训练任务，使用整卡模式，观察任务能否被正确调度到指定节点，日志流转是否正常；第二个场景是同时提交多个推理任务，使用 vDCU 算力切分模式，验证不同模型能否共享一张物理卡；第三个场景是模拟开发调试环境，用时间片共享模式让多个并行任务共用一张卡，观察性能波动是否在可接受范围。

实测下来，CubeStudio 在这三种场景下的表现都符合预期。最让我满意的其实是用户侧的体验：算法工程师不用关心底层 DCU 是怎么被调度和切分的，只要在界面里选择资源规格，提交任务就行。平台会自动把请求转换成对应的 K8s 资源声明，底层 Device Plugin 完成设备绑定。复杂的硬件细节被封装在平台和 K8s 层，这是 AI 平台该有的样子。

5. 在 DCU 集群上部署 DeepSeek 推理服务

5.1 部署方案选型：别一上来就选大模型

设备接入层的活儿干完，接下来这步是大家最关心的：怎么在 DCU 上把 DeepSeek 跑起来。这里我必须先泼一盆冷水，很多朋友一听到 DeepSeek，第一个念头就是把 V3 全量模型拉下来跑。但全量版本的显存需求不是几张卡能扛住的，部署复杂度和成本都不是一般团队能承受的。

更务实的路线是从 DeepSeek 的蒸馏版本入手，比如 DeepSeek-R1-Distill 系列的 7B 或 32B 模型。这个系列在保持较强推理能力的同时，模型体积小得多，量化之后单卡或者双卡就能跑起来，特别适合资源有限的 DCU 集群做验证。先把链路跑通，后续如果业务确实需要更大模型，再考虑多卡张量并行部署。

推理框架方面，DCU 的软件栈对 ROCm 生态兼容，所以主流的推理框架都能通过 ROCm 后端跑起来。我这次选择的是 vLLM，它在大模型推理场景下的性能调优成熟度最高，对连续批处理和 PagedAttention 的实现都很完善，社区问题也容易搜到答案。如果后续要做复杂的多轮对话和 Agent 调度，也可以考虑 SGLang，但作为第一版部署，vLLM 足够用了。

5.2 模型下载、启动与 K8s 服务暴露

模型文件可以通过 ModelScope 平台下载，这是国内环境最稳妥的渠道。下载完成后把模型目录放到每个计算节点都能访问的共享存储上。这里有个坑要提醒：模型文件很大，如果每个节点都放一份，存储成本浪费严重，而且更新模型版本时很容易出现节点间版本不一致。我用的是 NFS 共享存储挂载，所有节点访问同一份权重文件，既省空间又方便管理。要注意 NFS 的 I/O 性能不能太差，否则加载模型时间会很长。

模型准备就绪后，先手动验证一次推理，把命令写清楚：

vllm serve /mnt/models/deepseek-r1-distill-7b \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192

启动成功后用 curl 发一个请求测试接口，确认能正常返回。手动验证通过后，再把它封装成 K8s 的 Deployment，在 Pod YAML 里声明 DCU 资源：

resources: limits: hygon.com/vdcu: 1

这里做了一次关键验证：同一个 vLLM 服务在整卡模式和 vDCU 模式下都能正常启动，说明 DCU 设备层面对应用是透明的，应用只需要认资源声明就够了。服务再对接一个 K8s Service，将 8000 端口暴露到集群内部，方便 CubeStudio 平台统一注册，其他业务团队的代码就能直接通过服务名调用。

5.3 性能验证与几个值得调的参数

服务部署起来只是第一步，真正的活儿是调优。我测试时的核心指标有三个：首 Token 延迟、生成吞吐和并发请求下的稳定性。整卡模式下，7B 模型在 DCU 上的生成吞吐基本能达到硬件规格对应水平；切换到共享模式后，单任务吞吐会有所下降，但整体资源利用率上来了，换算到单位卡时成本反而更低。

几个影响性能的关键参数我先列出来：

• --max-model-len：最大序列长度，设太大会造成显存浪费，设太小长对话直接截断，一般按业务最长场景加上余量来设。
• --gpu-memory-utilization：GPU 显存利用率上限，默认是 0.9。如果你要在同一张卡上跑多个副本，这个值要相应调低，留出余量。
• --max-num-seqs：并发序列数，决定连续批处理能塞进多少请求。太大会导致显存不足，太小吞吐上不去，要靠压测调整。
• --enable-auto-tool-choice：如果业务要打通 Agent 场景，记得开启工具调用支持，否则函数调用类请求会报错。
• --port：服务端口，容器内和 Service 端口要对应得上。

参数调优没有标准答案，我建议把 Benchmark 脚本固化下来，每调一次参数就记录一次数据，形成压测基线后可追溯。

6. 常见问题与排障实录

6.1 我踩过的几个坑

第一坑是调度资源名不一致。最开始我在 Device Plugin 里把资源名配成了hygon.com/dcu，但 CubeStudio 资源池里填的是hygon.com/vdcu，结果所有任务都 Pending，看事件到处找原因，最后发现就是资源名对不上。这类问题排障最简单的方法，是在提交任务后马上看 Pod 的 Events，调度器会非常明确地提示不满足资源条件。

第二坑是共享模式下显存管理失灵。有一段时间任务频繁 OOM，但每张卡看起来都有空闲显存。排查下来是同一张卡上的不同容器共享显存，但没有任何机制做显存隔离保护，一个任务超量申请就把其他任务的显存空间挤占掉了。解决方案是在平台侧增加显存配额校验，同时又对 Device Plugin 的分配逻辑做了兜底，确保同一卡上的多个容器显存区间不重叠。

第三坑是节点负载不均。一开始所有任务都往同一两个节点上调度，其他节点空闲。检查后发现是 Device Plugin 的资源上报正常，但是集群调度器的节点打分策略没有针对 DCU 做优化，部分节点因为有其他 CPU 或内存压力被优先排除了。我在 CubeStudio 里给 DCU 资源设置了更高的权重，调度分布明显均匀多了。

6.2 快速排障速查表

这套表格我通常直接贴在运维文档里，新同事遇到问题先按表排查，能省下大量重复沟通的时间。实际上大部分 DCU 接入问题都不是硬件问题，而是配置不一致、版本不匹配、组件间约定没对齐这三大类，规范化和文档化能提前规避一半以上的坑。

最后再分享一个我实际操作中的体会：DCU 接入 K8s 和 AI 平台这件事，最难的永远不是单个组件的安装，而是把驱动、Device Plugin、调度器、平台、应用这一整条链路打通之后，还能稳定运行、随时排障。这是一条非常典型的"生态补齐"路径，也需要一套完整的监控告警来保障——把卡的温度、显存、利用率指标都纳入 Prometheus，设置合理的告警阈值，比任何事后排查都管用。上述内容如果能让你少踩几个坑，这趟适配就是值得的。