测验：图优化改变了什么

최적화된 그래프에 실제로 무엇이 들어 있는지 확인하는 가장 확실한 방법은?

• 세션을 연 뒤 실행 시간을 재어 줄어든 만큼을 추정한다
• 원본 파일의 노드를 세고 문서에 적힌 융합 규칙을 대입해 계산한다
• 로그 수준을 낮춰 최적화기가 찍는 메시지를 모아 읽는다
• SessionOptions.optimized_model_filepath 로 꺼낸 파일을 열어 노드를 센다

입력이 모두 initializer 인 Add 노드가 최적화 뒤에 사라졌다. 그 계산은 어디로 갔는가?

• 런타임이 매 호출마다 다시 계산하도록 코드로 옮겨졌다
• 미리 계산되어 결과가 새로운 initializer 로 들어앉았다
• 필요 없다고 판단되어 결과가 통째로 버려졌다
• 그 노드를 쓰는 다음 노드의 속성 값으로 접혀 들어갔다

최적화 단계를 올렸더니 FusedGemm 이라는 노드가 생겼다. 이 파일을 다른 팀에 보내면?

• 표준 연산자가 아니지만 onnx.checker 가 막아 주므로 사고가 안 난다
• ONNX 파일이므로 어느 런타임이든 연다
• 그 노드는 표준이 아닌 도메인에 있어 그 도메인을 모르는 런타임은 열지 못한다
• 노드 수가 줄어 파일이 작아졌으므로 오히려 권장된다

양자화 전후의 속도를 견주려 한다. 측정 전에 반드시 맞춰 두어야 하는 것은?

• 두 측정의 그래프 최적화 단계
• 두 모델의 파일 크기
• 두 모델의 producer_name
• 두 측정의 난수 씨앗

네 단계로 같은 입력을 돌렸더니 출력이 소수점 아래 일곱째 자리에서 달랐다. 어떻게 판단해야 하는가?

• 최적화가 계산을 바꿨으므로 그 단계를 쓰면 안 된다
• float32 의 유효자리 안쪽 흔들림이므로 허용 오차를 정해 두고 그 안인지 본다
• 런타임 버그이므로 정확히 같은 값이 나올 때까지 단계를 낮춘다
• 출력이 다르다는 것은 그래프가 손상되었다는 뜻이다

ORT_ENABLE_BASIC 단계가 하는 일에 대한 설명으로 가장 정확한 것은?

• 아무 변형도 하지 않고 그래프를 그대로 실행한다
• 특정 하드웨어에 맞춘 레이아웃 변환까지 전부 적용한다
• 모델을 정수로 양자화해 파일 크기를 줄인다
• 상수 접기와 없어도 되는 노드 제거처럼 의미를 바꾸지 않는 정리를 한다