M5 Max 128GB에서 Qwen3.8-Flash-Next(79GB, 2-bit) 350K 컨텍스트 구동 테스트: 속도와 컨텍스트 깊이 분석
Ran Qwen3.8-Flash-Next (79 GB, 2-bit) at 350K ctx for 3.5 hours on a 128 GB M5 Max — speed vs context depth, 100 turns, one graph
핵심 요약
M5 Max에서 2-bit 양자화 모델을 활용해 169K 컨텍스트까지 구동한 성능 테스트 결과입니다.
- 성능 테스트 — M5 Max 128GB 환경에서 350K 컨텍스트 슬롯을 활용한 모델 구동 테스트함
- 속도 분석 — 169K 컨텍스트까지 디코딩 속도 11.5 t/s 유지하며 실사용 가능한 수준을 보여줌
- 품질 이슈 — 100K 컨텍스트 이후 롱테일 작업에서 모델의 역할 혼동 현상이 발생함
- 기술 최적화 — 접두사 재사용(prefix reuse)을 통해 긴 컨텍스트에서도 효율적인 프리필 성능을 확보함
세팅: MacBook Pro M5 Max, 128 GB 통합 메모리, macOS 26.5.2 · llama.cpp b10686 (Metal, 12 스레드, 배치 2048, flash-attn, kv-unified, ngram-mod spec decode) · Qwen3.8-Flash-Next UD-Q2_K_XL (Unsloth), 78.9 GB · YaRN을 통한 358,400 토큰 컨텍스트 슬롯 (네이티브 262,144에서 확장, fp16 KV). 가중치랑 350K KV 전체가 기본 GPU 할당량 96 GB 안에 다 들어감 — sysctl 같은 꼼수 안 씀.
세션: 슬롯 1개, 100턴, 대화 2개. 대화 1은 프리픽스 재사용으로 0에서 48K 컨텍스트까지 늘어남. 한 20분 정도 쉬니까 슬롯에 5.5K 시스템 프리픽스만 남아서, 다음 턴에 105K 프롬프트를 333초 만에 콜드 프리필함 — 이번 실행에서 제일 긴 프리필이었음. 대화는 계속 늘어나서 169,425 컨텍스트까지 찍음 (슬롯 용량은 350K였는데 다 채우진 못함). 슬롯 초기화하고 대화 2는 ~125K까지 키우다가 캡처 멈춤.
그래프: x축은 측정 당시 슬롯 컨텍스트 크기, y축은 초당 출력 토큰 수(로그 스케일, 두 단계가 20배 정도 차이 남). 초록색은 프롬프트 처리, 빨간색은 토큰 생성. 점은 중간 체크포인트, 사각형은 턴 종료 시점. 보정이나 피팅 같은 거 안 함.
-
프리필 (초록색): 위에 매끄러운 곡선은 콜드 프리필임 — 첫 체크포인트(5.6K 컨텍스트)에서 1,561 t/s 찍고, KV 차오르면서 111K에서 318 t/s까지 떨어짐. 아래쪽 초록색 띠는 일반적인 턴 모습임: 프리픽스 재사용 덕분에 델타값만 프리필해서 각 깊이마다 몇천 토큰씩 새로 처리함 (169K 컨텍스트까지 77–854 t/s).
-
디코드 (빨간색): 깔끔하게 우하향함 — 작은 컨텍스트에서 ~30–35 t/s → 45K에서 ~21 t/s → 100–125K에서 13–15 t/s → 169K에서 11.5 t/s. 140K 근처에서 7.7 t/s까지 떨어진 건 macOS 저전력 모드 때문인데, 그래도 쓸만함.
디코드 수치 관련 주의사항: 이건 ngram-mod spec decode 켰을 때의 실질 처리량임 (내용에 따라 드래프트 수락률 0~81% 왔다 갔다 함). 베이스 모델 속도 아님.
실사용 후기: 프리픽스 재사용하면 턴당 프리필은 몇 초면 끝남. 5.5분짜리 프리필은 쉬는 시간 가진 뒤 딱 한 번 있었음. 169K 컨텍스트까지도 디코딩 속도 쾌적함.
체감: 100K 컨텍스트까지는 꽤 괜찮음. 그 이상 넘어가면 롱테일 작업에서 유저 메시지랑 모델이 이전에 뱉은 출력값을 섞어버리는 현상(역할 혼동)이 생기는데, 오래 쓸수록 더 심해짐. KV 양자화(fp16으로 돌림)나 RoPE 외삽(최악의 턴도 네이티브 262K보다 훨씬 아래임) 문제는 아님. 의심되는 건 2비트 양자화나 프리뷰 모델 자체의 긴 컨텍스트 품질 문제인 듯.
