Field note · 2026-04-17

경량 LLM 앙상블로 NLP 품질을 높이는 법

NLP 파이프라인에 LLM을 쓰다 보면 이런 상황에 자주 부딪힌다. 모델 하나를 골라 잘 쓰고 있는데, 가끔씩 답이 어긋난다. 더 좋은 모델로 교체하려니 비용이 부담되고, 그렇다고 틀린 답을 그대로 받아들일 수도 없다. 이럴 때 꺼내 볼 수 있는 카드가 앙상블이다. 원리는 의외로 단순하다. 서로 다른 방식으로 학습된 세

경량 LLM 앙상블로 NLP 품질을 높이는 법


1. 앙상블이 왜 통하는가

NLP 파이프라인에 LLM을 쓰다 보면 이런 상황에 자주 부딪힌다. 모델 하나를 골라 잘 쓰고 있는데, 가끔씩 답이 어긋난다. 더 좋은 모델로 교체하려니 비용이 부담되고, 그렇다고 틀린 답을 그대로 받아들일 수도 없다. 이럴 때 꺼내 볼 수 있는 카드가 앙상블이다.

원리는 의외로 단순하다. 서로 다른 방식으로 학습된 세 모델에게 같은 질문을 던지면, 세 모델이 동시에 똑같이 틀릴 확률이 매우 낮아진다. 각자 학습한 데이터가 다르고 훈련 방식이 다르니, 실수하는 지점도 각자 다르기 때문이다. 이 성질을 이용해 여러 모델의 답을 합의시켜 최종 답을 뽑는 게 앙상블의 전부다.

그 효과는 이미 수치로 확인됐다. Self-Consistency 논문(Wang et al., ICLR 2023)은 같은 모델(PaLM 540B)에서 40개 샘플을 뽑아 단순 다수결만 적용해도 GSM8K 수학 정확도가 17.9%p 오른다는 걸 보였다. 모델을 교체하지도, 재학습하지도 않고 얻은 향상이다.

단, 조건이 하나 있다. 같은 병원 의사 세 명에게 의견을 묻는 것은 앙상블이 아니다. 같은 교수 밑에서 같은 방식으로 훈련받은 의사들은 같은 지점에서 같은 실수를 반복한다. LLM도 다르지 않다. 유효한 앙상블이 되려면 아래 세 축 전부에서 다양성이 확보되어야 한다.

다양성 축Gemma 4 E4BQwen3.5-4BPhi-4-mini
아키텍처Dense + PLEGated DeltaNet + MoEDense
정렬 방식RLHF 계열RLHF 계열SFT + DPO
벤더/데이터Google (영어 중심)Alibaba (201개 언어)Microsoft (합성 데이터)

세 모델이 같은 입력에 대해 똑같이 틀릴 조건 자체가 성립하기 어렵다. 이게 이 구성을 선택한 이유다.


2. Proposer와 Arbiter — 역할 분담

다양성만 있다고 앙상블이 완성되지는 않는다. 세 모델이 각자 다른 답을 냈을 때 어떤 답을 최종으로 채택할 것인가라는 문제가 남는다. 이 합의 절차를 담당하는 게 Proposer와 Arbiter 구조다.

쉽게 말하면 법정 배심원제에 가깝다. Proposer 두 명은 독립적으로 의견을 제시하는 배심원이고, Arbiter 한 명은 배심원 의견이 갈렸을 때 결정을 내리는 재판장 역할이다. 두 Proposer가 같은 답을 내면 재판장 개입 없이 확정된다. 의견이 갈리거나 세 모델이 모두 다른 답을 내면, Arbiter가 최종 판단을 내린다.

Arbiter 역할에 Phi-4-mini를 배치한 데는 이유가 있다. 이 모델은 DPO(Direct Preference Optimization) 라는 특수한 방식으로 정렬된 모델이다. DPO는 "답 A보다 답 B가 낫다"는 선호 쌍 데이터를 직접 학습시키는 방법인데, 덕분에 카테고리에 딱 떨어지지 않는 애매한 입력에서 "덜 어색한 답"을 고르는 능력이 상대적으로 강하다. 배심원 의견이 갈리는 경계 케이스에서 필요한 바로 그 능력이다. 게다가 파라미터 크기가 3.8B로 작아 순차 실행 시 지연도 덜 준다.

한 가지 흥미로운 부가 효과가 있다. 1:1:1 완전 불일치 비율이 그 자체로 운영 지표가 된다는 점이다. 운영 중 이 비율이 갑자기 오르면 "입력 분포가 학습 당시와 달라졌거나(drift), 정의되지 않은 카테고리의 입력(OOS)이 늘고 있다"는 신호다. 앙상블은 품질 향상만이 아니라, 품질 이상을 감지하는 경보 시스템으로도 작동한다.

참고로 이 역할 배치가 고정된 건 아니다. 수치 추론처럼 DPO의 강점이 크게 발휘되지 않는 태스크에서는 Phi-4-mini를 Proposer로 배치하고 세 모델 모두에 단순 다수결을 적용할 수도 있다. 역할 할당은 태스크 성격에 따라 설계자가 결정하는 영역이다.


3. 앙상블이 실제로 얼마나 효과적인가

"직관은 그렇다 치고, 실제로 얼마나 효과가 있느냐"는 질문이 자연스럽게 따라온다. 세 개의 공개 논문이 서로 다른 각도에서 이 질문에 답한다.

논문태스크단일 모델앙상블향상
Self-ConsistencyGSM8K (수학)PaLM 540B greedy CoT+17.9%parXiv:2203.11171
Self-ConsistencyAQuA (수학 추론)PaLM 540B 35.8%48.0% (+12.2%p)arXiv:2203.11171
Self-ConsistencyStrategyQA (상식)PaLM 540B greedy CoT+6.4%parXiv:2203.11171
MoA, 2024AlpacaEval 2.0 LC WRGPT-4 Omni 57.5%오픈소스 앙상블 65.1%arXiv:2406.04692
Majority RulesIAB Tier-1 콘텐츠 분류 F1Claude 3.5 Sonnet 0.5510-모델 앙상블 0.92arXiv:2511.15714

세 실험이 보여주는 메시지는 각기 다르지만, 관통하는 패턴은 세 가지로 정리된다.

① 모델을 바꾸지 않아도 효과가 난다. Self-Consistency는 놀랍게도 같은 PaLM 540B의 출력을 여러 번 뽑아 다수결만 적용한 실험이다. 새 모델을 학습시키지도, 파인튜닝을 돌리지도 않았는데 두 자릿수 %p 개선이 나왔다. "추론 비용을 조금 더 쓰는 것만으로 품질이 올라가는" 구조다.

② 더 비싼 모델이 항상 답은 아니다. MoA 실험은 오픈소스 모델 6개(Qwen1.5-110B, LLaMA-3-70B 등)를 3계층으로 쌓아 Proposer-Aggregator로 연결했는데, GPT-4 Omni 단일 모델을 7.6%p 앞섰다. "프리미엄 모델 한 개"가 반드시 "오픈소스 여러 개의 앙상블"보다 나은 건 아니라는 얘기다. 모델 선택의 경제학이 달라진다.

③ 정답 구조가 명확할수록 효과가 크다. 수학 문제(+17.9%p)나 콘텐츠 분류(F1 +0.37)처럼 정답이 이산적(discrete)인 태스크에서는 도약이 크다. 반면 개방형 상식 추론(+6.4%p)처럼 정답이 애매한 태스크에서는 향상폭이 완만하다. 다수결은 결국 "어느 답이 더 자주 나왔는가"를 세는 것이기 때문에, 정답이 뚜렷할수록 수렴이 잘 된다.


4. 비용 — API vs 로컬 디바이스

앙상블에는 피할 수 없는 비용 측면의 진실이 하나 있다. 모델을 3번 호출하므로 추론 비용도 대략 3배가 된다는 점이다. 품질이 올라간다고 해도 이 비용을 어떻게 감당할지 계획이 서야 실전 배포로 이어진다.

선택지는 크게 두 가지다. 첫째, 클라우드 API로 돌리기. 초기 투자 없이 시작할 수 있지만 호출량이 늘수록 비용이 선형으로 증가한다. 둘째, 로컬 디바이스에 모델을 올리기. 초기 비용이 들지만 이후로는 전기료만 든다. 어느 쪽이 유리한지는 호출 규모와 응답 속도 요구에 따라 갈린다.

4.1 API 단가 비교

먼저 API 선택지를 살펴보자. 의외로 경량 오픈소스 모델의 API 비용은 생각보다 훨씬 싸다. Together.ai에서 Gemma 3n E4B 하나를 400토큰 입력·200토큰 출력으로 호출하면 호출당 $0.000016에 불과하다. 이를 3개 모델 앙상블로 확장해도 $0.000234 수준이며, 이는 비교 기준인 GPT-4o-mini 단일 호출($0.000180)보다 고작 30% 비싼 정도다.

구성입력 $/1M출력 $/1M1회 비용 (400/200 tok)
Gemma 3n E4B 단일 (Together.ai)$0.02$0.04$0.000016
3-모델 혼합 앙상블 (per-model avg, 추정)~$0.10~$0.19~$0.000234
GPT-4o-mini 단일 (OpenAI)$0.15$0.60$0.000180

출처: Together.ai Pricing, OpenAI API Pricing

즉 "3개 모델을 돌리는 비용"이 "단일 GPT-4o-mini 비용"과 사실상 비슷하다. 품질 향상 대비 비용 증가는 충분히 감당할 만한 수준이다. 거기에 더해 Gemma 4 E4B는 Google AI Studio에서 분당 요청 제한 내 무료로 제공된다. 그래서 프로토타입 단계라면 앙상블 비용이 실질적으로 $0으로 떨어질 수도 있다.

⚠️ Phi-4-mini·Qwen3.5-4B의 Together.ai 공식 단가는 페이지 직접 확인 권장. $0.000234는 Gemma 단가($0.02/$0.04) + Phi·Qwen 추정 혼합값이다.

4.2 로컬 디바이스 단가

API가 싸도 호출량이 많아지면 얘기가 달라진다. 이럴 때 로컬 디바이스가 대안이 된다. 로컬 앙상블에서 가장 먼저 던질 질문은 "내 장비에 이 세 모델이 들어가느냐"다. 다행히 Q4 양자화를 적용하면 세 모델 합쳐서 약 10GB 수준에 맞출 수 있다 (Gemma 4 E4B ~5GB + Phi-4-mini ~2.5GB + Qwen3.5-4B ~2.5GB). 16GB 메모리를 가진 Mac mini M4($599)에 여유 있게 들어간다는 뜻이다.

디바이스구매가Gemma 4 E4B 추론속도3모델 순차 지연 (출력 300 tok)월 운영비
Mac mini M4 (16GB)$599~24 tok/s37.5초$22.8
Mac mini M4 Pro (24GB)$1,399~54 tok/s16.7초$51.9

출처: Apple Newsroom — Mac mini, 추론속도: Medium — Gemma 4 E4B on Mac

로컬은 "초기에 디바이스 값을 치르고, 이후로는 전기료만 낸다"는 구조다. Mac mini M4 16GB를 예로 들어 월 운영비를 계산해 보자.

M4 16GB 월 운영비 계산 근거:

  • 하드웨어 36개월 분할: $599 / 36 = $16.6/월
  • 전기료: 40W × 24h × 30일 × $0.215/kWh ≈ $6.2/월
  • 합계 $22.8/월

4.3 손익분기점

위 운영비를 API 호출당 비용($0.000234)으로 나누면, "몇 건부터 로컬이 더 저렴해지는가"가 나온다.

M4 16GB: $22.8/월 ÷ 30일 ÷ $0.000234/회 ≈ 3,248회/일 → 약 3,200회/일
M4 Pro : $51.9/월 ÷ 30일 ÷ $0.000234/회 ≈ 7,393회/일 → 약 7,400회/일

M4 16GB는 하루 3,200회, M4 Pro는 하루 7,400회 이상 앙상블을 호출한다면 API보다 로컬이 더 저렴하다. 참고로 Mac mini는 24시간 켜 둬도 전기료가 $6 내외라, 서버용 PC보다 훨씬 경제적이다.

한 가지 더 체크해야 할 것이 응답 속도다. M4에서 3모델 순차 앙상블은 회당 약 37초 걸린다(M4 Pro는 약 17초). 실시간 챗봇이나 API 응답처럼 초 단위 응답이 필요한 경우에는 맞지 않는다. 반대로 LLM-as-a-Judge, 품질 검수 파이프라인, 배치 라벨링처럼 비동기로 돌려도 되는 태스크라면 37초 지연은 문제가 되지 않는다. 로컬 앙상블이 가장 빛나는 구간이 바로 이런 비동기 품질 파이프라인이다.

4.4 배포 전략 결정 트리

위 조건들을 하나의 결정 트리로 정리하면 다음과 같다.


5. 태스크 유형별 합의 방식

앙상블에서 가장 많이 고민하게 되는 부분이 "어떤 방식으로 합의시킬 것인가" 다. 다행히 모든 태스크를 하나씩 따로 볼 필요는 없다. NLP 태스크는 출력 형태를 기준으로 네 유형(분류·추출·추론·생성)으로 묶이고, 같은 유형이면 집계 방식도 대체로 공유된다. 유형별로 하나씩 풀어 보자.

5.1 분류 (Classification) — 7개 태스크

대상: Intent · Topic · Sentiment · NLI · Grammatical · STS · Dialogue Act

출력이 "레이블 하나"인 경우가 대부분이라 앙상블 적용이 가장 쉬운 유형이다. 처음 앙상블을 도입한다면 여기부터 시작하는 게 자연스럽다. 집계 방식은 출력 형태에 따라 아래처럼 조금씩 갈린다.

태스크집계 방식메커니즘
Intent · NLI · Grammatical · Dialogue ActMajority Voting레이블 하나 → 다수결
Topic ClassificationThreshold Set Agreement레이블별 독립 투표 (2/3 동의)
Sentiment AnalysisConfidence-Weighted Voting반어·풍자에서 confidence 분포 활용
STSEnsemble Average0~1 연속값 평균

분류 앙상블의 부가 효과: 모델 간 불일치 자체가 데이터 품질의 신호가 된다. 예컨대 감성 분석에서 세 모델이 긍정·부정·중립으로 서로 엇갈리게 답하면, 그 문장에 반어나 풍자가 섞여 있을 가능성이 높다. Intent 분류에서 세 모델이 모두 다른 레이블을 내놓으면, 기존 카테고리에는 없던 새로운 유형의 입력일 공산이 크다. 분류 앙상블은 품질 향상과 데이터 이상 탐지를 동시에 얻는 일석이조 구조다.

5.2 추출 (Extraction) — 6개 태스크

대상: NER · Relation Extraction · Slot Filling · Event Detection · SRL · Coreference

추출은 앙상블 구현 난이도가 가장 높은 유형이다. 왜 그럴까? 추출 태스크의 출력은 "텍스트 속 특정 범위(span)"인데, 두 모델이 같은 개체를 가리키면서도 범위를 조금씩 다르게 뽑는 일이 흔하기 때문이다. "3~7번째 글자"와 "3~8번째 글자"는 산술적으로는 다른 값이지만, 실제로는 거의 같은 대상을 가리킬 수 있다. 그래서 다수결을 곧바로 적용할 수가 없다.

해법은 두 범위의 "겹침 정도"를 기준으로 같은 대상인지 판단하는 것이다. 이를 Span IoU(Intersection over Union) 방식이라고 부른다.

Span IoU Merge 원리:

IoU(span_A, span_B) = |overlap| / |union|

IoU ≥ 0.5  → 같은 개체로 합의, 유형(type)은 Majority Voting
IoU < 0.5  → HITL (사람 검토)

임계값 0.5는 NLP 고유의 값이 아니라, 객체 검출 분야(PASCAL VOC, COCO 벤치마크)에서 오래 전부터 표준으로 정착한 값을 가져온 것이다. "절반 이상 겹치면 같은 대상"이라는 직관에 부합한다.

태스크집계 방식특이사항
NER · Slot · EventSpan IoU MergeIoU ≥ 0.5 합의, type 다수결
Relation ExtractionPair-level Voting(entity_1, entity_2) 쌍을 키로 relation_type 투표
SRLFrame-level Agreement술어 단위로 논항 Span IoU 반복
CoreferenceCluster Merge Agreementmention 쌍 투표 → Agglomerative Clustering, 전이 일관성 유지

5.3 추론 (Reasoning) — 3개 태스크

대상: MRC · Commonsense Reasoning · Argument Mining

추론 태스크는 하나의 유형으로 묶기 애매한 부분이 있다. 같은 기계 독해(MRC)여도 지문에서 답 구간을 뽑는 추출형이냐, 멀티홉 추론 후 자유 문장으로 답하는 생성형이냐에 따라 집계 방식이 전혀 달라지기 때문이다.

태스크집계 방식비고
MRC (추출형)Span IoU Mergeunanswerable 탐지 포함
MRC (생성형)MoAPhi-4-mini Aggregator가 사실 일관성 검증
Commonsense ReasoningMajority Voting벤더별 학습 데이터 차이 → 문화·도메인 커버리지 보완
Argument MiningSpan IoU Mergeclaim-evidence 구조

Commonsense Reasoning에서는 벤더 다양성이 특히 빛을 발한다. Google·Alibaba·Microsoft는 학습 데이터 출처가 다르므로, 한 벤더의 모델이 놓친 문화·도메인별 상식을 다른 벤더가 보완해 준다. "다양성이 앙상블의 연료"라는 원칙이 가장 잘 적용되는 태스크다.

5.4 생성 (Generation) — 4개 태스크

대상: Summarization · Machine Translation · Question Generation · Data-to-Text

생성 태스크는 출력이 자유형식 문장이라 다수결 자체가 원천적으로 불가능하다. 세 모델이 "같은 의미"의 요약을 만들어도, 어휘와 문장 구조가 다르면 "같은 답"으로 볼 수 없기 때문이다. 그래서 생성 태스크에는 두 가지 대체 전략이 쓰인다.

왜 번역에는 MBR을, 요약에는 MoA를 쓰는 걸까? Aggregator가 새 문장을 만들어낸다는 점이 핵심 차이다. 요약은 원문의 내용을 압축·재구성하는 작업이라 새 문장이 생겨나도 크게 문제될 게 없다. 오히려 여러 초안의 장점을 합친 문장이 더 좋은 요약이 될 수 있다. 반면 번역은 "원문에 없던 내용이 들어가면 안 된다"는 제약이 엄격하다. MoA Aggregator가 환각을 섞어 넣을 위험을 감수할 수 없다. 이럴 때는 기존 후보 중 하나를 고르는 MBR이 훨씬 안전하다. 태스크의 제약 조건이 집계 방식을 결정하는 대표적인 사례다.


6. 도입 우선순위

정리하자면, 앙상블 도입은 한 번에 전체 시스템을 바꾸려 하지 말고 구현 난이도가 낮은 곳부터 단계적으로 확장하는 전략이 현실적이다. 순서를 다음과 같이 제안한다.

우선순위유형구현 난이도이유
1분류낮음다수결만으로 즉시 효과 검증. Intent·감성부터 시작
2추론중간분류 파이프라인 위에 자연스럽게 확장
3생성높음Aggregator 추가 호출, 품질 평가 기준 별도 설계
4추출매우 높음Span IoU + HITL 플로우 구현 비용 최대

1순위인 분류부터 시작하면 앙상블 인프라를 가장 작은 비용으로 검증할 수 있다. 세 모델을 호출하고 투표를 집계하는 기본 구조만 만들면 되고, 단일 모델 대비 F1·Accuracy가 얼마나 올랐는지 즉시 측정된다. 실패해도 단일 모델로 롤백하기 쉽다. Intent 분류나 감성 분석 한두 태스크를 시범 운영해 본 뒤, 추론·생성으로 확장하고 마지막에 난이도 최상위인 추출을 붙이는 흐름이 안정적이다.

마지막으로 한 줄로 정리하면 이렇다. 앙상블은 모델을 "더 좋은 것"으로 바꾸는 게 아니라, 지금 가진 모델들을 "더 잘" 쓰는 방법이다. 비용 증가는 API 기준 약 30%에 불과하고, 하루 3,200콜 이상 규모라면 로컬 전환으로 오히려 줄어든다. 품질 향상과 이상 탐지를 동시에 얻을 수 있다는 점을 생각하면, 감당할 만한 비용으로 얻는 가장 큰 레버리지 중 하나다.


출처

논문

가격 및 하드웨어

추론 속도 벤치마크

API 무료 티어