简介Caffe是伯克利视觉与学习中心开发的流行深度学习框架原生面向Linux和macOS。caffe-windows这一资源针对Windows用户做了完整移植将源码、构建脚本和示例打包在一起适合希望在Windows环境训练与部署模型的开发者尤其是不熟悉手动编译依赖的入门者。压缩包共888个文件、约8.67MB主要包含C源码235个、头文件144个、CUDA代码95个、模型定义文件59个配以Python脚本、CMake构建文件、Shell脚本和Markdown文档构成一套可直接编译和运行的Windows版Caffe工程。资源除了Caffe主程序与测试文件还提供CUDA、构建配置、实用工具等模块方便按CPU或GPU需求调整配置后重新生成解决方案MNIST示例与模型定义可快速验证环境也能尝试训练AlexNet、VGG、ResNet等经典网络或自定义结构。当前已有293人学习或下载。对想在Windows上使用Caffe的开发者而言这个打包工程省去了整理依赖的环节明显降低入门门槛。1. caffe-windows接手老工程后为什么还要在Windows上折腾Caffe接到过一个存量检测服务模型结构是几年前调的训练和验证脚本全是caffe train的写法推理模块也直接基于Caffe的C接口。要把它平移到Windows服务器上做二次微调重新用别的框架训练一遍成本太高而且对比基准就变了最后选择了caffe-windows在Windows下源码构建一套能用的Caffe。这套方案解决的核心问题很简单就是让Windows成为Caffe的可落地环境最终产物是caffe.exe、caffe.dll和pycaffe接口老模型能继续训、能部署、也能做实验对照。适合维护存量模型的人、复现老论文的研究者以及想通过框架源码学习工程化的初学者。别把它当古董它是很多生产模型最后一公里的现实答案。2. 编译caffe-windows之前依赖栈与版本匹配是第一道生死线2.1 为什么Caffe在Windows上这么难装依赖栈与官方支持的历史包袱Caffe在设计上优先服务Linux这一点从它的依赖列表就能看出来protobuf负责序列化网络结构和权重glog提供日志gflags解析命令行参数lmdb和leveldb存储训练数据OpenCV处理图像读写HDF5做辅助数据管理。这些库在Linux世界里全部能用包管理器一键装好到了Windows上没有统一入口每个库都得自己解决“源码在哪、编什么版本、编完往哪放”三个问题。官方对Windows的支持又长期停留在实验性质构建文档更新慢和Linux主线的进度明显错位。caffe-windows这套方案把“依赖怎么来”这个问题前置处理了要么用脚本去下载预先编好的第三方库要么把第三方库的源码一起拉下来在CMake里统一编。这两种做法的本质都是把依赖栈固化住避免每次在新机器上重演“装一个库翻一次车”。但依赖栈只要有一点版本漂移后面所有环节都会被带偏。所以真正动手前先把版本矩阵定死比照着“最新版”这三个字装东西靠谱得多。准备工作做扎实后面编译和运行会顺利一大截省掉这一步基本等于把整个构建过程交给玄学。先有个心理预期首次完整编译caffe-windows快的也要半小时慢的能吃一顿饭的工夫。中间要是报错第一反应不要怀疑代码优先怀疑版本组合。2.2 版本匹配矩阵VS、CUDA、cuDNN、Python、CMake怎么锁我在给某公司一个老项目做Windows迁移时先把机器上所有工具链版本列了一张表逐个和Caffe的依赖要求比对然后再动手编译。这样做的原因是Caffe的C代码是按特定时代的标准写的新编译器可能会把一些宽松写法当成错误新版CUDA也可能改变运行时行为理论上“最新版”更先进但对老框架往往不是最友好的。下面这张表是我实际用下来比较稳的组合组件组合A老而稳组合B略新但可接受操作系统Win10 64位Win10/11 64位Visual StudioVS2013 Update 5VS2015 Update 3CUDACUDA 7.5CUDA 8.0cuDNNcuDNN v4或v5cuDNN v5.1PythonPython 2.7或3.5Python 3.5CMakeCMake 3.6CMake 3.8先说安装顺序。先装VS再装CUDA最后手动放cuDNN。CUDA安装器只在检测到已存在的VS时才会注册对应的编译规则顺序反了CMake生成工程时就会抱怨找不到CUDA工具集。cuDNN是解压即用的压缩包把它里的bin、include、lib三个目录拷进CUDA安装目录对应的文件夹这样编译和运行时都能直接找到。装完之后在命令行里敲nvcc --version确认CUDA可见再检查CUDA默认安装目录的bin下能看到cudnn64_5.dll这种文件这一步能避免后面一半以上的环境类报错。Python版本如果牵扯到pycaffe接口限制比较死原则是2.7或3.5。原因在于Caffe的Python层代码里还有挺多跨版本兼容写法最新的3.8以上对老的Cython生成代码并不友好。我见过有人直接上Python 3.9结果在生成_pycaffe扩展那一步连续报错换回3.5之后一次通过。如果你完全不用Python接口只跑caffe.exePython版本可以更随意但CMake在配置时还是会探测系统默认Python建议机器上装一个3.5备用省得CMake探测到个莫名其妙的版本后生成一堆不匹配的配置。2.3 拉取代码与初始化子模块别把第三方索引漏了依赖准备完之后开始拉代码。Caffe在Windows上的构建分支通常是仓库的windows分支所以拉代码时最好直接锁定分支避免在主分支和windows分支之间来回切换产生不必要的差异。常用操作如下# 克隆caffe-windows对应的仓库地址按你手头的那份来 git clone caffe-windows仓库地址 cd caffe git checkout windows # 切到windows维护分支 git submodule update --init --recursive # 拉全所有子模块命令行里的git checkout windows是为了切到Windows维护分支这个分支里才有完整的CMakeLists配置和Windows专属的构建脚本主分支一般不管Windows的事。紧接着的git submodule update --init --recursive是把Caffe依赖的第三方子模块索引拉全尤其是src/caffe/proto下面的protobuf定义以及部分第三方库的补丁和源码。漏掉子模块的典型症状CMake配置时提示找不到caffe.pb.cc或caffe.pb.h这两个文件正是靠子模块里的protobuf源码生成的。提示如果网络不好可以先克隆主干再切分支但子模块不要做浅克隆浅克隆会让子仓库的commit历史不完整个别子模块在CMake版本判断时会计算出错误分支信息导致构建失败。依赖下载方面仓库通常还会带一个下载预编译第三方库的脚本。我的建议是优先用脚本拉预编译库因为库版本和仓库分支是配套好的比自己逐个源码编译省时省力。但前提是你本机的VS版本和预编译库对应的编译环境一致否则链接阶段会冒出大量LNK2038之类的不匹配错误这类错误在几种报错里最难读懂因为错误信息里只给Mismatch不给具体哪个版本不匹配。如果遇到这种情况我的选择是彻底放弃预编译库改成让CMake从源码编第三方库多花一两个小时但换来的是确定性的环境。3. 用CMake构建caffe-windows最小构建命令与三个必调参数3.1 我为什么不用一键脚本而手工跑CMakecaffe-windows的仓库里常见一个build_windows.bat脚本看起来很方便双击就好。但我实际用下来更推荐手工敲CMake命令来构建。一键脚本封装了一堆默认值默认Python版本、默认CUDA架构列表、默认依赖目录一旦你的机器和脚本作者当初的开发环境不完全一致这些默认值就会成为第一个排查盲区。调试脚本的时间往往比自己敲CMake命令长很多。手工CMake的好处在于透明每一个选项都明明白白写进CMakeCache.txt你可以用文本编辑器打开这个文件确认某个开关到底开没开生成的VS解决方案也保留了所有中间产物出问题时能直接定位到具体项目。另外一个原因是对产物结构的理解手工走一遍CMake你就知道caffe.exe会生成在build/tools/Release下pycaffe模块在build/python下第三方dll在build/lib/Release下后面配置运行环境时基本不用查文档。3.2 从CMake到MSBuild的最小构建命令在源码根目录新建build目录执行下面命令mkdir build cd build cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_CONFIGURATION_TYPERelease ^ -DCPU_ONLY1 ^ -DBUILD_PYTHON1 ^ -DBUILD_EXAMPLES1 ^ -DCMAKE_PREFIX_PATHD:/libs/opencv cmake --build . --config Release --parallel 8首行的-G Visual Studio 14 2015 Win64对应VS2015的64位生成器如果你本机是VS2013则写成Visual Studio 12 2013 Win64生成器选错后面MSBuild会直接抱怨找不到工具集。CMAKE_CONFIGURATION_TYPERelease表示只生成Release配置Debug配置在Windows的Caffe构建里经常触发一些断言和奇怪的崩溃原因在于Caffe里面不少条件编译分支对NDEBUG有依赖所以这个参数别改成Debug。CPU_ONLY1是最小化构建的精髓第一次编译先不开CUDA把整条工具链跑通之后再开GPU也只是加参数的事排查问题时能大幅缩小范围。BUILD_PYTHON1和BUILD_EXAMPLES1同时开前者产出pycaffe后者产出后面造数据需要的convert_imageset和compute_image_mean。第二行cmake --build . --config Release等价于MSBuild编译Caffe.sln。这里--parallel 8控制并行度Windows下没有make -j的写法CMake会把它映射到MSBuild的并行编译参数。首次编译如果第三方库也要跟着编耗时至少在半小时以上中间看起来像卡住了很可能是正常的别轻易关进程。参数说明CMAKE_PREFIX_PATH用于指定OpenCV等非默认位置的库路径多个路径用分号隔开路径里统一用正斜杠省去转义麻烦。如果CMake找不到Python可以追加-DPYTHON_EXECUTABLED:/Python35/python.exe把它指向明确的解释器可执行文件。配置完成后打开build目录下的CMakeCache.txt搜索Caffe_开头的条目检查CPU_ONLY、BUILD_PYTHON、BUILD_EXAMPLES这三个值是否和你预期一致。3.3 CPU_ONLY和GPU两条路线CUDA_ARCH与USE_CUDNN怎么给当你不满足于CPU_ONLY、打算上GPU时CMake命令变成这样cmake .. -G Visual Studio 14 2015 Win64 ^ -DCMAKE_CONFIGURATION_TYPERelease ^ -DCPU_ONLY0 ^ -DUSE_CUDNN1 ^ -DCUDNN_ROOTD:/cudnn/cudnn-8.0-windows10-x64-v5.1 ^ -DCUDA_ARCH52 61 75 ^ -DBUILD_PYTHON1 ^ -DBUILD_EXAMPLES1相比CPU_ONLY的最低配置GPU构建多了三个关键参数。USE_CUDNN1开启cuDNN加速卷积和池化层的运行速度会明显提升但代价是CMake阶段必须能定位cudnn.h和cudnn.libCUDNN_ROOT专门用来指定cuDNN解压目录也可以直接把它配置进CUDA目录后省略这个参数。CUDA_ARCH声明目标显卡的算力列表比如你的卡是算力6.1、7.0、7.5就分别把这个三个数字写进去。这里有一个常见误解不完全确认自己显卡算力时就用“52 61 75”这种覆盖主流三代的范围编译时间会高一点但不会因为缺少某个架构代码而在别的机器上跑不了。如果漏了CUDA_ARCHCMake会尝试自动探测当前机器的显卡并只生成对应架构的代码。这在自用机上一时看不出来可一旦把编译好的环境拷贝到另一台显卡不同代的机器上运行时会报device kernel image is not supported。我就在一次环境迁移中吃过这个暗亏本机编好的caffe-windows拷到某实验室另一台显卡上推理一跑就崩重编时补上CUDA_ARCH列表才解决。CMake常用参数整理参数作用建议CMAKE_CONFIGURATION_TYPE生成Release还是Debug固定ReleaseCPU_ONLY是否只编译CPU版本首次排错设1正式训练设0USE_CUDNN启用cuDNN支持GPU必开CPU_ONLY时不要开CUDA_ARCH目标显卡算力列表写2到3代留点迁移余量BUILD_PYTHON是否编译Python接口需要pycaffe时设为1BUILD_EXAMPLES是否编译tools工具设为1造数据要用有一点容易被忽略Windows下Caffe要求能在配置时找到Python如果你机器上的Python是3.9之类太高版本CMake配置阶段可能直接报错或者生成一堆不合理的引用最后编出来的pycaffe根本导不进去。我的做法是在准备阶段就把Python锁成3.5并显式传入-DPYTHON_EXECUTABLE杜绝探测歧义。这一处准备到位能省掉后续很多“import失败”的排错。4. 把图片变成lmdb再训练caffe-windows数据链路与四个必改参数4.1 制作lmdb数据集convert_imageset的路径、标签与编码Caffe的数据层不直接读jpg需要先把图片转换成lmdb或leveldb格式。Windows下转换工具在编译完成后位于build/tools/Release/convert_imageset.exe。执行前先准备一个标签文件每行写成“相对路径 标签序号”例如00001.jpg 0路径是相对于图片根目录的。然后执行build/tools/Release/convert_imageset.exe ^ D:/data/mnist/train/ ^ D:/data/mnist/train_labels.txt ^ D:/data/mnist/train_lmdb ^ --backendlmdb ^ --shuffletrue ^ --resize_height28 ^ --resize_width28 ^ --encodingrgb第一个参数是图片根目录第二个是标签文件第三个是输出lmdb目录后面跟的可选参数里--backend指定存储格式lmdb是默认改成leveldb时注意后续prototxt里的backend也要同步改。--shuffletrue会打乱样本顺序避免同类样本扎堆导致训练震荡。--resize_height和--resize_width把图片统一缩放到指定尺寸这个尺寸必须和网络prototxt里data层的输入宽高一致否则训练在数据层就报错而不是等到前向推理才暴露。转换完成后再顺手算一份均值文件Caffe里常用来做数据预处理build/tools/Release/compute_image_mean.exe ^ D:/data/mnist/train_lmdb ^ D:/data/mnist/mean.binaryprotomean.binaryproto是二进制格式的均值文件后面在prototxt的data层用mean_file引用它。如果数据集比较小你可以直接用全部训练数据算均值数据集很大时一般只在训练集上算不在测试集上算。Windows路径这点要单独说标签文件里的相对路径分隔符统一用正斜杠不要写反斜杠输出目录名也不要带空格。Linux下有空格也许能跑Windows下convert_imageset对带空格的路径解析很容易出错表现为“打不开文件”或者生成的lmdb目录里只有零字节文件。这是我在一个项目里实际栽过的坑后来所有数据路径一律不建带空格的目录名问题彻底消失。4.2 修改prototxt与solver四个必改位置和数值关系数据集备好之后改动solver.prototxt和train_val.prototxt。需要重点关注的位置有几个。solver示例net: D:/models/lenet/train_val.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 display: 50 max_iter: 10000 snapshot: 1000 snapshot_prefix: D:/models/lenet/snapshot solver_mode: GPUtest_iter的含义是用测试batch数除以测试集图片数得到的整数比如batch_size是100、测试集有10000张那么test_iter100就能让测试阶段看完整个测试集。test_iter如果设得比实际可迭代次数大数据层会在测试阶段报错提示读不到更多数据。snapshot_prefix是保存断点的前缀Windows下如果目录带空格这里必须用双引号包住整个路径。solver_mode要和编译时的选项对应编译的是GPU版本就写GPU编译的是CPU_ONLY就写CPU写反了caffe会在初始化阶段报错。train_val.prototxt里也要同步调整。data层的source换成lmdb的Windows绝对路径用正斜杠mean_file如果上一步生成了mean.binaryproto就写它的绝对路径transform_param里的mirror和crop_size按你的实验需求来但crop_size如果大于resize后的图片尺寸数据层会取不到足够的像素而报错所以要检查resize尺寸和crop_size的数值关系。我一般在写完prototxt后有一个检查习惯打开train_val.prototxt把所有带D:/或C:/的路径字段过一遍确认路径结尾没有多余空格、没有中文目录、没有带空格目录名中文路径在Windows版本的Caffe里偶尔能跑偶尔不能跑属于纯不确定因素干脆不用。4.3 启动训练与恢复日志、GPU指定、solverstate和caffemodel的区别训练命令很简单但Windows下有几点和Linux完全不同build/tools/Release/caffe.exe train ^ --solverD:/models/lenet/solver.prototxt ^ --gpu0 21 | tee D:/logs/lenet_train.log--gpu0指定使用第0号显卡如果你编译的是CPU_ONLY版这句话就不要带而且solver里solver_mode: CPU。后面的21 | tee是Windows下保日志的常见写法caffe的警告信息通常走stderr不加21只能看到stdout内容训练过程中的warning会丢掉排查时就少了线索。tee能把屏幕输出同时写进文件便于事后复盘loss曲线和定位崩溃点。训练中途断了恢复训练也是常事build/tools/Release/caffe.exe train ^ --solverD:/models/lenet/solver.prototxt ^ --snapshotD:/models/lenet/snapshot_iter_5000.solverstate这里要强调solverstate和caffemodel的区别。.solverstate保存的是优化器完整状态恢复训练必须用它.caffemodel只保存网络权重适合部署或作为fine_tune的预训练初始化用来恢复训练会导致学习率、动量和迭代计数全部从零开始效果完全对不上。如果数据集顺序不变、模型结构不变正常快照恢复后的loss曲线应该和你当初中断时的曲线连续衔接如果出现断崖式跳变先检查是不是拿caffemodel冒充了solverstate。Windows下还有个隐藏差异caffe.exe运行时的工作目录会影响相对路径的解析。如果prototxt里写了相对路径那么路径是相对于exe运行目录的不是相对于prototxt所在目录的。我的做法是要么全部用绝对路径要么写一个启动脚本先cd到指定目录再执行caffe命令两条路选一条并保持一致避免换一台机器路径全废。5. 避坑caffe-windows从编译到训练的5个常见翻车现场5.1 编译时找不到cudnn.h头文件路径没进搜索目录现象CMake配置能通过一旦编译到convolution层cl.exe就报fatal error C1083打不开cudnn.h整个编译中断。原因Caffe的源码里写的是#include cudnn.h预处理器只在include搜索路径里找这个文件。USE_CUDNN1只代表需要启用cuDNN支持但CMake并不知道cuDNN具体在哪需要靠CUDNN_ROOT或者CUDA安装目录里的include路径传过去。解决最简单的做法是把cuDNN解压目录下的bin、include、lib三个文件夹内容合并进CUDA安装目录对应的文件夹里CMake配置时检查CUDNN_INCLUDE路径有效后再编译。另一种做法是显式传-DCUDNN_ROOTD:/cudnn/...配完检查CUDNN_LIBRARY和CUDNN_INCLUDE是不是都指向了非空文件。5.2 MSB8036错误VS版本和生成器不匹配现象cmake生成成功但msbuild一开始就报MSB8036意思是找不到生成器指定的Visual Studio版本工具集。原因生成器写的是VS2015 Win64但机器上装的是VS2017或者只装了Build Tools但没有装C桌面开发工作负载导致对应版本的VC工具集缺失。解决打开Visual Studio Installer检查有没有对应版本的“使用C的桌面开发”组件没有就补装如果你不想装全量VS可以装对应版本的Build Tools。装完以后删掉build目录重新配置一次不要在原目录上硬continue有些工具集相关的CMake缓存不会自动刷新。删了重新来30秒的事别心疼。5.3 import caffe直接挂PYTHONPATH指错目录现象编译一切正常build目录下也能看到caffe的python相关产物但进入python解释器执行import caffe报ModuleNotFoundError或者DLL load failed。原因pycaffe编译后的模块在build/python下而不在源码根目录的python目录里。如果只把源码根目录加进PYTHONPATHPython能找到部分py文件但找不到编译生成的扩展模块文件最终要么说找不到模块要么加载dll失败。解决把环境变量指向正确位置典型的设置如下set PYTHONPATHD:/caffe-windows/build/python;D:/caffe-windows/python set PATHD:/caffe-windows/build/lib/Release;D:/caffe-windows/build/python/caffe;%PATH%第一行的两个路径分别是编译生成的模块目录和源码带的Python辅助目录缺一个都可能出问题第二行的PATH把caffe.dll和第三方dll的所在目录放进去确保运行时能加载动态库。设置完在命令行重新进入Python再试不要在一个已经启动的解释器里反复import环境变量不会自动刷新。测试通过后建议把这两行写进系统的用户环境变量避免每次开终端重设。5.4 训练刚启动数据层就报错source路径和lmdb文件对不上现象训练开始几秒日志里弹出Check failed提示data.get_data()或类似的数据层错误进程退出。原因prototxt里data层的source路径写错、lmdb文件不存在、或者路径里的反斜杠和空格把数据层搞晕了。Windows的Caffe在解析路径时对外层路径的空格与分隔符非常敏感。解决先把source统一改成正斜杠绝对路径比如D:/data/mnist/train_lmdb确认这个目录下存在data.mdb和lock.mdb这两个文件——lmdb格式的特征就是这两个文件。如果你转出来的是leveldb则应该看到CURRENT、LOCK和一堆.ldb文件。最隐蔽的场景是convert_imageset转出的目录在A盘prototxt里写的是B盘路径拷文件时漏了其中一个就会产生这种“看似配置没问题实际读不到数据”的报错。检查一下路径指向的文件是否真实存在比研究日志有效率。5.5 GPU训练中途崩溃显存不足或cuDNN的dll版本混放现象GPU训练跑了几百次迭代loss正常下降突然段错误或报out of memory程序直接退出换一台机器跑同样的代码可能更早崩。原因最常见的是batch_size和网络输入把显存撑爆另一个隐蔽原因是运行环境里存在多个版本的cudnn64_*.dll而Caffe按PATH顺序加载到了一个和编译版本不一致的dll导致cuDNN handle初始化失败或结果异常。解决先把batch_size逐次减半64到32再到16同时把solver里的输入尺寸也临时缩小确认是不是显存问题。如果减到16还崩大概率是cuDNN库版本混放。去CUDA安装目录的bin下看一眼如果同时存在cudnn64_5.dll和cudnn64_7.dll这类文件就把不需要的那个改后缀名移走只保留与编译时一致的那一个。这个坑特别难发现因为报错信息里可能只是runtime api error不会直接提cuDNN名称而这类问题在CPU_ONLY版本上完全不出现所以排查时可以用CPU_ONLY跑同一步骤做对照能快速把问题范围缩小到GPU/cuDNN这边。6. 固化你的caffe-windows环境快速验证与一套值得保存的配置环境编译好只是开始更重要的是验证它真的能用于实际训练。我习惯在正式跑项目前先跑一遍Caffe自带的MNIST示例把数据转换、训练启动、断点保存整个链路走通。如果你不想下载完整MNIST手写数据集也可以拿手头任何一个小图片集凑200张图按第4章的命令转成lmdb只要网络能在一个合理时间内收敛就说明环境可用。跑通之后我强烈建议把手头这套环境“固化”下来而不是等下次换机器再重新编译一遍。具体做法是建一个caffe_env.bat集中写入下面这些环境变量和路径信息每次新终端先执行一次再启动Caffe相关命令set PYTHONPATHD:/caffe-windows/build/python;D:/caffe-windows/python set PATHD:/caffe-windows/build/lib/Release;D:/caffe-windows/build/tools/Release;%PATH% set CAFFE_ROOTD:/caffe-windows养成一个习惯环境变更全部记进这个bat文件不要临时在系统环境变量里改来改去。否则某天你开着多个终端其中一个带的PATH不同结果训练脚本跑出来的结果和另一个终端完全对不上排查会非常痛苦。我还在bat文件末尾加了两行echo打印当前生效的python路径和caffe版本每次开新终端第一件事是确认打印结果符合预期。例行验证命令是python -c import caffe; print(caffe.__version__)能打印版本号说明pycaffe可用再跑一个caffe.exe train --solver...能进入迭代说明训练链路可用。两件事都通过这套环境就可以放心交给后续任务了。很多进阶问题其实都源于环境不够“可复现”把环境做成一个可重复加载的bat脚本后续不管换机器还是给同事备份都只需要复现一份文件。希望这套caffe-windows的落地过程能帮到你少踩几个坑。本文还有配套的精品资源点击获取