當您在板端驗證.bin或在python端評測quantized.onnx發現精度不及預期時（精度損失超過4%），可參照本文第二章所述步驟排查問題。若精度損失較小，則可參考本文第三章嘗試精度調優。

在開始定位模型精度問題之前，我們建議您可以先瀏覽一下模型轉換的內部過程解讀，這將有助于您理解并排查數據和yaml文件準備過程中的問題。

1 內部過程詳解

模型轉換完成浮點模型到地平線混合異構模型的轉換。為了使得這個異構模型能快速高效地在嵌入式端運行，模型轉換重點在解決 輸入數據處理 和 模型優化編譯 兩個問題。

1.1 輸入數據處理

輸入數據處理方面我們為模型插入了預處理節點，幫助實現硬件通路數據和模型輸入數據的轉換對齊。因為地平線的邊緣AI計算平臺會為某些特定類型的輸入通路提供硬件級的支撐方案， 但是這些方案的輸出不一定符合模型輸入的要求。 例如視頻通路方面就有視頻處理子系統，為采集提供圖像裁剪、縮放和其他圖像質量優化功能，這些子系統的輸出往往是yuv420格式圖像， 而我們的算法模型往往是基于bgr/rgb等一般常用圖像格式訓練得到的。為減少客戶板端部署時的工作量，我們將幾種常見的圖像格式轉換以及常用的圖像標準化操作固化進了模型當中，其表現為模型input節點之后插入了預處理節點HzPreprocess（您可以使用開源工具 Netron 觀察轉換過程中的中間產物）。
轉換過程中，工具會根據yaml文件中 input_type_rt 和 input_type_train 指定的數據格式自動向HzPreprocess節點中添加數據格式轉換的操作。根據實際生產經驗， 并不是任意type組合都是需要的，為避免誤用，我們只開放了一些固定的type組合如下表所示。

表格中第一行是 input_type_rt 中支持的類型，第一列是 input_type_train 支持的類型， 其中的 Y/N 表示是否支持相應的 input_type_rt 到 input_type_train 的轉換。 在.bin模型部署階段，您只需要關注input_type_rt的數據格式。 以下是對 input_type_rt每種格式的說明：

(1) rgb、bgr和gray都是比較常見的圖像數據，注意每個數值都采用UINT8表示。

(2) yuv444是一種常見的圖像格式，注意每個數值都采用UINT8表示。

(3) nv12是常見的yuv420圖像數據，每個數值都采用UINT8表示。

(4) nv12有個比較特別的情況是 input_space_and_range 設置 bt601_video （配置參數介紹可參考《horizon_ai_toolchain_user_guide》3.4. 轉換模型 章節），較于常規nv12情況，它的數值范圍由[0,255]變成了[16,235]， 每個數值仍然采用UINT8表示。

(5) featuremap適用于以上列舉格式不滿足您需求的情況，此type只要求您的數據是四維的，每個數值采用float32表示。 例如雷達和語音等模型處理就常用這個格式。
圖像數據標準化操作則是根據yaml文件中的norm_type、mean_value、scale_value參數，判斷是否向HzPreprocess節點中添加mean/scale操作。

1.2 模型優化編譯

模型優化編譯方面則完成了模型解析、模型優化、模型校準與量化、模型編譯等幾個重要過程。其內部工作過程及輸入數據準備示例如下圖所示。
暫時無法在文檔外展示此內容

*最右邊一列為各階段圖像輸入類模型預處理示例，主要差異在于normalize操作以及圖像格式的轉換。若為featuremap輸入，則預處理不存在上述差異。

模型解析階段 對于Caffe浮點模型會完成到ONNX浮點模型的轉換。 在原始浮點模型上會根據轉換配置中的配置參數決定是否加入HzPreprocess節點，此階段產出original_float_model.onnx。 這個ONNX模型計算精度仍然是float32，和原始浮點模型輸出結果一致。
理想狀態下，這個HzPreprocess節點應該完成 input_type_rt 到 input_type_train 的完整轉換， 實際情況是整個type轉換過程會配合地平線AI芯片硬件完成，ONNX模型里面并沒有包含硬件轉換的部分。 因此ONNX的真實輸入類型會使用一種中間類型，這種中間類型就是硬件對 input_type_rt 的處理結果類型， 數據layout(NCHW/NHWC)會保持和原始浮點模型的輸入layout一致。 每種 input_type_rt 都有特定的對應中間類型，如下表：

表格中第一行是 input_type_rt 指定的數據類型，第二行是特定 input_type_rt 對應的中間類型， 這個中間類型就是original_float_model.onnx的輸入類型。每個類型解釋如下：

(1) yuv444_128/RGB_128/BGR_128/GRAY_128為對應input_type_rt減去128的結果。

(2) featuremap 是一個四維張量數據，每個數值采用float32表示。

模型優化階段 實現模型的一些適用于地平線平臺的算子優化策略，例如BN融合到Conv等。 此階段的產出是optimized_float_model.onnx，這個ONNX模型的計算精度仍然是float32，經過優化后不會影響模型的計算結果。 模型的輸入數據要求還是與前面的original_float_model一致。

模型校準階段 會使用您提供的校準數據來計算必要的量化閾值參數，這些參數會直接輸入到量化階段，不會產生新的模型狀態。

模型量化階段 使用校準得到的參數完成模型量化，此階段的產出是quantized_model.onnx。 這個模型的輸入計算精度已經是int8，使用這個模型可以評估到模型量化帶來的精度損失情況。 這個模型要求輸入的基本數據格式仍然與 original_float_model 一樣，不過layout和數值表示已經發生了變化， 整體較于 original_float_model 輸入的變化情況描述如下：
(1) 數據layout均使用NHWC。

(2) 當 input_type_rt 的取值為非 featuremap 時，則輸入的數據類型均使用int8， 反之， 當 input_type_rt 取值為 featuremap 時，則輸入的數據類型為float32。

模型編譯階段 會使用地平線模型編譯器，將量化模型轉換為地平線平臺支持的計算指令和數據， 這個階段的產出是***.bin模型，這個bin模型是后續將在地平線邊緣嵌入式平臺運行的模型，也就是模型轉換的最終產出結果。

2 精度問題定位建議流程

精度問題定位流程主要包括如下三個部分：

1）驗證Caffe/Onnx的有效性，確保其單張推理結果與原始浮點模型保持一致；
2）通過對比original_float_model.onnx與原始浮點模型的單張推理結果，確保PC端推理代碼的正確性；
3）通過比對quantized_model.onnx與.bin的單張推理結果，確保板端代碼與PC端代碼的一致性，以及模型集成（將quantized_model.onnx編譯為.bin）的過程沒有引入誤差。

2.1 驗證原始Caffe/Onnx模型有效性

這一步為了排查拿錯模型，或是導出onnx有誤等誤操作。onnx模型的正確性驗證，可參考如下代碼：

from horizon_nn import horizon_onnx
import horizon_nn.horizon_onnxruntime as rt
import numpy as np
import cv2

def preprocess(input_name):
# BGR->RGB、Resize、CenterCrop···
# HWC->CHW
# normalization
return norm_data

def main():
# 加載模型文件
onnx_model = horizon_onnx.load(MODEL_PATH)
# 創建推理Session
sess = rt.InferenceSession(onnx_model.SerializeToString())
# 獲取輸入&輸出節點名稱
input_names = [input.name for input in sess.get_inputs()]
output_names = [output.name for output in sess.get_outputs()]
# 準備模型輸入數據
feed_dict = dict()
for input_name in input_names:
feed_dict[input_name] = preprocess(input_name)
# 開始模型推理，推理的返回值是一個list，依次與output_names指定名稱一一對應
result = sess.run(output_names, feed_dict)
# 后處理
postprocess(result)

if __name__ == '__main__':
main()

2.2 驗證PC端推理代碼的正確性

轉換完成后，將在model_output文件夾下生成四個模型，其中*original_float_model.onnx以及*optimized_float_model.onnx的精度是與原始浮點模型完全一致的。但是由于您通過配置yaml文件中的 input_type_rt 以及norm_type等參數，將圖像格式轉換以及normalize這兩項常用的預處理操作固化進了模型中，因此預處理代碼會與訓練時有所差異，具體差異及注意事項可參考前文1.2節。若發現推理結果與浮點模型不一致，則需再次確認預處理代碼的正確性。常見錯誤如下：

(1)已在yaml文件中配置 norm_type（scale/mean），前處理仍做了重復的normalize操作

(2)讀圖方式與浮點訓練時不一致。skimage、OpenCV、PIL讀圖差異如下表所示

確保PC端代碼的正確性之后，建議您可以測試一下*quantized_model.onnx的精度或單張推理結果，確認量化后精度滿足您的預期，再至板端完成應用開發。若精度不滿足預期，則可參照第三章內容嘗試精度調優。

2.3 驗證.bin模型的正確性

通常來說，將*quantized_model.onnx編譯生成*.bin的過程不會引入誤差，但事有萬一，我們提供了 hb_model_verifier 工具幫助您驗證定點模型和runtime模型的一致性。具體使用方式因OE版本不同而有所差異，您可以通過 hb_model_verifier --help 查看幫助信息，或查閱《hb_mapper_tools_guide》文檔了解該工具的使用方式。驗證通過，終端將打印 Onnx and Arm result Strict check PASSED 提示信息。若驗證失敗，請將模型及OE版本號提供給地平線技術支持人員分析。
但是目前該工具只支持單輸入模型，若為多輸入模型則可使用板端 hrt_model_exec infer工具獲取模型原始輸出。為保證輸入數據的一致性，建議您將python端預處理好的數據通過 np.tofile() 函數保存為二進制文件，并通過 hrt_model_exec infer 工具的 --input_file 參數指定輸入數據（多個輸入文件請以“,”隔開），具體使用方式可通過在板端執行 hrt_model_exec，查看幫助信息。若使用該工具得到的輸出結果與python端不一致，請將模型及OE版本號提供給地平線技術支持人員分析。
*目前 hrt_model_exec infer 工具不支持自動完成featuremap輸入的 padding 操作（該操作與硬件對齊規則相關，具體介紹請參考后文2.4節），您需要在PC端預處理時完成該操作，參考代碼如下：
pad_image = np.zeros((target_h, target_w, 3), dtype=np.int)
pad_image[:image_h, :image_w, :] = image
* target_h, target_w可通過hrt_model_exec model_info工具查看輸入節點的aligned shape屬性獲取

2.4 驗證板端推理代碼的正確性

確認前面所有環節都正常之后，最后我們就只需要排查板端推理代碼是否有誤了。常見問題有如下幾項：

(1)PC端與板端計算環境的差異（例如opencv讀圖差異、浮點計算精度不同等）；

(2)輸入數據未對齊至轉換配置的input_type_rt和input_layout_rt；

(3)輸入數據不滿足對齊規則，且未修改InputTensor的aligned_shape屬性（僅針對圖像輸入）。（BPU對齊規則可參考下圖解析）

其中，featuremap輸入時較為特殊，由于預測庫不會對featuremap數據做padding操作，因此當您的模型輸入為featuremap時，需在預處理時完成數據對齊，參考代碼如下：

if (input_w == out_w) {
memcpy(out, input, static_cast(input_h * input_w) * data_size);
} else {
for (int i = 0; i < input_h; i++) {
memcpy(out, input, static_cast(input_w) * data_size);
input += input_w;
out += out_w;
}
}

3 精度調優

3.1 后量化調優

對于后量化的精度誤差，我們一般會通過以下 3 種方式進行優化，且均需要在 yaml 文件配置后重新轉換模型：

1.調整校準方式

(1)calibration_type 優先嘗試 default，除此之外還可以嘗試 kl/max；

(2)將 calibration_type 配置為 max，并配置 max_percentile 為不同的分位數，我們推薦您優先嘗試 0.99999、0.99995、0.9999、0.9995、0.999；

(3)嘗試啟用 per_channel，可與任意校準方式配合使用。

2.調準校準數據集

(1)可以嘗試適當增加或減少數據量；

(2)嘗試換一批校準數據。

3.將部分尾部算子回退到 CPU 高精度計算

參考依據為轉換日志中模型每一層輸出的余弦相似度，若您觀察到有某一層余弦相似度異常，可嘗試在yaml文件中通過 run_on_cpu 參數配置，將該層指定到cpu進行高精度計算。一般我們僅會嘗試將模型輸出層 1～2 個算子回退至 CPU，太多的CPU算子會較大程度影響模型最終性能。

3.2 Pytorch QAT訓練

如果您的模型經過以上調優手段還是無法解決量化精度問題，那么該模型可能確實是 后量化（post training quantization，PTQ）方案中的 corner case，只能嘗試 量化感知訓練（quantization aware training，QAT）。
目前很多開源訓練框架均已支持 QAT 訓練能力，例如 Pytorch 的 eager-mode 和 fx-graph方案，tf-lite的量化方案等等。相比于后量化，QAT 訓練在浮點模型訓練收斂后進行 finetune，其精度損失由算法同學自行訓練優化，會更加可控，且開源社區中也有非常多的幫助資料。但 QAT 方案因為訓練成本和上手難度相對更高，所以我們更建議您在后量化實在無法解決精度問題時再選擇此方案。
地平線目前僅支持編譯 Pytorch 框架的 QAT 模型，具體示例請參考用戶手冊《horizon_ai_toolchain_user_guide》3.6.3.4 QAT模型量化編譯。

本文轉載自地平線開發者社區：https://developer.horizon.ai
原作者：顏值即正義