Merge pull request #36 from BillyChen1/cqm_versioning

versioning documentation

Author: RongGu

docs/case-study/alibaba-case-study.md

@@ -54,7 +54,7 @@ To improve efficiency of large-scale machine learning model training for Alibaba
 #### Fluid
 [Fluid](https://github.com/fluid-cloudnative/fluid) is an open source scalable distributed data orchestration and acceleration system. It enables data access for data-intensive applications such as AI and big data based on the Kubernetes standard without user awareness. It is intended to build an efficient support platform for data-intensive applications in cloud-native environments. Based on data layer abstraction provided by Kubernetes services, Fluid can flexibly and efficiently move, replicate, evict, transform, and manage data between storage sources such as HDFS, OSS, and Ceph and upper-layer cloud-native computing applications of Kubernetes. Specific data operations are performed without user awareness. You do not need to worry about the efficiency of accessing remote data, the convenience of managing data sources, or how to help Kubernetes make O&M and scheduling decisions. You can directly access abstracted data from Kubernetes-native persistent volumes (PVs) and persistent volume claims (PVCs). Remaining tasks and underlying details are all handled by Fluid.
 
-![Fluid](../../static/img/docs/case-study/ali-fluid.png)
+![Fluid](/img/docs/case-study/ali-fluid.png)
 
 Fluid supports multiple runtimes, including JindoRuntime, AlluxioRuntime, JuiceFSRuntime, and GooseFSRuntime. JindoRuntime has outstanding capabilities, performance, and stability, and is applied in many scenarios. [JindoRuntime](https://github.com/aliyun/alibabacloud-jindodata/blob/master/docs/user/6.x/6.2.0/jindo_fluid/jindo_fluid_overview.md) is a distributed cache runtime of Fluid. It is built on JindoCache, a distributed cache acceleration engine.
 
@@ -73,13 +73,13 @@ JindoCache is applicable to the following scenarios:
 
 - AI and training acceleration, to reduce the costs of using AI clusters and provide more comprehensive capability support.
 
-![JindoCache](../../static/img/docs/case-study/ali-jindo.png)
+![JindoCache](/img/docs/case-study/ali-jindo.png)
 
 #### KubeDL
 KubeDL is a Kubernetes (ASI)-based AI workload orchestration system for managing the lifecycle of distributed AI workloads, interaction with layer-1 scheduling, failure tolerance and recovery, as well as dataset and runtime acceleration. It supports the stable operation of more than 10,000 AI training tasks on different platforms in the unified resource pool of Alibaba Group every day, including but not limited to tasks related to Taobao, Alimama, and DAMO Academy business domains. You can download the [open source edition of KubeDL](https://github.com/kubedl-io/kubedl) from GitHub.
 
 #### Overall Project Architecture
-![architecture](../../static/img/docs/case-study/ali-architecture.png)
+![architecture](/img/docs/case-study/ali-architecture.png)
 
 ### 3.2 Benefits of JindoCache-based Fluid
 1. Fluid can orchestrate datasets in Kubernetes clusters to co-deploy data and computing, and provide PVC-based APIs for seamlessly integrating Kubernetes applications. JindoRuntime can accelerate data access and caching in OSS. POSIX-based APIs of FUSE allow you to easily access large numbers of files in OSS the way you access local disks. Deep learning training tools such as PyTorch can read training data through POSIX-based APIs.
@@ -136,27 +136,27 @@ Cluster and model: high-performance A800 server cluster equipped with remote dir
 
 **Monitoring Data: Direct Connection without Caching**
 
-![w/o-cache-1](../../static/img/docs/case-study/ali-wo-cache-1.png)
+![w/o-cache-1](/img/docs/case-study/ali-wo-cache-1.png)
 
-![w/o-cache-2](../../static/img/docs/case-study/ali-wo-cache-2.png)
+![w/o-cache-2](/img/docs/case-study/ali-wo-cache-2.png)
 
-![w/o-cache-3](../../static/img/docs/case-study/ali-wo-cache-3.png)
+![w/o-cache-3](/img/docs/case-study/ali-wo-cache-3.png)
 
 **Monitoring Data: Caching Enabled**
 
-![with-cache-1](../../static/img/docs/case-study/ali-with-cache-1.png)
+![with-cache-1](/img/docs/case-study/ali-with-cache-1.png)
 
 The overall average GPU utilization is also close to 100%, and the loads of GPUs are uniform and are all close to 100%.
 
-![with-cache-2](../../static/img/docs/case-study/ali-with-cache-2.png)
+![with-cache-2](/img/docs/case-study/ali-with-cache-2.png)
 
 #### Checkpoint Acceleration
 **Training and Offline Inference Scenarios**
 A distributed training task loads a checkpoint model file to continue training each time it is restarted. The model size ranges from tens of GB to hundreds of MB. In addition, a large number of offline inference tasks occupy many spot instance resources in the unified resource pool. Resources of an inference task can be preempted at any time, and the task will reload the model for offline inference after a failover. Therefore, a large number of jobs load the same checkpoint file after restart.
 
 Distributed cache acceleration of Fluid converts multiple remote read operations into a single local read operation. This greatly accelerates job failovers and prevents bandwidth costs caused by multiple repeated read operations. In a typical large model scenario, the size of the model file is approximately 20 GB based on the 7B parameter size with FP16 precision. Fluid reduces the model loading time from 10 minutes to approximately 30 seconds.
 
-![Inference](../../static/img/docs/case-study/ali-inference.png)
+![Inference](/img/docs/case-study/ali-inference.png)
 
 **Spot Scenarios of Training (write-through)**
 In spot scenarios of distributed training, if resources of a synchronous training task are preempted, it is usually restarted globally through a failover to continue training. KubeDL cooperates with layer-1 scheduling to instruct, through interactive preemption, the rank 0 node of the training task to record an on-demand checkpoint to save the latest training progress. After the restart, the task can reload the latest checkpoint to continue training as soon as possible. This leverages low costs of spot instance resources and minimizes the costs of training interruption.

docs/case-study/haomo-case-study.md

@@ -21,13 +21,13 @@ Data intelligence can also help these vertical products and consolidate their le
 
 The rapid development of HAOMO.AI also reflects that higher-level intelligent driving will play a role in a wider range of scenarios, and autonomous driving is moving into the fast lane of commercial application.
 
-![](../../static/img/docs/case-study/haomo-arch.jpeg)
+![](/img/docs/case-study/haomo-arch.jpeg)
 
 ## 2. Training Effectiveness of Traditional Machine Learning Encounters a Bottleneck
 
 The machine learning platform has played a very central role in the widespread application of machine learning in autonomous driving scenarios. The platform adopts the architecture with separation of storage and computing, which decouples computing resources from storage resources. As such, it provides flexible resource allocation, realizes convenient storage expansion, and reduces storage and O&M costs.
 
-![](../../static/img/docs/case-study/haomo-ml-arch.png)
+![](/img/docs/case-study/haomo-ml-arch.png)
 
 
 However, this architecture also brings some challenges, among which the most critical ones lie in data access performance and stability:
@@ -63,7 +63,7 @@ It is necessary to improve the data localization on data access during model tra
 
 We are eager to find a system platform with distributed cache acceleration capabilities on Kubernetes to achieve these goals. Fortunately, we found Fluid, a CNCF Sandbox project that can meet our demands. Therefore, we have designed a new architecture scheme based on Fluid. After verification and comparison, we chose JindoRuntime as the acceleration run time.
 
-![](../../static/img/docs/case-study/haomo-with-fluid-arch.png)
+![](/img/docs/case-study/haomo-with-fluid-arch.png)
 
 ### 3.1 Technical Solution
 
@@ -108,15 +108,15 @@ We use different models to infer and train the same data. We conduct inference a
 
 - *The test result of the model inferring 10,000 frames of images on the cloud*
 
-![](../../static/img/docs/case-study/haomo-test-result-1.png)
+![](/img/docs/case-study/haomo-test-result-1.png)
 
 - *The test result of another larger model inferring 10,000 frames of images on the cloud*
 
-![](../../static/img/docs/case-study/haomo-test-result-2.png)
+![](/img/docs/case-study/haomo-test-result-2.png)
 
 - *Time consumption of a model with 4 GPUs to train 10,000 frames of images on the cloud*
 
-![](../../static/img/docs/case-study/haomo-test-result-3.png)
+![](/img/docs/case-study/haomo-test-result-3.png)
 
 The efficiency of cloud training and inference improves significantly with Fluid + JindoRuntime, especially for some small models. JindoRuntime can solve the I/O bottleneck problem, and the training can be accelerated by up to about 300%. It also improves the efficiency of GPU usage on the cloud and accelerates the efficiency of data-driven iterations on the cloud.