分享一個我這周剛踩完的坑把一個 OCR 檢測模型從 .tflite 轉(zhuǎn)成 Paddle Lite 的 .nb 格式命令里帶了 --target 參數(shù)指定目標(biāo)平臺結(jié)果各種報錯來回折騰光日志就看了好幾輪。這個問題看起來很小但涉及到的知識點其實很雜opt 工具版本差異、算子與 target 的匹配關(guān)系、轉(zhuǎn)換環(huán)境是否完整、最終部署目標(biāo)是否一致。如果你也正在做邊緣端 AI 部署或者模型是從 TensorFlow 導(dǎo)出、推理框架卻用的是 Paddle Lite那這篇排查記錄應(yīng)該能幫你省下不少時間。這篇文章適合幾類人第一次把 TFLite 模型拿去做 .nb 轉(zhuǎn)換的初學(xué)者在轉(zhuǎn)換時對 --target / --valid_targets 含義和區(qū)別不清不楚的工程師以及遇到“Unrecognized option”、“The model is not supported in arm”、“no target connected”這類報錯不知道怎么下手的同學(xué)。我會把整個排查過程、錯誤日志、最終解決方案以及常見的坑全部整理出來照著操作就能復(fù)現(xiàn)和避坑。1. 模型格式拆解.tflite 和 .nb 到底差在哪1.1 .tflite 和 .nb 的底層思路先別急著看報錯得先搞清楚這兩個格式之間的差異。.tflite 是 TensorFlow 的移動端推理格式本質(zhì)上是一個用 FlatBuffers 序列化之后的模型文件把計算圖、權(quán)重、算子元數(shù)據(jù)全部壓縮到一個二進(jìn)制里。它設(shè)計的目標(biāo)是“體積小、加載快、能在移動端跑”所以結(jié)構(gòu)非常緊湊。.nb 則是 Paddle Lite 的私有模型格式全名常叫 Naive Buffer。它不只是把模型重新序列化了一次而是按照 Paddle Lite 運行時所需要的算子排列順序和內(nèi)存布局把權(quán)重全部重新組織并寫入二進(jìn)制文件。這樣做的好處非常明顯加載 .nb 模型時運行時幾乎不需要再做復(fù)雜的解析和權(quán)重預(yù)處理直接映射到內(nèi)存就能開始推理。所以這就解釋了一個常見困惑為什么不能直接把 .tflite 后綴改成 .nb或者讓 Paddle Lite 直接加載 .tflite因為 Paddle Lite 的運行時不認(rèn)識 TFLite 的算子描述和權(quán)重排列方式它只認(rèn)自己定義的 .nb 結(jié)構(gòu)。如果最終推理框架定的是 Paddle Lite那這一步轉(zhuǎn)換就繞不開。1.2 Paddle Lite opt 工具在轉(zhuǎn)換鏈路里的位置負(fù)責(zé)把 TFLite 轉(zhuǎn)成 .nb 的官方工具是 opt也就是 paddle_lite_opt。它做的事情可以拆成三步把外部模型包括 Paddle 模型、TFLite、ONNX 等解析成 Paddle Lite 內(nèi)部的模型表示在這個表示上做算子融合、計算圖優(yōu)化、權(quán)重預(yù)處理根據(jù)你指定的目標(biāo)平臺挑選對應(yīng)的 kernel 實現(xiàn)并輸出最終的 .nb 文件。注意最后一步“根據(jù)目標(biāo)平臺挑選 kernel”這個目標(biāo)平臺就是通過 --target 或者新版工具里的 --valid_targets 參數(shù)來指定的。不同目標(biāo)平臺對應(yīng)不同的算子實現(xiàn)集合如果一個模型里的某個算子在你指定的 target 下沒有對應(yīng)的 kernel 實現(xiàn)轉(zhuǎn)換工具就會明確告訴你這個模型在這個 target 上不支持。這也是大量轉(zhuǎn)換報錯的總源頭。2. --target 參數(shù)的三個經(jīng)典坑版本、算子、運行時2.1 參數(shù)名本身就是一個版本陷阱我第一次轉(zhuǎn)換時命令是照著網(wǎng)上教程抄的paddle_lite_opt --model_fileocr_det.tflite --targetarm --optimize_outocr_det.nb結(jié)果工具直接回了一句ERROR: Unrecognized option: target我當(dāng)時的第一個反應(yīng)是工具沒裝好于是去查了paddle_lite_opt --help發(fā)現(xiàn)新版本里根本沒有 --target 這個參數(shù)官方參數(shù)已經(jīng)改成了--valid_targets。舊教程里常寫的--targetarm在舊版工具里能識別但新版工具會在參數(shù)解析階段直接拒絕。這個改動坑了不少人因為網(wǎng)上大量博客、帖子都停留在舊版本時代。所以碰到類似的“Unrecognized option”第一件事就是確認(rèn)你安裝的 opt 版本支持哪些參數(shù)不要盲目相信手頭的教程。2.2 算子覆蓋差異為什么 arm 轉(zhuǎn)不過、x86 卻能過把參數(shù)名改成--valid_targetsarm之后工具總算開始跑了但換來了另一個報錯[WARNING] Find 2 invalid ops: [p_placeholder, mirror_pad] [ERROR] The model is not supported in arm.這里的關(guān)鍵點在于Paddle Lite 在不同 target 上實現(xiàn)的算子集合是不同的。x86 平臺因為開發(fā)調(diào)試最常用算子覆蓋率往往最高arm 平臺的算子覆蓋會略少一些而 opencl、npu 這類異構(gòu)計算平臺支持的算子更集中。很多在 x86 上能順利轉(zhuǎn)換的模型切到 arm 后就會出現(xiàn)“某幾個算子找不到實現(xiàn)”的情況。我當(dāng)時這個模型里的問題算子就是 MirrorPad。這是一個在部分圖像前處理里會用到的算子但 Paddle Lite 的 arm kernel 列表里沒有實現(xiàn)它。這個只能從模型結(jié)構(gòu)層面解決比如在 TensorFlow 側(cè)用等價算子替換或者升級 Paddle Lite 版本碰碰運氣。2.3 運行時缺失導(dǎo)致的“no target connected”類報錯還有一類報錯和算子無關(guān)純粹是環(huán)境問題。我在一個精簡的 Docker 容器里試過指定--valid_targetsopencl結(jié)果工具報出no target connected這個錯誤的意思是opt 在初始化階段需要加載對應(yīng) target 的運行時但當(dāng)前環(huán)境里沒有 OpenCL 庫也沒有可用的 GPU 設(shè)備于是工具認(rèn)為這個 target 不可用。類似的情況還有指定 NPU target 但沒裝 NPU SDK、指定 xpu 但驅(qū)動未加載等。這類問題一般排查路徑比較清晰確認(rèn)對應(yīng)運行庫是否安裝設(shè)備節(jié)點是否存在環(huán)境變量是否設(shè)置。3. 轉(zhuǎn)換日志逐行看我是怎么定位到 MirrorPad 的3.1 環(huán)境準(zhǔn)備與版本確認(rèn)先說我當(dāng)時的運行環(huán)境這個很重要因為環(huán)境不同報錯現(xiàn)象真的會差很多宿主機(jī)x86_64 Ubuntu 20.04Python 3.8通過 pip 安裝 paddlelite 2.12opt 工具為同版本自帶的 paddle_lite_opt我強(qiáng)烈建議把轉(zhuǎn)換工作放在 x86 宿主機(jī)上做而不是在 ARM 開發(fā)板上做。原因后面會在速查表里詳細(xì)說簡單講就是板子上缺圖形庫、缺依賴的概率太高容易引出無關(guān)報錯。環(huán)境準(zhǔn)備如果用 conda有一個小坑要提醒創(chuàng)建虛擬環(huán)境時目標(biāo)目錄必須是一個不存在的新目錄如果你把 conda 環(huán)境直接指定到一個已經(jīng)存在且不是 conda 環(huán)境的目錄會報DirectoryNotACondaEnvironmentError。我當(dāng)時第一次建環(huán)境就踩了后來換了個全新路徑才順利裝上。3.2 從參數(shù)報錯到算子報錯的完整路徑最后的排查路徑其實是有邏輯的我按這個順序走了一遍先確認(rèn)參數(shù)名是否合法用--help查看當(dāng)前版本支持的選項把--target改成--valid_targets后工具進(jìn)入實際轉(zhuǎn)換再用--valid_targetsx86試轉(zhuǎn)同一個模型如果 x86 能成功說明模型本身結(jié)構(gòu)沒問題問題出在 arm 的算子覆蓋上最后定位到具體不支持的算子去 TensorFlow 側(cè)改模型。這個過程里x86 試轉(zhuǎn)是個關(guān)鍵動作。它能把“模型的問題”和“平臺的問題”切分開。如果連 x86 都轉(zhuǎn)不過那說明模型結(jié)構(gòu)和 TFLite 導(dǎo)出過程可能就有問題得先回到上層解決如果 x86 能過、arm 過不了那就專注處理不支持的算子。3.3 替換 MirrorPad 與重新導(dǎo)出我最終選擇在 TensorFlow 側(cè)把 MirrorPad 替換掉。簡單說MirrorPad 的作用是把張量按某種鏡像模式進(jìn)行邊緣填充這在圖像預(yù)處理里并不少見。我用 tf.pad 加 tf.concat 手動實現(xiàn)了同樣的效果然后重新導(dǎo)出 TFLite 模型import tensorflow as tf # 自定義鏡像填充實現(xiàn)代替 MirrorPad def mirror_pad_replacement(x, paddings): # paddings 是 [[top, bottom], [left, right]] 結(jié)構(gòu) # 先用 tf.reverse 構(gòu)造鏡像部分再 concat top, bottom paddings[0][0], paddings[0][1] left, right paddings[1][0], paddings[1][1] x_top tf.reverse(x[:, 1:1 top, :, :], axis[1]) x_bottom tf.reverse(x[:, -1 - bottom:-1, :, :], axis[1]) x tf.concat([x_top, x, x_bottom], axis1) x_left tf.reverse(x[:, :, 1:1 left, :], axis[2]) x_right tf.reverse(x[:, :, -1 - right:-1, :], axis[2]) x tf.concat([x_left, x, x_right], axis2) return x這里代碼只是一個示例思路在實際項目里替換操作要放在模型導(dǎo)出之前再經(jīng)過 TFLiteConverter 轉(zhuǎn)換converter tf.lite.TFLiteConverter.from_keras_model(model) converter.target_spec.supported_ops [tf.lite.OpsSet.TFLITE_BUILTINS] tflite_model converter.convert()重新導(dǎo)出后再執(zhí)行轉(zhuǎn)換命令就順利通過了。整個過程花的時間不算長但如果不理解“算子與 target 不匹配”這個原理很容易在錯誤方向上繞圈。3.4 成功轉(zhuǎn)換命令與部署驗證最終的轉(zhuǎn)換命令是這樣寫的paddle_lite_opt \ --model_fileocr_det.tflite \ --model_typetflite \ --valid_targetsarm \ --optimize_outocr_det \ --optimize_out_typenaive_buffer注意兩個容易被忽略的點一個是--model_typetflite如果不顯式指定工具默認(rèn)可能按 Paddle 模型處理結(jié)果完全對不上另一個是--optimize_out_typenaive_buffer這個參數(shù)決定了輸出的是 .nb 格式而不是默認(rèn)的 protobuf 格式模型。成功轉(zhuǎn)換后會生成ocr_det.nb文件。在開發(fā)板上用 Paddle Lite 的 C API 加載時標(biāo)準(zhǔn)的加載方式是#include paddle_api.h using namespace paddle::lite_api; MobileConfig config; config.set_model_from_file(/data/model/ocr_det.nb); auto predictor CreatePaddlePredictorMobileConfig(config);我在這一步也踩過一個坑一開始沒有指定 --model_type轉(zhuǎn)換命令跑完沒有報錯但生成的文件根本不是可用的 .nb部署時加載直接崩潰。所以轉(zhuǎn)換完一定要檢查文件別急著拷到板子上。4. 高頻報錯速查表一眼鎖定 .nb 轉(zhuǎn)換失敗原因4.1 常見錯誤對照與處理辦法我把這次排查過程中遇到以及從其他工程師那里收集到的常見報錯整理成了一張速查表遇到問題時直接對著找就行報錯信息可能原因處理辦法Unrecognized option: target工具版本較新參數(shù)已改為 --valid_targets用 --help 查看當(dāng)前版本支持的參數(shù)The model is not supported in arm模型包含 arm 平臺上不支持的算子替換算子上游實現(xiàn)或升級 Paddle Lite 版本Find N invalid ops: [xxx]日志中會具體列出不支持的算子逐個在 TensorFlow 側(cè)做等價替換no target connected目標(biāo)平臺運行時缺失或設(shè)備不可用檢查 OpenCL、NPU SDK、驅(qū)動是否安裝The target environment has been corrupted虛擬環(huán)境或工具安裝損壞重建 conda 環(huán)境重新安裝 paddleliteDirectoryNotACondaEnvironmentErrorconda 環(huán)境目標(biāo)路徑已被非 conda 目錄占用換一個全新的空目錄創(chuàng)建環(huán)境libGL error: failed to load driver: rockchip板卡上缺少圖形庫或 GPU 驅(qū)動不要在板子上跑轉(zhuǎn)換改用 x86 宿主機(jī)加載 .nb 時程序崩潰轉(zhuǎn)換 target 與部署設(shè)備不一致讓 --valid_targets 包含真實部署設(shè)備生成的文件無法被 Paddle Lite 識別未設(shè)置 --model_type 或 --optimize_out_type 不對顯式設(shè)置 --model_typetflite --optimize_out_typenaive_buffer這張表里前三條和最后一條出現(xiàn)的頻率最高建議把命令模板固定下來不要每次臨時寫參數(shù)。4.2 轉(zhuǎn)換與部署的幾條實用經(jīng)驗清單下面這些都是我在實際項目里實驗過、驗證過有效的方法按執(zhí)行順序整理轉(zhuǎn)換工具不要在目標(biāo)開發(fā)板上運行尤其不要在有圖形依賴的環(huán)境里運行。板卡上經(jīng)常缺 OpenGL 庫運行過程中容易爆出 libGL error 之類的無關(guān)錯誤干擾排查。轉(zhuǎn)換命令里強(qiáng)制寫明 --model_type。針對 TFLite 文件不寫的話工具可能按默認(rèn) Paddle 模型解析結(jié)果五花八門。--optimize_out_typenaive_buffer 才會生成真正可部署的 .nb。如果漏掉輸出格式不對部署時肯定加載失敗。先用 x86 target 試轉(zhuǎn)一遍。x86 能過、arm 不能過那基本是算子覆蓋問題x86 都不能過大概率是模型導(dǎo)出或結(jié)構(gòu)問題。模型算子復(fù)雜時用 Netron 打開 TFLite 文件人眼掃一遍算子列表遇到冷門算子提前在模型側(cè)替換能省一大輪轉(zhuǎn)換調(diào)試時間。--valid_targets 支持逗號分隔比如 --valid_targetsarm,opencl。在 GPU 設(shè)備上部署時這種寫法能讓算子盡量落到 GPU同時保留 CPU 后備提升整體成功率。轉(zhuǎn)換完成后用 file 命令檢查一下生成的 .nb確認(rèn)目標(biāo)文件確實是 Paddle Lite 的 naive buffer 格式。不要等到部署階段才知道轉(zhuǎn)換其實已經(jīng)失敗了。Paddle Lite 版本升級后舊的 .nb 最好重新轉(zhuǎn)換。因為新版本可能調(diào)整算子實現(xiàn)和模型格式舊文件不一定還能用。4.3 關(guān)于環(huán)境損壞和依賴缺失的補充有些報錯看起來很像模型問題實際是環(huán)境問題。比如我在排查過程中看到過這類信息corrupted environment: the target environment has been corrupted這種大概率是 conda 環(huán)境或者 pip 安裝的依賴文件損壞。不用去改模型直接把環(huán)境刪掉重建重新安裝 paddlelite 和相關(guān)庫問題就消失了。還有一種常見的是跑轉(zhuǎn)換工具時提示缺少某個動態(tài)庫比如 libOpenCL.so 找不到說明 opencl target 需要的運行庫沒有安裝。這時候裝對應(yīng)庫或者干脆不用那個 target都能解決。5. 最后分享幾點部署相關(guān)的經(jīng)驗這次踩坑之后我在團(tuán)隊里做了一個小改進(jìn)把轉(zhuǎn)換命令固化成腳本模型一更新就直接跑。腳本里把 --model_type、--valid_targets、--optimize_out_type 這些容易出錯的參數(shù)全部寫死只留模型路徑和 target 兩個變量。這樣無論是誰來做轉(zhuǎn)換都不會因為參數(shù)名寫錯再走一遍彎路。另外一個很重要的體會是不要迷信網(wǎng)上舊教程里的參數(shù)。工具版本迭代太快不同版本之間的參數(shù)和算子支持差異真的很大。遇到問題先確認(rèn)版本再對癥下藥比硬套教程要快得多。最后再分享一個小技巧如果模型很大轉(zhuǎn)換時間比較長可以在命令前加一個time記錄耗時同時讓工具輸出詳細(xì)日志。這樣一旦某次轉(zhuǎn)換失敗你能很快判斷是卡在哪一步而不是對著屏幕干等。做邊緣端模型轉(zhuǎn)換這件事耐心和系統(tǒng)性排查缺一不可。