EschaLabs/Qwen3.6-35B-A3B-Escha-W2
코드 생성·추론 중심 텍스트 생성 (OpenAI 호환 로컬 API 서빙)35B (MoE, 256 experts, A3B 활성)32K 컨텍스트apache-2.0
Qwen3.6-35B-A3B MoE를 2비트로 양자화해 12.3GB, 16~24GB GPU에서 로컬 서빙 가능하게 만든 배포판.
TL;DR
Escha-W2는 256개 전문가를 가진 Qwen3.6-35B-A3B MoE를 전문가 투영은 혼합 2/3비트, dense 레이어는 int8로 양자화해 12.3GB 체크포인트로 압축한 빌드로, 16GB(동시성·컨텍스트 택일) 또는 24GB 소비자 GPU에서 SGLang 또는 의존성 없는 단일 바이너리 ZML 런타임으로 서빙한다. HumanEval+ pass@1 92.07, MMLU-Pro 80.9%, MATH-500 93.8%, GPQA-Diamond 77.8%를 기록해 2비트 압축에도 지식·수학 과제에서는 FP8과 큰 차이가 없지만, LiveCodeBench v6 서브셋 pass@1은 62.64로 장문 코드 생성에서는 용량 손실이 더 두드러진다. SGLang은 동시성·도구 호출·구조화 출력을 지원해 모든 벤치마크가 이 엔진으로 측정됐고, ZML은 온도 0의 그리디 디코딩에서만 카드별로 최대 26% 더 빠른 대신 샘플링을 켜면 오히려 2배 이상 느려진다. 저비용 소비자 GPU 한 대로 35B급 MoE 코딩·추론 모델을 로컬에서 돌리려는 사용자에게 맞춰져 있다.
핵심 포인트
- 전문가 투영은 혼합 2/3비트, dense 레이어는 int8로 양자화해 35B MoE를 12.3GB로 줄였다.
- MMLU-Pro 80.9·MATH-500 93.8은 FP8과 큰 차이가 없지만 LiveCodeBench v6은 62.6으로 FP8(67.0)보다 손실이 크다.
- 동시성·도구 호출·구조화 출력을 지원하는 SGLang과 Python 없이 동작하는 단일 바이너리 ZML 두 런타임을 함께 제공해 용도에 맞게 고를 수 있다.
- ZML은 온도 0의 그리디 디코딩에서만 카드별로 최대 26% 더 빠르고, 샘플링(온도>0)을 켜면 오히려 2배 이상 느려져 SGLang이 유리해진다.
제한사항
- LiveCodeBench v6 서브셋 같은 장문 코드 생성 과제에서는 FP8 대비 성능 손실이 다른 축보다 뚜렷하게 나타난다.
- 16GB GPU에서는 컨텍스트 길이와 동시 처리 스트림 수 중 하나를 포기해야 하고, ZML 엔진은 16GB 카드에서 긴 프롬프트(약 700~2048 토큰 이상)를 주면 알아보기 힘든 HTTP 500 오류로 실패한다.
- ZML의 속도 우위는 온도 0의 그리디 디코딩에만 적용되고 샘플링을 쓰면 토큰당 처리량이 2배 이상 떨어진다.
벤치마크
| 벤치마크 | 지표 | 값 | 비교 |
|---|---|---|---|
| HumanEval+ | pass@1 (greedy, thinking-off) | 92.07 | — |
| MMLU-Pro | acc (5-shot CoT, thinking-on) | 80.9 | — |
| MATH-500 | acc (thinking-on, budget-capped) | 93.8 | — |
| GPQA-Diamond | acc (thinking-on) | 77.8 | — |
| LiveCodeBench v6 (N=182 subset) | pass@1 (FP8 대비 retention) | 62.64 | — |
244
LIKES
4.1k
DOWNLOADS
0 / 0
조회수
관련 토론
아직 관련 토론이 없습니다.
댓글
댓글을 작성하려면 로그인이 필요합니다.
