Become ABI Stable with LibTorch 2.11+ - #193
Conversation
3726f95 to
3911d00
Compare
| static inline PtrT* get_tensor_ptr(const at::Tensor& tensor) { | ||
| if (tensor.has_storage()) { | ||
| static inline PtrT* get_tensor_ptr(const torch::stable::Tensor& tensor) { | ||
| if (tensor.defined()) { |
There was a problem hiding this comment.
This is a weaker check, but as these kernels are registered to the CUDA backend key, the inputs will either be CUDA storage-backed tensors or null tensors so this check is sufficient.
1638811 to
a57563e
Compare
bvolpato
left a comment
There was a problem hiding this comment.
ABI work looks solid. I built the abi3 wheel after one CUDA 13 workaround, got zero unstable symbols from torch-abi-audit, and loaded the same artifact with Torch 2.10, 2.11, and 2.13.
Could we fix two install details before this lands? New README commands point to janeyx99/FlashMLA-ABI-Stable, so upstream users would install a different repository. Documented build also fails on CUDA 13.2 with cuda/std/utility missing. Adding /usr/local/cuda/targets/x86_64-linux/include/cccl made it build. Could setup add toolkit CCCL include path for each architecture, or should supported-toolkit text be narrower?
Fixes #180
The first commit migrates the library from pybind -> TORCH_LIBRARY. This allows the library to be CPython agnostic, meaning you can build one wheel for multiple python versions (3.10+ here). Then, the second commit does the mechanical work of migrating APIs to the stable APIs.
After the first commit, there are 70 unstable APIs used by the .so:
After the second, there are none!!
Test Plan
After commit 1:
After commit 2 (showing that perf diff is insignificant):
After both commits (ran twice):
test_fmha_sm100.py also had no failures:
Details