手机上的 AI - 在 Android/iOS 上运行 Caffe 深度学习框架

目录 开源

目前在云端基于各种深度学习框架的 AI 服务已经非常成熟,但最近的一些案例展示了在移动设备上直接运行深度神经网络模型能够带来很大的处理速度优势。比如 Facebook 在官方博客上发布的可在移动设备上进行实时视频风格转换的应用案例 “Delivering real-time AI in the palm of your hand”。其中提到 Caffe2go 框架加上优化后的网络模型,可以在 iPhone6S 上支持 20FPS 的视频风格转换。Google Tensorflow 也提供了 iOS 和 Android 的 example

Caffe 是一个知名的开源深度学习框架,在图像处理上有着非常广泛的应用。Caffe 本身基于 C++ 实现,有着非常简洁的代码结构,所以也有着很好的可移植性。早年也已经有了几个 github 项目实现了 Caffe 到 iOS/Android 平台的移植。但从我的角度来看,这些项目的编译依赖和编译过程都过于复杂,代码也不再更新,而且最终产出的产品包过大。caffe-compact 最接近我的思路,但是在两年前未完工就已经不更新了。

从我个人在 APP 产品上的经验来看,移植深度学习框架到 APP 中,不仅仅是能不能跑,跑不跑得快,还有个很重要的因素是包大小问题。因为一般用深度学习模型只是实现一个产品功能,不是整个产品。一个产品功能如果对 APP 包大小影响太大,很多 APP 产品都无法集成进去。我希望依赖库能尽量地精简,这样打包进 APP 的内容能尽量地少。所以我在春节期间在 github 上启动了一个 Caffe-Mobile 项目,将 Caffe 移植到 Android/iOS 上,并实现了以下目标:

NO_BACKWARD:手机的电量和计算能力都不允许进行模型训练,所以不如干脆移除所有的后向传播依赖代码,这样生成的库会更小,编译也更快。

最小的依赖。原始的 Caffe 依赖很多第三方库:protobuf, cblas, cuda, cudnn, gflags, glog, lmdb, leveldb, boost, opencv 等。但事实上很多依赖都是没必要的:cuda/cudnn 仅支持 GPU, gflags 仅为了支持命令行工具,lmdb/leveldb 是为了在训练时更高效地读写数据,opencv 是为了处理输入图片,很多 boost 库都可以用 c++0x 库来替换。经过精简和修改部分代码,Caffe-Mobile 的第三方库依赖缩减到两个:protobuf 和 cblas。其中在 iOS 平台上,cblas 用 Accelerate Framework 中的 vecLib 实现;在 Android 平台上, cblas 用交叉编译的 OpenBLAS 实现。

相同的代码基,相同的编译方式。两个平台都采取先用 cmake 编译 Caffe 库(.a or .so),然后再用对应平台的 IDE 集成到 app 中。编译脚本使用同一个 CMakeList.txt,无需将库的编译也放到复杂的 IDE 环境中去完成。

可随 Caffe 代码更新。为了保证开发者能追随最新 Caffe 代码更新,我在修改代码时使用了预编译宏进行分支控制。这样进行 diff/patch 时,如果 Caffe 源码改动较大,merge 时开发者可以清楚地看到哪些地方被修改,是如何改的,更方便 merge 最新更新。

除了 Caffe 库外,在 Caffe-Mobile 项目中还提供了 Android/iOS 两个平台上的最简单的 APP 实现示例 CaffeSimple,展示了在手机上使用 Caffe example 里的 MNIST 示例(深度学习领域的 Hello World)训练出来的 LeNet 模型预测一个手写字符 “8” 图片的过程和结果。 Caffe-Mobile 项目的地址在:https://github.com/solrex/caffe-mobile 欢迎体验,感兴趣的同学们也可以帮忙 Star 下 :)

Jabra Freeway车载蓝牙

目录 玩物

本人有幸在北京市缩减摇号规模前,半年,摇到了一个小客车指标,购入了一辆 2013 款别克凯越汽车。当然,出于一贯地性(kou)价(men)比考虑,选择了自动挡低配款,也就是 14 寸钢轮毂、无天窗、无 VoiceLink、非真皮座椅、无倒车雷达。通过团友的争取,倒是赠送了倒车雷达——这东西的确有用。

开车总有需要打电话的时候,虽然不愿意冒险手持来接,但每次上车都要塞耳机也挺烦人的,于是穷人就开始羡慕高端的车载蓝牙。一个偶然的机会发现了 Jabra Freeway 这个车载蓝牙,据说美国亚马逊打折,我就拜托一个同学帮忙买了一个。价钱是450块不到,比京东卖的便宜多了。使用了半年,这里整体做个评价,供感兴趣的朋友参考。

Jabra Freeway
充电中的 Jabra Freeway

这个东东用法呢,就是卡在汽车的遮光板上,当作车载蓝牙使用,免去了(忘)戴蓝牙耳机的烦恼。从我的使用过程来看,有几个优点值得夸一下。

一是易用。自动感应开关车门开关机,进入汽车以后蓝牙就会自动连接上;可连接两部蓝牙手机;连接部分手机时,可以在手机上显示 Freeway 的剩余电量;来电自动播报号码或姓名。这样上下车时完全不用理会它的存在,来电后只要点一下最大的通话按钮就能接通,省心。

二是声大。在声音表现上,其实它就是个蓝牙音箱,而且你在外出时也完全可以把它就当成个音箱用。这个音箱的声音能盖过车载音响。如果上高速或者车里开着广播,手机导航的播报声音就会显得很小,有 Freeway 放大音量,完全没有任何问题。音量控制按钮也很清楚,不会按错。

三是耐用。充一次电,差不多能撑两三个月,还是在经常使用导航外放音量的情况下。可以直接连点烟器充电,即使路上没电了也不用担心。

因为车载音响播放的是 U 盘,很方便,完全不需要手机通过 Freeway 再用 FM 发射音乐到车载音响。所以高级功能 RDS 完全没用过,不予评价。

下面说一下缺点,就是傻!在买来的第一天,我就把它刷成了中文系统,因为这样才能准确念出来电的联系人名字。但我发现这是 Freeway 中文版的唯一好处。Freeway 本来可以靠语音命令来调出“接听、重拨、回拨、电量、配对”等功能,但无论我尝试多少次,中文版的 Freeway 只能识别“配对”和“我能说什么”这两个命令,而且会把所有其它命令都识别成这两个其中之一。所以,在我这里,中文版的 Freeway 语音控制系统几乎是不可用状态。

总体来说,在关键的功能上,Jabra Freeway 没有让我失望,要知道好一点的蓝牙音箱或者蓝牙耳机也得两三百,Freeway 总比那些强多了。要是 Jabra 认真地做一下 Freeway 的中文版固件,把语音识别率做高一些,就完美了。

更新:13 年 9 月 Jabra 更新了一下固件,语音命令识别比原来好多了!

TCP Fast Open by Google 浅析

目录 IT杂谈, 无线和移动

Google 将在今年 12 月的 ACM CoNEXT 会议上发表他们在改善 Web 应用响应时延方面的一个工作,通过修改 TCP 协议利用三次握手时进行数据交换的“TCP Fast Open”。虽然 paper 是两天前才释出,但相关的 RFC 草案则早在 2011 年 3 月份就提交到了 IETF,并且在两周前进行了一次 UPDATE,这里是 DIFF

对于 TCP Fast Open 方案的内容,淘宝的一个朋友已经根据 RFC 草案进行了解读。我就不再赘述,感兴趣的朋友可以去看 paper 或者 RFC。我这里只是想讨论一下这个东西的应用前景。

由于对背景并没有做深入了解,我相信已经有很多人尝试去做过类似的工作,但我想类似的工作应该没有得到过大规模的应用。对于已经成型很久很久的 TCP 协议,让人很难有修改它的欲望,因为改那么底层的东西意味着很多很多的麻烦。

但是是否愿意付出代价,有一个前提是有没有足够的好处。TFO 给出的好处是:在 RTT (Round Trip Time) 比较低时,客户端页面加载时间优化大约在 4%~5%;RTT 越长,好处越大,平均大约在 25%。

Google TCP Fast Open Evaluation
Google TCP Fast Open Evaluation

除了页面加载变快改善了用户体验之外,TFO 给服务器端也带来了一些好处。由于每个请求都节省了一个 RTT,相应地也减少了服务器端的 CPU 消耗。paper 中给出的数据是每秒事务数由 2876.4 上升到 3548.7。

虽然 paper 中大部分时间在强调 TFO 对 web 页面加载的显著加速作用,但我认为即使 TFO 能成为互联网标准,它目前的状态离成为标准还有很长一段距离,因而在短期内它是无法影响到主流互联网世界的。但这并不意味着它没有机会,依小弟的愚见,目前它的推广应用可能有两个方向:

1. 移动互联网。移动互联网的 RTT 目前远大于传统互联网(常理推测,需数据支撑),因而一个 RTT 节省的效果无法被忽视;另外移动互联网终端操作系统多样化,不像桌面终端系统那么单一。 Google 自己就掌握着其中一个很重要的 android,百度也计划推出自己的“易平台”。这些互联网公司有动力去改善移动用户访问自身网站的用户体验。

2. 互联网企业数据中心。虽然数据中心内部访问时延很低,但对于典型的请求/响应的服务而言,减少一次 RTT 带来的好处还是有吸引力的,最起码能减少计算能力浪费和增加吞吐吧。再加上很多企业内部使用的都是定制的开源操作系统和定制的网络库,升级的代价并不是那么高。如果我是企业基础设施的负责人,我想我会很慎重地考虑这个方案的。