HarmonyOS 6.0 CANN Kit Dump Explained: AI Model Accuracy Debugging and Tensor Export on Device

HarmonyOS 6.0 adds Dump observability to CANN Kit, allowing developers to export layer-by-layer model outputs during on-device inference. This solves one of the hardest debugging problems in edge AI: when a model runs successfully but produces inaccurate results. Together with Profiling, Dump completes a two-dimensional debugging workflow for both performance and accuracy. Keywords: CANN Kit, Dump, HarmonyOS.

Technical specifications are easy to scan

Parameter	Description
Platform	HarmonyOS 6.0.0(20)+
Core capability	AI model Dump observability data export
Primary languages	C / C++
Runtime interfaces	CANN Kit, NN Runtime
Configuration enum	HiAI_OmType
Key function	HMS_HiAIOptions_SetOmOptions
Output location	Related directories under /data/local/tmp/
Companion capabilities	Profiling, offline OM model loading
Star count	Not provided in the original article
Core dependencies	neural_network_core.h, CANNKit/hiai_options.h

AI Visual Insight: The image shows a cover screenshot for a technical article centered on the HarmonyOS 6.0 CANN Kit Dump capability. Its key visual signals point to three themes: on-device AI debugging, layer-by-layer model outputs, and observability data extraction. It works well as an entry visual for understanding Dump-based accuracy troubleshooting.

Dump observability closes a critical gap in on-device AI accuracy debugging

The hardest problem in edge model deployment is often not whether the model can execute, but whether you can explain output deviations. Logs can tell you whether the pipeline succeeded, but they cannot show whether tensors have drifted at a specific layer.

With Dump mode added to CANN Kit in HarmonyOS 6.0, developers can preserve intermediate outputs during inference and turn black-box execution into a transparent, layer-by-layer comparison process. This is especially important when diagnosing quantization error, operator compatibility deviations, and input preprocessing issues.

Profiling and Dump have clearly separated responsibilities

Profiling focuses on performance and answers, “Why is it slow?” Dump focuses on accuracy and answers, “Why is it inaccurate?” They share the same configuration framework, but they serve two completely different debugging paths.

Mode	Problem it solves	Output
HiAI_OM_TYPE_GENERAL	Normal execution	No observability data collected
HiAI_OM_TYPE_PROFILING	Performance bottlenecks	Operator or full-network timing
HiAI_OM_TYPE_DUMP	Accuracy anomalies	Layer-level tensor outputs
HiAI_OM_TYPE_PROFILING_DUMP	Combined performance and accuracy analysis	Timing plus intermediate results

This table shows that HiAI_OmType is effectively a unified entry point for observability configuration.

Dump data generation depends on runtime instrumentation and file output

Dump data is not generated directly during model conversion. Instead, the runtime exports output tensors after operators complete execution when the OM model actually runs. In other words, the configuration phase only declares the strategy, while the inference phase is when the files are actually produced.

A complete workflow usually has three steps: first convert the source model to OM, then configure HiAI_OmType and the output directory in the application, and finally run inference and read the exported binary results from the device directory.

The core Dump APIs are concentrated in the HiAI options object

#include "neural_network_runtime/neural_network_core.h"
#include "CANNKit/hiai_options.h"

// Include NN Runtime and CANN Kit headers for subsequent observability configuration

This code prepares the required headers for integrating the Dump capability.

HiAI_Options *options = HMS_HiAIOptions_Create();
if (options == NULL) {
    // Failed to create the options object; terminate the flow immediately
    return;
}

OH_NN_ReturnCode ret = HMS_HiAIOptions_SetOmOptions(
    options,
    HiAI_OM_TYPE_DUMP,              // Enable Dump mode
    "/data/local/tmp/dump_data"    // Specify the Dump output directory
);

if (ret != OH_NN_SUCCESS) {
    // Release resources on configuration failure to avoid handle leaks
    HMS_HiAIOptions_Destroy(options);
    return;
}

This code creates the configuration object and explicitly enables Dump mode with an output path.

You must explicitly pass the Dump configuration object during model loading

Setting options alone is not enough. The key step is passing it into the offline model compilation and construction flow. Otherwise, the runtime will not detect the Dump strategy, and no intermediate results will be exported.

OH_NNCompilation *compilation = NULL;
ret = OH_NNCompilation_ConstructWithOfflineModelBuffer(
    modelBuffer,
    modelBufferSize,
    OH_NN_DEVICE_TYPE_NPU,
    options,          // Critical: pass the Dump configuration into the compilation object
    &compilation
);

if (ret != OH_NN_SUCCESS) {
    // Compilation instance construction failed; add cleanup logic based on your project standards
    return;
}

ret = OH_NNCompilation_Build(compilation); // The build stage determines runtime behavior

This code binds the Dump options to the model compilation instance so they take effect during inference.

Resource cleanup and debug switches must be managed in pairs

Dump mode introduces additional I/O overhead. If you accidentally leave it enabled in a release build, it can slow down inference and increase storage usage. For that reason, it is best to wire it into debug build configurations instead of keeping it in long-running production logic.

OH_NNCompilation_Destroy(compilation);   // Release the compilation instance
HMS_HiAIOptions_Destroy(options);        // Release the HiAI configuration object

This code cleans up the compilation and observability configuration resources to avoid memory and handle leaks.

The most common integration issues are path configuration, input order, and permissions

First, model files, input files, and the Dump output directory are usually placed under conventional paths in /data/local/tmp/. An incorrect path is the most common reason no Dump files are generated.

Second, multi-input models must strictly match the expected input order. It is a good practice to inspect the Inputs ordering in Netron first, then feed the binary files in exactly the same order. Otherwise, layer-by-layer error can start propagating from the very first layer.

Dump file export and parsing must be combined with tensor metadata

The Dump files retrieved from the device are usually binary tensor data, which is not human-readable on its own. To parse it, you at least need the shape, dtype, and layer name mapping.

hdc file recv /data/local/tmp/dump_data/ ./dump_analysis/
# Pull Dump results from the device into a local analysis directory

This command synchronizes the Dump files exported on the device to the PC side.

On the PC, there are three common approaches: deserialize the data with the CANN toolchain, write a NumPy script to reconstruct tensors, or compare layer by layer against ONNX or a CPU baseline using MSE. The most efficient debugging method is not to inspect only the final output, but to identify the first layer where divergence begins.

The current capability has clear version boundaries and usage constraints

The Dump feature is not available on all versions. The current requirement is a HarmonyOS 6.0.0(20)+ device, along with DevEco Studio 6.0.0 Release and the matching SDK. In lower-version environments, the code may still compile, but the actual capability may not exist.

In addition, Dump is suitable only for development and debugging. It introduces file write overhead and affects real-time inference performance, so it should not remain enabled continuously in production releases. Production builds should revert to HiAI_OM_TYPE_GENERAL.

FAQ: The 3 questions developers care about most

Q1: Do I have to choose between Dump and Profiling?

A: No. You can enable both at the same time with HiAI_OM_TYPE_PROFILING_DUMP. They share the same configuration entry point, but produce separate performance and accuracy data.

Q2: Why are no files generated even though Dump mode is enabled?

A: Check these three items first: whether the output directory is valid, whether options was passed during model loading, and whether the application has permission to access the target path.

Q3: Why can’t I directly analyze the Dump files after retrieving them?

A: Because the files are typically raw binary tensor streams. You must combine them with tensor shapes, data types, and layer mappings before you can reconstruct comparable intermediate results.

CANN Kit is evolving from an inference runtime into a complete observability platform

The significance of this Dump capability is not just that it adds another debugging interface. More importantly, it gives HarmonyOS on-device AI a dual closed loop for both performance analysis and accuracy analysis. For model migration, quantization validation, and device-cloud consistency troubleshooting, it is high-value infrastructure.

If Profiling tells developers where the model is slow, Dump tells them where the model is wrong. Only by combining both can teams build a truly engineering-grade optimization workflow for on-device AI.

Core summary captures the practical value of the feature

This article systematically reconstructs the new Dump observability capability added to CANN Kit in HarmonyOS 6.0. It focuses on the division of responsibilities between Dump and Profiling, HiAI_OmType configuration, the model loading integration flow, Dump data export and parsing methods, and version and permission constraints during debugging.