PyTorch手机价格分类实战：模型保存与loss波动解析

先摆个结果：我用 PyTorch 上手了一个手机价格区间分类实战，测试集准确率跑到 95% 左右。这篇文章不打算只晒一条漂亮的准确率，而是把大家私信问得最多的三块内容一次讲透：PyTorch 实战里模型保存与加载怎么搞才稳，训练时 loss 上蹿下跳到底正不正常，以及出了问题该怎么排查。

如果你是刚入门 PyTorch、对着公开数据集不知道从哪下手的人，这篇可以直接照着跑；如果你已经写过一些训练脚本，但每次保存模型、恢复训练都要现查资料，这篇也能帮你省不少时间。我尽量把代码、现象、原因、解决办法都放到一起，方便后面直接拿来当手册查。

这个项目用的是手机价格分类那类公开的匿名配置文件，特征都是硬件参数，目标变量是四个价格档位。任务本身不复杂，但作为 PyTorch 入门到实战过渡的案例非常合适：数据量不大、特征维度不高、不需要 GPU 也能几分钟跑完，同时又能把训练、验证、保存、加载、loss 分析这一整套流程完整走一遍。

1. 项目概述与整体方案

1.1 手机价格区间分类是个什么样的任务

手机价格区间分类，简单说就是给你一系列手机硬件配置，比如电池容量、蓝牙、摄像头像素、内存、重量、屏幕尺寸这些参数，让你判断这台手机属于哪个价格档位。常见的公开数据集会把价格切成 0、1、2、3 四档，0 代表低成本，3 代表高成本。整个任务本质是一个多分类问题，不是回归问题，所以输出层该用 softmax 或者全连接后接交叉熵损失，而不是用 MSE 去拟合具体价格。

我第一次接触这个数据集的时候，第一反应是这东西随便跑个随机森林也能有不错的准确率，干嘛非要用 PyTorch？后来想明白了，这个项目的核心价值不在“分类准确率能刷多高”，而在于它能把深度学习里最常用的工程流程完整串起来：数据预处理、自定义网络、训练循环、模型持久化、loss 监控。很多新手学 PyTorch 时天天看 MNIST 手写数字，但一遇到真正的表格数据就不知道怎么组织 DataLoader，这个项目刚好补上这块空白。

数据集本身大概有两千条样本，二十个特征，没有缺失值。特征里既有连续值，比如 ram、battery_power、px_height，也有二值特征，比如有无蓝牙、是否双卡、是否支持 4G。这种特征混合形态很常见，预处理的时候要注意量纲问题，不能直接丢进网络。

1.2 为什么选 PyTorch 而不是直接用 sklearn

如果只追求准确率，用 sklearn 的 GradientBoosting 或者 XGBoost 可能更省事，调参空间还大。但我推荐用 PyTorch 来做这个项目，有几个很实际的原因。

第一，PyTorch 的训练循环是完全可控的。你想在某个 batch 之后打印梯度、想中途改学习率、想手动判断 loss 是否异常，都可以直接插代码进去。sklearn 对底层训练过程的开放程度很低，出了问题只能当黑盒处理，不利于深入理解。

第二，这个任务非常适合体验“从零到一”的建模过程。自定义一个 MLP 只需要几十行代码，你能清楚看到每一层做了什么，也能直观感受 BatchNorm、Dropout、Adam 这些组件对训练曲线的实际影响。以后遇到更复杂的任务，这些基本功照样用得上。

第三，模型保存与加载这套操作在 PyTorch 里细节很多，而它们恰恰是这个项目的主题之一。如果你只用 sklearn，joblib 一行就完事，根本见不到 state_dict、checkpoint、map_location 这些坑，也就没办法积累真正的实战经验。

当然，我也不是说要排斥传统机器学习。事实上最后做对比的时候，XGBoost 在这个数据集上也能到 90% 以上。我的建议是两者都跑，一边用 PyTorch 练深度学习流程，一边用传统模型当基线，这样对“深度学习在表格数据上到底有没有优势”会有更直观的判断。

1.3 环境准备与依赖安装

这个项目不需要很夸张的硬件环境，CPU 也能跑，有 GPU 更好。我自己用的 PyTorch 2.x 版本，Python 3.10 左右，安装方式直接参考官网命令就行。建议先用 Anaconda 建一个干净的虚拟环境，别一股脑装进 base 环境里，后面项目多了容易乱。

bash复制conda create -n mobile_cls python=3.10
conda activate mobile_cls
pip install torch torchvision torchaudio
pip install pandas numpy scikit-learn tensorboard

如果本机有 NVIDIA 显卡，建议装对应 CUDA 版本的 PyTorch，训练会快很多。不过这个数据集太小，计算量几乎可以忽略，CPU 跑也就几十秒一个 epoch。很多人在安装 PyTorch 时会碰上网络慢的问题，我的经验是别死磕，换个网络好的时段，或者用官方轮子对应的本地安装方式，都比反复中断重试要省心。

数据方面，把下载好的 CSV 文件放到项目目录下，然后写代码读取。后面所有操作都是围绕这个文件展开的。

2. 数据预处理与特征分析

2.1 数据加载与初步检查

拿到数据的第一步永远是看结构，而不是急着写模型。用 pandas 读进来之后，我先做了三件事：看 shape、看 info、看缺失值。

python复制import pandas as pd

df = pd.read_csv("train.csv")
print(df.shape)
print(df.info())
print(df.isnull().sum().sum())
print(df["price_range"].value_counts())

两千多条样本，二十个特征，一个缺失值都没有，四个价格档位各占四分之一，类别非常均衡。这种均衡的好处是后面可以直接用 accuracy 作为主要指标，不用太担心类别不平衡导致的假象。

接着看特征的基本统计，这一步很关键。很多新手上来就把数据塞给 StandardScaler，但根本没看过原始数据长什么样。实际上这个数据集里有些特征是 0/1 标志位，有些是像 px_width、ram 这样的大数值连续特征，量纲差了上百倍。如果不做标准化，网络前期训练会被大数值特征主导，收敛速度慢，loss 曲线也不好看。

2.2 标准化与数据划分

标准化我是这样做的：

python复制from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler

X = df.drop(columns=["price_range"])
y = df["price_range"]

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, stratify=y, random_state=42
)

scaler = StandardScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)

请注意，StandardScaler 只能用训练集的数据去 fit，然后用训练集学到的均值和标准差去 transform 测试集。很多人图省事直接把整个 X 拿去 fit_transform，这会造成数据泄漏，等于让模型在训练阶段就偷看到了测试集的统计信息，最后评估结果会虚高。

标准化之后，大部分连续特征都会落在 0 附近、标准差为 1，二值特征虽然也会被缩放，但这不会破坏它们的语义。如果你想保留二值特征的原始 0/1 形态，也可以只对连续特征做标准化，但实测下来对最终准确率影响不大。

2.3 特征重要性分析

在训练之前，我还顺手看了一下特征重要性。用随机森林的 feature_importances_ 或者 pandas 的相关系数都能跑，结论很一致：ram（运行内存）是决定性特征，和价格区间的相关性极高。这符合直觉，手机价格和内存大小基本强相关。

这个发现有什么实际作用？它提醒我，哪怕网络结构很简单，只要能把 ram 这个特征利用好，准确率就不会低。同时也说明，这类表格数据里特征工程的重要性有时候比模型结构更大。不过我没有把 ram 单独拎出来做规则，因为那样就失去了用 PyTorch 训练模型的意义。保留全部特征，让网络自己学组合关系，反而更能体现深度模型的拟合能力。

3. 模型构建与训练

3.1 网络结构设计的思路

这个任务的特征维度只有 20，样本量也只有两千，不需要一上来就堆神经网络。我一开始就定了三层 MLP 的方案：输入层接一个 128 维的全连接层，中间接一个 64 维的全连接层，输出层是 4 个节点，对应四个价格档位。

python复制import torch
import torch.nn as nn

class PriceClassifier(nn.Module):
    def __init__(self, input_dim, num_classes=4):
        super().__init__()
        self.net = nn.Sequential(
            nn.Linear(input_dim, 128),
            nn.BatchNorm1d(128),
            nn.ReLU(),
            nn.Dropout(0.3),
            nn.Linear(128, 64),
            nn.ReLU(),
            nn.Linear(64, num_classes)
        )

    def forward(self, x):
        return self.net(x)

之所以加 BatchNorm 和 Dropout，是因为这个数据集样本量不大，网络稍微一深就容易过拟合。BatchNorm 能让每一层的输入分布更稳定，加速收敛；Dropout 则是在训练时随机丢弃一部分神经元，相当于给网络加了点正则，防止它死记硬背训练集。你可能会问，为什么不用 CNN 或者 Transformer？这种低维表格数据用 CNN 反而会丢失特征结构，Transformer 又需要大量数据和 attention 机制，在这个规模下纯属杀鸡用牛刀。

我也试过把网络加深到五层、每层 256 个节点，结果验证集准确率不但没有提升，反而因为过拟合掉了一些。所以后来还是回退到这个小而稳的结构。

3.2 损失函数和优化器怎么选

多分类任务首选 nn.CrossEntropyLoss，这个损失函数内部已经把 softmax 和交叉熵合并在一起，直接输入模型最后一层的 logits 就行，不要自己在 forward 里再加 softmax，否则损失计算会出现重复和数值不稳定。

python复制criterion = nn.CrossEntropyLoss()
optimizer = torch.optim.AdamW(model.parameters(), lr=1e-3, weight_decay=1e-4)

优化器我选的是 AdamW，相比传统 Adam 它对权重衰减的处理更规范，训练曲线也更稳。学习率初始设置成 1e-3，这是 MLP 在标准化后的表格数据上一个很常见的起点。如果 loss 发散，再降一档到 3e-4 或 1e-4。

至于很多人提到的 focal loss、perceptual loss，这里我并不建议用。focal loss 主要解决类别极度不平衡的问题，这个数据集四类很均匀，用了反而可能让训练更敏感；perceptual loss 是图像生成领域的东西，跟表格分类没有关系。选损失函数最重要的是匹配任务，而不是追热门名词。

3.3 训练循环与准确率统计

训练循环是 PyTorch 实战里最核心的代码，我每次都会写一个函数封装起来。关键点有三个：optimizer.zero_grad() 要放在前向之前，loss.backward() 只计算梯度，optimizer.step() 才更新参数。顺序不能乱，漏掉 zero_grad 梯度就会累积，导致 loss 异常。

python复制def train_one_epoch(model, loader, criterion, optimizer, device):
    model.train()
    total_loss = 0.0
    correct = 0
    total = 0

    for X_batch, y_batch in loader:
        X_batch = X_batch.to(device)
        y_batch = y_batch.to(device)

        optimizer.zero_grad()
        outputs = model(X_batch)
        loss = criterion(outputs, y_batch)
        loss.backward()
        optimizer.step()

        total_loss += loss.item() * X_batch.size(0)
        preds = outputs.argmax(dim=1)
        correct += (preds == y_batch).sum().item()
        total += y_batch.size(0)

    return total_loss / total, correct / total

这里强调一下 model.train() 和后面的 model.eval()。Dropout 和 BatchNorm 在训练和推理时行为不一样，train() 模式会随机丢神经元、用 batch 的统计量，eval() 模式会用全局统计量且不丢神经元。如果训练完直接推理忘了切到 eval，结果会有随机波动，准确率忽高忽低。

数据通过 DataLoader 加载，batch size 设成 64。每次迭代取一批数据，计算损失、回传梯度、更新参数，最后把所有样本的损失和正确数汇总起来除以总数，得到这个 epoch 的平均值和准确率。

3.4 完整训练脚本骨架

有了上面这个函数，剩下的就是循环训练多个 epoch，并且在每个 epoch 结束后跑验证集，记录最佳模型。完整骨架大概长这样：

python复制from torch.utils.data import TensorDataset, DataLoader

train_dataset = TensorDataset(
    torch.tensor(X_train, dtype=torch.float32),
    torch.tensor(y_train.values, dtype=torch.long)
)
test_dataset = TensorDataset(
    torch.tensor(X_test, dtype=torch.float32),
    torch.tensor(y_test.values, dtype=torch.long)
)

train_loader = DataLoader(train_dataset, batch_size=64, shuffle=True)
test_loader = DataLoader(test_dataset, batch_size=64, shuffle=False)

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = PriceClassifier(input_dim=20).to(device)

for epoch in range(30):
    train_loss, train_acc = train_one_epoch(
        model, train_loader, criterion, optimizer, device
    )
    print(f"Epoch {epoch+1:02d} | train_loss: {train_loss:.4f} | train_acc: {train_acc:.4f}")

这里我把训练和验证分开写了，后面接上验证逻辑就能在训练过程中实时观察模型表现。如果你想把代码写得工程化一点，可以把验证也封装成函数，方便保存最佳模型时调用。

4. 模型保存与加载全解析

4.1 state_dict 与整模型保存，到底该选哪个

模型训练完之后，最重要的一件事就是把它保存下来。PyTorch 里保存模型有两种主流方式，一个是直接保存整个模型对象，另一个是保存模型的 state_dict。我先说结论：长期维护、换环境部署，强烈建议保存 state_dict。

python复制# 方式一：保存整个模型（不推荐用于正式环境）
torch.save(model, "model_full.pth")

# 方式二：保存 state_dict（推荐）
torch.save(model.state_dict(), "model_state.pth")

两种方式我都在项目里试过。直接保存整个模型确实很省事，加载的时候一行 torch.load 就能拿到模型。问题在于，这种方式会把模型的类定义、参数、甚至 Python 环境的某些信息一起打包，换一台机器、换一个 PyTorch 版本，或者改了项目目录结构，加载的时候很容易报 “Can't get attribute” 这类错误。因为它本质上是 pickle 序列化，类定义必须能被完整导入。

state_dict 就稳得多。它只是一个字典，里面 key 是每层参数的名字，value 是张量。加载的时候只需要先手动创建同样结构的模型实例，再调用 load_state_dict 把参数填进去。

4.2 checkpoint 设计：把 optimizer、epoch、best_acc 一起存

如果你只是训练完存一个最终模型，那 state_dict 就够了。但实战里经常遇到训练到一半断掉、想接着训的情况，这时候就必须把 optimizer 的状态、当前 epoch、最佳指标一起存下来，这就是常说的 checkpoint。

python复制checkpoint = {
    "epoch": epoch,
    "model_state_dict": model.state_dict(),
    "optimizer_state_dict": optimizer.state_dict(),
    "best_acc": best_acc,
}
torch.save(checkpoint, "checkpoint.pth")

加载的时候对应写：

python复制ckpt = torch.load("checkpoint.pth", map_location=device)
model.load_state_dict(ckpt["model_state_dict"])
optimizer.load_state_dict(ckpt["optimizer_state_dict"])
start_epoch = ckpt["epoch"] + 1
best_acc = ckpt["best_acc"]

很多人会漏掉 optimizer_state_dict，然后拿一个全新的 Adam 优化器去接着跑旧模型。Adam 里存了每个参数的动量信息，一旦丢失，相当于优化器失忆了，后面训练会有一段明显的适应期，学习率调度也跟着变得不准。所以只要是想断点续训，optimizer 状态必须一起保存。

checkpoint 这种东西在一个项目里可以存多份，我习惯每轮都覆盖保存最新的，同时把验证集准确率最高的一份单独保存，用文件名区分。这样即使后面训练崩了，也能回退到历史最佳。

4.3 加载本地模型的常见坑

模型加载看起来简单，实际坑不少。我这套代码里踩过的典型问题大概有三个。

第一个是设备不匹配。在 GPU 上训练保存的 state_dict，到 CPU 机器上直接 torch.load 会报 device 相关的错误。解决办法是加载时指定 map_location：

python复制model.load_state_dict(torch.load("model_state.pth", map_location="cpu"))

如果是从 CPU 存出来再到 GPU 加载，map_location 可以直接写 "cuda:0"，或者用 map_location=device 统一控制。

第二个是忘了 model.eval()。加载回来的模型默认处于 train() 模式，如果模型里有 Dropout 或 BatchNorm，直接拿去推理结果会不稳定。所以加载之后一定要记得调用 model.eval()，这是每次写推理脚本最容易漏的一步。

第三个和 PyTorch 版本有关。新版本里 torch.load 默认 weights_only=True，对它来说，只允许加载张量这类安全对象。如果你保存的是老版本整模型或者其他非张量数据，加载时可能会报错。我的建议是保存时尽量只存 state_dict，这样既兼容又安全。如果一定要加载旧格式 checkpoint，可以在 torch.load 里显式指定 weights_only=False，但要对来源文件做好确认。

5. loss 波动全解析

5.1 什么样的 loss 曲线叫正常，什么样的要警惕

训练过程中的 loss 曲线是很多人最焦虑的东西。我先说一个结论：loss 上下波动不等于训练失败，只要整体趋势是下降的就别慌。

原因在于 PyTorch 每次计算 loss 用的是一个小批量样本，不是全量数据集。这批样本可能恰好比较容易，loss 低一些；下一批样本比较难，loss 高一些。batch size 越小、学习率越大，这个波动就越明显。所以正常的 loss 曲线看起来更像一条带毛刺的下降折线，而不是平滑的抛物线。

我整理了一张简单判断表，方便你对号入座：

这个表我在项目里贴了好几次，每当训练曲线一不对劲就对照检查，能省掉大量瞎猜时间。

5.2 从 loss 现象反推问题的排查清单

如果 loss 一直不降，我第一个想到的就是数据没标准化。这个数据集如果不做 StandardScaler，特征量纲差异会把某些维度放大，让网络前期优化方向特别偏，loss 就卡在一个高位下不去。把数据标准化之后，loss 几乎能立刻看到下降趋势。

如果 loss 震荡特别大，优先怀疑学习率太大。打个比方，学习率相当于你往山下走的步子，步子迈太大，会在山沟里来回横跳，永远踩不到谷底。这时候可以把学习率从 1e-3 降到 3e-4，或者换成带学习率衰减的调度器，比如 CosineAnnealingLR。

如果 loss 变成 nan，大多数情况是梯度爆炸或者数据里有异常值。我一般先检查输入数据是否有无穷值，再检查网络里有没有不稳定的中间层。标准化能解决一部分问题，实在不行可以加梯度裁剪：

python复制torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)

这段代码会在 loss.backward() 之后、optimizer.step() 之前执行，把梯度模长压到指定范围，防止梯度爆炸导致 loss 飞掉。

如果训练 loss 一直在降，验证 loss 却开始反弹，这就是过拟合。数据量只有两千，模型很容易背下训练集。解决办法就是我在网络里加 Dropout 和 weight_decay 的原因，也可以中途保存最佳模型，训练结束后直接用验证集表现最好的那个版本，而不是最后一个 epoch 的版本。

5.3 用 TensorBoard 把 loss 曲线画出来

肉眼盯着终端打印的 loss 数字也能看趋势，但不够直观。我建议用 TensorBoard 把曲线画出来，训练过程一目了然，后面排查问题非常爽。

python复制from torch.utils.tensorboard import SummaryWriter

writer = SummaryWriter("runs/mobile_cls")

for epoch in range(30):
    train_loss, train_acc = train_one_epoch(...)
    writer.add_scalar("train/loss", train_loss, epoch)
    writer.add_scalar("train/acc", train_acc, epoch)
    writer.flush()

训练结束后，在终端运行 tensorboard --logdir=runs，浏览器打开地址就能看到曲线。这里我习惯同时画训练 loss 和验证 loss，两张图叠在一起能很快看出有没有过拟合的苗头。如果你还想看网络结构，用 writer.add_graph(model, sample_input) 也能把计算图导出来，不过这个功能在这个小模型上意义不大。

6. 结果复盘与踩坑记录

6.1 95% 准确率是怎么跑出来的

最终结果：测试集准确率 95%，验证集跟测试集基本持平。这个成绩对四分类任务来说已经相当不错，但并不是靠玄学，而是靠几件很朴素的事。

第一是标准化做对了，量纲问题解决之后模型收敛速度明显加快。第二是网络结构合适，三层 MLP 对这个任务来说复杂度刚好。第三是用了 Dropout 和 weight_decay，抑制了过拟合，让验证集和测试集表现稳定。第四是训练过程中保存了最佳模型，而不是傻乎乎用最后一个 epoch。很多项目最后差几个点，往往就差在这些细节上。

我也固定了随机种子，这样每次跑出来的结果基本一致。做法是在训练脚本最开始加：

python复制import random
import numpy as np
import torch

def set_seed(seed=42):
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)

set_seed()

如果你复现的结果和我有微小差异，大概率是 PyTorch 版本或 CUDA 环境造成的，不影响整体结论。

6.2 我踩过的三个坑

第一个坑是忘记调用 model.eval()。训练完直接拿模型去测试，发现准确率忽上忽下，我还以为是 Dropout 的问题，后来才想起来推理时必须切到 eval 模式。这个坑印象太深了，所以这次写文章特意再提醒一次。

第二个坑是保存模型时图省事用了 torch.save(model, ...)，结果换台机器加载直接报错。从那以后我全部改成保存 state_dict，并且保存 checkpoint 时把必要的信息都放进去，再也没出过问题。

第三个坑是刚看到 loss 波动就慌了，赶紧调低学习率重训，结果反而把训练节奏打乱，最后准确率比原来还低。后来我学会先看整体趋势，让训练多跑几个 epoch，确认是持续停滞再做调整。这也是我整理那份判断表的初衷。

6.3 这个项目还能怎么扩展

项目跑通之后，玩法其实很多。你可以用交叉验证替代单次划分，得到更稳定的准确率估计；也可以把特征筛选和归一化换成不同的组合，观察对结果的影响。甚至可以把 XGBoost 和 PyTorch 模型的输出做集成，通常还能再往上提一点。

部署方面，把训练好的 state_dict 保存下来，写一个简单的 Flask 接口，接收手机配置参数，返回预测价格档位，就是一个完整的端到端小项目。如果还想进一步压缩模型，可以导出成 ONNX，这样部署时不需要依赖完整 PyTorch 环境。

我个人现在的习惯是，每次训练一个模型都会把 checkpoint 和 loss 曲线一起归档，标注好随机种子、学习率、网络结构。踩过几次坑之后你会发现，深度学习模型复现和调试最怕的不是模型太复杂，而是训练过程黑盒、保存加载混乱、loss 异常时瞎猜。这个手机价格分类项目虽然小，但把这一整套流程跑熟了，后面遇到更大的任务也能心里有底。