UkisAI Swift-Qwen3.8-27B / 사고 토큰 58.3% 감소, xhigh 정확도 유지하며 속도 1.95배 향상

1. 양자화된 Qwen 3.8 27B 인스턴스를 돌리는데, 자꾸 튀어나오는 추론 루프(아래 논문에서는 'overthinking errors'라고 부름) 때문에 진짜 짜증 나더라고. 이 루프가 medium이나 low 추론 설정에서도 계속 나타나는 거야.

2. Meta 논문 중에 PTQ에서 이 현상을 잡는다는 게 있어서 써봤는데, 그냥 그대로 쓰기엔 결과가 영 별로였어.

3. 그래서 키워드를 제대로 잡고 파라미터를 튜닝하면 되지 않을까 싶어서, 8xH100 박스 돌려가지고 엄청나게 많은 (당연히 out of distribution인) 도메인(코딩, 언어, 비전, 에이전트 등) 트레이스를 뽑아냈지.

4. 그중에서 '과도한 생각'이 들어간 것들만 골라내서 공통으로 들어가는 토큰들을 찾았고, 제일 눈에 띄는 놈들을 타겟으로 잡았어.

5. 논문에 나온 대로 추론 중에 해당 토큰들에 페널티를 주는 방식을 구현해 봤어. 트레이스를 생성하고 그 위에서 cross-entropy SFT를 돌려보려고 했지.

6. 처음엔 아예 안 먹혔는데, 페널티 주는 방식 자체가 논문에 나온 토큰들보다 훨씬 잘 작동하더라고. 저정밀도 모델뿐만 아니라 bf16에서도 말이야. 그래서 계속 실험을 이어갔지. 우리가 찾은 토큰들로 손실 함수를 만들고, 아까 뽑아둔 트레이스들로 LoRa SFT를 돌려봤어. 추론 능력이 확 떨어지는 것 같았는데, 정확도는 의외로 잘 따라오더라고. 추론 감소 효과가 일반화되는 느낌이었어.

7. (Qwen 3.8 27B 나오자마자 시작해서) 진짜 엄청나게 삽질한 끝에 추론 감소 결과가 만족스러워졌어. 그다음엔 정확도를 복구할 방법을 찾았지. RL(GSPO), On-Policy Distillation, ThinkingCap 3.6 27B 어댑터 청크 활용 등등 별짓을 다 해봤고, 결국 정확도 손실을 1% 미만으로 잡는 데 성공했어. 우리 내부 OOD 테스트 거의 전부에서 말이야.

8. 그 다음엔 여러 추론 강도와 정밀도 변형 등을 아우르는 빡센 벤치마크를 돌려봤음. 몇 가지 문제가 있었는데, 그중 하나가 신뢰할 만한 점수를 뽑으려면 각 벤치마크를 10번씩 돌려야 한다는 거였음(베이스 모델 5번 + 우리 어댑터 5번, 이건 Terminal Bench의 Qwen 3.6 27B 모델 카드에 나온 표준 절차를 그대로 따른 거임). 돌려보니까 GPQA, MMLU, Terminal Bench 2.1, LiveCodeBench v6, ERQA, C-Eval, IFBench, HMMT25 전반에서 토큰이 40~60% 줄어들면서도 정확도 손실은 1% 미만으로 수렴하더라. 딱 하나 AIME26에서 4.6% 정확도 손실이 났는데, 이건 나중에 확인해보니 수학 관련 추론에 중요한 특정 토큰에 페널티가 들어가는 학습 버그 때문이었음. 이건 다음 업데이트 때 고칠 예정임.

벤치마크 결과: (벤치마크 원본 파일은 여기 - https://github.com/UkisAI/Swift-Qwen3.8-27B-evals/ )

Swift-27B vs Qwen3.8-27B (BF16, 모든 벤치마크 5회 반복, thinking effort xhigh 기준)

토큰 절감 효과는 모든 추론 강도에서 유지됨 (평균 사고 토큰 감소율): xhigh 41%, medium 23%, low 26% (다만 medium에서 1~4%, low에서 1~2% 정도 정확도 손실이 있어서 추가 테스트가 좀 더 필요함)

GPQA-Diamond에서 Swift xhigh vs 베이스 모델 자체 추론 설정 비교 (198문제 x 5 시드):

결론적으로 Swift는 토큰을 절반도 안 쓰면서 xhigh 정확도를 유지하고, 베이스 모델 medium 설정보다 토큰은 1.6배 정도 쓰면서 정확도는 4%p 더 높게 나옴.

마치는 글:

우리가 완전 오픈 소스를 지향하긴 하지만, 이제 막 시작한 연구소라 학습 데이터랑 방법론 일부는 비공개로 둘 수밖에 없음. 라이선스가 Apache 2.0은 아니지만, 매출 100만 달러 넘는 기업들한테만 적용되는 거라 일반적인 커뮤니티 활동에는 문제없을 거임. 혹시라도 이게 커뮤니티에 걸림돌이 될까 걱정되긴 하는데, 피드백 주면 적극적으로 검토하겠음.

우리는 커뮤니티에 최대한 기여하고 싶고, 우리 작업물이나 양자화, Swift 모델 요청 같은 거에 피드백 주면 진짜 큰 힘이 될 것 같음. 참고로 지금 Swift 3.8 Flash Next 작업 중인데, xhigh 정확도를 유지하면서 사고 토큰 사용량을 벌써 30%까지 줄여놨음. 이건 우리 방법론이 Qwen 모델 계열 전체에서 먹힌다는 강력한 증거라고 봄. 여유 생기는 대로 다른 모델 계열도 건드려 볼 생각인데, 커뮤니티에서 어떤 모델을 먼저 최적화해주길 원하는지 알려주면 좋겠음.

일단 테스트용 API를 제공해 주는 거 자체가 아주 좋음. 모델을 직접 다운로드하거나 퀀타이징하기 전에 써봤는데, 덕분에 모델이 쓰레기가 아니라는 걸 바로 알 수 있었음.

공유할 만한 대단한 결과물은 딱히 없음. 난 LLM을 코딩 어시스턴트보다는 에이전트 용도로 주로 쓰거든. 문제 해결, 이슈 찾기, 결과가 명확한 제한적 작업 수행 같은 거엔 아주 뛰어남.

지금 Swift로 Deepseek V4 Flash의 ROCM 구현을 자율적으로 수정하는 중임...

Q_8이랑 f16 컨텍스트요. 아까 말했듯이 아주 제한적인 테스트였고, 한 번 돌리는 데 한 시간까지 걸려서 시간 날 때 몇 번 더 해볼 생각입니다.