finds.dev← search

// the find

huggingface/optimum

★ 3,416 · Python · Apache-2.0 · updated Jun 2026

🚀 Accelerate inference and training of 🤗 Transformers, Diffusers, TIMM and Sentence Transformers with easy to use hardware optimization tools

Optimum is HuggingFace's hardware optimization layer for Transformers, Diffusers, and related libraries. It handles export to ONNX/TFLite, quantization (GPTQ, Quanto), and backend-specific inference on Intel, AWS, NVIDIA, and AMD hardware. If you're deploying HF models and need something faster than vanilla PyTorch, this is the first place to look.

1. Backend coverage is real and maintained — ONNX Runtime, OpenVINO, TensorRT-LLM, Neuron (AWS Inferentia/Trainium), and Intel Gaudi all have active sub-packages with CI workflows, not just stubs. 2. The FX parallelization module (`optimum/fx/parallelization/`) does tensor parallelism through graph-level transformation rather than requiring model rewrites — useful if you're stuck with a model you can't modify. 3. GPTQ quantization is self-contained with its own calibration data pipeline and eval loop, not just a thin wrapper around another library. 4. The exporter's task registry (`optimum/exporters/tasks.py`) maps HF task names to model classes automatically, so you don't need to know the internal class hierarchy to export.

1. The repo is increasingly a thin coordination layer — ONNX support was just spun out to `optimum-onnx`, Intel to `optimum-intel`, Neuron to `optimum-neuron`. What remains in the main repo is shrinking, and the documentation still points everywhere, making it hard to know what version of what package you actually need. 2. The `--upgrade-strategy eager` requirement is a red flag for production environments — installing this in a locked dependency tree will cause pain. 3. Torch FX-based features are fragile by nature: symbolic tracing breaks on dynamic control flow, and the parallelization passes have no obvious fallback when they fail mid-graph. 4. 3.4k stars for something this foundational is low, which suggests most users go straight to the hardware-specific sub-packages and the core repo is underdiscovered or underdocumented at the getting-started level.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →