diff --git a/doc/MULTI_SERVICE_ON_ONE_GPU_CN.md b/doc/MULTI_SERVICE_ON_ONE_GPU_CN.md
new file mode 100644
index 0000000000000000000000000000000000000000..fd32fd5b1b063f6aa5e2fcd998d401f6ee19df3d
--- /dev/null
+++ b/doc/MULTI_SERVICE_ON_ONE_GPU_CN.md
@@ -0,0 +1,14 @@
+# 单卡多模型预测服务
+
+当客户端发送的请求数并不频繁的情况下，会造成服务端机器计算资源尤其是GPU资源的浪费，这种情况下，可以在服务端启动多个预测服务来提高资源利用率。Paddle Serving支持在单张显卡上部署多个预测服务，使用时只需要在启动单个服务时通过--gpu_ids参数将服务与显卡进行绑定，这样就可以将多个服务都绑定到同一张卡上。
+
+例如：
+
+```shell
+python -m paddle_serving_server_gpu.serve --model bert_seq20_model --port 9292 --gpu_ids 0
+python -m paddle_serving_server_gpu.serve --model ResNet50_vd_model --port 9393 --gpu_ids 0
+```
+
+在卡0上，同时部署了bert示例和iamgenet示例。
+
+**注意：** 单张显卡内部进行推理计算时仍然为串行计算，这种方式是为了减少server端显卡的空闲时间。 
\ No newline at end of file
diff --git a/doc/PERFORMANCE_OPTIM_CN.md b/doc/PERFORMANCE_OPTIM_CN.md
new file mode 100644
index 0000000000000000000000000000000000000000..e16dba7803c7a8b8ba7d403369f889cdddd8d119
--- /dev/null
+++ b/doc/PERFORMANCE_OPTIM_CN.md
@@ -0,0 +1,13 @@
+# 性能优化
+
+由于模型结构的不同，在执行预测时不同的预测对计算资源的消耗也不相同，对于在线的预测服务来说，对计算资源要求较少的模型，通信的时间成本占比就会较高，称为通信密集型服务，对计算资源要求较多的模型，推理计算的时间成本较高，称为计算密集型服务。对于这两种服务类型，可以根据实际需求采取不同的方式进行优化
+
+对于一个预测服务来说，想要判断属于哪种类型，最简单的方法就是看时间占比，Paddle Serving提供了[Timeline工具](../python/examples/util/README_CN.md)，可以直观的展现预测服务中各阶段的耗时。
+
+对于通信密集型的预测服务，可以将请求进行聚合，在对延时可以容忍的限度内，将多个预测请求合并成一个batch进行预测。
+
+对于计算密集型的预测服务，可以使用GPU预测服务代替CPU预测服务，或者增加GPU预测服务的显卡数量。
+
+在相同条件下，Paddle Serving提供的HTTP预测服务的通信时间是大于RPC预测服务的。
+
+对于模型较大，预测服务内存或显存占用较多的情况，可以通过将--mem_optim选项设置为True来开启内存/显存优化。