경량 언어모델의 종류와 장점, 한계

by

최근 생성형 AI가 다양한 업무 영역에 적용되면서 대규모 언어모델(Large Language Model, LLM)의 활용 범위도 빠르게 확대되고 있다. 일반적으로 모델의 규모가 커질수록 복잡한 문맥 이해와 추론 능력이 향상되는 경향이 있지만, 실제 서비스나 업무 환경에서는 성능만으로 모델을 선택하기 어렵다.

화학물질 민원 분석 업무를 진행하면서 이 점을 체감했다. 민원 데이터를 외부 API로 보내기 어려운 환경이었고, 수천 건 이상의 문서를 같은 방식으로 반복 처리해야 했다. 이런 조건에서는 가장 성능이 높은 모델보다 제한된 컴퓨팅 자원에서 실행할 수 있고 로컬 환경에 배포하기 쉬운 경량 언어모델이 더 현실적인 선택지가 되었다.

이 글에서는 경량 언어모델이 무엇인지 살펴보고, 현재 활용되고 있는 대표적인 모델과 장점 및 한계, 그리고 어떤 상황에서 선택할 만한지를 정리한다.

1. 경량 언어모델이란?

경량 언어모델은 대규모 언어모델보다 파라미터 수와 연산량을 줄여, 상대적으로 적은 컴퓨팅 자원에서도 실행할 수 있도록 설계된 언어모델을 말한다. Small Language Model(SLM)이라고도 부르며, 이 글에서는 “경량 모델”로 줄여 쓴다.

어느 규모까지를 경량 모델로 볼 것인지에 대한 절대적인 기준은 없다. 수십억 개 수준의 파라미터를 가진 모델도 수백억~수천억 개 이상의 대형 모델과 비교하면 경량 모델로 분류되곤 한다. 이 글에서는 대략 0.3B~14B 범위의 모델을 다룬다.

왜 경량화가 필요한가: 메모리 관점

모델 가중치를 올리는 데 필요한 메모리는 “파라미터 수 × 파라미터당 바이트 수”로 대략 가늠할 수 있다. 16비트(FP16/BF16)는 파라미터당 2바이트, 8비트는 1바이트, 4비트 양자화는 0.5바이트 수준이다.

모델 규모16비트8비트4비트 양자화
3B약 6GB약 3GB약 1.5~2GB
7B약 14GB약 7GB약 3.5~4GB
70B약 140GB약 70GB약 35~40GB

[표1] 모델 규모와 양자화 수준별 가중치 메모리 추정치

파라미터 수에 파라미터당 바이트 수를 곱해 계산한 대략값이다. 같은 7B 모델도 16비트에서는 약 14GB지만, 4비트 양자화를 적용하면 약 3.5~4GB로 줄어 약 1/4 수준이 된다.

위 수치는 가중치만 기준으로 한 대략적인 값이며, 실제 실행 시에는 KV 캐시와 런타임 오버헤드가 더해져 여유 메모리가 더 필요하다. 그래도 7B급 모델은 4비트 양자화 시 일반 노트북이나 소비자용 GPU에서도 실행을 시도해볼 수 있는 반면, 70B급 모델은 4비트 양자화를 적용하더라도 가중치만 약 35GB 이상이므로, 실용적인 추론 속도를 확보하려면 일반적으로 대용량 메모리나 다중 GPU 등 고사양 환경이 필요하다.  메모리뿐 아니라 요청당 연산량도 함께 줄어들기 때문에 추론 속도와 운영 비용 측면의 이점도 따라온다.

[그림1] 모델 규모와 양자화 수준별 가중치 메모리 (세로축: 로그 스케일)

[표1]의 수치를 막대그래프로 나타냈다. 세로축이 로그 스케일이라 막대 높이 차이가 실제보다 작게 보인다는 점에 유의해야 한다. 점선은 16GB급 소비자용 GPU를 예시로 한 기준선으로, 7B는 4비트 양자화 시 여유가 있지만 16비트에서는 가중치만으로 14GB라 KV 캐시를 고려하면 여유가 거의 없다. 70B는 4비트에서도 이 선을 크게 넘는다.

Google의 Gemma, Alibaba의 Qwen3.5, Meta의 Llama 3.2, Mistral의 Ministral 3처럼 여러 기업이 경량화를 전제로 한 모델을 꾸준히 공개하고 있다[1][2][3][4][5]. 대표 모델은 다음 장에서 정리한다.

2. 대표적인 경량 언어모델

2.1 모델 계열별 정리

모델 계열개발사주요 특징
PhiMicrosoft작은 규모에서 추론 및 일반 작업 수행을 목표로 설계. Phi-4-mini(약 3.8B)가 소형 라인업의 대표 모델 [6]
GemmaGoogle로컬·온디바이스 활용을 고려한 오픈 모델. Gemma 4는 2B·4B급 E 모델, 26B(MoE)·31B 모델, 12B Unified로 구성 [2]
QwenAlibaba CloudQwen3.5 소형 시리즈는 0.8B·2B·4B·9B 제공. 다국어 및 멀티모달 지원 [4]
LlamaMetaLlama 3.2의 1B·3B가 대표적인 경량 모델 [3]
MinistralMistral AI3B·8B·14B 규모의 Ministral 3. 엣지 및 로컬 환경 효율을 목표로 설계 [5]

[표2] 주요 경량 모델 계열 요약 (2026년 10월 기준)

개발사별 대표 소형 모델의 크기 구성과 특징을 정리했다. 모델 버전과 크기 구성은 빠르게 바뀌므로 도입 전에 각 공식 문서에서 최신 정보를 확인해야 한다.

이들 모델은 단순히 대형 모델의 축소판이라기보다, 제한된 자원에서 일정 수준 이상의 언어 처리 성능을 확보하는 것을 목표로 개발되고 있다.

  • Phi 계열. Microsoft의 Phi는 “작은 모델도 데이터 품질에 따라 충분한 추론 성능을 낼 수 있다”는 방향을 대표하는 계열이다. Phi-4-mini는 추론과 코딩, 지시 수행에 강점을 두고 설계되었다[6].
  • Gemma 계열. Gemma 3n은 모바일·온디바이스를 겨냥해 설계되었고, 텍스트뿐 아니라 이미지·오디오 입력까지 처리하는 멀티모달 모델이다[1]. 3n이 도입한 “Effective” 파라미터 방식(E2B·E4B)은 Gemma 4에서도 온디바이스용 모델로 이어지고 있다[1][2].
  • Qwen 소형 모델. 0.8B부터 9B까지 크기가 촘촘하게 나뉘어 있어 환경과 요구 성능에 맞춰 규모를 고르기 쉽다[4].
  • Llama 소형 계열. Llama 3.2 1B·3B는 128K 토큰 문맥을 지원하며 요약, 지시 수행, 문장 재작성 같은 온디바이스 작업을 겨냥했다[3]. 2024년 9월 공개 이후 시간이 지났으므로 실제 도입 전에는 더 최신 대안과 함께 비교해보는 편이 좋다.
  • Mistral 계열. Ministral 3는 3B·8B·14B 모두 Apache 2.0 라이선스로 공개되어 상업적 활용에 제약이 적다[5].

2.2 크기 구간별로 보면

계열별 나열만으로는 선택 기준을 잡기 어려우므로, 크기와 활용 환경 기준으로도 정리해보면 다음과 같다.

크기 구간예시 모델주로 고려하는 환경
약 2B 이하Gemma 3 270M, Qwen3.5 0.8B·2B, Llama 3.2 1B, EXAONE 4.0 1.2B
(2.3절 참고)		모바일, IoT, 엣지. 특정 작업에 맞춘 파인튜닝을 전제로 활용하는 경우가 많음
약 3~4BLlama 3.2 3B, Phi-4-mini, Ministral 3 3B, Qwen3.5 4B, Gemma 4 E4B노트북, 온디바이스. 가벼운 에이전트·분류·추출
약 8~14BQwen3.5 9B, Ministral 3 8B·14B단일 GPU 로컬 서버, 사내 서버. 요약·RAG 생성 모델

[표3] 크기 구간별 예시 모델과 주요 활용 환경

모델 크기에 따라 실행할 수 있는 환경이 달라진다. 같은 계열도 여러 구간에 걸쳐 있고 구간 경계는 편의상 나눈 대략적인 기준이므로, 후보를 좁히는 용도로 참고하면 된다.

다만 모델의 파라미터 수만으로 실제 메모리 사용량이나 추론 속도를 정확히 비교하기는 어렵다. 최근에는 MoE나 활성 파라미터와 같은 구조가 적용되므로, 같은 규모로 표시된 모델이라도 실제 연산량과 실행 환경은 달라질 수 있다. 따라서 모델 크기는 참고 기준으로 활용하고, 실제 도입 시에는 메모리 사용량과 처리 속도를 직접 측정하는 것이 좋다. 

2.3 한국어 특화 모델

한국어 업무가 중심이라면 한국어 특화 모델도 후보에 넣을 만하다. LG AI Research의 EXAONE 4.0은 32B 모델과 온디바이스용 1.2B 모델로 구성되며, 영어·한국어에 더해 스페인어까지 지원한다[7]. 다만 공개 모델의 라이선스가 연구·교육 목적 중심으로 안내되어 있으므로 상업적·업무적 활용을 계획한다면 라이선스 조건을 반드시 확인해야 한다.

3. 경량 언어모델의 장점

3.1 적은 컴퓨팅 자원

언어모델을 실행하려면 파라미터를 메모리에 올리고 추론 연산을 수행해야 하므로, 모델이 클수록 더 많은 GPU 메모리와 연산 자원이 필요하다. 경량 모델은 상대적으로 적은 메모리에서도 실행할 수 있어 고성능 GPU 서버가 없는 환경에서도 활용 가능성이 높다. 여기에 양자화(Quantization)를 적용해 가중치 표현 크기를 줄이면 앞서 본 표처럼 필요한 메모리를 추가로 절감할 수 있다.

3.2 빠른 응답 속도

연산량이 적으므로 같은 환경에서는 대형 모델보다 빠른 추론을 기대할 수 있다. 하나의 요청에서 최고 수준의 추론 성능을 내는 것보다 많은 데이터를 반복 처리하는 것이 중요한 업무라면 처리 속도가 핵심 선택 기준이 된다. 문서 분류, 정보 추출, 태깅처럼 같은 작업을 수천 건 이상 반복하는 경우 요청당 처리 시간이 누적되므로 모델 크기 차이가 전체 처리 시간에 큰 영향을 준다.

3.3 낮은 운영 비용

상용 LLM API는 입력·출력 토큰 사용량에 따라 비용이 발생한다. 경량 모델을 자체 환경에서 실행하면 초기 인프라 구축 비용은 필요하지만 반복적인 API 호출 비용을 줄일 수 있다. 정해진 업무를 장기간 반복 처리하는 환경이라면 성능뿐 아니라 전체 운영 비용까지 함께 비교해야 한다.

3.4 로컬 환경에서의 활용

경량 모델은 개인 PC, 내부 서버, 엣지 디바이스에서 직접 실행하기가 비교적 쉽다. Google은 Gemma 3n을 통해 텍스트뿐 아니라 멀티모달 처리까지 기기 안에서 수행하는 방향을 제시했다[1]. 외부 네트워크 연결이 어렵거나 내부 데이터의 외부 전송을 최소화해야 하는 환경에서 특히 유용한 특징이다.

3.5 목적에 맞는 모델 선택

모든 업무에 최고 수준의 범용 추론 성능이 필요한 것은 아니다. 업무 범위와 출력 형식이 비교적 명확하다면 다음과 같은 작업에서 경량 모델을 검토해볼 수 있다.

  • 문서 및 문의 유형 분류
  • 문서 요약
  • 키워드 및 개체 추출
  • 정해진 형식의 정보 추출
  • 제한된 도메인의 질의응답
  • RAG 시스템의 생성 모델
  • 텍스트 정규화 및 전처리

필요한 성능을 충족한다면 더 큰 모델보다 경량 모델이 시스템 전체 관점에서 더 효율적이다.

4. 경량 언어모델의 한계

경량 모델에는 분명한 장점이 있지만, 규모를 줄인 만큼 고려해야 할 한계도 있다.

4.1 복잡한 추론 능력

단순한 분류나 정보 추출에는 충분한 성능을 보이더라도, 여러 조건을 동시에 고려하거나 여러 단계의 추론이 필요한 문제에서는 대형 모델보다 성능이 떨어질 수 있다. 질문에 명시되지 않은 정보를 종합하거나 긴 논리 전개가 필요한 작업에서 특히 차이가 드러난다. 따라서 모델을 고를 때는 벤치마크 점수만 볼 것이 아니라 실제로 수행할 업무의 난이도를 기준으로 평가해야 한다.

4.2 긴 문맥 처리

최근 경량 모델도 수십만 토큰 수준의 문맥 길이를 지원하는 경우가 늘었지만, 지원하는 길이와 그 길이에서 실제로 안정적인 품질을 내는 것은 별개의 문제다. 입력이 길어질수록 KV 캐시가 커져 메모리 사용량과 처리 시간이 함께 늘고, 긴 문서 중간에 있는 정보를 놓치거나 지시를 잊는 현상도 대형 모델보다 두드러질 수 있다. 긴 문서를 다룬다면 문서를 나누어 처리하거나 RAG로 필요한 부분만 전달하는 설계를 함께 고려하는 편이 안전하다.

4.3 지식의 범위와 환각(Hallucination)

경량 모델은 표현 용량이 제한되어 있어 범용 지식과 전문 지식에서 대형 모델보다 불리할 수 있다. 특히 법률, 의료, 화학 같은 전문 도메인에서는 모델이 가진 지식만으로 정확한 결과를 내기 어렵다. 문제는 지식이 부족할 때 모델이 “모른다”고 답하기보다 그럴듯한 문장으로 사실과 다른 내용을 만들어내는 환각이 발생할 수 있다는 점이다. 이는 경량 모델에만 해당하는 문제는 아니지만, 경량 모델은 표현 용량과 학습된 지식 범위가 제한적일 수 있어 특정 전문 도메인이나 복잡한 질의에서 사실 오류가 증가할 가능성이 있다. 다만 환각은 모델 크기뿐 아니라 학습 방식, 프롬프트, 검색·검증 구조 등에도 영향을 받는다. 

이를 보완하기 위해 실제 서비스에서는 관련 문서를 검색해 모델에 함께 제공하는 RAG(Retrieval-Augmented Generation), 규칙 기반 검증, 출처 확인 절차를 병행한다. 정확성이 중요한 업무일수록 모델이 아는 내용만으로 답하게 하지 말고 이런 보완 장치를 반드시 두어야 한다.

4.4 프롬프트에 따른 성능 차이

경량 모델은 복잡하거나 모호한 지시에 대한 강건성이 상대적으로 낮을 수 있어, 프롬프트 구성에 따른 성능 편차가 크게 나타나는 경우가 있다. 복잡하거나 모호한 지시보다 수행할 작업, 판단 기준, 출력 형식을 명확히 정의했을 때 안정적인 결과를 얻는다. 경량 모델을 업무에 적용할 때는 모델 선정과 함께 프롬프트 설계, 결과 검증 과정까지 고려해야 한다.

4.5 범용성과 효율성 사이의 트레이드오프

작은 모델 크기는 가장 큰 특징이자 동시에 한계다. 파라미터와 연산량을 줄이면 실행 효율은 높아지지만, 다양한 분야의 복잡한 업무를 수행하는 범용 능력은 제한된다. 결국 경량 모델과 대형 모델의 관계는 성능의 우열이 아니라 성능과 효율 사이의 트레이드오프로 이해하는 것이 적절하다.

5. 어떤 상황에서 경량 언어모델을 사용할 수 있을까?

경량 모델이 항상 대형 모델보다 적합한 것은 아니고, 모든 업무에 가장 큰 모델을 쓸 필요도 없다. 모델을 고를 때는 다음 기준을 함께 살펴볼 수 있다.

고려사항경량 모델을 검토하기 좋은 경우
업무 범위수행할 작업이 비교적 명확한 경우
데이터량동일한 작업을 대량으로 반복해야 하는 경우
응답 속도빠른 응답이 중요한 경우
인프라사용할 수 있는 GPU·메모리가 제한적인 경우
운영 비용지속적인 API 비용을 줄여야 하는 경우
보안데이터를 외부 서비스로 전송하기 어려운 경우
배포 환경내부망·PC·모바일·엣지 환경에서 실행해야 하는 경우

[표4] 경량 모델 도입 판단 기준

해당하는 항목이 많을수록 경량 모델을 우선 검토할 만하다. 다만 한두 항목만으로 결정하지 말고, 실제 업무 데이터로 평가한 결과와 함께 종합해 판단해야 한다.

반대로 복잡한 추론, 다양한 도메인 지식의 활용, 높은 수준의 생성 품질이 중요하다면 더 큰 모델이 적합할 수 있다.

[그림2] 경량 모델 선택 흐름

요구사항을 정의하고 작은 모델부터 같은 데이터로 평가한 뒤, 성능이 부족하면 RAG·규칙 검증으로 구조를 보완하거나 더 큰 모델로 올려 다시 평가하는 순서를 나타냈다. 구조 보완으로 해결되는지 먼저 확인한 뒤 모델 크기를 올리면 불필요한 비용을 줄일 수 있으며, 평가 방법은 아래에서 다룬다.

실제 평가는 이렇게

  • 같은 데이터로 비교한다. 후보 모델을 크기별로 2~3개 고르고, 실제 업무 데이터에서 추린 평가 세트(수십~수백 건)에 동일한 프롬프트로 돌려 정확도를 비교한다. 공개 벤치마크 점수보다 내 데이터에서의 결과가 더 믿을 만하다.
  • 양자화 수준별 품질을 확인한다. 4비트와 8비트, 16비트를 비교해 품질 하락이 업무 허용 범위 안인지 확인한다. 메모리 절감폭과 품질 하락폭을 함께 보고 결정한다.
  • 속도와 메모리를 같이 잰다. 건당 처리 시간, 동시 처리량, 최대 메모리 사용량을 실제 환경에서 측정해 전체 처리 시간과 비용을 추정한다.
  • 실패 사례를 분류한다. 틀린 결과가 형식 오류인지, 판단 오류인지, 환각인지 나눠보면 프롬프트 개선으로 해결될지, 더 큰 모델이나 RAG가 필요한지 판단할 수 있다.

마무리

생성형 AI 기술이 발전하며 모델의 규모는 계속 커지고 있지만, 작은 모델을 효율적으로 쓰기 위한 기술도 꾸준히 발전하고 있다. Gemma, Qwen, Llama, Ministral 등에서 보듯 수십억 개 안팎의 모델이 계속 공개되고 있고, 모바일·엣지·로컬 환경을 겨냥한 모델도 늘고 있다.

경량 모델 선택을 정리하면 다음과 같다.

  1. 요구사항부터 정의한다. 작업 유형, 처리량, 허용 가능한 응답 시간, 데이터 반출 가능 여부를 먼저 정리한다.
  2. 작은 모델부터 시험한다. 여러 크기의 모델을 같은 데이터로 평가하고, 필요한 성능을 만족하는 가장 작은 모델을 고른다.
  3. 한계는 구조로 보완한다. 지식 부족과 환각은 RAG와 검증 절차로, 긴 문서는 분할 처리로 대응한다.

경량 모델은 대형 모델을 대체하기 위한 기술이 아니라, 제한된 자원과 명확한 목적 안에서 성능과 효율의 균형을 맞추기 위한 하나의 선택지다.

참고 자료