PyTorch和TensorFlow轮着用，到底该深耕哪个？

我们组就是PyTorch训、TF Serving部署，转换那步确实恶心，尤其自定义算子多了以后基本得重写一遍。后来干脆微调阶段全用PyTorch，导出ONNX再转TF，虽然多一层但比直接转SavedModel稳。你那边老代码如果动不了，可以试试这个路子，别硬扛着两边手写对齐。

我之前也遇到过类似问题，后来换了方案。

微调直接PyTorch吧，TF转HF坑太多，部署再单独搞转换或ONNX。

生态绑死了，HuggingFace那套就是PyTorch主场，硬转TF纯属给自己找罪受。

我们组就是两头都跑，训练微调全用PyTorch，训完转ONNX再进TF做线上推理，中间踩的坑能写本书。说白了TF现在就是给部署擦屁股的，Keras那套Callback再香也架不住生态全往PyTorch倒。你要是长期做大模型，建议把PyTorch吃透，TF会看懂SavedModel、能改改serving签名就够了。转换那些破事能避就避，实在避不开就转ONNX，比直接转TF权重靠谱多了。

HuggingFace生态基本绑死PyTorch了，硬转TF纯属给自己找罪受，老代码部署另说。

我们组就是TF训、PyTorch微调混着来，转换脚本都快成祖传代码了。说实话HF生态现在基本绑死PyTorch，你硬扛TF转权重纯属给自己加戏。建议老模型继续TF跑推理别动，新活儿全切PyTorch，别纠结深耕哪个，能跑通才是王道。

说实话你这个情况我太熟了，去年我们组也是TF老代码加新微调任务混着跑。HuggingFace那套生态确实基本绑死PyTorch了，转TF权重踩坑是常态，Embedding名字对不上还算轻的，有些自定义attention层转过去直接静默算错，排查起来要命。但你公司部署是SavedModel的话，全切PyTorch意味着推理链路得重搭，这个成本得先算清楚。我后来是微调阶段全用PyTorch加PEFT，训完导出ONNX再转回TF做serving，虽然多一步但两边优势都吃到了。Keras的Callback确实香，不过PyTorch Lightning的Trainer用习惯了也不差，就是得花两周适应。如果老代码短期内不会大改，建议别硬扛转换，直接把微调独立成PyTorch服务，跟TF部署解耦，长期看省心得多。

我们组现在就是PyTorch训、TF Serving推，中间用ONNX当桥，确实能跑但维护起来挺折腾的。你要是主要做微调，建议直接扎进PyTorch，HuggingFace那套生态省太多事了，TF转格式踩坑的时间够你重写好几版模型。老代码部署那块可以单独抽出来不动，新项目就别再往TF上靠了，两边都精通的成本太高，不值当。

TF部署PyTorch训练，身边这么干的不少，转换坑确实多但能忍。

大模型微调这块PyTorch就是亲儿子，TF转权重纯属给自己找活干，部署再另想办法吧。

我们组就是混着用的，训练侧全转PyTorch了，HuggingFace那套生态确实省事，LoRA微调基本开箱即用。TF那边就留着推理部署，SavedModel加TF Serving跑线上挺稳的，没必要硬转。转换踩坑太正常了，Embedding名字对不上算轻的，自定义层基本得手写一遍，后来我们干脆训练完导出ONNX再进TF，绕开权重转换这摊事。要是你主力搞微调，建议PyTorch学透，TF当部署工具用就行，别两头都深挖，精力扛不住。

建议直接深耕PyTorch，HF生态太香了，TF留着维护老代码就行，别跟转换较劲。