[APE-X] Distributed Prioritized Experience Replay

Paper Link: https://arxiv.org/pdf/1803.00933.pdf

1. Abstract

• 본 논문은 강화학습을 위한 분산 구조를 제안
  • Actors: 각자의 환경과 상호작용을 하며 shared neural network를 통해 행동을 결정, shared experience replay에 경험을 누적
  • Learner: 경험들을 샘플링하여 neural network를 학습
• Prioritized experience replay를 사용하여 actor에 의해 생성된 데이터 중 중요한 데이터에 집중
• Arcade Learning Environment에서 성능을 검증하였으며 적은 시간의 학습만으로도 좋은 성능을 얻음

2. Introduction

• 딥러닝의 경우 더 큰 데이터셋과 더 강력한 모델을 사용하여 더 많은 연산을 수행하여 좋은 성능을 얻는 것이 최근의 트렌드
• 심층강화학습에도 같은 원리를 적용할 수 있을 것이라 생각할 수 있음
  • 효율적으로 많은 연산 자원을 사용하는 것이 성능 향상에 주요한 원인이 될 수 있음!!
  • Gorila, A3C, GPU Advantage Actor Critic, Distributed PPO, AlphaGO 등등을 통해 예시를 찾아볼 수 있음
• Tensorflow와 같은 딥러닝 프레임워크는 분산 학습을 지원하여 큰 규모의 머신러닝 시스템을 쉽게 구현하고 사용할 수 있게 만들어줌 → 이에 따라 최근의 심층강화학습 연구들에서 한대의 머신의 계산량으로도 성능 향상을 시킬 수 있는 방법이 고려됨
• 본 논문에서는 DRL의 성능을 향상시키기 위해 더 많은 데이터를 생성하고 prioritized 방식으로 이를 선택하는 기법을 제안
  • 기존의 접근들은 neural network에 분산 학습을 수행할 때 gradient의 계산을 분산화 하는 것에 집중하여 파라미터들을 빠르게 최적화 수행
  • 대조적으로 본 논문에서는 experience 데이터를 생성하고 선택하는 것을 분산화하였고 이것만으로도 성능의 향상을 확인함
• 분산 구조를 다양한 Deep Q-Network (DQN) 기반의 알고리즘과 Deep Deterministic Policy Gradient (DDPG) 알고리즘에 적용
• Arcade Learning Environment에서 성능 검증 → Atari 게임들에서 state of the art 성능을 보이면서도 기존 기법들에 비해 더 적은 시간 동안 학습을 수행하였고 게임마다 하이퍼 파라미터 튜닝도 하지 않음
• 제안하는 기법의 확장성을 검증하기 위해 다음의 분석들을 수행
  • 데이터를 생성하는 worker들이 늘어남에 따라 Prioritization이 성능에 미치는 영향
  • Replay 용량이 성능에 미치는 영향
  • 최근의 경험이 성능에 미치는 영향 (recency)
  • 각 worker가 다른 데이터 생성 policy를 사용할 때 성능에 미치는 영향

3. Background

Distributed Stochastic Gradient Descent

• Distribued stochastic gradient descent는 supervised learning에서 deep neural network의 학습 속도 향상을 위해 자주 사용됨 → 파라미터의 업데이트를 위한 gradient의 연산을 병렬화
• 이것에 영감을 받아 Gorila 논문에서는 분산 비동기화 파라미터 업데이트와 분산 데이터 생성을 적용
• A3C에서는 분산 방식이 아닌 multi-thread 방식을 통해 비동기화 파라미터 업데이트와 분산 데이터 생성을 단일 머신에서 사용하여 성능 향상
• GPU Asynchronous Actor-Critic (GA3C), Parallel Advantage Actor-Critic (PAAC)는 해당 방식에 GPU를 효율적으로 적용

Distributed Importance Sampling

• Importance sampling을 사용한 variance reduction을 기반으로 학습의 속도를 향상시키는 기법 (Hastings, 1970)
• Neural network에서도 해당 기법이 좋은 성능을 보임 (Hinton, 2007)
• 데이터를 non-uniform하게 샘플링하고 sampling probability에 따라 업데이트를 weighting하는 것은 bias의 영향을 없애기 때문에 수렴 속도를 향상시키고 gradient의 variance를 감소시킴
• 해당 기법은 분산 환경에서도 성공적으로 적용 (Alain et al., 2015)
• Distributed Importance Sampling의 2가지 방법
  • 해당 gradient의 L2 norm에 비례하여 sampling probability를 설정
  • 가장 최근의 loss값을 통해 rank를 결정하고 이에 따라 sampling probability를 결정

Prioritized Experience Replay

• Experience replay는 강화학습에서 data efficiency를 향상시키기 위해 오래전부터 사용되어옴 (Lin, 1992)
• 특히 stochastic gradient descent 알고리즘을 사용한 neural network function approximator를 학습할 때 주요하게 사용 → Neural Fitted Q-Iteration (Riedmiller, 2005), Deep Q-Learning (Minh et al., 2015)
• 또한 experience replay는 데이터가 예전 버전의 policy를 통해 생성한 데이터를 이용하여 학습하므로 오버피팅을 방지
• Prioritized Experience Replay (PER)은 고전적인 prioritized sweeping 아이디어 (Moore & Atkeson, 1993)를 확장하고 deep neural network function approximator에 적용
• 이 기법은 이전에 설명한 importance sampling과 밀접한 연관이 있지만 더 일반적인 biased sampling 방법을 사용 → 가장 '놀라운' 경험에 집중하여 학습을 수행
• Biased sampling은 특히 강화학습에 도움이 될 수 있음 → reward가 sparse할 수 있고 data의 분포가 에이전트의 policy에 의존하므로
• PER은 다양한 에이전트들에 적용됨
  • Prioritized Dueling DQN (Wang et al., 2016)
  • UNREAL (Jaderberg et al., 2017)
  • DQfD (Hester et al., 2017)
  • Rainbow (Hessel et al., 2017)

4. Our contribution: Distributed Prioritized Experience Replay

• 본 논문은 PER을 분산 세팅으로 확장하였고 이것이 심층강화학습 접근에 대한 확장성이 좋다는 것을 보여줌
• 알고리즘에 대한 적은 변경만으로 이런 확장이 가능함을 보여줌
• 이 기법의 이름을 Ape-X라 정의함
• Gorila에서는 기존 심층강화학습 알고리즘을 2 부분으로 나누고 high-level synchronization 없이 동시에 실행
  • 첫번째 파트는 에이전트에 환경 내에서 경험을 수행하고 deep neural network로 구현된 policy를 평가하고 replay memory에 데이터를 저장 → 이 부분을 acting이라 정의
  • 두번째 파트는 메모리에서 배치를 샘플링하고 policy 파라미터를 업데이트 → 이 부분을 learning이라 정의
• 이론적으로 acting과 learning은 다수의 worker들을 통해 분산화 할 수 있음
• 본 논문에서는 아래 그림과 같이 수백개의 actor가 CPU를 통해 실행되며 데이터를 생성하며 단일 learner가 가장 유용한 경험들을 sampling하여 GPU를 통해 학습

• actor와 learner의 pseudocode는 다음과 같음

• Golira 논문과는 다르게 본 논문에서는 shared, centralized replay memory를 사용하며 uniform하게 sampling하지 않고 유용한 데이터들을 더 자주 sampling하도록 prioritized 적용
• PER에서 새로운 transition에 대한 priorities는 지금까지 봐온 데이터 중에 최대의 priority로 초기화 되고(priorities for new transitions were initialized to the maximum priority seen so far) 오직 샘플링될때 한번 업데이트 됨 → This does not scale well → 왜냐하면 해당 논문의 구조에서는 많은 수의 actor들이 존재하기 때문에 learner가 priorities를 업데이트하기 기다리는 것은 최신에 데이터에 대해 근시안적인 결과를 유발할 수 있음
• 대신에 Ape-X에서는 많은 수의 actor로 계산을 하므로 이미 policy의 local copies가 각각 priority를 평가 → 새로운 transition에 대해 온라인으로 적절한 priorities를 계산할 수 있음 → Replay가 더욱 정확한 priorities를 가지며 추가적인 cost가 없음
• Sharing experience는 sharing gradient에 비해 몇몇 장점을 가짐
  • Low latency communication이 distributed SGD 만큼 중요하지 않음 → 왜냐하면 experience data는 gradient에 비해 덜 outdated → off-policy data에 대해서 learning 알고리즘이 robust
  • Centralized replay를 사용하여 모든 통신을 수행하므로 효율적
  • 해당 기법을 사용하면 성능을 제한하지 않고 actors와 learner이 서로 다른 data center에서 실행될 수 있음
• 마지막으로 off-policy에서 학습은 많은 분산 actor들을 사용하는 Ape-X를 사용하는 것이 장점이 있음 → 각 actor가 다른 exploration policy를 사용하면 만날 수 있는 경험의 종류가 더 다양해짐 → 어려운 exploration 문제를 풀 때 도움이 될 수 있음

4.1 Ape-X DQN

• • 다양한 DQN 기반 알고리즘 결합 → Double Q-Learning, Multi-step bootstrap targets, Dueling network architecture
  • Loss는 다음과 같이 계산
    • $l_{t}(\theta)=\frac{1}{2}(G_{t}-q(S_{t}, A_{t}, \theta))^{2}$

• 이론적으로 Q-learning 기반의 기법들은 off-policy 기법이므로 데이터 생성을 위한 policy를 선택하는 것이 자유로움
• 하지만 behavior policy의 결정은 exploration과 function approximator의 quality를 결정하므로 중요함!
• Ape-X에서는 각 actor가 다른 policy를 가지도록 함 → 다양한 전략을 통해 experience를 생성
  • 각 actor가 epsilon greedy policy에서 epsilon 값을 다르게 설정

 

4.2 Ape-X DPG

• DDPG를 기반으로 한 continuous-action policy gradient system에 Ape-X 결합
• Ape-X DPG의 셋업은 Ape-X DQN과 유사하지만 actor의 policy가 이제 분리된 policy network에 의해 결정 → Actor & Critic 구조 (Policy network & Q-network)
• 두개의 네트워크들은 각자 sample된 경험을 기반으로 다른 loss를 계산하여 최적화를 수행
• Q-network의 출력은 action-value estimate $q(s,a,\psi)$로 multi-step bootstrap target을 이용하여 temporal difference learning 사용
• Q-network의 loss는 다음과 같음
  • $l_t (\psi)\frac{1}{2}(G_t -q(S_t , A_t, \psi))^2$

• Policy network의 출력은 action $A_t =\pi (S_t , \phi)$
• Policy network의 파라미터는 추정된 Q-value에 대해 policy gradient ascent를 사용
  • gradient: $\bigtriangledown _\phi q(S_t , \pi(S_t , \phi), \psi)$

5. Experiments

5.1 Atari

• Ape-X DQN을 Atari에서 성능 검증

• 360개의 actor사용 → 1 actor 1 CPU core
• Replay memory에 데이터를 제공하는 속도 → 각 actor 당 139 FPS → 약 50K FPS이며 fixed action을 4번씩 반복하므로 12.5K transition 데이터 제공
• actor들은 experience data를 replay에 보내기 전에 local하게 보관 → batches (B) = 50일때 비동기적으로 전송
• Learner는 512 transition의 16 batches를 뽑고 각 초마다 19 batch에 대한 연산 수행 → 즉 평균적으로 매 초마다 9.7K의 transition에 대한 gradient 계산
• 메모리와 bandwidth requirement 감소를 위해 observation data는 replay로 보내고 저장할 때 PNG 코덱으로 압축
• learner가 이 데이터를 뽑을 때 decompress하여 사용
• Actors는 learner의 네트워크 파라미터는 매 400 프레임마다 복사 (~2.8초)
• 각 actor ($i \in\{0, ..., N-1\}$)은 epsilon greedy policy를 다음의 epsilon 값으로 수행
  • $\epsilon_i = \epsilon^{1+\frac{i}{N-1}\alpha}$ ($\epsilon=0.4, \alpha=7$)
  • 각 epsilon값들은 학습 중에 값을 상수로 고정
• 학습동안 episode의 길이는 50000 frame으로 제한
• Shared experience replay memory의 용량은 2백만 transition으로 설정 → 새로운 데이터는 항상 추가되며 100 learning step 마다 용량을 초과하는 데이터는 제거 (FIFO)
  • 이에 따라 실제 메모리 사이즈는 2035050
• Data는 proportional prioritization으로 샘플링 됨 → priority exponent = 0.6, importance sampling exponent = 0.4
• Figure 2의 왼쪽을 보면 모든 57개의 게임에서 median human normalized score를 비교 (DQN, PER, Distributional DQN, Rainbow, Gorila)
• Figure 2의 오른쪽은 6개의 게임에 대한 learning curve (나머지 게임들의 결과는 appendix에)
• Ape-X의 경우 다른 baseline들에 비해 더 많은 연산 → 더 빠른 학습 수행
• 다른 기법들에 비해 더 높은 성능을 보임

5.2 Continuous Control

• Ape-X DPG를 4개의 continuous control task에 적용
  • Manipulator: 에이전트가 공을 특정 위치로 옮겨야 함
  • Humanoid: 에이전트가 humanoid body를 제어하여 특정 task를 수행 (Standing, Walking, Running)
• Pixel 대신 feature를 이용하여 학습하므로 observation space가 Atari domain에 비해 훨씬 작음
  • 더 작은 fully connected network 사용 (구조는 appendix에)
  • 64 actors 사용
• 총 14K FPS 데이터 취득, 22K transition을 매 초마다 학습 (86 batches of 256 transitions)

• Figure 3를 보면 Ape-X DPG가 4개의 모든 task에서 매우 좋은 성능을 보임
• Figure 3는 Ape-X DPG의 성능을 다른 수의 actor들을 사용하여 비교함
  • actor의 수가 늘어나면 에이전트는 더 효율적이고, 빠르고, 안정적으로 문제를 풀어냄
• 10배 정도 학습한 DDPG의 성능을 능가

6. Analysis

• 이번 장에서는 Ape-X DQN에 추가적인 실험을 수행한 것을 설명

• 첫번째로 actor의 수를 다양하게 하면서 성능 비교
  • 에이전트를 다른 수의 actor를 사용하여 학습 → 8, 16, 32, 64, 128, 256
  • 35시간 동안 6개의 Atari 게임에 대한 학습 수행
  • Shared experience replay의 크기는 백만개의 transition으로 고정
  • Figure 4를 보면 actor의 수가 늘어남에 따라 성능도 함께 늘어나는 것을 확인할 수 있음
  • Appendix에 추가적인 게임들에 대한 성능을 비교 (prioritized 추가, 제거 버전도)
  • 놀라운 점은 네트워크 파라미터가 업데이트 되는 빈도, 네트워크의 구조, 업데이트 방식 등등 아무것도 변경하지 않고 actor의 수만 늘려서 성능이 좋아졌다는 것!
    • 이유는? → 일반적인 심층강화학습의 경우 parameter space에서 policy가 local optimum을 찾아내서 학습이 제대로 안되는 경우가 있음 (e.g. 부족한 탐험)
    • 하지만 많은 수의 actor를 사용하면 exploration을 다양하게 수행하면서 새로운 action의 course를 발견할 수 있음
    • 또한 prioritized replay는 학습 알고리즘이 중요한 정보에 집중할 수 있도록 도와줌

• 다음으로 replay memory의 용량을 다양하게 변경
  • 256개의 actor 사용 (37K total environment frames per second)
  • 많은 수의 actor를 사용하면 DQN과 같은 에이전트에서 memory가 훨씬 빠르게 새로운 데이터로 대체됨
  • Replay의 용량이 커질 수록 약간의 성능 향상이 있는 것을 확인할 수 있음
    • 이것의 이유는 높은 priority를 가지는 경험들을 더 오래 보관하고 불러오면서 학습을 수행할 수 있다는 것을 생각할 수 있음
• 마지막으로 두개의 요소에 대한 효과를 살펴보는 추가적인 실험을 수행
  • Recency of the experience data in the replay memory
  • Diversity of the data-generating policies
• 자세한 설명은 appendix에서 살펴볼게요

7. Conclusion

• 심층강화학습을 위한 prioritized replay를 분산 framework로 디자인하고 구현하고 분석
• 해당 구조는 discrete와 continuous task에서 state of the art 성능 보임 → 학습 시간도 빨랐고 최종 성능도 좋았음
• Ape-X framework를 DQN과 DPG에 적용 → 다른 어떤 off-policy reinforcement learning update에도 적용할 수 있음
• 많은 심층강화학습 알고리즘들이 큰 도메인에서 효과적으로 탐험을 수행하는데 제한이 있음
  • Ape-X 구조는 단순하지만 효과적이고 해당 문제를 해결할 수 있는 메카니즘을 가짐
  • 다양한 경험을 생성해내고 가장 유용한 데이터를 통해 학습을 수행
• 본 구조는 분산 시스템이 연구나 대규모 application에 심층강화학습을 적용할 수 있음을 보여줌

Appendix

A. Recency of Experience

• Actor의 수가 늘어나도 replay memory의 크기를 고정하면 replay memory 내부의 데이터가 대체되는 속도가 달라짐
• 많은 actor들을 사용할수록 replay memory는 더욱 최신의 transition들이 많아지게 됨 → learner에 의해서 더 최적화 된 파라미터로 action을 결정한 데이터들
• 그럼 만약 빠르게 replay memory 내부의 데이터를 대체하는 것이 성능 향상의 원인이라면 많은 수의 actor를 쓸 필요가 없는 것 아닌가요?
  • 그래서 replay memory 내부의 컨텐츠가 대체되는 속도를 유지하기 위해 256개의 actor를 사용한 것과 32 actor를 사용하는데 각 transition을 8배로 늘려서 256개의 actor와 동일한 수의 데이터를 만들어낸 것의 결과를 비교
  • 후자의 경우 데이터가 256개의 actor를 사용했을 때 만큼 다양하지는 않지만 데이터를 대체하는 속도를 동일함
  • Figure 6의 결과를 보면 단순히 경험의 recency가 성능에 영향을 미친다고 말할수 없고 동일한 데이터를 몇배로 늘려서 넣는 것은 때로 성능을 저하시키는 것을 확인할 수 있음

B. Varying the Data-Generating Policies

• 각 actor가 다른 epsilon 값을 가지게 하는 것이 본 알고리즘의 scalability 향상에 기여함
• 이것을 다양하게 하는 것이 결과에 어떤 영향을 미치는지 보겠습니다.
  • 첫번째로는 고정적으로 6개의 epsilon 값만 사용한 경우
  • 두번째로는 본 논문의 기법처럼 모든 범위의 epsilon을 사용한 경우
• 모든 범위의 epsilon을 사용한 경우가 약간 더 좋은 성능을 보임 → 분산 프레임워크에서 좋은 성능을 보이는데 결정적인 요소는 아님

C. Atari: Additional Details

• DQN과 동일: Grayscale, frame stacking, repeating actions 4 times, reward clipping [-1, 1]
• Learner는 50000 transition을 기다려서 학습 전에 replay에 데이터를 쌓음
• RMSProp optimizer를 사용 (learning rate: 0.00025/4, decay = 0.95)
• Multi-step (n=3) loss 감소에 momentum 사용하지 않음
• Gradient norms는 40으로 clipping
• target network는 매 2500 학습 batch 마다 업데이트
• Dueling DDQN 에이전트와 같은 네트워크 사용

D. Continuous Control: Additional Details

• Critic network: 400 units → tanh activation → 300 units
• Actor network: 300 units → tanh activation → 200 units
• Actor network의 gradient는 [-1, 1]로 clipping
• Adam optimizer 사용 (learning rate = 0.0001)
• target network는 매 100 training batch 마다 복사
• Replay sampling priorities는 Critic에서 제공하는 TD error의 절대값으로 사용
• Learner는 proportional prioritized sampling 사용
  • priority exponent $\alpha_{sample}=0.6$
  • Replay capacity: 10^6
  • Proportional prioritized sampling을 위한 transition은 주기적으로 제거
    • priority exponent $\alpha_{evict}=-0.4$
• 기존의 DPG 알고리즘이 noise를 Ornstein-Uhlenbech process를 통해 sampling 한 것과 다르게 본 논문에서는 exploration을 위한 noise를 normal distribution ($\sigma=0.3$)에서 sampling
• Evaluation은 noise가 없는 deterministic policy 사용
• Benchmarking을 위해서 두개의 continuous control domain 사용
  • a: Humanoid, b: Manipulator
  • Humanoid walker
    • Action, state, observation dimensionalities: $|A|=21, |S|=55, |O|=67$
    • Walk: 최소 속도를 넘으면 reward 받음
    • Run: 이동 속도에 비례하여 reward 받음
    • Stand: 서있는 높이에 비례하여 reward 받음
  • Manipulator
    • Action, state, observation dimensionalities: $|A|=2, |S|=22, |O|=37$
    • 랜덤하게 초기화되는 움직이는 공을 잡으면 보상을 받음

E. Tuning

• Atari에서 learning rate와 batch size를 몇가지로 제한하여 tuning
  • 일반적으로 큰 batch size가 성능 향상에 주요한 요인이었음
  • batch size = {32, 128, 256, 512, 1024} → 512에서 좋은 성능을 보임
  • learning rate를 0.00025로 증가시키고 큰 batch size에서 학습해보았으나 몇몇 게임에서 성능이 불안정했음
  • 낮은 learning rate인 0.00025/8을 사용했을 때도 성능이 향상되지는 않음
• Continuous control
  • batch size = {32, 128, 256, 512, 1024}
  • learning rate = $10^{-3}$ ~ $10^{-5}$
  • prioritization exponents $\alpha$ = 0 ~ 1
• 많은 actor를 사용한 실험에서 actor의 네트워크 파라미터를 업데이트 하는 주기를 충분히 높게 설정하여 learner가 overloaded 되지 않도록 함
• 많은 transition이 각 actor에 local하게 누적되도록 설정하여 replay server가 network traffic에 overload되지 않도록 함
• 이런 파라미터들을 튜닝하지는 않았고 이런 요소들이 학습에 큰 영향을 미치는지 관측하지 않음

F. Implementation

• 다음의 요소들은 유사한 시스템을 구현할 때 관심있을 만한 실용적인 detail 들에 대해서 설명한 내용

Data Storage

• 알고리즘은 Tensorflow를 이용하여 구현
• Replay data는 custom Tensorflow ops로 구현된 distributed in-memory key-value store에 저장
• 이 ops는 Tensor data의 batch들을 더하고 읽고 제거하는데 효율적으로 사용 가능

Sampling Data

• Key에 대한 prioritized distribution으로부터 효율적으로 maintaining과 sampling을 할 수 있는 ops를 구현
• Sampling transition의 probability: $p_{k}^{\alpha}/\sum_{k}p_{k}^{\alpha}$
  • $p_{k}$: key k에 대한 transition의 priority
  • exponent $\alpha$ 는 prioritization을 조절 → 0은 uniform sampling
  • priority $p_k = |\delta_k|$, $\delta_k$ → TD error for transition k

Adding Data

• n-step transition data를 효율적으로 구축하기 위해 각 actor는 capacity n의 tuple을 circular buffer로 유지함

 

• B는 buffer의 현재 사이즈
• 만약 buffer가 capacity n에 도달하면 최신의 state $S_{t+n}$과 value estimates $q(S_{t+n})$을 결합하여 유효한 n-step transition을 만들어냄
• Remote replay memory에 데이터를 저장하기 위해 transition을 처음에는 local TensorFlow queue에 저장하여 replay server의 request를 줄여줌
• queue는 주기적으로 비워지고 이때 queued transition에 대한 absolute n-step TD-errors를 계산
• 각 transition에는 unique key를 부여 → 어떤 actor와 environment step을 통해 기록된 것인지 표시
• 각 transition의 시작과 끝 state를 모두 저장하기 때문에 몇 데이터는 두번 저장될 수 있음 → 더 많은 RAM이 필요하지만 코드가 더 간단해짐

Practical Consideration

Contention

• Replay server가 시간적인 측면으로 모든 request를 처리하는 것이 중요함 → 모든 시스템의 속도가 저하되는 것을 피하기 위해
• 가능한 bottleneck은 CPU, network bandwidth와 shared data의 보호를 위한 lock이 있음
• 본 실험에서는 CPU가 주요한 bottleneck이었음 → 이를 해결하기 위해 모든 request와 response는 충분히 큰 batch를 사용

Asynchronicity

• 본 논문에서는 acting과 learning이 동기화되지 않음
• 알고리즘의 성능은 이 두개에 모두 의존 → 이들 중 하나만 참조하여 성능을 고려하는 것은 좋지 못함
• 예를 들어 특정 environment frame의 수가 지난 뒤의 결과는 learner가 그동안 수행해온 update의 수에 매우 의존함
• 이에 따라 모든 파트의 스피드를 살펴보고 결과를 분석할 때 이를 고려하는 것이 좋음

Failure

• 많은 worker를 사용하는 분산 시스템에서 때로는 하드웨어 이슈로, 때로는 shared resource의 문제로 failure나 interruption이 발생할 수 있음
• 이에 따라 모든 시스템의 부분들은 주기적으로 저장되어야 하고 재시작 되었을 때 이어서 학습을 할 수 있게 설정해야 함
• 본 논문의 시스템에서 actor들은 언제든 중단될 수 있고 지속적으로 학습하는 것을 방해받을 수 있음 → replay memory에 새로운 데이터가 들어오는 속도를 감소시킬 수 있음
• 만약 replay server가 중단되면 모든 데이터가 버려지고 actor들을 통해 메모리를 빠르게 다시 채워야함 → 이때 오버피팅을 방지하려면 learner의 학습을 잠시 중단하고 적절한 양의 데이터가 누적될 때까지 기다려야함 → 그리고 learner의 학습을 재개해야함