Qwen3.8-Flash-Next, 팀 배포는 아직 개인용은 쓸 만

정정 (2026년 10월 3일): 원래 Qwen3.8-Flash-Next를 "320B급 MoE"라고 썼으나 Hugging Face 모델 정보를 다시 확인해 "180B급 MoE"(총 약 1,800억 파라미터)로 고쳤습니다.

GB10(NVIDIA DGX Spark) 한 대에 RadixArk가 낸 4비트(NVFP4) 비공개 후보판 Qwen3.8-Flash-Next를 올려 2026년 9월 3일부터 8일까지 6일간 직접 운영해 본 결과, 팀 트래픽을 받는 자리에는 아직 이르고 개인 사용으로는 쓸 만하다는 판정을 내렸습니다. 아래 나오는 모든 속도 수치는 이 조합 — GB10 한 대와 4비트 비공개 후보판 — 을 기준으로 한 값이라, 정식 BF16판이나 다른 하드웨어에서는 얼마든지 달라질 수 있습니다. 품질과 안정성은 확실히 합격점인데, 체감 속도가 기본 모드도 1.4배 느리고 사고(thinking)를 최대로 켜면 33분대까지 늘어나는 것이 발목을 잡았습니다. 다만 이 느림은 모델 자체의 결함이 아니라, GB10 한 대라는 이번 리뷰의 하드웨어 구성 탓에 생기는 구조적 병목입니다 — 47.7GiB짜리 PLE 임베딩 테이블을 NVMe에서 읽어야 하는 이 조합 자체의 한계라는 뜻입니다.

테스트 환경은 통합 메모리 128GB의 GB10 한 대, vLLM 하이브리드 모드입니다. 같은 기계에서 8월부터 운영 중인 두 모델 — 기본으로 쓰는 Gemma-4-26B와, 한국어에서 기본 모델보다 3배 느려 "느려도 좋은 질문"에만 붙이던 선택 모델 Qwen3.8-27B — 을 기준선으로 삼았습니다. 두 모델도 같은 기계에서 각각 따로 리뷰했습니다. 기본 모델은 넉 달, 선택 모델은 3주를 운영한 기록. Flash-Next는 180B급 MoE인데 활성 파라미터가 작고 공개 지능 지표가 선택 모델을 크게 앞서, 같은 기계 한 대에 들어가는지가 관건이었습니다.

180B급 MoE를 GB10 한 대에 4비트로 올렸다

Qwen3.8-Flash-Next는 180B급 MoE 구조이고 활성 파라미터는 그보다 훨씬 작습니다. 사고 강도를 -low·-medium·-xhigh 중에서 고르거나 모델이 자동으로 판단하게 두는 하이브리드 사고 게이트가 달려 있습니다. 공식 배포는 BF16 원본(Qwen3.8-Flash-Next↗)인데, 이번 실측은 RadixArk가 낸 4비트(NVFP4) 비공개 후보판↗(135.3GB)입니다. 저장소 README를 직접 열어 보면 스스로 "private candidate release"라고 밝히고 있어, 공식 양자화(quantization)판으로 오해하면 안 됩니다.

서빙 엔진은 vLLM MODE=hybrid이고, MTP 깊이는 2로 뒀습니다 — 이건 엔진 기본 설정값일 뿐 별도로 튜닝한 실험은 아닙니다. GPU_MEM=0.80에 컨텍스트 상한은 262,144토큰, 동시 시퀀스는 8, prefix caching은 켠 채로 KV 캐시 10.6GiB를 씁니다. 이 조합은 뒤에서 다룰 vLLM 미해결 이슈의 재현 설정과 사실상 같아서, 우리 6일 운영이 그 이슈의 재현 조건과 같은 설정이었다는 뜻이기도 합니다.

화면에는 사고 강도를 고르는 드롭다운이 있고 기본값은 자동 판정입니다. 이번 6일 동안은 자동 판정(49건)과 최대 강도인 -xhigh(28건)에 사용이 몰렸고, -low는 7건에 그쳤습니다. 뒤에 나오는 체감 속도 표에서 사용이 왜 이렇게 나뉘었는지가 그대로 드러납니다.

서빙 스택을 세 번 바꾸자 프리필이 4배가 됐다

처음 올린 것은 llama.cpp 프리빌트 4비트 GGUF였고, 프리필 속도가 253 tok/s로 같은 기계의 기존 기본 모델(Gemma-4-26B)의 4분의 1에 그쳤습니다. 업스트림에 아직 병합되지 않은 PR 두 건 — PLE 읽기 방식 개선과 MTP 지원 — 을 직접 병합해 자체 빌드를 만들자 328.7로 30% 올랐지만 그래도 3.4분의 1이었습니다. 마지막으로 vLLM NVFP4 하이브리드로 옮기자 프리필이 1,038~1,253까지 올라 기존 기본 모델과 동급이 됐습니다.

이 과정에서 가설이 실측으로 뒤집힌 순간이 있었습니다. "온디맨드 디스크 읽기가 프리필을 늦춘다"고 보고 그 기능을 끄자 오히려 281에서 215로 더 느려졌습니다. 진짜 해법은 기능을 끄는 것이 아니라 읽는 방식 자체를 바꾸는 것 — mmap 데맨드 페이징 대신 직접 읽기로 가는 것 — 이었고, 업스트림 PR은 이미 그렇게 고쳐져 있었습니다. 증상이 같아 보여도 원인은 정반대일 수 있다는 것을 이때 확인했습니다.

vLLM NVFP4로 넘어가면서 컨텍스트 상한도 65,536에서 262,144토큰으로 4배 늘었습니다. llama.cpp는 전체 컨텍스트를 슬롯 수로 미리 쪼개 놓고 사용하지 않는 슬롯이 있어도 빌려주지 않는 구조인데, vLLM은 페이지드 KV라 이 선택을 강요하지 않기 때문입니다. 긴 첨부를 처리하는 것이 실사용의 주된 불만이었던 것과는 정반대로, 구조 자체가 그 불만을 풀어준 셈.

프리필은 Gemma와 같은 자리에 왔지만 디코드는 못 따라왔다

같은 스크립트, 같은 조건으로 다섯 구성을 모두 측정했습니다. 순수 디코드(256토큰)는 vLLM 최종 구성이 22.97 tok/s(중앙값, n=47)로 llama.cpp 자체 빌드 26.2나 vLLM 콜드 18.5와 큰 차이가 없었고, Gemma-4-26B 38.8에는 못 미치지만 기존 선택 모델(27B급) 22.0과는 비슷했습니다. 반면 프리필(32k)은 1,038~1,253으로 Gemma의 1,130.2와 사실상 같은 자리에 왔습니다.

이 프리필 수치의 폭은 왜 이렇게 클까요? 답은 페이지 캐시 상태입니다. PLE 테이블이 5% 상주할 때는 264.7, 30% 상주할 때는 1,253으로 최대 4배까지 차이가 났고, 같은 조건에서도 회차마다 8.4~33.1 tok/s로 흔들리는 것을 확인했습니다. 생성이 샘플링이라 매번 다른 테이블 행을 읽기 때문이라, 단발 측정값은 믿을 수 없고 중앙값을 여러 번 쌓아야 합니다.

디코드가 느린 것은 튜닝으로 풀 문제가 아니었습니다. 47.7GiB짜리 PLE 임베딩 테이블을 NVMe에 두고 읽는 구조라, 약 30%만 페이지 캐시에 올라가고 나머지는 토큰마다 디스크에서 다시 읽습니다. 읽기량을 0으로 외삽하면 이론적 한계는 약 31 tok/s이고, 원인은 대역폭이 아니라 랜덤 읽기 지연(NVMe 처리량이 장치 대역폭의 1%에 불과)이고, 2비트로 낮춰도 바뀌지 않는 구조 자체의 한계.

실사용 벽시계가 벤치마크 판정을 뒤집었다

6일 동안 답변 95건, 대화 22개를 처리했고 출력 토큰은 총 362,655개, 최대 컨텍스트는 78,865토큰을 기록했습니다. 질문을 보낸 시각부터 답이 저장된 시각까지 벽시계로 측정한 체감 속도는 모델·모드별로 크게 달랐습니다. 기존 기본 모델(Gemma-4-26B, n=258)이 중앙값 29.1초, 기존 선택 모델(27B급, n=141)이 48.3초였고, Flash-Next는 자동 판정(n=49) 41.7초, -low(n=7) 84.4초, -xhigh(n=28) 218.9초(3.6분)였습니다.

기본 설정(자동 판정)은 기존 선택 모델과 비슷한 자리에 있고, 기존 기본 모델보다는 1.4배 느립니다(41.7 대 29.1초). 사고를 아예 켜지 않는 조합이 없다는 점을 감안해도, 이 정도면 기본 채팅 자리를 곧바로 대체하기는 어렵다는 뜻.

-xhigh는 사실상 다른 모드. 중앙값이 3.6분이고 열에 하나는 26분(p90 1,553초), 최악은 33.7분(2,022초)까지 걸렸습니다. 품질이 좋다는 평가도 대부분 이 설정에서 나왔는데, 이건 모델 자체가 빨라진 것이 아니라 품질과 대기시간을 맞바꾼 결과입니다.

-xhigh는 출력도 깁니다. 후반 4건의 평균 출력이 30,869토큰이었는데, tok/s 자체는 다른 모드와 크게 다르지 않아도 쓰는 글자 수가 늘어난 만큼 총 대기시간이 함께 늘어납니다.

순수 디코드만 보면 23 tok/s 안팎이라 앞 절에서는 쓸 만해 보였지만, 실제 사용자가 기다린 시간의 중앙값은 42초 근처였고 최악은 33.7분이었습니다. 실사용 벽시계 표가 판정을 뒤집었습니다.

4일 6시간 무재기동, 다만 같은 설정의 vLLM 이슈가 열려 있다

안정성은 확실한 합격점. 연속 가동 4일 6시간 동안 재기동 0회, 크래시 0건이었고, 서버 로그 45,788줄 어디에도 OOM이나 세그폴트가 없었습니다.

vLLM 저장소에는 이 조합과 정확히 일치하는 미해결 이슈(#54173↗)가 있습니다(2026년 9월 8일 기준 open). 재현 설정 — 동시 시퀀스 8, GPU_MEM=0.80, MTP 깊이 2, prefix caching 켬 — 이 우리 설정과 사실상 같아서 증상이 겹칠 위험이 있었지만, 6일 95턴 동안 실제 발생은 0건이었습니다. 트래픽이 한산했던 것도 사실이라 "안전하다"는 증거로 쓰기엔 표본이 작다는 점은 인정합니다. 이 이슈는 외부 리포터가 제기한 것으로, vLLM 메인테이너의 공식 판정은 아직 없다는 것도 밝혀둡니다.

이슈 상태는 아직 open이고 GitHub 라벨상 머지된 공식 수정은 없지만, 고칠 방법이 아예 없는 것은 아닙니다. 리포터는 이후 댓글에서 업스트림에 병합되지 않은 커뮤니티 패치 두 개로 자기 하드웨어(sm_121)에서 우회했다고 정정했습니다.

짧은 호출이 빈 응답으로 끝나고, system 메시지가 둘이면 400이 났다

사고 예산 파라미터(thinking_max_tokens 계열)를 짧은 호출에 그대로 물렸다가 곤란해진 경우가 있었습니다. 이 값이 사고 부분만이 아니라 턴 전체 출력 길이를 함께 묶고 있어서, 예산이 작은 짧은 호출(대화 제목 요약 등)이 사고만 하다 본문 없이 끝나 버립니다. 겉보기엔 정상 응답 형태라 실패인지 알아채기가 쉽지 않았습니다.

같은 계열이라고 API 관용도까지 같을까요? 기존 선택 모델(27B급)은 맨 앞에 system 메시지가 여러 개 이어져도 받아주는데, Flash-Next는 이를 400으로 거부합니다. 증상도 고약했습니다 — 화면엔 일반 오류 문구만 뜨고, 첨부나 이전 산출물이 붙어 system이 둘로 늘어나는 특정 턴만 골라 죽었습니다.

세 번째는 6일 동안 아무도 알아채지 못한 채 지나간 문제였습니다. 모델 강도별로 이름을 나눠 관리하고 있었는데, 그 강도가 붙은 이름이 정리 없이 그대로 추론 서버로 전달되는 경로가 하나 있었습니다. vLLM은 자신이 서빙하는 이름(--served-model-name)과 다른 이름으로 오면 404로 거부합니다. 본 답변 경로만 이름을 정리해서 보내고 대화 제목을 생성하는 것 같은 짧은 내부 호출은 정리 없이 보내고 있었던 탓에, 답변 자체는 멀쩡하고 그 대화의 제목만 요약 대신 질문 첫 줄로 남는 정도의 증상만 나타났습니다. 이건 이 vLLM 동작을 몰라서 생긴 문제였습니다. llama.cpp는 아무 이름이나 받아줘서 이전 스택에서는 이 문제 자체가 재현되지 않았습니다. 남의 도구를 감싸 쓸 때 실제로 부딪히는 종류의 발견이라, 이번 리뷰에서만 나온 대목입니다.

아직 측정하지 못한 것도 있습니다. Flash-Next와 기존 선택 모델의 같은 19문항 품질 블라인드 대조, 그리고 llama.cpp 경로의 동시 처리 수치. 이 두 가지는 6일 안에 들어가지 못했습니다.

다시 볼 조건은 셋. PLE 임베딩 테이블이 메모리에 전부 올라갈 수 있는 환경이면 지금의 병목(이론적 한계 31 tok/s)이 풀릴 가능성이 있고, prefix caching 버그가 고쳐지면 멀티턴 재프리필 지연이 사라집니다. 사고 강도 상한 문제가 해결되면 -xhigh를 상시 열어둘 수도 있는데, 지금은 53자짜리 짧은 질문에 사고만 20분 35초가 나온 사례가 있어 위험.

팀 배포용으로는 아직 이르고 개인 사용으로는 쓸 만합니다. 5점 만점에 3점을 부여했는데, 이 점수는 모델 자체의 지능이나 안정성 평가가 아니라 한국어 업무 산문·GB10 1대·팀 사용이라는 하드웨어 구성 안에서 실제로 쓸 수 있는지를 반영한 조건부 점수입니다. 품질은 실사용 인상과 공개 지능 벤치마크(DeepSWE 58.7 대 42.2, 기존 선택 모델 대비 큰 차이) 둘 다 좋다고 말하는데, 이 수치는 BF16 원본 기준으로 보이고 실제 구동판은 4비트라는 차이는 감안해야 합니다. 안정성은 4일 무재기동·크래시 0건으로 합격이지만, 체감 속도가 기본 모드도 1.4배 느리고 -xhigh는 33분대까지 늘어나는 게 발목을 잡습니다. 이건 모델의 한계가 아니라 GB10 한 대에서 47.7GiB짜리 PLE 테이블을 NVMe로 읽어야 하는 이 구성 자체의 구조적 병목입니다 — 읽기량을 0으로 외삽한 이론적 한계가 약 31 tok/s이고, NVMe 처리량이 장치 대역폭의 1%에 불과한 랜덤 읽기 지연이 원인입니다. 한국어 응답에 중국어·일본어 낱말이 섞이는 문제도 이번 6일 실측에서 나타났는데, 42건 중 2건(4.8%)이었고 같은 조건에서 기존 선택 모델은 84건 중 4건으로 같은 비율, 기존 기본 모델은 400건 중 0건이었습니다. 2건/42건과 4건/84건이 정확히 같은 값(4.76%)으로 맞아떨어진 것은 우연이고, 이 혼입률 자체는 최종 구성인 vLLM NVFP4가 아니라 이전 4비트 GGUF 빌드에서 측정한 값이라는 점도 감안해야 합니다. GB10 한 대로 개인 용도 — 느려도 되는 분석, 긴 문서 처리 — 에는 쓸 만하지만, 팀 트래픽을 받는 자리에는 지금 올리지 않는 것을 권합니다.