1. 为什么要在海光DCU上做大模型推理第一次接触海光DCU做推理部署很多人会下意识拿它和通用GPU的流程做对比结果发现从驱动到框架再到算子库整条链路都不太一样。海光DCUDeep Computing Unit是面向通用计算场景的加速卡配套的是DTKDCU Toolkit软件栈整体思路和主流加速卡生态有相似之处但在版本匹配、环境变量、算子支持度上都有自己的脾气。这篇笔记就是把我从裸机到稳定跑起大模型推理服务这一路的实操过程完整记录下来包括环境怎么搭、模型怎么转、服务怎么起、线上怎么盯。先说清楚这篇内容适合谁看。如果你手里有一台装了海光DCU的服务器想在上面跑通一个7B到70B参数级别的大语言模型推理服务并且希望它能稳定对外提供接口那这篇基本能覆盖你80%的疑问。如果你只是想了解DCU是什么、能干什么那看前两节就够了。整篇内容偏向工程落地不讲太多理论推导重点放在怎么做和为什么这么做上。需要提前说明的是DCU的软件生态还在快速迭代不同DTK版本之间的行为差异可能比较大。我下面提到的所有版本号、路径、参数都是基于我实际使用的那一套环境你在自己机器上操作时一定要先确认版本不要直接照搬命令。这也是我在整个过程中踩坑最多的地方——版本不对后面全是白费功夫。另外要强调一点大模型推理在生产环境落地和实验室里跑个demo完全是两码事。实验室里你只要看到输出正常就完事了生产环境要考虑并发、显存碎片、长稳、监控、故障恢复。这篇笔记会花不少篇幅讲这些跑通之后的事因为这才是真正决定你能不能睡好觉的部分。2. 环境搭建从裸机到能跑通第一个算子2.1 驱动与DTK的版本匹配是第一步海光DCU要工作底层需要装驱动上层需要装DTK。这两个东西的版本必须严格对应不能随便混搭。我一开始就是吃了这个亏驱动装的是比较新的版本DTK用的是旧版本结果hy-smi能看到卡但一跑算子就报错错误信息还很模糊只说什么device error排查了大半天才定位到是版本不匹配。正确的做法是先去确认你手头DTK的版本号然后去找对应的驱动版本。DTK安装包里通常会带一个版本说明文件里面会写明推荐的驱动版本范围。我建议直接按DTK推荐的驱动版本来装不要自己发挥。安装驱动的过程本身不复杂基本就是解压、执行安装脚本、重启。但有几个细节要注意安装前先确认系统内核版本某些老内核可能需要额外装kernel header。安装脚本执行完一定要重启不重启的话设备节点可能不完整。重启后用hy-smi确认卡能被识别并且显存容量、温度、功耗这些信息都能正常读出。hy-smi这个工具相当于DCU的仪表盘后面排查问题会经常用到。它能看显存占用、利用率、温度、功耗还能看当前跑的进程。建议把它当成日常巡检的第一入口。DTK的安装相对直接一些解压后执行安装脚本然后把环境变量配好。环境变量这块是重点我单独拎出来说。2.2 环境变量配置里最容易漏掉的几项DTK装完之后需要把它的库路径、二进制路径加到环境变量里。很多人只加了PATH和LD_LIBRARY_PATH结果跑起来发现找不到某些运行时库。我实际配下来比较稳妥的一套是这样的export DTK_HOME/opt/dtk export PATH$DTK_HOME/bin:$PATH export LD_LIBRARY_PATH$DTK_HOME/lib:$LD_LIBRARY_PATH export DTK_INCLUDE_PATH$DTK_HOME/include除了这几个基础的还有两个容易被忽略的一个是跟算子库相关的路径。DCU上跑深度学习底层会用到一些加速算子库这些库的路径如果不加进去框架加载的时候会静默回退到CPU实现性能直接掉一个数量级而且不会报错你只会觉得怎么这么慢。另一个是跟通信库相关的。如果你要做多卡推理通信库的路径必须配好否则多卡之间同步会出问题。这个在单卡测试的时候完全看不出来一上多卡就暴露。提示环境变量配完之后建议开一个新终端用env | grep DTK确认一下是否都生效了。另外如果你用conda或者venv管理Python环境注意这些环境变量要在激活虚拟环境之后再确认一遍避免被覆盖。2.3 框架选型PyTorch还是别的在海光DCU上跑大模型推理框架层面主流还是PyTorch。DTK会提供适配好的PyTorch版本你直接用官方提供的安装包就行不要自己去pip装官方PyTorch那个是跑不起来的。安装适配版PyTorch的时候注意它通常是一个whl包直接pip install本地安装。装完之后进Python执行import torch然后torch.cuda.is_available()DCU在框架层通常做了兼容映射所以这里可能仍然叫cuda如果返回True说明框架层面已经能识别到设备了。但这里有个坑is_available()返回True不代表算子都能跑。我遇到过框架能识别设备、能创建tensor但一执行矩阵乘法就报错的情况。所以装完框架之后一定要跑一个简单的矩阵运算测试确认基础算子没问题。import torch a torch.randn(1024, 1024).to(cuda) b torch.randn(1024, 1024).to(cuda) c torch.matmul(a, b) print(c.sum())这个测试跑通了说明基础环境没问题。如果这一步就报错那后面大模型肯定跑不起来先回头检查驱动和DTK版本。2.4 推理引擎的选择与安装大模型推理直接用PyTorch原生跑不是不行但性能和显存效率都比较一般。生产环境一般会用专门的推理引擎。在海光DCU上比较常见的选择是vLLM的适配版本或者一些国产推理框架的DCU适配版。我实际用的是vLLM的DCU适配版。安装方式和普通vLLM类似但要注意它依赖的底层库版本和DTK是对应的不能随便升级依赖。安装完之后可以用它自带的小模型测试脚本先跑一遍确认推理引擎本身没问题。这里有个经验推理引擎的版本和模型格式是强相关的。比如某些版本的vLLM只支持特定格式的模型权重你拿一个旧格式的模型去加载它会报一堆看不懂的错。所以选引擎版本的时候先确认你要跑的模型是什么格式然后去找支持这个格式的引擎版本。3. 模型准备与权重转换的那些坑3.1 模型格式确认别拿到权重就往上怼大模型权重有好几种常见格式比如HuggingFace格式、GGUF格式、还有一些框架私有的格式。在海光DCU上跑推理最稳妥的是用HuggingFace格式的权重因为适配版推理引擎基本都支持这个格式。拿到模型之后先看目录结构。一个标准的HuggingFace格式模型目录里应该有config.json、tokenizer.json、tokenizer_config.json以及一堆.safetensors或者.bin文件。如果缺了config.json那这个模型大概率不是标准格式需要先转换。我遇到过一次拿到的模型只有.bin文件没有配置文件。这种情况要么去找原始发布方要完整包要么自己根据模型结构手写一个config.json。手写配置文件风险比较大参数写错了模型加载出来是乱的输出全是胡言乱语。所以能找完整包就找完整包。3.2 权重精度选择FP16、BF16还是量化精度选择直接决定显存占用和推理速度。在海光DCU上我实测下来精度显存占用7B模型推理速度输出质量FP32约28GB慢最好FP16约14GB快好BF16约14GB快好INT8量化约7GB较快略有下降INT4量化约4GB快下降明显生产环境一般用FP16或者BF16。BF16的动态范围更大训练场景用得多推理场景FP16和BF16差别不大。如果显存紧张可以考虑INT8量化但要注意量化后的模型在某些任务上质量下降比较明显尤其是需要精确计算的场景。量化模型的加载需要推理引擎支持。有些引擎支持在线量化就是加载FP16模型后自动转成INT8这种方式比较方便但会多占一点显存。有些引擎需要你提前把模型量化好存成量化格式再加载。我建议如果要用量化提前量化好这样加载快、显存占用也明确。3.3 模型加载时的显存分配策略大模型加载到DCU上显存分配是个技术活。推理引擎一般会提供几个参数来控制显存使用gpu_memory_utilization控制引擎最多使用多少比例的显存。默认可能是0.9意思是留10%给系统和其他进程。这个值设太高容易OOM设太低又浪费显存。max_model_len最大序列长度。这个值直接影响KV Cache的显存占用。设得越大能处理的上下文越长但显存占用也越大。tensor_parallel_size张量并行度也就是用几张卡来跑一个模型。我实际调下来7B模型单卡FP16gpu_memory_utilization设0.85左右比较稳留一点余量给显存碎片。max_model_len根据实际业务需求设不要盲目设很大比如你业务上最长也就2K token那设4096就够了设32768纯属浪费显存。多卡场景下tensor_parallel_size要和实际卡数一致。比如你有4张卡想用4卡并行跑一个模型那就设4。这里要注意张量并行对通信要求比较高卡之间的互联带宽如果不够并行效率会很低甚至不如单卡。3.4 一个真实的加载失败排查过程有一次我加载一个13B模型反复失败报错信息是out of memory但我算了一下显存应该是够的。排查过程是这样的第一步用hy-smi看显存占用发现卡上确实没别的进程显存是空的。第二步怀疑是max_model_len设太大了把它从8192降到4096还是OOM。第三步怀疑是gpu_memory_utilization设太高从0.9降到0.8依然OOM。第四步换了个小模型7B测试能加载成功。说明环境本身没问题是13B模型的问题。第五步仔细看13B模型的配置文件发现它的hidden_size和num_hidden_layers比标准13B模型大实际上是一个13B的模型参数量接近15B。按15B算FP16需要约30GB显存而单卡显存只有32GB减去系统占用和KV Cache确实不够。最后解决方案是用两张卡做张量并行tensor_parallel_size2顺利加载。这个案例说明模型的实际参数量不一定和名字一致加载前一定要看配置文件里的真实参数。另外排查OOM问题要有顺序从最简单的可能性开始排除不要一上来就怀疑大问题。4. 推理服务部署与性能调优4.1 服务化部署的基本架构跑通单次推理之后下一步是把它做成服务。生产环境的推理服务一般长这样最前面是一个HTTP服务层接收请求、做鉴权、做限流中间是推理引擎负责实际的模型计算底层是DCU硬件。在海光DCU上推理引擎通常自带HTTP服务能力你可以直接用它的API server模式启动。启动命令大概是这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --port 8000启动之后它会暴露一个兼容OpenAI接口的HTTP端点你可以用标准的OpenAI客户端去调用。这种方式的好处是生态兼容好很多现成的工具和框架都能直接对接。但生产环境不能就这么裸跑。你需要考虑进程守护服务挂了要能自动拉起。可以用systemd或者supervisor。日志管理日志要落盘、要轮转不然磁盘很快满。健康检查要有一个健康检查接口方便负载均衡器判断服务是否正常。优雅退出收到停止信号时要等当前请求处理完再退出不能直接kill。4.2 并发能力测试与瓶颈定位服务起来之后第一件事是测并发。我用的是一个简单的压测脚本模拟多个客户端同时发请求观察吞吐量和延迟。测试结果发现单卡7B模型FP16并发数从1加到8的时候吞吐量线性增长加到16的时候增长变缓加到32的时候吞吐量不再增长延迟反而大幅上升。说明瓶颈在计算资源卡已经跑满了。这时候用hy-smi看DCU利用率确实接近100%。这种情况下想提升吞吐量只有两个办法一是加卡做张量并行二是用量化模型降低单次计算量。但要注意张量并行不是万能的。我实测下来2卡张量并行的吞吐量大概是单卡的1.6倍不是2倍因为有通信开销。4卡的话大概是单卡的2.5倍左右。所以如果单卡能满足需求尽量不要上多卡多卡带来的复杂度和故障点更多。4.3 KV Cache管理与显存碎片问题大模型推理和普通模型推理最大的区别就是KV Cache。每来一个请求引擎都要为它分配KV Cache显存。请求结束后这块显存要释放。如果频繁地分配和释放会产生显存碎片最终导致明明总显存够但就是分配不出来。推理引擎一般有几种策略来应对PagedAttention把KV Cache分成固定大小的块来管理类似操作系统的虚拟内存分页。这种方式能有效减少碎片。预分配启动时就把KV Cache的显存池分配好运行时从池子里取不动态申请。请求排队当显存不够时把新请求排队等有显存释放了再处理。我用的引擎默认开启了PagedAttention效果不错。但即便如此长时间运行后还是会有一定碎片。我的做法是设置一个显存使用阈值当碎片率达到一定程度时主动重启服务。这个阈值需要根据实际业务情况调我设的是连续运行72小时或者碎片率超过15%就重启。注意重启服务会导致正在处理的请求失败所以一定要配合优雅退出和负载均衡来做。一般是先把流量切走等请求处理完再重启重启完再切回来。4.4 长稳测试跑一天和跑一周是两回事实验室里跑个demo跑几分钟就完事了。生产环境要7x24小时运行长稳测试必不可少。我的长稳测试方案是这样的用一个脚本持续发请求模拟真实业务的请求分布比如80%短请求、20%长请求持续跑一周期间监控以下指标显存占用变化趋势推理延迟的P50、P95、P99服务进程的CPU和内存占用DCU的温度和功耗错误率跑下来发现几个问题第一显存占用会缓慢增长虽然很慢但一周下来涨了大概5%。这大概率是显存碎片导致的不是内存泄漏。解决方案就是前面说的定期重启。第二P99延迟在高峰期会明显高于P50说明有长尾请求。排查发现是某些超长请求接近max_model_len占用了大量计算时间阻塞了后面的请求。解决方案是对请求长度做限制超过一定长度的请求单独走一个队列或者直接拒绝。第三DCU温度在持续高负载下会升到比较高的水平风扇转速拉满。这个属于正常现象但要注意机房散热如果散热不好DCU会降频性能下降。5. 线上运维与故障处理5.1 监控体系搭建看什么指标生产环境的监控我分了几个层次硬件层用hy-smi采集DCU的利用率、显存、温度、功耗。这些指标能反映硬件是否健康。比如温度持续过高可能是散热问题功耗异常波动可能是电源问题。服务层采集服务的QPS、延迟分布、错误率、排队长度。这些指标反映服务是否正常。比如排队长度持续增长说明处理能力不足错误率上升说明有bug或者资源不够。业务层采集请求的内容分布、输出长度分布、用户反馈。这些指标反映业务是否健康。比如突然出现大量超长请求可能是有人在刷接口。监控数据要落盘并且设置告警阈值。我的告警策略是DCU温度超过85度告警显存占用超过90%告警P99延迟超过阈值告警错误率超过1%告警。告警要能推到手机上不然半夜出问题没人知道。5.2 常见故障与处理方案跑了大半年遇到过的故障大概有这么几类故障一服务进程还在但请求全部超时。排查用hy-smi看DCU利用率是0说明卡没在干活。进服务日志看发现是卡在某个算子上不动了。这种情况大概率是驱动或者DTK的bug导致某个算子hang住。处理重启服务。如果重启后还是这样那就要考虑升级或降级驱动/DTK版本。我遇到过一次是某个版本的DTK在特定算子上有死锁bug换了个版本就好了。故障二显存OOM但显存看起来没满。排查用hy-smi看显存占用确实没到100%但服务报OOM。这种情况一般是显存碎片导致的虽然总空闲显存够但没有连续的大块显存可用。处理重启服务。长期方案是调整gpu_memory_utilization留更多余量或者缩短重启周期。故障三推理结果异常输出乱码或者重复。排查先确认模型文件是否完整可以用md5校验。然后确认加载精度是否正确比如BF16的模型用FP16加载可能会出问题。最后确认推理参数比如temperature、top_p这些是否设得合理。处理如果是模型文件问题重新下载。如果是精度问题换正确的精度加载。如果是参数问题调参数。故障四多卡并行时某张卡利用率明显低于其他卡。排查用hy-smi看各卡利用率发现负载不均衡。这种情况一般是张量并行的切分策略问题或者卡之间的互联带宽不一致。处理检查卡之间的互联拓扑确认带宽是否对称。如果是切分策略问题可能需要调整并行配置。我遇到过一次是某张卡的PCIe链路降速了导致那张卡成为瓶颈换了个插槽就好了。5.3 版本升级的注意事项DCU的软件栈更新比较频繁版本升级是难免的。但升级有风险搞不好服务就跑不起来了。我的经验是升级前一定要在测试环境先验证。测试环境要和生产环境尽量一致包括硬件型号、系统版本、驱动版本、DTK版本。在测试环境跑一遍完整的回归测试确认没问题再上生产。升级要选在业务低峰期。升级过程中服务会中断所以要提前通知业务方并且准备好回滚方案。升级后要密切观察。升级后的头几个小时要盯着监控看确认各项指标正常。如果发现异常立即回滚。另外升级的时候要注意版本兼容性。比如DTK升级了驱动可能也要跟着升推理引擎升级了模型格式可能也要跟着变。这些都要提前确认好。5.4 性能调优的几个实用技巧最后分享几个我实际调优中用到的技巧技巧一调整batch size。推理引擎一般支持动态batch就是把多个请求合并成一个batch一起算。batch越大吞吐量越高但延迟也越高。生产环境要根据业务对延迟的容忍度来调。我的经验是如果业务能接受1秒以内的延迟batch可以设大一点如果要求200毫秒以内batch就要设小。技巧二用连续批处理continuous batching。传统的静态batch要等一个batch里所有请求都处理完才能处理下一批效率低。连续批处理是每处理完一个请求就立刻补一个新请求进来能显著提升吞吐量。我用的引擎默认开启了这个效果很明显。技巧三合理设置max_tokens。很多请求其实不需要生成很长的输出但如果不限制模型可能会一直生成到max_model_len。设置一个合理的max_tokens能减少无效计算提升吞吐量。技巧四预热。服务刚启动的时候第一次推理会比较慢因为要加载各种库、初始化算子。可以在服务启动后先发几个预热请求把常用的算子都跑一遍这样正式请求进来的时候就不会有冷启动延迟。技巧五监控显存碎片率。如果引擎支持可以暴露显存碎片率指标。当碎片率超过阈值时主动重启服务。这个比等到OOM了再重启要主动得多。6. 一些个人体会整套流程跑下来我最大的感受是海光DCU做推理生产落地技术本身不是最大的障碍最大的障碍是信息不透明。很多问题在官方文档里找不到答案只能靠自己一点点试。所以我把这些经验记下来希望能帮后面的人少走点弯路。另外生产落地和实验室demo真的是两回事。实验室里你只要关心能不能跑通生产环境你要关心能不能稳定跑一年。这中间的差距就是运维体系、监控体系、故障处理流程这些东西。这些东西看起来不酷但它们是真正让服务活下来的关键。最后说一个心态上的体会不要怕出问题出了问题才是学习的机会。我遇到过的每一个故障最后都变成了我经验的一部分。现在再遇到类似的问题我基本能很快定位到原因。这种能力不是看文档能看出来的是踩坑踩出来的。 
长河君 · 2026/10/23 1:18:48 · 阅读 1.2k 海光DCU大模型推理部署实战：从环境搭建到生产运维
1. 为什么要在海光DCU上做大模型推理第一次接触海光DCU做推理部署很多人会下意识拿它和通用GPU的流程做对比结果发现从驱动到框架再到算子库整条链路都不太一样。海光DCUDeep Computing Unit是面向通用计算场景的加速卡配套的是DTKDCU Toolkit软件栈整体思路和主流加速卡生态有相似之处但在版本匹配、环境变量、算子支持度上都有自己的脾气。这篇笔记就是把我从裸机到稳定跑起大模型推理服务这一路的实操过程完整记录下来包括环境怎么搭、模型怎么转、服务怎么起、线上怎么盯。先说清楚这篇内容适合谁看。如果你手里有一台装了海光DCU的服务器想在上面跑通一个7B到70B参数级别的大语言模型推理服务并且希望它能稳定对外提供接口那这篇基本能覆盖你80%的疑问。如果你只是想了解DCU是什么、能干什么那看前两节就够了。整篇内容偏向工程落地不讲太多理论推导重点放在怎么做和为什么这么做上。需要提前说明的是DCU的软件生态还在快速迭代不同DTK版本之间的行为差异可能比较大。我下面提到的所有版本号、路径、参数都是基于我实际使用的那一套环境你在自己机器上操作时一定要先确认版本不要直接照搬命令。这也是我在整个过程中踩坑最多的地方——版本不对后面全是白费功夫。另外要强调一点大模型推理在生产环境落地和实验室里跑个demo完全是两码事。实验室里你只要看到输出正常就完事了生产环境要考虑并发、显存碎片、长稳、监控、故障恢复。这篇笔记会花不少篇幅讲这些跑通之后的事因为这才是真正决定你能不能睡好觉的部分。2. 环境搭建从裸机到能跑通第一个算子2.1 驱动与DTK的版本匹配是第一步海光DCU要工作底层需要装驱动上层需要装DTK。这两个东西的版本必须严格对应不能随便混搭。我一开始就是吃了这个亏驱动装的是比较新的版本DTK用的是旧版本结果hy-smi能看到卡但一跑算子就报错错误信息还很模糊只说什么device error排查了大半天才定位到是版本不匹配。正确的做法是先去确认你手头DTK的版本号然后去找对应的驱动版本。DTK安装包里通常会带一个版本说明文件里面会写明推荐的驱动版本范围。我建议直接按DTK推荐的驱动版本来装不要自己发挥。安装驱动的过程本身不复杂基本就是解压、执行安装脚本、重启。但有几个细节要注意安装前先确认系统内核版本某些老内核可能需要额外装kernel header。安装脚本执行完一定要重启不重启的话设备节点可能不完整。重启后用hy-smi确认卡能被识别并且显存容量、温度、功耗这些信息都能正常读出。hy-smi这个工具相当于DCU的仪表盘后面排查问题会经常用到。它能看显存占用、利用率、温度、功耗还能看当前跑的进程。建议把它当成日常巡检的第一入口。DTK的安装相对直接一些解压后执行安装脚本然后把环境变量配好。环境变量这块是重点我单独拎出来说。2.2 环境变量配置里最容易漏掉的几项DTK装完之后需要把它的库路径、二进制路径加到环境变量里。很多人只加了PATH和LD_LIBRARY_PATH结果跑起来发现找不到某些运行时库。我实际配下来比较稳妥的一套是这样的export DTK_HOME/opt/dtk export PATH$DTK_HOME/bin:$PATH export LD_LIBRARY_PATH$DTK_HOME/lib:$LD_LIBRARY_PATH export DTK_INCLUDE_PATH$DTK_HOME/include除了这几个基础的还有两个容易被忽略的一个是跟算子库相关的路径。DCU上跑深度学习底层会用到一些加速算子库这些库的路径如果不加进去框架加载的时候会静默回退到CPU实现性能直接掉一个数量级而且不会报错你只会觉得怎么这么慢。另一个是跟通信库相关的。如果你要做多卡推理通信库的路径必须配好否则多卡之间同步会出问题。这个在单卡测试的时候完全看不出来一上多卡就暴露。提示环境变量配完之后建议开一个新终端用env | grep DTK确认一下是否都生效了。另外如果你用conda或者venv管理Python环境注意这些环境变量要在激活虚拟环境之后再确认一遍避免被覆盖。2.3 框架选型PyTorch还是别的在海光DCU上跑大模型推理框架层面主流还是PyTorch。DTK会提供适配好的PyTorch版本你直接用官方提供的安装包就行不要自己去pip装官方PyTorch那个是跑不起来的。安装适配版PyTorch的时候注意它通常是一个whl包直接pip install本地安装。装完之后进Python执行import torch然后torch.cuda.is_available()DCU在框架层通常做了兼容映射所以这里可能仍然叫cuda如果返回True说明框架层面已经能识别到设备了。但这里有个坑is_available()返回True不代表算子都能跑。我遇到过框架能识别设备、能创建tensor但一执行矩阵乘法就报错的情况。所以装完框架之后一定要跑一个简单的矩阵运算测试确认基础算子没问题。import torch a torch.randn(1024, 1024).to(cuda) b torch.randn(1024, 1024).to(cuda) c torch.matmul(a, b) print(c.sum())这个测试跑通了说明基础环境没问题。如果这一步就报错那后面大模型肯定跑不起来先回头检查驱动和DTK版本。2.4 推理引擎的选择与安装大模型推理直接用PyTorch原生跑不是不行但性能和显存效率都比较一般。生产环境一般会用专门的推理引擎。在海光DCU上比较常见的选择是vLLM的适配版本或者一些国产推理框架的DCU适配版。我实际用的是vLLM的DCU适配版。安装方式和普通vLLM类似但要注意它依赖的底层库版本和DTK是对应的不能随便升级依赖。安装完之后可以用它自带的小模型测试脚本先跑一遍确认推理引擎本身没问题。这里有个经验推理引擎的版本和模型格式是强相关的。比如某些版本的vLLM只支持特定格式的模型权重你拿一个旧格式的模型去加载它会报一堆看不懂的错。所以选引擎版本的时候先确认你要跑的模型是什么格式然后去找支持这个格式的引擎版本。3. 模型准备与权重转换的那些坑3.1 模型格式确认别拿到权重就往上怼大模型权重有好几种常见格式比如HuggingFace格式、GGUF格式、还有一些框架私有的格式。在海光DCU上跑推理最稳妥的是用HuggingFace格式的权重因为适配版推理引擎基本都支持这个格式。拿到模型之后先看目录结构。一个标准的HuggingFace格式模型目录里应该有config.json、tokenizer.json、tokenizer_config.json以及一堆.safetensors或者.bin文件。如果缺了config.json那这个模型大概率不是标准格式需要先转换。我遇到过一次拿到的模型只有.bin文件没有配置文件。这种情况要么去找原始发布方要完整包要么自己根据模型结构手写一个config.json。手写配置文件风险比较大参数写错了模型加载出来是乱的输出全是胡言乱语。所以能找完整包就找完整包。3.2 权重精度选择FP16、BF16还是量化精度选择直接决定显存占用和推理速度。在海光DCU上我实测下来精度显存占用7B模型推理速度输出质量FP32约28GB慢最好FP16约14GB快好BF16约14GB快好INT8量化约7GB较快略有下降INT4量化约4GB快下降明显生产环境一般用FP16或者BF16。BF16的动态范围更大训练场景用得多推理场景FP16和BF16差别不大。如果显存紧张可以考虑INT8量化但要注意量化后的模型在某些任务上质量下降比较明显尤其是需要精确计算的场景。量化模型的加载需要推理引擎支持。有些引擎支持在线量化就是加载FP16模型后自动转成INT8这种方式比较方便但会多占一点显存。有些引擎需要你提前把模型量化好存成量化格式再加载。我建议如果要用量化提前量化好这样加载快、显存占用也明确。3.3 模型加载时的显存分配策略大模型加载到DCU上显存分配是个技术活。推理引擎一般会提供几个参数来控制显存使用gpu_memory_utilization控制引擎最多使用多少比例的显存。默认可能是0.9意思是留10%给系统和其他进程。这个值设太高容易OOM设太低又浪费显存。max_model_len最大序列长度。这个值直接影响KV Cache的显存占用。设得越大能处理的上下文越长但显存占用也越大。tensor_parallel_size张量并行度也就是用几张卡来跑一个模型。我实际调下来7B模型单卡FP16gpu_memory_utilization设0.85左右比较稳留一点余量给显存碎片。max_model_len根据实际业务需求设不要盲目设很大比如你业务上最长也就2K token那设4096就够了设32768纯属浪费显存。多卡场景下tensor_parallel_size要和实际卡数一致。比如你有4张卡想用4卡并行跑一个模型那就设4。这里要注意张量并行对通信要求比较高卡之间的互联带宽如果不够并行效率会很低甚至不如单卡。3.4 一个真实的加载失败排查过程有一次我加载一个13B模型反复失败报错信息是out of memory但我算了一下显存应该是够的。排查过程是这样的第一步用hy-smi看显存占用发现卡上确实没别的进程显存是空的。第二步怀疑是max_model_len设太大了把它从8192降到4096还是OOM。第三步怀疑是gpu_memory_utilization设太高从0.9降到0.8依然OOM。第四步换了个小模型7B测试能加载成功。说明环境本身没问题是13B模型的问题。第五步仔细看13B模型的配置文件发现它的hidden_size和num_hidden_layers比标准13B模型大实际上是一个13B的模型参数量接近15B。按15B算FP16需要约30GB显存而单卡显存只有32GB减去系统占用和KV Cache确实不够。最后解决方案是用两张卡做张量并行tensor_parallel_size2顺利加载。这个案例说明模型的实际参数量不一定和名字一致加载前一定要看配置文件里的真实参数。另外排查OOM问题要有顺序从最简单的可能性开始排除不要一上来就怀疑大问题。4. 推理服务部署与性能调优4.1 服务化部署的基本架构跑通单次推理之后下一步是把它做成服务。生产环境的推理服务一般长这样最前面是一个HTTP服务层接收请求、做鉴权、做限流中间是推理引擎负责实际的模型计算底层是DCU硬件。在海光DCU上推理引擎通常自带HTTP服务能力你可以直接用它的API server模式启动。启动命令大概是这样python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.85 \ --max-model-len 4096 \ --port 8000启动之后它会暴露一个兼容OpenAI接口的HTTP端点你可以用标准的OpenAI客户端去调用。这种方式的好处是生态兼容好很多现成的工具和框架都能直接对接。但生产环境不能就这么裸跑。你需要考虑进程守护服务挂了要能自动拉起。可以用systemd或者supervisor。日志管理日志要落盘、要轮转不然磁盘很快满。健康检查要有一个健康检查接口方便负载均衡器判断服务是否正常。优雅退出收到停止信号时要等当前请求处理完再退出不能直接kill。4.2 并发能力测试与瓶颈定位服务起来之后第一件事是测并发。我用的是一个简单的压测脚本模拟多个客户端同时发请求观察吞吐量和延迟。测试结果发现单卡7B模型FP16并发数从1加到8的时候吞吐量线性增长加到16的时候增长变缓加到32的时候吞吐量不再增长延迟反而大幅上升。说明瓶颈在计算资源卡已经跑满了。这时候用hy-smi看DCU利用率确实接近100%。这种情况下想提升吞吐量只有两个办法一是加卡做张量并行二是用量化模型降低单次计算量。但要注意张量并行不是万能的。我实测下来2卡张量并行的吞吐量大概是单卡的1.6倍不是2倍因为有通信开销。4卡的话大概是单卡的2.5倍左右。所以如果单卡能满足需求尽量不要上多卡多卡带来的复杂度和故障点更多。4.3 KV Cache管理与显存碎片问题大模型推理和普通模型推理最大的区别就是KV Cache。每来一个请求引擎都要为它分配KV Cache显存。请求结束后这块显存要释放。如果频繁地分配和释放会产生显存碎片最终导致明明总显存够但就是分配不出来。推理引擎一般有几种策略来应对PagedAttention把KV Cache分成固定大小的块来管理类似操作系统的虚拟内存分页。这种方式能有效减少碎片。预分配启动时就把KV Cache的显存池分配好运行时从池子里取不动态申请。请求排队当显存不够时把新请求排队等有显存释放了再处理。我用的引擎默认开启了PagedAttention效果不错。但即便如此长时间运行后还是会有一定碎片。我的做法是设置一个显存使用阈值当碎片率达到一定程度时主动重启服务。这个阈值需要根据实际业务情况调我设的是连续运行72小时或者碎片率超过15%就重启。注意重启服务会导致正在处理的请求失败所以一定要配合优雅退出和负载均衡来做。一般是先把流量切走等请求处理完再重启重启完再切回来。4.4 长稳测试跑一天和跑一周是两回事实验室里跑个demo跑几分钟就完事了。生产环境要7x24小时运行长稳测试必不可少。我的长稳测试方案是这样的用一个脚本持续发请求模拟真实业务的请求分布比如80%短请求、20%长请求持续跑一周期间监控以下指标显存占用变化趋势推理延迟的P50、P95、P99服务进程的CPU和内存占用DCU的温度和功耗错误率跑下来发现几个问题第一显存占用会缓慢增长虽然很慢但一周下来涨了大概5%。这大概率是显存碎片导致的不是内存泄漏。解决方案就是前面说的定期重启。第二P99延迟在高峰期会明显高于P50说明有长尾请求。排查发现是某些超长请求接近max_model_len占用了大量计算时间阻塞了后面的请求。解决方案是对请求长度做限制超过一定长度的请求单独走一个队列或者直接拒绝。第三DCU温度在持续高负载下会升到比较高的水平风扇转速拉满。这个属于正常现象但要注意机房散热如果散热不好DCU会降频性能下降。5. 线上运维与故障处理5.1 监控体系搭建看什么指标生产环境的监控我分了几个层次硬件层用hy-smi采集DCU的利用率、显存、温度、功耗。这些指标能反映硬件是否健康。比如温度持续过高可能是散热问题功耗异常波动可能是电源问题。服务层采集服务的QPS、延迟分布、错误率、排队长度。这些指标反映服务是否正常。比如排队长度持续增长说明处理能力不足错误率上升说明有bug或者资源不够。业务层采集请求的内容分布、输出长度分布、用户反馈。这些指标反映业务是否健康。比如突然出现大量超长请求可能是有人在刷接口。监控数据要落盘并且设置告警阈值。我的告警策略是DCU温度超过85度告警显存占用超过90%告警P99延迟超过阈值告警错误率超过1%告警。告警要能推到手机上不然半夜出问题没人知道。5.2 常见故障与处理方案跑了大半年遇到过的故障大概有这么几类故障一服务进程还在但请求全部超时。排查用hy-smi看DCU利用率是0说明卡没在干活。进服务日志看发现是卡在某个算子上不动了。这种情况大概率是驱动或者DTK的bug导致某个算子hang住。处理重启服务。如果重启后还是这样那就要考虑升级或降级驱动/DTK版本。我遇到过一次是某个版本的DTK在特定算子上有死锁bug换了个版本就好了。故障二显存OOM但显存看起来没满。排查用hy-smi看显存占用确实没到100%但服务报OOM。这种情况一般是显存碎片导致的虽然总空闲显存够但没有连续的大块显存可用。处理重启服务。长期方案是调整gpu_memory_utilization留更多余量或者缩短重启周期。故障三推理结果异常输出乱码或者重复。排查先确认模型文件是否完整可以用md5校验。然后确认加载精度是否正确比如BF16的模型用FP16加载可能会出问题。最后确认推理参数比如temperature、top_p这些是否设得合理。处理如果是模型文件问题重新下载。如果是精度问题换正确的精度加载。如果是参数问题调参数。故障四多卡并行时某张卡利用率明显低于其他卡。排查用hy-smi看各卡利用率发现负载不均衡。这种情况一般是张量并行的切分策略问题或者卡之间的互联带宽不一致。处理检查卡之间的互联拓扑确认带宽是否对称。如果是切分策略问题可能需要调整并行配置。我遇到过一次是某张卡的PCIe链路降速了导致那张卡成为瓶颈换了个插槽就好了。5.3 版本升级的注意事项DCU的软件栈更新比较频繁版本升级是难免的。但升级有风险搞不好服务就跑不起来了。我的经验是升级前一定要在测试环境先验证。测试环境要和生产环境尽量一致包括硬件型号、系统版本、驱动版本、DTK版本。在测试环境跑一遍完整的回归测试确认没问题再上生产。升级要选在业务低峰期。升级过程中服务会中断所以要提前通知业务方并且准备好回滚方案。升级后要密切观察。升级后的头几个小时要盯着监控看确认各项指标正常。如果发现异常立即回滚。另外升级的时候要注意版本兼容性。比如DTK升级了驱动可能也要跟着升推理引擎升级了模型格式可能也要跟着变。这些都要提前确认好。5.4 性能调优的几个实用技巧最后分享几个我实际调优中用到的技巧技巧一调整batch size。推理引擎一般支持动态batch就是把多个请求合并成一个batch一起算。batch越大吞吐量越高但延迟也越高。生产环境要根据业务对延迟的容忍度来调。我的经验是如果业务能接受1秒以内的延迟batch可以设大一点如果要求200毫秒以内batch就要设小。技巧二用连续批处理continuous batching。传统的静态batch要等一个batch里所有请求都处理完才能处理下一批效率低。连续批处理是每处理完一个请求就立刻补一个新请求进来能显著提升吞吐量。我用的引擎默认开启了这个效果很明显。技巧三合理设置max_tokens。很多请求其实不需要生成很长的输出但如果不限制模型可能会一直生成到max_model_len。设置一个合理的max_tokens能减少无效计算提升吞吐量。技巧四预热。服务刚启动的时候第一次推理会比较慢因为要加载各种库、初始化算子。可以在服务启动后先发几个预热请求把常用的算子都跑一遍这样正式请求进来的时候就不会有冷启动延迟。技巧五监控显存碎片率。如果引擎支持可以暴露显存碎片率指标。当碎片率超过阈值时主动重启服务。这个比等到OOM了再重启要主动得多。6. 一些个人体会整套流程跑下来我最大的感受是海光DCU做推理生产落地技术本身不是最大的障碍最大的障碍是信息不透明。很多问题在官方文档里找不到答案只能靠自己一点点试。所以我把这些经验记下来希望能帮后面的人少走点弯路。另外生产落地和实验室demo真的是两回事。实验室里你只要关心能不能跑通生产环境你要关心能不能稳定跑一年。这中间的差距就是运维体系、监控体系、故障处理流程这些东西。这些东西看起来不酷但它们是真正让服务活下来的关键。最后说一个心态上的体会不要怕出问题出了问题才是学习的机会。我遇到过的每一个故障最后都变成了我经验的一部分。现在再遇到类似的问题我基本能很快定位到原因。这种能力不是看文档能看出来的是踩坑踩出来的。