LLM(대형 언어 모델)을 배포할 때 ML(기계 학습) 실무자는 일반적으로 모델 제공 성능에 대한 두 가지 측정, 즉 단일 토큰을 생성하는 데 걸리는 시간으로 정의되는 대기 시간과 생성된 토큰 수로 정의되는 처리량에 관심을 갖습니다. 초당. 배포된 엔드포인트에 대한 단일 요청의 처리량은 모델 대기 시간의 역과 거의 동일하지만, 여러 동시 요청이 동시에 엔드포인트로 전송되는 경우에는 반드시 그런 것은 아닙니다. 동시 요청의 클라이언트 측 연속 일괄 처리와 같은 모델 제공 기술로 인해 지연 시간 및 처리량은 모델 아키텍처, 제공 구성, 인스턴스 유형 하드웨어, 동시 요청 수 및 입력 페이로드의 변화에 ​​따라 크게 달라지는 복잡한 관계를 갖습니다. 입력 토큰과 출력 토큰의 수.

이 게시물에서는 Llama 2, Falcon 및 Mistral 변형을 포함하여 Amazon SageMaker JumpStart에서 사용할 수 있는 LLM의 포괄적인 벤치마킹을 통해 이러한 관계를 살펴봅니다. SageMaker JumpStart를 사용하면 ML 실무자는 공개적으로 사용 가능한 다양한 기반 모델 중에서 선택하여 전용 모델에 배포할 수 있습니다. 아마존 세이지 메이커 네트워크로 격리된 환경 내의 인스턴스. 우리는 가속기 사양이 LLM 벤치마킹에 어떻게 영향을 미치는지에 대한 이론적 원칙을 제공합니다. 또한 단일 엔드포인트 뒤에 여러 인스턴스를 배포할 때의 영향도 보여줍니다. 마지막으로, 지연 시간, 처리량, 비용 및 사용 가능한 인스턴스 유형에 대한 제약 조건에 대한 요구 사항에 맞게 SageMaker JumpStart 배포 프로세스를 조정하기 위한 실용적인 권장 사항을 제공합니다. 모든 벤치마킹 결과와 권장 사항은 다양한 기능을 기반으로 합니다. 수첩 사용 사례에 맞게 조정할 수 있습니다.

배포된 엔드포인트 벤치마킹

다음 그림은 다양한 모델 유형과 인스턴스 유형에 걸쳐 배포 구성에 대한 가장 낮은 지연 시간(왼쪽)과 가장 높은 처리량(오른쪽) 값을 보여줍니다. 중요한 점은 이러한 각 모델 배포는 원하는 모델 ID와 배포용 인스턴스 유형이 지정된 SageMaker JumpStart에서 제공하는 기본 구성을 사용한다는 것입니다.

이러한 지연 시간 및 처리량 값은 256개의 입력 토큰과 256개의 출력 토큰이 있는 페이로드에 해당합니다. 가장 낮은 대기 시간 구성은 단일 동시 요청에 대한 모델 제공을 제한하고, 가장 높은 처리량 구성은 가능한 동시 요청 수를 최대화합니다. 벤치마킹에서 볼 수 있듯이 동시 요청을 늘리면 처리량은 단조롭게 증가하고 대규모 동시 요청에 대한 개선은 줄어듭니다. 또한 모델은 지원되는 인스턴스에서 완전히 샤딩됩니다. 예를 들어, ml.g5.48xlarge 인스턴스에는 8개의 GPU가 있으므로 이 인스턴스를 사용하는 모든 SageMaker JumpStart 모델은 사용 가능한 XNUMX개의 가속기 모두에서 텐서 병렬 처리를 사용하여 샤딩됩니다.

이 수치에서 몇 가지 시사점을 확인할 수 있습니다. 첫째, 모든 모델이 모든 인스턴스에서 지원되는 것은 아닙니다. Falcon 7B와 같은 일부 소형 모델은 모델 샤딩을 지원하지 않는 반면, 대형 모델은 컴퓨팅 리소스 요구 사항이 더 높습니다. 둘째, 샤딩이 증가하면 일반적으로 성능이 향상되지만 소규모 모델의 경우 반드시 향상되는 것은 아닙니다.. 이는 7B 및 13B와 같은 소형 모델이 너무 많은 액셀러레이터에 걸쳐 분할될 때 상당한 통신 오버헤드가 발생하기 때문입니다. 이에 대해서는 나중에 더 자세히 논의하겠습니다. 마지막으로 ml.p4d.24xlarge 인스턴스는 A100G GPU에 비해 ​​A10의 메모리 대역폭 향상으로 인해 처리량이 훨씬 더 높은 경향이 있습니다. 나중에 논의하겠지만 특정 인스턴스 유형을 사용하기로 한 결정은 지연 시간, 처리량, 비용 제약 조건을 포함한 배포 요구 사항에 따라 달라집니다.

이러한 최저 대기 시간과 최고 처리량 구성 값을 어떻게 얻을 수 있습니까? 다음 곡선에 표시된 대로 2개의 입력 토큰과 7개의 출력 토큰이 있는 페이로드에 대한 ml.g5.12xlarge 인스턴스의 Llama 256 256B 엔드포인트에 대한 지연 시간과 처리량을 플롯하는 것부터 시작하겠습니다. 배포된 모든 LLM 엔드포인트에 대해 유사한 곡선이 존재합니다.

동시성이 증가함에 따라 처리량과 대기 시간도 단조롭게 증가합니다. 따라서 동시 요청 값이 1일 때 대기 시간이 가장 낮은 지점이 발생하며, 동시 요청을 늘려 시스템 처리량을 비용 효율적으로 늘릴 수 있습니다. 이 곡선에는 뚜렷한 "무릎"이 존재합니다. 여기서는 추가 동시성과 관련된 처리량 증가가 관련 대기 시간 증가보다 크지 않다는 것이 분명합니다. 이 무릎의 정확한 위치는 사용 사례에 따라 다릅니다. 일부 실무자는 미리 지정된 대기 시간 요구 사항(예: 100ms/토큰)이 초과되는 지점에서 무릎을 정의할 수 있는 반면, 다른 실무자는 부하 테스트 벤치마크 및 절반 대기 시간 규칙과 같은 큐잉 이론 방법을 사용할 수도 있고 다른 실무자는 다음을 사용할 수도 있습니다. 이론적 가속기 사양.

또한 최대 동시 요청 수가 제한되어 있습니다. 앞의 그림에서 회선 추적은 192개의 동시 요청으로 끝납니다. 이 제한의 원인은 SageMaker 호출 시간 초과 제한입니다. 여기서 SageMaker 엔드포인트는 60초 후에 호출 응답을 시간 초과합니다. 이 설정은 계정별로 적용되며 개별 엔드포인트에 대해 구성할 수 없습니다. LLM의 경우 다수의 출력 토큰을 생성하는 데 몇 초 또는 몇 분이 걸릴 수 있습니다. 따라서 큰 입력 또는 출력 페이로드로 인해 호출 요청이 실패할 수 있습니다. 또한 동시 요청 수가 매우 많으면 많은 요청에서 대기열 시간이 길어져 60초 제한 시간이 적용됩니다. 이 연구의 목적을 위해 제한 시간 제한을 사용하여 모델 배포에 가능한 최대 처리량을 정의합니다. 중요한 점은 SageMaker 엔드포인트가 호출 응답 시간 초과를 관찰하지 않고 많은 수의 동시 요청을 처리할 수 있더라도 지연 시간-처리량 곡선에서 Knee와 관련하여 최대 동시 요청을 정의할 수 있다는 것입니다. 이는 더 많은 동시 요청을 지원하기 위해 단일 엔드포인트가 모델 복제본으로 여러 인스턴스를 프로비저닝하고 복제본 간에 들어오는 요청의 로드 밸런싱을 수행하는 수평적 확장을 고려하기 시작하는 지점일 가능성이 높습니다.

한 단계 더 나아가 다음 표에는 다양한 수의 입력 및 출력 토큰, 인스턴스 유형, 동시 요청 수를 포함하여 Llama 2 7B 모델의 다양한 구성에 대한 벤치마킹 결과가 포함되어 있습니다. 앞의 그림은 이 테이블의 단일 행만 표시합니다.

우리는 이 데이터에서 몇 가지 추가 패턴을 관찰합니다. 컨텍스트 크기를 늘리면 대기 시간이 늘어나고 처리량이 감소합니다. 예를 들어, 동시성이 5.2인 ml.g1xlarge에서 총 토큰 수가 30개일 때 처리량은 512개 토큰/초이고, 총 토큰 수가 20개일 경우 처리량은 4,096개 토큰/초입니다. 이는 더 큰 입력을 처리하는 데 더 많은 시간이 걸리기 때문입니다. 또한 GPU 기능과 샤딩이 증가하면 최대 처리량과 최대 지원 동시 요청에 영향을 미치는 것을 확인할 수 있습니다. 표에서는 Llama 2 7B가 다양한 인스턴스 유형에 대해 최대 처리량 값이 현저히 다르며 이러한 최대 처리량 값은 동시 요청의 다양한 값에서 발생함을 보여줍니다. 이러한 특성으로 인해 ML 실무자는 한 인스턴스의 비용을 다른 인스턴스보다 정당화하게 됩니다. 예를 들어 짧은 지연 시간 요구 사항이 있는 경우 실무자는 ml.g5.12xlarge 인스턴스(A4G GPU 10개) 대신 ml.g5.2xlarge 인스턴스(A1G GPU 10개)를 선택할 수 있습니다. 높은 처리량 요구 사항이 있는 경우 전체 샤딩이 포함된 ml.p4d.24xlarge 인스턴스(A8 GPU 100개)를 사용하는 것은 높은 동시성에서만 정당화됩니다. 그러나 대신 단일 ml.p7d.4xlarge 인스턴스에 24B 모델의 여러 추론 구성 요소를 로드하는 것이 유용한 경우가 많습니다. 이러한 다중 모델 지원은 이 게시물의 뒷부분에서 논의됩니다.

이전 관찰은 Llama 2 7B 모델에 대해 이루어졌습니다. 그러나 비슷한 패턴은 다른 모델에서도 마찬가지입니다. 주요 요점은 지연 시간 및 처리량 성능 수치가 페이로드, 인스턴스 유형 및 동시 요청 수에 따라 달라지므로 특정 애플리케이션에 이상적인 구성을 찾아야 한다는 것입니다. 사용 사례에 대한 이전 숫자를 생성하려면 연결된 다음을 실행할 수 있습니다. 수첩, 모델, 인스턴스 유형 및 페이로드에 대한 부하 테스트 분석을 구성할 수 있습니다.

가속기 사양 이해

LLM 추론에 적합한 하드웨어를 선택하는 것은 특정 사용 사례, 사용자 경험 목표 및 선택한 LLM에 크게 좌우됩니다. 이 섹션에서는 가속기 사양을 기반으로 하는 상위 수준 원칙과 관련하여 대기 시간-처리량 곡선에서 무릎에 대한 이해를 시도합니다. 이러한 원칙만으로는 결정을 내리는 데 충분하지 않습니다. 실제 벤치마크가 필요합니다. 용어 장치 여기에서는 모든 ML 하드웨어 가속기를 포함하는 데 사용됩니다. 우리는 대기 시간-처리량 곡선의 무릎이 다음 두 가지 요소 중 하나에 의해 결정된다고 주장합니다.

• 가속기가 KV 행렬을 캐시하기 위해 메모리를 모두 사용했기 때문에 후속 요청이 대기열에 추가되었습니다.
• 가속기에는 여전히 KV 캐시를 위한 여유 메모리가 있지만 처리 시간이 메모리 대역폭이 아닌 컴퓨팅 작업 대기 시간에 따라 결정될 만큼 충분히 큰 배치 크기를 사용하고 있습니다.

우리는 일반적으로 가속기 리소스가 포화되었음을 의미하기 때문에 두 번째 요소로 제한하는 것을 선호합니다. 기본적으로 귀하는 비용을 지불한 리소스를 극대화하고 있습니다. 이 주장을 더 자세히 살펴보겠습니다.

KV 캐싱 및 장치 메모리

표준 변환기 주의 메커니즘은 모든 이전 토큰에 대해 각각의 새 토큰에 대한 주의를 계산합니다. 대부분의 최신 ML 서버는 모든 단계에서 재계산을 방지하기 위해 장치 메모리(DRAM)에 주의 키와 값을 캐시합니다. 이것을 이것을 이라고 한다 KV 캐시, 배치 크기와 시퀀스 길이에 따라 증가합니다. 이는 병렬로 처리할 수 있는 사용자 요청 수를 정의하고, 사용 가능한 DRAM을 고려할 때 앞서 언급한 두 번째 시나리오의 컴퓨팅 바인딩 방식이 아직 충족되지 않은 경우 대기 시간-처리량 곡선의 무릎을 결정합니다. 다음 공식은 최대 KV 캐시 크기에 대한 대략적인 근사치입니다.

이 공식에서 B는 배치 크기이고 N은 가속기 수입니다. 예를 들어 A2G GPU(7GB DRAM)에서 제공되는 FP16(2바이트/매개변수)의 Llama 10 24B 모델은 약 14GB를 소비하고 KV 캐시용으로 10GB를 남겨둡니다. 모델의 전체 컨텍스트 길이(N = 4096)와 나머지 매개변수(n_layers=32, n_kv_attention_heads=32 및 d_attention_head=128)를 연결하면 이 표현식은 DRAM 제약으로 인해 병렬로 XNUMX명의 사용자 배치 크기를 제공하는 것으로 제한됨을 보여줍니다. . 이전 표에서 해당 벤치마크를 관찰하면 이는 이 대기 시간-처리량 곡선에서 관찰된 무릎에 대한 좋은 근사치입니다. 다음과 같은 방법 그룹화된 쿼리 관심 (GQA)는 KV 캐시 크기를 줄일 수 있으며, GQA의 경우 동일한 요소로 KV 헤드 수를 줄입니다.

산술 강도 및 장치 메모리 대역폭

ML 가속기의 계산 능력 증가는 메모리 대역폭을 능가했습니다. 즉, 해당 바이트에 액세스하는 데 걸리는 시간 동안 각 데이터 바이트에 대해 더 많은 계산을 수행할 수 있습니다.

XNUMXD덴탈의 산술 강도또는 작업에 대한 메모리 액세스에 대한 컴퓨팅 작업의 비율은 선택한 하드웨어의 메모리 대역폭이나 컴퓨팅 용량에 의해 제한되는지 여부를 결정합니다. 예를 들어, 10TFLOPS FP5 및 70GB/초 대역폭을 갖춘 A16G GPU(g600 인스턴스 유형 제품군)는 약 116ops/byte를 계산할 수 있습니다. A100 GPU(p4d 인스턴스 유형 제품군)는 약 208ops/byte를 계산할 수 있습니다. 변환기 모델의 산술 강도가 해당 값보다 낮으면 메모리에 바인딩됩니다. 그보다 높으면 계산에 바인딩됩니다. Llama 2 7B의 주의 메커니즘에는 배치 크기 62에 대해 1 ops/byte가 필요합니다(설명은 다음을 참조하세요). LLM 추론 및 성능 가이드) 이는 메모리에 바인딩되어 있음을 의미합니다. 주의 메커니즘이 메모리에 묶여 있으면 값비싼 FLOPS가 활용되지 않은 채로 남습니다.

가속기를 더 잘 활용하고 산술 강도를 높이는 두 가지 방법이 있습니다. 즉, 작업에 필요한 메모리 액세스를 줄이는 것입니다. 플래시주의 집중) 또는 배치 크기를 늘립니다. 그러나 DRAM이 너무 작아 해당 KV 캐시를 보유할 수 없는 경우 컴퓨팅 경계 체제에 도달할 만큼 배치 크기를 충분히 늘리지 못할 수도 있습니다. 표준 GPT 디코더 추론을 위해 계산 경계와 메모리 경계 방식을 구분하는 임계 배치 크기 B*의 대략적인 근사치는 다음 식으로 설명됩니다. 여기서 A_mb는 가속기 메모리 대역폭, A_f는 가속기 FLOPS, N은 숫자입니다. 가속기의. 이 중요한 배치 크기는 메모리 액세스 시간이 계산 시간과 일치하는 위치를 찾아 파생될 수 있습니다. 인용하다 이 블로그 게시물 방정식 2와 그 가정을 더 자세히 이해합니다.

이는 이전에 A10G에 대해 계산한 작업/바이트 비율과 동일하므로 이 GPU의 중요 배치 크기는 116입니다. 이 이론적이고 중요한 배치 크기에 접근하는 한 가지 방법은 모델 샤딩을 늘리고 더 많은 N 가속기에 캐시를 분할하는 것입니다. 이는 KV 캐시 용량과 메모리 바인딩된 배치 크기를 효과적으로 증가시킵니다.

모델 샤딩의 또 다른 이점은 N개의 가속기에 걸쳐 모델 매개변수와 데이터 로드 작업을 분할하는 것입니다. 이러한 유형의 샤딩은 모델 병렬성 유형이라고도 합니다. 텐서 병렬 처리. 순진하게 말하면, 총 메모리 대역폭과 컴퓨팅 성능이 N배 더 높습니다. 어떤 종류(통신, 소프트웨어 등)의 오버헤드가 없다고 가정하면 메모리 제한이 있는 경우 토큰당 디코딩 대기 시간이 N만큼 감소합니다. 왜냐하면 이 방식의 토큰 디코딩 대기 시간은 모델을 로드하는 데 걸리는 시간에 따라 제한되기 때문입니다. 가중치와 캐시. 그러나 실제 생활에서는 샤딩 수준을 높이면 장치 간 통신이 증가하여 모든 모델 계층에서 중간 활성화를 공유하게 됩니다. 이 통신 속도는 장치 상호 연결 대역폭에 의해 제한됩니다. 그 영향을 정확하게 추정하기는 어렵습니다(자세한 내용은 모델 병렬 처리), 그러나 이는 결국 이점을 제공하지 않거나 성능을 저하시킬 수 있습니다. 이는 특히 작은 모델의 경우에 해당됩니다. 데이터 전송량이 적을수록 전송 속도가 낮아지기 때문입니다.

사양에 따라 ML 가속기를 비교하려면 다음을 권장합니다. 먼저 두 번째 방정식에 따라 각 가속기 유형에 대한 대략적인 중요 배치 크기를 계산하고 첫 번째 방정식에 따라 중요 배치 크기에 대한 KV 캐시 크기를 계산합니다. 그런 다음 가속기에서 사용 가능한 DRAM을 사용하여 KV 캐시 및 모델 매개변수를 맞추는 데 필요한 최소 가속기 수를 계산할 수 있습니다. 여러 가속기 중에서 결정하는 경우 메모리 대역폭의 GB/초당 비용이 가장 낮은 순서대로 가속기의 우선 순위를 지정하세요. 마지막으로 이러한 구성을 벤치마킹하고 원하는 대기 시간의 상한에 가장 적합한 비용/토큰이 무엇인지 확인하세요.

엔드포인트 배포 구성 선택

SageMaker JumpStart에서 배포한 많은 LLM은 다음을 사용합니다. 텍스트 생성 추론 (TGI) SageMaker 컨테이너 모델 제공을 위해. 다음 표에서는 지연 시간-처리량 곡선에 영향을 미치는 모델 제공에 영향을 주거나 엔드포인트에 과부하가 걸리는 요청으로부터 엔드포인트를 보호하기 위해 다양한 모델 제공 매개변수를 조정하는 방법을 설명합니다. 이는 사용 사례에 맞게 엔드포인트 배포를 구성하는 데 사용할 수 있는 기본 매개변수입니다. 별도로 지정하지 않는 한 기본값을 사용합니다. 텍스트 생성 페이로드 매개변수 과 TGI 환경 변수.

TGI 서버는 동시 요청을 동적으로 일괄 처리하여 단일 모델 추론 정방향 전달을 공유하는 연속 일괄 처리를 사용합니다. 정방향 패스에는 프리필(prefill)과 디코드(decode)라는 두 가지 유형이 있습니다. 각각의 새로운 요청은 입력 시퀀스 토큰에 대한 KV 캐시를 채우기 위해 단일 사전 채우기 정방향 전달을 실행해야 합니다. KV 캐시가 채워진 후 디코드 정방향 패스는 모든 일괄 요청에 대해 단일 다음 토큰 예측을 수행하며, 이는 출력 시퀀스를 생성하기 위해 반복적으로 반복됩니다. 새 요청이 서버로 전송되면 다음 디코드 단계는 새 요청에 대해 사전 채우기 단계가 실행될 수 있도록 기다려야 합니다. 이는 새로운 요청이 연속적으로 일괄 처리되는 후속 디코드 단계에 포함되기 전에 발생해야 합니다. 하드웨어 제약으로 인해 디코딩에 사용되는 연속 일괄 처리에는 모든 요청이 포함되지 않을 수 있습니다. 이 시점에서 요청은 처리 대기열에 들어가고 약간의 처리량 증가만으로 추론 대기 시간이 크게 증가하기 시작합니다.

LLM 대기 시간 벤치마킹 분석을 사전 채우기 대기 시간, 디코딩 대기 시간 및 대기열 대기 시간으로 분리할 수 있습니다. 이러한 각 구성 요소에 소요되는 시간은 본질적으로 근본적으로 다릅니다. 미리 채우기는 일회성 계산이고 디코딩은 출력 시퀀스의 각 토큰에 대해 한 번 발생하며 대기열에는 서버 일괄 처리 프로세스가 포함됩니다. 여러 동시 요청이 처리되는 경우 특정 클라이언트 요청에서 발생하는 대기 시간에는 새로운 동시 요청을 미리 채우는 데 필요한 대기열 대기 시간과 포함으로 인해 발생하는 대기열 대기 시간이 포함되므로 각 구성 요소의 대기 시간을 분리하는 것이 어렵습니다. 일괄 디코딩 프로세스의 요청. 이러한 이유로 이 게시물에서는 엔드투엔드 처리 대기 시간에 중점을 둡니다. 대기 시간-처리량 곡선의 무릎은 대기열 대기 시간이 크게 증가하기 시작하는 포화 지점에서 발생합니다. 이 현상은 모든 모델 추론 서버에서 발생하며 가속기 사양에 따라 발생합니다.

배포 중 일반적인 요구 사항에는 최소 필수 처리량, 최대 허용 대기 시간, 시간당 최대 비용, 1만 개의 토큰을 생성하는 데 필요한 최대 비용 충족이 포함됩니다. 최종 사용자 요청을 나타내는 페이로드에 대해 이러한 요구 사항을 지정해야 합니다. 이러한 요구 사항을 충족하기 위한 설계에서는 특정 모델 아키텍처, 모델 크기, 인스턴스 유형 및 인스턴스 수(수평 확장)를 비롯한 다양한 요소를 고려해야 합니다. 다음 섹션에서는 대기 시간을 최소화하고 처리량을 최대화하며 비용을 최소화하기 위한 엔드포인트 배포에 중점을 둡니다. 이 분석에서는 총 512개의 토큰과 256개의 출력 토큰을 고려합니다.

대기 시간 최소화

지연 시간은 많은 실시간 사용 사례에서 중요한 요구 사항입니다. 다음 표에서는 각 모델과 각 인스턴스 유형의 최소 지연 시간을 살펴봅니다. 다음을 설정하여 최소 대기 시간을 달성할 수 있습니다. MAX_CONCURRENT_REQUESTS = 1.

모델의 최소 지연 시간을 달성하려면 원하는 모델 ID와 인스턴스 유형을 대체하면서 다음 코드를 사용할 수 있습니다.

from sagemaker.jumpstart.model import JumpStartModel

model = JumpStartModel(
    model_id="meta-textgeneration-llama-2-7b",
    model_version="3.*",
    instance_type="ml.g5.12xlarge",
    env={
        "MAX_CONCURRENT_REQUESTS": "1",
        "MAX_INPUT_TOKENS": "256",
        "MAX_TOTAL_TOKENS": "512",
    },
)
predictor = model.deploy(accept_eula=False)  # Change EULA acceptance to True

지연 시간 수치는 입력 및 출력 토큰 수에 따라 변경됩니다. 그러나 환경 변수를 제외하고 배포 프로세스는 동일하게 유지됩니다. MAX_INPUT_TOKENS 과 MAX_TOTAL_TOKENS. 여기서 이러한 환경 변수는 더 큰 입력 시퀀스가 ​​대기 시간 요구 사항을 위반할 수 있으므로 엔드포인트 대기 시간 요구 사항을 보장하는 데 도움이 되도록 설정됩니다. SageMaker JumpStart는 인스턴스 유형을 선택할 때 이미 다른 최적의 환경 변수를 제공합니다. 예를 들어 ml.g5.12xlarge를 사용하면 다음과 같이 설정됩니다. SM_NUM_GPUS 모델 환경에서는 4로 변경됩니다.

처리량 극대화

이 섹션에서는 초당 생성되는 토큰 수를 최대화합니다. 이는 일반적으로 모델 및 인스턴스 유형에 대한 최대 유효 동시 요청에서 달성됩니다. 다음 표에서는 요청에 대해 SageMaker 호출 시간 초과가 발생하기 전에 달성된 최대 동시 요청 값에서 달성된 처리량을 보고합니다.

모델의 최대 처리량을 달성하려면 다음 코드를 사용할 수 있습니다.

from sagemaker.jumpstart.model import JumpStartModel

model = JumpStartModel(
    model_id="meta-textgeneration-llama-2-7b",
    model_version="3.*",
    instance_type="ml.g5.12xlarge",
    env={
        "MAX_CONCURRENT_REQUESTS": "128",  # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests.
        "MAX_INPUT_TOKENS": "256",
        "MAX_TOTAL_TOKENS": "512",
    },
)
predictor = model.deploy(accept_eula=False)  # Change EULA acceptance to True

최대 동시 요청 수는 모델 유형, 인스턴스 유형, 최대 입력 토큰 수 및 최대 출력 토큰 수에 따라 달라집니다. 따라서 설정하기 전에 이러한 매개변수를 설정해야 합니다. MAX_CONCURRENT_REQUESTS.

또한 대기 시간 최소화에 관심이 있는 사용자는 처리량 최대화에 관심이 있는 사용자와 충돌하는 경우가 많습니다. 전자는 실시간 응답에 관심이 있는 반면, 후자는 엔드포인트 대기열이 항상 포화되어 처리 중단 시간을 최소화하는 일괄 처리에 관심이 있습니다. 대기 시간 요구 사항에 따라 처리량을 최대화하려는 사용자는 대기 시간-처리량 곡선의 무릎에서 작업하는 데 관심이 있는 경우가 많습니다.

비용 최소화

비용을 최소화하는 첫 번째 옵션은 시간당 비용을 최소화하는 것입니다. 이를 통해 시간당 가장 낮은 비용으로 SageMaker 인스턴스에 선택한 모델을 배포할 수 있습니다. SageMaker 인스턴스의 실시간 가격은 다음을 참조하세요. Amazon SageMaker 요금. 일반적으로 SageMaker JumpStart LLM의 기본 인스턴스 유형은 가장 저렴한 배포 옵션입니다.

비용을 최소화하는 두 번째 옵션은 1만 개의 토큰을 생성하는 데 드는 비용을 최소화하는 것입니다. 이는 처리량을 최대화하기 위해 앞서 논의한 테이블을 간단히 변환한 것입니다. 여기서 먼저 백만 개의 토큰을 생성하는 데 걸리는 시간(1e1 / 처리량 / 6)을 몇 시간에 걸쳐 계산할 수 있습니다. 그런 다음 이 시간을 곱하여 지정된 SageMaker 인스턴스의 시간당 가격으로 3600백만 개의 토큰을 생성할 수 있습니다.

시간당 비용이 가장 낮은 인스턴스는 1만 개의 토큰을 생성하는 데 드는 비용이 가장 낮은 인스턴스와 동일하지 않습니다. 예를 들어, 호출 요청이 산발적이라면 시간당 비용이 가장 낮은 인스턴스가 최적일 수 있지만, 제한 시나리오에서는 백만 개의 토큰을 생성하는 데 가장 낮은 비용이 더 적절할 수 있습니다.

텐서 병렬 대 다중 모델 절충

이전의 모든 분석에서 우리는 배포 인스턴스 유형의 GPU 수와 동일한 텐서 병렬 수준을 갖는 단일 모델 복제본 배포를 고려했습니다. 이것이 기본 SageMaker JumpStart 동작입니다. 그러나 이전에 언급한 것처럼 모델을 샤딩하면 특정 한도까지만 모델 지연 시간과 처리량이 향상될 수 있으며, 이 한도를 초과하면 기기 간 통신 요구 사항이 계산 시간을 좌우합니다. 이는 텐서 병렬도가 높은 단일 모델보다는 단일 인스턴스에 텐서 병렬도가 낮은 여러 모델을 배포하는 것이 더 나은 경우가 많다는 것을 의미합니다.

여기서는 텐서 병렬(TP) 수준이 2, 7, 13, 4인 ml.p24d.1xlarge 인스턴스에 Llama 2 4B 및 8B 엔드포인트를 배포합니다. 모델 동작을 명확하게 하기 위해 이러한 각 엔드포인트는 단일 모델만 로드합니다.

이전 분석에서는 이미 ml.p4d.24xlarge 인스턴스에서 상당한 처리량 이점을 보여주었습니다. 이는 높은 동시 요청 로드 조건에서 g1 인스턴스 제품군에 비해 5만 개의 토큰을 생성하는 데 드는 비용 측면에서 더 나은 성능으로 해석되는 경우가 많습니다. 이 분석은 단일 인스턴스 내에서 모델 샤딩과 모델 복제 간의 균형을 고려해야 함을 명확하게 보여줍니다. 즉, 완전히 샤딩된 모델은 일반적으로 4B 및 24B 모델 계열에 대한 ml.p7d.13xlarge 컴퓨팅 리소스를 가장 잘 사용하지 않습니다. 실제로 7B 모델 계열의 경우 텐서 병렬 수준이 4이 아닌 8인 단일 모델 복제본에 대해 최고의 처리량을 얻습니다.

여기에서 7B 모델의 최고 처리량 구성에는 1개의 모델 복제본이 있는 텐서 병렬 수준 13이 포함되고, 2B 모델의 최고 처리량 구성은 XNUMX개의 모델 복제본이 있는 텐서 병렬 수준 XNUMX일 가능성이 높다는 것을 추정할 수 있습니다. 이를 수행하는 방법에 대해 자세히 알아보려면 다음을 참조하세요. Amazon SageMaker의 최신 기능을 사용하여 모델 배포 비용을 평균 50% 절감, 추론 구성 요소 기반 끝점의 사용을 보여줍니다. 로드 밸런싱 기술, 서버 라우팅 및 CPU 리소스 공유로 인해 복제본 수와 단일 복제본의 처리량을 곱한 것과 정확하게 동일한 처리량 향상을 달성하지 못할 수도 있습니다.

수평 확장

앞에서 살펴본 것처럼 각 엔드포인트 배포에는 입력 및 출력 토큰 수와 인스턴스 유형에 따라 동시 요청 수에 제한이 있습니다. 처리량 또는 동시 요청 요구 사항이 충족되지 않는 경우 배포된 엔드포인트 뒤에서 두 개 이상의 인스턴스를 활용하도록 확장할 수 있습니다. SageMaker는 인스턴스 간 쿼리의 로드 밸런싱을 자동으로 수행합니다. 예를 들어 다음 코드는 세 개의 인스턴스가 지원하는 엔드포인트를 배포합니다.

model = JumpStartModel(
    model_id="meta-textgeneration-llama-2-7b",
    model_version="3.*",
    instance_type="ml.g5.2xlarge",
)
predictor = model.deploy(
    accept_eula=False,  # Change EULA acceptance to True
    initial_instance_count = 3,
)

다음 표는 Llama 2 7B 모델의 인스턴스 수에 따른 처리량 증가를 보여줍니다.

특히 인스턴스 수가 많을수록 다중 인스턴스 엔드포인트 내에서 더 많은 수의 동시 요청을 처리할 수 있기 때문에 지연 시간-처리량 곡선의 무릎이 오른쪽으로 이동합니다. 이 표의 경우 동시 요청 값은 각 개별 인스턴스가 수신하는 동시 요청 수가 아니라 전체 엔드포인트에 대한 값입니다.

또한 워크로드를 모니터링하고 용량을 동적으로 조정하여 가능한 최저 비용으로 꾸준하고 예측 가능한 성능을 유지하는 기능인 자동 크기 조정을 사용할 수도 있습니다. 이는 이 게시물의 범위를 벗어납니다. 자동 크기 조정에 대해 자세히 알아보려면 다음을 참조하세요. Amazon SageMaker에서 자동 확장 추론 엔드포인트 구성.

동시 요청으로 엔드포인트 호출

높은 처리량 조건에서 배포된 모델로부터 응답을 생성하는 데 사용하려는 대규모 쿼리 배치가 있다고 가정해 보겠습니다. 예를 들어 다음 코드 블록에서는 각 페이로드가 1,000개의 토큰 생성을 요청하는 100개의 페이로드 목록을 컴파일합니다. 전체적으로 우리는 100,000개의 토큰 생성을 요청합니다.

payload = {
    "inputs": "I believe the meaning of life is to ",
    "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

SageMaker 런타임 API에 많은 수의 요청을 보낼 때 조절 오류가 발생할 수 있습니다. 이를 완화하기 위해 재시도 횟수를 늘리는 사용자 지정 SageMaker 런타임 클라이언트를 생성할 수 있습니다. 결과 SageMaker 세션 객체를 다음 중 하나에 제공할 수 있습니다. JumpStartModel 생성자 또는 sagemaker.predictor.retrieve_default 이미 배포된 엔드포인트에 새 예측기를 연결하려는 경우. 다음 코드에서는 기본 SageMaker JumpStart 구성으로 Llama 2 모델을 배포할 때 이 세션 객체를 사용합니다.

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel

sagemaker_session = Session(
    sagemaker_runtime_client=boto3.client(
        "sagemaker-runtime",
        config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}),
    )
)
model = JumpStartModel(
    model_id="meta-textgeneration-llama-2-7b",
    model_version="3.*",
    sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False)  # Change EULA acceptance to True

배포된 이 엔드포인트에는 MAX_CONCURRENT_REQUESTS = 128 기본적으로. 다음 블록에서는 동시 미래 라이브러리를 사용하여 128개의 작업자 스레드가 있는 모든 페이로드에 대한 엔드포인트 호출을 반복합니다. 엔드포인트는 최대 128개의 동시 요청을 처리하며, 요청이 응답을 반환할 때마다 실행 프로그램은 즉시 엔드포인트에 새 요청을 보냅니다.

import time
from concurrent import futures

concurrent_requests = 128

time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor:
    responses = list(executor.map(predictor.predict, payloads))

total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

결과적으로 단일 ml.g100,000xlarge 인스턴스에서 초당 1255개 토큰의 처리량으로 총 5.2개의 토큰이 생성됩니다. 처리하는 데 약 80초 정도 걸립니다.

이 처리량 값은 이 게시물의 이전 표에 있는 ml.g2xlarge의 Llama 7 5.2B에 대한 최대 처리량(486개 동시 요청에서 64개 토큰/초)과 현저히 다릅니다. 이는 입력 페이로드가 8개 대신 256개의 토큰을 사용하고, 출력 토큰 개수가 100개 대신 256개이며, 더 작은 토큰 개수로 인해 128개의 동시 요청이 허용되기 때문입니다. 이는 모든 지연 시간과 처리량 수치가 페이로드에 따라 다르다는 점을 마지막으로 알려드립니다! 페이로드 토큰 수를 변경하면 모델 제공 중 일괄 처리 프로세스에 영향을 미치며, 이는 다시 애플리케이션의 긴급 사전 채우기, 디코딩 및 대기열 시간에 영향을 미칩니다.

결론

이 게시물에서는 Llama 2, Mistral 및 Falcon을 포함한 SageMaker JumpStart LLM의 벤치마킹을 소개했습니다. 또한 엔드포인트 배포 구성에 대한 대기 시간, 처리량 및 비용을 최적화하기 위한 가이드도 제시했습니다. 다음을 실행하여 시작할 수 있습니다. 관련 노트북 사용 사례를 벤치마킹합니다.

저자에 관하여

 카일 울리히 박사 Amazon SageMaker JumpStart 팀의 응용 과학자입니다. 그의 연구 관심사는 확장 가능한 기계 학습 알고리즘, 컴퓨터 비전, 시계열, 베이지안 비모수 및 가우시안 프로세스를 포함합니다. Duke University에서 박사 학위를 받았으며 NeurIPS, Cell 및 Neuron에 논문을 발표했습니다.

Dr. 비벡 마단 Amazon SageMaker JumpStart 팀의 응용 과학자입니다. 그는 일리노이 대학교 어바나 샴페인에서 박사 학위를 받았고 조지아 공대에서 박사후 연구원이었습니다. 그는 기계 학습 및 알고리즘 설계 분야에서 활발한 연구원이며 EMNLP, ICLR, COLT, FOCS 및 SODA 컨퍼런스에 논문을 발표했습니다.

Ashish Khetan 박사 Amazon SageMaker JumpStart의 수석 응용 과학자이며 기계 학습 알고리즘 개발을 돕습니다. 그는 University of Illinois Urbana-Champaign에서 박사 학위를 받았습니다. 그는 기계 학습 및 통계적 추론 분야에서 활동적인 연구원이며 NeurIPS, ICML, ICLR, JMLR, ACL 및 EMNLP 컨퍼런스에서 많은 논문을 발표했습니다.

주앙 모 우라 AWS의 수석 AI/ML 전문가 솔루션 아키텍트입니다. João는 소규모 스타트업부터 대기업까지 AWS 고객이 대규모 모델을 효율적으로 교육 및 배포하고 AWS에서 ML 플랫폼을 보다 광범위하게 구축할 수 있도록 지원합니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/