Model Porting
A port is done when parity says so.
Porting a model off MXNet is not a file-format exercise. Weight conversion tools will happily produce a PyTorch or ONNX artifact that loads, runs, and returns numbers — slightly wrong numbers, for reasons that don't surface until someone compares outputs properly. Our porting practice is built around making that comparison the definition of done.
The porting path
- Target selection. PyTorch is the default target for models that will keep evolving; ONNX-first makes sense for frozen inference workloads where runtime portability matters more than a training story. We recommend per model, not per estate.
- Conversion or re-implementation. Where the architecture maps cleanly, we convert weights directly (Gluon block to PyTorch module, or export through ONNX). Where it doesn't — custom operators, hybridized control flow, MXNet-specific layer semantics — we re-implement the architecture in the target framework and transfer weights layer by layer.
- Numerical-parity testing. Every port gets a parity harness: the same inputs through both models, outputs compared at defined tolerances, across a sample that covers the input distribution's edges — not just a smoke-test batch. Layer-wise comparison when end-to-end parity fails, so divergence gets localized instead of guessed at.
- Retraining when conversion won't hold. Some models don't convert faithfully — BatchNorm semantics, padding differences, or custom ops with no equivalent. We say so early, estimate the retraining effort against your original data and pipeline, and validate the retrained model against the production model's evaluation metrics rather than pretending parity where there is none.
What "done" means
A ported model ships with:
- the parity harness and its results, reproducible in your CI;
- documented tolerances and any known, accepted divergences with their measured impact;
- an inference benchmark against the MXNet original on your target hardware;
- training code in the target framework (for PyTorch targets), so the model is maintainable again — which is the point of the whole exercise.
What we don't do
We don't declare victory on "it compiles," and we don't hide retraining costs inside an optimistic conversion estimate. If a model is going to need retraining, you'll know at assessment or in the first days of porting — not after the budget is spent.
Porting is hourly time and materials, staffed with engineers fluent in both MXNet/Gluon idioms and the target framework. Tell us about your models.