[GH-ISSUE #333] [Feature Request] Make binary artifacts portable on torch and Python versions #165

Open
opened 2026-10-26 21:14:00 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @Harry-Chen on GitHub (May 12, 2026).
Original GitHub issue: https://github.com/deepseek-ai/DeepGEMM/issues/333

Currently this project uses pybind11, which is coupled with both torch and Python ABIs. This leads to a huge amount of release artifacts (M * N, now 86) for each version, and sometimes causes some trouble to downstream projects that want to vendor it (https://github.com/vllm-project/vllm/pull/41516, https://github.com/vllm-project/vllm/issues/41487).

To make it portable, my suggestions are:

  1. Switch to https://github.com/apache/tvm-ffi as a whole. This might not be easy since this project depends on torch a lot. Or,
  2. Provides ABI stability on both torch and Python by migrating to LibTorch Stable ABI and compile the Cpp interface with Py_LIMITED_API. So we can have 1 binary wheel on each architecture that is compatible with Torch 2.9+ and Python 3.8+. Or,
  3. Moving to TORCH_LIBRARY (not using stable ABIs) and opt-inPy_LIMITED_API. Then the wheel still depends on a specific torch version, but a wide range of Python versions from 3.8+. Or,
  4. Replacing pybind11 with nanobind. This requires minimal effort with Python stable ABI support, but only ranging from 3.12+.

I can help with any option if needed.

Originally created by @Harry-Chen on GitHub (May 12, 2026). Original GitHub issue: https://github.com/deepseek-ai/DeepGEMM/issues/333 Currently this project uses pybind11, which is coupled with both torch and Python ABIs. This leads to a huge amount of release artifacts (M * N, now 86) for each version, and sometimes causes some trouble to downstream projects that want to vendor it (https://github.com/vllm-project/vllm/pull/41516, https://github.com/vllm-project/vllm/issues/41487). To make it portable, my suggestions are: 1. Switch to https://github.com/apache/tvm-ffi as a whole. This might not be easy since this project depends on torch a lot. Or, 2. Provides ABI stability on both torch and Python by migrating to [LibTorch Stable ABI](https://docs.pytorch.org/docs/stable/notes/libtorch_stable_abi.html) and compile the Cpp interface with [`Py_LIMITED_API`](https://docs.python.org/3/c-api/stable.html#limited-c-api). So we can have 1 binary wheel on each architecture that is compatible with Torch 2.9+ and Python 3.8+. Or, 3. Moving to `TORCH_LIBRARY` (not using stable ABIs) and opt-in`Py_LIMITED_API`. Then the wheel still depends on a specific torch version, but a wide range of Python versions from 3.8+. Or, 4. Replacing `pybind11` with `nanobind`. This requires minimal effort with Python stable ABI support, but only ranging from 3.12+. I can help with any option if needed.
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/DeepGEMM#165
No description provided.