로컬에서 Qwen 3.8 Max를 배포하는 방법: 하드웨어, vLLM, SGLang 및 양자화 가이드

로컬에서 Qwen3.8-Max를 실행하는 것은 이제 가능하지만, “Qwen 3.8 Max 로컬”이라는 표현에는 중요한 주의가 필요합니다. Alibaba의 관리형 Max 제품과 다운로드 가능한 체크포인트는 밀접하게 관련되어 있지만 동일한 제품은 아닙니다.

Qwen은 2026년 8월 초에 관리형 Max 서비스를 먼저 출시했으며, 2026년 8월 12일에 Qwen3.8-2.4T-A95B를 오픈 웨이트로 공개했습니다(https://github.com/QwenLM/Qwen3.8). 이 체크포인트가 실제로 여러분이 자체 인프라에 배포하는 모델입니다.

이 문서는 게이밍 PC에서 Ollama로 돌리는 평범한 튜토리얼이 아닙니다. 비양자화 체크포인트는 2.4조 매개변수의 Mixture-of-Experts 모델이며, 현재 vLLM 레시피는 BF16 가중치 크기를 4.45 TiB로 산정합니다. 프로덕션 지향 4비트 부동소수점 변형도 가중치만 약 1.3–1.5 TiB를 차지합니다.

빠른 답변: 완전한 Qwen 3.8 Max급 자체 호스팅은 데이터센터급 배포입니다. 실무적인 프로덕션 시작점은 8× B300 또는 8× MI355X GPU에서의 FP4 체크포인트이며, H200 배포는 더 많은 GPU가 필요합니다. 일반 워크스테이션이라면 Qwen3.8-27B를 사용하세요.

Qwen 3.8 Max와 실제로 배포하는 오픈 모델의 차이

다운로드 가능한 Qwen3.8-2.4T-A95B 체크포인트는 토큰당 약 95B가 활성화되는 2.4T-파라미터 인과 언어 모델로 공식 설명됩니다. 관리형 Max 서비스는 현재 오픈 체크포인트에 없는 제품 레이어 기능을 추가합니다.

관리형 제품은 텍스트, 이미지, 비디오 입력과 1,000,000 토큰 컨텍스트를 제공합니다. 반면 오픈 체크포인트는 텍스트 전용이며 기본 262,144 토큰 컨텍스트를 갖습니다. 애플리케이션이 멀티모달 입력이나 관리형 내장 도구에 의존한다면 이 차이는 중요합니다.

Qwen 3.8 아키텍처와 사양

CometAPI의 “What is Qwen3.8 Max”에서 모델 배경을 이미 다루므로, 이 배포 가이드는 메모리, 병렬화, 서빙에 영향을 주는 세부 사항에 집중합니다.

공식 Qwen 하이브리드 모델 아키텍처. 참조: SGLang Qwen3.8 배포 가이드.*

“95B 활성 파라미터”를 95B 모델의 메모리 풋프린트로 해석하지 마세요. 희소 활성화는 토큰당 연산량을 줄여주지만, 서빙 시스템은 여전히 전체 익스퍼트 가중치 집합에 접근할 수 있어야 합니다.

Qwen 3.8 Max 벤치마크 스냅샷

CometAPI의 기존 Qwen3.8 Max 개요가 이미 벤치마크를 자세히 다루므로, 본 글은 공식 Qwen 모델 카드의 벤치마크 테이블에서 배포 관련 하위집합만 사용합니다.

Qwen 팀이 공개한 공식 Qwen3.8 성능 그래픽(출처: Qwen 팀).

이 하위집합에서 Qwen3.7-Max 대비 가장 큰 향상은 PaperBench와 FrontierSWE입니다. Qwen3.8-Max는 SWE-bench Pro와 PaperBench에서 GPT-5.6 Sol을 능가하며, Terminal Bench 2.1에서는 GPT-5.6 Sol이 앞섭니다. 배포 결정을 위해서는 이를 역량 맥락으로 보되, 아래의 메모리 및 서빙 처리량 측정치가 운영 관점에서 더 중요합니다.

벤치마크 테이블은 보편적 순위표가 아닙니다. 하니스, 타임아웃, 컨텍스트 한도, 도구 접근, 양자화 여부가 결과를 바꿀 수 있습니다. 실제로 사용할 체크포인트, 정밀도, 서빙 엔진, 프롬프트 분포로 벤치마크하세요.

로컬 배포에 필요한 Qwen3.8 하드웨어는?

Qwen3.8-2.4T-A95B의 GPU 요구사항

이것이 핵심 배포 질문입니다. 현재 vLLM Qwen3.8 레시피는 체크포인트 용량과 런타임 헤드룸을 고려한 현실적인 GPU 수를 공개합니다. 이는 단순히 파라미터 수에서 VRAM을 추정하는 것보다 유용합니다.

대부분의 자체 호스팅 수요가 있는 조직에서는 FP4가 실질적인 시작점입니다. NVIDIA 측의 대표 구성은 8× B300에서의 NVFP4 W4A4이며, AMD 측의 대응 경로는 8× MI355X에서의 MXFP4입니다.

8× H200 서버로는 이러한 권장 풀모델 배포에 충분하지 않습니다. 공식 레시피는 H200에 대해 FP4는 16개, FP8은 32개, BF16은 48개의 GPU를 제시합니다.

Qwen3.8-27B의 VRAM 요구사항

Qwen3.8-27B는 실질적인 워크스테이션급 대안입니다. 순수 가중치 메모리는 BF16에서 약 54 GB, FP8에서 27 GB, 4비트 정밀도에서 13.5 GB 정도입니다. 런타임 오버헤드와 KV 캐시로 실제 요구량은 늘어나며, 특히 긴 컨텍스트에서 그렇습니다.

이 수치는 파라미터 수에서 도출한 계획용 추정치입니다. 프로덕션 하드웨어를 사이징하기 전, 실제 체크포인트, 양자화 형식, 서빙 엔진, 컨텍스트 길이, KV 캐시 설정을 확인하세요.

Qwen3.8을 소비자용 GPU에서 실행할 수 있나요?

풀사이즈 Qwen3.8-2.4T-A95B는 공격적으로 양자화하더라도 일반 소비자 GPU에서는 현실적이지 않습니다. 커뮤니티 프로젝트에서 4대의 DGX Spark 시스템에 걸쳐 397 GB UD-Q1_0의 극단적 압축 빌드를 시연하긴 했지만, 이는 품질 민감 서빙의 기준선이 아니라 실험적 극한 양자화 경로입니다.

워크스테이션이나 홈랩에는 2026년 8월 14일에 오픈 웨이트로 공개된 Qwen3.8-27B가 더 적합합니다. 호스팅 난이도가 몇 자릿수 낮으며, “로컬”이 한 대의 워크스테이션을 의미한다면 이 모델이 올바른 선택입니다.

Qwen 3.8 Max 설치 전 준비 사항

설치 명령을 실행하기 전에 인프라를 설계하세요. Linux, 호환 가속기 스택, 체크포인트를 위한 충분한 로컬/공유 스토리지, 고대역폭 GPU 인터커넥트, 노드를 넘나드는 경우 분산 추론을 위한 네트워크가 필요합니다. vLLM 레시피는 현재 vLLM nightly와 Transformers 5.4.0 이상을 권장합니다.

bash

uv venv
source .venv/bin/activate

uv pip install -U vllm \
  --extra-index-url https://wheels.vllm.ai/nightly

uv pip install -U "transformers>=5.4.0"

vLLM으로 Qwen 3.8 FP8 배포하기

Qwen이 제공한 체크포인트를 사용하면서 멀티 노드 인프라를 감당할 수 있다면 FP8이 합리적인 선택입니다. 공식 체크포인트는 Qwen/Qwen3.8-2.4T-A95B-FP8입니다.

두 노드, 16 GPU B300급 배포에서 헤드 노드는 다음과 같이 실행합니다:

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 0 \
  --master-addr "$HEAD_ADDR" \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3
On the worker node, use the same topology with a different node rank and no API server:

bash

export HEAD_ADDR="10.0.0.10"

vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --tensor-parallel-size 16 \
  --nnodes 2 \
  --node-rank 1 \
  --master-addr "$HEAD_ADDR" \
  --headless \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3

토폴로지를 조정하지 않은 채로 위 16-GPU 예시를 H200 서버에 그대로 적용하지 마세요. 동일한 FP8 변형이라도 vLLM 레시피에서는 현재 H200에 대해 32개 GPU로 사이징되어 있습니다.

1대의 8× B300 서버에서 Qwen 3.8 실행하기

NVIDIA Blackwell에서는 NVFP4가 가장 실용적인 풀모델 구성입니다. vLLM은 현재 8개의 B300 GPU에 걸친 텐서 병렬화와 함께 NVFP4 W4A4를 검증하고 있습니다.

bash

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --kv-cache-dtype fp8 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder

Inferact의 NVFP4 빌드는 원본 BF16 Qwen 아티팩트가 아닌 양자화된 체크포인트입니다. BF16이나 FP8의 대체재로 취급하기 전에, 자체 인수 기준 세트로 모델 품질을 검증하세요.

SGLang으로 Qwen 3.8 배포하기

SGLang은 8월 12일에 Qwen3.8 Day-0 지원을 추가했으며, 고처리량 서빙, 프리픽스 캐싱, Expert 병렬화, Speculative 디코딩, 프리필/디코드 분리(Disaggregation)에 특히 매력적입니다.

bash

SGLANG_ENABLE_MOE_DEFERRED_FINALIZE=1 \
SGLANG_FLASHINFER_MNNVL_CUTEDSL_AR_FUSION=1 \
sglang serve \
  --trust-remote-code \
  --model-path RadixArk/Qwen3.8-2.4T-A95B-NVFP4 \
  --tp-size 8 \
  --context-length 200000 \
  --preferred-sampling-params '{"top_k": 20}' \
  --attention-backend trtllm_mha \
  --linear-attn-prefill-backend flashinfer \
  --linear-attn-decode-backend flashinfer \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder \
  --host 0.0.0.0 \
  --port 30000

SGLang은 TP8 B300에서 MTP 사용 시 배치 사이즈 1 기준 346 토큰/초의 출력 속도를 보고했으며, 분리된 서빙 레이아웃에서는 집계 처리량이 크게 상승합니다. 해당 수치는 모델 품질 벤치마크가 아니라 서빙 스택 측정치로 보세요.

로컬 OpenAI 호환 엔드포인트 테스트

vLLM과 SGLang은 모두 OpenAI 호환 API를 제공하므로 애플리케이션 통합이 간단합니다.

python

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
    timeout=3600,
)

response = client.chat.completions.create(
    model="Qwen/Qwen3.8-2.4T-A95B-FP8",
    messages=[
        {
            "role": "user",
            "content": "Design a fault-tolerant Redis architecture for three regions."
        }
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=8192,
)

print(response.choices[0].message.content)

공식 모델 카드는 기준 샘플링 파라미터로 temperature=1.0, top_p=0.95, top_k=20을 권장합니다. 에이전트형 작업에서는 최종 가시 답변만 고려해 max_tokens를 잡지 말고, 추론을 위한 출력 예산을 충분히 남겨두세요.

1M 컨텍스트 창 활성화

Qwen3.8-2.4T-A95B 오픈 체크포인트는 기본 262,144 토큰 컨텍스트를 가지며, 약 1.01M까지 확장할 수 있습니다. vLLM 레시피는 다음 패턴을 문서화합니다:

bash

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 \
vllm serve Qwen/Qwen3.8-2.4T-A95B-FP8 \
  --max-model-len 1010000 \
  --hf-overrides '{"max_position_embeddings": 1010000}' \
  --reasoning-parser qwen3 \
  ...

지원된다고 해서 1M을 기본값으로 두지 마세요. 더 큰 최대 컨텍스트는 더 많은 캐시 용량을 예약하며 동시성을 급격히 낮출 수 있습니다. 실제 워크로드에 맞춰 --max-model-len을 설정하세요.

Qwen3.8 추론 성능을 높이는 방법

단일 사용자 지연을 줄이려면 MTP-3 사용

Qwen3.8은 Multi-Token Prediction을 지원합니다. vLLM의 공개 측정에서 MTP-3는 FP8 TP16에서 사용자당 출력 속도를 130 → 307 tok/s, NVFP4 TP8에서 133 → 304 tok/s로 올려줍니다.

bash

--speculative-config '{"method":"mtp","num_speculative_tokens":3}'

시작 시간을 줄이려면 fastsafetensors 사용

테라바이트급 모델에서는 시작 시간이 중요합니다. 한 vLLM 측정에서는 fastsafetensors와 지연 로딩으로 가중치 로딩 시간이 545초에서 306초로 줄었습니다.

bash

--load-format fastsafetensors \
--safetensors-load-strategy lazy

동시 처리량을 늘리려면 Expert 병렬화 사용

높은 동시성에서는 Qwen3.8이 512개의 라우팅 익스퍼트를 가지므로 Expert 병렬 레이아웃의 이점을 봅니다. vLLM은 FP8 EP에서 GPU당 최대 3,200 total tok/s, 최적화된 NVFP4 DEP16 구성에서 GPU당 최대 4,300 total tok/s를 보고합니다.

VRAM과 동시성 균형을 위해 --max-model-len 설정

--max-model-len을 워크로드가 진짜로 요구하는 최장 시퀀스에 맞추세요. 더 큰 값은 더 많은 KV 캐시를 예약해 메모리 압박을 높이고, 모델 가중치가 이미 맞더라도 동시 요청 수를 줄일 수 있습니다.

모델이 광고하는 최대 컨텍스트 대신, 실제 프로덕션 백분위에 기반해 시작하세요. 프로덕션에서 사용할 동일한 정밀도, 배치 패턴, 서빙 엔진으로 부하 테스트한 뒤, 실제 요청이 더 긴 컨텍스트를 필요로 할 때만 상향하세요.

Qwen 3.8 Max 로컬 배포 vs. API

오픈 웨이트라고 해서 자동으로 로컬 추론이 경제적이 되는 것은 아닙니다. 올바른 선택은 활용도, 데이터 레지던시, 인력, 가용성 목표, 그리고 관리형 모델의 멀티모달 기능이 실제로 필요한지 여부에 달려 있습니다.

이미 적합한 가속기를 보유하고 있고 활용도가 지속적으로 높다면 자체 호스팅이 타당할 수 있습니다. 이 모델만을 위해 클러스터를 새로 구매해야 한다면, 보통은 CometAPI의 Qwen3.8-Max가 마찰이 더 적은 경로입니다. 기존 API 가이드는 관리형 통합을, 가격 가이드는 비용 모델링을 다루므로, 본 문서는 로컬 배포에 집중합니다.

Qwen 3.8 로컬 배포의 흔한 문제

시작 중 서버가 GPU 메모리 부족으로 종료됨

캐시 이슈라면 먼저 --max-model-len을 줄이세요. 가중치 자체가 맞지 않는다면 컨텍스트 축소로 근본 원인은 해결되지 않습니다. 검증된 더 낮은 정밀도 체크포인트로 전환하거나 GPU를 추가하세요.

텐서 병렬화 크기 오류로 실패함

Qwen3.8에는 풀어텐션 레이어에 64개의 어텐션 헤드가 있으므로, vLLM은 TP가 64를 나눠야 한다고 요구합니다. 간단한 TP 크기는 1, 2, 4, 8, 16, 32입니다. 단순 합산 VRAM만으로 토폴로지를 정할 수 없습니다.

서버 시작에 시간이 오래 걸림

수 TB의 가중치 로딩과 커널 JIT에는 수분이 걸릴 수 있습니다. VLLM_ENGINE_READY_TIMEOUT_S를 늘리고, 짧은 시작 시간을 가정하기보다 실제 추론 엔드포인트를 프로빙하세요.

로컬 모델이 이미지를 처리하지 못함

그렇습니다. Qwen3.8-2.4T-A95B 오픈 체크포인트는 텍스트 전용입니다. 이 제한은 Qwen3.8-2.4T-A95B에 특화된 것입니다. Qwen3.8-27B는 별도의 비전 프로젝션 파일을 로드하면 시각 입력을 지원합니다.

1M 컨텍스트로 처리량이 급감함

--max-model-len을 워크로드가 실제로 필요로 하는 최대 길이로 줄이세요. 지원되는 최대 컨텍스트 창이 최적의 프로덕션 설정을 의미하지는 않습니다. 워크로드 요구, KV 캐시 사용, 동시성의 균형을 맞춘 컨텍스트 한도를 선택하세요.

Ollama나 LM Studio로 Qwen 3.8 Max를 실행할 수 있나요?

에코시스템은 라마.cpp 스타일 추론을 위해 강하게 양자화된 Qwen3.8 가중치를 패키징할 수 있지만, 이를 일반 데스크톱의 정상적인 Ollama 워크플로와 혼동해서는 안 됩니다. 수백 GB를 차지하는 양자화 빌드는 여전히 수백 GB의 접근 가능한 메모리를 필요로 하며, 품질과 성능에서 상당한 트레이드오프를 수반합니다.

일반적인 로컬 개발에는 Qwen3.8-27B가 적절한 대상입니다. 극단적인 커뮤니티 양자화로 비정상적 하드웨어에서 기술적으로 부팅 가능하더라도, 2.4T 풀모델은 서버/클러스터 모델로 취급해야 합니다.

어떤 배포 방법을 선택해야 하나요?

NVIDIA Blackwell에서는 8× B300 NVFP4 배포가 현재 가장 깔끔한 풀모델 시작점입니다. AMD에서는 8× MI355X의 MXFP4가 대응되는 실용적 구성입니다. 체크포인트 출처와 품질을 인프라 규모보다 우선한다면 FP8을, 최대 충실도가 다중 랙급 메모리 요구를 정당화할 때만 BF16을 사용하세요.

워크스테이션에는 Qwen3.8-27B를 사용하세요. GPU 클러스터 운영 없이 Max 기능이 필요한 애플리케이션 팀이라면 관리형 CometAPI의 Qwen3.8-Max 모델을 사용하세요.

결론

Qwen3.8-Max는 초기 API 출시 이후 중요한 경계를 넘어섰습니다. 이제 조직이 자체 인프라에서 완전히 운영할 수 있는 2.4T 오픈 체크포인트가 등장했습니다.

하지만 오픈 웨이트가 곧 소비자 하드웨어를 의미하는 것은 아닙니다. 4.45 TiB의 BF16 풋프린트, 2.27 TiB FP8 체크포인트, 1.3–1.5 TiB FP4 변형은 Qwen3.8-2.4T-A95B를 가장 인프라 집약적인 오픈 모델 중 하나로 만듭니다. 실무적 측면에서는 vLLM과 SGLang이 이미 아키텍처를 지원하고, FP4 덕분에 1노드 8× B300 또는 8× MI355X 배포가 가능하다는 점이 장점입니다.

데이터 통제, 지속적 활용, 인프라 소유가 클러스터를 정당화할 때 자체 호스팅을 선택하세요. 그렇지 않다면 관리형 Max API를 사용하거나, 한 대 워크스테이션에서 강력한 Qwen 모델이 필요하다면 Qwen3.8-27B를 사용하세요.