고성능 LLM 추론 프레임워크의 설계 및 구현

1. 대규모 언어 모델 추론 개요

기존 CNN 모델 추론과 달리 대규모 언어 모델의 추론은 일반적으로 사전 채우기와 디코딩의 두 단계로 나뉩니다. 각 요청이 시작된 후 생성된 추론 프로세스는 먼저 사전 채우기 프로세스를 거치며, 모든 사용자 입력을 계산하고 해당 KV 캐시를 생성합니다. 그런 다음 서버는 여러 디코딩 프로세스를 거칩니다. 캐릭터를 생성하고 KV 캐시에 넣은 다음 순차적으로 반복합니다.

디코딩 과정은 문자별로 생성되기 때문에 각 답변 조각을 생성하는 데 많은 시간이 걸리고 많은 수의 문자가 생성됩니다. 따라서 디코딩 단계의 수가 매우 많아 전체 추론 프로세스의 대부분을 차지하며 90%를 초과합니다.

Prefill 과정에서는 사용자가 입력한 모든 단어를 동시에 계산해야 하기 때문에 많은 계산을 처리해야 하지만 이는 일회성 과정일 뿐입니다. 따라서 Prefill은 전체 추론 프로세스에서 10% 미만의 시간만 차지합니다.

대규모 언어 모델 추론에는 일반적으로 처리량, 첫 번째 단어 대기 시간, 전체 대기 시간, 초당 요청 수(QPS) 등 4가지 주요 측정항목에 중점을 둡니다. 이러한 성과 지표는 다양한 관점에서 시스템의 서비스 기능을 평가합니다. 처리량은 시스템이 요청을 얼마나 빠르고 효율적으로 처리하는지를 측정하는 반면, 첫 번째 단어 대기 시간은 시스템이 첫 번째 토큰을 생성하는 데 걸리는 시간을 나타냅니다. 전체 대기 시간은 시스템이 전체 추론 작업을 완료하는 데 걸리는 시간입니다. 마지막으로 QPS는 시스템이 초당 처리하는 요청 수를 나타냅니다. 이러한 측정항목은 모델 성능과 시스템 최적화를 평가하는 데 핵심적인 역할을 하며 시스템이 다양한 추론 작업을 효율적으로 처리할 수 있도록 도와줍니다.

먼저 처리량(Throughput)을 소개하겠습니다. 모델 추론 수준에서 가장 먼저 집중해야 할 것은 처리량입니다. 처리량이란 시스템 부하가 최대에 도달했을 때 단위 시간당 몇 개의 디코딩을 수행할 수 있는지, 즉 몇 개의 문자가 생성되는지를 나타냅니다. 처리량을 테스트하는 방법은 모든 사용자가 동시에 도착하고 이러한 사용자가 동일한 질문을 하고 이러한 사용자가 동시에 시작하고 종료할 수 있다고 가정하는 것입니다. 입력 텍스트는 동일합니다. 완전한 배치는 정확히 동일한 입력을 사용하여 형성됩니다. 이 경우 시스템 처리량이 최대화됩니다. 그러나 이 상황은 비현실적이므로 이는 이론적 최대치입니다. 우리는 시스템이 1초에 얼마나 많은 독립적인 디코딩 단계를 수행할 수 있는지 측정합니다.

또 다른 주요 지표는 첫 번째 토큰 지연 시간입니다. 이는 사용자가 추론 시스템에 들어간 후 사전 채우기 단계를 완료하는 데 걸리는 시간입니다. 첫 번째 문자를 생성하기 위한 시스템의 응답 시간을 나타냅니다. 많은 사용자는 시스템에 질문을 입력한 후 2~3초 이내에 답변을 받기를 기대합니다.

또 다른 중요한 지표는 대기 시간입니다. 지연 시간은 각 디코딩 작업에 필요한 시간을 나타내며, 이는 대형 언어 모델 시스템이 실시간 처리 중에 각 문자를 생성하는 데 필요한 시간 간격과 생성 프로세스의 원활성을 반영합니다. 일반적으로 대기 시간을 50밀리초 미만으로 유지하려고 합니다. 즉, 초당 20자를 생성할 수 있습니다. 이러한 방식으로 대규모 언어 모델의 생성 프로세스가 더 원활해집니다.

마지막 측정항목은 QPS(초당 요청 수)입니다. 온라인 시스템 서비스에서 1초에 얼마나 많은 사용자 요청을 처리할 수 있는지를 나타냅니다. 이 지표의 측정 방법은 비교적 복잡하므로 나중에 소개하겠습니다.

첫 번째 토큰 지연 시간과 지연 시간 지표 모두에 대해 비교적 완전한 테스트를 수행했습니다. 이 두 지표는 사용자 입력의 길이와 배치 크기의 차이로 인해 크게 변경됩니다.

위 표에서 볼 수 있듯이, 동일한 7B 모델에 대해 사용자의 입력 길이가 8에서 2048로 변경되면 Prefill 시간은 6.78밀리초에서 2078밀리초, 즉 2초가 됩니다. 사용자가 80명이고 각 사용자가 1,024 단어를 입력하면 서버에서 Prefill이 실행되는 데 약 2초가 소요되며 이는 허용 범위를 벗어납니다. 그러나 사용자 입력 길이가 매우 짧은 경우, 예를 들어 방문당 8단어만 입력하면 768명의 사용자가 동시에 도착하더라도 첫 번째 단어 지연은 약 165밀리초에 불과합니다.

첫 번째 단어 지연과 가장 관련이 있는 것은 사용자의 입력 길이입니다. 사용자의 입력 길이가 길수록 첫 번째 단어 지연이 높아집니다. 사용자 입력 길이가 짧을 경우 첫 번째 단어 지연은 전체 대형 언어 모델 추론 프로세스에서 병목 현상이 되지 않습니다.

후속 디코딩 지연은 일반적으로 1000억 레벨 모델이 아닌 한 50밀리초 이내에 디코딩 지연이 제어됩니다. 주로 배치 크기의 영향을 받습니다. 배치 크기가 클수록 추론 지연이 커지지만 기본적으로 증가폭은 그리 높지 않습니다.

처리량은 실제로 이 두 가지 요소의 영향을 받습니다. 사용자 입력의 길이와 생성된 길이가 너무 길면 시스템 처리량이 그리 높지 않습니다. 사용자가 입력한 길이와 생성된 길이가 모두 그리 길지 않은 경우 시스템 처리량은 매우 터무니없는 수준에 도달할 수 있습니다.

QPS를 다시 살펴보겠습니다. QPS는 시스템이 처리할 수 있는 초당 요청 수를 나타내는 매우 구체적인 측정 기준입니다. 이 테스트를 수행할 때 실제 데이터를 사용합니다. (이 데이터는 이미 샘플링하여 github에 올렸습니다.)

QPS 측정은 처리량과 다릅니다. 대규모 언어 모델 시스템을 실제로 사용할 때 각 사용자가 오는 시간이 불확실하기 때문입니다. 어떤 유저는 일찍 올 수도 있고, 어떤 유저는 늦게 올 수도 있고, 각 유저가 프리필을 완료한 후의 세대 길이도 불확실합니다. 일부 사용자는 4개의 단어를 생성한 후 종료할 수 있지만 다른 사용자는 20개 이상의 단어를 생성해야 할 수도 있습니다.

실제 온라인 추론에서는 사전 채우기 단계에서 사용자가 실제로 다른 길이를 생성하기 때문에 문제에 직면하게 됩니다. 일부 사용자는 미리 생성하는 반면 일부 사용자는 많은 길이를 생성할 때까지 끝나지 않습니다. 이와 같은 빌드 중에 GPU가 유휴 상태가 되는 곳이 많이 있습니다. 따라서 실제 추론 프로세스에서는 QPS가 처리량을 최대한 활용할 수 없습니다. 우리의 처리량은 높을 수 있지만, 그래픽 카드를 사용할 수 없는 처리 구멍이 가득 차 있기 때문에 실제 처리 능력은 열악할 수 있습니다. 따라서 QPS 지표 측면에서 우리는 계산 허점이나 그래픽 카드를 효과적으로 활용하지 못하는 것을 방지하기 위한 많은 특정 최적화 솔루션을 보유하여 처리량이 사용자에게 완전히 도움이 될 수 있도록 할 것입니다.

2. 대규모 언어 모델 추론 성능 최적화

다음으로, 대규모 언어 모델의 추론 프로세스에 들어가서 시스템이 QPS, 처리량 및 기타 지표 측면에서 비슷한 결과를 얻을 수 있도록 어떤 최적화를 수행했는지 확인합니다. .훌륭한 상황입니다.

1. LLM 추론 프로세스

먼저 이전 기사에서 언급했듯이 각 요청은 사전 채우기와 디코딩이라는 두 단계를 거쳐야 합니다. 사전 채우기 단계에서는 최소한 네 가지 작업을 수행해야 합니다.

첫 번째는 사용자 입력을 벡터화하는 것입니다. 토큰화 프로세스는 사용자가 입력한 텍스트를 전체 사전 채우기 단계와 비교하여 벡터화하는 것을 의미합니다. , 아마도 시간의 10%를 차지할 것입니다. 이는 비용이 발생합니다.

실제 사전 채우기 계산이 수행되며 이 프로세스는 시간의 약 80%를 차지합니다.

계산 후 샘플링이 수행됩니다. 이 프로세스는 일반적으로 Pytorch에서 샘플과 상위 p를 사용합니다. Argmax는 대규모 언어 모델 추론에 사용됩니다. 전체적으로는 모델의 결과를 바탕으로 최종 단어를 생성하는 과정이다. 이 과정은 전체 시간의 10%를 차지합니다.

마지막으로 리필 결과가 고객에게 반환되는데, 이는 2%~5% 정도의 비교적 짧은 시간이 소요됩니다.

디코딩 단계에서는 토큰화가 필요하지 않습니다. 디코딩을 할 때마다 계산부터 직접 시작됩니다. 전체 디코딩 프로세스는 시간의 80%를 차지하며, 샘플링 및 단어 생성 프로세스가 진행됩니다. , 또한 시간의 10%를 차지합니다. 그러나 토큰 해제에는 시간이 걸립니다. 토큰 해제란 단어가 생성된 후 생성된 단어가 벡터이고 다시 텍스트로 디코딩되어야 함을 의미합니다. 마지막으로 생성된 단어는 시간의 약 5%를 차지합니다. 사용자에게 반환됩니다.

새로운 요청이 들어오면 미리 입력한 후 디코딩이 반복적으로 수행되며, 각 디코딩 단계 후에 결과가 그 자리에서 고객에게 반환됩니다. 이 생성 프로세스는 대규모 언어 모델에서 매우 일반적이며 이 방법을 스트리밍이라고 부릅니다.

2. 최적화: 파이프라인 전처리 및 후처리와 고성능 샘플링

여기서 소개할 첫 번째 최적화는 그래픽 카드 활용도를 극대화하는 것이 목적인 파이프라인 최적화입니다.

대규모 언어 모델 추론 과정에서 토큰화, 빠른 샘플링 및 해독 프로세스는 모델 계산과 관련이 없습니다. 이러한 과정으로 전체 대형 언어 모델의 추론을 상상할 수 있습니다. prefill을 실행하는 과정에서 빠른 샘플의 단어 벡터를 얻은 후 결과를 기다리지 않고 즉시 다음 단계의 디코딩을 시작할 수 있습니다. 결과가 이미 GPU에 있었기 때문에 반환되었습니다. 디코딩이 완료되면 디토큰화가 완료될 때까지 기다릴 필요가 없으며 다음 디코딩을 즉시 시작할 수 있습니다. 토큰 해제는 CPU 프로세스이므로 후자의 두 프로세스는 사용자에게 결과 반환만 포함하고 GPU 작업은 포함하지 않습니다. 그리고 샘플링 프로세스를 실행한 후 우리는 다음 생성된 단어가 무엇인지 이미 알고 있으며 필요한 모든 데이터를 얻었으며 다음 두 프로세스가 완료될 때까지 기다리지 않고 즉시 다음 작업을 시작할 수 있습니다.

PPL.LLM 구현에는 세 개의 스레드 풀이 사용됩니다.

첫 번째 스레드 풀은 토큰화 프로세스 실행을 담당합니다.

세 번째 스레드 풀은 후속 빠른 샘플 실행을 담당합니다. 결과 반환 프로세스 및 토큰화 해제

중간 스레드 풀은 컴퓨팅 프로세스를 실행하는 데 사용됩니다.

이 세 가지 스레드 풀은 지연의 세 부분을 서로 비동기적으로 격리하여 지연의 세 부분을 최대한 마스킹합니다. 이를 통해 시스템의 QPS가 10~20% 향상될 것이며 이는 우리가 수행하는 첫 번째 최적화입니다.

3. 최적화: 동적 일괄 처리

이후 PPL.LLM은 동적 일괄 처리라는 보다 흥미로운 최적화를 수행할 수도 있습니다.

이전 글에서 언급했듯이 실제 추론 과정에서는 사용자 세대 길이도 다르고, 사용자 도착 시간도 다릅니다. 따라서 현재 GPU가 추론 프로세스 중이라면 이미 온라인 추론에 대한 요청이 있는 상황이 발생하게 되며, 이때 두 번째 요청의 생성 프로세스가 시작됩니다. 첫 번째 요청의 생성 프로세스와 충돌합니다. GPU가 하나만 있고 이 GPU에서 작업을 직렬로만 실행할 수 있기 때문에 GPU에서 단순히 병렬화할 수는 없습니다.

우리가 하는 일은 두 번째 요청이 들어오는 시점에 첫 번째 요청에 해당하는 디코딩 단계와 사전 채우기 단계를 혼합하고 병합 단계라는 새로운 단계를 생성하는 것입니다. 이 병합 단계에서는 첫 번째 요청의 디코딩뿐만 아니라 두 번째 요청의 Prefill도 수행됩니다. 이 기능은 많은 대규모 언어 모델 추론 시스템에 존재하며, 이를 구현하면 대규모 언어 모델의 QPS가 100% 증가했습니다.

구체적인 프로세스는 첫 번째 요청 생성 프로세스가 중간에 있다는 것입니다. 즉, 디코딩 시 길이 1의 입력을 갖게 되며, 두 번째 요청이 새로 입력되어 Prefill 과정에 있게 됩니다. 길이가 48인 입력이어야 합니다. 이 두 입력을 첫 번째 차원을 따라 서로 접합하면 접합된 입력의 길이는 49, 숨겨진 차원은 4096의 입력이 됩니다. 길이가 49인 이 입력에서는 첫 번째 단어가 먼저 요청되고 나머지 48개 단어가 두 번째로 요청됩니다.

대형 모델 추론에서 RMSNorm, 행렬 곱셈, Attention 등 경험이 필요한 연산자는 디코딩에 사용하든 사전 채우기에 사용하든 동일한 구조를 갖기 때문입니다. 따라서 접속된 입력을 네트워크 전체에 직접 투입하여 실행할 수 있습니다. 우리가 차별화해야 할 부분은 바로 관심입니다. 어텐션 프로세스 또는 셀프 어텐션 연산자 실행 중에 데이터 분류를 수행하고 모든 디코딩 요청을 하나의 웨이브로 분류하고 모든 사전 채우기 요청을 다른 웨이브로 분류하고 두 가지 다른 작업을 실행합니다. 모든 사전 채우기 요청은 Flash Attention을 실행합니다. 모든 디코딩 사용자는 Decoding Attention이라는 매우 특별한 연산자를 실행합니다. Attention 연산자가 별도로 실행된 후 이러한 사용자 입력이 다시 결합되어 다른 연산자의 계산이 완료됩니다.

병합 단계에서는 실제로 각 요청이 오면 이 요청을 현재 시스템에 있는 모든 요청의 입력과 결합하고 이 계산을 완료한 다음 계속해서 디코딩을 수행합니다. 대규모 언어 모델에서 동적 일괄 처리 구현.

4. Decoding Attention

Decoding Attention 연산자는 Flash Attention 연산자만큼 유명하지는 않지만 실제로 디코딩 작업을 처리하는 데 있어서 Flash Attention보다 훨씬 빠릅니다.

이것은 디코딩 작업을 위해 특별히 설계된 연산자입니다. Cuda Core에 전적으로 의존하며 계산을 완료하기 위해 Tensor Core에 의존하지 않습니다. 매우 유연하고 수정이 용이하지만 텐서를 디코딩하는 연산이 특징이므로 입력 q의 길이는 1이어야 하지만 k와 v의 길이는 가변적이라는 한계가 있습니다. 이는 Decoding Attention의 제한 사항입니다. 이 제한 사항에 따라 몇 가지 특정 최적화를 수행할 수 있습니다.

이 특정 최적화를 통해 디코딩 단계에서 Attention 연산자를 Flash Attention보다 빠르게 구현할 수 있습니다. 이 구현은 이제 오픈 소스이며 위 그림의 URL에서 방문할 수 있습니다.

5. 최적화: VM Allocator

또 다른 최적화는 Page Attention 최적화에 해당하는 Virtual Memory Allocator입니다. 요청이 오면 사전 채우기 단계와 디코딩 단계를 거칩니다. 이 KV 캐시는 이 요청의 모든 기록 정보를 기록합니다. 그렇다면 이 생성 작업을 완료하려면 해당 요청에 얼마나 많은 KV 캐시 공간을 할당해야 할까요? 너무 많이 분할하면 비디오 메모리가 낭비됩니다. 너무 적게 분할하면 디코딩 단계에서 KV 캐시의 차단 위치에 도달하여 계속 생성할 수 없게 됩니다.

이 문제를 해결하려면 3가지 해결책이 있습니다.

Pytorch의 메모리 관리 방법은 4096 단어가 생성되도록 각 요청에 대해 충분한 긴 공간(일반적으로 2048 또는 4096)을 예약하는 것입니다. 그러나 대부분의 사용자가 실제로 생성하는 길이는 그다지 길지 않으므로 많은 메모리 공간이 낭비됩니다.

Page Attention은 또 다른 비디오 메모리 관리 방법을 사용합니다. 사용자가 생성 프로세스 중에 비디오 메모리를 지속적으로 추가할 수 있습니다. 운영 체제의 페이징 저장소 또는 메모리 페이징과 유사합니다. 요청이 오면 시스템은 요청에 대해 작은 비디오 메모리 조각을 할당합니다. 이 작은 비디오 메모리 조각은 일반적으로 8자를 생성하는 데 충분합니다. , 결과가 다시 추가될 수 있습니다. 이 비디오 메모리 블록에 쓸 때 시스템은 비디오 메모리 블록과 비디오 메모리 블록 사이의 연결 목록을 유지하므로 운영자가 정상적으로 출력할 수 있습니다. 생성된 길이가 계속 증가하면 비디오 메모리 블록의 할당이 사용자에게 계속 추가되고 비디오 메모리 블록의 할당 목록이 동적으로 유지될 수 있으므로 시스템에서 낭비되는 리소스가 많지 않습니다. 이 요청을 위해 너무 많은 비디오 메모리를 예약할 필요가 없습니다.

PPL.LLM은 가상 메모리 관리 메커니즘을 사용하여 각 요청에 필요한 생성 길이를 예측합니다. 각 요청이 들어온 후 연속 공간이 직접 할당되고 이 연속 공간의 길이가 예측됩니다. 그러나 이론적으로 달성하기 어려울 수 있으며, 특히 온라인 추론 단계에서는 각 요청에 대해 콘텐츠가 얼마나 오랫동안 생성되는지 명확하게 아는 것이 불가능합니다. 따라서 이를 수행하려면 모델을 교육하는 것이 좋습니다. Page Attention과 같은 모델을 채택하더라도 여전히 문제에 직면하게 되기 때문입니다. Page Attention 실행 프로세스 중 특정 시점, 예를 들어 현재 시스템에 이미 4개의 요청이 있고 아직 시스템에 할당되지 않은 6개의 비디오 메모리 블록이 남아 있습니다. 현재 4건의 요청이 아직 종료되지 않았고 향후 새로운 비디오 메모리 블록이 계속 추가될 수 있기 때문에 새로운 요청이 들어올지 여부와 이에 대한 서비스를 계속 제공할 수 있는지 여부를 알 수 있는 방법이 없습니다. 미래. 따라서 Page Attention 메커니즘을 사용하더라도 각 사용자의 실제 생성 기간을 예측하는 것은 여전히 ​​필요합니다. 이런 방법으로만 특정 시점에 새로운 사용자의 입력을 받아들일 수 있는지 여부를 알 수 있습니다.

이것은 PPL을 포함해 현재의 추론 시스템으로는 할 수 없는 일입니다. 그러나 가상 메모리의 관리 메커니즘을 사용하면 비디오 메모리 낭비를 상당 부분 피할 수 있으므로 시스템의 전체 QPS가 약 200%까지 증가합니다.

6. 최적화: KV 캐시 정량화

PPL.LLM이 수행하는 또 다른 최적화는 서버 측 추론 과정에서 KV 캐시가 대부분을 차지합니다. 비디오 메모리 공간으로 인해 시스템의 동시 요청 수가 심각하게 제한됩니다.

서버에서 7B 모델과 같은 대규모 언어 모델을 실행할 때, 특히 A100 및 H100과 같은 대용량 메모리가 있는 서버에서 KV 캐시가 메모리 공간의 84%를 차지한다는 것을 알 수 있습니다. , 176B와 같은 대형 모델의 경우 KV 캐시도 캐시 공간의 50% 이상을 차지합니다. 이로 인해 모델의 동시성 수가 심각하게 제한되며, 각 요청이 도착하면 많은 양의 비디오 메모리를 할당해야 합니다. 이런 방식으로는 요청 수를 늘릴 수 없으므로 QPS와 처리량을 향상시킬 수 없습니다.

PPL.LLM은 매우 특별한 양자화 방법인 그룹 양자화를 사용하여 KV 캐시의 데이터를 압축합니다. 즉, 원본 FP16 데이터를 INT8로 양자화하려는 시도가 이루어집니다. 이렇게 하면 KV 캐시 크기가 50% 줄어들고 서버가 수용할 수 있는 요청 수가 100% 늘어납니다.

Faster Transformer에 비해 처리량을 약 50% 향상할 수 있는 이유는 바로 KV 캐시 양자화로 인한 배치 크기의 증가 때문입니다.

7. 최적화: 행렬 곱셈 양자화

KV 캐시 양자화 후에 행렬 곱셈의 더 자세한 양자화를 수행했습니다. 전체 서버 측 추론 프로세스에서 행렬 곱셈은 전체 추론 시간의 70% 이상을 차지합니다. PPL.LLM은 동적 채널별/토큰별 교대 하이브리드 양자화 방법을 사용하여 행렬 곱셈을 가속화합니다. 이러한 양자화는 매우 정확하며 성능을 거의 100% 향상시킬 수 있습니다.

구체적인 방법은 RMSNorm 연산자를 기반으로 양자화 연산자를 통합하는 것입니다. 이 수량화 연산자는 RMSNorm 연산자의 기능을 기반으로 토큰 정보를 계산하고 각 토큰의 최대값과 최소값을 계산합니다. , 토큰의 차원에 따라 이 데이터를 수량화합니다. 즉, RMSNorm 이후의 데이터는 FP16에서 INT8로 변환되며, 이번에는 양자화가 완전히 동적이며 보정이 필요하지 않습니다. 후속 QKV 행렬 곱셈에서 이러한 세 가지 행렬 곱셈은 채널별로 양자화됩니다. 수신하는 데이터는 INT8이고 가중치도 INT8이므로 이러한 행렬 곱셈은 전체 INT8 행렬 곱셈을 수행할 수 있습니다. 해당 출력은 Soft Attention에 의해 승인되지만, 이번에는 역양자화 프로세스가 Soft Attention 연산자와 병합됩니다.

이후 O ​​행렬 곱셈은 양자화를 수행하지 않으며 Soft Attention 자체의 계산 프로세스도 양자화를 수행하지 않습니다. 후속 FeedForward 프로세스에서 이 두 행렬도 동일한 방식으로 양자화되어 위의 RMSNorm과 융합되거나 위의 Silu 및 Mul과 같은 활성화 함수와 융합됩니다. 솔루션 양자화 연산자는 다운스트림 연산자와 융합됩니다.

8. INT8 대 INT4

현재 대규모 언어 모델에 대한 학계의 정량적 초점은 주로 INT4에 초점을 맞출 수 있지만 서버 측 추론 과정에서는 실제로 INT8이 더 적합합니다. .

INT4 양자화는 Weight Only 양자화라고도 합니다. 이 양자화 방법의 중요한 점은 대규모 언어 모델 추론 과정에서 배치가 상대적으로 작을 때 행렬 곱셈 계산 중에 로드하는 데 90%의 시간이 사용된다는 것입니다. 프로세스. 가중치의 크기가 매우 크고, 입력을 로드하는 시간이 매우 짧기 때문에 해당 입력, 즉 활성화도 매우 짧고, 계산 시간도 그리 길지 않으며, 결과를 다시 작성하는 시간도 매우 짧습니다. 또한 그리 길지 않습니다. 이는 이 계산 하위가 메모리 액세스 집약적인 연산자임을 의미합니다. 이 경우 배치가 충분히 작은 경우 INT4 양자화를 선택합니다. INT4 양자화를 사용하여 각 가중치가 로드된 후 역양자화 프로세스가 수행됩니다. 이 역양자화는 INT4에서 FP16으로 가중치를 역양자화합니다. 이후의 계산은 FP16과 완전히 동일합니다. 즉, INT4 Weight Only의 양자화는 메모리 액세스 집약적인 행렬 곱셈에 적합합니다. 계산 프로세스는 여전히 FP16 컴퓨팅 장치에 의해 완료됩니다.

배치가 64 또는 128과 같이 충분히 큰 경우 INT4의 Weight Only 양자화는 성능 향상을 가져오지 않습니다. 배치가 충분히 크면 계산 시간이 매우 길어지기 때문입니다. 그리고 INT4 Weight Only 양자화는 배치(GEMM Batch)가 증가함에 따라 역양자화 프로세스에 필요한 계산량이 증가한다는 점에서 매우 나쁜 점이 있습니다. . 점점 길어질 것입니다. 배치 크기가 128에 도달하면 역양자화로 인한 시간 손실과 가중치 로딩으로 인한 성능 이점이 서로 상쇄됩니다. 즉, 배치 크기가 128에 도달하면 INT4 행렬 양자화는 FP16 행렬 양자화보다 빠르지 않으며 성능 이점은 최소화됩니다. 배치가 64일 때 INT4의 가중치 전용 양자화는 FP16보다 30% 더 빠르며 배치가 128일 때는 20% 정도 더 빠르거나 그보다 더 빠릅니다.

그러나 INT8의 경우 INT8 양자화와 INT4 양자화의 가장 큰 차이점은 역양자화 과정이 필요하지 않으며 계산 시간이 두 배로 늘어날 수 있다는 점입니다. 배치가 128이면 FP16 양자화에서 INT8까지 가중치를 로드하는 시간이 절반으로 줄어들고 계산 시간도 절반으로 줄어들어 100% 가속이 발생합니다.

서버 측 시나리오에서는 특히 요청이 지속적으로 유입되기 때문에 대부분의 행렬 곱셈은 계산 집약적입니다. 이 경우 궁극적인 처리량을 추구하려면 INT8의 효율성이 실제로 INT4보다 높습니다. 이는 우리가 지금까지 완료한 구현에서 주로 서버 측에서 INT8을 홍보하는 이유 중 하나이기도 합니다.

9. 최적화: FP8 vx INT8

H100, H800, 4090에서는 FP8 양자화를 수행할 수 있습니다. FP8과 같은 데이터 형식은 Nvidia의 최신 세대 그래픽 카드에 도입되었습니다. INT8의 정확도는 이론적으로 FP8보다 높지만 FP8이 더 유용하고 성능도 더 좋습니다. 또한 서버 측 추론 프로세스에 대한 후속 업데이트에서 FP8 구현을 촉진할 것입니다. 위 그림에서 볼 수 있듯이 FP8의 오류는 INT8의 오류보다 약 10배 더 큽니다. INT8은 양자화된 크기 인자를 가지며, INT8의 양자화 오류는 크기 인자를 조정하여 줄일 수 있습니다. FP8의 양자화 오류는 기본적으로 크기 요소와 무관합니다. 즉, 기본적으로 보정을 수행할 필요가 없습니다. 그러나 그 오류는 일반적으로 INT8보다 높습니다.

10. 최적화: INT4 대 비선형 양자화

PPL.LLM은 후속 업데이트에서 INT4의 행렬 양자화도 업데이트합니다. 이 가중치 전용 행렬 양자화는 주로 배치가 1로 고정되는 모바일 단말기와 같은 장치의 단말기 측에 사용됩니다. 후속 업데이트에서는 INT4에서 비선형 양자화로 점차 변경됩니다. Weight Only의 계산 프로세스에는 역양자화 프로세스가 있기 때문에 이 역양자화 프로세스는 실제로 사용자 정의 가능하며 다른 역양자화 프로세스와 양자화 프로세스를 사용하면 계산 정확도가 높아집니다.

전형적인 예는 논문에서 언급된 NF4의 양자화입니다. 이 정량화는 실제로 테이블 방법을 통해 양자화 및 역양자화됩니다. PPL.LLM의 후속 업데이트에서는 이러한 양자화를 사용하여 장치 측 추론을 최적화하려고 노력할 것입니다.

3. 대규모 언어 모델 추론을 위한 하드웨어

마지막으로 대규모 언어 모델 처리를 위한 하드웨어를 소개하겠습니다.

모델 구조가 결정되면 구체적인 계산량, 메모리 액세스가 필요한지, 계산량이 얼마나 필요한지 알 수 있습니다. 동시에 각 그래픽 카드의 대역폭, 컴퓨팅 성능, 가격 등도 알 수 있습니다. 모델의 구조를 결정하고 하드웨어 지표를 결정한 후 이러한 지표를 사용하여 이 그래픽 카드에서 대규모 모델을 추론하는 최대 처리량, 계산 지연은 얼마인지, 메모리 액세스 시간은 얼마나 필요한지 계산할 수 있습니다. 특정 테이블을 계산할 수 있습니다. 후속 정보에서 이 테이블을 공개할 예정입니다. 이 테이블에 액세스하여 대규모 언어 모델 추론에 가장 적합한 그래픽 카드 모델을 확인할 수 있습니다.

대규모 언어 모델 추론의 경우 대부분의 연산자는 메모리 액세스 집약적이므로 메모리 액세스 대기 시간은 항상 계산 대기 시간보다 높습니다. 대형 언어 모델의 매개변수 매트릭스가 실제로 너무 크기 때문에 A100/80G에서도 배치 크기가 272로 열리면 계산 지연은 작지만 메모리 액세스 지연은 더 높아집니다. 따라서 많은 최적화가 메모리 액세스에서 시작됩니다. 하드웨어를 선택할 때 우리의 주요 방향은 상대적으로 높은 대역폭과 큰 비디오 메모리를 갖춘 장비를 선택하는 것입니다. 이를 통해 대규모 언어 모델은 추론 중에 더 많은 요청과 더 빠른 메모리 액세스를 지원할 수 있으며 해당 처리량은 더 높아집니다.

위는 이번에 공유한 내용입니다. 모든 관련 정보는 네트워크 디스크에 저장됩니다. 위 링크를 참조하세요. 우리의 모든 코드는 github에서도 오픈소스로 공개되었습니다. 언제든지 우리와 소통하실 수 있습니다.

IV.Q & A

Q1: PPL.LLM에 최적화된 Flash Attention에 Softmax와 같은 메모리 액세스 문제가 있나요?

A1: Decoding Attention은 Q의 길이가 항상 1이므로 Flash Attention처럼 Softmax에서 매우 많은 양의 메모리 액세스에 직면하지 않습니다. 실제로 Decoding Attention 실행 중에는 Softmax의 완전한 실행이므로 Flash Attention만큼 빠르게 실행될 필요는 없습니다.

Q2: INT4의 가중치 전용 양자화는 왜 배치와 선형적으로 관련되어 있나요?

A2: 이것은 좋은 질문입니다. 우선 이 솔루션 양자화는 모든 사람이 생각하는 것과는 다릅니다. INT4의 가중치를 FP16에 다시 넣기만 하면 솔루션은 다음과 같습니다. 무게만큼이나. 실제로는 행렬 곱셈에 통합된 솔루션 양자화이기 때문에 그렇지 않습니다. 행렬 곱셈을 수행하기 전에 모든 가중치 솔루션을 양자화하고 거기에 놓은 다음 읽을 수는 없습니다. 이로 인해 우리가 수행하는 INT4의 양자화는 의미가 없게 됩니다. 실행 과정에서 지속적으로 양자화를 풀기 때문에 각 가중치에 대한 읽기 및 쓰기 횟수는 1이 아닙니다. 이 숫자는 실제로 배치와 관련이 있습니다. 즉, 이전의 양자화 최적화 방법과 달리 양자화 연산자와 솔루션 양자화 연산자가 별도로 존재하게 됩니다. 두 연산자를 삽입하는 경우 솔루션 양자화가 연산자에 직접 통합됩니다. 행렬 곱셈을 수행하고 있으므로 양자화를 해결하는 데 필요한 횟수가 한 번이 아닙니다.

Q3: KV 캐시의 역양자화 계산이 모방으로 가려질 수 있나요?

A3: 테스트 결과 가릴 수도 있고 실제로는 훨씬 더 많이 남아 있는 것으로 나타났습니다. KV 계산의 역양자화 및 양자화는 self attention 연산자, 특히 Decoding Attention에 통합됩니다. 테스트 결과에 따르면 이 연산자는 계산량이 10배나 필요하더라도 마스킹될 수 있습니다. 메모리 액세스 지연으로도 이를 커버할 수 없습니다. 주요 병목 현상은 메모리 액세스이며, 계산량이 메모리 액세스를 커버할 수 있는 수준에는 도달하지 못합니다. 따라서 KV 캐시의 역양자화 계산은 기본적으로 이 연산자에 대해 잘 다루어지는 것입니다.

위 내용은 고성능 LLM 추론 프레임워크의 설계 및 구현의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!