轉自:
先看兩個問題:
(1)深度學習中batch size的大小對訓練過程的影響是什麼樣的?
(2)有些時候不可避免地要用超大batch,比如人臉識別,可能每個batch要有幾萬甚至幾十萬張人臉影象,訓練過程中超大batch有什麼優缺點,如何儘可能地避免超大batch帶來的負面影響?
面試版回答
在不考慮Batch Normalization的情況下(這種情況我們之後會在bn的文章裡專門探討),先給個自己當時回答的答案吧(相對來說學究一點):
(1) 不考慮bn的情況下,batch size的大小決定了深度學習訓練過程中的完成每個epoch所需的時間和每次迭代(iteration)之間梯度的平滑程度。batch size只能說影響完成每個epoch所需要的時間,決定也算不上吧。根本原因還是CPU,GPU算力吧。瓶頸如果在CPU,例如隨機資料增強,batch size越大有時候計算的越慢。
對於一個大小為N的訓練集,如果每個epoch中mini-batch的取樣方法採用最常規的N個樣本每個都取樣一次,設mini-batch大小為b,那麼每個epoch所需的迭代次數(正向+反向)為 , 因此完成每個epoch所需的時間大致也隨著迭代次數的增加而增加。
由於目前主流深度學習框架處理mini-batch的反向傳播時,預設都是先將每個mini-batch中每個instance得到的loss平均化之後再反求梯度,也就是說每次反向傳播的梯度是對mini-batch中每個instance的梯度平均之後的結果,所以b的大小決定了相鄰迭代之間的梯度平滑程度,b太小,相鄰mini-batch間的差異相對過大,那麼相鄰兩次迭代的梯度震盪情況會比較嚴重,不利於收斂;b越大,相鄰mini-batch間的差異相對越小,雖然梯度震盪情況會比較小,一定程度上利於模型收斂,但如果b極端大,相鄰mini-batch間的差異過小,相鄰兩個mini-batch的梯度沒有區別了,整個訓練過程就是沿著一個方向蹭蹭蹭往下走,很容易陷入到區域性最小值出不來。
總結下來:batch size過小,花費時間多,同時梯度震盪嚴重,不利於收斂;batch size過大,不同batch的梯度方向沒有任何變化,容易陷入區域性極小值。
(2)(存疑,只是突發奇想)如果硬體資源允許,想要追求訓練速度使用超大batch,可以採用一次正向+多次反向的方法,避免模型陷入區域性最小值。即使用超大epoch做正向傳播,在反向傳播的時候,分批次做多次反向轉播,比如將一個batch size為64的batch,一次正向傳播得到結果,instance級別求loss(先不平均),得到64個loss結果;反向傳播的過程中,分四次進行反向傳播,每次取16個instance的loss求平均,然後進行反向傳播,這樣可以做到在節約一定的訓練時間,利用起硬體資源的優勢的情況下,避免模型訓練陷入區域性最小值。
通俗版回答
那麼我們可以把第一個問題簡化為一個小時候經常玩的遊戲:
深度學習訓練過程:貼鼻子
訓練樣本:負責指揮的小朋友們(觀察角度各不一樣)
模型:負責貼的小朋友
模型衡量指標:最終貼的位置和真實位置之間的距離大小
由於每個小朋友站的位置各不一樣,所以他們對鼻子位置的觀察也各不一樣。(訓練樣本的差異性),這時候假設小明是負責貼鼻子的小朋友,小朋友A、B、C、D、E是負責指揮的同學(A, B站在圖的右邊,C,D, E站在左邊),這時候小明如果採用:
每次隨機詢問一個同學,那麼很容易出現,先詢問到了A,A說向左2cm,再問C,C說向右5cm,然後B,B說向左4cm,D說向右3cm,這樣每次指揮的差異都比較大,結果調過來調過去,沒什麼進步。
每次隨機詢問兩個同學,每次取詢問的意見的平均,比如先問到了(A, C),A說向左2cm,C說向右5cm,那就取個均值,向右1。5cm。然後再問(B, D),這樣的話減少了極端情況(前後兩次迭代差異巨大)這種情況的發生,能更好更快的完成遊戲。
每次全問一遍,然後取均值,這樣每次移動的方向都是所有人決定的均值,這樣的話,最後就是哪邊的小朋友多最終結果就被很快的拉向哪邊了。(梯度方向不變,限於極小值)
科學版回答
就用MINST做一下實驗吧(程式碼主要轉自
http://
cnblogs。com/jiangnanyan
):
實驗環境:
1080ti * 1
Pytorch 0。4。1
超引數:SGD(lr = 0。02, momentum=0。5) 偷懶沒有根據batch size細調
我們先建立一個簡單的模型:
from torch。nn import *
import torch。nn。functional as F
class SimpleModel(Module):
def __init__(self):
super(SimpleModel, self)。__init__()
self。conv1 = Conv2d(in_channels=1, out_channels=10, kernel_size=5)
self。conv2 = Conv2d(10, 20, 5)
self。conv3 = Conv2d(20, 40, 3)
self。mp = MaxPool2d(2)
self。fc = Linear(40, 10)
def forward(self, x):
in_size = x。size(0)
x = F。relu(self。mp(self。conv1(x)))
x = F。relu(self。mp(self。conv2(x)))
x = F。relu(self。mp(self。conv3(x)))
x = x。view(in_size, -1)
x = self。fc(x)
print(x。size())
return F。log_softmax(x, dim=1)
然後把MINST加載出來訓練一下:
import time
import torch
import torch。nn as nn
import torch。nn。functional as F
import torch。optim as optim
import os
from torchvision import datasets, transforms
from simple_model import SimpleModel
os。environ[‘CUDA_VISIBLE_DEVICES’] = “0”
use_cuda = torch。cuda。is_available()
batch_size = 6
lr = 1e-2
# MNIST Dataset
train_dataset = datasets。MNIST(root=‘。/data/’,
train=True,
transform=transforms。ToTensor(),
download=True)
test_dataset = datasets。MNIST(root=‘。/data/’,
train=False,
transform=transforms。ToTensor())
# Data Loader (Input Pipeline)
train_loader = torch。utils。data。DataLoader(dataset=train_dataset,
batch_size=batch_size,
shuffle=True)
test_loader = torch。utils。data。DataLoader(dataset=test_dataset,
batch_size=batch_size,
shuffle=False)
model = SimpleModel()
optimizer = optim。SGD(model。parameters(), lr=lr, momentum=0。5)
if use_cuda:
model = nn。DataParallel(model)。cuda()
iter_losses = []
def train(epoch):
model。train()
total_loss = 0
compution_time = 0
e_sp = time。time()
for batch_idx, (data, target) in enumerate(train_loader):
if use_cuda:
data = data。cuda()
target = target。cuda()
b_sp = time。time()
output = model(data)
loss = F。nll_loss(output, target)
optimizer。zero_grad()
loss。backward()
optimizer。step()
compution_time += time。time() - b_sp
# optimizer。step()
epoch_time = time。time() - e_sp
print(‘Train Epoch: {} \t Loss: {:。6f}\t epoch time: {:。6f} s\t epoch compution time: {:。6f} s’。format(
epoch, total_loss / len(train_loader), epoch_time, compution_time))
return total_loss / len(train_loader)
def test():
model。eval()
with torch。no_grad():
test_loss = 0
correct = 0
for data, target in test_loader:
if use_cuda:
data = data。cuda()
target = target。cuda()
output = model(data)
# sum up batch loss
test_loss += F。nll_loss(output, target)。item()
# get the index of the max log-probability
pred = output。data。max(1, keepdim=True)[1]
correct += pred。eq(target。data。view_as(pred))。cpu()。sum()
test_loss /= len(test_loader)
print(‘\nTest set: Average loss: {:。4f}, Accuracy: {}/{} ({:。0f}%)\n’。format(
test_loss, correct, len(test_loader。dataset),
100。 * correct / len(test_loader。dataset)))
return test_loss, 100。 * correct。item() / len(test_loader。dataset)
if __name__ == “__main__”:
for epoch in range(1, 10000):
train_l = train(epoch)
val_l, val_a = test()
我們從以下指標來看一下不同batch size之間的區別:
迭代速度
感覺之前做的實驗有點不太科學,重新捋了一下思路,把時間計算的程式碼也放到了前面的程式碼之中,有興趣的同學也可以自己做一下看看。
(表中 Epoch Time是在此batch size下完成一個epoch所需的所有時間,包括載入資料和計算的時間,Epoch Computation Time拋去了載入資料所需的時間。)
(時間確實是有偏量,上面的資料可以大體做個參考,要做科學考究的話,還是要多做幾次實驗求均值減少偏差。)
其實純粹cuda計算的角度來看,完成每個iter的時間大batch和小batch區別並不大,這可能是因為本次實驗中,反向傳播的時間消耗要比正向傳播大得多,所以batch size的大小對每個iter所需的時間影響不明顯,未來將在大一點的資料庫和更復雜的模型上做一下實驗。(因為反向的過程取決於模型的複雜度,與batchsize的大小關係不大,而正向則同時取決於模型的複雜度和batch size的大小。而本次實驗中反向的過程要比正向的過程時間消耗大得多,所以batch size的大小對完成每個iter所需的耗時影響不大。)
完成每個epoch運算的所需的全部時間主要卡在:1。 load資料的時間,2。 每個epoch的iter數量。因此對於每個epoch,不管是純計算時間還是全部時間,大體上還是大batch能夠更節約時間一點,但隨著batch增大,iter次數減小,完成每個epoch的時間更取決於載入資料所需的時間,此時也不見得大batch能帶來多少的速度增益了。
梯度平滑程度
我們再來看一下不同batch size下的梯度的平滑程度,我們選取了每個batch size下前1000個iter的loss,來看一下loss的震盪情況,結果如下圖所示:
如果感覺這張圖不太好看,可以看一下這張圖:
由於現在絕大多數的框架在進行mini-batch的反向傳播的時候,預設都是將batch中每個instance的loss平均化之後在進行反向傳播,所以相對大一點的batch size能夠防止loss震盪的情況發生。從這兩張圖中可以看出batch size越小,相鄰iter之間的loss震盪就越厲害,相應的,反傳回去的梯度的變化也就越大,也就越不利於收斂。同時很有意思的一個現象,batch size為1的時候,loss到後期會發生爆炸,這主要是lr=0。02設定太大,所以某個異常值的出現會嚴重擾動到訓練過程。這也是為什麼對於較小的batchsize,要設定小lr的原因之一,避免異常值對結果造成的擾巨大擾動。而對於較大的batchsize,要設定大一點的lr的原因則是大batch每次迭代的梯度方向相對固定,大lr可以加速其收斂過程。
收斂速度
在衡量不同batch size的優劣這一點上,我選用衡量不同batch size在同樣引數下的收斂速度快慢的方法。
下表中可以看出,在minst資料集上,從整體時間消耗上來看(考慮了載入資料所需的時間),同樣的引數策略下 (lr = 0。02, momentum=0。5 ),要模型收斂到accuracy在98左右,batchsize在 6 - 60 這個量級能夠花費最少的時間,而batchsize為1的時候,收斂不到98;batchsize過大的時候,因為模型收斂快慢取決於梯度方向和更新次數,所以大batch儘管梯度方向更為穩定,但要達到98的accuracy所需的更新次數並沒有量級上的減少,所以也就需要花費更多的時間,當然這種情況下可以配合一些調參策略比如warmup LR,衰減LR等等之類的在一定程度上進行解決(這個先暫且按下不表),但也不會有本質上的改善。
不過單純從計算時間上來看,大batch還是可以很明顯地節約所需的計算時間的,原因前面講過了,主要因為本次實驗中純計算時間中,反向佔的時間比重遠大於正向。
(我一直覺得直接比較不同batch size下的絕對收斂精度來衡量batch size的好壞是沒有太大意義的,因為不同的batch size要配合不同的調參策略用才能達到其最佳效果,而要想在每個batch size下都找到合適的調參策略那可太難了,所以用這種方法來決定batch size未免有點武斷。)