简介面向CentOS 7上搭建Caffe深度学习框架的开发者和初学者这份PDF教程完整梳理了从依赖包安装到源码编译的流程涵盖protobuf、leveldb、snappy、opencv、boost、hdf5、gflags、glog、lmdb、openblas等常用组件的安装命令及Makefile配置尤其适合机器无GPU、需开启CPU_ONLY模式的开发者。资源包为1个PDF文件共35KB体量小巧适合在安装过程中随时对照查阅也便于离线使用。目前已有425人学习下载内容直击编译阶段的两大经典报错——缺少cblas.h头文件、找不到-lcblas与-latlas链接库并分别给出安装liblas-devel与atlas-devel、改用OpenBLAS后重新编译的解决方法。读者按步骤操作即可完成make all、make test与make runtest全流程验证规避依赖陷阱快速搭建出可运行的Caffe环境是一份可操作性强、能直接照做的CentOS 7安装指南。1. CentOS7 安装 Caffe一次从依赖到编译的完整落地在 CentOS7 上装 Caffe最折磨人的从来不是 Caffe 本身而是它那套老旧的依赖链。protobuf、leveldb、snappy、OpenCV、Boost、HDF5再加上 BLAS 库的选型任何一个环节版本对不上编译就会在某个头文件上报错而且错误信息往往指向不明让人无从下手。这篇笔记整理了我在某公司服务器上从零装通 Caffe 1.0 的完整流程包括依赖选型、编译参数修改以及两个高频报错的定位与修复。适合刚接触深度学习框架、需要在 CPU 机器上跑通 Caffe 做模型测试的同学参考也适合那些已经被 cblas.h 和 -lcblas 折磨过一轮的运维和算法工程师。2. 依赖包选型先搞清 BLAS 再动手能省一半时间2.1 为什么依赖分两批装顺序和理由Caffe 的依赖大致可以分为三类数据序列化与图像处理、基础数值计算、构建工具链。原作者给出的两条 yum 命令其实已经按功能做了划分但很多教程直接复制粘贴装完也不知道每个包是干嘛的出问题时自然无从排查。第一批命令sudo yum install protobuf-devel leveldb-devel snappy-devel opencv-devel boost-devel hdf5-develprotobuf-devel 提供 Protocol Buffers 序列化支持Caffe 的模型文件.prototxt解析依赖它leveldb 和 snappy 是 Caffe 默认的 LMDB 数据库的底层依赖训练时读写数据集要用opencv-devel 提供图像读取和预处理能力跑视觉任务绕不开boost 是 C 基础库hdf5 用于读取 HDF5 格式的数据集。第二批命令sudo yum install gflags-devel glog-devel lmdb-devel openblas-develgflags 解析命令行参数glog 负责日志输出lmdb 是 Caffe 训练时实际使用的数据存储引擎openblas 则是 BLAS 库的一种实现负责矩阵乘法等数值运算的核心计算。BLAS 是整个 Caffe 编译中最容易翻车的点后文会单独展开。提示建议两批命令分开执行不要合并成一条。第一批装完先确认有没有报错再装第二批。yum 在部分镜像源上会出现找不到 openblas-devel 的情况单独执行方便定位是哪一批出了问题。2.2 BLAS 选型atlas 和 open差别不仅在速度BLASBasic Linear Algebra Subprograms是底层线性代数库Caffe 的所有卷积和全连接层计算都建立在它之上。CentOS7 上常见的选项有三个atlas、open即 OpenBLAS、mkl。mkl 是 Intel 的闭源实现性能最好但安装麻烦需要在 Intel 官网下载CentOS7 的 yum 源里没有。atlas 是 yum 源里自带的安装方便但性能比 OpenBLAS 差一截。OpenBLAS 则在性能和安装便利性之间取了个平衡yum 直接能装后续训练时的 CPU 利用率也比 atlas 高。我在某图像处理Demo上做过对比同样的 LeNet 训练任务OpenBLAS 比 atlas 快 20% 到 30%对于动辄跑几个小时的 CPU 训练来说这个差距很可观。所以如果机器没有 GPU从一开始就用 open 模式不要走 atlas 的弯路。Makefile.config 里对应的修改# BLAS choice: atlas, open, or mkl BLAS : open修改后需要重新编译才会生效make clean make all2.3 protobuf 版本冲突容易被忽略的隐藏炸弹CentOS7 自带的 protobuf 版本是 2.5.0但某些第三方源会把系统 protobuf 升级到 3.x。Caffe 1.0 的代码只兼容 protobuf 2.x版本一旦冲突编译时的报错是google/protobuf/message.h: No such file or directory或者链接阶段出现一堆 undefined reference。网上很多教程遇到这个报错让去源码编译 protobuf其实多半是没查清楚系统里装了几个版本。排查方法# 查看已安装的 protobuf 相关包 rpm -qa | grep protobuf # 查看 protobuf 编译器版本 protoc --version如果发现版本是 3.x且你确认不是自己手动装的很可能是某些依赖自动升级带上来的。解决方式是把 protobuf 降回 2.5.0 并锁定版本sudo yum downgrade protobuf protobuf-devel protobuf-compiler sudo yum versionlock add protobuf protobuf-devel protobuf-compiler我见过有人在某实验室的机器上折腾了两天 protobuf最后发现是装 OpenCV 3.4 时把 protobuf 带到了 3.4.1降级后一次编译通过。编译前先花两分钟查版本绝对值得。3. 下载与配置从源码包到 Makefile.config3.1 下载 Caffe 1.0 并用版本锁定避开 master 分支的坑Caffe 官方仓库的 master 分支已经多年没有大更新但偶尔会有零散的 commit 提交这些提交有时会引入编译问题。最稳妥的方式是下载打了 tag 的稳定版本。1.0 虽然不是 Caffe 唯一的老版本但它是社区使用最广、教程最多、验证最充分的版本。wget -c https://github.com/BVLC/caffe/archive/1.0.tar.gz tar zxvf 1.0.tar.gz cd caffe-1.0-c 参数表示断点续传对于网络不稳定、下载中途断开的情况很实用重新执行命令会从断点继续而不是从头下载。解压后进入 caffe-1.0 目录后续所有操作都在这个目录下进行。复制配置文件cp Makefile.config.example Makefile.configMakefile.config.example 是官方提供的默认配置模板包含所有可选项的说明。复制之后接下来所有针对 CPU 模式的修改都基于这个副本万一改乱了可以随时从 .example 重新复制覆盖。3.2 CPU_ONLY 模式配置注释和启用之间的微妙关系在 Makefile.config 中搜索 CPU_ONLY会看到这样一行# CPU_ONLY : 1注意默认状态是注释掉的前面有个 # 号。这里有个很多新手会犯的错以为是CPU_ONLY : 0改成 1 就行。实际上默认就是 0即关闭 CPU_ONLY你要做的只是把 # 删掉让配置生效。用编辑器打开vim Makefile.config找到对应行修改为CPU_ONLY : 1保存退出。这一步的含义是告诉 Caffe 编译系统不要链接任何 CUDA 相关的库所有计算走 CPU 路径。如果你的机器有 NVIDIA GPU 且装了 CUDA 和 cuDNN就不用改这一行保持注释状态即可。提示修改完 Makefile.config 后建议先执行make clean再重新编译。跳过 clean 可能导致旧的编译缓存干扰新配置出现类似 undefined reference 的玄学报错。3.3 BLAS 配置的完整修改链路在 Makefile.config 中搜索 BLAS默认配置是BLAS : atlas把 atlas 改成 openBLAS : open同时如果之前配置过 BLAS_INCLUDE 和 BLAS_LIB 路径也要检查是否和 OpenBLAS 的实际路径匹配。CentOS7 上 OpenBLAS 的头文件通常在 /usr/include/openblas库文件在 /usr/lib64。Makefile 默认会自动查找一般不需要手动指定但如果你是从源码编译安装的 OpenBLAS路径会不同需要额外配置BLAS_INCLUDE : /usr/local/include BLAS_LIB : /usr/local/lib路径不对时编译会提示找不到 cblas.h 或 -lopenblas这时候按这个思路检查比盲目重装 OpenBLAS 高效得多。4. 编译与验证make all、make test、make runtest 全流程4.1 三阶段编译各自负责什么Caffe 的编译分为三步很多教程一句话带过直接三行命令贴上去跑但理解每一步的作用对排错很有帮助。make allmake all 编译 Caffe 的核心库libcaffe.so和命令行工具caffe 可执行文件。这一步是最耗时的CPU 机器上通常需要 15 到 30 分钟取决于机器配置。建议用 make -j4 或 make -j8 并行编译能明显加速make all -j4-j 后面的数字是并行编译的线程数一般设为 CPU 核心数的两倍以内。我习惯先看下机器核数nproc如果是 8 核用 -j16 编译最快。但注意内存不足时并行编译可能直接 OOM报错信息类似g: internal compiler error: Killed (program cc1plus)这时候把 -j 降到 4 再试。make testmake test 编译单元测试的可执行文件对应 build/test 目录下的二进制文件。如果你只打算用 Caffe 跑推理不跑测试这一步也可以跳过但后续遇到模型数值异常时没有对照基准排查会比较被动。我的习惯是第一次装必须完整跑一遍测试确认环境没问题再投入使用。make runtestmake runtest 实际执行 make test 编译出来的测试程序输出每个测试用例的通过情况。这一步是验证 Caffe 安装是否成功的最终标准比任何教程的安装成功文字都可信。4.2 编译日志的读法哪些警告可以忽略哪些必须处理编译过程中会输出大量警告warning和错误error。初学者容易被满屏的警告吓到其实 Caffe 1.0 在 CentOS7 上用新版 gcc 编译时warning 数量非常多其中大部分是-Wunused-variable、-Wunused-function这类无害警告。需要关注的错误类型fatal error: xxx.h: No such file or directory缺头文件是依赖没装全或路径不对/usr/bin/ld: cannot find -lxxx缺库文件是某些 -l 参数对应的 .so 文件不存在undefined reference to xxx编译能过、链接失败通常是库版本不匹配定位报错时可以配合 grep 缩小范围make all -j4 21 | grep -i error21 把标准错误重定向到标准输出方便 grep 统一搜索。如果报错太多可以输出到文件再慢慢看make all -j4 build.log 21 tail -100 build.log4.3 runtest 通过但个别用例失败先别慌看失败原因再决定runtest 默认会跑全部测试用例正常情况下一两百个用例全部通过。偶尔出现个别失败常见原因有两种一是浮点精度差异某些数值计算用例的断言误差阈值设定较紧CPU 模式下不同 BLAS 实现的计算顺序不同可能导致结果微小偏差二是特定功能的依赖没装全比如 Python 接口相关的测试用例在没装 pycaffe 依赖时就会跳过或失败。查看具体失败原因make runtest 21 | grep -A 5 FAILED如果失败信息和精度相关不影响正常使用不需要过度纠结。如果是undefined reference或找不到库说明某个用例对应的功能模块没编译进去需要回到依赖检查环节。注意runtest 全部通过不意味着万事大吉它只验证了核心库的功能正确性。Python 接口pycaffe需要单独编译模型转换和可视化工具也需要额外配置这两块在下文展开。5. 编译阶段避坑三个真实报错的排查记录5.1 报错一cblas.h not found包名对不上号的坑现象./include/caffe/util/mkl_alternate.hpp:14:19: fatal error: cblas.h: No such file or directory编译走到 mkl_alternate.hpp 时找不到 cblas.h编译器直接退出。这个报错几乎阻塞了所有后续流程网上最常见的解决方式是装 atlas-devel原因在于 cblas.h 这个头文件在 CentOS7 上由 atlas-devel 包提供而不论是 openblas-devel 还是 atlas 本体都不带这个头文件。原因分析Caffe 的 BLAS 层对不同后端做了一层抽象mkl_alternate.hpp 是给非 MKL 后端用的替代实现。它头两行就是#include cblas.h无论 BLAS 选的是 atlas 还是 open编译到这里都需要一个完整的 CBLAS 头文件。OpenBLAS 自己的头文件在 /usr/include/openblas/cblas.h但编译器搜索路径默认不包含这个子目录所以即便装了 openblas-devel还是会报找不到。解决sudo yum install atlas-devel装完之后头文件出现在 /usr/include/cblas.h问题解决。atlas-devel 的作用就是提供 CBLAS 的头文件定义至于底层链接的是 OpenBLAS 还是 Atlas由 Makefile.config 里 BLAS 选项决定。换句话说atlas-devel 和 OpenBLAS 可以共存前者提供编译期头文件后者提供运行期计算实现。我一开始也纠结过这样装会不会冲突实际验证了好几次完全没问题。装了 atlas-devel 之后BLAS 仍然可以保持 open 模式编译和运行都正常。5.2 报错二cannot find -lcblas 和 -latlas链接阶段的两个拦路虎现象/usr/bin/ld: cannot find -lcblas /usr/bin/ld: cannot find -latlas编译已经生成了目标文件但链接成可执行文件或动态库时链接器找不到 cblas 和 atlas 的库文件。这个报错紧跟着上一个出现通常是在 make all 阶段编译完所有 .o 文件后统一链接时报出来的。原因分析默认的 Makefile.config 里BLAS : atlas链接时通过 -lcblas 和 -latlas 找到 libcblas.so 和 libatlas.so。CentOS7 默认没有安装 atlas 的运行时库只有 atlas-devel 提供头文件运行时库需要额外确认ls /usr/lib64/libcblas* ls /usr/lib64/libatlas*如果列表为空说明运行时库确实缺失。而 CentOS7 的源里 libatlas 包的名称比较混乱有时叫 atlas有时叫 atlas-libs这也让不少人在 yum search 阶段就开始卡壳。解决两种路径装包或者换 BLAS。# 方案一安装 atlas 运行时库 sudo yum install atlas # 方案二换成 OpenBLAS推荐 # 编辑 Makefile.config 把 BLAS : atlas 改为 BLAS : open make clean make all方案二的前提是 2.1 节已经装了 openblas-devel。OpenBLAS 的库文件是 libopenblas.so链接时对应 -lopenblas。改完 BLAS 选项后Makefile 会自动把链接参数从 -lcblas/-latlas 切换为 -lopenblas不再需要系统里有 libcblas.so。我在模拟项目X的部署中试过两种方案方案一虽然也能编译通过但后续训练时 CPU 占用率不稳定偶尔出现性能尖刺方案二运行更平稳。所以我的结论是CentOS7 上直接用 OpenBLAS别在 atlas 的运行时库上浪费时间去折腾路径和版本匹配。5.3 报错三g 内部错误 Killed别急着重装系统现象g: internal compiler error: Killed (program cc1plus)编译过程中 g 进程被系统杀掉通常是内存不足的表现不是代码问题也不是 gcc bug。某些大文件如 layer_factory.cpp编译时峰值内存能到 1GB 以上并行编译 -j8 同时跑 8 个编译任务内存不够就容易被 OOM killer 干掉。原因分析CentOS7 服务器如果只分配了 2GB 内存并行编译很容易触发这个错误。另外 swap 空间不足时即使物理内存还有余量系统也可能因为无法分配虚拟内存而杀掉进程。解决# 先用 free -h 确认内存和 swap 情况 free -h # 降低并行度保守起见先 -j2 或 -j4 make clean make all -j2如果内存实在太小还可以临时增大 swapsudo fallocate -l 4G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile这套操作在内存吃紧的云主机上很实用装完 Caffe 后如果不需要可以随时swapoff /swapfile并删除文件。某些开发者习惯直接加大云主机内存规格但对于临时编译任务加 swap 更节约成本。5.4 避坑小结报错信息的两个关键词接触过几十个装 Caffe 的报错后我总结出一个规律绝大多数编译失败可以归为两类——No such file or directory和cannot find -lxxx。前者是缺头文件检查依赖包装全没有、路径对没对上后者是缺动态库检查对应 .so 是否存在、Makefile.config 的 BLAS 指向哪里。抓住这两个关键词90% 的问题都能在十分钟内定位到具体环节。剩下的 10% 是 protobuf 版本冲突这类需要看上下文的场景回到 2.3 节的排查思路即可。6. 安装后验证用 MNIST 跑一次手写数字识别6.1 下载 MNIST 数据集并转换成 LMDBCaffe 自带的脚本支持自动下载 MNIST 数据集并转换成 LMDB 格式。这一步很重要因为它同时验证了数据读取链路LevelDB/LMDB和图像处理链路OpenCV是否正常工作。# 进入 Caffe 根目录 cd caffe-1.0 # 执行 MNIST 数据准备脚本 ./data/mnist/get_mnist.sh # 将原始数据转换为 LMDB 格式 ./examples/mnist/create_mnist.shget_mnist.sh 从 Yann LeCun 的服务器下载四个 gz 压缩包训练图像、训练标签、测试图像、测试标签。create_mnist.sh 调用 Caffe 的 convert_mnist_data 工具把它们转换成 LMDB 数据库。如果转换成功examples/mnist 目录下会出现 mnist_train_lmdb 和 mnist_test_lmdb 两个文件夹。常见问题get_mnist.sh 下载失败因为原始服务器在国外网络不稳定时可能超时。解决方式是手动下载后放进 data/mnist 目录或者配置代理下载四个文件后重新执行 create_mnist.sh。某些环境上 curl 可能没有安装脚本会报curl: command not found先sudo yum install curl解决。6.2 修改 LeNet 训练配置适配 CPU-only 环境Caffe 自带的 MNIST 示例使用的是 LeNet 网络结构训练配置文件 examples/mnist/lenet_solver.prototxt 默认使用 GPU。CPU 机器上需要修改 solver 文件的运行模式# 打开 lenet_solver.prototxt vim examples/mnist/lenet_solver.prototxt找到关键配置项确认以下内容solver_mode: CPU如果默认是 GPU改为 CPU。同时检查 batch_size 的大小CPU 模式 64 的 batch_size 比较稳妥内存不足时可以改小到 32 或 16。迭代次数和测试间隔保持默认即可主要目的是验证链路通畅。6.3 启动训练并观察日志中的关键指标# 开始训练 ./examples/mnist/train_lenet.shtrain_lenet.sh 实际执行的是caffe train --solverexamples/mnist/lenet_solver.prototxt。训练启动后每个迭代周期会输出一行日志包含损失值loss、学习率lr和训练用时。关键观察点前几个迭代的 loss 应该在 2.3 左右然后逐步下降迭代到 100 轮时 loss 一般降到 0.5 以下测试阶段的 accuracy 从最初的 0.9 左右逐步逼近 0.99如果在 CPU 模式下训练速度很慢比如单轮迭代超过 5 秒可以调小 batch_size 换取更快的迭代周期。MNIST 全部训练完大概要一万多次迭代CPU 机器上大约需要 30 到 60 分钟。不需要全部跑完看到前几百轮 loss 稳定下降说明环境链路已经通了。6.4 验证模型的最终产出物训练完成后examples/mnist 目录下会生成 lenet_iter_10000.caffemodel 和 lenet_iter_10000.solverstate 两个文件。前者是训练好的模型权重后者是优化器状态用于断点续训。执行测试./build/tools/caffe test -model examples/mnist/lenet_train_test.prototxt -weights examples/mnist/lenet_iter_10000.caffemodel -iterations 100测试输出的 accuracy 如果稳定在 0.99 左右说明整个链路包括数据转换、模型定义、网络前向传播、权重复用全部正常。这套验证流程我每次配完新环境都会完整走一遍从依赖安装到模型产出每个环节都覆盖到对应模块的功能验证。从那以后任何环境上跑 Caffe我都至少完成一次 MNIST 全流程才敢说环境是可用的——这不仅验证了框架本身也把数据管道、文件权限、磁盘空间这些隐藏因素一并排除了。希望这篇笔记能帮你少踩几个坑。本文还有配套的精品资源点击获取
