Qwen3.8-Flash-Next-Uncensored-FP8 서빙: block-FP8 빌드를 위한 vLLM 런북

Qwen3.8-Flash-Next-Uncensored-FP8 — abliterated Flash-Next의 block-FP8 빌드 — 는 데이터센터 하드웨어에서 이 모델을 서빙할 때 실제로 다운로드하게 되는 아티팩트이며, 컬렉션에서 자체 런북(runbook)이 마지막으로 추가된 항목입니다. 이 모델은 다음 위치에 있습니다: orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 — Hugging Face에서 제공됩니다. Qw​en의 Qwen3.8-Flash-Next에서 거부 방향을 제거한 다음, 공식 Qwen3.8-Flash-Next-FP8의 정확한 FP8 스킴으로 오프라인 재양자화하여 vLLM이 동일한 커널 경로로 서빙합니다. Hopper급 이상 GPU에서 이 모델을 실행하는 모든 사람이 선택하게 될 빌드이며, 서빙 경로에는 잘못 설정하기 쉽고 막상 그러면 진단하기 어려운 플래그가 하나 있습니다.

{{1}}먼저, 경계에 대해 말하겠습니다. 독자들이 계속 이 경계를 흐리게 보는데, 이 경계가 아래의 모든 내용을 바꾸기 때문입니다.{{/1}} {{2}}Qwen3.8-Flash-Next-Uncensored와 Qwen3.8-27B-Uncensored는 서로 다른 두 모델입니다. 하나의 모델에 대한 두 빌드가 아닙니다.{{/2}} {{3}}기본 가중치가 다릅니다 — Qwen3.8-Flash-Next는 Qwen3.8-27B와 대비됩니다 — 아키텍처도 다르고, 가중치 드롭도 다르며, Hugging Face 컬렉션도 다릅니다.{{/3}} {{4}}두 모델이 공유하는 것은 abliteration 기법과 계열 이름뿐입니다. 그게 전부입니다.{{/4}} {{5}}27B 페이지의 수치 중 어느 것도 이 모델에 적용되지 않습니다. 27B 검색을 통해 이 페이지에 도착했다면, 27B 자체의 로컬 런북은 별도의 페이지이며 별도의 결정 사항을 담고 있습니다.{{/5}}

이 페이지는 Flash-Next FP8 서빙 페이지이며 그 외의 것은 아닙니다. GGUF/MLX 런북은 이 모델에 대한 abliteration 설명과 두 가지 소비자 하드웨어 빌드 라인을 다룹니다; 전체 제품군의 배후 기술은 abliteration 입문서와 더 광범위한 uncensored-LLM 설명서에 설명되어 있습니다; 그리고 안내받았을 수 있는 형제 모델인 Qwen3.8-27B-Uncensored-FP8은 자체 FP8 런북을 갖고 있습니다. 여기서 우리는 오직 한 가지 질문에 집중합니다: block-FP8 빌드를 어떻게 서빙하는지, 잘못했을 때 무엇이 깨지는지, 그리고 카드 자체의 숫자가 무엇을 말해주고 무엇을 말해주지 않는지입니다.

시작하기 전에: 게이트와 런타임

이 저장소를 게이트하는 두 가지가 있으며, 둘 다 다른 무언가처럼 보이는 실패를 발생시킵니다.

첫 번째는 접근입니다. 저장소는 접근 제한이 있습니다. 다운로드가 작동하려면 Hugging Face에 로그인하고 저장소의 이용약관에 동의해야 합니다. 모델 페이지 자체는 계정 없이도 읽을 수 있습니다. 전체 카드 설명은 공개되어 있지만, 가중치는 그렇지 않습니다. 분명히, 약관에 동의한 로그인 세션이 없으면 `hf download` 및 `vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8` 둘 다 인증 오류로 실패합니다. "동의를 클릭하세요"라는 친절한 안내가 아니라요. 먼저 일회성 클릭 동의를 한 다음, hf CLI로 ~186GB를 내려받거나, vLLM이 첫 실행 시 저장소를 해결하도록 하세요.

두 번째는 런타임입니다. 체크포인트는 qwen4_exp 아키텍처(Qwen4ExpForConditionalGeneration)로 등록되는데, 기본 vLLM과 기본 Transformers로는 로드할 수 없습니다. day-0 vLLM 이미지와 transformers 5.16+가 필요합니다. 이번 주 커뮤니티 런북 전반에서 가장 흔하게 나타난 '로드가 안 된다'는 실패는 손상된 다운로드가 아니라, 아키텍처보다 이전의 런타임 때문입니다. 그 이미지는 선택 사항이 아닙니다. 그것이 곧 해결책입니다.

하드웨어 관련 사항이므로, 무엇이든 가져오기 전에 계획을 세울 수 있습니다: 카드의 호출은 8-GPU 노드를 대상으로 하며, 공식 vLLM 레시피의 FP8 체크포인트에 대한 지침은 빌드가 텐서 단위로 일치하므로 여기에도 적용됩니다 — 풀 노드 배포 시 약 265GB의 GPU VRAM이 필요하며, TP2는 GB300급에서 최소 구성으로 간주되고 TEP4/TEP8은 검증된 풀 트레이 구성입니다.

FP8 빌드가 존재하는 이유 — 그리고 '동일한 커널 경로'가 바로 핵심이다

abliterated BF16 가중치가 기준(source of truth)이며, {{1}}이 저장소는 해당 모델을 오프라인으로 재양자화한 버전으로, 공식 Qwen3.8-Flash-Next-FP8 레시피를 의도적으로 재현합니다.{{/1}} 양자화기는 512개의 routed-expert 프로젝션(experts.{e}.down/gate/up_proj)에만 적용되며, 이들을 BF16 빌드의 3D 레이아웃에서 분리(un-fusing)하여 각각을 128×128 블록 단위의 float8_e4m3fn 가중치와 BF16 weight_scale_inv 스케일로 저장합니다. {{2}}활성화는 토큰별 동적 FP8이며, 캘리브레이션 세트가 없습니다.{{/2}} 나머지는 모두 BF16으로 유지됩니다: attention 및 linear_attn, shared expert, MoE 라우터(mlp.gate), Hyper-Connection 믹서, embeddings, lm_head, MTP speculative-decoding 헤드, 그리고 전체 vision tower.

“동일한 커널 경로”라는 표현은 단순한 마케팅 이상이며, 한 문장으로 설명할 가치가 있습니다. 이 빌드는 공식 FP8 체크포인트와 대조 검증되었습니다: 블록 스케일이 정확히 재현되고 (scale_relerr = 0), FP8 코드는 sub-ULP 반올림 수준으로 일치합니다. 그래서 vLLM은 공식 릴리스와 동일한 block-scaled FP8 커널과 동일한 MTP 추측 디코딩을 사용하여 이를 실행합니다 — 텐서는 사실상 동일한 텐서이며, refusal 방향만 제외된 것입니다.

구체적으로는 131개 샤드에 걸쳐 약 186GB(152,089개 텐서 중 75,264개가 FP8), 네이티브 컨텍스트 262,144토큰, 바이트 단위로 그대로 보존된 비전+비디오 타워(333개의 visual.* 텐서), 그리고 온전한 MTP 헤드를 얻게 됩니다. 가중치에는 먼저 abliteration이 적용되었습니다. 즉, 레이어 24에서 추정된 단일 거부 방향을 float32의 149개 잔차 기록(residual-writing) 텐서에서 직교화하여 제거했고(Arditi et al., 2024), MTP 헤드의 잔차 기록자들도 일관되게 편집하여 추측적 디코딩(speculative decoding)이 계속 작동하게 했습니다. 이 마지막 세부 사항은 자명하지 않으며, 디코딩을 가속화하는 헤드와 조용히 성능을 저하시키는 헤드를 구분 짓는 차이입니다.

로드의 성패를 결정짓는 유일한 플래그

이 빌드를 --enable-expert-parallel 없이 서빙하면 구성 오류가 아니라 셰이프 버그처럼 보이는 실패가 발생합니다. 이는 이 체크포인트에서 가장 많이 보고된 서빙 실패이며, 완전히 결정적으로 발생합니다.

여기 산술이 있습니다. 라우팅된 전문가들의 융합된 게이트+업 프로젝션의 중간 크기는 640입니다. Block-FP8은 128폭 블록으로 양자화합니다. 일반적인 텐서 병렬 처리에서 그 640은 랭크들에 걸쳐 분할됩니다 — 640 ÷ TP — 그리고 일반적인 TP 차수(2, 4, 8)에 대해 랭크당 슬라이스는 128로 나누어떨어지지 않습니다: TP8은 80, TP4는 160, TP2는 320이 됩니다. 그러면 vLLM은 형태 불일치처럼 보이는 오류와 함께 가중치 로드를 거부합니다: 게이트 및 업 가중치의 output_size = 80은 가중치 양자화 block_n = 128로 나누어떨어지지 않습니다.

전문가 병렬 처리는 전문가 가중치를 텐서 병렬 순위 대신 전문가 병렬 순위에 걸쳐 샤딩함으로써 이 문제를 해결하며, 이를 통해 FP8 블록 경계가 보존됩니다. 이것이 이 빌드에서 해당 플래그가 필수인 이유입니다. --enable-expert-parallel을 사용하면 TP8이 작동하는 TEP8이 됩니다. (보존해야 할 FP8 블록이 없는 BF16 빌드에서는 무해합니다.) 공식 vLLM 레시피는 일반 TP8이 체크포인트의 128폭 양자화 블록과 호환되지 않는다고 명시하며, 가중치가 공개된 지 이틀 후 제기된 vLLM 이슈는 8×L40s 노드에서 TP2, TP4, TP8 모두 동일한 실패를 기록하고 있습니다. 로드가 형태 관련 오류로 중단되면 다운로드를 확인하기 전에 플래그를 확인하세요.

정확한 명령

다음은 카드의 Docker 호출을 충실히 재현한 것입니다:

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

명확하지 않은 플래그를 검토하십시오:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — day-0 qwen4_exp 이미지입니다. 이것은 일반적인 vLLM이 아닙니다. 아키텍처별 이미지이며, qwen4_exp 이전의 기본 이미지는 체크포인트를 전혀 로드할 수 없습니다.

• --trust-remote-code — 저장소에 포함된 qwen4_exp 모델링 코드를 로드합니다. 이 옵션이 없으면 로더는 원칙적으로 거부합니다.

• --max-model-len 262144 — 기본 컨텍스트 창과 일치합니다. 기본값으로 남겨 두기보다는 여기에 명시적으로 지정하는 것이 좋습니다.

• --enable-expert-parallel — FP8 빌드에 필요합니다. 위 섹션에서 설명한 이유 때문입니다. 카드에는 BF16에는 무해하다고 명시되어 있습니다.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — Qwen3-Coder XML 형식을 사용하여 도구 및 함수 호출을 활성화합니다. 이 옵션을 끄면 모델은 여전히 대화할 수 있지만, 에이전트 도구 사용은 비활성화됩니다.

• --tensor-parallel-size 8 — 이 카드는 8-GPU 노드(8× Hopper급)를 가정합니다. --enable-expert-parallel을 사용하면 TEP8 배포입니다.

컨테이너가 실행되면 엔드포인트는 :8000/v1에서 OpenAI와 호환됩니다. --served-model-name을 클라이언트가 기대하는 값으로 설정하세요. 카드는 Qwen3.8-Flash-Next-Uncensored를 사용합니다.

대안들, 모두 이번 주에 카드에 있거나 실무자들에 의해 입증된 것들: HF 세션이 인증되면 vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8을 직접 실행; lmsysorg/sglang:qwen38flashnext 이미지를 통해 SGLang을 --tp 8 --ep 8로 사용 — 동일한 전문가 병렬 요구 사항, 동일한 이유; 그리고 모델을 서빙하는 대신 스크립트로 다루고 싶다면 transformers 5.16+에서 pipeline("image-text-to-text", ...)을 사용하는 Transformers.

실제로 서빙할 때 효과가 있는 것

이 섹션의 패턴은 이번 주 실무자 런북과 포럼 스레드에서 수집된 커뮤니티 발견 사항이며, 벤더 지침이 아닙니다. 둘 이상의 설정이 동일한 동작을 보고하는 경우, 실제 현상으로 취급할 가치가 있습니다:

• MTP 추측 디코딩이 작동합니다. --speculative-config '{"method":"mtp","num_speculative_tokens":3}'를 추가하면 vLLM이 보존된 MTP 헤드를 사용합니다. 여러 런북에서는 이 모델의 디코딩이 크기에도 불구하고 계속 사용 가능한 상태를 유지하는 이유로 MTP를 꼽습니다.

• 로드 중 OOM이 발생하나요? n-gram 테이블을 오프로드하세요.이 아키텍처에서 51B 파라미터 PLE n-gram 임베딩이 메모리 사용량의 예상치 못한 주범입니다. VLLM_PLE_CPU_OFFLOAD=1은 이를 호스트 RAM으로 옮기므로, 해당 공간에 최소 ~51GB를 확보하세요. 공식 레시피와 커뮤니티 멀티노드 런북 모두 이 플래그를 사용합니다.

• 비전은 실제이며, 퇴화된 잔재가 아닙니다. 비전+비디오 타워가 바이트 단위로 그대로 보존되어 완전한 비전-언어 모델로 유지됩니다. 채팅 완성에서 image_url 콘텐츠 부분을 전달하면 동일한 엔드포인트가 이미지 이해 기능을 제공합니다. 이 빌드에 대한 커뮤니티 OCR 테스트는 깨끗하게 통과했다고 보고합니다.

• 추론은 기본적으로 켜져 있습니다 — 그리고 이는 안전성 구도를 바꿉니다. 채팅 템플릿은 달리 지정하지 않는 한 추론을 활성화합니다. 요청별로 chat_template_kwargs={"enable_thinking": true|false}를 사용하여 전환하고, 추론 텍스트를 답변과 분리하려면 추론 파서를 추가하세요. 이 기본값 때문에 명시적으로 끄지 않는 한 거의 항상 추론이 켜진 모델을 서빙하게 됩니다.

• 기본 262K, rope 오버라이드 시 1M.기본 컨텍스트는 262,144 토큰입니다. 1M까지 확장하려면 명시적인 YaRN rope 스케일링 오버라이드와 vLLM의 max-model-len 상한을 해제하는 환경 변수가 필요합니다. 그리고 먼저 짧은 컨텍스트 품질을 회귀 테스트해야 합니다. 맹목적인 4배 확장은 장문 컨텍스트 품질이 대개 저하되는 지점이기 때문입니다.

카드의 숫자가 말하는 것 — 그리고 말하지 않는 것

이는 공급업체가 자체 편집본에 대해 실시한 자체 측정치로, 모델 카드에 게재되었으며, 동일한 스크립트와 설정으로 vLLM을 통해 서빙된 이 정확한 가중치를 공식 베이스와 비교해 측정한 것입니다. 이를 있는 그대로 보고하십시오: 참고용 수치이며 독립적인 감사가 아닙니다.

핵심은 thinking(추론)을 끈 상태에서 거부 반응이 붕괴된다는 것입니다. 카드의 유해 프롬프트 스위트에서 (벤치마크당 n=50~150), 기본 모델의 거부율은 64–100%이고 이 빌드는 0–2.7%입니다: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7%, 그리고 맞춤형 중국어/영어 프로브 63.6%→0.0%.

이제 정직한 절반을 보자. 베이스 모델 자체의 거부율은 추론을 활성화하면 급락한다. AdvBench는 베이스에서 100%에서 추론을 켜면 7.0%로 떨어진다. 따라서 추론을 켠 상태의 비교는 훨씬 덜 극적이다. 이 빌드는 동일한 스위트에서 0.0%를 기록하지만, 이는 베이스가 이미 줄여놓은 수치에서 아주 작은 숫자를 깎는 것에 불과하다. 추론을 끈 수치만 인용한다면 이야기에서 유리한 절반만 제시하는 것이며, 안전 평가가 바로 그 절반에 의존해서는 안 된다.

정상 프롬프트에 대한 과도한 거부(XSTest-safe, n=250)는 기본 모델의 9.6%에서 이 빌드에서는 thinking을 끈 상태로 1.2%까지 떨어집니다. 정상 프롬프트를 거부하는 모델이 더 조용한 실패 방식이기 때문에 이는 실질적인 개선입니다. MMLU / MMLU-Pro / GSM8K / CMMLU에서의 성능 유지율은 각각 −2.0, −1.2, −1.3, −0.6포인트의 변화를 보여주며, 이는 한 방향을 직교화하는 것이 일반 능력에 거의 비용이 들지 않는다는 주장과 일치합니다. 도구 호출, 비전/OCR, 추론은 모두 이 빌드에서 작동하는 것으로 보고되었습니다.

위의 모든 내용에는 두 가지 주의사항이 따른다. 거부 지표는 규칙 기반의 시작 문구 분류기에서 나온 수치로, 카드 자체에서도 LLM 심사자나 공식 발표 수준의 숫자라기보다 참고 지표라고 밝히고 있다. 인간 패널이나 심사 모델은 이와 똑같은 수치를 재현하지 못할 것이다. 그리고 주의사항 열이 중요하다. thinking-off 스위트에서는 이 빌드의 출력 가운데 대략 절반에서 4분의 3이 여전히 짧은 면책 문구로 시작한 뒤에야 요청을 이행한다. 이 모델은 좀처럼 거부하지 않는다. 그저 얼버무릴 뿐이다. 여기서 '무검열'은 답변을 한다는 뜻이지, 서두 없이 곧바로 답변한다는 뜻이 아니다.

안전 섹션은 단순한 형식이 아닙니다.

"웨이트를 당기기 전에 이걸 읽으세요, 하고 나서가 아니라."

이 모델은 안전 정렬이 상당 부분 제거되었으며, 그 메커니즘은 구체적입니다. 즉, 잔차 스트림에서 단일 거부 방향이 추정되어 float32로 계산된 모든 잔차 기록 행렬(총 149개)에서 직교화를 통해 제거되었습니다. 그 결과는 부수적인 것이 아니라 명시적으로 고지된 것입니다. 모델 카드는 기본 Qwen3.8-Flash-Next가 거부했을 유해하거나, 비윤리적이거나, 공격적이거나, 불법적인 요청에 이 모델이 응할 것이며, 의미 있는 내장 안전장치가 없음을 노골적으로 밝히고 있습니다. 이 모델은 오직 합법적인 연구(해석 가능성, AI 안전성 및 거부 메커니즘 연구, 레드티밍, 견고성 평가, 통제된 실험)를 위해서만 공개되었으며, 사용자는 모델이 생성하는 결과물에 대한 전적인 책임과 법적 책임을 부담합니다. Apache 2.0은 가중치로 수행할 수 있는 작업을 규율합니다.

정확히 해야 할 두 가지가 있습니다. 이 빌드에서는 실수하기 쉽기 때문입니다.

첫째, 이 모델에 대해 “성공하는” 탈옥 프로브는 안전 평가 통과가 아니다. 그것은 광고된 동작이다. 평가의 주장이 “이 모델의 안전이 우회되었다”는 것이라면, 당신은 취약점을 측정한 것이 아니라 설계를 측정한 것이다. 진짜 발견은 abliteration을 견디는 거부 반응이나 능력 회귀일 것이다 — 그리고 카드의 수치는 둘 다 드물다는 것을 시사한다.

둘째, 보존된 공격 표면은 텍스트보다 넓다. 비전 타워는 바이트 단위로 그대로 유지되고 도구 호출도 작동하므로 이미지 입력과 에이전트 사용이 모두 활성화되어 있다. 텍스트 프롬프트만 검사하는 레드팀 계획은 이 모델이 실제로 노출하는 양식을 놓친다. 그리고 위의 거부 수치는 공급업체 자체 편집에 기반한 규칙 기반 분류기에 불과하며, 안전을 포함한 그 어떤 것에 대한 독립적 감사가 아니다.

자체적인 안전, 중재, 악용 방지 계층을 직접 추가하지 않고 이 제품을 최종 사용자에게 배포하거나 프로덕션에 배포하지 마십시오. 저장소의 약관이 이를 명확히 말하며, 이는 형식적인 문구가 아닙니다. 출력물은 업로더나 Qw​en / Ali​baba의 견해를 반영하지 않습니다.

비교를 위한 검열된 기준선을 얻는 방법

당신이 하는 일이 거부 메커니즘 연구나 레드티밍이라면, 델타를 측정하기 위해 이 모델의 검열된 대응 버전—즉, 편집이 없는 동일한 아키텍처—을 나란히 두고 싶을 것이 거의 확실합니다. 이 검열되지 않은 빌드는 설계상 로컬 전용입니다. 저장소는 접근이 제한되어 있고 호스팅된 추론 배포가 없으며, 이는 민감한 페이로드가 제3자 API를 거치지 않도록 하기 위한 의도적인 조치입니다.

호스팅된 기준선의 경우, OrcaRouter는 Qwen 라인을 공급업체 목록 가격으로, 마크업 없이 라우팅합니다. Qwen3.8-Flash는 입력 토큰 100만 개당 $0.15, 출력 토큰 100만 개당 $0.47이며, 그대로 전달되고 자동 장애 조치와 200개 이상의 모델용 단일 키를 제공합니다. 공급업체 가격 변경은 당일에 반영됩니다. 이 빌드를 실행할지 여부나 이 빌드가 스택에서 얼마나 많은 부분을 처리할 수 있는지 고민 중이라면, 이는 추가 계약이나 추가 코드베이스 없이 검열된 버전을 비교 평가할 수 있는 저렴한 방법입니다.

여기서 시작하세요

결정 요약. 필요 사항: 저장소 이용 약관에 동의한 Hugging Face 계정; Hopper급 이상의 노드 — 모델 카드의 명령은 8개 GPU를 대상으로 하며, 공식 레시피의 안내에 따르면 해당 FP8 체크포인트에 대해 약 265GB의 GPU VRAM이 필요합니다; day-0 vLLM 이미지와 transformers 5.16+; 그리고 가중치용 디스크 약 186GB.

실행 순서: 저장소 약관에 동의 → 가중치 다운로드 → day-0 이미지 가져오기 → --enable-expert-parallel 플래그로 서버 실행 → :8000/v1/chat/completions에 요청을 보내 검증 → 그런 다음 평가를 시작하세요. 로드가 shape 관련 오류로 실패하면 다운로드를 확인하기 전에 플래그를 먼저 확인하세요.

그리고 프레임을 유지하십시오. 이것은 연구 도구이며, 그러한 조건으로 공개된 것입니다. 그 숫자들은 공급업체가 자체 편집본에서 측정한 지표상의 수치에 불과합니다. 안전 관련 동작은 이 실험의 핵심이지, 우회해야 할 버그가 아닙니다. 그것을 서비스하고, 측정하고, 그것과 인간 사이에 자체적인 중재 장치를 두십시오.

Flash-Next의 5가지 빌드(BF16, GGUF, MLX, FP8, NVFP4)는 모두 Hugging Face의 Qwen3.8-Flash-Next-Uncensored 컬렉션에 모여 있습니다.

이것의 또 다른 빌드가 아니라 다른 모델입니다: Qwen3.8-27B-Uncensored는 다른 베이스에서 abliteration되었으며, 자체 컬렉션과 자체 런북을 보유하고 있습니다.

이 가중치는 설계상 로컬 전용입니다. abliterated 빌드를 측정하기 위한 호스팅 기준선으로서, Qwen3.8-Flash는 OrcaRouter에서 공급업체 목록 가격에 0% 마크업으로 제공됩니다 — 안전 정렬이 그대로 유지된 기본 모델입니다.