diff --git a/README.md b/README.md
index 521a13d3d38b2ecfee79eccee42fb9f0a0f5327c..749b71c134beccf0000aebf7efb63ad4d4f08c1d 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 
 <p align="center">
     <br>
-<img src='doc/serving_logo.png' width = "600" height = "130">
+<img src='doc/images/serving_logo.png' width = "600" height = "130">
     <br>
 <p>
 
@@ -47,7 +47,7 @@ We consider deploying deep learning inference service online to be a user-facing
 [Serving Examples](./python/examples/).
 
 <p align="center">
-    <img src="doc/demo.gif" width="700">
+    <img src="doc/images/demo.gif" width="700">
 </p>
 
 
diff --git a/README_CN.md b/README_CN.md
index efd184eb249c5cc7604e8671a286577b3fb62641..a30b04e30d2e5805b1b5fe700ae81a70b379eaae 100644
--- a/README_CN.md
+++ b/README_CN.md
@@ -2,7 +2,7 @@
 
 <p align="center">
     <br>
-<img src='doc/serving_logo.png' width = "600" height = "130">
+<img src='doc/images/serving_logo.png' width = "600" height = "130">
     <br>
 <p>
 
@@ -48,7 +48,7 @@ Paddle Serving 旨在帮助深度学习开发者轻易部署在线预测服务
 - 提供丰富多彩的前后处理，方便用户在训练、部署等各阶段复用相关代码，弥合AI开发者和应用开发者之间的鸿沟，详情参考[模型示例](./python/examples/)。
 
 <p align="center">
-    <img src="doc/demo.gif" width="700">
+    <img src="doc/images/demo.gif" width="700">
 </p>
 
 <h2 align="center">教程</h2>
diff --git a/doc/ABTEST_IN_PADDLE_SERVING.md b/doc/ABTEST_IN_PADDLE_SERVING.md
index 71cd267f76705583fed0ffbb57fda7a1039cbba6..f250f1a176c76f8baf66411fc896a4bd9f4ce040 100644
--- a/doc/ABTEST_IN_PADDLE_SERVING.md
+++ b/doc/ABTEST_IN_PADDLE_SERVING.md
@@ -4,7 +4,7 @@
 
 This document will use an example of text classification task based on IMDB dataset to show how to build a A/B Test framework using Paddle Serving. The structure relationship between the client and servers in the example is shown in the figure below.
 
-<img src="abtest.png" style="zoom:25%;" />
+<img src="images/abtest.png" style="zoom:25%;" />
 
 Note that:  A/B Test is only applicable to RPC mode, not web mode.
 
diff --git a/doc/ABTEST_IN_PADDLE_SERVING_CN.md b/doc/ABTEST_IN_PADDLE_SERVING_CN.md
index af3cf1f83d2dbfc29101fe7bcd97fb8fbb820767..34d1525b71396220d535a38593fc99eeac84a86f 100644
--- a/doc/ABTEST_IN_PADDLE_SERVING_CN.md
+++ b/doc/ABTEST_IN_PADDLE_SERVING_CN.md
@@ -4,7 +4,7 @@
 
 该文档将会用一个基于IMDB数据集的文本分类任务的例子，介绍如何使用Paddle Serving搭建A/B Test框架，例中的Client端、Server端结构如下图所示。
 
-<img src="abtest.png" style="zoom:33%;" />
+<img src="images/abtest.png" style="zoom:33%;" />
 
 需要注意的是：A/B Test只适用于RPC模式，不适用于WEB模式。
 
diff --git a/doc/BERT_10_MINS.md b/doc/BERT_10_MINS.md
index 3857bc555dcd69be96d961f2acc363bac6575c50..cc356c359bf6cff525c37abe723d5c8dc73b4781 100644
--- a/doc/BERT_10_MINS.md
+++ b/doc/BERT_10_MINS.md
@@ -115,7 +115,7 @@ curl -H "Content-Type:application/json" -X POST -d '{"feed":[{"words": "hello"}]
 
 We tested the performance of Bert-As-Service based on Padde Serving based on V100 and compared it with the Bert-As-Service based on Tensorflow. From the perspective of user configuration, we used the same batch size and concurrent number for stress testing. The overall throughput performance data obtained under 4 V100s is as follows.
 
-![4v100_bert_as_service_benchmark](4v100_bert_as_service_benchmark.png)
+![4v100_bert_as_service_benchmark](images/4v100_bert_as_service_benchmark.png)
 
 <!--
 yum install -y libXext libSM libXrender
diff --git a/doc/BERT_10_MINS_CN.md b/doc/BERT_10_MINS_CN.md
index 3a480b6efc919f9a8af97e537db47ab3eafcbf14..484522256cbc07603002f2ef5f2ca3aa26395868 100644
--- a/doc/BERT_10_MINS_CN.md
+++ b/doc/BERT_10_MINS_CN.md
@@ -111,4 +111,4 @@ curl -H "Content-Type:application/json" -X POST -d '{"feed":[{"words": "hello"}]
 
 我们基于V100对基于Padde Serving研发的Bert-As-Service的性能进行测试并与基于Tensorflow实现的Bert-As-Service进行对比，从用户配置的角度，采用相同的batch size和并发数进行压力测试，得到4块V100下的整体吞吐性能数据如下。
 
-![4v100_bert_as_service_benchmark](4v100_bert_as_service_benchmark.png)
+![4v100_bert_as_service_benchmark](images/4v100_bert_as_service_benchmark.png)
diff --git a/doc/C++DESIGN.md b/doc/C++DESIGN.md
index 22c4a9201b6f6306bb1d4f432e999d2203f854ee..e45fe4392346a9e82ef9f2a671609c68413af0c2 100644
--- a/doc/C++DESIGN.md
+++ b/doc/C++DESIGN.md
@@ -45,11 +45,11 @@ Models that can be predicted using the Paddle Inference Library, models saved du
 
 ### 3.4 Server Inferface
 
-![Server Interface](server_interface.png)
+![Server Interface](images/server_interface.png)
 
 ### 3.5 Client Interface
 
-<img src='client_inferface.png' width = "600" height = "200">
+<img src='images/client_inferface.png' width = "600" height = "200">
 
 ### 3.6 Client io used during Training
 
@@ -66,7 +66,7 @@ def save_model(server_model_folder,
 
 ## 4. Paddle Serving Underlying Framework
 
-![Paddle-Serging Overall Architecture](framework.png)
+![Paddle-Serging Overall Architecture](images/framework.png)
 
 **Model Management Framework**: Connects model files of multiple machine learning platforms and provides a unified inference interface
 **Business Scheduling Framework**: Abstracts the calculation logic of various different inference models, provides a general DAG scheduling framework, and connects different operators through DAG diagrams to complete a prediction service together. This abstract model allows users to conveniently implement their own calculation logic, and at the same time facilitates operator sharing. (Users build their own forecasting services. A large part of their work is to build DAGs and provide operators.)
@@ -102,18 +102,18 @@ class FluidFamilyCore {
 
 With reference to the abstract idea of model calculation of the TensorFlow framework, the business logic is abstracted into a DAG diagram, driven by configuration, generating a workflow, and skipping C ++ code compilation. Each specific step of the service corresponds to a specific OP. The OP can configure the upstream OP that it depends on. Unified message passing between OPs is achieved by the thread-level bus and channel mechanisms. For example, the service process of a simple prediction service can be abstracted into 3 steps including reading request data-> calling the prediction interface-> writing back the prediction result, and correspondingly implemented to 3 OP: ReaderOp-> ClassifyOp-> WriteOp
 
-![Infer Service](predict-service.png)
+![Infer Service](images/predict-service.png)
 
 Regarding the dependencies between OPs, and the establishment of workflows through OPs, you can refer to [从零开始写一个预测服务](CREATING.md) (simplified Chinese Version)
 
 Server instance perspective
 
-![Server instance perspective](server-side.png)
+![Server instance perspective](images/server-side.png)
 
 
 #### 4.2.2 Paddle Serving Multi-Service Mechanism
 
-![Paddle Serving multi-service](multi-service.png)
+![Paddle Serving multi-service](images/multi-service.png)
 
 Paddle Serving instances can load multiple models at the same time, and each model uses a Service (and its configured workflow) to undertake services. You can refer to [service configuration file in Demo example](../tools/cpp_examples/demo-serving/conf/service.prototxt) to learn how to configure multiple services for the serving instance
 
@@ -121,12 +121,12 @@ Paddle Serving instances can load multiple models at the same time, and each mod
 
 From the client's perspective, a Paddle Serving service can be divided into three levels: Service, Endpoint, and Variant from top to bottom.
 
-![Call hierarchy relationship](multi-variants.png)
+![Call hierarchy relationship](images/multi-variants.png)
 
 One Service corresponds to one inference model, and there is one endpoint under the model. Different versions of the model are implemented through multiple variant concepts under endpoint:
 The same model prediction service can configure multiple variants, and each variant has its own downstream IP list. The client code can configure relative weights for each variant to achieve the relationship of adjusting the traffic ratio (refer to the description of variant_weight_list in [Client Configuration](CLIENT_CONFIGURE.md) section 3.2).
 
-![Client-side proxy function](client-side-proxy.png)
+![Client-side proxy function](images/client-side-proxy.png)
 
 ## 5. User Interface
 
diff --git a/doc/C++DESIGN_CN.md b/doc/C++DESIGN_CN.md
index e4cba4f831a56265f7c52a32900bc929aa4208ec..383666959a89876545cc07037d71faa73d6eae2e 100644
--- a/doc/C++DESIGN_CN.md
+++ b/doc/C++DESIGN_CN.md
@@ -47,11 +47,11 @@ PaddlePaddle是百度开源的机器学习框架，广泛支持各种深度学
 
 ### 3.4 Server Inferface
 
-![Server Interface](server_interface.png)
+![Server Interface](images/server_interface.png)
 
 ### 3.5 Client Interface
 
-<img src='client_inferface.png' width = "600" height = "200">
+<img src='images/client_inferface.png' width = "600" height = "200">
 
 ### 3.6 训练过程中使用的Client io
 
@@ -68,7 +68,7 @@ def save_model(server_model_folder,
 
 ## 4. Paddle Serving底层框架
 
-![Paddle-Serging总体框图](framework.png)
+![Paddle-Serging总体框图](images/framework.png)
 
 **模型管理框架**：对接多种机器学习平台的模型文件，向上提供统一的inference接口
 **业务调度框架**：对各种不同预测模型的计算逻辑进行抽象，提供通用的DAG调度框架，通过DAG图串联不同的算子，共同完成一次预测服务。该抽象模型使用户可以方便的实现自己的计算逻辑，同时便于算子共用。（用户搭建自己的预测服务，很大一部分工作是搭建DAG和提供算子的实现）
@@ -104,18 +104,18 @@ class FluidFamilyCore {
 
 参考TF框架的模型计算的抽象思想，将业务逻辑抽象成DAG图，由配置驱动，生成workflow，跳过C++代码编译。业务的每个具体步骤，对应一个具体的OP，OP可配置自己依赖的上游OP。OP之间消息传递统一由线程级Bus和channel机制实现。例如，一个简单的预测服务的服务过程，可以抽象成读请求数据->调用预测接口->写回预测结果等3个步骤，相应的实现到3个OP: ReaderOp->ClassifyOp->WriteOp
 
-![预测服务Service](predict-service.png)
+![预测服务Service](images/predict-service.png)
 
 关于OP之间的依赖关系，以及通过OP组建workflow，可以参考[从零开始写一个预测服务](CREATING.md)的相关章节
 
 服务端实例透视图
 
-![服务端实例透视图](server-side.png)
+![服务端实例透视图](images/server-side.png)
 
 
 #### 4.2.2 Paddle Serving的多服务机制
 
-![Paddle Serving的多服务机制](multi-service.png)
+![Paddle Serving的多服务机制](images/multi-service.png)
 
 Paddle Serving实例可以同时加载多个模型，每个模型用一个Service（以及其所配置的workflow）承接服务。可以参考[Demo例子中的service配置文件](../tools/cpp_examples/demo-serving/conf/service.prototxt)了解如何为serving实例配置多个service
 
@@ -123,12 +123,12 @@ Paddle Serving实例可以同时加载多个模型，每个模型用一个Servic
 
 从客户端看，一个Paddle Serving service从顶向下可分为Service, Endpoint, Variant等3个层级
 
-![调用层级关系](multi-variants.png)
+![调用层级关系](images/multi-variants.png)
 
 一个Service对应一个预测模型，模型下有1个endpoint。模型的不同版本，通过endpoint下多个variant概念实现：
 同一个模型预测服务，可以配置多个variant，每个variant有自己的下游IP列表。客户端代码可以对各个variant配置相对权重，以达到调节流量比例的关系（参考[客户端配置](CLIENT_CONFIGURE.md)第3.2节中关于variant_weight_list的说明）。
 
-![Client端proxy功能](client-side-proxy.png)
+![Client端proxy功能](images/client-side-proxy.png)
 
 ## 5. 用户接口
 
diff --git a/doc/CUBE_LOCAL.md b/doc/CUBE_LOCAL.md
index dc34a222a1b2691f2c51885e6b9b2f4c7192b845..def736230173018ce151dd0f85f1e8b4e15099fe 100644
--- a/doc/CUBE_LOCAL.md
+++ b/doc/CUBE_LOCAL.md
@@ -88,7 +88,7 @@ this step is not necessary, but it can help you to verify if the model is ready.
 ```
 if you succeed, you will see this
 <p align="center">
-    <img src="cube-cli.png" width="700">
+    <img src="images/cube-cli.png" width="700">
 </p>
 
 If you see that each key has a corresponding value output, it means that the delivery was successful. This file can also be used by Serving to perform cube query in general kv infer op in Serving.
diff --git a/doc/CUBE_LOCAL_CN.md b/doc/CUBE_LOCAL_CN.md
index e1f424a3b6f7ef856b53ff811196688ea33870c1..ea4c00c9f7e593dd40465c2ceff3bebd2ec299fb 100644
--- a/doc/CUBE_LOCAL_CN.md
+++ b/doc/CUBE_LOCAL_CN.md
@@ -91,7 +91,7 @@ cd cube
 
 如果执行成功，会看到如下结果
 <p align="center">
-    <img src="cube-cli.png" width="700">
+    <img src="images/cube-cli.png" width="700">
 </p>
 
 
diff --git a/doc/DESIGN_DOC.md b/doc/DESIGN_DOC.md
index d84c14f14067a7e668c12824eea5606193d20529..268d2ff67cbec90ff7714723d10a6a38df1b61b3 100644
--- a/doc/DESIGN_DOC.md
+++ b/doc/DESIGN_DOC.md
@@ -39,7 +39,7 @@ Paddle Serving provides RPC and HTTP protocol for users. For HTTP service, we re
 
 <p align="center">
     <br>
-<img src='user_groups.png' width = "700" height = "470">
+<img src='images/user_groups.png' width = "700" height = "470">
     <br>
 <p>
 
@@ -96,7 +96,7 @@ Distributed Sparse Parameter Indexing is commonly seen in advertising and recomm
 
 <p align="center">
     <br>
-<img src='cube_eng.png' width = "450" height = "230">
+<img src='images/cube_eng.png' width = "450" height = "230">
     <br>
 <p>
 
@@ -116,7 +116,7 @@ The core execution engine of Paddle Serving is a Directed acyclic graph(DAG). In
 
 <p align="center">
     <br>
-<img src='design_doc.png'">
+<img src='images/design_doc.png'">
     <br>
 <p>
 
@@ -132,7 +132,7 @@ After sufficient offline evaluation of the model, online A/B test is usually nee
 
 <p align="center">
     <br>
-<img src='abtest.png' width = "345" height = "230">
+<img src='images/abtest.png' width = "345" height = "230">
     <br>
 <p>
 
@@ -188,7 +188,7 @@ the end-to-end deep learning model can not solve all the problems at present. Us
 ### 5.1 Network Communication Mechanism
 The network framework of Pipeline Serving uses gRPC and gPRC gateway. The gRPC service receives the RPC request, and the gPRC gateway receives the RESTful API request and forwards the request to the gRPC Service through the reverse proxy server. Therefore, the network layer of Pipeline Serving receives both RPC and RESTful API.
 <center>
-<img src='pipeline_serving-image1.png' height = "250" align="middle"/>
+<img src='images/pipeline_serving-image1.png' height = "250" align="middle"/>
 </center>
 
 ### 5.2 Core Design And Use Cases
@@ -196,7 +196,7 @@ The network framework of Pipeline Serving uses gRPC and gPRC gateway. The gRPC s
 The core design of Pipeline Serving is a graph execution engine, and the basic processing units are OP and Channel. A set of directed acyclic graphs can be realized through combination. Reference for design and use documents《[Pipeline Serving](PIPELINE_SERVING.md)》
 
 <center>
-<img src='pipeline_serving-image2.png' height = "300" align="middle"/>
+<img src='images/pipeline_serving-image2.png' height = "300" align="middle"/>
 </center>
 
 ----
diff --git a/doc/DESIGN_DOC_CN.md b/doc/DESIGN_DOC_CN.md
index fd904d119cd68e2b5179c04604098a72627f2228..9e00840f5817ea69f4ea5ad9c5d4aee528fcfec9 100644
--- a/doc/DESIGN_DOC_CN.md
+++ b/doc/DESIGN_DOC_CN.md
@@ -42,7 +42,7 @@ Paddle Serving面向的用户提供RPC和HTTP两种访问协议。对于HTTP协
 
 <p align="center">
     <br>
-<img src='user_groups.png' width = "700" height = "470">
+<img src='images/user_groups.png' width = "700" height = "470">
     <br>
 <p>
 
@@ -99,7 +99,7 @@ fetch_var {
 为什么要使用Paddle Serving提供的分布式稀疏参数索引服务？1）在一些推荐场景中，模型的输入特征规模通常可以达到上千亿，单台机器无法支撑T级别模型在内存的保存，因此需要进行分布式存储。2）Paddle Serving提供的分布式稀疏参数索引服务，具有并发请求多个节点的能力，从而以较低的延时完成预估服务。
 <p align="center">
     <br>
-<img src='cube_eng.png' width = "450" height = "230">
+<img src='images/cube.png' width = "450" height = "230">
     <br>
 <p>
 分布式稀疏参数索引通常在广告推荐中出现，并与分布式训练配合形成完整的离线-在线一体化部署。下图解释了其中的流程，产品的在线服务接受用户请求后将请求发送给预估服务，同时系统会记录用户的请求以进行相应的训练日志处理和拼接。离线分布式训练系统会针对流式产出的训练日志进行模型增量训练，而增量产生的模型会配送至分布式稀疏参数索引服务，同时对应的稠密的模型参数也会配送至在线的预估服务。在线服务由两部分组成，一部分是针对用户的请求提取特征后，将需要进行模型的稀疏参数索引的特征发送请求给分布式稀疏参数索引服务，针对分布式稀疏参数索引服务返回的稀疏参数再进行后续深度学习模型的计算流程，从而完成预估。
@@ -118,7 +118,7 @@ C++ Serving采用[better-rpc](https://github.com/apache/incubator-brpc)进行底
 C++ Serving的核心执行引擎是一个有向无环图，图中的每个节点代表预估服务的一个环节，例如计算模型预测打分就是其中一个环节。有向无环图有利于可并发节点充分利用部署实例内的计算资源，缩短延时。一个例子，当同一份输入需要送入两个不同的模型进行预估，并将两个模型预估的打分进行加权求和时，两个模型的打分过程即可以通过有向无环图的拓扑关系并发。
 <p align="center">
     <br>
-<img src='design_doc.png'">
+<img src='images/design_doc.png'">
     <br>
 <p>
 
@@ -136,7 +136,7 @@ Paddle Serving采用对称加密算法对模型进行加密，在服务加载模
 
 <p align="center">
     <br>
-<img src='abtest.png' width = "345" height = "230">
+<img src='images/abtest.png' width = "345" height = "230">
     <br>
 <p>
 
@@ -189,13 +189,13 @@ imdb_service.run_server()
 ### 5.1 网络框架
 Pipeline Serving的网络框架采用gRPC和gPRC gateway。gRPC service接收RPC请求，gPRC gateway接收RESTful API请求通过反向代理服务器将请求转发给gRPC Service。即，Pipeline Serving的网络层同时接收RPC和RESTful API。
 <center>
-<img src='pipeline_serving-image1.png' height = "250" align="middle"/>
+<img src='images/pipeline_serving-image1.png' height = "250" align="middle"/>
 </center>
 
 ### 5.2 核心设计与使用用例
 Pipeline Serving核心设计是图执行引擎，基本处理单元是OP和Channel，通过组合实现一套有向无环图，设计与使用文档参考《[Pipeline Serving设计与实现](PIPELINE_SERVING_CN.md)》
 <center>
-<img src='pipeline_serving-image2.png' height = "300" align="middle"/>
+<img src='images/pipeline_serving-image2.png' height = "300" align="middle"/>
 </center>
 ----
 
diff --git a/doc/GRPC_IMPL_CN.md b/doc/GRPC_IMPL_CN.md
index bac9caf7340515212d975ba8721475ed6bfa4cad..0928b9eee6391e7b1b8e1d4316033daae239db9e 100644
--- a/doc/GRPC_IMPL_CN.md
+++ b/doc/GRPC_IMPL_CN.md
@@ -18,7 +18,7 @@
   
 使用gRPC接口，Client端可以在Win/Linux/MacOS平台上调用不同语言。gRPC 接口实现结构如下：
 
-![](https://github.com/PaddlePaddle/Serving/blob/develop/doc/grpc_impl.png)
+![](images/grpc_impl.png)
 
 ## 1.与bRPC接口对比
 
diff --git a/doc/PIPELINE_SERVING.md b/doc/PIPELINE_SERVING.md
index 592bd382323bf6b312a104c11486376796598f4d..15555aa4b76bdf16ce95b538b87201f801c72fb8 100644
--- a/doc/PIPELINE_SERVING.md
+++ b/doc/PIPELINE_SERVING.md
@@ -18,7 +18,7 @@ Paddle Serving provides a user-friendly programming framework for multi-model co
 The Server side is built based on <b>RPC Service</b> and <b>graph execution engine</b>. The relationship between them is shown in the following figure.
 
 <div align=center>
-<img src='pipeline_serving-image1.png' height = "250" align="middle"/>
+<img src='images/pipeline_serving-image1.png' height = "250" align="middle"/>
 </div>
 
 ### 1.1 RPC Service
@@ -61,7 +61,7 @@ The graph execution engine consists of OPs and Channels, and the connected OPs s
 - For cases where large data needs to be transferred between OPs, consider RAM DB external memory for global storage and data transfer by passing index keys in Channel.
 
 <div align=center>
-<img src='pipeline_serving-image2.png' height = "300" align="middle"/>
+<img src='images/pipeline_serving-image2.png' height = "300" align="middle"/>
 </div>
 
 
@@ -80,7 +80,7 @@ The graph execution engine consists of OPs and Channels, and the connected OPs s
 - The following illustration shows the design of Channel in the graph execution engine, using input buffer and output buffer to align data between multiple OP inputs and multiple OP outputs, with a queue in the middle to buffer.
 
 <div align=center>
-<img src='pipeline_serving-image3.png' height = "500" align="middle"/>
+<img src='images/pipeline_serving-image3.png' height = "500" align="middle"/>
 </div>
 
 
@@ -323,7 +323,7 @@ All examples of pipelines are in [examples/pipeline/](../python/examples/pipelin
 Here, we build a simple imdb model enable example to show how to use Pipeline Serving. The relevant code can be found in the `python/examples/pipeline/imdb_model_ensemble` folder. The Server-side structure in the example is shown in the following figure:
 
 <div align=center>
-<img src='pipeline_serving-image4.png' height = "200" align="middle"/>
+<img src='images/pipeline_serving-image4.png' height = "200" align="middle"/>
 </div>
 
 ### 3.1 Files required for pipeline deployment
diff --git a/doc/PIPELINE_SERVING_CN.md b/doc/PIPELINE_SERVING_CN.md
index 6ffa419382d071e3eb8cb26770b47d1fc259fb2c..aad71638f87b1ab4bb69456d33e615373d6d2629 100644
--- a/doc/PIPELINE_SERVING_CN.md
+++ b/doc/PIPELINE_SERVING_CN.md
@@ -20,7 +20,7 @@ Paddle Serving提供了用户友好的多模型组合服务编程框架，Pipeli
 Server端基于<b>RPC服务层</b>和<b>图执行引擎</b>构建，两者的关系如下图所示。
 
 <div align=center>
-<img src='pipeline_serving-image1.png' height = "250" align="middle"/>
+<img src='images/pipeline_serving-image1.png' height = "250" align="middle"/>
 </div>
 
 </n>
@@ -65,7 +65,7 @@ Response中`err_no`和`err_msg`表达处理结果的正确性和错误信息，`
 - 对于 OP 之间需要传输过大数据的情况，可以考虑 RAM DB 外存进行全局存储，通过在 Channel 中传递索引的 Key 来进行数据传输
 
 <div align=center>
-<img src='pipeline_serving-image2.png' height = "300" align="middle"/>
+<img src='images/pipeline_serving-image2.png' height = "300" align="middle"/>
 </div>
 
 
@@ -84,7 +84,7 @@ Response中`err_no`和`err_msg`表达处理结果的正确性和错误信息，`
 - 下图为图执行引擎中 Channel 的设计，采用 input buffer 和 output buffer 进行多 OP 输入或多 OP 输出的数据对齐，中间采用一个 Queue 进行缓冲
 
 <div align=center>
-<img src='pipeline_serving-image3.png' height = "500" align="middle"/>
+<img src='images/pipeline_serving-image3.png' height = "500" align="middle"/>
 </div>
 
 #### <b>1.2.3 预测类型的设计</b>
@@ -328,7 +328,7 @@ class ResponseOp(Op):
 以 imdb_model_ensemble 为例来展示如何使用 Pipeline Serving，相关代码在 `python/examples/pipeline/imdb_model_ensemble` 文件夹下可以找到，例子中的 Server 端结构如下图所示：
 
 <div align=center>
-<img src='pipeline_serving-image4.png' height = "200" align="middle"/>
+<img src='images/pipeline_serving-image4.png' height = "200" align="middle"/>
 </div>
 
 ### 3.1 Pipeline部署需要的文件
diff --git a/doc/SERVER_DAG.md b/doc/SERVER_DAG.md
index 8441e7d7fa8ea00d2d7accedb3f7cd2baab745ad..ae181798cff7ab596e8acb950badcc61fb7ffa89 100644
--- a/doc/SERVER_DAG.md
+++ b/doc/SERVER_DAG.md
@@ -9,7 +9,7 @@ This document shows the concept of computation graph on server. How to define co
 Deep neural nets often have some preprocessing steps on input data, and postprocessing steps on model inference scores. Since deep learning frameworks are now very flexible, it is possible to do preprocessing and postprocessing outside the training computation graph. If we want to do input data preprocessing and inference result postprocess on server side, we have to add the corresponding computation logics on server. Moreover, if a user wants to do inference with the same inputs on more than one model, the best way is to do the inference concurrently on server side given only one client request so that we can save some network computation overhead. For the above two reasons, it is naturally to think of a Directed Acyclic Graph(DAG) as the main computation method for server inference. One example of DAG is as follows:
 
 <center>
-<img src='server_dag.png' width = "450" height = "500" align="middle"/>
+<img src='images/server_dag.png' width = "450" height = "500" align="middle"/>
 </center>
 
 ## How to define Node
@@ -19,7 +19,7 @@ Deep neural nets often have some preprocessing steps on input data, and postproc
 PaddleServing has some predefined Computation Node in the framework. A very commonly used Computation Graph is the simple reader-inference-response mode that can cover most of the single model inference scenarios. A example graph and the corresponding DAG definition code is as follows.
 
 <center>
-<img src='simple_dag.png' width = "260" height = "370" align="middle"/>
+<img src='images/simple_dag.png' width = "260" height = "370" align="middle"/>
 </center>
 
 ``` python
@@ -51,7 +51,7 @@ python -m paddle_serving_server.serve --model uci_housing_model --thread 10 --po
 An example containing multiple input nodes is given in the [MODEL_ENSEMBLE_IN_PADDLE_SERVING](./deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING.md). A example graph and the corresponding DAG definition code is as follows.
 
 <center>
-<img src='complex_dag.png' width = "480" height = "400" align="middle"/>
+<img src='images/complex_dag.png' width = "480" height = "400" align="middle"/>
 </center>
 
 ```python
diff --git a/doc/SERVER_DAG_CN.md b/doc/SERVER_DAG_CN.md
index 16e53bc6a98af6abd4a114137f2e72593242afcd..8f073c635e92ae54822cab2c3b2d082545753241 100644
--- a/doc/SERVER_DAG_CN.md
+++ b/doc/SERVER_DAG_CN.md
@@ -9,7 +9,7 @@
 深度神经网络通常在输入数据上有一些预处理步骤，而在模型推断分数上有一些后处理步骤。 由于深度学习框架现在非常灵活，因此可以在训练计算图之外进行预处理和后处理。 如果要在服务器端进行输入数据预处理和推理结果后处理，则必须在服务器上添加相应的计算逻辑。 此外，如果用户想在多个模型上使用相同的输入进行推理，则最好的方法是在仅提供一个客户端请求的情况下在服务器端同时进行推理，这样我们可以节省一些网络计算开销。 由于以上两个原因，自然而然地将有向无环图（DAG）视为服务器推理的主要计算方法。 DAG的一个示例如下：
 
 <center>
-<img src='server_dag.png' width = "450" height = "500" align="middle"/>
+<img src='images/server_dag.png' width = "450" height = "500" align="middle"/>
 </center>
 
 ## 如何定义节点
@@ -18,7 +18,7 @@
 
 PaddleServing在框架中具有一些预定义的计算节点。 一种非常常用的计算图是简单的reader-infer-response模式，可以涵盖大多数单一模型推理方案。 示例图和相应的DAG定义代码如下。
 <center>
-<img src='simple_dag.png' width = "260" height = "370" align="middle"/>
+<img src='images/simple_dag.png' width = "260" height = "370" align="middle"/>
 </center>
 
 ``` python
@@ -50,7 +50,7 @@ python -m paddle_serving_server.serve --model uci_housing_model --thread 10 --po
 在[Paddle Serving中的集成预测](./deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING_CN.md)文档中给出了一个包含多个输入节点的样例，示意图和代码如下。
 
 <center>
-<img src='complex_dag.png' width = "480" height = "400" align="middle"/>
+<img src='images/complex_dag.png' width = "480" height = "400" align="middle"/>
 </center>
 
 ```python
diff --git a/doc/SERVING_AUTH_DOCKER.md b/doc/SERVING_AUTH_DOCKER.md
index 2ef2bbb8ab9341e7c3aca55dc63b3f7bd80b54ca..a3c303e3136a5d0fd0967bf68b1de2a1bc94eb33 100644
--- a/doc/SERVING_AUTH_DOCKER.md
+++ b/doc/SERVING_AUTH_DOCKER.md
@@ -32,17 +32,17 @@ ee59a3dd4806        registry.baidubce.com/serving_dev/serving-runtime:cpu-py36
 
 其中我们之前serving容器 以 9393端口暴露，KONG网关的端口是8443， KONG的Web控制台的端口是8001。接下来我们在浏览器访问 `https://$IP_ADDR:8001`, 其中 IP_ADDR就是宿主机的IP。
 
-<img src="kong-dashboard.png">
+<img src="images/kong-dashboard.png">
 可以看到在注册结束后，登陆，看到了 DASHBOARD，我们先看SERVICES，可以看到`serving_service`，这意味着我们端口在9393的Serving服务已经在KONG当中被注册。
 
-<img src="kong-services.png">
-<img src="kong-routes.png">
+<img src="images/kong-services.png">
+<img src="images/kong-routes.png">
 
 然后在ROUTES中，我们可以看到 serving 被链接到了 `/serving-uci`。
 
 最后我们点击 CONSUMERS - default_user - Credentials - API KEYS ，我们可以看到 `Api Keys` 下看到很多key
 
-<img src="kong-api_keys.png">
+<img src="images/kong-api_keys.png">
 
 接下来可以通过curl访问
 
@@ -194,6 +194,3 @@ credentials:
 curl -H "Content-Type:application/json" -H "apikey:ZGVmYXVsdC1hcGlrZXkK" -X POST -d '{"feed":[{"x": [0.0137, -0.1136, 0.2553, -0.0692, 0.0582, -0.0727, -0.1583, -0.0584, 0.6283, 0.4919, 0.1856, 0.0795, -0.0332]}], "fetch":["price"]}' https://$IP:$PORT/foo/uci/prediction -k
 ```
 我们可以看到 apikey 已经加入到了curl请求的header当中。
-
-
-
diff --git a/doc/architecture.png b/doc/architecture.png
deleted file mode 100644
index df20d0a522f354a0806cc3c71e8f945ec04293a7..0000000000000000000000000000000000000000
Binary files a/doc/architecture.png and /dev/null differ
diff --git a/doc/bert-benchmark-batch-size-1.png b/doc/bert-benchmark-batch-size-1.png
deleted file mode 100644
index 73cccde83ab6f7163eb2280f99655f5378ebe261..0000000000000000000000000000000000000000
Binary files a/doc/bert-benchmark-batch-size-1.png and /dev/null differ
diff --git a/doc/blank.png b/doc/blank.png
deleted file mode 100644
index d132d5abf7c1298a100ef2f7401d39879e77396d..0000000000000000000000000000000000000000
Binary files a/doc/blank.png and /dev/null differ
diff --git a/doc/coding_mode.png b/doc/coding_mode.png
deleted file mode 100644
index 617bc14166b60ec81609dd1c596a87d2a24347c9..0000000000000000000000000000000000000000
Binary files a/doc/coding_mode.png and /dev/null differ
diff --git a/doc/deprecated/BENCHMARKING.md b/doc/deprecated/BENCHMARKING.md
deleted file mode 100644
index 3544498e2ee7f8bdf6c32d7e16d226f7c4d81b84..0000000000000000000000000000000000000000
--- a/doc/deprecated/BENCHMARKING.md
+++ /dev/null
@@ -1,631 +0,0 @@
-本文以文本分类任务为例搭建Serving预测服务，给出Serving框架性能数据：
-
-1) 不同模型下预测服务单线程响应时间、QPS、准确率等指标和单机模式的对比
-
-2) 不同模型下Serving扩展能力对比
-
-3) Serving框架净开销测试
-
-# 1. Serving单次请求时间分解
-
-下图是一个对serving请求的耗时阶段的不完整分析。图中对brpc的开销，只列出了bthread创建和启动开销。
-
-![](serving-timings.png)
-
-(右键在新窗口中浏览大图)
-
-试与单机模式对比：
-
-1) 从原始样例填充PaddleTensor (几us到几十us)
-
-2) 从PaddleTensor填充LoDTensor (几us到几十us)
-
-3) inference (几十us到几百ms)
-
-4) 从LoDTensor填充PaddleTensor (几us到几十us)
-
-5) 从Paddletensor读取预测结果 (几us到几十us)
-
-与单机模式相比，serving模式增加了：
-
-1) protobuf数据构造和序列化与反序列化 (几us到几十us)
-
-2) 网络通信 (单机十几us，远程500us到几十ms)
-
-3) 和bthread创建于调度等。(十几us)
-
-从client端看(图中total time T2)，serving模式增加的时间，与inference时间的比例，对整个client端观察到的系统吞吐关系密切：
-
-1) 当inference时间达到10+ms到几百ms (例如，文本分类的CNN模型和LSTM模型)，而serving模式增加的时间只有几ms，则client端观察到的吞吐与单机模式几乎一致
-
-2) 当inference时间只有几个us到几十个us (例如，文本分类的BOW模型)，而serving模式增加了几个ms，则client端观察到的吞吐与单机模式相比，会下降到单机模式的20%甚至更低。
-
-**为了验证上述假设，文本分类任务的serving模式测试，需要在几个不同模型上分别进行，分别记录serving模式下，client端吞吐量的变化情况。**
-
-# 2. 测试任务和测试环境
-
-## 2.1 测试任务
-
-文本分类的三种常见模型：BOW, CNN, LSTM
-
-**Batch Size: 本实验中所有请求的batch size均为50**
-
-## 2.2 测试环境
-
-
-| | CPU型号、核数 | 内存 |
-| --- | --- | --- |
-| Serving所在机器 | Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 40核 | 128G |
-| Client所在机器 | Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 40核 | 128G |
-
-Serving端与Client端通信时延：0.102 ms
-
-
-# 3. 预测服务单线程响应时间、QPS、准确率等指标与单机模式的对比
-
-本测试用来确定Serving的准确率、QPS和响应时间等指标与单机模式相比是否无明显异常
-
-<table>
-<thead>
-  <tr>
-    <th> 模型</th>
-    <th colspan=3> Serving（client与serving同机器）</th>
-    <th colspan=3> 单机</th>
-  </tr>
-</thead>
-<tbody>
-  <tr>
-    <td></td>
-    <td>QPS</td>
-    <td>Latency (ms)</td>
-    <td>Accuracy</td>
-    <td>QPS</td>
-    <td>Latency (ms)</td>
-    <td>Accuracy</td>
-  </tr>
-  <tr>
-    <td>BOW</td>
-    <td> 265.393 </td>
-    <td>3</td>
-    <td>0.84348</td>
-    <td>715.973366</td>
-    <td>1.396700</td>
-    <td>0.843480</td>
-  </tr>
-  <tr>
-    <td>CNN</td>
-    <td>23.3002</td>
-    <td>42</td>
-    <td>0.8962</td>
-    <td>25.372693</td>
-    <td>39.412450</td>
-    <td>0.896200</td>
-  </tr>
-  <tr>
-    <td>LSTM</td>
-    <td>5.19578</td>
-    <td>192</td>
-    <td>0.85784</td>
-    <td>5.321040</td>
-    <td>187.933202</td>
-    <td> 0.857840</td>
-  </tr>
-</tbody>
-</table>
-可以看到，在预测时间很短的BOW模型上，通过serving进行服务，QPS下降为单机模式下的1/3左右，而在预测时间较长的CNN和LSTM模型上，QPS几乎与单机模式持平。这也验证了第1节的预期。
-
-# 4. Serving扩展能力
-
-Serving扩展能力的测试是指，在不同模型上：
-
-1) 固定serving端brpc使用的系统线程数
-
-2) 不断增加client端并发请求数
-
-3) 运行一段时间后，client端记录当前设定下QPS、平均响应时间和各个分位点的响应时间等信息
-
-4）serving与client在不同机器上，Serving端与Client端通信时延：0.102 ms
-
-## 4.1 BOW模型
-
-### Serving 4线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 561.325 | 3563 | 7.1265 | 9 | 11 | 23 | 62 |
-| 8 | 807.428 | 4954 | 9.9085 | 7 | 10 | 24 | 31 |
-| 12 | 894.721 | 6706 | 13.4123 | 18 | 22 | 41 | 61 |
-| 16 | 993.542 | 8052 | 16.1057 | 22 | 28 | 47 | 75 |
-| 20 | 834.725 | 11980 | 23.9615 | 32 | 40 | 64 | 81 |
-| 24 | 649.316 | 18481 | 36.962 | 50 | 67 | 149 | 455 |
-| 28 | 709.975 | 19719 | 39.438 | 53 | 76 | 159 | 293 |
-| 32 | 661.868 | 24174 | 48.3495 | 62 | 90 | 294 | 560 |
-| 36 | 551.234 | 32654 | 65.3081 | 83 | 129 | 406 | 508 |
-| 40 | 525.155 | 38084 | 76.1687 | 99 | 143 | 464 | 567 |
-
-### Serving 8线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 397.693 | 5029 | 10.0585 | 11 | 15 | 75 | 323 |
-| 8 | 501.567 | 7975 | 15.9515 | 18 | 25 | 113 | 327 |
-| 12 | 598.027 | 10033 | 20.0663 | 24 | 33 | 125 | 390 |
-| 16 | 691.384 | 11571 | 23.1427 | 31 | 42 | 105 | 348 |
-| 20 | 468.099 | 21363 | 42.7272 | 53 | 74 | 232 | 444 |
-| 24 | 424.553 | 28265 | 56.5315 | 67 | 102 | 353 | 448 |
-| 28 | 587.692 | 23822 | 47.6457 | 61 | 83 | 287 | 494 |
-| 32 | 692.911 | 23091 | 46.1833 | 66 | 94 | 184 | 389 |
-| 36 | 809.753 | 22229 | 44.4581 | 59 | 76 | 256 | 556 |
-| 40 | 762.108 | 26243 | 52.4869 | 74 | 98 | 290 | 475 |
-
-### Serving 12线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 442.478 | 4520 | 9.0405 | 12 | 15 | 31 | 46 |
-| 8 | 497.884 | 8034 | 16.0688 | 19 | 25 | 130 | 330 |
-| 12 | 797.13 | 7527 | 15.0552 | 16 | 22 | 162 | 326 |
-| 16 | 674.707 | 11857 | 23.7154 | 30 | 42 | 229 | 455 |
-| 20 | 489.956 | 20410 | 40.8209 | 49 | 68 | 304 | 437 |
-| 24 | 452.335 | 26529 | 53.0582 | 66 | 85 | 341 | 414 |
-| 28 | 753.093 | 18590 | 37.1812 | 50 | 65 | 184 | 421 |
-| 32 | 932.498 | 18278 | 36.5578 | 48 | 62 | 109 | 337 |
-| 36 | 932.498 | 19303 | 38.6066 | 54 | 70 | 110 | 164 |
-| 40 | 921.532 | 21703 | 43.4066 | 59 | 75 | 125 | 451 |
-
-### Serving 16线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 559.597 | 3574 | 7.1485 | 9 | 11 | 24 | 56 |
-| 8 | 896.66 | 4461 | 8.9225 | 12 | 15 | 23 | 42 |
-| 12 | 1014.37 | 5915 | 11.8305 | 16 | 20 | 34 | 63 |
-| 16 | 1046.98 | 7641 | 15.2837 | 21 | 28 | 48 | 64 |
-| 20 | 1188.64 | 8413 | 16.8276 | 23 | 31 | 55 | 71 |
-| 24 | 1013.43 | 11841 | 23.6833 | 34 | 41 | 63 | 86 |
-| 28 | 933.769 | 14993 | 29.9871 | 41 | 52 | 91 | 149 |
-| 32 | 930.665 | 17192 | 34.3844 | 48 | 60 | 97 | 137 |
-| 36 | 880.153 | 20451 | 40.9023 | 57 | 72 | 118 | 142 |
-| 40 | 939.144 | 21296 | 42.5938 | 59 | 75 | 126 | 163 |
-
-### Serving 20线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 686.813 | 2912 | 5.825 | 7 | 9 | 18 | 54 |
-| 8 | 1016.26 | 3936 | 7.87375 | 10 | 13 | 24 | 33 |
-| 12 | 1282.87 | 4677 | 9.35483 | 12 | 15 | 35 | 73 |
-| 16 | 1253.13 | 6384 | 12.7686 | 17 | 23 | 40 | 54 |
-| 20 | 1276.49 | 7834 | 15.6696 | 22 | 28 | 53 | 90 |
-| 24 | 1273.34 | 9424 | 18.8497 | 26 | 35 | 66 | 93 |
-| 28 | 1258.31 | 11126 | 22.2535 | 31 | 41 | 71 | 133 |
-| 32 | 1027.95 | 15565 | 31.1308 | 43 | 54 | 81 | 103 |
-| 36 | 912.316 | 19730 | 39.4612 | 52 | 66 | 106 | 131 |
-| 40 | 808.865 | 24726 | 49.4539 | 64 | 79 | 144 | 196 |
-
-### Serving 24线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 635.728 | 3146 | 6.292 | 7 | 10 | 22 | 48 |
-| 8 | 1089.03 | 3673 | 7.346 | 9 | 11 | 21 | 40 |
-| 12 | 1087.55 | 5056 | 10.1135 | 13 | 17 | 41 | 51 |
-| 16 | 1251.17 | 6394 | 12.7898 | 17 | 24 | 39 | 54 |
-| 20 | 1241.31 | 8056 | 16.1136 | 21 | 29 | 51 | 72 |
-| 24 | 1327.29 | 9041 | 18.0837 | 24 | 33 | 59 | 77 |
-| 28 | 1066.02 | 13133 | 26.2664 | 37 | 47 | 84 | 109 |
-| 32 | 1034.33 | 15469 | 30.9384 | 41 | 51 | 94 | 115 |
-| 36 | 896.191 | 20085 | 40.1708 | 55 | 68 | 110 | 168 |
-| 40 | 701.508 | 28510 | 57.0208 | 74 | 88 | 142 | 199 |
-
-### Serving 28线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 592.944 | 3373 | 6.746 | 8 | 10 | 21 | 56 |
-| 8 | 1050.14 | 3809 | 7.619 | 9 | 12 | 22 | 41 |
-| 12 | 1220.75 | 4915 | 9.83133 | 13 | 16 | 26 | 51 |
-| 16 | 1178.38 | 6789 | 13.579 | 19 | 24 | 41 | 65 |
-| 20 | 1184.97 | 8439 | 16.8789 | 23 | 30 | 51 | 72 |
-| 24 | 1234.95 | 9717 | 19.4341 | 26 | 34 | 53 | 94 |
-| 28 | 1162.31 | 12045 | 24.0908 | 33 | 40 | 70 | 208 |
-| 32 | 1160.35 | 13789 | 27.5784 | 39 | 47 | 75 | 97 |
-| 36 | 991.79 | 18149 | 36.2987 | 50 | 61 | 91 | 110 |
-| 40 | 952.336 | 21001 | 42.0024 | 58 | 69 | 105 | 136 |
-
-### Serving 32线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 654.879 | 3054 | 6.109 | 7 | 9 | 18 | 39 |
-| 8 | 959.463 | 4169 | 8.33925 | 11 | 13 | 24 | 39 |
-| 12 | 1222.99 | 4906 | 9.81367 | 13 | 16 | 30 | 39 |
-| 16 | 1314.71 | 6085 | 12.1704 | 16 | 20 | 35 | 42 |
-| 20 | 1390.63 | 7191 | 14.3837 | 19 | 24 | 40 | 69 |
-| 24 | 1370.8 | 8754 | 17.5096 | 24 | 30 | 45 | 62 |
-| 28 | 1213.8 | 11534 | 23.0696 | 31 | 37 | 60 | 79 |
-| 32 | 1178.2 | 13580 | 27.1601 | 38 | 45 | 68 | 82 |
-| 36 | 1167.69 | 15415 | 30.8312 | 42 | 51 | 77 | 92 |
-| 40 | 950.841 | 21034 | 42.0692 | 55 | 65 | 96 | 137 |
-
-### Serving 36线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 611.06 | 3273 | 6.546 | 7 | 10 | 23 | 63 |
-| 8 | 948.992 | 4215 | 8.43 | 10 | 13 | 38 | 87 |
-| 12 | 1081.47 | 5548 | 11.0972 | 15 | 18 | 31 | 37 |
-| 16 | 1319.7 | 6062 | 12.1241 | 16 | 21 | 35 | 64 |
-| 20 | 1246.73 | 8021 | 16.0434 | 22 | 28 | 41 | 47 |
-| 24 | 1210.04 | 9917 | 19.8354 | 28 | 34 | 54 | 70 |
-| 28 | 1013.46 | 13814 | 27.6296 | 37 | 47 | 83 | 125 |
-| 32 | 1104.44 | 14487 | 28.9756 | 41 | 49 | 72 | 88 |
-| 36 | 1089.32 | 16524 | 33.0495 | 45 | 55 | 83 | 107 |
-| 40 | 940.115 | 21274 | 42.5481 | 58 | 68 | 101 | 138 |
-
-### Serving 40线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 610.314 | 3277 | 6.555 | 8 | 11 | 20 | 57 |
-| 8 | 1065.34 | 4001 | 8.0035 | 10 | 12 | 23 | 29 |
-| 12 | 1177.86 | 5632 | 11.2645 | 14 | 18 | 33 | 310 |
-| 16 | 1252.74 | 6386 | 12.7723 | 17 | 22 | 40 | 63 |
-| 20 | 1290.16 | 7751 | 15.5036 | 21 | 27 | 47 | 66 |
-| 24 | 1153.07 | 10407 | 20.8159 | 28 | 36 | 64 | 81 |
-| 28 | 1300.39 | 10766 | 21.5326 | 30 | 37 | 60 | 78 |
-| 32 | 1222.4 | 13089 | 26.1786 | 36 | 45 | 75 | 99 |
-| 36 | 1141.55 | 15768 | 31.5374 | 43 | 52 | 83 | 121 |
-| 40 | 1125.24 | 17774 | 35.5489 | 48 | 57 | 93 | 190 |
-
-下图是Paddle Serving在BOW模型上QPS随serving端线程数增加而变化的图表。可以看出当线程数较少时(4线程/8线程/12线程)，QPS的变化规律非常杂乱；当线程数较多时，QPS曲线又基本趋于一致，基本无线性增长关系。
-
-![](qps-threads-bow.png)
-
-(右键在新窗口中浏览大图)
-
-## 4.2 CNN模型
-
-### Serving 4线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 81.9437 | 24407 | 47 | 55 | 64 | 80 | 91 |
-| 8 | 142.486 | 28073 | 53 | 65 | 71 | 86 | 106 |
-| 12 | 173.732 | 34536 | 66 | 79 | 86 | 105 | 126 |
-| 16 | 174.894 | 45742 | 89 | 101 | 109 | 131 | 151 |
-| 20 | 172.58 | 57944 | 113 | 129 | 138 | 159 | 187 |
-| 24 | 178.216 | 67334 | 132 | 147 | 158 | 189 | 283 |
-| 28 | 171.315 | 81721 | 160 | 180 | 192 | 223 | 291 |
-| 32 | 178.17 | 89802 | 176 | 195 | 208 | 251 | 288 |
-| 36 | 173.762 | 103590 | 204 | 227 | 241 | 278 | 309 |
-| 40 | 177.335 | 112781 | 223 | 246 | 262 | 296 | 315 |
-
-### Serving 8线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 86.2999 | 23175 | 44 | 50 | 54 | 72 | 92 |
-| 8 | 143.73 | 27830 | 53 | 65 | 71 | 83 | 91 |
-| 12 | 178.471 | 33619 | 65 | 77 | 85 | 106 | 144 |
-| 16 | 180.485 | 44325 | 86 | 99 | 108 | 131 | 149 |
-| 20 | 180.466 | 55412 | 108 | 122 | 131 | 153 | 170 |
-| 24 | 174.452 | 68787 | 134 | 151 | 162 | 189 | 214 |
-| 28 | 174.158 | 80387 | 157 | 175 | 186 | 214 | 236 |
-| 32 | 172.857 | 92562 | 182 | 202 | 214 | 244 | 277 |
-| 36 | 172.171 | 104547 | 206 | 228 | 241 | 275 | 304 |
-| 40 | 174.435 | 114656 | 226 | 248 | 262 | 306 | 338 |
-
-### Serving 12线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 85.6274 | 23357 | 45 | 50 | 55 | 75 | 105 |
-| 8 | 137.632 | 29063 | 55 | 67 | 73 | 88 | 134 |
-| 12 | 187.793 | 31950 | 61 | 73 | 79 | 94 | 123 |
-| 16 | 211.512 | 37823 | 73 | 87 | 94 | 113 | 134 |
-| 20 | 206.624 | 48397 | 93 | 109 | 118 | 145 | 217 |
-| 24 | 209.933 | 57161 | 111 | 128 | 137 | 157 | 190 |
-| 28 | 198.689 | 70462 | 137 | 154 | 162 | 186 | 205 |
-| 32 | 214.024 | 74758 | 146 | 165 | 176 | 204 | 228 |
-| 36 | 223.947 | 80376 | 158 | 177 | 189 | 222 | 282 |
-| 40 | 226.045 | 88478 | 174 | 193 | 204 | 236 | 277 |
-
-### Serving 16线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 82.9119 | 24122 | 45 | 52 | 60 | 79 | 99 |
-| 8 | 145.82 | 27431 | 51 | 63 | 69 | 85 | 114 |
-| 12 | 193.287 | 31042 | 59 | 71 | 77 | 92 | 139 |
-| 16 | 240.428 | 33274 | 63 | 76 | 82 | 99 | 127 |
-| 20 | 249.457 | 40087 | 77 | 91 | 99 | 127 | 168 |
-| 24 | 263.673 | 45511 | 87 | 102 | 110 | 136 | 186 |
-| 28 | 272.729 | 51333 | 99 | 115 | 123 | 147 | 189 |
-| 32 | 269.515 | 59366 | 115 | 132 | 140 | 165 | 192 |
-| 36 | 267.4 | 67315 | 131 | 148 | 157 | 184 | 220 |
-| 40 | 264.939 | 75489 | 147 | 164 | 173 | 200 | 235 |
-
-### Serving 20线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 85.5615 | 23375 | 44 | 49 | 55 | 73 | 101 |
-| 8 | 148.765 | 26888 | 50 | 61 | 69 | 84 | 97 |
-| 12 | 196.11 | 30595 | 57 | 70 | 75 | 88 | 108 |
-| 16 | 241.087 | 33183 | 63 | 76 | 82 | 98 | 115 |
-| 20 | 291.24 | 34336 | 65 | 66 | 78 | 99 | 114 |
-| 24 | 301.515 | 39799 | 76 | 90 | 97 | 122 | 194 |
-| 28 | 314.303 | 44543 | 86 | 101 | 109 | 132 | 173 |
-| 32 | 327.486 | 48857 | 94 | 109 | 118 | 143 | 196 |
-| 36 | 320.422 | 56176 | 109 | 125 | 133 | 157 | 190 |
-| 40 | 325.399 | 61463 | 120 | 137 | 145 | 174 | 216 |
-
-### Serving 24线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 85.6568 | 23349 | 45 | 50 | 57 | 72 | 110 |
-| 8 | 154.919 | 25820 | 48 | 57 | 66 | 81 | 95 |
-| 12 | 221.992 | 27028 | 51 | 61 | 69 | 85 | 100 |
-| 16 | 272.889 | 29316 | 55 | 68 | 74 | 89 | 101 |
-| 20 | 300.906 | 33233 | 63 | 75 | 81 | 95 | 108 |
-| 24 | 326.735 | 36727 | 69 | 82 | 87 | 102 | 114 |
-| 28 | 339.057 | 41291 | 78 | 92 | 99 | 119 | 137 |
-| 32 | 346.868 | 46127 | 88 | 103 | 110 | 130 | 155 |
-| 36 | 338.429 | 53187 | 102 | 117 | 124 | 146 | 170 |
-| 40 | 320.919 | 62321 | 119 | 135 | 144 | 176 | 226 |
-
-### Serving 28线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 87.8773 | 22759 | 43 | 48 | 52 | 76 | 112 |
-| 8 | 154.524 | 25886 | 49 | 58 | 66 | 82 | 100 |
-| 12 | 192.709 | 31135 | 59 | 72 | 78 | 93 | 112 |
-| 16 | 253.59 | 31547 | 59 | 72 | 79 | 95 | 129 |
-| 20 | 288.367 | 34678 | 65 | 78 | 84 | 100 | 122 |
-| 24 | 307.653 | 39005 | 73 | 84 | 92 | 116 | 313 |
-| 28 | 334.105 | 41903 | 78 | 90 | 97 | 119 | 140 |
-| 32 | 348.25 | 45944 | 86 | 99 | 107 | 132 | 164 |
-| 36 | 355.661 | 50610 | 96 | 110 | 118 | 143 | 166 |
-| 40 | 350.957 | 56987 | 109 | 124 | 133 | 165 | 221 |
-
-### Serving 32线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 87.4088 | 22881 | 43 | 48 | 52 | 70 | 86 |
-| 8 | 150.733 | 26537 | 50 | 60 | 68 | 85 | 102 |
-| 12 | 197.433 | 30390 | 57 | 70 | 75 | 90 | 106 |
-| 16 | 250.917 | 31883 | 60 | 73 | 78 | 94 | 121 |
-| 20 | 286.369 | 34920 | 66 | 78 | 84 | 102 | 131 |
-| 24 | 306.029 | 39212 | 74 | 85 | 92 | 110 | 134 |
-| 28 | 323.902 | 43223 | 81 | 93 | 100 | 122 | 143 |
-| 32 | 341.559 | 46844 | 89 | 102 | 111 | 136 | 161 |
-| 36 | 341.077 | 52774 | 98 | 113 | 124 | 158 | 193 |
-| 40 | 357.814 | 55895 | 107 | 122 | 133 | 166 | 196 |
-
-### Serving 36线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 86.9036 | 23014 | 44 | 49 | 53 | 72 | 112 |
-| 8 | 158.964 | 25163 | 48 | 55 | 63 | 79 | 91 |
-| 12 | 205.086 | 29256 | 55 | 68 | 75 | 91 | 168 |
-| 16 | 238.173 | 33589 | 61 | 73 | 79 | 100 | 158 |
-| 20 | 279.705 | 35752 | 67 | 79 | 86 | 106 | 129 |
-| 24 | 318.294 | 37701 | 71 | 82 | 89 | 108 | 129 |
-| 28 | 336.296 | 41630 | 78 | 89 | 97 | 119 | 194 |
-| 32 | 360.295 | 44408 | 84 | 97 | 105 | 130 | 154 |
-| 36 | 353.08 | 50980 | 96 | 113 | 123 | 152 | 179 |
-| 40 | 362.286 | 55205 | 105 | 122 | 134 | 171 | 247 |
-
-### Serving 40线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 87.7347 | 22796 | 44 | 48 | 54 | 73 | 114 |
-| 8 | 150.483 | 26581 | 50 | 59 | 67 | 85 | 149 |
-| 12 | 202.088 | 29690 | 56 | 69 | 75 | 90 | 102 |
-| 16 | 250.485 | 31938 | 60 | 74 | 79 | 93 | 113 |
-| 20 | 289.62 | 34528 | 65 | 77 | 83 | 102 | 132 |
-| 24 | 314.408 | 38167 | 72 | 83 | 90 | 110 | 125 |
-| 28 | 321.728 | 43515 | 83 | 95 | 104 | 132 | 159 |
-| 32 | 335.022 | 47758 | 90 | 104 | 114 | 141 | 166 |
-| 36 | 341.452 | 52716 | 101 | 117 | 129 | 170 | 231 |
-| 40 | 347.953 | 57479 | 109 | 130 | 143 | 182 | 216 |
-
-下图是Paddle Serving在CNN模型上QPS随serving端线程数增加而变化的图表。可以看出，随着线程数变大，Serving QPS有较为明显的线性增长关系。可以这样解释此图表：例如，线程数为16时，基本在20个并发时达到最大QPS，此后再增加并发压力QPS基本保持稳定；当线程能够数为24线程时，基本在28并发时达到最大QPS，此后再增大并发压力qps基本保持稳定。
-
-![](qps-threads-cnn.png)
-
-(右键在新窗口中浏览大图)
-
-## 4.3 LSTM模型
-
-### Serving 4线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.8242 | 106246 | 208 | 230 | 254 | 353 | 448 |
-| 8 | 31.4584 | 127152 | 242 | 283 | 337 | 448 | 536 |
-| 12 | 35.6235 | 168428 | 328 | 384 | 455 | 601 | 732 |
-| 16 | 38.2777 | 208999 | 412 | 457 | 505 | 675 | 806 |
-| 20 | 39.3926 | 253855 | 503 | 551 | 589 | 751 | 902 |
-| 24 | 40.0085 | 299936 | 595 | 650 | 698 | 870 | 1023 |
-| 28 | 38.2019 | 366474 | 728 | 805 | 870 | 1076 | 1208 |
-| 32 | 37.7817 | 423486 | 842 | 923 | 995 | 1231 | 1363 |
-| 36 | 39.3513 | 457418 | 911 | 1018 | 1099 | 1351 | 1556 |
-| 40 | 34.7731 | 575158 | 1144 | 1296 | 1395 | 1653 | 1836 |
-
-### Serving 8线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 16.9203 | 118201 | 232 | 264 | 292 | 418 | 653 |
-| 8 | 32.8672 | 121702 | 237 | 279 | 351 | 458 | 530 |
-| 12 | 43.9741 | 136444 | 270 | 307 | 330 | 399 | 472 |
-| 16 | 43.4809 | 183989 | 364 | 403 | 430 | 566 | 769 |
-| 20 | 42.4901 | 235349 | 467 | 517 | 552 | 689 | 815 |
-| 24 | 46.0386 | 260651 | 519 | 566 | 597 | 686 | 758 |
-| 28 | 45.0191 | 310979 | 619 | 672 | 715 | 841 | 991 |
-| 32 | 47.9803 | 333470 | 664 | 713 | 745 | 837 | 953 |
-| 36 | 47.518 | 378804 | 754 | 809 | 856 | 1017 | 1202 |
-| 40 | 48.2631 | 414395 | 825 | 888 | 927 | 1048 | 1136 |
-
-### Serving 12线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.568 | 107712 | 212 | 236 | 264 | 396 | 496 |
-| 8 | 28.7212 | 139270 | 268 | 331 | 389 | 478 | 531 |
-| 12 | 37.1195 | 161640 | 315 | 411 | 444 | 523 | 580 |
-| 16 | 38.6195 | 207149 | 406 | 511 | 556 | 654 | 722 |
-| 20 | 39.8772 | 250770 | 490 | 599 | 652 | 758 | 840 |
-| 24 | 41.1097 | 291902 | 578 | 691 | 747 | 861 | 930 |
-| 28 | 39.5161 | 354286 | 699 | 822 | 875 | 979 | 1052 |
-| 32 | 40.4252 | 395793 | 785 | 899 | 957 | 1090 | 1197 |
-| 36 | 40.4617 | 444865 | 885 | 1011 | 1077 | 1215 | 1312 |
-| 40 | 41.6045 | 480717 | 957 | 1083 | 1161 | 1322 | 1429 |
-
-### Serving 16线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.456 | 108366 | 211 | 240 | 266 | 372 | 449 |
-| 8 | 29.3468 | 136301 | 265 | 319 | 367 | 454 | 510 |
-| 12 | 40.3432 | 148724 | 289 | 368 | 410 | 487 | 535 |
-| 16 | 46.0167 | 173850 | 336 | 429 | 459 | 535 | 577 |
-| 20 | 52.8142 | 189343 | 372 | 475 | 517 | 619 | 689 |
-| 24 | 49.9422 | 240278 | 475 | 581 | 625 | 728 | 805 |
-| 28 | 49.0184 | 285607 | 564 | 676 | 720 | 822 | 889 |
-| 32 | 49.3077 | 324493 | 642 | 760 | 807 | 912 | 977 |
-| 36 | 49.2754 | 365294 | 724 | 838 | 884 | 985 | 1067 |
-| 40 | 51.2923 | 389922 | 774 | 890 | 946 | 1065 | 1157 |
-
-### Serving 20线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 17.0678 | 117180 | 226 | 258 | 303 | 426 | 503 |
-| 8 | 30.9986 | 129038 | 254 | 302 | 345 | 440 | 505 |
-| 12 | 42.4962 | 141189 | 274 | 336 | 385 | 467 | 530 |
-| 16 | 48.877 | 163676 | 316 | 398 | 433 | 507 | 555 |
-| 20 | 55.1089 | 181459 | 350 | 432 | 463 | 539 | 596 |
-| 24 | 57.4941 | 208717 | 412 | 503 | 540 | 623 | 695 |
-| 28 | 57.1506 | 244967 | 483 | 577 | 614 | 702 | 779 |
-| 32 | 58.0059 | 275834 | 545 | 641 | 681 | 773 | 847 |
-| 36 | 56.8352 | 316705 | 628 | 725 | 765 | 856 | 929 |
-| 40 | 57.1989 | 349657 | 693 | 792 | 833 | 925 | 994 |
-
-### Serving 24线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 17.7026 | 112978 | 223 | 261 | 293 | 403 | 491 |
-| 8 | 26.8649 | 148893 | 288 | 377 | 414 | 492 | 556 |
-| 12 | 42.2262 | 142092 | 279 | 348 | 392 | 463 | 518 |
-| 16 | 50.3214 | 158978 | 310 | 391 | 427 | 503 | 568 |
-| 20 | 56.5803 | 176740 | 345 | 422 | 452 | 526 | 583 |
-| 24 | 63.9107 | 187762 | 367 | 443 | 472 | 546 | 595 |
-| 28 | 64.5965 | 216730 | 427 | 506 | 540 | 623 | 690 |
-| 32 | 63.4186 | 252292 | 497 | 578 | 614 | 701 | 770 |
-| 36 | 65.5919 | 274424 | 543 | 634 | 669 | 757 | 818 |
-| 40 | 65.4862 | 305408 | 605 | 695 | 731 | 824 | 898 |
-
-### Serving 28线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.6808 | 107062 | 209 | 235 | 257 | 338 | 444 |
-| 8 | 31.966 | 125133 | 240 | 281 | 340 | 451 | 507 |
-| 12 | 44.1527 | 135892 | 266 | 328 | 377 | 464 | 529 |
-| 16 | 55.0464 | 145332 | 282 | 359 | 401 | 476 | 528 |
-| 20 | 61.7234 | 162013 | 317 | 403 | 436 | 510 | 561 |
-| 24 | 67.4385 | 177940 | 349 | 425 | 454 | 525 | 590 |
-| 28 | 72.2096 | 193880 | 381 | 447 | 476 | 548 | 611 |
-| 32 | 72.8617 | 219594 | 431 | 505 | 538 | 613 | 680 |
-| 36 | 74.0488 | 243083 | 480 | 559 | 593 | 680 | 753 |
-| 40 | 71.9171 | 278098 | 551 | 629 | 665 | 755 | 825 |
-
-### Serving 32线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.6911 | 107003 | 209 | 233 | 254 | 353 | 428 |
-| 8 | 34.3059 | 116598 | 227 | 255 | 295 | 433 | 494 |
-| 12 | 45.449 | 132016 | 257 | 313 | 363 | 454 | 508 |
-| 16 | 56.7094 | 141070 | 275 | 347 | 392 | 471 | 522 |
-| 20 | 62.2615 | 160613 | 315 | 398 | 431 | 503 | 553 |
-| 24 | 66.4489 | 180590 | 354 | 423 | 453 | 523 | 570 |
-| 28 | 73.1823 | 191303 | 376 | 438 | 467 | 538 | 584 |
-| 32 | 77.7122 | 205888 | 405 | 463 | 491 | 562 | 621 |
-| 36 | 76.4029 | 235593 | 464 | 527 | 560 | 652 | 763 |
-| 40 | 77.7339 | 257288 | 509 | 576 | 609 | 692 | 779 |
-
-### Serving 36线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 18.745 | 106695 | 208 | 232 | 252 | 308 | 357 |
-| 8 | 33.6047 | 119031 | 234 | 267 | 316 | 426 | 497 |
-| 12 | 43.5076 | 137907 | 269 | 333 | 381 | 467 | 521 |
-| 16 | 55.1968 | 144936 | 284 | 360 | 402 | 477 | 529 |
-| 20 | 62.9188 | 158935 | 312 | 394 | 430 | 502 | 547 |
-| 24 | 68.7411 | 174568 | 343 | 418 | 447 | 522 | 574 |
-| 28 | 74.3033 | 188417 | 371 | 436 | 463 | 535 | 581 |
-| 32 | 78.7723 | 203117 | 401 | 459 | 488 | 561 | 612 |
-| 36 | 80.4861 | 223641 | 440 | 497 | 529 | 627 | 980 |
-| 40 | 79.6733 | 251025 | 497 | 562 | 601 | 731 | 910 |
-
-### Serving 40线程
-
-| 并发数 | QPS | 总时间 | 平均响应时间 | 80分位点响应时间 | 90分位点响应时间 | 99分位点响应时间 | 99.9分位点响应时间 |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| 4 | 17.0187 | 117518 | 231 | 267 | 302 | 416 | 505 |
-| 8 | 28.4661 | 140518 | 276 | 360 | 407 | 479 | 548 |
-| 12 | 37.6549 | 159342 | 312 | 398 | 429 | 500 | 553 |
-| 16 | 53.7681 | 148787 | 291 | 366 | 407 | 486 | 532 |
-| 20 | 60.6704 | 164825 | 321 | 402 | 435 | 511 | 564 |
-| 24 | 67.2227 | 178511 | 351 | 422 | 452 | 526 | 585 |
-| 28 | 71.6659 | 195351 | 384 | 446 | 474 | 551 | 618 |
-| 32 | 77.2745 | 207054 | 408 | 465 | 495 | 576 | 643 |
-| 36 | 80.0028 | 224992 | 445 | 502 | 538 | 636 | 705 |
-| 40 | 80.9894 | 246946 | 486 | 554 | 601 | 767 | 1181 |
-
-下图是Paddle Serving在LSTM模型上QPS随serving端线程数增加而变化的图表。可以看出，随着线程数变大，Serving QPS有较为明显的线性增长关系。可以这样解释此图表：例如，线程数为16时，基本在20个并发时达到最大QPS，此后再增加并发压力QPS基本保持稳定；当线程能够数为24线程时，基本在28并发时达到最大QPS，此后再增大并发压力qps基本保持稳定。
-
-![](qps-threads-lstm.png)
-
-(右键在新窗口中浏览大图)
-
-# 5. 净开销测试
-
-本测试是为了描画引入Serving框架后，在Serving端空转的情况下，每query消耗的时间，也就是框架引入的开销。
-
-所谓空转是指，serving端去除实际执行预测的计算时间，但保留拆包和组包逻辑。
-
-| 模型 | 净开销 (ms) |
-| --- | --- |
-| BOW | 1 |
-| CNN | 1 |
-| LSTM | 1 |
-
-# 6.结论
-
-## 6.1 单线程模式下准确率和QPS等指标与单机模式对比
-
-准确率：Serving模式下与单机模式下预测准确率一致
-
-QPS：与模型特点有关：当模型预测时间极短时，Serving框架本身的开销和网络通信固定时间在单次请求中的时间占比占了绝大部分，这导致Serving模式下的QPS与单机模式相比下降明显；当预测时间较长，Serving框架开销和网络通信时间在单次请求中的占比较小，Serving模式下QPS与单机模式下相差不多。
-
-## 6.2 Serving扩展能力
-
-当模型较为复杂时（以上述实验中CNN和LSTM模型为例），Paddle Serving能够提供较好的线性扩展能力；当模型是简单模型（以上述实验中BOW模型为例），随着serving端线程数的增加，qps的增长趋势较为杂乱，看不出明显的线性趋势。猜测是因为预测时间较短，而线程切换、框架本身的开销等占了大头，导致虽然随着线程数增加，qps也有增长，但当并发数增大时，qps反而出现下降。
-
-## 6.3 净开销测试
-
-本测试用来估计框架本身带来的时间消耗。
-
-在Serving模式下，框架引入的时间开销较小，约为1ms。
diff --git a/doc/deprecated/CTR_PREDICTION.md b/doc/deprecated/CTR_PREDICTION.md
index a55bcc3d883c31eb3ec12bc06676f11e69e23006..acfb6c08e61a8a393d3978dc4ca29b9cda631d20 100644
--- a/doc/deprecated/CTR_PREDICTION.md
+++ b/doc/deprecated/CTR_PREDICTION.md
@@ -26,7 +26,7 @@
 
 第1) - 第5)步裁剪完毕后的模型网络配置如下：
 
-![Pruned CTR prediction network](../pruned-ctr-network.png)
+![Pruned CTR prediction network](../images/pruned-ctr-network.png)
 
 
 整个裁剪过程具体说明如下：
diff --git a/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING.md b/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING.md
index 5107c6ea6a07fe9633d534f649a56b052db0e787..e0fc00301302e75ffb18c0d0ec9c385174127b71 100644
--- a/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING.md
+++ b/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING.md
@@ -10,7 +10,7 @@ Next, we will take the text classification task as an example to show model ense
 
 In this example (see the figure below), the server side predict the bow and CNN models with the same input in a service in parallel, The client side fetchs the prediction results of the two models, and processes the prediction results to get the final predict results.
 
-![simple example](../model_ensemble_example.png)
+![simple example](../images/model_ensemble_example.png)
 
 It should be noted that at present, only multiple models with the same format input and output in the same service are supported. In this example, the input and output formats of CNN and BOW model are the same.
 
diff --git a/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING_CN.md b/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING_CN.md
index 95d8fb9081798c4ec4e2d0095615d69a8f3f2298..12d6e5c3ed697c2b06ca346357fa0f2617116e4d 100644
--- a/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING_CN.md
+++ b/doc/deprecated/MODEL_ENSEMBLE_IN_PADDLE_SERVING_CN.md
@@ -10,7 +10,7 @@
 
 该样例中（见下图），Server端在一项服务中并行预测相同输入的BOW和CNN模型，Client端获取两个模型的预测结果并进行后处理，得到最终的预测结果。
 
-![simple example](../model_ensemble_example.png)
+![simple example](../images/model_ensemble_example.png)
 
 需要注意的是，目前只支持在同一个服务中使用多个相同格式输入输出的模型。在该例子中，CNN模型和BOW模型的输入输出格式是相同的。
 
diff --git a/doc/gpu-local-qps-batchsize.png b/doc/gpu-local-qps-batchsize.png
deleted file mode 100644
index 97db37518e2afd3cacccb82b0be967d605655bc9..0000000000000000000000000000000000000000
Binary files a/doc/gpu-local-qps-batchsize.png and /dev/null differ
diff --git a/doc/gpu-local-qps-concurrency.png b/doc/gpu-local-qps-concurrency.png
deleted file mode 100644
index cd4c3dd8f672c3620e452213ab363b1b7b00905e..0000000000000000000000000000000000000000
Binary files a/doc/gpu-local-qps-concurrency.png and /dev/null differ
diff --git a/doc/gpu-local-time-batchsize.png b/doc/gpu-local-time-batchsize.png
deleted file mode 100644
index 35af4a6b1e6cea4793861c6dc34b52ebddd38495..0000000000000000000000000000000000000000
Binary files a/doc/gpu-local-time-batchsize.png and /dev/null differ
diff --git a/doc/gpu-local-time-concurrency.png b/doc/gpu-local-time-concurrency.png
deleted file mode 100644
index 28626f3470fae72685300d8a6aed05c23da9593f..0000000000000000000000000000000000000000
Binary files a/doc/gpu-local-time-concurrency.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client1.png b/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client1.png
deleted file mode 100644
index 4ce901823695184deb10be4b56b2c8e9eb6d5ad7..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client1.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client2.png b/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client2.png
deleted file mode 100644
index b1535b95e112307c4ce917b1bdad5f7b34e24ad3..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-multi-concurrency-qps-batchsize-concurrency-client2.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client1.png b/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client1.png
deleted file mode 100644
index dd651e94f250a649978f0445962723aeb6ef3071..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client1.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client2.png b/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client2.png
deleted file mode 100644
index 048c095fc0607e80f3b7e51e6e2930978e20dcd0..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-multi-concurrency-time-batchsize-concurrency-client2.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client1.png b/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client1.png
deleted file mode 100644
index 9823b85055e897ea496d8ae557c9fe84f6bfedd4..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client1.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client2.png b/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client2.png
deleted file mode 100644
index 8a3723ed217eca900e561d35dfa01fdf916c57a6..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-single-concurrency-qps-batchsize-client2.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client1.png b/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client1.png
deleted file mode 100644
index 40504bb13f15feee0ebdb90f3490a57d13cd53d8..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client1.png and /dev/null differ
diff --git a/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client2.png b/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client2.png
deleted file mode 100644
index d8a90087444d85eccf7be8dd34ae1a6e5d4eaa4e..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-multi-card-single-concurrency-time-batchsize-client2.png and /dev/null differ
diff --git a/doc/gpu-serving-single-card-qps-batchsize.png b/doc/gpu-serving-single-card-qps-batchsize.png
deleted file mode 100644
index 35e0a5b60ca5659cc8e0a6e2e66e90c26a385d2a..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-single-card-qps-batchsize.png and /dev/null differ
diff --git a/doc/gpu-serving-single-card-qps-concurrency.png b/doc/gpu-serving-single-card-qps-concurrency.png
deleted file mode 100644
index 025a3908d1b172b22344a8950f4d9f0bbc6c246d..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-single-card-qps-concurrency.png and /dev/null differ
diff --git a/doc/gpu-serving-single-card-time-batchsize.png b/doc/gpu-serving-single-card-time-batchsize.png
deleted file mode 100644
index 4c7498ae22c9c5febc6d7a6566a839ded6ec6cf2..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-single-card-time-batchsize.png and /dev/null differ
diff --git a/doc/gpu-serving-single-card-time-concurrency.png b/doc/gpu-serving-single-card-time-concurrency.png
deleted file mode 100644
index fc4332536bb145846439b2e5693d1da5c3feaac3..0000000000000000000000000000000000000000
Binary files a/doc/gpu-serving-single-card-time-concurrency.png and /dev/null differ
diff --git a/doc/4v100_bert_as_service_benchmark.png b/doc/images/4v100_bert_as_service_benchmark.png
similarity index 100%
rename from doc/4v100_bert_as_service_benchmark.png
rename to doc/images/4v100_bert_as_service_benchmark.png
diff --git a/doc/abtest.png b/doc/images/abtest.png
similarity index 100%
rename from doc/abtest.png
rename to doc/images/abtest.png
diff --git a/doc/client-side-proxy.png b/doc/images/client-side-proxy.png
similarity index 100%
rename from doc/client-side-proxy.png
rename to doc/images/client-side-proxy.png
diff --git a/doc/client_inferface.png b/doc/images/client_inferface.png
similarity index 100%
rename from doc/client_inferface.png
rename to doc/images/client_inferface.png
diff --git a/doc/complex_dag.png b/doc/images/complex_dag.png
similarity index 100%
rename from doc/complex_dag.png
rename to doc/images/complex_dag.png
diff --git a/doc/criteo-cube-benchmark-avgcost.png b/doc/images/criteo-cube-benchmark-avgcost.png
similarity index 100%
rename from doc/criteo-cube-benchmark-avgcost.png
rename to doc/images/criteo-cube-benchmark-avgcost.png
diff --git a/doc/criteo-cube-benchmark-qps.png b/doc/images/criteo-cube-benchmark-qps.png
similarity index 100%
rename from doc/criteo-cube-benchmark-qps.png
rename to doc/images/criteo-cube-benchmark-qps.png
diff --git a/doc/cube-cli.png b/doc/images/cube-cli.png
similarity index 100%
rename from doc/cube-cli.png
rename to doc/images/cube-cli.png
diff --git a/doc/cube.png b/doc/images/cube.png
similarity index 100%
rename from doc/cube.png
rename to doc/images/cube.png
diff --git a/doc/cube_eng.png b/doc/images/cube_eng.png
similarity index 100%
rename from doc/cube_eng.png
rename to doc/images/cube_eng.png
diff --git a/doc/demo.gif b/doc/images/demo.gif
similarity index 100%
rename from doc/demo.gif
rename to doc/images/demo.gif
diff --git a/doc/design_doc.png b/doc/images/design_doc.png
similarity index 100%
rename from doc/design_doc.png
rename to doc/images/design_doc.png
diff --git a/doc/framework.png b/doc/images/framework.png
similarity index 100%
rename from doc/framework.png
rename to doc/images/framework.png
diff --git a/doc/grpc_impl.png b/doc/images/grpc_impl.png
similarity index 100%
rename from doc/grpc_impl.png
rename to doc/images/grpc_impl.png
diff --git a/doc/kong-api_keys.png b/doc/images/kong-api_keys.png
similarity index 100%
rename from doc/kong-api_keys.png
rename to doc/images/kong-api_keys.png
diff --git a/doc/kong-dashboard.png b/doc/images/kong-dashboard.png
similarity index 100%
rename from doc/kong-dashboard.png
rename to doc/images/kong-dashboard.png
diff --git a/doc/kong-routes.png b/doc/images/kong-routes.png
similarity index 100%
rename from doc/kong-routes.png
rename to doc/images/kong-routes.png
diff --git a/doc/kong-services.png b/doc/images/kong-services.png
similarity index 100%
rename from doc/kong-services.png
rename to doc/images/kong-services.png
diff --git a/doc/model_ensemble_example.png b/doc/images/model_ensemble_example.png
similarity index 100%
rename from doc/model_ensemble_example.png
rename to doc/images/model_ensemble_example.png
diff --git a/doc/multi-service.png b/doc/images/multi-service.png
similarity index 100%
rename from doc/multi-service.png
rename to doc/images/multi-service.png
diff --git a/doc/multi-variants.png b/doc/images/multi-variants.png
similarity index 100%
rename from doc/multi-variants.png
rename to doc/images/multi-variants.png
diff --git a/doc/pipeline_serving-image1.png b/doc/images/pipeline_serving-image1.png
similarity index 100%
rename from doc/pipeline_serving-image1.png
rename to doc/images/pipeline_serving-image1.png
diff --git a/doc/pipeline_serving-image2.png b/doc/images/pipeline_serving-image2.png
similarity index 100%
rename from doc/pipeline_serving-image2.png
rename to doc/images/pipeline_serving-image2.png
diff --git a/doc/pipeline_serving-image3.png b/doc/images/pipeline_serving-image3.png
similarity index 100%
rename from doc/pipeline_serving-image3.png
rename to doc/images/pipeline_serving-image3.png
diff --git a/doc/pipeline_serving-image4.png b/doc/images/pipeline_serving-image4.png
similarity index 100%
rename from doc/pipeline_serving-image4.png
rename to doc/images/pipeline_serving-image4.png
diff --git a/doc/predict-service.png b/doc/images/predict-service.png
similarity index 100%
rename from doc/predict-service.png
rename to doc/images/predict-service.png
diff --git a/doc/pruned-ctr-network.png b/doc/images/pruned-ctr-network.png
similarity index 100%
rename from doc/pruned-ctr-network.png
rename to doc/images/pruned-ctr-network.png
diff --git a/doc/server-side.png b/doc/images/server-side.png
similarity index 100%
rename from doc/server-side.png
rename to doc/images/server-side.png
diff --git a/doc/server_dag.png b/doc/images/server_dag.png
similarity index 100%
rename from doc/server_dag.png
rename to doc/images/server_dag.png
diff --git a/doc/server_interface.png b/doc/images/server_interface.png
similarity index 100%
rename from doc/server_interface.png
rename to doc/images/server_interface.png
diff --git a/doc/serving_logo.png b/doc/images/serving_logo.png
similarity index 100%
rename from doc/serving_logo.png
rename to doc/images/serving_logo.png
diff --git a/doc/simple_dag.png b/doc/images/simple_dag.png
similarity index 100%
rename from doc/simple_dag.png
rename to doc/images/simple_dag.png
diff --git a/doc/timeline-example.png b/doc/images/timeline-example.png
similarity index 100%
rename from doc/timeline-example.png
rename to doc/images/timeline-example.png
diff --git a/doc/user_groups.png b/doc/images/user_groups.png
similarity index 100%
rename from doc/user_groups.png
rename to doc/images/user_groups.png
diff --git a/doc/imdb-benchmark-server-16.png b/doc/imdb-benchmark-server-16.png
deleted file mode 100644
index 9e39d257ad4e6e487c4d3d1c86230304f97e738e..0000000000000000000000000000000000000000
Binary files a/doc/imdb-benchmark-server-16.png and /dev/null differ
diff --git a/doc/imdb_loss.png b/doc/imdb_loss.png
deleted file mode 100644
index 08767ef9d2a6de83200e301f8031658609cfc225..0000000000000000000000000000000000000000
Binary files a/doc/imdb_loss.png and /dev/null differ
diff --git a/doc/qps-threads-bow.png b/doc/qps-threads-bow.png
deleted file mode 100644
index 8123b71ee154ca86ea8b028fba4bceecac363007..0000000000000000000000000000000000000000
Binary files a/doc/qps-threads-bow.png and /dev/null differ
diff --git a/doc/qps-threads-cnn.png b/doc/qps-threads-cnn.png
deleted file mode 100644
index f983d4882be0a923c0bbfbb41bbca56d684d4035..0000000000000000000000000000000000000000
Binary files a/doc/qps-threads-cnn.png and /dev/null differ
diff --git a/doc/qps-threads-lstm.png b/doc/qps-threads-lstm.png
deleted file mode 100644
index d474b8423f6fc7f49f817181fce48adfa3e15df3..0000000000000000000000000000000000000000
Binary files a/doc/qps-threads-lstm.png and /dev/null differ
diff --git a/doc/qq.jpeg b/doc/qq.jpeg
deleted file mode 100644
index d097e55aa5242bd6b4e968e3df48feed299a5e46..0000000000000000000000000000000000000000
Binary files a/doc/qq.jpeg and /dev/null differ
diff --git a/doc/serving-timings.png b/doc/serving-timings.png
deleted file mode 100644
index 32bab31a57799f7f1d4b80f7e809e284df98d332..0000000000000000000000000000000000000000
Binary files a/doc/serving-timings.png and /dev/null differ
diff --git a/doc/wechat.jpeg b/doc/wechat.jpeg
deleted file mode 100644
index 52dd20702ec17060992f2c2362db203eacc04a3d..0000000000000000000000000000000000000000
Binary files a/doc/wechat.jpeg and /dev/null differ
diff --git a/python/examples/criteo_ctr_with_cube/README.md b/python/examples/criteo_ctr_with_cube/README.md
index de5c3269228a8d7ef619a8c46f2252208e53b982..4492b398add170104a7cd17adff6dc5b83368dbe 100755
--- a/python/examples/criteo_ctr_with_cube/README.md
+++ b/python/examples/criteo_ctr_with_cube/README.md
@@ -65,8 +65,8 @@ bash benchmark.sh
 
 the average latency of threads
 
-![avg cost](../../../doc/criteo-cube-benchmark-avgcost.png)
+![avg cost](../../../doc/images/criteo-cube-benchmark-avgcost.png)
 
 The QPS is 
 
-![qps](../../../doc/criteo-cube-benchmark-qps.png)
+![qps](../../../doc/images/criteo-cube-benchmark-qps.png)
diff --git a/python/examples/criteo_ctr_with_cube/README_CN.md b/python/examples/criteo_ctr_with_cube/README_CN.md
index 15d61160317f866aae25a4d777d76e14725424d3..8c8d51d918410f5fa8a681dacab2000cdc0192bd 100644
--- a/python/examples/criteo_ctr_with_cube/README_CN.md
+++ b/python/examples/criteo_ctr_with_cube/README_CN.md
@@ -63,8 +63,8 @@ bash benchmark.sh
 
 平均每个线程耗时图如下
 
-![avg cost](../../../doc/criteo-cube-benchmark-avgcost.png)
+![avg cost](../../../doc/images/criteo-cube-benchmark-avgcost.png)
 
 每个线程QPS耗时如下
 
-![qps](../../../doc/criteo-cube-benchmark-qps.png)
+![qps](../../../doc/images/criteo-cube-benchmark-qps.png)
diff --git a/python/examples/util/README.md b/python/examples/util/README.md
index 678ca388df5106e57f146a9758e3ef8da485e270..0f6782ab50eaf0bcbc87abb8f654b87aac3a4671 100644
--- a/python/examples/util/README.md
+++ b/python/examples/util/README.md
@@ -28,4 +28,4 @@ Specific operation: Open the chrome browser, enter `chrome://tracing/` in the ad
 
 The data visualization output is shown as follow, it uses [bert as service example](https://github.com/PaddlePaddle/Serving/tree/develop/python/examples/bert) GPU inference service. The server starts 4 GPU prediction, the client starts 4 `processes`, and the timeline of each stage when the batch size is 1. Among them, `bert_pre` represents the data preprocessing stage of the client, and `client_infer` represents the stage where the client completes sending and receiving prediction requests. `process` represents the process number of the client, and the second line of each process shows the timeline of each op of the server.
 
-![timeline](../../../doc/timeline-example.png)
+![timeline](../../../doc/images/timeline-example.png)
diff --git a/python/examples/util/README_CN.md b/python/examples/util/README_CN.md
index aaca0ae21dd1af33a3fb708efd0b2113525e5141..e12b4cc1a5fc69764455483b0a00dc41c31824a1 100644
--- a/python/examples/util/README_CN.md
+++ b/python/examples/util/README_CN.md
@@ -28,4 +28,4 @@ python3 timeline_trace.py profile trace
 
 效果如下图，图中展示了使用[bert示例](https://github.com/PaddlePaddle/Serving/tree/develop/python/examples/bert)的GPU预测服务，server端开启4卡预测，client端启动4进程，batch size为1时的各阶段timeline，其中bert_pre代表client端的数据预处理阶段，client_infer代表client完成预测请求的发送和接收结果的阶段，图中的process代表的是client的进程号，每个进进程的第二行展示的是server各个op的timeline。
 
-![timeline](../../../doc/timeline-example.png)
+![timeline](../../../doc/images/timeline-example.png)
diff --git a/python/paddle_serving_app/README.md b/python/paddle_serving_app/README.md
index 648d830d674d7bc71dc472182a9b017bf063932e..d336e7a2e5159b2dbe282fcaa703c809b9382636 100644
--- a/python/paddle_serving_app/README.md
+++ b/python/paddle_serving_app/README.md
@@ -149,7 +149,7 @@ The server side starts service with 4 GPU cards, the client side starts 4 proces
 In the figure, bert_pre represents the data pre-processing stage of the client, and client_infer represents the stage where the client completes the sending of the prediction request to the receiving result.
 The process in the figure represents the process number of the client, and the second line of each process shows the timeline of each op of the server.
 
-![timeline](../../doc/timeline-example.png)
+![timeline](../../doc/images/timeline-example.png)
 
 ## Debug tools
 
diff --git a/python/paddle_serving_app/README_CN.md b/python/paddle_serving_app/README_CN.md
index fec648d84092902819bd59400a3df71a733021bf..3002ac870de3daf2373fa6985c422feb734c3570 100644
--- a/python/paddle_serving_app/README_CN.md
+++ b/python/paddle_serving_app/README_CN.md
@@ -138,7 +138,7 @@ paddle_serving_app针对CV和NLP领域的模型任务，提供了多种常见的
    效果如下图，图中展示了使用[bert示例](https://github.com/PaddlePaddle/Serving/tree/develop/python/examples/bert)的GPU预测服务，server端开启4卡预测，client端启动4进程，batch size为1时的各阶段timeline。
 其中bert_pre代表client端的数据预处理阶段，client_infer代表client完成预测请求的发送到接收结果的阶段，图中的process代表的是client的进程号，每个进程的第二行展示的是server各个op的timeline。
 
-   ![timeline](../../doc/timeline-example.png)
+   ![timeline](../../doc/images/timeline-example.png)
 
 ## Debug工具