이어받기 가능한 전송

긴 전송은 반드시 중단된다 — 계획해라

아카이브 속도로 당기는 기가바이트급 풀은 몇 시간 걸려. 몇 시간에 걸쳐, 중단 확률은 확실성으로 수렴해: 노트북이 잠들고, Wi-Fi가 타워를 바꾸고, VPN이 재협상하고, 전원이 순간 날락하고, 허브가 연결을 초기화해. 이건 불운이 아니야 — 대용량 파일 작업의 예상 운용 조건이야. 설계 질문은 중단이 뭘 비용으로 하는 거야: 완전 재시작(순진한 정책) 또는 계속(이어받기 정책).

HTTP가 메커니즘을 줘: Range 요청. 이미 쥔 바이트 수를 아는 클라이언트는 서버에 나머지만 요청할 수 있어 — Range: bytes=4920320256- — 그리고 이어 붙이지. 파일을 정적으로 저장하는 서버(모델 허브의 CDN 엔드포인트 포함)는 이걸 지원해. 클라이언트 쪽 의례는 이렇게 안전해져:

.part(또는 비슷하게 표시된) 파일명으로 내려받기 — 미완료 파일이 절대 완료 파일의 이름을 입지 않게.
이어받을 때 정확히 현재-크기부터 요청해서 붙이기.
바이트 수가 기대 총량과 일치할 때만 파일이 진짜 이름으로 졸업하기.
그다음에야 — 그때에만 — 다이제스트 점검.

마지막 순서가 중요해: 이어받기가 파일을 조립하고, 검증이 그 조립을 증명해. 이어받은 파일은 여러 시간에 걸친 여러 세션이 썼어. 어떤 창의 바이트가 전송 중 손상됐다면, 전송 끝의 다이제스트만 잡아. 검증 없는 이어받기는 점검 없는 배관이야.

이미 갖고 있는 도구들

curl은 이어받기를 일급 플래그로 갖고(-C -: "디스크의 파일이 끝나는 곳에서 계속"), 어떤 스크립트 다운로드든 이어받기 가능하게 만들어. 공식 허브 CLI들은 이어받기를 내부적으로 구현해 — 수집에 CLI를 선호할 또 하나의 이유지. rsync는 같은 파일의 저장소 쪽 복사를 위한 일꾼이고, 자체의 블록 단위 델타 논리와 부분 파일 처리를 가져와.

그 어떤 도구도 정책을 대신 정해주진 못해: .part 관례, 이름 바꾸기 전 기대-크기 점검, 조립 후 다이제스트 — 이 세 규칙은 기록관의 것이고, 그 순서대로, 매번 적용돼.

미완료 파일은 절대 완료 파일의 이름을 입지 않는다. .part 관례 + 크기-그리고-다이제스트 졸업이, 존재하는 것에 대해 거짓말하지 않으면서 중단들을 살아남게 하는, 몇 달짜리 수집 캠페인의 조건이야.

이어받기 가능성의 일부인 속도 조절

아카이브 전송이 일부러 느리게 도는, 조용한 두 번째 이유가 있어: 몇 시간 동안 포화된 링크는 중단률을 올리고(메모리 압박의 라우터 재부팅, 과열 어댑터, 가족이 뭘 재부팅함) 매번의 재시작 비용을 곱해. 속도가 조절된 전송(일부러 링크 천장 아래로)은 약간의 속도를 훨씬 낮은 기대 중단 횟수와 바꿔. 인내는 출처에 대한 예의만이 아니라. 이어받기 가능성의 아군이야.

Code

curl로 끝까지 가는 이어받기 의례·bash

URL=https://huggingface.co/<org>/<model>/resolve/main/model-00001-of-00003.safetensors
EXPECTED=4920320256   # 포인터 파일의 size 필드에서
PART=model-00001.safetensors.part

resume_pull() {
  while true; do
    curl -L -C - --fail -o "$PART" "$URL" && break
    echo "$(stat -f%z "$PART") 바이트에서 중단; 10초 뒤 재시도"; sleep 10
  done
}
resume_pull

# 올바른 크기일 때만 졸업시키고, 그다음 검증:
ACTUAL=$(stat -f%z "$PART")
[ "$ACTUAL" = "$EXPECTED" ] && mv "$PART" model-00001.safetensors \
  || echo "크기 불일치: $ACTUAL != $EXPECTED -- 이름 바꾸지 마"
shasum -a 256 model-00001.safetensors   # 포인터 oid와 비교

# 저장소 쪽 복사에는 rsync (이어받기 + 검증 내장):
# rsync -avh --partial --progress src/ archive/models/<model>/

Exercise

실제 URL 하나에 이어받기 의례를 지어 봐: resume_pull 셸 함수(또는 동등물)를 쓰고, 적당히 큰 파일로 돌리고, 최소 두 번 일부러 중단해 보기(Ctrl-C). 완료되고 올바른 크기로 졸업하고 다이제스트 점검을 통과하는지 확인해. 각 중단 뒤 .part 파일의 크기가 뭘 보여줬는지 적어.

Hint

포인터에서 기대 크기를 아는 파일을 골라(이전 레슨). 중단 크기들이 이어받기 오프셋이 작동함을 말해 줘 — 각 재시작은 0이 아닌 시작점을 기록해야 해.

긴 전송은 반드시 중단된다 — 계획해라

이미 갖고 있는 도구들

이어받기 가능성의 일부인 속도 조절

Code

External links

Exercise

Progress

댓글 0