1. 为什么要在国产DCU上部署大模型从“能用”到“好用”的实战思考最近几年AI大模型火得一塌糊涂但很多朋友一提到部署脑子里蹦出来的可能还是英伟达的GPU。这很正常毕竟生态成熟教程也多。但作为一名在国产化AI基础设施领域摸爬滚打了挺多年的“老司机”我越来越觉得咱们自己的硬件平台比如海光的DCU已经到了一个非常值得投入实战的阶段。这不仅仅是“支持国产”的情怀更是实打实的技术和成本考量。想象一下这个场景你所在的公司或团队因为业务需求或者合规要求需要构建一个完全自主可控的AI推理服务。模型选定了通义千问的qwen2.5-instruct-7B因为它指令跟随能力强7B的规模在精度和速度上取得了很好的平衡非常适合企业级应用。硬件呢一批搭载了海光DCU加速卡的服务器已经就位。这时候你的任务就是让模型在这套“国产芯”上跑起来并且要跑得稳、跑得快。这个过程中你会遇到和通用GPU平台不太一样的问题比如驱动生态、软件栈适配、性能调优。但别担心这正是这篇文章要解决的问题。我会把我自己从零开始在海光DCU Z100卡上成功部署qwen2.5-instruct-7B推理服务的完整过程包括踩过的坑和验证有效的解决方案毫无保留地分享给你。目标就一个让你也能快速复现把大模型服务稳稳当当地跑在咱们自己的硬件上。2. 实战第一步摸清你的DCU“家底”与环境准备在开始敲命令之前花点时间搞清楚你的硬件和基础软件环境能避免后面一大堆莫名其妙的错误。这就像装修房子得先知道承重墙在哪水电怎么走。2.1 认识你的DCU加速卡海光DCU全称深度计算单元你可以把它理解为一款为AI和高性能计算量身定做的国产加速卡。我这次实战用的是DCU Z100卡它有几个关键特性你需要了解大显存32GB的HBM2显存。这对于部署7B参数的大模型至关重要因为模型权重加载、KV Cache推理时的键值缓存都很吃显存。32GB的容量为运行qwen2.5-instruct-7B提供了充裕的空间甚至允许较长的上下文长度。高带宽PCIE 4.0 x16的接口确保数据在主机CPU和DCU卡之间高速传输减少瓶颈。计算核心拥有8192个通用计算核心提供强大的并行计算能力专门优化了FP16/BF16等混合精度计算这正是大模型推理所需要的。我使用的服务器配置是双路海光C86 7380处理器32核配了1TB的内存。这个配置保证了在模型加载、数据预处理等CPU端任务上不会有短板不会拖累DCU的推理速度。2.2 操作系统与核心软件栈安装操作系统我们选择Ubuntu 22.04 LTS。长期支持版本社区资源丰富稳定性有保障这是生产环境的首选。接下来是三个最核心的软件它们构成了DCU运行的基石安装顺序不能乱DCU驱动Driver这是让系统识别和管理DCU硬件的“桥梁”。我使用的是rock-5.2.0-5.16.29-V01.13这个版本。安装后你可以通过ls /dev/dri/和ls /dev/kfd来检查设备文件是否存在这是后续所有工作的前提。DTKDeep Learning Toolkit这是海光提供的深度学习工具包你可以把它类比为英伟达的CUDA Toolkit。它包含了编译器HIPCC、数学库、以及一些优化过的深度学习算子。我安装的版本是DTK 23.10.1。安装完成后务必要设置好环境变量例如ROCM_PATH或HIP_PATH这样后续的框架才能找到正确的计算库。Docker引擎我们将使用容器化部署这能完美解决环境依赖复杂、版本冲突的问题。直接安装Docker CE的最新稳定版即可。这里有个小坑我踩过驱动和DTK的版本需要匹配。最好从海光官方文档或提供的资源列表中确认你下载的驱动版本和DTK版本是经过兼容性测试的。盲目使用最新版有时会带来意想不到的兼容性问题。3. 构建容器化环境为什么用Docker怎么用直接在物理机上安装Python环境、PyTorch、各种依赖库太容易“污染”系统环境了而且难以迁移和复现。Docker容器化是解决这个问题的银弹。3.1 选择与拉取合适的DCU基础镜像海光官方和其生态伙伴通常会提供预置好基础环境如DTK、Python、PyTorch的Docker镜像这能省去我们大量手动配置的时间。我这次选用的是一个集成了较新DTK24.04.1和vLLM推理引擎基础环境的镜像docker pull image.sourcefind.cn:5000/dcu/admin/base/custom:vllm0.5.0-dtk24.04.1-ubuntu20.04-py310-zk-v1注意镜像仓库地址和标签可能会更新你需要根据实际情况从可靠的渠道获取最新的镜像信息。这个镜像基于Ubuntu 20.04Python 3.10已经集成了vLLM 0.5.0框架对DCU的初步支持这是我们能顺利运行qwen2.5的关键。3.2 以特权模式运行容器并映射资源为了让容器内的应用能充分调用DCU硬件我们需要以一些特殊的参数来启动容器docker run -it --name qwen_inference \ --privileged \ --shm-size256G \ --device/dev/kfd \ --device/dev/dri/ \ --cap-addSYS_PTRACE \ --security-opt seccompunconfined \ --ulimit memlock-1:-1 \ --ipchost \ --network host \ --group-add video \ -v /opt/hyhal:/opt/hyhal \ -v /home/your_username/env/model:/home/env/model \ image.sourcefind.cn:5000/dcu/admin/base/custom:vllm0.5.0-dtk24.04.1-ubuntu20.04-py310-zk-v1 \ /bin/bash我来解释一下这些参数的重要性--privileged和--device赋予容器访问DCU设备/dev/kfd,/dev/dri/的权限。--shm-size256G大模型推理时进程间通信可能需要很大的共享内存设置大一些避免报错。-v /opt/hyhal:/opt/hyhal将宿主机上的DTK等工具目录映射到容器内保证容器内能使用正确的计算库。-v /home/your_username/env/model:/home/env/model这是模型目录映射。你需要提前在宿主机上下载好qwen2.5-instruct-7B的模型文件然后通过这个参数映射到容器内这样容器就能直接读取模型无需重复下载。启动后你就进入了一个全新的、干净的、但已经为DCU优化好的Linux环境。接下来我们就在这个容器里操作。4. 部署推理引擎为什么是Xinference vLLM模型部署需要一个服务化的框架。我这里选择Xinference。它是一个由社区推动的、开源的大模型推理和服务框架设计得足够轻量且灵活。它最大的好处是支持多种后端引擎比如vLLM、Transformers等我们可以根据硬件特性选择最优解。对于DCU平台在现阶段vLLM是一个非常有潜力的选择。vLLM以其高效的PagedAttention分页注意力技术闻名能极大优化显存使用提升吞吐量。虽然其原生对AMD ROCmDCU的软件栈与之兼容的支持还在持续完善中但我们已经可以通过一些集成了补丁的版本如我们镜像里的vLLM 0.5.0来在DCU上运行。4.1 在容器内安装Xinference进入容器后首先安装Xinference并指定安装vLLM后端支持pip install xinference[vllm] -i https://pypi.mirrors.ustc.edu.cn/simple这里我使用了国内的中科大镜像源来加速下载。安装完成后Xinference及其vLLM引擎的依赖就都准备好了。4.2 启动服务并加载qwen2.5-instruct-7B模型这是最激动人心的一步。我们使用一条命令来启动Xinference服务并加载模型XINFERENCE_MODEL_SRCmodelscope xinference-local --host 0.0.0.0 --port 9997 xinference launch \ --model-engine vLLM \ --model-name qwen2.5-instruct \ --size-in-billions 7 \ --model-format pytorch \ --gpu-idx 0,1,2,3我们来拆解这条命令XINFERENCE_MODEL_SRCmodelscope告诉Xinference从ModelScope平台获取模型信息如果你映射的本地模型目录结构符合规范它也能直接读取。--host 0.0.0.0 --port 9997将服务绑定到所有网络接口并监听9997端口这样同一网络内的其他机器也能访问。--model-engine vLLM指定使用vLLM作为推理引擎。--model-name qwen2.5-instruct --size-in-billions 7 --model-format pytorch指定加载通义千问7B指令微调版PyTorch格式的权重。--gpu-idx 0,1,2,3这是关键如果你有多张DCU卡这里可以指定使用的卡号。例如0,1表示使用前两张卡。vLLM会自动进行张量并行将模型分布到多卡上从而加速推理并支持更大的模型。对于7B模型单卡通常足够但多卡可以进一步提升吞吐量。命令执行后你会看到控制台开始输出日志。Xinference会首先从你映射的本地目录/home/env/model查找模型如果找不到会根据model-name尝试从网络下载。加载过程中会显示进度条当看到模型权重加载完毕、服务启动成功的日志时恭喜你部署成功了5. 验证、测试与性能调优实战服务跑起来了但到底稳不稳定速度快不快我们需要亲手测试一下。5.1 基础功能验证与模型对话最直接的测试就是发送一个推理请求。你可以用curl命令或者用Python写个简单的测试脚本。这里我用一个Python示例import requests import json # Xinference服务地址 url http://localhost:9997/v1/completions headers {Content-Type: application/json} # 构造一个简单的文本补全请求 data { prompt: 中国的首都是, max_tokens: 50, temperature: 0.1 } response requests.post(url, headersheaders, datajson.dumps(data)) result response.json() print(result[choices][0][text])如果返回了“北京”等相关内容说明模型加载和基础推理功能完全正常。你也可以测试更复杂的指令比如“写一首关于春天的五言绝句”看看qwen2.5-instruct的指令遵循能力。5.2 性能观测与关键指标部署不只是“能跑”更要“跑得好”。你需要关注几个核心指标吞吐量Throughput每秒能处理多少tokenTokens per second, t/s。这在高并发场景下尤为重要。你可以使用压力测试工具如locust模拟多个并发请求来测试。首Token延迟Time to First Token, TTFT从发送请求到收到第一个token输出所花的时间。这直接影响用户体验。显存占用使用rocm-smiDCU上的类似nvidia-smi的工具来监控DCU卡的显存使用情况。确保在最大上下文长度下显存不会溢出。在DCU平台上性能调优可能涉及调整--gpu-idx尝试不同的卡组合观察多卡并行效率。vLLM引擎参数例如--max-num-batched-tokens最大批处理token数、--block-size注意力块大小这些参数会影响显存利用率和计算效率需要根据实际负载进行微调。DTK环境变量有些环境变量可以控制线程数、内存分配策略等具体可以参考海光的优化手册。5.3 可能遇到的坑与解决方案在实际操作中我遇到了几个典型问题这里分享给你容器内找不到DCU设备这几乎都是因为docker run命令中的--device参数没写对或者宿主机驱动未正确安装。务必检查/dev/kfd和/dev/dri/renderD*文件在宿主机上的存在性。模型加载失败或报HIP异构计算接口错误这通常是DTK版本与PyTorch或vLLM版本不匹配导致的。解决方法是严格使用镜像提供的、经过验证的软件版本组合不要轻易升级或降级某个组件。推理速度慢首先确认是否成功使用了DCU进行计算查看rocm-smi的计算单元利用率是否上来。如果利用率低可能是计算图没有成功offload到DCU需要检查框架的DCU支持情况。其次检查是否因显存不足导致频繁的内存-显存交换。内存不足OOM除了增加--shm-size还需要关注vLLM的--max-model-len最大模型上下文长度参数设置过大会导致显存预估错误而OOM。根据你的实际需求合理设置。6. 总结与展望走完这一整套流程从裸机到成功运行起一个可以响应请求的qwen2.5-instruct-7B服务你会发现在国产DCU平台上部署大模型虽然路径与英伟达GPU有所不同但整体思路是相通的硬件驱动、计算工具链、容器化、推理框架、模型加载。这次实战的核心与其说是具体的命令不如说是理解每个环节的作用和可能的问题点。比如知道为什么需要映射/dev/kfd设备理解--shm-size设置多大的依据明白Xinference和vLLM各自扮演的角色。掌握了这些即使将来软件版本更新、模型换成了别的你也能快速找到适配的方法。从我自己的体验来看国产DCU的软件生态正在以肉眼可见的速度完善。社区贡献的镜像、逐步完善的框架支持都让部署门槛越来越低。把大模型推理服务迁移到国产硬件平台已经从一个“能否实现”的技术挑战转变为一个“如何优化得更好”的工程问题。这背后是我们整个AI基础软件栈自主可控能力提升的体现。下一步你可以尝试部署更大的模型如14B、72B探索多机多卡推理或者将这套服务集成到你的业务系统中结合LangChain等框架构建更复杂的AI应用。这条路已经跑通了剩下的就是不断深化和优化。希望这份详细的实战记录能成为你在国产AI算力平台上探索的一块坚实垫脚石。如果在操作中遇到新的问题不妨多看看相关开源社区的Issue和讨论很多时候答案就在那里。