大家现在主力用PyTorch还是TensorFlow？最近转项目好纠结

嵌入式部署的话我建议直接看ONNX的支持情况，PyTorch这边转ONNX再量化成熟些，TensorFlow的TFLite在树莓派这类平台上也挺稳。我之前做过类似的检测项目，最后选了PyTorch，主要是社区教程多，踩坑时好搜答案。你不如先确认下老板说的嵌入式具体是哪种芯片，是NV的Jetson还是ARM的，这个对选型影响很大。

嵌入式部署的话建议PyTorch，ONNX导出生态比TF顺滑太多，踩坑少一半。

嵌入式部署的话PyTorch生态更全，转ONNX也顺，TensorFlow Lite在部分硬件上反而折腾。

PyTorch吧，部署这块现在TorchScript和LibTorch在嵌入式上已经很成熟了，而且你之前用Keras的话转过来上手成本其实不高。TensorFlow Lite虽然生态全，但版本兼容性有时候真能让人折腾到怀疑人生。建议先看看你们目标板子对哪个框架的算子支持更全，这个比纠结框架本身更重要。

PyTorch吧，你之前用Keras转过来基本没啥学习成本，torch的生态对CV太友好了。不过嵌入式部署这块，TensorFlow Lite的成熟度确实比PyTorch强不少，ONNX中转的话两边都能用。建议先看看你们目标设备的SDK到底支持哪个runtime，这个比纠结框架本身重要多了。另外torch现在也有torchscript和mps，但工业落地坑还是比TF多。

说实话你这情况我太懂了，之前做检测也是从Keras往PyTorch迁，但嵌入式部署的话建议直接看TensorFlow Lite或者NCNN的算子支持列表，PyTorch这边转ONNX再量化有时候会遇到op不兼容的坑。而且工业项目维护周期长，TensorFlow的生态在部署链路上成熟不少，虽然写起来难受点。要是团队里没人啃过C++，还是先拿PyTorch把模型训出来，部署再找人帮忙转吧。

嵌入式部署的话PyTorch的ONNX生态更省心，TensorFlow Lite踩坑踩到怀疑人生。

嵌入式部署这块，PyTorch的torchscript和量化工具链确实比TF顺滑不少，社区里做边缘端的案例也更多。不过你要是图省事，ONNX导出后两边都能转，关键看你目标平台对哪个runtime优化更到位。我之前踩过坑，TF Lite在某些NPU上算子支持不全，调试起来挺头疼的。你嵌入式板子的SDK文档里一般会写推荐框架，照着来最稳。

嵌入式部署这块PyTorch的生态确实更顺一些，尤其TorchScript和量化工具链比TF成熟，我们之前做RK3588迁移踩了不少TF的坑。不过你要是Keras老手，转TF的TFLite可能上手快，但后期模型剪枝那些就得自己折腾了。建议先看下你们目标板子的SDK对哪个框架支持更全，很多NPU厂商现在优先给PyTorch出适配工具。

另外PyTorch 2.0的compile模式在推理速度上提升挺明显的，我们最近在Jetson上测试比原来快了近一倍。不过你要是团队里有人熟TF，协作起来可能更省事，框架选型有时候也得考虑队友的舒适区。你那个工业检测如果对实时性要求特别高，可能还得考虑TensorRT或者ONNX中转，别太纠结框架本身。

说实话嵌入式部署这块PyTorch的生态会省心不少，尤其你之前用Keras的话，转过去学TorchScript或者量化接口都比TF的TFLite顺手。不过要提醒你注意下目标板子的支持情况，有些专用NPU反而对TensorFlow的算子优化更成熟。我自己之前做工业质检，最后是PyTorch训练完转ONNX再调推理引擎，两头都不耽误，你可以参考这个思路。

嵌入式部署的话还是PyTorch吧，转ONNX生态成熟，踩坑少太多了。

说实话我跟你情况差不多，之前也是Keras用惯了，去年转PyTorch花了两周才彻底适应。但你要上嵌入式部署的话，我觉得TensorFlow这边生态确实更省心，TFLite和量化工具链成熟得多，PyTorch虽然现在也有TorchScript和ExecuTorch，但真到了树莓派或者Jetson上踩坑还是得自己折腾。我之前做过一个缺陷检测项目，试过把PyTorch模型转ONNX再转TensorRT，中间各种算子不兼容，调了一星期，后来同事用TF直接导出冻图反而顺滑。不过话说回来，现在很多工业场景其实也接受ONNX中间格式，如果你团队里有人熟悉C++部署，选哪个框架差别没那么大。另外你要注意一下，组里后续会不会跟学术界合作，如果那边全是PyTorch代码，你传出去不好对接。我个人的话，现在主力PyTorch，但部署环节会特意用TF或者ONNX兜底，两头都留着退路，就是维护成本高点。你老板让你自己选的话，不如先拿你们真实模型跑一遍两个框架的量化精度对比，哪个跟原模型误差小就选哪个，别光看网上评测。

PyTorch吧，部署这块现在ONNX+TensorRT/OpenVINO都挺成熟了，嵌入式上没比TF差多少。而且你之前用Keras，转PyTorch的torchvision接口上手反而更快，社区现成代码也多。关键PyTorch动态图调试省心，工业项目后期调模型太重要了，TF静态图改起来真要命。

既然要部署到嵌入式，那基本不用纠结了，PyTorch的torchscript和量化支持虽然比之前强不少，但TensorFlow Lite在边缘设备上的生态和算子覆盖还是更成熟些。我去年做个缺陷检测项目，试了转ONNX再走TF Lite，折腾半天精度掉了不少，后来直接用TF的post-training quantization就顺多了。不过你要是以后想发论文搞研究，PyTorch写起来确实爽，就看你们组更偏工程落地还是算法创新了。对了，你们目标板子是啥型号？有些芯片对特定框架的加速库优化差别挺大的。

说实话PyTorch在部署这块现在生态挺成熟的，TorchScript加ONNX转起来比TF顺手很多，尤其嵌入式场景下NCNN和MNN对PyTorch模型的支持都更友好。我自己之前从Keras迁到PyTorch大概花了俩礼拜，主要是习惯那个函数式API的写法，但上手后写自定义网络结构确实灵活不少。你那个工业检测项目如果涉及大量数据增强或自定义算子，PyTorch动态图调试起来能省不少时间。不过要是你们团队有人特别熟TF Serving那套，也别硬换，毕竟部署链路稳定最重要。

刚把Keras项目整体迁到PyTorch，只能说真香。如果你最后要部署到嵌入式设备，PyTorch这边有torchvision加量化工具链，转ONNX再走TensorRT或者NCNN都挺顺的，社区案例也多。TensorFlow这边主要是TF Lite生态成熟，但Keras转过去中间层有点绕，调试起来会想骂人。建议直接拿你现在的模型在两个框架各跑一遍推理速度和内存占用，数据比啥都靠谱。

嵌入式部署的话PyTorch转ONNX生态更顺，TensorFlow Lite对老设备支持好点，看你们目标平台是哪家芯片。

如果主要考虑部署到嵌入式设备，PyTorch这边现在转ONNX再走TensorRT或者NCNN的链路其实挺成熟的，社区资料也多。TensorFlow Lite虽然也不错，但遇到自定义算子的时候调试起来真的会让人头大。我之前在RK3588上跑过YOLOv5，PyTorch转出来的模型踩坑比TF少很多，特别是量化这块。建议你直接拿一个小模型把两端流程都跑通一遍，哪个顺手就选哪个，别光看文档脑补。

实话说，你要是纯做CV还得上嵌入式，PyTorch这边转ONNX再量化部署的链路我踩过坑，整体比TF顺不少，尤其现在torch的torchvision模型库直接export挺省事。不过TensorFlow Lite在微控制器和树莓派这类低算力设备上的算子支持确实更成熟，Firmware的坑少一些。我之前做过一个缺陷检测项目，最后是PyTorch训练，转成ONNX再用TensorRT或者OpenVINO推的，基本绕开了框架绑定的问题，但中间调试量化精度那一步真是折腾人。你老板让你自己选，可能更看重你对整个pipeline的把控能力，而不是框架本身，建议先看看你们目标板子的SDK对哪个框架的runtime支持最完整，比如有些NPU只给TF的demo，那就别纠结了。另外Keras转过来其实PyTorch的学习曲线没那么陡，就是得适应一下动态图和自定义Dataset那套逻辑。你调研的时候有没有试过把一个小模型完整跑通部署流程？这个比看文档有用多了。

说实话我之前也纠结过这个问题，后来发现关键还是看你部署的硬件平台。如果目标是树莓派或者Jetson这种，PyTorch的TensorRT和量化工具链现在挺成熟的，而且社区案例也多。TensorFlow的TFLite在MCU上确实更稳，但写起来感觉比Keras还绕。你之前用Keras的话，可能PyTorch的迁移曲线更平滑，毕竟API设计更接近Python直觉。不过最好先确认下你们嵌入式设备的算力，如果特别受限，可能还得考虑ONNX中转，这样两边都不耽误。