PyTorch部署时打包环境更可靠，因pip无法锁定libtorch、CUDA、glibc等二进制ABI兼容性；conda pack可完整捕获所有so依赖，但需保证架构一致且目标机glibc版本不低于打包机。
PyTorch模型部署时为什么打包环境比直接 pip install 更可靠
因为 PyTorch 的二进制依赖（如 libtorch、CUDA 运行时、glibc 版本）和 Python 层依赖（torch、torchvision）存在隐式耦合，pip 安装无法锁定底层 ABI 兼容性。生产环境缺一个 libcudnn.so.8 或 glibc 版本低 0.2，import torch 就直接报 ImportError: libxxx.so: cannot open shared object file。
实操建议：
- 用
conda pack打包完整环境（含lib/下所有 so 文件），它能捕获 conda 安装的全部二进制依赖，比pip freeze+requirements.txt更彻底 - 打包前确保环境是 clean 的：新建 conda env，只装必要包，避免带入宿主机残留依赖
- 目标机器必须和打包机架构一致（x86_64 / aarch64），且 glibc 版本 ≥ 打包机（可用
ldd --version对比）
torchscript 模型能否脱离 Python 环境运行
可以，但仅限推理；torch.jit.script 或 torch.jit.trace 导出的 .pt 文件本身不依赖 Python 解释器，但默认仍需 libtorch 动态链接库 —— 它不是“零依赖”，而是“Python-free”。
常见错误现象：
- 用
torch::load()加载模型时崩溃，报undefined symbol: _ZN3c104cuda17getCurrentCUDACtxEv→ CUDA 版本不匹配或未链接libtorch_cuda.so - CPU 模型在无 GPU 机器上跑出
CUDA error: no kernel image is available for execution on the device→ 模型里混用了.cuda()调用，没做 device 判断
实操建议：
- 导出时显式指定 device：
model.to('cpu').eval()，再torch.jit.script(model)，避免残留 CUDA 调用 - C++ 部署时，用
libtorch的 CPU-only 版本（下载地址含cpu字样），体积小、兼容性高 - 若必须用 CUDA 版本，确保目标机器安装对应版本的 NVIDIA 驱动和
cudnn，且LD_LIBRARY_PATH包含libtorch/lib/
用 PyInstaller 打包 PyTorch 项目为什么常失败
PyInstaller 对 C 扩展和动态加载路径处理粗糙，而 PyTorch 大量使用 dlopen 加载 libtorch_*.so、torch/_C.cpython-*.so，这些路径在打包后失效。
典型错误信息：
ModuleNotFoundError: No module named 'torch._C'-
torch.nn.modules.module.ModuleAttributeError: 'MyModel' object has no attribute '_parameters'（实际是 _C 没加载成功）
实操建议：
- 不要用
--onefile，改用--onedir，然后手动把torch/lib/下所有.so文件复制到打包目录的./lib/并通过LD_LIBRARY_PATH=./lib启动 - 在
hook-torch.py中显式添加隐藏导入：hiddenimports = ['torch._C', 'torch.distributed', 'torch.multiprocessing'] - 更稳妥的做法：放弃 PyInstaller，改用
conda-pack+ 自定义启动脚本（#!/bin/bash; export LD_LIBRARY_PATH=$(pwd)/lib:$LD_LIBRARY_PATH; ./venv/bin/python app.py）
编译成可执行文件是否真能“免安装”运行
不能一概而论。所谓“免安装”只是免 Python 和 pip，但依然强依赖系统级共享库 —— 比如 libstdc++.so.6、libgomp.so.1、libcudnn.so.8。这些库在 CentOS 7 上可能叫 libstdc++.so.6.0.19，在 Ubuntu 22.04 上是 6.0.30，不兼容就直接 Segmentation fault。
性能与兼容性权衡：
- 静态链接
libstdc++可行（加-static-libstdc++），但libtorch官方不提供静态版，强行静态会失败 - 用
linuxdeployqt或自建容器镜像（FROM ubuntu:20.04）反而更可控 —— 把运行时环境“固化”下来，比折腾链接更省时间 - 如果目标是边缘设备（Jetson、RK3588），优先用厂商提供的
torch2trt或rknn-toolkit2转模型，它们生成的引擎文件自带 runtime，才是真正意义的“免依赖”
最常被忽略的一点：模型里调用的第三方库（如 cv2、scipy）的二进制依赖，往往比 PyTorch 本身更难打包干净。别只盯着 torch，先 ldd your_binary | grep "not found" 看漏了啥。
