最近大模型落地这块国产算力的存在感越来越强。我这边从去年开始就在搞海光 DCU 怎么接入 Kubernetes一开始以为把 NVIDIA 那套 device plugin 换皮就能用结果从驱动到调度器再到推理框架几乎每个环节都踩了坑。这篇文章把 CubeStudio、Kubernetes、vDCU 虚拟化以及 DeepSeek 部署这条链路完整梳理一遍既是给自己做个记录也给准备在 DCU 上做集群化和模型服务的同学一份可以直接照着抄的实操参考。内容适合谁已经在用或准备用 DCU 做训练/推理的运维和算法同学手里有 K8s 集群想接国产加速卡的平台工程师以及想在 DCU 上跑 DeepSeek 但不知道从哪下手的人。下面我尽量按原理 → 配置 → 踩坑的顺序来讲命令和 yaml 都是我们在生产环境验证过的版本可以直接改着用。1. 为什么海光 DCU 上 K8s 这件事值得单独写一篇1.1 先分清 DCU 到底是个什么角色海光 DCUDeep Computing Unit从硬件架构上讲走的是类 CDNA 的路线生态上兼容 HIP/ROCm。这句兼容很重要它决定了你后面所有软件选型的方向不能再用 CUDA 的思维方式而是要切换到 HIP 的语境下。对很多团队来说最难接受的不是性能数字而是心智模型的转变。我们有几台 64GB 显存的 DCU 卡单卡能装下 7B~14B 的模型如果做量化32B 也有机会。这个规格其实已经覆盖了相当大一部分企业级推理场景。所以从业务需求出发DCU 不是能不能用的问题而是怎么用好的问题。1.2 直接照搬 NVIDIA 方案为什么不行NVIDIA 在 K8s 里靠三件套device plugin、容器运行时插件、以及 CUDA 生态里的各类 operator。这三件套任意一件都假设了设备厂商是 NVIDIA。DCU 对应的替代品是海光自己的 device plugin、容器运行时和 DTK 工具链。名字听起来像但接口、配置项、上报的资源名都不一样。而且有一个特别容易踩的坑NVIDIA 的 device plugin 上报的资源名是 nvidia.com/gpu而 DCU 的 device plugin 默认上报的是 hygon.com/dcu 这类自定义扩展资源。K8s 调度器对扩展资源只做整数数量的匹配不做显存、拓扑、卡上任务的感知这意味着你必须额外想办法把显存大小卡间拓扑虚拟化粒度这些信息带进调度决策里否则 Pod 能不能起来完全是运气。1.3 这篇文章解决的问题范围我不会展开讲 DCU 驱动怎么安装这个官方文档写得很清楚重点放在三块一是 DCU 正确接入 K8s 的基础设施链路二是 CubeStudio 这类 AI 平台在中间帮我们解决了什么、没解决什么三是 vDCU 的两种虚拟化模式怎么选以及怎么在 DCU 上把 DeepSeek 跑起来。看完你应该能回答我的业务到底该用整卡、共享还是 vDCU这个问题。2. 搞懂 DCU 软件栈是适配的地基DTK、HIP 与容器运行时2.1 DTK 版本和驱动对应关系DTKDCU Toolkit是海光在 ROCm 生态上封装的一整套开发套件里面有 HIP 编译器、MIOpen-DCU算子库、HiCCL集合通信库等等。第一次接触的人最容易犯的错是以为 DTK 只是一个装完就完事的 SDK。实际上 DTK 的版本必须和驱动版本、PyTorch 版本严格对齐否则你会看到编译能过、算子却全部回退到 CPU 的诡异现象——因为 HIP runtime 和 kernel 版本不匹配时很多算子会静默降级。我建议把版本对齐当成第一优先级先确定驱动版本再选对应 DTK然后才谈镜像。官方镜像的 tag 通常会写明 dtk 和 pytorch 的版本组合比如 pytorch:2.1.0-dtk24.04-py3.10这种 tag 策略能省掉你一半以上的环境问题。注意DCU 容器镜像里一定要保留 /opt/dtk 这个路径很多框架在容器里会硬编码找它。你自定义镜像的时候如果在精简阶段把这个目录删了运行时会报cannot find libamdhip64这类错误非常隐蔽。2.2 为容器运行时装好眼睛和手脚K8s 要调度 DCU节点上必须有三个东西驱动、容器运行时插件、device plugin。驱动提供设备节点 /dev/dcu0 这类文件容器运行时插件负责在容器启动时把设备文件、驱动库、权限注入容器device plugin 负责把设备数量上报给 kubelet让 K8s 认为节点上存在hygon.com/dcu这种资源。其中容器运行时插件是最容易被忽略的一环。很多人以为装了 device plugin 就能用结果 Pod 里看不到设备就是因为容器运行时没有注入设备。以 Docker 为例需要在 /etc/docker/daemon.json 里配置 runtime 指向 DCU 的 runtime 可执行文件然后重启 docker 和 kubelet。如果你用的 containerd则在 /etc/containerd/config.toml 里加对应的 runtime 配置。2.3 最小验证清单我建议在正式接入 K8s 之前先在单机上用 docker 手动跑一个容器验证docker run --rm \ --device/dev/dcu0 \ --security-opt seccompunconfined \ -e HIP_VISIBLE_DEVICES0 \ hub.example.com/dcu/pytorch:2.1.0-dtk24.04-py3.10 \ sh -c dcu-smi hipcc --version能看到类似驱动版本、显存总量、HIP 编译器版本信息说明驱动和运行时没问题再看 device plugin 上报数量才轮到 K8s 层的问题。这个顺序很重要——先把底层链路打穿不要一上来就在 K8s 里排查。3. CubeStudio 在整套体系里扮演什么角色3.1 CubeStudio 是什么CubeStudio 是我这边选型下来的一站式 AI 平台底层还是 Kubernetes只不过它把 K8s 那套资源抽象、调度、配额、多租户功能做了产品化封装对外提供的是开发训练推理一体的界面和 API。用户不需要直接写 Deployment 去申请 DCU而是在平台里创建开发环境、提交训练任务、上线推理服务平台负责把这些请求翻译成 K8s 对象。对我们做平台的人来说选 CubeStudio 而不是自己基于原生 K8s 一点一点搭最大的收益是省掉了三块重复劳动资源配额和租户隔离、任务生命周期管理排队、重试、日志、指标、以及加速卡资源的上报与展示。这些功能自己写不是不行但每一条都对应着一堆边缘情况性价比很低。3.2 CubeStudio 与 K8s、DCU 的联动方式CubeStudio 不会重复造 device plugin 的轮子它默认还是走节点有 DCU 资源 → 平台在上层做调度的路线。资源上报依旧靠我们部署的 DCU device pluginCubeStudio 只是读取节点 capacity 和 allocatable并在创建任务时帮你注入对应的 resource request/limit。不过要注意一个细节CubeStudio 这类平台的调度器通常只认资源数量不认显存和卡型。如果你集群里混着不同显存大小的 DCU它可能把 7B 模型的任务调度到显存不够的节点上。我们的做法是在 CubeStudio 里用资源模板/机型的概念隔离卡型把相同显存的节点放进同一个池子再把模型所需的最小显存做成模板参数。这一层经验一定要提前设计别等节点多了再后悔。3.3 CubeStudio 里跑通第一个 DCU 任务以我们环境为例在 CubeStudio 里创建一个 PyTorch 开发环境时需要选三样东西镜像带 DTK 的、资源规格几卡、多少 CPU/内存、以及启动命令。平台背后生成的是一个带有 resource limits 的 Pod我们只要确认 Pod 里能跑通 dcu-smi 就算成功。这里有个坑如果平台默认给的 Pod 模板不带 DCU 的资源请求就算节点有卡也不会注入必须先确认平台的资源规格配置里有 hygon.com/dcu 这个自定义资源。4. 整卡接入Device Plugin 调度器的改造4.1 整卡模式下的资源模型整卡模式最简单一张 DCU 卡只能被一个 Pod 独占。device plugin 把每张物理卡上报为一个hygon.com/dcu资源单位用户申请 1 就是独占一张申请 2 就是独占两张。这种模式的优点是隔离彻底、行为可预期、适合大模型训练和需要确定性性能的推理缺点是碎片化严重——一张 64GB 卡跑个 7B 模型可能只用了 20GB剩下的 40GB 谁也碰不到。4.2 Device Plugin 上报的工作原理Device Plugin 是 K8s 的一组标准插件接口插件启动后通过 ListAndWatch 向 kubelet 提供设备列表kubelet 将这些设备作为扩展资源公布到节点状态上。调度器看到节点 capacity 里有 hygon.com/dcu: 4就知道这台机器有 4 张 DCU。Pod 调度后kubelet 会调用插件的 Allocate 接口由插件决定给容器注入哪些设备文件和环境变量。官方或社区常见的 DCU device plugin 支持环境变量配置文件比如通过环境变量控制 HIP 相关参数也支持在 Allocate 阶段设置 HIP_VISIBLE_DEVICES保证每个容器只能看到自己申请的那张卡。这个隔离依赖的正是 HIP_VISIBLE_DEVICES 的注入检查 Pod 环境变量是你排查容器里看到所有卡问题的第一步。4.3 裸 K8s 下整卡调度的 yaml一条最朴素的 DCU Pod 大概长这样直接用原生 K8s 发布的方式apiVersion: v1 kind: Pod metadata: name: dcu-whole-card-demo spec: restartPolicy: Never containers: - name: pytorch-dcu image: hub.example.com/dcu/pytorch:2.1.0-dtk24.04-py3.10 command: [sh, -c] args: - | dcu-smi hipcc --version sleep infinity resources: limits: hygon.com/dcu: 1一个关键点必须说清楚K8s 原生调度器对自定义扩展资源只支持按整数数量调度它不知道这张卡还剩多少显存。所以上面这个 yaml 里虽然申请了 1 张卡但如果同一台节点上已经有其他 Pod 占用了这张卡共享模式原生调度器是感知不到的这就需要 vDCU 或调度器扩展来兜底具体后面两章展开。4.4 验证整卡是否真的隔离Pod 起来后进容器执行 dcu-smi如果环境变量隔离生效你应该只能看到 1 张卡编号从 0 开始和宿主机的物理卡号无关。这一步验证通过才说明 device plugin 的 Allocate 阶段工作正常。5. 共享模式一张卡上跑多个 Pod 的折中方案5.1 共享的收益与代价整卡独占的资源浪费在推理场景尤其明显。很多小而多的推理任务比如一批轻量 embedding 服务、多个小模型的灰度版本显存只用到 10GB 左右却要占一整张 64GB 的卡。共享模式就是为了解决这种大卡小任务的错配一张物理卡拆成多个逻辑设备每个 Pod 申请其中一个逻辑设备。代价是共享会引入性能和稳定性的不确定性。多个容器共享一张卡HBM 带宽和算力是竞争关系一个跑满算力的任务会把同卡其他任务的延迟拉高。所以共享模式绝不是免费的弹性它适合负载峰谷明显的场景不适合所有任务都混在一起跑。5.2 共享模式怎么实现共享模式的实现关键在 device plugin通过配置把每张物理卡暴露成多个副本。比如你希望一张卡最多同时跑到 4 个容器就把 plugin 配置里的副本数设置为 4plugin 会向 kubelet 上报 hygon.com/dcu: 4×N。每个容器申请 1 个实际拿到的还是同一张物理卡只是 plugin 保证这张卡上同时运行的容器数不超过 4。注意共享模式下 device plugin 往往也需要注入不同的 HIP_VISIBLE_DEVICES但物理卡只有一张所以真正隔离的是并发数而不是显存。假如三个容器各占了 20GB 显存这张卡只有 64GB剩下的 4GB 一旦再有任务申请就会直接 OOM。设备插件通常不感知显存分配这属于共享模式和 vDCU 最本质的差异。5.3 共享模式最适合的落地场景我们用下来的体会是共享模式最适合两类任务一类是开发调试和 notebook占着卡跑交互式代码负荷低但需要快速响应另一类是轻量推理服务模型小、吞吐有限、对偶尔的延迟抖动不敏感。训练任务尽量不要放共享卡上反向传播的显存占用峰值很难预测万一 OOM 把整张卡上其他任务都拖下水这种事故我们出过一次之后就再也没敢混过。6. vDCU 虚拟化两条路线怎么选vDCU 是解决共享痛点更系统的方式。它和前面说的共享模式的区别是共享模式只做一个并发计数 环境变量注入而 vDCU 是驱动层面真正把一张 DCU 虚拟化出多个逻辑 DCU 设备每个逻辑设备有自己的显存视图和算力配额。目前我们实际用到的 vDCU 分两种侧重点完全不同。6.1 时间片型 vDCU时间片型 vDCU 的思路是多个逻辑设备共享同一张物理卡的算力由驱动按时间片轮转调度每个逻辑设备拥有独立的显存地址空间视图但显存总容量仍然是共享的。它适合的应用画像和共享模式很像但隔离性更好任务之间不会互相搞挂单个任务的崩溃不会导致整卡不可用。配置上通常在 device plugin 的配置文件里指定虚拟化模式。大致是这样{ virtualization: { mode: vdcu-timeslice, slices: 4 } }然后在 Pod 里申请对应资源即可。这里要注意时间片型 vDCU 对延迟敏感型任务不友好时间片切换意味着任务的实际执行会被打断长尾延迟会变大。所以我们在生产里只把时间片型 vDCU 给了测试环境和低优推理线上核心服务一个都不用。6.2 显存算力切分型 vDCU第二种 vDCU 是切分型可以类比大家更熟悉的 MIG 思路但实现细节不同一张物理卡按比例切分成多个独立逻辑卡每个逻辑卡拥有固定的显存上限和相对独立的算力资源。这种模式下这张卡的显存剩多少是可以被平台准确统计的调度器终于能按显存去匹配模型而不是靠数量去碰运气。切分型 vDCU 的配置和第一种类似但多了一个显存/算力配比的参数比如把 64GB 卡切成 2 个 32GB 或 4 个 16GB 逻辑卡。由于显存硬隔离业务之间的 OOM 不再互相传染这是它比前两种方案更接近生产可用的原因。但切分型 vDCU 也有代价一是切分粒度固定一旦按 4×16GB 切了你就没有 64GB 的整卡可用了需要在建集群前先规划好混合比例二是部分算子在小显存分区里可能性能下降尤其是需要大 KV Cache 的推理场景显存被切小后同一个 batch 能容纳的请求数变少吞吐反而下降。6.3 两种 vDCU 怎么选一张对照表维度时间片型 vDCU切分型 vDCU显存隔离无硬隔离总量共享固定显存上限硬隔离算力分配时间片轮转竞争式按切分配额相对独立适配场景开发调试、低优推理、批量小任务生产推理、多租户、SLA 明确调度感知只感知数量可感知显存上限最大风险长尾延迟、内存竞争切分粒度固定资源碎片在我们集群里最终方案是整卡 切分型 vDCU混部训练和大模型在线推理用整卡中小模型的在线推理用切分型 vDCU开发环境和跑批用共享模式。时间片型 vDCU 反而用得最少因为它的收益和共享模式重叠又比共享模式复杂除非你确实需要崩溃隔离否则性价比不高。7. 在 DCU 上部署 DeepSeek 的完整实操7.1 模型选型与权重准备DeepSeek 系列开源模型里R1 系列蒸馏版如 deepseek-r1-distill-qwen-7b/14b/32b是 DCU 单机单卡/双卡最现实的选择。V3 这种超大 MoE 模型不是不能跑但需要大规模多卡甚至多节点对大多数团队来说没必要第一时间挑战。我们选择 14B 蒸馏版作为服务主力单卡 64GB 显存可以吃下 FP16 权重加足量 KV Cache 和请求并发如果只有 32GB 卡就选 7B 或对模型做量化。权重下载后建议先做一次完整性校验然后解压到共享存储我们用的 NFS生产建议上并行文件系统或对象存储方便集群内多个节点复用同一份模型文件避免每个节点都拷贝一份。这一步虽然简单但在多节点推理场景里能省很多麻烦。7.2 推理框架选型vLLM 的 DCU 适配DCU 上跑 LLM 推理最主流的路线是用适配了 ROCm/HIP 的 vLLM。vLLM 对 DCU 的支持主要体现在PagedAttention 的显存管理、continuous batching、量化算子的 HIP 实现。如果你的镜像里没有适配好的 vLLM建议直接基于官方 PyTorch-DCU 镜像构建装上对应分支并验证版本与 DTK 的匹配关系。一个非常影响吞吐的参数是--gpu-memory-utilization它决定 vLLM 把多少百分比显存预留给 KV Cache。显存预留太低最大并发上不去太高又可能和 DCU 驱动自身的显存开销冲突。我们用 14B 模型时的经验值是 0.88~0.92具体根据模型大小和量化方式微调。7.3 在 K8s/CubeStudio 中发布 DeepSeek 推理服务以原生 K8s 方式发布一个 DeepSeek 在线推理服务核心是 Deployment Service。如果你的推理框架多卡并行还要注意 tensor parallel 的调度约束——两张卡最好在同一个节点上否则跨节点走网络通信吞吐会掉得很难看。apiVersion: apps/v1 kind: Deployment metadata: name: deepseek-r1-distill-14b spec: replicas: 1 selector: matchLabels: app: deepseek-r1 template: metadata: labels: app: deepseek-r1 spec: containers: - name: vllm-dcu image: hub.example.com/dcu/vllm:0.6.2-dtk24.04 command: [python, -m] args: - vllm.entrypoints.openai.api_server - --model - /models/deepseek-r1-distill-qwen-14b - --tensor-parallel-size - 1 - --max-model-len - 32768 - --gpu-memory-utilization - 0.9 - --port - 8000 ports: - containerPort: 8000 resources: limits: hygon.com/dcu: 1 cpu: 16 memory: 64Gi requests: hygon.com/dcu: 1 cpu: 8 memory: 32Gi --- apiVersion: v1 kind: Service metadata: name: deepseek-r1-svc spec: type: ClusterIP selector: app: deepseek-r1 ports: - port: 8000 targetPort: 8000在 CubeStudio 里操作更简单直接填模型路径、镜像、资源规格、副本数平台会生成等价的 K8s 对象。但要提醒多副本服务必须以无状态方式设计因为 vLLM 各副本之间不共享 KV Cache请求分发到哪个副本完全由上层决定如果你要靠副本数扛 QPS需要确认上层负载均衡策略符合预期。7.4 压测与调参启动后用 curl 验证接口curl http://service-ip:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: /models/deepseek-r1-distill-qwen-14b, messages: [{role: user, content: 你好介绍一下你自己}]}然后做并发压测。我们测下来几个关键结论一是--max-model-len别贪大32K 和 64K 对显存占用差距非常大除非业务真的有长上下文需求否则按 P99 请求长度加 20% 余量设二是并发请求到达 32 左右时单卡 14B 的吞吐就基本到瓶颈了再往上 QPS 涨不动延迟反而线性上升三是如果发现 DCU 利用率只有 40% 左右优先检查是不是 token 太短或模型并行方式不对而不是急着加卡。8. 从驱动到推理的踩坑排查链路这一章把我实际经历的几个坑按排查链路写出来比单给结论有用得多。8.1 容器里看不到 DCU 设备现象是 Pod 正常 Running但进容器执行 dcu-smi 报no DCU found或者 /dev/dcu 文件不存在。排查顺序先在宿主机执行 dcu-smi确认驱动正常、卡在线在宿主机用一个临时容器手动加 --device 参数确认容器运行时插件是否工作如果手动可以、K8s 不行检查 device plugin 的 DaemonSet 是否在节点上运行以及 plugin 日志里有没有 Allocate 调用检查 Pod 的 spec 是否真的带上了 hygon.com/dcu 的 limits很多平台模板会漏掉。我们当时的问题出在容器运行时配置没生效改完 daemon.json 后只重启了 dockerkubelet 缓存的容器运行时还是旧的导致注入失败。重启 kubelet 或者重启节点解决。8.2 Pod 一直 Pending 调度不上去现象是新提交的 DCU 任务一直 Pending描述里看到 0/8 nodes available: 8 Insufficient hygon.com/dcu。先别急着加机器按这个链路查kubectl describe node看 allocatable 里 hygon.com/dcu 的值是否大于 0如果节点上明明有卡但 allocatable 为 0查 device plugin 日志大概率是 plugin 上报失败或与 kubelet 握手异常如果 allocatable 正常但就是调度不出去检查 DaemonSet 是否真的在每个有卡节点上运行以及是否被 taint 挡住注意多卡任务申请 2 张卡的调度条件K8s 默认调度器是逐个节点匹配的如果 2 张卡分布在两个节点上你是拿不到 1 个 2 卡任务的这在大模型训练里尤其常见。如果是 CubeStudio 这类平台还要看平台自己的资源池是否把 DCU 节点正确纳管了。平台界面显示有卡、但底层没有打对 label也会导致任务永远在队列里。8.3 推理过程 OOM前几分钟正常并发一高就 OOM而且整卡上其他任务也跟着挂。这类 OOM 大多是 KV Cache 预留问题。vLLM 在启动时按 gpu-memory-utilization 预留显存但如果你切分型 vDCU 的逻辑卡本身显存就小0.9 的比例就会把显存吃光。我们的解法是把 gpu-memory-utilization 调低到 0.85并给 Pod 的 limits 留出 10%~15% 的显存水位宁可少几个并发也不要触发驱动级 OOM 把整张卡拖崩。还有一种场景是共享或时间片型 vDCU 下多个容器显存叠加超限这种就只能靠切分型 vDCU 或者物理上分开解决代码层面没有银弹。8.4 多卡通信性能远低于预期DeepSeek 多卡部署后总吞吐没有随卡数线性增长甚至掉到单卡的 70%。排查链路确认节点上多卡之间的互连拓扑。用 dcu-smi 或 rocm-smi 查看拓扑如果两张卡走的是 PCIe 而不是高带宽互连tensor parallel 通信开销会吃掉大部分收益检查是否设置了集合通信库的环境变量。DCU 的 HiCCL 通常需要配置 HCCL 相关环境变量比如绑定正确的网卡接口不设的话默认可能会走错误的路由检查 Pod 的 CPU 绑核情况。通信密集型任务如果 CPU 被调度到不同 NUMA 节点延迟会明显上升有条件就上拓扑感知调度比如 Kubernetes Topology Manager把 DCU 设备和 CPU/NUMA 绑定在同一区域。最后给个通用建议任何 DCU 问题先把宿主机原生环境能不能复现这个边界画出来。宿主机能复现问题大概率在驱动或 DTK宿主机能跑但容器不行问题在容器运行时或镜像容器可以但 K8s 不行问题在 device plugin、调度或平台。这个边界一画排查范围能缩小 80%。9. 生产环境的配置参考与优化建议9.1 我们最终采用的配置清单给一个可以直接抄的生产配置思路以 4 节点、每节点 8 张 64GB DCU 为例层面配置项我们的建议驱动DCU 驱动版本与 DTK 版本严格对应升级前看 release notes容器运行时Docker/containerd runtime配置 DCU runtime重启 dockerkubelet资源上报device pluginDaemonSet 部署按整卡共享vDCU 三种配置拆分调度显存感知用 CubeStudio 资源池按卡型隔离原生 K8s 考虑调度器扩展存储模型权重放并行文件系统多节点复用推理vLLM-DCUgpu-memory-utilization 0.88~0.92max-model-len 按业务定监控指标采集dcu-smi 定时采集显存/温度/利用率接 Prometheus每个节点既要保证有足够的 CPU 和内存给 DCU 任务一般建议至少 16 核 64GB 起步否则容易出现 CPU 等待导致 DCU 空转也要提前规划好网卡和存储带宽。很多团队只盯着 DCU 卡数最后卡利用率上不去一半原因是 CPU、网络、存储成了瓶颈。9.2 运维与监控的细节DCU 的监控和 NVIDIA 不太一样dcu-smi 输出项虽多但最需要盯的是显存占用率、温度、利用率以及卡是否进入 ECC 报错状态。建议在节点上用一个 DaemonSet 定期采集 dcu-smi 的 JSON 输出打到 Prometheus再在 Grafana 里按节点、按卡维度展示。这样当共享模式或时间片型 vDCU 下出现显存竞争时你能第一时间在监控上看到哪张卡在打抖而不是等业务方报障。日志和告警方面device plugin 和 vLLM 的日志都必须集中收集。我们吃过一次亏vLLM 因为一个请求触发了内部异常CPU 被打满但没有崩溃业务侧表现为请求超时由于日志散在节点上排查花了整整一个下午。后来把所有 Pod 日志接到统一的日志平台再按 model、service、node 三个维度打标签五分钟就能定位。9.3 后续可以扩展的方向DCU 集群跑稳之后可以往三个方向继续做深一是训练侧把 PyTorch-DCU 和 HiCCL 接入到分布式训练框架做更大规模模型预训练和微调的弹性调度二是推理侧接入更完整的服务网格和灰度发布能力让 DeepSeek 这类大模型服务可以平滑升级、按流量切分三是资源侧在 CubeStudio 上做更细粒度的配额和计费让不同业务团队按真实用量分摊成本。最后分享一个个人的小体会接 DCU 这件事最忌讳的是拿 NVIDIA 的整套方法论生搬硬套。DCU 有它自己的软件栈和生态节奏整卡、共享、vDCU 以及推理框架之间是全链路联动的不是某一个组件换一下就完事。我们也是从整卡入门被共享模式的显存坑过一次最后才依赖切分型 vDCU 把生产稳下来。如果你刚起步建议按先把整卡链路打穿 → 再引入共享/虚拟化 → 最后上推理框架的顺序走每一步都留足验证时间这样踩坑成本最低。