1. 项目缘起与整体架构思路
1.1 为什么选择海光DCU做推理落地
第一次接触海光DCU是在一个国产化替代的推理项目中，当时团队面临一个很现实的问题：手里有一批已经调优好的大模型权重，但目标部署环境只有国产加速卡可用。摆在面前的选择无非两条路——要么把模型重新适配到别的推理框架上，要么找到一条能在国产卡上跑通且性能可接受的路径。我们最终选了后者，核心原因有三个：一是模型权重迁移成本最低，二是海光DCU的软件栈对主流推理框架的兼容度比预期好，三是长期运维角度看，国产化环境下的自主可控性更符合项目要求。
海光DCU本质上是一块通用计算加速卡，它的软件栈提供了类似CUDA的编程接口，官方称之为DTK（DCU Toolkit）。这意味着大量基于CUDA生态写的推理代码，理论上可以通过一定的适配工作迁移过来。但“理论上可以”和“生产环境稳定跑”之间，隔着一条不小的鸿沟。我踩过的坑包括驱动版本与DTK版本不匹配、推理框架编译时找不到正确的后端、多卡并行时通信库配置错误等等。这篇笔记就是把这些经验完整地梳理出来，从环境搭建一直讲到稳定运维，适合正在做或准备做国产加速卡推理落地的同行参考。
1.2 整体部署架构拆解
我们的部署架构并不复杂，但每一层都有讲究。最底层是物理服务器，搭载海光DCU加速卡，服务器通过PCIe总线与DCU通信。往上一层是操作系统层，我们选的是主流Linux发行版，内核版本需要与DCU驱动兼容。再往上是DTK软件栈，包括驱动、运行时库、编译器、通信库等。最上面才是推理框架层，我们用的是主流的大模型推理框架，通过DTK提供的后端接口调用DCU算力。
这个架构里最容易出问题的环节是DTK软件栈与推理框架的衔接。很多教程只告诉你“装好驱动就行”，但实际上驱动只是第一步，后面还有运行时库的路径配置、环境变量设置、框架编译时的后端选择等一系列操作。我见过不少团队卡在“驱动装好了，但推理框架识别不到DCU”这一步，排查半天发现是环境变量没配对。
提示：在开始任何安装操作之前，先用官方提供的检测工具确认DCU硬件被系统正确识别。如果这一步就出问题，后面所有工作都是白费。
1.3 版本选型的核心考量
版本选型这件事，我的经验是：不要追新，要追稳。海光DCU的DTK版本迭代比较快，但推理框架对DTK版本的支持往往滞后。我们最终选的组合是：操作系统用较新的稳定版内核，DTK用官方文档明确标注支持推理框架的版本，推理框架用其稳定分支。这个组合不是性能最优的，但经过实测，是稳定性最好的。
具体来说，选DTK版本时要重点看两个东西：一是该版本是否包含你需要的通信库版本，二是该版本是否被你的推理框架官方文档列为支持版本。这两个条件缺一不可。我曾经试过一个更新的DTK版本，性能确实有提升，但推理框架编译时一直报链接错误，折腾了两天最后还是退回旧版本。
2. 环境搭建的完整实操流程
2.1 操作系统准备与内核适配
操作系统这块，我们用的是主流Linux发行版的最新稳定版。安装时有一个关键点：不要选最小化安装，因为后续编译推理框架需要大量的开发工具和依赖库。我建议至少选带开发工具的标准安装，省得后面一个个补依赖。
内核适配是第一个容易翻车的地方。DCU驱动对内核版本有明确要求，太新或太旧都可能有问题。安装完系统后，先确认当前内核版本，然后对照DTK文档里的兼容性列表检查。如果不匹配，要么升级内核，要么换系统版本。这一步千万别偷懒，我见过有人强行装驱动，结果系统直接起不来。
# 查看当前内核版本 uname -r # 查看系统发行版信息 cat /etc/os-release确认内核版本后，还需要安装内核头文件和开发包，因为DCU驱动编译时需要用到。这一步在有些系统上默认没装，需要手动补上。
# 以主流发行版为例，安装内核开发包 sudo apt install linux-headers-$(uname -r) build-essential2.2 DCU驱动与DTK安装细节
驱动安装是整个环境搭建里最需要耐心的环节。官方提供的驱动安装包通常是一个run文件，执行后会有图形化或命令行界面引导。我的建议是全程用命令行模式安装，因为图形界面在某些服务器环境下可能显示异常。
安装驱动前，必须确保系统里没有残留的旧版本驱动。如果有，先用官方卸载脚本清理干净。然后禁用系统自带的nouveau驱动（如果之前装过其他加速卡驱动的话），避免冲突。安装过程中会提示是否安装DKMS模块，建议选是，这样内核升级后驱动能自动重新编译。
# 给驱动安装包添加执行权限 chmod +x dcu_driver_xxx.run # 以命令行模式安装 sudo ./dcu_driver_xxx.run --silent # 安装完成后验证驱动 lsmod | grep dcu驱动装好后，接下来装DTK。DTK通常是一个大的软件包集合，包含运行时、编译器、数学库、通信库等。安装方式有离线包和在线源两种，生产环境建议用离线包，版本可控。安装完成后需要配置环境变量，把DTK的库路径和可执行文件路径加到系统配置里。
# 在~/.bashrc或/etc/profile.d/下添加环境变量 export DTK_HOME=/opt/dtk export PATH=$DTK_HOME/bin:$PATH export LD_LIBRARY_PATH=$DTK_HOME/lib:$LD_LIBRARY_PATH注意：环境变量配置完后一定要source一下或者重新登录，否则当前终端不生效。这个坑我踩过不止一次，明明装好了却找不到命令，折腾半天发现是没刷新环境。
2.3 推理框架的编译与后端配置
推理框架的编译是另一个关键环节。我们用的框架支持多种后端，编译时需要显式指定使用DCU后端。编译前的依赖检查很重要，缺任何一个依赖都可能导致编译失败。建议先把框架文档里列出的依赖全部装齐，再开始编译。
编译时的参数配置有几个关键点：一是要指定DTK的安装路径，二是要开启DCU后端支持，三是要根据实际使用的DCU型号设置计算能力参数。这些参数在框架的编译文档里通常有说明，但不同版本可能略有差异，需要仔细对照。
# 以某推理框架为例的编译配置 mkdir build && cd build cmake .. \ -DUSE_DCU=ON \ -DDTK_PATH=/opt/dtk \ -DDCU_ARCH=xxx \ -DCMAKE_BUILD_TYPE=Release make -j$(nproc)编译完成后，先跑框架自带的测试用例，确认DCU能被正确识别和调用。如果测试用例跑不通，后面部署模型肯定也不行。测试通过后再进行模型转换和部署。
2.4 环境验证与常见安装问题
环境装完后，我习惯做一个完整的验证流程：先用DTK自带的工具查看DCU状态，再用推理框架的测试程序跑一个简单模型，最后用实际业务模型做一次推理测试。这三步都通过，才算环境真正可用。
安装过程中最常见的问题有三个：一是驱动装完但系统识别不到DCU，通常是内核模块没加载或版本不匹配；二是DTK装完但推理框架编译时报找不到库，通常是环境变量没配好；三是编译通过但运行时崩溃，通常是通信库版本冲突。这三个问题的排查思路在后面的章节会详细展开。
3. 模型部署与推理性能调优
3.1 模型格式转换与权重加载
大模型部署的第一步是模型格式转换。我们拿到的原始权重通常是训练框架的格式，需要转换成推理框架支持的格式。转换过程中有几个关键点：一是要确保转换工具版本与推理框架版本匹配，二是要检查转换后的模型精度是否与原始模型一致，三是要注意模型的分片策略。
模型分片是个容易被忽视的细节。大模型参数量大，单卡显存放不下时就需要分片。分片策略直接影响推理性能和显存占用。我们的经验是：优先按层分片，尽量让每张卡的计算量均衡。如果按参数分片，可能会出现某些卡计算量大、某些卡空闲的情况。
# 模型转换示例（伪代码） from converter import ModelConverter converter = ModelConverter( input_path="./original_model", output_path="./converted_model", target_format="inference_format", precision="fp16", shard_num=4 ) converter.convert()转换完成后，用推理框架的加载工具加载模型，确认能正常读取。加载时要注意显存分配策略，有些框架支持动态显存分配，有些需要预分配。预分配的好处是运行时不会因为显存不足而崩溃，坏处是启动慢且占用固定显存。
3.2 推理参数配置与批处理策略
推理参数配置直接决定性能和效果。核心参数包括批处理大小、最大序列长度、采样参数等。批处理大小需要根据显存容量和延迟要求来权衡：批越大吞吐越高，但延迟也越大，且显存占用成倍增加。
我们的做法是先做一轮压力测试，找到显存占用的拐点。具体操作是：固定序列长度，逐步增大批处理大小，观察显存占用和推理延迟的变化。当显存占用接近上限或延迟超过业务要求时，就取前一个批大小作为生产配置。
| 批处理大小 | 显存占用 | 单次推理延迟 | 吞吐量 |
|---|---|---|---|
| 1 | 较低 | 最低 | 最低 |
| 4 | 中等 | 中等 | 中等 |
| 8 | 较高 | 较高 | 较高 |
| 16 | 接近上限 | 高 | 最高 |
提示：生产环境建议留20%左右的显存余量，避免突发流量导致显存溢出。我见过因为没留余量，高峰期推理服务直接崩溃的案例。
3.3 多卡并行与通信优化
多卡并行是提升吞吐的关键手段。海光DCU支持多种并行策略，包括数据并行、张量并行和流水线并行。我们主要用的是张量并行，因为大模型的单层参数量就很大，数据并行解决不了单卡显存放不下的问题。
通信优化是多卡并行的核心。DCU之间的通信通过专用的通信库实现，配置不当会成为性能瓶颈。关键配置包括通信域的大小、通信算法的选择、通信缓冲区的设置等。我们的经验是：小规模并行用默认配置就行，大规模并行需要手动调优通信算法。
# 通信库环境变量配置示例 export NCCL_DEBUG=INFO export NCCL_IB_DISABLE=1 export NCCL_SOCKET_IFNAME=eth0通信库的调试信息很有用，遇到通信超时或失败时，打开调试日志能看到具体的通信过程和错误原因。但生产环境不建议一直开着，因为日志量很大，会影响性能。
3.4 性能调优的实操记录
性能调优是个迭代过程。我们的调优顺序是：先调单卡性能，再调多卡通信，最后调服务层。单卡性能调优主要看计算利用率和显存带宽利用率，如果计算利用率低，可能是批大小太小或算子实现效率低；如果显存带宽利用率低，可能是数据加载或预处理成了瓶颈。
多卡通信调优主要看通信耗时占比。如果通信耗时超过总耗时的20%，就需要优化通信配置。我们试过调整通信算法、增大通信缓冲区、改用更高效的通信原语，最终把通信耗时降到了10%以下。
服务层调优主要看请求排队和调度策略。我们的做法是给推理服务加一个请求队列，按批处理大小动态组批，避免单个请求占用整卡资源。这个策略把吞吐量提升了将近一倍。
4. 生产环境稳定运维与问题排查
4.1 监控体系搭建与关键指标
生产环境的稳定运维离不开完善的监控体系。我们监控的指标分三层：硬件层、系统层和应用层。硬件层主要看DCU的温度、功耗、显存占用、计算利用率；系统层看CPU、内存、磁盘、网络；应用层看推理延迟、吞吐量、错误率、队列长度。
监控工具我们用的是主流开源方案，DCU的监控数据通过DTK提供的接口采集。关键指标要设置告警阈值，比如显存占用超过90%告警、推理延迟超过业务要求告警、错误率超过1%告警。告警要分级，不同级别对应不同的处理流程。
# DCU状态查看命令示例 dcu-smi # 输出包括温度、功耗、显存使用、计算利用率等信息注意：dcu-smi的输出格式在不同DTK版本间可能有差异，监控脚本要做好版本适配。我们之前升级DTK后监控脚本直接失效，排查了半天才发现是输出格式变了。
4.2 常见故障与排查思路
生产环境遇到的故障大致分几类：硬件故障、驱动故障、框架故障、模型故障。硬件故障最直接，dcu-smi能看到异常，比如温度过高、显存报错等。驱动故障通常表现为设备突然不可用，需要重启驱动或系统。框架故障表现为推理报错或崩溃，需要看框架日志。模型故障表现为输出异常，需要检查模型加载和输入数据。
排查思路我总结了一个原则：从下往上查。先确认硬件正常，再确认驱动正常，再确认框架正常，最后确认模型正常。这个顺序能避免很多无效排查。我见过有人一上来就查模型，结果发现是驱动掉了，白白浪费半天时间。
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| 设备不可见 | 驱动未加载 | 检查lsmod和dmesg |
| 推理崩溃 | 显存不足 | 检查dcu-smi显存占用 |
| 输出异常 | 模型加载错误 | 检查模型转换日志 |
| 通信超时 | 通信库配置错误 | 打开通信库调试日志 |
| 性能下降 | 温度过高降频 | 检查DCU温度和功耗 |
4.3 长期运行稳定性保障
长期运行的稳定性保障，我的经验是做好三件事：定期巡检、版本管理、容量规划。定期巡检包括检查硬件状态、清理日志、更新监控阈值。版本管理包括记录每次变更的版本号和配置，方便回滚。容量规划包括根据业务增长预测资源需求，提前扩容。
我们还做了一个自动化巡检脚本，每天定时跑一次，检查所有关键指标并生成报告。这个脚本帮我们提前发现了好几次潜在问题，比如显存泄漏、温度异常等。显存泄漏是个隐蔽的问题，短期看不出来，跑几天后显存占用越来越高，最终导致服务崩溃。自动化巡检能通过趋势分析提前发现。
4.4 运维避坑经验与实操心得
运维这块我踩过的坑不少，挑几个典型的说说。第一个坑是日志管理，推理服务的日志量很大，如果不做轮转，磁盘很快就会被写满。我们的做法是配置日志轮转，按天切割，保留最近7天。第二个坑是模型更新，更新模型时需要先停服务再替换文件，否则可能出现新旧模型混用的情况。第三个坑是资源隔离，多个推理服务跑在同一台机器上时，要做好显存和计算资源的隔离，避免互相影响。
还有一个容易被忽视的点是时间同步。多卡并行推理时，如果各卡所在节点的时间不同步，通信可能会出问题。我们统一配置了时间同步服务，确保所有节点时间一致。这个细节在单机部署时可能不重要，但多机多卡部署时非常关键。
最后分享一个实用技巧：给推理服务加一个健康检查接口，定期检查服务状态和DCU状态。负载均衡器通过这个接口判断服务是否可用，不可用时自动摘除。这个机制在DCU出现偶发故障时特别有用，能避免请求打到故障节点上。
5. 从落地到规模化扩展的思考
5.1 单机到多机的扩展路径
单机部署跑通后，下一步就是多机扩展。多机扩展的核心挑战是网络通信和任务调度。网络方面，DCU之间的跨机通信需要高速网络支持，我们用的是主流高速网络方案。任务调度方面，需要引入调度框架来管理多机资源，我们用的是主流调度方案。
扩展过程中要注意的是：不要一次性扩太多，先扩到两机验证通信和调度，稳定后再继续扩。我们第一次扩展时直接上了四机，结果通信配置有问题，排查起来非常麻烦。后来改成先两机验证，再逐步增加，效率高很多。
5.2 成本与性能的平衡策略
国产加速卡的成本优势是明显的，但性能与进口卡相比还有差距。我们的策略是：用数量换性能，用调度换效率。具体来说，单卡性能不够就多卡并行，多卡并行效率不高就优化调度策略。通过合理的调度，我们把整体资源利用率提升到了较高水平。
另一个策略是混合部署。不是所有推理任务都需要DCU，一些轻量级任务可以跑在CPU上，把DCU留给大模型推理。这个策略能显著降低整体成本。我们做了一个任务分类器，根据模型大小和延迟要求自动分配计算资源。
5.3 后续优化方向与扩展思路
后续优化方向主要有三个：一是算子优化，针对DCU架构特点优化关键算子，提升单卡性能；二是量化推理，用低精度量化减少显存占用和计算量；三是服务网格化，把推理服务拆成微服务，提升弹性和可维护性。
算子优化是最有技术含量的方向，需要对DCU架构有深入理解。我们目前在做的是把一些计算密集的算子用DTK提供的底层接口重写，性能提升比较明显。量化推理是性价比最高的方向，把FP16量化到INT8，显存占用减半，性能提升明显，但精度损失需要评估。服务网格化是架构层面的优化，适合大规模部署场景。
这个项目从最初的环境搭建到现在的稳定运行，前后经历了几个月的时间。中间踩过的坑、熬过的夜、排查过的问题，都变成了这篇笔记里的经验。国产加速卡的生态还在完善中，很多问题没有现成答案，需要自己摸索。但正是这些摸索的过程，让最终跑通的那一刻特别有成就感。希望这篇笔记能帮到正在或准备做类似项目的同行，少走一些弯路。
