PyTorch高性能算子必须用C++/CUDA实现核心逻辑，Python仅作调度；pybind11用于暴露C++函数，需手动处理tensor设备、dtype、contiguity；编译须用setup.py显式配置，CUDA需加错误检查与autograd支持。
为什么不能直接在Python里写高性能算子
PyTorch的Python接口本质是C++后端的薄封装，所有张量计算最终落到ATen或CUDA kernel。你用torch.tensor做循环、条件判断、逐元素if-else，性能会断崖式下跌——Python解释器开销+全局解释器锁（GIL）+无法向量化。自定义算子不是“锦上添花”，而是当torch.nn.functional里没有你需要的数学逻辑，或者现有算子组合太慢时的必选项。
常见错误现象：RuntimeError: Expected all tensors to be on the same device，或算子比纯Python还慢，基本都是因为没把数据真正移交到C++侧处理，还在Python里来回搬运。
- 必须用C++/CUDA实现核心计算逻辑，Python只负责调度和封装
- pybind11不是用来“包装Python函数”的，而是把C++函数暴露给Python调用的胶水层
- 所有
torch::Tensor输入必须在C++函数内完成device检查、dtype对齐、contiguous转换，不能依赖Python侧传入“干净”数据
如何用setuptools编译C++扩展并加载进Python
不推荐用torch.utils.cpp_extension.load做开发期热编译——它隐藏了链接细节，出错时堆栈难读，且无法控制nvcc参数或第三方库链接。生产级做法是手写setup.py，显式声明依赖和编译选项。
使用场景：你要链接OpenMP加速CPU路径，或调用cuBLAS/cuDNN的某个底层函数，或需要静态链接某个数学库（如Eigen）。
立即学习“C++免费学习笔记（深入）”；
- 在
setup.py中用CppExtension或CUDAExtension类，明确指定sources、include_dirs、libraries -
extra_compile_args里加-O3 -fopenmp（CPU）或-gencode arch=compute_75,code=sm_75（CUDA），别依赖默认值 - 安装时用
pip install -v --no-deps --no-build-isolation -e .，-v能看清每条nvcc命令是否真被执行 - 编译产物是
.so（Linux）或.pyd（Windows），Python导入时路径必须在sys.path里，别指望自动发现
pybind11封装时tensor参数怎么传、怎么取
pybind11不认识torch::Tensor，必须靠PyTorch自带的torch::python模块注册类型转换器。否则你会看到TypeError: Unable to convert function return value to Python object。
参数差异：Python传进来的torch.Tensor在C++里是torch::Tensor，但它的data_ptr()返回的是void*，需按dtype强转（如tensor.data_ptr<float>()</float>），且必须先调用tensor.contiguous()再取指针——非contiguous张量直接取ptr会读错内存。
- 在C++文件开头加
#include <torch></torch>，它自动注册了torch::Tensor的pybind11绑定 - 函数签名写成
torch::Tensor my_op(torch::Tensor input, double alpha)，pybind11会自动转换 - 务必检查
input.device().is_cuda()，CPU和CUDA路径要分开实现，混用cudaMemcpy和memcpy会卡死 - 输出tensor用
torch::empty_like(input)或torch::zeros({n}, input.options())，复用输入的dtype、device、layout
调试CUDA算子时最常卡在哪几个点
CUDA kernel崩溃不会抛Python异常，而是让Python进程静默退出，或卡在cudaStreamSynchronize。根本原因是GPU错误未被主动检查。
性能影响：没加cudaGetLastError()检查，kernel launch失败后后续操作全无效；没用cudaEventRecord测kernel耗时，误以为瓶颈在CPU侧。
- 每个kernel launch后立即跟
CUDA_CHECK(cudaGetLastError());（自己定义宏封装cudaGetLastError+ 报错信息） - 不要在kernel里用
printf调试——它只在device支持且开启-Xptxas -dlcm=cg时才工作，优先用assert+cudaDeviceSynchronize() - 核函数参数传递超过8个？拆成多个
struct传，避免寄存器溢出导致性能骤降 - 用
nvidia-smi确认你的进程真占用了GPU，有时torch.cuda.is_available()返回True但实际被其他进程锁死
最容易被忽略的是：CUDA算子必须和PyTorch的autograd系统对接。如果要支持反向传播，不能只写前向——得额外实现torch::autograd::Function子类，或用torch::autograd::gradcheck验证数值梯度。这事关模型能否正常训练，不是“先跑通再说”的环节。
