-
Notifications
You must be signed in to change notification settings - Fork 678
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PyTorch Custom Operator Integration #1544
Conversation
The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update. |
…/bitsandbytes into customop-refactoring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The custom_ops as well as clean up parts are looking really excellent. Thanks for this impactful work!
As we said, let's do separate PRs for
- torch.compile
- about fixing avoidable issues with graph breaks
- fix issues around torch.compile of quantize functions
- deprecate:
- TestSpMMFunctional tests and mark related functions with @deprecated
- SwitchBackLinear and communicate on issues / repo of open_clip
- fix AttributeError: module 'bitsandbytes.functional' has no attribute 'double_quant'
Overview
This PR introduces the initial scaffolding to integrate PyTorch Custom Operators as the primary mechanism for dispatching to device-specific operator implementation.
As outlined in the related RFC #1545, the intent is that this will supersede the previous backend registration interface that was developed on the
multi-backend-refactor
branch. The baseline CUDA operators are established in this PR, and the implementation for additional backends is to be ported over to this new interface.Why Custom Ops?
torch.library
allows us to take advantage of the existing device dispatch mechanisms in PyTorch.torch.compile
support.Operator Definitions
We broadly categorize operator functionality into three feature groups, though there can be some overlap.
LLM.int8()
Inference requirements
int8_vectorwise_quant(A: Tensor, threshold: float = 0.0) -> (Tensor, Tensor, Tensor?)
int8_scaled_mm(A: Tensor, B: Tensor, row_stats: Tensor, col_stats: Tensor, bias: Tensor?, dtype=torch.float16)
int8_linear_matmul(A: Tensor, B: Tensor) -> Tensor
A @ B.T
int8_mm_dequant(A: Tensor, row_stats: Tensor, col_stats: Tensor, dtype=torch.float16, bias: Tensor?) -> Tensor
torch.float16
for the current CUDA implementation.Optional
int8_vectorwise_dequant(A: Tensor, stats: Tensor)
int8_vectorwise_quant
.int8_double_quant(A: Tensor, threshold: float = 0.0)
int8_vectorwise_quant
.NF4/FP4
Minimal requirements
dequantize_4bit(A: Tensor, absmax: Tensor, blocksize: int, quant_type: Literal["nf4" | "fp4"], shape: int[], dtype) -> Tensor
bitsandbytes.functional.dequantize_4bit
, this operator does not dequantize theabsmax
tensor. If utilized,dequantize_blockwise
must be performed first.quantize_4bit(A: Tensor, blocksize: int, quant_type: Literal["nf4" | "fp4"], quant_storage=torch.uint8) -> (Tensor, Tensor)
bitsandbytes.functional.quantize_4bit
, this operator does not quantize theabsmax
tensor. If utilized,quantize_blockwise
must be performed first.Double quantization (aka
compressed_statistics
ornested
)dequantize_blockwise(A: Tensor, absmax: Tensor, code: Tensor, blocksize: int, dtype) -> Tensor
quantize_blockwise
quantize_blockwise(A: Tensor, code: Tensor, blocksize: int) -> (Tensor, Tensor)
code
.blocksize
will typically be 256 for usage with NF4/FP4 and optimizers.Optional
gemv_4bit
Optimizers
Optimizer functionality will be implemented to support the custom operators in a future update.