Huawei Ascend AI Computing Platform and CANN
Domain scope
This domain tests the Ascend software stack: the Da Vinci AI Core, CANN components, AscendCL runtime APIs, and ATC offline-model conversion. You should know which tool performs conversion, which API loads a model, and which preprocessing block handles image normalization.
Core rules and concepts
- Ascend 310 targets inference; Ascend 910 targets training. The Da Vinci AI Core includes Cube units for matrix multiply, Vector units for elementwise work, and Scalar units for control.
- CANN provides the graph compiler, runtime, operator libraries, HCCL collective communication, DVPP vision preprocessing, and AIPP.
- ATC converts a trained model (for example ONNX with --framework=5) into an offline .om model for a specific --soc_version.
- AscendCL handles device/context/stream setup, memory allocation, model load, input/output datasets, and execution.
- AIPP can perform crop, resize, color-space conversion, and mean/scale normalization on the device; DVPP handles decode and basic image transforms.
Worked example
A team exports an ONNX image classifier and converts it with: atc --model=cls.onnx --framework=5 --output=cls --soc_version=Ascend310 --input_format=NCHW --input_shape="input:1,3,224,224". The resulting cls.om is loaded with AscendCL's model-load API, input buffers are filled from the preprocessed image, and execution is asynchronous on a stream. If the original model expects RGB mean [123.675,116.28,103.53] and scale [58.395,57.12,57.375], those values must be applied consistently-either in host preprocessing or in AIPP, not both.
Traps that cost marks
- Converting for the wrong soc_version or with a different input layout than the trained model.
- Assuming dynamic batch is free; it must be declared and may require multiple profiles.
- Double-normalizing when AIPP and host code both apply mean/scale.
- Treating .om as portable across Ascend chip types.