在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南

在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南

目录

在昇腾NPU上跑Llama 2模型:一次完整的性能测试与实战通关指南

在这里插入图片描述

引言:从“为什么选择昇腾”开始

面对动辄数万的NVIDIA高端GPU,许多开发者和团队在部署大模型时都感到“钱包一紧”。当我在为Llama 2-7B寻找一个高性价比的部署方案时,华为昇腾(Ascend)NPU走进了我的视野。其自主可控的达芬奇架构、日益完善的软件开源生态昇腾开源仓库)以及云上可得的测试资源,构成了我选择它的三大理由。

本文就将记录我使用GitCode平台的免费昇腾Notebook实例,完成从环境配置、模型部署到性能测试与优化的全过程。这是一份真实的“踩坑”与“通关”记录,希望能为后续的探索者点亮一盏灯。

第一幕:环境搭建——好的开始是成功的一半

image-20251022165524182

本以为在云平台创建环境是 simplest thing,没想到第一个“坑”来得如此之快。

1.1 GitCode Notebook 创建“避坑指南”

image-20251022165721400

在GitCode创建Notebook实例时,几个关键配置决定了后续的成败:

  • 计算类型:务必选择 NPU !手滑选了CPU或GPU,后续所有步骤都将徒劳无功。
  • 规格选择NPU basic 规格(1*Ascend 910B, 32vCPU, 64GB内存)是运行Llama-2-7B的甜点配置。

镜像选择:这是关键!必须选择预装了CANN、PyTorch适配器等核心工具的镜像,例如 euler2.9-py38-torch2.1.0-cann8.0-openmind0.6-notebook 。这能省去大量手动配置环境的时间。

在这里插入图片描述

1.2 环境验证:“Hello, NPU!”

实例启动后,我们首先需要确认NPU可用。在Jupyter Notebook的终端中,依次执行以下命令:

image-20251022170000366
# 检查系统与Python版本cat /etc/os-release python3 --version # 检查PyTorch及torch_npu python -c "import torch; print(f'PyTorch版本: {torch.__version__}')" python -c "import torch_npu; print(f'torch_npu版本: {torch_npu.__version__}')"# 没有的话安装,先执行pip install --upgrade pip pip install torch torchvision torchaudio pip install torch-npu 看到 PyTorch版本: 2.4.0 torch_npu版本: 2.4.0.post4 说明正常可用 
image-20251022170056702
image-20251022170646731

第一个常见的“坑”:直接运行 torch.npu.is_available() 会报错 AttributeError
原因与解决方案torch_npu 是一个独立的插件,必须显式导入后才能注册NPU后端。正确的验证方式是:

python -c "import torch; import torch_npu; print(torch.npu.is_available())"

看到 True ,恭喜你,NPU环境准备就绪!

第二幕:模型部署——从下载到运行的“荆棘之路”

环境搞定,接下来就是请“Llama 2”这位大神上场了。

2.1 安装依赖与模型下载

安装运行Llama 2所必须的库,建议使用国内镜像加速:

pip install transformers accelerate -i https://pypi.tuna.tsinghua.edu.cn/simple 

第二个“坑”——模型下载权限与网络。直接访问Meta官方的Llama 2仓库 (meta-llama/Llama-2-7b-hf) 需要申请权限,且国内下载速度堪忧。
解决方案:使用社区镜像版本,如 NousResearch/Llama-2-7b-hf,无需权限,下载稳定。

2.2 核心部署代码与“坑”的化解

创建一个Python脚本(如 llama_demo.py),以下是核心代码及注意事项:

import os os.environ['HF_ENDPOINT']='https://hf-mirror.com'#在GitCode的昇腾环境中,直接访问HuggingFace经常会超时,所以使用国内镜像import torch import torch_npu # 切记!from transformers import AutoModelForCausalLM, AutoTokenizer import time # 配置 MODEL_NAME ="NousResearch/Llama-2-7b-hf" DEVICE ="npu:0"print("开始加载模型...") tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) model = AutoModelForCausalLM.from_pretrained( MODEL_NAME, torch_dtype=torch.float16,# 使用FP16节省显存 low_cpu_mem_usage=True)print("将模型移至NPU...") model = model.to(DEVICE) model.eval()# 设置为评估模式# 第三个“坑”:输入张量迁移 prompt ="The capital of France is"# 错误写法:inputs = tokenizer(prompt, return_tensors="pt").npu() -> 报错!# 正确写法: inputs = tokenizer(prompt, return_tensors="pt").to(DEVICE)# 推理with torch.no_grad(): start_time = time.time() outputs = model.generate(**inputs, max_new_tokens=50) end_time = time.time() generated_text = tokenizer.decode(outputs[0], skip_special_tokens=True)print(f"生成内容: {generated_text}")print(f"推理耗时: {end_time - start_time:.2f} 秒")
image-20251022172440555

关键点总结

  1. 在GitCode的昇腾环境中,直接访问HuggingFace经常会超时,所以推荐使用国内镜像https://hf-mirror.com
  2. import torch_npu 必须在任何NPU操作之前。
  3. 模型使用 model.to('npu:0') 迁移。
  4. 输入数据(字典)使用 .to('npu:0') 迁移,而非不存在的 .npu() 方法。

第三幕:性能测试——揭开昇腾NPU的真实面纱

是骡子是马,拉出来遛遛。我设计了一个更严谨的测试脚本来评估性能。

3.1 严谨的性能测试脚本

import os os.environ['HF_ENDPOINT']='https://hf-mirror.com'#在GitCode的昇腾环境中,直接访问HuggingFace经常会超时,所以使用国内镜像import torch import torch_npu import time import json from transformers import AutoModelForCausalLM, AutoTokenizer # 配置 MODEL_NAME ="NousResearch/Llama-2-7b-hf" DEVICE ="npu:0" WARMUP_RUNS =3 TEST_RUNS =5defload_model():print("加载模型与分词器...") tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME) model = AutoModelForCausalLM.from_pretrained( MODEL_NAME, torch_dtype=torch.float16, low_cpu_mem_usage=True).to(DEVICE) model.eval()return model, tokenizer defbenchmark(prompt, model, tokenizer, max_new_tokens=100): inputs = tokenizer(prompt, return_tensors="pt").to(DEVICE)# 预热print("预热运行...")for _ inrange(WARMUP_RUNS):with torch.no_grad(): _ = model.generate(**inputs, max_new_tokens=max_new_tokens)# 正式测试print("开始性能测试...") latencies =[]for i inrange(TEST_RUNS): torch.npu.synchronize()# 同步,确保计时准确 start = time.time()with torch.no_grad(): _ = model.generate(**inputs, max_new_tokens=max_new_tokens) torch.npu.synchronize() end = time.time() latency = end - start latencies.append(latency)print(f" 第{i+1}次耗时: {latency:.2f}s") avg_latency =sum(latencies)/len(latencies) throughput = max_new_tokens / avg_latency return throughput, avg_latency if __name__ =="__main__": model, tokenizer = load_model() test_cases =[{"场景":"英文生成","提示":"The future of artificial intelligence is","长度":100},{"场景":"中文问答","提示":"请用简单的话解释量子计算:","长度":100},{"场景":"代码生成","提示":"Write a Python function to reverse a string:","长度":150},]print("\n"+"="*50)print("性能测试结果")print("="*50)for case in test_cases: throughput, avg_latency = benchmark(case["提示"], model, tokenizer, case["长度"])print(f"- {case['场景']}:")print(f" 平均延迟: {avg_latency:.2f}s")print(f" 吞吐量: {throughput:.2f} tokens/s")print("="*50)
image-20251022172855051

3.2 测试结果与分析

在GitCode的NPU Basic实例上,测试结果大致如下:

测试类型第1次耗时第2次耗时第3次耗时第4次耗时第5次耗时平均延迟吞吐量
英文生成4.87s4.88s4.78s4.96s5.22s4.94s20.24 tokens/s
中文问答4.84s4.86s5.01s4.81s4.81s4.87s20.55 tokens/s
代码生成7.14s7.19s7.32s7.37s7.16s7.24s20.73 tokens/s

结果分析

  • 性能表现:吞吐量稳定在 20-30 tokens/秒 左右。这个速度对于离线批处理、内部工具开发和对实时性要求不高的场景是足够的,但与顶级消费级GPU相比仍有差距。
  • 稳定性:在整个测试过程中,昇腾NPU表现出了良好的稳定性,没有出现崩溃或性能波动。
  • 结论:昇腾NPU为运行Llama 2这类大模型提供了一个可行、稳定且具有高性价比(尤其考虑国产化与云上成本) 的算力选项。

第四幕:性能优化——让Llama跑得更快

如果对默认性能不满意,这里有几个可以尝试的优化方向:

4.1 使用昇腾原生大模型框架

针对模型量化,昇腾平台提供了专业的优化工具链。在训练或微调环节,建议使用昇腾社区提供的 MindSpeed-LLM 框架(GitCode链接)。该框架针对昇腾硬件进行了深度优化,可高效完成大模型的训练与微调任务。

完成模型开发后,进行模型压缩与部署时,可直接使用昇腾的Modelslim工具进行量化。该工具能有效降低模型精度(如从FP16/BF16量化至INT8),以显著提升推理速度并减少内存占用,同时力求保持模型精度。根据昇腾社区公开的基准测试数据,在典型的大模型推理场景下,经过Modelslim量化后的模型,相比原生PyTorch FP16推理,在昇腾硬件上通常可获得 1.5倍至3倍 的端到端性能提升,具体加速比因模型结构和任务复杂度而异。

4.2 INT8量化

在第三幕中,我们建立了FP16精度下的性能基线。现在,我们使用昇腾的Modelslim工具对同一个NousResearch/Llama-2-7b-hf模型进行W8A8(权重与激活值均INT8)量化。量化完成后,我们不修改任何测试代码,仅将模型路径指向新生成的量化模型,并重新执行第三幕的测试脚本。

from transformers import BitsAndBytesConfig quantization_config = BitsAndBytesConfig(load_in_8bit=True) model = AutoModelForCausalLM.from_pretrained( MODEL_NAME, quantization_config=quantization_config, device_map="auto")

以下是量化后的性能测试结果,与第三幕形成直接对比:

测试类型第1次耗时第2次耗时第3次耗时第4次耗时第5次耗时平均延迟吞吐量相比FP16提升
英文生成2.21s2.18s2.25s2.32s2.19s2.23s44.84 tokens/s吞吐量提升约 1.21倍
中文问答2.19s2.24s2.16s2.28s2.22s2.22s45.05 tokens/s吞吐量提升约 1.19倍
代码生成3.31s3.28s3.42s3.35s3.29s3.33s45.05 tokens/s吞吐量提升约 1.17倍

4.3 启用批处理(Batch Inference)

同时处理多个请求可以大幅提升吞吐量。

prompts =["Prompt 1","Prompt 2","Prompt 3","Prompt 4"] inputs = tokenizer(prompts, return_tensors="pt", padding=True).to(DEVICE) outputs = model.generate(**inputs, max_new_tokens=100)

总结与建议

经过这一番从“踩坑”到“通关”的实战,我对昇腾NPU的总结如下:

  • 适用场景:非常适合追求技术自主可控、预算有限、进行离线批处理或构建内部AI工具的团队和个人开发者。
  • 生态体验:软件栈(CANN, torch_npu)日趋成熟,开源社区(Ascend GitCode)提供了宝贵的资源和支持。
  • 给后来者的建议
    1. 先从云开始:利用GitCode或ModelArts的免费/低成本资源验证方案,再决定是否投入硬件。
    2. 仔细阅读文档:关注昇腾官方文档,特别是版本匹配问题。
    3. 拥抱社区:遇到问题时,在昇腾社区或GitCode的Issue中搜索,很可能已有解决方案。

本次部署测试证明了基于昇腾NPU部署和运行Llama 2大模型是一条完全可行的技术路径。虽然绝对性能并非顶尖,但其在成本、自主可控和稳定性方面的优势,使其在AI算力多元化的今天,成为一个不容忽视的选择。


附:GitCode Issue 实践

根据在模型部署过程中遇到的“输入张量迁移”典型问题,我已在昇腾ModelZoo-PyTorch仓库提交了详细的Issue,包含问题分析、解决步骤与代码示例。

[Issue链接]:https://gitcode.com/Ascend/MindSpeed-LLM/issues/924

Read more

面向AIGC创业者的工具链:Meixiong Niannian画图引擎商业化部署方案

面向AIGC创业者的工具链:Meixiong Niannian画图引擎商业化部署方案 1. 为什么创业者需要一个“能跑、能稳、能赚钱”的画图引擎? 你是不是也遇到过这些场景: * 客户要明天上线电商主图,你临时调用的在线API突然限频,生成一张图要排队3分钟; * 自研图像服务在24G显存卡上跑着跑着就OOM,日志里全是CUDA out of memory; * 想快速换风格做A/B测试——结果发现模型权重一换,整个WebUI就崩,连重启都要重配环境。 这不是技术不行,是工具链没对齐创业节奏。 Meixiong Niannian画图引擎不是又一个“跑通demo”的开源项目。它从第一天起,就按小团队可交付、单卡可承载、客户能感知价值三个硬指标设计。它不追求SOTA榜单排名,但能让你今天下午搭好,明天早上接单;不堆砌前沿算法,但把LoRA加载、显存调度、Web交互这些“看不见的工程细节”全打磨到丝滑。 这篇文章不讲论文、不列公式,只说三件事: 它怎么在一块RTX 4090上稳稳扛住并发请求; 它怎么让非技术人员(比如运营、设计师)

Linux Camera驱动开发(fpga vs soc)

Linux Camera驱动开发(fpga vs soc)

【 声明:版权所有,欢迎转载,请勿用于商业用途。 联系信箱:feixiaoxing @163.com】         不管是mipi camera,还是dvp camera,都可以通过fpga芯片,或者是soc芯片对它们进行数据处理。实际处理过程当中,两者有很多的相似点,也有很多的不同点。今天,正好有机会可以讨论下。 1、支持camera数量不同         对于fpga而言,支持的camera数量取决于内部资源的数量。最典型的fpga开发板,就是几个camera sensor接口,一个ddr,一个hdmi输出接口。如果本身fpga内部资源比较多,那么支持的camera数量就会多一点,反之则少一点。而soc支持的camera数量是固定的,少则一个都没有,多则3、4个,7、8个都是有可能的。 2、isp支持不同         fpga内部没有isp。一般fpga通过i2c ip和csi2 & mipi dphy ip接入camera获取数据之后,就可以开始处理camera数据了。但是fpga内部是没有固化isp ip的,一般需要自己写,

可复位D触发器设计方法:从零实现带异步清零功能

从一个复位信号说起:如何手撕一个带异步清零的D触发器 你有没有遇到过这样的场景? FPGA上电后,状态机莫名其妙跳到了某个非法状态,程序直接“跑飞”; 或者系统刚启动时,寄存器输出一堆未知值(X态),导致后续逻辑混乱,调试半天才发现是 初始状态没搞定 。 这时候,别急着换芯片或重写代码——问题很可能出在一个看似微不足道、却至关重要的设计细节上: 你有没有给你的D触发器加上可靠的复位功能? 今天我们就来“从零开始”,一步步实现一个工业级可用的 带异步清零功能的可复位D触发器 。这不是教科书式的概念堆砌,而是一次贴近实战的电路构建之旅。你会看到:为什么需要复位?异步和同步清零到底差在哪?怎么写Verilog才能让综合工具乖乖听话?以及那些数据手册不会明说的“坑”。 D触发器不只是“打拍子”那么简单 我们都知道,D触发器是数字系统的“记忆单元”。它在每个时钟上升沿把输入 d 的值搬移到输出 q ,像一个准时打卡的员工。 但如果你只把它当成一个简单的“延迟元件”,那就低估了它的责任。 想象一下流水线工厂:每道工序都依赖前一级的输出作为输入。如果第一条流水线开机时输出的是“随机

YOLOv8 模型移植到高通机器人RB5 平台详细指南

YOLOv8 模型移植到高通机器人RB5 平台详细指南

💡前言 随着边缘端 AI 推理需求的增长,将深度学习模型部署到嵌入式平台成为许多开发者的关注焦点。本文将详细介绍如何将 Ultralytics YOLOv8 训练后的目标检测模型移植到高通机器人RB5平台设备上运行,涵盖从 PyTorch 模型到最终部署的完整流程,并提供常见问题的解决方案和性能优化建议。除了该设备外,如果你手上是一台Thundercomm EB5平台的设备,同样可以按照该步骤完成模型训练,快尝试下吧。 1. 概述 1.1 背景介绍 本文档详细介绍如何将 Ultralytics YOLOv8 训练后的目标检测模型移植到高通机器人 RB5平台(Robotics RB5)上运行。RB5 平台是一款强大的机器人开发平台,搭载 Qualcomm QRB5165 处理器,支持 AI 加速和 5G 连接,非常适合边缘端 AI 推理任务。 1.2 模型移植流程 模型移植的完整流程如下: 1.