知識點回歸：
- CPU性能的查看：看架構代際、核心數、線程數
- GPU性能的查看：看顯存、看級別、看架構代際
- GPU訓練的方法：數據和模型移動到GPU device上
- 類的call方法：為什么定義前向傳播時可以直接寫作self.fc1(x)
①CPU性能查看 ：
- 架構代際： cat /proc/cpuinfo 查看型號和flags
- 核心/線程數： lscpu 或Python中 os.cpu_count()
②GPU性能查看 ：
import torch
print(torch.cuda.get_device_name(0)) # 型號
print(torch.cuda.get_device_capability(0)) # 計算能力
print(torch.cuda.get_device_properties(0).total_memory/1e9) # 顯存(GB)③GPU訓練方法 ：
device = torch.device("cuda" if torch.cuda.is_available() else "cpu")
model = Model().to(device)
data = data.to(device)④類的 __call__ 方法 ：
- 當類實現 __call__ 時，實例可以像函數一樣調用
- self.fc1(x) 有效是因為PyTorch的 nn.Module 實現了 __call__ ，其內部會調用 forward()
?實驗現象解釋：
一、GPU-CPU交互特性 ：
- loss.item() 確實需要同步，但現代GPU有：
? - 異步執行能力（計算和傳輸可重疊）
? - 并行流水線（下一個計算可提前開始）
二、瓶頸分析 ：
# 典型訓練循環中的時間分布
for epoch in range(epochs):# 數據加載時間（CPU） ← 常被忽視的瓶頸# GPU計算時間# 同步記錄時間（約0.1-1ms/次） # 其他開銷（梯度清零等）三、實驗數據解讀 ：
- 記錄次數從200→10次（20倍變化），但時間僅差0.69秒（6.6%）
- 說明：
? - 記錄操作本身耗時占比極小（<1ms/次）
? - 主要時間消耗在數據加載和GPU計算
四、驗證方法建議 ：
# 精確測量記錄操作耗時
import time
record_times = []
for _ in range(1000):start = time.perf_counter()losses.append(loss.item()) # 測試單次記錄耗時record_times.append(time.perf_counter() - start)
print(f"平均記錄耗時：{sum(record_times)/len(record_times)*1e6:.2f}微秒")
![[Java] 封裝](http://pic.xiahunao.cn/[Java] 封裝)
)
Docker安裝Jitsi Meet指南-使用內網IP訪問)
)
