Strands Decider 2B 공개 — 빠른 판단을 위한 소형 오픈소스 모델

AI 요약

Strands 팀이 공개한 Strands Decider 2B는 일반적인 대화형 언어 모델(LLM)처럼 자유롭게 문장을 생성하지 않습니다. 주어진 선택지에서 답을 고르거나 점수를 매기는 ‘결정 모델(decision model)’입니다. 예를 들어 문장이 특정 기기와 관련 있는지 예·아니요로 판단하거나, 감정이 긍정적인지 0~1 사이 점수를 매깁니다. 선택지가 정해져 있어 항상 그중 하나를 답하고, 같은 크기의 LLM보다 빠르고 지연 시간이 짧다는 점이 장점입니다. 대신 복잡한 추론을 잘하지 못하며, 코딩·챗봇·문서 요약처럼 자유로운 텍스트 생성이 필요한 작업에는 맞지 않습니다.

에이전트의 판단 단계를 맡는 모델

결정 모델은 답변과 함께 신뢰도 점수를 냅니다. Strands 팀은 이 점수를 활용해 특정 판단을 얼마나 믿을지 평가할 수 있다고 설명합니다. 같은 입력에 여러 질문을 던지는 작업도 효율적입니다. 따라서 모델 라우팅, 도구 선택, 평가, 가드레일, 메모리, 컨텍스트 관리, 정책 분류처럼 에이전트가 반복해서 해야 하는 간단한 판단에 적합합니다.

팀은 LLM이 어려운 판단을 맡고 결정 모델이 단순하고 반복적인 판단을 처리하는 하이브리드 에이전트도 활용 사례로 들었습니다. 이 방식으로 비용과 지연 시간을 줄이는 실험이 진행되고 있으며, 고정된 워크플로 언어와 결정 모델을 결합하는 접근도 언급했습니다.

구조: 생성 헤드를 포인터 헤드로 교체

기반 모델은 사전 학습된 Qwen3.5-2B입니다. Strands 팀은 텍스트 생성을 담당하는 언어 모델 헤드(LM head)를 제거하고, 선택지에 점수를 매기는 포인터 헤드(pointer head)를 붙였습니다. 포인터 헤드는 각 선택지 위치의 은닉 상태(hidden state)를 <answer> 위치의 은닉 상태와 비교해 점수를 계산합니다. 이 헤드는 전체 파라미터가 100만 개를 조금 넘는 크기이며, 기반 모델 몸체는 rank-16 LoRA 어댑터로 미세 조정했습니다.

공개 모델은 아키텍처의 19번째 버전입니다. 초기 버전은 비슷한 구조에 슬롯 헤드(slot head)를 사용했지만 성능이 더 낮았다고 합니다. 각 버전에서 바꾼 점은 저장소에 기록했습니다. 코드뿐 아니라 학습 데이터와 학습 스크립트도 공개해, 다른 개발자가 모델을 직접 실험하고 학습할 수 있도록 했습니다.

정확도·보정·지연 시간

팀은 결정 모델을 정확도, 보정(calibration), 지연 시간 세 기준으로 평가했습니다. 정확도와 보정은 JevBench 공개 데이터셋에서 측정했습니다. 보정에는 브라이어 점수(Brier score)를 사용했습니다. Strands Decider 2B는 2B급 모델 33개 가운데 종합 3위였고, 2B를 약간 넘는 모델을 제외하면 30개 중 1위였다고 밝혔습니다. JevBench의 쉬운 과제는 100% 정확히 처리했다고도 설명했습니다.

지연 시간은 작업 크기에 따라 대략 선형으로 늘어납니다. RTX 3090에서 측정한 결과, 로컬 판단의 중앙값은 약 115ms였습니다. M3 MacBook에서는 작은 작업 기준 중앙값이 약 153ms로, 팀은 크게 뒤처지지 않는다고 설명했습니다. 다만 이 수치는 GPU 환경과 작은 작업을 기준으로 한 결과입니다. 커뮤니티에서는 M3 Mac에서 CPU만 사용하고 Docker 컨테이너로 실행했을 때 한 판단에 약 1.7초가 걸렸다는 사례도 나왔습니다. 다른 사용자는 6코어에서 약 0.5초를 보고했습니다. 실행 환경과 최적화에 따라 체감 속도가 달라질 수 있음을 보여줍니다.

Strands 에이전트에서 도구 호출 검증하기

본문은 모델을 Strands 에이전트의 도구 호출 개입(intervention) 기능에 붙이는 예제를 소개합니다. 예제 에이전트는 사용자가 지역을 말하지 않았는데도 날씨 도구를 호출하도록 일부러 성급하게 설정했습니다. 도구가 실행되기 전에 Decider가 대화 내용과 제안된 호출을 읽고 두 가지를 확인합니다. 도구 인자가 사용자가 실제로 말한 내용에 근거하는지, 그리고 지금 도구를 호출하기에 이른 시점은 아닌지 판단합니다. 사용자가 도시를 말하지 않았다면 에이전트가 임의의 지역 날씨를 답하는 대신 어느 도시인지 되묻게 됩니다.

Strands의 InterventionHandler는 before_tool_call 메서드에서 도구 실행 직전 개입합니다. 핸들러는 진행(Proceed), 거부(Deny), 사용자 확인 요청(Confirm), 피드백을 돌려 모델이 다시 답하도록 하는 안내(Guide) 가운데 하나를 반환합니다. 이 구조는 특정 모델에 종속되지 않습니다. 결정 모델뿐 아니라 Cedar 정책이나 다른 에이전트도 같은 자리에 연결할 수 있습니다. 예제의 질문, 임계값, 정책은 직접 정한 값이며, 팀은 이를 권장 설정이 아니라 저렴한 판단 모델을 에이전트 실행 경로에 넣는 사례로 제시했습니다.

커뮤니티 반응

• @miguelspizza — 훌륭한 모델입니다. Chrome 확장 프로그램에서 기기 내 실행으로 이메일 같은 항목을 필터링하고 있습니다. 크기, 성능, 속도가 잘 맞아 필요할 때 대량 분류하는 데 유용합니다. 브라우저에서 실행하려는 분을 위해 WebGPU 버전도 있습니다.
  • @babelfish — 실시간 데모입니다.
• @keyle — 설명이 정말 훌륭합니다. AI 전문가들이 무슨 말을 하는지 이해하기 어려울 때가 많은데, 사람이 사람을 위해 쓴 글은 드뭅니다. 기술적으로는 여러 용도에 쓸 수 있는데, 어떤 아이디어가 있는지 다른 사람들 의견도 듣고 싶습니다.
  • @nryoo — 점심 메뉴 고르기요?
  • @mattstir — 전구를 제어하고 주방 스피커에서 음악을 재생하는 간단한 홈 어시스턴트 앱을 생각하고 있습니다. “조명을 30% 밝기로 설정해” 같은 명령과 “오늘 날씨가 어때?” 같은 일반 질문을 구분해, 후자는 저렴한 LLM에 보내면 됩니다. 전부 LLM으로 처리할 수도 있지만 결정 모델은 빠르다는 점이 마음에 듭니다.
• @davvie — 좋아 보입니다. Mac mini에서 간단한 자동화 작업에 쓸 수 있을 것 같습니다.
• @teruakohatu — CPU에서 얼마나 잘 실행되나요?
  • @gopalv — M3 Mac에서 CPU만 사용하는 Docker 컨테이너로 돌려 봤는데 괜찮았습니다. 86개 입력 토큰을 처리하는 판단에 1,732ms가 걸렸습니다. 실행 방법도 공유했습니다. Docker 래퍼 대신 MLX에 맞춰 최적화하면 Mac mini에서 더 나아질 여지가 많습니다.
  • @avereveard — 6코어에서 판단 하나에 약 0.5초입니다.
  • @davidwritesbugs — 이런 모델치고는 느린 것 아닌가요?
• @soltanov — 벤치마크에서 보정이 잘됐다고 해서 낯선 실제 운영 입력에서도 믿을 만하다는 뜻은 아닙니다.
• @SubiculumCode — 멀티모달 모델도 있나요? 보정된 확률로 “이 도형들이 서로 맞나요?” 같은 질문을 해 보고 싶습니다. LLM에 물어볼 수도 있겠지만요.
  • @necubi — Cloudflare의 Clef는 멀티모달입니다. 참고로 저는 Cloudflare에서 일하지만 모델 팀 소속은 아닙니다.
  • @sauhsoj — Strands Decider도 이미지를 입력받을 수 있습니다. 그 질문에는 어떤가요?
  • @Zopieux — 제품 페이지에는 그런 내용이 없습니다. 지어낸 것 아닌가요? OCR만이 아니라 이미지 분류·분석을 하는 결정 모델은 아직 부족하다고 봅니다. Cloudflare의 Clef는 제 테스트에서 괜찮았지만 더 크고 느렸습니다. Strands는 어떤지 궁금합니다.
• @stephantul — 2B를 작다고 부르는 걸 보니 시대가 달라졌네요.
• @mattvr — 왜 이진 선택을 다들 noul이라고 부르나요? 무슨 뜻이 있나요, 아니면 Jev API를 그대로 따라 한 건가요?
  • @haarts — 베르누이(Bernoulli)에서 왔습니다.
  • @jtfrench — 흥미롭네요. 베르누이가 만든 단위인가요, 아니면 성을 따온 이름이 굳어진 건가요?
  • @mijoharas — 베르누이 사상(Bernoulli maps)에서 왔다고 합니다. 그래도 왜 그런지는 모르겠습니다.
  • @henrymerrilees — 문장이 헷갈리게 쓰였네요. “maps to”에서 maps는 동사로 쓰인 것 같습니다. 베르누이 분포를 뜻하는 Bernoulli에서 줄인 “noul”이 if 문으로 대응된다는 의미라고 이해했습니다.
  • @WASDx — 새 OpenAI Decisions API는 이를 “predicate”라고 부릅니다. API 이름도 “system one” 대신 “decisions”입니다. 새 용어를 만드는 걸 보통 좋아하지 않지만, OpenAI 스키마가 자리 잡았으면 합니다. 이런 유행어가 더 필요하지는 않습니다.
  • @dprkh — Claude가 만들었고 그대로 굳어졌습니다.
  • @tchalla — 다들 System One thinking이라고 부르는 것과 같은 이유입니다. 남들과 다르게 보이고 똑똑해 보이고 싶어 하니까요.
  • @hiimkeks — 제 추측으로는 “nool”이라고 발음하면 “bool”과 비슷하고, 모델이 베르누이 분포를 생성하기 때문에 Bernoulli의 일부를 딴 것 같습니다.
• @hrpnk — Cloudflare Clef는 llama.cpp에서 실행됩니다. Strands CLI에 종속되면 도입이 번거로워지고 확산도 늦어질 수 있습니다. Qwen 기반 LoRA이니 llama.cpp에서도 돌릴 수 있을 것 같은데, PEFT/LoRA를 GGUF로 변환하는 일을 사용자가 직접 해야 한다니 아쉽습니다. convert_lora_to_gguf.py를 실행했더니 layers.0.linear_attn.in_proj_a.weight 텐서 이름을 매핑할 수 없다는 오류가 났습니다.
• @real_faxenoff — 여러 전문 소형 모델을 써 본 사용자로서 말하자면, PC CPU에서 이런 모델이나 Jev 계열을 계속 실행하면 만족스럽지 않을 겁니다. NPU로 처리를 넘겨야 합니다. 시행착오가 많지만 결과는 그만한 가치가 있습니다. NPU 성능은 두 배, 전력 소비는 4분의 1이 되고 팬 소음도 없습니다. 이런 모델 경쟁의 첫 단계가 끝날 때까지 한 달 정도 기다렸다가 NPU/iGPU용 솔루션을 만들어 Hugging Face에 올리겠습니다.
• @woadwarrior01 — 약 2주 전에 나온 Intern-Decision 모델군에도 0.8B, 2B, 4B 모델이 있습니다. Qwen3.5 기반 모델 계열을 쓰고 포인터 헤드 구조도 같습니다. 다만 instruction-tuned 모델입니다.
• @mynti — 아키텍처를 좀 더 자세히 설명해 주실 수 있나요? 포인터 헤드가 각 선택지의 은닉 상태와 답 위치의 은닉 상태를 비교한다고 했는데, LLM은 토큰마다 은닉 상태를 만듭니다. 선택지가 여러 토큰으로 나뉘면 어떻게 처리하나요?
• @girvo — 이런 결정 모델을 원하는 질문 형태에 맞춰 미세 조정하는 게 범용 모델보다 나을까요? 직장에서 Jev를 꽤 잘 쓰고 있는데, 어떤 선택지가 있는지 궁금합니다.
  • @weinzierl — 저도 궁금합니다. 라벨이 붙은 데이터가 충분하고 그 데이터에 맞춰 판단을 보정해야 한다면, 1) 유행은 무시하고 전통적인 분류기를 학습할지, 2) LLM 기반 결정 모델을 미세 조정할지, 3) LLM 분류기의 컨텍스트에 데이터 일부를 넣을지 궁금합니다. 3번이라면 데이터를 입력 본문, 요청 전체 상태, 질문 지시문, 기준 중 어디에 넣어야 하나요? 데이터를 얼마나 써야 하나요?
  • @gxcsoccer — Jev는 오픈 모델 미세 조정에 흥미로운 방법을 보여준다고 생각합니다. 기존 모델을 대체하는 게 목표가 아니라, 특정 분야의 예·아니요와 객관식 질문을 빠르게 처리하도록 학습해 전체 시스템을 더 빠르고 나은 결과로 만드는 것입니다.
• @Ujj-001 — 이제 Jev는 누구나 쉽게 쓸 수 있는 상품이 된 건가요?
• @kimseungyong — 이 오픈소스 모델을 기다렸습니다. 개발 에이전트가 모델을 선택하고 실행해 토큰 효율을 높이도록 해야겠습니다. 요즘 이렇게 많이 쓰이고 있나요?

원문: Strands / 번역·요약: Trawling