The checkpoint is not the product
A fine-tuned checkpoint carries learned weights, not a complete edge release. The target also needs a tokenizer, processor behavior, vision and language partitions, quantization choices, runtime configuration, input ordering, output limits, and an application that knows how to fail safely.
Treating conversion as an opaque final command hides the most important compatibility questions. We instead define an immutable conversion contract before the candidate is allowed into the toolchain.
Pin and audit the toolchain
Vendor converters and runtimes move quickly. Pin the exact source revision and tool versions, record the expected artifact inventory, review redistribution terms, and audit the source boundary before installing anything into a controlled conversion environment. A newer converter is not silently equivalent to the model-specific path that was reviewed.
If an authorized converter, package, or license is missing, stop. Guessing an undocumented command may produce files, but not a defensible model release.
- Record the base model, adapter, processor, converter, quantizer, and runtime revisions.
- Hash the reviewed conversion wrapper and expected outputs.
- Keep conversion authorization separate from model-selection evidence.
Use calibration data without contaminating evaluation
Quantization calibration should come from the approved training partition and cover the real input modes, positions, lighting, and output tasks. Validation and protected evaluation data must remain excluded, even when using them would make calibration appear more representative.
Multimodal conversion can expose a subtler mismatch: a vendor example may demonstrate one image while the product contract requires an ordered set. The calibration loader and processor path must preserve the production sequence. Flattening the inputs to fit an example changes the model contract rather than validating it.
Verify on the physical accelerator
Desktop parity is useful but insufficient. The converted artifact must run through the exact edge runtime and application boundary. We compare structured behavior, determinism, error handling, memory pressure, restarts, thermal behavior, and sustained operation. Latency is measured, but it is not turned into a claim unless a product requirement was defined in advance.
Hardware validation should use the same bounded input contract and output validator as the workstation path. A response that is numerically plausible but structurally invalid still fails.
Package the whole release boundary
The deployable unit should bind the model to compatible application code, recipe or processor settings, decision policy, provenance, software bill of materials, and release notes. Sign the immutable bundle, verify it again on the device, activate it atomically, run a local health check, and retain the prior known-good release.
This is where accelerator work becomes lifecycle engineering. The value is not merely that an edge chip can run a model; it is that an operator can know which model is active, whether it is healthy, and how to recover without improvising on the device.
Ecosystem note
AXERA’s converter and AX-LLM ecosystems provide the device-specific building blocks. Qwen provides the multimodal base. Our role is to integrate those components under an application-specific contract, validate the exact target behavior, and keep unsupported assumptions outside the release path.