LLM : On-Device LLM

오늘은 On-Device LLM에 대해서 이야기해보려고 합니다. 최근 On-Device AI라는 키워드와 함께 On-Device LLM이라는 표현도 많이 회자되고 있습니다.

삼성전자는 Galaxy S24부터 Galaxy AI에 On-Device LLM을 탑재하고 있고, 다른 제조사들도 이를 뒤따르고 있습니다. 최근 애플로 곧 출시할 Apple Intelligence에 3B 급 On-Device LLM을 탑재한다고 밝혔죠.

On-Device LLM이 도대체 무엇이고, On-Device LLM을 만들기 위해서는 어떤 것들이 필요한지 알아보겠습니다.

On-Device LLM이 뭐야?

On-Device LLM이 무엇인지부터 이야기 해보겠습니다.

너무나 당연하지만 On-Device LLM은 On-Device에서 돌아가는 LLM을 이야기합니다.

먼저 On-Device는 무엇을 의미할까요? 여기에서 On-Device는 Cloud와 반대되는 개념입니다. Cloud가 아니라 내가 가진 기기를 의미합니다. 일반적으로 LLM은 매우 크기 때문에 강력한 하드웨어를 사용할 수 있는 Cloud 환경을 사용합니다. 하지만 On-Device LLM은 Cloud 대신에 내가 가진 기기로 직접 LLM을 돌립니다.

이론적으로 On-Device는 Cloud가 아니면 어떤 기기든 될 수 있습니다. 스마트폰, 노트북, PC, 심지어는 냉장고, TV, 자동차도 될 수 있습니다. 아무튼 Cloud만 쓰지 않으면 됩니다.

이 글에서는 On-Device LLM을 이야기할 때 가장 많이 언급되는 스마트폰을 가정하고 이야기해 보겠습니다.

다음으로 On-Device에서 "돌린"다는 의미는 무엇일까요? 여기에서 돌린다는 것은 Inference를 의미합니다. On-Device에서 LLM을 훈련시키려는 시도가 없는 것은 아니지만 아무래도 아직은 Inference 정도만 가능한 수준입니다.

On-Device LLM이라고 할 때는 보통 두 가지 의미가 있습니다.

1. On-Device에서 Inference를 할 수 있을 정도로 가벼운 LLM을 의미합니다. 요즘 자주 언급되는 sLM(또는 sLLM)이 떠오르실 겁니다.
2. LLM을 On-Device에서 돌리는 행위 자체를 말하기도 합니다. 아무리 가볍다고 해도 명색이 LLM인데 On-Device에서 돌리려면 기술이 좀 들어가야 합니다.

On-Device 환경의 제약 : 메모리

그럼 Cloud와 다른 On-Device의 특정은 무엇이 있길래 Cloud와 구분해서 On-Device LLM이라고 부를까요? 앞에 이야기한 대로 스마트폰을 가정하고 이야기해 보겠습니다. 스마트폰을 예로 들기는 하지만 대부분 On-Device 환경에 적용됩니다.

먼저 메모리 제약이 있습니다. 여기에서 메모리 제약은 메모리 크기와 메모리 속도 두 가지가 모두 해당합니다.

요즘 스마트폰들은 편차가 있지만 8GB에서 많게는 24GB(중국 브랜드 중에 이런 것들이 있습니다)의 램을 가지고 있습니다. Galaxy S24는 8GB 모델과 12GB 모델이 있습니다. 아이폰 15 Pro는 8GB입니다.

7B 짜리 LLM을 메모리에 올리려면 어느 정도 메모리가 필요할까요? 모델 파라미터 저장에 fp32를 사용한다면 28GB, fp16을 사용한다면 14GB가 필요합니다. 램 크기를 넘어서기도 하지만 8GB 혹은 12GB은 이미 운영체제, 다른 앱들이 많은 부분을 쓰고 있다는 것을 생각하면 턱없이 메모리가 부족합니다.

그럼 조금 더 작은 3B LLM은 어떨까요? fp32 기준으로는 12GB, fp16 기준으로는 6GB가 필요합니다. 여전히 현실적인 수준이 아닙니다.

메모리 용량 못지않게 메모리 속도도 문제입니다. AI 기술 중에는 compute bound도 있고 memory bound도 있는데, Transformer 아키텍처를 사용하는 요즘의 LLM은 대표적인 memory bound로 꼽힙니다. compute bound는 처리 속도가 CPU, GPU 같은 연산 장치의 연산 속도에 영향을 많이 받는 경우이고, memory bound는 처리 속도가 memory access 속도에 영향을 많이 받는 경우입니다.

이를 해결하기 위해 A100, H100 같은 Cloud 환경에서 사용하는 고사양 GPU들은 무시무시하게 빠른 메모리를 사용하고 있습니다. 물론 메모리가 크기도 하고요. 하지만 스마트폰은 이렇게 할 수 없습니다.

가장 큰 이유는 이렇게 하면 제품이 너무 비싸지기 때문입니다. On-Device LLM을 구동할 수 있는 스마트폰이라고 2,000만 원에 팔면 얼마나 팔릴지 의구심이 듭니다.

또 다른 이유는 배터리입니다. 저런 고사양의 하드웨어는 전기도 많이 먹습니다. 배터리를 사용하는 스마트폰으로서는 현실적으로 탑재하기가 어렵습니다.

On-Device 환경의 제약 : 저장장치

저장장치도 메모리와 유사한 문제가 있습니다. 아이폰 15 Pro는 128GB부터 1TB까지 저장장치를 지원합니다. 우리가 일상적으로 쓰는 앱들은 크기가 수십MB에서 수백 M B입니다. 게임들은 커서 몇 GB가 되기도 하고요.

LLM은 앞에서 계산한 대로 하면 3B LLM이라고 하더라도 작게는 6GB에서 12GB까지도 필요합니다. 매번 사진 저장할 공간이 없다고 불평을 하는 스마트폰에 12GB 앱이라니. 작은 투자가 아닙니다.

저장장치의 속도도 문제입니다. LLM을 구동하려면 저장장치에 저장돼있는 LLM을 메모리로 읽어 들어야 합니다. 보통 메모리보다 저장장치의 속도가 훨씬 느리기 때문에 모델을 로딩하려면 저장장치의 속도도 문제가 됩니다.

이 문제는 메모리 크기 문제와 결합하면 더 심각해집니다. Cloud 장비들은 처음에 모델 로딩은 시간이 걸리더라도 한번 로딩하면 되기 때문에 서버가 시작될 때 시간이 좀 걸리더라도 괜찮습니다. 하지만 스마트폰은 여러 앱을 구동하기 위해서 운영체제가 불필요한 앱을 주기적으로 죽입니다. 엄청난 메모리를 쓰고 있는 LLM이 그 대상이 되기 쉽겠죠. 이렇게 메모리에서 내려가고 나면 또다시 모델 로딩을 해야 합니다.

대안으로 LLM 앱을 죽이지 않게 할 수도 있습니다. 하지만 그렇게 하면 그렇지 않아도 부족한 메모리를 거대한 LLM이 항상 차지하고 있어서 다른 앱들이 사용할 메모리가 줄어드는 문제가 있습니다.

On-Device 환경의 제약: 연산 속도

연산 속도도 커다란 문제입니다. 아무리 스마트폰용 CPU, GPU가 좋아졌다고 해도 Cloud에서 보통 사용하는 A100, H100 등을 따라가기는 역부족입니다. On-Device ChatGPT가 있다고 치고 겨우겨우 메모리에도 올렸다고 가정해 보겠습니다. 내가 물어본 질문에 답이 나오는데 10분씩 걸린다면 과연 사용자들이 이 기능을 사용할까요?

On-Device 환경의 제약: 배터리, 발열

앞의 여러 제약 외에도 배터리와 발열이라는 문제가 있습니다. 모바일 기기 특성상 배터리 효율이 매우 중요합니다. 강력한 하드웨어를 사용하기 위해서는 전기를 많이 써야 하는데 배터리로는 한계가 있죠.

발열도 관련된 또 다른 문제입니다. 배터리 문제를 해결했다고 하더라도 강력한 하드웨어로 LLM을 구동하다 보면 엄청난 발열이 생깁니다. 스마트폰 구조 특성상 열을 식히는데 취약합니다. 발열은 결국 하드웨어의 성능을 떨어트리기도 하지만 사용자에게 저온화상을 입힐 수도 있습니다.

한계를 극복하기 위한 방법들

여기까지 보면 On-Device LLM이 말이 되는 거야?라는 생각이 들 수 있습니다. 결론은 말이 됩니다. 그래서 삼성도 애플도 진지하게 각자 플래그십 제품에 On-Device LLM을 탑재하고 있는 것이고요.

지금부터는 어떻게 앞의 난제들을 극복하고 On-Device LLM을 상품화 수준까지 끌어올리고 있는지 이야기해보려고 합니다.

경량화

On-Device LLM을 이루기 위해 가장 먼저 해야 할 것은 모델의 크기를 줄이는 것입니다. 다른 것들을 따지기 전에 LLM은 스마트폰에서 돌리기에는 너무 큽니다. 모델 크기를 줄이기 위한 방법은 무엇이 있을까요?

가장 직관적인 방법은 작은 모델은 사용하는 겁니다. 100B보다는 70B가 좋고, 70B보다는 7B가 좋습니다. 작을수록 좋습니다. 애플은 Apple Intelligence에 3B LLM을 쓴다고 합니다. Cloud 기준으로는 귀여운 크기이지만 On-Device 크기로는 여전히 무시하기 힘든 크기입니다.

적절한 모델 크기를 골랐으면 이미 검증된 여러 가지 모델 경량화 기법을 사용할 수 있습니다. 불필요한 Weight를 제거하는 Pruning도 쓰고, 큰 모델로 작은 모델을 학습시키는 Distillation도 씁니다. 이 두 가지 기법도 중요하지만 On-Device 환경에서 가장 관심을 많이 받는 기술은 Quantization(양자화)입니다.

Pruning이나 Distillation과 마찬가지로 Quantization이 On-Device만을 위한 기술은 아닙니다. 모델 경량화를 위해서 Cloud에서도 널리 사용하는 기법입니다. 다만 On-Device라는 특성상 Cloud보다 더 공격적으로 Quantization을 합니다.

(Quantization 자체만으로도 매우 복잡한 주제라서 이번 글에서는 자세히 다루지 않고 다음에 기회가 되면 따로 글을 적어보겠습니다.)

Quantization은 간단히 이야기하면 모델의 파라미터를 저장하는 데이터의 크기를 줄이는 작업입니다. Cloud 환경에서 많이 사용하는 fp32는 숫자(실수) 하나를 저장하는데 4바이트가 필요합니다. 3B LLM이라면 30억 개의 파리미터를 각각 4바이트에 저장하기 때문에 30억 X 4 = 12GB의 메모리가 필요합니다. fp32 대신에 2바이트인 fp16을 사용하면 30억 X 2 = 6GB의 메모리가 필요하고요.

만약 fp32나 fp16보다 더 작은 데이터 타입을 사용한다면 어떻게 될까요? 당연히 더 줄어들겠죠. 더 작은 데이터 후보로는 int8과 int4이 있습니다. int8은 8비트(1바이트) 정수 타입이고, int4는 4비트(0.5바이트) 정수 타입입니다. 이렇게 하면 물론 정확도는 떨어지겠지만, 모델 크기는 작아집니다.

3B LLM을 int8으로 Quantization 하면 3GB, int4로 Quantization하면 1.5GB의 공간을 차지합니다. fp32를 사용할 때 12GB였는데, int4를 사용하면 1.5GB만 필요하니 획기적인 공간 절약입니다.

단, 모델의 품질을 최대한 유지할 수 있다는 전제 조건이지만요. 그리고 다행히 기술의 발전으로 int4를 사용하더라도 fp32 대비 많은 성능 저하 없이 Quantization을 할 수 있는 기술들이 나왔고 실제로 쓰이고 있습니다. 퀄컴은 NPU에서 INT4 타입을 지원한다고 자신있게 광고하고 있기도 합니다.

Pruning이나 Distillation과 다르게 Quantization을 제대로 사용하기 위해서는 하드웨어 지원이 필요합니다. 아무리 int4로 Quantization을 한 모델이라고 하더라도 하드웨어가 int4 타입을 지원하지 않고 fp16만 지원한다면 메모리를 로딩할 때 어차피 각 값을 fp16으로 변환해야 합니다. 저장장치에 있을 때는 경량화 효과를 볼 수 있어도 메모리에 올리면서 이런 효과가 사라지게 되는 셈이죠. 뒤에서 또 이야기하겠지만 On-Device에서 주로 사용하는 NPU는 GPU와 달리 지원하는 데이터 타입이나 연산이 상대적으로 적기 때문에 Quantization 시에도 이를 고려해야 합니다.

가속화

12GB짜리 3B 모델을 int4로 Quantization 해서 1.5GB까지 줄였다고 해보겠습니다. 어마어마한 압축이죠. 하지만 안타깝게도 이 크기도 여전히 스마트폰 CPU에서 돌리기는 너무 큽니다.

Inference 가속화가 필요합니다.

첫 번째로 떠오르는 후보는 친숙한 GPU입니다. 요즘 스마트폰 게임의 그래픽을 보면 스마트폰의 GPU도 꽤나 강력할 것이라는 생각이 듭니다. 실제로 GPU를 사용하면 CPU보다 속도가 월등히 빨라집니다. 하지만 여기에는 크게 두 가지 문제가 있습니다.

첫 번째는 GPU가 독점 자원이 아니라는 점입니다. 스마트폰을 사용할 때 GPU는 여러 곳에서 사용됩니다. 게임, 그래픽 앱 등 여러 앱이 그래픽 가속을 위해 GPU를 사용하려고 합니다. 때문에 LLM이 GPU를 잡고 있으면 다른 앱들이 정상 구동되지 않습니다.

다른 문제는 배터리입니다. GPU는 스마트폰 하드웨어 중에서 배터리를 많이 먹는 하드웨어 중 하나입니다. GPU를 써서 LLM을 구동하면 배터리가 빠르게 줄어드는 것을 볼 수 있습니다. GPU 100% 사용하는 게임을 쉬지 않고 계속 돌리는 셈이니까요.

그래서 등장은 하드웨어가 NPU입니다.

(Quantization처럼 NPU도 그 하나만으로 큰 주제라 자세한 이야기는 다음에 기회가 되면 다루어보겠습니다.)

GPU가 그래픽 가속을 위한 전용 하드웨어인 것처럼 NPU는 딥러닝 구동을 위한 전용 하드웨어입니다. 딥러닝에 자주 쓰이는 연산을 칩으로 만들어서 가속화시키는 방식입니다. NPU는 처음에 CNN 같은 Image Processing을 위한 딥러닝 위주로 발전을 시작했지만, RNN/LSTM과 같은 NLP 관련 기능 추가를 거쳐 최근에는 대세인 Transformer를 효과적으로 구동하기 위한 기능들을 추가하고 있습니다.

LLM 구동에 NPU를 사용하면 몇 가지 장점이 있습니다.

첫 번째로 NPU는 딥러닝 전용 자원이기 때문에 다른 앱들과 경쟁할 가능성이 적습니다.

두 번째는 딥러닝에 필요한 연산을 저전력으로 지원하기 위해 만들었기 때문에 CPU나 GPU를 썼을 때보다 배터리 소모량이 적습니다.

세 번째는 하드웨어 가속을 통해 Inference가 빠르다는 점입니다.

하지만 NPU를 사용할 때 단점도 있습니다.

NPU는 GPU에 비해 범용성이 떨어집니다. 칩셋 제조사(퀄컴, 애플, 삼성 등)마다 지원하는 연선과 기능이 다르기 때문에 모델이 사용하는 특정 연산이나 기능이 특정 NPU에서 제공되지 않을 수도 있습니다. 이런 문제 때문에 pytorch나 tensorflow로 만든 범용 모델을 각 NPU 칩셋 별로 변환해 주는 과정이 필요합니다. 이 과정에서 각 NPU가 지원하지 않는 기능이 있다면 원래 모델을 바꾸거나 NPU 소프트웨어 부분에서 우회적으로 기능을 구현해주어야 합니다.

이런 변환 과정의 불편함이 그냥 불편함으로만 끝나지 않기도 합니다. 모델 구조를 바꾸거나 NPU가 지원하는 연산이 완전히 같지 않기 때문에 성능 저하가 생기는 경우도 있습니다. 최악의 경우는 내가 만든 모델을 NPU에서 구동할 수 없게 되기도 하고요.

이런 제약 때문에 칩셋 제조사들도 무작정 NPU를 홍보하고 권장하지는 않습니다. 예를 들어 퀄컴은 아래와 같은 가이드라인을 제시하고 있습니다.

• 실시간성이 중요한 태스크: 모델을 작게 만들어서 CPU로 구동
• 상대적으로 긴 시간 동안 입력을 처리해야 하거나 모델인 큰 경우: NPU로 구동

가속화는 하드웨어만의 전유물은 아닙니다. Cloud LLM에서 도입되었던 가속화 기법들이 On-Device LLM에도 도입되고 있습니다. KV Cache, GQA, (Self) Speculative Decoding 등이 대표적입니다.

품질 확보

이제 모델도 작아졌고 하드웨어를 잘 써서 Inference도 빨라졌다고 해보겠습니다. 하지만 모델의 생성 품질이 나쁘면 꽝입니다. On-Device라는 제약상 작은 모델을 쓸 수밖에 없으니 이 문제는 더욱 심각합니다. 모델이 작으니 Prompt(Instruction)도 잘 안 먹힙니다. 자연스럽게 Fine Tuning의 중요성이 더 커질 수 밖에 없습니다.

On-Device LLM 수준에서 성능확보를 위해서는 아직까지 Fine Tuning은 선택이 아닌 필수입니다. 그런데 여기에서 또 다른 문제에 봉착합니다.

3B 짜리 모델을 Fine Tuning 해서 요약 기능을 만들었다고 해보겠습니다. 추가로 이력서를 작성해 주는 기능도 만들고 싶습니다. 앞에서 Fine Tuning 한 모델은 이미 요약 기능으로 특화됐기 때문에 새로 이력서 작성용으로 Fine Tuning을 합니다. 그런데 이번에는 이메일 초안을 만들어 주는 기능을 만들고 싶습니다. 이렇게 하다 보면 3B 짜리 Fine Tuning 된 LLM을 여러 개 탑재해야 합니다. 저장공간을 지원하는 Task 수만큼 차지하게 됩니다.

이럴 때 딱 맞는 기능이 LoRA입니다. LoRA를 사용하면 Task별로 작은 크기의 LoRA Weight만 유지하면서 필요에 따라 LoRA Weight만 갈아 끼우면 됩니다. 물론 이 기능을 On-Device에서 구현하는 것은 쉽지 않습니다. 하지만 이미 구현해서 상품화한 곳들이 있기 때문에 불가능한 것만도 아닙니다.

단계별 성능 저하

지금까지 이야기한 부분을 정리해 보면 이렇게 됩니다.

1. 시작 지점으로 삼을 적당한 크기의 LLM을 하나 고릅니다.
2. 원하는 Task에 맞춰 Fine Tuning을 합니다.
3. Pruning, Distillation, Quantization 등을 써서 모델 크기를 줄입니다.
4. 모델을 구동하려는 NPU에 맞춰 변환&최적화 작업을 합니다.

문제는 각 단계에서 성능 저하가 생긴다는 점입니다.

Fine Tuning을 할 때 LoRA를 사용한다면 Full Fine Tuning 보다는 성능이 낮을 가능성이 있습니다.

Quantization 과정에서 성능 저하가 생깁니다.

NPU에 맞추는 과정에서 성능 저하가 생깁니다.

이 모든 과정을 거치고 나면 처음 생각했던 것보다 성능이 낮은 경우가 많습니다. 더 골치 아픈 것은 어느 단계에서 성능이 떨어졌는지를 분석하면서 고치고 평가하는 지난한 과정을 거쳐야 한다는 점입니다.

그런데도 On-Device LLM?

이런 어려움에도 불구하고 많은 사람과 기업들이 On-Device LLM에 관심을 가지는 이유는 무엇일까요?

사용자 입장에서는 사생활 보호가 가장 큰 이유일 것입니다. 점점 AI가 지원하는 기능이 많아지다 보면 나의 개인정보를 더 많이 AI에 제공해야 합니다. 그런데 On-Device AI를 사용하면 이런 정보가 내 기기를 떠나지 않는다는 것이 보장됩니다.

기업 입장에서도 여러 장점이 있습니다.

먼저 Cloud 인프라 운영 부담을 줄일 수 있습니다. GPU는 매우 비싼 자원이고, 전기세 같은 비용까지 생각하면 Cloud LLM을 운영하는 비용이 만만치 않습니다.

개인정보에 관련된 법적 위험을 피할 수 있습니다. 사용자 데이터를 Cloud에서 처리하고 저장하는 것은 장점도 있지만 최근 GDPR과 같은 법을 고려하면 리스크도 매우 큽니다.

새로운 제품 판매의 동인이 됩니다. 실제로 삼성은 Galaxy AI, 애플은 Apple Intelligence를 새 스마트폰의 강력한 소구 포인트로 앞세우고 있습니다. 스마트폰뿐 아니라 PC에서도 AI PC라는 마케팅이 흥하고 있습니다. On-Device LLM을 구동하기 위해서는 더 많은 메모리, 저장공간이 필요하고 더 강력한 프로세서가 필요하기 때문에 반도체 업체들에게도 좋습니다.

요즘은 LLM을 전문으로 하는 업체들도 두 가지로 나뉘는 느낌입니다. OpenAI나 Anthropic처럼 큰 모델을 중심으로 하는 곳과 처음부터 On-Device를 타깃으로 작업 모델을 중심으로 하는 곳으로 말이죠. 특히 스타트업들은 큰 모델은 하기에는 이제 규모의 경쟁에서 되지 않기 때문에 작은 모델에 집중하는 모습입니다.

마무리

오늘은 On-Device LLM이라는 분야에 대해서 이야기해 보았습니다. On-Device LLM을 가능하게 하는 기술 하나하나가 매우 깊이 있는 주제라 자세히 다루지는 못했지만 On-Device LLM이라는 분야를 이해하는데 조금이나마 도움이 되셨으면 하는 바람입니다.