想反映一个问题，就是我们在 DTK 25.04 的 GPUfusion CUDA 兼容接口中遇到了 cusolverDnXpotrf_bufferSize 的输出参数问题，希望确认接口行为。 调用逻辑简化如下： ```cpp size_t device_bytes; size_t host_bytes; cusolverStatus_t status = cusolverDnXpotrf_bufferSize( handle, params, CUBLAS_FILL_MODE_LOWER, n, CUDA_R_64F, dA, lda, CUDA_R_64F, &device_bytes, &host_bytes ); // 调用方当前只支持不需要 CPU 工作区的情况 if (host_bytes != 0) throw std::runtime_error("host_work_size != 0"); ``` 实际运行在最后这个检查处失败。单卡和 64 卡均可复现，矩阵乘法测试正常。 我们检查了以下目录中的库： /public/software/compiler/rocm/dtk-25.04 静态反汇编显示： - cusolverDnXpotrf_bufferSize 转发给 hipsolverDnXpotrf_bufferSize； - 后者返回前，将第 4 个参数 n 写入最后一个参数指向的位置，即看起来执行了：*workspaceInBytesOnHost = n; 想确认的核心问题是：这个返回行为是否符合预期？ 1. CPU 工作区确实需要 n 字节吗，还是这里的大小/单位存在问题？ 2. 如果确实需要，调用方是否应分配 n 字节主机内存，并将它传入 cusolverDnXpotrf？ 3. 该主机内存是否有 pinned memory、对齐或生命周期方面的要求？ 目前只能确认库的非零输出与调用方“必须为零”的假设冲突