老周在“风味楼”掌勺二十年，灶台上那口进口珐琅锅（NVIDIA GPU）是他最趁手的兵器，一柜子的西式菜谱（CUDA 代码）更是反复打磨的传家宝。直到某天老板说：供应链不稳、成本太高，咱们换成国产精铁灶（海光 DCU），菜谱能迁就就迁就，迁就不了就让徒弟小海帮着“翻译”。 小海做的翻译工作很特别——不是把菜谱从头抄一遍，而是把“盎司换克、华氏换摄氏”，把用料、火候、步骤一一对应到新灶台的脾气上。这套“翻译层”就是 HIP/ROCm 兼容方案。而老周真正操心的是：翻译之后的菜，还能不能保住“风味楼”的招牌水准？本篇文章就以老周的厨房为镜，把海光 DCU 的架构、兼容、迁移与性能讲个通透。

岗位关联

对 AI 从业者而言，理解海光 DCU 等于掌握国产算力替代的核心技能——看懂架构定位、搞懂 CUDA 兼容原理、跑通迁移路径，是未来智算中心选型与部署的硬通货。

目录
  1. 可视化演示
  2. DCU起源定位：为什么老周要换灶
  3. 万象架构解析：灶台的分区布局
  4. CUDA兼容工程：菜谱翻译的艺术
  5. 软件栈生态：从灶台到整条后厨流水线
  6. 迁移实战路径：四步完成菜谱改编
  7. 性能表现剖析：招牌菜端上桌的那一瞬
  8. 国产算力格局：三家灶台各有脾气
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

三步展示海光DCU：硬件架构（DCU芯片→CU计算单元→Matrix Core→HBM,支持FP64/FP32/FP16/INT8）、DTK软件栈（CUDA代码→HIP接口→DTK工具包→ROCm兼容）、CUDA迁移兼容性（95%代码兼容+99%算子覆盖，迁移成本仅5%）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

海光DCU硬件架构 DCU芯片：GPGPU架构，多CU计算单元 Matrix Core: 矩阵乘加单元，支持多精度 HBM显存：高带宽存储 DCU = CU × N + Matrix Core + HBM 支持FP64/FP32/FP16/INT8四种精度。

DCU起源定位：为什么老周要换灶

老周那口珐琅锅最大的问题是“娇贵”——炉芯要进口、配件要预订，哪天断了货，招牌菜就得停售。老板一合计，决定换一口国产能量产、坏了随时能配件的“精铁灶”。这颗国产灶芯的学名，叫 DCU（深度计算单元，Deep Computing Unit），由海光信息主导设计，定位就是“中国厨房里的 GPGPU 全能灶”。

从技术脉络看，DCU 走的是 GPGPU（通用图形处理器）路线：像 GPU 一样堆大量并行计算核心，但又不像显卡那样执着于图形渲染，而是把火力全部集中在矩阵运算、张量计算这类 AI 负载上。与 CPU 相比，它牺牲了复杂的控制逻辑与中断处理，换来了成百上千倍的并行吞吐。这就像老周把炖煮的精细活儿交给文火灶（CPU），把爆炒的千次翻勺交给大猛火灶（DCU）。

三者的乘积就是“整桌菜”的出餐速率。海光选择拉高核心数这条路径，配合适中频率换高吞吐，这在 AI 训练这种“千菜同炒”的场景下，正是最划算的厨艺路线。老周看到这口灶，悬着的心放下了一半：火力够猛，接下来就看菜谱能不能套用了。

D=Ncore×f×OPScycle\displaystyle D = N_{\text{core}} \times f \times \text{OPS}_{\text{cycle}}
算力密度 D 由核心数、主频、每周期运算次数三者相乘决定，直观解释了为何堆并行核心比堆频率更能提升 AI 算力。
  1. 核心规模 N_coreDCU 内部集成的并行计算核心总数，类似灶台上灶眼数量，越多同时处理的“菜量”越大。
    NcoreN_{\text{core}}
  2. 工作频率 f核心每秒运行的时钟周期数（赫兹），决定每个灶眼的“翻勺速度”。
    ff
  3. 单周期吞吐 OPS_cycle每个时钟周期内单个核心能完成的浮点运算次数，好比一次翻勺同时颠起多少菜。
    OPScycle\text{OPS}_{\text{cycle}}

万象架构解析：灶台的分区布局

老周绕着新灶台转了三圈：左边是六个猛火灶眼（计算单元），中间是三层蒸屉（片内缓存），底下是巨大的蓄水池（高带宽显存），连接它们的是一条传菜电梯（高速互联总线）。这套布局在海光内部被称为“万象”架构——不是指一灶一炉，而是整个厨房系统的协同运转。

计算单元集群是绝对的主力，每个单元由大量流式处理器组成，支持 SIMT（单指令多线程）执行模型，一个指令广播出去能驱动成百上千个线程同时翻勺。存储层次则是典型的多级结构：每个计算单元自带小容量高速缓存（L1/L2），如同灶台边的调料盒，随手即取；而片外的大容量 HBM 显存则是仓库，容量大但取用稍慢。存储与计算之间有多条高带宽总线连接，决定“备菜速度”能否跟上“爆炒速度”。

带宽越高，矩阵搬运越快，计算单元越不容易“等菜下锅”。海光在存储系统上着重堆高带宽与缓存命中率，就是为了让“洗切配”（数据搬运）与“爆炒”（矩阵运算）尽量重叠。老周试了试灶眼和蒸屉的配合，点点头：至少这套布局，能同时应付八桌宴席的节奏。

B=fmem×Wbus8\displaystyle B = \frac{f_{\text{mem}} \times W_{\text{bus}}}{8}
访存带宽 B 等于显存等效频率乘以总线位宽再除以 8，它决定了数据从“仓库”搬到“灶台”的上限速度，是 AI 训练的隐形天花板。
  1. 等效频率 f_mem显存颗粒的实际数据传输频率，类似传菜电梯每秒运行的趟数。
    fmemf_{\text{mem}}
  2. 总线位宽 W_bus每一次传输能并排搬动的“托盘”数量（单位 bit），位宽越大，一趟能搬的菜越多。
    WbusW_{\text{bus}}
  3. 除以 8 字节换算把 bit 换算为字节（Byte），因为程序按字节寻址，除以 8 才能得到每秒搬运的字节数。
    Wbus8\frac{W_{\text{bus}}}{8}

CUDA兼容工程：菜谱翻译的艺术

真正的难题来了。老周的菜谱全是用“盎司、华氏度”写的（CUDA API），而新灶台只认得“克、摄氏度”（HIP API）。把上千道菜谱全部重写？那是小海三个月熬秃头也完不成的工程。海光的解法是请来一位“双语翻译官”——ROCm 开源平台与 HIP 编程模型。

HIP（Heterogeneous-Computing Interface for Portability）提供了一套与 CUDA 几乎一一对应的 API：cudaMalloc 对应 hipMalloc，cudaMemcpy 对应 hipMemcpy，__global__ 内核声明也只需替换为 __global__ 的 HIP 版本。这套映射不是粗暴的文本替换，而是由编译工具链在底层完成调度语义的对应，让同一份源码既能跑在英伟达 GPU 上，也能跑在海光 DCU 上，即“一次编写，双端编译”。

需要说明的是，CUDA 生态中有大量“生僻调料”：cuDNN 卷积库、cuBLAS 数学库、TensorRT 推理引擎等，这些并不在 HIP 的直接映射范围内。翻译官只能解决“语言”问题，解决不了“食材”问题——那些深度绑定英伟达库的代码，仍需要手工寻找或重写替代方案。老周听完小海的汇报，心里有底了：菜谱能保留九成，剩下的一成需要“本土化改良”。

C=NmappedNused×100%\displaystyle C = \frac{N_{\text{mapped}}}{N_{\text{used}}} \times 100\%
API 映射覆盖率 C 是已成功映射的 API 数量占程序使用的 CUDA API 总数的比例，它直接决定代码能“零改写”还是需要“局部返工”。
  1. 已映射 API 数 N_mappedHIP 运行时能提供等价语义替代的 CUDA API 数量，对应“翻译官”掌握的双语词汇量。
    NmappedN_{\text{mapped}}
  2. 实际使用 API 数 N_used老周菜谱里真正用到的洋词数量，如果只用到了常用词汇，翻译难度自然就低。
    NusedN_{\text{used}}
  3. 百分比换算两者相除得到覆盖率，覆盖率越接近 100%，说明菜谱主体无需大改，只需修正少数生僻词。
    ×100%\times 100\%

软件栈生态：从灶台到整条后厨流水线

光有灶台还开不了席。一道菜从下单到上桌，需要传菜员（驱动层）、打荷工（运行时）、掌勺师傅（框架层）和管事（调度工具）协同配合。海光为此打造了一整条软件栈生态，对标 CUDA 体系的 DTK（DCU Toolkit 开发套件）。

DTK 是海光的“工具库总线”，它提供了编译器（基于 LLVM 的 hipcc）、调试器、性能分析器（如类似于 ncu 的 profiler），以及大量数学库和通信库的实现。在它之上，PyTorch、TensorFlow、PaddlePaddle 等主流深度学习框架已完成适配——老周不用自己“研发锅铲”，直接拿起顺手的标准厨具就能干活。每一层都不是孤岛，而是层层调用的“流水线协作”。

三层开销此消彼长。DCU 的驱动层在设计上尽量复用成熟 Linux 内核调度机制，运行时也借鉴了 ROCm 的成熟路径，使得整体开销与原生 CUDA 相比增加得可控。老周在 DTK 加持下试了试 PyTorch 的训练任务，发现大部分“复杂菜式”（如 ResNet、Transformer 类模型）可以直接端上桌，心里踏实了不少——整套后厨流水线，转起来了。

Ototal=Odriver+Oruntime+Oframework\displaystyle O_{\text{total}} = O_{\text{driver}} + O_{\text{runtime}} + O_{\text{framework}}
单次训练迭代的总开销是驱动层、运行时、框架三层开销的叠加；层与层之间的转换和同步越频繁，额外损耗就越大。
  1. 驱动层开销 O_driverCPU 与 DCU 之间的指令提交与内存映射消耗的时间，类似传菜员把订单递进厨房的沟通耗时。
    OdriverO_{\text{driver}}
  2. 运行时开销 O_runtime内存分配、内核启动、流同步等运行时服务的耗时，对应打荷工备料和协调灶眼秩序的时间。
    OruntimeO_{\text{runtime}}
  3. 框架层开销 O_framework深度学习框架封装算子、管理梯度、组装计算图带来的额外损耗，类似掌勺师傅在标准化流程之外的多余动作。
    OframeworkO_{\text{framework}}

迁移实战路径：四步完成菜谱改编

翻译理论再完美，落地才是硬道理。老周和小海制定了一套四步走策略：先盘点（评估）、再翻译（移植）、后试菜（验证）、终调味（调优）。每一步都踩在新旧两个环境的交界处。

第一步是代码评估。小海写了个脚本扫描整个项目，统计用了哪些 CUDA API、是否涉及多 GPU 通信、是否依赖 cuDNN 等闭源库，输出一份“菜谱改造难度报告”。第二步是移植适配。将 CUDA API 替换为 HIP API，将 blockIdx、threadIdx 等线程模型保留——DCU 的线程模型与 CUDA 保持语义一致，这部分可以原样搬用。第三步是正确性验证。跑通单元测试与数值对比，确认翻译后的“菜”没把糖当盐。第四步是性能调优。通过 Profiler 定位访存热点和同步等待，用共享内存替代全局显示访问、合并流水线减少数据搬运。

真正让人头疼的是“生态陷阱”：使用了 NVTX 标注、CUDA Graphs 等高级特性，或依赖 cuDNN 中自定义算法（如某些卷积实现）的代码，HIP 并没有等价物，需要手工重构。老周的实操感悟是：评估越细心，后期返工越少；把“生僻调料”提前筛出来，才不会在宴席当天抓瞎。

R=LreuseLtotal×100%\displaystyle R = \frac{L_{\text{reuse}}}{L_{\text{total}}} \times 100\%
代码复用率 R 是无需修改即可直接编译运行的代码行数占总行数的比例，是衡量迁移成本的最直观指标。
  1. 复用行数 L_reuse不需要改动就可在 HIP 下编译通过的行数，主要包括纯算法逻辑、张量运算和基础 API 调用。
    LreuseL_{\text{reuse}}
  2. 总行数 L_total项目全部有效代码行数，包含核函数、内存管理、主机端逻辑等所有部分。
    LtotalL_{\text{total}}
  3. 复用率计算两者之比反映了“直接复用+轻量修改”的比例，一般典型工程可达到 60%-90% 的复用率。
    ×100%\times 100\%

性能表现剖析：招牌菜端上桌的那一瞬

所有努力最终都要落到同一句话上：这道菜，快不快，香不香？在真实训练任务中，海光 DCU 的表现可以用一组对比数据来刻画。以常见的 ResNet-50 图像分类训练为基准，DCU 直接运行 HIP 移植版的吞吐约为同档次 NVIDIA GPU 的 70%左右；经过算子融合、显存复用和内核并发调优后，可提升至 85%-90%；多卡互联场景下，DCU 的高速互连能支撑近线性扩展，8 卡集群效率可维持在 90% 上下。

这些数字背后的物理约束，可以用一个加速比公式来解剖。老周的直觉是：灶台火力（峰值算力）再猛，配菜（数据搬运）跟不上、灶眼之间（同步协作）互相等，出菜速度照样上不去。

从公式能清晰看到：如果访存占比高，那么提升有效带宽（如利用共享内存、合并访问）比提升峰值算力更管用；如果同步开销高，就要减少内核启动次数、使用流并发或图执行。老周看着 Profiler 的瓶颈分析，像厨师长审视一道慢菜的每个环节——找到了“坨火候”，就找到了优化的钥匙。

S=Tcompute+Tmem+TsyncTcompute′/U+Tmem′/Beff+Tsync′\displaystyle S = \frac{T_{\text{compute}} + T_{\text{mem}} + T_{\text{sync}}}{T'_{\text{compute}}/U + T'_{\text{mem}}/B_{\text{eff}} + T'_{\text{sync}}}
加速比 S 等于原平台总耗时除以 DCU 平台总耗时。分子是计算、访存、同步三段耗时之和；分母各段被硬件利用率 U 与有效带宽 B_eff 放大或缩小，一眼看出瓶颈在哪里。
  1. 计算耗时 T_computeGPU 核心实际执行数学运算的时间，原平台与 DCU 平台的差异在于核心频率和单周期吞吐。
    TcomputeT_{\text{compute}}
  2. 访存耗时 T_mem数据在全局显存与缓存之间搬运的时间。DCU 侧除带宽外，还要考虑实际可达带宽 B_eff 与理论峰值的差距。
    Tmem=数据量BeffT_{\text{mem}} = \frac{\text{数据量}}{B_{\text{eff}}}
  3. 同步开销 T_sync内核启动、多卡通信、主机与设备同步的等待时间，类似多个灶眼等一锅高汤熬好的时间。
    TsyncT_{\text{sync}}
  4. 利用率 U 的放大作用如果 DCU 计算单元利用率只有 70%，那理论计算时间要被放大 1/U 倍，这就是迁移后跑分打折的根源。
    Tcompute′U\frac{T'_{\text{compute}}}{U}

国产算力格局：三家灶台各有脾气

把海光 DCU 放回“国产 AI 芯片”这张大桌上，旁边还坐着另外两口灶：寒武纪和燧原。三者定位不同，各有一批拥趸。寒武纪的 MLU 系列以自研架构和专用 AI 加速著称，在 CNN 推理等特定负载上能效比亮眼，但通用性较弱，CUDA 代码迁移到 MLU 基本等于“重写菜谱”；燧原的云燧 T20 主打云端训练与推理，自研架构配合自己的软件栈，在数据中心场景发力，但生态同样相对封闭。

海光 DCU 的差异化王牌是“兼容”——因为走 GPGPU + HIP 路线，大量现有 CUDA 代码能用较低成本迁移，这让它在“存量替换”市场占据先机。选用哪家，本质上回答一个问题：你的团队打算花多少成本适配，换取多少国产化收益？老周的老板最后选了 DCU，理由朴素：老菜谱能留住，老师傅不用改行，供应链还稳。

从长远看，国产算力格局会从“一家独大”演变为“各擅胜场”：推理市场认寒武纪的能效，训练市场看燧原的集群，存量迁移市场押海光生态。老周最后的总结是：灶台没有绝对的好坏，只有合不合自家的菜系。他选择了海光 DCU，因为那套珍藏多年的西式菜谱，终于找回了国产灶台上的用武之地。

V=Perf×α×βCost\displaystyle V = \frac{\text{Perf} \times \alpha \times \beta}{\text{Cost}}
性价比 V 由性能 Perf、生态兼容系数 α、供应链安全系数 β 共同决定，除以总拥有成本 Cost；三个因素相乘，意味着任一项偏低都会显著拉低综合价值。
  1. 性能 Perf芯片在目标负载上的实测吞吐或训练速度，是各家的口碑底线。
    Perf\text{Perf}
  2. 生态兼容 αCUDA/已有代码可复用程度，α 越高，团队迁移成本越低——这是 DCU 的主场优势。
    α\alpha
  3. 供应链安全 β在制裁加剧背景下，稳定供货与自主可控的加成系数。
    β\beta
  4. 总拥有成本 Cost采购价、改造成本、运维成本、人力成本的总和。
    Cost\text{Cost}

AI 应用场景

大模型训练平台的国产化迁移

阶段：模型训练与资源调度

解决的问题：传统智算中心完全依赖英伟达 GPU，面临采购周期长、供应不稳定、成本高企等痛点。海光 DCU 基于 HIP 的兼容方案，使存量 CUDA 训练代码可迁移复用，避免“推倒重来”的巨额开发成本，同时满足国产化合规要求。

具体案例：某金融科技公司的风控大模型原跑在 8 卡 V100 集群上，模型基于 PyTorch 实现。团队用 HIP 工具链扫描 4.7 万行代码，API 自动映射率达 92%，剩余手工修改集中在自定义算子与 NCCL 通信库替换上。迁移至海光 DCU 集群后，单卡训练吞吐为原平台的 76%，经算子融合与显存复用调优后达 89%，满足上线要求。

智算中心异构算力池的统一调度

阶段：基础设施选型与统一调度

解决的问题：大型智算中心往往需要混合使用不同厂商芯片，但各家软件栈互不兼容导致调度困难。海光 DCU 兼容 CUDA 生态的特性，使其更容易接入现有 Kubernetes 调度体系与容器化训练平台，实现“异构芯片看起来像同一种芯片”。

具体案例：某省级智算中心规划了 100P 算力池，其中 60% 采用海光 DCU，其余为存量英伟达 GPU。平台通过接入 HIP 编译方案与统一容器镜像，使上层 PyTorch 任务无需区分物理芯片即可调度。运营数据显示，混合集群的平均 GPU 利用率比纯英伟达集群仅低 4 个百分点，但整体算力成本下降约 35%。

Python 演示

python61 行
# -*- coding: utf-8 -*-"""CUDA 代码迁移到海光 DCU 的兼容性评估器"""import re CUDA_TO_HIP = {    'cudaMalloc': 'hipMalloc',    'cudaMemcpy': 'hipMemcpy',    'cudaFree': 'hipFree',    'cudaDeviceSynchronize': 'hipDeviceSynchronize',    'cudaGetLastError': 'hipGetLastError',    'cudaLaunchKernel': 'hipLaunchKernel',} class MigrationAdvisor:    def __init__(self, code_lines):        self.code_lines = code_lines        self.api_count = 0        self.hit_count = 0        self.block_conflicts = []        self.free_lists = []     def analyze(self):        self.free_lists = []        for line in self.code_lines:            for cuda_api, hip_api in CUDA_TO_HIP.items():                if cuda_api in line:                    self.api_count += 1                    self.hit_count += 1                    self.free_lists.append((cuda_api, hip_api))            if 'blockIdx' in line or 'threadIdx' in line:                self.block_conflicts.append(line.strip())        return self.score()     def score(self):        if self.api_count == 0:            return 0.0        base = self.hit_count / self.api_count        penalty = min(len(self.block_conflicts) * 0.04, 0.4)        return round(max(base - penalty, 0.0), 2) def main():    sample = [        "cudaMalloc(&d_a, size);",        "cudaMemcpy(d_a, h_a, size, cudaMemcpyHostToDevice);",        "kernel<<<grid, block>>>(d_a);",        "cudaDeviceSynchronize();",        "cudaFree(d_a);",    ]    advisor = MigrationAdvisor(sample)    score = advisor.analyze()    print("迁移兼容评分:", score)    print("API 替换建议:")    for cuda_api, hip_api in advisor.free_lists:        print("  ", cuda_api, "->", hip_api)    if advisor.block_conflicts:        print("注意: 行内含 blockIdx/threadIdx, 请确认线程模型:")        for line in advisor.block_conflicts:            print("  ->", line) if __name__ == '__main__':    main()
目的：模拟迁移工程师的调研工作——扫描 CUDA 源码中的 API 调用与线程模型，计算迁移兼容评分并输出替换建议，帮助团队预判工作量。
  1. CUDA_TO_HIP = {...}维护一张“双语词典”，把常见 CUDA API 映射为对应的 HIP API，如同菜谱翻译中的词汇表。
  2. self.free_lists = []用列表记录每一条匹配到的映射关系，为最终输出替换建议做数据准备。
  3. def analyze(self):核心扫描方法，逐行检查代码中出现的 CUDA API 和线程索引变量。
  4. if 'blockIdx' in line or 'threadIdx' in line:特殊标记线程模型相关行，提示迁移者需要核验 DCU 下的语义一致性。
  5. base = self.hit_count / self.api_count计算 API 映射覆盖率，即无需手工处理的词汇占比。
  6. penalty = min(len(self.block_conflicts) * 0.04, 0.4)每出现一处线程模型风险点扣 4 分，最高扣 40 分，模拟“生僻词”带来的附加工作量。

常见误区

误区既然海光 DCU 兼容 CUDA，那我把 .cu 文件拿来重新编译一下就能跑，一行代码都不用改。

正解DCU 并不在指令级兼容 x86 GPU 生态，它的“兼容”是通过 HIP 翻译层实现的。你可以把 HIP 理解为一座翻译桥——桥能过去，但需要先确认你用的“词汇”在桥对岸有对应词。API 能自动映射，但涉及 cuDNN、NCCL 等闭源库的代码无法翻译，必须手工替换或重构。

为何常见：厂商宣传中“兼容 CUDA”过于亮眼，让很多人误以为是“即插即用”，忽略了兼容层的语义鸿沟。

误区cuDNN 和 cuBLAS 是 CUDA 生态的一部分，DCU 既然兼容 CUDA，这些库自然也能用。

正解cuDNN、cuBLAS、TensorRT 是 NVIDIA 的闭源库，只绑定自家 GPU，HIP 无从映射。DCU 生态提供的是类似功能的开源替代（如 rocBLAS、MIOpen 或海光自研数学库），但算子覆盖度和性能表现需要重新验证。老周换国产灶后，进口浓缩高汤（闭源库）用不了，得用自己熬的骨汤（开源/自研库）替代，味道要重新调。

为何常见：很多人把“兼容 CUDA 编程模型”等同于“全盘接受 NVIDIA 软件栈”，混淆了编程接口与闭源运行时。

误区把 `cudaMalloc` 改成 `hipMalloc`、`cudaMemcpy` 改成 `hipMemcpy` 就是完成了迁移，内存管理方面应该没差别。

正解HIP 虽然保持内存模型语义一致，但 DCU 的显存带宽、页表管理、统一内存实现与 NVIDIA 存在差异。忽略这些差异，即使跑通也可能性能损失 20%-30%。正确做法是：替换 API 后，用 Profiler 分析访存模式，把分散的显存访问改为合并访问，必要时引入共享内存做数据复用，才算真正适配了“新灶台的传菜系统”。

为何常见：文本替换的“可见工作量”极低，让人误以为任务已完成，而性能验证的隐性工作容易被忽视。

误区DCU 单卡训练速度达到英伟达 GPU 的 85%，那 8 卡集群就是单卡的 8 倍，整体乘以 0.85 就行。

正解集群扩展性能取决于高速互联而非单卡算力。DCU 的多卡通信依赖其特有的互联总线和集合通信库（类似 NCCL 的角色），如果通信库未针对 DCU 拓扑优化，8 卡扩展效率可能只有 60%-70%。公式里的 T_sync 项会在多机多卡场景急剧放大，软件栈的调优程度直接决定集群的真实性价比。

为何常见：人们习惯用单卡指标外推集群性能，忽略了 Amdahl 定律中串行通信部分对扩展性的钳制作用。

面试题

Q1. 海光 DCU 最核心的设计路线是哪一种？

单选题 · easy

  • A.专用 ASIC 加速张量运算
  • B.GPGPU 通用并行架构路线← 正确答案
  • C.FPGA 动态可重构逻辑
  • D.CPU 与 NPU 异构融合方案

答案：B。海光 DCU 走的是 GPGPU 路线，类似通用 GPU 一样堆并行核心但专注计算而非渲染。ASIC（寒武纪）、FPGA（部分加速卡）、CPU+NPU（融合芯片）都是其他技术路线，不是 DCU 的核心定位。

Q2. DCU 实现兼容 CUDA 编程模型的关键桥梁是？

单选题 · easy

  • A.通过 CUDA Driver API 直接调用
  • B.基于 ROCm 与 HIP 翻译层桥接← 正确答案
  • C.借助 TensorRT 解析器翻译
  • D.依赖 ONNX Runtime 后端加速

答案：B。DCU 的兼容实现基于 AMD 开源的 ROCm 平台与 HIP 编程模型，HIP 提供与 CUDA 一一对应的 API 映射。选项 A 不可能（NVIDIA 驱动不开放给 DCU），C 和 D 分别是英伟达推理库和模型交换格式，与硬件兼容无关。

Q3. 海光 DCU 的“万象”架构中，以下哪些属于其核心组成？

多选题 · mid

  • A.流式多处理器集群← 正确答案
  • B.片外主存与片内缓存← 正确答案
  • C.高带宽互联总线← 正确答案
  • D.光刻机纳米制程

答案：ABC。计算单元集群、存储层次、互联总线是芯片架构的三要素，共同决定算力、带宽与扩展性。光刻制程属于制造工艺而非芯片组成，虽然影响频率和功耗，但不在“架构”的讨论范围内。

Q4. 将一段 CUDA 程序迁移到海光 DCU 时，核心工作是？

单选题 · mid

  • A.重写全部 Python 脚本文件
  • B.将 CUDA API 映射为 HIP API← 正确答案
  • C.更换底层操作系统为 Windows
  • D.完全忽略 GPU 内存模型与拷贝

答案：B。迁移核心是把 cudaMalloc/cudaMemcpy 等 API 替换为 HIP 等价 API，同时验证线程模型语义一致性。Python 脚本通常不涉及直接 CUDA 调用，操作系统与 DCU 兼容性无关，忽略内存模型必然导致性能断崖。

Q5. 与寒武纪 MLU 相比，海光 DCU 的差异化优势体现在哪些方面？

多选题 · mid

  • A.兼容 CUDA 生态迁移成本较低← 正确答案
  • B.采用 x86 处理器架构
  • C.支持 HPC 通用计算负载← 正确答案
  • D.基于 GPGPU 路线拥抱开源生态← 正确答案

答案：ACD。DCU 走 GPGPU+HIP 路线，CUDA 代码可低成本迁移，并依托 ROCm 生态支持 HPC 通用计算。选项 B 错误——DCU 是加速协处理器，并非 x86 架构处理器。

Q6. 关于 DCU 迁移中 blockIdx/threadIdx 的处理，下列说法正确的是？

单选题 · mid

  • A.必须删除，DCU 并不支持线程块
  • B.语义完全一致，可帮助映射线程块与线程← 正确答案
  • C.需改名为 pidx 和 didx 专用接口
  • D.仅影响性能，不影响功能正确性

答案：B。HIP 完整保留了 CUDA 的线程层次模型，blockIdx/threadIdx 语义一致，代码可直接复用。A、C 是虚构说法；D 错误——线程索引同时影响正确性与性能，索引错位会导致数据错乱。

Q7. DTK 工具包在海光 DCU 软件栈中扮演的核心角色是？

单选题 · hard

  • A.对标 CUDA Toolkit 的开发套件← 正确答案
  • B.用于深度学习超参搜索的库
  • C.提供海量数据标注的服务
  • D.充当分布式文件存储系统

答案：A。DTK（DCU Toolkit）是海光提供的完整开发工具链，包含 hipcc 编译器、调试器、性能分析器与数学库，定位对标 NVIDIA 的 CUDA Toolkit。其余选项均与开发套件职能无关。

Q8. 以下哪些是影响 DCU 实际训练性能的典型瓶颈？

多选题 · hard

  • A.内核启动同步开销较大← 正确答案
  • B.片外显存带宽严重不足← 正确答案
  • C.共享内存银行冲突严重← 正确答案
  • D.驱动未适配特定内核代码

答案：ABC。内核启动同步、显存带宽、共享内存冲突是加速卡三大经典性能瓶颈，在 DCU 上同样适用。选项 D 的“内核代码”是指操作系统内核，与 CUDA 内核（kernel）概念混淆，迁移性能问题不涉及操作系统内核适配。

Q9. 智算中心选择海光 DCU 替代英伟达 GPU，首要的决策考量通常是？

单选题 · easy

  • A.提高游戏画面渲染帧率
  • B.规避供应链风险与国产可控← 正确答案
  • C.兼容 Windows 桌面生态
  • D.缩短 CPU 指令执行周期

答案：B。国产算力替代的核心驱动力是供应链安全与自主可控。DCU 不针对游戏渲染（A 错误），其软件栈以 Linux 服务器生态为主（C 错误），且 DCU 是协处理器，不改动 CPU 指令周期（D 错误）。

Q10. 某团队将训练代码迁移到 DCU 后性能仅达原平台的 70%，最值得优先执行的优化手段是？

单选题 · hard

  • A.增加 printf 调试日志信息
  • B.优化访存连续性与内核并行度← 正确答案
  • C.升级显示器分辨率参数
  • D.提升 CPU 睿频主频上限

答案：B。迁移后性能损耗通常源于访存模式未适配与并行度不足。用 Profiler 定位后，优先做合并内存访问、共享内存复用、提高内核占用率，能有效逼近峰值带宽。打印日志、显示器分辨率、CPU 主频均与 DCU 性能无关。