Model Compression Toolkit: hardware-aware quantization for PyTorch and Keras models
Model Compression Toolkit (MCT) is an open source project for neural network model optimization under efficient, constrained hardware. This project provides researchers, developers, and engineers advanced quantization and compression tools for deploying state-of-the-art neural networks.
At a glance
- What is it?
- MCT is Sony Semiconductor Solutions' Apache-2.0 Python package for post-training quantization, gradient-based fine-tuning and quantization-aware training of pre-trained float models. Its distinguishing feature is a target-platform capability file that constrains the search to what the intended hardware can actually execute.
- Who is it for?
- Adopt MCT if you already have a trained PyTorch or Keras model and a defined target device, and you are willing to spend the time producing a target platform capability file or checking whether one already exists for your hardware. Do not adopt it if you need training from scratch, if your deployment target is unconstrained server hardware where float inference is acceptable, or if you cannot supply a representative dataset.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem MCT addresses: float models that will not fit or run on the target
A trained network that runs correctly in PyTorch or Keras is not automatically deployable. Edge accelerators frequently implement only a subset of integer arithmetic, and a model quantized to 8-bit weights and activations without regard for the accelerator's constraints can end up with layers the hardware cannot execute, or with accuracy that falls below the product requirement. MCT targets that gap. The README states the required input plainly: a pre-trained floating point model in PyTorch or Keras. The representative dataset used for calibration is optional, because MCT can generate one through its Data Generation capability. The intended audience is stated in the project description as researchers, developers and engineers deploying neural networks under constrained hardware, and the topic list names edge-ai, ptq, qat and network-quantization. This is not a training framework and not a runtime. It sits between an existing trained model and a deployment toolchain.
Three quantization flows with very different cost profiles
The README lays out three methods in a comparison table, and the cost column is the most useful part of it. Post Training Quantization is described as low complexity and low computational cost, roughly 1 to 10 CPU minutes, with separate PyTorch and Keras APIs. GPTQ, described as parameter fine-tuning using gradients, is moderate complexity and moderate cost, roughly 1 to 3 GPU hours, again with PyTorch and Keras APIs. QAT, quantization aware training, is high complexity and high cost, roughly 12 to 36 GPU hours, and the table links only a Keras tutorial for it. That progression is the decision axis: PTQ first, because it is cheap enough to run repeatedly while tuning; GPTQ when PTQ accuracy is not sufficient and you have GPU hours; QAT when you need the last increment and can afford a full retraining cycle. The absence of a PyTorch QAT tutorial link in that table is worth noting if PyTorch is your framework.
Target platform capabilities: the constraint that shapes the search
The mechanism that separates MCT from a generic quantizer is described in the README as hardware-aware quantization, with a link to a dedicated target_platform_capabilities README in the repository. Quantization core, in the README's wording, uses various algorithms and hyper-parameters for optimal hardware-aware quantization results. The practical consequence is that the bit-width search is bounded by what the target device supports rather than by what minimizes error in the abstract. Mixed-precision search, one of the listed core features, assigns a bit-width per layer for weights and activations. Without a capability description for your accelerator, that search has no ground truth to respect, so the output may be numerically better and physically unrunnable. The repository also lists graph optimizations, described as transforming the model to be best fitted for the quantization process, and quantization parameter search. These are the pieces that run before and around the bit-width decision.
Getting it installed and the version constraints you inherit
Installation is a single command in a Python 3.10 or newer environment: pip install model-compression-toolkit. The README points to INSTALLATION.md for a source build. The version badges are the part to read carefully. PyTorch is listed as 2.3, 2.4, 2.5 or 2.6; TensorFlow as 2.14 or 2.15; Python as 3.10, 3.11 or 3.12. Those are narrow windows, and they are the first thing to check against your existing training environment, because installing MCT into an environment pinned to an older PyTorch means either upgrading PyTorch or building MCT from source. The README repeats the input requirement in bold: you need a pre-trained floating point model. There is no path here from raw data to a model. The tutorials directory contains notebooks for both Keras and PyTorch covering the compression techniques, and the README links Colab versions of several of them, including a PyTorch mixed-precision PTQ notebook and MobileNet GPTQ notebooks for both frameworks.
Where MCT is the wrong tool
The clearest limitation is stated by the project itself: a pre-trained floating point model is a required input. If your model does not exist yet, or exists only in a form MCT does not accept, the toolkit has nothing to operate on. The second limitation follows from the first. Quantization cannot repair a model that was already too inaccurate; it can only trade accuracy for size and speed, and the PTQ flow will surface that trade rather than resolve it. Third, the hardware-aware design is only as good as the capability description you feed it. If no capability file exists for your accelerator, you are either writing one or falling back to a generic configuration, and in the latter case you lose the property that motivated using MCT in the first place. Fourth, the framework version windows are narrow enough that MCT may dictate the rest of your environment rather than fit into it. Finally, the cost figures in the README are order-of-magnitude guidance for the flows, not a prediction for your model; a large backbone will sit at the top of those ranges or beyond them.
Compared with a general-purpose quantization library
The obvious alternative category is a general quantization toolkit that ships with the training framework or a vendor-neutral compression library, where you specify bit-widths and calibration directly and the tool applies them. The difference in approach is where the constraint lives. In a generic flow, you choose a configuration and then discover at deployment whether the target executes it. In MCT, the target's capabilities are an input to the search, so the bit-width assignment is produced under that constraint from the start. That is a real architectural difference, and it is also the source of MCT's main adoption cost: you need a target description before you get a result. If your deployment target is a server GPU running float or a runtime that accepts a wide range of integer configurations, the hardware-aware layer adds work without adding much benefit, and a generic quantizer is the better fit. If your target is a fixed-function edge accelerator with a documented operator and bit-width set, the constraint-first approach is the reason to pick MCT.
Maintenance, release cadence and licence
The repository is not archived, and the release history shows a steady cadence: v2.5.0 in December 2025, v2.5.1 in January 2026, v2.6.0 in March 2026, with the last push to main in September 2026. Three releases in roughly three months suggests active maintenance rather than a frozen snapshot. The upgrade cost is dominated by the framework version windows rather than by MCT's own API surface: because the supported PyTorch and TensorFlow ranges are explicit and narrow, each MCT upgrade is also a decision about your training stack. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual obligations around preserving notices and stating changes. That is a summary of the licence identifier, not legal advice; read LICENSE.md in the repository and get your own counsel for a commercial deployment. Note that the package name on PyPI is model-compression-toolkit while the repository is mct-model-optimization, so search results and import paths will not match the project name you started from.
Editorial conclusion
Adopt MCT if you already have a trained PyTorch or Keras model and a defined target device, and you are willing to spend the time producing a target platform capability file or checking whether one already exists for your hardware. Do not adopt it if you need training from scratch, if your deployment target is unconstrained server hardware where float inference is acceptable, or if you cannot supply a representative dataset. Before committing, verify three things: that a capability file exists for your accelerator, that the bit-widths it allows are the ones your runtime supports, and that the PTQ accuracy on your own model and calibration set is acceptable, since MCT requires a pre-trained floating point model as input and cannot recover accuracy you never had.
Community notes