简介：Caffe深度学习框架的Windows版本资源包，面向想在Visual Studio与CUDA环境下使用Caffe、但不愿从零配置Linux环境的开发者。压缩包内含完整源码树与构建辅助文件，覆盖从编译到测试的常见需求，可显著降低Windows端的安装门槛。

资源共888个文件，总大小8.67MB，核心类型包括cpp/hpp源文件、cu/cuh GPU内核、prototxt网络描述、py/m脚本接口，以及cmake/vcxproj/sln工程配置，目录结构沿官方Caffe布局组织。已有293人学习，适合深度学习入门者及需要在Windows上训练或部署模型的工程人员。

包内提供GeneratePB.bat等辅助脚本、gtest单元测试文件、MNIST训练示例及多种网络定义，配合CMake与Visual Studio工程文件，可快速完成CPU/GPU环境编译、接口验证与模型训练，是动手实践Caffe的实用资料。

1. caffe-windows是个什么东西：为什么老模型离了它跑不起来

如果你这些年一直在 Linux 上玩深度学习，突然拿到一个基于 caffe 训练的模型，要在一个 Windows 机器上复现推理，大概率会卡在第一关：caffe 官方并不原生支持 Windows，源码拉下来连编译都过不去。而这个 caffe-windows 资源，就是把这个问题替你解决了的一个可编译工程包。它自带 VS 解决方案、三方依赖、示例脚本和模型文件，核心价值在于让你不用自己去拼一堆老版本依赖链，直接打开工程就能把 caffe 的 CPU/GPU 版本编出来，跑通经典的 MNIST 训练和 CaffeNet 分类。适合需要复现老论文实验、接手别人的 caffe 工程、或者在 Windows 上做迁移学习的从业者。别指望它有新框架那种开箱即用的体验，它更像一把需要拧对几个螺丝才能用的老式钳子。

2. 环境准备：VS版本、CUDA与依赖库的对应关系，为什么必须一次核对完

2.1 版本组合是 caffe-windows 的第一道门槛

我用过好几版 Windows 上的 caffe 工程，最大的感受是：编译不过，十次有八次不是代码问题，而是版本搭配问题。caffe 是 2014 年左右开始流行的框架，它的依赖库版本停留在一个特定时期，跟你机器上最新的 VS、最新的 CUDA 往往配不上。

这个 caffe-windows 工程包里面，通常会给出几个版本的配置文件，比如CommonSettings.props里会区分 VS2013、VS2015、VS2017 的路径映射。我见过不少人是这样翻车的：机器上装的是 Visual Studio 2022，打开工程的.sln提示需要升级工具集，手一抖就点了“确定”，结果编译到一半全是 C++ 标准库的语法错误，比如std::unary_function被删掉之类的老接口消失问题。原因很简单，caffe 的老代码是按 C++11 写的，VS2022 默认用的是 C++17 标准，很多旧写法会被标记为 error，而且新版 MSVC 对模板实例化更严格，老代码直接被拒。

我一般会这样处理：如果只是想快速跑通，优先用 VS2015 或者 VS2017，这两个版本对 caffe 老代码兼容性最好。系统是 Win10 或 Win11 都没问题，VS2015 编译出来的程序在 Win11 上一样能跑，不需要操作系统严格匹配。如果非要装在 VS2019 上，需要在属性管理器里把每个项目的PlatformToolset改为v142，然后单独处理 C++ 标准版本，遇到的编译错误多一些，但也不是完全不能走。

2.2 CUDA 与 cuDNN：版本不匹配是玄学重灾区

GPU 版本的 caffe 依赖 CUDA 和 cuDNN。这个 caffe-windows 工程包里，CommonSettings.props里面会写死一个默认的 CUDA 路径，比如C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0。如果你机器上装的是 CUDA 11.x，这个路径根本不存在，编译到 cuDNN 相关的源文件时直接报“找不到 cudnn.h”。更隐蔽的坑是：CUDA 11 的算力代码生成机制跟 CUDA 8/9 不一样，就算你把路径改对了，编译出来的 kernel 在你的新显卡上可能直接报 “no kernel image is available for execution on the device”。

所以在动手编译之前，我强烈建议你先把自己的 GPU 算力查一下，表格放在下面供参考，不同架构对应不同的 sm 值。

如果你确定只是做 CPU 推理，那更简单，把CommonSettings.props里的UseCUDA和UseCuDNN都设为false，后面所有跟 CUDA 相关的编译选项都会绕开。CPU 模式下 caffe 跑 MNIST 训练也没问题，就是慢一些，几分钟一个 epoch，做验证完全够。

2.3 三方依赖库：NuGet、OpenCV、Python 路径怎么统一

这个 caffe-windows 工程包一般把三方依赖放在了3rdparty目录，包含glog、gflags、protobuf、lmdb、leveldb、opencv、hdf5这些库的预编译静态库和 DLL。好处是省去了手动编译这些库的时间，坏处是它们的运行库版本和你机器上的 VS 运行库必须匹配。比如 3rdparty 里的 DLL 是用 VS2015 编译的，而你的系统里只装了 VS2019 的 VC++ Redistributable，一般没问题，因为 VS2015-2022 的运行库是二进制兼容的。但如果你拿到的是用 VS2013 编译的依赖包，那运行的时候就会遇到各种内存分配相关的诡异崩溃。

你需要重点检查的是这几项配置：

<PythonSupport>true</PythonSupport> <MatlabSupport>false</MatlabSupport> <OpenCV3>true</OpenCV3> <UseCuDNN>true</UseCuDNN> <UseCPUOnly>false</UseCPUOnly> <NugetPackageDirectory>$(SolutionDir)packages\</NugetPackageDirectory>

这段配置位于 caffe-windows 工程根目录的CommonSettings.props文件里。PythonSupport控制是否编译 pycaffe 接口；MatlabSupport同理；OpenCV3表示使用 OpenCV 3.x，如果你用的是包内自带的 opencv，保持默认即可；UseCuDNN控制是否使用 cuDNN 加速；UseCPUOnly为 true 时会忽略 CUDA 配置；NugetPackageDirectory定义了 NuGet 包的恢复路径。如果开启了 NuGet 自动恢复，首次编译时会从网上下载一部分缺失的依赖包，网络不好时这个过程会卡很久，我通常会在3rdparty齐全的情况下把EnableNuGetPackageRestore设为 false，完全离线编译。

还有一个很容易忽略的点：Python 路径。如果你打算使用 pycaffe，CommonSettings.props里需要指定PythonDir，指向你 Anaconda 的根目录，比如D:\Anaconda3\。这里的路径斜杠必须带反斜杠结尾，且 Python 版本位数必须与 caffe 编译平台一致，也就是 x64 编译对应 64 位 Python，否则链接python37.lib时会报 LNK1112 之类的位数不匹配错误。

2.4 写一个环境自检脚本，比反复翻配置文件省事

环境检查不该靠肉眼，我每次拿到新的 caffe-windows 工程副本，都会先跑一个简单脚本，确认关键的版本信息落在预期范围，再决定怎么改配置。

@echo off rem 检查 VS 版本号 cl 2>&1 | findstr /i "Version" rem 检查 CUDA 版本 nvcc --version | findstr /i "release" rem 检查 Python 版本和位数 python -c "import struct;print(struct.calcsize('P')*8)" rem 检查 cuDNN 头文件里的版本宏 findstr /C:"CUDNN_MAJOR" "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\include\cudnn.h"

脚本的作用是先把编译依赖的五个关键项一次性列出来：MSVC 版本、CUDA release 版本、Python 位数、cuDNN 主版本号。逻辑很简单，就是用各自自带的命令行工具打印版本号。需要注意，cl是 VS 的 C++ 编译器，必须在 VS 开发者命令行里运行，普通 cmd 窗口会提示找不到命令。nvcc同理需要 CUDA 的 bin 目录加入 PATH。如果python命令没有指向你打算给 caffe 用的那个解释器，建议直接用绝对路径执行，比如D:\Anaconda3\python.exe -c "..."，避免 PATH 里多个 Python 互相干扰。

3. 编译流程：从.props到caffe.exe的三个步骤，参数逐个说清楚

3.1 配置阶段：.props 文件是最核心的开关面板

整个 caffe-windows 编译过程，本质上就是围绕CommonSettings.props和caffe.sln两个文件做的操作。.props文件相当于 MSBuild 的公共属性面板，VS 里打开属性管理器能看到，它在每个项目的属性生效之前被加载，所以你在里面定义的路径、开关、宏，会被所有子项目继承。

我第一次用这个工程的时候，直接打开.sln就按 F5 编译，结果报了“无法找到 cudnn.h”这类错误。后来才明白，CommonSettings.props里有几个选型参数必须提前确认：

<CudaArchitecture>sm_61</CudaArchitecture> <CudaArchitecture Condition="'$(CudaArchitecture)' == ''">sm_52</CudaArchitecture>

CudaArchitecture决定 CUDA 编译器为哪种 GPU 架构生成机器码。如果你的显卡是 GTX 1060，计算能力是 6.1，填sm_61编译出的 kernel 就能直接用。如果填高了，比如填sm_75而你的显卡是 Pascal 架构，运行时就会报“no kernel image is available”。这个参数可以直接在命令行里覆盖：msbuild caffe.sln /p:CudaArchitecture=sm_61。还有一种做法是同时列出多个架构，用分号分隔，但那样编译时间会成倍增加，不推荐。

还要注意CpuOnlyBuild参数，如果设成 true，caffe 会编译成纯 CPU 版本，所有caffe_gpu相关的源文件都会被排除，链接时也不需要 CUDA 库。CPU 版本对入门用户其实是更稳的选择，因为少了一半的编译错误可能。

3.2 命令行编译：libcaffe、caffe、pycaffe 这三个目标怎么选

VS 界面编译适合交互式排错，但如果你要反复清洁重编，命令行 msbuild 是更好的方式。下面的命令依次执行，先编核心静态库，再编命令行工具，最后编 Python 接口。

rem 进入 VS 开发者命令行环境（x64 版本） call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Auxiliary\Build\vcvars64.bat" rem 编译核心库 libcaffe，这是整个工程的心脏 msbuild caffe.sln /t:libcaffe /p:Configuration=Release /p:Platform=x64 /m rem 编译命令行工具 caffe.exe msbuild caffe.sln /t:caffe /p:Configuration=Release /p:Platform=x64 /m rem 编译 Python 接口 pycaffe msbuild caffe.sln /t:pycaffe /p:Configuration=Release /p:Platform=x64 /m

/t后面跟的是 MSBuild 的 target 名称，对应解决方案里的项目名，不是文件名。/p:Configuration=Release指定 Release 配置，/p:Platform=x64指定 64 位平台，/m表示并行编译加速。这一步最容易出问题的是libcaffe编译期间的 proto 生成步骤，caffe 的网络描述文件caffe.proto需要先用protoc生成caffe.pb.h和caffe.pb.cc，VS 工程里这一步骤是作为编译前事件自动完成的，但如果你的protoc版本和工具链不匹配，生成的头文件会说缺失，需要手动执行一次 protoc 命令。

3.3 修改源码适配高版本 CUDA：老工程的必经手术

如果你的 CUDA 版本超过 10.0，直接编译大概率会遇到caffe/proto/caffe.pb.h这类报错之前，先在一处源码挂掉：include/caffe/util/device_alternate.hpp里有一个判断 GPU 是否可用的宏，老代码用的是cudaDeviceProp和cudaGetDeviceProperties，新版本 CUDA 把一些cudaDeviceProp的成员变量标记为 deprecated，但不至于编译失败。真正会编译失败的是CUDNN_CONVOLUTION_FWD_ALGO_IMPLICIT_PRECOMP_GEMM这类枚举值，在 cuDNN 7 以后某些算法枚举被改名或废弃。

遇到这种情况，我一般会先关闭UseCuDNN用纯 GPU 模式编译，等跑通了再针对 cuDNN 相关代码做具体修改。纯 GPU 模式只依赖 CUDA 核心库，不依赖 cuDNN，兼容性宽泛得多。如果你想硬上 cuDNN，常见做法是在cudnn.hpp里把废弃的枚举映射到新版对应枚举，比如把CUDNN_CONVOLUTION_FWD_ALGO_IMPLICIT_PRECOMP_GEMM替换成CUDNN_CONVOLUTION_FWD_ALGO_IMPLICIT_GEMM，这在大部分卷积场景下是等价的，但到 ResNet 这种深层网络时性能会有明显差异，具体取舍看你的使用场景。

3.4 编译输出的东西在哪、怎么确认成功

编译成功后，输出目录一般在build\x64\Release\下面，这个目录里会有下面几个核心产物。表格可以帮你快速确认该找什么文件。

编译成功的标志是 msbuild 输出结尾出现Build succeeded，而且上述文件都真实存在。有个细节：pycaffe 的caffe.pyd在 Release 目录下，但python/caffe目录里的.py文件需要被 import 时的路径找到，通常做法是把build\x64\Release\和python\两个路径都加入PYTHONPATH环境变量，否则import caffe会报找不到模块。

4. 避坑清单：编译失败与运行时崩溃的五个常见场景，现象、原因、对策

4.1 场景一：caffe.pb.h 文件缺失导致的首次编译失败

你在编译 libcaffe 时发现错误列表里先是“无法打开包括文件: 'caffe/proto/caffe.pb.h'”，然后跟着几百个依赖它的红错，看起来像是源码不全。

原因是 caffe.proto 的描述文件还没有被 protoc 编译器生成出头文件。VS 工程里虽然配置了“生成代码”的预编译事件，但protoc.exe的路径有时候没有正确指定，或者碰巧被别的版本的 protobuf 工具抢占了。

解决的顺序是：先看看src\caffe\proto\caffe.proto这个文件在不在。在的话直接手动跑一次 protoc：

rem 进入 3rdparty 里 protobuf 工具目录，不同版本路径略有差异 protoc.exe -I=.\src\caffe\proto --cpp_out=.\include\caffe\proto .\src\caffe\proto\caffe.proto

执行完检查include\caffe\proto\caffe.pb.h是否生成。如果 protoc 版本太新，生成的代码可能要配 C++17 才能编译，这时候建议换用工程 3rdparty 里自带的老版 protoc，尽量不要用系统安装的最新版。需要注意，caffe.pb.cc文件默认生成在当前的--cpp_out目录，你可能还需要把它挪到源码树对应的位置，或者让 VS 工程能自动找到。

4.2 场景二：python 扩展编译不通过或 import 后崩溃

pycaffe 编译报错链接失败，或者在import caffe后直接进程崩掉，没有任何 Python 报错信息，只是弹窗“python.exe 已停止工作”。

原因通常是 Python 版本、位数、或者运行库不一致。caffe 的 Python 接口是 C++ 扩展，它链接到python39.lib等导入库，同时运行时需要用同一个 Python 解释器去加载.pyd。如果你编译时指定的PythonDir是 32 位 Python 的路径，而 caffe 本身是 x64 编译的，链接阶段就会报 LNK1112 或 LNK2005。另一种可能：电脑上安装了多个 Python，import caffe时某个 Python 去加载了针对另一个版本编译的.pyd。

解决方法是：在CommonSettings.props里把PythonDir指向你要用的那个解释器根目录，确保它是 64 位的，然后用同一个解释器执行下面的验证：

import sys, struct print(sys.version) print(struct.calcsize("P") * 8) # 输出 64 表示解释器是 64 位

需要注意：即使在 Windows 命令提示符里输入python显示的路径正确，也要确认这个路径跟编译时PythonDir指向的是同一份，尤其是你使用了 Anaconda 就一定要用 Anaconda 自带的python.exe，不要用 Windows 应用商店默认安装的那个短链接入口。

4.3 场景三：运行时提示缺少 DLL，程序无法启动

编译全部成功，caffe.exe --version一跑就弹窗“找不到 libglog.dll”或“找不到 cudnn64_7.dll”，程序根本无法启动。

原因是 caffe 依赖的三方库 DLL 没有被系统找到。它们在 3rdparty 的bin或lib目录里静静地躺着，但没有进入 PATH 环境变量，也没有被复制到 caffe.exe 所在目录。

解决方法是把3rdparty\bin目录和 CUDA 的bin目录都加入系统 PATH。如果需要保持环境干净，也可以直接把3rdparty\bin下的*.dll复制到build\x64\Release\里，一劳永逸但不优雅。我用的是后者，因为复制的 DLL 跟着 exe 走，换机器部署不容易漏，代价是占用一些存储空间。如果加入 PATH 依然报缺少别的 DLL，可以在命令行里用dumpbin /dependents caffe.exe查看完整的依赖清单，逐个对照 3rdparty 目录排查。

4.4 场景四：GPU 模式下训练时显存报错或性能极低

训练启动后很快报Check failed: error == cudaSuccess (2 vs. 0) out of memory，甚至直接把显存吃光后系统卡死。还有一种情况是不报错但速度慢到比 CPU 还差，GPU 利用率几乎为 0。

显存不足的原因一方面是你的batch_size设得太大，在solver.prototxt里 batch_size 和模型输入分辨率共同决定单次迭代显存占用，而 caffe 默认会在每个test_iter里做完整测试集推理，可能一次性把显存冲爆。另一方面是 caffe 的 CUDNN 模式会为每一个卷积层预留工作空间，cudnn_conv_workspace参数如果配置得太大，也会加速显存消耗。性能低下的原因集中在前面提到的 CudaArchitecture 设置不对，kernel 在 GPU 上做了 JIT 编译，或走了兼容模式的老代码路径。

解决要分两步：先把solver.prototxt里的batch_size调小，比如从 128 降到 32，同时把test_iter调小，或者干脆注释掉测试阶段先训几轮看显存曲线。然后把CommonSettings.props里的CudaArchitecture精确改为你的显卡型号对应的sm_XX值，例如 RTX 2080 Ti 用sm_75，GTX 1080 用sm_61。改完需要重编 libcaffe 和 caffe，因为 kernel 编译信息是编译期嵌入的，不是运行时读配置文件。

4.5 场景五：网络结构改动后报维度不匹配，前向对齐困难

你已经按照论文把deploy.prototxt改了层结构，比如把全连接层换成了 GAP（全局平均池化），准备用原模型做迁移学习，但一跑caffe test就报Error: Shape mismatch in blob 'fc8'...，改了半天也不知道哪层算错了。

原因本质上不是代码缺陷，而是 caffe 的 blob 形状依赖前一层的输出通道和池化核大小连续推导，任何一层尺寸变化都会往后传导，报错信息只显示当前 mismatch 点，不会告诉你最早是从哪一层偏差开始的。

解决方法是写一个小脚本，逐层打印 blob 的 shape，对着你的网络结构纸核对每一层。下面是一个在 Linux 和 Windows pycaffe 都能跑的检查脚本：

import caffe net = caffe.Net("deploy.prototxt", "weights.caffemodel", caffe.TEST) for name, blob in net.blobs.items(): print(name, list(blob.data.shape))

脚本作用是遍历网络中每一层的前向输出张量并打印形状。net.blobs是一个 OrderedDict，键是层名，值是 blob 对象，blob.data.shape给出 (N, C, H, W)。需要注意deploy.prototxt里最后必须包含input_shape或者input_dim，否则脚本直接报错。只有当你对全链路的 shape 都确认无误后，才算真正解决了 mismatch 问题。要求不高的场景，也可以直接用caffe.Net的参数caffe.TEST忽略掉训练阶段的 loss 层，只看主干网络输出。

5. 验证部署：MNIST训练与Python分类接口的真实跑法

5.1 数据转换：从原始二进制到 lmdb 的必经之路

任何 caffe 网络的训练和测试，输入数据都得是 lmdb 或 leveldb 格式，caffe 不直接吃图片文件夹。这个 caffe-windows 工程包在data\mnist目录下放了 MNIST 原始数据的下载脚本，但 Windows 上没有 Linux 的wget，我一般直接手工下载那四个 gz 文件，放在data\mnist\下。

解压后用工程自带的convert_mnist_data.exe转到 lmdb：

build\x64\Release\convert_mnist_data.exe ^ data\mnist\train-images-idx3-ubyte ^ data\mnist\train-labels-idx1-ubyte ^ examples\mnist\mnist_train_lmdb ^ 0

四个参数分别是：训练图像文件路径、训练标签文件路径、输出 lmdb 目录、是否需要打乱数据（0 表示不打乱）。这个工具内部按固定格式读取 MNIST 的 magic number 和图像尺寸，如果你的原始文件不是 MNIST 标准格式，这一步就会崩溃。转换成功后会生成data.mdb和lock.mdb两个文件，这是 lmdb 启动时自动创建的，看到它们就说明转换成功。

5.2 训练参数解读：solver.prototxt 里每行都能改出不同效果

接下来看examples\mnist\lenet_solver.prototxt，这个文件是训练控制台。核心参数我用一个表格列出，方便你对照自己的训练任务去替换。

训练命令很简单：

build\x64\Release\caffe.exe train --solver=examples/mnist/lenet_solver.prototxt

如果一切顺利，几分钟内会开始打印迭代日志，能看到每一轮的 loss 逐渐下降，测试阶段会输出 accuracy。如果你只是想验证环境，不想等完整训练，可以改max_iter成 200，或者直接在命令行覆盖参数：caffe train --solver=... --max_iter=200。需要注意的是，这种命令行覆盖方式在某些老版本 caffe 里不生效，所以最稳妥的还是直接编辑 solver 文件。

5.3 Python 接口：用 CaffeNet 做一张图片的分类

训练跑通之后，更实用的验证是 Python 接口。这个过程中最常见的需求是加载预训练模型bvlc_reference_caffenet.caffemodel，对一张图做分类。代码不长，但每一步都有讲究：

import caffe import numpy as np # 设置网络为测试模式，读取结构和权重 net = caffe.Net( "models/bvlc_reference_caffenet/deploy.prototxt", "models/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel", caffe.TEST ) # 配置输入预处理，把 HxWxC 的图片转换成 CxHxW transformer = caffe.io.Transformer({"data": net.blobs["data"].data.shape}) transformer.set_transpose("data", (2, 0, 1)) transformer.set_mean("data", np.load("python/caffe/imagenet/ilsvrc_2012_mean.npy").mean(1).mean(1)) transformer.set_raw_scale("data", 255) transformer.set_channel_swap("data", (2, 1, 0)) # 送入一张图片，注意必须 reshape 成 batch 大小 net.blobs["data"].reshape(1, 3, 227, 227) image = caffe.io.load_image("examples/images/cat.jpg") net.blobs["data"].data[...] = transformer.preprocess("data", image) # 前向传播，得到分类概率 output = net.forward() prob = output["prob"][0] top_k = prob.argsort()[-5:][::-1] print(top_k, prob[top_k])

代码的逻辑分四段：载入网络、构造预处理流水线、送入图片、取 top 结果。容易出错的细节在transformer.set_mean那一行，ilsvrc_2012_mean.npy是 3 通道均值图，caffe 官方给的均值是 227x227x3 的格式，而这里用.mean(1).mean(1)把它压缩成 3 个通道均值，这个是简化处理，对单张图片分类影响很小。set_channel_swap处理的是 RGB 与 BGR 通道顺序，caffe 预训练模型基于 BGR 图像训练，所以这一步不能省。如果你用自己的图片做测试，注意caffe.io.load_image会读取成 [0,1] 范围的浮点图，所以后面要乘以raw_scale255。

5.4 服务化前验证：命令行工具也能直接测单张图片

有些场景你不想写 Python 脚本，比如部署在纯 C++ 环境里，那就可以用caffe.exe自带的test或classify功能。但老版 caffe-windows 默认不带 classify 功能，需要自己编译tools/classification.cpp，相对繁琐。更轻量的做法是写一个极短的 Batch 文件循环调用caffe.exe test，不断更换测试集来验证模型稳定性，或者直接采用caffe time来评估前向推断耗时：

build\x64\Release\caffe.exe time -model models/bvlc_reference_caffenet/deploy.prototxt ^ -weights models/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel ^ -iterations 100

time子命令会执行指定次数的前向和反向传播，输出平均每层耗时和总耗时，这个数据对于判断 GPU 是否真正在工作很有价值。如果所有层的耗时都在 0.1 ms 级别，说明 GPU 可能根本没被唤起，回去检查 CudaArchitecture 设置。100 次迭代的耗时数据已经足够稳定，不需要设更大。

6. 进阶用法：把Caffe模型参数洗成numpy，为迁移学习铺路

caffe 自带的老接口虽然不够新潮，但它的模型结构非常透明，你可以从deploy.prototxt里看到每一层的名字和参数形状，这就有了一个在别的框架里很难得的优势：把任意层权重导出成通用格式，供 PyTorch、TensorFlow 或者其他工具消费。这一步最典型的需求就是，你手里只有 caffe 老模型，但你的整个训练管线已经迁到了 PyTorch，不想为了一个旧模型重新搭 caffe 环境。

导出权重的核心思路很简单：遍历net.params字典，把每个名字对应的 blob 数据存成 numpy 的压缩包。

import caffe import numpy as np net = caffe.Net("deploy.prototxt", "xxx.caffemodel", caffe.TEST) for layer_name, param_blobs in net.params.items(): arrays = [np.array(blob.data) for blob in param_blobs] np.savez(f"weights/{layer_name}.npz", *arrays)

逻辑说明：net.params是层名到参数 blob 列表的映射。对于卷积层，blobs[0]是卷积核，形状是 (输出通道, 输入通道, 核高, 核宽)，blobs[1]是偏置，形状是 (输出通道,)。全连接层同理，blobs[0]是权重矩阵，blobs[1]是偏置，但形状是 (输出维度, 输入维度)。保存之后，每个.npz文件可以直接被np.load读取，拿到原始参数矩阵，再配合现代框架的load_state_dict或from_pretrained做权重初始化。

这里有一个必须注意的差异：caffe 的卷积核布局是 (C_out, C_in, H, W)，而 PyTorch 是 (C_out, C_in, H, W)，看起来很一致，但全连接层 caffe 的形状是 (C_out, C_in)，PyTorch 是 (C_in, C_out)，需要转置. 我第一次做转换时就因为这个转置问题，在模型微调时损失完全降不下去，白跑了一个多星期。从那以后，我每次加载 caffe 权重都会用一个小脚本把每个层的 shapes 先打印出来，手工核对一遍再放进训练代码里。

做完权重导出之后，还有一件事值得做：利用 caffe 的前向网络作为特征提取器。比如你只需要倒数第二层的输出，用来做图片检索或者训练一个小型分类器，那就不用像上面那样导出全部权重，只需要用 caffe 的前向传播保存中间层特征。

net.blobs["fc7"].data[0].copy()

这个过程相当于把 caffe 当作一个特征仓库，你只需要写少量代码，就能把任意层的特征批量落盘。唯一的代价是你必须保留 deploy.prototxt 和训练时的预处理流程，特别是 mean 值，否则特征分布跟预训练状态不一样，下游模型的精度会受直接影响。我一般会把transformer里的 mean 值也同步保存成一个.npy文件，跟特征一起留档，方便以后回查。caffe-windows 工程本身虽然老，但模型权重是通用的，只要你能把参数安全取出来，后面的路就宽了。希望帮到你。

本文还有配套的精品资源，点击获取