요약
보틀캡AI가 Gemma-4-26B-A4B의 생각 길이를 평균 39% 줄이고도 정확도는 거의 그대로라고 밝혔습니다.
보틀캡AI는 추론 모델이 답하기 전에 쓰는 생각 토큰을 줄이는 ThinkingCap 시리즈를 만들어 왔습니다. 이번이 다섯 번째 모델이고, 구글 모델을 바탕으로 한 것은 처음입니다.
왜 중요한가
- 같은 답을 얻는 데 드는 토큰이 줄어 응답이 빨라지고 추론 비용도 낮아집니다.
- 원래 모델과 같은 샘플링 설정과 vLLM 환경을 그대로 쓰므로 모델 파일만 바꿔 끼우면 됩니다.
핵심 내용
- 12개 벤치마크에서 생각 토큰이 평균 38.9%, LongBench v2에서는 최대 69.1% 줄었습니다.
- 평균 정확도는 75.18%에서 75.03%로 0.15%p 낮아졌습니다.
- 회사는 이 차이가 대부분의 벤치마크에서 실행마다 생기는 편차보다 작다고 설명했습니다.
- 같은 생각을 맴도는 응답은 3.64%에서 0.76%로, 생각을 끝내지 못하고 잘린 응답은 4.35%에서 0.72%로 줄었습니다.
- 다만 긴 문서 추론 벤치마크인 AA-LCR에서는 정확도가 4%p 떨어졌고, 모든 수치는 회사 자체 평가 환경에서 나왔습니다.
HN 반응
- 같은 회사의 Qwen용 ThinkingCap을 써 본 이용자들은 실제 작업에서 원래 모델보다 덜 똑똑하고 검열도 심했다고 전했습니다.
- 반면 PR 리뷰처럼 비용 대부분이 생각 토큰인 작업에서는 점수를 조금 더 얻기보다 추론이 짧아지는 쪽이 낫다는 의견도 있었습니다.
오픈 웨이트 모델을 가져다가 자기들의 사소한 기여분 결과물을 꽁꽁 걸어 잠그는 이런 회사들이 정말 마음에 안 듭니다.
진짜 오픈 모델을 만든 쪽에서 라이선스를 고쳐서, 이런 관행이 과거의 일이 되게 해 주길 바랍니다.
"ThinkingCap PRO: 더 나은 효율을 원하십니까? 이 모델의 PRO 버전은 사고 토큰을 최대 87.6%, 평균 62% 적게 사용합니다. 더 빠른 답변, 더 낮은 대규모 추론 비용. [email protected]으로 문의하세요."
ㅋㅋ 옛날 방식이 다시 돌아왔네요. 소프트웨어가 성능을 옵션으로 파는 게 꼭 멀티코어 시대 초창기 같아요.
QWEN-3.8 27B용 Thinking cap과 Swift 모델을 써 봤는데, 제 경험으로는 덜 똑똑하고 덜 유능했습니다. 같은 작업에서 결과가 더 별로였어요. 아끼는 토큰 양을 생각하면 충분히 그럴 만한 가치가 있을 수도 있습니다. 하지만 저는 최고의 결과를 원해서 일부러 xhigh로 돌린 거였습니다. 이 모델은 써 보지 않았지만, 아마 비슷한 트레이드오프로 귀결될 것 같습니다. 이론상 벤치마크에서는 잘 나오지만, 실제로 내 작업에 쓰면 그만큼의 능력은 안 나온다는 거죠.
네, 저도 그것들은 별로였어요.
그래도 Gemma 4 26B는 일반적인 대화형 질문용으로는 꽤 괜찮은 모델입니다(흔한 코드 질문에도 그리 나쁘지 않아요. 에이전트형 코딩에는 그만큼은 아니지만요).
그러니 상황에 따라서는 이게 빠르고 좋은 모델이 될 수도 있겠네요. 한번 테스트해 볼까 합니다.
솔직히 저는 여전히 대체로 Muse Glimmer로 작업하는 게 더 좋아요. 서로 잘 맞거든요. 요즘은 Nemotron Bolt 74B/A9B MoE를 써 보고 있는데, 정말 꽤 괜찮을 수 있겠다 싶으면서도 Metal에서는 아직 느립니다.
아주 배타적인 클럽에 오신 걸 환영해요. 이제 회원이 두 명이에요! 나온 뒤로 계속 더 나은 모델을 찾아봤는데, 도저히 못 찾겠더라고요.
왜 더 낫다고 느끼는지 설명하기가 어렵습니다. 벤치마크나 컨텍스트 길이 같은 걸 보면 Qwen 3.8 27B보다 못한 게 맞고, 긴 컨텍스트 작업에서는 분명 그럴 겁니다.
하지만 오래된 제 M1 Max에서 시스템 프롬프트에 "Reasoning strength: low"를 넣고 쓰면 그냥 쓰기 좋습니다. 느리지 않고(덴스 모델인데도 실제로 해답에 도달하는 속도는 Qwen 3.6 35B MoE보다 빠릅니다), 글도 잘 쓰고, 그렇습니다.
그래서 지금은 개발자 친구이자 리서처로 쓰고 있습니다. 사실 제가 직접 배포까지 한 코드를 써 준 유일한 모델이기도 합니다! 메인 프로젝트가 독자적인 프레임워크에 묶여 있어서 보통은 제가 직접 짜지만, 다른 앱에 필요했던 플러그인은 어려움 없이 만들어 줬습니다.
하드웨어를 맞춰 볼까 생각해 본 첫 번째 로컬 LLM입니다.
그런데 Qwen 3.8 27b는 느려서 못 써 줄 정도예요. 사소한 걸 물어봐도 "생각해 볼게"만 10분씩 듣게 되잖아요.
Qwen 3.8 27B는 사고 수준이 기본값으로 "xhigh"(최대 단계)로 되어 있어서 끔찍하게 느립니다. "medium"이나 "low"로 설정하면 훨씬 빨라집니다.
맞습니다. low 설정에서는 꽤 괜찮아요. 저는 뭐랄까, 설명하기 힘든 편안함 때문에 Muse Glimmer가 더 좋습니다.
Qwen 3.8-27B를 low 추론 모드로 돌리려고 템플릿을 직접 손봐야 했는데, 지금은 고쳐졌는지 모르겠네요.
Nemotron 74B-9B는 써 보셨나요? (텐서 타입이 빠져 있어서 맥의 llama.cpp에서는 느립니다)
그 nemotron 모델은 완전 개판이에요. 다른 nemotron들이랑 똑같이요.
저는 범용적인 코드 개요 파악 같은 일에는 괜찮다고 봤습니다. 지금은 맥의 llama.cpp에서 너무 느려서 더 테스트해 볼 엄두가 안 나네요.
Fireworks Ember-1(사고를 줄인 Kimi K3)을 써 본 제 경험도 이렇습니다.
거의 매 세션마다 환각을 일으키고 작업을 끝냈다고 주장했습니다. 과도한 사고를 파인튜닝으로 없앤다는 이 개념은 전혀 신뢰가 안 가고, 득보다 실이 큰 것 같습니다. 결국 토큰 판매 업체들이 계속 범용화되면 우리는 신경 쓰지도 않게 될 겁니다.
작은 모델들이 파라미터 수준에서 하던 사고를 추론 시간으로 옮기고 있는 게 분명해 보입니다. 즉, 모델 안에서 계산을 못 하니까 토큰을 더 써서 계산한다는 거죠. 작업의 난이도에는 일종의 보존 법칙이 있어서, 계산을 모델 안에서 하든 모델을 반복 실행하는 루프에서 하든 둘 중 하나입니다.
그래서 작은 MoE 여러 개에서 보이는 어마어마한 tok/s가 쓸 만한 결과로는 절대 이어지지 않는 겁니다. Sonnet 5.5가 DeepSeek 4 Flash Vision보다 작업을 더 빨리 끝낼 수 있는 것도 그냥 답에 더 빨리 도달하기 때문입니다.
맞습니다. 그래서 저는 늘 같은 전력 소비 기준으로 실제 소요 시간을 비교해 왔습니다. 모델을 비교하는 가장 공정한 방법이라고 생각합니다.
맞아요. 출력 토큰 속도는 화려해 보이기만 하지 지표로서는 별로 쓸모가 없죠.
Muse Glimmer(덴스 30B)는 실제로 Qwen 3.6 35B-A3B보다 더 빨리 더 나은 답에 도달할 수 있어요.
그냥 단어 하나하나는 더 느려 보일 뿐이에요.
저는 thinkingcap Qwen 27B를 2주쯤 써 봤습니다. 기본 27B보다 확실히 멍청한 짓을 하지만 차이가 아주 크지는 않습니다. Swift 1.5는 눈에 띄게 멍청해서 하루 만에 그만 썼습니다. 이상하게도 결국 일반 27B로 돌아왔는데, thinkingcap 쪽이 눈에 띄게 검열이 심하기 때문입니다. 수위 있는 내용은 thinkingcap이 즉시 쳐내는 반면, 기본 27B는 계속 잘 따라옵니다.
PR 리뷰의 경우 비용은 대부분 사고 토큰에서 나옵니다. 제게 중요한 건 점수가 조금 더 높은 것보다, 같은 정확도에서 추론이 더 짧은 것입니다.
Byteshape의 Qwen 양자화 모델은 제 인문학 쪽 작업에서 놀랄 만큼 빠르고 결과물도 좋았습니다. 작은 모델이 체급을 훌쩍 뛰어넘는 성능을 내는 데다, 이 난리통의 초기에 이런 게 나왔다는 게 정말 놀랍습니다.
그리고 웃기기도 하죠. 참 살아 볼 만한 시대예요.
추론 엔진과 하니스의 다른 개선들 덕분에 초당 토큰 수가 합산 1.5배 이상 좋아졌어요. 그러니 자기 하드웨어에서 돌린다면 토큰이 적게 필요한 게 아니라 출력이 빨리 끝나기만 하면 되는 거죠.