ThinkingCap Qwen3.8-27B 공개 — 추론 토큰 평균 37% 절감

AI 요약

BottleCap AI가 ThinkingCap 시리즈 두 번째 모델인 ThinkingCap Qwen3.8-27B를 공개했습니다. 목표는 어려운 문제와 에이전트 작업에서 Qwen3.8-27B의 성능을 유지하면서 답변을 만들 때 쓰는 추론 토큰을 줄이는 것입니다. 모델 제작자 측 평가에서 평균 추론 토큰 수는 15,735개에서 12,144개로 37.2% 줄었고, 평균 정확도는 86.6에서 85.8로 0.8포인트 낮아졌습니다. 벤치마크에 따라 토큰 감소 폭은 10.7~65.5%입니다.

벤치마크 결과

지식·추론 영역에서는 GPQA-Diamond의 추론 토큰이 43.1%, MMLU-Pro가 57.3%, MMMLU가 65.5% 감소했습니다. 정확도는 각각 89.93에서 88.04, 85.54에서 84.67, 85.38에서 84.09로 내려갔습니다. 수학·코드에서는 AIME 2026 토큰이 30.2% 줄고 정확도는 98.13에서 94.27로 낮아졌습니다. LiveCodeBench v6에서는 토큰이 20.3% 줄었으며 정확도는 91.14에서 91.21로 소폭 올랐습니다.

긴 문맥 검색 벤치마크 AA-LCR에서는 토큰 사용량이 38.6% 줄었고 정확도는 81.75에서 84.00으로 2.25포인트 상승했습니다. 지시 수행 IFBench에서는 토큰이 46.4% 줄었지만 정확도는 79.75에서 79.71로 거의 같았습니다. 에이전트 작업인 τ²-bench는 토큰이 30.9% 줄고 정확도는 76.16에서 75.15로 낮아졌습니다. 긴 추론이 필요한 Terminal-Bench 2.1에서는 감소 폭이 10.7%로 가장 작았습니다.

추론 강도와 서빙

제작자는 정확도와 토큰 사용량의 균형을 위해 xhigh 추론 강도를 권장합니다. medium과 low도 지원하며, 낮은 강도에서는 원래 설정의 정확도와 토큰 사용량 사이 절충이 더 크게 드러난다고 설명합니다. Hugging Face Transformers로 불러올 수 있고, vLLM과 SGLang에서는 Qwen 계열 reasoning parser와 도구 호출 parser를 지정해 서빙합니다. 도구 호출은 XML 형식 출력을 구조화된 tool_calls로 변환합니다.

모델에 포함된 MTP(다중 토큰 예측) 헤드를 이용하면 별도 초안 모델 없이 자기 추측 디코딩을 적용할 수 있습니다. 제작자 측 vLLM 0.29.0 평가에서는 초안 토큰 3개 설정으로 제안된 토큰의 53%가 채택됐습니다. 디코딩 단계당 약 2.6개 토큰으로, 기반 모델의 54%·2.6개와 비슷한 결과입니다. 제작자는 MTP 추측 디코딩이 손실 없는 방식이라 표준 디코딩과 출력이 같다고 설명합니다.

양자화 모델과 이용 조건

BF16 외에도 FP8, GGUF, NVFP4, NVFP4 W4A4 변형을 제공합니다. FP8 모델은 31GB이며 Hopper와 Blackwell을 대상으로 합니다. GGUF는 IQ4_XS부터 F16까지 16~55GB로, llama.cpp·LM Studio·Ollama와 CUDA·Apple Metal·Vulkan·CPU 환경을 지원합니다. NVFP4 모델은 21GB이며 Hopper와 Blackwell에서 사용할 수 있고, NVFP4 W4A4는 23GB로 Blackwell 전용입니다.

모델 파일을 받으려면 저장소 접근 조건에 동의하고 접근을 요청해야 합니다. 라이선스는 PolyForm Small Business 1.0.0과 BottleCap의 개인 사용 허가를 결합했으며, 상업적 이용은 BottleCap AI에 문의하도록 안내합니다. 기반 Qwen 자료에는 Apache-2.0이 적용됩니다.

Reddit 반응

• @u/igotanewaccount — 기본 Qwen3.8 27B에서도 추론 수준을 조절할 수 있습니다. medium이면 토큰 사용량이 크게 줄어듭니다.
  • @u/newtonapple — 제가 여러 문제로 시험해 본 결과, 기본 모델은 low에서도 여전히 생각을 너무 많이 합니다.
  • @u/FullstackSensei — 어떤 양자화 모델을 쓰고 있나요?
  • @u/newtonapple — DGX Spark에서 NVFP4를 사용합니다.
  • @u/FullstackSensei — 이 작은 모델에서는 8비트보다 낮은 비트 수가 성능을 떨어뜨립니다. NVFP4는 이전 4비트 양자화보다 낫지만 마법은 아닙니다. 과도한 생각이나 사고 루프는 QwQ 때부터 계속 나온 얘기입니다. 4비트 모델을 쓰는 사람들은 사고 문제를 말했고, 8비트 모델을 쓰는 우리는 그런 문제를 겪지 않았습니다. 4비트가 특히 Spark처럼 메모리 대역폭이 제한된 장치에서 빠르다는 건 압니다. 하지만 작업이 잘 안 되거나 모델과 씨름한다면 초당 토큰을 더 얻어도 소용이 없습니다.
  • @u/newtonapple — 제 사용 사례에서는 잘 작동합니다. 주로 여러 저장소에 걸친 코딩 작업입니다. Hermes 안에서도 사용해 봤습니다. 프로덕션 로그와 Prometheus 지표를 보고 실제 운영 문제를 디버깅하는 일도 잘합니다. 덧붙이면 NVFP4에서 덜 생각하는 SwiftQwen을 말한 겁니다. ThinkingCap도 써 보려고 합니다.
  • @u/FullstackSensei — “내 컴퓨터에서는 돼요”라는 밈을 아시죠? 코딩 작업이라고 다 같은 난이도는 아닙니다. 여러 파일이나 저장소를 다룬다는 사실만으로 작업의 복잡성이 드러나지는 않습니다. 이 모델이나 Qwen 27B를 비난하는 건 아닙니다. Qwen은 3.5부터 좋아했고 3.8도 정말 좋습니다. 하지만 생각을 너무 많이 한다고 불평하는 사람은 늘 4비트 양자화 모델을 쓰는 경우였습니다. 속도와 지능을 맞바꾸는 셈입니다. 작업을 끝냈다는 사실만으로 잘했다는 뜻은 아닙니다. 더 어려운 작업의 결과를 나란히 놓고 실제 코드를 읽어 봐야 합니다.
  • @u/newtonapple — 코드 품질에서 양자화가 어떤 영향을 주는지는 잘 압니다. 모델과 양자화별로 직접 쓰는 벤치마크도 있습니다. 제가 잘된다고 한 건 제가 작성한 코드뿐 아니라 팀원들이 검토한 코드에서도 잘됐다는 뜻입니다. 대충 만들어서 배포하지 않습니다. Qwen 27B가 모든 최상위 모델을 대체한다고 말하는 것도 아닙니다. 문제마다 절충점이 있습니다. 과도한 생각은 양자화 비트를 높인다고 해결될 것 같지도 않습니다. 제가 다른 글에 링크한 GitHub 이슈를 보셔도 됩니다.
  • @u/Gary_Spivey — Qwen3.8에서 low가 medium보다 더 오래 생각하는 문제는 알려진 버그입니다.
• @u/r16051studio — [BottleCap AI 모델 접근 요청] 아, 안 돼요.
  • @u/Wandering_By_ — “남의 작업을 조금 가져다 썼으니, 원작자가 요구하지 않은 개인정보쯤은 받을 자격이 있겠죠?”
  • @u/Sudden_Topic5154 — 아무거나 입력해도 됩니다. 저는 욕설을 썼는데 통과됐습니다.
  • @u/MasterNomie — 고맙습니다. 저도 그렇게 했습니다. 개인 이메일을 알려줄 필요는 없네요.
• @u/returnity — 이 모델을 시험해 보고, 이미 자세히 올린 Swift와 성능·효율을 비교한 전체 보고서를 올리겠습니다.
  • @u/Kodix — 꼭 부탁합니다. 기대하고 있겠습니다.
• @u/AreaFifty1 — 지능이 떨어지는 대가를 치르면서 추론 토큰을 줄이는 이유를 모르겠습니다. 벤치마크 전체에서 0.8%를 잃습니다. 긴 코딩 세션에서는 그 정도도 뉘앙스나 문맥 이탈에 충분히 영향을 줄 수 있습니다.
  • @u/Aubrey_D_Graham — 추론을 줄이면 전체 문맥과 비용이 줄고, 토큰당 주의가 높아지며, 문맥 오염도 줄어듭니다.
  • @u/droptableadventures — 어떤 때는 턴마다 10,000개 토큰을 생성하지 않아도 되는 대가로 0.8%를 잃어도 괜찮습니다. 그중 절반은 “잠깐”이나 “하지만” 같은 말입니다. 같은 시간에 문제를 여러 번 시도하고 결과를 시험할 수 있다면 그 손실을 만회할 때도 많습니다.
  • @u/1Poochh — 속도도 고려해야 할 요소입니다.
  • @u/Independent-Fly730 — 사용 사례에 따라 다릅니다. 코딩이라면 필요한 만큼 추론하길 바라겠지만, 음성 에이전트나 고객용 챗봇이라면 지연 시간과 균형을 맞춰야 합니다.
  • @u/newtonapple — 기본 Qwen3.8 모델은 생각을 너무 많이 합니다. 개인 작업에서 두 모델을 모두 시험해 봤습니다. 제게는 추론을 줄인 모델이 훨씬 잘 맞습니다. 간단한 작업도 기본 모델은 끝내는 데 한 시간 넘게 걸릴 수 있습니다. 실제 업무에는 쓸 수 없습니다. 덜 생각하는 모델은 사고 루프에 빠지지 않아서 똑같이 잘하거나 더 잘합니다.
  • @u/AreaFifty1 — 사고 루프는 가중치를 심하게 반올림한 양자화 모델에서 생깁니다. 즉, 기본 정밀도로 올리면 해결됩니다.
  • @u/newtonapple — 과도한 생각 때문에 이 문제를 꽤 자주 겪었습니다. [QwenLM GitHub 이슈](https://github.com/QwenLM/Qwen3.8/issues/216)를 보시면 양자화 문제만은 아닌 것 같습니다. 실제로는 덜 생각하는 모델의 NVFP4가 가장 쓸 만한 결과를 줬습니다.

원문: Hugging Face / 번역·요약: Trawling