M11.06 · 추론 지연·메모리·분포 이동과 실험 추적

모델 호출보다 오래된 관측

추론 지연 latency는 정한 시작과 끝 사이의 시간이다. 모형 함수 호출만 잰 값, 전처리/후처리를 포함한 값, 관측 취득부터 명령 적용까지의 값은 서로 다르다. 높은 FPS라는 보고도 어떤 처리량 throughput인지 확인한다. 여러 입력을 묶거나 파이프라인으로 겹치면 초당 처리 수는 늘어도 한 입력의 결과가 늦게 나올 수 있다. 로봇은 처리된 개수와 현재 행동이 어떤 시각의 관측을 쓰는지를 함께 봐야 한다.

같은 단조 시계로 측정했다고 가정한 합성 시간표를 보자. 영상 취득 0 ms, 전처리 시작 5, 전처리 끝 9, 추론 끝 17, 후처리 끝 19, 발행 22, 적용 25다. 추론 자체는 8 ms이고 전처리 4/후처리 2/발행까지 3/적용까지 3/초기 대기 5 ms로 전체 25 ms다. 전체 기한을 20 ms로 정했다면 5 ms 초과다. 추론 8 ms만 보고 20 ms 기한을 만족했다고 판정하면 틀리다. 다른 시계의 stamp를 빼려면 먼저 M05.06의 시계 변환/오차 조건이 필요하다.

꼬리 지연도 확인한다. 합성 지연 표본[8,9,10,11,42] ms의 평균은 16, 중앙값은 10, 최대는 42다. 20 ms 기한 초과는 1/5다. 여기서 p95는 정렬한 n개 중 ceil(0.95n)번째를 쓰는 nearest-rank 규약으로 정의하면 42 ms다. ceil은 올림이고 n=5다. 라이브러리의 보간 분위수는 다른 숫자를 낼 수 있으므로 규약을 기록한다. 다섯 표본만으로 실제 장기 꼬리 분포를 추정했다고 주장하지 않는다.

측정에는 입력 크기/batch·dtype/device·thread 수, 첫 호출과 warm-up 이후, eval/경사 추적 정책, 전송/동기화·후처리 포함 여부를 남긴다. GPU 연산은 비동기일 수 있어 CPU에서 호출한 직후의 경과 시간만 재면 완료가 아니라 실행 요청 비용만 셀 수 있다. PyTorch 공식 benchmark 자료는 warm-up과 장치 동기화·스레드 조건의 필요성을 설명한다. 여기서는 GPU benchmark를 실행하지 않고 합성 기록을 해석한다.

가중치 파일 크기가 실행 메모리는 아니다

파라미터 원소 수를 N, 원소당 byte 수를 b라고 하면 수치 저장량은 Nb다. 가상 모형 N=2000000개를 float32의 4 byte로 저장하면 8000000 byte, 십진 8 MB다. MiB는 2²⁰ byte 기준이므로 같은 숫자가 아니다. 이 값은 구조/직렬화 헤더나 buffer/중간 활성값까지 포함한 전체 메모리가 아니다.

훈련은 경사와 optimizer 상태를 추가로 가질 수 있다. 단순 비교를 위해 파라미터·경사·Adam의 1차/2차 moment 배열이 모두 float32이고 각 N개이며 상태가 이미 생성됐다고 가정하자. 네 배열은 8 MB씩 총 32 MB다. Adam의 moment는 경사의 이동 평균과 제곱 관련 상태를 저장하는 배열이다. 실제 구현에는 단계 상태/임시 결과와 설정별 추가 비용도 있다. mixed precision의 master 가중치나 상태 dtype도 다를 수 있으므로 ‘모든 학습은 정확히 가중치 4배’라는 공식으로 쓰지 않는다.

추론은 보통 학습용 경사/optimizer 상태가 필요 없지만 입력/출력·활성값·workspace와 라이브러리/장치 컨텍스트가 필요하다. batch나 영상 해상도/토큰 수를 바꾸면 이 비용도 바뀐다. weights만 float16으로 바꾸면 위 가중치 저장량은 4 MB가 되지만 다른 배열과 실제 peak가 모두 절반이라는 보장은 없다. 정밀도 변경에 따른 수치/성과 차이도 재검사한다.

peak는 정한 구간에서 실제 동시에 사용한 메모리의 최대다. 장치 allocator가 예약한 reserved와 살아 있는 텐서의 allocated도 다를 수 있다. PyTorch CUDA 메모리 문서처럼 캐시가 있어 모니터의 점유량과 텐서 수치 합이 다를 수 있다. 측정 API·구간/초기화·warm-up/최대 batch를 적고 가중치 8 MB만으로 ‘8 MB 장치에서 실행 가능’이라고 승인하지 않는다.

전체 평균은 새 조건의 성능을 숨긴다

분포 이동은 배포 입력/과제 조건이 학습/검증 때와 달라지는 상황이다. 조명·렌즈/노출·물체/배경·로봇 자세와 행동 분포가 바뀔 수 있고, 입력이 비슷해 보여도 목표 관계가 달라질 수 있다. 출력 score가 높다는 사실은 새 조건에서 맞다는 보정 증거가 아니다. threshold를 다시 맞추려면 M11.03의 검증/시험 정책도 함께 유지한다.

합성 조건표에서 밝은 조명은 100회 중 90성공, 어두운 조명은 40회 중 20성공이라고 하자. 조건별 성공률은 0.9/0.5, 전체는 110/140≈0.785714다. 이것은 실제 실험 성과가 아닌 산술 예다. 배포가 밝음 20%/어두움 80%이고 각 조건의 성공률이 그대로라는 추가 가정을 두면 기대 혼합 성공률은 0.2×0.9+0.8×0.5=0.58이다. 전체 78.6%를 그대로 배포 성능이라 옮기면 조건 비율 변화를 무시한다.

조건별 성공률도 유한 표본의 추정이므로 이 혼합 계산만으로 실제 배포율을 보장하지 않는다. 드문 실패·새 조건/가림·안전 개입·기한 초과를 따로 보고하고 어떤 변화가 있었는지 기록한다. 모델을 바꾼 날 카메라 노출과 전처리도 바뀌었다면 성능 차이를 모델 하나의 효과라고 단정할 수 없다. 같은 자료/조건의 비교와 별도 통제 검사가 필요하다.

실험 기록은 결과를 설명하는 입력이다

run ID에 원본 코드 개정/dirty 상태, 학습/검증/시험 manifest·자료/라벨 해시, 모형/가중치·전처리/목표 단위, 학습 설정/선택 기준·seed를 연결한다. 실행 기록에는 runtime/라이브러리·backend/하드웨어/드라이버, batch/dtype/thread·warm-up/측정 구간, 시간원/전송 포함 범위, 메모리 API·조건별 지표와 실패 원자료를 붙인다. 값이 없는 항목은 미확인으로 남기며 다른 run의 좋은 숫자를 채우지 않는다.

같은 seed나 checkpoint 해시는 조건 중 일부다. PyTorch 공식 재현성 지침은 릴리스/플랫폼/CPU·GPU를 넘는 완전한 재현을 보장하지 않는다. 허용 오차의 수치 반복인지 비트 동일성인지, offline 예측인지 실제 closed-loop 작업인지 구분한다. 기존 5.9 폐루프 추론과 5.10 평가도 이 서로 다른 측정 범위를 연결해 읽는다.

입력은 위 합성 시간표/지연 5개·20 ms 기한, N=2000000의 네 float32 배열 가정, 밝음/어두움 성공표와 배포 20/80%다. 실제 benchmark나 성공률 측정이 아니다.

1. 추론/전체 지연·초과량, 평균/중앙/최대/nearest-rank p95와 초과 비율을 계산한다. 추가 측정 조건을 제안한다.
2. 가중치와 명시된 네 배열의 수치 저장량을 계산하고 실제 훈련/추론 peak에 빠진 항목을 적는다.
3. 조건별/전체와 새 혼합 성공률을 계산한다. 분포/동시 변경의 해석 한계 및 재현 기록을 제안한다.

관찰은 시간/통계·저장량/peak·조건/추적으로 나눈다. 막히면 같은 시계의 끝−시작을 구하고 MB와 byte를 통일한다. 장치/GPU·모델 학습은 필요하지 않다.