```{toctree}
:hidden:
:maxdepth: 2
:caption: Getting Started
Overview <self>
Installation and Environment Check <installation.md>
First Compile <first_compile.md>
```

```{toctree}
:hidden:
:maxdepth: 2
:caption: Compile Workflow
Basic Compile Flow <basic_compile_flow.md>
Compile Configuration <compile_configuration.md>
Model Parsing <model_parsing.md>
Model Quantization <model_quantization.md>
```

```{toctree}
:hidden:
:maxdepth: 2
:caption: Model Guides
Vision <vision.md>
Transformer <transformer.md>
```

```{toctree}
:hidden:
:maxdepth: 2
:caption: Troubleshooting & Reference
Troubleshooting <troubleshooting.md>
CPU Offloading <cpu_offloading.md>
Reference <reference.md>
API <../doxygen/html_en/group__API>
Classes <../doxygen/html_en/annotated_classes>
Files <../doxygen/html_en/files>
Changelog <CHANGELOG.md>
License <license.md>
```

# Overview

qb Compiler converts a trained original model into an MXQ artifact that can run on a Mobilint NPU. The original model can come from ONNX, PyTorch, HuggingFace transformers, TensorFlow, or TFLite.

The manual uses the same conversion path throughout:

```text
Original model -> MBLT -> MXQ
```

MBLT is Mobilint's parsed model format. It contains the model graph and weights after qb Compiler has read the source framework format. MXQ is the deployable artifact produced from MBLT for a specific Mobilint target device.

![SDK Components](../res/image/qbcompiler.jpg "SDK Components"){width="60%" align="center"}

## What Is qb Compiler?

qb Compiler takes the model that was trained or exported on a host machine and prepares it for the Mobilint runtime stack. The usual inputs are:

- an original model file or Python model object
- model input information, such as shapes or a `feed_dict` for PyTorch-style models
- calibration data that represents real inference inputs
- a target device string
- optional compile configuration or preset selection

The main output is an `.mxq` file. For staged workflows, qb Compiler can also write an `.mblt` file so you can inspect the parsed model before generating MXQ.

## Original Model -> MBLT -> MXQ

The pipeline has two conceptual stages.

First, `parse` converts the original model into MBLT:

```text
ONNX / PyTorch / HuggingFace transformers / TensorFlow / TFLite -> MBLT
```

Second, `quantize` converts MBLT into MXQ:

```text
MBLT -> MXQ
```

The command name `quantize` is broader than calibration alone. In qb Compiler documentation it means the MBLT-to-MXQ stage, including calibration, quantization decisions, target-specific compilation, and generation of the machine-instruction package needed by the runtime.

For the common case, `compile` runs both stages end to end:

```text
Original model -> MBLT -> MXQ
```

Use end-to-end `compile` when you already know the model and target. Use separate `parse` and `quantize` steps when you want to inspect the MBLT in Netron, debug unsupported layers, reuse the parsed model, or compare several quantization/configuration choices from the same MBLT.

## Supported Input Formats

qb Compiler supports these public backend names:

- `onnx` for ONNX models
- `torch` for PyTorch models and HuggingFace/transformers flows
- `torchscript` for TorchScript models
- `tf` for TensorFlow and Keras saved models
- `tflite` for TensorFlow Lite models

ONNX and PyTorch are the recommended input formats for new compile flows. Use TensorFlow, TFLite, or TorchScript when those formats are already part of the model export path or deployment workflow.

HuggingFace LLM compilation is described as a `backend="torch"` workflow because the compiler receives a PyTorch/transformers model path or object rather than a separate HuggingFace backend.

## Supported NPUs

The target device string selects the target device to compile for. Use one of:

| NPU Chip | Target device string |
| --- | --- |
| `ARIES` | `aries-rb` |
| `REGULUS` | `regulus-ra`, `regulus-rb` |

ARIES and REGULUS are NPU Chips. `aries-rb`, `regulus-ra`, and `regulus-rb` are target device strings passed to the CLI and Python API. Use the exact target device value, not the NPU Chip name alone.

## Common Artifacts

The most common artifacts are:

- `.mxq`: deployable compiled model for the selected target device
- `.mblt`: parsed model graph and weights, useful for inspection and staged compilation
- calibration data directory: preprocessed sample tensors used during MXQ generation
- calibration metadata `.txt`: a list of calibration sample paths generated by the calibration helpers
- compile config `.json` or `.yaml`: optional settings used by CLI or Python workflows