sLLM와 LLM의 차이점: 제작 방법, 대표 모델, 성능·속도와 현장 활용

sLLM과 LLM의 차이: LLM은 광범위한 지식과 복잡한 추론을 처리하는 범용 대형 언어 모델이고, sLLM은 특정 업무를 제한된 하드웨어에서 빠르고 저렴하게 처리하도록 크기와 구조를 최적화한 소형 언어 모델이다.

생성형 AI를 기업이나 개인 환경에 도입하려고 하면 곧바로 한 가지 질문과 마주친다.

가장 성능이 좋은 대형 LLM을 사용해야 할까, 아니면 내부 서버나 개인용 컴퓨터에서 실행할 수 있는 sLLM으로도 충분할까?

대형 LLM은 광범위한 지식, 복잡한 추론, 고품질 글쓰기와 코딩에서 강하다. 그러나 모든 업무가 이런 범용 능력을 요구하는 것은 아니다.

문서 분류, 정보 추출, 사내 규정 검색, 설비 알람 설명, 정해진 API 호출처럼 범위가 명확한 작업은 작은 모델에 RAG, 구조화 출력, 파인튜닝과 검증기를 결합해 더 빠르고 저렴하게 처리할 수 있다.

최근에는 모델을 평가하는 기준도 달라지고 있다.

• 가장 큰 모델인가?
• 공개 벤치마크 점수가 가장 높은가?

보다 다음 질문이 더 중요해졌다.

• 실제 업무 성공률이 충분한가?
• 데이터를 외부로 보내지 않고 처리할 수 있는가?
• 목표 장치의 메모리와 전력 안에서 실행되는가?
• 응답 속도와 운영비를 예측할 수 있는가?
• 잘못된 응답을 시스템 수준에서 차단할 수 있는가?

이 글에서는 sLLM와 LLM의 개념과 차이, sLLM을 만드는 세 가지 기술 경로, 대표 모델, 성능과 속도, 기업이 온프레미스에서 sLLM을 선택하는 이유, Mac mini 로컬 AI 열풍과 실제 산업 현장 활용까지 정리한다.

1. LLM이란?

LLM(Large Language Model, 대규모 언어 모델)은 대규모 텍스트와 코드, 경우에 따라 이미지·음성·영상 데이터를 학습해 사용자의 입력을 이해하고 다음 토큰을 생성하는 인공지능 모델이다.

대표적인 활용은 다음과 같다.

• 질문 답변
• 문서 요약과 번역
• 보고서·이메일 작성
• 코드 생성과 디버깅
• 수학·과학 추론
• 이미지·음성·영상 이해
• 데이터 분석
• 도구 호출
• 여러 단계를 수행하는 AI 에이전트

LLM의 핵심은 특정 업무 하나만 처리하는 모델이 아니라 여러 분야와 작업에 대응할 수 있는 범용성이다.

1.1 LLM은 파라미터 수만으로 정의되지 않는다

“몇 B 이상이면 LLM인가?”에 대한 절대적인 기준은 없다.

파라미터 수는 모델 규모를 설명하는 중요한 지표지만 다음 요소도 함께 살펴야 한다.

• 학습 데이터의 규모와 품질
• Dense 또는 MoE 아키텍처
• 총 파라미터와 활성 파라미터
• 컨텍스트 길이
• 멀티모달 지원
• 추론 학습 여부
• 도구 호출 능력
• 학습·추론 연산량
• 목표 배포 환경

따라서 LLM은 실무적으로 다음과 같이 정의하는 편이 적절하다.

광범위한 지식과 여러 종류의 언어·추론 작업을 수행하도록 대규모 데이터와 연산량으로 학습한 범용 모델

2. sLLM 또는 SLM이란?

국내에서는 sLLM(small Large Language Model)이라는 용어가 널리 사용된다. 영어권과 공식 기술 문서에서는 주로 SLM(Small Language Model)이라고 부른다.

Microsoft는 SLM을 대형 모델보다 적은 자원으로 특정 작업을 수행하는 언어 모델로 설명한다. Google의 Gemma, Microsoft의 Phi, Meta의 Llama 소형 모델처럼 모바일·PC·엣지 환경을 목표로 만든 모델이 대표적인 예다.

sLLM은 주로 다음 환경을 겨냥한다.

• 기업 내부 서버
• 폐쇄망
• 단일 GPU 워크스테이션
• 일반 PC와 노트북
• 스마트폰과 태블릿
• 자동차
• 로봇과 드론
• 공장 엣지 서버
• 인터넷 연결이 불안정한 현장

실무적으로는 다음처럼 정의할 수 있다.

sLLM은 제한된 자원과 명확한 업무 범위에서 필요한 정확도·속도·비용을 달성하도록 모델 크기, 구조, 정밀도와 학습 범위를 최적화한 언어 모델이다.

2.1 sLLM은 단순히 작은 파일을 의미하지 않는다

다음 모델은 모두 저장 용량이 비슷해질 수 있지만 기술적 의미는 다르다.

1. 처음부터 3B 구조로 설계하고 사전학습한 모델
2. 14B 모델의 레이어와 채널을 줄여 3B로 만든 모델
3. 7B 모델의 구조는 그대로 두고 4비트로 양자화한 모델
4. 70B 모델을 극저비트로 압축해 수십 GB로 만든 모델

특히 70B 모델을 4비트로 양자화했다고 해서 파라미터 수 기준의 sLLM이 되는 것은 아니다.

파일과 메모리는 줄었지만 모델 구조와 파라미터 수는 여전히 70B다. 이런 모델은 “양자화된 대형 LLM” 또는 “경량화된 LLM”이라고 부르는 편이 정확하다.

3. sLLM와 LLM의 공통점

sLLM와 LLM은 서로 전혀 다른 기술이 아니다. 대부분 같은 핵심 원리를 공유한다.

3.1 Transformer 계열 구조

대부분의 현대 언어 모델은 Transformer 또는 그 변형을 사용한다.

기본 과정은 다음과 같다.

1. 입력을 토큰으로 분리한다.
2. 토큰을 벡터로 바꾼다.
3. Attention으로 토큰 사이의 관계를 계산한다.
4. 여러 레이어를 통과한다.
5. 다음 토큰의 확률을 계산한다.
6. 토큰을 반복 생성해 답변을 완성한다.

모델의 크기가 다르더라도 기본적인 생성 원리는 유사하다.

3.2 사전학습과 후속학습

두 모델 모두 일반적으로 다음 단계를 거친다.

• 사전학습
• 지도 미세조정(SFT)
• 선호도 정렬
• 도메인 파인튜닝
• 안전성 평가
• 배포 후 회귀 평가

3.3 같은 한계를 가진다

sLLM와 LLM 모두 다음 문제가 생길 수 있다.

• 사실과 다른 내용을 생성하는 환각
• 최신 정보 부족
• 질문 표현에 따른 답변 변동
• 긴 문맥에서 조건 누락
• 프롬프트 인젝션
• 개인정보와 기밀정보 노출
• 근거 없는 자신감 있는 답변

모델이 크다고 항상 사실에 맞는 것도 아니며, 작다고 자동으로 안전해지는 것도 아니다.

3.4 같은 보조 기술을 활용한다

두 모델 모두 다음 기술과 결합할 수 있다.

• RAG
• 벡터 데이터베이스
• Function Calling
• Tool Calling
• AI 에이전트
• LoRA·QLoRA
• 양자화
• 구조화 출력
• Guardrail
• Speculative Decoding
• KV Cache 최적화
• 프롬프트 캐시

4. sLLM와 LLM의 차이점

4.1 범용성과 전문성의 차이

대형 LLM은 다음과 같은 문제에 유리하다.

• 여러 전문 분야가 섞인 분석
• 처음 접하는 유형의 질문
• 복잡하고 긴 추론
• 대규모 코드베이스 분석
• 전략과 기획
• 장문의 고품질 글쓰기
• 여러 도구를 연속으로 사용하는 에이전트

sLLM은 다음과 같은 작업에 유리하다.

• 민원·문의 분류
• 정해진 필드 추출
• 제품 매뉴얼 기반 질의응답
• 설비 알람 원인 후보 생성
• 보고서 양식 자동 작성
• 승인된 함수 중 하나 선택
• 상담 내용을 JSON으로 변환
• 사내 용어를 사용하는 반복 업무

4.2 비용의 차이

외부 LLM API의 비용 구조는 다음과 같다.

API 총비용
= 입력 토큰 + 출력 토큰 + 검색·저장 + 네트워크 + 부가 서비스

자체 sLLM 운영 비용은 다음과 같다.

자체 운영 총비용
= 서버 감가상각 + 전력 + 냉각 + 운영 인력 + 장애 대응 + 모델 유지보수

사용량이 적고 업무가 자주 변하면 API가 저렴할 수 있다. 반대로 요청량이 많고 업무가 정형화돼 있다면 자체 sLLM의 요청당 비용이 낮아질 수 있다.

4.3 보안의 차이

sLLM의 중요한 장점은 데이터가 외부 클라우드로 나가지 않도록 설계할 수 있다는 점이다.

다음 분야에서는 특히 중요하다.

• 의료 기록
• 금융 거래
• 국방·치안
• 제조 공정 노하우
• 설계 도면
• 고객 개인정보
• 폐쇄망 행정 시스템

다만 온프레미스라고 자동으로 안전한 것은 아니다.

• 모델 API 인증
• 문서별 접근권한
• 로그 마스킹
• 벡터 DB 보안
• 프롬프트 인젝션 방어
• 백업과 관리자 권한
• 모델 파일 공급망

을 별도로 관리해야 한다.

5. sLLM을 만드는 세 가지 기술 경로

sLLM을 만드는 방식은 출발점과 변경 대상을 기준으로 세 가지로 나눌 수 있다.

경로 1: 처음부터 작은 모델을 설계하고 학습
경로 2: 기존 LLM의 구조와 파라미터 수를 축소
경로 3: 기존 LLM의 웨이트 표현을 압축

이 구분은 타당하지만 완전히 배타적이지는 않다. 실제 모델은 여러 기술을 함께 사용한다.

5.1 경로 1: 처음부터 sLLM으로 설계하고 사전학습

첫 번째 방법은 대형 LLM을 만든 뒤 줄이는 것이 아니다.

목표 장치, 메모리, 지연시간과 전력 예산을 먼저 정한 뒤 그 조건에 맞는 작은 아키텍처를 설계하고 처음부터 사전학습한다.

목표 하드웨어와 업무 정의
   ↓
토크나이저 설계
   ↓
레이어·차원·Attention 구조 결정
   ↓
사전학습 데이터 구축
   ↓
사전학습
   ↓
SFT·정렬·증류
   ↓
양자화와 장치 최적화

조정하는 대표 요소는 다음과 같다.

• Transformer 레이어 수
• Hidden Dimension
• FFN 중간 차원
• Attention Head 수
• KV Head 수
• Grouped-Query Attention
• Multi-Query Attention
• 임베딩과 출력 헤드 공유
• 토크나이저 어휘 크기
• 위치 인코딩
• 활성화 함수
• 메모리 대역폭에 맞는 행렬 크기
• 모바일·NPU가 지원하는 연산자

장점

• 목표 장치에 최적화할 수 있다.
• 불필요한 구조를 처음부터 줄일 수 있다.
• 데이터와 라이선스를 직접 통제할 수 있다.
• 한국어 또는 특정 산업 중심으로 설계할 수 있다.
• 압축된 대형 모델보다 하드웨어 효율이 좋을 수 있다.

단점

• 대규모 사전학습 데이터가 필요하다.
• GPU 클러스터와 분산 학습 역량이 필요하다.
• 토크나이저와 데이터 정제부터 직접 설계해야 한다.
• 학습 실패 위험과 비용이 크다.

이 경로는 대형 플랫폼 기업, 모델 개발사, 국가 단위 프로젝트에 적합하다.

5.2 경로 2: 기존 LLM의 구조와 파라미터 수를 경량화

두 번째 방법은 이미 학습된 LLM에서 레이어, Head, FFN 채널과 차원을 줄이는 것이다.

구조적 프루닝

다음 구조를 통째로 제거한다.

• Transformer 레이어
• Attention Head
• KV Head
• FFN 뉴런과 채널
• Hidden Dimension
• 임베딩 차원

구조적 프루닝은 실제 행렬과 레이어가 작아지므로 적절한 커널을 사용하면 메모리와 연산량, 지연시간을 함께 줄일 수 있다.

레이어 드롭

모델의 일부 레이어를 제거해 깊이를 줄인다.

단순히 마지막 레이어부터 잘라내는 것보다 레이어 중요도와 표현 유사도를 분석해 제거해야 성능 손실을 줄일 수 있다.

저랭크 분해

큰 가중치 행렬을 작은 행렬의 곱으로 근사한다.

큰 행렬 W
   ↓
작은 행렬 A × 작은 행렬 B

파라미터 수를 줄일 수 있지만 추론 엔진이 해당 형태를 효율적으로 처리하지 못하면 실제 속도는 기대보다 개선되지 않을 수 있다.

지식 증류

대형 교사 모델의 능력을 작은 학생 모델로 이전한다.

대형 교사 모델
   ↓ 답변·확률 분포·합성 데이터
작은 학생 모델
   ↓ 증류 학습
sLLM

지식 증류는 기존 LLM의 구조를 직접 잘라내는 기술은 아니다. 하지만 작은 구조에 대형 모델의 지식을 이전하는 핵심 방법이므로 구조 경량화와 함께 사용되는 경우가 많다.

장점

• 기존 LLM의 지식을 활용할 수 있다.
• 처음부터 사전학습하는 것보다 비용이 낮을 수 있다.
• 실제 파라미터 수와 연산량을 줄일 수 있다.
• 특정 크기의 학생 모델을 만들 수 있다.

단점

• 제거 대상에 따라 성능이 크게 떨어질 수 있다.
• 보정 학습과 재평가가 필요하다.
• 원본 모델의 파생 모델 라이선스를 확인해야 한다.
• 희귀 지식과 복잡한 추론 능력이 먼저 손실될 수 있다.

5.3 경로 3: LLM의 웨이트를 경량화

세 번째 방법은 모델의 레이어 수와 차원을 거의 유지하면서 가중치의 저장·연산 표현을 줄이는 것이다.

양자화

FP32 또는 FP16 가중치를 더 낮은 정밀도로 표현한다.

• INT8
• INT4
• FP8
• FP4
• GPTQ
• AWQ
• GGUF 양자화 형식

양자화 방식은 다시 나뉜다.

• Weight-only Quantization: 가중치만 저정밀도로 저장
• Weight-Activation Quantization: 가중치와 활성값 모두 양자화
• KV Cache Quantization: KV Cache까지 양자화
• PTQ: 학습 완료 후 양자화
• QAT: 학습 중 양자화 오차를 반영

비정형 프루닝과 희소화

중요도가 낮은 개별 가중치를 0으로 만든다.

이론적으로 저장량과 연산량을 줄일 수 있지만 일반 GPU가 희소 행렬을 효율적으로 처리하지 못하면 실제 속도는 크게 개선되지 않는다.

2:4 구조적 희소성처럼 하드웨어가 지원하는 규칙적인 패턴이 있어야 처리량 향상으로 이어지기 쉽다.

가중치 공유와 코드북 압축

여러 가중치가 같은 대표값을 공유하거나 코드북의 인덱스로 저장되도록 한다.

저장 공간은 줄일 수 있지만 디코딩 오버헤드와 런타임 지원 여부를 확인해야 한다.

장점

• 기존 모델 구조와 API를 유지하기 쉽다.
• 적용이 구조 축소보다 간단하다.
• 메모리 절감 효과가 크다.
• 더 큰 모델을 PC나 단일 GPU에 적재할 수 있다.

단점

• 파라미터 수 자체는 그대로일 수 있다.
• 파일 크기 감소가 속도 향상을 보장하지 않는다.
• 하드웨어가 저정밀 연산을 지원해야 한다.
• 극저비트에서는 숫자 처리와 추론 품질이 떨어질 수 있다.
• 긴 문맥에서는 웨이트보다 KV Cache가 병목이 될 수 있다.

5.4 세 가지 방법 비교

5.5 실제로는 여러 방식을 조합한다

상용 sLLM은 한 가지 기술만 사용하는 경우가 드물다.

소형 아키텍처 설계
 + 고품질 사전학습
 + 대형 교사 모델 증류
 + 도메인 SFT
 + 4비트·8비트 양자화
 + 추론 엔진 최적화

기존 모델을 줄일 때는 다음처럼 구성할 수 있다.

기존 LLM
   ↓ 구조적 프루닝
작은 학생 구조
   ↓ 증류·보정 학습
압축 sLLM
   ↓ 양자화
현장 배포 모델

따라서 모델을 소개할 때는 다음을 구분해야 한다.

• 처음부터 학습한 네이티브 sLLM인가?
• 대형 모델을 프루닝·증류한 파생 모델인가?
• 구조는 그대로인 양자화 LLM인가?
• 작은 공개 모델을 업무용으로 파인튜닝한 것인가?

6. 현재 사용되는 대표적인 모델

모델 시장은 빠르게 바뀐다. 다음 목록은 2026년 7월 기준으로 많이 검토되는 계열을 용도 중심으로 정리한 것이다.

모델 이름에 Mini, Flash, Lite가 들어간다고 모두 sLLM은 아니다. API 제품명은 가격이나 속도 등급을 뜻할 수 있으며 실제 파라미터 수가 공개되지 않은 경우도 있다.

6.1 클라우드 중심의 범용 LLM

비공개 상용 모델은 일반적으로 API와 서비스 형태로 제공되며, 웨이트를 내려받아 사내 GPU 서버에 자유롭게 설치할 수 없다.

6.2 로컬·엣지에서 검토되는 대표 sLLM

모델을 고를 때는 최신이라는 이유만으로 선택하지 말아야 한다.

• 한국어 성능
• 상업적 사용 조건
• 파생 모델 배포 조건
• 채팅 템플릿
• 양자화 형식
• Function Calling
• JSON 유효률
• 실제 장치의 TTFT와 tokens/s
• RAG 근거 충실도
• 장기 지원과 커뮤니티

를 직접 검증해야 한다.

6.3 Dense와 MoE 모델은 숫자를 다르게 읽어야 한다

MoE 모델은 총 파라미터와 토큰당 활성 파라미터가 다르다.

예를 들어 235B-A22B는 전체 웨이트가 약 235B지만 토큰을 처리할 때 약 22B 규모의 전문가만 활성화한다는 의미다.

총 파라미터
→ 파일 크기와 적재 메모리에 큰 영향

활성 파라미터
→ 토큰당 연산량과 생성 속도에 큰 영향

MoE 모델은 토큰당 연산을 줄일 수 있지만 전체 전문가 웨이트를 메모리에 올려야 하므로 같은 활성 파라미터의 Dense 모델보다 훨씬 많은 RAM이나 VRAM이 필요할 수 있다.

7. 왜 기업은 온프레미스에서 대형 LLM 대신 sLLM을 사용하는가?

기술적으로 공개된 대형 오픈 웨이트 모델을 기업 내부에 설치하는 것은 가능하다.

문제는 모델을 다운로드할 수 있느냐가 아니다.

필요한 속도와 동시 사용자 수를 유지하면서 감당할 수 있는 비용으로 지속 운영할 수 있느냐가 핵심이다.

7.1 대표 상용 LLM은 웨이트가 공개되지 않는다

GPT, Claude, Gemini의 대표적인 상용 모델은 API나 서비스 형태로 제공된다.

기업이 해당 모델의 웨이트를 내려받아 완전한 폐쇄망에 설치하는 형태가 일반적인 사용 방식은 아니다.

완전한 온프레미스가 필요하다면 다음 선택지가 있다.

• 오픈 웨이트 모델 사용
• 온프레미스 계약을 제공하는 기업용 제품
• 자체 모델 개발
• 공개 sLLM과 내부 RAG 구축
• 민감 작업은 로컬, 고난도 작업만 외부 API 사용

7.2 대형 LLM은 메모리 요구량이 크다

가중치 메모리의 단순 이론값은 다음과 같다.

가중치 메모리 ≈ 파라미터 수 × 파라미터당 바이트

실제 추론에는 다음 메모리가 추가된다.

• KV Cache
• 입력·출력 버퍼
• 추론 엔진 작업 공간
• CUDA Graph
• 동시 요청
• 긴 컨텍스트
• 비전 인코더
• 임베딩·재정렬 모델
• 운영체제와 다른 서비스

70B 모델을 4비트로 줄여 수십 GB에 적재하더라도 긴 컨텍스트와 여러 사용자를 처리하려면 48GB 또는 80GB급 GPU 한 장으로 부족할 수 있다.

7.3 서버와 운영비가 비싸다

대형 모델을 서비스하려면 다음 구성이 필요해질 수 있다.

• 48GB·80GB급 GPU
• 다중 GPU
• GPU 간 고속 연결
• 대용량 시스템 RAM
• 고전력 전원과 냉각
• 이중화 스토리지
• 고속 네트워크
• 모니터링과 예비 장비

GPU 구매비 외에도 다음 비용이 지속된다.

• 전력
• 냉각
• UPS
• 랙 공간
• 장애 대응
• 부품 교체
• 운영 인력
• 보안과 모델 업데이트

7.4 한 명의 실험과 기업 서비스는 다르다

개발자 한 명이 70B 모델에 질문해 답을 받는 것과 수십 명이 동시에 사용하는 서비스는 전혀 다르다.

동시 사용자가 늘면 다음 문제가 생긴다.

• KV Cache 증가
• GPU 메모리 부족
• 요청 큐 적체
• p95 지연시간 증가
• 긴 프롬프트의 Prefill 병목
• 모델 복제 비용 증가

단일 사용자에게 초당 15토큰이 나왔다고 해서 50명이 사용할 때도 같은 속도가 유지되는 것은 아니다.

7.5 기업 업무 대부분은 대형 모델의 모든 능력이 필요하지 않다

다음 업무를 처리하기 위해 수백B 모델의 모든 지식이 필요한 것은 아니다.

• 문서 분류
• 개인정보 탐지
• 정해진 필드 추출
• 회의록 요약
• 사내 규정 검색
• 설비 알람 설명
• API 함수 선택
• 보고서 양식 작성

업무를 좁히고 RAG, 구조화 출력과 검증기를 결합하면 3B~14B급 모델로도 충분한 경우가 많다.

7.6 sLLM은 비용과 지연시간을 통제하기 쉽다

sLLM은 모델 전체를 단일 GPU, 워크스테이션 또는 엣지 장치에 적재하기 쉽다.

• 네트워크 왕복 제거
• 외부 API 장애 영향 감소
• 호출 제한 회피
• 반복 요청의 낮은 한계비용
• 데이터 외부 전송 제거
• 고정된 모델·프롬프트 버전
• 장치별 용량 계획
• 예측 가능한 지연시간

기업이 sLLM을 선택하는 이유는 단순히 저렴해서가 아니다.

필요한 업무 성능을 통제 가능한 비용, 보안과 지연시간 조건으로 제공하기 쉽기 때문이다.

8. 왜 개인도 로컬에서 sLLM을 사용하는가?

개인이 로컬 AI를 사용하는 이유는 다음과 같다.

• 개인 문서와 이메일을 외부로 보내지 않기 위해
• API 요금과 사용량 제한을 피하기 위해
• 인터넷 없이 사용하기 위해
• 자신만의 RAG와 에이전트를 구축하기 위해
• 모델·프롬프트를 자유롭게 수정하기 위해
• 코딩과 자동화 도구를 상시 실행하기 위해

현실적으로 실행 가능한 모델 규모는 메모리에 크게 좌우된다.

이는 대략적인 범위다. 운영체제, KV Cache와 다른 프로그램을 위한 여유 메모리를 남겨야 한다.

9. Mac mini 품귀와 로컬 AI 열풍

2026년에는 고용량 Mac mini의 재고 부족과 긴 배송 지연이 보도됐다.

보도에서는 다음 원인이 함께 거론됐다.

• Apple의 수요 예측 문제
• 차세대 제품 출시를 앞둔 공급 조절 가능성
• AI 데이터센터 수요에 따른 메모리 공급 압박
• 로컬 AI 모델과 상시 실행 에이전트를 위한 고용량 제품 수요

따라서 Mac mini 품귀를 로컬 AI 하나의 원인으로 단정하면 안 된다. 다만 고용량 메모리 Mac을 로컬 AI 서버로 사용하려는 예상 밖의 수요가 원인 중 하나로 지목된 것은 중요한 변화다.

9.1 Apple Silicon이 로컬 LLM에 유리한 이유

일반적인 PC는 시스템 RAM과 GPU VRAM이 분리된다.

일반 PC
CPU ↔ 시스템 RAM
GPU ↔ 전용 VRAM

Apple Silicon은 CPU와 GPU가 통합 메모리를 공유한다.

Apple Silicon
CPU · GPU · Neural Engine
        ↕
     통합 메모리

통합 메모리의 장점은 다음과 같다.

• CPU와 GPU가 같은 메모리 공간 사용
• 데이터 복사 부담 감소
• 소비자용 GPU보다 큰 메모리 구성을 선택 가능
• 큰 양자화 모델을 한 장치에 적재하기 쉬움
• 전력과 소음이 낮은 편

Apple의 MLX는 Apple Silicon의 통합 메모리 구조를 활용하도록 설계된 프레임워크다.

9.2 Mac mini와 중고 MacBook이 관심받는 이유

Mac mini는 다음 특성 때문에 개인 로컬 AI 서버로 주목받았다.

• 작은 크기
• 낮은 소음
• 비교적 낮은 전력 소비
• 24시간 켜두기 쉬운 형태
• 고용량 통합 메모리 선택지
• MLX·llama.cpp·Ollama·LM Studio 지원
• 완제품이라 별도 조립이 필요 없음

고용량 M1 Max·M2 Max·M3 Max 계열 중고 MacBook Pro와 Mac Studio도 같은 이유로 관심을 받는다.

특히 중고 MacBook은 다음 장점이 있다.

• 신제품보다 낮은 가격
• 32GB·64GB 이상의 통합 메모리
• 화면과 배터리가 포함된 이동형 환경
• 7B~30B급 양자화 모델 실험
• 개발 PC와 로컬 AI 장치 겸용

다만 “맥이면 모두 로컬 AI에 좋다”는 말은 틀리다.

로컬 LLM에서는 CPU 세대보다 통합 메모리 용량과 메모리 대역폭이 더 중요할 수 있다. 8GB나 16GB 기본형은 실행 가능한 모델 범위가 제한적이다.

9.3 Mac이 항상 최선은 아니다

Apple Silicon의 한계도 분명하다.

• CUDA를 사용할 수 없다.
• 대규모 배치 추론은 NVIDIA가 유리하다.
• 학습과 파인튜닝 생태계는 NVIDIA가 성숙하다.
• 메모리를 나중에 증설할 수 없다.
• 고용량 옵션이 비싸다.
• 외장 GPU 확장이 어렵다.
• 다중 사용자 처리량은 서버 GPU가 유리하다.

Mac이 적합한 경우:

• 개인용 로컬 챗봇
• 문서 RAG
• 코딩 보조
• 상시 실행 개인 에이전트
• 개인정보 기반 자동화
• 저동시성 기업 PoC
• 7B~30B급 모델 실험

NVIDIA GPU 서버가 적합한 경우:

• 많은 동시 사용자
• 고속 배치 추론
• 모델 학습과 파인튜닝
• 70B 이상 고처리량
• vLLM·TensorRT-LLM 운영
• 다중 GPU 확장

Mac mini 품귀가 보여주는 핵심은 모든 사용자가 대형 LLM을 로컬에서 돌린다는 뜻이 아니다.

클라우드에만 의존하던 개인과 소규모 팀이 개인정보 보호, 사용량 제한 회피와 고정 비용 운영을 위해 sLLM과 양자화 모델을 자신의 기기에서 실행하기 시작했다는 신호에 가깝다.

10. 성능은 LLM과 sLLM 중 누가 더 좋은가?

결론부터 말하면 다음과 같다.

범용 지식과 복잡한 추론은 대형 LLM이 대체로 우세하지만, 범위가 명확한 업무에서는 잘 설계된 sLLM이 충분히 정확하거나 더 안정적일 수 있다.

10.1 대형 LLM이 유리한 영역

• 폭넓은 세계 지식
• 모호한 질문 해석
• 여러 조건을 포함한 추론
• 긴 단계의 문제 해결
• 낯선 문제에 대한 일반화
• 장문 일관성
• 복잡한 코드 분석
• 다중 도구 에이전트

10.2 sLLM이 유리할 수 있는 영역

예를 들어 고객 문의를 30개 코드로 분류하는 업무를 생각해 보자.

대형 LLM은 유창하게 설명하지만 회사의 내부 분류 기준을 정확히 모를 수 있다.

반면 sLLM을 실제 상담 데이터로 튜닝하고 출력값을 30개 코드 중 하나로 제한하면 다음 효과를 얻을 수 있다.

• 분류 정확도 향상
• 출력 형식 오류 감소
• 사내 용어 인식
• 짧은 응답 시간
• 낮은 비용
• 높은 재현성

즉, 실무에서 중요한 것은 공개 벤치마크 점수 하나가 아니라 업무 성공률이다.

10.3 성능 평가 지표

가장 실용적인 지표 중 하나는 다음과 같다.

성공한 업무 1건당 비용(Cost per Successful Task)

작은 모델이 요청당 저렴해도 오류가 많아 사람이 계속 수정해야 한다면 전체 비용은 더 높아질 수 있다.

11. 속도는 sLLM이 항상 빠른가?

sLLM이 대체로 적은 메모리와 연산량을 사용하지만 항상 더 빠른 것은 아니다.

속도는 다음 조건에 따라 달라진다.

• CPU·GPU·NPU 종류
• 메모리 대역폭
• 양자화 형식
• 추론 엔진
• 입력 길이
• 출력 길이
• 배치 크기
• 동시 사용자
• RAG 검색 시간
• 외부 도구 호출

11.1 반드시 구분해야 할 지표

TTFT

요청을 보낸 뒤 첫 토큰이 나타날 때까지 걸리는 시간이다.

입력이 길면 Prefill 시간이 늘어난다.

tokens/s

첫 토큰 이후 초당 생성되는 토큰 수다.

전체 지연시간

답변이 완성될 때까지 걸리는 시간이다.

p95 지연시간

전체 요청 중 95%가 완료되는 시간이다. 기업 서비스에서는 평균보다 p95가 더 중요하다.

11.2 작은 모델도 느릴 수 있는 경우

• CPU만 사용하고 메모리 대역폭이 낮음
• 긴 문서를 매번 전체 입력
• 하드웨어와 맞지 않는 양자화
• GPU와 CPU 사이의 잦은 레이어 이동
• 잘못된 배치 설정
• 동시 요청으로 KV Cache가 급증
• 느린 Python 후처리
• RAG나 도구 호출이 병목

반대로 대형 모델 API는 제공업체가 고성능 GPU와 최적화된 서빙 시스템을 사용하면 개인 PC의 sLLM보다 빠를 수 있다.

12. 기업이 sLLM을 구축하는 실무 절차

대부분의 기업은 처음부터 사전학습하지 않는다.

공개된 소형 베이스 모델에 RAG, 파인튜닝, 증류와 양자화를 조합하는 방식이 현실적이다.

12.1 목표 업무 정의

나쁜 목표:

우리 회사용 챗GPT를 만든다.

좋은 목표:

설비 매뉴얼과 정비 이력을 근거로 고장 원인 후보 3개와 점검 순서를 JSON으로 반환한다.

다음을 명확히 해야 한다.

• 입력은 무엇인가?
• 출력 형식은 무엇인가?
• 허용 지연시간은 얼마인가?
• 실패 위험은 어느 정도인가?
• 근거 인용이 필요한가?
• 인터넷 연결이 가능한가?
• 동시 사용자는 몇 명인가?
• 어떤 장치에서 실행할 것인가?

12.2 RAG로 해결 가능한지 먼저 확인

자주 바뀌는 회사 지식을 무조건 파인튜닝으로 넣을 필요는 없다.

질문
 ↓
권한 확인
 ↓
문서 검색·재정렬
 ↓
관련 근거 + 질문
 ↓
sLLM
 ↓
출처가 포함된 답변

RAG가 적합한 경우:

• 규정이 자주 바뀜
• 최신 문서가 중요함
• 출처를 제시해야 함
• 문서별 접근권한이 다름
• 재학습 없이 데이터를 갱신해야 함

파인튜닝이 적합한 경우:

• 고정된 출력 형식
• 사내 용어와 문체
• 특정 분류 기준
• 함수 호출 패턴
• 일관된 행동

실무에서는 다음 원칙이 유용하다.

RAG는 지식을 제공하고, 파인튜닝은 행동과 형식을 가르친다.

12.3 베이스 모델 선택

확인 항목:

• 한국어 성능
• 파라미터와 활성 파라미터
• 컨텍스트 길이
• 라이선스
• 채팅 템플릿
• Function Calling
• JSON 출력
• 양자화 모델
• 추론 엔진
• GPU·NPU 호환성
• 커뮤니티와 업데이트

12.4 데이터셋 구축

예시:

{
  "instruction": "모터 과열 알람의 원인 후보를 분류하라.",
  "input": "온도 92도, 전류 18A, 진동 정상, 냉각팬 RPM 0",
  "output": {
    "cause_code": "COOLING_FAN_FAILURE",
    "confidence": 0.94,
    "next_action": "팬 전원과 커넥터를 점검한다."
  }
}

데이터에는 다음 사례가 필요하다.

• 정상 사례
• 대표 오류
• 애매한 사례
• 정보 부족
• 답변 거부
• 조건 충돌
• 현장 약어와 오탈자
• 스키마 공격
• 프롬프트 인젝션

12.5 LoRA와 QLoRA

LoRA는 원본 모델을 고정하고 작은 저차원 어댑터만 학습한다.

QLoRA는 기본 모델을 4비트 등으로 양자화한 상태에서 LoRA를 학습한다.

장점:

• 낮은 GPU 메모리
• 빠른 학습
• 작은 어댑터 파일
• 업무별 어댑터 분리

12.6 양자화와 배포

대표 실행 환경:

PoC 도구와 운영용 서빙 시스템은 구분해야 한다.

운영 단계에서는 다음이 필요하다.

• 인증
• 요청 큐
• 배치 처리
• 모니터링
• 모델 버전 관리
• 장애 복구
• 회귀 평가
• 감사 로그

13. 현장에서는 sLLM을 어떻게 사용하는가?

13.1 제조업과 설비 유지보수

입력:

• PLC 알람
• 센서 요약
• 정비 매뉴얼
• 과거 고장 이력
• 작업자 메모

출력:

• 원인 후보
• 위험도
• 점검 순서
• 필요한 부품
• 매뉴얼 근거

안전한 구조는 다음과 같다.

센서·PLC
   ↓
이상 탐지 모델·규칙 엔진
   ↓
이벤트 요약
   ↓
RAG + sLLM
   ↓
작업자용 안내

sLLM이 센서 원시 데이터를 단독으로 판정하게 하기보다 기존 분석 모델의 결과를 설명하고 조치로 연결하는 방식이 안전하다.

13.2 비전 검사

비전 모델
   ↓ 불량 유형·좌표·신뢰도
sLLM + 작업 표준서
   ↓
불량 코드·원인·재작업 절차

sLLM은 이미지 판정의 최종 근거보다 비전 모델의 결과를 사람이 이해할 수 있는 설명과 조치로 변환하는 데 적합하다.

13.3 금융·보험

• 상담 기록 요약
• 약관 질의응답
• 민원 분류
• 심사 문서 필드 추출
• 내부 규정 점검
• 이상 거래 조사 보조

금융 분야에서는 근거 인용, 구조화 출력, 담당자 승인과 감사 로그가 중요하다.

13.4 의료

• 진료 기록 요약
• 의료진용 문서 검색
• 퇴원 안내문 초안
• 의료 코드 후보
• 검사 결과 설명 보조

의료 sLLM은 독립 진단보다 의료진의 문서 작성과 정보 검색을 보조하는 형태가 현실적이다.

13.5 공공·국방·폐쇄망

• 행정 규정 검색
• 민원 초안
• 회의록 요약
• 보고서 형식 변환
• 장비 매뉴얼 질의응답
• 내부 지식 검색

외부 API가 제한되는 환경에서는 모델, 임베딩, 벡터 DB와 로그를 모두 내부망에 배치한다.

13.6 모바일과 개인 기기

• 메시지 요약
• 키보드 문장 추천
• 오프라인 번역
• 음성 명령
• 메모 분류
• 앱 내부 자연어 명령
• 개인 데이터 검색

온디바이스의 장점은 오프라인 동작, 개인정보 보호와 낮은 지연시간이다.

13.7 로봇·드론·차량

언어 모델이 모터를 직접 제어하게 하면 위험하다.

자연어 명령
   ↓
sLLM: 의도와 인수를 JSON으로 변환
   ↓
안전 정책·권한 검증
   ↓
승인된 제어 함수
   ↓
제어기

sLLM은 자연어 인터페이스를 담당하고 실제 제어는 결정론적 시스템이 수행해야 한다.

14. 가장 현실적인 구조: sLLM 우선, LLM 폴백

기업은 sLLM와 LLM 중 하나만 선택할 필요가 없다.

사용자 요청
   ↓
민감정보 제거·권한 확인
   ↓
라우터
   ├─ 단순·정형 업무 → sLLM
   ├─ 복잡·모호한 업무 → LLM
   └─ 고위험 업무 → 사람
   ↓
검증기
   ↓
최종 응답

sLLM에 적합한 작업:

• 분류
• 정보 추출
• 짧은 요약
• 정형 보고서
• 단일 함수 호출
• 반복적인 사내 업무
• 개인정보 로컬 처리

LLM에 적합한 작업:

• 복잡한 추론
• 다수 문서 종합
• 새로운 유형의 질문
• 긴 계획 수립
• sLLM 신뢰도가 낮은 요청
• 여러 도구를 사용하는 에이전트

이 구조는 비용과 지연시간을 낮추면서 대형 모델의 고급 능력을 유지할 수 있다.

15. 2026년 sLLM 트렌드

15.1 가장 큰 모델보다 가장 적합한 모델

기업의 관심은 파라미터 경쟁에서 다음으로 이동하고 있다.

• 실제 업무 성공률
• 성공 작업당 비용
• p95 지연시간
• 데이터 보안
• 전력 효율
• 구조화 출력
• 운영 가능성

15.2 온디바이스 AI 확대

Google의 Gemma, Microsoft의 Phi, Meta의 Llama 소형 모델과 Mistral의 Ministral은 모바일·PC·엣지 실행을 중요한 목표로 삼고 있다.

스마트폰과 PC에 NPU가 보급되면서 다음 기능이 로컬로 이동하고 있다.

• 요약
• 번역
• 문장 추천
• 앱 명령
• 개인정보 기반 검색
• 경량 멀티모달 이해

15.3 초소형 전문 모델

하나의 7B 모델에 모든 역할을 맡기기보다 수백M~수B 모델을 전문 부품으로 사용하는 흐름이 커지고 있다.

• 라우터
• 문서 분류기
• 개인정보 탐지
• 검색어 재작성
• 함수 호출
• Guardrail
• 답변 검증기

15.4 구조화 출력과 검증기 중심

프롬프트만으로 모델을 통제하기보다 다음을 결합한다.

• JSON Schema
• 문법 제약 디코딩
• 함수 화이트리스트
• 타입 검사
• 정책 엔진
• 실행 전 승인
• 결과 재검증
• LLM 또는 사람 폴백

15.5 멀티모달 sLLM

소형 모델도 텍스트만 처리하지 않는다.

• 장비 사진 설명
• 계기판 인식
• 문서 이미지 추출
• 작업자 음성 명령
• 비전 검사 결과 설명
• 로봇 카메라와 작업 지시 결합

다만 안전이 중요한 판정은 전용 비전·센서 모델과 규칙 엔진이 담당하는 것이 바람직하다.

15.6 하드웨어와 모델의 공동 최적화

같은 4비트 모델이라도 하드웨어와 런타임에 따라 속도가 다르다.

• 메모리 대역폭
• 양자화 형식
• KV Cache
• 배치
• 추론 엔진
• NPU 지원 연산
• 전력 제한
• 발열
• 지속 성능

엣지에서는 최고 속도보다 와트당 처리량과 장시간 안정성이 더 중요할 수 있다.

16. sLLM 도입 시 흔한 실패 원인

16.1 모델부터 고른다

유명한 모델을 먼저 선택하고 업무를 끼워 맞추면 실패하기 쉽다.

목표, 데이터, 출력 형식과 평가 기준을 먼저 정해야 한다.

16.2 공개 벤치마크만 믿는다

영어 벤치마크 점수가 높아도 한국어 현장 약어와 숫자 추출에서는 성능이 낮을 수 있다.

16.3 파인튜닝으로 모든 지식을 넣으려 한다

자주 바뀌는 지식은 RAG로 관리해야 한다.

파인튜닝은 최신 문서 데이터베이스를 대체하지 못한다.

16.4 작은 모델에 너무 많은 일을 맡긴다

분류, 검색, 장문 작성, 복잡한 판단과 다단계 도구 호출을 하나의 작은 모델에 모두 맡기면 오류가 누적된다.

16.5 평균 속도만 본다

평균보다 동시 사용자 환경의 p95 지연시간을 봐야 한다.

16.6 사람 검토 비용을 계산하지 않는다

모델 응답을 직원이 매번 수정하면 요청당 모델 비용이 낮아도 전체 비용은 증가한다.

16.7 라이선스를 확인하지 않는다

오픈 웨이트는 반드시 오픈소스와 같은 뜻이 아니다.

다음을 확인해야 한다.

• 상업적 이용
• 파생 모델 배포
• 재배포
• 사용자 수·매출 제한
• 학습 데이터 사용
• 출력물 이용 조건

17. 실무 도입 체크리스트

업무

• 입력과 출력이 명확한가?
• 실패 위험을 정의했는가?
• 사람 검토 조건이 있는가?
• 목표 지연시간과 동시 사용자를 정했는가?

데이터

• 학습·검증·테스트가 분리됐는가?
• 개인정보를 처리했는가?
• 현장 약어와 오탈자가 포함됐는가?
• 합성 데이터의 품질을 검수했는가?

모델

• 한국어와 도메인 성능을 직접 평가했는가?
• 라이선스를 확인했는가?
• 양자화 전후를 비교했는가?
• 실제 하드웨어에서 측정했는가?
• RAG 근거 충실도를 확인했는가?

운영

• 인증과 권한 관리가 적용됐는가?
• 로그의 민감정보를 마스킹하는가?
• 모델·프롬프트·데이터 버전을 기록하는가?
• p50·p95와 메모리를 모니터링하는가?
• sLLM 실패 시 폴백이 있는가?
• 회귀 평가를 자동 실행하는가?

18. 결론

sLLM와 LLM의 차이를 단순히 “작은 모델과 큰 모델”로 설명하면 중요한 부분을 놓치게 된다.

sLLM은 다음과 같은 여러 형태로 만들어진다.

1. 처음부터 작은 구조로 설계하고 사전학습한 모델
2. 기존 LLM의 레이어와 차원을 줄인 모델
3. 대형 모델의 능력을 작은 학생 모델에 증류한 모델
4. 기존 모델의 웨이트를 양자화한 경량 모델
5. 공개 소형 모델을 특정 업무에 맞게 파인튜닝한 모델

이 가운데 양자화된 대형 모델은 저장 용량이 작아졌더라도 파라미터 수와 구조 기준에서는 sLLM과 구분해야 한다.

대형 LLM은 범용 지식, 복잡한 추론과 새로운 문제에 강하다. sLLM은 제한된 업무를 빠르고 저렴하게 처리하고, 기업 내부나 사용자 기기에서 데이터를 보호할 수 있다는 강점이 있다.

2026년의 핵심 흐름은 하나의 모델이 모든 일을 처리하는 것이 아니다.

sLLM이 반복적이고 정형화된 업무를 처리하고, RAG가 최신 지식을 제공하며, 검증기가 오류를 차단하고, 어려운 요청만 대형 LLM이나 사람에게 넘기는 구조가 현실적인 방향이다.

Mac mini와 고용량 Apple Silicon 기기에 대한 로컬 AI 수요 역시 같은 흐름을 보여준다. 개인과 소규모 팀도 클라우드 API에만 의존하지 않고 자신이 통제할 수 있는 장치에서 sLLM과 양자화 모델을 실행하기 시작했다.

결국 좋은 모델은 가장 큰 모델이 아니다.

목표 업무의 정확도, 속도, 비용, 보안과 운영 조건을 가장 잘 만족하는 모델이 좋은 모델이다.

자주 묻는 질문

sLLM은 LLM보다 성능이 낮은가?

범용 지식과 복잡한 추론은 대형 LLM이 대체로 우세하다. 하지만 범위가 좁은 업무는 RAG, 파인튜닝과 출력 제약을 적용한 sLLM이 더 안정적일 수 있다.

70B 모델을 4비트로 양자화하면 sLLM인가?

엄밀히 말하면 아니다. 메모리와 파일 크기는 줄지만 구조와 파라미터 수는 70B로 유지된다. 양자화된 대형 LLM이라고 부르는 편이 정확하다.

sLLM을 처음부터 학습해야 하는가?

대부분의 기업은 그럴 필요가 없다. 공개 소형 모델에 RAG, LoRA·QLoRA와 양자화를 적용하는 방식이 현실적이다.

RAG와 파인튜닝 중 무엇을 사용해야 하는가?

최신 지식과 출처가 중요하면 RAG, 출력 형식과 행동을 학습하려면 파인튜닝이 적합하다. 두 기술을 함께 사용하는 경우가 많다.

Mac mini가 로컬 LLM에 좋은 이유는 무엇인가?

Apple Silicon의 통합 메모리, 낮은 전력과 작은 크기 때문이다. 다만 고성능 학습, 대규모 동시 사용자와 CUDA 기반 운영에는 NVIDIA GPU 서버가 더 적합하다.

sLLM이 LLM을 대체할까?

완전히 대체하기보다 역할을 나눌 가능성이 높다. 정형 업무는 sLLM, 복잡한 분석과 예외 처리는 대형 LLM이 담당하는 하이브리드 구조가 유력하다.

참고 자료

• Microsoft Azure, What Are Small Language Models
• Microsoft Azure, Phi Open Models
• Google AI for Developers, Gemma
• Google AI for Developers, Gemma 4 Model Overview
• Meta AI, Llama 3.2: Edge AI and Vision
• Meta AI, Quantized Llama Models
• Qwen, Qwen3
• Mistral AI, Mistral 3 and Ministral 3
• IBM, Granite Models
• LG AI Research, EXAONE
• MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases
• PhoneLM: An Efficient and Capable Small Language Model Family
• A Survey on Model Compression for Large Language Models
• Hugging Face Transformers, Quantization Overview
• NVIDIA NeMo, Quantization
• Apple ML Research, MLX and Apple Silicon
• The Wall Street Journal, The Mystery of Why You Can’t Buy a Mac Mini Right Now

같이 보기

• sLLM 완벽 가이드: 작은 고추가 맵다! 온디바이스 AI의 미래를 열다
• 소형 AI 모델 혁명: SLM과 온디바이스 AI가 바꾸는 미래 – 클라우드 없이 스마트폰에서 GPT급 AI를!
• 역설의 칩들: 왜 똑같이 AI를 돌리는데 어떤 건 배우지 못하고 추론만 하는가?
• LLM 양자화 & 경량화 완벽 가이드: 70B 모델을 4GB로 압축하는 마법! GPTQ, AWQ, GGUF 총정리
• GPT vs Claude vs Gemini – 생성형 AI 완전 해부: Transformer부터 멀티모달까지
• BERT vs GPT – 두 거인의 차이점