Qwen3.8을 SageMaker HyperPod에 배포하는 방법

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

이 글은 2.4T 파라미터와 토큰당 95B 활성 파라미터를 가진 Qwen3.8-2.4T-A95B를 Amazon SageMaker HyperPod의 ml.p6-b300 인스턴스에 vLLM으로 배포하는 절차를 다룹니다. NVFP4 양자화로 가중치를 약 1.2TB까지 줄이고 8개의 NVIDIA B300 GPU에 적재하며, HyperPod Inference Operator가 모델 다운로드와 GPU 할당, 상태 점검, endpoint 수명주기를 Kubernetes manifest 하나로 관리합니다. Qwen3.8의 Gated DeltaNet과 Gated Attention을 결합한 구조는 긴 컨텍스트에서 메모리 증가를 제한하고, 내장 reasoning, tool calling, Multi-Token Prediction을 통해 agentic workload를 처리합니다. 512개 요청과 동시성 32 조건의 실험에서는 TP와 EP에 MTP를 함께 적용했을 때 TTFT가 59.7% 줄고 요청 지연 시간이 12.2% 감소했으며 출력 처리량이 12.6% 늘었습니다.

섹션별 상세

Qwen3.8-2.4T-A95B는 Qwen-Max급 모델의 open-weight 공개판으로, 전체 2.4T 파라미터 중 토큰마다 약 95B만 활성화합니다. 512개의 routed expert와 1개의 shared expert를 둔 fine-grained MoE가 입력마다 10개의 routed expert를 선택해 전체 모델 용량과 실제 계산량을 분리합니다. 262,144토큰의 native context와 1,010,000토큰까지 확장 가능한 길이는 여러 차례의 tool output, 코드, reasoning trace를 누적하는 agentic workload에 맞춰져 있습니다.

Qwen3.8은 92개 층을 Gated DeltaNet과 Gated Attention의 혼합 구조로 구성합니다. 69개의 Gated DeltaNet 층은 고정 크기 recurrent state를 유지하고 23개의 Gated Attention 층만 full attention으로 토큰 간 정밀한 상호작용을 처리하므로, 컨텍스트가 길어질 때 모든 층의 KV-cache가 함께 증가하지 않습니다. 이 구조는 긴 문서 분석과 장기 계획에서 메모리 부담을 제한하지만, full attention 층의 KV-cache와 활성값을 위한 GPU 여유 공간은 여전히 필요합니다.

2.4T 파라미터를 BF16으로 저장하면 가중치만 약 4.8TB가 필요해 단일 8-GPU 노드에 들어가지 않습니다. NVFP4 W4A4 양자화는 가중치 크기를 약 1.2TB로 낮추며, 총 2.1TB의 HBM3e를 제공하는 ml.p6-b300.48xlarge의 8개 NVIDIA B300 GPU에 KV-cache와 활성값을 위한 공간을 남깁니다. 글의 추정치에서는 recurrent state에 약 50–100GB, 활성값과 framework overhead에 약 100–200GB, batching과 긴 컨텍스트에 약 500–700GB의 여유 공간을 배정합니다.

Amazon SageMaker HyperPod는 Amazon EKS를 control plane으로 사용하면서 GPU 드라이버와 네트워크, 스토리지, NVIDIA device plugin의 인프라 수명주기를 관리합니다. Inference Operator의 InferenceEndpointConfig에 모델 위치, 컨테이너 이미지, GPU 요청량, vLLM 인자를 선언하면 모델 다운로드, 스케줄링, readiness gate, rolling update, KEDA 기반 autoscaling이 이어집니다. ml.p6-b300.48xlarge는 on-demand로 제공되지 않으므로 Flexible Training Plan으로 용량을 예약하고 계획의 Availability Zone과 worker group 설정을 맞춰야 합니다.

Amazon EKS가 Amazon SageMaker HyperPod 클러스터의 orchestration을 담당하고, HyperPod Inference Operator와 ALB Controller, KEDA가 모델 endpoint 운영을 지원하는 구조도입니다. — Diagram왼쪽의 Data Scientists와 Client Applications가 Amazon EKS와 Application Load Balancer를 통해 HyperPod 클러스터의 GPU 노드로 요청을 전달합니다. 클러스터 내부에서는 Inference Operator가 배포를 관리하고 FSx for Lustre가 파일을 제공하며, Amazon Managed Service for Prometheus와 Amazon CloudWatch의 지표가 autoscaling과 관측 기능으로 연결됩니다.

vLLM 설정은 TP=8로 모델을 8개 GPU에 분할하고 NVFP4와 fastsafetensors를 사용해 메모리 적재와 시작 시간을 조정합니다. reasoning parser는 reasoning_content와 최종 content를 분리하고, tool-call parser와 auto tool choice는 모델이 reasoning 후 별도의 구조화된 함수 호출을 내보내게 하며 strict JSON schema로 인자 형식을 제한합니다. 내장 MTP는 별도의 draft model 없이 draft head가 다음 토큰을 예측한 뒤 본 모델이 검증하도록 하며, 기본값인 speculative token 1개에서 acceptance rate를 관찰한 후 2–3개로 늘리는 방식이 권장됩니다.

단일 p6-b300 노드의 벤치마크는 입력 1,024토큰, 출력 1,024토큰, 512개 요청, 동시성 32 조건에서 TP, MTP, EP 조합을 비교했습니다. TP+MTP는 TTFT를 58.7%, 요청 지연을 7.0% 줄이고 출력 처리량을 6.2% 높였으며, TP+EP+MTP는 각각 59.7% 감소, 12.2% 감소, 12.6% 증가를 기록했습니다. MTP는 decode 지연을 줄이고 EP는 expert dispatch overhead를 줄이는 상호보완적 역할을 하므로, 글은 production 환경에서 두 기능을 함께 켜는 구성을 권장합니다.

Qwen3.8의 TP, TP+MTP, TP+EP, TP+EP+MTP 설정을 기준 구성 대비 TTFT, 요청 지연, 출력 처리량으로 비교한 막대그래프입니다. — ChartTP+MTP는 TTFT 감소 58.7%, 요청 지연 감소 7.0%, 출력 처리량 증가 6.2%를 기록하고, TP+EP+MTP는 각각 59.7%, 12.2%, 12.6%의 가장 큰 개선을 보입니다. 그래프는 MTP가 TTFT 개선을 주도하고 EP를 함께 적용하면 지연과 처리량 측면의 추가 이득이 생긴다는 벤치마크 결과를 시각화합니다.

용어 해설

Mixture of Experts: — Mixture of Experts는 하나의 거대한 모델을 여러 Expert로 나누고 입력 토큰마다 일부 Expert만 선택해 계산하는 구조입니다. Qwen3.8은 512개의 routed expert와 1개의 shared expert를 사용하며 토큰마다 10개의 routed expert를 활성화합니다. 전체 파라미터는 2.4T이지만 실제 추론에는 약 95B만 참여해 계산량과 서빙 비용을 줄입니다.
NVFP4 양자화(NVFP4): — NVFP4는 가중치와 활성값을 4비트 수준으로 표현하는 NVIDIA의 양자화 형식입니다. Qwen3.8의 가중치 메모리를 BF16 기준 약 4.8TB에서 약 1.2TB로 줄여 8개의 B300 GPU가 제공하는 총 2.1TB 메모리에 적재할 수 있게 합니다. 낮아진 메모리 사용량은 KV-cache와 활성값을 위한 공간을 남깁니다.
Multi-Token Prediction: — Multi-Token Prediction은 모델에 내장된 draft head가 다음 여러 토큰을 먼저 예측하고 본 모델이 한 번의 forward pass에서 이를 검증하는 speculative decoding 방식입니다. Qwen3.8은 별도의 draft model 없이 이 기능을 사용할 수 있습니다. 실험에서는 draft token 1개만으로 TTFT가 TP 기준보다 58.7% 줄었습니다.
Tensor Parallelism: — Tensor Parallelism은 하나의 모델 계산을 여러 GPU에 나눠 각 GPU가 텐서의 일부를 처리하는 방식입니다. 이 글의 기본 설정은 TP=8로, 2.4T 파라미터 모델을 p6-b300 인스턴스의 8개 B300 GPU에 분산합니다. Expert Parallelism과 결합하면 MoE Expert 분배 방식을 별도로 조정할 수 있습니다.
KV-cache: — KV-cache는 이전 토큰의 Key와 Value를 저장해 긴 대화에서 이미 계산한 어텐션 결과를 재사용하는 메모리 구조입니다. 일반적인 full attention에서는 컨텍스트가 길어질수록 캐시가 커지지만 Qwen3.8의 Gated DeltaNet 층은 고정 크기의 recurrent state를 사용합니다. 전체 92개 층 중 23개 Gated Attention 층만 컨텍스트 길이에 따른 KV-cache 증가를 만듭니다.

코드 예제

bash

vllm serve Inferact/Qwen3.8-2.4T-A95B-NVFP4 \
  --tensor-parallel-size 8 \
  --quantization nvfp4 \
  --load-format fastsafetensors \
  --trust-remote-code \
  --enable-prefix-caching \
  --moe-backend auto \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --served-model-name Qwen3.8

8개 B300 GPU에 모델을 분산하고 NVFP4, reasoning parser, tool calling, prefix caching, MTP speculative decoding을 활성화하는 vLLM 실행 명령입니다.

yaml

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: qwen38
spec:
  modelName: qwen38
  instanceType: ml.p6-b300.48xlarge
  invocationEndpoint: v1/chat/completions
  replicas: 1
  modelSourceConfig:
    huggingFaceModel:
      modelId: Inferact/Qwen3.8-2.4T-A95B-NVFP4
      modelSourceType: huggingface
  worker:
    image: vllm/vllm-openai:qwen38
    modelInvocationPort:
      containerPort: 8000
      name: http
    modelVolumeMount:
      mountPath: /opt/ml/model
      name: model-weights
    resources:
      limits:
        nvidia.com/gpu: 8
      requests:
        nvidia.com/gpu: 8

SageMaker HyperPod의 InferenceEndpointConfig으로 Hugging Face 모델 소스, vLLM 컨테이너, 8개 GPU 자원, OpenAI 호환 호출 경로를 선언합니다.

python

from openai import OpenAI
client = OpenAI(
    base_url="http://:8000/v1",
    api_key="unused", # vLLM does not require auth by default
)
response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "Explain the trade-offs of MoE vs dense models for inference."}],
    temperature=0.6,
    top_p=0.95,
)
# Reasoning trace (the model's thinking)
print("Thinking:", response.choices[0].message.reasoning_content)
# Final answer
print("Answer:", response.choices[0].message.content)

OpenAI Python SDK를 사용해 Qwen3.8의 reasoning_content와 최종 content를 분리해 받는 기본 채팅 요청입니다.

python

tools = [{ "type": "function", "function": { "name": "get_stock_price", "description": "Get the current stock price for a ticker symbol", "parameters": { "type": "object", "properties": { "ticker": {"type": "string", "description": "Stock ticker, e.g. 'AMZN'"} }, "required": ["ticker"], "additionalProperties": False, }, "strict": True, } }]
response = client.chat.completions.create(
    model="Qwen3.8",
    messages=[{"role": "user", "content": "What's Amazon's stock price right now?"}],
    tools=tools,
    tool_choice="auto",
)
# The model reasons internally, then emits a structured tool call
print("Thinking:", response.choices[0].message.reasoning_content)
tool_call = response.choices[0].message.tool_calls[0].function
print(f"Function: {tool_call.name}, Args: {tool_call.arguments}")

strict JSON schema를 적용한 함수 도구를 등록하고 reasoning_content와 구조화된 tool call 인자를 각각 읽습니다.

bash

curl http://:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{ "model": "Qwen3.8", "messages": [{"role": "user", "content": "Hello, Qwen3.8!"}], "temperature": 0.6, "max_tokens": 256 }'

OpenAI 호환 chat completions endpoint가 준비됐는지 curl로 간단히 확인하는 요청입니다.