Numbers every LLM Developer should know

github : https://github.com/ray-project/llm-numbers

 

"구글에서 전설적인 엔지니어인 제프 딘이 '모든 엔지니어가 알아야 할 숫자들”이라는 문서를 작성했습니다. LLM 개발자들이 역 앤벨로프 연산과 유사한 숫자 셋을 가지고 있다는 것은 유용하다는 것을 알 수 있습니다. 여기에서 우리는 Anyscale에서 사용하는 특정 숫자, 숫자가 중요한 이유 및 이점을 활용하는 방법을 공유합니다.

Notes on the Github version

Last updates: 2023-05-17

 

숫자의 정확성에 문제가 있다고 생각되면 문제를 제기하십시오. 이 문서에 있어야 할 숫자가 더 있다고 생각하십니까? 저희에게 알리거나 PR을 제출하십시오. 다음으로 여기에 추가해야 할 것은 서로 다른 모델의 초당 토큰에 대한 통계입니다.

 

Prompts

40-90%1: Amount saved by appending “Be Concise” to your prompt

응답할 때 토큰 단위로 비용이 청구되는 것을 기억하는 것이 중요합니다. 이는 LLM에게 간결하게 답변을 요청하면 많은 비용을 절약할 수 있다는 것을 의미합니다. 이는 단순히 "간결하게 해주세요"라는 문구를 프롬프트에 추가하는 것을 넘어서 확장될 수 있습니다. 예를 들어, GPT-4를 사용하여 10개의 대안을 만들어 달라고 요청하는 대신 5개만 요청하여 남은 절반의 비용을 절약할 수 있습니다.

 

Average tokens per word

LLM은 토큰을 기반으로 작동합니다. 토큰은 단어나 단어의 일부로, 예를 들어 "eating"은 "eat"과 "ing" 두 개의 토큰으로 분할될 수 있습니다. 영어로 된 750단어 문서는 약 1000개의 토큰으로 이루어집니다. 하지만 영어 이외의 언어는 LLM의 임베딩 코퍼스에서의 공통성에 따라 토큰 당 단어 수가 증가합니다.

 

이 비율을 알고 있는 것은 중요합니다. 왜냐하면 대부분의 청구는 토큰 단위로 이루어지며, LLM의 문맥 창 크기도 토큰 단위로 정의되기 때문입니다.

 

Prices

가격은 물론 변동될 수 있지만, LLM 운영 비용이 매우 비싸기 때문에 이 섹션의 숫자들은 매우 중요합니다. 우리는 여기서 숫자를 위해 OpenAI를 사용하지만, 다른 공급자인 Anthropic, Cohere의 가격은 비슷한 수준일 것입니다.

Cost Ratio of GPT-4 to GPT-3.5 Turbo

이 말은 많은 실제 응용에서는 GPT-4를 고품질의 fine - tuning 데이터 생성이나 다른 모델의 자동 평가와 같은 작업에 사용하는 것이 훨씬 더 좋다는 뜻입니다. – 이는 한 번만 수행할 수도 있는 작업들을, 추론 주기 중간에 지속적으로 수행하는 것 대신 한 번만 수행하는 것을 의미합니다. GPT-3.5-Turbo를 사용하는 것은 GPT-4를 사용하는 것보다 대략 50배 더 저렴합니다. ("대략"은 GPT-4가 프롬프트와 생성된 출력에 대해 다르게 청구하기 때문입니다.) 따라서, GPT-3.5-Turbo로 얼마나 나아갈 수 있는지 꼭 확인해야 합니다. GPT-3.5-Turbo는 요약과 같은 작업에는 충분히 적합합니다.

Cost Ratio of generation of text using GPT-3.5-Turbo vs OpenAI embedding

이는 벡터 저장소에서 무언가를 찾는 것이 LLM에게 생성을 요청하는 것보다 훨씬 더 저렴하다는 의미입니다. 예를 들어, "Delaware의 수도는 무엇인가요?"라고 뉴럴 정보 검색 시스템에서 찾을 때, GPT-3.5-Turbo에게 물어보는 것보다 약 5배 4분의 1 만큼 비용이 적게 듭니다. GPT-4와 비교해서 비용 차이는 놀라운 250배입니다!

 

Cost Ratio of OpenAI embedding to Self-Hosted embedding

Note : 이 숫자는 부하와 임베딩 배치 크기에 민감하므로, 이는 대략적인 값으로 고려해주세요.

 

저희 블로그 글에서는 g4dn을 사용하는 것에 대해 언급했습니다.

 

 

4xlarge (온디맨드 가격: 1.20달러/시간)를 사용하여 Hugging Face의 SentenceTransformers(OpenAI의 임베딩과 거의 비슷한 성능을 보입니다)로 대략 9000개의 토큰을 초당 임베딩할 수 있었습니다. 그 속도와 노드 유형에 대해 기본적인 계산을 하면, 자체 호스팅 임베딩이 상당히 더 저렴하다는 것을 나타냅니다 (비용이 10배 낮다는 의미입니다). 이는 인그레스 및 이그레스 수수료와 같은 추가 비용을 생각하기 전의 상태입니다.

 

Cost Ratio of OpenAI fine tuned vs base model queries

 

OpenAI에서 fine-tuning된 모델을 제공하는 데는 base 모델을 제공하는 데에 비해 6배 더 많은 비용이 듭니다. 이는 꽤 과도한 비용이지만, 기본 모델의 multi-tenancy 가능성 때문에 합리적일 수 있습니다.

(멀티테넌시(Multi-tenancy)는 단일 소프트웨어 인스턴스가 클라우드에서 실행되고 해당 단일 인스턴스가 여러 고객에게 서비스를 제공하는 아키텍처 접근 방식입니다.) 이는 base 모델의 프롬프트를 조정하는 것이 customized 모델을 fine - tuning 하는 것보다 훨씬 더 비용 효율적이라는 것을 의미합니다.

 

Training and Fine Tuning

~$1 million: Cost to train a 13 billion parameter model on 1.4 trillion tokens - $1 million : 1,400조 개의 토큰을 사용하여 130억 개의 파라미터 모델을 훈련하는 데 드는 비용

 

LLaMa 논문에 따르면 2048개의 A100 80GB GPU를 사용하여 LLaMa 모델을 훈련하는 데에는 21일이 소요되었습니다. 우리는 Red Pajama 훈련 세트를 사용하여 자체 모델을 훈련하는 것을 고려했고, 그 후에 계산을 실행했습니다. 위의 내용은 모든 것이 순조롭게 진행되고, 아무런 충돌 없이 계산이 처음에 성공한다고 가정한 것입니다. 그리고 이것은 2048개의 GPU를 조정하는 작업을 포함합니다. 대다수 기업들이 할 수 있는 일이 아닙니다. 요점은 자체 LLM을 훈련하는 것이 가능하지만, 저렴하지 않다는 점입니다. 그리고 각 실행마다 실제로 몇 일이 걸릴 수 있습니다. 미리 훈련된 모델을 사용하는 것이 훨씬 더 저렴합니다.

< 0.001: Cost ratio of fine tuning vs training from scratch

이것은 약간 일반화된 주장이지만, fine-tuning 비용은 무시할 수 있을 정도로 적습니다. 우리는 예를 들어 6B 파라미터 모델을 약 7달러로 세밀하게 조정할 수 있다는 것을 보였습니다. OpenAI의 가장 비싼 fine-tunable 모델인 Davinci의 가격으로도 1000개의 토큰당 3센트입니다. 이것은 전체 셰익스피어 작품(약 100만 단어)을 세밀하게 조정하는 데에는 405달러가 필요하다는 뜻입니다. 하지만 fine-tuning은 한 가지이고, 처음부터 훈련하는 것은 또 다른 문제입니다...

GPU Memory

만약 모델을 자체 호스팅하는 경우, GPU 메모리를 이해하는 것이 정말 중요합니다. LLM은 GPU 메모리를 한계까지 사용하게 됩니다. 다음 통계는 특히 추론에 관한 것입니다. 훈련이나 세밀 조정을 위해서는 훨씬 더 많은 메모리가 필요합니다.

 

V100: 16GB, A10G: 24GB, A100: 40/80GB: GPU Memory Capacities

 

이것은 이상하게 느껴질 수 있지만, 다른 종류의 GPU가 가지고 있는 메모리 양을 알아두는 것이 중요합니다. 이로 인해 LLM이 가질 수 있는 파라미터의 수가 제한될 것입니다. 일반적으로 우리는 AWS 온디맨드 가격으로 각각 1.50달러에서 2달러의 비용을 지불하고 24G의 GPU 메모리를 가지고 있는 A10Gs를 선호합니다. 반면, A100은 AWS 온디맨드 가격으로 약 5달러에 구매할 수 있습니다.

2x number of parameters: Typical GPU memory requirements of an LLM for serving

예를 들어, 70억 개(7B)의 파라미터를 가진 모델은 약 14GB의 GPU 공간이 필요합니다. 이는 대부분의 경우 하나의 16비트 float (또는 2바이트)가 각 파라미터마다 필요하기 때문입니다. 보통 16비트 정확도를 넘어가는 것이 필요하지 않으며, 8비트 정확도로 넘어가면 대부분 해상도가 저하되는 경향이 있습니다 (일부 경우에는 허용 가능할 수 있습니다). 물론 이를 줄이기 위한 노력들이 있습니다. 특히 llama.cpp는 13억 개의 파라미터 모델을 6GB GPU에서 4비트로 강력하게 양자화하여 실행합니다(8비트로도 큰 영향 없이 실행 가능합니다). 하지만 이는 일반적이지 않습니다.

 

~1GB: Typical GPU memory requirements of an embedding model

문장 임베딩을 할 때(군집화, 의미 검색 및 분류 작업에서 일반적으로 수행하는 작업), sentence transformers와 같은 임베딩 모델이 필요합니다. OpenAI도 상업적으로 제공하는 자체 임베딩을 가지고 있습니다. 일반적으로 GPU에서 임베딩이 얼마나 많은 메모리를 차지하는지 걱정할 필요가 없습니다. 임베딩은 상당히 작기 때문입니다. 실제로 우리는 임베딩과 LLM을 같은 GPU에서 실행한 적이 있습니다.

 

>10x: Throughput improvement from batching LLM requests

GPU를 통해 LLM 쿼리를 실행하는 것은 매우 높은 지연 시간을 가지며, 예를 들어 5초가 소요될 수 있으며, 초당 0.2개의 쿼리 처리량을 가질 수 있습니다. 재미있는 점은, 두 가지 작업을 실행하면 단지 5.2초가 소요될 수 있다는 것입니다. 이는 25개의 쿼리를 함께 묶을 수 있다면 약 10초가 소요되며, 처리량이 초당 2.5개의 쿼리로 개선된다는 것을 의미합니다. 하지만 다음 항목을 확인하세요.

 

~1 MB: GPU Memory required for 1 token of output with a 13B parameter model

필요한 메모리 양은 생성하려는 최대 토큰 수와 직접 비례합니다. 그래서 예를 들어, 최대 512개의 토큰(약 380단어)까지 출력을 생성하려면 512MB가 필요합니다. 큰 문제가 없다고 말할 수 있을 겁니다.

 

남아있는 24GB가 있는데, 512MB는 뭐길래? 하지만 더 큰 배치를 실행하려면 누적됩니다. 따라서 배치를 16개로 실행하려면 8GB의 공간이 필요합니다. 이를 극복하기 위해 몇 가지 기술이 개발되고 있지만, 여전히 실제 문제가 됩니다.