明白，我们会找时间更新一下，因为之前一直沿用旧方法部署，我们想先部署到板端进行正常使用
可以先用现有版本把板端跑通——工具链 1.24.x 本身支持 yolov11 pose 转换（你已转换成功），更新不是跑通的前提，AP=0 的根因大概率在板端解析这一环。建议按这个顺序收敛：
- 先跑一遍官方对照样例
OE 包samples/ai_toolchain/horizon_model_convert_sample/04_detection/16_yolov11_pose里自带模型和配套的ptq_yolo11_kpt_output_parser，原样上板跑一次：
- 官方样例正常 → 链路没问题，问题在你的模型导出或 parser 改动；
- 官方样例也是 0 → 板端环境/输入数据问题（重点查 NV12 数据源）。
- 检查你们改过的 parser 两个高危点
output_order默认值{1,0,6,3,2,7,5,4,8}是按官方样例输出顺序写死的，你的模型输出顺序不一定相同。到转换产物yolov11x_court_keypoint_model_256x256_output/下确认各输出 tensor 的实际名称和顺序，再对应填 order，顺序错位 AP 直接归零。is_performance为 true 时走 fastExp 近似，调试阶段先在 config json 里置 false，用标准 exp 排除近似误差干扰。
- 对齐后仍为 0 再做输出级对比
板端 dump 一帧推理输出，和 onnxruntime 跑同一张 NV12 图的结果对一下，能直接区分是量化问题还是后处理问题：
hrt_model_exec infer -m xxx_nv12.bin -i input_nv12.bin
先把第 2 步的 output_order 核对了再上板测，这个是最常见也最快的命中点。
？我把关键点的 - 0.5 去掉就没有偏移了
我再次总结现在遇到的情况：
人体关键点模型和3点模型，训练，部署的方法完全相同，校准数据（rgb）数量相同，bin模型都去除3个box的反量化节点，并且尝试了全int16和全int8两种量化方法。
pt模型的输出正常。
部署到板端后，全int16和全int8的人体关键点模型输出正常，我认为后处理代码没有问题。
全int16和全int8的3点模型输出的关键点、目标框都不正常，但有时候会有1、2个点与gt值很接近（oks=1），就算我拿训练集的数据输入模型，输出也很不正常。我认为模型在量化过程中出了问题。
我不妨提供训练集数据的检测效果，红色为gt，绿色为检测
旧版本还能使用的，但是现在model zoo具体的Runtime demo都已经更新到了不需要反量化的， 大概率是后处理代码的问题
两个模型同一条流水线、同样量化设置，人体模型正常、3 点模型全崩（int8/int16 都崩，训练集输入也崩），这基本排除「量化精度损失」——量化掉点不会掉成这样。「偶尔有 1、2 个点恰好对上 gt」这个现象反而更像输出 tensor 错位：你 parser 里 output_order {1,0,6,3,2,7,5,4,8} 是写死的，但 mapper 输出顺序取决于 ONNX 的输出顺序，两个模型导出时顺序未必一致；人体模型碰巧对上了，3 点模型没对上。
建议两步定位：
- 板端 dump 输出 vs PT 模型输出，先切开量化和解析的责任
hrt_model_exec infer -m xxx.bin -i one_frame_nv12.bin -o dump_out/
同一张图（同样预处理）过一遍 onnxruntime，9 个输出逐个对比。一致 → 量化没问题，查第 2 步；不一致 → 量化问题，去看 mapper log 里 main quantized node information 表中各输出节点的 Cosine Similarity，找塌掉的分支再调校准。
- 核对 9 个输出 tensor 的真实顺序
用 hrt_model_exec model_info -m xxx.bin（或运行时打印每个 tensor 的 validShape/dataType），按通道数对号入座：3 点模型应该是 box=64 通道（int16，你去了反量化节点）、cls=1 通道、kpt=9 通道，三个 stride 各一组。如果实际顺序和你写死的 output_order 对不上，box 被当 kpt 解析，就会出现「大部分点乱飞、偶尔蒙对一个」的现象。改法是把 output_order 按实际顺序填进 json 配置，别沿用人体模型那份。
工具用法参考：Rspress