简介Caffe 是伯克利视觉与学习中心开发的流行深度学习框架caffe-windows 压缩包面向需要在 Windows 平台使用 Caffe 的开发者省去自行编译的复杂过程降低环境搭建门槛。包内共有 888 个文件涵盖 cpp、hpp、cu 等源码与头文件cmake、vcxproj、sln 等工程构建配置prototxt 模型定义、Python 训练与转换脚本、Markdown 说明文档和示例图片等整体约 8.67MB目录组织清晰便于按模块查阅也能快速定位需要的源码、配置或模型文件。已有 292 人学习下载。资源围绕 Windows 下的安装使用展开梳理了 Visual Studio、CMake、CUDA、cuDNN、Python 与 NumPy 等组件的配置要点并给出从源码获取、配置修改、编译构建到功能测试的完整思路可以帮助读者规避常见错误。对于需要在 Windows 上训练或部署 Caffe 模型的初学者和研发人员这份整理好的包体与配套注意点很有参考价值也能为后续自定义网络结构提供基础。 Caffe 在 Windows 上一直是个让人又爱又恨的话题。这个框架本身是伯克利视觉实验室的产物当年在 CV 领域几乎是标配特别是那些经典的 ResNet、VGG、SSD 模型的 prototxt 和 caffemodel到现在还在各种老项目里躺着。但官方源码压根不提供 Windows 支持所谓 caffe-windows 全靠社区分支硬撑。这篇东西就围绕“怎么在 Windows 上把 Caffe 跑起来”这个主题把我踩过的坑、验证过的方案、排查思路全部摊开来讲适合需要复现老模型、对比论文结果、或者因为项目历史包袱不得不留在 Caffe 生态里的同学。我默认你的场景是Windows 10/11 系统想用 Caffe 训练或推理一个已有的深度模型但不想为此专门装双系统或虚拟机。如果你属于这种情况这篇内容应该能帮你省下不少时间。1. 方案选型不是所有 Caffe-Windows 都长一个样1.1 官方不支持时我们有哪些路可以走Caffe 官方仓库的 README 写得很清楚仅支持 Linux 和 macOS。Windows 用户想用不外乎三条路一是用微软维护的 BVLC/caffe 的 Windows 分支二是用 conda 直接装编译好的包三是找第三方预编译包或自己编译。三条路各有代价。微软那个分支当年确实是福音能在 Visual Studio 里打开 Caffe.sln 直接编译但问题也明显它停更太久绑定的依赖版本停留在 VS2013/2015 时代。如果你现在的机器装的是 VS2022光是改平台工具集就能折腾半天。而 conda 装 caffe 或 caffe-gpu 是最快的路子一条命令搞定但包管理器里的版本比较老而且如果你需要改动 Caffe 源码、加自定义层这条路就走不通了。我的建议很直接如果你只是想跑通一个已有的模型做推理优先试 conda如果你要基于 Caffe 改网络结构、加自定义 Python 层那就老老实实自己编译。我自己两种方式都试过后来因为要改 SS 的检测头还是走回了源码编译这条路。1.2 分支选择决定了你的痛苦程度确定要自己编译后下一个问题就是选哪个仓库。在 Windows 上比较常见的两个来源BVLC/caffe 的 Windows 分支官方账号下维护的 windows 分支年代久远但相对稳定支持 VS2013/2015。willyd/caffe-windows社区维护者 willyd 的分支更新一些对 VS2015/2017 以及新版本 CUDA 兼容性更好。我自己用的是 willyd 这个分支原因很简单它能支持 CUDA 10.0 和 cuDNN 7.x这个组合在 2018 年以后很长一段时间里是 Windows 深度学习环境的主流搭配能找到的资料也最多。如果你机器显卡太新比如 RTX 30 系以后那就得注意 CUDA 版本兼容问题了这属于另一个坑后面会提到。选分支时还有一个判断技巧去 GitHub 看最近的 commit 时间和 Issues 内容。如果最近一两年都没人维护说明用的人少、踩坑资料也少出问题基本只能自己啃源码。2. 编译前环境准备这几项不做好会浪费一整天2.1 Visual Studio、CUDA、cuDNN 版本怎么搭配先说结论这是我在多台机器上验证过最省心的一套组合组件推荐版本备注Visual Studio2015 或 2017不要直接用 VS2022 尝试老分支CUDA10.0 或 9.2驱动升级不影响工具包版本要匹配cuDNN7.4 或 7.6要和 CUDA 一一对应Python3.5 或 3.6编译 pycaffe 接口时建议使用OpenCV3.4.x尽量不要用 4.x接口变了选这套组合的原因很实际Caffe 的 Windows 分支源码依赖较老新编译器对老代码的强类型检查会导致大量“无法解析的外部符号”“未知类型名”这类编译错误。VS2015 对老代码的容忍度最高而 CUDA 10.0 之后的版本从编译角度看变化不大但 Caffe 源码里的 caffe.pb.h 是拿 protobuf 生成的protobuf 版本太新会和源码里的旧文件冲突。这里有个细节如果你用的是 30 系以后显卡CUDA 10.0 装倒是能装但驱动不认旧版工具包的可能性很大编译出来跑不起来。这种情况可以试试 CUDA 11.x 手动修源码兼容但工作量会大不少建议评估一下是不是直接用 conda 预编译包更划算。2.2 依赖库下载别一股脑全装Caffe 依赖的东西不少OpenCV、protobuf、glog、gflags、lmdb、leveldb、hdf5、boost。Windows 上没有 apt-get你得一个个下载源码或二进制包。先说 OpenCV官方源码下载后你需要把它编译成 static 库。Windows 分支要求 OpenCV 必须是 static build也就是说要让 Caffe 把图像编解码能力直接编进去而不是运行时找 dll。你的 OpenCV 源码编译时对着 CMake 配置把 BUILD_SHARED_LIBS 关掉即可。protobuf 这块我特别提醒一下Caffe 用的是 protobuf 的 C 运行时来读写模型结构文件。如果你装的是 protobuf 3.6 以上版本编译 Caffe 时大概率会遇到“protobuf 版本不匹配”的报错因为 Caffe 源码里预生成的 .pb.cc 文件是拿旧版 protobuf 生成的。解决办法只有一个就是在 Caffe 的 src/caffe/proto 目录下重新生成一次 .pb.cc 和 .pb.h这要求你的 protobuf 编译器版本和运行库一致。其他依赖用一种比较笨但有效的方式处理直接把库文件放到 Caffe 源码的 dependencies 目录里然后修改 CommonSettings.props 指定路径。不用刻意追求目录清爽能编过就是胜利。2.3 Python 接口的版本陷阱很多人编译 Caffe 的 Python 接口时会踩这个坑装好 Anaconda设好 PYTHON_INCLUDE、PYTHON_LIB 路径编译时却报“无法打开 Python.h”。原因通常是 VS 默认找的是 64 位 Python而你环境里装的是 32 位或者反之。我的建议是给 Python 接口专门建一个独立的 conda 环境不要用 base。命令无非是 conda create -n py36 python3.6然后在 CommonSettings.props 里把 Python 相关路径指到这个环境。这个环境保持干净除了 numpy 之外什么都别装避免依赖冲突。3. 编译实操从下载源码到跑通示例3.1 源码准备和关键配置项首先把仓库克隆到本地路径有个硬性要求不能有中文不能有空格。我见过有人把工程放到“C:\Users\张三\我的项目\caffe-windows”结果是编译器各种诡异的路径错误折腾一晚上才发现是路径问题。建议直接放到 C:\caffe 这种短路径下。打开 windows 目录下的 CommonSettings.props主要改这几个地方!-- CPU_ONLY 设为 true 时只编译 CPU 版本不依赖 CUDA -- CpuOnlyBuildfalse/CpuOnlyBuild !-- 开启 Python 接口 -- PythonSupporttrue/PythonSupport !-- CUDA 目录按实际安装路径填 -- CudaVersion10.0/CudaVersion PythonDirD:\Anaconda3\envs\py36\/PythonDir另一个重要配置是 cuDNN 的路径。把解压后的 cuDNN 文件夹里的 cuda 目录内容复制到 CUDA 安装目录对应位置然后确认 CommonSettings.props 里的CuDnnPath指向 CUDA 安装根目录。3.2 Visual Studio 编译流程详解用 VS2015 打开 Caffe.sln首先要做的事是检查解决方案里的项目依赖关系。默认会包含 libcaffe、caffe、pycaffe 等几个项目。右键解决方案选择“配置管理器”确认当前是 Release x64 模式然后直接生成。第一次编译耗时比较长通常在 20~40 分钟取决于机器性能。需要提醒的是编译过程中如果报错不要急着改代码。很多错误属于配置层面的比如找不到 libcaffe.lib其实是编译顺序不对caffe.exe 项目依赖的 libcaffe 还没有生成。调整项目依赖关系或者先单独编译 libcaffe 项目即可。编译完成后你会在 x64\Release 目录下看到 caffe.exe、libcaffe.lib 以及 pycaffe 目录下的 caffe 包。这时候可以快速验证一下 C 版本是否可用把该目录加入系统 PATH然后打开命令行执行 caffe。如果输出版本信息说明编译成功。3.3 Python 接口安装和环境变量配置pycaffe 的安装方式和普通 Python 包不太一样。你不需要执行 pip install直接把编译生成的 pycaffe 目录添加到环境变量 PYTHONPATH 即可。我的具体做法是在系统环境变量里新建一个 PYTHONPATH值填 C:\caffe\Build\x64\Release\pycaffe。然后在 Python 里尝试 import caffe能成功就说明接口通了。如果不成功优先检查你是否在同一个 conda 环境里执行以及 numpy 版本是否是 1.16 左右的旧版本——numpy 1.17 以后某些 API 变化会导致 import 报错这算是比较常见的坑。4. 常见问题排查这些坑几乎每个人都会遇到4.1 命令行运行 caffe 时闪退或提示找不到 dll原因基本只有两个依赖的 dll 不在 PATH 里或者 cuda 运行时库版本不匹配。前者好办把 OpenCV 的 dll、CUDA 的 bin 目录都加进 PATH 试一遍后者就得用工具查看 exe 到底依赖哪些 cudart64_*.dll再比对系统里装的是哪个版本。排查这类问题我推荐用 Dependencies 这个工具比老旧的 Dependency Walker 更直观能显示 dll 依赖树和缺少的模块。顺着红色标记找几乎立刻定位问题。4.2 Check failed: registry.count(type) 1 这个报错怎么处理这个报错在跑模型时非常常见意思是 prototxt 网络定义文件里写了某个 layer type但 Caffe 里没有注册这个层。出现这种情况通常是三类原因一是拼写错误比如把 Convolution 写成 Convoution二是用了 Caffe 本身没有的自定义层比如某些老项目里写的 NormalizeLayer 其实是某个特定分支才有的三是这个层的实现写在了 Python 层里部署时没有把对应的 Python 模块路径加进来。排查思路很直接先把 prototxt 里的 layer type 和源码 src/caffe/layers 目录下的文件名对照一遍。如果发现确实只有老版本 Caffe 才有这个层那只能切换分支或者把该层的实现手动移植过来。4.3 编译报错 MSB8036 找不到 Windows SDK 版本微软分支的工程文件默认指定了某一年份的 SDK而新装的 VS 不一定带那个版本。解法是在工程属性里把 Windows SDK 版本改成你机器上实际安装的版本。操作路径右键项目 - 属性 - 配置属性 - 常规 - Windows SDK 版本下拉选择最新安装的那个。还有一个比较隐蔽的类似问题是平台工具集版本不匹配比如工程默认是 v140VS2015而你用的是 VS2017 的 v141。这种情况经常伴随一堆莫名其妙的编译错误把平台工具集改对就全好了。4.4 老代码和新编译器的兼容性问题如果你实在没办法只能用 VS2017 或更高版本编译老 Caffe 分支会遇到一类很统一的报错源码里某个头文件里用了一个老编译器允许但新编译器不认的语法。最典型的是 unknown type name uint8_t。这个报错本质是 Caffe 源码没有主动包含标准库的 头文件。工程里 caffe.pb.h 生成时可能也没带上。解决办法是全局搜索一下哪个文件用了 uint8_t 但没有 include 需要的头手动补上就行。不要试图靠更改编译器级别规避治标不治本。4.5 模型训练时 loss 一直是 NaN 或输出全零这个问题和 Windows 本身关系不大但我在 Windows 平台上遇到过太多次还是提一嘴。如果你用的是自定义数据且通过 lmdb 格式输入大概率是数据预处理环节出了问题比如图片均值文件没有生成、mean.binaryproto 格式和 prototxt 里的配置不匹配。更隐蔽的是 GPU 模式下的浮点计算问题。某些老分支的 Caffe 在特定 CUDA 版本下BatchNorm 层的实现会踩到 cuDNN 的 bug导致训练数值不稳定。这种问题排查起来很难受我的建议是先用 CPU 模式跑几十个迭代如果 CPU 正常而 GPU 异常十有八九是 cuDNN 版本匹配问题换个版本重编一次即可。5. 实操验证跑通一个真实的推理任务5.1 准备模型文件和测试图片编译成功不等于万事大吉强烈建议跑一个完整的推理流程做验证。最简单的方式是用官方训练好的 CaffeNet 或 ResNet-50 模型。需要准备三个文件网络定义 prototxt、训练好的 caffemodel、以及一张测试图片。模型文件去对应项目官方页面下载即可。这里提醒一下有些老模型的 caffemodel 是从 Caffe 的 GitHub 仓库发布页下载的格式没问题但对应的 prototxt 可能依赖一个老版本的 Deploy 头直接跑可能报 Input layer 相关错误。遇到的话把测试图片的尺寸、通道数、均值参数改对就行。5.2 用 caffe.exe 命令行和 Python 接口分别验证命令行验证最简单执行一条类似这样的命令caffe.exe test -model deploy.prototxt -weights bvlc_reference_caffenet.caffemodel -gpu 0 -iterations 1如果能看到测试 loss 和 accuracy 输出说明 C 版本链路正常。Python 接口验证更灵活核心代码就几行import caffe import numpy as np net caffe.Net(deploy.prototxt, bvlc_reference_caffenet.caffemodel, caffe.TEST) transformer caffe.io.Transformer({data: net.blobs[data].data.shape}) transformer.set_transpose(data, (2, 0, 1)) transformer.set_mean(data, np.load(ilsvrc_2012_mean.npy).mean(1).mean(1)) transformer.set_raw_scale(data, 255) net.blobs[data].reshape(1, 3, 227, 227) img caffe.io.load_image(test.jpg) net.blobs[data].data[...] transformer.preprocess(data, img) out net.forward() print(out[prob][0].argmax())这段能跑出指数结果说明 pycaffe 接口的预处理、前向推理、模型文件读取链路都正常。很多人编译成功后跑 Python 报错多数都卡在 transformer 的均值和缩放参数上这一步值得单独验证。5.3 把 Windows 上的 Caffe 模型转到其他框架如果你留 Caffe 是为了老模型迁移那有一个重要步骤导出模型。Caffe 模型转成 ONNX 是常见做法网上工具不少但先在 Windows 本地把 Caffe 跑通是第一步。这就能体现自己编译的好处了转换工具多半是一段 Python 脚本依赖 pycaffe 接口只有编译过 pycaffe 的环境才能运行。转换的时候有个很常见的坑Caffe 模型的 blob 命名和 ONNX 期望的不一致。比如 Concat 层的 output 参数Caffe 里默认是空ONNX 要求显示声明。这类问题没有通用解法基本上就是按照报错信息一个个改 prototxt再重新加载验证。6. 注意事项与最终建议整个 Caffe-Windows 的折腾过程本质上是在跟旧代码、旧工具链、旧依赖做斗争。有几条经验我觉得值得单独拎出来强调一下。第一不要追求新版本。很多人在 Windows 上装 Caffe 习惯性地装最新 CUDA、最新 VS、最新 Python这其实适得其反。Caffe-Windows 的源码绑定了一组特定版本你只要换掉其中一个连锁反应会接踵而至。整套环境尽量按老版本配齐越接近当时作者的开发环境越容易成功。第二备份好编译产物。编译一次 Caffe 至少要二三十分钟如果调试中某个环节把 libcaffe.lib 弄坏了重新编译非常浪费时间。我在踩过一次坑之后每次成功编译完都会把整个 x64\Release 目录压缩备份一份后续出了任何问题直接解压恢复省下的时间完全值得。第三尽量在 conda 虚拟环境里操作 Python 相关的内容。之前说了pycaffe 对 numpy 版本有要求虚拟环境隔离后不会影响你日常用 Python 干活反过来日常升级包也不会把 pycaffe 弄崩。如果问我在实际项目中怎么评价 Caffe-Windows 这套方案我的体会是它确实老、确实折腾、确实有不少历史遗留问题但考虑到大量老模型和学术代码都长在 Caffe 的生态里能在 Windows 下多保留一套可用的 Caffe 环境往往能在关键时刻解决问题。至于后续的新项目我会建议尽快转向更现代、跨平台支持更好的框架但这就是另一个话题了。最后再分享一个小技巧如果你只是偶尔跑一下 Caffe 模型不需要每天开发完全可以把编译好的整个 Caffe 目录拷贝到一个移动硬盘或者网络存储上。这样换机器后只需要把 CUDA 运行时库、依赖 dll 配好直接就能用不需要每次重新编译。这个方法我用了很久相当省心。本文还有配套的精品资源点击获取