AWS strands-labs가 2B 결정 모델 Strands Decider 2B 공개, Jev 잇는 결정 모델 대열에 합류

크롬 확장에서 온디바이스로 돌려서 이메일 필터링에 쓰고 있음. 크기랑 성능, 속도가 딱 맞아서 아무 대량 분류 작업에나 갖다 쓸 수 있더라. WebGPU 버전도 HF에 올라와 있음.

설명이 진짜 잘 쓰여 있음. AI 하는 사람들 얘기가 무슨 소린지 몰랐던 내가 읽어도 이해가 됐어. 활용 아이디어 있으면 좀 알려줘.

스마트홈 제어 앱에 쓰려고 생각 중임. "조명 30%로 맞춰줘" 같은 명령이랑 "오늘 날씨 어때" 같은 질문을 구분해서 후자는 값싼 LLM으로 넘기는 식. LLM 하나로 다 돼도 이런 결정 모델이 훨씬 빠르더라.

CPU에서 얼마나 돌아가는지 궁금함. M3 맥에서 도커로 CPU만 써서 돌려봤는데 결정 하나에 1.7초 나왔음. 6코어에서는 결정당 0.5초 정도. MLX로 최적화하면 맥미니에서 훨씬 나아질 텐데.

벤치마크 보정이 낯선 프로덕션 입력에서의 신뢰성을 보장하진 않음.

이런 모델 중에 멀티모달 되는 게 있음? "이 도형들 같은 모양이야?" 같은 질문을 확률까지 받아서 물어보고 싶음. Cloudflare clef가 멀티모달이고, Strands Decider도 비전 입력은 받음.

2B를 두고 작다고 하는 게 지금이 어떤 시대인지 보여줌.

왜 다들 이진 선택을 noul이라고 부름? Bernoulli에서 온 거고 bool처럼 "눌"로 읽으라고 만든 이름 같음. OpenAI Decisions API는 이걸 predicate라고 부르더라. 새 표준 만들지 말고 OpenAI 스키마가 먹혔으면 좋겠음.

strands cli에 묶이는 건 아쉬움. clef는 llama.cpp에서 돌아가는데 이건 Qwen에 LoRA라서 llama.cpp로 돌아갈 텐데, PEFT/LoRA를 GGUF로 바꾸는 건 사용자 몫으로 남겨놨음. 나는 tensor 매핑 에러에서 막혔음.

이런 소형 모델 여러 개를 CPU 백그라운드로 계속 돌리면 만족 못 함. NPU로 넘겨야 되는데 성능 2배에 전력은 4분의 1로 줄고 팬 소음도 사라짐. 한 달 뒤에 이런 모델들 대결 구도가 정리되면 NPU/iGPU용 솔루션을 HF에 올릴 예정.

2주쯤 된 Intern-Decision 패밀리(0.8B, 2B, 4B)도 같은 Qwen3.5 베이스에 포인터 헤드 구조를 씀.

포인터 헤드가 각 옵션의 히든 스테이트를 정답 히든 스테이트와 비교해 점수를 낸다는데, LLM은 토큰마다 히든 스테이트를 내니까 옵션이 여러 토큰에 걸치면 어떻게 되는지 궁금함.

레이블 데이터가 충분하면 그냥 전통적인 분류기를 학습시키는 게 나은지, 결정 모델을 파인튜닝하는 게 나은지 모르겠음. 데이터를 컨텍스트에 밀어넣는 선택지도 있는데 그럼 데이터를 어디에 넣어야 함?

Jev는 이제 commoditized 된 거임?