境配置到MNIST實戰(zhàn)避坑指南)
簡介面向Windows平臺的Caffe深度學(xué)習(xí)框架資源包主要服務(wù)于需要在Windows環(huán)境中安裝、編譯和使用Caffe的深度學(xué)習(xí)開發(fā)者、科研人員及學(xué)生能夠顯著降低環(huán)境搭建門檻。壓縮包共包含888個文件容量約8.67MB文件類型覆蓋C源碼cpp/hpp、CUDA加速代碼cu/cuh、模型配置文件prototxt、Python與MATLAB腳本、CMake構(gòu)建腳本以及Visual Studio工程文件等從底層實現(xiàn)到上層調(diào)用均有涉及。目前已有292人學(xué)習(xí)下載目錄組織清晰適合不同基礎(chǔ)的用戶按需查閱。包內(nèi)不僅包含編譯好的可執(zhí)行程序和依賴庫還提供了構(gòu)建配置、依賴檢測腳本、測試用例和示例工程能夠幫助用戶快速理解Windows下Caffe的編譯流程與文件間的關(guān)系在遇到配置問題時也能借助相關(guān)腳本定位原因。對于希望在非Linux平臺開展深度學(xué)習(xí)實驗的讀者這份資源具備較強的實用性和參考價值。 直接在Windows上把Caffe跑起來這事兒擱現(xiàn)在依然是不少人的心頭痛。明明是個深度學(xué)習(xí)框架裝起來卻像在搞硬件驅(qū)動動不動就編譯失敗報一堆宏錯誤。但你如果是因為老項目、課程作業(yè)、或者某些只提供了Caffe模型權(quán)重的算法源碼不得不回頭用Caffe那這篇文章就是給你準(zhǔn)備的。我用自己的經(jīng)歷幫你把caffe-windows這條路捋清楚告訴你哪些坑可以繞開哪些細(xì)節(jié)必須死磕。先說清楚Caffe是什么。它全稱是Convolutional Architecture for Fast Feature Embedding由伯克利視覺與學(xué)習(xí)中心BAIR開發(fā)在深度學(xué)習(xí)剛火起來那幾年幾乎是工業(yè)界和學(xué)術(shù)界用CNN做圖像分類、目標(biāo)檢測的事實標(biāo)準(zhǔn)。后來PyTorch和TensorFlow出來之后Caffe的社區(qū)熱度下降不少但它的經(jīng)典地位還在大量老模型文件.caffemodel和網(wǎng)絡(luò)定義文件.prototxt仍然活躍在產(chǎn)線上。你如果拿到一個老模型想在新機(jī)器上推理或者在一臺Windows機(jī)器上復(fù)現(xiàn)師兄的實驗就得把Caffe這套老工具鏈重新搭起來。我在前兩年因為一個OCR項目的維護(hù)需求被迫在一臺Windows Server上編譯Caffe整個過程踩了無數(shù)坑?，F(xiàn)在回頭看很多問題其實可以避免。這篇文章從環(huán)境配置講到編譯實操再到訓(xùn)練一個MNIST驗證全流程最后附上常見問題排查表按順序走一遍你就能在Windows上把Caffe正常用起來。1. 項目定位為什么非要在Windows上折騰Caffe1.1 Caffe的核心設(shè)計思路與適用場景Caffe的設(shè)計哲學(xué)和現(xiàn)代框架差別很大。它把自己的核心抽象成了四個層Blob數(shù)據(jù)存儲、Layer計算單元、Net網(wǎng)絡(luò)結(jié)構(gòu)、Solver訓(xùn)練策略算法實現(xiàn)。你在Caffe里定義一個網(wǎng)絡(luò)不用寫代碼而是用一個純文本的.prototxt文件去描述網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。比如你用層類型Convolution、Pooling再指定bottom和topCaffe就會自動把這些層串成一幅計算圖。這個設(shè)計的好處是做實驗時想改網(wǎng)絡(luò)結(jié)構(gòu)改一個文本文件就行不用重新編譯整個項目。所以Caffe特別適合兩類人一類是做視覺算法研究、需要大量快速迭代網(wǎng)絡(luò)結(jié)構(gòu)的人另一類是手上有老模型權(quán)重需要在新環(huán)境下做推理部署的人。它不像PyTorch那樣“什么都得自己在Python里搭”Caffe把大部分事情都固化在C層跑起來比當(dāng)時的Python框架快很多尤其適合在嵌入式設(shè)備或服務(wù)器上批量跑圖片任務(wù)。1.2 為什么Windows移植版本是一個“獨立大陸”Caffe原生從Linux起家代碼里大量使用了POSIX接口比如文件鎖、dirent.h、unistd.h這類在Windows上根本不存在的頭文件。官方源碼的Windows分支長期處于“能用但沒人維護(hù)”的狀態(tài)。后來微軟內(nèi)部有人牽頭做了microsoft/caffe這個Windows遷移版后來社區(qū)里也陸續(xù)冒出一些fork。這些版本的共同點是改寫了底層文件操作和系統(tǒng)調(diào)用把所有第三方依賴boost、glog、gflags、protobuf、hdf5、leveldb等統(tǒng)一用NuGet或腳本拉取再通過CMake或Visual Studio的屬性表.props來組織構(gòu)建系統(tǒng)。這件事的本質(zhì)是你拿到的caffe-windows并不是一個普通源碼包它是一套“已經(jīng)被改造成Windows工程”的解決方案。你用Linux上那種“./configure make”的思路去套必死。在Windows上編譯Caffe核心就兩件事把依賴配齊、把構(gòu)建系統(tǒng)認(rèn)準(zhǔn)別自己發(fā)明流程。我接下來要講的每一步都是圍繞這兩件事展開的。2. 環(huán)境準(zhǔn)備版本匹配是生死線2.1 Visual Studio、CUDA、cuDNN的版本矩陣在Windows上編Caffe最容易翻車的就是版本不匹配。不是說拿最新版Visual Studio和最新版CUDA就能編過恰恰相反越新越容易失敗。Caffe-Windows項目在GitHub上有明確的版本對應(yīng)關(guān)系我這個項目用的是CUDA 8.0 cuDNN 5.1 Visual Studio 2013/2015。這套組合雖然老卻是微軟官方驗證過最穩(wěn)定的一套。如果你用VS2017或者更高版本去編譯老源碼會在Protobuf生成代碼、CUDA編譯參數(shù)等環(huán)節(jié)遇到成片報錯比如“C1001編譯器內(nèi)部錯誤”“錯誤C2220”改到心態(tài)爆炸。我個人的建議是如果不是非要在這臺機(jī)器上跑CUDA 11以上版本的項目盡量不要升級。我見過有人用VS2019硬編英文老版本最后改了兩百多行源碼才編過完全不值得。專門為Caffe這個項目準(zhǔn)備一個獨立的、版本適配的環(huán)境是成本最低的選擇。如果你電腦空間足夠裝一個VS2015和一個老版本CUDA和你的現(xiàn)代開發(fā)環(huán)境共存完全沒問題。2.2 依賴庫的三種獲取方式老版本Caffe-Windows的依賴庫可以從項目管網(wǎng)下載到預(yù)編譯包文件名通常是libraries_v140_x64_py35_1.1.0.tar.bz2這種格式。這個壓縮包里面已經(jīng)編譯好了boost、glog、gflags、protobuf、hdf5、leveldb、lmdb等一整套第三方庫解壓到指定目錄就行。還有第二種方式是用NuGet自動拉取打開項目目錄下的Caffe.sln之前先執(zhí)行NuGet Restore系統(tǒng)會按照packages.config把依賴下載到項目根目錄的packages文件夾里。第三種方式是自己手動編譯每個依賴這種方式最靈活但工程量太大我只在需要定制某個庫版本的時候才用。我實際用下來NuGet 預(yù)編譯包混合的方式最靠譜。你先解壓預(yù)編譯包把目錄名改為libraries放在Caffe工程根目錄下再執(zhí)行NuGet Restore最后用CMake生成工程時它會自動去libraries目錄里找頭文件和lib文件。順序不能反如果先執(zhí)行CMake再解壓庫CMake配置階段找不到庫就會報錯。3. 源碼編譯從CMake到ALL_BUILD的完整過程3.1 拿到源碼并確認(rèn)目錄結(jié)構(gòu)第一步把microsoft/caffe這個倉庫的源碼clone下來。官方倉庫下有一個Windows文件夾里面有批處理腳本還有CommonSettings.props這個核心配置文件。整個目錄結(jié)構(gòu)我覺得有必要解釋一下因為很多新手會把文件放錯位置導(dǎo)致路徑出問題。倉庫根目錄下主要包含cmake存放CMake相關(guān)模塊負(fù)責(zé)找第三方庫include與srcCaffe的源碼本體包含caffe的頭文件和cpp文件tools編譯后會生成caffe.exe等可執(zhí)行工具pythonpycaffe的Python接口代碼models經(jīng)典的模型定義與權(quán)重下載地址examples官方示例其中mnist文件夾就是我們后面要用的手寫數(shù)字示例還有CommonSettings.props和Caffe.sln這兩個Windows工程核心文件3.2 編輯CommonSettings.props編譯前必須修改CommonSettings.props這個文件。它是一個MSBuild的屬性表定義了整個編譯過程中的關(guān)鍵宏。你需要按自己的環(huán)境開啟或關(guān)閉相應(yīng)的配置項。比如如果只用CPU環(huán)境把CpuOnlyBuild這個標(biāo)簽從false改為true這樣就不需要CUDA了如果要帶Python接口把PythonSupport從false改為true并且根據(jù)你裝的Python版本把PythonDir指向?qū)嶋H路徑比如C:\Python35要注意CUDA版本對應(yīng)的CUDA_PATH環(huán)境變量VS會自動讀取我寫過一篇總結(jié)建議第一次編譯時盡量先關(guān)掉Python和Matlab支持只編C核心等跑通了再加擴(kuò)展接口。這樣做是因為Python接口要額外編譯pycaffe的入口Matlab接口需要去配Mex文件如果這些一起編出錯時日志會非常長很難定位問題。3.3 CMake生成VS工程在項目根目錄執(zhí)行CMake用CMake GUI或者命令行都行。關(guān)鍵參數(shù)是指定源碼目錄和構(gòu)建目錄build文件夾指定Visual Studio生成器比如Visual Studio 14 2015 Win64勾選或設(shè)置Python相關(guān)的選項如果第2步關(guān)閉了PythonSupport這里也可以不勾CMake配置階段如果提示找不到某些庫基本都是因為libraries預(yù)編譯包沒放對位置或者版本不對。它找到所有依賴項后就會生成Caffe.sln和一堆.vcxproj項目文件。這一步的報錯通常和路徑有關(guān)解決方案就是檢查libraries目錄是否存在、環(huán)境變量CUDA_PATH是否指向正確路徑。3.4 編譯并生成caffe.exe用Visual Studio打開生成的Caffe.sln在解決方案管理器里找到ALL_BUILD項目右鍵選擇生成。第一次編譯Caffe會花很長時間因為要編譯數(shù)百個源文件還有Protobuf的生成代碼。如果你是四核以上的CPU可以在CMake時開啟多線程編譯或者直接在VS里調(diào)整“項目屬性 - C/C - 命令行”加上/MP參數(shù)。我自己用的是八核機(jī)器開啟多線程后大概20多分鐘能編完。編譯完成后所有可執(zhí)行文件會生成在build目錄下的x64/Release里其中包括caffe.exe這是Caffe的命令行入口。同時也會生成libcaffe.lib靜態(tài)庫和對應(yīng)的頭文件。到這里核心部分就編譯成功了。4. 實際驗證用MNIST快速跑通第一個模型4.1 準(zhǔn)備MNIST數(shù)據(jù)集Caffe官方提供了一個腳本get_mnist.bat位于examples/mnist文件夾里。運行它之后會自動從網(wǎng)上下載MNIST數(shù)據(jù)集并且調(diào)用convert_mnist_data.exe把原始二進(jìn)制文件轉(zhuǎn)成Caffe能夠直接讀取的LMDB格式數(shù)據(jù)庫。這個轉(zhuǎn)換過程要注意如果你編譯時不帶LMDB支持轉(zhuǎn)換工具就生成不了所以前面編譯依賴時一定要檢查leveldb和lmdb這兩個庫是否編譯進(jìn)去。轉(zhuǎn)完之后會在examples/mnist文件夾下生成mnist_train_lmdb和mnist_test_lmdb兩個文件夾。這兩個文件夾就是標(biāo)準(zhǔn)的數(shù)據(jù)源網(wǎng)絡(luò)定義文件里會引用它們。4.2 給出LeNet網(wǎng)絡(luò)定義和Solver配置Caffe官方在examples/mnist文件夾里已經(jīng)提供了兩個核心文件lenet_train_test.prototxt和lenet_solver.prototxt。前者定義了LeNet網(wǎng)絡(luò)結(jié)構(gòu)一個卷積層、一個池化層、再一個卷積層、一個池化層最后接兩個全連接層后者是訓(xùn)練超參數(shù)的配置。我截取lenet_solver.prototxt里最關(guān)鍵的一段來分析net: examples/mnist/lenet_train_test.prototxt test_iter: 100 test_interval: 500 base_lr: 0.01 momentum: 0.9 weight_decay: 0.0005 lr_policy: inv gamma: 0.0001 power: 0.75 max_iter: 10000 display: 100 type: SGD solver_mode: GPU這里的base_lr是初始學(xué)習(xí)率0.01是個經(jīng)驗值用SGD做MNIST分類足夠。momentum設(shè)為0.9是沿用經(jīng)典策略目的是在梯度更新時保留上一次更新的方向減少震蕩。weight_decay設(shè)為0.0005是常用的L2正則化參數(shù)防止過擬合。max_iter設(shè)為10000表示訓(xùn)練一萬步。4.3 執(zhí)行訓(xùn)練并解讀日志輸出在命令行中運行caffe.exe train --solverexamples/mnist/lenet_solver.prototxt如果你是CPU編譯版本記得先把solver_mode改成CPU。跑起來之后你會看到每100次迭代輸出一次當(dāng)前l(fā)oss比如I1012 10:23:45.678901 1234 solver.cpp:245] Iteration 100, loss 0.6234 I1012 10:23:45.678902 1234 solver.cpp:271] Train net output #0: loss 0.6234 (* 1 0.6234 loss)loss從初期的2.3左右逐漸下降到一萬次迭代后基本能到0.02以下測試準(zhǔn)確率在99%附近。這時候你的Caffe Windows環(huán)境就正式驗證通過了。我實際操作時的經(jīng)驗是第一次跑最好盯著loss下降曲線如果發(fā)現(xiàn)loss卡住不動或者直接變成NaN先檢查學(xué)習(xí)率設(shè)置把base_lr調(diào)小10倍再試。還有prototxt里數(shù)據(jù)層的路徑如果是從其他機(jī)器復(fù)制過來的記得用絕對路徑或相對路徑保持正確。5. 常見問題與避坑經(jīng)驗我一次性幫你踩完5.1 編譯階段報錯速查表報錯信息可能原因解決方法找不到cuda_runtime.hCUDA未安裝或路徑不對檢查CUDA_PATH環(huán)境變量確認(rèn)CUDA版本與VS匹配cudnn.h找不到cuDNN未解壓到CUDA目錄把cuDNN的include和lib合并到CUDA安裝目錄MSB4062或MSB3723VS版本與CUDA工具集不兼容換用VS2013/2015搭配CUDA 8.0編譯Python接口失敗Python版本與依賴庫不匹配關(guān)閉PythonSupport先編核心LNK1104無法打開xxx.lib第三方庫路徑配置錯誤重新檢查libraries目錄路徑是否在VC庫目錄里5.2 運行階段出現(xiàn)的問題編譯成功后運行時還會遇到幾個非常典型的坑我把它們單獨拿出來說。第一個是找不到動態(tài)庫。編譯好的caffe.exe雙擊運行會閃退或者提示找不到cudart64_80.dll / cudnn64_5.dll。這是因為CUDA和cuDNN的bin目錄沒有加入系統(tǒng)PATH。你把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin加進(jìn)PATH并把cuDNN的bin目錄里的cudnn64_5.dll復(fù)制到CUDA的bin目錄即可解決。第二個是命令行運行提示“無法啟動此程序因為計算機(jī)中丟失libglog.dll”。這個問題說明編譯時選擇的運行庫是Debug版本或動態(tài)鏈接方式而運行時沒有把對應(yīng)的依賴庫一起帶過來。libraries預(yù)編譯包里的bin目錄有這些動態(tài)庫把它們加進(jìn)PATH或者拷貝到caffe.exe的同目錄下就解決了。第三個是prototxt路徑問題。運行時如果提示“Failed to open lmdb”或者“Check failed: file exists”要先檢查工作目錄。Caffe內(nèi)部解析相對路徑的口徑是以當(dāng)前命令行所在目錄為準(zhǔn)的所以如果你在build目錄下運行caffe.exe就記得用相對路徑時帶上源碼目錄名或者干脆用絕對路徑。5.3 性能相關(guān)的建議Caffe跑在Windows上的性能一般不如Linux這是文件系統(tǒng)機(jī)制和編譯優(yōu)化的差異導(dǎo)致的。我在同一臺機(jī)器上做過對比Windows上的推理速度大約是Linux的80%到90%如果開了CPU模式差距更明顯。所以如果項目對延遲特別敏感我建議把訓(xùn)練放在Linux服務(wù)器上Windows這邊只做模型轉(zhuǎn)換和簡單驗證。如果只能Windows上跑盡量把Caffe的編譯配置從Debug換成Release并從項目屬性里打開SSE2和AVX指令集優(yōu)化。5.4 Python接口的配置細(xì)節(jié)如果你需要pycaffe編譯完P(guān)ython支持后還需要把python目錄和build目錄里生成的caffe文件夾加入Python的搜索路徑。最簡單的方式是在系統(tǒng)環(huán)境變量PYTHONPATH里添加兩個路徑D:\caffe-windows\python D:\caffe-windows\build\x64\Release\pycaffe然后在終端測試import caffe print(caffe.__version__)如果能正常輸出版本號就說明接口沒問題。這里有個坑是Python版本位數(shù)必須是64位Python而且要和你編譯時PythonSupport指定的版本一致32位Python和64位Caffe庫絕對對不上。6. 寫在最后的個人經(jīng)驗我在折騰caffe-windows的過程中最深的一個感受是“老技術(shù)不等于過時但你得按老技術(shù)的規(guī)則來玩”。這個框架的代碼結(jié)構(gòu)和現(xiàn)代深度學(xué)習(xí)框架完全不同它對系統(tǒng)環(huán)境的假設(shè)非常死板一個版本號不對就可能失敗。但當(dāng)你真正跑通之后你會發(fā)現(xiàn)它的速度和可定制性仍然有自己的優(yōu)勢。如果你現(xiàn)在也在為某個老模型不得不編譯Caffe別急著換框架按我上面的步驟一步步來大概率能順利搞定。最后再分享一個小技巧如果你只做推理不做訓(xùn)練其實可以直接用caffe.exe test命令去跑測試配合訓(xùn)練好的權(quán)重文件比寫一堆Python代碼簡單得多。這也是Caffe作為命令行工具最被人忽視的優(yōu)點。本文還有配套的精品資源點擊獲取 Windows下編譯Caffe：從環(huán)境配置到MNIST實戰(zhàn)避坑指南
簡介面向Windows平臺的Caffe深度學(xué)習(xí)框架資源包主要服務(wù)于需要在Windows環(huán)境中安裝、編譯和使用Caffe的深度學(xué)習(xí)開發(fā)者、科研人員及學(xué)生能夠顯著降低環(huán)境搭建門檻。壓縮包共包含888個文件容量約8.67MB文件類型覆蓋C源碼cpp/hpp、CUDA加速代碼cu/cuh、模型配置文件prototxt、Python與MATLAB腳本、CMake構(gòu)建腳本以及Visual Studio工程文件等從底層實現(xiàn)到上層調(diào)用均有涉及。目前已有292人學(xué)習(xí)下載目錄組織清晰適合不同基礎(chǔ)的用戶按需查閱。包內(nèi)不僅包含編譯好的可執(zhí)行程序和依賴庫還提供了構(gòu)建配置、依賴檢測腳本、測試用例和示例工程能夠幫助用戶快速理解Windows下Caffe的編譯流程與文件間的關(guān)系在遇到配置問題時也能借助相關(guān)腳本定位原因。對于希望在非Linux平臺開展深度學(xué)習(xí)實驗的讀者這份資源具備較強的實用性和參考價值。 直接在Windows上把Caffe跑起來這事兒擱現(xiàn)在依然是不少人的心頭痛。明明是個深度學(xué)習(xí)框架裝起來卻像在搞硬件驅(qū)動動不動就編譯失敗報一堆宏錯誤。但你如果是因為老項目、課程作業(yè)、或者某些只提供了Caffe模型權(quán)重的算法源碼不得不回頭用Caffe那這篇文章就是給你準(zhǔn)備的。我用自己的經(jīng)歷幫你把caffe-windows這條路捋清楚告訴你哪些坑可以繞開哪些細(xì)節(jié)必須死磕。先說清楚Caffe是什么。它全稱是Convolutional Architecture for Fast Feature Embedding由伯克利視覺與學(xué)習(xí)中心BAIR開發(fā)在深度學(xué)習(xí)剛火起來那幾年幾乎是工業(yè)界和學(xué)術(shù)界用CNN做圖像分類、目標(biāo)檢測的事實標(biāo)準(zhǔn)。后來PyTorch和TensorFlow出來之后Caffe的社區(qū)熱度下降不少但它的經(jīng)典地位還在大量老模型文件.caffemodel和網(wǎng)絡(luò)定義文件.prototxt仍然活躍在產(chǎn)線上。你如果拿到一個老模型想在新機(jī)器上推理或者在一臺Windows機(jī)器上復(fù)現(xiàn)師兄的實驗就得把Caffe這套老工具鏈重新搭起來。我在前兩年因為一個OCR項目的維護(hù)需求被迫在一臺Windows Server上編譯Caffe整個過程踩了無數(shù)坑?，F(xiàn)在回頭看很多問題其實可以避免。這篇文章從環(huán)境配置講到編譯實操再到訓(xùn)練一個MNIST驗證全流程最后附上常見問題排查表按順序走一遍你就能在Windows上把Caffe正常用起來。1. 項目定位為什么非要在Windows上折騰Caffe1.1 Caffe的核心設(shè)計思路與適用場景Caffe的設(shè)計哲學(xué)和現(xiàn)代框架差別很大。它把自己的核心抽象成了四個層Blob數(shù)據(jù)存儲、Layer計算單元、Net網(wǎng)絡(luò)結(jié)構(gòu)、Solver訓(xùn)練策略算法實現(xiàn)。你在Caffe里定義一個網(wǎng)絡(luò)不用寫代碼而是用一個純文本的.prototxt文件去描述網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。比如你用層類型Convolution、Pooling再指定bottom和topCaffe就會自動把這些層串成一幅計算圖。這個設(shè)計的好處是做實驗時想改網(wǎng)絡(luò)結(jié)構(gòu)改一個文本文件就行不用重新編譯整個項目。所以Caffe特別適合兩類人一類是做視覺算法研究、需要大量快速迭代網(wǎng)絡(luò)結(jié)構(gòu)的人另一類是手上有老模型權(quán)重需要在新環(huán)境下做推理部署的人。它不像PyTorch那樣“什么都得自己在Python里搭”Caffe把大部分事情都固化在C層跑起來比當(dāng)時的Python框架快很多尤其適合在嵌入式設(shè)備或服務(wù)器上批量跑圖片任務(wù)。1.2 為什么Windows移植版本是一個“獨立大陸”Caffe原生從Linux起家代碼里大量使用了POSIX接口比如文件鎖、dirent.h、unistd.h這類在Windows上根本不存在的頭文件。官方源碼的Windows分支長期處于“能用但沒人維護(hù)”的狀態(tài)。后來微軟內(nèi)部有人牽頭做了microsoft/caffe這個Windows遷移版后來社區(qū)里也陸續(xù)冒出一些fork。這些版本的共同點是改寫了底層文件操作和系統(tǒng)調(diào)用把所有第三方依賴boost、glog、gflags、protobuf、hdf5、leveldb等統(tǒng)一用NuGet或腳本拉取再通過CMake或Visual Studio的屬性表.props來組織構(gòu)建系統(tǒng)。這件事的本質(zhì)是你拿到的caffe-windows并不是一個普通源碼包它是一套“已經(jīng)被改造成Windows工程”的解決方案。你用Linux上那種“./configure make”的思路去套必死。在Windows上編譯Caffe核心就兩件事把依賴配齊、把構(gòu)建系統(tǒng)認(rèn)準(zhǔn)別自己發(fā)明流程。我接下來要講的每一步都是圍繞這兩件事展開的。2. 環(huán)境準(zhǔn)備版本匹配是生死線2.1 Visual Studio、CUDA、cuDNN的版本矩陣在Windows上編Caffe最容易翻車的就是版本不匹配。不是說拿最新版Visual Studio和最新版CUDA就能編過恰恰相反越新越容易失敗。Caffe-Windows項目在GitHub上有明確的版本對應(yīng)關(guān)系我這個項目用的是CUDA 8.0 cuDNN 5.1 Visual Studio 2013/2015。這套組合雖然老卻是微軟官方驗證過最穩(wěn)定的一套。如果你用VS2017或者更高版本去編譯老源碼會在Protobuf生成代碼、CUDA編譯參數(shù)等環(huán)節(jié)遇到成片報錯比如“C1001編譯器內(nèi)部錯誤”“錯誤C2220”改到心態(tài)爆炸。我個人的建議是如果不是非要在這臺機(jī)器上跑CUDA 11以上版本的項目盡量不要升級。我見過有人用VS2019硬編英文老版本最后改了兩百多行源碼才編過完全不值得。專門為Caffe這個項目準(zhǔn)備一個獨立的、版本適配的環(huán)境是成本最低的選擇。如果你電腦空間足夠裝一個VS2015和一個老版本CUDA和你的現(xiàn)代開發(fā)環(huán)境共存完全沒問題。2.2 依賴庫的三種獲取方式老版本Caffe-Windows的依賴庫可以從項目管網(wǎng)下載到預(yù)編譯包文件名通常是libraries_v140_x64_py35_1.1.0.tar.bz2這種格式。這個壓縮包里面已經(jīng)編譯好了boost、glog、gflags、protobuf、hdf5、leveldb、lmdb等一整套第三方庫解壓到指定目錄就行。還有第二種方式是用NuGet自動拉取打開項目目錄下的Caffe.sln之前先執(zhí)行NuGet Restore系統(tǒng)會按照packages.config把依賴下載到項目根目錄的packages文件夾里。第三種方式是自己手動編譯每個依賴這種方式最靈活但工程量太大我只在需要定制某個庫版本的時候才用。我實際用下來NuGet 預(yù)編譯包混合的方式最靠譜。你先解壓預(yù)編譯包把目錄名改為libraries放在Caffe工程根目錄下再執(zhí)行NuGet Restore最后用CMake生成工程時它會自動去libraries目錄里找頭文件和lib文件。順序不能反如果先執(zhí)行CMake再解壓庫CMake配置階段找不到庫就會報錯。3. 源碼編譯從CMake到ALL_BUILD的完整過程3.1 拿到源碼并確認(rèn)目錄結(jié)構(gòu)第一步把microsoft/caffe這個倉庫的源碼clone下來。官方倉庫下有一個Windows文件夾里面有批處理腳本還有CommonSettings.props這個核心配置文件。整個目錄結(jié)構(gòu)我覺得有必要解釋一下因為很多新手會把文件放錯位置導(dǎo)致路徑出問題。倉庫根目錄下主要包含cmake存放CMake相關(guān)模塊負(fù)責(zé)找第三方庫include與srcCaffe的源碼本體包含caffe的頭文件和cpp文件tools編譯后會生成caffe.exe等可執(zhí)行工具pythonpycaffe的Python接口代碼models經(jīng)典的模型定義與權(quán)重下載地址examples官方示例其中mnist文件夾就是我們后面要用的手寫數(shù)字示例還有CommonSettings.props和Caffe.sln這兩個Windows工程核心文件3.2 編輯CommonSettings.props編譯前必須修改CommonSettings.props這個文件。它是一個MSBuild的屬性表定義了整個編譯過程中的關(guān)鍵宏。你需要按自己的環(huán)境開啟或關(guān)閉相應(yīng)的配置項。比如如果只用CPU環(huán)境把CpuOnlyBuild這個標(biāo)簽從false改為true這樣就不需要CUDA了如果要帶Python接口把PythonSupport從false改為true并且根據(jù)你裝的Python版本把PythonDir指向?qū)嶋H路徑比如C:\Python35要注意CUDA版本對應(yīng)的CUDA_PATH環(huán)境變量VS會自動讀取我寫過一篇總結(jié)建議第一次編譯時盡量先關(guān)掉Python和Matlab支持只編C核心等跑通了再加擴(kuò)展接口。這樣做是因為Python接口要額外編譯pycaffe的入口Matlab接口需要去配Mex文件如果這些一起編出錯時日志會非常長很難定位問題。3.3 CMake生成VS工程在項目根目錄執(zhí)行CMake用CMake GUI或者命令行都行。關(guān)鍵參數(shù)是指定源碼目錄和構(gòu)建目錄build文件夾指定Visual Studio生成器比如Visual Studio 14 2015 Win64勾選或設(shè)置Python相關(guān)的選項如果第2步關(guān)閉了PythonSupport這里也可以不勾CMake配置階段如果提示找不到某些庫基本都是因為libraries預(yù)編譯包沒放對位置或者版本不對。它找到所有依賴項后就會生成Caffe.sln和一堆.vcxproj項目文件。這一步的報錯通常和路徑有關(guān)解決方案就是檢查libraries目錄是否存在、環(huán)境變量CUDA_PATH是否指向正確路徑。3.4 編譯并生成caffe.exe用Visual Studio打開生成的Caffe.sln在解決方案管理器里找到ALL_BUILD項目右鍵選擇生成。第一次編譯Caffe會花很長時間因為要編譯數(shù)百個源文件還有Protobuf的生成代碼。如果你是四核以上的CPU可以在CMake時開啟多線程編譯或者直接在VS里調(diào)整“項目屬性 - C/C - 命令行”加上/MP參數(shù)。我自己用的是八核機(jī)器開啟多線程后大概20多分鐘能編完。編譯完成后所有可執(zhí)行文件會生成在build目錄下的x64/Release里其中包括caffe.exe這是Caffe的命令行入口。同時也會生成libcaffe.lib靜態(tài)庫和對應(yīng)的頭文件。到這里核心部分就編譯成功了。4. 實際驗證用MNIST快速跑通第一個模型4.1 準(zhǔn)備MNIST數(shù)據(jù)集Caffe官方提供了一個腳本get_mnist.bat位于examples/mnist文件夾里。運行它之后會自動從網(wǎng)上下載MNIST數(shù)據(jù)集并且調(diào)用convert_mnist_data.exe把原始二進(jìn)制文件轉(zhuǎn)成Caffe能夠直接讀取的LMDB格式數(shù)據(jù)庫。這個轉(zhuǎn)換過程要注意如果你編譯時不帶LMDB支持轉(zhuǎn)換工具就生成不了所以前面編譯依賴時一定要檢查leveldb和lmdb這兩個庫是否編譯進(jìn)去。轉(zhuǎn)完之后會在examples/mnist文件夾下生成mnist_train_lmdb和mnist_test_lmdb兩個文件夾。這兩個文件夾就是標(biāo)準(zhǔn)的數(shù)據(jù)源網(wǎng)絡(luò)定義文件里會引用它們。4.2 給出LeNet網(wǎng)絡(luò)定義和Solver配置Caffe官方在examples/mnist文件夾里已經(jīng)提供了兩個核心文件lenet_train_test.prototxt和lenet_solver.prototxt。前者定義了LeNet網(wǎng)絡(luò)結(jié)構(gòu)一個卷積層、一個池化層、再一個卷積層、一個池化層最后接兩個全連接層后者是訓(xùn)練超參數(shù)的配置。我截取lenet_solver.prototxt里最關(guān)鍵的一段來分析net: examples/mnist/lenet_train_test.prototxt test_iter: 100 test_interval: 500 base_lr: 0.01 momentum: 0.9 weight_decay: 0.0005 lr_policy: inv gamma: 0.0001 power: 0.75 max_iter: 10000 display: 100 type: SGD solver_mode: GPU這里的base_lr是初始學(xué)習(xí)率0.01是個經(jīng)驗值用SGD做MNIST分類足夠。momentum設(shè)為0.9是沿用經(jīng)典策略目的是在梯度更新時保留上一次更新的方向減少震蕩。weight_decay設(shè)為0.0005是常用的L2正則化參數(shù)防止過擬合。max_iter設(shè)為10000表示訓(xùn)練一萬步。4.3 執(zhí)行訓(xùn)練并解讀日志輸出在命令行中運行caffe.exe train --solverexamples/mnist/lenet_solver.prototxt如果你是CPU編譯版本記得先把solver_mode改成CPU。跑起來之后你會看到每100次迭代輸出一次當(dāng)前l(fā)oss比如I1012 10:23:45.678901 1234 solver.cpp:245] Iteration 100, loss 0.6234 I1012 10:23:45.678902 1234 solver.cpp:271] Train net output #0: loss 0.6234 (* 1 0.6234 loss)loss從初期的2.3左右逐漸下降到一萬次迭代后基本能到0.02以下測試準(zhǔn)確率在99%附近。這時候你的Caffe Windows環(huán)境就正式驗證通過了。我實際操作時的經(jīng)驗是第一次跑最好盯著loss下降曲線如果發(fā)現(xiàn)loss卡住不動或者直接變成NaN先檢查學(xué)習(xí)率設(shè)置把base_lr調(diào)小10倍再試。還有prototxt里數(shù)據(jù)層的路徑如果是從其他機(jī)器復(fù)制過來的記得用絕對路徑或相對路徑保持正確。5. 常見問題與避坑經(jīng)驗我一次性幫你踩完5.1 編譯階段報錯速查表報錯信息可能原因解決方法找不到cuda_runtime.hCUDA未安裝或路徑不對檢查CUDA_PATH環(huán)境變量確認(rèn)CUDA版本與VS匹配cudnn.h找不到cuDNN未解壓到CUDA目錄把cuDNN的include和lib合并到CUDA安裝目錄MSB4062或MSB3723VS版本與CUDA工具集不兼容換用VS2013/2015搭配CUDA 8.0編譯Python接口失敗Python版本與依賴庫不匹配關(guān)閉PythonSupport先編核心LNK1104無法打開xxx.lib第三方庫路徑配置錯誤重新檢查libraries目錄路徑是否在VC庫目錄里5.2 運行階段出現(xiàn)的問題編譯成功后運行時還會遇到幾個非常典型的坑我把它們單獨拿出來說。第一個是找不到動態(tài)庫。編譯好的caffe.exe雙擊運行會閃退或者提示找不到cudart64_80.dll / cudnn64_5.dll。這是因為CUDA和cuDNN的bin目錄沒有加入系統(tǒng)PATH。你把C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin加進(jìn)PATH并把cuDNN的bin目錄里的cudnn64_5.dll復(fù)制到CUDA的bin目錄即可解決。第二個是命令行運行提示“無法啟動此程序因為計算機(jī)中丟失libglog.dll”。這個問題說明編譯時選擇的運行庫是Debug版本或動態(tài)鏈接方式而運行時沒有把對應(yīng)的依賴庫一起帶過來。libraries預(yù)編譯包里的bin目錄有這些動態(tài)庫把它們加進(jìn)PATH或者拷貝到caffe.exe的同目錄下就解決了。第三個是prototxt路徑問題。運行時如果提示“Failed to open lmdb”或者“Check failed: file exists”要先檢查工作目錄。Caffe內(nèi)部解析相對路徑的口徑是以當(dāng)前命令行所在目錄為準(zhǔn)的所以如果你在build目錄下運行caffe.exe就記得用相對路徑時帶上源碼目錄名或者干脆用絕對路徑。5.3 性能相關(guān)的建議Caffe跑在Windows上的性能一般不如Linux這是文件系統(tǒng)機(jī)制和編譯優(yōu)化的差異導(dǎo)致的。我在同一臺機(jī)器上做過對比Windows上的推理速度大約是Linux的80%到90%如果開了CPU模式差距更明顯。所以如果項目對延遲特別敏感我建議把訓(xùn)練放在Linux服務(wù)器上Windows這邊只做模型轉(zhuǎn)換和簡單驗證。如果只能Windows上跑盡量把Caffe的編譯配置從Debug換成Release并從項目屬性里打開SSE2和AVX指令集優(yōu)化。5.4 Python接口的配置細(xì)節(jié)如果你需要pycaffe編譯完P(guān)ython支持后還需要把python目錄和build目錄里生成的caffe文件夾加入Python的搜索路徑。最簡單的方式是在系統(tǒng)環(huán)境變量PYTHONPATH里添加兩個路徑D:\caffe-windows\python D:\caffe-windows\build\x64\Release\pycaffe然后在終端測試import caffe print(caffe.__version__)如果能正常輸出版本號就說明接口沒問題。這里有個坑是Python版本位數(shù)必須是64位Python而且要和你編譯時PythonSupport指定的版本一致32位Python和64位Caffe庫絕對對不上。6. 寫在最后的個人經(jīng)驗我在折騰caffe-windows的過程中最深的一個感受是“老技術(shù)不等于過時但你得按老技術(shù)的規(guī)則來玩”。這個框架的代碼結(jié)構(gòu)和現(xiàn)代深度學(xué)習(xí)框架完全不同它對系統(tǒng)環(huán)境的假設(shè)非常死板一個版本號不對就可能失敗。但當(dāng)你真正跑通之后你會發(fā)現(xiàn)它的速度和可定制性仍然有自己的優(yōu)勢。如果你現(xiàn)在也在為某個老模型不得不編譯Caffe別急著換框架按我上面的步驟一步步來大概率能順利搞定。最后再分享一個小技巧如果你只做推理不做訓(xùn)練其實可以直接用caffe.exe test命令去跑測試配合訓(xùn)練好的權(quán)重文件比寫一堆Python代碼簡單得多。這也是Caffe作為命令行工具最被人忽視的優(yōu)點。本文還有配套的精品資源點擊獲取