简介面向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整个过程踩了无数坑。现在回头看很多问题其实可以避免。这篇文章从环境配置讲到编译实操再到训练一个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整个过程踩了无数坑。现在回头看很多问题其实可以避免。这篇文章从环境配置讲到编译实操再到训练一个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作为命令行工具最被人忽视的优点。本文还有配套的精品资源点击获取