3.5 BPW로 압축한 Qwen3.8-Flash-Next Coder 공개

AI 요약

Qwen3.8-Flash-Next Coder는 Mixture-of-Experts(MoE) 모델의 전문가 절반을 제거하고 남은 가중치를 3.5 BPW로 양자화한 실험적 GGUF 배포본입니다. 원래 BF16 모델은 176.9B 파라미터에 354GB를 차지하지만, 변환기 가중치는 29.6GB로 줄었습니다. n-gram 테이블은 별도 샤드이며 디스크에서 읽을 수 있어 상주 메모리 계산에서 제외합니다. 모델 카드가 제시하는 1.89 bit/parameter는 제거한 전문가까지 원래 파라미터 수에 나눠 반영한 유효 압축률입니다. 개별 가중치가 1.89비트로 저장되는 것은 아니며, 남은 가중치는 3.5 BPW입니다.

전문가 제거와 성능

Flash-Next는 48개 층에 층마다 전문가 512개를 두고, 토큰마다 그중 10개를 활성화합니다. 배포본은 전문가의 절반을 없애고, GSQ 양자화와 RCO(Riemannian Constrained Optimization)를 함께 적용합니다. RCO는 보정 데이터에서 가지치기 모델과 원 모델 사이의 KL divergence를 줄이면서 층마다 정확한 예산을 지키도록 전문가를 선택합니다. GGUF는 모든 층에 같은 전문가 수를 요구하므로 층별 제약을 걸어 최적화합니다. 손실 함수는 전체 모델에 걸쳐 계산하며 층별로 독립 최적화하지 않습니다.

보정 데이터에 비전 능력을 포함하지 않고 탐색했을 때는 비전 경로에 필요한 전문가가 제거됐고, 이미지 능력이 크게 떨어졌습니다. 공개 버전은 보정 혼합물에 비전을 포함해 해당 능력을 유지하도록 탐색했습니다. 개발자 측정치에서 Coder 모델은 SWE-bench Verified 79.20점으로 BF16 기준 82.80점의 95.7%를 기록했고, LiveCodeBench v6는 두 모델 모두 87.43점입니다. 수치는 xhigh reasoning effort에서 측정했습니다. 모델 카드도 코드와 에이전트 작업, 비전, 공간 추론을 우선하며 그 밖의 능력 저하는 감수한다고 설명합니다.

8GB GPU 실행과 메모리 배치

두 샤드 중 변환기 가중치 29.6GB는 상주해야 하고, 28.8GB n-gram 테이블은 디스크에서 조회할 수 있습니다. Reddit 작성자는 전문가 가중치를 CPU 메모리에 두고 일부를 GPU에 올리는 llama.cpp 설정을 공유했습니다. 해당 댓글은 70 T/s를 프롬프트 처리(PP), 약 8 T/s를 토큰 생성(TG) 속도로 구분합니다. MMAP 첫 실행은 느릴 수 있어 두 번째 실행으로 속도를 확인하라고 덧붙였습니다. 262144 토큰 컨텍스트 설정도 공유했지만, 댓글에서 실제 8GB GPU에서 그 설정이 모두 재현됐다는 뜻은 아닙니다.

작성자는 본인 테스트가 RX 6700 10GB에서 이뤄졌다고 밝혔습니다. 8GB NVIDIA GPU 사용자는 동일 설정으로 메모리가 부족하거나 CUDA에서 실행에 실패했다고 보고했고, 작성자는 VRAM에 올리는 전문가를 더 줄이거나 Vulkan 백엔드를 써보라고 답했습니다. 속도는 GPU의 여유 VRAM, CPU와 RAM, PCIe 대역폭, 백엔드 및 오프로딩 설정에 따라 달라집니다. 70 T/s는 토큰 생성 속도가 아니라 프롬프트 처리 속도입니다.

어휘 가지치기 버전

별도 P1G 처리본은 코딩에 불필요하다고 분류한 비영어 문자를 어휘에서 제거해 248,320개 토큰을 130,020개로 줄였습니다. 특수 토큰과 256개 바이트 폴백 토큰은 유지했고, 임베딩·출력 가중치의 관련 행만 추려 약 409MB를 절약합니다. 변환기 구조와 나머지 1,222개 텐서는 그대로 유지됐다고 검증 로그에 적혀 있습니다. 모델 카드는 비영어 사용을 권장하지 않는다고 명시합니다.

Reddit 반응

• @jonathanx37 — 제 시스템은 8GB VRAM과 24GB RAM이며, MoE 일부를 VRAM에 두고 나머지는 RAM에 둡니다. n-gram 테이블은 디스크에서 읽습니다. 전체 메모리가 약 32GB라면 컨텍스트 크기를 낮춰야 할 수 있습니다. CUDA에서 8GB로 실패한다면 Vulkan을 써보세요. 제가 공유한 70 T/s PP와 약 8 T/s TG는 서로 다른 지표입니다.
• @Ne00n — 8GB RTX 4060과 64GB DDR4에서 설정을 그대로 복사했지만 메모리가 500MB 부족해 실행이 중단됐습니다. 생성 속도도 11 T/s라 4비트 모델과 별 차이가 없었습니다.
  • @jonathanx37 — 제 화면은 10GB RX 6700에서 찍었습니다. 8GB에서는 배경 프로그램이 쓰는 VRAM까지 고려해 CPU로 보내는 전문가를 늘려야 합니다. Vulkan을 시도하거나 컨텍스트를 16K로 낮춰 먼저 확인해보세요.
• @iAlexandreS — 제목은 n-gram이 디스크에 있다고 하지만 공유한 명령의 ngram-map-k4v는 메모리에서 쓰는 추측 디코딩용 맵입니다. GGUF 파일에 MMAP을 쓰는 것과는 다른 얘기입니다. 또 명령은 CUDA에서 실패할 수 있다고 한 8GB 설정과 일치하므로 70 T/s 수치가 어떤 백엔드에서 나온 것인지 확인이 필요합니다.
  • @jonathanx37 — 모델 내장 n-gram 임베딩과 --spec-type ngram-map-k4v의 추측 디코딩 맵은 서로 다른 기능입니다. 앞서 말한 디스크의 n-gram은 모델에 포함된 임베딩을 뜻합니다.
• @MindfulMan1984 — 온도 0.6은 instruct나 thinking 모드에서 권장되는 값이 아닙니다. 직접 확인한 느낌보다 정량 벤치마크와 모델 개발자의 권장 설정을 따르는 편이 낫습니다.
  • @jonathanx37 — 여러 모델에 같은 코딩 과제와 대화 프롬프트를 넣어 제 사용 환경에서 비교한 결과입니다. 공식 권장값도 시도했으며, 다른 사람에게도 같은 설정을 강요하는 것은 아닙니다.
• @YouCantMissTheBear — 프롬프트 처리 70 T/s라면 간단한 에이전트 작업에서도 첫 토큰까지 몇 분이 걸릴 수 있습니다.
  • @CodeMichaelD — llama.cpp는 KV 캐시를 저장해 새 세션에서 재사용할 수 있지만, 하네스의 준비 과정 일부만 줄여줍니다. 여러 차례 이어지는 작업이나 큰 파일의 프리필 문제까지 해결하지는 않습니다.
• @Nakidnakid — 코더 모델은 전문가가 빠진 버전이므로, 속도가 좋아도 무엇을 제거했는지 알아야 합니다.
• @BleynSpecnaz — 8GB RTX 5060과 32GB RAM에서 Strata로 262K 컨텍스트를 실행하고 약 800 T/s PP와 35 T/s TG를 얻었다고 주장합니다. 해당 속도와 품질 비교는 댓글 작성자의 보고입니다.
  • @pyr0kid — 8GB VRAM과 32GB RAM에서 그 속도가 가능하다는 주장에 의문을 제기합니다.
  • @jonathanx37 — Strata가 자주 쓰는 전문가를 VRAM에 캐시해 해당 속도를 낼 수 있다고 설명합니다. 자기 llama.cpp 수치와는 실행 엔진과 캐시 방식이 다르다고 덧붙입니다.

원문: Hugging Face 모델 카드, Reddit / 번역·요약: Trawling