GPT-3.5나 GPT-4에 비하여 파라미터 수가 훨씬 적은 Llama-2 모델이지만, 여전히 로컬 환경이나 vRAM 크기가 작은 GPU로 실행하기에는 쉽지 않다. 다행히 가중치 양자화(quantization)를 비롯한 대규모 언어모델의 경량화 연구도 활발하게 이뤄지고 있고, 이에 따라 오픈소스 언어모델들의 양자화된 모델들이 GPTQ 또는 GGML 포맷으로 공개되고 있다.
llama.cpp 레포는 Llama 모델의 추론 프로세스를 순수한 C/C++로 구현한 프로젝트로서, 맥북에서 4-bit quantized LLaMA 모델을 실행하는 것을 목표로 한다.
그러나 Windows나 Linux 등 다양한 플랫폼에서도 사용 가능하고, 점차 많은 모델들을 지원해 나가고 있으며, 여러 프로그래밍 언어로의 바인딩도 함께 제공하고 있다(각각 Description 섹션의 Supported platforms, Supported models, Bindings 참고).
컴퓨터 비전 분야에서 주로 일하면서 NLP분야는 아는 바가 거의 없고, 대규모 언어모델(LLM)등의 최신 연구동향도 낯설기 그지 없다. 하지만 각 분야마다 foundation model이 발표되며, 멀티 모달(multi-modality) 활용의 중요성이 강조되는 시점에 맞춰, 조금이나마 기웃거리는 노력정도는 보이는 게 최소한의 도리가 아닌가 생각하고 있다.
이번 포스트에서는 LLM 공부를 시작하면서 처음 했었던, llama.cpp를 통하여, llama-2의 ggml 모델 파일들을 활용한 경험을 간단히 정리하려 한다.
LLM 모델의 경량화 포맷인 GGML과 GPTQ는 경량화 방식 등 여러 차이점이 있지만, 주로 GGML 파일은 CPU에서 빠른 추론 속도를 보이고, GPTQ는 GPU에서 빠르다고 비교되고는 한다. ggml은 처음 제안한 Gerogi Gerganov의 이름 앞 두글자와 ML을 합쳐서 이름 지은 것으로, GPU가 없는 경량환경에서도 ML모델의 동작을 가능하게 하는 Tensor library로 소개되고 있다.
GGML포맷에 관한 추가 설명은 ggml 공식 레포와 GGLM-LLM for Everyone 문서를 참고한다. 대규모 언어모델(LLM)을 배포하기 위하여 C로 작성된 바이너리 포맷으로서, 맥북 뿐만 아니라 라즈베리 파이와 같은 경량 환경에서도 이용할 수 있다. 대표적인 예가 다음의 두 가지다. (1) LLM 실행을 위한 llama.cpp (2) OpenAI의 음성인식 모델(Whisper)의 경량화된 실행 whisper.cpp
한편, llama.cpp는 CUDA를 비롯한 Metal, OpenCL 등의 GPU 백엔드를 지원하고 있어서, GPU를 일부 사용한 추론도 가능하다. 처음 테스트를 할 때, 연구서버에 GPU 메모리가 넉넉하지 않고 얼마나 많은 GPU메모리가 요구되는지 가늠하기가 어려워서, ggml 모델 파일을 사용한 cpu inference를 우선 테스트하였다. 이후 (연산의 일부를 GPU를 사용해 계산하는) GPU offloading을 통하여, 추론 속도 향상도 경험해 보았다.
설치는 깃헙 레포 Usage 섹션의 Build 과정을 따라가며 수행한다. 단, 추후에 GPU를 사용할 계획이므로, 아래의 BLAS Build 섹션의 cuBLAS 부분을 함께 참고한다. 만약 Nvidia GPU를 사용하지 않거나 다른 BLAS 라이브러리를 사용한다면, BLAS Build의 해당 과정을 따라서 진행하면 된다.
(우선은 (1) CMake를 사용하여 빌드하는 과정을 설명하고, (2) make를 사용한 빌드과정도 추가로 적었다. 개인적으로는 CMake를 활용한 빌드 과정을 선호하지만, llama.cpp에서 두 방식에 따라 a)실행 방법, b)발생할 수 있는 에러 등 차이가 존재하였어서 참고를 위하여 함께 서술하였다.)
선형대수 연산 수행을 위한 low-level 루틴에 대한 명세를 BLAS(Basic Linear Algebra Subprograms)라고 한다. BLAS연산을 Nividia GPU에서 GPU 가속을 사용해 실행하는 라이브러리가 cuBLAS이며, CUDA toolkit에 포함되어 있다.
실행에 사용한 서버의 OS 버전은 Ubuntu 20.04.6 LTS 였으며, CUDA toolkit은 11.5로 설치하였다. 참고로 10.x 버전의 오래된 툴깃에서 자주 빌드 에러를 경험하였고, (이번 테스트와는 관계 없지만) CUDA 12.x 버전은 PyTorch 설치 시아직 공식 설치 문서의 Compute Platform에 등장하지 않고, 때때로 설치 이슈를 리포트하는 글들을 접해서 11.x 로 결정하였다.
참고로 LLM 관련 라이브러리들이 빠르게 발전하는 까닭에 자주 의존성 있는 라이브러리나 패키지의 호환성 문제가 언급되지만, 현재로서는 11.5 이후의 11.x 버전에서는 llama.cpp 설치는 문제 없는 것 같다.
아래는 각각 cmake와 make를 사용한 빌드과정으로서, 어떤 방식을 택하여도 상관없다.
(1) CMake 빌드를 위해서 최종적으로 cuBLAS의 Using CMake 부분의 빌드 명령어를 사용하였다.
이 때, 빌드시스템 관리를 위해 사용하는 CMake가 설치되지 않은 경우 설치가 필요하다.
$ sudo apt-get install cmake
그런데, 이렇게 cmake를 설치할 경우 CMake Error가 발생할 수 있다. CMake를 사용하는 프로젝트는 최상위 디렉토리에 CMakeLists.txt 파일이 있어야하는데, 여기에는 빌드파일 생성을 위한 정보가 들어 있다. 이 정보 가운데에는 사용할 CMake의 최소 버전을 명시할 수 있는데, 파일의 첫번째 라인을 보면 llama.cpp는 3.12버전 이상의 cmake가 필요함을 알 수 있다. 그런데 우리는 cuBLAS 백엔드를 사용하기 위해서, -D옵션으로 캐시 엔트리를 생성하였다. 캐시(cache)는 일종의 설정 파일과 같아서, 프로젝트의 기본 설정값보다 우선 순위를 갖는다. 즉, llama.cpp의 LLAMA_CUBLAS 옵션을 ON 상태로 사용하려고 한다. 이렇게 되면, 281번째 라인의 분기에 따라 요구되는 cmake의 최소 버전이 3.17이 되게 된다. 우분투를 비롯한 데비안(debian) 계열의 패키지 관리자인 apt는 apt-cache policy 명령어를 통해 apt의 내부 데이터베이스에 저장된 패키지 관련 정보를 볼 수 있다. 이를 통해 cmake의 정보를 확인하면 아래와 같다.
즉, apt install을 통해 기본으로 설정되는 cmake 버전은 (2023년 9월 현재) 3.16임을 알 수 있다. 이러한 이유 때문에 직접 최신버전을 받아서 설치하는 작업이 필요하다. cmake 설치파일들은 깃헙 레포의 release 또는 공식 페이지의 Download에서 확인할 수 있다. (2023년 9월 26일 현재 최신버전인) 3.27.6을 설치한다.
$ wget https://github.com/Kitware/CMake/releases/download/v3.27.6/cmake-3.27.6.tar.gz
$ tar -zxvf cmake-3.27.6.tar.gz
$ cd cmake-3.27.6
$ ./bootstrap
$ make
$ sudo make install
혼란을 피하기 위해서, 다른 디렉토리에서 cmake의 다운로드와 설치를 진행하였다.
(2) 한편, CMake 대신 make를 사용하는 경우의 빌드 명령어는 다음과 같다 (여기에서도 역시 GPU사용을 위하여, cuBLAS 빌드 섹션의 명령어를 사용한다).
$ make LLAMA_CUBLAS=1
BLAS build를 선택하고 않고 그냥 make 명령어만 사용하여 빌드했을 때와 달리, 위처럼 cuBLAS 사용을 위한 빌드 진행 시사용환경에 따라nvcc fatal 에러가 발생할 수 있다. CMake가 CMakeLists.txt를 사용한다면, make 명령어는 Makefile을 사용한다. 예를 들어 위의 빌드과정에서 LLAMA_CUBLAS 플래그의 분기를 확인하려면, Makefile의 332번째 라인을 살펴보면 된다. Nvidia CUDA Compiler를 의미하는 nvcc는 Nvidia GPU에서 병렬 연산을 지원하는 CUDA를 사용할 수 있도록 작성된 .cu 파일을 위한 컴파일러다. CUDA Toolkit을 설치할 때 함께 설치되며, (2023년 9월 현재) 최신 툴킷인 CUDA Toolkit 12.2와 함께 릴리즈된 공식문서의 nvcc 설명을 참고한다. Makefile에 따르면 llama.cpp는 ggml-cuda.cu와 ggml-cuda.h를 이용해 목적파일 ggml-cuda.o를 생성하기 위하여(384번째 라인) nvcc를 사용한다. 이 과정에서 여러 줄에 걸쳐 추가된 nvcc 컴파일옵션(Makefile의 NVCCFLAGS)을 함께 사용한다. 앞서 언급한 에러의 경우, 에러 메세지는 다음과 같다.
nvcc fatal : Value 'native' is not defined for option 'gpu-architecture'
즉, 이 에러는 nvcc의 --gpu-architecture(-arch) 옵션을 native 값으로 지정한 탓에 일어난 에러임을 알 수 있다. nvcc 공식문서의 설명에 따르면, 이 옵션은 컴파일 때 사용할 vGPU(virtual GPU)의 클래스 이름을 명시하기 위해 사용한다. 보통 이 값은 GPU가 사용할 CUDA의 특성과 관계되는 compute capability 값으로 나타낸다. 정확한 compute capability 값을 찾아서 지정하려면, 사용하고 있는 그래픽카드의 종류를 확인한 후 Nvidia의 Compute capability 표에서 확인할 수 있다. 우분투에서는 그래픽카드의 종류를 확인하려면 다음의 명령어를 사용할 수 있다.
$ nvidia-smi --query | fgrep 'Product Name'
개인적으로 이번 포스트에 사용한 GPU는 Tesla V100 이었는데, Compute capability는 7.0(compute_70 또는 sm_70)임을 알 수 있었다. Makefile에서 --gpu-architecture(-arch)를 지정하는 부분은 345번째 라인인데, 이 부분을 아래처럼 바꾸면 nvcc 에러가 사라지고 정상적으로 빌드할 수 있다.
NVCCFLAGS += -arch=compute_70
하지만 이처럼 공개되는 코드에서 특정 사용자 환경에 맞게 플래그를 설정하는 것은 그다지 바람직하지 않다. 이 때문에 llama.cpp의 Makefile에서는 시스템에 존재하는 GPU를 nvcc가 스스로 탐색하여 그에 맞게 컴파일하고 코드를 생성하도록 -arch 옵션을 native로 설정해두었다. 위에서 이번 에러가 "사용환경에 따라 발생할 수 있다"고 하였다. 이번 포스트를 위해, 여기서는 CUDA Toolkit을 11.5 버전으로 설치했다고 밝혔었다. 위에 추가한 현시점 기준 최신 툴킷인 12.2의 nvcc 공식문서 대신 기존 11.5버전의 nvcc 공식문서를 찾아서 비교하면 에러의 이유를 확인할 수 있다. 11.5 버전에서는 -arch 에 허용되는 값 중에 native가 정의되어 있지 않았던 것이 nvcc fatal 에러의 원인이다. 그래서 다양한 CUDA Toolkit에서도 (버전)문제 없이 빌드가 되며 또 직접 compute capability를 구하지 않으려면, -arch 값을 all로 설정하는 것이 가장 간단한 해결책이다. llama.cpp와 유사한 경량화 프로젝트 whisper.cpp의 실행에도 동일한 오류와 해결책이 논의되어서 링크를 함께 남긴다.
NVCCFLAGS += -arch=all
경량화된 LLaMA-2 모델 준비
llama.cpp 레포의 Prepare Data & Run 섹션에서는 원래의 LLaMA 모델로부터 직접 양자화된 경량모델을 생성하는 코드를 안내하고 있다. 하지만 이번 포스트는 LLM의 로컬에서의 실행을 경험하는 것이 목표이기 때문에, 공유되어 있는 경량모델을 받아서 사용하려고 한다. 허깅페이스(Hugging Face)의 TheBloke는 다양한 오픈소스 언어모델을 경량화하여 공개하는 유저로 유명하다. 더불어 각 모델 카드마다 사용 방법, 양자화 모델의 실행 스펙, 기타 프로젝트에서의 활용 방법 등의 세부 사항을 함께 제공하기 때문에, LLM을 학습하기에 적합하다.
TheBloke/Llama-2-13B-chat-GGML 모델 카드에서도 밝히고 있다시피, GGML 포맷은 GGUF 포맷으로 대체되었고, llama.cpp는 2023년 8월 21일 시점에 더이상 GGML 모델을 지원하지 않는다고 한다. 따라서 2023년 9월 현재, 그리고 이후의 llama.cpp에서는 GGML 모델을 통한 실행이 불가능하고 GGUF 모델 파일을 받아서 실행시켜야 한다. 그럼에도 GGML 모델을 기준으로 이번 포스트의 설명을 시작한 까닭은 2023년 7월 말 Llama-2 공개 이후, 개인적으로 실습할 수 있는 자원이 넉넉하지 못한 상황에서 처음 사용해본 모델이었고, 덕분에 여러모로 부족하더라도 언어모델 학습을 시작하게 된 계기가 되었기 때문이다. 또, 대규모 언어모델(LLM)을 제한된 컴퓨팅 리소스에서도 실행하게 하려는 목표와 의도가 특히 감동적이었고, (누군가에게는 쓸모 없을 수 있지만) 빌드 및 모델 준비 과정에서 배울 바가 더욱 많았다고 생각한다. 다행히 llama.cpp는 GGUF 모델 파일을 다운로드 하여서 실행할 것을 권장하며서도, GGML 파일을 GGUF로 변환하는 코드를 제공하고 있다. (convert-llama-ggml-to-gguf.py)
변환된 모델의 다양한 양자화 버전은 Files and versions 탭에서 확인할 수 있다. 이 중 4-bit quantization 모델 중에서 llama-2-13b-chat.ggmlv3.q4_0.bin 파일을 받아서 사용하려고 한다. 편의상 앞으로 다운로드하는 모델 파일들은 models/ 디렉토리에 저장하여 관리하려고 한다.
우선, 파일 옆의 다운로드 버튼을 우클릭하여 링크 주소를 복사해준다.
wget 명령어로 해당 모델을 다운로드한다. 앞서 설명했듯이 모델 파일은 사용 상의 통일성을 위해서 models 디렉토리 안에 저장한다.
$ cd models
$ wget https://huggingface.co/TheBloke/Llama-2-13B-chat-GGML/resolve/main/llama-2-13b-chat.ggmlv3.q4_0.bin
GGUF 포맷으로의 변환은 다음 절에서 서술한다.
실행 전 참고 사항
LLaMA-2의 경량화 모델까지 준비되면, 이제 컴파일 후 생성된 실행 파일을 모델 경로와 함께 실행시켜서 llama.cpp에서 제공하는 다양한 사용방식으로 Llama-2를 활용할 수 있다. 그런데 여기서 고려해야 할 사항이 두 가지 있다.
(1) 실행 파일의 생성 위치
첫 번째로어떤 방식으로 빌드했는지(Cmake vs make)에 따라서 main 파일과 같은 실행 파일의 생성 위치가 달라진다는 것이다. CMake를 사용하는 빌드 과정에서는 llama.cpp의 최상위 디렉토리에서 build라는 빌드용 디렉토리를 만들어서 그 안에서 빌드를 진행하였다. 최종 실행 파일이 생성되는 디렉토리 경로는 CMakeLists.txt에서 변수로 지정된다.(CMAKE_RUNTIME_OUTPUT_DIRECTORY 변수) 11번째줄에서 이 위치를 \${CMAKE_BINARY_DIR}/bin 으로 지정하였다. 이 때, \${CMAKE_BINARY_DIR}는 빌드 트리가 시작되는 경로로서 여기서는 build 디렉토리가 되며, 이에 따라 main을 비롯한 각종 실행 파일이 위치한 경로는 build/bin/ 이 될 것이다.
반면에 make를 사용하게 된 경우, 소스 코드가 있는 최상위 경로에 각종 실행파일이 생성되도록 Makefile이 작성되어 있다. (main의 경우 Makefile 513번째줄, 따로 타겟의 경로가 지정되어 있지 않다)
(2) GGML 모델 파일을 GGUF 포맷으로 변환
두 번째로 위에서 언급했듯이 2023년 9월 현재 GGML 파일은 더이상 llama.cpp에서 실행이 불가능하기 때문에, GGUF포맷의 파일을 대신 사용하거나, GGML 파일을 GGUF 파일로 변환해야 한다. 위에서 내려받은 Llama-2-13B-chat-GGML 모델은 Meta가 처음 공개했던 Llama-2 모델 중에서 13B의 파라미터를 가진 chat model을 GGML로 변환한 것이다.(HuggingFace에 공개된 meta-llama/Llama-2-13b-chat-hf 참고) 이에 대응되는 GGUF 모델은 theBloke/Llama-2-13B-chat-GGUF 에서 확인할 수 있다. 이 중 위의 파일과 동일한 양자화방법으로 변환된 llama-2-13b-chat.Q4_0.gguf 파일을 저장하여 사용할 수 있다.
$ cd models
$ wget https://huggingface.co/TheBloke/Llama-2-13B-chat-GGUF/resolve/main/llama-2-13b-chat.Q4_0.gguf
(한번 더 언급하지만, 단순히 실행 테스트를 위한 목적이었고 최적의 성능 탐색을 위한 모델 파일 선정은 아니었다.)
또는 llama.cpp에서 제공해주는 convert-llama-ggml-to-gguf.py를 이용해서 ggml 파일을 gguf 파일로 변환할 수 있다. 변환은 (1) 입력으로 사용할 ggml 파일 경로와 (2) 출력할 gguf 파일의 경로를 함께 입력하면 된다. 단, Llama-2은 다른 LLM과 다르게 컨텍스트 길이가 4096 토큰인 장점을 가지고 있고, 이를 반영하려면 (기본 설정값이 2048대신에) 4096을 함께 명시해주는 편이 좋다.
examples 디렉토리 안에는 이러한 추가 내용에 대한 설명과 C/C++로 작성된 소스 코드도 함께 제공되고 있다. 여기에서는 그 중에서 llama.cpp/example/main 의 관련 내용에 따라 main 이라는 실행파일로 컴파일되는 부분을 살펴보려고 한다. 이 파일은 (1) CLI 창에서 인자(argument)로 함께 입력한 프롬프트에 대해 응답하거나 (2) CLI에서 Chatbot과 같은 interactive 사용자 경험을 제공하는 단일 실행 파일이다.
실행을 할 때 함께 입력할 수 있는 다양한 옵션이 존재하는데, 이 중 간단히 사용할 때 알아야하는 몇 가지만을 여기에서 설명 한다. 전체 내용과 세부사항은 연관 문서를 확인한다.
-m (--model) : 사용할 모델 파일의 경로
--prompt : LLM에 입력한 프롬프트 내용을 지정
연관문서에서는 리눅스 등의 유닉스 기반 시스템에서 가장 간단한 실행방법(Quick Start)에 관하여 위의 두 가지 옵션을 설명한다.
위의 예시에서는 텍스트 생성(Text-generation)을 목표로 하는 기본 LLM 모델의 실행을 전제로 하였기 때문에, 문단이 시작하는 첫 문장을 프롬프트로 입력하였다. 아마도 예시의 실행결과는 "Once upon a time"으로 시작하는 단락일 것이다. 그러나 이번 포스트에서는 사람의 질문에 응답할 수 있도록 조정된(instruction-tuned) Chat-model을 사용하였기 때문에, 프롬프트에 함께 입력한 지시를 따르거나, 프롬프트의 질문 내용에 대한 응답을 생성하여 답변하게 된다. 예제로 "Tell me about Seoul in Korea" 를 프롬프트로 사용하여 LLaMA-2가 서울에 대한 설명을 답변하도록 요구하였다.
# built with CMake
$ ./build/bin/main -m ./models/llama-2-13b-chat.ggmlv3.q4_0.gguf\
--prompt "Tell me about Seoul in Korea"
# build with make
$ ./main -m ./models/llama-2-13b-chat.ggmlv3.q4_0.gguf\
--prompt "Tell me about Seoul in Korea"
응답의 생성 속도와 같은 성능은 다음 2가지 실행 옵션에 따라 달라질 수 있다.
-t (--threads) : 텍스트 생성에 사용하는 쓰레드의 수
-ngl (--n-gpu-layers) : 성능 향상을 위하여 GPU에 offloading할 레이어의 수
실험해보려는 위의 옵션 이외에 동일한 생성 결과를 가지고 비교하기 위하여, 생성의 무작위성을 뜻하는 temperature 옵션(--temp)을 0으로 설정하였다. 이에 따라 생성된 텍스트는 아래와 같았다.
다음의 다섯가지 테스트는 (1) CPU 쓰레드의 수와 (2) GPU에서 연산하는 offloading 레이어 수를 변경해 가면서, 초당 토큰 생성 속도 등을 비교한 실험이다.
테스트 1) CPU 스레드 1개 사용, GPU offloading 사용하지 않았을 때
테스트2) CPU 스레드 16개 사용, GPU offloading 사용하지 않았을 때
테스트3) CPU 스레드 1개 사용, 모든 레이어를 GPU offloading
테스트4) CPU 스레드 16개 사용, 절반의 레이어를 GPU offloading
테스트 5) CPU 스레드 16개 사용, 모든 레이어를 GPU offloading
비록 (1) 엄밀하게 설정된 테스트 조건이 아니었고, (2) 반복 실험에 의한 결과 분석이 아니었기 때문에, 실험 결과를 객관적으로 받아들이는 것은 어렵다. 하지만 간단한 실험에서도 보이는 비교 결과로부터, 아래의 내용들을 알 수 있었다.
CPU 쓰레드의 수를 증가시키는 것보다 GPU offloading을 이용하는 것이 답변 생성 속도를 더욱 크게 증가시켰다.
GPU offloading하는 레이어 수와 이에 따른 생성 속도는 선형관계가 아니어서, GPU에서의 연산량을 증가시킬수록 텍스트 생성 속도는 더욱 크게 증가하였다.
-ngl 옵션의 값이 실제 경량화모델의 레이어 수보다 크더라도, 오류 없이 최대한 offloading하기 때문에 가능한 GPU 메모리를 모두 사용할 수 있도록 하는 것이 성능상의 이득이 크다.
테스트 5)의 결과로부터 GPU에 최대한 연산을 할당할 수 있으면, 비록 할당한 CPU 쓰레드가 크더라도 강제로 점유하지는 않는다.
테스트 1) 등에서 볼 때, GPU를 사용하지 않더라도 GPU 메모리를 점유하는 일이 있었다.
GPU를 사용하기 위해서 cuBLAS를 활용해 빌드하는 과정때문에, offloading 여부와 관계없이 실행 할 때 연관 라이브러리 등을 GPU에 로드하는 건 아닌지 확인할 필요가 있어 보인다.
llama와 Alpaca 그리고 llama-2로부터 촉발된 오픈 소스 대규모 언어모델 연구들이 매우 활발하게 이뤄지고 있고, LLM을 사용하는 애플리케이션 개발을 쉽게 만들어주는 LangChain, Semantic Kernel 같은 프레임워크도 빠르게 업데이트 되고 있다. 그리고 여기에 소개된 llama.cpp처럼 경량환경을 지원해주는 프로젝트들 덕분에, 개인이 해볼 수 있는 응용의 범위도 크게 넓혀졌다고 생각한다. 그리고 무엇보다 LLM을 활용하는 작업들은 즐겁다. 비록 여기 올린 내용은 실행방법을 정리한 간단한 글이지만, 구석구석 올려진 상세하고 깊이있는 좋은 글들만으로도 지식의 지평을 넓히기 충분하다고 생각한다. 더 많은 사람들이 관심을 가지고 참여하여, 또 새롭고 참신한 연구가 소개되기를 기대해본다.
댓글