fix issues (#159)

* fix 8.1 * refine * refine a bit * refine * refine * refine a bit * fix broken figures
microsoft · Jun 10, 2022 · a51a91e · a51a91e
1 parent ece19de
commit a51a91e
Show file tree

Hide file tree

Showing 8 changed files with 122 additions and 166 deletions.
diff --git a/Textbook/第8章-深度学习推理系统/8.1-推理系统简介.md b/Textbook/第8章-深度学习推理系统/8.1-推理系统简介.md
@@ -17,9 +17,9 @@
 深度学习模型已经广泛的部署在各类应用中，充斥在我们生活的周边。例如，对话机器人，新闻推荐系统，物体检测器等。这些应用中，部署深度学习模型。
 
 <center> <img src="./img/1/8-1-1-app.png" width="1000" height="400" /></center>
-<center>图 8-1-1. 典型深度学习推理应用</center>
+<center>图 8.1.1 典型深度学习推理应用</center>
 
-如图 8-1-1 所示，对话机器人接收一句问题作为输入，通过深度学习模型（例如，Seq2Seq 模型）预测出回答并返回给用户。在这个过程中，推理系统需要考虑和提供以下的功能：
+如图 8.1.1 所示，对话机器人接收一句问题作为输入，通过深度学习模型（例如，Seq2Seq 模型）预测出回答并返回给用户。在这个过程中，推理系统需要考虑和提供以下的功能：
 - 提供可以被用户调用的接口
 - 能够完成一定的数据处理将输入数据转为向量
 - 能够在指定低延迟要求下返回用户响应
@@ -33,20 +33,20 @@
 
 接下来，我们先从深度学习训练过程和推理过程对比两者的相同点和不同点，以及在生命周期所处的环节，进而便于理解深度学习推理系统所侧重的目标。
 
-如图 8-1-2，深度学习模型的生命周期（Life Cycle）包含以下几个阶段：首先，需要从存储系统或其他数据源收集和准备训练数据。之后进入训练阶段，开始训练模型，一旦模型满足一定的学习性能，终止训练，并保存模型。完成训练之后，模型部署在推理系统中。推理系统对外暴露接口，接收用户请求或系统调用，模型通过推理（Inference）处理完请求后，返回给用户相应的响应结果，完成推理任务。
+如图 8.1.2，深度学习模型的生命周期（Life Cycle）包含以下几个阶段：首先，需要从存储系统或其他数据源收集和准备训练数据。之后进入训练阶段，开始训练模型，一旦模型满足一定的学习性能，终止训练，并保存模型。完成训练之后，模型部署在推理系统中。推理系统对外暴露接口，接收用户请求或系统调用，模型通过推理（Inference）处理完请求后，返回给用户相应的响应结果，完成推理任务。
 
 <center> <img src="./img/1/8-1-2-lifecycle.png" width="1200" height="500" /></center>
-<center>图 8-1-2. 深度学习模型的生命周期</center>
+<center>图 8.1.2 深度学习模型的生命周期</center>
 
 如果我们将训练阶段和推理阶段模型的执行过程进行抽象，我们可以总结出两者的共性和不同。训练阶段，深度学习模型常常采用梯度下降算法或类似的优化算法进行模型训练，我们可以将其拆解为三个阶段:
 - 前向传播（Forward Propagation）过程将输入样本（Sample）计算为输出标签（Label）。
 - 反向传播（Back Propagation）过程求解权重的梯度。
 - 梯度更新（Weight Update）阶段将模型权重通过一定的步长和梯度进行更新。在推理阶段，则只需要执行前向传播过程，将输入样本计算为输出标签。
 
-如图 8-1-3，相比训练阶段，推理阶段则只需要执行前向传播（Forward Propagation）一个过程，将输入样本通过深度学习模型计算输出标签（Label）。
+如图 8.1.3，相比训练阶段，推理阶段则只需要执行前向传播（Forward Propagation）一个过程，将输入样本通过深度学习模型计算输出标签（Label）。
 
 <center> <img src="./img/1/8-1-3-traininfer.png" width="1200" height="700" /></center>
-<center>图8-1-3. 模型训练与推理阶段</center>
+<center>图 8.1.3 模型训练与推理阶段</center>
 
 训练作业常常在之前章节中所介绍的异构集群管理系统中进行执行，通常执行，几个小时，天，或周，是类似传统的批处理作业（Batch Job）。而推理作业需要 $ 7 \times 24 $ 小时运行，类似传统的在线服务(Online Service)。具体来说，深度学习模型推理相比训练的新特点与挑战主要有以下几点：
 
@@ -59,7 +59,7 @@
 - 部署的设备型号更加多样
   - 需要多样的定制化的优化
 
-如图 8-1-3，深度学习训练与推理相比。在训练中，需要许多输入，通常是更大的批尺寸（Batch Size），用于训练深度学习模型。 在推理中，数据经过训练的网络用于发现和预测新输入中的信息，这些输入通过更小的批尺寸输入网络。
+如图 8.1.3，深度学习训练与推理相比。在训练中，需要许多输入，通常是更大的批尺寸（Batch Size），用于训练深度学习模型。 在推理中，数据经过训练的网络用于发现和预测新输入中的信息，这些输入通过更小的批尺寸输入网络。
 
 对于推理，相比训练的性能目标是不同的。 为了最大限度地减少网络的端到端响应时间（End to End Response Time），推理通常比训练批量输入更少的输入样本，也就是更小的批尺寸，因为依赖推理工作的服务（例如，基于云的图像处理管道）需要尽可能的更快响应，因此用户不必要让系统累积图像成更大批尺寸，进而不必等待几秒钟的响应时间。高吞吐量是训练期间最为重要的考量，但低延迟对于推理更加重要。
 
@@ -97,12 +97,12 @@ print("Prediction: ", LABELS[np.argmax(output)])
 >>> Prediction:  n01608432 kite 
 ```
 
-类似其他的推理系统也是有类似的步骤。也有很多场景下是通过CPU进行推理，这样就不需要进行主存与设备内存之前的数据拷贝。通过以上代码实例我们可以了解主干流程，那么当把模型部署之后，我们可以通过下图观察到常见推理系统的模块，与推理系统交互的系统和推理任务的流水线。
+类似其他的推理系统也是有类似的步骤。也有很多场景下是通过 CPU 进行推理，这样就不需要进行主存与设备内存之前的数据拷贝。通过以上代码实例我们可以了解主干流程，那么当把模型部署之后，我们可以通过下图观察到常见推理系统的模块，与推理系统交互的系统和推理任务的流水线。
 
-从下图 8-1-4，我们可以看到，模型首先经过训练后会保存在文件系统中，随着训练处的模型效果不断提升，可能会产生新版本的模型，并存储在文件系统中。之后模型会通过服务系统部署上线，推理系统会加载模型到内存，同时会对模型进行一定的版本管理，对输入数据进行批尺寸（Batch Size）动态优化，并提供服务接口（例如，HTTP，gRPC等），供客户端调用。
+从下图 8.1.4，我们可以看到，模型首先经过训练后会保存在文件系统中，随着训练处的模型效果不断提升，可能会产生新版本的模型，并存储在文件系统中。之后模型会通过服务系统部署上线，推理系统会加载模型到内存，同时会对模型进行一定的版本管理，对输入数据进行批尺寸（Batch Size）动态优化，并提供服务接口（例如，HTTP，gRPC等），供客户端调用。
 
 <center> <img src="./img/1/8-1-4-servingsys.png" width="1000" height="300" /></center>
-<center>图8-1-4. 推理服务系统</center>
+<center>图 8.1.4 推理服务系统</center>
 
 
 ## 8.1.2 推理系统的优化目标与约束
@@ -119,12 +119,12 @@ print("Prediction: ", LABELS[np.argmax(output)])
   - 随着新闻和读者兴趣的变化提供准确的预测 
 
 <center> <img src="./img/1/8-1-5-recommendsys.png" width="400" height="500" /></center>
-<center>图 8-1-5. 推荐系统</center>
+<center>图 8.1.5 推荐系统</center>
 
 除了应用场景的需求，推理系统也需要应对不同模型训练出的框架和多样性的推理硬件所产生的部署环境多样性，部署优化和维护困难且容易出错的挑战：
 
 <center> <img src="./img/1/8-1-6-flexibility.png" width="1000" height="300" /></center>
-<center>图 8-1-6. 推理系统部署需要支持多种框架和硬件</center>
+<center>图 8.1.6 推理系统部署需要支持多种框架和硬件</center>
 
 
 - 框架多样：
@@ -152,7 +152,7 @@ print("Prediction: ", LABELS[np.argmax(output)])
 除了以上的优化目标，设计推理系统时，相比训练系统，需要满足更多的约束：
 
 <center> <img src="./img/1/8-1-7-constraint.png" width="600" height="600" /></center>
-<center>图 8-1-6. 推理系统部署需要支持多种框架和硬件</center>
+<center>图 8.1.7 推理系统部署需要支持多种框架和硬件</center>
 
 - 服务等级协议（SLA）对延迟的约束：例如，某应用希望模型返回请求在 100ms 以内。
 - 资源约束
@@ -166,9 +166,9 @@ print("Prediction: ", LABELS[np.argmax(output)])
 通过下图我们可以看到推理系统的全貌。首先从流程上来看，推理系统完成以下处理并涉及以下系统设计问题:
 
 <center> <img src="./img/1/8-1-8-infersys.png" width="1000" height="700" /></center>
-<center>图 8-1-7. 推理系统组件与架构 <a href="https://developer.nvidia.com/tensorrt">图片引用</a></center> 
+<center>图 8.1.8 推理系统组件与架构 <a href="https://developer.nvidia.com/tensorrt">图片引用</a></center> 
 
-如图图 8-1-7 所示，推理系统中常常涉及相应模块并完成相应功能，我们将在后面章节中逐步展开：
+如图图 8.1.8 所示，推理系统中常常涉及相应模块并完成相应功能，我们将在后面章节中逐步展开：
 
 1. 请求与响应处理：系统需要序列化与反序列化请求，并通过后端高效执行，满足一定的响应延迟
 2. 请求调度：系统可以根据后端资源利用率，动态调整批尺寸，模型的资源分配，进而提升资源利用率，吞吐量。
@@ -181,10 +181,10 @@ print("Prediction: ", LABELS[np.argmax(output)])
 1. 云（Cloud）端：云端有更大的算力，内存，且电更加充足满足模型的功耗需求，同时与训练平台连接更加紧密，更容易使用最新版本模型，同时安全和隐私更容易保证。相比边缘侧可以达到更高的推理吞吐量。
 2. 边缘（Edge）端：边缘侧设备资源更紧张（例如，手机和 IOT 设备），且功耗受电池约束，需要更加在意资源的使用和执行的效率。
 
-推理系统中应用了大量的策略与工具进而让模型可以部署在多样的环境中达到更好的性能和满足资源约束。图 8-1-8 中所示，一般我们可以将引入的策略分为在线和离线策略，离线策略是在模型还没有加载到推理系统内存部署的阶段，对模型本身进行的转换，优化与打包，在线部分是推理系统加载模型后，运行时对请求和模型的执行进行的管理和优化。我们将在后面的章节中介绍相应的策略，让读者对推理系统也形成系统化（Systematic）的感知。
+推理系统中应用了大量的策略与工具进而让模型可以部署在多样的环境中达到更好的性能和满足资源约束。图 8.1.9 中所示，一般我们可以将引入的策略分为在线和离线策略，离线策略是在模型还没有加载到推理系统内存部署的阶段，对模型本身进行的转换，优化与打包，在线部分是推理系统加载模型后，运行时对请求和模型的执行进行的管理和优化。我们将在后面的章节中介绍相应的策略，让读者对推理系统也形成系统化（Systematic）的感知。
 
 <center> <img src="./img/1/8-1-9-policyinfer.png" width="1000" height="500" /></center>
-<center>图 8-1-8. 推理系统中涉及到的策略与优化</center>
+<center>图 8.1.9 推理系统中涉及到的策略与优化</center>
 
  ## 小结与讨论
 
@@ -203,15 +203,7 @@ print("Prediction: ", LABELS[np.argmax(output)])
 - [Crankshaw, Daniel et al. “Clipper: A Low-Latency Online Prediction Serving System.” NSDI (2017).](https://www.usenix.org/system/files/conference/nsdi17/nsdi17-crankshaw.pdf)
 - [Denis Baylor, Eric Breck, Heng-Tze Cheng, Noah Fiedel, Chuan Yu Foo, Zakaria Haque, Salem Haykal, Mustafa Ispir, Vihan Jain, Levent Koc, Chiu Yuen Koo, Lukasz Lew, Clemens Mewald, Akshay Naresh Modi, Neoklis Polyzotis, Sukriti Ramesh, Sudip Roy, Steven Euijong Whang, Martin Wicke, Jarek Wilkiewicz, Xin Zhang, and Martin Zinkevich. 2017. TFX: A TensorFlow-Based Production-Scale Machine Learning Platform. In Proceedings of the 23rd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD '17). Association for Computing Machinery, New York, NY, USA, 1387–1395. DOI:https://doi.org/10.1145/3097983.3098021](https://research.google/pubs/pub46484/)
 - [Olston, Christopher et al. “TensorFlow-Serving: Flexible, High-Performance ML Serving.” ArXiv abs/1712.06139 (2017): n. pag.](https://arxiv.org/abs/1712.06139)
-- [Jeong-Min Yun, Yuxiong He, Sameh Elnikety, and Shaolei Ren. 2015. Optimal Aggregation Policy for Reducing Tail Latency of Web Search. In Proceedings of the 38th International ACM SIGIR Conference on Research and Development in Information Retrieval (SIGIR '15). Association for Computing Machinery, New York, NY, USA, 63–72. DOI:https://doi.org/10.1145/2766462.2767708](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/samehe-2015sigir.optimalaggregation.pdf)
-- [Cheng, Yu et al. “A Survey of Model Compression and Acceleration for Deep Neural Networks.” ArXiv abs/1710.09282 (2017): n. pag.](https://arxiv.org/abs/1710.09282)
 - [CSE 599W: System for ML - Model Serving](https://dlsys.cs.washington.edu/)
 - https://developer.nvidia.com/deep-learning-performance-training-inference 
-- [Han, Song et al. “Deep Compression: Compressing Deep Neural Network with Pruning, Trained Quantization and Huffman Coding.” arXiv: Computer Vision and Pattern Recognition (2016): n. pag.](https://arxiv.org/abs/1510.00149) 
-- [Song Han, Jeff Pool, John Tran, and William J. Dally. 2015. Learning both weights and connections for efficient neural networks. In Proceedings of the 28th International Conference on Neural Information Processing Systems - Volume 1 (NIPS'15). MIT Press, Cambridge, MA, USA, 1135–1143.](https://arxiv.org/abs/1506.02626)
 - [DEEP LEARNING DEPLOYMENT WITH NVIDIA TENSORRT](https://developer.nvidia.com/blog/deploying-deep-learning-nvidia-tensorrt/)
-- [Jonathan Ragan-Kelley, Connelly Barnes, Andrew Adams, Sylvain Paris, Frédo Durand, and Saman Amarasinghe. 2013. Halide: a language and compiler for optimizing parallelism, locality, and recomputation in image processing pipelines. SIGPLAN Not. 48, 6 (June 2013), 519–530. DOI:https://doi.org/10.1145/2499370.2462176](https://people.csail.mit.edu/jrk/halide-pldi13.pdf)
-- [Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Meghan Cowan, Haichen Shen, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: an automated end-to-end optimizing compiler for deep learning. In Proceedings of the 13th USENIX conference on Operating Systems Design and Implementation (OSDI'18). USENIX Association, USA, 579–594.](https://arxiv.org/abs/1802.04799)
-- [8-bit Inference with TensorRT](https://on-demand.gputechconf.com/gtc/2017/presentation/s7310-8-bit-inference-with-tensorrt.pdf)
-- [GPU-Based Deep Learning Inference: A Performance and Power Analysis](https://www.nvidia.com/content/tegra/embedded-systems/pdf/jetson_tx1_whitepaper.pdf)
-- https://developer.nvidia.com/blog/inference-next-step-gpu-accelerated-deep-learning/
+
diff --git a/Textbook/第8章-深度学习推理系统/8.2-模型推理的离线优化.md b/Textbook/第8章-深度学习推理系统/8.2-模型推理的离线优化.md
@@ -4,7 +4,7 @@
 # 8.2 模型推理的离线优化
 
 <center> <img src="./img/2/8-2-4-offlineopt.png" width="600" height="500" /></center>
-<center>图 8-2-0. 模型的离线优化 </center>
+<center>图 8.2.1 模型的离线优化 </center>
 
 本章将围绕推理系统或库针对模型的离线优化策略展开相应的介绍，如图所示，其是一般介于工程师训练完模型与运行期推理之间的环节。
 
@@ -148,7 +148,7 @@ for j in range(len(B[0])):
 我们将模型抽象为数据流图（Data-Flow Graph)，其中在设备执行的层（Layer）在一些框架内也称作内核（Kernel）或算子（Operator）。我们可以从下图中看到，设备中执行一个内核，一般需要以下几个步骤和时间开销，启动内核，读取数据到设备，执行内核，结果数据写回主存。
 
 <center> <img src="./img/2/8-2-1-fusion.png" width="1000" height="400" /></center>
-<center>图 8-2-1. 内核执行时间线</center>
+<center>图 8.2.2 内核执行时间线</center>
 
 我们从上面的实例可以观察到需要对模型的层间和张量融合的原因：
 - 相对于内核启动开销和每个层的张量数据读写成本，内核（Kernel）计算通常非常快
@@ -161,7 +161,7 @@ for j in range(len(B[0])):
 如下图所示，左图为未进行融合的深度学习模型网络结构，右图为经过 TensorRT 优化和融合之后的深度学习模型网络结构。优化后将很多小的层融合为大的层，这样减少了大量的内核启动与数据读写和内存分配释放的开销，提升性能。
 
 <center> <img src="./img/2/8-2-2-fusionopt.png" width="1000" height="800" /></center>
-<center>图 8-2-2. TensorRT使用内核融合进行模型执行优化</center>
+<center>图 8.2.3 TensorRT使用内核融合进行模型执行优化</center>
 
 代表性的开源应用内核融合优化的系统还有很多，例如，微软开源的 [NNFusion](https://github.com/microsoft/nnfusion)。
 
@@ -180,9 +180,9 @@ for j in range(len(B[0])):
 代表性的开源后端自动调优编译器或工具有：[TVM](https://tvm.apache.org/),[Hadlide](https://dl.acm.org/doi/10.1145/2491956.2462176),[Ansor](https://tvm.apache.org/2021/03/03/intro-auto-scheduler)等。
 
 <center> <img src="./img/2/8-2-3-autotuning.png" width="1000" height="400" /></center>
-<center>图 8-2-3. 对比不同后端自动调优搜索策略 <a href="https://arxiv.org/pdf/2006.06762.pdf">图片引用Ansor</a></center>
+<center>图 8.2.4 对比不同后端自动调优搜索策略 <a href="https://arxiv.org/pdf/2006.06762.pdf">图片引用Ansor</a></center>
 
-如图 8-2-3 所示，当前深度学习算子大多会转换为矩阵计算，而矩阵计算又会转换为多级for循环在特定设备执行。[Ansor](https://arxiv.org/pdf/2006.06762.pdf) 工作中总结当前目标后端自动调优通常有以下几种方案：
+如图 8.2.4 所示，当前深度学习算子大多会转换为矩阵计算，而矩阵计算又会转换为多级for循环在特定设备执行。[Ansor](https://arxiv.org/pdf/2006.06762.pdf) 工作中总结当前目标后端自动调优通常有以下几种方案：
 
 1. 模板引导搜索（Templated-guided Search）： 如图 a 所示，在模板引导搜索中，搜索空间由手动模板定义。编译器（例如，TVM）需要用户手动为计算定义编写模板。模板用一些可调参数定义张量程序的结构参数（例如，平铺大小和展开因子）。编译器然后针对输入形状配置和特定的硬件目标搜索这些参数的最佳值。该方法在常见问题上取得了良好的性能，例如，深度学习算子。 然而，开发模板重新需要较大的工作量。
 2. 基于顺序构建的搜索（Sequential Construction Based Search）：如图b所示，这种方法通过分解程序结构来细化搜索空间转化为固定的决策序列。然后编译器使用诸如束搜索（Beam Search）之类的算法来搜索好的决策（例如，[Halide](https://dl.acm.org/doi/10.1145/3150211) 自动调度器采用这种方式）。在这种方法中，编译器通过逐步展开计算图中的所有节点顺序构造一个张量程序（Tensor Program）。
@@ -215,7 +215,7 @@ $$
 \end{array}
 $$
 
-<center>图8-2-3. 精度取值范围</center>
+<center>表 8.2.1 精度取值范围</center>
 
 
 ## 8.2.6 模型压缩