前言

在 Ascend C 算子开发中，**Host 侧（CPU）与Device 侧（AI Core）** 是分工明确的两个层级：Device 侧负责执行具体的计算逻辑（Kernel），而 Host 侧则负责算子的 “前置准备” 与 “调度管理”—— 包括参数校验、资源规划、Kernel 调用等。

对于很多开发者而言，Host 侧的代码往往被忽略：要么直接复用框架的默认逻辑，要么简单实现参数传递，导致算子的性能或兼容性出现问题。但实际上，Host 侧的实现质量直接决定了算子的 “易用性” 与 “资源利用率”—— 例如，不合理的分块策略会导致 AI Core 的计算资源闲置，错误的 Shape 推导会引发运行时崩溃。

本文将深入解析 Host 侧实现的 4 个核心操作：Tiling（分块）、Shape 推导、算子原型注册，以及 Host 侧的核心职责，帮助大家理解 Host 侧的底层逻辑，写出更高效、更健壮的 Ascend C 算子。

一、Host 侧实现的核心职责

在 Ascend C 的算子开发流程中，Host 侧的代码运行在 CPU 上，其核心职责可以总结为以下 4 点：

1.1 接收与校验用户参数

Host 侧是算子与用户的 “交互接口”：用户通过 Host 侧的 Op 接口传入输入 Tensor、配置参数等，Host 侧需要先对这些参数进行合法性校验，包括：

  • Shape 校验：如 Add 算子要求两个输入 Tensor 的 Shape 完全一致；
  • Dtype 校验：如卷积算子要求输入 Tensor 的 Dtype 为 float16 或 float32；
  • 参数范围校验：如池化算子的 kernel_size 不能超过输入 Tensor 的维度。

若参数不合法，Host 侧需要直接抛出错误（如 “Input shapes do not match”），避免错误的参数传递到 Device 侧，导致计算崩溃或结果错误。

1.2 规划 Device 侧的计算资源

Host 侧需要根据输入 Tensor 的大小、目标芯片的硬件资源，规划 Device 侧的计算资源，核心是分块（Tiling）：将大 Tensor 分成若干个小分块，每个分块的大小匹配 AI Core 的计算能力（如 256 元素 / 分块），确保 AI Core 的计算资源被充分利用。

此外，Host 侧还需要规划 Local Memory 的分配、Kernel 的线程块数量等资源，避免出现资源不足或闲置的情况。

1.3 调度 Kernel 在 Device 侧执行

Host 侧是 Kernel 的 “调度中心”：在完成参数校验与资源规划后，Host 侧会调用框架的接口（如LaunchKernel），将输入 Tensor 的数据、Kernel 的配置参数传递到 Device 侧，并调度 AI Core 执行 Kernel。

在调度过程中，Host 侧还需要处理 Device 侧的执行状态：如等待 Kernel 执行完成、获取执行结果、处理异常等。

1.4 返回计算结果给用户

Device 侧的 Kernel 执行完成后，Host 侧会将输出 Tensor 的数据从 Device 侧的 Global Memory 拷贝到 Host 侧的内存中（若需要），并将结果返回给用户 —— 这是算子调用的 “最后一步”。

二、Tiling：让计算 “适配 AI Core” 的分块策略

Tiling（分块）是 Host 侧实现中最核心的操作之一，其本质是将大 Tensor 拆分为若干个小分块，使每个分块的大小匹配 AI Core 的计算能力，从而最大化 AI Core 的资源利用率。

2.1 为什么需要 Tiling？

昇腾 AI Core 的 Vector Unit 虽然能实现大规模并行计算，但单次处理的元素数量是有限的（如 256 个 float16 元素）。若输入 Tensor 的大小超过了 AI Core 的单次处理能力（如 1024 维向量），直接将整个 Tensor 传递给 Kernel 会导致：

  • 计算资源闲置：AI Core 只能处理部分数据，其余资源处于闲置状态；
  • 内存不足：Local Memory 的容量有限（如昇腾 310B 的 Local Memory 为 256KB），无法容纳整个大 Tensor。

因此，Tiling 是解决 “大 Tensor 与硬件资源限制” 矛盾的关键手段。

2.2 Tiling 的核心原则

在 Ascend C 中，Tiling 的实现需要遵循以下 3 个核心原则：

2.2.1 分块大小匹配硬件能力

分块的大小应尽量匹配 AI Core 的 Vector Unit 宽度或 Local Memory 容量：

  • 基于 Vector Unit 宽度：如 Add 算子的分块大小设置为 256（匹配 Vector Unit 的单次处理能力），确保每个分块能被 Vector Unit 一次性处理；
  • 基于 Local Memory 容量：如卷积算子的分块大小需要考虑输入特征图、权重的内存占用，确保所有数据能同时加载到 Local Memory 中。
2.2.2 分块数量匹配线程块数量

在 Ascend C 中，Kernel 的执行是通过 ** 线程块（Block）** 实现的：每个线程块负责处理一个分块。因此，分块的数量应等于线程块的数量 ——Host 侧需要根据分块数量设置gridDim（线程块的维度）。

例如，Add 算子的输入 Tensor 大小为 1024，分块大小为 256，则分块数量为 4，对应的gridDim.x = 4。

2.2.3 处理 “非对齐分块”

若输入 Tensor 的大小不是分块大小的整数倍，最后一个分块的大小会小于分块大小（如 1024=256×4，若输入 Tensor 大小为 1100，则最后一个分块的大小为 1100-256×4=1100-1024=76）。Host 侧需要在 Tiling 逻辑中处理这种 “非对齐分块”，确保最后一个分块能被正确处理。

2.3 Tiling 的代码实现（以 Add 算子为例）

以下是 Add 算子 Host 侧 Tiling 逻辑的代码示例：

c++

// Add算子的Tiling类
class AddTiling : public TilingBase {
public:
    // 分块大小（匹配Vector Unit宽度）
    static constexpr int BLOCK_SIZE = 256;

    // Tiling的核心函数：计算分块数量、线程块配置等
    Status ComputeTiling(const std::vector<TensorPtr>& inputs, const std::vector<TensorPtr>& outputs) override {
        // 1. 获取输入Tensor的大小
        int64_t size = inputs[0]->GetShape()[0];

        // 2. 计算分块数量
        int block_num = (size + BLOCK_SIZE - 1) / BLOCK_SIZE;  // 向上取整

        // 3. 设置线程块配置（gridDim）
        grid_dim_.x = block_num;
        grid_dim_.y = 1;
        grid_dim_.z = 1;

        // 4. 设置每个线程块的大小（blockDim）
        block_dim_.x = 1;  // Add算子的Kernel不需要多线程，每个Block对应一个分块
        block_dim_.y = 1;
        block_dim_.z = 1;

        // 5. 记录分块信息（供Kernel使用）
        tiling_info_.block_size = BLOCK_SIZE;
        tiling_info_.size = size;

        return Status::SUCCESS;
    }

private:
    AddTilingInfo tiling_info_;  // 分块信息结构体
};

在上述代码中，我们通过(size + BLOCK_SIZE - 1) / BLOCK_SIZE的方式计算分块数量（向上取整），并设置了线程块的配置（gridDim）—— 这些信息会被传递到 Kernel 中，供 Kernel 确定每个分块的处理范围。

三、Shape 推导：保证 Tensor 维度的合法性

Shape 推导是 Host 侧的 “参数校验核心环节”，其本质是根据输入 Tensor 的 Shape，计算输出 Tensor 的 Shape，并验证输入 Shape 的合法性。

3.1 Shape 推导的核心作用

Shape 推导的作用主要有以下 2 点：

  • 保证输入 Shape 的合法性：如 Add 算子要求两个输入 Tensor 的 Shape 完全一致，若不一致则抛出错误；
  • 确定输出 Shape 的正确性：如 Add 算子的输出 Shape 与输入 Shape 完全一致，卷积算子的输出 Shape 需要根据输入 Shape、kernel_size、stride 等参数计算得出。

3.2 Shape 推导的实现逻辑（以 Add 算子为例）

以下是 Add 算子 Host 侧 Shape 推导的代码示例：

c++

// Add算子的Op类
class AddOp : public OpBase {
public:
    // Op的构造函数：绑定Shape推导逻辑
    AddOp() {
        shape_infer_func_ = std::bind(&AddOp::InferShape, this, std::placeholders::_1, std::placeholders::_2);
    }

    // Shape推导函数
    Status InferShape(const std::vector<TensorPtr>& inputs, std::vector<TensorPtr>& outputs) override {
        // 1. 校验输入Tensor的数量
        if (inputs.size() != 2) {
            return Status::FAILED("AddOp requires 2 inputs");
        }

        // 2. 校验两个输入Tensor的Shape是否一致
        TensorPtr x1 = inputs[0];
        TensorPtr x2 = inputs[1];
        if (x1->GetShape() != x2->GetShape()) {
            return Status::FAILED("Input shapes do not match: x1 shape is " + x1->GetShape().ToString() + ", x2 shape is " + x2->GetShape().ToString());
        }

        // 3. 计算输出Tensor的Shape（与输入一致）
        outputs.resize(1);
        outputs[0] = std::make_shared<Tensor>(x1->GetShape(), x1->GetDtype());

        return Status::SUCCESS;
    }
};

在上述代码中，我们首先校验输入 Tensor 的数量，然后验证两个输入 Tensor 的 Shape 是否一致，最后设置输出 Tensor 的 Shape 与输入一致 —— 这一逻辑确保了 Add 算子的输入参数合法，输出 Shape 正确。

四、算子原型注册：让框架 “认识” 你的算子

写完 Host 侧的 Tiling、Shape 推导逻辑后，需要将算子注册到昇腾框架中，才能被框架识别并调用。算子原型注册是 Host 侧实现的 “最后一步”，其本质是向框架声明算子的接口规范、绑定 Host 侧的逻辑。

4.1 算子原型注册的核心内容

在 Ascend C 中，算子原型注册需要包含以下内容：

  • 算子名称：如 “Add”，是用户调用算子的标识；
  • 输入 / 输出声明：声明输入、输出 Tensor 的数量、类型；
  • 参数约束：声明输入参数的合法性约束（如 Shape 一致）；
  • 绑定 Host 侧逻辑：绑定 Shape 推导函数、Tiling 函数等；
  • 关联 Device 侧 Kernel：关联 Device 侧的 Kernel 实现。

4.2 算子原型注册的代码实现（以 Add 算子为例）

以下是 Add 算子原型注册的代码示例：

c++

// 注册Add算子的原型
REGISTER_OP(Add)
    // 声明输入：x1（float16）、x2（float16）
    .INPUT(x1, TensorType::FLOAT16)
    .INPUT(x2, TensorType::FLOAT16)
    // 声明输出：y（float16）
    .OUTPUT(y, TensorType::FLOAT16)
    // 声明参数约束：输入Shape必须一致
    .REQUIRE(x1.shape() == x2.shape(), "Input shapes must be the same")
    // 绑定Op的构造函数
    .SET_OP_CONSTRUCT_FUNC(AddOp::Construct)
    // 绑定Tiling函数
    .SET_TILING_FUNC(AddTiling::ComputeTiling)
    // 关联Device侧的Kernel
    .SET_KERNEL_FUNC(AddKernel);

在上述代码中，REGISTER_OP是 Ascend C 提供的算子注册宏，通过链式调用的方式声明算子的各项信息：

  • .INPUT/.OUTPUT声明输入输出；
  • .REQUIRE声明参数约束；
  • .SET_OP_CONSTRUCT_FUNC绑定 Op 的构造函数；
  • .SET_TILING_FUNC绑定 Tiling 函数；
  • .SET_KERNEL_FUNC关联 Device 侧的 Kernel。

五、Host 侧实现的调试与优化技巧

在实际开发中，Host 侧的实现往往会出现各种问题（如分块错误、Shape 推导失败），以下是一些常用的调试与优化技巧：

5.1 打印日志调试

在 Host 侧的代码中添加日志打印，输出输入 Tensor 的 Shape、分块数量、线程块配置等信息，帮助定位问题：

c++

// 打印输入Tensor的Shape
std::cout << "x1 shape: " << x1->GetShape().ToString() << std::endl;
// 打印分块数量
std::cout << "block num: " << block_num << std::endl;

5.2 模拟分块逻辑

在本地环境中模拟分块逻辑，验证分块数量、分块大小的正确性：

c++

// 模拟分块逻辑
int size = 1100;
int block_size = 256;
int block_num = (size + block_size - 1) / block_size;
for (int i = 0; i < block_num; ++i) {
    int start = i * block_size;
    int end = min(start + block_size, size);
    std::cout << "block " << i << ": start=" << start << ", end=" << end << std::endl;
}

5.3 优化分块策略

根据硬件资源的实际情况优化分块策略：

  • 若 AI Core 的 Vector Unit 宽度为 512，则将分块大小设置为 512；
  • 若 Local Memory 容量较大，则可以适当增大分块大小，减少分块数量，降低内存操作的开销。

结语

Host 侧的实现是 Ascend C 算子开发中 “承上启下” 的关键环节：它既是用户与算子的交互接口，也是 Device 侧计算资源的调度中心。掌握 Tiling、Shape 推导、算子注册等核心操作，不仅能写出更高效、更健壮的算子，更能深入理解 Ascend C 框架的底层逻辑。

在实际开发中，很多开发者会忽略 Host 侧的优化：例如，使用框架的默认 Tiling 逻辑导致资源闲置，或者跳过 Shape 推导的详细校验引发运行时错误。因此，建议大家在开发算子时，重视 Host 侧的实现细节，结合硬件资源与业务场景，定制化设计 Tiling 策略与 Shape 推导逻辑。

在后续的文章中，我们将解析算子开发的工程流程（快速流程 vs 标准流程），帮助大家选择合适的开发方式，进一步提升算子开发的效率。

 2025年昇腾CANN训练营第二季，基于CANN开源开放全场景，推出0基础入门系列、码力全开特辑、开发者案例等专题课程，助力不同阶段开发者快速提升算子开发技能。获得Ascend C算子中级认证，即可领取精美证书，完成社区任务更有机会赢取华为手机，平板、开发板等大奖。

报名链接:https://www.hiascend.com/developer/activities/cann20252
 

# microsoft # windows # 昇腾
Logo
CANN开发者社区

CANN开发者社区旨在汇聚广大开发者，围绕CANN架构重构、算子开发、部署应用优化等核心方向，展开深度交流与思想碰撞，携手共同促进CANN开放生态突破！

更多推荐

cover

芯模赋能，智启未来：杭电CANN启航营圆满收官，解锁AI实践

avatar CANN开发者社区
cover

第九届信息技术新工科产学研联盟年会召开CANN开源社区分享高校人才生态建设

avatar CANN开发者社区
cover

芯聚力量，智创未来：南京信息工程大学CANN启航营圆满收官，为AI注入青春力量

avatar CANN开发者社区