深度学习应用开发架构的一种思路
背景
深度学习当下依然处在风口，它从一开始解决单一场景中单一问题的算法，逐步成长为能够解决复杂问题的效率工具。
随着深度学习相关的各项技术的发展，对深度学习的要求也越来越具体：一方面是朝着小而快的方向发展，不断针对特定场景做深度定制优化、精简模型，将算法部署到到移动端甚至嵌入式设备；另一方面是朝着大而全的方向演进，目标是解决一些复杂但是通用的问题，这部分模型大多部署在高性能的服务器，作为SAAS服务提供给B端或C端用户使用。
结构划分
当我们提到深度学习，第一反应是什么？绝大多数人的反应是模型。这是因为深度学习应用开发的核心就是将合适的模型用合适的计算资源处理。所以我们从模型开始，分别往下到硬件，往上到业务进行结构划分。
从模型往下走，是推断框架，也就是上面说的”合适的计算资源“。这个推断框架可以是兼容各平台的，也可以是针对单一平台深度定制优化的，具体如何选择要结合场景和业务要求。推断框架以下，就是硬件层，其他软件框架一般还会有系统适配层，但是深度学习对系统的依赖会包含在推断框架中，所以推断框架以下就只考虑硬件层。
从模型往上走，我们需要一个问题：我的模型如何被外部调用？也就是说需要逐步考虑外界的需求。最简单的场景，比如我就是要识别键盘鼠标等通用物体，那么我的应用场景所需要的算法就是物体识别，而物体识别这个算法也只需要一个模型，比如MV2。但是实际应用场景往往包含不止一个算法、且一个算法可能会需要多个模型的结果。
所以模型上面需要一个算法层，用来控制和管理各个可能需要的模型，算法层网上，是场景逻辑层，用来管理这些算法。
资源管理
深度学习算法至少包含两类资源文件，一是算法配置文件，里面包括模型路径、输入输出feature的形状、输入输出层名称、以及一些可配置的阈值等常量参数，这类配置文件可以用JSON等格式保存和读取；二是算法模型，这个模型可以存放在应用沙盒中，本地记载，也可以存放在服务器上，以网络下载的方式加载。
整体结构
优缺点分析
优点
- 场景自由度高，每个层级内部是完全解耦的，可以自由组合算法和场景，满足更多复杂需求
- 模块划分清晰，各层各模块只需要关注自身，做好本模块的优化即可
- 可配置性强，将各类参数用配置晚间管理，对于大部分需求修改，都只需要修改模型文件或者配置文件，不用重新编译发布代码库
- 可移植性强，这套框架本身并不依赖平台，所以可以很轻松的在移动端(iOS/Android)和服务器上实现
缺点
- 不适合轻量场景，对于很轻量的场景(单算法单模型单系统不需要配置)，这套架构显得有点复杂，数据流过长
- 调试麻烦，因为所有模块都是同一对外输出，所以在开发各个模块时调试起来不方便
结论
我们针对深度学习应用开发提出了一种架构思路，可以在复杂场景中提升开发效率，易于部署且可以灵活定制适配各种需求。
