퀴즈: 체크포인트·재개·시간여행
compile(checkpointer=MemorySaver()) 한 그래프를 같은 thread_id 로 두 번 돌렸다. 두 번째 실행이 보는 것은?
- 매번 빈 상태에서 시작한다. thread_id 는 기록용 이름일 뿐이다
- 첫 실행의 입력만 남고 노드가 쓴 값은 남지 않는다
- 첫 실행이 남긴 상태 위에서 이어 돈다. 리듀서가 붙은 열쇠는 쌓인다
- 첫 실행이 끝났으므로 오류를 내며 새 thread_id 를 요구한다
과거 체크포인트에서 이어 돌리려고 한다. invoke 의 첫 인자로 무엇을 주어야 하는가?
None— 저장된 그 시점의 상태로 이어서 돌라는 뜻이다- 그 시점의 상태 딕셔너리를 그대로 다시 준다
- 바꾸고 싶은 열쇠만 담은 딕셔너리를 준다
- 빈 딕셔너리를 준다. 그래야 덮어쓰지 않는다
update_state(snapshot.config, {...}) 가 돌려주는 것은?
- 값만 바뀐 상태 딕셔너리. config 는 그대로다
- 아무것도 돌려주지 않는다. 그 자리를 덮어쓴다
- 그 시점 이후의 체크포인트를 지운 개수를 돌려준다
- 새
checkpoint_id가 든 config 하나
한 번 돌린 뒤 중간 지점에서 갈래를 쳤다. 이제 thread_id 만 담은 config 로 get_state 를 부르면?
- 원래 갈래의 끝이 나온다. 분기는 따로 보관된다
- 새 갈래의 끝이 나온다. 스레드의 '지금' 이 그리로 옮겨 갔다
- 두 갈래의 끝이 목록으로 함께 나온다
- 갈래가 둘이라 어느 쪽인지 정할 수 없어 오류가 난다
상태에 큰 값 하나를 담았더니 체크포인트 저장량이 크게 늘었다. 무엇이 일어난 것인가?
- 그 값이 압축되지 않아 원래보다 커진 채로 저장되었다
- 리듀서가 없는 열쇠라 값이 매번 복사되어 쌓였다
- 체크포인트마다 상태 전체가 저장되므로 그 값이 여러 번 거듭 저장되었다
- 직렬화가 실패해 예비 형식으로 다시 저장되었다
체크포인트의 비용을 시간이 아니라 바이트로 재라고 하는 이유로 가장 알맞은 것은?
- 같은 상태면 크기는 늘 같지만 시간은 기계와 부하에 따라 달라진다
- 직렬화 시간이 저장 시간보다 늘 짧아 시간 측정이 의미가 없다
- 체크포인터가 시간을 재는 기능을 제공하지 않는다
- 바이트 수가 커질수록 저장 시간이 정확히 비례해 늘어난다