没有软件支持的硬件就是一块砖，围绕硬件编写通用且易用的软件栈所需的资源以及重要性不亚于硬件开发。
在硬件工程师主导的团队中，可能会忽视软件的作用以及开发工作量。
因为从硬件的角度来看，软硬件接口的抽象非常明确：
- 寄存器表
- 数据
- 指令
后端硬件通常暴露一组控制寄存器，上层软件通过驱动读写寄存器，完成初始化，复位，状态监测等操作。
后端硬件和主控CPU通过主存交换数据和指令，硬件指令解析器读取指令并发出相应的信号影响控制流和数据流。
然而软件工程需要在软硬件接口之上做多层封装，提供不同层次的接口抽象，满足不同需求的用户。
# 驱动（Driver）
软件层最底层的封装，与操作系统耦合，提供最基本的硬件控制接口，基本和软硬件接口一致，比如读写寄存器表，读写存储器数据等。
但通常处于安全性考虑，驱动不会直接提供上面的功能，而是进一步封装，提供执行特定功能的接口。一个接口中，可能执行多个寄存器和存储器读写操作。
除此之外，驱动运行于操作系统层，天然具备跨进程的能力，因此在驱动也会负责跨进程的硬件状态管理，比如内存管理，指令调度等。
# 运行时（Runtime）
用户使用驱动可以最大程度的控制硬件逻辑，但相应的所需要编写的代码量相当可观，因此，驱动层之上还会封装runtime。
runtime通常提供更高层次的抽象接口，进一步屏蔽硬件初始化，上下文（context）管理，设备管理，以及指令/数据的显示加载读取等操作。
总体上来看，runtime的性能相较驱动没有太多损失，但易用性大为提升，错误反馈和排查功能也更为友好。
因此，如果不是对硬件控制有特别高的需求，会使用runtime接口编程。
# 计算库（Libraries）
编写硬件指令，由其是高效的硬件指令需要对硬件结构有深刻的理解，但是手工编写硬件指令对更高层的用户（比如算法工程师）来说是不够友好并且困难的。
因此后端硬件官方或第三方通常会提供特定领域计算库，提供常见计算pattern的接口，内置凝结了工程师智慧的手工优化代码，比如CuDNN，MKL-DNN等面向深度学习的计算库。
一般来说，硬件厂商提供的计算库性能高于第三方开发的计算库，毕竟对于硬件结构的理解更深入。但是第三方在应用上的创新速度远快于硬件厂商的响应速度，各家厂商对于应用的参与和主导程度也会影响计算库的迭代速度和易用性，比如NVIDIA和Intel。
# 计算框架（Framework）
计算库提供了特定计算pattern的优化指令，尤其是对计算密集型算子，提高了硬件利用率。但对于一个特定应用来说，还需要足够灵活和高效的计算框架的支持。
对于深度学习应用，计算框架（比如Tensorflow和PyTorch等训练框架）提供了算子级别的抽象，使用Python定义DSL，让用户灵活构建计算图，并提供了反向梯度计算，方便训练。
服务框架用来将训练后的模型部署为在线服务，供业务应用调用，通常使用训练框架的计算核心，但是更注重面向网络接口的高可用，高并发等特性。
后端硬件通常只能支持主流框架全部算子的子集，需要接入框架提高可用性，否则，整个计算图都能在专用硬件上运行的概率不会太高。接入过程主要考虑调度，算子融合，以及常规的编译优化手段。
# 业务
业务应用通常使用微服务架构，各个模块间相互独立。业务应用负责处理数据处理，格式转换，模型调用等任务。
业务应用从前端被动获取数据（比如用户的行为数据），或者从数据库/数据仓库中取数据，通过RPC1或HTTP调用机器学习模型在线服务，根据服务返回结果（比如物品推荐的打分）执行数据处理操作（比如筛选排列返回给前端的物品呈现顺序），优化某项业务指标（比如点击率或观看时长）。
机器学习服务有SaaS2化的趋势，对小微用户来说，招聘全职的算法工程师和平台工程师的风险偏高，且限于技术深度相对不可控。SaaS服务提供了更高层的使用接口，甚至是无代码操作方式，标准化托管用户的数据收集、处理、分析流程，根据用户的不同需要（比如推荐、风险控制、用户增长等）提供不同类型的服务。
# 影响
基于数据分析的业务决策已经被实践证明在优化某些特定业务指标时效果明显，但数据分析逐步普及的趋势下，似乎陷入了电影院困境，大家被迫要用数据分析来决策。
数字化确实能带来效率提升，紧随其后的大数据计算利用机器学习在试图在微观层面上找到一些可以带来收益的价值，也就是所谓的挖掘数据中的金子。
智能化是在数据、算力双双获得爆发性增长后的趋势，但目前的智能化仍然只能看做大数据分析的进一步发展形态，依赖算力和数据规模暴力拟合。
因此而消耗的能源和人类时间，给环境造成的影响是否真正创造了等量的价值呢？
正如模型训练步长过小容易陷入局部最优解，依赖于一个个AB Test做出的短期决策是否对长期价值有贡献呢？