Meta의 추천 모델 deployment 방법 (논문: First-Generation Inference Accelerator Deployment at Facebook)

이전 블로그에 소개했 듯, Meta의 AI 추론 사이클 중 80%가 추천 모델을 서빙하는데 사용된고 있다. Meta의 First-Generation Inference Accelerator Deployment at Facebook (’21) 논문을 통해 실제 Meta가 추천 모델을 어떻게 deployment 하는지 살펴보았다.

[리뷰] Meta의 Supporting Massive DLRM inference through Soft Defined Memory

Meta의 1st 추론 가속기

Meta가 추론 가속기를 자체 디자인한 이유

• Meta는 추론 시 CPU를 사용하였으나 2년 동안 ML 추론에 사용되는 서버의 수가 5~7x 증가함
• Meta의 NLP 모델은 현재 배포된 것보다 300x 더 큰 모델이 개발되고 있을 정도로 앞으로 Meta가 사용하는 모델의 FLOPs와 모델 사이즈가 복잡해질 예정
• CPU가 이러한 복잡한 모델을 추론하는 것은 latency budget 상 어려움
• 결과적으로 Meta는 latency와 throughput 요구사항을 충족하는 추론 가속기를 자체 디자인함

Meta의 추론 가속기 요구사항

• 높은 perf/watt
• 대용량 추천 시스템 모델 (빠른 lookup을 위한 대용량 메모리 & 높은 BW)
• 빠르게 진화하는 ML 프레임워크 환경에 적응할 수 있어야 함 (e.g. Caffe2 → Pytorch)

Meta의 1st 추론 시스템 & 가속기 overview

• Meta는 위의 추론 가속기 요구사항을 만족시키기 위한 추론 시스템을 HW/SW co-design함
• Meta의 추론 시스템은 메모리 용량, 메모리 BW, 컴퓨팅 기능을 확장하기 위해 PCIe 스위치를 통해 6개 추론 가속기 카드를 연결함
• Multi-card 파티셔닝 전략을 사용하면 대규모 추천 시스템 워크로드를 처리할 수 있을 만큼 충분히 큼
• HW peak 효율은 2.0~3.0 TOPS/W임
• 각 카드는 x4 PCIe로 연결
• CV & 추천 모델의 compute layer를 저장할수 있도록 수십 MB의 on-chip memory를 보유함

추천 모델의 특징

• 100B 이상의 파라미터 (매우 큰 임베딩)
• MLP는 상대적으로 적은 weight (수십 M 파라미터)
• 상대적으로 낮은 arithmetic intensity: 80~90 ops/byte
• on-chip memory에 weight를 저장하면 큰 이점을 얻을 수 있음
• 추천 모델의 임베딩 lookup 결과가 한 곳에 모여야 하므로 분산 방식으로 처리될 수 없음

Accuracy 요구사항

• offline accuracy metric을 사용함: NE (Normalized cross Entropy)
• FP32와 비교하여 low precision 모델을 사용한 경우, 최대 NE 허용 오차(degradation tolerance): 0.02% ~ 0.05%
• 추천 모델은 주기적으로 자주 업데이트되어야 하므로 수동 개입이 필요없는 robust quantization 워크플로우가 필수적임
• 모든 경우에 INT8 quantization에 의존하기 어려움. 합리적으로 높은 FP16 연산 throughput이 중요함

Quantization 워크플로우

quantization은 accuracy loss의 원인이 되므로 계산량이 많은 연산자에만 quantization을 적용함. 다음은 추론을 위한 quantization 워크로우임

1) 성능 프로파일링

• E2E 추론 연산 중 top bottleneck을 일으키는 연산자를 식별 후 quantization이 필요한 연산자의 순위를 매김.

2) 애플리케이션 수준 요구사항을 만족시키는 Precision 탐색

• E2E accuracy가 애플리케이션 수준 요구사항을 만족할 때까지 반복적으로 mixed precision(e.g. INT4, INT8, FP16)을 가지는 모델을 탐색함.
• 레이어별 quantization error를 피드백으로 사용하여 높은 quantization error가 발생하면 연산을 위한 precision을 올리는 방식을 사용함
• 추천 시스템은 FC(Fully-Connected)와 SLS(Sparse Length Sum) 연산자가 대부분의 추론 latency를 차지함
• 최신 추천 시스템의 임베딩 테이블은 100GB 이상의 파라미터를 포함함.
• 임베딩 테이블에 INT8과 INT4의 Mxied precision를 사용하면 accuracy를 손상시키지 않으면서 메모리 용량고 모델 크기를 크게 줄일 수 있음
• SLS 연산자는 accuracy loss 없이 벡터 코어의 FP16에서도 수행할 수 있음
• FC 연산자는 가능한 많은 연산에 대해 INT8 quantization을 이용하지만 quantization error이 너무 높으면 FP16으로 돌려놓음
• 0.05% NE threshold 이내 요구사항을 만족시키기 위해서 보통 마지막 FC를 포함한 약간의 FC를 스킵함

성능 최적화

1) Model 수준 최적화

1–1) quantization & 데이터 타입 변경

• INT8 quantization
• 추천모델의 입력 dense feature를 FP32 → FP16으로 변환

1–2) 네트워크 최적화

• Host와 가속기 간의 PCIe 전송 시간을 줄이도록 분할
• CPU 시스템은 가속기 시스템보다 짧은 latency의 작은 작업을 실행
• 가속기에 할당된 네트워크 부분은 컴퓨팅의 대부분을 포함해야 하며 가속기가 지원하는 연산이어야 함
• 네트워크 전송 시간은 종단 간 latency의 중요한 구성 요소이기 때문에 네트워크 대역폭과 대기 시간을 최소화

2) Card-side 최적화

2–1) 모델 분할

• 추천 모델은 너무 커서 6개의 카드에 분할
• Model parallelism을 사용하여 가속기 카드 전체에 sparse 임베딩 lookup 테이블을 배포하고 data parallelism를 사용하여 가속기 카드 전체에 dense compute를 병렬화
• Accel Cores의 일부분은 sparse lookup에 할당하고 나머지는 dense compute에 할당함

2–2) 리소스 할당

• 모델을 분할시킨 추천 모델의 경우, 한 가속기 카드에서 여러 파티션이 동시에 실행됨
• 이런 경우, 런타임의 균형을 맞추기 위해 각 파티션에 할당할 Accel Core 수를 결정해야 함
• 일반적으로 SLS에 코어의 1/3을 사용하는 것이 좋은 밸런싱임

2–3) Accel. Core의 병렬화 및 배치

• Compute graph가 모든 accel. cores에서 실행하지 못할 만큼 충분히 독립적이지 않다면, graph에 필요한 병렬화를 생성하기 위해 graph의 작업을 분할해야함
• 노드가 병렬화되면 프로파일링을 통해 Glow에 내장된 배치 hint API를 사용하여 Accel Core에서 명시적으로 노드를 스케줄링할 수 있음
• 명시적 batch로 추천모델의 성능 향상은 10~20%를 초과하지 않음

2–4) Sparse Lookups 최적화

• SLS의 실행 latency는 임베딩 테이블 lookup의 개수에 의존함
• 내부 성능 모델링 프레임워크를 사용하여 임베딩 테이블 조회의 평균 수를 추정하고, 모델의 정보에 주석을 달고, 컴파일 시간에 이 정보를 사용하여 SLS operator를 카드 내의 여러 코어와 여러 카드에 걸쳐 로드 밸런싱
• SLS 파티션 latency를 약 15%-34% 감소시킴

3) 시스템수준 최적화

3–1) 부분적 텐서 전송

• PCIe 트래픽을 크게 줄이기 위해 “부분 텐서”만 전송하는 기능을 추가함 (실제 사용되는 텐서만 전송함)

3–2) Command Batching

• 추천 모델은 많고 작은 독립적인 입력으로 구성되어 전송 overhead가 발생함
• 이를 극복하기 위해 Command Batching을 사용하여 많고 작은 전송을 하나의 큰 전송으로 결합함

3–3) 전송을 위한 host 중개자 제거

• 디바이스 상주 텐서 및 P2P 텐서 전송에 대한 지원을 추가하여 디바이스 간 텐서 통신에서 Host를 제거하고 PCIe 전송을 절반 이상 감소시킴

추천 모델의 실험 결과

추천 시스템 모델은 컨텐츠 이해 모델(CV/NLP)에 비해 배치당 더 낮은 latency와 higher QPS로 실행됨

• 추천은 배치당 수십 ms의 latency를 요구하므로 이 엄격한 latency 요구사항과 모델의 복잡한 특성을 감안했을 때 추천 모델을 CPU에서 추론하는 것은 쉽지 않거나 효율적으로 실행되지 않음
• 추천 모델은 FC 연산의 비율(30.9%)과 SLS 연산의 비율(27.%)를 합하면 런타임 시, 두 연산의 비중이 거의 60%를 차지함

미래 AI 워크로드를 위한 추론 HW design 방향성

더 커진 모델 (Much larger models)

• Meta의 추론 시스템은 추천 모델의 큰 임베딩 테이블을 지원하기 위해 디자인됨
• 하지만 추천 및 CV/NLP 모델의 크기가 지속적으로 커지고 있으므로 6개 accelerator card의 96GB으론 부족할 수 있음
• 이를 해결하기 위해 hierarchical storage를 고려하는 것이 필요함. → Local LPDDR + Large-Capacity Persistent Memory(e.g. NVM)
• NVM은 더 높은 endurance (> 60 pDWPD)때문에 FLASH보다 serving에 더 좋음

더 복잡한 모델 (More complex models)

• 추천 모델은 arithmetic intensity가 크게 변하지 않는 반면, FLOPs는 점점 커질 것임
• 배치를 늘리면 arithmetic intensity를 개선할 수 있지만 serving latency의 제약에 걸리게 됨
• 모델이 커질수록, 성능은 on-chip SRAM이 weight와 activation을 둘다 수용하기엔 부족하므로 DRAM BW이 제약으로 작용함
• 이와 같은 문제는 개별적인 FC 레이어를 분할하여 각 accelerator의 subsets에 실행시키는 model parallelism(FC sharding, FC pipeline parallelism)을 사용하여 SRAM에 더 많은 weight를 유지할 수 있도록 하여 BW bottleneck 문제를 경감시킴
• 연산을 매핑하는 것이 더 복잡해지므로 모델 아키텍처를 accelerator 친화적으로 설계하는 것이 필요함
• 또한 현재 모델의 세부사항에 대해 accelerator를 과도하게 최적화하지 말고 장기적인 추세를 보는 것이 중요함

수치 지원(Numerical support)

• 엄격한 accuracy 요구사항 및 자주 업데이트되는 추천 모델의 경우 모든 모델과 모든 compute-intensive 파트가 low precision의 정수 연산으로 실행될 수 있다고 기대해서는 안됨
• FP16 compute throughput 지원이 없으면 accelerator의 사용성이 크게 저해됨
• 동적 quantization은 정확도를 개선하고 activation 텐서값 분포를 프로파일링하는 것이 필요한 정적 quantization의 복잡성을 피할 수 있는 기술임을 발견함
• 학습 하드웨어가 BF16을 지원하므로 추론 accelerator 또한 BF16을 지원하는 것이 유용함

Sparsity의 중요성

• Pruning은 추천과 CV/NLP 모두에 유용한 기술임
• 이를 위해선 sparsity를 위한 전문적인 HW 지원이 필요함.
• Arithmetic operations을 줄이는 것보다 메모리 & on-chip 메모리 용량과 대역폭을 sparsity로 줄이는 것이 더 쉬움

임베딩 테이블 압축

• 압축 기술은 임베딩 테이블 크기의 증가를 완화하는데 중요하며 programmability가 중요한 또다른 영역임
• 몇년전 accelerator 시스템을 설계할 때, 4bit quantization이나 row-wise pruning을 예상하지 못했으나 programmable vector core는 이들 압축 기술들을 지원할 수 있었음

레퍼런스

[1] First-Generation Inference Accelerator Deployment at Facebook

First-Generation Inference Accelerator Deployment at Facebook