Qwen3.8-Flash-Next-NVFP4 vs Qwen3.8-27B-FP8 테스트 결과

Qwen3.8-Flash-Next-NVFP4 (inferact) vs Qwen3.8-27B-FP8 (qwen)

일이 너무 밀려서 예쁘게 다듬을 시간도 없네. 내용은 대부분 Qwen이 썼지만 데이터는 내가 직접 확인했다.

모든 테스트는 같은 장비, 같은 프롬프트로 돌렸고, 대부분 내 실무 워크로드 기반이다.

단일 GPU 로컬 평가 환경: RTX PRO 6000 Blackwell Max-Q (96 GB, SM120) 1장 + 256 GB DDR5, vLLM nightly 버전 사용. 내 에이전트 스택(텍스트 스코어링 파이프라인, 메모리 통합, 로컬 심층 조사, 브라우저 자동화 등)이 실제로 쓰는 서비스 별칭과 포트에 두 모델을 번갈아 가며 올렸다. 코딩은 최소한으로 했다. 어차피 하위 소비자들이 별칭을 보고 호출하니까, 뒤에 붙은 모델만 바꿔치기하는 게 뭐가 터지는지 확인하는 가장 확실한 방법이지.

테스트한 모델:

- Qwen3.8-Flash-Next-NVFP4 (https://huggingface.co/Inferact/Qwen3.8-Flash-Next-NVFP4)

- Qwen3.8-27B-FP8 (https://huggingface.co/Qwen/Qwen3.8-27B-FP8).

아래에 나오는 모든 프롬프트, 픽스처, 스코어러는 두 번의 테스트 과정에서 바이트 단위까지 똑같다. 오직 모델만 바꿨다.

**세 줄 요약:** Flash-Next가 훨씬 빠르고 기계적으로 완벽함(엄격한 JSON, 인젝션 방어, SLA: 실패 0건). 고도의 추론이 필요한 공간/코드 생성 티어에서도 더 나은 실패 모드를 보여주며 승리함. 반면 27B 밀집 모델은 여전히 지속적인 다단계 상징 작업(버그 수정, 수학 증명, 추상 퍼즐)에서 우위를 점함. 여기서 Flash-Next는 아주 골 때리는 실패 유형을 보이는데, 결과물을 주겠다고 큰소리치고 "완료"라고 선언한 뒤 아무것도 출력하지 않음. 같은 reasoning_effort 값을 줘도 의미론적으로 완전히 다르게 작동함. 그냥 바로 갈아끼울 수 있는 건 아니고, 상황 봐서 골라 써야 함.

서빙 레시피 (내가 실제로 돌린 설정)

**Flash-Next:**

-e VLLM_PLE_CPU_OFFLOAD=1 \ # ~100GB n-gram 임베딩 테이블을 호스트 RAM에 박아둠
-e VLLM_API_KEY=*** \
--entrypoint vllm serve Inferact/Qwen3.8-Flash-Next-NVFP4 \
--max-model-len 200704 \ # ~200K (네이티브 262K)
--gpu-memory-utilization 0.91 \
--max-num-seqs 16 \ # 지연 시간 우선 단일 워크스테이션
--no-enable-flashinfer-autotune \ # 하이브리드 어텐션 경로가 알아서 백엔드 선택
--structured-outputs-config '{"backend":"xgrammar","disable_any_whitespace":true}' \
--enable-prefix-caching --enable-chunked-prefill \
--reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \
--speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
--served-model-name llm-large ```

현장에서 얻은 팁: PyPI 휠은 이 아키텍처를 지원 안 함. 전용 이미지로만 돌려야 함. 위에서 `xgrammar` 고정한 건 27B 스택에서 가져온 건데, 이게 핵심이었음(빼니까 조용히 멈추는 현상 재발함). 측정 결과: 생성 속도 약 177 tok/s, MTP 드래프트 수락 길이 약 2.1.

\*\*3.8-27B:\*\*

```bash
python3 -m vllm.entrypoints.openai.api_server \
--model Qwen3.8-27B-FP8 --max-model-len 262144 --kv-cache-dtype fp8 \
--gpu-memory-utilization 0.52 --max-num-seqs 16 --attention-backend FLASHINFER \
--structured-outputs-config '{"backend":"xgrammar","disable_any_whitespace":true}' \
--reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \
--speculative-config '{"method":"mtp","num_speculative_tokens":2}' \
--served-model-name llm-large ```

변수 통제: 샘플러 기본값(`enable_thinking`, MTP, xgrammar)은 둘 다 똑같이 고정함. 작업마다 샘플링 설정이 달라지는 경우(아래 참고)에도 두 모델에 동일하게 적용함.

## 세 가지 테스트 스위트

\*\*1. 역량 테스트 배터리\*\* — 8개 작업 × 2~3회 반복, 온도 1.0 / 노력도 `medium`: 트레이스백 기반 버그 수정, 긴 문맥 파이프라인 지시사항, 다중 편집 이메일, 문서 정책 감사(일상 티어); Codeforces 1117-D, ARC-AGI 227, IMO 5번 문제 스케치, 오염 방지된 2026년 사실 관계 회상(고난도 티어). 결정론적 스코어러 사용, 0~1점 채점. \*(배터리: Flash-Next 작업당 N=2, 27B 작업당 N=3 — 중요한 부분은 따로 표시함.)\*

**2. 실무 등급 스윕(Production grading sweep)** — 내 실제 작업량: 엄격한 json_schema 강제 적용, temp 0.3 / `medium`, 요청당 300초 SLA를 적용한 루브릭 기반 클라이언트 텍스트 문서 채점. 27B는 전체 320개 요청 검증(엣지 케이스 + 인젝션 케이스)을 돌렸고, Flash-Next는 12개 엣지/인젝션 서브셋 × 3회 반복(36개 요청)에 27B의 전체 세트 수치를 참조용으로 썼음.

**3. 체스판 공간 재구성(Chessboard spatial reconstruction)** — 스트레스 테스트: 7수 PGN을 주고, 30개 기물이 정확한 칸에 배치되고 마지막 수가 하이라이트된 유효한 SVG를 출력하게 함. `reasoning_effort` 축(xhigh/medium/low/off)을 스윕했고, Flash-Next는 암(arm)당 N=5, 27B는 암당 N=3으로 설정. 채점자가 정답지와 기하학적 구조를 대조했고, 애매한 렌더링은 눈으로 직접 확인해서 판가름함.

## 결과

### 채점 스윕 (이 GPU가 실제로 돈값 하는 작업)

| | 27B-FP8 | Flash-Next-NVFP4 |
|---|---|---|
| 요청 (검증 스윕) | 320 | 36 (엣지+인젝션 서브셋) |
| 스키마 위반 JSON | 0 | 0 |
| SLA 위반 (>300초) | 0 | 0 |
| 루브릭 정확도 점수 | 319/320 (99.7%) | 33/36 (91.7%) |
| 프롬프트 인젝션 방어 | 54/55 | 9/9 |

Flash-Next가 틀린 3번은 전부 같은 케이스임: 키보드 막 두드린 쓰레기 값 사이에 묻혀 있는 유효한 항목. 27B는 10번 연속으로 부분 점수를 줬는데, Flash-Next는 3번 다 루브릭에 근거해서 0점 때림. 이건 불안정한 게 아니라 노이즈 허용 범위에 대한 안정적이고 논리적인 재조정임. 기계적인 보장(순수 JSON, 타임아웃 없음, 인젝션 방어)은 둘 다 완벽했지만, 루브릭 경계에서의 의미론적 판단은 달랐음. 내 시스템 루브릭에 ("노이즈에 묻힌 항목도 부분 점수 인정")이라는 줄 하나만 추가하면 이 격차는 메워질 것 같지만, 테스트는 안 해봄.

### 능력치 배터리 (effort `medium`, temp 1.0)

| 작업 | 27B (N=3) | F-N (N=2) | |
|---|---|---|---|
| 트레이스백으로 버그 수정 | **0.900** | 0.525 | 퇴보 |
| 긴 문맥 지시사항 | **0.917** | 0.675 | 퇴보 |
| 다중 편집 이메일 | **0.887** | 0.870 | ~동점 |
| 문서 감사 | **0.651** | 0.611 | ~동점 |
| Codeforces 1117-D | **0.667** | 0.562 | 동전 던지기 수준 |
| ARC-AGI 227 | 0.615 (≤216초) | **타임아웃 >420초, 둘 다** | 퇴보 |
| IMO P5 스케치 | **0.533** | 0.300 | 퇴보 |
| 2026년 사실 관계 회상 | 0.250 | 0.250 | 둘 다 바닥 |
| **일상 평균** | **0.839** | 0.670 | |
| **고난도 평균** | **0.516** | 0.371 | |

포맷팅 위주의 일상 업무는 거의 차이 없음. 지속적인 기호 조작은 성능이 떨어짐. 특히 ARC에서 Flash-Next가 이상하게 굴었는데, 두 번 다 GPU 100%로 7분 넘게 태우면서 spec-decoding 수용 길이가 ~1.0으로 꼬라박음(초안이 거의 계속 거부되고, greedy한 찌꺼기들만 계속 돌아감). 절대 수렴 안 함. 반면 dense 모델은 같은 문제를 3.5분 안에 해결함. 사실상 라이브락(livelock) 상태.

### 체스판 (정확한 보드 + 올바른 하이라이트, 암당)

| Effort | 27B (N=3) | Flash-Next (N=5) |
|---|---|---|
| **xhigh** | 1/3 (최고점: 2/3 기물 정확; 하나는 **완전 빈 보드**) | **3/5** — 틀린 건 1~3칸 오차; 빈 보드 없음; 벽 시간 약 20% 빠름 (165초 vs 206초) |
| medium | 1/3 | **0/5** — 3번은 *SVG를 아예 안 내뱉음* |
| low | 1/3 | 1/5* |
| off | 0/3 | 0/5 |

\* SVG 마크업으로 채점함(미리보기에서 렌더러 잘림 현상); 이걸 제외하면 low는 0/5 — 어느 쪽이든 결론은 안 바뀜.

실패 유형이 다름: 27B의 xhigh는 가끔 **치명적으로 터짐**(토큰 17.8k 소비, 빈 보드 출력, `finish_reason: stop`). Flash-Next의 xhigh는 **거의 안 터짐** — 에러가 기물 1~3개 위치가 어긋나는 정도로 국소적임. 그리고 `medium`에서 Flash-Next의 시그니처 실패는 이 벤치마크에서 제일 무서운 부분임: `finish_reason: stop`이 뜨는데, 응답 끝이 *"여기 최종 SVG입니다:"* — 하고 아무것도 없음. 지는 다 했다고 믿는 거임.

## 놀라운 발견

1. **`reasoning_effort`는 아키텍처마다 호환 안 됨.** 27B 덴스 모델에서 "Medium"은 믿고 쓰는 국밥 설정임. 근데 Flash-Next에선 *유령 결과물*(생성 완료라고 뜨는데 아티팩트는 없음)을 뱉거나 보드 상태가 맛이 가버림. 이 작업 한정으론 Flash-Next에서 "xhigh"가 27B의 "xhigh"보다 *훨씬 빠르고 좋음*. 추론 노브의 의미론은 모델마다 다 따로 놀음.

2. **실패 양상이 점진적이지 않고 절벽 수준임.** 27B는 결과물이 좀 구려도 일단 나오긴 하는데, Flash-Next는 이분법적임. 거의 완벽하거나 아예 구조가 박살 나거나 둘 중 하나임. 게다가 병적인 토큰 루프(18~22k 정도의 쓰레기 값 뱉고 finish=stop 찍힘)나 ARC 스타일의 수락-붕괴 라이브락 현상도 발생함. 타임아웃 가드만 걸지 말고 *아티팩트 검증* 로직을 래퍼에 꼭 넣으셈.

3. **엄격한 메커니즘은 둘 다 완벽함.** 36번 테스트 전부 strict-JSON 오류 0건, 인젝션 실패 0건, SLA 위반 0건. 이 아키텍처에서 xgrammar 구조화 출력 경로는 진짜 돌덩이처럼 단단함.

4. **처리량 ≠ 추론 시간.** 속도 자체는 Flash-Next가 어디서든 1.3~1.9배 정도 빨랐음(MoE 희소성 + MTP×3으로 약 177 tok/s). 근데 작은 덴스 모델이 몇 분 만에 끝낼 퍼즐을 얘는 *몇 시간 동안 끙끙대며* 붙잡고 있었음.

5. **토큰 제한이 생각보다 훨씬 치명적임.** Flash-Next 출력 예산을 12k 정도로 자르면 덴스 모델에서 발생한 모든 실패 유형을 합친 것보다 더 많은 생성 오류가 터짐. 얘가 생각하는 과정이 훨씬 말이 많거든. 예산은 최소 16k 이상 잡으셈. 아니면 잘린 결과물 보고 뒷목 잡게 될 거임.

6. **이 모델 패밀리 직접 돌려볼 사람들을 위한 삽질 방지 팁:** PyPI vLLM으론 로드 안 됨(전용 이미지 필수). 96GB 카드 한 장 쓸 거면 `VLLM_PLE_CPU_OFFLOAD=1`은 필수고, 강제 어텐션 백엔드가 하이브리드 경로랑 충돌함. 그리고 내 순차 요청 하네스는 긴 생성 작업 끝나고 파이썬 인터프리터 종료될 때 뻗어버리더라. poll-and-kill 드라이버로 해결함. 다 해결 가능한 문제긴 한데, 내가 찾을 땐 어디에도 문서화가 안 돼 있었음.

## 개인적인 결론 (LLM이 쓴 거 아님)

- Qwen3.8-27B-FP8이 Qwen3.8-Next-Flash-NVFP4보다 전반적으로 훨씬 안정적인 국밥임. vLLM 지원이 더 좋아지고 양자화가 잘 되면 바뀔 수도 있겠지만, 지금 당장 Next-Flash를 프로덕션에 올리는 건 좀 에바임.

- Next-Flash가 속도 이점은 확실함. 눈에 띄게 빠름. 물론 미친 듯이 생각만 하다가 출력도 하기 전에 12k 토큰을 태워먹기 전까진 말이지.

- 27B는 reasoning을 'medium'으로, Flash-Next는 'xhigh'로 설정하셈. 27B는 medium일 때 프로덕션 모델로서 훨씬 안정적임. 27B를 xhigh로 돌리면 치명적인 오류나 생각 루프가 더 자주 터짐. 물론 xhigh에서 대박을 터뜨릴 때도 있긴 한데, 품질이 극단적으로 갈림. Flash-Next는 무조건 xhigh가 답임. medium으로 돌리면 그냥 쓰레기임.

- 'low'는 쓸 수는 있는데 품질이 너무 구림. 그렇다고 medium보다 토큰을 적게 먹는 것도 아님.

- **두 모델 다 `off`(생성 시 생각 안 함)는 쓰지 마셈.** 우리가 테스트한 어떤 작업에서도 쓸모가 없음. Qwen3.6-27B랑 다르게, 27B-FP8이랑 Flash-Next는 추론 기능을 끄는 순간 둘 다 병신 됨.

## 주의사항

이건 내 개인적인 업무 부하를 기반으로 한 소규모 테스트임.

샘플 수가 적음(2~3회 반복). 0.1 미만의 차이는 그냥 경향성 정도로만 보고, 큰 차이(ARC, 버그 수정 등)는 유의미한 결과로 받아들이셈. 단일 머신, 단일 운영자, 비공개 테스트셋 사용(공개 리더보드랑 겹치는 거 없음. 'hard' 티어는 오염 방지를 위해 의도적으로 새로운 문제들로 섞음).

vLLM 쪽 문제일 수도 있음. Qwen3.8-27B 아키텍처보다 Flash-Next 지원이 훨씬 덜 성숙했으니 100% 얘 탓만 하긴 좀 그럼.