真相了，和rknn版本有問題，這版本轉出來的模型實際推理chunk也有問題...和txt的誤差相同...

我以為他來原來一樣，chunk肯定是對的，因為我之前只確定chunk的輸出了...

換成這個版本后...rknnpython輸出和torch輸出都對了：

使用此模型在c++端保存第一次推理的attncache，與python輸出比較，結果正確：

至此，最終部署還有兩個問題，第一個問題是板端是pipeline形式送來音頻，和目前測試的單條音頻直接計算出所有fbank分段輸入還不太一樣，同樣一條音頻送入pipeline反復推理，他結果總是變

第二個問題就是我之前搞的前綴束搜索好像沒啥用，他竟然和貪心的輸出一模一樣，關鍵那個代碼是用了kaldi的實現，不好編譯進sdk，只在demo中編譯還比較方便...

關于實際的轉換，我也不確定可不可以直接轉了，因為wenet的代碼我已經做過不少修改，但是沒有破壞網絡層數，主要是他里面的一些if啊什么的條件判斷影響了模型的追蹤，一層一層排查吧~

另外，今天辦公室空調開的真猛，現在已經發(fā)燒了嗚嗚嗚，最后附上板端推理的黃鶴樓（貪心）

明天換成束搜索不知道會好多少呢~