Qwen3.8 Flash Next Uncensored, 공식 GGUF로 바꾸니 M5 Ultra 128K 요청이 47초에서 24초로
M5 Ultra 256GB에서 Qwen3.8 Flash Next Uncensored GGUF 두 개를 같은 빌드로 번갈아 쟀습니다. 희소 어텐션이 켜진 공식 Q4_K_M은 128K 위치 요청 한 번이 약 24초로, 꺼진 IQ4_XS(약 47초)의 절반이었습니다.
Qwen3.8 Flash Next의 Uncensored 판은 GGUF가 여러 곳에서 나와 있습니다. 이전 비교 글에서 쓴 mradermacher의 IQ4_XS는 희소 어텐션(QSA) 설정 값이 모두 0이라 llama.cpp에서 QSA 없이 돌고, 그래서 문맥이 길어질수록 크게 느려졌습니다. 모델을 만든 orcarouter가 직접 낸 공식 GGUF에는 이 값이 들어 있습니다.
공식 Q4_K_M을 받아 Mac Studio M5 Ultra(GPU 80코어, 통합 메모리 256GB)에서 두 파일을 같은 llama.cpp 빌드, 같은 설정으로 쟀습니다. 회차마다 두 파일의 순서를 바꿔 가며 같은 밤에 번갈아 돌렸습니다. 이 공식 Q4_K_M 파일을 잰 다른 기기는 아직 없습니다.
128K 위치 요청 한 번에 걸리는 시간
작업은 공통 벤치마크와 같습니다. 이탈리아어 소설과 C++ 코드 원문을 한 세션에서 32K토큰씩 이어 붙여 128K까지 채우고, 단계마다 새로 넣은 32K의 prefill과 이어지는 256토큰 생성을 HTTP 스트리밍으로 쟀습니다. greedy, 원문마다 새 서버 프로세스로 3회입니다. Q4_K_M은 12회차 48단계가 실패나 재측정 없이 모두 유효했습니다.
아래 합계는 128K 단계의 첫 토큰까지 시간(TTFT)에 256토큰 생성 시간(256 ÷ 생성 tok/s)을 더한 계산값입니다. 모델 로딩(처음 30.6초, 이후 4.1~5.2초)은 들어 있지 않습니다.
| 파일 | 원문 | 측정 범위 | 회수 | 128K 첫 토큰까지 | 256토큰 생성 | 합계 (계산) |
|---|---|---|---|---|---|---|
| 공식 Q4_K_M | 소설 | 128K 단계 요청 하나, 로딩 제외 | 3 | 18.38초 | 5.90초 | 24.28초 |
| 공식 Q4_K_M | 코드 | 같음 | 3 | 18.44초 | 5.81초 | 24.25초 |
| mradermacher IQ4_XS | 소설 | 같음 | 3 | 40.78초 | 6.64초 | 47.42초 |
| mradermacher IQ4_XS | 코드 | 같음 | 3 | 41.07초 | 6.31초 | 47.38초 |
두 파일 모두 같은 기계, 같은 빌드, 같은 설정입니다. 32K 위치에서는 둘 다 약 22초로 같았고, 차이는 문맥이 깊어질수록 벌어져 128K에서 거의 2배가 됐습니다.
사용 설정
설정은 10월 27일 원본 모델(Unsloth UD-Q4_K_XL)로 고른 이 기계의 대표 설정을 그대로 썼습니다. 비교한 IQ4_XS도 같은 설정입니다.
| 항목 | 값 |
|---|---|
| 기계 | Mac Studio, M5 Ultra (CPU 12+24코어, GPU 80코어), 256GB, macOS 27.2 |
| 엔진 | llama.cpp b12040 00ef136, 소스 빌드 (Release, Metal 라이브러리 내장, 정적 링크) |
| 가중치 | orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF Q4_K_M (rev 98eb3357), 3조각 119.2GB, SHA256을 HF 값과 대조. 텍스트만 (비전 파일 미사용) |
| backend | Metal, 전 층 GPU (-ngl 99), CPU 대체 경고 없음 |
| KV | f16 / f16 |
| batch / ubatch | 2048 / 2048 |
| Flash Attention | on |
| MTP / speculative | off |
| 문맥 | 135,168 고정, 동시 요청 1, context shift 끔 |
| 모델 로딩 | mmap, 내장 SSD |
| 스레드 | 엔진 기본 (12) |
측정하는 동안 메모리 여유는 62~68%였고 swap은 쓰지 않았습니다.
문맥이 깊어질수록 벌어지는 차이
단위는 tok/s, 3회 평균입니다. 배율은 Q4_K_M ÷ IQ4_XS입니다.
| 원문·문맥 | IQ4_XS prefill | Q4_K_M prefill | 배율 | IQ4_XS 생성 | Q4_K_M 생성 | 배율 |
|---|---|---|---|---|---|---|
| 소설 32K | 1961.71 | 2004.83 | 1.02× | 47.27 | 44.89 | 0.95× |
| 소설 64K | 1341.41 | 1901.54 | 1.42× | 46.45 | 45.30 | 0.98× |
| 소설 96K | 1006.05 | 1840.48 | 1.83× | 40.41 | 44.73 | 1.11× |
| 소설 128K | 803.73 | 1784.16 | 2.22× | 38.56 | 43.38 | 1.12× |
| 코드 32K | 1948.13 | 2003.40 | 1.03× | 46.16 | 45.47 | 0.99× |
| 코드 64K | 1327.97 | 1925.53 | 1.45× | 46.74 | 44.40 | 0.95× |
| 코드 96K | 1001.63 | 1858.05 | 1.86× | 40.60 | 45.01 | 1.11× |
| 코드 128K | 798.12 | 1779.14 | 2.23× | 40.60 | 44.06 | 1.09× |
32K를 새로 넣는 데 걸린 시간으로 보면 차이가 더 분명합니다. 소설 기준으로 Q4_K_M은 16.4, 17.2, 17.8, 18.4초로 거의 늘지 않았고, IQ4_XS는 16.7, 24.4, 32.6, 40.8초로 단계마다 약 8초씩 늘었습니다.
이유는 파일 안의 희소 어텐션 설정입니다. Qwen3.8 Flash Next는 일부 층에서 문맥 전체가 아니라 골라낸 위치에만 attention을 하는 QSA를 씁니다. GGUF의 compress_ratios 값이 공식 파일은 4층마다 4(48층 중 12층)이고, mradermacher 파일은 48층 모두 0입니다. llama.cpp는 이 값이 0보다 큰 층이 있을 때만 QSA를 만들기 때문에, IQ4_XS는 모든 층이 문맥 전체에 일반 attention을 합니다. 원래 Qwen3.8 Flash Next 설정에도 이 값은 4로 들어 있습니다.
생성은 128K에서 Q4_K_M이 1.09~1.12배 빨랐지만, 32K에서는 0.95~0.99배로 조금 느렸습니다. Q4_K_M 파일이 21% 커서 토큰마다 읽는 양이 많기 때문으로 보입니다.
두 파일은 양자화 말고도 다릅니다
이 비교는 양자화 방식 하나만 바꾼 것이 아니라 파일 대 파일 비교입니다.
| mradermacher IQ4_XS | orcarouter 공식 Q4_K_M | |
|---|---|---|
| 양자화 형식 | IQ4_XS | Q4_K_M (21% 큼) |
QSA (compress_ratios) |
48층 모두 0, 꺼짐 | 4층마다 4, 켜짐 |
| imatrix | 표시 없음 | 사용 (200청크) |
모델 이름 (general.name) |
Qwen3.8 Flash Next Uncensored | Qwen3.8 Flash Next Abliterated |
모델 이름이 달라서, 두 파일이 같은 원본 가중치에서 나왔는지는 확인하지 못했습니다. 공식 저장소에는 IQ4_XS(97.5GB)도 있고 역시 QSA가 켜져 있지만, 이번에는 받지 않았습니다.
보충: perplexity
공통 벤치마크는 속도만 잽니다. 품질 차이를 가늠하려고 같은 빌드, 같은 옵션으로 llama.cpp의 perplexity 도구를 돌렸습니다. 원문은 벤치마크 입력 두 개이고, 16,384토큰 창 8개에서 각 창의 뒤쪽 절반(8K~16K 위치)만 채점했습니다. QSA가 골라 보는 위치 수(2048)를 넘는 구간입니다.
| 원문 | IQ4_XS | Q4_K_M | 차이 |
|---|---|---|---|
| 소설 (이탈리아어) | 8.0704 ± 0.0820 | 7.7223 ± 0.0777 | −4.3% |
| 코드 (C++) | 1.3538 ± 0.0062 | 1.3422 ± 0.0062 | −0.9% |
소설은 8개 창 누적 값이 모두 Q4_K_M 쪽이 낮았습니다. 코드는 첫 창에서는 Q4_K_M이 높았고 셋째 창부터 낮았습니다. ±는 도구가 낸 추정 오차이고, 두 파일이 같은 토큰을 채점하므로 두 값은 서로 독립이 아닙니다. 유의성 검정은 하지 않았습니다. 위 표처럼 형식, imatrix, QSA가 함께 다르므로 이 차이를 어느 하나의 효과로 볼 수 없고, 원본 BF16 기준 KL divergence는 원본이 없어 재지 않았습니다.
그 밖에 본 것
- greedy인데 Q4_K_M은 회차마다 출력이 달랐습니다. 3회 출력이 모두 같은 단계는 8단계 중 코드 32K 하나뿐이었고, IQ4_XS는 8단계 모두 같았습니다. QSA가 켜진 원본 모델
UD-Q4_K_XL에서도 같은 현상이 있었습니다. 원인은 확인하지 않았습니다. - IQ4_XS를 10월 27일(b11921)에 잰 값과 비교하면 prefill은 같고(128K 806 대 804 tok/s), 32K 생성은 51.70에서 47.27 tok/s로 8.6% 낮았습니다. 128K 생성은 38.49와 38.56으로 같았습니다. 이번 빌드는 회차 간 생성 편차도 컸습니다(128K 코드 37.2~43.2). 측정 중에 화면을 쓰고 있어서(WindowServer 최대 42%, 미디어 분석 프로세스 최대 56%, Safari) 이것이 원인인지 빌드 탓인지는 가르지 않았습니다.
- 다른 빌드로 Q4_K_M을 재서 가장 빠른 빌드를 고르는 일은 하지 않았습니다.
범위
- MTP는 재지 않았습니다. 공식 저장소에 MTP용 draft 파일(4.1GB)이 있지만, README에 따르면 아직 병합되지 않은 llama.cpp PR #30592 빌드에서만 돕니다.
- 품질은 위 perplexity만 봤습니다. 실제 글쓰기나 코딩 결과는 비교하지 않았습니다.
- 다른 기기 결과와는 나란히 두지 않았습니다. Ryzen AI Max+ 395 쪽 결과도 같은 mradermacher 파일이라 QSA 없이 잰 값이고, 공식 GGUF로 잰 결과는 아직 없습니다.