LLM이 다 할 필요는 없다: 20억 파라미터 의사결정 모델 'Strands Decider 2B'

한눈에 보는 요약

AWS의 실험 조직 strands-labs가 Strands Decider 2B를 공개했습니다. 이 모델의 특징은 한 문장으로 정리됩니다. 텍스트를 생성하지 않고, 주어진 선택지 중 하나를 고르거나 0~1 사이의 점수를 매기는 일만 합니다.

크기는 20억(2B) 파라미터 — 로컬 CPU/GPU에서 충분히 돌아갑니다
모든 결정에 신뢰도 점수가 함께 나옵니다
JevBench 공개 세트 평가에서 2B급 33개 모델 중 3위
RTX 3090 기준 결정 지연 중앙값 약 115ms
코드, 가중치, 학습 데이터와 학습 스크립트까지 전부 공개

의사결정 모델이란 무엇인가

'의사결정 모델(decision model)', 다르게는 시스템 1 모델이라고 부르는 이 유형은 TypeSafe AI의 Jev 출시 이후 관심이 커졌습니다. 자유로운 텍스트 대신 제한된 선택지나 수치만 출력하는 모델이죠. 실제로 이런 질문들을 처리합니다.

"turn on the lights"가 커피 머신에 관한 요청인가? → 예/아니요
"sihamba ngokushesha"는 어떤 언어인가? → English / Zulu / Dutch 중 하나
"this is the best doc I've ever read"의 긍정 감정 정도는? → 0~1 점수

유연성을 버리고 속도와 정확도를 얻는 거래

출력의 자유도를 포기한 대가로, 같은 크기의 범용 모델보다 더 빠르고 해당 작업에서 더 정확합니다. 선택형 질문에서는 반드시 주어진 선택지 중 하나를 반환하므로 파싱 실패나 포맷 오류를 걱정할 필요가 없습니다. 모든 출력을 한 번의 병렬 처리로 계산해 지연 시간도 짧습니다.

여기에 더해 각 결정마다 고품질 신뢰도 점수를 제공합니다. 최첨단 LLM 추론 API조차 제공하지 않는 정보인데, "이 판단을 얼마나 믿어야 하는가"를 코드에서 임계값으로 다룰 수 있게 해줍니다.

할 수 없는 일도 분명합니다

복잡한 문제 해결 능력은 추론 모델보다 크게 떨어집니다
텍스트를 생성하지 않으므로 코딩, 챗봇, 문서 요약 같은 일반적인 LLM 작업에는 부적합합니다

만능 도구가 아니라, 특정 모양의 문제에 맞춘 전용 도구로 보는 게 정확합니다.

구조: LM 헤드를 떼고 포인터 헤드를 붙였다

구현 방식이 꽤 깔끔합니다.

사전 학습된 Qwen3.5-2B 본체를 가져옵니다
텍스트 생성 헤드(LM head)를 제거합니다
대신 선택지별 점수를 계산하는 포인터 헤드(pointer head) 를 붙입니다
포인터 헤드는 각 선택지 위치의 은닉 상태를 <answer> 위치의 은닉 상태와 비교해 점수를 냅니다

포인터 헤드의 파라미터는 100만 개를 조금 넘는 수준이고, 본체는 rank-16 LoRA 어댑터로 미세 조정했습니다. 즉 거의 모든 능력은 기존 사전 학습 모델에서 가져오고, 아주 얇은 레이어만 새로 얹은 구조입니다.

참고로 이 구조는 두 번째 아키텍처입니다. 첫 버전에서 쓴 슬롯 헤드는 성능이 상당히 낮았다고 밝히고 있습니다.

공개 범위가 인상적입니다

코드: GitHub
가중치 및 최신 스냅샷: Hugging Face (공개 버전 v19)
학습 데이터 전체 + 학습 스크립트 전체

가중치만 던지는 '오픈 웨이트'가 아니라, 같은 모델을 처음부터 다시 만들거나 자기 도메인에 맞게 재학습할 수 있는 수준으로 공개했습니다.

성능: 정확도·보정·지연 시간

평가 축이 세 가지인 점이 눈여겨볼 만합니다.

| 기준 | 측정하는 것 | | --- | --- | | 정확도 | 질문에 얼마나 잘 답하는가 | | 보정(calibration) | 신뢰도 점수를 얼마나 믿을 수 있는가 | | 지연 시간 | 결정을 얼마나 빨리 내리는가 |

정확도는 JevBench 공개 세트로, 신뢰도 보정은 같은 세트의 Brier 점수로 평가했습니다. 결과는 2B급 33개 모델 중 3위이고, 20억 파라미터를 조금 넘는 모델들을 제외하면 30개 중 1위입니다.

지연 시간은 이렇습니다.

로컬 RTX 3090: 결정 지연 중앙값 약 115ms (측정 대상은 v18)
M3 MacBook: 작은 작업 기준 중앙값 약 153ms
작업 크기가 커지면 지연은 대략 선형으로 증가

개발팀은 특히 최소 지연 시간을 더 낮추는 개선을 검토 중이라고 합니다.

왜 하필 2B인가

이유가 솔직합니다. 이미 가진 하드웨어로 추론뿐 아니라 학습까지 시도할 수 있는 크기이기 때문입니다. 실험 사이클을 빠르고 저렴하게 돌릴 수 있는 규모면서, 의미 있는 작업은 충분히 해내는 지점이라는 판단이죠.

실제로 JevBench의 쉬운 작업은 100% 정답 처리했는데, 이 유형이 바로 에이전트가 일상적으로 마주치는 비교적 쉬운 판단들과 잘 겹칩니다.

활용처

모델 라우팅 — 이 요청을 어느 모델에 보낼까
도구 선택 — 어떤 툴을 호출할까
가드레일 / 정책 분류
평가(eval), 메모리, 컨텍스트 관리
게임 플레이, 작업 자동화, 미로 탐색

핵심 아이디어는 '하이브리드 에이전트'

어려운 결정은 LLM에게, 쉽고 반복적인 결정은 소형 의사결정 모델에게 맡겨 비용과 지연을 함께 줄이는 접근입니다. 의사결정 모델을 고정된 워크플로 언어와 결합하는 실험도 진행 중입니다.

실제로 써보기: CLI 예제

설치는 간단합니다.

pip install strands-decider

strands-decider CLI에 상태, 질문, 선택지를 넣어 실행합니다. 예제 모델 식별자는 StrandsAgents/strands-decider-2B-hobson-v19입니다.

"지급이 3일째 실패하고 있다"는 요청을 billing, sales, retail 중 어느 팀이 처리해야 하는지 물으면:

선택: billing
출력 신뢰도: 0.768
선택지별 확률: billing 0.845 / retail 0.091 / sales 0.064

선택 결과만 주는 게 아니라 확률 분포 전체를 볼 수 있다는 점이 중요합니다. "0.8 미만이면 사람에게 넘긴다" 같은 정책을 코드로 바로 작성할 수 있죠.

도구 호출 검증: 가장 설득력 있는 사례

저장소의 examples/strands/에 있는 예제가 이 모델의 가치를 잘 보여줍니다. 에이전트와 의사결정 모델은 로컬에서 실행되고, 에이전트의 기본 LLM은 Amazon Bedrock을 사용합니다.

문제 상황: 데모용 get_weather 도구와 적극적으로 행동하게 만든 시스템 프롬프트가 맞물려, 사용자가 도시를 말하지 않고 날씨를 물으면 에이전트가 도시를 임의로 추측해 도구를 호출하려 합니다.

해결: 도구 실행 전에 의사결정 모델이 대화 내용과 제안된 도구 호출을 읽고 두 가지 예/아니요 질문에 답합니다.

args_grounded — 모든 인자 값이 사용자가 실제로 제공한 사실에 근거하는가?
premature — 사용자에게 추가 확인을 받기 전에 호출하기엔 이른가?

몇 줄의 Python 코드가 이 예측을 행동으로 바꿔, 엉뚱한 도시의 날씨를 알려주는 대신 사용자에게 도시를 다시 묻게 만듭니다.

Strands 개입(Intervention) 시스템

이 검사를 끼워 넣는 방식도 깔끔합니다. InterventionHandler의 before_tool_call 메서드를 구현하고 Agent(interventions=[...])에 전달하면, 모든 도구 실행 전에 검사가 돌아갑니다.

핸들러는 타입이 지정된 행동을 반환합니다.

| 행동 | 의미 | | --- | --- | | Proceed | 실행을 진행 | | Deny | 실행을 거부 | | Confirm | 멈추고 사람에게 확인 요청 | | Guide | 그냥 차단하지 않고, 피드백과 함께 모델에 차례를 넘김 |

Guide가 특히 실용적입니다. 호출을 막기만 하면 에이전트가 왜 막혔는지 모르지만, 피드백과 함께 턴을 돌려주면 스스로 고칠 기회를 얻습니다.

핸들러는 내부 구현을 제한하지 않는 평범한 Python 클래스이므로, 의사결정 모델이든 Cedar 정책이든 다른 에이전트든 같은 형태로 연결할 수 있습니다. 모델 호출 전후, 전체 실행 전후에도 동등한 훅이 있습니다.

적용할 때 주의할 점

개발팀이 직접 밝힌 한계를 짚어둘 만합니다.

날씨 예제는 권장 정책이 아니라 시연입니다. 질문 문구, 임계값, 정책 모두 수작업으로 고른 값입니다. 그대로 복사해 프로덕션에 쓸 설계도가 아닙니다
복잡한 추론이 필요한 판단은 여전히 LLM의 몫입니다

다만 결정 비용이 워낙 낮다는 점이 판을 바꿉니다. LLM 호출을 끼워 넣기엔 너무 비싸고 느렸던 실행 경로에도 이런 검사를 배치할 수 있게 되니까요. 모든 도구 호출마다 LLM에 "이거 괜찮아?"를 물어볼 수는 없지만, 115ms짜리 로컬 모델이라면 가능합니다.

Strands 팀은 의사결정 모델 통합 라이브러리를 개발 중이며, 저장소에 후속 업데이트를 제공할 예정입니다.

마무리

Strands Decider 2B가 던지는 메시지는 "더 큰 모델"이 아니라 "알맞은 모델" 입니다. 에이전트 워크플로를 들여다보면 상당수의 LLM 호출이 사실은 예/아니요 판단이나 선택지 고르기에 지나지 않습니다. 그 자리에 115ms, 2B 모델을 놓으면 비용과 지연이 함께 내려가고, 보너스로 신뢰도 점수까지 얻습니다.

학습 데이터와 스크립트까지 전부 공개됐으니, 자기 도메인의 결정 작업으로 직접 파인튜닝해보는 것도 현실적인 선택지입니다. 에이전트 시스템의 비용 구조를 고민하고 있다면 한 번 살펴볼 만합니다.

원문: https://news.hada.io/topic?id=34934