알리바바 Qwen 계열의 새 모델 Qwen3.8-2.4T-A95B가 허깅페이스에 공개됐다. 배포 문서에 따르면 이 저장소는 사후 학습(post-trained)을 마친 모델의 가중치와 설정 파일을 트랜스포머스(Transformers) 형식으로 담고 있으며, vLLM·SGLang·TokenSpeed 같은 서빙 엔진과 호환된다. 주목할 대목은 Qwen 측이 이번 모델을 두고 "처음으로 Qwen-Max 급 모델을 오픈 공개한 사례"라고 표현한 점이다. 그동안 상용 API로만 접근할 수 있던 최상위 체급의 모델이 자체 인프라에서 구동 가능한 형태로 풀렸다는 의미다.
모델 이름 자체가 구조를 짐작하게 한다. '2.4T-A95B'는 Qwen이 써 온 MoE(전문가 혼합) 명명 방식으로, 전체 파라미터 규모와 실제 추론 시 활성화되는 파라미터를 구분해 표기한다. 즉 총 규모는 매우 크되 요청마다 일부 전문가만 활성화해 연산 비용을 억제하는 구조다. 문서상 이 오픈 가중치 모델은 Qwen3.5의 아키텍처 위에 세워졌으며, 코딩·전문 업무·리서치·장기 에이전트 작업 전반에서 향상됐다고 설명된다. 단순히 더 어려운 질문에 답하는 수준을 넘어, 여러 단계를 거치는 복잡한 작업을 끝까지 완수하는 신뢰성에 초점을 맞췄다는 것이 강조점이다.
오픈 가중치와 Max API의 경계
실무자가 헷갈리기 쉬운 부분은 오픈 공개된 Qwen3.8-2.4T-A95B와 상용 서비스인 Qwen3.8-Max의 차이다. 문서에 따르면 Qwen3.8-Max는 이 오픈 모델을 기반으로 한 공식 버전이되, 비전(이미지) 입력, 비사고(non-thinking) 모드 지원, 기본 1M 토큰 컨텍스트, 공식 내장 도구 등 추가 기능을 얹은 형태다. 반대로 이번에 가중치가 풀린 모델은 텍스트 전용이며 멀티모달 입력을 지원하지 않는다. 즉 자체 구동을 택하면 Max의 부가 기능은 포기해야 하고, 그 기능이 필요하면 Qwen Cloud API를 쓰라는 구도다.
가장 실무에 직접 영향을 주는 제약은 '사고 모드 강제'다. 이 오픈 모델은 모든 상호작용에서 추론 모드를 요구하며, 사고 과정을 끌 수 없다. 모든 응답은 자동으로 블록에 감싼 추론을 먼저 생성한 뒤 최종 출력을 내놓는다. 챗봇처럼 짧고 빠른 응답을 기대하는 워크로드에는 이 구조가 지연과 토큰 비용 측면에서 부담이 될 수 있다. 대신 Qwen은 reasoning_effort 파라미터를 공식 지원해 추론 깊이와 비용을 조절할 수 있게 했고, preserve_thinking을 기본 활성화해 별도 설정 없이도 무난한 기본 경험을 제공한다고 밝혔다.
벤치마크와 통합 방식
공개 자료는 성능 근거로 Terminal Bench 2.1, SWE-bench Pro, DeepSWE 1.1, NL2Repo-Bench, FrontierSWE 등 코딩·소프트웨어 엔지니어링 계열 벤치마크를 제시한다. 다만 각 수치의 절대값보다 측정 조건에 눈길이 간다. 예컨대 Terminal Bench 2.1은 Claude Code 하네스로 5시간 타임아웃과 max_tokens 131,072 조건에서 평가했고, NL2Repo-Bench에서는 리포지터리 접근을 시도하는 pip install·git clone 등의 명령을 차단해 보상 해킹을 막았다고 명시한다. 이처럼 하네스와 조건에 따라 결과가 크게 달라지므로, 도입을 검토하는 팀이라면 발표 수치를 자사 환경에 그대로 대입하기보다 동일 조건 재현 여부를 먼저 확인하는 편이 안전하다.
통합 관점에서는 진입 장벽이 낮은 편이다. Chat Completions API를 대부분의 추론 프레임워크와 Qwen Cloud에서 그대로 쓸 수 있고, OpenAI 파이썬 SDK로 모델명과 API 베이스 URL만 바꿔 연결하는 방식을 안내한다. 다만 Qwen Cloud API를 쓸 때는 사고 관련 옵션을 chat_template_kwargs 대신 enable_thinking·preserve_thinking 형태로 extra_body에 직접 전달해야 한다는 차이가 있어, 프레임워크별 파라미터 지원 범위를 사전에 확인해 둘 필요가 있다.
종합하면 Qwen3.8은 최상위 체급의 추론·에이전트 모델을 자체 인프라에서 돌릴 선택지를 넓혔다는 점에서 의미가 크다. 반면 텍스트 전용, 사고 모드 필수, 1M 컨텍스트를 감당하기 위한 서빙 자원 요구 등은 현실적인 비용으로 돌아온다. 결국 관건은 이 모델이 요구하는 추론 오버헤드와 인프라 부담을, 장기 에이전트 작업에서의 완수 신뢰성이라는 강점이 상쇄해 주느냐다. 가벼운 대화형 서비스라면 Max API나 더 작은 모델이 합리적일 수 있고, 자율적으로 여러 단계를 밟아야 하는 개발·리서치 파이프라인이라면 자체 구동의 통제력이 값어치를 할 수 있다.