AMD AI 엔진용 BLAS 라이브러리, AI 가속의 숨은 핵심 부품
딥러닝 프레임워크를 최신 AMD 하드웨어에 올렸는데, 생각보다 성능이 안 나와서 당황해본 적 있나요?
이유는 의외로 간단합니다. 겉으로 보이는 GPU, AI 엔진보다 더 밑바닥에서 돌아가는 “수학 라이브러리”가 아직 충분히 최적화되지 않았기 때문입니다.
이 글에서 다룰 주제는 바로 그 밑단, AMD AI 엔진용 BLAS 라이브러리 개발입니다.
BLAS가 무엇인지, 왜 AMD AI 엔진에 특화된 BLAS가 중요한지, 그리고 이것이 앞으로 AI·머신러닝 개발자에게 어떤 의미를 갖는지까지 한 번에 정리해 보겠습니다.
BLAS란 무엇인가? AI 연산의 어셈블리어
BLAS(Basic Linear Algebra Subprograms)는 이름 그대로 “기본 선형 대수 서브루틴”입니다.
쉽게 말해, AI와 수치해석에서 매번 반복되는 연산을 모아 표준 인터페이스로 정의한 낮은 단계의 수학 함수 모음입니다1.
BLAS가 다루는 대표적인 연산은 다음과 같습니다.
행렬–행렬 곱셈, 행렬–벡터 곱셈, 벡터 더하기, 스칼라 곱, 내적 계산 등입니다.
이런 것들이 바로 신경망의 한 층을 통과할 때마다 엄청난 횟수로 반복되는 연산들입니다.
BLAS는 기능에 따라 세 단계로 나뉩니다1.
레벨 1: 벡터–벡터 연산 (예: 두 벡터 더하기, 내적)
레벨 2: 행렬–벡터 연산 (예: matvec)
레벨 3: 행렬–행렬 연산 (예: matmul, GEMM)
여기서 레벨 3, 특히 GEMM(General Matrix Multiply)은 딥러닝 성능을 거의 좌우하는 핵심입니다.
LINPACK 같은 벤치마크도 GEMM 성능을 기준으로 평가할 정도죠1.
재미있는 건, BLAS 자체는 “규격(specification)”에 가깝다는 점입니다.
실제 구현은 하드웨어 제조사나 오픈소스 커뮤니티가 각자 최적화해서 만듭니다. 그래서 같은 BLAS API라도, 인텔 CPU에선 MKL, AMD CPU에선 BLIS, NVIDIA GPU에선 cuBLAS, AMD GPU에선 rocBLAS처럼 서로 다른 라이브러리를 쓰게 됩니다1234.
정리하자면 BLAS는 이렇게 볼 수 있습니다.
“프레임워크 위에 모델이 있고, 그 아래에 선형대수 라이브러리가 있고, 그 아래에 하드웨어가 있다.
이때 프레임워크가 ‘행렬 곱해줘’라고 말할 때 호출하는 공용 언어가 바로 BLAS.”
AMD AI 엔진용 BLAS 라이브러리는 이 공용 언어를 AI 엔진이라는 새로운 하드웨어에 맞게 재정의·최적화하는 작업이라고 보면 됩니다.
AMD AI 엔진과 BLAS의 만남: 왜 별도 라이브러리가 필요한가
AMD는 CPU, GPU뿐 아니라 Versal 같은 Adaptive SoC에 들어가는 “AI Engine”이라는 전용 컴퓨팅 블록을 제공합니다56.
이 AI 엔진은 대략 이런 특징을 갖습니다.
작고 빠른 벡터 연산 유닛이 수십~수백 개 타일 형태로 배열된 구조,
FPGA/SoC 내부에서 초저지연/고효율 연산을 하는 용도,
딥러닝·신호처리·비전 처리 같은 특정 워크로드를 오프로딩하기 좋은 구조.
문제는, 이런 하드웨어가 아무리 좋아도 소프트웨어 스택이 받쳐주지 않으면 제 성능을 내기 어렵다는 점입니다.
그리고 그 소프트웨어 스택의 핵심에 바로 BLAS가 있습니다.
NVIDIA의 CUDA 생태계를 떠올려 보면 이해가 쉽습니다.
CUDA 위에 cuBLAS, cuDNN 같은 고성능 라이브러리가 있고, 그 위로 PyTorch·TensorFlow가 올라갑니다.
AMD도 ROCm 스택 위에 rocBLAS, rocSOLVER 같은 라이브러리를 올려서 GPU 연산을 가속합니다4.
이제 AMD는 이를 한 단계 더 확장해, AI 엔진 전용 BLAS 라이브러리를 만드는 단계로 가고 있습니다.
왜 굳이 “전용”이 필요할까요?
AI 엔진은 일반 GPU나 CPU와 구조가 다릅니다.
메모리 계층, 데이터 이동 방식, 벡터 유닛의 크기, 타일 간 인터커넥트… 이런 것들이 모두 다르기 때문에, 일반적인 BLAS 구현을 그대로 가져다 쓰면 대역폭이 막히거나, 파이프라인이 놀거나, 캐시/로컬 메모리를 제대로 활용하지 못하는 일이 발생합니다.
따라서 AI 엔진용 BLAS는 다음을 노립니다.
행렬–벡터(matvec), 행렬–행렬(matmul) 연산을 AI 엔진의 타일 구조에 맞게 최적 분할,
로컬 메모리에 데이터 블록을 똑똑하게 배치해 메모리 트래픽 최소화,
벡터 명령·SIMD 유닛을 100%에 가깝게 활용하는 커널 제공,
나아가 기존 BLAS 인터페이스(예: GEMM)를 최대한 유지해, 상위 라이브러리와 프레임워크가 코드를 바꾸지 않고도 사용하게 하는 것.
결국 이 작업은 “새로운 하드웨어에 맞는 고성능 수학 엔진을 만들어, 프레임워크에서는 그냥 BLAS로 호출만 하게 만드는 것”입니다.
프레임워크 입장에선 마치 하드웨어가 알아서 빨라진 것처럼 보이지만, 사실은 그 밑에서 AI 엔진용 BLAS가 조용히 일하고 있는 셈이죠.
행렬 곱(matmul)·matvec 최적화: AI 성능을 바꾸는 디테일
AI 엔진용 BLAS 라이브러리가 현실에서 가장 먼저 집중할 타깃은 두 가지입니다.
행렬–벡터 곱(matvec)
행렬–행렬 곱(matmul, GEMM)
왜냐하면 이것들이 실제 AI/머신러닝 모델에서 사용량이 압도적으로 많기 때문입니다.
예를 들어:
Transformer의 Attention,
CNN의 FC 레이어,
RNN, LSTM의 시퀀스 처리,
대부분의 학습·추론에서 수백, 수천만 번 호출되는 연산이 바로 matmul입니다.
이 연산을 최적화하는 대표적인 기법들을 AI 엔진에 맞게 다시 설계해야 합니다.
첫째, 블로킹(blocking)과 타일링(tiling)입니다.
거대한 행렬을 한 번에 곱하지 않고, AI 엔진 타일 하나가 처리하기 좋은 크기의 작은 블록으로 쪼개어 순차·병렬 처리합니다.
이때 각 블록이 AI 엔진의 로컬 메모리 안에서 왔다 갔다 하도록 설계하면, 느린 외부 메모리 접근을 크게 줄일 수 있습니다.
둘째, 데이터 레이아웃 최적화입니다.
행렬을 row-major로 둘지, column-major로 둘지, 혹은 AI 엔진 타일 구조에 맞는 사용자 정의 레이아웃을 쓸지에 따라 메모리 접근 패턴이 크게 달라집니다.
BLAS는 API 레벨에서 이를 추상화해주면서, 내부에서는 AI 엔진에 맞는 레이아웃으로 재배치하거나, 연산 순서를 조정해 캐시 친화적인 접근을 합니다.
셋째, 특수 데이터 타입 최적화입니다.
AI 워크로드에서는 FP16, BF16, INT8 같은 저정밀도 연산이 성능·전력 효율 측면에서 매우 중요합니다.
AI 엔진이 제공하는 저정밀도 연산 유닛을 적극 활용하도록, BLAS의 GEMM/Matvec 커널을 타입별로 튜닝하는 작업이 필요합니다.
넷째, 파이프라이닝과 중첩 실행입니다.
한 타일이 연산을 수행하는 동안, 다른 타일은 다음 연산에 필요한 데이터를 미리 불러오게 하는 식으로 연산–데이터 전송을 겹쳐 실행하면, 전체 처리량을 크게 높일 수 있습니다.
AI 엔진용 BLAS 라이브러리는 이 파이프라인 설계를 라이브러리 내부에서 책임지는 쪽에 가깝습니다.
흥미로운 연구로, NVIDIA 환경에서 cuBLAS조차 강화학습과 LLM으로 자동 튜닝한 HGEMM 커널이 성능을 앞질렀다는 사례도 있습니다7.
이런 흐름을 보면, AMD AI 엔진용 BLAS 개발에서도 자동 탐색, RL 기반 튜닝, LLM 보조 최적화 같은 기법이 향후 들어갈 가능성이 크다고 볼 수 있습니다.
AI 프레임워크 호환성과 개발자 경험: “그냥 돌렸는데 빨라졌다”를 만들기
하드웨어가 새로 생길 때마다 개발자에게 “이제부터 전용 API로 새로 짜세요”라고 하면 아무도 좋아하지 않습니다.
그래서 BLAS의 가장 큰 장점 중 하나가 바로 인터페이스의 표준화입니다1.
AMD가 GPU용으로 제공하는 ROCm 스택만 봐도, 하위에는 rocBLAS, 상위에는 PyTorch·TensorFlow를 위한 백엔드가 연결되어 있습니다4.
프레임워크는 그저 “BLAS/GEMM 호출”을 할 뿐이고, 실제로 어느 라이브러리가 어느 하드웨어에서 돌아가는지에 대해서는 몰라도 됩니다.
AI 엔진용 BLAS가 제대로 자리 잡으면, 다음과 같은 그림이 가능합니다.
PyTorch나 TensorFlow가 AMD 플랫폼에서 돌아간다.
프레임워크가 GEMM, matvec을 호출한다.
GPU가 아니라 AI 엔진이 더 효율적인 경우, BLAS가 그 연산을 AI 엔진으로 오프로딩한다.
개발자는 코드 한 줄 바꾸지 않았는데, 특정 워크로드에서 지연 시간과 전력 소모가 눈에 띄게 줄어든다.
이런 통합을 위해 AMD는 이미 Developer Central, ROCm AI Developer Hub, Ryzen AI Software 등 다양한 개발자 포털과 도구를 운영하고 있습니다2389.
AI 엔진용 BLAS가 이 생태계에 녹아들면, 개발자 입장에서는 “AI 엔진을 직접 프로그래밍한다”기보다 “기존 프레임워크를 쓰는데, 뒤에서 AI 엔진이 BLAS를 통해 자연스럽게 활용되는 구조”가 되는 것이 이상적인 방향입니다.
즉, 좋은 BLAS 라이브러리의 증거는, 개발자가 BLAS를 의식하지 않아도 된다는 것입니다.
그냥 네이티브 PyTorch, ONNX Runtime, 혹은 AMD가 제공하는 가속 라이브러리를 쓰면, 내부에서 알아서 AI 엔진이 가장 맛있는 연산만 골라 가져가는 그림이죠.
앞으로의 시사점: AMD 플랫폼에서 AI를 돌리는 개발자에게
정리해보면, AMD AI 엔진용 BLAS 라이브러리 개발은 단순한 “수학 함수 최적화” 이상의 의미를 가집니다.
첫째, AMD 하드웨어 풀 스택 최적화의 핵심 조각입니다.
CPU(EPYC, Ryzen), GPU(Instinct, Radeon), Adaptive SoC와 AI Engine까지 이어지는 구조에서, BLAS는 공통의 수학 엔진 역할을 합니다.
AI 엔진용 BLAS는 이 퍼즐을 완성하는 마지막 조각 중 하나에 가깝습니다.
둘째, AI/ML 워크로드의 성능·전력 효율을 동시에 끌어올리는 수단입니다.
행렬 곱과 matvec을 AI 엔진에 최적화하면, 같은 모델을 덜 뜨거운 전력·더 낮은 지연으로 돌릴 수 있습니다.
특히 엣지, 임베디드, 실시간 처리가 중요한 도메인에서 체감 효과가 클 것입니다.
셋째, 프레임워크 호환성을 유지한 채 새로운 하드웨어를 활용할 수 있는 길입니다.
BLAS 인터페이스를 유지하면서 AI 엔진에 맞는 구현을 제공하면, 상위 레벨의 코드 변화 없이도 성능 이득을 볼 수 있습니다.
이는 기업 입장에서 “레거시 코드 자산을 지키면서도 새로운 하드웨어로 이주”할 수 있게 해 줍니다.
개발자 관점에서 할 수 있는 실질적인 준비를 꼽자면 이 정도입니다.
AMD 플랫폼에서 PyTorch·TensorFlow를 쓰고 있다면, 어느 BLAS 백엔드를 사용하는지, ROCm/AI 엔진 관련 설정이 어떻게 되는지 한 번 점검해보기.
행렬 크기, 배치 사이즈에 따라 어느 쪽 하드웨어(GPU vs AI Engine)가 유리할지 감을 잡아두기.
향후 공개될 AI 엔진용 BLAS/라이브러리 문서와 샘플 코드를 관심 있게 따라가며, “별도 커스텀 커널” 대신 BLAS 호출만으로 튜닝하는 방향을 고려해 보기.
AI 엔진용 BLAS 라이브러리는 지금 눈앞에 보이는 기능은 아닐 수 있습니다.
하지만 언젠가 “그냥 업데이트했더니 AMD 기기에서 모델이 더 빨라졌다”는 순간이 온다면, 그 조용한 공로자 중 하나가 바로 이 라이브러리일 가능성이 큽니다.
참고
1Basic Linear Algebra Subprograms
7CUDA-L2: Surpassing cuBLAS Performance for Matrix Multiplication through Reinforcement Learning