cublasgemmex是大规模乘法的唯一合理选择，因其支持异步、任意内存布局、混合精度、灵活stride及精确错误反馈，而cublassgemm等旧接口受限于列主序、无异步、易静默出错。
直接用 cublasGemmEx，别碰 cublasSgemm/cublasDgemm 做大规模乘法——它们不支持异步、不支持非标准 layout、不支持混合精度，一上大矩阵就卡死或报 CUBLAS_STATUS_INVALID_VALUE。
为什么 cublasGemmEx 是大规模乘法的唯一合理选择
旧版 cublasSgemm 等函数强制要求输入矩阵按列主序（column-major）且 stride 必须等于 leading dimension，而 C++ 里绝大多数矩阵是行主序（row-major）一维数组。强行适配会导致：要么手动转置（内存翻倍 + 额外拷贝），要么传错 lda/ldb 参数（常见错误：把 lda = M 写成 lda = K，结果静默出错）。cublasGemmEx 允许显式指定 AType、BType、CType 和各自的 lda/ldb/ldc，还能控制是否 transposed，真正解耦了内存布局与数学语义。
- 它支持 FP16 输入 + FP32 Accumulate（
CUDA_R_16F→CUDA_R_32F），比纯 FP32 节省带宽且不损失最终精度 - 它允许
ldc大于M，方便写入预分配的 padded buffer，避免每次重 alloc - 它返回
cublasStatus_t可直接检查，不像cublasDgemm出错时可能只设全局状态
cublasGemmEx 调用前必须检查的 4 个参数
漏检任意一个，都会在运行时报 CUBLAS_STATUS_INVALID_VALUE，且错误信息不指明具体哪个参数错。
-
m、n、k：必须是正整数，且不能超过 GPU 显存能容纳的线性尺寸（例如 A 是m×k，则m*k*sizeof(float)≤ 可用显存） -
lda：对 A，若未 transpose，则lda ≥ m；若 transpose，则lda ≥ k—— 很多人在这里反着设 -
ldb：对 B，若未 transpose，则ldb ≥ k；若 transpose，则ldb ≥ n -
ldc：必须 ≥m，哪怕你只用前m×n个元素；小于则直接 crash
数据搬运和流同步最容易被忽略的坑
很多人以为只要 cudaMemcpyAsync + cudaStreamSynchronize 就够了，其实 cuBLAS 内部也依赖 stream。不显式绑定，cuBLAS 会用默认 stream，导致 CPU 等 GPU、GPU 又等自己，吞吐掉一半。
- 必须调用
cublasSetStream(handle, stream)，且在cublasGemmEx前完成 - 输入拷贝用
cudaMemcpyAsync(d_A, h_A, ..., stream)，输出拷贝也必须用同个stream - 如果中间穿插了其他 kernel，记得在
cublasGemmEx前加cudaStreamWaitEvent或显式cudaStreamSynchronize(stream)，否则结果不可靠 - 别用
cublasSetVector做大矩阵搬运——它底层是分块 memcpy，小矩阵还行，>1GB 就比裸cudaMemcpyAsync慢 20%+
释放资源时最隐蔽的崩溃点
cublasDestroy 不是“可有可无的礼貌”，它是强制同步点。如果在 cublasGemmEx 后立刻 cudaFree 设备内存，而 cublasDestroy 还没跑，GPU 上的计算可能仍在写 d_C，free 就会触发 illegal memory access。
- 顺序只能是：
cublasGemmEx→cudaMemcpyAsync(..., stream)→cudaStreamSynchronize(stream)→cudaFree→cublasDestroy - 不要在多线程里共享同一个
cublasHandle_t：即使加锁，内部 stream 状态也可能冲突；每个线程应有自己的 handle - 如果程序里用了
cudaMallocManaged，cublasGemmEx仍需显式指定cudaHostAlloc的 pinned memory 才能保证 async 性能，否则降速 3–5×
大规模乘法真正的瓶颈从来不在计算本身，而在你有没有让数据在 host/gpu/stream 三者之间“刚好准时”地抵达。参数设对只是起点，流控和内存生命周期才是决定能否跑满 GPU 的分水岭。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
