华为ModelLink解释

华为ModelLink解释

变量解释

变量名含义
working_dir加速库及模型库下载后放置的目录
cur_dir运行指令或执行脚本时的路径当前目录
version版本

环境准备

依赖版本

  • 模型仓代码配套可运行的硬件型号
  • Atlas 800I A2(32GB显存)
  • Atlas 300I DUO(96GB显存)
  • 模型仓代码运行相关配套软件
  • 系统OS
  • 驱动(HDK)
  • CANN
  • Python
  • PTA
  • 版本配套关系
  • 待正式商发后补充版本链接

1.1 安装HDK

详细信息可参见,先安装firmwire,再安装driver

1.1.1 安装firmwire

安装方法:

包名
Ascend-hdk-*-npu-firmware_${version}.run

根据芯片型号选择相应的安装包安装 # 安装firmwire chmod +x Ascend-hdk-*-npu-firmware_${version}.run ./Ascend-hdk-*-npu-firmware_${version}.run --full

1.1.2 安装driver

安装方法:

cpu包名
aarch64Ascend-hdk-*-npu-driver_${version}_linux-aarch64.run
x86Ascend-hdk-*-npu-driver_${version}_linux-x86-64.run

# 根据CPU架构 以及npu型号 安装对应的 driver chmod +x Ascend-hdk-*-npu-driver_${version}_*.run ./Ascend-hdk-*-npu-driver_${version}_*.run --full

1.2 安装CANN

详细信息可参见,先安装toolkit 再安装kernel

1.2.1 安装toolkit

安装方法:${version}代表具体版本

cpu包名
aarch64Ascend-cann-toolkit_${version}_linux-aarch64.run
x86Ascend-cann-toolkit_${version}_linux-x86_64.run

# 安装toolkit  以arm为例 chmod +x Ascend-cann-toolkit_${version}_linux-aarch64.run ./Ascend-cann-toolkit_${version}_linux-aarch64.run --install source /usr/local/Ascend/ascend-toolkit/set_env.sh

1.2.2 安装kernel

安装方法:

包名
Ascend-cann-kernels-*_${version}_linux.run

根据芯片型号选择相应的安装包安装 # 安装 kernel chmod +x Ascend-cann-kernels-*_${version}_linux.run ./Ascend-cann-kernels-*_${version}_linux.run --install

1.3 安装PytorchAdapter

先安装torch 再安装torch_npu

1.3.1 安装torch

安装方法:

包名
torch-2.0.1+cpu-cp38-cp38-linux_x86_64.whl
torch-2.0.1+cpu-cp39-cp39-linux_x86_64.whl
torch-2.0.1-cp38-cp38-linux_aarch64.whl
torch-2.0.1-cp39-cp39-linux_aarch64.whl
...

根据所使用的环境中的python版本以及cpu类型,选择对应版本的torch安装包。 # 安装torch 2.0.1 的python 3.9 的arm版本为例 pip install torch-2.0.1-cp39-cp39-linux_aarch64.whl

1.3.2 安装torch_npu

,安装方法:

包名
pytorch_v2.0.1_py38.tar.gz
pytorch_v2.0.1_py39.tar.gz
...
  • 安装选择与torch版本 以及 python版本 一致的npu_torch版本 # 安装 torch_npu 以torch 2.0.1 的python 3.9的版本为例 tar -zxvf pytorch_v2.0.1_py39.tar.gz pip install torch*_aarch64.whl

1.4 安装加速库

下载加速库

  • 加速库下载链接待补充
包名
Ascend-mindie-atb_1.0.RC1_linux-aarch64_abi0.run
Ascend-mindie-atb_1.0.RC1_linux-aarch64_abi1.run
Ascend-mindie-atb_1.0.RC1_linux-x86_64_abi0.run
Ascend-mindie-atb_1.0.RC1_linux-x86_64_abi1.run
...
  • 将文件放置在${working_dir}路径下

安装 chmod +x Ascend-mindie-atb_*_linux-*_abi*.run ./Ascend-mindie-atb_*_linux-*_abi*.run --install --install-path=${working_dir} source ${working_dir}/atb/set_env.sh

可以使用uname -a指令查看服务器是x86还是aarch架构

可以使用以下指令查看abi是0还是1 python -c "import torch; print(torch.compiled_with_cxx11_abi())"

  • 若输出结果为True表示abi1,False表示abi0

1.5 安装模型仓

场景一:使用编译好的包进行安装

下载编译好的包

  • 下载链接待补充
包名
Ascend-mindie-atb-models_1.0.RC1_linux-aarch64_torch1.11.0-abi0.tar.gz
Ascend-mindie-atb-models_1.0.RC1_linux-aarch64_torch2.0.1-abi1.tar.gz
Ascend-mindie-atb-models_1.0.RC1_linux-x86_64_torch1.11.0-abi1.tar.gz
Ascend-mindie-atb-models_1.0.RC1_linux-x86_64_torch2.0.1-abi1.tar.gz
...

将文件放置在${working_dir}路径下

解压 cd ${working_dir} mkdir ModelLink cd ModelLink tar -zxvf ../Ascend-mindie-atb-models_*_linux-*_torch*-abi*.tar.gz

场景二:手动编译模型仓

  • 获取模型仓代码 git clone https://gitee.com/ascend/ModelLink.git
  • 切换到目标分支 cd ModelLink git checkout master
  • 代码编译 cd mindie_ref/mindie_llm/atb_models bash scripts/build.sh cd output/atb/ source set_env.sh

安装 sdk cd pytorch/examples/atb_speed_sdk pip3 install .

环境变量参考

CANN、加速库、模型仓的环境变量 source /usr/local/Ascend/ascend-toolkit/set_env.sh source ${working_dir}/atb/set_env.sh # 若使用编译好的包(即1.5章节的场景一),则执行以下指令 source ${working_dir}/ModelLink/set_env.sh # 若使用gitee上的源码进行编译(即1.5章节的场景二),则执行以下指令 source ${working_dir}/ModelLink/mindie_ref/mindie_llm/atb_models/scripts/set_env.sh

日志打印(可选)

加速库日志

  • 打开加速库日志 export ATB_LOG_TO_FILE=1 export ATB_LOG_TO_STDOUT=1 export ATB_LOG_LEVEL=INFO export TASK_QUEUE_ENABLE=1 export ATB_STREAM_SYNC_EVERY_KERNEL_ENABLE=1
  • 关闭加速库日志 export ATB_LOG_TO_FILE=0 export ATB_LOG_TO_STDOUT=0 export TASK_QUEUE_ENABLE=0 export ATB_STREAM_SYNC_EVERY_KERNEL_ENABLE=0
  • 日志存放在${cur_dir}/atb_temp/log下

算子库日志

  • 打开算子库日志 export ASDOPS_LOG_TO_FILE=1 export ASDOPS_LOG_TO_STDOUT=1 export ASDOPS_LOG_LEVEL=INFO
  • 关闭算子库日志 export ASDOPS_LOG_TO_FILE=0 export ASDOPS_LOG_TO_STDOUT=0
  • 日志存放在~/atb/log下

注意:开启日志后会影响推理性能,建议默认关闭;当推理执行报错时,开启日志定位原因

性能Profiling

  • 待补充

Dump Tensor

  • 适用于定位精度问题
  • 使用方式见

特性支持矩阵

  • 待补充

预置模型列表

  • 多模态模型Readme链接待补充

问题定位

  • 若遇到推理执行报错,优先打开日志环境变量,并查看算子库和加速库的日志中是否有error级别的告警,基于error信息进一步定位
  • 若遇到精度问题,可以dump tensor后进行定位

Key Feature

  • 待补充

Release Note

  • 待正式商发后补充

Read more

科普文:软件架构数据库系列之【MySQL:innodb刷脏页之Checkpoint机制详解】

科普文:软件架构数据库系列之【MySQL:innodb刷脏页之Checkpoint机制详解】

概叙 CheckPoint是MySQL的WAL和Redolog的一个优化技术。 ‌MySQL的CHECKPOINT机制‌是一种优化技术,主要用于将缓存池中的脏页刷新到磁盘,确保数据的持久性和一致性。 CHECKPOINT机制通过记录一个特定的时间点(称为检查点),在该时间点上,所有在此之前的修改都会被刷新到磁盘上,从而在系统崩溃时能够快速恢复数据。 CHECKPOINT的作用 1. ‌缩短数据库的恢复时间‌:当数据库宕机时,由于CHECKPOINT之前的页已经被刷新到磁盘,因此只需要对CHECKPOINT之后的重做日志进行恢复,从而缩短恢复时间‌。 2. ‌缓冲池不够用时刷新脏页‌(buffer pool大小有限):当缓冲池空间不足时,系统会强制执行CHECKPOINT,将脏页刷新到磁盘,以释放空间‌。 3. ‌重做日志不可用时刷新脏页‌(redolog file组中日志文件大小有限制):当重做日志不可用时(例如重做日志循环使用),系统会强制执行CHECKPOINT,确保脏页至少刷新到当前重做日志的位置‌。 CHECKPOINT的触发时机 1. ‌定期执行‌:

By Ne0inhk
科普文:软件架构Linux系列之【搞懂计算机架构NUMA(Non-Uniform Memory Access)非一致性内存访问】

科普文:软件架构Linux系列之【搞懂计算机架构NUMA(Non-Uniform Memory Access)非一致性内存访问】

概叙 前面了解了cpu、内存、磁盘、磁盘阵列,我们再接着看看NUMA。 NUMA到底指的是什么?我们怎么可以感受到它的存在?以及NUMA的存在对于我们编程会有什么影响?今天我们一起来看一下。 计算机应用和计算机模式 NUMA 非一致内存访问结构 ( Non Uniform Memory Access ) 系统架构 , 可以 集成多个处理器 , 使得系统在 " 处理事务 " 方面 , 有着 很高的性能 ; NUMA 架构中 , 处理器 访问 自己的本地内存速度很快 , 但是 访问 其它处理器的内存速度慢 , 这样为了 保证事物的执行性能 , 需要 减少 CPU 处理器之间的数据交互 , NUMA 架构 只适合OLTP ( On-Line Transaction Processing 联机事务处理过程 ) 事务处理场景 ; 使用

By Ne0inhk
科普文:软件架构数据库系列之【MySQL:innodb对numa的支持】

科普文:软件架构数据库系列之【MySQL:innodb对numa的支持】

概叙 关于numa和其他cpu架构,可以看看上面的文章。 在数据库系统中,OLTP(在线事务处理)数据库通常面临着高并发和高吞吐量的要求。 在某些情况下,可以通过启用 NUMA(非统一内存访问)来改善 OLTP 数据库的性能。 NUMA 系统的内存分配策略与传统的对称多处理 (SMP) 系统不同。在 SMP 系统中,所有 CPU 核心都可以访问同一个共享的内存。而在 NUMA 系统中,内存访问被限制在特定的节点(或节点集合),这取决于 CPU 核心的物理位置。 为了在 OLTP 数据库中使用 NUMA 技术来提升性能,可以考虑以下策略: 1. 内存分配:确保数据库进程被调度到具有足够内存的 NUMA 节点上。 1. 文件系统和磁盘:使用本地磁盘和文件系统来减少跨节点的通信。 1. 数据库配置:调整数据库的内存配置,使其尽可能利用本地内存。

By Ne0inhk
科普文:微服务之容器化【8种JDK性能测试:K8s上应该用哪种JDK?】

科普文:微服务之容器化【8种JDK性能测试:K8s上应该用哪种JDK?】

概叙 这次我将通过多次重复进行非常准确的比较以获得可重现的结果。 我将测试以下 JVM 实现: * Adoptium Eclipse Temurin * Alibaba Dragonwell * Amazon Corretto * Azul Zulu * BellSoft Liberica * IBM Semeru OpenJ9 * Oracle JDK * Microsoft OpenJDK 对于所有测试,我将使用 Paketo Java buildpack。我们可以使用 Paketo 轻松地在多个 JVM 实现之间切换。我将测试一个简单的 Spring Boot 3 应用程序,它使用 Spring Data 与 Mongo 数据库进行交互。 如果您已经使用 Dockerfile 构建了镜像,那么您可能使用的是来自 Docker Hub

By Ne0inhk