GN⁺: LLaMA, 이제 CPU에서 더 빠른 속도로 작동

LLaMA의 CPU에서의 속도 향상

• Mozilla의 llamafile 프로젝트에서 84개의 새로운 행렬 곱셈 커널을 작성함
• F16과 Q8_0 가중치를 CPU에서 사용할 때 llama.cpp에 비해 프롬프트 평가 시간이 30%에서 500% 더 빨라짐
• ARMv8.2+ (예: RPI 5), Intel (예: Alderlake), AVX512 (예: Zen 4) 컴퓨터에서 가장 극적인 개선이 이루어짐
• L2 캐시에 맞는 행렬에 대해 MKL보다 2배 빠른 속도를 보임
• 1,000개 미만의 토큰을 가진 프롬프트에 대해 속도 향상이 가장 잘 작동함

배경

• llamafile은 2023년 11월 Mozilla와 함께 시작한 로컬 LLM 프로젝트임
• Cosmopolitan Libc를 사용하여 llama.cpp를 단일 파일 크로스 플랫폼 바이너리로 패키징함
• AMD64와 ARM64용 6개 OS에서 실행되며 약간의 수정이 이루어짐
• 핵심 기술을 개선함으로써 사용자에게 최상의 llama.cpp 경험을 제공하고 두 프로젝트가 더 넓은 청중에 다가갈 수 있도록 도울 수 있다고 믿음
• Mozilla는 이를 위한 리소스를 제공해 왔음

엔터프라이즈 하드웨어에서의 성능 향상

• 처음 LLM에 관심을 가졌을 때 작업 환경은 회전 디스크, 느린 RAM, AVX2 프로세서, GPU 없이 Alpine을 실행하는 검소한 Hewlett Packard였음
• llama.cpp가 마음에 들었던 점은 그들이 자신과 같은 사람들을 가장 먼저 신경 썼다는 것임
• 전임으로 자원 봉사를 시작했고 Slaren과 같은 사람들과 협력하여 mmap() 지원을 도입했는데, 이는 RAM 사용량을 절반으로 줄이면서 가중치를 즉시 로드할 수 있게 해줌
• 당시 로컬 LLM에 있어 큰 도약이었지만 평가 속도 개선에는 거의 기여하지 못함
• 추론 코드의 대부분은 Georgi Gerganov 자신이 작성했으며 너무 훌륭해서 결국 1년이 더 걸려서야 개선할 수 있었음
• 이제 개선했으니 옛 Hewlett Packard에서 얼마나 더 빨라졌는지 살펴보자는 것

취미용 하드웨어에서의 성능 향상

• 대형 컴퓨터가 없어도 대형 언어 모델을 실행할 수 있음
• 오늘날 매장에서 구할 수 있는 최고의 개인용 컴퓨터 중 하나는 Raspberry Pi임
• 저렴한 가격에 우수한 성능을 제공하며 전력 소모량이 매우 적음
• Raspberry Pi는 5세대를 며칠 전에 출시했는데 이전 모델에 비해 엄청나게 빠름
• ARMv8.2 dotprod 및 fp16 산술 ISA에 대한 지원도 도입했는데, 이는 LLM에 매우 유용함
• 이 두 가지 기능만으로도 작년에 llama.cpp가 f16 가중치에 대해 10배의 성능 향상을 달성할 수 있게 해줌
• 이번 주에는 원래 AVX512를 위해 의도했던 커널을 사용하여 그 위에 2배의 성능 향상을 더 이끌어냄
• 데이터 센터 장비용으로 설계된 커널이 작고 가벼운 Raspberry Pi에 잘 맞을 거라고는 생각하지 못했지만, 두 CPU 모두 32개의 벡터 레지스터를 가지고 있기 때문에 실제로 딱 들어맞았음

게이밍 하드웨어에서의 성능 향상

• 게이머는 가치 소비자 중 가장 높은 품질 기대치를 가지고 있어서 게이머를 위해 만들어진 하드웨어는 보통 꽤 훌륭함
• 기계 학습 업계에서는 게이머를 위한 하드웨어를 전용하여 수년간 번성해 왔음
• 게이머들의 중요한 기여가 없었다면 AI 겨울은 10년 더 지속되었어야 했을 것임
• 몇 달 전, 옛 Hewlett Packard를 대체할 수 있는 컴퓨터를 만들어달라고 게이머에게 부탁함
• Alderlake는 훌륭한 CPU라고 생각하지만 float16 성능을 5배나 쉽게 높일 수 있었던 것으로 보아 널리 오해받고 있음
• ARMv8.2와 달리 x86 커널은 내부적으로 float32 연산 유형을 사용하므로 반올림 오차를 발생시키지 않고 그렇게 할 수 있었음
• 이는 더 스마트한 스팸 필터를 만들 수 있음을 의미함
• spam.sh 셸 스크립트를 실행하면 420밀리초밖에 걸리지 않는데, 이는 Raspberry Pi 5보다 7배 빠른 것임
• 작은 작업량에 있어서는 CUDA가 시작되기도 전에 이 칩이 마무리할 수 있는 것
• Alderlake 소유자들은 llamafile이 효율성 코어에서 실행되지 않도록 특별히 주의를 기울인다는 사실을 기대할 수 있음
• 이는 llamafile이 llama.cpp보다 빠르게 실행되는 데 도움이 되는 것들 중 하나임
• 또한 LLM을 24시간 내내 실행해도 컴퓨터의 다른 프로그램에 여전히 충분한 리소스가 남아 있음을 의미함
• llama.cpp는 쓰레드를 lockstep으로 디스패치하므로, 1개의 코어가 다른 코어보다 오래 작업을 수행하면 다른 모든 n개의 코어가 완료될 때까지 busy loop를 수행해야 했을 것임
• 이 마이크로프로세서의 가장 큰 특징은 Cosmopolitan monorepo의 260만 줄의 코드를 얼마나 빨리 빌드할 수 있는지임
• Hewlett Packard는 항상 64초가 걸렸지만 이 게이밍 컴퓨터는 20초면 됨
• 원래는 35초가 걸렸는데, 액체 금속과 AI 오버클로킹을 적용하여 더 빨라졌음
• Alderlake에서 시스템 코드가 매우 빠른 또 다른 이유는 이 CPU 제작 과정에서 해커와 과학자 사이에 격렬한 싸움이 있었고 해커가 이겼기 때문임
• 앞으로 AVX512에 대해 더 나은 타협점을 마련하기를 바라지만, 이전 모델에 비해 상당한 진전을 나타낸다고 믿기에 이 칩에 대해 전반적으로 매우 만족함

애플 하드웨어에서의 성능 향상

• 가장 수준 높은 개인용 컴퓨터라면 단연 Mac Studio일 것임
• 여기서 성능 우위를 차지하는 것은 llama.cpp 개발자들이 가장 신경 쓰는 하드웨어 플랫폼이기 때문에 나에게 더 어려웠고, Stallman의 컴파일러를 사용하기로 한 선택 때문에 애플의 독점 도구 대신 핸디캡을 안고 작업하고 있음
• M2 마이크로프로세서가 llamafile을 합성 콘텐츠의 급수관으로 만드는 것에 놀라지 않을 것임
• 애플이 이를 위해 사용한 트릭은 수직 통합을 활용하는 것임
• Mac Studio를 구입하고 내부를 들여다보면 RAM DIMM을 CPU 안에 넣었다는 것을 발견하게 될 것임
• CPU가 더 이상 이러한 장거리 전화를 걸 필요가 없기 때문에 토큰 생성과 같은 대기 시간에 따른 작업 속도가 훨씬 빨라짐
• 그러나 순수한 flop 측면에서 (프롬프트 tok/sec로 측정) M2 Ultra ARM ISA는 내 훨씬 저렴한 Intel 컴퓨터에 비해 30% 더 많은 계산만 노출함을 알 수 있음
• Metal이나 Accelerate와 같은 독점 프레임워크를 통해야만 더 많은 것에 액세스할 수 있음
• xcode가 설치되어 있다면 llamafile은 기본적으로 당신과 실리콘 사이에 있는 모든 폐쇄 소스 라이브러리 앞에 서도록 도와주는 작은 스텁 모듈을 컴파일할 것임
• Mac Studio 구매를 고려하고 있다면 중요한 한 가지는 Windows Executive와 마찬가지로 XNU가 데스크톱을 안정적으로 유지하는 데 정말 좋은 일을 한다는 것이고, 그것은 시스템을 당신으로부터 보호한다는 의미임
• 이러한 모든 안전 기능 때문에 Mac Studio에서 Cosmo monorepo를 컴파일하는 데 45초가 걸리지만 포크 폭탄을 터뜨려도 Netflix가 단 한 프레임도 건너뛰지 않을 것 같음
• spam.sh 스크립트도 430ms로 실행되어 Intel보다 느림
• 그러나 Asahi Linux가 M2의 잠재력을 최대한 발휘할 수 있는 방법을 보았기 때문에 이 중 어느 것도 나를 걱정시키지 않음

전문가용 하드웨어에서의 성능 향상

• llamafile은 GPU가 부족한 사람들을 돕는 데 큰 관심을 기울이지만 상위 1%에게도 최고 수준의 경험을 제공함
• AMD Ryzen Threadripper PRO 7995WX는 몇 달 전에 출시되었으며 현재 돈으로 살 수 있는 가장 비싼 CPU임
• 1만 달러의 비용이 들지만 Zen4 아키텍처를 기반으로 96코어의 AVX512를 얻을 수 있음
• 두 배의 가격임에도 불구하고 7995WX x86 ISA는 M2 Ultra ARM ISA보다 7배 더 많은 원시 컴퓨팅 성능을 제공하며 거의 동일한 토큰 생성 속도를 보임
• 이는 384MB L3 캐시 덕분일 가능성이 큼
• AVX512의 한 가지 장점은 Google의 Gemma 모델이 AVX512에서는 수학 수수께끼를 풀 수 있지만 AVX2에서는 그렇지 않다는 것인데, 더 큰 벡터가 일반적으로 반올림 오차를 줄이기 쉽기 때문임
• VDPBF16PS 명령은 VNNI 및 ARM dotprod와 유사하게 bf16을 updot하는 데 도움이 됨
• Mistral 및 TinyLLaMA와 같은 모델은 정식 형식으로 bfloat16을 사용하여 가중치를 배포하므로 bf16에 대한 기본 지원이 좋음
• bf16을 fp16으로 변환하면 가능한 숫자의 13%만 정확하게 표현될 수 있음
• 실제로 Mistral 7b가 사용하는 숫자의 99.71%가 해당 13% 중에 있기 때문에 거의 중요하지 않음
• 그러나 llamafile은 주장되는 비트 수를 최선을 다해 전달

[savvykang]

인텔 14600이나 라이젠 5600 같은 중급기에 대한 데이터가 없네요. 라즈베리 파이에서 돌아는 간다는 걸 의도한거 같긴 한데 실사용에는 무리가 있을거 같아 보입니다. 그럼에도 불구하고 로컬 LLM 구동에 필요한 하드웨어 스펙이 점점 내려가고 있다는 것을 위안으로 삼고 싶습니다

[neo]

Hacker News 의견

• Fortran SGEMM 구현에 대한 의견:

  • 현대의 Fortran 컴파일러는 추가적인 변경 없이도 AVX와 FMA 최적화를 적용할 수 있음.
  • 루프 언롤링(loop unrolling) 최적화는 컴파일러 플래그(-funroll-all-loops)를 통해 가능.
  • Intel 컴파일러는 사용자의 명시적 요청 없이도 루프 언롤링을 수행.
  • Fortran 77 소스에 병렬화를 추가하는 것은 어려울 수 있지만, OpenMP 구문을 추가하거나 현대 Fortran의 병렬화 구조를 사용할 수 있음.
  • Fortran 77 함수를 과소평가하지 말 것. 플랫폼 특정 세부 사항으로부터 개발자를 해방시키고 컴파일러에게 작업을 맡기는 것이 Fortran의 목적임.

• cuBLAS 대체에 대한 의견:

  • cuBLAS를 CUDA 내에서 다시 작성하려는 시도로 보임.
  • 다음 단계는 CUDA 의존성을 제거하고 Vulkan이나 Metal 컴퓨트 셰이더를 직접 사용하는 것일 수 있음.

• LLM(Local Language Model) 실행에 대한 의견:

  • 모든 사람이 최소한의 요구 사항으로도 로컬에서 LLM을 다운로드하고 실행할 수 있어야 함.
  • 이는 인간 지식의 큰 부분을 백업하는 역할을 할 수 있음.

• 성능 측정에 대한 의견:

  • C++를 사용하여 서브루틴을 정의하는 것을 선호함. C++는 Python보다 세 오더 이상 빠름.
  • 성능 차이를 "무어의 법칙의 연도"로 측정하는 아이디어를 좋아함.

• 관련 링크 제공:

  • 성능 개선과 관련된 자료로 UTexas LAFF와 Nadav Rotem의 Gist를 참조할 것.

• 제목에 대한 의견:

  • 제목이 혼란스러움. 처음에는 모델이 CPU에서 GPU보다 빠르다고 주장하는 것으로 오해할 수 있음.
  • "LLaMa on CPU의 성능 개선"과 같이 더 명확한 제목이 좋을 것.

• MKL-DNN 대비 성능 개선에 대한 의견:

  • 제한된 행렬 크기에 대해 MKL-DNN을 능가하려 했지만 실패한 경험이 있음.
  • CPU에서 이러한 에너지 효율성은 물리적으로 불가능함.

• LLM 실행에 대한 의견:

  • 큰 컴퓨터 없이도 큰 언어 모델을 실행할 수 있음.
  • 작은 파라미터 모델을 실행하는 것도 기술적으로 언어 모델 실행에 해당하지만, 대부분의 사람들이 유용하다고 생각하는 기준을 충족하지 못할 수 있음.

• Pixar의 CPU 사용에 대한 의견:

  • Pixar와 같은 대형 스튜디오가 비용/성능 및 더 큰 RAM 접근성 때문에 영화 렌더링에 CPU를 사용함.
  • 관련 뉴스 링크 제공.

• AMD Zen4와 AVX512에 대한 의견:

  • 7995WX x86 ISA는 M2 Ultra ARM ISA보다 가격은 두 배지만, 7배 더 많은 원시 컴퓨팅 파워를 제공하며, 토큰 생성 속도도 거의 동일함.
  • 이는 384MB L3 캐시 덕분일 가능성이 있음.
  • Zen4에서 LLaMA를 이전보다 2.8배 빠르게 실행할 수 있게 하는 작업을 수행함.