죄송합니다. 더 이상 지원되지 않는 웹 브라우저입니다.

데이터센터 가속화: GPU가 아니라 FPGA를 사용한 Alveo가 답이다

PDF 다운로드

글/이공흠기자(leekh@seminet.co.kr)

데이터 센터 가속기 카드: Alveo 발표

자일링스의 CEO인 빅터 펭은 2018 XDF에서 “우리가 제공하는 다양한 시스템은 완전생산을 할 정도의 수준으로 제공되지만 데이터센터는 그렇지 않다. 데이터센터는 매우 표준화된 인터페이스와 프로세스가 있기 때문이다. 칩을 가지고 개발자가 개발하는 것이 아니라 개발자에게 직접 보드를 공급하기 때문에 우리는 데이터센터 애플리케이션을 개발하려는 사람들에게 더 높은 가치를 제공할 수가 있다”고 말하고 Alveo 보드를 소개했다.
장내는 빅터 펭이 꺼내 든 빨강색 보드에 잠시 웅성거렸지만 이내 그의 발표에 집중하기 시작했다. “Alveo 보드는 컴퓨팅 가속을 위한 것으로써 스토리지 네트워킹과 데이터센터 부문에서 컴퓨팅 가속을 위한 것이기 때문에 PCIe와도 관련되어 있고 다른 가속기의 표준기능 등과도 연관되어 있다. 그러나 다른 가속기와는 차이점이 있다. 어댑터빌리티가 있어서 고객의 실리콘에 맞게 매우 광범위한 용도로 적용이 가능하며 머신러닝 등도 포함된 통합 머신러닝에도 적용할 수가 있다. 다양한 데이터센터 아키텍처에도 사용 가능하다. 물리적인 가속기 카드는 풀로부터 데이터센터의 액티브 워크로드에 얼마 정도 리소스를 배분할 것인지 결정할 수가 있다. DSA가 해당 카드를 탐지할 수 있도록 해야 한다. 이 경우에 워크로드에 대해서 데이터센터의 최대의 쓰루풋이 가능하게 되고 시간이 흘러서 워크로드가 변하면 워크로드 밸런싱도 한다. TCL은 줄이면서 최대의 쓰루풋을 달성할 수가 있다”고 발표했다.
그 후 1년이 지났다. 자일링스는 데이터 센터 가속기 카드인 Alveo 제품 포트폴리오를 확장하고 새로운 Alveo U50을 출시했다. U50은 광범위한 컴퓨팅 및 네트워크, 스토리지의 핵심 작업부하를 재구성이 가능한 단일 플랫폼으로 처리할 수 있도록 설계된 PCIe Gen 4를 지원하는 업계 최초의 로우-프로파일 적응형 가속기 카드이다.
Alveo U50은 클라우드 및 에지에 구축된 모든 서버의 도메인별 가속은 물론, 스케일-아웃 아키텍처를 위해 구현된 프로그램이 가능한 로우-프로파일, 저전력 가속기 플랫폼이다. Alveo U50은 클라우드 마이크로 서비스와 같은 새로운 동적 작업부하 문제를 해결할 수 있도록 처리량 및 지연시간, 전력 효율을 10배~20배까지 향상시킬 수 있다. 이 U50 카드는 네트워킹 및 스토리지 작업부하를 가속화할 수 있도록 데이터에 보다 근접하여 컴퓨팅을 수행함으로써 개발자들이 지연 및 데이터 이동 병목현상을 식별하고, 제거할 수 있도록 해준다.
Alveo 50은 머신 러닝 추론 및 비디오 트랜스코딩, 데이터 분석에서 연산 스토리지 및 전자거래, 금융 리스크 모델링에 이르기까지 구축된 모든 서버에 프로그래머블 기능과 유연성, 높은 처리량 및 낮은 지연 성능의 이점을 제공한다. 다른 고정형 아키텍처와 달리 Alveo U50은 소프트웨어 및 하드웨어를 프로그램할 수 있기 때문에 계속해서 진화하는 작업부하 및 알고리즘에 대응하여 애플리케이션 성능을 최적화하고, 끊임없이 변화하는 요구사항을 충족시킬 수 있다.
자일링스 데이터 센터 그룹의 수석 부사장 겸 총괄 매니저인 살릴 라제(Salil Raje)는 “데이터 센터에 대한 수요가 전례 없이 증가하면서 기존 인프라는 한계에 직면해 있다. 이로 인해 광범위한 작업부하 전반에 걸쳐 성능을 최적화하고, 기존 인프라의 수명주기를 연장하고, 궁극적으로는 TCO를 절감할 수 있는 적응형 솔루션의 필요성이 높아지고 있다”고 말하고, “새로운 Alveo U50은 데이터 센터 작업부하를 위한 최적화된 폼팩터와 탁월한 성능은 물론, 적응력을 제공한다. 자일링스는 이전에는 상상조차 할 수 없었던 기능을 다양한 산업 분야에 제공하기 위해 점차 증가하는 애플리케이션 파트너의 에코시스템과 함께 솔루션 스택을 지속적으로 구축해 나가고 있다”고 밝혔다.

Alveo와 가속이란?

전통적인 무어의 법칙이 폐기되고, 성능, 전력, 지연시간, 유연성을 모두 필요로 하는 개발자들에게 DSA가 인기가 높아지고 있다. 그런데 순수하게 소프트웨어 배경지식만을 가진 개발자들에게는 FPGA 및 ACAP 개발이 매우 어렵게 느껴질 수 있다.
이 글에서는 Alveo를 사용한 애플리케이션 가속화에 대해서 기초적인 것들을 이해하기 쉽게 설명한다. 먼저, 가속화의 원리를 설명한다. 기본적인 아키텍처, 가속화에 관련된 코드, 소프트웨어 API 및 Alveo 카드와 상호작용하는 것에 대해서 설명한다.
본론으로 들어가기 앞서, 가속화에 익숙하지 않은 분들을 위해서 가속화 시스템이 어떤 일을 하는 것인지 비유적으로 설명해 보겠다.
예를 들어서 우리에게 서울 시티 투어를 안내하는 임무가 주어졌다고 가정해 보자. 서울이란 도시는 클 수도 있고 작을 수도 있고, 인구 밀도가 높을 수도 있고 낮을 수도 있고, 특정한 교통 규칙들이 정해져 있을 수 있다. 이것은 애플리케이션 공간에 해당된다. 여러분은 사람들에게 서울에 대해서 설명하고 일련의 관광지들도 둘러봐야 한다. 이것은 알고리즘에 해당된다.
애플리케이션 공간과 알고리즘이 주어졌으므로, 작은 규모에서부터 시작해 보자. 이 투어는 차량 한 대에 다 들어가는 인원이고, 규모는 점점 더 커지고 있다. 투어가 갈수록 인기를 끌면서 점점 더 많은 사람들이 투어를 신청한다. 하지만 차가 운행할 수 있는 속도 제한이 있다. 그렇다면 어떻게 더 많은 사람을 받을 수 있을까? 이것은 CPU 가속화 문제에 해당된다.
해답은 바로 투어 차량이다. 최대 속도는 더 느리고 사람들을 싣고 내리기 위해서 더 많은 시간이 걸리기는 하더라도 훨씬 더 많은 사람들을 운송할 수 있는 차량이 필요하다. 시간이 지나면서 버스 대수를 늘림으로써 더 많은 사람들이 투어를 즐길 수 있다. 다만 연료 비용이 증가하고, 교통량 증가에 따라 교통 정체가 심해지는 불편은 감수해야 한다. 이것이 GPU 가속화의 기본 모델이다. 훨씬 더 많은 데이터를 전송할 수 있는 것이다.
이때 시 당국에서 모노레일을 깔 수 있도록 승인한다면 어떨까? 열차마다 사람을 가득 태우고 모든 정류장을 들를 수 있다(또 필요에 따라서 경로를 정비하고 변경할 수 있는 유연성이 가능하다). 이것이 투어 가이드에게는 환상처럼 들릴 수도 있을 것이다. 이렇게 할 수 있는 것이 바로 Alveo 가속화이다. FPGA는 GPU의 병렬성과 DSA의 저지연 스트리밍을 결합함으로써 이전에 가능하지 않던 성능을 가능하게 한다.

[그림 1] 자일링스의 CEO인 빅터 팽(XDF2018 사진)

Alveo 개요

Alveo 카드는 크게 세 부분으로 구성된다. 가속화를 하기 위한 강력한 FPGA 또는 ACAP, 고대역폭 DDR4 메모리 뱅크, 고대역폭 PCIe Gen3x16 링크를 통해서 호스트 서버로 연결하기 위한 커넥티비티이다. 이 링크는 Alveo 카드와 호스트 사이에 초당 약 16GiB의 데이터를 전송할 수 있다.
CPU, GPU, ASIC과 달리 FPGA는 실제로 거의 비어 있다. 플립플롭, 게이트, SRAM 같은 일련의 저수준 로직 자원들을 포함하며 고정 기능은 매우 적다. 이러한 자원의 일부를 사용해서 PCIe나 외부 메모리 링크 같은 모든 인터페이스를 구현한다.
PCIe 링크, 시스템 모니터링, 보드 건전성 인터페이스를 호스트 프로세서로 항상 이용할 수 있도록 하기 위해서 Alveo 디자인을 쉘(shell)과 역할(role) 개념 모델로 분할하고 있다. 쉘은 외부 링크, 구성, 클로킹을 비롯한 모든 정적 기능을 포함한다. 역할 부분은 특정한 알고리즘을 구현하기 위한 커스텀 로직으로 채워진다. 그림 2는 이 토폴로지를 보여준다.

[그림 2] Alveo 토폴로지

Alveo FPGA는 다시 다중의 SLR(super logic region)로 나뉜다. 이것은 고성능 디자인 아키텍처에 유용하다. 이에 관해서는 Alveo 개발을 처음 접하는 초보자들이 다루기에 다소 난이도 높은 주제일 수 있으므로 여기서는 그냥 넘어가도록 하겠다.
Alveo 카드는 카드 상으로 다중의 DDR4 메모리를 포함한다. 이들 메모리는 Alveo 디바이스로 고대역폭으로 실행되며, OpenCL에서는 이들 메모리를 집합적으로 디바이스 전역 메모리라고 한다.
각각의 메모리 뱅크는 용량이 16GiB이며 2400MHz DDR로 실행된다. 이 메모리는 대역폭이 매우 높으며, 원한다면 커널을 사용해서 쉽게 포화시킬 수 있다. 하지만 이 메모리로 읽기를 하거나 쓰기를 하기 위해서 지연시간이 발생된다. 특히 액세스하고자 하는 어드레스들이 인접해 있지 않거나 짧은 데이터 비트를 읽고 쓸 때는 더 그렇다.
이에 비해서 PCIe 레인은 대역폭이 꽤 높기는 하나 Alveo 카드 상의 DDR 메모리만큼 높지는 않다. 더욱이 PCIe를 통해서 데이터를 전송하기 위해서 발생되는 지연시간이 상당히 높다. 경험적 원칙으로서, PCIe를 통해서는 데이터를 되도록 자주 전송하지 말아야 한다. 또 연속적인 데이터를 처리할 때, 커널들이 다른 일을 처리하면서 데이터를 전송하도록 설계하는 것이 좋다. 예를 들어서 Alveo가 비디오 프레임을 처리하면서 동시에 CPU로부터 전역 메모리로 다음 프레임을 전송하도록 할 수 있다.

Xilinx Runtime(XRT)과 API

당연한 얘기이지만, 어떤 하드웨어 가속화 시스템이든 두 부분으로 나누어서 설명할 수 있다. 하드웨어 아키텍처 구현과 상호작용하는 소프트웨어이다. Alveo 카드를 사용할 때 어떤 고수준 소프트웨어 프레임워크를 사용하느냐에 상관없이(FFmpeg, GStreamer 등), Alveo 하드웨어와 상호작용하는 소프트웨어 라이브러리는 기본적으로 Xilinx Runtime(XRT)이다.
Alveo 카드 커널을 프로그래밍하기 위해서는 근본적으로 어느 정도 시간이 소요된다. 카드의 FPGA 용량이나 구성 이미지를 전송하기 위해서 사용할 수 있는 PCIe 대역폭 같은 것에 따라서 프로그래밍을 하기 위해서 소요되는 시간은 수십 밀리초부터 수백 밀리초까지 이를 수 있다. 이 일은 애플리케이션을 시작할 때 한 번만 하면 되는 일이므로, 구성에 소요되는 시간을 전체적인 셋업 지연시간 안으로 흡수시킬 수 있다. 하지만 유의할 점이 있다. 어떤 애플리케이션들은 작동 중에 다양한 커널을 제공하기 위해서 Alveo를 여러 번 다시 프로그래밍할 수 있다. 이러한 아키텍처를 구축하고자 할 때는 이러한 구성 시간을 애플리케이션으로 되도록 매끄럽게 통합시켜야 한다. 또 다른 중요한 점은, 다수의 애플리케이션이 Alveo 카드를 동시적으로 사용할 수 있으나 특정 시점에 하나의 이미지만 프로그래밍할 수 있다는 것이다.
XRT의 진가가 발휘되는 때는 메모리를 할당하고 이동할 때이다. 메모리를 효과적으로 할당하고 관리하는 것은 가속화 아키텍처를 개발할 때 중요한 능력 중의 하나이다. 메모리와 메모리 이동을 효율적으로 관리하지 못하면 전반적인 애플리케이션 성능에 바람직하지 않게 영향을 미칠 수 있다. XRT는 메모리와 상호작용할 수 있는 다수의 기능들을 제공한다.
XRT를 사용해서 커널 인자를 설정하고 커널 실행 플로우를 관리함으로써 하드웨어 실행을 관리할 수 있다. 커널은 한 프로세스나 여러 프로세스가 순차적으로나 병렬로 실행할 수 있으며 블로킹이나 논블로킹(non-blocking) 방식으로 실행할 수 있다. 소프트웨어가 커널과 어떻게 상호작용하도록 할지는 전적으로 사용자에게 달렸다.
또 다른 특기할 점은, XRT가 저수준 API라는 점이다. 고급 활용 모델이거나 예외적인 활용 모델의 경우에는 XRT와 직접적으로 상호작용할 수도 있으나, 대부분의 디자인은 OpenCL이나 XMA(Xilinx Media Accelerator) 프레임워크 같은 고수준 API를 사용할 것이다. 그림 3은 상위 수준에서 이용 가능한 API들을 보여준다. 이 글에서는 편의상 OpenCL API를 위주로 설명한다. OpenCL을 사용한 경험이 있으시다면 거의 비슷하다는 것을 알 수 있을 것이다.

[그림 3] XRT 소프트웨어 스택

메모리 할당

CPU로 프로그램을 실행할 때는 하드웨어가 메모리를 어떻게 관리하는지에 대해서 거의 신경을 쓰지 않는 것이 일반적이다. 일부 프로세서 아키텍처는 정렬 등과 관련해서 문제가 있을 수도 있으나, 대부분의 최신 OS와 컴파일러들은 이러한 것들을 추상화함으로써 저수준 드라이버 작업(또는 가속화)을 많이 하지 않는 한은 표면에 드러나지 않는다.
기본적으로 메모리는 여섯 가지 속성으로 구분할 수 있다. 데이터 버퍼로 포인터가 주어졌을 때 이 데이터 포인터가 가상적인 것이거나 물리적인 것일 수 있다. 포인터가 지정하는 메모리가 페이징되어 있거나 물리적으로 연속적일 수 있다. 또 프로세서 관점에서 이 메모리가 캐쉬가 가능한 것이거나 불가능한 것일 수 있다.
대부분의 최신 운영체제는 가상 메모리를 사용한다. 여기에는 많은 이유가 있으나, 이 글은 컴퓨터 아키텍처 교재가 아니므로 한 가지만 기억해야 한다면, XRT는 리눅스로 실행될 가능성이 높고 리눅스는 가상 메모리를 사용한다는 것이다. 그러므로 malloc()나 new 같은 표준적인 C 또는 C++ 사용자공간 API 기능을 사용하면 결국에 물리 메모리 어드레스가 아니라 가상 메모리 어드레스에 대한 포인터를 사용하는 것이다.
페이징된 메모리의 어드레스 블록에 대한 포인터일 수도 있다. 거의 모든 최신 OS(리눅스 포함)는 어드레스 범위를 페이지로 구분하며, 통상적인 페이지 크기는 4KiB이다. 그런 다음 각각의 페이지를 물리 메모리의 해당 페이지로 맵핑한다.
두 가지 것을 기억해야 한다. 첫째, 표준적 C API를 사용해서 버퍼를 할당하면 도로 물리 메모리 어드레스를 얻는 것이 아니다. 둘째, 단일 버퍼가 아니라 각기 4KiB 길이의 N개의 메모리 페이지 모음을 얻는다. 예를 들어서 6MiB 버퍼를 할당한다고 하자. 그러면 다음과 같다:

이 전체적인 6MiB 버퍼를 호스트에서 Alveo 카드로 복제하려면 1536개의 가상 페이지 어드레스를 물리 메모리 어드레스로 바꿔야 한다. 이들 물리 어드레스를 스캐터 개더 리스트로 만들어서 스캐터 개더 기능이 있는 DMA 엔진의 대기행렬에 더해야 한다. 그러면 이 엔진이 이들 페이지를 하나씩 목적지로 복제한다. 이것을 역으로 해서 버퍼를 Alveo에서 호스트 메모리의 페이징된 가상 어드레스 범위로 복제할 수도 있다. 호스트 프로세서는 대체로 꽤 빠르기 때문에 이 리스트를 빌드하기 위해서 그렇게 많은 시간이 걸리지 않는다. 하지만 상당히 큰 버퍼라고 한다면 이 시간이 전체적인 시스템 지연시간을 증가시킬 수 있으므로, 이 작업이 전반적인 시스템 성능으로 어떻게 영향을 미칠지 이해하는 것이 필요하다.
그림 4는 이러한 시스템 예를 보여준다. 이 예에서는 A와 B라고 하는 2개의 버퍼를 사용하고 있다. A와 B 둘 다 가상 버퍼이다. A를 Alveo로 전송하고, B 버퍼를 업데이트하는 어떤 작업을 하고, 다시 전송하고 있다. 그림을 보면 가상 대 물리 맵핑이 어떻게 작용하는지 알 수 있다. Alveo 카드 안에서 가속화기는 물리 메모리 어드레스들로만 실행되며 데이터는 항상 인접하게 저장된다. 대개의 경우에 이 구성이 성능을 극대화할 수 있기 때문이다.

[그림 4] Alveo로 가상 메모리 전송

그림에서 보듯이, 개략적인 데이터 플로우만으로도 이미 꽤 복잡하다는 것을 알 수 있다. 이번에는 상당히 큰 버퍼라고 하자. 크기가 수 메가바이트(혹은 기가바이트)에 달하고 수천 개의 페이지로 이루어졌다. 아무리 빠른 호스트 프로세서라고 하더라도 이러한 스캐터 개더 리스트를 구축 및 관리하고 페이지 테이블을 관리하기 위해서는 상당한 시간이 소요될 것이다. 실제로는 메모리가 이 예에서 보는 것처럼 그렇게 분리되어 있지 않다. 하지만 페이지들의 물리 어드레스를 미리 알지 못하므로 페이지들을 따로따로 다루어야 한다.
모든 페이지들이 물리 메모리로 인접해 있다는 것을 안다면 스캐터 개더 리스트를 훨씬 쉽게 빌드할 수 있다. 다시 말해서 데이터 바이트가 순차적이므로 물리 어드레스를 증가시켜서 데이터를 취할 수 있다[n+1]. 이러한 경우에는 버퍼의 시작 어드레스와 크기만 알면 스캐터 개더 리스트를 구축할 수 있다.
이것이 단지 Alveo와 DMA뿐만 아니고 많은 DMA 동작의 장점이다. 최신 운영체제는 이러한 용도로 메모리 할당을 제공한다(통상적으로 커널 서비스를 통함). 리눅스에서는 CMA 서브시스템을 통해서 이루어진다. 이것은 커널 공간 기능인데, DMABUF, XRT API, 그래픽 드라이버 같은 다양한 메커니즘을 통해서 사용자에게 노출된다. 앞서의 버퍼를 인접하게 할당하면 그림 5에서 보듯이 훨씬 간소화할 수 있다.

[그림 5] Alveo로 가상 메모리 전송

만약에 버퍼가 딱 4k 페이지 경계에서 시작하지 않으면 어떻게 될까? DMA 엔진은 어느 정도의 정렬을 필요로 하며, Alveo DMA도 다르지 않다. 할당된 메모리가 페이지 경계에 정렬되어 있지 않으면 런타임이 알아서 정렬을 한다. 다만 memcpy() 동작이 발생되고, 이 동작을 하기 위해서는 연산을 많이 필요로 한다. 또 런타임으로부터 경고가 뜰 것이다(이 기능을 끄지만 않았다면). 이것은 되도록 신속하게 해결해야 할 문제이기 때문이다.
끝으로는, 메모리가 캐쉬가 가능한지 아니면 불가능한지 알아야 한다. 외부 메모리를 액세스하기 위해서는 “비용”이 들기 때문에 거의 모든 최신 프로세서는 내부적인 데이터 캐시를 사용해서 지연시간을 낮춘다.
프로세서 아키텍처에 따라서 캐시 크기는 수십 킬로바이트에서 수 메가바이트까지 이를 수 있다. 이러한 내부적 캐시 메모리는 필요에 따라 외부적 물리 메모리와 동기화할 수 있다. 통상적으로 이러한 캐시 관리는 프로세서로 실행되는 소프트웨어에 투명하게 이루어진다. 실행 시간이 향상되는 것으로서 캐시의 유용성을 확인할 수 있다. 일반적인 개발 차원에서 캐시와 상호작용할 필요는 없다.
DMA를 사용할 때 유의할 점은, 프로세서가 가속화기와 공유하고자 하는 데이터를 외부 메모리와 동기화한 후에 전송해야 한다는 것이다. DMA 전송을 하기에 앞서 캐시에 들어 있는 데이터를 외부 메모리로 비워야 한다. 마찬가지로 데이터가 전송되었을 때는 캐시에 들어 있는 데이터를 무효화해서 외부 메모리로부터 리프레시해야 한다. 이 동작은 x86 기반 프로세서로 매우 빠르게 실행되며 런타임에 의해서 투명하게 처리된다.
하지만 다른 아키텍처는 캐시 관리를 위해서 성능 측면에서 불리해질 수 있다. 이 문제를 완화하기 위해서 API로 캐시 불가능 버퍼를 할당하고 사용하기 위한 기능을 포함한다. 다만 염두에 둘 점은, 프로세서가 캐시 불가능 버퍼로 데이터를 액세스하기 위해서는 캐시 관리 동작을 실행하는 것보다 속도가 훨씬 느려질 수 있다는 것이다. 이것은 프로세서가 버퍼를 시퀀싱하기는 하는데 여기에 들어 있는 데이터를 실제로 액세스하지는 않는 모델에 주로 사용된다.

하드웨어 디자인 셋업

이 글에서는 Alveo 카드를 사용한 가속화에 대해서 설명하고 있다. 그러기 위해서는 FPGA를 프로그래밍하고 메모리를 할당하고 메모리를 이동시키기 위해서 호스트 코드를 작성해야 한다. 이들 초보적인 디자인 예제는 매우 단순한 가속기들이다. 가속화 하드웨어가 매우 단순하므로 CPU로 알고리즘이 빠르게 실행될 것이다.
하드웨어 디자인을 빌드하기 위해서도 상당한 시간이 소요된다. 나노초 미만의 타이밍으로 수십억 개의 트랜지스터들로 커스텀 로직을 합성하고 배치하고 배선하는 것은 머신 코드로 컴파일링하는 것보다 좀 더 복잡하다. 불필요하게 FPGA 하드웨어를 다시 구축할 필요가 없도록 하기 위해서 Xilinx는 다수의 커널 사례들을 포함하는 단일 FPGA 디자인을 제공한다. 이것들을 필요에 따라서 조합할 수 있다.

Alveo는 매우 표준적이고 완벽한 제품으로 현재 16nm Ultrascale+ Virtex에 기반한 것이다. 이 제품에는 세 가지 장점이 있다. 첫 번째 매우 빠르다. 심지어 서버 기반의 CPU보다도 빠르다. Twitch가 16nm 아마존 클라우드를 기반으로 했을 때 10-30배 빨라졌다는 것이 이것이다. 두 번째로 어댑터블하다. 개발에 대해선 걱정할 필요가 없다. 애플리케이션이나 머신러닝을 위해서 이 제품을 사용할 수도 있다. 여러 네트워크에도 사용 가능하며 변경도 가능하다. 그리고 셋째 다루기 쉬운 플랫폼이라는 점이다. 쉘을 적용하고 보드를 디자인했으며 열관리 소자와 S/W 등 모든 것을 넣었다.
더 쉽게 할 수 있도록 에코 시스템 작업도 진행 중이다. 정리해보면 최고의 가속기이며 매우 다루기 쉬운 추가적인 작업이 필요 없는 플랫폼이라고 할 수가 있다. Alveo의 중요한 특징 중 하나는 에코시스템도 같이 존재할 것이라는 점이다. 데이터베이스, 데이터 분석 가속, 영상처리, 금융서비스, 머신러닝 등 다양한 애플리케이션 등이 지원될 것이다.