璧韧GPU算子开发实战：从矩阵乘到性能调优的完整记录

这张璧韧卡是周五下午拆开包装的。我第一件事不是跑benchmark，而是把自己最熟的一个ResNet推理脚本丢上去，心想换个后端也就几条环境变量的事。结果等来的是惨到没法看的延迟——同样batch size，比平时在用的参考卡慢了快一个数量级。驱动装了，环境也配了，一度怀疑是卡本身有问题。后来花了两天时间一路追到算子层，才反应过来：模型跑得动和跑得快，根本是两码事。

GPU算子这个词，做AI的人天天挂在嘴边，但真正被逼着去逐行抠算子的，往往是换了硬件平台之后。璧韧系列这篇“01”，我决定不装高深，从最基础的算子概念讲起，再完整记录一次从环境准备、算子编写、性能调优到踩坑排错的实跑过程。后面每一篇会围绕一个具体算子展开，这篇先把路子趟平。

1. 为什么先聊算子：一张卡能不能打，先看这层“螺丝钉”

1.1 算子到底是个什么东西

我把算子拆成一句大白话：给定若干张量输入，做一次确定性的数学运算，输出若干张量。 卷积是算子，矩阵乘是算子，LayerNorm、Softmax、ReLU都是算子。AI框架里的神经网络，本质是一张有向无环图，节点是算子，边是流动的张量。

看起来很简单。但难点在于：同一个数学逻辑，在不同硬件上怎么写、怎么优化，性能可以差一个数量级以上。你用PyTorch写一个torch.matmul(a, b)，NVIDIA平台上会路由到cuBLAS里经过几十年调优的kernel；在璧韧这类非NVIDIA平台上，这条调用链会走到哪里，取决于算子生态覆盖了多少、每个kernel优化到什么程度。

很多做AI应用的同学不直接感知算子的存在，是因为框架帮你把底层屏蔽了。一旦换了硬件平台，这个“屏蔽层”厚度立刻打回原形。算子数量大不大？非常大。一个常用深度学习模型涉及的算子类型大概几十种，但加上各种特殊shape、数据类型、融合模式，实际需要维护的kernel数量是几百上千的规模。这就是为什么“能跑”容易，“跑得快”很难。

1.2 一张GPU卡能跑模型，不代表就能跑得快

我举一个真实观察。很多人第一次拿到非NVIDIA的GPU卡，流程通常是：装驱动、装框架的适配版本、跑脚本。如果模型能正常出结果，就会觉得“适配得还挺好”。但如果你顺手打印一下各层耗时，会发现Conv、MatMul这类大算子往往还好，反而是LayerNorm、Softmax、各种elementwise小算子占比高得离谱。

原因很直接：大算子通常是各家芯片厂商优先优化的对象，会专门手写汇编级kernel；而小算子如果只是简单编译映射，没有针对内存布局和并行度做优化，访存效率会非常差。算子的性能不是“能不能算”的问题，而是“数据搬得快不快、计算单元等没等数据”的问题。 这句话是理解后面所有优化动作的钥匙。

1.3 为什么要单独写璧韧系列

市面上的算子优化文章，绝大多数以NVIDIA CUDA为背景。但璧韧这类芯片的编程模型、工具链、算子生态成熟度，和CUDA相比有明显差距。刚上手时，很多CUDA上的经验可以平移，但也有不少地方“看起来一样，跑起来不一样”。

我写这个系列的核心目的很朴素：把璧韧算子开发的真实过程记录下来，包括硬件特性、编程接口、性能分析思路、实际踩过的坑。不是抄官方文档，是拿一个算子一个算子地跑出数据，说实话，给后来的人省点时间。

2. 璧韧芯片的硬件底子：动手写算子前先看懂这几件事

写算子如果只盯着代码不看硬件，等于闭着眼开车。璧韧的底层架构我不展开讲太多细节，因为不同型号差异不小，但几个核心设计思想是通用的。

2.1 计算单元与线程组织方式

璧韧GPU采用典型的GPGPU设计思路：大量简单计算核心组成多级并行结构，以SIMT方式执行。你写的一个kernel函数，会被实例化成成千上万个线程同时跑。线程的层级关系也遵循常见模型：

• 线程：最小的执行单元，每个线程跑同一份代码、处理不同数据。
• 线程束：硬件调度和执行的单位，一批线程作为一个整体被派发到计算核心上执行。这个大小通常和SIMD宽度相关。
• 线程块：编程层面的线程集合，块内线程可以协作、同步，共享一块片上内存。
• 线程网格：整个kernel启动时创建的全部线程集合。

这个组织方式和CUDA非常接近，所以从CUDA迁移过来的开发者会觉得熟悉。但熟悉不等于照搬，因为具体到计算核心数量、线程束大小、片上内存容量，璧韧各型号都可能有自己的参数，这些参数直接决定了你该怎么设计kernel的形状。

2.2 访存结构：芯片性能的胜负手

芯片的存储体系是金字塔结构，离计算单元越近，容量越小、速度越快。璧韧的存储层次大致可以分为：

矩阵乘这类计算密集型算子，理论计算量很大，但你实际能达到的速度往往不取决于算得多快，而取决于数据从显存搬到计算单元的速度。这就是经典的roofline模型：计算密度低时是访存瓶颈，计算密度高时才是算力瓶颈。

2.3 硬件视角下算子优化的两个出发点

看懂硬件之后，算子优化的方向其实就两条：让计算单元别等数据、让数据在片上尽量多复用。 无论你是调卷积、调矩阵乘还是调LayerNorm，做的一切动作最终都落在这两句话上。

举个例子：一个朴素的矩阵乘，每个线程负责算输出矩阵的一个元素。这个逻辑没错，但它每次计算都要从显存读一行A和一列B。如果不做任何缓存优化，显存带宽会被打到爆炸，计算单元大量时间在空转等待数据。后面我会演示怎么用片上内存把访存量降下来，这是同样的代码逻辑下性能能翻十几倍的核心原因。

3. 一条数据从PyTorch到璧韧算子的完整旅程

这一章不是讲理论，而是帮你在脑海里建立一条完整的链路。很多人出了性能问题不知道从哪查，就是因为只知道“PyTorch调到GPU跑”，不知道中间到底经过了几道关卡。

3.1 AI框架侧的调度逻辑

以PyTorch为例。你调用torch.matmul(a, b)时，首先进入的是ATen的dispatch机制。PyTorch会检查张量的device类型和布局，然后找到对应的后端实现。如果你装了璧韧适配的插件，PyTorch就能把算子分发给璧韧的运行时；如果没装，就会掉到CPU实现上。

这个细节非常关键：我见过有人号称“用GPU跑了模型”，一看日志，算子全在CPU上执行。因为PyTorch对非NVIDIA后端的支持需要额外的后端注册机制，通常通过torch.library或特定适配插件完成。如果你的算子没有注册到璧韧后端，框架会悄悄用CPU实现兜底，模型还能跑，但慢得离谱。

3.2 从框架分发到GPU执行

算子被分发给璧韧运行时后，链路是这样的：

1. 璧韧的运行时库接收算子描述（输入张量、输出张量、参数）。
2. 运行时根据算子类型从kernel库中找到对应实现，或者通过JIT把源码编译成机器码。
3. host端准备好参数缓冲区，把kernel启动参数写入。
4. 驱动把kernel派发到GPU设备上，GPU上的线程网格开始执行。
5. 执行完毕后，通过同步操作通知host端。

这条链路里容易出问题的点依次是：后端注册缺失、kernel库覆盖不足、JIT编译不稳定、同步和异步语义混淆。 后面踩坑部分我再展开。

3.3 打通链路前最容易忽略的验证动作

刚接触一个新平台时，我建议不要直接跑大模型，先做一个最小验证：创建一个几百MB的随机张量，在璧韧设备上做一次矩阵乘或加法，手动打印shape、device、耗时。确认这一条小路走通了，再往上堆模型。

如果这一步就出问题，省下来的时间够你后面排查十倍的麻烦。我当时就是跳过了这一步，直接跑ResNet，结果性能差得离谱，花了半天才确认算子链路本身是通的，问题出在算子实现效率上。

4. 手写第一个璧韧算子：从矩阵乘开始的完整流程

矩阵乘是算子界的“hello world”，也是几乎所有深度学习模型的核心计算。这一章我把完整流程走一遍：环境准备、host端代码、device端kernel、编译运行、正确性验证。

4.1 环境准备与工程搭建

你需要的东西包括：璧韧设备驱动、璧韧的异构编程工具包（包含编译器、运行时库、头文件）、Python端适配插件（如果要和PyTorch联动）。此外建议装一个支持璧韧设备查询的工具，用来确认驱动版本、设备名称、显存大小。

我在项目里通常使用一个CMake工程来组织代码，结构如下：

code复制matmul_demo/
├── CMakeLists.txt
├── src/
│   ├── main.cpp           # host侧主逻辑
│   └── matmul_kernel.h    # device侧kernel声明
├── cmake/
│   └── FindBiren.cmake    # 查找璧韧工具包的CMake模块
└── scripts/
    └── run_demo.sh        # 编译和运行脚本

璧韧的编程接口在语法上和业界常见的类CUDA异构编程模型非常接近，有global修饰符、线程索引内置变量、显存分配/拷贝接口。具体头文件和库名请以你拿到的SDK文档为准，本篇为了可读性，接口风格用类CUDA写法示意，重点是逻辑链路而不是逐字复刻API。

4.2 host侧代码怎么写

host侧负责的事情有六件：分配显存、初始化数据、设置执行配置、调用kernel、等待完成、回收资源。核心代码如下：

cpp复制#include <iostream>
#include <cstdlib>
#include <chrono>
#include "matmul_kernel.h"

int main() {
    const int M = 512, N = 512, K = 512;
    size_t bytes_a = M * K * sizeof(float);
    size_t bytes_b = K * N * sizeof(float);
    size_t bytes_c = M * N * sizeof(float);

    // 在host侧分配并初始化数据
    float* h_a = (float*)malloc(bytes_a);
    float* h_b = (float*)malloc(bytes_b);
    float* h_c = (float*)malloc(bytes_c);
    for (int i = 0; i < M * K; i++) h_a[i] = float(rand() % 100) / 10.0f;
    for (int i = 0; i < K * N; i++) h_b[i] = float(rand() % 100) / 10.0f;

    // 在device侧分配显存
    float *d_a, *d_b, *d_c;
    device_malloc((void**)&d_a, bytes_a);
    device_malloc((void**)&d_b, bytes_b);
    device_malloc((void**)&d_c, bytes_c);

    // 把输入数据拷贝到显存
    memcpy_host_to_device(d_a, h_a, bytes_a);
    memcpy_host_to_device(d_b, h_b, bytes_b);

    // 设置线程块和网格尺寸
    dim3 block(16, 16);
    dim3 grid((N + block.x - 1) / block.x, (M + block.y - 1) / block.y);

    // 启动kernel
    matmul_naive<<<grid, block>>>(d_a, d_b, d_c, M, N, K);
    device_synchronize();

    // 把结果拷回host并打印部分值
    memcpy_device_to_host(h_c, d_c, bytes_c);
    for (int i = 0; i < 5; i++) std::cout << h_c[i] << " ";
    std::cout << std::endl;

    // 释放资源
    device_free(d_a);
    device_free(d_b);
    device_free(d_c);
    free(h_a); free(h_b); free(h_c);
    return 0;
}

如果你有CUDA经验，会发现这套逻辑几乎是无痛迁移的。需要注意的一点是：璧韧的运行时可能有自己推荐的异步执行和同步方式，建议阅读SDK中关于stream/event的部分，使用异步接口配合同步点，而不是简单地在每个kernel后面同步。 刚上手可以用同步方式保平安，做性能测试时再切异步。

4.3 device侧kernel的朴素实现

kernel端代码是真正跑在GPU上的部分。素朴版矩阵乘逻辑：一个线程负责计算输出矩阵的一个元素，遍历K维度累计乘加结果。

cpp复制// matmul_kernel.h
#ifndef MATMUL_KERNEL_H
#define MATMUL_KERNEL_H

// 索引命名：row对应M维度，col对应N维度，k是累加维度
__global__ void matmul_naive(const float* A,
                             const float* B,
                             float* C,
                             int M, int N, int K) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;

    if (row < M && col < N) {
        float acc = 0.0f;
        for (int k = 0; k < K; k++) {
            acc += A[row * K + k] * B[k * N + col];
        }
        C[row * N + col] = acc;
    }
}

#endif

每个线程的工作量是K次乘加，看起来没问题。但这个版本有几个明显的性能问题：

• 每次循环都要访问两次全局显存：A的一个元素、B的一个元素。A的行内访问是连续的，但B的列访问是跳跃的，缓存命中率很差。
• 同一个线程对A和B的访问没有复用，相邻线程算相邻列时，B的列访问会重复很多。
• 没有利用任何片上内存，所有数据都从显存拿。

这个版本能跑，但性能会非常难看。为什么还要写它？因为正确性验证是性能调优的前提。你后续做了任何优化，都要拿这个naive版本的结果当基准做比对，确保优化没有改坏结果。

4.4 正确性验证与结果分析

我的验证习惯是：先用小规模矩阵（比如M=N=K=16）跑一遍，把GPU结果和CPU上自己写的一个三重循环参考实现做逐元素对拍。误差阈值要合理，float累加本身会有精度误差，我通常用1e-3的相对误差容忍度。

确认结果正确后，再用大一点的矩阵做性能测量。性能指标用GFLOPS（每秒十亿次浮点运算），矩阵乘的计算量是2 * M * N * K，除以耗时就是FLOPS。

拿512x512的矩阵乘来说，计算量约0.268 GFLOP。我第一版naive kernel跑出来的耗时是0.92 ms左右，折算下来约291 GFLOPS。你可能觉得这数字还凑合，但和璧韧这代芯片的理论算力相比，连5%都不到。也就是说，计算单元绝大部分时间在干等数据。

5. 初版性能不到理论峰值5%：三个优化动作让算子上了一个台阶

上一章的naive版本帮我验证了功能正确，但性能完全不能看。这一章记录我对它做的三次优化，每一步都有明确的性能分析依据，不是盲目堆技巧。

5.1 为什么naive版本这么慢：用roofline模型说话

咱先用一道简单的算术题说明问题。假设矩阵是512x512，kernel的访存量怎么算？每个输出元素需要读A的一整行（K个元素）和B的一整列（K个元素）。输出元素有M*N个，所以总访存量大约是2 * M * N * K个float，也就是物理上要把所有数据重复读很多遍。

计算密度 = 总计算量 / 总访存量。naive版本里计算量是2 * M * N * K，访存量也是2 * M * N * K，计算密度只有1 FLOP/Byte。而璧韧这类GPGPU的roofline转折点通常在几十到上百FLOP/Byte量级。算力再高也没用，你卡在带宽上。这就是naive版本性能差的根本原因：它是访存密集型实现，但面对的却是计算密集型问题。

5.2 第一个动作：利用片上共享内存做分块

既然问题是显存访问太频繁，优化思路就是让数据在片上多复用。最经典的方案是分块矩阵乘：一个线程块负责计算输出矩阵的一个子块，先把需要的A子块和B子块从显存搬到共享内存，然后所有线程在片上完成计算。

cpp复制// 线程块负责计算 TILE_M x TILE_N 的输出子块
// 每个线程负责子块内一个元素
__global__ void matmul_tiled(const float* A,
                             const float* B,
                             float* C,
                             int M, int N, int K) {
    __shared__ float As[TILE_M][TILE_K];
    __shared__ float Bs[TILE_K][TILE_N];

    int row = blockIdx.y * TILE_M + threadIdx.y;
    int col = blockIdx.x * TILE_N + threadIdx.x;
    float acc = 0.0f;

    // 沿K维度分块搬运
    for (int k0 = 0; k0 < K; k0 += TILE_K) {
        // 协作搬运A的子块到共享内存
        As[threadIdx.y][threadIdx.x] =
            A[(blockIdx.y * TILE_M + threadIdx.y) * K + k0 + threadIdx.x];
        // 协作搬运B的子块到共享内存
        Bs[threadIdx.y][threadIdx.x] =
            B[(k0 + threadIdx.y) * N + blockIdx.x * TILE_N + threadIdx.x];
        __syncthreads();

        // 在片上累加
        for (int kk = 0; kk < TILE_K; kk++) {
            acc += As[threadIdx.y][kk] * Bs[kk][threadIdx.x];
        }
        __syncthreads();
    }

    C[row * N + col] = acc;
}

这个版本的核心思想是空间换时间：用片上的显式缓存承载A和B的子块数据，让每个数据在共享内存里被TILE_M和TILE_N个线程复用。TILE_K这个维度决定了搬运的粒度。我测试时TILE大小取16，配合16x16的线程块，显存访问量直接降了几个数量级，性能有了质的飞跃。

5.3 第二个动作：向量化访存与循环展开

分块做了之后，性能上来了，但看一下profiling数据，还有一个很明显的问题：访存指令太碎。每个线程一次只读4字节，这对现代GPU的访存单元来说太浪费了。优化方向是向量化访存，一次读16字节的float4。

向量化之后还有一层优化：循环展开。在计算循环里，编译器有时候能帮你展开，但有时代码写得太复杂导致它不敢做。手动展开的好处是减少循环控制开销，让更多的乘加指令连续发射。我在璧韧上实测，展开因子取4左右比较稳定，展开太多会让寄存器压力变大，反而降低占用率。

这一阶段有个特别容易踩的细节：共享内存向量化读写时要注意对齐和bank冲突。 共享内存的bank宽度通常是4字节，如果你访问As[threadIdx.y][kk]这种布局，同一行的线程如果恰好访问同一个bank，会发生冲突，严重时让共享内存访问慢好几倍。我当时做的一个调整是在共享内存的行尾加padding，把As[TILE_M][TILE_K + 1]，这样列方向错位，bank冲突大幅减少。这个操作代码上只动了一个中括号，性能差了20%以上。

5.4 第三个动作：调整线程块形状和每线程计算量

第三个优化动作看起来不起眼，收益却不小。之前的版本每个线程只负责一个输出元素，这带来两个问题：一是线程数量太多，调度和调优开销大；二是每个线程做的工作量太小，计算的累积效应不够，访存latency很难被隐藏。

优化思路是：降低线程数，提升每线程计算量。 比如让一个线程块负责32x32的输出子块，但只启动16x16个线程，每个线程通过循环计算2x2个输出元素。这样一来，A和B的某个数据可以在寄存器或共享内存里被复用两次，进一步压降访存量，同时每个线程有了更长的计算序列来遮盖访存延迟。

这里需要强调一个观点：线程数多不等于并行度高。 并行度取决于SM上能同时驻留多少活跃线程束，而每个SM的寄存器文件和共享内存是有限的。你把每线程的寄存器用量降下来，SM能塞下更多线程块，整体吞吐才会上去。所以做算子调优时要在寄存器、共享内存、线程块大小之间找平衡点，这往往是玄学味道最重的地方，只能靠实际profile数据说话。

5.5 三招之后的性能对比

优化过程不是一蹴而就的。我记录了一组实测数据：

需要说明的是，这里的绝对数字只针对我手里这张璧韧卡和512x512的小矩阵，不代表芯片的峰值能力。但相对的加速趋势是典型的：共享内存分块带来的提升最猛，向量化和线程形状调整是锦上添花但必不可少。

6. 这一路踩过的坑：璧韧算子开发中值得记录的四个问题

代码能跑通、性能能看之后，真正的硬仗才开始。这一章记录我在这个过程中遇到的四个坑，每个都花了我不少时间。写出来，希望你不用重走。

6.1 一个越界访问导致的神秘死锁

现象描述：kernel在某些矩阵尺寸下表现正常，但把M、N、K换成不能被16整除的尺寸时，程序直接挂起，没有任何错误输出。

排查链路：

1. 第一反应是看host侧的同步返回码，结果没有报错。
2. 加上逐行打印，发现卡在kernel启动之后，说明GPU侧执行异常。
3. 怀疑是边界判断缺失，我检查了代码，发现if (row < M && col < N)这个guard是有的。
4. 进一步检查共享内存下标，发现问题出在搬运循环：当blockIdx.y * TILE_M + threadIdx.y恰好等于M时，共享内存写入仍然执行，但A的地址越界了。因为越界访问没有触发异常，而是破坏了相邻地址的数据，在特定尺寸下恰好踩到了驱动内部结构，导致挂起。

这个坑的教训是：kernel里的每个显存访问都要在guard内完成，包括共享内存的搬运阶段。 你不能只在最后写回数据时判断边界，前面每一步读到显存的地方都要判断。

6.2 编译优化级别把代码改坏了

现象描述：同样的kernel，用-O2编译跑出的结果和-O0相差很多，某些元素误差大到1e-1量级。

排查链路：

1. 一开始以为是并行计算本身的浮点误差，但1e-1的误差对float累加来说太大了。
2. 把kernel单独抽出来，用不同优化级别编译对拍，确认是编译选项的问题。
3. 查看反汇编，发现开了-O2后，编译器把乘加运算重排了，并且启用了类似fast math的重写规则，把非规格化浮点数直接flush成0，破坏了精度。
4. 解决办法：对算子kernel单独关闭fast math选项，保持常规的IEEE浮点语义。

这个坑在NVIDIA平台也存在，但璧韧的编译器在处理某些边界浮点值时的行为更激进。我的建议是：首先要保证正确性，再谈性能。 编译选项里和fast math相关的开关，默认关掉，除非你对数值误差有明确预期。

6.3 warmup问题：第一次跑出来的性能数据不能信

现象描述：同一份kernel，连续跑10次，第一次耗时会比后续几次高出30%到50%，而且前几次耗时一直不稳定。

排查链路：

1. 我一开始以为是环境温度或功耗波动，但波动幅度实在太大。
2. 检查驱动日志，发现首次调用kernel时，运行时会触发额外的初始化流程，包括编译缓存加载、显存分配、性能计数器初始化等。
3. 后续调用之所以快，是因为这些初始化已经被跳过。
4. 我对璧韧的Triton或其他JIT路径测试后发现，有的算子走的是运行时编译，首次调用要把源码编译成机器码，这个开销可能高达数百毫秒。如果某个模型加载时很多算子都在第一次调用时才编译，耗时会大得惊人。

正确的benchmark姿势是：正式测量前先跑5到10次warmup，抛弃前几次的数据，只统计后面稳定的区间。 这个经验在写博客或做报告时尤其重要，否则你给出的“性能数据”只是启动开销，不是真实算力。

6.4 显存带宽跑不满的罪魁祸首：错误的对齐方式

现象描述：矩阵规模翻倍之后，耗时不是线性增长，而是突然跳变。比如从512到1024，耗时涨了不止4倍。

排查链路：

1. 先用profile工具看访存效率，发现全局内存load/store的利用率只有60%左右。
2. 检查数据地址，宿主分配的大数组起始地址没问题，但矩阵的每一行起始地址因为行距是K个float，而K不是4的倍数时，行的对齐就被破坏了。
3. 向量化访存指令要求16字节对齐，一旦地址不对齐，指令会被拆成多个标量指令，访存效率暴跌。
4. 解决办法有两个：要么向上取整分配行的stride，比如把K向上对齐到4的倍数；要么在数据预处理阶段做一次转置或padding，保证每行起始地址天然对齐。

这个问题非常隐蔽，因为程序结果完全正确，只是性能莫名其妙地变差。我做算子优化时的经验是：每层数据结构都要单独检查对齐情况，尤其是从框架API拿到的张量，底层存储往往藏着额外的stride和offset。

把这张璧韧卡从“能跑到”调成“能跑好”的过程，让我彻底把算子的理解从理论层面拉到了实弹射击层面。硬件各有各的脾气，但这套方法论是通用的：先看访存特征，再做数据复用，再抠指令细节，最后回归正确性验证。接下来我打算把注意力放到FlashAttention风格的高阶融合算子上，那个系列会涉及更复杂的分块策略和内存调度，到时候再单独开一篇聊。这篇01只是个开始，后面见。