Python训练营打卡Day34

# 加载鸢尾花数据集
iris = load_iris()
X = iris.data  # 特征数据
y = iris.target  # 标签数据
 
# 划分训练集和测试集
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)
 
# 归一化数据
from sklearn.preprocessing import MinMaxScaler
scaler = MinMaxScaler()
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)
 
# 将数据转换为PyTorch张量并移至GPU
# 分类问题交叉熵损失要求标签为long类型
# 张量具有to(device)方法，可以将张量移动到指定的设备上
X_train = torch.FloatTensor(X_train).to(device)
y_train = torch.LongTensor(y_train).to(device)
X_test = torch.FloatTensor(X_test).to(device)
y_test = torch.LongTensor(y_test).to(device)
class MLP(nn.Module):
    def __init__(self):
        super(MLP, self).__init__()
        self.fc1 = nn.Linear(4, 10)
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(10, 3)
 
    def forward(self, x):
        out = self.fc1(x)
        out = self.relu(out)
        out = self.fc2(out)
        return out
 
# 实例化模型并移至GPU
# MLP继承nn.Module类，所以也具有to(device)方法
model = MLP().to(device)
# 定义损失函数和优化器
criterion = nn.CrossEntropyLoss()
optimizer = optim.SGD(model.parameters(), lr=0.01)
 
# 训练模型
num_epochs = 20000
losses = []
start_time = time.time()
 
for epoch in range(num_epochs):
    # 前向传播
    outputs = model(X_train)
    loss = criterion(outputs, y_train)
 
    # 反向传播和优化
    optimizer.zero_grad()
    loss.backward()
    optimizer.step()
 
    # 记录损失值
    losses.append(loss.item())
 
    # 打印训练信息
    if (epoch + 1) % 100 == 0:
        print(f'Epoch [{epoch+1}/{num_epochs}], Loss: {loss.item():.4f}')
 
time_all = time.time() - start_time
print(f'Training time: {time_all:.2f} seconds')
 
# 可视化损失曲线
plt.plot(range(num_epochs), losses)
plt.xlabel('Epoch')
plt.ylabel('Loss')
plt.title('Training Loss over Epochs')
plt.show()

你这时可能会好奇，不是说gpu比cpu快很多吗？怎么cpu跑了3s，gpu跑了11s。

你问AI，他会告诉你，对于非常小的数据集和简单的模型，CPU 通常会比 GPU 更快。实际上，这并非本质的原因。

这需要你进一步理解二者的区别，深度学习项目的运行时长往往很长，如果只停留在跑通的层面，那是不够的。

本质是因为GPU在计算的时候，相较于cpu多了3个时间上的开销

数据传输开销 (CPU 内存 <-> GPU 显存)
核心启动开销 (GPU 核心启动时间)
性能浪费：计算量和数据批次
下面详细介绍下

数据传输开销 (CPU 内存 <-> GPU 显存)
在 GPU 进行任何计算之前，数据（输入张量 X_train、y_train，模型参数）需要从计算机的主内存 (RAM) 复制到 GPU 专用的显存 (VRAM) 中。
当结果传回 CPU 时（例如，使用 loss.item() 获取损失值用于打印或记录，或者获取最终预测结果），数据也需要从 GPU 显存复制回 CPU 内存。
对于少量数据和非常快速的计算任务，这个传输时间可能比 GPU 通过并行计算节省下来的时间还要长。
在上述代码中，循环里的 loss.item() 操作会在每个 epoch 都进行一次从 GPU 到 CPU 的数据同步和传输，以便获取标量损失值。对于20000个epoch来说，这会累积不少的传输开销。

核心启动开销 (GPU 核心启动时间)
GPU 执行的每个操作（例如，一个线性层的前向传播、一个激活函数）都涉及到在 GPU 上启动一个“核心”(kernel)——一个在 GPU 众多计算单元上运行的小程序。
启动每个核心都有一个小的、固定的开销。
如果核心内的实际计算量非常小（本项目的小型网络和鸢尾花数据），这个启动开销在总时间中的占比就会比较大。相比之下，CPU 执行这些小操作的“调度”开销通常更低。
性能浪费：计算量和数据批次
这个数据量太少，gpu的很多计算单元都没有被用到，即使用了全批次也没有用到的全部计算单元。
综上，数据传输和各种固定开销的总和，超过了 GPU 在这点计算量上通过并行处理所能节省的时间，导致了 GPU 比 CPU 慢的现象。

CPU (12th Gen Intel Core i9-12900KF): 对于这种小任务，CPU 的单核性能强劲，且没有显著的数据传输到“另一块芯片”的开销。它可以非常迅速地完成计算。
GPU (NVIDIA GeForce RTX 3080 Ti):需要花费时间将数据和模型从 CPU 内存移动到 GPU 显存。
每次在 GPU 上执行运算（如 model(X_train)、loss.backward()) 都有核心启动的固定开销。
loss.item() 在每个 epoch 都需要将结果从 GPU 传回 CPU，这在总共 20000 个 epoch 中会累积。
GPU 强大的并行计算能力在这种小任务上完全没有用武之地。
这些特性导致GPU在处理鸢尾花分类这种“玩具级别”的问题时，它的优势无法体现，反而会因为上述开销显得“笨重”。

那么什么时候 GPU 会发挥巨大优势？

大型数据集： 例如，图像数据集成千上万张图片，每张图片维度很高。
大型模型： 例如，深度卷积网络 (CNNs like ResNet, VGG) 或 Transformer 模型，它们有数百万甚至数十亿的参数，计算量巨大。
合适的批处理大小： 能够充分利用 GPU 并行性的 batch size，不至于还有剩余的计算量没有被 GPU 处理。
复杂的、可并行的运算： 大量的矩阵乘法、卷积等。
针对上面反应的3个问题，能够优化的只有数据传输时间，针对性解决即可，很容易想到2个思路：

直接不打印训练过程的loss了，但是这样会没办法记录最后的可视化图片，只能肉眼观察loss数值变化。
每隔200个epoch保存一下loss，不需要20000个epoch每次都打印，

如何衡量GPU的性能好坏呢？
以RTX 3090 Ti, RTX 3080, RTX 3070 Ti, RTX 3070, RTX 4070等为例

通过“代” 前两位数字代表“代”: 40xx (第40代), 30xx (第30代), 20xx (第20代)。“代”通常指的是其底层的架构 (Architecture)。每一代新架构的发布，通常会带来工艺制程的进步和其他改进。也就是新一代架构的目标是在能效比和绝对性能上超越前一代同型号的产品。

通过级别 后面的数字代表“级别”，

xx90: 通常是该代的消费级旗舰或次旗舰，性能最强，显存最大 (如 RTX 4090, RTX 3090)。
xx80: 高端型号，性能强劲，显存较多 (如 RTX 4080, RTX 3080)。
xx70: 中高端，甜点级，性能和价格平衡较好 (如 RTX 4070, RTX 3070)。
xx60: 主流中端，性价比较高，适合入门或预算有限 (如 RTX 4060, RTX 3060)。
xx50: 入门级，深度学习能力有限。
通过后缀 Ti 通常是同型号的增强版，性能介于原型号和更高一级型号之间 (如 RTX 4070 Ti 强于 RTX 4070，小于4080)。

通过显存容量 VRAM （最重要！！） 他是GPU 自身的独立高速内存，用于存储模型参数、激活值、输入数据批次等。单位通常是 GB（例如 8GB, 12GB, 24GB, 48GB）。如果显存不足，可能无法加载模型，或者被迫使用很小的批量大小，从而影响训练速度和效果

训练阶段：小批量梯度是对真实梯度的一个有噪声的估计。批量越小，梯度的方差越大（噪声越大）。显存小只能够使用小批量梯度。
推理阶段：有些模型本身就非常庞大（例如大型语言模型、高分辨率图像的复杂 CNN 网络）。即使你将批量大小减到 1，模型参数本身占用的显存可能就已经超出了你的 GPU 显存上限。

在 Python 中，call 方法是一个特殊的魔术方法（双下划线方法），它允许类的实例像函数一样被调用。这种特性使得对象可以表现得像函数，同时保留对象的内部状态。

# 我们来看下昨天代码中你的定义函数的部分
class MLP(nn.Module): # 定义一个多层感知机（MLP）模型，继承父类nn.Module
    def __init__(self): # 初始化函数
        super(MLP, self).__init__() # 调用父类的初始化函数
 # 前三行是八股文，后面的是自定义的
 
        self.fc1 = nn.Linear(4, 10)  # 输入层到隐藏层
        self.relu = nn.ReLU()
        self.fc2 = nn.Linear(10, 3)  # 隐藏层到输出层
# 输出层不需要激活函数，因为后面会用到交叉熵函数cross_entropy，交叉熵函数内部有softmax函数，会把输出转化为概率
 
    def forward(self, x):
        out = self.fc1(x)
        out = self.relu(out)
        out = self.fc2(out)
        return out

可以注意到，self.fc1 = nn.Linear(4, 10) 此时，是实例化了一个nn.Linear(4, 10)对象，并把这个对象赋值给了MLP的初始化函数中的self.fc1变量。

那为什么下面的前向传播中却可以out = self.fc1(x) 呢？，self.fc1是一个实例化的对象，为什么具备了函数一样的用法，这是因为nn.Linear继承了nn.Module类，nn.Module类中定义了__call__方法。（可以ctrl不断进入来查看）

在 Python 中，任何定义了 call 方法的类，其实例都可以像函数一样被调用。

当调用 self.fc1(x) 时，实际上执行的是：

self.fc1.call(x)（Python 的隐式调用）
而 nn.Module 的 call 方法会调用子类的 forward 方法（即 self.fc1.forward(x)）。这个方法就是个前向计算方法。
relu是torch.relu()这个函数为了保持写法一致，又封装成了nn.ReLU()这个类。来保证接口的一致性

PyTorch 官方强烈建议使用 self.fc1(x)，因为它会触发完整的前向传播流程（包括钩子函数）这是 PyTorch 的核心设计模式，几乎所有组件（如 nn.Conv2d、nn.ReLU、甚至整个模型）都可以这样调用。

# 不带参数的call方法
class Counter:
    def __init__(self):
        self.count = 0
    
    def __call__(self):
        self.count += 1
        return self.count
 
# 使用示例
counter = Counter()
print(counter())  # 输出: 1
print(counter())  # 输出: 2
print(counter.count)  # 输出: 2

类名后跟()，表示创建类的实例（对象），仅在第一次创建对象时发生。

call方法无参数的情况下，在实例化之后，每次调用实例时触发 call 方法

# 带参数的call方法
class Adder:
    def __call__(self, a, b):
        print("唱跳篮球rap")
        return a + b
 
adder = Adder()
print(adder(3, 5))  # 输出: 8

@浙大疏锦行