[ARIES / QBCompiler 1.2.0] 시계열 Transformer ONNX 컴파일 오류

Product & Environment

Compile

  • Target: aries-rb

  • QBCompiler: 1.2.0

  • Docker: mobilint/qbcompiler:1.2-cpu-ubuntu22.04

  • Backend: ONNX

  • Python: 3.10

  • Device: CPU

  • cpu_offload=False

  • use_random_calib=False

Runtime

  • Device: Mobilint ARIES

  • Driver: 1.13

  • qbruntime: 1.3.2

  • Firmware: 1.2

  • NPU Memory: 16,384 MB

  • Python: 3.12

모델은 공통적으로 다음 과정으로 준비했습니다.

PyTorch checkpoint
→ fixed-shape tensor-only wrapper
→ torch.onnx.export (opset 17, dynamic_axes=None)
→ ONNX Runtime CPU parity 확인
→ qbcompiler.mxq_compile_V2
→ ARIES qbruntime 실행

ONNX Runtime에서 PyTorch reference와의 수치 일치 여부를 먼저 확인한 뒤 QBCompiler에 입력했습니다.

Description

1. TimesFM 2.5 200M

대상 모델:

google/timesfm-2.5-200m-transformers

입출력은 다음과 같습니다.

Input:
normalized_context, FP32 [1,1024]

Output:
point_forecast, FP32 [1,128]

기본 ONNX를 컴파일하면 graph transformation stage 1에서 다음 내부 예외가 발생합니다.

.../mblt/transform/ruleset/operator_folding/inputconst.py
line 611, in case1

NotImplementedError: code should not reach here!

Causal mask를 constant로 고정한 static-mask variant에서는 stage 1을 통과해 stage 4 CPU optimization까지 진행했지만, 최종 MXQ 파일은 생성되지 않았습니다.

2. Chronos-Bolt Tiny

대상 모델:

amazon/chronos-bolt-tiny

정적 FP32 ONNX로 변환했으며, ONNX Runtime에서 PyTorch reference와의 parity를 확인했습니다.

컴파일 시 graph transformation stage 1에서 TimesFM과 동일한 내부 예외가 발생했습니다.

.../mblt/transform/ruleset/operator_folding/inputconst.py
line 611, in case1

NotImplementedError: code should not reach here!

따라서 MXQ 생성 단계까지 진행되지 않았습니다.

3. PatchTST

대상 모델:

ibm-granite/granite-timeseries-patchtst

입출력은 다음과 같습니다.

Input:
past_values, FP32 [1,512,7]
past_observed_mask, BOOL [1,512,7]

Output:
prediction_outputs, FP32 [1,96,7]

PatchTST는 ONNX가 아니라 PyTorch module을 backend="torch"로 QBCompiler에 직접 전달했습니다.

초기 컴파일에서는 다음 연산을 처리하지 못해 MBLT compile 단계에서 실패했습니다.

Tensor.clamp_min(1.0)

Tensor.unfold를 fixed slice/stack patchifier로 변경하고 observation mask를 FP32로 변환한 이후에도 Tensor.clamp_min(1.0)에서 동일하게 실패했습니다.

추가로

Tensor.clamp_min(1.0)
→ Tensor.clamp(min=1.0)

으로 변경한 뒤에는 해당 단계를 통과했지만, 이후 BatchNorm1d 변환 과정에서 compiler가 builder에 존재하지 않는 다음 API를 호출하면서 다시 실패했습니다.

make_batchnorm_1d

세 번의 시도 모두 MBLT 생성 단계에서 실패하여 MXQ compilation과 ARIES runtime은 수행하지 못했습니다.

4. Granite TTM-R1

대상 모델:

ibm-granite/granite-timeseries-ttm-r1

입출력은 다음과 같습니다.

Input:
past_values, FP32 [1,512,1]

Output:
forecast, FP32 [1,96,1]

ONNX input과 동일한 [1,512,1] calibration tensor를 사용하면 quantization 단계에서 다음 오류가 발생했습니다.

RuntimeError: Error. quantizeFB failed.

Given groups=1, weight of size [192, 64, 1, 1],
expected input[1, 1, 1, 512] to have 64 channels,
but got 1 channels instead

Compiler 내부에서 입력이 [1,1,8,64] 형태로 lowering되는 것을 확인하여 calibration data만 [1,8,64]로 reshape했습니다.

feed_dict에는 기존 ONNX ABI인 [1,512,1]을 유지했습니다.

이 방법으로 MXQ 생성 및 ARIES 실행에 성공했습니다.

5. Granite TTM-R2

대상 모델:

ibm-granite/granite-timeseries-ttm-r2

입출력은 다음과 같습니다.

Input:
past_values, FP32 [1,512,1]

Output:
forecast, FP32 [1,96,1]

TTM-R1과 동일하게 semantic calibration shape인 [1,512,1] 대신 compiler calibration data를 [1,8,64]로 reshape했습니다.

이 방법으로 MXQ 생성 및 ARIES 실행에 성공했습니다.

다만 FP32 CPU reference 대비 ARIES 실행 결과에서 일정 수준의 accuracy 차이가 확인되었습니다.

문의사항

위와 같이 여러 시계열 모델에서 컴파일 실패 또는 calibration 관련 문제가 발생하고 있습니다.

제가 모델 변환이나 QBCompiler 사용 과정에서 잘못 적용한 부분이 있는지, 아니면 현재 QBCompiler 1.2.0 및 ARIES의 지원 범위상 발생하는 문제인지 확인 부탁드립니다.

특히 현재 적용한 fixed-shape 변환, calibration 구성, compiler 옵션 중 수정하거나 추가해야 할 사항이 있다면 안내 부탁드립니다.

롹인에 필요한 재현 정보나 추가 로그를 말씀해주시면. 현재 보관 중인 자료를 확인하여 가능한 범위에서 전달드리겠습니다.

감사합니다.

안녕하세요~

모빌린트의 박상형입니다.

현재 qb Compiler 1.3.0 이 릴리즈 된 상태입니다.

하기 릴리즈 노트와 같은 수정 사항들이 있어,

최신 버전으로 다시 한번 시도 후 확인 좀 부탁드리겠습니다.

감사합니다.

안녕하세요. 위 질문에서 추가로 궁금한 사항이 있습니다.

  1. 다중 입력 노드 지원 여부
    qbcompiler v1.3.0 릴리즈 노트에서 "입력 노드가 여러 개인 모델에 대한 컴파일 지원"이 언급되었던 것으로 기억하는데, 실제 릴리즈 노트(docs.mobilint.com)에서는 해당 내용을 확인하기 어렵습니다. 이 기능이 v1.3.0에 실제로 추가되었는지, 아니면 추가될 예정인지 확인 부탁드립니다.

  2. Transformer 기반 모델 컴파일 차이점
    RT-DETR 계열 모델은 transformer 레이어로 인해 현재 컴파일이 불가능한 것으로 알고 있습니다. 그런데 동시에 qbcompiler에서는 transformer 모듈을 사용하는 VLM 및 LLM 모델들은 컴파일이 지원되고 있습니다. RT-DETR과 이러한 VLM/LLM 모델들 간에 컴파일 가능 여부를 결정하는 기술적 차이점은 무엇인지 궁금합니다

감사합니다.

안녕하세요,

모빌린트 박상형입니다.

추가 문의 주신 두 가지 답변드립니다.

1. 다중 입력 노드 지원
입력이 여러 개인 모델의 컴파일은 v1.3.0에서 새로 추가된 기능이 아니라 이전 버전부터 지원하고 있습니다. calibration 데이터는 입력마다 텐서를 하나씩 준비하시고, 같은 샘플 번호의 입력들은 같은 실제 예시에서 나온 데이터여야 합니다(매뉴얼 Model Quantization › Multi-input Calibration 참고).
v1.3.0에서는 다중 입력과 관련된 수정이 두 가지 있었습니다. 첫째, calibration 입력을 이름 기반으로 줄 때 shape이 같은 입력끼리 순서가 뒤바뀌던 문제가 수정되었습니다. 둘째, 분할(split) 모델의 입출력 순서 문제가 수정되었습니다.

2. RT-DETR과 LLM/VLM의 차이
컴파일 가능 여부를 가르는 것은 Transformer 사용 여부가 아니라 attention의 연산 방식입니다. LLM/VLM의 attention은 크기가 고정된 행렬곱으로만 이루어져 있어 NPU에서 효율적으로 실행됩니다.
반면 RT-DETR의 decoder는 deformable attention을 사용합니다. 이 방식은 입력마다 샘플링할 좌표를 예측한 뒤, 그 좌표의 값을 grid_sample로 읽어옵니다. 읽을 메모리 위치가 실행 시점의 데이터에 따라 달라지기 때문에, 현재 ARIES 하드웨어에서는 지원되지 않습니다. D-FINE 등 deformable attention을 쓰는 DETR 계열도 같은 사유로 현재 미지원입니다.

감사합니다.