실행 엔진
워크플로우 실행 엔진 내부: 입력 검증, 실행 순서, 단계 입력과 출력, 흐름 제어.
이 컴파일 과정 워크플로우 실행 그래프를 생성하며, 워크플로우 정의를 실행하는 데 필요한 모든 세부 정보를 담고 있습니다. 이 섹션에서는 실행 과정의 세부 사항을 설명하겠습니다.
대략적으로 이 과정은 다음을 수행합니다:
런타임 입력 검증: 워크플로우 정의에 있는 모든 필수 플레이스홀더가 데이터로 채워졌는지 확인하고 데이터 타입이 올바른지 보장합니다.
실행 순서 결정: 단계가 실행되는 순서를 정의합니다.
단계 입력 준비 및 출력 캐싱: 각 단계의 입력을 구성하고 나중에 사용할 수 있도록 출력을 저장합니다.
최종 워크플로우 출력 생성: 워크플로우의 전체 결과를 조립합니다.
런타임 입력 검증
워크플로우 정의는 워크플로우 실행에 필요한 예상 입력을 지정합니다. 앞서 설명했듯이 이전, 입력은 단계에서 처리할 배치 지향 데이터일 수도 있고 단계 실행을 구성하는 매개변수일 수도 있습니다. 이 구분은 워크플로우가 실행되는 방식에 매우 중요하며, 이 페이지 전반에서 살펴볼 것입니다.
입력 검증부터 시작하면, 실행 엔진에는 입력을 파싱하고 사용하도록 준비하는 전용 구성 요소가 있습니다. 이 구성 요소는 워크플로우 정의에서 배치 지향 입력을 인식해 내부 표현으로 변환합니다(예: WorkflowImage 는 Batch[WorkflowImageData]). 이를 통해 블록 개발자는 데이터를 쉽게 다룰 수 있습니다. 비배치 지향 매개변수는 해당 매개변수가 필요한 단계를 만들기 위해 사용되는 블록 매니페스트와 타입 일치 여부를 검사합니다. 이를 통해 타입 오류를 실행 과정 초기에 잡아낼 수 있습니다.
모든 배치 지향 입력의 크기는 1 또는 n이어야 합니다. 배치에 단일 요소만 포함된 경우, 전체 배치에 자동으로 브로드캐스트됩니다.
실행 순서 결정
워크플로우 실행 그래프는 방향 비순환 그래프(DAG)이며, 이를 통해 위상 순서를 결정할 수 있습니다. 위상 순서는 워크플로우 단계가 실행되는 순서를 의미하며, 각 단계가 실행되기 전에 의존성이 충족되도록 보장합니다. 다시 말해, 어떤 단계가 다른 단계의 출력에 의존한다면, 워크플로우 엔진은 해당 의존 단계가 먼저 실행되도록 보장합니다.
또한 위상 구조를 통해 경쟁 조건을 일으키지 않고 병렬로 실행할 수 있는 단계들을 식별할 수 있습니다. 병렬 실행은 워크플로우 실행 엔진의 기본 모드입니다. 즉, 모델 앙상블에 사용되는 단계처럼 서로 독립적인 여러 단계가 동시에 실행될 수 있으며, 그 결과 순차 처리에 비해 실행 속도가 크게 향상됩니다.
실행 엔진의 병렬 실행 모드 때문에(그리고 각 단계에 전달할 때 불필요한 데이터 복사를 피하기 위해) 블록 개발자 여러분께서는 블록의 run(...) 메서드에 전달된 데이터를 절대 변경하지 않도록 강력히 권장합니다. 수정이 필요하다면 변경을 가하기 전에 항상 입력 객체의 복사본을 만드세요!
단계 입력과 출력 처리
단계 입력과 출력을 처리하는 것은 실행 엔진에게 복잡한 작업입니다. 여기에는 다음이 포함됩니다:
입력과 관련하여 SIMD(Single Instruction, Multiple Data) 블록과 비-SIMD 블록을 구분합니다.
조건부 실행과 예상 입력 차원성을 고려하면서 단계 입력을 준비합니다.
실행 흐름을 제어하는 단계의 출력을 관리합니다.
데이터 처리 단계의 출력을 등록하여, 블록이 선언한 출력 차원성과 일치하도록 보장합니다.
이제 각 주제를 자세히 살펴보겠습니다.
SIMD 대 비-SIMD 단계
정의에서 알 수 있듯이, SIMD(Single Instruction, Multiple Data) 단계는 배치 지향 데이터를 처리하며, 동일한 연산이 각 데이터 포인트에 적용되고 구성용으로 비배치 지향 매개변수가 사용될 수 있습니다. 이러한 단계의 출력은 입력 배치 요소의 순서를 유지하는 요소들의 배치여야 합니다. 이는 일반 처리 단계와 흐름 제어 단계 모두에 적용되며(참조 블록 개발 가이드), 흐름 제어 결정이 각 배치 요소에 개별적으로 영향을 미칩니다.
본질적으로, 단계에 입력되는 데이터의 유형이 그것이 SIMD인지 비-SIMD인지 결정합니다. 어떤 단계가 배치 지향 입력을 하나라도 요청하면, 그 단계는 SIMD 단계로 취급됩니다.
반대로 비-SIMD 단계는 입력 데이터에 대해 단일 결과를 제공해야 합니다. 비-SIMD 흐름 제어 단계의 경우, 배치의 각 요소를 개별적으로가 아니라 전체적으로 이후 단계에 영향을 미칩니다.
과거에는 실행 엔진이 비-SIMD 단계의 출력이 SIMD 단계 입력으로 전달되는 모든 시나리오를 잘 처리하지 못했습니다. 그 결과 SIMD 단계에 전달할 때 이러한 출력을 배치로 자동 캐스팅할 수 없어서 컴파일 오류가 발생했습니다. 실행 엔진 v1.6.0부터는 Auto Batch Casting:
SIMD 입력이 감지되었지만 스칼라 데이터가 들어오면, 실행 엔진이 이를 자동으로 배치로 캐스팅합니다.
배치의 차원성은 컴파일 시점에 다음을 사용해 결정됩니다 계보 가능한 경우 다른 배치 지향 입력의 정보를 사용합니다. 누락된 차원은 다음과 유사한 방식으로 생성됩니다
torch.unsqueeze(...).출력은 캐스팅 컨텍스트에 따라 평가됩니다. 블록이 출력 차원성을 유지하거나 줄이면 스칼라로 두고, 새로운 배치를 생성하며 차원성 증가가 예상될 때 그렇게 합니다.
단계 입력 준비
요청된 각 입력 요소는 배치 지향일 수도 있고 아닐 수도 있습니다. 비배치 입력은 비교적 쉽고 특별한 처리가 필요하지 않습니다. 하지만 배치 지향 입력은 훨씬 더 많은 작업이 필요합니다. 실행 엔진은 각 배치 지향 데이터 포인트에 대한 인덱스를 유지합니다. 예를 들어:
입력 이미지 배치가 있으면 각 요소는 고유한 인덱스를 갖습니다. 예를 들어 입력 이미지가 네 장이라면 배치 인덱스는
[(0, ), (1, ), (2, ), (3, )].배치가 아닌 단계 출력도 마찬가지로 인덱싱됩니다. 예를 들어 위의 각 이미지에 대한 모델 예측 역시 인덱싱됩니다
[(0, ), (1, ), (2, ), (3, )].차원성을 증가시키는 블록이 있을 때
차원 수준- 예를 들어 객체 탐지 모델의 예측을 기반으로 하는 동적 크롭이 있고 첫 번째 이미지에 2개, 두 번째에 1개, 네 번째에 3개의 크롭이 있다면 - 이러한 단계의 출력은 다음과 같이 인덱싱됩니다:[(0, 0), (0, 1), (1, 0), (3, 0), (3, 1), (3, 2)].
단계 실행을 위한 입력을 수집할 때 요소의 인덱싱은 중요합니다. 덕분에 모든 배치 지향 입력을 정렬할 수 있습니다. 즉, 실행 엔진은 항상 예측 (3, ) 과 이미지 (3, ) 그리고 크롭 배치의 크롭 [(3, 0), (3, 1), (3, 2)] 을 어떤 단계가 요청하더라도 함께 전달합니다.
요청된 각 입력 요소는 배치 지향 또는 비배치일 수 있습니다. 비배치 입력은 직관적이며 특별한 처리가 필요하지 않습니다. 하지만 배치 지향 입력은 더 복잡합니다. 실행 엔진은 각 배치 지향 데이터 포인트의 인덱스를 추적합니다. 예를 들어:
입력 이미지 배치가 있으면 각 요소는 고유한 인덱스를 받습니다. 이미지 4장의 배치라면 인덱스는
[(0,), (1,), (2,), (3,)].차원을 증가시키지 않는 단계 출력도 비슷하게 인덱싱됩니다. 예를 들어, 네 이미지 각각에 대한 모델 예측의 인덱스는
[(0,), (1,), (2,), (3,)].블록이
dimensionality_level을 증가시키는 경우(예: 객체 탐지 모델의 예측을 기반으로 하는 동적 크롭), 출력은 다르게 인덱싱됩니다. 첫 번째 이미지에 2개, 두 번째에 1개, 네 번째에 3개의 크롭이 있다고 가정해 봅시다. 이 출력의 인덱스는[(0, 0), (0, 1), (1, 0), (3, 0), (3, 1), (3, 2)].
단계 실행 중 입력을 정렬하는 데 인덱싱은 매우 중요합니다. 실행 엔진은 모든 배치 지향 입력이 동기화되도록 보장합니다. 예를 들어, 예측 (3,) 과 이미지 (3,) 과 해당하는 크롭 배치 [(3, 0), (3, 1), (3, 2)] 를 단계가 요청할 때 일치시킵니다.
컴파일 중 데이터 계보를 정리해 두면 실행이 단순해집니다. 실행 엔진은 동적으로 생성된 중첩 배치가 같은 소스에서 왔는지 확인할 필요가 없습니다. 단계 입력을 준비할 때 인덱스를 정렬하는 것이 그 역할입니다.
추가 고려 사항
입력 차원성 오프셋
워크플로우 블록은 입력 차원성을 어떻게 처리할지 정의합니다. 실행 엔진이 입력 차원성의 차이를 감지하면 더 큰 차원을 배치로 감쌉니다. 예를 들어, 어떤 블록이 입력 이미지와 동적으로 크롭된 이미지를 모두 처리한다면, 후자는 각 최상위 이미지가 해당 크롭 배치와 함께 처리되도록 배치로 감싸집니다.
깊게 중첩된 배치는 단계 실행 전에 평탄화됩니다
블록이 모든 입력을 같은 차원 수준으로 정의하므로, 입력 배치의 중첩이 아무리 깊더라도 단계 입력은 단일 배치로 평탄화되며 출력의 인덱스는 실행 엔진이 자동으로 유지합니다.
조건부 실행
흐름 제어 블록은 특정 조건에 따라 어떤 단계를 실행할지 관리합니다. 컴파일 중에는 이러한 조건의 영향을 받는 단계에 플래그가 지정됩니다. 입력을 구성할 때 흐름 제어 제외 마스크(SIMD 및 비-SIMD 모두)가 적용됩니다. 이 마스크에 따라 특정 입력 요소는 None로 대체되며, 이는 빈 값을 나타냅니다.
기본적으로 블록은 빈 값을 허용하지 않으므로 None 인덱스의 (i,) 가 배치 안에 있으면 해당 인덱스는 처리에서 제외됩니다. 이것이 실행 엔진 내부에서 흐름 제어가 관리되는 방식입니다. 그러나 일부 블록은 빈 입력을 처리하도록 설계되어 있습니다. 이러한 경우 흐름 제어 마스크는 적용되지만 빈 입력은 입력 배치에서 제거되지 않습니다.
배치 처리 모드
블록은 배치 입력을 한 번에 처리할 수도 있고, 기본적으로는 실행 엔진이 각 입력을 반복하면서 블록의 run(...) 메서드.
흐름 제어 단계 출력 관리
흐름 제어 단계의 출력은 이 단계들이 어떤 데이터 포인트를 다음 단계로 전달할지 결정하기 때문에 고유합니다. 이는 대략 다음 의사 코드의 결과와 비슷합니다:
워크플로우 실행 엔진은 흐름 제어 단계의 출력을 구문 분석하여 실행 분기를 생성합니다. 각 분기에는 연관된 마스크가 있습니다:
다음의 경우 SIMD 분기에서는 마스크에 처리 대상으로 유지될 인덱스 집합이 포함됩니다.
다음의 경우 비-SIMD 분기에서는 마스크가 단순한
True/False값으로, 전체 분기가 활성화되는지 여부를 결정합니다.
흐름 제어 단계가 실행된 후 이 마스크가 등록되고 해당 결정의 영향을 받는 모든 단계에 적용됩니다. 이를 통해 엔진은 하위 분기에서 특정 데이터 포인트를 처리에서 걸러낼 수 있습니다. 어떤 데이터 포인트가 분기의 첫 단계에서 제외되면(마스킹 때문에), 그 데이터 포인트는 전체 분기에서 자동으로 제거됩니다(기본적으로 빈 입력이 제외되기 때문입니다).
단계 출력 캐싱
주의 깊게 관리해야 하는 것은 흐름 제어 단계의 결과만이 아닙니다. 데이터 처리 단계의 결과도 다른 단계에 올바르게 전달되도록 신경 써야 합니다. 여기서 핵심은 출력을 적절히 인덱싱하는 것입니다.
모든 입력이 같은 차원 수준 을 공유하고 출력도 동일한 차원성을 유지하는 간단한 경우에는, 실행 엔진의 주된 역할은 입력 인덱스의 순서를 보존하는 것입니다. 그러나 입력 차원성이 서로 다르면, 단계를 만들 때 사용된 워크플로우 블록이 인덱싱을 어떻게 처리할지 결정합니다.
처리 중 차원성이 변경되면 실행 엔진은 상위 수준 인덱스를 사용하거나 출력 요소 목록의 길이에 따라 중첩 차원을 동적으로 생성합니다. 이를 통해 단계 간 데이터의 올바른 정렬과 추적이 보장됩니다.
워크플로우 출력 생성
출력이 어떻게 구성되는지에 대한 자세한 내용은 워크플로우 정의 페이지와 출력 구성 워크플로우 실행 문서의 섹션을 참고하세요.
Python에서 실행 엔진 실행
컴파일러와 실행 엔진은 inference 패키지에 함께 포함되어 있어, HTTP API를 거치지 않고 Python 애플리케이션 내부에서 워크플로우를 직접 실행할 수 있습니다. 이는 다음과 같은 팀에 적합합니다:
애플리케이션을 Python으로 유지하고,
애플리케이션 프로세스 안에서 자원 소모가 큰 계산을 허용하며,
HTTP 요청 왕복으로 인한 지연과 실패 가능성을 피하고 싶고,
워크플로우 실행을 완전히 제어하고 싶은 경우.
이것이 가장 요구가 높은 통합 방식입니다. 워크플로우의 블록이 필요로 하는 모든 초기화 매개변수를 제공해야 합니다. 이러한 매개변수와 그 해결 방식은 를 통해 알려 주세요..
HTTP, WebRTC 비디오 스트리밍, CLI, 배치 처리 등 워크플로우를 실행하는 다른 방법은 Workflow 배포하기.
마지막 업데이트
도움이 되었나요?