训练一个深度学习模型很多人觉得最难的是“调参”和“算力”。但真到要把模型用起来做预测的时候我见过最多的问题反而是训练结束后那一堆文件到底该拿哪一个去预测这个问题看似基础却卡住过从入门到中阶的不少人。本文就把“模型预测时需要的文件”这件事彻底讲透讲得比较通俗适合刚跑通训练流程、正要把模型接进业务或毕业设计项目的读者。先给一个总体结论预测时需要的不是“一个模型文件”而是一整套配套文件。权重文件只是其中一环。你还需要知道模型结构长什么样、输入数据要经过怎样的预处理、输出结果要怎么翻译成可读信息。后面我会把这些环节逐个拆开结合我实际踩过的坑来讲。1. 预测文件全景为什么光有权重文件并不够1.1 四类文件的分工与组织方式先说清楚一件事深度学习里说的“模型文件”在绝大多数场景下并不是单指一个文件而是指一组协同工作的文件。任何一个环节缺失推理代码要么直接报错要么静默地给出一个错误得离谱的结果。为了方便记忆我把预测阶段需要的文件分成四类类别常见文件作用少了会怎样权重文件model_final.pt、pytorch_model.bin、model.h5保存训练得到的参数模型只是未初始化的结构输出全是噪声结构/配置信息config.json、模型定义代码描述网络层数、维度、类别数无法重建模型权重填不进去预处理参数preprocess.json、mean_std.txt、tokenizer文件记录归一化均值、缩放尺寸、词表等输入分布和训练不一致精度断崖式下跌标签与后处理参数labels.txt、class_indices.json把输出索引映射为类名、设置阈值输出是一堆数字没法直接用很多项目里权重文件被当成唯一要紧的东西其他三类被随手丢在训练脚本的某个角落。等到要预测了才发现要么找不到要么版本对不上。尤其是“预处理参数”和“标签文件”它们不像权重那样不可或缺到会直接报错所以更容易被忽略——但代价是预测结果完全不可信。1.2 从一个 checkpoint 说起你可能已经注意到了.pt、.pth、.ckpt这些后缀在PyTorch世界里其实没有严格区分它们本质上都只是torch.save保存出来的二进制文件内部存什么完全由保存代码决定。很容易发生的一种情况是训练时图省事直接torch.save(model.state_dict(), model.pt)结果把模型结构信息全给丢了。或者反过来训练恢复逻辑很复杂需要保存优化器状态、epoch、学习率、best metric于是保存了一整个dict预测时却直接把dict丢给load_state_dict结果报一堆Missing key错误。提示预测时你需要的只是state_dict——也就是模型参数那一份数据。优化器状态、epoch、学习率这些是给“继续训练”用的预测根本用不上。所以我的建议很明确训练阶段用一个checkpoint文件保存完整训练状态包含model_state_dict、optimizer_state_dict、epoch、best_metric方便中途断点续训到了训练结束再用一个独立的部署文件保存仅预测所需的state_dict并顺手把config、preprocess、labels一起打包到同一个目录。这样预测代码只需要读固定目录逻辑干净也不会误把优化器状态喂给模型。2. 权重文件与模型结构预测的核心组合2.1 checkpoint 里到底存了什么以PyTorch为例state_dict是一个Python字典key是网络层的名字比如conv1.weight、fc.biasvalue是对应的张量。load_state_dict做的事情就是把这个字典里的值逐项拷进当前模型的参数里。这就带来一个隐含前提当前模型的层名字和形状必须和state_dict里的key完全一致。换句话说模型结构必须是“知道”的否则权重根本挂不上去。这里有个常见的坑GPU上训练的模型权重张量存在显存或带上cuda设备信息如果在CPU机器上直接用torch.load读取并尝试推理有时会报错或者产生奇怪的设备不匹配。稳妥做法是加载时带上map_locationcpu先把所有张量拉到CPU内存再在推理设备上重新移动例如model.to(cuda)。对于一个部署流程稳定的项目我建议统一写成torch.load(weight_path, map_locationcpu)避免设备不匹配这个低级错误。2.2 模型结构文件到底存不存在这个问题很多初学者会纠结。严格说模型结构在PyTorch里通常是以代码形式存在的它不是传统意义上的“文件”。你训练时定义了一个class ResNetClassifier(nn.Module)里面写了forward怎么算预测时就必须能import到这个类然后用这个类构造一个空模型再调用load_state_dict加载权重。不过在HuggingFace生态里“结构”被做成了配置文件config.json。例如BERT模型的config里会写num_hidden_layers、hidden_size、num_attention_heads、vocab_size这些字段加载模型时你不需要把整个网络类拷贝过来只需要调用某个AutoModel.from_pretrained(model_dir)它会先读config.json重建结构再加载pytorch_model.bin里的权重。这种方式对部署非常友好把“结构”这个隐性依赖变成了显式文件。我自己训练自定义模型时也会模仿这种做法把网络的必要参数写入config.json比如层数、隐藏维度、类别数、输入通道。预测脚本先读config重建模型再加载权重。好处是模型目录拷到任何机器上只要环境里有PyTorch就能重建出同样的网络不用到处找训练源码。2.3 常见权重格式速查表不同框架、不同部署阶段权重文件后缀五花八门。我整理了一个速查表方便你在接到陌生项目时快速判断格式后缀所属框架/生态典型场景备注.pt / .pthPyTorch训练产出、本地推理实质是pickle存state_dict或完整模型均可.ckptPyTorch Lightning / 旧版TensorFlow训练时保存的checkpoint需要确认内部结构可能是dict.h5Keras / TensorFlow教学项目、较早的部署存权重或完整模型.pb / .saved_modelTensorFlowTensorFlow Serving服务化部署SavedModel是目录结构.tfliteTensorFlow Lite移动端、嵌入式设备通常还伴随量化参数.onnxONNX Runtime / TensorRT等跨框架转换、端侧加速结构与计算图一并固化.pkl / .pickle各种自定义实验脚本随手保存兼容性差不建议作为交付格式接一个项目时先看后缀能快速缩小问题范围。比如拿到.pb就别用PyTorch去load拿到.onnx基本上说明对方已经把网络结构固化进计算图了预测时只需要onnxruntime或TensorRT加载不再需要原始模型代码。这也是为什么很多部署工程师会建议“要上线就转ONNX”——它把结构、权重、计算图全部变成一个文件依赖最少。3. 预处理参数与标签文件最容易丢的两个环节3.1 预处理参数训练和预测之间的隐形协议在图像分类里同样的权重用不同的预处理方式预测效果可能天差地别。最常见的就是归一化参数不对训练时用ImageNet的mean[0.485, 0.456, 0.406]、std[0.229, 0.224, 0.225]预测时随手写了mean[0.5,0.5,0.5]那么模型看到的输入分布就完全变了原本85%的准确率可能直接掉到20%以下。这不是模型坏了而是你和模型之间的“协议”没对上。所以我在做完一个模型后会把预处理参数单独存成一个preprocess.json{ resize: [224, 224], mean: [0.485, 0.456, 0.406], std: [0.229, 0.224, 0.225], to_rgb: true, max_value: 1.0 }预测代码读取这个JSON后再构造对应的transform。这样即使过了一个月忘了训练脚本里怎么写的也能从模型目录找到标准预处理流程。对于非图像任务也一样例如时间序列预测数据归一化用到的min、max或mean、std必须一并保存。我曾见过一个股价预测项目训练时把数据标准化了预测新数据时忘了做同样的标准化结果输出全部离谱后来发现就是缺少一个scaler描述文件。3.2 标签映射与后处理阈值分类模型的输出通常是一个概率向量比如1000类最后取argmax得到一个索引这个索引要映射成类名。最基本的做法是保存一个labels.txt每行一个类名按类别ID顺序排列预测时读取成list用索引取元素。如果用到中文类名或者复杂层级目录建议保存成class_indices.jsonkey是字符串形式的索引value是类名避免编码问题。这些文件如果丢失模型的输出就是一堆“18、7、203”这样的数字完全没法用。目标检测类模型还会更麻烦因为除了类别索引还依赖置信度阈值、NMS的IoU阈值、anchor尺寸等后处理参数。这些参数我会写进config.json或单独的后处理配置文件里而不是写死在预测代码里。这样调阈值时不需要改动代码只需要改配置重新加载便可看到效果。注意标签文件在保存时一定要固定顺序。训练时classes.txt是什么顺序预测时就要原样使用任何排序操作都有可能让整个结果错位。我见过有人为了方便按字母排序标签结果所有预测类名都张冠李戴。4. 浮点数精度格式为什么同一份模型文件体积会差一倍4.1 四种格式的原理与区别浮点数精度这个话题在模型部署时绕不开。因为你训练好的权重默认是fp32也就是32位浮点数每个参数占4字节。一个亿级参数的模型光权重就要占400MB左右。但如果用fp16保存每个参数只占2字节文件直接减半显存占用也减半推理速度还能提升。这里把常见的四种格式讲清楚格式符号位指数位尾数位每参数字节数特点fp3218234精度高范围大训练默认格式fp1615102范围小容易溢出但显存减半bf161872范围和fp32一样大精度低训练稳定tf321810截断实际无独立存储运行时计算的中间精度不是保存格式初看可能觉得fp16和bf16都是2字节为什么不直接用fp16关键在于指数位的位数。fp16的指数位只有5位能表示的数值范围很小比如在梯度计算时出现1e-5和1e4这样的中间值很容易溢出变成Inf或NaN。而bf16的指数位和fp32一样是8位范围足够大只是尾数位少了精度变差但在大多数网络的前向推理中这个精度损失是可以接受的。所以在Ampere及更新架构的GPU上bf16在训练加速里越来越受欢迎。4.2 推理时该怎么选精度这里强调一下tf32不是一种文件格式而是NVIDIA Ampere架构Tensor Core上的一种矩阵乘法计算模式本质是把fp32的输入截断成更低位宽参与计算从而获得接近fp16的速度、但保持接近fp32的数值范围。很多部署工程师会把“模型文件转成tf32”挂在嘴边严格来说是不准确的更常见的做法是在cuDNN或cuBLAS层面开启TF32开关让算子在运行时自动使用。对于推理精度的选择我的经验法则是如果模型文件是fp32且你的硬件和推理框架支持fp16先直接转fp16试一下。对于图像分类、目标检测这类模型精度损失通常很小但文件体积减半、加载速度变快、显存占用降低收益非常明显。如果转fp16后出现NaN、Inf或精度明显下降一定不要硬扛。先找出是哪些层出了问题常见的是大数值logits层或某些归一化层的统计数据过于敏感可以保留关键层为fp32其他层用fp16这就是混合精度。bf16用于推理时如果推理引擎和硬件支持它比fp16更稳坑更少因为不容易溢出。但CPU端对bf16支持不如fp16普遍需要实测不要盲上。ONNX或TensorRT导出时会提供量化或精度转换选项建议导出后用一个固定输入样本做对比把fp32和低精度模型的前向输出差控制在可接受范围再决定是否采用低精度版本。有一个细节值得留意低精度只是改变权重和激活值的存储、计算方式并没有改变模型的结构。所以如果你在预测时发现加载低精度文件后输出形状变了或报错那不是精度的问题而是转换过程本身出了问题要先检查导出脚本和算子支持情况。5. 从训练目录到上线预测的完整实操5.1 一份可以直接参考的模型目录模板我现在的习惯是每个项目结束训练后都整理出一个干净的deploy目录结构固定如下medical_classifier/ ├── config.json ├── model_final.pt ├── preprocess.json ├── labels.json └── README.mdconfig.json里放模型结构参数比如输入尺寸、网络层维度、类别数model_final.pt放纯state_dictpreprocess.json放归一化和尺寸参数labels.json放标签映射README.md写清楚模型版本、训练数据范围、输入要求、运行环境依赖。这个目录可以整体压缩成zip也可以直接作为下游服务的输入包。我把这个固定结构反复用在很多项目里包括一些序列模型和检测模型。只要是深度学习预测本质上都需要这四类信息。统一目录模板的最大好处是预测脚本永远只需要知道“模型目录在哪”不用关心具体项目里有哪些文件也不容易漏文件。5.2 一个可运行的推理示例下面用一个PyTorch图像分类任务做例子展示一个完整的预测流程代码不长但点出了加载文件的正确顺序import json import torch import torchvision.transforms as transforms from PIL import Image # 1. 读取结构配置重建模型 with open(config.json, r) as f: config json.load(f) model ResNetClassifier(num_classesconfig[num_classes]) model.load_state_dict(torch.load(model_final.pt, map_locationcpu)) model.eval() # 2. 读取预处理参数 with open(preprocess.json, r) as f: pre json.load(f) transform transforms.Compose([ transforms.Resize((pre[resize][0], pre[resize][1])), transforms.ToTensor(), transforms.Normalize(pre[mean], pre[std]), ]) # 3. 读取标签映射 with open(labels.json, r) as f: labels json.load(f) # {0: cat, 1: dog} # 4. 推理 image Image.open(test.jpg).convert(RGB) input_tensor transform(image).unsqueeze(0) with torch.no_grad(): logits model(input_tensor) pred_id logits.argmax(dim1).item() print(预测类别:, labels[str(pred_id)])这里有几个细节需要解释。model.eval()是必须的它会关闭Dropout和BatchNorm的训练行为否则同样的输入每次预测结果可能不同。torch.no_grad()用来关闭梯度追踪能减少显存占用推理速度也会更快。加载权重时用map_locationcpu然后由模型自己决定是否迁移到GPU这是最不容易出错的写法。5.3 部署交付时还要注意什么把模型目录打包交给别人时不要只发一个压缩包。我会额外做三件事第一在压缩包内附带requirements.txt或环境说明写清楚PyTorch版本、第三方库版本因为不同版本的PyTorch保存的权重文件在极端情况下可能无法互相加载第二用sha256生成一个校验文件防止传输过程中文件损坏第三附上一个smoke_test.py脚本里面固定一张测试图加载模型后跑一次前向打印输出shape和预测结果。这套流程看起来简单但能省下大量联调时间。我之前接过一个项目对方只给了一个.pth文件没有config、没有预处理参数、没有标签映射我花了整整一天反推网络结构和预处理方式。如果对方按照上面的模板交付整个对接过程大概只花十分钟。预测文件这件事本质上不是技术难题而是工程习惯问题。6. 常见问题排查与避坑技巧6.1 问题速查表为了让你在遇到问题时能快速定位我把平时最常遇到的几个问题整理成表格现象常见原因排查方法加载权重报“Missing key(s)”保存的是完整checkpoint而非纯state_dict检查字典key取model_state_dict字段加载权重报“size mismatch”模型结构和训练时不一致核对config里的类别数、层维度预测结果全是同一个类别预处理参数错误或数据增强没关闭对照训练时的transform检查数据分布CPU上加载报cuda错误权重里带了设备信息加map_locationcpu输出为NaN或Inffp16溢出、输入未归一化换bf16、混合精度或检查预处理ONNX结果和PyTorch不一致opset版本、动态维度、精度转换固定输入做数值对比逐步排查标签全部错位标签文件顺序和后处理不一致核对labels.json与训练时class顺序6.2 几个很重要的好习惯最后分享几个我花了不少代价才养成的习惯。第一训练结束的那一刻就顺手把部署包生成好不要把这件事拖到“真正要上线时”再做。那时候训练脚本可能已经改了很多版训练参数、标签顺序、预处理方式都记不清了逆向恢复部署文件会非常痛苦。第二写一个简单的模型自检脚本。加载完成后给一个随机输入跑一次前向检查输出shape是否符合预期。这个脚本不需要复杂十行以内就行但它能提前暴露80%的文件缺失问题比直接接业务代码后慢慢查要高效得多。第三对于从网上下载的预训练模型先验证文件是否完整。很多模型的官方来源会提供sha256校验值下载后用命令比对一下避免训练或推理到一半才发现模型文件损坏、结果全部跑偏。别高估自己踩坑的运气这类问题真遇到一次就够难受了。第四同一个模型如果既要跑fp32又要跑fp16建议分别保存不同文件不要一个文件反复覆盖。fp16模型验证通过后再删除fp32版本这样出现问题还有退路。我在实践中的体会是预测文件这块做得越规范后面接服务、换硬件、改预处理、加新场景时就越省心。很多“模型上线后效果崩了”的问题根源根本不是模型算法不行而是文件配套没跟上。 
长河君 · 2026/9/7 18:17:33 · 阅读 1.2k 深度学习模型预测需要哪些文件？权重、配置与预处理全解析
训练一个深度学习模型很多人觉得最难的是“调参”和“算力”。但真到要把模型用起来做预测的时候我见过最多的问题反而是训练结束后那一堆文件到底该拿哪一个去预测这个问题看似基础却卡住过从入门到中阶的不少人。本文就把“模型预测时需要的文件”这件事彻底讲透讲得比较通俗适合刚跑通训练流程、正要把模型接进业务或毕业设计项目的读者。先给一个总体结论预测时需要的不是“一个模型文件”而是一整套配套文件。权重文件只是其中一环。你还需要知道模型结构长什么样、输入数据要经过怎样的预处理、输出结果要怎么翻译成可读信息。后面我会把这些环节逐个拆开结合我实际踩过的坑来讲。1. 预测文件全景为什么光有权重文件并不够1.1 四类文件的分工与组织方式先说清楚一件事深度学习里说的“模型文件”在绝大多数场景下并不是单指一个文件而是指一组协同工作的文件。任何一个环节缺失推理代码要么直接报错要么静默地给出一个错误得离谱的结果。为了方便记忆我把预测阶段需要的文件分成四类类别常见文件作用少了会怎样权重文件model_final.pt、pytorch_model.bin、model.h5保存训练得到的参数模型只是未初始化的结构输出全是噪声结构/配置信息config.json、模型定义代码描述网络层数、维度、类别数无法重建模型权重填不进去预处理参数preprocess.json、mean_std.txt、tokenizer文件记录归一化均值、缩放尺寸、词表等输入分布和训练不一致精度断崖式下跌标签与后处理参数labels.txt、class_indices.json把输出索引映射为类名、设置阈值输出是一堆数字没法直接用很多项目里权重文件被当成唯一要紧的东西其他三类被随手丢在训练脚本的某个角落。等到要预测了才发现要么找不到要么版本对不上。尤其是“预处理参数”和“标签文件”它们不像权重那样不可或缺到会直接报错所以更容易被忽略——但代价是预测结果完全不可信。1.2 从一个 checkpoint 说起你可能已经注意到了.pt、.pth、.ckpt这些后缀在PyTorch世界里其实没有严格区分它们本质上都只是torch.save保存出来的二进制文件内部存什么完全由保存代码决定。很容易发生的一种情况是训练时图省事直接torch.save(model.state_dict(), model.pt)结果把模型结构信息全给丢了。或者反过来训练恢复逻辑很复杂需要保存优化器状态、epoch、学习率、best metric于是保存了一整个dict预测时却直接把dict丢给load_state_dict结果报一堆Missing key错误。提示预测时你需要的只是state_dict——也就是模型参数那一份数据。优化器状态、epoch、学习率这些是给“继续训练”用的预测根本用不上。所以我的建议很明确训练阶段用一个checkpoint文件保存完整训练状态包含model_state_dict、optimizer_state_dict、epoch、best_metric方便中途断点续训到了训练结束再用一个独立的部署文件保存仅预测所需的state_dict并顺手把config、preprocess、labels一起打包到同一个目录。这样预测代码只需要读固定目录逻辑干净也不会误把优化器状态喂给模型。2. 权重文件与模型结构预测的核心组合2.1 checkpoint 里到底存了什么以PyTorch为例state_dict是一个Python字典key是网络层的名字比如conv1.weight、fc.biasvalue是对应的张量。load_state_dict做的事情就是把这个字典里的值逐项拷进当前模型的参数里。这就带来一个隐含前提当前模型的层名字和形状必须和state_dict里的key完全一致。换句话说模型结构必须是“知道”的否则权重根本挂不上去。这里有个常见的坑GPU上训练的模型权重张量存在显存或带上cuda设备信息如果在CPU机器上直接用torch.load读取并尝试推理有时会报错或者产生奇怪的设备不匹配。稳妥做法是加载时带上map_locationcpu先把所有张量拉到CPU内存再在推理设备上重新移动例如model.to(cuda)。对于一个部署流程稳定的项目我建议统一写成torch.load(weight_path, map_locationcpu)避免设备不匹配这个低级错误。2.2 模型结构文件到底存不存在这个问题很多初学者会纠结。严格说模型结构在PyTorch里通常是以代码形式存在的它不是传统意义上的“文件”。你训练时定义了一个class ResNetClassifier(nn.Module)里面写了forward怎么算预测时就必须能import到这个类然后用这个类构造一个空模型再调用load_state_dict加载权重。不过在HuggingFace生态里“结构”被做成了配置文件config.json。例如BERT模型的config里会写num_hidden_layers、hidden_size、num_attention_heads、vocab_size这些字段加载模型时你不需要把整个网络类拷贝过来只需要调用某个AutoModel.from_pretrained(model_dir)它会先读config.json重建结构再加载pytorch_model.bin里的权重。这种方式对部署非常友好把“结构”这个隐性依赖变成了显式文件。我自己训练自定义模型时也会模仿这种做法把网络的必要参数写入config.json比如层数、隐藏维度、类别数、输入通道。预测脚本先读config重建模型再加载权重。好处是模型目录拷到任何机器上只要环境里有PyTorch就能重建出同样的网络不用到处找训练源码。2.3 常见权重格式速查表不同框架、不同部署阶段权重文件后缀五花八门。我整理了一个速查表方便你在接到陌生项目时快速判断格式后缀所属框架/生态典型场景备注.pt / .pthPyTorch训练产出、本地推理实质是pickle存state_dict或完整模型均可.ckptPyTorch Lightning / 旧版TensorFlow训练时保存的checkpoint需要确认内部结构可能是dict.h5Keras / TensorFlow教学项目、较早的部署存权重或完整模型.pb / .saved_modelTensorFlowTensorFlow Serving服务化部署SavedModel是目录结构.tfliteTensorFlow Lite移动端、嵌入式设备通常还伴随量化参数.onnxONNX Runtime / TensorRT等跨框架转换、端侧加速结构与计算图一并固化.pkl / .pickle各种自定义实验脚本随手保存兼容性差不建议作为交付格式接一个项目时先看后缀能快速缩小问题范围。比如拿到.pb就别用PyTorch去load拿到.onnx基本上说明对方已经把网络结构固化进计算图了预测时只需要onnxruntime或TensorRT加载不再需要原始模型代码。这也是为什么很多部署工程师会建议“要上线就转ONNX”——它把结构、权重、计算图全部变成一个文件依赖最少。3. 预处理参数与标签文件最容易丢的两个环节3.1 预处理参数训练和预测之间的隐形协议在图像分类里同样的权重用不同的预处理方式预测效果可能天差地别。最常见的就是归一化参数不对训练时用ImageNet的mean[0.485, 0.456, 0.406]、std[0.229, 0.224, 0.225]预测时随手写了mean[0.5,0.5,0.5]那么模型看到的输入分布就完全变了原本85%的准确率可能直接掉到20%以下。这不是模型坏了而是你和模型之间的“协议”没对上。所以我在做完一个模型后会把预处理参数单独存成一个preprocess.json{ resize: [224, 224], mean: [0.485, 0.456, 0.406], std: [0.229, 0.224, 0.225], to_rgb: true, max_value: 1.0 }预测代码读取这个JSON后再构造对应的transform。这样即使过了一个月忘了训练脚本里怎么写的也能从模型目录找到标准预处理流程。对于非图像任务也一样例如时间序列预测数据归一化用到的min、max或mean、std必须一并保存。我曾见过一个股价预测项目训练时把数据标准化了预测新数据时忘了做同样的标准化结果输出全部离谱后来发现就是缺少一个scaler描述文件。3.2 标签映射与后处理阈值分类模型的输出通常是一个概率向量比如1000类最后取argmax得到一个索引这个索引要映射成类名。最基本的做法是保存一个labels.txt每行一个类名按类别ID顺序排列预测时读取成list用索引取元素。如果用到中文类名或者复杂层级目录建议保存成class_indices.jsonkey是字符串形式的索引value是类名避免编码问题。这些文件如果丢失模型的输出就是一堆“18、7、203”这样的数字完全没法用。目标检测类模型还会更麻烦因为除了类别索引还依赖置信度阈值、NMS的IoU阈值、anchor尺寸等后处理参数。这些参数我会写进config.json或单独的后处理配置文件里而不是写死在预测代码里。这样调阈值时不需要改动代码只需要改配置重新加载便可看到效果。注意标签文件在保存时一定要固定顺序。训练时classes.txt是什么顺序预测时就要原样使用任何排序操作都有可能让整个结果错位。我见过有人为了方便按字母排序标签结果所有预测类名都张冠李戴。4. 浮点数精度格式为什么同一份模型文件体积会差一倍4.1 四种格式的原理与区别浮点数精度这个话题在模型部署时绕不开。因为你训练好的权重默认是fp32也就是32位浮点数每个参数占4字节。一个亿级参数的模型光权重就要占400MB左右。但如果用fp16保存每个参数只占2字节文件直接减半显存占用也减半推理速度还能提升。这里把常见的四种格式讲清楚格式符号位指数位尾数位每参数字节数特点fp3218234精度高范围大训练默认格式fp1615102范围小容易溢出但显存减半bf161872范围和fp32一样大精度低训练稳定tf321810截断实际无独立存储运行时计算的中间精度不是保存格式初看可能觉得fp16和bf16都是2字节为什么不直接用fp16关键在于指数位的位数。fp16的指数位只有5位能表示的数值范围很小比如在梯度计算时出现1e-5和1e4这样的中间值很容易溢出变成Inf或NaN。而bf16的指数位和fp32一样是8位范围足够大只是尾数位少了精度变差但在大多数网络的前向推理中这个精度损失是可以接受的。所以在Ampere及更新架构的GPU上bf16在训练加速里越来越受欢迎。4.2 推理时该怎么选精度这里强调一下tf32不是一种文件格式而是NVIDIA Ampere架构Tensor Core上的一种矩阵乘法计算模式本质是把fp32的输入截断成更低位宽参与计算从而获得接近fp16的速度、但保持接近fp32的数值范围。很多部署工程师会把“模型文件转成tf32”挂在嘴边严格来说是不准确的更常见的做法是在cuDNN或cuBLAS层面开启TF32开关让算子在运行时自动使用。对于推理精度的选择我的经验法则是如果模型文件是fp32且你的硬件和推理框架支持fp16先直接转fp16试一下。对于图像分类、目标检测这类模型精度损失通常很小但文件体积减半、加载速度变快、显存占用降低收益非常明显。如果转fp16后出现NaN、Inf或精度明显下降一定不要硬扛。先找出是哪些层出了问题常见的是大数值logits层或某些归一化层的统计数据过于敏感可以保留关键层为fp32其他层用fp16这就是混合精度。bf16用于推理时如果推理引擎和硬件支持它比fp16更稳坑更少因为不容易溢出。但CPU端对bf16支持不如fp16普遍需要实测不要盲上。ONNX或TensorRT导出时会提供量化或精度转换选项建议导出后用一个固定输入样本做对比把fp32和低精度模型的前向输出差控制在可接受范围再决定是否采用低精度版本。有一个细节值得留意低精度只是改变权重和激活值的存储、计算方式并没有改变模型的结构。所以如果你在预测时发现加载低精度文件后输出形状变了或报错那不是精度的问题而是转换过程本身出了问题要先检查导出脚本和算子支持情况。5. 从训练目录到上线预测的完整实操5.1 一份可以直接参考的模型目录模板我现在的习惯是每个项目结束训练后都整理出一个干净的deploy目录结构固定如下medical_classifier/ ├── config.json ├── model_final.pt ├── preprocess.json ├── labels.json └── README.mdconfig.json里放模型结构参数比如输入尺寸、网络层维度、类别数model_final.pt放纯state_dictpreprocess.json放归一化和尺寸参数labels.json放标签映射README.md写清楚模型版本、训练数据范围、输入要求、运行环境依赖。这个目录可以整体压缩成zip也可以直接作为下游服务的输入包。我把这个固定结构反复用在很多项目里包括一些序列模型和检测模型。只要是深度学习预测本质上都需要这四类信息。统一目录模板的最大好处是预测脚本永远只需要知道“模型目录在哪”不用关心具体项目里有哪些文件也不容易漏文件。5.2 一个可运行的推理示例下面用一个PyTorch图像分类任务做例子展示一个完整的预测流程代码不长但点出了加载文件的正确顺序import json import torch import torchvision.transforms as transforms from PIL import Image # 1. 读取结构配置重建模型 with open(config.json, r) as f: config json.load(f) model ResNetClassifier(num_classesconfig[num_classes]) model.load_state_dict(torch.load(model_final.pt, map_locationcpu)) model.eval() # 2. 读取预处理参数 with open(preprocess.json, r) as f: pre json.load(f) transform transforms.Compose([ transforms.Resize((pre[resize][0], pre[resize][1])), transforms.ToTensor(), transforms.Normalize(pre[mean], pre[std]), ]) # 3. 读取标签映射 with open(labels.json, r) as f: labels json.load(f) # {0: cat, 1: dog} # 4. 推理 image Image.open(test.jpg).convert(RGB) input_tensor transform(image).unsqueeze(0) with torch.no_grad(): logits model(input_tensor) pred_id logits.argmax(dim1).item() print(预测类别:, labels[str(pred_id)])这里有几个细节需要解释。model.eval()是必须的它会关闭Dropout和BatchNorm的训练行为否则同样的输入每次预测结果可能不同。torch.no_grad()用来关闭梯度追踪能减少显存占用推理速度也会更快。加载权重时用map_locationcpu然后由模型自己决定是否迁移到GPU这是最不容易出错的写法。5.3 部署交付时还要注意什么把模型目录打包交给别人时不要只发一个压缩包。我会额外做三件事第一在压缩包内附带requirements.txt或环境说明写清楚PyTorch版本、第三方库版本因为不同版本的PyTorch保存的权重文件在极端情况下可能无法互相加载第二用sha256生成一个校验文件防止传输过程中文件损坏第三附上一个smoke_test.py脚本里面固定一张测试图加载模型后跑一次前向打印输出shape和预测结果。这套流程看起来简单但能省下大量联调时间。我之前接过一个项目对方只给了一个.pth文件没有config、没有预处理参数、没有标签映射我花了整整一天反推网络结构和预处理方式。如果对方按照上面的模板交付整个对接过程大概只花十分钟。预测文件这件事本质上不是技术难题而是工程习惯问题。6. 常见问题排查与避坑技巧6.1 问题速查表为了让你在遇到问题时能快速定位我把平时最常遇到的几个问题整理成表格现象常见原因排查方法加载权重报“Missing key(s)”保存的是完整checkpoint而非纯state_dict检查字典key取model_state_dict字段加载权重报“size mismatch”模型结构和训练时不一致核对config里的类别数、层维度预测结果全是同一个类别预处理参数错误或数据增强没关闭对照训练时的transform检查数据分布CPU上加载报cuda错误权重里带了设备信息加map_locationcpu输出为NaN或Inffp16溢出、输入未归一化换bf16、混合精度或检查预处理ONNX结果和PyTorch不一致opset版本、动态维度、精度转换固定输入做数值对比逐步排查标签全部错位标签文件顺序和后处理不一致核对labels.json与训练时class顺序6.2 几个很重要的好习惯最后分享几个我花了不少代价才养成的习惯。第一训练结束的那一刻就顺手把部署包生成好不要把这件事拖到“真正要上线时”再做。那时候训练脚本可能已经改了很多版训练参数、标签顺序、预处理方式都记不清了逆向恢复部署文件会非常痛苦。第二写一个简单的模型自检脚本。加载完成后给一个随机输入跑一次前向检查输出shape是否符合预期。这个脚本不需要复杂十行以内就行但它能提前暴露80%的文件缺失问题比直接接业务代码后慢慢查要高效得多。第三对于从网上下载的预训练模型先验证文件是否完整。很多模型的官方来源会提供sha256校验值下载后用命令比对一下避免训练或推理到一半才发现模型文件损坏、结果全部跑偏。别高估自己踩坑的运气这类问题真遇到一次就够难受了。第四同一个模型如果既要跑fp32又要跑fp16建议分别保存不同文件不要一个文件反复覆盖。fp16模型验证通过后再删除fp32版本这样出现问题还有退路。我在实践中的体会是预测文件这块做得越规范后面接服务、换硬件、改预处理、加新场景时就越省心。很多“模型上线后效果崩了”的问题根源根本不是模型算法不行而是文件配套没跟上。