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