海光DCU大模型推理生产落地：从环境搭建到稳定运维的完整实战笔记

海光DCU大模型推理生产落地从环境搭建到稳定运维的完整实战笔记国产算力落地到生产环境从来不是“把模型跑起来”这么简单。很多团队都遇到过类似的问题实验室里单卡跑demo一切正常一到线上高并发场景就性能跳水、显存泄漏、服务偶发崩溃排查起来又缺乏成熟的方法论只能靠反复试错踩坑。事实上海光DCU的推理落地是一套系统性工程环境基线决定了性能的下限部署选型决定了资源利用率的天花板调优策略决定了最终的吞吐表现运维体系则保障了长期运行的稳定性。四个环节环环相扣任何一处短板都会拉低整体效果。本文结合多个信创项目的落地经验把从环境搭建到生产运维的全流程实操方法整理出来每一步附带可复用的脚本与参数建议帮助团队少走弯路快速实现从“跑通”到“用好”的跨越。一、环境打底三类隐性配置决定性能下限很多人容易忽略环境层的重要性觉得“能识别设备、能启动模型”就算环境合格。实际上至少有三成的性能损耗都来自环境配置的隐性问题——版本不匹配、路径优先级错误、NUMA跨节点调度这些问题不会让程序报错却会悄悄吃掉20%~40%的硬件性能。1. DTK版本选型不是越新越好DTK作为DCU的核心工具链版本选择的第一原则是“匹配优先稳定优先”而不是盲目追新。内核驱动、DTK、PyTorch三者必须版本对齐任何一环错位都会出现“能启动但性能异常”的诡异问题。生产环境优先选择经过厂商验证的稳定版比如深算二号K100优先搭配DTK 26.04深算一号Z100优先搭配DTK 25.04.4这两个版本的算子适配、工具链完整度都经过了大规模场景验证版本一致性校验要做双端既要查用户态DTK版本也要查内核驱动版本两者大版本必须对应。# 查用户态DTK版本hipcc--version|grepHIP version# 查内核驱动版本lsmod|grephydcu modinfo hydcu|grepversion新手最容易踩的坑是系统里预装了多个版本DTK环境变量配置混乱编译时用一个版本运行时加载另一个版本的动态库最终出现算子不兼容、性能骤降的问题。更稳妥的做法是在作业脚本开头显式加载指定版本避免依赖系统默认环境。2. PyTorch安装版本对应是第一原则PyTorch的安装是高频踩坑点直接pip install torch默认下载CUDA版本在DCU环境里永远识别不到设备。正确的安装逻辑是先确认DTK对应的ROCm版本再安装对应ROCm版本的PyTorch。版本对应关系可以简单记为DTK 25.x对应ROCm 5.xDTK 26.x对应ROCm 6.x。以DTK 26.04为例标准安装命令如下pipinstalltorch2.4.0torchvision0.19.0\--index-url https://download.pytorch.org/whl/rocm6.0安装完成后不能只看torch.cuda.is_available()返回True就完事还要做两层校验一是确认ROCm运行时版本正确二是确认设备架构与硬件匹配。importtorchprint(fPyTorch版本:{torch.__version__})print(fHIP运行时版本:{torch.version.hip})print(f设备可用:{torch.cuda.is_available()})print(f设备架构:{torch.cuda.get_device_properties(0).gcnArchName})如果架构名显示异常、或者HIP版本和DTK不对应后续运行大概率会出现数值错误或者性能异常越早排查越省时间。3. NUMA亲和性零成本的性能提升主流双路服务器的DCU通常分属两个NUMA节点组内卡间通过xGMI高速互联跨组通信则要经过CPU总线带宽只有组内的三分之一左右。如果进程不做绑核操作系统会随机调度CPU核心频繁跨NUMA传输数据多卡并行效率可能连60%都到不了。优化方法非常简单启动任务前先查清楚显卡对应的NUMA节点用numactl把进程绑定到对应NUMA节点的CPU和内存上完全零代码改动通常能带来20%~40%的性能提升。# 第一步查看DCU拓扑与NUMA归属rocm-smi--showtopo# 第二步绑定对应NUMA节点启动示例前4卡绑定NUMA 0numactl--cpunodebind0--membind0\python your_inference_script.py单卡推理场景下绑核的收益可能不明显但在4卡、8卡多卡张量并行的场景下这个优化的效果会非常显著是所有优化里投入产出比最高的一项。二、部署选型模型、精度与框架的匹配逻辑环境配置合格之后下一步是选择合适的部署方案。同样的硬件和模型不同的精度、框架、参数配置最终的吞吐和延迟可能差出数倍。选型没有绝对的最优解核心是在业务的精度要求、延迟要求、并发需求之间找平衡点。1. 卡型与模型规格的匹配参考不同量级的模型对显存和算力的需求差异很大选对配置才能兼顾成本和性能。以下是生产环境的常用匹配参考基于BF16精度、vLLM框架7B及以下模型单张K10096GB显存即可轻松承载剩余显存可以支撑大量KV缓存支持高并发请求即使是Z10064GB显存也能单卡部署适合边缘场景、低并发业务。**32B70B模型**需要48张K100做张量并行推荐8卡整机部署xGMI全互联能保证多卡通信效率如果是Z100机型通常需要8卡以上才能承载70B级模型且并发能力有限。多模态模型视觉塔会额外占用一部分显存和算力同参数模型建议按提升一个量级配置硬件比如7B级多模态模型建议预留至少24GB显存余量。2. 精度选择在性能、显存、精度之间做取舍四种常见精度各有适用场景不是精度越低越好也不是越高越稳妥FP32精度最高但显存占用大、速度慢除了训练梯度计算场景推理基本不会使用FP16/BF16推理场景的主流选择显存占用是FP32的一半精度损失可忽略DCU硬件原生支持兼容性最好业务对精度有要求时优先选这个FP8显存占用再减半吞吐提升明显但有两个注意点一是DCU的FP8编码格式和NVIDIA不通用不能直接复用CUDA环境的量化权重二是部分复杂算子支持度一般适合以自回归解码为主的纯推理场景。INT8显存占用最低但精度损失相对明显适合对响应速度要求高、精度容忍度高的场景比如检索、分类类任务。3. vLLM生产级参数详解vLLM是目前DCU上推理性能最优的框架之一但很多人直接照搬CUDA的启动参数导致稳定性和性能都不达预期。DCU环境有几个专属参数需要重点调整下面是生产环境的标准启动模板附带每个参数的设计逻辑#!/bin/bashsource/opt/dtk-26.04/env.shexportTRITON_HIP_LLD_PATH/opt/dtk-26.04/llvm/bin/ld.lld numactl--cpunodebind0--membind0\vllm serve /data/models/Qwen2-7B-Instruct\--served-model-name Qwen2-7B-Instruct\--tensor-parallel-size1\--dtypebfloat16\--max-model-len8192\--gpu-memory-utilization0.9\--kv-cache-dtype fp8\--enforce-eager\--max-num-seqs256\--host0.0.0.0\--port8000几个关键参数的选型逻辑--gpu-memory-utilization 0.9预留10%显存给运行时开销、临时张量避免高并发下触发OOM不要设成0.95以上DCU运行时的显存开销比CUDA略高打满显存很容易崩溃。--enforce-eager关闭CUDA Graph这是DCU环境的必加参数。CUDA Graph在部分算子上兼容度不佳会导致偶发崩溃和长尾延迟飙升开启eager模式后虽然单序列速度略有下降但P99延迟和稳定性会大幅提升。--kv-cache-dtype fp8开启FP8 KV缓存显存占用直接减半能支撑的并发数几乎翻倍是性价比最高的优化项之一且对最终生成质量影响极小。--max-num-seqs 256最大并发序列数这个值不是越大越好。太小会导致算力喂不饱太大则会让每个请求的延迟升高需要根据业务的吞吐和延迟要求平衡。三、性能调优三层优化路径按需落地性能优化不用上来就写自定义算子可以按照从易到难的顺序分层落地先做零代码的通用优化再做框架级参数调优最后针对热点算子做深度定制。大部分场景下做完前两层就能达到80分的性能足够满足生产需求。第一层通用基础优化零代码改动这一层不需要改业务代码只需要调整启动配置和环境参数就能覆盖大部分性能问题适合所有场景优先落地。除了前面提到的NUMA绑核、开启eager模式、FP8 KV缓存之外还有两个实用技巧固定显存分配阈值避免运行时频繁申请释放显存减少调度开销。可以通过环境变量设置PyTorch缓存分配器的行为减少显存碎片。避开显存残留卡DCU的显存回收机制和CUDA不同进程异常退出后显存不会立刻释放新任务尽量选择空闲卡启动通过HIP_VISIBLE_DEVICES指定设备编号避免和残留进程抢显存。第二层算子级融合优化轻量代码改动如果基础优化后性能仍有瓶颈可以针对高频算子做融合优化核心思路是减少中间张量的读写把多次显存访问合并成一次。最典型的就是RMSNorm、BiasGELU这类逐元素算子原生PyTorch实现会产生多次显存读写融合成单个核函数后性能能提升1.5倍左右。下面是一个简化的融合BiasGELU核函数示例__global__voidfused_bias_gelu_kernel(constfloat*input,constfloat*bias,float*output,introws,inthidden){introwblockIdx.y;intcolblockIdx.x*blockDim.xthreadIdx.x;if(rowrows||colhidden)return;intidxrow*hiddencol;floatvalinput[idx]bias[col];constexprfloatkSqrt2OverPi0.79788456f;constexprfloatkCoeff0.044715f;floatcubicval*val*val;output[idx]0.5f*val*(1.0ftanhf(kSqrt2OverPi*(valkCoeff*cubic)));}这类融合算子的开发成本不高但收益非常明显尤其适合Transformer里的高频小算子。如果团队有HIP开发能力优先优化Top5热点算子整体性能就能上一个台阶。第三层吞吐与延迟的平衡调优当服务进入稳定运行阶段就需要根据业务特征做精细化调优。核心是在吞吐和延迟之间找平衡点高吞吐优先场景比如离线批量推理、非实时问答适当调大max-num-seqs增加批处理大小让硬件尽量跑满追求单位时间处理的请求总数最大化低延迟优先场景比如实时对话、在线客服适当减小最大并发数避免请求排队同时可以调小max-model-len缩短单次推理的计算量长文本场景重点优化KV缓存的分页效率开启前缀缓存复用减少长上下文的重复计算。四、生产运维稳定性与可观测性建设生产环境和实验室demo最大的区别就是需要保证7×24小时稳定运行。很多团队只关注上线时的性能却忽略了运维体系建设结果线上频繁出问题排查又没有抓手。其实只要做好三层保障就能大幅降低故障率。1. 日常健康巡检把问题扼杀在萌芽期每天做一次基础巡检提前发现潜在风险比故障发生后再排查效率高得多。下面是一个通用巡检脚本覆盖硬件状态、服务状态、资源占用三大类核心指标#!/bin/bashecho DCU 推理服务日常巡检$(date%Y-%m-%d %H:%M)echo-e\n1. 硬件状态检查rocm-smi--showuse--showmemuse--showtemp--csv2/dev/null|tail-n2|\awk-F,{printf 卡%s: 使用率%s%%, 显存%s/%s, 温度%s℃\n, $1, $3, $5, $6, $8}echo-e\n2. 推理服务状态if[-fvllm.pid]kill-0$(catvllm.pid)2/dev/null;thenecho 服务运行中PID:$(catvllm.pid)curl-shttp://localhost:8000/v1/models/dev/null21echo 接口响应正常||echo 接口无响应elseecho 服务未运行fiecho-e\n3. 显存与进程检查count0fordevin/dev/dri/renderD*;dopids$(fuser$dev2/dev/null)if[-n$pids];thencount$((count$(echo $pids|wc-w)))fidoneecho 共$count个进程占用DCU设备echo-e\n✅ 巡检完成通过巡检可以提前发现显存异常占用、温度过高、服务无响应等问题及时处理避免扩大成线上故障。2. 常见故障的排查流程三类最常见的线上故障按优先级排查基本都能快速定位服务OOM崩溃优先检查是否并发过高、KV缓存设置过大再排查是否有显存泄漏最后确认是否有其他进程抢占显存性能突然下降先查是否有其他任务抢占资源再查NUMA绑定是否失效、是否切换了运行设备最后核对模型权重、精度是否被改动偶发返回异常优先排查算子兼容性问题尤其是自定义算子、量化算子再检查是否有静默数值错误必要时关闭对应优化项回退到稳定路径。3. 简单的服务自愈机制生产环境不可能时刻有人值守给服务加一层简单的守护和自愈能力能大幅降低运维压力。最基础的方式是写一个定时检测脚本发现服务异常时自动重启#!/bin/bash# 简单的服务健康检查与自愈脚本LOG_FILE./service_guard.logif!curl-shttp://localhost:8000/v1/models/dev/null21;thenecho$(date%Y-%m-%d %H:%M:%S)服务无响应执行重启$LOG_FILEbashvllm_service.sh stopsleep5bashvllm_service.sh startecho$(date%Y-%m-%d %H:%M:%S)服务重启完成$LOG_FILEfi配合crontab定时执行就能实现基础的故障自愈应对偶发的服务崩溃完全够用。写在最后海光DCU的推理落地本质上是一个工程化问题。硬件参数决定了理论上限但最终能发挥出多少性能全看环境、部署、调优、运维每一个环节的打磨程度。不用一开始就追求极致性能也不用上来就做深度算子开发。先把环境基线对齐把部署配置选对把基础优化落地再根据业务瓶颈逐步深入大部分场景下都能获得非常不错的效果。国产算力的生态还在快速成熟工程经验越沉淀后续的落地成本就越低长期收益也会越明显。