Qwen3.8-Flash-Next를 Unsloth로 로컬 실행하기: 96GB와 128GB의 실제 기준

Qwen3.8-Flash-Next를 로컬에서 돌릴 수 있다는 말은 맞지만, 75GB만 확보하면 모든 작업이 해결된다는 뜻은 아닙니다. Unsloth는 가장 작은 1-bit quant의 최소 총 메모리를 75GB로 제시하고 96GB RAM 또는 통합 메모리 장치를 권장합니다. 현재 4-bit 기준은 약 112GB이므로, 128GB 장비도 긴 context와 여러 앱을 동시에 쓰기 전에 여유를 계산해야 합니다.

“토큰당 6B parameters 활성화”도 6B footprint라는 뜻이 아닙니다. Qwen 공식 모델 카드에 따르면 main MoE는 125B, N-gram embedding은 51B, MTP는 4B입니다. 한 토큰을 계산할 때 main model의 6B가 선택되더라도 필요한 weight는 저장하고 읽을 장소가 있어야 합니다.

메모리 등급별로 먼저 No-Go를 정한다

표시된 용량이 아니라 추론 시점의 실제 가용 메모리를 봅니다. Apple Silicon은 macOS와 앱이 unified memory를 공유합니다. discrete GPU 시스템은 VRAM만 볼 수 없고 system RAM, PCIe transfer, CPU offload까지 함께 봐야 합니다.

Unsloth의 현재 분석은 UD-IQ1_S 72.5GB, UD-IQ1_M 74.5GB, UD-Q2_K_XL 78.9GB, UD-IQ3_XXS 82GB, UD-Q3_K_XL 90GB, UD-IQ4_XS 93.7GB, UD-Q4_K_XL 111.3GB를 보여 줍니다. 별도 hardware table은 1/2/3/4-bit의 총 메모리를 약 75/79/90/112GB로 요약합니다.

artifact size와 runtime budget은 같지 않습니다. KV cache, compute buffer, OS, client, chat template이 추가됩니다. vision을 쓰면 현재 저장소 기준 약 908MB BF16 projector도 별도로 필요합니다. model load 후 계속 swap이 발생하면 “실행 성공”이 아니라 현재 구성의 실패입니다.

24–48GB급 장비에서 local coding agent가 필요하다면 별도 dense model인 Qwen3.8-27B 로컬 agentic coding 가이드가 더 적절합니다.

모델 이름과 runtime 문제를 분리한다

Qwen/Qwen3.8-Flash-Next는 Qwen4 architecture를 미리 공개한 open-weight multimodal MoE입니다. Gated DeltaNet과 Qwen Sparse Attention을 결합하고 N-gram embedding으로 capacity를 확장합니다.

Qwen3.8-Flash는 Qwen의 managed service입니다. Qwen은 이 제품 버전에 default 1M context와 built-in tool 같은 production feature가 있다고 설명합니다. local GGUF endpoint가 같은 기능을 자동 제공하지 않습니다.

Qwen3.8-27B는 27B dense model입니다. Flash-Next의 작은 quant가 아니므로 memory, parser, benchmark를 서로 복사하면 안 됩니다.

새 모델을 지원하지 않는 오래된 runtime에서 format error가 난다면 메모리를 추가해도 해결되지 않습니다. 반대로 최신 runtime이 model을 읽더라도 cache가 메모리를 넘으면 support 문제처럼 보이는 crash가 생깁니다. 먼저 runtime/version과 실제 model ID를 확인한 뒤 memory pressure를 측정해야 합니다.

Qwen이 공개한 coding, agent, tool-use benchmark는 평가할 이유를 줍니다. 하지만 vendor harness 결과이며, Unsloth 저비트 quant가 여러분의 tool schema를 지키거나 특정 DGX Spark/Mac에서 같은 성능을 낸다는 증거는 아닙니다.

quant alias로 먼저 실행한다

새 architecture를 지원하는 최신 llama.cpp를 사용합니다. Unsloth GGUF 저장소는 quant alias를 제공하므로 shard 이름을 직접 조합하지 않아도 됩니다.

bash
llama serve -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

96GB machine에서는 Q4 example을 그대로 쓰지 말고 published budget에 맞는 low-bit alias로 교체합니다. Unsloth entry point도 사용할 수 있습니다.

bash
unsloth run --model unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

alias가 중요한 이유가 하나 더 있습니다. 확인 시점의 Unsloth manual example은 local directory를 GGFF로 적고, 다음 경로에서 UD-IQ1_S directory와 UD-Q4_K_XL filename을 섞고 있습니다. 문서가 수정될 수 있지만 수동 다운로드 시에는 실제 저장된 파일 목록과 첫 shard 이름을 확인해야 합니다.

context는 8K 또는 16K부터 시작합니다. native 262,144 tokens와 1,000,000 확장 가능성은 model capability이지 로컬 기본값이 아닙니다. 같은 prompt로 context를 단계적으로 올리며 KV cache, prompt processing, swap을 기록합니다.

첫 실행에서 확인할 다섯 가지

1. /v1/models가 응답하고 server가 어떤 model ID를 노출하는지 확인합니다.
2. 짧은 text request로 Flash-Next와 선택한 quant가 맞는지 확인합니다.
3. load 후 free memory, time to first token, steady generation, swap 여부를 기록합니다.
4. 같은 입력을 8K, 16K, 그 이상에서 반복해 context 비용을 측정합니다.
5. agent 용도라면 tool name, typed arguments, tool result, 다음 assistant turn까지 구조가 유지되는지 봅니다.

그 다음 정답을 판정할 수 있는 5–10개 repository task를 여러 quant에 동일하게 줍니다. completion, manual repair, tool failure, wall-clock time을 비교하면 단일 tok/s나 KLD보다 실제 선택에 가깝습니다.

OOM, 지속적인 swap, long prompt 이후 깨진 tool JSON, 과도한 first-token wait는 No-Go입니다. context를 줄이고 quant를 바꾼 뒤에도 기준을 못 넘으면 smaller model로 이동합니다. load 성공만을 목표로 계속 tuning하면 운영 비용만 숨겨집니다.

어떤 경우에 Flash-Next가 맞는가

최소 96GB급 실제 가용 메모리가 있고 low-bit 품질 위험을 받아들이며, large-capacity sparse model의 agentic/long-context 능력을 시험해야 한다면 가치가 있습니다. Q3/Q4 비교에는 다른 메모리 사용 앱을 닫을 수 있는 128GB급이 더 낫습니다.

64GB가 하드 한계이거나 낮은 latency의 상시 assistant가 목적이라면 작은 dense model이 합리적입니다. Flash-Next architecture는 토큰당 계산을 줄이지만 weight와 N-gram embedding 저장 요구를 없애지 않습니다.

다운로드 전에 Qwen 공식 저장소에서 identity와 runtime support를 확인하고 Unsloth 최신 guide에서 quant 정보를 다시 확인하세요. 현재 weight page의 license tag는 qwen-community-1.0입니다. 상업 이용이나 재배포는 tag가 아니라 실제 license text로 판단해야 합니다.