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

Meta의 Compute Footprint & Energy Footprint

Meta의 AI System capacity는 지난 18개월 만에 AI training은 2.9배, AI inference는 2.5배 가량 증가하였다. 특히 Meta의 recommendation 모델은 AI training의 50%와 AI inference의 80%를 차지할만큼 중요도가 높다.

AI serving에 가장 중요한 요소 중의 하나는 power budget이다. 데이터센터에서 공급할 수 있는 power는 한계가 있으며 power 한계 이상의 power를 요구할 때 더이상 서버의 확충이 어렵게 되어 AI serving이 어렵게 된다.ㅏ

아래 그림은 MS, Google, Meta의 Energy Footprint를 보여준다. 특이한 점은 Meta의 Energy Footprint 증가량이 MS와 Google에 비해 훨씬 더 높다는 것이다. 따라서 Meta은 AI serving의 대부분을 차지하는 Recommendation 모델(DLRM)의 power 소모를 줄이는 것이 절실한 상황이다.

Ref: How Facebook/Meta Design Sustainable Datacenters with AI

Meta는 이와 같은 상황을 개선하기 위해 Supporting Massive DLRM inference through Soft Defined Memory(‘21/11) 논문를 통해 DLRM inference 시 임베딩을 SCM(Storage Class Memory)과 같은 Soft Defined Memory(SDM)에 저장하여 power를 줄이는 방식을 제안하였다.

DLRM Inference Overview

DLRM(Deep Learning Recommendation Model)은 Meta의 추천모델로 추천모델 중 가장 잘 알려진 모델이다. DLRM은 MLP와 임베딩 테이블로 구성되어 있으며 trillion-scale의 모델 사이즈를 갖는다. 이와 같이 모델 사이즈가 큰 이유는 임베딩 테이블로 표현되는 sparse features가 더 클수록 더 좋은 모델 품질을 제공하기 때문이다.

따라서 임베딩 테이블이 DLRM의 모델 사이즈의 대부분을 차지하며 모델 serving 시 수백 GB의 메모리가 필요하다. 하지만 DRAM은 비싸므로 serving에 많은 비용이 요구된다.

하나 다행인 것은 모든 임베딩 테이블이 동일한 메모리 BW를 요구하지 않는다는 점이다. DLRM은 item 임베딩과 user 임베딩을 포함하는데 두 임베딩의 BW 요구량은 다음과 같다.

• item 임베딩: high BW@small capacity
• user 임베딩: low BW@large capacity

따라서 기존 HBM(device)+DRAM(host)와 같은 시스템 형상에 SCM(Storage Class Memory)와 같은 SM(Slower Memory)를 추가하여 HBM+DRAM+SCM와 같은 메모리 계층구조를 DLRM serving에 활용한다면 더 값 싸고 더 적은 power로 serving이 가능할 것이다.

Serving 시 수십 Mega-Watts를 절약할 수 있다는 것은 tier-memory를 활용하는 것이 더 매력적으로 작용하고 있다. 하지만 latency, BW 요구량, access granularity는 tier-memory의 challenge로 작용한다.

이 논문은 contribution은 다음과 같다.

SCM(Nand Flash, Optane SSD)를 이용하여 DLRM의 가용 메모리를 확장

NVMe 디바이스에 대해 read access를 dword까지 더 작은 단위로 활성화하여 read amplification을 방지

가능한한 dequantization과 pooling를 우회하여 성능 개선을 위해 pooling 된 임베딩 캐시를 평가하며, 가능한한 더 높은 성능을 얻기 위한 SM 용량의 trade-off 범위를 고려함

Realistic warehouse 규모의 배포 시나리오에서 각 솔루션의 부가가치를 논의

DLRM의 Background

DLRM Architecture

DLRM은 두가지 주요 컴포넌트로 구성되어 있다.

임베딩(Embedding)

• 임베딩은 categorical features(e.g. 사용자가 관심을 보이는 주제)를 dense representation으로 매핑하는데 활용됨
• 임베딩은 user 임베딩(사용자를 위한 categorical features의 형태를 부여)과 item 임베딩(뉴스와 영화와 같이 추천 항목에 대한 categorical feature의 형태를 부여)로 나뉨
• 임베딩은 일반적으로 memory-intensive함

상호작용(Interaction)

• Continuous features과 categorical features의 dense representation을 집계하고 복잡한 상호작용(e.g. MLP)을 캡처함
• 상호작용은 일반적으로 compute-intensive함

BW & Capacity 요구사항

서두에서 user 임베딩의 요구 메모리 BW가 낮다라고 설명하였다. 그 이유는 다음과 같다.

• 추론시 여러 item들이 추천를 위한 top item에 도달하기 위해 평가된다. 추론 query는 해당 사용자당 user 임베딩을 한번 접근하는 반면, item 배치 당 item 임베딩을 접근한다. User 임베딩 결과는 Top MLP 계산을 위한 모든 item에 broadcast 될 수 있다.
• 결과적으로 user 임베딩을 위한 query당 BW 요구량은 item 임베딩의 query당 요구량보다 훨씬 더 낮다.

관찰 #1. user 임베딩은 DLRM 모델 용량의 2/3를 차지한다. 이는 사용자를 설명하는 categorical features이 더 광범위하기 때문에 모델에 사용되는 user 임베딩이 더 많아지는 결과를 낳는다.이 것은 모델 사이즈의 더 많은 부분이 더 낮은 BW 요구하는 것을 암시한다.

관찰 #2. user 임베딩과 item 임베딩은 독립적으로 실행되는 반면, Top MLP는 둘다 의존한다는 것이다. 따라서 user 임베딩의 access 시간이 item 임베딩의 acess 시간보다 작기만 한다면 user 임베딩은 SM에 수용할 수 있는 첫번째 후보군이다.

Hyper-Scale Depolyment

Latency & Throughput

• DLRM 추론은 latency & throughput 모두에 민감하다.
• Latency 민감도는 실시간 사용자 상호작용에서 파생되며, ranking을 위한 위해 수십 ms 범위의 latency가 요구된다.
• 동시에 데이터센터 수준의 query는 예상 throughput 내에서 처리되어야 한다. 주어진 목표 latency에서 host 당 QPS가 주어지면 총 throughput (e.g. DC 지역)은 host의 수로 변환된다.
• latency 요구사항은 모델/usecase에 따라 다르다.

Scale Up vs Scale Out

• 모델 사이즈가 커지면 host 당 메모리를 증가시키던지(scale up), multi-host로 메모리를 확장하여 모델을 쪼개는(scale out) 방법을 사용해야 한다.
• 모델 크기의 증가는 모델의 compute intensity 증가를 동반한다. 모델을 serving하기 위해선 compute, memory BW, memory 용량 요구사항과 그들의 비율에 의존한다.

Power Boundness

• 데이터센터가 새로 건립되는 속도보다 DLRM의 복잡도와 사이즈가 더 빨리 증가하고 있다. 게다가 infrastructure 리소스의 상당한 비중을 차지한다.
• 따라서 DLRM을 scale할 때 허용가능한 latency 에서 query/watt를 유지해야 하므로 power boundness가 존재한다. (데이터센터의 power boundness 내에서 infrastructure 리소스를 증가시키려면 querey/watt를 낮게 유지하는 것이 중요하다.)

TCO (Total Cost of Ownership)

• GB 당 더 싼 메모리는 전체 TCO를 줄인다.
• 게다가 host 당 더 많은 메모리 용량을 늘리는 것(scale up)은 항상 가능한 것이 아니므로 tiered memory 또는 scaling out 솔루션이 요구될 수 있다.

Technology

메모리 계층을 SCM으로 확장하는 것은 가속기의 선택 (e.g. 추론용 GPU) 및 더 빠른 메모리(e.g. HBM + DRAM)의 계층과 관계없이 배포될 수 있다. 이 논문에서 SCM은 SM(Slow Memory)으로 HBM+DRAM은 FM(Fast Memory)로 언급한다.

SM 기술 및 key 파라미터

SM을 위해 사용될 수 있는 기술은 아래와 같이 5가지이다.

• PCIe Nand Flash
• PCIe 3DXP(optane)
• PCIe ZSSD
• DIMM 3DXP(optane)
• CXL 3DXP

각 기술별 key 파라미터는 다음과 같다.

• IOPS(IO Per Second): 임베딩 테이블에 접근 패턴은 랜덤이므로 GB/s 대신 IOPS를 추적한다.
• Access Granualrity: 양자화된 임베딩 row는 128~256B 범위 내에 있다. 더 높은 granularity (e.g. 4KB)로 IO read하는 것은 read amplification과 BW 낭비를 초래한다.
• Latency: 데이터 블럭을 로드하는데 걸리는 access 시간으로 로드가 낮을 때부터 높을 때까지 증가할수록 SM 기술마다 다른 커브를 보인다.
• Write BW: 모델 업데이트 시에만 write access가 발생한다.
• Endurance: 모델 업데이트 interval로 계산할 수 있다.
• Cost: DDR4 DRAM에 비해 GB 당 상대적인 cost를 의미한다.
• Sourcing: 얼마나 많은 벤더가 그 기술을 제공할 수 있는지? 더 높을수록 좋다.

SM 기술별 장/단점 분석

SM을 위한 기술 선택은 특정 usecase 및 모델 특성에 따라 다릅니다. 모델의 사이즈와 BW가 scale 되면 더 높은 BW 옵션이 더 의미가 있다. Nand Flash 및 Optane SSD는 다양한 DLRM 모델에 대해 계층화된 메모리를 지원한다. 모델의 용량과 BW가 scale 되면 CXL기반 솔루션의 관련성이 높아진다.

Nand Flash

• 장점: 1) 가장 싸고 2) 가장 많은 벤더가 제공하고 있음
• 단점: 1) 낮은 random IOPS, 2) IOPS가 증가할수록 latency가 증가함

PCIe 3DXP(Optane)

• 장점: 1) 좋은 random IOPS(4M@512B) 2) Nand Flash대비 더 좋은 latency 3) endurance로 잦은 업데이트를 수용하기 충분히 높음
• 높은 용량과 BW 요구사항에 대응할 수 있음

PCIe ZSSD

• 장점: 1) Flash Nand에 비해 더 좋은 latency
• 단점: 1) Flash Nand를 능가할 정도의 IOPS를 제공하지 않음

DIMM 3DXP

• CPU에 가용 메모리의 BW에 영향을 준다.

CXL 3DXP

• DIMM 3DXP의 부정적인 효과없이 가장 좋은 성능을 제공하지만 아직까지는 다른 기술만큼 준비되지 않는 기술이다.

Design & Implementation

Fast I/O

모델의 BW 요구사항이 커질수록 IOPS 요구사항도 결과적으로 커진다. 그러나 NVMe 스택을 통한 IO은 여전히 비싼 operation이다. 수 백만 IOPS를 수행하는 것은 엄청나게 많은 양의 컴퓨팅 리소스(CPU)를 요구한다. Meta는 IO 당 더 적은 overhead 덕분에 io-uring을 사용한다. 애플리케이션-수준 캐시로 mmap vs Direct-IO 중에서 Direct-IO을 선택한다.

NAND Flash의 경우, 최대 미처리된 requests를 제한하여 bursts를 스무하게 하는 것이 필요하다. 왜냐하면 SSD 컨트롤러는 일반적으로 추가 latency를 초래하는 가능한 모든 미처리 requests를 처리하려고 한다.

Tuning API

• 주어진 시간내 처리될 수 있는 임베딩 테이블 당 미처리 IOs의 총 개수
• 주어진 시간내 처리될 수 있는 임베딩 테이블의 총 개수

Sub-Block(e.g. 4KB) reads는 일반적으로 OS에 의해 지원되지 않는다. Spacial Locality 부족으로 인해 SCM 디바이스에 더 높은 access granularity는 3가지 부정적인 의미를 갖는다.

1. 더 많은 데이터를 Device → Host로 전송해야 하므로 Read Amplication(읽기 증폭)으로 인해 더 높은 latency
2. 시스템의 상호 연결(PCIe)에 대한 더 많은 압력으로 인해 더 많은 lane을 프로비저닝을 요구함 → 시스템 전력 및 비용이 증가함
3. 블럭 데이터에서 row 데이터를 추출 후 캐시에 복사하는 것을 처리하기 위해 추가 메모리 복사가 필요함

추론 시 대부분의 테이블은 512B 보다 작은 임베딩 dimension을 갖기 때문에 NVMe의 arbitrary access granularity를 DWORD로 내려야 한다. 이 목표를 달성하기 위해 2가지 방식이 있다.

1. 리눅스 커널: 4B 단위까지 읽기를 허용하는 io-uring(Axboe) 애플리케이션 전송 위로 custom command가 허용되도록 리눅스 커널을 업데이트함
2. NVMe Driver: NVMe Scatter Gather List(SGL) Bit Bucket이 block의 원하는 부분을 통신하기 위해 사용된다. 이를 통해 PCIe 상으로 read가 필요한 부분만 전달이 가능함

Block의 필요한 부분만 읽기가 가능해져 BUS BW의 75%이 절감되며 전송에 필요한 시간이 3~5%까지 줄어든다.

Locality

(작성 중)

Cache Organization

(작성 중)

Pooled Embedding Cache

(작성 중)

SM vs FM capacity Traff-off

추론 시 모델 사이즈를 줄이기 위해 임베딩 테이블을 pruning하는 것은 일반적으로 사용되는 방식이다. 0에 매우 근접한 임베딩 row는 경험적으로 제거된다. unpruned space에 있는 인덱스들을 pruned space로 매핑하기 위해 새로운 텐서가 정의된다. 매핑 텐서의 크기는 다음과 같다.

NumRow(Unpruned)*IdxType : IdxType = {4,8} Bytes

SM에 pruned 임베딩 테이블을 저장하기 위한 방법은 다음과 같다.

Option-1. Pruned 임베딩 테이블과 매핑 텐서를 SM에 저장하고 임베딩을 lookup할 때마다 2번 접근한다.

Option-2. SM에 pruned 임베딩 테이블을 저장하고 FM에 매핑 텐서를 유지한다.

SM이 갖는 IOPS boundness와 상대적으로 작은 크기의 매핑 텐서를 고려하였을 때 Option-2가 더 바람직한 선택이다. 그러나 모델 사이즈가 증가하면 매핑 텐서의 총 크기 또한 증가한다. 매핑 텐서가 차지하는 공간은 SM 캐시가 사용할 수 없는 공간이다.

매핑 텐서에 의해 사용 중인 메모리를 해제하기 위해 로딩 시간에 임베딩을 de-pruning할 수 있다. 알고리즘 2는 de-pruning 방법을 설명한다.

SM에 모델 footprint 증가 외에도 de-pruning은 SM의 추가적인 접근으로 이어져 결과적으로 cache 오염까지 일으킨다. 이것은 pruned 임베딩은 접근되어지고 캐시되기 때문이다. 하지만 직관은 pruned 임베딩 또한 덜 자주 접근되어지므로 그 영향이 최소화된다는 것이다.

관찰1. 총 requests가 2.5% 증가하였을 때, 실제로 일부 구성에서는 최대 2x cache size를 허용한다.

관찰2. SM에 있는 user 임베딩에 의해 성능이 제한되는 경우에도 성능이 48%까지 증가하는 것을 볼 수 있었다.

실험 셋업 & 결과

Meta는 3가지 다른 특성을 가지 모델을 사용하였다. (M1~M3)

다음은 M1~M3 모델을 평가하기 위한 HW 플랫폼 셋으로 usecase 특성 및 요구사항에 따라 HW 플랫폼을 선택하였다.

결과적으로 다음과 같이 5%~29%의 전력 절감 효과를 확인하였다.

1. 더 간단한 HW(e.g. Nand Flash) 사용할 경우, 20% 전력 절감
2. Scale-out 방지로 컴퓨팅이 많은 다른 모델을 사용할 경우, 5% 전력 절감
3. Multi-tenancy를 통해 가속기의 활용도를 높이는 경우, perf./watt 29% 절감

결과 #1: 더 간단한 HW 사용하기 (M1 + HW-SS_SDM)

타겟 모델 M1을 위해 SM을 사용하는 것은 모델을 서비스하기 위해 host당 DRAM 용량 요구량을 줄일 수 있다.

• HW-L 대비 HW-SS는 원하는 latency에서 더 낮는 QPS를 유지한다.
• SSD를 사용하는 HW-SS는 더 유리한 compute 대 DRAM 비율은 20% 더 낮은 전력 소비로 이어진다.
• 모델에 필요한 IOPS@120 QPS는 약 246K(120 QPS × 50 Tables× 42 avgP F)이다. 전체 모델 업데이트 후 몇 분 이내에 도달하는 정상 상태에서 cache hit rate가 96% 이상임을 관찰하였다.
• Nnad Flash의 long-tail latency로 인해 HW-SS에서 더 높은 p99 latency을 관찰하지만 HW-SS의 관심 metric은 p95이다.
• HW-SS를 사용하면 159.4TB의 DRAM을 절약할 수 있다.

결과 #2: Scale-out 피하기 (M2 + HW-AN_SDM or HW-AO_SDM)

M2는 더 높은 compute-intensity 때문에 가속기를 사용하며(HW-AN), 모델의 dense 파트와 item 임베딩은 가속기에 매핑되며 user 임베딩은 host CPU에 매핑된다.

• 64GB host DRAM은 user 임베딩에 필요한 100GB보다 작다.
• 평균적으로 HW-S는 5개의 HW-AN을 처리할 수 있으며, 이 usecase에서 SM을 사용하면 scale-out을 방지할 수있다.
• Host 당 가속화된 QPS를 고려할 때 SM에서 더 높은 수준의 IOPS가 필요하다. (450 QPS × 450 Tables × 25 AvgPF = 4.8M IOPS)
• SM cache에서 90% 이상의 hit rate가 관찰되므로 평균 지속 IPS 요구량은 약 480k IOPS이다. (=4.8M IOPS * 1/10)
• HW-AN의 2개의 Nand Flash는 약 1M의 총 최소 IOPS를 제공하나 Nand Flash에 access하는 긴 latency로 인해 latency을 낮게 유지하기 위해 장치를 상당히 적게 활용해야 한다.
• Optane SSD는 훨씬 더 높은 IOPS와 더 낮은 지연시간을 제공하여 user 임베딩을 critical path 밖에서 처리되도록 유지한다.
• Scale-out의 필요성을 제거하여 HW-AO는 전력 소비를 5%까지 줄인다.
• HW-AO는 scale-out에 비해 단순하고, 절전 효과가 크지 않지만 모델이 커짐에 따라 절전 효과가 커진다.

결과 #3: Multi-tenancy 촉진

M3는 업데이트된 가속기 플랫폼에서 실행할 수 있는 미래 모델이다. SDM의 주요 주장은 host당 배포되는 DRAM의 양을 제한하는 것이다. DRAM 전력은 이러한 플랫폼에서 전체 전력의 중요한 부분이 아니기 때문에 주로 cost 주장이다.

• Multi-tenancy를 통해 DRAM 메모리 용량 제한없이 증가하여 가속기의 utilization을 높여 전력을 절감한다.
• Multi-tenancy는 동일한 호스트에서 여러 모델을 실행하는 것이다. Multi-tenancy는 요구사항이 다른 모델을 함께 배치하고 가속기, CPU 및 DRAM과 같은 다양한 리소스 활용의 균형을 맞춘다면 전체 host의 활용도를 높이고 전력 절감할 수 있다.
• 프로덕션 모델당 실행 중인 실험 모델의 수가 주어지며, 평균적으로 할당된 리소스의 최대 1/4을 소비한다. 이러한 실험 모델은 적은 양의 트래픽에서 실행되므로 모델당 QPS 요구 사항이 낮아 호스트가 충분히 활용되지 않을 수 있다.
• 더 강력한 가속기의 출현으로 더 많은 컴퓨팅 기능이 단일 호스트에 압축되어 host를 충분히 활용하지 못하는 모델의 비용이 증가한다.
• 지정된 호스트에 둘 이상의 모델을 함께 배치하면 활용도가 높아지며 특히 메모리 용량 요구 사항은 함께 배치된 모델 수에 따라 확장된다.
• 따라서 serving은 메모리 용량에 제한된다. 이 경우 SM을 사용하면 호스트당 모델에 사용 가능한 메모리 용량이 증가하여 다중 테넌트로 인한 메모리 용량 한계를 방지할 수 있다.

다음 표는 각각 4M IOPS를 제공하는 9개 Optane SSD로 충족될 수 있는 36 M IOPS의 필요성을 보여준다. 실험 모델의 수와 필요한 QPS를 감안할 때 규모에서 host의 사용률은 63%이다.

SM과 multi-tenancy를 사용하는 상태에서 전력 절감에 대한 roofline 추정치은 아래와 같으며 29%의 전력 절감을 보여준다.

레퍼런스

[1] Supporting Massive DLRM Inference Through Software Defined Memory

Supporting Massive DLRM Inference Through Software Defined Memory

[2] Designing AI Systems for Deep Learning Recommendation and Beyond (Carole-Jean Wu. Facebook. ‘21/05)

[3] How Facebook/Meta Design Sustainable Datacenters with AI (Bilge Acun. Facebook. ‘22/01)