企业官网建设流程全解析

前言

在现代人工智能和高性能计算领域，基础线性代数子程序（BLAS）库扮演着至关重要的角色。ops-blas 作为 CANN（Compute Architecture for Neural Networks）生态系统中的关键组件，专门为昇腾 NPU 提供了高度优化的 BLAS 线性代数计算能力。本文将深入剖析 ops-blas 的技术架构、算子实现原理、性能优化策略以及与业界主流 BLAS 库的效率对比。通过概念拆解的方式，我们将从底层硬件特性出发，逐步构建对这款国产 AI 芯片专用线性代数库的全面理解。

第一章：ops-blas 项目架构与核心设计理念

1.1 项目定位与生态位置

ops-blas 是华为昇腾计算架构 CANN 的重要组成部分，专门提供高性能的 BLAS（Basic Linear Algebra Subprograms）计算能力。与传统通用 BLAS 库（如 OpenBLAS、BLIS、Intel MKL）不同，ops-blas 从设计之初就深度绑定昇腾 NPU 的硬件特性，充分利用达芬奇架构的矢量计算单元（Vector Core）和矩阵计算单元（Cube Core）的并行计算能力。

仓库结构揭示了 ops-blas 的模块化设计理念，不同 BLAS 算子按照功能家族进行组织。项目根目录下的关键文件体现了其工程化成熟度：

• CMakeLists.txt：顶层构建配置文件，支持灵活的编译选项
• build.sh：一体化构建脚本，支持算子级编译、打包、测试
• install_deps.sh：自动化依赖安装脚本
• include/cann_ops_blas.h：核心 API 头文件，提供标准 BLAS 接口

项目的核心设计理念可以归纳为三点：

第一，硬件感知的算子实现。ops-blas 中的每个算子都针对昇腾 NPU 的达芬奇架构进行了深度优化。例如，矢量运算充分利用 Vector Core 的 SIMD 能力，矩阵运算则调用 Cube Core 的矩阵乘加指令。

第二，灵活的接口设计。项目同时提供传统 BLAS 接口（aclblas* 系列函数）和现代化的 aclBLASLt 轻量化接口，满足不同层次的用户需求。

第三，完整的开发工具链。从算子开发、编译、测试到性能采集，ops-blas 提供了端到端的工具支持，降低了开发者的入门门槛。

1.2 目录结构与代码组织

分析 blas 目录下的算子组织，可以清晰看到 BLAS 标准的功能分类在 ops-blas 中的映射：

Level 1 BLAS（向量-向量运算）：

• asum：向量元素绝对值之和
• axpy：向量缩放与加法（y = alpha*x + y）
• copy：向量复制（scopy、ccopy 等）
• dot：向量点积（sdot、cdot 等）
• nrm2：向量二阶范数
• rot/rotm：向量旋转变换
• swap：向量元素交换

Level 2 BLAS（矩阵-向量运算）：

• gbmv：带带宽的矩阵-向量乘法
• gemv：通用矩阵-向量乘法
• ger/gerc：外积更新（y = alphaxy^T + A）
• sbmv/spmv/symv：对称矩阵-向量乘法
• tbmv/tpmv/trmv：三角矩阵-向量乘法
• tbsv/tpsv/trsv：三角矩阵求解

Level 3 BLAS（矩阵-矩阵运算）：
虽然当前仓库主要展示 Level 1 和 Level 2 算子，但 aclBLASLt 接口已支持 GEMM（通用矩阵乘）等高级功能。

这种组织方式不仅符合 BLAS 标准的习惯，也便于开发者快速定位目标算子。每个算子目录下通常包含：

• blas/<算子名>/<具体实现>/arch<版本>/：不同架构版本的核函数实现
• test/：对应的测试用例
• docs/：相关文档

代码清单 1 展示了一个典型的算子目录结构（以 scopy 为例）：

blas/copy/scopy/ ├── arch22/# 适用于算腾 910 等 arch22 架构│ ├── scopy_kernel.cpp# 设备端核函数│ ├── scopy_host.cpp# 主机端调用逻辑│ └── scopy_tiling.h# 分块参数定义└── test/ └── scopy_test.cpp# 功能验证用例

第二章：Ascend C 编程模型与算子实现机制

2.1 达芬奇架构与 Ascend C 编程框架

要理解 ops-blas 的高性能来源，必须先了解其底层硬件架构和编程模型。昇腾 NPU 采用达芬奇（Da Vinci）架构，核心计算单元分为：

Vector Core（矢量核心）：负责标量、矢量和复杂数学运算。每个 Vector Core 包含多个矢量计算单元，支持 FP16、FP32、INT8 等多种数据类型，通过 SIMD（单指令多数据）方式实现数据并行。

Cube Core（矩阵核心）：专门为矩阵乘法运算优化，可在单个指令周期内完成一个小型矩阵块的乘积累加运算，是 AI 计算中卷积、全连接层的核心加速单元。

Scalar Core（标量核心）：负责逻辑控制、地址计算和简单标量运算。

Ascend C 是华为推出的面向达芬奇架构的 C++ 编程框架，它提供了一组内建函数和编程抽象，让开发者能够高效利用 NPU 的异构计算能力。ops-blas 中的所有算子都基于 Ascend C 实现。

2.2 算子实现的核心范式：以 scopy 为例

让我们深入分析blas/copy/scopy/scopy_kernel.cpp的实现，理解 ops-blas 算子的一般结构。

代码清单 2 展示了 CopyAIV 类的核心框架：

template<typenameT>classCopyAIV{public:__aicore__inlinevoidInit(GM_ADDR x,GM_ADDR y,GM_ADDR workSpace,GM_ADDR tilingGm);__aicore__inlinevoidProcess();__aicore__inlinevoidParseTilingData(GM_ADDR tilingGm);__aicore__inlinevoidSingleIteration(uint32_tcurOffset,uint32_tdataCount);private:TPipe pipe;// 流水线管理器GlobalTensor<T>inGM;// 输入全局内存张量GlobalTensor<T>outGM;// 输出全局内存张量TQue<QuePosition::VECIN,BUFFER_NUM>inQueue;// 输入队列（双缓冲）uint32_ttotalVecCoreNum=40;// 总矢量核心数（示例值）uint32_tmaxDataCount=0;// 单次处理最大数据量uint32_tstartOffset=0;// 当前核的起始偏移uint32_tcalNum=0;// 当前核的计算量// ... 其他状态变量};

为什么需要这样的设计？

1. 流水线（Pipeline）管理：TPipe pipe负责管理 DMA 数据传输和计算指令的流水线。在 NPU 上，数据传输（Global Memory ↔ Local Memory）和计算可以同时执行，通过流水线隐藏传输延迟。

2. 双缓冲（Double Buffering）：BUFFER_NUM = 2表示使用双缓冲队列。当一个数据块在计算单元上执行时，下一个数据块可以同时进行 DMA 传输，实现计算和传输的重叠。

3. 分块（Tiling）策略：ParseTilingData函数从 host 端接收分块参数。由于 NPU 的本地内存（Local Memory）有限（通常几十 KB），无法一次性加载全部数据，必须将大问题划分为适合本地内存的小块。

4. 核间并行：GetBlockNum()和GetBlockIdx()获取总核数和当前核编号，实现多核任务划分。

2.3 单步迭代的实现细节

SingleIteration函数是算子执行的核心循环体。代码清单 3 展示了其实现逻辑：

template<typenameT>__aicore__inlinevoidCopyAIV<T>::SingleIteration(uint32_tcurOffset,uint32_tdataCount){// 步骤1：从全局内存加载数据到本地队列LocalTensor<T>inLocal=inQueue.AllocTensor<T>();DataCopy(inLocal,inGM[curOffset],dataCount);inQueue.EnQue<T>(inLocal);// 步骤2：设置事件依赖，确保数据传输完成int32_teventIDMTE2ToMTE3=static_cast<int32_t>(GetTPipePtr()->FetchEventID(AscendC::HardEvent::MTE2_MTE3));AscendC::SetFlag<AscendC::HardEvent::MTE2_MTE3>(eventIDMTE2ToMTE3);AscendC::WaitFlag<AscendC::HardEvent::MTE2_MTE3>(eventIDMTE2ToMTE3);// 步骤3：从队列取出数据，执行计算（此处为复制，无计算）LocalTensor<T>outLocal=inQueue.DeQue<T>();// 步骤4：将结果写回全局内存DataCopy(outGM[curOffset],outLocal,dataCount);// 步骤5：释放本地内存，设置反向事件依赖inQueue.FreeTensor(outLocal);int32_teventIDMTE3ToMTE2=static_cast<int32_t>(GetTPipePtr()->FetchEventID(AscendC::HardEvent::MTE3_MTE2));AscendC::SetFlag<AscendC::HardEvent::MTE3_MTE2>(eventIDMTE3ToMTE2);AscendC::WaitFlag<AscendC::HardEvent::MTE2_MTE3>(eventIDMTE2ToMTE2);}

为什么需要事件（Event）机制？

达芬奇架构是异构并行架构，DMA 传输（MTE2 引擎）和矢量计算（MTE3 引擎）是独立的硬件单元，可以并行执行。但数据传输和计算之间存在依赖关系：必须确保数据已经到达本地内存，才能开始计算；必须确保计算完成，才能启动写回传输。

SetFlag/WaitFlag机制通过硬件信号量实现这种依赖同步，避免数据竞争和错误读写。

第三章：Host-Device 协同与 aclblas API 设计

3.1 主机端调用框架

ops-blas 的算子执行需要主机端（Host）和设备端（Device）协同工作。主机端负责：

1. 分配和初始化 workspace 内存
2. 计算分块参数（Tiling）
3. 启动设备端核函数
4. 管理 AscendCL 上下文和流

以aclblasScopy函数为例，其调用流程如下：

步骤1：参数校验。检查 handle、指针、维度等输入参数的合法性。

步骤2：Tiling 计算。根据问题规模（n）、硬件资源配置（核心数、本地内存大小）计算分块策略。

步骤3：Workspace 分配。如果算子需要临时缓冲区，从 handle 中获取预分配的 workspace。

步骤4：启动核函数。通过 AscendCL 的aclrtLaunchKernel接口启动设备端程序。

3.2 aclblasHandle 的设计哲学

aclblasHandle_t是 ops-blas 的核心抽象句柄，类似于 CUDA 中的 cuBLAS Handle 或 Intel MKL 的 BLAS Handle。其设计具有以下特点：

上下文封装：Handle 内部封装了 AscendCL 的上下文（aclrtContext）、流（aclrtStream）、workspace 指针等状态信息，用户无需直接操作底层 API。

资源管理：aclblasCreate和aclblasDestroy负责 Handle 生命周期管理，遵循 RAII（资源获取即初始化）原则。

流管理：通过aclblasSetStream/aclblasGetStream实现多流并发执行，支持异步计算。

workspace 复用：aclblasSetWorkspace允许用户预分配一块设备内存供所有算子复用，减少动态内存分配开销。

代码清单 4 展示了一个典型的调用序列：

// 创建 handleaclblasHandle_t handle=nullptr;aclblasCreate(&handle);// 设置 workspace（可选，用于需要临时内存的算子）void*workspace=nullptr;aclrtMalloc(&workspace,workspaceSize);aclblasSetWorkspace(handle,workspace,workspaceSize);// 设置计算流（可选，默认使用 NULL 流）aclrtStream stream=nullptr;aclrtCreateStream(&stream);aclblasSetStream(handle,stream);// 调用 BLAS 算子aclblasScopy(handle,x,y,n,incx,incy);// 同步等待完成aclrtSynchronizeStream(stream);// 清理资源aclblasDestroy(handle);aclrtFree(workspace);

为什么需要 workspace？

某些 BLAS 算子（如矩阵转置、矩阵乘法）在执行过程中需要临时存储空间来存放中间结果（例如分块计算时的数据重排）。如果每次调用都动态分配内存，会产生显著的性能开销。通过aclblasSetWorkspace，用户可以一次性分配足够大的内存块，供所有算子调用复用。

第四章：性能优化技术深度剖析

4.1 内存层级与数据传输优化

昇腾 NPU 的内存层级结构为：Host Memory（主存）↔ Global Memory（设备全局内存）↔ Local Memory（核上本地内存）。数据传输开销是性能的主要瓶颈之一。

ops-blas 采用以下技术降低传输开销：

合并访问（Coalesced Access）：确保连续的内存访问请求被合并为尽可能少的内存事务。在 scopy 算子中，DataCopy(inLocal, inGM[curOffset], dataCount)假设输入数据在内存中连续存放，从而触发合并访问。

异步传输与计算重叠：通过流水线技术，在核函数执行计算的同时，启动下一数据块的 DMA 传输。双缓冲队列（BUFFER_NUM=2）是实现这种重叠的基础。

数据预取（Prefetching）：在计算当前数据块时，提前启动下一个数据块的传输，进一步隐藏延迟。

4.2 分块策略与资源利用优化

Tiling（分块）是 NPU 编程的核心优化技术。由于每个 Vector Core 的本地内存有限（通常 192 KB 或 256 KB），无法一次性处理大规模数据。

ops-blas 的 Tiling 策略需要考虑以下因素：

本地内存容量：确定每个数据块的最大尺寸。例如，如果本地内存为 192 KB，float32 数据类型每个元素占 4 字节，则理论上最多可加载 48K 个元素。但实际需要为输入队列、输出队列、中间变量等分配空间，因此实际可用容量会打折扣。

核心数利用：将问题划分为多个块，分发到不同核心上并行执行。ParseTilingData函数中的useCoreNum和startOffset就是实现这种分发的关键参数。

负载均衡：确保各个核心的计算量尽可能均衡，避免某些核心提前完成而闲置。

代码清单 5 展示了一个简化的 Tiling 计算逻辑（伪代码）：

voidComputeTiling(uint32_tn,uint32_tcoreNum,uint32_tlocalMemSize,uint32_t&useCoreNum,uint32_t*startOffset,uint32_t*calNum){// 计算每个核心平均处理的元素数uint32_tavgLoad=(n+coreNum-1)/coreNum;// 根据本地内存限制，调整实际使用的核心数uint32_tmaxElementsPerCore=localMemSize/sizeof(float)/2;// 输入输出各占一半if(avgLoad>maxElementsPerCore){// 单个核心无法一次处理完，需要多次迭代useCoreNum=coreNum;for(uint32_ti=0;i<coreNum;i++){startOffset[i]=i*avgLoad;calNum[i]=(i==coreNum-1)?n-startOffset[i]:avgLoad;}}else{// 可以一次处理完，可能不需要所有核心useCoreNum=(n+maxElementsPerCore-1)/maxElementsPerCore;// ... 重新计算 startOffset 和 calNum}}

4.3 指令级优化与 SIMD 向量化

Vector Core 支持 SIMD 指令，可以在单个周期内对多个数据执行相同操作。ops-blas 通过以下方式利用 SIMD 能力：

数据对齐：确保数据地址对齐到 SIMD 寄存器的宽度（例如 256 位 = 32 字节），触发高效的向量加载/存储指令。

循环展开（Loop Unrolling）：通过展开循环减少分支开销，增加指令级并行度。

软件流水（Software Pipelining）：重新排列指令顺序，使数据传输和计算重叠执行。

为什么这些优化如此重要？

在传统 CPU 上，频率提升带来的性能增益已趋于瓶颈，现代处理器的性能提升主要依赖并行度。NPU 的设计哲学更是将并行推向极致：数千个核心同时执行矢量或矩阵运算。但硬件的并行能力需要软件进行有效挖掘，否则会沦为"沉睡的算力"。ops-blas 的优化本质上是让数据流动和指令执行尽可能连续，消除硬件资源闲置。

第五章：效率对比与性能基准测试

5.1 理论性能上限分析

评估 ops-blas 的性能，需要先理解昇腾 NPU 的理论峰值性能。以 Atlas 系列产品为例：

Atlas 910（训练卡）：

• Vector Core 数量：40 个（每核心 192 KB 本地内存）
• 每个 Vector Core 的 FP32 峰值性能：约 32 GFLOPS
• 整卡 Vector 峰值性能：40 × 32 = 1280 GFLOPS
• Cube Core 的 FP16 矩阵乘峰值性能：约 256 TFLOPS

Atlas 200（推理卡）：

• Vector Core 数量：4-8 个（取决于具体型号）
• 峰值性能相应降低

ops-blas 的 Level 1 和 Level 2 BLAS 算子主要利用 Vector Core，因此其性能上限受限于 Vector 峰值性能。

5.2 与业界主流 BLAS 库的效率对比

虽然无法在此进行实时基准测试，但基于公开资料和架构分析，可以进行定性对比：

对比 OpenBLAS（开源，CPU）：

OpenBLAS 是针对 CPU 优化的 BLAS 库，充分利用 AVX-512 等 SIMD 指令集。在 Intel Xeon 铂金 8380 处理器（40 核，AVX-512）上，sgemv（单精度矩阵-向量乘法）的性能约为 50-100 GFLOPS。

ops-blas 在 Atlas 910 上，通过 40 个 Vector Core 并行执行，理论性能可达 1280 GFLOPS，是高端 CPU 的 10 倍以上。但实际达到的性能取决于算子优化程度和计算密度。对于小规模问题（n < 1000），启动开销和同步成本会稀释并行优势；对于大规模问题（n > 10000），ops-blas 的并行度优势才会充分显现。

对比 NVIDIA cuBLAS（GPU）：

cuBLAS 是 NVIDIA GPU 的官方 BLAS 库，深度优化 CUDA 核心和 Tensor Core。在 A100 GPU（40 GB）上，sgemv 的性能可达 200-400 GFLOPS（取决于矩阵大小）。

Atlas 910 的 Vector Core 理论性能高于 A100 的 CUDA 核心，但 cuBLAS 经过多年迭代，其内存访问模式和指令调度已高度优化。ops-blas 作为相对较新的项目，在某些算子上可能仍存在性能差距，但差距正在快速缩小。

对比 Intel MKL（商业，CPU）：

MKL 是 Intel 的商业数学库，针对 Intel 架构进行深度优化。在矩阵-向量运算上，MKL 的性能通常略优于 OpenBLAS。但 MKL 的许可成本和平台绑定限制了其应用范围。

ops-blas 的开源特性和对国产硬件的原生支持，使其在信创场景中具有不可替代的优势。

5.3 性能采集与瓶颈分析

ops-blas 集成了msprof工具，支持采集算子级性能数据。通过分析这些数据和，开发者可以识别性能瓶颈并进行针对性优化。

典型的性能分析流程：

1. 采集性能数据：msprof --application="./scopy_test"
2. 分析时间分布：查看算子执行时间中，数据传输、计算、同步各占多少比例
3. 识别瓶颈：
   • 如果数据传输占比高，说明存在内存带宽瓶颈，需要优化数据布局和访问模式
   • 如果计算占比高但利用率低，说明存在指令流水线中断，需要优化指令调度
   • 如果同步占比高，说明存在核心间负载不均衡，需要调整 Tiling 策略

代码清单 6 展示了一个性能优化的迭代过程：

初始实现：单纯的数据复制，未充分利用双缓冲 ↓ 性能分析：发现 DMA 传输等待时间长，计算单元闲置 ↓ 优化1：启用双缓冲，重叠数据传输和计算 ↓ 性能分析：计算单元利用率提升，但仍有间隙 ↓ 优化2：增加循环展开，减少分支开销 ↓ 性能分析：接近理论峰值

为什么性能优化是一个迭代过程？

现代处理器的性能受多种因素交织影响：内存层级、缓存策略、指令流水线、分支预测、多线程同步等。单一优化手段往往只能解决一个问题，可能暴露出下一个瓶颈。因此，性能优化需要反复采集数据、分析问题、实施优化，直至达到满意的效果。

第六章：aclBLASLt 现代接口与轻量化 GEMM 调用

6.1 传统 BLAS 接口的局限性

传统 BLAS 接口（如aclblasSgemv、aclblasSgemm）虽然符合业界标准，但在实际应用中存在局限性：

灵活性不足：接口参数固定，无法适应多样化的计算需求。例如，某些应用场景需要特殊的矩阵布局（行主序 vs 列主序）、混合精度计算、自定义激活函数等。

性能调优困难：用户无法直接控制分块大小、核心绑定、算法选择等底层优化参数。

扩展性问题：新增算子需要修改标准接口，破坏向后兼容性。

6.2 aclBLASLt 的设计理念

aclBLASLt（Lightweight）是 ops-blas 提供的现代化、可扩展的线性代数接口，其设计灵感来源于 NVIDIA cuBLASLt。核心特点包括：

分治（Divide-and-Conquer）API 设计：将 GEMM 操作分解为多个可配置阶段：

1. 矩阵描述（Layout）创建
2. 算法选择（Algorithm）配置
3. 分块参数（Tiling）调整
4. 执行计划（Plan）生成
5. 异步执行

灵活的矩阵描述：支持任意矩阵布局（行主序、列主序、自定义跨步）。

算法自动调优：根据矩阵大小、数据类型、硬件平台自动选择最优算法和分块参数。

混合精度支持：允许输入、输出、计算使用不同精度（如 FP16 输入、FP32 计算、FP16 输出）。

6.3 aclBLASLt 调用示例

代码清单 7 展示了一个典型的 aclBLASLt GEMM 调用流程：

// 创建矩阵描述aclblasLtMatrixLayout_t Adesc=nullptr;aclblasLtMatrixLayout_t Bdesc=nullptr;aclblasLtMatrixLayout_t Cdesc=nullptr;aclblasLtMatrixLayoutCreate(&Adesc,ACLBLAS_R_32F,M,K,lda);aclblasLtMatrixLayoutCreate(&Bdesc,ACLBLAS_R_32F,K,N,ldb);aclblasLtMatrixLayoutCreate(&Cdesc,ACLBLAS_R_32F,M,N,ldc);// 创建算法选择和配置aclblasLtMatmulAlgoGetHeuristic(handle,operationDesc,Adesc,Bdesc,Cdesc,Cdesc,nullptr,0,&heuristicResult);// 创建执行计划aclblasLtMatmulPlanInit(handle,plan,operationDesc,Adesc,Bdesc,Cdesc,Cdesc,&heuristicResult.algo);// 执行 GEMMaclblasLtMatmul(handle,plan,&alpha,A,Adesc,B,Bdesc,&beta,C,Cdesc,C,Cdesc,nullptr,workspace,workspaceSize,stream);// 销毁资源aclblasLtMatmulPlanDestroy(plan);aclblasLtMatrixLayoutDestroy(Adesc);// ...

为什么需要如此复杂的接口？

因为现代 AI 计算的矩阵乘场景极其多样化：大模型训练需要支持张量并行和流水线并行，需要切分矩阵；推理需要支持量化（INT8/INT4）和稀疏化；科学计算需要支持双精度（FP64）。单一接口无法优雅地支持所有这些变体。aclBLASLt 通过"构建器模式"（Builder Pattern）提供了这种灵活性。

第七章：开发实践与调试技巧

7.1 基于 WebIDE 的快速入门

ops-blas 推荐使用 WebIDE 或 Docker 环境进行开发，因为这两种环境预装了配套版本的 CANN 包和开发工具，避免了环境配置难题。

对于新手，项目提供了以scopy算子为主线的快速入门教程（docs/QUICKSTART.md），涵盖：

1. 环境部署
2. 编译运行
3. 算子开发（修改 Kernel 代码）
4. 算子调试（添加打印、性能采集）

7.2 调试技巧：打印与 Dump

当算子执行结果不正确时，需要调试定位问题。ops-blas 支持两种调试手段：

printf 接口：在核函数中插入AscendC::PRINTF("Tiling blockLength is %llu\n", blockLength_)，打印标量数据。注意，由于 NPU 的并行执行特性，打印输出可能交错，需要仔细分析。

DumpTensor 接口：DumpTensor(zLocal, 0, 128)可以打印 LocalTensor 的内容，帮助检查数据是否正确加载或计算。

代码清单 8 展示了一个调试示例：

template<typenameT>__aicore__inlinevoidCopyAIV<T>::SingleIteration(uint32_tcurOffset,uint32_tdataCount){LocalTensor<T>inLocal=inQueue.AllocTensor<T>();DataCopy(inLocal,inGM[curOffset],dataCount);inQueue.EnQue<T>(inLocal);// 调试：打印加载的数据AscendC::PRINTF("Core %d: loaded %d elements from offset %d\n",AscendC::GetBlockIdx(),dataCount,curOffset);DumpTensor(inLocal,0,dataCount);// ... 后续计算}

7.3 性能 profiling 与瓶颈定位

msprof是昇腾生态的性能分析工具，支持采集算子的以下指标：

• 执行时间（device 端和 host 端）
• 数据传输量（DMA 读写字节数）
• 计算利用率（Vector/Cube 单元占用率）
• 内存带宽利用率

通过分析这些数据，可以定位性能瓶颈是指令流水线问题、内存带宽问题还是同步开销问题。

仓库地址：ops-blas 项目托管在 AtomGit（https://atomgit.com/cann/ops-blas）