随着近几年AI的高速发展，涌现出越来越多的AI产品，我们生活中也深切感受到AI给带来的不一样的服务和体验。比如高铁和机场的刷脸安检闸机，家里面的智能音响和智能家居，还是儿童教育类的陪伴教育机器人，其背后是人工智能各种算法作为支撑。
AI各种算法在产品化落地时，即要保持算法的各种性能指标，又要足够的快（起码的要求必须能实时处理）。各种算法根据不同业务场景，部署的位置不太一样，大多数是部署到云端服务器中，还有一部分需要边缘化部署。前者的主要挑战是并发服务能力，主要指标是吞吐率和延时；后者主要挑战是平台多样化，主要挑战是实时率和功耗（意味着成本）。
针对上述的问题，给算法工程化提出了很高的要求，算法虽然是核心模块，但是占据了大多数的计算资源和时延，所以，工程化做的越好，需要的计算资源越少，要么可以提高吞吐量（云端），要么可以降低功耗（边缘）；工程化做的越好，时延越小，带来的好处是，可以加入更复杂的业务逻辑，给产品设计更多自由和选择。
算法引擎工程化的主要工作内容包含如下几点：
1）算法引擎设计与工程研发
2）版本发布维护与管理
3）算法引擎配套的测试框架设计与搭建
4）算法引擎的性能测试和边界测试
5）算法引擎的平台移植与产品化落地
6）上下游相关联的算法引擎的端到端测试和匹配问题
本文无法针对上述所有问题分别进行详述，后续会分篇慢慢展开。下面以对云端和边缘端算法的工程化思路为例，抛砖引玉，简单聊聊。
云端AI算法工程化思路
云端运行的算法有足够的硬件资源，如果不考虑电费和云服务租金的话，可以不用太考虑工程化的深度，只要保证运行稳健性即可。即便不考虑成本，也需要考虑吞吐量和时延的问题，对外提供服务，时延是必须要考虑的问题，吞吐量可以拿钱砸（如果不差钱）。如果想把事情做到极致，云端AI算法的工程化的要求大概不外乎以下几点：
云端的所有程序的最基本要求，要稳健运行，算法引擎大概率是C\C++语言开发的，众所周知，C是没有异常机制的，算法引擎要是crash，往往崩掉的是整个服务，这个是灾难性的。
很多人认为引擎的封装不就是弄几个API接口，编译一个library就OK了吗？实际上，我们看到的表象是这样的，但是认知有偏见。虽然是云端\服务端上来部署的，但是，接口是不同部门之间的协议，设计不好，会浪费多个部门的资源。这里有两方面的要求：
1）接口设计的稳定性，易用性和扩展性（引擎基本要求）。
2）接口对业务支持的匹配性，
是设计一个大而全的引擎，还是设计一个和业务精致匹配的引擎，前者容易维护，一把梭，后者需要较深的设计架构能力，也许你担心可维护性，这个通过架构，完全可以不用担心。
这个涉及到成本和客户体验问题，也是最要紧的问题，加速的前提是不得有不可容忍的性能损失。第一个问题：成本，服务部署好之后，就是电费\租金的问题，加速的越快，吞吐率越高，成本越低；第二个问题：客户体验问题，上面也说了，速度越快，时延越低，产品设计的自由度越大，可以增加更复杂的业务逻辑。
边缘端AI算法工程化思路
边缘端共有的特点是受成本影响，一般算力有限，除了AI算法，还会有诸如视频编解码，音频采样，和业务逻辑等模块，分给AI算法的资源是越少越好，这就要求运行在端上的算法即要够快，又要占用资源少，工程化的原则和思路如下：
端上的算法稳定性虽然没有云端\服务端要求那么高，但是会影响用户体验，所以也是必须排在首位，产品体验不好，产品经理会重点盯着你。
端的平台类型非常之多，主流还是ARM类芯片，即便是ARM类芯片，不同玩家的平台差异还是挺大的，如果每种平台做一个版本，那到项目多的时候，维护工作就让你傻眼了。可移植性是工程化的重点工作内容之一。
对于端侧的设备，引擎的加速意味着功耗的降低和体验性的提高，功耗的降低以为着成本的压缩，或者增加更多的算法模块。由于算法引擎是密集计算模块，可加速的空间比较大，是从事引擎工程化人员必备的核心技能。
以上是对算法引擎工
