從代碼層次理解Caffe的實現(xiàn),從而實現(xiàn)新功能的定制
本文作者薛云峰,主要從事視頻圖像算法的研究,于浙江捷尚視覺科技股份有限公司擔(dān)任深度學(xué)習(xí)算法研究員。
相信很多小伙伴和我一樣使用了很長時間的Caffe深度學(xué)習(xí)框架,也非常希望從代碼層次理解Caffe的實現(xiàn)從而實現(xiàn)新功能的定制。本文將從整體架構(gòu)和底層實現(xiàn)的視角,對Caffe源碼進行解析。
1.Caffe總體架構(gòu)Caffe框架主要有五個組件,Blob,Solver,Net,Layer,Proto,其結(jié)構(gòu)圖如下圖1所示。Solver負責(zé)深度網(wǎng)絡(luò)的訓(xùn)練,每個Solver中包含一個訓(xùn)練網(wǎng)絡(luò)對象和一個測試網(wǎng)絡(luò)對象。每個網(wǎng)絡(luò)則由若干個Layer構(gòu)成。每個Layer的輸入和輸出Feature map表示為Input Blob和Output Blob。Blob是Caffe實際存儲數(shù)據(jù)的結(jié)構(gòu),是一個不定維的矩陣,在Caffe中一般用來表示一個拉直的四維矩陣,四個維度分別對應(yīng)Batch Size(N),F(xiàn)eature Map的通道數(shù)(C),F(xiàn)eature Map高度(H)和寬度(W)。Proto則基于Google的Protobuf開源項目,是一種類似XML的數(shù)據(jù)交換格式,用戶只需要按格式定義對象的數(shù)據(jù)成員,可以在多種語言中實現(xiàn)對象的序列化與反序列化,在Caffe中用于網(wǎng)絡(luò)模型的結(jié)構(gòu)定義、存儲和讀齲
2.Blob解析
下面介紹Caffe中的基本數(shù)據(jù)存儲類Blob。Blob使用SyncedMemory類進行數(shù)據(jù)存儲,數(shù)據(jù)成員data_指向?qū)嶋H存儲數(shù)據(jù)的內(nèi)存或顯存塊,shape_存儲了當(dāng)前blob的維度信息,diff_這個保存了反向傳遞時候的梯度信息。在Blob中其實不是只有num,channel,height,width這種四維形式,它是一個不定維度的數(shù)據(jù)結(jié)構(gòu),將數(shù)據(jù)展開存儲,而維度單獨存在一個vector 類型的shape_變量中,這樣每個維度都可以任意變化。
來一起看看Blob的關(guān)鍵函數(shù),data_at這個函數(shù)可以讀取的存儲在此類中的數(shù)據(jù),diff_at可以用來讀取反向傳回來的誤差。順便給個提示,盡量使用data_at(const vector& index)來查找數(shù)據(jù)。Reshape函數(shù)可以修改blob的存儲大小,count用來返回存儲數(shù)據(jù)的數(shù)量。BlobProto類負責(zé)了將Blob數(shù)據(jù)進行打包序列化到Caffe的模型中。
3.工廠模式說明接下來介紹一種設(shè)計模式Factory Pattern,Caffe中Solver和Layer對象的創(chuàng)建均使用了此模式,首先看工廠模式的UML的類圖:
如同F(xiàn)actory生成同一功能但是不同型號產(chǎn)品一樣,這些產(chǎn)品實現(xiàn)了同樣OperaTIon,很多人看了工廠模式的代碼,會產(chǎn)生這樣的疑問為何不new一個出來呢,這樣new一個出來似乎也沒什么問題吧。試想如下情況,由于代碼重構(gòu)類的名稱改了,或者構(gòu)造函數(shù)參數(shù)變化(增加或減少參數(shù))。而你代碼中又有N處new了這個類。如果你又沒用工廠,就只能一個一個找來改。工廠模式的作用就是讓使用者減少對產(chǎn)品本身的了解,降低使用難度。如果用工廠,只需要修改工廠類的創(chuàng)建具體對象方法的實現(xiàn),而其他代碼不會受到影響。
舉個例子,寫代碼少不得餓了要加班去吃夜宵,麥當(dāng)勞的雞翅和肯德基的雞翅都是MM愛吃的東西,雖然口味有所不同,但不管你帶MM去麥當(dāng)勞或肯德基,只管向服務(wù)員說“來四個雞翅”就行了。麥當(dāng)勞和肯德基就是生產(chǎn)雞翅的Factory。
4.Solver解析接下來切回正題,我們看看Solver這個優(yōu)化對象在Caffe中是如何實現(xiàn)的。SolverRegistry這個類就是我們看到的上面的factory類,負責(zé)給我們一個優(yōu)化算法的產(chǎn)品,外部只需要把數(shù)據(jù)和網(wǎng)絡(luò)結(jié)構(gòu)定義好,它就可以自己優(yōu)化了。
Solver* CreateSolver(const SolverParameter& param)這個函數(shù)就是工廠模式下的CreateProduct的操作, Caffe中這個SolverRegistry工廠類可以提供給我們6種產(chǎn)品(優(yōu)化算法):
這六種產(chǎn)品的功能都是實現(xiàn)網(wǎng)絡(luò)的參數(shù)更新,只是實現(xiàn)方式不一樣。那我們來看看他們的使用流程吧。當(dāng)然這些產(chǎn)品類似上面Product類中的OperaTIon,每一個Solver都會繼承Solve和Step函數(shù),而每個Solver中獨有的僅僅是ApplyUpdate這個函數(shù)里面執(zhí)行的內(nèi)容不一樣,接口是一致的,這也和我們之前說的工廠生產(chǎn)出來的產(chǎn)品一樣功能一樣,細節(jié)上有差異,比如大多數(shù)電飯煲都有煮飯的功能,但是每一種電飯煲煮飯的加熱方式可能不同,有底盤加熱的還有立體加熱的等。接下里我們看看Solver中的關(guān)鍵函數(shù)。
Solver中Solve函數(shù)的流程圖如下:
Solver類中Step函數(shù)流程圖:
Solver中關(guān)鍵的就是調(diào)用Sovle函數(shù)和Step函數(shù)的流程,你只需要對照Solver類中兩個函數(shù)的具體實現(xiàn),看懂上面兩個流程圖就可以理解Caffe訓(xùn)練執(zhí)行的過程了。
5.Net類解析分析過Solver之后我們來分析下Net類的一些關(guān)鍵操作。這個是我們使用Proto創(chuàng)建出來的深度網(wǎng)絡(luò)對象,這個類負責(zé)了深度網(wǎng)絡(luò)的前向和反向傳遞。以下是Net類的初始化方法NeTInit函數(shù)調(diào)用流程:
Net的類中的關(guān)鍵函數(shù)簡單剖析:
1.ForwardBackward:按順序調(diào)用了Forward和Backward。
2.ForwardFromTo(int start, int end):執(zhí)行從start層到end層的前向傳遞,采用簡單的for循環(huán)調(diào)用。
3.BackwardFromTo(int start, int end):和前面的ForwardFromTo函數(shù)類似,調(diào)用從start層到end層的反向傳遞。
4.ToProto函數(shù)完成網(wǎng)絡(luò)的序列化到文件,循環(huán)調(diào)用了每個層的ToProto函數(shù)。
6.Layer解析Layer是Net的基本組成單元,例如一個卷積層或一個Pooling層。本小節(jié)將介紹Layer類的實現(xiàn)。
(1)Layer的繼承結(jié)構(gòu)
(2)Layer的創(chuàng)建
與Solver的創(chuàng)建方式很像,Layer的創(chuàng)建使用的也是工廠模式,這里簡單說明下幾個宏函數(shù):
REGISTER_LAYER_CREATOR負責(zé)將創(chuàng)建層的函數(shù)放入LayerRegistry。
我們來看看大多數(shù)層創(chuàng)建的函數(shù)的生成宏REGISTER_LAYER_CLASS,可以看到宏函數(shù)比較簡單的,將類型作為函數(shù)名稱的一部分,這樣就可以產(chǎn)生出一個創(chuàng)建函數(shù),并將創(chuàng)建函數(shù)放入LayerRegistry。
REGISTER_LAYER_CREATOR(type, Creator_##type##Layer)
這段代碼在split_layer.cpp文件中
REGISTER_LAYER_CLASS(Split)。
這樣我們將type替換過以后給大家做個范例,參考下面的代碼。
當(dāng)然這里的創(chuàng)建函數(shù)好像是直接調(diào)用,沒有涉及到我們之前工廠模式的一些問題。所有的層的類都是這樣嗎?當(dāng)然不是,我們仔細觀察卷積類。
卷積層怎么沒有創(chuàng)建函數(shù)呢,當(dāng)然不是,卷積的層的創(chuàng)建函數(shù)在LayerFactory.cpp中,截圖給大家看下,具體代碼如下:
這樣兩種類型的Layer的創(chuàng)建函數(shù)都有了對應(yīng)的聲明。這里直接說明除了有cudnn實現(xiàn)的層,其他層都是采用第一種方式實現(xiàn)的創(chuàng)建函數(shù),而帶有cudnn實現(xiàn)的層都采用的第二種方式實現(xiàn)的創(chuàng)建函數(shù)。
(3)Layer的初始化
介紹完創(chuàng)建我們看看層里面的幾個函數(shù)都是什么時候被調(diào)用的。
關(guān)鍵函數(shù)Setup此函數(shù)在之前的流程圖中的NeTInit時候被調(diào)用,代碼如下:
這樣整個Layer初始化的過程中,CheckBlobCounts被最先調(diào)用,然后接下來是LayerSetUp,后面才是Reshape,最后才是SetLossWeights。這樣Layer初始化的生命周期大家就有了了解。
(4)Layer的其他函數(shù)的介紹
Layer的Forward函數(shù)和Backward函數(shù)完成了網(wǎng)絡(luò)的前向和反向傳遞,這兩個函數(shù)在自己實現(xiàn)新的層必須要實現(xiàn)。其中Backward會修改bottom中blob的diff_,這樣就完成了誤差的方向傳導(dǎo)。
7.Protobuf介紹Caffe中的Caffe.proto文件負責(zé)了整個Caffe網(wǎng)絡(luò)的構(gòu)建,又負責(zé)了Caffemodel的存儲和讀齲下面用一個例子介紹Protobuf的工作方式。
利用protobuffer工具存儲512維度圖像特征:
1.message編寫:新建txt文件后綴名改為proto,編寫自己的message如下,并放入解壓的protobuff的文件夾里;
其中,dwFaceFeatSize表示特征點數(shù)量;pfFaceFeat表示人臉特征。
2.打開windows命令窗口(cmd.exe)---->cd空格,把protobuff的文件路徑復(fù)制粘貼進去------>enter;
3.輸入指令protoc *.proto --cpp_out=. --------->enter
4.可以看到文件夾里面生成“ *.pb.h”和“*.pb.cpp”兩個文件,說明成功了
5.下面可以和自己的代碼整合了:
(1) 新建你自己的工程,把“ *.pb.h”和“*.pb.cpp”兩個文件添加到自己的工程里,并寫上#include" *.pb.h"
(2) 按照配庫的教程把庫配置下就可以了。
VS下Protobuf的配庫方法:
解決方案---->右擊工程名---->屬性
使用protobuf進行打包的方法如下代碼:
(1)Caffe的模型序列化
BlobProto其實就是Blob序列化成Proto的類,Caffe模型文件使用了該類。Net調(diào)用每個層的Toproto方法,每個層的Toproto方法調(diào)用了Blob類的ToProto方法,這樣完整的模型就被都序列化到proto里面了。最后只要將這個proto繼承于message類的對象序列化到文件就完成了模型寫入文件。Caffe打包模型的時候就只是簡單調(diào)用了WriteProtoToBinaryFile這個函數(shù),而這個函數(shù)里面的內(nèi)容如下:
至此Caffe的序列化模型的方式就完成了。
(2)Proto.txt的簡單說明
Caffe網(wǎng)絡(luò)的構(gòu)建和Solver的參數(shù)定義均由此類型文件完成。Net構(gòu)建過程中調(diào)用ReadProtoFromTextFile將所有的網(wǎng)絡(luò)參數(shù)讀入。然后調(diào)用上面的流程進行整個caffe網(wǎng)絡(luò)的構(gòu)建。這個文件決定了怎樣使用存在caffe model中的每個blob是用來做什么的,如果沒有了這個文件caffe的模型文件將無法使用,因為模型中只存儲了各種各樣的blob數(shù)據(jù),里面只有float值,而怎樣切分這些數(shù)據(jù)是由prototxt文件決定的。
Caffe的架構(gòu)在框架上采用了反射機制去動態(tài)創(chuàng)建層來構(gòu)建Net,Protobuf本質(zhì)上定義了graph,反射機制是由宏配合map結(jié)構(gòu)形成的,然后使用工廠模式去實現(xiàn)各種各樣層的創(chuàng)建,當(dāng)然區(qū)別于一般定義配置采用xml或者json,該項目的寫法采用了proto文件對組件進行組裝。
總結(jié)
以上為Caffe代碼架構(gòu)的一個總體介紹,希望能借此幫助小伙伴找到打開定制化Caffe大門的鑰匙。本文作者希望借此拋磚引玉,與更多期望了解Caffe和深度學(xué)習(xí)框架底層實現(xiàn)的同行交流。