딥다이브¶

RBLN 런타임 워크플로우¶

RBLN 런타임의 추론 워크플로우는 크게 세 단계로 단순화할 수 있습니다:

1. 컴파일된 파일 로드: .rbln 파일을 메모리에 로드합니다.
2. 런타임 인스턴스 생성: rebel.Runtime() 객체를 생성해 RBLN NPU 기반 추론에 필요한 준비 절차를 수행합니다.
3. 추론 실행: module.run() 메서드를 호출해 NPU에서 실행을 트리거합니다.

다음은 RBLN 런타임을 사용하는 간단한 코드 예제입니다:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import rebel
import torch

# Define input tensor
x = torch.rand(1, 3, 224, 224)

# 1. Load the compiled artifacts from the .rbln file
# 2. Create the runtime instance.
module = rebel.Runtime("simple_conv_bn_relu.rbln", tensor_type="pt")

# 3. Run inference
result = module.run(x)

.rbln 파일 구조¶

컴파일된 .rbln 파일은 NPU에서 신경망을 효율적으로 실행하기 위해 필요한 모든 데이터를 담고 있는 최적화된 컨테이너입니다. 이는 모델을 사전에 패키징하여 추론 경로에서 실시간 컴파일(on-the-fly compilation) 과정을 제거한 형태입니다.

파일의 구성 요소는 크게 모델, 메타데이터, 프로파일 정보 의 세 가지 섹션으로 구분됩니다.

1. 모델(Model)

이 섹션에는 NPU에서 효율적으로 실행될 수 있도록 사전에 최적화된 신경망의 기본 구성 요소들이 포함되어 있습니다.

• 컴파일된 그래프(Compiled Graph): 모델의 연산 흐름을 표현하는 방향성 비순환 그래프(DAG)입니다. torch.nn.Module과 같은 프레임워크에서 가져온 모델의 원본 그래프는 이 최적화된 형태로 “하향 변환(Lowering)“됩니다. 각 노드는 디바이스 연산, 호스트 연산, 메모리 복사이거나, 모델이 여러 NPU에 걸쳐 있을 때는 RBLN 집합 통신 라이브러리(rbln-ccl)가 수행하는 집합 통신(collective communication) 연산입니다. 이를 통해 호스트(CPU)와 NPU 간의 데이터 전송을 포함한 모든 연산이 올바른 위상(Topological) 순서로 실행되어 최대의 효율성을 보장합니다.
• 프로그램 바이너리(Program Binary): NPU의 명령어 집합에 맞게 특별히 컴파일된 실행 가능한 기계어 코드입니다. 이는 전통적인 CPU에서 실행 파일처럼, NPU 프로세서가 직접 실행할 수 있는 저수준 연산들을 포함합니다.
• 커맨드 스트림(Command Stream): NPU의 커맨드 프로세서가 처리하는 최적화된 커맨드 시퀀스입니다. 런타임이 할당한 디바이스 메모리 주소로 커맨드 스트림을 갱신하는 데 사용하는 재배치(relocation) 테이블을 포함합니다.
• 메모리 및 I/O(Memory & I/O): 컴파일 시점에 계획된 메모리 레이아웃을 담습니다. 입력, 출력, 가중치, 중간 데이터 등 모델에 필요한 모든 버퍼가 크기와 메모리 영역과 함께 나열됩니다. 런타임은 초기화 중에 버퍼를 할당하면서 이 레이아웃을 디바이스 주소에 매핑합니다.
• 가중치(Weights): 가중치가 파일에 저장되는지는 컴파일 경로에 따라 다릅니다. RBLN compile API(rebel.compile_from_torch)로 컴파일한 모델은 NPU가 요구하는 레이아웃으로 가중치와 바이어스를 파일에 포함하므로, 런타임을 생성할 때 그대로 디바이스 메모리에 업로드됩니다. torch.compile(backend="rbln")로 컴파일한 모델은 기본적으로 가중치를 파일에 포함하지 않습니다. 파일에는 torch.nn.Module의 어떤 파라미터나 버퍼가 각 가중치 버퍼를 채우는지, 그리고 디바이스 레이아웃으로 어떻게 변환되는지만 기록되며, 런타임을 생성할 때 런타임이 실제 모듈에서 텐서를 읽어 옵니다. 따라서 산출물의 크기는 작아지지만, 로드 시점에 원래 모듈의 파라미터가 필요합니다.

2. 메타데이터(Metadata)

이 섹션에는 모델의 중요한 구조적 정보와 컴파일 정보가 포함되어 있습니다. 이러한 데이터는 RBLNCompiledModel.inspect() API를 통해 확인할 수 있으며, 이를 통해 모델의 아키텍처와 컴파일 과정의 세부 내용을 파악할 수 있습니다.

3. 프로파일 정보(Profile Info)

이 섹션에는 성능 분석에 필수적인 프로파일링 데이터가 포함되어 있습니다. 이 정보는 개발자가 모델이 NPU에서 어떻게 동작하는지를 이해하고, 잠재적인 병목 구간과 개선할 부분을 식별하는 데 도움을 줍니다.

RBLN 커맨드 구조¶

RBLN 런타임은 그래픽 API가 GPU 작업을 관리하는 방식과 유사하게, RBLN NPU에서 태스크를 오케스트레이션하기 위해 구조화된 저수준 커맨드 시스템을 사용합니다.

런타임 초기화 및 실행¶

성능 측정을 위한 방법들¶

1. python에서 time.perf_counter_ns()를 사용하는 방법
   1. 예제 코드:

      1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

      import argparse import time import torch import rebel N_WARMUP = 10 N_ITERS = 50 @torch.compile(backend="rbln", dynamic=False) def matmul(tensor_a: torch.Tensor, tensor_b: torch.Tensor): return torch.matmul(tensor_a, tensor_b) def run(M, N, K): tensor_a = torch.randn(M, K, dtype=torch.float16) tensor_b = torch.randn(K, N, dtype=torch.float16) for _ in range(N_WARMUP): matmul(tensor_a, tensor_b) start_time = time.perf_counter_ns() for _ in range(N_ITERS): matmul(tensor_a, tensor_b) end_time = time.perf_counter_ns() elapsed_time_ms = (end_time - start_time) / 1e6 / N_ITERS tflops = (M * N * (2 * K - 1)) / (elapsed_time_ms * 1e9) return elapsed_time_ms, tflops if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--m", type=int, default=1024) parser.add_argument("--n", type=int, default=1024) parser.add_argument("--k", type=int, default=1024) args = parser.parse_args() ms, tflops = run(args.m, args.n, args.k) print(f"\nelapsed time : {ms} ms / tflops: {tflops} TFLOPs/s")

   2. 장점
      1. end to end 시간을 간단하게 측정할 수 있습니다.
   3. 단점
      1. 실행에 관련된 detail을 파악하기 어렵습니다.
      2. host에서 실행되는 부분이 얼마나 있는지, host to device copy가 얼마나 걸리는지와 같은 정보들은 볼 수 없습니다.
2. get_reports() API를 사용하는 방법
   1. 예시 및 설명: get_reports()
      1. 런타임 그래프에서의 실행시간을 보여줍니다. 여기에서는 host에서 실행되는 h2d copy등이 하나의 op으로 보이고 디바이스에서 실행되는 함수도 하나의 op으로 보입니다.
   2. 장점
      1. 주로 전체 graph에서 host op이 병목이 되는 경우 어떤 host op이 원인인지 찾을 때 유용합니다.
   3. 단점
      1. 런타임 그래프에서 op당 실행시간을 측정하는 도구이므로, 각 op execution 이외의 overhead는 측정되지 않습니다.
         1. op execution 이외의 overhead의 예
            1. python level에서 graph를 실행하기 전에 input에 대한 shape, dtype등의 sanity check(us 단위로 걸립니다)
            2. graph 실행하기 전에 graph의 topology상으로 불가피한 memcpy(ms 단위까지 걸릴 수 있습니다)
            3. RBLN_RUNTIME_TIMER가 설정되는 경우, op 실행 전후에 터미널 출력이나 파일입출력, 또는 json dump등에 걸리는 시간(대체로 us 단위로 걸립니다)
            4. graph 실행 후 graph의 output tensor를 새로 할당하는 경우의 memcpy(ms 단위까지 걸릴 수 있습니다)
3. RBLN 프로파일러를 사용하는 방법
   1. 예시 및 설명
      1. 디바이스에서 실행되는 모든 개별 연산이 각각의 op으로 보이도록 되어 있습니다.
   2. 장점
      1. Perfetto로 실행 과정을 시각화할 수 있어 병목 지점을 분석하기 쉽습니다.
   3. 단점
      1. Profile 오버헤드가 있어서 1번 방법과 2번 방법으로 측정된 값과 차이가 있습니다.
      2. 실행된 op의 정보는 표시되지만, 각 op이 어떤 연산인지 이해하기는 어렵습니다.
         1. Perfetto 분석 가이드를 먼저 읽어 보는 것을 권합니다.
      3. 프로파일링 정보를 시각화만 하고 CSV 등으로 내보내는 기능은 없어서, get_reports() API의 결과와 대조하는 작업이 번거롭습니다.
4. RBLN vLLM에서 PyTorch 프로파일러를 사용하는 방법
   1. 예시
   2. 장점:
      1. vllm 전체에 걸쳐 발생하는 오버헤드와 디바이스 실행시간을 한눈에 훑어볼 수 있습니다.
   3. 단점:
      1. 디바이스 내부에서 일어나는 일의 정보는 보이지 않습니다.

성능 측정 시 유의사항¶

1. 실제 측정 전에 warm up을 위한 실행을 충분히 수행합니다.
2. 실제 측정값은 반복해서 실행한 뒤에 측정된 모든 값의 대표값(예를 들어 평균)으로 표현합니다.
3. 반복 측정 시 측정값의 편차가 크다면 대부분 host preprocessing/post processing에서 생긴 편차입니다. RBLN_NUM_THREADS 환경 변수로 thread 수를 충분히 설정하면 이 편차가 줄어듭니다.
4. RBLN NPU의 end to end 모델 연산은 다음과 같은 것으로 구성되어 있습니다.
   1. host preprocessing -> host-to-device DMA -> device compute -> device-to-host DMA -> host post-processing
   2. 각 단계의 실행시간은 RBLN 프로파일러로 측정할 수 있습니다.
      1. 사용법과 예제는 RBLN 프로파일러 가이드에 있습니다.
      2. torch.compile로 컴파일한 뒤에 실행하면 실행시간에는 위의 모든 과정이 포함됩니다.
5. torch.compile을 통해서 compile된 모델은 sync로 동작합니다.

get_reports() 주의점¶

1. get_reports() 문서를 먼저 주의 깊게 읽어 보는 것을 권합니다.
2. 위의 get_reports() 함수를 쓰려면 RBLN_RUNTIME_TIMER=1 환경변수를 설정해야 합니다.
3. 이 함수를 사용하면 inference가 조금 느려질 수 있습니다.
4. Warm-up을 하는 코드에서 get_reports()를 사용할 경우 warm-up까지 통계에 포함되기 때문에 결과에 왜곡이 생길 수 있습니다. 따라서 warm-up이 끝난 이후에 명시적으로 module.flush_reports()를 호출하면 warm-up으로 인한 결과는 통계에 포함되지 않게 됩니다.
5. 측정 시에 다음의 상황을 고려해야 합니다.
   1. 보통 모델 load하고 첫 한 두번 정도는 디바이스에서 수행 시간이 크게 나오고, 그 이후에 계속 반복하면 비교적 일정한 수행시간이 나옵니다.
   2. host에서 걸리는 시간은 실행마다 편차가 큽니다.