작은 모델의 과장 광고를 잡는다

한 줄 요약

모델 파일 크기와 실행 성능을 나눠 재고 배포 근거의 범위를 명시합니다.

왜 이게 필요했나

작아진 모델을 보고 “메모리도 줄고 어디서나 빨라졌습니다”라고 보고하면 무엇이 빠졌을까요? 파일은 디스크의 바이트 수이고, 실행 프로세스에는 Python·추론 엔진·작업 버퍼도 들어갑니다. 배포 판단에는 정확도뿐 아니라 무엇을 어떤 환경에서 측정했는지가 필요합니다. 이 실습은 양자화의 승리를 보장하는 대회가 아니라 근거를 갖고 배포 여부를 정하는 연습입니다.

어떻게 동작하나

제공 bench.py는 모델 로딩과 입력 준비를 시간 측정 밖에 두고 engine.run 호출을 잽니다. 따라서 보고된 지연은 웹 요청의 전체 응답 시간이 아닙니다. CPU 추론 스레드는 1개로 고정하고, 독립 프로세스 3라운드에서 각 배치 크기마다 워밍업 10회 후 100회씩 측정합니다. 배치 크기는 1과 32입니다. 모델 실행 순서도 라운드마다 교대합니다. 측정값은 마이크로초/배치이고 각 배치에는 합계 300개의 원시 시간이 남습니다.

latency_stats(samples_us, batch_size)를 구현할 때 p50은 정렬된 표본의 중앙값, p95는 nearest-rank 방식의 ceil(0.95×n)번째 값입니다. Python 인덱스는 여기서 1을 뺍니다. 짝수 표본의 중앙값은 가운데 둘의 평균입니다. 라운드별 p95를 평균하지 않고 원시 표본을 합친 뒤 다시 계산합니다. 처리량은 batch_size×n×1,000,000/sum(samples_us)입니다. 배치 32의 시간을 그대로 초당 요청 수로 뒤집으면 이미지 수가 32배 어긋납니다.

메모리는 Linux /proc/self/status의 VmHWM을 바이트로 환산해 기록합니다. 이는 측정 프로세스 전체의 최고 상주 메모리이며 모델만의 메모리도, GPU 메모리도 아닙니다. 이번 개발 컨테이너의 한 측정에서는 모델 파일이 약 70KB에서 24KB로 줄어도 프로세스 HWM은 약 62MB로 비슷했습니다. 시간은 공유 CPU 부하·명령어 집합·런타임 등에 따라 달라지므로 그 숫자를 채점 정답으로 고정하지 않습니다.

benchmark.json은 모델과 데이터의 SHA-256을 함께 기록합니다. 모델을 다시 변환했다면 측정도 다시 해야 합니다. 해시 연결과 통계 검사는 오래된 보고서나 계산 오류를 찾지만, 학생이 시간을 직접 지어 쓰지 않았다는 것을 증명하는 장치는 아닙니다. 원시 표본은 검토 가능한 실험 기록이지 위변조 방지 인증서가 아닙니다.

실무 검토 회의에서 묻는 질문

“얼마나 빨라졌나요?”라고 묻기 전에 “어디부터 어디까지 쟀나요?”라고 물어보세요. 파일 읽기와 모델 로딩까지 잰 cold start와 이미 준비된 세션의 run 호출은 사용자가 겪는 다른 상황입니다. 앱을 하루에 한 번 여는 사람과 같은 세션으로 영상을 계속 처리하는 장치는 중요한 지표가 다릅니다. 이번 실습은 후자의 일부인 준비된 CPU 추론을 측정하며, 네트워크·이미지 전처리·결과 전달 지연은 포함하지 않습니다.

세 라운드의 p95가 각각 10, 20, 100이라면 평균 43.3을 전체 p95라고 적어도 될까요? 백분위수는 데이터 개수와 순서에 의해 정해집니다. 라운드 요약 세 개만으로는 어느 쪽에 느린 표본이 몇 개 있었는지 복원할 수 없습니다. 그래서 도우미는 원시 시간을 모두 남기고 학생 함수는 합친 300개를 다시 정렬합니다. 반대로 전체 원시 시간을 버리고 요약만 저장하면 이상치를 재검토할 근거도 사라집니다.

단위가 붙은 손 계산도 해보세요. 배치 크기 32, 반복 300회이면 이미지 총 9,600개입니다. 시간 합이 3,000,000마이크로초이면 3초이므로 처리량은 3,200개/초입니다. 배치 호출 수를 분자로 쓰면 100회/초가 되는데, 그 값 자체가 틀린 것은 아닙니다. 잘못은 그것을 이미지 처리량이라고 이름 붙이는 데 있습니다. 보고서의 키와 단위가 계산식의 의미를 고정해야 합니다.

평균적으로 빨라도 드물게 긴 지연이 나타나는 모델은 마감이 있는 작업에 맞지 않을 수 있습니다. 그러나 이 실습의 p95가 하드 실시간 상한을 보장하는 것은 아닙니다. 아직 관찰하지 않은 부하나 장치 조건이 있습니다. 전력·열·장시간 안정성도 별도의 시험이 필요합니다. target_benchmark_required를 true로 남기는 것은 일을 덜 끝내기 위한 문구가 아니라 이번 증거로 주장할 수 없는 부분을 정확히 넘기는 인수인계입니다.

마지막으로 모델을 다시 변환했을 때 무엇을 다시 해야 하는지 적어 보세요. 해시만 새로 쓰는 것이 아니라 추론 회귀와 측정을 다시 실행해야 합니다. 새 파일의 해시를 예전 시간 표본에 붙이면 연결 형식은 맞아도 실험 기록은 거짓입니다. 자동 채점이 모든 행동을 감시할 수는 없습니다. 재현 스크립트·원시 결과·실행 조건을 함께 남기고 동료가 같은 방법으로 다시 확인할 수 있게 하는 것이 실무의 기본입니다.

다음 실습에서 할 것

7단계에서 통계 함수를 구현하고 제공 측정 도우미를 실행하세요. 8단계의 release.json에는 모델 파일 32KiB 이하, 정확도 손실 1%p 이하라는 이 실험의 배포 조건을 기록합니다. 이는 전체 프로세스가 32KiB 안에서 돈다는 뜻이 아닙니다. target_benchmark_required는 true, universally_faster는 false입니다. 실제 장치의 지연·메모리·전력 검증은 별도로 남습니다. 실습 종료 전 소스와 보고서를 보관하세요. 세션 종료 후 작업 파일은 유지되지 않습니다.