# PyTorch Distributed
Created Thứ tư 12 Tháng 5 2021
<https://pytorch.org/tutorials/beginner/dist_overview.html#data-parallel-training>

## A. Tìm hiểu về Autograd:
* Chiều forward: build 1 đồ thị có hướng ko chu trình với root là output và leaf là input. (computational graph)
* Chiều backward: dựa vào đồ thị để tính gradient
* **đồ thị sẽ được build lại từ đầu sau mỗi iteration**. Điều này làm cho Autograd trở nên linh hoạt.

## B. **Gồm 3 thành phần chính:**

### 1. **DDP (Distributed Data Parallel) (là 1 cơ chế training)**
#### a. **Khi nào dùng DDP?**
* 1 chương trình — fit —> bộ data song song
* Data song song là data chia ra các cục đc; N * X (với N là số điểm dữ liệu, X là 1 điểm dữ liệu)
* chạy được trên cả single-machine và multi-machine
* chạy được trên multi-GPU
#### b. Workflow và Internal design:
* 1 chương trình —nhân bản—> nhiều chương trình giống nhau —> each chương trình xử lý 1 khúc data
* Sử dụng c10d để giao tiếp giữa các process
* Mọi process đều phải được chạy từ cùng 1 trạng thái.
* Các **gradients** được lưu theo các cục **bucket**. 1 bucket gồm 1 hoặc nhiều gradients, tùy vào size của gradients và size của bucket

* Mỗi khi gộp đủ các gradients cho 1 tham số. Tham số đấy nhận gradients là trung bình các gradient con. -> Mọi tham số con đều như nhau sau mỗi lần trừ gradient. -> câu hỏi: vì sao ko phải là tổng mà là trung bình?
* Đảm bảo tính đồng bộ cho các replicas xuyên suốt training

#### c. DDP vs DP:
* DP: single-process, multi-thread. DDP: multi-process và multi-thread -> DDP nhanh hơn, ngay cả khi single-machine

#### d. Question???
* doc bảo là: if span multi-machine -> sử dụng RPC
* DDP cũng multi-machine được mà. Nếu multi-machine + data song song thì DDP vẫn ok mà?

#### e. Torch Elastic
* failure tolerance tool
* Nếu multi-machine chạy DDP ko được đồng đều về phần cứng, hoặc các máy có thể bị mất kết nối -> dẫn đến lỗi.
* VD:
* Máy A có phần cứng ngon hơn máy B. Máy A đang chạy ngon nhưng máy B thì bị quá tải -> lỗi
* Máy A kết nối ổn định, máy B chập chờn. Đang chạy, máy B dỗi, ngắt kết nối -> lỗi
* Torch Elastic quản lý train_step và states:
* Khi states khác với expectation -> train_step bị lỗi -> quay về với states đúng trước đó và thực hiện train_step lại
* Nếu có worker bị lỗi -> thay thế worker mới.

### 2. RPC: (là 1 framework)
#### a. Khi nào dùng RPC:
* Mô hình không chạy song song được
* Data ko song song
* Mô hình pipeline:
* process C chạy khi A chạy xong rồi.
* Mô hình parameter server:
* Cái tham số của mô hình được lưu trên các server. Các server chia sẻ với nhau. Các server sẽ truyền tham số cho các client và 1 client sẽ chỉ truyền tham số cho 1 server.
* DDP + mô hình khác

#### b. Workflow:
* Tùy vào mỗi mô hình mà sẽ có workflow riêng.

#### c. 4 nền tảng cấu thành:
1. **RPC** (Remote Procedure Call):
* Có thể gọi hàm ở một nơi khác
2. **RRef** (Remote Reference):
* Có thể lấy tham số từ một nơi khác
3. **Distributed Autograd: (DA)**
* So với Autograd thông thường, DA có thêm 2 loại node "send" và "recv" và 2 loại node này luôn đi thành 1 cặp và có id.
* VD: send1 - recv1, send2 - recv2
* Các local Autograd vẫn xử lý như bình thường. Tuy nhiên, khi gặp node "send" hoặc "recv" thì sẽ lấy gói thông tin từ "recv" và "send" cùng id tương ứng.
4. **Distributed Optimizer:**
* Mỗi worker có 1 optimizer riêng.
* RPC có 1 optimizer bự để optimize các RRef.

### 3. **Collective Communication (c10d):**
* là thư viện hỗ trợ việc gửi các gói tensor qua lại giữa các process -> nền tảng cho cả DDP và RPC.

# TF Distribute vs PyTorch Distribute theo các use case
## 1. Data-Parallelism
### a. Torch:
* single-machine, multi-machine: DDP(synchronized)
### b. TF:
* single-machine: MirroredStrategy(DDP), CentralStorageStrategy.
* multi-machine: MultiWorkerMirroredStrategy
## 2. Parameter Server:
### a. Torch:
* tự thiết lập bằng RPC
### b. TF:
* ParameterServerStrategy
## 3. Pipeline Model:
### a. Torch:
* tự thiết lập bằng RPC
### b. TF:
* ko có trong tf.distribute
* sử dụng tf.devices để thiết lập nhưng ko đc hỗ trợ mạnh
## 4. Failure Tolerance:
### a. Torch:
* sử dụng Torch Elastic
### b. TF:
* sử dụng checkpoint: (giống các game phiêu lưu)
* cơ chế: lưu checkpoint vào file
* nếu lỗi thì recovery lại từ checkpoint bằng file
## 4. Nhận xét:
* Torch cho phép người dùng có thể tùy biến nhiều hơn với RPC là 1 framework.
* TF đơn giản hơn cho người dùng hơn. Chỉ cần define strategy và sử dụng "with strategy.scope():"
* TF chú trọng tập trung cho Data-Parallelism với nhiều cơ chế hơn.

# Comments
*
*
*