Even within the same model quantization and deployment workflow, different J6 computing platforms are not exactly the same in quantization strategy, output precision, input and output handling, or deployment capability.

These differences directly affect your choices in ONNX model quantization, PyTorch model quantization, model compilation, quantized.bc validation, hbm validation, and board-side deployment. If platform differences are not considered at the beginning, it becomes easy to go back and forth later in quantization configuration, result validation, and deployment adaptation.

If you are currently deciding which quantization path or tuning entry point to use, it is better to finish this page first and then continue to the quantization or deployment sections.

#First Identify Which Platform Group You Belong To

In practice, platform differences can be understood in the following two groups first:

• J6E/M/B: mainly fixed-point oriented. Quantization strategy tends to rely more on int8 + int16, and deployment usually requires more attention to high-precision output form, input and output alignment, and fixed-point result validation.

• J6H/P: stronger floating-point capability. It supports more fp16 / fp32-related capability, usually introduces more fp16 configuration in quantization and deployment, and also requires extra attention to multi-core scheduling, L2M, and core binding.

If your current goal is only to verify whether the model can be deployed, start with Quantization Strategy Differences and Input and Output Handling Differences.

If you are already in board-side deployment or performance tuning, continue with Deployment Capability Differences as well.

#Which Decisions Are Affected First

Platform differences usually affect the following decisions first:

So platform differences are not just about different hardware specifications. They directly change the recommended choices in quantization configuration, result validation, and deployment code.

#Quantization Strategy Differences

#How to Understand Platform Differences in ONNX Model Quantization First

If you are working on the ONNX model quantization path, the first platform difference is not that the overall workflow becomes different. The bigger differences appear in precision configuration, output precision, and deployment adaptation.

The optimization workflow for ONNX models is generally consistent across different platforms. The overall process typically begins with the standard PTQ workflow to complete model structure validation, quantization compilation, and basic accuracy verification.

Platform differences mainly continue to affect two things:

1. Whether you need to perform additional higher-precision configuration validation later, such as int8 + fp16, full int16, or partial floating-point configuration.

2. Whether output type, input and output alignment, and board-side deployment adaptation need to change after compilation.

#On J6E/M/B, Where Does the PyTorch Workflow Usually Start

On J6E/M/B, in the Calibration stage before a PyTorch model enters QAT, the quantization strategy is usually centered on int8 + int16 mixed precision.

A common order of use is:

1. First complete PyTorch Calibration or full int8 validation, and confirm that model structure, quantization workflow, and baseline performance do not show obvious problems.

2. If accuracy is still insufficient, use full int16 or a higher int16 ratio to check the accuracy ceiling first.

3. After accuracy reaches the target, gradually reduce the int16 ratio and move back to a more balanced int8 / int16 mixed-precision configuration.

4. If Calibration is already close to floating-point results, then after entering PyTorch QAT, you can first try training with fixed activation scale.

The key idea here is not to raise every operator to higher precision at the beginning, but to identify the accuracy ceiling first, then roll back the high-precision ratio, and finally return to quantized.bc / hbm result validation.

#On J6H/P, Where Does the PyTorch Workflow Usually Start

On J6H/P, because floating-point capability is stronger, the starting point of PyTorch Calibration and later PyTorch QAT is usually different.

A more common starting strategy is:

1. Start with “global fp16 + Conv / Matmul / GEMM operators using int8” as the baseline configuration.

2. If accuracy is still insufficient under this baseline, then raise only local sensitive operators to int16 based on sensitivity results.

3. For a large amount of vector computation, fp16 is often more effective than directly pushing more operators to int16 when the goal is to reduce quantization tuning difficulty.

4. If the value range of some intermediate computation exceeds the representable range of fp16, then switch those parts back to int16 in a targeted way.

The core reason is that on J6H/P, for many vector computations, the speed difference between int16 and fp16 is not large, while fp16 is usually more helpful for reducing quantization difficulty and tuning cost.

#What These Differences Directly Affect

• For ONNX model quantization: the overall PTQ workflow is basically shared across platforms, and the differences mainly appear in later precision configuration checks, output form, and deployment adaptation.

• For PyTorch Calibration: J6E/M/B is more suitable for using full int8 or full int16 first to observe the accuracy boundary, while J6H/P is more suitable for including fp16 in the baseline configuration.

• For PyTorch QAT: J6E/M/B focuses more on finding the accuracy ceiling through int16 and then rolling back, while J6H/P focuses more on using fp16 to reduce quantization difficulty and then adding int16 back only to selected operators.

• For quantization configuration: J6H/P is more likely to use global fp16 settings in the new qconfig templates, while J6E/M/B more often starts from global int8 and then raises sensitive operators to int16.

If the platform and starting strategy are already clear, the next step is to continue with Accuracy Tuning Guide and the corresponding workflow chapters to refine the configuration.

#Output Precision Differences

#Why Can High-precision Output Have Different Forms on Different Platforms

Across different platforms, the high-precision output form of tail GEMM operators may differ, and this directly affects postprocessing code and result validation.

On J6E/M, if tail GEMM operators such as Conv / Linear / Matmul are configured as high-precision outputs, the common form is:

• The operator first outputs int32

• Then a dequantization node converts it to float32

On J6H/P, because the hardware supports floating-point output, the same high-precision output more often appears directly as fp32.

This means that if the deployment code on J6E/M originally assumes a tail int32 result followed by software-side dequantization, then after moving to J6H/P, the software side needs to check again whether the output type has already become floating point.

#Which Stages This Affects

• For PyTorch QAT configuration: you need to confirm whether the goal of high-precision output is to keep an int32 result or to let the model output floating-point values directly.

• For quantized.bc / hbm validation: you need to confirm whether the objects being compared still have the same output type, otherwise output-type changes may be misdiagnosed as accuracy issues.

• For postprocessing and deployment code: if the code assumes a fixed int32 path or a fixed dequantization path, platform migration can break it directly.

If your model tail uses high-precision output, continue with Build QConfig, Accuracy Tuning Guide, and Deployment Consistency Analysis to confirm the output path.

#Input and Output Handling Differences

#Why stride, padding, and aligned byte size Most Often Cause Cross-platform Problems

When moving across platforms, one of the most common issues is not quantization itself, but inconsistent handling of the memory layout of input and output tensors.

The main differences to watch are:

• Different stride alignment requirements for nv12 inputs.

• Different minimum memory units for non-image tensors.

• Possible changes in stride and alignedByteSize for model input and output tensors.

In common deployment scenarios, for example:

• On J6H/P, nv12 input usually needs 64-byte alignment.

• On J6E/M/B, nv12 input usually needs 32-byte alignment.

• For non-image tensors, the minimum allocation unit is commonly 256 bytes on J6H/P, 64 bytes on J6E/M, and 128 bytes on J6B.

These differences eventually appear in node properties such as stride, validShape, and alignedByteSize.

#What Is Recommended in Practice

It is better to follow the two approaches below so that platform-specific logic does not get hard-coded:

1. During compilation, consistently evaluate whether to enable input_no_padding=True and output_no_padding=True.

2. In deployment code, always prepare inputs and parse outputs based on validShape, stride, and alignedByteSize, instead of relying on a fixed stride or fixed memory size written by hand.

If deployment code already parses valid data based on node properties, then even if stride or minimum alignment changes after platform migration, a separate new branch of logic is usually unnecessary.

#What These Differences Affect

• For model compilation: whether input_no_padding and output_no_padding are enabled affects whether manual padding handling is still needed during deployment.

• For quantized.bc / hbm validation: if offline validation and board-side input and output layout are inconsistent, layout issues can easily be mistaken for accuracy problems.

• For board-side deployment: if input and output are still handled according to the old platform stride, padding, or minimum memory unit, migration is much more likely to produce parsing errors or abnormal results.

For the detailed interfaces and handling methods here, continue with Model Inference Application Development Guide, Dynamic Input Introduction, and Alignment Rules.

#pyramid / resizer Input Differences

If model inputs come from pyramid or resizer, platform differences show up earlier in the input path itself rather than later as a model runtime error.

The main points to watch are:

• pyramid input usually has dynamic stride.

• resizer input usually has both dynamic shape and dynamic stride.

• Different platforms have different image-input stride alignment requirements, so during cross-platform migration, both the configuration file and the input preparation logic need to be checked together.

For example, on J6H/P, nv12 input is usually handled with 64-byte alignment, while on J6E/M/B, 32-byte alignment is more common. If a pyramid configuration file on J6E/M/B is written with hard-coded 32-byte alignment, it needs to be checked again after migrating to J6H/P.

For this type of model, besides checking input stride, also confirm the following:

• The input data format and numerical range used in training.

• The preprocessing nodes inserted at deployment time and the input type configuration.

• If fixed scale is used on inputs in PyTorch QAT, whether it still matches the actual input source on the current platform.

These differences directly affect PyTorch Calibration, PyTorch QAT, compilation configuration, and board-side validation results. If the input path is inconsistent, the model may still show accuracy deviation even when the quantization configuration itself is correct.

If your model uses pyramid or resizer input, continue with Model Inference Application Development Guide, Dynamic Input Introduction, and the quantization configuration chapters.

#Deployment Capability Differences

#What Needs Extra Attention on J6H/P

Compared with J6E/M/B, J6H/P also requires extra attention to multi-core scheduling, L2M, and core binding.

These capabilities do not directly change the quantization formula itself, but they clearly affect:

• Model splitting strategy.

• Compilation strategy.

• Runtime scheduling method.

• Board-side latency and bandwidth behavior.

#Multi-core and Core Binding

J6H/P features more BPU cores, providing greater flexibility for application scheduling.

In practice, the more common recommendation is:

• Split models by function or split the pipeline first.

• Bind tasks to specific cores after static scheduling is arranged.

• Minimize dependence on options such as HB_UCP_BPU_CORE_ANY, which may introduce extra latency fluctuation.

The reason is that the model gains are strongly coupled to model structure, and the BPU is exclusive hardware. Once a single inference occupies multiple cores, the scheduling space for other tasks drops significantly.

#L2M

J6H/P supports L2M, which can be used to mitigate DDR bandwidth contention in multi-core concurrent scenarios.

But L2M is not a capability that takes effect automatically. In most cases, two things need to be done together:

1. Specify an appropriate max_l2m_size at compile time.

2. Assign the correct L2M size to the target core through environment variables at runtime.

If L2M is specified during compilation but not enough space is assigned at runtime, inference may fail directly, or the expected bandwidth benefit may not appear.

#What These Differences Affect

• For model compilation: whether to introduce L2M will change the compilation and deployment strategy.

• For board-side deployment: whether to bind cores, whether to enable preemption, and how to allocate L2M all directly affect end-to-end latency stability.

• For performance evaluation: on J6H/P, evaluation is no longer only about single-model latency. Multi-core parallelism, bandwidth contention, and pipeline design also need to be considered together.

If you are already in deployment orchestration or board-side performance optimization, continue with Model Inference Application Development Guide and the corresponding performance evaluation chapters.

#Where to Read Next

After reading this page, if you already know which type of difference matters most to your current task, continue in the following direction:

• If you want to continue with the shared PTQ workflow and tuning method for ONNX model quantization, read Accuracy Tuning Guide and the related ONNX model quantization chapters.

• If you want to continue with the starting strategy for PyTorch Calibration, read Accuracy Tuning Guide and the related PyTorch quantization workflow chapters.

• If you want to continue with precision and output strategy for PyTorch QAT, read Basic Workflow for PyTorch Model Quantization, Build QConfig, and Quantized Awareness Training.

• If you want to troubleshoot inconsistencies between quantized.bc and hbm, or result deviations after platform migration, read Deployment Consistency Analysis.

• If you want to continue with input and output handling, stride, padding, dynamic shape, or board-side inference code, read Model Inference Application Development Guide, Dynamic Input Introduction, and Alignment Rules.