在昇腾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(生成式AI)试用 45 -- DocsGPT 与 Python开发 1

一切从python调用本地DocsGPT完成python开发开始。 遗留问题:如何验证AI开发提交的结果? * 提问 1: 使用python+Tkinter进行GUI程序编码 1. 界面分为左右两部分     - 左侧为python代码编辑区:       左上部为代码多行输入框,嵌入python idle,浅灰色底色;       左下部为 Run 按钮     - 右侧为GPT调用区:       右上部为tab,名称 Question,嵌入多行文本,输入提问问题;       中部为Show Answer按钮,海蓝色;       下部为2个tab:tab1,名称 Answer,嵌入多行文本,显示GPT处理结果;                                tab2,名称History,显示提问历史,answer + question,数据来自名为pyai的sqlite的数据库  2. 优化界面  3. 优化代码 * DeepSeek 回复 1: - 1 次调用界面

本地部署 Kimi K2 全指南(llama.cpp、vLLM、Docker 三法)

本地部署 Kimi K2 全指南(llama.cpp、vLLM、Docker 三法)

Kimi K2 是 Moonshot AI 于2025年7月11日发布的高性能多专家语言模型(MoE),支持最大 128K 上下文,激活参数规模为 32B,具备极强的推理、代码生成与多轮对话能力。自从其权重以多种格式开源以来,许多开发者希望将其部署在本地,以获得更高的私密性和灵活性。 本文将详细介绍三种主流本地部署路径,并提供完整的配置步骤和使用建议。 📦 准备工作(通用部分) 在进行部署前,请准备如下环境与资源: ✅ 最低硬件配置建议: 项目要求存储空间≥ 250 GB(用于量化模型,若使用 FP8 请预留 1 TB)内存≥ 128 GB RAM(越大越流畅)GPU≥ 24 GB 显存,推荐多卡(如 2×A100、H100)操作系统Linux(Ubuntu 推荐)

Copilot vs Claude Code终极对决哪个会更好用呢?

Copilot vs Claude Code终极对决哪个会更好用呢?

📊 核心差异:一句话概括 * GitHub Copilot:你的智能代码补全器 * Claude Code:你的全栈AI开发伙伴 🎯 一、产品定位对比 GitHub Copilot:专注代码补全 <TEXT> 定位:AI结对编程助手 核心理念:让你写代码更快 核心功能:基于上下文的代码建议和补全 收费模式:个人$10/月,企业$19/用户/月 Claude Code:全栈开发加速器 <TEXT> 定位:AI驱动的开发平台 核心理念:提升整个开发流程效率 核心功能:代码生成+架构设计+调试+部署 收费模式:按token计费,灵活弹性 ⚡ 二、核心技术对比

dify平台集成OCR:低代码+AI模型打造智能表单识别系统

dify平台集成OCR:低代码+AI模型打造智能表单识别系统 📖 项目背景与技术选型动因 在企业数字化转型过程中,大量纸质表单、发票、合同等非结构化文档需要转化为可处理的结构化数据。传统人工录入方式效率低、成本高、易出错,而通用OCR服务往往对中文支持不完善,尤其在复杂背景或手写体场景下识别准确率骤降。 为此,我们基于 dify 低代码平台,集成了一套轻量级但高精度的 OCR 文字识别系统。该系统采用经典的 CRNN(Convolutional Recurrent Neural Network)模型架构,专为中英文混合文本识别优化,在无GPU依赖的前提下实现 <1秒 的平均响应时间,真正做到了“开箱即用”的工业级OCR能力。 本方案的核心价值在于: - 低代码集成:通过dify平台快速接入AI能力,无需深度开发即可构建智能表单应用 - 高识别精度:相比传统轻量模型,CRNN在中文长文本、模糊图像、倾斜排版等复杂场景下表现更优 - 双模输出支持:同时提供可视化Web界面和标准REST API,