1. 项目缘起与整体架构思路1.1 为什么选择海光DCU做推理落地第一次接触海光DCU是在一个国产化替代的推理项目中当时团队面临一个很现实的问题手里有一批已经调优好的大模型权重但目标部署环境只有国产加速卡可用。摆在面前的选择无非两条路——要么把模型重新适配到别的推理框架上要么找到一条能在国产卡上跑通且性能可接受的路径。我们最终选了后者核心原因有三个一是模型权重迁移成本最低二是海光DCU的软件栈对主流推理框架的兼容度比预期好三是长期运维角度看国产化环境下的自主可控性更符合项目要求。海光DCU本质上是一块通用计算加速卡它的软件栈提供了类似CUDA的编程接口官方称之为DTKDCU 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_DCUON \ -DDTK_PATH/opt/dtk \ -DDCU_ARCHxxx \ -DCMAKE_BUILD_TYPERelease 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_formatinference_format, precisionfp16, shard_num4 ) converter.convert()转换完成后用推理框架的加载工具加载模型确认能正常读取。加载时要注意显存分配策略有些框架支持动态显存分配有些需要预分配。预分配的好处是运行时不会因为显存不足而崩溃坏处是启动慢且占用固定显存。3.2 推理参数配置与批处理策略推理参数配置直接决定性能和效果。核心参数包括批处理大小、最大序列长度、采样参数等。批处理大小需要根据显存容量和延迟要求来权衡批越大吞吐越高但延迟也越大且显存占用成倍增加。我们的做法是先做一轮压力测试找到显存占用的拐点。具体操作是固定序列长度逐步增大批处理大小观察显存占用和推理延迟的变化。当显存占用接近上限或延迟超过业务要求时就取前一个批大小作为生产配置。批处理大小显存占用单次推理延迟吞吐量1较低最低最低4中等中等中等8较高较高较高16接近上限高最高提示生产环境建议留20%左右的显存余量避免突发流量导致显存溢出。我见过因为没留余量高峰期推理服务直接崩溃的案例。3.3 多卡并行与通信优化多卡并行是提升吞吐的关键手段。海光DCU支持多种并行策略包括数据并行、张量并行和流水线并行。我们主要用的是张量并行因为大模型的单层参数量就很大数据并行解决不了单卡显存放不下的问题。通信优化是多卡并行的核心。DCU之间的通信通过专用的通信库实现配置不当会成为性能瓶颈。关键配置包括通信域的大小、通信算法的选择、通信缓冲区的设置等。我们的经验是小规模并行用默认配置就行大规模并行需要手动调优通信算法。# 通信库环境变量配置示例 export NCCL_DEBUGINFO export NCCL_IB_DISABLE1 export NCCL_SOCKET_IFNAMEeth0通信库的调试信息很有用遇到通信超时或失败时打开调试日志能看到具体的通信过程和错误原因。但生产环境不建议一直开着因为日志量很大会影响性能。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显存占用减半性能提升明显但精度损失需要评估。服务网格化是架构层面的优化适合大规模部署场景。这个项目从最初的环境搭建到现在的稳定运行前后经历了几个月的时间。中间踩过的坑、熬过的夜、排查过的问题都变成了这篇笔记里的经验。国产加速卡的生态还在完善中很多问题没有现成答案需要自己摸索。但正是这些摸索的过程让最终跑通的那一刻特别有成就感。希望这篇笔记能帮到正在或准备做类似项目的同行少走一些弯路。
